Artikel kostenlos lesen

Serientäter : Illegales Krypto-Mining durch Angriffe auf unsichere Deserialisierung liegt im Trend

Bei der Beobachtung neuer Schwachstellen in Webanwendungen hat die Forschungsgruppe von Imperva unlängst mindestens vier große Schwachstellen aufgrund von unsicherer Deserialisierung identifiziert, die im vergangenen Jahr öffentlich wurden.

Lesezeit 5 Min.

Von Gilad Yehudai und Nadav Avital, Tel Aviv (IL)

Analysen zeigen, dass sich die Zahl der Deserialisierungsangriffe im letzten Quartal 2017 monatlich im Durchschnitt vervierfacht hat. Das macht diese Bedrohung zu einem ernsthaften Sicherheitsrisiko für Webanwendungen. Schlimmer noch: Viele dieser Angriffe werden jetzt mit dem Ziel gestartet, KryptoMining-Malware auf anfälligen Webservern zu installieren, was deren CPU-Belastung drastisch erhöht. Doch was genau sind Schwachstellen durch unsichere Deserialisierung, wie nehmen die Angriffe auf solche Schwachstellen zu und wie gehen Angreifer dabei vor?

Serialisierung

Zweck der Serialisierung ist es, ein Objekt zu bewahren, damit es auch über die Laufzeit der lokalen Maschine (bzw. der akt. Ablaufumgebung) hinaus bestehen bleibt, mit der es erstellt wurde. Dazu wird ein „lebendes“ Objekt (eine Struktur und/oder ein Zustand), beispielsweise ein Java-Objekt, in ein Format umgewandelt, das sich über Netzwerke übertragen, in den Arbeitsspeicher oder auf eine Festplatte schreiben lässt. Bei der Deserialisierung wird dieses Format dann wieder in ein lauffähiges Objekt zurückverwandelt.

Um ein Beispiel zu geben: Wenn jemand von einem Bankautomaten Geld abhebt, werden die Informationen zum Kontoinhaber und der erforderlichen Operation in einem lokalen Objekt gespeichert. Bevor der Automat dieses Objekt an den Hauptserver überträgt, wird es serialisiert, damit die erforderlichen Operationen ausgeführt und genehmigt werden können. Der Server deserialisiert das Objekt dann, um die Transaktion abzuschließen.

Arten der Serialisierung

Es gibt viele Arten von Serialisierung, abhängig vom Objekt, das serialisiert wird, und dem verfolgten Zweck – das beginnt bei so grundlegenden Formaten wie CSV (CommaSeparated Values) und reicht bis zu spezifischen Verfahren bestimmter Programmiersprachen und Architekturen. So wird beispielsweise in Java ein Objekt in eine kompakte ByteStrom-Repräsentation konvertiert (Serialisierung), die anschließend dann wieder in eine Kopie des ursprünglichen Objekts umgewandelt werden kann (Deserialisierung).

Andere Arten der Serialisierung sind zum Beispiel die Konvertierung eines Objekts in ein hierarchisches Format wie JSON oder XML. Der Vorteil ist dabei, dass derart serialisierte Objekte als normaler Text gelesen werden können, statt als ByteStrom vorzuliegen.

Deserialisierungs-Schwachstellen

In den Top-10 Security-Risks 2017 des Open Web Application Security Projects (OWASP) liegt unsichere Deserialisierung bereits auf dem achten Platz [1] – mit Recht, wie auch ein Imperva-Blogpost zur Entwicklung der Schwachstellen in Webanwendungen argumentiert hat [2]. Denn allein 2017 wurden vier gravierende neue Sicherheitslücken durch unsichere Serialisierung öffentlich – zumeist in Java (siehe Tab. 1, vgl. Abb. 2). Insgesamt gab es seit 2015 fast siebzig Schwachstellen (Common Vulnerabilities and Exposures, CVEs), die mit unsicherer Deserialisierung zusammenhängen – eine vollständige Liste enthält der Blogpost [3], der diesem Beitrag zugrunde liegt.

Um die Tragweite dieser Schwachstellen zu verstehen, hat man Angriffe aus den Monaten Oktober bis Dezember 2017 analysiert, bei denen versucht wurde, eine unsichere Deserialisierung auszunutzen. Eine wichtige Beobachtung war dabei der starke Anstieg von Angriffen auf unsichere Deserialisierung in den letzten Wochen des Jahres (vgl. Abb. 1).

Die meisten Attacken verwendeten dabei neben der unsicheren Deserialisierung keine anderen Angriffsvektoren. Wie festgestellt wurde, versuchte jeder Angreifer, verschiedene Sicherheitslücken in diesem Feld auszunutzen, doch die vier in Tabelle 1 erwähnten CVEs waren am häufigsten vertreten.

Die meisten „in the Wild“ beobachteten Angriffe hängen mit der Byte-Strom-Serialisierung von Java-Objekten zusammen. Darüber hinaus wurden aber auch einige Angriffe registriert, die mit der Serialisierung in XML und anderen Formaten zu tun haben (vgl. Abb. 2).

Tabelle 1

Tabelle 1: Schwachstellen, die mit unsicherer Deserialisierung in Zusammenhang stehen

Abbildung 1

Abbildung 1: Angriffe auf unsichere Deserialisierung im Verlauf des letzten Quartals 2017

Abbildung 2

Abbildung 2: Verteilung der Schwachstellen auf verschiedene Serialisierungsformate

Konkrete Angriffe

In einem Angriff versuchten Angreifer, die Schwachstelle CVE-2017-10271 auszunutzen: Die Payload wurde dazu im Body eines HTTP-Requests gesendet, und zwar mithilfe eines serialisierten Java-Objekts in XML-Repräsentation. Dass es sich dabei um ein Java-Array handelt, ließ sich aus einer hierarchischen Struktur der Parameter mit dem Suffi x „java/void/array/void/string“ ersehen.

Der Angreifer versuchte, mit dessen Inhalten auf dem angegriffenen Server ein Bash-Skript auszuführen. Dieses sendet per „wget“ einen HTTP-Request, um ein Shell-Skript herunterzuladen, das durch die Dateierweiterung .jpg als Bilddatei getarnt war, und dieses anschließend auszuführen.

Bei der Untersuchung dieses Angriffs-Befehls zeigten sich einige interessante Details:

  • Die Shell- und wget-Befehle lassen darauf schließen, dass die gefundene Payload auf Linux-Systeme abzielt.
  • Die Verwendung einer Bilddateiendung soll dazu dienen, Sicherheitsmechanismen zu umgehen.
  • Das wget-Kommando wurde mit dem Parameter „-q“ (quiet) ausgeführt. Das bedeutet, dass „wget“ keinen Output in der Konsole erzeugt, wodurch schwieriger zu erkennen ist, dass überhaupt ein solcher Request abläuft.
  • Sobald das heruntergeladene Skript ausgeführt wird, wird der betroffene Server mit einer Krypto-Mining-Malware infiziert, die versucht, Monero zu schürfen (eine Krypto-Währung, vergleichbar mit Bitcoin).

Auch eine weitere konkrete Attacke versuchte, dieselbe Schwachstelle auszunutzen, zielte mit ihrer Payload jedoch auf Windows-Server – dabei wurden cmd.exe und Powershell-Befehle verwendet, um die Malware herunterzuladen und auszuführen.

Abbildung 3 zeigt ein anderes Beispiel: Dieser Angriff versucht, eine Deserialisierungsschwachstelle mit einem serialisierten Java-Objekt auszunutzen (vgl. http://seclists.org/osssec/2016/q1/461). Die „schlechte“ Kodierung ist dabei ein Artefakt der Java-Serialisierung, in der das Objekt als Bytestrom dargestellt wird.

Dennoch kann man ein Skript im Klartext erkennen (in der Abbildung gelb markiert): „${IFS}“ ist dabei eine Variable, die einen internen Feldtrenner definiert – wobei es sich in diesem Fall nur um einen Leerraum (Space) handelt. Die Variable wurde wahrscheinlich anstelle eines Leerraums verwendet, um die Payload schwerer erkennbar zu machen. Genau wie im ersten beschriebenen Beispiel richtet sich auch hier ein Bash-Skript gegen Linux-Server und versucht, mit „wget“ einen HTTP-Request zu senden, um einen KryptoMiner herunterzuladen.

Abbildung 3

Abbildung 3: Angriffsbeispiel auf eine Deserialisierungs-Schwachstelle in Java

Weitere Angriffsvektoren

Der gemeinsame Nenner all dieser Attacken ist, dass die Angreifer versuchen, eine Schwachstelle mit unsicherer Deserialisierung auszunutzen, um Server mit einer Krypto-Mining-Malware zu infizieren. Unsichere Deserialisierung ist jedoch natürlich nicht die einzige Methode, um dieses Ziel zu erreichen.

Abbildung 4 illustriert ein Beispiel für eine andere Angriffs-Payload, die sich diesmal im Content-Type-Header versteckt. Diese Attacke versucht CVE-2017-5638 auszunutzen, eine bekannte Remote-Code-Execution-(RCE)-Schwachstelle in Apache Struts, die im März 2017 veröffentlicht wurde (siehe auch [4]).

Zum Zeitpunkt der Veröffentlichung dieser Sicherheitslücke sah man keine Anzeichen für Krypto-Miner in den Payloads von Angriffen, die sich gegen diese CVE richteten – die meisten Attacken dienten lediglich der Erkundung.

Beim zuletzt beobachteten Angriff ähnelt die Payload (in der Abbildung gelb markiert) jedoch stark dem Schadcode aus dem vorhergehenden Beispiel: Über denselben Remote-Server und mit genau dem gleichen Skript soll sie den betroffenen Server mit Krypto-Mining-Malware infizieren.

Diese „alte“ Angriffsmethode mit neuer Payload deutet auf einen neuen Trend der Cyber-Kriminellen hin: Angreifer versuchen offenbar, alle verfügbaren Schwachstellen auszunutzen, um anfällige Server in Krypto-Miner zu verwandeln und mit ihrer „Arbeit“ einen schnelleren „Return on Invest“ (ROI) zu erzielen.

Abbildung 4

Abbildung 4: Beispiel für eine Attacke via Apache-Content-Type-Header

Empfehlung

Angesichts zahlreicher neuer Schwachstellen aus 2017, die mit unsicherer Deserialisierung zusammenhängen, sowie der Aufnahme in die OWASP Top-10 der Sicherheitsrisiken muss damit gerechnet werden, dass 2018 weitere Sicherheitslücken dieser Art öffentlich werden. Unternehmen, die betroffene Server verwenden, sollten unbedingt die jeweils neuesten Patches einspielen, um bekannte Lücken möglichst zeitnah zu schließen.

Eine Alternative zum manuellen Patchen aller betroffenen Systeme kann dabei unter Umständen ein „virtuelles Patchen“ sein, wie es verschiedene Web-Application-Firewalls (WAFs) oder andere Sicherheitssysteme ermöglichen.

Gilad Yehudai ist Algorithm-Developer, Nadav Avital ist Security-Research-Team-Leader bei Imperva.

Diesen Beitrag teilen: