Heartbleed Used To Bypass 2-Factor Authentication, Hijack User Sessions 59
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."
Re: (Score:2)
Re: (Score:1)
This doesn't negate the fact that this was their favorite vulnerability. Realistically most intelligence services probably new about this shortly after that commit.
Re:NSA is so annoyed right now (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:1)
new? shread?
Re: (Score:2)
I don't thing NSA knew about it. Somebody would have caught the unusual requests.
Re: (Score:3, Insightful)
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.
Re: (Score:3)
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 pre
Re: (Score:2)
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.
Re: (Score:2)
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... [dailytech.com]
Re: (Score:2)
I always thought Windows OS was their favorite vulnerability?
Re: (Score:3, Interesting)
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.
Re: (Score:2, Interesting)
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 [washingtonpost.com] it's been hacked.
not enough evidence against conspiracy theory (Score:4, Interesting)
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.
Re: (Score:2, Interesting)
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.
Is it just me, or is this just insane? (Score:2)
Intentionally vulnerable - so this wasn't a bug in the NGINX server, it was a feature, right?
Re: (Score:1)
"intentionally-vulnerable" in your quote referrs to the intentions of Cloudflare in installing Nginx on top of a vulnerable Openssl installation.
I missed that. (Score:2)
Why not? (Score:2)
Re:Is it just me, or is this just insane? (Score:4, Informative)
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.
Okay, but WHEN (Score:2)
Was this before the public disclosure, or after?
Re: (Score:2)
No. The linked article doesn't say. I did click on a link to the company's blog from the linked article and found it. Such critical information should have been both in the page that /. linked to and in the /. summary!
tl;dr: This took place AFTER the public disclosure, but not by much: it seems it was April 8th.
News: Not just webservers use OpenSSL! (Score:5, Insightful)
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.
Comment removed (Score:4, Informative)
Re: (Score:2)
Thanks for that info. I haven't had time to look.
Re: (Score:3)
Re: (Score:3)
There are other parts of DD-WRT that could potentially be a
Re: (Score:1)
News: Not just webservers use OpenSSL!
Yup.
Although, this article is about a device that uses https on port 443 to set up a vpn, so I would still call it a webserver.
Common non-webservers would be SMTP servers that use OpenSSL for STARTTLS, along with POP and IMAP servers.
Re: (Score:2)
Yes, LiteSpeed web server, a common drop-in replacement for Apache, had the bug even when the shell of a LAMP stack did not. LS patched it.
If this bug had been in 0.9.8 the web would be in a real disaster now. Many web ISP's stay behind a few versions on the stack. I've got one that runs the oldest PHP version still in release. That's a bit extreme. So the bug hit more big companies.
Re: (Score:2)
In other words, you could not detect the bug by looking at "openssl version" at the shell prompt, or looking for the openssl version in phpinfo().
Modern security model horribly broken. (Score:1)
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.
Re: (Score:2)
Re: (Score:1)
It doesn't matter how clever you are... at some point, some session will have to run with more privileges than the user in order to be able to do something.
Or, as here, the session gets taken over as "just a user" and steals all their data / credentials anyway and tries to move deeper by finding more.
The problem of privilege separation can be fixed today, the tools are there. The problems described here aren't helped or hindered by privilege separation.
To be honest, what you have to have is an enormously f
Schneier's 11 was well-justified (Score:5, Interesting)
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.
Re: (Score:2)
Mitigation (Score:3)
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.
Lesson 1 (Score:2)
Your application server shouldn't be running SSL.
I can't think of one good reason to expose your application server to the internet.
Has the bug been fixed or not (Score:1)