Introduction:

This week’s retiring box is DevOops. Coming in at a difficulty rating of 4.3/10, it’s not an incredibly hard machine to root, but it does teach some valuable lessons in web application penetration testing and basic Linux privesc enumeration. Let’s take a look at what a simple “oops” can mean for the bad guy.

Nmap scan:

Starting Nmap 7.70 ( https://nmap.org ) at 2018-09-29 23:24 EDT Nmap scan report for 10.10.10.91 Host is up (0.041s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 42:90:e3:35:31:8d:8b:86:17:2a:fb:38:90:da:c4:95 (RSA) | 256 b7:b6:dc:c4:4c:87:9b:75:2a:00:89:83:ed:b2:80:31 (ECDSA) |_ 256 d5:2f:19:53:b2:8e:3a:4b:b3:dd:3c:1f:c0:37:0d:00 (ED25519) 5000/tcp open http Gunicorn 19.7.1 |_http-server-header: gunicorn/19.7.1 |_http-title: Site doesn't have a title (text/html; charset=utf-8). Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Aggressive OS guesses: Linux 3.2 - 4.9 (95%), Linux 3.16 (95%), Linux 3.18 (95%), ASUS RT-N56U WAP (Linux 3.4) (95%), Linux 3.1 (93%), Linux 3.2 (93%), Linux 3.10 - 4.11 (93%), Oracle VM Server 3.4.2 (Linux 4.1) (93%), Linux 3.12 (93%), Linux 3.13 (93%) No exact OS matches for host (test conditions non-ideal). Network Distance: 2 hops Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE (using port 22/tcp) HOP RTT ADDRESS 1 39.93 ms 10.10.14.1 2 39.99 ms 10.10.10.91 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.55 seconds

So, we only have two ports open here: SSH on 22 and a web server on 5000. Given that this is a CTF, my first thoughts are we will likely use the web server to find SSH creds. It’s almost a standard way of thinking on these lower difficulty machines. Let’s first check out the web server:

Not a lot of info here. Just an under construction page with an image for the feed. I looked into the source of the webpage and investigated around where I could, but found nothing interesting. Maybe there’s more directories. Let’s do a dirb and find out:

Nice! We found an upload page and a feed page. The feed page is just the image from the home page, which was actually in the source code. The upload page, however, is intriguing. I always get excited when I see the word upload. Let’s check it out:

So, we have the availability to upload an XML file it appears. Does this ring a bell from your OWASP top 10 studies? If you said XXE (XML External Entities), you are correct!

If you did not know the answer, I suggest you brush up on XXE here: https://www.owasp.org/index.php/Top_10-2017_A4-XML_External_Entities_(XXE)

In a nutshell, XXE is when we are allowed to upload malicious XML content to a web application. We can use an XML upload to manipulate a server into giving us sensitive file information. It looks like the server wants three elements: Author, Subject, and Content. We can craft an exploit as such:

Since the system is a Linux system, I’ve requested the /etc/passwd file. This file will allow us to see what users are on the machine. Here is what came back when we uploaded the XML file to the server:

With passwd files, I like to start from the bottom and work my way up. That’s typically where the system users are. There are service accounts and such included in the passwd file that make reading it from top to bottom a much slower process. From the bottom up, I see two accounts of interest: blogfeed and roosa. We know we need an SSH private key in order to log in via SSH. Private keys are typically stored in the /home/username/.ssh/id_rsa file. I attempted to retrieve a key from both users and one worked. Here is the payload:

Here is the result:

Dope. This key looks pretty jacked up. We’ll need to clean it up and make it pretty. Here is what it looks like cleaned up:

We can then modify the key permissions with chmod (SSH keys require 600 permission settings) and attempt to connect:

WOOOOO. We have a shell! From here, we are able to retrieve the user flag. The next task is to begin enumeration for privesc. Among the first things I always check are sudo levels and bash history. Sudo because you never know what permissions the user has and bash history because there might be some juicy information left behind. There was nothing in terms of sudo permissions, but history?

roosa@gitter:~$ history 1 ssh-keygen --help 2 ssh-keygen 3 ls -altr .ssh/ 4 cat .ssh/id_rsa.pub 5 nano /etc/host 6 nano /etc/hostname 7 sudo nano /etc/hostname 8 exit 9 nano .ssh/id_rsa.pub 10 exit 11 ssh git@localhost 12 exit 13 ssh git@localhost 14 clear 15 apt-get upgrade 16 exit 17 ls -altr 18 mkdir work 19 cd work 20 mkdir blogfeed 21 git init 22 git add . 23 git commit -m 'initial commit' 24 git config --global user.email "roosa@solita.fi" 25 git config --global user.name "Roosa Hakkerson" 26 git commit -m 'initial commit' 27 nano README-MD 28 nano README-md 29 nano README.md 30 git add README.md 31 git commit -m 'initial commit' 32 git remote add origin git@localhost:/srv/git/blogfeed.git 33 git push origin master 34 exit 35 ps -Af 36 kill 27499 37 exit 38 sudo su - 39 exit 40 groups 41 exit 42 git push origin master 43 cd work/blogfeed/ 44 git push origin master 45 cd .. 46 cd blogfeed/ 47 cd .. 48 git add README.md 49 git commit -m 'Initial commit' 50 git push 51 git log 52 ls 53 mkdir src 54 mkdir resources 55 cd resources 56 mkdir integration 57 mkdir integration/auth_credentials.key 58 nano integration/auth_credentials.key/ 59 ls -altr 60 chmod go-rwx authcredentials.key 61 ls -atlr 62 cd .. 63 ls -altr 64 chmod -R o-rwx . 65 ls -altr 66 ls resources/ 67 ls resources/integration/ 68 ls -altr resources/ 69 ls -altr resources/integration/ 70 rm -Rf resources/integration/auth_credentials.key 71 mv resources/authcredentials.key resources/integration/ 72 git add resources/integration/authcredentials.key 73 git commit -m 'add key for feed integration from tnerprise backend' 74 ls -altr resources/integration/ 75 git push 76 ssh-keygen 77 ös -altr 78 ls .altr 79 ls -altr 80 cat kak 81 cp kak resources/integration/authcredentials.key 82 git add resources/integration/authcredentials.key 83 git commit -m 'reverted accidental commit with proper key' 84 git push

Now, let’s start from the beginning and try to make some sense of what’s happened. The user is generating ssh keys and making a series of commits to their git repo. On top of this, they are SSHing in and out of different accounts. If we follow the story, we see that there is an SSH key that is committed to the git repo. Later on, there is a revert on that key with the notes “reverted accidental commit with proper key”. This reads to me like they accidentally used the wrong SSH key when they committed to the repo. We can take a look at the git log history and see what happened. The command is git log -p

A little bit of scrolling and we come across the following:

Would you look at that. It’s a private RSA key. Surely it’s not root’s:

Dev….

Wanna chat? Add me on Twitter, YouTube or LinkedIn!

Veteran? Join our Slack!