Pour information…
-------- Message original -------- Bonjour à toutes et à tous, L’analyse à posteriori des intrusions récentes dans des sites SPIP du CNRS ont montré qu’il était possible d’exploiter deux vulnérabilités de SPIP. La première vulnérabilité, que je signalais dans cette liste mercredi dernier, consiste à récupérer des informations dans le fichier meta_cache.txt et de les utiliser pour déposer un script PHP dans un sous répertoire de IMG. La seconde vulnérabilité consiste en une injection de code SQL dans le script spip_image.php3. La plupart des installations de SPIP ne sont pas vulnérables. Mais des choix de configuration d’Apache ou des mises à jour incomplètes peuvent avoir rendu votre site vulnérable. Dans le cas où l’accès à l’une des URL , , renvoie autre chose qu’une page d’erreur, alors votre site est vulnérable. La suite de ce document vous concerne et vous explique quelles mesures adopter. : les informations ci-dessous ne concernent que les sites SPIP installés sur un serveur Linux/Apache. Il n’y a pas eu d’analyse faite sur des configuration Windows/Apache ou Windows/IIS. Mais, étant donné le caractère « OS independant » des vulnérabilités décrites, il est fort probable que ces vulnérabilités soit aussi exploitables avec SPIP sous Windows. Le fichier meta_cache.txt contient des informations qui peuvent être utilisées pour contourner les mécanismes d’authentification de SPIP. Celui qui y a accès peut alors exécuter sans aucune authentification des opérations réservées à des auteurs SPIP. L’action qui a été utilisée dans deux cas d’intrusion sur des sites SPIP du CNRS est l’adjonction d’un script PHP dans un des sous répertoires de IMG. A priori, les installations récentes de SPIP ne devraient pas être vulnérables. En effet, SPIP installe dans le répertoire /tmp ou dans le répertoire /ecrire/data un fichier .htaccess contenant la directive « ». Malheureusement, dans des distributions comme Fedora 8 ou Centos 5.2, cette directive est ignorée car Apache est configuré par défaut avec un « AllowOverride none » qui inhibe le contenu des .htaccess. Il y a probablement d’autres distributions issues de la famille RedHat dans ce cas. Par ailleurs, ce fichier .htaccess peut avoir été, intentionnellement ou non, modifié ou supprimé postérieurement à l’installation de SPIP et le rendre ainsi vulnérable. D’où l’importance de vérifier si le contenu de ce fichier est accessible depuis l’extérieur ou pas. Dans mon message précédent, j’indiquais quelques pistes pour corriger ce problème. Je les rappelle ici, tout en les complétant. Notez que dans la directive Location, le nom du répertoire se termine désormais par un /. En effet, la directive « <Location /tmp> » s’applique à la fois à un répertoire « /tmp/ » et un répertoire « /tmpxyz ». Si le serveur est Apache et la version SPIP est 1.9.2g (meta_cache.txt est dans « /tmp »; pour des versions antérieures de SPIP remplacez « /tmp » par « /ecrire/data »), vous pouvez appliquer l’une ou l’autre des solutions suivantes : Les deux dernières solutions sont intéressantes car elles peuvent s’appliquer à toutes les instances de SPIP présentes ou à venir installées dans des VirtualHosts. Néanmoins, compte-tenu de la façon dont Apache gère l’ordonnancement des restrictions d’accès contenues dans les directives Location, Directory, DirectoryMatch, .htaccess, etc. il est plus prudent de vérifier sur chaque site que la directive globale n’a pas été masquée par une autre directive spécifique au VirtualHost. Dans ce cas, la directive sera à reporter dans le VirtualHost en question. Suite au message posté sur le sujet le 25 février dernier, on m’a signalé que le répertoire /config/ de SPIP devrait être protégé lui aussi, à l’instar de /tmp. En effet, le fichier /config/connect.php contient le mot de passe en clair d’accès à la base MySQL utilisée par SPIP. A priori, tant que le moteur PHP est opérationnel sur le site, tant qu’on n’a pas fait l’erreur de renommer le fichier connect.php en connect.sav, connect.bak (ou n’importe quel autre suffixe dont sont friands les administrateurs), le fichier connect.php n’est pas exposé. Par mesure de prudence, il est donc recommandé de protéger également le répertoire /config/ par l’une des méthodes décrite au paragraphe 1. : l’attaque décrite ci-dessous a été menée viua spip_image.php3. Il est probable qu’il existe des vulnérabilités similaires dans d’autres fichiers *.php3 contenus dans des distributions anciennes. Le script spip_image.php3 fait partie des anciennes versions de SPIP. Il est vulnérable à des injections de code SQL. Ce fichier, ainsi que tous ceux dont le suffixe est .php3 ne font plus partie des versions actuelles de SPIP et ne devraient pas exister. Malheureusement, le processus de mise à jour de SPIP n’efface pas totalement les scripts des anciennes versions. Ce script peut donc être présent, même sur des installations avec la toute dernière version de SPIP. Si vous utilisez une version récente de SPIP (1.9.2g ou 2.0), vérifiez que vous pouvez supprimer ce fichier, par exemple en faisant un « chmod 0 spip_image.php3 ». Idem pour tous les fichiers .php3 de SPIP. Pour d’anciennes versions, il est vivement conseillé de faire une mise à jour vers les versions plus récentes de SPIP et de vérifier que les fichiers .php3 ont disparu. Il est apparu que les deux vulnérabilités étaient exploitées dans le même but : récupérer une information, soit dans meta_cache.txt, soit dans la base de données SPIP, afin de lancer une requête POST sur spip.php qui a pour effet d’installer un script PHP dans un sous répertoire de IMG. Ce script permet au pirate d’exécuter n’importe quelle action sur le serveur avec les droits de l’utilisateur Apache. Les mises à jour de l’ensemble des instances de SPIP de votre serveur peuvent demander un délai important. Par ailleurs, le squelette SPIP de votre site peut faire référence aux scripts *.php3 de versions antérieures. La recommandation de mettre à jour et de supprimer les fichiers *.php3 est donc difficile à mettre en œuvre. Dans ces conditions, il est possible de se prémunir des conséquences des deux vulnérabilités ci-dessous par l’une ou l’autre des méthodes suivantes : Testez alors l’effet de cette modification en installant un script PHP dans le répertoire /IMG. Par exemple, créez le fichier /IMG/test-spip.php avec le contenu suivant : Depuis votre navigateur, accédez à . Selon la configuration d’Apache sur votre site, vous observerez soit une page vide, soit le code source ci-dessus, soit la valeur des variables d’environnement de votre serveur. Dans les deux premiers cas votre serveur est protégé. Dans le troisième cas, il ne l’est pas. Vérifiez la configuration. Bon courage. Roland.