Healthcare: 1 || VulnHub Walkthrough

Hello everyone! Welcome to my latest video. Today, we'll be exploring a vulnerable machine called " Healthcare ". This machine is classified as " Easy ", in terms of difficulty.

To begin, visit the VulnHub website and download the vulnerable image. If you're not familiar with VulnHub, take a look at our VulnHub playlist for some useful tutorials.

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:

On VirtualBox, click on " Tools ." Then, select " Import " to bring in the OVA image file. 

This will open the " Appliance to Import " window, where you can browse and select the OVA image from your local storage. 

Click " Next ," and the " Appliance Settings " window will appear, where you will 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 " Healthcare " 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. Now, 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.20 ."

Network Scan to Identify Open Ports

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 the following command:

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 discovered the presence of two open ports.

• Port 21/TCP is running an FTP service, indicating that gaining access to the server with valid credentials will be straightforward.
• Additionally, Port 80/TCP is hosting an HTTP service, suggesting that a vulnerable website may be hosted on a target server.

Nmap Scripting Engine to Enumerate FTP

The scan results show that Port 21 is running an FTP server, FTPD 1.3.3d , which appears to be an old version. This increases the likelihood of vulnerabilities. To investigate further, we will use the Nmap Scripting Engine (NSE) .

To run, the following command:

When executed, the scan might take some time to complete because the Nmap Scripting Engine not only searches for vulnerabilities but also attempts to brute force the username and password.

Unfortunately, the scan did not provide any valuable information.

Web Enumeration

Now, let's explore the content of the website running on Port 80 . To look at the contents ourselves, open a web browser of your choice, and navigate to the target’s IP address in the URL bar at the top of the window.

Upon exploring the webpage, it appears to be that, it uses a Bootstrap responsive design. However, the visible content on the page doesn't provide any valuable information. 

To explore further, we can inspect the page's source code by right-clicking on the page and selecting, " View Page Source ," 

But this doesn't reveal anything useful either.

Directory Busting to uncover hidden or hard-to-access directories

To continue our investigation of the target URL, we will perform directory busting to uncover hidden or hard-to-access directories and pages. For this task, we'll use the " gobuster " tool with the following command.

Where, 

• gobuster dir is used to instruct gobuster to perform directory busting. 
• -u is used to specify the target URL we want to explore. 
• -w is used to provide the path to the wordlist containing common directory names to try.

Using Gobuster, we have identified various directories. Among these, I found,  /robots, which seemed potentially helpful for further exploration. Unfortunately, it didn't provide any valuable information. None of the other directories revealed useful information either.

Although, several directories such as /index, /images, /css, /js, /vendor, /fonts, and /gitweb were found.

Some directories like /phpMyAdmin, /server-status, and /server-info are accessible but return a 403 Forbidden status, indicating restricted access.

Let's try directory busting again using a larger wordlist. The wordlist we need isn't included in the default dirbuster wordlist, so we have to download it manually. 

Once downloaded, move it to the dirbuster directory, and run Gobuster again using the new wordlist.

Using this enhanced directory-busting approach, we have identified various directories. Among them, the /openemr directory stands out as particularly interesting. 

OpenEMR is an open-source electronic medical record and medical practice management application. This directory might contain a potentially vulnerable application.

Exploitation ( OpenEMR 4.1.0 - 'u' SQL Injection)

Let’s visit this web directory. 

Upon visiting this directory, it displays a login page, prompting for a username and password.

After identifying that OpenEMR 4.1.0 is running, it's important to check for any known vulnerabilities. Using searchsploit helps find publicly available exploits that can be used to compromise the system.

Here, I identified SQL injection vulnerabilities. 

Now, it’s time to copy, 49742.py . Copying the exploit script to the local directory allows you to inspect and execute it.

The copied Python file is saved in, the /home/kali directory. Now, we need to modify some basic needs. Replace the URL with our target URL, and save it.

Now, execute it. It will automatically, exploit the vulnerability to extract the username and password hash.

The credentials suggest administrative and medical roles, indicating a risk of unauthorized access to sensitive medical records and administrative functions. The obtained password hashes could potentially be cracked to reveal plaintext passwords.

Hash Cracking Using John the Ripper

For this purpose, we can use John the Ripper. 

But before that, we have these two hash in a text file. 

Now, run John the Ripper .

It successfully cracks the hashes, displaying the cracked passwords alongside the usernames. 

Since we have the username and password, the next steps involve leveraging the access to gain a more persistent and possibly privileged foothold on the system.

Foothold

Leveraging Openemr

By logging into OpenEMR with the cracked credentials, we have access to a wealth of patient and clinical data. 

From here, we can explore various functionalities, look for additional vulnerabilities, and establish a more persistent and elevated access level.

Since we logged in as administrators, it means, we have permission to modify or upload files on the website. This is crucial for finding ways to establish a more persistent and elevated access level.

Upon clicking on the Administration menu item, this expands various options that allow us to create and modify medical records, and also while looking for an entry related to file management or file editing among these options under the Administration menu, I find it out which is labeled simply as Files .

Clicking on this option displays us an interface where we can view and edit web pages in the OpenEMR web directory.

Here is a dropdown menu within the file edit interface. 

This dropdown may list all the web files in the directory. 

As I previously, thought, my guess is right. Select any file from this list to view its details.

Upon scrolling down, I figured out that there is a functionality to upload any file on the web directory. 

So it means, if we browse and upload, the reverse shell file and execute it, it may lead us to get the reverse shell .

Gain Reverse Shell by File upload 

So, we need a PHP reverse shell script, which can be located on the terminal, and we need to copy it to the user’s home directory. 

Use the upload functionality to upload this reverse shell script to the web directory. 

Before we upload this file, we have to replace the IP and Port with our listening Host and port of the attacking machine.

Next, start a listener using Netcat . 

Browse the uploaded file in a browser to execute it to initiate a reverse shell connection, and save it. 

Once it is saved, it can be accessible from the image directory. 

Now, let’s establish the connection by accessing from the web directory.

Once the reverse shell script is executed, we now gain a reverse shell connection to the target system.

This will give you command-line access, allowing for further exploration and exploitation, and also verify the user information to understand your current privileges. But it is not very valuable.

Let’s move on to the home.

Upon changing the directory path to the home directory, I discover 3 directories. Since it is in the home directory, it means, these are the user of the target machine.

We not access the user flag now, it is better to gather information by running LinPEAS which may lead us to escalate Privilege.

Privilege Escalation

Escalate Privilege using LinPEAS

Lin PEAS , is a powerful tool used to extract various information, including SUID binaries and vulnerabilities, which can aid in 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 w get 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.

After successfully downloading Lin PEAS 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 lin peas.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.

Upon analyzing the LinPEAS output, two unknown SUID binaries have been identified as potentially suspicious. These binaries are /usr/bin/Xwrapper and /usr/bin/healthcheck .

Let’s examine the binaries by running it.

The  /usr/bin/Xwrapper  binary is related to the  X Window System , which is a graphical windowing system for Unix-like operating systems.

The error message indicates an authentication failure and lack of console ownership, meaning the user running this binary doesn't have the necessary permissions to start an X server.

Now, let’s run the healthcheck binary. 

The  /usr/bin/healthcheck  binary is designed to perform a system health check.

The error message indicates that the TERM environment variable is not set, which is typically required for terminal-based applications to function properly. Despite this, the script displays information about network interfaces and disk partitions.

Now, let’s run strings to the command. The strings  the command displays printable strings in binary files. 

Running it on the healthcheck binary gives insight into what the binary does internally, revealing potential command executions and file paths.

The presence of the system function suggests that the binary executes shell commands.

The string clear; echo 'System Health Check' ; echo '' ; echo 'Scanning System' ; sleep 2 ; ifconfig ; fdisk -l ; du -h indicates the commands the binary executes: clear, ifconfig, fdisk -l, and du -h.

From the detailed findings, I discovered that:

We can exploit the SUID binary by replacing the clear command with a malicious script or binary. This is possible because the binary uses the system function, which relies on the PATH environment variable to locate executables.

Path Hijacking vulnerability in a SUID binary

By placing our malicious binary in a directory that appears earlier in the PATH, we can hijack the execution of clear.  Here, we copy /bin/bash to /tmp/clear , effectively replacing clear with bash .

Adjusting the PATH variable to include /tmp at the beginning ensures our malicious clear is executed instead of the legitimate one. 

Now, it’s time to Execute the healthcheck Binary. 

With the modified  PATH , running  /usr/bin/healthcheck  will execute  /tmp/clear  (which is actually  bash ), which leads us to the root shell.

To conform run the id command. This confirms that we have obtained a root shell.

For convenience, we spawn a proper interactive shell using Python. 

Let's view the flags both the user and root flags to complete the challenge. Changing the directory to almirant and listing the files and directories give us the user flag.

To get the root flag, we can find it in the Root directory. 

If there are any doubts or queries write me in the comment section.