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

1
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 lapplication Web métier
• Historique et évolutions des attaques (Pourquoi
  ?)
• Doù proviennent ces attaques (Qui ?)
• Vecteurs et méthodes dattaques (Comment ?)
• Conclusion

3
Présentation des intervenants

• Emilien LE JAMTEL
• Consultant expert en sécurité des systèmes
  dinformations
• 3 ans dexpérience
• Spécialiste en
• Tests dintrusion
• Audit de configuration
• Audit darchitectures 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
  lentreprise ?
• Pourquoi la plupart des mesures actuelles ne
  suffisent pas ?
• Quelles sont les causes de ces menaces ?
• Que mettre en place pour sen protéger ?

5
Applications Web métier Définition (1)

• Applications accédées en réseau au moyen dun
  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 dinstallation 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 dexploitation Windows, Linux, UNIX...

7
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 daccè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 dentré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 dentré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 à limage 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 quavant 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 dautres 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 dinformations 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 nimporte quel poste (poste en
  démonstration)
• Au travers de proxies anonymes
  (international)
• Proxy au sein dune entreprise
  (imputabilité ?)

20
Vulnérabilités applicatives majeures

• Présentation de vulnérabilités applicatives
  majeures
• Repose sur une classification évolutive de
  lOWASP
• Projet  Top Ten 
• http//www.owasp.org/index.php/OWASP_Top_Ten_Proje
  ct
• 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 dinjection (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 dinformation et Traitement derreur incorrect (A7)
A7 Violation de gestion dauthentification et de session (A3)
A8 Stockage cryptographique non sécurisé (A8)
A9 Communications non sécurisées (A10)
A10 Absence de restriction daccès à certaines URL (A2)
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
  lutilisateur
• Cause
• Manque de validation/dencodage des données
  utilisateurs
• Conséquences
• Exécution de scripts au sein du navigateur de
  lutilisateur (javascript le plus employé)
• Vol de session
• Modification de lapparence de lapplication
• Commander le navigateur de lutilisateur
• Périmètre
• Applications propriétaires / Applications du
  commerce

22
Vulnérabilités applicativesFailles Cross-Site
Scripting (XSS) (2)

• Retour dexpérience
• Rencontré quasiment au cours de chaque test
  dintrusions applicatif
• ltscriptgtalert(document.cookie)lt/scriptgt

23
Vulnérabilités applicativesFailles dinjection
(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/dencodage des données
  utilisateurs
• Conséquences
• lecture
• suppression
• modification de données de lapplication
• Périmètre Toute application disposant dun
  interpréteur

24
Vulnérabilités applicativesFailles dinjection
(2)

• Exemple Injection SQL
• Retour dexpérience Accès à plusieurs
  applications dadministration (par injection SQL
  OR 11 dans le champ mot de passe)

25
Vulnérabilités applicativesExécution de fichiers
malicieux (1)

• Principe
• Lapplication 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/dencodage des données
  utilisateurs
• Conséquences
• Exécution de code malicieux par le serveur
  (inclusion)
• Accès à des fichiers hors de larborescence de
  lapplication
• Installation de rootkit, chevaux de Troie
• Périmètre
• Toute application faisant appel à des ressources
  externes
• Particulièrement si lupload 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 dexpérience (suite)
• Insertion de code ASP, PHP
• Upload dun  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 daccès permet daccéder à
  dautres ressources sans autorisation
• Cause
• Conception de lapplication
• Conséquences
• Accès à des fichiers/répertoire en dehors de
  lapplication
• Accès à des ressources et fonctionnalités
  dadministration
• Accès à des ressources dautres utilisateurs
• Périmètre
• Potentiellement toute application
• Retour dexpérience
• Accès (lecture/écriture) à des données
  personnelles concernant des élèves
  javascriptvisu(1234') ? javascriptvisu(1235')
• Lecture de fichiers du système
  http//www.xxxxxxxxxxx.fr/print.php?PAGEL2V0Yy9wY
  XNzd2Q
• avec L2V0Yy9wYXNzd2Q /etc/passwd encodé en
  base64

28
Vulnérabilités applicatives Référence directe
non sécurisée à un objet (2)

• Retour dexpérience
• Accès à lensemble du système de fichier dun
  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 lapplication, au
  travers de son navigateur
• Cause
• Envoi automatique des éléments dauthentification
  par le browser (cookie, authentification Basic,
  certificats, adresse IP)
• Conséquences
• Réalisation daction légitimes non désirées
  (suppression de données, extinction du serveur)
• Exploitation de failles dans lapplication par un
  utilisateur légitime
• ? Pour le bénéfice de lattaquant
• Périmètre
• Toute application ne nécessitant que des éléments
  dauthentification envoyés automatiquement
• Retour dexpérience (basique)
• Forcer un utilisateur à se déconnecter
• http//www.xxxxxx.fr/logout
• - Modifier le mot de passe dun utilisateur

30
Vulnérabilités applicativesFuite dinformation
et Traitement derreur incorrect (1)

• Principe
• Divulgation dinformations diverses par
  lapplication configuration de lapplication/du
  serveur, données métier
• En réponse à certaines requêtes
• Cause
• Conception et/ou configuration de lapplication
• Le plus souvent Messages derreurs verbeux
  code derreur, 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 dinformation
et Traitement derreur incorrect (2)

• Retours dexpérience
• Nombreux messages derreur avec version des
  logiciels
• Chemin daccès locaux
• Erreurs SQL
• Énumération de comptes applicatifs

32
Vulnérabilités applicativesViolation de gestion
dauthentification et de session

• Principe
• Possibilité de contourner les mécanismes
  dauthentification ou de sapproprier des
  sessions sur lapplication
• Cause
• Mauvaise gestion des données dauthentification
  et/ou de session (cookie, login/password)
• Parfois au sein du mécanismes
  dauthentification 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 didentité
• Vol de session administrateur ou utilisateur
• Problèmes dimputabilité
• Violation du contrôle daccès sur les ressources
• Périmètre
• Toute application peut être vulnérable
• Retour dexpé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 dapplication
• 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 dinformations sensibles
• Violation des politiques de sécurité daccè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 dexpérience
• Stockage de mots de passe de comptes applicatifs
  en clair
• Dans une BDD avec interface Web dadministration
• 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 dauthentification 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 dinformations 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 dexpérience
• SSLv2 autorisé
• Authentification en HTTP, login/password en clair
• ? URL contient url_vuelta2Findex.php2Fmod._I
  NDICE2Fmem.i2Ferror.12Fchk.24efab3d4c81a36f28f6
  2c738d3de53c.htmlusuarioXXXXclaveXXXX

36
Vulnérabilités applicativesAbsence de
restriction daccès à certaines URL (1)

• Principe
• Sécurité par lobscurité
• La simple connaissance de lURL donne laccès
• URL Volontairement masquées / URL par défaut
• Dautant plus problématique si listage des
  répertoires (Directory Browsing)
• Cause
• Protection daccès de certaines URL uniquement
  par non référencement
• Manque de contrôle daccès (absence, insuffisance
  (ex côté client seulement))
• Conséquences
• Accès à des informations sensibles (fichiers,
  répertoires)
• Accès à des fonctionnalités dadministrations
  (interfaces)
• Périmètre
• Toute application peut être vulnérable

37
Vulnérabilités applicativesAbsence de
restriction daccès à certaines URL (2)

• Retour dexpérience
• Interface web daccès à une base de données (sans
  authentification sur lapplication)
• 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 dintrusions
• 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 à
  lapplication
• 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 dintrusion
• Complémentarité outils automatiques et tests
  manuels (processus récursif)
• Nécessité dune prestation dexpertise,
  récurrente
• Nécessité dun travail de veille permanent

40

• Questions ?