Remote command injection through an endpoint security product

TL;DR?

We discovered command injection in a popular endpoint security product, Heimdal Thor. By using the product, customers PCs were exposed to compromise. Irony++

Heimdal fixed the issue quickly and responded well, but it appears that the vulnerability had been present in ~650,000 PCs for around one year!

29-03-2019 Correction

We stated that the vulnerability had been present in 650,000 PCs for around one year. This is not accurate.
Heimdal have since contacted us to correct this.
The vulnerability only shows in the 2.5.170 to 2.5.172 versions (it was fixed in 2.5.173).
The release for those versions started in late January, and they fixed it in February, so the period was around one month, not one year.
Also, regarding the affected PCs, they recorded only around 50,000 endpoints running those versions, since their update process is usually pretty slow, in order to detect failures in time.
Most of their users were still using the 2.5.151 version at that time and updated straight to the 2.5.173 version that they force-pushed to their clients.

There’s the CVE here, and Heimdal blogged about it, but er… didn’t mention the remote command injection!

How did we find it? During an automotive IoT pen test, of course!

During hardware tests, we often setup a Wi-Fi access point and attempt to redirect the device’s traffic through an intercepting proxy, like Burp Suite. Why? Because a disturbingly large number of embedded devices don’t check the identity of servers, which allows us to act as a man-in-the-middle.

Normally, if you connect a Windows laptop to one of these access points, you will be inundated with SSL/TLS etc. certificate errors and applications that flat-out refuse to communicate, as doing so wouldn’t be secure. Most software developers have realised that checking who you are communicating with is as important as encrypting the communications.

MITM

I was reviewing my Burp Suite traffic during a hardware test. As expected, the device under test hadn’t checked the identity of the server, allowing me to tamper with the firmware update process. But then I saw a different request. One that clearly contained details of a Windows machine:

Earlier in the day, one of our customer’s staff had connected his laptop to the access point to observe another issue we had found. During this period, most software on his machine noticed the crude attempts to tamper with traffic and stopped communicating.

But not all the software.

The domain it was communicating with – coreservice.heimdalsecurity.com – quickly led us to the culprit – Heimdal Thor. It appears to combine aspects of endpoint protection and automated software updates.

My first suspicion was that somehow, in the past, I had installed a Burp Suite certificate on the laptop. A quick check of the certificate store showed this wasn’t the case.

Ten minutes later, I have an evaluation copy of Heimdal Thor running inside of a virtual machine, and I’m seeing the same behaviour – I can intercept HTTPS communication without being noticed.

Heimdal Thor also does automated software updates. I could see JSON lists of software being downloaded, containing a URL, version etc.. And in those lists, parameters called “beforeInstallScript” and “afterInstallScript”.

So I could easily add in my own commands to be run:

So, when the client updates that piece of software, the commands will execute.

We can now run arbitrary commands on the client!

Endpoint protection products have to run with high privilege, so if an attacker can intercept traffic between your machine and the servers, they can take control of your machine.

Yes, the attacker needs to be able to intercept traffic, but an ideal location would be an open Wi-Fi access point in a coffee shop. Or one could compromise a home Wi-Fi network (weak PSK?) and then compromise the PCs on that home network.

The irony is not lost on us: a security product that makes you less secure…

Disclosure

This was reported to Heimdal Thor immediately.

It took them a few days to respond, and the response was very… honest.

It turns out that changes had been made to the software, bypassing certificate validation, probably to temporarily cure a functionality problem. This appeared to have been present for up to a year

The issue was fixed and automatically deployed in around 10 days – not bad for a large software deployment.

It’s often the disclosure process that’s a train wreck, but actually Heimdal did a good job of this.

However, we still can’t figure out why Heimdal downplayed the issue quite so much in their blog. To quote:

…did not correctly validate the TLS certificates …which would allow a highly skilled attacker with network access to be able to see details like hostname, hard drive serial number and motherboard serial number.

…and the RCI?!

Analysis

So what went wrong here?

Heimdal Thor is security software that runs at a high level of privilege on a user’s machine. It’s essential that it is held to the highest possible standards; we feel they have fallen far short.

The certificate validation issue should have been caught far earlier:

• Many instances of certificate validation can be caught at the code review stage – I have lost count of the number of times that it is turned off for “development” and left off when deployed.
• Significant changes to software should be tested. Checking that certificate validation is working should be done frequently, and ideally, automatically.

There’s more

I also noticed that the application wasn’t downloading normal executables for updates – these were .enc files, hosted by Heimdal.

Entropy analysis of the downloaded files indicated that they were encrypted. But how?

The application is written in .NET. This makes decompilation trivial. Within minutes, we have found decryption code

Rijndael is the predecessor to AES. Looking for references to this, we find it being used to decrypt files, with the key and IV being set to the slightly suspicious “CryptingConstants.Key” and “CryptingConstants.IV”.

And as expected, both key and IV are static, unchanging values across all installs of Heimdal Thor.

The issues don’t stop there with encryption. RijndaelManaged inherits from SymmetricAlgorithm, which by default uses CBC mode. This mode provides no authentication. Changes to the cipher text – either accidental or malicious – could go unnoticed.

You may also note that there is a “checksum” field in the JSON returned by the server. That’s an MD5 checksum. It might be helpful to detect accidental changes to the update file, but it’s not a barrier to an attacker. They would just generate a new MD5 and replace the old one.

In summary, the encryption provides neither confidentiality or authenticity.

The encryption is, in my opinion, a failure at the design and specification stage. It looks like there is a requirement for confidentiality – but confidentiality from who? Designing a cryptography system requires very clear security goals from the outset. Our recommendation here would be to start from the scratch all over again.