17. Juni 2021

Ausnutzung von Schwachstellen in Java Deserialisierung

Im Certified Security Operations Center (CSOC) wurde ein Angriffsversuch mit der Meldung ‚ET EXPLOIT Serialized Java Object Calling Common Collection Function‘ identifiziert. Die Angreifer zielten auf die Schwachstelle CVE-2017-12149 in der Java Deserialisierung ab, um sich einen Remote-Zugriff zu verschaffen.

Die Deserialisierung ist ein Vorgang, bei dem aus einer Byte-Folge erneut ein programmierbares Objekt erzeugt wird. In diesem Kontext handelte es sich um einen Java Deserialisierungsfehlertypen, der im Filter ‚ReadOnlyAccessFilter‘ der ‚HttpInvoker-Komponente‘ von JBoss der Versionen AS 5.x und AS 6.x existiert. Der Filter versucht, ohne Sicherheitsüberprüfung den Datenstrom von einem Client zu deserialisieren, was einem Angreifer die Ausführung von beliebigem Remote Code auf dem Server ermöglicht. Bei diesem Angriffsversuch wurde der POST-Befehl ‚POST /invoker/readonly HTTP/1.1\r\n‘ verwendet. Daraufhin folgten vom System des Kunden die Fehlermeldungen „301 Moved Permanently“, „HTTP/1.1 501 Not Implemented“ und „HTTP/1.1 302 Document Moved“, womit die Verbindung unterbunden und anschließend mit Reset beendet wurde.

Leider ist solch ein Angriff für Cyberkriminelle recht einfach durchzuführen: Es muss lediglich eine ser-Datei mit Payload konstruiert und die Binärdatei mithilfe von curl an die invoker/readonly-Seite des Zielservers versendet werden. Im Anschluss kann der Angreifer den in der Payload angegebenen Befehl ausführen, um die Kontrolle über den Computer zu erlangen.

In diesem Fall wurde unser Kunde durch unser Blue-Team über die permanenten Angriffsversuche informiert, sodass die IP des Angreifers in der Firewall des Kunden gesperrt werden konnte, um schlimmeres zu verhindern. Die Erfolgswahrscheinlichkeit des Angriffs war in diesem Fall sehr hoch, da eine veraltete Version von JBoss verwendet wurde.

Unsere Handlungsempfehlungen:

Installieren Sie die neueste Version von Java und insbesondere JBoss.
Entfernen Sie die ‚http-invoker.sar‘ Komponente, falls diese nicht verwendet wird.
Fügen Sie den folgenden Code in das security-constraint-Tag der web.xml Datei unter ‚http-invoker.sar‘ ein, um den Zugriff auf die http-invoker-Komponente zu sichern: <url-pattern>/*</url-pattern>