Backdoor code was committed by a former Oracle employee. Developers of Socat, a *NIX-based networking utility, have discovered and patched a security bug affecting its encryption capabilities and that weakened the tool enough to allow attackers to downgrade and break encrypted data streams.
Socat is a command-line utility for *NIX-based operating systems that enables developers to create network connections to various ports and protocols. One of the features distinguishing it from the older netcat project is its support for encrypted data streams.
This process employs the Diffie-Hellman algorithm, which uses a prime number to generate a random cryptographic key, and which in turn is used to encrypt all communications.
Socat wasn’t using prime numbers to create secure encryption keys
According to a security advisory put out yesterday, Santiago Zanella-Beguelin from the Microsoft Vulnerability Research team discovered a problem with how Socat was creating its encrypted communication channels.
“In the OpenSSL address implementation the hard coded 1024 bit DH p parameter was not prime,” the advisory reads. “The effective cryptographic strength of a key exchange using these parameters was weaker than the one one could get by using a prime p.”
“Moreover,” the advisory continues, “since there is no indication of how these parameters were chosen, the existence of a trapdoor that makes possible for an eavesdropper to recover the shared secret from a key exchange that uses them cannot be ruled out.”
Socat versions 1.7.3.1 and 2.0.0-b9 were released to address this issue.
“Alleged” encryption backdoor was introduced in 2015 by an Oracle employee
But things didn’t stop here. The infosec community did not take the discovery of an encryption backdoor in one of their favorite open source debugging tools very lightly.
Developers discussing this topic on Hacker News sifted through thousands of commit logs and found out when and who added the malicious code to the Socat project.
The person that committed the code is named Zhigang Wang and was an Oracle employee that regularly contributed to the Xen and Socat projects.
Chances are that this is an intentional backdoor
In the message attached to the commit, Socat developer Gerhard Rieger wrote, “Socat did not work in FIPS mode because 1024 instead of 512-bit DH prime is required.” This code was added in January 2015 and was removed only a few days ago by the same Gerhard Rieger.
FIPS stands for “Federal Information Processing Standard” and is a US Government standard that describes the use of encryption and cryptographic services.
This standard regulates that all software and devices used by the US Government and its military must be FIPS 140 compatible. Companies that want to be FIPS 140 compatible must submit their software for testing to an independent testing laboratory before being deployed in US agencies.
The commit explanation from January 2015 does not make any technical sense, since it actually lowers Socat’s encryption capabilities, and should have been treated with more scrutiny from the project’s maintainers.
Intentional or just a random bugfix, this case only comes to show that open-source projects aren’t automatically protected from malicious code, as the FOSS community often likes to boast.
Source:https://news.softpedia.com/
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
