Schwachstellen in CD-Pipelines - Teil 1: Kennst DU sie?

Bist du Mitarbeiter eines Unternehmens, das moderne Praktiken der kontinuierlichen Softwareentwicklung und Ansätze wie Continuous Integration (CI), Continuous Delivery (CD) oder DevOps einsetzt und lebt? Dann sind dir die Vorteile dieser Praktiken grundsätzlich bewusst. Diese Ansätze können die Softwarequalität erhöhen oder die Time-to-Market reduzieren. Hast du jemals darüber nachgedacht, wie sicher die Tools oder die Infrastruktur in eurer CD-Pipeline sind? Werden Versionen von Tools verwendet, die Schwachstellen aufweisen?

In diesem Artikel gehe ich davon aus, dass du die Grundlagen von CD-Pipelines kennst.

Gerade im Zeitalter der Digitalisierung und der Datenschutz Grundverordnung (DS-GVO) ist es wichtig, Sicherheit frühzeitig in den agilen Softwareprozess zu integrieren und die verwendeten Pipelines abzusichern. Wenn eine Pipeline nicht verfügbar ist oder sensible Daten an Dritte weitergegeben werden, stehen alle genannten Vorteile, z. B. die Erhöhung der Softwarequalität, sehr schnell auf dem Spiel. Je nach Ausmaß des Angriffs kann ein Unternehmen erhebliche Schäden erleiden, z. B. Imageschäden.

Aus diesem Grund möchte ich dir in diesem Blogbeitrag aufzeigen, welche Schwachstellen eine CD-Pipeline haben kann und welche Probleme dadurch entstehen können.

Keine oder unzureichende Zugriffsbeschränkungen

Wie sehen die Zugriffsbeschränkungen in deiner Pipeline aus? Werden Authentifizierungsmechanismen eingesetzt, damit nicht willkürliche Personen auf Komponenten eurer Pipeline zugreifen können?

Wenn es Schwachstellen im Bereich Authentifizierung gibt, kann ein Angreifer ohne Benutzeranmeldung auf die Anwendung zugreifen. Gelingt es einem Angreifer Benutzer-Login-Daten zu erlangen, dann erhält er die gleichen Rechte wie die berechtigten Nutzer. Mit diesen Rechten können die CD-Pipeline-Skripte oder die entwickelte Anwendung manipuliert werden.

Unverschlüsselte Verbindungen

Werden z. B. integrierte Werkzeuge, Tools oder Repositories nur mit HTTP aufgerufen, dann besteht die Gefahr von sogenannten „Man-In-The-Middle-Angriffen“. Diese Schwachstelle ermöglicht Angreifern bösartigen Code in die Pipeline einzuschleusen bzw. können sie den Datenverkehr mitlesen und manipulieren. Wenn ein Angreifer erfolgreich war, kann er den im Build-Prozess eingeschleusten Code anschließend ausführen.

Angreifer manipuliert Datenverkehr

Verwendung von verwundbaren Pipeline Komponenten oder unsicheren Umgebungen

Verwendet deine Pipeline Komponenten, die Schwachstellen besitzen? Wenn du diese Frage mit „Ja“ beantworten kannst, können Angreifer Schadecode, Produktionscode bzw. Unit-Tests in die Pipeline einschleusen. Diese Codes bzw. Tests können dazu führen, dass Backdoors geöffnet, das Netzwerk gescannt bzw. angegriffen oder Daten an andere Server transferiert werden.

Ein Beispiel: Im Februar 2019 wurde bekannt, dass Docker vor Version 18.09.2 eine kritische Schwachstelle besitzt. Durch diese Schwachstelle können Angreifer aus dem Container direkt auf das Hostsystem zugreifen [Chanana2019, letzter Zugriff 09/2019].

Verwundbarkeit der Pipeline Konfigurationen

Wenn Werkzeuge oder die Infrastruktur falsch konfiguriert sind, dann wissen Unternehmen meistens nicht, dass ihre Daten möglicherweise öffentlich zugänglich sind. Falls bei den Pipeline Komponenten die Sicherheitseinstellungen nicht konfiguriert werden, dann können Angreifer z. B. Viren in die Pipeline einschleusen.

Verwundbare Code Commits, Pipeline-Skripte, Docker-Images/Container, Artefakte

Eine Schwachstelle kann auch sein, wenn Commits Passwörter enthalten, erzeugte Software-Artefakte oder verwendete Docker-Images verwundbar sind. Die genannten Komponenten können Einfallstore für Angreifer sein. Vor allem muss bedacht werden, dass Schwachstellen eines Softwareartefakts eine Gefahr darstellen, wenn das Produkt ausgeliefert wird.

Keine Überprüfung von Änderungen an der Pipeline

Werden Pipeline-Skripte oder die Infrastrukturkonfiguration verändert und es findet kein Review nach dem Vier-Augen-Prinzip statt, können sehr einfach Manipulationen stattfinden. Bei fehlendem Review kann es vorkommen, dass kein Teammitglied erfährt, welche Änderungen vorgenommen wurden. Das kann dazu führen, dass Daten ausgelesen werden oder die Pipeline kompromittiert wird (Denial-of-Service-Angriff). Eine nicht verfügbare Pipeline führt zu einem Entwicklungs- und Auslieferungsstopp.

Angreifer kompromittiert Pipeline

Jedes zugriffsberechtigte Teammitglied

Jedes Teammitglied (auch ein Gekündigtes), welches Zugriff auf die Einstellungen und Skripte der Pipeline hat, ist eine potentielle Gefahr für die Sicherheit der Pipeline (sog. Insider-Angriffe). Jede absichtliche oder unabsichtliche Handlung kann dazu führen, dass Dritte auf die Pipeline zugreifen können. Beachte deshalb, dass du es nicht bist, der durch Unwissenheit die Sicherheit einzelner Komponenten ausschaltet.

Fazit:

Zusammenfassend lässt sich festhalten, dass Angreifer eine Vielzahl an Möglichkeiten besitzen Schwachstellen auszunutzen. Diese treten dann auf, wenn unachtsam Komponenten von Dritten eingesetzt werden oder durch zu wenig Erfahrung die nötige Sicherheit nicht eingestellt wurde. Oftmals tritt der Fall ein, dass einem Unternehmen gar nicht bewusst ist, dass sie Komponenten einsetzen, die Schwachstellen enthalten.

Mach dir eines bewusst: Deine Pipeline ist nur so sicher, wie ihr schwächstes Glied. Eine Schwachstellen reicht aus, dass ein Angreifer großen Schaden anrichten kann.

Meiner Meinung nach sind die Unwissenheit der Mitarbeiter, fehlende Zeit und fehlendes Budget das Problem, dass Sicherheit im agilen Softwareentwicklungsprozess hinten angestellt wird.

Es ist nie zu spät — deshalb fange heute noch an und integriere Sicherheit in deinem Softwareprozess. Lebe „Agile Security“ und stärke du als Erster das Sicherheitsbewusstsein in deinem Team.

Interesse geweckt?

Dann besuche mich auf der Continous Lifecyle und erfahre, wie du die gannnten Schwachstellen erkennen kannst, bzw. welche Tools dir dabei helfen können, die Schwachstellen automatisch in deiner Pipeline aufzuspüren.

Verpasse auch nicht Teil 2 dieses Blogposts. Darin erfährst du, wie du diese Schwachstellen/Probleme dauerhaft beseitigen bzw. überhaupt entdecken kannst (durch Tools/Monitoring etc.).

Bist Du eher der Typ für eine Schulung?

Als Kursteilnehmer unseres „Security Training for Developers“ lernst Du die am häufigsten auftretenden Sicherheitslücken in Anwendungen, deren Ursachen und das Schadenspotential kennen. Dazu wirst du nach einer Grundlageneinführung in die Rolle eines Angreifers schlüpfen, um die gelernten Angriffe in Eigenregie in einer sicheren Umgebung zu erproben.