Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Webhacking: les failles php Tuto by 0k4pix © 0k4pix@gmail.com http://0k4pix.nop

Webhacking: les failles php Tuto by 0k4pix © 0k4pix@gmail.com http://0k4pix.noprobz.be Création le 11avril 2006 Dernière modif. le 16 août 2006 Avant propos J'ai écrit ce tuto afin que les webmasters se rendent compte des risques qu'ils peuvent prendre en sécurisant mal leurs scripts. Beaucoup de webmasters ne sont pas au courant des techniques de hack qui pourraient leur être fatal. J'invite grandement les webmasters qui débutent à lire ce tuto et surtout de tester les différentes failles sur leurs scripts afin qu'ils n'aient pas de mauvaises surprises après le passage d'un petit c** qui défacerait leur site. Si vous trouvé une faille sur un site, soyez sympa, au lieu de tout défacer, pensez plutôt à envoyer un mail au webmaster pour lui expliquer son erreur. Si celui-ci est compréhensif, il vous remerciera. En aucun cas, je ne pourrais être tenu responsable de vos actes après la lecture de ce tuto. Que chaque un assume ce qu'il fait :) Sachez aussi que vous risquez de lourdes peines lors de l'intrusion et/ou la destruction d'un système. Ne vous croyez pas invulnérable derrière votre pc, la plupart de vos actions, votre ip... sont loguées afin de vous identifier en cas de problème. Si on veut vraiment vous retrouvez, on vous trouvera... Dans ce tuto je vous parlerais de tout ce qui tourne autour des failles php, de leurs exploitation et bien sûr leurs sécurisations. Je vais essayer de faire un tuto le plus complet possible (c-a-d ne pas s'arrêter à la faille de base, mais montrer leurs autres exploitations bien plus hostiles). Bien évidemment, il existe des failles en abondance, c'est pourquoi je ne m'atarderais que sur les plus connues. Pour les gens de mauvaise langue, qui passent leur temps à critiquer les tutos des autres, je leur dirais qu'il n'y a pas 15 façons de cuire un oeuf et donc que ce tuto ressemblera à beaucoup d'autre tuto, et sans pour autant avoir été copié. Et que si il n'aime pas mon travail, ils sont libre de ne pas le lire. Le tuto se déroulera comme ceci: - Explication théorique d'une faille Copyright 0k4pix 1 - Exploitation de la faille - Protection de la faille Le serveur de test est un serveur Apache (php 5.0.4) – MYSQL (4.1.12) tournant sur Win2000 Server. Directives php spécialles: register_global ON, magic_quotes ON, display_errors ON E_ALL, file_uploads ON, safe_mode OFF. Codes des couleurs: - en vert les commentaires - en rouge les entrées ou sorties des scripts - en bleu les instructions de bases (php/mysql) - en gras pour attirer l'attention Pour commencer, il ne faut pas forcément être un acharné du php/mysql pour suivre ce tuto, mais quelques notions sont quand même requises (html, javascript, php (forcement) avec SQL, batch). En cas de doute, d'incompréhension, n'hésitez pas à aller jeter un oeil sur www.phpdebutant.org ou sur www.google.com. Pour suivre corrrectement ce cours, il est préférable de télécharger cette archive (24.6Mo) : Celle-ci contient des petits utilitaires que nous utiliserons, mais également des scripts de test. Lien Bonne lecture. Table des matières 0) Introduction 1) Récupérer des infos 2) Filtres 3) Forcer les variables 4) XSS 1. non-permanent 2. permanent 5) Injection SQL 1. Injection de base (avec magic_quote off) 2. Utilisation des commentaires 3. UNION 4. OUTFILE 5. UPDATE 6. LIMIT magic_quote on 7. NULL Authentification 6) Include 1. Include à distance 2. Les backdoor shell 3. Netcat 4. Backdoor permanente 5. Include local et .htaccess 6. Les fichiers des clients ftp 7. NULL Byte 7) Upload 1. Double extension Copyright 0k4pix 2 2. Bypass mime vérification 3. Sélection du répertoire de destination 8) CSRF 9) Les Sessions 1. Prédiction 2. Capture 3. Fixation 4. Directory Listing 10)Conclusion 11) Références 12) Greetz 13) Copyright 0) Introduction Les services de forums, livre d'or, espace admin ... utilisent des scripts dans des langages évolués qui s'exécutent du côté serveur (languages interpretés). C'est-à-dire que, contrairement aux javascripts qui sont côté client, ces derniers s'exécutent sur le site que vous visitez. Vous ne recevez jamais que le résultat en html lorsque vous visitez une page php, asp, cgi... C'est pour ça qu'on ne peut pas lire la source php (sinon ce serait trop facile). Les failles php s'exploitent sur des erreurs de programmation due à l'inattention ou la méconnaissance du programmeur mais également dans certaines fonctions php. Beaucoup de webmasters vont coder leurs scripts, les tester et s'ils fonctionnent, ne se soucieront pas des risques qu'ils peuvent prendre. Par exemple, en ne filtrant pas les variables car la plupart des failles viennent du fait qu'elles ne sont pas filtrées (ou pas correctement). Durant tout le tuto nous nous servirons des erreurs éventuelles renvoyées par l'interpréteur php (à savoir que celle- ci ne sont pas forcement affichées, voir directive display_error dans le php.ini). 1) Récupérer des infos Avant de directement nous lancer sur une cible, il est important d'analyser au maximum celle-ci. Par exemple la version php utilisée, la version apache, les configurations du serveur... Déjà récupérer l'ip du serveur. Dans dos: ping -a victime.com On récupère l'ip (216.239.59.104). Des infos sur le serveur apache: Dans dos: telnet >> open victime.com 80 Ensuite taper HEAD \index.php HTTP 1.1 puis 2fois enter. Copyright 0k4pix 3 Voilà, on a la version apache qui tourne sur un serveur Windows, et on a également la version de php. (A savoir que ces informations ne sont pas forcément dévoilées). Grâce au phpinfo, on peut déjà savoir si certaines directives sont activées ou non (comme les magic_quotes, l'upload de fichier, register_globals...). Ces renseignements sont enregistrés dans le php.ini. Une version consultable peut être visualisée suivant les hébergeurs (ou forcer l'affichage par <?php phpinfo(); ?>). Une info qui serait pas mal, ce serait de déterminer le chemin du répertoire web sur le serveur. On peut provoquer des erreurs pour faire afficher le path en modifiant des variables. Exemple (pris au hasard sur internet): Warning: imagejpeg(): Unable to open 'files/thumbs/tse.jpg' for writing in /data/members/free/fr/f/o/r/votreforum/htdocs/attach_mod/includes/functions_thumbs.php on line 203 Et bien on en sait désormais un peu plus sur l'arborescence du serveur. Cette "faille" s'appele Faille path disclosure. Et les failles, où les chercher? Et bien déjà, visionnez les sources du site, on y trouve beaucoup d'infos (les hiddens, les posts, les url, les cookies...) qui nous mettrons sur une voie afin de savoir quelle faille faille tester. 2) Les filtres Le but d'un filtre va être de filtrer la variable (sans déconner :p). Généralement, ils vont convertir leurs entrées par leurs équivalents ascii et interdire ou modifier certains de celle-ci par mesure de sécurité. Il existe différents types de filtres: a) Les fonctions php Il existe plusieurs fonctions qui filtrent les variables, les plus connues sont: htmlentities(), htmlspecialchars(), addslashes(), strip_tags() ... Ces fonctions ne peuvent pas être bypasser, mais heureusement pour nous et malheureusement pour les webmasters, la fonction str_replace() peut l'être. Imaginons le code suivant: $var=str_replace("<script>","",$var); //Ceci est une fausse sécurité La fonction str_replace() est case sensitive, c-à-d qu'elle tient compte des majuscules et des espaces. Donc si on envoie: <Script>alert("hack")</script >, le str_replace() ne servira a rien :) On peut également envoyé <sc<script>ript>alert("hack")</sc<script>ript> Copyright 0k4pix 4 Le str_replace() va effacer le mot <script> ce qui nous donnera: <script>alert("hack")</script> ce qui bypass encore la protection. Autre cas: $var=str_replace("<script>","<script>",$var); //plus proche de la réalité Ici le caractère interdit va être remplacé par son équivalant html. Mais on peut bypasser ça si on envoie: <script/*<script>*/>alert("hack")</script> (attention à ne pas couper le mot SCRIPT, mettez les commentaires directement avant ou après les < >) <script> va être remplacé, mais on l'a mit en commentaire. Ce qui donne: <script/*<script>*/>alert("hack")</script>. Protection: $dede=str_replace("<","<",$dede); $dede=str_replace(">",">",$dede); Dans ce cas, on ne saurait pas échapper au remplacement des caractères < et > par leurs équivalents html. Mais le mieux et le plus sûr est d'utiliser les fonction php comme htmlentities() ou encore htmlspecialchars(). b) Le filtre javascript J'en vois déjà qui vont sourire mais il y a de quoi. Certains webmasters créent leurs filtres en javascript. Ils testent leurs filtres, et en effet ils fonctionnent comme il le souhaite. Seulement voilà, on peut très bien recréer le formulaire sur notre machine en enlevant la vérification du javascript (ou tout simplement en désactivant le javascript dans le browser web). Protection: Le javascript doit être banni pour la vérification des entrées. Rien ne vous empêche de faire une petite alerte pour prévenir l'utilisateur pour une meilleure convivialité mais en aucun cas ne faites les vérifications avec les du javascript. c) La configurations du php.ini Certaines configurations peuvent (théoriquement) bloquer/sécuriser certaines entrées. ● magic_quotes remplacera les quotes dans les requêtes envoyées par des \' ● display_errors affichera les erreurs dans les scripts ● file_uploads permettra l'upload de fichier sur le serveur ● safe_mode est le mode de sécurité de PHP plus d'info: http://webdocs.math.univ- rennes1.fr/php/fr/features.safe-mode.htm ● register_globals acceptera toute créations de variable en get ou post. ● ... d) Les différents codages Tous les caractères peuvent s'écrire avec des codages différents et suivant certains filtres, certains codages passent et d'autre non. Voici les codages les plus courament utilisés. Encoding Type Encoded uploads/Litterature/ french-web-hacking.pdf