af Bhabesh Raj Rai, Security Research

Den 2. juni 2022 udsendte Atlassian en sikkerhedsmeddelelse om en kritisk zero-day sårbarhed (CVE-2022-26134), som hackere udnytter i Confluence Server og Data Center. Fejlen gør det muligt for en uautoriseret angriber at udføre en vilkårlig kode på en sårbar Confluence Server- eller Data Center-instans.

Meddelelsen angav, at alle understøttede versioner af Confluence Server og Data Center er berørt. Atlassian leverede programrettelser en dag efter, at meddelelsen blev udsendt, og rådede alle kunder til at opgradere deres instanser til en af de rettede versioner – 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4 og 7.18.1.

I bund og grund er zero-day en OGNL-injektionsfejl, der gør det muligt for en uautoriseret bruger at udføre en vilkårlig kode i Confluence-applikationens kontekst. OGNL-nyttelaster kan indsættes i URI’en eller som nyttelaster i HTTP-anmodninger. For at få kommandooutputtene tilbage bruger angriberne dummy-headere (X-Cmd-Response er den mest almindelige) til at rumme de output, der vil blive returneret i HTTP-reaktionen.

Volexity, et Washington-baseret cybersikkerhedsfirma, opdagede fejlen i forbindelse med en IR-undersøgelse, som de havde foretaget i løbet af Memorial Day-weekenden. Volexity observerede angribere, der brugte zero-day til at udrulle en in-memory kopi af BEHINDER-implantatet og sikkerhedskopiere webshells på Confluence serveren.

Cloudflare har identificeret anmodninger, der matcher potentielt ondsindede nyttelaster allerede den 26. maj, hvilket tyder på, at angriberne havde kendskab til zero-day før sikkerhedsmeddelelsen fra Atlassian. De observerede en stor stigning i aktiviteten fra 3. juni, sandsynligvis på grund af udgivelsen af detaljer og PoC’er om sårbarheden.

Hvis du ikke er i stand til at opgradere Confluence med det samme, har Atlassian medtaget midlertidige løsninger i deres sikkerhedsmeddelelse. Atlassian nævnte også, at Confluence end-of-life-versioner ikke er fuldt testede med workaround, så de anbefaler kraftigt opgradering til en rettet version af Confluence, da der er flere andre sikkerhedsrettelser inkluderet.

Kunderne kan benytte Logpoints Use Case v5.1.2 applikation, der indeholder alarmer relateret til identifikation af CVE-2022-26134 udnyttelse.

Hurtige fakta om CVE-2022-26134

  • Udnyttet siden maj 2022
  • Påvirker alle understøttede versioner af Confluence Server og Data Center
  • Massescanning og udnyttelse er allerede påbegyndt
  • Flere PoC’er er offentlige

Påkrævede logkilder

  • Confluence adgangslogger
  • DNS
  • Firewall
  • Confluences, der kører i Linux
    • Sysmon til Linux
    • Auditd
  • Confluences, der kører i Windows
    • Oprindelige hændelseslogge
    • Sysmon

Identifikation af udnyttelse i LogPoint

Det første analytikere kan gøre, er at udføre en IoC-sweep ved hjælp af indikatorer fra Volexity, GreyNoiseosv.

 Geolocation distribution of source IP hit

Geolokationsdistribution af kilde IP hit

Confluence access logging registrerer OGNL-nyttelaster, men er ikke aktiveret som standard. Administratorer skal sikre, at de har aktiveret den, fordi Confluence logger alle anmodninger, der sendes til webstedet, når funktionen er aktiveret. Logfilen ligger 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 access logging viser OGNL-nyttelaster

Hvis din Confluence-instans kører på Windows, skal du kigge efter tomcat-processen, der opretter mistænkelige 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øger efter tomcat-proces, der opretter mistænkelige underordnede processer

Hvis din Confluence-instans kører på Linux og har Sysmon for Linux installeret, skal du kigge efter Confluence-brugeren, der opretter mistænkelige processer. I vores test fangede Sysmon for Linux ikke det overordnede procesnavn (java), så vi er nødt til at stole på enten bruger- eller stifeltet.

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øgning efter Confluence-brugeren, der opretter mistænkelige processer i Sysmon for Linux-hændelser

Alternativt kan angribere bruge Nashorn Java-klassen til at skabe omvendte skaller til direkte 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øgning efter anvendelse af Nashorn java-klassen

Analytikere kan søge efter omvendte skal-artefakter ved hjælp af procesoprettelseshæ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øger efter oprettelser af omvendt skal i Sysmon for Linux-hændelser

Hvis du ikke har Sysmon for Linux-overvågning, kan analytikere benytte 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øger efter mistænkelige procesudførelser i auditd hændelser

Proctitle-hændelser registrerer de fulde kommandolinjer for procesudførelser. Overvåg dine Confluence-instanser for mistænkelige kommandolinjer, som den normalt ikke udfører.

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øg efter mistænkelige kommandolinjer i auditd’s proctitle-hændelser

Angribere bruger ofte eksterne websteder som Interactsh til at identificere sårbare systemer gennem out-of-band-interaktion. Undersøg systemer, der ligger bag disse DNS-forespørgsler.

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øger efter DNS-forespørgsler til Interactsh-type-sites i Sysmon DNS-hændelser

Denne sårbarhed gør det også muligt for angribere nemt at tilføje en ny administratorbruger til Confluence-sitet ved hjælp af getUserAccessor().addUser()-metoden i OGNL-nyttelasten.

(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øgning efter artefakter til oprettelse af nye brugere

Administratorer kan bekræfte dette ved at søge efter nye brugeroprettelser (især administratorer) af brugeren “Anonym” i Confluences auditlogs.

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

Ny admin-bruger ‘newadmin’ oprettet af brugeren ‘Anonym’

Som tidligere nævnt observerede Volexity angribere – efter at have udnyttet zero-day – ved hjælp af open-source BEHINDER webshell, som erstattede den legitime noop.jsp-fil placeret på /confluence-stien. De lancerede også en anden JSP-version af open source-chopperens webshell som backup.

Vi anbefaler analytikere at overvåge for HTTP-anmodninger til noop.jsp-ressource . Vi har ikke brug for særlige forespørgsler for at registrere kommandoudførelser gennem disse webshells.

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

 Search for requests to noop.jsp resource

Søg efter anmodninger til noop.jsp-ressource

Afhjælpning med Logpoint SOAR playbooks

Når analytikerne opdager spor efter udnyttelse, skal de isolere Confluence-instansen og iværksætte deres hændelsesresponsprocedure.

Block IP template in Logpoint SOAR

Blokér IP-skabelon i Logpoint SOAR

Isolate Host playbook in Logpoint SOAR

Isoler Host playbook i LogPoint SOAR

Kunderne kan køre deres SOAR playbooks for at blokere IP’er, der forsøger at udnytte eller har haft succes med at udnytte fejlen.

Identifikation af aktivitet udført efter at være kompromitteret er nøglen til at påvise zero-day-udnyttelser

Vi råder analytikere til at prioritere identifikation af aktiviteter efter at være blevet kompromiteret, da det er trivielt at omgå signaturkontroller på URL’er. Angribere kan også udnytte denne sårbarhed via nyttelaster i POST-data, hvilket gør identifikation baseret på URL’er ubrugelig.

Det nuværende trusselslandskab har tvunget virksomhedernes forsvar til at indføre scenariet “formod overtrædelse” og proaktivt jagte trusler. Det er svært at identificere zero-day-udnyttelse, men der er en nem og gennemførlig måde at gøre det på. Forsvarere bør lede efter almindelige aktiviteter efter at være blevet kompromitteret og undersøge dem for at finde den grundlæggende årsag. De skal skabe en basislinje, så enhver mistænkelig aktivitet let kan skelnes fra støjen.

 

Contact Logpoint

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

Contact Logpoint