diff --git a/src/pentesting-web/crlf-0d-0a.md b/src/pentesting-web/crlf-0d-0a.md index 769b621ff..bd3abbf47 100644 --- a/src/pentesting-web/crlf-0d-0a.md +++ b/src/pentesting-web/crlf-0d-0a.md @@ -4,7 +4,7 @@ ### CRLF -Carriage Return (CR) und Line Feed (LF), zusammen bekannt als CRLF, 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 Körper einer Antwort zu unterscheiden. Diese Zeichen werden universell in HTTP/1.1-Kommunikationen über verschiedene Webserver-Typen hinweg eingesetzt, wie z.B. Apache und Microsoft IIS. +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 Körper einer Antwort zu unterscheiden. Diese Zeichen werden universell in HTTP/1.1-Kommunikationen über verschiedene Webserver-Typen hinweg eingesetzt, wie z.B. Apache und Microsoft IIS. ### CRLF Injection Vulnerability @@ -14,7 +14,7 @@ CRLF-Injection beinhaltet das Einfügen von CR- und LF-Zeichen in vom Benutzer b [Example from here](https://www.invicti.com/blog/web-security/crlf-http-header/) -Betrachten Sie eine Protokolldatei in einem Admin-Panel, die das Format `IP - Zeit - Besucht Pfad` folgt. Ein typischer Eintrag könnte so aussehen: +Betrachten Sie eine Protokolldatei in einem Admin-Panel, die das Format: `IP - Zeit - Besuchter Pfad` hat. Ein typischer Eintrag könnte so aussehen: ``` 123.123.123.123 - 08:15 - /index.php?page=home ``` @@ -29,7 +29,7 @@ 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 erscheinen lässt, als ob der localhost (eine Entität, die typischerweise im Serverumfeld vertraut ist) die Aktionen ausgeführt hat. Der Server interpretiert den Teil der Abfrage, der mit `%0d%0a` beginnt, als einen einzelnen Parameter, während der `restrictedaction`-Parameter als eine andere, separate Eingabe geparst wird. Die manipulierte Abfrage ahmt effektiv einen legitimen administrativen Befehl nach: `/index.php?page=home&restrictedaction=edit` +Der Angreifer tarnt somit seine bösartigen Aktivitäten, indem er es so erscheinen lässt, als ob der localhost (eine Entität, die typischerweise im Serverumfeld vertraut ist) die Aktionen ausgeführt hat. Der Server interpretiert den Teil der Abfrage, der mit `%0d%0a` beginnt, als einen einzelnen Parameter, während der `restrictedaction`-Parameter als eine andere, separate Eingabe analysiert wird. Die manipulierte Abfrage ahmt effektiv einen legitimen administrativen Befehl nach: `/index.php?page=home&restrictedaction=edit` ### HTTP Response Splitting @@ -68,15 +68,13 @@ Sie können die Payload **innerhalb des URL-Pfads** senden, um die **Antwort** v 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 ``` -Check more examples in: - {{#ref}} https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md {{#endref}} ### HTTP Header Injection -HTTP Header Injection, oft ausgenutzt durch CRLF (Carriage Return und Line Feed) Injection, ermöglicht es Angreifern, HTTP-Header einzufügen. Dies kann Sicherheitsmechanismen wie XSS (Cross-Site Scripting) Filter oder die SOP (Same-Origin Policy) untergraben, was potenziell zu unbefugtem Zugriff auf sensible Daten, wie CSRF-Tokens, oder zur Manipulation von Benutzersitzungen durch Cookie-Platzierung führen kann. +HTTP Header Injection, das oft durch CRLF (Carriage Return und Line Feed) Injection ausgenutzt wird, ermöglicht es Angreifern, HTTP-Header einzufügen. Dies kann Sicherheitsmechanismen wie XSS (Cross-Site Scripting) Filter oder die SOP (Same-Origin Policy) untergraben, was potenziell zu unbefugtem Zugriff auf sensible Daten, wie CSRF-Tokens, oder zur Manipulation von Benutzersitzungen durch Cookie-Platzierung führen kann. #### Ausnutzen von CORS über HTTP Header Injection @@ -84,7 +82,7 @@ Ein Angreifer kann HTTP-Header injizieren, um CORS (Cross-Origin Resource Sharin #### SSRF und HTTP Request Injection über CRLF -CRLF-Injection kann genutzt werden, um eine völlig neue HTTP-Anfrage zu erstellen und einzufügen. Ein bemerkenswertes Beispiel hierfür ist die Schwachstelle in PHPs `SoapClient`-Klasse, insbesondere im `user_agent`-Parameter. Durch Manipulation dieses Parameters kann ein Angreifer zusätzliche Header und Body-Inhalte einfügen oder sogar eine neue HTTP-Anfrage vollständig injizieren. Unten ist ein PHP-Beispiel, das diese Ausnutzung demonstriert: +CRLF-Injection kann genutzt werden, um eine völlig neue HTTP-Anfrage zu erstellen und einzufügen. Ein bemerkenswertes Beispiel dafür ist die Schwachstelle in PHPs `SoapClient`-Klasse, insbesondere im `user_agent`-Parameter. Durch Manipulation dieses Parameters kann ein Angreifer zusätzliche Header und Body-Inhalte einfügen oder sogar eine neue HTTP-Anfrage vollständig injizieren. Unten ist ein PHP-Beispiel, das diese Ausnutzung demonstriert: ```php $target = 'http://127.0.0.1:9090/test'; $post_string = 'variable=post value'; @@ -111,7 +109,7 @@ $client->__soapCall("test", []); ``` ### Header Injection zu Request Smuggling -Für weitere Informationen zu dieser Technik und potenziellen Problemen [**prüfen Sie die ursprüngliche Quelle**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning). +Für weitere Informationen zu dieser Technik und möglichen Problemen [**prüfen Sie die Originalquelle**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning). Sie können essentielle Header injizieren, um sicherzustellen, dass der **Back-End die Verbindung offen hält**, nachdem auf die ursprüngliche Anfrage geantwortet wurde: ``` @@ -125,37 +123,37 @@ Nachfolgend kann eine zweite Anfrage spezifiziert werden. Dieses Szenario beinha `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. **Erstellen eines Präfixes für das Vergiften der Antwortwarteschlange**: Dieser Ansatz beinhaltet das Erstellen eines Präfixes, das, wenn es mit nachfolgendem Müll kombiniert wird, eine vollständige zweite Anfrage bildet. Dies kann das Vergiften der Antwortwarteschlange auslösen. Ein Beispiel ist: +2. **Crafting a Prefix for Response Queue Poisoning**: Dieser Ansatz beinhaltet die Erstellung eines Präfixes, das, wenn es mit nachfolgendem Müll kombiniert wird, eine vollständige zweite Anfrage bildet. Dies kann das Vergiften 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 Injection -Memcache ist ein **Key-Value-Store, der ein Klartextprotokoll verwendet**. Weitere Informationen finden Sie in: +Memcache ist ein **key-value store, der ein Klartextprotokoll verwendet**. Weitere Informationen finden Sie in: {{#ref}} ../network-services-pentesting/11211-memcache/ {{#endref}} -**Für die vollständigen Informationen lesen Sie die**[ **ursprüngliche Beschreibung**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/) +**Für die vollständigen Informationen lesen Sie die**[ **originale Ausarbeitung**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/) -Wenn eine Plattform **Daten aus einer HTTP-Anfrage entnimmt und diese ohne Bereinigung** verwendet, um **Anfragen** an einen **Memcache**-Server zu stellen, könnte ein Angreifer dieses Verhalten ausnutzen, um **neue Memcache-Befehle einzufügen**. +Wenn eine Plattform **Daten aus einer HTTP-Anfrage entnimmt und diese ohne Bereinigung verwendet**, um **Anfragen** an einen **memcache**-Server zu stellen, könnte ein Angreifer dieses Verhalten ausnutzen, um **neue memcache-Befehle einzufügen**. -Zum Beispiel wurden in der ursprünglich entdeckten Schwachstelle Cache-Schlüssel verwendet, um die IP und den Port zurückzugeben, mit dem sich ein Benutzer verbinden sollte, und Angreifer konnten **Memcache-Befehle injizieren**, die den **Cache vergifteten**, um die **Details der Opfer** (einschließlich Benutzernamen und Passwörter) an die Server des Angreifers zu senden: +Zum Beispiel wurden in der ursprünglich entdeckten Schwachstelle Cache-Schlüssel verwendet, um die IP und den Port zurückzugeben, mit dem sich ein Benutzer verbinden sollte, und Angreifer konnten **memcache-Befehle injizieren**, die den **Cache vergifteten**, um die **Details der Opfer** (Benutzernamen und Passwörter eingeschlossen) an die Server des Angreifers zu senden:
https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop
-Darüber hinaus entdeckten Forscher auch, dass sie die Memcache-Antworten desynchronisieren konnten, um die IP und Ports der Angreifer an Benutzer zu senden, deren E-Mail der Angreifer nicht kannte: +Darüber hinaus entdeckten Forscher auch, dass sie die memcache-Antworten desynchronisieren konnten, um die IP und Ports der Angreifer an Benutzer zu senden, deren E-Mail der Angreifer nicht kannte:
https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop
-### So verhindern Sie CRLF / HTTP-Header-Injektionen in Webanwendungen +### Wie man CRLF / HTTP Header Injektionen in Webanwendungen verhindert -Um die Risiken von CRLF (Carriage Return und Line Feed) oder HTTP-Header-Injektionen in Webanwendungen zu mindern, werden die folgenden Strategien empfohlen: +Um die Risiken von CRLF (Carriage Return und Line Feed) oder HTTP Header Injektionen in Webanwendungen zu mindern, werden die folgenden Strategien empfohlen: -1. **Vermeiden Sie direkte Benutzereingaben in Antwort-Headern:** Der sicherste Ansatz besteht darin, Benutzereingaben nicht direkt in Antwort-Headern zu verwenden. +1. **Vermeiden Sie direkte Benutzereingaben in Antwort-Headern:** Der sicherste Ansatz besteht darin, Benutzereingaben nicht direkt in Antwort-Header zu integrieren. 2. **Kodieren Sie Sonderzeichen:** Wenn es nicht möglich ist, direkte Benutzereingaben zu vermeiden, stellen Sie sicher, dass Sie eine Funktion verwenden, die speziell für die Kodierung von Sonderzeichen wie CR (Carriage Return) und LF (Line Feed) zuständig ist. Diese Praxis verhindert die Möglichkeit einer CRLF-Injektion. -3. **Aktualisieren Sie die Programmiersprache:** Aktualisieren Sie regelmäßig die in Ihren Webanwendungen verwendete Programmiersprache auf die neueste Version. Wählen Sie eine Version, die das Einfügen von CR- und LF-Zeichen in Funktionen, die für das Setzen von HTTP-Headern zuständig sind, von vornherein verbietet. +3. **Aktualisieren Sie die Programmiersprache:** Aktualisieren Sie regelmäßig die in Ihren Webanwendungen verwendete Programmiersprache auf die neueste Version. Wählen Sie eine Version, die das Injizieren von CR- und LF-Zeichen innerhalb von Funktionen, die für das Setzen von HTTP-Headern zuständig sind, von vornherein verbietet. ### CHEATSHEET @@ -181,20 +179,57 @@ Um die Risiken von CRLF (Carriage Return und Line Feed) oder HTTP-Header-Injekti • %E5%98%BC = %3C = \u563c (<) • Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test ``` +### Aktuelle Schwachstellen (2023 – 2025) + +In den letzten Jahren wurden mehrere hochgradige CRLF/HTTP-Header-Injection-Fehler in weit verbreiteten Server- und Client-Komponenten entdeckt. Die lokale Reproduktion und Untersuchung dieser Fehler ist eine hervorragende Möglichkeit, um reale Ausnutzungsmuster zu verstehen. + +| Jahr | Komponente | CVE / Advisory | Grundursache | PoC-Hervorhebung | +|------|-----------|---------------|--------------|------------------| +| 2024 | RestSharp (≥110.0.0 <110.2.0) | **CVE-2024-45302** | Der `AddHeader()`-Helfer hat CR/LF nicht bereinigt, was die Konstruktion mehrerer Anforderungsheader ermöglichte, wenn RestSharp als HTTP-Client in Backend-Diensten verwendet wird. Nachgelagerte Systeme könnten zu SSRF oder Request Smuggling gezwungen werden. | `client.AddHeader("X-Foo","bar%0d%0aHost:evil")` | +| 2024 | Refit (≤ 7.2.101) | **CVE-2024-51501** | Header-Attribute in Schnittstellenmethoden wurden wörtlich in die Anfrage kopiert. Durch das Einbetten von `%0d%0a` konnten Angreifer beliebige Header oder sogar eine zweite Anfrage hinzufügen, wenn Refit von serverseitigen Worker-Jobs verwendet wurde. | `[Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")]` | +| 2023 | Apache APISIX Dashboard | **GHSA-4h3j-f5x9-r6x3** | Der vom Benutzer bereitgestellte `redirect`-Parameter wurde ohne Kodierung in einen `Location:`-Header zurückgegeben, was eine offene Umleitung + Cache-Vergiftung ermöglichte. | `/login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a` | + +Diese Fehler sind wichtig, da sie **innerhalb des Anwendungscodes** ausgelöst werden und nicht nur am Rand des Webservers. Jedes interne Element, das HTTP-Anfragen durchführt oder Antwortheader setzt, muss daher CR/LF-Filterung durchsetzen. + +### Fortgeschrittene Unicode / Steuerzeichen-Umgehungen + +Moderne WAF/Umformungsstacks entfernen oft das literale `\r`/`\n`, vergessen jedoch andere Zeichen, die viele Backends als Zeilenbegrenzer behandeln. Wenn CRLF gefiltert wird, versuchen Sie: + +* `%E2%80%A8` (`U+2028` – ZEILENBEGRENZER) +* `%E2%80%A9` (`U+2029` – ABSATZBEGRENZER) +* `%C2%85` (`U+0085` – NÄCHSTE ZEILE) + +Einige Java-, Python- und Go-Frameworks konvertieren diese während der Header-Analyse in `\n` (siehe die Praetorian-Forschung von 2023). Kombinieren Sie sie mit klassischen Payloads: +``` +/%0A%E2%80%A8Set-Cookie:%20admin=true +``` +Wenn der Filter zuerst UTF-8 normalisiert, wird das Steuerzeichen in einen regulären Zeilenumbruch umgewandelt und der injizierte Header wird akzeptiert. + +### WAF-Evasion über den Trick mit doppeltem `Content-Encoding` (2023) + +Die Forscher von Praetorian zeigten auch, dass durch Injektion: +``` +%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a +``` +in einen reflektierten Header ignorieren Browser den vom Server bereitgestellten Body und rendern den vom Angreifer bereitgestellten HTML-Code, der folgt, was gespeichertes XSS ermöglicht, selbst wenn der eigene Inhalt der Anwendung inert ist. Da `Content-Encoding: identity` von RFC 9110 erlaubt ist, leiten viele Reverse-Proxys es unverändert weiter. + ## Automatische Werkzeuge -- [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) -- [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz) +* [CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) – schneller aktiver Scanner, geschrieben in Go. +* [crlfuzz](https://github.com/dwisiswant0/crlfuzz) – auf Wortlisten basierender Fuzzer, der Unicode-Zeilenumbruch-Payloads unterstützt. +* [crlfix](https://github.com/glebarez/crlfix) – 2024 Dienstprogramm, das HTTP-Anfragen, die von Go-Programmen generiert werden, patcht und eigenständig verwendet werden kann, um interne Dienste zu testen. -## Brute-Force Erkennungsliste +## Brute-Force-Erkennungsliste -- [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt) +- [carlospolop/Auto_Wordlists – crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt) ## Referenzen -- [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/) -- [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/) -- [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning) -- [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/) +- [https://www.invicti.com/blog/web-security/crlf-http-header/](https://www.invicti.com/blog/web-security/crlf-http-header/) +- [https://www.acunetix.com/websitesecurity/crlf-injection/](https://www.acunetix.com/websitesecurity/crlf-injection/) +- [https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning) +- [https://www.netsparker.com/blog/web-security/crlf-http-header/](https://www.netsparker.com/blog/web-security/crlf-http-header/) +- [https://nvd.nist.gov/vuln/detail/CVE-2024-45302](https://nvd.nist.gov/vuln/detail/CVE-2024-45302) +- [https://security.praetorian.com/blog/2023-unicode-newlines-bypass/](https://security.praetorian.com/blog/2023-unicode-newlines-bypass/) {{#include ../banners/hacktricks-training.md}}