1 / 40

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

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

nita
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 ?

More Related