Log4j detecting an attack and compromise in logs
Written by Brian WagnerChief Technical Officer
Over the last two weeks, many have had flashbacks to 2012 when Heartbleed was released and everyone scrambled to fix broadly used OpenSSL. Due to their nature, some applications and services are so prolific that when a vulnerability is identified it causes massive issues for vendors and customers alike. The latest of this kind of issue is the Log4j vulnerability that has been dominating the press. No doubt you are here because you are concerned, the first concern probably being ‘could I have been hacked?’ the second ‘how would I know?’ and the third ‘how do I make sure I know when someone is poking around on my systems?’.
What is Log4shell?
For those that don’t know, let’s first start with the question: What is Log4j? In simple terms, it’s a logging module available in Java that a developer can enable when they are writing an application. It’s a great feature as it allows a user to see a record of what has taken place in an application, and most of the time its enabled for Governance, Risk and Compliance (GRC) purposes. ‘Log4j’ is the module that has the vulnerability that everyone is going on about and what hackers are looking for to exploit. ‘Log4shell’ is the name given to the vulnerability in the module, and it allows hackers to execute commands on vulnerable servers/machines, which is why it is so concerning. One of the most concerning things about this vulnerability is how easy it is to exploit a system, a single string of text and the right conditions internally and the attacker can execute their remote code on your systems.
KillchainAn attacker will do four main things to find and exploit this vulnerability:
- Scan the internet looking for a target that is vulnerable.
- Once discovered, attackers attempt to exploit the system running the vulnerable log4j module, a webserver, for example, by sending a simple string to exploit the vulnerability. The exploit string will include something similar to this:
- If step 2 is successful, the server will connect to an external LDAP server, the LDAP server can then be set to return a malicious script which the victim machine will run on the vulnerable server.
- Finally, the attacker will perform post compromise actions such as grab malware from an attackers server in order to take action or execute their objective (for instance, install ransomware or cryptocurrency miner).
As this vulnerability is in the wild and well understood the internet is a light with hackers and researchers looking for vulnerable systems. Making sure your business reduces its attack surface and does not expose services that are not required is vital in general but the most important think now is to make sure what you do have exposed is secure or access limited. The best way to quickly identify if you are vulnerable can be found below but a quick way is by scanning your system or checking file hashes and if you have a software inventory checking software versions.
The best advice is to patch to the latest version, as the behaviour is disabled by default. As of writing this blog the latest version of Log4j is 2.16.0. If you are using Log4j version 2.10.0 to version 2.14.0 and can't yet update, you can still set the flag manually:
Set formatMsgNoLookups=truewhen you configure Log4j by performing one of the following three actions:
- You can pass this JVM flag as an argument when you invoke Java:
- Alternatively, this feature may be set via environment variable:
- Or you can set this using the JVM arguments environment variable:
In some non-default configurations the vulnerability can still be exploitable even when this mitigation is in place so refer to the second CVE (CVE-2021-45046) for more details.
If you are using a version less than 2.10.0 you will need to do the following (because the flag that mitigates it above wasn’t added until 2.10.0), you can substitute a non-vulnerable or empty implementation of the class
org.apache.logging.log4j.core.lookup.JndiLookup in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application’s or stack's classloading documentation to understand this behaviour.
Other mitigations/defence in depth
As best practice suggests; we advocate that you should follow a defence in depth strategy as no single solution will protect you.
Our experts are the ones to trust when it comes to your cyber security
Get a quote today
If you are interested in our services, get a free, no obligation quote today by filling out the form below.