> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/fr/useful-resources/exploit-development/linux-buffer-overflow-custom.md).
# Buffer overflow Linux - personnalisé
Notes personnalisées de buffer overflow Linux pour construire des exploits, contrôler le flux d’exécution, élaborer des payloads et documenter la méthodologie de corruption mémoire.
## Premier exemple de binaire personnalisé (Pdmenu/exim) :
Téléchargez la machine arracher
> Le premier exemple se concentre sur l'exploitation du binaire légitime exim-4.84-7, qui présente une vulnérabilité identifiée comme CVE-2016-1531. Cette vulnérabilité permet à un attaquant d'exécuter des commandes avec des privilèges en abusant de certaines variables d'environnement.
* Dans ce cas, lorsque nous accédons à l'utilisateur Paul, un **Pdmenu** lui est attribué avec certaines fonctionnalités (liste des répertoires, édition de fichiers, lancement de ping, etc.) :
* Pour quitter ce menu, nous **éditons un fichier**, par exemple (etc/host) :
* Dans ce cas, **vi** est utilisé comme éditeur de texte :
* En regardant **gtfobins**, si nous filtrons par vi, nous obtenons les commandes pour quitter Pdmenu et **exécuter un shell**:
* Nous filtrons **SUID** les fichiers et en trouvons un appelé exim :
* Avec l' **searchsploit** outil, nous recherchons les vulnérabilités possibles pour ce binaire :
* Téléchargez maintenant le script et servez-le avec **python3** afin qu'il puisse être chargé une fois la machine compromise :
* Nous exécutons le script et, en effet, la vulnérabilité de ce binaire est exploitée, nous obtenons ainsi **l'accès root**:
## Deuxième exemple (débordement de tampon) :
Téléchargez laUbuntumachineInstallez l'outilPeda
> Le deuxième exemple concerne un **débordement de tampon** dans un binaire personnalisé [binaire](https://hack4u.io/wp-content/uploads/2023/04/custom) sur une machine Linux 32 bits avec protections actives et ASLR activé. Dans ce cas, nous nous concentrons sur l'exploitation de ret2libc dans un binaire doté de permissions SUID et appartenant à root. Grâce au débordement de tampon, nous montrons comment injecter des commandes privilégiées et élever les privilèges de l'utilisateur.
\***débordement de tampon** consiste à écraser certains registres système, et puisque le binaire est créé par l'utilisateur et appartient au groupe root, **il s'exécutera avec les privilèges d'un utilisateur privilégié**:
* Le binaire appelé "custom" attend une **entrée de chaîne de caractères** et lorsqu'il est exécuté, rien ne se passe :
* Mais si nous entrons une **chaîne très longue**, il renvoie une erreur (core dumped) :
Nous envoyons une **chaîne courte** de AAAAAAAA et aucune **erreur n'apparaît**:
* Pour analyser le binaire en profondeur, nous utiliserons l'outil **gdb-peda** .
* Mais si nous envoyons **beaucoup de caractères**, nous obtenons l'erreur suivante :
1. La première chose à faire est de **déterminer le nombre total de chaînes** nécessaires pour écraser le registre (EIP).
* La première méthode consiste à utiliser un **motif (pattern)** qui crée une chaîne **spécialement conçue** (dans ces cas, 300 caractères) que nous exécutons dans le binaire :
* Dans la réponse de **EIP**, nous savons que la **chaîne inférieure visible** est "AA8A" :
* Le **automatique** mode de l'outil se fait avec le `offset du pattern $eip` commande :
* Pour vérifier cela, nous utilisons **python3** en envoyant 112 caractères A puis 4 B finaux :
```bash
r $(python3 -c 'print("A"*112 + "B"*4)')
```
* En effet, nous confirmons maintenant la fin grâce à **EIP** qui détecte les 4 derniers B :
2. Une fois que nous connaissons le nombre maximal de chaînes, nous **vérifions l'ASLR** qui déterminera s'il y a **de l'aléa dans les adresses mémoire** ou non :
/- Avec la commande suivante, nous filtrons les chaînes qui nous intéressent spécifiquement pour exécuter le binaire 10 fois afin de voir s'il change à chaque fois et de voir si la **bibliothèque C** est aléatoire ou non :
C'est bien "aléatoire"
3. Le problème avec ces **32 bits** binaires est souvent que si nous exécutons par exemple maintenant **1000 fois** A et que nous filtrons par une chaîne fixe, nous voyons qu'à chaque fois, **il se répétera au moins une fois**:
4. L'objectif maintenant est d'abord de trouver **EIP** des chaînes (**system + exit + bin/\_sh**), qui seront toujours fixes et nécessaires pour exécuter un **Bash en tant que root** comme dans l'exemple suivant mais en Python :
* Nous créons un **point d'arrêt** afin que le flux du programme s'arrête à cet endroit :
* Nous injectons le **EIP** de (system/exit/bin/\_sh) :
5. Une fois que nous voyons qu'il y a **de l'aléatoire**, nous devrons utiliser **force brute** jusqu'à ce que le **base/\_libc/\_addr** soit égal à la valeur souhaitée :
/- Avec ce qui suit, nous verrons les **bibliothèques en cours d'exécution** (dans ce cas **libc.so**):
* Avec **readelf**, nos filtres pour la bibliothèque et la recherche des variables injectées plus tôt, qui sont (**exit et system**) avec les codes :
* Et pour trouver la chaîne **/bin/sh**, nous procédons comme suit, en ajoutant un **0x00** au début :
Le script Python3 suivant va **automatiser toute la force brute** jusqu'à ce que **base/\_libc/\_addr** soit identique :
```python
#!/usr/bin/python3
import subprocess
from struct import pack
import sys
offset = 112
before_eip = b"A" * 112
# Débordement de tampon Linux personnalisé
base_libc_addr = 0xb7595000
system_addr_off = 0xb7d86db0
exit_addr_off = 0xb7d7a9e0
bin_sh_addr_off = 0xb7ea7b2b
system_addr = pack("
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hacking-notes.jord4n.pro/fr/useful-resources/exploit-development/linux-buffer-overflow-custom.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
