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