Entwickler meistern Sicherheit: Share & Learn-Reihe – CRLF-Injektion

Bei Blogs oder Artikeln wie diesem helfen Satzzeichen dem Leser bei der Orientierung. Punkte zeigen beispielsweise das Ende eines Satzes an, während Kommas entweder Aufzählungen gliedern oder bewusste Pausen setzen, um Gedanken voneinander abzugrenzen. In einem gut geschriebenen Blog (wie diesem) sind die Satzzeichen fast unsichtbar – sie sind einfach Teil des grundlegenden Codes, den wir alle vor vielen Jahren gelernt haben zu verarbeiten.

Doch was passiert, wenn ein Hacker in diesen Artikel eindringt und an den falschen Stellen seltsame Satzzeichen einfügt? Etwa so:

Ohne,dass! sich. der, Text. ändert? kann. es! die, Verarbeitung? der. Informationen! deutlich? erschweren!

Genau das passiert im Grunde bei einem CRLF-Injection-Angriff. Die Buchstaben CRLF stehen für „Carriage Return“ (Wagenrücklauf) und „Line Feed“ (Zeilenvorschub), die einzeln oder zusammen verwendet werden, um das Ende einer Zeile zu markieren. Wenn es einem Angreifer gelingt, einen CR- oder LF-Code in eine bestehende Anwendung einzuschleusen, kann er unter Umständen deren Verhalten verändern. Die Auswirkungen sind im Vergleich zu den meisten anderen Angriffen schwerer vorhersehbar, können für das betroffene Unternehmen jedoch ebenso gefährlich sein.

In dieser Folge erfahren Sie:

• Wie Angreifer eine CRLF-Injection auslösen können
• Warum CRLF-Injections gefährlich sind
• Techniken zur Behebung dieser Schwachstelle.

Wie lösen Angreifer eine CRLF-Injection aus?

Das Einschleusen von CRLF-Zeichen in bestehenden Code mit dem Ziel, ein spezifisches Ergebnis zu erzielen, ist ziemlich schwierig, wenn auch nicht unmöglich. Erschwert wird dies dadurch, dass ein Angreifer je nach Betriebssystem und anderen Faktoren des Zielsystems unterschiedliche CRLF-Kombinationen verwenden muss. Moderne Windows-Systeme benötigen beispielsweise sowohl CR als auch LF, um eine Zeile zu beenden, während unter Linux nur der LF-Code erforderlich ist. HTTP-Anfragen erfordern immer einen präzisen CRLF-Code als Zeilenende.

Abgesehen davon, dass CRLF-Angriffe schwer umzusetzen sind und ihre Ergebnisse noch schwerer vorhersehbar sind, werden sie ähnlich eingeleitet wie andere Injection-Angriffe. Ein böswilliger Nutzer gibt einfach Daten in einen Bereich einer Website oder Anwendung ein, der dies zulässt, fügt jedoch anstelle oder nach den normalen Eingabedaten den CRLF-Code ein.

Ein Angreifer könnte beispielsweise den ASCII-Code für einen Wagenrücklauf (%0d) gefolgt vom ASCII-Code für einen Zeilenvorschub (%0a) am Ende eines HTTPS-Headers eingeben. Die gesamte Abfrage würde dann so aussehen:

https://validsite.com/index.php?page=home%0d%0a

Wenn die Daten nicht bereinigt oder gefiltert werden, könnte der obige Code dazu führen, dass in der Zielanwendung oder auf der Website unerwartete Dinge geschehen.

Warum sind CRLF-Injections gefährlich?

Obwohl CRLF-Injection-Angriffe weniger präzise sind als die meisten anderen, können sie durchaus gefährlich sein. Im harmlosesten Fall kann eine zusätzliche Zeile die Protokolldateien verfälschen, was automatische Sicherheitsmechanismen dazu veranlassen könnte, Administratoren vor einem nicht existierenden Problem zu warnen. Dies könnte jedoch dazu genutzt werden, Ressourcen von einem tatsächlichen Angriff abzulenken, der gleichzeitig stattfindet.

CRLF-Angriffe können aber auch direkten Schaden anrichten. Wenn eine Anwendung beispielsweise so konzipiert ist, dass sie Befehle akzeptiert und dann nach einer bestimmten Datei sucht, könnte das Hinzufügen eines CRLF-Codes zur Abfrage dazu führen, dass die Anwendung diesen Prozess auf dem Bildschirm anzeigt, anstatt ihn zu verbergen. Dies könnte einem Angreifer wertvolle Informationen liefern.

CRLF-Injections können auch für sogenannte Response-Splitting-Angriffe verwendet werden, bei denen die Zeilenumbruch-Codes eine gültige Antwort in mehrere Teile zerlegen. Dies kann Hackern die Kontrolle über den Header nach dem CRLF-Code geben, was zum Einschleusen von zusätzlichem Code genutzt werden kann. Es kann auch dazu dienen, eine Lücke zu schaffen, durch die der Angreifer eigenen Code vollständig einschleusen und wahrscheinlich eine weitere Angriffsform in jeder Zeile auslösen kann, die auf den durch den CRLF-Angriff unterbrochenen Teil folgt.

Beseitigung der CRLF-Injection-Schwachstelle

Wenn es eine zentrale Botschaft gibt, die man aus dieser Serie mitnehmen sollte, dann diese: Vertrauen Sie niemals, wirklich niemals, einer Benutzereingabe. Die meisten Schwachstellen, die wir in dieser Serie behandelt haben, betrafen auf die eine oder andere Weise Benutzereingabebereiche, und die CRLF-Injection-Lücke bildet da keine Ausnahme.

Überall dort, wo Benutzereingaben möglich sind, müssen Filter eingesetzt werden, um die Einschleusung von nicht autorisiertem Code zu verhindern, der von der Anwendung oder dem Server falsch interpretiert werden könnte. Bei CRLF-Angriffen ist die Absicherung von HTTP-Headern besonders wichtig, aber auch GET- und POST-Parameter sowie Cookies dürfen nicht vernachlässigt werden. Eine hervorragende Methode, um CRLF-Codes gezielt daran zu hindern, weitere Injektionen zu ermöglichen, ist die HTML-Kodierung aller an den Browser des Benutzers gesendeten Daten.

Weitere Informationen zu CRLF-Injektionen

Weiterführende Informationen finden Sie in den OWASP-Richtlinien zu CRLF-Injektionen. Sie können Ihr neu erworbenes Wissen zur Abwehr auch direkt mit der kostenlosen Demo der Secure Code Warrior-Plattform testen, die Cybersicherheitsteams zu echten Experten ausbildet. Um mehr über die Bekämpfung dieser und vieler weiterer Bedrohungen zu erfahren, besuchen Sie den Secure Code Warrior-Blog.