Innovate. Accelerate. Win.
September 18-19 | Las Vegas and Virtual
#MIMSummit2023 is the frontier for unstoppable innovation. The gathering ground for security leaders looking to redefine what’s possible. The must-see industry event of 2023. Register today and save with special Early Bird rates!
DoS/DDoS attacks are another tool increasingly deployed to erode trust on the internet, which relies on machine identities such as digital certificates.
For safe and secure utilization of machine identities such as SSL/TLS certificates, a careful check on the validity of such certificates is crucial. One of the ways this validity check is performed is using the OCSP (Online Certificate Status Protocol).
But OCSP also creates a favorable attack vector which threat actors have exploited directly by mounting DoS/DDoS attacks.
OCSP is an internet protocol which browsers use to determine the revocation status of digital certificates that are deployed on websites.
By traditional design, OCSP requests are made to an OCSP server/responder. This dependence creates a single point of failure and makes the OCSP responders a favorable target for DoS/DDoS attacks – that if successfully executed can disable certificate validation.
Targeting OCSP by DDoS-ing has the potential to cause impairment of validity checks of SSL security certificates, as was seen in the SwissSign Certificate Authority (CA) incident in 2020. Such attacks can lead to web browsers such as Chrome being prevented from verifying the validity of the certificates to prove identity. This leads to browser trust issues on the client’s end and results in hindering access to sites.
OCSP Stapling is an enhancement to the original OCSP protocol. It relieves the client of querying the OCSP server on its own and reduces the attack surface. But even OCSP stapling can be made vulnerable to DoS if the remote web server is using a vulnerable version of OpenSSL as has been uncovered by CVE-2011-0014, published back in 2011.
Machine identities as primary agents
On the other hand, machine identities when compromised could also become primary agents or auxiliaries in creating and sustaining a DoS attack (as in the case of a second stage attack).
Maliciously crafted SSL certificates can cause overwhelming resource consumption, leading to a DoS situation. CVE-2022-0778 published this year has the potential to do that, if exploited.
CVE-2022-0778 causes the OpenSSL library to enter an infinite loop (DoS condition) when parsing an invalid certificate. What is concerning here is a malicious actor does not need a verified certificate to exploit this because just the parsing of a malicious certificate triggers the loop before the verification process is even completed.
This impacts the OpenSSL toolkit and, because it is one of the most popularly used implementations of SSL, immediately opens up a broad range of exploitation potentialities.
An example of an actual incident—and illustrating a similar situation—is the one reported by the Dutch CA KPN, which back in 2011 discovered a breach of its infrastructure and was forced to temporarily cease issuing SSL/TLS certificates as it had uncovered a DDoS tool on one of its servers.
Another relatively commonly known scenario tied to DoS is a buffer overrun that can be triggered in X.509 certificate verification. This can result in a crash causing DoS. This is one of the best-known types of DoS attacks that’s still widely seen. Most software engineers / builders know or have heard of what a buffer overflow vulnerability is, but that still hasn’t eliminated this form of attack.
More needs to be done to properly implement techniques that have so far turned out to be error-prone and are still often used to, ironically, prevent this.
Until then, we will keep seeing buffer overflow vulnerabilities impacting a sizable chuck of products, like the recent OpenSSL CVEs - CVE-2022-3602 and CVE-2022-3786 that triggered a lot of frenzy in the security community.