[HITB COnference] Day 2

La première journée était riche en vulnérabilités et exploitations. Après avoir visité un peu Amsterdam (non non, je ne faisais pas partie du groupe parti pour la zone rouge) avec notamment la visite de la maison d'Anne Frank (tout de suite, c'est moins sexy ;). Je n'ai pas assisté au deuxième keynote mais voici la suite des conférences que j'ai suivi.

Conf 1 - SAProuter, An Internet Window to your SAP platform - Mariano Numez di Croce

Fidèle à mon aventure sur SAP, voici la dernière conférence sur le sujet. Cette conférence se concentre sur le composant SAP Router et était très pratique puisqu'après une présentation de SAP, une démonstration de l'attaque par étape nous a été présentée. Pour ceux qui ne connaitrait pas bien SAP, je vous renvoie vers le résumé de la formation qui a eu lieu les deux premiers jours du HITB (résumé 1 et résumé 2).

Il faut rappeler avant tout que le SAP Router a pour rôle de filtrer les requêtes (couches 3 et 4), de tracer les connexions, d'appliquer une sécurité sur les flux (avec une clé partagée) et de sécuriser les flux (avec SNC).

Pour le filtrage des requêtes, une table permet de définir les flux autorisés, interdits et limités (ie, seuls les flux ayant pour protocole SAP sont autorisés). Première faille potentielle : les administrateurs, dans la vraie-vie, finissent souvent leur configuration par un "j'autorise tout". En effet, sur la base d'une liste blanche, les administrateurs n'ont pas toujours le courage d'entrer tous les accès et sachant qu'il faut que ça marche à tout prix ...

La démonstration a été réalisée à l'aide de l'outil BIZPLOIT (dont le speaker est le principal développeur). L'attaque se déroule en plusieurs étapes :

• phase de découverte : on recherche le port utilisé par le SAP Router. Par défaut, le port TCP/3299 mais nous vérifions à l'aide du module "discover" ;
• phase de découverte interne : le plugins saprouter spy nous permet de connaître les ports ouverts sur la machine comme si nous y étions ! Intéressant ;
• l'attaque consiste a utilisé le SAP Router en tant que proxy. Nous trouverons cette fois des infos sur la solution SAP (ex : version) ;
• Puis, on utilise le plugin de bruteforce pour trouver des comptes valides (e.g. mots de passe par défaut ou triviaux) ;
• On utilisera l'exploit saprouterAgent pour obtenir une connexion sur le SAP Router ;
• Enfin, c'est grâce à l'outil tsocks que notre trafic sera redirigé vers le proxy mis en place et que nous pourrons attaquer le système SAP comme de l'intérieur.

Une démonstration convaincante qui montrer les risques d'une mauvaise sécurisation de sa plateforme SAP. Les solutions de correction existent cependant :

• l'application des patches (pas toujours évidente malheureusement) ;
• l'application de la sécurité sur les connexions (nombre de connexion maximum, chiffrement, etc.) ;
• la politique de mot de passe pour les clients ;
• la généralisation des messages erreurs pour éviter l'affichage d'information technique.

Conf 2 - Firefox 4 and Opportunities for security research - Chris HOFMANN

Je ne m'étendrais pas sur cette conf qui n'avait pas tout l'intérêt attendu. L'idée est de lancer un "Bug Bounty Program". plus précisément, il s'agit de récompenser les personnes qui découvrent des bugs sur la prochaine version de Firefox (Firefox 4 donc). Cela existe déjà en réalité mais l'accent est mis sur le sujet pour motiver les chercheurs potentiels en leur octroyant une prime plus importante (3.000$). Cependant, le bug doit remplir plusieurs conditions comme conduire à un exploit distant. Problème : les marchés noirs offriront toujours plus. Néanmoins, souhaiteriez vous fournir des armes à des black hats, même pour de l'argent ?

Finalement, Mozilla estime que s'il ne paye pas pour la recherche des bugs maintenant, ils paieront plus cher d'une manière ou une autre la découverte des bugs. Ceci est vrai pour tout logiciel mais rarement considéré ... Dans le même temps, Mozilla a pour objectif d'assurer la sécurité de ses utilisateurs. De plus, la fondation en question veut se donner les moyens de faire face aux bugs :

• en assumant les bugs potentiels ;
• en motivant les chercheurs à trouver ces bugs ;
• en les corrigeant rapidement.

Il s'agit d'un réel défi car Firefox 4 bénéficiera de nouvelles fonctionnalité (tels qu'un parser HTML 5) qui pourront aussi représenter de nouveaux vecteurs d'attaque ...


Conf 3 - XProbe-NG, Building Efficient Network Discovery Tools - Fyodor YAROCHKIN

Il existe déjà beaucoup d'outil de découverte. Alors pourquoi un nouveau ? Celui proposé par Fyodor, déjà existant (Xprobe), est de tenir compte de la vraie-vie, des attaques qui ont lieu sur le Net. Ce tool de fingerpringting a aussi pour but d'étendre son action à la couche applicative pour combiner la collecte d'information aux couches réseaux et applicatives. Enfin, cette nouvelle version a pour vocation d'enrichir la version précédente à l'aide de scripts et de données échangées.

Plusieurs défis sont alors engagés pour réussir ce pari. Notamment, il faut :

• limiter le temps de traitement des couches réseaux, la couche applicative étant gourmande en interprétation ;
• être suffisamment rapide pour analyser les flux en temps réel (ou presque), ce qui pourra se faire avec un nouveau moteur.

L'outil, écrit en Python, utilise le principe de scoring et de prioroté pour traiter les informations les plus importantes en premier lieu. Ensuite, une autre solution consiste à ne lancer les modules d'analyse que quand ils sont nécessaires.

Au final, XProbe-NG va réaliser différents tests applicatifs comme analyser les séparateurs de répertoire, les fichiers spéciaux dans les répertoires, la sensibilité de la casse, etc ... pour différencier un Linux d'un Windows.

D'autres améliorations sont prévues pour permettre à cet outil de se démarquer. Une première version sera disponible la semaine prochaine à cette adresse.


Conf 4 - Top 10 Web 2.0 Attacks and exploits - Shreeraj SHAH

Lors de cette conférence, le speaker a pris en compte le Top 10 des vulnérabilités liées au WEB 2.0 en se basant sur l'OWASP. Voici le classement :

• 1) DOM Based XSS (Ajax) ;
• 2) SQL Injections (SOAP / XML) ;
• 3) Blind SQL over JSON/AMF ;
• 4) XPATH Injection ;
• 5) Business logic bypass ;
• 6) Decompilation Attack (ex : SWF) ;
• 7) WSDL ;
• 8) XSS with Flash ;
• 9) CSRF with XML ;
• 10) Widget / Marshup.

Une description et une démonstration a été réalisée pour chacune de ces attaques. Tout expliquer demanderait donc un billet à lui tout seul (au moins) mais cette présentation intéressante appelle notamment à la veille que nous devons réaliser en tant que pentesters sur ces nouvelles attaques. En effet, de nombreux sites sont touchées par ce type de vulnérabilités encore mal connues des développeurs.


Conf 5 - The travelling Hacksmith 2009/2010 - Saumil SHAH

Une présentation particulière qui ne manquait pas d'intérêt et qui en a fait rire plus d'un : il ne devait pas y avoir d'opérateur wifi ni d'agent d'opérateur de voyage dans la salle ...
Je m'explique ! Le speaker nous raconte qu'il voyage beaucoup et que tout se paye et souvent cher comme les connexions WiFi dans les chambres d'hôtel.

A travers les différents voyages et hôtels visités, Saumil nous montre comment il a réussit à obtenir un accès Internet gratuit ou moins cher. De la modification du numéro de chambre dans la requête au contrôle de la passerelle en passant par les injections SQL, aucun accès ne lui a résisté ;)

Ensuite, il s'attaque aux billets d'avion dans le but d'être surclassé. Il réussit à plusieurs reprise en modifiant son numéro de place dans le choix des places au check-in sur Internet.

Enfin, sur un site de réservation d'hôtel que je ne dois pas citer et que je ne ferais donc pas, il est possible de réserver et d'annuler sans payer de frais : sauf que l'annulation se fait sur le jour précédent de l'arrivée ! A voir si ça marche toujours ?


Et c'est la fin de cette conférence ! Ces 4 jours auront passé bien vite mais il est temps de sortir de Hackerland et de retrouver son chez-soi : enfin, si le Thalys arrive, déjà 30 minutes de retard ...

[HITB Conference] Day 1

Un petit retour sur cette première journée de conférence au HITB d'Amsterdam où l'ambiance est très bonne, l'hôtel cool (sauf pour y dormir apparemment ?) et les HITB girls sont ... sociables ! D'ailleurs, à quand les SSTIC girls ?

Keynotes - Dr Anton CHUVAKIN - Security Chasm

Cette conférence me rappelle un talk donné par Nicolas RUFF l'année dernière au SSTIC. En effet, une idée dans tout ça est de montrer l'échec de la sécurité depuis les années 90.

Tout d'abord, on a traversé plusieurs période de la sécurité en déplaçant le problème finalement à chaque fois. Tout d'abord, la sécurité était portée sur les ordinateurs, puis sur les réseaux, puis sur la prévention, puis sur la conformité et les normes, etc ...
En parallèle, nous avons voulu couvrir les risques locaux dans un premier temps puis les menaces extérieures (avec le pare-feu à tout va) puis la détection des attaques (mode des IDS/IPS) puis, plus récemment, le cybercrime et pour en arriver maintenant à la période des clouds.

Le problème, selon le conférencier, le manque de cohérence dans tout ça. Il y a d'une part ceux qui conseille de faire de la sécu et fournissent les recommandations alors qu'ils ne touchent pas au matériel (l'auditeur ne maitrise n'a jamais administré d'IPS qu'il va conseiller de configurer de telle ou telle manière par exemple pour mieux protéger le réseau) et d'autre part, nous avons les personnes qui appliquent la sécurité parce qu'il le faut bien ou parce qu'on leur demande, pas par conscience des risques.

Alors pour résoudre cela, plusieurs lignes de conduite nous sont fournis. A titre d'exemple, les normes peuvent être bénéfiques mais seulement pour mettre encadrer la mise en place de la sécurité dans un SI, pas pour avoir l'étiquette "compliant" notamment.

En fait, selon l'orateur, si une entreprise n'est pas en mesure d'assurer sa sécurité en 2020, elle mourra car un attaquant aura d'ici là toutes les armes lui permettant de mettre fin au business d'une entreprise.


Conf 1 - John 'Kanen' Flowers - Introducing Kane |Box

L'orateur part du principe que la sécurité ne fonctionne pas pour diverses raisons : elle coûte chère, les outils sont souvent contournés et cassés et les façons de penser et de "faire de la sécurité" n'ont pas évoluées depuis des années. A l'inverse, les outils de hacking sont souvent libres et les compétences des attaquants ne cessent d'évoluer.

Et c'est là que l'orateur à la bonne idée : proposer une solution de sécurité qui n'est pas seulement un nouveau logiciel mais un boitier "clé en main". Pour avoir travailler dans la sécurité, vous allez me dire que ça existe déjà : de nombreux éditeurs en proposent ... oui mais à quel prix ? A 475$ vous en connaissez combien ? En effet, c'est le prix de base d'un boitier Kane|Box. Et même, pour ceux qui ont l'âme d'un bricoleur, le code est libre et il ne vous reste plus qu'à monter le boitier.

L'auteur n'était donc pas là pour vendre sa marchandise mais pour fournir une solution complète et tout à fait abordable ; ce qui résout les problèmes actuelles pour implémenter la sécurité.

Et que permet de faire cette solution ? C'est une virtual box rassemble les caractéristiques suivantes :

• un module d'exploitation (sniffer + analyseur de paquets + crackers de mots de passe + scripts d'exploitation) ;
• un module de détection (pour la détection d'attaque réseau) ;
• un pare-feu (permettant d'inspecter les paquets et de les bloquer) ;
• un routeur (pouvant bénéficier de règles de filtrage) ;
• un mode host-based (pour collaborer avec les anti-virus et les pare-feu des machines).

L'idée est bonne et il serait intéressant de voir ce que cela pourrait donner en pratique.
En attendant, je vous invite à voir la page du produit pour plus d'info.


Conf 2 - Alexander POLYAKOV - Attacking SAP Users with SAPSPLOIT

Je continue mon aventure sur la sécurité de SAP (cf. traning1 et training2). Ici, l'orateur part du principe que le système SAP est correctement sécurisé et que les vecteurs d'attaque sur le système (OS, DB, appli, services additionnels) ne sont pas exploitables depuis notre point d'attaque. Ce qui, pour une version récente de la plateforme serait envisageable. Du moins, admettons.
Alors, le vecteur d'attaque sera l'utilisateur. En effet, c'est lui qui aura les permissions appropriées pour ce connecter au serveur SAP et une fois son poste de travail compromis, nous aurons la possibilité de nous attaquer au cœur de notre cible. De plus, les utilisateurs sont nombreux donc plus de chance de succès.

L'utilisateur se connecte au serveur SAP via le client SAPGUI. Premier point : les flux ne sont pas toujours chiffrés et seulement compressé au mieux (XOR avec une clé connue, base64, ...).
Deuxième point : SAPGUI est vulnérable à un certain nombre d'attaques :

• a) SAPGUI utilise des activeX et alors, les vulnérabilités concernant ce dernier sont aussi valables pour notre cible (ex : des buffer overflows sont réalisables). Aussi, les activeX permettent des intéractions avec les fichiers enregistrés sur le serveur : et si on changeait la configuration du serveur pour supprimer des protections ? Enfin, il est possible d'exécuter des commandes système ou de déployer un cheval de Troyes.
• b) Une fois le client compromis, il est possible de retrouver des données intéressantes sur la machine de la victime. Par défaut, nous les retrouverons dans le répertoire c:\windows\sap.
• c) D'autres attaques souvent prometteuses peuvent être menées sur le client : XSS (stored XSS notamment dans une fonction d'upload), phishing, XSRF, etc ...
• d) Il est même possible d'obtenir un shell en uploadant une page HTML dans une fonction d'upload du client.

Afin d'empêcher ce type d'attaque, voici quelques recommandations fournies par Alexander :

• Effectuer les mises à jour nécessaires : les dernières versions sont bien mieux protégées ;
• Tester la force des mots de passe des clients et appliquer un seuil d'échec pour la tentative de connexion ;
• Quelques configurations au niveau de la clé de registre permettent de mieux sécuriser le client ;
• Attention, à minuit, une option permet de délocker tous les utilisateurs ! A supprimer.

Des infos supplémentaires peuvent être trouvées ici.


Conf 3 - Laurent OUDOT - Web in the Middle - Attacking Client

La première conférence de l'après-midi nous parlait d'attaque de type MiTM que nous connaissons tous mais d'un type plus particulier qu'on appellera WiTM. En fait, il s'agit ici d'opérer sur des réseaux publics et si pensez réseaux Wi-Fi ... vous pensez juste !
En face, nous avons tous les appareils mobiles capables de se connecter via le Wi-Fi. En particulier, nous avons les smartphones et tout objet qui se croque ( [Début private joke] Oui Fred, j'ai décidé de reprendre le concours d'hier [Fin private joke] ;)).

J'ai retenu deux idées principales pendant la conférence :

• Lors d'une communication dite sécurisée via SSL, toutes les requêtes ne sont pas toujours envoyées de manière sécurisée. En effet, de la page de login à la déconnexion de l'utilisateur, nous pouvons retrouver des requêtes HTTP. Cela peut concerner notamment les pages de déconnexion ;
• Nous pouvons modifier le user-agent dans nos requêtes et voir le comportement du site WEB qui peut être différent pour certains.

A partir de ces deux idées, cela a donné naissance à des 0days que nous a présentés le speaker. Les références associées sont les suivantes :

• CVE-2010-1752 qui concerne l'iPhone ;
• CVE-2010-0028 qui concerne le navigateur du HTC (Opera) ;
• CVE-2010-0027 qui concerne les blackberry (vulnérabilité dans le "hotspot browser") ;

La démonstration réalisée en live concernait une dernière vulnérabilité touchant cette fois l'iPad. Une vulnérabilité dans son navigateur (Safari) permet de le crasher pour l'instant et peut être plus plus tard.

Il y a certainement eu un très gros travail derrière tout ça pour trouver et exploiter les vulnérabilités. Malheureusement, aucune explication n'a été fournie sur celles-ci. Aucun point technique n'a été abordé non plus. Même si cela se comprend vis à vis des constructeurs, cela a enlevé du piquant à la présentation.


Conf 4 - Niels TEUSINK - Owned Live on Stage: Hacking Wireless Presenters

Pour le coup, la présentation qui a suivi a été très explicite dans son explication et sa démonstration ! De plus, il s'agit là d'un sujet tout à fait original : le hacking à travers les périphériques sans fil !

A priori, tout périphérique sans fil pourrait nous servir entrer en ligne de mire. Tout d'abord, nous connectons via USB un périphérique sans fil (un appareil Logitech R-R0001 pour la présentation) sur deux PCs différents. Un des PC représente la machine de l'attaquant et l'autre, celui de la cible. Et vous avez bien compris, nous allons tenter de faire communiquer les appareils sans fil entre eux pour compromettre la machine cible !

Je vous passe les détails techniques de ces attaques physiques : il ne s'agit tout simplement de mon domaine et ne suis pas en mesure de vous apprendre quelque chose à ce sujet. Cependant, la technique d'attaque consiste dans un premier temps à sniffer via le BUS avec le matériel adéquat. De l'autre côté, le speaker choisit un appareil sans fil un peu différent. Pour résumer, le but va être de trouver le bon canal de communication qui nous permettra de communiquer entre les deux appareils. Une fois le canal trouvé, les appareils sont "liés" et là, le speaker nous montre ce qu'il est possible de faire : un connect-back sur du VNC sur la machine cible. Je peux juste vous confirmer que ça a bien marché pendant la démonstration ! C'est assez terrifiant non ? Et là, ce n'est pas une souris sans fil que vous tenez sous la main ? ...

Aujourd'hui, la sécurité n'existe pas pour les périphériques en question : il est donc important de créer un protocole sécurisé et d'utiliser une cryptographie fiable afin d'éviter des attaques de ce type.


Conf 5 - Tamas RUDNAI - Fireshark

Le speaker nous présente ici un plugin de Firefox. Un de plus ! Mais particulier celui-ci puisqu'il permet de cartographier les sites infectés par les malwares. Pour cela, le plugin visite les pages web et collecte les informations dont il a besoin (code source, redirections, screenshots, etc.).
Un autre but est de désobfusquer le code, ce qui permettra d'étudier les malwares rencontrés sur les sites.

L'outil peut fonctionner selon deux modes :

• le Network mode : ou mode automatique ;
• le Single-user mode : l'utilisateur choisit les sites qu'il souhaite inspecter ;

La dernière fonctionnalité qui n'a pas été évoquée est le post-processing. Le but est de pouvoir analyser un malware à partir des preuves collectées précédemment.

Étant donné que les malwares sont de plus en plus nombreux, ce plugin a tout à fait sa place au sein des outils d'un chercheur. En effet, outre le rôle de prévention (en évitant ainsi de visiter des sites contaminés), l'analyse des malwares permet de mieux comprendre les nouvelles attaques et d'en trouver les contre-mesures.


Fin de cette première journée. La suite dans le billet suivant.