Making network protocols go crazy

Je suis récemment tombé sur un papier intitulé Off-Path TCP Sequence Number Inference Attack - How Firewall Middleboxes Reduce Security [1]. Je ne connaissais pas la classification Off-path, ou littéralement, hors du chemin. Du coup, j'ai regardé de plus près le contenu de celui-ci.

[1] http://web.eecs.umich.edu/~zhiyunq/pub/oakland12_TCP_sequence_number_inference.pdf

Ce papier propose une nouvelle attaque pour injecter un contenu dans une session TCP, depuis le coté client (en mode non-privilégié). La faute serait sur les middle-boxes, telles que nos chères modems ADSL, par exemple, ou autres firewalls NATant. Plus précisémment, celles faisant du suivi de session en se basant sur l' ISN (Initial Sequence Number) de TCP. C'est ici que serait la faille, ce numéro pourrait fuire à cause d'une fuite d'information accessible en off-path.

Pour qu'une session TCP ne soit pas facilement détournable, un numéro de séquence est généré aléatoirement (sur 32-bits). Si ce numéro venait à être prédictible, ou à fuire, un attaquant pourrait insérer un contenu dans la session. Bien sur, l'attaquant devra également connaitre les adresses IP source et destination, ainsi que les ports TCP source et destination.

Qu'est-ce que l' off-path ? C'est différent d'un man-in-the-middle dans le sens ou l'écoute se fait à coté de la communication. Ici, l' off-path se passe sur le poste client, via un malware. Par exemple, les informations IP/ports se trouvent en utilisant la commande netstat. Ensuite, un side-channel permet de découvrir l' ISN possible. Par l'envoi de segments TCP depuis l'extérieur (adresse IP spoofée) avec un TTL ajusté pour émettre un message d'erreur, et par la consultation des statistiques via le /proc filesystem en local, il est possible de savoir si le segment TCP est passé au travers du firewall (ou non). Si il est passé, l' ISN choisi est autorisé par le firewall. Toutes les infos en mains, l'injection dans une session existante est réalisable. Bon, après, il faut avoir le bon timing, mais des propositions concrêtes sont faites dans le papier [1] que je vous invite à lire.

Plus techniquement, un firewall peut avoir plusieurs politiques pour accepter un segment TCP out-of-order, c'est à dire accepter s'il fait bien partie d'une session établie. En gros, l' ISN est dans la fenêtre (TCP window) ou non. Mais pour connaitre cette fenêtre, le firewall doit aussi garder cet état (tailles de la fenêtre initiale) depuis l'initialisation de la connexion TCP. Evidemment, pour des raisons de performance, ce n'est pas fait dans tous les produits. Du coup, certains firewalls utilisent une fenêtre hardcodée de 1 000 000 000 (1G), par exemple. Ca réduit l'espace des possibles. Il y a d'autres méthodes de suivi de l' ISN, je vous invite à lire le papier.

En gros, tous les dispositifs se reposant sur le suivi de session utilisant l' ISN sont vulnérables de manière plus ou moins critique. Mais la contrainte pour exploiter cette menace est de taille, un malware (non privilégié) doit être installé sur le poste de la victime. Je serai un malware, je ferai autre chose qu'injecter du contenu dans une session TCP ;) genre installer un plugin navigateur Web pour avoir un accès lecture/écriture au contenu.

Pas de compte-rendu pour les trois premières conf (pour cause de social event).

Utilisation malveillante des suivis de connexions

Eric Leblond

Slides : https://home.regit.org/2012/06/transparents-de-ma-presentation-au-sstic/ Blog : https://home.regit.org/2012/06/opensvp-a-new-tool-to-analyse-the-security-of-firewalls-using-algs/.

Présentations courtes

Clément Lecigne - Google

Netusse, un kernel fuzzer (de socket) qui existe depuis 2006. Google SoC de 2006 pour tester la solidité de la pile FreeBSD.

Développement pour tester sur les failles déjà existantes pour voir si l'outil les détecte. FreeBSD :

• REDZONE pour détecter les buffer overflows
• il y a aussi d'autres protections contre les heap overflow (voir présentation)

Note : Récupérer le lien de cette présentation (qui n'est pas dans les actes).

Description de l'exploitation des failles heap overflow sous FreeBSD.

Démo : un beau 0day sur kernel FreeBSD 8.2 et 8.3.

Outil : https://code.google.com/p/netusse/.

Etienne Millon - EADS Innovation Works

Vérification de code système par typage statique. Donc, une conf sur l'analyse statique ^^ Le typage des variables est fait lors de la compilation.

Outil : http://penjili.org/.

Ronan Mouchoux - CERT La Poste - @yenos

Détection de domaines malveillants par analyse sémantique et mathématique.

Spoofing des réponses DNS pour rediriger le trafic vers une machine (firewall) de contrôle. Les requêtes DNS sont analysées afin de détecter l'utilisation de noms de domaines aléatoires (cas des botnets). Utilisation du filtrage bayésien pour classer les noms de domaines comme malveillant ou non.

Limitations :

• certains noms d'hôtes officiels ressemblent à des noms malicieux (cas serveur d'update TrendMicro)
• certains noms de domaines malicieux utilisent la concaténation de mots, et coutournent ce contrôle

Ces noms de domaines sont générés par un DGA (Domain Generation Algorithm). Ils correspondent aux serveurs de Command & Control utilisés dans le botnet. Merci à Kevin pour cette information que j'avais ratée.

Successes (and limitations) of (static) binary analysis

Halvar Flake - Google

De plus en plus d'entreprises investissent dans l'analyse statique. Probablement des millions de bugs ont été corrigés grâce à cela. Ce sont les hackers qui ont poussé les entreprises dans cette direction.

Explication de la faille CrackAddr() de Sendmail datant de 2003. Une attaque sur la machine à état du parsing des adresses emails. Un état n'était pas correctement géré, et une suite de () permettait d'écrire au delà de la taille d'un buffer local (stack overflow). Une simple décrémentation était manquante dans le code.

Comment l'analyse statique peut détecter ce genre de bug ? les outils actuels n'y arrivent pas.

Les navigateurs sont déplacés dans des sandboxes aujourd'hui. Comme ça, la compromission du navigateur n'entraîne pas la compromission des données de la machine. Mais comme toutes ces données sont de plus en plus déplacées dans le Cloud ...

La complexité des programmes a maintenant dépassé notre capacité à les comprendre.

Note : version originale : Our ability to construct software has exponentially outpaced our ability to understand software

Nos outils d'analyse ne permettent de comprendre qu'une petite île dans un énorme océan. Nous devrions considérer que l'ouverture de n'importe quel document est l'équivalent à l'ouverture d'un exécutable (page web, PDF, Word, ...) et se protéger contre ça.

Compromission d'une application bancaire JavaCard par attaque logicielle

Julien Lancia

Je n'ai pas suivi cette conf, je vous renvoie chez n0secure : http://www.n0secure.org/2012/06/sstic-2012-compromission-dune.html

IronHide : Plate-forme d'attaques par entrées-sorties

Fernand Lone Sang - LAAS-CNRS Vincent Nicomette Yves Deswarte

Complexité croissante de la protection des systèmes d'exploitation. Etude des attaques hybrides (logiciels + matériels). Focus principal sur les attaques par entrées/sorties des composants matériels.

Pour étudier ces attaques et avoir un grand contrôle sur les tests, ils ont développé leur contrôleur en utilisant un FPGA. Ce contrôleur d'entrées/sorties se nomme IronHide.

Rappels sur l'architecture matériel et la gestion de la mémoire (espace mémoire, port I/O, PCI, PCI-Express). Focus sur PCI-Express. C'est un modèle en couches (physique, liaison, transaction et logique du contrôleur). Dans la couche transaction, nous avons les I/O, la configuration, les accès mémoire ainsi le message "applicatif".

Détails d'architecture d' IronHide.

Cet outil permet de générer tout type de paquets (valides, invalides). Le firmware est écrit en langage C. Il souffre actuellement de problèmes de performance (5 Mo/s).

Expérimentations :

• la carte IronHide est connectée sur la carte mère cible
• une connexion depuis la machine d'analyse avec un cable RS-232 sur l' IronHide pour le reporting
• et un autre cable RJ45 pour le command & control

Dans les tests, des dénis de service sont possibles sur l' I/O MMU, même avec des paquets valides lors de certains accès mémoire.

Démonstration d'une attaque : interception à distance des frappes claviers (accès arbitraire à la mémoire). Les paquets sont construits en utilisant Scapy. Leur méthode d'accès mémoire contourne les protections de l' IO/MMU, puisqu'ils utilisent directement les ports I/O.

Travaux futurs :

• Création d'un IDS/NIDS pour contrôleurs

La qualité d'hébergeur en 2012

Romain Beeckman - Directeur Juridique - OVH

Conférence invitée.

Pas de slides, donc pas de compte-rendu. Na ! Et puis c'est une conf juridique ;)

Je note quand même des trucs ; réponses à des questions comme :

• notions d'éditeur, d'hébergeur et de courtier (eBay)
• un courtier doit être uniquement passif (pas d'optimisation des résultats de recherche, par exemple)
• on devient éditeur si on a la capacité de modifier un contenu
• les responsabilités et obligations d'un hébergeur
• comment réagir lorsqu'on est hébergeur et notifié d'un contenu illicite
• l'hébergeur doit mettre en place des moyens pour les utilisateurs de notifier de la découverte de ces contenus
• le stockage des logs doit être d'au moins 12 mois

Résultats du challenge

Axel Tillequin Fabien Perigaud Florent Marceau

Par Julien Perrot (le grand gagnant du challenge). Un très bon travail de reverse.

Présentations courtes

Anthony Desnos - VirusTotal

Elsim + Androguard = Androsim Analyse automatique de programmes pour détecter les similarités entre codes et/ou bibliothèques. Le but est de trouver si un programme non-malicieux a été patché pour des fins malicieuses et/ou publicitaires. Détection à base de signatures, et surtout d'algorithmes de recherche de similarité. Tests sur le top des jeux Android : une majorité de code publicitaire (17% de code utile pour AngryBirds).

http://code.google.com/p/elsim/ http://code.google.com/p/androguard/

Davide Canali - EURECOM

Analyse des attaques Web par l'utilisation de Honeypots. Très peu d'études sur le début des attaques et sur ce que font les pirates ensuite. Setup : 500 sites Web avec 7 CMS (+ Web shells) chacun et 100 noms de domaines. Redirection via un proxy vers 7 VMs.

Outils permettant de voir :

• si les attaquants automatisent l'exploration (suivi des liens)

3 mois de collecte :

• 9.5 Go de requêtes HTTP
• 73 000 IP sources
• 178 pays
• 11 000 User agents

Attaques les plus fréquentes (69 000 attaques détectées) :

• Shells
• OsCommerce (vulnérabilités file upload)

Les classes d'attaquants, analyse basée sur les fichiers uploadés :

• Phishing
• Spam
• Défiguration
• Link farming (Blackhat SEO)
• Drive-by-download, botnets

Pierre Karpman - ENS Cachan / Supélec

Durcissement de programmes C avec SIDAN.

But : détecter :

• les flots illégaux de contrôle du programme
• les écritures dans la mémoire depuis des endroits illégaux

Des listes d'invariants :

• une variable X ne doit être que entre telle ou telle valeur
• on lance l'analyse
• si la variable X n'est pas comprise dans ce range durant l'analyse, on peut éventuellement trouver une faille.

SIDAN est implémenté comme plugin dans Frama-C.

Ces travaux se rapprochent de ceux d' endrazine présentés au CCC de décembre 2012. http://www.slideshare.net/endrazine/ccc28c3-post-memory-corruption-memory-analysis

Contrôle d’accès mandataire pour Windows 7

Damien Gros - thésard - CEA

Le modèle DAC est limité. Difficile à mettre en place de manière globale dans le cadre d'une politique globale. Confidentialité et intégrité sont également manquants dans ce modèle. La solution est le Controle d'Accès Mandataire (MAC). Pour Linux : SELinux, SMACK, TOMOYO, RSBAC.

Implémentation d'un équivalent à SELinux (de type Type Enforcement) sous Windows 7 en utilisant l' API hooking sur la SSDT (32-bits). L'outil permet aussi de créer automatiquement une politique de base par l'analyse d'un processus s'exécutant.

20 years of PaX

PaX team - plus qu'une personne sur trois dans l'équipe

Introduction sur ce que PaX est aujourd'hui. Modèle de menace: accès aribitraire à la mémoire (userland, kerneland) en lecture/écriture. Il vaut mieux dépenser son temps à prévenir l'exploitation des bugs que de les chercher. Une fonction importante: kernel self-protection. Nous n'aborderons dans ce compte-rendu que cette fonction qui est moins connue.

Quelques techniques d'exploitation :

• return-to-libc
• ROP (Return Oriented Programming)
• JOP (Jump Oriented Programming)

Fonctions de kernel self-protection :

• Non-exec kernel pages
  • Les pages userland ne doivent pas être exécutables depuis le kernel
• Read-only kernel data
  • constification : création de mappings des données vers du read-only
• Séparation de la mémoire userland/kerneland
  • Prévention de l'utilisation de code userland depuis le kernel
• Restriction sur les copies userland/kerneland
  • Bounds checking pour les copies kerneland vers userland ou vice versa
  • Protection contre les stack overflow (limiter aussi les attaques ROP/JOP)
• Protection contre les race condition de type copie/utilisation
• Nettoyage automatique sur les appels free()
  • La mémoire libérée est nettoyée, tout de suite (2 lignes de code au bon endroit)

Certaines fonctions implémentées dans PaX ont été inspirées par le reverse engineering de Windows 95 (durant les années 90). Ces fonctions nécessitent une mise à jour de la toolchain de compilation : plugin gcc, par exemple. Quelques plugins :

• Stackleak : prévention de la fuite d'information depuis la stack
• Constify : constification automatique des structures ops
• Kernexec : prévention de l'exécution de code userland
• Size overflow : prévention de l'exploitation de failles integer overflow

Les futures protections :

• Control Flow Enforcement : protection compète contre les ROP/JOP
  • Sous forme d'un plugin compilateur
  • Support JIT (Just-in-Time)
• Détection et prévention des size overflow
  • Même plugin que pour le kernel
  • Ce plugin aurait protégé contre les failles CVE-2012-2110 et CVE-2012-2131 (OpenSSL)
• User-after-free

Et beaucoup d'autres protections basées sur des plugins compilateur. Cela semble être le meilleur moyen aujourd'hui d'avoir des protections génériques. Le support LLVM/clang est également envisagé.

Les hyperviseurs : ils ajoutent une couche de complexité dans le système, et donc abaissent la sécurité du système. Le support ARM est prévu, mais seulement les fonctions compilateur et userland (beaucoup plus difficile pour le kerneland).

SSL/TLS - état des lieux et recommandations

Olivier Levillain - ANSSI

Description du fonctionnement du protocole de communication ("SSLv3/TLSv1.*) (ClientHello, ServerHello'', ...). Le client propose des algorithmes crypto, le serveur choisi.

SSLv2 (1995) à proscrire pour des raisons de faiblesses sécuritaires. Ce protocole tend à disparaitre. SSLv3 (1996) : problèmes avec la vieille implémentation. Ces problèmes sont corrigés par TLSv1.0.

Mais attaque à clair-choisi adaptative sur TLSv1.0 (Rogeway 2002). Corrigée dans TLSv1.1. Dans TLSv1.2, nouveaux algorithmes de gestion de l'authentification. Comme DHE/ECDHE qui assure la PFS (Perfect Forward Secrecy), afin qu'une caputre de session à un instant t ne puissent pas être déchiffrée dans le future.

Test de différents navigateurs pour le support des différentes version du protocole :

• SSLv2 est désactivé par défaut sur les dernières versions de firefox
• Chrome ne semble pas basé sur OpenSSL, il utilise son implémentation

Test de différents serveurs sur le support des différentes version du protocole. Scan de serveurs avec sslscan. A voir : référentiel RGS.

Test automatisé des navigateurs : http://ssltest.offenseindepth.com.

Le magasin de certificat : différents programmes utilisent différents magasins. Des avantages et des inconvenients à l'utilisation de magasins. Le magasin sous Linux est dans $HOME/.pki.

Note : Voir l'IDS Suricata.

Aucune réponse dans cette présentation concernant la gestion de la confiance globale au système (les PKI). Aucune étude non-plus sur le certificate pinning.

Netzob : un outil pour la rétro-conception de protocoles de communication

Frédéric Guihery Georges Bossert Guillaume Hiet

De nombreux protocoles (propriétaires ou non) qui ne sont pas documentés. Un des buts de la rétro-conception est le fuzzing de l' API, ou l'écriture de règles d' IDS. La communauté est globalement dépourvue d'outils d'analyse (processus manuel et visuel).

• Vocabulaire : liste des messages et leur format
• Grammaire : règles de procédure permettant d'assurer la cohérence des messages échangés.

Découpage du message brut en couches, puis champs. Les champs possèdent une liste d'attributs qui donneront la sémantique (optionnelle). La partie découpage en champ (automatisé) est basée sur un algorithme issu de la bio-informatique. Classification des messages (regroupés par similarité) aussi basé sur un algorithme issu de la bio-informatique.

Fonctions de l'outil :

• Import => inférence du protocole => simulation => export.
• Export : génération automatique de module Scapy.

Démo : découpage (presque) automatique de messages Ehernet/IP/UDP/DNS. Démo : instrumentation d'un serveur TCP pour inférence des différents état d'un protocole.

• Output : un automate des états du protocole.

Note : aHR0cDovL2dvby5nbC9pOFo3UA==

prompt$ perl -MMIME::Base64 -e 'print decode_base64("aHR0cDovL2dvby5nbC9pOFo3UA=="),"\n"'
http://goo.gl/i8Z7P
prompt$ printf "GET /i8Z7P HTTP/1.1\r\nHost: goo.gl\r\n\r\n" |nc goo.gl 80 |grep http
Location: http://sarssi-conf.org/SAR-SSI2011-Programme.pdf
The document has moved <A HREF="http://sarssi-conf.org/SAR-SSI2011-Programme.pdf">here</A>.

Sécurité de RDP

Arnaud EBALARD - ANSSI Aurélien Bordes - ANSSI Raphaël Rigo - ANSSI

Microsoft recommande l'utilisation des RPC via la MMC et non pas de RDP. Initialement uniquement un protocole de déport d'affichage, mais étendu ensuite avec de nouvelles fonctions (énormément, tellement qu'il est lié à tout le système au final). 2000 pages de documentation sur le site de Microsoft ...

RDP participe simplement à la mise en place de canaux de communication entre composants (matériel ou logiciel). Protocole complexe : 8 messages pour établir une session.

Démo : recupération de la clé RSA (512-bits) depuis une capture de paquets. Factorisation du RSA, puis rejeu du traffic déchiffré : accès mot de passe admin et tout le déport de session. C'est beau. Pas de perfect forward secrecy.

Pour corriger ces erreurs de sécurité, Microsoft a introduit Enhanced RDP Security (pour remplacer le Standard RDP Security) :

• TLS

Un protocole avec beaucoup de fonctions (même pour la sécurité), mais (presque) pas configurable. Une logique étrange pour le client Microsoft RDP au fil des versions (exemple : certificats X.509 doivent être formés d'une manière particuilère).

Démo :

• L'admin a déjà coché la case pour reconnaître le certificat serveur
• Attaque : MiTM sur Enhanced RDP Security
  • on laisse passer les premiers messages pour l'authentification
  • on se met ensuite en MiTM pour la suite afin de récupérer le mot de passe.

Finalement, le passage à TLS n'a pas vraiment amélioré la sécurité de RDP. Conclusion : l'utiliser sur un réseau vraiment sécurisé.

Votre serviteur s'est intéressé au cloud storage tel qu'implémenté par hubiC. Malheureusement, OVH ne fournit pas encore de binaire pour Linux. Eh oui, OVH a choisi de rendre disponible son espace de stockage uniquement via un client lourd. J'ai décidé d'analyser ce programme afin rendre ce cloud storage interopérable avec mon système (c'est légal).

Tout d'abord, certaines personnes arrivent à se connecter depuis Linux. Ces personnes possédaient un compte CloudNAS, le prédécesseur d'hubiC. Pour ces personnes, pas de problèmes. Pour les nouveaux arrivants (comme moi), le sytème de gestion des comptes d'OVH a changé. Un WAS (Web Application Service) est utilisé pour gérer les crédences d'hubiC. En analysant le programme Windows, je me suis aperçu que le client hubiC effectue 3 requêtes avant d'obtenir les informations qui serviront ensuite à la connexion WebDAV. Pour pouvoir se connecter, il est nécessaire d'avoir :

• l'URL du WebDAV
• le login du WebDAV
• le mot de passe du WebDAV

Les 3 requêtes sus-mentionnées sont destinées au serveur ws.ovh.com et permettent d'obtenir ces trois informations indispensables à la connexion WebDAV. Sans plus tarder, voici ces requêtes (en mode raw), toutes à destination de ws.ovh.com en HTTPS :

Requête POST nasLogin :

'POST /cloudnas/r0/ws.dispatcher/nasLogin HTTP/1.1'."\r\n".
'Content-Type: application/x-www-form-urlencoded'."\r\n".
'User-Agent: hubiC/1.0.9 (Windows NT 6.1; fr_FR)'."\r\n".
'Content-Length: 126'."\r\n".
'Connection: Keep-Alive'."\r\n".
'Accept-Encoding: gzip'."\r\n".
'Accept-Language: fr-FR,en,*'."\r\n".
'Host: ws.ovh.com'."\r\n".
''."\r\n".
'session=&params=%7B%20%22email%22%20%3A%20%22<login>%22%2C%20%22password%2
2%20%3A%20%22<password>%22%20%7D'."\r\n".
"\r\n";

Requête POST getNas :

'POST /cloudnas/r0/ws.dispatcher/getNas HTTP/1.1'."\r\n".
'Content-Type: application/x-www-form-urlencoded'."\r\n".
'User-Agent: hubiC/1.0.9 (Windows NT 6.1; fr_FR)'."\r\n".
'Content-Length: 54'."\r\n".
'Connection: Keep-Alive'."\r\n".
'Accept-Encoding:gzip'."\r\n".
'Accept-Language: fr-FR,en,*'."\r\n".
'Host: ws.ovh.com'."\r\n".
''."\r\n".
'session=<id>'."\r\n".
"\r\n";

Requête POST getCredentials :

'POST /cloudnas/r0/ws.dispatcher/getCredentials HTTP/1.1'."\r\n".
'Content-Type: application/x-www-form-urlencoded'."\r\n".
'User-Agent: hubiC/1.0.9 (Windows NT 6.1; fr_FR)'."\r\n".
'Content-Length: 54'."\r\n".
'Connection: Keep-Alive'."\r\n".
'Accept-Encoding: gzip'."\r\n".
'Accept-Language: fr-FR,en,*'."\r\n".
'Host: ws.ovh.com'."\r\n".
''."\r\n".
'session=<id>'."\r\n".
"\r\n";

Et voilà. Ca va renvoyer les trois précieuses informations.

Certains pourraient me demander : mais comment avez-vous fait pour avoir ces informations ? Le serveur d'hubiC est en HTTPS ; on ne peut pas écouter la conversation entre le client et le serveur. Effectivement, sauf que le client tourne sur mon système. Rien ne m'empêche de brancher un débuggeur sur mon programme sur ma machine. En deux mots : OllyDbg, SSL_write.

Bon, comme j'aime aussi le Perl, je fournis le programme qui permet de récupérer les précieux sésames : http://www.protocol-hacking.org/public/hubic.pl

% ./hubic.pl 
Usage: ./hubic.pl -l login [-d] [-h]
% ./hubic.pl -l <mon_login_genre_une_adresse_email>
Password:
URL:      https://cloudnas1.ovh.com/XXXXXXXXXX/
Login:    cloudnas
Password: YYYYYYYYYY

mount -t davfs https://cloudnas1.ovh.com/XXXXXXXXXX/ /mnt

Maintenant, hubiC fonctionne sur tous les systèmes supportant un client WebDAV.

UPDATE : la presse en parle :

• PCinpact
• Journal du lapin
• Presence-PC
• Mac world

UPDATE : autres versions du programme :

• Hubic.py
• getHubicWebdavInfos.ps1

Pour vous souhaiter la bonne année, et un joyeux Noyel, dans le désordre, voici une nouvelle version du "long awaited" SinFP.

Plus d'info ici : http://www.gomor.org/sinfp

Goulag, je ne me suis toujours pas occupé de ton cas ;)

Jeudi 10 Juin

"Ca recommence comme avant".
"Pas tout à fait comme avant".
-- Matrix

09:00 - Présentation des résultats du challenge de reverse du SSTIC

Présentation du classement et remise des prix.

Présentation d'une solution par Arnaud Ebalard NatIsBad :

• décompression de l'archive par 7zip
• reconstruction de 2 fichiers .apk en analysant le format du fichier extrait
• récupération d'un premier message signé (PGP) et chiffré (format spécial)
  • chiffrement de type décalage (ROT)
  • répondre aux énigmes pour trouver des coordonnées GPS
  • un mot de passe est contenu dans une section chiffrée (PGP)

Autre méthode :

• reverse de 2 fichiers .smali
• collecte des infos des coordonnées
• collecte du mot de passe
• reverse de la fonction "deriverclef()" contenue dans la bibliothèque libhello-jni.so
  • bug dans l'utilisation de la fonction cryptographique : seuls les 2 premiers caractères du mot de passe sont pris en compte (résultat : O7)
• on peut ensuite déchiffrer un binaire qui affiche une adresse email (résultat final)

09:45 - Sécurité de la plate-forme d'exécution Java : limites et propositions d'améliorations

Christian Brunette
David Pichardie
Frédéric Guihery
Goulven Guiheux
Guillaume Hiet

Travail collaboratif entre AMOSSYS, l'INRIA et SILICOM.

Constats :

• l'implémentation de la plateforme Java de plus en plus complexe.
• des vulnérabilités récurrentes.
• un mécanisme de contrôle d'accès peu utilisé.

Une question :

• Java est-il adéquat pour le développement d'applications de sécurité ?
  • Voir les résultats d'évaluation de la sécurité Java par l'ANSSI.

L'architecture Java semble simple sur le papier ; mais elle est plus compliquée en pratique (beaucoup de composants ne passant pas par la JVM pour accomplir des fonctions bas niveau). Il existe 3 vérifications de sécurité lors de l'exécution d'une application Java :

• à la compilation (JAVAC)
• au chargement des classes (ByteCode Verifier : BCV)
• à l'exécution (HIT)

Il existe d'autre mécanismes de sécurité :

• un contrôle d'accès orienté code (JPSA)
• un contrôle d'accès orienté identité (JAAS)
• chargement des classes en utilisant du cloisonnement
• vérification de la signature et de l'intégrité des classes

Le composant JPSA est écrit en Java (d'où la nécessité de bien protéger cette partie). Mais la plupart du temps, ce composant est soit inutilisé, soit mal utilisé par les développeurs. Il existe également un certain nombre de problèmes ou de questions à propos de la JVM elle-même :

• rémanence des données confidentielles
• échappement de la vérification de ByteCode (BCV escape)
• quelle confiance dans l'implémentation ("évaluabilité")
  • les propriétés sont-elles effectivement assurées dans l'implémentation de la JVM ?
  • suppression de certaines vérifications ?
• pas ou peu d'intégration avec les protections OS
• pas de contrôle d'accès au sein-même de la JVM

Propositions d'amélioration (pour le langage Java "at large") :

• guide de développement
• guide de configuration et de déploiement
• auditer, rechercher des failles
• limiter la surface d'attaque
• appliquer le contrôle d'accès

Propositions d'amélioration (pour la JVM):

• augmenter la confiance dans le module d'exécution
• proposer un contrôle fin de la durée de vie des données confidentielles
• améliorer l'intégration avec les mécanismes de sécurité de l'OS
• implémenter le contrôle d'accès au sein de la JVM
• étendre les vérification faites par le BCV

Suivi d'un exemple de modification de code pour appliquer ces propositions : éviter la fuite d'objets partiellement initialisés.

Conclusion :

• langage non-parfait, mais au moins pensé dès le départ pour la sécurité
• mais certaines classes d'attaques sont non-couvertes de base (injection SQL, par exemple)
• des faiblesses dans l'architecture et l'implémentation
• faire un effort dans la sécurisation de la bibliothèque de base
• augmenter la confiance dans la JVM (trouver le bon compromis performance vs sécurité)

10:15 - Analyse de l'efficacité du service fourni par une I/O MMU

Eric LACOMBE
Fernand LONE SANG

L'I/O MMU est un mécanisme de sécurité permettant de contrer les attaques DMA. C'est une gestion du contrôle d'accès à la mémoire pour les périphériques. Cela fonctionne en ajoutant une couche de virtualisation sur les adresses mémoires (mapping virtuel). Les attaques DMA sont réalisées :

• soit depuis le CPU
• soit depuis un contrôleur d'E/S

DMA permet un accès directe à la mémoire :

• transfert de données entre contrôleur d'E/S et mémoire pour décharger le CPU.
• l'I/O MMU s'intercale entre les contrôleurs d'E/S et la mémoire pour contrôler l'accès (limiter les zones mémoires accessibles)
• fait de la translation d'adresses mémoire

Intel VT-d implémente l'I/O MMU.

• description de l'architecture matériel (MMU, RAM, chipset, DRHU, ...).
• c'est de la virtualisation de requête DMA.

Vecteurs d'attaques contre l'I/O MMU :

• modification de la configuration d'une DRHU
• altération des tables de pages pour donner accès à de nouvelles pages physiques
• altération des tables de contexte
• altération du registre d'une DRHU (plus difficile à détecter que les autres altérations).
• modification du source-id (spoofing du contrôleur d'E/S)

Exemple de scénario d'attaque :

• permettre une écoute réseau par exploitation d'une vulnérabilité matérielle
• mise en œuvre de l'attaque :
  • FireWire et Ethernet partagent une même identité (accès aux mêmes régions mémoire)
  • du coup, le contrôleur FireWire peut modifier les trames Ethernet reçues !!
• utilisation d'un iPod et de "social engineering" pour rejouer une attaque "pré-enregistrée" lorsqu'il est branché sur le port FireWire de la victime (nécessite le même hardware que l'attaquant, l'attaque étant spécifique au matériel réseau).
• l'attaque utilise FireWire pour modifier à la volée les trames ARP de la carte Ethernet victime, et ainsi rediriger le trafic ("ARP poisonning")

Demo. La vidéo tourne sur la victime, il branche l'iPod. Elle s'arrête, et vient tourner sur la machine de l'attaquant. C'est beau.

Conclusion :

• la solution qu'est l'I/O MMU possède des limites, la principale étant le partage d'identité (source-id) entre différents contrôleurs d'E/S
• nécessite une confiance entre contrôleurs
• ne contrôle pas les échanges internes au "southbridge"

Recommandation :

• utilisation conjointe de VT-d et VT-x, TxT (TxT protège contre l'attaque de modifications sur les tables de contextes et de pages puisqu'elles sont stockées dans la mémoire principale du système)

11:15 - Quelques éléments en matière de sécurité des cartes réseau

Guillaume Valadon
Loic Duflot
Olivier Levillain
Yves-Alexis Perez

Cette présentation est la même (sauf la démo) que celle donnée à CanSecWest 2010. J'en ai déjà fait un résumé sur ce blog. Mais bon, comme j'aime bien, j'en refait un autre (plus court) ici.

Les cartes réseaux sont devenues très complexes (plusieurs processeurs, firmware, contrôleurs, opérations d'administration à distance, ...). Exploiter les cartes réseaux pour :

• empoisonnement ARP, DNS
• SSLStrip
• bref, tout type d'attaque réseau est imaginable

Cas d'étude : "Broadcom NetXtreme". Lors de celle-ci :

• une vulnérabilité a été mise en évidence
• elle est exploitable de la même manière quelque soit l'OS (lien).

Cette carte possède un processeur MIPS qui accède à toute la mémoire de la carte, au SMBus, aux paquets entrant/sortant, à l'espace de configuration PCI. La carte possède des fonctions ASF (envoi d'alertes via le réseau) et doit fonctionner même si plus rien ne marche. Elle supporte aussi les "RMCP Security Extensions" (RSP), ainsi que le support de l'authentification et du contrôle d'intégrité. RMCP utilise un protocole tournant sur le port 664/UDP (toutes les requêtes à destination de ce port sont interceptées par la carte réseau, aucune application sur l'OS ne pourront l'utiliser). L'ASF "legacy" utilise lui le port 623/UDP (même punition, l'OS ne verra aucun paquet à destination de ce port).

L'ASF/RMCP est très simple sur UDP. Mais il y a aussi AMT et IPMI qui sont plus complexes, et sur TCP. Dans le cas d'AMT et IPMI, la carte réseau doit implémenter une pile TCP ... risque d'autres vulnérabilités accru.

Démo de compromission à distance.

12:00 - Honeynet Project en 2010

Sebastien Tricaud - PicViz labs (conférence invitée)

Buts du projet :

• améliorer la sécurité d'Internet à aucun cout pour le public (tout un programme)
• fournir des documents et des outils
• organiser des challenges

L'orateur s'attache ensuite à la description de l'organisation du projet. De manière simplifiée, il est découpé en chapitres ; un chapitre représentant un pays (Canada, USA, Mexique, Brésil, France, Allemagne, Espagne, Norvège, Chine, Iran, ...)

Le projet est orienté sur la recherche, et non sur l'opérationnel. Objectifs :

• piéger nos ennemis
• analyser leurs activités
• se renseigner
• discuter et échanger
• fournir des informations telles que :
  • papiers
  • KYE (Know Your Enemies)
  • KYT (Know Your Tools)

Ces informations sont accessibles via différents média :

• site Web
• blog (des différents acteurs)
• twitter

Exemple de réalisation : travail avec Fyodor ("nmap") pour détecter facilement le vers "Conficker" (travail issu de la recherche du chapitre Allemand). Un script NSE a été écrit pour que tout utilisateur de "nmap" puisse scanner son réseau afin de détecter les machines compromises. Quelques outils :

• Glastopf
• Google Hack Honeypot

Les honeypots s'articules autours de trois grandes catégories :

• serveur/client
• haute/basse interaction
• analyse

D'autres outils :

• Nepenthes : émulateur de vulnérabilités connues.
• PhoneyC : honeypot client écrit en Python
  • interaction avec des pages Web, téléchargement, analyse, alerte (PhoneyC)

Conférencier : sebastien@honeynet.org (Blog LogViz)

14:30 - La sécurité des systèmes de vote

Frédéric Connes

ABSENT

15:00 - Applications Facebook : Quels Risques pour l'Entreprise ?

Alban Ondrejeck
Francois-Xavier Bru
Guillaume Fahrner

ABSENT

15:45 - Projet OpenBSC

Harald Welte (conférence invitée)

Peu de documentation publique sur les protocoles GSM/3G. Et du coup, quasiment aucune évaluation de la sécurité de l'implémentation sur ceux-ci. Les entreprises ne livrent aucune documentation ("closed minded"). Même les gros clients (les opérateurs) de ces produits ("manufacturers") ne reçoivent que peu de documentation, et aucun code source. Peu de personnes connaissent vraiment la suite complète de protocoles. Ils connaissant juste ce qui est nécessaire au bon fonctionnent opérationnel.

GSM, c'est bien plus que la gestion des communications téléphoniques. On trouve également ce protocole dans les endroits suivants :

• BWM peut ouvrir/fermer les portes d'une voiture
• les systèmes d'alarmes
• applications de "Smart Metering"
• GSM-R (système de contrôle de train européen : "European Train Control System"
• les caisses enregistreuses des supermarchés quand quand la caisse est pleine
• numéros de transaction pour le commerce électronique

Les implications sécurité :

• personne ne connait les détails des protocoles et du réseau GSM à part les fabricants
• pas de recherches indépendantes en sécurité
• pas d'implémentations "open source" (of course, j'ai envie de dire)
• retard de 10 ans par rapport à la sécurité sur les protocoles régissant l'Internet
  • pas de firewall, de filtrage ou de détection d'intrusion
  • les opérateurs comptent seulement sur le fait que 'ça va marcher comme prévu'
  • pas de stratégie de gestion des incidents

Des problèmes de spécification :

• chiffrement optionnel
• manque d'authentification mutuelle
• appels 'silencieux'
• obtention des coordonnées GPS de l'appareil via les protocoles RRLP et SUPL (invisible pour l'utilisateur)

Des problèmes d'implémentation :

• fuite de l'information TMSI au changement de réseau
• des parsers TLV peu testés
• options obscures et peu testées

Des problèmes d'opérationnel :

• débordement de champ VLR
• ré-allocation TMSI trop peu fréquente

Mais par où débuter la recherche sécurité ?

• à partir du combiner de téléphone ?
  • certains ont tenté, mais trop difficile (pas d'accès au hardware)
  • tentatives comme TSM30 (THC GSM), mados pour les Nokia DTC3
• à partir de la couche réseau ?

Premières étapes :

• obtenir les spécifications GSM : > 1000 documents PDF
• obtenir un équipement réseau GSM (BTS)
• obtenir des traces réseaux

Note : dans une démo publique, il a fait sonner tous les téléphones de l'assistance ^^

C'est une suite complexes de différentes interfaces avec leurs protocoles associés. Pour l'interface réseau GSM :

• Layer1 : Radio Layer
• Layer2 : LAPDm
• Layer3 : Radio Resource, Mobility Management, Call Control
• Layer4+ : USSD, SMS, LCS

Pour l'interface A-bis, une autre suite de protocoles ...

Il a démarré ses recherches en 2006. En 2008, il a réussit à faire apparaitre son antenne comme un vrai réseau pour son téléphone. 01/2010 : les 25 premières antennes OpenBSC tournent chez des opérateurs. Mais toutes les fonctionnalités GSM ne sont pas implémentées :

• support des équipements BS-11 BTS (E1) et ip.access nanoBTS (IP Based)
• roaming, et envoi de SMS

Note : les iPhones crashent facilement à cause de paquets ne respectant pas les spécifications. L'orateur n'a même pas eu besoin d'utiliser du fuzzing pour s'en apercevoir ...

Problèmes connus des GSM :

• pas d'authentification mutuelle
• algorithme de chiffrement faible
• et puis, de toute façon, le chiffrement est optionnel (et l'utilisateur ne sait pas si c'est on ou off)
• le réseau GSM peut demander au téléphone sa position GPS exacte
• des features obscures de part les spécifications :
  • demander à un téléphone d'appeler tel numéro
  • d'envoyer un FAX par SMS

Utilisation de Scapy pour coder les différentes couches réseau.

Il peut maintenant envoyer des données :

• depuis un rogue network vers les téléphones (OpenBSC, OpenBTS)
• depuis un proxy A-bis vers le réseau ou les téléphones

Liens : GSM Phone Anatomy
OpenBSC
OpenBTS
OsmocomBB

Note : environ 7/8 personnes à développer ce code.

16:45 - Rump Sessions

Les habituelles rumps, mais avec rien de vraiment extra-ordinaire cette année. Ah si, l'excellent Netglub de l'ami Guillaume Prigent.

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)

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.

"Tiens, on dirait que j'ai de moins en moins d'emails ces temps-ci ....". C'est par cette triste pensée que débuta ma recherche de la cause du problème. En effet, je possède un serveur dédié comme nombre de passionnés. Et bien sûr, mon serveur dédié héberge de multiples domaines. Mais surtout, un serveur SMTP pour dans les ténèbres les lier. C'est de ce dernier et de sa configuration dont je vais parler aujourd'hui.

Donc, je ne reçois presque plus de mails. Première hypothèse, plus personne ne m'aime. Non, ça ne tiens pas, j'ai pas été plus méchant ces temps-ci que les temps précédents. Deuxième hypothèse, ma mail queue commence à saturer. Je me connecte en SSH, et là, c'est le drame. Le mailq me donne une liste qui défile pendant près d'une minute. Je traduis pour les incultes : ça veut dire beaucoup beaucoup de messages en attente de livraison.

Mais pourquoi donc que c'est comme ça ? En regardant rapidement, je vois que 80% des messages sont à destination de personnes ayant (ou pas) un mail @yahoo.com.tw. Avec un peu de chance, je n'ai qu'un spammeur qui a repéré une faiblesse chez moi.

Je tente un premier truc : bloquer les adresses IP sources qui me mettent ces messages @yahoo.com.tw dans ma queue (huhu). Mais comme prévu, la liste est longue; je ne retiens pas cette solution. Par contre, en attendant de trouver mieux, je bloque les messages sortant à destination des IP des MX de yahoo.com.tw afin de les décharger de ce load. Sympa knorr.

Deuxième truc : analyser les commandes SMTP. Je capture le trafic SMTP sur mon serveur pendant quelques minutes pour avoir de quoi jouer. Après analyse, voici les data qui me semblent intéressantes :

> EHLO msg-g09pmirpcam
< 250-ns22829.ovh.net
< 250-AUTH LOGIN CRAM-MD5 PLAIN
< 250-AUTH=LOGIN CRAM-MD5 PLAIN
< 250-PIPELINING
< 250 8BITMIME
> AUTH LOGIN
< 334 VXNlcm5hbWU6
> YWRtaW4=
< 334 UGFzc3dvcmQ6
> YWRtaW4=
< 235 ok, go ahead (#2.0.0)
> RSET
> MAIL FROM:<fkp@ns22829.ovh.net>
> RCPT TO:<oprah2073@yahoo.com.tw>
...
> DATA
< 250 flushed
< 250 ok
...
< 354 go ahead
> From: =?BIG5?B?uFW+8KRI?= <fkp@ns22829.ovh.net>
> To: "oprah2073" <oprah2073@yahoo.com.tw>
> Subject: =?BIG5?B?obShtKG0obSkQK3TpKOlsqnxsfOnQaq6pHWnQLROpWm8V6VbpqykSqq6pOiqa6G0?==?BIG5?B?obShtKG0obShtA==?=
> Date: Tue, 19 Jan 2038 11:14:07 +0800
...
< 250 ok 1237657002 qp 1924

Mais que vois-je ? mon serveur accepte les messages à destination d'un domaine que je n'héberge pas ? En l'occurrence, les messages à destination de yahoo.com.tw. Mais pourquoi tant de haine ? En regardant le début de la transaction, je note l'utilisation de AUTH LOGIN. En regardant encore mieux, non seulement la négociation n'échoue pas, mais en plus elle réussit !

Avant de vous traduire le dialogue, oui, pour vous, pauvres mécréants, un petit mot sur AUTH LOGIN. Mon serveur SMTP est (était) configuré pour utiliser la méthode SMTP AUTH LOGIN. Cette méthode permet aux seuls utilisateurs ayant un compte sur mon serveur (je simplifie) de s'authentifier en SMTP, et de se voir attribuer le droit de pouvoir utiliser mon serveur SMTP pour relayer tous leurs messages. Ai confiance en tes users :) L'intérêt est pour eux de ne pas avoir besoin d'utiliser le webmail de mon serveur pour expédier des messages provenant de leur nom de domaine. Mais leur client de messagerie se doit de supporter AUTH LOGIN. Revenons à notre traduction :

> AUTH LOGIN
# Can I haz authenticashun to spam teh interwebs ?
< 334 VXNlcm5hbWU6
# base64_decode => 'Username:'
> YWRtaW4=
# base64_decode => 'admin'
< 334 UGFzc3dvcmQ6
# base64_decode => 'Password:'
> YWRtaW4=
# base84_decode => 'admin'
< 235 ok, go ahead (#2.0.0)
# authentication: WIN

Caugh, caugh. Vous lisez bien, admin/admin et le spammeur est authentifié sur mon serveur. Je me bas presque tous les jours pour que les gens changent les mots de passe par défaut. C'est pas dur merde ! Bon, que celui qui n'a jamais fauté jette la première pêche.

A ma décharge, la faille de configuration de mon serveur était plus sévère. N'importe quel couple login/mot de passe était accepté, et permettait de s'authentifier.

Je recompile donc qmail en désactivant le support AUTH LOGIN, n'ayant pas d'utilisateur s'en servant. Si ils me le demandent, je regarderai de plus près comment configurer ça de manière secure. Je redémarre qmail. Je regarde ma mailq. Je capture du trafic. J'analyse le trafic ... nan, c'est bon :) c'est corrigé. Mais la chose amusante, c'est que le spammeur en question n'utilise plus la méthode AUTH LOGIN. Voyons le nouveau trafic :

< 220 ns22829.ovh.net ESMTP
> EHLO msg-g09pmirpcam
< 250-ns22829.ovh.net
< 250-PIPELINING
< 250 8BITMIME
< RSET
< 250 flushed
> MAIL FROM:<ins@ns22829.ovh.net>
> RCPT TO:<roety503@yahoo.com.tw>
...
< 250 ok
< 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)
...

Voilà qui va beaucoup mieux. Mais vous avez remarqué ? le spammeur n'utilise plus la méthode AUTH LOGIN. Ce qui veut dire que son robot analyse la sortie de la commande EHLO, et si le serveur SMTP supporte AUTH LOGIN, il tente une authentification. Au moins avec admin/admin. Je ne vais pas analyser plus que ça, mais il est possible que le robot brute-force un minimum avec différents couples login/mot de passe. Intéressant spammeur, on se reverra peut-être. A+