Atlassian Confluence Security Vulnerability wird aktiv ausgenutzt

Am 4. Oktober veröffentlichte Atlassian ein Advisory zu einer kritischen Schwachstelle (CVE-2023-22515) in Confluence Data Center und Server. Die Schwachstelle ermöglicht es entfernten Angreifenden unautorisierte Administrator-Konten zu erstellen und auf Confluence Instanzen zuzugreifen.

Die Schwachstelle erhält eine CVSS-Bewertung von 10.0 (“kritisch”) [NVD23]. Nach Angaben des Herstellers Atlassian wurde die Schwachstelle möglicherweise bei einigen Kunden bereits aktiv ausgenutzt. Die nachfolgenden Versionen des Confluence Data Centers und Confluence Servers sind jeweils von der
Sicherheitslücke betroffen: 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.1.0, 8.1.1, 8.1.3, 8.1.4, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.3.0, 8.3.1, 8.3.2, 8.4.0, 8.4.1, 8.4.2, 8.5.0,
8.5.1

Versionen unter dem Patchstand von 8.0.0 sind nicht von dieser Schwachstelle betroffen, ebenso nicht bei Atlassian Cloud gehostete Instanzen (erkennbar an atlassian.net in der Domain).

Bewertung

Die weite Verbreitung von Atlassian Confluence Data Center und Server sowie die dort gespeicherten, mitunter vertraulichen Daten machen die Kollaboration und Wissensmanagement-Lösung zu einem beliebten Ziel bei Angreifenden. Eine Ausweitung der von Atlassian beobachteten Angriffe hält das BSI für wahrscheinlich. Besonders kritisch ist die Ausnutzbarkeit von extern, sollte die Confluence Instanz aus dem Internet erreichbar sein.

Maßnahmen

Atlassian gibt im Advisory zu der Schwachstelle Mitigationsmaßnahmen an und stellt Updates zur Verfügung. IT-Sicherheitsverantwortliche sollten so schnell wie möglich Confluence Instanzen aktualisieren oder, falls dies nicht möglich ist, die beschriebenen Mitigationsmaßnahmen des Herstellers umsetzen. Ebenfalls sollte auf eine
mögliche, bereits stattgefundene Kompromittierung anhand der bereitgestellten Indikatoren von Atlassian geprüft werden.

Folgende Versionen von Confluence Data Center und Confluence Server schließen die Schwachstelle (CVE-2023-22515): 8.3.3 oder höher, 8.4.3 oder höher, 8.5.2 oder höher

Sollte nicht auf eine der gelisteten Versionen aktualisiert werden können, so können folgende Mitigationsmaßnahmen
getroffen werden:

• Zwischenzeitlich den externen Netzwerkzugriff auf die Instanz beschränken
• Zusätzlich den Zugriff auf die /setup/* Endpunkte von Confluence blockieren, die zur Ausnutzung der Schwachstelle notwendig sind. Dies kann umgesetzt werden durch: Beschränken des Netzwerkzugriffs auf diesen Pfad oder durch das Anpassen der Confluence Konfigurationsdatei. Hierzu muss die //confluence/WEB-INF/web.xml Dateien angepasst werden und der folgende Codeblock vor dem Tag am Ende der Datei hinzugefügt werden:

<security-constraint>
<web-resource-collection>
<url-pattern>/setup/*</url-pattern>
<http-method-omission>*</http-method-omission>
</web-resource-collection>
<auth-constraint />
</security-constraint>

Ebenfalls stellt Atlassian folgende Indicators-of-Compromises (IoCs) zur Verfügung, die auf eine bereits stattgefundene Ausnutzung der Schwachstelle hindeuten:

• Nicht autorisierte Teilnehmer in der confluence-administrators Gruppe
• Nicht erwartete, neu erstellte Nutzer-Konten
• Anfragen an die /setup/*.action Endpunkte (sind in den Netzwerk-Logs zu finden)
• Fehlermeldungen, die “/setup/setupadministrator.action” enthalten, sind in atlassian-confluence-security.log (im
  Confluence Installations-Ordner) zu finden
  Weitere Informationen zu der Schwachstelle stellt Atlassian in einem FAQ [ATLA23b] zur Verfügung.
  Bei einer festgestellten Kompromittierung sollte nach Möglichkeit:

1. Eine schnelle Einzelfallbetrachtung mit einem lokalen oder externen IT-Sicherheits-Team durchgeführt werden,
   bevor Notfallmaßnahmen wie z.B. die Trennung von Netzwerkverbindungen ergriffen werden. Ziel wäre dabei u.a. eine Prüfung, ob unter Akzeptanz von Restrisiken laufende Angreiferaktivitäten beobachtet werden können. In einigen Fällen ist nur so das Ausmaß der eigenen Kompromittierung feststellbar. Die dabei potentiell durch Entscheidungsträger zu akzeptierenden Restrisiken für alle Netzwerke, an denen das betroffene System angeschlossen ist, sind vor Akzeptanz genauso zu prüfen wie die zur Beobachtung erforderlichen Sicherheitsmaßnahmen (z.B. erhöhte Detektion, Klärung von Abbruchkriterien).
2. Wenn 1. nicht kurzfristig möglich ist oder sich gegen eine Beobachtung des Angreifers entschieden wurde, sollten betroffene Systeme lediglich vom Netzwerk getrennt werden und nicht ausgeschaltet werden.
3. Falls ein betroffenes System ohne forensische Sicherung ausgeschaltet wird, gehen für die forensische Analyse wichtige Daten unwiederbringlich verloren. Dies kann im schlimmsten Fall die Vorfallsaufklärung verhindern. Deswegen ist der unter 2. beschriebene Schritt aus Sicht des BSI empfehlenswert. Falls ein betroffenes System
   trotzdem ausgeschaltet werden soll, sollte zuvor eine forensische Sicherung des Systems erfolgen

www.bsi.bund.de