Is it dangerous to share the internet with a hacked phone?

Question

I'm sharing my hacked phone's Wifi connection with tethering, so my data travels trough it from my PC. I'm using VPN both on PC, and phone. My phone(facebook account, camera) got hacked, but I made a factory reset, and changed my passwords.

I'm using firewall, which is set to public, so it has some restrictions. Also deny all incoming connections. What can he do if I only use HTTPS, dont visit shady links, and don't download anything, which can be a virus?

Answer 1

The problem exists irregardless of whether any aspect of your communication and network infrastructure is not secure. The standing assumption should be that the network is in some way compromised, because it's basically impossible to prove that it isn't.

Having said that, I can't say with any certainty what was done and what is still possible with your previously hacked phone. You're "on the back foot" already. If you can afford to, I think you should replace the tethered phone and possibly even the wifi-ap it is connecting to.

The following long-winded and opinionated rant offers tactics for mitigating the risk posed by insecure networks, ideally ones that haven't already been hacked! Consider some combination of these going forward.

THE PHONE and WIFI ACCESS-POINT IT CONNECTS TO

1. if possible you should install an app-firewall on your phone (eg. netguard or afwall+)

2. ruthlessly cull any and all pre-bundled or convenience software - disable untrusted sources (including the default ones!)

WIFI ACCESS-POINT IT CONNECTS TO

assuming you can't eliminate wifi and just use wired networking you must review the security in the wifi-ap that you connect to - if at all possible, directly connect to the admin interface of your wifi-ap using wired networking (avoid using the tethered wifi for this bit if you can):

1. change the default admin password to a strong passphrase

   • if possible, permanently disable the admin interface via wifi
   • lower the transmit power (switching to a less congested band may help here)
   • ensure there is no dmz or inbound routes configured
   • if possible, choose a more secure protocol that allows for client and server certificates when establishing the wifi-based link (unlikely on consumer-grade hardware)

2. ensure use of the "most secure" wifi protocol available, ie. at a minimum wpa2

   • create a new (longest possible) random (high-entropy) pre-shared key, eg: https://www.grc.com/passwords.htm Gibson'20
   • ensure wep is disabled
   • also disable wps (pin-code/ wifi protected setup)
   • if possible, choose a more secure protocol that allows for client and server certificates when establishing the wifi-based link (unlikely on consumer-grade hardware)
   • remember: you need to update the pre-shared key on the phone, and assuming it is still compromised, this new psk will still be available to your adversary (... but that won't matter, because they can access all the packets- encrypted or not- flowing to and fro anyway!)

YOUR OTHER DEVICE

1. you're using a firewall on your device which is good - you should also audit the listen servers and open ports running on your device's local os and disable any services that aren't in use

2. since you already have a pre-existing vpn in use now might be a good time to plan getting a new account:

   • consider using your own- or some commercial- wireguard (or equivalent) vpn service provider
   • change your account credentials that you use to connect to your provider as they may have been stolen from your phone
   • (if at all possible don't use the new account credentials from the phone, eg. manually specify the host endpoints and pk-certs)
   • alternatively consider some other form of encrypted point-to-point tunnelling, eg, sshd socks5 proxying
   • ensure all traffic is forced through this tunnel (easier said than done)

3. you've hard-coded your dns service provider which is a step, however, check the following:

   • ensure the dns resolution is configured to occur through the vpn
   • consider the use of a locally installed dns cache that supports dnscurve or equivalent
   • ie. another option is to configure your browsers to prefer the use of dns-over-https (aka doh) resolvers to resolve host ip addies

4. on the topic of your browser:

   • configure it to force the use of https
   • consider using some extension that allows you to limit what 3rd-party resources will be loaded at time of page load, eg. ublock origin or the currently unsupported umatrix (both by the same author) and configure this to restrict all 3rd party by default
   • review https://browserleaks.com for webrtc leaks

5. audit the certificate authority store to ensure nothing unexpected, and find out how this gets updated

6. also find out how your host os and other installed software is kept up-to-date automatically - are updates delivered securely?