Are we getting better? – Hacking Todays Technology
Dave Kennedy
David Kennedy est le fondateur de TrustedSec, société de conseil en sécurité et éditeur de SET (Social Engineering Toolkit).
[Depuis https://www.hackinparis.com/dave-kennedy]
David Kennedy commence sa présentation en nous informant que malgré une augmentation des moyens de défense, il y a eu une augmentation de 47% des intrusions en 2012.
Il liste ensuite quelques-uns de ces types de produits ainsi que le temps qu’il faut pour les contourner :
• Next-Gen Firewall : 4 minutes ;
• Web Application Firewall : 1 heure ;
• Analyse comportementale : 30 secondes ;
• White et black listing : 30 secondes ;
• Antivirus, DLP, Content Filtering : 0 seconde, s’il s’agit d’un nouvel exploit/fichier, il n’y pas encore de signature ;
• MSSP : concept intéressant, mais pas assez évolutif en outsourcing.
Après quelques démonstrations, il apparaît qu’il est relativement facile de déjouer ces méthodes de défense, malgré la multiplication des produits. Il met en avant la définition de l’absurdité : faire encore et toujours la même chose tout en attendant un résultat différent.
Il faut donc aborder la problématique de la défense sous un autre angle.
David Kennedy présente son programme sécurité en 5 étapes :
1. Changer de culture pour une basée sur la sécurité, incluant l’éducation et la sensibilisation des collaborateurs, en considérant la sécurité comme un « business enhancer » ;
2. Privilégier le « 1 year challenge » qui consiste à ne pas acheter de nouvel équipement pendant un an, de continuer à utiliser ce qui est déjà présent, puis faire le point à la fin de cette année sur ce qui a été utilisé ou non ;
3. Focaliser sur les bases : les principales menaces ne sont pas les 0 day et les APT mais bien les mots de passe par défaut et les XSS, entre autres ;
4. Détecter et surveiller : cela n’est pas efficient à 100%, mais reste tout de même nécessaire ;
5. Faire des tests d’intrusion manuels. Il regrette qu’aujourd’hui il y ait une commercialisation intensive de l’automatisation.
Il nous invite donc à prendre un peu de recul pour réfléchir à ce que nous faisons et à simplifier notre démarche, citant la lecture de Rework (Jason Fried et David Heinemeier Hansson, 2010) comme une bonne source d’inspiration.
Origin policy enforcement in modern browsers
Frederik Braun
Frederick Braun est security engineer chez Mozilla à Berlin.
Les Same Origin Policies (SOP) ont pour objectif d’éviter l’inclusion d’une page Web malveillante dans une page Web légitime, ceci afin de limiter les problématiques de sécurité engendrées par l’authentification partagée.
Firefox 16 corrigeait 11 vulnérabilités rencontrées dans Firefox 15, mais offrait une possibilité de SOP-bypass. La décision a été prise de revenir vers la version 15, jugeant que les vulnérabilités détectées présentaient un risque moindre qu’une problématique de SOP-bypass.
Une SOP est souvent considérée comme le moyen de s’assurer du respect d’un périmètre d’authentification.
SOP existe depuis 1996, depuis le traitement des frames par Napster.
L’origine est déterminée depuis différents éléments de l’URL : le schéma (ex. : http://), le hostname (ex. : www.devoteam.com) et le port (ex. : 80).
Si ces éléments sont identiques, alors les composants sont reconnus comme provenant de la même source… mais certaines exceptions existent.
About:blank représente ainsi une page vierge, ne semblant former aucune origine valide, mais est cependant conforme à une SOP. La raison est historique, expliquée par le besoin de pouvoir ouvrir des pop-up vides afin d’y insérer du contenu via JavaScript.
De plus, Internet Explorer ne prend pas en compte le port dans l’analyse de l’origine.
Frederik présente ensuite différentes vulnérabilités passées, relatives à SOP :
• vers 2007, l’ajout d’un null byte dans l’adresse entraînait une incohérence de traitement de la SOP puisque les couches sous-jacentes du navigateur, codées en C, interprétaient différemment ce null byte de l’encodage UTF-16 du navigateur ;
• vers 2010, l’ajout d’un caractère ‘@’ dans une URL entraînait une erreur de traitement par Flash et une mauvaise évaluation des origines.
Ces erreurs résident globalement dans une évaluation différente de l’origine entre la première API et les couches sous-jacentes (DNS, HTTP API etc.).
Différents moyens sont ensuite présentés pour éviter les soucis de la SOP, mais tous semblent difficilement exploitables à court terme.
Les SOP-bypass pourraient par exemple être réduits par l’utilisation des métadonnées allow values (dans le modèle CSP, permettant de spécifier une liste blanche des adresses depuis lesquelles le contenu est chargé). Cependant, 96% des sites de l’Alexa TOP 10000 incluent du JavaScript directement dans le corps de la page. Encore une fois, la sécurité serait moins mise à mal si les bonnes pratiques étaient mieux respectées dans les phases de développement.
La recommandation principale pour éviter ces problématiques des SOP-bypass est, si votre site contient du contenu créé par ses utilisateurs, de l’héberger sur un domaine dédié afin de s’assurer du respect de la SOP (comme peut le faire Google avec son domaine googleusercontent.com).
Ces SOP sont donc très inconsistantes et diffèrent pour chaque vendeur. Elles constituent, en théorie du moins, une liste noire mais de nombreux éléments viennent la rendre de moins en moins efficace. La moindre extension chargée augmente donc le nombre d’URL concernées par la SOP.
Certains modèles, sécurisés et bien conçus, tels que CSP devraient permettre, dans un avenir relativement proche, de réduire les risques liés aux problématiques SOP.
Malware vs Virtualization: The endless cat and mouse play
Aurélien Wailly
Aurélien Wailly est un doctorant en sécurité du Cloud chez Orange Labs et Telecom SudParis.
[Depuis https://www.hackinparis.com/aurelien-wailly]
Aurélien Wailly introduit sa présentation en décrivant le principe de la virtualisation permettant, entre autres choses :
- la mise à disposition de machine de manière rapide et facile ;
- le retour arrière ;
- la consolidation et le contrôle des ressources laissant peu de traces.
Cela en fait donc un outil parfait pour mener des tests, notamment sur les malwares. Il décrit également ceux-ci comme étant largement disséqués, ayant un comportement adaptatif et pouvant détecter les environnements virtuels. C’est sur ce dernier point que l’orateur focalise son intervention.
Il liste différentes techniques de détection principalement basées sur l’étude du vCPU (calcul du ratio des temps d’exécution de différentes instructions) et la MMU ainsi que leurs comportements, mais il est également possible d’étudier le trafic réseau (TCP TTL, taxonomie).
Malgré cette relative aisance de détection, il semblerait que moins de 2% des malwares utilisent de telles techniques, cependant ce sont souvent les pires.
Il mentionne ensuite des techniques de contournement comme la formalisation, Ether, f00f ou autres méthodes réduisant la virtualisation des périphériques au minimum, mais au coût de la consommation des ressources. Il cite également la physicalisation illustrée par Barebox. Cependant, il existe quelques contre-mesures, comme Nether.
L’orateur pense que la prochaine grande étape de la virtualisation portera sur l’intégration de l’hyperviseur dans le CPU.
Enfin, il conclut en soulignant l’importance de la virtualisation physique.
Les slides de sa présentation sont disponibles à l’adresse suivante: http://aurelien.wail.ly/publications/hip-2013-slides.pdf
Web applications forensics
Jens Müller
Jens Müller présente une étude de cas qu’il a pu résoudre grâce à LORG, un outil développé à cette occasion.
Le point de départ de sa réflexion vient du manque de solutions de log management, analysis ou forensics dédiées au traitement poussé des logs de solution Web (Waf, IDS, serveur web, etc.).
Compte tenu du volume important généré, il n’est pas envisageable de se reposer sur des outils basiques de recherche tels que grep, sed ou awk.
Il décide donc de créer LORG (Logfile Outlier Recognition and Gathering), un outil PHP et CLI qui implémente différentes techniques permettant un scan automatique des logs HTTPD à la recherche d’attaques à l’encontre des frontaux Web.
La première approche quant à la fiabilisation des logs consiste à associer des techniques basiques telles que l’analyse de regex, les statistiques de répartition des caractères et autres fonctionnalités reproduisant, globalement, une approche par signature de la détection.
PHPIDS est utilisé pour la désobfuscation et la recherche de regex.
Les statistiques établies ont pour objectif d’attribuer à chaque requête d’URL la probabilité que celle-ci soit bénigne ou non.
La seconde approche est basée sur l’apprentissage machine, notamment par la recherche de chaînes de Markov par agrégation, conversion, phase d’apprentissage, etc. Après expérimentation de ce modèle par l’évaluation de 63 000 requêtes (considérées saines) dans lesquelles ont été injectés 40 exploits, répartis dans des URL de différentes WebApp, il s’avère que le nombre d’éléments reste toujours trop important pour être traité de façon manuelle.
Différents éléments comportementaux ont donc été ajoutés à la solution afin de mieux évaluer la probabilité qu’une requête provienne d’un robot, par exemple l’accès au fichier robots.txt en premier, des requêtes non POST/GET, des éléments indiquant un comportement trop rapide pour être humain.
Puisque l’analyse des codes de réponse ou l’analyse de la taille des réponses ne peut attester de façon fiable de la réussite ou non d’une attaque, le tableau de bord de la solution LORG permet de filtrer les informations et de réaliser des visualisations permettant d’identifier des tendances globales dans le trafic observé.
L’outil, en phase de prototypage, n’est pas utilisable dans toutes les situations, puisqu’il est vulnérable à de l’obfuscation des vecteurs d’attaque ou à l’utilisation de vecteurs non visibles dans les logs, entre autres. Cependant, il fournit un ensemble de fonctionnalités permettant de retracer la progression d’une attaque via une fonctionnalité de rejeu des attaques.
LORG est disponible à l’adresse suivante : https://github.com/jensvoid/lorg/
DBI Frameworks applied to computer security: Uses and comparative
Ricardo Rodriguez
L’orateur, espagnol, est en ce moment en train de terminer sa thèse sur les frameworks de DBI.
Il faut donc revenir sur ce qu’est un DBI.
Dynamic Binary Instrumentation est un programme qui permet de faire de l’instrumentation (monitoring) de binaire au cours de son exécution.
Les avantages sont : c’est indépendant du langage de programmation (puisque l’analyse porte sur le binaire, et non le code, on peut également faire fi des licences, en monitorant des binaires propriétaires. En revanche, il y a une grosse perte en matière de performances et le fait que l’analyse soit dynamique implique qu’on ne peut analyser l’ensemble des possibles (l’ensemble des traces symboliques) mais uniquement les traces qui seront exécutées.
Ricardo a ensuite comparé 3 frameworks que l’on peut trouver sur le marché :
1. Valgrind ;
2. Pin framework (Intel) ;
3. DynamaRIO (MIT/HP et GOOGLE).
Les résultats indiquent que pour une utilisation optimum de la mémoire et une meilleure rapidité d’action, Pin est le plus performant alors que Valgrind donne des résultats médiocres.
Ensuite, il a montré comment en utilisant Pin Tools, il a réussi à trouver des applications à la sécurité informatique. Il est notamment capable de détecter des Buffer Overflow. À partir d’un bref exemple, il montre qu’en lançant un programme monitoré par son outil, celui-ci remonte des alertes lorsqu’il détecte l’utilisation potentielle d’un scanf pouvant mener à une vulnérabilité. Si un attaquant potentiel tente une exploitation, l’outil remonte une alerte.
En conclusion, cet outil a un fort potentiel, il n’y a pas besoin d’avoir de grosses connaissances en OS bas niveau car des API permettent de le développer facilement. Par contre, les performances s’en trouvent fortement affectées.
The inner HTML Apocalypse: How MXSS attacks change everything we believed to know so far
Mario Heiderich
Mario Heiderich est chercheur à la Ruhr Universität à Bochum (Allemagne), ses recherches ciblent majoritairement le domaine du Web comme le HTML5, JavaScript, les XSS et SVG.
[Depuis https://www.hackinparis.com/Mario-Heiderich]
Mario Heiderich commence sa conférence en admettant que l’on parle beaucoup de HTML en ce moment, principalement parce que c’est un langage utilisé partout. Il a même calculé la quantité de JavaScript sur Gmail : 3,5Mo par page !
Il continue en mentionnant qu’au fur et à mesure des années, plusieurs niveaux de sécurité se sont construits autour du HTML, notamment afin de déjouer les 3 types de XSS : Reflected XSS, Stored XSS et DOM-XSS.
Il présente ensuite une propriété DOM, l’« element.innerHTML », que Microsoft a introduit il y a une dizaine d’années et qui sert à manipuler du contenu, principalement du texte. Très pratique et facile à utiliser (malgré le fait qu’il ne soit pas vraiment compatible avec les balise <table> et le XML), cet élément est présent dans quasiment toutes les WebApp qui manipulent du texte aujourd’hui. Le problème est que cette propriété n’est pas indépendante et est amenée à changer.
En 2007, Yosuke Hasegawa a découvert les prémices des mXSS (mutant XSS), que l’orateur nous présente aujourd’hui par une démonstration. On voit qu’il est possible d’injecter du code dans les balises des classes, et même dans les attributs de style CSS à l’intérieur des balises !
Il existe beaucoup trop de variations et même si l’utilisation du caractère d’échappement (‘\’) est bloquée, certaines injections fonctionneront sans, en utilisant une simple virgule… Enfin, pour ne pas faciliter la tâche, les mXSS fonctionnent de manière récursive.
L’orateur propose tout de même quelques recommandations afin de se protéger :
- Utiliser du HTML5 strict (< !doctype html>), du CSP, des listes blanches ;
- Éviter le SVG et le MathML, les caractères étranges dans les attributs HTML ;
- Patcher les filtres et connaître les vulnérabilités associées.
En conclusion, il évoque une spécification de sérialisation et de parsing des propriétés DOM en cours de rédaction, mais rappelle qu’en attendant, il faut que les développeurs restent vigilants et qu’il y a de quoi s’amuser pour les pentesters.
Les slides de sa présentation sont disponibles à l’adresse suivante : http://fr.slideshare.net/x00mario/the-innerhtml-apocalypse
The Realex payments application security story, narrated by Security Ninja
Security Ninja (David Rook)
La clôture de cette troisième édition de Hack in Paris revient à @SecurityNinja, qui présente les travaux de sécurité mis en place autour de l’application de paiement Realex.
La présentation commence par la distribution du support de diaporama… au format comic book, ça s’annonce compliqué pour prendre des notes.
En fait, David Rook raconte son histoire commune avec Realex, de son arrivée en 2006, en qualité d’ « Operations Security something », avant d’évoluer vers le rôle de premier « application security guy » de l’entreprise.
La présentation passe en revue les différentes étapes du cycle de vie de l’application et de la méthode implémentée dans l’ordre suivant :
• En 2006, un besoin de revue du legacy code est nécessaire ainsi que le besoin de s’assurer de la compliance PCI-DSS. Pour ce faire, les développeurs vérifient l’absence de vulnérabilités de l’OWASP Top10 et c’est tout ;
• Débute alors un audit de l’intégralité du code, durant la majorité des six premiers mois, permettant d’auditer environ 250 000 lignes d’un code écrit, modifié, repris et corrigé au fil du temps ;
• Ajout de livrables « security deliverables » au cycle de vie de l’application ;
• Début de la création d’un Secure Development LifeCycle (SDLC) basique, proche de l’approche informelle choisie jusqu’alors ;
• Début des formations sécurité au sein de l’entreprise ;
• Début de l’automatisation des tests de sécurité avec l’arrivée de Burp Suite au sein des équipes de développement et de quality assessment ;
• Les audits réguliers du code mettent en avant des vulnérabilités, mais aussi des failles de conception dans le SDLC ainsi que des défauts dans la méthodologie de remontée des incidents ;
• Mise en place d’une fonctionnalité de modélisation des menaces ;
• Réalisation du premier audit externe de l’application, non pas à des fins de compliance, mais afin d’identifier des faiblesses, tant dans l’implémentation que dans l’organisation du SDLC ;
• Introduction des principes de développement sécurisé (global et non plus basé sur l’OWASP Top 10) ;
• Partage global de l’information par le biais de Twitter, de blogs, etc. ;
• Changement de l’organisation des équipes avec la création de teams plus petites et plus concentrées sur un développement plus morcelé, axé par fonctionnalité ;
• Création par Realex d’une nouvelle société, Carapay, l’occasion de tester la portabilité de la méthode développée par Realex ;
• Début d’utilisation des « méthodes agiles » ;
• automatisation plus poussée, notamment grâce au développement d’un plugin Eclipse de revue de code.
Cette méthode a été portée avec succès vers le développement de l’application mobile de Realex.
Le retour d’expérience significatif de Realex et Security Ninja permet de prendre conscience de certaines règles à suivre :
• Il est nécessaire de collecter des métriques dès le début du projet, afin de pouvoir en qualifier précisément l’évolution ;
• Il semble envisageable de commencer l’implémentation du SDLC durant la phase d’audit de code ;
• Tous les développeurs sont volontaires pour se former à la sécurité des applications, les formations, même internes sont indispensables ;
• Il est recommandé d’éviter les outils bureautiques dans la vie quotidienne du projet et de favoriser les bases de données et autres médias indexables ;
• Il faut se baser sur les retours des services marketing et quality assessment pour porter leurs vecteurs de réussite vers la branche d’application security.
Comptes rendus rédigés par Geoffrey Bertoli, Brice Duprieu et Yannick Fournel.
Relus par Isabelle Feetz.
