Quantcast
Channel: Devoteam Blog, specialist talk point » French
Viewing all articles
Browse latest Browse all 10

Hack in Paris – Jour 2

0
0

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 nous informant que malgré une augmentation des moyens de défenses, il y a eu une augmentation de 47% de pénétrations en 2012. Il liste ensuite quelques-uns de ces types de produits et le temps qu’il faut pour les contourner :

  • NextGen Firewall : 4 minutes
  • Web Application Firewall : 1 heure
  • Analyse comportementale : 30 secondes
  • White et black listing : 30 secondes
  • Antivirus, DLP, Content Filtering : 0 secondes, 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émonstration, il apparait donc qu’il est relativement facile de déjouer ces méthodes de défense, malgré une multiplication des produits. Il met en avant la définition de l’absurdité : faire encore et toujours la même chose et attendre 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 la culture pour une basée sur la sécurité, incluant l’éducation et la sensibilisation des collaborateurs, en voyant la sécurité comme un « business enhancer ».
  2. 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 et faire le point à la fin de cette année sur ce qui a été utilisé ou non.
  3. Focalisation sur les bases : les principales menaces ne sont pas les 0day et les APT mais bien les mots de passes par défaut et les XSS par exemples.
  4. La détection et la surveillance : cela ne marche pas à 100%, mais est tout de même nécessaire.
  5. Faire des tests d’intrusion manuelle. Il regrette qu’aujourd’hui il y ait une commercialisation de l’automatisation

Il nous invite donc à prendre un peu de recul afin de réfléchir à ce que nous faisons afin de le simplifier, citant la lecture de Rework (Jason Fried et David Heinemeier Hansson, 2010) comme une bonne source d’inspiration.

A case study in same origin policy implementation

Frederik Braun

Les Same Origin Policies (SOP) ont pour objectif d’éviter l’inclusion d’une page web malicieuse 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 apportait 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.

SOP est souvent considéré 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 (e.g. : http://), le hostname (e.g. : www.devoteam.com) et le port (e.g. : 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 constituer aucune origine valide, mais est cependant conforme à une SOP. La raison en est historique, expliquée par le besoin de pouvoir ouvrir des pop-ups vides et 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 entrainait 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 entrainait une erreur de traitement par Flash et une mauvaise évaluation des origines

Ces erreurs consistent globalement en 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 SOP, mais tous semblent difficilement exploitables à court terme.

Les SOP-bypass pourraient par exemple être réduits par l’utilisation des meta-données allow-values (dans le modèle CSP, permettant de spécifier une whitelist des adresses depuis lesquelles le contenu est chargé). Cependant, 96% des sites du Alexa TOP10000 incluent du javascript directement dans le corps de la page. Encore un fois, la sécurité serait moins mise à mal si les best-practices étaient mieux respectées dans les phases de développement.

La recommandation principale pour éviter ces problématiques de 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 domain googleusercontent.com).

Ces SOP sont donc très inconsistantes et diffèrent pour chaque vendeur. Elles représentent, 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 au 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 : une mise à disposition de machine de manière rapide et facile, le retour arrière, la consolidation et le contrôle des ressources, et 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 et 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 cout de la consolidation des ressources. Il cite également la physicalisation, avec Barebox comme exemple. Cependant il existe quelques contre-contre-mesures, comme Nether.

L’orateur pense que la prochaine grande étape de la virtualisation sera 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 ici : http://aurelien.wail.ly/publications/hip-2013-slides.pdf

HTTPD logfile security analysis

Jens müller

Jens Müller présente une étude de cas à laquelle il a pu répondre grâce à LORG, un outil développé pour l’occasion.

Le point de départ de sa réflexion vient du manque de solution de log management, log analytics ou forensics dédiée au traitement poussé des logs de solution web (waf, ids, web server 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 des attaques à l’encontre des frontaux web.

La première approche à la fiabilisation des logs consiste en l’association de techniques basiques telles que l’analyse de regex, les statistiques de répartition des caractères et autres fonctionnalités reproduisant, globalement, un 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.

La seconde approche est basée sur l’apprentissage machine, notament par la recherche de chaines de Markov par aggrégation, conversion, phase d’apprentissage etc…

Après expérimentation de ce modèle par l’évaluation de 63k requêtes (considérées saines) dans lesquelles ont été injectés 40 exploits, répartis dans des urls de différentes web apps, il s’avère que le nombre d’éléments est 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 permetde filtrer les informations et réaliser des visualisation permettant d’identifier des tendances globales dans le trafic observé.

L’outil, en phase de prototypage, nest pas utilisable dans toutes les situations, puisqu’il est notamment vulnérable à de l’obfuscation des vecteurs d’attaque ou l’utilisation de vecteurs non visibles dans les logs, mais 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

Le speaker est espagnol, il 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 : C’est un programme qui permet de faire de l’instrumentation (monitoring) de binaire au cours de son exécution. Les avantages sont : compte tenu que l’on analyse le binaire, c’est indépendant du langage de programmation, et on peut faire fi des licences, en monitorant des binaires propriétaires. En revanche il y a une grosse perte en performance et le fait que l’analyse soit dynamique implique qu’on ne peut analyser l’ensemble des possibles (l’ensemble des traces symbolique) mais uniquement les traces qui seront exécutées.

Ricardo a ensuite fait un comparatif de 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 meilleure utilisation de la mémoire et une rapidité d’action, Pin est le plus performant alors que Valgrind a des résultats lamentables.

Ensuite, il a montré comment en utilisant PinTools il a réussi à trouver des applications à la sécurité informatique. Il est notamment capable de détecter des Buffers Overflows. Sur un bref exemple il montre qu’en lançant un progamme monitorer par son outil, celui-ci remonte des alertes lorsqu’il détecte l’utilisation potentiels d’un « scanf » pouvant mener à une vulnérabilté. Si on 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 grosse connaissance en OS bas niveau car des API permettent de développer facilement. Par contre les performances sont 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 University à 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 Heiredrich commence sa conférence admettant que l’on parle beaucoup de HTML en ce moment mais que c’est 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 les DOM-XSS.

Il présente ensuite une propriété DOM, le element.innerHTML, que Microsoft a introduit il y a une dizaine d’années et qui sers à manipuler du contenu, principalement du texte. Très pratique et facile à utiliser (malgré le fait qu’il en soit pas vraiment compatible avec les <table> et le XML), cet élément est présent dans quasiment toutes les webapps qui manipulent du texte aujourd’hui. Le problème est que cette propriété n’est pas idépendante et est amenée à changer.

En 2007, Yosuke Hasegawa a découvert les prémisses des mXSS (mutant XSS), que l’orateur nous présente aujourd’hui avec 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 a l’intérieur des balises !

Le problème est qu’il existe beaucoup trop de variations et que même si l’utilisation du caractère d’échappement (‘\’) est bloquée, certaines injections marcheront sans, en utilisant une simple virgule… Enfin pour ne pas faciliter les choses, les mXSS fonctionnent de manière récursive.

Il propose tout de même quelques recommandations afin de se protéger, tel qu’utiliser du HTML5 strict (< !doctype html>), du CSP, des whitelists ; éviter le SVG et le MathML, les caractères étranges dans les attributs HTML ; patcher les filtres ; et connaitre ses vulnérabilités.

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 être vigilant pour les développeurs et qu’il y a de quoi s’amuser pour les pentesteurs.

Les slides de sa présentation sont disponibles ici : http://fr.slideshare.net/x00mario/the-innerhtml-apocalypse

The Realex payments applicationsecurity story, narrated by Security Ninja

Security Ninja (David Rook)

La clôture de cette troisième édition de Hack in Paris revient à @SecurityNinja, afin qu’il présente les travaux de sécurité mis en place autour de l’application de paiement de Realex.

La présentation commence par la distribution du support de diaporama… au format comic-book, ça s’annonce compliqué de prendre des notes.

David Rook raconte en fait son histoire commune avec Realex, de son arrivée en 2006, en qualité de Operations Security something, avant d’évoluer ver 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, les developpeurs vérifient l’absence de vulnérabilités présentes dans 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 250k lignes d’un code écrit, modifié, repris, 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 prise jusqu’alors ;
  • Début des formations sécurité au sein de l’entreprise ;
  • Début de l’automatisation des tests de sécurité par 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 et mise en évidence de défauts dans la méthodologie de remontée d’incidents ;
  • Mise en place d’une fonctionnalité de modélisation des menaces ;
  • Réalisation du premier audit externe de l’application, pas à des fins de compliance, mais d’identification 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 morcélé, axé 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 de 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 certains éléments critiques tels que :

  • le besoin de collecter des métriques dès le début du projet, afin de pouvoir 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 ;
  • se baser sur les retours des services marketing et quality assessment pour porter leurs vecteurs de réussites vers la branche d’application security.

Compte-rendus par Geoffrey Bertoli, Brice Duprieu et Yannick Fournel.


Viewing all articles
Browse latest Browse all 10

Latest Images

Trending Articles





Latest Images