En bref : lorsque PHP-FPM, Apache ou un autre processus de serveur web lance un shell comme sh ou bash, c'est l'un des signaux d'alerte les plus forts d'une intrusion via le site web. Vérifiez l'arbre des processus, la ligne de commande et le répertoire de travail du shell avant d'arrêter quoi que ce soit. Quelques shells brefs et isolés peuvent être légitimes ; des shells de longue durée avec des outils réseau ne le sont presque jamais.
Pourquoi ce schéma en dit autant
Un serveur web répond à des requêtes. PHP-FPM, le gestionnaire de processus qui exécute les scripts PHP pour le serveur web, ne lance normalement pas d'autres programmes pour cela. Un shell sous le serveur web signifie que du code PHP a délibérément appelé un programme. Soit l'application le fait à dessein, soit quelqu'un d'autre a injecté du code.
Pour PHP2Shell, il n'existe pas d'indicateurs de compromission (Indicators of Compromise) publiés et confirmés, donc pas de liste de signes de détection fixes. La détection repose sur le comportement. Selon les rapports dont nous disposons, les processus de serveur web ou de PHP-FPM qui lancent un shell comptent parmi les signaux d'alerte généraux les plus forts. Cela vaut pour toute faille par laquelle des attaquants exécutent du code sur le serveur. Un aperçu d'autres signes est donné par Suis-je déjà compromis ?.
Pourquoi le shell est-il si important pour un attaquant ? Avec une faille, il ne peut d'abord émettre que des commandes isolées via le processus PHP. Un shell en fait un poste de travail confortable : il peut regarder autour de lui, télécharger des outils, lire des identifiants dans des fichiers de configuration et s'installer durablement. Qui reconnaît le shell reconnaît donc souvent l'attaquant au moment même où il passe du premier accès au véritable projet.
PHP-FPM lance bash : lire l'arbre des processus
Chaque processus sous Linux a un processus parent. La question est de savoir si un shell tourne comme enfant d'un processus de serveur web. Les commandes suivantes ne font que lire :
# Arbre des processus avec utilisateur, PID parent et heure de démarrage
ps -eo user,pid,ppid,lstart,cmd --forest | grep -B2 -A4 -E "[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp"
# Shells qui tournent sous les utilisateurs typiques de serveur web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) " | grep -E "[ /](ba|da)?sh( |$)"
# Arbre à partir du plus ancien processus PHP-FPM
pstree -alp "$(pgrep -o php-fpm)"
Si vous avez trouvé un shell suspect, les entrées sous /proc fournissent d'autres indices, également en lecture seule :
PID=12345 # PID du shell suspect
tr '\0' ' ' < /proc/$PID/cmdline; echo # ligne de commande complète
ls -l /proc/$PID/cwd /proc/$PID/exe # répertoire de travail et fichier du programme
ls -l /proc/$PID/fd 2>/dev/null | grep socket # connexions réseau ouvertes
Les noms de processus sous Debian et Ubuntu sont souvent php8.3-fpm ou similaire ; adaptez les motifs de recherche. Des répertoires de travail dans /tmp, /dev/shm ou dans des répertoires de téléversement sont un signe net.
Exceptions légitimes et vrais signes d'alerte
Certaines applications appellent des programmes via PHP. Un shell peut alors apparaître brièvement, par exemple lorsque PHP transmet des courriels via sendmail_path ou qu'une application traite des images avec un outil externe. De tels shells ne vivent que quelques secondes et appellent toujours le même programme. Documentez une fois proprement ces cas attendus ; chaque écart se remarque alors immédiatement, au lieu de se perdre dans un flot de messages connus.
| Observation | Plutôt bénin si | Suspect si |
|---|---|---|
| Shell bref sous PHP-FPM | il lance un programme connu de l'application | la cible et l'objet sont flous |
| Shell de longue durée | jamais | il tourne pendant des minutes ou des heures |
| Outils réseau comme processus enfant | interrogation connue de mise à jour ou d'API de l'application | des téléchargements dans des répertoires temporaires suivent |
| Répertoire de travail | dossier de projet de l'application | /tmp, /dev/shm, répertoire de téléversement |
| Moment | correspond à une action connue, par ex. envoi de courriels | la nuit, sans activité d'utilisateur, de façon répétée |
Si vous ne savez pas si votre application appelle des programmes, demandez au développeur ou cherchez dans le code des fonctions comme exec, shell_exec, system, passthru, proc_open et popen. Des occurrences dans votre propre code sont normales, dans des fichiers inconnus non.
Surveiller durablement plutôt que regarder une fois
Un instantané avec ps n'attrape que les shells qui tournent à ce moment. Les processus éphémères passent à travers. Il est plus fiable de journaliser durablement les lancements de programmes par l'utilisateur du serveur web. Sous Linux, le service d'audit auditd s'en charge avec une règle pour les lancements de programmes de l'utilisateur du serveur web. L'exploitation se fait en lecture :
# Afficher les lancements de programmes journalisés sous une clé de règle (clé à titre d'exemple)
sudo ausearch -k web_exec --start today -i | grep -E "exe=|proctitle="
L'aspect de la règle dépend de la distribution et de l'ID utilisateur ; testez-la d'abord, car sur des serveurs très sollicités, de nombreuses entrées apparaissent.
Deux compléments rendent la surveillance fiable. Premièrement, les journaux devraient en plus aller vers un système central, car un attaquant disposant des droits root peut supprimer les journaux locaux. Deuxièmement, il faut une alerte : un lancement de programme par l'utilisateur du serveur web qui ne figure pas sur une courte liste de programmes attendus devrait déclencher une notification, pas seulement une entrée de journal. Qui utilise déjà une solution de détection sur les terminaux ou les serveurs peut y reproduire la même règle. À titre préventif, on peut bloquer avec disable_functions ce dont l'application n'a pas besoin. Cela ne ferme aucune faille dans l'interpréteur, mais complique la prochaine étape d'un attaquant. Les détails figurent sous Bien utiliser disable_functions.
Que faire si vous trouvez un shell sous le serveur web
- Documenter : sauvegarder dans un fichier hors du répertoire web la sortie de
ps, la ligne de commande, le répertoire de travail et les connexions ouvertes. - Ne pas nettoyer : ne supprimer aucun fichier et n'arrêter aucun processus avant que les traces soient sauvegardées.
- Isoler : déconnecter le serveur du réseau ou restreindre fortement l'accès.
- Chercher la cause : vérifier les journaux, les nouveaux fichiers et la persistance comme les tâches cron, voir Trouver les processus suspects sur les serveurs Linux.
- Changer les accès : tous les mots de passe et clés qui se trouvaient sur le serveur sont considérés comme connus.
Si l'application tourne dans des conteneurs, le même principe s'applique en petit. Un shell dans le conteneur PHP est aussi suspect que sur un serveur classique, et les images de conteneurs n'en contiennent souvent que parce que l'image de base l'apporte. Sauvegardez l'état du conteneur avant son redémarrage, car avec le conteneur disparaissent aussi les traces dans le système de fichiers éphémère.
Vérifiez en outre le voisinage. Un attaquant avec un shell sur un serveur web essaie souvent d'atteindre depuis là d'autres systèmes, par exemple la base de données, le stockage de sauvegarde ou des interfaces d'administration internes. Les identifiants dans les fichiers de configuration de l'application le lui facilitent.
Un shell de longue durée sous PHP-FPM sur un serveur contenant des données clients est un incident de sécurité. Traitez-le comme tel : sauvegarder, isoler, instruire de manière structurée, faire vérifier les obligations de notification.
Comment PHP SOS aide-t-il concrètement ?
- Situer le constat : nous examinons l'arbre des processus, les lignes de commande et les connexions et distinguons le comportement de l'application des traces d'intrusion.
- Sauvegarder les traces : nous sauvegardons l'état du système de façon traçable avant que quoi que ce soit ne soit modifié.
- Traiter l'incident : avec la réponse aux incidents, nous accompagnons de l'endiguement jusqu'à la clôture documentée.
- Sécuriser durablement : nous mettons en place la journalisation des lancements de programmes et limitons les fonctions PHP au nécessaire. Le fonctionnement interne de PHP-FPM est expliqué dans PHP-FPM expliqué.
Questions fréquentes
Tout shell sous PHP-FPM est-il une attaque ?
Pas tous. Certaines applications appellent délibérément des programmes via PHP, par exemple pour le traitement d'images ou l'envoi de courriels, et un shell peut alors apparaître brièvement. Cela devient suspect si le shell tourne plus longtemps, lance des outils réseau ou travaille depuis des répertoires inhabituels.
Dois-je arrêter immédiatement le processus suspect ?
D'abord documenter, ensuite agir. Consignez les données du processus, la ligne de commande, le répertoire de travail et les connexions réseau. Isolez ensuite le serveur. Un arrêt précipité détruit des traces et n'empêche pas l'attaquant de revenir.
Existe-t-il des signes de détection confirmés pour PHP2Shell ?
Non. Il n'existe pas d'indicateurs de compromission (Indicators of Compromise) publiés et confirmés. Des shells sous le serveur web sont un signal d'alerte général d'intrusions via des applications web, non spécifique à PHP2Shell.
Comment empêcher PHP de lancer des shells ?
Avec disable_functions, on peut bloquer des fonctions comme exec, shell_exec, system et proc_open si l'application n'en a pas besoin. Cela ne ferme aucune faille dans l'interpréteur PHP, mais rend l'exploitation plus difficile.