How Would an Attacker Use This Traffic to Hack You?
I did not hack anybody or compromise anybody’s privacy, and I did consult with legal counsel before publishing this. But, here are some of the ways that people using public Wi-Fi can be compromised, today, by inexpensive hardware and/or free tools (e.g. wireless adapter, Wireshark, Bettercap, etc.).
First, to successfully carry out a phishing attack, an attacker could target some of the popular sites that are accessible over HTTP and not implementing HSTS properly, maybe also leveraging DNS requests since all are insecure (in a sense, captive portals used to work by carrying out DNS-forged MITM attacks every time they wanted to display their splash pages, and this is easily accomplished with DNS today since DNS has never been secured properly since).
Create a Sense of Urgency
Our hypothetical attacker could, ideally, create a sense of urgency to get users to make more mistakes by hurrying (i.e. overlooking the long and slightly modified URL in the address bar). For example, a captive portal that prompts a user for their email address and provides a very short amount of time to check email for a verification link before they get kicked offline could be the perfect companion to a phishing login page for said email provider.
Best yet, once grabbing the user’s credentials and confirming that they are correct, booting them off the network with a fake error message might slow them down from noticing the compromise or from resetting their email password. >:~>
Fabricate a Familiar Pretext
Serving up the hypothetical attacker’s own phishing pages and securing them with Let’s Encrypt certificates should be easy enough. At least, then, they should look “secure” just long enough to fool a frantic Internet addict into trading their digital identity for a few more minutes of Snapchat. If someone wanted to target credentials for a higher-profile website — perhaps one that actually implements HSTS properly but, with no surprise, just like a number of popular websites it isn’t in the preloading list — the attacker could just wait to target potential victims until after their computer sent an NTP request.
By playing with time travel and alternate universes (forging an NTP response with a time set in the future), all HSTS policies cached by the user’s browser whose cache entries expired before the new “present” time could be invalidated. Then, the attacker could just carry out a downgrade attack, 301 Redirect via HTTP to a phishing page, and the rest is gravy.
Confuse the s/Deputy/User/
Our hypothetical attacker could trick people into installing some backdoor or botnet software. From then on, the attacker could basically pwn their devices, information, and network of contacts whenever convenient, and identity theft or theft of money would be easy. For this, the attacker could pop up some “warnings” about viruses or spyware on the computer, and kindly suggest that users install an actual virus to “fix” it.
This would require the user to actually allow the attacker’s software to be installed. Alternatively, our hypothetical attacker could just mine cryptocurrency in users’ web browsers, which wouldn’t require tricking users into giving their consent for software to be installed.
Hit the Unencrypted Plaintext Jackpot
Additionally, the traffic that my tool saw sent over Port 5090 is interesting, in that it is a port used by common business VoIP mobile apps to send phone calls over the SIP protocol. Some cellular providers similarly offload voice traffic in this way. I was pleasantly surprised to see this in my statistics! Even if SIP payloads are encrypted, their headers are not, and often contain CID and DID (telephone numbers) in the clear.
This could be particularly useful to our hypothetical hacker for carrying a vishing attack on victims or their contacts, since CIDs are easily spoofed to make an attacker caller look familiar. If our hypothetical hacker wanted to hack you or your life by phone, he or she could gather these phone numbers and have a little fun with them later. >:~> >:~>