Kali Linux CTF Blueprints

The purpose of this book may seem counterintuitive to the majority of practices that security professionals carry out each day, but most core ideas to create a secure machine are the same as those to create a vulnerable machine.

Servers can be thought of as being created to serve a specific purpose—for example, to provide DNS services, host an Exchange environment, or manage a domain. This idea can be applied to the practice of hosting vulnerable services as well. The aim is to expose the server in one very particular way and secure it in every other aspect. You may treat them as authentication methods for the overthinking masochists of the world if you wish; that may help you envision the end result a little more clearly. To that end, the following tenets should be abided by:

I realize that some people who like to break stuff haven't had experience in building stuff. In my experience, it should be a longer-term goal for any dedicated tester to get involved in some network architecture design (at the very least), sit through some app or program development, and above all, get scripting. Those of you who have taken time out of your busy, stack-smashing schedule and learned network design can skip ahead. Those who haven't, strap yourself in, grab yourself a router, and prepare to have your mind gently rattled.

The choice of vulnerability to host is one of the more difficult parts when it comes to making challenges. If the vulnerability is too easy, the challengers will tear through it; however, if the vulnerability is too hard, the majority of the target audience are alienated. To resolve this, I've provided some suggestions of vulnerabilities to host, marked for difficulty of setup and difficulty of exploitation. For reference, the following descriptions of difficulties are provided:

Adobe ColdFusion is the Adobe framework for hosting web applications. It's available for a 30-day evaluation trial, is easy to set up, and creates remotely accessible web pages—perfect for our purposes.

Many people enable Microsoft SQL Server (MSSQL) for personal projects from their work computers (I know that I run an MSSQL Server on my laptop 90 percent of the time). Unfortunately, some of those people leave the settings as default. As before, we're going to be using default credentials as the initial attack vector, but this time, we're going to follow up with some Metasploit action. This is a pretty standard scenario for beginners to run through.

Trivial File Transfer Protocol (TFTP) is an older service that presents blind FTP services to unauthenticated users. It was traditionally used to install lightweight, thin clients and transfer configurations from one location to another, similar to SNMP. Simply connect to the port, knowing the exact location of the file you want to copy, and copy away. The vulnerability here is that anyone who knows the kind of architecture hosting the TFTP service will be able to guess the location of sensitive files. There are numerous ways to make sure that TFTP is set up in a relatively safe way (though the lack of authentication does make it hard to justify), but that's not what we're after. We're after a nice vulnerable setup that we can chase down.

To start with, you need to decide which TFTP provider you want to use. You can score a double win here by selecting a build with vulnerabilities associated.

TFTPD32 2.2 is vulnerable to a buffer overflow, which can be a nice starting point for those beginning infrastructure tests and vulnerability assessments. For TFTPD32, there's an associated Metasploit module, and the version is disclosed in the headers, so a beginner can easily get a shell going. TFTPD32 also works on all architectures, is free, and provides older versions from their website. It is one of the best examples of a great resource for a CTF creator. It is available at http://tftpd32.jounin.net/.

Alternatively, you can enable the Windows TFTP solution through the Programs and Features and Enable Windows Features options for Windows 7 or equivalent options if running a different version. This has no known vulnerabilities to exploit with Metasploit or similar, but doesn't require hunting down to install.

Once downloaded, perform the following normal checks:

TFTP works by creating a socket directly to the folder you create it in. By default, it will be in a specific installation folder which only allows access to the installation files and README files. This can be set up as a basic exploit, if you wish, by placing a flag file in the folder; however, you would have to tell the attackers the name of the file, which defeats the purpose of this challenge and the vulnerability underlying in TFTP. In order to make it more interesting, try setting up TFTP in root C:\ or hunting down a version that allows directory traversal. TFTPD32 won't allow users to go up directories, but will only allow them to travel down into the depths of whatever folder structure you have, so moving from the install folder to the System32 folder isn't possible.

Run the TFTP solution in whichever folder you wish, and test it from a remote location. An exploit guide can be found at the end of this chapter.

If you're using TFTPD32, your configuration should look like the next screenshot. The Create "dir.txt" files selection is optional because seasoned testers will look for it immediately as it will give away the structure of the directory. If you want to make the challenge harder, turn this off. Have a look at the following screenshot:

Flags are useful because they provide definite objectives for your testers. The difficulty with flags is that while your testers need to be able to identify them, you should also want to simulate a real penetration test or hack as closely as possible. By this logic, a flag should be easily identifiable but not in your face. This can be handled carefully in a number of different ways, as mentioned in the following list:

Testing your flags

Test your flag by writing a brief and completing the challenge up until the point of needing to locate the flag. Then, grab someone nearby, hand them the brief, point them at the computer, and ask them to locate the file. Given a limited amount of knowledge about the system, they should be able to locate it based solely on the brief you gave them. If not, you need to rethink.

The following sections provide some examples and descriptions as to why they are inappropriate.

Making the flag too easy

To begin with, let's show a finding that is too easy. The following screenshot shows a flag (flag.txt) in the root C:/:

There are multiple problems with the placement shown in the previous screenshot. Firstly, the flag file itself bears no resemblance to a real-world file. A flag file can provide so much more than a simple objective. Second, it's in the root C:/—where the user would first be dropped in the event of a successful shell being launched, which means that the user wouldn't need to explore the filesystem at all.

Making your finding too hard

Where the first example was too obvious, this next example isn't nearly obvious enough! The following screenshot shows a flag saved as config.conf in a random hexadecimal subdirectory of the extensions folder of Firefox:

I understand the logic in obfuscating files, but this is simply time consuming and pointless. Firstly, the directory is so absurdly esoteric that without briefing that there is a Firefox extension that has sensitive data in it, a tester would not look there. Second, the file, though containing a unique string, is not obviously a flag. This will cause doubts in some cases and lead to unnecessary checking time for the test leader.

A folder of significance, such as system32, will work as a good placement with a file named to fit your scenario. The name Flag.txt simply isn't interesting. The names Finances.xls and Clients.docx, provided they fit the story you assign to your challenges, will serve well. In this case, they can be stored in My Documents without seeming forced or arbitrary.

The concept of post-exploitation is a skill that few get to practice on a regular basis, but in engagements, it's a core task that needs to be performed in the limited margins around tests. Pivoting is a matter of knowledge of operating systems and protocols that allow the hacker to bounce from machine to machine. Both of these skills help a tester to work out the extent of a vulnerability and better understand and articulate the risk associated with it. Consequently, it's important for scenarios to be created for testers to develop them. This can be performed in numerous ways as shown in the following list:

The following are the exploit guides for the scenarios created in this chapter. These are guidelines, and there are more ways to exploit the vulnerabilities.

We all have highfliers in our teams who complete challenges so fast we wonder why we spent our weekend setting them up. Challenging these types of people can be difficult, so here are some suggestions to keep even the most avid hacker busy:

In this chapter, we've covered Microsoft environments and the vulnerabilities inherent within them. The focus has largely been on third-party applications for this chapter due to the difficulty in finding out-of-date Microsoft operating systems and services on the Internet. If you own copies of Microsoft OSs or services, these are goldmines for the creation of vulnerable boxes to attack as they can present multiple exploits in one installation. Alas, I cannot guarantee that you have one or more outdated Microsoft installation(s).

We have gone through three scenarios covering Adobe ColdFusion, MSSQL, and TFTP. These vulnerabilities will allow new testers to get used to the Windows architecture, hone those well-needed Nmap and Metasploit skills, and also get a handle on regular services, SQL and TFTP, which have their own nuances to master. Also, this chapter has provided the framework for the later chapters to capitalize on. The sections on flag placement and design, post-exploitation and pivoting, and secure network creation will be referenced heavily throughout the rest of the book. In order to save time later, become comfortable with these ideas now.

The next chapter is Chapter 2, Linux Environments, a chapter which I'm sure you'll enjoy as we plumb the depths of SMB, tear up Telnet, and poke fun at Apache.