Hardcoding Keys. Is that Wyse?

A couple of years ago, we were testing a large system of around 3000 Wyse terminals, all operating unattended. To configure themselves, they download a configuration file called wlx.ini from a webserver.

This file contained a few fields that seemed interesting – ChangeRootPassword and PasswordEncryption.

This is different – rather than distribute a hashed password, they are distributing an encrypted password. If the password were hashed, the two paths we could take are:

1. Alter the file as it is distributed to the Wyse terminals, either by tampering with it in-transit or on the server. It was downloaded over correctly validated HTTPS and the server was secure, so this was a no-go.

2. Perform a brute-force attack against the hash. For a password of reasonable quality (which, it should be), this would be impractical.

However, they chose to encrypt it. Now we have an easier path:

3. Decrypt the password and use it to directly login to the boxes.

To me, it seems like the more secure path is to hash rather than encrypt.

We now needed to work out how to decrypt the password. We assumed the key was the same for all Wyse terminals on this network – they all downloaded the same file. A bit of research led us to a Dell tool to create the encrypted passwords:

Crucially, there is no input for a key. Now we know the key is not just the same for this network, but ALL Wyse terminals.

The app was put into IDA Pro. I was surprised that the app wasn’t .NET – it looked like it was. .NET is much easier to reverse engineer. A combination of static and dynamic analysis was used to work out what was going on.

I could clearly see the strings like “—–BEGIN PUBLIC KEY—–” – this is RSA! The documentation said AES. What is going on? Maybe they encrypt it with a private key and the device decrypts it with a public key?

I spent a fair while looking through the app for RSA routines. I couldn’t find them. This made no sense!

Time to take a step back and look for AES encryption. This is normally quite easy for an Intel x86 binary – they tend to use the hardware AES-NI instructions.

A little bit of reverse engineering later, and we can see what Wyse are doing.

AES-128 encryption in CBC mode, using PKCS#7 padding, with the initialisation vector hardcoded as “1123456789012345” and the key hardcoded as:

“-----BEGIN PUBLIC KEY-----
MIGfM”

Yes, they were using an RSA public key as an AES key. This blew my mind. I really can’t comprehend how this happened.

It’s embarrassing rather than impactful though – whatever the AES key is, it must be stored in the application.

We reported this to Wyse (which was a smooth process) and they have issued a CVE.

And I’ve created a CyberChef link so you can decrypt any passwords you find.

The result for this test was root access to all Wyse terminals.