STE WILLIAMS

High performance access to file storage

Although most attention surrounding the Heartbleed vulnerability has been given to the server side, the SANS Institute is reminding the world that the client side is also vulnerable.

Williams said the bug “is much scarier” than the recent GOTO FAIL bug in Apple’s environment, and his opinion is that it will have been known to blackhats before its public discovery and disclosure.

In a presentation given on 9 April (US time), Jake Williams – @MalwareJake – noted that vulnerable OpenSSL implementations on the client side can be attacked using malicious servers.

Williams said a malicious server could easily send an exploit message to a client and retrieve the 64 KB memory block from the victim user – something that would probably yield handy amounts of data if deployed against users of public WiFi hotspots, for example.

Writing client exploits are “not going to be that difficult to do,” he said.

Pen-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. ®

High performance access to file storage

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2014/04/10/many_clientside_vulns_in_heartbleed_says_sans/