The Washington Post was first to break the story on the proposal of Senators Schumer and Cornyn to require prepaid cell phone purchasers to provide ID. Now, most of the media has been reporting in the same typical "objective" sense, with some grandstanding statements voiced by the Senators being "balanced" by privacy advocates. The final paragraph of these articles typically sums things up by pointing out that about 10-15 countries already require ID for prepaid cell phones. The thing that is appallingly missing is that no one in the mainstream press has stopped to do the minimal amount of research to see if prepaid cell phone registration has at all reduced crime or terrorism in any these countries, nor have they really questioned if it stands any chance of actually working. Not one person has stopped to question the core assumption of this proposal, and that is this: it requires that WE TRUST OUR NATIONAL SECURITY TO OUR POINT OF SALE CLERKS.
After waiting far, far longer than I had originally anticipated, I'm finally publicly posting the CookieMonster utility. I've worked with a number of developers and site admins to help test and secure their sites properly, but unfortunately, it is still the case that many sites still are vulnerable. In fact, even after much correspondence with Google on the subject, it is still possible to hijack the GMail accounts of users who attempt to use https but are unaware of the Always Use HTTPS Preference. Using Cookiemonster's FULL_BOUNCE_FOR config option to redirect those users to the plain http://mail.google.com url will still cause Google to re-issue an insecure version of their 'GX' cookie which a local attacker can then sniff to hijack their Gmail accounts...
I've spent the past four and a half years of my professional life working on reverse engineering and accelerating the Microsoft Exchange email protocol for Riverbed Technology, Inc. It's been a maddening journey, and it finally comes to a close this Friday, as I have accepted a position with the Tor Project starting January 1st. What follows is my farewell email to the company. I somewhat regret not documenting the exploits alluded to in this email better outside of various Riverbed email lists. Maybe someday when the statute of limitations is up I'll declassify them and post them retroactively here.
Two weeks ago, I announced on slashdot that CookieMonster was available via email to people who were security consultants and site admins. Unfortunately, I guess I wasn't crystal clear on the procedure for requesting the tool, and many people simply emailed me with no body. Now I'm announcing it again, and also opening up the field to all journalists and all bloggers as well. So, if you would like a copy of the tool, and are a security consultant, teacher, student, blogger, journalist, or site admin, please email me with which sites you admin, write for, blog on, or consult with, and MAKE SURE to put "CookieMonster" in the subject line. If you can't figure out my email address, you are automatically ineligible for the tool ;).
About 3 weeks ago, I sent a preliminary copy of the CookieMonster tool to an Amazon employee who requested it after I announced they were vulnerable, and that it was available for testing/proof. I was glad he contacted me, because I was having a really hard time contacting their security team (all their security pages are FAQs on phishing, and their security alias returns a bounce saying not to trust any mail that comes from it!).
He didn't mention anything in specific or even claim to officially represent Amazon, but we did exchange a couple emails, and he seemed legitimately interested in the tool. Then, about a week or so ago, I received word via a friend of a friend that an Amazon employee had gotten some heat for requesting the tool. Since there was only one Amazon employee who bothered responding or requesting the tool at all, I decided to send him an updated copy and wish him luck on whatever happened. To my great surprise, the email bounced with a "no such user" error. The address certainly was valid when I sent him the first copy, so I'm not sure what this means. I suppose it could be coincidence: the employee could have just quit, but I suspect something fishy is going on..
Shortly after Drupal fixed their issues with cookie demotion, I applied the patch. Unfortunately, since I run both http and https on my site, when I added ini_set('session.cookie_secure', 1) to my settings.php, it caused cookies for my site to get marked as secure even for http visitors. This had the side effect of breaking comments for my site, since the captcha module could not track users that properly solved it. Some of you noticed and contacted me, thanks for the heads up. Check below the fold for some suggestions and solutions for flagging Drupal and other php-based session cookies as secure for mixed sites.
I've realized that the fact that I'm still getting questions to the effect of "How does this attack differ from Robert Graham's 'Sidejacking' attack?" means I did not do a very good job of classifying what sorts of vulnerabilities a Man In The Middle attacker can exploit over the web, especially with respect to what CookieMonster does that other tools do not (or at least do not automate). This post is an attempt to clarify the situation, and describe the two main classes of cookie stealing Man In The Middle vulnerabilities that popular websites are vulnerable to, depending on their security properties.
Google has committed to providing automatic secure cookie support for https gmail users by 9/4/08 via a mechanism similar but not identical to the method I described in this post, and has requested I not release the tool until then. Additionally, Twitter has informed me they are working on a fix as well.
A couple people have asked me to provide a list of sites vulnerable to HTTPS hijacking. Unfortunately as a privacy advocate, I have a habit of shunning most Internet services that accumulate or otherwise link my activity long term and beyond my control. I also hate buying items online because of the data profiling, marketing, identity theft, and privacy issues associated with the inability to use anonymous digital cash, and the requirement for complete tracking of every purchase.
However, a number of people have tested the security properties of their own accounts using the method I outlined at the bottom of this post. What follows are the unofficial, unverified, secondhand results as reported to me. If you are aware of any other sites that seem vulnerable, please contact me and I will add them to the list. Additionally, if you have already been provided a copy of the tool, verification or repudiation of the status of these sites would be much appreciated, as I personally have accounts at almost none of them.