by Bhabesh Raj Rai, Security Research
Le 2 juin 2022, Atlassian a publié un avis de sécurité concernant une vulnérabilité critique de type zero-day (CVE-2022-26134) que des cybercriminels exploitaient dans Confluence Server et Data Center. La faille permettait à un attaquant non authentifié d’exécuter du code arbitraire sur une instance vulnérable de Confluence Server ou Data Center.
L’avis indiquait que toutes les versions prises en charge de Confluence Server et Data Center étaient affectées. Atlassian a fourni des correctifs un jour après la publication de l’avis et a conseillé à tous les clients de mettre à niveau leurs instances vers l’une des versions corrigées suivantes : 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4 et 7.18.1.
Pour résumer, la vulnérabilité zero-day est une faille d’injection OGNL qui permet à un utilisateur non authentifié d’exécuter du code arbitraire dans le contexte de l’application Confluence. Les charges virales OGNL peuvent être injectées dans l’URI ou via la charge virale des requêtes HTTP. Pour récupérer les sorties de commande, les attaquants utilisent des en-têtes factices (X-Cmd-Response étant le plus courant) pour héberger les sorties qui seront renvoyées dans la réponse HTTP.
Volexity, une société de cybersécurité basée à Washington, a découvert la faille lors d’une investigation IR qu’elle avait menée pendant le week-end du Memorial Day. Volexity a observé des attaquants utilisant la faille zero-day pour déployer une copie en mémoire de l’implant BEHINDER et des Web shells de sauvegarde sur le serveur Confluence.
Cloudflare a identifié des requêtes correspondant à des charges virales potentiellement malveillantes dès le 26 mai, indiquant que les attaquants connaissaient cette faille zero-day avant l’avis de sécurité émis par Atlassian. Ils ont observé un important pic d’activité à partir du 3 juin, probablement en raison de la publication des détails et du PoC concernant cette vulnérabilité.
Si vous ne parvenez pas à mettre à niveau Confluence immédiatement, Atlassian a inclus des solutions de contournement temporaires dans son avis. Atlassian a également déclaré que les versions en fin de vie de Confluence n’étaient pas entièrement testées avec ces solutions. Ils recommandent donc fortement de passer à une version fixe de Confluence, car plusieurs autres correctifs de sécurité sont inclus.
Les clients peuvent utiliser l’application Use Case v5.1.2 de Logpoint qui inclut des alertes liées à la détection de l’exploitation de CVE-2022-26134.
CVE-2022-26134 en bref
- Exploité sur le terrain depuis mai 2022
- Affecte toutes les versions prises en charge de Confluence Server et Data Center
- L’analyse et l’exploitation de masse ont déjà commencé
- Plusieurs PoC sont publics
Sources de log nécessaires
- Logs d’accès à Confluence
- DNS
- Firewall
- Confluences fonctionnant sous Linux
- Sysmon pour Linux
- Auditd
- Confluences fonctionnant sous Windows
- Logs d’événements natifs
- Sysmon
Détection de l’exploitation avec Logpoint
La première action que les analystes peuvent lancer est un balayage des IoC en utilisant les indicateurs fournis par Volexity, GreyNoise, etc.
(source_address IN CVE_2022_26134_IPS OR destination_address IN CVE_2022_26134_IPS)
Répartition de la géolocalisation des hits de l’IP source
La journalisation des accès Confluence enregistre les charges virales OGNL, mais elle n’est pas activée par défaut. Les administrateurs doivent s’assurer qu’ils l’ont activé, car lorsqu’elle est activée, Confluence enregistre chaque demande effectuée sur le site. Le fichier log se trouve dans <install directory>/logs/conf_access_log<date>.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*"] )
La journalisation des accès Confluence affiche les charges virales OGNL
Si votre instance Confluence s’exécute sous Windows, recherchez le processus Tomcat qui génère des processus suspects.
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
Recherche d’un processus Tomcat engendrant des processus enfants suspects
Si votre instance Confluence s’exécute sous Linux et que Sysmon pour Linux est installé, recherchez l’utilisateur Confluence qui génère des processus suspects. Dans notre test, Sysmon pour Linux n’a pas capturé le nom du processus parent (java), nous devons donc nous fier au champ ‘user’ ou ‘path’.
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
Recherche de l’utilisateur de Confluence engendrant des processus suspects dans les événements Sysmon pour Linux
Alternativement, les attaquants peuvent utiliser la classe Java Nashorn pour créer des shells inversés concernant des interactions directes.
(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()*" ] )
Recherche d’utilisation de la classe Java Nashorn
Les analystes peuvent rechercher des artefacts de shell inversé à l’aide d’événements de création de processus.
label="Process" label=Create
command IN ["*/dev/tcp/*", "*bash -i >&*"]
| chart count() by log_ts, user, image, command
Recherche de créations de shell inversé (reverse shell) dans les événements Sysmon pour Linux
Si vous ne disposez pas de la surveillance Sysmon pour Linux, les analystes peuvent utiliser les événements auditd.
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
Recherche d’exécutions suspectes de processus dans les événements auditd
Les événements Proctitle capturent les lignes de commande complètes des exécutions de processus. Surveillez vos instances Confluence concernant les lignes de commande suspectes qu’il n’exécute pas normalement.
norm_id=Unix "process"=audit event_type=PROCTITLE host IN CONFLUENCE_HOSTS
| chart count() by host, command
Rechercher des lignes de commande suspectes dans les événements proctitle d’auditd
Les attaquants utilisent couramment des sites externes comme Interactsh pour identifier les systèmes vulnérables via des interactions hors bande. Examinez les systèmes qui se cachent derrière ces requêtes DNS.
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'] )
Recherche de requêtes DNS vers des sites de type Interactsh dans les événements DNS Sysmon
Cette vulnérabilité permet également aux attaquants d’ajouter facilement un nouvel utilisateur administrateur au site de Confluence en utilisant la méthode getUserAccessor().addUser() dans la charge virale OGNL.
(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
Recherche de nouveaux artefacts de créations d’utilisateurs
Les administrateurs peuvent le vérifier en recherchant les nouvelles créations d’utilisateurs (en particulier les administrateurs) par l’utilisateur « Anonymous » dans les logs d’audit de Confluence.
Nouvel utilisateur administrateur « newadmin » créé par l’utilisateur » Anonymous »
Comme mentionné précédemment, Volexity a observé des attaquants, après avoir exploité la faille zero-day, en utilisant le Web shell open source BEHINDER qui a remplacé le fichier légitime noop.jsp situé dans <Confluence root>/confluence path. Ils ont également diffusé une autre version JSP du webshell open source Chopper en tant que sauvegarde.
Nous conseillons aux analystes de surveiller les requêtes HTTP concernant la ressource noop.jsp. Nous n’avons pas besoin de requêtes spéciales pour détecter les exécutions de commandes via ces Web shells.
(resource="/noop.jsp" OR url="*/noop.jsp")
Rechercher des demandes concernant la ressource noop.jsp
Remédiation avec les playbooks Logpoint SOAR
Lors de la détection de traces d’exploitation, les analystes doivent isoler l’instance Confluence et lancer leur procédure de réponse aux incidents.
Bloquer le modèle d’IP dans Logpoint SOAR
Isoler le playbook de l’hôte dans Logpoint SOAR
Les clients peuvent exécuter leurs playbooks SOAR pour bloquer les IP qui tentent d’exploiter ou ont réussi à exploiter la faille.
La détection de l’activité post-compromission est essentielle pour détecter les exploitations zero-day
Nous conseillons aux analystes de donner la priorité à la détection de l’activité post-compromission car il est facile de contourner les vérifications de signature au niveau des URL. Les attaquants peuvent également exploiter cette vulnérabilité via des charges virales dans les données POST rendant les détections basées sur des URL inutiles.
Le paysage actuel des menaces a contraint les défenseurs des entreprises à adopter le scénario «assume breach» et à rechercher de manière proactive les menaces. Détecter l’exploitation zero-day est difficile, mais il existe un moyen simple et faisable. Les défenseurs doivent rechercher les activités courantes post-compromission et les investiguer pour trouver la cause racine. Ils doivent créer une référence afin que toute activité suspecte se démarque facilement du bruit.
