Anmeldedaten weiterzugeben ist bestenfalls gut gemeint: Wie weitergegebene Anmeldeinformationen die Tür für Datenverletzungen öffnen
Inhalt
Einführung
Ob über ein Banking-Anmeldeportal, Open-Source-Software oder sogar das Betriebssystem selbst: Moderne Technologien haben sowohl Technologie-Experten als auch die Öffentlichkeit vom Code anderer Menschen abhängig gemacht. Das Bedürfnis nach Konsistenz und Praktikabilität hat uns Dinge wie Code-Bibliotheken gebracht, da das Schreiben jedes Codes von Grund auf nicht skalierbar ist.
Je komplexer die Umgebungen werden, desto wichtiger ist es, Orte zu finden, an denen Sie bereits verfügbare Tools automatisieren und wiederverwenden können.
Die Verwendung von Code aus diesen vordefinierten Bibliotheken als Grundlage für ihren eigenen Code durch einen Entwickler führt jedoch zu „Vertrauensproblemen“, d. h., sie erfordert ein Maß an Vertrauen, das ein Sicherheitsexperte als riskant ansehen könnte. Je weiter unten im Quellcode eine Schwachstelle verborgen ist, desto schwieriger ist es, sie zu finden – vorausgesetzt, man weiß überhaupt, wo in diesem Heuhaufen man nach der digitalen Nadel suchen soll.
Wir sind in unserem eigenen Entwicklungsprozess auf ein Beispiel für diese sogenannten Vertrauensfragen gestoßen. Eine scheinbar routinemäßige Nutzung eines unserer externen Services führte letztendlich zur Entdeckung mehrerer schwerwiegender Angriffsmöglichkeiten. Nach der Weitergabe der Informationen an den Anbieter wurden die identifizierten Probleme behoben. In diesem Blogbeitrag erfahren Sie, was wir gefunden haben, wie wir es gefunden haben und wie Angreifer es potenziell zu ihrem Vorteil nutzen können.
Sehen wir uns das einmal genauer an
Während eines routinemäßigen Optimierungstests hat einer unserer DevOps-Ingenieure einen neuen Container für ein Testtool von Drittanbietern erstellt. Er führte den bekannten Befehl aus: apt get update && apt get install XXXX -y.
Nach Eingabe des Befehls wollten wir sehen, was auf unserem Endpunkt ausgeführt wurde, während der Erstellungsprozess ausgeführt wurde. Dazu haben wir den Befehl simple list process ps auf unserem Endpunkt ausgeführt und sind auf diese sehr interessante Zeile gestoßen:
Wir konnten die identifizierten Anmeldeinformationen verwenden, um uns bei einer Website zu authentifizieren, die Hunderte von Kunden-Builds enthielt.
Dass es einen Schlüssel in Klartext gab, war alarmierend, konnte aber durch eine ordnungsgemäße Nutzersteuerung erklärt/eingeschränkt werden, z. B. wenn das Token nur für eine Anwendung zugelassen war. Nun, das war hier eindeutig nicht der Fall. Der angegebene Nutzername enthielt die Zeichenfolge „default“, was nie gut ist.
Wir haben uns dazu entschieden, etwas tiefer zu gehen, und versuchten, die Anmeldedaten zur Authentifizierung an der API zu verwenden, wodurch wir potenziell sensible Informationen abfragen konnten – und zwar jede Menge davon. Es stellte sich heraus, dass der „default“-Nutzer tatsächlich sehr Standard war – der Nutzer war nicht für die Nutzung durch Akamai vorgesehen, sondern wurde von der gesamten Kundenbasis der Anwendung genutzt.
Mit diesem Klartextgeheimnis kann jeder Angreifer vertrauliche Daten für die meisten Kunden der Anwendung abrufen, wie z. B. interne Testlaufergebnisse, Videoaufzeichnungen, Screenshots und interne Skriptausführungsabläufe (Abbildung 1).
Fig. 1: Example of improperly accessed sensitive customer data
Die unglaubliche Menge an Daten, die offengelegt wurde, und die Tatsache, dass die Schwachstelle so leicht zu finden war, haben uns dazu gebracht, uns den Code genauer anzuschauen und zu sehen, was wir noch finden können.
Anmeldedaten weiterzugeben ist bestenfalls gut gemeint
Nachdem wir ein weitergegebenes Geheimnis identifiziert haben, das von der Anwendung schwer missbräuchlich verwendet wurde, haben wir uns entschieden, andere solche Geheimnisse zu identifizieren. Nach ein paar gut platzierten Suchvorgängen (und viel Verschönern) im Quellcode der Anwendung kamen wir auf drei zusätzliche Geheimnisse:
- Ein privater Coralogix-Schlüssel
- Ein Google-API-Schlüssel
- Ein ngrok-Token
Sehen wir uns nun diese Geheimnisse und ihr Potenzial für eine missbräuchliche Verwendung an.
Coralogix: Ein (sehr öffentlicher) privater Schlüssel
Eines der Geheimnisse, das wir in der Codebasis unserer Anwendungen identifiziert haben, war ein privater Schlüssel, der unser Interesse geweckt hat. Daher haben wir nach einem Nutzernamen gesucht, der mit diesem privaten Schlüssel verknüpft sein könnte. Im Rahmen einer Protokollierungsfunktion konnten wir unter dem Schlüssel ein paar Zeilen mit einem Nutzernamen finden. Wir haben andere Hinweise verwendet, die zurückgelassen wurden, und festgestellt, dass der private Schlüssel zum Coralogix-Logging-Framework gehört.
Die Anmeldedaten wurden fest codiert, sodass sie auch von verschiedenen Kunden weitergegeben wurden. Dies könnte ein weiteres mögliches Datenleck bedeuten, aber glücklicherweise hatte dieser Nutzer/Angreifer nur geringe Berechtigungen und konnte nur Protokollmeldungen in das Framework schreiben.
Eine Schreibprimitive ist zwar nicht so stark wie die vorherige Primitive, kann aber trotzdem ein paar interessante Vektoren auf den Anbieter selbst ermöglichen: Ein Angreifer kann gefälschte Protokollmeldungen in die Umgebung des Anbieters einfügen oder versuchen, schädliche Protokollmeldungen einzufügen, um Angriffe wie Cross-Site Scripting (XSS) oder Structured Query Language (SQL) Injection durchzuführen.
Google-API-Schlüssel
OAuth ist ein Autorisierungsmechanismus, der von allen Google-Vorgängen verwendet wird. Anwendungen und Websites können Nutzern die Möglichkeit geben, sich mit ihrem OAuth-gestützten Google-Konto bei ihren Apps oder Websites anzumelden. Um diese Option über den Code zu aktivieren, benötigen Entwickler mehrere Parameter, die sie über ihr Google-Konto erhalten können – nämlich ihren API-Schlüssel: google_name und google_secret.
Beim Durchsuchen des Codes haben wir einen Verweis auf die Google-API gefunden. In Fällen, in denen wir einen „google api“-Schlüssel sehen, sehen wir dies normalerweise – aber diesmal war dies nicht der Fall. Diesmal haben wir auch den „google api“-Schlüssel gefunden, die eindeutige Kennung google_client und die Kennung google_secret. Letzteres war am überraschendsten. Bei allen drei können Angreifer einen Authentifizierungslink von Google als Anbieter anfordern. Dieser Link kann als Teil einer Phishing-Kampagne verwendet werden, um die Opfer dazu zu verleiten, Angreifern Zugriff auf ihren Workspace zu geben.
Potenzielles Phishing
Angreifer können eine Phishing-E-Mail mit einem Link zu einer Website erstellen, die bis auf einen wichtigen Unterschied identisch ist mit der Website des Anbieters – der Link zur Anmeldung bei Google ist der Link, den der Angreifer über die Google-API-Details des Anbieters erhalten hat (Abbildung 2).
Fig. 2: Malicious Google login page appears to be legitimate
Durch die Anmeldung gibt das Opfer dem Angreifer eine Berechtigung für sein gesamtes Google-Workspace-Konto. Da ein Angreifer Zugriff auf so sensible Daten wie eine Google-Identität hat, sind die Möglichkeiten eines Angreifers riesig. Eine erfolgreiche Ausnutzung würde es einem Angreifer ermöglichen, jeden Aspekt des Google-Workspace-Kontos des Opfers zu manipulieren, einschließlich E-Mail-Kompromittierung, Herunterladen von Dateien und vielem mehr. Dies könnte im Rahmen eines Social-Engineering-Angriffs auf Unternehmen sehr nützlich sein.
ngrok
Netzwerk-Tunneling ist eine nahezu universelle Lösung für die sichere Datenübertragung, die Angreifern bei Kompromittierung eine Schatztruhe voller bösartiger Möglichkeiten bieten kann. Wir haben viele Tunneling-bezogene Parameter in der Installation der beeinträchtigten Anwendung aufgedeckt, einschließlich einer ngrok-Konfiguration, die uns dazu veranlasst, weitere Untersuchungen durchzuführen. Dieselben Funktionen, die eine bessere Zusammenarbeit der Entwickler fördern, sind genau das, was sie für einen Cyberkriminellen attraktiv macht.
Ngrok ist ein Dienst, der sich auf die Bereitstellung einer Plattform für das Tunneling von Informationen über Server spezialisiert hat. Ngrok macht es sehr einfach, Dienste im Internet zugänglich zu machen, was ein schnelleres Debugging und effizientere Entwicklungsfeedback-Schleifen ermöglicht. Wenn ein Angreifer die Kontrolle über den Tunnel übernommen hat, ist diese Einfachheit auch für ihn verfügbar.
Durch Aufrufen eines einfachen ps-Befehls kann ein Angreifer die eindeutige ID und das Authentifizierungstoken des Unternehmens aufrufen. Diese eindeutige ID kann nicht geändert werden. Sie bleibt auch bei anderen Verwendungen auf der Anwendung auf anderen Endpunkten unverändert. Angreifer können diese Parameter verwenden, um die ID und das Token an den Online-Server eines Anbieters zu senden, um die ngrok-Details des Unternehmens zu empfangen (Abbildung 3).
Fig. 3: Ngrok token received from the vendor’s server
Das heißt, dass Angreifer nach dem ersten Zugriff die eindeutige ID und das Token vom Opfer kopieren und damit die Daten lesen können, die von der Anwendung des Opfers gesendet/empfangen werden (Abbildung 4).
Fig. 4: Example of data being read from ngrok tunnel
Fazit
Bedrohungen sind nicht ausschließlich extern – tatsächlich akzeptieren wir bereitwillig einige Bedrohungen intern. Viele sind der Meinung, dass Open-Source-Software aufgrund des Vertrauens, das wir in sie haben, die größte Gefahr darstellt. Tools von Drittanbietern können jedoch eine größere Herausforderung für Unternehmen darstellen als Open-Source-Software.
Nach unseren Untersuchungen haben wir die in diesem Blog hervorgehobenen Probleme dem betroffenen Anbieter mitgeteilt und sie wurden behoben. Dennoch stehen neue Sicherheitslücken schon immer vor der Tür.
Wir glauben, dass in diesem Fall – und in vielen anderen Fällen – die Sicherheitsüberwachung genauso wichtig ist wie die Schulung von Entwicklern, um eine Sicherheitsmentalität zu schaffen. Diese beiden Dinge können dazu beitragen, dass Managed Services keine Probleme für Unternehmen verursachen.