SRS Day – Conférence 17 novembre 2010 Par : Cyril Amar – amar_c Rémi Chaintron – chaint_r Romain Léonard – leonar_r Arthur Obriot – obriot_a Tom Pineau.

Présentation au sujet: "SRS Day – Conférence 17 novembre 2010 Par : Cyril Amar – amar_c Rémi Chaintron – chaint_r Romain Léonard – leonar_r Arthur Obriot – obriot_a Tom Pineau."— Transcription de la présentation:

1 SRS Day – Conférence 17 novembre 2010 Par : Cyril Amar – amar_c Rémi Chaintron – chaint_r Romain Léonard – leonar_r Arthur Obriot – obriot_a Tom Pineau – pineau_t Nicolas Stefanski

2 Sommaire  Introduction  Présentation  Typologie des attaques  Outils Externes  Recommandations  Conclusion 2 SRS Day @ EPITA - 17 novembre 2010

3 Introduction  Sites web de plus en plus complexes et dynamiques  De plus en plus d’implication des visiteurs (web 2.0)  De plus en plus de vulnérabilités…  … dont le Cross Site Scripting 3 SRS Day @ EPITA - 17 novembre 2010

4 Introduction « Le fait d'accéder ou de se maintenir, frauduleusement, dans tout ou partie d'un système de traitement automatisé de données est puni de deux ans d'emprisonnement et de 30000 euros d'amende. Lorsqu'il en est résulté soit la suppression ou la modification de données contenues dans le système, soit une altération du fonctionnement de ce système, la peine est de trois ans d'emprisonnement et de 45000 euros d'amende. » Article 323-1 du Code Pénal 4 SRS Day @ EPITA - 17 novembre 2010

5 Présentation  XSS, ou “Cross Site Scripting”:  Vulnérabilité Web la plus (mal) connue.  2ème au Top 10 OWASP en 2007 et 2010.  Concerne 80% des sites Web.  Permet d’injecter et exécuter du code non prévu sur un navigateur Web. « XSS is the new buffer overflow, JavaScript malware is the new shellcode » Jeremiah Grossman (XSS Attacks, 2007) SRS Day @ EPITA - 17 novembre 2010 5

6  Exemples:  4 Juillet 2010: Attaques par le biais de XSS permanent sur les commentaires de Youtube  21 Septembre 2010: Onmouseover Twitter Worm  4 Novembre 2010: Découverte d’une faille xss sur le site de la CIA Présentation SRS Day @ EPITA - 17 novembre 2010 6

7 Typologies des attaques  3 catégories d’attaques XSS  XSS réflectif  XSS persistant  XSS hybride  3 modes d’attaques, et de propagation SRS Day @ EPITA - 17 novembre 2010 7

8 Typologie des attaques > XSS réflectif  L’attaquant forge une URL, et la transmet à sa cible http://www.domain.tld/p.php?p= alert(1); ­­  Traitée par le serveur visé, cette URL retourne du Javascript malveillant  Exploitation simple, mais diffusion restreinte SRS Day @ EPITA - 17 novembre 2010 8

9 Typologie des attaques > XSS persistant  Détection des failles moins aisée  Diffusion large SRS Day @ EPITA - 17 novembre 2010 9  L’attaquant stocke du code malveillant sur le serveur  Les victimes sont infectées lorsqu’elles visionnent la ou les pages compromises

10 Typologie des attaques > XSS hybride SRS Day @ EPITA - 17 novembre 2010 10  L’attaquant forge une URL et la transmet à une cible, qui infecte le serveur  Fonctionnalité « Qui est en ligne ? »

11 Outils externes  BeEF  XSS Shell et XSS Tunnel  Xeek SRS Day @ EPITA - 17 novembre 2010 11

12 Outils externes SRS Day @ EPITA - 17 novembre 2010 12  Fonctionnement

13 BeEF – Browser Exploitation Framework  Framework d’exploitation de navigateur web  But: démontrer l’impact des failles XSS sur les navigateurs  Se présente sous la forme d’une interface web  Prérequis:  Un serveur principal hébergeant BeEF  Un site compromis avec une faille XSS  Une machine client envoyant les commandes au serveur SRS Day @ EPITA - 17 novembre 2010 13

14 BeEF – Browser Exploitation Framework  Fonctionne sous forme de modules (AlertDialog, RawJavascript, Detection de plugins …)  Possibilité de créer ses propres modules (javascript)  Gestionnaire de zombies journalisé  Connexion possible avec Metasploit SRS Day @ EPITA - 17 novembre 2010 14

15 BeEF – Browser Exploitation Framework AvantagesInconvénients Simplicité d’installationMauvaise gestion des botnets de plus de 100 zombies (principalement dû à l’utilisation du Javascript) Intégration avec MetasploitPas de sauvegarde en base de données Fusion avec XSS Shell et XSS Tunnel en prévision Nécessité de mettre en place un serveur web distant accessible depuis internet Interface graphiqueLes victimes ne restent pas infectées si elles changent de page Installation Multiplateforme: Windows, Linux et Mac OS Portable grâce à l’utilisation de PHP Possibilité de customisation (création de modules) SRS Day @ EPITA - 17 novembre 2010 15

16 XSS Shell et XSS Tunnel  XSS Shell  Alternative à BeEF  Application en 3 parties  Le serveur (IIS)  L’interface d’administration (IHM)  Le clients (ou zombies)  XSS Tunnel  Utilisation d’un zombie du shell comme proxy SRS Day @ EPITA - 17 novembre 2010 16

17 XSS Shell - Fonctionnement  Le serveur  Il centralise les connections des victimes et leur transfert les commandes  Il s’appuie sur un serveur IIS et une base de données Ms Access  L’interface d’administration  Elle permet l’envoie de commandes  Côté client  Un fichier javascript exécuter par le navigateur de la victime SRS Day @ EPITA - 17 novembre 2010 17 AvantagesInconvénients Interface graphiqueServeur IIS (=> pas portable) Base de données

18 XeeK - XSS Easy Exploitation Kernel  Framework d’exploitation de failles XSS (alternative a BeEF ou XSS Shell)  Projet récent (débuté en 2008), en cours de développement.  Développé par un français  A été créé dans le but de rajeunir les outils existants et vieillissants en cumulant leurs avantages  Développé en PHP/Python SRS Day @ EPITA - 17 novembre 2010 18

19 XeeK - XSS Easy Exploitation Kernel SRS Day @ EPITA - 17 novembre 2010 19 AvantagesInconvénients PortableProjet non terminé, développement lent (on doit se contenter de quelques exploits basics et d’une interface console). Base de données Architecture client/serveur Projet modulaire tant au niveau de l’interface client/serveur (ajout d’une interface graphique possible) que de l’ajout de nouveaux exploits. Exploits à jour, pour navigateurs récents.

20 Recommandations  Côté serveur  Ne jamais faire confiance aux utilisateurs  Ne pas oublier de filtrer les listes déroulantes  Filtrage  Htmlentities, verification des entiers  Filtrage par liste blanche  Maintenir les frameworks utilisés à jour  Pour des applications non maitrisées utiliser un relais inverse avec du filtrage applicatif (mod_security pour Apache par exemple) SRS Day @ EPITA - 17 novembre 2010 20

21 Recommandations  Côté client  Pour une utilisation normale  Vérifier la correspondance entre le site et son url  Vérifier les liens qui nous sont envoyés  Pour aller plus loin  Vérifier les connexions qu’effectuent les scripts avec d’autres sites (avec firebug par exemple)  Utiliser des plugins bloquant les scripts (NoScript par exemple pour Firefox)  Désactiver le javascript! SRS Day @ EPITA - 17 novembre 2010 21

22 Conclusion  Vulnérabilités XSS sous-estimées car exécution côté client  Exploitation entièrement automatisée  Impacts importants (vol d’informations au réseau de botnet)…  … et croissants, avec l’arrivée de l’HTML 5 SRS Day @ EPITA - 17 novembre 2010 22