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.
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*"] )
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
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
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()*" ] )
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
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
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
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'] )
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
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.
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")
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.
Das Block-IP-Template 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.
