Fuzzing SQL,XSS and Command Injection using Burp Suite

From Portswigger

Hello friends!! Today we are going to perform fuzzing testing on bwapp application using burp suite intruder, performing this testing manually is a time consuming and may be boring process for any pentester.

The fuzzing play a vital role in software testing, it is a tool which is use for finding bugs, errors, faults and loophole by injecting a set of partially –arbitrary inputs called fuzz into a program of the application to be tested. Fuzzer tools take structure input in file format to differentiate between valid and invalid inputs. Fuzzer tool are best in identifying vulnerability like sql injection, buffer overflow, xss injection and OS command injection and etc.

Let’s start!!

Fuzzing XSS

 Start burp suite in order to intercept the request and then send intercepted data into Intruder

Many input-based vulnerabilities, such SQL injection, cross-site scripting, and file path traversal can be detected by submitting various test strings in request parameters, and analyzing the application’s responses for error messages and other anomalies.

Considered following as given below:

Configure the position where payload will be inserted, the attack type determine the way in which payloads are assigned to payload positions.

Payload position: test (user input for first name)

Attack type: Sniper (for one payload)

Set payload which will be placed into payload positions during the attack. Choose payload option to configure your simple list of payload for attack. Configure the payload list using one of Burp’s predefined payload lists containing common fuzz strings.

Burp suite intruder contain fuzzing string for testing xss injection, therefore choose fuzzing –xss and click on ADD tab to load this string into simple list as shown in screenshot and at final click on start attack.

It will start attack by sending request which contains random string to test xss vulnerability in the target application. Now from given list of applied string select the payload which has highest length as output as shown in given image, we have select request 1 having length equal to 13926.

Insert selected payload into intercepted request and then forward this request as you can see in given image.

Bravo!!  Fuzzing test is completed and it found that application have bug which lead to xss vulnerability. From screenshot you can see it is showing an xss alert prompt.

Fuzzing OS command injection

Similarly repeat the same process in order to intercept the request and then send intercepted data into Intruder.

Configure the position where payload will be inserted, the attack type determine the way in which payloads are assigned to payload positions.

Payload position: www.nsa.gov (user input for target)

Attack type: Sniper (for one payload

Burp suite intruder contain fuzzing string which will test for os command injection, therefore choose fuzzing full and click on ADD tab to load this string into simple list as shown in screenshot and at final click on start attack.

It will start attack by sending request which contains arbitrary string to test OS command injection vulnerability in the target application. Now from given list of applied string select the payload which has highest length as output as shown in given image, we have select request 34 having length equal to 13343.

Insert selected payload into intercepted request and then forward this request as you can see in given image.

Great Job!!  Fuzzing test is completed and it found that application have bug which lead to OS command vulnerability. From screenshot you can see application is showing ID as per the request of the selected payload.

Fuzzing SQL

Similarly repeat the same process in order to intercept the request and then send intercepted data into Intruder.

Configure the position where payload will be inserted, the attack type determine the way in which payloads are assigned to payload positions. It is much similar like brute force attack.

Payload position: 1:1 (user input for login: password)

Attack type: Cluster bomb (for two payloads)

Burp suite intruder contain fuzzing string which will test for SQL injection, therefore choose fuzzing –SQL Injection for first payload postion and click on ADD tab to load this string into simple list as shown in screenshot and at final click on start attack.

Similarly repeat the same process to set payload option for second payload position.

It will start attack by sending request which contains arbitrary string to test SQL injection vulnerability in the target application. Now from given list of applied string select the payload which has highest length as output as shown in given image, we have select request 168 having length equal to 13648.

Insert selected payload into intercepted request and then forward this request as you can see in given image.

Wonderful!!  Fuzzing test is completed and it found that application have bug which lead to SQL injection vulnerability. From screenshot you can see we had login into Neo’s account without valid input this happens only as per the request of the selected payload.

Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

Beginner Guide to Understand Cookies and Session Management

From Wikipedia and w3schools

Cookie

Cookie is a small piece of data sent by a server to a browser and stored on the user’s computer while the user is browsing. Cookies are produced and shared between the browser and the server using the HTTP Header.

It Allows server store and retrieve data from the client, It Stored in a file on the client side and maximum size of cookie that can stored is limited upto 4K in any web browser. Cookies have short time period because they have expiry date and time as soon as browser closed.

Example- when you visit YouTube and search for Bollywood songs, this gets noted in your browsing history, the next time you open YouTube on your browser, the cookies reads your browsing history and you will be shown Bollywood songs on your YouTube homepage

Creating cookie

The setcookie() function is used for the cookie to be sent along with the rest of the HTTP headers.

When developer creates a cookie, with the function setcookie, he must specify atleast three arguments. These arguments are setcookie(name, value, expiration);

Image Source Goolge

Cookie Attributes

  1. Name: Specifies the name of the cookie
  2. Value: Specifies the value of the cookie
  3. Secure: Specifies whether or not the cookie should only be transmitted over a secure HTTPS connection. TRUE indicates that the cookie will only be set if a secure connection exists. Default is FALSE
  4. Domain: Specifies the domain name of the cookie. To make the cookie available on all subdomains of example.com, set domain to “example.com”. Setting it to www.example.com will make the cookie only available in the www subdomain
  5. Path: Specifies the server path of the cookie. If set to “/”, the cookie will be available within the entire domain. If set to “/php/”, the cookie will only be available within the php directory and all sub-directories of php. The default value is the current directory that the cookie is being set in
  6. HTTPOnly: If set to TRUE the cookie will be accessible only through the HTTP protocol (the cookie will not be accessible by scripting languages). This setting can help to reduce identity theft through XSS attacks. Default is FALSE
  7. Expires: Specifies when the cookie expires. The value: time ()+86400*30, will set the cookie to expire in 30 days. If this parameter is omitted or set to 0, the cookie will expire at the end of the session (when the browser closes). Default is 0

Necessity of Cookies

Cookies can be used for various purposes –

  • Identifying Unique Visitors.
  • Http is a stateless protocol; cookies permit us to track the state of the application using small files stored on the user’s computer.
  • Recording the time each user spends on a website.

Type of cookies

Session Cookie

This type of cookies dies when the browser is closed because they are stored in browser’s memory. They’re used for e-commerce websites so user can continue browsing without losing what he put in his cart. If the user visits the website again after closing the browser these cookies will not be available. It is safer, because no developer other than the browser can access them.

Persistent Cookie

These cookies do not depend on the browser session because they are stored in a file of browser computer. If the user closes the browser and then access the website again then these cookies will still be available. The lifetime of these cookies are specified in cookies itself (as expiration time). They are less secure.

Third Party Cookie

A cookie set by a domain name that is not the domain name that appears in the browser address bar these cookies are mainly used for tracking user browsing patterns and/or finding the Advertisement recommendations for the user.

Secure Cookie

A secure cookie can only be transmitted over an encrypted connection.  A cookie is made secure by adding the secure flag to the cookie. Browsers which support the secure flag will only send cookies with the secure flag when the request is going to a HTTPS page.

HTTP Only Cookie

It informs the browser that this particular cookie should only be accessed by the server. Any attempt to access the cookie from client script is strictly prohibited. This is an important security protection for session cookies.

Zombies Cookie

A zombie cookie is an HTTP cookie that is recreated after deletion. Cookies are recreated from backups stored outside the web browser’s dedicated cookie storage.

Sessions

PHP session: when any user made any changes in web application like sign in or out, the server does not know who that person on the system is. To shoot this problem PHP session introduce which store user information to be used across several web pages.

Session variables hold information about one single user, and are exist to all pages in one application.

Example: login ID user name and password.

Session ID

PHP code generates a unique identification in the form of hash for that specific session which is a random string of 32 hexadecimal numbers such as 5f7dok65iif989fwrmn88er47gk834 is known as PHPsessionID.

session ID or token is a unique number which is used to identify a user that has logged into a website. Session ID is stored inside server, it is assigns to a specific user for the duration of that user’s visit (session). The session ID can be stored as a cookie, form field, or URL.

Explanation:

Now let’s have a look over this picture and see what this picture says:

In given picture we can clearly see there are three components inside it: HTTP Client, HTTP server and Database (holding session ID).

Step1: client send request to server via POST or GET.

Step2: session Id created on web server. Server save session ID into database and using set-cookie function send session ID to the client browser as response.

Step3: cookie with session ID stored on client browser is send back to server where server matches it from database and sends response as HTTP 200 OK.

Image Source: Google Images

Session hijacking

As we know different users have unique session ID when an attacker sniff the session via man-in-middle attack or via XSS and steal session ID or session token this is called session hijacking. When attacker sends the stealing session ID to web server, server match that ID from database stored session ID. If they both matched to each other then the server reply with HTTP 200 OK and attacker get successfully access without submitting proper Identification.

Example 1: Using the session cookies issued to the user by the server.

For example, on any website an official user logged-in, and the server has generate a session cookie SESSION-TOKEN for that user. If the SESSION-TOKEN is the cookie which recognized the session of that user, the attacker can steal the SESSION-TOKEN cookie value to login as the legitimate user. The attacker can perform a cross-site scripting or other technique to steal the cookie from the victim’s browser.

Let’s suppose the attacker steals the cookie PHPSESSID=user-raj-logged-in-2341785645. Now, he can use the cookie with the following request to post a status (HACKED!!!!!!) in the victim’s home page:

 POST /home/post_status.php HTTP/1.1

Host: www.Facebook.com

Cookie: PHPSESSID=user-raj-logged-in-2341785645

Content-Length:38

Content-Type:application/x-www-form-urlencoded

 Status= HACKED!!!!!&Submit=submit

The attacker uses the cookie subjected to the authorized user, and gains control on the user’s session.

Example 2: Guessing the cookie values of users if a complicated algorithm is not used for the cookie generation.

For example, consider a website uses an algorithm to generate cookies for the users. If the user name is “raj”, then the cookie generated for the user could be “LOGINID=-772017- qszbik”. In this case, the algorithm used to generate the cookie can be as follows:

First part of the cookie is the date i.e. 7/7/2017 and second part is the arrangement of the previous and next alphabet letter for each letter of the username “John” (i.e., the previous letter for r is “q” and the following letter is “s”). If the attacker is able to break the algorithm, he might estimate the cookie of users and hack their session.

  r=qs

  a=zb

  j=ik

If the attacker decide to hack the session of admin, he can make a cookie as LOGINID =772017- zbcelnhjmo, login to raj’s session and post a status on his account.

Host: www.facebook.com

Cookie:LOGINID =772017- zbcelnhjmo

Content-Length:45

Content-Type:application/x-www-form-urlencoded

 Todays_status=I am hacked!!!!!!&Submit=submit

Session hijacking tutorial

For this tutorial I have targeted DVWA, here cookie name is dvwa Session.

Note: session ID for this page will change every time when we will close the browser.

Now capture the browser request using burp suite.

From given image we can see the cookie holds PHPSESSID P38kq30vi6arr0b321p2uv86k0; now send this intercepted data into repeater to observe its response.

In response you can see the highlighted data show set –cookie: dvwaSession =1 more over HTTP 200 OK response from server side.

According to developer each time a new sessionID will generate by server each time, but attacker sniff this session ID P38kq30vi6arr0b321p2uv86k0 for unauthorized login.

Next time we receive another session id when data is intercepted through burp suite i.e. PHPSESSID= gutnu601knp4qsrgfdb4ad0te3, again send this intercepted data into repeater to observe its response.

But before we perceive its response, replace new PHPSESSID from old PHPSESSID.

From given image you can observe we have replaced the SESSION ID and then generate its response in which set –cookie: dvwaSession =6 and HTTP 200 OK response from server side.  

Now change the value inside intercepted data and then forward this request to the server.

Session Vs cookies

Session Cookies
Data are stored on Server Data are stored in Client’s Browser
Sessions Data are more secure because they never travel on every HTTPRequest Travel with each and Every HTTP request
You can store Objects (Store Large Amount of Data) You can store strings type (Max File Size 4 kb)
Session Cannot be used for Future Reference Cookies are mostly used for future reference

Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

Beginner Guide to Insecure Direct Object References (IDOR)

Insecure Direct Object References (IDOR) has been placed fourth on the list of OWASP Top 10 Web application security risks since 2013. It allows an authorized user to obtain the information of other users, and could be establish in any type of web applications. Basically it allows requests to be made to specific objects through pages or services without the proper verification of requester’s right to the content.

OWASP definition: Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.

The Application uses untested data in a SQL call that is accessing account information.

Let consider a scenario where a web application allow the login user to change his secret value.

Here you can see the secret value must be referring to some user account of the database.

Currently user bee is login into web server for changing his secret value but he is willing to perform some mischievous action that will change the secret value for other user.

Using burp suite we had captured the request of browser where you can see in the given image login user is bee and secret value is hello; now manipulate the user from another user.

SQLquery = “SELECT * FROM useraccounts WHERE account = ‘bee’;

Now let’s change user name into raj as shown in given image. To perform this attack in an application it requires atleast two user accounts.

SQLquery = “SELECT * FROM useraccounts WHERE account = ‘raj’;

Great!!!  We have successfully changed the secret value for raj.

Note: in any official website the attacker will replace user account from admin account.

Let take another scenario that look quite familiar for most of IDOR attack.

Many times we book different order online through their web application for example bookmyshow.com for movie ticket booking.

Let consider same scenario in bwapp for movie ticket booking, where I had book 10 tickets of 15 EUR for each.

Now let’s confirm it and capture the browser request through burp suite.

Now you can see we have intercepted request where highlighted text contains number of tickets and price of one ticket i.e 15 EUR it means it will reduce 150 EUR from my (user) account; now manipulate this price from your desire price.

I had changed it into 1 EUR which means now it will reduce only 10 EUR from account, you can observe it from given image then forward the request.

Awesome!!! We had booked the 10 tickets in 10 EUR only.

Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

Beginner Guide to OS Command Injection

The dynamic Web applications may make the most of scripts to call up some functionality in the command line on the web server to process the input that received from the client and unsafe user input may led to OS command injection.  OS Command injection is refer as shell injection attack arise when an attacker try to perform system level commands through a vulnerable application in order to retrieve information of  web server or try to make unauthorized access into server .

Impact Analysis

Impact: Critical

Ease of Exploitability: Medium

Risk Rating: High

In this attack the attacker will inject his unwanted system level command so that he can fetch the information of web server; for example: ls , whoami , uname -a and etc.

Let’s consider a scenario where web application allows user to PING an IP other user so that it get confirms that the host connection 

Verify parameters to inject data

 The following parameters should be tested for command injection flaws, as the application may be using one of these parameters to build a command back at the web server:

  • GET: In this method input parameters are sent in URLs.
  • POST: In this method, input parameters are sent in HTTP body.
  • HTTP header: Applications frequently use header fields to discover end users and display requested information to the user based on the value in the headers.

Some of the important header fields to check for command injection are:

  • Cookies
  • X-Forwarded-For
  • User-agent
  • Referrer

METACHARACTER

Using vulnerability scanner attacker come to know that current web application is vulnerable to command injection and try injecting system level unwanted command using Meta character.

Metacharacter are symbolic operators which are use to separate actual command from unwanted command. The ampercent (&) was used as a separator that would divide the authentic input and the command that you are trying to inject.

It will more clear in following image where attacker will inject his payload dir using metacharacter that retrieve present directory of web server.  

As result it will dump following output as shown in given image where it has validated wrong user input.

OS Command Injection Operators

 The developer possibly will set filters to obstruct the some metacharacter. This would block our injected data, and thus we need to try out with other metacharacters too, as shown in the following table:

Operators Description
; The semicolon is most common metacharacter used to test an injection flaw. The shell would run all the commands in sequence separated by the semicolon.
& It separates multiple commands on one command line. It runs the first command then the second command.
&& It runs the command following  && only if the preceding command is successful
||(windows) It run the command following || only if the preceding command fails. Runs the first command then runs the second command only if the first command did not complete successfully.
|| ( Linux) Redirects standard outputs of the first command to standard input of the second command
The unquoting metacharacter is used to force the shell to interpret and run the command between the backticks. Following is an example of this command: Variable= “OS version `uname -a`” && echo $variable
() It is used to nest commands
# It is used as command line comment

Steps to exploit – OS Command Injection

Step 1: Identify the input field

Step 2: Understand the functionality

Step 3: Try the Ping method time delay

Step 4: Use various operators to exploit OS command Injection

Type of Command Injection

 Error based injection: When attacker injects a command through an input parameter and the output of that command is displayed on the certain web page, it proof that the application is vulnerable to the command injection. The displayed result might be in the form of an error or the actual outcomes of the command that you tried to run. An attacker then modifies and adds additional commands depending on the shell the web server and assembles information from the application.

Blind based Injection: The results of the commands that you inject will not displayed to the attacker and no error messages are returned it similar as blind SQL injection. The attacker will use another technique to identify whether the command was really executed on the server.

Mitigation-OS Command Injection

  • Strong server side validation
  • Implement a white list
  • OS Hardening
  • Use build in API’s for interacting with the OS if needed. More secure!!
  • Avoid applications from calling out directly the OS system commands

Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

Related Posts Plugin for WordPress, Blogger...