Qu'est-ce que l'exécution de code à distance (RCE) ? Comment l'IA accélère l'exploitation et comment limiter les dégâts

Une faille d'exécution de code à distance transforme un serveur vulnérable en l'ordinateur de quelqu'un d'autre. L'attaquant envoie une entrée que l'application aurait dû rejeter, et l'application l'exécute comme une commande. L'IA accélère les parties de ce travail qui prenaient auparavant du temps réel à l'attaquant.

Qu'est-ce que l'exécution de code à distance (RCE) ?

L'exécution de code à distance est une classe de vulnérabilité qui permet à un attaquant d'exécuter son propre code ou ses commandes sur un système cible via un réseau, sans accès préalable. On l'appelle aussi exécution arbitraire de code. Dans tous les cas, c'est l'attaquant qui décide des actions de la machine. Une vulnérabilité RCE provient généralement d'une application qui transmet des entrées non fiables à quelque chose qu'elle exécute : une commande shell, un modèle, un objet désérialisé, un gestionnaire de téléchargement de fichiers. L'exploit RCE est l'entrée ou la séquence spécifique qui déclenche la faille.

Comment fonctionne l'exécution de code à distance

L'attaque se déroule généralement en ligne droite. L'attaquant trouve un système exposé exécutant un composant vulnérable, envoie une entrée conçue et fait exécuter du code sous le compte de service. La première charge utile reste petite, généralement un web shell ou une commande qui télécharge quelque chose. Des outils plus importants arrivent après que l'attaquant confirme que la prise de contrôle fonctionne.

Log4Shell (CVE-2021-44228) est un bon exemple de la portée qu’une seule faille peut avoir. Révélée en décembre 2021 dans la bibliothèque de journalisation Apache Log4j, elle permettait à une chaîne spécialement conçue dans un champ journalisé de faire exécuter du code contrôlé par un attaquant sur un serveur vulnérable. Log4j était intégré dans tant d’applications que la faille est apparue partout.

La plupart des bugs RCE commencent petits. La première fonction ci-dessous transmet directement l'entrée utilisateur à un shell. La seconde abandonne le shell et valide l'entrée.

      # Vulnerable: input goes straight to a shell
import os
def ping(host):
    os.system("ping -c 1 " + host)   # host = "8.8.8.8; id" runs a second command

# Safer: no shell, validated input
import ipaddress, subprocess
def ping(host):
    ipaddress.ip_address(host)        # raises ValueError unless host is an IP
    subprocess.run(["ping", "-c", "1", host], check=True)

      

Comment l'IA modifie les attaques d'exécution de code à distance

La classe de vulnérabilité est ancienne. Les attaquants ont modifié la rapidité avec laquelle ils peuvent progresser à chaque étape.

Les cibles sont classées

Le scan à l’échelle d’Internet existe depuis des années. L’IA aide au tri : les résultats du scan peuvent être regroupés par logiciel et version, puis classés selon la probabilité que chaque système présente une faille connue, afin que les attaquants ciblent d’abord les meilleures cibles.

Les correctifs deviennent des tutoriels d’exploitation

Les fournisseurs publient des correctifs et des avis pour aider les défenseurs, et les attaquants les lisent aussi. Un modèle peut prendre un diff de correctif ou un avis et décrire le chemin de code vulnérable, ce qui réduit le travail de rétro-ingénierie et raccourcit le temps entre la divulgation publique et un exploit fonctionnel.

Un proof of concept, plusieurs versions

Une preuve de concept publique cible généralement une version ou un framework. Les modèles peuvent la porter vers une version ou une langue différente et modifier la charge utile pour contourner un schéma de détection connu.

Les attaques en plusieurs étapes nécessitent moins de compétences

De nombreuses attaques web se déroulent en deux étapes. Une petite injection prouve que le code s’exécute, puis une seconde étape télécharge des outils plus importants. Les modèles peuvent concevoir cette chaîne et la réessayer avec des modifications lorsqu’une étape échoue, donc lancer des attaques en plusieurs étapes contre un CMS, une API ou un portail demande moins de compétences qu’avant.

Le travail de suivi s'exécute via un script

Après l'exécution du code, la suite est répétitive : lire les fichiers de configuration, collecter les clés et les identifiants, créer une tâche planifiée pour que l'accès survive à un redémarrage, et rechercher les systèmes voisins. Les routines scriptées et assistées par IA effectuent ces étapes de la même manière à chaque fois.

La même chaîne, des centaines d’organisations

Une chaîne qui fonctionne contre une organisation peut être dirigée contre des centaines. Chaque étape précédente alimente la suivante, et chaque cible supplémentaire coûte moins à l’attaquant que la précédente.

Ce que font les attaquants dans les premières minutes après une exploitation RCE

Les premières actions après une exploitation réussie suivent un schéma. Les attaquants déposent un web shell ou un chargeur dans un répertoire où le service peut écrire, puis ajoutent une tâche planifiée, un service ou un cron job pour que l'accès survive à un redémarrage. Ensuite, ils extraient les credentials et les clés des fichiers de configuration et de la mémoire, puis commencent à sonder les systèmes voisins.

Chaque étape laisse une trace que vous pouvez vérifier. Ces commandes affichent les modifications récentes des fichiers dans une racine web et les nouvelles entrées cron sous Linux.

      # Files changed in the web root in the last 24 hours
find /var/www -type f -mtime -1 -ls

# Recently modified cron entries
ls -lt /etc/cron.d /var/spool/cron 2>/dev/null | head
      

Sous Windows, cette requête liste les tâches planifiées enregistrées au cours des dernières 24 heures. Activez d'abord le journal opérationnel du Planificateur de tâches, car il est désactivé par défaut.

      Get-WinEvent -FilterHashtable @{
  LogName   = 'Microsoft-Windows-TaskScheduler/Operational'
  Id        = 106
  StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated, Message
      

Les contrôles manuels comme ceux-ci fonctionnent sur un seul serveur. Sur des centaines de systèmes, ils prennent du retard, et un attaquant rapide peut finir avant la prochaine revue programmée.

Comment empêcher l'exécution de code à distance et limiter les dégâts

La correction et la gestion sécurisée des entrées restent les principales défenses contre une vulnérabilité RCE. Tout ce qui suit suppose qu'une faille sera exploitée avant la mise en place du correctif, donc l'objectif devient de détecter rapidement les changements et de limiter ce qu'un service compromis peut faire.

Netwrix Change Tracker surveille les systèmes touchés par une attaque RCE. Il établit des bases de référence de configuration et utilise la surveillance de l'intégrité des fichiers pour signaler les fichiers nouveaux ou modifiés, comme un web shell ajouté à un répertoire web, ainsi que les modifications des fichiers système critiques et des paramètres sur Windows, Linux, Unix et les appareils réseau. Son modèle de changement planifié compare ce qu'il observe aux demandes de changement approuvées, de sorte qu'une modification non programmée est signalée pour examen. L'historique des modifications fournit aux enquêteurs une chronologie, et l'authentification des fichiers système vérifie les fichiers par rapport aux bases de données mondiales de réputation pour confirmer lesquels sont fiables.

Netwrix PolicyPak limite ce qu’un attaquant peut faire une fois que le code s’exécute sur un système Windows. Le principe du moindre privilège supprime les droits d’administrateur local et définit des règles d’élévation pour les utilisateurs standard, de sorte qu’un processus compromis dispose de moins d’autorisations. Avec PolicyPak, vous pouvez bloquer l’exécution d’applications et de scripts si le propriétaire du fichier n’a pas été préalablement ajouté à la liste blanche.

Liste de contrôle pour la prévention de l'exécution de code à distance

1. Appliquez des correctifs aux logiciels exposés à internet selon un calendrier défini, en commençant par les plateformes CMS, les portails VPN et les API.
2. Validez et assainissez les entrées, et maintenez les entrées utilisateur éloignées des shells, modèles et désérialiseurs.
3. Exécutez les services avec le moindre privilège et supprimez les droits d’administrateur local là où ils ne sont pas nécessaires.
4. Surveillez les répertoires web, les fichiers critiques et les configurations pour les modifications non planifiées.
5. Bloquez l'exécution des applications et scripts non fiables sur les systèmes Windows.
6. Conservez un historique des modifications consultable pour que les enquêtes commencent par une chronologie.