Angreifbare Software bleibt auch in Containern angreifbar

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Es wurde schon gesagt – und zwar nicht nur von mir –, dass verschlüsselter Schadcode nach wie vor Schadcode ist. Die Verschlüsselung ändert daran nichts, außer dass sie möglicherweise Sicherheits- und Anwendungsinfrastruktur für dessen Erkennung blind macht während er durch das Netzwerk übertragen wird.

Dasselbe gilt für Apps und Plattformen, die in Containern ausgeführt werden. Wenn die App Schwachstellen aufweist, ist sie unabhängig davon anfällig, ob sie auf einem Betriebssystem, in einer virtuellen Maschine oder heutzutage in einem Container ausgeführt wird. Ist die App im Rechenzentrum anfällig, ist sie es auch in der Cloud. Und umgekehrt.

Container sind nicht dafür ausgelegt, Anwendungen auf magische Weise zu schützen. Sie bieten zwar eine grundlegende Absicherung auf Netzwerkebene, doch das Netzwerk ist nicht die Anwendung. Anwendungen verfügen über eine eigene Angriffsfläche, die ihren Code und ihre Schnittstellen (APIs) ebenso umfasst wie die verwendeten Protokolle (HTTP, TCP) und den benötigten Anwendungs-Stack. Daran ändert sich auch nichts, wenn ein Eintrag in einer IP-Tabelle hinzugefügt wird oder eingehende Anfragen anderweitig auf solche beschränkt werden, die über den Ingress der containerisierten Umgebung eingehen.

Der Grund, warum ich dies anspreche, ist die DevSecOps-Umfrage 2017 von Sonatype. Darin stimmten 88 % der mehr als 2.200 Befragten zu, dass die Sicherheit von Containern wichtig sei, aber nur 53 % setzen Sicherheitsprodukte ein, um anfällige Anwendungen, Betriebssysteme oder Konfigurationen in Containern zu identifizieren.

Die ersten beiden Bestandteile dieser Statistik – Anwendungen und Betriebssysteme – fielen mir besonders auf, da sie zu den Komponenten eines vollständigen Anwendungs-Stacks gehören, die sich nicht zwangsläufig je nach Standort oder Betriebsmodell (Cloud, Container, Virtualisierung usw.) ändern. Eine Anwendung oder API mit einer SQLi- oder XSS-Schwachstelle erhält nicht auf magische Weise Schutz, wenn sie von einem Modell in ein anderes verschoben wird. Diese Schwachstelle befindet sich im Code. Dasselbe gilt für Plattformen, die unbestreitbar Teil des Anwendungssicherheits-Stacks sind. Eine Schwachstelle bei der Verarbeitung von HTTP-Headern in Apache unter Linux besteht auch dann weiterhin, wenn die Anwendung von einem herkömmlichen, betriebssystembasierten Modell in ein Container-Modell verschoben wird.

Es ist wichtig – ja sogar unerlässlich –, dass wir weiterhin Schwachstellen im gesamten Anwendungs-Stack identifizieren, unabhängig davon, wo oder in welcher Form die Anwendung bereitgestellt wird.

Ebenso wichtig ist es, beim Umstieg auf Container die bereits für herkömmliche Anwendungen eingesetzten Schutzmaßnahmen beizubehalten. Eine Web Application Firewall ist für in Containern bereitgestellte Anwendungen genauso nützlich wie für Anwendungen, die in der Cloud oder in herkömmlichen Umgebungen bereitgestellt werden.

Das gilt auch für die anderen Sicherheitstools, die laut der Umfrage von den Befragten eingesetzt werden, etwa Lösungen für statische Scans und Echtzeit-Scans (SAST, DAST, IAST und RASP). Web Application Firewalls (WAF) werden zwar häufiger eingesetzt als andere Tools, doch auch SAST und SCA (Source Code Analysis) sind weit verbreitet. SCA ist ein statisches Verfahren, mit dem Probleme bereits vor der Bereitstellung aufgespürt werden können. Ich verrate damit wohl mein Alter, wenn ich anmerke, dass Tools wie lint in die Kategorie der SCA-Tools fallen. Diese decken zwar nicht in Echtzeit Schwachstellen auf, die sich aus dem Zusammenspiel des Codes sowie aus der Interaktion mit Benutzern ergeben, können jedoch einige der häufigeren Fehler von Entwicklern erkennen, die zu Speicherlecks, Abstürzen oder dem berüchtigten Pufferüberlauf führen.

Ich weiß, was Sie denken. Sie denken: „Lori, ich habe gerade die Ergebnisse der Stack Overflow-Entwicklerumfrage 2017 gelesen, und JavaScript ist mit Abstand die beliebteste Programmiersprache unter Entwicklern. Und JavaScript wird interpretiert, also sind diese ganzen Pufferüberläufe und Speicherlecks doch nur unschöne Erinnerungen an die alten Zeiten, als Sie noch in C/C++ programmiert haben.“

Allerdings sind JavaScript – und andere moderne, interpretierte Sprachen – letztlich in einer hardwarenäheren Sprache wie C/C++ implementiert. Und wie bereits in der Vergangenheit gezeigt wurde, kann man sich diese Tatsache mit genügend Einfallsreichtum zunutze machen, um einen Exploit für das System zu entwickeln.

Und selbst wenn das kein Grund zur Sorge ist, gibt es in jedem Code zahlreiche weitere Schwachstellen, die auf verwendete Bibliotheken oder einen falsch verwendeten Systemaufruf zurückzuführen sind, der die serverseitige Sicherheit gefährdet. Aktuellen Erhebungen zufolge bestehen 80 % der Anwendungen aus Open-Source-Komponenten. Die Sonatype-Studie stellte außerdem fest, dass die Zahl der bestätigten oder vermuteten Sicherheitsverletzungen im Zusammenhang mit Open-Source-Komponenten von 2014 bis 2017 um 50 % gestiegen ist. Viele davon sind in Sprachen geschrieben, die besonders gravierende Fehler begünstigen – sowohl weil sie weniger streng kontrolliert werden als auch weil es immer weniger Entwickler gibt, die diese Sprachen beherrschen.

Der Punkt ist, dass jeder Code Schwachstellen enthalten kann. Und da Code der Grundbaustein von Anwendungen ist, die heute das Aushängeschild eines Unternehmens sind, ist es wichtig, sie unabhängig davon, wo oder wie sie bereitgestellt werden, zu überprüfen und zu schützen.

Container oder Cloud. Traditionell oder virtuell. Alle Anwendungen sollten auf Schwachstellen geprüft und vor der Ausnutzung von Sicherheitslücken in Plattformen und Protokollen geschützt werden. Punkt.

Anwendungen sollten während der Entwicklung gründlich gescannt und getestet und anschließend in der Produktionsumgebung erneut getestet werden. Beides ist notwendig, denn der Trugschluss der Zerlegung besagt, dass die Einführung neuer Komponenten die Ausgangslage verändert. Durch neue Interaktionen können bisher unentdeckte Schwachstellen zutage treten.

Beachten Sie zum Schutz von Apps Folgendes:

• Setzen Sie bei der Entwicklung Tools zur Code- und App-Analyse ein. Integrieren Sie diese nach Möglichkeit in die CI/CD-Pipeline.
• Testen Sie erneut in der Produktionsumgebung, falls durch die Interaktion mit anderen Komponenten/Apps Probleme auftreten.
• Informieren Sie sich laufend über Schwachstellen in Protokollen und Plattformen, ebenso wie über Schwachstellen, die in möglicherweise von Ihnen verwendeten Drittanbieterbibliotheken entdeckt werden
• Integrieren Sie eine Web Application Firewall in Ihre Architektur. Selbst wenn Sie sie nicht im Blockierungsmodus einsetzen, ist sie von unschätzbarem Wert, falls eine Zero-Day-Schwachstelle in einem Protokoll oder einer Plattform beziehungsweise eine Schwachstelle in einer Bibliothek entdeckt wird.

Bleiben Sie sicher!

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie