---
# System prepended metadata

title: SLO 2021 Exploitation

---

# SLO 2021 Exploitation


Auteurs : Christian Gomes, Johann Werkle

## Buffer overflow - Niveau 1

Le binaire concerné par ce challenge est le `chall1` , le port de connexion est le `10001`.

### Question 3.1

***Quelle fonction fait référence à la fonction win et comment s’y prend-elle ?*** 

On note que la fonction `win` est referencé dans la fonction `login`. 

***Que fait cette fonction avec la référence à win ? Dans quelles conditions, la fonction win sera-t-elle exécutée ?***


Il y a une génération de bytes aléatoires qui va être comparée avec le mot de passe entré par l'utilisateur. Si ceux-ci correspondent, la fonction retournera la référence à la fonction win, dans le cas échéant, c'est la fonction `fail` qui sera retournée. 

***Au final, quelle fonction fait vraiment l’appel à win ?***

La fonction `login` est appelée dans le main, et c'est donc à cet endroit-là que la fonction sera appelée. 


### Question 3.2

***Quelle vulnérabilité pourrait nous permettre d’assurer l’appel à la fonction win ?***

Il faudrait utiliser un buffer overflow afin d'avoir le contrôle sur la fonction qui sera retournée par login. Cela permettrait de détourner le flux d'éxécution.


### Question 3.3

***Dessiner la stack frame de la fonction qui fait référence à win.***


| StackFrame function win |  |  |
| --------    | -------- | -------- |
| fonctionReturn       | ...     | ...     |
| passwordGenerate       | ...     | ...     |
| passwordEnter       | ...     | ...     |
| isValid       | ...     | ...     |
| Saved EBP       | ...     | ...     |
| Saved EIP        | ...     | ...     |


### Question 3.4

***Quel est le flag obtenu ?***

Le flag obtenu est : `5ay5x7N2AohfNH8pTGgD`


## Buffer overflow - Niveau 2

Le binaire concerné par ce challenge est le `chall2` , le port de connexion est le `10002`.

### Question 4.1

***En quoi ces protections empêchent-elles une attaque de type stack smashing ?***

Cette protection va empecher le stack smashing, en détectant si une modification a eu lieu dans la stack frame. 



### Question 4.2

***Dessiner la stackframe de la fonction securelogin.***

| StackFrame function securelogin | ...  | ...  |
| ------------------------------- | ---- | ---- |
| iVar1 (return authentication)   | ...  | ...  |
| puVar2 (initializer)            | ...  | ...  |
| in_GS_OFFSET (GS_Offset)        | ...  | ...  |
| local_400 (password)            | ...  | ...  |
| local_208 (username)            | ...  | ...  |
| local_14 (canaryValue)          | ...  | ...  |
| local_10 (offset)               | ...  | ...  |
| Saved EBP                       | ...  | ...  |
| Saved EPI                       | ...  | ...  |


### Question 4.3

***Dans ce cas, que veut-on remplacer par l’adresse de la fonction win ? Quelle vulnérabilité permet de le faire ?***

On veut remplacer la valeur de retour de la fonction `secure_login` par l'adresse de la fonction `win`

La vulnérabilité qui permet de le faire est un buffer overflow

### Question 4.4

***Quelle autre valeur que l’adresse de la fonction win doit-on connaitre afin d’effectuer l’attaque ? Quelle(s) vulnérabilité(s) permet(tent) d’obtenir cette valeur sans besoin d’avoir recours à un debugger?***

La taille des tableaux username et password ainsi que la valeur du canary.

On peut obtenir ces informations avec un buffer overread qui nous les fournira.

### Question 4.5

***Si vous n’avez pas anticipé sur cette question, vous ne devriez pas avoir réussi à obtenir votre flag ? Pourquoi ?***

On arrive pas à obtenir le flag car la valeur du canari change constamment à chaque éxecution du programme. Il faudra donc anticiper dans le script d'attaque de récuperer cette valeur à chaque attaque. 

### Question 4.6

***Quel est le flag obtenu ?***

Le flag obtenu est : `MoF9dadIPSsggRSoc0Yc`


## Format strings - Niveau 1

Le binaire concerné par ce challenge est le `chall3` , le port de connexion est le `10003`.

Compilé avec : `gcc -Wno-format-security -no-pie -fno-PIC -m32 -O0`

### Question 5.1

***Dans quelle partie de la mémoire se trouve le pointeur sur function?***

On a remarqué que le pointeur sur `function` était dans une variable statique. Il est donc dans la partie BSS de la mémoire. 

***Dans quelle fonction ce pointeur est-il initialisé ? Avec quelle valeur ?*** 

On observe dans le main que celui-ci est initialié avec l'adresse de la fonction fail.

***Déduisez-en ce qu’il vous faut faire pour atteindre votre objectif (exécuter win).*** 

On peut déduire qu'il va falloir mettre l'adresse de win et non celle de fail dans le pointeur `function`



### Question 5.2

***Quelle vulnérabilité voyez-vous pour vous permettre d’atteindre votre objectif ? Où se trouve-t-elle dans le code ? Que va-t-elle vous permettre de faire pour atteindre votre objetcif ?*** 

### Question 5.3

***Est-ce que l’ASLR est activé en remote ?*** 
Oui, lors de chaque exécution, on voit que les valeurs changent.

### Question 5.4

***Que doit-on faire précisément (description de la construction du payload) pour exécuter la fonction win ?***

(Méthode en partie trouvée sur https://secgroup.dais.unive.it/teaching/security-course/format-strings/)
En premier lieu, il faut trouver l'offset de la faille qu'on peut obtenir par un print d'une valeur connue suivie d'un nombre variable de '%08x. 

Une fois l'offset en main, on peut completer le payload en y insérant l'adresse de la variable statique trouvée, l'adresse du byte qui suit et `%<x1>x + %<y1>$hhn + %<x2>x + %<y2>$hh` avec x<n> correspondant au nombre de bytes à ajouter à la valeur y<n> pour obtenir le byte de l'adresse de `win`.


### Question 5.4bis
***Quel est le flag obtenu ?***

Le flag obtenu est : `hi2gqyjg0PZjFnfD4e7`

### Question 5.5

***Est-ce que le fait d’avoir ou pas l’ASLR change l’attaque ? Pourquoi ?***

Non, l'adresse de la BSS n'est pas générée aléatoirement, contrairement à l'adresse de la pile. Les variables statiques conservent donc leur adresse (tout comme l'adresse du pointeur sur `function`).

## Format strings - Niveau 2

Le binaire concerné par ce challenge est le `chall4` , le port de connexion est le `10004`.

Le code source concerné : `chall4.c`

Compilé avec : `gcc -Wno-format-security -no-pie -fno-PIC -m32 -O0`

### Question 6.1

***Est-ce que l’ASLR est activé en remote ?***

Oui, lors de chaque exécution, on voit que les valeurs changent.

### Question 6.2

***Listez toutes les vulnérabilités du binaire. Comment peut-on les corriger ?***

En observant le code source fini, et les différents vues en cours, on note rapidement quelques éléments vulnérables tels que le format string avec le code `printf(something)`. Il faudrait dans cas indiqué un format tel que `printf("%s", something)` pour corriger ce problème.

Le deuxième problème subsite au niveau de la fonction `scanf` avec un BUFFER_SIZE comme taille d'entrée qui est la même que celle des tableaux declarées. Dans le cas, d'une entrée de taille maximum, il risque 


### Question 6.3

***Comment pouvez-vous récupérer l’adresse du pointeur sur function en remote ?***

Selon le même principe que le challenge précédent, il est nécessaire d'évaluer la position du pointeur sur la fonction `functino`. 

Un fois la position trouvée,  on effectue une attaque format string en read sur le username et ensuite une attaque format string en write sur le password afin de modifier l'adresse du pointeur vers la fonction win.

### Question 6.4

***Quel est le flag obtenu ?***

Le flag obtenu est : `KaOe5Vd1nWdiaUYzzoo7`

## Conculsion

C'était super! Mais compliqué. Mais super!

## Annexe

Code python chall 1-4

