SamuraiNet Blog

Continuing on with my web application penetration testing series I will now go into the usage of RefControl. RefControl is useful in checking referrer-based exploits, such as CSRF.

RefControl

RefControl allows you to specify the referrer for a site when you view it. Accessed either from the Tools->RefControl options is the global list of all rules for all sites that you have set. Access from the right clicking menu are the current settings for the site you are visiting. If you have set no rules, you will be able to add in a new rule.

After selecting the RefControl options for the current site, you are able to add in your custom referer, send no referer, or have RefControl automatically send the root of the current site.

What use is this? With the tidal wave of CSRF exploits being found a tool that can help find these would be welcomed with open arms. This is where RefControl enters the domain. While referrer checking is not a hardened safe guard against CSRF many site still employ its use.  By setting RefControl’s custom referrer to an off-site referrer you are able to check forms and links with GET variables simply by interacting as you normally would. If the request goes through, that form or link should be inspected further. Sites using only Token Key Pairs might be vulnerable to this method of probing, but not vulnerable to CSRF itself. This is why it is important to continue inspecting after said vulnerability is found, rather than simply accepting it as a vulnerability.

Another interesting permutation of RefControl is setting the custom referrer to include SQL characters. Many sites check referrers and store then in a database for analytic purposes and this allows the penetration tester to check if those inputs are being validated also.

In my previous post on penetration testing I mentioned various tools that I use for web application testing. In this post and future posts, I will go into some of these tools and how I use them. This post will be over Tamper Data, which is probably the add-on I use most for penetration testing.

Tamper Data is used for monitoring and editing requests made to a server. When you start Tamper up and refresh a page or have a page that automatically refreshes or uses AJAX you will see the requests in the top portion of the window. When selected, the bottom will display both the request headers you sent as well as the response headers you received. These can be useful for determining information about the server, monitoring background processes on a site (such as AJAX requests), and seeing all the various files and locations that are loaded when you view the page. While this is useful for reconnaissance work and gaining initial information on the a target, this is not where Tamper’s strong suit lies. As the name suggests, Tamper Data is for … Tampering with data.

Despite the fact that Tamper is running and capturing headers for requests and responces, Tampering has not actually be started. By clicking “Start Tamper” we enable Tampering of Data. Now, when Tamper notices an outgoing request it will halt that request and ask for approval. You are then presented with three options to proceed, along with the option to discontinue Tampering. If you unselect the check box, Tamper will go back into passive mode and allow you to work, undisturbed, on the current request.

Submit: This simply sends the request as-is. Normally I use this if unsuspecting traffic gets caught up in Tamper’s web, such as gmail which makes AJAX requests.

Abort Request: This should be a fairly obvious option. It will stop the request from being sent. I generally use this when I am testing a potentially malicious site. In the case that a client asks me to review some code or I am analyzing a piece of Cross Site Scripting code I will use Tamper, to allow the request to be made, but to stop it before any of the data is actually transfered. I would recommend using this only after looking over the code. Some Cross Site Scripting code does not need for a request to be made to be dangerous and therefore Tamper is a poor defense.

Tamper: Here is where the real meat and potatoes to Tamper lay. When you choose to tamper with the request you are brought to a new window. On the top of the window is the URL the request is being sent to. In the case of a POST, this saves us the effort of looking through the HTML (and potentially JavaScript) for where the request is to be sent. On the left-hand side of the window we have the Request headers and their values. We can actually modify the request headers on the spot. Instead of using JavaScript injection to modify cookie data, we can simply change it in the request header, we can modify our referrer to be anything we want, even spoof our User Agent. For referrers and User Agents I recommend other tools, but Tamper is the swiss army knife of my FireFox plug-in set of tools and I have used it over the others for such actions. Finally, we reach the right-hand side of the window. This is the POST data of the request. Here we can see what POST fields are sent and the values they are sent with. By right clicking we can add other elements and we can modify the values of current fields. Again, this saves us the effort of bypassing client side restrictions on what values may be sent or to submit an element not part of a select without using JavaScript. When finished tampering, simply select OK and watch you request be sent.

As this is an introduction to the usage of Tamper, I won’t go into advanced usage of the tool nor will I go into exactly how I execute some exploits with it. I leave you to tamper with Tamper.

I read a question recently on LinkedIn asking what tools penetration testers used for web application testing and felt that it was probably a question that merited more than the few sentences I put down as an answer. The following tools are for web application testing. This is by no means a complete list, but these are some common tools that are useful and anyone interested in penetration testing should look into understanding.

When we talk about web site penetration testing most people think of scanners like Nessus or Acunetix’s scanner. While these have some merit and I have seen them provide useful information, the best method in my opinion is to test by hand. This does not mean using no tools at all, rather simply not using these automated tools. The following is a list of tools and plug-ins that I find useful. All of the following tools are add-ons for FireFox 2, an appropriate platform for web application testing.

ChickenFoot - This is a great tool since it allows you to run javascript on the page. Much like greasemonkey, you can configure default scripts to run, but the real advantage is having a “javascript console” in the browser that can interact with the DOM. This has saved me a lot of trouble debugging scripts while developing as well as breaking scripts already in place.

LiveHTTPHeaders - This is a great tool for grabbing the request headers and banners that a server sends out. Data such as operating system and apache version can be found as well as a comprehensive list of ALL data that is transfered to your browser at request time.

User Agent Switcher - Normally changing your user agent doesn’t help with penetration testing much, since few sites require you to be using a specific browser or operating system as part of authentication, however; by using the Google Bot’s user agent sites designed for Search Engine Optimization sometimes open their doors for you. If the designer or developer allowed restricted pages to be indexed (I don’t know why they do this, but they do) by the Google Bot, we can now access them.

Tamper Data - This is a brilliant tool that allows you to capture outgoing HTTP requests and modify the data. This makes modifying data in select menus much easier than using javascript to modify the DOM. You can also enter in other fields to the POST array which is sometimes useful if the site is using automated SQL queries based on POST’s contents.

RefControl - Another great add-on. This allows you to customize the referrer you send. Many sites check this to make sure that you are sending data from an allowed page and RefControl can be used to forge this. This is useful when you want to send data from your own web-app to another (for fuzzing) or if you are trying to access another zone of the site without the correct credentials from the previous zone.

Beyond these FireFox add-on I have a few more tricks up my sleeve. The following are not necessarily tools for penetration testing, but they can lead to extra information.

http://www.myipneighbors.com/ - This is a great site that allows you to easily see what other sites sit on the same IP address. This is useful for testing sites on shared hosts where a cross-server hack is possible. This widens your range of vulnerabilities from one site to many. (In some cases I’ve seen IP address with upwards of 700 sites on them.) The site even provides an iFrame so that you can briefly browse the sites and see which look most likely to be useful.

nmap - Most of you are probably asking why a port scanner is on this list, but the fact that nmap can easily determine what version of Apache is running makes it useful. If you were unable to capture the banner from a request before nmap is your next option. You may even be able to find out versions of MySQL and what Operating system is being used. These can be useful for exploits inherent in the background processes of the site.

Finally, I will talk a brief bit about some automated tools that I will use for fuzzing and quick scans. Normally IF I run these, I set them and forget them until I’ve burned myself out and check them only later.

Nessus - This is a great tool for scanning even beyond web applications, but with the features for SQL injection, Cross site scripting, and I believe now even Remote and Local File inclusion vulnerabilities it can provide useful information. If you are doing more than simple Web Application scanning Nessus can provide even more information. Rather than just giving you a listing of ports and services like nmap, Nessus provides information on WHY these are dangerous and how they can be both exploited and fixed. This is great for testing your own network.

Acunetix’s scanner - This scanner will basically fuzz all inputs for Cross Site Scripting holes and report back to you on which, if any, were successful. I have had only moderate success with it, but again as a “set it and forget it” tool while you work by hand it can be useful.