CyberInsecure.com

Daily cyber threats and internet security news: network security, online safety and latest security alerts
November 4th, 2009

Browser Protocol Weakness Allows Theft/Poisoning Of Website Credentials

A security researcher has discovered a weakness in a core browser protocol that compromises the security of Google, Facebook, and other websites by allowing an attacker to tamper with the cookies they set.

The weakness stems from RFC 2965, which dictates that browsers must allow subdomains (think www.google.com) to set and read cookies for their parent (google.com). The specification also states that if a cookie for a subdomain doesn’t already exist, the browser should use the cookie belonging to the parent instead.

The arrangement makes it possible for attackers to steal or even alter the cookies that websites use to authenticate their users. Attackers would first have to identify an XSS, or cross-site scripting, bug in some part of the site they are targeting. But because virtually any subdomain will suffice, the scenario isn’t unrealistic, two web security experts said.

“Most websites actually will store session IDs in a cookie and that’s actually how they keep track of users throughout the use of their website,” said Mike Bailey, a senior researcher for Foreground Security who first documented the flaw at last month’s Toorcon hacker conference. “Using the same techniques to attack those cookies, I can really damage sessions and cause some problems.”

Bailey’s paper goes on to demonstrate how he used the technique to bypass a feature Google recently implemented to beef up security on Gmail and other properties. By exploiting a minor vulnerability in sites.google.com, he was able to falsify the contents of his global Google cookie. Google has since fixed the XSS hole in the subdomain.

In turn, that allowed him fool the Google protection, which checks to make sure the value in the cookie matches a hidden parameter of the login page.

Bailey lists several other sites that have been known to be vulnerable to similar attack techniques. Using an XSS hole on www.advertising.expedia.com, he found it was possible to poison the global cookies for the entire expedia.com domain. Because the site didn’t set the cookies with proper escaping, an attacker could have used the weakness to inject malicious javascript into expedia pages.

Chase.com, capitalone.com and chasevisasignature.com either are or were vulnerable to similar attacks because they shared code with images.bigfootinteractive.com, which was vulnerable to XSS exploits.

Bailey said it’s not hard to imagine university websites would be vulnerable to such attacks because the domain names frequently use names such as psychology.school.edu, geography.school.edu and so forth. A single bug in a student-maintained computer science project might be enough to compromise personal data stored on the college’s student enrollment server, he said.

Websites can guard against attacks by regularly checking their pages for bugs, but because the attack exploits the way browsers are supposed to handle cookies, a more comprehensive fix will probably require a change to the underlying protocols. Which means this attack will probably be around for a while to come.

Credit: The Register

Share this item with others:

More on CyberInsecure:
  • Google Adds User Enabled HTTPS Secure Connections Into GMail
  • Another Google Bug Put Users At Phishing Risk Due To Domain Flaw And Frame Injection Possibility
  • New Tool To Be Released Can Steal Authentication Credentials Through Encrypted Secure Channels
  • WordPress 2.6.2 Released Due To PHP Weakness That Might Lead To Attack
  • The Pirate Bay Compromised, Hacker Swipes Details Of 4 Million Users

  • If you found this information useful, consider linking to it from your own website.
    Just copy and paste the code below into your website (Ctrl+C to copy)
    It will look like this: Browser Protocol Weakness Allows Theft/Poisoning Of Website Credentials

    Leave a Reply

    Comments with unsolicited links to other resources will be marked as spam. DO NOT leave links in comments. Please leave your real email, it wont be published.

    *
    To prove you’re a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.