Burp Suite Tutorial – Web Application Penetration Testing

[Nytro]

Burp Suite Tutorial – Web Application Penetration Testing

Author: Royce Davis

Burp Suite from Portswigger is one of my favorite tools to use when performing a Web Application Penetration Test. The following is a step-by-step Burp Suite Tutorial. I will demonstrate how to properly configure and utilize many of Burp’s features. After reading this, you should be able to perform a thorough web application penetration test. This will be the first in a two-part article series.

What we will cover:

• Outbound SOCKS Proxy Configuration
  
• Intercept & Scope Configuration
  
• Manual Application Walkthrough
  
• Using The Spider & Discover
  
• Using The Repeater Tab
  
• Using The Intruder Tab
  
• Text Specific Searching
  
• Using The Automated Scanner
  

Disclaimer: Testing web applications that you do not have written authorization to test is illegal and punishable by law.

Burp Suite Tutorial – Configure Outbound SOCKS Proxy

Depending on the scope of your engagement, it may be necessary to tunnel your burp traffic through an outbound socks proxy. This ensures that testing traffic originates from your approved testing environment. I prefer to use a simple SSH which works nicely for this purpose. SSH out to your testing server and setup a socks proxy on your localhost via the ‘–D’ option like this.

ssh –D 9292 –l username servername

Navigate to the Options tab located near the far right of the top menu in Burp. From the “Connections” sub-tab, Scroll down to the third section labeled “SOCKS Proxy”. Type in localhost for the host option and 9292 for the port option.

Figure #1 – SOCKS Proxy Settings

Now burp is configured to route traffic through your outbound SSH tunnel. Configure your browser’s proxy settings to use burp. Navigate to What Is My IP - The IP Address Experts Since 1999 and ensure your IP address is coming from your testing environment.

#ProTip I use a separate browser for web application testing. This ensures I don’t accidently pass any personal data to one of my client’s sites such as the password to my gmail account for example.

I also prefer to use a proxy switching addon such as “SwitchySharp” for Google Chrome. This allows me to easily switch back and forth between various proxy configurations that I might need during different engagements. Here is what my configuration settings look like for Burp.

Figure #2 – SwitchySharp Proxy Settings

Burp Suite Tutorial – Configure Intercept Behavior

The next thing I do is configure the proxy intercept feature. Set it to only pause on requests and responses to and from the target site. Navigate to the “Proxy” tab under the “Options” sub-tab. The second and third headings display the configurable options for intercepting requests and responses. Uncheck the defaults and check “URL Is in target scope”. Next turn intercept off as it is not needed for the initial application walkthrough. From the “Intercept” sub-tab ensure that the toggle button reads “Intercept is off”

Figure #3 – Proxy Intercept Settings

Burp Suite Tutorial – Application Walkthrough

For some reason, a lot of people like to skip this step. I don’t recommend this. During the initial walkthrough of your target application it is important to manually click through as much of the site as possible. Try and resist the urge to start analyzing things in burp right a way. Instead, spend a good while and click on every link and view every page. Just like a normal user might do. Think about how the site works or how it’s “supposed” to work.

You should be thinking about the following questions:

• What types of actions can someone do, both from an authenticated and unauthenticated perspective?
  
• Do any requests appear to be processed by a server-side job or database operation?
  
• Is there any information being displayed that I can control
  

If you stumble upon any input forms, be sure to do some manual test cases. Entering a single tick and hit submit on any Search form or zip code field you come across. You might be surprised at how often security vulnerabilities are discovered by curious exploration and not by automated scanning.

Burp Suite Tutorial – Configure Your Target Scope

Now that you have a good feel for how your target application works its time to start analyzing some GETs and Posts. However, before doing any testing with burp it’s a good idea to properly define your target scope. This will ensure that you don’t send any potentially malicious traffic to websites that you are not authorized to test.

#ProTip I am authorized to test Pentest Geek - Penetration Testing Tutorials - Information Security Professionals. *You* are not.

Head over to the “Target” tab and then the “Site map” sub-tab. Select your target website from the left display pane. Right click and choose “Add to scope’. Next highlight all other sites in the display pane, right click and select Remove from scope. If you’ve done this correctly your scope should look something like the image below.

Figure #4 – Scope Settings

Burp Suite Tutorial – Initial Pilfering

Click on the “Target” tab and the “Site Map” sub tab. Scroll down to the appropriate site branch and expand all the arrows until you get a complete picture of your target site. This should include all of the individual pages you browsed as well as any javascript and css files. Take a moment to soak all of this in, try and spot files that you don’t recognize from the manual walkthrough. You can view the response of each request in a number of different formats located on the “Resposne” tab of the bottom right display pane. Browse through each respond searching for interesting gems. Things you might be surprised to find include:

• Developer comments
  
• Email addresses
  
• Usernames & passwords if you’re lucky
  
• Path disclosure to other files/directories
  
• Etc…
  

Burp Suite Tutorial – Search Specific Keywords

You can also leverage burp to do some of the heavy lifting for you. Right click on a node, from the “Engagement tools” sub-menu select “Search”. One of my favorite searches is to scan for the string “set-cookie”. This lets you know which pages are interesting enough to require a unique cookie. Cookies are commonly used by web application developers to differentiate between requests from multiple site users. This ensures that user ‘A’ doesn’t get to view the information belonging to user ‘B’. For this reason it is a good idea to identify these pages and pay special attention to them.

Figure #5 – Search Specific Keywords

Burp Suite Tutorial – Using Spider and Discover

After a good bit of manual poking and prodding it’s usually beneficial to allow burp to spider the host. Just right click on the target’s root branch in the sitemap and select “Spider this host”.

Figure #6 – Spider Feature

Once the spider has finished, go back to your site-map and see if you picked up any new pages. If you have, take a manual look at them in your browser and also within burp to see if they produce anything interesting. Are there any new login prompts, or input boxes for example? If you’re still not satisfied with all that you have found you can try Burp’s discovery module. Right click on the target site’s root branch and from the “Engagement tools” sub-menu select “Discover Content”. On most sites this module can and will run for a long time so it’s a good practice to keep an eye on it. Make sure that it completes or shut it off manually before it runs for too long.

Burp Suite Tutorial – Using The Repeater

The Repeater tab is arguably one of the most useful features in Burp Suite. I use it hundreds of times on every web application that I test. It is extremely valuable and also incredibly simple to use. Just right click on any request within the “Target” or “Proxy” tab and select “Send to Repeater”. Next click over to the “Repeater” tab and hit “Go”. You will see something like this.

Figure #7 – The Repeater

Here you can manipulate any part of the HTTP request headers and see what the response looks like. I recommend spending some good time here playing with every aspect of the HTTP request. Especial any GET/POST parameters that are besting sent along with the request.

Burp Suite Tutorial – Using The Intruder

If you are limited on time and have too many requests and individual parameters to do a thorough manual test. The Burp Intruder is a really great and powerful way to perform automated and semi-targeted fuzzing. You can use it against one or more parameters in an HTTP request. Right click on any request just as we did before and this time select “Send to Intruder”. Head over to the “Intruder” tab and click on the “Positions” sub-tab. You should see something like this.

Figure #8 – Intruder Positions

I recommend using the “Clear” button to remove what is selected at first. The default behavior is to test everything with an ‘=’ sign. Highlight the parameters you wan’t to fuzz and click “Add”. Next you need to go to the “Payloads” sub-tab and tell Burp which test cases to perform during the fuzzing run. A good one to start off with is “Fuzzing – full”. this will send a number of basic test cases to every parameter that you highlighted on the “Positions” sub-tab.

Figure #9 – Intruder Payloads

Burp Suite Tutorial – Automated Scanning

The last thing that I do when testing a web application is perform an automated scan using Burp. Back on your “Site map” sub-tab, right click on the root branch of your target site and select “Passively scan this host”. This will analyze every request and response that you have generated during your burp session. It will produce a vulnerability advisor on the “Results” sub-tab located on the “Scanner” tab. I like to do the passive scan first because it doesn’t send any traffic to the target server. Alternatively you can configure Burp to passively analyze requests and responses automatically in the “Live scanning” sub-tab. You can also do this for Active Scanning but I do not recommend it.

When doing an active scan I like to use the following settings.

Figure #10 – Active Scan Settings

Burp Suite Tutorial – End Of Part1

Hopefully you’ve learned some useful techniques for performing Web Application Penetration Testing. In part #2, we will go over some more of Burp’s features. We will cover reporting and exporting session data for collaboration with other pentesters. I look forward to seeing you there. Thank you for reading and as always, Hack responsibly.

Sursa: Burp Suite Tutorial - Web Application Penetration Testing

[indianul]

Portswigger’s Burp Proxy is one of my absolute favorite pen testing tools. Brute forcing forms is one of my favorite pen test activities. I’m not quite sure why, maybe “brute force” conjures up the image of piling some TNT against a door and seeing things go BOOM! I’m sick enough to even enjoy brute forcing security questions for password recovery. In fact, I’ve compiled several nice wordlists for just that purpose that you may help yourself to, as well as some of my other favorite lists.

So here’s the deal, most, if not all of us, are using one or a few large to huge password/word lists in these scenarios. Hello crack lib dictionary at 13+ megs! So, why should we process each and every line in that file if we don’t have to?

Over the past year or so when talking to other pen testers, I share a little trick I keep in my back pocket for just this purpose, and the feedback is always “wow, really?!” so I thought it was time to share the information. So here we go…

Scenario: You’ve done your recon on a login system and discovered it is brute-forcable. You’ve also unearthed the password requirements.

For the purposes of our demo, let’s say our app requires passwords to be 4-8 characters in length. We’re going to use Burp Intruder to do our dirty work, so, get your request captured and sent to the Intruder module, mark your injection positions and all that jazz then flip over to the Payloads tab. You can use this trick on any payload type, but if you’re typing in a manual list (say just a few user IDs), there’s really no need, so I’m going to jump right to tweaking the password list. Under Payload Type, select Runtime File, and load in your favorite password list. At this point, your config should look a little something like this:

Now, here’s a quick result set from the default run (for brevity, I’m only fuzzing the password parameter):

You can see we have some short passwords, some long passwords, and some special character passwords. Let’s start filtering! Next, you want to Add a Payload Processing rule, in this case the “Skip if matches regex” option, and you want to add the following as a filter: ^.{1,3}$

This filter will ignore any string with a length of 1, 2 or 3. Now, Add a second regex rule and add the following value: ^.{9,}$ This filter will ignore any string of 9 characters or more. When done, your settings should look something like this:

That’s it, we’re all set to kick it off!

Voila, short and long passwords are filtered, and now the attack will finish much quicker!

But, can I make it even more efficient?

Why yes, yes you can. Lets say you’re performing recon on the authentication system, and you come along a message like this:

So, we are not allowed to use special characters, eh? Good news, we can tune up the filter set to ignore non-alpha-num characters. In this case, it’s nice and easy, we just use the NOTWORD filter anywhere on the string. So create a new “Skip if matches regex” rule, and add: .*[\W].* When complete, your config should look like this:

And that’s it, Burp will now only attack the application with strings that are 4-8 characters, with numbers and digits only.

Obviously, the regex filtering has many uses, such as filtering certain characters during fuzzing that are known to cause unwanted server behavior, but this is my favorite example. Enjoy!

-rance

Sursa:Storm The Net

O lista de dictionare buna la multe:Index of /wordlists