Scripts John The Ripper - Jumbo

Bon, cet article est un peu lame, surtout vu les exemples que je vais donner, mais l'idée c'est d'aborder la possibilité de récupérer le mot de passe d'un conteneur chiffré à l'aide de John the Ripper et ses outils (généralement fournis par le patch Jumbo).

Premièrement, ce que j'entends par conteneur, c'est un fichier dont le contenu est chiffré, et pour lequel un mot de passe est nécessaire pour obtenir/dériver une clé permettant le déchiffrement du contenu chiffré. Ici je vais présenter l'exemple de KeePassX et de TrueCrypt.

Il existe des outils certainement plus performants que John The Ripper pour ces algorithmes là. Je pense particulièrement à "truecrack" que je n'ai pas encore eu l'occasion de tester, mais qui est adapté pour la récupération du mot de passe d'un volume TrueCrypt. Mais mon propos ici est de montrer que le patch Jumbo de John The Ripper apporte un certain nombre de scripts très intéressants (ensuite, il est parfaitement possible d'utiliser oclHashCat pour casser le hash d'un volume TrueCrypt une fois qu'on l'a).

Je n'explique pas ici comment récupérer et compiler John the Ripper et son patch Jumbo (rtfm).

J'ai créé un volume TrueCrypt pour l'occasion, avec un mot de passe bateau: "toto", présent dans une de mes wordlists. Les algos utilisés sont ceux proposés par défaut par TrueCrypt :

On utilise ensuite le script "truecrypt_volume2john" fourni par John Jumbo :

Puis on passe le fichier résultant à John en spécifiant l'algo de hash utilisé (même si par défaut il utilise le bon), ainsi que le chemin vers notre wordlist bien fournie. Au bout de quelques secondes, on obtient notre mot de passe:

On peut faire la même chose avec KeePassX. J'ai créé une base KeePassX standard (pas de keyfile), puis le script keepass2john :

Là encore, on utilise John, et on a le mot de passe :

Bien évidemment, il existe un très grand nombre d'autres scripts, dont en vrac :

- 7z2john.py

- androidfde2john.py

- ecryptfs2john.py

- odf2john.py

- office2john.py

- pdf2john.py

- rar2john

...

De l'interprétation des advisos de sécurité : BES

En faisant un peu de veille sur Twitter, je suis tombé sur un lien vers un article parlant d'une vulnérabilité de la mort qui tue, affectant les serveurs BlackBerry :

La semaine dernière, les responsables de la sécurité de RIM ont reporté une vulnérabilité assez importante. En l’espèce, il s’agirait d’une faille qui toucherait surtout BlackBerry Enterprise Server, la solution professionnelle de BlackBerry.

De façon succincte, du code malveillant véhiculé à travers une image au format TIFF pourrait ouvrir une backdoor sur le téléphone, simplement en visitant un site Web comportant la dite image, ou envoyée en pièce jointe par email ou par BBM, la messagerie instantanée de BlackBerry.

Ca a l'air sexy, mais le peu que je connais du fonctionnement d'un serveur BlackBerry est en contradiction avec certains trucs écrits là dedans, et le fait de lire qu'une faille dans le processing TIFF du BES permet d'exécuter du code arbitraire sur le téléphone me chiffonne. Voyons ce que dit BlackBerry (ex RIM) dans son adviso...

Déjà, ce n'est pas une vulnérabilité, mais deux (CVE-2012-4447 et CVE-2012-2088). Il s'agit de deux overflows dans la bibliothèque LibTIFF, qui est utilisée dans un paquet de solutions diverses, commerciales ou non (merci la licence BSD qui le permet). Ces deux vulnérabilités permettent d'exécuter du code arbitraire avec les privilèges de "l'utilisateur" faisant tourner une hypothétique application utilisant la libtiff (donc du code en tant que user si une version vulnérable de la bibliothèque libtiff est embarquée dans le navigateur web d'une personne sous Linux par exemple). Bon, puis il s'agit de vulnérabilités qui ont été remontées il y a déjà un an pour la plus vieille, et il y a plus de six mois pour la seconde.

Ensuite, on voit que le score CVSS attribué aux deux vulnérabilités est de 10 (le max). C'est déjà le niveau au dessus de "assez importante". Mais passons, en fonction du contexte, le score CVSS de ces vulnérabilités pourrait varier de 10 (libtiff dans une application s'exécutant avec des privilèges d'administrateur) à 7.5 (libtiff dans une application s'exécutant sans privilèges) en pouvant même chûter à 6.8 si on ajoute la nécessité d'une interaction utilisateur (on attend qu'il visite une page web contenant un .tiff malveillant) . Dans le cadre du BES, c'est évidemment le premier cas qui s'applique.

Au niveau des logiciels impactés par ces vulnérabilités, toujours sur la page de l'adviso publié par BlackBerry, on expand le champ "affected software" de la catégorie "products" et on voit que seul le produit "BlackBerry Enterprise Server" et ses composants pour Domino, Exchange, etc. sont affectés. Dans la catégorie "non-affected software" on retrouve certaines versions du BES intégrant une version non vulnérable de la libtiff, ainsi que "BlackBerry Desktop Software" (le truc qui permet de synchroniser un device BlackBerry avec son PC) et "BlackBerry Device Software", qui est l'OS tournant sur les téléphones BlackBerry (BlackBerry OS). A ce niveau là, on a donc effectivement la confirmation que ça touche le BES, mais par contre on apprend que les smartphones ne sont pas impactés.

Donc pour l'installation d'une backdoor sur le téléphone, on repassera.

De toutes façons, la vulnérabilité se situe dans le moteur de traitement des images du BES (exemple, un utilisateur de smartphone blackberry reçoit un e-mail avec une image, le BES va la convertir dans un format et des dimensions adaptés au téléphone - c'est lors de ce traitement que la vulnérabilité dans la libtiff est exploitée et que du code arbitraire peut-être exécuté sur le BES, et non sur le téléphone). Il y a quelques années, une vulnérabilité permettant la même chose, exploitable par le même biais (pièce-jointe malveillante) avait été identifiée dans le composant PDF du BES.

Continuons la lecture de l'article...

Pour en revenir à la vulnérabilité, elle ne concerne pas uniquement que les entreprises, mais finalement, tous les possesseurs de BlackBerry car RIM a intégré sa propre vulnérabilité dans son système : BlackBerry Messenger.Considéré comme le killer apps  de la marque, il reste l’un des seuls atouts majeurs de BlackBerry face à Apple, Samsung et Nokia. Or, cette application est parfaite pour une attaque de type « drive-by-download » et nécessite Java pour fonctionner pleinement.

Il m'a fallu relire quelques fois la phrase pour comprendre qu'il s'agissait d'humour. Mais si on considère qu'un smartphone BlackBerry est vulnérable à cause de BlackBerry Messenger (BBM), on doit se rappeler qu'il y a 3 ou 4 ans, il était possible d'exécuter du code arbitraire sur un iPhone juste en lui envoyant des SMS (Charlie Miller, où que tu sois, on pense à toi).

J'ai eu un peu de mal à comprendre la petite phrase "et nécessite Java pour fonctionner pleinement". En effet, la majorité des téléphones BlackBerry en circulation utilisent un BlackBerry OS basé sur Java, donc le fait que BBM dépende de Java me semble évident : les applications BlackBerry sont en Java ! En regardant le lien vers lequel pointe cette petite phrase j'ai compris pourquoi l'auteur de l'article l'a mentionné; il y est dit que BBM  exige "Un téléphone Blackberry compatible Java", car effectivement, les premiers devices BlackBerry n'utilisaient pas Java.

Chaque smartphone BlackBerry possède un PIN (Personal Identification Number) composé de huit caractères, mélangeant chiffres et lettres, de façon apparemment aléatoire. Les rares documentations accessibles à ce sujet sont peu parlantes et ne permettent pas de déterminer si cette suite répond à une logique similaire à celle des IMEI ou des numéros de cartes de crédit.Dans la mesure où le PIN est limité à huit caractères, qu’il ne comporte pas de caractères spéciaux, qu’il n’est pas sensible à la casse, on peut émettre l’hypothèse d’une tentative d’attaques par le biais de BBM, en tapant quelque peu au hasard, du moins dans un premier temps et qu’une fois certaines informations collectées, l’attaquant peut ajuster son tir.

En fait ces "huit caractères, mélangeant chiffres et lettres, de façon apparemment aléatoire" sont la représentation hexadécimale d'un entier non-signé de 32 bits (donc dans les 4 milliards de possibilités, allant de 0x00000000 à 0xffffffff, tout en gardant à l'esprit que ces deux là sont peut-être réservés). Du coup, dans la mesure où il s'agit d'hexadécimal, on peut considérer qu'il est normal qu'il n'y ait pas de caractères aléatoires (et même qu'il n'y ait pas tout l'alphabet).

Concernant ensuite les infections de smartphones BlackBerry par "des petits malins générant des PIN aléatoires" et invitant les victimes à les rejoindre dans des groupes avant de les infecter, il ne semble pas y avoir eu de cas documenté. D'autant plus que dans le cas des vulnérabilités de la libtiff citées ci-dessus, il ne peut pas y avoir de compromission du téléphone, donc je ne vois pas bien ce que ces petits malins pourraient exploiter (mis à part se faire des amis sur BBM...).

Conclusion : l'auteur de l'article initial n'a vraisemblablement pas lu l'adviso de sécurité de BlackBerry (ex RIM quoi), et démontre sa totale méconnaissance de l'architecture blackberry (j'ai tenté d'être constructif en avançant mes arguments, ce n'est donc pas une attaque gratuite). Ce qui est un comble dans la mesure où la même personne a fait un talk à la Nuit du Hack l'an dernier parlant de sécurité mobile se soldant par la destruction d'un BlackBerry à l'aide d'un marteau (vers la 33e minute sur cette vidéo) :

Mozinor

Faisons un peu de hors sujet avec une vidéo de Mozinor bien bien amusante, basée sur une pub récente de La Poste (j'ignorais qu'il s'agissait d'une vraie pub à l'origine avant que l'on me le dise ce soir, vu que je n'ai pas de télé)

Documents Corrompus

Surfons sur la vague, continuons dans la lignée des posts inutiles et parlons de cette grande trouvaille (LoLoLoL) qu'est le site "corrupted-files". Ce site vend des documents Microsoft Office corrompus, c'est à dire que lorsque l'on en ouvre un, cela génère une erreur disant que le document est corrompu et ne peut pas être ouvert. Cool. Intérêt ? Envoyer un document qui semble correct à un prof/patron (typiquement le rapport du commercial hein) alors qu'on a rien foutu et qu'on veut gagner du temps ("oh comme c'est dommage, le document ne s'ouvre pas sur ton pc...")

En ouvrant un .docx avec un éditeur hexa, et en supprimant quelques octets, j'ai réussi à obtenir un message me disant que le document était corrompu:

Suivi, lorsque je clique sur OK, d'un message me disant que des données sont manquantes (j'ai peut-être été trop brutal lors de mon hexedit):


Et j'ai même réussi à obtenir un crash de Microsoft Word comme ça. Par contre je n'ai pas pensé à faire de screenshot, et vu que je n'arrive plus à le reproduire, c'est bien balot.
Je sens que je vais m'y mettre moi aussi à vendre des documents office corrompus pour 1 euro.
Plus sérieusement, je n'ai pas encore regardé comment OpenOffice ou AntiWord gèrent mon document corrompu (s'ils l'ouvrent quand même en essayant de se passer des infos manquantes en fonction de leur nature, ou s'ils échouent lamentablement comme Microsoft Word).
Puis faudrait aussi savoir quel est le contenu de ces fichiers Microsoft Office vendus sur ce site, car quand j'ouvre un .doc dans un hexedit, je vois quand même le texte apparaitre dedans. Et si l'étudiant paresseux envoie un tel document à son prof, et que ce dernier, en étudiant le contenu du fichier, découvre le "Lorem Ipsum blablabla", il risque de faire la tronche.

Challenge SSTIC

Il semblerait même que les diverses solutions du challenge SSTIC aient été mises en ligne (bon ça fait peut-être même quelques jours, mais je n'ai pas pensé à regarder ça ce week-end à vrai dire).
Ca me fera un peu de lecture pour les soirées à venir.

IRCFAIL

[mickou] hier je suis allé voir le film milenieum au ciné il est genial conseil allé le voir car la meuf qui joue le role de hackers pour un journaliste et tros baleze meme si sa reste qun film

Je pense que je vais grepper mes logs (quelle idée aussi d'idler sur ce chan irc) et faire un fichier de quotes de ce type.

Image du Challenge Securitech

Conformément à ce qui a été dit lors d'une rump session du SSTIC par Benjamin Caillat, une image vmware permettant de re-jouer une bonne partie des épreuves des différents challenges securitech a été mise à disposition via bit torrent (comme quoi, bittorrent ne permet pas QUE le partage des mp3 de johnny ou la filmographie complète de besson). Tout est décrit sur le site. Du coup j'en profite pour rendre ma bande passante chez OVH utile et je seed à une bonne vitesse pour permettre aux prochains téléchargeurs de la récupérer rapidement.

CR SSTIC 09

Contrairement à l'an dernier, je n'ai pas fait de compte rendu de chaque journée le soir même. Cette année j'ai à peine commencé à rédiger un compte rendu, je le mettrai en ligne au fur et à mesure (je pense que ça me fera une bonne activité pour mes trajets dans le métro dans les deux jours à venir).

Mais pour faire court, quelques impressions en vrac:

- La keynote de Pascal Andrei, qui travaille à la sécurité et la sûreté des avions Airbus, et nous a expliqué en quoi ces deux domaines sont différents, en citant des exemples de chacun (instruments de vol et leur fiabilité en cas de problème, cas des gilets de sauvetage avant décollage, le cas de l'isolation des réseaux passagers des réseaux de pilotage (point dont il avait été question à propos du prochain avion de chez Boeing, avec une notice de la FAA))

- La backdoor ACPI qui se déclenche après une succession de branchements/débranchements d'un laptop d'une source d'alimentation électrique m'a bien plue. L'objectif était de démontrer que certains composants d'un ordinateur ne faisant pas partie des architectures de confiance à la TxT d'Intel (comme un BIOS) peuvent quand même piloter (enfin, "influencer") la protection offerte par ces mêmes architectures de sécurité, le tout en modifiant les tables ACPI. Edifiant. On dira même "du grand Loic Duflot".

- La conf sur l'ISO 27001, ça m'a sensiblement éclairé sur certains points. Ca ne va pas révolutionner la sécurité informatique (sinon ça se saurait), et son utilité reste quand même discutable (bien que le speaker nous a dit que la majorité des boites qui se font certifier le font par réel souci de bien gérer les événements de sécurité et les moyens de réponse, et le reste le fait juste pour avoir le label rouge)

- Une présentation de fuzzgrind, outil de fuzzing basé sur la recherche (et la résolution) de contraintes dans un programme (trouver ce qui fait qu'un if() retourne vrai/faux, ou dans quels cas un while() sort par exemple) à l'aide de valgrind (enfin, un module de valgrind, au même titre que le célèbre memcheck, sauf que ce module permet de représenter des conditions sous une forme symbolique) et STP (un solveur de contraintes) et générer des saisies qui peuvent faire que ces contraintes sont résolues. On a eu un exemple sur un crackme, résolu en très peu de temps avec fuzzgrind (bon, en même temps la solution du crackme consistait à sortir une serie de chiffres dont la valeur etait égale à 15). Mais la démo était vraiment convaincante. On a aussi eu un début de démo (mais qui n'a pas pu aboutir faute de temps) d'un fuzzing de "readelf". Le speaker aurait trouvé un problème là dedans avec son fuzzer. Dès que j'aurai plus de temps, je m'y intéresserai.

- Mon trollomètre a pas mal bougé pendant la conf de Nicolas Ruff ("Pourquoi la sécurité est un echec ...") mais je m'y attendais. Beaucoup de choses ont été dites, et il fallait qu'elles le soient. Ce talk mériterait un post entier (ou une série de posts entiers) pour en parler. Le top, c'est que tout ça sentait le vécu, et les exemples étaient vraiment géniaux, au point que j'aurais bien aimé en avoir d'autres.
- J'ai été un peu largué pendant la conf sur "le traçage de traitres en multimédia". En gros c'est la présentation d'une variante du watermarking avec une dose de théorie des jeux afin de dire qui est à l'origine d'une fuite du prochain film de luc besson en intégrant des bits par ci par là dans la vidéo, de la manière la moins visible possible, tout en étant un max résistant aux dégradations dues au ré-encodage dans un format différent et de moins bonne qualité. Il y avait des maths d'un niveau tout autre que le mien (n'oubliez pas que j'ai passé un bac Littéraire et que je n'ai quasiment pas fait de maths après le bac (epitech, tout ça))

- Un talk sur les XSS, là aussi, même si c'était assez généraliste, on a eu quelques ouvertures intéressantes (botnet basé sur du xss) et des démos amusantes (la démo du xss sur le site du sstic était pas mal, et le xss sur myspace (qui demande de ne pas utiliser la balise script) aussi). Je ne suis pas pentester, mais c'est un talk comme celui ci que j'attendais pour changer d'avis sur ce type de failles.

- Maitre Raynal nous a montré quelques contournements de la sécurité d'acrobat reader avec des PDF spécialement craftés, avec par exemple un PDF qui exécute un binaire embarqué dans le fichier PDF une fois ouvert. Pas mal. Je m'intéressais à ce type d'attaques depuis un moment (pas forcément PDF, mais aussi les documents office par exemple), je pense que les actes vont bien m'occuper (le truc bien, c'est que les siens sont déjà en ligne pour ceux qui n'ont pas eu l'honneur d'y assister)

- Le talk sur la récupération des frappes claviers (filaires et sans-fils !!) était vraiment génial. Même si le concept est bien vieux (sur cryptome.org on trouve des documents déclassifiés de la NSA (grace au FOIA aux états unis) parlant de ce type d'écoutes et qui datent des années 50 ou 60), c'était captivant. Le speaker a bien réussi à intéresser tout le monde.

Concernant les rump sessions, là aussi je développerai dans les jours à venir, mais j'ai également fait une vidéo d'environ 25 minutes, correspondant aux 25 premières minutes de rumps. La qualité est moyenne, mais on arrive à entendre ce qui est dit, et on distingue quelques trucs au projecteur. La mauvaise nouvelle, c'est que j'ai pas trouvé de truc de compression pour conserver la meme qualité (enfin, si on peut dire ...) d'image et de son. Donc je vous uploaderai le fichier quelque part, qui fait dans les 1,5gb. Si quelqu'un parvient à en faire un fichier plus petit et utile (moi j'ai juste obtenu des fichiers inaudibles comme ça), je suis preneur.

J'ai aussi commencé à uploader une partie de mes photos. Du moins celles qui ne sont pas trop ratées (j'ai voulu éviter d'utiliser le flash, afin de ne pas perturber les speakers, du coup dans un amphi sombre, c'est pas super le résultat). Là aussi je mettrai le lien une fois l'upload terminé (ceux qui me suivent sur twitter ont peut être déjà vu celles que j'ai déjà pu uploader)

Je développerai tout ça au fur et à mesure en ajoutant mes commentaires sur les autres talks de ces trois jours un peu plus tard. De même, j'uploaderai mes photos et vidéos très prochainement et j'agrémenterai cet article de liens, so stay tuned. En attendant, vous pouvez vous rabattre sur le compte rendu fait en quasi direct par Sid. Il faudra aussi que je pense à remplir le sondage.

Préparatifs SSTIC

Voilà je suis fin prêt pour le SSTIC. Oui, vu la date c'est pas trop tôt. Enfin l'an dernier j'avais réservé mon hotel deux jours avant le début, et acheté mon billet aller 10 minutes avant le départ du train (je fais toujours ça, je paie plein pot :)).
M'étant acheté un appareil photo à l'occasion de vacances l'an dernier je pourrai enfin immortaliser certains moments avec autre chose que l'appareil photo 1,3mpx de mon téléphone portable, et peut-être même filmer les rump sessions! (l'an dernier, la qualité de la vidéo était vraiment trop mauvaise pour que j'ose la mettre à disposition)
Sinon, le texte de la LOPPSI est enfin disponible. Je l'ai lu sur http://www.loppsi.fr/. Le passage le plus amusant (lulz) se trouve au chapitre V, article 23 (ça fait un peu biblique dit comme ça, genre le Lévitique, Chapitre 19)
Pour finir, le dernier album de Marilyn Manson est sorti. C'est clairement mieux que l'inqualifiable merde qu'il avait osé nous sortir la dernière fois (eh oui, je n'écoute pas que du black metal !)

Des gens, et de leur vie privée

En fait tout ça me rappelle le gros bordel que ça avait été à l'époque où on nous parlait d'EDVIGE. Les gens ralent blabla le fichage policier blabla pas bien. Soit. Puis à côté de ça ils balancent leurs infos sans faire le tri, sur l'Internet Multimédia Interactif. Puis ça donne ce genre de choses.

Ca m'a évoqué le souvenir d'un workshop il y a deux semaines quelque part en allemagne... D'ailleurs une idée dont il était question, pour espérer sensibiliser les gens, était de les mettre face à la quantité d'infos sur eux à laquelle il est possible d'avoir accès dans être un service de renseignement. Je ne regarde plus la télé depuis des mois, je ne sais donc pas, par conséquent, si cette (més)aventure a été racontée au JT de 20h de TF1, mais si c'est le cas, ça va peut-être faire prendre conscience aux gens qu'ils en disent peut-être un peu trop sur eux.