von Bhabesh Raj Rai, Security Research

Am 2. Juni 2022 veröffentlichte Atlassian eine Sicherheitsempfehlung zu einer kritische Zero-Day-Schwachstelle (CVE-2022-26134), die Hacker in Confluence Server und Confluence Data Center ausnutzen können. Diese Schwachstelle ermöglicht es einem Angreifer, beliebigen Code auf einer anfälligen Confluence Server-Instanz oder Confluence Data Center-Instanz auszuführen.

In dieser Sicherheitsempfehlung erklärt Atlassian, dass alle unterstützten Versionen von Confluence Server und Confluence Data Center betroffen sind. Einen Tag nach der Veröffentlichung dieser Empfehlung stellte das Unternehmen Patches zur Verfügung und empfahl allen Kunden, ihre Instanzen auf eine der folgenden, korrigierten Versionen zu aktualisieren: 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4 sowie 7.18.1.

Im Wesentlichen handelt es sich bei diesem Zero-Day-Exploit um eine OGNL-Injection-Schwachstelle, die es einem nicht authentifizierten Benutzer ermöglicht, beliebigen Code im Kontext einer Confluence-Anwendung auszuführen. OGNL-Payloads können in den URI oder die Payload von HTTP-Anfragen injiziert werden. Um Befehlsausgaben zu erhalten, verwenden Angreifer Dummy-Header (X-Cmd-Response ist der häufigste). So können sie die Ausgaben unterbringen, die in der HTTP-Antwort zurückgegeben werden.

Volexity, ein in Washington ansässiges Unternehmen für Cybersicherheit, erkannte die Schwachstelle während einer IR-Untersuchung, die es über das Memorial-Day-Wochenende durchgeführt hatte. Volexity beobachtete, dass Angreifer den Zero-Day-Exploit nutzten, um eine In-Memory-Kopie des BEHINDER-Implants und der Backup-Web-Shells auf dem Confluence-Server zu installieren.

Cloudflare hat bereits am 26. Mai Anfragen identifiziert, die mit potenziell schädlichen Payloads übereinstimmen. Dies deutet darauf hin, dass Angreifer bereits vor der Sicherheitsempfehlung von Atlassian Kenntnis von dieser Zero-Day-Schwachstelle hatten. Ab dem 3. Juni beobachtete das Unternehmen einen starken Anstieg der Aktivitäten, der vermutlich auf die Veröffentlichung von Details und PoCs für die Schwachstelle zurückzuführen ist.

Falls Sie Confluence nicht sofort aktualisieren können, nutzen Sie die vorübergehenden Workarounds, die Atlassian in seiner Sicherheitsempfehlung aufgeführt hat. Atlassian gibt zudem an, dass die End-of-Life-Versionen von Confluence nicht vollständig mit diesen Workarounds getestet wurden. Daher ist es dringend zu empfehlen, auf eine der aktuell unterstützten Versionen von Confluence zu setzen, da diese auch einige weitere Sicherheitsaktualisierungen umfassen.

Kunden können die Anwendung Use Case v5.1.2 von LogPoint nutzen, die Warnmeldungen zur Erkennung der Schwachstelle CVE-2022-26134 umfasst.

CVE-2022-26134 – die Fakten im Überblick

  • Die Schwachstelle ist im Mai 2022 erstmals aufgetreten.
  • Die Schwachstelle betrifft alle unterstützten Versionen von Confluence Server und Confluence Data Center.
  • Massen-Scans und Exploits haben bereits begonnen.
  • Einige PoCs sind frei verfügbar.

Die erforderlichen Logdaten-Quellen

  • Zugriffsprotokolle von Confluence
  • DNS
  • Firewall
  • Confluence auf Linux
    • Sysmon für Linux
    • Auditd
  • Confluence auf Windows
    • Native Event-Logdaten
    • Sysmon

Die Erkennung des Exploits mit LogPoint

Als erstes können Analysten einen IoC-Sweep mit den Indikatoren durchzuführen, die von Volexity, GreyNoise, etc. bereitgestellt werden.

 Geolocation distribution of source IP hit

Geografische Verteilung der Quell-IP-Treffer

Die Zugriffsprotokollierung von Confluence zeichnet die OGNL-Payloads auf, aber diese ist standardmäßig nicht aktiviert. Administratoren sollten sicherstellen, dass die Protokollierung aktiviert ist, denn nur so zeichnet Confluence jede Anfrage auf, die an die Site gestellt wird. Die Logdaten befinden sich in /logs/conf_access_log.log.

(url=* OR resource=*) request_method=*

| process eval("decoded_resource=urldecode(resource)")
| process eval("decoded_url=urldecode(url)")
| rename decoded_resource as resource, decoded_url as url
| search ( resource IN [ "*${*", "*getRuntime().exec(*", "*X-Cmd-Response*"]
OR url IN [ "*${*", "*getRuntime().exec(*", "*X-Cmd-Response*"] )

 Confluence access logging shows OGNL payloads

Die Zugriffsprotokollierung in Confluence zeigt OGNL-Payloads an.

Falls Ihre Confluence-Instanz auf Windows läuft, suchen Sie nach dem Tomcat-Prozess, der verdächtige Prozesse auslöst.

label="Process" label=Create
parent_process IN ["*\tomcat8.exe", "*\tomcat9.exe"]
"process" IN ["*\whoami.exe", "*\systeminfo.exe", "*\ipconfig.exe", "*\cmd.exe", "*\powershell.exe", "*\wget.exe", "*\curl.exe", "*\nslookup.exe"]
-command="cmd.exe /c set"
| chart count() by host, parent_process, "process", command

 Searching for tomcat process spawning suspicious child processes

Die Suche nach Tomcat-Prozessen, die verdächtige Kind-Prozesse auslösen

Falls Ihre Confluence-Instanz auf Linux läuft und Sysmon für Linux installiert ist, suchen Sie nach Confluence-Nutzern, die verdächtige Prozesse auslösen. In unserem Test hat Sysmon für Linux den Namen des übergeordneten Prozesses (java) nicht erfasst, sodass wir uns entweder auf das Benutzer-Feld oder Pfad-Feld verlassen müssen.

norm_id=UnixSysmon label="Process" label=Create
(user="confluence" OR path="*/Atlassian/Confluence/bin")
image IN ["/usr/bin/uname", "/usr/bin/whoami", "/usr/bin/hostname", "/usr/bin/ip", "/usr/bin/id", "/usr/bin/wget", "/usr/bin/curl", "/usr/bin/ss", "/usr/sbin/iptables", "/usr/bin/bash", "/usr/bin/sh"]
| chart count() by user, host, path, image, command

Searching for the confluence user spawning suspicious processes in Sysmon for Linux events

Die Suche nach Confluence-Nutzern, die verdächtige Prozesse auslösen – mithilfe der Events in Sysmon für Linux

Alternativ können Angreifer die Nashorn-Java-Klasse verwenden, um Reverse-Shells für direkte Interaktionen zu erstellen.

(url="*%24%7B*" OR resource="*%24%7B*")
| process eval("decoded_resource=urldecode(resource)")
| process eval("decoded_url=urldecode(url)")
| rename decoded_resource as resource, decoded_url as url
| search ( resource IN [ "*${*ScriptEngineManager()*", "*${*javax.*nashorn*", "*${*.eval(*ProcessBuilder()*" ]
OR url IN [ "*${*ScriptEngineManager()*", "*${*javax.*nashorn*", "*${*.eval(*ProcessBuilder()*" ] )

Searching for use of the Nashorn java class

Die Suche nach der Nutzung der Nashorn-Java-Klasse

Analysten können anhand der Events zur Prozesserstellung nach Reverse-Shell-Artefakten suchen.

label="Process" label=Create
command IN ["*/dev/tcp/*", "*bash -i >&*"]
| chart count() by log_ts, user, image, command

Searching for reverse shell creations in Sysmon for Linux events

Die Suche nach erstellten Reverse-Shells in den Events von Sysmon für Linux

Falls Analysten keine Überwachung mit Sysmon für Linux nutzen, können sie auch die auditd-Events nutzen.

norm_id=Unix "process"=audit event_type=SYSCALL
command IN ["hostname", "id", "whoami", "curl", "wget", "uname", "ss", "ip", "sh", "bash"]
| chart count() by host, command

Searching for suspicious process executions in auditd events

Die Suche nach verdächtigen Prozessausführungen in den auditd-Events

Proctitle-Events erfassen die vollständigen Befehlszeilen von Prozessausführungen. Überwachen Sie Ihre Confluence-Instanzen auf verdächtige Befehlszeilen, die üblicherweise nicht ausgeführt werden.

norm_id=Unix "process"=audit event_type=PROCTITLE host IN CONFLUENCE_HOSTS
| chart count() by host, command

Search for suspicious command lines in auditd’s proctitle events

Die Suche nach verdächtigen Befehlszeilen in den Proctitle-Events von auditd

Angreifer nutzen in der Regel externe Websites wie Interactsh, um anfällige Systeme durch Out-of-Band-Interaktionen zu identifizieren. Untersuchen Sie die Systeme, die hinter diesen DNS-Anfragen stehen.

label=DNS label=Query (query IN ['*.interact.sh', '*.oast.pro', '*.oast.live', '*.oast.site', '*.oast.online', '*.oast.fun', '*.oast.me', '*.burpcollaborator.net', '*.oastify.com', '*.canarytokens.com', '*.requestbin.net', '*.dnslog.cn']
OR domain IN ['*interact.sh', '*oast.pro', '*oast.live', '*oast.site', '*oast.online', '*oast.fun', '*oast.me', '*burpcollaborator.net', '*oastify.com', '*canarytokens.com', '*requestbin.net', '*dnslog.cn'] )

Searching for DNS queries to Interactsh-type sites in Sysmon DNS events

Die Suche nach DNS-Anfragen von Sites wie Interactsh oder ähnlichen in den Sysmon-DNS-Events

Diese Schwachstelle ermöglicht es Angreifern auch, einer Confluence-Site auf einfache Weise einen neuen Administrator hinzuzufügen, indem sie die Methode getUserAccessor().addUser() in der OGNL-Payload nutzen.

(url=* OR resource=*) request_method=*
| process eval("decoded_resource=urldecode(resource)")
| process eval("decoded_url=urldecode(url)")
| rename decoded_resource as resource, decoded_url as url
| search ( resource IN [ "*${*addUser(*"] OR url IN [ "*${*addUser(*"] )
| chart count() by log_ts, user, source_address, resource, user_agent

Searching for new user creations artifacts

Die Suche nach Artefakten zu neu erstellten Usern

Administratoren können dies überprüfen, indem sie in den Audit-Logs von Confluence nach neu erstellten Usern (insbesondere Admins) durch den Benutzer „Anonymous“ suchen.

New admin user ‘newadmin’ created by the ‘Anonymous’ user

Der neue Administrator „newadmin“, der von dem User „Anonymous“ erstellt wurde

Wie bereits erwähnt, beobachtete Volexity, dass die Angreifer – nachdem sie den Zero-Day-Exploit ausgenutzt hatten – die Open-Source-Webshell BEHINDER nutzten, die die legitime Datei noop.jsp im Pfad /confluence ersetzte. Sie haben auch eine andere JSP-Version der Open-Source-Webshell Chopper als Backup abgelegt.

LogPoint empfiehlt Analysten, HTTP-Anfragen an die Ressource noop.jsp zu überwachen. Sie benötigen keine speziellen Abfragen, um Befehlsausführungen über diese Web-Shells zu erkennen.

(resource="/noop.jsp" OR url="*/noop.jsp")

 Search for requests to noop.jsp resource

Die Suche nach Anfragen an die Ressource noop.jsp

Die Behebung der Schwachstelle mit den LogPoint SOAR Playbooks

Falls Analysten Spuren eines Angriffs entdecken, sollten sie die Confluence-Instanz isolieren und ihr Incident-Response-Verfahren einleiten.

Block IP template in Logpoint SOAR
Das Block-IP-Template in LogPoint SOAR

Isolate Host playbook in Logpoint SOAR

Das Isolate-Host-Playbook in LogPoint SOAR

Kunden können ihre SOAR-Playbooks ausführen, um IPs zu blockieren, die versuchen, die Schwachstelle auszunutzen oder dies bereits erfolgreich getan haben.

Die Erkennung von Aktivitäten nach einer Kompromittierung ist der Schlüssel zur Erkennung von Zero-Day-Exploits

LogPoint empfiehlt Analysten, der Erkennung von Aktivitäten nach einer Kompromittierung Priorität einzuräumen, da es sehr einfach ist, die Signaturprüfung von URLs zu umgehen. Angreifer können diese Schwachstelle auch über Payloads in POST-Daten ausnutzen. Somit sind Erkennungen auf Basis von URLs unbrauchbar.

Die aktuelle Bedrohungslandschaft zwingt die Sicherheitsverantwortlichen in Unternehmen dazu, von dem Szenario „Sicherheitsverletzungen sind zu erwarten“ auszugehen und proaktiv nach Bedrohungen zu suchen. Die Erkennung von Zero-Day-Exploits ist schwierig, aber es gibt auch einen einfachen und praktikablen Weg. Security-Teams sollten nach den Aktivitäten in Folge Kompromittierung Ausschau halten und diese untersuchen, um die eigentliche Ursache zu finden. Sie müssen hierfür eine Baseline erstellen, damit verdächtige Aktionen aus den regulären und legitimen Aktivitäten hervorstechen.

Contact Logpoint

Contact us and learn why
industry-leading companies
choose Logpoint:

Contact Logpoint