From 8d50742aaf924241293fcc17b3d0eacff6af35af Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 12 Jul 2025 18:08:27 +0000 Subject: [PATCH] Translated ['src/mobile-pentesting/ios-pentesting/ios-pentesting-without --- .../ios-pentesting-without-jailbreak.md | 14 +-- .../request-smuggling-in-http-2-downgrades.md | 95 ++++++++++++++++++- 2 files changed, 101 insertions(+), 8 deletions(-) diff --git a/src/mobile-pentesting/ios-pentesting/ios-pentesting-without-jailbreak.md b/src/mobile-pentesting/ios-pentesting/ios-pentesting-without-jailbreak.md index 77c5e142f..cce16596c 100644 --- a/src/mobile-pentesting/ios-pentesting/ios-pentesting-without-jailbreak.md +++ b/src/mobile-pentesting/ios-pentesting/ios-pentesting-without-jailbreak.md @@ -31,7 +31,7 @@ Um sie zu installieren, entpacke einfach die IPA: ```bash unzip redacted.ipa -d unzipped ``` -Überprüfen Sie die `Info.plist` auf die minimal unterstützte Version und wenn Ihr Gerät älter ist, ändern Sie den Wert, damit es unterstützt wird. +Überprüfen Sie die `Info.plist` auf die minimale unterstützte Version, und wenn Ihr Gerät älter ist als diese, ändern Sie den Wert, damit es unterstützt wird. Zippen Sie die IPA zurück: ```bash @@ -42,14 +42,14 @@ Dann installieren Sie die IPA beispielsweise mit: ```bash ideviceinstaller -i no-min-version.ipa -w ``` -Beachten Sie, dass Sie möglicherweise den **AppSync Unified Tweak** von Cydia benötigen, um `invalid signature`-Fehler zu vermeiden. +Beachten Sie, dass Sie möglicherweise den **AppSync Unified tweak** von Cydia benötigen, um `invalid signature`-Fehler zu vermeiden. -Sobald installiert, können Sie den **Iridium Tweak** von Cydia verwenden, um die entschlüsselte IPA zu erhalten. +Sobald installiert, können Sie den **Iridium tweak** von Cydia verwenden, um die entschlüsselte IPA zu erhalten. ### Berechtigungen patchen & neu signieren -Um die Anwendung mit der Berechtigung `get-task-allow` neu zu signieren, stehen mehrere Tools wie `app-signer`, `codesign` und `iResign` zur Verfügung. `app-signer` hat eine sehr benutzerfreundliche Oberfläche, die es ermöglicht, eine IPA-Datei sehr einfach neu zu signieren, indem die zu signierende IPA, die **`get-task-allow`** gesetzt werden soll, sowie das Zertifikat und das zu verwendende Bereitstellungsprofil angegeben werden. +Um die Anwendung mit der Berechtigung `get-task-allow` neu zu signieren, stehen mehrere Tools wie `app-signer`, `codesign` und `iResign` zur Verfügung. `app-signer` hat eine sehr benutzerfreundliche Oberfläche, die es ermöglicht, eine IPA-Datei sehr einfach neu zu signieren, indem die zu signierende IPA, die **`get-taks-allow`**-Berechtigung sowie das zu verwendende Zertifikat und das Bereitstellungsprofil angegeben werden. Bezüglich des Zertifikats und der Signierungsprofile bietet Apple **kostenlose Entwickler-Signierungsprofile** für alle Konten über Xcode an. Erstellen Sie einfach eine App und konfigurieren Sie eine. Konfigurieren Sie dann das **iPhone, um den Entwickler-Apps zu vertrauen**, indem Sie zu `Einstellungen` → `Datenschutz & Sicherheit` navigieren und auf `Entwicklermodus` klicken. @@ -61,7 +61,7 @@ ideviceinstaller -i resigned.ipa -w ### Entwicklermodus aktivieren (iOS 16+) -Seit iOS 16 hat Apple den **Entwicklermodus** eingeführt: Jede Binary, die `get_task_allow` enthält *oder* mit einem Entwicklungszertifikat signiert ist, wird sich weigern zu starten, bis der Entwicklermodus auf dem Gerät aktiviert ist. Sie können auch Frida/LLDB nicht anhängen, es sei denn, dieses Flag ist aktiviert. +Seit iOS 16 hat Apple den **Entwicklermodus** eingeführt: Jede Binary, die `get_task_allow` *oder* mit einem Entwicklungszertifikat signiert ist, wird sich weigern zu starten, bis der Entwicklermodus auf dem Gerät aktiviert ist. Sie können auch Frida/LLDB nicht anhängen, es sei denn, dieses Flag ist aktiviert. 1. Installieren oder pushen Sie **irgendeine** entwickler-signierte IPA auf das Telefon. 2. Navigieren Sie zu **Einstellungen → Datenschutz & Sicherheit → Entwicklermodus** und aktivieren Sie ihn. @@ -76,7 +76,7 @@ Es gibt jetzt mehrere ausgereifte Möglichkeiten, IPAs zu sideloaden und sie ohn | Tool | Anforderungen | Stärken | Einschränkungen | |------|--------------|-----------|-------------| | **AltStore 2 / SideStore** | macOS/Windows/Linux-Begleitgerät, das die IPA alle 7 Tage mit einem kostenlosen Entwicklerprofil neu signiert | Automatisches Nachladen über Wi-Fi, funktioniert bis iOS 17 | Computer im selben Netzwerk erforderlich, 3-App-Limit von Apple auferlegt | -| **TrollStore 1/2** | Gerät mit iOS 14 – 15.4.1, das anfällig für den CoreTrust-Bug ist | *Permanente* Signierung (kein 7-Tage-Limit); kein Computer erforderlich, sobald installiert | Nicht unterstützt auf iOS 15.5+ (Bug gepatcht) | +| **TrollStore 1/2** | Gerät mit iOS 14 – 15.4.1, das anfällig für den CoreTrust-Bug ist | *Dauerhafte* Signierung (kein 7-Tage-Limit); kein Computer erforderlich, sobald installiert | Nicht unterstützt auf iOS 15.5+ (Bug gepatcht) | Für routinemäßige Pentests auf aktuellen iOS-Versionen sind Alt/Side-Store in der Regel die praktischste Wahl. @@ -94,7 +94,7 @@ Neuere Frida-Versionen (>=16) behandeln automatisch die Zeiger-Authentifizierung ### Automatisierte dynamische Analyse mit MobSF (kein Jailbreak) -[MobSF](https://mobsf.github.io/Mobile-Security-Framework-MobSF/) kann eine von einem Entwickler signierte IPA auf einem echten Gerät mit der gleichen Technik (`get_task_allow`) instrumentieren und bietet eine Web-UI mit Dateisystembrowser, Verkehrserfassung und Frida-Konsole【】. Der schnellste Weg ist, MobSF in Docker auszuführen und dann dein iPhone über USB anzuschließen: +[MobSF](https://mobsf.github.io/Mobile-Security-Framework-MobSF/) kann eine von einem Entwickler signierte IPA auf einem echten Gerät mit der gleichen Technik (`get_task_allow`) instrumentieren und bietet eine Web-UI mit Dateisystembrowser, Verkehrserfassung und Frida-Konsole【†L2-L3】. Der schnellste Weg ist, MobSF in Docker auszuführen und dann dein iPhone über USB anzuschließen: ```bash docker pull opensecurity/mobile-security-framework-mobsf:latest docker run -p 8000:8000 --privileged \ diff --git a/src/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md b/src/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md index f47c5cea0..e0b98341e 100644 --- a/src/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md +++ b/src/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md @@ -2,6 +2,99 @@ {{#include ../../banners/hacktricks-training.md}} -**Überprüfen Sie den Beitrag [https://portswigger.net/research/http-2-downgrades](https://portswigger.net/research/http-2-downgrades)** +HTTP/2 wird allgemein als immun gegen klassisches Request-Smuggling angesehen, da die Länge jedes DATA-Frames explizit ist. **Dieser Schutz verschwindet, sobald ein Front-End-Proxy die Anfrage vor dem Weiterleiten an ein Back-End auf HTTP/1.x „downgradet“**. In dem Moment, in dem zwei verschiedene Parser (das HTTP/2 Front-End und das HTTP/1 Back-End) versuchen, sich darauf zu einigen, wo eine Anfrage endet und die nächste beginnt, kommen alle alten Desynchronisations-Tricks zurück – plus ein paar neue. + +--- +## Warum Downgrades passieren + +1. Browser sprechen bereits HTTP/2, aber viele veraltete Ursprungsinfrastrukturen verstehen immer noch nur HTTP/1.1. +2. Reverse-Proxys (CDNs, WAFs, Load-Balancer) beenden daher TLS + HTTP/2 am Rand und **schreiben jede Anfrage als HTTP/1.1** für den Ursprung um. +3. Der Übersetzungsschritt muss *sowohl* `Content-Length` **und/oder** `Transfer-Encoding: chunked` Header erstellen, damit der Ursprung die Körperlänge bestimmen kann. + +Wann immer das Front-End der HTTP/2-Frame-Länge **aber** das Back-End CL oder TE vertraut, kann ein Angreifer sie zwingen, nicht übereinzustimmen. + +--- +## Zwei dominante primitive Klassen + +| Variante | Front-End-Länge | Back-End-Länge | Typische Payload | +|---------|-----------------|-----------------|-----------------| +| **H2.TE** | HTTP/2-Frame | `Transfer-Encoding: chunked` | Fügen Sie einen zusätzlichen chunked Nachrichtentext ein, dessen finales `0\r\n\r\n` *nicht* gesendet wird, sodass das Back-End auf die vom Angreifer bereitgestellte „nächste“ Anfrage wartet. | +| **H2.CL** | HTTP/2-Frame | `Content-Length` | Senden Sie ein *kleineres* CL als den tatsächlichen Körper, sodass das Back-End über die Grenze hinaus in die folgende Anfrage liest. | + +> Diese sind im Geiste identisch mit klassischem TE.CL / CL.TE, nur dass HTTP/2 einen der Parser ersetzt. + +--- +## Identifizierung einer Downgrade-Kette + +1. Verwenden Sie **ALPN** in einem TLS-Handshake (`openssl s_client -alpn h2 -connect host:443`) oder **curl**: +```bash +curl -v --http2 https://target +``` +Wenn `* Using HTTP2` erscheint, spricht der Edge H2. +2. Senden Sie eine absichtlich fehlerhafte CL/TE-Anfrage *über* HTTP/2 (Burp Repeater hat jetzt ein Dropdown-Menü, um HTTP/2 zu erzwingen). Wenn die Antwort ein HTTP/1.1-Fehler wie `400 Bad chunk` ist, haben Sie den Beweis, dass der Edge den Verkehr für einen HTTP/1-Parser im Nachgang umgewandelt hat. + +--- +## Ausbeutungs-Workflow (H2.TE-Beispiel) +```http +:method: POST +:path: /login +:scheme: https +:authority: example.com +content-length: 13 # ignored by the edge +transfer-encoding: chunked + +5;ext=1\r\nHELLO\r\n +0\r\n\r\nGET /admin HTTP/1.1\r\nHost: internal\r\nX: X +``` +1. Das **Front-End** liest genau 13 Bytes (`HELLO\r\n0\r\n\r\nGE`), denkt, die Anfrage sei beendet und leitet so viel an den Ursprung weiter. +2. Das **Back-End** vertraut dem TE-Header, liest weiter, bis es das *zweite* `0\r\n\r\n` sieht, und verbraucht damit das Präfix der zweiten Anfrage des Angreifers (`GET /admin …`). +3. Der Rest (`GET /admin …`) wird als *neue* Anfrage behandelt, die hinter der des Opfers in der Warteschlange steht. + +Ersetze die geschmuggelte Anfrage durch: +* `POST /api/logout`, um eine Sitzungsfixierung zu erzwingen +* `GET /users/1234`, um eine opferspezifische Ressource zu stehlen + +--- +## h2c Smuggling (Klartext-Upgrades) + +Eine Studie aus dem Jahr 2023 zeigte, dass, wenn ein Front-End den HTTP/1.1 `Upgrade: h2c` Header an ein Back-End weitergibt, das Klartext-HTTP/2 unterstützt, ein Angreifer *rohe* HTTP/2-Frames durch eine Kante tunneln kann, die nur HTTP/1.1 validiert hat. Dies umgeht die Header-Normalisierung, WAF-Regeln und sogar die TLS-Terminierung. + +Wichtige Anforderungen: +* Die Kante leitet **sowohl** `Connection: Upgrade` als auch `Upgrade: h2c` unverändert weiter. +* Der Ursprung wechselt zu HTTP/2 und behält die Semantik der Verbindungswiederverwendung bei, die das Anfragen-Queueing ermöglicht. + +Die Minderung ist einfach – entferne oder hard-code den `Upgrade`-Header an der Kante, außer für WebSockets. + +--- +## Bemerkenswerte reale CVEs (2022-2025) + +* **CVE-2023-25690** – Apache HTTP Server mod_proxy Umschreiberegeln könnten für Anfrageaufteilung und Smuggling verkettet werden. (behoben in 2.4.56) +* **CVE-2023-25950** – HAProxy 2.7/2.6 Anfrage/Antwort Smuggling, wenn der HTX-Parser pipelined Anfragen falsch handhabte. +* **CVE-2022-41721** – Go `MaxBytesHandler` verursachte, dass übrig gebliebene Body-Bytes als **HTTP/2**-Frames geparst wurden, was Cross-Protocol Smuggling ermöglichte. + +--- +## Werkzeuge + +* **Burp Request Smuggler** – seit v1.26 testet es automatisch H2.TE/H2.CL und versteckte ALPN-Unterstützung. Aktiviere „HTTP/2-Probing“ in den Erweiterungsoptionen. +* **h2cSmuggler** – Python PoC von Bishop Fox zur Automatisierung des Klartext-Upgrade-Angriffs: +```bash +python3 h2csmuggler.py -u https://target -x 'GET /admin HTTP/1.1\r\nHost: target\r\n\r\n' +``` +* **curl**/`hyper` – manuelles Erstellen von Payloads: `curl --http2-prior-knowledge -X POST --data-binary @payload.raw https://target`. + +--- +## Verteidigungsmaßnahmen + +1. **End-to-End HTTP/2** – die Downgrade-Übersetzung vollständig eliminieren. +2. **Einzige Quelle der Längenwahrheit** – beim Downgrade *immer* eine gültige `Content-Length` **erzeugen** **und** alle benutzereingereichten `Content-Length`/`Transfer-Encoding`-Header **entfernen**. +3. **Normalisieren vor der Route** – Header-Sanitization *vor* der Routing-/Umschreibelogik anwenden. +4. **Verbindungsisolierung** – keine Back-End-TCP-Verbindungen zwischen Benutzern wiederverwenden; „eine Anfrage pro Verbindung“ besiegt warteschlangenbasierte Exploits. +5. **`Upgrade` entfernen, es sei denn WebSocket** – verhindert h2c-Tunneling. + +--- +## Referenzen + +* PortSwigger Research – “HTTP/2: The Sequel is Always Worse” +* Bishop Fox – “h2c Smuggling: request smuggling via HTTP/2 clear-text” {{#include ../../banners/hacktricks-training.md}}