Sicherheitslücke durch fehlerhafte Autorisierung in Atlassian Confluence

Warum dieser Exploit so gefährlich war

Als der Vorfall CVE-2023-22518 – Improper Authorization Vulnerability In Confluence Data Center and Server am Dienstag, den 31. Oktober, erstmals bekannt wurde, waren die Details noch sehr spärlich. Es handelte sich um ein schwerwiegendes Problem mit einem Schweregrad von 9,1, allerdings mit bislang ausschließlich zerstörerischer Wirkung. Um das Risiko zu mindern, sollten Unternehmen eine solide Backup-Strategie sicherstellen und ihre Instanz vom Internet trennen, falls sie nicht sofort auf eine gepatchte Version aktualisieren konnten.

Zu diesem Zeitpunkt gehen wir davon aus, dass die interne Diskussion ähnlich verlief wie bei uns bei Eficode. Wir vermuteten, dass etwa eine Injection von SQL-Befehlen zum Löschen der Datenbank im Spiel sein könnte. Unabhängig davon spielten wir das Patch still ein, informierten unsere Kunden und machten weiter.

Die Zusicherung von Atlassian, dass weder Code-Ausführung noch Datenexfiltration möglich seien, hat vermutlich zur Gefahr beigetragen. Ob Atlassian klar war, wie sich die Schwachstelle entwickeln würde, ist jedoch nicht bekannt.

Irreführende erste Kommunikation und Maßnahmen zur Risikominderung

Das schnelle Handeln erwies sich bei Eficode als Rettung. Anbieter wählen für die Verbreitung von Informationen einen von zwei Wegen: Entweder informieren sie zunächst ihre Partner, sodass Patches unauffällig eingespielt werden können, bevor Details zum Exploit öffentlich werden. Oder sie veröffentlichen die Informationen für alle, damit sie sofort verfügbar sind.

Im zweiten Fall beginnt ein Wettlauf zwischen Security-Teams, die patchen wollen, und Bedrohungsakteuren, die die Schwachstelle ausnutzen wollen. Dass dieser Fall zunächst als weniger schwerwiegend eingestuft wurde, verschaffte etwas Zeit. Er war zerstörerisch, aber nicht ausnutzbar.

Doch bis zum Ende der Woche war der Schweregrad des Exploits auf 10,0 angehoben worden, und Remote Code Execution war in Form von Proofs of Concept entwickelt worden. Zum Zeitpunkt der Veröffentlichung sind auf GitHub bereits einsatzfähige Exploits leicht verfügbar.

Mehrere Tage nach dem Auftauchen der ersten PoCs erhielten wir Nachrichten über Ransomware-Angriffe.

Als dies geschah, waren die Instanzen von Eficode bereits gepatcht.

Fehlende grundlegende Sicherheitsmaßnahmen

Ransomware hängt natürlich stark davon ab, dass einem Unternehmen wirksame Sicherheitsmaßnahmen fehlen – in diesem Fall Backups. Eine robuste Backup-Lösung ist der Schlüssel, um Ransomware-Angriffe schnell und effizient zu bewältigen.

In der Cybersecurity gibt es einen Begriff dafür: Cybersecurity Fatigue. Gemeint ist die Ermüdung von Mitarbeitern durch die Maßnahmen, die für eine sichere Plattform erforderlich sind. Genau dieses Phänomen führt dazu, dass keine Backups vorhanden sind, Firewalls nicht eingerichtet werden und sensible Ressourcen öffentlich zugänglich sind.

Während Sicherheitsbedrohungen und die Reaktion darauf weiter zunehmen, wächst auch die Erschöpfung. Besonders deutlich zeigt sich das in DevOps, wo Teams oft aus spontan zusammengestellten Entwicklern und Infrastrukturspezialisten bestehen und keine klar definierten Sicherheitsrichtlinien haben.

Ein nicht wiederherstellbarer Datenverlust ist bis heute der schnellste Weg eines Unternehmens in die Insolvenz. Immer mehr Unternehmen versuchen, diese Tatsache zu umgehen, und erkennen nicht an, dass sie inzwischen neben allem anderen auch IT-Unternehmen sind.

Eine Möglichkeit, dem entgegenzuwirken, ist natürlich die Zusammenarbeit mit einem Managed-Service-Anbieter wie Eficode. Wir betreiben diese Plattformen für Hunderte von Unternehmen und betreuen Services wie Jira, Confluence, Bitbucket, GitLab, GitHub, Jenkins und weitere gehostete DevOps-Anwendungen.

Wie Instanzen entdeckt werden

Eine der ersten Maßnahmen zur Risikominderung für diese Schwachstelle war einfach: die Instanz aus dem öffentlichen Internet entfernen. Das ist immer eine gute Möglichkeit, die Angriffsfläche zu reduzieren, setzt jedoch voraus, dass ihr jedem Mitarbeiter in eurem Unternehmen jederzeit vertrauen könnt.

Aufgrund dieses Potenzials für interne Angriffe und der Unternehmensprofile liegt die Annahme nahe, dass solche Angriffe gezielt erfolgen. Das trifft jedoch größtenteils nicht zu. Es sind einfache Gelegenheitsangriffe. Tools wie Shodan.io dienen als Suchmaschinen – nicht für Informationen, sondern für Maschinen, die mit dem Internet verbunden sind.

Die Suche nach:

Confluence "country:fi"

zeigt allein in Finnland mehrere hundert offene Confluence-Instanzen im öffentlichen Internet. Ohne den Filter sind es Zehntausende.

So funktioniert die Ausnutzung

Die Schwachstelle auszunutzen war äußerst einfach: Es genügte eine einzelne HTTP-POST-Anfrage an den folgenden Endpoint:

/json/setup-restore.action

mit folgendem Header:

"X-Atlassian-Token": "no-check",

Confluence-Administratoren nutzen diesen Endpoint, um die Website aus einem komprimierten Backup wiederherzustellen, das mit den Daten der Anfrage hochgeladen wird. Normalerweise ist ein administrativer Endpoint durch eine Form der Authentifizierung geschützt. In den betroffenen Versionen gibt es jedoch keine solche Sicherheitsmaßnahme.

Allein das Einspielen eines kompromittierten Confluence-Backups mit bösartigen Plugins wie dem bei diesem Angriff häufig vorkommenden Web Shell Plugin ermöglicht diesen Angriff.

So mindert ihr das Risiko

Es gibt mehrere Maßnahmen zur Risikominderung. Ein Update auf eine neue Version ist der zuverlässigste Weg. Wenn das nicht möglich ist, reduziert das Entfernen der Instanz aus dem öffentlichen Internet die Angriffsfläche erheblich – auch wenn es den Angriff nicht vollständig verhindert.

Auch das Blockieren der folgenden URLs auf Netzwerkebene stoppt den Exploit nach aktuellem Stand

/json/setup-restore.action/json/setup-restore-local.action/json/setup-restore-progress.action

Am sichersten ist es jedoch, auf die neueste korrigierte Version zu patchen.

Was bedeutet das für mich als Nutzer?

Wenn ihr auf eine korrigierte Version gepatcht habt, sollte eure Confluence-Instanz sicher sein. Bleibt über Atlassian-Sicherheitsmeldungen auf dem Laufenden. Für die meisten DevOps-Tools gibt es ähnliche Informationsquellen.

Wenn eure Teams jedoch unter Cybersecurity-Müdigkeit leiden, könnt ihr auch einen Managed-Services-Anbieter in Betracht ziehen. Er kümmert sich um diese Themen, sodass eure Entwickler sich auf das konzentrieren können, was sie am besten können: großartige Dinge programmieren.

Was kommt als Nächstes für die Sicherheit?

Diese Schwachstelle zeigt ein Problem in der Cyberwelt, das sich mit einer einfachen Frage verdeutlichen lässt: Was haben dieser Exploit und Log4Shell gemeinsam?

Beide haben einen Schweregrad von 10,0.

Und dennoch brachte Log4Shell das Internet für mehrere Wochen nahezu zum Stillstand, während dieser Exploit relativ gut unter Kontrolle ist. Worin liegt der Unterschied?

Es zeigt sich, dass die gängigste Cybersecurity-Kennzahl zur Bewertung von Vorfällen, das CVSS (Common Vulnerability Scoring System), nur eines misst: die Auswirkungen pro System.

Wir können nicht messen, wie weit ein Angriff verbreitet ist. Solange unsere einzige relevante Kennzahl zeigt, wie schwerwiegend ein Exploit sein kann, wenn er auf einem System aktiv ist, werden wir auf verwirrende Fälle wie diesen stoßen: Ein Schweregrad von 10,0 betrifft einige tausend Confluence-Installationen, während Log4j auf Millionen von Systemen installiert war.

Die Cybersecurity sollte Kennzahlen für Reichweite und Auswirkungen entwickeln, die den CVSS-Score ergänzen und diese Vorfälle – und ihre Folgen – klarer einordnen.

Atlassian Data Center Security mit Eficode ROOT

Zum Abschluss möchten wir erwähnen, wie Eficode ROOT euch in diesen herausfordernden Zeiten der Cybersecurity das Leben erleichtern kann. Stellt es euch als ein engagiertes Team vor, das sich stets um Themen wie den Patch für CVE-2023-22518 kümmert. Es spielt Sicherheitsupdates als Teil seiner täglichen Arbeit reibungslos und schnell ein. So könnt ihr euch auf eure Kernaufgaben konzentrieren – mit der Gewissheit, dass die Sicherheit ohne zusätzlichen Stress oder Aufwand gewährleistet ist.