7 ms·
Hijacking user sessions with the Heartbleed vulnerability
- pearjuice 13y agoThis is one of these things of which you think "Ah, what are the odds of me being affected?" but quickly changing to "This is pretty bad..." and finally to "FUCK FUCK FUCK, WHY?". Two years is a long time, people. If ordinary people can write proof of concepts in less than 24 hours after it is publicly disclosed, what to think of those getting paid to find and abuse such bugs? I mean, what are the odds this bug was not abused in production environments the past two years?
- M4v3R 13y agoIt might be a coincidence, but last month I received an alert that someone tried to sign in to my hosting control panel using a correct password (which was long and random), but was blocked by a geo-filter (which blocks requests outside of my country) fortunately. I do not know up to this day how my password did leak, and that's one possible candidate cause.
- smonte 13y agoI had similar issue with my email account. The password is only used for that specific service and I got a notification yesterday that someone had tried to access the account with correct password. Coincidence, could be. But probably not.
- danielweber 13y agoSomeone broke into my yahoo account a month or two ago to send spam. I changed passwords quickly enough. It was low-priority, but looking at the passwords that people have captured from yahoo's servers, I used a very very common password theme. Also, a lot of Yahoo users were born between 1970 and 1975.
- orblivion 13y agoReally I can only assume that there are plenty of other bugs out there. It's just a matter of how few people know about any of them. I dunno, keep your secrets close. PGP. Meh.
- mykhal 13y agoon some servers you can even get the credentials themselves :)
- blantonl 13y agoWow, just piping the output from this proof of concept python script through grep and searching for the string "pass" shows that on a number of sites that are vulnerable it is that easy to pull a logged in user's username and password. Scary...
- gatehouse 13y agoYeah, up until very recently it would be possible to make a script that would log you into a random yahoo mail account. For vulnerable servers right now it would be better to just block port 443, forcing regular HTTP is safer.
- danielweber 13y agoAlthough there are no guarantees there, what you are likely getting is people logging in very recently because their POST request is still in memory. If you were just logged in with an old session from a few hours ago, it's unlikely your PUSH request will still be in memory. But every time you connect you are sending a cookie which allows for session hijacking.
- Bootvis 13y agoFor SSH it's common to use private keys to communicate securely with servers using public key cryptography. This is convenient and protects against key loggers. What are the possibilities of using public key cryptography in the browser? For example, I upload my public key to some website, create an account which is locked to my private key. I get the convenience of not having to log in manually and some extra safety.
- mikeash 13y agoI believe what you're describing is encompassed by SSL client certificates. They're supported, but roughly nobody uses them for some reason.
- Bootvis 13y agoWhat a shame, maybe now something will change. I won't miss typing in passwords at all.
- tjohns 13y agoStartCom is the only site I know of that uses them for user authentication. The biggest problem is that the client-side UI is rather confusing, and you still need a separate authentication system in case the user loses their certificate (or switches devices).
- mikeash 13y agoYou're right, I actually have an account with them and remember setting up the client-side certificate. I completely forgot about it afterwards. I would say that "rather confusing" is a deep understatement. The process, at least on the Mac, is atrocious and makes this method only suitable for the most advanced users, and even then only if you're willing to take on only the most enthusiastic.
- dfc 13y agoIt is possible and has been for some time. Like many other PKI systems it is a pain in the ass to configure on the server (atleast it was with apache) and teaching/getting users to generate keys is a nightmare.
- fnsa 13y agoThis is scary: # ./hb-test.py mail.yahoo.com |grep -A3 -B3 pass
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]
- bri3d 13y agoWhat's potentially scarier than plaintext passwords leaking out is that key material leaks as well. 64k of random memory is bad, 64k of OpenSSL's state is worse. Also, why haven't Yahoo taken down their login service yet? I really don't see how leaving your users' passwords leaking in plaintext is ever better than downtime. Someone had to have made that call, and I really don't think it was the right one. Will be interesting to see how the media treats this over the next few days. EDIT: Looks like Yahoo is finally fixed. Wonder how many accounts were compromised in the interim, and if their cert and private key were compromised as well. Does not look like they've re-issued yet.
- thisisdave 13y agoThis isn't my area, but why would Yahoo even have plaintext passwords in the first place? Shouldn't they only have hashes?
- nemothekid 13y agoThe data being read is the plaintext password being sent from the client. The standard login procedure goes like this: 1.) Client sends Plain text user/pass over SSL -> 2.) Server reads that info to memory -> 3.) Server hashes password and tests hash -> 4.) Server discards plaintext memory. Whats happening here with heartbleed, is you are reading the RAM of the server, so before Yahoo even has the chance to hash the password, this exploit allows you to read the password. Remember, even though Yahoo may only store the hashes in the database, your password (for any service) is still being sent effectively as cleartext.
- rbobby 13y agoDollars to donuts the NSA has had this hack in its bag of tricks.
- higherpurpose 13y agoMaybe it will be easier to look through the Snowden documents for this, now that we know about it, and see if they had it.
- danielweber 13y agoBut using it would reveal it if anyone was capturing traffic of SSL requests. "Why in the world did they do a heartbeat test . . . hey, what's all that stuff . . . OHMIGOD."
- mey 13y agoIt's unlikely that anyone would be logging that these network requests would be made, let alone the raw input/output. This level of network logging is typically only turned on briefly for diagnostics.
- danielweber 13y agoMaybe, maybe not. If you are paranoid enough to have this attack in your toolbelt, how paranoid are you that your victim will be watching his traffic and/or request logs? If you have that kind of inside knowledge about your target you probably wouldn't need a tool like this. For fun and for research purposes, in the past I've set up SSL dumps that just log all the TLS commands and sort them by frequency. The ones at the top and at the bottom of the list were the most interesting.
- MetaCosm 13y agoExploit hording is counter-productive. Exploits only have value when used, they have no defensive or other value. Their half-life is not in your control, at any time they can stop being usable. Therefore the best course of action when you get an exploit is to use it whenever you can until it gets fixed.
- labguy10001 13y agoIt's not a vulnerability. It's a BACKDOOR.
- choult 13y agoI don't believe there's any evidence on that yet, so please cool your jets. One dev wrote that line of code but anyone could have made that mistake.
- quasque 13y agoIs the vulnerability, or this script to exploit it, platform-specific? I tried this script against a Raspberry Pi running Raspbian with an unpatched OpenSSL library, but received an unexpected EOF.
- danielweber 13y agoIf your webserver has the vulnerable version of the OpenSSL library, then your server will return some extra bytes, from someplace in memory. It may turn out that the space in memory it's returning from is useless. Or, like yahoo, you may be giving out plain-text ASCII passwords to complete strangers who can type a command line. Which of these two extremes you get is largely based on luck.
- quasque 13y agoThanks for the information. I modified the script to request a different number of bytes. It seems that 16384 is too much and causes the server to abort sending, but lower amounts work to successfully dump memory. EDIT: The other thing is that it seems better to check for "Server Hello Done" at the end of the handshake message as some servers seem to send all submessages within one handshake message (though not sure if they're OpenSSL-based), i.e. look for ord(pay[-4]) == 0x0E rather than at ord(pay[0]).
- smtddr 13y agoFor those that don't python and/or don't know where to edit. hb = h2bin(''' 18 03 02 00 03 01 40 00 ''') See that "40 00" there? That's hex and 0x4000 = 16384. Change it to something like "02 00", so it's 0x200 = 512, or 0x400 = 1024 ...or whatever you want.(But keep it at a power of 2... I assume). http://en.wikipedia.org/wiki/Power_of_two http://en.wikipedia.org/wiki/Power_of_two
- axisK 13y agoAs long as it's valid hex it should be fine, there seems to be a lower bound at which point servers don't respond but I didn't play around for too long with that part. Most articles also mention 64kb which the script can do with some small modifications.
- danielweber 13y agoWhat tool is he using for editing his cookies?
- kaeruct 13y agoEditThisCookie extension: https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg?hl=en https://chrome.google.com/webstore/detail/editthiscookie/fng...
- joshfraser 13y agopython heartbleed.py okcupid.com |grep -C3 username=
- willvarfar 13y agoA malicious server can also read the memory of a client using the same heartbleed vulnerability. So the -NSA-mafia can go get the private key from a vulnerable server, MitM its clients, and attack those clients too. Nasty stuff. And in the last day, even those agencies that didn't know about the vulnerability beforehand have likely spidered the entire web scraping everyone's keys just-in-case.
- justincormack 13y agoAnyone seen any evidence of attempts to do this, or set up honeypots?
- kevjiang 13y agoIn fact, an attacker doesn't even need to steal the private key.. Heartbeats can be sent before certificate authentication takes place.
- sinak 13y agoRecovery process for this seems like it would be: - All affected sites need need to update OpenSSL, reissue certs, tell users to update their passwords. - All users need to reset their passwords, using a unique password for each site if possible. If they can't feasibly use unique passwords for each site, they need to make sure they don't use their new password on sites that aren't fixed yet. That's pretty crazy, and getting anything close to 100% compliance is going to require a ton of visibility. Someone should make a browser extension as quickly as possible to tell users if they're visiting a yet-unfixed site.
- mixedbit 13y agoThe problem is also that as long as a vulnerable site is not fixed, users should not attempt to login or interact with such site while logged in. Such interactions increase chances that users' cookies or passwords will be in servers memory.
- patio11 13y agoThat's a bit unworkable, particularly as you can get many sites to load a user into memory by putting a post-auth URL into an IMG tag anywhere on the Internet. Your browser will obediently GET that URL, passing along the session cookie to the legitimate server, where it will then be exfiltrated via heartbleed. Basically: this vulnerability must be patched, or the server must be taken offline, and that needs to happen everywhere.
- shock-value 13y ago> Basically: this vulnerability must be patched, or the server must be taken offline, and that needs to happen everywhere. No one is arguing against that. The point is that from the user's point of view, they shouldn't interact with a server at all if it is still vulnerable to this attack.
- lockes5hadow 13y agoAnd how would a browser extension do that reliably? Someone who has exploited a Bleeding Heart server would have their cert and could then impersonate the server using a patched OpenSSL.
- AaronFriel 13y agoThere seems to be some confusion about the vulnerability on the client side, which I think should be clarified. The Heartbleed vulnerability seems to only affect OpenSSL clients and servers. The buffer overrun is only known to be in OpenSSL, so other SSL clients should be unaffected. Client web browsers are not affected because: Firefox uses NSS on all platforms. Chrome uses NSS on Linux or platform libraries for SSL or uses NSS on all platforms for SSL, and then uses the system libraries for other cryptographic operations and certificate validation. Platform-specific browsers (IE, Safari) likely use their platform's SSL code. Almost every other mainstream browser is a derivative of one of the four mentioned so far. Edit: As another commenter pointed out, client-side consumers of the OpenSSL library are likely affected as well. That means web spiders and server-side code that uses web APIs are likely affected. That may or may not be concerning, depending on the networks that traffic travels over and the method of authentication.
- bri3d 13y agoWhile client browsers aren't generally affected, other clients may be. If you have some form of web spider, or especially a web hook or callback service which can accept an arbitrary URL, you could be exploited relatively easily. This applies to language runtimes, too.
- sinak 13y agoRunning the exploit and all I see are session IDs. Has anyone seen any passwords being output?
- axisK 13y agoOn my first run today I saw some passwords going to the admin section on our staging servers so it really depends on what you're targeting.
- Cthulhu_ 13y agoTRWTF is how Jira doesn't apparently check if the session id is coming from the same computer (a simple ip address check for example). Pretty sure most sites are secure against cookie (and thus session) takeovers.