A US CERT reminder: The net is an insecure place
World's biggest websites no match for decade-old web bug
If you use Gmail, eBay, MySpace, or any one of dozens of other web-based services, the United States Computer Emergency Readiness Team wants you to know you're vulnerable to a simple attack that could give an attacker complete control over your account.
Five weeks after we reported this sad reality, US CERT on Friday warned that the problem still festers. It said the world's biggest websites have yet to fix the gaping security bug, which can bite even careful users who only log in using the secure sockets layer protocol, which is denoted by an HTTPS in the beginning of browser address window.
US CERT warned that Google, eBay, MySpace, Yahoo, and Microsoft were vulnerable, but that list is nowhere near exhaustive. Just about any banking website, online social network or other electronic forum that transmits certain types of security cookies is also susceptible.
The vulnerability stems from websites' use of authentication cookies, which work much the way an ink-based hand stamp does at your favorite night club. Like the stamp, the cookie acts as assurance to sensitive web servers that the user has already been vetted by security and is authorized to tread beyond the velvet rope.
The thing is just about every website transmits these digital hand stamps in the clear, which leaves them wide open to snoops monitoring public Wi-Fi traffic or some other type of network. Once attackers have the cookie, they gain complete access to the victim's account, and depending on the way many cookies are crafted, those privileges may continue in perpetuity - even if the victim changes the account password.
A Microsoft spokesman said the company is "investigating new public claims of a possible vulnerability involving sending authentication tokens over unencrypted channels." New? Evidently, Microsoft security people attending Black Hat sat out the Errata Security presentation.
And eBay spokesman Hani Durzy said: "This vulnerability is a well known weakness within the HTTP protocol itself. If the user logs out, it will clear the session. Beyond that, the only thing that can be done about it would be to turn the entire site into SSL - which would be prohibitive on several fronts, including usability."
Indeed, awareness of this man-in-the-middle vulnerability is by no means new. For more than a decade people have known that authentication cookies could be manipulated, but somehow it took the folks at Errata Security to make a presentation at Black Hat to remind the world that the risks continue.
It's also true that cloaking an entire site behind SSL would require significantly more processing power and would also slow many users' browsing experience by a considerable measure.
But you'd think the collective brainpower and considerable pursestrings at the world's most elite tech companies would by now have found a way to tackle a problem that leaves attackers free to rifle through their users' most intimate details. It begs the question: is this problem unsolvable or are these guys simply uninterested in figuring it out?
"What David Maynor and Robert Graham are finding is actually very important for the community to pick up and reanalyze," said security researcher Robert Hansen, referring to the two Errata Security researchers who presented at Black Hat. "Even though it's been around forever it's not something we can ignore."
If you're waiting for a fix, we recommend you pack a very large lunch. And beyond that, where possible you might switch to Google, which has already gone a long way to closing the hole.
As the only web-based email service we know of that offers a start-to-finish SSL session, the service is among the most resilient to cookie hijacking. Unfortunately, Gmail doesn't enable persistent SSL by default, and has done little to educate its users about its benefits.
The company also offers SSL for its calendar, search history, documents and reader services, and a Google spokesman said security engineers "are actively working to expand capacity to enable HTTPS encryption for all users."
In the meantime, a Firefox extension called CustomizeGoogle provides a simple way to ensure that all sessions with the above-mentioned Google services are automatically protected by SSL. ®
The real problem with SSL
The real problem with SSL everywhere hasn't been mentioned.
In the U.S., using encryption while committing a crime is a really nasty additional crime.
As I understand it, anything done online that would normally be a misdemeanor, or ignored completely, becomes a big nasty felony if any form of encryption was used in the process.
Why? Because our good old government wants to be able to keep track of all terrorists, suspected terrorists, or anyone involved in terrorist-related activities.
What is a "terrorist-related" activity? Does that include any airplane flight, any suitcase (might contain a bomb), any "weapon" (including knives, which means all kitchens), etc? Does it ever stop?
Obviously, you haven't used mainframes: at least one System/360 developer told me that because of early implementations on the card-stack readers, there was no such thing as an EOF, so programmers used something like DATE=31/12/1999 as a placeholder for EOF. Programming passes on, and though nobody uses punched cards, the code for that management stuck on. Guess when they started getting problems...
Of course, OpenVMS, the VAXen and pretty much all UNIX systems use calendar systems unaffected by the Y2K "bug". But even then, sloppy programming did some hilarious stuff like making software show dates like 1/1/100 and such.
So finally, yes some stuff didn't break w/o patches, some did, most stuff got patched anyway. Just don't assume Y2K was all hype, some critical systems did have this problem.
Oh, and cookies are something that do need to be fixed, but that would have to be either going into full SSL on everything using sessions, or cooking up a new protocol, a stateful one unlike HTTP. ;)
Whenever somebody logs in (which is presumably over SSL), or out, you generate them a new session ID and invalidate the old one. Anybody who sniffed the cookie previously doesn't get access to the elevated credentials.