Abuser le filtre XSS pour faciliter une attaque de ClickJacking

Le clickjacking est une attaque relativement répandue visant les utilisateurs d’un site vulnérable X. L’idée est de faire cliquer l’utilisateur sur un endroit du site en question sans qu’il ne s’en rende compte. Le plus souvent, cela est fait en utilisant une iframe cachée sous la souris de l’utilisateur.

[sourcecode language=”html”]<iframe src="http://vulnerable.com" style="position:absolute; opacity:0"></iframe>[/sourcecode]

Afin de contrer cette attaque, beaucoup de sites utilisent des scripts dits de framebusting permettant à une page de ne pas s’afficher si elle détecte qu’elle est à l’intérieure d’une frame.

Le problème le plus évident de ces scripts est que si l’utilisateur a désactivé javascript, la page est tout de même affichée. En partant de ce principe, il est possible d’abuser le filtre XSS d’Internet Explorer 8 par exemple pour le convaincre que le script de framebusting est en fait une attaque XSS. Ceci aura pour conséquence de désactiver le script et de permettre l’attaque de ClickJacking. Typiquement il suffit de créer l’iframe de la manière suivante.

[sourcecode language=”javascript”]<iframe src="http://vulnerable.com/?toto=<script>/*code_frame_busting*/</script>" style="position:absolute; opacity:0"></iframe>[/sourcecode]

Le navigateur détectera alors le code comme étant du XSS et ne l’exécutera pas, ce qui veut dire que la page s’affichera normalement dans la frame.

La méthode la plus efficace pour bloquer le ClickJacking est l’utilisation du header HTTP X-FRAME-OPTIONS qui permet à une page de spécifier par quels autres domaines elle peut être “framée”.

Pour plus d’informations, vous pouvez lire l’article suivant qui contient pas mal de détails sur les différentes techniques de framebusting et de contournement.

http://seclab.stanford.edu/websec/framebusting/framebust.pdf

if (‘RFID’==’Radio Frequency Insecure Devices’) {Emulation();}

Précédent : if (‘RFID’==’Radio Frequency Insecure Devices’) {Clonage();}

Mise à jour: le lien vers le code source du firmware a été mis à jour.

Introduction

Nous avons vu précédemment comment tirer parti des tags de type Q5 ou Hitag2, capables de cloner l’identifiant d’un tag EM4X02 et ainsi de se substituer à lui auprès du lecteur légitime. Bien que cette solution soit simple à mettre en oeuvre elle requiert l’accès au tag original et demande du matériel spécifique. Ainsi, peut-on faire mieux? Cet article est là non seulement pour montrer que l’on peut faire mieux, mais surtout pour expliquer comment le faire. Alors rentrons directement dans le vif du sujet: le but est – ici – de fabriquer un “faux” tag EM4X02 capable de prendre n’importe quel identifiant.

Circuit

Pour ce faire, nous allons utiliser uniquement du matériel électronique “standard” et plus précisément les composants suivants:

  • 1 microcontrôleur Atmel ATtiny45
  • 1 résistance 10K
  • 1 transistor NPN (BC547)
  • 1 condensateur 10nF
  • du fil de cuivre émaillé (0.25mm de diamètre)

Avant d’attaquer – et pour rendre à César ce qui lui appartient – notons que l’émulateur que nous construisons ici est partiellement inspiré de travaux précédents, notamment en ce qui concerne la gestion de l’encodage Manchester. Ceci étant dit, le circuit que nous proposons ici est volontairement plus simple afin de pouvoir être mieux appréhendé en détail. Comme nous le voyons ci-dessous, le schéma électronique est très basique. Il manque toutefois le système d’alimentation ainsi que l’antenne. Concernant l’antenne, nous y reviendrons plus bas.

Pour ce qui est de l’alimentation, le problème est simple puisque le système n’a aucune entrée/sortie et que, par conséquent la seule contrainte est la plage de voltage supportée par l’ATtiny45: 2.7-5.5V (pour une fréquence maximale de 10MHz). Comme nous utilisons ici une fréquence d’horloge de 8 MHz, deux piles de 1,5V (AA ou AAA) devraient faire l’affaire. Toutefois, pour une meilleure fiabilité, rien n’empêche d’utiliser un véritable circuit d’alimentation, basé sur un régulateur de tension de type LM7805.

A ce stade vous vous demandez peut-être pourquoi nous avons besoin d’une alimentation alors que les tags EM4X02 sont purement passifs. Effectivement, il est possible de reproduire le comportement d’un tag authentique en utilisant le lecteur comme source d’alimentation (et de signal d’horloge). Pour des raisons de simplicité, nous n’avons pas opté pour cette solution ici et, du coup, nous obtenons un tag qui “triche” vis-à-vis du lecteur. En effet, au lieu d’être synchronisé avec ce dernier, notre tag se contente d’envoyer “égoïstement” et à répétition son identifiant à la bonne fréquence jusqu’à ce que “par accident” il se retrouve en phase avec le lecteur. Dans la pratique, tout ceci se passe en quelques fractions de seconde et n’est pas perceptible à l’utilisation.

Mis à part l’alimentation et l’antenne – sur laquelle nous reviendrons ci-dessous – le circuit se résume donc à un microcontrôleur qui embarque toute la logique et qui pilote l’antenne au travers d’un transistor NPN.

Encodage de l’identifiant

Comme nous l’avons vu dans les articles précédents, les systèmes EM4X02 transmettent un identifiant du tag au lecteur. Cet identifiant n’est pas envoyé tel quel et est, tout d’abord, encodé afin d’inclure des bits de parité permettant ainsi au lecteur de détecter un erreur de transmission. Cet encodage se fait de la manière suivante: tout d’abord, le tag envoie un série de neuf ‘1’ afin de signaler le début de transmission. Ensuite, l’identifiant – 40 bits – est envoyé sous la forme (conceptuelle) d’un tableau de 10 lignes x 4 colonnes agrémentés de bits de parité. Plus précisément l’identifiant est envoyé par blocs (lignes) de 4 bits, chacun de ces blocs étant suivi d’un bit de parité de ligne. Une fois les 10 blocs transmis, 4 bits de parité de colonne sont envoyés et terminés par un dernier bit ‘1’. Ceci fait donc un total de 64 bits. Toutes les parités utilisées sont des parités “paires”. Pour illustrer tout cela, prenons comme exemple l’identifiant 0x0123456789. Celui-ci sera envoyé de la manière suivante (les bits en noir constituent l’identifiant à proprement parler, ceux en rouge sont les bits de parité et ceux en bleu indiquent le début et fin de transmission):

111111111 0000 0 0001 1 0010 1 0011 0 0100 1 0101 0 0110 0 0111 1 1000 1 1001 0 0001 1

Transmission des données

Pour ce qui est de la trasmission des données, les tags utilisent un encodage de type Manchester. Du point de vue de notre émulateur, voici comment se fait la transmission de données.

L’antenne connectée aux bornes X1-1/X1-2 (sur laquelle nous reviendrons ci-dessous) ainsi que le condensateur C1, connecté en parallèle, forment un circuit LC résonnant à la fréquence de 125 KHz. Ce circuit est piloté par le microcontrôleur, au travers du transistor Q1. En bref, quand la pin #3 du microcontrôleur est à un niveau bas, aucun passage de courant ne se fait au travers du transistor. En conséquence, l’antenne de l’émulateur (plus précisément le circuit résonnant LC) est alors en syntonie avec l’antenne du lecteur, ce qui est perçu par le lecteur au travers d’une charge accrue et interprété comme un ‘1’ logique. A l’inverse, quand la pin du microcontrôleur est à un niveau haut, les bornes de l’antenne sont alors en court-circuit ce qui provoque la dé-syntonie de l’antenne et est alors interprété par le lecteur comme un ‘0’ logique.

Il est à noter que les tags EM4X02 utilisent généralement 64 cycles d’horloge par bit (bien que d’autres valuers soient également possibles). Ainsi un bit est transmis en 512 us et l’identifiant complet en 32.768 ms.

Au final donc, le microcontrôleur va changer compter des cycles à une fréquence de 125 KHz, et changer l’état du pin #3 tous les 32 cycles selon le bit à transmettre, l’encodage Manchester ayant des transitions en début et milieu de cycle.

L’antenne

Le dernier point important qu’il reste à aborder est l’antenne à utiliser. Le but de cette antenne est de former, avec le condensateur C1, un circuit LC d’une fréquence de résonance de 125 KHz. Ainsi, selon la formule correspondante – et en fixant la valeur de C1 à 10 nF – nous pouvons calculer qu’il nous faut une bobine de environ 162 uH.

Bien qu’il soit certainement possible de trouver une antenne toute prête répondant à ces exigences, il est certainement plus rapide (et plus intéressant) de la fabriquer soi-même. Pour cela il suffit de disposer d’une bonne longueur de fil de cuivre émaillé, de diamètre connu. Nous avons opté pour un diamètre de 0.25 mm.

En se référant à une note applicative publiée par la société EM Microelectronic, nous obtenons la formule permettant de calculer l’inductance d’une antenne en forme de bobine circulaire en fonction du diamètre de la bobine D, du diamètre du fil d et du nombre de spires N.

A partir de cette relation et en fixant le diamètre de la boucle à 4 cm (ce qui, au passage, correspond au diamètre du cylindre en carton autour duquel est enroulé un rouleau de papier toilette et autour duquel nous pouvons enrouler le fil pour fabriquer l’antenne), nous obtenons N=43. Il nous faut donc une bobine de 4 cm de diamètre, composée de 43 spires.

Circuit Final

En mettant toutes ces informations ensemble, nous obtenons le résultat ci-dessous. On peut noter que nous avons opté pour un circuit d’alimentation un peu plus élaboré, utilisant un régulateur de tension, alimenté par une pile 9V. Un petit interrupteur permet également de mettre le tout sous tension, ce qui est signalé par l’allumage de la LED verte.

Le connecteur six pôles situé à côté du microcontroleur est utilisé pour la programmation ISP (In System Programming) de l’AVR. Notre émulateur ne disposant (volontairement) d’aucun moyen de communication avec un PC, il est nécessaire de flasher le firmware du microcontroleur pour changer l’identifiant à émuler. Ce connecteur permet ainsi d’accomplir aisément et rapidement cette tâche, sans avoir à enlever le chip pour le mettre dans un circuit de programmation. D’ailleurs, en parlant du firmware, vous pouvez en télécharger le code source ici.

Démonstration

Au final, comme nous l’avons mentionné dans les précédents articles de cette série, le problème n’est pas tant le EM4X02 en lui-même que l’utilisation qui en est faite. Par exemple, de nombreux systèmes RFID sont suffisamment robustes pour être utilisés comme moyen de contrôle d’accès… toutefois celui-ci n’en fait définitivement pas partie. La preuve en images … quelque part en Suisse romande!

[youtube=http://www.youtube.com/watch?v=mVWALgC0TmA]

Ne refaites pas ça chez vous … et surtout pas chez votre voisin! 🙂

if (‘RFID’==’Radio Frequency Insecure Devices’) {Clonage();}

Précédent : if (‘RFID’==’Radio Frequency Insecure Devices’) {Intro();}

Après avoir très (brièvement) introduit les tags RFID EM4X02, nous allons maintenant nous focaliser sur un des moyens permettant de contourner la sécurité d’un système basé sur ceux-ci: le clonage.

Comme nous l’avons vu précédemment, l’élément sur lequel repose toute la sécurité du mécanisme est l’identifiant (soit-disant) unique et inaltérable contenu dans chacun d’eux. Cet identifiant est codé sur 40 bits, laissant ainsi la possibilité d’avoir un total de 1 099 511 627 776 identifiants différents. A priori, il est vrai que cela semble permettre le déploiement d’un assez grand nombre de tags avant d’arriver à l’épuisement des IDs possibles. Toutefois, la problématique qui nous intéresse ici est autre et tourne autour de l’aspect lecture-seule de ces tags.

En effet, comme nous l’avons déjà vu, la valeur des tags EM4X02 ne peut pas être modifiée après fabrication, il n’est donc pas possible de modifier un de ces tags afin de “voler” l’identité d’un autre. Si cette remarque est tout a fait vraie, ce qu’elle ne dit pas c’est qu’il existe – toutefois – d’autres types de tags disposant de cette fonctionnalité, et surtout, fonctionnellement compatibles aves les EM4X02. Parmi ceux-ci, on peut notamment citer les tags Q5 et Hitag2. Tout deux fonctionnent de manière compatible avec les lecteurs EM4X02, tout en disposant d’une mémoire accessible en lecture/écriture, altérable au travers d’un ensemble de commandes spécifiques. Bien entendu, l’utilisation de ces commandes spécifiques (en d’autres termes la programmation d’un identifiant arbitraire) nécessite du matériel spécifique, notamment un lecteur compatible. Néanmoins, une fois cet investissement initial effectué (lecteur et tags Q5 ou Hitag2), il est alors possible de programmer n’importe quel identifiant sur un de ces tags et de s’en servir pour cloner un tag EM4X02 légitime. A ce propos, il existe un excellent outil – RFIDIOt – développé sous forme de collection d’outils Python par Adam Laurie et destiné à faciliter l’interaction (bien ou mal intentionnée) avec une large palette de systèmes RFID. Le seul bémol de cette solution est la relative difficulté à mettre la main sur ce type de tags ainsi que sur les lecteurs compatibles (tous deux peuvent néanmoins être directement commandés sur le site de RFIDIOt). Le prix de ces derniers est toutefois, sensiblement supérieur à celui d’un simple lecteur EM4X02.

Ceci étant dit, d’autres moyens si on est prêt à sacrifier un peu de la flexibilité offerte par la combinaison RFIDIOt + Q5/Hitag2, d’autres solutions – plus simples à mettre en oeuvre et moins chères – existent, notamment des appareils “stand-alone” pouvant cloner un tag EM4X02 en quelques secondes. Ce type d’appareils se content en réalité de lire le tag original, de stocker temporairement l’identifiant de celui-ci, pour l’envoyer à un tag de type lecture/écriture, généralement livré avec l’appareil. Ces tags sont, en termes de concept, très similaires aux tags Q5 et Hitag2. Bien qu’il soit difficile de faire plus simple au niveau utilisation – on pose la tag légitime dessus, on appuie sur un bouton et on répète l’opération avec la tag “pirate” – la seule contrainte de cette solution est de devoir disposer (au moins pour quelques secondes) du tag original que l’on souhaite copier.

Ayant présenté ces deux moyens faciles de cloner un tag RFID de type EM4X02, il est facile de comprendre pourquoi la sécurité système reposant uniquement sur ce type de tags – et notamment s’il s’agit d’un système sensible tel qu’un système de contrôle d’accès – est en réalité toute relative. En effet, une fois le côté “mystérieux” du RFID mis de côté, il est au final bien plus simple et rapide de cloner un tag “unique” que de dupliquer un clé de serrure!

Bien que nous ayons déjà, avec ce type d’équipements, largement de quoi déjouer un système de sécurité basé uniquement sur ce type de tags, nous allons plonger encore un peu plus profondément dans le EM4X02 afin de voir comment construire soi-même – pour quelques francs – un circuit électronique capable d’émuler n’importe quel tag EM4X02. Rendez-vous, pour cela, dans le prochain article.

A suivre: if (‘RFID’==’Radio Frequency Insecure Devices’) {Emulation();}

if (‘RFID’==’Radio Frequency Insecure Devices’) {Intro();}

Depuis quelques années, le RFID (Radio Frequency IDentification) est omni-présent et largement mis à profit pour des applications aussi diverses que le contrôle d’accès, le tracking, les systèmes de payement, les systèmes d’abonnement divers, etc… Du coup, il n’est pas étonnant de constater un intérêt grandissant pour ses aspects (in-)sécuritaires et c’est à cela que nous allons nous intéresser dans une série d’articles, dont celui-ci est le premier.

Toutefois, que les choses soient claires dès le départ, le but de cet article – ou plutôt de cette série de trois articles – n’est pas de présenter ni de discuter en détail de la technologie RFID. Si vous voulez en savoir plus sur ce sujet, un peu de lecture sur Internet peu répondre à la plupart de vos questions. Il y a toutefois un point important qu’il faut relever avant de pouvoir rentrer dans vif du sujet: ce que l’on appelle communément RFID n’est pas une technologie unique mais bien une large palette de technologies, de normes et de systèmes différents, reliés par un point commun, à savoir l’interaction – sans contact – d’un transpondeur et d’un lecteur. Ainsi, il y a certainement autant de différences entre deux systèmes RFID différents qu’il n’y en a entre la serrure d’un cadenas bon marché et celle d’un coffre-fort. Ceci étant dit, nous pouvons maintenant attaquer le sujet de cet article à savoir la sécurité des systèmes EM4102 et par transition aux autres systèmes basse fréquence, basés sur des transpondeurs lecture seule.

Les “tags” (transpondeurs) EM4X02, ainsi que les lecteurs associés, sont des systèmes RFID LF (low frequency), fonctionnant à une fréquence de 125KHz. Leur fonctionnement est simple puisque la seule donnée qu’ils contiennent est un identifiant “unique”, programmé d’usine, qui peut uniquement être lu et qui ne peut être altéré. Ces tags sont (comme la majorité des systèmes RFID) de type passif, à savoir qu’ils sont alimentés par le lecteur lui-même, au travers d’un système de couplage électromagnétique et ne nécessitent donc pas d’alimentation embarquée. Dans la réalité, ces tags – ou d’autres tags fonctionnant de la même manière – sont très utilisés, pour des application diverses et sous de nombreux formats (cartes au format carte de crédit, porte-clés, bracelets, voire même … implants humains!) De par leur fonctionnement (et notamment leur aspect lecture seule) ils sont toutefois limités aux systèmes stockant des données dans un “back-end” et utilisant le tag comme simple moyen d’identification de l’utilisateur.

Ainsi, la sécurité proposée par l’utilisation de ce type de tags repose essentiellement sur l’aspect “unique” de l’identifiant embarqué. En effet, si le tag n’a pour seule fonction que celle d’identifier de manière unique un utilisateur, il paraît clair qu’il serait problématique de pouvoir falsifier cet identifiant. C’est donc bien à cette falsification que nous allons nous intéresser dans les prochains articles, ainsi qu’aux conséquences possibles de celle-ci.

Qu’il soit toutefois clair que ce n’est pas – comme souvent en matière de sécurité – le système EM4X02 lui-même qui est mis en cause mais plutôt l’utilisation qui en est faite, notamment en termes de contrôle d’accès. Ainsi, à terme, l’idée n’est pas de démontrer que EM4X02 (ou d’autres systèmes équivalents) est bon ou mauvais mais plutôt de démontrer pourquoi il ne faut pas s’en servir pour certaines applications…

A suivre: if (‘RFID’==’Radio Frequency Insecure Devices’) {Clonage();}

Vulnérabilités “old school”

En regardant les titres des présentations des conférences de sécurité ou les articles traitants de JIT-Spraying et ROP on pourrait penser que pour exécuter du code sur une machine ou élever ses privilèges il faut déployer des techniques de plus en plus complexes.

Ce raisonnement est correct à la vue des protections comme l’ASLR, DEP, SEHOP, … Malheureusement, il existe toujours des types de vulnérabilités qui ne peuvent pas être protégées d’une exploitation via de telles techniques: celles liées au design ou à l’implémentation de certaines fonctionnalités par le développeur de l’application. Récemment deux vulnérabilités de ce type ont été publiées: PAM MOTD sous Ubuntu et une vulnérabilité touchant iTunes pour Windows.

La vulnérabilité touchant le module PAM sous Ubuntu est due au fait que du code exécuté en tant que root réassigne un dossier situé dans le répertoire personnel de l’utilisateur actuel à ce dernier après en avoir modifié le contenu. En apparence cela ne pose pas de problème puisque le dossier appartient déjà à l’utilisateur actuel, sauf… dans le cas où le dossier est en réalité un lien symbolique. Un attaquant ayant un accès restreint à la machine (local, ssh, … mais avec un compte d’utilisateur lambda) peut alors faire pointer ce lien sur des fichiers tels que /etc/passwd et /etc/shadow afin d’obtenir les droits permettant de les modifier pour ajouter un utilisateur root. Ici la vulnérabilité a été corrigée en appelant les appels systèmes setreuid() et setreguid() afin de perdre les droits root avant de modifier le fichier.

La faille découverte dans iTunes résulte d’une mauvaise utilisation de la fonction LoadLibrary. Lors de la lecture d’un fichier, iTunes va tenter de charger une bibliothèque depuis le répertoire courant, qui sera celui où se trouve ce fichier. Ce fichier pouvant être accédé via le protocole WEBDAV, un attaquant peut exécuter du code à distance du moment qu’un utilisateur ouvre le fichier se trouvant dans le même répertoire que la bibliothèque qui sera chargée par iTunes. De nombreuses autres applications sont sujettes au même problème. Dans le cas d’iTunes, le code chargeant la bibliothèque a été supprimé mais on peut également se prémunir de telles vulnérabilités via des règles dans AppLocker/GPO par exemple.

Il faut bien noter que ces deux vulnérabilités ne sont pas le résultat de nouvelles techniques d’exploitation (en 2000 une vulnérabilité liée à SearchPath/LoadLibrary avait déjà été publiée), mais d’erreurs d’implémentation au moment du développement des applications.