When performing an assessment of a web application I’ll spend most of my time in the History tab under the Proxy tab quite a bit. By default Burp will append the latest request to the bottom of that History log which means that I have to keep scrolling down to see my latest request to the application. This can be annoying and it’s better if my latest request were at the top of the History log. Luckily this is an easy fix with the proper sort in the History tab, simply click on the first column which will keep your latest request at the top.
Category: proxy
This will be a quick and simple tip that you may not have been aware of, you can rename tabs within Burp. A friend of mine who works out of Raleigh turned me onto this. I find new sometimes obvious and hidden features in Burp all the time and this is one of them.
I find this feature handy especially in a large application as I can easily keep track of what I’m testing. I use the tab renaming on the Repeater and Intruder functionality. In order to rename a tab simply double click the tab which will allow you to edit the tab.
Repeater before
Repeater after
Intruder before
Intruder after
Hope this simple tip helps you perform better application pen testing.
Sometimes when you want to grab the bleeding edge version of software you’ll need to utilize subversion (SVN). You can go and read Wikipedia’s take on SVN but basically SVN can be used to grab the latest snapshot of software. Grabbing Metasploit through SVN is the best way to get the latest exploits, payload, scanners, and auxiliary components. If you were to grab Metasploit from it’s main page you would be missing a lot of that functionality, this is where SVN comes into play. Unfortunately I’m not able to grab the latest version of Metasploit because my organization has restrictive firewalls and proxies preventing me from using the SVN protocol. So the best way around this problem is to wrap the application, SVN in this case, inside of a tunneled proxy for transporting. The best implementation I’ve found for doing that is using SOCKS proxies.
The basic goal of this article is to explain to others how to tunnel an application in a SOCKS proxy that doesn’t support SOCKS proxies. A SOCKS proxy is another network protocol but what’s special about SOCKS is that it doesn’t rely on the underlying packet to do it’s routing. SOCKS handles the routing and basically just creates an envelope for whatever it’s “wrapping up”. SOCKS can work with lots of protocols (HTTP, FTP, SMTP, etc) and lots of applications (Firefox, Internet Explorer, OpenSSH, etc). One useful example of using a SOCKS proxy is tunneling HTTP traffic through an SSH tunnel. This can be accomplished because both Firefox and SSH have support for SOCKS proxies. Refer to my earlier article concerning tunneling HTTP over SSH. One application / protocol that SOCKS does not work with is SVN, so then how can you tunnel SVN. Proxychains to the rescue.
Proxychains is the coolest thing since sliced bread. If an application doesn’t support SOCKS then Proxychains will make it support SOCKS. Proxychains basically SOCKSifies applications. The main reason to SOCKSify an application is so that you can tunnel it through SSH because SSH supports SOCKS. So how do you download Metasploit through restrictive firewalls? The answer is ProxyChains + SVN + SSH = latest Metasploit. So enough with the yip yapping how does all this work, below are instructions.
Requirements
- Internet facing listening SSH server
- Linux client (client being your laptop or desktop) with SSH
- Proxychains on client
- SVN on client
You may could perform all of these steps in Windoze but why would you? Besides all of my instructions will be Linux based. Once you’ve got Proxychains installed (see proxychains INSTALL file) the next thing to do is edit it’s config file proxychains.conf. In my situation all I had to modify were two lines. I first commented out the line that says dynamic_chain as seen below.
# only one option should be uncommented at time,
# otherwise the last appearing option will be accepted
#
dynamic_chain
#
Next we’ll tell proxychains to use our localhost as the proxy and which port to connect to. At the very bottom of your conf file you’ll need to add the following.
# add proxy here ...
# meanwile
# defaults set to "tor"
socks5 127.0.0.1 4545
I randomly chose port 4545. I usually choose a port higher than 1024 because you don’t need root privileges to use higher ports. Now your proxychains config file is set. Now let’s create the ssh tunnel.
In my case it would be
The -D flag tells ssh to listen on your localhost (127.0.0.1) and forward that connection to your remote host, in my case 74.208.13.81. Now that you’ve got proxychains configured and your ssh tunnel is up and running you’re ready to go. We don’t need to configure SVN we just need to have the client installed. So now that you’ve got everything up and running simply issue the command below to download the latest Metasploit.
What this final command will do is use proxychains to wrap the SVN protocol into your ssh tunnel thus allowing you to download the latest version of Metasploit behind a restrictive firewall, pretty nifty huh.
Keep in mind this will download metasploit into whatever directory you happen to be in. If for example you wanted to download metasploit into your home directory (e.g /home/travis) then issue the following command.
Also keep in mind that in the above examples proxychains is assumed to be a recognized command and is set in your path. I installed proxychains in my /opt directory so I had to issue the proxychains command below.
Happy sploiting and downloading, hope this explanation helps.
I have finally gotten around to posting a video tutorial of Webscarab. This tutorial merely covers the basics on Webscarab and is a mirror reflection of my written tutorial, Webscarab Tutorial Part 1 (learning the basics). I plan on continuing this video series as I did with my written tutorials. I have always been a fan of video tutorials because they cut right to the chase and show the exact steps how something is performed. I have always frequented the videos on Iron Geek and Milw0rm which have been great resources as well. Don’t forget to maximize the video in the bottom right hand corner of the player, otherwise the video is pointless because you wouldn’t be able to see anything.
The video seems to have some background noise from the audio recording, if anyone has a suggestion for making a better recording I’m all ears. I recorded the screen cast with CamStudio but I also tried Record My Desktop in Linux. I wanted to use Record My Desktop but it was even worse. It could have been my cheap Logitech microphone that was the root cause of the problem? Please post feedback and let me know if these videos are useful, your feedback will determine what content I post in the future.
Part 2 covered the neat functionality of session ID analysis within Webscarab. Now we’ll focus on another great function within Webscarab, fuzzing. I define fuzzing as testing the input of an application by trying various parameters that the input may not expect. These parameters don’t have to be random, in my opinion it’s best when you tailor your parameters depending on the application. When fuzzing you typically want to inject “command & control” parameters into the input to find the most serious vulnerability. For example if a web application is expecting a social security number I may inject html parameters such as ” < / > ” to manipulate the look, feel, and operation of a web application. I don’t want to delve a whole lot into fuzzing because there are books out there that talk about this one subject. This tutorial is going to focus on using Webscarab to fuzz web applications and find vulnerabilities. Hopefully by the end of this tutorial you will better understand the technical aspects of fuzzing as oppose to the concept of fuzzing, but more reading on fuzzing web applications may be required.