HackInTheBox Amsterdam 2011

Introduction

En fin de semaine passée – les 19 et 20 mai – s’est déroulée l’édition européenne de la conférence HackInTheBox, à Amsterdam. Comme c’est souvent le cas pour ce type d’événements, de nombreux professionnels du milieu font le déplacement afin d’assister aux présentations, se tenir au courant des nouveautés et aussi … enfin … cela se passe à Amsterdam donc aussi profiter de la ville.

Quelques ingénieurs SCRT faisant partie de ceux-là, nous vous livrons ici un petit compte rendu de cette édition 2011.

Ambiance

Arrivés sur place quelques minutes avant le lancement de la Keynote – officiée par, non moins, que le CSO de Facebook – nous constatons que les choses se mettent en place gentiment et que, bien que les participants semblent arriver petit à petit, la foule reste à échelle humaine, permettant de circuler aisément d’une salle à l’autre sans devoir jouer des coudes.

Du coup, quelques petites minutes après, l’enregistrement est effectué et nous nous retrouvons assis dans la salle principale à écouter Joe Sullivan argumenter au sujet d’innovation et des challenges engendrés par celle-ci : discussion, bien évidemment, illustrée de nombreux exemple issus de l’évolution de la plate-forme Facebook.

Une fois celle-ci terminée, la pause café prévue au programme permet de prendre mieux connaissance de ce qui semble être le point central de la conférence : installé dans le jardin d’hiver du l’hôtel, un espace ou les stands d’exposants tels que Google ou OWASP côtoient les espaces réservés aux différents hackerspaces prenant part à un challenge de robotique ainsi qu’à l’emplacement prévu pour la traditionnelle CTF. Au milieu de cet espace, un buffet de boissons et de nourriture – omniprésent au long des deux jours – est appréciable et visiblement appréciée des participants qui s’y retrouvent entre deux présentations, tenues dans une des trois salles dédiées à cela.

Vous l’aurez compris, l’ambiance est donc celle d’une conférence à relativement petite échelle – loin de ses consœurs telles que Defcon (USA) – ce qui a ses avantages et ses inconvénients.

Présentations

L’ambiance étant posée, venons-en au vif du sujet à savoir les présentations en elle-mêmes. Pour cela, HackInTheBox Amsterdam disposait de trois tracks en parallèle, proposant au total une trentaine de présentations.

Comme c’est généralement le cas, de nombreux sujets étaient abordés au fil des tendances du moment. Parmi ceux-ci, diverses présentations d’outils ou de projets en cours (Netglub, OpenDLP, etc…), des présentations de nouvelles attaques – génériques ou ciblant des produits en particulier – ou encore des présentations tournant autour des cartes à puce et autres systèmes plus spécialisés.

Toutefois, et c’est certainement là une tendance durable pour l’avenir, si un thème de présentation ressortait du lot c’était certainement celui des systèmes pour appareil mobiles. En effet, qu’il s’agisse de iOS ou de Android, de nombreuses présentations s’articulaient autour de la recherche de vulnérabilités ou de l’exploitation de ses systèmes, désormais omniprésents et très populaires.

Ceci étant dit, le catalogue des présentations – bien que assez varié – pêchait peut-être un peu par son manque de fraîcheur générale. En effet, quelques présentations avaient tendance à aborder des thèmes déjà largement discutés et revus sans apporter de nouveauté (par exemple, Stuxnet) ou encore avaient déjà fait l’objet de précédentes présentations à d’autres conférence (ce qui – néanmoins – ne remet pas en cause l’intérêt du sujet traité).

En marge des présentations « classiques » il probablement intéressant de relever la discussion d’ouverture du deuxième jour, intitulée « The Economics of Vulnerabilities » et permettant au public d’interagir avec quelques invités choisis, et non des moindres : parmi eux le directeur de la sécurité de Mozilla (Lucas Adamski), le dirigeant du Tipping Point Research Team (Aaron Portnoy), par ailleurs à la tête de la célèbre Zero Day Initiative, Chris Evans (Google) ainsi que des émissaires de la sécurité de grandes compagnies (Microsoft, Adobe, BlackBerry).

Ce panel de une heure et demi à donné lieu à d’intéressants débats sur les aspects économiques et étiques de la recherche et revente de vulnérabilités, notamment dans le contexte de divers programmes de récompense, petit à petit mis en place par certaines corporations afin d’inciter la recherche de vulnérabilités sur leur systèmes (ou des systèmes tiers dans le cas du ZDI).

Challenges

En parallèle des présentations, HackInTheBox Amsterdam était également le théâtre de divers ateliers et challenges. Parmi ceux-ci relevons le « Hackerspaces Challenge» ainsi que la CTF (Capture The Flag).

Le premier était un concours de robotique au cours duquel les équipes participantes (des représentants de différents hackerspaces hollandais ou de pays voisins) recevaient un kit de LEGO Mindstorm et avaient pour mission de construire un robot capable de suivre un source lumineuse. Ces robots étaient ensuite opposés lors de duels et départagés par le vote du public (effectué grâce à un tag RFID dissimulé dans les bracelets qui faisaient office de laisser-passer pour la conférence). Résultat assez drôle et plutôt original !

Le second était une traditionnelle CTF opposant différentes équipes préalablement qualifiées au travers d’épreuves de hacking diverses. Après deux jours en tête du classement, ce challenge a finalement été remporté par la team C.o.P : une équipe française, dont les membres sont des habitués des podiums dans ce type d’événements.

Conclusion

Au final, s’il est vrai qu’une conférence de ce type est toujours intéressante, il n’en demeure pas moins que l’impression générale sur cette édition de HackInTheBox Amsterdam était, de notre point de vue, dans l’ensemble assez mitigée.

Certaines présentations étaient certes intéressantes et ludiques mais elles faisaient toutefois plutôt figure d’exception dans un programme, dans l’ensemble, assez peu étoffé et ayant, de plus, subi plusieurs annulations à la dernière minute.

Toutefois, il est évident que ce constat et clairement dépendant des intérêts personnels de chacun et nous ne doutons pas que cette même conférence à apporté entière satisfaction à d’autres participants.

Insomni’hack 011 : c’est déja fini

Bonjour à tous,

Voila, Insomni’hack 2011 c’est déjà fini.

L’équipe SCRT tient à vous remercier d’avoir contribué à la réussite de cette 4ème édition d’Insomni’hack.

Au final, plus de 100 personnes auront fait le déplacement pour assister à l’une des grandes nouveautés de cette année : les conférences.

Pour ce qui concerne le concours : environ 200 personnes se sont mesurées aux épreuves en solo, ou par équipe (25 équipes enregistrées au total).

En fin de soirée, une équipe s’est finalement démarquée : les “BLES”, ou NibBLES 😉 Avec 8160 points, ils ont remporté haut la main cette 4ème édition. L’équipe “HZV” a remporté la 2ème place, en marquant 6340 points, et enfin l’équipe “KALUTEAM” la 3ème place avec 5520 points.

Une première série de corrigés des épreuves ainsi que les résultants et une série de photos/vidéos sont déjà disponibles sur notre site web : www.scrt.ch

En attendant la prochaine édition et ceci afin de répondre au mieux à vos attentes, vous avez la possibilité de répondre aux quelques questions suivantes :

[polldaddy poll=4784238] [polldaddy poll=4784228]

[polldaddy poll=4784079] [polldaddy poll=4784072]

[polldaddy poll=4784066] [polldaddy poll=4778544]

Nous nous réjouissons de vous retrouver pour Insomni’hack 2012 !

27C3 : We come in peace !

27c3  : We come in peace
D’année en année, la conférence berlinoise du Chaos Computer Club amène son lot de surprises et de révélations aux amateurs de sécurité, professionnels ou non, et aux bricoleurs de toutes tendances. Cette fois-ci, pour sa vingt-septième occurrence, le Chaos Communication Congress, a vu l’intérêt pour l’analyse de sécurité du protocole GSM se confirmer, et de nouveaux sujets d’inquiétude apparaître au grand jour. Un tour d’horizon des sujets des conférences auxquelles nous avons pu participer.

GSM, hacking et analyse
En quelques années, une sorte de tradition s’est établie qui consiste à faire de fracassantes révélations sur l’état actuel des implémentations du protocole GSM, toujours utilisé dans la téléphonie mobile. Cette année ne fait pas exception, et c’est avec plaisir que nous avons pu suivre les présentations respectives de Harald Welte et Steve Markgraf sur l’état actuel de l’implémentation open-source de la pile GSM, et de Karsten Nohl et Sylvain Munaut à propos d’un système de «  sniffing  » GSM. La conférence de Welte et Markgraf abordait ainsi le projet osmocomBB, qui permet de remplacer le logiciel propriétaire de certains types de téléphones mobiles par un firmware complètement ouvert, et représente la dernière brique manquante de l’édifice GSM libre composé également des projets OpenBTS et OpenBSC. Nohl et Munaut, utilisaient d’ailleurs osmocomBB dans leur démonstration  : avec l’aide de quelques téléphones à 10~15€ la pièce, ont montré la capture et le décryptage quasiment en temps réel d’une conversation téléphonique entre eux-deux  ! Relevant au passage que les fournisseurs d’accès téléphoniques dans leur grande majorité ne changent pas assez souvent les clefs de chiffrages utilisées dans leurs réseaux, ce qui rend le décodage d’autant plus facile. Sans citer de noms, Nohl signale quand même que certaines compagnies de téléphones ne changent tout simplement jamais de clefs de chiffrage, ce qui avait été révélé l’année passée dans d’autres conférences, et aurait du être corrigé. Un outil de déboguage comme celui-ci, lorsqu’il sera publié, représentera une menace sérieuse pour ces compagnies.

Les cartes de paiement à puce, un problème à venir
EMV est le protocole le plus fréquemment utilisé pour les paiements par carte à puce dans le monde entier, avec plus de 730 millions de cartes en circulation. Dans son exposé, Steven Murdoch a montré comment l’utilisation d’une faille du protocole permet aux criminels d’utiliser une vraie carte pour effectuer un paiement sans en connaître le PIN. Le fraudeur effectue une attaque man-in-the-middle pour tromper le terminal et lui faire croire que le code PIN a été vérifié correctement, tout en faisant croire à la banque émettrice qu’aucun code PIN n’est nécessaire ( ce cas est inclus dans les spécifications, exemples : handicapés, péages, …). Le point est mis sur le fait que par ce moyen la banque a l’impression que la carte a été utilisée avec un code PIN mais ce n’est pas le cas, la responsabilité retombe donc sur l’établissement banquaire, ce que l’orateur aide réguliérement à prouver en cas de litige. À noter qu’en date de la conférence, une seule banque a corrigé cette faille depuis sa communication ( private advance disclosure ), mettant ainsi en lumière l’immobilisme de l’industrie surtout si celle-ci n’a que la moitié de la facture à payer le reste étant à la charge du client.

DNSSEC, le dernier «  rant  » de D.J. Bernstein
Daniel J. Bernstein (DJB) est connu comme le loup-blanc dans le milieu de la sécurité informatique. Depuis plusieurs années, il publie du code minimisant les vulnérabilités (qmail, djbdns, etc.) allant même jusqu’à promettre une récompense substantielle à ceux qui démontreraient des failles dans ses logiciels. Il publie aussi des recherches sur les algorithmes de chiffrage et son algorithme Salsa20 figure dans le quartet final du projet eSTREAM (une initiative destinée à remplacer les plus anciens algo de chiffrage utilisés par exemple en téléphonie). En bref, quelqu’un dont les mérites ne sont plus à prouver. Il est aussi connu pour son discours acide, et sa tendance à bouter le feu à tout ce qu’il perçoit comme une idiotie. Cette année, c’est à DNSSEC qu’il a choisi de s’attaquer, ironisant avec talent sur les défauts de ce protocole et expliquant chiffres à l’appui que les pirates et autres vandales du web ont vraiment tout intérêt à supporter l’adoption universelle de DNSSEC, tant elle leur simplifie la mise en place d’un déni de service. DJB ensuite décris une collection de solution, prenant chaque fois DNSSEC comme contre-exemple, et finalement dévoile le but de son discours, qui est bien entendu la promotion sans honte d’une de ses propres créations, DNSCurve. Rien d’inhabituel là non plus, DJB ayant coutume de joindre le code à la parole, surtout lorsqu’il a l’occasion de revêtir son costume de chevalier blanc, pourfendeur de la sécurité par l’obscurité et défenseur des solutions simples… Ceci étant dit, le coté histrion de DJB ne doit pas cacher qu’il a eu très souvent raison et que la majorité, si ce n’est l’ensemble, de ses prévisions en matière de sécurité s’est révélée exacte. En quelques mots, qu’est-ce que DJB reproche à DNSSEC et qu’est-ce que DNSCurve est supposé apporter  ? La page web du projet ( www.dnscurve.org ) entre dans le détail des avantages de DNSCurve sur une collection d’attaques types, et documente la manière dont le protocole est supposé fonctionner. Il y a aussi quelques avantages de DNSSEC qui sont cités, mais par contre il n’y a pas encore d’implémentation de référence. Ce qui peut avoir des effets négatifs sur l’image de ce projet.

Ingénierie inverse de circuits intégrés
La conférence donnée par Michael Steil traitait de la reconstruction du schéma électronique d’un circuit intégré en partant du circuit lui-même et de quelques données connues à son sujet. La conférence s’intitulait «  Reverse Engineering the MOS 6502 CPU  » et démontrait et expliquait comment une équipe de mordus a reconstruit un modèle physique de l’historique MOS 6502 alors que la documentation d’ingénierie de ce chip a été perdue dans la débâcle Commodore. L’intérêt de cette présentation, hormis le pur facteur «  hacking  », est que ces techniques d’investigations peuvent être appliquées à n’importe quels circuits intégrés, et dans le futur probablement même aux plus récents d’entre eux. Reconstruire un modèle physique d’un processeur historique comme le 6502 (qui équipait entre autres les premiers ordinateurs Apple, Commodore et Atari) pour ensuite émuler son fonctionnement avec des FPGA ou un logiciel ad-hoc parait peut-être un peu ridicule et vain, mais si on peut le faire avec un circuit inoffensif comme celui-ci, on peut parfaitement imaginer reconstruire de la même manière les composants propriétaires équipant nos téléphones, ou n’importe quel équipement où la norme est de sécuriser les données en cachant dans le silicium la manière dont la «  sécurité  » est assurée. Par exemple, les circuits propriétaires des consoles de jeu, les chips de zonage des lecteurs DVD, les circuits de chiffrage de donnée des disques durs auto-cryptés du commerce, etc. Cette démonstration est dans la même lignée de la vulnérabilité de la non moins fameuse OysterCard.

Les vulnérabilités de PDF
Cette dernière décennie, le Portable Document Format, ou PDF, est devenu clairement le format le plus commun dans la publication de documents électroniques. Il est utilisé dans l’industrie du livre comme format de référence tant pour l’impression que pour la publication de ebooks. Et l’implémentation de référence de PDF est encore et toujours le célèbre Adobe Acrobat, dans ses deux éditions, Writer ou simple «  reader  ». Malheureusement, comme Julia Wolf l’a rappelé durant sa conférence, PDF est un standard qui a plus ou moins été aggloméré au fil des besoins de son éditeur d’origine, et Acrobat est le reflet de cette évolution organique  : à plus de 15 millions de lignes de code, Acrobat est plus lourd que Mozilla Firefox, plus lourd que le kernel Linux et la majorité de son code a été écrit dans les années ’90, dans le secret des laboratoires de Adobe. Le résultat est qu’il est possible de tromper Acrobat très facilement. La syntaxe de PDF et parmi d’autres le fait que la norme ne décrit explicitement aucune méthode de validation des documents PDF permettent de manufacturer des documents PDF qui sont en même temps des exécutables, qui contiennent du code malicieux ou qui se font passer pour toute une collection de formats de données. Dans un PDF, on peut appeler des commandes systèmes, exécuter des programmes arbitrairement, former des documents qui affichent des contenus différents selon le programme de lecture PDF utilisé, etc. Julia Wolf c’est concentrée sur Acrobat, parce qu’il est encore aujourd’hui le client PDF le plus fréquent, mais la norme sur laquelle ces programmes sont construits est suffisamment confuse et complexe pour que des exploitations de failles soient envisageables avec chacune des implémentations indépendantes.

Analyse de code par optimisation et déobfuscation
Deux autres conférences ont parlé respectivement de la déobfuscation de code par l’utilisation d’outils d’optimisation, et d’identification de primitives de chiffrage dans des exécutables à l’aide de techniques similaires. Dans la première, Branco Spasojevic a présenté l’utilisation conjointe d’un dés-assembleur scriptable (IDA Pro) et des fonctions d’optimisation de code d’un compilateur pour éliminer d’un code obscurci les obfuscations les plus courantes utilisées aujourd’hui. Puis, utilisant les possibilités de script du dés-assembleur, a montré comment personnaliser le décodage d’un binaire obscurci. Dans la seconde conférence, c’est Felix Grobert qui a montré comment les bibliothèques génériques de chiffrage partageaient plusieurs caractéristiques inhérentes qui pouvaient être identifiées dans des binaires, par exemple dans des malwares, et comment avec un outil développé dans ce but il est possible d’analyser le comportement d’un programme même si certaines de ses parties sont encodées. Un aspect intéressant propre à ces deux conférences est qu’il a été question les deux fois de théorie des compilateurs, et surtout de graphes d’exécution  : les programmes analysés sont décrits sous forme de graphes de flux et c’est sur ces graphes que les opérations d’analyse fonctionnelle sont faits. L’utilisation de graphes de flux semble se généraliser, c’est quelque chose qui est très utilisé dans l’écriture de compilateurs pour des langages dynamiques, par exemple dans le projet PyPy, un générateur de compilateur JIT pour le langage Python.

Pour l’avenir  ?
Une nouveauté dans l’organisation de 27c3 par rapport aux éditions précédentes est qu’il y avait cette fois ci un système de pré-location, et que les salles étaient limitées au nombre exact de places assises qu’elles comportaient. Pour compenser, le CCC a aussi mis en place des canaux TV accessibles avec une carte tuner, et des streaming vidéo visibles si on acceptait de prendre le risque de se connecter au réseau. Il y avait également des écrans de diffusion devant les portes des salles, donnant ainsi aux malchanceux la possibilité de suivre les démonstrations. Le même système d’écran était aussi supposé informer le public de l’organisation et du planning actuel des conférences, mais ce dernier point a été un échec particulièrement frustrant à observer  : non seulement les conférences changeaient de position dans le planning de manière encore plus aléatoire que les années précédentes, mais en plus les informations relatives étaient contradictoires entre les écrans, les affichettes imprimées à la minute, les corrections au marqueur sur les affichettes et le site web du congrès. Les locaux ont également montré leurs limites, avec seulement trois salles à disposition les conférences en anglais étaient particulièrement prises d’assaut. Si 28c3 (la prochaine édition) veut espérer se passer dans de meilleures conditions, les organisateurs reconnaissent qu’ils doivent chercher de nouveaux locaux, plus spacieux, et s’assurer que les affichages soient pertinents.
Dans tous les cas, si le succès du Chaos Communication Congress grandit encore, les conférences et les activités qui y seront présentées mériteront qu’on y fasse à nouveau un tour. L’ambiance du congrès reste bon-enfant, malgré le sérieux de la plupart des conférences, et on reprend toujours contact avec plaisir avec ce coté anarchiste défenseur des libertés individuelles qui fait son charme. Une fois de plus, toutes les tranches d’âges sont représentées, avec une participation féminine en augmentation et une très nette préférence pour les téléphones à système Android, par opposition à la concurrence de la marque à la pomme. Un point peut-être, c’est qu’on ressent de plus en plus un agacement des hackeurs vis à vis du comportement «  l’argent passe avant tout  » de la plupart des acteurs industriels. Des protocoles confus, des implémentations misérables, des interlocuteurs muets, tout ça devient la cible de l’ironie à peine déguisée de certains orateurs, surtout lorsque le silence ne fait que masquer le peu d’intérêt que les grandes compagnies ont réellement pour leurs clientèles. Par exemple dans sa présentation Karsten Nohl souligne que les clefs propriétaires du protocole GSM sont très bien protégées, contrairement à celles qui chiffrent les données des utilisateurs. Il dit, avec un sourire en biais, que c’est normal, les clefs propriétaires protègent l’argent des compagnies, tandis que les autres ne protègent que nos données personnelles… Un symptôme seulement, mais comment est-ce que cette situation évoluera  ?

En guise de conclusion
Nous n’avons malheureusement pas pu suivre toutes les conférences que nous aurions voulu, soit pour des raisons d’horaire, soit parce que la salle était déjà pleine. Ainsi nous n’avons pas pu suivre les conférences sur l’état des lieux du monde OpenSSL et la situation actuelle en matière de sécurité dans Ipv6. Il a fallu faire des choix.

Pour terminer, il est possible de visionner les conférences de 27c3 et de lire tout ou partie des présentations. L’organisation publie sur son wiki les liens vers tous les documents de référence, à l’adresse http://events.ccc.de/congress/2010/wiki/Documentation

Auteurs : Lantoane + LeLouac

DEFCON : How I Met Your Girlfriend

L’une des présentations les plus en vue cette année à la Defcon, tout comme à la BlackHat, était intitulée « How I met your girlfriend ». Il fallait scrutiner la brochure pour comprendre qu’il s’agissait d’une présentation donnée par Samy Kamkar, illustre créateur du vers « Samy » ayant sévi sur MySpace il y a quelques années, qui allait traiter de plusieurs nouvelles failles Web. Le tout était présenté de manière intelligente autour de la recherche fictive d’une célébrité.

La première attaque vise le générateur de sessions PHP et surtout le générateur de nombre pseudo-aléatoires du mécanisme. En effet, il a démontré qu’il est possible de réduire l’entropie des identifiants de session de 160 à moins de 30 bits, ce qui donne la possibilité de découvrir la valeur d’un identifiant à l’aide d’une attaque de type « bruteforce ».

En examinant le code utilisé pour générer un identifiant de session dans la version 5.3.1 de PHP, on trouve qu’il se base sur les éléments suivants:

  • Adresse IP du client (32 bits)
  • Temps Epoch (32 bits)
  • Microseconde courante (32 bits, mais réellement moins de 20)
  • valeur aléatoire issue de la fonction php_combined_lcg (64 bits)
  • Total : ~148 bits

[sourcecode language=”cpp”]

char *buf;

struct timeval tv;

char *remote_addr = NULL;

gettimeofday(&tv, NULL);

spprintf(&buf, 0, "%.15s%ld%ld%0.8F",

remote_addr ? remote_addr : "",

tv.tv_sec,

(long int)tv.tv_usec,

php_combined_lcg(TSRMLS_C) * 10);

[/sourcecode]

On se rend compte que certaines de ces valeurs peuvent être découvertes relativement facilement par un attaquant, surtout sur des réseaux sociaux. En effet, la plupart d’entre eux offrent aux utilisateurs (dans ce cas ci à l’attaquant) la possibilité de voir lorsqu’un autre utilisateur se connecte, par exemple via un chat. De plus, l’utilisation de ce chat pourrait permettre à un attaquant de convaincre sa victime de visiter un site sous son contrôle afin de découvrir son adresse IP. Cela signifie que les 64 bits d’entropie liés à l’adresse IP du client et de la seconde à laquelle il s’est connecté disparaissent. Il reste donc les 20 bits lié à la microseconde de la connexion, qui sont difficilement devinable, et les 64 bits liés à l’utilisation de la fonction php_combined_lcg.

Cette fonction génère 2 x 32 bits d’informations pour générer les 64 bits d’entropie. Lors du premier appel à la fonction, une valeur est générée par lcg_seed pour aléatoiriser les prochains appels à la fonction. Cependant, si l’on connait cette valeur, on va pouvoir en déduire toutes les prochaines valeurs « aléatoires » générées. La fonction lcg_seed va concaténer deux valeurs de 32 bits afin de créer les 64 bits d’entropie de la fonction.

[sourcecode language=”cpp”]

struct timeval tv;

if (gettimeofday(&tv, NULL) == 0) {

LCG(s1) = tv.tv_sec ^ (~tv.tv_usec);

} else {

LCG(s1) = 1;

}

#ifdef ZTS

LCG(s2) = (long) tsrm_thread_id();

#else

LCG(s2) = (long) getpid();

#endif

[/sourcecode]

Le premier de ces nombres (s1) est un XOR entre la valeur epoch et le complément à un des microsecondes lors de l’appel de la fonction. Le problème ici vient du fait que les microsecondes n’ont qu’une entropie de 20 bits ( 0 – 1’000’000) et les 12 premiers bits du complément à 1 ne changent donc jamais. Les premiers bits du temps en epoch ne sont que peu aléatoires et si l’on peut estimer que le premier « seed » a été généré dans un espace de 12 jours, seul les 20 derniers bits ne sont pas déterministes. Les 12 premiers bits de s1 peuvent donc être considérés comme constants.

Le second nombre (s2) utilisé par lcg_seed est simplement le process ID d’Apache. Sur un système Linux, cet identifiant n’est codé que sur 15 bits par défaut, ce qui signifie que l’entropie de ce deuxième chiffre est réduite de 32 à 15 bits.

On arrive alors à une combinaison de 20+15 bits, soit 35 bits au lieu des 64 bits annoncés par la fonction. En imaginant qu’on puisse exécuter du code sur la machine cible, par exemple via une faille web, on peut alors découvrir le PID exact (commande getmypid()). Il ne reste alors que les 20 bits du lcg à découvrir. En utilisant la fonction lcg_value, on peut écrire un programme permettant de bruteforcer la valeur du seed initial. Au final, il ne reste plus que les 20 bits relatifs à la microseconde de connexion de l’utilisateur. Cela correspond à environ 1 millions de valeurs de cookie différentes, ce qui peut être testé en une journée.

Dans la suite de son discours, Samy a présenté une attaque dite de Cross Protocol Scripting (XPS) qui se base sur l’utilisation de JavaScript pour communiquer avec un protocole autre que le traditionnel HTTP. En effet, il est tout à fait possible d’ouvrir une session en spécifiant un port autre que 80 ou 443, malgré certaines limitations au niveau de quelques navigateurs Internet.

Il est par exemple possible de se connecter à un serveur IRC en envoyant les requêtes désirées via un formulaire caché dans une page. Le serveur recevra les en-têtes HTTP qu’il ignorera car ce ne sont pas des commandes IRC valides, cependant le corps de la requête peut contenir des commandes valides.

L’XPS peut alors être utilisé pour tenter d’exploiter une faille dite de NAT Pinning sur certains routeurs. L’idée se base sur le fait que certains protocoles nécessitent l’ouverture de certains ports sur la machine du client. Par exemple, lors de transferts de fichiers sur IRC via la commande DCC, un nouveau port est ouvert et le contact de l’autre côté se connecte directement sur la machine du client pour récupérer le fichier. Ceci évite de surcharger la bande passante du serveur. Comme de plus en plus de machine se trouvent aujourd’hui derrière un firewall, ces derniers ont évolué et sont capables de reconnaitre ce type de flux et peuvent rediriger automatiquement le port requis vers la machine initiant la connexion. On peut donc utiliser cela pour accéder directement à la machine de la victime en redirigeant les ports voulus sur le firewall.

Finalement, la dernière partie de la présentation se base sur une combinaison d’attaques de type Cross-Site Scripting afin de découvrir la position exacte de la victime. Ceci se fait en plusieurs étapes:

  1. Convaincre la victime d’aller voir une page sous le contrôle de l’attaquant contenant un bout de code javascript permettant de fingerprinter le type de routeur de la victime. Ceci est typiquement fait à l’aide d’iframes cachées recherchant des noms de pages connues pour les différents types de routeurs.
  2. Après avoir trouvé une faille XSS sur le routeur, l’exploiter afin de récupérer l’adresse MAC de ce dernier. S’il est nécessaire de s’authentifier pour cela, l’utilisation des identifiants par défaut du routeur marchent dans la plupart des cas.
  3. Utiliser le service de géolocalisation de Google pour localiser l’adresse exacte de la personne.

Le dernier point est possible car pendant que les voitures Google prennent des photos pour Google Street View, elles captent également les différents réseau WiFi aux alentours. En spécifiant l’adresse MAC d’un routeur WiFi, ce service est alors capable de localiser à une dizaine de mètres près, la position exacte du routeur de la victime.

Alain Mowat