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.

Le hacking hardware (presque) à portée de tous

Vous vous êtes toujours demandé comment fonctionnaient certains équipements électroniques que vous utilisez tous les jours? Ou, en bon et curieux hacker, vous aimeriez bien décortiquer ce disque dur – soit disant – protégé par un mot de passe afin de comprendre comment il fonctionne réellement? Malheureusement, dans la plupart de ces cas, vous vous retrouvez bloqué dès les premières vis enlevées car vous ne savez pas comment lire le contenu de l’EEPROM qui se trouve devant vous ou comment ni comment « sniffer » le bus de données.

S’il est vrai que le hacking « hardware » est une discipline très répandue, il requiert des connaissances spécifiques et un investissement conséquent en termes de temps et d’équipement, même pour des gens provenant de la communauté hacking. Ces deux éléments suffisent généralement à décourager la plupart d’entre nous – pauvres « cliqueurs de boutons » – qui ne savent pas comment programmer un microcontrôleur, ni même comment assembler tous ces composant, nécessaires à sa mise en oeuvre.

Eh bien, pour notre plus grand bonheur à tous, il semble que cet effort d’apprentissage soit en train de s’amenuiser grâce à des projets comme Arduino. Cette plateforme, construite autour d’un microcontrôleur Atmel ATmega328, ainsi que l’environnement de développement (IDE) qui l’accompagne sont peut-être le chaînon manquant entre le monde du software et celui du hardware, en ayant l’immense avantage d’être « prête à l’emploi » et de pouvoir être programmée avec un simple port USB, sans avoir besoin d’équipement spécifique.

Bien entendu, le hardware ainsi que le software sont Open Source et l’IDE existe pour la plupart des plateformes. D’ailleurs il n’y a qu’à voir la liste de projets compatibles ou qui reposent sur l’Arduino pour se rendre compte de sa popularité ces dernières années.

S’il est certainement le plus populaire, Arduino n’est toutefois pas unique en son genre et de nombreux projet similaires (basés sur différents types de microcontrôleurs) voient le jour au fil du temps et semblent donner avoir donnée naissance à une tendance qui vise à démocratiser le monde du (hacking) hardware. Dans ce contexte, il n’est pas surprenant de constater que ce type de plateformes occupent une bonne part de l’attention de sites spécialisés – tels que Hack A Day – ou se voient propulsées sur scène à des conférences comme DefCon. Après tout, ce n’est certainement que justice!

Cocorico++

wget http://www.france.fr/robots.txt

[sourcecode language=”text”]
# $Id: robots.txt,v 1.9.2.1 2008/12/10 20:12:19 goba Exp $
#
# robots.txt
#
# This file is to prevent the crawling and indexing of certain parts
# of your site by web crawlers and spiders run by sites like Yahoo!
# and Google. By telling these "robots" where not to go on your site,
# you save bandwidth and server resources.
#
# This file will be ignored unless it is at the root of your host:
# Used: http://example.com/robots.txt
# Ignored: http://example.com/site/robots.txt
#
# For more information about the robots.txt standard, see:
# http://www.robotstxt.org/wc/robots.html
#
# For syntax checking, see:
# http://www.sxw.org.uk/computing/robots/check.html

User-agent: *
Crawl-delay: 10
# Directories
Disallow: /includes/
Disallow: /misc/
Disallow: /modules/
Disallow: /profiles/
Disallow: /scripts/
Disallow: /sites/
Disallow: /themes/
# Files
Disallow: /CHANGELOG.txt
Disallow: /cron.php
Disallow: /INSTALL.mysql.txt
Disallow: /INSTALL.pgsql.txt
Disallow: /install.php
Disallow: /INSTALL.txt
Disallow: /LICENSE.txt
Disallow: /MAINTAINERS.txt
Disallow: /update.php
Disallow: /UPGRADE.txt
Disallow: /xmlrpc.php
# Paths (clean URLs)
Disallow: /admin/
Disallow: /comment/reply/
Disallow: /contact/
Disallow: /logout/
Disallow: /node/add/
Disallow: /search/
Disallow: /user/register/
Disallow: /user/password/
Disallow: /user/login/
# Paths (no clean URLs)
Disallow: /?q=admin/
Disallow: /?q=comment/reply/
Disallow: /?q=contact/
Disallow: /?q=logout/
Disallow: /?q=node/add/
Disallow: /?q=search/
Disallow: /?q=user/password/
Disallow: /?q=user/register/
Disallow: /?q=user/login/
[/sourcecode]

Hypothèse 1 : On l’a copié de quelque part, mais on sait pas trop ce que cela fait
Hypothèse 2 : Quitte à en mettre un, autant bien le remplir

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