Heartbleed: Not only servers hit by OpenSSL bug, your PC and phone may be vulnerable too
Although most attention surrounding the Heartbleed vulnerability has been given to the server side, the SANS Institute has reminded the world that the client side is also vulnerable.
In a presentation given yesterday, Jake Williams – aka MalwareJake – noted that vulnerable OpenSSL implementations on the client side can be attacked using malicious servers to leak passwords and cryptographic keys.
Williams said a malicious server could easily send a message to vulnerable software on phones, laptops, PCs, home routers and other devices, and retrieve a 64KB block of sensitive data from the targeted system. It’s an attack that would probably yield handy amounts of data if deployed against users of public Wi-Fi hotspots, for example.
Writing client exploits are “not going to be that difficult to do,” he said.
Security penetration testers are going to find themselves in work “through 2020” with this bug, Williams said, and noted that it’s going to be hard to identify vulnerabilities in some environments. For example, he said, it’s going to be hard to tell if Windows client programs were compiled against vulnerable OpenSSL versions.
And that’s not to mention all the “non-port-443” software that might be compiled to vulnerable versions of OpenSSL – e-mail servers, databases, LDAP services, and so on.
While The Register has a code-level description of Heartbleed here, it’s also handy to have an easy pictorial, which Williams provided. In the OpenSSL RFC, there are two user-supplied inputs that create the problem as shown in the image below:
When the attacker sends a request filled in as per the second of the two message blocks, here’s* what’s returned by the target:
That this happens during connection negotiation – which is why it’s available to an unauthenticated attacker. Williams also noted that the risk that the vulnerability could reveal site certificates means that if an attacker – or a spook – has previously recorded encrypted sessions, they will now be able to decrypt that traffic.
Worse, he said it’s also feasible that what turns up in the leaked memory could give attackers hints at how to take the axe to other software, turning known bugs that are currently seen as “hard to exploit” into easy kills.
Another issue that could be easily overlooked, he said, is in the cloud. If you’re running VMs in a cloud environment: admins must find their cloud machines and make sure their code base isn’t Heartbleed vulnerable.
User training is going to be another big issue: end-users are going to have to be trained to check certificate issue dates, to make sure that their trusted services (like the bank) have re-issued their certificates.
Then, he added, there are thousands of “shoestring budget” VPN concentrators in smaller businesses that will be vulnerable and probably won’t be updated.
Williams was critical of vendors, since so few of them have made vulnerability statements (SANS has a list here). “Too many vendors not communicating with their customers,” he said.
Google has released its response to Heartbleed here, in which it lists the status of key products and services. CloudSQL is currently being patched, users need to update OpenSSL on each running instance on Google Compute Engine, the Google Search Appliance is currently being updated, and it says only Android 4.1.1 is at risk.
Regarding vulnerable Android units, Williams said he’ll be watching carrier responses “with interest”. ®
* The author’s apologies to @MalwareJake for not screen-grabbing his copyright in the second slide.