There’s never been a good time to be cavalier about certificate security. But with the speed of digital transformation comes the increased risk of inadvertent errors in the treatment of certificates—particularly in software. And security flaws that impact these machine identities, such as those recently uncovered in HP’s software assistant tool, prove why you can never let your guard down in managing your machine identities.
Valid certificate exploited
In an in-depth blog, researcher Bill Demirkapi outlined three different ways that cybercriminals could gain remote code execution against the HP Support Assistant. You may remember Demirkapi as the 18-year old boy wonder who uncovered vulnerabilities in education software made by Blackboard and Follett last year. This effort then propelled Demirkapi into a speaking slot at DEF CON last year.
First, I’m impressed by the depth of his work. But the one thing about his HP discovery that most interests me the most is Remote Code Execution Variant #3, which exploits a very liberal acceptance of security certificates by HP during the signature check.
Demirkapi outlines the vulnerable signature check as follows:
“The method takes in a file name and first verifies that it’s a valid certificate. This means a certificate ripped from a legitimate HP binary won’t work because it won’t match the binary. The concerning part is the check for if the certificate is an HP certificate.
To be considered an HP certificate, the subject of the certificate must contain in any case hewlett-packard, hewlett packard, or o=hp inc. This is a pretty inadequate check, especially that lower case conversion.”
A weak implementation such as this would create a heyday for cybercriminals. Essentially, it would allow them to avoid HP checking if the application has the correct signature so a malicious version of the application could be substituted. In this scenario, cybercriminals could create any number of bogus certificates that would pass this loosely defined certificate check. Given the number of machines that include preinstalled versions of HP software assistant tools, we’re talking about a virtual spoofapalooza.
As Demirkapi notes, “I could probably spend days making up company names. All an attacker needs to do is create an organization that contains any of those words and they can get a certificate for that company. Next thing you know, they can have a one click RCE for anyone that has the HP bloatware installed.”
How can you tell a bogus certificate?
The good news is that all of the remote code execution flaws have already been patched by HP. But the question remains, how would an organization know if a cybercriminal were using a bogus certificate to access critical infrastructure? I mean, most organizations struggle to maintain a complete inventory of the legitimate certificates on their networks. But they would need a whole lot deeper intelligence if they are going to locate all certificates in use in their network—including potentially malicious usage. A spreadsheet, or a Certificate Authority dashboard alone simply won’t provide that level of insight.
That, my friends, is why machine identity management is such a vital tool for even the largest, most security savvy organizations. With complete visibility and continual monitoring, these organizations will be able to drill down to the level of who owns a particular certificate and where it’s being used. It’s the most effective way of maintaining control over the ever-increasing numbers of machine identities that all organizations rely on for secure connections and communications.
How much do you know about your machine identities?