Vulnerabilities

Lecture Notes

This lecture will present an overview over vulnerability management processes and tools, CVEs, CWEs and the CVSS.

Download here or here with additional generated notes.

Note: Notes are genereated by AI and edited by staff as way of providing additional comments. If you find issues, please report them.

Practical tasks: building your lab

The vulnerabilities tracked in CVEs may originate from a wide range of sources, and have an wide impact on computer systems, processes and the society. Other vulnerabilities are never tracked as CVEs and are handled in alternative ways, not ever disclosed to the public and traded, or just ignored.

This session has two parts. First you build the environment you will use for the rest of the course, which takes around two hours, most of it waiting for downloads. Then you use it on a short ladder of four vulnerable applications, from one HTTP request to a flaw that will not fall in a single sitting.

The rules of engagement apply here without exception, and in particular when running environments that are vulnerable by design.

Part 1. One virtual machine, one lab

Virtual machines are a vital tool for security research: they provide an isolated environment to run specialised tools, reducing the danger of compromising the host system. One of the most popular distributions for this purpose is Kali Linux, which we will require during this course.

1. Check what your laptop can run.

If VirtualBox refuses to start a 64-bit machine, virtualisation is disabled in the firmware: enable VT-x or AMD-V.

2. Get the system. Either download it, or use one of the pre-loaded USB drives that staff carry, described at the end of this page.

3. Create the virtual machine. At least 4 GB of RAM (8 if your own machine allows it) and 40 GB of disk, dynamically allocated. Take a snapshot once the system is installed and updated, and take one before every vulnerable environment, named after the CVE you are about to run. Restoring a snapshot is faster than rebuilding an environment, and it keeps anything you break inside the VM.

4. Install the container engine. This course uses Podman rather than Docker: it has the same command surface, it has no daemon to keep alive, and it runs rootless by default, which is exactly what you want when the containers you pull are deliberately broken.

sudo apt update && sudo apt install -y podman podman-compose
podman run --rm docker.io/library/alpine:3.20 echo "podman works"

If podman-compose is not offered by apt, install it with pipx install podman-compose. If your image still ships a http:// mirror, switch it to https://, in /etc/apt/sources.list or in the files under /etc/apt/sources.list.d/ depending on the image. Two things worth knowing: podman machine only exists on Windows and macOS hosts and you do not need it inside your Linux VM; and anonymous pulls from Docker Hub are rate limited per IP address, which on a shared campus connection can produce “too many requests” errors. Those two options make Podman comfortable for the tools that expect Docker, if you ever need them:

echo 'alias docker=podman' >> ~/.bashrc
systemctl --user enable --now podman.socket
export DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock

5. Understand how the pieces reach each other. The VM is a separate machine. localhost inside it is the VM, and localhost on your laptop is your laptop. To reach a container from your laptop’s browser you need an address for the VM, which you get with hostname -I inside it.

Publish container ports only on the VM, keep the VM itself off bridged networking, and shut environments down when you are done with them. podman ps lists the published ports; curl -I http://<vm-address>:<port> from your laptop confirms you can reach it.

6. Capture the traffic. This is the habit the rest of the course grades. On the VM, sudo tcpdump -i any -w 01-lab.pcap sees traffic in both directions between your tools and the container, including the internal bridge; Wireshark opens the file. For HTTP and HTTPS, point the browser in the VM at Burp or ZAP listening on 0.0.0.0:8080, and import the proxy’s certificate authority into the browser if you want to read TLS.

Name the artefacts so they are still legible a month later: 02-cve-2021-41773.pcap, -request.txt, -response.txt, and one line of caption saying what the interesting part of it is. The midterm writeups and the research project are graded on exactly this.

Definition of done

You are set up when all of the following hold, and you can paste the output of the block below into the course channel if you are unsure:

podman --version
podman run --rm docker.io/library/alpine:3.20 echo "podman works"
python3 -c 'import requests' && echo "requests ok"
hostname -I

• a vulnerable application from the ladder below is running and you reached it from a browser
• you captured at least one of its conversations in tcpdump or Burp
• you tore the environment down again and the disk did not fill up

Part 2. Four environments, from one request to a bad evening

The vulnerabilities tracked in CVEs come in every shape. Vulhub provides containerised deployments of real ones, one directory per environment. Inside an environment directory, podman compose up -d starts it and podman compose down -v removes it; podman system prune -a reclaims the disk between sessions. Directory names move around in that repository, so search the repository for the CVE identifier if a path does not resolve.

Work through these in order. They are chosen for the shape of the reasoning they ask for, not for their score.

1. httpd/CVE-2021-41773, Apache HTTP Server 2.4.50 path traversal. Very easy, and deliberately so: one carefully built request reads a file outside the document root, and a second achieves remote code execution on the same build. Do it with curl first and through a proxy second. Then read what the fix changed and say, in your own words, why it works.
2. tomcat/CVE-2017-12615, Tomcat file upload through the PUT method. Easy, and it teaches a different lesson: nothing about the request is exotic, the flaw is that the server accepts a method it should not. Upload a page, then make the server run it. Answer one question: which configuration default is enabling this, and what would a hardened installation have instead?
3. spring/CVE-2017-4995, Spring Cloud Config Server. More demanding: several moving parts, an endpoint that is meant to be internal, and a payload that is interpreted rather than merely executed. You cannot brute force your way through it; you have to understand what the application is for.
4. shiro/CVE-2016-4437, Apache Shiro remember-me deserialisation. The demanding one, and you are not expected to finish it in one session. A cookie is encrypted with a key that the library ships badly, and the path through it requires you to understand the class of bug rather than to find a magic string. If you want an alternative of the same weight, struts2/S2-048 fills the same slot.

For each environment, record in one page: the CVE, the affected component and version, the port you reached it on, the exact command or request that worked, one annotated capture, and the impact you actually reached. That page is your first lab journal entry, and the journal is what you will be asked for later in the course.

These environments are years old, and Assignment 1 asks for a CVE published in the last year: their value here is the exposure and the tooling, not the target itself.

This will be a great opportunity to test your new Kali environment, and to bootstrap our first assignment.

When something does not work

Pre-loaded USB drive

If downloading a distribution is a problem, staff carry the image on a pen. What you need to reproduce it, or what to ask for:

• The Kali Linux Live image, named like kali-linux-<version>-live-amd64.iso, which boots on real hardware and runs without installing anything to the disk. A matching -live-arm64.iso exists for Apple silicon machines.
• A pen of 16 GB or more, so that your work survives a reboot: the live image includes a helper to create the persistent area, and it is worth setting up before the pen leaves the staff machine.
• Written with BalenaEtcher, Rufus or dd, after checking the SHA256 published alongside the download.
• Booting a laptop from a pen may require Secure Boot to be disabled, and may be blocked by a firmware password. If that is your machine, arrange a lab slot instead of fighting it.
• Note that the container images for the ladder still need the network once, so plan one session with connectivity after booting from the pen.

An alternative for the VirtualBox route is the pre-built Kali image for VirtualBox, named like kali-linux-<version>-virtualbox-amd64.7z, which skips the installer entirely.

Questions

• What is a CVE, CWE and CVSS and how they relate to each other?
• What is the difference between a vulnerability, an exploit and a malware?
• What is the difference between a vulnerability, a weakness and a misconfiguration?
• Can you deploy a container with a vulnerable application?
• Can you run an exploit against the vulnerable application?
• Can you capture and analyze the traffic generated by the exploit?
• Can you use ZAP to generate traffic against the vulnerable application?

Relevant Sources

• K. Tsipenyuk, B. Chess and G. McGraw, “Seven pernicious kingdoms: a taxonomy of software security errors,” in IEEE Security & Privacy, vol. 3, no. 6, pp. 81-84, Nov.-Dec. 2005, doi: 10.1109/MSP.2005.159.
• Chris Hughes, Nikki Robinson, “Effective Vulnerability Management”, 2024, ISBN: 978-1-119-82399-0

Web pages

• Vulhub: Docker Compose environments of real, publicly documented vulnerabilities, used for the ladder above.
• Podman: the container engine used in this course, with its documentation on networking and rootless setup.
• Kali Linux downloads: live images, pre-built virtual machine images and checksums.
• VirtualBox: the hypervisor used on x86 hosts.
• Wireshark capture setup: which interface to sniff when the traffic is inside a container bridge.
• CVSS calculator: score a vector interactively and see what each choice does.
• CVSS 4.0: The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities.
• CVE Sandbox: A platform for researching, developing, and testing CVE-related vulnerabilities and exploits.
• OWASP Top 10: The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
• Top 25 CWE: Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
• CVE Details: security vulnerability datasource
• CVSS: Common Vulnerability Scoring System SIG
• Pwntools: CTF framework and exploit development library