baner

Cơ sở dữ liệu nâng cao

Cơ sở dữ liệu nâng cao, Advanced Database.

Khai phá dữ liệu

Khai phá dữ liệu.

An Toàn Thông Tin

An Toàn Thông Tin

Trí tuệ nhân tạo

Trí tuệ nhân tạo.

Bảo Mật Thông Tin

Bảo Mật Thông Tin

Chủ Nhật, 5 tháng 1, 2014

Session Hijacking

Picture
WHAT IS SESSION HIJACKING? WHAT DO YOU USE?

Session Hijacking, is when you take someones cookie and inject it into your browser, letting you log in without the password

In beginner terms: Session Hijacking is taking the persons unique code (cookie) stored in their browser while they are logged into something (like GMail). If you have that code, you can put it into your own browser, and trick the system into thinking you are that user. This is a common method on how you can hack emails.

It's a pretty simple concept, however it can be pretty hard to perform if you're still a learner or beginner hacker, and takes a lot of programs. 

So, to get started we need the proper tools for this sorta thing:

Cain and Abel: (Only if you're going to do this on Windows)
http://www.net-security.org/software.php?id=110

Network Miner: (Alternative to Wireshark)
http://sourceforge.net/projects/networkminer/

Wireshark: (What we use in this particular tutorial)
http://www.wireshark.org

Now that we have what we need, move on down to part 2! 


Session Hijacking PART 2

Picture
HOW DO YOU PERFORM "SESSION HIJACKING"?

Ok, now it's time to actually hijack the session token and get into that account!

In this specific tutorial, we will focus on GMail, which uses a cookie called the GX Cookie. This is vital because we need to know exactly what we are trying to capture before capturing it, because computers, as you may know, need things to be very specific,

First off, we gotta decide which path to take. If you're on a hub based network, you can find local traffic with packet sniffers. Here, we will be using Wireshark.
Let's start by downloading Wireshark (link was given above). Install it and then, once opened, click on Analyze, then click on Interfaces. Now click on the interface appropriate to you and click Start. 

Picture
Now Wireshark should start capturing the traffic. By now you should start seeing the term "packets", this is a term used in wireless connections. For more information on this "packet" term, you can go to my Wireless Cracking tutorial. I explain more stuff there about wireless. After all, It's about wireless cracking!

So now that you're capturing the data packets, you can log into gmail and set the "Don't use https://" option. This option will make you vulnerable to these session hijacking attacks. We want to do this so that you can practice hacking on yourself. 

Next, set the filter on the top left to http.cookie contains "Gx" in Wireshark to filter out all the unnecessary stuff... we just want the GX cookie. Got that? Once you have found the right line of Gmail GX Cookie, right click on it and click "copy", then click "Bytes (Printable Text Only)"

Yay! You just capture the GX Unsecured cookie! Keep in mind now before you do this that you would need a Wincap before capturing the traffic from Wireshark (or Network Miner for that matter) 


This concludes Part 2. Scroll down the part 3 now if you're still thirsty for hacking goodness! 

Session Hijacking PART 3

PictureHOW DO I INJECT IT INTO MY BROWSER AND GET INTO THE ACCOUNT?

So, congratulations so far on reading this much! But, you may be wondering how capturing the cookie did anything if you're not on the account yet? Well... Thats because you still have to complete the injection part, where you trick your browser into thinking you are that person you're hacking, so it will let you go on the account. This is sorta the key part of this session hijacking stuff.

Firstly, there are a ton of plug-ins for achieving the injection part, and like you may have guessed, their free! They usually fall under the category of "Cookie Editors".

In this tutorial, we will be using the Firefox Browser, it's by far the best for the injection part of session hijacking! You will also need the "Developer Toolbar" for it , as this is what we will be using in the tutorial.

Firefox Browser: 
http://www.mozilla.org/en-US/

Developer Toolbar:https://addons.mozilla.org/en-US/firefox/addon/web-developer/

Once you have installed the WebDeveloper Toolbar, click on the "cookie" drop-down menu, and select the cookie you want to edit. Once you have selected the "Edit Cookie" option, you should get the following screen on the side.

Now replace the cookie value with your victims cookie value.

In this tutorial we used Wireshark, so there is an easier way for us to achieve the same thing. Instead of using WebDeveloper Toolbar, you may just use the Cookie Injector with GreasMonkey installed to inject it directly into your browser. Simply press     Alt-C after installing it and just paste the Wireshark cookie dump, then press OK. Now just refresh your browser and you are in your victims account!

GreasMonkey:https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/

Now, session hijacking isn't always that great under certain circumstances:
1. First of all cookie stealing becomes useless if victim is using a https:// protocol for browsing and end to end encryption is enabled.

2. Most of the cookies expire once the victims clicks on the logout button and hence the attacker also logs out of the account.

3. Lots of websites do not sport parallel logins which also makes cookie stealing useless.

Although these seem like major drawbacks, It's still good to know. Not only that but lots of people leave their accounts logged in all day! (Facebook users, I'm pointing at you!)

Thanks for reading this, and I hope you use this along your hacking journey!

Thứ Bảy, 4 tháng 1, 2014

Lịch Đào Tạo Bảo Mật Ứng Dụng Web

Chương trình đào tạo bảo mật ứng dụng web sẽ bao gồm các bài học về dò quét, kiểm lỗi cho hệ thống máy chủ web và website, quy trình penetration testing một trang web cùng những kỹ năng an toàn thông tin liên quan đến việc bảo mật cho một ứng dụng web. Các bài học và mô hình lab sẽ được thực hiện trên các hệ thống webploit như DVWA, Multilidea, Metasploitable ... và những công cụ thực hành mạnh mẽ nhất hiện nay như BackTrack, Kali Linux cùng với các ứng dụng hàng đầu trong lĩnh vực bảo mật thông tin (xem tại www.sectools.org)

Ngày 1 - Session Hijaking

Giới thiệu về bảo mật thông tin nói chung và bảo mật cho trang web, máy chủ web.
Trình bày về Sesiion Hijacking
- Cài đặt và cấu hình bộ công cụ thực hành Kali Linux.
- Thực hành tấn công session hijacking.

Ngày 2 - Hacking Web Server & Web Application Vulneribilities

Trình bày các  phương pháp tấn công máy chủ web và cách thức hardening hệ thống, phòng chống tấn công.
- Các lỗi bảo mật thông dụng của ứng dụng web cùng cách khai thác và phòng chống

Ngày 3 - Web-based Password Cracking & Client-side Attack (Hacking Web Browser)

Các phương pháp bẻ khóa mật khẩu và tấn công vào phía người dùng cùng những giải pháp phòng chống.

Ngày 4 - SQL Injection & Hacking Database Server

Tìm hiểu về một trong những hình thức tấn công website thông dụng nhất là SQL Injection.

Ngày 5 - Thực Hành - Ôn Tập - Kiểm Tra

Thứ Tư, 1 tháng 1, 2014

CSRF Proof of Concept with OWASP ZAP

1. Introduction
This article introduces CSRF (cross-site request forgery) vulnerability and demonstrates how to prepare a CSRF proof of concept with OWASP ZAP.
2. Cross-site request forgery
The vulnerability allows an attacker to forge a user request. Consequently, the user does what the attacker wants. Here’s an example:
I. Social engineering is used to lure the user to the attacker’s website. Simultaneously, the user is logged in to bank X.
II. Let’s assume, that the bank X’s money transfer form is vulnerable to CSRF (no CSRF token, no authorization password). The attacker prepares an exploit that transfers the user’s money to his account and puts it on his website.
III. When the user visits the site of the attacker, the exploit is launched.
IV. The request of money transfer is sent by the user to bank X. From the perspective of bank X, everything is fine (with a valid authentication cookie.)
3. Environment
Metasploitable is a Linux based virtual machine that is deliberately vulnerable. [1] It can be used, for example, to practice penetration testing skills. The machine is vulnerable and should not operate in bridge mode.
OWASP Mutillidae II is web application that’s also deliberately vulnerable (OWASP Top 10 vulnerabilities.) [2]. It’s a part of Metasploitable (edit /var/www/mutillidae/config.inc on Metasploitable and set $dbname = ‘owasp10′ to get OWASP Mutillidae II working.) One can use OWASP Mutillidae II to play with web application security.
OWASP Zed Attack Proxy (ZAP) is a penetration testing tool for web site security testing [3]. This article presents how to use OWASP ZAP to prepare CSRF proof of concept.
4. OWASP Mutillidae II – a form for adding new entries to a blog
This form is available in Metasploitable at 192.168.56.101/mutillidae/index.php?page=add-to-your-blog.php (192.168.56.101 is the IP address of Metasploitable.)
It’s vulnerable to cross-site request forgery. Let’s set the Security Level to 0 (which can be changed using Toggle Security) and configure the browser to send traffic through OWASP ZAP. Then launch OWASP ZAP to see the request that will be generated, and add an exemplary comment (BLOG_ENTRY_1) to the blog of USER (name of the registered user).

5. OWASP ZAP – analyzing the request
OWASP ZAP was launched before submitting the blog entry. Let’s see the request. The key parts were marked in the screenshot.
fig1-sec5
Want to learn more?? The InfoSec Institute Ethical Hacking course goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises. While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to black hat hackers. Some features of this course include:
  • Dual Certification - CEH and CPT
  • 5 days of Intensive Hands-On Labs
  • Expert Instruction
  • CTF exercises in the evening
  • Most up-to-date proprietary courseware available
There’s no protection against cross-site request forgery when the Security Level is set to 0 (the value of csrf-token is SecurityIsDisabled.) One can use data from this request to prepare a CSRF proof-of concept manually. However, OWASP ZAP can do it automatically.
6. OWASP ZAP – generating CSRF proof of concept
Right click on the request and choose “Generate anti-CSRF test FORM.”
fig2-sec6
A new tab is opened with a CSRF proof of concept. It contains the POST parameters and values from the request. The values can be adjusted by the attacker.


7. Launching CSRF proof of concept
Let’s log in as a different user (USER2), who is the victim of CSRF attack. Then go to the tab with a CSRF proof of concept and click submit. Finally BLOG_ENTRY_1 is added to the blog of USER2.
fig3-sec7
8. Summary
This article introduced CSRF vulnerability and presented how to use OWASP ZAP to prepare a CSRF proof of concept. The user is redirected to the vulnerable form after launching the attack. Real attacks would probably use AJAX request, in order to be silent. However, the CSRF proof of concept generated by OWASP ZAP is fine for the purposes of a vulnerability demonstration.
References:
[1] Metasploitable
http://www.offensive-security.com/metasploit-unleashed/Metasploitable (access date: 28 September 2013)
[2] OWASP Mutillidae II
http://sourceforge.net/projects/mutillidae/ (access date: 28 September 2013)
[3] OWASP ZAP
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project (access date: 28 September 2013)

Fuzzing for SQL injection with Burp Suite Intruder

1. Introduction
This article introduces Burp Suite Intruder and shows how it can be used for SQL injection fuzzing.
2. Burp Suite Intruder
It is a part of Burp Suite, which is an integrated platform for website security testing [1]. Burp Suite Intruder is helpful when fuzzing for vulnerabilities in web applications.
Let’s assume that a penetration tester wants to find SQL injection vulnerabilities. First he needs to intercept the request with Burp Suite Proxy. Then the request is sent to Burp Suite Intruder. After that, the penetration tester needs to define the parameters that will be tested for SQL injection. The next step is defining the payloads and attack type (described later in the article). Then Burp Suite Intruder is launched. When fuzzing is finished, the penetration tester is expected to analyze the output to identify potential vulnerabilities.
3. Target
DVWA (Damn Vulnerable Web Application) is a web application that is intentionally vulnerable [2]. One can use it to play with web application security stuff.
Let’s attack the website in DVWA that is vulnerable to SQL injection. The user is asked to enter User ID. Then the first name and surname of the user are displayed.

DVWA is a part of Metasploitable, which is an intentionally vulnerable Linux-based virtual machine [3]. It can be used to practice penetration testing skills. Please keep in mind that this machine is vulnerable and should not operate in bridge mode.
4. Request Interception, Payload Position, Attack Type
Let’s set the security level to low (it can be changed using DVWA Security) in DVWA. Then enter User ID, click submit and intercept the request with Burp Suite Proxy. The next step is sending the request to Burp Suite Intruder (click right on the request and choose “Send to Intruder”). Then use the “Add” button in Burp Suite Intruder to choose the parameter that will be fuzzed (it is called payload position in Burp Suite Intruder). User ID is sent in parameter id. That’s why it is chosen as a payload position.

As can be seen on the screenshot, sniper was chosen as an attack type. Then a single set of payloads is used and the payloads are taken one by one. It starts from the first position. When all payloads from the set are used, the same procedure is executed for the next payload position if it’s present. That’s why the number of requests generated is a product of the payloads in the set and payload positions.

5. Set of payloads
A penetration tester can create his own list of payloads or use an existing one. Exemplary payloads can be found, for example, in Kali Linux (penetration testing distribution [4]) in the /usr/share/wfuzz/wordlist/Injections directory. Let’s use SQL.txt from this location to test the parameter id for SQL injection vulnerability.

Then choose “Start attack” from the Burp Suite Intruder menu to start fuzzing.
6. Output analysis and exploitation
Let’s see how the website responds to different payloads. As we can observe, the length of the response changes. It is 4699 bytes for baseline request (the one with id equal to 2) and 5005 bytes, when x’ or 1=1 or ‘x’='y is the payload.


It might suggest that more data was read from the database. Let’s check the response for this payload.

As we can see, this payload can be used to extract first names and surnames of all users from the database.
7. Summary
Burp Suite Intruder was introduced. It can be helpful when fuzzing for vulnerabilities in web applications. Exemplary payloads can be found, for example, in Kali Linux in /usr/share/wfuzz/wordlist/Injections directory. It was presented how to use Burp Suite Intruder for SQL injection fuzzing.
References:
[1] Burp Suite http://portswigger.net/burp/ (access date: 25 October 2013)
[2] DVWA (Damn Vulnerable Web Application) http://www.dvwa.co.uk/ (access date: 25 October 2013)
[3] Metasploitable http://www.offensive-security.com/metasploit-unleashed/Metasploitable (access date: 25 October 2013)
[4] Kali Linux http://www.kali.org/ (access date: 25 October 2013)

Vulnerable Applications

Introduction
How often have we found ourselves in need of a vulnerable application, which we could use for various purposes? We could use such applications to test the web application scanners to assess the effectiveness of each scanner. We could also use vulnerable applications to test our knowledge of specific vulnerability detection and exploitation.
In this article we’ll introduce two applications: the Damn Vulnerable Web Application (DVWA) and WebGoat. These two applications exist for one purpose only: to contain web vulnerabilities which we can exploit. Those two applications can be categorized as shown in the picture below. They are web applications, which require a webserver to run.

  • Damn Vulnerable Web Applications (DVWA): PHP/MySQL web applications that contain various vulnerabilities.
  • WebGoat: J2EE web application maintained by OWASP, designed to teach web application security lessons.
Damn Vulnerable Web Applications
First we need to download the Damn Vulnerable Web Application, extract it, and move it into the Apache document root folder:
# unzip DVWA-1.0.7.zip
# mv dvwa/ /var/www/
DVWA needs Apache web server and MySQL database server to function correctly, which is why we need to start them. To start both of them we need to issue the commands below:
# /etc/init.d/apache start
# /etc/init.d/mysql start
Afterwards we also need to edit DVWA configuration file /var/www/dvwa/config/config.inc.php, so the DVWA will be able to connect to the MySQL database. We have to change the following settings: db_server specifies the server host, which is localhost. The db_database specifies the name of the database to use; the database will be created once we’ve successfully set-up the DVWA web application. The last two configuration variables, db_user and db_password specify the username and password for MySQL database. On Backtrack Linux distribution the default username and password for MySQL are root:toor.
The relevant part of the configuration file is presented below:
$_DVWA = array();
$_DVWA[ 'db_server' ] = ‘localhost’;
$_DVWA[ 'db_database' ] = ‘dvwa’;
$_DVWA[ 'db_user' ] = ‘root’;
$_DVWA[ 'db_password' ] = ‘toor’;
When we first connect to the URI http://localhost/dvwa/ we’ll have to set up the database. To do that we need to press on the “Create/Reset Database” button as presented in the picture below:

We can see that the database dvwa has been successfully created. Two tables were also created and popularized in that database. Those two tables are users table and guestbook table.
Afterwards, we can successfully login with the default username admin and password password that were automatically created by the DVWA web application. The next picture shows the DVWA login web page.

When we’ve successfully authenticated into the application, the web application will look like the picture below:

On the left side of the application there’s a menu which we can use to navigate through the application. The DVWA web application contains the following vulnerability types:
  • Brute Force Login
  • Command Execution
  • CSRF
  • File Inclusion
  • SQL Injection
  • Upload Vulnerability
  • XSS
We can start solving those challenges immediately or we can input the appropriate URIs to the web vulnerability scanner.
WebGoat
The WebGoat standard installation file already contains the Tomcat web server and Java JRE, which is why we don’t need to install those separately. But let’s just present what we would have to do if those were not present; this is included just to better introduce the default standalone Webgoat package. First we would need to install the Tomcat web server which will be used to host the WebGoat application. We can install the Tomcat web server with the command below:
Want to learn more?? The InfoSec Institute Ethical Hacking course goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises. While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to black hat hackers. Some features of this course include:
  • Dual Certification - CEH and CPT
  • 5 days of Intensive Hands-On Labs
  • Expert Instruction
  • CTF exercises in the evening
  • Most up-to-date proprietary courseware available
# apt-get install tomcat6 tomcat6-admin tomcat6-examples tomcat6-docs
The package tomcat6 is the actuall Tomcat web server, whereas tomcat6-admin is used to administer the Tomcat web server. The tomcat6-examples provides useful Tomcat examples, whereas the tomcat6-docs installs the Tomcat documentation.
When we want to get server status and restart web applications, we need to access the URI http://yourserver:8080/manager/html, which is password protected. We need to create a user with a role manager in /etc/tomcat6/tomcat-users.xml.
We can also create virtual hosts if we connect to the URI http://yourserver:8080/host-manager/html, which is also password protected. To access it, we must create a user with a role admin in /etc/tomcat6/tomcat-users.xml.
When administering the Tomcat web server, some features need write access to the /etc/tomcat6/ directory, which isn’t granted to the Tomcat user by default. This is why we need to grant the tomcat6 user permissions to that directory. We can do that with the commands below:
# chown tomcat6:tomcat6 /etc/tomcat6 -R
# chmod ug+w /etc/tomcat6 -R
Add the Tomcat admin users by editing the /etc/tomcat6/tomcat-users.xml configuration file. The configuration file should contain the following:
    <?xml version=’1.0′ encoding=’utf-8′?>
    <tomcat-users>
        <role rolename=”admin”/>
        <role rolename=”manager”/>
        <user username=”tomcatadmin” password=”admin” roles=”admin,manager”/>
        <role rolename=”webgoat_basic”/>
        <role rolename=”webgoat_user”/>
        <role rolename=”webgoat_admin”/>
        <user username=”basic” password=”basic” roles=”webgoat_basic,webgoat_user”/>
        <user username=”guest” password=”guest” roles=”webgoat_user”/>
        <user username=”webgoat” password=”webgoat” roles=”webgoat_admin”/>
        <user username=”admin” password=”admin” roles=”webgoat_admin”/>
    </tomcat-users>
We added a new administrator user with username tomcatadmin and password admin. We also added WebGoat usernames basic, guest and webgoat with appropriate passwords. This is needed for being able to login to the WebGoat web application.
After that we can start Tomcat web server normally with the command:
# /etc/init.d/tomcat6 start
The port 8080 should be opened and in LISTENing state:
# netstat -lntup
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 0 0 :::8080 :::* LISTEN 6864/java
When connecting to the Tomcat web server on the URI address http://localhost:8080 we can see the following default Tomcat webpage:

It really isn’t much, but the links introduced on the webpage can display the documentation, samples and administrative interface.
We must download the WebGoat application WAR file:
# wget http://webgoat.googlecode.com/files/WebGoat-5.4.war
To install the WAR file, we must connect to the URI http://127.0.0.1:8080/manager/html and click on the “WAR file to deploy”, which is presented in the picture below:

When we click on the Deploy button, the WebGoat-5.4.war file will be uploaded to the Tomcat web server and installed.
But we can avoid all of this if we use the default standalone Tomcat package. First we need to download and extract it:
# unzip WebGoat-5.4-OWASP_Standard_Win32.zip
# cd WebGoat-5.4/
# ./webgoat.sh start8080
This will start the Tomcat web server on port 8080 and the WebGoat application should be accessible on the http://localhost:8080/WebGoat/attack URI. This can be seen in the picture below:

Ok, we can see the WebGoat entry website. To actually start WebGoat, we need to press on the “Start WebGoat” button. The WebGoat is immediately started and we’re redirected to the Web site presented below:

Now we have a working WebGoat vulnerable application and we can start testing various attacks on it. The following categories are available:
  • Introduction
  • General
  • Access Control Flaws
  • AJAX Security
  • Authentication Flaws
  • Buffer Overflows
  • Code Quality
  • Concurrency
  • Cross-Site Scripting (XSS)
  • Improper Error Handling
  • Injection Flaws
  • Denial of Service
  • Insecure Communication
  • Insecure Configuration
  • Insecure Storage
  • Malicious Execution
  • Parameter Tampering
  • Session Management Flaws
  • Web Services
  • Admin Functions
We’ve seen that it really pays off to use the standalone WebGoat package, since we don’t need to bother with installation and configuration of Tomcat web server, and we also don’t have to deploy the WebGoat war file.
Conclusion
We can see that WebGoat and DVWA contain mostly different vulnerabilities. That is why when trying to test a specific web application scanner, it’s best to compare the results of chosen scanners against both web vulnerable applications. If we have an option, it would also be great to test all the scanners against real websites; just to be sure that one scanner is indeed better than the other. Of course the targeted website should contain at least one vulnerability so the web scanners can actually find something, otherwise it’s not possible for them to detect something that isn’t there.

Burp Suite Walkthrough

Burp Suite is one of the best tools available for web application testing. Its wide variety of features helps us perform various tasks, from intercepting a request and modifying it on the fly, to scanning a web application for vulnerabilities, to brute forcing login forms, to performing a check for the randomness of session tokens and many other functions. In this article we will be doing a complete walkthrough of Burp Suite discussing all its major features.
Burp Suite (free edition) is available by default in Backtrack 5. The professional edition can be downloaded from here. Some of the features that are not available in the free edition are Burp Scanner, Task Scheduler, Target Analyzer, etc. Overall it has the following features.
1) Proxy - Burp Suite comes with a proxy, which runs on port 8080 by default. Using this proxy, we can intercept and modify the traffic as it flows from the client system to the web application. In order to use this proxy, we have to configure our browser to use this proxy. We can also drop the packets if we want so that they do not reach their intended destination, or redirect the traffic to a particular host, etc.
2) Spider - The spider feature of Burp Suite is used to crawl web applications looking for new links, content, etc. It automatically submits login forms (through user defined input) in case it finds any, and looks for new content from the responses. This information can then be sent to the Burp Scanner to perform a detailed scan on all the links and content provided by the spider.
3) Scanner - It is used to scan web applications for vulnerabilities. The type of scanning can be passive, active or user-directed. Some false positives might occur during the tests. It is important to remember that no automated scanner is 100 percent accurate in its results. Unfortunately Burp Scanner is not available with the free edition that is included in Backtrack 5.
4) Intruder - This feature can be used for various purposes like exploiting vulnerabilities, fuzzing web applications, carrying out brute force attacks etc.
5) Repeater - This feature is used to modify and send the same request a number of times and analyze the responses in all those different cases.
6) Sequencer - This feature is mainly used to check the randomness of session tokens provided by the web application. It performs various advanced tests to figure this out.
7) Decoder - This feature can be used to decode data to get back the original form, or to encode and encrypt data.
8) Comparer - This feature is used to perform a comparison between any two requests, responses or any other form of data. This feature could be useful when comparing the responses with different inputs.

1) Proxy

The proxy feature allows us to intercept and modify requests. In order to intercept the requests and manipulate them, we must configure our browser to direct its traffic through Burp’s proxy, which is 127.0.0.1:8080 by default.
Want to learn more?? The InfoSec Institute Web Application Penetration Testing Boot Camp focuses on preparing you for the real world of Web App Pen Testing through extensive lab exercises, thought provoking lectures led by an expert instructor. We review of the entire body of knowledge as it pertains to web application pen testing through a high-energy seminar approach.

The Web Application Penetration Testing course from InfoSec Institute is a totally hands-on learning experience. From the first day to the last day, you will learn the ins and outs of Web App Pen Testing by attending thought provoking lectures led by an expert instructor. Every lecture is directly followed up by a comprehensive lab exercise (we also set up and provide lab workstations so you don't waste valuable class time installing tools and apps). Benefits to you are:

  • Get CWAPT Certified
  • Learn the Secrets of Web App Pen Testing in a totally hands-on classroom environment
  • Learn how to exploit and defend real-world web apps: not just silly sample code
  • Complete the 83 Step "Web App Pen Test Methodology", and bring a copy back to work with you
  • Learn how perform OWASP Top 10 Assessments: for PCI DSS compliance

Once this is done, open up Burp Suite. Go to Proxy, then Intercept and make sure Intercept is on.

Go to the alerts tab, we can see that a proxy service is running on port 8080. We can also change this configuration by going to the options tab under proxy.

Let’s have a look at all the options we have while running the proxy. Go to the options tab under proxy.

Here we can edit the port the proxy is listening on, and even add a new proxy listener. Burp also has option of presenting certificates to SSL protected websites. By default, Burp creates a self-signed CA certificate upon installation. The current checked option, i.e generate CA-signed per-host certificates will generate a certificate for the particular host we are connecting to signed by Burp’s CA certificate. The only thing with which we are concerned here is to decrease the number of warnings which a user gets when connecting to a SSL protected website.
If we don’t check the listen in loopback interface only option then this means that the burp proxy can serve as a proxy for other systems on the network too. This means any computer in the same network can use this Burp proxy as a proxy and relay its traffic through it.
The support invisible proxying for non-proxy-aware client option is used for clients that do not know that they are using a proxy. This means that the option for proxy is not set in the browser, but somewhere else, e.g., in the hosts.txt file. The only issue with this is that the request in this case will be a bit different than the requests when the proxy option is set in the browser itself, and hence Burp needs to know if it is receiving traffic from a non-proxy aware client. The redirect to host, redirect to port option will redirect the client to the host and port we specify in that option.

Similarly we can intercept requests and responses based on the rules we specify here. This could be a handy feature when we want to intercept only some of the requests in a very high traffic environment.

There are options for modifying HTML received from the response. We can unhide hidden form fields, remove JavaScript, etc. Similarly there is an option for finding a specific pattern and replacing it with a custom string. We need to specify regular expressions here. Burp will parse the request or response looking for this pattern and will replace it with the custom string.
Now that we have set up Burp Suite and the configurations in our browser properly, we can intercept requests. Please note that whenever we send a request, it will be intercepted by Burp Suite and we will have to forward it manually. Hence it is advisable to keep the “intercept is on” option checked only when you really want to see the contents of the packets going through.
Open up your browser and start browsing. We will see that the request is being intercepted by Burp Suite. Hence our proxy is working. We can right click on it and send the request to various other tools in Burp Suite for analysis.

2) Spider

Burp Spider is used for mapping web application. It will automatically crawl the web application looking for links and will submit any login forms it finds and hence provide a detailed analysis of the whole application. These links can then be passed over to Burp Scanner to perform a detailed scan using the information provided by the scanner. In this case I will be using the spider tool on DVWA (Damn Vulnerable Web Application). To do that simply go to the application DVWA using your browser, make sure intercept is on in Burp Suite, and get the request intercepted by Burp Suite. Right click on the intercepted request, and click on send to spider.

Once you do this, an alert will pop up asking us to add the item to the scope. Click on Yes. A scope basically defines the target region on which we want to run our tests.

If we go to the target tab under site map, we will see that the url has been added in the target. Also we can see that some other targets like http://google.com have been added to the targets list. Burp Suite automatically adds targets as we browse the web while using Burp’s proxy. We can add the targets to our scope by right clicking on any target and clicking on add item to scope.

Want to learn more?? The InfoSec Institute Web Application Penetration Testing Boot Camp focuses on preparing you for the real world of Web App Pen Testing through extensive lab exercises, thought provoking lectures led by an expert instructor. We review of the entire body of knowledge as it pertains to web application pen testing through a high-energy seminar approach.

The Web Application Penetration Testing course from InfoSec Institute is a totally hands-on learning experience. From the first day to the last day, you will learn the ins and outs of Web App Pen Testing by attending thought provoking lectures led by an expert instructor. Every lecture is directly followed up by a comprehensive lab exercise (we also set up and provide lab workstations so you don't waste valuable class time installing tools and apps). Benefits to you are:

  • Get CWAPT Certified
  • Learn the Secrets of Web App Pen Testing in a totally hands-on classroom environment
  • Learn how to exploit and defend real-world web apps: not just silly sample code
  • Complete the 83 Step "Web App Pen Test Methodology", and bring a copy back to work with you
  • Learn how perform OWASP Top 10 Assessments: for PCI DSS compliance
If we go to the Scope tab we find that the application dvwa has been added to the scope.

Go to the Spider tab now and click on options. Here we can set various options while running the Burp Spider on the application. We can ask it to check for the robots.txt file, in which it will try to crawl to the directories that the website administrator has not allowed to be indexed for search engines. Another important option is passively spider as you browse. Basically Burp Spider can be run both in passive and active mode. This asks Burp Spider to keep scanning for new links and content as we browse the web application using Burp’s proxy.

Another important option is application login. Whenever Burp Spider hits a login form while crawling, it can automatically submit the credentials that we provide to it here. I have asked Burp Spider to submit the credentials admin/password as these are the credentials used in DVWA. Hence Burp Spider will submit these credentials automatically and keep crawling ahead looking for extra information. You can also change the thread count if you want.

To begin spidering an application, just right click on the target to reveal the branch for DVWA (in this case dvwa) and click on spider this branch.

This will start the Burp Spider. If we go to the Spider control tab, we can see the requests being made. We can also define a custom scope for Burp Spider.

Once it has finished running, we will see a lot of new URL’s for dvwa branch. This provides us very useful information about the web application. We can then send these URLs to other Burp tools like Burp Scanner (available only in the professional edition) and scan it for vulnerabilities.

3) Intruder

Burp Intruder can be used for exploiting vulnerabilities, fuzzing, carrying out brute force attacks and many other purposes. In this case we will be using the Intruder feature in Burp Suite to carry out a brute force attack against DVWA. Browse over to DVWA and click on Brute Force. Enter any username/password, make sure Intercept is on in Burp Suite, and click on Login.

The request will be intercepted by Burp Suite, right click on it and click on send to intruder.

This will send the request information to the Intruder. Go to the Intruder tab. Now we will have to configure Burp Suite to launch the brute force attack. Under the target tab, we can see that it has already set the target by looking at the request.

Go to the positions tab now, here we can see the request which we had previously sent to intruder. Some of the things are highlighted in the request. This is basically a guess by Burp Suite to figure out what will be changing with each request in a brute force attack. Since in this case only username and password will be changing with each request, we need to configure Burp accordingly.

Click on the clear button on the right hand side. This will remove all the highlighted text. Now we need to configure Burp to only set the username and password as the parameters for this attack. Highlight the username from this request (in this case “infosecinstitute”) and click on Add. Similarly, highlight the password from this request and click on Add. This will add the username and password as the first and second parameters. Once you are done, your output should look something like this.

The next thing we need to do is set the attack type for this attack, which is found at the top of the request we just modified. By default it is set to Sniper. However, in our case we will be using the attack type “Cluster Bomb”. According to Burp’s documentation from portswigger.net here is the difference between the different types of attack.
Sniper – This uses a single set of payloads. It targets each position in turn, and inserts each payload into that position in turn. Positions which are not targeted during a given request are not affected – the position markers are removed and any text which appears between them in the template remains unchanged. This attack type is useful for testing a number of data fields individually for a common vulnerability (i.e., cross-site scripting). The total number of requests generated in the attack is the product of the number of positions and the number of payloads in the payload set.
battering ram – This uses a single set of payloads. It iterates through the payloads, and inserts the same payload into all of the defined positions at once. This attack type is useful where an attack requires the same input to be inserted in multiple places within the HTTP request (i.e., a username within the cookie header and within the message body). The total number of requests generated in the attack is the number of payloads in the payload set.
pitchfork – This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 8). The attack iterates through all payload sets simultaneously, and inserts one payload into each defined position. For example, the first request will insert the first payload from payload set 1 into position 1 and the first payload from payload set 2 into position 2. The second request will insert the second payload from payload set 1 into position 1 and the second payload from payload set 2 into position 2, and so on. This attack type is useful where an attack requires different but related input to be inserted in multiple places within the HTTP request (i.e., a username in one data field, and a known ID number corresponding to that username in another data field). The total number of requests generated by the attack is the number of payloads in the smallest payload set.
cluster bomb – This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 8). The attack iterates through each payload set in turn, so that all permutations of payload combinations are tested. For example, if there are two payload positions, the attack will place the first payload from payload set 1 into position 1, and iterate through all the payloads in payload set 2 in position 2; it will then place the second payload from payload set 1 into position 1, and iterate through all the payloads in payload set 2 in position 2. This attack type is useful where an attack requires different and unrelated input to be inserted in multiple places within the HTTP request (i.e., a username in one parameter, and an unknown password in another parameter). The total number of requests generated by the attack is the product of the number of payloads in all defined payload sets – this may be extremely large.
As we can see in the image below, our attack type is set to “Cluster Bomb”.

Go to the payload tab, make sure payload set 1 is selected, click on load and load the file containing a list of usernames. In my case I am using a very small file just for demonstrations purposes. Once you load the file all the usernames will be displayed as shown in the image below.

Similarly select payload set 2, click on load and load the file containing a list of passwords.

Go to the options tab now and make sure “store requests” and “store response” options are set under results. Have a look at all the options and see if you need or don’t need any of these options.

All right we are now set to launch our attack. Click on Intruder on the top left and click on start attack. We will see a window pop up with all the requests being made.
So how do we know which request is successful? Usually a successful request will have a different response than an unsuccessful request or will have a different status response. In this case we see that the request with the username “admin” and the password “password” has a response of different length than the other responses.

Let’s click on the request with a different response size. If we click on the response section, we see the text “Welcome to the password protected area admin” in the response. This confirms that the username/password used in this request is the correct one.

I recommend you explore Burp Intruder in more detail as it is one of the most powerful features available in Burp Suite.

4) Repeater

With Burp Repeater, we can manually modify a request, and resend it to analyze the response. We need to send a request to Burp Repeater for this. The request can be sent to it from various places like Intruder, proxy, etc.
Let’s send a request to Repeater from the Intruder attack we just performed on DVWA. To send the request to the Intruder, just right click on the request and click on Send to Intruder.

If we go to the Repeater tab, we can see the request there. We also see that there are 3 tabs with the name 1, 2 and 3. In Burp Repeater, a tab is used for each request.

We can also see the params, header, hex and raw format of the request. We can modify any of these before sending the request.

Let’s just change the username, password to the correct one, i.e., username=admin and password=password and click on Go. This will send the request.

We can analyze the response in the response section. Again we have the option to see the params, header, hex and raw format of the response. The render option displays the page as if it were displayed in a browser, though it is not fully reliable.

5) Sequencer

Burp Suite Sequencer is used to figure out the randomness of the session tokens generated by a web application. This is because session tokens are usually used to authenticate a user, and hence should not be compromised. It is important for a web application to have a high degree of randomness for session tokens, so that brute force attacks are not successful against it. We need to send a request which returns a session token to the sequencer, the Sequencer then repeatedly sends the request, thus obtaining a high number of session IDs. It then passes these session IDs through various statistical tests to determine the randomness.
Let’s send a request that returns a session token to the Sequencer. Right click on the request and click on Send to Sequencer.

In sequencer we can see that it automatically identified the ID parameter. We can also use manual selection to select it ourselves, or we can use the cookie and form field drop box to select the value which we think is the session token.

Click on start capture to start the process.

We can see the requests being made and the different tokens being received. It is good to have a sample size of at least 100-200 tokens before starting the analysis. However, the more no of tokens, the better would be the test results. Once you think you have captured enough tokens, click on Analyze now. We will see that Burp Sequencer is now performing all the tests.

The results are displayed as shown in the figure below. As we can see, the overall randomness within the sample is estimated to be excellent. You can switch between tabs to see the results of different types of analyses.

Burp Suite will still continue to capture tokens so that you can again perform the test once you have collected more tokens. Examining the different types of test and how they work is beyond the scope of this article. To understand how Burp Sequencer actually works, read this article.

6) Comparer

Burp Suite Comparer tool is used to do a comparison between two pieces of data, which could be requests, responses, etc. We must provide the Comparer tool with two pieces of data in order to do that. In this case we will be giving the Comparer tool a successful response and an unsuccessful response from the brute force attack against DVWA which we carried out earlier. Make sure the response tab is selected while sending it to the comparer so that we send the responses and not the requests. Right click on an unsuccessful response and click on send to comparer, do the same for the successful response (which is the response for request #11 in the figure below).

Go to the comparer tab. Here we can see the two responses which we had sent to it earlier. Click on the first response (#3) on the top half, and on the second response (#4) on the bottom half. Now the two responses have been selected to carry out the comparison.

We have two ways of performing a comparison between the two responses – through words or through bytes. Click on words to perform a comparison by words. The result is pretty clear. While one response has a “Username and/or password incorrect” message, the other one has a “Welcome to the password protected area admin” message.

Similarly, comparing by using bytes returns the following output. By now you must have begun to understand the importance of this tool.

7) Decoder

Burp Suite Decoder can be used to decode encoded data and get it back into its canonical form. It can also be used to encode and encrypt data to get the encoded and encrypted forms. We can manually paste data into the decoder or send an encoded request to it. In this case I will be sending an HTML Basic authentication request that contains the username and password in base64 encoded form to the decoder. Right click on the request and click on Send to Decoder

Highlight the encoded form and click on decode as and then click on base64

Burp Decoder decodes the base64 encoded string and gives us the username/password in plaintext.

You should check out the Smart Decode feature too in Burp Suite, in which Burp decoder intelligently guesses the encoding used and decodes it. Though it is not fully reliable and some mistakes might occur.

8) Scanner

Burp Scanner is one of the most powerful web application scanners. Though, like any other web application scanner, it is not perfect and some false positives may occur. Burp Scanner is not available with the free edition. You can find more information about Burp Scanner here.

Conclusion

In this article we looked at almost all the popular features of Burp Suite – proxy, scanner, sequencer, repeater, etc. The extent to which it can be helpful in Web application testing is only up to the imagination of the user which makes it a valuable tool for web application testing.

References

  1. PortSwigger Website
    http://portswigger.net/burp/
  2. Hacking Web Authentication – Part 1
    http://resources.infosecinstitute.com/authentication-hacking-pt1/
  3. Burp Sequencer 101
    http://blog.portswigger.net/2008/05/burp-sequencer-101.html
  4. Burp Scanner
    http://portswigger.net/burp/scanner.html