A Digression: The Offensive Security Certified Professional (OSCP) — Part 3 of 3

#offsec #pentest #training #tryharder

Say “try harder”…

Here I will deviate from most typical OSCP reviews and discuss a little about creating machines. If we can break machines and obtain administrator privileges, can we create them?

One way to get good at a subject is to approach it from different perspectives. For instance, we peer-tutor each other in school, and to test each other, we sometimes set questions for each other to solve. There is no difference in the world of offensive security; offence and defence inform each other; breaking machines and creating machines are two sides of the same coin. Much has been discussed about breaking machines. How about creating them?

Creating Machines

I was thrusted into creating a capture-the-flag (CTF) environment. In particular, I was supposed to design a deliberately vulnerable network. At first, I was overwhelmed.

So… I have to create secure machines of various OSes, and then “misconfigure” them appropriately?!

Well, but in Offensive Security’s mantra, what fun is there if we do not try harder?

The Plan

Planning these machines requires some sound understanding on the penetration testing process. In short, we can summarise this as:

1. Target Identification
2. Enumeration (from the outside environment)
3. Exploitation
4. Low-privilege user!
5. Enumeration (with a low-privilege user)
6. Exploitation
7. Root user!

Sometimes, some of these steps may be removed, or added in an iterative manner. The first question to ask is, “What is the teaching value of this machine?” Let us think of a sample machine. Say, I want to teach the student on the following:

• Exploitation of common vulnerabilities in FTP servers, such as directory traversal.
• Web application enumeration.
• Web application exploitation through the uploading of a malicious file, bypassing some file upload checks.
• Privilege escalation arising from a misconfiguration of a cronjob (world-writable scheduled task!)!

One way I might approach this:

1. Install an updated Ubuntu kernel (an outdated kernel will simply leave us vulnerable to common exploits like DirtyCOW)
2. Spin up a FTP server vulnerable to directory traversal on the default FTP port (21). We can use Exploit-DB to allow us to spin up a sample vulnerable FTP server.
3. Because I want to teach enumeration through directory traversal, we need to locate a critical file in some common, default folder. In this case, we shall spin a LAMP stack. This time, because we want users to go through the directory traversal, we should perform the following steps:
   • Insert, in the FTP server, a set of credentials that should stand out, but not obviously. These credentials will be required for something user needs to do anyway, such as logging into the web application.
   • Modify the default listening port of the HTTP server. This is so that a quick nmap scan will not immediately pick up this HTTP server, which may affect the intent of this machine. Instead, house this away on a non-default port (e.g. could be 60080) by adjusting the httpd.conf file.
4. Install an appropriate web application with a file upload vulnerability. This should be simple.
5. Because the cronjob is world-writable, runs as root, there is no need to create additional users on the machine. The user of the web server (www-data or apache) can adjust such files.

The Test

Do not underestimate the test. Testing takes up far more time than planning. This is also where one’s hands get dirty, and one learns a lot from numerous failures. Common problems in this case include:

• Installing an application that does not meet the LAMP requirements we have, and in the process, introducing compromises.
• Misconfiguration of the server (e.g. failure to harden, over-hardened, too many distractions, too unreal-looking)
• Having machines that look too contrived. These merely make the attacker get infuriated that he has to look at everything without any concrete advancement.

This is, however, also the phase where one learns extremely quickly about the default file systems, applications, defensive measures that can be implemented. One example which I remember was how SELinux interfered in my privesc vector even though this was not specified by design. However, I had never touched SELinux from the perspective of a system administrator, and did not know it was silently handling my intrusion. It was a great learning experience understanding SELinux’s three main modes (enabled, permissive, disabled) and how they work.

Common integration problems happen as well. Examples include outdated PHP code for an application, often requiring something like PHP 5.6.36 instead of PHP 7. (common with older applications that may use functions that are deprecated in updated PHP versions)

Sometimes, we are, ourselves, not aware of the exact nature of the vulnerabilities we intend to set. These need to be tested extensively (simple payloads, more complicated bypasses). These will inform us of the appropriate difficulty of these exploits.

Use and Abuse

Now we need to check that our path indeed works. For such a box, a pentester could have done the following:

• Ran nmap on the machine, and find TCP ports 21 (FTP), 22 (SSH), 139 (NetBIOS), 445 (SMB) open. We can leave 22, 139 and 445 in the machine set-up because these are usually what we expect on many Linux installations — installation of a SSH daemon and Samba.
• Ran enum4linux to enumerate the SMB service, but is not allowed any null share. This is probably OK.
• Checked the versions of OpenSSH, the FTP server and Samba with searchsploit. Searchsploit informs that the FTP server is vulnerable to a directory traversal.
• Explore the directory traversal. The pentester uncovers important files like /etc/passwd, which tells him there are no additional user accounts. In the /etc folder, the pentester notes the existence of apache2. That would raise an alarm to the pentester because the nmap scan did not pick up the existence of a web server.
• Within the apache2 folder contains a password file.
• Read the httpd.conf file, and realised that the web server is hosted on Port 60080.
• Enumerate the web server and realise its vulnerability to a file upload function.
• Authenticate with valid credentials, that we obtained from the password file.
• Enumerate the web application and find the vulnerable file upload function.
• Test with uploading simple files, before uploading a .php reverse shell.
• Catch the reverse shell using netcat.
• Enumerate the system, and notice that there exists a cron-job running with root privileges. However, the cron-job is world-writeable.
• Fire a text editor, edit it to call a shell to our attacking machine.
• Set up a netcat listener once again, wait, and collect the root shell.

All well and good, except that, just like any other product, we must test for both use cases and abuse cases. Sometimes, incomplete understanding of the components, default or otherwise, that comes with our machine can lead to unintended shortcuts. Thus, a good machine is often cross-checked by others who have zero knowledge of the machine. They could find shortcuts, or overly permissive paths, ruining the learning value of such a machine.

What One Learns from Creating Machines

Blue-teamers and red-teamers benefit from added literacy of the Windows and Linux file systems, common configurations and misconfigurations associated with them. Experience often distinguishes between the script kiddie and the professional penetration tester or security auditor. Having experience through getting one’s hands dirty building up a machine is beneficial from both a technical and management angle. The technical side of us benefits greatly from better direct understanding. Creating vulnerable machines allows us to appreciate a complete understanding of whatever we may be deploying on it, with knowledge on what makes an application or service vulnerable and exploitable. This has downstream benefits. Later on, in one’s career, the tacit knowledge gained from strong technical foundations leads to quicker and more accurate management decisions.

So, where’s your machine?

https://www.vulnhub.com/entry/digitalworldlocal-mercy,263/. I hope to write a small series of vulnerable machines, for self-improvement, contribution to others, and if others find such challenges fun, I think I’d be contented as well.