Heartbleed Defense-in-Depth Part #1: Preventing Admin Session Hijacking
This post is the first of a blog mini-series (is that even a term?) around the Heartbleed vulnerability and some of defense-in-depth techniques we've had in place for years that helped mitigate its impact. Stay tuned for additional posts throughout the week!
No one can predict the variety or impact of Internet-ending cyber-pompeii vulnerabilities. Whether it's the Kaminsky DNS poisoning, Mark Dowd owning your Sendmail MTAs, or fun Apache remotes, the Internet is guaranteed to come to a screeching halt every couple years. You will know when this happens, since your relatives will post on your Facebook wall to ask you if it's safe to shop online or send family pictures from their AOL account and will, for the first time, take an interest in what you do in your security profession.
But still, if we had done a "Security Family Feud" about the next big vulnerability, survey says zero people would have expected an Internet-scale infoleak compromising confidential data, passwords, private key material, session identifiers, and address space information (why is no one talking about those nginx remotes that suddenly became 100% reliable?) of all OpenSSL-based SSL/TLS services.
So everyone scrambles reactively to patch their servers, rotate passwords and keys, post buggy patches to mailing lists, and blast notifications to their users to promote themselves as a vendor that really cares about security. Because hitting that send button in your marketing automation platform faster than everyone else is the one true metric of security.
At Duo, we like to boast that we've designed our two-factor service with security in mind from day one. But we're often boasting to ourselves (or to my cats) and don't broadly externalize those design decisions or our philosophies around defense-in-depth. However, while the Heartbleed vulnerability is generally a "Bad Thing" for the Internet as a whole (hey, a lot more TLS 1.2 will be in use now, eh?), it has provided good motivation for me to fire up
vim and externalize some of our defensive mechanisms that helped mitigate the impact of Heartbleed for Duo customers.
##Session Hijacking with Heartbleed
While the initial concern about Heartbleed focused around the exposure of confidential data and private key material, security researchers quickly realized a more insidious attack: remote session hijacking. That is, an attacker can steal the session key or identifier associated with another user's already-authenticated session and impersonate that user remotely. This is possible since those little cookies that your browser sends along with every authenticated web request sit peacefully in your web server's memory waiting for a friendly Heartbleed'er to come whisk them away.
If a remote attacker leveraging Heartbleed can leak the memory of your web server and capture an active session key, he can then stuff that key into his browser, hijack the session, and impersonate the authenticated user as if he had logged in to your web application as that user directly.
In order to demonstrate what session hijacking looks like with Heartbleed, I found the worst possible graphical representation on Google Images:
##Preventing Admin Session Hijacking
At Duo, we have an admin interface that our customers access to manage their accounts. Obviously, this is a security-sensitive web application, protected by 2FA, TLS 1.2 w/PFS, CSP, HSTS, CSRF/XSS mitigations, and many other smart-looking acronyms. But, if an attacker had knowledge of the Heartbleed vulnerability before it was publicized and patched in our service, couldn't they have performed a session hijacking attack and impersonated an authenticated administrator?
Obviously that answer is no, otherwise this would be a weird blog post to write. How do we mitigate session hijacking? We simply bind the client's IP address to the authenticated session. So, when you log in, your session will be tied to that initial IP address. If you happen to change IP addresses for some legitimate reason, you will be forced to re-authenticate. If an attacker steals your session key via the Heartbleed attack and they attempt to re-use that session, they will be rejected since their request will be coming from an IP that doesn't match the one originally bound to the session.
Is this a super l33t technique? Definitely not. After all, if it's listed on Wikipedia on the Session Hijacking page, it's probably not rocket science. But it is a sensible defense-in-depth measure that many security-sensitive services do not implement. So, keep your vendors honest and make sure they implement best practices, ya know?
This is a design decision not without downsides. Duo is an enterprise software service and often times enterprises have interesting network configurations. In particular, we sometimes see external NAT'ing or even from multiple upstream providers which appears to our service as multiple IPs, causing an admin's session to be rejected if it's seen from an invalid IP address. But, from our perspective, the security gain from binding admin sessions to a specific IP address outweighs the usability concerns.
We hope you feel the same, and can sleep a little better knowing your authenticated sessions are hardened against hijacking by Heartbleed and whatever the next Internet-ending vulnerability is around the corner. After all, the goal of defense-in-depth is not to respond reactively to newly-discovered vulnerabilities, but to be proactive in security architecture and design to mitigate future ones. :-)
Keep an eye out for more of our Heartbleed defense-in-depth series for the rest of the week!