Wie werden Bedrohungsakteure Container angreifen und nutzen? Das ist eine Frage, über die ich ständig nachdenke. Ich arbeite jetzt seit mehr als zwei Jahrzehnten in diesem Bereich und habe das Gefühl, dass ich eine Antwort haben sollte. Aber ich nicht.
Stattdessen habe ich viele verschiedene Ideen, von denen ich keine wirklich als richtig bezeichnen kann. Ein Teil dieser Unentschlossenheit ist darauf zurückzuführen, dass ich so viel Zeit damit verbracht habe, mich in der „alten“ Welt mit dem Thema Sicherheit vertraut zu machen. Container haben eigentlich kein Gegenstück. Sicher, virtuelle Maschinen (VMs) werden oft mit Containern in Verbindung gebracht, aber sie konnten nie wie Container skaliert werden. Sie dienen auch ganz anderen Zwecken als Container. Es hat eine Weile gedauert, bis ich mein Denken angepasst und verstanden hatte, wo Container tatsächlich in die Angriffsfläche passen.
Die öffentlichen Beispiele für Angriffe auf Containerumgebungen sind sehr begrenzt. Die Verstöße stehen fast immer im Zusammenhang mit Kryptomining, was schwerwiegende Angriffe darstellt, aber der Vorfallhelfer in mir findet sie enttäuschend. Eine weitere Gemeinsamkeit besteht darin, dass sie meist das Ergebnis einer Fehlkonfiguration sind, sei es in Kubernetes oder einem Cloud-Konto. Die Kombination der Motive und der Taktik war bisher nicht sehr inspirierend.
Der alte Weg
RCE-Schwachstellen (Remote Code Execution) sind seit langem das Hauptanliegen der Computersicherheit. Sie sind es immer noch, aber wie lässt sich diese Denkweise auf Container übertragen? Es ist leicht, sofort auf RCE als primäre Bedrohung zu verweisen, aber es scheint nicht die richtige Herangehensweise an Container zu sein. Zum einen sind Container oft sehr kurzlebig – 44 % der Container leben weniger als fünf Minuten – also müsste ein Eindringling schnell sein.
Bei diesem Ansatz wird auch davon ausgegangen, dass der Container dem Internet ausgesetzt ist. Sicherlich sind einige Container auf diese Weise aufgebaut, aber oft sind sie sehr einfach und nutzen bewährte Technologien wie NGINX. Für diese Anträge gibt es möglicherweise eine Frist von null Tagen, aber sie wären äußerst wertvoll und schwer zu bekommen. Meine Erfahrung hat mir gezeigt, dass viele Container intern verwendet werden und keine direkte Verbindung zum Internet herstellen. In diesem Fall wird das RCE-Szenario deutlich schwieriger. Ich sollte erwähnen log4j, obwohl diese Art von Schwachstellen das Potenzial haben, aus der Ferne ausgenutzt zu werden, selbst wenn sich das anfällige System nicht am Rande befindet.
Der neue Weg
Wenn RCE nicht die größte Bedrohung für Container darstellt, was dann? Sind Container überhaupt auf dem Radar der Bedrohungsakteure? Ja, Container und ihre unterstützende Infrastruktur sind zu wichtig, um sie zu ignorieren. Container-Orchestrierungssoftware hat es ermöglicht, containerisierte Arbeitslasten auf unvorstellbare Zahlen zu skalieren. Der Nutzungstrend nimmt ebenfalls zu, sodass Sie sicher sein können, dass sie ein Ziel sein werden. Man kann sie einfach nicht als Server betrachten, die man durch RCE-Schwachstellen erreichen kann.
Stattdessen ist das Gegenteil der Fall. Anstatt Container von außen nach innen anzugreifen, müssen sie von innen nach außen angegriffen werden. Dies ist im Wesentlichen das, was Supply-Chain-Angriffe bewirken. Die Lieferkette ist ein äußerst effektiver Angriffsvektor gegen Container, wenn man beginnt zu verstehen, wie sie aufgebaut sind. Ein Container beginnt mit einer Definitionsdatei, z. B. Dockerfile, die alles definiert, was sich bei der Ausführung im Container befindet. Sobald es erstellt wurde, wird es in ein Image umgewandelt, und dieses Image kann unzählige Male in eine Arbeitslast umgewandelt werden. Wenn irgendetwas in dieser Definitionsdatei gefährdet ist, dann ist auch jede einzelne ausgeführte Arbeitslast gefährdet.
Container werden oft, aber nicht immer, speziell für eine Anwendung erstellt, die etwas tut und beendet wird. Diese Anwendungen können fast alles sein – es ist wichtig zu verstehen, wie viel mithilfe von Bibliotheken erstellt wird, entweder Closed Source oder Open Source, die von anderen Leuten geschrieben wurden. GitHub verfügt über Millionen von Projekten, und das ist nicht das einzige Code-Repository, das es gibt. Wie wir bei SolarWinds gesehen haben, ist Closed Source auch anfällig für Angriffe auf die Lieferkette.
Ein Supply-Chain-Angriff ist eine hervorragende Möglichkeit für Bedrohungsakteure, in die Containerumgebung eines Ziels einzudringen. Sie können den Angriff sogar von der Infrastruktur des Kunden skalieren lassen, wenn die Kompromittierung unbemerkt bleibt. Ein solches Szenario spielt sich bereits ab, wie wir bei der gesehen haben Codecov-Verstoß. Aber es ist schwer zu erkennen, da das alles neu ist und unser Denken immer noch in den Problemen der Vergangenheit verwurzelt ist.
Ein Weg nach vorne
Wie bei der Behebung der meisten Probleme ist die Sichtbarkeit normalerweise ein guter Ausgangspunkt. Es ist schwer, etwas zu reparieren, was man nicht sieht. Um Ihre Container zu sichern, benötigen Sie Einblick in die Container selbst sowie in die gesamte Pipeline, die sie erstellt. Das Schwachstellenmanagement ist eine Art von Sichtbarkeit, die in die Build-Pipeline integriert werden muss. Ich würde auch andere statische Analysetools einbeziehen, beispielsweise solche, die ebenfalls nach durchgesickerten Geheimnissen suchen. Da sich ein Angriff auf die Lieferkette nicht wirklich vorhersagen lässt, ist die Laufzeitüberwachung von entscheidender Bedeutung, damit Sie genau wissen, was Ihre Container tun.
