Cookie-jacking: Potential security risk largely ignored by public

by Steve Ragan - Aug 25 2008, 21:05

During Defcon this year, Mike Perry of Riverbed Technology (and also a privacy advocate and part-time security researcher), gave a talk covering a common failing in SSL security online. This address spawned from another given in 2007, where Perry talked about Tor security. Offering up information on a very serious problem, Perry was largely ignored by the security world and, more importantly, by the Web giants the issue largely affected. Tired of waiting to be noticed, Perry is taking his issue public and, in the interest of full disclosure, plans to back his findings with details and a tool that can be used to execute the attack.

Full disclosure is a highly-debated topic. Like asking a room full of people to decide on pizza toppings, getting researchers to agree on full-disclosure principals and policy is next to impossible. The issue of full disclosure is made worse when you get vendors involved. Moreover, add lawyers to the discussion, and your head can spin.

However, thanks to some highly-visible problems, full disclosure is once again in the limelight. There are two issues, current events, which are prime examples.

The first one is Dan Kaminsky and his DNS vulnerability. For this, it isn’t just the damage his discovery could have caused, but his methods for releasing information that set some in the security world on end and armed them with pitch forks and torches.

The second, is the three students from MIT, Zack Anderson, R.J. Ryan, and Alessandro Chiesa, who were going to give a talk based on security flaws in magnetic stripe tickets and RFID cards (CharlieTicket and CharlieCard). The CharlieTicket flaw was new in respect to the reported problems, but the CharlieCard flaws were well established and previously known to many in the security and research world. The CharlieCard issues revolve around the use of the MiFare Classic RFID chip, developed by NXP, which has been proven to be seriously flawed.

In both of these cases, there were opinions issued both for and against the respective methods of disclosure.

A new entry to the full disclosure debate is the discovery by Mike Perry, called Automated HTTPS Cookie Hijacking.

Originally, Perry’s research and information was released in 2007, in a posting on BugTraq. However, at the same time Perry reported his findings, a similar attack vector was getting attention. Called SideJacking, the process was researched and demonstrated at Defcon 15 by Robert Graham, CEO of Errata Security.

SideJacking is a method used to compromise a Web-based account by snatching cookies from Wi-Fi networks (In the SideJacking demo at Defcon, one user had their Gmail account SideJacked live during the talk, the user was victim to an unscripted demo).

It is largely because of the tool released shortly after Graham’s talk, and the lack of forewarning, that gave SideJacking its hype. However, the vector of attack and the tool do deserve their proper credit, as does the creator. Yet, with no live example or tool, Perry and his research were ignored.

This is where full disclosure comes back into play. Perry developed a tool to exploit his reported vulnerability, which currently affects Google (Blogger, Doc’s, Gmail), Bank of America, Domain Registrars Register and Namesecure.com, Netflix, eBay, and a host of other services and sites; and he plans to release this tool and all of the information needed to use it. Now, suddenly his research is valid and the press and security community are taking notice. Unlike what has been reported, this is not a simple Gmail flaw, and the offering by Google to fix the problem (providing the option of using only https for Gmail) was not a complete fix.

Perry explains why Google is still missing out on the protection in a blog post on fscked.org:

“First off, the average user will not set this [preference]. They have been trained that "https in the URL means it is secure". Even if they do see it, they will likely read the help for the option (which informs them https is slower), and think to themselves they do not need https always, but really only sometimes.” adding that Gmail users with hosted accounts will not have the https option, and https is not applicable to other Google services.

“Gmail is now setting the 'secure' bit on their 'GX" cookie for users who start out in https via the login page. However, it is still possible to redirect these users to http://mail.google.com, and cause the login system to demote their GX cookies back to insecure. Additionally, users who start out in http, but later decide they want SSL security by navigating to https://mail.google.com still do not get their cookies set as secure.

“SSL may be expensive, but it certainly should be a market differentiator, and with the investment, it certainly should be done properly. Without a valid threat and the associated publicity storm to encourage people to choose secure, properly implemented, SSL-enabled services over insecure ones, the market is not going to function properly, and important sites will continue to be insecure, perhaps not even providing SSL at all."

It's also worth noting that, along with Google issuing a quasi-fix, Microsoft Corp. has committed to providing a timeline for a fix by Friday.

While there have been no direct criticisms of Perry’s work, he is still a potential target in the full-disclosure debate. In a recent interview, the Tech Herald asked him why he thought full disclosure was such a volatile issue. He gave a unique spin to the normal arguments, telling us that he thinks people revert to a “shoot the messenger syndrome,” and fail to understand that just because a researcher won't release a tool, does not mean there aren't people able to exploit the issue on their own using no tools and running on limited information.

"Not to mention they are often financed by organized crime or their own illegal activity and have way more time and motivation to develop exploits than honest researchers do. This is especially true in the case of general exploits where people need to test their systems and see if whatever custom protections they have may have leave them still vulnerable or not," Perry explained. 

"Yet obviously, dropping fully functional 0days with no notification doesn't help anyone, and can do quite a bit of damage. However, the other extreme where people say "we should never ever release functional exploits" is also bad, because it keeps new researchers from learning an art that really has to be learned on the streets, and can't be effectively taught in any institutional curriculum."

As mentioned, Perry is moving forward with his release, and his consistent blog postings on the subject can either remove him from or place him in the direct line of fire where the debate on full disclosure is concerned.

What is refreshing though, is that Perry is not just releasing details and tools; he is offering help as well. However, this help will come with a condition as Perry explains:

“At some point after receiving timelines from Microsoft and Google (depending on the duration and level of security provided), I will begin providing copies of the tool to anyone who matches the contact information for ANY domain with any type of unofficial SSL certificate. At some further date after that, I will begin provide copies of the tool to anyone who asks, and then shortly after that, the tool will be posted publicly.”

Perry sees this as the best way to balance “the need for people to have the ability to test their sites with the need to not damage the general public by unnecessary early release of an automated exploit tool.”

Expect more from Mike Perry as this story unfolds, it should prove to be an interesting experiment in managed disclosure.

Update: Click here to learn more about the public availability of Perry's emergent "CookieMonster" tool.

Around the Web

comments powered by Disqus