Einführung
Orca Security hat kürzlich einen Designfehler im Google Cloud Build-Dienst namens „Bad.Build“ entdeckt. Dieser Fehler stellt ein ernstes Sicherheitsrisiko dar, da er Angreifern die Möglichkeit bietet, eine Rechteausweitung durchzuführen und sich so unbefugten Zugang zu den Code-Repositories von Googles Artifact Registry zu verschaffen.
Die Folgen dieser Sicherheitslücke reichen bis in die Software-Lieferkette, da Angreifer sie ausnutzen können, um Anwendungsbilder mit böswilliger Absicht zu manipulieren. Folglich können ahnungslose Benutzer und Kunden, die die manipulierten Anwendungen installieren, Opfer von Infektionen werden.
Diese Situation erinnert uns an die erheblichen Auswirkungen früherer Angriffe auf die Lieferkette wie bei SolarWinds. 3CX und MOVEitund betonte die weitreichenden Folgen solcher Sicherheitslücken.
Wie funktioniert es?
Google Cloud-Build steht für Continuous Integration/Continuous Delivery (CI/CD)-Dienst, der innerhalb des Google Cloud-Ökosystems angeboten wird. Er spielt eine wichtige Rolle in Cloud-basierten Anwendungen, indem er nahtlos mit anderen wichtigen Diensten wie dem Artifact Registry und der App Engine interagiert.
Der vorliegende Fehler resultiert aus einem Problem mit übermäßigen Berechtigungen. Insbesondere die „logging.privateLogEntries.list”-Aktion erlaubt versehentlich die Auflistung von Audit-Protokollen für eine unbeabsichtigte Rolle, nämlich „Rollen/Cloudbuild.Builds.Builder"
Leider ist diese Standardrolle dem Cloud Build Service-Konto zugewiesen. Diese Situation stellt ein großes Risiko dar, da Prüfprotokolle vertrauliche Informationen enthalten, die alle mit dem Projekt verbundenen Berechtigungen offenlegen. Dieser unbeabsichtigte Zugriff gibt Angreifern die Möglichkeit, sich als Cloud Build-Konto auszugeben und so zu erfahren, welche Aktionen von verschiedenen Google-Konten ausgeführt werden können. Folglich öffnet dies die Tür für laterale Bewegungen und Rechteausweitungen, was eine äußerst gefährliche Sicherheitslücke darstellt.
Das Impersonieren des Build-Service-Kontos erfordert nur die cloudbuild.builds.erstellen Berechtigung, die viele vordefinierte Rollen haben und die Entwicklern in jeder vernünftigen CI/CD Umgebung mit Cloud Build. Wenn Sie also Zugriff auf ein solches Entwicklerkonto haben, führt die Erstellung einer maßgeschneiderten Build-Konfigurationsdatei tatsächlich die Befehl „gcloud logging read“, wo die Berechtigungen aufgelistet werden.
Aber das Problem ist noch nicht beendet: die Das Google Cloud Build-Dienstkonto verfügt über hohe Berechtigungen, mit vielen Aktionen zur Interaktion mit dem Artefaktregister von Goggle.
Durch Ausnutzen der Sicherheitslücke, die die Nachahmung des standardmäßigen Cloud Build-Dienstkontos ermöglicht, können böswillige Akteure Bilder manipulieren, die in Googles Artifact Registry gespeichert sind, indem sie bösartigen Code einschleusen. Folglich sind alle Anwendungen, die aus diesen kompromittierten Bildern erstellt werden, anfällig für potenzielle Folgen, darunter Denial-of-Service-Angriffe (DoS), Datendiebstahl und die Verbreitung von Malware.
Der Ernst der Lage verschärft sich, wenn diese manipulierten Anwendungen für den Einsatz in Kundenumgebungen vorgesehen sind, sei es on-premise oder Semi-SaaS. Dies erweitert das Risiko über die Infrastruktur des liefernden Unternehmens hinaus und führt zu einem Angriff auf die Lieferkette, der die Umgebungen der Kunden infiltriert und gefährdet. Solche Angriffe ähneln früheren Vorfällen bei Sicherheitsverletzungen in der Software-Lieferkette, wie beispielsweise der Sicherheitsverletzung bei SolarWinds. Die Folgen eines solchen Angriffs können schwerwiegend sein, weitreichenden Schaden verursachen und mehrere Unternehmen innerhalb der Lieferkette betreffen.
Es gab einen ähnlichen PoC zur Rechteausweitung von Rhino Sicherheitslabore, das die übermäßigen Berechtigungen des Standard-Cloud Build-Kontos auf andere Weise ausnutzte.
Warum ist es gefährlich?
Die Schwere dieser Sicherheitslücke liegt darin, dass Angreifer das Artifact Registry ausnutzen und Schadcode in Artefakte einschleusen können. Dadurch sind alle Anwendungen, die aus diesen kompromittierten Images erstellt werden, anfällig für verschiedene negative Auswirkungen.
Zu diesen Auswirkungen gehören die Möglichkeit von Denial-of-Service-Angriffen, Datendiebstahl und die Verbreitung von Malware. Darüber hinaus, wenn diese kompromittierten Anwendungen anschließend eingesetzt werden on-premise In einer Semi-SaaS-Umgebung geht das Risiko über das betroffene Unternehmen hinaus und betrifft auch dessen Kunden. Dieses Szenario ähnelt dem Supply-Chain-Angriff, der beim SolarWinds-Vorfall beobachtet wurde, und verdeutlicht die potenziellen Folgen sowohl für das Unternehmen als auch für seinen Kundenstamm.
-
Xygeni-Empfehlung
Wenden Sie das Prinzip der geringsten Privilegien an
- Xygeni-Sensor überwacht Benutzeraktionen in den Systemen, in denen es eingesetzt wird, und teilt sie mit unserer Kernplattform, die ungewöhnliches Verhalten oder Abweichungen von normalen Mustern identifiziert, wie z. B. ungewöhnliche login Zeiten oder Orte, große Datenübertragungen oder Änderungen der Benutzerzugriffsrechte, die außerhalb des Bereichs des modellierten „normalen“ Benutzerverhaltens liegen.
Die Richtlinien und Prüfungen von Xygeni setzen bewährte Methoden bei Zugriffskontrollen, Multi-Faktor-Authentifizierungsanforderungen und rollenbasierten Berechtigungsanwendungen durch, um den Benutzerzugriff auf kritische Systeme und Daten zu beschränken.
Diese Tools überwachen Benutzeraktionen wie Codeänderungen, Systemzugriffe oder Datenübertragungen und vergleichen sie mit vordefinierten Richtlinien und Verhaltensmustern. Sie kennzeichnen auch verdächtige Aktivitäten, wie etwa unbefugten Zugriff, übermäßige Berechtigungen oder ungewöhnliche Datenübertragungsmuster..
Wie mit der Sicherheitslücke umgegangen wurde
Nachdem das Google-Sicherheitsteam über die Sicherheitslücke informiert wurde, ergriff es Maßnahmen, indem es die Berechtigung logging.privateLogEntries.list für das Standard-Dienstkonto von Cloud Build widerrief. Sie räumten ein, dass die Prüfprotokolle von setIamPolicy zwar für Prüfzwecke relevant sind, es jedoch aus Sicht des Dienstkontos von Cloud Build unnötig war, Zugriff auf diese Protokolle zu gewähren.
Es ist jedoch wichtig zu verstehen, dass diese Reaktion die grundlegende Schwachstelle im Artifact Registry nicht direkt behob. Infolgedessen blieben der Vektor der Rechteausweitung und das potenzielle Risiko eines Lieferkettenangriffs unberührt. Im Wesentlichen begrenzte Googles Fix das Problem, beseitigte es jedoch nicht vollständig, sodass Unternehmen weiterhin erheblichen Risiken in der Softwarelieferkette ausgesetzt waren.
Als Reaktion auf die Situation riet Google seinen Kunden, die Berechtigungen des standardmäßigen Cloud Build Service-Kontos zu ändern, indem alle Berechtigungsnachweise entfernt werden, die vom Prinzip der geringsten Privilegien (PoLP) abweichen. Diese Maßnahme soll die Sicherheit erhöhen, indem sichergestellt wird, dass Konten nur über die minimal erforderlichen Berechtigungen verfügen, um ihre beabsichtigten Aufgaben auszuführen.
Um sich gegen diesen Angriff mit der Rechteausweitung zu verteidigen, ist es notwendig, die Berechtigungen für das Cloud Build Service-Konto einzuschränken und vorsichtig zu sein bei der Erteilung der cloudbuild.builds.erstellen Berechtigung für alle Benutzer in Ihrer Organisation. Am wichtigsten ist, dass Sie wissen, dass jeder Benutzer, dem die Berechtigung cloudbuild.builds.erstellen, erhält indirekt auch alle Berechtigungen, die dem Cloud Build Service-Konto gewährt werden. Wenn das für Sie in Ordnung ist, müssen Sie sich über diesen Angriffsvektor möglicherweise keine Sorgen machen, es wird jedoch dennoch dringend empfohlen, die dem Cloud Build Service-Konto gewährten Standardberechtigungen zu ändern.
Google empfiehlt dies kurz und bündig, liefert jedoch keine weiteren Einzelheiten:
„Wenn Sie nicht vorhaben, eine Aktion im Rahmen des Build-Prozesses auszuführen, empfehlen wir Ihnen, die entsprechende Berechtigung für das Cloud Build-Dienstkonto zu widerrufen, um dem Sicherheitsprinzip der geringsten Privilegien zu entsprechen.“
Geschichte
Es ist jedoch wichtig zu beachten, dass Googles Abhilfe den entdeckten Privilege Escalation (PE)-Vektor nicht vollständig eliminierte. Stattdessen beschränkte es seine Auswirkungen und verwandelte ihn effektiv in einen Konstruktionsfehler, der Unternehmen immer noch dem größeren Risiko eines Supply-Chain-Angriffs aussetzt. Daher sind zusätzliche Maßnahmen für Sicherheitsteams erforderlich, um sich vor diesem anhaltenden Risiko zu schützen.
Fazit
Angreifer könnten übermäßige Berechtigungen, die dem standardmäßigen Google Cloud Build-Konto gewährt wurden, ausnutzen, um einen Angriff zu starten, indem sie ein Entwicklerkonto verwenden, mit dem sie ein Cloud-Build erstellen können. Angreifer können ein Container-Image exfiltrieren, es mit bösartigem Verhalten manipulieren und es dann in das Artifact Registry übertragen. Dies ist ein Software-Supply-Chain-Angriff, der verheerende Folgen haben kann.
Googles Antwort überlässt die Schadensbegrenzung den Organisationen, die den Cloud Build-Dienst nutzen. Diese müssen die Berechtigungen widerrufen, um das Risiko zu kontrollieren. Man kann Google bitten, in Zukunft zusätzliche Unterstützung bei der Bewältigung von Sicherheitsproblemen zu leisten. CI/CD System.
Referenzen
- Funktioniert wie vorgesehen: RCE-zu-IAM-Berechtigungsausweitung in GCP Cloud Build. Rhino-Sicherheitslabore.
- Bad.Build: PE- und RCE-Schwachstellen in Google Cloud Build. Orca-Sicherheit.
- Sicherheitsbulletin. Google Cloud.
Erfahren Sie mehr über die Xygeni-Plattform. Laden Sie das Datenblatt der Xygeni-Plattform herunter.
