Re: [Captive-portals] poor captive port design --- A Deep Dive on the Recent Widespread DNS Hijacking Attacks — Krebs on Security

[Christian Saunders <[e-mail]>]

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 <[e-mail]> 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   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
> 

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.

Christian Saunders
Sr. Software Architect, Wireless Core
Shaw Communications Inc.