After many years Jake and I have finally returned to streaming our exploits (pun intended) online!

In our last stream we ran through a retired HackTheBox (HTB) capture the flag called "Precious". The VOD for the stream is located over on Youtube and you can read through a more detailed writeup at https://so.thosearethegui.se/2023/07/10/precious.html.

As a component of our streams and write-ups Jake and I also thought it would be good to take a higher-level view of either direct learnings we had from doing a box, or point out the learnings that might apply to you (the reader) in your day to day. You might be a student, studying towards a career in Cyber Security, a security practitioner who might find a handy reminder about something to look in to, or someone who is just curious. There's no great theme, and points might repeat over the weeks, but we hope you find them informative and helpful!

The flow of the "Precious" was:

• There was a web service running on port 80 on the server.
• The web service contained a page to convert arbitrary URLs to PDFs, using a vulnerable PDF conversion library called PDFKit.
• Using the vulnerable library we were able to gain command execution on the box, which we used to get a reverse shell.
• From there we found credentials in a file in the .bundle directory that we could read as the service user we had reverse shell as. These credentials for another user on the server.
• Using those credentials we SSH'd to the server directly, now no longer needing the reverse shell.
• Investigating with `sudo -l` we found that our user could run a command to update ruby dependencies. There is a known issue with bundle updates and using yml templates where more command execution is possible.
• Using the exploit with yml templates we escalated to root.

In terms of realism versus gameyness, I would categorise this as having "abbreviated realism." Most of the steps were simple, without requiring much hunting or guesswork to exploit vulnerabilities. Additionally, the user credentials we found belonged to another user on a server, which allowed for escalation. While these scenarios are possible, in reality things aren't always so straightforward.

Key takeaways:

• Avoid directly using unsanitised user input for requesting other internet resources (or any resource, such as a local file on a filesystem). In our case it wasn't the external resource that was the risk, it was a vulnerability in the way PDFKit parsed URLs, but the point still stands, be careful with external content.
• If your app calls an external URL based on user input, control as much of the URL as possible. Manage and sanitise the set of possible locations server-side, ensuring user can't escape your restrictions. Be wary of client-side drop-downs; they can be manipulated.
• Don't "fix" application vulnerabilities by overriding or obscuring version data in dependencies. However, this isn't a reliable security measure. It's better to update the dependency rather than resort to security by obscurity. Note that OWASP does recommend removing reported versions and tools from output, this is good to do, but don't do it in lieu of actually updating vulnerable dependencies.
• Avoid credential reuse and storing secrets on a filesystem. Use a secrets management tool or processes for injecting secrets when required. Consider breaking up credentials/service accounts based on identity, risk, and information sensitivity.
• Be cautious with administrative tools left on a server. Deploy your application and its dependencies from somewhere else, such as a build pipeline. Limit permission to run commands to the build pipeline only. Ensure utilities like Ansible and Saltstack aren't run in a root context on the server, or that untrusted configuration can't be easily picked up by them, (including from git repos).
• Leverage containers' advantages. With them, you only need a container runtime in your deployment location, and dependencies can be injected at build time, eliminating the need for updating server components.