Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Ivar
New Contributor

CVE-2021-44228 Apache LOG4J vulnerability

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?

1 Solution
Carl_Windsor_FTNT

PSIRT advisory on impacted products can be found here:

 

https://www.fortiguard.com/psirt/FG-IR-21-245

Dr. Carl Windsor Field Chief Technology Officer Fortinet

View solution in original post

44 REPLIES 44
AlexC-FTNT

The action is "Allow" for the moment, while undergoing extensive testing on our side in order to avoid false positives. Manually changing to "Block" should be done under supervision, monitoring valid traffic not to be blocked. 


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
AlexC-FTNT
Staff
Staff

We have developed an IPS signature, Apache.Log4j.Error.Log.Remote.Code.Execution, with VID 51006 to address this threat. This signature has been released in IPS package (version 19.215). Please note that this is an emergency release, so the default action for this signature is set to pass at the moment. If you want this blocked, please change the action in the IPS profile. 

 

For protection against this vulnerability, make sure that the IPS definition version is the one above. You can verify in System > FortiGuard, where you can also trigger an automated update. Once updated, alter the ips profile and change the action for this signature to block. 


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
indi81
New Contributor II

So, is there any option to automatically set these as Action: block instead of the default Pass? It's the same story as with Hafnium.

 

I think the majority would prefer a smaller incident/faulty service before risking a major breach. Atleast give the option. 

AlexC-FTNT

The option exists, but works the other way. I did not make this choice of default Action, but I understand it from a business-user perspective: a/any firewall should not block legitimate traffic from one day to the next just after some automated update. That may be difficult to isolate and cause revenue loss. The SysAdmin should be aware of the latest attacks and select the appropriate signature action - knowing that action may cause some false positives.


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
J13224
New Contributor III

Your risk analysis needs to be reevaluated.  What is the bigger threat to revenue.  A possible edge case bad ips pattern file that could be easily detected in logs or a trivial full system access compromise of thousands of different products on millions of systems that are globally accessible. I pay Fortinet to be aware of the latest attacks so I don't have to panic when I wake up in the morning to the news.

FnUser
New Contributor II

Doesn't seems that signature is doing anything, don't see any violations on testing.

FnUser
New Contributor II

Does it work for anybody?

indi81
New Contributor II

Yes, but only for HTTP.

FnUser
New Contributor II

what payload did you use for testing?

indi81
New Contributor II

On Fortigate, we had both active attacks logged on HTTP and tested with https://log4shell.huntress.com/

 

Nothing showed in the logs for HTTPS. We just tested with adding the payload as plain querystrings.

 

The FortiADC didn't seem to have any IPS or known attack signature for it so we couldn't see anything there. 

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors