In Teil 2 unserer AWS-Hacking-Serie werfen wir einen Blick auf den Open-Source-Automatisierungsserver Jenkins.
Jenkins hilft dabei, die Teile der Softwareentwicklung zu automatisieren, die mit dem Erstellen, Testen und Bereitstellen zusammenhängen, und spielt eine wichtige Rolle bei der Gewährleistung der kontinuierlichen Integration und Bereitstellung.
Es ist auch als Management-Tool für die Entwicklung von Pipelines zum Aufbau, Testen und Bereitstellen von Cloud-Infrastrukturen verwendet; Es ist eine beliebte Wahl für viele Entwicklungsteams, die mit der AWS-Cloud arbeiten.
In diesem Artikel gehen wir auf mögliche Sicherheitsprobleme ein und erstellen was Sie tun können, um Ihre AWS-Konten vor unerwünschtem Zugriff durch Jenkins zu schützen.
Alsoohne weitere Erklärungen, lassent's schnallen Sie sich an und starten Sie die Zündung.
Hack und Slash
Jenkins erfordert viele Privilegien für die Bereitstellung und Zerstörung von Infrastrukturen und Ressourcen in der Cloud, was es zu einem idealen Einstiegspunkt für Hacker macht!
TAus diesem Grund schränken die meisten Unternehmen den Zugang ein, indem sie ihn hinter einem Virtual Private Network (VPN) verstecken, so dass er nur für nur für ihre Mitarbeiter.
Es kommt jedoch vor, dass der Jenkins-Server einer Firma öffentlich zugänglich ist und dass anonyme Besucher ihn über verschiedene Zugriffsstufen nutzen - die einfachste ist die reine Leseberechtigung Berechtigungen.
Ich setze wieder einmal meinen weißen Hut auf, lassen Sie mich zunächst etwas Licht auf diese besondere Zugangsart werfen.
Nach dem Lesen verbrannt
Sie würden sich wundern welchen Schaden angerichtet werden kann mit "nur" a Nur-Lese-Berechtigung. Zugriff auf AWS-Anmeldeinformationen, Daten und geheime Informationen... dieiese und mehr können können Ihnen offenbart werden - wenn Sie wissen, wo sie zu finden sind.
Schauen wir uns drei spezifischen Einstiegspunkte, die können Zugang zu einigen pikanten Details gewähren können.
Arbeitsbereich
Innerhalb von Jenkins bietet Ihnen der Arbeitsbereich einen Überblick und einfachen Zugriff auf Ihre Projektstruktur und Projektdateien.
Hier kann ein unbefugter Benutzer leicht den Quellcode einer einer bestimmten Anwendung finden, den er dann in Verbindung mit der Nur-Lese-Berechtigung verwenden kann, um eine Vorschau aller Projekt Dateien.
Neben der Quellcode, können Sie können Sie finden Sie auch Konfigurationsdateien, Daten-Dumps, CSV-Dateien mit PII oder sogar Datenbank-Dumps.
Das ist alles schön und gut, aber jetzt kommt der Clou: Sie können AWS-Anmeldedaten im Klartext in Konfigurationsdateien oder sogar fest in der Anwendung kodiert.
Sobald ein Hacker dies entdeckt, kann er kannn so viel tun wie IAM-Richtlinien angehängt dieser Benutzer ihm erlauben.
Übrigens: Ein weiterer Einstiegspunkt ist der Step Workspace. Wenn Sie mit Pipelines arbeiten, haben Sie hier Zugriff auf die Projektstruktur und die Dateien in Ihren Pipelines.
Umgebungsvariablen
Diese werden für jeden Auftrag einzeln definiert und sind nur während der Ausführung des Auftrags verfügbar. Mit der Nur-Lese-Berechtigungfinden Sie AWS-Zugangsschlüssel, Logins, Passworts und andere sensible Informationen hier. Die Seite Seite Umgebungsvariablen ist für die meisten bereits abgeschlossenen Aufträge.
Konsolenprotokoll
Das Konsolenprotokoll enthält die Ergebnisse und Ausgaben jedes ausgeführten Befehls für jeden Auftrag. Sie können eine Menge interessante Informationen hhier, wie Protokolle von Anmeldedaten, Endpunkte und E-Mail-Adressen.
Beispiel Aufträge die ich gefunden habe und die sensible Daten enthalten:
- Erstellen neuer AWS IAM-Benutzer (und Drucken von Zugangsschlüsseln);
- Erzeugen von temporären AWS-Zugangsschlüsseln mit STS (und Drucken);
- Testen Sie der Anwendung auf verschiedenen Zugriffsebenen (und Drucken von Login und Passwort).
Benutzername/Passwort ermöglicht Ihnen, zum Beispiel, um sich bei der Bühnenumgebung anzumelden wo der Test durchgeführt wurdeucted. Nun, die Bühnenumgebung kann sein verbunden mit eine Produktionsdatenbank. Und wenn das ist der Fall, dann wir sind dabei es für die große Zeit!
Jobs für alle!
Eine andere Zugriffsebene, die häufig auf öffentlich zugänglichen Jenkins-Rechnern zu finden ist, erlaubt es jedem anonymen Benutzer, einen Jenkins-Job zu erstellen.
Ein Job könnte ein Skript sein, das dann von der Jenkins-Maschine ausgeführt wird. Das heißt, Sie können jedes beliebige Skript erstellen, und Jenkins wird es für Sie ausführen.
Möchten Sie die temporäre Zugriffsschlüssel aus dem Jenkins EC2 Metadaten? Kein Problem:
curl 169.254.169.254/latest/meta-data/iam/security-credentials/
Möchten Sie einenccess Schlüssel in Jenkins Credentials gespeichert? Kein Problem, drucken Sie sie auf dem Bildschirm aus oder senden Sie sie an eine E-Mail.
Wie wäre es mit Jenkins mit IAM User Zugriffsschlüssel statt einer Rolle? Sehr gut:
cat ~/.aws/credentials
Wenn das's nicht ausreicht, gibt es eine weitere leistungsstarke Berechtigungsstufe - Jenkins verwalten.
Jenkins, Holen!
Diese Zugriffsart erlaubt Ihnen die Seite "Jenkins verwalten" mit allen Konfigurationsdetails öffnen.
Mit dieser Erlaubnis levelkönnen Sie eine Vorschau anzeigen (und ändern!) die aktuelle Konfiguration aller Erweiterungen. Es kann Ihnen E-Mail-Adressen, private Schlüssel und Anmeldedaten liefern, Git-Repository-Adressen und mehr.
Mit Jenkins verwalten haben Sie auch Zugriff auf eine Skriptkonsole. Über diese Konsole können Sie beliebige Skripte ausführen, ohne einen Auftrag zu starten. Die Angriffsszenarien sind ähnlich wie bei der vorherigen Zugriffsebene mit der Auftragserstellung. Aber die Konsole ist auch nützlich zur Entschlüsselung von Jenkins Anmeldeinformationen. Holen Sie sich einfach den Hash der interessanten Anmeldeinformationen (prüfen Sie das html Formularfeld) und führen Sie das folgende Skript aus:
hashed_credential='credential-hash-value' decrypted_credential = hudson.util.Secret.decrypt(hashed_credential) println(decrypted_credential)
Sie druckt den Wert der sich hinter dem ausgewählten Berechtigungsnachweis versteckten Wert.
Wenn Sie Zugang zu AWS erhalten Zugangsschlüssel die zu zu Jenkins gehören, können Sie alles tun, was der Jenkins-Benutzer/Rolleerlaubt ist tun.
Die oben genannten Beispiele sind alle wahr und möglich. Um Ihnen zu verdeutlichen, dass dies tatsächlich der Fall ist, möchte ich Ihnen eine kleine Geschichte aus einem Fall erzählen, mit dem ich kürzlich zu tun hatte.
Zeit für Geschichten
PGS Software hat ein Sicherheitsaudit für einen unserer Kunden durchgeführts ein paar Monaten vor. Als Teil dieser Prüfung erhielt ich AWS-Zugangsdaten für das Konto des Kunden mit Nur-Lese-Zugriff.
Mit diesen Anmeldeinformationen überprüfte ich jeden Teil der Projektinfrastruktur - und es dauerte nicht lange, I fand ich einen Jenkins-Rechner, der in einer der AWS-Regionen lief.
Die Maschine war in einem öffentlichen Subnetz und mit einer öffentlichen IP. Es sah auch so aus, als wäre es erstellt mit terraform Vorlagen. Sicherheitsgruppe erlaubted jedem den Zugriff darauf (0.0.0.0/0).
Leider, gab es eine Login-Seite ohne anonymen Zugang.
Ich habe auch ein vollständiges Protokoll gefunden von der Bereitstellung der Jenkins-Instanz auf CloudWatch. Erstaunlicherweise, tendete das Protokoll mit den Anmeldedaten eines neu angelegten Jenkins-Admin-Benutzers.
Also habe ich geöffnet. die Jenkins Anmeldeseite noch einmal - aber dieses Mal Ich konnte mich mit einem Administratorkonto anmelden. Bei der Überprüfung der IAM-Rolle und der Richtlinien, die mit der EC2, wusste ich bereitswusste ich bereits, dass Jenkins hatte einen AWS AdministratorZugang Richtlinie hat, die mit dieser Rolle verknüpft ist, und so jetzt vollen Zugriff auf das AWS-Konto.
Der Kunde ging davon aus, dass sein Konto sicher war, weil sich die Benutzer anmelden mussten. Er hat nicht damit gerechnet, dass die Anmeldedaten im CloudWatch-Protokoll mit einer Nur-Lese-Berechtigung leicht zugänglich sind.
Warum passiert das?
Die oben genannten Zugangspunkte müssen nicht angreifbar sein. Wie in meinem letzten Artikel erwähnt, ist Cybersicherheit eine Strategie, die an allen Fronten umgesetzt werden muss.
Wenn Sie dem Wind Ihre Geheimnisse verraten, sollten Sie dem Wind nicht vorwerfen, dass er sie den Bäumen verrät. H. Kahlil Gibran
Sicherheitsverletzungen sind möglich, wenn die Sicherheitsmaßnahmen nicht konsequent und effektiv angewandt werden. Im Fall von Jenkins können wir vier Hauptprobleme identifizieren Ausgaben:
Jenkins ist öffentlich verfügbar
Das Fehlen eines VPN kann schwerwiegende Folgen haben Folgen haben. Das Internet ist ein riesiger Dschungel der Konnektivität, in dem es viele Raubtiere gibt, die nicht zögern, sich auf einfache Beute. Wenn nicht VPN, sperren Sie es zumindest auf einer Sicherheitsgruppe, damit nur zugelassene IPs eine Verbindung herstellen können. Zuhause IPs Ihrer Mitarbeiter werden nicht als sicher angesehen, da eine einzelne IP könnte abdecken. Hälfte einer a großen Stadt.
Jenkins Sicherheit ist deaktiviert
Jenkins verfügt über einige Sicherheitsoptionen. Zum Beispiel, standardmäßig müssen Sie sich anmelden. Dennoch, Die Einrichtung kann mühsam und zeitaufwendig sein, daher entscheiden sich einige Unternehmen dafür, die zu deaktivieren. das Sicherheitsmodul und... vergessen Sie es später. "Wie funktioniertes Kennt jemand die IP meines neu eingerichteten Jenkins-Rechners? Nur meine Mitarbeiter wissen, dass, und sie brauchen sich nicht anzumelden um Dinge zu tun"
Schlechte Virtuelle Host-Konfiguration
Der Zugriff auf die Domäne ist ordnungsgemäß eingeschränkt,aber der IP-Zugriff erfolgt über die Standardvhostohne Einschränkungen. Dies bedeutet dass, wenn ich versuche, die jenkins.beispiel.com wird die Verbindung NICHT zugelassen werden. Aber wenn ich es dann mit der IP hinter dieser Domäne versuche, verwendet er eine andere Konfigurationsdatei auf dem Server und lässt mich rein.
Gebrochenes Prinzip der geringsten Privilegierung
"Geben Sie allen Menschen Admin-Rechte, dann können sie können brauchen sie irgendwann einmal". Dies ist ein gängiges Beispiel - Admin-Rechte werden vergeben an Menschen weil sie weil sie glauben, dass sie es irgendwann einmal brauchen könnten. Das kann passieren, wenn Sie nicht wollen, dass Ihr technische Leitung auf alle 5 Minuten belästigt wird mit einer Anfrage belästigt wird.
Wie Sie Vermeiden Sie diese Lecks
Die oben genannten Punkte können mit den richtigen Sicherheitsmaßnahmen und -strategien definitiv vermieden werden. Hier sind einige Tipps, was Sie tun können, um Ihre AWS-Konten mit Jenkins zu sichern.
- Stellen Sie sicher, dass Jenkins nur von einem lokalen Netzwerk aus zugänglich ist oder verwenden Sie ein VPN
- Stellen Sie sicher, dass die Sicherheitseinstellungen in Jenkins ordnungsgemäß eingerichtet sind - prüfen die Domäne und den direkten IP-Zugang.
- Geben Sie Jenkins nur bei Bedarf Zugriff auf Ihre AWS-Umgebung. Das Prinzip des geringsten Privilegs is Ihr Freund.
Zusammenfassung
Sicherheit ist eine unendliche Geschichte. Wenn Sie Ihr Unternehmen erweitern und mehr digitale Tools einsetzen, müssen Sie sicherstellen, dass Sie die Schwachstellen Ihrer Plattformen und Konten im Blick behalten. Wenn Sie sich weiterbilden und interne und externe Sicherheitsprüfungen durchführen, können Sie Ihre Systeme und AWS-Umgebungen besser verstehen und mit eigenen Mitteln schützen.
Die ultimative Sicherheit ist Ihr Verständnis der Realität. H. Stanley Judd
Mein Rat an Sie lautet machen Sie die Sicherheitsanalyse jeder Komponente Ihrer digitalen Lösung zu einer Standardpraxis. Auf diese Weise behalten Sie die Kontrolle und können unerwünschte Eindringlinge abwehren.
Mehr aus dieser Serie über das Hacken eines AWS-Kontos
Unsere Ideen
Weitere Blogs
Contact