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.
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.
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:
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.
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 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.
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.
Hier sind einige Audit-Schritte, mit denen Sie sicherstellen können, dass Ihre Jira-Instanz genau so konfiguriert ist, wie Sie es erwarten.
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).