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

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

Ohne. den. Text. zu. ändern,. kann. es. viel. schwieriger. werden,. die. Informationen. zu. verarbeiten.

Das ist im Grunde das, was bei einer CRLF-Injektionsattacke passiert. Die Buchstaben CRLF stehen für Carriage Return und Line Feed, die einzeln oder zusammen verwendet werden, um das Ende einer Zeile zu vermerken. 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 nicht weniger gefährlich für die Zielorganisation sein.

In dieser Folge lernen wir:

• Wie Angreifer eine CRLF-Injektion auslösen können
• Warum CRLF-Injektionen gefährlich sind
• Techniken, die diese Sicherheitslücke beheben können.

Wie lösen Angreifer eine CRLF-Injektion aus?

Das Einfügen von CRLF-Zeichen in vorhandenen Code und der Versuch, ein bestimmtes Ergebnis zu erzielen, ist ziemlich schwierig, wenn auch nicht unmöglich. Es wird dadurch erschwert, dass ein Angreifer je nach Betriebssystem und anderen Faktoren des Zielsystems unterschiedliche CRLF-Kombinationen verwenden muss. Moderne Windows-Rechner erfordern zum Beispiel sowohl ein CR als auch ein LF, um eine Zeile zu beenden, während unter Linux nur der LF-Code benötigt wird. HTTP-Anfragen erfordern immer einen genauen CRLF-Code, um eine Zeile zu beenden.

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

Ein Angreifer könnte z. B. den ASCII-Code für einen Wagenrücklauf (%0d) gefolgt von ASCII für einen Zeilenvorschub (%0a) am Ende eines HTTPS-Headers eingeben. Die gesamte Abfrage würde dann wie folgt 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 in der Zielanwendung oder -website einige seltsame Dinge passieren.

Warum sind CRLF-Injektionen gefährlich?

Obwohl CRLF-Injektionsangriffe weniger präzise sind als die meisten anderen, können sie zumindest manchmal ziemlich gefährlich sein. Am unteren Ende kann das Hinzufügen einer zusätzlichen Zeile die Protokolldateien durcheinander bringen, was automatische Cybersecurity-Abwehrmaßnahmen auslösen könnte, um Administratoren auf ein Nicht-Problem aufmerksam zu machen. Dies könnte jedoch genutzt werden, um Ressourcen von einem tatsächlichen Einbruch abzulenken, der zur gleichen Zeit stattfindet.

Aber CRLF-Angriffe können auch direkt Schaden anrichten. Wenn eine Anwendung z. B. so konzipiert ist, dass sie Befehle annimmt und dann nach einer bestimmten Datei sucht, könnte das Hinzufügen eines CRLF-Codes zur Abfrage dazu führen, dass die Anwendung diesen Vorgang auf dem Bildschirm anzeigt, anstatt ihn verborgen zu halten, was einem Angreifer wertvolle Informationen liefern könnte.

CRLF-Injektionen können auch verwendet werden, um einen so genannten Response-Splitting-Angriff zu erstellen, bei dem die Codes am Zeilenende eine gültige Antwort in mehrere Teile aufteilen. 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 der der Angreifer seinen eigenen Code vollständig einfügen und wahrscheinlich eine andere Form des Angriffs auslösen kann, und zwar in jeder Zeile, die auf den Teil folgt, der durch den CRLF-Angriff unterbrochen wurde.

Beseitigung der CRLF-Injection-Schwachstelle

Wenn es eine Schlüsselbotschaft gibt, die man aus dieser Serie mitnehmen kann, dann ist es die, dass man niemals auf Benutzereingaben vertrauen sollte. Die meisten Schwachstellen, die wir in dieser Serie behandelt haben, betrafen auf die eine oder andere Weise Benutzereingabebereiche, und der CRLF-Injection-Fehler ist keine Ausnahme.

An jedem Punkt, an dem ein Benutzer Eingaben machen kann, müssen Filter eingesetzt werden, um das Einschleusen von nicht autorisiertem Code zu verhindern, der von der Anwendung oder dem Server falsch interpretiert werden könnte. Für CRLF-Angriffe ist das Sperren von HTTP-Headern besonders wichtig, aber auch GET- und POST-Parameter oder sogar Cookies dürfen nicht vergessen werden. Eine großartige Möglichkeit, CRLF-Codes gezielt daran zu hindern, weitere Injektionen auszulösen, ist die Anwendung von HTML-Kodierung auf alles, was an den Browser des Benutzers zurückgesendet wird.

Mehr Informationen über CRLF Injections

Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über CRLF-Injektionen sagt. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Plattform Secure Code Warrior testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .