Vu sur la liste utilisateurs : http://permalink.gmane.org/gmane.comp.web.spip.user/140928
-------- Message original --------
Sujet : [Fwd: Une autre vulnérabilité de SPIP exploitée]
Pour : spip-rezo rezo <spip@rezo.net>
Forum : gmane.comp.web.spip.user
Pour information...
-------- Message original --------
Sujet : Une autre vulnérabilité de SPIP exploitée
Pour : plume-spip@services.cnrs.fr
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
http://votre.site/tmp/meta_cache.txt,
http://votre.site/ecrire/data/meta_cache.txt,
http://votre.site/spip_image.php 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.
_*Note*_ : 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.
_*1. Vulnérabilité induite par l'accès au fichier meta_cache.txt*_
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
"Deny from all".
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 :
* rajoutez un fichier .htaccess dans le répertoire
/var/www/html/.../tmp contenant "deny from all". Vérifiez que ce
..htaccess n'est pas inhibé par une directive "AllowOverride None"
d'Apache.
* rajoutez dans la config d'Apache les directives ci-dessous dans la
section correspondant à SPIP (redémarrage de Apache nécessaire).
Notez que cette solution ne s'applique pas si le système de
fichiers est, comme Windows, insensible à la casse, car la
directive va s''appliquer à /tmp/ mais pas à /tMp/.
<Location /tmp/>
deny from all
</Location>
* rajoutez dans la configuration d'Apache, dans la section
principale les lignes ci-dessous inspirées de la solution mise en
place à la DR de Marseille (redémarrage d'Apache nécessaire)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^/tmp/ / [NC,G,L]
</IfModule>
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.
_*2. Faut-il protéger le répertoire /config/ de SPIP 1.9.2g ?*_
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.
_*3. Vulnérabilité du script spip_image.php3*_
_*Note*_ : 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.
_*4. Une parade commune aux deux problèmes ?*_
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 :
* installer dans le répertoire /IMG un ficher .htaccess contenant la
directive suivante :
RemoveHandler .php .php3 .cgi .pl .py
* Rajouter dans la section globale du fichier httpd.conf d'Apache
les directives suivantes (redémarrage d'Apache nécessaire)
<Location /IMG/>
RemoveHandler .php .php3 .cgi .pl .py
</Location>
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 :
<?php
Header('Content-Type: text/plain');
print_r($_SERVER);
?>
Depuis votre navigateur, accédez à http://votre.site/IMG/test-spip.php.
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.