CVE-2021-44228 Apache LOG4J vulnerability

[Ivar]

Would appreciate a response from Fortinet regarding the Apache log4 vulnerability if any Fortinet product

is affected.

Any information regarding updated IPS signature for CVE-2021-44228?

[jsexton]

Thank you. I'm still confused, though. EMS reports: "Apache.Log4j.Error.Log.Remote.Code.Execution has been blocked because it tried to receive network data., An unknown application" which is not very helpful. I'm seeing this on several PCs. None have apache or log4j installed. None are exposed directly to the internet, so I'm unclear how an attacker could even be reaching the machine. Is there anyway to get further detail about what is triggering the alert?

[Carl_Windsor_FTNT]

See:  CVE-2021-44228 — Apache Log4j Vulnerability | Fortinet for more info.

There are many ways this could have been triggered e.g. browsing to a web site with this set in the headers.  Initiating a connection with these headers outbound.  Also there are other more esoteric methods being used to exploit this e.g. 

Lets take a real world PC OS example:

• Laptop connects to a WiFi SSID containing the JNDI string
• Laptop shares this string to the OS vendor to cache known Wifi networks
• OS Vendor logs this info and triggers vulnerability (OS providers devce connects out)

Key points here:

• The initial device  that is used to trigger the vulnerability doesn't need to be vulnerable or run Log4j itself.
• The attack doesn't need to be just in HTTP, if it is a string that gets logged (e.g. the SSID, SMS or anything else) it can trigger the vulnerability.  This is why this could be seen in weird and wonderful edge case places for some time to come.
• Fortinet IPS will block the spray and prey of this attack that is taking place and trigger if it sees the attack regardless of whether or not the backend is vulnerable.

[jsexton]

OK, so is there any way to view what exactly is triggering this? We are responding to dozens of these alerts now, and without a picture of what's going on, I can't justify pulling and reimaging computers, especially since that may not even be the source. Surely there is a more detailed log available.

[Carl_Windsor_FTNT]

This is network level detection so we are not logging the actual application that is triggering this.  I recommend opening a ticked to see if there is more detail we can pull out of this for you. (DM me the ticket ID and I will have someone take a look)

Key thing here though is, if you are sure the system does not have vulnerable Log4j, and we blocked this exploit, you do not need to re-image the system.  Expect to see many more of these going forwards.  To be safe I would monitor systems for unexpected outbound LDAP connections which is a better indicator of exploitation.

[Carl_Windsor_FTNT]

Some additional debugging info from the FCT team if you want to dig into this further.  It does require to reproduce the issue so no use after the fact.

1. register FCT to EMS
2. after profile received, do the following changes to registry on the FCT:
[HKEY_LOCAL_MACHINE\SOFTWARE\Fctlog\fortifws]
"flag"=dword:000031ff
"size"=dword:00000200
3. wait 10 seconds to make sure the above settings take effect.
4. reproduce the issue
5. run diagnostic tool in the FCT GUI > About page.,  which will include all debug log.

Please note:
1. the FW log file will rotate when reaching 512M, and it will increase quickly, so please run diagnostic tool as early as possible.
2. open FW log (FCT\logs\trace\fortifws*.log) to check if it contains "log4j" to ensure it contains the correct info
3. the configuration in HKEY_LOCAL_MACHINE\SOFTWARE\Fctlog\fortifws could be re-written when any setting changes on EMS, please make sure flag is 0x31ff when starting diagnostic tool.

Debug log will capture all the packets.