Retours sur BlueHat Fall 2009

Mon 02 November 2009 by JB

Voilà un résumé des conférences que j’ai pu voir à BlueHat, les 22 et 23 octobre 2009. Les conférences qui m’ont moins intéressé ne sont pas résumées ici. En particulier, la demi-journée sur le Cloud Computing est mise de côté, par manque de compétences pour les comprendre et d’intérêt pour le sujet.

The language of Trust: Exploiting Relationships in Active Content - Ryan Smith, Mark Dowd, David Dewey

Une très, très bonne conférence, dont le compte-rendu a déjà été fait. La présentation a été assurée par Ryan Smith et David Dewey, contrairement à HITB où seul Mark Dowd était présent.

Tavis Ormandy, Neel Mehta - Making software dumber

J’ai été très déçu par le contenu de cette présentation. Les speakers ont commencé par un historique du fuzzing, Ils montrent ensuite leur approche (« corpus distillation »). En gros, ils créent un corpus de fichiers / trames réseau de tests, récupérés principalement sur Internet, et considèrent l’entrée d’un programme comme des éléments d’un univers fini des lignes de code source, qui forment le programme.

Par exemple, une vulnérabilité a été trouvée sur le parsing de la réponse « Retry With » d’Internet Explorer. Ils ont récupéré une trame HTTP/ 1.1 449 Retry With d’un serveur IIS en crawlant, ont trouvé une vulnérabilité facilement exploitable dans IE (versions 4 à 8) en mutant légèrement la réponse.

Ça a l’air intéressant, mais vraiment trop peu de détails ont été donnés durant la conférence (ou j’ai raté quelque chose).

Tom Gallagher, David Conger - Under the Kimono of Office Security Engineering

La présentation portait principalement sur la mise en œuvre d’un outil de fuzzing distribué pour les outils Office.

Un bref historique tout d’abord : au départ, les principaux problèmes de sécurité sous Office étaient les macro-virus.Puis apparut LoveLetter en 1999-2000. Le ver était envoyé en pièce jointe et contenait un script VBS. Il se propageait en s’envoyant à tous les contacts de l’ordinateur infecté. Depuis, les pièces jointes exécutables sont automatiquement supprimés par Outlook.Aujourd’hui, la menace est liée aux exploits Word / Excel. Cette menace n’est vraiment apparue qu’à partir de 2006 d’après les auteurs.

Pour contrer l’exploitation de nouvelles failles, les auteurs ont développé un outil de fuzzing interne à Microsoft. Les problèmes majeurs résident dans le parsing des documents, évidemment. Et ça a l’air d’être l’horreur : plus de 300 formats de fichiers sont gérés, et il peut exister plusieurs parsers par types de fichiers…

Un outil de fuzzing existait déjà. Chaque équipe de développement ne pouvait alors tester qu’un sous-ensemble des formats supportés. On ne savait pas vraiment combien de tests étaient réellement effectués, les doublons étaient difficiles à identifier. On ne savait pas quels ordinateurs étaient disponibles pour les tests.

Les détails techniques sur les méthodes de fuzzing utilisées ne sont pas expliqués. La présentation porte plus sur les aspects pratiques mis en œuvre pour que le fuzzer soit facile à utiliser :

  • Il n’y a que 3 boutons : « Start », « Stop » et « Stop now » !
  • Le fuzzer se lance sur n’importe quelle machine sur laquelle est installée Office.
  • Lorsqu’un crash est trouvé, il est remonté à un serveur central. Celui-ci détecte les doublons, et logge le crash dans une base de données. Les résultats sont visibles en temps réel. Les problèmes sont caractérisés, et le contexte du processus est stocké dans la base de données pour que les développeurs puissent identifier le problème.
  • Les ressources inutilisées sont détectées, et peuvent être utilisées par n’importe quelle équipe.
  • Il y a un héritage entre les fuzzers : quand un bug est détecté dans un des fuzzers parents, il est donc automatiquement corrigé dans les fuzzers fils. Il semble donc que le fuzzing ne fasse pas que des mutations aléatoires sur une série de fichiers.

Les développeurs ne cherchent pas à savoir si un bug est exploitable ou non : ils le corrigent directement (ce qui prend moins de temps, et est plus sûr).

Ca a l’air intelligent, pratique, et très utilisé : plus de 500 millions de fichiers malformés ont été testés, d’après une capture d’écran du serveur d’administration.

Une dernière partie présentait les améliorations de sécurité d’Office 2010. Un nouveau module, GateKeeper, vérifie si les documents sont bien formés. S’ils ne le sont pas, les fichiers sont ouverts avec Office dans un mode protégé, sandboxé. C’est également le cas des fichiers arrivant par e-mail ou téléchargés sur une page Web. L’utilisateur doit ensuite valider le fichier pour pouvoir le modifier. Office 2010 est ensuite relancé en mode normal.GateKeeper rejette pas mal d’attaques inconnues : 82% sur Excel, 100% sur PowerPoint d’après les tests des développeurs.

Le fuzzer distribué m’a bien plu : il a l’air efficace, tout en ne pénalisant pas les utilisateurs. D’où son utilisation importante. Une approche intelligente.

Zane Lackey, Luis Miras - Attacking SMS

Une des présentations les plus intéressantes de la conférence.

Le terme SMS est utilisé pour différents types de messages : SMS, MMS, EMS, etc. Ils permettent de transporter plusieurs types de données, comme les images, les vidéos et les sonneries. La présentation porte sur l'attaque de téléphones via les SMS.

Il s'agit d'envoyer des SMS malformés au téléphone. Pour cela, il faut éviter de passer par le réseau GSM : ça coûte cher, et c'est trop lent. Les attaques sont donc lancées sur le téléphone via des commandes AT.Les tests ont été faits sur de vieux téléphones, car ils écrivent directement les PDU (protocole description unit) dans la carte SIM. On peut ensuite retirer la carte SIM et l'analyser.

Quelques vulnérabilités détectées :

  • Une vulnérabilité dans le parseur des UDH (User Data Header, qui contient les informations sur le SMS envoyé) des Android crashait le processus com.android.phone. Il n'était alors plus possible d'envoyer ou de recevoir des SMS ou des appels.
  • Une attaque assez violente avec les messages de service sur certains téléphones Windows Mobile (HTC en particulier, apparemment) permet d'exécuter du code directement sur le téléphone. Ces messages sont normalement utilisés par les opérateurs pour avertir l'utilisateur de mises à jour logicielles, ou pour installer des mises à jour silencieusement. On envoie donc des messages de type WAP Push SL ("Service Load") au téléphone, contenant l'URL d'un binaire à exécuter. Ce dernier est exécuté sur le téléphone de l'utilisateur si la politique de sécurité n'est pas configurée correctement sur le téléphone. Il ne s'agit pas d'une vulnérabilité, mais d'une mauvaise configuration du téléphone.
  • Enfin, les conférenciers pensent, à juste titre, que les messages d'alerte envoyés aux utilisateurs doivent être plus explicites. Ils montrent un exemple de SMS de service changeant les paramètres OTA ("Over the air") du téléphone. Le message affiché sur le téléphone est "New settings received. Install?"… Que feront les utilisateurs face à un tel message ?

Une présentation assez didactique, sur un sujet qui est loin d'être complètement exploré.

Josh Lackey - Mobile Security and Software Radio

Josh Lackey explique comment, dans la théorie, intercepter des trames GSM, et surtout les problèmes qu'il rencontre.

En fait, chaque trame GSM est transmise en 4.6ms. Les tours GSM ont des fréquences variables, et le téléphone change parfois de tour à chaque émission. Il est alors très difficile d'intercepter le signal si on ne connaît pas l'algorithme de changement de fréquence.Le signal intercepté est chiffré. Deux algorithmes sont utilisés : A5/1 et A5/2, selon les régions. Dans certains pays, il n'y a même pas de chiffrement. Josh affirme qu'en France les SMS ne sont pas chiffrés, ce qui est faux.Si A5/2 est cassable en temps réel, ce n'est pas le cas pour A5/1. On peut créer en revanche des rainbow tables permettant de déchiffrer la communication après l'avoir interceptée. Le projet A5/1 cracking projet est dédié à cela. Le cassage par GPU permet de tester 162 millions de clés par seconde, ce qui permettrait, avec des tables de 2To, de casser le chiffrement en 2h. Le problème est qu'il faut un budget d'environ 3 millions de dollars pour générer de telles tables.

Une seconde partie montre comment trouver des failles d'implémentation sur les téléphones, en attaquant les couches basses avec des logiciels radio (GNUradio) et une fausse BTS (avec OpenBTS).

Enfin, une dernière partie montre comment attaquer l'infrastructure. Un exemple est montré avec un iPhone. Celui-ci se connecte à la BTS de Josh. Toutes les autres BTS disparaissent. Josh contrôle alors les émissions sur le téléphone, et envoie un faux appel de Steve Ballmer, et un SMS du 911. Marrant.

C'était une fois de plus une bonne présentation, pas d’un très haut niveau technique mais intéressante. Son contenu ressemble fortement aux travaux de mon voisin de bureau ...

Charlie Miller - iPhone: Fuzzing and Payloads

Charlie Miller a résumé deux présentations : "Fuzzing the phone in your phone", et "Post exploitation bliss, meterpreter for iPhone". Cela a donné lieu à une conférence assez dense.

Cela commence par un rappel sur l'iPhone et ses protections, ainsi que sur les attaques existantes sur les différents firmwares. Ensuite, il explique comment il a mené ses attaques. Quand un SMS arrive sur le téléphone, il envoie une commande AT contenant le numéro, la longueur et le contenu du message. Il se place donc entre le canal du port applicatif et celui du modem, et cherche à crasher le téléphone en fuzzant le User Data Header. Le fuzzing est effectué avec Sulley.Il explique ensuite comment exploité une vulnérabilité qu'il a découverte, en envoyant 519 SMS à un téléphone. Il vaut mieux regarder les slides pour se faire une idée, l'explication serait bien trop longue pour un article de blog (notamment la manipulation du heap, et un mini heap feng-shui via des SMS…).

Enfin, une dernière partie explique comment porter meterpreter pour l'iPhone. Sur ce téléphone, une page mémoire marquée en écriture ne pourra jamais avoir les droits d'exécution. Il faut donc recopier toutes les pages en écriture dans d'autres zones mémoire exécutables.

Au final, la présentation aura montré comment manipuler le heap (difficilement, mais c'est faisable), fuzzer des SMS sur un réseau local, et lancer un shell via meterpreter sur un iPhoneOS 2.2.1. Ce qui, en 50 minutes, n'est pas facile à digérer.

Patrick McCanna - Mobile Operator Security: Security Challenges for Global Networks for Pocket-sized Devices

Cette présentation était la moins technique de la journée. Le point de vue adopté est celui d'un responsable de la sécurité chez AT&T. Un point de vue, donc, très défensif.Pour eux, il y a deux choses à protéger sur le réseau téléphonique :- la vie privée du client ;- la disponibilité du réseau.Patrick McCanna détaille ensuite les problèmes de sécurité potentiels sur le réseau. Si certains, comme les services IP, sont des problème classiques (Firewalls, DMZ, etc.), d'autres sont particuliers, et sont en général plus compliqués à régler. Il détaille notamment les problèmes dus à la sécurité des terminaux mobiles.

Le but ultime serait d'obtenir un framework de sécurité pour tous les terminaux, afin de protéger l'accès aux informations sensibles (localisation, carnet d'adresse, données de la SIM). Malheureusement, les terminaux possèdent des architectures différentes, des utilisations différentes. Ce n'est pas gagné…

Les SMS sont également un problème : AT&T en traite 60000/s. Les IPS ont du mal à suivre. Ce sont surtout les User Data Headers qui posent problème. De plus, les SMS ne sont pas toujours transportés par IP, et là, les IPS ne peuvent rien voir.

La sécurité des terminaux est un enfer : quand une vulnérabilité est découverte, il faudrait pouvoir mettre à jour tous les téléphones de son parc. Pour cela, il faut être sûr que la mise à jour fonctionne parfaitement, ce qui impose des durées de tests conséquentes.

Patrick prend le cas d'une vulnérabilité dans la gestion des SMS. Il faut vérifier si la vulnérabilité existe vraiment. Puis, vérifier si elle n'est pas spécifique à un opérateur ou à un constructeur. Ou au réseau…Que faire ?- Filtrer au niveau réseau ? Il est clair que ça n'est pas une bonne solution.- Patcher le terminal ? Cela a donné lieu à de très mauvaises expériences : des téléphones ne marchaient plus après la mise à jour, etc.- Remplacer tous les terminaux affectés ? Ça coûte cher, et il faut patcher tous les terminaux de remplacement.- Ne rien faire ? Non, ça ce n'est pas possible !

La solution la moins pire consiste à patcher le téléphone. Si le déploiement via FOTA ("Firmware over the air") ne fonctionne pas, il faut demander à tous les utilisateurs de patcher eux-mêmes. Les utilisateurs n'ont pas tous une connexion data illimitée : ils doivent donc payer pour télécharger la mise à jour. Enfin, on ne peut pas forcer un utilisateur à mettre à jour son téléphone : le problème est le même que sur les ordinateurs. Bref, c'est un casse-tête …