Facts (S10)— HTB Writeup
First, this machine is an easy machine with Linux OS, and skill required :
- Web and cloud enumeration
- S3/object storage misconfiguration analysis
- SSH key handling and Linux fundamentals
- Post-exploitation enumeration (
sudo -l) - Binary abuse and privilege escalation (fecter custom code loading)
Overall level: Medium
Focused on misconfiguration chaining rather than complex exploit development.
Always do reconn, let's use Nmap
Nothing special here, now do an enumeration
there are so many 200, but there is an interesting thing here
Let’s create an account on the admin panel and log in with the account
We can login into the admin panel, but the role is only clients, not administrators.
but it’s ok, now we’re gonna looking for the Vulnerabilities on Cameleon CMS — Version 2.9.0
We found it, it’s CVE-2025–2304
let’s try it on
We’re doing privEsc and AWS S3 Configuration Leak
After obtaining the exposed AWS access key and secret key, I configured the AWS CLI to validate whether the credentials were still valid. Once configured, I specified the custom endpoint pointing to the internal service and enumerated the available S3 buckets. This confirmed that the credentials were active and allowed access to internal storage resources
Let’s dig deeper into the bucket’s contents. Interestingly, an SSH private key was found inside. This could potentially allow direct access to the target machine, so I copied the key to my attack machine for further use
After obtaining the private key, I converted it into a format compatible with John the Ripper using ssh2john.py. Then, I launched a dictionary attack with the rockyou wordlist. Within a few minutes, John successfully recovered the passphrase: dragonballz
With the passphrase in hand, I was able to authenticate via SSH using the private key. dont forget to give permission to the key “chmod 600” and get the user flag~
After obtaining the user flag, the next step is gaining root flag, of course, wkwk
This means that the user trivia is allowed to execute /usr/bin/facter as any user (including root) without being prompted for a password. In other words, facter can be executed with root privileges. If the binary can be abused or leveraged for command execution, this misconfiguration could lead to full privilege escalation.
After discovering that facter could be executed as root without a password, I leveraged its Ruby-based functionality to achieve privilege escalation.
Facter is written in Ruby and allows the creation of custom facts using Ruby syntax. These custom facts can execute arbitrary Ruby code when facter runs.
I created a malicious custom fact:
Facter.add(:pwn) do
setcode do
exec(“/bin/bash -p”)
end
end
and run this to spawn root:
sudo facter — custom-dir=/tmp pwn
And boommm, we got root!!
Ruby was necessary because:
facterloads custom facts as Ruby scripts- The
Facter.addfunction is part of the Ruby API - The
exec()call is a Ruby method that executes system commands
In short:
The exploitation worked because
facterexecutes Ruby code, and we were allowed to run it as root.
This allowed arbitrary command execution with elevated privileges, resulting in a root shell.
Key takeaways:
- Sensitive data exposure is often the first domino. A single leaked SSH private key can lead to initial access.
- Encryption alone is not enough, weak passphrases can be cracked, especially with common wordlists.
- Post-exploitation enumeration is critical. Running
sudo -lshould always be one of the first checks after gaining a shell. - Any binary allowed via
NOPASSWDmust be treated as a potential root escalation vector. - Scripting-based tools (Ruby, Python, etc.) are particularly dangerous when misconfigured, as they can execute arbitrary code.
- Privilege escalation is rarely about exploiting memory corruption, it’s often about abusing trust and misconfigurations.
- Chaining small weaknesses together is what turns “low severity findings” into full root compromise.
