Inside of a .Net environment WCF services can uses the proprietary WCF-Binary-XML protocol as described here.
Because the only implementation for decoding and encoding such binary streams exists in .Net itself (and there mostly with validation and/or auto correction features), we had decided to write our own python library according to Microsoft’s Open Specification.
The library has a rudimentary commandline interface for converting XML to WCF-Binary and vice versa, as well as a plugin for our Burp-Python proxy.
The commandline interface consists of two python scripts:
Script | Description | Examples |
---|---|---|
wcf2xml.py |
|
./wcf2xml.py request.bin
./wcf2xml.py < request.bin
|
xml2wcf.py |
|
./xml2wcf.py request.xml
./xml2wcf.py < request.xml
|
One of fiddlers [http://www.fiddler2.com] advantages are his extensibility and his WCF-Binary plugins. Sadly, this plugins can only decode and display the binary content as XML text.
Our first tool of choice for Webapptests (Burp Suite) has also a plugin feature, and you could also find plugins for decode (and encode XML back to) WCF-Binary streams. But all WCF-Binary plugins out there are based on the .Net library. Therefore you have to use Microsoft Windows, or some Mono constellation. Another disadvantage is the validation and auto-correction of such libraries... not very useful for penetration testing ;-)
That’s why we’ve decided to write a small python library which enables us to decode and encode WCF-Binary streams. In combination with our python-to-Burp plugin (pyBurp) we can decode, edit and encode WCF-Binary streams on the fly.
At the moment you’ll need three Burp instances to use all Burp features. The first one (“Client-Burp”) decodes/encodes the data from/to the client. The second one (“Cleartext-Burp”) operates on the XML like it was a normal request/response. The third one (“Server-Burp”) encodes/decodes the data to/from the server.
A setup without the “Cleartext-Burp” is also possible, but we experienced problems in combination with some Burp features like auto replace.
We are currently working on a one-Burp-solution, but we have to find out the exact communication flow inside of Burp and how we could interact with it (without breaking some things).
After setting up pyBurp, you only have to connect to your current Burp instance, change the current root directory to the path were pyWCFBin is saved and load the WcfPlugin:
$ nc localhost 55666
cd /home/foo/Downloads/pyWCFBin
add WcfPlugin
quit
$
The pyWCFBin plugin must only be used on the Client-Burp and Server-Burp.