Slashdot Mirror
Heartbleed Used To Bypass 2-Factor Authentication, Hijack User Sessions
wiredmikey (1824622) writes "Security nightmares sparked by the Heartbleed OpenSSL vulnerability continue. According to Mandiant, now a unit of FireEye, an attacker was able to leverage the Heartbleed vulnerability against the VPN appliance of a customer and hijack multiple active user sessions. The attack bypassed both the organization's multifactor authentication and the VPN client software used to validate that systems connecting to the VPN were owned by the organization and running specific security software.
"Specifically, the attacker repeatedly sent malformed heartbeat requests to the HTTPS web server running on the VPN device, which was compiled with a vulnerable version of OpenSSL, to obtain active session tokens for currently authenticated users," Mandiant's Christopher Glyer explained. "With an active session token, the attacker successfully hijacked multiple active user sessions and convinced the VPN concentrator that he/she was legitimately authenticated."
After connecting to the VPN, the attacker attempted to move laterally and escalate his/her privileges within the victim organization, Mandiant said."
"Specifically, the attacker repeatedly sent malformed heartbeat requests to the HTTPS web server running on the VPN device, which was compiled with a vulnerable version of OpenSSL, to obtain active session tokens for currently authenticated users," Mandiant's Christopher Glyer explained. "With an active session token, the attacker successfully hijacked multiple active user sessions and convinced the VPN concentrator that he/she was legitimately authenticated."
After connecting to the VPN, the attacker attempted to move laterally and escalate his/her privileges within the victim organization, Mandiant said."
We all love a bit of conspiracy but it was not intentionally malicious. Simple mistake by some professor.
This doesn't negate the fact that this was their favorite vulnerability. Realistically most intelligence services probably new about this shortly after that commit.
This doesn't negate the fact that this was their favorite vulnerability. Realistically most intelligence services probably new about this shortly after that commit.
How so was it their "favorite vulnerability"? Is there even a shread of evidence linking them with it? Exploits exist in code - we found a big bad one - great. Many white hats will have looked at the code and not noticed the flaw. That doesn't mean the NSA were using it. I'm not for a moment saying the NSA wouldn't use a similar exploit but there's nothing special about Heartbleed.
Intentionally vulnerable - so this wasn't a bug in the NGINX server, it was a feature, right?
Was this before the public disclosure, or after?
I don't thing NSA knew about it. Somebody would have caught the unusual requests.
News: Not just webservers use OpenSSL!
No kidding. My Synology NAS had a same-day update to patch this - my custom router firmware needed updating too. If there's a story for every device someone forgot might contain OpenSSL code, it's going to be a busy month.
It seems completely obvious to me that each authenticated session to any remote server should be running as a separate user. There is something so fundamentally wrong about any security model where it is possible for the code executing for one user to access data private to another user.
So they were merely confirming how bad bad could get by proving that technology that relies on OpenSSL is vulnerable. Okay, thanks. I suppose there are a lot of people who might try denying that - I've already heard people muttering that the firms which are vulnerable to this exploit should have a workaround in place. This demonstration could well serve as an example of just how difficult that could be, as well as how wide-reaching the problem is.
That guy RS is not a professor, but has a PhD in applied informatics.
We here in Germany no longer believe it was unintentional though, because the particular department where he works at T-Systems (the IT daughter of Deutsche Telekom), also did the remote maintenance for DLR, the German Aerospace Center, that coincidentally reported it's been hacked.
I'm not convinced this wasn't an intentional effort to backdoor OpenSSL.
Code was submitted on new year's eve. A moment when the fewest people would be available to review it. Many people are on vacation and likely to gloss over the pile of code submitted while they were gone.
Just because he's a professor doesn't mean he wasn't compromised. A common page out of spycraft textbook would be to get an agent to seduce the professor and then document his infidelity. With this hanging over his head, he'll plant the requested vulnerability and even after it's discovered, he'll stick to the cover story to prevent those photos from being sent to his wife. For further reading on this topic, see the wikipedia page on Julian Assange.
$5 / month hosted VPS on linux = awesome!
I don't think so. This is a high value vulnerability, you keep it in the back pocket. Especially since it has demonstrated key extrication and affects a large number of hardware and software platforms.
Didn't the problem come about by OpenSSL doing it's own memory handling because some people's OS had slow memory management? Sounds like an excuse to have mistakes that bypass other kinds of checks.
On Windows, there are probably three billion apps each with their own copy of openssl.dll, many of which will never be updated. I remember when some serious zlib bug was announced years ago, I found about 30 copies of zlib.dll on my Windows machine, all of which had to be independently replaced with a patched version.
Lots of people scoffed at Bruce Schneier for saying Heartbleed is an 11 on the 1-10 scale... I agree that sometimes he goes overboard but this is not one of those times, and the attack mentioned in the article demonstrates this.
The summary is a little muddled on what happened here, but if you follow the link you'll find this is not a security test or a research group showing something could theoretically be done. This is a real live company somewhere just using a VPN many other companies probably use, that had over the course of many hours multiple VPN session hijacked and made use of. That is a huge deal, if one person can do this you can almost bet there is a script somewhere that even the great unwashed hacker masses can make use of.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
And even if they were, it does not mean it was their favorite. Perhaps there is something out there that they like even more. Talking about code, not 'social engeneering'.
Don't fight for your country, if your country does not fight for you.
Somebody would have caught the unusual requests.
Not if they were careful about it. Someone with access to credit cards details in mind would get it discovered pretty quickly as they would be poking everywhere as quickly as they could in order to try get information so they could get as much out of the flaw as quickly as they could. This is more likely to be seen as there would be unusual amounts of traffic. But a security agency trying to find a VPN's private key? Where the VPN isn't employing FPS techniques the time you have to perform the attack it pretty long so they could easily have managed some useful penetration with much more subtle traffic, that would just look like background noise. OK so they wouldn't get something nearly as quickly that way, but a good security service plays the long game instead of looking for quick wins. Heck, even a burst of traffic would be written off by many as a random DoS attempt or some fool with a misconfigured client, so someone could have used this maliciously in bulk a few times without raising significant suspicions that would lead people to dig in and find the flaw they were trying to exploit..
This doesn't mean that the NSA did, or that they even knew about the flaw, but it means if they did know about it they certainly could have (and most probably would have) made good use of it without anyone suspecting.
While it won't happen in the vast majority of cases, so you could implement a client address lock as an option, there are a number of valid reasons why a session might jump from one address to another.
I always thought Windows OS was their favorite vulnerability?
Just as a side note, for any corporate intranet with VPN and web servers facing the outside world, it really is a good idea to isolate your various services, so if one is compromised, the others aren't. This is a classic example of why you should do that: If the web server and VPN were on separate VM's, heartbleed fishing through the web server wouldn't have exposed the VPNs keys.
I wish I could afford to practice that myself, I unfortunately lump all my internet facing services on one VM, but for a corporation with more assets, it really is a cheap way to cover your butt.
Please be specific. Try to express yourself with more than a thinly veiled one-line ad hominem statement. Written exposition demonstrating linguistic and reasoning skills appropriate to an adult would also be desirable.
Re Somebody would have caught the unusual requests.
If a gov wants to sit between you and your site, the logs of your site would reflect whatever the gov wants.
They have man in the middle, fake sites and efforts like TURBINE would show very little skilled, attentive admins.
http://www.dailytech.com/Tax+a...
Domestic spying is now "Benign Information Gathering"
Your application server shouldn't be running SSL.
I can't think of one good reason to expose your application server to the internet.
new? shread?
Has the bug been fixed or not? Or is this a case of poor security management by not applying the fix??
Jack of all trades,master of none
Lots of people keep server logs around for a long time. Now that the requests that cough up private keys have been identified I would think that hack attempts would have been identified by now, just like the ones that are the subject of this story.
They haven't been.