AWS CodeBuild-Schwachstelle (CodeBreach) gefährdete 2025 GitHub-Repo-Übernahmen
Eine kritische Fehlkonfiguration in AWS CodeBuild hätte Angreifern die Übernahme von AWS-eigenen GitHub-Repositories ermöglicht – mit Risiko für Supply-Chain-Angriffe. Details zur Lücke und Schutzmaßnahmen.
AWS CodeBuild-Fehlkonfiguration setzte GitHub-Repositories Supply-Chain-Angriffen aus
Eine kritische Sicherheitsfehlkonfiguration in Amazon Web Services (AWS) CodeBuild hätte es Angreifern ermöglichen können, AWS-eigene GitHub-Repositories – einschließlich des AWS JavaScript SDK – zu kompromittieren. Dies hätte potenziell weitreichende Supply-Chain-Angriffe in AWS-Umgebungen auslösen können. Die als CodeBreach bezeichnete Schwachstelle wurde vom Cloud-Sicherheitsunternehmen Wiz identifiziert und von AWS im September 2025 nach verantwortungsvoller Offenlegung behoben.
Technische Details zu CodeBreach
Die Schwachstelle resultierte aus einer Fehlkonfiguration in der Integration von AWS CodeBuild mit GitHub-Repositories. Laut den Forschern von Wiz ermöglichte das Problem unbefugten Zugriff auf interne GitHub-Repositories von AWS, indem übermäßig permissive OAuth-Token-Bereiche und Build-Projekt-Einstellungen ausgenutzt wurden. Obwohl die genauen technischen Mechanismen nicht offengelegt wurden, hätte die Fehlkonfiguration Angreifern folgende Möglichkeiten eröffnet:
- Vollständigen Repository-Zugriff, einschließlich Lese- und Schreibberechtigungen
- Fähigkeit, schädlichen Code in AWS SDKs oder andere kritische Repositories einzuschleusen
- Potenzial für Supply-Chain-Kompromittierungen, da manipulierte Abhängigkeiten sich über AWS-Dienste verbreiten könnten
Wiz betonte, dass für die Ausnutzung der Schwachstelle kein vorheriger AWS-Account-Zugriff erforderlich war, was sie besonders schwerwiegend für Organisationen machte, die auf AWS-gemanagte Build-Services angewiesen sind.
Auswirkungsanalyse
Hätte die Schwachstelle ausgenutzt werden können, wären die Folgen verheerend gewesen:
- Supply-Chain-Angriffe: Angreifer hätten AWS SDKs oder andere Abhängigkeiten manipulieren und so Backdoors in Software-Bereitstellungen für AWS-Kunden einschleusen können.
- Datenexfiltration: Sensible Repository-Daten, einschließlich proprietärem AWS-Code, hätten offengelegt werden können.
- Reputationsschaden: Ein erfolgreicher Angriff auf AWS-eigene Repositories hätte das Vertrauen in die Sicherheit der Plattform untergraben.
Wiz hat nicht offengelegt, ob die Schwachstelle vor dem Patch aktiv ausgenutzt wurde. AWS hat keine Hinweise auf Missbrauch gemeldet.
Empfehlungen für Sicherheitsteams
Obwohl AWS das Problem behoben hat, sollten Sicherheitsexperten folgende Maßnahmen ergreifen:
- CodeBuild-Konfigurationen prüfen: GitHub-Repository-Integrationen auf übermäßig permissive OAuth-Tokens oder Build-Projekt-Einstellungen überprüfen.
- Supply-Chain-Risiken überwachen: Abhängigkeitsscans und Integritätsprüfungen für AWS SDKs und andere Drittanbieter-Bibliotheken implementieren.
- Prinzip der geringsten Privilegien durchsetzen: Repository-Berechtigungen auf notwendige Rollen und Dienste beschränken.
- Über Cloud-Sicherheitshinweise auf dem Laufenden bleiben: AWS-Sicherheitsbulletins abonnieren, um über neue Bedrohungen informiert zu sein.
AWS hat dieser Schwachstelle keine CVE-ID zugewiesen, dennoch wird Organisationen empfohlen, ihre CodeBuild-Bereitstellungen mit den neuesten AWS-Sicherheitsbest Practices abzugleichen.
Originalbericht von The Hacker News.