
PCRE-Regex-Abgleich von Log4Shell-CVE-2021-44228-IoCs in Ihren Logs
Der folgende RegEx wurde geschrieben, um Indikatoren einer Log4Shell-Ausnutzung (CVE-2021-44228 und CVE-2021-45046) zu erkennen.
Wenn Sie eine Version von vor dem 21.12.2021 verwenden, wird dringend empfohlen, zu testen und zu aktualisieren.
Ich habe einige Eigenheiten entfernt und die Leistung verbessert.
Der RegEx zielt darauf ab, PCRE-kompatibel zu sein, sollte aber auch mit re2 und möglicherweise weiteren RegEx-Engines laufen.
RegEx:```regex (?im)(?:^|[\n]).?(?:[\x24]|%(?:25%?)24|\u?0(?:44|24))(?:[\x7b]|%(?:25%?)7b|\u?0(?:7b|173))[^\n]?((?:j|%(?:25%?)(?:4a|6a)|\u?0(?:112|6a|4a|152))[^\n]?(?:n|%(?:25%?)(?:4e|6e)|\u?0*(?:4e|156|116|6e))[^\n]?(?:d|%(?:25%?)(?:44|64)|\u?0*(?:44|144|104|64))[^\n]?(?:[i\x{130}\x{131}]|%(?:25%?)(?:49|69|C4%(?:25%?)B0|C4%(?:25%?)B1)|\u?0(?:111|69|49|151|130|460|131|461))[^\n]?(?:[\x3a]|%(?:25%?)3a|\u?0(?:72|3a))[^\n]?((?:l|%(?:25%?)(?:4c|6c)|\u?0*(?:154|114|6c|4c))[^\n]?(?:d|%(?:25%?)(?:44|64)|\u?0*(?:44|144|104|64))[^\n]?(?:a|%(?:25%?)(?:41|61)|\u?0*(?:101|61|41|141))[^\n]?(?:p|%(?:25%?)(?:50|70)|\u?0*(?:70|50|160|120))(?:[^\n]?(?:[s\x{17f}]|%(?:25%?)(?:53|73|C5%(?:25%?)BF)|\u?0(?:17f|123|577|73|53|163)))?|(?:r|%(?:25%?)(?:52|72)|\u?0(?:122|72|52|162))[^\n]?(?:m|%(?:25%?)(?:4d|6d)|\u?0*(?:4d|155|115|6d))[^\n]?(?:[i\x{130}\x{131}]|%(?:25%?)(?:49|69|C4%(?:25%?)B0|C4%(?:25%?)B1)|\u?0(?:111|69|49|151|130|460|131|461))|(?:d|%(?:25%?)(?:44|64)|\u?0*(?:44|144|104|64))[^\n]?(?:n|%(?:25%?)(?:4e|6e)|\u?0*(?:4e|156|116|6e))[^\n]?(?:[s\x{17f}]|%(?:25%?)(?:53|73|C5%(?:25%?)BF)|\u?0(?:17f|123|577|73|53|163))|(?:n|%(?:25%?)(?:4e|6e)|\u?0(?:4e|156|116|6e))[^\n]?(?:[i\x{130}\x{131}]|%(?:25%?)(?:49|69|C4%(?:25%?)B0|C4%(?:25%?)B1)|\u?0(?:111|69|49|151|130|460|131|461))[^\n]?(?:[s\x{17f}]|%(?:25%?)(?:53|73|C5%(?:25%?)BF)|\u?0(?:17f|123|577|73|53|163))|(?:[^\n]?(?:[i\x{130}\x{131}]|%(?:25%?)(?:49|69|C4%(?:25%?)B0|C4%(?:25%?)B1)|\u?0(?:111|69|49|151|130|460|131|461))){2}[^\n]?(?:o|%(?:25%?)(?:4f|6f)|\u?0*(?:6f|4f|157|117))[^\n]?(?:p|%(?:25%?)(?:50|70)|\u?0*(?:70|50|160|120))|(?:c|%(?:25%?)(?:43|63)|\u?0(?:143|103|63|43))[^\n]?(?:o|%(?:25%?)(?:4f|6f)|\u?0*(?:6f|4f|157|117))[^\n]?(?:r|%(?:25%?)(?:52|72)|\u?0*(?:122|72|52|162))[^\n]?(?:b|%(?:25%?)(?:42|62)|\u?0*(?:102|62|42|142))[^\n]?(?:a|%(?:25%?)(?:41|61)|\u?0*(?:101|61|41|141))|(?:n|%(?:25%?)(?:4e|6e)|\u?0(?:4e|156|116|6e))[^\n]?(?:d|%(?:25%?)(?:44|64)|\u?0*(?:44|144|104|64))[^\n]?(?:[s\x{17f}]|%(?:25%?)(?:53|73|C5%(?:25%?)BF)|\u?0(?:17f|123|577|73|53|163))|(?:h|%(?:25%?)(?:48|68)|\u?0(?:110|68|48|150))(?:[^\n]?(?:t|%(?:25%?)(?:54|74)|\u?0*(?:124|74|54|164))){2}[^\n]?(?:p|%(?:25%?)(?:50|70)|\u?0*(?:70|50|160|120))(?:[^\n]?(?:[s\x{17f}]|%(?:25%?)(?:53|73|C5%(?:25%?)BF)|\u?0(?:17f|123|577|73|53|163)))?)[^\n]?(?:[\x3a]|%(?:25%?)3a|\u?0(?:72|3a))|(?:b|%(?:25%?)(?:42|62)|\u?0*(?:102|62|42|142))[^\n]?(?:a|%(?:25%?)(?:41|61)|\u?0*(?:101|61|41|141))[^\n]?(?:[s\x{17f}]|%(?:25%?)(?:53|73|C5%(?:25%?)BF)|\u?0(?:17f|123|577|73|53|163))[^\n]?(?:e|%(?:25%?)(?:45|65)|\u?0*(?:45|145|105|65))[^\n]*?(?:[\x3a]|%(?:25%?)3a|\u?0(?:72|3a))(JH[s-v]|[\x2b\x2f-9A-Za-z][CSiy]R7|[\x2b\x2f-9A-Za-z]{2}[048AEIMQUYcgkosw]ke[\x2b\x2f-9w-z]))
## Fähigkeiten
Inzwischen sollte dieser RegEx den Exploit abdecken, unabhängig davon, ob er:
- Nur protokolliert wurde
- Ohne Beachtung der Groß-/Kleinschreibung auftritt (auch in allen unterstützten Kodierungen)
- URL-kodiert ist
- Rekursiv URL-kodiert ist
- Mit Unicode-Kodierung
- Mit Oktal-Kodierung
- Base64-kodiert (rudimentär)
### Hintergrund
Das Ziel ist eine RegEx, die einen vernünftigen Kompromiss darstellt zwischen dem Erkennen möglichst vieler Angriffsversuche und einer vertretbaren Anzahl von Fehlalarmen.
Der APT-Angreifer wird bei Bedarf einen Weg darum herum finden, aber weniger ausgefeilte Angriffe lassen das Warnlicht aufleuchten.
Warum eine (einzige) RegEx: Weil sie einfach über die CLI oder in einem SIEM ausgeführt werden kann, ohne zusätzliche Werkzeuge. Wenn Werkzeuge ausgeführt werden können, dann tu das, sie existieren.
Die Länge der RegEx ist weniger ein Problem als ihre Performance. Trotz der Länge sollte die RegEx bei durchschnittlichen Logdaten akzeptabel schnell ausführbar sein.
### Aufruf zum Mitmachen
Ich möchte es schwer machen, einen Angriff in realen Szenarien zu verbergen.
Falls diese RegEx etwas nicht erkennt, das du in freier Wildbahn gesehen hast oder von dem du zeigen kannst, dass es ausnutzbar ist, erstelle bitte ein Issue.
Es ist bekannt, dass man die RegEx leicht umgehen kann, indem man verschiedene Teile des Angriffsmusters mit Base64 kodiert. Allerdings wird dies akzeptiert, da `base64` es noch nicht endgültig in eine offizielle Log4j-Version geschafft hat. ([LOG4J2-2446](https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-2446))
### Werkzeuge