Programmierer erobern die Sicherheit: Serie „Teilen und Lernen“ — CRLF Injection

Bei Blogs oder Artikeln wie diesem werden die Leser durch Satzzeichen unterstützt. Beispielsweise teilen Punkte den Lesern mit, wo ein Satz endet, während Kommas entweder Artikel in Listen trennen oder harte Pausen einfügen, um Ideen voneinander zu trennen. Bei einem gut geschriebenen Blog (wie diesem) ist die Interpunktion fast unsichtbar, sie ist nur ein Teil des Standard-Hintergrundcodes, den wir alle vor vielen Jahren zu verarbeiten gelernt haben.

Aber was passiert, wenn ein Hacker in diesen Artikel gerät und seltsame Satzzeichen an den falschen Stellen einfügt? So wie das:

Sogar ohne! ändern. das, texten... es? kann. schaffe es! viel? schwieriger. Zu? verarbeiten! die, Information!

Das passiert im Grunde genommen bei einem CRLF-Injektionsangriff. Die CRLF-Buchstaben stehen für Carriage Return und Line Feed, die einzeln oder zusammen verwendet werden, um das Ende einer Leitung zu kennzeichnen. Wenn ein Angreifer einen CR- oder LF-Code in eine bestehende Anwendung einfügen kann, kann er manchmal deren Verhalten ändern. Die Auswirkungen sind im Vergleich zu den meisten Angriffen weniger leicht vorherzusagen, können aber für die Zielorganisation nicht weniger gefährlich sein.

In dieser Folge werden wir lernen:

• Wie Angreifer eine CRLF-Injektion auslösen können
• Warum CRLF-Injektionen gefährlich sind
• Techniken, mit denen diese Sicherheitsanfälligkeit behoben werden kann.

Wie lösen Angreifer eine CRLF-Injektion aus?

CRLF-Zeichen in vorhandenen Code einzufügen und zu versuchen, ein bestimmtes Ergebnis zu erzielen, ist ziemlich schwierig, wenn auch nicht unmöglich. Dies wird noch schwieriger, da ein Angreifer je nach Betriebssystem und anderen Faktoren des Zielsystems unterschiedliche CRLF-Kombinationen verwenden müsste. Moderne Windows-Computer benötigen beispielsweise sowohl CR als auch LF, um eine Zeile zu beenden, während unter Linux nur der LF-Code benötigt wird. HTTP-Anfragen benötigen immer einen präzisen CRLF-Code, um eine Zeile zu beenden.

Abgesehen von der Tatsache, dass CRLF-Angriffe schwierig zu implementieren sind und ihre Ergebnisse noch schwieriger vorherzusagen sind, werden sie auf die gleiche Weise initiiert wie andere Angriffe vom Typ Injektion. Ein böswilliger Benutzer gibt einfach Daten in einen beliebigen Bereich einer Website oder Anwendung ein, der dies zulässt. Nur er gibt den CRLF-Code anstelle von oder nach normalen Eingabedaten ein.

Ein Angreifer könnte beispielsweise den ASCII-Code eingeben, der einen Wagenrücklauf (%0d) gefolgt von ASCII für einen Zeilenvorschub (%0a) am Ende eines HTTPS-Headers darstellt. 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, kann der obige Code dazu führen, dass auf der Zielanwendung oder Website seltsame Dinge passieren.

Warum sind CRLF-Injektionen gefährlich?

CRLF-Injektionsangriffe sind zwar weniger präzise als die meisten anderen, können aber zumindest zeitweise ziemlich gefährlich sein. Im unteren Bereich kann das Hinzufügen einer zusätzlichen Zeile die Protokolldateien durcheinander bringen, wodurch automatische Cybersicherheitsmaßnahmen ausgelöst werden, um Administratoren vor einem Problem zu warnen. Dies könnte jedoch genutzt werden, um Ressourcen von einem tatsächlichen Angriff abzuhalten, der zur gleichen Zeit stattfindet.

CRLF-Angriffe können aber auch direkt schädlich sein. Wenn eine Anwendung beispielsweise so konzipiert ist, dass sie Befehle akzeptiert und dann nach einer bestimmten Datei sucht, kann das Hinzufügen eines CRLF-Codes zur Abfrage dazu führen, dass die Anwendung diesen Prozess auf dem Bildschirm anzeigt, anstatt ihn versteckt zu halten, was einem Angreifer wertvolle Informationen liefern könnte.

CRLF-Injektionen können auch verwendet werden, um einen sogenannten Response-Splitting-Angriff auszulösen, bei dem die Codes am Ende einer Zeile eine gültige Antwort in mehrere Teile zerlegen. Das kann Hackern die Kontrolle über den Header nach dem CRLF-Code geben, der zum Einfügen von zusätzlichem Code verwendet werden kann. Es kann auch verwendet werden, um eine Öffnung zu schaffen, in die der Angreifer seinen eigenen Code vollständig einfügen und wahrscheinlich eine andere Form von Angriff auslösen kann, und zwar in jede Zeile, die auf den Teil folgt, der durch den CRLF-Angriff unterbrochen wurde.

Beseitigung der CRLF-Injektionsanfälligkeit

Wenn es eine wichtige Botschaft gibt, die wir aus dieser Serie mitnehmen können, dann ist es, niemals Benutzereingaben zu vertrauen. Die meisten Sicherheitslücken, die wir in dieser Serie behandelt haben, betrafen auf die eine oder andere Weise Benutzereingabebereiche, und der CRLF-Injection-Fehler ist da keine Ausnahme.

An jedem Punkt, an dem ein Benutzer Eingaben eingeben kann, müssen Filter angewendet werden, um zu verhindern, dass unautorisierter Code injiziert wird, der von der Anwendung oder dem Server falsch interpretiert werden könnte. Bei CRLF-Angriffen ist das Sperren von HTTP-Headern besonders wichtig, aber Sie dürfen auch die GET- und POST-Parameter oder sogar Cookies nicht vergessen. Eine gute Möglichkeit, gezielt zu verhindern, dass CRLF-Codes dazu beitragen, weitere Injektionen auszulösen, besteht darin, die HTML-Codierung auf alles und jedes anzuwenden, was an den Browser eines Benutzers zurückgesendet wird.

Weitere Informationen zu CRLF-Injektionen

Zum weiteren Lesen können Sie sich ansehen, was OWASP dazu sagt CRLF-Injektionen. Sie können Ihr neu gewonnenes Defensivwissen auch auf die Probe stellen mit dem kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Blog von Secure Code Warrior.