it-swarm.com.de

BREACH - ein neuer Angriff gegen HTTP. Was kann getan werden?

Nach CRIME haben wir jetzt VERLETZUNG , die am Donnerstag (heute) auf der Black Hat in Las Vegas vorgestellt werden soll. Aus dem verlinkten Artikel geht hervor, dass dieser Angriff gegen die Komprimierung nicht so einfach auszuschalten ist wie zur Abschreckung von CRIME. Was kann getan werden, um diesen jüngsten Angriff auf HTTP abzuschwächen?

EDIT: Die Moderatoren von BREACH haben eine Website mit weiteren Details erstellt. Die aufgeführten Abhilfemaßnahmen sind:

  • Deaktivieren der HTTP-Komprimierung
  • Geheimnisse von Benutzereingaben trennen
  • Geheimnisse nach Anfrage randomisieren
  • Geheimnisse maskieren
  • Schutz anfälliger Seiten mit CSRF
  • Länge versteckt
  • Ratenbegrenzende Anfragen

(Hinweis - auch der bearbeitete Titel und die ursprüngliche Frage zur Verdeutlichung dieses Angriffs richten sich gegen HTTP, das möglicherweise verschlüsselt ist, nicht gegen HTTPS.)

39
JoltColaOfEvil

Obwohl der Artikel nicht voller Details ist, können wir einige Dinge ableiten:

  • Angriff verwendet Komprimierung nach dem gleichen allgemeinen Prinzip wie VERBRECHEN : Der Angreifer kann ein Zielsystem dazu bringen, eine Folge von Zeichen zu komprimieren, die sowohl einen geheimen Wert enthält (den der Angreifer) versucht zu erraten) und einige Charaktere, die der Angreifer auswählen kann. Das ist ein gewählter Klartextangriff . Die Länge von komprimiert hängt davon ab, ob die Zeichenfolge des Angreifers wie das Geheimnis "aussieht" oder nicht. Die komprimierte Länge geht durch die SSL-Verschlüsselung verloren, da die Verschlüsselung Inhalt, nicht Länge verbirgt.

  • Der Artikel spricht speziell von "jedem Geheimnis, das [...] sich im Körper befindet". Es handelt sich also um eine Komprimierung auf HTTP-Ebene, nicht um eine Komprimierung auf SSL-Ebene. Die HTTP-Komprimierung gilt nur für den Anforderungshauptteil, nicht für den Header. Geheimnisse im Header, insbesondere Cookie-Werte, sind vor diesem sicher.

  • Da es "Testanfragen" gibt, erfordert der Angriff bösartigen Code im Client-Browser. Der Angreifer muss auch die verschlüsselten Bytes im Netzwerk beobachten und beide Elemente koordinieren. Dies ist das gleiche Setup wie für CRIME und BEAST.

  • Es ist unklar (allein aus dem Artikel, auf den ich jetzt noch eingehen muss), ob der komprimierte Körper einer vom Client oder vom Server Ist =. "Testanforderung" wird sicherlich vom Client (im Namen des Angreifers) gesendet, aber die Antworten vom Server können einen Teil der in der Anforderung gesendeten Antworten enthalten, sodass der "ausgewählte Klartextangriff" in beide Richtungen funktionieren kann.

In jedem Fall sieht "BREACH" wie ein Angriff aus Methodik, der an den speziellen Fall einer Zielsite angepasst werden muss. In diesem Sinne ist es überhaupt nicht neu; Es war bereits "bekannt", dass durch die Komprimierung Informationen verloren gehen, und es gab keinen Grund zu der Annahme, dass die Komprimierung auf HTTP-Ebene magisch immun ist. Heck, es wurde diskutiert genau hier letztes Jahr. Es ist jedoch eine gute Sache, dass einige Leute die Extrameile gehen, um Arbeitsdemonstrationen zu zeigen, da sonst Fehler niemals behoben würden. Zum Beispiel wurde das Auffüllen von Oracle-Angriffen gegen CBC im Jahr 2002 beschrieben und sogar prototypisiert, aber es war eine tatsächliche Demo gegen ASP im Jahr 2010 erforderlich, um Microsoft davon zu überzeugen, dass die Gefahr real war. Ähnliches gilt für BEAST im Jahr 2011 (Die Notwendigkeit einer unvorhersehbaren IV für den CBC-Modus war auch seit 2002 bekannt) und CRIME im Jahr 2012; BREACH ist mehr "CRIME II": eine weitere Ebene der Pädagogik, um die Ungläubigen niederzuschlagen.

Leider werden viele Leute es falsch verstehen und glauben, dass es ein Angriff gegen SSL ist, was es nicht ist. Es hat eigentlich nichts mit SSL zu tun. Es ist ein Angriff, der ein Informationsleck durch einen Datenkanal mit geringer Bandbreite, die Datenlänge, erzwingt, den SSL nie abgedeckt hat und von dem nie behauptet wurde, dass er abdeckt.

Die einzeilige Zusammenfassung lautet: du sollst nicht komprimieren .

41
Thomas Pornin

BREACH ist wie CRIME ein kompressionsbedingter Angriff. Das Ausschalten der Komprimierung macht den Angriff unmöglich.

HINZUGEFÜGT
Beachten Sie, dass Sie in diesem Fall anscheinend eine andere Komprimierungskonfiguration deaktivieren. Während CRIME die TLS-Layer-Komprimierung nutzt, nutzt BREACH die HTTP-Layer-Komprimierung.

9
tylerl

Ich habe mir gerade eine Möglichkeit überlegt, einer CSRF-Minderungsmaßnahme "Randomizing Secrets per Request", "Length Hiding" und "Rate-Limiting Requests" hinzuzufügen.

  1. Überlegen Sie, welche Formulare ein Angreifer nicht im Namen des Benutzers POST] verwenden soll. Dies sind die Formulare, die Sie vor CSRF schützen möchten.
  2. Generieren Sie für jede Seitenansicht ein zufälliges Salz mit zufälliger Länge. Senden Sie dieses Salz als versteckte Eingabe. Die zufällige Länge sollte dazu beitragen, die Längen zu verrauschen, selbst wenn Ihr Front-End-Load-Balancer Kommentare entfernt oder Ihren HTML-Code auf andere Weise minimiert.
  3. Berechnen Sie einen Hash des Salt, die Sitzungs-ID und ein serverseitiges Geheimnis und senden Sie diesen CSRF-Schlüssel als weitere versteckte Eingabe.
  4. Optional können Sie den Salt- oder CSRF-Schlüssel in einer Tabelle protokollieren. Dies ermöglicht die Ratenbegrenzung eines bestimmten Benutzerkontos oder einer bestimmten IP-Adresse auf eine Anzahl von Hashes pro Stunde und die Begrenzung der Wiederholungen eines bestimmten Salzes.
  5. Wenn Sie das Formular verarbeiten, berechnen Sie den Hash auf die gleiche Weise wie in den vorherigen Schritten, indem Sie das Salz im Formular verwenden, und stellen Sie sicher, dass es mit dem CSRF-Schlüssel übereinstimmt.
2
Damian Yerrick

Der Angriff funktioniert, indem Informationen aus der Nutzlastgröße abgeleitet werden. Das künstliche Auffüllen von bereitgestellten HTTPS-Seiten (z. B. eine zufällig große Kommentarzeichenfolge) könnte deren Wirksamkeit verringern.

1
Max David