DevOops Write-up (HTB)

George O
George O
Oct 13, 2018 · 4 min read

This is a write-up for the recently retired DevOops machine on the Hack The Box platform. If you don’t already know, Hack The Box is a website where you can further your cybersecurity knowledge by hacking into a range of different machines.

TL;DR: XXE & Git Reverts. | While DevOops is known to be fairly easy, it was still good practice and fun to do. While I have seen both the same user and root methods in other CTFs before, they were both presented well, and overall the box was very well-structured.


Our initial nmap scan reveals only two ports: SSH and HTTP:

nmap -sV -sC -oN nmap.log

When opening the HTTP page in Firefox, we are presented with the following:

A page that is “under construction”.

Unfortunately, there is little more we can do on this page. As such, I ran a dirb to try and find some other directories/files.

This revealed two different paths.

Since we already know what /feed is, let’s take a look at the /upload page:

A page in which we can upload files.

The first thing that came to my mind here was XXE (External XML Entity) attack, similar to that described in my Aragog write-up.

For the payload to work, we know that we will need to send off an XML file that includes the author field, subject field and content field. As such, we can likely enter our payload into any of these.

As such, I came up with the following payload:

<?xml version="1.0"?><!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><Container><Author></Author><Subject></Subject><Content>

Uploading this then spits out the contents of /etc/passwd, which means that we have read-only access onto the server!

The (unformatted) contents of /etc/passwd.

While I could enumerate through files manually to try and find out how to gain a full shell, I decided to simply edit the script that I wrote for the Aragog box to suit our need here. Essentially, this script creates and posts the payload with the file specified by the user, and then outputs the file contents in a neat format:

With this, we can very quickly find out that there is a user called roosa:

The same contents shown previously.

This article is always very useful when it comes to read-only server access, as it illustrates the files that we should be looking for. In this case, I quickly found out that we have access to roosa’s id_rsa file:

The contents of /home/roosa/.ssh/id_rsa.

The above command is explained here.

We can now give the roosa.key file the appropriate permissions, and connect to the server through SSH:

We have the user flag!


At this stage, I began the usual enumeration. revealed very little, and there was no use checking for sudo permissions since we didn’t have roosa’s password.

However, there were some interesting entries in roosa’s .bash_history file:

cd work/blogfeed/rm -Rf resources/integration/auth_credentials.keymv resources/authcredentials.key resources/integration/git add resources/integration/authcredentials.keygit commit -m 'add key for feed integration from tnerprise backend'ls -altr resources/integration/git pushssh-keygenös -altrls .altrls -altrcat kakcp kak resources/integration/authcredentials.keygit add resources/integration/authcredentials.keygit commit -m 'reverted accidental commit with proper key'git push

We can see here that roosa accidentally made a commit with the “proper key”.

In order to find this key, we must revert that commit. We can use ‘git log’ to find the commit’s id:

git log | tail -n17

We can then revert the commit with ‘git revert commitid’.

As stated, the authcredentials.key file has been changed. So, we can open that and find the deleted rsa key.

After copying this, we can give it the correct permissions, and connect to the server using the key as the identity file:

We have the root flag!

And with that, the box has been completed.

CTF Writeups

A collection of write-ups for various systems.