Log4j has recently created chaos in the IT world, and all security and operation engineers are busy patching their servers. No wonder that this is critical severity with a CVSS score of 10/10
This blog post will discuss why the entire security industry and the internet are in a frenzy over application security log4J.
What is Log4J
Log4J is a logging framework in Java; basically, those in development and security try to do good by logging things in their applications. It helps the developers and security analysts. Developers will use this as troubleshooting to find problems with the application, and security analysts will use this to find anomalies within that traffic. So let’s say you are developing an application and you want to do good by logging these kinds of things. Now, instead of writing all the code to support that, logging, that’s where log4j comes into play. It’s an open-source, free framework/library that you can wrap into your code-friendly and easy. And it does all the hard work for you.
How can an attacker exploit this
Unfortunately, a bug in this library allows for a vulnerability; we’re calling log4 shell. It will enable an attacker to send a message to a vulnerable application to execute potentially malicious code. We’ve seen reports of log4 shell being called the worst software vulnerability ever. It is widespread, and it can exploit many applications using this library. Millions of enterprise applications use Log4J; it includes cloud services and manufacturers, including even IoT devices. It’s literally on mars; the mars 2020 drone ingenuity is logging data with log4J. The vulnerability is so widespread. The fact that it’s difficult to pinpoint all the places it exists and the vulnerability being so extremely easy to exploit this perfect storm. All an attacker needs to do is prepare a malicious file, place it on a server they control, and send some modified text to a field logged by the application server. Once the server logs this string, log4J will retrieve and execute the malicious code from the attacker’s server. An attacker’s potential to control the application and move elsewhere within an organization’s network is very real. Does this mean that every piece of software using log4J is vulnerable to this exploit? Not at all. The caveat is that your application would need to be logging the field that an attacker could send that modified text to think of it like this, you have a Java application that allows your users to log in with an account. Do you want to log all the user names that are being attempted? Probably yes, But that’s also a great example of a field the attacker could use to submit that modified code instead of a username.
Steps need to be taken by security teams
The first step any organization should take is to assess their systems and determine where the library containing log4J is being used. It is more complicated than it sounds. Third-party vendors, open-source software, any application on your network can include an extension that uses a Java library; then having to drill down to whether those libraries using log4J can be a lot of work. Keep in Mind one of the reasons Java is so widespread is because it works everywhere. It isn’t limited to standard Windows domains or even a specific industry. After the difficult task of a security team or dev team discovering and confirming that it’s being used on their systems, they want to patch where possible immediately.
In some cases, they may run into a situation where they are at the vendor’s mercy to push out the patch. Now actually finding those instances can be accomplished in a variety of ways., Apache has released an update. Simply patching log4J is a little bit more complicated than doing a simple sweep across the network and calling it good Since Log4J is used as an open-source logging plugin for thousands. If not millions of applications, organizations will need to figure out what applications within their network are using it. Everyone should assume compromise if they have any Java applications as part of their environment monitoring. Network traffic is extra critical now to watch for any abnormal network activity. Enterprises will need to invest heavily in their incident response and security analytics if they intend to stay clear of becoming compromised. As more and more information is released, this vulnerability is vulnerable to evolve. Reports of a second sister vulnerability have already been released. This new vulnerability that has been released has been known to cause dDoS attacks.
Where can I find help and more information
Official CISA Guidance & Resources: https://github.com/cisagov/log4j-affected-db
Log4Shell detector: https://github.com/Neo23x0/log4shell-detector
List of Vulnerable Packages: https://github.com/NCSC-NL/log4shell/tree/main/software
Originally published at http://goldytech.wordpress.com on December 18, 2021.
