Die Lücken im Blick: Der Stand der Schwachstellen in cloud-nativen Anwendungen

Originalartikel von Magno Logan, Information Security Specialist

Was bedeutet es, auf Cloud Native zu setzen? Laut der Cloud Native Computing Foundation (CNCF), einer Unterorganisation der Linux Foundation, unterstützen cloud-native Technologien Unternehmen bei der Entwicklung und Ausführung von Lösungen in Cloud-Umgebungen und On-Premises-Architekturen. Mittlerweile übernehmen immer mehr Unternehmen diese Technologien, zu denen auch Container und Infrastructure-as-Code gehören. Doch müssen sich Unternehmen und Anwender von cloud-nativen Applikationen darüber im Klaren sein, dass eine Schwachstelle in einer der dabei vorhandenen Abhängigkeiten das gesamte System beeinträchtigen und in einigen Fällen zu einer vollständigen Kompromittierung des Clusters führen kann. Und es gibt es noch andere Gründe für erhöhte Vorsicht. So greifen beispielsweise die meisten Cloud-Native-Projekte auf Bibliotheken und Abhängigkeiten zurück, die wiederum Open-Source sind. Diese Bibliotheken werden in der Regel während des Entwicklungszyklus eingebunden und nur selten aktualisiert oder auf bekannte Schwachstellen überprüft — ein weiterer Weg zu kompromittierten Cloud-Ressourcen. Unser Bericht zeigt die Schwachstellen in der Sicherheit nativer Cloud-Anwendungen auf. und macht deutlich, dass Unternehmen diesen Fragen Zeit und Ressourcen widmen sollten.

Das Security TAG Team (STAG) innerhalb der CNCF vereinfacht die Erstellung von Sicherheitsressourcen und -kontrollen für Nutzer im gesamten cloud-nativen Ökosystem. Eine der Aufgaben des Teams ist das Beantragen und Koordinieren unabhängiger Sicherheitsprüfungen für cloud-native Projekte. Eine Liste der zwischen 2018 und 2020 durchgeführten Sicherheitsaudits für diese Projekte finden Sie im Anhang.

Die CNCF beauftragt seit 2018 unabhängige Sicherheitsfirmen mit der Analyse von Projekten: Cure53, Trail of Bits, Atredis Partners und AdaLogics. Wir haben die Berichte dieser externen Beratungsunternehmen gesammelt und ihre Ergebnisse analysiert. Außerdem haben wir ihre Sicherheitsprüfungen untersucht und unter anderem die Art und den Schweregrad der Schwachstellen verglichen.

Dazu gehört als erster Punkt die Anzahl der gemeldeten Schwachstellen in jedem Projekt. Es ist kaum überraschend, dass Kubernetes an der Spitze steht, ist es doch das größte dieser Projekte, wird am häufigsten eingesetzt und enthält mehr Code, so dass die Wahrscheinlichkeit, Schwachstellen darin zu finden, größer ist. Die Projekte etcd und Helm belegten den zweiten bzw. dritten Platz.

Bild 1. Die Anzahl der Schwachstellen pro Projekt, die in den Sicherheits-Auditberichten der CNCF veröffentlicht wurden.

Auch die Art der Schwachstellen oder deren Klassifizierung wurden analysiert. Das Beratungsunternehmen Trail of Bits hat die Schwachstellen in viele verschiedene Klassen oder Kategorien eingeteilt: Datenvalidierung, Denial of Service, Authentifizierung und viele andere Probleme. Hier ist die Aufschlüsselung, was jeder dieser Typen bedeutet:

Class Description
Access Controls Related to authorization of users and assessment of rights
Auditing and Logging Related to auditing of actions or logging of problems
Authentication Related to the identification of users
Configuration Related to security configurations of servers, devices, or software
Cryptography Related to protecting the privacy or integrity of data
Data Exposure Related to unintended exposure of sensitive information
Data Validation Related to improper reliance on the structure or values of data
Denial of Service Related to causing system failure
Error Reporting Related to the reporting of error conditions in a secure fashion
Patching Related to keeping software up to date
Session Management Related to the identification of authenticated users
Timing Related to race conditions, locking or order of operations
Undefined Behavior Related to undefined behavior triggered by the program

Tabelle 1. Beschreibung der verschiedenen Klassen von Schwachstellen, gemäß der Schwachstellen Klassifizierung von Trail of Bits

In einigen Berichten wurde keine Art der Sicherheitslücke angegeben, so dass wir sie anhand der Beschreibung der Sicherheitslücke und der betroffenen Bereiche zusammengefasst haben. Hier ist die Aufschlüsselung der Schwachstellen nach Schwachstellentyp aus unserer Analyse:

Bild 2. Die Anzahl der Schwachstellen pro Klassenkategorie gemäß der Trail of Bits-Schwachstellenklassifizierung

Die Datenvalidierung stand an erster Stelle und gibt Anlass zur Sorge, da wir fast 60 Schwachstellen dieser Art feststellen konnten. Bei der Datenvalidierung geht es hauptsächlich um die Validierung von Eingaben. Dazu gehören auch Stack-basierte Buffer Overflows, Heap Overflows, Integer Overflows und andere Probleme. Die Verwendung nicht vertrauenswürdiger Daten ohne Validierung ist ein schwerwiegendes Problem und kann alle Arten von Sicherheitslücken verursachen. Ein Beispiel für eine solche Schwachstelle in Kubernetes und den Umgang damit finden Sie im Originalbeitrag.

An zweiter Stelle, nach dem Typus der Datenvalidierung, steht Konfiguration. Auch hier geht es in der Regel um Probleme, die sich durch die Implementierung der richtigen Sicherheitseinstellungen vermeiden lassen. Fehlkonfigurationen sind die Hauptursache für Sicherheitsprobleme in der Cloud, so dass es nicht verwunderlich ist, dass es ähnliche Probleme bei nativen Cloud-Anwendungen gibt. Ein Beispiel dafür finden Sie im Originalbeitrag.

Und an dritter Stelle steht Denial-of-Service (DoS) mit genau 20 Schwachstellen, die zu einem DoS des betreffenden Projekts und manchmal des gesamten Systems führen können. DoS-Schwachstellen können auch durch eine unzureichende Datenvalidierung entstehen, die es einem Angreifer ermöglichen würde, größere Datenmengen als erwartet oder zu viele Anfragen in einem kurzen Zeitraum zu senden. Ein Beispiel dafür finden Sie im Originalbeitrag.

Wie schwerwiegend waren die bei diesen Projekten festgestellten Schwachstellen? Sind diese Projekte zuverlässig? Kann man ihnen trauen? In den meisten Fällen ja, es handelt sich um sehr robuste Open-Source-Projekte. Dank der Unterstützung der CNCF werden sie gut gewartet, und die Sicherheit hat immer Priorität. Aus der Sammlung der gemeldeten Schwachstellen sind die meisten Schwachstellen von geringem Schweregrad, gefolgt von einem mittleren. Das bedeutet, dass nur wenige dieser Projekte schwerwiegende oder kritische Schwachstellen aufweisen, die den Benutzer in Gefahr bringen würden, was hervorragend ist. Hier ist eine Aufschlüsselung der Anzahl der Schwachstellen nach Schweregrad:

Bild 3. Die Anzahl der Schwachstellen nach Schweregrad, gemäß den von der CNCF veröffentlichten Sicherheitsauditberichten

Schwachstellen, die als niedrig eingestuft werden, haben in der Regel einen CVSS 3.0-Wert zwischen 0,1 und 3,9, während die mittleren Schwachstellen zwischen 4,0 und 6,9 liegen – dies bedeutet im Allgemeinen, dass sie schwerer auszunutzen sind oder geringere Auswirkungen auf das System haben als hohe oder kritische Schwachstellen. Dies zeigt, dass nur sehr wenige Projekte erhebliche Probleme aufwiesen. Nur 17 Schwachstellen wurden bei allen geprüften Projekten als hoch und sieben als kritisch eingestuft.

In der Fortsetzung der Analyse geht es um die Abhängigkeiten von quelloffener Software und entsprechende Empfehlungen für einen besseren Schutz.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.