[dns-operations] A Deep Dive on the Recent Widespread DNS Hijacking Attacks

Bill Woodcock woody at pch.net
Sun Feb 24 06:17:05 UTC 2019



> On Feb 23, 2019, at 12:00 PM, Lee <ler762 at gmail.com> wrote:
> Have you made any changes in response to this bit
>> Woodcock said PCH’s reliance on DNSSEC almost completely blocked that
>> attack, but that it managed to snare email credentials for two
>> employees who were traveling at the time. Those employees’ mobile
>> devices were downloading company email via hotel wireless networks
>> that — as a prerequisite for using the wireless service — forced their
>> devices to use the hotel’s DNS servers, not PCH’s DNNSEC-enabled
>> systems.
>> “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.”
> that you can talk about on an open list?

Sure, happy to.

The main thing so far has been switching the VPN to “always on” setting.  It sometimes causes devices to run through battery really fast, when you roam onto a network that blocks VPN traffic, and apps go crazy trying to reconnect.

We’re switching to split-horizon DNS, such that nothing else which requires authentication will be resolvable without first being on the VPN.

We’re investigating whether MDM can enforce DNS or routing policy to ensure that devices never query our domains against other recursive resolvers, or send traffic for our IP addresses outside the VPN.  Getting differing opinions from folks as to whether either of those are possible.

Longer-term, we’ve increased the amplitude of our badgering of Apple Product Security regarding DNSSEC and DANE validation in the OS, rather than via recursive resolver.  Both of those should be end-to-end, not dependent on an external resolver.

Anybody have any other suggestions?

                                -Bill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190223/04ce6829/attachment.sig>


More information about the dns-operations mailing list