A while back I wrote about the nightmare of digital certificates, and the Heartbleed vulnerability has brought many of the problems within it to the fore. With Heartbleed with have the problem of an intruder viewing the running memory of the Apache Web server, and where the private key from the certificate is viewable. This has caused large-scale panic across the media, with users being told to immediately change their passwords, and for companies to revoke their digital certificates. Both these things are not good general advice, as it is important to understand the technology underpinning the infrastructure, and its associated risks.
Users changing passwords
One of the worst pieces of advice was related to users changing their passwords. While generally this is not a bad piece of advice, with Heathbleed a user going on-line and revealing their previous and new passwords in the running memory is probably going to cause more problems than it solves, so it’s generally a bad piece of advice. Users should thus contact their service provider and find-out if their systems have been patched, and that they have tested them. After which the user can change their password, just in case. What amazes me is how few organisations have informed their employees about the exposure of their systems to the vulnerability, and the patch strategy around this. If have been contacted by many people asking for advice on the vulnerability, and the only piece of advice I can give is for them to contact their service provide and get advice from them.
The other issue relates to the revocation of the digital certificate from a Web site. With this, if the intruder manages to get the private key related to a digital certificate, the intruder can then sign things with this key, and thus provide a fake identity. There is a chance with Heartbleed that the private key could be revealed in the memory of the Web server, thus many companies are worried that their identities have been stolen. Along with this there is no actual evidence that this has taken place, as there is no way of determining of the data from the memory was ever examined, and where the key was present when the access took place. Thus there has been a knee-jerk reaction, which is understandable, and companies have went ahead and changed all the certificates with new private keys. This might work, but unfortunately, the method of certificate revocation is not implemented as well as it could be. This is highlighted most with Google Chrome, often used on mobile phones, which has a default setting where certificate revoking is not checked.
Figure 1: Chrome setting for certificate revocation
What also is strange is that I’ve heard of companies who have a Microsoft IIS Web infrastructure and have went ahead and revoked their certificates. This shows the chaos that Heartbleed has caused.
Adobe Revocation Part II
The last time there was a major threat like this, there was much less publicity about it, but it did cause many problems with companies. I know of one major defence company who shutdown their whole operations in order to root out any possible compromises. It was officially announced on 27 Sept 2012 with a statement from Adobe of:
We recently received two malicious utilities that appeared to be digitally signed using a valid Adobe code signing certificate. The discovery of these utilities was isolated to a single source. As soon as we verified the signatures, we immediately decommissioned the existing Adobe code signing infrastructure and initiated a forensics investigation to determine how these signatures were created. We have identified a compromised build server with access to the Adobe code signing infrastructure. We are proceeding with plans to revoke the certificate and publish updates for existing Adobe software signed using the impacted certificate. This only affects the Adobe software signed with the impacted certificate that runs on the Windows platform and three Adobe A IR applications* that run on both Windows and Macintosh. The revocation does not impact any other Adobe software for Macintosh or other platforms. Sophisticated threat actors use malicious utilities like the signed samples during highly targeted attacks for privilege escalation and lateral movement within an environment following an initial machine compromise. As a result, we believe the vast majority of users are not at risk. We have shared the samples via the Microsoft Active Protection Program (MAPP) so that security vendors can detect and block the malicious utilities. Customers should not notice anything out of the ordinary during the certificate revocation process. Details about what to expect and a utility to help determine what steps, if any, a user can take are available on the support page on Adobe.com.
Wow … what a passive and bland statement about something that had a major impact of the credibility of Adobe software … Adobe Reader, Adobe Photoshop, Adobe Flash … all of the packages in Windows! It warns users not to worry about the revocation, as if to say that it was a minor little background process. What the major threat here was the existing Adobe software, which could not be covered by the revoke, and for the browsers which did not check for the revoke process. Imagine now that the scope of Heartbleed multiples this by every company with an Apache Web infrastructure or even with Cloud infrastructures, and you have the scope of the current problem.
The statement I love is:
This only affects the Adobe software signed with the impacted certificate that runs on the Windows platform and three Adobe AIR applications* that run on both Windows and Macintosh.
which basically is all the software running on Microsoft Windows, and three packages that run on both Windows and Mac OS. If we did a Venn diagram of this, it is all of the Microsoft Windows software and three apps for Mac OS (as illustrated in Figure 2), where the cross-over are the three Adobe AIR applications).
The Adobe key release brings back the scariness of the threats caused by Heartbleed. The most serious threat was related to pwdump7 v7.1, which is a program which extracts passwords hashes from the operating system, and then links to the OpenSSL library libeay32.dll. Both these files were signed with the Adobe private key and were thus highly trusted on the system.
With an eye on their product range, and a lesser focus on security, they continued on with:
Our internal testing indicates that moving the impacted Adobe certificate to the Windows Untrusted Certificate Store does not block threat actors from executing the malicious utilities on a victim machine. However, this configuration does have a negative impact on the user experience and execution of valid Adobe software signed with the impacted certificate. Adobe does not recommend using the Untrusted Certificate Store in this situation.
So, as with all companies, there is a tightrope that must be traversed between useability and security. In this case Adobe, erred on the side of making sure their products still worked, and for system administrators to weed out the malicious software. What is more worrying is that there might have been many more programs in the wild which were signed by the leaked private key (and still could be).
Finally we must end with a great statement:
The vast majority of Adobe customers will not be impacted by this issue. However, some customers, in particular administrators in managed Windows environments, may need to take certain action.
which basically meant that most customers could be affected, especially if they were running on a Windows platform, and the people that had the work to do were the system administrators – just like Heartbleed.
One of the first companies highlighted within the Heartbleed vulnerability was Yahoo. With this a screen shot showed how usernames and passwords, along with the possible presence of private keys should be viewed from the returned payload. One of the first things that they did to mitigate the threat of intruders stealing their private key, was to re-issue the certificate. So on 9 April 2014, Yahoo’s main Web site had a new 2,048-bit RSA public key:
While most people think the main issues with the Internet relates to malware and data leakage, the actual real thing that could cause the Internet to fall-apart is actually a large-scale loss of private keys, especially where the software signed is doing highly trusted activities, such as reading passwords, creating VPN tunnels, in generating encrypted content. The greatest current threat is that we trusted openssl, and it has become the bedrock of our secure infrastructure, but the great future threat lies within the loss of encryption keys. CEOs should say to themselves … I know where the keys of my company are … but where are my electronic keys? If they can’t answer that, then their company could have problems in the future!