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

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2019 13:00:24 -0500

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.”

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Christian Saunders <[email-masked]>
Date: Thu, 21 Feb 2019 21:17:38 +0000

On 2019-02-21 11:00 a.m., Michael Richardson wrote:

--
Michael Richardson <[email-masked]><mailto:[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

_______________________________________________
Captive-portals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals

The active element here seems to be the forced use of insecure DNS servers.

The fact that the insecure DNS configuration was forced in order to navigate a Captive Portal is incidental, though unfortunate.

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Feb 2019 11:41:21 -0500

> The active element here seems to be the forced use of insecure DNS

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-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Christian Saunders <[email-masked]>
Date: Fri, 22 Feb 2019 16:59:08 +0000

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.
> 
> [email-masked]

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