What is this vulnerability all about?

On December 11th, a critical vulnerability was found in the Apache Java library Log4J. All versions up to 2.14.1 are affected, which allows an anonymous attacker to execute arbitrary code on systems as long as the attacker can influence the log entries (e.g. when the accessed URL is protocolled).

Since the vulnerability is exploitable very easily, it is considered a high a risk issue. Utilities providing this attack are already very widely used, as our latest investigations are showing.

What systems are affected?

As it’s an almost default library, almost all Java-based applications are using it. As the code only gets executed when the vulnerable string is being written into the logs, this issue affects most likely web applications that e.g. automatically write the URL to the access logs. At the moment there are multiple (non-conclusive) lists referring to the vendor statements. Here are two that might help you:

In the meantime, there are already some tools that check for the usage of the given library and others that look for the special strings that might appear in the log files.

For our most prominent products you can find the vendors announcements here:

  • Fortinet: Multiple products affected, see FortiGuard for a detailed list
  • Nutanix: Multiple products affected. See Nutanix for a detailed list
  • Infoblox: NIOS 8.3.x – 8.6x are not affected. See Infoblox for more information
  • Seppmail: Not affected
  • macmon: macmon NAC -> new version with the fix is available. macmon SDP -> not affected

What Measures should be taken?

First thing is to make sure you know which services are affected and which are not (see above). Have an especially close look at the public-facing systems.

In case you have affected systems, check if the vendor already provides updates for these applications and install them.

In case there are no updates or you are unable to install the patch you should check the IDS/IPS configured on your firewall or web app protection solution. The Fortinet FortiGate already has a pattern for this vulnerability, though it is in “Log only” (aka. IDS) mode and does not block the requests (unless manipulated). The FortiWeb also includes matching patterns that should be applied automatically. Have a look at the guide below on how to configure your Fortinet products.

One way to limit the extent of the vulnerability is to prevent any outbound connections from the potentially affected devices. Keep in mind this does not prevent an attacker to execute code but blocks and prevents any command and control (C2) connections. In a public-facing system, this should be the default in any case.

How can I detect an attack?

Have a look at your IDS/IPS logs, most likely you will already find some entries as multiple organizations are running heavy scans to see what devices are vulnerable. An attempted attack does not mean it was successful though as the system needs to be vulnerable.

If you see that there is an ongoing or there was an attack against a vulnerable system, we suggest you to check for outbound connections and do a Yara scan using the utilities in Github.

Where can I get more information?

How to check and enable the IPS Pattern?

On a FortiGate

BTW.: In case you are using FortiGates, please consider upgrading to the latest release of  6.0.x, 6.2.x 6.4.x or 7.0.x trail. Which, as of today is: 6.0.14, 6.2.10, 6.4.8 or 7.03as it also contains various major security patches

Make sure your FortiGate firewall has the IPS pattern Version 19.215 or later. In general, this is updated automatically.

To verify you have the signature, open up „Security Profiles“ > „IPS Signatures“ and search for „Apache.Log4j.Error.Log.Remote.Code.Execution“:

FGT Signatures

As you see, the policy is set to action „Pass“ which detects it and alerts but lets the request still pass. As usual with early IPS rules (since it is still beta in this IPS version), you need to curate the Fortinet IPS patterns enabled in your network. In order to set it to block you need to override this action in the Intrusion Prevention Profile. To do so open up „Security Profiles“ > „Intrusion Prevention“ and in there open up the policy you would like to edit. In the IPS Signatures and Filters box click „Create New“. In the overlay, choose „Signature“, set the action to „Block“ and search for the IPS signature „Apache.Log4j.Error.Log.Remote.Code.Execution“. Select the entry and add it with the button „Add Selected“.

Once created, you need to add this IPS Security Profile to the inbound webserver rule allowing internet traffic to pass on to your affected webserver.

On a FortiWeb

Make sure you have the Web Security Pattern Version 0.00305 or later (generally updated automatically)
On the FortiWeb open up „Web Protection“ > „Known Attacks“ > „Signatures“ and open up the signature policy you have enabled for your web service.

On the new page open up the signature details.

In the new window filter for the CVE-2021-44228:

When it’s enabled you’re all set. Make sure to set the action to „Alert & Deny“ to get notified when an attack is detected:

For more information, contact us at support@sidarion.ch or +41 43 544 10 67.