Comments

Humdee February 20, 2019 9:02 AM

Two brief remarks on the opsec of this situation. First, I feel vindicated with my practice of turning on email auto upate only when I want an update and not let it sit in the background. Yes this is a PITA but it decreases attack surface. I hope this incident prompts Google to retink it horrible practice of not allowing access to gmail unless autoupdates are turned on.

Second, regarding the fact no one noticed the one hour window. @bruce wrote years ago about how technology was so buggy it was often impossible to tell what was bug and what was attack. This case is a beautiful albeit sad reminder of that truth.

me February 20, 2019 9:40 AM

I hope this incident prompts Google to retink it horrible practice of not allowing access to gmail unless autoupdates are turned on.

??? i don’t have gmail (i use posteo, which has dns-sec) but as far as i know if you enable imap on the web interface you can use thunderbird and configure it for manual or automatic updates, i have a “disposable” gmail account configured that way, so that i have to click “check new emails” in thunderbird. while for the posteo account i have configured it to sync on thunderbird open and every 15 min.

i don’t find that your opsec is very useful, yes checking emails less often expose you less but it’s all about luck you could have checked email in that hijacked hour.
security should be more than luck.
an example can be trusting single ssl cert for thunderbird instead of using ca root based scheme. or using certificate patrol which warn if the cert change.

Humdee February 20, 2019 10:45 AM

@me “security should be more than luck.”

Well of course security should be about MORE than just luck but luck enters into the equation; it is intrinsic to the notion of risk. So all I take your comment to assert is that you and I have different risk profiles and that is banal.

“but as far as i know if you enable imap on the web interface you can use thunderbird”

Security should be more than using obscure settings and little used programs. This attack worked precisely because most people use the default client and under Android the default gmail client is gmail and the gmail client requires auto updates turned on and that requires a constant refreshing of credentials. The right solution to Google’s horrible security practices is not to send people out of the common road turning on switches in deep caves and downloading obscure programs: it is to fix the defaults. What Google has right now is its users playing Zork under the guise of a security paradigm.

Arclight February 20, 2019 11:59 AM

It doesn’t help that ISPs seem to love messing with, redirecting and otherwise diddling DNS requests whenever they want to communicate with their customers or to inject tracking cookies/ads. DNS-SEC that actually works end-to-end would go a long way here. Also, it seems like we’re approaching the point where e-mail verification is just as bad as SMS when real money is on the line.

Jesse Thompson February 20, 2019 3:42 PM

@Humdee

So if your advise is for Gmail to change it’s defaults, it sounds like you are saying they should turn email auto-update off by default, is that correct?

If not, then I personally have a challenging time imagining somebody knowing enough to understand the security difference between autoupdates being on or off being confused by the concept of installing a third party email client which offers that security advantage.

EG: if you need the switch to be so close to hand, are you liable to understand what the switch is even for?

How many people who do not know what it’s for will wind up missing emails because they just “pushed the big red button marked ‘security'” without internalizing the changes to their workflow that decision would require?

me February 21, 2019 4:39 AM

@Humdee

Security should be more than using obscure settings and little used programs.

imap is standard excactly like pop3 and the more “modern” web interface and i don’t think thunderbird is little used program.
(please note that i’m talking about windows)
on android i don’t use email or passwords in general, it’s just completly untrusted for me… i don’t even have mobile network, only wifi and it has timeout, i don’t like to be contacted all the day, if you need to contact me “urgently” you can call me, otherwise i prefer to see your message when i pick up the phone for some reason.

default client and under Android the default gmail client is gmail and the gmail client requires auto updates turned on and that requires a constant refreshing of credentials

thanks for the clarification i thought you were talking as “gmail require autopudate” meaning gmail as a service (not true as i said) while you were meaning “gmail as application”.
i think that this is the default because:
-people expect their email to be synced
-google wants to know how much you use the pc/phone and where you are.
but mostly the first

me February 21, 2019 4:53 AM

i have some questions to all readers:

1-how can i find out if my dns has dns-sec enabled/is supported?
now, supposing that i’m using a dns-sec enabled server
2-the client side (windows) must support dns-sec to be used right?
3-it’s something system-wide so that if windows supports this it’s “extended” to all the apps or every app must support it? if it must be app-level firefox and thunderbird support it? (without plugins)
4-is it secure that just works like tls certificates that can’t be abused or it’s a bad solution? (i know that tls certs can be abused too but misinsurance can be mitigated, noticed and it’s rare; private key theft it’s not a tls problem; and if someone steal your domain and gets a legit cert it’s again not a tls/ca infrastructure problem it’s outside scope; if you click ignore on the warning “someone is intercepting the connection” it’s your fault)
5-i know that in tls if someone mess with the connection i will see a warning, they can’t intercept my data without my consent, the “best” attack they can do is dos (because warning or drupping traffic on port 443). what about dns-sec? what it aim to prevent? mitm?
6-what is the scope of dns-sec? tls is data integrity, autenticity and secrecy

tl;dr: i’d like to know more about dns-sec because to me looks like something obscure and i can’t find easy explained informations on the internet

thanks a lot for any answer

me February 21, 2019 5:23 AM

with tls there are two other important problems:
-http is insecure and still used and even if you type “https” you can’t know if it doesn’t open because mitm is dropping packets or the server has no support for tls so it’s not listening on port 443 (same problem apply to digital signatures of exe, if there isn’t you can’t know if the exe has been hijacked and signature stripped or it’s just missing because the author has not signed it)
-ssl strip with mixed content, http to https redirects…

so i’d like to know what happens in case of attacks and what is prevented.
without dnssec anyone can do whatever they want with your dns query/answer. with dns sec how much it improve? what change?

i hope i’m not spamming too much
thanks

AL February 21, 2019 11:31 PM

I use a dnscrypt solution, because I like my DNS to be strictly UDP tranmission. The one I’m using is dnscrypt-proxy. That takes care of encrypting my connection to the DNS server. I hardcode my choice of DNS provider into dnscrypt-proxy. My choice of DNS server is Quad 9. This is a service that blocks sites known to be malicious, but no other blocking is provided. On their malicious blocking DNS servers, they employ Dnssec.

So, at that point, I think it is up to the web site, particularly a site that deals with finances, to follow best practices and use Dnssec.

I’ve done my part. If I lose any money due to some online compromise, my suit will include the failure of the financial company to utilize Dnssec, should that deficiency become apparent (after the interrogatories).

65535 February 22, 2019 8:32 AM

@ me and others

Re: DNSSEC

There are a few complications. Poster here that are more knowledgeable can probably answer better – but I will give it a go. YMMV

The first is it cost money to implement it. For those who are on the wrong side of the TLAs it would blow their OPSEC unless front-man after front-man companies were used to buy it.

Moving to the current case:

“It is somewhat more complicated for end-users. You can set your DNS settings to something like Google’s DNS — 8.8.8.8 and 4.4.2.2 — which should enforce DNNSEC when the domain signs it as such. But things can get trickier when you are not on your own network, and your mobile data provider’s DNS settings kick in. I’m not sure there is a way for end users to control what DNS settings get used in that case.”-Brian Krebs

https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/#comment-483747

Next are some complications:

Kreb’s comment ecco points to PowerDNS blog:

[ecco]

https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/#comment-483763

[PowerDNS blog]

“…As DNS becomes more complex, the number of people that “get it” also goes down. Notably, the advent of DNSSEC caused a number of implementations to drop out (MaraDNS, MyDNS, for example).Also, with the rise in complexity and the decrease in number of capable contributers, the inevitable result is a drop in quality:[chart removed] …with the advent of DNSSEC this is what we found. For several years, security & stability bugs in popular nameserver implementations were absolutely dominated by DNSSEC and cryptography related issues.”-powerdns

https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/

I think there are a few “Kinks” to iron out before it can be implemented – so to speak.

Rach El February 22, 2019 7:40 PM

65535

the better DNS solutions cost money and require expertise.
There is also the issue of who to trust. In some respects the trust is just being shifted to a different surface, and it becomes security in exchange for privacy
. albeit a better class of problem depending upon ones model.

a benign example is firefox sending everything via googles servers when browsing to check websites against their database of malicious sites

i’m also thinking of OpenDNS being acquired by Cisco, which was quite unfortunate.

65535 February 23, 2019 4:01 AM

@ Rach El

“better DNS solutions cost money and require expertise. There is also the issue of who to trust. In some respects the trust is just being shifted to a different surface, and it becomes security in exchange for privacy . albeit a better class of problem depending upon ones model.”- Rach El

Good point.
Who do you trust?

“a benign example is firefox sending everything via googles servers when browsing to check websites against their database of malicious sites…i’m also thinking of OpenDNS being acquired by Cisco, which was quite unfortunate.”- Rach El

Yep. I cannot argue with that. Who do you trust?

Rach El February 23, 2019 11:20 PM

65535

Who do you trust?

I can’t tell if you are being rhetorical or not so I’ll try and interpret you literally. In the case of DNS I don’t trust OpenDNS any more. DIY solutions are preferable and require expertise.DNScrypt looks good. There are some solutions that look attractive to me that require some financial investment. I’m still fine tuning my approach but it sounds like you’re at about the same place I am. With DNS it appears the main point is surpassing a certain threshold to mitigate most of the more common issues.
I’ve had problems with accessing some ISP’s though.

As for my instance of privacy vs security, well YMMV. A great way to avoid malcious websites is not to browse malicious websites, instead of getting googles servers to work it out. considering everything goes through google anyway, if one is at the level of using firefox, their malicious site checklist is probably okay

me February 25, 2019 3:47 AM

@65535

so seems that google and cloud flare dns has dnssec enabled so, server-side they will refuse to answer if they receive a bogous update like that.
but unless it’s enforced also client side they will not help much as it is still possible to do man in the middle, force you to use different dns…

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.