Aus der Hölle der Internetprotokolle: Exotische Kompressionen

Aus der Hölle der Internetprotokolle: Exotische Kompressionen

Das grundlegende Protokoll im Internet ist das HTTP (Hypertext Transfer Protokol), welches auf den ersten Blick recht einfach erscheint. Sieht man jedoch genauer hin, so fallen viele unklare oder widersprüchliche Details auf. Dort verbergen sich die Teufelchen, welche die zuverlässige Analyse von Datenverbindungen zur Hölle machen können ...

Ca. 30 Prozent der Inhalte im Internet werden komprimiert ausgeliefert. Dabei wird fast ausschließlich der bekannte Algorithmus "gzip" eingesetzt. Ob Kompression verwendet wird und mit welchem Algorithmus, wird in der Antwort des Webservers über den Content-Encoding Header angegeben:

HTTP/1.1 200 ok
Content-Encoding: gzip

...mit gzip komprimierte Daten...

Praktisch alle Firewalls und Antivirus-Produkte sind in der Lage, mit gzip komprimierte Daten zu analysieren. Das wird dadurch erleichtert, dass gzip ein paar magische Bytes am Anfang der Daten hat, womit es leicht zu erkennen ist.

Aber neben gzip gibt es noch andere etablierte Kompressionsformate. Und mit diesen haben Firewalls deutlich mehr Probleme. So ist im HTTP-Standard auch die Kompression mittels "deflate" spezifiziert, welches fast das gleiche wie gzip ist, aber nicht solche magischen Bytes am Anfang hat. Diese Kompression wird zur Zeit nur bei ca. 0,03 Prozent der Daten eingesetzt:

HTTP/1.1 200 ok
Content-Encoding: deflate

...mit deflate komprimierte Daten...

Obwohl praktisch alle Browser seit vielen Jahren diese Kompression unterstützen, waren nach unseren Untersuchungen im Herbst vergangenen Jahres 90 Prozent der Enterprise-Firewalls nicht in der Lage, mit deflate komprimierte Inhalte zuverlässig zu analysieren – die Daten wurden einfach durchgelassen. Nachdem die entsprechenden Hersteller von uns kontaktiert wurden, sind diese Ergebnisse etwas besser geworden, aber eine vollständige Unterstützung ist noch nicht erreicht.

Doch selbst viele der Hersteller, die inzwischen mit deflate klar kommen, haben weiterhin Probleme, wenn andere Kompressionen benutzt werden. So unterstützen Chrome und Opera seit langem "sdch", Opera kennt "lzma" und seit kurzem haben Firefox, Chrome und Opera mit  "br"  die neue brotli Kompression implementiert:

HTTP/1.1 200 ok
Content-Encoding: br

...mit br komprimierte Daten...

Mit der genugate lassen sich Gefahren durch exotische Kompressionen vermeiden

Wie kann eine Firewall damit umgehen, wenn immer wieder neue Kompressionsalgorithmen in den Browsern implementiert werden? Und woher weiß überhaupt der Webserver, welche Arten von Kompression der Client kann? Hierzu ist es im Standard vorgesehen, dass der Client (d. h. der Browser) in der Anfrage mitschickt, welche Kompressionsalgorithmen er unterstützt. So gibt der Client über die folgende Anfrage zu verstehen, dass er mit gzip, deflate oder br (brotli) komprimierte Antworten versteht:

GET /index.html HTTP/1.1
Accept-Encoding: gzip, deflate, br
...

Die High Resistance Firewall genugate ist als Application Level Gateway (bzw. Proxy) in der Lage, sowohl die Anfrage des Clients, als auch die Antwort des Servers zu modifizieren. Somit kann sie die Anfrage einfach so ändern, dass nur unterstützte Algorithmen genannt werden:

GET /index.html HTTP/1.1
Accept-Encoding: gzip, deflate
...

Damit weiß der Webserver, welche Fähigkeiten der Client hat und benutzt nur die vom Client unterstützten Algorithmen. Wenn der Server hier trotzdem ein nicht unterstütztes Kompressionsverfahren benutzt (warum sollte sich ein Angreifer auch an Regeln halten?), wird die offensichtlich ungültige Antwort von der Firewall genugate blockiert, d. h. nicht an den Client weitergereicht.

Wie gut ist Ihre Firewall? Finden Sie es heraus!

Leider ist dieses Vorgehen bei vielen anderen Firewalls architekturbedingt nicht möglich. Gerade Firewalls, welche die Priorität auf hohe Geschwindigkeit legen, sind nicht in der Lage, die nötigen Modifikationen an den transferierten Daten vorzunehmen. Daher leiten diese Firewalls Daten mit unbekannter Kompression einfach weiter – egal ob es sich um ungefährliche Daten oder Malware handelt. Aber so etwas erzählt Ihnen der Hersteller natürlich nicht und wiegt Sie in falscher Sicherheit.

Wie gut Ihre Firewall gegen derartige Umgehungsversuche tatsächlich schützt, können sie einfach auf der HTTP Evader Testseite überprüfen.

Weitere Informationen:

 

 Bildquellen: © Terminator3d - Fotolia.com


Lesen Sie auch

Diskutieren Sie mit

Sie können diesen Artikel sofort ohne Registrierung als Gast-User kommentieren.

Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.



Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.