Contournement des protections SSRF

Bonjour,

Cela fait un moment que je n'ai pas posté. Je voulais partager un contournement SSRF soigné que j'ai trouvé en chassant sur un programme privé.

SSRF signifie falsification de requête côté serveur. La contrefaçon de requête côté serveur permet à un attaquant d'abuser des requêtes HTTP pour demander des informations sur le serveur en interne ou sur le réseau interne.

Choses à surveiller? Des paramètres tels que url= next= host= image= img= etc. Tout ce qui semble faire une requête Web à un serveur. Cela peut alors être abusé pour pointer la demande en interne.

Comment ai-je trouvé le point final vulnérable ?

Alors que je chassais dans le cadre d'un programme privé, je faisais une reconnaissance approfondie. J'avais rassemblé une énorme liste de sous-domaines, principalement tirés de censys. Après cela, j'ai forcé brutalement et recherché dans la machine de cheminement des URL sur tous les hôtes. À l'époque, ssrf était mon objectif, j'ai donc rassemblé mon répertoire et la sortie de mon point de terminaison et j'ai recherché "proxy.php". Heureusement, j'ai eu un coup.

Lors de l'étude de la requête, il s'agissait d'effectuer une requête HTTP sortante vers une URL spécifiée. Si j'ai entré mon lien de collaborateur burp, je n'ai pas reçu de recherche. J'ai essayé les bases habituelles, en entrant 127.0.0.1 et les notations IP des hôtes internes, chaque demande était bloquée à moins que la demande ne contienne le nom d'hôte des sites Web.

C'est là que les choses deviennent techniques. lors de l'envoi d'une demande par exemple avec mon collaborateur burp, parallèlement au formatage des informations d'identification du navigateur, par exemple url=https: //hostnameofwebsite.com@myburpcollablink , j'ai reçu un retour.

J'ai ensuite essayé d'exploiter cela en le modifiant car actuellement, ce qui précède utilisait le navigateur pour envoyer le nom d'hôte du site Web en tant qu'informations d'identification à myburpcollablink, ce qui n'était pas bon.

Je venais de voir récemment une vidéo ssrf sur google où il était expliqué que si vous utilisiez un \ cela arrêterait l'analyse sur le backend après le premier hôte. Le front-end interpréterait la demande comme hostnameofwebsite comme des informations d'identification pour myburpcollablink mais le backend traiterait uniquement la demande frontale donc hostnameofwebsite. Ici, je l'ai changé et j'ai utilisé url=http://169.254.1698.254\@hostnameofwebsite.

Expliquons-nous. 169.254 est l'adresse IP interne des métadonnées AWS. La demande frontale considère cela comme 169.254 comme informations d'identification pour le nom d'hôte du site Web, qui passe la vérification frontale car le nom d'hôte du site Web doit figurer dans la demande. Le backend ignore ce format et traite commehttp://169.254.169.254\qui coupe ensuite et transmet juste la demande.

Fermé comme résolu