Making network protocols go crazy

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - CanSecWest

Fil des billets - Fil des commentaires

lundi, avril 19 2010

Compte-rendu CanSecWest 2010 - jour 3

Friday March 26

08:30 - 09:00 Breakfast

09:00 - 10:00 Stuff we don't want on our Phones: On mobile spyware and PUPs - Jimmy Shah, McAfee, Inc

Chercheur en antivirus pour la mobilité. Les spyware sous plateformes mobiles : - adware : pas aussi intrusifs que sur PC - PUP : Potentially Unwanted Program, comme des serveurs Web ou FTP intégrés au téléphone. Mais aussi des programmes qu'une entreprise ne souhaite pas voir sur ses téléphones comme Metasploit, Aircrack, ...

En Indes, le gouvernement a demandé un accès de type spyware aux téléphone Blackberry. Ils ont aussi réduit la taille des clés de chiffrement de 256 bits à seulement 40 bits. Ils ont aussi obtenu que les serveurs Blackberry soient en Indes, pour pouvoir monitorer le trafic. Le gouvernement a aussi prétendu avoir cracké le chiffrement "non-corporate".

Etisalat a poussé une mise à jour sur les Blackberry. Un reverse engineering a montré que cette mise à jour intégrait du lawful interception. Une copie des mails était envoyée à une adresse Etisalat. Ce reverse a été simplifié puisque l'update était au format .JAR, au lieu du format .COD.

Une famille de vers iPhone (OSX/RRoll.A-B) modifiait l'image de fond et désactivait le démon SSH. L'auteur était Ashley "ikex" Towns.

Attention, certains spywares sont distribués via Android Appstore (cas d'une App de banking). Il existe aussi des Appstore alternatifs aux originaux, où le contrôle est difficile.

Présentation sans intérêt, j'ai arrêté de la suivre à la moitié. En gros, il fait un historique des recherches en développement spyware pour téléphones mobiles faites par d'autres, et présentées à BlackHat et autres conférences (Spyphone (iPhone), Phonesnoop (Blackberry)).

A noter aussi un PoC de botnet (WeatherFistBadMonkey), mais jamais releasé. Envoi des emails, fait du DDoS et fournit un reverse shell.

La présentation s'est achevée parce que l'ordinateur de l'orateur n'avait plus de batterie ... à 10 minutes de la fin. Un mec de l'organisation est venu l'aider pour rétablir le courant. Ça donne le niveau. Sur le mur tweeter de CanSecWest, les gens se lâchent sur la présentation. Je ne suis pas le seul à l'avoir trouvé pourri.

10:00 - 10:30 Second Breakfast

10:30 - 11:30 Practical Exploitation of Modern Wireless Devices - Thorsten Schroeder and (contributing) Max Moser, Dreamlab Technologies

Les gars sont du Dreamlab Technologies et de remote-exploit.

C'est un talk sur l'injection et l'écoute de données pour les claviers sans fils basés sur les fréquences 27 MHz. Keykeriki est un petit dispositif hardware, ils ont aussi fait le firmware. Le talk n'aborde pas l'infrarouge ou les technologies bluetooth.

Ça parle des communications en sens unique sur 27 MHz. Le protocole n'a pas de support pour le chiffrement (enfin c'est à la charge du fabriquant d'implémenter çà), et les messages ne sont pas protégés contre le rejeu. Ils ont reversé le protocole des claviers Logitech et Microsoft. Chaque frappe au clavier provoque l'envoi d'un paquet avec le keyboard ID, la touche, et l'état (appuie ou relâche).

Ils ont releasé la V1 de Keykeriki en may 2009, et il pouvait juste sniffer les claviers Microsoft, Seimens-Fujitsu et Logitech. Une SDCard pour le stockage des données, et du cracking à la volée du chiffrement. L'injection était limité, parce que certains bits du protocole n'était pas encore vraiment reversé.

Nordic Semi NRF24xxx permet d'avoir un receiver, et jusqu'à 6 appareils connectés (concept du multiceiver). Le protocole supporte un CRC (mais optionnel). Pour sniffer, il faut tout d'abord trouver l'adresse de l'appareil. Il faut identifier le préambule, et seulement ensuite on peut trouver cette information. Cette-ci est sur 5 bytes. et le préambule fait 8 bits. Un heuristique est utilisé pour trouver cette adresse, avec un certain niveau de False Positive. Keykeriki a une interface JTAG pour le débogage.

Microsoft utilise du crypto hardware AES-128 dans ses claviers. Ensuite, une explication sur les différents paquets et leur format. Les claviers Logitech utilisent aussi le chiffrement AES-128.

Note : certains appareils utilisés pour le vote sont basés sur ce genre de hardware. Certains appareils sont aussi présents dans les voitures.

Démo sur un clavier Micorosoft, remote command execution par injection de frappes clavier. Ce n'est pas du simple replay, ils ont implémenté les fonctions d'un vrai clavier. Injection possible jusqu'à 75 mètres ...

Ils ont l'intention de fournir une version gratuite et une version commercial du produit, ainsi qu'un module Wireshark. Toutes les infos sur http://www.remote-exploit.org/.

11:30 - 12:30 RFID Hacking at Home - Dr. Melanie Rieback, Vrije Universiteit Amsterdam

Elle bosse dans le lab ubisec, Security in Ubiquitous Computing. C'est le même genre de travail qui a été fait dans la présentation précédente.

Les menaces à prendre en compte : - lecture non autorisée - clonage - DoS - tracking - écoute

Existe-t-il des malwares pour RFID ? - exploits - vers - virus Via l'exploitation de buffer overflow dans le format des messages. Rien de connu pour l'instant.

Note : utilisation de Google Trend pour voir l'évolution d'un sujet (comme RFID malware).

Elle bosse sur un dispositif nommé RFID Guardian. Un dispositif mobile de pentesting et firewalling pour RFID. C'est un projet vendor-neutral, tout est disponible sur http://rfidguardian.org/. Le but est de montrer au monde que les RFID ne sont pas suffisamment sécurisés. Le dispositif coûte dans les 500 euros à fabriquer. Le bootloader est GPL. Ils cherchent des sociétés qui voudraient collaborer avec eux.

Fonctionnalités: - emulation de tag RFID - attaques de rejeu - attaques de relai - selective jamming - tag spoofing - RFID firewall (ACL) => n'autoriser que les bonnes personnes à accéder au tag RFID => mais ça n'empêche pas une personne d'écouter le trafic. - implémentation de SSL. Ça marche, mais c'est très lent - RFID fuzzing (Bstorm)

12:30 - 13:30 Lunch

Remise des prix de PWN2OWN, les gagnants se voient remettre un super laptop et un gros chèque de 10,000 CAD.

13:30 - 14:30 Advanced Mac OS X Physical Memory Analysis - Matthieu Suiche

Il a créé sa propre société MoonSols. Spécialisé dans le forensics. C'est notamment l'auteur du Sandman framework et de Windd.

Pourquoi ? La mémoire non-volatile ne suffit pas. Actuellement uniquement base sur x86 (32-bits) Mac OS X. Uniquement de l'acquisition basée sur du software. En hardware, le mapping mémoire n'est pas le même.

Accès à la mémoire physique : - soit accès au /dev/mem, mais c'est désactivé par défaut (et on ne peut pas rebooter, c'est du live forensics) => donc utilisation bcopy_phys() - soit utiliser l'hibernation (Safe Sleep)

Safe Sleep : créé une image compressée (format WKDM). Et peut éventuellement être chiffré (mais désactivable sans rebooter). Le but de l'analyse est d'éviter la recherche de chaine en mémoire de manière aléatoire. Méthodologie: - recherche des symboles kernel - initialisation du gestionnaire de mémoire - parcourir l'espace d'adressage virtuel du kernel - collecter l'information.

On obtient : - la liste des threads - les processus - information sur la machine - les descripteurs de fichiers - des informations réseau - des fichiers ouverts et leur contenu - des mots de passe ...

Windows stocke les symboles dans des fichiers séparés (.PDB). Sous Mac OS X, ils sont stockés dans l'exécutable kernel. Pour lire les données d'adresse des symboles kernel, ils faut utiliser une formule de conversion. S'ensuit une description du parcours de l'espace d'adressage virtuel. Maintenant, on a les sympboles kernel et le gestionnaire de mémoire est initialisé, tout l'espace mémoire kernel est maintenant parcourable.

D'abord récupérer les informations de version du système. Puis la liste des systèmes de fichier. La liste des extensions kernel via le parcours de la liste chainée kmod. Puis la liste des processus BSD via la structure kernproc, ainsi que les informations associées dans la structure de données du processus. Reconstruction de la syscall table.

Détection de rootkit : si un offset dans une entrée syscall n'est pas dans les symboles kernel, y'a un soucis ^^

Démo. Commandes info (version du kernel, mémoire, CPU), mount (listage des filesystems avec leur mountpoints). syscall pour la syscall table (avec offset associés, et si l'entrée est correcte pour détecter la modification d'une entrée comme par du hooking). kext pour avoir la liste des extensions kernel. ps pour la liste des processus avec parent ID. On peut "zoomer" sur un processus via la commande pid. Puis démo en zoomant sur le processus loginwindow. Une simple commande exploite une faiblesse de ce programme divulguée début 2008 qui affiche en clair le mot de passe utilisé pour se loguer.

Site : http://www.moonsols.com/ Twitter : msuiche

14:30 - 15:30 Full Process Analysis and Reconstitution of a Virtual Machine from the Native Host - James Butler, MANDIANT

Une présentation qui se rapproche très fortement de la précédente. Cette fois c'est sous Windows que ca se passe. Il fait l'historique des dispositifs hardware permettant un accès à la mémoire physique (PCI, bus DMA, PCMCIA, ...). Ensuite les méthodes software (BSoD, \.\DebugMemory, ...). Il n'est plus possible aujourd'hui depuis un processus userland d'avoir accès à la mémoire physique (Doh!). Outils : Windd (Matthieu Suiche), Memoryze (MANDIANT). Description du mécanisme de translation d'adresse mémoire sous x64. Des pages de débogueur kernel Windows.

VMSafe (disponible dans VMWare vSphere) fournit de l'introspection de la mémoire et de l'état des CPUs, du filtrage des paquets réseau, monitoring et contrôle complet des processus, montage des filesystems depuis le guest sur le host. XenAccess tente d'implémenter les même fonctions.

Démo. Son outil se branche sur une machine virtuelle VMWare en cours d'exécution (un guest Windows). Il se branche sur le fichier .vmem que VMWare utilise pour ses machines en cours d'exécution. Donc, outil est vraiment poussé, beaucoup de choses sont explorés dans la mémoire des processus.

Vraiment trop orienté Windows internals, je n'ai pas vraiment suivi (désolé Charles). L'orateur n'était pas aussi didactique que le précédent.

15:30 - 16:00 Break

16:00 - 17:00 Through the Looking Glass: An Investigation of Malware Trends and Response Activity - Jeff Williams, Microsoft

Historique de la détection des botnets. Puis zoom sur le malware Win32/Waledac. Il parle de la bêtise des utilisateurs qui cliquent sur n'importe quel lien. Waledac installe aussi automatiquement d'autres malwares une fois la machine infectée. S'ensuit une énumération d'autres malwares ainsi que leur distribution à travers le monde. L'idée est que chaque botnet est distribué de manière différente à travers le globe. Certains sont plus répandus en Russie, d'autres en Chine, d'autres encore aux États-Unis.

Tous les botnets n'utilisent pas le même canal de C&C : IRC, HTTP, P2P, autre.

Waledac est un acteur majeur de production de spam. Son canal de C&C se base sur différents protocole : HTTP, P2P et l'architecture est basé autour d'une structure hiérarchique de type fast-flux DNS. Tous les domaines sont en .com. Microsoft a bossé avec Verisign (gestionnaire des .com) et les forces de l'ordre pour couper ce botnet. Ce botnet possède un middle-tier pour masquer la tête du réseau. Cette opération s'est appelée "Operation b49".

Cela a créé un précédent : le shutdown de certains domaines. Pour la première fois, on a montré qu'un botnet basé sur du P2P pouvait être contrôlé par une autre personne que le hurder.

Maintenant, grâce aux enseignements de cette opération, Microsoft lance le projet MARS (Micrososft Active Response for Security) pour couper le plus de botnet possible. Des centaines de milliers d'heures de ressource humaines sur ce projet.

Présentation était très courte et sans détails techniques, en forme de "Microsoft sauveur du monde".

17:00 - 18:00 The Jedi Packet Trick takes over the Deathstar: taking NIC backdoors to the next level - Arrigo Triulzi, Independent Security and Networking Consultant

Le speaker est loin, il est connecté via Skype. Talk originellement donné à PacSec 2008. Il a découvert par hasard que le NIC faisait du checksum offloading. Il s'est posé la question : peut-on en tirer quelque chose ? Il utilise une carte Broadcom (Tigon, basé sur un processeur MIPS), avec un firmware téléchargeable sur le site du fabriquant. L'idée est d'implémenter une attaque depuis une carte NIC1 vers une carte NIC2. Une carte n'a pas l'habitude de gérer une attaque venant de l'intérieur. Via PCI-to-PCI. Comment créer un rootkit directement dans une carte ?

Pré-requis : - NIC1 pour communication externe - NIC2 pour communication interne - nVidia GPU (on dirait que l'attaque repose en grande partie sur le fait qu'il y ait un kit de développement nVidia) - EFI BIOS

nicssh utilise plusieurs fonctions : findnic pour trouver une autre carte en scannant le bus PCI. grabnic pour injecter un firmware sur une carte vulnérable. forward pour mettre en place du forwarding de paquets. Il y a aussi nicfw (le firmware modifié).

La possibilité de faire du remote update nécessitait des droits admin. Cela fonctionne en envoyant un WOL suivi d'un message UDP dans un format particulier. Mais pousser un firmware via UDP est risqué, on risque de perdre des morceaux.

En gros, il injecte un nouveau firmware à distance, et ouvre un shell sur la carte réseau ...

Amélioration suivante, utiliser un module EFI pour charger nicssh 2.0 sur la NIC. Ce module chargera le nouveau firmware et installera nicssh sur le GPU. Le but final étant d'obtenir la persistance pour se protéger contre le re-flashing de la NIC. Le module EFI est stocké dans le SATA pour gérer ca.

Ces problèmes de sécurité viennent de failles crypto, d'une mauvaise gestion des clés (PKI FAIL). Une autre idée est d'utiliser les ucode pour mettre à jour les CPU (les errata). Les updates de ucode ne sont pas persistantes lors des reboots. EFI est encore la solution. C'est encore du work-in-progress, plein de choses sont encore à explorer dans ce domaine.

18:00 - 19:00 C8H10N4O2 and C2H6O (and teardown)

lundi, avril 12 2010

Compte-rendu CanSecWest 2010 - jour 2

Thursday March 25

09:00 - 10:00 SEH overwrite and its exploitability - Shuichiro Suzuki, Fourteenforty

SEH overwrite est la méthode d'exploitation principale pour les programmes sous Windows. Il existe des méthodes de protection (DEP, SEHOP, SafeSEH). Sont-elles suffisantes ? SEH est le système de gestion des exceptions employé sous Windows. Il y a une liste chainée dans la pile. C'est une liste chainée gérant les exceptions. Le classique stack overflow permet de ré-écrire le pointeur d'entrée de la liste des exceptions. Suivi d'une description de la callstack quand une exception survient. Description de SafeSEH. Et d'une faiblesse de SafeSEH. Il existe encore une zone exécutable dans la protection SafeSEH, et le but est de l'utiliser. Il passe ensuite aux faiblesses de SEHOP (SEH Overwrites Protection). Une autre protection nommée Hardware DEP empêche l'exécution de code dans l'attribut exécutable. Il y a aussi l'ASLR qui a de nombreux impacts sur SEH. Il passe à l'explication du contournement de ces protections. L'idée pour contourner SEHOP est de reconstruire une chaine de gestion des exceptions valide. Pour contourner le Hardware DEP, il utilise des méthodes de type return-into-libc et de return-oriented programming. Ne pas perdre de vue qu'on parle d'un stack overflow, et donc ces techniques fonctionnent.

Liste des choses a faire : - re-créer la chaine SEH (bypass SEHOP) - ré-écrire l'exception handler address dans un module non protégé SafeSEH - créer une pile pour exécuter le code voulu (bypass Hardware DEP) => utilisation de memcpy() pour ensuite placer un code ou on veut ...

Demo sous Windows 7. Bon, il nous lance un débogueur, et fait de l'exécution pas à pas pour bien tout comprendre sur un programme vulnérable.

ASLR rend difficile la création d'une chaine SEH valide. Il rend aussi difficile de trouver les instructions utiles à une adresse fixe.

Conclusion : cette présentation demande de fortes compétences en exploitation de failles sous Windows. Sans ca, c'est difficile de comprendre les tenants et les aboutissants. Pour terminer, il donne un tableau des conditions d'exploitation en fonction des différentes protections.

10:00 - 10:30 Second Breakfast

Je reconfigure ma carte WiFi qui a décidé de ne plus fonctionner :/ Mise en place de connexion sur le bon AP, établissement de mon tunnel SSH préféré avec du DynamicForwarding pour éviter tout risque d'écoute de mon trafic. Vive les serveurs dédiés sur Internet.

10:30 - 11:30 There's a party at ring0, and you're invited. - Julien Tinnes & Tavis Ormandy, Google

Ils bossent dans l'Information Security team de Google. Il y a du sandboxing dans Google Chrome et Android. Le talk est a propos du kernel comme cible des attaques de type local privilege escalation. Deux types de bug kernel : memory management corruption et bug de logique. Exemple de bugs de logique : CVE-2001-1384, CVE-2003-0123. Exemple de bugs de mémoire : CVE-2003-0961. En milieu kernel, on contrôle tout l'espace d'adressage, on accède à la complexité de gestion de l'espace mémoire. Exploiter le kernel sert par exemple à : sortir de chroot(), contourner les MAC, contourner les vserver. Pour bien se protéger, il vaut mieux utiliser un suite de protection kernel comme grsecurity. Avant, ce genre d'attaque n'était pas très répendues sous Windows, mais cela change. Très peu de remote kernel exploits pour Linux (publics en tout cas). Certains bugs sont exploitables en remote via le Web browser (exemple : faille dans le driver nVidia). Grande surface d'attaque pour le kernel : ioctls, devices, kernel parsers. Filesystems, network protocols, format des exécutables ... Demo orientée kernel Windows. Ils ont trouvé un moyen de placer le bit supervisor à 1 en exploitant une faille. Ce qui donne un accès au mode Virtaul-8086 (ring0?). GDI a été deplacé du userland vers le kernelland pour des raisons de performances. Mais le GDI est ce qu'il y a de plus simple à exploiter à distance. Par exemple via IE, en accédant aux fonts (TTF) qui sont gérées via GDI. Description d'une faille dans le parsing des fonts TTF (donc, code exécuté en ring0). Description de l'exploitation des NULL pointer dereferences sous Linux. Exemple d'une faille découverte par eux : CVE-2009-2692. NULL pointer dereference en local via sock_sendpage. sock_sendpage à un modèle de fonctionnement fragile, puisque nécessite la MAJ de tous les modèles si on modifie certaines fonctions pointées dans la structure proto_ops. Par exemple, pour une faille, une structure était initialisée à NULL. Il suffisait de placer son shellcode à NULL pour qu'il soit exécuté au lancement. Puis ils ont trouvé un autre bug de même type : CVE-2009-2698 dans udp_sendmsg. Suivi d'un exemple d'exploitation pour fasync, une faille de type use-after-free. Suivi d'un exemple d'exploitation sous NetBSD. Explication sur la syscall interface sous Windows : compliquée, instable, et non documentée. Vaste aussi (300 sous Linux). Normalement seulement utilisé par du code Microsoft. Les syscall sont très vulnérable au fuzzing car peu résistants aux mauvaises entrées. Et comme le kernel parse des fonts, des pixmaps, la syscall interface est un excellent candidat au fuzzing. Plus facile de trouver des bugs en fuzzant la syscall sous Windows sur sous Linux. Solution pour se protéger contre les privileges escalation : TPE (Trusted Path Executables). Facile à contourner sous Linux, à moins d'utiliser grsecurity. Gagne en popularité sous Windows. Pour contourner cette protection; on peut utiliser des failles dans des programmes interprétés (Python, Perl, ...). Autre solution : le sandboxing, à base de chroot() et de ptrace() (lent et difficile à mettre en place). SECCOMP-based sandbox aussi (sera peut-être implémenté dans Chrome-Linux). Mais si on ne peut protéger le kernel, l'utilisation de la virtualisation peut être une alternative. Une autre bonne protection pour le kernel Linux est l'utilisation de PaX, qui utilise des techniques de limitation de permissions dans le kernel.

Conclusion : Si le kernel trust une donnée userspace, une faille de sécurité de type escalade de privilège existe. Cela vaut pour l'existence d'une donnée, mais aussi pour l'absence d'une donnée. En gros, c'était une liste d'exemple d'exploitation de bugs kernel sous Linux et Windows. Tavis est plus Windows, et Julien plus Linux. La surface d'attaque kernel est grande et grossit de plus en plus. De plus en plus facile à atteindre en remote. La difficulté d'exploitation va de simple à très dur. Les technos de prévention d'exploitation en kernel sont aujourd'hui immatures. En gros, les sandbox c'est bien, mais il y a toujours une surface d'attaque depuis la sandbox vers le kernel qu'il est difficile de protéger.

Lien : http://blog.cr0.org/2010/03/theres-party-at-ring0-and-youre-invited.html

11:30 - 12:30 Babysitting an army of monkeys: an analysis of fuzzing 4 products with 5 lines of Python - Charlie Miller, Independent Security Evaluators

Fuzzing de 4 produits en 5 lignes de Python. Fuzzing de PDF (Preview et Acrobat Reader). Fuzzing de PPT (OpenOffice et PowerPoinet). Dumb fuzzing : faire des modifications sur un fichier correct. Smart fuzzing : utiliser des entrées créatives "from scratch". Compromis : utilisation de dumb fuzzing avec de nombreux fichiers différents. Idée : avec suffisamment de fichiers en entrée, on peut couvrir une grande surface des fonctionnalités offertes par le format. Mais toujours la limitation du CRC et de la compression sur ces fichiers.

Méthodologie : - download de plus de 80 000 fichiers PDF depuis Internet. - Acrobat Reader + Valgrind sous Linux pour mesurer la couverture de code. - réduit à ~1500 fichiers

Le fuzzer de 5 lignes: - change juste des bytes au hasard par des valeurs prisent au hasard. - ne rien supprimer, ne rien ajouter.

Utilisation de son framework de fuzzing parallèle (Tiamat). Scripté par AppleScript et monitoring du CPU pour savoir quand lancer le fichier suivant. Enregistrement des crashs répétés. Utilisation de libgmalloc (comme libefence) pour détecter les heap overflow sous Mac OS. Utilisation de memcheck (outil Valgrind) pour simuler l'exécution de programme et enregistrer les opérations mémoire invalides. Détection sous Linux. Crashwrangler classe les bugs en disant si ils sont exploitables ou pas.

Le fuzzing est une histoire de filtrage. Filtrage des résultats pour les classer en crash, exploitables, ... Recherche des crashs donnant des EIP uniques grâce à libgmalloc et Valgrind. S'ensuit une liste de chiffres sur le classement, et le nombre de bugs exploitables au final. Lancement de plus de 3 millions de tests depuis 1500 fichiers PDF.

Plus on fuzz un fichier unique, plus on trouve de faille exploitables: 500 => 1; 1000 => 2; 1500 => 3; 2000 => 4; ...

Ensuite même chose, mais contre Preview (viewer PDF sous Mac OS). Ensuite même chose, mais contre les fichiers PPT d'OpenOffice. Ensuite même chose, mais contre les fichiers PPT d'Office.

L'orateur a fini par faire un check lui-même pour vérifier l'exploitabilité de ce qu'il a trouvé. Il est souvent d'accord avec le résultat de Crashwrangler. L'autre programme pour tester s'appelle !exploitable et donne des résultats moins fiables.

Conclusion : plus on fait d'itérations sur ces 5 lignes de Python, plus ou trouve de bugs exploitables. L'idée intéressante ici était de prendre des fichiers valides, et de modifier 1 byte de manière aléatoire dans chacun de ceux-ci, et d'itérer sur chacun un grand nombre de fois pour avoir le plus grand nombre de fichiers de fuzzinga différents. Mais l'orateur arrive à une conclusion étonnante : les outils qu'il utilise ne sont pas doués pour détecter les erreurs et l'exploitabilité ... Beaucoup de chiffres affichés, difficile de tirer une conclusion claire.

ooo Un gars éteint son ordinateur portable sous Windows. Je vois l'écran de mise à jour : 72 patchs restants ... ooo

12:30 - 13:30 Lunch

13:30 - 14:30 ShareREing is Caring - Halvar Flake and Sebastian Porst, zynamics GmbH

EScript.api (Adobe Reader JavaSript Engine). Le talk est a propos d'un plugin IDA Pro nommée BinCrowd. BinCrowd a permis de détecter que c'est en fait l'engine SpiderMonkey qui est derrière EScript.api. Cela a été possible sans le code source associé.

L'idée est de trouver les programmes intégrant les mêmes bibliothèques non-dynamiques dans leur code. Ainsi, si on trouve une faille dans un programme A qui intègre une bibliothèque vulnérable, on peut trouver les autres programmes qui ont aussi cette faille.

S'ensuit une description de l'algorithme permettant l'identification de duplication de bibliothèque. C'est une fonction de hash pour un graphe. Ainsi, une comparaison numéraire est possible. Mais en fait, a l'usage, cela se montre trop limité, et il est nécessaire de développer un algo pour gérer un callgraph complet avec les adresses de fonctions associées.

BinCrowd est aussi une solution pour faire du RE entre équipes qui ont un différent niveau d'accréditation. Les données sensibles ne peuvent être transmises entre équipes qui ne possède pas le même niveau. Ainsi, il est possible de partager le travail, mais pas les données sensibles. Cela fonctionne comme un middleware, avec une base de données centrale, et un contrôle du transfert des informations.

Tout le monde peut utiliser BinCrowd, le plugin (opensource?) ainsi qu'un compte sont nécessaires.

14:30 - 15:30 Cisco IOS Exploitation with IODIDE - Andy Davis, KPMG

Il fait de la rechercher sécurité chez KPMG en Angleterre. IODIDE est un IOS débogueur et un Integrated Disassembler Environment écrit en Python. Il communique avec IOS via le remote gdb intégré. Il a une interface graphique. S'ensuit une explication du fonctionnement du gdb Cisco (qui varie au niveau du remote protocole par rapport à celui d'un gdb standard). Le gdb Cisco ne supporte qu'un nombre limité de commandes. On peut s'y connecter via IP où un accès port série.

Démo.

Grâce à cet outil, on peut utiliser un débogueur ressemblant à OllyDbg pour voir l'état des registres, les exceptions, l'état de la pile, ainsi que le code désassemblé ... le tout en remote. Le débogueur a vraiment l'air puissant. Recherche de données en mémoire. Obtention de la liste des process. Affichage de la configuration Cisco actuelle. On peut aussi modifier les registres et la mémoire. L'environnement de désassemblage est pas mal non-plus, il permet d'ajouter des commentaires de manière simple.

Ensuite un historique des failles IOS. Stack et heap overflows. Format string (mais seulement fuite d'information, pas de %n chez IOS). Mike Lynn a été le premier à créer un shellcode pour IOS (un connect-back shellcode) mais qui n'a jamais été diffusé.

IOS est un gros binaire ELF dont toutes les fonctions ont des adresses différentes en fonction de la version d'IOS. Le processeur est du PowerPC. Identifier la version exacte est très difficile. Si l'ont utilise une adresse incorrecte lors d'une tentative d'exploitation, le router reboute.

Étude de cas sur une faille dans le serveur FTP. Un stack overflow dans le verbe MKD. S'ensuit une explication de l'exploitation des stack overflow sur architecture PowerPC. L'équivalent de EIP sous x86 est ici LR (Link Register). L'adresse que nous souhaitons utiliser pour lancer le shellcode se retrouvera dans le PC (Program Counter).

Le shellcode devra supprimer le prompt pour un password au login, et donner un accès "level 15" équivalent à root. Et surtout, sortir de manière propre sans crasher le routeur. Pour supprimer le password prompt, il écrit la valeur 1 à un offset. Pour accroitre les privilèges, il écrit la valeur 0x1f000000 à un autre offset. Pour sortir de manière propre, il fait l'équivalent d'un kill(-1), pour se tuer lui-même. Mais ca ne coupe que la connexion, pas le service FTP.

Il a diffusé un shellcode (cassé) en juillet 2008. Maintenant, il utilise un méthode return-oriented programming. Il utilise le propre code PowerPC pour écrire une adresse où il veut. En 2 paquets, il obtient la suppression du password prompt, et l'élévation de privilèges. Mais il utilise des adresses hard-codées.

Utilisation du syscall #34 pour accéder à la chaine de version IOS. Utilise la fonction send() pour retourner l'info via la socket ouverte.

Démo. Via IODIDE (Exploit Edition), il exploite la faille. Pas mal.

Conclusion : excellent outil de débogage et désassemblage. A mon avis excellent pour écrire des exploits IOS. Pas grand monde fait de la recherche sur l'exploitation IOS; plein de boulot en perspective dans le domaine. IODIDE ne supporte que PowerPC pour le moment. Il sera releasé en open source (mais pas l'Exploit Edition).

15:30 - 16:00 Break

16:00 - 17:00 Random tales from a mobile phone hacker - Collin Mulliner

Checheur en sécurité sur les appareils mobiles. Tout ce qui possède une carte SIM.

Découverte de fuite d'information et exploitation à l'aide d'URI "from hell" principalement. Tout d'abord fuite d'information par connexion à des sites Web via le navigateur intégré au téléphone mobile. Aujourd'hui les téléphones ont un vrai navigateur (WAP est mort), et l'accès au Web est populaire.

- MSISDN : numéro de téléphone. - IMSI : SIM card ID - IMEI : phone ID

Rumeur : certains téléphones feraient fuir des infos privées via les en-têtes HTTP. Du coup, il a mis un place un logging systématique des en-têtes HTTP sur son serveur Web qui est assez populaire. Il peut collecter des données pour vérifier. Quelques exemples : - Rogers : opérateur Canadien révèle le MSISDN. - H3G Italie : révèle aussi le MSISDN. - Vodafone aussi. - Orange UK aussi, et bien plus encore. - Pelephone, Israel, fait fuir le MSISDN, l'IMSI et l'IMEI clairement dans les en-têtes.

Et l'énumération continue, c'est l'hécatombe. Certains encodent l'info en Hex ^^ D'autres infos souvent remontées : customer ID, point de connexion (APN).

Apparemment, les téléphones n'ont pas ces infos, elles sont donc ajoutées par un proxy/gateway de l'opérateur. Le sujet des Web proxy de téléphones semble compliqué.

Démo. Une liste d'information capturées avec des statistiques.

L'orateur trouve étonnant que ces fuites d'informations n'aient pas eu une plus grande attention médiatique.

L'orateur fournit un lien pour valider son opérateur (sans qu'il ne logue, rires) : http://www.mulliner.org/pc.cgi

Ensuite on passe au hack du Kindle. Il possède une carte SIM qui marche sur tout téléphone, mais sans voix ni SMS. On peut seulement accéder au net via un proxy hardcodé chez amazon.com. Le trafic est rejeté si il ne vient pas du navigateur du Kindle. Mais comment ? Utilisation de privoxy (ou Modify Header) pour ajouter un en-tête x-fsn. L'outil Tethering implémente ca. Le hack permet un accès complet à Internet.

Ensuite il passe a Digital Picture Frame (HUAWEI DP230). Il a un modem et une carte SIM et un numéro de téléphone ... Désossage, branchement sur le port série puis accès shell (admin:admin). Il peut recevoir des SMS et possède un accès GPRS. Un SMS en XML permet de modifier la conf de l'appareil, comme par exemple modifier l'image de fond. Il doit par contre être originaire d'un numéro spécifique. Spoofer ce numéro est assez facile. Des services en ligne le fond pour pas cher. C'est le download des binaires qui a permis de reverser ce fonctionnement.

Quelques attaques: - désactiver l'accès Internet "<req><GPRS apn="brick"/></req>" - effacer toutes les images

Conclusion : les numéros assignés par les opérateurs sont guessable. On peut bricker tout un parc de machine de ce genre en brute-forçant un petit espace de numéros.

Il passe ensuite sur les cartes pré-payées. Quand le compte est vide, le trafic est redirigé vers un portail Web pour la recharge. On peut faire du DNS tunnel comme ca ^^ mais c'est identifiable par l'opérateur à cause de la nécessité d'avoir un endpoint DNS. Ça reste du tunnel DNS sur une connexion 3G, les performances ne sont pas super.

Maintenant les URIs from hell : des protocoles spéciaux implémentés dans les navigateurs des téléphones. C'est facile de faire crasher un téléphone avec du JavaScript embarqué dans un site Web malicieux, les téléphones trouvant automatiquement les URI qui les intéressent. Pour l'iPhone, une attaque permet le lancement d'un appel automatique via un iframe et un URI de type "sms:" ou "tel:" (<iframe src="sms:numéro" ...>). Avec une chaine trop longue dans le "sms:" URI, le téléphone freeze (CVE-2009-0961). Pour l'instant, ca fait juste apparaitre la fenêtre d'envoi de SMS ou d'appel. Pas d'automatisation possible.

Conclusion : il n'y a pas que les smartphones dans la vie, il faut penser aussi aux simples? téléphones, aux réseaux des opérateurs mobiles et au "Consumer Electronics Devices".

17:00 - 18:00 Legal Perspectives of Hardware Hacking - Jennifer Granick, EFF

Présentation orientée lois aux US. Mais utile, car si on enfreint les lois US depuis un autre pays, on peut être poursuivi en posant les pieds chez eux (en gros). L'EFF travail sur le droit des développeurs, sur les DRM, ...

Nouveauté : accéder à du software embarqué viol le DMCA.

Elle n'aborde pas les violations de brevets, ni les "trade secrets". Les présentation est donc orientée violation du DMCA. Quelques exemples : iPhone jailbreaking, calculatrices TI, Kindle Souvent, les attaques s'articulent autour de la signature des composants (la chaine de confiance TPM). Et donc à une attaque ciblée sur les clés de signature. Pour le Kindle, c'est une méthode pour contourner le DRM.

Note : pour la calculatrice TI : la clé privée est dérivée de la clé publique :) Le fait que les clés de signatures soit faibles n'entre pas en compte lors d'une poursuite judiciaire.

Ce qu'il faut retenir : - éviter de cliquer pour accepter le EULA - avoir l'autorisation du fabriquant du produit - et d'autres encore.

Un talk sur la légalité que je n'ai pas vraiment suivi.

Question ouverte : pourquoi dans toutes les conférences de sécurité, la seule femme qui présente parle des aspects légaux ?

18:00 - 19:00 Lightning Talks - Various

ooo La fille qui s'occupe de faire le gong entre les talks boit une bière. Elle prend une pause comme dans une pub. D'ailleurs, les gens qui font un lightning talk ont le droit à une bière. ooo

- CSP (Content Security Policy) - URL shorteners (utilisation d'encoder de shellcode alphanumeric pour les URI véhiculant un exploit genre smb://long_string, et on place dans un URL shortener, et ca passe) (Saumil Shah) - Waledac Botnet (Thorsten Holz) Attaque Sybil pour couper une partie du réseau P2P. - 2600 Hz or not, Jon Van Boxtel

Saumil gagne le prix du meilleur talk.

20:00 - 1:00 Party Venue TBA

lundi, avril 5 2010

Compte-rendu CanSecWest 2010 - jour 1

Wednesday March 24

La matinée de cette première journée est consacrée à l'enregistrement des participants. Environ 500 personnes présentes dans la salle.

13:00 - 14:00 Internet Nails Marcus Ranum, Tenable

Une histoire de bad software engineering et de bad design ; où comment une petite erreur de design peut couter très cher. En 1971, FTP est inventé et codé. Les premières versions de transport d'email était faite via FTP. En 1976, NCP. Qui était l'ancêtre de TCP. Fonctionnement a sens unique, pas encore de full-duplex. Suivi d'une explication sur le fonctionnement de FTP.

Question clé : peut-on parler de design pour FTP dans un monde de software a cet époque ?

Puis, description sur la difficulté de faire fonctionner FTP au travers d'un firewall. Blabla sur l'introduction des firewalls. Le premier produit commercialisé en 1991 coutait $175,000. L'idée est que le design de FTP de l'époque coute des millions aujourd'hui, a cause de la difficulté de filtrage de ce protocole au niveau firewall. Puis une autre histoire : pour décharger le noyau, les Sockets BSD furent introduit. Le but était d'accepter un plus grand nombre de connections. Mais il fallait garder une table des sockets ouvertes, et cela n'a pas protégé contre le SYN flooding. En 1995, le protocole HTTP a été imaginé pour être stateless, aussi pour décharger le noyau. HTTP fonctionne en ouvrant de nombreuses connections TCP short-lived. Ce fut lent, et les codeurs de navigateurs Web décidèrent de faire ces connections en parallèle ...

Résultat : du surf plus rapide, mais plus de load sur le réseau et le serveur.

Aujourd'hui, on a amélioré le code gérant les short-lived connections pour résoudre ces problèmes. En 1997, le E-commerce. Problème avec HTTP, aucun état n'est maintenu, et c'est devenu nécessaire (gestion de l'authentification, garder la liste des courses ...). Ainsi des frameworks de développement furent introduit pour garder l'état des connexions via un session management. Tout cela, parce que HTTP a été designé pour être stateless. Quel coup pour tout ceci ? Sans compter les erreurs de codage menant à toutes les failles que l'on connait. Vient ensuite la gestion de la charge. Chaque load balancer doit garder l'état pour savoir où rediriger les requêtes et éviter de briser l'état de la session. Tout cela alors que TCP/IP sait déjà gérer l'état d'une session ... et en plus de ré-implémenter une gestion de session, nous avons de nouvelles classes de vulnérabilités (XSS, XSRF, ...).

Conclusion : un mauvais design coute extrêmement cher. D'où l'idée de développer le "design intelligent" mais par un visionnaire omniscient. Le soft est au coeur de tout, on doit faire mieux, être moins concernés par le "backward compatibility" et être plus au fait des conséquences d'une petite décision de design.

14:00 - 15:00 Under the Kimono of Office Security Engineering - Tom Gallagher & David Conger, Microsoft

Respectivement Senior Security Test leader et Software Design Engineer. Historique des menaces : macro virus principalement. Avant 2006, tèrs peu d'attaques sur le format des documents eux-même. Quand Microsoft a vu que les failles commençaient a être commercialisées, ils ont décidé d'investir pour éviter les failles dès le début. Nouvelles organisation : chaque produit à une liste de contacts sécurité. Chaque produit à une liste de feature owner.

1. Harden the attack surface : suivre le SDL, automatiser la revue de code, SafeInt?, suppression des vieux parseurs (exemple : 3 parseurs différents pour JPEG), fuzzing distribué (300+ formats de fichier à supporter, certains n'étant pas simples et nécessitant des fuzzers particuliers). Suivi d'une explication sur le fuzzing distribué, qui pourrait être utilisé pour les tests en général. L'idée est de centraliser la gestion du fuzzing : les tests, les résultats, les erreurs et les rapports. Le but est aussi de répartir la charge pour exploiter les machines non utilisées. Microsoft a developé un client de fuzzing distribué facile à utiliser par tous les dveloppeurs. Un serveur avec interface Web centralise le tout. Une fonction intéressante permet de re-tester contre les régressions, en prenant par exemple une call stack d'erreur en input. Également la possibilité de tester les même bugs sur différents produits. Pour chaque bug trouvé, toutes les infos sont disponibles (état des registres, call stack complète ...). En gros, ils ont fait un botnet sur leur réseau qui sert à faire du fuzzing. Ils ne se posent pas la question de l'exploitabilité d'un bug quand ils en trouvent un, ils le patch (au minimum, ca rendra le produit plus stable).

2. Reduce the attack surface : File Block (exemple: bloquer les formats non utilisés) et Gatekeeper (évaluation de la 'correctness' des fichiers à l'ouverture, avec mécanisme de mise à jour des informations de 'correctness'). Demo. En gros, ils ont mis un anti-virus dédié aux formats de fichier dans Office.

3. Mitigate the Exploits : Création d'un Office 'Protected Viewer' qui classe toutes les sources venant d'Internet comme untrusted. Architecture avec un processus Host et un processus Client. Utilise des composants de sandboxing (isolation des processus). Ceci est géré par wwlib.dll, qui lance une instance de winword.exe dans une sandbox.

4. Improve the User Experience : l'améliorer en rapport avec la confiance. A l'avenir, en prenant l'exemple de l'ouverture d'un attachement mail : Open > Gatekeeper Validation > Sanboxed Viewer > User Clicks enable > Document Opened. Ensuite, le user peut le sauvegarder, et le rouvrir sans ces checks. Option très intéressante pour regarder les "conneries" envoyées par les potes, les documents sont vus dans la Sandbox, et ne doivent pas pouvoir abimer le système (exemple pris tel quel par l'orateur).

Conclusion : Ils ont d'abord décris un processus de tests bien fait, pas forcément orienté uniquement sécurité. Ensuite, ils ont décrits les améliorations apportées à Office qui elles ont été pensées pour la sécurité.

15:00 - 15:30 Break

Quelqu'un s'est amusé à broadcaster le SSID "CanSecWest". C'était évidemment un faux.

15:30 - 16:30 Automated SQL Ownage Techniques - Fernando Federico Russ, Core

Description d'une méthode blackbox automatisée d'intrusion SQL. La vulnérabilité est exploitée de manière à éviter les "False Positives". Première étape de reconnaissance. Un web spider utilisant un MitM proxy. Reconstruction des QUERY_STRING et parfois du chemin de l'URL (cas mod_rewrite). Parcours aussi les champs HTML <form>. Fonctionne en mode fuzzing, et peut potentiellement abimer l'application. Détection des erreurs (HTTP error codes, error strings, redirections ...). Pour déterminer la présence d'une injection, une liste de test retournant true/false est jouée. Si true, alors on contre-test par une autre méthode pour confirmer. C'est une technologie de type système expert. Une autre fonction est de déterminer le type de la base de donnes (produit, version). La méthode retenue : du brute-force sur les fonctions possibles (HEX() pour DB2, HOST_NAME() pour SQL Server, VERSION() pour MySQL, ...). L'implémentation tourne autour d'une couche d'abstraction nommée "channel". Elle fournit une API (UNION, Scalar, Blind, ...).

ooo Le téléphone rouge sonne, Charlie Miller semble avoir exploité avec succès une faille dans l'iPhone. Il gagne un truc ^^ ooo

L'outil permet de savoir si la requête exploitée est de type SELECT. Il détecte la morphologie (nombre de colonnes, leur type, la visibilité dans le HTML, ...). Un exemple d'utilisation : remplacer la vrai requête par la notre (SELECT user,pass FROM credentials). Pour que cela marche, il faut détecter le nombre d'élément de la requête d'origine (ici 2), et leur type (ici string). Si c'est le cas, nous pouvons construire la requête de l'exemple. Si les types ne sont pas les mêmes, on peut utiliser des fonctions pour "caster" les valeurs. Pour extraire toutes ces informations, une requête SQL CASE est utilisée (CASE WHEN ... THEN ... ELSE). Mais cela permet uniquement d'extraire bit par bit (un bit étant true/false).

ooo Le téléphone rouge sonne de nouveau, une nouvelle faille a été trouvée (IE? 64-bit). ooo

16:30 - 17:30 Can you still trust your network card? - Yves-Alexis Perez & Loïc Duflot

Yves-Alexis et Loïc travaillent pour l'ANSSI (Agence Nationale de SSI). Tout type de carte réseau. Leur hardware est complexe (plusieurs processeurs, différents types de mémoire, ...). Leur firmware est complexe (gestion de la segmentation TCP en offloading, remote management, ...). Ça n'a rien a voir avec les bugs drivers ou les vulnérabilités de l'OS. Description de l'architecture. PHY (send/recv sur le réseau), DMA-engine (send/recv sur le bus interne), negociation and link control (full-duplex, ...). Explication pour la carte Broadcom intégrée sur certains NIC. La carte possède un processeur MIPS, le firmware permet une customisation pour processer des paquets propriétaires par exemple. La mémoire interne de la carte est mappée sur la mémoire de la machine hôte. Protocole ASF. La carte réseau reçoit les évènements des autres devices de la machine via SMBus. Utilisation du protocole RMCP pour rebooter et autres actions ... ASF n'a aucune interface sécurité de prévu, et les fabriquant ne sont pas vraiment incités à en faire.

ooo Le téléphone rouge sonne : Firefox sous Windows 7. ooo

ASF 2.0 ajoute un nouveau protocole : RSP. Des extensions sécurité pour RMCP, comme l'authentification et le contrôle d'intégrité. Mais pas de chiffrement. RMCP est en écoute sur 623/UDP. La version secure sur 664/UDP. Broadcom fournit un outil de configuration ASF. Ces paquets UDP ne sont jamais vu par l'OS, puisque interceptés par la carte réseau avant.

Vulnérabilité potentielle sur le protocole d'authentification (réduction de l'entropie). Problème d'implémentation sur le username (CVE-2010-0104), limité à 16 caractères sans null byte avec 1 byte pour spécifier sa longueur. Nécessité de déboguer la carte réseau par un débogueur de NIC (accès aux registres du processeur MIPS). Ils ont développé un débogueur NIC maison. Ils ont ensuite pu écrire un exploit pour la faille trouvée dans la gestion du champ username. Comme il n'y a que 255 octets (moins le padding) pour placer le shellcode de l'exploit, ils utilisent l'accès aux network buffers pour placer leur shellcode. En effet, le NIC est le mieux placé pour accéder aux network buffers. NIC utilise le DMA engine ; il peut donc lire et écrire la mémoire de la machine hôte. Un paquet réseau exploitant une faille peut donc être utilisé pour écrire des données dans la mémoire de la machine hôte sans contrôler son OS.

Suivi d'une démo sur l'amélioration de leur exploit : lancement des paquets RMCP exploitant la faille. Puis d'un message ICMP magique. Enfin, un rootshell en écoute sur le port 2 est activé. De plus, faire un ps sur la machine victime montre juste un shell, et un khelper (donc, attaque assez stealth).

Note : Le débogueur accède aux registres de la NIC via le driver local qui lui, à accès aux registres du processeur de la carte NIC via un mapping mémoire. Pas besoin de JTAG et compagnie.

Conclusion : Ce n'est pas encore le moment de paniquer. Peu de cartes supportent ASF, et encore moins l'ont activé par défaut.