Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
DirtyClone — DirtyClone - preuve de concept d'escalade de privilèges locaux (LPE) ciblant une vulnérabilité liée au noyau/XFRM décrite dans la source comme CVE-2026-43503 | Kitploit
Outils/GitHubGitHub/gl1tch0x1/dirtyclone
Escalade de PrivilègesExploitationShellcodeCryptographieDéveloppement de Charges UtilesExploitation de Binaires
GitHubgl1tch0x1/dirtyclone

DirtyClone

DirtyClone - preuve de concept d'escalade de privilèges locaux (LPE) ciblant une vulnérabilité liée au noyau/XFRM décrite dans la source comme CVE-2026-43503

Voir le dépôt
21il y a 1 moisPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

DirtyClone

DirtyClone est un outil de diagnostic et de preuve de concept pour l'escalade de privilèges locaux écrit en C. Il cible un vecteur d'exploitation lié au noyau/XFRM décrit dans la source sous le nom CVE-2026-43503 et est destiné uniquement à des recherches de sécurité autorisées dans des environnements contrôlés.

Aperçu

Ce dépôt contient :

  • dirtyclone.c – l'implémentation complète de l'exploit
  • README.md – guide d'utilisation et d'environnement

L'implémentation actuelle effectue les étapes de haut niveau suivantes :

  • crée des espaces de noms utilisateur et réseau isolés,
  • configure le réseau loopback et l'état/les politiques XFRM/IPsec,
  • construit une charge utile ESP utilisant le chiffrement AES-CBC,
  • tente la livraison via un chemin UDP basé sur TEE et un repli IP brut,
  • attend que le cache de pages du binaire SUID cible soit patché,
  • exécute le binaire cible si le cache de pages est modifié.

Avis important

Cet outil est destiné uniquement aux tests de sécurité autorisés. L'exécuter sur des systèmes sans autorisation explicite peut être illégal et peut compromettre l'intégrité du système.

Construction

Installez d'abord le paquet de développement OpenSSL requis :

root@kitploit:~
# Debian/Ubuntu
sudo apt-get install libssl-dev

# Fedora
sudo dnf install openssl-devel

# Arch Linux
sudo pacman -S openssl

Ensuite, compilez le binaire :

root@kitploit:~
gcc -o dirtyclone dirtyclone.c -lcrypto -Wall -O2

Utilisation

Exécutez le programme avec :

root@kitploit:~
./dirtyclone

Arguments optionnels :

root@kitploit:~
./dirtyclone -q    # mode silencieux
./dirtyclone -v    # mode verbeux (par défaut)
./dirtyclone -h    # afficher l'aide

Ce que fait le programme

Lors de l'exécution, le programme :

  1. affiche une bannière et vérifie s'il est déjà exécuté en tant que root ;
  2. vérifie les détails du noyau et de l'architecture et indique si le système semble correspondre à la plage vulnérable ;
  3. configure les espaces de noms et le réseau loopback ;
  4. configure l'état/les politiques XFRM et tente d'ajouter une règle netfilter TEE ;
  5. mappe le binaire SUID cible en mémoire et affiche un résumé PoC des octets d'origine par rapport aux octets attendus ;
  6. envoie un paquet ESP via UDP+TEE ou un repli IP brut ;
  7. attend que le cache de pages reflète les octets injectés, puis tente d'exécuter le binaire cible.

Comment DirtyClone fonctionne

L'exploit est construit autour d'une idée simple : le programme prépare une charge utile ESP/XFRM conçue qui amène le noyau à déchiffrer des données dans une région mémoire adossée au cache de pages, puis vérifie si les octets du binaire SUID cible ont changé.

En termes pratiques, le programme effectue les actions suivantes :

  • identifie un fichier cible, /usr/bin/su, et le mappe en mémoire ;
  • prépare une petite charge utile contenant des octets de shellcode et les métadonnées ESP nécessaires ;
  • chiffre la charge utile avec AES-CBC afin qu'elle puisse être injectée dans le chemin XFRM/ESP ;
  • envoie le paquet via la pile réseau locale en utilisant soit UDP assisté par TEE, soit un repli IP brut ;
  • surveille la région mappée pour voir apparaître les octets attendus ;
  • si les octets apparaissent, il suppose que le chemin d'exploitation a modifié le cache de pages et exécute le chemin cible patché.

Il s'agit d'un flux de preuve de concept, pas d'un framework d'escalade de privilèges généraliste. Il est destiné à démontrer le mécanisme de l'exploit et à aider à vérifier si un noyau cible expose encore le comportement vulnérable.

Exemple d'implémentation factice

L'exemple simplifié suivant montre le même concept à un niveau élevé :

root@kitploit:~
#include <stdio.h>
#include <string.h>

static int dummy_exploit(unsigned char *target_bytes) {
    unsigned char expected[] = {0x31, 0x0f, 0x05};
    memcpy(target_bytes, expected, sizeof(expected));
    return 0;
}

int main(void) {
    unsigned char target[16] = {0};
    dummy_exploit(target);
    printf("Octets patchés : %02x %02x %02x\n", target[0], target[1], target[2]);
    return 0;
}

Le vrai projet utilise le même principe, mais il conditionne la charge utile en un paquet de style ESP/XFRM et pilote le chemin du noyau via la pile réseau au lieu d'une simple copie mémoire.

Procédure d'exploitation

  1. Phase de configuration

    • le programme crée des espaces de noms pour isoler l'environnement du processus ;
    • il configure le réseau loopback pour que les paquets restent locaux.
  2. Préparation XFRM

    • l'exploit ajoute des états et politiques XFRM qui indiquent au noyau comment traiter le trafic ESP ;
    • il tente également d'installer une règle TEE pour que le trafic puisse être redirigé via le chemin prévu.
  3. Construction de la charge utile

    • le code construit une petite charge utile en texte clair contenant des octets de type shellcode ;
    • la charge utile est chiffrée avec AES-CBC en utilisant une clé de test statique.
  4. Phase de livraison

    • le programme envoie le paquet ESP conçu via UDP ou IP brut ;
    • le noyau traite le paquet et, sur un système vulnérable, écrit les données déchiffrées dans la région du cache de pages du binaire cible.
  5. Vérification et exécution

    • le code surveille les octets du fichier cible et vérifie s'ils correspondent aux octets de shellcode attendus ;
    • si c'est le cas, il tente d'exécuter le binaire cible et de passer le contrôle au chemin de charge utile injecté.

Détails techniques

L'implémentation inclut :

  • une logique de réessai adaptative en attendant les modifications du cache de pages,
  • des routines de nettoyage enregistrées via atexit et des gestionnaires de signaux,
  • une exécution sécurisée de commande basée sur fork/execvp,
  • le chiffrement AES-CBC à l'aide des API OpenSSL EVP,
  • un shellcode adapté à l'architecture pour x86_64 et AArch64,
  • une logique de livraison double pour le transport UDP assisté par TEE et IP brut.

Prérequis

La source attend un environnement Linux avec :

  • GCC ou Clang,
  • les en-têtes et bibliothèques de développement OpenSSL,
  • les commandes ip, iptables et modprobe disponibles sur le système,
  • un binaire cible à /usr/bin/su,
  • un noyau potentiellement vulnérable au chemin d'exploitation décrit.

Comportement attendu

Le programme est destiné à afficher un résumé PoC de diagnostic, puis soit :

  • patcher avec succès le cache de pages et exécuter le binaire cible, soit
  • échouer proprement si le noyau est patché ou si le chemin d'exploitation n'est pas disponible.

Si l'exploit ne se déclenche pas, le programme imprime un message clair suggérant que le noyau est probablement patché.

Sécurité et éthique

Utilisez ce projet uniquement lorsque :

  • vous possédez le système cible,
  • vous avez l'autorisation explicite de le tester,
  • vous opérez dans un laboratoire ou un environnement isolé.

N'exécutez jamais ce code sur des systèmes de production ou des systèmes pour lesquels vous n'avez pas la permission d'auditer.

Licence et paternité

L'en-tête source identifie l'auteur comme MrAashish0x1 (gl1tch0x1). Le dépôt n'inclut pas de fichier de licence séparé, donc le code doit être traité comme du matériel de recherche plutôt que comme un logiciel de production.

Télécharger l’outil