Imaginez un manoir doté d'un système de sécurité haut de gamme. Caméras, détecteurs, portes blindées. Chaque visiteur fait l'objet d'un contrôle rigoureux.
Cependant, les livraisons de provisions pour la cuisine s'effectuent par l'entrée de service. Les agents de sécurité surveillent la grille principale, tandis qu'un fournisseur de confiance remet directement les colis au cuisinier.
Un jour, le contenu d'un carton ne correspond pas à ce qui est indiqué sur l'étiquette.
Le problème ne vient même pas d'une défaillance de la sécurité. C'est simplement que personne n'a vérifié les modalités de transmission entre deux acteurs de confiance du système.
Dans l'infrastructure web, une situation similaire se produit à la frontière entre NGINX et PHP-FPM.
Le serveur web reçoit la requête externe, puis transmet les données nécessaires à l'interpréteur PHP via le protocole FastCGI. En temps normal, ce mécanisme fonctionne de manière fiable. Toutefois, des erreurs de configuration ou des failles dans le traitement des données peuvent transformer cette interface interne en vecteur d'attaque.
Dès lors, une question cruciale se pose : que faire lorsque le problème ne provient pas du code du site, mais du mécanisme qui exécute ce code ?
Quand la protection du site ne protège pas l'interpréteur lui-même
NGINX traite les requêtes HTTP, détermine le parcours d'exécution et achemine les requêtes PHP vers le gestionnaire approprié.
PHP-FPM gère quant à lui les processus de travail PHP qui exécutent les scripts côté serveur.
Le protocole FastCGI fait office d'intermédiaire entre eux pour transmettre les paramètres de requêtes, les variables d'environnement et les données.
Cette architecture expose à plusieurs catégories de menaces bien distinctes :
- Erreurs de routage des requêtes vers les scripts PHP.
- Transmission non sécurisée des paramètres FastCGI.
- Interface réseau PHP-FPM non protégée.
- Vulnérabilités liées à la mémoire dans certaines versions de PHP.
- Erreurs applicatives permettant l'exécution d'opérations non autorisées.
Il ne faut pas confondre ces éléments. Une valeur PATH_INFO erronée n'entraîne pas automatiquement un dépassement de mémoire (buffer overflow), tout comme un accès à FastCGI ne garantit pas une exécution de code à distance. Néanmoins, dans certaines conditions, les conséquences peuvent s'avérer critiques.
Cas réel : CVE-2019-11043
En octobre 2019, la vulnérabilité CVE-2019-11043 a été rendue publique.
Elle concernait certaines versions de PHP 7 ainsi que des configurations NGINX associées à PHP-FPM. Une anomalie dans le traitement de PATH_INFO pouvait provoquer une corruption de la mémoire du processus et, ultimement, mener à une exécution de code à distance.
Plusieurs facteurs devaient être réunis : une version vulnérable de PHP, un mode de traitement spécifique du chemin de la requête, et l'absence des vérifications requises concernant l'existence effective du fichier PHP.
Le correctif a été apporté dans les versions PHP 7.1.33, 7.2.24 et 7.3.11.
Il s'agit d'un cas d'école majeur : même si les développeurs ont veillé à prévenir les injections SQL et gèrent prudemment les téléchargements de fichiers, une défaillance au niveau du gestionnaire serveur peut engendrer une faille d'attaque autonome.
Toutefois, il serait erroné d'appliquer le scénario de la CVE-2019-11043 à n'importe quelle installation moderne de PHP-FPM.
Pourquoi les attaquants s'intéressent-ils à la mémoire vive ?
Lors de l'exploitation de certaines vulnérabilités, l'attaquant cherche à modifier le comportement d'un processus en cours d'exécution, sans déposer de fichier malveillant persistant dans l'arborescence du site.
Cette approche complexifie la détection par les outils de surveillance axés exclusivement sur les modifications de fichiers.
Cependant, parler d'"attaque sans traces" est trompeur.
Même en l'absence de fichier malveillant inscrit sur le disque, des indices subsistent souvent dans la télémétrie réseau, les journaux de proxy, les événements de processus, l'audit système et la mémoire.
L'absence de nouveau fichier PHP ne prouve pas qu'aucune attaque n'a eu lieu. De même, l'absence de lignes suspectes dans un fichier access.log standard ne constitue en rien une garantie de sécurité.
Pour les experts, il est impératif de distinguer trois notions :
Corruption de mémoire (Memory corruption). Une anomalie d'accès à la mémoire susceptible de perturber le fonctionnement du processus et, sous certaines conditions, de conférer le contrôle à l'attaquant.
Injection de configuration FastCGI (FastCGI configuration injection). Le risque de modifier le comportement de PHP via une interface ou des paramètres de configuration mal protégés.
Exécution sans fichier (Fileless execution). La réalisation d'actions malveillantes sans recourir au stockage traditionnel d'un exécutable sur le disque.
Ces mécanismes peuvent apparaître dans différentes attaques, mais ne forment pas une chaîne obligatoire unique.
Comment sécuriser la liaison NGINX + PHP-FPM
Première règle : maintenir à jour PHP et ses composants associés. Aucune configuration de serveur web ne saurait remplacer la correction d'une faille connue.
Deuxième règle : restreindre l'accès à PHP-FPM. Le socket FastCGI ne doit être accessible qu'aux processus qui en ont strictement besoin. Si une communication TCP est utilisée, l'interface ne doit pas être exposée inutilement sur Internet.
Troisième règle : valider le routage des requêtes PHP. NGINX ne doit pas transmettre de chemins arbitraires inexistants au gestionnaire PHP. Des règles spécifiques doivent être définies en accord avec l'architecture de l'application, en particulier si celle-ci exploite PATH_INFO.
Quatrième règle : isoler les applications. L'utilisation de comptes utilisateur distincts, de privilèges d'écriture restreints, d'un accès minimal aux données sensibles et du cloisonnement des services permet de limiter l'impact d'une compromission.
Cinquième règle : surveiller les connexions sortantes. Un serveur peut avoir besoin d'accéder à des API externes, des passerelles de paiement ou des serveurs de messagerie. Une politique réseau rigoureuse doit donc cibler les flux autorisés, plutôt que de bloquer tout trafic sortant aveuglément.
Sixième règle : exploiter les mécanismes de durcissement du système. Les restrictions via systemd, seccomp, AppArmor ou SELinux réduisent les capacités d'un processus compromis. Leur déploiement doit toutefois faire l'objet de tests de compatibilité préalable, au lieu d'une simple duplication de directives génériques.
Enfin, la journalisation et la supervision doivent s'étendre au-delà de l'application PHP elle-même. Si un attaquant parvient à prendre le contrôle d'un processus de travail, il ne faut plus se fier uniquement aux journaux de l'application.
Pourquoi le WAF ne suffit pas
Les solutions WAF (Web Application Firewall), telles que Cloudflare WAF, demeurent des outils de protection précieux.
Elles permettent de bloquer de nombreuses attaques courantes, les requêtes suspectes ainsi que l'activité automatisée.
Cependant, un WAF ne corrige pas un interpréteur PHP vulnérable, ne remplace pas une configuration FastCGI sécurisée et ne garantit pas la détection de méthodes d'exploitation inédites.
Par conséquent, la sécurité d'un système repose non pas sur un produit unique, mais sur la combinaison de mises à jour régulières, d'une architecture saine, du principe du moindre privilège et d'une observabilité accrue.
Le dernier rempart
L'erreur la plus périlleuse pour un administrateur consiste à assimiler l'absence d'alertes à une absence de problèmes.
Le site web peut paraître parfaitement fonctionnel. La base de données continue de répondre. Les visiteurs ne constatent rien d'anormal.
Néanmoins, si un processus serveur a acquis des privilèges qui ne lui étaient pas destinés, les répercussions peuvent se manifester bien plus tard.
La véritable sécurité commence là où même un composant compromis se voit refuser le contrôle de l'ensemble du système.
C'est pourquoi il est primordial de protéger non seulement les entrées principales du manoir numérique, mais aussi les passages de service situés entre ses mécanismes internes.
Sources techniques
- CVE-2019-11043, notice CVE : https://www.cve.org/CVERecord?id=CVE-2019-11043
- Documentation PHP-FPM : https://www.php.net/manual/en/install.fpm.configuration.php
- Documentation systemd.exec : https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
- Analyse technique de Qualys : https://blog.qualys.com/product-tech/2019/10/30/php-remote-code-execution-vulnerability-cve-2019-11043