burp

Burp is Going to Support PKCS#11

alla — Tue, 26 Mar 2013 09:18:05 +0000

Burp is Going to Support PKCS#11

Great news - PortSwigger is working on PKCS#11 support (SSL client certificates stored on hardware tokens, such as smart cards) for Burp. I got to try the test build - it works perfectly with Belgian eID on Linux.

I am really happy about it - no more awkward chaining of proxies and SSL tunnels to get the job done.

alla Tue, 03/26/2013 - 10:18

Burp plugin for scanning GWT and JSON HTTP requests

alla — Fri, 01 Jun 2012 12:36:34 +0000

Burp plugin for scanning GWT and JSON HTTP requests

Update: Burp Suite Pro 1.4.10 supports JSON scanning out of the box, see http://releases.portswigger.net/2012/06/v1410.html
Update 2: The plugin is released under the terms of GNU GPL. In short it means that you can use it and change it as you like, publish the changes under GNU GPL if you like, but cannot include it as a part of any closed-source software. If you really want to use it as a part of closed-source software, contact me, we can figure something out.

A while ago Alex came up with a solution to get Burp to scan JSON formatted requests. It required a rather involved setup with two Burp listeners and an Apache server acting as a proxy packing and unpacking JSON data for Burp's consumption.

A more straightforward solution to the problem would be making a Burp plugin using BurpExtender interface that parses the request, marks appropriate insertion points and feeds it to Burp.

And now we have it. As a bonus, it is also capable of scanning GWT (Google Web Toolkit) requests. Download the JAR file or the source code.

Running Burp on Unix/Linux:
java -classpath burpsuite_pro_v1.4.07.jar:Gwtscan.jar burp.StartBurp

Running Burp on Windows:
java.exe -classpath burpsuite_pro_v1.4.07.jar;Gwtscan.jar burp.StartBurp

Using the plugin:

Select the reques or requests you want to scan in Burp proxy or target
Select "Actively scan GWT request(s)" or "Actively scan JSON request(s)" from the context menu
That's all

alla Fri, 06/01/2012 - 14:36

Transparent Connection Interception Trick

abb — Wed, 07 Jul 2010 17:09:31 +0000

Transparent Connection Interception Trick

Now when I have a blog for half a year I figured I should post something. So here goes description of using Linux (Ubuntu in my case) bridge configured to redirect selected TCP connections to intercepting proxy (Burp) and while letting the intercepting proxy communicate with the server. Quite useful when doing pentests of fat clients and appliances communicating over HTTP(S), especially in a situation when you can't tamper with client's /etc/hosts file or use other technique to redirect interesting traffic.

Assuming the networking and bridging are configured, there is one thing which needs to be done to start playing with traffic redirection. You should create a group which will be used to designate local processes exempt from traffic redirection. Here I use group name 'noredir' which is hardcoded in 'do_redirect.sh' script, so you have to alter it if you decide to use another group name.

$ sudo addgroup noredir
Adding group `noredir' (GID 1003) ...
Done.

Choose a password and generate a hash for it. You can also just take the one specified below, it corresponds to an empty password.

$ echo -n | mkpasswd 
Password: 
H4ueB58xqisRQ

Set the password for 'noredir' group. (Yes, groups can have passwords. You didn't know? Neither did I.) Edit /etc/gshadow file and change

noredir:!::

noredir:7eVADNYgCIWO6::

Now by issuing 'sg noredir' command you can easily spawn a new shell process with primary GID set to 'noredir'. You will need it to control what iptable rules get applied to traffic generated by programs I use.

$ id
uid=1000(abb) gid=1000(abb) groups=4(adm),20(dialout),24(cdrom),29(audio),46(plugdev),108(lpadmin),123(admin),124(sambashare),1000(abb)

$ sg noredir
Password: 

$ id
uid=1000(abb) gid=10000(noredir) groups=4(adm),20(dialout),24(cdrom),29(audio),46(plugdev),108(lpadmin),123(admin),124(sambashare),1000(abb),10000(noredir)

Now run Burp under 'noredir' group.

$ sg noredir
Password: 
$ java -jar burpsuite_pro_v1.3.jar

Proxy options must be set as following:

loopback only = NO
support invisible = YES

Consider disabling interception until the networking part is working fine. If some of services under attack run over SSL, you may want to provide SSL keys as well. Having one listener for both HTTP and HTTPS traffic has worked out for me.

Now everything is ready to kick off traffic redirection. Create a shell script file like the one shown below and save it in the same directory as do_redirect.sh file available here.

#!/bin/sh -xe

snatip=XXX.YYY.64.57
burpport=8008

. `dirname $0`/do_redirect.sh

reset_redirects
redirect_tcp XXX.YYY.3.187 80 $burpport
redirect_tcp XXX.YYY.3.215 8088 $burpport
redirect_tcp XXX.YYY.8.57 80 $burpport

true

Some explanations regarding redirect_tcp() function are in order.

TCP connections (originated by from local programs and in bridged traffic) heading towards the selected TCP ports get redirected to local TCP port 8008. NB: this port has to be bound to *, ports bound to 127.0.0.1 will not receive redirected traffic. Don't ask me how I know.
Connections originated by Burp (and other programs running under 'noredir' group) don't get redirected. You will know something goes wrong here if Burp hangs and eventually run out of file handles. If you get this it is better to restart Burp.
Connections exempt from redirection get SNAT'ed to the specified IP address. You should manually set 'snatip' to the IP address of the client under attack. This is done to prevent server from noticing requests are coming from another IP address. (The same can be done with source MAC address if needed.) If SNAT'ting is not required, don't set this variable.
All other traffic gets bridged. One notable exception is link-local traffic such as 802.1x. You have to tweak the kernel a bit to make the described approach work on 802.1x-enabled links, check this article for details.

All this is implemented in do_redirect.sh file using iptables and ebtables. Have a look inside if you are interested in how it is actually done.

The end.

abb Wed, 07/07/2010 - 19:09

Enabling SSL/TLS Renegotiation in Java

alla — Tue, 08 Jun 2010 12:40:29 +0000

Enabling SSL/TLS Renegotiation in Java

All the crazy SSL servers seem to come my way - ones that only support weird combinations of protocols and ciphers, ones that require client certificates stored on PKCS#11 hardware, and ones that require SSL renegotiation.

Turns out that Sun has recently disabled SSL/TLS renegotiation in Java by default as a workaround for SSL/TLS renegotiation vulnerability. This becomes a problem when trying to test an HTTPS server that actually requires renegotiation. Burp suite reacts to it with an error message saying "javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message" or, if I enable only TLSv1, with a message saying "javax.net.ssl.SSLHandshakeException: renegotiation is not allowed". I expect that other Java-based proxies, such as WebScarab behave in a similar way.

Fortunately, renegotiation can be explicitly enabled by setting the Java system property system property sun.security.ssl.allowUnsafeRenegotiation to true. For example, to run Burp suite we can do :

java -Dsun.security.ssl.allowUnsafeRenegotiation=true -jar burpsuite_pro_v1.3.04.jar

alla Tue, 06/08/2010 - 14:40