Description

spawn.sh is a helper script/wrapper that automates spinning up a quick minimal Ubuntu 16.04 LTS (Xenial Xerus) container

Pretext

If you've ever found yourself in a situation where you compiled an older kernel exploit on your Kali Linux and tested it on the target, only to be hit with an error that reads as follows

/path/to/libc.so.6: version 'GLIBC_2.34' not found

This setup should help you with that scenario

Intended Audience

PEN-200 Learners

Supported Architectures

x86_64; aarch64

Note on mirrors

Some users have reported issues with the default mirror selector. If progress stalls at I: Retrieving InRelease, please try one of the mirrors listed on http://mirrors.ubuntu.com/mirrors.txt (or https://launchpad.net/ubuntu/+archivemirrors for geographic locations). You can pass the mirror as the second arg to the script. The second argument is optional, meaning if no custom mirrors are passed, the script defaults to the ubuntu archive. You should always try the default archive first, and only pass a custom mirror if needed

Additionally, whichever network mirror you specify is stored in the preferred_mirror file and is therefore used by default. This is done for your convenience, but can be reverted at any time by deleting the file: sudo rm preferred_mirror

Usage

# Clone the repo locally, or download the script
kali@kali:~$ git clone https://github.com/X0RW3LL/XenSpawn.git

# cd into the cloned repo
kali@kali:~$ cd XenSpawn/

# Make the script executable
kali@kali:~/XenSpawn$ chmod +x spawn.sh

# Note: the script must be run as root
# Note: MACHINE_NAME is a custom name you will be
#       spawning the container with
kali@kali:~/XenSpawn$ sudo ./spawn.sh MACHINE_NAME

# Starting the newly spawned container
# Note: MACHINE_NAME is to be replaced with the machine name of choice
kali@kali:~/XenSpawn$ sudo systemd-nspawn -M MACHINE_NAME

Spawning container MACHINE_NAME on /var/lib/machines/MACHINE_NAME.
Press ^] three times within 1s to kill container.

root@MACHINE_NAME:~$ exit
logout
Container MACHINE_NAME exited successfully.

Screenshots

Compiling Exploits

For practical reasons, it's advised to switch to root
We will be copying/sharing exploit code/binaries to and from the machine, so it's going to be tedious to use sudo every step along the way (for this specific context)
Ideally, we want to keep the files on the containers root directory for easy access

# Note: I edited the prompt to show $ instead of # for visibility
root@kali:~$ cd /var/lib/machines/Xenial/root

root@kali:/var/lib/machines/Xenial/root$ searchsploit -m 40839

  Exploit: Linux Kernel 2.6.22 < 3.9 - 'Dirty COW' 'PTRACE_POKEDATA' Race Condition Privilege Escalation (/etc/passwd Method)
      URL: https://www.exploit-db.com/exploits/40839
     Path: /usr/share/exploitdb/exploits/linux/local/40839.c
    Codes: CVE-2016-5195
 Verified: True
File Type: C source, ASCII text
Copied to: /var/lib/machines/compiler/root/40839.c

root@kali:/var/lib/machines/Xenial/root$ systemd-nspawn -M Xenial

Spawning container Xenial on /var/lib/machines/Xenial.
Press ^] three times within 1s to kill container.

root@Xenial:~$ gcc -pthread 40839.c -o dirty -lcrypt

root@Xenial:~$ exit
logout
Container Xenial exited successfully.

root@kali:/var/lib/machines/Xenial/root$ python -m http.server 80

Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
192.168.1.20 - - "GET /dirty HTTP/1.1" 200 -

Tests

Currently, the following exploits (compiled with this solution) have been tested:

Exploit	Kernel	Status
9542	2.6 < 2.6.19 (32bit)	OK
37292	3.13.0 < 3.19	OK
40839	2.6.22 < 3.9	OK
44298	4.4.0-116-generic	OK
CVE-2021-4034	------	OK

Removing The Container

To completely remove the container from your system, you can use machinectl as follows

kali@kali:~$ sudo machinectl remove MACHINE_NAME

Ephemeral Container

Note: any changes made to the container in this state will not be saved upon exiting

kali@kali:~$ sudo systemd-nspawn -xM MACHINE_NAME

FAQs

"Why XenSpawn?"

Well, it builds an Ubuntu 16.04 LTS (Xenial Xerus) system using systemd-nspawn 😉

"I can just use Docker, so what gives?"

By all means, you can use whichever preferred setup that works best for you. I personally never liked the overhead that comes with using Docker, so I wanted a quicker (lightweight) option. Luckily, systemd-nspawn and debootstrap are exactly what I've been looking for! You get relatively lightweight images ( ~ 365Mb ), direct access to the container filesystem, and the ability to switch between persistent and ephemeral data. Meaning you can keep whatever changes to your container persistent across reboots, or get a free playground to practice creative ways on messing up an entire system without breaking the actual image

"I messed up my container, and now it's completely stuck"

The killswitch for sending a SIGKILL is Ctrl + ]]]

Credits

This would not have been made possible without the constant help and patience of @steev, the Kali dev team, and OffSec

References

Script inspiration
Walkthrough and gotchas

Links

OffSec Official Website
OffSec Community Discord
Kali Linux & Friends Discord