Der Firma Cyberark gelang es, den Host der “Play with Docker”-Umgebung zu übernehmen. Der Anbieter hatte schlecht abgesicherte privilegierte Container verwendet.

Den bei ihrem Hack zurückgelegten Weg beschreibt die Firma minutiös in ihrem Blogpost. Zunächst gelang es ihnen mit ein paar simplen Kommandozeilentools (findfs, debugfs, readelf) mehr über das Read-only-Dateisystem des Hosts herauszufinden, Zugriff auf ein Kernelmodul (“ceph.ko”) zu erhalten, das die “printk()”-Funktion verwendet und dieses auszulesen.

Im nächsten Schritt fanden sie den CRC-Wert der Funktion “call_usermodehelper()” und über “ceph.ko” den “vermagic”-String und die Adressen der CRCs heraus, erzeugten ein eigenes Modul (“probing.ko”) und passten das automatisch generierte File “probing.mod.c” mit den ermittelten Werten an die Bedürfnisse des Originalkernels auf dem Host an und bauten zunächst eine “printk()”-Funktion ein. Über “readelf” und “chngelf” änderten sie schließlich den Offset für das “init_module”.

Eigenes Kernelmodul

Nach diesen Schritten luden die Sicherheitsforscher das neu erzeugte Kernelmodul “probing.ko” im Container (“insmod”) und fanden so die gesuchten CRC-Adressen heraus. Ein weiteres Modul nutzte dann “call_usermodehelper()”, um eine Remote Shell auf dem Host zu öffnen und per Netcat eine Verbindung zum Angreifer zu öffnen.

Die kompletten Details zu dem Hack stehen im Blogpost von Cyberark. Dass der Angriff möglich war, führt die Firma vor allem auf den Einsatz unzureichend abgesicherter privilegierter Container zurück. Dass diese in der Lage waren, überhaupt Kernelmodule zu laden, sei dabei nur ein Problem. Play with Docker wurde bereits Anfang November von dem Vorfall informiert.