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 ?
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.
- 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") ;
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 ;
É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.
Aucun commentaire:
Enregistrer un commentaire