av Bhabesh Raj Rai, Security Research

Den 2 juni 2022 publicerade Atlassian en säkerhetsrekommendation för en kritisk zero-day-sårbarhet (CVE-2022-26134) som hackare utnyttjar i Confluence Server och Data Center. Sårbarheten gör det möjligt för en icke-autentiserad angripare att exekvera godtycklig kod på en sårbar Confluence Server eller Data Center-instans.

Säkerhetsrekommendationen konstaterade att alla stödda versioner av Confluence Server och Data Center berörs. Atlassian tillhandahöll patchar en dag efter att meddelandet publicerades och rekommenderar att alla kunder uppgraderar sina instanser till någon av de permanenta versionerna – 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4 och 7.18.1.

Zero-day-sårbarheten är i princip en injektionssårbarhet i OGNL som låter en icke-autentiserad användare exekvera godtycklig kod i programmet Confluence. OGNL-nyttolaster kan injiceras i URI:n eller nyttolasten i HTTP-förfrågningar. För att få åtkomst till kommando-utdata använder angriparna dummy-headers (X-Cmd-Response är den vanligaste) för att hysa utdata som returneras i HTTP-responsen.

Det Washington-baserade cybersäkerhetsföretaget Volexity upptäckte sårbarheten under en incidentresponsundersökning (IR) som genomfördes under Memorial Day-helgen. Volexity observerade att angripare använde sårbarheten för att distribuera en in-memory-kopia av implantatet BEHINDER och backup web-shells på Confluence server.

Cloudflare har identifierat förfrågningar som matchar potentiellt skadliga nyttolaster så tidigt som maj 26, vilket tyder på att angripare hade kunskap om sårbarheten innan säkerhetsrekommendationen från Atlassian. De observerade en stor ökning av aktiviteten från och med 3 juni, sannolikt på grund av publiceringen av detaljer och PoC:er av sårbarheten.

Om du inte kan uppgradera Confluence omedelbart har Atlassian inkluderat tillfälliga lösningar i sin säkerhetsrekommendation. Atlassian uppgav också att end-of-life-versioner av Confluence inte är fullt testade med den tillfälliga lösningen och rekommenderar därför uppgradering till en permanent version av Confluence eftersom de innehåller flera andra säkerhetskorrigeringar.

Kunder kan använda Logpoints program Use Case v5.1.2  som innehåller larm kopplade till identifiering av sårbarheten CVE-2022-26134.

Snabbfakta om CVE-2022-26134

  • Utnyttjad sedan maj 2022
  • Påverkar alla stödda versioner av Confluence Server och Data Center
  • Masskanning och exploatering har redan påbörjats
  • Flera PoC:er är publika

Loggkällor som krävs

  • Confluence åtkomstloggar
  • DNS
  • Brandvägg
  • Linux-versioner av Confluence
    • Sysmon för Linux
    • Auditd
  • Windows-versioner av Confluence
    • Inbyggda händelseloggar
    • Sysmon

Identifiering av intrång med Logpoint

Det första en analytiker kan göra är att utföra en IoC-sweep med hjälp av indikatorer från VolexityGreyNoise osv.

(source_address IN CVE_2022_26134_IPS OR destination_address IN CVE_2022_26134_IPS)

 Geolocation distribution of source IP hit

Geolokaliseringsfördelning av käll-IP-träffar

Confluence åtkomstloggning registrerar OGNL-nyttolaster men är inte aktiverad som standard. Administratörer bör säkerställa att de har aktiverat den, eftersom Confluence loggar varje begäran som görs till webbplatsen när den är aktiverad. Loggfilen finns i /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
Confluence åtkomstloggar visar OGNL-nyttolaster

Om din Confluence-instans körs på Windows ska du söka efter tomcat-processen som genererar misstänkta processer.

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
Sökning efter tomcat-process som genererar misstänkta underordnade processer

Om din Confluence-instans körs på Linux och har Sysmon för Linux installerat ska du söka efter confluence-användaren som genererar misstänkta processer. I vårt test fångade inte Sysmon för Linux den överordnade processens namn (java) och vi måste därför förlita oss på user- eller path-fältet.

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
Söka efter Confluence-användaren som genererar misstänkta processer i Sysmon för Linux-händelser

Alternativt kan angripare använda Java-klassen Nashorn för att skapa reverse shells för direkta interaktioner.

(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
Söka efter användning av Java-klassen Nashorn

Analytiker kan söka efter artefakter från reverse shells med hjälp av processkapande händelser.

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
Söker efter skapande av reverse shell i Sysmon för Linux-händelser

Om du inte har Sysmon för Linux-övervakning kan analytiker använda sig av auditd-händelser.

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
Söka efter misstänkt processexekvering i auditd-händelser

Proctitle-händelser registrerar alla kommandorader för processexekvering. Övervaka dina Confluence-instanser för misstänkta kommandorader som de normalt inte exekverar.

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
Sök efter misstänkta kommandorader i proctitle-händelser från auditd

Angripare använder ofta externa webbplatser som Interactsh för att identifiera sårbara system genom out-of-band-interaktioner. Undersök systemen som ligger bakom dessa DNS-frågesatser.

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
Söka efter DNS-förfrågningar till webbplatser av Interactsh-typ i Sysmon DNS-händelser

Denna sårbarhet gör det också möjligt för angripare att enkelt lägga till en ny administratörsanvändaretill Confluence-webbplatsen genom att använda metoden getUserAccess().adduser() i OGNL-nyttolasten.

(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
Söka efter artefakter från skapande av nya användare

Administratörer kan verifiera detta genom att söka efter skapandet av nya användare (särskilt administratörer) av användaren ”Anonymous” i granskningsloggarna från Confluence.

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

Ny administratörsanvändare ”newadmin” skapad av användaren ”Anonymous”

Som nämnts tidigare observerade Volexity att angripare – efter att ha utnyttjat zero-day-sårbarheten – använde open source webshell BEHINDER som ersatte den legitima filen noop.jsp som finns i sökvägen /confluence. De installerade även en annan JSP-version av open-source webshell Chopper som backup.

Vi rekommenderar att analytiker övervakar HTTP-förfrågningar till resursen noop.jsp. Vi behöver inga speciella frågesatser för att identifiera kommandoexekveringar genom dessa webshells.

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

 Search for requests to noop.jsp resource
Sök efter förfrågningar till resursen noop.jsp

Åtgärda med hjälp av Logpoint SOAR playbooks

Vid detektering av spår av intrång bör analytiker isolera Confluence-instansen och initiera sin incidenthanteringsprocedur.

Block IP template in Logpoint SOAR

Mallen Block IP i Logpoint SOAR

Isolate Host playbook in Logpoint SOAR

Isolate Host playbook i Logpoint SOAR

Kunder kan köra sina SOAR playbooks för att blockera IP-adresser som försöker eller redan har utnyttjat sårbarheten.

Identifiering av aktiviteter efter framgångsrikt intrång är avgörande för att detektera zero-day-intrång

Vi råder analytiker att prioritera identifiering av aktiviteter efter intrång eftersom det är mycket enkelt att kringgå signaturkontroller för URL:er. Angripare kan även utnyttja denna sårbarhet via nyttolaster i POST-data, vilket gör detekteringar baserade på URL:er meningslösa.

Det nuvarande hotlandskapet har tvingat säkerhetsexperter att förutsätta att intrång redan har skett och aktivt söka efter hot. Det är svårt att upptäcka zero-day-intrång, men det finns ett enkelt och genomförbart sätt. Säkerhetsexperter bör söka efter vanligt förekommande aktiviteter efter intrång och undersöka dem för att hitta grundorsaken. De måste fastställa en basnivå så att alla misstänkta aktiviteter lätt sticker ut från bruset.

Contact Logpoint

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

Contact Logpoint