Labs · Cyber Security

Lab: Patch an Outdated Package on Your Own Ubuntu VM and Verify the Vulnerability Is Fixed

By Ravindra Bagale Last updated: 8 October 2026

Intermediate35 minYour own Ubuntu Server VM · apt · pro (Ubuntu Pro client, free) · VirtualBox snapshots

Course: Cyber Security · Chapter 23: Exploitation with Metasploit

Chapter 23 explains how exploitation frameworks use known vulnerabilities; this lab is the defender's answer: patch the vulnerable service and verify the risk is gone.

Chala mitrano! Metasploit works because many servers run old versions with known holes. The defender's best weapon is simple: patch, restart, verify. Today we do it the professional way, with a snapshot first and proof at the end. Patch kela, pan check kela ka? Te aaj shikuya!

Suppose we are…

Suppose we are on the server operations team at Paytm. A security bulletin says an OpenSSH vulnerability (for example CVE-2024-6387, nicknamed "regreSSHion") affects many Linux servers. The manager asks: "Are we patched? Prove it." We practise that exact workflow on our own Ubuntu VM.

Goal of this lab

By the end you will have:

A VM snapshot taken before any change (your rollback).
A list of upgradable packages and the CVE status of one of them.
OpenSSH upgraded, the service restarted, and proof of the fixed version.

What you need (all free)

Your own Ubuntu Server 22.04 or 24.04 VM, switched to NAT for updates (not Metasploitable).
VirtualBox snapshots. About 35 minutes.

Safety and ethics

Patch only systems you own or are responsible for. On real servers, patching happens in an agreed maintenance window after a backup, because a restart can briefly interrupt users.

Steps

In VirtualBox, take a snapshot of your Ubuntu VM named before-patching.
Log in and refresh the package list:
```
sudo apt update
apt list --upgradable
```
What you should see: a list of packages with [upgradable from: ...]. Security fixes come from the -security pocket, for example noble-security.
Check the installed OpenSSH version:
```
dpkg -l openssh-server | tail -n 1
ssh -V
```
Write the version down, for example 1:9.6p1-3ubuntu13.
Ask Ubuntu whether a specific CVE affects this machine (the pro tool is pre-installed on Ubuntu and free for this):
```
sudo pro fix CVE-2024-6387
```
What you should see: either CVE-2024-6387 is resolved. (already patched) or a message that the affected package will be upgraded, followed by the fix being applied.
Read what the latest OpenSSH update fixed:
```
apt changelog openssh-server 2>/dev/null | head -n 20
```
What you should see: entries like SECURITY UPDATE: ... with CVE numbers.
Apply all pending updates (the normal way to stay patched):
```
sudo apt upgrade -y
```
A patched program is only safe once the running copy is the new one. Restart SSH and check:
```
sudo systemctl restart ssh
systemctl status ssh --no-pager | head -n 5
```
What you should see: active (running) with a "since" time of just now.
Verify again:
```
dpkg -l openssh-server | tail -n 1
sudo pro fix CVE-2024-6387
```
What you should see: the version is the same or newer than before, and CVE-2024-6387 is resolved.
Check whether the kernel or core libraries need a reboot:
```
ls /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs
```
If the file exists, reboot with sudo reboot, log in again, and confirm SSH still works.
Write a 3-line patch note: Package, old → new version, CVE status verified on (date/time).

Ravindra Bagale's Tip

"Updated" and "protected" are not the same thing. Old code keeps running in memory until the service restarts or the server reboots. That is why we always restart and verify. Aani snapshot aadhi, nehami!

Common mistakes

Mistake	What happens	Fix
Upgrading without a snapshot or backup	No easy way back if something breaks	Snapshot first
Not restarting the service	The old, vulnerable code is still running	`systemctl restart` or reboot, then check "since"
Trusting only `ssh -V`	It shows the upstream version, not Ubuntu's patch level	Check `dpkg -l` and `pro fix`
Ignoring `/var/run/reboot-required`	Kernel fixes are not active	Reboot in a planned window
Patching Metasploitable from the internet	Its repositories are dead and it must never be online	Patch practice is done on your normal Ubuntu VM

Self-check checklist

I took a before-patching snapshot.
I listed upgradable packages and noted the OpenSSH version.
I checked a CVE with pro fix and read the changelog.
I upgraded, restarted SSH and saw a fresh "since" time.
I wrote a 3-line patch note with proof.

0 of 5 done

Try-at-home challenge

Find one more CVE in the apt changelog output of any package you upgraded and check it with sudo pro fix CVE-XXXX-XXXXX. Then turn on automatic security updates and prove they are enabled.

Check your answer

Run sudo apt install -y unattended-upgrades and sudo dpkg-reconfigure -plow unattended-upgrades (choose Yes). Proof: cat /etc/apt/apt.conf.d/20auto-upgrades shows APT::Periodic::Unattended-Upgrade "1";, and systemctl list-timers apt-daily-upgrade.timer shows the next run.

Samjla ka? Snapshot, patch, restart, verify, write it down. Aata pudhe jaauya: Chapter 24 shows why encryption on the wire matters.