# Deathnote: BOOT2ROOT CTF VULNHUB WRITEUP Welcome back to my writeup! Today, I’ll show you how I solved the **Deathnote** challenge from **Vulnhub**. It’s a simple Boot2Root, and I’ll walk you through each step, the tools I used, and the techniques that made it straightforward to complete. Let's start!!! **Reconnaissance** First, we’ll use **Nmap** to identify open ports that could serve as potential attack vectors. ``` nmap -A -T5 172.29.160.38 ```
From the **Nmap** scan results, we can see that both port 22 (commonly used for **SSH**) and port 80 (used for **HTTP**) are open on the target machine. This tells us that the system is running services on these ports, which could potentially be leveraged for further enumeration and exploitation. Let's visit the website.
The reason it didn’t work is because the service relies on a specific domain name. If you look closely at the URL, you’ll notice it uses a domain instead of just an IP address. To access it properly, we need to add that domain to our `/etc/hosts` file so the system can resolve it correctly. After adding the entry to our `/etc/hosts` file, we simply refresh the page, and we’re now able to access the site properly
Woah, Kira!!! Let's take a look at the **HINT**.
It mentions that there’s a file called *notes.txt* somewhere on the server—but where exactly? Let’s broaden our enumeration to find out. While going through the site, I noticed that it’s actually running **WordPress**. With that in mind, using **WPScan** seems like a logical next step to gather more information and potentially uncover vulnerabilities. ``` wpscan --url 172.29.160.38 ```
I quickly noticed the *uploads* directory. In most WordPress assessments, this is one of the first locations you should inspect, since it often contains user-uploaded files that might reveal useful information or even lead to potential footholds. Let's visit it.
After digging around, I finally found the file mentioned in the earlier hint, located inside the `2021/07/` directory.
At the bottom, I found two text files, and one of them matched the hint we saw earlier. I simply used `wget` to download both files onto my machine.
With both files in our hands, the next step is to inspect what’s inside them. Here's the `notes.txt`
And here's the `user.txt`
This looks like a wordlist. If my assumption is right, it might contain the credentials for SSH. So, let’s use these two lists and try brute-forcing SSH with **Hydra**. In this case, we’ll brute-force both the username and the password. This is manageable because `user.txt` contains only a handful of usernames, and `note.txt` provides just a few potential passwords or phrases. ``` hydra -L user.txt -P notes.txt 172.29.160.38 ssh -t 20 ```
After some time, we've successfully got the SSH credential for user `l` . Now let's login to SSH as user `l` . ``` ssh l@172.29.160.38 ```
We’re in! Inside the user `l` account, there’s a `user.txt` file that contains a **Brainfuck** code.
When I decode it using [Dcode](https://www.dcode.fr/brainfuck-language), this is the result: `i think u got the shell, but you won't be able to kill me -kira` It seems that `l` is not alone here, maybe there's another user named `kira` .
There it is! `kira` is here! Now let's take a look!
As you can see, there’s a file called `kira.txt`. However, if you look closely at its permissions, it’s readable only by the user `kira`. Since we’re currently logged in as user *l*, we don’t have access to it. This means we’ll need to switch from user `l` to user `kira` in order to read the file. But the question is, how? Since we don't know the password of `kira` . Looking more closely, you’ll notice an `.ssh` directory, and inside it there’s an `authorized_keys` file and we can read it!!
Given this setup, you’ll notice that the `authorized_keys` file is owned by user `l`, which is our current account. Because of that, we can SSH into the `kira` account without needing a password. But how? Let me explain how SSH authentication logic works. When you connect to a Linux system using SSH, the authentication process relies on a **public–private key pair**. The flow is simple: * The **public key** goes into the target user’s `~/.ssh/authorized_keys` * The **private key** stays with the attacker/user who wants to authenticate During login, SSH checks: "Does the client’s private key match any of the public keys in this user’s `authorized_keys`?" If **yes**, access is granted.\ If **no**, authentication fails. To switch to `kira`, we'll just use ssh ``` ssh kira@172.29.160.38 ```
We're now `kira` ! Now let's check the `kira.txt` .
It's a **Base64** encoded string, if we decode it, this is the result:
Looks like there's a folder hidden inside `/opt` and `/var` . Let's visit `L` in `/opt` first.
Now, let's visit the `fake-notebook-rule` directory first.
That `case.wav` looks like a wav file but when I attempt to listen to it, it's said that it's not in correct format and when I take a look at its content, it's a hex string!
Decode it and this is the result:
It's a Base64 string, decode it and this is the result:
So it's a password! Let's try to use this to switch to **root**. ``` sudo su ```
We're finally root!!
We've successfully solved Deathnote!!!