Being found out only once maybe an oversight from which lessons might be learned. However, doing it twice in a seven-year period demonstrates a laissez-faire attitude about the internet’s stability.
Heartbleed appeared in 2014, demonstrating to the public that the standardization that powers the internet — in this case, the OpenSSL library that supports SSL/TLS secure connections – is fundamentally defective. Anyone who used this library, whether directly or through the software that contained it, was in danger. As a result, the entire internet was jeopardized.
Setting the clock forward. There is already a fault that is equally lethal. This time it’s in log4j, a Java-based logging application. This, dubbed Log4Shell, is significantly more similar to Heartbleed. It is ubiquitous around the globe, right down to the smallest gadgets in people’s homes. The task is to figure out where it is.
Controls for software development are strict
Any developer working on Java apps should check to see if log4j is being used. Professional software engineers in big firms with established software development procedures often have good component management. This implies they can determine which of their apps employ log4j-required software modules. Is it imported via another module required by the developer to construct the application? The National Cyber Security Centre has recommended businesses fix their programs as quickly as possible. “The critical step for enterprises is to upgrade enterprise software immediately, and for log4j developers to update and share their product as soon as possible,” the company stated in a statement.
The fundamental weakness has existed for many years. In reality, during BlackHat 2016, a design fault in Java RMI that renders log4j susceptible was demonstrated. However, there had been no exploits. However, as of December 13, around 72 hours following the revelation, security firm Check Point said that its systems had blocked over 846,000 attempts to exploit log4j, with 46 percent of them being attempted by known malevolent parties.
This raises fundamental concerns about the administration and finance of the internet. Why didn’t anybody try to address an issue that had been known about since 2016? The reason for this is that there was no burning platform. No one bothered to address the Java RMI bug since experts assumed it’d be difficult to remotely attack devices and servers. However, log4j enables developers to remotely monitor the health of their apps via remote logging. A Python proof-of-concept code snippet demonstrates how simple it may be abused. Because creating an attack is so simple, Log4Shell has the potential to devastate internet security.
Sources:
https://www.techtarget.com/searchsecurity/answer/Heartbleed-vulnerability-Why-does-it-persist-on-so-many-services
https://www.computerweekly.com/news/252510939/Almost-half-of-networks-probed-for-Log4Shell-weaknesses
https://www.ncsc.gov.uk/news/apache-log4j-vulnerability
https://www.computerweekly.com/blog/Cliff-Sarans-Enterprise-blog/Log4Shell-Why-arent-we-taking-the-security-of-the-internet-seriously