It makes sense to kick off this book with the most prevalent operating system in business. I'm sure the majority of penetration testers will agree that though both Linux and Windows have their benefits, the industry still falls heavily on Microsoft to provide the brunt of servers. Microsoft has provided testers with some of the most reliable vulnerabilities over the years, and I know that I'm always happy to see an MS reference whenever a scan completes.
By the end of the chapter, you should know at least three types of scenarios and have some idea about how to vary them for repeated tests. The chapter will aim to be as interactive as possible and follow-through as much as possible. In detail, we will cover the following topics:
The creation of basic vulnerable machines
A selection of suggestions for vulnerabilities to host
In-depth setup of a vulnerable Adobe ColdFusion installation
In-depth setup of a misconfigured MSSQL server
In-depth setup of TFTP
Flag setup and variations
Post-exploitation and pivot options
Exploitation guide for all three scenarios
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:
Unless the scenario requires it, a proper antivirus solution with a firewall should be in place to secure other services.
Run the scenario on a separate network to any production or sensitive systems. This is quite simple to achieve by setting up a new network on a LAN connection without Internet access or through the use of virtual machines.
Virtual or physical, your machine needs to be secure, and there's a simple process to achieve this. Build a fresh operating system. This is easy with a LiveCD when you have a spare Windows OS, but that's not always possible. At the time of this writing, TechNet provides 180-day accounts of the Windows operating system for testing purposes (technet.microsoft.com), which covers this style of usage. If you are using this book to kick off a future career in CTF building, consider getting a Microsoft Developer Network (MSDN) account, which will enable you to set up multiple environments for testing purposes.
At this point, if you're aiming to host a vulnerable Windows product, don't perform the following step.
So, you have a fresh install—what now? Ensure everything is up to date. As you don't have anything other than the OS installed, you should just run Start | Search | Windows Update. Let it run, finish, and restart. Have a look through your build and remove any unnecessary programs that may have come with the install. You are now working with a clean slate. Wonderful.
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.
A network needs some basic things to function:
More than one networkable device
If you are performing these tests for a single individual, be it yourself or someone you trust with the device you're building these vulnerable builds on, you can just host them on the device through the VM solution.
Plug the device into the hub/switch.
Open a terminal.
ifconfig eth0 10.0.0.124or whichever local subnet you wish to use.
Congratulate yourself on a job well done.
Plug the device into the router/hub/switch.
Open a command line.
netsh int ip set address "local area connection" static 10.0.0.2 255.255.255.0 10.0.0.255.
Close all the screens.
Congratulate yourself slightly more than the Linux user; they had it easy.
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:
The following are the various levels in difficulty of setup:
The following are the various levels in difficulty of exploitation:
Difficulty of setup
Difficulty of exploitation
Adobe Flash Player
Oracle Java JRE
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.
First, take your freshly installed or sanitized Windows installation and download Adobe ColdFusion 9. There are newer versions available from adobe.com, but we will be working with version 9, which you can download from http://download.macromedia.com/pub/coldfusion/updates/901/ColdFusion_update_901_WWEJ_win64.exe. Now, perform the following steps:
.exefile to install the program, and use the defaults as you go along.
Make sure you perform the following steps:
Set Adobe ColdFusion 9 to host as a self-contained application as the following screenshot shows:
Set default credentials throughout as shown in the following screenshot, and make a note of them:
Go through with the final stages of the setup by logging on to the application through your browser. Make a note of the port that you're accessing it through; this will be the port that should be accessible remotely if the software is correctly set up.
There are a few vulnerabilities that can work here. First, the RDS login method can be attacked through a Metasploit module to gain an administrative login. This can be used to get a remote shell. Alternatively, default credentials can be used as the vulnerability, and a directory traversal can be used to gain the key.
To place a
.flag file for the directory traversal, create a
.txt file, or a file in any other format based on what you want it to be, and place it in a directory. As the directory traversal can only call specific files and not print directories, you will have to provide the attackers with the path in brief.
First, work out the scenario you want. It can simply be: find John's PC and exploit the common web weakness to find his bank details. I hear he keeps them in
Then, name the computer such that it has something to do with John.
John-PC works for me over
LittleJohn, which make it easy for the attacker to identify it. Create the
BankDetails.txt file, and place the file in the correct folder.
Once everything is set up, you have to test it and prepare the brief for the attackers. To test, please see the exploitation guide further along in this chapter.
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.
We are going to create an MSSQL Server instance on your host, and then open it up to external access. We'll go through it step by step so that it's nice and easy. You will need MSSQL Server 2005 Express and MSSQL Management Suite to complete this. There are newer versions of MSSQL available, but the use of MSSQL Server 2005 is intentional, as it grants more options for attacks. Perform the following steps:
First of all, download MSSQL Server 2005 Express from http://www.microsoft.com/en-gb/download/details.aspx?id=21844. Follow the standard process until you hit the Authentication Mode screen, which is shown in the following screenshot:
It's important to set this to Mixed Mode (Windows Authentication and SQL Server Authentication) and set the credentials to something guessable. For this example, I've used
sa:sa. These are the most common default credentials for SQL Servers on the planet. If your flag captors don't guess this, send them packing. Complete the installation by phoning it in; everything else should be clicked through.
Second, download MSSQL Management Suite 2008. This is available from the Microsoft site at http://www.microsoft.com/en-gb/download/details.aspx?id=7593, and again, free! I've saved you literally dozens of your currency of choice so far. You'll want to follow the standard installation procedure and then set up a MSSQL database in the following manner:
.exefile, select Installation, and then select New SQL Server stand-alone installation or add features to an existing installation. In the following screenshot, this is the topmost option:
Proceed with the installation; click through until you reach the choice of installation. Select the Management tools – Basic option—everything else is unnecessary. The following screenshot shows how it should look:
Once all the options have been completed, boot up SQL Server Management Studio and log in with the credentials you set earlier (
sa:saif you used my choice). You should be presented with a screen showing the standard layout of a SQL Server. This proves that the server is running.
Finally, before going away and giving the server a good kicking, open SQL Server Configuration Manager, browse to SQL Server Network Configuration (32bit), and then browse to TCP/IP. Double-click on TCP/IP, and make sure that the port you want to run MSSQL on is completed in every network adapter that you want in the TCP Port option, as shown in the following screenshot:
Nmap is a network mapping tool that is installed by default on Kali Linux. What it does is that it attempts to connect to ports on a host and returns whether they are open or not. The exploit guides contain specific strings to use when attacking, but the following are useful for now:
Windows Firewall is disabled or an exception is made for MSSQL.
Any antivirus is turned off. The Meterpreter payload we will be using is essentially a Trojan, so any antivirus that isn't just pretending to be secure will pick it up.
MSSQL is configured to listen on the port you selected previously. Run
netstat –ato check.
As a last resort, put your desired port in the
IP ALLoption in the server configuration tool.
Once it's up and running, you have some choices. If you have the time, you can populate some data as red herrings (or as the objective of sub-challenges if you wish). As you'll find in Chapter 6, Red Teaming, it's useful to have these kinds of things hanging around to make the scenario feel a bit more real. These can also be scripted quite easily to generate fluff data. Alternatively, you can leave it as a test environment and leave the scenario as attacking a developer in progress.
When you're satisfied that you've made it lifelike enough, roll out your Kali box and smack that MSSQL installation around a bit. The guide to this is, again, at the end of this chapter.
Your brief is once again important. The suggestions here are:
Collect X records from a MSSQL database using default credentials
Exploit a vulnerable MSSQL database using Metasploit and a common web vulnerability
Gain a foothold on the box running MSSQL
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:
Make sure Windows Firewall or other such solutions are off
Make sure any antivirus is off if you intend to let testers use Metasploit
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.
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:
There are multiple briefs available for this scenario dependent on which files you wish to host:
SSH keys could be stored for use in further scenarios
Credentials for other boxes
Access to hashes on older OSs that are crackable
The key thing to remember when setting up a TFTP-related scenario is that the attackers will not be able to see which files are present or which folder they are in. This means that barring any default answers as shown in the exploit guide, they are unlikely to know what you've hidden there unless you give them clues. This can be set up as part of a larger exercise and is shown in situ in Chapter 6, Red Teaming.
This particular vulnerability can easily be set up on Linux, if required, by using a different installation. There are many TFTP packages for Linux; it's just a matter of picking one that suits you.
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:
Location: You can place the file in a directory commonly associated with loot. I mean, sensitive files is a good way to go. This will teach your testers good habits while also not taxing their brain cells excessively. Examples are shown in the next section.
Filename: The name
Flag.txtis self-explanatory, but there is a thing called too little imagination.
John D. Objectiveare examples of making things a little less obvious.
Obfuscation: Hiding the flag in another form works well in substitute for time to set up a set of dummy files; for example, hiding the flag in the Exif information of a picture. A guide to this can be found in Chapter 4, Social Engineering.
Cryptography: Flawed encryption methods can be used to add an extra challenge to a CTF. For extra information, go to Chapter 5, Cryptographic Projects.
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.
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.
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
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.
Credentials make good targets as they represent normal penetration tests. Using these will teach the testers to check SAM files, databases, and other files that may contain credentials. There is a list of likely places in the next subsection.
Descriptions of background images can be quick ways to solve the issue. A sample question would be: Describe the desktop background of XXX.XXX.XXX.XXX.
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 first example is providing a method of privilege escalation and making the flag only accessible to an administrative user. It's not hard to find software with privilege escalation vulnerabilities present as they are often ignored due to not being network accessible. Meterpreter will provide privilege escalation for the uninitiated, and bespoke methods can be used by the more skilled testers. To make it even simpler or possible in a case where a shell is limited, provide admin credentials in saved e-mails or files, and a legitimate method of authentication. This will show testers that exploitation isn't the aim of a test, as some may think, but discovering the associated risk. (If you need an easy sell, taunt anyone resting on their laurels with the age old phrase: "Got root?")
A second method is providing a secondary stage to the scenario resulting from things taken from the device. The application of cryptographic tools or scenarios detailed later in Chapter 5, Cryptographic Projects, will present extra challenges to even the most skilled testers. Hunting through an operating system for relevant details, keys, or snippets of information potentially describing the method used, or the method to be used, can be an engaging and educating experience.
Pivoting through providing credentials for other devices, certificates, or SSH keys can allow you to chain scenarios together, making a more realistic scenario. Though most clients will be reluctant to allow testers full access to their networks, they will often be curious about the risk an exposed service provides and provide an exemption for these circumstances. The last thing you want to happen here is for your tester to balk at the thought.
The final option encourages the tester to attempt to install their tools on the compromised machine to enable further testing. This is the true meaning of pivoting in a Subvert, Upgrade, Subvert (Su-Su) cycle (this is a joke more entertaining, marginally, for Linux users).
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.
The brief provided for this exploitation guide is assumed to be:
Use the common web framework vulnerability to capture the RFLAGG's finances spreadsheet from his documents directory.
So, first of all, we boot up Netdiscover or Nmap to discover/map the hosts on the network. We then use Nmap once again to enumerate the ports on the host and look at the output. We look for an output that either defines the PC as belonging to a variation on RFLAGG or a web framework that may be vulnerable. You can see in the following screenshot that there's a high port running as an HTTP server:
The great thing about this scenario is that the vulnerable package runs on a high port, which means that a user who only runs quick Nmap scans won't find it.
Browse to the site in the browser of your choice, and you're presented with the screen we saw earlier when we were setting up the ColdFusion installation. (It should be the
ColdFusiondirectory; that wasn't a trick.)
This looks vulnerable in itself, containing installation files, so we can make a note of it and move on. There's an
admindirectory, so we click on that, and we are presented with a login page.
A quick Google search shows that ColdFusion doesn't appear to have package-specific default credentials, and so we try the following standard ones just to be sure:
If one of these credentials has been set, we have passed the first step and gained administrative access to the web framework.
If they haven't, checking the version will show that RDS can be used for a login without credentials as they are blank by default on earlier packages. We can also find that there's a Metasploit module for this (
exploit/multi/http/coldfusion_rds) that can deliver Meterpreter payloads. If you take this route, Meterpreter will carry you the entire way in a canoe, and the usage of Meterpreter is found in the next exploitation guide.
We'll assume here that we've taken the first route and found that the default credentials had been set. While browsing around, we can see there is limited functionality, but there are some rather suspicious-looking URLs, as shown in the following screenshot:
That looks vulnerable to the might of URL-based directory traversal. By supplying a directory that goes up as well as down the directories, as shown in the preceding screenshot, we can potentially access sensitive files. So, in this example, we're going to go after the Excel sheet with RFLAGG's finances in it. We supply the following URL:
Network-facing installation pages and administrative portals
Directory traversal vulnerability in ColdFusion
The brief provided for this exploitation guide is assumed to be:
Using a vulnerable database, become an administrative user on The Wizard's computer and describe the desktop picture.
The following are the steps to be performed for this scenario:
The first step is to profile all of the devices using Nmap and locate one matching
The Wizardas a description.
Then, use Nmap to enumerate all the open ports, preferably with
-Ato detect the currently running service, as shown in the following screenshot:
Using the inbuilt username and password list for MSSQL, we can test default credentials pretty quickly, as shown in the following screenshot:
The module you want is
exploit/windows/mssql/mssql_payload, which (provided the antivirus isn't on the box) will give us a Meterpreter payload on the box. It needs to be configured as shown in the following screenshot:
The preceding screenshot sets the Metasploit values as:
METHOD = cmd
PASSWORD = sa
RHOST = the target
RPORT = 1433 (default for MSSQL)
USERNAME = sa
USE_WINDOWS_AUTHENTICATION = false
The payload is in and you are in. Experiment with Meterpreter; there are many things it can do. It takes a lot of time to become fully familiar with the tool and learn what's appropriate in different situations.
To satisfy the flag conditions, we need to view the wallpaper. In order to do that, we will need to secure a graphical login, so the easiest method will be to enable remote desktop. We launch the server and change the password to enable a login.
The vulnerabilities shown here are:
Default MSSQL credentials
Lack of antivirus on hosts
Use the vulnerable service to extract the user Jay Bacon's secret file stored at C:/Bearnaisesauce.txt.
The following are the steps to be performed for this scenario:
First, identify the live hosts on the network with a ping sweep. On Kali Linux, there are two straightforward options: Netdiscover and Nmap. Netdiscover will use a combination of ARP traffic and ping sweeps to identify the live machines. It presents this data as shown in the following screenshot and is a generally reliable form of host discovery:
However, since Nmap is useful for port identification anyway, you can use the
-Pnoperator to perform a ping sweep on the range given.
Once the host(s) is/are identified, the next thing to do is to ensure that it is the targeted host. An aggressive scan with Nmap will identify the ports open, the services running, fingerprint the device, and also retrieve the name of the computer. If the name matches the brief, such as
JayBacon, or something similar, we know we're on the right track.
The standard output of a Windows 7 machine without a firewall enabled looks like the examples we've seen before, except this time there are no vulnerable services. Junior testers may scratch their heads (but Nmap finds everything!), but they need to scan for UDP ports. A quick search of the top 1,000 UDP ports (
nmap –sU<IP>) will show that port 69 is open.
After a quick Google search, your testers will find that TFTP runs on port 69/UDP. TFTP, we know, is accessible with the
tftpcommand from the Kali terminal, and so we connect.
There's no way to know which folder TFTP is built into. So, the methods we try are:
get ../../../../../../../ Bearnaisesauce.txt
get C:/ Bearnaisesauce.txt
The file should be retrieved and the challenge is completed.
The vulnerabilities shown here are:
TFTP in use
TFTP in use in a privileged folder
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:
Tool restrictions – Established vulnerabilities are likely to be supported by Metasploit modules or at least have proof-of-concept code floating around in the wilderness. This fits environments and testing scenarios where clients have requested tests be performed from the perspective of regular users or to simulate an internal attack.
Time – While time restrictions are the obvious solution to challenging someone, it's not really applicable in real life. The necessity for speed is present in a testing environment, but it is a soft skill. The ability to detect and exploit with skill is a far more valuable trait to nurture.
Fun ones – Play random noises or get them to listen to Barney the Dinosaur (though I cannot be held responsible for any long-term psychological damage caused by this action). While it may seem childish, testers should be able to perform in uncomfortable and strange environments. Most of the time, it'll be sitting in a cold server room with only the sounds of fans to keep you company (the blowy kind, not the "we love you!" kind), but who knows where you may end up.
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.