Chase, American Express, Office 365 vulnerable to cookie replay attacks

You are Bob. I am Alice. Although we can’t see them, two others – Eve and Mallory – are reading over our shoulders. Eve is feeling evil and Mallory is full of malicious intent. Both Bob and Alice have accounts with financial services we access via the Internet. If those sites we accessed included Chase or American Express, both Eve and Mallory would be wickedly delighted, because they could steal the cookies when we logged in and then replay them to access those accounts and do with them as they wanted.

Office 365 was among the seven “bad” sites that allowed cookie re-use and could be hijacked, as pointed out by ethical hacking teacher Sam Bowne last week. At that time, he asked people to test other sites and let him know the results. And people did, highlighting that Microsoft is one of the worst offenders. Office 365 not only would allow an attacker to re-use cookies to hijack an account, but the stolen cookies still work after resetting the password! But wait, there’s more! The cookies from Microsoft’s Outlook.com and Hotmail still work when copied to another machine, too.

Conversely, Google doesn’t suffer from this same issue. If Google can fix this for Gmail, what is Microsoft waiting on? In December 2012, Microsoft Security Response Center brushed off The Hacker News for reporting it, calling it a “known issue” that would be addressed in an “upcoming release.” It’s July 2013, so when is the fix slated for that “upcoming release?” Is the issue so “difficult” to fix that Microsoft needs to contact Craigslist or Slashdot for a “how-to,” since both are listed as “good” sites that don’t allow cookie re-use?

Oh wait, Microsoft published a help page in 2007 to help people setup the right configuration to reduce the risk of cookie-replay attacks.

Meanwhile, Bowne notified major financial sites of also being vulnerable and gave them seven days to fix the flaw. They didn’t bother to fix it, so now Bowne has publicly disclosed the vulnerabilities in both American Express and Chase. He told me, “I sent the information to their computer security departments, and both Chase and AmEx acknowledged receiving the messages, but never got back to me further.”

The list of “bad” sites that reportedly allow cookie reuse and therefore are vulnerable to replay attacks started at seven and grew to 27. All it needs to grow more is for people to test more sites and services. It’s super-duper simple to do, and Bowne has posted step-by-step instructions with screenshots. Here’s the growing list of “bad” sites:

Financial: Chase and American Express.

Shopping: Amazon, NetFlix, TigerDirect, and IBM (including Many Eyes).

Email & Social: Office 365, Live.com, Yahoo mail, Twitter, LinkedIn, WordPress, Apple’s iCloud, StumbleUpon, and Flickr.

News: Forbes, Huffington Post, The Guardian, The New York Times, The Register, and Reddit.

Security: CloudFlare (The company is reportedly fixing it).

Others: Github, CourseSmart, Waze, and Vimeo.

Why should you care? Put another drastically simplified way for the nontechnical who don’t know much about cookies other than the kind you eat: What if the key to your private life, or your business life, was stolen?

Let’s use your house key. Someone secretly grabs the key, makes a copy, and returns your house key so that you never know it was stolen and copied. If you don’t know about it, then you probably wouldn’t change your locks. Therefore, the crook with the key could come and go whenever he wanted to, free to rifle through your private and personal belongings, and your sensitive and financial paperwork and files; so long as you didn’t catch him, then your house would be forever owned.

Let’s say you do catch the crook with your key, or otherwise become aware of it, so you change your lock. What if the stolen and copied key could still open the door? When it comes to cookie-replay attacks, even if you change your lock (password), it simply doesn’t matter. As Bowne explained to me:

It’s more powerful than session hijacking, because it doesn’t kick someone out while they are logged in and take over their session in progress. It’s more like a stolen password, because the attacker can come back and use your account over and over with the cookie. And you can’t stop them, even by changing your password. It’s really scary–someone could steal your cookie once, invisibly, and then they own your account for a long time, and there is nothing you can do about it.

After reading my house key example and then some more testing, Bowne found that the risk was reduced with American Express; users are automatically logged out after only 10 minutes of inactivity, so “the house key analogy is not really fair to them,” he told me.

Bowne previously explained why cookie reuse (replay attack) is important. “There are many ways of stealing cookies; XSS, malware, or just stealing your phone. And the person with the cookie can still use your account after you log off. So the ‘Log off’ feature is the opposite of security–blocking the authorized user but not blocking the attacker.”

He elaborated on ways to steal cookies:

The simplest way to steal a cookie is to steal a phone or laptop computer. Cookies are stored on the computer, and even if you change your password, the old cookies can still be used to access your account.

The most common way to steal a cookie is through Cross-Site Scripting. An attacker creates a malicious link or Web page, and when the victim views it, their cookies are sent to the attacker. This is also easy, because browsers send cookies to Web servers all the time. All the attacker needs is a way to trick the browser into sending the cookie to the wrong server, and there are many ways to do that. The simplest is at an Internet coffeehouse, just eavesdropping on the Wi-Fi traffic–that’s how FireSheep did it.

The Firesheep add-on, as you may recall, made it so simple that even the clueless could hack Facebook, Twitter, Amazon, Google, Cisco, Dropbox, Windows Live and many more services over Wi-Fi. Firesheep caused a big stink and many sites closed the holes.

As consumers and users, we should expect sites and services to be secured from such simple attacks that reuse cookies.

Bowne asked people to test more services and tweet the results to him @sambowne, so please do.

Microsoft may or may not choose to comment later as I asked, “There is a list of sites tested so far that are not vulnerable, so why doesn’t Microsoft also fix this flaw? Is it that difficult to implement? In Dec 2012, MSRC called it a ‘known issue’ that would be addressed in an ‘upcoming release.’ It’s July 2013, so when it that ‘upcoming release’?”

Update 1: Bowne retested, then said: “Both Chase and AmEx cookies expire after ten minutes, which compensates somewhat for their poor cookie handling.”

Update 2: Dustin Childs, group manager for Microsoft Trustworthy Computing said, “The cookie handling issue described is not a security vulnerability as it would require the attacker to be physically present at the machine, on the same network or be combined with a more severe issue. Any machine to which a would-be attacker has access to run his or her own programs is, by definition, not a fully secure machine.”

Like this? Here’s more posts:

• You might be a terrorist if…you complain about your tap water
• Microsoft joins ranks of those believing the government is conspiring against them
• Microsoft cites constitutional rights to lift gag orders, tell public about gov’t spying
• Govt’s $2.7 million KILL IT WITH FIRE approach to malware: Destroy all hardware
• How much privacy will you have with Microsoft’s ‘family of devices’?
• Hackers can wipe or steal data from security holes in 300,000 servers
• Hacking and attacking automated homes
• Hijacking Office 365 and other major services via cookie re-use flaw
• MSFT to developers: Fix Windows app security flaws in 180 days or be kicked from stores
• Microsoft Research: MoodScope, a context-aware smartphone to sense and share your mood
• USA PRISM Plus, the perfect NSA photo-sharing app for those who have nothing to hide

Follow me on Twitter @PrivacyFanatic