Forum Discussion
NimbostratusLog4j iRule mitigation as described in K59329043 - which encoding is the regex using ?
MVPThe 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
CarloMunHi
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
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
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
Yes, , that pretty much sums it up.
