Don’t ‘Roley’ your own encryption, says Bob the Builder

The Uplogix 3200 is a console server for out-of-band management. It claims ‘high security’ as it’s a closed appliance with a locked-down OS.

We were a little surprised therefore to find security flaws in the method they use to protect passwords on the device.

We were even more surprised by their initial response to our attempt to report the vulnerability. ‘Washing their hands of it’ springs to mind, although more recent interactions with Uplogix have been more constructive.

A CVE has since been allocated.

I wonder if whoever rolled the password encryption scheme is a parent of young children?

What Went Wrong?

The passwords stored on the device for connecting to serial devices are not adequately protected.

They are encrypted using a hard-coded password and 3DES, which means that someone with physical access can recover passwords for other devices from the disk.This becomes an issue if someone re-uses passwords across sites, or a discarded/disused Uplogix is recovered.

I re-wrote the encryption scheme in Python for your enjoyment:

import base64
from pyDes import *
import binascii

encrypted = b'V2T50GXo3UA='

data = base64.b64decode(encrypted)

key = ‘*********muckdizzy********'

des_obj = triple_des(key, ECB, IV=None, pad=None, padmode=PAD_PKCS5)

decrypt = des_obj.decrypt(data)

print decrypt

Whilst we’ve redacted most of the key, it does look rather ‘Bob The Builder’-ish doesn’t it!

Yes, it’s fairly low risk as it requires physical access.

Lesson 1: don’t roll your own encryption

Lesson 2: Can We Fix It? No We Can’t

Responsible Disclosure

Email #1 December 12 2018

RE: Contact for reporting a security vulnerability in Uplogix 3200

Hello,

Do you have a security contact?

Reply from Uplogix December 12 2018

Hello,

The Uplogix 3200 went End of Life December 2016.

That was it. WTF?

We replied later on Dec 12:

There are still a number in circulation though – we’ve just found several during a test.

Uplogix replied, again on the 12th

We do not support or upgrade End of Life products. Customers with them still in circulation are aware of this.

Washing their hands of any responsibility for EOL product?

We replied, explaining the vulnerability, even though they hadn’t asked us for any details. No reply

So we chased for feedback on December 13^th and got this:

I do [have feedback] but first I have to ask why you care and are testing an EOL product running old code?

Is this at a particular customers request and if so who?

Also what version of code are you running?

The resolution to all these issues would be to run the current version of code on the current platform which has an encrypted drive.

Or run on the 3200 in FIPS mode. But as I said we do not support the 3200 anymore and our current code does not run on it.

If you are trying to sell me penetration testing or resolution services just let me know.

This is all going a bit wrong: Do they expect us to name our client, clearly breaching an NDA?

Why do we care? Because we found a vulnerability that both Uplogix and our client may not know about, so the responsible thing would be to report it.

No, we’re not trying to sell you a pen test, we’re trying to do you a favour!

So we sent a last reply. At the very least Uplogix could have sent an alert to their customer base, encouraging them to upgrade!

We simply work with the equipment we find within the customer’s network. From our perspective (and that of a hacker), we don’t care if a product is EOL or how it was configured – we only care if it is vulnerable.

We don’t have any way to determine which versions of the software the issues exists in – it is possible this problem exists in later software as well. This is one of the reasons we report issues to vendors, as they can take the information and determine which software versions and products are impacted.

It was disappointing to find that Uplogix didn’t have an obvious security contact or vulnerability disclosure program, though I may have missed this.

I can’t see much documentation on the 3200 to indicate the different modes that the device can operate in. There may be a reason it can operate in non-FIPS mode.

Regardless, our intent is simply to make users of the device (and pen testers who may encounter them) aware of the issue so that they can take appropriate steps to mitigate risk.

Why was it necessary to be so brusque and unhelpful to researchers? Frankly, I’m a bit annoyed now and I really want to go reverse some of their other equipment and later firmware, then drop any vulns as 0-days.

But I won’t, I’m far too responsible for that.

Uplogix Support recovered the situation after we mentioned that we had a CVE allocated. We don’t disagree with the mitigations in place and would encourage anyone with old, unsupported kit to upgrade.

Thank you for reaching out to us; we are aware of this limitation.Physical access to our LMs is often behind a locked door and the devices it manages are usually co-located.  We do offer full disk encryption with Opal 2.0 SEDs in some of our newer products.

Conclusion

Don’t roll your own encryption and please be a little more understanding of security researchers. We’re trying to help.