This 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?
It 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.
Someone 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.
I 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.
Really 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.
There 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.
While 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.
- 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.
The 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.
That'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.
> 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.
And 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.
Recovery should also probably include nuking all current sessions, as any session key created prior to updating is potentially compromised and would remain so after the update.
Wow, 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.
Although 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.
Yeah, 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.
A 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.
What'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.
In this attack, data from the server process's address space is sent back to a malicious client.
Yahoo hopefully/presumably store only password hashes at rest, but just as in almost any system the user's real, clear password has to be sent from the user to the server to hash and verify against the database in order for the user to log in. Yahoo were following best practices by sending this password encrypted over HTTPS, but this vulnerability is a particularly insidious one because it actually punishes sites for doing the right thing in the form of encrypting traffic.
Because of the particular memory read using this attack and the memory layout Yahoo's service ended up with, other users' decrypted login traffic would get sent back to malicious clients with high frequency.
If I remember correctly, a browser add-in using TOTP could remove this as a viable attack method. By the time the user's one-time-encrypted login token is sent to the server it's been invalidated after login, and a new token is required, so siphoning off durable creds from memory becomes useless. However, you can still skim sessions.
Session skimming is definitely still viable, and is especially bad if the compromised service doesn't require an escalated / different session to disable 2FA.
Additionally, there's a chance an attacker could compromise the TOTP secret as well as it will probably be in memory around the same time (unless the system is using a keyserver or HSM). At that point, the whole setup is blown and the user's credentials could presumably be replayed.
If I understand it all correctly, wouldn't the secret key exchange have been potentially exposed as well? It had to traverse some medium from server to client (or in reverse) at some point, so an attack could plausibly have account information as well as TOTP secrets to perform full two-factor authentications in perpetuity, no?
It's worse than that. Since the server has to use the TOTP key/secret to generate the token for validation, there's a very high chance the secret will be in the server's process memory at around the same time as the first-factor credentials are, unless a separate keyserver or HSM is in use. This applies on every login, not just during the initial TOTP exchange / setup process.
Thus, the key exchange doesn't need to be exposed for heartbleed to have a good potential to leak TOTP/2FA secrets.
Well I suppose you're right, if you're using your bastion host as the TOTP operation service provider, but I wouldn't recommend that for a whole host of reasons - the main one being that the bastion host is always the first host exploited, so you shouldn't be running anything from there but a proxy.
You should be able to simply move the TOTP operation to an authentication server on a more secure network and have your web-application server query it with the user's token. The web app will get back the result of the operation and never expose the secret key to the bastion host.
The 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.
The passwords did not come from the database (which should only have hashes stored) but from the http request send by the client during login (originally this was transmitted encrypted but leaked out due to the bug).
But 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."
It'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.
Maybe, 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.
Exploit 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.
This isn't true in the home videogame console scene. I know for a fact in the Sony PSP hacking scene, the main hackers had a handful of kernel exploits but are very careful about using them since SONY usually released patched firmware less than 48hrs after the exploit is public.
They hope exploits carry forward into newer firmwares so that they can use them to find newer exploits introduced in that firmware so when they use the previous exploits, they can use the news ones when SONY patches the older and explore what SONY did to fix it; learn more about how SONY's devs think.
There are limited circumstances when hording them might make sense; rumors are that there's been hording of XP vulnerabilities in anticipation of the support period ending, as using them pre-support might have meant that MS would have patched them, whereas saving them would presumably keep them unpatched forever.
But yes, generally you're right, and this circumstance is obviously different from that one.
Is 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.
If 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.
Thanks 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]).
For 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).
As 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.
For 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.
StartCom 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).
You'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.
It 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.
TRWTF 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.
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?