Ansicht umschalten Baum an
Avatar von Harry Boeck
  • Harry Boeck

mehr als 1000 Beiträge seit 14.03.2000

Nach einem Jahr: Es gibt so triviale Gegenmaßnahmen!

Damals hatte ich diese Meldung nicht großartig ernst genommen aus
einem anderen Grund: Die Voraussetzung für diese
Known-Plaintext-Attacke ist ja immerhin ein im zu attackierenden
Kontext laufender Virus. WENN dort ein Virus läuft, ist eine Attacke
auf einen Plaintext-Anteil in einem "Nebenkanal" der SSL-Verbindung
das kleinere Übel von denen, die solch ein Virus anstellen kann:

a) Ein Virus, der beliebig Cross-Side-Scripten kann, ist die
Katastrophe schlechthin. Er stellt faktisch ein Botnetz-Element dar.
Falls die Angriffsfähigkeit durch eine solche
Cross-Site-Schwachstelle entsteht, ist Polen offen. Da ist Bankraub
nicht die optimalste aller Möglichkeiten des PC-Kontrolleurs, Geld zu
verdienen: Der Verkauf für Spamversand und DDOS bringt auch Geld
übers Jahr ein und dürfte deutlich weniger gefährlich sein.

b) Falls KEIN derartiges Cross-Site-Loch klafft, müßte der Virus
zwingend vom Zielserver der HTTPS-Verbindung stammen. Wenn DAS der
Fall ist, ist auf dem Server Polen offen und in Folge dessen auf
sämtlichen Clients, die Javascript eingeschaltet haben, ebenfalls -
zumindest hinsichtlich allem, was die gegenüber dem Server tun oder
lassen.

Beide Fälle stellen Szenarien dar, in denen jene Attacke auf einen
Daten-Nebenkanal nur eine marginale Verschärfung einer bereits an
sich wütenden Katastrophe wären. Aus Nutzersicht stellte diese
Attacke für mich somit kein Problem dar: Ich schalte Javascript
sowieso nur in belanglosen Ausnahmefällen ein und starte vor Besuchen
wichtiger Seiten ohnehin eine neue Browsersitzung. Also darf mir
diese Attacke den Hintern knutschen!

==============

Aber nach einer Weile kam mir doch nochmal der Gedanke, daß dies ja
nur meine Sichtweise als Browser-NUTZER ist, und es daneben doch noch
die als Server-Betreiber gibt. Wo sich die Frage stellt: Was kann ich
denn als Server-Betreiber tun, um zum Naseputzen und Türschließen zu
dusslige DAU's, die nun mal einen Virus in den Kontext einer bei mir
laufenden Webanwendung auf deren Browser hineingelassen haben
(ähhh... wie auch immer die das anstellten mit was für katastrophalen
Cross-Site.-Lücken in deren Browsern...), immun gegen die hier
beschriebene Attacke zu machen?

Und da gibt es ein extrem einfaches Mittel: Die gefährdeten Daten
werden einfach in Zufallsdaten eingepackt.

Im konkreten Fall geht es erstmal nur allgemein um Session-ID's,
wobei anderes Zeug natürlich auch betroffen gemacht werden könnte -
spezifisch für jeden einzelnen Fall von generiertem Inhalt, der eine
einigermaßen stabile, vorhersehbare Umgebung aufweist.

Zunächst mal zur Session-ID: Die packen wir einfach in ein zufälliges
MD5-Padding ein. Das wird lediglich genauso anständig gesalzen wie
die Session-ID und ansonsten von den Millisekunden der Anfrage
abhängig gemacht. Folge ist, daß die Klartext- und Cipherblöcke rund
um die anzugreifenden Daten bunt rauschen und die Angriffstechnik von
BEAST damit fehlschlägt.

Kommen innerhalb einer HTML-Seite sensible Daten vor, können wir das
mit denen genauso leicht machen: Kleine, in Mini-HTML-Tags verpackte
Zufallsblöcke rund herum gesetzt und schon ist BEAST unmöglich.

Das geht vollkommen ohne jede Änderung von Protokollen oder inneren
Funktionen von Webanwendungen. Komplett neutral.

Der Grund für die Idee war, daß bis heute (nach einem Jahr bzw.
etliche Jahre nach Bekanntwerden der Idee zu diesem
Plaintext-Seitenkanal-Angriff) noch immer keine Änderung auf Ebene
der Protokolle in Sicht ist.

Wobei EIGENTLICH nur die Browserhersteller darauf verzichten müßten,
die Datenströme mehrerer unabhängiger Fenster bzw. Frames über ein
und denselben OFFENEN (!) Datenkanal zu vereinen, wenn einer von
denen verschlüsselt ist! (Also: Jedes Fenster im Browser müßte nur
seinen eigenen Crypto-Kanal bekommen, hinter dem die Datenströme ja
dann gern wieder zusammengeführt und über den selben Socket
übertragen werden dürften.)

Wie auch immer; Das Problem kann auf mehreren Ebenen unabhängig
gelöst werden - UND AUCH OHNE Mithilfe der Browserhersteller.

Bewerten - +
Ansicht umschalten Baum an
Anzeige