Translated ['src/mobile-pentesting/ios-pentesting/ios-pentesting-without

This commit is contained in:
Translator 2025-07-12 18:09:02 +00:00
parent c84d5a969e
commit ce95a484fb
2 changed files with 100 additions and 5 deletions

View File

@ -10,6 +10,7 @@ Cependant, ce n'est pas aussi simple que de simplement extraire l'IPA, de le re-
Avec un ancien appareil jailbreaké, il est possible d'installer l'IPA, **de le déchiffrer en utilisant votre outil préféré** (comme Iridium ou frida-ios-dump), et de le récupérer de l'appareil. Cependant, si possible, il est recommandé de demander simplement au client l'IPA déchiffré.
## Obtenir l'IPA déchiffré
### Obtenez-le d'Apple
@ -23,6 +24,7 @@ Avec un ancien appareil jailbreaké, il est possible d'installer l'IPA, **de le
Vérifiez [https://dvuln.com/blog/modern-ios-pentesting-no-jailbreak-needed](https://dvuln.com/blog/modern-ios-pentesting-no-jailbreak-needed) pour des informations plus détaillées sur ce processus.
### Déchiffrer l'application
Pour déchiffrer l'IPA, nous allons l'installer. Cependant, si vous avez un ancien iPhone jailbreaké, il est possible que sa version ne soit pas prise en charge par l'application, car généralement les applications ne prennent en charge que les dernières versions.
@ -71,7 +73,7 @@ Le mode développeur reste actif jusqu'à ce que vous le désactiviez ou que vou
### Options modernes de sideloading
Il existe maintenant plusieurs façons matures de sideloader et de maintenir les IPAs re-signés à jour sans jailbreak :
Il existe maintenant plusieurs méthodes matures pour sideloader et maintenir les IPAs re-signés à jour sans jailbreak :
| Outil | Exigences | Forces | Limitations |
|-------|-----------|--------|-------------|
@ -94,7 +96,7 @@ Les récentes versions de Frida (>=16) gèrent automatiquement l'authentificatio
### Analyse dynamique automatisée avec MobSF (sans jailbreak)
[MobSF](https://mobsf.github.io/Mobile-Security-Framework-MobSF/) peut instrumenter un IPA signé par un développeur sur un appareil réel en utilisant la même technique (`get_task_allow`) et fournit une interface web avec un navigateur de système de fichiers, capture de trafic et console Frida【】. Le moyen le plus rapide est de faire fonctionner MobSF dans Docker, puis de connecter votre iPhone via USB :
[MobSF](https://mobsf.github.io/Mobile-Security-Framework-MobSF/) peut instrumenter un IPA signé par un développeur sur un appareil réel en utilisant la même technique (`get_task_allow`) et fournit une interface web avec un navigateur de système de fichiers, capture de trafic et console Frida【†L2-L3】. Le moyen le plus rapide est de faire fonctionner MobSF dans Docker, puis de connecter votre iPhone via USB :
```bash
docker pull opensecurity/mobile-security-framework-mobsf:latest
docker run -p 8000:8000 --privileged \
@ -106,7 +108,7 @@ MobSF déploiera automatiquement le binaire, activera un serveur Frida à l'int
### iOS 17 & avertissements sur le mode verrouillage
* **Mode verrouillage** (Réglages → Confidentialité & Sécurité) bloque le chargeur dynamique de charger des bibliothèques dynamiques non signées ou signées de manière externe. Lors de tests sur des appareils qui pourraient avoir ce mode activé, assurez-vous qu'il est **désactivé** ou vos sessions Frida/objection se termineront immédiatement.
* **Mode verrouillage** (Réglages → Confidentialité & Sécurité) bloque le chargeur dynamique de chargement des bibliothèques dynamiques non signées ou signées de manière externe. Lors de tests sur des appareils qui pourraient avoir ce mode activé, assurez-vous qu'il est **désactivé** ou vos sessions Frida/objection se termineront immédiatement.
* L'authentification par pointeur (PAC) est appliquée à l'échelle du système sur les appareils A12+. Frida ≥16 gère de manière transparente le stripping PAC — il suffit de garder à jour à la fois *frida-server* et la chaîne d'outils Python/CLI lorsque qu'une nouvelle version majeure d'iOS est publiée.
## Références

View File

@ -1,7 +1,100 @@
# Request Smuggling dans les Downgrades HTTP/2
# Request Smuggling in HTTP/2 Downgrades
{{#include ../../banners/hacktricks-training.md}}
**Vérifiez le post [https://portswigger.net/research/http-2-downgrades](https://portswigger.net/research/http-2-downgrades)**
HTTP/2 est généralement considéré comme immunisé contre le request-smuggling classique car la longueur de chaque trame DATA est explicite. **Cette protection disparaît dès qu'un proxy frontal “downgrade” la requête en HTTP/1.x avant de l'envoyer à un back-end**. Au moment où deux parseurs différents (le front-end HTTP/2 et le back-end HTTP/1) essaient de s'accorder sur l'endroit où une requête se termine et où la suivante commence, tous les anciens trucs de désynchronisation reviennent plus quelques nouveaux.
---
## Pourquoi les downgrades se produisent
1. Les navigateurs parlent déjà HTTP/2, mais une grande partie de l'infrastructure d'origine héritée ne comprend encore que HTTP/1.1.
2. Les reverse-proxies (CDNs, WAFs, load-balancers) terminent donc TLS + HTTP/2 à la périphérie et **réécrivent chaque requête en HTTP/1.1** pour l'origine.
3. L'étape de traduction doit créer *à la fois* des en-têtes `Content-Length` **et/ou** `Transfer-Encoding: chunked` afin que l'origine puisse déterminer la longueur du corps.
Chaque fois que le front-end fait confiance à la longueur de la trame HTTP/2 **mais** que le back-end fait confiance à CL ou TE, un attaquant peut les forcer à ne pas être d'accord.
---
## Deux classes primitives dominantes
| Variante | Longueur front-end | Longueur back-end | Charge utile typique |
|---------|-----------------|-----------------|-----------------|
| **H2.TE** | Trame HTTP/2 | `Transfer-Encoding: chunked` | Intégrer un corps de message chunked supplémentaire dont le final `0\r\n\r\n` n'est *pas* envoyé, de sorte que le back-end attende la “prochaine” requête fournie par l'attaquant. |
| **H2.CL** | Trame HTTP/2 | `Content-Length` | Envoyer un CL *plus petit* que le vrai corps, de sorte que le back-end lise au-delà de la limite dans la requête suivante. |
> Celles-ci sont identiques en esprit aux classiques TE.CL / CL.TE, juste avec HTTP/2 remplaçant l'un des parseurs.
---
## Identification d'une chaîne de downgrade
1. Utilisez **ALPN** dans une poignée de main TLS (`openssl s_client -alpn h2 -connect host:443`) ou **curl** :
```bash
curl -v --http2 https://target
```
Si `* Using HTTP2` apparaît, la périphérie parle H2.
2. Envoyez une requête CL/TE délibérément malformée *sur* HTTP/2 (Burp Repeater a maintenant un menu déroulant pour forcer HTTP/2). Si la réponse est une erreur HTTP/1.1 telle que `400 Bad chunk`, vous avez la preuve que la périphérie a converti le trafic pour un parseur HTTP/1 en aval.
---
## Workflow d'exploitation (exemple H2.TE)
```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. Le **front-end** lit exactement 13 octets (`HELLO\r\n0\r\n\r\nGE`), pense que la requête est terminée et transmet cette quantité à l'origine.
2. Le **back-end** fait confiance à l'en-tête TE, continue de lire jusqu'à ce qu'il voit le *deuxième* `0\r\n\r\n`, consommant ainsi le préfixe de la deuxième requête de l'attaquant (`GET /admin …`).
3. Le reste (`GET /admin …`) est traité comme une *nouvelle* requête mise en file d'attente derrière celle de la victime.
Remplacez la requête dissimulée par :
* `POST /api/logout` pour forcer la fixation de session
* `GET /users/1234` pour voler une ressource spécifique à la victime
---
## h2c smuggling (mises à niveau en texte clair)
Une étude de 2023 a montré que si un front-end passe l'en-tête HTTP/1.1 `Upgrade: h2c` à un back-end qui prend en charge HTTP/2 en texte clair, un attaquant peut tunneliser des *trames* HTTP/2 brutes à travers un edge qui ne validait que HTTP/1.1. Cela contourne la normalisation des en-têtes, les règles WAF et même la terminaison TLS.
Exigences clés :
* L'edge transmet **à la fois** `Connection: Upgrade` et `Upgrade: h2c` sans changement.
* L'origine passe à HTTP/2 et conserve la sémantique de réutilisation de connexion qui permet la mise en file d'attente des requêtes.
L'atténuation est simple : supprimer ou coder en dur l'en-tête `Upgrade` à l'edge sauf pour les WebSockets.
---
## CVEs notables dans le monde réel (2022-2025)
* **CVE-2023-25690** Les règles de réécriture mod_proxy d'Apache HTTP Server pourraient être enchaînées pour le fractionnement et le smuggling de requêtes. (corrigé dans 2.4.56)
* **CVE-2023-25950** Smuggling de requêtes/réponses HAProxy 2.7/2.6 lorsque le parseur HTX gérait mal les requêtes en pipeline.
* **CVE-2022-41721** Le `MaxBytesHandler` de Go a causé des octets de corps restants à être analysés comme des **trames HTTP/2**, permettant le smuggling inter-protocoles.
---
## Outils
* **Burp Request Smuggler** depuis v1.26, il teste automatiquement H2.TE/H2.CL et le support ALPN caché. Activez "HTTP/2 probing" dans les options de l'extension.
* **h2cSmuggler** PoC Python par Bishop Fox pour automatiser l'attaque de mise à niveau en texte clair :
```bash
python3 h2csmuggler.py -u https://target -x 'GET /admin HTTP/1.1\r\nHost: target\r\n\r\n'
```
* **curl**/`hyper` création de charges utiles manuelles : `curl --http2-prior-knowledge -X POST --data-binary @payload.raw https://target`.
---
## Mesures défensives
1. **HTTP/2 de bout en bout** éliminer complètement la traduction de rétrogradation.
2. **Source unique de vérité sur la longueur** lors de la rétrogradation, *générez toujours* un `Content-Length` valide **et** **supprimez** tous les en-têtes `Content-Length`/`Transfer-Encoding` fournis par l'utilisateur.
3. **Normaliser avant le routage** appliquer la sanitation des en-têtes *avant* la logique de routage/réécriture.
4. **Isolation de connexion** ne pas réutiliser les connexions TCP back-end entre les utilisateurs ; "une requête par connexion" contrecarrerait les exploits basés sur la file d'attente.
5. **Supprimer `Upgrade` sauf WebSocket** empêche le tunneling h2c.
---
## Références
* PortSwigger Research “HTTP/2: The Sequel is Always Worse” <https://portswigger.net/research/http2>
* Bishop Fox “h2c Smuggling: request smuggling via HTTP/2 clear-text” <https://bishopfox.com/blog/h2c-smuggling-request>
{{#include ../../banners/hacktricks-training.md}}