ASFWS 2011 - L’importance du protocole HTTP dans la menace APT
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

ASFWS 2011 - L’importance du protocole HTTP dans la menace APT

  • 1,206 views
Uploaded on

Depuis plusieurs mois, les APT font la une de la presse spécialisée en sécurité. Les plus grands noms de l’industrie tombent les uns après les autres et voient leur données compromises et affichées......

Depuis plusieurs mois, les APT font la une de la presse spécialisée en sécurité. Les plus grands noms de l’industrie tombent les uns après les autres et voient leur données compromises et affichées au yeux de tous.
Les APT ne sont pas nouvelles et représentent une intrusion calculée, orchestrée et avec un objectif bien plus ciblé que les attaques classiques. Nous verrons comment le Web et le protocole HTTP prennent une place importante dans la réalisation d’une APT, du début de l’intrusion, en passant par le maintient et l’évolution dans l’infrastructure pour finir par l’extraction des données.

Application Security Forum 2011
27.10.2011 - Yverdon-les-Bains (Suisse)
Conférencier: Matthieu Estrade

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to like this
No Downloads

Views

Total Views
1,206
On Slideshare
1,206
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
35
Comments
1
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. L’importance du web et duprotocole HTTP dans lesAdvanced Persistent Threat(APT)Matthieu EstradeCTOBee Ware Application Security Forum Western Switzerland 27 octobre 2011 - HEIGVD Yverdon-les-Bains http://appsec-forum.ch
  • 2. Agenda Historique du protocole HTTP Anatomie d’une APT Comment faire face à ces menaces
  • 3. Speaker Matthieu Estrade CTO Bee Ware Co-fondateur d’Axiliance en 2001 Expert en sécurité Web Membre du chapitre Français de l’OWASP WASC Officer Committer Apache HTTPd
  • 4. Un peu d’histoire !
  • 5. Le protocole HTTP Inventé par Tim Berners-Lee (CERN) en même temps que le HTML pour créer le World Wide Web HTTP 0.9 -> 1989/1990 HTTP 1.0 -> Mai 1996 HTTP 1.1 -> 1997 / 1999 http://www.w3.org/Administration/HTandCERN.txt
  • 6.  Un protocole qui a peu évolué Dernières spécifications en 1999… Stateless… – Pas de suivi de session sécurisé
  • 7.  Dépassé par le contenu qu’il véhicule – HTML au début – Flash, Javascript, ActivX etc. – De plus en plus complexe – De plus en plus riche
  • 8. Les contraintes actuelles… Plus de performances Plus de fiabilité – 24 / 7 / 365 Plus de sécurité – Confidentialité Plus de médias – Video – Audio – Etc.
  • 9. Aujourd’hui ! Intégration d’interpréteurs de langages directement dans les navigateurs Le browser devient un client riche universel ! – Pas de client natif à installer – Déjà présent sur les systèmes – Et sur toutes les plateformes (mobiles, pc, mac etc.) Tout est bien plus simple avec le Web 
  • 10. Le Web prend le pouvoir !
  • 11.  Paiement en ligne Gestion des comptes bancaires en ligne
  • 12.  Paiement en ligne  Numéro de carte de Gestion des comptes crédit bancaires en ligne  Virements externes
  • 13.  Publication de données « corporate » Publication de données sensibles
  • 14.  Publication de  Image de la société données « corporate » Publication de  Données métiers et données sensibles confidentielles
  • 15.  Sites communautaires – Facebook/LinkedIN/et c. Informations patient Divertissement – PSN/XBox live/etc.
  • 16.  Sites communautaires  Données personnelles – Facebook/LinkedIN/et – Habitudes c. – Choix – Croyances Informations patient  Données médicales Divertissement  Données bancaires – PSN/XBox live/etc.
  • 17. Et la sécurité dans tout ça ?
  • 18.  Les firewall réseaux classiques ne filtrent pas le contenu Les applications sont de plus en plus sécurisées mais quid des anciennes, de celles dont on ne maitrise pas le code source, des erreurs de conception et de développement ? La responsabilité de la sécurité web est souvent floue, entre équipe réseau, développement, exploitation etc.
  • 19. Les méchants !
  • 20. Ils ont bien compris l’enjeu dusystème Peuvent commettre leurs délis de l’autre bout du monde – Bien moins risqué que la criminalité classique – Une image High Tech qui banalise cette criminalité Ne risquent strictement rien dans certains pays – Peu de lois N’ont pas besoin d’avoir recours à la violence
  • 21. Anatomie d’une APT
  • 22. Définition Une attaque orchestrée, complexe, qui cible principalement les données sensibles Dure plusieurs semaines/mois/années N’a pas pour but principal d’être médiatisées ou détectées
  • 23. A qui profite une APT ? A un concurrent qui récupère les informations sensibles au fur et à mesure – Décisions stratégiques – Résultats de recherches – Salaires, ressources humaines A une organisation criminelle – Données bancaires – Détournement de fonds
  • 24. HTTP, principal vecteur d’intrusion Les port 80 et 443 sont très souvent ouverts vers Internet Les employés d’une société naviguent sur Internet Les sociétés sont interconnectées entre elles grâce aux Webservices qui utilisent HTTP
  • 25. La surface d’attaque augmente Le moindre site web de l’infrastructure peut être une porte d’entrée (Le Blog du Playstation Network) Un seul partenaire compromis peut rebondir dans votre infrastructure Un employé peut être connecté en VPN de chez lui et naviguer sur des sites web compromis
  • 26.  Les cibles: utilisateurs et employés Objectif: les forcer à naviguer sur des données ou des applications compromises • Phishing • Spam • Malware Il y aura toujours une personne dont l’antivirus n’est pas à jour et qui cliquera sur un lien compromis…
  • 27.  Les cibles: les applications et services Objectif: exploiter les vulnérabilités • Exploits • 0 Day Les applications « publiques » et exposées sont souvent bien protégées, bien plus que celles qui sont peu utilisées…
  • 28. Se maintenir Une fois introduit sur une machine, il est nécessaire de pouvoir y revenir quand nécessaire, et d’installer ses outils ou établir un tunnel pour continuer l’attaque.
  • 29. Comment ? Les backdoors « web » Peuvent être de simples applications déposés dans l’arborescence – C99.php etc. Peuvent être des hooks sur les sockets pour avoir un tunnel (LD_PRELOAD) Les backdoors sont souvent installées sur les applications utilisant le protocole HTTP.
  • 30. L’évolution dans le SI Pour atteindre les données sensibles, il est souvent nécessaire de traverser plusieurs zones. – DMZ – Présentation – Applicatives – Données – LAN – Etc.
  • 31. Rebondir via … Interconnexion de WebServices Interface/GUI de produits et applications Ports d’administration en HTTP Dialogue entre Serveur Web frontal et serveur web applicatif Connexion vers une base de donnée Connexion vers un annuaire LDAP Etc.
  • 32. Rebond Le protocole HTTP est souvent ouvert entre les différentes zones. Rares sont les infrastructures avec des zones filtrées sur le trafic entrant ET sortant… Les crédentiels utilisés sont souvent identiques entre les différentes zones
  • 33. L’extraction de données L’objectif final d’une APT Ponctuelle ou permanente Le plus discrètement possible Le protocole HTTP est toujours autorisé à sortir au niveau de l’infrastructure Dans le pire des cas, un proxy filtrant rendra les choses plus compliquées
  • 34. Comment se protéger ? Prévenir Filtrer Authentifier/autoriser Monitorer Comprendre / analyser
  • 35. Prévenir
  • 36.  Définir une infrastructure applicative sécurisée – Cloisonnement des réseaux • Sas de contrôles – Séparation des applications • Par criticité • Par type de données manipulées – Anticiper les différentes réactions possibles • Monitoring • Compréhension d’une attaque
  • 37.  Analyse de risque et modélisation des attaques – Lister les composants – Comprendre les menaces – Anticiper les incidents – Mesurer l’impact d’une intrusion en fonction des données compromises
  • 38.  Formation des développeurs aux techniques d’attaques web et au développement sécurisé – Librairies de filtrage d’input – OWASP TOP10 / WASC TC v2
  • 39.  Auditer régulièrement – Si vous avez accès au code source des applications • Analyse de code et recherche de vulnérabilités – Si vous n’avez pas accès au code source • Scanner de vulnérabilités applicatives • Tests d’intrusions
  • 40. Mettre en place uneréponse appropriée
  • 41.  Au niveau de l’infrastructure – En complément du pare-feu réseau – Devant chaque zone manipulant le protocole HTTP – Défense en profondeur – Association du contexte utilisateur avec la politique de sécurité
  • 42.  Filtrer les flux: Le Web application Firewall – Extension applicative du pare-feu réseau – Analyse du contenu HTTP (Niveau 7 OSI) – Protection contre les attaques • SQL Injection • XSS / XSRF • Parser Evasion • Remote command • Etc.
  • 43.  Filtrer les flux: Le Web Services Firewall – Extension du WAF sur les échanges SOAP/REST – Analyse du contenu XML – Protection contre les attaques Web – Protection contre les attaques de parseur – Signature et chiffrement des messages
  • 44.  Authentifier, Autoriser – Vérification des identités – Association d’un profil de sécurité par identité (PICWIC) – Autorisation par groupe d’utilisateurs • Business • HR • Admin
  • 45.  Assurer la continuité de service – Bloquer les Dénis de service – Bloquer les comportements anormaux • Robots • Taches automatisées – Répartition de charge – Accélération SSL
  • 46. Exploiter
  • 47.  Monitorer – Comprendre quelle est la cible de l’attaquant – Suivre l’évolution de la menace – Détecter en temps réel les utilisations abusives – Détecter en temps réel les tentatives d’exploitations
  • 48.  Corrélation des logs – Entre les différentes attaques sur les applications de l’infrastructure – Comportement de l’utilisateur – Evolution de l’attaque • Détection/compréhension • Exploitation • Compromission (backdoor)
  • 49.  Reporting et Alerting – Rapports sur les attaques – Rapports d’utilisation de l’application – Alertes en fonction du type d’attaque – Déclenchement de procédures • Blacklist automatique • Redirection vers Honeypot – Audit de authentifications
  • 50. Forensics
  • 51.  Comprendre la portée d’une attaque Pour chaque zone compromise – Trouver la technique d’intrusion utilisée – Analyser la méthode de backdoor pour le maintien sur le système – Analyser les données compromises et extraites du système d’information – Analyser les volumes de données sortantes
  • 52.  Analyse des systèmes – Utilisateurs ajoutés récemment – Erreurs d’exécution • Segfault – Fichiers de configuration modifiés – Démons en cours d’exécution – Owner et group des démons exécutés
  • 53.  Analyse de logs Recherche de traces pour l’historique de l’incident Logs d’accès et logs d’erreur – Sur les équipements de filtrage – Sur les serveurs web – Sur les bases de données – Sur les systèmes d’exploitation – Etc.
  • 54.  Recherche de backdoor Analyse des systèmes de fichiers – Fichiers • modifiés • Effacés • Ajoutés – Backdoors • Sur les binaires • Déposées directement sur le FS
  • 55. Conclusion La sécurité d’une infrastructure applicative devrait se jouer principalement lors de sa conception. La réalité du terrain met en évidence des difficultés à appliquer toutes les bonnes pratiques Une étude approfondie des menaces, une réponse approprié ainsi que l’anticipation des incidents possibles sont aujourd’hui la meilleure réponse aux attaques applicatives
  • 56. Questions ? mestrade@bee-ware.net