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

1. Internet facing listening SSH server
2. Linux client (client being your laptop or desktop) with SSH
3. Proxychains on client
4. 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.

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.

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.

This tutorial will once again be targeting Foundstone’s Hacme Casino which intentionally has vulnerabilities built into the application. Fuzzing can focus on different types of vulnerabilities and parameters within web applications (e.g. XSS, SQL injection, queries, directory paths, etc…), although this tutorial will focus on parameters vulnerable to SQL injection. Foudstone’s documentation lets us know that the username input is vulnerable to SQL injection so we can try fuzzing it with Webscarab to find other possible injections. First we’ll try and login with the username ‘test’ and password ‘test’. This can be seen in Figure 1.

Figure 1: Trying to login

This will not log us into the application but Webscarab will capture the login process in the summary tab. Once this has happened find the login conversation in the summary tab. After you have found the login conversation simply right click and select “Use as fuzz template”, this will send the parameters and headers associated with that request / conversation to the fuzzing tab. Selection of the login request can be seen in Figure 2.

Figure 2: Send conversation to fuzz template

Now navigate to the Fuzzer tab within Webscarab. Here you’ll see all the parameters that are associated with that request / conversation. You could add parameters to the request and see how the web application reacts to different paths, value, or types. You could also delete parameters for simplicity and to also see how the application reacts with those parameters missing. Once you have determined the parameters for fuzzing you’ll need to define a fuzz source. So click on the “Sources” button beside “Start” and “Stop” within the Fuzzer tab. Here you will choose a dictionary style text file that contains parameters you want to fuzz with. I chose a SQL injection dictionary because we know the “username” field is vulnerable to SQL injections. The selection of the SQL injection dictionary can be seen in Figure 3.

Figure 3: Choosing fuzz source

In my SQL injection dictionary I have 66 items, but Webscarab does not have a limit. There are lots of SQL injection dictionaries out there, some are even dedicated towards different platforms (e.g. MySQL, MS SQL Server, DB2, etc…). I got most of my SQL attacks from Andres Andreu’s website Neurofuzz, the dictionary I pulled from can be found here. In this tutorial we won’t be trying to fuzz for XSS vulnerabilities but ha.ckers.org has a now infamous XSS dictionary which is a great resource. Once all dictionary sources are added go to the main Fuzzer tab and assign parameters a fuzz source. This can be done via a drop down menu as seen in Figure 4.

Figure 4: Drop down menu containing fuzz source

In order to prevent a parameter from being fuzzed simply leave the “Fuzz Source” field blank or delete the parameter altogether. In this case the “user_login” is the only parameter that will reiterate through the SQLattack dictionary. The next step is to click on “Start” and let Webscarab try all of your parameters within the dictionary. This means the value “test” will be replaced with values inside the SQL injection attack dictionary and new request is sent to the web server for every attack parameter inside your dictionary. The fuzzer in action can be seen in Figure 5.

Figure 5: Running the fuzzer

Notice the “Total Requests” and the “Current Request”, once the fuzzer has run through all of the parameters in the SQL injection dictionary both of these numbers will be 68. Also notice the ID number 97 on the left hand side of the table, this is the first request of the fuzzing operation. The last request will have an ID number of 164, it’s important to keep track of these request ID’s when reviewing results of the fuzzing operation. I have found myself reviewing requests that weren’t fuzzed and accidentally identified requests as not being vulnerable when in fact they were.

Once the fuzzer has made all of the requests a review of the results is needed to see if any of the attack parameters succeeded in a SQL injection. I do this simply by going back to the summary tab and opening up the first conversation of the fuzzing process. I then manually step through every conversation involved in the fuzzing operation and look for any “interesting differences” between responses. The phrase interesting differences is in quotation marks because fuzzing and looking for SQL injections is not an exact science but knowing how an application normally deals with the input will be helpful in determining what should and should not be expected in a HTTP response. Let’s take a look at some of our fuzzing conversations to get a better idea of discovering differences. Have a look at the first fuzzing request, note the value of the “user_login” parameter in the request and the value of the “Location” in the response. This can be seen in Figure 6.

Figure 6: First fuzzed conversation

Here it’s seen that the first value in the attack dictionary was actually used for the username value, good to know Webscarab is functioning properly. The top of Figure 6 shows that a POST request is sent to /account/login to check the credentials of the user, since the first SQL injection is not a valid user the response is to redirect back to the login screen. Keep in mind when looking at these conversation screen shots that the top half of the figure is the request and the lower half is the response. It can be deferred from this conversation that if an invalid username is inserted into the web application the response will be a redirect to the login screen. So when looking through the other SQL injected conversations it would be a good idea to look for a redirect to another location or an error message. It’s always a good idea to look for database error messages when trying to find SQL injection vulnerabilities within a web application. Stepping through the other conversations I notice something different, this can be seen in Figure 7.

Figure 7: SQL injection changed redirect location

Looks like on conversation 103 one of the SQL injections in the attack dictionary changed the location of the redirect to /lobby/games. Let’s throw the injection value back into the web application and see what the response may be. The request can be seen in Figure 8.

Figure 8: SQL injection request on Hacme Casino

The response to this SQL injection can be seen below in Figure 9.

Figure 9: SQL injection response (Great success!)

Looks like the SQL injection gave us access to Andy Aces’ account. This occurred because we added the phrase “or 1=1″ (which is always true) to the end of the SQL query that authenticates the users to Hacme Casino. The reason Andy Aces’ account was hijacked is because his name is the first one in the database. Guess having the last name Altman could be bad for me as well? Looking through the other conversations there appears to be another SQL injection that worked as well, this can be seen in Figure 10.

Figure 10: Another successful SQL injection

The hits just keep on coming. This may seem to easy but there are plenty of web applications out in the wild that don’t validate input and let malicious users manipulate their application and backend databases. SQL injections within a web application can be a serious vulnerability depending on the data held within the database. Had this scenario been real a malicious user could have taken over Andy Aces’ account and had his way inside the online casino.

The fuzzing functionality of Webscarab makes web application vulnerability assessment a more automated process. Manually entering all of those SQL injection attacks can take a very long time. There is a downside to the dictionary approach though, your dictionary may not be as creative as a malicious user. Some people believe that a fuzzer should generate random input and that you should try thousands of requests in order to properly test a web application. Thousands of random requests could be better but stepping through those requests to determine validity can make for a long day. Although if one were to take the random input approach Webscarab has a solution for stepping through those results, the Compare and Search functionality. I may dive into the Compare and Search functionality at a later date, these functions can really speed up the process of web vulnerability assessment. Also keep your eye open for a video tutorial of Webscarab coming soon, you could always subscribe to my feed for the latest and greatest.

Once again I hope this tutorial was helpful in showing you the great features of Webscarab, as always your comments and feedback are welcomed.

travis@home:~$ more references

Owasp Webscarab fuzzing tutorial

Rogan Dawes documentation for Webscarab

Foundstone Hacme Casino

Part 2 in this series is going to focus on session ID analysis. If you are not familiar with session ID’s I’ll do a quick explanation. HTTP is a stateless protocol, so it’s equivalent to walkie talkies or CB radios. You’ll send a request and wait for a reply, you don’t have a constantly open communication line as you would with a phone. So in order to emulate this open communication the HTTP protocol uses session ID’s, commonly known as cookies. These cookies are simply agreements between you and the web application that you are who you claim to be. Once you have exchanged your cookie with the website you can then talk back and forth as long as the cookie is tied to your communication. So there’s the quick and dirty intro to session ID’s. So the next logical question is how does this session ID process work or even better how should it work? Let’s use a web mail application as an example:

1. You login to your web mail account
2. Your web mail provider sends you a “random” cookie that is tied to your login session
3. Each time you click on a new message within your Inbox your cookie is sent along to validate who you claim to be, that way you’ll get your next message and not another person’s message.

These are the basic steps. The main thing to remember is that your login credentials are tied to the session ID / cookie. So the key to keeping your conversations private is protecting the session ID and making it hard to guess. Session ID’s are similar to passwords in that regard, you always want to keep them a secret and make them hard to guess. When Webscarab analyzes the session ID it only focuses on if the session is easy or hard to guess (aka randomness). So enough with the chit chat let’s see how Webscarab analyzes session ID’s.

Once again we’re going to be analyzing the Hacme Casino web application. The login page for this application can be seen in Figure 1.

Figure 1: Hacme Casino login

So with Webscarab already running in the background I’ll go ahead and login into Hacme Casino and click on a few links. Navigating inside the application will generate requests and responses that we can later analyze. Now the login process should generate a session ID but there could be other session ID’s generated within the application that you may want to analyze as well. You could always keep an eye on the summary tab to see if you are capturing cookies. There are other ways to maintain state within a web application but cookies are the most common. When looking at the summary tab for the login process you can see that cookies are being set. This can be seen in the first conversation in the bottom row on Figure 2.

Figure 2: Login process for Hacme Casino

So the conversation with the path /account/login is setting a cookie, also the top pane has a check mark indicating that the login URL is setting a cookie as well. This is definitely a good target because we know the functionality of this session ID is to maintain my balance and gambling stats. Some session ID’s can be tough to figure out and sometimes it seems like developers set cookies for no reason. So now let’s walk through the steps to analyze the session ID associated with /account/login.

1. Log out of the current session. I can’t stress this enough, the first time I was using this feature I bumbled around for a couple of hours trying to figure out why it wasn’t analyzing the sessions. Further down in this article I’ll show you a screen shot of what it looks like when you try and analyze the session you are currently logged into.
2. Navigate to the Session ID Analysis tab >> Collection tab within Webscarab. There you will see a drop down list labeled “Previous Requests”, here you can pick a conversation from your history of transactions within the web application to analyze. We already know that we want to analyze the /account/login conversation because we saw that it was setting cookies. If you were unsure which conversation used session ID’s you could click on the “Test” button to verify if session information existed. Figure 3 shows a screen shot of me choosing the /account/login conversation for analysis.



Figure 3: Choosing conversation in Collection tab

3. After you have chosen your conversation for analysis you will then click on the “Fetch” button to start collecting session ID’s from the web server. The default number of session ID’s collected is set at 100 but you can choose more if you like. My background is math and science so I’m of the opinion that you can never have to many data points. Play with this number if you like, in my experience more samples will do a better job at producing trends and pointing out weaknesses in random number generation. The law of diminishing returns will eventually kick in though. So after you have clicked the “Fetch” button you will need to move over to the “Analysis” tab. When you first click on the “Analysis” tab it may seem like nothing is happening, this is because you need to select your session ID from the “Session Identifier” drop down list. This drop down list can be seen in Figure 4.



Figure 4: Choosing session in Analysis tab

Once you have selected your session that you are analyzing the table should begin to populate with the number of samples that you chose in the Collection tab. Webscarab takes the session ID’s found within the web application and converts them into numbers so that they can be easily parsed. These numbers are then compared to one another for predictability. Figure 5 below shows what happens when you try to analyze the current session, you’ll get zeros for both the Numeric value and the difference. This is because the session ID / cookie stays the same.



Figure 5: Analyzing current session

 

4. The fourth and final step is neatest part of the session ID analysis functionality within Webscarab, the Visualization tab. This tab creates a graph using the numbers from the Analysis tab. This will give you a quick visual representation of how weak or strong the session ID’s are. The graphical analysis of the Hacme Casino session ID’s can be seen below in Figure 6.

Figure 6: Cookies over time for Hacme Casino

It appears that the session ID’s created for Hacme Casino are random or at the very least not easy to guess. Your average malicious user is going to see that the session ID’s are going to be difficult to guess, so they’ll move on and try another vector to get inside the web application. A malicious user will be looking for easy access so they will be looking for session ID’s that are very easy to guess. Figure 7 shows an application that implements session ID’s that are very easy to guess.

Figure 7: Weak cookies over time

This graph was not generated using Foundstone’s Hacme Casino but had a malicious user seen this type of graph it would be very easy for them to guess a session ID and essentially hijack that person’s Hacme Casino account. From the casino example you can see how dangerous weak session ID’s can be. Session ID’s are the “key” to someone’s account information. This is possible due to the stateless nature of HTTP. So a malicious user could hijack your account without ever knowing your username or password.

This concludes Part 2 of the Webscarab tutorial. If you have something to add or see an error please leave a comment or contact me. Part 3 is going to focus on the fuzzing functionality within Webscarab. Until then try the session ID functionality on a web application that you use often and see how weak or strong their session ID management is.

This tutorial is going to focus on Webscarab, although there are other numerous useful tools on the market (e.g. Paros, Burp). The first thing we’ll need to do is obtain Webscarab, I like to use the version signed by Rogan Dawes, which can be found here. Go to the downloads section and make sure you get the Java Web Start version signed by Rogan Dawes. The second thing we’ll need to do is start up Webscarab. By default Webscarab listens on port 8008 but this can be easily changed to any port. These settings can be seen in Figure 1.

Figure 1: Webscarab proxy settings

We’ll also need to configure our browser so that our communication is pointed through the proxy. In recent versions of Firefox the path should be Tools >> Options >> Advanced Tab >> Network Tab >> Settings. Once there you’ll need to highlight “Manual proxy configuration”, then for “HTTP Proxy” type in “localhost” and for port use 8008. You’ll also need to do this for the SSL proxy if the web application uses SSL. These settings can be seen in Figure 2.

Figure 2: Firefox proxy settings

The path to change IE settings: Tools >> Internet Options >> Connections tab >> LAN settings. Here you’ll need to check the box that says “Use a proxy server for your LAN”, this can be seen in Figure 3.

Figure 3: IE proxy settings

This tutorial is going to show how Webscarab can walk through and assess the Hacme Casino web application provided by Foundstone, Figure 4 shows the login page for this application.

Figure 4: Hacme Casino login page

I have already created an account within the application with the username “hacker” and a password of “passwd”. So with Webscarab already running in the background I am going to login to Hacme Casino. If you are on the summary tab within Webscarab you will notice requests and responses filling up rows in the bottom pane. Webscarab is logging all communication between you and the web server, this includes all images, CSS files, Javascript files, parameters, etc… The top pane of the summary tab shows you a directory structure of your history through the web application. This summary tab can be seen in Figure 5.

Figure 5: Webscarab summary tab

Now a summary of your history is neat but that only scratches the surface of Webscarab’s functionality. One of the best functions of a HTTP proxy is the ability to intercept requests on the fly or replay those requests at a later time. In order to intercept requests / responses make sure you have checked the “Intercept requests” / “Intercept responses” checkboxes in the Proxy >> Manual Edit tab. These settings can be seen in Figure 6.

Figure 6: Webscarab intercept settings

You may be wondering why you would want to intercept or repeat a HTTP request / response. The simple answer is to learn more about what a website is doing with your input (e.g. SSN, credit card, personal information). Application security folks, developers, or curious people may want to understand more about the web application they’re using. Intercepting a request / response will allow you to see and manipulate communication being sent back and forth. Application security analysts like to replay requests over and over again with different inputs to see what the application will allow as input. This will give security analysts an idea of how secure the application is. Had we intercepted the login process you would have seen the inputs for username and password being sent to the web server. A screen shot of this can be seen in Figure 7.

Figure 7: Interception of the login process for Hacme Casino

You can see in Figure 7 that Webscarab has intercepted both the username “hacker” and password “passwd”. A HTTP proxy is able to see the password even though each character was replaced by an asterisk within the application. At this point you could accept the request or manipulate the parameters. You could try to login as someone at this point even though you initially typed in a different username and password. With a HTTP proxy you could manipulate any request / response not just the login process.

This covers Part 1 of the tutorial on Webscarab. OWASP also has a great write up, called Getting Started, going over basically what I have covered here. So if you ever wanted to know more about a web application Webscarab is a great tool that can help you learn more. In Part 2 of this series we’ll analyze how an application maintains state by using the “SessionID Analysis” functionality of Webscarab.