Die meisten Teams betrachten eine Schwachstelle zur Rechteausweitung als einen Kernel-Fehler oder einen missbrauchten sudo auf einem Produktionsserver. Im Jahr 2026 befindet sich die gefährlichere Version an einem anderen Ort: im pipeline Das erstellt und versendet Ihren Code. CI/CD Dieser Job verfügt routinemäßig über Schreibzugriff auf Ihre Repositories, Tokens für Ihre Paketregistrierungen und Anmeldeinformationen für Ihre Cloud. Ein Angreifer, der Code innerhalb dieses Jobs ausführt, benötigt keine großen Eskalationsschritte. pipeline hat es bereits für sie erledigt.
Dieser Leitfaden erklärt, wie eine Schwachstelle zur Rechteausweitung aussieht. CI/CD pipelineEr behandelt s und Container, geht die häufigsten Angriffspfade von Angreifern durch und zeigt, wie man jeden einzelnen davon schließt.
Kurz gesagt: Schwachstelle zur Rechteausweitung in CI/CD pipelines
Kurz und pipelineDer Angreifer muss seine Berechtigungen oft nicht erweitern. pipeline besitzt sie bereits. Eine Schwachstelle zur Rechteausweitung in CI/CD ist in der Regel eine Berechtigung, die weiter gefasst ist als für den jeweiligen Job erforderlich, und darauf wartet, dass nicht vertrauenswürdiger Code darin ausgeführt wird.
- Pipelines sind per Definition privilegiert. Sie lesen Quellcode, besitzen Geheimnisse, veröffentlichen Artefakte und stellen diese in der Produktion bereit, was sie zu einem der wertvollsten Eskalationsziele in Ihrem Unternehmen macht.
- Die meisten Eskalationswege beruhen auf Fehlkonfigurationen, nicht auf Exploits. Weit verbreitete Standardtoken,
pull_request_targetWorkflows, die Fork-Code ausführen, und langlebige Cloud-Schlüssel richten mehr Schaden an als jede Zero-Day-Schwachstelle. - Durch die Eskalation von Container-Berechtigungen wird aus einem Job der gesamte Runner. Privilegierte Container, Root-Benutzer und ein eingebundener Docker-Socket machen den Build-Container zu einer Tür, nicht zu einer Grenze.
- Das geschieht bereits in großem Umfang. Der CHAINDROP-Wurm nutzte erhöhte Zugriffsrechte auf GitHub Actions-Runner, um Anmeldeinformationen direkt aus dem Runner-Speicher auszulesen.
- Die Lösung besteht im Prinzip der minimalen Rechtevergabe, das konsequent durchgesetzt wird. Jedes Token muss geschützt, jeder Container gehärtet und Berechtigungsabweichungen erkannt werden, bevor ein Angreifer sie entdeckt.
Was ist eine Schwachstelle?
Eine Schwachstelle zur Rechteausweitung ist jede Sicherheitslücke, die es einem Benutzer, Prozess oder Codeabschnitt ermöglicht, Berechtigungen zu erlangen, die über die vorgesehenen hinausgehen. MITRE ATT&CK verfolgt dies als eigene Taktik. TA0004: RechteausweitungDenn es ist der Schritt, der aus einem kleinen Halt echten Schaden macht.
Es gibt zwei klassische Formen:
- Vertikale Eskalation: beim Aufstieg, beispielsweise vom normalen Benutzer zum Root-Benutzer oder vom schreibgeschützten Token zum beschreibbaren Token.
- Horizontale Eskalation: Seitwärtsbewegung, zum Beispiel durch Nutzung der Zugriffsrechte eines Jobs, um auf das Repository, die Geheimnisse oder die Umgebung eines anderen Teams zuzugreifen.
Angreifer nutzen eine Schwachstelle zur Rechteausweitung durch drei Arten von Sicherheitslücken aus: Softwarefehler, Fehlkonfigurationen und übermäßige Berechtigungen. Auf Servern erhalten Fehler die größte Aufmerksamkeit. CI/CD pipelineFehlkonfigurationen und übermäßige Berechtigungen sind fast die Hauptursache.
Warum es so gefährlich ist CI/CD pipelines
A pipeline ist nicht nur ein Build-Tool. Es ist eine automatisierte Identität mit weitreichenden Zugriffsrechten in Ihrem Unternehmen. Ein typischer Job kann Folgendes umfassen:
- Quellcode ansehen und bearbeiten
- Geheimnisse aus Umgebungsvariablen, Tresoren und Cloud-Metadatendiensten lesen
- Pakete, Images und Release-Artefakte veröffentlichen
- Bereitstellung in Staging- und Produktionsumgebung
Das OWASP Top 10 CI/CD Sicherheitsrisiken Dieses Problem wird direkt benannt. Sein Risiko CICD-SEC-5: Unzureichend Pipeline-basierte Zugriffskontrollen beschreibt, wie Angreifer, die bösartigen Code in einem ausführen, pipeline missbrauchen Sie die ihm erteilten Berechtigungen zur seitlichen Bewegung innerhalb oder außerhalb des CI/CD System.
Dies ist keine Theorie. Während der CHAINDROP-Kampagne im August 2026 wurde die Schadsoftware eingesetzt. Temporäre Anmeldeinformationen aus dem Speicher des GitHub Actions Runners extrahiert. und nutzten gestohlene Veröffentlichungstoken, um weitere Pakete zu infizieren. Auf Linux-Runnern war die Payload Der Collector wurde mit sudo ausgeführt um den Speicher des Runner-Prozesses zu lesen. Das ist eine Rechteausweitung in CI/CD pipelineS in seiner reinsten Form: eine vergiftete Abhängigkeit, privilegierter Zugang zum Runner und jedes Geheimnis, das der Job berühren könnte. Es ist dasselbe Muster, das wir in unseren wöchentlichen Erkenntnissen sehen. bösartige npm-Pakete.
Wo versteckt sich eine Schwachstelle zur Rechteausweitung in einem pipeline?
Sechs gängige Angriffswege, was jeder einzelne einem Angreifer ermöglicht und welche Kontrollmechanismen ihn schließen.
| Eskalationspfad | Wie es passiert | Was der Angreifer erhält | Wie man es schließt |
|---|---|---|---|
| Überprivilegiert pipeline Zeichen | Workflows werden mit breiten Standard-Tokenbereichen ausgeführt, weil keine permissions Block ist gesetzt | Schreibzugriff auf Code, Releases und andere Workflows | Legen Sie standardmäßig den Nur-Lese-Modus fest und gewähren Sie Schreibzugriff pro Auftrag nur bei Bedarf. |
| Vergiftet pipeline Ausführung | pull_request_target oder ähnliche Auslöser checken Code aus einem nicht vertrauenswürdigen Fork aus und führen ihn aus | Repository-Geheimnisse und ein Schreibtoken, von einem einzigen pull request | Führe Fork-Code niemals in einem privilegierten Kontext aus; trenne vertrauenswürdige und nicht vertrauenswürdige Jobs. |
| Eskalation von Containerrechten | Build-Container, die als Root, im privilegierten Modus oder mit eingebundenem Docker-Socket ausgeführt werden. | Root-Zugriff auf den Runner-Host und Zugriff auf alle von ihm ausgeführten Jobs. | Als Nicht-Root ausführen, Berechtigungen einschränken und Rechteausweitung in der Containerspezifikation blockieren |
| Langlebige Cloud-Zugangsdaten | Statische Cloud-Schlüssel, die als Geheimnisse oder Umgebungsvariablen gespeichert werden | Dauerhafter Zugriff auf Cloud-Konten, auch lange nach Beendigung des Auftrags | Verwenden Sie kurzlebige, föderierte Anmeldeinformationen und automatisch gesperrte Geheimnisse widerrufen |
| Persistente selbstgehostete Runner | Runner werden job- und repositoryübergreifend wiederverwendet, ohne neu erstellt werden zu müssen. | Beharrlichkeit und die Fähigkeit, die Strategien anderer Teams zu manipulieren. | Verwenden Sie kurzlebige Runner und isolieren Sie diese pro Vertrauensstufe. |
| Berichte über überprivilegierte Menschen | Inaktive Administratoren, externe Mitarbeiter und ungeprüfte Berechtigungsänderungen häufen sich. | Ein gültiges Konto, das sich ändern kann pipelines und Zweigschutz | Überprüfen Sie die Zugriffsrechte kontinuierlich und geben Sie Warnungen bei ungewöhnlichen Berechtigungsänderungen aus. |
Rechteausweitung im Container: wenn der Build-Container keine Grenze ist
Container vermitteln ein Gefühl der Isolation, daher behandeln Teams sie oft als Sicherheitsgrenze. CI/CDDas ist häufig nicht der Fall. Eine Rechteausweitung in einem Container tritt auf, wenn Code innerhalb eines Build-Containers die Kontrolle über den Host und damit über alle anderen dort ausgeführten Prozesse erlangt.
Drei Einstellungen decken die meisten Fälle ab:
- Als Root ausgeführt. Wenn der Prozess innerhalb des Containers root ist, beginnt jeder Ausbruch von der bestmöglichen Position aus.
- Privilegierter Modus. Ein privilegierter Container hat nahezu die gleichen Zugriffsrechte auf den Host wie ein Prozess, der direkt darauf ausgeführt wird.
- Ein eingebundener Docker-Socket. Montage
/var/run/docker.sockin einen Job, damit er Images effektiv erstellen kann. Übergibt diesem Job Root-Rechte auf dem Host, da er neue privilegierte Container starten kann.
Sicherheitsforscher haben gezeigt, wie sich dies in realen CI-Systemen auswirkt. In einem gut dokumentierten Fall gingen Forscher von Build-Skripten, die innerhalb eines CI-Containers liefen, zu einem Vollständiger Container-Escape auf den Build-Hosts von Cloudflare Pages, Vorciswahrscheinlich, weil der Container als Sicherheitsgrenze behandelt wurde.
So sieht eine gehärtete Kubernetes-Jobspezifikation aus. Die wichtigste Einstellung ist allowPrivilegeEscalation: false, Die verhindert, dass ein Prozess mehr Berechtigungen als sein übergeordneter Prozess erlangt.zum Beispiel durch Setuid-Binärdateien.
# Gehärteter Build-Pod: Blockiert die häufigsten Wege zur Rechteausweitung in Containern apiVersion: v1 Art: Schote Metadaten: Name: ci-build spec: Sicherheitskontext: runAsNonRoot: was immer dies auch sein sollte. runAsUser: 10001 seccompProfile: tippe: RuntimeDefault Behälter: - Name: bauen Image: registry.example.com/build-image@sha256: Sicherheitskontext: Erweitern Sie Ihre Berechtigungen: falsch privilegiert: falsch readOnlyRootFilesystem: was immer dies auch sein sollte. Ressourcen:
Das gleiche Prinzip gilt auch für die Dockerfile selbst. Fügen Sie einen Benutzer hinzu, der kein Root-Benutzer ist, und wechseln Sie vor dem Einstiegspunkt zu diesem:
# Führe den Container als Nicht-Root-Benutzer aus AB node:22-slim RENNE useradd --uid 10001 --create-home Baumeister ARBEITSVERZEICHNIS / app COPY --chown=Bauherr:Bauherr . . USER Baumeister CMD ["Knoten", "index.js"]
Die Kubernetes-Dokumentation auf Konfigurieren eines Sicherheitskontexts behandelt jede dieser Einstellungen im Detail.
GitHub Actions: Eine Eskalationslücke, die sich direkt vor unseren Augen verbirgt
Bei GitHub Actions stoßen viele Teams zum ersten Mal auf eine Rechteausweitung. CI/CD pipelineDenn die gefährlichen Muster sehen völlig normal aus. Zwei davon sollten heute in jedem Repository überprüft werden.
Token-Bereich. Jeder Workflow erhält einen GITHUB_TOKENDie eigenen Richtlinien von GitHub zu automatische Token-Authentifizierung Es ist klar: Eine Aktion kann dieses Token auch dann erreichen, wenn Sie es nicht explizit übergeben. Daher sollten Sie die Berechtigungen stets auf das absolute Minimum beschränken. Durch das Festlegen von Leseberechtigungen am Anfang des Workflows und das Gewähren von Schreibzugriff pro Auftrag wird der häufigste Eskalationspfad mit einem Schritt beseitigt:
Name: bauen on: [drücken] # Standardeinstellung für jeden Job: Nur-Lese-Modus Berechtigungen: Inhalt: besuch Jobs & Karriere: Test: läuft auf: ubuntu-latest Schritte: # Aktionen von Drittanbietern an eine vollständige commit SHA, kein veränderliches Tag - verwendet: Aktionen/Checkout@commit-sha> - Lauf: npm ci && npm test Release: Bedürfnisse: Test läuft auf: ubuntu-latest Nur dieser Job kann schreiben, und nur das, was er braucht. Berechtigungen: Inhalt: schreiben Schritte: - verwendet: Aktionen/Checkout@commit-sha> - Lauf: ./scripts/release.sh
Nicht vertrauenswürdige Auslöser. Arbeitsabläufe, die ausgelöst werden durch pull_request_target Führen Sie die Aktion mit den Geheimnissen des Ziel-Repositorys und einem schreibfähigen Token aus, selbst wenn die pull request stammt von einem Fork. Wenn dieser Workflow dann den Code des Forks auscheckt und ausführt, kann jeder eine Datei öffnen. pull request und Code mit Ihren Berechtigungen ausführen. Das ist eine Schwachstelle zur Rechteausweitung, die keinerlei Ausnutzung erfordert, sondern nur einen pull requestPrivilegierte Schritte sollten in vertrauenswürdigem Code ausgeführt werden, nicht vertrauenswürdiger Code hingegen in einem separaten Workflow ohne Geheimnisse.
Wenn Sie diese Muster an einem sicheren Ort sehen möchten, xygeni-goat Das Repository sammelt absichtlich unsichere pipeline und IaC Konfigurationen für Schulungszwecke. Eine umfassendere Übersicht Ihrer GitHub-Einrichtung finden Sie in unserem Leitfaden unter Wie man erkennt, ob eine GitHub-App oder ein Repository sicher ist.
Wie man eine Schwachstelle zur Rechteausweitung verhindert CI/CD pipelines
Schließung der Rechteausweitung in CI/CD pipelineEs läuft auf ein Prinzip hinaus: minimale Berechtigungen, angewendet auf jeder Ebene und kontinuierlich statt nur einmal überprüft. Eine praktische Checkliste:
- Erfasse jeden Token. Standardmäßig schreibgeschützt, Schreibzugriff pro Job und keine organisationsweiten Token in Repository-Workflows.
- Vertrauenswürdigen und nicht vertrauenswürdigen Code trennen. Führe niemals Code aus Forks oder von externen Mitwirkenden in einem Job aus, der Geschäftsgeheimnisse enthält.
- Verhärtet jeden Baucontainer. Benutzer ohne Root-Rechte, kein privilegierter Modus, kein Docker-Socket, eingeschränkte Berechtigungen
allowPrivilegeEscalation: false. - Ersetze langjährige Geheimnisse. Bevorzugen Sie kurzlebige föderierte Anmeldeinformationen und widerrufen Sie alle offengelegten Daten sofort.
- Pinne an, was du läufst. Verweisen Sie auf Aktionen und Bilder Dritter durch commit SHA oder Digest, damit ein kompromittiertes Tag Ihre pipeline.
- Achten Sie auf Abdrift. Berechtigungen erweitern sich im Laufe der Zeit. Warnungen bei neuen Administratoren, geschwächten Zweigschutzmechanismen und unerwarteten Workflow-Änderungen.
- Tor das pipeline. Der Build soll fehlschlagen, wenn vor dem Zusammenführen eine kritische Fehlkonfiguration auftritt.
Die Schwierigkeit besteht nicht darin, diese Regeln zu kennen. Es besteht darin, sie in Hunderten von Repositories und Workflows durchzusetzen, die sich täglich ändern.
Wie behebt Xygeni eine Schwachstelle zur Rechteausweitung in CI/CD?
Jeder Eskalationspfad wird der Xygeni-Funktion zugeordnet, die ihn erkennt oder blockiert.
| Risiko | Was Xygeni tut |
|---|---|
| Pipeline Fehlkonfigurationen | Fehlkonfigurationsdetektoren Durchsucht CI-Jobdefinitionen, Build-Skripte und Konfigurationsdateien in GitHub, GitLab, Azure DevOps, Bitbucket, CircleCI und Jenkins und weist Berechtigungen zu, die über die Best Practices hinausgehen. |
| Eskalation von Containerrechten | IaC und Containerprüfungen Beinhaltet Dockerfiles, docker-compose-Dateien, Kubernetes-Manifeste und Helm-Charts, einschließlich Container, die als Root ausgeführt werden. |
| Überprivilegierte und inaktive Nutzer | Die Analyse der geringsten Privilegien identifiziert inaktive und überprivilegierte Nutzer, und die Health Check verwandelt jeden Fund in ein Ticket |
| Berechtigungsdrift | Die Anomalieerkennung warnt vor ungewöhnlichen Berechtigungsänderungen, anomalen Zusammenführungen und unerwarteten Plugin-Installationen. |
| Offengelegte Zugangsdaten | Die Erkennung von Geheimnissen umfasst Code, pipelines und Container-Images mit automatischer Widerrufung für unterstützte Geheimnistypen |
| Schadcode im pipeline | Blockiert Reverse Shells und Malware-Downloads in pipelineMEW erkennt schädliche Pakete in Echtzeit, noch bevor eine Signatur existiert. |
| aktionen | Pre-commit hooks und CI guardrails Den Build bei kritischen Problemen abbrechen, mit benutzerdefinierten YAML-Richtlinien für Ihre eigenen Regeln |
Die Prüfungen stimmen mit den OWASP Top 10 CI/CD Sicherheitsrisiken und standards wie CIS, NIST und OpenSSFJede Erkenntnis fließt in Xygeni ASPM, wo sie zusammen mit Code-, Abhängigkeits- und Geheimnis-Befunden priorisiert wird, sodass die Privilege-Escalation-Schwachstelle, die tatsächlich die Produktion erreicht, zuerst behoben wird.
Die meisten Privilegienausweitungen in CI/CD pipelines befindet sich bereits in Ihren Workflow-Dateien und wartet darauf, dass nicht vertrauenswürdiger Code ausgeführt wird.
FAQ
Was ist eine Privilege Escalation-Schwachstelle in CI/CD?
Es handelt sich um jede Schwäche, die es ermöglicht, Code in einem pipeline sich mehr Zugriffsrechte zu verschaffen, als für den jeweiligen Job erforderlich sind, wie beispielsweise ein Token mit zu hohen Berechtigungen, ein Workflow, der nicht vertrauenswürdigen Code mit Geheimnissen ausführt, oder ein Build-Container, der den Host erreichen kann.
Was ist eine Privilegieneskalation in Containern?
Bei einer Privilegieneskalation in einem Container erlangt ein Prozess höhere Berechtigungen, häufig Root-Rechte auf dem Hostsystem. Häufige Ursachen sind die Ausführung als Root, der privilegierte Modus und ein eingebundener Docker-Socket.
Beeinflusst die allowPrivilegeEscalation: false Container-Escapes verhindern?
Es blockiert einen wichtigen Pfad: einen Prozess, der mehr Berechtigungen als sein übergeordneter Prozess erlangt, beispielsweise durch Setuid-Binärdateien. Es funktioniert am besten in Kombination mit einem Nicht-Root-Benutzer, reduzierten Berechtigungen und deaktiviertem privilegierten Modus.
Is pull_request_target Immer gefährlich?
Nicht für sich allein. Es wird zu einer Schwachstelle zur Rechteausweitung, wenn der Workflow Code auscheckt und ausführt. pull requestDenn dieser Code wird dann mit Ihren Geheimnissen und einem schreibfähigen Token ausgeführt.
Wie finde ich Wege zur Rechteausweitung über viele Repositories hinweg?
Manuelle Überprüfungen sind nicht skalierbar. Eine automatisierte Überprüfung CI/CD Das Sicherheitstool scannt kontinuierlich jeden Workflow, jede Container-Spezifikation und jeden Berechtigungssatz und gibt eine Warnung aus, wenn etwas erweitert wird.
