Attaques sur les applications web Pourquoi un firewall et un antivirus ne suffisent plus …

1. CertificatN°1994-/2759h Accréditation N° 1-1528 Section Laboratoires Portée sur www.cofrac.fr SGDN-DCSSI Attaques sur les applications webPourquoi un firewall et un antivirus ne suffisent plus … OSSIR BRETAGNE le 08/03/2008 Emilien LE JAMTEL

2. Sommaire • Présentation des intervenants • Objectifs de la présentation • Définition de l’application Web métier • Historique et évolutions des attaques (Pourquoi ?) • D’où proviennent ces attaques (Qui ?) • Vecteurs et méthodes d’attaques (Comment ?) • Conclusion

3. Présentation des intervenants • Emilien LE JAMTEL • Consultant expert en sécurité des systèmes d’informations • 3 ans d’expérience • Spécialiste en : • Tests d’intrusion • Audit de configuration • Audit d’architectures sécurisées • …

4. Objectifs • Répondre concrètement à plusieurs questions : • Quelles menaces liées aux applications Web métier ? • Quelles conséquences de ces menaces sur l’entreprise ? • Pourquoi la plupart des mesures actuelles ne suffisent pas ? • Quelles sont les causes de ces menaces ? • Que mettre en place pour s’en protéger ?

5. Applications Web métier – Définition (1) • Applications accédées en réseau au moyen d’un client léger (Web) • Pour tout type de structure • PME/PMI, Grandes entreprises, service public... • Service fourni • Externe • Commerce en ligne • Catalogue de produits • Banque en ligne (Virements, consultation…) • Webmail • … • Interne : Accès aux ressources internes de l'entreprise • Annuaire • Référentiel de documents (commercial, technique…) • Plannings • … Importance grandissante !

6. Applications Web métier - Définition (2) • Avantages • pas d’installation préalable (client léger), ni maintenance • accès depuis partout, via Internet (appli. externes) • Web-isation de « vieilles » applications (Web Services) • Technologies utilisées • Langages : HTML, Javascript, PHP/ASP/CGI, Perl, Java, ActiveX… • Base de Données : MySQL, Oracle, MS-SQL Server, Sybase… • Serveurs d'applications : Tomcat, Websphere… • Serveurs Web : IIS, Apache… • Systèmes d’exploitation : Windows, Linux, UNIX...

7. Menace 1 Vulnérabilité 3 Attaque Vulnérabilité 1 Menace 2 Vulnérabilité 2 Définitions • Vulnérabilité, Menace, Attaque

8. « Pourquoi ? »

9. Historique – Évolution des attaques (1) • Depuis quelques années (globalement) • Meilleure prise en compte des recommandations sur la sécurité périmétrique • Firewall, cloisonnement (VLANs, DMZ), passerelles (reverse proxy…) • Serveurs et appliances publics : plus ou moins configurés, minimisés  Attaques plus difficiles à mettre en œuvre à ce niveau • Évolution des attaques • Montée dans les couches du modèle OSI • Pour passer les défenses périmétriques (firewalls...) • Ports applicatifs : HTTP/HTTPS, Microsoft SMB, FTP... • A la fois • Directement, par les serveurs applicatifs et les applications métiers • Indirectement, via les postes utilisateurs

10. Historique – Évolution des attaques (2) • Intérêts (1) • Flux autorisés vers les serveurs • Flux plus ou moins surveillés • Les machines des utilisateurs internes sont : • Moins protégés • Plus de fonctionnalités • Connectés sur le réseau interne • Autorisations d’accès aux personnes internes • Accèdent à Internet

11. Historique – Évolution des attaques (3) • Intérêts (2) • Produits ayant davantage de vulnérabilités (Web, AS) • Applications métiers propriétaires • Non éprouvées • Peu auditées • Anciennes (Web Services) • Lien direct avec les données métiers • De nombreuses vulnérabilités ! Points d’entrées privilégiés

12. Objectifs de ces attaques • Récupération d'informations confidentielles • Atteinte à la confidentialité • Modification du contenu • Données internes (BDD financière, cliente…) • Sites Web publiques (façade commerciale) • Atteinte à l'intégrité • Rendre le service indisponible (Déni de Service – DoS) • Temporaire • Permanent • Atteinte à la disponibilité • Rebond • Point d’entrée privilégié • Atteindre des machines internes • Relais pour attaques externes

13. Conséquences • Récupération d'informations confidentielles • Secrets industriels, annonces commerciales, résultats, données clientes, webmails… • Modification du contenu Résultats incorrects/incohérents, Comptes faussés, Défiguration, BDD corrompues Atteinte à l’image de la société (référencement de défiguration (zataz, zone-h…) • Rendre le service indisponible Production : Perte financière Annuaire, serveur de fichier… : Force de travail bloquée • Rebond Attaque de serveurs internes Attaques externes : imputabilité, responsabilité juridique Les risques restent les mêmes qu’avant Les moyens changent

14. « Qui ? »

15. Qui ? • « Scripts kiddies » (débutants) • Pas de cible spécifique : au hasard • « Gloire » • Concurrents • Un objectif (espionnage industriel, perte de productivité) • Maîtres chanteurs • Menace au déni de service • Extorsion de fond • Worms Web • Autonomes • Exploitent les vulnérabilités Web (PHP…) pour infecter le serveur • Se reproduisent (recherches d’autres sites vulnérables) • Ex : Santy.A (vulnérabilité PhpBB, recherche Google)

16. « Comment ? »

17. Vecteurs de ces attaques • Les vecteurs actuels de ces attaques sont : • Les vulnérabilités des technologies Web • Javascript, PHP/ASP, Perl, Java, CGI, ActiveX... • Les vulnérabilités du code source de l'application • Relativement indépendant du langage utilisé • Vient de la logique de développement • Les vulnérabilités dues aux configurations systèmes et applicatives : • BDD (MySQL, Oracle, MS-SQL Server, Sybase...) • Serveurs Web (Websphere, Tomcat...) • OS (Windows, Linux, UNIX...)

18. Attaques applicativesDémarche générale (1) • Comme pour la plupart des attaques… • Recherche d’informations sur la cible • Recherche de vulnérabilités • Manuelle • Automatique • Outils • Proxies locaux pour le navigateur (Tamper Data, WebScarab…) : modification des paramètres • Différents types de navigateurs (Firefox, IE, Opera…) • Clients spécifiques (pour les Web Services…) • Scanners de vulnérabilités (Nessus, WebInspect, Nikto…)

19. Attaques applicativesDémarche générale (2) • De nombreuses attaques avec seulement un navigateur Depuis n’importe quel poste (poste en démonstration…) Au travers de proxies anonymes (international) Proxy au sein d’une entreprise (imputabilité ?)

20. Vulnérabilités applicatives majeures • Présentation de vulnérabilités applicatives majeures • Repose sur une classification évolutive de l’OWASP • Projet « Top Ten » • http://www.owasp.org/index.php/OWASP_Top_Ten_Project • 10 types de vulnérabilités les plus critiques (2007 RC)

21. Vulnérabilités applicativesFailles Cross-Site Scripting (XSS) (1) • Principe • Envoi de données au serveur • Renvoyées à un utilisateur • Considérées comme du code interprétable (javascript) au sein du navigateur de l’utilisateur • Cause • Manque de validation/d’encodage des données utilisateurs • Conséquences • Exécution de scripts au sein du navigateur de l’utilisateur (javascript le plus employé) • Vol de session • Modification de l’apparence de l’application • Commander le navigateur de l’utilisateur • Périmètre • Applications propriétaires / Applications du commerce

22. Vulnérabilités applicativesFailles Cross-Site Scripting (XSS) (2) • Retour d’expérience • Rencontré quasiment au cours de chaque test d’intrusions applicatif • <script>alert(document.cookie);</script>

23. Vulnérabilités applicativesFailles d’injection (1) • Principe • Envoi de données au serveur (interpréteur : PHP, SQL…) • Considérées comme des commandes • Exécution de commande non prévues • Cause • Manque de validation/d’encodage des données utilisateurs • Conséquences • lecture • suppression • modification de données de l’application Périmètre : Toute application disposant d’un interpréteur

24. Vulnérabilités applicativesFailles d’injection (2) • Exemple : Injection SQL Retour d’expérience : Accès à plusieurs applications d’administration (par injection SQL‘ OR ‘1’=‘1 dans le champ mot de passe)

25. Vulnérabilités applicativesExécution de fichiers malicieux (1) • Principe • L’application fait appel à des ressources distantes ou locales • En fonction de paramètres utilisateurs (URL, nom de fichier…) • Sans en contrôler la teneur (fichiers modifiés au préalable) • Cause • Manque de validation/d’encodage des données utilisateurs • Conséquences • Exécution de code malicieux par le serveur (inclusion) • Accès à des fichiers hors de l’arborescence de l’application • Installation de rootkit, chevaux de Troie • Périmètre • Toute application faisant appel à des ressources externes • Particulièrement si l’upload de fichiers sur le serveur est permis • Particulièrement vrai pour PHP • Exemple (PHP) • include $_GET['page'].'.php';

26. Vulnérabilités applicatives Exécution de fichiers malicieux (2) • Retour d’expérience (suite) • Insertion de code ASP, PHP • Upload d’un « shell » en PHP

27. Vulnérabilités applicativesRéférence directe non sécurisée à un objet (1) • Principe • Utilisation explicite de références à des objets internes (Fichier, répertoire, champ de BDD…) dans une URL ou un formulaire • Un manque de contrôle d’accès permet d’accéder à d’autres ressources sans autorisation • Cause • Conception de l’application • Conséquences • Accès à des fichiers/répertoire en dehors de l’application • Accès à des ressources et fonctionnalités d’administration • Accès à des ressources d’autres utilisateurs • Périmètre • Potentiellement toute application • Retour d’expérience • Accès (lecture/écriture) à des données personnelles concernant des élèves : javascript:visu(‘1234')  javascript:visu(‘1235') • Lecture de fichiers du système : http://www.xxxxxxxxxxx.fr/print.php?PAGE=L2V0Yy9wYXNzd2Q= avec ‘L2V0Yy9wYXNzd2Q=‘ : /etc/passwd encodé en base64

28. Vulnérabilités applicatives Référence directe non sécurisée à un objet (2) • Retour d’expérience • Accès à l’ensemble du système de fichier d’un serveur • Variable ‘PathToExpand’ : ../../../../../../../../../../

29. Vulnérabilités applicativesFaille Cross Site Request Forgery (CSRF) • Principe • Faire effectuer une action légitime ou non à un utilisateur authentifié sur l’application, au travers de son navigateur • Cause • Envoi automatique des éléments d’authentification par le browser (cookie, authentification Basic, certificats, adresse IP…) • Conséquences • Réalisation d’action légitimes non désirées (suppression de données, extinction du serveur…) • Exploitation de failles dans l’application par un utilisateur légitime  Pour le bénéfice de l’attaquant • Périmètre • Toute application ne nécessitant que des éléments d’authentification envoyés automatiquement • Retour d’expérience (basique) • Forcer un utilisateur à se déconnecter • http://www.xxxxxx.fr/logout - Modifier le mot de passe d’un utilisateur

30. Vulnérabilités applicativesFuite d’information et Traitement d’erreur incorrect (1) • Principe • Divulgation d’informations diverses par l’application : configuration de l’application/du serveur, données métier… • En réponse à certaines requêtes • Cause • Conception et/ou configuration de l’application • Le plus souvent : Messages d’erreurs verbeux : code d’erreur, contenu de la mémoire, requêtes SQL… • Également : temps de réponses, types de réponses en fonction des entrées… • Conséquences • Première étape • Fournit des informations utiles à un attaquant • Pour porter atteinte à la sécurité du serveur • Périmètre • Toute application peut être vulnérable

31. Vulnérabilités applicativesFuite d’information et Traitement d’erreur incorrect (2) • Retours d’expérience • Nombreux messages d’erreur avec version des logiciels • Chemin d’accès locaux • Erreurs SQL • Énumération de comptes applicatifs

32. Vulnérabilités applicativesViolation de gestion d’authentification et de session • Principe • Possibilité de contourner les mécanismes d’authentification ou de s’approprier des sessions sur l’application • Cause • Mauvaise gestion des données d’authentification et/ou de session (cookie, login/password…) • Parfois : au sein du mécanismes d’authentification principal • Le plus souvent : au sein des mécanismes secondaires (logout, gestion de mot de passe, mot de passe oublié, mise à jour du compte…) • Conséquences • Usurpation de droits et/ou d’identité • Vol de session administrateur ou utilisateur • Problèmes d’imputabilité • Violation du contrôle d’accès sur les ressources • Périmètre • Toute application peut être vulnérable • Retour d’expérience • A quelques rares exceptions près • Utilisation de cookie statiques (n’évoluent pas dans le temps) • Rejeu possible

33. Vulnérabilités applicativesStockage cryptographique non sécurisé (1) • Principe • Accès à des informations sensibles • Stockées sur le serveur d’application • Cause • Absence de cryptographie sur un ou plusieurs de ces éléments • Utilisation de mécanismes de cryptographie « maison » ou faibles • Mauvaise utilisation de mécanismes de cryptographie forts • Clés codées en dur, clés stockées dans des emplacements non sûrs • Conséquences • Fuite d’informations sensibles • Violation des politiques de sécurité d’accès aux ressources • Non respect des règles de conformité (CNIL, PCI DSS…) • Périmètre • Toute application peut être vulnérable

34. Vulnérabilités applicativesStockage cryptographique non sécurisé (2) • Retour d’expérience • Stockage de mots de passe de comptes applicatifs en clair • Dans une BDD avec interface Web d’administration • Login/password de la BDD en clair dans un script ! • Egalement comptes de domaine Windows • Egalement comptes de messagerie

35. Vulnérabilités applicativesCommunications non sécurisées • Principe • Accès à des informations sensibles transitant entre deux entités • Données d’authentification et Données nominatives, de santé, bancaires… • Front End, Back End • Cause • Pas de chiffrement des (de toutes les) communications (sniffing) • Utilisation de mécanismes de chiffrements faibles (SSLv2) • Mauvaise utilisation de mécanismes de chiffrement forts • Débrayage des fonctions de chiffrements (volontairement ou non) • Conséquences • Fuite d’informations sensibles (authentification, données métiers) • Non respect des règles de conformité (CNIL, PCI DSS…) • Périmètre • Toute application peut être vulnérable • Retour d’expérience • SSLv2 autorisé • Authentification en HTTP, login/password en clair  URL contient : url_vuelta=%2Findex.php%2Fmod._INDICE%2Fmem.i%2Ferror.1%2Fchk.24efab3d4c81a36f28f62c738d3de53c.html&usuario=XXXX&clave=XXXX

36. Vulnérabilités applicativesAbsence de restriction d’accès à certaines URL (1) • Principe • Sécurité par l’obscurité • La simple connaissance de l’URL donne l’accès • URL Volontairement masquées / URL par défaut • D’autant plus problématique si listage des répertoires (Directory Browsing) • Cause • ‘Protection d’accès’ de certaines URL uniquement par non référencement • Manque de contrôle d’accès (absence, insuffisance (ex : côté client seulement)) • Conséquences • Accès à des informations sensibles (fichiers, répertoires) • Accès à des fonctionnalités d’administrations (interfaces) • Périmètre • Toute application peut être vulnérable

37. Vulnérabilités applicativesAbsence de restriction d’accès à certaines URL (2) • Retour d’expérience • Interface web d’accès à une base de données (sans authentification sur l’application) • Scripts par défaut vulnérables (XSS) • Fichiers non référencés: • Documentation décrivant le format de logins/passwords • Annuaire au format MDB

38. Recherche des vulnérabilités Outils automatisés (Nessus, QualysGuard…) • Recherche de vulnérabilités • Analyse statique de code • Rapide • Cas simples, limitations techniques, faux positifs Recherches manuelles • Tests d’intrusions • Revue de code • Cas complexes, validation des faux positifs • Long Complémentarité et Récursivité

39. Conclusion • Les menaces sont passées du réseau à l’application • Vulnérabilités applicatives sont graves, exploitables et exploitées • Évolution rapide des technologies et des problèmes de sécurité • Problème de fond • Applications en projet • Prise en compte de la sécurité dès le début du projet • Bonnes pratiques de développement • Implémenter des mécanismes de sécurité • Tests complémentaires adaptés • Applications en production • Audits de sécurité technique : revue de code, audits, tests d’intrusion • Complémentarité outils automatiques et tests manuels (processus récursif) • Nécessité d’une prestation d’expertise, récurrente • Nécessité d’un travail de veille permanent

40. Questions ?