Biz & IT —

Crypto flaw was so glaring it may be intentional eavesdropping backdoor

Network tool contained hard-coded prime number that wasn't prime after all.

Crypto flaw was so glaring it may be intentional eavesdropping backdoor

An open source network utility used by administrators and security professionals contains a cryptographic weakness so severe that it may have been intentionally created to give attackers a surreptitious way to eavesdrop on protected communications, its developer warned Monday.

Socat is a more feature-rich variant of the once widely used Netcat networking service for fixing bugs in network applications and for finding and exploiting security vulnerabilities. One of its features allows data to be transmitted through an encrypted channel to prevent it from being intercepted by people monitoring the traffic. Amazingly, when using the Diffie-Hellman method to establish a cryptographic key, Socat used a non-prime parameter to negotiate the key, an omission that violates one of the most basic cryptographic principles.

The Diffie-Hellman key exchange requires that the value be a prime number, meaning it's only divisible by itself and the number one. Because this crucial and most basic of rules was violated, attackers could calculate the secret key used to encrypt and decrypt the protected communications. What's more, the non-prime value was only 1,024 bits long, a length that researchers recently showed is susceptible to cracking by state-sponsored attackers even when prime numbers are used.

"In the OpenSSL address implementation, the hard coded 1024 bit DH p parameter was not prime," an official with Socat wrote in an advisory published Monday. "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, since there is no indication of how these parameters were chosen, the existence of a trapdoor that makes [it] possible for an eavesdropper to recover the shared secret from a key exchange that uses them cannot be ruled out."

The advisory went on to say that an updated version of Socat used a 2,048-bit prime number to generate the secret key. People can also temporarily work around the vulnerability by disabling Diffie-Hellman ciphers.

Who is Zhigang Wang?

A post published to the Hacker News forum suggested that the non-prime parameter was the result of a code update published in January 2015. The update credited someone named Zhigang Wang for reporting the underlying problem and sending a patch. Posts attributed to Wang suggested that he worked for Oracle at the time that the fix was introduced. So far, no one has stepped forward to explain how an error of this magnitude was made and why it wasn't spotted by developers maintaining the Socat code base. An e-mail sent to a former address used by Wang wasn't immediately returned. This post will be updated if a response comes later.

Monday's disclosure came two months after officials with Juniper Networks said unauthorized code in its NetScreen line of firewalls gave the unspecified code creators the ability to log in to vulnerable devices and decrypt data encrypted by virtual private networks. Juniper officials have yet to say how the code managed to get into the code and stay there for years or who was responsible. The Dual_EC_DRBG random number generator, which was developed by the National Security Administration, also contains functions that can serve as a backdoor, a vulnerability that prompted security company RSA and, more recently, Juniper to remove it from their offerings.

If the non-prime number was knowingly supplied in Socat, it's hard to escape the conclusion that it amounted to someone intentionally building a backdoor into the tool. If, on the other hand, the catastrophically weak value was inadvertently added, it amounts to one of the more breathtaking programming blunders to populate the annals of modern applied cryptography.

Post updated to note Wang has been contacted and asked to comment.

Channel Ars Technica