[EDIT] Je viens de mettre en ligne mes slides ici. Toutes les autres sont dispos sur le site officiel.

[EDIT 2] Le challenge public a été mis en ligne sur cette page. Bonne chance à tous

Préparation

Bien que l’événement ne dure qu’une nuit, il s’agit d’un travail de préparation de plusieurs mois. Outre le temps passé à rechercher des conférenciers et des ateliers, le développement du CTF et du challenge commun nous a pris plus d’un mois. Contrairement aux autres années, nous avions vraiment pris de l’avance sur l’organisation de l’événement, qui a débuté fin 2009.

En ce qui me concerne, j’étais chargé de gérer les conférences, et surtout veiller à ce que l’on ne prenne pas (trop) de retard sur le planning. J’ai fort heureusement été aidé par Silkcut et Vorex, sans qui je n’aurais probablement jamais réussi à gérer les deux tracks en simultané. Les ateliers étaient gérés par Heurs, les bars tenus par Crashfr, Pieuvre, Tr00ps, Freeman et Ginette, Olive s’occupait de l’organisation générale, John, Qbix et Philemon aux platines, Rosa, Cathy et Picon à l’accueil, pendant que Virtualabs, Sh4ka, Mysterie, Shell-storm, NiklosKoda et T0ka7a s’occupaient des challenges. Et encore, je suis sûr d’oublier à peu près la moitié des autres membres de l’équipe qui se sont investis dans l’installation de l’événement et son bon déroulement.

Conférences

N’ayant pu au final suivre que peu de conférences (sans cesse à courir partout pour gérer le timing et les imprévus) je ne pourrais malheureusement pas faire de résumé détaillé ici. Fort heureusement les slides seront bientôt publiées sur le site officiel. J’ai plus ou moins suivi la track 2 au rez-de chaussée, avec :

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

D’après les retours que j’ai eu, les conférences ont été bien appréciées. Quelques problèmes techniques ont été rencontrés : bug de micro, streaming de mauvaise qualité pour les confs de Geohot et Matthieu Suiche, coupure d’électricité… Je regrette vraiment ces problèmes qui font partie des aléas du direct (Murphy était parmi nous) et j’espère que cela n’aura pas trop embêté le public.

Je n’ai quasiment pas suivi les ateliers qui se déroulaient en parallèle aux confs et au CTF ; j’ai juste aperçu XavBox à son stand de puçage de console, NoCrash pour le lockpicking et Barbozor se préparant à tourner son premier épisode de la saison 3 de la grotte du barbu ayant pour thème le hacking de caddie…

Au final, les confs se terminent un peu après minuit (seulement une vingtaine de minutes de retard !), et laissent la place au challenge qui se déroule dans la cale.

Retrouvez toutes les slides sur le site officiel de la NDH.

Capture The Flag

Après avoir câblé toute la salle en une trentaine de minutes, les 12 équipes sont accueillies et s’installent. Virtualabs présente rapidement l’objectif du challenge. Comme l’année dernière, il s’agit de défendre ses serveurs (Windows et Linux) tout en attaquant ceux des autres équipes. Pour valider une faille, l’équipe doit récupérer un hash et le soumettre, chaque épreuve ne pouvant être résolue qu’une seule fois.

Les dénis de services sont autorisés, mais ne doivent pas cibler le serveur de monitoring. L’accès à Internet est fourni mais ne doit pas être utilisé pour communiquer avec des personnes extérieures sous peine de pertes de points voire de disqualification. La grosse nouveauté cette année est la présence d’un tableau de bord pour les équipes qui permet de suivre en temps réel l’évolution des scores. Les équipes sont libres de corriger leurs failles, mais ne disposent pas d’un accès root. En parallèle à cela, des épreuves communes sont lancées sur un serveur dédié.

Après quelques validations de la team Choucroute, les dénis de service deviennent rapidement (et malheureusement) la seule stratégie viable, du fait de la quantité importante de points perdue par l’équipe victime. Cela engendre alors un nombre assez importants de problèmes : plus de réseau pour certaines équipes, épreuves non accessibles, déconnexions SSH intempestives… Comme si cela ne suffisait pas, des problèmes internent viennent s’ajouter : problèmes au niveau du serveur de monitoring, crash de la base MySQL à cause d’une erreur de débranchement de prise électrique, problèmes sur les permissions des fichiers dus à une mauvaise version des ghosts déployés, etc. Sans parler du challenge public qui est assailli par des dizaines de participants et dont le Wifi souffre atrocement. Les concepteurs du CTF ne savent plus ou donner de la tête et sont sans cesse en train de redémarrer les VMs, patcher des fichiers sur les serveurs équipes (quand ceux-ci sont accessibles), etc. Et la team WWFamous ne les aide pas, puisque ce sont eux qui lancent majoritairement tous ces DoS à grand coup de slowloris et variantes sur SSH…

A 6h45, les WWFamous sont déclarés vainqueurs, Beerware terminent 2ème et Kowalski 3ème. Les lots sont distribués : disques datalocker, place pour Hacker Halted à Miami, formations…

Le public quitte tranquillement la péniche, tandis que nous remballons tout le matériel en luttant contre la fatigue…

Au final, très peu d’épreuves ont pu être exploitées avec succès pendant ce challenge. Pas mal d’équipes nous ont demandé s’il était possible de diffuser les épreuves en ligne ainsi que les solutions. C’est désormais chose faite ! Rendez-vous sur wargame.nuitduhack.com et préparez-vous à griller quelques neurones

Bilan

J’ai croisé beaucoup de monde pendant cette soirée, mais je n’ai malheureusement pas pu discuter avec tout le monde. En me basant sur les retours de ces personnes, je pense pouvoir affirmer que cette Nuit Du Hack 2010 était un véritable succès. Certes nous avons rencontré un certain nombre de problèmes qui en ont déçu certains, notamment le streaming qui n’a pas pu se faire convenablement, ou les dysfonctionnement des challenges. Nul n’est parfait ; chaque année nous faisons face à certains problèmes que nous tentons de résoudre l’année suivante. On le voit clairement lorsque l’on compare la NDH de cette année avec celle de 2007 par exemple… Cette année, un effort considérable a été porté sur l’organisation du challenge, la communication avec les équipes, le respect du timing pour les conférences, le niveau sonore (qui, on le rappelle, était assez insupportable les années précédentes), etc. Je remercie toute l’équipe pour avoir réussi à organiser un événement de cette ampleur, qui est à ma connaissance le plus grand de ce genre en France.

N’hésitez pas à donner votre avis sur l’événement, faites nous part de vos remarques et vos suggestions pour les années futures. Un topic/sondage va très certainement être ouvert sur les forums officiels, alors comme on dit, lachez vos com’ !

Note : Ayant été assez occupé, je n’ai pris que très peu de photos de l’événement. Je les mettrai sans doute en ligne dans quelques jours. En attendant vous pouvez en trouver sur Les Tutos de Nico.

• 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.

]]> http://www.segmentationfault.fr/securite-informatique/sstic-2010/feed/ 7 http://www.segmentationfault.fr/securite-informatique/resume-dc18-ctf-quals/ http://www.segmentationfault.fr/securite-informatique/resume-dc18-ctf-quals/#comments Mon, 24 May 2010 19:29:25 +0000 Emilien Girault http://www.segmentationfault.fr/?p=796 Contrairement à ce que certains pensent peut-être en voyant ce blog à l’abandon depuis plusieurs mois, non, je ne suis pas mort ! J’ai simplement été assez pris ces derniers temps, et j’essaye au passage de finaliser ma première release de XeeK pour la NDH le 19 juin…

Ce week-end, j’ai rapidement participé aux qualifications du CTF de la DefCon 18. Je n’avais pas refait de challenge depuis Insomni’hack 2010 donc je me suis senti obligé de me décrasser un peu le cerveau. Ma participation à ces qualifications est toutefois restée limitée ; n’ayant pas pu m’inscrire à temps j’ai du rejoindre une team à l’arrache (Big-Daddy).

Vue d’ensemble

Le challenge consistait en 6 séries de 5 épreuves, chacune intitulée de la sorte :

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

N’ayant pas énormément de temps à consacrer à ce challenge, je n’ai pas vraiment touché à tout mais me suis focalisé sur la crypto et le réseau.

Dans l’ensemble j’ai trouvé ça plutôt sympa, même si j’ai quand même deux remarques négatives à faire :

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

Étant loin d’avoir réussi à valider toutes les épreuves, je vous propose de dévoiler la solution de deux d’entre elles que j’ai trouvées assez sympathiques.

Packet Madness 200

Dans cette épreuve, on fournissait une capture de paquets (à renommer en .pcap), le but étant comme toutes les autres épreuves de trouver une passphrase de validation.

Sous Wireshark, on constate qu’il s’agit d’un trafic TCP entre un client et un serveur. En utilisant l’option « Follow TCP Stream », on constate qu’il semble s’agir de trafic binaire…

Capture Wireshark

Cependant, l’indice laissé par l’épreuve suggère que les deux machines communiquent avec une « langue » inhabituelle. S’agirait-il d’un encodage connu mais peu courant ? En regardant un peu les encodages supportés par Wireshark, on s’aperçoit rapidement qu’ils ‘agit en fait de l’EBCDIC, encodage créé par IBM qui semble remonter à l’époque quasi-préhistorique des cartes perforées… En utilisant cet encodage, on y voit tout de suite plus clair :

Trafic décodé

Il s’agit donc d’une sorte de telnet encodé en EBCDIC. Visiblement, le serveur propose plusieurs options, comme la création d’un compte, l’authentification, un mode maintenance et un affichage de news. L’IP du serveur visible dans le dump, 192.42.96.121, existe bel et bien et héberge bien ce service sur le port 8686. Il semble donc que la réponse à l’épreuve doive être obtenue en s’y connectant. Malheureusement les outils classiques comme telnet et netcat ne supportent pas l’EBCDIC. Mais c’est sans compter Python, qui le supporte nativement, et qui va ainsi nous permettre de se coder un petit client maison :

#!/usr/bin/python

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

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

 input = raw_input()
 input_to_send = input.decode('ascii').encode('EBCDIC-CP-BE')+"%"
 s.send(input_to_send)

Ce client permet d’envoyer des commandes au service tout en affichant ses réponses. Toutefois, j’ai constaté qu’il était toujours en retard d’un message par rapport au serveur. N’ayant pas le temps d’être perfectionniste, je m’en suis contenté et ai pu me créer un compte sur le serveur avec la commande « a », puis me loguer avec ce même compte (« l »). Le mode administrateur « m » ne fonctionnant pas, il ne restait que l’affichage des news (« n »), qui donnait cette sortie :

5/21/2010 - Defcon qualifiers are underway.

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

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

4/29/2001 - First post! w00t!

La news du 16 mai 2010 m’interpelle du fait de la présence du mot « key »… Nous testons donc la réponse « once upon a time IBM ruled the world » à l’épreuve, et après un léger acharnement collectif sur le team board, nous parvenons à valider ! Finalement, ce n’était pas compliqué…

Crypto Badness 400

Dans cette épreuve épinglée de l’indice « crack me », on fournit une archive tgz (encore une fois à renommer). Celle-ci contient un fichier blob.dat visiblement chiffré et une clé publique pubkey.pem. Il s’agit donc visiblement de casser la clé publique afin de retrouver la clé privée et déchiffrer le fichier .dat. Voici la clé publique :

-----BEGIN RSA PUBLIC KEY-----
MGgCYQDK2YRVfJfgOUMaImrXJ/DG1D7z1BhGnxs3UEmyKYQ+6fg7H5dzisJ09fYf
QB8h8ZE+S2S7MbVaONOYwN/tALE5LwiJcRxEs1nnl2xhf8xzTwbj6VwmR2CRtS9G
LnlBPbUCAwEAAQ==
-----END RSA PUBLIC KEY-----

Il s’agit d’une clé RSA. Pour analyser ce genre de clé, l’outil tout indiqué est OpenSSL. Cependant, une mauvaise surprise nous attend…

$ openssl rsa -pubin -in pubkey.pem -text
unable to load Public Key
20934:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: PUBLIC KEY

Impossible de lire la clé avec cet outil, donc. Un peu de recherche Google, et je trouve quelqu’un qui a eu le même problème :

The problem is this an RSA public key PEM or DER generated by Ruby’s OpenSSL::PKey::RSA are unreadable by OpenSSL, Bouncy Castle and probably other crypto tools.

The actual issue is that Ruby’s OpenSSL::PKey::RSA#to_pem and #to_der generate a PKCS#1 public key format while the openssl rsa command only works PKCS#8 formatted public keys.

Ainsi, la clé semble avoir été générée avec le module OpenSSL de Ruby, et son format PKCS#1 empêche sa lecture avec OpenSSL. Qu’à cela ne tienne, nous allons utiliser ce même module pour la lire ! On ouvre le shell Ruby (IRB) et on tape :

$ irb
irb(main):001:0> require 'openssl'
=> true
irb(main):002:0> a=OpenSSL::PKey::RSA.new(File.read("pubkey.pem"))
=> -----BEGIN RSA PUBLIC KEY-----
MGgCYQDK2YRVfJfgOUMaImrXJ/DG1D7z1BhGnxs3UEmyKYQ+6fg7H5dzisJ09fYf
QB8h8ZE+S2S7MbVaONOYwN/tALE5LwiJcRxEs1nnl2xhf8xzTwbj6VwmR2CRtS9G
LnlBPbUCAwEAAQ==
-----END RSA PUBLIC KEY-----

irb(main):003:0> a.params
=> {"dmq1"=>0, "dmp1"=>0, "iqmp"=>0, "n"=>12301866845301177551304949
58384962720772853569595334792197322452151726400507263657518745202199
78646938995647494277406384592519255732630345373154826850791702612214
29134616704292143116022212404792747377940806653514195974598569021434
13, "d"=>0, "p"=>0, "e"=>65537, "q"=>0}

On arrive ainsi à extraire le module (n) et l’exposant public (e). Ce dernier étant quasiment toujours le même, seul le module importe ici. Pour savoir si nous avons une chance de le casser, regardons sa taille en bits :

$ python
>>> import math
>>> n=12301866845301177551304949583849627207728535695953347921973224
52151726400507263657518745202199786469389956474942774063845925192557
32630345373154826850791702612214291346167042921431160222124047927473
7794080665351419597459856902143413
>>> math.log(n, 2)
767.66426718447133

Il semble codé sur 728 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…