Hacking Public Wi-Fi DNS to Steal Credentials
Attackers can hijack public Wi-Fi DNS to redirect users to credential-stealing fake login pages; commenters debate HTTPS limits and mitigations like encrypted DNS.
The discussion examines how an attacker controlling DNS on shared or public Wi-Fi networks can redirect requests for legitimate services to attacker-controlled servers to steal credentials. Commenters analyze whether HTTPS and certificates mitigate the attack, noting attackers often rely on HTTP or browser trust quirks. Suggested defenses include encrypted DNS (DoH), DNSSEC, and travel routers running OpenWRT. No specific campaign, victims, or indicators are provided.
- DNS control on shared networks enables redirection to attacker-controlled credential pages.
- Commenters debate HTTPS/certificate limits; attackers may fall back to plain HTTP.
- Mitigations discussed include encrypted DNS, DNSSEC, and OpenWRT travel routers.
- No specific campaign, victims, or technical indicators are provided.
- Products
- Firefox
Indicators of compromise
auto-extracted · verify before use · export allAll| Type | Indicator | Context |
|---|---|---|
| domain | www.schneier.com | em, three of the five browsers on my laptop complained that www[dot]schneier[dot]com was insecure, and somebody might be spoofing it. I |
| ipv4 | 1.2.3.4 | -browswer. DNS lookup is redirected and goes to a the wrong 1.2.3.4 ip address. As long as that IP address has a security cert, |
| ipv4 | 8.8.8.8 | in LA, what should I do – edit my android hosts file to use 8.8.8.8 to get DNS? Aim my browser at the IP address of my hosting |
From the original article
8 min read at schneier.comWould that be compatible with https? Would the fake login page not have the wrong cert, if it even had SSL enabled? Or is the user meant not to notice a redirect from att.
By Bruce Schneier · schneier.com
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.