There is a critical vulnerability has been identified within the Apache Log4J framework which is used by millions of devices running online services. It is a Java-based logging framework part of the Apache Logging Services, a project of the Apache Software Foundation.
What are the implications of the Log4J vulnerability?
The bug in the Apache Log4j module will allow an attacker to execute arbitrary code on any system that uses Log4j to write logs.
How bad is this?
This is a very critical bug that should not be ignored until it is patched. The bug is easily exploitable by someone with limited knowledge of the system.
What we need to understand…
We need to understand that this vulnerability is not going to be prevented by having authentication in place. This is a pre-authentication exploit where the attacker does not need to be authenticated to launch an attack.
What you should do to mitigate this?
The first thing is to make sure all the Internet-facing systems are checked and verified of this vulnerability. One should not negate the fact about Legacy Applications and systems which has a higher chance of using this Log4j java module.
Then move on to the outbound traffic. Make sure you can limit the outbound traffic to the bare minimum. It is also a good idea to do an audit on the outbound traffic to make sure whether such traffic needs to be allowed.
Then, make sure you address every single medium which talks to the Internet. You also need to make sure not to negate any services such as SaaS, PaaS, or any other cloud-hosted service.
Endpoints need to be patched as well as all the main systems. Do not ignore or negate from patching endpoints and if there is no patch available, I would recommend uninstalling the application until a patch has been released by the vendor.
One thing I would highlight is to shorten the patch window to hourly than some ridiculous weekly patch cycle. It is also a time to force the users to update the Endpoints via Group Policy or a similar mechanism.
I would also recommend educating all the users to update their work, personal, BYOD devices as soon as possible. It would be a good idea to organize some educational sessions to get the devices patched.
It is also a good idea to educate them to patch their personal devices along with their corporate devices. This is because a large number of workers are currently working from home due to the pandemic, a compromised home network of a remote user will put your company at risk.
Can we implement a perimeter-based technology such as IPS/WAF to block keywords to tackle this vulnerability?
The answer is simply a big No. I have seen several initial mitigations was taken in this direction. However, an attacker can easily obfuscate payload and bypass the security controls. This could be a broken solution, but my recommendation is to concentrate on patching every single affected system.
And finally…
My take on this vulnerability, this is still the tip of the iceberg. It is not going to go anywhere since Java is one of the common programming language been used in the past 30 years. We are not going to see this vulnerability go away in a matter of days/months or even years until we patch.
It is also important to involve all the stakeholders and replace, uninstall or to decommission all the unsupported or retired hardware, devices and software.
Where is the CVE?
The CVE can be found here.
What are the Apache Products affected by Log4J?
All the affected Apache Products can be found here
Patching Information
If you are looking for a patch to mitigate Log4J vulnerability, then you need to download version 2.16.0. This version has been released without the vulnerability.
log4j-core.jar is available to be downloaded via here.
How to identify an installed Log4J version on Linux
I would recommended running a search on log4j2 to verify the vulnerable version.