Changing burpsuite versions on Kali Linux

You may have used Burpsuite in the past and are now wondering why some features such as Spider are missing from newer versions. The following instructions will install an older version of burpsuite on Kali Linux and get the burpsuite Spider back.

Head to Portswigger’s burp releases page and grab a legacy version that supports Spider. In this case, we grabbed version 1.7.36 Community Edition. On Kali Linux, the installer is a .sh file. Make sure you download the correct version for your Kali instance (32bit/64bit).

Use chmod to allow the sh to be executed:

chmod +x

Run the bash script file:

sudo ./

The install script will open up a wizard. Point the install at an appropriate folder. In my case I installed burp to /opt/tools/.

Now we must add the new burpsuite install to /usr/bin so that we can run it easily from the terminal. The old burpsuite will need to be renamed. In this case, we’ll rename it to burpsuite_latest and make sure to use this one when we want to use the latest version of burpsuite:

cd /usr/bin
sudo mv burpsuite burpsuite_latest
cp /opt/tools/BurpSuiteCommunity/burpsuite_community.jar /usr/bin/burpsuite

The last step is allowing the new burpsuite to be executable:

sudo chmod +x burpsuite

Now we’re all done! We can launch the legacy version of burpsuite by simply executing the ‘burpsuite’ command in a terminal. As shown in the image below, our legacy version of burpsuite has the Spider feature.

VulnHub Walkthrough – Kioptrix #1

Vulnhub link: kioptrix #1

I attempted (and succeeded) to root this box as part of my preparations for the OSCP exam. This was a very easy box to own (it is noted as ‘beginner’ for a reason)

netdiscover to find the target host:


In this case, our target is located at Let’s run a standard nmap scan against it.

nmap -sS -sV -T4 -A -O -v -v -v -v

Nothing of interest to be found on the web server that is running on port 80/443. Running dirb against it reveals the directory /manual/ on the server. If we navigate here we can see two manuals for Apache mods. One of these mods is mod_ssl. Navigating to /manual/mod/mod_ssl/ reveals that the version of mod_ssl is 2.8.


Searching exploit-db for Apache 1.3.20, we find a remote buffer overflow vulnerability affecting mod_ssl that allows us to run arbitrary code. Bingo.

Download an exploit of this vulnerability called OpenFuck from GitHub. Depending on whether or not it has been updated from the time of this post, you will have to make one small modification to the source code. In its current state, there is a typo on line 1087 of OpenFuck.c (broken if statement). Change it to so that it matches the following:

if (encrypted_key_length <= 0) {
     printf("send client master key: RSA encryption failure\n");

You should now be able to successfully compile the exploit using gcc (make sure to link it with the crypto library using the -lcrypto option).

gcc -o OpenFuck OpenFuck.c -lcrypto

Running ./OpenFuck outputs a massive list of OS fingerprints. The two we are interested in are 0x6a and 0x6b for RedHat Linux 7.2 (apache-1.3.20-16)1 and 2. We will pass this parameter to OpenFuck so it knows what memory offset to use.

./OpenFuck 0x6b 443 -c 40

After a few seconds, we should have root access to the box.


Configuring Splunk and Snort On Your Home Network

Prerequisites: A Windows/Linux machine capable of running Splunk and Snort. Basic networking knowledge. Basic knowledge of network/port scanning and a machine capable of doing so.

Splunk is a SIEM (Security Information and Event Management) system used widely by Security analysts across the industry. There is a basic version available for free (with a limit of one user account). This is perfect for your home network defensive needs.

So head on over to Splunk’s website to download the latest version of Splunk Enterprise (7.2.6 at the time of this writing). After a sixty day trial your license will convert to a free license.

Ideally you would have an independent server on your network running Splunk 24/7. Running it alongside other tools (e.g., snort) on your personal machine can bog it down and cause other personal programs to run slowly.


After the installation completes, a browser window should open with a login prompt for Splunk. If the web service didn’t automatically open, navigate to localhost:8000/. Enter the username and password combo that you set during the installation.

Download the “Splunk for Snort” app from splunkbase. This app allows Splunk to search fields relevant to Snort (e.g., source ip/port) as well as show statistics and generate reports.

On the home page of Splunk, click “+ Find More Apps” on the main menu (the left side of the page). Now from the drop down menu in the top-left corner of the screen, click “Manage Apps.” From here we can see all of the apps that are installed and we have the option to install new ones. Click “Install app from file” and upload the Splunk for Snort tar.gz file that was previously downloaded.

Now if you navigate to the main page the Splunk for Snort app should be visible in the main menu.

We are going to configure the IDS (Intrusion Detection System) Snort on our system as well. If you don’t know what that is I’m not quite sure how you found this post but all you need to know is that Snort filters through your network traffic and creates alerts when certain traffic is found. Again, ideally you would have Snort on some machine that is then passing traffic onward to the rest of your network so that you can capture all inbound traffic for analysis. We will add an App to Splunk which will allow it to pull data gathered from Snort. We won’t have to pour over thousands of lines in a text file anymore to analyze potentially dangerous traffic. Download Snort and follow the instructions for installation based on your OS.

Navigate to your Snort rules directory and create a file named sample_rules.conf. Insert the following text into the file and save.

output alert_full: alert.full
alert tcp any any -> any any (msg:"FIN Scan" ; flags: F ; sid:1;)
alert tcp any any -> any any (msg:"Xmas Scan" ; flags: FUP ; sid:2;)
alert tcp any any -> any any (msg:"Null Scan" ; flags: 0 ; sid:3;)

The first line of this conf file formats the output of Snort’s alert log so that the Splunk for Snort App can utilize it properly. This simple rule set will create an alert whenever a FIN, Xmas or Null scan is detected. The purpose of this set is to showcase how Splunk imports Snort data. A much more “full” rule set can always be created afterwards.

Home Page > Add Data > Monitor > Files & Directories and select the folder where Snort stores its alert files. In my case, it’s C:\Snort\log. Add “alert.full” in the whitelist field so that Splunk will only monitor the correct Snort file. Click Next.


On the Input Settings page we need to make a few more important configurations. For source type, Splunk for Snort uses two different data types: snort_alert_full and snort_alert_full. In our case we have elected to use the alert_full output format. Click “Select” and enter “snort_alert_full.” Then for App Context, select the Splunk for Snort App. Click Next. Review the settings and click Submit.

If you need to modify these settings in the future (maybe to use the fast alerts instead), navigate to Settings > Data > Data inputs and find the rule.

Now start running Snort on your machine. Issue a command in your terminal similar to the following (you may have to change the file location(s) or network interface).

snort -i1 -l c:\snort\log -c c:\snort\rules\sample_rules.conf

From another machine (in my case, an instance of Kali running in VirtualBox) run FIN, Xmas and Null scans against the machine running Snort. Use the -sF, -sX, and -sN options in nmap respectively.

Back in Splunk, navigate to the Spunk for Snort App and execute a search against the monitored data set (e.g., “null” or “src_port = AND name = “Xmas scan””)

Searching the data set for null scans

And there you have it! Splunk will now pull in your Snort IDS data and you will be able utilize Splunk’s extensive analytics tools.

Splunk for Snort generates reports like this one — Top 10 signatures

I hope this tutorial helps you out with defending your home network. If you have any questions or comments please post them below!

~ D

PHP Spot the Bug Challenge

Recently I came across one of Securify‘s “spot the bug” challenges. The goal is to find one (or possibly more) critical vulnerabilities in the following code:

if (empty($_POST['hmac'] || empty($_POST['host'])) {
   header('HTTP/1.0 400 Bad Request');
$secret = getenv("SECRET");
if (isset($_POST['nonce']))
    $secret = hash_hmac('sha256', $_POST['nonce'], $secret);

$hmac = hash_hmac('sha256', $_POST['host'], $secret);

if ($hmac !== $_POST['hmac']){
    header('HTTP/1.0 403 Forbidden');
echo exec("host "._POST['host']);

The immediate line that sticks out to me is the last one — the exec() call. This function is used to execute an external program (its output will be displayed by the echo call). Thinking like an attacker, finding a way to somehow inject our own command into this exec call would give us the ability to directly interact with the underlying system. Let’s see how we can manipulate this value with the code available to us.

Starting from the top, the first if statement is simply a check to see if the host or hmac variables have not been set in the POST request. All it does is return a HTTP 400 error and then exit. Nothing of real interest here.

Next the secret key value is being set to equal some environment variable on the system named SECRET. Again, not much we can do here other than perhaps attempt to brute-force the secret key value, but this could take a lifetime.

If the user sets a nonce value, the script will call the hash_hmac function to return a keyed hash value using the nonce provided by the user. The hash_hmac function in PHP takes three parameters: the encryption algorithm, the data to encrypt, and the secret key.

This calculated value is then compared with an hmac value that the user provides in the POST request. This assumes that only a user with knowledge of the correct secret value would be able to generate a valid hash…

However, passing an array as the second argument causes the function to return NULL and display a warning message. What this means is that if we pass in an array as the nonce value in the POST request, the $secret value will always evaluate to NULL. We can fire up php in interactive mode to demonstrate the bug:


The second hash_hmac call will look something like this:

hash_hmac(‘sha256’, ‘hostvalue’, NULL);


Even with a secret value of NULL, the hash_hmac function still computes a value. This lets an attacker calculate the hash value for anything.  If an attacker calls this hash_hmac function on their own machine, entering a command in place of the data parameter, a valid hash will be generated that will cause the php exec call to run the attackers input command. The command will have to be preceded by a ‘;’ character.

For example, to call the linux program whoami, an attacker would do the following:

1. Calculate the hash_hmac value for hash_hmac(‘sha256’, ‘;whoami’, NULL). This value will be passed to the web server in a POST request as the hmac value.
2. Pass ‘;whoami’ as the host value in the POST request.
3. Pass an array in for the nonce value in the POST request.;whoami&nonce=%5B%5D