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 …

COMMENTS

Simple fix, but requires changes on both sides

The "fix" is surprisingly simple: treat cookies for non-SSL sessions completely separate from cookies for SSL sessions. Put another way, treat SSL and non-SSL as different domains. If a user logs into https://www.example.com and cookie "mypassword" is set, then that cookie should only be for the SSL site. If the user then switches over to http://www.example.com (non-SSL), don't send that cookie.

Mind you, this is a problem for both sides -- the browsers and the website maintainers. The browsers need to be changed to use this method. Website maintainers need to make sure that they're using SSL when sending private data (such as these authentication tokens). Sadly, it seems a lot of website maintainers aren't so smart. All too often, sites use SSL only for the login form, then switch you over to non-SSL after login. My local power company has you log in in-the-clear BEFORE switching over to SSL. What good is it to use SSL after you've forced the user to send their name and password in clear-text?

Subpeona?

"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."

Significant risk of something possibly happening someday (maybe)

While I recognize the need for reasonable security too many security articles sound just like the big Western Governments of today. We are exposed, and at risk by "problemX", quickly, do something before someone exploits the "opening".

Pansies. I expect this entire event will be looked as a complete fiasco is the near future, much like "Y2K".

People will say hey, do you remember that time we spent two months fixing the "poison cookie" problem. Yeah, what a waste of time. Oh well, at least we got a big consulting fee for helping my client "serve safe cookies".

Re: NOT new to the past 5 weeks

The Reg hereby institutes a new requirement for all commentators: They must actually read the article before making remarks.

This article makes it perfectly clear that this vulnerability is as old as the hills. Here are a few sentences that prove that: "World's biggest websites no match for decade-old web bug."

"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."

The point is the smartest minds in the world seem no closer to a fix now than we were 10 years ago. What the hell is up with that?

Raheim: Significant risk...maybe

Off topic: Don't spread an urban legend.

Y2K was not a fiasco - because major corporations (I am familiar with US telcos) spent the time and effort to analyze and correect some VERY large legacy programs. Thus - no failures. That is a success story. What would have been said if no one had done these corrections and a major network had failed for a long period.

On a small scale, I used a server side database program that had a y2k problem that went undetected (by us) until Feb 2000. Fortunately, this was an annoyance, not a crisis. The vendor had a fix that we purchased for $300. If the vendor had not already had this fix, it might have turned into an embarrassment.

@ Raheim Sherbedgia

I'm not sure where the fuck you had your buried in 1999/2000 but a modicum of research would reveal that, in fact, critical systems did not fail (to badly), satellites did not fail to earth (although quite a few went off-line for bit of a nap), and (most) nuclear power stations did not go tits up, simply because sufficient preparatory and remedial work had been undertaken.

Without this, and the many people standing by in safety critical installations on the eve of the millennium with their fingers on the off switches, things would have been very different indeed.

In fact, as you will see if you bother to do a reality check, there were rather a lot of nasty incidents, involving comms satellites and indeed nuclear power stations and the like, that simply went under- or unreported in many places.

Without the legions of code monkeys (of which I was one) and engineers who worked so hard in the run up and then stayed awake minding the equipment, lots of things would have broken. Sure it wouldn't have been the nuclear armageddon we were promised by the more hysterical media, but it would have been very unpleasant.

Re: NOT new to the past 5 weeks

hehe love the way the person that posted this comment did not read the article at all, briliant!!

And yeah as other people have said it can be fixed and as long as secure cookies are kept seperate and only sent over secure connection and there is no using half a ssl and half not during login then it can be fixed!

Workaround?

Is an authentication cookie valid only for a session? And is the session terminated when I explicitly "log out" from the site concerned? If so, presumably one can limit the damage radius by avoiding the "remember me" options (which are likely to involve more persistent cookies) and being sure to terminate one's session explicitly. Please correct me if I am wrong: this would be useful to know.

OK

How sure are you, John and Steve?

Yes, but John, have you really considered the contribution of urban legends to Western Society? 98%of English speaking people believe in one urban legend or another. Think of how that effects your social life... I'm doing a good deed here you know. :)

Outside of that:

Y2K was/is a great example of "making a mountain out of a mole-hill". Sure, *some* really old satellites didn't plummet to Earth, and U.S. nukes didn't destroy the world but it's sort of like modern pharma. Look! You did what we recommended and you didn't die! Our recommendations saved you! Yea for us!!!

FYI in 2010 a large scale study is going to be published that proves Y2K was crap. Too much fear and not enough knowledge. A rather large group has been running a variety of systems with no Y2K patches since '99 and so far nothing, absolutely nothing, has happened that is related to clock times. From profitable e-commerce to HTTPS there have been no ramifications due to not being "Y2K compliant". Money says you've probably purchased something from one of the study participants.

A lot of people made a big deal out of nothing and based on recent comments, they still feel like they contributed. Sorry to be the one that told you, but Y2K was crap, just like 85% of the "security" issues we read about today. Sure there is a "possibility" of "something" "happening" but it's so remote it isn't worth spending money on.

As I said earlier, IT "security" is starting to sound like the "security" of the Western world. Fear and panic are driving too many decisions in today's world.

Horsepower???

"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."

You mean a 3 GHz dual core machine isn't big enough to do that? Has software gotten so bloated it will chew up a machine that wasn't around two years ago?

And yes, Raheim, security is way over hyped. Turn off your firewall and I'll show you. Or, post your email address and I'll email you yesterday's Snort logs. You'll see that there is absolutely nothing to be afraid of. And I'll use your machine to make sure the world knows about my amazing penis patch, all while using your credit card to buy my new iPhone.

Y2K was not a fiasco, perhaps if you had actually had a job in the IT industry at the time you'd know better.

Reality check

Raheim, are you just trolling or do actually believe what you are saying? If you do believe what you are saying, then you are clear NOT in the IT industry. As pointed out, the reason "Y2K" didn't cause a lot of problems is because of millions of man-hours of work put into it starting years ahead of the deadline. I can also claim that I never had any Y2K-related problems. But then again, I don't do anything (important) which uses a date field. It's easy to speak facts or find "conclusions" when you know what you want to say/prove to start with. It's another matter entirely to make an unbiased, impartial review. And the facts are stacked up against you on this one.

One quick question: how reliable is that "study" you speak of? You know, since most software had already been updated for the Y2K issue before 1999. That would seem to make your "study" moot since it would have started with software which had already been updated. And since you're obviously uninformed, the Y2K issue was a DATE-related issue, not a TIME-related issue. So nothing would have happened that "is related to clock times". It would have been issues relating to the date.

As for security being overrated, try that out at the next Black Hat conference. Better yet, reinstall the copy of Windows you're most likely running, don't use a firewall, don't use antivirus, and don't install the security patches, since all of that is overrated. Oh, and don't be surprised when you get owned in less than 3 minutes.

Security is overrated. That's a good one. I guess that's why software is always being patched to protect against ACTIVE zero-day exploits. And I guess that's why Storm, Sobig, Melissa, I-Love-You, and CodeRed spread as quickly as they did. And ignore the reports about zombies and botnets. That's obviously just propaganda put out by the U.S. government to try to fool smart people like you into silly things like security patches and antivirus.

Simple fix, but requires changes on both sides

Spot on Chris:

I really pisses me off how many moronic web designers mix http and https pages for secure logins and private sessions; cross-sight scripting exploits as common now, so people who do this should be regarded as negligent.

Confidential information must only be held in uncached https pages or in server-side https session data, cookies must never be used to hold passwords or confidential details, even session cookies maybe vulnerable. I would regard anyone who does otherwise as negligent.

If a company machine has network access to intranet sites containing confidential data and has internet access, then all affected intranet sites must also be secured too, network sniffing is so easy!

85% of all issues are fluff

If you can tell with any reliability which 85 bugs out of 100 are the crap ones, then you'll make a mint.

Same goes for the y2k stuff. 99.9% of the bugs were crap, and a waste of time time to fix, the problem is that that 0.1% that were really, really important are hard to pick out from all the rest :-).

I fixed hundreds of bugs over that period, of all of them, I know that only two would have actually caused anything other than cosmetic issues. One would have lead to aircraft not being tracked by a particular of radar system. The other would have caused a major car company to lose months of compliance and testing data. I would not like to have been flying on Jan 1 with that bug production code, but I had to find all the bugs to find that one.

I believe that the Nigerian government didn't pay for any Y2K work and they were only without water for 2 months and air traffic control, or that might be another urban myth.

Same goes for security bugs, I remember the internet going tits up for about a week because of a bug in MSSQL 2000, I wonder how much that cost.

Mozilla site 100% SSL

Re: Google, Y2K and all that...

Nick,

By default, Google is insecure. The only way someone can be "fairly secure" is by to embark on what is a pretty steep learning curve for the average computer user. Those Google users who don't are as insecure as users of MySpace, Yahoo and the rest of them.

re: Mozilla site 100% SSL

The Mozilla site is NOT 100% SSL. The parts you SEE may be 100% SSL, but go to the site using the https link provided and then download Firefox or Thunderbird. You'll see that the download is using plain http (non-SSL), not https. The download launching page is https, but the actual download is only http.

RE: Mozilla site 100% SSL

I personally think all web sites should just adopt SSL as how they work default for as much of the site as possible and practical,,, unlike now where its used for the smallest amount of time possible.

Lets not even discuss email being so non-secure while there are complete solutions already in place in all the client and server products currently in use.

The use of encryption and real authentication is WAY OVERDUE.

The tools for complete end to end encryption are available now. From a completely encrypted hard disc to SSL browsing & SSL email transmission. These require almost zero client awareness. Server to server SSL is available in Sendmail and Microsoft products.

If bandwidth is such a huge issue then use a low grade. Its still better then none at all. Change to a high grade on critical items.

Y2K

SSL and caching

> 100% SSL has two basic problems;

> 1 - Increased bandwidth (encrypted data can be upto 4 times larger)

There is a header overhead, which is significant for small payloads. But for larger payloads it's not significant. As far as I am aware the encryption of the actual "application data" is byte-for-byte.

> 2 - No caching (especially a problem for image intensive sites)

No, it is possible for the browser to cache SSL data (I've just tested it). But if the data is sensitive, or dynamically generated, the server will probably send a "no-cache" header.

The point that you didn't mention -

3 - processor effort is needed

could be an issue for some applications, but many systems now include some sort of hardware acceleration that can help.

Simple fix

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.

Y2K

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. ;)