Escape

upload file suid openssl snmp

  • Nom machine : Escape

  • Difficulté : Difficile

  • OS : Linux

Enumération

NMAP

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-13 04:37 EDT
Nmap scan report for 192.168.229.113
Host is up (0.035s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 f0:85:61:65:d3:88:ad:49:6b:38:f4:ac:5b:90:4f:2d (RSA)
|   256 05:80:90:92:ff:9e:d6:0e:2f:70:37:6d:86:76:db:05 (ECDSA)
|_  256 c3:57:35:b9:8a:a5:c0:f8:b1:b2:e9:73:09:ad:c7:9a (ED25519)
80/tcp   open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Escape
8080/tcp open  http    Apache httpd 2.4.38 ((Debian))
|_http-title: Escape
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: Apache/2.4.38 (Debian)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-13 04:57 EDT
Nmap scan report for 192.168.229.113
Host is up (0.033s latency).
Not shown: 999 closed udp ports (port-unreach)
PORT    STATE SERVICE
161/udp open  snmp

HTTP (80)

HTTP (8080)

Même image que précédemment

Dev ?

Le chemin dev/uploads peut possiblement être intéressant. Nous allons tester d'upload un fichier malveillant sur le serveur. sur la page, on nous indique que seul les gifs sont acceptés.

Accès initial

Nous testons un fichier gif pour voir si il est bien uploadé... et non ! Nous avons testé plusieurs choses avec Burp Suite:

  • Intruder - tester un grand nombre d'extension --> sans résultat

  • Changer manuellement le magic number --> sans résultat

  • Jouer avec le Content-type --> sans résultat Jusqu'ici rien de surprenant, le site ne nous mène pas vers une fausse piste et il demande bien un fichier .gif

Nous allons voir le code source de la page.

Intéressant.... On supprime tout le contenu de notre gif sur Burp et on retente l'upload

"Uploaded"

Nous allons tester le chemin /uploads

Bingo ! Maintenant nous allons essayer d'upload un shell. Si nous changeons uniquement l'extension, le fichier peut toujours être upload. On ajoute donc notre code php en plein milieu de la requête en renomons le fichier : shell.php

Nous touchons au but.

La commande whoami nous indique bien www-data. Nous essayons which nc et n'avons pas de réponse, which bash indique /bin/bash, pas de réponse pour which python (problématique pour upgrade le shell)

On génère un reverse shell avec https://www.revshells.com/ en lançons un listeneur... Sans résultat. Nous allons tenter autrement, on va directement uploader php-pentest-monkey, de la même manière que le shell précédent. Et cela fonctionne !

Elévation des privilèges

Nous lançons un serveur python sur le port 8888 de notre machine kali et exécutons linpeas.

Rien qui ne saute véritablement aux yeux... Cependant certains fichier peuvent sembler intéressants, en se rappelant l'énumération initiale.

Deux informations importantes :

  • Nous avons le mot de passe : 53cur3M0NiT0riNg

  • Un fichier est exécuté : /tmp/shtest

Nous allons y placer un reverse-shell

Nous allons le télécharger dans le dossier /tmp de notre machine cible.

Nous avons bien échappé à Docker ! Maintenant nous devons devenir root

Un binaire est inhabituel : /usr/bin/logconsole Nous allons l'exécuter pour voir ce qu'il fait.

Ok, il permet d'exécuter des commandes. Nous allons voir si on ne peut pas remplacer l'une de ses commandes par un shell. Si le binaire appele par un chemin absolu, nous ne pourrons pas le remplacer (sauf si chemin ouvert en écriture pour nous). Nous n'avons pas la commande string sur la cible, nous allons donc récupérer le binaire sur notre machine. Téléchargeons nc sur la cible, avec un serveur python puis

La plupart des commandes utilisent leur chemin absolu. Ce n'est pas le cas de lscpu.

Choisir le 6

On relance linpeas... /opt/cert/openssl =ep is writable

Nous sommes root !

Mis à jour