Die Schwachstelle:

Wir haben eine kritische Schwachstelle gefunden, auf die jeder Entwickler achten muss: die Möglichkeit, bösartigen Code direkt in der Produktionsumgebung bereitzustellen. Dies war nicht nur hypothetisch; unsere Beurteilung wurde erfolgreich durchgeführt.

Detailangaben:

Fehlkonfigurierter Bereitstellungsworkflow: Der Kern des Problems liegt in der CI/CD-Pipeline (Continuous Integration/Continuous Deployment). Bei diesem entscheidenden Prozess fehlten die erforderlichen Sicherheitsvorkehrungen, um sicherzustellen, dass jeder bereitgestellte Code gründlich überprüft und genehmigt wurde. Das Fehlen dieser Schutzmaßnahmen ist eine Einladung für Angreifer.

Ausnutzung von Schwachstellen:

Unter Nutzung der Lücken in der CI/CD-Pipeline konnten wir eine NodeJS-Webshell, eine Art bösartiger Code, der einem Angreifer eine Remote-Befehlszeilenschnittstelle zum Webserver bietet, in der Produktionsumgebung bereitstellen. Dies war nicht irgendeine Produktionsumgebung, sondern eine, die sich in einem OCP4-Cluster (OpenShift Container Platform 4) befand, der typischerweise für seine robusten Sicherheitsfunktionen bekannt ist.

Warum ist das geschehen?

Es gibt mehrere Faktoren, die zu dieser Verwundbarkeit beigetragen haben:

Übersicht bei der CI/CD-Konfiguration: Während der Einrichtungsphase wurden wichtige Sicherheitsschritte entweder übersehen oder falsch konfiguriert.
Unterschätzung der Genehmigungsverfahren: Die Verfahren, mit denen sichergestellt werden soll, dass jeder Einsatz geprüft wird, wurden nicht mit dem erforderlichen Stellenwert versehen.
Wissenslücken: Es kann ein Mangel an Verständnis oder Bewusstsein für die schwerwiegenden Bedrohungen durch unkontrollierte Bereitstellungen innerhalb des für diese Systeme verantwortlichen Teams gegeben haben.

Abhilfe schaffen:

Um diese klaffende Sicherheitslücke zu schließen, empfehlen wir folgende Schritte:

Obligatorische Überprüfung und Genehmigung: Führen Sie eine eiserne Regel ein, dass kein Code die Produktion erreicht, ohne einen strengen Überprüfungs- und Genehmigungsprozess durchlaufen zu haben.
Pipeline-Audits: Machen Sie es zu einer Routine, die CI/CD-Pipeline zu durchkämmen und nach Fehlkonfigurationen oder Sicherheitsschritten zu suchen, die möglicherweise übersprungen wurden.
Aufklärung und Sensibilisierung: Fördern Sie eine Sicherheitskultur, indem Sie die Entwicklungs- und Betriebsteams über die Risiken unkontrollierter Bereitstellungen aufklären.
Automatisierte Sicherheitstools: Verwenden Sie fortschrittliche Tools, die nicht autorisierte oder anormale Änderungen während des Entwicklungs- und Bereitstellungsprozesses automatisch erkennen und blockieren.

Dieser Vorfall unterstreicht die Notwendigkeit von Wachsamkeit und strengen Sicherheitsprotokollen in der heutigen digitalen Landschaft. Es ist ein Aufruf zum Handeln für Unternehmen, ihre Cybersicherheitsstrategien neu zu bewerten und zu stärken.

Die versteckten Gefahren von gefundenen, nicht gescannten Secrets in GitHub-Repositorys

Im Bereich des Quellcode-Managements ist GitHub ein Titan, der Millionen von Code-Repositories hostet. Es ist jedoch wichtig zu wissen, wie man Daten in Repositories speichert. Wir haben eine erhebliche Sicherheitsfehlkonfiguration gefunden und hervorgehoben: das Fehlen eines ordnungsgemäß konfigurierten Secret-Scans. Diese Aufsicht unterstreicht die Bedeutung der Einhaltung von Best Practices bei der Repository-Verwaltung, um die Datenintegrität und -sicherheit zu gewährleisten.

Die Schwachstelle:

Unsere Bewertung hat ergeben, dass das geheime Scannen, eine automatisierte Funktion in GitHub (https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning), die darauf abzielt, sensible Informationen wie Passwörter und private Schlüssel zu erkennen, nicht aktiviert wurde. Darüber hinaus wurde kein Schutz und keine Erkennung gegen das Speichern sensibler Daten in Repositories angewendet. Dadurch sind Repositories anfällig für die versehentliche Offenlegung sensibler Daten.

Detailangaben:

Enthüllte Geheimnisse: Ohne Secret-Scannen können sensible Daten versehentlich in öffentliche oder private Repositories übertragen werden, was ein erhebliches Sicherheitsrisiko darstellt.

Mögliche Auswirkungen:

Datenschutzverletzung: Enthüllte Secrets sind eine Goldgrube für Angreifer, die möglicherweise zu Datenschutzverletzungen und unbefugtem Zugriff auf andere Dienste führen.
Kompromittierung der Infrastruktur: Zugriffstoken, SSH-Schlüssel und andere Anmeldeinformationen könnten ausgenutzt werden und nicht nur die Repositories, sondern auch die Infrastruktur und Dienste, mit denen sie interagieren, gefährden.

Warum ist das geschehen?

Die mangelnde Konfiguration des Secret-Scannens kann auf Folgendes zurückzuführen sein:

Mangelndes Bewusstsein: Entwickler und Repository-Administratoren sind sich der Funktion oder ihrer Bedeutung möglicherweise nicht bewusst.
Fehlkonfiguration: Bei der Einrichtung des Repositorys oder während der Migration zwischen Systemen wurden möglicherweise Konfigurationen wie das Scannen von Secrets übersehen.
Ausgaben und Fachwissen: Eine Lizenz für geheime Scan-Funktionen von Github muss erworben werden, was kostspielig sein kann, was zu einer weniger sicheren Umgebung führt. Fachwissen ist in Bezug auf CI/CD und Sicherheit wichtig, daher sind Experten für die Kontrolle und Einhaltung der Regeln verantwortlich, um ein Höchstmaß an Sicherheit zu gewährleisten.

Abhilfe schaffen:

Um diese Sicherheitsanfälligkeit zu verringern, sollten sofort die folgenden Schritte unternommen werden:

Aktivieren Sie das geheime Scannen: Aktivieren Sie das geheime Scannen für alle GitHub-Repositories, um festgelegte Secrets in Echtzeit zu erkennen. Märkte bieten verschiedene Lösungen, die Ihren Präferenzen entsprechen können.
Schulung und Ausbildung: Bieten Sie Entwicklern Schulungen zu sicheren Codierungspraktiken und zur Wichtigkeit, Secrets aus Code-Repositories fernzuhalten.
Automatische Entfernung von Secrets: Implementieren Sie Tools, die entlarvte Geheimnisse automatisch widerrufen und neu ausgeben.
Richtliniendurchsetzung: Legen Sie Richtlinien fest, die die Aufnahme von Secrets in den Code verbieten, und erzwingen Sie sie mit automatisierten Kontrollen.

Es ist wichtig zu erkennen, dass die Sicherung von Code-Repositories genauso wichtig ist wie die Sicherung der Infrastruktur, für die sie bereitgestellt werden.

Umgehung des Zweigstellenschutzes von Github: Eine Sicherheitsanfälligkeit mit hohem Risiko aufgedeckt

Vor kurzem haben wir einen bekannten Bypass verwendet, um GitHub Actions Branch Protection Rules auszunutzen, eine Funktion, die für die Aufrechterhaltung der Integrität von Code in mehreren Entwicklungsumgebungen von entscheidender Bedeutung ist.

Die Schwachstelle:

Im Wesentlichen dreht sich diese Sicherheitsanfälligkeit um die unbefugte Umgehung von Branch-Schutzmechanismen in Github. Branch-Schutzregeln sind entscheidend, um sicherzustellen, dass Änderungen an wichtigen Filialen ordnungsgemäße Überprüfungen und Genehmigungen erfordern. Ein bekannter Bypass, den wir im System von GitHub verwendet haben, ermöglicht die Ausnutzung von GitHub-Aktionen, um den obligatorischen Überprüfungsprozess zu umgehen. Dieser Verstoß ermöglicht das unbefugte Einfügen von nicht überprüftem Code in einen sicheren Branch. Eine solche Lücke könnte zur unbeabsichtigten Verwendung von schädlichem Code durch andere Benutzer oder zur unbeabsichtigten Integration in die Produktionspipeline führen.

Detailangaben:

Bypass-Mechanismus: Bei der Ausnutzung wurden die Berechtigungen von Github-Aktionen ausgenutzt. Durch die Verwendung von Schreibberechtigungen für den Pull-Requests-API-Endpunkt können wir eine Pull-Request erstellen, um bösartigen Code in einen geschützten Branch zusammenzuführen. Obwohl ein solcher Pull-Request in der Regel nicht ohne Genehmigung zusammengeführt werden kann, könnte der Github-Actions-Bot, der mit dem GITHUB_TOKEN verknüpft ist, ihn genehmigen. Da der Bot kein Organisationsmitglied ist, aber immer noch für Genehmigungszwecke zählt, ermöglicht er es einem Angreifer, die Pull-Anforderung selbst zu genehmigen und die Branch-Schutzmechanismen effektiv zu umgehen. Dieser Verstoß ermöglicht das unbefugte Einfügen von nicht überprüftem Code in einen sicheren Branch. Eine solche Lücke führt uns zu einer nicht autorisierten Code-Integration in die Produktionsumgebung.

Risiken und Bedrohungen:

Unerlaubte Codeänderungen an geschützten Branches.
Bereitstellung von bösartigem Code in der Produktion und anderen Umgebungen.
Kompromittierte Anwendungsintegrität und -zuverlässigkeit.
Schadet dem Vertrauen in den Bereitstellungsprozess und die gesamte Infrastruktur.

Warum ist das geschehen?

Dieses Problem ergibt sich aus einer Lücke in den Einstellungen von Github, die es GitHub Actions ermöglichte, Pull-Anfragen zu genehmigen, ein Standard, der in bestehenden Organisationen nicht sicher war.

Abhilfe schaffen:

Um diesem erheblichen Risiko zu begegnen, werden folgende Lösungen vorgeschlagen:

Github-Einstellungen aktualisieren: Verwenden Sie die Github-Einstellung, die es Github-Aktionen untersagt, Pull-Anfragen zu genehmigen. Dies muss unternehmensweit festgelegt werden, um wirksam zu sein.

Genehmigungen überprüfen: Durchsetzen von Pull-Request-Überprüfungen von Code Ownern, um sicherzustellen, dass alle Änderungen von autorisiertem Personal überprüft wurden.
Erhöhen Sie die Genehmigungsanforderungen: Ändern Sie die Anzahl der erforderlichen Genehmigungen auf zwei oder mehr, was eine zusätzliche Sicherheitsebene hinzufügt, da mehrere Prüfer erforderlich sind.

Diese Schwachstelle unterstreicht die entscheidende Bedeutung ständiger Wachsamkeit und regelmäßiger Aktualisierungen der Sicherheitskonfigurationen in allen Aspekten des Entwicklungsbetriebs. Durch die Umsetzung der empfohlenen Änderungen können Unternehmen ihren Code vor solchen Sicherheitslücken schützen und das Vertrauen in ihre Bereitstellungsprozesse stärken.

Artifactory Service-Konfiguration - Unbeabsichtigter offener Datenzugang

Die Integrität jeder Entwicklungspipeline hängt von der Sicherheit und dem kontrollierten Zugriff auf ihre Artefakte ab. Bei einer kürzlich durchgeführten Sicherheitsbewertung ist es uns gelungen, eine klaffende Lücke im Artifactory-Dienst zu nutzen, um uns ohne ausdrückliche Genehmigung anzumelden.

Die Schwachstelle:

Artifactory ermöglicht es jedem Domänenbenutzer, sich anzumelden, ohne explizite Berechtigungen zu benötigen. Nach der Anmeldung kann der Benutzer Artefakte anzeigen, herunterladen und Schwachstellenberichte von Xray-Scans überprüfen, die sich auf die Repositories beziehen.

Detailangaben:

Übermäßig zulässige Zugriffskontrollen: Die Standardkonfiguration erlaubte jedem Benutzer innerhalb der Domäne, auf den Artifactory-Dienst zuzugreifen. Diese Art der Konfiguration vernachlässigt das Prinzip der geringsten Privilegien, das für die Sicherung sensibler Daten unerlässlich ist.

Auf diese Weise werden jedem Domänenbenutzer viele sensible Informationen zur Verfügung gestellt. Die Fähigkeit zu erkennen, welche Anwendungen kritische Schwachstellen enthalten, kann von böswilligen Akteuren genutzt werden, um diese Schwachstellen auszunutzen. Darüber hinaus können Artefakte sensible Daten enthalten, da kein vorgeschriebenes Scannen solcher Daten erfolgt.

Risiken und Folgen:

Unbefugter Zugriff auf sensible Artefakte.
Möglicher Datenverlust.
Erosion der Datenintegrität.
Erhöhtes Risiko von Insider-Bedrohungen.

Warum ist das geschehen?

Die Gründe für diese Fehlkonfiguration können sein:

Fehlende rollenbasierte Zugriffskontrollen (RBAC): Unzureichend definierte Benutzerrollen und -berechtigungen könnten zu einem so weit offenen Zugriff führen.

Abhilfe schaffen:

Die Behebung dieser Schwachstelle erfordert eine strategische Überarbeitung der Zugriffsberechtigungen:

RBAC implementieren: Definieren Sie Benutzerrollen präzise und weisen Sie Berechtigungen zu, die mit dem Prinzip der geringsten Berechtigungen übereinstimmen.
Zugriffsprotokolle überwachen: Überprüfen Sie regelmäßig Zugriffsprotokolle, um unbefugte Versuche oder Zugriffe auf den Dienst zu überwachen.
Kontinuierliche Überwachung: Implementieren Sie Echtzeit-Überwachungstools, um ungewöhnliche Zugriffsmuster zu erkennen und zu warnen.
Regelmäßige Zugriffsüberprüfungen: Überprüfen Sie regelmäßig die Benutzerzugriffsrechte, um sicherzustellen, dass sie der Rolle und den Verantwortlichkeiten jedes Benutzers entsprechen.

Das Risiko einer künstlichen Datenexposition erinnert eindringlich daran, dass selbst die vertrauenswürdigsten Dienste innerhalb der Entwicklungspipeline auf Sicherheitslücken untersucht werden müssen. Durch entschlossene Maßnahmen zur Korrektur dieser Fehlkonfigurationen können Unternehmen ihre Abwehr gegen externe und interne Bedrohungen verstärken.

OpenShift-Fehlkonfiguration: Uneingeschränkter Host-Netzwerkzugriff vom POD

Die Agilität und Skalierbarkeit von containerisierten Umgebungen kann auch erhebliche Sicherheitsrisiken mit sich bringen, wenn sie nicht ordnungsgemäß verwaltet wird. Eine kürzlich durchgeführte Bewertung hat Aufschluss über eine schwerwiegende Fehlkonfiguration innerhalb eines OpenShift-Clusters gegeben und eine Schwachstelle aufgezeigt, die schwerwiegende Auswirkungen auf die Netzwerksicherheit haben könnte.

Die Schwachstelle:

Im Rampenlicht steht ein Konfigurationsfehler in OpenShift, einer beliebten Container-Orchestrierungsplattform. Diese Fehlkonfiguration ermöglichte es Pods (die kleinsten einsetzbaren Recheneinheiten, die in OpenShift erstellt und verwaltet werden können), die IP-Adresse des Host-Computers und sogar das gesamte Host-Subnetz zu erreichen. Laienhaft ausgedrückt: Wenn ein Pod kompromittiert würde, hätte der Angreifer uneingeschränkten Zugriff auf potenziell sensible interne Netzwerkressourcen.

Detailangaben:

Weitreichende Netzwerksichtbarkeit: Diese Fehlkonfiguration war nicht trivial; sie bedeutete, dass ein bereitgestellter Pod in OpenShift eine Vielzahl interner Systeme sehen und möglicherweise mit ihnen interagieren konnte. Diese Art von Zugang ist vergleichbar damit, jemandem die Schlüssel zum Königreich zu geben, und könnte mit verheerender Wirkung ausgenutzt werden.

Risiken und Folgen:

Potenzial für eine weit verbreitete interne Netzwerkaufklärung durch einen kompromittierten Pod.
Erhöhtes Risiko von seitlichen Bewegungen innerhalb des Netzwerks, was dazu führt, dass mehr Systeme kompromittiert werden.
Datenschutzverletzungen durch Zugriff auf sensible interne Systeme.
Kompromittierte Netzwerkintegrität und Sicherheitslage.

Warum ist das geschehen?

Die Grundursache für diese Fehlkonfiguration könnte sein:

Unzureichende Netzwerkrichtlinien: Mangel an strengen Netzwerkrichtlinien, um den Netzwerkzugriff der PODs auf nur notwendige Ressourcen und Dienste innerhalb des eigenen Subnetzes zu beschränken
Fallstricke bei der Standardkonfiguration: Standardeinstellungen, die eine einfache Bereitstellung gegenüber der Sicherheit begünstigen, die nach der Bereitstellung nicht erneut überprüft und ordnungsgemäß gesichert werden.

Abhilfe schaffen:

Um diese gefährliche Aufsicht zu korrigieren, sollten Organisationen die folgenden Maßnahmen ergreifen:

Netzwerksegmentierung: Implementieren Sie Netzwerkrichtlinien, die spezifisch definieren, welche Netzwerkverbindungen für jeden Pod zulässig sind, basierend auf dem Prinzip der geringsten Berechtigung.
Regelmäßige Sicherheitsaudits: Führen Sie regelmäßige Überprüfungen der Netzwerkkonfigurationen innerhalb der OpenShift-Umgebung durch, um die Einhaltung der Best Practices für die Sicherheit sicherzustellen.
Pod-Sicherheitsstandards: Annahme und Durchsetzung von Pod-Sicherheitsstandards, die die Fähigkeiten und den Zugriff von Pods einschränken, insbesondere solche, die in der Produktionsumgebung ausgeführt werden.
Sicherheitstraining: Bieten Sie fortlaufende Schulungen für das Personal über die potenziellen Risiken von Fehlkonfigurationen und die Bedeutung sicherer Bereitstellungspraktiken.

Dieses Beispiel der OpenShift-Fehlkonfiguration dient als Warnung vor der kritischen Notwendigkeit strenger Netzwerksicherheitspraktiken in containerisierten Umgebungen. Durch sorgfältiges Management und ständige Wachsamkeit können Unternehmen ihre Netzwerke vor solchen Schwachstellen schützen.

Schwachstellen der GitHub-Konfiguration: Ein Tor zu nicht autorisierten Bereitstellungen

Die Schwachstelle:

Vor kurzem haben wir ein eklatantes Problem in der Repository-Konfiguration von GitHub hervorgehoben, bei dem Quellcodes von Anwendungen in einer GitHub-Organisation gespeichert wurden, was die Tür zu einer Schwachstelle öffnet, die zu nicht autorisierten und potenziell schädlichen Bereitstellungen führen könnte.

Detailangaben:

Der Kern dieses Problems liegt in der Permissivität der Standard-Repository-Konfigurationen und dem Fehlen strenger Flusskontrollmechanismen. Da es keine Zweigschutzregeln, keine Umgebungen mit Schutzregeln und Geheimnissen gibt, ermöglicht diese Situation jedem, der Schreibzugriff auf das Repository hat, potenziell bösartige Aktivitäten auszuführen, wie das Lesen aller Geheimnisse, das Erstellen von Artefakten (einschließlich bösartiger), das Entfernen statischer Quellcodeanalyseprüfungen in der Pipeline und möglicherweise das Ausnutzen selbst gehosteter Runner.

Risiken und Folgen:

Zugriff auf alle Geheimnisse, die dem CI-Job zur Verfügung stehen, wie z. B. Geheimnisse, die als Umgebungsvariablen injiziert werden, oder zusätzliche Geheimnisse, die im CI gespeichert sind. CI/CD-Systeme sind für den Aufbau von Code und die Bereitstellung von Artefakten verantwortlich und enthalten in der Regel Dutzende von hochwertigen Anmeldeinformationen und Token – z. B. für einen Cloud-Anbieter, Artefaktregister und das SCM selbst.
Zugriff auf externe Assets, auf die der Runner Zugriff hat, z. B. Dateien, die im Dateisystem des Knotens gespeichert sind, oder Anmeldeinformationen für eine Cloud-Umgebung, auf die über den zugrunde liegenden Host zugegriffen werden kann.
Fähigkeit, Code und Artefakte weiter unten in der Pipeline zu versenden, unter dem Deckmantel legitimen Codes, der durch den Build-Prozess erstellt wurde.
Möglichkeit, auf zusätzliche Hosts und Assets im Netzwerk/in der Umgebung des Job-Node zuzugreifen.

Warum ist das geschehen?

Dieses Problem ergibt sich oft aus:

Unzureichende Repository-Einstellungen: Standardeinstellungen, die auf Komfort und Sicherheit ausgerichtet sind, können Repositories anfällig machen.
Vernachlässigung der Flusskontrolle: Unzureichende Maßnahmen, um sicherzustellen, dass Änderungen einen strengen Genehmigungsprozess durchlaufen, bevor sie zusammengeführt oder bereitgestellt werden.

Abhilfe schaffen:

Um solche unbefugten Einsätze zu verhindern und die Sicherheit zu erhöhen, werden folgende Schritte empfohlen:

Artifactory - Einsatz anfälliger Artefakte

Als nächstes ging es darum, eine Schwachstelle in der Art und Weise aufzudecken, wie Artefakte verwaltet und bereitgestellt werden. Dieses Problem könnte, wenn es nicht kontrolliert wird, den Weg für erhebliche Sicherheitsbedrohungen in Produktionsumgebungen ebnen.

Die Schwachstelle:

Während des Bereitstellungsprozesses von Artefakten, die in Artifactory gespeichert sind, haben wir festgestellt, dass Artefakte, auch solche mit kritischen oder hochgradigen Schwachstellen, ohne eine Überprüfung vor der Bereitstellung in Produktionsumgebungen bereitgestellt werden können. Dieser Fehler im Verifizierungsprozess lässt die Produktionsumgebung für potenzielle Sicherheitsverletzungen offen.

Artifactory X-Ray: Node. Js Webshell-Docker-Image mit kritischer Schwachstelle. Später in der Produktion eingesetzt

Wir sind uns bewusst, dass das Blockieren aller anfälligen Artefakte den Build-/Bereitstellungsprozess stören und geschäftliche Auswirkungen haben könnte. Dennoch sollten diese Schwachstellen zumindest vor dem Einsatz überprüft und genehmigt werden, um das Risiko der Einführung von Sicherheitslücken in die Produktionsumgebung zu verringern.

Auswirkung:

Die potenziellen Auswirkungen des Einsatzes gefährdeter Artefakte sind weitreichend und alarmierend:

Erhöhtes Cyber-Angriffsrisiko: Der Einsatz von Artefakten mit Schwachstellen direkt in der Produktion erhöht die Wahrscheinlichkeit von Cyber-Angriffen.
Kompromittierung des Geschäftsbetriebs: Die Ausnutzung kritischer Schwachstellen könnte wichtige Geschäftsabläufe stören oder sogar gefährden.
Ordnungswidrigkeit: Solche Praktiken können gegen Industriestandards oder Vorschriften verstoßen, die ein effektives Schwachstellen- und Patch-Management vorschreiben.

Die Lösung:

Um diese Risiken zu mindern, werden folgende Maßnahmen dringend empfohlen:

Schwachstellen-Scan-Prozess: Implementieren Sie einen Prozess, der alle Artefakte vor der Bereitstellung in der Produktionsumgebung auf hohe oder kritische Schwachstellen scannt. Dieser Prozess sollte eine obligatorische Genehmigung für die Bereitstellung von Artefakten mit identifizierten Schwachstellen beinhalten.
Verwendung von Xray: Konfigurieren Sie in Xray Richtlinien, um Probleme mit hohen/kritischen Schwachstellen zu identifizieren. Vermeiden Sie zunächst Aktionen wie fehlgeschlagene Builds oder das Verhindern von Downloads, sondern konzentrieren Sie sich stattdessen darauf, jede Verletzung zu sortieren.
Umfassendes Patch-Management: Etablieren Sie ein robustes Patch-Management-System, um die rechtzeitige Erkennung, Bewertung und Behebung von Schwachstellen in Artefakten zu gewährleisten.

Zusammenfassung:

Unser Ziel war es, alle Sicherheitsmaßnahmen zu umgehen und Schadcode in der Produktionsumgebung mit Wissen und Zugriff auf die OCP4-Konfiguration und die gesamte CI/CD-Pipeline und den zugewiesenen Namespace im Cluster bereitzustellen.

Wir haben festgestellt, dass das Szenario durch Ausnutzung einer Kette von Fehlkonfigurationen und Schwachstellen realisierbar ist, die in den folgenden Abschnitten speziell beschrieben werden:

Github - Nicht autorisierte Umgehung von Branch-Schutzmechanismen
Github - Permissive Standard-Repository-Konfiguration und unzureichende Flusskontrollmechanismen
Artifactory - Einsatz anfälliger Artefakte

Am Ende war es uns gelungen, die bösartige Anwendung - NodeJS-Webshell - in einer Produktionsumgebung innerhalb eines OCP4-Clusters bereitzustellen. Wir möchten die Bedeutung der Verantwortung der Entwickler hervorheben und wie eine Kombination kleiner Schwachstellen zu einer kritischen Situation führen kann, in der all die harte Arbeit und die Sicherheit von Unternehmen in Gefahr sein können.

Sind Sie sich bei der Sicherheit Ihres Pipelines nicht sicher? Testen Sie es mit uns.

Blog