Jamieson's Tech Blog

Stream of consciousness musings on the state of the art.

Wednesday, July 23, 2008

"Patch. Today. Now. Yes, stay late. Yes, forward to OpenDNS if you have to. (They’re ready for your traffic.) Thank you to the many of you who already have."

The largest vulnerability since about 1999 is here!

THIS IS HUGE. THIS IS HUGE. THIS IS HUGE. (AND APPARENTLY QUITE REPETITIVE.)

EVERY WEBSITE THAT YOU LOG INTO MIGHT NOT ACTUALLY BE THE WEBSITE THAT YOU THINK IT IS.


If you've ever clicked on a phishing email link, you know how it goes. There are many variations, but here's an example:

SECURITY VERIFICATION REQUIRED FOR BANK OF AMERICA

Due to recent activity on your account, we are taking steps to ensure the safety of your online banking history. Please log into your account to verify your identity.

https://accounts.bankofamerica.com/

(If you click on this, you'll see the real URL. In an HTML email, just like in a web page, the really long URL is hidden only to partly show up in the location bar when you click the conveniently short URL actually shown in the email.)

In many cases, you might not even see the whole hostname. People see the "https://payments.bankofamerica.com" and go ahead and log into the carefully copied Bank or PayPal site. (It takes about 20 minutes to set this up.)

Oh, and in case you are wondering, seldom do real social engineers (or at least successful ones) put "hahasucker" in the URL.

Once this occurs, they grab your username and password and then refer you to the REAL paypal.com "password denied." You believe that you typed it in wrong and try it again and log in successfully. (Yes, this is even possible -- although much harder -- with Bank of America's picture verification procedure, where you should be attempting to authenticate Bank of America at the same time that they are authenticating you!) The beautiful thing about this (if such it may be called) is that the victim doesn't even realize he gave his information away!

Notice the httpS in the above URL? that means you're talking on a secure connection directly to the bad guys! It costs about $10 to get an SSL certificate. Even if you see that, there's no guarantee that you're talking to the right people, only that you're talking to them securely.

ONLY if you're able to verify the hostname AND you're talking on an SSL certificate that was issued to that vendor, then HOPEFULLY you're talking to the right website, not one in Russia or Romania or China or North Korea or some hacked webserver in the U.S. or the E.U.

Of course, many vendors, including banks, refer you to a third party website (i.e., liveperson.net) for certain services. I was on Sprint's main page the other day and was referred to a third-party chat provider for login assistance. The problem here is that unless the hostname still ends with Sprint.com, it's very possible that the homepage had an XSS or CSRF attack and the link was replaced with EvilSocialEngineers.com chat "assistance." Only providing the chat link after one logs in is a bit safer, but not a lot safer. (Tangentially, the safest way is for Sprint to set up an A-Record to their chat provider and only refer to that record, but then the chat provider needs to carry a Sprint-signed SSL certificate; still, that certificate could be chat.sprint.com or something suitably restricted.)

Ok, the preliminaries are out of the way. We already know the Intertubes are a dangerous place, full of nasty back alleys and red light districts and masked men who will walk right into our bank's online lobby and rob us blind.

As of yesterday, a massive DNS hole that allows DNS cache poisoning (possibly even at the root server level) will permit bad guys to even masquerade as a particular host name. In English, that means that even if you see "bankofamerica.com" in your location bar and EVERYTHING ELSE is ok, you STILL might be logged into the bad guys.

Worse, this has NOTHING AT ALL to do with your bank. They can't help you -- they don't even see you logging in, because you never even get to them. It's not their fault.

Worse, there's very little way to really fix this problem short of redesigning the entire QID design in DNS, which will take years. YEARS. We can mitigate it a bit but not entirely prevent this from occuring right now.

Worse, THIS MEANS THAT ANY WEBSITE CAN PRETEND TO BE ANY OTHER WEBSITE, AND IT DOESN'T TAKE A ROCKET SCIENTIST TO PULL IT OFF. (Or even a computer scientist.) You could be talking to an evil Microsoft website instead of the real one. Oh, wait. Let's come up with a better example. You might be talking to the "Take your money and Run, LLC" company based in Nigeria instead of www.WellsFargo.com!

Examples of sites that are vulnerable:
yahoo.com
wellsfargo.com
aol.com
amazon.com
ebay.com
msn.com
hotmail.com
gmail.com
paypal.com

... starting to get the picture? There is no site that is not vulnerable. More precisely, no sites are vulnerable: you're not even GETTING TO THE RIGHT SITE before you're shunted off to an evil webserver somewhere else. Can you detect this? No. Can a computer professional detect this from viewing the web page in a browser? No.

This is an attack that happens at your ISP's DNS level. That means that if you use CONCast -- err, Comcast -- or Bell South or Charter or Time Warner or anyone else, they'll be about as anxious and fast and precise at fixing this security hole as they are about fixing everything else. (Yes, you've had DNS problems at your giganto-ISP-who-should-know-better, too?) Odds are they're more concerned about throttling Bittorrent than fixing holes that don't affect them -- except that this hole can't truly be fixed without redesigning DNS, which is an integral piece of the Internet itself.

The coolest part about this (spoken with tongue firmly in cheek) is that once you've poisoned your victim's DNS cache (using glue records with long time-to-lives, so your poison lasts forever) everyone who uses that DNS server will visit the wrong site .. forever! And they won't have a clue! (cue evil cackle).

Ok, enough doom and gloom. Some practical recommendations:
  • Avoid or minimize logging into any website that holds your personal information for the next few months. As always, you should never do so from a computer that you don't personally control anyway. That means, for instance, that you should never check your email at a Kinko's or hotel computer; and, yes, I do this to when I have to. At least try to clear the cache and close the browser. Better yet, install Firefox on it.

  • If you MUST log in, visit the website first. Type it in yourself, never click a link. Look for https. If you only see http, proceed no further. If you do see https, look for the padlock (Firefox, Safari) or key (Internet Exploder) and double click it. Read and try to understand the security chain. It was probably signed by Equifax or someone like that -- ok, no problem -- but make sure it was actually ISSUED TO your bank or the business that you're trying to log into and not Evil Anonymous, New Jersey. (Not that evil finds itself only in the Garden State.)

  • If you know how and are able to, use one of the following DNS addresses until you are certain that your ISP has their act together. Better yet, set this also in your router so that all your computers use these new DNS addresses. (Don't forget to DHCP release/renew!) Ah, right, forget about your ISP: just keep using these good ones. Level(3)'s public DNS servers are almost certainly faster and safer than your ISP's anyway. Level(3) offers this as a public service. (These are formerly GTE Internet addresses.):
    • 4.2.2.1
    • 4.2.2.2
    • 4.2.2.3
    • 4.2.2.4 (etc)

  • Sign up for http://opendns.com/, which is great and free (ad supported) for individuals and organizations. For your organization,

  • If you know how, install DJBDNS as a recursive resolver or hire (shameless plug!) LabArts to do it for you. This is only possible if you are using a Linux or UNIX (such as Mac OS X) operating system AND you know your way around the command line.
Again, these recommendations are no silver bullet, but they'll hopefully keep you safer until this gets fixed in a few years.

References
  1. Dan Kaminsky's blog: 13>0 [referring to the 13 days of silence for vendors to patch their systems; Dan was hoping for 30.]

    "Patch. Today. Now. Yes, stay late. Yes, forward to OpenDNS if you have to. (They’re ready for your traffic.) Thank you to the many of you who already have."

    http://www.doxpara.com/

  2. Halver's speculation that's amazingly close to the mark that resulted in the release of the actual crack:

    http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html

  3. Matasono's original "Cat is Out of the Bag" posting, since deleted. Here is Google's cache.
    www.matasano.com/log/1103/reliable-dns-forgery-in-2008-kaminskys-discovery/

  4. News articles about this. http://news.google.com/news?ncl=1229016951