CS6262_SUMM25 Project 1-Network Security Solution

Table of Contents
Project 1: Introduction to Penetration Testing 2
Introduction 3
Learning Goals 3
Virtual Machine 4
Minimum Hardware to Run the Project 1 VM: 4
Networks 5
Networking in Docker 5
Environment Setup: 6
Project Tasks (100 points): 7
Setup 7
Task 1: Network Scanning (10 points) 9
Task 2: Exploit the Shellshock Vulnerability (20 points) 10
Task 3: Brute Force with Metasploit (25 points) 11
Introduction to Metasploit 12
Task 4: Privilege Escalation (20 points) 17
Task 5: Password Cracking (25 points) 18
Background on Using John the Ripper 18
Task 5.0 Demonstration of John the Ripper – Not For Credit 18
Extra Task 6 – Optional, Not for Credit 21
Task 6 Bypass Authentication with HTTP Request Smuggling 22
Deliverables: 23
Reminders: 23
Acknowledgments: 24
Appendix 1 – Resources / Links 24
Appendix 2 - Running the VM on an ARM-based Mac 25
Emulating x86/x64 on Apple MX Chipset 25
Disclaimers 26
Requirements 26
Obtaining the Virtual Disk Image from the OVA 26
Creating the Emulated Virtual Machine 26
Configuring the Emulated Virtual Machine 27
Completing Course Projects via SSH 27
Obtaining the VM's IP address 28
Completing Project 1 over SSH 28
Appendix 3 - VirtualBox Networking 29
NAT Networking 29
Bridged Networking 30
Restarting VM Networking 30
Forwarding Ports to Your Host 30
Appendix 4 – VM Troubleshooting 32
Closing 33


Project 1: Introduction to Penetration Testing
Summer 2025

This project involves port scanning and the programmatic creation of network attacks and other hacking techniques. Be certain that you always direct attacks at the Docker container ONLY. Accidentally scanning outside your local network could have serious consequences.

The Docker network is on 172.22.0.0/24 (CIDR notation) in the VM, do not scan other networks!
- We make such warnings here, in part, so that you avoid unauthorized port scanning. It’s an interesting subject, you can learn more at https://nmap.org/book/legal-issues.html.
- These attacks are intended only for the isolated environment of the virtual machine.
- Your ISP Terms of Service likely ban unauthorized (or any) port scanning, don’t port scan the Internet.
- Never scan a computer that you don’t have explicit, written permission to scan.

Introduction
Penetration testing is an important part of ensuring the security of a system. This project introduces some of the common tools used in penetration testing, while also exploring common vulnerabilities (such as Shellshock and bit exploits).

In this project, you will gain hands-on experience by exploiting a server running inside a Docker container, hosted within a virtual machine (VM). You will better understand the Shellshock vulnerability, how privilege escalation can occur, and how to crack weak passwords — all crucial elements in penetration testing.
There are Tasks centering on the use of Metasploit and getting a privileged shell on the Docker container. There is also a new optional task, Task 6 HTTP
Smuggling, that we hope students will try, but is not part of the graded project.
Learning Goals
In this project, you will:
• Learn to use penetration testing apps and techniques in a Linux virtual machine, attacking a vulnerable Docker container.
• Perform network reconnaissance to discover open services running inside a containerized environment.
• Exploit common web vulnerabilities to gain remote code execution inside the target container.
• Use Metasploit to automate attacks and establish shells on the container.
• Escalate privileges inside the container by exploiting misconfigured binaries or services.
• Crack passwords and recover sensitive files to simulate postexploitation activities.
• Document attack steps clearly to demonstrate real-world penetration testing workflows and best practices.

Virtual Machine
For this semester’s project we are releasing a new virtual machine (VM). It’s x86based, using Xubuntu 24.04 which uses the xfce user interface. This is done to require less processing power than the Gnome-based full Ubuntu release for graphical user interface (GUI) users.
One GUI note about xfce, if you try to grab the lower corners of windows it’s hard to grab and resize diagonally. It’s much easier to grab and drag the upper corners of windows.
Minimum Hardware to Run the Project 1 VM:
• 8th generation chips better support virtualization than previous gen chips.
• At least 4 logical cores (e.g., quad-core CPU or dual-core with hyper-threading).
• 4 GB RAM strongly recommended, perhaps could run on 3GB, not less.
• SSD strongly recommended for increased performance.
• Host OS must support virtualization (e.g., VT-x enabled in BIOS).
If you are trying to use our x86-based VM under emulation on an ARM-based Mac, then you should NOT expect to be able to use the xfce-based GUI environment. It might work, but it will be very slow. Instead, ARM-based VM users will be using ssh to access the services needed on the VM.
We only provide limited support here, M-based Macs are not a supported platform for CS 6262. Please see Appendix 2 for instructions on how to attempt to make this work on an ARM-based Mac.
Networks
For your convenience we have opened port 22 on the VM. The VM runs the openssh server. In VirtualBox, you can set up Port Forwarding, see Appendix 2 for information. Once you set up port forwarding of the VM port 22 to your chosen port on your host, you can simply use ssh localhost:chosen_port_number to login to the VM from your host.
Because we have opened the ssh port on the VM, the VM is only as secure as your network. In theory, your typical home network has a router that uses Network Address Translation and blocks all incoming ports from incoming connections from the outside world. This means in theory, assuming that your router isn’t hacked, attackers on the Internet can try to attack your routers WAN IP Address, but the router will rebuff any connection that wasn’t originated in your network. Also in theory, your ISP is doing something to block these attacks, but some will get through.
The minute you open a port on your router for your favorite game, you have just opened a can of worms. We strongly recommend you turn the port forwarding on your router OFF while working on this project. Having said that, we also recommend you turn it off all the time.
Consider where the instructions tell you to access the vulnerable website at the target IP address and vulnerable target port. In the VM you would enter the IP address of the Docker container and the port number together into the browser.
Once you set up forwarding, the vulnerable web server port is available on the port you choose on your host. The IP address will be different. We forward the target webserver port on the Docker container to the VM itself. Thus, it’s possible to use the VM’s localhost address followed by the target port number to access the vulnerable website like: http://localhost:9999.
See Appendix 3 for more information about two popular VirtualBox networking styles and other VirtualBox information.
Networking in Docker
Relative to the Docker network, remember that the VM has one network interface that talks to your host, and another interface to talk on the Docker network. You’ll see more about this in the details of Task 2. The Docker network is 172.22.0.0/24 on this VM. Google CIDR (related to networking) if this notation doesn’t make sense to you, it’s CIDR notation to denote a network with 254 nodes. The VM Docker interface and the Docker container both live in this network address range.
Environment Setup:

You will be provided a virtual machine (VM) based on Xubuntu 24.04 Linux, preinstalled with necessary tools like Metasploit and John the Ripper. Inside this VM, a Docker container will run, it has various vulnerabilities that you will attack.
Provided Files:
- CS6262-Release-01.ova: The Virtual Machine image (Ubuntu Linux)
- assignment_questionnaire.txt: Template for final submission

Steps:
1. Install the latest version of VirtualBox (7.1.8 or newer).
2. Download the VM ova file from the link on Canvas.
3. Import the VM ova file into VirtualBox using the Import Appliance menu item.
4. Start the VM in VirtualBox once it’s done importing, this will take some time.
6. The password is 6262student and can also be found in Canvas.
7. Once logged in, from your home directory, run:
./StartShockServer.sh
8. The vulnerable container will then be accessible on the Docker network.
9. For this project, the container address is on the 172.22.0.0/24 network. Important: You are attacking the Docker container, not the VM itself.
Note: Once you start the Docker container, it will restart itself if it dies, unless you run the ./StopShockServer.sh script.
Project Tasks (100 points):
Setup
The first step in any penetration test is to gather information about the network and servers you’ll be exploiting. In this task, you will perform network scanning and answer a few questions based on your findings. On startup, the shellshockvulnerable container in the VM runs a webserver and listens to multiple ports for incoming messages. It also runs a ssh server.
In the VM logged in as penteststudent, open a Terminal Emulator window.
First, before doing anything else, run the command to start up the Docker container that runs the vulnerable services:
./StartShockServer.sh
You should see a message after a few moments that the container has started. While it’s not strictly necessary, when you are shutting down or rebooting the VM, you can run the shutdown command first:
./StopShockServer.sh
Now, let’s investigate the network. At the command prompt, enter this command:
ip a
You will see the output pictured in Figure 1.
In the output you will see various network interfaces. The important ones are:
lo -- this is the loopback interface, it refers to the VM itself. It’s the same, effectively, as 0.0.0.0 and 127.0.0.1 (with minor differences).
docker0 -- this is the default Docker network on 172.17.0.0/24, we will not be using it.
br-a795c89aa411 -- this is an important interface, it’s the VM’s interface on the Docker network. From this entry you can see the Docker network is 172.22.0.0/24, note this address as it will come in handy for the next steps. It’s possible the interface will use a different br-xxxx ID, though we wouldn’t expect it to. Here you can see the VM’s Docker address is 172.22.0.1.

Figure 1 -- Output of ip a command shows the different network interfaces’ properties
There’s also (when the container is running) a veth-xxxx interface. This is the virtual ethernet interface for the running Docker container. While you could use the IPV6 address you see in the output, for this project you should use IPV4 exclusively, don’t use IPV6 addressing.
Now it’s time to get down to the tasks:
Task 1: Network Scanning (10 points)
Find the IP address of the vulnerable Docker container on the NAT network using nmap or zenmap (the GUI version of nmap). You’ll find both installed in the VM, ignore any GTK errors if you run zenmap from the command line.
Remember to limit your scans to the 172.22.0.0/24 network and nodes on that network only! Don’t scan outside the Docker network!
IMPORTANT: For people who are logging into the VM using ssh to do their work, we have forwarded ports from the Docker container to the VM so you can complete the port forwarding in VirtualBox on your host.
You will see ports exposed on 172.22.0.1, the VM. These simply reflect the ports on the actual Docker container, so you can ignore ports on this address when answering questions in the assignment_questionnaire.txt.
NOTE: You have zenmap on the GUI menu to use, it’s more intuitive to use than the command line version. It will complain that it’s not run as root, that’s OK.
Use an Intense scan in zenmap to identify all the open ports on the Docker container’s webserver and submit the port numbers which handle http traffic to the Apache web server and the Python web server on the VM. You can determine the server type in zenmap, and with nmap on the command line with the correct options.
While zenmap scans all ports, nmap by default only scans the top 1000 ports, to scan EVERY port from 1-10000, you need to specify -p 1-10000 in the nmap command. All the ports you’re looking for are lower than port 10000.
One suggested workflow for zenmap is to do a “quick scan” of the 172.22.0.0/24 network to identify nodes on the network. Then inspect interesting nodes more closely with further, more intense scans.
If you are scanning and not finding web server ports, did you remember to run ./StartShockServer.sh in your home directory?
Submit in assignment_questionnaire.txt:
• The IP address of the vulnerable container in the Docker network. (3 pts.)
• The HTTP port number of the container’s Apache2 webserver. (4 pts.)
• The HTTP port number of the container’s Python webserver. (3 pts.)
Task 2: Exploit the Shellshock Vulnerability (20 points)
In this task, you will launch the Shellshock attack on a remote web server. Many web servers enable Common Gateway Interface (CGI), which is an older method used to generate dynamic content on Web pages and Web applications.
Many CGI programs are written using a shell script. Therefore, before a CGI program is executed, the shell program will be invoked first. This can be triggered by a user from a remote computer, typically using the curl command. To access this CGI program on the Docker container from the VM browser or command line, you need to first make sure you started the Docker container using:
./StartShockServer.sh.
Then, you can either use a browser by typing the following URL:
http://<IP address found in part 1>:<http port found in part 1>/cgi-bin/shellshock.cgi
or use the following command line program curl to do the same thing:
$ curl http:// <IP address found in part 1>:<http port found in part 1>/cgi-bin/shellshock.cgi
For this task, your goal is to launch the attack through this URL with the proper parameters, such that you can achieve something that you cannot do as a normal remote user. You will get a shell directly on the container, without using ssh to login or even knowing a password! For example, once you have a shell, you can directly execute a file on the container or look up information about files located on the container.
When you successfully launch an attack, please execute the /bin/task2 program (which needs your GT username as the input) inside the VM. It will generate the submission hash for you.
For students that want to verify their work, here’s an example correct input/output for running /usr/bin/task2:
$ /usr/bin/task2 gburdell3
Here is your task2 hash:
5732307cf1ef49dd2613e9bbe28dd3e0ea907c28d6c8736faf0c9537c2b 20c5a
Submit in assignment_questionnaire.txt:
• The command (with any parameters) you used to exploit the container.
• The hash from running /bin/task2.
While you’re in a shell and able to inspect the file system, look around /usr/bin for files that start with “task.” Run a ls -l on /usr/bin/ and get familiar with the variety of programs found there. One of them is important for Task 4!
NOTE: Keep your shell open for part of Task 3, you need to search the filesystem for two files needed for Task 3.
Task 3: Brute Force with Metasploit (25 points)

Now that you have established a foothold on the server through Shellshock, you've discovered that the /usr/bin/task3 executable is owned by a different user account that has enhanced privileges. To execute this file and complete the challenge, you'll need to gain access to that user's account.
During a penetration test, weak credentials remain one of the most common vulnerabilities found in systems. Attackers often exploit this by attempting to authenticate using common username and password combinations. That's where Metasploit's brute force capabilities come in.
Metasploit includes powerful auxiliary modules for password attacks, along with extensive wordlists of commonly used usernames and passwords. For this project, we're going to use Metasploit's SSH brute force module to identify weak credentials on the Docker container. This will demonstrate how penetration testers systematically identify accounts with poor password hygiene.
Metasploit works by automating login attempts against the SSH service, trying different username and password combinations from predefined wordlists. This is a critical skill for penetration testers, as password spraying and credential stuffing attacks are frequently used in real-world scenarios.
This approach teaches students about:
- The importance of strong password policies
- How automated tools can exploit weak credentials
- The built-in wordlists available in security testing frameworks
- Real-world attack patterns used by threat actors
Introduction to Metasploit

1. Begin by opening a new terminal on your VM. In the new terminal type:
msfconsole
After a moment, the Metasploit Framework console (msfconsole) will load. For this project, msfconsole is the main way of accessing Metasploit. While there are other tools and command prompts associated with Metasploit, msfconsole is suitable for the related tasks of this project.


Figure 2 - Metasploit opening screen

Wait a minute for the msf6 > prompt before entering commands.

2. For this example, we’re going to scan the ports of a host. You can use the results from task 1 to ensure Metasploit is behaving properly. In practice using a Metasploit module solely for the purpose of scanning ports on a host is a little overcomplicated, since nmap can do much more and takes less setup, but this does offer a good introduction to using a Metasploit module.

3. A Metasploit module is the base of any task performed in Metasploit. It consists of Ruby code that is written to perform a certain task (like exploiting a certain vulnerability or scanning a certain kind of system). There are multiple different varieties of modules, but for our purposes we’ll focus on three of them:

a The Exploit modules: These are modules written to exploit a certain vulnerability.
b The Auxiliary modules: These are modules written to perform some tasks related to exploiting a system (like scanning). Within the auxiliary modules there are many kinds of modules. We’ll be using the “scanner” modules for this example.
c Payloads: Calling these modules is a little misleading. They are the payloads (for example the shellcode) that are sent within the exploit.

4. First, we must find the correct module. We know it’s scanning the system, so let’s start by searching for “scanner” using the command
(in msfconsole):

search scanner

5. Hmm… that’s quite a few results (752 at the time of writing this).


Figure 3 - Shows 752 results for search scanner command

The reason there are so many results is that “scanner” is a class of
auxiliary modules (as seen by there being so many modules beginning with “auxiliary/scanner”). So, searching for “scanner” (or “scan”) will give everything at all related to network or vulnerability scanning.

6. So, we need to narrow our search. One way of doing this is with the “grep” command, which filters the output. (grep is also the commonly-used “find/search” command in Linux when you are searching inside files.) Since we’re looking to scan the ports, let’s try the following command to search for “portscan” within the search results from “scanner”.

grep portscan search scanner


Figure 4 - Narrowed down results for grep portscan search scanner command

That seems a little better. Only 7 results. Since we’re scanning for open tcp ports, let’s use: “auxiliary/scanner/portscan/tcp”. To use this metasploit module, you should run the command:

use auxiliary/scanner/portscan/tcp
You will get this response:

Figure 5 - Shows the new prompt with scanner/portscan/tcp
You now see “auxiliary(scanner/portscan/tcp)” after the prompt, indicating you are using the auxiliary(scanner/portscan/tcp) module.
7. Now that we’re using the correct module, we must set the correct options. Try running the command options. You should see something like this on the next page:


Figure 6 - Viewing options such as RHOSTS

While each of the options is marked as required, most of the prefilled values work for our purposes. The only one we need to change is RHOSTS. RHOSTS should be the IP address of the host we want to scan. In this case, you should set it to the IP address of the Docker container, that you found in part 1. You can use the command:

set rhosts insert_IP_of_host

Now try running options again and ensure the RHOSTS option is set to the correct IP address for the Docker container.

8. Now use the run command and you should see the same list of open ports that nmap showed. (While “run” is usually used to run auxiliary exploits, the command “check” and “exploit” are often used to check and run exploit modules.)

run

Now you’ve seen an example of how to use Metasploit. You’ll follow a similar process when exploiting the vulnerability to run /bin/task3.

Make note of the ssh server port found, if you didn’t note it during Task 1.

Task 3 Assignment:

1. Research the available Metasploit commands to learn how to brute force a ssh login attack. Remember if there are too many search results you can use Metasploit’s grep command to narrow down results, as you did earlier in the Task 3 practice section above.
2. When narrowing down the search properly there are only fourteen results to inspect (as of Summer 25). It should be obvious which one to use, if you are unsure try out different attacks! Experiment!
3. The attack will use files called unix_users.txt and unix_passwords.txt, these files are on the VM, not on the container.
4. You need to use a Linux command to find these files on the VM so you get the full path to the files – research the Linux find command and understand how to specify the search location and set other parameters for your search.
5. Because grep -v is apparently not working on the VM, if you search the / (root) directory you will get too many results saying “Permission denied.” Narrow your search down to /opt, Metasploit is installed under there.
6. Once you have the full path to the files, research the available Metasploit commands to figure out how to use those files in your brute force attack.
7. Find an option to stop the search when a successful login is made, or the process will continue past the login. Set this option as desired.
8. Set the ssh port to scan to the port you found earlier in the Task 3 Introduction to Metasploit section.
9. Run the brute force ssh attack once all options are set.
10. Once the attack is finished you should see something like this:

11. Use the sessions -i 1 command to enter your running session (use the session number you obtained in Step 10, run the sessions command to see all active sessions.

Normally you would allow some amount of time waiting for the ssh attack to complete, as the attack will try every combination of usernames and passwords in the username and password files.

For convenience we have set up these files to finish very quickly, you won’t have to wait long to get in.

NOTE: You should keep the reverse shell running after finishing Task 3, as you will need it in Task 4.

Submit:
• Exploit module name
• Hash from /bin/task3
Task 4: Privilege Escalation (20 points)

Your goal in Task 4 is to upgrade the privilege for your command shell by exploiting a setUID vulnerability. You will run /bin/task4 with a higher effective user id (euid), not the default user “www-data”. To be clear, you will still see the www-data user and group, but when you run the id command, you will also see an “euid” (effective user id) of 0.

You will learn about various commands in Linux and find one that lets you escalate your privileges.
Assignments:

NOTE: Remember to keep the shell open from the previous task, or recreate the steps needed to get the shell in Metasploit.

As a first step, type id in your shell. You should see system_admin which is your user ID. Now, run /usr/bin/task4 gt_username. You will see a permission denied error. That is because /usr/bin/task4 is configured to allow only a privileged user to run it. Thus, you need to find a way to run /bin/task4 as a privileged user. A feasible approach is to spawn a shell running as the “root” user and run task4 through it.

Useful Resource: https://gtfobins.github.io/

1. What is the vulnerable program?
2. What command do you use to spawn a shell with the vulnerable program?
3. And what is the hash value from running /bin/task4 your_gt_username?

Please leave your answers in assignment_questionnaire.txt.

NOTE: Keep your Task 4 root shell open for Task 5.
Task 5: Password Cracking (25 points)
Background on Using John the Ripper
Remember you have learned about the Linux find command. On the container, there are two password-protected files. task51.zip is password-protected with zip, while task52.gpg is encrypted with gpg, a common file encryption tool in
Linux. GPG is the open-source version of PGP – Symantec owns PGP. It is typically licensed for a fee.
We already know the developers of this web server are not very security savvy, since they let a shellshock vulnerability plus a setUID exploit give a high privilege shell on their machine. So, chances are they did not pick very secure passwords for these secret files. Your goal in this task is to crack the passwords of these two files using John the Ripper (a popular password cracker) and cewl (a password scraper).
Task 5.0 Demonstration of John the Ripper – Not For Credit
1. Create a simple password hash file:
echo 'myuser:$1$salty$yYc40qf3j5dc2QNtidPP8/' > hello.hash
That hash is:
Username: myuser
Password: password12
Format: MD5-Crypt (--format=md5crypt)
2. Use John to crack it with a wordlist, this command is one line:
john --format=md5crypt -wordlist=/home/penteststudent/rockyou.txt hello.hash There’s no space between -- and wordlist. You will see this output:
Cracked 1 password hash
3. View the cracked password:
john --show hello.hash
The output is:
myuser:password123
Overview
In this task, you will analyze two password-protected files suspected of containing sensitive content:
task51.zip task52.gpg
These files have been encrypted using weak or guessable passwords. Your job is to recover these passwords using password cracking techniques and tools.
To prepare for these tasks, you need to download the files from the Docker container to your VM so you can work on them with John the Ripper tools.
Remember you are using your login from Tasks 3 and 4, this is a Metasploit shell.
• Remember you know how to use the find command.
• Research Metasploit, learn how to download files using a command.
• Download the files to your virtual machine file system.
Once you download the files from the Docker container, be sure to switch to a VM Terminal where you’re not logged into the container anymore. You do the rest of Task 5 on your VM, not in the Docker environment.
You’ll work with:
• John the Ripper: a fast and customizable password cracking tool.
• zip2john and gpg2john: utilities that convert encrypted files into hash formats John can understand.
• cewl: a custom wordlist generator that scrapes words from a webpage.

This task reinforces your ability to:
• Extract password hashes.
• Use wordlists and brute-force strategies.
• Investigate contextual clues to guide password generation.
Part 1: Cracking task51.zip
1. Ensure you're in the same directory as task51.zip and task52.gpg.
2. Use zip2john to extract the hash from task51.zip.
Hint: This will produce a hash line John can use as input.
3. Run John the Ripper on the hash. Start with incremental mode.
Hint: Try using --incremental to perform a brute-force attack.
4. Use the show feature of john to show the password you cracked.
5. Once you've cracked the password, decrypt the ZIP file.
Hint: Use the unzip command and supply the recovered password.
6. Inside the ZIP file is an executable file. Run it with:
./task51.pyc your_gt_username
Record the output hash in your assignment questionnaire.
Part 2: Cracking task52.gpg
1. Use gpg2john to convert task52.gpg into a John-compatible hash. Start with an incremental brute-force attack.
Hint: Pay attention to how long this process takes and whether it seems productive.
2. If the incremental method takes too long or fails, consider a more intelligent approach.
Ask yourself:
• Have the developers shown any patterns of weak security elsewhere?
• Could clues about the password be hidden in related web content?

4. Use cewl to generate a wordlist from this webpage.
5. Use the generated wordlist with John the Ripper to process your task52.hash.
Hint: Use the --wordlist option and allow default --rules to permute the words.
6. Use the john command to show the cracked password for task52.hash
7. Once cracked, decrypt the GPG file using the password you found. Because Docker can’t do this interactively, you’ll need to use this command with the password as an argument:
gpg --batch --yes --passphrase 'your_cracked_password' -output task52 --decrypt task52.gpg
This command is one line, substitute your cracked password.
8. Run the decrypted script:
./task52 your_gt_username
Record the resulting hash in your assignment questionnaire.
What to Submit
In your assignment_questionnaire.txt, include:
• The commands you used to run John the Ripper (required).
• The command you used to run cewl (required).
• The final password for each file (required).
• The output of each Python script after entering your GT username (required).

Extra Task 6 – Optional, Not for Credit
We have a new task you can help us test. If you are enjoying attacking the Docker container so far, then you can continue the fun with this task. We would appreciate any feedback on this task for when we incorporate it into the project for future semesters.
We’re not 100% sure we have the HTTP Smuggling vulnerability set up correctly, but you can spend some time researching the weakness. We are running vulnerable Apache2 version 2.4.32.
UPDATE: Hold off working on this unless you want to hack at it, based on student input I don’t think I have a vulnerable version of the Apache2 server on it. I will produce a new VM with the correct server version soon, thanks for your patience.
Task 6 Bypass Authentication with HTTP Request Smuggling
In this project Apache not only serves up a site directly, it’s also a reverse proxy for a Python web server. The Python back-end server is configured with these routes:
• / -- the root of the server is a simple content page that says “Welcome to the Back-end Server”
• /protected – a page that you must be authenticated to view, this is the goal, when you get to see this page, you’ll get your flag there.
HTTP Request Smuggling is a critical web security vulnerability that occurs when front-end and back-end servers interpret HTTP requests differently. This can allow attackers to bypass security controls and access protected resources.
The Python webserver has a protected administrative area at /protected that requires authentication. Your goal is to bypass this authentication and access the protected resource to retrieve your personalized flag.
What You Know
• The server is running a vulnerable version of Apache2 as a reverse proxy.
• There's a protected area at /protected that you cannot access without credentials.
• The server has a vulnerability related to how it processes HTTP headers.
• You'll need to include your GT login to get a personalized flag.
Hints
• The vulnerability involves differences in how Content-Length and Transfer-Encoding headers are interpreted.
• The proxy forwards requests from /backend/ to the backend server.
• You'll need to "smuggle" a request past Apache's authentication.
• Include the header X-GT-Login: jsmith3 to get your personalized flag.
Getting Started
1. First, try to access the protected area directly:
2. curl http://172.22.0.10:8088/admin/
3. Notice that it requires authentication that you don't have.
4. Try accessing the backend directly through the proxy: curl http://172.22.0.10:8088/backend/
5. Also try curl http://172.22.0.10:8088/backend/protected and see what happens.
6. Research how HTTP Request Smuggling works and how to exploit the difference between how Apache and the backend server request parsing.
Deliverables:

Submit to Gradescope:
- assignment_questionnaire.txt (completed)
- README.txt explaining your attack methods

Important:
- Follow the template exactly. - Do NOT ZIP your files.
That’s it, you’re done with Project 1!
Reminders:
- Only attack the container (172.22.0.10), not the VM itself.
- Keep detailed records of all commands used, so you Don’t Repeat Yourself. - Restart the container, if necessary, by running ./StopShockServer.sh and ./StartShockServer.sh in your home directory on the VM.
- Be patient when loading Metasploit.
Acknowledgments:
Appendix 1 – Resources / Links
Here are some resources for the various concepts and tools presented in the project:
nmap - https://nmap.org/book/man.html#man-description zenmap - https://nmap.org/zenmap/

Task 3 – MetaSploit https://docs.rapid7.com/metasploit/bruteforce-attacks/ https://www.offsec.com/metasploit-unleashed/scanner-ssh-auxiliary-modules/
Task 4 – Root Privilege Escalation Getting a root shell –
General links:
Shellshock - https://en.wikipedia.org/wiki/Shellshock_(software_bug)
Metasploit - https://www.offensive-security.com/metasploit-unleashed/
John the Ripper - https://www.openwall.com/john/doc/
CeWL - https://tools.kali.org/password-attacks/cewl
Webserver Marketshare -
https://w3techs.com/technologies/overview/web_server

Appendix 2 - Running the VM on an ARM-based Mac

VM Download link: Will be posted on Canvas on the Machine Learning project when we release it.

Emulation on ARM-based Macs doesn’t always work, it can be very slow. You should use ssh to access the VM using your hosts tools like Terminal, curl and your browser if needed.


Note: None of the material below is necessary for running in VirtualBox on an Intel-based machine, but you can run the VM headless using the same SSH instructions as below:

Emulating x86/x64 on Apple MX Chipset
While it is possible to use emulation to run the CS6262 VMs it is important to note that it is not officially supported.

You will need to be familiar with SSH and using the terminal as the Linux GUI is not very responsive. You will find it difficult to impossible to finish the project using the VM GUI.

Disclaimers

Requirements
1. A copy of the class VM in .ova format.
2. An ARM-based Mac.
3. Install QEMU and UTM on your Mac:
Homebrew -- https://www.qemu.org/download/#macos UTM -- https://mac.getutm.app or other any other emulation tool
4. You need at least 50GB of drive space available, plus free space desired after installation.
Obtaining the Virtual Disk Image from the OVA

1. Open a terminal
2. Download the class VM
3. Extract the VM disk image from the OVA archive (look for the .vmdk file): tar -xvf CS6262Project1-R01.ova

This will result in this file being created:
CS6262Project1VM-disk002.vmdk

4. Convert the disk image to qcow2 format
qemu-img convert -O qcow2 CS6262Project1VM-disk002.vmdk CS6262Project1VM-disk002.qcow2

Creating the Emulated Virtual Machine
Note these instructions assume that you are using UTM. The instructions will differ if you are not using UTM.

1. Open the UTM application
2. Click on the 'Create a new Virtual Machine' button
3. Click on the 'Emulate' button
4. Click on the 'Other' button
5. For 'Boot Device' select 'None'
6. Click on the 'Continue' button
6. For 'Architecture' ensure that 'x86_64' is selected
7. For 'System' you can use the default value of 'Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-7.2)(q35)
8. Set the 'Memory' to ~50% of your total Mac RAM (We recommend 4096MB or more)
9. For Storage you can use the default of '64 GB' - we will be deleting this drive
10. You do not need to set a shared directory - click 'Continue'
11. Set the VM name (CS6262Project1 for example)
12. Click the 'Open VM Settings' checkbox
13. Click the 'Save' button

Configuring the Emulated Virtual Machine
The VM settings window should have opened once you saved the VM. Now you'll need to configure the VM to use your .qcow2 image to boot the course VM.

1. Select the 'QEMU' menu item on the left
2. Disable (unselect) the 'UEFI Boot' option
3. Select the 'Display' menu item on the left
4. Set the 'Emulated Display Card' to 'virtio-gpu-gl-pci (GPU Supported)'
5. Select the 'IDE Drive' from the left hand menu
6. Click the 'Delete' button
7. A prompt will appear asking you to confirm the action - click the 'Delete' button
8. Select 'New...' under the 'Drives' section in the lefthand menu
9. A prompt will open - click the 'Import...' button
10. Find your drive image that ends with ‘.qcow2' for this example
11. Click the 'Save' button in the bottom right of the Settings view

Completing Course Projects via SSH
Given the fact that emulating the Linux UI typically results in poor user experience, the expectation is that you would use SSH to complete all project activities. If you are unable to use SSH to perform a specific task then you're unlikely to be able to complete the project using an emulated VM.
Obtaining the VM's IP address
1. Power on the VM
2. Login to the VM as any user
4. Open the 'Terminal' application
5. Query all network interfaces: `ip a`
6. Find the entry for the VM's network interface card:
Note that it is likely the second interface, denoted by `2:`
The default subnet for UTM is typically `192.168.64.0/24`
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether ee:50:4e:d3:b0:d1 brd ff:ff:ff:ff:ff:ff inet 192.168.64.12/24 brd 192.168.64.255 scope global dynamic noprefixroute enp0s1


Completing Project 1 over SSH
Ensure that you have Chrome installed on your Mac.
Connect to the VM via ssh:
ssh penteststudent@192.168.64.12


If you want to view the project website, then you need port forwarding. You can possibly set this up in UTM/QEMU, the author isn’t sure. You can also use SSH tunneling to forward the vulnerable website to view from your host:

Ssh -L ssh -L 127.0.0.1:9999:127.0.0.1:9999 penteststudent@192.168.64.12
(note the port 9999 is just an example, use the port you discover with nmap / zenmap)

We hope you have been able to work your way through these instructions, please let us know of any suggested changed on Ed Discussion.
Appendix 3 - VirtualBox Networking
NAT Networking
If you look at the networking settings in VirtualBox, you’ll see various network styles available. We will look at two of those here: NAT and Bridged.

Figure 7 - Network Types in VirtualBox
In VirtualBox NAT Networking, the VM accesses the Internet through a softwarebased router created by VirtualBox. This is the simplest and default method of networking in VirtualBox. The VM has Internet access, but you typically can’t access the VM from your host. The IP address for the VM will be in the range
10.0.2.0/24.
This networking style is fine if you plan to do all your work in the VirtualBox VM’s GUI. You will be able to work in a shell in the VM and will have full network access from within the VM to the Docker container running in the VM. From the VM you’ll also be able to access the Internet.
This is the safest networking style in VirtualBox, as the VM is not accessible from the network.
Bridged Networking
For those who want to be able to ssh into the VM from their host machine, you’ll want to choose Bridged networking in the VM. This promotes the VM to be a full member of your network. This means instead of a 10.0.2.0/24 address, your VM will get an address on your home network. We do not recommend Bridged Networking if you are in a work environment or otherwise exter.
Once you switch to Bridged networking, you should see the IP address of the VM change to be an address on your network, which is typically in the range 192.168.1.0/24 on a home router.
Restarting VM Networking
We have seen behavior in VirtualBox that when you switch between NAT and Bridged networking, the IP address of the VM will not update. In this case, please run the following command in the pentestuser’s home directory:
./RestartNetworking.sh
This runs the following commands:
ip link set enp0s3 down ip link set enp0s3 up
You can’t normally run these commands as penteststudent, so use the provided script to update your networking on the VM.
Forwarding Ports to Your Host
We might be giving away the game a bit here but it’s OK. As we have noted, the Docker network is on 172.22.0.0/24. It’s easy enough to run ip a and discover the VM’s IP address is 172.22.0.1. As noted previously, you will see the Docker container’s ports duplicated on the VM. This is to make them available for port forwarding to your host if you desire to work from your host.
To set up port forwarding, open the VM’s Network settings. You can change network settings while the VM is running.

Figure 8 - Choose the Network Option
This only works if you’re in NAT networking: you will see a port forwarding button in the VM’s Networking settings:

Click this button and you’ll see the Port Forwarding Rules dialog appear:

Click the + icon to create a new rule, under Host Port enter the port you want to use on your host, and under Guest port enter the port numbers the VM’s Docker container is using.

If you’re already running something on Port 22, for example you run Windows Subsystem for Linux (WSL), then use a different port on the host side. The VM’s ssh is setup on port 22.
This will make the designated ports available on your host’s localhost interface.
You can then run a command like this to ssh into the vm, per the settings above:
ssh penteststudent@localhost
You can also access the Docker container’s published ports from localhost. Let’s say you found the Apache 2 server on the container on port 9999. Then you could use this curl command from your host to access the webpage with curl or a browser:
curl http://localhost:9999
Appendix 4 – VM Troubleshooting


In this example we are using a Bridged network, regardless of whether you use NAT or Bridged, to fix this problem choose your eth0 interface in the Network Settings:

If you can select the adapter type (if it’s not greyed out like here) try different adapters starting with the Intel desktop adapters:

Closing
Thanks for going through the project. We hope you see by now, while this is a long document, most of it is introductory and background information. We would appreciate any feedback, positive or negative, about out choice to include so much extra information about Docker, Networks and VMs in this document. Did you find it helpful? Was the size of the document so large that it initially discouraged you? Thanks for any feedback, please use the Document Feedback post on Ed to make your comments.
Thank You