Confluence Server Webwork OGNL Injection (CVE-2021-26084): So schützt Akamai Sie vor Zero‑Day-Angriffen
Kürzlich hat Atlassian eine kritische RCE‑Schwachstelle (Remote Code Execution) in seinen Produkten Confluence Server und Confluence Data Center bekannt gegeben (CVE-2021-26084). Über diese Schwachstelle können nicht authentifizierte Nutzer auf anfälligen Servern beliebigen Code ausführen.
Das Kernproblem
Bei der Schwachstelle handelt es sich um eine OGNL Injection (Object-Graph Navigation Language) in einer der „Velocity“-Vorlagen (Vorlagen-Engine) von Confluence. Diese Vorlagen könnten durch Zugriff auf „/pages/createpage-entervariables.action“ und möglicherweise auch andere URLs ausgelöst werden. Einige PoC-Exploits (Proof of Concept) und unsere Daten lassen auf zusätzliche URLs schließen, obwohl wir sie nicht in der Analyse des ursprünglichen Patches sehen.
Über die Parameter „queryString“ und „linkCreation“ können Angreifer Java-Code injizieren. Abbildung 1 zeigt die Unterschiede zwischen den gepatchten und ungepatchten Versionen von Confluence Server.
Abb. 1: Das Zeichen $ wurde bei zwei Tags entfernt (https://github.com/httpvoid/writeups/blob/main/Confluence-RCE.md).
Unmengen schädlicher Aktivität
Die Komplexität dieses Exploits ist gering. Dementsprechend sind seit seiner Offenlegung am 25. August Dutzende PoC-Varianten entstanden. Und wie auch bei anderen Zero‑Day-RCEs wurden einige dieser PoCs in kürzester Zeit von verschiedenen Cyberkriminellen übernommen. Die erste Massenausspähung sowie die ersten Versuche, die Schwachstelle auszunutzen, wurden bereits am 28. August beobachtet.
Aktuelle Angriffskampagnen nutzen laut Berichten bereits die Cryptominer XMRig und Kinsing – neuere Varianten umfassen außerdem Tsunami-/Kaiten-DDoS‑Bots.
Während die Early Adopter unter den Angreifern die bestehenden PoCs einfach nur kopierten, erkennen wir mittlerweile in den Daten die natürliche Evolution der verschiedenen Varianten. Neben den zwei URLs, die ursprünglich veröffentlicht wurden, haben wir mittlerweile folgende Varianten gefunden:
/pages/createpage.action
/pages/createpage-entervariables.action
/pages/doenterpagevariables.action
/confluence/pages/createpage-entervariables.action
/confluence/pages/doenterpagevariables.action
/collaboration/pages/createpage.action
/jirapages/doenterpagevariables.action
/wiki/pages/doenterpagevariables.action
/-/media/pages/doenterpagevariables.action
/ae/en/pages;/createpage-entervariables.action
/link/lookup/pages;/createpage-entervariables.action
/pages;/createpage-entervariables.action
In diesen Beispielen sehen wir, dass Angreifer bereits eine bekannte Umgehungstechnik verwenden: Sie fügen dem Pfad Semikolons hinzu (die für die „Pfadparameter“ stehen). Viele Server, die Pfadparameter unterstützen, entfernen das Semikolon, bevor sie die URL aufrufen. So erreichen sie am Ende erfolgreich die anfällige Confluence-Ressource, wobei die URL-basierte Erkennung möglicherweise umgangen wird.
Wie in den Abbildungen 2 bis 4 gezeigt, haben wir in den letzten 24 Stunden folgende Werte auf unserer globalen Plattform verzeichnet:
Nahezu 2 Millionen Versuche wurden unternommen, diese Schwachstellen zu scannen und/oder auszunutzen.
88.378 eindeutige Hosts wurden angegriffen.
91 % der Angriffsaktivität zielten auf die Branchen Handel, Hightech, Fertigung und Finanzdienstleistungen ab.
Abb. 2: Am stärksten angegriffene Branchen
7.456 eindeutige IPs waren an diesen Versuchen beteiligt.
- Die Top 3 der an den Angriffen beteiligten ASNs waren AS4134, AS14061 und AS15169. Diese sind dafür bekannt, Ursprung vieler schädlicher Aktivitäten im Internet zu sein (obwohl sie von legitimen Cloudanbietern betrieben werden).
Abb. 3: Die Top 10 der schlimmsten Botnet‑ASNs laut Spamhaus
Die meisten Angriffe hatten ihren Ursprung in den USA (43 %), in China (15 %) und in Indien (10 %).
Abb. 4: Anzahl angreifender IP‑Adressen nach Land
Unsere bisherige Erfahrung mit ähnlichen Schwachstellen lässt uns vermuten, dass diese Kampagnen sehr wahrscheinlich ihr Arsenal erweitern und serverseitige Ransomware einsetzen werden. So könnten sie die Knowledge Base von Unternehmen sperren oder mit Geschäftsgeheimnissen handeln.
Abwehr von Zero‑Day-Angriffen
Der Schutz, den die Akamai-Plattform vor Web‑Exploits bietet, darunter auch vor zahlreichen Zero‑Day-Angriffen, profitiert von unserem Ökosystem zur Bedrohungserkennung. Darüber hinaus erhalten unsere Kunden dank der riesigen weltweiten Abdeckung Transparenz und Bedrohungsinformationen, die sich direkt in gesteigerte Sicherheit übersetzen lassen. Bei der Skalierung von Akamai ist „mehrstufige Verteidigung“ nicht nur ein Marketingbegriff. Unsere Lösung Client Reputation basiert auf Bedrohungsinformationen und bietet tiefer gehende Schutzmechanismen wie z. B. Aktivitätsscans und die Erkennung von Anomalien in Clientanfragen. Gleichzeitig führt Akamai Compliance‑Prüfungen für HTTP-Anfragen durch und stellt eine Sammlung allgemeiner KSD-Regeln (Kona Site Defender) bereit, um gefährliche Payloads zu identifizieren.
Die Abbildungen 5 und 6 zeigen Beispiele eines echten Angreifers, der eine böswillige HTTP-Anfrage (also eine Anfrage mit der Fähigkeit, Malware zu implementieren, um den Server zu übernehmen) sendet, die von den vorhandenen Regelsätzen erkannt wird.
Abb. 5: Von Akamai Adaptive Security Engine erkannt
Abb. 6: Von Kona Rule Set erkannt
Doch der Angriff wurde nicht nur anhand der Böswilligkeit seines Ursprungs erkannt, welche Akamai Client Reputation bekannt war (Webangreifer, Webscanner usw.), sondern auch durch die vorhandenen, allgemeinen Regeln. Sie zielen darauf ab, gefährliche Befehlsmuster zu erkennen, die von Angreifern verwenden werden.
Adaptive Security Engine erkennt und blockiert die aktuellen Exploits mithilfe bestehender Regeln in Command‑Injection- und XSS‑Angriffsgruppen.
· 950002 – CMD-Injection-Angriff erkannt (Betriebssystem-Befehle 4)
· 3000156 – CMD-Injection-Angriff erkannt (hochriskante PHP-Funktionen)
· 973307 – XSS-Angriff erkannt (Funktionen eval/atob)
· 3000081 – XSS-Angriff erkannt (Attributinjektion 2)
· 3000005 – CMD-Injection-Angriff erkannt (Betriebssystem-Befehl mit vollständigem Pfad)
Automatisierte Angriffsgruppen erkennt und blockiert die aktuellen Exploits mithilfe bestehender Regeln in Command‑Injection- und XSS‑Angriffsgruppen.
· 1000002 – XSS-Angriffsgruppe
· 1000005 – CMD-Injection-Angriffsgruppe
Kona Rule Set erkennt und blockiert die aktuellen Exploits mithilfe bestehender
Regeln in PHP‑Injection- und XSS-Angriffsgruppen.
· 958976 – PHP-Injection-Angriff (allgemeine Funktionen)
· 950109 – Multi-URL-Codierung erkannt
· 973307 – XSS-Angriff erkannt
· 3000081 – XSS-Angriff: Attributinjektion
Abschließende Bemerkung
Es ist das gleiche Muster, das wir bereits kennen: Cyberkriminelle brauchen nur einen Tag, um PoC-Exploits so anzupassen, dass daraus neue Zero‑Day-Schwachstellen entstehen. Mit einer Web Application Firewall als zusätzliche Schutzebene können Sie sich etwas wertvolle Zeit verschaffen, bis auf dem anfälligen Ziel ein Patch bereitgestellt wird. So können Sie das Risiko für Ihre Webanwendungen erheblich reduzieren.
Das Team von Akamai Threat Research überwacht das Internet auch weiterhin auf neue Exploit-Varianten und reagiert blitzschnell, indem Kunden Regelupdates und neue Empfehlungen bereitgestellt werden.