mardi 27 novembre 2012

NSA CryptoChallenge

La NSA recrute à fond en ce moment [1]. Pour attirer des tonnes de gens pouvant l'aider dans ses tâches habituelles, ils ont mis en ligne un jeu sur iPhone et Android dont le but est de "casser" le chiffrement de messages secrets (en l'occurence, il s'agit par exemple de citations d'hommes politiques célèbres ou de banalités sur la cuisine du monde).



Le chiffrement en lui même est assez simpliste, il s'agit d'un chiffrement par substitution monoalphabétique pouvant être "cassé" par une bête analyse de la fréquence d'apparition des lettres et un peu de logique (je pense qu'un grand nombre d'écoliers ont déjà communiqué avec leurs potes en cours en mettant au point un truc comme ça)
Vu que sur iTunes on nous que cette application est "Developped by the National Security Agency", on s'attend à avoir une application ultra protégée. En réalité, pas du tout. En se balladant dans le dossier de l'application sur un iPhone jailbreaké, on peut tomber là dessus :

MeiK:/var/mobile/Applications/1EA019DB-BBD6-4414-81C2-CFF692C3D07B/Documents/PuzzlePacks root# ls -l
total 48
-rw-r--r-- 1 mobile mobile 12970 Nov 26 15:28 CCPPFamousQuotes.xml
-rw-r--r-- 1 mobile mobile  6771 Mar 23  2012 CCPPGreenFacts.xml
-rw-r--r-- 1 mobile mobile  6948 Nov 26 14:35 CCPPPopCulture.xml
-rw-r--r-- 1 mobile mobile  5510 Mar 23  2012 CCPPStemTrivia.xml
-rw-r--r-- 1 mobile mobile  5696 Nov 26 14:39 CCPPWorldCulture.xml
MeiK:/var/mobile/Applications/1EA019DB-BBD6-4414-81C2-CFF692C3D07B/Documents/PuzzlePacks root#

Dans chaque fichier XML, on va retrouver en clair les citations. Dans l'exemple montré en début de post, on voit que c'est la quote #18 de la catégorie "World Culture & Cuisine", du coup on va chercher la 18e quote du fichier "CCPPWorldCulture.xml" qui est "Some airlines won't allow transport of canned Swedish surstromming (fermented Baltic herring) because cans have been known to explode."...



De la triche quoi.

[1] C'est pas les seuls :-)

lundi 1 octobre 2012

Test du casque Parrot Zik

Après quelques semaines d'utilisation du casque "Zik" de chez Parrot, je me suis dit que ça pourrait peut-être valoir le coup d'écrire une petite review sur ce blog.

Présentation du produit
Le Zik est présenté comme un casque audio sans-fil haut de gamme (au même titre que des casques de référence comme le Bose QC 15 par exemple) en raison de ses fonctionnalités (très nombreuses) mais aussi de son prix (349 euros au lancement).

Fonctionnalités
Le casque présente un très grand nombre de caractéristiques et de fonctionnalités :
- sans-fil (bluetooth et fonctionne via le protocole A2DP)
- annulation active du bruit via de multiples capteurs
- parrot concert hall (permet de simuler un effet concert donnant l'impression que le son vient de devant)
- equalizer embarqué dans le casque
- appairage via NFC
- contrôles via un pavé tactile (volume, pause, morceau suivant/précédent)

Test
J'ai toujours eu besoin, quel que soit mon casque, d'activer un equalizer afin de corriger un éventuel biais introduit par la qualité du casque (et à peu près tous les casques en ont un j'ai l'impression). Typiquement je me contente d'un equalizer "rock" qui rend un son à peu près potable, surtout sur du mp3 à la qualité variable (on pourrait aussi s'enliser dans un troll à ce sujet, mais on va s'en passer). Toujours est-il que dans le Zik, sans activer d'equalizer, j'ai à peu de choses près le son que j'attends d'un morceau de musique donné. Je ne suis pas non plus un puriste extrême, de toutes façons, quand on écoute (entre autres) du black metal enregistré dans un garage, plus ça sature, mieux c'est. J'ai pu constater une baisse de la qualité audio en fonction de l'usage ou pas du cable jack. Avec mon dongle bluetooth un peu pourri payé 13 euros en grande surface, l'écoute en A2DP dans un endroit silencieux s'est révélée assez douloureuse pour les oreilles. Une écoute depuis un iPhone en A2DP semble déjà plus écoutable. Avec le cable jack fourni, j'ai pu entendre certaines subtilités dans certains morceaux de musique (au point d'arriver à entendre la respiration de musiciens de l'orchestre dans une interprétation des Quatre Saisons de Vivaldi !)

Le casque se configure via une application iPhone ou Android, gratuite, qui communique via bluetooth. Elle permet l'activation/désactivation de l'ANC, du Parrot Concert Hall et de l'equalizer, puis aussi d'effectuer la mise à jour du firmware, changer le nom du device qui apparaîtra dans un scan bluetooth ainsi que vérifier l'état de la batterie.

Au niveau de l'isolation active du bruit (ANC), c'est tout à fait correct et conforme à ce que j'attendais. Lors de mon premier contact avec l'outil, dans une grande chaîne de magasins qui vend "de la culture" (en boîte) et qui vend également ce casque, je n'entendais plus la musique d'ambiance du magasin, ni le brouhaha des gens qui se demandaient s'ils devaient acheter le MacBook exposé 2m plus loin ou un 4x4 (au même prix (presque)). Il n'y avait pas de musique dans le casque, juste l'annulation du bruit. J'entendais par contre, tout doucement, un vendeur juste à côté qui essayait de refourguer un produit à un hypothétique futur client.

Après l'achat, et depuis bientôt 3 semaines, je l'utilise entre autres dans les transports en commun. On entend la musique, et rien que la musique. Sauf certains cas exceptionnels où on peut distinguer l'horrible grincement des roues du matériel de la RATP en raison de son grand âge (j'exagère, le matériel a tout juste 40 ans sur ces lignes là, il en a pour encore une dizaine d'années). Un test dans un bar parisien il y a quelques jours s'est également révélé concluant.
En comparaison avec mon précédent casque à isolation du bruit, le Zik est nettement plus efficace.

Je ne vais pas spécialement m'étendre sur le "Parrot Concert Hall". En gros ça donne un semblant d'impression que le son provient de devant nous (suivant un angle et une distance qui se règlent (salle silencieuse, salon, club de jazz et salle de concert)). C'est marrant 5 minutes sur certains styles de musique (exemple du blues), mais ce n'est clairement pas une fonction particulièrement utile (elle est désactivée chez moi).

L'equalizer embarqué dans le casque peut également avoir son utilité. Plusieurs presets sont disponibles (punchy (qui est très proche du preset "rock" que l'on rencontre ailleurs), crystal, etc). Il est également possible de faire son propre réglage ("Utilisateur1"). D'après une info rencontrée sur le forum Parrot, dans une mise à jour à venir il sera possible d'enregistrer plusieurs réglages personnalisés (contre un seul à l'heure actuelle). Ensuite, la qualité du rendu du casque, de base, étant convenable, il m'arrive de désactiver l'equalizer. A ce niveau là, ça dépendra du goût de la personne qui écoute (mais il est inconcevable d'écouter certains morceaux sans booster les basses parfois).

D'ailleurs puisqu'on parle de mises à jour, lorsque l'on branche le casque sur le port USB d'un PC (c'est ainsi que se charge la batterie de l'engin, mais j'y reviendrai plus tard), un périphérique mass storage de 10mo apparaît. C'est dans celui-ci que l'on dépose un fichier "PLF" (un format proprio de Parrot) qui permettra d'effectuer la mise à jour du firmware du casque lorsque lorsque l'on ne dispose pas d'un iPhone ou d'un téléphone sous Android. Une fois reversé, le fichier PLF contient plusieurs "sections" dont peuvent être extraits un certain nombre de fichiers, dont un kernel (qui semble être "ECOS") ainsi qu'un rootfs. D'ailleurs c'est blindé de sqlite tout ça, ce qui est assez déroutant (de se dire qu'on a du sqlite en marche autour de la tête). Voilà, ça c'était pour la minute reverse engineering du post (pas très poussé je le reconnais).

Je n'ai pas testé l'appairage via NFC, ne disposant pas d'un téléphone compatible, mais il semblerait que ça soit pour simplifier l'étape extrèmement compliquée d'appairage bluetooth qui consiste juste à choisir le device dans la liste d'équipements bluetooth détectés à portée et sans avoir de PIN à saisir (de toutes façons c'est 0000).

Les contrôles du casque quant à eux se font via un petit pavé tactile sur l'écouteur droit. Une tape simple pour mettre en pause/reprendre la musique ou un appel, pour monter ou baisser le volume il suffit de faire glisser son doigt vers le haut ou vers le bas, et vers l'avant ou l'arrière pour passer au morceau suivant ou précédent. Il existe aussi des combinaisons pour gérer le double appel, mais n'utilisant absolument jamais cette fonction, je n'ai pas la moindre idée du fonctionnement (mais vous saurez qu'elle est prise en compte par le casque). Bon du coup ça donne la possibilité à n'importe qui de faire un DoS sur nos oreilles en venant tripatouiller l'écouteur après avoir spoofé notre identité (mouahah).

Le tout est assez massif, mais je n'ai ressenti aucune gêne après de longues heures d'utilisation. De toutes façons, en mode A2DP + ANC, le casque ne tient pas plus de 5 à 6 heures (je n'ai pas encore eu trop l'occasion de tester juste l'ANC en mode connecté via prise jack afin de voir l'autonomie). Certains se plaindront que 5-6 heures ne suffisent pas pour leur trajet en avion, mais le "mode avion" du téléphone désactivera le bluetooth de  toutes façons, donc ils devront brancher leur casque à la prise jack, et l'autonomie sera peut-être plus longue (à tester du coup).

Défauts
Je déconseille formellement l'écoute de musique avec le cable jack lorsque le casque est en charge (en USB) sur un PC. Il doit y avoir une masse flottante ou un truc dans ce genre là qui fait qu'on entend de gros bruits parasites. Il aurait peut-être été amusant que le casque, lorsque branché en USB, soit reconnu comme un périphérique audio (comme les cartes son sur port USB quoi) par l'ordinateur, afin de ne pas avoir à brancher de cable jack, mais ça n'est malheureusement pas le cas.

Une fonctionnalité est décrite dans le manuel, mais n'est pas implémentée : le lancement de la reconnaissance vocale du téléphone (genre SIRI pour ceux qui ont un iPhone 4S) lors d'un toucher "long" (2s) sur le pavé tactile du casque. Ca permettrait de ne pas avoir à sortir son téléphone lorsque l'on s'en sert pour passer des appels, pour saisir le numéro ou le dicter. La fonction est décrite dans le manuel, ils ont probablement eu un peu de retard pour la sortie du casque et n'ont pas implémenté ça, donc ça viendra sûrement plus tard (après tout, lors de la sortie du casque, il n'y avait pas d'application mobile disponible).

Le casque n'est également pas fourni avec un adaptateur pour avion 2x mono vers 1x stereo.

Un autre truc qui manque cruellement, c'est une application permettant de contrôler le Zik en bluetooth depuis un PC sous Windows, MacOS X ou encore Linux, ou du moins, une API permettant de développer une telle application. Car supposons un instant que j'écoute de la musique en A2DP depuis mon PC (bon, la qualité, dans ce cas là, est vraiment atroce en raison de limitations propres à l'A2DP, mais imaginons) et que je veuille changer un paramètre (le parrot concert hall, ou l'équalizer), eh bien je ne peux pas sans déconnecter le Zik du PC, l'associer au téléphone, faire le réglage, déconnecter du téléphone et réassocier au PC. Assez pénible comme manipulation. Alors certes, ce n'est pas le genre de manip qu'on fait tout le temps, mais le contrôle du niveau de batterie du casque, vu son autonomie, oui. Il doit être possible, après un peu de reverse engineering et de sniffing du protocole de communication en bluetooth de déterminer quelles sont les instructions envoyées au casque.
Puis on aimerait bien (du moins, c'est mon cas), avoir la possibilité de modifier le PIN bluetooth du casque.

D'ailleurs, le jonglage avec différents équipements associés au casque s'avère assez pénible (par exemple passer du téléphone à la tablette). Mais je suppose que sur ce point là, c'est un peu le cas de chaque équipement de ce style. L'utilisateur lambda utilise probablement son casque avec un unique téléphone, et non pas la panoplie complète du technophile.

Il y a quelques petits bugs de temps à autres, mais sur ce point, les développeurs de chez Parrot sortent des mises à jour de temps en temps (je suis passé par tous les firmwares en 3 semaines). Seul un bug semble résister (mises en pause intempestives sans qu'aucune commande n'ait été initiée). Un correctif serait à l'étude, il paraït, mais ce bug reste rare (3 fois en 3 semaines).

Le plus gros défaut, et là c'est assez scandaleux, c'est l'autonomie du casque. Entre 5 et 6 heures en mode equalizer + ANC. Je vois pas trop quoi ajouter à ça. Dans mon cas actuel ça ne me dérange pas spécialement, j'ai toujours une prise USB à proximité pour recharger le casque, mais ce n'est pas forcément le cas de tous les autres utilisateurs. Certains souhaiteraient pouvoir acheter des batteries supplémentaires, mais personnellement je ne me vois pas me trimballer un set de batteries dans mes poches ou mon sac. Heureusement qu'on a la possibilité de continuer l'écoute de la musique sans batterie.

Conclusion
Après 2-3 semaines d'utilisation (j'allais quand même pas écrire cette review après 2h d'utilisation quand même), je trouve ce casque plus que correct. J'ai été agréablement surpris par la qualité du son (encore que vu mes casques précédents, ça ne pouvait pas être pire) et par les fonctionnalités qui en font un casque relativement unique dans sa catégorie (il n'y a pas, à ma connaissance, de casque concurrent présentant les mêmes fonctionnalités, même si ce que l'on attend d'un casque c'est qu'il restitue de la musique de manière correcte, ce que fait parfaitement le Zik). Il a malheureusement quelques défauts "de jeunesse", mais qui peuvent, en théorie et pour la plupart, être corrigés par une mise à jour du firmware

Je pense avoir à peu près tout dit, mais si certains points demandent un éclaircissement, la section commentaires est encore accessible !

dimanche 15 juillet 2012

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."


lundi 20 février 2012

Retour au moyen-âge

La règlementation en matière de crypto est assez variable selon les pays du monde. La littérature à ce sujet est assez facilement trouvable (encore qu'il faille faire le tri et organiser ce qu'on trouve, par date, dans la mesure où ça a fortement évolué ces 15 dernières années). C'est le cas Français qui m'a surpris dernièrement.
Il y a encore quelques années, la crypto était assez limitée en France (un outil comme SSH était interdit, il fallait utiliser une version french-law-compliant, SSF, et on a retrouvé des vestiges de cette période jusqu'en 2008). Fort heureusement, depuis 2004 on peut utiliser une grande partie des outils existants sans avoir à se perdre en démarches administratives, comme le montre ce tableau récapitulatif (tronqué, pour ne garder que ce qui nous intéresse ici) trouvé sur le site de l'ANSSI :


















Maintenant, pourquoi avoir entouré de rouge la partie relative à la gestion et la configuration des systèmes d'information ? D'après ma compréhension du français, il s'agit là d'outils type SSH, qui sont amenés à utiliser la cryptographie pour des raisons que tout le monde connait. Et c'est de ce genre d'outils dont il va être question maintenant.
Il existe encore des endroits où on peut trouver des programmes basés sur SSH, non téléchargeables en France. Un exemple est sur l'AppWorld de BlackBerry. Le programme "Telnet SSH", qui est un vulgaire clone de PuTTY, n'est pas téléchargeable par nous Français :













Après avoir contacté le développeur de l'application pour savoir si la restriction était voulue ou non, j'ai eu droit à une réponse qui m'a ramené aux âges sombres de l'Internet Multimédia Interactif :
"I believe it should be allowed to use worldwide.
But that's the restriction of AppWorld. As soon as you choose that your application contains any security related algorithms/features, France is automatically excluded."
Grosso merdo, dès qu'on soumet une application BlackBerry qui utilise de la crypto, les usagers français sont automatiquement exclus et ne peuvent pas télécharger l'application. Ce qui en soi est un peu con dans la mesure où les BlackBerries usent et abusent de cryptographie pour sécuriser les échanges (ils en font même un argument de vente hein). De là à imaginer que, quelque part, tapi dans le code de l'OS de RIM, une fonction "IsEncryptionPermitted()" nous attend, il n'y a qu'un pas que je suis bien tenté de franchir (mais je ne le ferai pas ce soir, promis).
Mais que les utilisateurs français aient l'impossibilité de télécharger un clone de PuTTY en 2012 me semble assez édifiant. Je me demande si les gens de chez RIM sont au courant que depuis au moins 1999 on a le droit d'utiliser SSH en France. Je n'ai pas trouvé de contact chez RIM pour leur poser directement la question (vu leurs difficultés actuelles, ce n'est peut-être pas leur priorité). L'autre possibilité est que je me sois complètement fourvoyé et qu'en réalité SSH soit interdit dans notre beau pays, mais ça me semble assez peu probable.
Je précise que cette application est faite pour la tablette BlackBerry PlayBook. Sur les téléphones BlackBerry, l'application "BBSSH" est très bien (du moins juste pour se connecter et faire de l'IRC over SSH, on ne peut pas faire de tunnel ou de forwarding).

mercredi 25 janvier 2012