Terrible secrets are often just a peek at a binary away

Why bother to trick someone into revealing their password when there’s perfectly good ones hardcoded into software?

At DEF CON 31, LMG Security Penetration Testing Team Manager Tom Pohl warned that manufacturers often leave private credentials, legitimate certificates, encryption keys, and other secrets inside software and firmware binaries. If the wrong person manages to glean a look at such a binary’s inner workings, the result can be disastrous.

“I look at a lot of firmware, I look at a lot of software, and everywhere I look, pretty much, I find some kind of a terrible secret,” Pohl told IT Brew. “It’s an easy route to put a secret in a place where it can be retrieved and used later.”

In NetGear router firmware, Pohl and Aruba Threat Researcher Nicholas Starke found two valid, signed TLS certificates, as well as their corresponding private keys in PEM-encoded text files, potentially useful for man-in-the-middle attacks or hijacking routers.

Fortinet’s FortiGate hardware firewall and FortiAuthenticator security appliance had private keys used to communicate with Apple and Google Cloud messenger services stored in plaintext in obfuscated archive files. That vulnerability, which Pohl told attendees could potentially allow him to send push notifications to people’s phones as Fortinet, wasn’t resolved for three years.

Finally, Dell’s Compellent Integration Tools for VMware contained a static AES encryption key used to decrypt vCenter credentials. The key was the same for every customer, potentially allowing attackers to retrieve any other vCenter credentials stored in the program’s configuration file. (According to BleepingComputer, Dell has since advised customers to change Compellent devices’ root passwords.)

“A key shouldn’t be static for all customers,” Pohl told IT Brew. “Beyond that, using some kind of a secure enclave, or some kind of a mechanism—a TPM or something like that.”

With a static key for all customers, “you can go to any customer’s thing and get the password back, when there’s reversible encryption in play,” Pohl added.

In some situations, like commodity router hardware, protecting secrets can be difficult due to hardware limitations, according to Pohl. He said the Fortinet fix took so long because the fix was “actually an architectural change that requires significant enhancement.”

Pohl speculated software developers, under pressure to ship code, often just wrongly assume no one will ever be able to find hardcoded secrets.

“Java is stupid easy to decompile,” Pohl told IT Brew. “Other binaries, written in C and other languages, you can put in Ghidra [a National Security Agency-developed reverse engineering tool] and come up with it that way. That’s kind of eye-opening when you show a developer, ‘No, this thing you think is secret is not actually secret.’”

“This is a systemic problem, where the secrets are not managed well,” Pohl continued.

Pohl said bug bounty programs have often become vehicles companies use to pay off researchers rather than fix bugs. For example, he said that NetGear directed him to go through their official bug bounty agreement, which would require LMG Security to agree to silence. They released details of the vulnerability instead, and NetGear issued a patch within days.

Instead of so-called “responsible disclosure” with terms set by manufacturers, Pohl urged DEF CON attendees to pursue coordinated disclosure, where security researchers and software developers agree on a timeline to release details of a vulnerability.

“I think that’s honestly the more secure way to approach bugs,” Pohl concluded. “That’s actually going to move the industry forward, because the manufacturer is going to be incentivized to fix it, because it’s going to be disclosed.”