Pureblood –Information Gathering and Security Auditing Tool

Pureblood is a Python tool that can be used during the information gathering and gaining access phases of penetration testing. Pureblood can collect useful information about target web applications, such as Banner grabbing, WHOIS record, DNS data, reverse DNS lookup, reverse IP lookup, CMS information, ports information, admin panel paths, subdomain scan results, subnet information, file and directory fuzzing, zone transfer lookup, Shodan search, and Shodan host lookup data. The security auditing features include SQL database injection and WordPress vulnerabilities analysis. Moreover, Pureblood can perform some miscellaneous tasks like generating defaced pages, random passwords, and message digests.

Pureblood Installation

Pureblood does not require any installation. We can clone Pureblood from Github as follows.

git clone https://github.com/cr4shcod3/pureblood

Pureblood depends on the following packages.

python-whois
Colorama
Dnspython
Requests
bs4
shodan

The required packages can be installed through the following pip command.

cd pureblood
pip install –r requirements.txt

How Pureblood Works

Pureblood can be set into action using the following command.

python pureblood.py

Since Pureblood can be used for information gathering, vulnerabilities detection, and aforementioned miscellaneous tasks, we can select the desired utility by typing the respective sequence number from the menu list.

Let’s suppose we want to start with information gathering utility. Selecting information gathering utility displays all the information gathering features of the tool as shown below.

Before utilizing the listed features, we have to define the target web application in the following manner.

The rest of the tasks are performed by selecting the desired features (sequence numbers). For instance, the tool performs the banner grabbing by selecting its sequence number (#1). The results are displayed in the following format.

The port scanning task can be performed by selecting its sequence number (i-e #7). However we have to select the end limit of ports to be scanned. The tool lists all the open ports in the defined range.

Extracting (directory) links is an important information gathering feature of Pureblood. The tool gathers all the (directory) links on the target web application that can further be explored for potential vulnerabilities.

The security auditing tasks can be performed by selecting the Web Application Attack option from the main menu.

The process of utilizing web attack (security audit) features of Pureblood is similar to the information gathering tasks. For instance, the SQL injection test scan be performed by selecting its sequence number (i-e #2) from the Web Application Attack menu. The tool requires target link to test the possibility of SQL injection. If the web application is vulnerable, the tool fetches backend database information and enumerates all the vulnerable columns.

Pureblood also enumerates the database tables in the following format.

We can further explore the data in tables by mentioning the desired tables and columns. Following is a screenshot of one of the extracted tables from the target web application. The table i-e users has different fields like uname (username), pass (password), email, address, and phone number.

We can obtain information against each table field in the table by mentioning their names in the following format.

Pureblood can check different WordPress vulnerabilities shown in the following screenshot.

We can also use Pureblood for miscellaneous tasks like generating defaced page templates and generating message digests (hashes).

Conclusion

Pureblood can help red teamers during different stages of penetration testing. The tool gathers detailed information about target web applications. The tool can simulate SQL injection and WordPress attacks in details to identify the potential vulnerabilities and bugs in web applications.

Wapiti –Web Applications Security Auditing Framework

Wapiti is a vulnerability assessment framework that performs black box security auditing of the web applications. The vulnerabilities that can be assessed with Wapiti include database injections, Local File Inclusion (LFI), Remote File Inclusion (RFI), command execution, CRLF injection, Server Side Request Forgery (SSRF), XML External Entity (XXE) injection, Shellshock bugs, .htaccess attacks, and source code disclosure vulnerabilities. The database injection includes SQL, XPATH, PHP, ASP, and JSP injection attacks. Command execution attack analysis includes detection of eval(), system(), and pastru() vulnerabilities. Wapiti makes use of the pre-installed modules to perform these assessments.

Wapiti Installation

Wapiti is a Python based framework. Clone Wapiti using the following Github path.

git clone https://github.com/IFGHou/wapiti

Navigate to the wapiti directory to install the framework using the following commands.

cd wapiti
python3 setup.py install

Wapiti Working

The framework can be launched by running the wapiti executable from bin folder in Wapiti directory. The help command loads all the mandatory and optional parameters of Wapiti.

python3 wapiti -h

The following basic command executes Wapiti framework to scan vulnerabilities in target web application.

python3 wapiti –u <target web application>

Let’s assume a web application (testphp.vunweb.com). The following command loads all Wapiti modules to scan the application for the aforesaid vulnerabilities.

python3 wapiti –u http://testphp.vulbweb.com

Wapiti finds all the available links on the target web application and runs each module one by one against each file (link). If any file (link) is found vulnerable, Wapiti mentions it in Command Line Interface (CLI) along with the attack path and potential injection parameters.

Since Wapiti basic command loads all the modules, the process can take some time to scan web applications with too many directories and pages. The CTRL+C command halts the current scan process with few options, such as skipping the active module and executing the next, generating report without performing further analysis, and stopping the whole scanning process without generating any reports.

Besides launching all modules, Wapiti allows using a specific module. The –lists-modules argument lists all the available modules in Wapiti framework.

Python3 wapiti --list-modules

The –m parameter in the following format executes desired module for specific vulnerabilities assessment.

python3 wapiti –u <target web application> -m <module name>

For instance, we can limit the vulnerability search scope to SQL injections by using the sql module in the following format.

python3 wapiti –u http://testphp.vulnweb.com –m sql

The above command loads all the modules, however executes only sql module to find out SQL related vulnerabilities in the target web application.

The module goes through each directory and page to find out the SQL vulnerabilities. We can define depth level to limit the scanning process to desired number of links or files. The –max-links-per-page argument is used to define the maximum links to be scanned one each page of the target web application. Similarly, –max-files-per-dir argument is used to define maximum number of files per directory. Wapiti supports many other arguments that can be used along with the search command. All these options can be explored in the help section. Besides displaying individual findings in CLI, Wapiti generates a detailed report of detected vulnerabilities in the root directory. The report is in HTML format that can be viewed in preferred web browser.

Conclusion

Wapiti is an automated way of searching top level web application vulnerabilities. The framework does not rely on the provided url path. Rather, it scans all the directories and pages in the target to find out the potential vulnerabilities.

PwnLab CTF Walkthrough Part 1: Recon and Data Extraction

Welcome back everyone! This is the first in a new series we’re launching that will walk you through various capture the flag (CTF) challenges. In order to ease into this new series we’re going to take a minute now to detail what a CTF challenge is (for those of you that don’t already know). Then, we’ll get hacking at the PwnLab: init CTF challenge. So, let’s get started!

What is a CTF Challenge?

Simply put, a CTF challenge is a system that has been intentionally configured with vulnerable software for the sole purpose of hacking. When hacking a CTF the “player” (attacker) must find and exploit these vulnerabilities in order to gain access to a text file containing the flag. Once the flag has been read, the game is won!

You may be wondering how this helps us become better hackers. Well, my direct answer to that question is: practice makes perfect! If we really take the time to play these CTF challenges, we become exposed to a far wider range of attacks than we’d normally see. By seeing and using these attacks ourselves, we gain a better understanding of how they work, which in turn makes us better hackers. Now that we know what a CTF is and the perks gained from playing them, let’s get started at hacking our first CTF challenge!

Hacking the PwnLab: init CTF

The first CTF challenge we’ll be taking a crack at is PwnLab: init. This is meant to be a relatively easy CTF to complete, so it’s a perfect candidate to start us out! When we download PwnLab, it comes as a VM, so we can run it inside VirtualBox, which is what we’ll be doing here. This CTF can get a bit lengthy, so we’re going to split the pwnage up into two parts. This part will be reconnaissance and preparing the attack, and the next part will be exploitation and privilege escalation. Let’s get hacking!

Step 1: Finding the Target

If we’re going to hack PwnLab, we need to know it’s address! Since PwnLab is configured to automatically pull an IP address via DHCP, we need to have a scan running in order to see it’s address. So, we’ll start the scan, then we’ll start the PwnLab VM and we’ll have the address. We’ll be hacking PwnLab from BackTrack, so we’ll be using netdiscover. First we need to find the address range to use in netdiscover. We can use the ifconfig command for this:

We can see that our address is 10.130.10.18 with a subnet mask of 255.255.255.0. By representing this information is CIDR notation, we can deduce that we need to scan for the 10.130.10.0/24 range of IP addresses. The netdiscover tool has a lot of output, so I’ve typed the command out as well. Now that we have our scan ready, let’s execute it. We’ll need to give it a second to gather results, then we’ll start our VM. Once we do, we should see a new host appear in the scan results:

We can see at the end of our netdiscover output that we have the IP address of out target, 10.130.10.41. Now that we have this address, we can do some recon on the target.

Step 2: Performing a Port Scan with Nmap

In order to find potential vulnerabilities on our target, we need to know what ports are open, and what services are listening on those ports. To find this oh-so-valuable information, we’ll be performing a port scan using nmap. Let’s see the command and the output, then we’ll discuss what’s happening under the hood:

We can see that we’ve not only used nmap, but we’ve given a variety of flags and switches to customize our scan. We’ve disabled host checking (-Pn), enabled SYN scanning (-sS), and enabled service detection (-sV). We’ve also specified that we only want to scan ports 1 through 4000. Then, we pipe the output into a new text file named nmap.txt. This is so that we can look at the scan results again at any time without having to re-scan the target.

We can see by the result of our scan that PwnLab is hosting a MySQL database and some sort of website. The database may contain some sweet goodies, but I think we’ll take a look at this web server being hosted on port 80 first.

Step 3: Analyzing the Web App for Vulnerabilities

Since we know that there’s a web app being hosted on PwnLab, we’re going to see if we can find any vulnerabilities to exploit. We’re going to start by pointing our browser to PwnLab’s IP address. Once we do, we should be greeted with a home page like this:

Nothing particularly stands out on the home page, so let’s move to the login page and see if anything sticks out to us:

When we move to the login page, we can see the URI change as a new resource is selected. After some research I found that there’s a local file inclusion vulnerability in this sort of resource selection. Local file inclusion (LFI) can help us read files that we otherwise shouldn’t be able to read. In this case, we can use it to read the source code of the PHP scripts that run the web app. We’ll have to use a variant of LFI that uses built-in PHP converters to convert the source code to base64 so we can decode and read it.

Step 4: Retrieving and Reviewing the Login PHP Script Source Code

In order to exploit this LFI vulnerability, we simply need to modify the URI and point the base64 converter to the login.php resource. Once we do, we should see a result such as this:

There we go! We successfully exploited LFI. Now we need to retrieve this base64 string and decode it to get the login PHP script source code. We can download the base64 string by re-using the current URL and feeding it to the curl command, we’re also going to save the output to a file named tmp.txt. Let’s do that now:

Now, the curl command will also save the rest of the source code for the webpage, so we need to open a text editor and remove the HTML tags so we have nothing but the base64 string left; I’ll leave that to you. Now that we have our base64 string in a text file, we can decode it and delete our temp. file. Let’s decode the base64 now:

We’ve decoded the base64 and stored the output in a new text file. We then delete our temporary file as we no longer need it. Now that we have the login page source code, let’s take a look at it:

Step 5: Retrieving and Viewing the Config PHP Source Code

We can see here at the very beginning of the login PHP source code, it required code from another resource named config.php. Since the LFI worked for the login PHP script, it should work for the config PHP script as well. I’m not going to go through the whole process again, as it’s the exact same steps we took before. I will however post a screenshot with all the steps. Let’s download and decode the config.php source code:

Now that we have the config.php source, we can see what PwnLab is trying to hide from us:

Aha! We found a username and a password inside the config.php source code. I’m willing to bet that these are the credentials we need to log into the MySQL database we saw earlier!

Step 6: Log into and Explore the MySQL Database

Now that we have the creds to get into the MySQL database, we can log in and see what goodies they’re trying to keep from us. We can use the default MySQL client installed on BackTrack to log into and explore the MySQL database. Once we give all the info to our client, we should be prompted with a password, and once we enter the password, we should be given a MySQL prompt. Let’s log into the database now:

There we go! Our stolen credentials checked out and now we have access to the database. Now we can use the show and use commands in order to find and select a database, and show the tables inside that database. Let’s start by looking for databases with the show command:

When we execute our show command, we are returned with a single database under the name Users. This must be where they keep all the user passwords! Let’s utilize the use command in order to select this database, then we’ll use the select command to extract all the data from it:

Once we extracted all entries from the users table we were given a table of usernames and passwords. But, it seems that the passwords are encoded with base64. But, that’s not a problem for determined attackers like us!

Step 7: Retrieve and Decode the Credentials

I’ve made a new file named users.txt and have stored the usernames and passwords in it. We can now go through and use the echo command along with the base64 command in order to decode each of these passwords. We’ll start by decoding kent’s password:

Now we just have to repeat this process for the other two usernames and we end up with credentials that look like this:

Now that we have credentials, we may be able to cause more havoc in the web app we used earlier! But, we’ll save that for the next part, as we’ve done more than enough damage here.

Today we covered and demonstrated the concept of LFI and basic data extraction with native tools. In the next part, we’ll use these newly found credentials to gain access to the functionality of the web app, and thus the PwnLab server. We’ll then perform some privilege escalation and capture that flag!

How to Find and Use Public Exploit Code

Welcome back my fellow hackers! Today we’re going cover how to find and use public exploit code. Often times when trying to compromise a target, we find vulnerabilities that we, the attackers, can exploit. But it would be extremely time consuming if we had to develop our own exploits every time we wanted to take advantage of these vulnerabilities. Instead of being forced to make our own exploits, what if we could just use code already written by somebody else?

exploit

In order to demonstrate this concept of code-borrowing, we’ll be hacking a Metasploitable VM from a Backtrack VM. First, we’ll get a basic shell on the victim server, then we’ll do some privilege escalation and get root! Also, throughout the process, we’ll be using online resources to find code that we can use in our hacks.

In order to get our basic shell, we’ll be exploiting a file upload vulnerability in the DVWA which is available through the web server provided by Metasploitable. First, we need to open a browser (In Backtrack we have FireFox) and navigate to the DVWA. It should reside at Home page > DVWA (Note: The user name and password is admin: password). Next, we navigate to the vulnerability upload page. It should look something like this:

You can also get to the upload vulnerability page by using this URI:

Now that we’re at the GUI, we can discuss this vulnerability. This file upload function can allow us to upload a PHP script that will give us a basic shell on the server. But, we don’t have a PHP script to do this. So, let’s just ask Google for PHP reverse shells. Once we look this up, we can find a page from pentestmonkey with just the code we need! The page should look like this:

But, if you want to speed up the downloading process, just run this command:

Now that we have a tar.gz file, we need to perform some commands in order to prepare it for uploading. Let’s take a look at the commands and then we’ll explain the reason for them:

First, we use the tar command with the x and f flags, this will extract the specified file. Once we extracted our tar.gz file, a new directory appeared. Then we entered this new directory and checked its contents, which was the PHP script that we needed. Then, we use the move command to rename the PHP script to rs.jpeg.php. By renaming this file, we can trick the DVWA’s upload function into accepting our PHP script as a legitimate file. But, if we want our payload to connect back to us, we need to change some information within the script. It’s very simple, the lines we need to change are marked by the developer with comments. Let’s see these changed values:

As seen in the changed values above, we’ve set the payload to connect back to the attacking machine on port 4444. Now that we’ve found and prepared our payload, let’s upload it:

Now that we’ve navigated to our script, let’s upload it and see what the DVWA thinks of our file:

There we go! We successfully uploaded our shell. Now, instead of keeping our browser open, let’s just figure out the URI we need to trigger and use the curl command to trigger it. We’ll be using Netcat to control our shell once we receive the connect back. In order to do this, we’ll need to setup a listener on port 4444 before we trigger the payload with curl. Let’s take a look at both of these commands:

Now, when we execute the payload triggering curl command, we should receive a shell on our Netcat listener. Let’s trigger the payload now:

We have a shell! This allows us some very restricted control of the server. But we can do better than this, let’s do some privilege escalation and get ourselves of root shell! First, we need to find the kernel version the Metasploitable is running. We can do this with the uname command:

As we can see here, our victim is currently running kernel version 2.6.24. Now, we can tell from this that we have a privilege escalation opportunity here.

It’s time to introduce something insanely useful, Offensive Security’s very own exploit database. This database is maintained by the same people that make Kali, the successor to Backtrack. With over 35,000 exploits on archive, this database can help us on many occasions. Let’s use the search option to look for an exploit for the Linux kernel 2.6. Let’s enter our query and check the CAPTCHA box, now let’s see the results:

We can see here that our query returned two exploits. We’re going to be using the first result, which is a UDEV privilege escalation exploit for Linux kernel 2.6! In order to download this exploit code, we can run the following command:

Now, when this exploit fires, it will run whatever file is under /tmp/run with root privileges. That means we need to make a payload to run. Since this is very simple, we can just whip this payload up ourselves. Let’s go ahead and make this payload in C:

This code simply calls Netcat to connect back to the attacker on port 1337 and serve a bash shell through that connection. Now that we have the code for our payload (run.c), we’re ready to move on. Since these files need to be on the server in order to work, we need to find a way to move them over. If we start the apache2 service on our Backtrack machine, we can use the shell we already have to download the files from our attacking machine to the victim server. Once we start the apache web server, we need to move our files to /var/www in order for them to be accessible. Let’s prepare our apache server now:

(Note: We also need move the run.c file to /var/www.) Now that we have our server started and our files in the proper places, we can download them to the victim server by using the basic shell we already have. Let’s transfer our files now:

Since we have the permissions of the DVWA web application, we only have permission to write files in the /var/www directory. Now that we have our files downloaded, we can prepare for the exploit. First, we need to prepare the payload and put it in the proper place (/tmp/run). Let’s prepare our payload now:

We can see here that we use the GNU GCC compiler to compile our run.c file into an executable named run. We then move this executable to /tmp, and that concludes the preparation of our payload. Now that we’ve prepared our payload, let’s get our exploit ready to fire:

Nothing much to see here, we just used the same compiler to compile our exploit into another executable. Now, in order to this exploit to work, we need to know the process ID of the process we’re going to attack. We can find the PID of this process by reading the contents of /proc/net/netlink. Let’s read this file now:

We can see by the results above that the only PID we see in the netlink file is 2293. This is the PID of the process we’re going to attack. Now that we have everything in place and ready, we can launch our second attack. But before we do, we need to setup another Netcat listener to catch our root shell:

Now that we have our listener ready, let’s move back to our shell on the victim and launch our exploit:

Now that we’ve fired our exploit, let’s go back to our Netcat listener and see if we caught anything:

There we have it, we have a root shell! I know we talked about a lot of different things today, but here’s the gist; being able to find and use preexisting exploit code can be an incredibly valuable skill. It will not only save you time, but it allows you diagnose exactly what is wrong with the target. Today we proved that public exploit code can be used for some very powerful things. I’ll see you next time!