Einem Forscherteam von Wiz fiel auf, dass der sogenannte OMI-Agent automatisch installiert wird, wenn ein Azure-Kunde in seiner Umgebung eine virtuelle Linux-Maschine in Betrieb nimmt. OMI steht hier für das quelloffene „Open Management Infrastructure“-Paket, das die Leistungsdaten virtueller Maschinen zentralisiert sammelt und für Administratoren grafisch darstellt. Auf dieser Maschine läuft OMI im Hintergrund – und zwar mit root-Rechten, der höchsten möglichen Berechtigungsstufe in der Linux-Welt. Und genau hier liegt die Schwachstelle. Von der Installation dieses verwundbaren Management-Tools bekommen Azure-Nutzer jedoch nichts mit. Laut Wiz sind 65 Prozent aller von ihnen stichprobenartig untersuchten Azure-Tenants von der Sicherheitslücke betroffen. Microsoft macht es Nutzern jedoch nicht leicht, die Lösung auf deren Webseite zu finden.
Fatale Viererkette
Die Installation eines Management-Werkzeuges ohne Wissen der Admins ist jetzt in mehrfacher Hinsicht zu einem großen Problem geworden:
Hier kommen insgesamt vier Sicherheitslücken zum Tragen, die es einem Cyberkriminellen ermöglichen, Programmcode aus der Ferne auf ein betroffenes System zu bringen und dort auszuführen. Mit Hilfe dreier weiterer Schwachstellen in OMI wird der Angreifer dann zum „root“-Nutzer – und hat damit das System übernommen. Die drei Sicherheitslücken, die den Weg zu „root“ freimachen, sind alleine schon problematisch genug. Die Remote Code Execution (RCE), die die Übernahme von außen ermöglicht, ist jedoch derart trivial, dass manche Experten sich gefragt haben, wie so etwas im Jahr 2021 überhaupt möglich ist. Auf der NVD-Kritikalitätsskala hat die RCE-Lücke einen Wert von 9.8 – der höchstmögliche Wert ist 10.
Gretchenfrage
Das grundlegende Problem: Wie soll ein Administrator eine Sicherheitslücke in einem Programm schließen, von dem er nicht einmal weiß, dass es installiert ist? Jeder Sicherheitsexperte, der etwas auf sich hält, predigt immer wieder, dass ein vollständiges Software-Inventar ein wichtiger Baustein für ein tragfähiges Sicherheitskonzept ist. Doch dadurch, dass das OMI-Werkzeug ohne Wissen der verantwortlichen Person installiert wird, ist das Tool plötzlich zu einem Bestandteil der gefürchteten Schatten-IT geworden. Also zu einem Programm, von dessen Existenz niemand weiß. Gerade ein Werkzeug, das eine so wichtige Funktion ausfüllt, sollte definitiv nicht Teil dieser Kategorie sein.
Ein erfolgreicher Angriff mit Hilfe der vorgenannten „Viererkette“ käme für Betroffene buchstäblich aus heiterem Himmel.
„Offen“ gleich „Sicher“?
Der Name des Management-Tools legt es bereits nahe: Es handelt sich um ein quelloffenes Werkzeug, das von Microsoft und der Open Group unterhalten wird. Die Nutzung ist kostenfrei und der Quellcode frei verfügbar.
Quelloffene Werkzeuge haben durchaus ihre Vorzüge, daran gibt es keinen Zweifel. Auch wir bei G DATA treiben wir das Thema aktiv voran und haben einige Werkzeuge auf Github veröffentlicht. Doch viele Menschen unterliegen dem Fehlschluss, dass Open-Source-Software automatisch sicherer ist, weil der Quellcode öffentlich ist. Sicherheitslücken, so die Argumentation, würden so wesentlich schneller auffallen und könnten behoben werden. Diese Annahme funktioniert jedoch nur unter der Prämisse, dass der Quellcode auch laufend von einer größeren Anzahl von Entwicklerinnen und Entwicklern speziell darauf hin untersucht wird. Das ist jedoch nicht immer der Fall. Das zeigen Berichte über teils hochkritische Sicherheitslücken wie „Baron Samedit“, die fast ein Jahrzehnt in sudo schlummerten, ohne dass sie bemerkt wurde. Die Diskussion zu diesem Thema wird jedoch teilweise sehr emotional und dogmatisch geführt, daher soll dies als Ausführung genügen.
Risiken und Nebenwirkungen
Da Cloudplattformen mittlerweile ein nicht mehr wegzudenkender Bestandteil von Versorgungsketten ist, sind Sicherheitslücken darin besonders kritisch. Wer eine Liefer- oder Versorgungskette angreifen kann, kann großen wirtschaftlichen Schaden anrichten und schlimmstenfalls sogar Menschenleben gefährden. Gerade deshalb ist es wichtig, hier für Transparenz zu sorgen. Fehlt diese, fehlt auch jegliche Möglichkeit der Intervention.
Das hat sich auch in der Vergangenheit schon als potenziell hochgefährlich herausgestellt. In diesem Zusammenhang sei an die Sicherheitslücken in der Kaseya-Netzwerkverwaltung erinnert. Diese wird auch oft als „White Label“-Lösung vertrieben, das heißt es steht nicht unbedingt auch der tatsächliche Hersteller drauf. Und wenn Endanwender dann von einer Sicherheitslücke in einem Kaseya-Produkt erfahren, schließen sich nicht unbedingt darauf, dass sie selbst auch das Programm einsetzen und daher auch zum potenziellen Kreis der Betroffenen gehören.
Abhilfe
Microsoft hat auf einer Webseite Informationen zur RCE-Sicherheitslücke zur Verfügung gestellt und Schritte beschrieben, die die Lücke beheben. Besonders übersichtlich ist die Tabelle allerdings nicht und man mus schon recht genau hinsehen. Wer eine Linux-VM unter Azure betreibt, sollte hier schnellstmöglich aktiv werden. Laut einem Heise-Bericht sind zwar insgesamt nicht viele Maschinen betroffen - dennoch ist die Ausnutzung nur eine Frage der Zeit.
