Inside this Article:
- Settings Up
- Enumeration
- Identifying the IP address
- Enumerate the Network
- Web Enumeration and Directory Busting
- Troubleshooting the " We’re having trouble finding that site " error
- Identify the vulnerability
- Exploiting the LFI Vulnerability
- Foothold using Log injection Vulnerability
- Observing Log Injection Behavior with Burp Suite
- Trigger RCE to inject reverse shell
- Brute-force the username and password
- Privilege Escalation
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.
.png)
If you're new to VulnHub, check out our VulnHub playlist for helpful videos.
Vulhub: Vulnerable by Design
Vulhub provides a collection of pre-built vulnerable docker environments, designed for learning and practicing security vulnerability assessments and penetration testing. Explore various scenarios and improve your cybersecurity skills.
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.
.png)
To import an OVA image, navigate to the menu bar and click on " File ". From the dropdown menu, select " Import Appliance ".
.png)
Choose the downloaded OVA file from your computer.
.png)
Click " Next " and review the appliance details and settings. You can adjust them as needed.
.png)
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.
.png)
Select the virtual machine, go to " Settings ," and change the network adapter to " Host-only adapter ."
.png)
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.
.png)
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.
.png)
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.
.png)
Upon accessing this directory, I found another website built with Bootstrap, which I confirmed using Wappalyzer.
.png)
On
this website, every link is static except for the "
Get Started
"
navigation link.
.png)
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.
.png)
Troubleshooting the "We’re having trouble finding that site" error
This type of error appears due to two underlying reasons.
- 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.
- 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.
.png)
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.
.png)
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 ".
.png)
After inspecting the source code, we found a hint that might indicate a vulnerability.
.png)
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.
.png)
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.
SecLists: LFI Fuzzing
Explore SecLists, a collection of multiple types of lists used during security assessments, including lists for fuzzing Local File Inclusion (LFI) vulnerabilities. Enhance your penetration testing toolkit with these comprehensive lists.
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,0means 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
Upon inspecting the output of " ffuf," revealed an unsanitized file, possibly containing Apache access logs. This suggests a potential vulnerability related to log injection.
Log injection vulnerabilities arise when user-controlled data is not properly sanitized before being logged by the server. This can allow attackers to inject malicious code into the logs, potentially leading to various consequences.
Let's access the /var/log/apache2/access.log on the browser.
.png)
Upon accessing the "/var/log/apache2/access.log" file, I discovered that it contains detailed information about requests made to the Apache web server.
.png){kind=small}
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.
Burp Suite is a valuable tool for investigating potential vulnerabilities like log injection. By intercepting and analyzing traffic between the browser and the server, we can observe how the application handles user-controlled data.
So, Launch
Burp Suite from the Kali Menu, and configure the browser's proxy settings using
FoxyProxy.
.png)
Access the proxy tab, and activate intercept mode to capture target requests.
.png)
Switch the proxy to Burp Suite within the FoxyProxy extension.
.png)
Now, reload the page to intercept the request
data, then send the captured request to Burp Suite's repeater tool.
.png)
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.
.png)
Click on Send.
.png)
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.
.png)
This can help us see if the
server logs are vulnerable to code injection.
.png)
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.
.png)
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.
.png)
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.
.png)
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.
.png)
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.
.png)
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:
But I don't find anything suspicious there. I return to the previous directory and navigate to the
var
directory where I find a
backup
directory that looks
interesting.
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.
PEASS-ng: Latest Release
Check out the latest release of PEASS-ng, a set of scripts to perform privilege escalation on Windows and Linux systems. This release includes new features and improvements for better performance and usability.
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.
.png)
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.
.png)
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.
GTFOBins: Perl
Explore GTFOBins, a curated list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems. This page focuses on using Perl for privilege escalation and other security bypass techniques.
But here, I am looking for capabilities.
Capabilities
If the binary has the Linux
CAP_SETUIDcapability 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.
