Les alertes de sécurité de la semaine écoulée dévoilent une tendance majeure : l’exploitation de logiciels PHP populaires par le biais de l’inclusion de code à distance. La parade est pourtant très simple à mettre en oeuvre.
Les attaques contre des applications PHP populaires sont une manne bien connue pour les pirates. Elles leur permettent de prendre facilement le contrôle de serveurs à travers la planète afin de l’utiliser pour cracher du spam ou mener des attaques automatisées contre d’autres serveurs.

Et le bulletin d’alerte très officiel US-CERT pour la semaine écoulée est sans ambiguïté à ce sujet : la vaste majorité de ces attaques repose sur la possibilité, pour l’attaquant, d’inclure à distance un script PHP de son choix.

Ainsi, rien que pour la semaine dernière le CERT-US épingle les applications PHP suivantes, toutes vulnérables à une attaque par inclusion de code à distance :

Topsites PHP (Aardvark)

Picture-Engine (Alexscriptengine)

2Bgal (ben3w)

BT-Sondage

CodeBB

Le module « Forum picture and META tags » pour phpBB

Company Website Builder (GraFX Software)

Kaqoo Auction Software (Kaqoo)

MangoBery CMS

Exhibit Engine 2 (Photography-on-the-net)

Time-Assistant (Softerra)

Shop-Script (WebAsyst LLC)

MapLab

Rien que ça, et juste pour une semaine…

L’inclusion de code à distance est certes une fonction qui peut se révéler très pratique… lorsqu’elle est vraiment nécessaire ! Mais pour la vaste majorité des propriétaires de serveurs dédiés, cette fonction est inutile car les scripts PHP s’exécutent exclusivement localement. Mais l’inclusion de code étant activée par défaut dans PHP, elle le reste souvent à l’insu de l’administrateur peu regardant.

Il suffit pourtant de placer à off la directive allow_url_fopen dans la configuration de PHP pour ne plus être vulnérable à la majorité de ce type d’attaque (Mise à jour du 02/06/07 : les puristes objecteront que cela ne protège pas contre l’inclusion via php://input ou data://. Pour cela, l’utilisation d’un outil tiers tel Suoshin peut s’avérer utile).

Cependant la solution allow_url_fopen brille par sa simplicité : il est inutile de recompiler quoi que ce soit, un simple redémarrage d’Apache suffit.

Bien entendu, si une application (y compris parmi celles ci-dessus) exigent de pouvoir interpréter un script distant pour fonctionner, cette solution miracle ne fonctionne plus. Mais dans une telle circonstance, il convient peut-être de considérer l’idée de changer d’application plutôt que d’accepter un tel risque.

Enfin, pour aller plus loin – mais toujours aussi rapidement et simplement – dans la sécurisation de PHP, le projet +PHPsecinfo+ offre un outil rapide d’audit de la configuration de PHP sur un serveur, à la manière de la fonction phpinfo().

Outre la directive allow_url_fopen, PHPsecinfo examine dix-sept points de configuration susceptibles d’avoir un impact sur la sécurité du serveur. On pourrait le considérer comme le minimum syndical pour la horde d’apprentis administrateurs qui découvrent Linux grâce à un serveur dédié à bas prix et se le font détourner en 24h…