Accréditation N° Section Laboratoires Portée sur SGDN-DCSSI

Présentation au sujet: "Accréditation N° Section Laboratoires Portée sur SGDN-DCSSI"— Transcription de la présentation:

1 Portée sur www.cofrac.fr
Accréditation N° Section Laboratoires Portée sur SGDN-DCSSI Certificat N°1994-/2759h Attaques sur les applications web Pourquoi 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 Définitions Vulnérabilité, Menace, Attaque Menace 1 Attaque Menace 2

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 AS = Application Server Ici, on se concentre sur les attaques des applications Web métiers : Attaques Web (depuis un réseau interne/sûr ou non) Ces attaques constituent un sous-ensemble de toutes les attaques possibles. Actuellement, il existe beaucoup de failles de ce type et cela constitue un point d'entrée privilégié. --> Faille inconnues au préalable, mais de "type" connus/classiques. (classes d'attaques génériques).

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 Les risques restent les mêmes qu’avant
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) Concurrents Maîtres chanteurs
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 applicatives Dé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 applicatives Dé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 » 10 types de vulnérabilités les plus critiques (2007 RC) 2007RC Vulnérabilité applicative (2004) A1 Failles Cross Site Scripting (XSS) (A4) A2 Failles d’injection (A6) A3 Exécution de fichiers malicieux A4 Référence directe non sécurisée à un objet (A2) A5 Faille Cross Site Request Forgery (CSRF) A6 Fuite d’information et Traitement d’erreur incorrect (A7) A7 Violation de gestion d’authentification et de session (A3) A8 Stockage cryptographique non sécurisé (A8) A9 Communications non sécurisées (A10) A10 Absence de restriction d’accès à certaines URL

21 Vulnérabilités applicatives Failles 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 applicatives Failles 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 applicatives Failles 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 applicatives Failles 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 applicatives Exé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 applicatives Ré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 : 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 applicatives Faille 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 - Modifier le mot de passe d’un utilisateur

30 Vulnérabilités applicatives Fuite 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 applicatives Fuite 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 applicatives Violation 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 applicatives Stockage 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 applicatives Stockage 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 applicatives Communications 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 applicatives Absence 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 applicatives Absence 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 ?