[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] poor captive port design --- A Deep Dive on the Recent Widespread DNS Hijacking Attacks — Krebs on Security
On 2019-02-22 9:41 a.m., Michael Richardson wrote:
> CAUTION: This email is from an external source. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> Michael Richardson quoted:
> > From https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/
> > "The two people who did get popped, both were traveling and were on their
> > iPhones, and they had to traverse through captive portals during the hijack
> > period,” Woodcock said. “They had to switch off our name servers to use the
> > captive portal, and during that time the mail clients on their phones checked
> > for new email. Aside from that, DNSSEC saved us from being really, thoroughly
> > owned.”
> Christian Saunders <[email protected]> wrote:
> > The active element here seems to be the forced use of insecure DNS
> > servers.
> I disagree. It's due to forced use of the captive portal's DNS.
> A device will in general have no trust relationship with a captive portal.
> It has no reason to trust the captive portal to do DNS correctly
> (and no way to get privacy for the requests either).
> > The fact that the insecure DNS configuration was forced in order to navigate
> > a Captive Portal is incidental, though unfortunate.
> So to me, all captive portal DNS systems are by definition insecure.
> If one needs to do a DNS lookup in order to get traffic and get a
> redirection, then the portal is insecure. And that's why we need an API that
> involves more than just capture port-80 and redirect.
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect [
> ] [email protected] http://www.sandelman.ca/ | ruby on rails [
> Captive-portals mailing list
> [email protected]
Point taken - and I agree with your reasons as well as your solution.
My meaning was only to suggest that there are other reasons/cases where
a network or application may force a particular set of DNS servers and
that users in those cases may be exposed to the same attack.
Sr. Software Architect, Wireless Core
Shaw Communications Inc.