Tag: covfefe

Another day, another challenge.

In this post we’re going to solve the Cofveve virtual machine.

Let’s get started

After downloading the virtual machine and starting it we see the following:

Using the netdiscover command we can find the IP that the virtual machine is using

Going back to our attacking machine (I’m using the parrot virtual machine).

Doing an nmap scan with the command – nmap -sV <IP address from netdiscover command>, we see the following

There are three ports that are open – ssh, and two http ports.

When http ports are opened the next step is to try to do a recursive brute force attacks to find hidden directories.

We’re going to use two programs – dirb and gobuster.

Doing the dirb of port 80, we get:

Using gobuster we see:

We see that both of the programs did not return anything.

Let’s try to the following programs with the 31337 port, let’s start

We see five files – a robots.txt, and four hidden files (start with .)

The robots.txt gives information about sites that should not be crawled by the internet. This is useful as it will give us files or directories (folders) to review to get more information.

Going to the robots.txt we see:

Hmm, there are three directories that are disallowed. Let’s try to go to them.

Let’s start with taxes. When navigating there we see:

We found the first flag!

Going to the second directory .bashrc we see

Hmm, it’s a file, let’s save it.

Going to the last directory of .profile we see

Another file to save.

Going back to either dirb or gobuster results we have one more directory, .ssh.

This is strange. The .ssh which is hidden should not be exposed on the internet. This folder has information about how to login into the system. Such information is a private key (which only the user should know) public key (which everyone knows), as well as other things.

Going to this folder we see:

We see three items, which look like additional files.

Let’s see if we can navigate to these files.

Navigating to the first item, id_rsa we see:

Another file, so let’s save it.

Let’s try the second file – authorized_keys. Going there we see:

Another file, let’s save it.

Finally, let’s go to the third item – id_rsa.pub

Now that we saved everything let’s go back to our virtual machine and open the files.

First, let’s open the id_rsa.pub file. This file is the public key that is part of a pair. The other pair is the private key. As the name suggests only the user should know their private key and not expose it to anyone else. The public key can be exposed to everyone.

Opening the file we see:

We see a ssh-rsa. RSA is a cryptographic algorithm. Looking at the end of the file we see a valid user – simon@covfefe. We need to save this user as we will need it later.

Opening the id_rsa file we see:

This file is the private key to log into the SSH server as Simon! This is bad, as I said before this file should NOT be exposed as Simon private key should only be known by him only.

Opening the authorized_keys file it has the same content as the id_pub

How can we use this information?

We know a user (simon@covfefe) and a private key.

Well we can log into the ssh server.

Let’s start.

We can use the command ssh -i id_rsa simon@covfefe

Let’s break this down.

We’re logging into the SSH server, specifying a file id_rsa (Simon’s private key) and the user of Simon

We get the following output:

Uh oh – we received an error:

The private key is too open. We need to change the make it less accessible. To do this we’re going to change the permissions from 644 to 600. What this will do is give access to the owner in this case parrot (which is us).

To do this we will use the command chmod 600 id_rsa

Trying to log in again we have the following:

We need a passphrase… which we don’t have. How do we get this?

Doing a good ol’ Google search of cracking passphrase for id_rsa we see the following link

We see there’s a command ssh2john which can be used to crack the passphrase. Let’s do it!

First, we located where the ssh2john command lives in the file system. Next, we’re going to create a hash using ssh2john. We’re going to use this for the next step.

Next, we’re going to send our hash to john which will be used to crack it. We’re going to use the wordlist rockyou.txt which is a common wordlist used to crack passwords. Doing so, we found our passphrase – starwars.

Running our SSH command again, we enter the passphrase of starwars and we’re in the system!

Doing a long listing and showing all of the files (ls -la) we see the files we found before when brute forcing the directories. Let’s look at the .bash_history. This file is good to review as it will let you know commands that were executed on the machine.

Opening this file we see a read_message and then exit. What is read_message? Is this a program?

Executing the read_message we get a prompt. Let’s enter the name Simon. We received a message stating this is is a private messaging system and the source code is in the root directory.

Navigating to the root directory and doing a long listing with all the files (ls -la) we see there’s a read_message.c file, and flag.txt!

Opening the flag.txt file we see a permission denied :-(. Looking at the long listing again this file (flag.txt) can only be accessed the owner, which in this case is root (column 4). I am the user Simon, so I can’t view the file.

Opening the read_message.c file, we see source code, and… the second flag!

And it’s giving us a hint – we need to review the source code.

Looking at the source code we have a buffer (buf) that is holding 20 characters and is executing another file program which is pointing to /usr/local/sbin/message. Whenever we see buf we need to think of buffer overflows.

Buffer overflows are a vulnerability where you overflow the input to access other parts of the computer system. In this case, since we have a holding space of 20 characters – we’re going to overload the buffer with characters OVER 20 characters. Also we’re going to try to change the shell to /bin/sh <— bourne shell. We’re going to change the shell to escalate the user. Changing from Simon to root. We need to be root to open the flag.txt file.

Let’s try it.

Running the commands id and whoami we see we’re root!

Now let’s open the flag.txt and see what’s in the file.

We solved the challenge!