Ich betreue inzwischen seit mehreren Jahren kleinere Instanzen von Jira, Bitbucket, Bamboo und zeitweise auch Confluence On Prem. Im Zuge der immer häufiger werdenden Sicherheitsprobleme habe ich mir einige der Schwachstellen genauer angeschaut und die Frage gestellt, was bei Atlassian los ist. Mein durchaus erschreckendes Fazit dazu findet sich in diesem Artikel zusammengefasst.
Wer ist Atlassian?
Das Unternehmen ist durch proprietäre Anwendungen für Softwareentwickler groß geworden. Die wohl bekanntesten sind Jira und Confluence: Jira ist ein Ticketsystem. Es kann zum Projektmanagement verwendet werden und kommt mittlerweile auch in Bereichen außerhalb der IT zum Einsatz. Confluence als Wiki-System dient hingegen zur Dokumentation. Der Konzern existiert seit 20 Jahren, beschäftigt 6.500 Mitarbeiter, die einen Jahresumsatz von 2,09 Milliarden US-Dollar erwirtschaften. Zumindest in diesen beiden Bereichen haben sich seine Produkte zum Marktführer entwickelt.
Oft starten Unternehmen mit einem dieser Produkte und steigen mit der Zeit tiefer in das Ökosystem von Atlassian ein, wodurch auch weniger verbreitete Anwendungen des Konzerns zum Einsatz kommen. Darunter etwa Bitbucket zum Hosting des Quellcodes oder Bamboo als Buildserver. Diese lassen sich auch untereinander recht einfach integrieren: Etwa Jira-Tickets in Confluence, wenn man etwas zu einem Fehler dokumentieren möchte.
Sicherheitsprobleme
Atlassian ist alleine in den letzten Monaten dutzende Male durch Sicherheitsprobleme aufgefallen. Hierbei geht es mir aber nicht um die Quantität. Wenn eine Software wenig oder keine bekannten Sicherheitslücken aufweist, ist sie dadurch nicht automatisch sicherer als eine andere mit mehreren Lücken. Die Art der Lücke und der Umgang damit sagt jedoch weit mehr darüber aus, wie wichtig dem Unternehmen Sicherheit wirklich ist.
Und gerade hier fällt Atlassian besonders negativ auf: Oft handelt es sich um fahrlässige Fehler, die bei sauberer Programmierung oder zumindest gründlichen Tests auffallen. Die Auswirkungen sind zudem nicht selten gravierend und Enden in der Möglichkeit, aus der Ferne eigenen Code auszuführen. Remote Code-Ausführung bedeutet: Der Angreifer kann so ziemlich alles machen, worauf er Lust hat! Zum Beispiel Informationen entwenden, manipulieren oder zerstören. Und das sind noch die vergleichsweise harmlosen Dinge. Er hat Rechte auf alles, was auch die Anwendung darf. Somit könnte er auf andere Systeme im Netz zugreifen, dort nach Lücken oder schlecht geschützten Anwendungen suchen. Im schlimmsten Falle kommt er bis zum Active Directory und kann das gesamte Netzwerk wahlweise ausspionieren, kompromittieren oder lahm legen.
Wir sprechen hier also von keiner Kleinigkeit. Wenn Angreifer so eine Lücke ausnutzen, ist das ein potenzieller Totalschaden! Je nach Sichtweise kurz vor einem GAU oder bereits der GAU.
Atlassian gibt bei Sicherheitsproblemen keinen CVSS-Wert an. Sondern stattdessen eine von vier Kategorien, die bestimmten Bereichen der Skala entsprechen. CVSS 9.0 bis 10.0 steht beispielsweise für „kritisch“.
Bitucket
Bitbucket dient zum Hosten von Git-Repositorys: Man betreibt einen Server und kann seinen Code dort hin pushen. Andere haben die Möglichkeit, den Code von dort per pull zu laden sowie Änderungen zu verteilen. Im Grunde wie Gogs, oder im Cloudbereich GitHub.
Codeausführung Januar 2020
Mehrere Fehler in Bitbucket führen dazu, dass jeder Nutzer der Repositorys klonen oder darin pushen darf, Schadcode auf dem Server ausführen konnte. Die Sicherheitslücke wurde von Atlassian als „kritisch“ eingestuft.
Codeausführung August 2022
Im August 2022 erschien ein Sicherheitsupdate, das die Lücke CVE-2022-36804 behob. Dabei konnte ein Angreifer per HTTP-Header Code einschleusen und damit mindestens den Server kompromittieren. Sämtliche unterstützte Versionen waren betroffen, sowohl Server als auch DataCenter. Man musste lediglich ein öffentliches Repository haben, oder Lesezugriff auf ein privates, um die Lücke auszunutzen.
Jira
Codeausführung Service Management Oktober 2021
Oktober 2021 wurde eine Schwachstelle in Jira Service Management bekannt. Angreifer können aus der Ferne manipulierten Code ausführen, dementsprechend wurde die Lücke als „kritisch“ eingestuft. Der Fehler liegt in der Bibliothek für H2 Datenbanken. Dabei handelt es sich um eine eingebettete Datenbank, ähnlich wie SQLite. Von Jira wird H2 jedoch nicht für den produktiven Betrieb unterstützt. Die Bibliothek ist nur für Testinstallationen vorhanden, sodass man diese ohne eigenen Datenbankserver ausprobieren kann.
Hier zeigt sich, dass Abhängigkeiten die Angriffsfläche erhöhen. Atlassian hätte dieses Problem leicht verhindern können, in dem die H2 Bibliothek nicht in jeder Jira-Instanz vorhanden ist, obwohl sie produktiv gar nicht benötigt wird. Sondern diese nur bei Bedarf in z.B. einem Testpaket integriert. Diese Vereinfachung hat dazu geführt, dass eine zu Testzwecken gedachte Bibliothek zum Risiko für sämtliche produktive Installationen wurde.
Codeausführung in Slack-Erweiterung für Jira
Die Erweiterung soll eine Integration zwischen Jira und Slack ermöglichen. So kann man etwa Jira-Projekte mit bestimmten Kanälen in Slack verbinden. „Jira Server for Slack“ ist nicht standardmäßig installiert. Allerdings handelt es sich um eine offizielle Erweiterung von Atlassian selbst. Gegenüber Drittanbietersoftware genießt diese daher einen Vertrauensvorteil – leider zu unrecht, denn die als „kritisch“ eingestufte Lücke ermöglicht es jedem angemeldeten Benutzer, beliebigen Schadcode auszuführen. Sie wurde im Februar 2021 bekannt.
Confluence
CVE-2021-26084 ist doch für nicht authentifizierte Nutzer ausnutzbar
Mitte 2021 kam es zu einer kritischen Schwachstelle in Confluence, die nur authentifizierte Benutzer treffen soll. Wenige Tage später wurden jedoch auch Systeme ohne Konto angegriffen – Atlassian musste zurück rudern. Wie kam es zu dieser falschen Information? Der verwundbare Code befindet sich in einer Java Teilansicht, die nur bei angemeldeten Benutzern eingebunden wird. Übersehen wurde jedoch, dass man diese Teilansicht auch direkt über ihren Name aufrufen kann – somit ließ sich die Lücke problemlos auch ohne Authentifizierung ausnutzen. Wer sich auf diese ersten Informationen verlassen hatte und sich in Sicherheit wog, weil keine anonymen Konten möglich sind, wurde möglicherweise nichtsahnend infiziert.
Es gehört zu den grundlegenden Sicherheitsmaßnahmen für Entwickler, dass man von außen stammende Daten nicht vertraut. Falls diese in dynamischem Code eingesetzt werden, kommen Filter zum Einsatz, um Manipulation auszuschließen. Dies ist hier nicht bzw. nur unzureichend geschehen, wodurch eine schwere Sicherheitslücke entstand.
Zero-Day Schwachstelle im Juni 2022
Anfang Juni informierte Atlassian über eine schwerwiegende Zero-Day Sicherheitslücke (CVE-2022-26134). Sie ermöglicht es Angreifern, beliebigen (Schad-) Code auszuführen. Bereits wenige Stunden später konnten die ersten Angriffsversuche beobachtet werden, auch Medien berichteten darüber.
Ein Workaround wurde nicht angeboten. Man empfiehlt Betroffenen, sich an die eigenen Sicherheitsteams (also die des Kunden, nicht von Atlassian!) zu wenden, was man dagegen tun könnte. Als Optionen wird genannt, den Zugriff auf Confluence über eine Firewall in Richtung Internet einzuschränken – sodass nur interne Anwender das System nutzen können. Oder alternativ Confluence komplett abzuschalten. Vor allem letzteres dürfte für viele absolut unrealistisch sein: Als zentrales Dokumentationssystem enthält es wichtige Informationen. Ein Ausfall auf unbewusste Zeit würde die Möglichkeit zu Arbeiten deutlich einschränken.
Später wurde ergänzt, dass man eine Firewall für Webanwendungen vor Confluence setzen kann, um darin Adressen zu blockieren, die „${“ enthalten. Das sei allerdings kein Workaround, der schütze. Sondern man würde damit „möglicherweise das eigene Risiko reduzieren“.
Einige Zeit darauf kommunizierte Atlassian einen Workaround, der gegen einzelne Sicherheitslücken schützt, nicht aber gegen alle. Es folgten dann Sicherheitsaktualisierungen, die jedoch nur Kunden mit Wartungslizenz erhielten. Wer diese nicht für einen jedes Jahr üppig steigenden Aufschlag besaß, erhielt keinen Zugriff auf die Sicherheitskorrektur. Wer hingegen die teure DataCenter-Edition lizenziert hatte, musste einen Ausfall hinnehmen – trotz Clustering, wodurch genau das vermieden werden sollte.
„Questions for Confluence“ umgeht Benutzerauthentifizierung
„Questions for Confluence“ erzeugt automatisch im Hintergrund ein Konto namens disabledsystemuser. Das Passwort ist bei jedem gleich und leicht zu ermitteln. Darüber kann man sich anmelden und auf alle Seiten zugreifen, die für sämtliche Nutzer freigegeben sind. Laut Atlassian dient es zur Migration, wenn Benutzer von On-Prem in die Cloud umziehen. So wie es umgesetzt wurde, erfüllt es jedoch alle Merkmale einer Hintertür (Backdoor). Im Juni 2022 informierte der Hersteller über diese Lücke und stufte sie mit der höchsten Einstufung „kritisch“ auf der eigenen Skala ein.
Bei „Questions for Confluence“ handelt es sich um eine Erweiterung, die es Benutzern ermöglicht, Fragen zu stellen, über Antworten abzustimmen, Punkte zu sammeln und ähnliches. Als Wiki-Software stellt Confluence keine derartige Funktionalität bereit. Im Marktplatz stehen verschiedene Erweiterungen bereit, womit sich das System um zusätzliche Funktionen erweitern lässt. Zwar wird „Questions for Confluence“ nicht automatisch installiert, sodass nur ein Teil der Benutzer betroffen ist. Allerdings handelt es sich um eine offizielle Erweiterung von Atlassian selbst. Sie genießt dadurch besonderes Vertrauen im Gegensatz von Drittanbietern, die von anderen Unternehmen bereitgestellt werden.
Atlassian stellte eine Aktualisierung bereit. Die neue Version legt keinen Account mehr an und entfernt das Konto, falls es existiert. Doch nicht alle Betroffene werden damit geschützt: Wer Beispielsweise die Erweiterung früher installiert hatte, bei dem ist die Hintertür noch vorhanden. So jemand ließt die Meldung möglicherweise gar nicht, weil er sich sich für nicht betroffen hält. Oder deaktiviert bzw. entfernt die Erweiterung, im Glaube, damit die Gefährdung abzuschalten. Das reicht jedoch nicht. Auch das Löschen des Kontos ist unzureichend: Wenn die Erweiterung aktiv ist und nicht aktualisiert wurde, wird sie den Account wieder anlegen.
Noch brisanter wird der Vorfall dadurch, dass eine Einweg-E-Mail-Adresse des Dienstes Yopmail eingetragen wurde: Über das Web kann dort jeder durch Eingabe der in Confluence sichtbaren Adresse sämtliche Mails lesen, ohne Schutz. Das ist problematisch, weil Confluence an alle Benutzer regelmäßig Newsletter verschickt. Das Postfach dieser Adresse enthält viele solcher Mails. Schon in diesen Nachrichten können Inhalte aus Confluence und damit sensible/interne Informationen enthalten sein, etwa als Vorschautext. Noch schwerwiegender ist aber, dass die vorhandenen Newsletter eine für jeden abrufbare Liste mit verwundbaren Installationen darstellen. Schließlich enthalten diese Links zum jeweiligen Confluence. Und alle Instanzen welche E-Mails an diese Adresse senden, sind von der Lücke betroffen.
Ein weiteres Risiko besteht durch die Möglichkeit, das Passwort per E-Mail zurück zu setzen. Auch dafür ließe sich das öffentlich erreichbare Postfach missbrauchen. In einer Sammlung von häufig gestellten Fragen listet der Hersteller die Frage „Warum es jüngst so viele Sicherheitswarnungen“ gab, weicht jedoch aus.
Sicherheitslücken in allen Atlassian-Produkten
Zusammen mit der vorhin erwähnten Sicherheitslücke in „Questions for Confluence“ wurden zwei weitere Sicherheitslücken bekannt: Nahezu die gesamte Produktpalette des Herstellers Atlassian ist von CVE-2022-26136 und CVE-2022-26137 betroffen. In beiden Fällen geht es um fehlerhafte Filter. Die zweite Lücke ermöglicht es, CORS-Header mithilfe einer manipulierten Anfrage zu umgehen. In der Praxis bedeutet das: Der Angreifer sendet dem Opfer einen präparierten Link. Klickt das Opfer darauf, kann der Angreifer das Konto kapern – er hat die gleichen Rechte in der verwundbaren Atlassian-Anwendung, wie das Opfer.
CVE-2022-26136 ermöglicht sogar zwei Schwachstellen: Per XSS kann der Angreifer mit einer bestimmten Adresse JavaScript-Code in den Browser einschleusen. Klickt das Opfer auf so einen Link, kann der Angreifer z.B. die Sitzung des Opfers stehlen. Oder alle Aktionen ausführen, zu denen das Konto des Opfers die notwendigen Rechte besitzt. Zusätzlich lässt sich die Authentifizierung durch diese Lücke sogar komplett aushebeln: Der Angreifer hat damit Zugriff auf Funktionen der Anwendung, ohne dass ein anderer Benutzer dafür irgend eine Aktion ausführen muss.
Im November 2021 kam es zu einer mit Risiko „hoch“ kategorisierten Schwachstelle, die einen Großteil der Atlassian-Software betraf. Die Systeme prüften Nutzereingaben nicht korrekt, etwa aus Beschreibungs- oder Kommentarfeldern. Dadurch können unsichtbare Zeichen in den Code eingeschleust werden, um ihn zu manipulieren.
Viele Beispiele, wenig Besserung
Es gibt noch viele weitere Beispiele. CVE-2019-3398 ist beispielsweise eine Sicherheitslücke, bei der Angreifer durch hochgeladene Dateien beliebig in das Dateisystem des Servers schreiben konnten. Dadurch war die unkontrollierte Ausführung von Schadcode möglich. Solche Lücken sind leicht auszunutzen, haben jedoch schwerwiegende Folgen. Das Prüfen von Inhalten die von Nutzern eingegeben werden, ist eine grundlegende Schutzmaßnahme. Atlassian fällt immer wieder damit auf, dass Grundlagen der Sicherheit unvollständig oder gar nicht umgesetzt werden. Offensichtlich sieht das Unternehmen selbst die seit 2017 explodierende Anzahl an Schwachstellen nicht als Anlass, ihre Sicherheitsvorkehrungen zu prüfen und deutlich zu verbessern.
Falschinformationen und ein kaputtes Update-Konzept
Was bei Atlassian gravierend schief läuft, demonstrieren CVE-2016-10750 und CVE-2022-26133 an einem Extrembeispiel: Die erste CVE wurde im April 2016 in der Hazelcast-Bibliothek entdeckt. Dort erhielt sie einige Zeit lang wenig Beachtung, bis dieser Pull request das Problem im Januar 2018 löste. Die Version 3.11 enthält den Fix. Bei Atlassian interessierte man sich nicht dafür – erst im März 2022 veröffentlicht Atlassian einen Security Advisory, dass mehrere Atlassian-Anwendungen von der 2016 entdeckten Lücke betroffen sind. Mindestens 4 Jahre lang hielt es Atlassian also nicht für nötig, ihre Abhängigkeiten zu prüfen, geschweige denn zu aktualisieren. Und das wäre wahrscheinlich noch viel länger, denn CVE-2022-26133 hat ein unabhängiger Dritter gemeldet. Erst dadurch wurde Atlassian auf das Sicherheitsproblem aufmerksam.
Und selbst danach scheint Atlassian schlampig gearbeitet zu haben: Im Security Advisory wird bis heute behauptet, es seien nur die DataCenter-Versionen von z.B. BitBucket betroffen. In dieser Ankündigung schließen sie sogar explizit aus, dass BitBucket Cloud sowie Server von dieser Lücke verwundbar sind. Offensichtlich stimmt das nicht, wenn der Hazelcast-Port 5701 auch auf meiner BitBucket Server Instanz lauscht:
$ sudo netstat -tulpn | grep 5701
tcp 0 0 0.0.0.0:5701 0.0.0.0:* LISTEN 6728/java
$ sudo ps -ax | grep 6728
6728 ? Sl 104:13 /usr/java/latest/bin/java -classpath /home/bitbucket/bitbucket/app -Datlassian.standalone=BITBUCKET -Dbitbucket.home=/home/bitbucket/data -Dbitbucket.install=/home/bitbucket/bitbucket -Xms512m -Xmx1g -XX:+UseG1GC -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 -Djava.io.tmpdir=/home/bitbucket/data/tmp -Djava.library.path=/home/bitbucket/bitbucket/lib/native;/home/bitbucket/data/lib/native com.atlassian.bitbucket.internal.launcher.BitbucketServerLauncher start
Diese erschreckende Nachlässigkeit lässt nur einen Schluss zu: Atlassian hat jede Menge Drittanbieter-Abhängigkeiten in ihrer Software, die sie offensichtlich nie prüfen oder gar aktualisieren. Das sind grundlegende Sicherheitsmaßnahmen, sie gehören zum kleinen Einmaleins.
Sicherheitsupdates nicht für alle
Wenn eine Software Sicherheitsaktualisierungen bereitstellt, sollte man diese natürlich so schnell wie möglich einspielen – das ist eine altbekannte Grundlage für IT-Sicherheit und gilt unabhängig von einzelnen Produkten oder Herstellern. Bei Atlassian ist dies jedoch mit einem cleveren Preisschild versehen: Sämtliche Aktualisierungen kann man nur installieren, sofern zum Veröffentlichungsdatum ein aktiver Supportvertrag besteht wurde. Der kostet, und zwar nicht zu knapp. Fehlerkorrekturen sind hierbei keine Ausnahme, selbst für Sicherheitsaktualisierungen verlangt Atlassian Geld.
Dass der Fehler ja bereits von Atlassian in der Vergangenheit gemacht wurde und somit dem Kunde ein mangelndes Produkt verkauft wurde, spielt für das Unternehmen keine Rolle. Man stelle sich das in anderen Branchen vor: Es wird z.B. ein Serienfehler in einem Automodell bekannt. Der Hersteller behebt ihn, aber verlangt dafür einen Wartungsvertrag. Dieser kostet nicht nur jeden Monat bzw. jedes Jahr Geld, sondern wird zudem jedes Jahr deutlich teurer. Würde man vermutlich nicht akzeptieren, und das zu Recht. Vor allem dann, wenn es sich dazu nicht um einen einzigen Fehler handelt. Sondern alle paar Monaten ein neuer entdeckt wird.
Warum werden die Produkte trotzdem genutzt?
Diese Frage stellt sich nach einem Blick auf Atlassians Qualität unweigerlich: Müsste der Markt das nicht regeln? Das passiert aus vermutlich mehreren Gründen nicht: Atlassian versucht mit allen Mitteln, die Kunden in ihre Cloud zu drängen. Beispielsweise ist bei jeder der Dokumente zu den Sicherheitslücken zu lesen, alle Cloud-Produkte seien nicht betroffen. Im besten Falle ließt man, dass Atlassian die Updates dort bereits eingespielt hat. Als sei On-Prem das Problem, nicht die offensichtlich fragwürdige Qualität.
Ob man glauben mag, dass Atlassian bei den Cloudprodukten viel bessere Arbeit liefert als On-Prem, muss jeder für sich selbst entscheiden. Wer das tat, dürfte spätestens seit März 2022 wieder enttäuscht sein: Dort sind Atlassians Clouddienste für mehrere Wochen ausgefallen. Ursache waren mehrere Fehler des Unternehmens selbst. Neben schlechter Kommunikation und fehlerhaften Skripten hat es Atlassian versäumt, die Wiederherstellung zu testen. Für eine garantierte Verfügbarkeit von 99,9 % oder gar 99,95 % zahlt man übrigens Aufpreise. Im Standardpreis ist gar keine Verfügbarkeit inbegriffen. Auf der Werbeseite, um den Kunden die Cloud schmackhaft zu machen, wird mit „Höhere Zuverlässigkeit“ geworben.
Das größte Problem, warum Kunden sich das antun, dürfte aber woanders liegen: In bestimmten Bereichen gibt es keine „Enerprise-Software“, die uneingeschränkt mit Atlassian vergleichbar ist. Besonders bei Jira und Confluence hat das Unternehmen eine Monopolstellung aufgebaut. In anderen Gebieten dagegen kann sich Atlassian gegen die Konkurrenz nicht durchsetzen, weil die mindestens gleichwertig ist – teils sogar besser und/oder günstiger:
Bitbucket verliert deutlich an Marktanteilen zugunsten von GitLab und GitHub.
HipChat wurde daher 2019 sogar komplett abgeschaltet. Wer Cloud möchte nutzt Slack oder Teams, zum selber Betreiben stehen genug FOSS-Alternativen wie z.B. Matrix oder Mattermost bereit.
Fazit
Offensichtlich fehlen bei Atlassian grundlegende Sicherheitsmaßnahmen und Qualitätskontrollen seit Jahren. Das hindert den Konzern aber nicht daran, die Kunden mit saftigen Preiserhöhungen zur Kasse zu bitten oder gar in die Cloud zu drängen. Ironischerweise werden diese u.a. mit dem „besonderen Wert auf Sicherheit“ begründet. Leidtragende sind alle Kunden, die trotz stetig steigender Kosten schlechte Produkte erhalten, welche immer wieder ein schweres Sicherheitsrisiko darstellen.
Statt endlich Schutzmaßnahmen auf dem Stand der Technik einzuführen, drängt man die Kunden in ihre Cloud. Diese haben aber nicht nur Vorteile, sondern auch eine ganze Reihe an Nachteilen. Dass man selbst dort keine Software erwarten kann, deren Qualität sich um 180 Grad gebessert hat, zeigte der jüngste Großausfall: Eine unzureichende oder fehlende Qualitätssicherung machte ihn überhaupt erst möglich. Atlassian war unvorbereitet, hunderte Entwickler mussten Wochenlang im 24/7 Betrieb von Hand zusammen mit den Kunden einzelne Daten rekonstruieren.