®️RCE

RCE : Remote Code Execution

Une faille RCE (Remote Code Execution) permet à un attaquant de faire exécuter du code ou des commandes sur le serveur cible, à distance, via une application vulnérable. C’est l’une des vulnérabilités les plus critiques : si elle est exploitable, l’attaquant peut souvent prendre le contrôle complet de la machine.

Qu’est-ce qu’une RCE ?

Une RCE se produit lorsque des données contrôlées par l’utilisateur sont injectées dans une partie du code qui exécute :

• des commandes système (system, exec, shell_exec, popen, os.system, etc.) ;

• du code applicatif (eval, assert, moteurs de templates, interpréteurs…) ;

• des objets désérialisés (PHP, Java, Python, etc.) avec un mécanisme vulnérable.

En résumé : l’application utilise des entrées utilisateur là où seul du code de confiance devrait être exécuté.

Fonctionnement d’une attaque RCE

1. Entrée utilisateur mal contrôlée L’application récupère une donnée depuis l’utilisateur (paramètre GET/POST, header, champ de formulaire, upload…) et l’intègre dans une commande ou un bloc de code.

2. Injection dans une fonction dangereuse Cette donnée est utilisée dans une fonction de type :

   • exécution système : system(), exec(), shell_exec(), os.system(), subprocess mal utilisé…

   • exécution de code : eval(), assert() en PHP, template injection, etc.

3. Exécution de commandes / code arbitraire L’attaquant construit une charge malveillante (payload) pour :

   • exécuter une commande système (whoami, id, ls, cat /etc/passwd, etc.) ;

   • déposer un webshell ou un script malveillant ;

   • installer un backdoor, pivot, ou lancer d’autres attaques (ransomware, exfiltration).

---

Conséquences d’une RCE

• Compromission complète du serveur Exécution de commandes avec les droits de l’utilisateur du service (souvent www-data, apache, nginx, parfois plus).

• Accès / exfiltration de données sensibles Lecture de fichiers, dumps de bases de données, secrets, credentials…

• Mouvement latéral Utiliser le serveur comme point d’appui pour attaquer d’autres machines internes.

• Déploiement de malware / ransomware Téléchargement et exécution de binaires malveillants.

• Persistance Ajout de backdoors, modification de scripts, tâches planifiées, etc.

C’est donc une vulnérabilité critique, souvent classée en CVSS élevé.

---

Exemple d’attaque RCE – code vulnérable (PHP)

1. Command Injection via system()

<?php
  // Script ping vulnérable
  $ip = $_GET['ip'];                // ex : ?ip=8.8.8.8
  system("ping -c 4 " . $ip);
?>

Un attaquant peut envoyer :

?ip=8.8.8.8;id

La commande réelle devient :

ping -c 4 8.8.8.8;id

→ la commande id sera exécutée sur le serveur.

---

Exemple sécurisé (simplifié)

1. Restreindre strictement l’entrée

Plutôt que d’exécuter une commande système, valider l’IP et limiter fortement ce qui est possible :

<?php
  $ip = $_GET['ip'] ?? '';

  // Vérifier que l'IP est valide
  if (filter_var($ip, FILTER_VALIDATE_IP)) {
      // Utiliser des fonctions sécurisées, sans concatenation libre
      $commande = escapeshellcmd("ping -c 4 " . escapeshellarg($ip));
      system($commande);
  } else {
      echo "IP invalide.";
  }
?>

Encore mieux : ne pas appeler du tout de commandes système depuis du code web si tu peux faire autrement (librairie interne, API, etc.).

---

Principales sources de RCE

• Command Injection Paramètres injectés dans :

  • system, exec, shell_exec, popen, os.system, subprocess mal configuré…

• Utilisation de eval / assert / moteurs de templates

  • Exécution de code à partir de chaînes construites dynamiquement.

  • Template engines mal configurés (SSTI : Server-Side Template Injection).

• Désérialisation non sécurisée

  • Désérialisation d’objets non fiables pouvant déclencher des gadgets d’exécution.

• Librairies / frameworks vulnérables

  • Vulnérabilités RCE dans des composants tiers (frameworks, plugins, libs, etc.).

---

Prévention des RCE

1. Ne jamais exécuter directement des entrées utilisateur

• Éviter autant que possible :

  • system, exec, shell_exec, popen, eval, assert, etc.

• Si tu dois appeler une commande système :

  • utiliser des wrappers / API de plus haut niveau ;

  • ne jamais concaténer directement des chaînes venant de l’utilisateur.

2. Validation stricte des entrées

• Valider type, format et plage de valeurs :

  • IP → filter_var

  • integer → cast (int)

  • choix utilisateur → liste blanche (in_array, enums…).

• Refuser tout caractère non attendu : ;, &, |, backticks, $(), etc., si applicable.

3. Utiliser des listes blanches (whitelist)

• Préférer des options prédéfinies à des valeurs libres :

  • Ex : action=ping_google, action=ping_dns plutôt que ip=….

• Mapper ensuite ces choix vers des commandes côté serveur (sans paramètre libre).

4. Principe du moindre privilège

• L’utilisateur du serveur Web doit avoir des droits minimaux :

  • pas d’accès root,

  • pas de droits d’écriture inutiles sur le système de fichiers,

  • pas d’accès direct à des répertoires sensibles.

5. Durcissement & supervision

• Journaliser les erreurs et commandes suspectes.

• Surveiller les comportements anormaux :

  • connexions sortantes inhabituelles,

  • exécution de commandes systèmes non prévues,

  • création de fichiers / webshells dans les répertoires Web.

6. Mise à jour des composants

• Maintenir à jour :

  • frameworks,

  • librairies,

  • extensions,

  • plugins, car beaucoup de RCE viennent de vulnérabilités dans des composants tiers (CVE).

Pratiques recommandées

• Revue de code ciblée : rechercher l’usage des fonctions dangereuses (system, exec, eval, assert, popen, etc.) et vérifier les entrées associées.

• Tests de sécurité :

  • Pentests applicatifs (tests manuels de command injection / RCE),

  • Scanners SAST/DAST pour repérer les patterns dangereux.

• Formation des développeurs :

  • Sensibiliser aux risques d’exécution de commandes / code,

  • Diffuser des bonnes pratiques (validation, whitelists, usage de librairies sûres).