# DriftingBlues: 6 BOOT2ROOT CTF VULNHUB WRITEUP Glad to have you back for another writeup! In this one, I’ll walk you through the step-by-step process I followed to solve the sixth stage of the DriftingBlues Boot2Root challenge from VulnHub. Let’s dive in!

First off, like usual, we’ll start by using `Nmap` to scan for open ports that might serve as our entryway into the system. `nmap -A -sC -p- -T5 -oN nmap_result.log 192.168.54.188`

As you can see from the Nmap scan, there's a subdirectory revealed: `/textpattern/textpattern`. But let's visit the main webpage first.

Now let's visit the `/textpattern/textpattern` .

A textpattern login page. Textpattern is a lightweight, open-source content management system (CMS) written in PHP that uses MySQL for managing website content. It’s known for producing clean, semantic code and is favored by designers who want full control over HTML and CSS. Often installed in directories like `/textpattern/`, it includes an admin panel for managing articles, templates, and plugins. When I visit the `robots.txt` , there's a note.

Now, based on the hint, let’s begin enumerating for any files with a `.zip` extension using `Gobuster`. `gobuster dir -u http://192.168.54.188 -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -x .zip`

There's a zip file named, `spammer.zip` . Let's unzip the zipfile.

But there's a password, let's crack it! We will use `zip2john` to get the hash of the zipfile. `zip2john spammer.zip > hash`

Now let's crack the hash using `john`. `john --wordlist=/usr/share/wordlists/rockyou.txt hash`

Now that we got the password for the zipfile, let's unzip it again! After extracting the contents, a text file named `creds.txt` was revealed.

Let's see what's inside.

A username and a password, when I enter these credentials in textpattern, it works!

Since we have administrative access, we can take advantage of a built-in feature in Textpattern that allows users with elevated privileges to upload files. This functionality is typically restricted to roles like the Publisher or site administrator for security reasons. Given our level of access, we can attempt to upload a malicious payload, such as a reverse shell payload. Under the **Content** tab, you’ll find a **File** section—go ahead and click the **Upload** option and select your reverse shell payload to upload it. You can opt to use [PentestMonkey’s](https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php) reverse shell payload, but in my case, I chose to use my [own](https://github.com/kUrOSH1R0oo/reverse-shell-payloads/blob/main/payload.php) custom PHP payload instead.

It's now uploaded, now to execute our payload, we should know the actual path of it, since it's in file, the path should be `http://target.com/textpattern/files/payload.php` . Bu before that, let's setup our listener for a while. `nc -lnvp 1234` Now we can trigger our payload.

We're in!! Now, let’s upgrade our shell to a fully interactive one using a pseudo-terminal `(pty)`. `python -c 'import pty; pty.spawn("/bin/bash")'` After that, we’ll set our terminal type to `xterm` for better compatibility and display. `export TERM=xterm`

When I navigated to the `/home` directory to check for existing user accounts, I found it completely empty—which is quite unusual. So, I went ahead and decided to run `LinPEAS` at this point. During the scan, I came across something that caught my attention.

It turns out that this machine is susceptible to the **DirtyCOW** vulnerability! **What is DirtyCOW?** **DirtyCOW (CVE-2016-5195)** is a privilege escalation vulnerability in the Linux kernel that takes advantage of a race condition in the way the kernel handles the **copy-on-write (COW)** mechanism. When a process requests a private, read-only mapping of a file (like `/etc/passwd`), the kernel allows it to make a private copy if it tries to write to it. However, DirtyCOW exploits a race condition where an attacker rapidly writes to memory while simultaneously using `madvise()` to trigger the kernel’s COW process, tricking it into writing to the underlying read-only file instead of a private copy. This allows an unprivileged user to overwrite protected files, potentially inserting a new root user or modifying binaries—thus gaining full root access. We can search the exploit using `searchsploit` . `searchsploit dirty`

In our case, we will use the `40839.c` . `searchsploit -m linux/local/40839.c` Then transfer the exploit to our target machine. Once the exploit is transferred, we’ll compile it using `gcc`. Keep in mind that DirtyCOW relies on `pthread` and `lcrypt`, so we need to include those libraries during compilation. `gcc -pthread -lcrypt -o exploit 40839.c`

Now let's execute our exploit! `./exploit`

It should work at this point, let's check the `/etc/passwd` .

It worked perfectly! As you can see, the user **firefart** now has root access! Now let's switch to **firefart**! `su firefart` And enter the password we've set during the the exploit.

We are root!!!!

We've successfully pwned DriftingBlues: 6!!! Honestly, this machine was relatively straightforward compared to others. The steps to gain access and escalate privileges were clear, with minimal obstacles along the way. From basic enumeration and file upload to exploiting a well-known vulnerability like DirtyCOW, the entire process flowed smoothly. It’s a great box for beginners looking to practice core skills in privilege escalation and web-based exploitation.