OpenSSL Patches New Bug Targeting Encryption [Lessons from Heartbleed]

What is the new OpenSSL vulnerability?

CVE-2022-0778 is described as an infinite loop DoS attack discovered by Google vulnerability researcher Tavis Ormandy. A flaw in the encryption algorithm used to underpin OpenSSL was exploited, triggering an infinite number of requests when certain input value(s) are used. OpenSSL relies on Elliptic Curve (EC) cryptography, which is faster and more elegant than the older RSA, and the bug resided within the Tonelli-Shanks algorithm that gives EC its reduced form.

“The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli,” states the security advisory. “Exploitation of the vulnerability is possible in certain situations, and it can lead to a DoS attack against a process that parses externally supplied certificates.”

Ironically, the only programs affected by this DoS attack were the ones doing their due diligence in checking for legitimate cryptographic certificates. “The most common scenario where this would be a problem would be for a TLS client accessing a malicious server that serves up a problematic certificate. TLS servers may be affected if they are using client authentication (which is a less common configuration) and a malicious client attempts to connect to it.” Be this as it may, a DoS attack is still favorable to a breach, so while programs not using proper encryption may avoid this minor attack, they leave themselves open to far worse outcomes.

Thankfully, according to one OpenSSL developer, there are not any known cases of this being exploited.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Heartbleed: Have we learned our lesson?

The last time we saw a bug of this scope was Heartbleed, the infamous attack on OpenSSL that lay undetected for two years (originating in 2012 and remaining unknown until 2014). Prior to this, there had never been an exploited open-source vulnerability of this scale. Heartbleed used a memory copy function to extradite additional data from servers upon returning data requests, then “panned for gold,” sifting through the copied information to find valuables such as usernames, passwords, keys and certificates. It affected nearly two-thirds of servers on the internet and was not only dangerous, but relatively simple to understand and execute, which lead to its massive proliferation.

What did Heartbleed teach us?

1. Open source is a prime target for attackers. Heartbleed directly affected OpenSSL and taught us that criminals also see the potential of nearly ubiquitous open-source coding. Because OpenSSL is everywhere, infiltrating it is like hitting the hacking jackpot. OpenSSL underpins Unix and Linux systems, is used by a host of other software, and is bundled in a plethora of applications, including Windows, where they have cryptographic libraries of their own. Because it is a widely used programming toolkit, tampering with OpenSSL yields a very high ROI attack.

2. “Open-source” does not make it safe. This attack taught us that just because OpenSSL is widely used, it does not mean it is widely protected. While at one time the two concepts may have seemed synonymous, attacks like Heartbleed show us that errors still occur and that we must regularly and independently perform security checks on all applications, software, programs and systems that are running on open-source cryptography. It also teaches us to use the latest version of OpenSSL, be aware of known vulnerabilities, and patch often.

3. Damaging attacks do not have to be sophisticated. As one of the most severe cases of an OpenSSL attack on record, Heartbleed was surprisingly simple to execute. It did not require sophisticated malware, and it was easy to replicate. Even the most advanced detections could not stop such a simple bug from stealing data and the credentials that came with it, it is important to ensure that our keys and certificates are independently guarded.

4. Encryption must be encrypted. Heartbleed accumulated large amounts of random server data, and (perhaps unsurprisingly) there were a lot of unprotected keys and certificates in the mix. Having keys and certificates roaming around in unencrypted and unsecured locations on your server lays you open to attack. Even internally, exposed keys and certificates are unsafe, and should be not only protected, but carefully accounted for.

5. Automate certificate lifecycle management. To defend against OpenSSL vulnerabilities or any attack on your encrypted assets, you must have the ability to renew your keys and certificates at a moment’s notice. That way, even if Heartbleed or another vulnerability managed to discover your credentials, an immediate and universal update of all keys and certificates enterprise-wide will eliminate the problem. This can be done by automating each of the stages (enrollment, validation, revocation, and renewal) so your security teams don’t have to bear the burden of manually deploying certificates. Manual deployment is prone to errors and slows down remediation at a critical time. Automating your certificate lifecycle management not only solves the issue of certificate expiration and human error but enables you to stay agile in the event of certificate compromise.
 

If you found your certificates had been compromised in an OpenSSL attack, the question you would need to ask is… “Can I identify the location of each certificate and have them all revoked, renewed, and reconfigured within one day?” If the answer is no, you would need a robust machine identity management platform, such as one offered by Venafi, which will allow you to secure all your certificates with ease.

Related Posts

• Schrems II: Modernized Contractual Clauses and End-to-End Encryption
• Level Up: Get End-to-end Machine Identity Lifecycle Protection with Intel® SGX
• Concerned About Social Media Hijacks? Then Don’t Ban End-to-End Encryption

A bug in the cryptographic coding of OpenSSL was recently disclosed and mitigated. Known as CVE-2022-0778, this high severity DoS attack was traced back to a loophole in the encryption and has now been patched. This is one of several high severity attacks that have impacted OpenSSL over the years, and although a lot has changed since Heartbleed, many lessons remain salient. It is worth comparing the two OpenSSL attacks, what they have taught us, and what we can learn to protect our open-source encryption in the future.

After reading this blog, check out the security update and upgrade to versions 3.0.2 and 1.1.1n, if you haven’t already done so.