Certainement que, comme moi un de ces jours où l'on a le cerveau patraque, vous vous êtes retrouvés face à une vulnérabilité permettant une inclusion de fichier local sans avoir identifié de moyen d'envoyer (ou de créer) sur le serveur distant un fichier contenant du code actif... Et ce n'est pas faute d'avoir essayé d'injecter dans le fichier de session, voire même dans les logs ou les images uploadées via un formulaire ! Mais rien n'y fait. Même ce satané formulaire d'upload écrit en PHP et utilisant la bibliothèque GD pour décoder et écrire ensuite sur disque les images qui lui sont envoyées nous empêche d'obtenir un remote shell. Damned, we're doomed.
Quelques fuites d'informations
C'est vrai que d'habitude, l'envoi d'une image au format JPEG par exemple avec un commentaire paramétré avec Gimp fait l'affaire, en dernier recours. Seulement dans mon cas, ce n'était pas possible, la bibliothèque GD étant utilisée pour décoder et écrire ensuite le fichier image sur disque: celle-ci a la fâcheuse manie de remplacer tout commentaire existant et d'y coller le sien:
Pour le coup, cette particularité est très intéressante: la qualité utilisée pour stocker l'image est dévoilée, en l'occurrence il s'agit d'une qualité de 99 (celle par défaut étant de 75 environ). On sait aussi que l'image a bien été générée par la bibliothèque GD. Bon, c'est pas folichon, mais ca peut aider.
Découverte du format de fichier JPEG
Le site distant n'acceptant que les images au format JPEG, j'ai donc décidé de mettre les mains dans le cambouis, et de voir comment est structuré ce format de fichier. L'objectif principal étant d'arriver à trouver une zone dans laquelle on peut écrire mais qui n'est pas supprimée par cette satanée bibliothèque. Je suis donc parti à la chasse aux sources, et j'en ai trouvé plusieurs:
Le format de fichier JPEG (Joint Photographic Expert Group) est un format de stockage d'image qui emploie une compression avec perte, basée sur une conversion d'une disposition de pixels en répartition fréquentielle (grosso modo). Le problème de ce format de fichier, c'est que la configuration des pixels composant l'image n'est pas écrite telle quelle dans le fichier, contrairement aux images dites raster (comme le format BMP de Microsoft, ou le format GIF), et cela pose des soucis. En particulier quand on cherche à insérer un bout de code PHP pour exploiter convenablement une LFI.
De plus, le format de fichier est assez particulier, l'ensemble des informations étant réparties dans des sections, définies par des marqueurs. Un marqueur débute toujours par l'octet de valeur 255 (0xFF), et contient un code indiquant son rôle. Ainsi, le marqueur ayant pour code 0xD8 marque le début de l'image (Start of Image, ou SOI), et celui ayant pour code 0xD9 la fin de l'image (EOI). D'autres marqueurs sont aussi définis, dont celui définissant un commentaire, 0xFE. Je vous renvoie aux quelques liens donnés précédemment pour de plus amples informations.
Mais alors, où écrire dans ce format de fichier ?
C'est toute la question. Il ne peut y avoir qu'un champ de commentaire dans un fichier JPEG, et de toute façon nous avons vu que celui-ci était écrasé par la bibliothèque GD lors de la sauvegarde. Le format de fichier JPEG autorise aussi des marqueurs spécifiques aux applications (les fameux APPX), mais encore une fois ceux-ci ne sont pas pris en compte par GD. Il ne nous reste pas d'autre choix que de tenter une insertion dans les données stockées dans le fichier, servant à la reconstruction de l'image.
En théorie, il suffit de localiser la section SOS (Start of Scan, ayant pour marqueur 0xDA), de trouver les données compressées qui la suivent et de remplacer les premiers octets avec notre payload PHP. Oui, en théorie c'est censé fonctionner. Seulement en pratique, notre payload PHP va être interprété comme une donnée compressée et servir ensuite à générer une image composée de pixels que nous ne maîtrisons pas. Une fois recompressée par la bibliothèque GD, rien ne nous garantit que notre payload PHP sera conservé. L'insertion idéale consisterait à injecter à la place des données permettant de reconstituer les pixels notre payload PHP, et lorsque GD décode puis encode l'image, que notre payload soit conservé et écrit sur disque. Dans le cas où le fichier ne transite pas par la bibliothèque GD, celui-ci contient tout de même notre payload et fonctionnera. Ainsi, nous serions à même de construire une image Jpeg contenant du code PHP malveillant, et résistante aux transformations induites par la compression réalisée par la bibliothèque GD !
Création d'une image Jpeg "bulletproof"
Pour pouvoir créer ces merveilleuses images, j'ai tout d'abord codé en Python le code réalisant l'injection. Pour effectuer celle-ci, il suffit de rechercher la séquence d'octet 0xFF 0xDA (correspondant à la section Start of Scan), puis de lire les deux octets qui suivent (contenant la taille de la section stockée sur 2 octets en big-endian), afin de trouver l'endroit où les données compressées sont écrites. On recherche ensuite à partir de cet emplacement le marqueur de fin d'image (0xFF 0xD9), et les données situées entre les deux correspondent aux données compressées définissant le contenu de l'image (enfin, une partie pour être précis, mais là n'est pas la question).
Il est ensuite trivial de remplacer les quelques octets de début par notre payload. Notez que dans le code présent j'ai prévu un décalage variable, j'y reviendrai plus tard. Voici le code de cette fonction:
def insertPayload(_in, _out, payload,off):
img = _in
# look for 'FF DA' (SOS)
sos = img.index("\xFF\xDA")
sos_size = struct.unpack('>H',img[sos+2:sos+4])[0]
sod = sos_size+2
# look for 'FF D9' (EOI)
eoi = img[sod:].index("\xFF\xD9")
# enough size ?
if (eoi - sod - off)>=len(payload):
_out.write(img[:sod+sos+off]+payload+img[sod+sos+len(payload)+off:])
return True
else:
return False
Pour tester les images générées, j'ai installé les bindings Python de la bibliothèque GD, sous debian le package nommé python-gd. Ces bindings permettent de simuler à l'aide de Python l'ensemble des traitements effectués par la bibliothèque GD, et en particulier de reproduire ce qu'il se passe sur le serveur cible à savoir l'ouverture puis l'écriture sur disque de l'image uploadée.
Un point est cependant capital à prendre en compte: la qualité de l'image. GD permet de définir une qualité (tout comme plein d'autres logiciels d'infographie, comme GIMP par exemple) afin d'ajuster la taille du fichier sur disque. Plus la qualité est bonne (proche ou égale à 100), plus le fichier sera gros et l'image nette, et a contrario plus celle-ci est faible plus le fichier sera petit et l'image dégradée. Ce facteur de qualité est très important: il faut utiliser exactement le même facteur lors de la génération de l'image bulletproof afin d'être sûr que le serveur distant va bien générer notre payload lors de l'écriture sur disque. La fuite d'information découverte précédemment va sûrement vous être utile afin de déterminer la qualité employée =).
J'ai automatisé la génération des images bulletproof à l'aide d'un script Python (encore un), et j'ai ainsi pu générer des images contenant le code PHP (ou équivalent) suivant pour les facteurs de qualité de 52 à 98:
<?php system($_GET['c']); ?>
Certes, quelques variantes ont du être employées pour assurer une insertion maximale, mais le résultat est plutôt intéressant. De plus, mon script essaie d'insérer le payload à différents endroits, pas forcément au début de la section (vous vous rappelez de l'offset dans la fonction d'insertion ?), car les phases de décompression/compression rendent le résultat un poil aléatoire. Ainsi, voici à quoi ressemble une image avant traitement par la bibliothèque GD (côté serveur), image contenant notre payload PHP (pour la qualité par défaut):
En regardant en détail le contenu de l'image, on peut apercevoir le payload PHP:
Fin mot de l'histoire
Avec cette image JPEG, j'ai pu facilement contourner la restriction imposée via la bibliothèque GD et forcer celle-ci à écrire elle-même une image contenant un code PHP malveillant, qui m'a permis d'exécuter des commandes systèmes sur le serveur distant à l'aide de la vulnérabilité d'inclusion de fichier local trouvée auparavant.
Pour vous éviter de générer tout vous-même, je vous ai préparé une petite archive contenant mon code python ayant servi à la génération de toutes les images bulletproof, ainsi que les images elles-même (32x32 pixels). Si avec ça je ne vous gâte pas pour Pâques, je ne comprends pas ...
Pour terminer sur une note sécuritaire, lorsque vous autorisez l'upload d'images au format JPEG (mais ceci est d'ailleurs vrai avec d'autres formats comme BMP ou PNG, une attaque identique pouvant être réalisée) prenez plusieurs précautions:
version de GD employée: 2.0.36rc1
version de Python employée: 2.7
Grand utilisateur de tickets de métro (émis par le STIF/RATP), je me suis posé la question un jour (oui, j'ai de ces idées pourries des fois) de savoir comment sont codées les informations sur ce support magnétique. L'idée m'a semblé intéressante à creuser, mais nécessitait un brin de bidouille électronique. L'occasion de tester mon nouveau fer à souder reçu à Noël, et de découvrir l'univers des bandes magnétiques et plus particulièrement celui des tickets de la RATP.
Les bandes magnétiques
J'ai fureté pendant des heures sur Internet, à la recherche de documentation sur la lecture des bandes magnétiques, ainsi que sur les normes de codage employées. J'ai déniché quelques papiers intéressants:
Ces trois ressources sont très intéressantes, le white paper du CCC étant celle qui m'a apporté le plus. J'en ai discuté au boulot avec Tixlegeek, et il m'a lui aussi soumis l'idée d'utiliser la carte son de mon ordinateur portable pour échantillonner les données stockées sur le ticket (à l'instar de ce qui est documenté dans le papier de Joseph Battaglia). Il s'agit là d'un hack archi-simple, vu qu'il suffit de trouver une tête de lecture d'un vieux lecteur cassette et de la souder sur un jack 3.5 puis de le brancher dans la prise micro. La carte son fera le reste.
En ce qui concerne le codage des données sur bande, celui-ci peut se faire de deux manières:
La première méthode est celle employée pour stocker des données audio, mais est peu robuste. La seconde permet de stocker de manière plus robuste, et indépendamment de la vitesse de lecture ou d'écriture, des données binaires. C'est celle qui est préférée dans la grande majorité des systèmes de stockage numériques sur bande.
Le codage de fréquence le plus classique a un joli surnom: F2F. Ou plus généralement connu sous le nom de Aiken Biphase. L'idée est de coder le 0 avec un signal de fréquence F, et le 1 avec un signal de fréquence 2F. L'avantage de ce codage, c'est que peu importe la vitesse de lecture (qui est variable selon les périphériques), le décodage reste fiable. Bon par contre ça complique un brin la phase de décodage. Patrick Gueulle explique très bien cela dans son livre "Carte magnétique et PC".
Traitement du signal
Le papier du CCC [2] présente deux programmes (nommés DAB et DMBS) visant à respectivement décoder le codage Aiken Biphase (F2F) et à extraire les données selon les normes ISO781X. Ces mêmes programmes ont été utilisés par K1wy dans [1]. Le souci c'est que ceux-ci ont été principalement conçus pour les cartes magnétiques rigides à trois pistes, pas forcément pour les tickets de métro. De plus, selon les réglages audio de l'ordinateur servant à la capture (Mic-Boost notamment). Il me fallait une solution plus malléable, car ces deux programmes sont écrits en C et pas forcément bien documentés.
J'ai trouvé plusieurs modules python permettant de réaliser la capture d'un signal sur l'entrée micro et le traitement de celui-ci:
A l'aide de ces modules, j'ai réalisé quelques scripts de capture de signal et de sauvegarde des données sous format PCM et WAV. l'avantage de pouvoir sauvegarder les captures audio est double: on peut facilement refaire des analyses et surtout on peut les lire avec des outils comme Audacity. J'ai donc réalisé un script de capture du signal, et un script de traitement visant à traiter le signal afin de mettre en évidence le codage fréquentiel.
J'ai réalisé les tests de capture à l'aide d'un micro, et utilisé pylab pour afficher l'allure du signal. Pour le coup, c'était assez efficace:
Il m'a fallut ensuite réaliser mon lecteur de bande magnétique à la manière du CCC, à l'aide d'un vieux lecteur de cassette audio, d'un fer à souder, d'un jack 3.5 et d'un cable IDE =). J'ai du sacrifier mon super lecteur CD/K7 de mes 18 ans (de toute façon je n'ai plus de K7), mais c'est pas grave.
Fabrication du lecteur de bande magnétique maison
Premièrement, j'ai démonté le lecteur pour pouvoir accéder à la partie électro-mécanique au niveau du lecteur de K7:
Une fois les têtes de lecture et d'écriture démontées, j'ai pu souder la tête de lecture (stéréo, mais on s'en moque) sur le jack 3,5mm. Bon la méthode de connection étant pas trop documentée, j'ai un peu galéré mais j'y suis arrivé. Pour information, si vous essayez de refaire le montage chez vous et que vous employez un jack 3,5mm stéréo, faites très attention au contact central: il délivre du 5V (cette tension est utile pour les microphones de type Electret). Pour ma part j'ai pas gazé car j'aurais du relier la sortie de la seconde bobine de lecture à la première, pour cumuler les tensions de sortie, alors que dans mon montage je l'ai mise à la masse (donc je n'utilise qu'une seule des deux bobines de lecture).
J'ai utilisé trois fils couplés d'un cable IDE, de manière à avoir de quoi manipuler la tête de lecture et l'éloigner de l'ordinateur portable (pour limiter les interférences). Bon au final ça n'a pas tellement aidé, le cable IDE faisant une merveilleuse antenne. Une meilleure solution serait d'utiliser un cable blindé à trois brins dont le blindage est mis à la masse. Une fois celui-ci connecté à mon ordinateur portable, j'ai pu balayer un ticket de métro et capturer avec mon précédent script le signal issu de la tête de lecture (signal brut).
Décodage du signal et analyse
A l'aide de ce lecteur de bande magnétique fait maison et de mes quelques scripts, j'ai codé un second script permettant de mettre en évidence les données codées sur la bande magnétique, et ça n'a pas été une paire de manche. J'ai réalisé trois décodages pour la forme:
Et voilà les données codées (Aiken Biphase, ou F2F) extraites des captures de signaux:
Le premier est issu d'un ticket neuf, et les deux suivants de deux tickets a priori validés à Saint Lazare (Paris). Il est flagrant de voir qu'un motif général est présent, motif que l'on retrouve en partie dans le ticket de métro neuf. Chose intrigante, le ticket de métro neuf possède moins d'information que les tickets compostés. J'en déduis donc que des données sont ajoutées lors de la validation, et qu'un ticket de métro neuf est codé d'une manière particulière.Si vous regardez bien, il y a de légères variations de période, mais cela est dû au fait que je scanne manuellement, et ma vitesse de balayage n'est pas constante.
J'ai donc entrepris de décoder les premiers bits significatifs communs aux trois tickets, et voici ce qui en ressort:
Ticket neuf: 11111111 00100 11111 11111 11111 0 Ticket #1: 11111111 00100 11111 00110 01001 0 Ticket #2: 11111111 00100 11111 00110 01110 1
Les espaces sont de mon fait ;). J'ai pu déduire le rôle de chacun (ou du moins tenter de deviner) à partir des informations décodées:
Si on regarde de plus près le codage, on peut voir que sur le premier ticket validé les troisième et quatrième séquences de 5 bits correspondent aux valeurs 69 et 6E. Ou plus précisemment aux valeurs 6 et 9, et 6 et 14. Cela ressemble bien aux codes de stations connus de Paris, tels que décrit sur Wikipédia. Cela signifie qu'un de mes tickets a été validé à Saint-Lazare même (code station 0609), l'autre à la station ayant pour code 0614 (inconnu sur Wikipédia oO). Le dernier bit que j'ai repéré semble être un bit de parité.
Le plus drôle dans l'histoire, c'est de voir que le ticket vierge n'a aucune valeur paramétrée, si ce n'est le type de ticket (première séquence de 5 bits). Donc facile à cloner.
Conclusion
La sécurité des tickets de métro ... heuu.... quelle sécurité ? Il est a priori aisé de dupliquer des tickets neufs (aucune limite dans le temps ni dans l'espace}, la seule limitation est technique (il faut un matériel particulier). De même, je n'ai pas détaillé ici le décodage complet mais la suite des bits stockés représentent très certainement la date de validation et l'heure de validation, mais je n'ai pas vraiment cherché à le décoder.
Heureusement qu'il y a le passe Navigo pour tous nous sauver (spéciale dédicace à Nono2357 ;).
C'était un de ces soirs durant lesquels je geeke jusqu'à tomber de sommeil, sauf que là j'étais en vacances. C'est ennuyeux, les vacances. Alors j'ai pris la (sage) décision de mettre à profit mon temps disponible pour avancer mes nombreux projets. Et comme à mon habitude, je n'ai pas pu m'empêcher de diverger et d'aller titiller d'autres sujets. Je ne sais plus trop pourquoi, mais je me suis intéressé à un moyen d'évaluer de manière fiable ou presque le trafic d'un serveur distant, et la première chose qui m'est venue à l'esprit est l'analyse du champ Identification des datagrammes IP.
Premiers tests, et premières déceptions
J'ai donc entamé la recherche d'une méthode efficace permettant d'évaluer le trafic d'un serveur distant, en me basant sur l'évolution du champ Identification du protocole IP. Ce champ est en réalité un compteur sur 16 bits (entier non-signé), incrémenté de 1 à chaque émission de paquet. Au vu des quantités de paquets émis par un serveur, ce compteur boucle assez régulièrement, et il est donc très difficile de déduire quoi que ce soit. Ce champ est aussi souvent appelé IP/ID.
J'ai donc commencé mes tests par le développement d'un outil en Python, utilisant Scapy, et émettant à intervalle très court deux requêtes ICMP Echo Request, calculant le temps de parcours depuis l'envoi, et essayant de déterminer la vitesse d'évolution des IP/ID. L'implémentation n'a pas été un problème en soit, par contre les résultats n'étaient pas au rendez-vous, et pour cause: la mesure de temps n'est pas fiable. En réalité, nous ne disposons que d'une référence pour cette mesure de temps: la machine émettrice. Le réseau Internet étant ce qu'il est nous ne sommes pas sûrs de plusieurs choses: * les paquets peuvent avoir été routés via des chemins différents entre les deux requêtes * des latences réseau ont pu se produire, et faire varier le temps d'émission./réception des paquets Autant de facteurs qui rendent la mesure imprécise, et au vu du laps de temps très court séparant l'envoi des deux paquets, l'erreur introduite est élevée. Il n'est donc pas fiable d'employer cette méthode pour déterminer la quantité de trafic qu'émet un serveur distant.
Les timestamps à la rescousse
Heureusement, le protocole ICMP met à notre disposition d'autres types de messages, comme celui permet de demander à une machine distante de nous envoyer des indications sur son horloge interne (Timestamp), ce qui a pour intérêt de pouvoir nous renseigner sur l'heure d'émission du paquet. En effet, le protocole ICMP étant un protocole de couche 4 (Transport), ses datagrammes sont encapsulés dans des datagrammes IP (protocole couche 3). Autrement dit, en envoyant un message ICMP Timestamp Request (Code:0, Type:13), le serveur distant peut y répondre avec un paquet ICMP contenant notamment un Timestamp paramétré par la machine ayant effectué la requête, et un Timestamp correspondant à l'heure d'émission de la réponse.
Il ne me fallait pas plus de choses pour que j'implémente une variante de l'outil précédent, prenant en compte cette fois-ci une mesure de temps beaucoup plus précise. Bien sûr, il faut que le serveur distant testé réponde à ce type de requête ICMP, ce qui n'est pas monnaie courante. Mais j'ai pu identifier certains sites connus qui y répondent favorablement: www.hsc.fr, www.lemonde.fr, www.lefigaro.fr, etc ... L'exemple ci-dessous, réalisé avec l'utilitaire hping2, démontre bien les réponses reçues:
virtubox:/home/virtualabs# hping2 -1 -K 0 -C 13 -r www.hsc.fr HPING www.hsc.fr (wlan0 217.174.211.25): icmp mode set, 28 headers + 0 data bytes len=40 ip=217.174.211.25 ttl=53 id=21302 icmp_seq=0 rtt=23.3 ms ICMP timestamp: Originate=2647898 Receive=2647955 Transmit=2647955 ICMP timestamp RTT tsrtt=24 len=40 ip=217.174.211.25 ttl=53 id=+15 icmp_seq=1 rtt=24.0 ms ICMP timestamp: Originate=2648899 Receive=2648955 Transmit=2648955 ICMP timestamp RTT tsrtt=24 len=40 ip=217.174.211.25 ttl=53 id=+6 icmp_seq=2 rtt=23.5 ms ICMP timestamp: Originate=2649899 Receive=2649955 Transmit=2649955 ICMP timestamp RTT tsrtt=23
Le timestamp qui m'intéressa fut celui dénommé Transmit, correspondant à l'heure de transmission. Ce timestamp est en réalité le nombre de millisecondes écoulées depuis 00h00, et est donc suffisamment précis pour être utilisé. De là, j'ai développé un premier outil affichant un aperçu visuel du trafic, toujours en Python avec la bibliothèque curses. Le résultat n'est pas super joli, mais fait l'affaire:
J'étais assez satisfait du résultat, bien que cet outil ne casse pas trois pattes à un canard. Néanmoins, après différents tests sur des serveurs publics, j'ai pu noter les inconvénients suivants:
Et cela a commencé à m'ennuyer, je suis donc reparti à la recherche de la méthode ultime permettant de déterminer dans tous les cas de figures la quantité de trafic supporté par une machine distante. Et c'est devenu un poil plus complexe ...
Approche probabiliste
Je me suis rapidement rendu à l'évidence, après plusieurs tentatives infructueuses: réaliser une étude analytique pure de la variation du champ IP/ID est une pure perte de temps, à cause de la faible entropie de ce compteur. Il me fallait partir dans une autre direction, et trouver une approche différente, mais toutefois fiable. Et c'est là que m'est venu l'idée de prendre le problème dans l'autre sens. Si une machine subit un trafic conséquent, alors il devrait être très difficile de prédire la valeur du prochain IP/ID retourné. Il s'agit ici d'une simple constatation probabiliste. Plus il y a de trafic, plus le champ IP/ID varie, et plus il est difficile de prédire sa prochaine valeur. Il existe toutefois un cas de figure, mais qui reste très peu probable: celui où le trafic est conséquent et constant.
Il m'a donc semblé intéressant de tenter cette approche. J'ai donc entamé le développement d'une preuve de concept, toujours en Python, qui visait à réussir une prédiction pour un serveur donné. Malheureusement, ceci est très difficile à obtenir, surtout lorsque l'on cherche à prédire exactement la valeur du prochain IP/ID. J'ai donc introduit une variable représentant une marge d'erreur augmentant progressivement (suite aux tests infructueux), et en faisant varier cette marge d'erreur de manière exponentielle, j'ai pu obtenir des résultants probant.
La recherche de prédiction exacte et/ou approximative permet, lorsqu'elle est réalisée sur une durée suffisamment longue, de pouvoir associer un score (heuristique) à la quantité de trafic émis par la machine distante. Il y a dans le cas présent une relation qui lie cette quantité de trafic (et de manière indirecte, la variation de cette quantité de trafic) à la difficulté de prédiction du champ IP/ID. En évaluant la difficulté de prédiction, on peut tenter de déduire la quantité de trafic. Il sagit d'une méthode probabiliste, aboutissant à un résultat fiable (qualitatif) mais non-quantitatif, permettant d'apprécier la quantité de trafic par rapport à un trafic de référence. Il semblerait toutefois qu'en cas de présence de répartiteurs de charge ou lorsque l'intervalle de temps entre deux mesures est trop grand, la mesure ne soit pas fiable.
To be continued ...
Je suis actuellement en train d'approfondir cette méthode d'évaluation probabiliste, en tentant notamment de lier la difficulté de prédiction d'IP/ID à la quantité de paquets émis par le serveur, bien que cela ne me semble pas évident du tout. De même, je continue mes tests afin de vérifier la validité de mes résultats, bien que pour le moment ils soient positifs.
Je publierai mon analyse dans les détails par la suite, ainsi que le code source de ma preuve de concept.