A US CERT reminder: The net is an insecure place

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 …

[Chris]

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?

[CIM]

Already possible

Cookies have a "secure" option that means those cookies will only be sent over SSL. It's perfectly possible already.

(Is The Register going to switch to SSL for these comment logins, I wonder?)

[Mark Randall]

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

It's called a Subpoena isn't it?

[Raheim Sherbedgia]

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

[Anonymous Coward]

NOT new to the past 5 weeks.

This attack has been known and executed for longer than 5 weeks. It's been known for about 5 years now actually, and has been performed, the whole time...

It's only "new" because someone did a presentation at a security conference on it.

[Dan Goodin]

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?

[John Atkins]

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.

.

[Steve]

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

Check your facts.

[Bruce]

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!

[Bob Bramwell]

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.

[Alan Donaly]

OK

This story is either for a different crowd or it's supposed to be

funny it is sort of but not that funny yes we knew the web was

insecure what else?

[Raheim Sherbedgia]

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.

[Dillon Pyron]

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.

[Chris]

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.

[Anonymous Coward]

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!

[Matthew]

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.

[John PM Chappell]

Raheim?

Did you also know that 99% of statistics are made up on the spot? ;¬)

Or, to put it another way, got any evidence, even a source you can quote, for that nonsense about 'Urban Myths' and English speakers? If it's Wikipaedia, don't bother.

[Nick Pettefar]

Google, Y2K and all that...

Well, I did read the article and it starts off by stating that Google is vulnerable and then finishes off by saying that it is fairly secure. Did two people write the article?

I set the date of a SunOS workstation in 1999 to 2000 and it crashed. The company's accounting system would not take a non-19xx date.

[Anonymous Coward]

Simplicity.......

just proves It doesn't matter how advanced something is......

A hammer is still the most effective way to stop an Ipod!!

(forgive the terrible analogy)

[Anonymous Coward]

Mozilla site 100% SSL

Firefox/Thunderbird/Mozilla's web site can be used 100% SSL.

https://www.mozilla.com/en-US/

I do not understand what the huge problem is running a site 100% SSL ?

[Dan Goodin]

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.

[Matt]

RE: Mozilla site 100% SSL

100% SSL has two basic problems;

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

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

These problems lead to the basic usage of SSL for login, then move to raw data afterwards.

[Chris]

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.

[Chris Stephens]

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.

Come on IT professionals, protect the clients and users.

[Anonymous Coward]

Y2K

I worked with a company that spent a year getting y2k right-- and dropped the ball on all other important issues, leading to unpaid invoices worth millions.

[Anonymous Coward]

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.

[tom currie]

100% SSL

I am a sysadmin for an online retail catalog co. we tried running one of our catalogs on 100% SSL and we just couldn't sustain it.

customers reported poor performance, we had to stop using akamai (we have > 100,000 images), performance was visibly worse from every measurement.

We tried for about a month to get it worked out, but in the end we gave up. customers with old hardware could hardly use the site at all and got frustrated.

forget about flash downloads and background music and sound samples, it was just too slow.

maybe someday we will do another test, but for now we just accept it and try to do the right things on other fronts.

tc

[Mo]

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.

[Daniel Ballado-Torres]

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

[keybounce]

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?