Aller au contenu
Hermes Codex

Playbook de Réponse aux Incidents : Ivanti EPMM (CVE-2026-1281 & 1340)

1. Mécanique de la vulnérabilité : l’injection Bash

Section intitulée « 1. Mécanique de la vulnérabilité : l’injection Bash »

Selon les recherches approfondies menées par WatchTowr Labs, la cause profonde de ces deux vulnérabilités est un défaut de nettoyage des entrées (sanitization) conduisant à une injection de commande OS.

L’architecture d’EPMM utilise des points de terminaison API spécifiques (/mifs/c/aftstore et /mifs/c/appstore) pour gérer les téléversements de fichiers et la préparation des applications. Lors du traitement des requêtes vers ces points de terminaison, l’application Java en arrière-plan transmet l’entrée fournie par l’utilisateur (spécifiquement le paramètre theValue) directement dans un script Bash mal construit et exécuté via Runtime.getRuntime().exec().

En concevant soigneusement une charge utile utilisant des techniques d’expansion Bash et de substitution de commandes (contournant ainsi les filtres simples sur les espaces et les guillemets), un attaquant sort du contexte d’exécution prévu et exécute des commandes arbitraires directement sur l’OS Linux sous-jacent.

2. Phase 1 : triage des journaux (l’inspection des 15 minutes)

Section intitulée « 2. Phase 1 : triage des journaux (l’inspection des 15 minutes) »

L’objectif principal est de déterminer si une tentative d’exploitation a eu lieu et si elle a réussi. Cela nécessite d’analyser les journaux d’accès Apache sur l’appliance.

Fichier cible : /var/log/httpd/https-access_log

  1. La regex de chasse : les attaquants ciblent des chemins d’URI spécifiques contenant les paramètres vulnérables. Utilisez grep sur les journaux extraits :
    Fenêtre de terminal
    grep -E ".*\/mifs\/c\/(aft|app)store.*theValue\?\?.*" /mnt/analyse/var/log/httpd/https-access_log
  2. Interpréter le code de statut HTTP (le paradoxe du 404) :
    • Statut 404 Not Found : ne l’ignorez pas ! En raison de la façon dont le backend gère la charge utile malformée après le déclenchement de l’injection de commande, un exploit réussi renverra fréquemment un code de statut 404. Une correspondance de regex associée à un 404 est un indicateur de compromission (IOC) de haute fiabilité.
    • Statut 200 OK : cela représente souvent un trafic légitime de “heartbeat” ou de synchronisation (ex: les requêtes se terminant par .../sha256:kid=0). Si l’URI correspond au modèle de heartbeat bénin connu, il peut être filtré.

3. Phase 2 : analyse forensique hors ligne (post-exploitation)

Section intitulée « 3. Phase 2 : analyse forensique hors ligne (post-exploitation) »

Contrairement à Ivanti Connect Secure (ICS), EPMM ne dispose pas d’un outil de vérification d’intégrité (ICT) mature pour la chasse automatisée aux artefacts. Les analystes DFIR doivent monter manuellement l’image forensique (ex: dans /mnt/analyse/) et chasser les mécanismes de préparation et de persistance.

A. Chasse aux webshells et aux droppers

Section intitulée « A. Chasse aux webshells et aux droppers »

Comme l’a observé l’unité de recherche Unit 42, les acteurs de la menace déposent des webshells distincts pour établir un accès distant persistant.

  • Répertoires cibles :
    • / (répertoire racine, pour les exploits mal codés)
    • /tmp/ et /var/tmp/ (préparation standard de la charge utile)
    • /var/www/ext/html/ (la racine web critique pour la persistance)
  • Signatures de fichiers à chasser :
    • noms de fichiers extrêmement courts (ex: a, x.sh).
    • archives compressées utilisant l’algorithme LZMA2 (fréquemment utilisé dans cette campagne spécifique pour contourner l’inspection réseau basique).
    • fichiers se faisant passer pour des pages d’erreur : 401.jsp ou error.jsp.
    • Actifs modifiés (Trojanized) : les attaquants écrasent des fichiers d’images légitimes avec du code de webshell. Prêtez une attention particulière à favicon.png dans /var/www/ext/html/. Vérifiez son type de fichier en utilisant file favicon.png et vérifiez son hash. S’il contient du code Java ou Perl, c’est un webshell.

B. IOCs réseau et reverse shells

Section intitulée « B. IOCs réseau et reverse shells »

Les appliances EPMM ne devraient pas initier de connexions sortantes inattendues.

  • Vérifiez les journaux du pare-feu sortant ou du proxy pour des connexions de longue durée provenant de l’IP de l’EPMM.
  • User-Agent spécifique : recherchez Edg/143.0.0.1 dans vos journaux de bordure. Cette chaîne d’Agent Utilisateur spécifique était codée en dur dans plusieurs scripts d’exploitation publics.

4. Phase 3 : évaluation de l’impact

Section intitulée « 4. Phase 3 : évaluation de l’impact »

Si un exploit réussi et le dépôt subséquent d’un webshell sont confirmés, les analystes doivent envisager le pire scénario. L’acteur de la menace a obtenu l’accès à l’intégralité de la base de données MDM.

Les données exfiltrées incluent probablement :

  • Données administratives : noms, e-mails et noms d’utilisateurs des administrateurs EPMM.
  • PII des utilisateurs : noms, e-mails professionnels, UPN de tous les employés enregistrés.
  • Télémétrie des appareils : numéros de téléphone, IMEI/MEID, localisations GPS et listes des applications installées sur les appareils d’entreprise.
  • Secrets d’entreprise : mots de passe de liaison LDAP, hashs de comptes de service Kerberos, et potentiellement les certificats clients poussés via le MDM.

5. Phase 4 : remédiation (la politique de la “terre brûlée”)

Section intitulée « 5. Phase 4 : remédiation (la politique de la “terre brûlée”) »

Les directives de sécurité officielles d’Ivanti sont explicites : ne tentez pas de nettoyer une appliance compromise. La profondeur de l’injection de commande OS et le potentiel de rootkits enfouis rendent toute remédiation non fiable.

Si l’appliance est compromise, vous devez exécuter une reconstruction de type “terre brûlée” (Scorched Earth).

  1. Isoler et préserver : déconnectez immédiatement l’appliance EPMM compromise du réseau. Capturez un snapshot forensique (mémoire et disque) à des fins légales et d’investigation.
  2. Reconstruire : déployez une nouvelle instance d’appliance EPMM entièrement propre.
  3. Restaurer : importez une sauvegarde de configuration effectuée à une date strictement antérieure à la première tentative d’exploitation identifiée dans les journaux.
  4. Patcher : appliquez les correctifs pour les CVE-2026-1281 et CVE-2026-1340 sur la nouvelle instance avant de la connecter au réseau de production.
  5. Faire pivoter tous les secrets (CRITIQUE) :
    • réinitialisez tous les mots de passe administratifs locaux d’EPMM.
    • réinitialisez les mots de passe de tous les comptes de service Active Directory (LDAP, KDC) utilisés par l’intégration EPMM.
    • révoquez et remplacez le certificat TLS public de l’appliance EPMM.
    • considération : selon la gravité de la brèche, évaluez la nécessité de révoquer les certificats clients poussés vers les appareils mobiles gérés.

6. Requêtes de Threat Hunting

Section intitulée « 6. Requêtes de Threat Hunting »
hunt_epmm_cve_1281.spl
# Recherche du motif d'URI d'exploit spécifique dans les journaux d'accès Apache/EPMM
index=web_logs sourcetype=access_combined
| search uri_path="*/mifs/c/aftstore*" OR uri_path="*/mifs/c/appstore*"
| search query="*theValue??*"
# Alerte spécifique si le serveur a renvoyé un 404 (indicateur de succès de l'exploit)
| eval is_suspicious = if(status==404, "HIGH", "MEDIUM")
| table _time, src_ip, http_method, uri_path, query, status, is_suspicious
| sort - _time

Sources et références

Section intitulée « Sources et références »