BlackWidow: 1 || VulnHub Walkthrough

Hello everyone! Welcome to my new video. Today, we're exploring a vulnerable machine called " Black Widow ". This machine is part of a single series and is categorized as " Medium " in terms of difficulty.

To get started, head over to the VulnHub website and download the vulnerable image. 

If you're new to VulnHub, check out our VulnHub playlist for helpful videos.

Settings Up

Once you've downloaded the image, the next step is setting up the server in VirtualBox. This process is quite simple and involves importing the OVA file into VirtualBox using the " import appliance " feature.

Importing the OVA file into VirtualBox is a straightforward process. Here's how to do it:

Launch VirtualBox. 

To import an OVA image, navigate to the menu bar and click on " File ". From the dropdown menu, select " Import Appliance ".

Choose the downloaded OVA file from your computer. 

Click " Next " and review the appliance details and settings. You can adjust them as needed. 

Click " Finish " to start the import. Once the import is finished, you'll see the " Black Widow " vulnerable machine listed in the VirtualBox Manager under the VulnHub group. 

Select the virtual machine, go to " Settings ," and change the network adapter to " Host-only adapter ."

It's important to ensure that both your Kali Linux machine (used for attacks) and the vulnerable machine are connected to the same network, so make sure they're both connected via the host-only adapter. 

Now, it’s time to start the VM, and you'll notice that our Vulnerable Machine is ready, with a login prompt awaiting. 

Let's dive into the fun!

Enumeration

Identifying the IP address

The initial step in our attack is enumeration, which involves identifying the IP address of our target machine using NetDiscover. To execute this, open a terminal and run " netdiscover -i " followed by specifying the network interface name, which in this case is " eth1 ."

From the scan results, we've obtained our target IP address: " 192.168.95.16 ."

Enumerate the Network 

Next, we'll conduct a network scan to identify open ports, a crucial step in the enumeration process. This helps us understand the attack surface and strategize targeted attacks. We'll use the popular Nmap tool for this task. Run " nmap -sC -sV {specify the IP address} ".

In this command, " -sC " is used to perform a script scan using the default set of scripts, while " -sV " enables version detection, allowing us to identify which versions are running on which port.

After completing the network scan, we found 5 open ports:

• Port 22/TCP : OpenSSH is running here, allowing for secure shell (SSH) access.
• Port 80/TCP (HTTP) : An Apache web server is running, but the default page doesn't have a title, suggesting it might be a default or misconfigured setup.
• Port 111/TCP (RPCbind) : Several RPC services, including NFS, Mountd, and Nlockmgr, are available. This could indicate a network file system setup.
• Port 2049/TCP (NFS) : Network File System is running, which might allow for remote file sharing. This could be a potential target if not properly secured.
• Port 3128/TCP (HTTP Proxy) : The Squid proxy server is running, but it returned an error page, indicating it might be configured for specific use or restricted access.

Web Enumeration and Directory Busting

Now, let's explore the web content hosted on port 80 . Open a web browser and enter the target's IP address in the URL bar. 

After analyzing the webpage, we didn't find any additional links or pages that might reveal potential vulnerabilities.

To investigate further, we'll use directory busting to uncover hidden or hard-to-find directories and pages. For this task, we'll use the " dirb" tool.

Using " dirb," I identified an important directory called " company," which looks suspicious. Let's visit this page.

Upon accessing this directory, I found another website built with Bootstrap, which I confirmed using Wappalyzer. 

On this website, every link is static except for the " Get Started " navigation link.

Clicking on "Get Started" results in a " We’re having trouble finding that site " error, indicating that we can't connect to the server at blackwidow.com.

Troubleshooting the "We’re having trouble finding that site" error

This type of error appears due to two underlying reasons. 

1. You might have accidentally typed the web address (URL) incorrectly in the search bar. This confuses the computer's naming system (DNS) and it can't find the corresponding website.
2. You might have left the search bar empty entirely. Some websites require you to enter an address (like a specific page name) to navigate to the content you want.

We can fix this by modifying the local DNS file named " hosts " located in the “/etc” directory. Open a terminal, type nano, and then specify the path of the “ hosts ” file.

Add the IP address with its associated hostname in the “/hosts” table, which would allow your web client to visit the website that was previously reporting an error.

Now save it using CTRL + X and hit Enter. Once this configuration is complete, reload the target's webpage to verify if it loads successfully. 

Since the requested hostname now has an association in the hosts file, the website should load without any issues.

Identify the vulnerability

Let's check the application for potential security weaknesses. To examine the underlying code and gain insights, we can view the page source code. Right-click anywhere on the webpage and Select " View Page Source ".

After inspecting the source code, we found a hint that might indicate a vulnerability. 

There's a mention of a " file " parameter that seems to be used for including files. This suggests a possibility of an LFI (Local File Inclusion) vulnerability existing in the application.

Exploiting the LFI Vulnerability

LFI (Local File Inclusion) vulnerabilities can allow us to access sensitive files on the server. To verify this, we'll conduct further tests to identify any LFI vulnerabilities in the URL.

Identifying exploitable parameters

By examining the page source code, we found parameters that might be used to manipulate the URL. These parameters typically appear after a question mark (?) followed by key-value pairs separated by equal signs (=).

When I tried simple key-value pairs, I didn't get any useful results. 

Utilizing ffuf for advanced testing

To explore a wider range of possibilities, we'll use a tool called ffuf . 

This tool automates the process of testing various payloads (data inputs) within the URL parameter. The goal is to identify potential values that might trigger LFI.

Finding a suitable wordlist

Unfortunately, the default wordlists included with Kali Linux don't have a specific one for LFI testing. A popular resource called SecLists offers wordlists for various security assessments, including LFI. However, SecLists isn't pre-installed on Kali. 

We'll need to download it from the SecLists GitHub page for further testing.

The command you can use on the terminal for fuzzing a URL is:

ffuf -u <target_URL> -w <wordlist> -c -i c -r --fs 0

Here's a breakdown of the options used:

• -u <target_URL> : This specifies the target URL you want to fuzz. Replace <target_URL> with the actual URL you want to test.
• -w <wordlist>: This specifies the path to the wordlist file containing the payloads to be tested. Replace <wordlist> with the actual path to your wordlist file.
• -c: This enables color output for better readability in the terminal.
• -ic: This instructs ffuf to ignore any comments present within the wordlist file.
• -r: This tells ffuf to follow redirects encountered during the fuzzing process.
• --fs 0: This option filters the responses based on the HTTP status code. In this case, 0 means ffuf will show all responses, regardless of the status code.

The ffuf scan appears to have been successful in uncovering a Local File Inclusion (LFI) vulnerability within the application. This vulnerability allowed the tool to access and read the contents of several sensitive files on the server.

Here's a breakdown of the discovered files:

• /etc/passwd: This file contains critical information about user accounts on the system, including usernames, hashed passwords, and other user details. Accessing this file can be a major security breach.
• /etc/group: This file stores information about groups on the system, including group names and the users belonging to each group.
• /proc/self/cmdline, proc/self/stat, proc/self/status: These files are specific to the Linux operating system and provide details about the currently running process, including its command line arguments, resource usage, and overall status.
• /var/log/apache2/access.log: This file functions as the access log for the Apache web server, recording details about user requests, including IP addresses, timestamps, and accessed resources.

This indicates that the application does not properly sanitize the file parameter, allowing an attacker to traverse directories and access files outside the intended directory. 

This vulnerability could be exploited further to gain more information about the system, and its users, and potentially gain a foothold on the server.

Foothold using Log injection Vulnerability

Let's access the /var/log/apache2/access.log on the browser.

Upon accessing the "/var/log/apache2/access.log" file, I discovered that it contains detailed information about requests made to the Apache web server.

To gain a foothold, we need to inject malicious code into the logs. This involves sending a request with malicious code in a field that gets logged, such as User-Agent or Referer .

Observing Log Injection Behavior with Burp Suite

For this purpose, I'll use Burp Suite, to observe the behavior of the injection in the /var/log/apache2/access.log. 

So, Launch Burp Suite from the Kali Menu, and configure the browser's proxy settings using FoxyProxy.

Access the proxy tab, and activate intercept mode to capture target requests. 

Switch the proxy to Burp Suite within the FoxyProxy extension.

Now, reload the page to intercept the request data, then send the captured request to Burp Suite's repeater tool.

Select a captured request and analyze it within the Burp Suite's Repeater tool to identify a suitable HTTP header (e.g., User-Agent) to inject a test payload.

Send the captured request to the repeater tool(CTRL+R) in Burp Suite. 

When we send the request, we get the logs of previous inputs in the response section. 

Now, it's time to inject a payload into the logs. This can manipulate log files, disclose information, and potentially allow Remote Code Execution if the logs are not handled correctly. 

To do this, we inject the RCE PHP code snippet into the log files by making a request with the code in the User-Agent or another HTTP header. 

This can help us see if the server logs are vulnerable to code injection.

Trigger RCE to inject reverse shell

Now, it’s time to trigger Remote Code Execution. 

After injecting the PHP code, include the “ cmd ” parameter after the access.log file in the request, to execute system commands. Here, I will use the id command to test this. 

When I send this data, we receive the user and group names and numeric IDs (UID or group ID) of the current user, which is www-data , in the log file.

Next, it's time to execute malicious code to get a reverse shell. For this purpose, here, I will use a bash reverse shell script. 

Let me change the listening host IP address with my Kali Linux host-only IP address, and set the listening port to 4444.

Before sending the request to execute this setup, I will turn on a listener using Netcat.

After that, send the request to gain a shell. 

Initially, the shell request didn't seem to work, so I decided to encode the URL to see if that would fix the issue. I used an online URL encoder for this purpose and then sent the request again. 

After exploiting a vulnerability, a remote shell was successfully obtained on the target machine "Blackwidow." 

This initial foothold likely has limited privileges.  Let's check if we can access the user flag. First, let's change to the home directory and list the files and directories:

I find a directory named viper , which seems to be the target's username. Change to the viper directory and list its contents. 

However, when I try to access the user flag, I get a " permission denied " error. Additionally, there is another file in the directory that looks suspicious. 

Upon attempting to access it, I do not have the necessary permissions. Next, I decided to look for any backup files in the web directory: 

I change into this directory and discover an important file,  auth.log .

The auth.log contains logs of user login attempts. By examining its contents using the cat command, I see a large amount of data.

The identified file is named " auth.log " which potentially contains logs of login attempts on the target machine. In some cases, these logs might contain usernames or even passwords if they were not properly masked during login.

This scenario highlights a potential vulnerability where login credentials could be leaked within the system logs, especially if sensitive data is not sanitized before logging. It emphasizes the importance of secure login practices and proper logging configurations to mitigate such risks.

So, I get the idea to copy this data, modify it into a wordlist, and then use it to perform a brute-force attack on the target to find the correct password.

Brute-force the username and password

For this purpose, First, I save the output of auth.log to my Kali Linux system using a text editor, and save it as log.txt . 

Next, I extract words and create a wordlist by running this command to process the log.txt file, and generate wordlist.txt .

Now, I will attempt a brute-force attack on SSH, which we identified as an open port from the earlier nmap scan.

I use Hydra for this purpose. We already know that there is a user named, viper . 

After running Hydra, I discover a valid password. With the username and password in hand, I log in using an SSH client tool.

Once logged in, I have user-level permissions. So, let’s check for the user flag, and there it is. 

Next, try to access the root flag:

Unfortunately, I got a " permission denied " error. This means I need to gain root access to obtain the root flag and complete our lab.

Privilege Escalation

During privilege escalation, the initial step involves gathering system information to pinpoint potential vulnerabilities or misconfigurations that could grant higher access privileges, ultimately leading to root access.

To begin, we need to examine the permissions assigned to users to assess their privileges on the system. This can be achieved by executing commands like " sudo -l " to view the commands the current user can run with elevated privileges.

However, it appears that the user " viper " does not have permission to run sudo. 

Let's gather more details by checking the kernel version using the " uname -a " command, and searching for any associated exploits using searchsploit. 

Unfortunately, this search doesn't yield any results.

Upon further exploration, a suspicious directory named " backup-site " is discovered within the home directory. 

Enumerate the Linux Privilege using LinPEAS

To delve deeper into potential vulnerabilities, we'll employ LinPEAS, a powerful tool designed to extract various system information, including SUID binaries and vulnerabilities conducive to privilege escalation.

To get started, download LinPEAS from its GitHub repository. 

Once you have LinPEAS, initiate a Python3 HTTP server.

Switch back to the target server and use the wget command to download LinPEAS from the IP address of the machine running the Python3 HTTP server. 

If you are unsure about the IP address of your host-only adapter, you can use the “ ifconfig eth1 ” command to find it.

But upon running, I found out that, on the target system, wget is not available. So, to download the linpeas.sh file, I will use, the curl tool.

After successfully downloading LinPEAS on the target server, use the “ ls -al ” command to check if the file exists. 

Upon inspecting, I discovered that the linpeas.sh file does not have the necessary execution permissions.

To resolve this, give the execution permission to the linpeas.sh, file using the “ chmod +x linpeas.sh ” command. 

Once the execution permission is granted, run the linpeas.sh file. This time, it should execute without any issues.

After running “ linpeas.sh ”, the tool will generate output, providing comprehensive information, including SUID binaries , vulnerabilities, and other relevant data to aid in the privilege escalation process.

After reviewing the  LinPEAS output, I found that the suspicious directory contains a tool with permissions for executing at the root level. 

To exploit the arsenic binary for privilege escalation, we can utilize its cap_set uid+ep capability. This feature enables the binary to alter its user ID to any user, including root.

Uncover embedded information in binaries

For a better understanding, let's download it to Kali Linux using the SCP tool. 

SCP is renowned for its simplicity and seamless integration with SSH, facilitating secure file transfers across networks. 

Let's execute it. 

Upon execution, the file will be automatically downloaded. Now, let's examine the readable strings using the strings command.

The strings command extracts readable text from binary files like executables, object files, and core dumps. It scans the file for sequences of printable characters and displays them. This tool is commonly used in reverse engineering and security analysis to uncover embedded information in binaries.

In the strings output, I found a reference to Perl. Finding the reference to perl within the arsenic binary, which could potentially be significant for privilege escalation. This suggests that the binary might invoke Perl scripts or use Perl in some capacity.

To understand how the tool works, I'll run it with the help option. 

In the help menu, I noticed the -e flag, which can compile a program. Since arsenic is built with Perl, there's a possibility of compiling a Perl program.

Visit this website, where you will find out various shell codes to gain root. 

But here, I am looking for capabilities.

Capabilities

If the binary has the LinuxCAP_SETUID   capability set or it is executed by another binary with the capability set, it can be used as a backdoor to maintain privileged access by manipulating its own process UID.

• cp $(which perl) .
  sudo setcap cap_setuid+ep perl
  
  ./perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/sh";'
  

After copying the code, I'll paste it after the arsenic binary. 

Upon execution, it provides a root shell. Now, let's navigate to the root directory to obtain the root flag. 

That concludes this tutorial. If you have any questions or concerns regarding this video, feel free to leave a comment below.