Introduction
Log4j is a java based worldwide and highly used logging system and more recently coming to the media regarding potential security issues within the Log4J framework. To begin with, in this report, to provide context, I will be discussing the background and idea behind what Log4j is and how it is not only used but how it is essential to modern-day computing. I will then analyse the shortcomings that face Log4j and then discuss how this has impacted people and businesses, along with some examples of this impact. Next, I will move on to the mitigations/workaround and what can be done to move forward. Finally, I will conclude the document and overview what has been discussed and the implications overall.
Background
Log4j is an open-source, Java-based program that plays a simple but essential role in data logging, troubleshooting and recording many system items such as error messages and routine operations. It is one of the many building blocks of modern software logging. With the initial release of Log4J in January 2001, it has become the known defacto standard for software logging and management, with over 95% of all software either directly or indirectly using this logging system (Jessica, 2021), hence the significant impact of the vulnerability. With Log4J gaining such massive usage worldwide, it’s no secret that many legacy-based systems also use this service, suggesting that there is a wide range of Log4J versions and patches meaning there is a large spread of potentially out of date devices. The vulnerability in Log4J was found in Beginning of December 2021 by a member of the Alibaba Cloud Security Team, who then alerted the Apache Foundation 9 th of December. After this release resulted in a substantial move on both sides, both offensive and defensive. Shortly after this release, a second vulnerability was discovered, which was resulted from the initial patch“CVE-2021-4510”. However, this was not to do with remote code execution and was based more on denial of service.
Analysis of Log4j
The critical error that has come about from Log4j is called“Log4jshel” (CVE-2021-44228), which is a remote code vulnerability and is predominantly targeting the Java Naming and Directory Interface (JNDI) by using a maliciously crafted string. According to statistics, only shortly after being released, over 3.7 million hacking attempts had been made to this exploit (CheckPoint, 2021) The vulnerability of these systems will allow attackers to extract data and information. Not only this, but attackers will also gain the ability to extradite data without asking for a user’s username or 9/12/21 – Log4J Vulnerbility Found 9/12/21 – Apache foundation involved advisory given 15/12/21 – Initial Patch Released 19/12/21 – Final 2.17.0 Released password and gain complete control of a system. This control would then allow an attacker to either gain control of a system via a reverse TCP shell or/and exfiltrate data out of an organisation, this also runs the risk that once the system is patched, the connection may continue to exist with the potential for even more damage to occur. This attack impacted large, java-based services such as Cloudflare, iCloud and Minecraft Java Edition. With an overall CVSS rating of 10, it was described as“a design failure of catastrophic proportion” (FREE WORTLEY, 2021) it was extremely devastating. Log4JShell, being a zero-day exploit, there were no mitigations initially that existed; however, a few workarounds allowed companies to maintain integrity during this time. One of these was to change the default configuration that was causing the issue; this would mean disabling the mentioned JNDI lookup. Workarounds were a temporary fix that many vendors and companies recommended (Fossa, 2021) until the mitigation of this vulnerability came about, which was to update the affected server or device to Log4j version 2.17.0 or higher, with the initial patch of 2.16.0 being affected by the mentioned DoS bug. This update to 2.17.0 mitigates the initial RCE exploit and the second DoS exploit mentioned. Mitigation and detection for smaller businesses can be achieved relatively easily by using software tools such as Nessus community edition or OpenVAS, which have both the ability to find Log4J on affected systems (Tenable, 2021)
Discussion
With over 3 billion devices that currently use Java, as stated by Java themselves, this vulnerability is an issue of catastrophic scale, furthermore there is 58% of organisations running on ‘legacy systems’ (GEORGESCU, 2021). This could mean that a substantial amount of these devices are vulnerable into the foreseeable future and may even remain unpatched until the day they are taken out of service if an update is not possible or feasible. The damage of Log4JShell was substantial, with many companies incurring enormous losses from data breaches and other issues caused by Log4J Shell. For example, Equifax alone offered to pay over 700 million dollars to settle actions that occurred from this vulnerability (team”, 2021). On top of the initial monetary damage, many companies will have their reputation damaged by such data breaches causing more distrust and scepticism within the company moving forward. On top of this damage, many people/companies affected by Log4J Shell may be entirely unaware that this is the case with Log4J being bundled with many large and small scale programs, making it much harder to eradicate this vulnerability. The future impact of this is likely to range depending on the device’s environment, with many large providers such as VMware and Microsoft fixing this exploit quickly within their mainstream products and services (VMWare, 2022) quelling the possibility of any more damage. On the flip side many unpatched systems being too small or legacy to warrant being fixed meaning that issues may occur further down the line.
Conclusion
In conclusion, Log4J can safely be regarded as one of the most devastating software vulnerabilities of recent times, and for some devices, this may never go away. The implications of this exploit show this goes to show just how reliant we are on particular out of date legacy systems and just how we patch these given systems. Furthermore, how this reliance on the legacy systems may need to be reviewed over time to avoid another such event. This analysis has shown that although this is an easy vulnerability to fix, it may not be economical or even achievable for many companies.
Leave a Reply