[SOLVED] Cs6262: network security project 1 summer 2025

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

 

 

Summer 2025

Security Warning

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!

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.

On September 24, 2014, a severe vulnerability in Bash, nicknamed Shellshock, was identified. This vulnerability could exploit many systems at the time. In this project, you will gain a better understanding of the Shellshock vulnerability by exploiting it to attack a machine. The objective of this project is to get first-hand experience on this interesting attack, understand how it works, and think about the lessons that we can get out of this attack.

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.

In this project, you will:

 

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.

We expect some people to run the VM on older CPUs. There’s no hard line of what the minimum specification is, these are guidelines, your experience may vary:

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.

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.

Instead, if you are logged in from your host, you have to consider what networking style you are using in Virtual Box (or your choice of virtualization software. You may need to use Bridged networking, see Appendix 3.

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.

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.

Here we repeat our warning to only use nmap or zenmap on the Docker network!

 

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:

 

Steps:

./StartShockServer.sh

Note: Once you start the Docker container, it will restart itself if it dies, unless you run the ./StopShockServer.sh script.  

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:

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:

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).

enp0s3 — this is the VM interface with your host. If you are trying to ssh into your VM from your host computer, you use this address. You may need Bridged networking for this, see Appendix 2. For Ubuntu24.04, enp0s3 always seems to be the name chosen for the first interface, instead of the traditional eth0.

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:

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:

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:

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: 

Submit in assignment_questionnaire.txt:

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.

 

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:

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.

 

It may take a little time for Metasploit to load, you are ready when you see the msf6 prompt at the bottom:

 

Figure 2 – Metasploit opening screen

The text-art image will likely be different. You can ignore the warning about Metasploit being more than two weeks old.

 

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

 

 

 

 

(in msfconsole):

 

 

 

 

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.

 

 

 

 

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:

 

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.

 

 

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:

 

 

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

 

 

 

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:

 

 

 

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:

 

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/

 

You may want to look at the output of ls -l /usr/bin for a program which has a higher privilege than the default user and run /bin/task4 gt_username in the shell spawned. Also look at the commands featured on the link above.

 

Please leave your answers in assignment_questionnaire.txt.

 

NOTE: Keep your Task 4 root shell open for Task 5.

A valuable part of any penetration test is password cracking. While there may be no known vulnerabilities in a system, a weak password could be just as damaging in allowing an attacker to gain access to a system or view sensitive information once they gain access. We’re going to look at two kinds of weak passwords in this task: passwords that are too short, and passwords that can easily be guessed via password scraping.

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).

That hash is:

Username: myuser

Password: password12

Format: MD5-Crypt (–format=md5crypt)

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

john –show hello.hash

The output is:

In this task, you will analyze two password-protected files suspected of containing sensitive content:

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.

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:

 

This task reinforces your ability to:

Hint: This will produce a hash line John can use as input.

Hint: Try using –incremental to perform a brute-force attack.

Hint: Use the unzip command and supply the recovered password.

Record the output hash in your assignment questionnaire.

Hint: Pay attention to how long this process takes and whether it seems productive.

Ask yourself:

 

Hint: You may need to configure cewl to follow links to profile pages.

Hint: Use the –wordlist option and allow default –rules to permute the words.

This command is one line, substitute your cracked password.

Record the resulting hash in your assignment questionnaire.

In your assignment_questionnaire.txt, include:

 

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.

In late 2024 a new Common Vulnerability and Exposure (CVE 2024-40725) came out for the Apache2 web server. The Apache2 server sees widespread use – as of summer, 2025, Apache reportedly had a 15-20% share of the server market. Nginx was the leader, Apache second, Cloudfare Server third and Lightspeed server fourth. Often these different servers are used in combination, with nginx acting as a front end (reverse proxy) for back-end servers that run on Apache2.

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:

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.

 

Submit to Gradescope:

 

Important:

That’s it, you’re done with Project 1!

This project is adapted from SEED Labs by Wenliang Du, licensed under GNU Free Documentation License, Version 1.2.

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 –

https://gtfobins.github.io/ (compare this list to the output of ls -l /usr/bin on the Docker container, once you already have a regular shell. Searching inside the Docker container with find /usr/bin -perm 4000 doesn’t work as it should, we’re not sure why it doesn’t.) Task 6 – HTTP Request Smuggling –  https://portswigger.net/web-security/request-smuggling https://www.imperva.com/learn/application-security/http-request-smuggling/ https://nvd.nist.gov/vuln/detail/cve-2024-40725  https://httpd.apache.org/security/vulnerabilities_24.html

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

 

 

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.

 

Credit where credit is due, TA Eric Johnson wrote these instructions and we modified them for CS 6262 students for Project 1. We decided to provide some details below on how to configure emulation, but these instructions come without any warranty – we cannot grant extensions due to emulation issues. SHA256:

 

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:

 

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.

 

Please understand the teaching assistants (TAs) can provide only very limited support on emulation. You will NOT receive extensions due to technical difficulties with the VM. Using emulation to complete the homework for the class is done at your own risk.

 

Homebrew — https://www.qemu.org/download/#macos UTM — https://mac.getutm.app or other any other emulation tool

For the purposes of this tutorial we will use the CS6262Project1-R01.ova name as the VM filename, be sure to adjust the instructions for your VM image name. Note that these instructions were created using a Linux VM and the exact commands may vary slightly on MacOS.

 

 

This will result in this file being created:

CS6262Project1VM-disk002.vmdk

 

qemu-img convert -O qcow2 CS6262Project1VM-disk002.vmdk CS6262Project1VM-disk002.qcow2

 

Note these instructions assume that you are using UTM. The instructions will differ if you are not using UTM.

 

 

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.

 

 

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.

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

 

In this example: We will assume that the IP address for the course VM is 192.168.64.12 for the purposes of this example. Your IP address may vary. Please use the address identified above to complete each SSH command.

 

Ensure that you have Chrome installed on your Mac.

Connect to the VM via ssh:

ssh [email protected]

 

This will get you a bash session running on the VM, presented in your host interface. For portions of the project that can be done from the command line (all of it), use this window. You may want to open a second windows for certain types of attacks, though it isn’t required or necessary.

 

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 [email protected]

(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.

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.

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.

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:

You can’t normally run these commands as penteststudent, so use the provided script to update your networking on the VM.

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:

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

 

This VM was produced on a Windows machine. If you are on an Intel-based Mac, you may see an error like this when starting the VM:

 

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:

 

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