GDS Security Blog » Application Security

Constricting the Web: The GDS Burp API

Marcin Wielgoszewski — Tue, 10 Aug 2010 14:38:41 +0000

Last week, I presented “Constricting the Web: Offensive Python for Web Hackers” at Black Hat USA 2010 and DEF CON 18 with Nathan Hamiel. In this talk, we presented methods and techniques for using Python in custom tools to allow testers to be more effective at finding flaws in web applications. One of the tools I demo’d during our talk was the GDS Burp API.

Introducing the GDS Burp API

At GDS, of the many web application security testing tools available, we often use PortSwigger’s Burp Suite. We found Burp to fit well with our testing methodology, partly because it seems the target audience is penetration testers like us. One of the features I like most is the ability to record requests/responses that were intercepted by its proxy. After a thorough crawl of the application (having visited every page, and submitted every form), this proxy log contains a treasure trove of data. Because of my lack of desire to write extensions in Java and current limitations of the Burp Extender API, I wrote a toolkit in Python which I call the GDS Burp API.

What is it?

The GDS Burp API exposes a Python object interface to requests/responses recorded by Burp (whether Proxy/Spider/Repeater, etc). The API is used to parse Burp logs, creating a list of “Burp objects” that contain the request / response data and related meta-data. To help visualize this, imagine a request and its associated response within your Burp history now available to you as a single Python object outside of Burp and free of Extender limitations.

One of the main reasons for doing this is because web application scanners usually do not provide enough context into the actual requests they send and the responses they receive. I like to have a full understanding into the underlying scanner implementation, so that I know in what scenarios a scanner will be effective versus where I will have to resort to manual/semi-automated methods.

How do I use it?

Using the GDS Burp API is relatively simple, and takes only a beginner level understanding to Python to take advantage of. After you’ve performed a thorough crawl, logging each request/response, you use the gds.pub.burp.parse() method to parse the proxy log into a list of Burp objects.

>>> import gds.pub.burp >>> proxylog = gds.pub.burp.parse("my_application_proxy.log") >>> proxylog [, , , , ]

Within each Burp object there are several properties, as seen in an example object below:

>>> pprint(proxylog[2].__dict__) {'host': 'http://demo.blah:80', 'index': 3, 'ip_address': '65.61.137.117', 'parameters': {'query': {'txtSearch': 'hello'}}, 'request': {'body': '', 'headers': {'Cookie': 'ASP=a0iq3c550j1xtyqbjajmymi4;', 'User-Agent': 'Mozilla/5.0 (X11; U; Linux x86_64; }, 'method': 'GET', 'path': '/search.aspx?txtSearch=hello', 'version': 'HTTP/1.1'}, 'response': {'body': '\\r\\n\\r\\n 'headers': {'Content-Length': '7275', 'Content-Type': 'text/html; charset=utf-8', 'Server': 'Microsoft-IIS/6.0', 'X-Aspnet-Version': '2.0.50727',}, 'reason': 'OK', 'status': 200, 'version': 'HTTP/1.1'}, 'time': '1:56:38 PM', 'url': ParseResult(scheme='http', netloc='demo.blah:80', path='/search.aspx', params='', query='txtSearch=hello', fragment='')}

You can access these object members directly or via object API methods such as get_request_header("User-Agent"), get_request_path(), get_response_body(), get_response_status(), etc. The full generated API documentation for the GDS Burp API can be accessed online or within the docs folder included in the zip file.

What can I do with it?

The purpose of this API is to simply provide a Python object interface to the request/response data that was recorded by Burp. I did not want to implement any fuzzing or analyses capabilities in the API, because I felt that that would detract people from writing their own. I do not want to limit anyone by including a scanner, since someone else’s requirements may and very likely will be different than my own.

A couple ideas to get you started that I have done on my own are the following:

Replaying individual requests as-is
Replaying sequences of requests (such as a login or a checkout operation)
Comparing two proxy logs, returning a diff output of the URLs and parameters submitted
Fuzzing requests (creating a Burp object) and appending them to the original’s replayed list
Comparing response bodies and headers of fuzzed requests against their original
Using difflib module in Python standard library to return a diff-formatted HTML output of two response bodies

Download Constricting the Web: Offensive Python for Web Hackers.

Visit GDS Burp API on GitHub.

GWTEnum: Enumerating GWT-RPC Method Calls

Ron Gutierrez — Tue, 20 Jul 2010 14:09:02 +0000

Google Web Toolkit (GWT) applications do not provide a straight forward way to enumerate all services and method calls. By default, GWT obfuscates client-side Javascript code which, as a tester, prevents one from being able to easily enumerate GWT-RPC method calls. Most pen testers typically limit testing to only the method calls that can be captured while crawling the application.

Using a technique described by Sripathi Krishnan, one can programmatically de-obfuscate GWT’s Javascript files in order to enumerate all of the exposed method calls. This typically leads to the discovery of vulnerable un-used or administrative methods that may not normally be seen during normal application use. It is worth noting that this technique can usually be performed anonymously, potentially leaving a GWT application open to attack if authentication and authorization checks are not properly performed. What follows is a short walkthrough of Krishnan’s enumeration technique along with a tool that I wrote to automate the process.

De-obfuscating the Javascript
First, it is worth noting that not all GWT applications you will encounter will be obfuscated. GWT applications can be compiled in one of the following three modes:

Obfuscated: Javascript is obfuscated and minified to reduce the size of the generated files. This is the default compilation mode for GWT applications.

Pretty: Generated Javascript is human readable

Detailed: Javascript code contains even more detail, such as verbose variable names.

When a GWT application first loads in the browser, the main entry page will typically call a Javascript file with the “.nocache.js” suffix. This file is responsible in detecting the browser type and loading the correct browser-specific Javascript code for the GWT application. Most of the core GWT client logic is kept inside files with the “.cache.html” suffix. These are ultimately the files we are most interested in since they also contain the logic responsible for invoking GWT-RPC calls.

Before we dive into the de-obfuscation logic, let’s start by analyzing the similarities between Javascript created when the GWT application is compiled in “obfuscated mode” versus “pretty mode” to see how RPC calls are performed. Below is the “pretty” version a generic “greetServer” method call which accepts one string parameter.

Pretty Mode

function $greetServer(this$static, arr, callback){
    var $e0, payload, requestId, streamWriter, clientSerializationStreamWriter;
    requestId = requestId_0++;
    !!$stats && $stats({moduleName:$moduleName, sessionId:$sessionId,
          subSystem:'rpc', evtGroup:requestId,
          method:'GreetingService_Proxy.greetServer', millis:(new Date).getTime(), type:'begin'});
    try {
        append(streamWriter.encodeBuffer, '' + $addString(streamWriter, 'com.gwttest.client.GreetingService'));
        append(streamWriter.encodeBuffer, '' + $addString(streamWriter, 'greetServer'));
        append(streamWriter.encodeBuffer, '1');
        append(streamWriter.encodeBuffer, '' + $addString(streamWriter, '[Ljava.lang.String;/2600011424'));
        $writeObject(streamWriter, arr);
        payload = $toString_3(streamWriter);
        $doInvoke(this$static, ($clinit_187() , 'GreetingService_Proxy.greetServer'), requestId, payload, callback);

By analyzing this method call, we see a hash table is assigning the “method” key a string value containing the GWT-RPC service and method name ( ‘GreetingService_Proxy.greetServer’ ). Within a try block we also see the building of a GWT-RPC Payload string which contains how many parameters the method expects (One Parameter)

append(streamWriter.encodeBuffer, '1');

and the data type it is expecting (String)

append(streamWriter.encodeBuffer, '' + $addString(streamWriter, '[Ljava.lang.String;/2600011424'));

Now, search through the obfuscated version of the same GWT application using the following regular expression:

"^function \w+\(.*method\:([A-Za-z0-9_\$]+),.*$"

You should eventually encounter a matching method. Below is an example of the obfuscated version of the same method (code expanded for readability)

Obfuscated Mode

function aH(b,c,d){
      var a,f,g,h,i;
      g=Ky++;
      !!$stats&&$stats({moduleName:$moduleName,sessionId:$sessionId,subSystem:AQ,evtGroup:g,
        method:kS,millis:(new Date).getTime(),type:lS});
      h=(i=yy(new vy,b.b,b.e),i.e=0,lK(i.f),lK(i.g),mM(i.h),i.b=DJ(new AJ),iy(i,i.c),iy(i,i.d),i);
      try{
              Ey(h.b,KO+fy(h,mS));
              Ey(h.b,KO+fy(h,nS));
              Ey(h.b,oS);
              Ey(h.b,KO+fy(h,pS));
              hy(h,c);
              f=Cy(h);
              !!$stats&&$stats({moduleName:$moduleName,sessionId:
                      $sessionId,subSystem:AQ,evtGroup:g,
                      method:kS,millis:(new Date).getTime(),type:qS});
              Py(b,(oz(),kS),g,f,d)
..snip..

The highlighted areas of the obfuscated code above are the parts we are most interested in. The service and method name is once again assigned to the “method” element of the hash table. The value of the variable “kS” is assigned towards the end of the same Javascript file.

kS='GreetingService_Proxy.greetServer

Within the “try” block, you’ll see several “Ey” method calls which correspond to the “append” method we previously saw in the “pretty” version. Looking at the second parameter of the 3rd append call we see that the variable “oS” is passed.

Ey(h.b,oS);

By searching the Javascript code for the assigned value of “oS” we see that it is the expected value of “1”.

oS='1'

Moving onto the next append method call

Ey(h.b,KO+fy(h,pS));

the “fy” method call is called, which corresponds to the “$addString” method call seen in the “pretty” version. The value assigned to the second parameter of the “fy” method will provide us the data type the GWT-RPC method is expecting.

pS='[Ljava.lang.String;/2600011424'

As you can see, the process of performing de-obfuscation manually is time consuming and tedious due to the amount of variable tracing involved. For this reason I created GWTEnum, a python tool that automates the process of enumerating GWT-RPC method calls for any GWT application compiled in obfuscated mode.

The Tool
GWTEnum works by analyzing the “nocache.js” file, which contains references to the underlying “cache.html” files where the actual method calls lie. Simply point GWTEnum to the “nocache.js” file and the tool will take care of the rest. A good example of how the tool works can be seen in the following example, where GWTEnum was run against the Whirled.com virtual world website. This site was chosen for this example since it is accessible to the public and uses GWT compiled in obfuscated mode.

>python gwtenum.py –u "http://www.whirled.com/gwt/frame/frame.nocache.js"


Analyzing http://www.whirled.com/gwt/frame/02DA50B7EB86809D55630981FE1D7F1A.cach

e.html
===========================

Enumerated Methods

===========================

FacebookService_Proxy.getStoryFields(com.threerings.msoy.facebook.gwt.FacebookService$StoryKey/2584007011 ) FacebookService_Proxy.trackPageRequest( I,java.lang.String/2004016611 ) FacebookService_Proxy.trackStoryPosted(com.threerings.msoy.facebook.gwt.FacebookService$StoryKey/2584007011,java.lang.String/2004016611,java.lang.String/2004016611 ) WebMemberService_Proxy.escapeTheme( ) WebMemberService_Proxy.getInvitation( java.lang.String/2004016611,Z ) WebMemberService_Proxy.getMemberCard( I ) WebMemberService_Proxy.isThemeManager( I ) WebMemberService_Proxy.noteNewVisitor(com.threerings.msoy.data.all.VisitorInfo/3279131818,java.lang.String/2004016611,Z ) WebMemberService_Proxy.trackTestAction( java.lang.String/2004016611,java.lang.String/2004016611,com.threerings.msoy.data.all.VisitorInfo/3279131818 ) WebUserService_Proxy.getApp( I ) WebUserService_Proxy.getConnectConfig( ) WebUserService_Proxy.loadLaunchConfig( I ) WebUserService_Proxy.validateSession( java.lang.String/2004016611,java.lang.String/2004016611,I,I )

As shown above, we now have a complete list of all accessible RPC methods. Once the available methods have been enumerated, there are several ways to invoke RPC calls to these methods.

The simplest method of invocation would be for cases where you have already encountered another method (through normal site use) that accepts the same number and type of parameters. In this case, you can intercept the original method call with an intercepting proxy like Burp and change the method name in order to execute the new method. There will likely be cases, however, where the new method accepts a unique combination of different parameters than the methods you have already encountered. For these cases, you can use a tool such as GWT SyncProxy in order to invoke GWT-RPC calls using Java.

In summary, GWTEnum aims to eliminate the complexities posed by obfuscated GWT code that normally make testing these applications more difficult. Hopefully application testers out there find this tool and enumeration technique helpful when encountering an obfuscated GWT application. If you encounter any issue while using the tool, feel free to send an email to rgutierrez at gdssecurity.com

GWTEnum can be downloaded here

ISSD Conference

AndrewN — Mon, 17 May 2010 15:17:32 +0000

The very first International Secure Systems Development Conference (ISSD) is being held this week in London, and GDS is very happy to be supporting it from the start as both speakers and conference sponsors. Event details are as follows:

The International Secure Systems Development Conference
London 20-21st May 2010, Westminster Conference Centre
Getting Started in Building Security In

If you are planning on attending, Justin and Matt both speak on Friday (Day 2):

11:15 Managing Business Processes for Secure Software Development – Matt Bartoldus

3:30 Tips & Tricks for Retro-fitting Secure Code – Justin Clarke

Be sure to stop by the GDS booth, as Justin will be signing and giving away a few free copies of his latest book “SQL Injection Attacks and Defense”.

Fuzzing GWT RPC Requests

Ron Gutierrez — Thu, 06 May 2010 17:59:07 +0000

In a previous post, I went through the process of parsing GWT RPC requests to determine the method and parameter values sent. In this post I will discuss, GwtParse, a tool that I wrote to automate this process in order to easily determine the values within a GWT RPC payload that can actually be manipulated. GwtParse can be downloaded here but I recommend you continue reading…

Why use this tool?

Fuzzing every delimited value in GWT RPC requests is not practical and produces a lot of unnecessary output. GWT client side code is heavily obfuscated, which makes it difficult to identify all the fuzzable values passed in the request by reviewing the JavaScript. Additionally, there could be values passed in the request that do not necessarily originate from user input. For example, assume there is a custom “User” object which contains a numeric property that indicates a user’s role membership. Manipulation of this value could result in unauthorized access to data or privileged functionality. The tool I wrote gwtparse.py will help identifying the meaningful values in a GWT RPC request so that you can more easily identify security bugs in GWT applications during a Black Box assessment.

gwtparse.py

A command line tool that parses a GWT RPC payload and creates a new payload value with all fuzzable values identified. This new payload value can then be plugged into the web application fuzzer of your choice. The tool has currently only been tested using GWT version 2.0.

The following types can be parsed:

Primitive Java Types and Object (ie. Integer, Double, Byte, etc )
Strings
Arraylist, Vector, LinkedList
Arrays
Custom Objects ( to a limited extent )

Parsing of custom objects cannot be guaranteed to work correctly in all scenarios as they can be very complex. I created a number of test cases with custom objects, but there is bound to be cases that the current version of my tool cannot handle. I just want to point out a couple key points:

Parsing a GWT RPC request is as simple as follows

$ python gwtparse.py -i "5|0|12|http://127.0.0.1:8888/gwt_test/|4E7583E4BED25F58DDD5F1A1D675522A| com.gwttest.client.GreetingService|greetServer|java.util.ArrayList/3821976829| com.gwttest.client.CustomObj/427743781|com.gwttest.client.Person/2847577871| PersonName|java.lang.Integer/3438268394|CustomObjParam1|CustomObjParam2| CustomObjParam3|1|2|3|4|2|5|6|5|2|7|200|8|7|200|8|6|9|200|10|11|12|10|"

Output from above command:

GWT RPC Payload Fuzz String

5|0|12|http://127.0.0.1:8888/gwt_test/|4E7583E4BED25F58DDD5F1A1D675522A| com.gwttest.client.GreetingService|greetServer|java.util.ArrayList/3821976829| com.gwttest.client.CustomObj/427743781|com.gwttest.client.Person/2847577871| %s|java.lang.Integer/3438268394|%s|%s|%s|1|2|3|4|2|5|6|5|2|7| %d|8|7|%d|8|6|9|%d|10|11|12|10|

The default output of the script replaces the fuzzable string values with a %s and numeric values with a %d. This is incredibly useful since Java is a strong typed language and will throw an exception if a string value is passed anywhere the application is expecting an Integer.

Tool output can be customized so that the fuzzable values are easily recognized by your favorite fuzzer. This is done with the “-s” option, which surrounds the values with the string/character of your choice.

For Burp Suite users, there is the “-b” switch to surround the values using the Burp Intruder Position Value (Section Sign). Note that the Section Sign character is only output to the command-line when run within a terminal that can output UTF-8 values (i.e. Linux, Cygwin). Windows users can add the “-w” or “-a” switches to write or append the output to a text file.

Lastly, there is the “-p” switch that displays the request in a human readable format. This can be especially useful in identifying the values which belong to a custom object. I have included an example of this at the end of my post.

The gwtparse.py program simply calls functionality available within my GWTParser object. The GWTParser object can be easily reused by testers within their own python fuzzers or tools. Hopefully, application testers will find the tool useful when tackling a GWT application assessment.

If you find GWT RPC payload strings which are not properly handled by my tool (which I am sure there will be), send an email to rgutierrez at gdssecurity.com and I will work on incorporating a fix for the next version. GwtParse can be downloaded here

Sample output when using the –p Switch to Display GWT RPC Requests in Human Readable Format

Serialized Object:

5|0|12|http://127.0.0.1:8888/gwt_test/|4E7583E4BED25F58DDD5F1A1D675522A| com.gwttest.client.GreetingService|greetServer|java.util.ArrayList/3821976829| com.gwttest.client.CustomObj/427743781|com.gwttest.client.Person/2847577871| PersonName|java.lang.Integer/3438268394|CustomObjParam1|CustomObjParam2| CustomObjParam3|1|2|3|4|2|5|6|5|2|7|200|8|7|200|8|6|9|200|10|11|12|10|

Stream Version: 5 Flags: 0 Column Numbers: 12 Host: http://127.0.0.1:8888/gwt_test/ Hash: 4E7583E4BED25F58DDD5F1A1D675522A Class Name: com.gwttest.client.GreetingService Method: greetServer # of Params: 2


Parameters:

{'flag': False,

'is_array': False,

'is_custom_obj': True,

'is_list': True,

'subtype': 'com.gwttest.client.Person',

'typename': 'java.util.ArrayList/3821976829',

'values': [,

]}
{        'flag': False,

'is_array': False,

'is_custom_obj': True,

'is_list': False,

'typename': 'com.gwttest.client.Person/2847577871',

'values': [200, 'PersonName']}

{         'flag': False,

'is_array': False,

'is_custom_obj': True,

'is_list': False,

'typename': 'com.gwttest.client.Person/2847577871',

'values': [200, 'PersonName']}

{'flag': False, 'is_array': False, 'is_custom_obj': True, 'is_list': False, 'typename': 'com.gwttest.client.CustomObj/427743781', 'values': [200, 'CustomObjParam1', 'CustomObjParam2', 'CustomObjParam3', 'CustomObjParam1']}

The above “pretty” output shows that the RPC call has two parameters. The first parameter is an ArrayList of Person Objects with two member variables and the second parameter is another object called CustomObj which has five member variables.

OWASP NYNJMetro – Pentesting Adobe Flex Applications

Marcin Wielgoszewski — Fri, 23 Apr 2010 13:20:56 +0000

I’ve uploaded my slides from the presentation I gave last week at the OWASP NYC Chapter on Pentesting Adobe Flex Applications.

In an upcoming post, I’ll describe in detail working with custom objects and how to craft AMF messages containing them and other data types.

Penetrating Intranets through Adobe Flex Applications

Marcin Wielgoszewski — Wed, 17 Mar 2010 15:23:35 +0000

In my last post, Pentesting Adobe Flex Applications with a Custom AMF Client, I described how one could write a client using Python and PyAMF to perform manual penetration testing of Flex applications. The example application I focused on utilized RemoteObjects and communicated via binary AMF encoded messages, a common roadblock for security testers. If you are new to penetration testing Flex applications, I suggest reading my previous post to familiarize yourself with Flex and the techniques I discussed.

In this post, I’ll show how you can exploit Flex applications that use BlazeDS to gain access to internal networks and other hosts behind the firewall. BlazeDS is a Java-based remoting server that allows developers to utilize existing application logic and web services in Flex applications. The following also applies to applications that use Adobe LiveCycle Data Services ES.

A common insecure configuration that we encounter when assessing Flash applications is an insecure crossdomain.xml policy file (usually hosted within a web site’s root directory). By default, a Flash application hosted on domain A cannot access resources from domain B unless domain B has configured their cross-domain policy to allow domain A. More often than not, the cross domain policy file has been configured to allow the entire world access rather than a specific list of trusted domains. Now, assuming the cross domain policy file has been secured, developers of Flex applications that consume data from external web services must now incorporate this restriction into their design. This makes it difficult to develop Flex applications that will be hosted on multiple, possibly untrusted domains.

Enter BlazeDS. To get around the restrictions imposed by cross-domain policy files, BlazeDS allows developers to configure “Proxy Services”. Using Proxy Services, BlazeDS will make calls to remote service destinations on behalf of the Flex application. BlazeDS Proxy Services allows Flex applications to consume SOAP and Web Services hosted on other domains without the need for a cross-domain policy. A common use case for proxy services is to allow external access to internally hosted web services via a specified destination. A typical proxy service is configured like so (see BlazeDS Developer Guide for more detail):

# contents of WEB-INF\flex\proxy-config.xml:

  ...
  
  
    
      http://ws.localdomain:9899/web/service/content.jsp
    
  
  
  
    
      http://ws.localdomain:9899/ws?wsdl
      *

In the proxy-config.xml above, we have two destinations defined: web-service and soap-service. If you look closely, the soap property has an asterisk (wildcard) defined. This property can define an absolute domain and path, however like cross-domain policies, an asterisk permits BlazeDS to make requests to any hosts it can reach on the network that match this property. This is a common occurrence, due in part to sample configuration files supplied with BlazeDS and lack of awareness on part of those responsible for securing the application server. In more secure configurations, this property is set to a strict domain or path (such as the web-service destination).

If you want to build a Flex client that communicates with Proxy Services, you’ll need to familiarize yourself with the following objects (refer to the Flex Language Reference for more information):

mx.rpc.http.HTTPService (url)
mx.rpc.http.mxml.HTTPService(url)
mx.messaging.messages.HTTPRequestMessage (url)
mx.rpc.soap.WebService (endpointURI)
mx.rpc.soap.mxml.SOAPService (endpointURI)
mx.messaging.messages.SOAPMessage (url)

Without further ado, I’d like to introduce Blazentoo, a tool I developed to exploit such functionality. With Blazentoo, you can exploit insecurely configured Proxy Services and browse internal websites, potentially those on trusted corporate networks. Just recently I was working on an assessment and I was able to successfully compromise an internal application via an exposed BlazeDS server – as this wasn’t the first (or last) time, I decided it was time to build Blazentoo.

To use Blazentoo, you’ll need to know the following (most of this information can be obtained by examining HTTP requests proxied through a tool like Burp Suite, Charles Proxy, or WebScarab):

AMF/HTTP endpoint (the message broker servlet that flex requests are routed to)
The “destination” id (if this is left blank, the DefaultHTTP destination is used)
An optional “channel” id (leave blank if unknown)

If using SOAP, you’ll need to know the following additional information:

A SOAP Action associated with the destination id, and/or
URL of the WSDL (required if no destination id is defined)

Below is a screenshot of Blazentoo in action. Note that the URL being accessed in this example is “http://localhost/”. This could just as easily have been an internal IP address or hostname.

You can download Blazentoo from our tools page.

Multiple DOM-Based XSS in Dojo Toolkit SDK

Bix — Fri, 12 Mar 2010 19:11:33 +0000

We released an advisory today to Bugtraq regarding a DOM-Based XSS bug I found in the Dojo Toolkit SDK 1.4.1 and earlier versions. The Dojo team was informed on February 19, 2010 and released the fix today along with some other security bugs. If you want some more information on this bug as well as the other bugs that were fixed, see their security bulletin.

The files identified with the XSS issues are primarily designed for testing; however a quick Google search will identify numerous sites that have deployed these files along with the core framework components. Unfortunately, this is evidence of a much larger issue. All too often, test code gets deployed to production and ultimately leads to a security exposure. This is clearly a recipe for disaster!!! Folks, please clean up your web root. You clean up your house when relatives come by, right? You wouldn’t want them tripping over your GI Joe’s and breaking their leg! It’s the same thing, more or less : )

Overview

The Dojo Toolkit is an open source modular JavaScript library/toolkit designed to ease the rapid development of cross platform, JavaScript/Ajax based applications and web sites. Multiple instances of DOM-based Cross Site Scripting (XSS) vulnerabilities were found in the _testCommon.js and runner.html files within the SDK. The XSS vulnerabilities appear to affect all websites that deploy any of the affected SDK files.

More information on DOM-based XSS can be found at OWASP’s site.

Technical Details

File: dojo-release-1.4.1-src\dojo-release-1.4.1-src\dijit\tests\_testCommon.js
1) Data enters via “theme” URL parameter through the window.location.href property.
Line 25:
var str = window.location.href.substr(window.location.href.indexOf("?")+1).split(/#/);
..snip..
2) The “theme” variable with user-controllable input is then passed into “themeCss” and “themeCssRtl” which is then passed to document.write().

Writing the un-validated data to HTML creates the XSS exposure.
Line 54:
..snip..
var themeCss = d.moduleUrl("dijit.themes",theme+"/"+theme+".css"); var themeCssRtl = d.moduleUrl("dijit.themes",theme+"/"+theme+"_rtl.css"); document.write(''); document.write('');

==================================================

File: dojo-release-1.4.1-src\dojo-release-1.4.1-src\util\doh\runner.html
1) Data enters via “dojoUrl” or “testUrl” URL parameters through the window.location.search property.
Line 40:
var qstr = window.location.search.substr(1);
..snip..

2) The “dojoUrl” and “testUrl” variables with user-controllable input are passed to document.write(). Writing the un-validated data to HTML creates the XSS exposure.
Line 64:
document.write(""); ..snip.. document.write("");

Proof-of-Concept Exploit

This vulnerability can be exploited against websites that have deployed any of the 145 SDK files which reference _testCommon.js.

Reproduction Request:
http://WebApp/dijit/tests/form/test_Button.html?theme=”/>

(Note: test_Button.html is one of the SDK files that includes the _testCommon.js file)

==================================================

This vulnerability can be exploited against any website that has deployed the runner.html file.

Reproduction Request:
http://WebApp/util/doh/runner.html?dojoUrl=’/>foo<’”

Recommendation

Update to Dojo Toolkit SDK 1.4.2

Abusing WCF to Perform Remote Port Scans

Brian Holyfield — Fri, 12 Feb 2010 13:00:47 +0000

Last weekend at Shmoocon, I demonstrated how an attacker can trick certain WCF web services into performing an unauthorized port scan of machines behind a firewall. For those that were not able to attend the talk, the slides are posted here. The part that covers the port scanning technique may not be clear in isolation, so I’ll try and explain it in detail. The problem is related to the WSDualHttpBinding, so in order to understand how the scanning technique works you must first understand some WSDualHttpBinding basics.

The WSDualHttpBinding

The WSDualHttpBinding is one of several “Duplex” WCF bindings. The term Duplex refers to the bi-directional nature of the communication channel, meaning that both the client and the service can directly send messages to each other. This is ideal for scenarios where a service needs to “push” data down to a client, rather than the alternative of constantly polling the server for a callback. In order to do this over HTTP, which is by nature a one-way protocol, WCF sets up a dedicated HTTP listener port on the client that accepts incoming HTTP requests from the service (known as the callback channel). If you are like me, you probably just raised an eyebrow when I said that WCF sets up an inbound HTTP listener on the client machine. This scenario sounds odd from a security perspective, which is what initially caught my eye.

The first step in establishing a session with WSDualHttpBinding requires the client and server to negotiate the duplex connection. This negotiation is a required part of the connection sequence, and is the mechanism that can be abused to perform remote port scanning. The negotiation starts with the client sending a “CreateSequence” SOAP request to the web service endpoint. A typical CreateSequence request is shown below.

As you can see, the CreateSequence request includes a “ReplyTo” address. This address is the URL of the callback channel at which the client expects to receive callback requests from the service. When the service receives this request, it reacts by initiating a “CreateSequenceResponse” to the ReplyTo address, and then responding to the original request with a “202 Accepted”. Conceptually this is represented by the diagram below. Note that the circled numbers represent the order in which each request and response occurs.

The scenario above represents the intended chain of events for a CreateSequence negotiation. There are a few important things to note:

There are two separate HTTP conversations occurring. One is between the client and the service over port 80, and the other is between the service and the client on port 8000.
When the service receives a CreateSequence request, it will immediately attempt to issue the CreateSequenceResponse request to the address that is passed within the ReplyTo value. This does NOT have to be the same address (or port) where the CreateSequence request originated from.

Next, let’s introduce another slightly more complex example. In this scenario, we have 4 machines:

The client, which in this case will end up being the bad guy
The WCF service that uses WSDualHttpBinding
Two unrelated hosts that will serve as targets

The client in this case will send two CreateSequence requests to the service. The first request will include a ReplyTo address of Target1, and the second request will include a ReplyTo address of Target2. Again, the circled numbers represent the order in which each request and response occurs.

This diagram is much more interesting as it depicts what is certainly NOT an intended use case. As illustrated above, the first CreateSequence request (1) causes the service to initiate a connection to Target1 on port 8000, just as the second CreateSequence request (4) does to Target2. Even more interesting is that the “Accepted” HTTP response (7) to the second CreateSequence request (4) does not occur until AFTER the connection to Target1 times out (5). This means that the delay between the second CreateSequence (4) and the subsequent “Accepted” response (7) was directly related to the response time of the first CreateSequenceResponse attempt (5). It appears that a WCF service will not respond to a new CreateService request until all previous CreateSequenceResponse requests have either been acknowledged or timed out.

What Does this Mean?

Based on the behavior described above, the CreateSequence HTTP response delay is an effective mechanism to determine the state of a prior connection request. By issuing multiple requests to different hosts and ports, we can use this behavior to probe remote hosts from the server hosting the WCF service. Depending on the connectivity available from the host, we can even probe systems that would not otherwise be available to us (such as on an internal network or DMZ).

In order to prove this theory, I wrote a utility to issue successive CreateSequence requests to a WCF service that each have a different ReplyTo address and/or port. It measures the time between a CreateSequence request and the “202 Accepted” response in an attempt to determine whether a previous request was successful. The utility is fairly simple and operates as follows (assume that Service is the WCF service we want to mis-use, and that the Target is the machine we want to port scan):

Request #1: Issue a CreateSequence request to Service which will ReplyTo Target on Port 1. The delay (if any) on this first request is not associated with a connection we initiated so the timing of this first response is ignored.
Request #2: Issue another CreateSequence request to Service which will ReplyTo Target on Port2. A timer is used to measure the time between this request the “202 Accepted” response from Service. This response will not occur until the previous CreateSequenceResponse has been acknowledged or timed out. As such, this delay will be used to infer the outcome of the probe caused by Request #1.
Request #3: Issue a CreateSequence request to Service which will ReplyTo Target on Port3. A timer is used to measure the time between this request the “202 Accepted” response from Service. This response will not occur until the previous CreateSequenceResponse has been acknowledged or timed out. As such, this delay will be used to infer the outcome of the probe caused by Request #2.
and on and on and on…

Proof of Concept

As a proof of concept, I deployed an instance of the MSDN CalculatorDuplex sample service to a virtual machine in the Microsoft Azure cloud to use as a test case. This service is a simple calculator web service that uses the WCF WSDualHttpBinding. As it turns out, the Azure environment was a great place to test this concept since Azure VMs actually reside on an internal private 10.x.x.x network behind a firewall. Conceptually, this is represented in the diagram below (note, this is an over simplified diagram based on what I have seen in my limited testing with Azure).

Based on an analysis of the VM running the sample service, it also appeared that the VMs within the Azure environment typically run IIS on port 20000. I used the utility to remotely scan other VMs within the 10.x.x.x address space on this port through requests to the Calculator service. The results from the initial test are shown in the screenshot below.

As you can see, the result of each probe is inferred based on the average response time of the other requests. The scan above shows that four of the probes returned very quickly (around 114 ms) while the others appear to have timed out. The probes that do not time out in this case are the other internal VMs that are up and running IIS on port 20000. As a second test, I used the utility to probe ports on the localhost of the machine running the Calculator service. As you can see below, the probe to port 3389 times out while the others return after about 1 second. So in this case, the Remote Desktop service is running on the localhost.

So to summarize, this appears to be a potential design flaw within the WCF create sequence negotiation process. As a result, any service that uses this binding can be abused by a remote user to scan other hosts (even those behind a firewall that they may not otherwise have access to). Certain web-based attacks can also be proxied through these services since the remote attacker has the ability to control not only the target address and port, but also the complete URI that will be requested. The source code for the scanner utility is posted here for reference.

Breaking Password Based Encryption with Azure

Brian Holyfield — Fri, 29 Jan 2010 21:02:20 +0000

During a recent security review, we came across a .NET application that was encrypting query string data to thwart parameter based attacks. We had not been given access to the source code, but concluded this since each .aspx page was being passed a single Base64 encoded parameter which, when decoded, produced binary data with varying 16 byte blocks (likely AES considering it is the algorithm of choice for many .NET developers).

The Code

After doing some research (aka plugging the words “.NET”, “Query String” and “Encryption” into Google), we identified several references to a piece of code that had been written and published a few years back for encrypting query strings in .NET. The code we found even used the same parameter name as our application did to pass the encrypted query string data to each page, so we were fairly confident it was the code they were using.

Having written SPF, I am always interested to see how other applications implement cryptography since I know it is not always easy to do properly. In addition to the common problem of re-using the same IV for every encrypted query string, we noticed that the key was entirely derived from a static password embedded in the code (it was being derived using the .NET Framework PasswordDeriveBytes class directly from the literal string value “key”).

For reference, I’ve included the Decrypt method below:

  private const string ENCRYPTION_KEY = "key";

  public static string Decrypt(string inputText)
  {
    RijndaelManaged rijndaelCipher = new RijndaelManaged();
    byte[] encryptedData = Convert.FromBase64String(inputText);
    byte[] salt = Encoding.ASCII.GetBytes(ENCRYPTION_KEY.Length.ToString());
    PasswordDeriveBytes secretKey = new PasswordDeriveBytes(ENCRYPTION_KEY, salt);

    using (ICryptoTransform decryptor = rijndaelCipher.CreateDecryptor(secretKey.GetBytes(32),

    secretKey.GetBytes(16)))
    {
      using (MemoryStream memoryStream = new MemoryStream(encryptedData))
      {
        using (CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Read))
        {
          byte[] plainText = new byte[encryptedData.Length];
          int decryptedCount = cryptoStream.Read(plainText, 0, plainText.Length);
          return Encoding.Unicode.GetString(plainText, 0, decryptedCount);
        }
      }
    }
  }

Password based encryption schemes like this are common in many applications, since the key can easily be represented by a word or passphrase. The nice thing from an attacker’s perspective is that regardless of how large the real encryption key is, the feasibility of a brute force attack is largely dependent on the length and complexity of the password used to derive the key and not the key itself. So for this example, even though they are using 256-Bit AES encryption (generally considered secure), the password used to generate the key is easily brute forced since it is only 3 characters.

Given the code we found, the first and obvious test was to try decrypting our query string values with the same “key” string. Sadly that didn’t work. After trying several educated guesses at what we thought could be the password, I decided to clone the decryption logic into a .NET console utility and run a recursive alphanumeric brute force against the password. The approach was rather simple:

Take one of our encrypted samples
Loop through every alphanumeric character combination
Using the identical logic shown above, derive the key and decrypt

The caveat here is that we really don’t know what value to expect when it decrypts, but chances are it should be just ASCII text (and hopefully a query string name/value pair). The good news is that most of the keys we generate will generate a CryptographicException, so we can rule out any key value that results in this exception. For safety’s sake I decided to convert the results of every successful decrypt to ASCII and save for further review if needed.

The Cloud

After running the utility for an hour or so I realized that a laptop Windows instance was not the optimal environment for running a brute force password crack (not to mention it rendered the machine pretty useless in the meantime). Having recently signed up for a test account on the Microsoft Azure cloud platform for some unrelated WCF testing, I thought this would be a great opportunity to test out the power of the Microsoft cloud. Even better, Azure is FREE to use until February 1, 2010.

The concept of using the cloud to crack passwords is not new. Last year, David Campbell wrote about how to use Amazon EC2 to crack a PGP passphrase. Having never really worked with the Azure platform (aside from registering for a test account), I first needed to figure out the best way to perform this task in the environment. Windows Azure has two main components, which both run on the Azure Fabric Controller (the hosting environment of Windows Azure):

Compute – Provides the computation environment. Supports “Web Roles” (essentially web services and web applications) and “Worker Roles” (services that run in the background)
Storage – Provides scalable storage (Blobs, Tables, Queue)

I decided to create and deploy a “Worker Role” to run the password cracking logic, and then log all output to a table in the storage layer. I’ll spare you the boring details of how to port a console utility to a Worker Role, but it’s fairly simple. The first run of the Worker Role was able to produce approximately 1,000,000 decryption attempts every 30 minutes, or about 555 tries/second. This was definitely faster than the speed I was getting on the laptop, but not exactly what I was hoping for from “the cloud”.

I did some research on how the Fabric Controller allocates resources to each application, and as it turns out there are 4 VM sizes available as shown below:

Compute Instance Size	CPU	Memory	Instance Storage	I/O Performance
Small	1.6 GHz	1.75 GB	225 GB	Moderate
Medium	2 x 1.6 GHz	3.5 GB	490 GB	High
Large	4 x 1.6 GHz	7 GB	1,000 GB	High
Extra large	8 x 1.6 GHz	14 GB	2,040 GB	High

The size of the VM used by the Worker Role is controlled through the role properties that get defined when the role is configured in Visual Studio. By default, roles are set to use the “small” VM, but this is easily changed to another size. The task at hand is all about CPU, so I increased the VM to “Extra Large” and redeployed the worker role.

Expecting significant performance gains, I was disappointed to see that the newly deployed role was running at the same exact speed as before. The code was clearly not taking full advantage of all 8 cores, so a little more research led me to the Microsoft Task Parallel Library (TPL). TPL is part of the Parallel Extensions, a managed concurrency library developed by Microsoft for .NET that was specifically designed to make running parallel processes in a multi-core environment easy. Parallel Extensions are included by default as part of the .NET 4.0 Framework release. Unfortunately Azure does not currently support .NET 4.0, but luckily TPL is supported on .NET 3.5 through the Reactive Extensions for .NET (Rx).

Once you install Rx, you can reference the System.Threading.Tasks namespace which includes the Parallel class. Of specific interest for our purpose is the Parallel.For method. Essentially, this method executes a for loop in which iterations may run in parallel. Best of all, the job of spawning and terminating threads, as well as scaling the number of threads according to the number of available processors, is done automatically by the library.

As expected, this was the secret sauce I had been missing. Once re-implemented with a Parallel.For loop, the speed increased significantly to 7,500,000 decryption attempts every 30 minutes, or around 4,200 tries/second. That’s 1M tries every 4 minutes, meaning we can crack a 5 character alphanumeric (lowercase) password in about 4 hours, or the same 6 character equivalent in about 6 days. This is still significantly slower than the speed obtained by Campbell’s experiment, but then again he was using a distributed program designed specifically for fast password cracking (as opposed to the proof of concept code we are using here), not to mention I am also logging output to a database in the storage layer. At the time of writing, the password hasn’t cracked but the worker process has only been running for about 24 hours (so there’s still plenty of time). What remains to be seen is how fast this same code would run in the Amazon EC2 cloud, which may be a comparison worth doing.

The important takeaway here is not about the power of the cloud (since there’s nothing we can do to stop it), but rather about Password Based Encryption. Regardless of key length and choice of algorithm, the strength of your encryption always boils down to the weakest link…which in this case, is the choice of password.

WCF Binary Soap Plug-In for Burp

Brian Holyfield — Fri, 20 Nov 2009 00:38:55 +0000

Update 2010: With the official release of Burp Suite v1.3, both plug-ins discussed in this post can be used with either Pro or Free versions of Burp.

If you run into a Silverlight application that consumes WCF, there’s a good chance it will use Binary XML Message Encoding to send data between the Silverlight client and the WCF endpoint. These messages usually include a Content-Type: application/soap+msbin1 header to indicate that they are using Microsoft’s .NET Binary Format for SOAP (NBFS). From an attack perspective, the main problem with this encoding format is that you can’t simply edit requests or responses on-the-fly like you would with text-based SOAP messages, since the recipient of the message expects the data to be properly encoded (otherwise it will throw an exception) and, as such, will throw an exception if it’s not.

My initial research into what security tools support NBFS didn’t turn up much. The only option I found were two WCF Binary Inspectors for Fiddler (one here written by Richard Berg, and another here written by Samuel Jack). Both of these inspectors are essentially plug-ins for Fiddler that add support to view NBFS encoded data. Originally these both looked like the solution I was after, however upon further analysis I realized that while those plug-ins let you VIEW encoded messages, they don’t let you EDIT them. I decided it would be a worthwhile effort to try and leverage the plug-in architecture of Burp Suite (through use of the BurpExtender interface) to write a NBFS plug-in for Burp.

The Solution (sort of)
Not wanting to re-invent the wheel, I figured I would leverage the work that had already been done with Fiddler by calling into one of the existing Fiddler libraries from Burp. I chose to use Richard Berg’s code since it looks like it can be ported entirely to Java down the road if needed (it doesn’t rely on WCF’s built-in decoder). Luckily for me, his code also had all of the methods needed to both encode and decode message data.

The way the plug-in works is pretty simple…when a request comes in, the processProxyMessage method of BurpExtender is used to check whether the requests should be decoded and, if so, passes the request data to the C# library. The C# library decodes the message and returns the plain-text version back to Burp. As requests exit Burp, the processHttpMessage method of BurpExtender is used to determine whether the request needs to be re-encoded and, if so, calls into the C# library again.

There are a couple of interesting points to note here:

The processHttpMessage of BurpExtender is currently only supported in the Professional version of Burp Suite. It is my understanding that this method will be supported in the Free version starting with the next release (v1.3) but for now only licensed users of Burp pro have access to this extender method.
Both the processProxyMessage AND processHttpMessage methods of BurpExtender alway fire BEFORE a response can be edited by the user. Unfortunately this precludes the Plug-in from being able to re-encode RESPONSE messages should the user want to edit one.

What this means is that you’ll need to resort to the proxy chaining as a workaround for this if you use the Burp Free Edition (explained in more detail below). Additionally, even if you use Burp Professional Edition, you’ll need to use this workaround if you want to edit RESPONSE data (REQUEST data can be edited on the fly with a single instance of Burp Professional).

Plug-In Versions
There are two version of the Burp plug-in available:

Burp Professional Edition Plug-in: Allows binary requests to be edited on the fly. This version does not support editing of response data. Pro users can use the Free Edition Plug-in with Burp Professional for editing response data.

Burp Universal Plug-in: The Universal Plug-in works with both Free and Professional Editions of Burp and supports editing of binary REQUESTS and RESPONSES. The caveat to using this version of the plug-in is that you’ll need to chain two burp instances together as outlined in the diagram below for the plugin to work properly.

The purpose of chaining two proxies together is as follows:

The first instance handles decoding requests, intercepting (and editing) requests, and re-encoding edited responses. Set this instance to intercept REQUESTS only (not responses) and to use the 2nd proxy as the next hop.
The second instance handles re-encoding edited requests, decoding responses, and intercepting (and editing) responses. Set this instance to intercept RESPONSES only (not requests).

Each proxy will add or remove a custom header (X-WCF-Proxy: must-encode) to edited requests/responses which they use to notify each other of whether re-encoding of a message is necessary. This custom header is removed when read by the plug-in, so it shouldn’t ever get disclosed to the target system.

Albeit it slightly crude, I didn’t see much in the way of a better work around (I am certainly open to suggestions if anyone has any). It should be noted that this workaround is ONLY necessary if you are using the Free Edition (1.2.x) of Burp Suite OR if you want to want to edit WCF binary response content using Burp Professional Edition. Editing WCF binary request data is supported with a single instance of the Burp Professional Plug-In.

Next Steps
These plug-ins were created as a proof of concept for the talk at OWASP AppSec DC 2009. Looking forward, the C# decoding library should easily port to pure Java since it doesn’t make use of the native WCF decoding classes. This would not only eliminate cross-language calls but would also make the plug-in platform independent (since the implementation would be in pure Java). The drawback to this approach, of course, is that we would be using a home grown decoder for a proprietary Microsoft protocol that could change down the road.

In any case, hopefully the plug-ins will be useful in the short term until more security tools include native support for NBFS messages. You can find both versions of the plug-in available for free on our tools page.