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/