Geheimnisse sind alle Daten, die für eine Organisation oder Person vertraulich sind und nicht öffentlich zugänglich gemacht werden sollten. Dies kann ein Passwort, ein Zugriffsschlüssel, ein API-Token, eine Kreditkartennummer und mehr sein. Weitere Informationen zu den Gefahren, die durch die Offenlegung von Geheimnissen über Ihre Quellcodeverwaltungssysteme (SCM) entstehen, finden Sie hier.Hier. Aber SCMs sind nicht die einzigen Dienste, bei denen Geheimnisse verloren gehen können. Im Grunde kann jeder Dienst, den Sie als Teil Ihres Softwareentwicklungslebenszyklus (SDLC) verwenden und in dem Daten gespeichert werden, die Quelle für das Durchsickern von Geheimnissen sein. Unser Forschungsteam hat untersucht, wie vertrauliche Informationen über AppSec-Tools offengelegt werden können, die Sie möglicherweise als Teil Ihrer Entwicklungspipeline verwenden, und in diesem Blogbeitrag demonstrieren wir den SonarQube-Studienfall.
Wenn Ihr Code-Scanner zu Ihrem Code-Explorer wird
SonarQube ist eine Open-Source-SAST-Plattform zur Verwaltung der Codequalität, die kontinuierliche Codeprüfung und Codeanalyse bietet, um Fehler, Schwachstellen und Code-Smells im Quellcode (die charakteristisch sind oder möglicherweise auf ein tieferes Problem hinweisen) zu identifizieren, der in verschiedenen Programmiersprachen geschrieben ist. Dies geschieht durch die Integration in Ihr SCM und das Scannen Ihrer gesamten Codebasis.
Ironischerweise kann sich diese Art von Code-Scanner bei falscher Konfiguration von einem Anwendungssicherheitstool in ein risikobehaftetes Tool verwandeln, mit dem Angreifer vertrauliche Informationen abgreifen können.
Öffentlich zugängliche SonarQube-Instanzen, die den anonymen Zugriff nicht einschränken, sind unsicher, da sie jedem mit einer Internetverbindung den Zugriff auf die Instanz ermöglichen, einschließlich privatem Code, erkannten Problemen und anderen vertraulichen Informationen. Dies könnte potenziell zu mehreren Sicherheitsrisiken führen, wie z. B. Datenverletzungen, Codediebstahl und vor allem durchgesickerte Geheimnisse im Code, was schließlich zu einem umfassenderen Angriff auf die Lieferkette des Unternehmens führen kann.
Darüber hinaus macht die bloße Tatsache, dass eine SonarQube-Instanz öffentlich zugänglich ist, auch wenn sie keinen anonymen Zugriff auf alle ihre Ressourcen erlaubt, sie anfällig für verschiedene Arten bekannter CVEs und Zero-Day-Schwachstellen, einschließlich Authentifizierungs-Bypass- und Remote-Code-Execution-Angriffen – was wiederum dazu führt, dass ihre Ressourcen offengelegt werden. Der Benutzer muss das System ständig patchen, um CVEs zu beheben, sobald diese entdeckt werden. Es
ist wichtig anzumerken, dass wir SonarQube für ein großartiges Tool halten. Wir haben kein Problem mit SonarQube selbst. Das Problem liegt in der Art und Weise, wie es eingerichtet wird, und unser Ziel ist es, seinen Benutzern zu helfen, das Risiko zu verstehen, es falsch zu machen.
Scannen öffentlicher SonarQube-Instanzen
Das Legit Security Research Team hat sich kürzlich öffentliche SonarQube-Instanzen mithilfe von Tools angesehen, mit denen Benutzer bestimmte Arten von mit dem Internet verbundenen Geräten und Systemen finden können.
Zunächst extrahieren wir eine Liste mit IPs von SonarQube-Instanzen. Anhand dieser Liste fordern wir die SonarQube-API auf, die Version abzurufen und zu überprüfen, ob es sich um tatsächliche SonarQube-Instanzen handelt. Von diesen Servern aus haben wir die Komponentensuch-API verwendet, um zu ermitteln, ob sich Komponenten – ein allgemeiner Name für verwendete Projekte – auf diesem Server befinden, damit wir Daten extrahieren können. Jeder Server mit Komponenten wurde weiter untersucht, während wir den Code jeder seiner Komponenten heruntergeladen haben. Dies könnte es einem Angreifer möglicherweise ermöglichen, vertrauliche Informationen wie privaten Code und andere vertrauliche Daten aus der Organisation zu extrahieren. Bei einer alten Version von SonarQube könnte diese anfällig sein, und die öffentliche Veröffentlichung erhöht das Risiko exponentiell.
Unsere Untersuchung ergab, dass von über 2200 öffentlichen SonarQube-Instanzen in freier Wildbahn etwa 80 zugänglich waren, aber leere Daten enthielten (möglicherweise ohne Verwendung des eingeschränkten Zugriffs von SonarQube für anonyme Benutzer), und fast 200 von ihnen erlaubten anonymen Zugriff, wodurch privater Quellcode offengelegt wurde. Das Scannen dieses Codes nach Geheimnissen mit einem geheimen Scanner enthüllt mehrere Arten von Geheimnissen, z. B. API-Token, Schlüssel, AWS-Token und vertrauliche Informationen von Personen – Kunden/Mitarbeitern. Wir haben mit den Organisationen, bei denen festgestellt wurde, dass sie diese vertraulichen Informationen offenlegten – wahrscheinlich ohne dass sie sich dessen bewusst waren – einen verantwortungsvollen Offenlegungsprozess durchgeführt.
Wir haben mehrere Arten von Geheimnissen gesammelt. Die Verteilung der Geheimnisse zeigt, dass es sich bei der überwiegenden Mehrheit um generische API-Schlüssel handelt (die den Zugriff auf Dienste wie interne Assets ermöglichen, die im Entwicklungsprozess oder in der Produktionsumgebung verwendet werden). Anhand des Quellcodes kann ein Angreifer die Verwendung dieser API-Schlüssel verstehen und so weitere Daten extrahieren oder sogar manipulieren. Es ist erwähnenswert, dass es auch eine große Anzahl von AWS-Zugriffstoken gab, die in den meisten Fällen den Zugriff auf die Cloud-Assets einer Organisation (z. B. S3-Bucket) ermöglichen und vertraulichere Informationen extrahieren. Ein weiterer gefährlicher Geheimnistyp, der durchgesickert ist, warStreifen- eine Finanzinfrastruktur. Stripe-API-Tokens könnten es böswilligen Akteuren ermöglichen, finanzielle Ressourcen einer Organisation zu stehlen. Andere Arten von Geheimnissen, die erkannt wurden, umfassen PKCS, RSA, SendGrid-API-Token und Alibaba-Zugriffsschlüssel-ID usw.
Risiken offengelegter Geheimnisse
Wir haben in diesem Artikel mehrere Risiken angesprochen:
1. Den SonarQube-Server öffentlich zugänglich machen.
Es bietet böswilligen Akteuren die Möglichkeit, einen Hinweis für einen Angriff auf Ihr Unternehmen zu finden. Bei einer Fehlkonfiguration kann es äußerst einfach sein, Ihr Unternehmen anzugreifen.
2. Anonymen Zugriff auf SonarQube, das den Code der Organisation enthält. Dies ermöglicht:
- Codediebstahl, einschließlich der Verwendung von Geheimnissen im Code
- Durch den anonymen Zugriff können Angreifer ihre Identität und Aktivitäten verbergen, sodass es für Organisationen schwieriger wird, Angriffe zu erkennen und darauf zu reagieren.
3. Geheimnisse im Code haben und laterale Bewegung ermöglichen.
Wenn alle drei Risiken kombiniert werden, reicht dies aus, um einem böswilligen Akteur den Angriff auf Ihr Unternehmen zu ermöglichen.
Gegenmaßnahmen
Um diese Risiken zu mindern, wird Folgendes empfohlen:
1. Zugriff auf die SonarQube-Instanz einschränken
SonarQube-Server, die privaten Code scannen, sollten im Allgemeinen nicht öffentlich sein. Öffentlicher Zugriff auf SonarQube kann zu öffentlichem Zugriff auf den privaten Code führen, Social Engineering zum Diebstahl von Anmeldeinformationen verwenden, beliebte Passwörter aufzählen und sogar den Server angreifen, wenn er nicht aktualisiert ist/einen Zero-Day-Angriff verwenden. Allgemein gesagt sollten öffentlich und privat getrennt werden, und bei Verwendung von privatem Code sollte sich jede Instanz, die darauf zugreift, höchstwahrscheinlich in einem privaten Netzwerk befinden.
2. Verwenden Sie geeignete Authentifizierungs- und Autorisierungsmechanismen.
Von einem anonymen Zugriff auf privaten Organisationscode wird dringend abgeraten. Und wenn Sie Zugriff auf den SonarQube-Server haben, ist das sogar noch schlimmer. Solange Sie den Code haben, können Sie das Ergebnis eines Codescanners sehen und erhalten weitere Informationen über den Code. Für Organisationen ist es wichtig, die Sicherheitsauswirkungen des anonymen Zugriffs auf diese Art von Tools sorgfältig abzuwägen und geeignete Sicherheitsvorkehrungen zum Schutz vor potenziellen Angriffen zu treffen. Dazu können die Implementierung starker Authentifizierungs- und Zugriffskontrollen, die Überwachung verdächtiger Aktivitäten und die regelmäßige Aktualisierung und Patches der Tools zur Behebung von Schwachstellen gehören.
3. Von Geheimnissen im Code wird dringend abgeraten
Dies führt zu Bedrohungen durch Lateralbewegungen und kann durch den Einsatz von Scannern und die Speicherung von Geheimnissen auf verschlüsselten Speichern mit angegebener Autorisierung behoben werden.
Das Einbinden der Geheimnisse in den Code führt zu Sicherheitsverletzungen, die durch Scanner und das Speichern der Geheimnisse auf verschlüsselten Speichern mit angegebener Autorisierung behoben werden können. Weitere Informationen zu diesem Thema finden Sie in unseremBlog.
Lassen Sie nicht zu, dass Geheimnisse aus SDLC-Tools nach außen dringen!
Zusammenfassend lässt sich sagen, dass Fehlkonfigurationen in einem SDLC-Dienst wie SonarQube, die anonymen öffentlichen Zugriff ermöglichen, Ihr Unternehmen anfällig für mehrere Bedrohungen machen, darunter Codediebstahl, der letztendlich dazu führen kann, dass Geheimnisse durchsickern. Der Diebstahl von Geheimnissen kann schwerwiegende Folgen haben, darunter Zugriff auf private Kundendaten, Zugriff auf kritische Produktionsdienste und Angriffe auf die Lieferkette. Es ist wichtig, Ihre SDLC-Assets sicher aufzubewahren und Ihre Codebasis frei von fest codierten Geheimnissen zu halten.
Mehr lesen: So verwenden Sie Ublock Origin und Privacy Badger, um Browser-Tracking in Firefox zu verhindern
Legit kann helfen
DerLegit-Sicherheitsplattformbietet erweiterte Funktionen zur Geheimniserkennung, die Ihnen helfen, die Offenlegung vertraulicher Informationen zu verhindern, sowie eine breite Palette zusätzlicher Sicherheitsfunktionen und -vorteile. Eine dieser zusätzlichen Funktionen ist die Warnung vor gefährlichen Fehlkonfigurationen von SDLC-Systemen und -Infrastrukturen in Ihrer Vorproduktions-Entwicklungsumgebung. Weitere Informationen erhalten Sie unter kontaktiere uns!