diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a0c0a0bb7..9200053c6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -81,6 +81,7 @@ - [Basic Python](generic-methodologies-and-resources/python/basic-python.md) - [Threat Modeling](generic-methodologies-and-resources/threat-modeling.md) - [Blockchain & Crypto](blockchain/blockchain-and-crypto-currencies/README.md) + - [Defi/AMM Hook Precision](blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md) - [Lua Sandbox Escape](generic-methodologies-and-resources/lua/bypass-lua-sandboxes/README.md) # 🧙‍♂️ Generic Hacking @@ -769,7 +770,7 @@ - [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md) - [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md) - [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.md) -- [ROP & JOP](binary-exploitation/rop-return-oriented-programing/README.md) + - [ROP and JOP](binary-exploitation/rop-return-oriented-programing/README.md) - [BROP - Blind Return Oriented Programming](binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md) - [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md) - [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md) @@ -846,7 +847,6 @@ - [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md) - [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md) - # 🤖 AI - [AI Security](AI/README.md) - [Ai Assisted Fuzzing And Vulnerability Discovery](AI/AI-Assisted-Fuzzing-and-Vulnerability-Discovery.md) @@ -895,7 +895,6 @@ - [RC4 - Encrypt\&Decrypt](crypto-and-stego/rc4-encrypt-and-decrypt.md) - [Stego Tricks](crypto-and-stego/stego-tricks.md) - [Esoteric languages](crypto-and-stego/esoteric-languages.md) -- [Blockchain & Crypto Currencies](crypto-and-stego/blockchain-and-crypto-currencies.md) # ✍️ TODO diff --git a/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md b/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md index 650c9960e..bef577a91 100644 --- a/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md +++ b/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md @@ -3,11 +3,11 @@ {{#include ../../banners/hacktricks-training.md}} -## Bag +## Ranljivost -You have a [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), ali ukratko: +Postoji [odlično objašnjenje ranjivosti ovde](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), ali ukratko: -Svaka Mach poruka koju kernel primi završava se sa **"trailer"**: struktura promenljive dužine sa metadata (seqno, sender token, audit token, context, access control data, labels...). Kernel **uvek rezerviše najveći mogući trailer** (MAX_TRAILER_SIZE) u baferu poruke, ali **inicijalizuje samo neka polja**, i kasnije **odlučuje koja veličina trailera će biti vraćena** na osnovu **opcija za prijem koje kontroliše korisnik**. +Svaka Mach poruka koju kernel primi završava se sa **"trailer"**: struktura promenljive dužine sa metapodacima (seqno, sender token, audit token, context, access control data, labels...). Kernel **uvek rezerviše najveću moguću veličinu trailera** (MAX_TRAILER_SIZE) u message buffer-u, ali **inicijalizuje samo neka polja**, i kasnije **odlučuje koju veličinu trailera da vrati** na osnovu **opcija prijema koje kontroliše korisnik**. Ovo su relevantne strukture trailera: ```c @@ -31,7 +31,7 @@ msg_labels_t msgh_labels; typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t; #define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t)) ``` -Zatim, kada se trailer object generiše, samo su neka polja inicijalizovana, a max trailer size je uvek rezervisana: +Zatim, kada se generiše trailer objekat, samo su neka polja inicijalizovana, i maksimalna veličina trailera je uvek rezervisana: ```c trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size); trailer->msgh_sender = current_thread()->task->sec_token; @@ -41,7 +41,7 @@ trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE; [...] trailer->msgh_labels.sender = 0; ``` -Na primer, kada se pokuša pročitati mach poruku koristeći `mach_msg()`, poziva se funkcija `ipc_kmsg_add_trailer()` da bi se trailer pripojio poruci. Unutar ove funkcije izračunava se veličina trailera i popunjavaju neka druga polja trailera: +Zatim, na primer, prilikom pokušaja čitanja mach poruke koristeći `mach_msg()` poziva se funkcija `ipc_kmsg_add_trailer()` da doda trailer u poruku. Unutar ove funkcije izračunava se veličina trailera i popunjavaju se neka druga polja trailera: ```c if (!(option & MACH_RCV_TRAILER_MASK)) { [3] return trailer->msgh_trailer_size; @@ -51,9 +51,9 @@ trailer->msgh_seqno = seqno; trailer->msgh_context = context; trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option); ``` -Parametar `option` je pod kontrolom korisnika, pa je **potrebno proslediti vrednost koja prolazi `if` proveru.** +Parametar `option` je kontrolisan od strane korisnika, pa je **potrebno proslediti vrednost koja prođe `if` proveru.** -Da bismo prošli ovu proveru, moramo poslati važeći podržani `option`: +Da bismo prošli ovu proveru, moramo poslati validan podržan `option`: ```c #define MACH_RCV_TRAILER_NULL 0 #define MACH_RCV_TRAILER_SEQNO 1 @@ -67,9 +67,9 @@ Da bismo prošli ovu proveru, moramo poslati važeći podržani `option`: #define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24) #define MACH_RCV_TRAILER_MASK ((0xf << 24)) ``` -Ali, pošto `MACH_RCV_TRAILER_MASK` samo proverava bits, možemo proslediti bilo koju vrednost između `0` i `8` da ne uđemo u `if` statement. +Međutim, pošto `MACH_RCV_TRAILER_MASK` samo proverava bitove, možemo proslediti bilo koju vrednost između `0` i `8` da ne uđemo unutar `if` iskaza. -Zatim, nastavljajući sa kodom možete naći: +Zatim, nastavljajući kroz kod, možete pronaći: ```c if (GET_RCV_ELEMENTS(option) >= MACH_RCV_TRAILER_AV) { trailer->msgh_ad = 0; @@ -92,11 +92,11 @@ ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread)); return trailer->msgh_trailer_size; ``` -Ovde možete videti da, ako je `option` veći ili jednak `MACH_RCV_TRAILER_AV` (7), polje **`msgh_ad`** biva inicijalizovano na `0`. +Kao što možeš videti, ako je `option` veće ili jednako `MACH_RCV_TRAILER_AV` (7), polje **`msgh_ad`** se inicijalizuje na `0`. -Ako ste primetili, **`msgh_ad`** je i dalje bilo jedino polje trailer-a koje prethodno nije bilo inicijalizovano i koje je moglo sadržati leak iz ranije korišćene memorije. +Ako si primetio, **`msgh_ad`** je i dalje bilo jedino polje trailer-a koje ranije nije bilo inicijalizovano i koje je moglo sadržati leak iz prethodno korišćene memorije. -Dakle, način da se izbegne njegovo inicijalizovanje je da se prosledi `option` vrednost `5` ili `6`, tako da prođe prvi `if` i ne uđe u `if` koji inicijalizuje `msgh_ad`, jer vrednosti `5` i `6` nemaju nikakav tip trailer-a povezan. +Dakle, način da se izbegne njegova inicijalizacija je da se prosledi vrednost `option` `5` ili `6`, tako da prođe prvi `if` i ne uđe u `if` koji inicijalizuje `msgh_ad`, zato što vrednosti `5` i `6` nemaju pridružen nijedan trailer tip. ### Basic PoC @@ -104,9 +104,9 @@ Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-h ### Leak Kernel Address PoC -Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to leak a kernel address. For this, a message full of `mach_msg_port_descriptor_t` structs is sent in the message cause the field `name` of this structure in userland contains an unsigned int but in kernel the `name` field is a struct `ipc_port` pointer in kernel. Thefore, sending tens of these structs in the message in kernel will mean to **dodaju nekoliko kernel adresa unutar poruke** tako da jedna od njih može biti leaked. +Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to leak a kernel address. For this, a message full of `mach_msg_port_descriptor_t` structs is sent in the message cause the field `name` of this structure in userland contains an unsigned int but in kernel the `name` field is a struct `ipc_port` pointer in kernel. Thefore, sending tens of these structs in the message in kernel will mean to **add several kernel addresses inside the message** so one of them can be leaked. -Dodani su komentari radi boljeg razumevanja: +Komentari su dodati za bolje razumevanje: ```c #include #include @@ -324,9 +324,9 @@ printf("[+] Port %x has address %lX\n", sent_port, sent_port_address); return 0; } ``` -## Izvori +## Reference -- [Post na blogu Synacktiv-a](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}} diff --git a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md index c9b5e916c..79c2f2e67 100644 --- a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md +++ b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md @@ -5,23 +5,22 @@ ## iOS Exploit Mitigations -- **Code Signing** u iOS funkcioniše tako što svaki izvršni kod (apps, libraries, extensions, itd.) mora biti kriptografski potpisan sertifikatom koji izdaje Apple. Kada se kod učitava, iOS proverava digitalni potpis protiv Apple-ovog root sertifikata. Ako je potpis nevažeći, nedostaje ili je izmenjen, OS odbija da ga pokrene. Ovo onemogućava napadačima da ubace maliciozni kod u legitimne aplikacije ili pokreću unsigned binarije, efikasno zaustavljajući većinu exploit lanaca koji zavise od izvršavanja proizvoljnog ili izmenjenog koda. -- **CoreTrust** je iOS subsistem odgovoran za provođenje provere potpisivanja koda u runtime-u. On direktno verifikuje potpise koristeći Apple-ov root sertifikat bez oslanjanja na keširane trust store-ove, što znači da samo binariji potpisani od strane Apple-a (ili sa važećim entitlements) mogu da se izvršavaju. CoreTrust osigurava da čak i ako napadač izmeni aplikaciju nakon instalacije, modifikuje sistemske biblioteke ili pokuša da učita unsigned kod, sistem će blokirati izvršavanje osim ako je kod i dalje pravilno potpisan. Ova stroga primena zatvara mnoge post-exploitation vektore koje su starije iOS verzije dozvoljavale kroz slabije ili zaobilažive provere potpisa. -- **Data Execution Prevention (DEP)** označava regije memorije kao neizvršne osim ako eksplicitno ne sadrže kod. To sprečava napadače da ubacuju shellcode u data regione (kao što su stack ili heap) i da ga pokreću, prisiljavajući ih da se oslone na složenije tehnike kao što je ROP (Return-Oriented Programming). -- **ASLR (Address Space Layout Randomization)** nasumično raspoređuje adrese memorije za kod, biblioteke, stack i heap pri svakom pokretanju sistema. To otežava napadačima da predvide gde se nalaze korisne instrukcije ili gadgets, narušavajući mnoge exploit lance koji zavise od fiksnih rasporeda memorije. -- **KASLR (Kernel ASLR)** primenjuje isti koncept randomizacije na iOS kernel. Mešanjem kernel base adrese pri svakom boot-u, sprečava napadače da pouzdano lociraju kernel funkcije ili strukture, povećavajući težinu kernel-level exploita koji bi inače omogućili potpunu kontrolu nad sistemom. -- **Kernel Patch Protection (KPP)**, takođe poznat kao **AMCC (Apple Mobile File Integrity)** u iOS-u, kontinuirano nadgleda kernel-ove code page-ove da bi osigurao da nisu modifikovani. Ako se otkrije bilo kakvo mešanje—npr. pokušaj exploita da patch-uje kernel funkcije ili ubaci maliciozni kod—uređaj će odmah panic-ovati i restartovati se. Ova zaštita otežava postojane kernel exploite, jer napadači ne mogu jednostavno hook-ovati ili patch-ovati kernel instrukcije bez izazivanja sistemskog pada. -- **Kernel Text Readonly Region (KTRR)** je hardverska bezbednosna funkcija uvedena na iOS uređajima. Koristi memorijski kontroler CPU-a da označi kernel-ovu code (text) sekciju kao trajno read-only nakon boot-a. Jednom zaključana, čak ni kernel ne može menjati tu memorijsku regiju. Ovo sprečava napadače—i čak privilegovani kod—from da patch-uju kernel instrukcije u runtime-u, zatvarajući veliku klasu exploita koji su se oslanjali na direktnu modifikaciju kernel koda. -- **Pointer Authentication Codes (PAC)** koriste kriptografske potpise ugrađene u neiskorišćene bitove pokazivača da bi verifikovali njihov integritet pre upotrebe. Kada se pokazivač (npr. return address ili function pointer) kreira, CPU ga potpisuje tajnim ključem; pre dereferenciranja, CPU proverava potpis. Ako je pokazivač izmenjen, provera ne uspeva i izvršavanje prestaje. Ovo sprečava napadače da falsifikuju ili ponovo koriste korumpirane pokazivače u mem-korupciji, otežavajući tehnike poput ROP ili JOP. -- **Privilege Access Never (PAN)** je hardverska funkcija koja sprečava kernel (privileged mode) da direktno pristupi user-space memoriji osim ako eksplicitno ne omogući pristup. Ovo zaustavlja napadače koji su stekli kernel code execution da lako čitaju ili pišu user memoriju radi eskalacije privilegija ili krađe osetljivih podataka. Stroga separacija smanjuje uticaj kernel exploita i blokira mnoge uobičajene tehnike eskalacije privilegija. -- **Page Protection Layer (PPL)** je iOS bezbednosni mehanizam koji štiti kritične memorijske regione koje kernel upravlja, naročito one povezane sa code signing-om i entitlements. On primenjuje stroge write protection koristeći MMU (Memory Management Unit) i dodatne provere, osiguravajući da čak ni privilegovani kernel kod ne može proizvoljno menjati osetljive stranice. Ovo sprečava napadače koji dobiju kernel-level izvršavanje da mešaju strukture važne za bezbednost, čineći persisteniciju i zaobilaženje code-signing-a znatno težim. - +- **Code Signing** in iOS radi tako što zahteva da svaki komad izvršnog koda (apps, libraries, extensions, itd.) bude kriptografski potpisan sertifikatom izdatim od Apple-a. Kada se kod učitava, iOS proverava digitalni potpis naspram Apple-ovog poverljivog root-a. Ako je potpis nevažeći, nedostaje ili je izmenjen, OS odbija da ga pokrene. Ovo sprečava napadače da ubacuju maliciozni kod u legitimne aplikacije ili da pokreću unsigned binare, efikasno zaustavljajući većinu exploit lanaca koji zavise od izvršavanja proizvoljnog ili izmenjenog koda. +- **CoreTrust** je iOS pod-sistem odgovoran za sprovođenje code signing-a u runtime-u. Direktno verifikuje potpise koristeći Apple-ov root sertifikat bez oslanjanja na keširane trust store-ove, što znači da samo binari potpisani od Apple-a (ili sa validnim entitlements) mogu da se izvršavaju. CoreTrust osigurava da čak i ako napadač izmeni aplikaciju posle instalacije, modifikuje sistemske biblioteke ili pokuša da učita unsigned kod, sistem će blokirati izvršavanje osim ako je kod i dalje ispravno potpisan. Ovo strogo sprovođenje zatvara mnoge post-exploitation vektore koje su starije verzije iOS-a dopuštale kroz slabije ili zaobilažljive provere potpisa. +- **Data Execution Prevention (DEP)** označava regiona memorije kao non-executable osim ako eksplicitno ne sadrže kod. To sprečava napadače da ubace shellcode u data regione (poput stack-a ili heap-a) i pokrenu ga, terajući ih da koriste kompleksnije tehnike kao što su ROP (Return-Oriented Programming). +- **ASLR (Address Space Layout Randomization)** nasumično raspoređuje adrese memorije za kod, biblioteke, stack i heap pri svakom pokretanju sistema. To otežava napadačima da predvide gde se nalaze korisne instrukcije ili gadget-i, rušeći mnoge exploit lance koji zavise od fiksnih layout-a memorije. +- **KASLR (Kernel ASLR)** primenjuje isti koncept randomizacije na iOS kernel. Mešanjem kernel base adrese pri svakom boot-u, sprečava napadače da pouzdano lociraju kernel funkcije ili strukture, povećavajući težinu kernel-level exploit-a koji bi inače dobili potpunu kontrolu nad sistemom. +- **Kernel Patch Protection (KPP)** takođe poznat kao **AMCC (Apple Mobile File Integrity)** u iOS-u, kontinuirano nadgleda code pages kernela da bi osigurao da nisu modifikovane. Ako se detektuje bilo kakvo diranje—kao kad exploit pokuša da patch-uje kernel funkcije ili ubaci maliciozni kod—uređaj će odmah panic-ovati i reboot-ovati. Ova zaštita otežava persistentne kernel exploit-e, jer napadači ne mogu jednostavno da hook-uju ili patch-uju kernel instrukcije bez izazivanja sistemskog crash-a. +- **Kernel Text Readonly Region (KTRR)** je hardverski bazirana sigurnosna funkcija uvedena na iOS uređajima. Koristi CPU-ov memory controller da označi kernel-ov code (text) segment kao trajno read-only nakon boot-a. Jednom zaključan, čak ni kernel sam ne može modifikovati ovaj region memorije. To sprečava napadače—i čak privilegovani kod—from patch-ovanja kernel instrukcija u runtime-u, zatvarajući veliki klas exploits koji su zavisili od direktne izmene kernel koda. +- **Pointer Authentication Codes (PAC)** koriste kriptografske potpise ugrađene u neiskorišćene bitove pokazivača da provere njihov integritet pre upotrebe. Kada se pointer (kao return address ili function pointer) kreira, CPU ga potpisuje sa tajnim ključem; pre dereferenciranja, CPU proverava potpis. Ako je pointer izmenjen, provera ne uspeva i izvršavanje se zaustavlja. Ovo sprečava napadače da falsifikuju ili ponovo koriste korumpirane pointer-e u memory corruption exploit-ima, čineći tehnike poput ROP ili JOP mnogo težim za pouzdano izvođenje. +- **Privilege Access never (PAN)** je hardverska karakteristika koja sprečava kernel (privileged mode) da direktno pristupa user-space memoriji osim ako eksplicitno ne omogući pristup. Ovo onemogućava napadače koji su dobili kernel code execution da jednostavno čitaju ili pišu user memoriju radi eskalacije ili krađe osetljivih podataka. Postrojavajući strogu separaciju, PAN smanjuje uticaj kernel exploit-a i blokira mnoge uobičajene privilege-escalation tehnike. +- **Page Protection Layer (PPL)** je iOS sigurnosni mehanizam koji štiti kritične kernel-managed memorijske regione, posebno one vezane za code signing i entitlements. Primjenjuje stroge write zaštite koristeći MMU (Memory Management Unit) i dodatne provere, osiguravajući da čak ni privilegovani kernel kod ne može proizvoljno menjati osetljive stranice. Ovo sprečava napadače koji dobiju kernel-level execution da diraju sigurnosno-kritične strukture, značajno otežavajući postizanje persistence-a i bypass-ovanje code-signinga. ## 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) -### Upravljanje memorijom u XNU +### Memory management in XNU The **virtual memory address space** for user processes on iOS spans from **0x0 to 0x8000000000**. However, these addresses don’t directly map to physical memory. Instead, the **kernel** uses **page tables** to translate virtual addresses into actual **physical addresses**. @@ -128,7 +127,7 @@ io_connect_t id = result.surface_id; } } ``` -Pretražite objekte **`IOSurface`** u jednoj oslobođenoj fizičkoj stranici: +Potražite **`IOSurface`** objekte u jednoj oslobođenoj fizičkoj stranici: ```c int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) { io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000); @@ -162,24 +161,24 @@ free(surfaceIDs); return 0; } ``` -### Postizanje čitanja/brisanja u kernelu pomoću IOSurface +### Postizanje Kernel read/write pristupa sa IOSurface -Nakon što dobijemo kontrolu nad IOSurface objektom u kernel memoriji (mapiranom na oslobođenu fizičku stranicu dostupnu iz userspace), možemo ga iskoristiti za **arbitrarne operacije čitanja i pisanja u kernelu**. +Nakon što ostvarimo kontrolu nad IOSurface objektom u kernel memoriji (mapiranom na oslobođenu fizičku stranicu dostupnu iz userspace), možemo ga iskoristiti za **proizvoljne kernel read i write operacije**. **Ključna polja u IOSurface** -IOSurface objekat ima dva ključna polja: +Objekat IOSurface ima dva bitna polja: 1. **Use Count Pointer**: Omogućava **32-bit read**. 2. **Indexed Timestamp Pointer**: Omogućava **64-bit write**. -Prepisivanjem ovih pokazivača preusmeravamo ih na proizvoljne adrese u kernel memoriji, čime omogućavamo mogućnosti čitanja/pisanja. +Prepisivanjem ovih pokazivača preusmeravamo ih na proizvoljne adrese u kernel memoriji, omogućavajući read/write mogućnosti. #### 32-Bit Kernel Read -Da biste izvršili čitanje: +Za izvođenje čitanja: -1. Prepišite **use count pointer** da pokazuje na ciljnu adresu umanjenu za offset od 0x14 bajta. +1. Prepišite **use count pointer** tako da pokazuje na ciljnu adresu umanjenu za offset od 0x14 bajta. 2. Upotrebite `get_use_count` metodu da pročitate vrednost na toj adresi. ```c uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) { @@ -203,7 +202,7 @@ return value; Da biste izvršili upis: 1. Prepišite **indexed timestamp pointer** na ciljnu adresu. -2. Iskoristite metodu `set_indexed_timestamp` da upišete 64-bit vrednost. +2. Koristite `set_indexed_timestamp` metodu da upišete 64-bitnu vrednost. ```c void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) { uint64_t args[3] = {surfaceID, 0, value}; @@ -217,13 +216,13 @@ set_indexed_timestamp(info.client, info.surface, value); iosurface_set_indexed_timestamp_pointer(info.object, orig); } ``` -#### Exploit Flow Recap +#### Rekapitulacija toka exploita -1. **Trigger Physical Use-After-Free**: Slobodne stranice su dostupne za ponovnu upotrebu. -2. **Spray IOSurface Objects**: Alociraj mnogo IOSurface objekata sa jedinstvenom "magic value" u kernel memory. -3. **Identify Accessible IOSurface**: Lociraj IOSurface na oslobođenoj stranici koju kontroliš. -4. **Abuse Use-After-Free**: Izmeni pokazivače u IOSurface objektu kako bi omogućio proizvoljno **kernel read/write** preko IOSurface metoda. +1. **Okini Physical Use-After-Free**: Slobodne stranice su dostupne za ponovno korišćenje. +2. **Spray IOSurface Objects**: Alociraj mnogo IOSurface objekata sa jedinstvenom "magic value" u kernel memoriji. +3. **Identify Accessible IOSurface**: Pronađi IOSurface na oslobođenoj stranici koju kontrolišeš. +4. **Abuse Use-After-Free**: Izmeni pokazivače u IOSurface objektu kako bi omogućio proizvoljno **kernel read/write** putem IOSurface metoda. -Sa ovim primitivima, exploit obezbeđuje kontrolisane **32-bit reads** i **64-bit writes** u kernel memory. Dalji koraci za jailbreak mogli bi uključivati stabilnije read/write primitive, koje mogu zahtevati zaobilaženje dodatnih zaštita (npr. PPL na novijim arm64e uređajima). +Uz ove primitive, exploit obezbeđuje kontrolisane **32-bit reads** i **64-bit writes** u kernel memoriju. Dalji koraci jailbreak-a mogu zahtevati stabilnije read/write primitive, koje mogu zahtevati zaobilaženje dodatnih zaštita (npr. PPL na novijim arm64e uređajima). {{#include ../../banners/hacktricks-training.md}} diff --git a/src/blockchain/blockchain-and-crypto-currencies/README.md b/src/blockchain/blockchain-and-crypto-currencies/README.md index 56c792059..c2253075a 100644 --- a/src/blockchain/blockchain-and-crypto-currencies/README.md +++ b/src/blockchain/blockchain-and-crypto-currencies/README.md @@ -1,176 +1,178 @@ +# Blockchain i kriptovalute + {{#include ../../banners/hacktricks-training.md}} -## Osnovni Koncepti +## Osnovni pojmovi -- **Pametni ugovori** definišu se kao programi koji se izvršavaju na blockchain-u kada su ispunjeni određeni uslovi, automatizujući izvršenja sporazuma bez posrednika. -- **Decentralizovane aplikacije (dApps)** se oslanjaju na pametne ugovore, imajući korisnički prijatan front-end i transparentan, auditable back-end. -- **Tokeni i Kovanice** se razlikuju, pri čemu kovanice služe kao digitalni novac, dok tokeni predstavljaju vrednost ili vlasništvo u specifičnim kontekstima. -- **Utility tokeni** omogućavaju pristup uslugama, a **Security tokeni** označavaju vlasništvo nad imovinom. -- **DeFi** označava decentralizovane finansije, nudeći finansijske usluge bez centralnih vlasti. -- **DEX** i **DAO** se odnose na decentralizovane berzanske platforme i decentralizovane autonomne organizacije, redom. +- **Smart Contracts** su definisani kao programi koji se izvršavaju na blockchain-u kada su ispunjeni određeni uslovi, automatizujući izvršavanje sporazuma bez posrednika. +- **Decentralizovane aplikacije (dApps)** nadograđuju se na smart contracts, imajući korisnički prihvatljiv front-end i transparentan, auditabilan back-end. +- **Tokeni & Coinsi** razlikuju se tako što coinsi služe kao digitalni novac, dok tokeni predstavljaju vrednost ili vlasništvo u specifičnim kontekstima. +- **Utility Tokens** daju pristup uslugama, a **Security Tokens** označavaju vlasništvo nad imovinom. +- **DeFi** označava Decentralizovane finansije, koje nude finansijske usluge bez centralnih autoriteta. +- **DEX** i **DAOs** odnose se na Decentralizovane berze i Decentralizovane autonomne organizacije. -## Mehanizmi Konsenzusa +## Mehanizmi konsenzusa -Mehanizmi konsenzusa osiguravaju sigurne i dogovorene validacije transakcija na blockchain-u: +Mehanizmi konsenzusa obezbeđuju sigurnu i dogovorenu validaciju transakcija na blockchain-u: -- **Proof of Work (PoW)** se oslanja na računarsku snagu za verifikaciju transakcija. -- **Proof of Stake (PoS)** zahteva od validatora da drže određenu količinu tokena, smanjujući potrošnju energije u poređenju sa PoW. +- **Proof of Work (PoW)** oslanja se na računarsku snagu za verifikaciju transakcija. +- **Proof of Stake (PoS)** zahteva od validatora da drže određenu količinu tokena, smanjujući potrošnju energije u odnosu na PoW. -## Osnovne Informacije o Bitcoinu +## Osnove Bitcoina ### Transakcije -Bitcoin transakcije uključuju prebacivanje sredstava između adresa. Transakcije se validiraju putem digitalnih potpisa, osiguravajući da samo vlasnik privatnog ključa može inicirati transfere. +Bitcoin transakcije uključuju prenos sredstava između adresa. Transakcije se validiraju digitalnim potpisima, što osigurava da samo vlasnik privatnog ključa može inicirati transfer. -#### Ključne Komponente: +#### Ključne komponente: -- **Multisignature transakcije** zahtevaju više potpisa za autorizaciju transakcije. -- Transakcije se sastoje od **ulaza** (izvor sredstava), **izlaza** (odredište), **naknada** (plaćene rudarima) i **skripti** (pravila transakcije). +- **Multisignature Transactions** zahtevaju više potpisa za autorizaciju transakcije. +- Transakcije se sastoje od **inputs** (izvor sredstava), **outputs** (odredište), **fees** (plaćeni rudarima) i **scripts** (pravila transakcije). ### Lightning Network -Cilj je poboljšati skalabilnost Bitcoina omogućavanjem više transakcija unutar kanala, samo emitovanjem konačnog stanja na blockchain. +Cilj mu je poboljšanje skalabilnosti Bitcoina omogućavajući više transakcija unutar kanala, pri čemu se samo konačno stanje objavljuje na blockchain-u. -## Problemi Privatnosti Bitcoina +## Problemi privatnosti Bitcoina -Napadi na privatnost, kao što su **Common Input Ownership** i **UTXO Change Address Detection**, koriste obrasce transakcija. Strategije poput **Mixers** i **CoinJoin** poboljšavaju anonimnost zamagljujući veze transakcija između korisnika. +Napadi na privatnost, kao što su **Common Input Ownership** i **UTXO Change Address Detection**, iskorišćavaju obrasce u transakcijama. Strategije kao što su **Mixers** i **CoinJoin** poboljšavaju anonimnost time što zamagljuju veze transakcija između korisnika. -## Sticanje Bitcoina Anonimno +## Anonimno sticanje Bitcoina -Metode uključuju gotovinske trgovine, rudarenje i korišćenje miksera. **CoinJoin** meša više transakcija kako bi otežao praćenje, dok **PayJoin** prikriva CoinJoins kao obične transakcije radi povećane privatnosti. +Metode uključuju trgovinu za keš, mining i korišćenje mixera. **CoinJoin** meša više transakcija kako bi otežao praćenje, dok **PayJoin** prikriva CoinJoin kao obične transakcije za veću privatnost. -# Napadi na Privatnost Bitcoina +# Bitcoin Privacy Atacks -# Sažetak Napada na Privatnost Bitcoina +# Sažetak napada na privatnost Bitcoina -U svetu Bitcoina, privatnost transakcija i anonimnost korisnika često su predmet zabrinutosti. Evo pojednostavljenog pregleda nekoliko uobičajenih metoda kroz koje napadači mogu kompromitovati privatnost Bitcoina. +U svetu Bitcoina, privatnost transakcija i anonimnost korisnika često su predmet brige. Evo pojednostavljenog pregleda nekoliko uobičajenih metoda kojima napadači mogu ugroziti privatnost Bitcoina. -## **Pretpostavka Zajedničkog Vlasništva Ulaza** +## **Common Input Ownership Assumption** -Generalno je retko da se ulazi različitih korisnika kombinuju u jednoj transakciji zbog složenosti koja je uključena. Tako se **dve adrese ulaza u istoj transakciji često pretpostavljaju da pripadaju istom vlasniku**. +Generalno je retko da se inputi različitih korisnika kombinuju u jednoj transakciji zbog složenosti koja je u tome uključena. Zato se **dve input adrese u istoj transakciji često pretpostavljaju da pripadaju istom vlasniku**. -## **UTXO Adresa Promene Detekcija** +## **UTXO Change Address Detection** -UTXO, ili **Unspent Transaction Output**, mora biti potpuno potrošen u transakciji. Ako se samo deo pošalje na drugu adresu, ostatak ide na novu adresu promene. Posmatrači mogu pretpostaviti da ova nova adresa pripada pošiljaocu, kompromitujući privatnost. +UTXO, odnosno **Unspent Transaction Output**, mora biti u potpunosti potrošen u transakciji. Ako se samo deo šalje na drugu adresu, ostatak ide na novu change address. Posmatrači mogu pretpostaviti da ta nova adresa pripada pošiljaocu, čime se narušava privatnost. ### Primer -Da bi se to ublažilo, usluge mešanja ili korišćenje više adresa mogu pomoći u zamagljivanju vlasništva. +Da bi se to ublažilo, mixing servisi ili korišćenje više adresa mogu pomoći da se zamagli vlasništvo. -## **Izloženost Društvenih Mreža i Foruma** +## **Izlaganje preko društvenih mreža i foruma** Korisnici ponekad dele svoje Bitcoin adrese online, što olakšava **povezivanje adrese sa njenim vlasnikom**. -## **Analiza Transakcionih Grafova** +## **Analiza grafova transakcija** Transakcije se mogu vizualizovati kao grafovi, otkrivajući potencijalne veze između korisnika na osnovu toka sredstava. -## **Heuristika Nepotrebnog Ulaza (Optimalna Heuristika Promene)** +## **Unnecessary Input Heuristic (Optimal Change Heuristic)** -Ova heuristika se zasniva na analizi transakcija sa više ulaza i izlaza kako bi se pogodilo koji izlaz je promena koja se vraća pošiljaocu. +Ova heuristika se zasniva na analizi transakcija sa više inputa i outputa kako bi se pogodilo koji output predstavlja change koji se vraća pošiljaocu. ### Primer ```bash 2 btc --> 4 btc 3 btc 1 btc ``` -Ako dodavanje više ulaza čini da promena izlaza bude veća od bilo kog pojedinačnog ulaza, to može zbuniti heuristiku. +Ako dodavanje više inputa učini da change output bude veći od bilo kojeg pojedinačnog inputa, to može zbuniti heuristiku. -## **Prisilna Ponovna Upotreba Adresa** +## **Forced Address Reuse** -Napadači mogu slati male iznose na prethodno korišćene adrese, nadajući se da će primalac kombinovati ove sa drugim ulazima u budućim transakcijama, čime se povezuju adrese. +Napadači mogu poslati male iznose na prethodno korišćene adrese, nadajući se da će primalac u budućim transakcijama kombinovati te iznose sa drugim inputima, čime bi adrese bile povezane. -### Ispravno Ponašanje Novčanika +### Correct Wallet Behavior -Novčanici bi trebali izbegavati korišćenje kovanica primljenih na već korišćenim, praznim adresama kako bi sprečili ovaj gubitak privatnosti. +Novčanici bi trebalo da izbegavaju korišćenje coina primljenih na već korišćene, prazne adrese kako bi sprečili ovaj privacy leak. -## **Druge Tehnike Analize Blokčejna** +## **Other Blockchain Analysis Techniques** -- **Tačni Iznosi Plaćanja:** Transakcije bez promene su verovatno između dve adrese koje poseduje isti korisnik. -- **Celi Brojevi:** Celi broj u transakciji sugeriše da je to plaćanje, pri čemu je ne-celi izlaz verovatno promena. -- **Otisak Novčanika:** Različiti novčanici imaju jedinstvene obrasce kreiranja transakcija, što omogućava analitičarima da identifikuju korišćen softver i potencijalno adresu promene. -- **Korelacije Iznosa i Vremena:** Otkriće vremena ili iznosa transakcija može učiniti transakcije tragovima. +- **Exact Payment Amounts:** Transakcije bez change-a verovatno su između dve adrese koje pripadaju istom korisniku. +- **Round Numbers:** Zaokružen broj u transakciji ukazuje na to da je reč o uplati, dok je ne-zaokruženi output verovatno change. +- **Wallet Fingerprinting:** Različiti novčanici imaju jedinstvene obrasce kreiranja transakcija, što analitičarima omogućava da identifikuju korišćeni softver i potencijalno change address. +- **Amount & Timing Correlations:** Otkrivanje vremena ili iznosa transakcija može učiniti transakcije sledljivim. -## **Analiza Saobraćaja** +## **Traffic Analysis** -Praćenjem mrežnog saobraćaja, napadači mogu potencijalno povezati transakcije ili blokove sa IP adresama, ugrožavajući privatnost korisnika. Ovo je posebno tačno ako entitet upravlja mnogim Bitcoin čvorovima, što poboljšava njihovu sposobnost praćenja transakcija. +Praćenjem mrežnog saobraćaja, napadači potencijalno mogu povezati transakcije ili blokove sa IP adresama, ugrožavajući privatnost korisnika. Ovo je naročito tačno ako neka organizacija upravlja velikim brojem Bitcoin nodova, čime povećava svoju sposobnost nadgledanja transakcija. -## Više +## More Za sveobuhvatan spisak napada na privatnost i odbrana, posetite [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy). # Anonimne Bitcoin Transakcije -## Načini za Sticanje Bitcoina Anonimno +## Načini za anonimno dobijanje Bitcoina -- **Transakcije Gotovinom**: Sticanje bitcoina putem gotovine. -- **Alternativne Gotovine**: Kupovina poklon kartica i njihova razmena online za bitcoin. -- **Rudarenje**: Najprivatnija metoda za zarađivanje bitcoina je kroz rudarenje, posebno kada se radi samostalno, jer rudarske grupe mogu znati IP adresu rudara. [Informacije o Rudarskim Grupama](https://en.bitcoin.it/wiki/Pooled_mining) -- **Krađa**: Teoretski, krađa bitcoina bi mogla biti još jedan način za njegovo anonimno sticanje, iako je to ilegalno i nije preporučljivo. +- **Cash Transactions**: Nabavka bitcoina gotovinom. +- **Cash Alternatives**: Kupovina poklon kartica i njihova zamena na internetu za bitcoin. +- **Mining**: Najprivatniji metod za zarađivanje bitcoina je mining, posebno kada se radi samostalno, jer mining poolovi mogu znati IP adresu rudara. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining) +- **Theft**: Teoretski, krađa bitcoina mogla bi biti još jedan metod za njegovo anonimno sticanje, iako je to protivzakonito i ne preporučuje se. -## Servisi za Mešanje +## Mixing Services -Korišćenjem servisa za mešanje, korisnik može **poslati bitcoine** i primiti **različite bitcoine u zamenu**, što otežava praćenje originalnog vlasnika. Ipak, ovo zahteva poverenje u servis da ne čuva evidenciju i da zaista vrati bitcoine. Alternativne opcije mešanja uključuju Bitcoin kockarnice. +Korišćenjem mixing servisa, korisnik može poslati bitcoine i primiti drugačije bitcoine zauzvrat, što otežava praćenje izvornog vlasnika. Ipak, to zahteva poverenje u servis da neće čuvati logove i da će zaista vratiti bitcoine. Alternativa mixing servisima su Bitcoin kazina. ## CoinJoin -**CoinJoin** spaja više transakcija od različitih korisnika u jednu, komplikujući proces za svakoga ko pokušava da uskladi ulaze sa izlazima. I pored svoje efikasnosti, transakcije sa jedinstvenim ulaznim i izlaznim veličinama i dalje se mogu potencijalno pratiti. +CoinJoin spaja više transakcija od različitih korisnika u jednu, otežavajući povezivanje inputa i outputa. Uprkos efikasnosti, transakcije sa jedinstvenim veličinama inputa i outputa i dalje se mogu pratiti. -Primeri transakcija koje su možda koristile CoinJoin uključuju `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` i `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`. +Primer transakcija koje su možda koristile CoinJoin uključuju `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` i `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`. -Za više informacija, posetite [CoinJoin](https://coinjoin.io/en). Za sličnu uslugu na Ethereum-u, pogledajte [Tornado Cash](https://tornado.cash), koja anonimizuje transakcije sa sredstvima od rudara. +Za više informacija, posetite [CoinJoin](https://coinjoin.io/en). Za sličan servis na Ethereum-u, pogledajte [Tornado Cash](https://tornado.cash), koji anonimizuje transakcije koristeći sredstva od miner-a. ## PayJoin -Varijanta CoinJoin, **PayJoin** (ili P2EP), prikriva transakciju između dve strane (npr. kupca i trgovca) kao redovnu transakciju, bez karakterističnih jednakih izlaza koji su karakteristični za CoinJoin. Ovo čini izuzetno teškim otkrivanje i moglo bi da poništi heuristiku zajedničkog vlasništva ulaza koju koriste entiteti za nadzor transakcija. +Varijanta CoinJoin-a, PayJoin (ili P2EP), maskira transakciju između dve strane (npr. kupac i trgovac) kao običnu transakciju, bez karakterističnih jednakih outputa tipičnih za CoinJoin. To je izuzetno teško detektovati i može poništiti common-input-ownership heuristic koju koriste entiteti za nadzor transakcija. ```plaintext 2 btc --> 3 btc 5 btc 4 btc ``` -Transakcije poput gornjih mogu biti PayJoin, poboljšavajući privatnost dok ostaju neprepoznatljive od standardnih bitcoin transakcija. +Transakcije kao gore navedene mogu biti PayJoin, poboljšavajući privatnost dok ostaju neodvojive od standardnih bitcoin transakcija. -**Korišćenje PayJoin-a može značajno ometati tradicionalne metode nadzora**, čineći ga obećavajućim razvojem u potrazi za transakcionom privatnošću. +**Korišćenje PayJoin-a moglo bi značajno da poremeti tradicionalne metode nadzora**, čineći ga perspektivnim razvojem u potrazi za privatnošću transakcija. # Najbolje prakse za privatnost u kriptovalutama ## **Tehnike sinhronizacije novčanika** -Da bi se održala privatnost i sigurnost, sinhronizacija novčanika sa blockchain-om je ključna. Dve metode se ističu: +Za očuvanje privatnosti i bezbednosti, sinhronizacija novčanika sa blockchain-om je ključna. Ističu se dve metode: -- **Puni čvor**: Preuzimanjem celog blockchain-a, puni čvor osigurava maksimalnu privatnost. Sve transakcije ikada izvršene se čuvaju lokalno, što onemogućava protivnicima da identifikuju koje transakcije ili adrese korisnik zanima. -- **Filtriranje blokova na klijentskoj strani**: Ova metoda uključuje kreiranje filtera za svaki blok u blockchain-u, omogućavajući novčanicima da identifikuju relevantne transakcije bez izlaganja specifičnih interesa posmatračima mreže. Laki novčanici preuzimaju ove filtere, preuzimajući pune blokove samo kada se pronađe podudaranje sa adresama korisnika. +- **Full node**: Preuzimanjem celog blockchain-a, Full node obezbeđuje maksimalnu privatnost. Sve transakcije ikada izvršene se čuvaju lokalno, čime je onemogućeno da protivnici identifikuju koje transakcije ili adrese korisnika su relevantne. +- **Client-side block filtering**: Ova metoda podrazumeva kreiranje filtera za svaki blok u blockchain-u, omogućavajući novčanicima da identifikuju relevantne transakcije bez otkrivanja specifičnih interesovanja posmatračima mreže. Lightweight wallets preuzimaju ove filtere i dohvataju pune blokove samo kad se pronađe poklapanje sa adresama korisnika. -## **Korišćenje Tora za anonimnost** +## **Korišćenje Tor-a za anonimnost** -S obzirom na to da Bitcoin funkcioniše na peer-to-peer mreži, preporučuje se korišćenje Tora za maskiranje vaše IP adrese, poboljšavajući privatnost prilikom interakcije sa mrežom. +S obzirom da Bitcoin radi na peer-to-peer mreži, preporučuje se korišćenje Tor-a za maskiranje IP adrese, čime se povećava privatnost pri interakciji sa mrežom. -## **Prevencija ponovne upotrebe adresa** +## **Sprečavanje ponovne upotrebe adresa** -Da bi se zaštitila privatnost, važno je koristiti novu adresu za svaku transakciju. Ponovna upotreba adresa može kompromitovati privatnost povezivanjem transakcija sa istim entitetom. Moderni novčanici obeshrabruju ponovnu upotrebu adresa kroz svoj dizajn. +Za zaštitu privatnosti važno je koristiti novu adresu za svaku transakciju. Ponovna upotreba adresa može ugroziti privatnost povezivanjem transakcija sa istim entitetom. Moderni novčanici svojim dizajnom obeshrabruju ponovnu upotrebu adresa. ## **Strategije za privatnost transakcija** -- **Više transakcija**: Deljenje uplate na nekoliko transakcija može zamagliti iznos transakcije, ometajući napade na privatnost. -- **Izbegavanje promena**: Odabir transakcija koje ne zahtevaju promene poboljšava privatnost ometajući metode detekcije promena. -- **Više izlaza za promenu**: Ako izbegavanje promene nije izvodljivo, generisanje više izlaza za promenu može i dalje poboljšati privatnost. +- **Multiple transactions**: Razdvajanje uplate na više transakcija može zamagliti iznos transakcije i otežati napade na privatnost. +- **Change avoidance**: Odabir transakcija koje ne zahtevaju change outputs povećava privatnost jer remeti metode detekcije change-a. +- **Multiple change outputs**: Ako izbegavanje change-a nije moguće, generisanje više change outputs može i dalje poboljšati privatnost. # **Monero: Svetionik anonimnosti** -Monero odgovara na potrebu za apsolutnom anonimnošću u digitalnim transakcijama, postavljajući visoke standarde za privatnost. +Monero odgovara na potrebu za apsolutnom anonimnošću u digitalnim transakcijama, postavljajući visok standard privatnosti. # **Ethereum: Gas i transakcije** ## **Razumevanje gasa** -Gas meri računski napor potreban za izvršavanje operacija na Ethereum-u, a cena je u **gwei**. Na primer, transakcija koja košta 2,310,000 gwei (ili 0.00231 ETH) uključuje gas limit i osnovnu naknadu, uz napojnicu za podsticanje rudara. Korisnici mogu postaviti maksimalnu naknadu kako bi osigurali da ne preplate, a višak se vraća. +Gas meri računarski napor potreban za izvršavanje operacija na Ethereum-u, cenjen u **gwei**. Na primer, transakcija koja košta 2,310,000 gwei (ili 0.00231 ETH) uključuje gas limit i baznu naknadu, kao i napojnicu za podsticanje rudara. Korisnici mogu postaviti maksimalnu naknadu kako ne bi preplatili, a višak se refundira. ## **Izvršavanje transakcija** -Transakcije u Ethereum-u uključuju pošiljaoca i primaoca, koji mogu biti adrese korisnika ili pametnih ugovora. One zahtevaju naknadu i moraju biti rudarene. Osnovne informacije u transakciji uključuju primaoca, potpis pošiljaoca, vrednost, opcione podatke, gas limit i naknade. Značajno je da se adresa pošiljaoca deducira iz potpisa, eliminišući potrebu za njom u podacima transakcije. +Transakcije na Ethereum-u uključuju pošiljaoca i primaoca, koji mogu biti adrese korisnika ili smart contract-a. One zahtevaju naknadu i moraju biti mined. Osnovne informacije u transakciji uključuju primaoca, potpis pošiljaoca, vrednost, opcionu data, gas limit i naknade. Značajno je da se adresa pošiljaoca izvodi iz potpisa, što eliminiše potrebu da bude eksplicitno uključena u podacima transakcije. -Ove prakse i mehanizmi su osnovni za svakoga ko želi da se angažuje sa kriptovalutama dok prioritet daje privatnosti i sigurnosti. +Ove prakse i mehanizmi su temeljni za svakoga ko želi da se bavi kriptovalutama, a prioritet mu je privatnost i bezbednost. -## Reference +## References - [https://en.wikipedia.org/wiki/Proof_of_stake](https://en.wikipedia.org/wiki/Proof_of_stake) - [https://www.mycryptopedia.com/public-key-private-key-explained/](https://www.mycryptopedia.com/public-key-private-key-explained/) @@ -179,4 +181,12 @@ Ove prakse i mehanizmi su osnovni za svakoga ko želi da se angažuje sa kriptov - [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/) - [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse) +## DeFi/AMM Exploitation + +Ako istražujete praktičnu eksploataciju DEX-ova i AMM-ova (Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps), pogledajte: + +{{#ref}} +defi-amm-hook-precision.md +{{#endref}} + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md b/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md new file mode 100644 index 000000000..7bd59170f --- /dev/null +++ b/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md @@ -0,0 +1,160 @@ +# DeFi/AMM Exploitation: Uniswap v4 Hook Precision/Rounding Abuse + +{{#include ../../banners/hacktricks-training.md}} + +Ova stranica dokumentuje klasu DeFi/AMM eksploatacionih tehnika protiv Uniswap v4–stil DEX‑ova koji proširuju osnovnu matematiku dodatnim hookovima. Nedavan incident u Bunni V2 iskoristio je grešku u zaokruživanju/preciznosti u Liquidity Distribution Function (LDF) koja se izvršavala pri svakoj zameni, omogućivši napadaču da akumulira pozitivne kredite i isisava likvidnost. + +Ključna ideja: ako hook implementira dodatno računovodstvo koje zavisi od fixed‑point matematike, zaokruživanja tick‑ova i logike praga, napadač može da sastavi exact‑input swapove koji prelaze specifične pragove tako da se razlike u zaokruživanju akumuliraju u njegovu korist. Ponavljanje obrasca i potom povlačenje uvećanog salda realizuje profit, često finansiran flash loan‑om. + +## Background: Uniswap v4 hooks and swap flow + +- Hooks su contracti koje PoolManager poziva u specifičnim tačkama životnog ciklusa (npr. beforeSwap/afterSwap, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity). +- Pools se inicijalizuju sa PoolKey koji uključuje hooks address. Ako nije nula, PoolManager izvršava callbacks pri svakoj relevantnoj operaciji. +- Core math koristi fixed‑point formate kao što je Q64.96 za sqrtPriceX96 i tick aritmetiku sa 1.0001^tick. Bilo koja custom matematika koja se nadograđuje mora pažljivo da uskladi semantiku zaokruživanja da bi se izbegao drift invarianti. +- Swaps mogu biti exactInput ili exactOutput. U v3/v4 cena se pomera duž tickova; prelazak granice tick‑a može aktivirati/deaktivirati range likvidnost. Hooks mogu implementirati dodatnu logiku na prelascima praga/ticka. + +## Vulnerability archetype: threshold‑crossing precision/rounding drift + +Tipičan ranjiv obrazac u custom hookovima: + +1. Hook računa per‑swap delta‑e likvidnosti ili balansa koristeći integer division, mulDiv, ili fixed‑point konverzije (npr. token ↔ liquidity koristeći sqrtPrice i tick range). +2. Logika praga (npr. rebalansiranje, stepwise redistribucija, ili per‑range aktivacija) se aktivira kada veličina swapa ili pomeranje cene pređe internu granicu. +3. Zaokruživanje se primenjuje nekonzistentno (npr. truncation toward zero, floor naspram ceil) između forward izračuna i settlement puta. Male razlike se ne poništavaju već umesto toga kreditiraju pozivaoca. +4. Exact‑input swapovi, precizno dimenzionisani da obuhvate te granice, ponavljano sakupljaju pozitivan remainder iz zaokruživanja. Napadač kasnije povlači akumulirani kredit. + +Preduslovi napada +- Pool koji koristi custom v4 hook koji obavlja dodatne matematičke operacije pri svakoj zameni (npr. LDF/rebalancer). +- Bar jedan izvršni put gde zaokruživanje koristi u korist inicijatora swapa preko prelaska praga. +- Mogućnost ponavljanja mnogo swapova atomično (flash loan‑ovi su idealni da obezbede privremeni float i amortizuju gas). + +## Practical attack methodology + +1) Identify candidate pools with hooks +- Enumerišite v4 pools i proverite PoolKey.hooks != address(0). +- Inspektujte hook bytecode/ABI za callbacks: beforeSwap/afterSwap i bilo koje custom rebalancing metode. +- Tražite matematiku koja: deli po likvidnosti, konvertuje između token amount‑a i liquidity, ili agregira BalanceDelta sa zaokruživanjem. + +2) Model the hook’s math and thresholds +- Rekreirajte hook‑ov formula za likvidnost/redistribuciju: ulazi tipično uključuju sqrtPriceX96, tickLower/Upper, currentTick, fee tier, i net liquidity. +- Mapirajte threshold/step funkcije: tickove, bucket granice, ili LDF breakpoint‑ove. Odredite na kojoj strani svake granice delta biva zaokružena. +- Identifikujte gde konverzije kastuju između uint256/int256, koriste SafeCast, ili se oslanjaju na mulDiv sa implicitnim floor. + +3) Calibrate exact‑input swaps to cross boundaries +- Koristite Foundry/Hardhat simulacije da izračunate minimalni Δin potreban da pomerite cenu tek preko granice i aktivirate hook‑ovu granu. +- Potvrdite da afterSwap settlement kreditira pozivaoca više nego što je trošak, ostavljajući pozitivan BalanceDelta ili kredit u hook‑ovom računovodstvu. +- Ponavljajte swapove da akumulirate kredit; zatim pozovite hook‑ov withdrawal/settlement put. + +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); +} +``` +Calibrating the exactInput +- Izračunajte ΔsqrtP za tick korak: sqrtP_next = sqrtP_current × 1.0001^(Δtick). +- Aproksimirajte Δin koristeći v3/v4 formule: Δx ≈ L × (ΔsqrtP / (sqrtP_next × sqrtP_current)). Pazite da smer zaokruživanja odgovara osnovnoj matematici. +- Podesite Δin za ±1 wei oko granice da biste pronašli granu u kojoj hook zaokružuje u vašu korist. + +4) Amplify with flash loans +- Pozajmite veliki notional (npr. 3M USDT ili 2000 WETH) da biste pokrenuli mnogo iteracija atomski. +- Izvršite kalibrisani swap loop, zatim povucite sredstva i vratite ih unutar flash loan callback-a. + +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) Izlaz i replikacija između lanaca +- Ako su hooks deploy‑ovani na više chain‑ova, ponovite istu kalibraciju po chain‑u. +- Bridge vraća sredstva nazad na target chain i opciono kruži preko lending protocol‑a da zamagli tokove. + +## Uobičajeni osnovni uzroci u matematici hook‑a + +- Pomešana semantika zaokruživanja: mulDiv radi floor dok kasniji putevi efektivno zaokružuju nagore; ili konverzije između token/liquidity primenjuju različito zaokruživanje. +- Greške u usklađivanju tick‑ova: korišćenje nezaokrugljenih ticks u jednom putu i tick‑spaced zaokruživanja u drugom. +- Problemi sa znakom/overflow BalanceDelta pri konverziji između int256 i uint256 tokom settlement‑a. +- Gubitak preciznosti u Q64.96 konverzijama (sqrtPriceX96) koji nije zrcaljen u obrnutom mapiranju. +- Putanje akumulacije: per‑swap rezerve praćene kao krediti koji su withdrawable by the caller umesto da budu burned/zero‑sum. + +## Odbrambene smernice + +- Diferencijalno testiranje: zrcalite matematičku logiku hook‑a sa referentnom implementacijom koristeći visokopreciznu racionalnu aritmetiku i assertujte jednakost ili ograničenu grešku koja je uvek adversarijalna (nikad povoljna za caller‑a). +- Testovi invarianti/svojstava: +- Zbir delta (tokens, liquidity) preko swap path‑ova i podešavanja hook‑a mora sačuvati vrednost modulo fees. +- Nijedan path ne bi trebalo da stvori pozitivan net credit za swap initiator‑a pri ponovljenim exactInput iteracijama. +- Testovi oko pragova/tick granica za ±1 wei inpute za oba exactInput/exactOutput. +- Politika zaokruživanja: centralizujte rounding helpers koji uvek round against the user; eliminišite nekonzistentne casts i implicitne floors. +- Settlement sinks: akumulirajte neizbežan rounding residue u trezor protokola ili ga burn‑ujte; nikada ga ne pripisujte msg.sender‑u. +- Rate‑limits/guardrails: minimalne veličine swap‑ova za rebalancing okidače; onemogućite rebalanse ako su delte sub‑wei; sanity‑check delte protiv očekivanih opsega. +- Pregledajte hook callbacks holistički: beforeSwap/afterSwap i before/after promene likvidnosti treba da se poklapaju u pogledu tick usklađivanja i delta zaokruživanja. + +## Studija slučaja: Bunni V2 (2025‑09‑02) + +- Protokol: Bunni V2 (Uniswap v4 hook) sa LDF primenjenim po swap‑u za rebalans. +- Osnovni uzrok: greška u zaokruživanju/preciznosti u LDF accounting‑u likvidnosti tokom threshold‑crossing swap‑ova; per‑swap razlike akumulirane kao pozitivni krediti za caller‑a. +- Ethereum leg: attacker uzeo ~3M USDT flash loan, izveo kalibrisane exact‑input swap‑ove na USDC/USDT da izgradi kredite, povukao inflirane balance‑e, vratio i routovao sredstva preko Aave. +- UniChain leg: ponovio exploit sa 2000 WETH flash loan‑om, iskorištavajući ~1366 WETH i bridžujući na Ethereum. +- Uticaj: ~USD 8.3M isisano preko chain‑ova. Nije bila potrebna interakcija korisnika; potpuno on‑chain. + +## Kontrolna lista za otkrivanje + +- Da li pool koristi non‑zero hooks adresu? Koji callbacks su enabled? +- Postoje li per‑swap redistributions/rebalances koji koriste custom math? Bilo kakva tick/threshold logika? +- Gde su divisions/mulDiv, Q64.96 konverzije, ili SafeCast korišćeni? Da li su semantike zaokruživanja globalno konzistentne? +- Možete li konstruisati Δin koji jedva pređe granicu i daje povoljnu rounding branch? Testirajte obe smerove i oba exactInput i exactOutput. +- Da li hook prati per‑caller kredite ili delte koje kasnije mogu biti withdrawn? Osigurajte da je residue neutralisan. + +## 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}} diff --git a/src/crypto-and-stego/blockchain-and-crypto-currencies.md b/src/crypto-and-stego/blockchain-and-crypto-currencies.md deleted file mode 100644 index 46fd5b59a..000000000 --- a/src/crypto-and-stego/blockchain-and-crypto-currencies.md +++ /dev/null @@ -1,182 +0,0 @@ -{{#include ../banners/hacktricks-training.md}} - -## Osnovni Koncepti - -- **Pametni Ugovori** definišu se kao programi koji se izvršavaju na blockchain-u kada su ispunjeni određeni uslovi, automatizujući izvršenja ugovora bez posrednika. -- **Decentralizovane Aplikacije (dApps)** se oslanjaju na pametne ugovore, imajući korisnički prijatan front-end i transparentan, auditable back-end. -- **Tokeni i Kovanice** se razlikuju gde kovanice služe kao digitalni novac, dok tokeni predstavljaju vrednost ili vlasništvo u specifičnim kontekstima. -- **Utility Tokeni** omogućavaju pristup uslugama, a **Security Tokeni** označavaju vlasništvo nad imovinom. -- **DeFi** označava Decentralizovane Finansije, nudeći finansijske usluge bez centralnih vlasti. -- **DEX** i **DAO** se odnose na Decentralizovane Berzanske Platforme i Decentralizovane Autonomne Organizacije, redom. - -## Mehanizmi Konsenzusa - -Mehanizmi konsenzusa osiguravaju sigurne i dogovorene validacije transakcija na blockchain-u: - -- **Proof of Work (PoW)** se oslanja na računarsku snagu za verifikaciju transakcija. -- **Proof of Stake (PoS)** zahteva od validatora da drže određenu količinu tokena, smanjujući potrošnju energije u poređenju sa PoW. - -## Osnovne Informacije o Bitcoinu - -### Transakcije - -Bitcoin transakcije uključuju prebacivanje sredstava između adresa. Transakcije se validiraju putem digitalnih potpisa, osiguravajući da samo vlasnik privatnog ključa može inicirati transfere. - -#### Ključne Komponente: - -- **Multisignature Transakcije** zahtevaju više potpisa za autorizaciju transakcije. -- Transakcije se sastoje od **ulaza** (izvor sredstava), **izlaza** (odredište), **naknada** (plaćene rudarima) i **skripti** (pravila transakcije). - -### Lightning Network - -Cilj je poboljšati skalabilnost Bitcoina omogućavajući više transakcija unutar kanala, samo emitovanjem konačnog stanja na blockchain. - -## Problemi Privatnosti Bitcoina - -Napadi na privatnost, kao što su **Common Input Ownership** i **UTXO Change Address Detection**, koriste obrasce transakcija. Strategije poput **Mixers** i **CoinJoin** poboljšavaju anonimnost prikrivanjem veza između transakcija korisnika. - -## Sticanje Bitcoina Anonimno - -Metode uključuju gotovinske trgovine, rudarenje i korišćenje miksera. **CoinJoin** meša više transakcija kako bi otežao praćenje, dok **PayJoin** prikriva CoinJoins kao obične transakcije za povećanu privatnost. - -# Napadi na Privatnost Bitcoina - -# Sažetak Napada na Privatnost Bitcoina - -U svetu Bitcoina, privatnost transakcija i anonimnost korisnika često su predmet zabrinutosti. Evo pojednostavljenog pregleda nekoliko uobičajenih metoda kroz koje napadači mogu kompromitovati privatnost Bitcoina. - -## **Pretpostavka Zajedničkog Vlasništva Ulaza** - -Generalno je retko da se ulazi različitih korisnika kombinuju u jednoj transakciji zbog složenosti koja je uključena. Tako se **dve adrese ulaza u istoj transakciji često pretpostavljaju da pripadaju istom vlasniku**. - -## **UTXO Adresa Promene Detekcija** - -UTXO, ili **Unspent Transaction Output**, mora biti potpuno potrošen u transakciji. Ako se samo deo pošalje na drugu adresu, ostatak ide na novu adresu promene. Posmatrači mogu pretpostaviti da ova nova adresa pripada pošiljaocu, kompromitujući privatnost. - -### Primer - -Da bi se to ublažilo, usluge mešanja ili korišćenje više adresa mogu pomoći u prikrivanju vlasništva. - -## **Izloženost Društvenih Mreža i Foruma** - -Korisnici ponekad dele svoje Bitcoin adrese na mreži, što olakšava **povezivanje adrese sa njenim vlasnikom**. - -## **Analiza Transakcionih Grafova** - -Transakcije se mogu vizualizovati kao grafovi, otkrivajući potencijalne veze između korisnika na osnovu toka sredstava. - -## **Heuristika Nepotrebnog Ulaza (Optimalna Heuristika Promene)** - -Ova heuristika se zasniva na analizi transakcija sa više ulaza i izlaza kako bi se pogodilo koji izlaz je promena koja se vraća pošiljaocu. - -### Primer -```bash -2 btc --> 4 btc -3 btc 1 btc -``` -Ako dodavanje više ulaza čini izlaz veći od bilo kog pojedinačnog ulaza, to može zbuniti heuristiku. - -## **Prisilna Ponovna Upotreba Adresa** - -Napadači mogu slati male iznose na prethodno korišćene adrese, nadajući se da će primalac kombinovati ove sa drugim ulazima u budućim transakcijama, čime se povezuju adrese. - -### Ispravno Ponašanje Novčanika - -Novčanici bi trebali izbegavati korišćenje kovanica primljenih na već korišćenim, praznim adresama kako bi se sprečilo ovo curenje privatnosti. - -## **Druge Tehnike Analize Blockchain-a** - -- **Tačni Iznosi Plaćanja:** Transakcije bez kusura su verovatno između dve adrese koje poseduje isti korisnik. -- **Celi Brojevi:** Celi broj u transakciji sugeriše da je to plaćanje, pri čemu je ne-celi izlaz verovatno kusur. -- **Otisak Novčanika:** Različiti novčanici imaju jedinstvene obrasce kreiranja transakcija, što omogućava analitičarima da identifikuju korišćen softver i potencijalno adresu kusura. -- **Korelacije Iznosa i Vremena:** Otkriće vremena ili iznosa transakcija može učiniti transakcije tragovima. - -## **Analiza Saobraćaja** - -Praćenjem mrežnog saobraćaja, napadači mogu potencijalno povezati transakcije ili blokove sa IP adresama, ugrožavajući privatnost korisnika. Ovo je posebno tačno ako entitet upravlja mnogim Bitcoin čvorovima, što poboljšava njihovu sposobnost praćenja transakcija. - -## Više - -Za sveobuhvatan spisak napada na privatnost i odbrana, posetite [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy). - -# Anonimne Bitcoin Transakcije - -## Načini za Sticanje Bitcoina Anonimno - -- **Transakcije Gotovinom**: Sticanje bitcoina putem gotovine. -- **Alternativa Gotovini**: Kupovina poklon kartica i njihova razmena online za bitcoin. -- **Rudarenje**: Najprivatnija metoda za zarađivanje bitcoina je kroz rudarenje, posebno kada se radi samostalno, jer rudarske grupe mogu znati IP adresu rudara. [Informacije o Rudarskim Grupama](https://en.bitcoin.it/wiki/Pooled_mining) -- **Krađa**: Teoretski, krađa bitcoina bi mogla biti još jedna metoda za sticanje anonimno, iako je to ilegalno i ne preporučuje se. - -## Servisi za Mešanje - -Korišćenjem servisa za mešanje, korisnik može **poslati bitcoine** i primiti **različite bitcoine u zamenu**, što otežava praćenje originalnog vlasnika. Ipak, ovo zahteva poverenje u servis da ne čuva evidenciju i da zaista vrati bitcoine. Alternativne opcije mešanja uključuju Bitcoin kockarnice. - -## CoinJoin - -**CoinJoin** spaja više transakcija od različitih korisnika u jednu, komplikujući proces za svakoga ko pokušava da uskladi ulaze sa izlazima. I pored svoje efikasnosti, transakcije sa jedinstvenim ulaznim i izlaznim veličinama i dalje se potencijalno mogu pratiti. - -Primeri transakcija koje su možda koristile CoinJoin uključuju `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` i `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`. - -Za više informacija, posetite [CoinJoin](https://coinjoin.io/en). Za sličnu uslugu na Ethereum-u, pogledajte [Tornado Cash](https://tornado.cash), koja anonimizuje transakcije sa sredstvima od rudara. - -## PayJoin - -Varijanta CoinJoin-a, **PayJoin** (ili P2EP), prikriva transakciju između dve strane (npr. kupca i trgovca) kao redovnu transakciju, bez karakterističnih jednakih izlaza koji su karakteristični za CoinJoin. Ovo čini izuzetno teškim otkrivanje i moglo bi da poništi heuristiku zajedničkog vlasništva ulaza koju koriste entiteti za nadzor transakcija. -```plaintext -2 btc --> 3 btc -5 btc 4 btc -``` -Transakcije poput gornjih mogle bi biti PayJoin, poboljšavajući privatnost dok ostaju neprepoznatljive od standardnih bitcoin transakcija. - -**Korišćenje PayJoin moglo bi značajno ometati tradicionalne metode nadzora**, čineći ga obećavajućim razvojem u potrazi za transakcionom privatnošću. - -# Najbolje prakse za privatnost u kriptovalutama - -## **Tehnike sinhronizacije novčanika** - -Da bi se održala privatnost i sigurnost, sinhronizacija novčanika sa blockchain-om je ključna. Dve metode se ističu: - -- **Puni čvor**: Preuzimanjem celog blockchain-a, puni čvor osigurava maksimalnu privatnost. Sve transakcije ikada izvršene se čuvaju lokalno, što onemogućava protivnicima da identifikuju koje transakcije ili adrese korisnik zanima. -- **Filtriranje blokova na klijentskoj strani**: Ova metoda uključuje kreiranje filtera za svaki blok u blockchain-u, omogućavajući novčanicima da identifikuju relevantne transakcije bez izlaganja specifičnih interesa posmatračima mreže. Laki novčanici preuzimaju ove filtere, preuzimajući pune blokove samo kada se pronađe podudaranje sa adresama korisnika. - -## **Korišćenje Tora za anonimnost** - -S obzirom na to da Bitcoin funkcioniše na peer-to-peer mreži, preporučuje se korišćenje Tora za maskiranje vaše IP adrese, poboljšavajući privatnost prilikom interakcije sa mrežom. - -## **Sprečavanje ponovne upotrebe adresa** - -Da bi se zaštitila privatnost, važno je koristiti novu adresu za svaku transakciju. Ponovna upotreba adresa može kompromitovati privatnost povezivanjem transakcija sa istim entitetom. Moderni novčanici obeshrabruju ponovnu upotrebu adresa kroz svoj dizajn. - -## **Strategije za privatnost transakcija** - -- **Više transakcija**: Deljenje uplate na nekoliko transakcija može zamagliti iznos transakcije, ometajući napade na privatnost. -- **Izbegavanje promena**: Odabir transakcija koje ne zahtevaju promene poboljšava privatnost ometajući metode detekcije promena. -- **Više izlaza za promenu**: Ako izbegavanje promene nije izvodljivo, generisanje više izlaza za promenu može i dalje poboljšati privatnost. - -# **Monero: Svetionik anonimnosti** - -Monero se bavi potrebom za apsolutnom anonimnošću u digitalnim transakcijama, postavljajući visoke standarde za privatnost. - -# **Ethereum: Gas i transakcije** - -## **Razumevanje gasa** - -Gas meri računski napor potreban za izvršavanje operacija na Ethereum-u, a cena je u **gwei**. Na primer, transakcija koja košta 2,310,000 gwei (ili 0.00231 ETH) uključuje gas limit i osnovnu naknadu, uz napojnicu za podsticanje rudara. Korisnici mogu postaviti maksimalnu naknadu kako bi osigurali da ne preplate, a višak se vraća. - -## **Izvršavanje transakcija** - -Transakcije na Ethereum-u uključuju pošiljaoca i primaoca, koji mogu biti adrese korisnika ili pametnih ugovora. One zahtevaju naknadu i moraju biti rudarenje. Osnovne informacije u transakciji uključuju primaoca, potpis pošiljaoca, vrednost, opcione podatke, gas limit i naknade. Značajno je da se adresa pošiljaoca deducira iz potpisa, eliminišući potrebu za njom u podacima transakcije. - -Ove prakse i mehanizmi su osnovni za svakoga ko želi da se bavi kriptovalutama dok prioritet daje privatnosti i sigurnosti. - -## Reference - -- [https://en.wikipedia.org/wiki/Proof_of_stake](https://en.wikipedia.org/wiki/Proof_of_stake) -- [https://www.mycryptopedia.com/public-key-private-key-explained/](https://www.mycryptopedia.com/public-key-private-key-explained/) -- [https://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions](https://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions) -- [https://ethereum.org/en/developers/docs/transactions/](https://ethereum.org/en/developers/docs/transactions/) -- [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/) -- [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse) - -{{#include ../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md index bfe7f3c36..32c79b94d 100644 --- a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md +++ b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md @@ -4,14 +4,14 @@ ## Uvod -Electron kombinuje lokalni backend (sa **NodeJS**) i frontend (**Chromium**), iako mu nedostaju neki sigurnosni mehanizmi modernih pretraživača. +Electron kombinuje lokalni backend (sa **NodeJS**) i frontend (**Chromium**), iako mu nedostaju neki sigurnosni mehanizmi modernih pregledača. -Obično možete naći kod Electron aplikacije unutar `.asar` arhive; da biste dobili kod, potrebno je da je izdvojite: +Obično možete pronaći kod Electron aplikacije unutar `.asar` fajla; da biste dobili kod, potrebno je da ga izdvojite: ```bash npx asar extract app.asar destfolder #Extract everything npx asar extract-file app.asar main.js #Extract just a file ``` -U izvornom kodu Electron aplikacije, u datoteci `packet.json`, možete pronaći specificiranu datoteku `main.js` u kojoj su podešene sigurnosne konfiguracije. +U izvornom kodu Electron aplikacije, u datoteci `packet.json`, može se naći naveden fajl `main.js` u kojem su podešene sigurnosne konfiguracije. ```json { "name": "standard-notes", @@ -19,12 +19,12 @@ U izvornom kodu Electron aplikacije, u datoteci `packet.json`, možete pronaći ``` Electron ima 2 tipa procesa: -- Main Process (ima potpuni pristup NodeJS-u) -- Renderer Process (trebalo bi da ima ograničen pristup NodeJS-u iz bezbednosnih razloga) +- Glavni proces (ima potpuni pristup NodeJS) +- Renderer proces (trebalo bi da ima ograničen pristup NodeJS iz bezbednosnih razloga) ![](<../../../images/image (182).png>) -A **renderer process** biće prozor pregledača koji učitava fajl: +**Renderer proces** će biti prozor pregledača koji učitava fajl: ```javascript const { BrowserWindow } = require("electron") let win = new BrowserWindow() @@ -32,18 +32,18 @@ let win = new BrowserWindow() //Open Renderer Process win.loadURL(`file://path/to/index.html`) ``` -Podešavanja **renderer process** mogu se **konfigurisati** u **main process** u fajlu main.js. Neka od podešavanja mogu **sprečiti Electron application da dobije RCE** ili druge ranjivosti ako su **podešavanja pravilno konfigurisana**. +Podešavanja **renderer procesa** mogu se **konfigurisati** u **main procesu** unutar fajla main.js. Neka podešavanja će **sprečiti Electron aplikaciju da dobije RCE** ili druge ranjivosti ako su **podešavanja ispravno postavljena**. -The electron application **could access the device** via Node apis although it can be configure to prevent it: +Electron aplikacija **može pristupiti uređaju** preko Node apis, iako se to može konfigurisati da se spreči: -- **`nodeIntegration`** - je `off` po defaultu. Ako je uključen, omogućava pristup node funkcijama iz renderer procesa. -- **`contextIsolation`** - je `on` po defaultu. Ako je `off`, main i renderer procesi nisu izolovani. -- **`preload`** - prazan po defaultu. -- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - je `off` po defaultu. Ograničiće akcije koje NodeJS može izvršavati. -- Node Integration u Workers -- **`nodeIntegrationInSubframes`** - je `off` po defaultu. -- Ako je **`nodeIntegration`** **enabled**, to bi omogućilo korišćenje **Node.js APIs** na web stranicama koje su **učitane u iframes** unutar Electron application. -- Ako je **`nodeIntegration`** **disabled**, tada će preloads biti učitani u iframe +- **`nodeIntegration`** - je podrazumevano `off`. Ako je `on`, omogućava pristup node funkcijama iz renderer procesa. +- **`contextIsolation`** - je podrazumevano `on`. Ako je `off`, main i renderer procesi nisu izolovani. +- **`preload`** - podrazumevano prazan. +- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - podrazumevano je `off`. Ograničava akcije koje NodeJS može izvršavati. +- Node Integration in Workers +- **`nodeIntegrationInSubframes`**- je podrazumevano `off`. +- Ako je **`nodeIntegration`** omogućen, to bi dozvolilo korišćenje **Node.js APIs** u web stranicama koje su **učitane u iframes** unutar Electron aplikacije. +- Ako je **`nodeIntegration`** onemogućen, tada će se preloads učitati u iframe Example of configuration: ```javascript @@ -95,15 +95,15 @@ onerror="alert(require('child_process').execSync('ls -l').toString());" /> src="x" onerror="alert(require('child_process').execSync('uname -a').toString());" /> ``` -### Presretanje saobraćaja +### Snimanje saobraćaja -Izmenite konfiguraciju start-main i dodajte korišćenje proxy-ja, na primer: +Izmenite konfiguraciju start-main i dodajte upotrebu proxy-ja, na primer: ```javascript "start-main": "electron ./dist/main/main.js --proxy-server=127.0.0.1:8080 --ignore-certificateerrors", ``` ## Electron Local Code Injection -Ako možete lokalno izvršiti Electron App, moguće je da biste ga mogli naterati da izvrši proizvoljan javascript kod. Pogledajte kako u: +Ako možete lokalno pokrenuti Electron App, moguće je da biste mogli naterati da izvrši proizvoljan javascript kod. Pogledajte kako u: {{#ref}} @@ -112,7 +112,7 @@ Ako možete lokalno izvršiti Electron App, moguće je da biste ga mogli naterat ## RCE: XSS + nodeIntegration -Ako je **nodeIntegration** podešen na **on**, JavaScript na web stranici može lako da koristi Node.js funkcionalnosti jednostavno pozivanjem `require()`. Na primer, način da se pokrene aplikacija calc na Windows-u je: +Ako je **nodeIntegration** postavljen na **on**, JavaScript na web stranici može lako koristiti Node.js funkcije samo pozivanjem `require()`. Na primer, način da se pokrene aplikacija calc na Windows je: ```html ``` -## **RCE: XSS + Stari Chromium** +## **RCE: XSS + Stari chromium** -Ako je **chromium** koji aplikacija koristi **zastareo** i postoje **poznate** **ranjivosti** u njemu, možda je moguće **iskoristiti ih i dobiti RCE kroz XSS**.\ -Možete videti primer u ovom **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/) +Ako je **chromium** koji aplikacija koristi **star** i postoje **poznate** **ranjivosti** na njemu, možda je moguće da **iskoristite ih i dobijete RCE kroz XSS**.\ +You can see an example in this **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/) -## **XSS Phishing via Internal URL regex bypass** +## **XSS Phishing putem obilaženja Internal URL regex-a** -Pretpostavimo da ste pronašli XSS ali ne možete da **pokrenete RCE ili ukradete interne fajlove** — možete pokušati da ga iskoristite da **ukradete kredencijale putem phishinga**. +Pretpostavimo da ste našli XSS, ali **ne možete pokrenuti RCE ili ukrasti interne fajlove** — možete pokušati da ga iskoristite za **ukrasti credentials putem phishinga**. -Prvo treba da znate šta se dešava kada pokušate da otvorite novi URL, proveravajući JS kod u front-endu: +Prvo treba da znate šta se dešava kada pokušate da otvorite novi URL, proverom JS koda u front-endu: ```javascript webContents.on("new-window", function (event, url, disposition, options) {} // opens the custom openInternally function (it is declared below) webContents.on("will-navigate", function (event, url) {} // opens the custom openInternally function (it is declared below) ``` -Poziv funkcije **`openInternally`** odlučiće da li će **link** biti **opened** u **desktop window** pošto je to link koji pripada platformi, **or** će biti otvoren u **browser as a 3rd party resource**. +Poziv ka **`openInternally`** odlučiće da li će se **link** **otvoriti** u **desktop prozoru** jer pripada platformi, **ili** da li će biti otvoren u **browseru kao resurs treće strane**. -U slučaju da je **regex** koji funkcija koristi **vulnerable to bypasses** (na primer **not escaping the dots of subdomains**) napadač može iskoristiti XSS da **open a new window which** će se nalaziti na infrastrukturi napadača i **asking for credentials** od korisnika: +U slučaju da je **regex** koji funkcija koristi **ranjiv na bypass-e** (na primer zbog **ne-escape-ovanja tačaka u subdomenima**) napadač bi mogao iskoristiti XSS da **otvori novi prozor koji** će se nalaziti u napadačevoj infrastrukturi i **tražiti kredencijale** od korisnika: ```html