Chapter 1. Microsoft Environments

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

Creating a vulnerable machine

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 aims require it, ensure that any other services that you require to run on the system are fully patched and up to date.
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.

Securing a machine

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.

Note

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.

Creating a secure network

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.

Basic requirements

A network needs some basic things to function:

A switch/hub
More than one networkable device

That's essentially your network right there. Technically speaking, you don't even need more than one device, but that setup would be a little pointless for our purposes.

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.

Setting up a Linux network

To set up networking on a Linux device, perform the following steps:

Plug the device into the hub/switch.
Open a terminal.
Type ifconfig eth0 10.0.0.124 or whichever local subnet you wish to use.
Congratulate yourself on a job well done.

Setting up a Windows network

To set up networking on a Windows device, perform the following steps:

Plug the device into the router/hub/switch.
Open a command line.
Type 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.

In order to test the connection, simply open a terminal on either device and ping the other host. For example, ping 10.0.0.2 should respond with a long stream of returns as any good ping should.

Hosting vulnerabilities

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:
- Simple – This level of difficulty requires installation of the affected software
- Moderate – This level of difficulty requires installation of the affected software on a specific operating system
- Complex – This level of difficulty requires installation and configuration of the affected software on, specific operating system

The following are the various levels in difficulty of exploitation:

Simple – This level of difficulty requires the use of out-of-the-box tools
Moderate – This level of difficulty requires configuration and the use of out-of-the-box tools or simple scripting to perform exploits

Complex – This level of difficulty requires the creation of complex scripts, else it is not supported by common exploitation tools

Vulnerable package	Difficulty of setup	Difficulty of exploitation
Adobe Flash Player	Simple	Moderate
Oracle Java JRE	Simple	Moderate
Internet Explorer	Simple	Complex
QuickTime	Moderate	Complex
ColdFusion	Simple	Simple
TFTP	Simple	Simple
MSSQL	Simple	Moderate

Scenario 1 – warming Adobe ColdFusion

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.

Setup

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:

Run the .exe file to install the program, and use the defaults as you go along.
Make sure you perform the following steps:
1. Set Adobe ColdFusion 9 to host as a self-contained application as the following screenshot shows:
2. Set the application to run a built-in server, as shown in the following screenshot:
3. Set default credentials throughout as shown in the following screenshot, and make a note of them:
4. Check the Enable RDS option as shown in the following screenshot:
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.
To test the installation, browse to the server. The default will be port 8500, so http://127.0.0.1:8500 should provide the installation directory, as the following screenshot shows:

Variations

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 C:/BankDetails.txt.

Then, name the computer such that it has something to do with John. John-PC works for me over JohnBoy or 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.