(If you have not read Part 1, you should have a look at it here.)
DISCLAIMER: If you would like to try the TORMENT machine and root it (this is currently pending Vulnhub publication), please download a copy of the machine here. Do NOT read beyond this disclaimer because this will be a full post about the TORMENT machine itself.
Link to machine: https://drive.google.com/open?id=1IfaMMn1NAkJwKcfM9OLo39tbWIedHGMQ
If you need a walk-through, I have finally come up with a walk-through of this machine. DO NOT download unless you have tried harder, but not hard enough.
The Inspiration Behind TORMENT
Many students in the OSCP comment on enumeration. How much enumeration is enough? The answer is almost always “try harder”. While it sounds frustrating and morale-sapping, the “try harder” ethic is often extremely important for red-teamers. The subject of penetration testing is often filled with rabbit holes, and non-exploitable vulnerabilities. And as most penetration testers know, more information is generally good, so enumerate harder.
To appreciate the “try harder” ethic, one needs to have the following traits:
- A willingness to challenge one’s limits of knowledge.
- A willingness to learn.
- A willingness to try, fail, and try again.
Brainstorming
I wanted TORMENT to feature different “schoolboy” mistakes in different forms, some of which do not appear on typical CTFs. I had fun introducing multiple services that were not familiar to many. I learnt much about these services as well. At the last, before the era of web applications dominating the Internet, there were services like IRC servers. I thought it would be interesting to introduce the penetration tester to an environment not typically found on CTFs, but might be a legacy machine on a corporate network.
TORMENT hence took a rough design to:
- Allow penetration testers to be introduced to somewhat “unfamiliar” network services like CUPS and IRC.
- Make penetration testers take dutiful notes; different pieces of the puzzles in TORMENT need to be put together to make sense.
Because of the rough design, this machine will become difficult because of the amount of research required to properly implement the machine.
Designing and Storytelling
The Chain
I used a “chain” to string the different steps together in a previous machine I built: MERCY. This is fairly typical in CTFs. An example of a typical “chain” can be shown by another machine I built, MERCY (skip this part if you have not rooted MERCY. Box is available here. (Skip the chain picture if you have yet to root MERCY, and you would like to do so.)
A Different Approach
The design for TORMENT differs. Instead of a chain, the penetration tester will need to find different “puzzle pieces” and put them together. An elegant puzzle design is in the usage of SSH.
SSH has multiple methods of implementation. We shall look at the key methods because a SSH log-in requiring keys needs three input fields: username, SSH key and passphrase. For all the fun we have, this is certainly NOT three-factor authentication by any means!
Users can be designed into the machine through many methods. Some of these include:
- SMTP/POP3/IMAP users
- Samba users (Linux) and SMB/CIFS users (Windows)
- NFS users
- Web application users
However, this led me to investigate how else we could implement users. This was where the design was that:
- TORMENT will resemble a printing management environment.
- Users connect their printers through this server.
- Unfortunately, this server is “not clean” – there are other services also hidden and hosted on this server, giving rise to many problems.
This immediately solved puzzle piece #1: users. I then decided to add a bunch of users to the CUPS service. I found a default CUPS installation through apt-get, and install it.
Inserting Users: Learning about the CUPS Service
The CUPS service was interesting for a number of reasons. It featured its own web interface. In the old days, CUPS could be used as a local manager to manage printers that will be controlled and connected to this server. However, many administrators prefer remote management from the comfort of their own machines. Misconfigurations of this sort can lead to unintended consequences for the CUPS service.
Misconfiguration #1: We shall let the CUPS web service listen to outside IP addresses as well, with the full printer listing available to anyone that can find it, unauthenticated. The full printer listing has users of members in said enterprise.
Inserting a Secret Key: FTP Service
Many of us typically manage our servers with SSH, and secure it through IP whitelisting, using an authentication mode such as a key exchange, and assign proper host privileges. However, complacency can happen, and a string of misconfigurations can lead to unwanted information disclosure.
Some users place keys in locations out of convenience for their fellow administrators, but do not realise the insecurity of this. Sometimes, for accessibility, some administrators even think “security by obscurity”, and hide the key in an easily accessible service (think of stories where keys to the house were found under flower pots).
In the spirit of adding an IRC server later as well, we shall also add a second file here, informing the administrators which channels they should check for “printer defects”. We shall add two ingredients here: a key and a channel list.
Further Perverting the Print Management Server: The Passphrase on IRC!
We designed TORMENT to be an abused, overused, unclean machine. We could further deteriorate its security posture with some common enterprise rhetoric of “one-stop portals”. We shall create a “one-stop insecure printing portal” ourselves, by implementing a helpdesk, in the form of a chat, in case of issues with the print management server. This should be a separate application in an enterprise, or simply just reliant on enterprise chat like Skype. Predictably, this is a nightmare for the security department.
The IRC service can be quite enlightening. Despite its age, IRC still sees use, especially by techies, such as surfing the Kali Linux IRC channel. However, it is now a fairly niche community. Let us now get an IRC server to play with.
I obtained a copy of ngIRCd by apt-get, once again. There were some interesting properties about ngIRCd when looking through their configuration files. One of it is when I realised the Debian variant of the configuration file had an interesting line (default config file is located at /etc/ngircd/ngircd.conf):
At this point, I thought this was interesting to have; some developers use default passwords, or easily available passwords by virtue of ease of use, which can prove the undoing of many applications. This discovery is interesting, because we wondered how ngircd.conf would look like on different flavours of Linux. On Ubuntu, we saw:
But on CentOS, I get a slightly different config file after installing ngIRCd:
At this point, I could perform a thought experiment: how many pentesters will try (because they will not be able to brute force the IRC password easily) to replicate the environment, knowing it is a Debian box (Samba will leak this information), and try to set it up?
Privilege Escalation: The Writable, Configurable Service
Many OSCP wannabes complain of the lack of machines to test Windows privilege escalation on. This is partially because of the need for licensing for Windows machines. Hence, you cannot find them on Vulnhub (this essentially means free redistribution of Windows OS, which can’t be the case).
I decided to try to look for a privilege escalation technique in Windows to see if it was reasonable to “attempt” a crude implementation on a Linux machine. Some ideas clearly do not work (e.g. AlwaysInstallElevated=1), but I found some analogies between services on the Windows and Linux platforms.
Weak service permissions are often looked at in a privilege escalation enumeration because these can be redirected to run our own binaries. In Windows, we try to adjust the path to the binary to be executed, and we may trigger a restart of the machine for services that start on start-up (this setting is not trivial; you can deny shutdown privilege).
When crudely “attempted” on Linux, I decided to simply make the Apache service configuration file world-writable, introducing a misconfiguration. This misconfiguration alone is not enough; I must similarly provide privileges, through some way, to restart the service. Hence, the introduction of systemctl rights to shutdown and reboot with a certain user account.
Apparently, later versions of Apache did not run as root (otherwise you could simply set to it); I decided to create a “staging account” with higher unintended privileges for the privilege escalation; the ideas as they seem turned out to be more of a TORMENT than I expected (more on validation).
The Finalised Design
The finalised design for TORMENT looks like this, for a low-privileged shell.
Validating
Validating was a rather simple affair because there was no exploits to “take care of”. There was also no interference from protection such as SELinux, or having to configure iptables to allow users to spawn reverse shells (no need, because the way in is through SSH).
All we needed to make sure, though, is that, the machine was not breakable through unintended ways. We must make sure we:
- have an updated FTP server (easy)
- have an IRC channel whose passphrase mechanism cannot be circumvented/bypassed
- have a CUPS server that is not vulnerable (only the most updated version seemed to be fine
All in all, validating TORMENT was easy. Because there was no real exploit code to use, there was no need to test for exploit reliability.
Testing
Even if one man’s view of the world was pristine, I needed more than myself to check for the machine’s “rootability” and intended difficulty. I was taken aback with my initial set of testers.
Let us recall the design for TORMENT.
I expected that these alone were not supposed to pose much difficulty. What I thought testers might have decided to do:
- probe other services and wonder why they got nothing out of it.
- not realise they did not need to probe every service so deeply.
Some examples:
What I found:
- Testers were confused at the CUPS service on what they were supposed to find. Mission accomplished — it looked so natural that testers were looking for clues that would shout at them, except that there were clues that lay subtlely.
- Testers found FTP access standard. That was OK.
- One tester bypassed the IRC channel and brute forced the SSH passphrase without much effort. I had to change that.
- Many testers complained how difficult it was to find “wealllikedebian” on the Internet. It was clear that many testers do not adopt an approach of replicating an environment and testing the application from a controlled environment. (Download application, understand its internals and see what can be done.)
The privilege escalation was more well-received, because it was not a run-of-the-mill Linux privilege escalation. Little can be mentioned about the privilege escalation because its design was compact.
Part 3: From one machine to many machines: a penetration testing cyber-range. I may split it into three parts, namely:
- 3A: Network Ideas (with examples from my other published creations)
- 3B: Dependencies and Pivots (with examples, but not necessarily published creations)
- 3C: Putting it Altogether: Black-box, white-box elements (Not all skills are best taught with merely black-box methods.)
I will probably take a break from the series for a month or two, but will return to discuss cyber-ranges.
Until then, ciao!