Sichern Sie Ihre CI/CD-Pipeline: Erkunden Sie die Gefahren Ihres Selbst

Home » Security Bloggers Network » Sichern Sie Ihre CI/CD-Pipeline: Entdecken Sie die Gefahren selbstgehosteter Agenten

Continuous Integration/Continuous Deployment (CI/CD)-Pipelines sind für moderne Softwareentwicklungspraktiken von entscheidender Bedeutung geworden. CI/CD-Pipelines können die Entwicklungseffizienz und Softwarequalität erheblich verbessern, indem sie den Prozess des Erstellens, Testens und Bereitstellens von Code automatisieren. Die meisten modernen CI/CD-Plattformen (wie GitHub-Aktionen, Circle CI usw.) bieten die Option, den Pipeline-Prozess über einen selbst gehosteten Läufer auszuführen – einen Agenten, der vom Benutzer anstelle der CI/CD-Plattform gehostet wird, um Jobs darauf auszuführen ihre eigene Infrastruktur.

Mit selbst gehosteten Läufern können Sie benutzerdefinierte Hardwarekonfigurationen erstellen, die Ihren Anforderungen an Rechenleistung oder Arbeitsspeicher entsprechen, um größere Aufgaben auszuführen. Darüber hinaus können Sie in Ihrem lokalen Netzwerk verfügbare Software installieren und ein Betriebssystem auswählen, das nicht von der Plattform angeboten wird. Selbstgehostete Läufer können physisch, virtuell, in einem Container, vor Ort oder in einer Cloud-Umgebung sein. Die Alternative besteht darin, einen von der SaaS CI/CD-Plattform angebotenen Build-as-a-Service-Runner zu verwenden, bei dem der Benutzer keine Kontrolle über die Umgebung hat.

Es gibt mehrere Gründe, selbst gehostete Läufer zu verwenden:

Compliance und Datenschutz: Viele Unternehmen sind an strenge Vorschriften gebunden, die sie daran hindern, sensible Daten zu erstellen und an SaaS-Build-Services zu senden. Beispielsweise bevorzugen Organisationen aus dem Finanz- oder Regierungssektor häufig die Ausführung des Builds auf ihren internen Servern.

Besondere Spezifikationen: Beim Erstellen von Software für ungewöhnliche Betriebssysteme oder unterschiedliche Architekturen benötigt der Erstellungsprozess eine Maschine mit Spezifikationen, die ihren Anforderungen entsprechen. Dies ist auch in vielen eingebetteten, IoT- oder clientseitigen Anwendungen der Fall.

Kosteneinsparung: Unternehmen mit bestehender Cloud-Infrastruktur/privater Cloud können Kosten sparen, wenn sie sich für die Verwendung selbst gehosteter Läufer entscheiden und Ressourcenpools selbst verwalten.

Aus den oben genannten Gründen erfreuen sich selbst gehostete Läufer in vielen Organisationen zunehmender Beliebtheit. Selbst gehostete Läufer können jedoch erhebliche Sicherheitsrisiken darstellen, insbesondere wenn nicht vertrauenswürdige Workflows auf ihnen ausgeführt werden. Schädliche Programme können die Build-Maschine gefährden und aus der Sandbox des Läufers entkommen, wodurch Zugriff auf das Netzwerk, Geheimnisse und mehr der Maschine preisgegeben wird.

Die Verwendung eines selbst gehosteten Läufers kann Vorteile bieten, wie z. B. eine verbesserte Leistung und eine bessere Kontrolle der Umgebung. Allerdings sind damit auch Sicherheitsrisiken verbunden:

Selbstgehostete Läufer benötigen zum Betrieb dedizierte Server oder virtuelle Maschinen (VMs). Die Sicherheit dieser Server ist von entscheidender Bedeutung. Wenn der Server, auf dem der Läufer gehostet wird, nicht ordnungsgemäß gesichert ist, kann er zu einem potenziellen Einstiegspunkt für Angreifer werden.

Selbstgehostete Läufer benötigen normalerweise privilegierten Zugriff auf das Repository und das System, auf dem sie installiert sind. Es ist wichtig, die Zugriffskontrolle sorgfältig zu verwalten und die dem Läufer gewährten Berechtigungen einzuschränken. Unbefugter Zugriff auf den Runner könnte zu potenziellen Datenschutzverletzungen oder der Ausführung von Schadcode führen.

Gelingt es nicht, selbst gehostete Läufer von kritischen Systemen und sensiblen Daten zu isolieren, erhöht sich das Risiko, dass ein kompromittierter Läufer zu unbefugtem Zugriff und potenziellen Datenschutzverletzungen führt. Ohne angemessene Isolierung können sich Angreifer, die die Kontrolle über den Runner erlangen, möglicherweise seitlich im Netzwerk bewegen und möglicherweise andere Systeme und Daten gefährden.

Wenn die selbstgehostete Runner-Software nicht regelmäßig aktualisiert und überwacht wird, wird das System bekannten Schwachstellen ausgesetzt und anfällig für Angriffe. Ohne rechtzeitige Sicherheitspatches und Updates können Angreifer bekannte Schwachstellen in der Runner-Software ausnutzen. Eine unzureichende Überwachung erhöht die Wahrscheinlichkeit unentdeckter böswilliger Aktivitäten und Verzögerungen bei der Reaktion auf Sicherheitsvorfälle, was möglicherweise zu längeren Zeiträumen unbefugten Zugriffs oder Schadens führt.

Die Verwendung eines selbst gehosteten Läufers ohne Beschränkung des Zugriffs auf autorisierte Benutzer ermöglicht es jedem, Rechenressourcen für Aktivitäten wie Krypto-Mining und andere Aktivitäten zu nutzen, die finanziellen Schaden anrichten können.

GitHub Actions hat in den letzten Jahren als leistungsstarkes CI/CD-Automatisierungstool für die Softwareentwicklung stark an Bedeutung gewonnen. Mit GitHub Actions können Entwickler Aufgaben wie das Erstellen, Testen und Bereitstellen von Software automatisieren und sich so auf wichtigere Aufgaben konzentrieren. GitHub Actions bietet eine breite Palette an Anpassungsoptionen, darunter vorgefertigte Aktionen, von der Community erstellte Aktionen und die Möglichkeit, eigene Aktionen zu erstellen. Da immer mehr Organisationen GitHub Actions einsetzen, wird es zu einem immer wichtigeren Werkzeug für die moderne Softwareentwicklung.

GitHub bietet auch die Möglichkeit, selbst gehostete Läufer zu verwenden. Sie können selbstgehostete Runner auf verschiedenen Ebenen der Verwaltungshierarchie hinzufügen, darunter Runner auf Repository-Ebene, die einem einzelnen Repository gewidmet sind, Runner auf Organisationsebene, die Jobs für mehrere Repositorys in einer Organisation verarbeiten können, und Runner auf Unternehmensebene, die zugewiesen werden können an mehrere Organisationen in einem Unternehmenskonto.

Im Rahmen unserer Recherche haben wir gescanntdrei Millionen öffentliche Repositories. Für jedes Repository haben wir die verschiedenen GitHub-Aktionsdateien untersucht und den von jedem Job verwendeten Runner extrahiert. Wir haben erfahren, dass von 3.106.445 überprüften öffentlichen Repositories 43.803 selbst gehostete Läufer verwenden. Durch die Verwendung eines selbst gehosteten Läufers in einem öffentlichen Repository erhöhen sich die genannten Risiken dramatisch, da jeder GitHub-Benutzer auf der Welt einen Angriff starten könnte.

GitHub bietet Organisationen mehrere Optionen zur Konfiguration ihrer selbst gehosteten Läufer. Benutzer müssen überprüfen, ob ihre Organisation Best Practices für die Konfiguration befolgt, um potenzielle Risiken zu verhindern.

Runner-Gruppen: Wenn ein selbstgehosteter Runner auf Organisations- oder Unternehmensebene definiert wird, kann GitHub Workflows aus mehreren Repositorys auf demselben Runner planen. Folglich kann eine Sicherheitskompromittierung in diesen Umgebungen weitreichende Auswirkungen haben. Um den Umfang einer Kompromittierung zu verringern, können Sie Grenzen schaffen, indem Sie Ihre selbst gehosteten Läufer in separate Gruppen organisieren.

Öffentliche Repositorys verbieten: Wenn Sie selbst gehostete Runner mit öffentlichen Repositorys verwenden und die Zugriffskontrollen nicht richtig konfigurieren, kann ein Angreifer möglicherweise Zugriff auf Ihren selbst gehosteten Runner-Computer erhalten, indem er eine Pull-Anfrage erstellt, die einen böswilligen Workflow ausführt. Dies kann es dem Angreifer ermöglichen, beliebigen Code auf Ihrem Computer auszuführen, auf vertrauliche Daten zuzugreifen oder andere böswillige Aktionen auszuführen, abhängig von der Zugriffsebene, über die Ihr selbst gehosteter Runner-Computer verfügt.

Ein Angreifer könnte beispielsweise den Code in einer Pull-Anfrage ändern, um Befehle auszuführen, die Malware auf Ihrem selbstgehosteten Runner-Computer installieren oder vertrauliche Daten aus Ihrem Unternehmen stehlen. Dies kann schwerwiegende Folgen haben, einschließlich Datenschutzverletzungen, Verlust geistigen Eigentums und Rufschädigung Ihres Unternehmens.

Um dieses Risiko zu vermeiden, wird empfohlen, selbstgehostete Läufer nur mit privaten Repositorys zu verwenden. Sie können die Angriffsfläche begrenzen und das Risiko eines unbefugten Zugriffs auf Ihre selbst gehostete Runner-Maschine verringern.

Zugriffskontrolle: Sie können einschränken, welche Organisationen und Repositorys auf Runner-Gruppen zugreifen können. Darüber hinaus können Sie die Läufer auf bestimmte Arbeitsabläufe beschränken. Weitere Informationen finden Sie unter „Verwalten des Zugriffs auf selbst gehostete Läufer mithilfe von Gruppen“.

In einem Blogbeitrag von @ryotkak können wir ein Beispiel dafür sehen, wie selbst gehostete Läufer Risiken darstellen und bei falscher Verwendung zum Diebstahl sensibler Informationen führen können. ryotkak zeigt ein Beispiel eines von GitHub erstellten Workflows. Der anfällige Workflow ist Teil des Aktionsframeworks selbst. Unter bestimmten Bedingungen war der selbstgehostete Läufer für jeden Angreifer erreichbar. Der in diesem Beispiel gestohlene Token war ein Token, der einem Entwickler von GitHub selbst gehörte und den Angreifer für einen weitreichenden Angriff auf die Software-Lieferkette hätten nutzen können.

In dieser Demo zeigen wir, wie wir mit einem selbst gehosteten Runner ein öffentliches GitHub-Repository erstellt haben. Dieses Beispiel zeigt einen externen böswilligen Kollaborateur, der mehrere Angriffe durchführt.

Im ersten Bild können wir sehen, dass der Läufer pwn_me zum Läufergruppenpool hinzugefügt wurde.

Unser nächster Schritt bestand darin, einen Workflow zu konfigurieren, der auf unserem selbstgehosteten Läufer läuft und durch den pull_request-Trigger ausgelöst wird:

Jetzt muss ein Angreifer nur noch einen Fork mit einer modifizierten Workflow-Datei erstellen, die die Geheimnisse und sensiblen Informationen des Runners abruft. Ein Beispiel für einen Job, der von einem böswilligen Beitrag erstellt wurde:

Dieses Video zeigt als Beispiel, wie wir einen Pull-Request aus einem Fork erstellt und Zugriff auf die Datei /etc/passwd erhalten haben.

Die folgenden Best Practices sind für alle selbst gehosteten CI/CD-Plattformen relevant. Unabhängig davon, ob Sie GitHub Actions Jenkins, GitLab oder eine andere Plattform verwenden, helfen diese Richtlinien dabei, die Sicherheit Ihrer selbst gehosteten Läufer und Ihrer Software-Lieferkette zu gewährleisten:

Stellen Sie sicher, dass keine vertraulichen Informationen über den Läufer gespeichert werden. Zum Beispiel unter anderem private SSH-Schlüssel und API-Zugriffstoken.

Stellen Sie sicher, dass der Runner über minimalen Netzwerkzugriff auf andere interne Ressourcen verfügt. Zum Beispiel Azure- oder AWS-Verwaltungskonsolen oder Metadatendienste. Verwaltungskonsolen und Metadatendienste sind Panels, die der Cloud-Anbieter bereitstellt, um die Verwaltung der Cloud-Umgebung abzurufen oder Informationen durchzuführen. Ein Angreifer mit Zugriff auf diese Ressourcen kann die Cloud-Konfiguration des Opfers ändern oder seine Angriffsfläche erweitern. Die Menge an vertraulichen Informationen in dieser Umgebung sollte minimal sein. Sie sollten immer bedenken, dass jeder Benutzer, der Workflows aufrufen kann, Zugriff auf diese Umgebung hat.

Stellen Sie sicher, dass alle Dienste im Runner auf dem neuesten Stand und frei von bekannten Schwachstellen sind.

Vermeiden Sie Persistenz – stellen Sie sicher, dass jeder Job auf einem sauberen, frischen Agent-Container/einer sauberen, frischen Agent-Container/VM ausgeführt wird

Wenn Sie Container verwenden, führen Sie diese mit minimalen Berechtigungen aus.

Vermeiden Sie es, Container im privilegierten Modus auszuführen.

Stellen Sie sicher, dass der Container auf dedizierten Geräten bereitgestellt ist und keine Ressourcen mit dem Host teilt.

Führen Sie nur einen einzigen Container pro Host aus.

Verwenden Sie HTTPS für die Kommunikation: Verwenden Sie HTTPS, um die Kommunikation zwischen Ihrem selbst gehosteten Läufer und GitHub zu verschlüsseln, und vermeiden Sie die Verwendung von unverschlüsseltem HTTP.

Insgesamt können selbsthostende CI/CD-Pipelines riskant sein, wenn sie nicht ordnungsgemäß verwaltet werden. Um die potenziellen Gefahren zu minimieren, ist es wichtig, bewährte Sicherheitspraktiken zu befolgen, wie z. B. die regelmäßige Aktualisierung selbstgehosteter Agenten, die Implementierung von Zugriffskontrollen und die Überwachung auf verdächtige Aktivitäten. Darüber hinaus sollten Unternehmen den Einsatz cloudbasierter CI/CD-Dienste in Betracht ziehen, die eine bessere Sicherheit und Zuverlässigkeit bieten als selbst gehostete Lösungen.

Die Legit Security-Plattform stellt eine Verbindung zu Ihrer Build-Umgebung her, um Angriffsversuche in Ihrer Pipeline zu erkennen und vieles mehr. Wir identifizieren verschiedene Fehlkonfigurationen, beispielsweise ein öffentliches Repository, das einen selbst gehosteten Läufer verwendet. Wenn Sie über diese und andere Sicherheitsrisiken in Ihrer Software-Lieferkette besorgt sind, kontaktieren Sie uns bitte, um eine Demo auf unserer Website anzufordern.

*** Dies ist ein syndizierter Blog des Security Bloggers Network von Legit Security Blog, verfasst von Nadav Noy. Lesen Sie den Originalbeitrag unter: https://www.legitsecurity.com/blog/securing-your-ci/cd-pipeline-exploring-the-dangers-of-self-hosted-agents