Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Security Encryption

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."
This discussion has been archived. No new comments can be posted.

Heartbleed Used To Bypass 2-Factor Authentication, Hijack User Sessions

Comments Filter:
  • ...researchers independently retrieved the private keys from the intentionally-vulnerable NGINX server...

    Intentionally vulnerable - so this wasn't a bug in the NGINX server, it was a feature, right?

    • by qha ( 23486 )

      "intentionally-vulnerable" in your quote referrs to the intentions of Cloudflare in installing Nginx on top of a vulnerable Openssl installation.

      • 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.
    • by EvilSS ( 557649 ) on Saturday April 19, 2014 @02:30PM (#46795635)

      ...researchers independently retrieved the private keys from the intentionally-vulnerable NGINX server...

      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.

  • Was this before the public disclosure, or after?

  • by Nanoda ( 591299 ) on Saturday April 19, 2014 @01:38PM (#46795359)

    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.

    • Speaking of routers, DD-WRT is vulnerable, but only if you use its VPN-service. It doesn't use OpenSSL for anything else, and if the VPN-service isn't enabled then there's not even that.

      • by hax4bux ( 209237 )

        Thanks for that info. I haven't had time to look.

      • Thank you. This is good to know. I used, https://filippo.io/Heartbleed/ [filippo.io], to test my web facing services. No affiliation. I found it through Google.
      • The key thing to note is that the main vulnerability here is through the use of OpenVPN with an affected SSL library. IIRC OpenVPN is only affected when used in "pre shared key" mode instead of using client certificates (which is the recommended way of running things anyway), so there is further mitigation there (but anyone using OpenVPN needs to check they config and confirm that the server end (if using another party for that) has done so too.

        There are other parts of DD-WRT that could potentially be a
    • by Anonymous Coward

      News: Not just webservers use OpenSSL!


      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.

    • by colfer ( 619105 )

      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.

      • by colfer ( 619105 )

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

  • by Anonymous Coward

    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.

    • SELinux or Apparmor will prevent that, but it is usually not installed on embedded systems.
    • by ledow ( 319597 )

      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

  • by SuperKendall ( 25149 ) on Saturday April 19, 2014 @03:01PM (#46795809)

    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.

  • by duke_cheetah2003 ( 862933 ) on Saturday April 19, 2014 @06:31PM (#46796777) Homepage

    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.

  • 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? Or is this a case of poor security management by not applying the fix??

We declare the names of all variables and functions. Yet the Tao has no type specifier.