SECURIDAY 2012 Pro Edition

Transcription

1 SECURINETS CLUB DE LA SECURITE INFORMATIQUE INSAT SECURIDAY 2012 Pro Edition [Nom de l atelier] Chef Atelier : Melek DRIDI (RT5) Sameh HAMDI (RT4) Slim BEN ABDERRAZEK(RT4) Fedi BOUKHROUF (RT4) Souad Manai (RT3) Fares BEN ABBES (RT4) Faten MKACHER (RT2) 30/04/2011

2 1) Présentation de l atelier : Cet atelier consiste à maitriser l audit en utilisant le guide OWASP qui est un projet open source communautaire mis en place pour développer des outils logiciels et la connaissance de la documentation pour la sécurité des applications Web, c est un guide aussi pour définir les exigences de sécurité pour construire des applications Web sécurisées. Il est important de noter que la norme étudiée est dédiée à la partie tests d'intrusion d'une application WEB. L'OWASP en propose d'autres comme un guide de développement et un guide de revue de code qui sont complémentaires au guide de tests en question. Le but de la méthode OWASP est de fournir un ensemble de techniques pour tester la sécurité des applications web. Cette méthode est destinée aux : Développeurs pour produire du code sécurisé. Testeurs d application pour avoir un ensemble de tests supplémentaires à effectuer. Expert sécurité pour vérifier si d autres vulnérabilités ne peuvent pas être découvertes avec cette méthode. Historique de l owasp Juillet 2004 => v1 : OWASP Web Application Penetration Checklist Décembre 2006 => v2 : OWASP Testing Guide v2.0 Novembre 2008 => v3 : OWASP Testing Guide v3.0 V4 en fin d année Type d attaques applicatives : 2

3 Présentation des outils utilisés : OWASP (Open Web Application Security Project) est une communauté travaillant sur la sécurité des applications Web. L'objectif principal de l'owasp est de produire des outils, documents et standards dédiés à la sécurité des applications Web. Les projets les plus connus sont les suivants : Top Ten OWASP : le but de ce projet est de fournir une liste des Dix Risques de Sécurité Applicatifs Web les Plus Critiques. WebGoat : il s'agit d'une plateforme de formation permettant à un utilisateur d'apprendre à exploiter les vulnérabilités les plus courantes sur une application Web. WebScarab : il s'agit d'un proxy disposant de nombreuses fonctionnalités utiles lors de la réalisation d'audits de sécurité. En plus de proposer à l'utilisateur de visualiser les requêtes échangées avec un serveur Web, il est possible de modifier ces requêtes, d'analyser les sessions ID, etc. Guide de tests : il s'agit d'un document de plusieurs centaines de pages destiné à aider une personne à évaluer le niveau de sécurité d'une application Web. Guide de revue de code : il s'agit d'un document de plusieurs centaines de pages présentant une méthode de revue de code sécurité 3

4 WebGoat(guide éducatif) Webgoat : le projet webgoat est hébergé sur le site de l owasp,ce projet a pour objectifs de fournir une application évolutive de formations aux techniques d attaques des sites web,son utilisation requiert de disposer d un serveur sur lequel est installé un serveur d application tomcat Des exercices guidés pour s entrainer avec les solutions. Voici quelques failles testées en utilisant WebGoat : SQL injection: C est une faille très répondue utilisée par un grand nombre de pirates informatiques avec de très mauvaises conséquences les deux principales raisons pour lesquelles cette faille est assez répondue sont : 1 l importance des données qu on peut utiliser se trouvant dans les base de données ce qui incite des pirates a utilisé cette 4

5 faille pour des raisons personnelles 2-le manque de sensibilisation des programmeurs qui laisses beaucoup de failles dans leur code lors de la création d une application Exemple 1 : String SQL Injection Dans cet exemple on veut se connecter sur le compte de l administrateur Neville sans utiliser le vrai mot de passe Démarche à suivre : Tout d abord il faut activer l altérateur de données (Tamper data) ou bien utiliser une interface telle que WebScarab ces deux outils permettent d intercepter les requêtes avant qu elles ne soient reçues par le serveur contenant la base de données en interceptant cette requête on peut alors modifier les champs dont on a besoin pour activer notre faille. La deuxième étape : 5

6 Il faut savoir qu une requête SQL est de la forme suivante Select * from salaries where userid= amine and password= salut ; Cette requête se traduit par sélectionner tout a partir de la base de donner qui s appelle salaries quand le user id est amine, en d autre terme sélectionner toutes les informations concernant la personne qui se nomme amine et dont le mot de passe est salut User id = amine renvoie un TRUE Password = salut renvoie TRUE TRUE AND TRUE = TRUE Donc dans le cas ou on n a pas le vrai password la requête renverra un false car TRUE and FALSE = FALSE Si on a pas le vrai mot de passe il faut juste forcer la requête a retourner un TRUE pour que les informations de l utilisateur soient affichés En utilisant l altérateur de données on va essayer d ouvrir donc la session de Neville sans utiliser le mot de passe 6

7 Ensuite en appuyant sur le bouton login la requête sera intercepté par l altérateur comme suit Notez bien que toutes les informations de la requête sont afficher et peuvent êtres modifier avant de les envoyer au serveur contenant la base de donnée. On va introduire dans le champ password un mot de passe qui retournera un TRUE et qui fera en sorte 7

8 que la session de Neville soit ouverte Les password qu on peut introduire par exemple est : x or 1 = 1 Quand le serveur va analyser la requête il va prendre tout d abord le password x donc il va retourner un FALSE car ce password n est pas le password exact puis il passera a 1=1 qui est toujours vrai ce qui fait que FALSE or TRUE renvoi TRUE Donc comme vu précédemment le résultat de la requête va renvoyer un TRUE and TRUE = TRUE D où l exécution de la requête et l ouverture de la session de Neville Exemple 2 : Modification de données dans une base de donnée 8

9 On veut faire en sorte de modifier la valeur du salaire de jsmith : On va juste envoyer une deuxième requête SQL a travers ce champ d affichage qui est vulnérable et jsmith';update salaries set salary=30000 where userid='jsmith dans cette requête on demande a afficher le salaire de jsmith et en utilisant la deuxième requête on demande a la base de données de changer la valeur de sont salaire par donc quand on affiche a nouveau la table salaries on aura comme résultat : Solutions pour contrer les failles du type SQL Injection : Pour éviter les failles du type sql injection on peut citer deux principales méthodes : 1) Les requêtes paramètres 2) Procédures stockées Pour plus d informations lire le guide owasp A retenir : Les failles SQL injection peuvent êtres utilisées que dans des 9

10 champs vulnérables Il faut avoir une connaissance en langage de requête SQL pour pouvoir utiliser cette faille La faille SQL injection est très dangereuse car elle peut affecter une base de données toute entière soit en modifiant ou en supprimant ou en ajoutant des données Faille : XSS 1) Problématique : Le faite de donner la confiance aux utilisateurs est un grand problème CAD si le webmaster n exige pas des filtres et des traitements sur les variables ou les données introduites par les utilisateurs par exemple dans les champs d un site, peut générer beaucoup de problème. Puisque un utilisateur malveillant peut introduire du code java script ou autre qui sera exécuté automatiquement. Pour ce fait on choisit ces petits exercices guidés sur le webgoat. 10

11 1.1) Définition bref du Faille XSS : Insertion de code (généralement JavaScript) dans une page pour en modifier le comportement dans le but de voler des informations, de faire des redirections. C'est basé sur du code exécuté coté client. 2) Etapes 2.1) Stage1 Stored XSS L'objectif de cette première étape est de vous montrer comment la saisie de code dans un champ et son enregistrement en base peuvent impacter les autres utilisateurs de l'application. Pour ce faire, s'authentifier sous le profil de Tom Cat (mot de passe "tom"), sélectionner son profil puis cliquer sur "View Profile". Pour accéder au formulaire de modification du profil, 11

12 ciquez sur "Edit Profile". Visiblement, le champ "Street" n'est pas protégé. On tape le code suivant <script>alert( U are welcome )</script> Le résultat sera : 12

13 2.2) Stage 2 Stored XSS Revisited A cette étape, on doit constater que le profil de "Bruce Mc Guirre" est "pré-chargé" avec une attaque de type XSS. Pour s'en rendre compte, on se connecte sous le profil de "David Giambi" (mot de passe "david"), on sélectionne le profil de "Bruce McGuirre", puis on click sur "View Profile". En consultant le code source: 13

14 Plus claire : 3) Comment se prémunir? Pour éviter que de telles failles ne se trouvent sur notre site il n y pas mille solutions: toujours s'assurer qu'aucun code Javascript frauduleux (c'est à dire que vous ne contrôlez pas) ne soit envoyé dans son état actif vers le navigateur du visiteur. Un état actif veut dire ici que le code javascript sera exécute sur le navigateur. Pour faire en sorte que le code Javascript ne s'exécute pas sur le navigateur, simplement remplacer tout les < et > par leurs équivalents HTML< et > Ainsi du code genre: <script>alert("salut je suis revenu!")</script> ne s'exécutera plus et s'affichera comme telle, si vous vérifiez dans le code source de cette page vous remarquerais qu'il est écrit sous la forme: 14

15 <script>alert("salut je suis revenu!")</script> Ainsi le concepteur de ce site a bien fait les choses, en PHP par exemple, le remplacement peut être fait avec la fonction preg_replace(). Il existe également une fonction PHP toute prête, htmlspecialchars(), qui permet de neutraliser toutes les balises HTML (y compris <script>) présentes dans une chaine passée. La protection d'un site contre ces failles se résume donc par une des doctrines de l'informatique : Never trust user input (ne faites jamais confiance aux données utilisateur) Access Control Flaws : Cette section est divisée en 4 parties. Au cours de ces parties on s intéressera aux failles lié au contrôle d accès. Using an Access Control Matrix : Dans un schéma de contrôle d accès basé sur le rôle (rolebased access control scheme), le rôle représente l ensemble des permissions et privilèges. Un utilisateur peut avoir un ou plusieurs rôles. Ce schéma est résumé en 2 points : la gestion des permissions et la fixation des rôles. La faille à exploiter est le fait d obtenir des 15

16 permissions non permise par defaut dans le role, ou, accéder à un rôle plus privilégier. Par exemple les ressources du manager ne sont accessibles que par l utilisateur *admin+. (voir cidessous le resultat de «Using Access Control Matrix) Bypass a Path Based Access Control Scheme : Dans ce cas, l utilisateur «webgoat» a un acces à tous les fichiers du repertoire lesson_plans/english. On essayera d accedes à des ressources non existant dans le repertoire. L exemple proposé est : tomcat/conf/tomcat-users.xml. Hierarchiquement, Pour remonter au repertoire tomcat ( dans lequel on a le repertoire conf) on doit faire 3 monter soit : /../../../../ Donc l acces au repertoire souhaité est possible en ajoutant conf/tomcat-users.xml au repertoire tomcat soit /../../../../conf/tomcat-users.xml. Il suffit alors d intercepter la requete avec le add-on Tamper Data. LAB Role-Based Access Control : Stage 1: Bypass Business Layer Access Control : L'objectif de cet exercice est de vous montrer comment bénéficier de droits plus élevés par rapport à 16

17 ceux initialement prévus pour un profil donné Pour ce faire, connectons-nous avec un profil "employee" (compte Tom par exemple, mot de passe "tom"). Interceptons le paramètre utilisé afin de supprimer un utilisateur à l'aide de Tamper Data. On modifie le paramètre «ViewProfile» par le paramètre "DeleteProfile" : Puis en envoie la requete avec le nouveau parametre : Stage 2: Add Business Layer Access Control : L'objectif de cet exercice est de modifier le code existant afin de mettre en place un "patch de sécurité" qui corrige la faille de vulnérabilité étudié au stage 1. # cd ~/WebGoat- 5.2/tomcat/webapps/WebGoat/JavaSource/org/owasp/webgoat/lesson 17

18 s/rolebasedaccesscontrol/ # vim RoleBasedAccessControl.java //***************CODE HERE************************* if(!isauthorized(s, userid, requestedactionname)) { } throw new UnauthorizedException(); //************************************************* On peut alors Enregistrer puis retenter de modifier les droits de suppression. Stage 3: Bypass Data Layer Access Control : L'objectif de cet exercice est de voir le profil d'une personne sans y être autorisé. Pour ce faire, il suffit de récupérer le numéro d'identifiant d'un administrateur (John Wayne, employee_id=111) puis de se connecter avec un profil non autorisé à consulter le compte d'un administrateur (par exemple Bruce McGuirre, mot de passe "bruce", profil "employee") : Vous accédez alors au profil de l'administrateur, sans que l'application ne vous y autorise : 18

19 Stage 4: Add Data Layer Access Control : L'objectif de cet exercice est de mettre en place un patch de sécurité afin d'empêcher l'opération réalisée au stage précédent. # ~/WebGoat- 5.2/tomcat/webapps/WebGoat/JavaSource/org/owasp/webgoat/lesson s/rolebasedaccesscontrol/rolebasedaccesscontrol.java # vim RoleBasedAccessControl.java Repérer la section "CODE HERE" puis y insérer le code suivant : //***************CODE HERE************************* if(!isauthorized(s, userid, requestedactionname)) { } throw new UnauthorizedException(); if(!action.isauthorizedforemployee(s, userid, employeeid)) { } throw new UnauthorizedException(); //************************************************* 19

20 Enregistrer le fichier puis répéter l'opération précédente afin de tester que le patch est effectif. Remote Admin Access : Notre but est d acceder à l interface WebGoat en tant qu admin, on effectue alors la modification ci-dessous dans la bare URL : On obtient alors l interface admin functions à partir de laquelle on peut consulter : Les User Information : Les Product Information : Conclusion Chaque 3ans il y a une nouvelle version, jusqu' à aujourd'hui il y a 3 versions. La 4éme version en fin d'année, elle va suivre la tendance de l'internet 2.0(AJAX..),(s'intéresser aux failles de l AJAX..). 20

21 NB : OWASP va travailler sur d'autres domaines autres que le web, mobile, développer des applications variées sécurisées (non seulement applications web) etc.. 21