Ende letzten Jahres hat der Cloud-Hoster AWS recht schnell auf die Log4J-Lücke reagiert. Allerdings konnten Forscher nun aber gravierende Fehler in den damals eingespielten Hotpatches zeigen.
Schon ziemlich früh und viel schneller als die meisten anderen Konkurrenten hat der Cloud-Hoster Amazon Web Services (AWS) im Dezember 2021 auf die auch als Log4Shell bekannte Sicherheitslücke (CVE-2021-44228) in der Java-Bibliothek Log4J reagiert und dagegen einen sogenannten Hotpatch veröffentlicht.
Die zu Palo Alto Networks gehörenden Sicherheitsforscher von Unit 42 berichten aber nun, dass auch dieser Hotpatch selbst wiederum gravierende Sicherheitslücken mitgebracht hatte.
Die fehlerhaften Patches kamen als RPM- und DEB-Pakete
Die Hotpatches von AWS wurden als RPM oder DEB-Paket über einen Service in Amazon Linux, für Kubernetes-Cluster sowie auch für den eigenen Container-Host Bottlerocket verteilt.
Allerdings seien die so aufgespielten Patches laut Unit 42 aber fehlerhaft und ließen sich auch dazu missbrauchen, zum Beispiel aus Containern auf den Host auszubrechen oder die eigenen Rechte zu erweitern und damit Root-Rechte zu erlangen.
Rechteausweitung durch das Updaten
Wie es zu den fehlerhaften Hotpatches von AWS kommen konnte, ist im Grunde leicht zu verstehen, denn laut den Forschern hab der Update-Dienst nach Binärdateien mit dem Namen “java” gesucht, um dessen Version abzufragen. Die Binärdatei wurde anschließend ein zweites Mal aufgerufen, um im laufenden Betrieb das eigentliche Hotpatch-Update einzuspielen. Konkret handelt es sich bei dem Vorgang laut AWS um das Deaktivieren des Java Naming and Directory Interface (JNDI), das für Log4Shell genutzt wird.
Wie Unit 42 jetzt schreibt, sind bei dem zweiten Aufruf und dem damit verbundenen Neustart nicht etwa wieder die gleichen Rechte für Java vergeben worden wie vorher. In Containern sind zum Beispiel sämtliche Linux Capabilities vergeben worden, auch Seccomp und Cgroups seien nicht mehr genutzt worden, letztlich lief das Programm auch mit Root-Rechten. Auf Hostsystemen lief dies laut der Beschreibung ähnlich, und eine Rechteeinschränkung habe dabei nicht stattgefunden.
Ein Angriff ist deshalb mehr als simpel…
Um einen erfolgreichen Angriff oder auch Ausbruch aus dem Container durchzuführen, reiche es also, eine eigene Anwendung mit dem Namen “java” in dem System unterzubringen.
Diese erkennt dann der Update-Dienst und startet sie mit den erweiterten Rechten. AWS hat diese Fehler inzwischen schon behoben und stellt korrigierte Updates bereit.
