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

...

Protip: Nokia N900 et kb_lock défectueux (écran qui clignote)

Il y a quelques semaines, mon bon vieux Nokia n900 (recyclé en "pwnphone") a commencé à défaillir. En gros, après un délai variable écoulé après le démarrage du téléphone, l'écran se mettait à "clignoter" (comprendre: s'allumer et s'éteindre plusieurs fois), et évidemment, le clavier semblait ne plus trop réagir au moment où l'écran s'éteignait. Ce qui est assez ennuyeux, vous en conviendrez aisément, lorsqu'on est dans un terminal pour geeker.

Fort heureusement, l'OS tournant sur ce téléphone (qui n'a pas été mis à jour depuis super longtemps) est un Linux (la distribution est Maemo), ce qui facilite un peu la tache pour essayer de comprendre ce qui se passe, et éventuellement régler le problème. La commande dmesg m'a aidé. En effet, entre deux blinks de mon écran, j'ai pu afficher le contenu du dmesg pour me rendre compte qu'il était rempli d'événements de ce type :

"kb_lock (GPIO 113) is now open"
"kb_lock (GPIO 113) is now closed"
[...]

En tout, une bonne dizaine par seconde. Une mauvaise impression m'a mené à penser que c'était l'écran coulissant qui était à l'origine de ce problème (me menant à démonter l'écran et son connecteur, résolvant le problème le temps d'une soirée ...), mais il s'agit de la GPIO 71 !

Quelques recherches m'ont mené au switch de verrouillage clavier situé sur le côté droit. C'est l'activation de ce dernier qui génère des événements sur la GPIO 113. Dans la mesure où je n'utilise pas ce switch lorsque l'écran clignote (faudrait être sacrément rapide pour l'activer une dizaine de fois en une poignée de secondes...), j'en déduis qu'il est défectueux (le n900 n'est plus produit par Nokia depuis 2009, je vous laisse faire le calcul de l'age minimum du téléphone...).

Fort heureusement, il est possible de désactiver, au niveau de l'OS, la prise en compte des événements générés par ce switch (le kb_lock). Il suffit de positionner à 1 le fichier déterminant la désactivation du kb_lock : /sys/devices/platform/gpio-switch/kb_lock/disable

# echo 1 > /sys/devices/platform/gpio-switch/kb_lock/disable

Evidemment, pour rendre cette manipulation persistante, il est nécessaire d'ajouter cette ligne dans un script qui sera exécuté au démarrage...

Skype et les données personnelles en clair

Ces derniers jours j'ai vu passer un certain nombre de fois un article parlant des données personnelles des utilisateurs de Skype qui sont stockées en clair sur les machines de ces derniers, comme quoi ça serait un scandale; par exemple, je lis sur PCInpact (excusez la référence...) "il s’agit d’une porte ouverte aux pirates en cas d’accès à la machine."

Le problème, si le contenu est chiffré, c'est que si la machine est compromise, rien n'interdit au vilain pirate d'accéder au contenu "protégé", ce dernier étant chiffré avec une clé stockée à un endroit accessible par l'application pour utilisation "user-friendly", et si l'application peut y accéder (car elle aura besoin de ce contenu), un pirate aussi (je me comprends).

Il s'agit d'une problématique qui a déjà été "abordée" (si on veut) par les développeurs de Google Chrome, en expliquant pourquoi, d'après eux, il est limite absurde d'implémenter un système de "master password" pour déverrouiller les accès aux mots de passe enregistrés dans le navigateur :

I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater.

Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants.

We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get.

On s'y retrouve.

Ensuite, j'ai limite envie de dire "ooooold" quand je vois cette "news" sur Skype. En fait, déjà dans le bouquin "Violent Python" sorti fin 2012 l'auteur explique comment développer un parser de logs Skype en Python (assez obvious vu le titre du livre). A titre personnel, je me suis fait un bête "parser" de logs Skype en Perl il y a quelques mois, histoire d'avoir un formatage personnalisé ("parser" est un bien grand mot, surtout quand on voit que le script se contente de faire un SELECT sur une base sqlite3 ...), et pour finir, j'ai vu passer début Avril un script (linké via les liens de LOTFREE) faisant la même chose.

Et si on va par là, on peut s'intéresser au dossier "~/.purple" des utilisateurs de Pidgin sous Linux, histoire de ne pas cracher que sur Skype.

Fin 2013

C'est pas que ce blog semble à l'abandon, mais presque. Un peu par manque de temps. D'un point de vue un peu plus personnel, en 2013 j'ai pu :

- faire un Paris-Londres à vélo cet été (je ferai un petit post à ce sujet un jour)

- passer une certification dans le domaine de la sécu (GIAC Reverse Engineering Malware, là aussi je ferai un petit post de review de la formation FOR610 du SANS qui allait avec)

- changer de boîte (bon, pas de post à ce sujet là, j'évite un maximum de parler d'aspects pro sur ce blog)

Sinon internet n'est toujours pas tombé. Pourtant on nous annonce tous les six mois qu'une nouvelle faille énorme arrive et va faire tomber le commerce en ligne. Encore que là, c'est les "révélations" de Snowden dont les gens parlent depuis le début de l'été (je n'irais pas jusqu'à dire "tout le monde", parce que je suis pas certain que le citoyen lambda que je croise dans la rue soit conscient de grand chose à ce sujet là).

D'ailleurs, tout le monde s'offusque des pratiques de la NSA, genre "oh mon dieu on nous espionne". Mais, sans vouloir faire de mauvais esprit (non, ce n'est pas mon genre), si la NSA a réussi, c'est que des services de contre espionnage ont échoué, ou en tout cas, mal fait leur boulot. Puis quand on espionne nous mêmes les USA, on espère que leurs services de contre espionnage se vautrent afin de récupérer une info précieuse, par-ci par là.

Lorsque j'ai commencé à m'intéresser à "la sécu", au tout début des années 2000 (oui, bon, c'était en 2000, OK), on parlait déjà un peu de la NSA, et d'un truc qui, visiblement, n'était pas connu de nos élus en 2013: ECHELON. C'est con, parce que le parlement européen avait pondu un joli petit rapport à propos d'ECHELON et de ses capacités présumées. Alors qund je vois nos élus raler en disant qu'ils ne savaient pas, et que c'est inacceptable, presque 15 ans plus tard, j'ai à peine l'impression d'être pris pour un abruti (ou alors, certains ont de grosses pertes de mémoire).

En 2014, on va peut-être nous dire que des reptiliens ont pris le contrôle des gouvernements de la planète...

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) :

Aide Google aux webmasters de sites compromis

C'est quelque chose qui est arrivé à un paquet de webmasters/administrateurs. Ca se matérialise parfois par un appel (en pleine nuit), avec au bout du fil quelqu'un qui dit (pas forcément en ces termes) :

"Google dit que le site est hacké"

Soudain, c'est la panique.

Que s'est-il passé ? Que faire ? C'est des conneries ?

Non.

Une faille merdique dans le CMS (moisi, genre Joomla) utilisé par le site/blog, ou un serveur encore vulnérable à une vulnérabilité dans Exim ou ProFTPd a permis à un Jean-Kevin (enfin, pas forcément, ça peut-être un bot à lui, ou son homologue russe Ivan-Boris) de venir polliniser (ou souiller) l'hébergement dudit site avec divers kits d'exploitation ou de phishing afin de contribuer à agrandir tel ou tel botnet.

A ce moment là commence la réponse à incident (enfin, en réalité ça commence avant la compromission en étant prêt à réagir). Pour le webmaster du dimanche, ça ne sera pas forcément évident.

Google a pensé à eux et a mis en ligne un guide (pour l'instant en anglais uniquement) expliquant tout un tas de choses :

- Pourquoi et comment les sites se font compromettre

- Mise en quarantaine du site

- Recherche du contenu posant problème

- Recherche de la vulnérabilité ayant permis la compromission

- Nettoyage du contenu malveillant

- Vérification du nettoyage

Ce guide permettra donc au responsable d'un site compromis de comprendre ce qui est attendu de lui au moment où il découvrira que son site héberge du blackhole. Le niveau de complexité des opérations est croissant, et si les premières étapes sont relativement simples, la fin l'est un peu moins (on ne peut en effet pas vraiment attendre de tous les webmasters qu'ils soient capables de faire du network forensics sur les logs du serveur hébergeant leur site). D'ailleurs, Google rappelle que s'il est possible de faire ça soi-même si on est à l'aise dans ces choses là, il est possible de faire appel à des spécialistes.

Bref, un bon guide qui mérite d'être mis plus en avant (et éventuellement traduit en français pour ceux qui ne sont pas compatibles avec l'anglais).

Résolution du challenge "Bandit"

A force de ne plus poster ici, j'en avais presque oublié l'existence de ce blog. Aussi, pour me ratrapper un peu je vous propose ma solution au challenge "Bandit" hébergé par overthewire que j'ai découvert récemment. Comme vous pourrez le voir, il n'est pas bien complexe, et sa résolution prend tout au plus 1h-1h30, pour une vingtaine de niveaux. Le niveau de difficulté n'est pas spécialement croissant, en fait c'est assez variable; certains des derniers niveaux peuvent être résolus en une dizaine de secondes, quand certains des premiers niveaux peuvent demander quelques minutes. Il ne s'agit pas d'un challenge de sécurité à proprement parler, mais plutôt de skillz en ligne de commande UNIX (néanmoins, ça peut représenter une bonne initiation aux challenges de sécurité type CTF).


Vu que mon but n'est pas de balourder bêtement une série de commandes UNIX permettant la résolution (autant refiler directement le mot de passe du dernier niveau), j'essaie d'expliquer au maximum mon raisonnement à chaque étape.

Niveau 0 :
Comme indiqué dans l'intitulé du niveau, le but est de se logguer sur la machine bandit.labs.overthewire.org avec le login bandit0 et le même mot de passe.

meik@athena:~$ ssh bandit0@bandit.labs.overthewire.org
[...]
bandit0@bandit.labs.overthewire.org's password: 
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-virtual x86_64)
[...]
bandit0@melissa:~$

Voilà, à vaincre sans péril, on triomphe sans gloire. En même temps il s'agit du premier niveau d'un challenge assez simple.

Niveau 1 :
On reste connecté en tant que bandit0 (étape précédente). L'intitulé du niveau nous dit que le mot de passe permettant d'accéder au niveau suivant se situe dans un fichier nommé "readme" dans le répertoire home. Ce mot de passe nous permettra de nous authentifier en tant que "bandit1".

On vérifie qu'on est bien dans notre répertoire home avec la commande pwd :

bandit0@melissa:~$ pwd
/home/bandit0

On vérifie la présence du fichier "readme" avec la commande "ls" :

bandit0@melissa:~$ ls -l
total 4
-rw-r----- 1 bandit1 bandit0 33 2012-05-10 23:51 readme

On affiche son contenu avec la commande "cat" :

bandit0@melissa:~$ cat readme 
boJ9jbbUNNfktd78OOpsqOltutMc3MY1


Niveau 2 :
On utilise le mot de passe obtenu précédemment afin de se logguer en tant que bandit1 :

meik@athena:~$ ssh bandit1@bandit.labs.overthewire.org
[...]
bandit1@bandit.labs.overthewire.org's password: 
[...]
bandit1@melissa:~$

On nous dit que dans notre dossier home il y a un fichier dont le nom est "-", et ce fichier contient notre mot de passe. Facile, allons y avec "cat" :

bandit1@melissa:~$ cat -
[rien]

Il ne se passe rien. En fait, la commande "cat", lorsqu'elle a en paramètre "-", elle n'affiche pas un fichier nommé comme ça. Ce paramètre signale à la commande "cat" qu'elle va devoir récupérer des données sur stdin (le flux d'entrées standard, grosso modo le clavier). Alors comment faire pour afficher un fichier nommé "-" si cat ne le permet pas ? Eh bien on va feinter et faire croire à "cat" que le fichier a un nom sensiblement plus long, et surtout, qu'il ne commence pas par un "-" en utilisant le préfixe "./" qui signale que le fichier se trouve dans le dossier courant (chemin relatif):

bandit1@melissa:~$ cat ./-
CV1DtqXWVFXTvM2F0k09SHz0YwRINYA9

Ca marche. Notez que ça fonctionne également en passant le chemin complet du fichier :

bandit1@melissa:~$ cat /home/bandit1/-
CV1DtqXWVFXTvM2F0k09SHz0YwRINYA9


Niveau 3 :
Tout comme dans le niveau précédent, le mot de passe se situe dans un fichier présent dans le dossier home. Comme à l'instant, un "cat" sur le nom de fichier seul ne suffit pas. En effet, cat va croire qu'on veut afficher le contenu des fichiers "spaces", "in", "this" et "filename", sauf qu'aucun de ces fichiers là n'existe. On va devoir feinter d'une de ces deux manières :

- échapper les caractères d'espacement :
$ cat spaces\ in\ this\ filename
Cela permet "d'ignorer" les espaces en tant que délimiteurs de paramètres.
- passer tous ces mots en un seul paramètre à l'aide des "" :
$ cat "spaces in this filename"

Notez que dans les deux cas, vous pouvez juste taper
$ cat spaces

Et le shell va compléter automatiquement le nom de fichier (dans ce cas là, il utilise la première méthode).

On obtient notre mot de passe pour le niveau suivant :
UmHadQclWmgdLOKQ3YNgjWxGoRMb5luK



Niveau 4 :
Ici le mot de passe se situe dans un fichier caché du dossier "inhere". D'après la page de manuel de la commande "ls", on va utiliser le paramètre "a" pour lister les fichiers cachés (fichiers dont le nom commence par un point '.') :

Allons dans le dossier "inhere" à l'aide de la commande "cd" (change directory) et affichons le contenu de ce dossier à l'aide de la commande "ls" et des paramètres qui vont bien :

bandit3@melissa:~$ cd inhere
bandit3@melissa:~/inhere$ ls -al
total 12
drwxr-xr-x 2 root    root    4096 2012-05-10 23:51 .
drwxr-xr-x 3 root    root    4096 2012-05-10 23:51 ..
-rw-r----- 1 bandit4 bandit3   33 2012-05-10 23:51 .hidden

Il y a effectivement un fichier caché dont le nom est .hidden. Affichons le comme tout fichier normal :
bandit3@melissa:~/inhere$ cat .hidden 
pIwrPrtPN36QITSp3EQaw936yaFoFgAB


Niveau 5 :
Cette fois, dans le dossier "inhere" on a plusieurs fichiers. On nous dit dans l'énoncé que notre mot de passe se situe dans le seul fichier lisible humainement du dossier. Voyons ça :

bandit4@melissa:~/inhere$ ls -l
total 40
-rw-r----- 1 bandit5 bandit4 33 2012-05-10 23:51 -file00
-rw-r----- 1 bandit5 bandit4 33 2012-05-10 23:51 -file01
-rw-r----- 1 bandit5 bandit4 33 2012-05-10 23:51 -file02
-rw-r----- 1 bandit5 bandit4 33 2012-05-10 23:51 -file03
-rw-r----- 1 bandit5 bandit4 33 2012-05-10 23:51 -file04
-rw-r----- 1 bandit5 bandit4 33 2012-05-10 23:51 -file05
-rw-r----- 1 bandit5 bandit4 33 2012-05-10 23:51 -file06
-rw-r----- 1 bandit5 bandit4 33 2012-05-10 23:51 -file07
-rw-r----- 1 bandit5 bandit4 33 2012-05-10 23:51 -file08
-rw-r----- 1 bandit5 bandit4 33 2012-05-10 23:51 -file09
bandit4@melissa:~/inhere$ cat ./-file00 
[données que je ne peux même pas copier en mode plaintext]

Bon ok. pas vraiment concluant. On pourrait afficher tous ces fichiers, on finirait par tomber sur le bon (-file07). Mais ce n'est pas la solution la plus élégante. L'énoncé nous conseille d'utiliser la commande "file". Oui, mais que fait cette commande ? Eh bien d'après la page de manuel (man file), elle nous indique le type d'un fichier. On va aller plus loin automatisant la recherche de différences entre fichiers via un mini "script" :

bandit4@melissa:~/inhere$ for i in ./*; do file $i; done
./-file00: data
./-file01: data
./-file02: data
./-file03: data
./-file04: data
./-file05: data
./-file06: data
./-file07: ASCII text
./-file08: data
./-file09: data

Cette commande consiste en une boucle (for) qui va lancer la commande "file" sur chaque fichier (un fichier différent à chaque itération) correspondant à un pattern donné (./*). On voit ici que "-file07" est un fichier d'un type différent des autres. Affichons le :

bandit4@melissa:~/inhere$ cat ./-file07 
koReBOKuIDDepwhWk7jZC0RTdopnAYKh


Niveau 6 :
Cette fois, nous devons trouver un fichier dont nous ne savons pas grand chose:

- il se situe dans le dossier "inhere"
- il est lisible humainement (heureusement)
- il fait 1033 octets
- il n'est pas exécutable

Allons dans le dossier "inhere" :

bandit5@melissa:~$ cd inhere/
bandit5@melissa:~/inhere$ ls
maybehere00  maybehere04  maybehere08  maybehere12  maybehere16
maybehere01  maybehere05  maybehere09  maybehere13  maybehere17
maybehere02  maybehere06  maybehere10  maybehere14  maybehere18
maybehere03  maybehere07  maybehere11  maybehere15  maybehere19

Bon ok, la méthode bourrinage va être un peu trop longue. On va utiliser la commande "find". En lisant la page de manuel (man find), on apprend qu'on peut spécifier la taille du fichier à l'aide de la commande "-size" suivie de la taille et de l'unité, dans notre cas la commande sera :

bandit5@melissa:~/inhere$ find ./ -size 1033c
./maybehere07/.file2

Affichons le contenu de ce fichier :
bandit5@melissa:~/inhere$ cat ./maybehere07/.file2
DXjZPULLxYr17uwoI01bNLQbtFemEgo7[...]


Niveau 7 :
Cette fois, on ne nous dit pas où est situe le fichier. On sait juste qu'il est quelque part sur le serveur et qu'il a ces propriétés :

- il appartient à l'utilisateur "bandit7"
- il fait partie du groupe "bandit6"
- il fait 33 octets

Comme on est bien élevés, on a lu la page de manuel de find, et ça nous donne la commande suivante :

bandit6@melissa:~$ find / -user bandit7 -group bandit6 -size 33c 2>/dev/null
/var/lib/dpkg/info/bandit7.password

Notez le petit "2>/dev/null" qui nous permet de rediriger le contenu du file descriptor 2 (stderr) vers /dev/null (autrement dit, en langage humain, ça nous permet de ne pas afficher les messages d'erreurs renvoyés par "find" lors de la recherche et dûs à des fichiers un peu spéciaux pas accessibles).

Affichons le mot de passe :
bandit6@melissa:~$ cat /var/lib/dpkg/info/bandit7.password
HKBPTKQnIay4Fw76bEy8PVxKEDQRKTzs


Niveau 8 :
Cette fois, nous avons un fichier "data.txt" qui contient notre mot de passe. On nous indique qu'il se situe à côté du mot "millionth". Un "ls" nous indique que ce fichier fait tout de même 4Mo, donc le parcourir à la main ne sera pas évident. On va donc voir si on ne peut pas faciliter cette recherche. La commande "head" nous permet d'afficher les premières lignes du fichier :

bandit7@melissa:~$ head data.txt 
toothpaste's   8Qu0FK3BZmkIj8JNJBNqTfZCaYlkyhi7
russet's   6f1kAhSjlmKIrPPCe7na5PdscB9bzqWk
lithography   EbBu8X0J12sYVH3ZmhNyf98vPzmN1duC
fisherman   PK7F2mPR0ZWurRuM7uM4Ax9odVmBVeOI
vaporizers   qKYU1t8tZANX4gacarW8PEFAvbgfpQOl
sequenced   EjcO8zOwsMGQUsZdNjaE0gFNa4CGT7S9
Benzedrine's   NXb0DMO27PlJRJkR3m3A3Ie7Bb88YLN1
Procrustes   8vhCvrtmViwoggcW4SWTky6axLiooaQB
earthwards   vrzDbocWB3MehcDSes14sHQ56JzWfMCQ

On voit qu'il y a un "mot" ainsi qu'une chaine de caractères ressemblant à ce qui pourrait être notre mot de passe sur chaque ligne. Alors on a là encore plusieurs possibilités :

- la triche en utilisant vi/emacs/autre et sa fonction de recherche
/millionth (dans vi)
- la méthode attendue :
bandit7@melissa:~$ grep "millionth" data.txt 
millionth   cvX2JJa4CFALtqS87jk27qwqGhBM9plV


Niveau 9 :
Dans ce niveau, nous avons un fichier contenant plein de chaines pouvant potentiellement être notre mot de passe. On nous donne une indication, c'est la seule ligne dont le contenu est unique qui nous intéresse. Bon, le problème c'est que toutes ces lignes se ressemblent un peu. On nous donne en "hint" la commande "uniq". En regardant la page de manuel (man uniq) on apprend que cette commande ne marche bien que lorsque les lignes se suivent. On va donc également trier le contenu du fichier à l'aide de la commande "sort, et rediriger la sortie du fichier trié vers "uniq" :

bandit8@melissa:~$ cat data.txt | sort | uniq -u
UsvVyFSfZZWbi6wgC7dAFyFuR6jQQUhR


Niveau 10 :
La commande "file" indique qu'on nous a mis en présence du fichier "data.txt" qui est un gros fichier de données binaires qui ne peuvent pas être affichées dans cat, head, etc. On va donc utiliser l'utilitaire "string" qui permet d'extraire les chaines de caractère d'un fichier :

bandit9@melissa:~$ strings data.txt
[...] (plein de chaines)

Pour simplifier, on nous indique que le fichier contient quelques lignes qui commencent par le caractère "=" et que notre mot de passe se situe sur l'une de ces lignes. On va filtrer à l'aide de la commande "grep" :

bandit9@melissa:~$ strings data.txt | grep '='
========== the
R=ev2,
NF=!^
M5Q=
========== password
TuI@=
========== iss
c   =$
w=RO
eD=p
jR=JlB
G========== truKLdjsbJ5g7yyJ2X2R0o3a5HQJFuLk
:=*1p
KA=%

Et hop, on repère immédiatement notre mot de passe (truKLdjsbJ5g7yyJ2X2R0o3a5HQJFuLk) et on passe à la suite...


Niveau 11 :
On nous indique ici que le mot de passe se situe dans le fichier data.txt qui a été encodé au format base64. On voit qu'il y a une commande "base64" sur le système et qu'elle permet d'encoder/décoder des données dans ce format. Redirigeons la sortie d'un "cat" vers cette commande :

bandit10@melissa:~$ cat data.txt | base64 -d
The password is IFukwKGsFW8MOq3IRFqrxE1hxTNEbUPR


Niveau 12 :
On nous a mis ici en présence d'un fichier "chiffré" à l'aide de l'algorithme rot13 (chaque lettre est décalée de 13 rangs) :

bandit11@melissa:~$ cat data.txt 
Gur cnffjbeq vf 5Gr8L4qetPEsPk8htqjhRK8XSP6x2RHh

On peut là encore résoudre ce problèmes de deux manières :
- trouver un décodeur rot13 sur google
- utiliser la commande "tr" qui permet d'effectuer des correspondances de caractères

On va donc indiquer à la commande tr que les caractères entre A et M devront être remplacés par des caractères allant de N à Z et inversement (idem pour les minuscules) :

bandit11@melissa:~$ cat data.txt | tr a-zA-Z n-za-mN-ZA-M
The password is 5Te8Y4drgCRfCx8ugdwuEX8KFC6k2EUu



Niveau 13 :
Cette fois ci, notre fichier "data.txt" a une apparence étrange :

0000000: 1f8b 0808 8538 ac4f 0203 6461 7461 322e  .....8.O..data2.
0000010: 6269 6e00 0141 02be fd42 5a68 3931 4159  bin..A...BZh91AY
0000020: 2653 5935 a61d 4000 0017 7fff fd73 cf7f  &SY5..@......s..
0000030: abf1 1f5f fffb ffff bdff 7ed0 ab5b acf9  ..._......~..[..
0000040: 7fff f7fd fe59 feff fdfb f7ff b001 3a68  .....Y........:h
0000050: d200 d00d 0000 3400 0d07 a400 0000 0340  ......4........@

Il s'agit de ce qu'on appelle un "dump hexa". Ca facilite la visualisation du contenu de données binaires. On nous indique qu'il s'agit du dump hexa d'un fichier compressé à de multiples reprises. Bien, mais que faire avec un dump hexa ? On pourrait s'amuser à le recréer à la main, mais en fait la commande "xxd" peut faire ça pour nous :

Créons d'abord un répertoire de travail dans /tmp/ :
bandit12@melissa:~$ mkdir /tmp/lolz
bandit12@melissa:~$ cd /tmp/lolz

Recréons maintenant le fichier original à partir du dump :
bandit12@melissa:/tmp/lolz$ xxd -r ~/data.txt > data.txt
bandit12@melissa:/tmp/lolz$ file data.txt 
data.txt: gzip compressed data, was "data2.bin", from Unix, last modified: Thu May 10 23:52:05 2012, max compression

Bon, il s'agit de données au format gzip. On peut renommer le fichier en data.txt.gz (gzip se plaint si le fichier n'a pas cette extension) ou alors utiliser zcat et rediriger la sortie vers un autre fichier :

bandit12@melissa:/tmp/lolz$ zcat data.txt > blah
bandit12@melissa:/tmp/lolz$ ls
blah  data.txt
bandit12@melissa:/tmp/lolz$ file blah 
blah: bzip2 compressed data, block size = 900k

Une archive bzip2, décompressons là :
bandit12@melissa:/tmp/lolz$ bzip2 -d blah
bzip2: Can't guess original name for blah -- using blah.out

Quel est le format du fichier qui vient de sortir ?
bandit12@melissa:/tmp/lolz$ file blah.out 
blah.out: gzip compressed data, was "data4.bin", from Unix, last modified: Thu May 10 23:52:05 2012, max compression

Encore du gzip...
bandit12@melissa:/tmp/lolz$ zcat blah.out > lol
bandit12@melissa:/tmp/lolz$ file lol
lol: POSIX tar archive (GNU)


du tar cette fois ci...
bandit12@melissa:/tmp/lolz$ tar -xvf lol 
data5.bin
bandit12@melissa:/tmp/lolz$ file data5.bin 
data5.bin: POSIX tar archive (GNU)
bandit12@melissa:/tmp/lolz$ tar -xvf data5.bin 
data6.bin
bandit12@melissa:/tmp/lolz$ file data6.bin 
data6.bin: bzip2 compressed data, block size = 900k
bandit12@melissa:/tmp/lolz$ bzip2 -d data6.bin
bzip2: Can't guess original name for data6.bin -- using data6.bin.out
bandit12@melissa:/tmp/lolz$ file data6.bin.out 
data6.bin.out: POSIX tar archive (GNU)
bandit12@melissa:/tmp/lolz$ tar -xvf data6.bin.out 
data8.bin
bandit12@melissa:/tmp/lolz$ file data8.bin 
data8.bin: gzip compressed data, was "data9.bin", from Unix, last modified: Thu May 10 23:52:05 2012, max compression
bandit12@melissa:/tmp/lolz$ zcat data8.bin > marre
bandit12@melissa:/tmp/lolz$ file marre 
marre: ASCII English text
bandit12@melissa:/tmp/lolz$ more marre 
The password is 8ZjyCRiBWFYkneahHwxCv3wb2a1ORpYL




Niveau 14 :
Pour ce niveau, pas de mot de passe à récupérer. On nous indique juste que le mot de passe pour le niveau suivant se situe dans /etc/bandit_pass/bandit14 et que seul l'utilisateur bandit14 peut le lire (ce qui n'est pas notre cas, vu qu'on est bandit13). On nous donne par contre la clé SSH privée de cet utilisateur. Si on lit attentivement la page de manuel openssh, on voit que le paramètre "-i" permet de spécifier une clé privée à utiliser. Voyons cela :

bandit13@melissa:~$ ssh -i sshkey.private bandit14@localhost
Could not create directory '/home/bandit13/.ssh'.
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 9d:09:d9:46:84:df:f9:dd:cc:7c:dc:49:a0:95:b2:10.
Are you sure you want to continue connecting (yes/no)? yes
[...]
bandit14@melissa:~$ cat /etc/bandit_pass/bandit14 
4wcYUJFw0k0XLShlDzztnTBHiqxU3b3e

Parfait. Passons au niveau suivant. Vu qu'on a besoin de ce mot de passe, on le garde précieusement de côté...


Niveau 15 :
On nous demande d'envoyer le mot de passe qu'on vient d'obtenir sur le port 3000 de localhost. En regardant un peu les commandes suggérées dans les conseils, on retient les commandes "nc" et "telnet". Essayons "telnet" :

bandit14@melissa:~$ telnet localhost 30000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
4wcYUJFw0k0XLShlDzztnTBHiqxU3b3e
Correct!
BfMYroe26WYalil77FoDi9qh59eK5xNr


Niveau 16 :
Il s'agit de faire la même chose sur le port 30001, la différence est que le service tournant sur ce port s'attend à recevoir des données chiffrées. On retient la commande "openssl" avec son paramètre "s_client" :

bandit15@melissa:~$ openssl s_client -connect localhost:30001
CONNECTED(00000003)
[...]
BfMYroe26WYalil77FoDi9qh59eK5xNr
Correct!
cluFn7wTiGryunymYOu4RcffSxQluehd


read:errno=0




Niveau 17 :
D'après l'énoncé, c'est assez proche des deux niveaux précédents. La différence est qu'on ne nous dit pas sur quel port se trouve le service auquel envoyer notre mot de passe. On nous dit qu'on va en trouver plusieurs, mais que celui qui nous intéresse est en SSL et que c'est le seul qui ne nous renverra pas strictement la même chose que ce qu'on lui envoie (comme un écho).

On utilise la commande "nmap" pour lister les ports en écoute sur le serveur :

bandit16@melissa:~$ nmap localhost -p 31000-32000


Starting Nmap 5.21 ( http://nmap.org ) at 2012-07-09 17:40 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00081s latency).
Not shown: 996 closed ports
PORT      STATE SERVICE
31046/tcp open  unknown
31518/tcp open  unknown
31691/tcp open  unknown
31790/tcp open  unknown
31960/tcp open  unknown


Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
bandit16@melissa:~$ 

Alors là j'ai pas trouvé de solution particulièrement élégante, si ce n'est tester chaque port à la main et voir si ce qu'il me renvoie est un bête écho ou pas, à l'aide de netcat (ou telnet). Lorsque ça n'est pas le cas, c'est que le port attend du SSL, et j'utilise "openssl s_client localhost:port" et je soumets le mot de passe ayant servi à m'authentifier.

On finit par tomber sur le port 31790 qui nous donne une clé privée RSA :

-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAvmOkuifmMg6HL2YPIOjon6iWfbp7c3jx34YkYWqUH57SUdyJ
imZzeyGC0gtZPGujUSxiJSWI/oTqexh+cAMTSMlOJf7+BrJObArnxd9Y7YT2bRPQ
Ja6Lzb558YW3FZl87ORiO+rW4LCDCNd2lUvLE/GL2GWyuKN0K5iCd5TbtJzEkQTu
DSt2mcNn4rhAL+JFr56o4T6z8WWAW18BR6yGrMq7Q/kALHYW3OekePQAzL0VUYbW
JGTi65CxbCnzc/w4+mqQyvmzpWtMAzJTzAzQxNbkR2MBGySxDLrjg0LWN6sK7wNX
x0YVztz/zbIkPjfkU1jHS+9EbVNj+D1XFOJuaQIDAQABAoIBABagpxpM1aoLWfvD
KHcj10nqcoBc4oE11aFYQwik7xfW+24pRNuDE6SFthOar69jp5RlLwD1NhPx3iBl
J9nOM8OJ0VToum43UOS8YxF8WwhXriYGnc1sskbwpXOUDc9uX4+UESzH22P29ovd
d8WErY0gPxun8pbJLmxkAtWNhpMvfe0050vk9TL5wqbu9AlbssgTcCXkMQnPw9nC
YNN6DDP2lbcBrvgT9YCNL6C+ZKufD52yOQ9qOkwFTEQpjtF4uNtJom+asvlpmS8A
vLY9r60wYSvmZhNqBUrj7lyCtXMIu1kkd4w7F77k+DjHoAXyxcUp1DGL51sOmama
+TOWWgECgYEA8JtPxP0GRJ+IQkX262jM3dEIkza8ky5moIwUqYdsx0NxHgRRhORT
8c8hAuRBb2G82so8vUHk/fur85OEfc9TncnCY2crpoqsghifKLxrLgtT+qDpfZnx
SatLdt8GfQ85yA7hnWWJ2MxF3NaeSDm75Lsm+tBbAiyc9P2jGRNtMSkCgYEAypHd
HCctNi/FwjulhttFx/rHYKhLidZDFYeiE/v45bN4yFm8x7R/b0iE7KaszX+Exdvt
SghaTdcG0Knyw1bpJVyusavPzpaJMjdJ6tcFhVAbAjm7enCIvGCSx+X3l5SiWg0A
R57hJglezIiVjv3aGwHwvlZvtszK6zV6oXFAu0ECgYAbjo46T4hyP5tJi93V5HDi
Ttiek7xRVxUl+iU7rWkGAXFpMLFteQEsRr7PJ/lemmEY5eTDAFMLy9FL2m9oQWCg
R8VdwSk8r9FGLS+9aKcV5PI/WEKlwgXinB3OhYimtiG2Cg5JCqIZFHxD6MjEGOiu
L8ktHMPvodBwNsSBULpG0QKBgBAplTfC1HOnWiMGOU3KPwYWt0O6CdTkmJOmL8Ni
blh9elyZ9FsGxsgtRBXRsqXuz7wtsQAgLHxbdLq/ZJQ7YfzOKU4ZxEnabvXnvWkU
YOdjHdSOoKvDQNWu6ucyLRAWFuISeXw9a/9p7ftpxm0TSgyvmfLF2MIAEwyzRqaM
77pBAoGAMmjmIJdjp+Ez8duyn3ieo36yrttF5NSsJLAbxFpdlc1gvtGCWW+9Cq0b
dxviW8+TFVEBl1O4f7HVm6EpTscdDxU+bCXWkfjuRb7Dy9GOtt9JPsX8MBTakzh3
vBgsyi/sN3RqRBcGU40fOoZyfAMT8s1m/uYv52O6IgeuZ/ujbjY=
-----END RSA PRIVATE KEY-----

On la copie quelque part dans /tmp/ et on utilise ssh pour se logguer en tant que bandit17 sur la machine, sans oublier de mettre les bons droits sur le fichier (openssh ignore la clé privée si elle est lisible par d'autres personnes que son propriétaire):

bandit16@melissa:/tmp/ololol$ chmod 600 ssh.key 
bandit16@melissa:/tmp/ololol$ ssh -i ssh.key localhost -l bandit17
Could not create directory '/home/bandit16/.ssh'.
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 9d:09:d9:46:84:df:f9:dd:cc:7c:dc:49:a0:95:b2:10.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/bandit16/.ssh/known_hosts).
[...]
Last login: Wed Jul 11 15:53:55 2012 from localhost
bandit17@melissa:~$


Niveau 18 :
On a deux fichiers dans le dossier :

bandit17@melissa:~$ ls -l
total 8
-rw-r----- 1 bandit18 bandit17 3300 2012-05-30 14:15 passwords.new
-rw-r----- 1 bandit18 bandit17 3300 2012-05-30 14:15 passwords.old

Le mot de passe est la seule ligne qui a changé entre les deux fichiers. Les hints de bas de page ne nous seront pas très utiles ici, on va régler ça avec la commande "diff" :

bandit17@melissa:~$ diff passwords.new passwords.old 
42c42
< kfBf3eYk5BPBRzwjqutbbfE887SVc5Yd
---
> bECYSoXjOeGseirUCztuCBDF3xXqE7By

Et notre gagnant est kfBf3eYk5BPBRzwjqutbbfE887SVc5Yd


Niveau 19 :
Ce niveau là aussi n'est pas bien compliqué. Lorsqu'on se loggue en tant que bandit18, on est (quasi) immédiatement déconnecté. L'énoncé du challenge nous explique qu'il y a une instruction dans le .bashrc qui nous déconnecte (en fait c'est juste un exit :))

Ici encore, rien de bien sorcier pour venir à bout de ce challenge, on va essayer de voir si on peut passer l'exécution d'une commande à ssh, si on a de la chance, son exécution se déroulera avant l'interprétation du .bashrc :

meik@athena:~$ ssh bandit18@bandit.labs.overthewire.org cat readme


This is the OverTheWire game server. More information on http://www.overthewire.org/wargames


Please note that wargame usernames are no longer level, but wargamename
e.g. vortex4, semtex2, krypton1, bandit13, ...


Note: at this moment, blacksun and drifter are not available.


bandit18@bandit.labs.overthewire.org's password: 
IueksS7Ubh8G3DCwVzrTd8rAVOwq3M5x
meik@athena:~$ 


Niveau 20 :
Encore un niveau pas bien complexe histoire de nous initier aux joies du setuid qui sont très utiles dans certains des quelques niveaux restants. On nous explique qu'il y a un programme dans notre dossier home qui nous permettra d'obtenir un accès au niveau suivant :

bandit19@melissa:~$ ls -l
total 8
-rwsr-x--- 1 bandit20 bandit19 7165 2012-05-30 14:16 bandit20-do

On voit en effet qu'il dispose du petit "flag" 's'. Dans la pratique qu'est ce que ça veut dire ? Ca veut dire que ce programme, lorsqu'il s'exécutera, disposera des privilèges de son propriétaire. Ici le propriétaire est "bandit20", donc lorsqu'on exécutera une commande, notre "euid" (effective UID) sera bandit20, alors que nous sommes loggué en tant que "bandit19".

Ici, le programme prend en paramètre une commande à exécuter :

bandit19@melissa:~$ ./bandit20-do 
Run a command as another user.
  Example: ./bandit20-do id

Essayons :

bandit19@melissa:~$ ./bandit20-do id
uid=11019(bandit19) gid=11019(bandit19) euid=11020(bandit20) groups=11020(bandit20),11019(bandit19)

Ca confirme ce qui a été dit plus haut donc. On a bien un euid de bandit20. Ce qui nous sera fort utile pour lire le fichier contenant le mot de passe du niveau suivant :

bandit19@melissa:~$ ls -l /etc/bandit_pass/bandit20 
-r-------- 1 bandit20 bandit20 33 2012-05-30 14:16 /etc/bandit_pass/bandit20

Ici, seul l'utilisateur "bandit20" a le droit de lecture ('r') sur ce fichier contenant le mot de passe. Si on utilise la commande "cat" avec notre petit programme suid, la commande "cat" sera exécutée avec les privilèges de l'utilisateur bandit20 et on pourra donc lire le fichier :

bandit19@melissa:~$ ./bandit20-do cat /etc/bandit_pass/bandit20 
GbKksEFF4yrVs6il55v6gwY5aVje5f0j


Niveau 20 :
Cette fois, on est à nouveau mis en présence d'un fichier setuid. Voyons comment il réagit lorsqu'on le lance sans paramètres :

bandit20@melissa:~$ ./suconnect
Usage: ./suconnect
This program will connect to the given port on localhost using TCP. If it receives the correct password from the other side, the next password is transmitted back.

Ok donc ce programme va se connecter sur un port TCP local qu'on lui passe en paramètre. S'il *reçoit* le bon mot de passe (on déduit que c'est notre mot de passe actuel), il nous envoie le mot de passe permettant d'accéder au niveau suivant (bandit21).

On va donc ouvrir un port sur la machine à l'aide de netcat :

bandit20@melissa:~$ nc -l 6666

Comme indiqué dans les notes du niveau, on va ouvrir un autre terminal, se connecter sur la machine via ssh et effectuer le reste de la manipulation depuis ce terminal, à savoir lancer le "suconnect" :

bandit20@melissa:~$ ./suconnect 6666

De retour dans notre premier terminal, on va envoyer le mot de passe

bandit20@melissa:~$ nc -l 6666
GbKksEFF4yrVs6il55v6gwY5aVje5f0j
gE269g2h3mw3pwgrj0Ha9Uoqen1c9DGr


Niveau 22 :
Pour ce niveau, on nous indique qu'une tache périodique cron se lance régulièrement. On regarde donc dans /etc/cron.d/ comme suggéré dans les indications, et on voit plusieurs fichiers, dont un cronjob_bandit22, dont on se doute que c'est celui qui nous intéresse vu le nom.

On jete un oeil dedans :

bandit21@melissa:~$ cat /etc/cron.d/cronjob_bandit22
* * * * * bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null

C'est donc une tache qui se lance toutes les minutes, qui lance le script /usr/bin/cronjob_bandit22.sh. Regardons le contenu de ce script :

bandit21@melissa:~$ cat /usr/bin/cronjob_bandit22.sh
#!/bin/bash
chmod 644 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv

Ce script donne les droits 644 à un fichier dans /tmp et copie le contenu du fichier /etc/bandit_pass/bandit22 dedans (le mot de passe qui nous intéresse donc). Regardons le contenu de ce fichier :

bandit21@melissa:~$ cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
Yk7owGAcWjwMVRwrTesJEwB7WVOiILLI


Niveau 23 :
Ce niveau est également très simple. On nous suggère là encore de regarder dans /etc/cron.d, et on y trouve cronjob_bandit23 :

* * * * * bandit23 /usr/bin/cronjob_bandit23.sh &> /dev/null

Là encore, un script qui s'exécute toutes les minutes, en tant que l'utilisateur "bandit23" :

#!/bin/bash
myname=$(whoami)
mytarget=$(echo I am user $myname | md5sum | cut -d ' ' -f 1)
echo "Copying passwordfile /etc/bandit_pass/$myname to /tmp/$mytarget"

Ce script récupère le nom de l'utilisateur qui lance le script (dans la tache cron, ça sera bandit23), génère une chaine de caractères avec ce nom, calcule son hash md5 et récupère ce dernier, qui sera le nom d'un fichier dans /tmp/ qui contient le mot de passe qui nous intéresse. On va donc exécuter les mêmes commandes, en remplaçant "myname" par "bandit23", sinon le traitement s'appliquera à l'utilisateur "bandit22" et ça ne marchera pas :

bandit22@melissa:~$ echo I am user bandit23 | md5sum | cut -d ' ' -f 1
8ca319486bfbbc3663ea0fbe81326349
bandit22@melissa:~$ cat /tmp/8ca319486bfbbc3663ea0fbe81326349
jc1udXuA1tiHqjIsL8yaapX5XIAI6i0n


Niveau 24 :
La encore, on regarde dans /etc/cron.d, on trouve encore une tache cron, qui se lance en tant que bandit24 et qui exécute le script suivant :

bandit23@melissa:~$ cat /usr/bin/cronjob_bandit24.sh
#!/bin/bash
myname=$(whoami)
cd /var/spool/$myname
echo "Executing and deleting all scripts in /var/spool/$myname:"
for i in *;
do
    echo "Handling $i"
    ./$i
    rm -f $i
done

Ce script exécute tous les scripts présents dans le dossier /var/spool/bandit24 (vu que la tache cron s'exécute en tant que bandit24) et les supprime. On va donc créer un simple script shell qui copie le contenu de /etc/bandit_pass/bandit24 vers un fichier dans /tmp et donner les droits d'exécution à ce script :

bandit23@melissa:/var/spool/bandit24$ echo "cat /etc/bandit_pass/bandit24 > /tmp/abcde ; chmod 644 /tmp/kikoolol" > gna ; chmod 755 gna

On attend quelques secondes le temps que la tache cron s'exécute...

bandit23@melissa:/var/spool/bandit24$ cat /tmp/abcde
UoMYTrfrBFHyQXmg6gzctqAwOmw1IohZ

A ce stade là, on a fini le challenge : "At this moment, level 25 does not exist yet."