While most of the buzz surrounding OpenSSL's Heartbleed vulnerability has focussed on websites and other servers, the SANS Institute reminds us that software running on PCs, tablets and more is just as potentially vulnerable.
Institute analyst Jake Williams said the data-leaking bug “is much scarier” than the gotofail in Apple's crypto software, and his opinion is that it will have been known to black hats before its public discovery and disclosure.
More ReadingFixing OpenSSL's Heartbleed flaw will take MONTHS, warns SecuniaArts and crafts store Michaels says 3 million credit cards exposed in breachVMware patches man-in-the-middle vSphere vulnOpenSSL Heartbleed: Bloody nose for open-source bleeding heartsHeartbleed vuln under ACTIVE ATTACK as hackers map soft spots
In a presentation given yesterday, Williams – aka MalwareJake – noted that vulnerable OpenSSL installations on the client side can be attacked by malicious servers to extract passwords and cryptographic keys from users' computers and gadgets.
Williams said a dodgy server could easily send a message to vulnerable software on phones, laptops, PCs, home routers and other devices, and retrieve up to 64KB of highly sensitive data from the targeted system at a time. It's an attack that would probably yield handy amounts of data if deployed against users of public Wi-Fi hotspots, for example.
Writing code to exploit vulnerabilities in clients is “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:
This can happen during connection negotiation, which is why the flaw can be exploited by 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.