Executive Summary
Varonis-Forscher haben eine Liste mit 812 Subdomänen erstellt und 689 zugänglichen Jira-Instanzen gefunden. Wir haben 3.774 öffentliche Dashboards, 244 Projekte und 75.629 Issues mit E-Mail-Adressen, URLs und IP-Adressen in diesen Instanzen gefunden.
Außerdem haben wir festgestellt, dass die Jira REST API mehr öffentliche Informationen offenlegt als die Web-Schnittstelle. Dadurch kann ein Administrator fälschlicherweise denken, dass keine Daten preisgegeben werden, während Angreifer über die API-Zugang zu vielen Daten haben.
Einige der öffentlichen Informationen, die wir gefunden haben, sind absichtlich öffentlich (z. B. Dashboards und Issues im Zusammenhang mit Open-Source-Projekten). Andere Instanzen, die wir gefunden haben, enthalten jedoch sensible Informationen, die vom Jira-Administrator des Unternehmens privat gemacht werden sollten.
NB: Dies ist KEINE Schwachstelle in Jira. Daten werden offengelegt, wenn ein Jira-Kunde seine Jira-Einstellungen versehentlich falsch konfiguriert. Wir haben Atlassian kontaktiert, um unsere Ergebnisse offenzulegen.
Die Auswirkungen
Auf den ersten Blick mögen URLs und E-Mail-Adressen harmlos erscheinen, aber E-Mail-Adressen, die an Jira-Issues angehängt sind, können Aufschluss darüber geben, wer die Kunden eines Unternehmens sind. Einige der Jira-Issue-Datensätze, die wir gefunden haben, legen Bugs, Produktfunktionen und Roadmap-Details offen.
Es gibt Situationen, in denen ein Jira-Benutzer ein Dashboard oder einen Filter absichtlich offenlegen möchte. Unsere Untersuchungen zeigen jedoch, dass Fehlkonfigurationen, die zur Offenlegung von Daten führen, immer noch viel zu häufig vorkommen.
In einem Beispiel haben wir ein Standard-Dashboard „System“ eines Versandunternehmens mit öffentlich sichtbaren URLs zu sensiblen Systemen (z. B. Build-Server, Quellcode-Repos, Roadmap-Tools) gefunden. Das ist ein perfekter Ausgangspunkt für Angreifer, um Benutzer zu phishen oder sich lateral zu bewegen.
Die von uns gescannte Jira-Instanz eines Bankdienstleisters enthielt Dutzende von E-Mail-Adressen von Bankmitarbeitern, die zum Spoofen von Phishing-E-Mails oder zum Credential Stuffing bzw. zum Brute-Force-Angriff auf die SaaS-Anwendungen der Bank verwendet werden können.
Hintergrund
Jira ist ein beliebtes Produkt von Atlassian zum Issue Tracking und für Agile Development. Es gibt sie in zwei Varianten: Jira Cloud und Jira Server (lokal).
Jira enthält Dashboards, mit denen Produktmanager und Entwickler ihre Projekte verfolgen können. Dashboards können Filter haben. Sowohl für Dashboards als auch für Filter gibt es Berechtigungseinstellungen, die festlegen, wer sie anzeigen und ändern darf.
Hier ein Beispiel für ein verschleiertes Jira-Dashboard, das mit ziemlicher Sicherheit nicht im Internet offengelegt werden sollte:
Wie passiert das? Es gibt zwei Berechtigungseinstellungen, die von Jira-Administratoren häufig missverstanden und versehentlich falsch konfiguriert werden:
- Öffentliche Freigaben – mit dieser Einstellung können Benutzer Dashboards und Filter für alle Benutzer, einschließlich anonymer Benutzer, freigeben.
- Berechtigungsschema mit der Gruppe „öffentlich“– Jira-Administratoren gehen gelegentlich davon aus, dass „öffentlich“ gleichbedeutend mit „offen für jeden im Unternehmen“ ist. In Wirklichkeit bedeutet es jedoch „offen für das Internet“.
Atlassian hat seine Benutzeroberfläche aktualisiert, um Kunden zu helfen, diesen kritischen Fehler zu vermeiden.
Im Jahr 2016 hat das Unternehmen die Bezeichnung der Einstellungen von „Jeder“ in „Öffentlich“ geändert und eine Warnmeldung hinzugefügt:
Das Unternehmen hat außerdem eine globale Einstellung hinzugefügt, mit der Administratoren die öffentliche Freigabe vollständig deaktivieren konnten. Diese Einstellung finden Sie unter JIRA Admin > System > General Configuration > Edit Settings.
Beachten Sie jedoch, dass die globale Deaktivierung der öffentlichen Freigabe nicht automatisch die öffentlichen Berechtigungen von Jira-Objekten entfernt, die zuvor öffentlich gemacht wurden. Sie müssen die Einstellungen für die Freigabe auf jedem Dashboard neu konfigurieren.
Altes Thema, neue Probleme
Dies ist nicht das erste Mal, dass jemand über Fehlkonfigurationen von Jira-Berechtigungen geschrieben hat. Es lohnt sich jedoch, sich genauer mit dem auseinanderzusetzen, was unsere Forscher gefunden haben.
In Anbetracht der Ergebnisse unserer Scans wollten wir zunächst das Bewusstsein der Jira-Administratoren schärfen, die möglicherweise immer noch über falsch konfigurierte Instanzen sensible Daten der Öffentlichkeit preisgeben.
Zweitens hat unser Forschungsteam herausgefunden, dass wir mit der REST API von Jira mehr offengelegte Daten aufdecken können, als zuvor (über die Web-UI) entdeckt wurden. Mit der REST API kann ein Angreifer ein einfaches Skript schreiben, um das Jira-Konto eines Unternehmens zu scannen und schnell sensible Daten zu extrahieren.
Hier sehen Sie ein Beispiel für ein Jira-Kundendashboard in der Web UI. Hier gibt es nicht viel zu sehen:
Und hier ist das gleiche Dashboard über die REST API:
Die API-Rückgabe zeigt den Besitzer an, einschließlich seines Namens, Avatars und der URL der Benutzerseite.
Was sind die Risiken?
Was kann ein Angreifer mit den Informationen aus dem Jira-Dashboard anfangen?
Erkundung– mit dem Projektnamen, dem Besitzer und den Avataren kann ein Angreifer eine gezielte Phishing-Kampagne erstellen.
Laterale Bewegung – einige Jira-Dashboards enthalten sensible Daten zu anderen Tools und Systemen, die das Unternehmen verwendet (interne IP-Adressen, URLs, Anmeldeinformationen usw.). Wenn ein Angreifer die URLs von Systemen mit Internetzugang kennt, kann er einen Passwort-Spraying- oder Credential-Stuffing-Angriff starten oder bekannte Schwachstellen in diesen Systemen ausnutzen.
Exfiltration. – in schwerwiegenden Fällen muss ein Angreifer keine von Jira erlangten Informationen verwenden, um auf sensiblere Systeme umzuschwenken, da die von ihm gesuchten Informationen im Jira-Dashboard selbst gespeichert sind.
Wie viele Daten sind öffentlich?
Mithilfe der REST API fand unser Team 689 Atlassian-Subdomänen mit öffentlichen Projekten, Filtern, Dashboards oder Issues.
Bei der Überprüfung von Subdomänen, die zu Unternehmen auf der Fortune-1000-Liste gehören, fanden wir viele Instanzen des System-Dashboards, bei denen lediglich der Eigentümer offengelegt war. In anderen Fällen fanden wir jedoch Hunderte von offengelegten Issues.
- 812 Atlassian-Subdomänen geprüft
- 689 Sites gefunden (84 %)
- Die durchschnittliche Anzahl öffentlicher Objekte pro Konto:
- 87 Filter
- 6 Dashboards
- 12 Projekte
- 4.448 Issues
- Die Gesamtzahl der gefundenen öffentlichen Objekte:
- 23.135 Filter
- 3.774 Dashboards
- 244 Projekte
- 75.629 Issues
- Potenziell sensible Informationen:
- 2.922 E-Mail-Adressen
- 5.424 IPv4-Adressen
- 60.411 URLs
Abhilfe: Wie man ein Audit der Jira-Einstellungen durchführt
Hier sind einige Audit-Schritte, mit denen Sie sicherstellen können, dass Ihre Jira-Instanz genau so konfiguriert ist, wie Sie es erwarten.
- Zur Entfernung des öffentlichen Zugriffs empfehlen wir diesen hervorragenden Leitfaden von Atlassian.
- Überprüfen Sie alle öffentlichen Berechtigungen auf der Seite mit den globalen Berechtigungen:
- Gehen Sie zuSettings -> System -> Global Permissions
- Stellen Sie sicher, dass es keine Berechtigungen gibt, die in der Spalte „Benutzer/Gruppen“ die öffentliche Gruppe enthalten, wenn sie nicht für das Internet öffentlich sein sollen.
- Falls vorhanden, klicken Sie auf „Löschen“, um die öffentliche Gruppe aus einer Berechtigung zu entfernen, die nicht öffentlich sein sollte.
- CPrüfen Sie alle öffentlichen Berechtigungsschemata:
- Gehen Sie auf Settings -> Issues -> Permission Schemes
- Überprüfen Sie jedes Berechtigungsschema und entfernen Sie den öffentlichen Zugriff, wo dies für Ihr Unternehmen angemessen ist.
- ergewissern Sie sich, dass keine Gruppen in der Spalte „Zugelassen“ vorhanden sind, die mit der Warnung „Jeder angemeldete oder anonyme Benutzer kann dieses Projekt betrachten“ versehen sind.
- Wenn dies der Fall ist, klicken Sie auf „Entfernen“, um die Gruppe „Gruppe – öffentlich“ zu entfernen. Wir empfehlen, diese Gruppe aus allen Projekten zu entfernen.
FAZIT
Es gibt einen Grund, warum „defekte Zugriffskontrolle“ an die Spitze der OWASP Top 10 Web Application Security Risks katapultiert wurde.
Unternehmen haben Dutzende von SaaS-Anwendungen, die es zu verwalten gilt – jeweils mit eigenen Berechtigungsschemata und Einstellungen. Und viele von ihnen sind miteinander sowie mit dem Internet verbunden, was das Risiko noch zusätzlich erhöht. Eine einzige Fehlkonfiguration kann dazu führen, dass sensible Daten für Ihr gesamtes Unternehmen oder die ganze Welt zugänglich sind.
Wir werden weiterhin nach SaaS-Fehlkonfigurationen suchen und unsere Erkenntnisse weitergeben, um Administratoren darüber zu informieren, worauf sie achten können, um das Risiko bei Cloud-Daten zu minimieren.
Wir entwickeln auch die Funktionen von DatAdvantage Cloud ständig fort, um Ihre SaaS-Anwendungen automatisch zu scannen und so gängige Fehlkonfigurationen zu finden, auf offenliegende sensible Daten hinzuweisen und Sie zu alarmieren, wenn kritische Änderungen stattfinden (z. B. wenn jemand eine Freigabeeinstellung von „privat“ auf „öffentlich“ ändert).
