• XeeK v0.1b : archive comportant le client, le serveur, ainsi que l’aide (fichiers INSTALL.txt et README.txt)
• Slides de la conférence (PDF)

J’éditerai ce billet prochainement pour y ajouter un petit tutorial concernant l’installation et l’utilisation de XeeK.

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.

]]> https://www.segmentationfault.fr/securite-informatique/sstic-2010/feed/ 9 https://www.segmentationfault.fr/securite-informatique/resume-dc18-ctf-quals/ https://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…

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

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.

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

Or, deux collègues de Sysdream, Stéfan Leberre (Heurs) et Damien Cauquil (Virtualabs), viennent de trouver une méthode permettant de la contourner sous certaines conditions. Leur article ainsi que leur Proof Of Concept est disponible sur le site de Sysdream :

• L’article Bypassing SEHOP
• Proof Of Concept fonctionnant sous Windows 7

Il était une fois une include non protégée…

Je me lance donc dans l’exploration de l’arborescence en récupérant quelques fichiers intéressants. Commepar exemple /proc/version, qui indique que le serveur tourne sous une Ubuntu basée sur un kernel 2.6.25. Je regarde également une partie de la configuration Apache dans /etc/apache2/apache2.conf, la liste des utilisateurs dans /etc/passwd. /etc/shadow est bien évidemment non accessible car Apache n’est pas lancé par le root. Mais sachant qu’un exploit touchant les Linux non patchés a récemment été publié,  je me dis qu’il doit certainement être possible de rooter le serveur à partir de là. Si j’arrive à exécuter des commandes sur le serveur avec les droits d’Apache, devenir root ne devrait pas être dur en utilisant cet exploit…

Je cherche donc un moyen d’utiliser la faille include pour pouvoir exécuter du code. Je pense en particulier à l’injection de commandes dans les logs Apache. Seul problème : ils ne sont lisibles que par le root, donc pas par Apache (il suffit de tester pour s’en rendre compte rapidement). Où vais-je donc pouvoir injecter mes commandes… ? Quels sont les fichiers manipulés par Apache et PHP dans lesquels on peut écrire indirectement et lire ensuite ? Sur le coup, je sèche…

…un site utilisant les sessions…

Là, Heurs et Virtualabs me donnent la réponse : les sessions PHP. En effet, PHP stocke les variables de session dans des fichiers (elles sont sérialisées) qui se situent dans /var/lib/php5/. Leur nom suit le format sess_$PHPSESSID où $PHPSESSID est l’identifiant de session qui est envoyé dans le cookie, donc facilement récupérable. Et, coup de chance, il se trouve que le challenge en question utilise les sessions pour stocker l’utilisateur courant et son mot de passe. Champs qui ne sont sont bien pas vérifiés lors de la soumission du formulaire

C’est parti ! Je crée un compte bidon avec quelque chose comme <?php system($_GET['c']); ?> pour le login. Je soumet, récupère le cookie contenant l’identifiant de session, et inclus le fichier de session correspondant. Et là, j’obtiens une jolie backdoor PHP sur le serveur. Rudimentaire, certes, mais fonctionnelle ! A partir de là, j’en conçois une légèrement plus élaborée, que je place sur un de mes serveurs, et que je fais télécharger au serveur victime avec un wget (suivi d’un mv). Je peux maintenant exécuter des commandes PHP à volonté, lire des fichiers sources, etc. Je récupère une autre backdoor permettant d’obtenir un remote shell sur ma machine. J’ouvre un port avec Netcat sur ma machine, j’upload et lance la backdoor, et le tour est joué.

… et un kernel non patché.

Je peux maintenant exécuter des commandes de façon interactive, mais toujours avec les droits d’Apache. Je télécharge un des exploits sock_sendpage de Milw0rm, le compile sur le serveur (gcc y était installé, cool), je lance l’exécutable généré, et bing ! Root sur le serveur . Comme mon but n’est pas de planter le serveur, je m’arrête ici. Enfin je prends quand même soin de supprimer toute trace de l’intrusion dans les logs. Et je garde un petit screenshot, pour envoyer au propriétaire du site, l’histoire de le prévenir. Bien entendu, pour envoyer le mail j’ai pris soin de créer un mail anonyme et de passer par un proxy, au cas où le propriétaire serait furax et menacerait de porter plainte… Heureusement, celui-ci est sympa ; il me répond rapidement et me remercie de l’avoir prévenu. Et vous savez le comble de l’histoire ? Ce serveur ne lui appartenait pas, il ne disposait pas lui-même des droits root

Conclusion

Je crois que cette histoire (vraie, pour ceux qui douteraient) illustre plutôt bien et de façon concrète la marche à suivre employée par un attaquant afin de prendre la main sur un serveur : exploitation d’une faille distante pour récupérer des informations, exécution de commandes dans le contexte du processus vulnérable, élévation de privilèges en utilisant un local root, et nettoyage des logs. De plus, cet exemple démontre que ce n’est pas parce que l’on a interdit l’inclusion de fichiers distant que l’on a un appel à include() sécurisé.

J’insiste enfin sur le fait que ce que j’ai réalisé ici était à la portée d’un script kiddie pour peu qu’il connaisse la faille, sache utiliser une backdoor PHP et compiler un exploit. Administrateurs de challenges de hack PHP, méfiez-vous : reproduire des applications vulnérables c’est bien, mais pensez à vous protéger un minimum pour éviter le pire…

Pour cet article, on se propose d’écrire un driver qui effectuera ce hook et qui détournera RDTSC afin de rendre les valeurs 11223344 et 55667788 respectivement dans EAX et EDX lorsqu’on l’appelle. Je présente en premier lieu la théorie nécessaire pour l’attaque, puis décris comment l’implémenter sous Linux. Enfin, je détaille une difficulté majeure à laquelle on peut faire face sur les distributions récentes telles qu’ArchLinux : le flag TIF_NOTSC.

L’instruction RDTSC et le flag TSD

RDTSC signifie « ReaD TimeStamp Counter », autrement dit elle permet de lire le compteur de temps du processeur, incrémenté à chaque cycle d’horloge. Ce compteur n’est autre que le MSR IA32_TIME_STAMP_COUNTER (cf manuel 3B d’Intel, section 18.11). Celui-ci fait 64 bits et est retourné dans EDX et EAX lors de l’appel à RDTSC. Les applications classiques s’en servent généralement pour :

• Effectuer des mesures de performance (benchmark) sans passer par les fonctions du noyau
• Générer des nombres pseudo-aléatoires, à cause du caractère à priori non prévisible de ce compteur (surtout des bits de poids faible)
• Détecter des débogueur en mesurant des deltas entre deux instructions fixes ; si un débogueur est présent et qu’un breakpoint a été posé (ou que le mode step-by-step a été utilisé), le temps écoulé sera beaucoup plus long donc il est facile à l’application de quitter.

Cependant, ce n’est pas exactement comme cela qu’est décrit l’instruction RDTSC dans le manuel 2B d’Intel. En effet, on peut y lire le pseudo-code suivant :

IF (CR4.TSD = 0) or (CPL = 0) or (CR0.PE = 0)
THEN EDX:EAX ? TimeStampCounter;
ELSE (* CR4.TSD = 1 and (CPL = 1, 2, or 3) and CR0.PE = 1 *)
#GP(0);
FI;

On y apprend que le registre CR4 possède un flag TSD qui, s’il est activé, provoquerait une exception lorsque RDTSC est appelé dans un ring supérieur à 0 (mode protégé). Cette exception est la General Protection Fault, notée #GP et définie à l’index 13 dans l’IDT (table des interruptions). L’OS traite cette exception par une routine du noyau qui n’est généralement pas prévue pour gérer ce cas, donc on aura par défaut droit à un crash du programme ayant appelé RDTSC. Sous Linux, cela se traduit par l’envoi d’un signal SIGSEGV au processus, causant une segmentation fault.

IDT hooking

Pour hooker RDTSC, il faut donc dans un premier temps mettre à 1 le flag TSD (bit 2) de CR4 pour déclencher une #GP. Mais ce que nous voulons, c’est appeler notre fonction et non celle du noyau lors de l’exception. Il va donc falloir patcher l’IDT en remplaçant l’adresse du handler 13 par le notre ; autrement dit, faire du IDT hooking.

L’IDT recense des descripteurs explicités à la section 5.11 du manuel 3A d’Intel. Les descripteurs suivant plus ou moins le même format :

Descripteur d'interruption

Comme d’habitude dans la doc Intel, le schéma se lit de bas en haut et de droite à gauche (little endian, quand tu nous tiens…). A la mode des autres descripteurs propres à l’architecture x86, on constate que le champ Offset est découpé en deux parties : poids forts et poids faibles. C’est ce champ qui pointe vers le handler à exécuter lors de l’exception. Il suffit de remplacer sa valeur par l’adresse d’une de nos fonctions, et nous pourrons alors détourner le flux d’exécution lors d’un appel ring 3 à RDTSC.

Trouver l’IDT

Pour pouvoir faire un hook de l’IDT, il faut d’abord savoir la trouver. En fait, il est nécessaire de préciser que pour les processeurs multi-coeur, il n’y a pas une seule IDT mais plusieurs :  une par cœur. Il est donc en théorie nécessaire de hooker toutes les IDT pour éviter les problèmes. Pour connaître l’IDT référencée par un cœur, il suffit d’utiliser l’instruction SIDT sur ce cœur. Cette instruction est accessible en ring 3 ; voici un code qui l’illustre. Cependant, si vous utilisez Linux dans une machine virtuelle telle que VirtualBox, il se peut que vous rencontriez des problèmes en fonction de vos options de virtualisation. En effet, l’instruction SIDT n’est pas toujours bien émulée par l’hyperviseur et il se peut que la valeur qu’elle retourne soit erronée. Préférez-donc la solution suivante si vous tenez à faire vos tests dans une VM.

Même si un procceseur peut avoir plusieurs IDT, Linux n’en utilise qu’une car chaque cœur référence la même. Celle-ci est définie dans le noyau par le symbole idt_table. Pour connaître son adresse, tentez :

grep idt_table /proc/kallsyms

Le premier champ retourné est l’addresse de l’IDT. Si cela ne vous renvoie rien, il vous faudra à la place utiliser le fichier /boot/Symbol.map, généré à la compilation du noyau. Il se peut que son nom soit quelque peu différent ; par exemple sous Ubuntu il suit le format /boot/System.map-$(uname -r) alors que sous ArchLinux il s’appelle /boot/System.map26.

Conception du handler

Une bonne conception du nouveau handler d’interruption est cruciale pour éviter de rendre instable tout le système. En effet, #GP est utilisée non seulement pour RDTSC mais aussi à chaque fois qu’un check de privilèges échoue (pour une bonne ou une mauvaise raison) dans l’OS, autrement dit un sacré paquet de fois… Autant dire qu’il est préférable de laisser l’OS gérer ces cas là tout seul.

Pour cela, il va falloir filtrer dans un premier temps les #GP dues à RDTSC et celles dues à une autre instruction. Détecter l’instruction fautive est facile vu que l’EIP a été empilé ; il suffit de le regarder, d’examiner ce qu’il pointe et de comparer cette valeur à l’opcode de RDTSC : 0F 31, soit 0x310F en mot de 16 bits little endian. Si cela ne correspond pas, on saute sur le handler de base de l’OS pour ne pas tout crasher.

Ce n’est pas tout : les programmes ring 3 de l’OS aussi utilisent RDTSC. Si nous leur rendons des valeurs comme 0×11223344, ils risquent d’avoir un comportement plutôt imprévisible, surtout s’ils s’en servent comme base de temps. J’ai d’ailleurs testé sous Linux ; Cron a segfaulté instantanément et la machine est devenue inutilisable en quelques secondes.

Bref, il faut se débrouiller pour rendre la bonne valeur à ces programmes. La solution est d’émuler RDTSC dans le driver, et de transmettre les résultats dans EAX et EDX au ring 3. Mais comment savoir quand retourner les bonnes et valeurs et les fakes ? La solution la plus simple qui m’est venue à l’esprit est d’utiliser le PIDs du processus courant, en supposant que l’on connaisse le PID à hooker. Pour transmettre au driver le PID du processus en question, on peut utiliser des IOCTLs, justement prévues pour la communication ring 3 – ring 0. Une fois que l’on a le PID, il suffit de consulter le PID courant et on peut savoir si on doit émuler RDTSC ou forger les valeurs.

Récupération du PID courant

Nous avons quasiment tout ce qu’il faut pour implémenter cette attaque sous Linux. La seule chose qu’il nous manque, c’est un moyen dé récupérer le PID du processus courant lorsque l’on est dans un handler d’interruption. Après lecture en diagonale du chapitre 7 d’Understanding The Linux Kernel 3rd edition, on constate qu’il existe une macro nommée current qui permet de récupérer un pointeur vers le descripteur de processus courant. Après avoir testé cette macro, je me suis rendu compte qu’elle ne marche en fait pas dans le contexte d’un handler d’interruption. Il faut utiliser à la place la fonction current_thread_info() qui marche à tous les coups. A partir de là, récupérer le PID est très simple, via l’expression suivante : current_thread_info()->task->pid.

Implémentation 1

Nous pouvons maintenant implémenter l’attaque. Je l’ai réalisé sans problèmes particulier sur une Ubuntu 9.04 avec un noyau 2.6.28, sur processeur AMD dualcore. Les sources sont disponibles plus bas ; voici les points principaux.

//Typedefs
typedef unsigned char u_int8;
typedef unsigned short u_int16;
typedef unsigned int u_int32;
typedef unsigned long long int u_int64;

/**
 * An IDT entry. Cf Intel SDM 3A
 */
typedef struct {
 u_int16 low_offset;
 u_int16 selector;
 u_int8 unused_lo;
 u_int8 segment_type:4;
 u_int8 system_segment_flag:1;
 u_int8 DPL:2;
 u_int8 P:1;
 u_int16 hi_offset;
} __attribute__((packed)) IDTENTRY_ST, *P_IDTENTRY_ST;

Dans un premier temps, on déclare la structure d’un descripteur d’interruption. On fera particulièrement attention à bien spécifier __attribute__((packed)) pour spécifier au compilateur de ne pas faire de padding entre les champs. La fonction effectuant le hook est ci-après :

//Interrupt handlers
u_int32 old_int_handler, new_int_handler2;

void HookOneIDT (P_IDTENTRY_ST _p_IDT, u_int32 _interrupt_number,
                 u_int32* _old_address, u_int32 _new_address)
{
 asm("cli\n\t");

 *_old_address =  ((_p_IDT[_interrupt_number].hi_offset << 16)
                | (_p_IDT[_interrupt_number].low_offset));
 _p_IDT[_interrupt_number].hi_offset = (_new_address >> 16) & 0xFFFF;
 _p_IDT[_interrupt_number].low_offset = (_new_address & 0xFFFF);

 asm("sti\n\t");
}

Rien de particulier ici, à part une désactivation temporaires des interruptions. D’ailleurs, pour être plus rigoureux, il aurait fallu les désactiver sur tous les cœurs, mais comme cette fonction sera appelée avec interrupt_number = 13, qui n’est de toutes façon pas masquable, il n’y a pas de risque.

Le nouveau handler d’interruption est codé à part dans un fichier assembleur. Il s’agit en fait d’un squelette qui sauvegarde le contexte et appelle une fonction C, pour des raisons de commodité :

.globl interrupt_handler

//The interrupt handler.
//This function must be naked. Since it's not possible with gcc on x86 platforms, we put it in a separate asm file.
interrupt_handler: 

 //Save registers
 pusha
 pushf

 //Call our hook function and  the parameter
 //Since convention call of my_func_handler is fastcall, parameter has to be in %ecx
 mov %esp, %ecx
 call my_func_handler

 //Check the return value
 cmp $1, %eax

 //If 1, throw the exception away
 je  my_exit

 //Otherwise, restore registers
 popf
 popa

 //Jump to the original handler
 jmpl * old_int_handler

my_exit:

 //Restore registers
 popf
 popa

 //Pop interrupt error code
 add $4, %esp

 //Return from interrupt
 iret

La fonction appelée, my_func_handler, doit déterminer la nature de l’exception et la traiter si besoin en détournant RDTSC. On utilise son code de retour pour savoir si l’on repasse la main au handler par défaut de Linux, ou si on se contente de retourner en userland.

//Opcode for RDTSC : 0F 31 => 31 OF in little endian
#define RDTSC_OPCODE 0x310F

//Size of RDTSC instruction
#define RDTSC_SIZE   2

/**
 * Interrupt stack structures
 */
typedef struct
{
 u_int32 edi;
 u_int32 esi;
 u_int32 ebp;
 u_int32 esp;
 u_int32 ebx;
 u_int32 edx;
 u_int32 ecx;
 u_int32 eax;
} PUSHA_ST, *P_PUSHA_ST;

typedef struct
{
 u_int32 error_code;  // !! Check Intel Manuals to see if the error code is present or not
 u_int32 eip;
 u_int32 cs;
 u_int32 eflags;
 u_int32 esp;
 u_int32 sp;
} INT_STACK_HARD_ST, P_INT_STACK_HARD_ST;

typedef struct
{
 u_int32              eflags;

 PUSHA_ST             pusha_st;
 INT_STACK_HARD_ST    int_stack_hard_st;

} MY_INT_STACK_ST, *P_MY_INT_STACK_ST;

/**
 * Return current PID
 */
unsigned int GetCurrentPID (void)
{
 // !!! The 'current' macro doesn't work in interrupt context !
 // !!! We have to use current_thread_info()->task instead
 return current_thread_info()->task->pid;
}

/**
 * Function called by the interrupt handler.
 *  !! WARNING !! Don't call printk() inside, or the kernel will freeze !
 *
 * @param stack pointer to the stack
 * @return 0 if this is a normal #GP exception,
 * 1 if it is due to our RDTSC hook
 */
u_int32  __attribute__((__fastcall__))
         my_func_handler (P_MY_INT_STACK_ST stack)
{
 //nb_interrupts++;+
 asm volatile("lock incl nb_interrupts\n\t");

 //Detect if the instruction that triggered the exception is RDTSC
 if(* (u_int16*) stack->int_stack_hard_st.eip == (u_int16) RDTSC_OPCODE)
 {
 //Check who is executing RDTSC
 if(GetCurrentPID() == pid_to_hook)
 {
 //Change EAX and EDX with magic values
 stack->pusha_st.eax = 0x11223344;
 stack->pusha_st.edx = 0x55667788;
 }
 else
 {
 //Perform a normal call to RDTSC
 RDTSC_ST rdtsc;
 RDTSC(&rdtsc);

 stack->pusha_st.eax = rdtsc.eax;
 stack->pusha_st.edx = rdtsc.edx;
 }

 //Increment EIP
 stack->int_stack_hard_st.eip += RDTSC_SIZE;

 return 1;
 }
 else
 {
 return 0;
 }

}

Il y a plusieurs détails qui ont leur importance. D’une part,on définit des structures correspondant à l’état de la pile lors de l’appel à cette fonction. Cela inclut les registres généraux pushés par PUSHA ainsi que les valeurs pushés automatiquement par le processeur. Il faut faire attention à bien inverser leur ordre relativement aux specifications d’Intel, vu que la pile croît des addresses hautes vers les basses. On récupère l’EIP empilé, on déréférence ce pointeur et on compare le mot de 16 bits avec l’opcode de RDTSC renversé (vu qu’il se trouve en mémoire, donc en little-endian). On émule RDTSC su besoin, et on n’oublie pas d’incrémenter EIP afin de sauter par dessus l’instruction lors du retour. On notera que le debug de cette fonction n’est pas trivial, car il est impossible d’utiliser des fonctions comme printk() à l’intérieur.

Voici désormais la partie relative aux IOCTLs. Je n’ai pas détaillé cette partie précédemment car elle fait plutôt partie d’un choix d’implémentation.

#include <linux/ioctl.h>

//The device name in /proc/devices
#define DEVICE_NAME        "rdtsc_exploit"

//The name of the device file in /dev
#define DEVICE_FILE_NAME   "/dev/rdtsc_exploit"

//IOCTL command codes
#define IOCTL_SET_PID    _IOWR(0, 0, unsigned int)

//Device major and minor numbers
static dev_t g_device_num;

//Count the number of hooked interrupts
extern volatile unsigned int nb_interrupts;

//The file_operation structure, to link the device
//to the appropriate handlers
static struct file_operations g_fops = {
 .owner   = THIS_MODULE,
 .ioctl   = my_ioctl,
};

//Char device structure
static struct cdev g_device;

Sous Linux, pour pouvoir communiquer avec un module en utilisant des IOCTLs, il faut créer un périphérique virtuel en mode caractère (char device) et lui assigner un handler l’ioctl. Ce device possèdera un numéro majeur dynamiquement alloué par le noyau. Pour le numéro mineur, nous choisissons simplement 0. Une fois ces ressources allouées, nous enregistrons le device ce qui a pour effet de le faire apparaître dans /proc/devices. Tout ce procédé est fort bien décrit aux chapitres 3 et 6 de Linux Device Drivers, 3rd edition, livre libre que je vous conseille vivement.

/**
 * Create the device
 */
int create_device (void)
{
 //Allocate the device major and minor
 if(alloc_chrdev_region(&g_device_num, 0, 1, DEVICE_NAME))
 {
 printk(KERN_INFO "ERROR: alloc_chrdev_region FAILED\n");
 return -1;
 }

 //Initialise the device
 cdev_init(&g_device, &g_fops);

 //Fill in some fields (optional)
 g_device.owner = THIS_MODULE;
 g_device.ops = &g_fops;

 //Register the device into the kernel
 if(cdev_add(&g_device, g_device_num, 1))
 {
 printk(KERN_INFO "ERROR: cdev_add FAILED\n");
 return -1;
 }

 printk(KERN_INFO "Device registrated successfully - name = %s, "
                  "major = %d, minor = %d\n", DEVICE_NAME,
                  MAJOR(g_device_num), MINOR(g_device_num));

 return 0;
}

/**
 * Delete the device
 */
void delete_device (void)
{
 //Unregister the device
 cdev_del(&g_device);

 //Unregister the device number
 unregister_chrdev_region(g_device_num, 1);
}

Ces deux fonctions réalisent la création et la suppression du device.

Pour manipuler le flag TSD de CR4, on cree les fonctions suivantes :

//Flag of CR4 that disable RDTSC in userland
#define FLAG_DISABLE_USER_RDTSC 0x4

/**
 * Get CR4 value
 */
u_int32 GetCR4 (void)
{
 u_int32 res = 0;

 asm volatile (
 "push %%eax\t\n"
 "mov %%cr4, %%eax\t\n"
 "mov %%eax, %0\t\n"
 "pop %%eax\t\n"
 : "=m"(res));

 return res;
}

/**
 * Set CR4 value
 */
void SetCR4 (u_int32 _new_cr4)
{
 asm volatile(
 "push %%eax\t\n"
 "mov %0, %%eax\t\n"
 "mov %%eax, %%cr4\t\n"
 "pop %%eax\t\n"
 : : "m" (_new_cr4));
}

/**
 * Enable userland calls to RDTSC
 */
void EnableUserRDTSC (void)
{
 SetCR4(GetCR4() & ~FLAG_DISABLE_USER_RDTSC);
}

/**
 * Disable userland calls to RDTSC
 */
void DisableUserRDTSC (void)
{
 SetCR4(GetCR4() | FLAG_DISABLE_USER_RDTSC);
}

On notera au passage la syntaxe assez inhabituelle de l’assembleur inline de GCC, notemment les doubles % nécessaires puisque l’on utilise des références (%0), ainsi que les \n\t en fin de ligne. Et bien entendu, les arguments inversés par rapport à la syntaxe officielle d’Intel.

Lors du chargement du driver, il suffira de hooker l’IDT et de positionner le flag CR4.TSD. Cependant, cette dernière opération doit être faite sur tous les coeurs. On utilisera donc la macro on_each_cpu().

//Hook the General Protection Fault handler (0x0D)
#define INTERRUPT_VECTOR_TO_HOOK 0x0D

#include <linux/module.h>  /* Needed by all modules */
#include <linux/kernel.h>  /* Needed for KERN_ALERT */
#include <linux/init.h>     // Needed for the macros

#include "../include/defines.h"
#include "hook.h"
#include "device.h"

static int module_load(void)
{
 Hook();
 create_device();

 //Must return 0, otherwise the module is not loaded
 return 0;
}

static void module_unload(void)
{
 delete_device();
 UnHook();
}  

module_init(module_load);
module_exit(module_unload);

/**
 * Hook
 */
void Hook ()
{
 //Get the IDT address (all CPUS use the same)
 P_IDTENTRY_ST pIDT = GetIDTSoft();

 printk(KERN_INFO "interrupt_handler = %08x\n", (u_int32) interrupt_handler);

 //Hook interrupt handler
 HookOneIDT(pIDT, INTERRUPT_VECTOR_TO_HOOK,
            &old_int_handler, (u_int32) interrupt_handler);

 //Hook RDTSC
 on_each_cpu(DisableUserRDTSC, 0, 0);
}

/**
 * Unhook
 */
void UnHook ()
{
 //Unhook RDTSC
 on_each_cpu(EnableUserRDTSC, 0, 0);

 //Unhook interrupt handler
 HookOneIDT(GetIDTSoft(), INTERRUPT_VECTOR_TO_HOOK,
            &new_int_handler2, old_int_handler);
}

Dans mon prototype, je récupère l’adresse de l’IDT en userland dans le Makefile…

IDT_ADDRESS = "0x`grep idt_table /boot/System.map-2.6.28-11-generic
               | cut -d ' ' -f 1`"

… que je passe en paramètre à GCC lors de la compilation avec le flag -D. Le module la récupère comme une constante pré-processeur :

/**
 * Get a pointer to the IDT - the soft way.
 * Works perfectly in VMs, but we either have to hardcode the IDT offset,
 * or read it from userland ('grep idt_table /proc/kallsyms'
 * or 'grep idt_table /boot/System.map').
 */
P_IDTENTRY_ST GetIDTSoft (void)
{
 P_IDTENTRY_ST pIDT = 0;

 pIDT = (P_IDTENTRY_ST) IDT_ADDRESS;

 return pIDT;
}

En userland, il faudra transmettre le PID à hooker au device, ce qui se fait par le code suivant :

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <fcntl.h>
#include <sys/ioctl.h>

#include "defines.h"

int main(int ac, char **av)
{

 //int i;
 int fd;
 int pid_to_hook;

 if(ac != 2)
 {
 printf("Usage: set_pid pid\n");
 printf("Set the pid to hook.\n\n");
 exit(0);
 }

 pid_to_hook = atoi(av[1]);

 if(pid_to_hook <= 0)
 {
 fprintf(stderr, "Error, pid must be > 0.\n");
 exit(1);
 }

 //Open the device in order to communicate with the driver
 fd = open(DEVICE_FILE_NAME, O_RDONLY);

 if(fd == -1)
 {
 printf("Error: %s does not exist!\n", DEVICE_FILE_NAME);
 exit(1);
 }

 //Send IOCTLs to the driver to set the pid do hook
 if(ioctl(fd, IOCTL_SET_PID, pid_to_hook))
 {
 fprintf(stderr, "Error setting the pid.\n");
 }
 else
 {
 printf("pid set successfully.\n");
 }

 //Close the device
 close(fd);

}

Enfin, la routine de traitement de l’IOCTL qui sert à récupérer le PID dans le module est relativement simple :

/**
 * IOCTL handler
 */
int my_ioctl (struct inode * _inode, struct file * _file,
              unsigned int _ioctl_num, unsigned long _ioctl_param)
{
 struct task_struct *task;

 switch(_ioctl_num)
 {
 //Set the PID
 case (IOCTL_SET_PID):

 pid_to_hook = (unsigned int) _ioctl_param;

 break;

 default:
 printk(KERN_INFO "rdtsc_exploit: ERROR: Unsupported ioctl code: "
                  "%08x.\n", _ioctl_num);
 }
 return 0;
}

Test

Après avoir compilé le tout, on charge le module :

# insmod module/rootkit.ko
# grep rdtsc_exploit /proc/devices
250 rdtsc_exploit
# mknod /dev/rdtsc_exploit c 250 0

On lance le programme exécutant RDTSC dans un shell à part :

$ exe/rdtsc/rdtsc
Press <Enter> to call rdtsc. Press q to quit.

RDTSC result (edx : eax) = (0000126d : 8c1cc9a2)

RDTSC result (edx : eax) = (0000126d : a38e75be)

Puis on envoie son PID au module avec :

# exe/set_pid/set_pid $(pidof rdtsc)
pid set successfully.

Et on revient au terminal précédent, en constatant que le hook fonctionne bien :

RDTSC result (edx : eax) = (55667788 : 11223344)

RDTSC result (edx : eax) = (55667788 : 11223344)

RDTSC result (edx : eax) = (55667788 : 11223344)

On n’oubliera pas de décharger le module avec :

# rmmod rootkit
# rm /dev/rdtsc_exploit

Problème avec ArchLinux

En testant l’implémentation précédente avec deux distributions ArchLinux de noyaux 2.6.29 et 2.6.30, j’ai constaté qu’ell ne marchait tout simplement pas. En faisant plusieurs tests, je constate que le handler de #GP est bien hooké, mais RDTSC ne l’est pas du tout car le programme de test affiche toujours des valeurs normales. J’affiche la valeur de CR4.TSD à plusieurs reprises, et je vois que de temps en temps, il repasse à 0, ce qui expliquerait pourquoi RDTSC n’est pas détournée.

Après plusieurs recherches, je tombe sur ce blog, qui pointe du doigt quelques bizarreries du noyau Linux concernant justement le flag TSD. Apparemment, il serait possible de l’activer ou non pour certains processus seulement. Il s’agit du Thread Information Flag TIF_NOTSC définit dans le fichier arch/x86/include/asm/thread_info.h du noyau. Ce flag est plus ou moins l’équivalent du flag TSD, mais dans le contexte de chaque processus. Il est possible de le définir avec l’appel système prctl en utilisant l’option PR_SET_TSC. La valeur PR_TSC_ENABLE revient à positionner TSD = 0, tandis que PR_TSC_SIGSEGV est équivalent à TSD = 1.

Ces flags existent déjà dans les noyaux 2.6.28 d’Ubuntu 9.04 ; je n’ai pas encore bien saisi pourquoi ceuxi-ci sont effectivement appliqués sur ArchLinux. Le blog cité précédemment parle de l’option de configuration CONFIG_SECCOMP du noyau, présente sur ArchLinux, mais visiblement désactivée ia le flag TIF_SECCOMP qui vaut 0 pour tous les processus. Je vais continuer mes recherches de ce côté… Si toutefois vous avez des explications, je suis preveur .

Implémentation 2

En attendant, il reste tout de même effectuer le hook de RDTSC. Il suffit de positionner le flag TIF_NOTSC du processus en question à PR_TSC_SIGSEGV. Cela peut se faire en appelant prctl, mais cette technique n’est pas vraiment convenable car un hook se doit d’être extérieur au processus. La technique consiste donc à émuler le fonctionnement de cet appel système au sein de notre module. Il nous suffit de parcourir la liste chainée des processus, d’isoler celui qui a le bon PID, et à positionner son flag. Cela revient à modifier la fonction my_ioctl() comme ceci :

/**
 * IOCTL handler
 */
int my_ioctl (struct inode * _inode, struct file * _file,
              unsigned int _ioctl_num, unsigned long _ioctl_param)
{
   struct task_struct *task;

   switch(_ioctl_num)
   {
      //Set the PID
      case (IOCTL_SET_PID):

         pid_to_hook = (unsigned int) _ioctl_param;
         printk(KERN_INFO "rdtsc_exploit: pid_to_hook = "
                          "%d.\n", pid_to_hook);

         for_each_process(task) {
            if(task->pid == pid_to_hook){
               test_and_set_ti_thread_flag(task_thread_info(task), TIF_NOTSC);
               printk("TIF_NOTSC set for process %d\n", task->pid);
            }
         }

      break;

      default:
         printk(KERN_INFO "rdtsc_exploit: ERROR: Unsupported ioctl code: "
                          "%08x.\n", _ioctl_num);
   }
   return 0;
}

La macro for_each_process() définie dans linux/sched.h permet d’itérer très simplement sur les threads du système. On utilise la fonction test_and_set_ti_thread_flag() afin de positionner le flag TIF_NOTSC du thread en question. On notera qu’il n’y a même plus besoin de modifier à la main CR4 à l’initialisation.

Sources

Téléchargez les sources

Les sources incluent l’implémentation 2, sachant que celle-ci fonctionne aussi bien sur les deux distributions que j’ai testées (Ubuntu et ArchLinux). Les lignes spécifiques à la 1ère implémentation sont commentées, donc vous pouvez toujours jouer avec et voir le résultat que vous obtenez.

Pour compiler, invoquez simplement make à la racine de rdtsc_exploit. Si jamais cela ne compile pas, éditez le fichier module/Makefile, et indiquez le bon chemin vers votre fichier /boot/System.map. Vérifiez également que le fichier module/handler.S a bien un S majuscule concernant son extension.

Les fichiers fournis sont organisés comme ceci :

• module/ contient les sources du module
• exe/ contient deux sources d’exécutables :
  • rdtsc : programme de test exécutant RDTSC à chaque appui sur une touche. Il contient aussi un fichier de test du noyau, disable-tsc-test.c, que j’ai jugé intéressant de garder pour des tests. A compiler séparément.
  • set_pid : programme prenant en paramètre le PID de rdtsc et l’envoyant au module par ioctl
• scripts/ contient trois scripts permettant d’automatiser le chargement du module et la création du device. load_hook.sh et unload_hook.sh appellent en réalité load.sh, capable de charger/décharger un module et créer/détruire son device.

Applications

Pour terminer, voici quelques possibilités offertes par le hook de RDTSC :

• Empoisonnement des générateurs de nombres pseudo-aléatoires : Certaines applications utilisent RDTSC comme source d’aléa, pour générer des valeurs pseudo-aléatoires qui peuvent par exemple être utilisées pour la génération de clé de chiffrement. En forçant à RDTSC à renvoyer des valeurs bien précise, on peut injecter des valeurs bien précises dans l’algorithme de génération et pouvoir prédire plus facilement son résultat.
• Anti-anti-debuging : Comme dit au premier paragraphe, une technique d’anti-debug consiste à utiliser RDTSC pour estimer le temps passé entre deux instructions et le comparer à une valeur seuil. Une technique d’anti-anti-debug peut donc être de hooker RDTSC et de retourner des valeurs plausibles à l’application, en masquant le fait que celle-ci est en train de se faire déboguer. C’est précisément ce que fait le plugin Olly Advanced d’OllyDbg.
• Communication offusquée entre une application et un driver : Puisqu’avec cette technique RDTSC est exécutée en ring 3 et provoque une exception #GP en ring 0, c’est un moyen de donner la main à un driver afin qu’il effectue des opérations « ni vu ni connu », dans le sens ou il n’y a aucun appel explicite vers fonction noyau dans l’application ring 3.

Conclusion

Cette technique n’est pas nouvelle, mais encore assez peu connue (enfin sans doute pas des reversers :p). Cependant, elle peut se révéler très intéressantes dans de multiples occasions. Si je devais donner un conseil, ce serait d’éviter de l’utiliser en ring 3, pour deux raisons principales de sécurité :

• Il existe des générateurs aléatoires reconnus comme fiables, il est donc préférable de les utiliser plutôt que de se faire son propre algorithme.
• L’OS fournit généralement des appels systèmes permettant d’appeler RDTSC en ring 0 et de retourner sa valeur (cf NtQueryPerformanceCounter() sous Windows). Comme l’appel est en ring 0, la méthode de hook décrite précédemment ne marche plus.

Références

• The Art of Unpacking, Marc Vincent Yason, BlackHat 2007
• Intel Software Devloper’s Manuals 2B, 3A
• Understanding the Linux kernel, 3rd edition, Daniel Pierre Bovet, Marco Cesati, O’Reilly
• Nibbles – SMP : IDT et GDT, j0rn
• Linux Device Drivers, 3rd edition, Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman, O’Reilly
• CR0′s blog : Time-stamp counter disabling oddities in the Linux kernel
• Man prctl

PR_SET_TSC