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."
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.
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.
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.
Intentionally vulnerable - so this wasn't a bug in the NGINX server, it was a feature, right?
They put up a publicly accessible NGINX server with the vulnerable version of OpenSSL to see if anyone could get the private keys from it (they thought that this was not possible from their internal testing). It only took a few hours before they were proven wrong. At the time they had already patched the rest of their systems to address the Heartbleed vulnerability.
I browse on +1 so AC's need not respond, I won't see it.
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
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.
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.