Verbreitung von HSTS – Aktualisierung

Zur Beobachtung der Entwicklung von HSTS wurde im Januar und im Februar 2014 eine weitere Analyse zur Verbreitung von HSTS durchgeführt.

Das konkrete Vorgehen zur Durchführung der Analyse ist in Kapitel 1 im Dokument zur Verbreitung von HSTS beschrieben [1]. Zur eigentlichen Durchführung wurden zwei verschiedene Ansätze mit verschiedenen Datengrundlagen gewählt. Die folgenden Ergebnisse konnten mit den zwei verschiedenen Ansätzen gewonnen werden:

1. Auswertung mit Alexa-Liste der Top-1-Million von Oktober 2012

Zum einen wurde die Alexa-Liste der Top-1-Million-Webseiten eingesetzt, die bereits im Oktober 2012 bei der ursprünglichen Auswertung verwendet wurde. Dadurch soll ein direkter Vergleich ermöglicht und die Entwicklung wiedergespiegelt werden (siehe auch [1] für detaillierte Ergebnisse von 2012).

Die Auswertung wurde am 28. und 29.01.2014 durchgeführt. Die Verbreitung des HSTS Headers hat sich unter den untersuchten Seiten bis heute fast vervierfacht. Von ursprünglich 412 ist die Zahl der Webserver, die HSTS anbieten, nun auf insgesamt über 1.400 gestiegen. Die Verteilung der für die max-age-Direktive verwendeten Werte ist dabei nahezu gleich geblieben. Es wird in den meisten Fällen ein Wert von 31.536.000 Sekunden gesetzt, was einem Jahr entspricht.

Gegenüberstellung Auswertung vom Oktober 2012 mit Januar 2014

Gegenüberstellung der Auswertung vom Oktober 2012 mit Januar 2014

2. Auswertung mit Alexa-Liste der Top-1-Million von Februar 2014

Neben der Gegenüberstellung der Auswertungen von Oktober 2012 und Januar 2014 wurde darüber hinaus die Alexa-Top-1-Million-Liste vom 01.02.2014 verwendet, um eine aktuelle Liste zu überprüfen und damit Änderungen in der Rangfolge gerecht zu werden. Die Auswertung wurde am 2. und 3. Februar 2014 durchgeführt. Die Verbreitung von HSTS beläuft sich in diesem Fall auf 1.510 Webseiten, die einen gültigen HSTS-Header ausliefern.  Auch hier wird in den meisten Fällen der Wert 31.536.000 für die max-age-Direktive gewählt.

Auswertung Februar 2014

Auswertung Februar 2014


Referenzen:

[1] Verbreitung von HSTS http://www.securenet.de/fileadmin/papers/HTTP_Strict_Transport_Security_HSTS_Verbreitung.pdf

Firefox bekommt auch HSTS-Preloading-Liste

Google hat in Chrome mit Version 13 eine HSTS-Preloadinging-Liste eingeführt. Diese besteht aus einer in der Binary hinterlegten Liste von Domains, die vom Browser ausschließlich über HTTPS angesprochen werden dürfen. Mozillas Firefox übernimmt dieses Feature nun in Version 17 und verwendet dazu auch die vom Chromium-Project gepflegte Liste. Besagte Version befindet sich aktuell im Beta-Stadium.

Die HSTS-Preloading-Listen setzen an einer prinzipiellen Schwachstelle des Strict-Transport-Security-Headers als Schutz gegen SSL-Stripping an: dem ersten Besuch der Seite. Hat ein Benutzer eine Website mit einem Browser noch nie besucht (z.B. auf Grund einer Neuinstallation oder weil ein neues Gerät verwendet wird) oder ist die Dauer des Schutzes vom vorherigen Besuch bereits abgelaufen, so ist der HSTS-Eintrag im Browser noch nicht bzw. nicht mehr vorhanden. Besucht er nun eine Seite über ein unsicheres Netz, kann ein Man-in-the-Middle den HSTS-Header in der ersten Response des Servers entfernen und einen SSL-Stripping-Angriff ausführen. Ist die jeweilige Domain jedoch schon in der HSTS-Preloading-Liste aufgeführt, weiß der Browser auch vor dem ersten Besuch schon, dass diese Seite per HTTPS angesprochen werden muss.

Als Mindestwert für den max-age-Paramter hat Mozilla 10.886.400 Sekunden gewählt. Dies entspricht 18 Wochen und liegt damit unter dem Mindestwert von einem Jahr, den wir im Whitepaper zum Thema empfehlen. Dieser Wert ist allerdings trotzdem deutlich restriktiver als der für die HSTS-Preloding-Liste in Chrome gewählte; dort sind auch Domains mit deutlich geringeren Werten enthalten. Die Umsetzung der HSTS-Preloading-Liste in Firefox ist erfreulich und hat für die Serverbetreiber keine negativen Effekte.

SSL-Stripping, die ignorierte Gefahr.

Wie kann es einem Angreifer gelingen, die Passwörter für sensitive Webanwendungen wie Online-Banking, Webmail-Konten oder Businessportale trotz korrekt angewandter Verschlüsselung (HTTPS) mit einer hohen Erfolgswahrscheinlichkeit zu erspähen – und das bei der großen Mehrzahl aller heutigen Webangebote? Darunter so vermeintlich sichere Vorgänge wie 3-D Secure Payment (der sichere Standard beim Zahlen mit Kreditkarte), Paypal oder ebay?

Die Antwort lautet: Mit einem recht eleganten Trick! Der möglich ist, weil Webserver eine einfache Sicherheitsmaßnahme außer Acht lassen.

Dieser Blogeintrag will Adminstratoren und Verantwortlichen aufzeigen, wie real diese Bedrohung ist und was sie dagegen tun können. Es sei aber vorweg auch gesagt, dass sich beim gegenwärtigen Stand der Browsertechnik die Lücke nicht komplett schließen lässt, wenn nicht zusätzliche Vorkehrungen getroffen werden.

Wie funktioniert der Angriff?

Machen wir den Anfang mit der Darstellung des Angriffs. Das im folgenden Clip dargestellte Szenario ist eines, in das jeder ganz leicht selbst geraten kann. Darin wird der Ablauf eines Online-Einkaufs durchgespielt und gezeigt, wie der Benutzer – je nach gewähltem Bezahlverfahren – am Ende seine Shop-Zugangsdaten, seine kompletten Kreditkarten-Daten oder seinen Paypal-Benutzernamen mit Passwort an den Angreifer verloren hat. Der Angriff ist jedoch bei weitem nicht auf das Onlineshopping beschränkt. Wir hätten statt des hier verwendeten Online-Shops genauso gut einen x-beliebigen anderen Shop oder eine andere Anwendung mit Login oder sensiblen Daten hernehmen können.

Schauen wir uns den Ablauf des Angriffs aus Sicht des Benutzers an und blenden parallel dazu ein, was der Angreifer im selben Moment auf seinem Bildschirm angezeigt bekommt:

Noch einmal: Der Trick beruht zum einen darauf, dass die initiale Verbindung unverschlüsselt abläuft und der als Man-in-the-Middle (MitM) arbeitende Angreifer somit in der Lage ist, jeden HTTPS-Link, den der Server zurückliefert, in einen HTTP-Link umzuwandeln und damit die Verbindung zwischen sich und dem Benutzer über die gesamte Dauer unverschlüsselt zu halten. Zum anderen beruht der Angriff darauf, dass der MitM den anderen Teil der Verbindung, also die zum Server, per HTTPS durchführt und der Server somit keine Chance hat, den Angriff zu erkennen und abzuwehren.

Damit hängt der Angriff natürlich ganz entscheidend davon ab, dass der Benutzer nicht darauf achtet, dass er die ganze Zeit per HTTP statt wie gewohnt per HTTPS kommuniziert. Würde die Verbindung zwischen MitM und Browser per HTTPS ablaufen, so würde der Browser das Vorhandensein eines MitM erkennen und dem Benutzer eine entsprechende Warnung zeigen. Denn die Sicherstellung der Authentizität des Servers ist neben der Verschlüsselung die zweite wichtige Eigenschaft von SSL, auf welche die Sicherheit der Browser-Server-Kommunikation sich stützt. Mit dem gezeigten Angriff wird das geschickt ausgehebelt.

Ist der Benutzer selbst schuld?

Man könnte sich nun auf den Standpunkt stellen „Naja, da muss der Benutzer halt aufpassen“. Aber das ist sicher zu kurz gegriffen, wie leicht zu erkennen ist, wenn man diesen Zusammenhang in den Alltag überträgt: Würde an einer Verkehrsampel ein Schalter zum Umschalten der Signalisierung an einer mit wenig Anstrengung zugänglichen Stelle angebracht sein, so würde man auch nicht den Autofahrer verurteilen, der bei grün ohne nach links und rechts zu schauen über die Kreuzung fährt und dann mit dem Querverkehr kollidiert. Selbstverständlich wird denjenige zur Verantwortung gezogen, der eine so schlecht vor Missbrauch geschützte Ampel aufstellt.

Wie leicht hat es der Angreifer?

Damit der Angriff vonstatten gehen kann, muss die Kommunikation des Benutzers über den Rechner des Angreifers geleitet werden. Der Angreifer kann diese Voraussetzung auf verschiedene Weisen herstellen, was, abhängig von der Umgebung, sehr leicht bis weniger leicht aber immer noch möglich, sein kann.

Am einfachsten lässt sich die benötigte Voraussetzung wohl auf die im Video dargestellte Weise herstellen: Der Angreifer positioniert sich an einem Ort wo gewartet – zB. am Flughafen – oder gechillt – zB. im Straßencafe – wird, oder wo man sich halbwegs sicher fühlt, z. B. im Hotel. Hier bietet er mit seinem Laptop einen öffentlichen Hotspot an. Wenn dieser mit einem unverfänglichen Namen wie „FreePublicHotspot“ oder „GuestAccess“ daher kommt, kann er davon ausgehen, dass das Angebot gerne angenommen wird. Die Erfolgsquote ist letztlich wohl nur noch davon abhängig, wie glaubwürdig das Ganze daherkommt.

Aber auch in kabelgebundenen Netzen ist man nicht automatisch sicher. Befinden Angreifer und Benutzer sich im selben Netzwerksegment, so kann der Angreifer den Rechner des Benutzers mittels eines ARP-Spoofing Angriffs dazu bringen, dass dieser seine Kommunikation an den Angriffsrechner zur Weiterleitung ins Internet übergibt, sofern nicht spezielle Netzwerkgeräte oder -überwachung dies unterbindet.

Der Angriff selbst erfordert nicht sehr viel technisches Wissen. Im Internet kursieren detaillierte Anleitungen und ein auch von Programmierlaien leicht zu verwendendes Tool vom Entdecker dieser Schwachstelle.

Welche Schadensszenarien bestehen?

Neben dem hier beschriebenen Szenario, welches höchst sensitive Zahlungsdaten freilegt, ist als weitere Gefahr an oberster Stelle der Zugriff auf das Email-Konto (wenn es per Webmailer angesprochen wird) oder das Soziale Netzwerk (Facebook, Google+, Xing, LinkedIn etc) zu nennen. Siehe dazu auch die Nutzerbefragung von Google, wonach von den meisten Nutzern das Emailkonto als kostbarstes Online-Gut angesehen wird.

Ein weites Feld mit hohen Begehrlichkeiten ist sicher auch der gesamte E-Business-Bereich. Das Eindringen in das Konto des Wettbewerbers im Partnerportal des gemeinsamen Auftraggebers oder in dessen mit einem Webzugang ausgestattetes CRM-System sind sicher realistische Angriffsszenarien.

Was lässt sich serverseitig dagegen tun?

Wir haben es bei diesem Sachverhalt mit einem tief in der Webtechnik steckenden Designproblem zu tun. Insofern ist ein komplettes Schließen dieser Lücke sobald nicht zu erwarten. Aber es existieren Mittel, die die Erfolgsquote eines Angriffs signifikant herabsetzen. Und diese sollten von den Webanwendungsbetreibern unter allen Umständen zum Einsatz gebracht werden!

An erster Stelle steht die Einschaltung des HSTS-Schutzes. Dahinter verbirgt sich die Möglichkeit des Servers, den Browser zu zwingen, dass er ihm niemals einen HTTP-Link, sondern immer nur HTTPS-Links, schickt. Selbst wenn der Benutzer auf einen HTTP-Link klickt, wird dieser vom Browser in den sicheren HTTPS-Link umgewandelt.

Diese und weitere Gegenmaßnahmen sind in dem Whitepaper zu HSTS erläutert.

Was hilft serverseitig nicht?

Die sensible Webanwendung nur per HTTPS zur Verfügung zu stellen, dh. auf einen HTTP-Request ein Redirect auf HTTPS oder gar keine Antwort zu geben, löst das Problem nicht. Denn der MitM sorgt dafür, dass die HTTP-Requests des Browsers den Server korrekt als HTTPS-Requests erreichen.

Welche Lücken bleiben trotz HSTS bestehen?

  •  Microsofts IE9 und auch IE10 unterstützen HSTS nicht. Deren Nutzer sind also auch bei HSTS-geschützten Seiten komplett ungeschützt!
  • Findet der erstmalige Aufbau einer Verbindung zu einer HSTS-geschützten Website bereits über ein Angreifer-Gateway – den MitM – statt, so „weiss“ der Browser noch nicht, dass HTTP-Zugriffe zu diesem Host nicht zugelassen sind. Er kann den initialen HTTP-Zugriff damit auch nicht unterbinden und der MitM hat wieder freie Bahn – denn er sorgt natürlich dafür, dass der HSTS-Header den Browser nie erreicht!

Wie lässt sich der Angriff benutzerseitig verhindern?

HSTS-Schutz bieten gegenwärtig nur wenige Websites (siehe die Untersuchung zur Verbreitung von HSTS im Nov. 2012). Ein jeder muss daher selbst dafür sorgen, dass er nicht zum Angriffsopfer wird.

  • Unbedingt auf das Schloss in der Adressleiste achten und niemals schützenswerte Informationen in ein Formlar ohne Schloss in der Adressleiste eingeben. Das ist leichter gesagt als getan, denn gerade beim Login wird häufig so verfahren, dass das Formular selbst sich auf der unverschlüssselt ausgelieferten Homepage befindet, wie in diesem Beispiel gezeigt:
  • Um dem aus dem Weg zu gehen, Firefox oder Chrome mit HTTPS Everywhere– oder noscript-Plugin verwenden und diese entsprechend konfigurieren
  • Die Best-Practice für Firmen, die verhindern wollen, dass ihre Mitarbeiter durch Fehlverhalten in der hier beschriebenen Weise zum Sicherheitsrisiko werden, lautet: Die Unterwegs-Laptops und Homeoffice-PCs der Mitarbeiter sind per VPN ins Unternehmens-LAN zu zwingen. Dann wird jeder Verbindungsaufbau des Browsers, egal ob HTTP oder HTTPS, unangreifbar durch den geschützten Kanal ins Firmennetz gezwungen und von dort aus zum jeweiligen Webserver geleitet.
  • Internet Explorer und Safari meiden, solange diese HSTS nicht unterstützen

Wo besteht keine Gefahr?

Mobile Apps, die für den Serverzugriff fest eingebaute Links verwenden, sind nicht gefährdet. Das ist in der Regel bei einer Native App der Fall. Wird hingegen das Zugriffsziel als URL in der Serverantwort ermittelt, besteht dasselbe Problem wie bei den Browsern.

Weiterführende Links

HSTS Whitepaper: http://www.securenet.de/fileadmin/papers/HTTP_Strict_Transport_Security_HSTS_Whitepaper.pdf

OWASP-Hinweise zum Thema (zum Zeitpunkt der Veröffentlichung dieses Posts leider noch nicht sehr ausgeprägt): https://www.owasp.org/index.php/HTTP_Strict_Transport_Security

Untersuchung zur Verbreitung von HSTS: http://www.securenet.de/fileadmin/papers/HTTP_Strict_Transport_Security_HSTS_Verbreitung.pdf