Mac OS X for Pen Testers

Mac OS X

for Pen Testers

Solutions in this chapter:

The OS X Command Shell

Compiling and Porting Open Source Software

Using the “Top 75 Security Tools” List Installing and Using the “Big” Tools Other OS X “Must Haves”

■ ■ ■ ■ ■ ˛ Summary

˛ Solutions Fast Track

Introduction

A penetration test (pen test) is a client-authorized simulation of an attack on a computer system or network. The purpose is to determine network vulnerabilities and repair them before a compromise occurs. Upon completion of this test, the tester produces a report outlining discovered weaknesses and provides detailed repair procedures. In some cases, a pen testing team will also assist in the defensive repair work, but most often this type of team focuses on offensive procedures. Once the network is repaired (or patched), the test is repeated at regular intervals, ensuring that the network remains secure. Pen testing is a lucrative, honorable, and highly technical profession. By contrast, mali- cious hackers perform unauthorized attacks against computer systems and networks. There is no report produced. There is no defensive patching performed unless the objective is to lock out other attackers. Although malicious hacking is highly technical and may be fairly lucrative, it is also highly illegal.

Malicious hackers and skilled pen testers have a great deal in common, however. While their motives differ, their actions are nearly identical. After all, the point of a pen test is to secure a network by properly emulating all permutations of a real attack. A home alarm system is ineffective if it fails to protect against every tactic of a burglar, and this holds true for network security as well. Because of this, malicious hackers and pen testers share a symbiotic relationship. The two are so closely related that they are often distinguished by only the color of their “hats”; pen testers are referred to as white hats and malicious hackers are referred to as black hats. In order to maintain their skills, black hats and white hats attend the same conferences, frequent the same digital hangouts, and practice the same digital hijinks. They congregate in person and online, speak the same lingo rife with acronyms and tech jargon, and trade code (computer programs) like little kids trade Pokemon cards. And although Hollywood has painted a specific picture of what a hacker looks like, those outside the industry would be hard-pressed to distinguish between the good guys and the bad guys at a large security conference. Many of the best and brightest hackers in the world are really quite normal-looking people in real life (IRL).

White hats and black hats alike take great pride in their skills and abilities, and in the content and capabilities of their software toolkits. These toolkits contain very specific programs, which, when run properly, produce effective results. This may seem fairly straightforward, but there is a great deal of debate (and personal preference)

about which tool is the best tool for the job. In this industry, however, there’s hardly ever a best tool for any job. There are usually many tools that can perform a port scan, for example, but nmap is regarded as one of the best. It’s entirely possible to pull off a perfectly good pen test without nmap, and most automated tools do just that. The point is that there are different strokes for different folks, and this is certainly true of the operating system (OS) you decide to use. While there is great debate amongst the hacker community as to which operating system is the best, the simple truth is that there really is no best OS, but rather preferred OSes for specific tasks. An adept pen tester or hacker can operate in just about any environment, regardless of operating system. The best pen-testing platform simply becomes a matter of personal preference. Mac OS X is an excellent choice due mainly to its robust, industry-accepted use of an underlying Berkeley Software Distribution (BSD)-based (UNIX) OS. Although many pen testers use Windows-based systems, the standard tools available with most UNIX OSes (like sed, awk, grep, PERL, and so on) have become “must haves” in the industry, forcing Windows users to find (or code) replacements for nearly all of these tools. Beyond the utilities included with the OS, the Linux community in particular has worked feverishly to create an absolutely stunning amount of UNIX-based software for just about any purpose imaginable. Most of this software is accessible to OS X users, although some of that software requires porting, or conversion, to OS X.

The purpose of this chapter is to reveal ways that OS X can be used as a platform for pen testing. This discussion will primarily focus on installing many of the popular pen testing tools, rather than the actual techniques and processes used during a pen test. We will begin this chapter by discussing Darwin, the core of the Mac OS X OS, and set the stage for installation of open source tools on Mac OS X. We will discuss the Mac OS X command shell and Terminal applications, the Apple Developer Tools, and the X Windows environment. Next we will take a look at methods of running software on, or porting software to the OS X platform, namely the use of direct compilation, DarwinPorts, and Fink. We will also take a look at the “Top 75 Security Tools,” available from www.insecure.org/tools.html. This list has become an industry standard list of must-have security tools, many of which will run on or have been ported to Mac OS X. Next, we will discuss a few must haves, namely Ethereal and Nessus, describing the process for installing each natively, as well as Virtual PC, which makes the complete library of Windows and Linux software available for the Mac.

The OS X Command Shell

We’ll start discussing juicier Mac hacking tools in short order, but it’s important to discuss the Mac command shell interface, and install the baseline utilities required to compile non-native programs on OS X. If you’ve never had any exposure to this side of Mac OS X, be warned. You won’t be seeing much of the sweet graphics you’ve grown accustomed to with OS X, but the path to true Mac enlightenment lies in letting go of the mouse every now and then. As shown in Figure 5.1, the command shell is entirely text-based. This interface may seem foreign to many “point-and-clickers,” but it enables access to the powerful heart and soul of the Mac OS X, the BSD subsystem.

The BSD subsystem is installed by default during a standard OS X install. After installation of the subsystem, you should have a file called BSD.pkg in the /Library/ Receipts directory of your hard drive. If you have performed a custom installation that bypassed the installation of the BSD subsystem, or the Receipts directory is

missing the receipt for BSD, you will need to install it from the OS X install disc before working with the command shell interface. Follow these steps to install the BSD subsystem:

1. Insert the Mac OS X CD or DVD.

2. Double-click the Install Mac OS X icon located in the root of the installation disk.

3. Click Restart to continue the installation.

4. After the system has rebooted, follow the prompts to the Installation Type phase of the installer.

5. Click Customize.

6. Select the BSD subsystem option.

7. Finish the installation by following the prompts.

Although the BSD subsystem consists of hundreds of programs and services, one of the most commonly used programs is Terminal, which can be found in the Finder’s Applications | Utilities folder. Double-clicking this icon will launch the Terminal program shown in Figure 5.1. When launched, the Terminal program displays the last login date, time, and terminal location, the message of the day, the hostname of the system, the current working directory, and a $ prompt. Running inside Terminal’s

window is a UNIX command-line or shell, specifically (under OS X 10.4) the bash shell.

Notes From the Underground

Mac OS X Family Tree

Historically, the Mac’s OS X was based on BSD UNIX of the early 1970s. Some design considerations were implemented from Carnegie Mellon University’s MACH OS as well, but the core of Mac OS X is most often referred to as Darwin. Darwin can function as a standalone (text-based) OS, but OS X adds many advanced capabilities such as Quartz Extreme (for 2D graphics rendering), OpenGL (for 3D graphics rendering), and the QuickTime multimedia architec- ture, to create a truly capable, unique, and powerful OS.

Although OS X ships with a wide variety of shell interfaces including the C shell (csh), the Z shell (zsh), and the ever-popular GNU Bourne-Again SHell (bash), each of these shells operates in a similar fashion; they each accept typed commands, and display the results of those commands back to the user.

Although the Terminal window may appear to be quite foreign, it is really nothing more than a standard UNIX interface to OS X commands. For example, running open /Applications/TextEdit.app/ from the Terminal will launch the TextEdit program. Although the command is run from inside the Terminal window, TextEdit runs exactly as if it were launched from the dock or the Finder.

Most UNIX users recognize the familiar $ prompt, which is an indicator that the shell is logged in as a standard user. By default, the shell is logged with the permissions of the user that launched the Terminal program, in this case, the johnnylong user. The vast majority of commands can be run as a standard user, but some commands, especially system administration commands, require a higher level of access. This is handled through the use of a root, or superuser account. Like most versions

of UNIX, Mac OS X has a built-in root user that can be accessed in a number of ways.

Notes from the Underground

Bash Auto Complete

The bash shell has many handy features, but the auto complete feature may be one of the most popular. Auto complete is triggered with the Tab key. After pressing Tab, auto complete will attempt to finish the text you started typing. If the letters you typed were specific enough, auto complete will finish typing the command for you. Otherwise, if the letters you typed were not specific enough, auto complete will offer suggestions for that command each time you press Tab. For example, to fly through the command go to open /Applications/ TextEdit.app/, type open /App, then press Tab to complete the name of the / Applications directory. Since this was the name of a directory, auto complete will finish typing the name of the directory and place a slash after the name. Next, type Tex and press Tab to auto complete the name of the TextEdit.app directory. Simply press Enter to execute the command. In this example, less than half the keystrokes are required to execute the command.

Typically, the su command is used to invoke a root-level shell, and it’s not uncommon for first-time Mac users to attempt to su to the root user, but OS X does not ship with an enabled root user.

While it is possible to enable the root user and set a root password with the sudo passwd root command, this is generally frowned upon, and is unnecessary. Most system administration functions on OS X can be performed via the sudo command (or by visiting the built-on OS X configuration programs like System Preferences), and a root shell can be spawned with the sudo su or sudo bash command without actually enabling the root user account. It’s a generally accepted security practice to have as few enabled accounts as possible, and despite OS X’s very solid security posture, it’s best not to tempt fate. Leave the root user disabled, and get accustomed to using sudo whenever possible!

Once the Terminal program has launched, take a moment to relish in your geek- ness! You’re now sitting in the real Mac OS X driver’s seat, interfacing with the Mac’s BSD UNIX-styled shell. Even mundane tasks like manipulating text files take on a whole new edge when performed from the shell. Any decent Mac OS X hacker has shell skills, and this is where the magic happens. Time spent learning your way around the shell will ultimately pay off in increased productivity, and an appreciation for what all the grizzled UNIX vets have been raving about for years. Although we can’t possibly cram a decent shell tutorial in this chapter, any decent UNIX book will have at least one section devoted to basic shell usage. Mac OS X’s help system includes some basic information about the BSD subsystem (try searching for “BSD” or “UNIX” in Mac help), but OS X also includes standardized UNIX manuals via the man (manual) command-line program. The “M” in the term RTFM (“Read The Friggin’ Manual”) most likely refers to the UNIX manual program, and RTFM is very good advice for the novice UNIX user. If you’re unfamiliar with the UNIX bash shell, for example, look at its man page by issuing the man bash command. The man program itself even has it’s own man page, which can be accessed via the man man command. Either way, take some time to learn your way around the Mac’s command shell before jumping into more advanced topics.

Compiling and

Porting Open Source Software

Many veteran Mac users relish the look and feel of the very slick OS X interface. The interface is intuitive, uncluttered, and when mastered, makes life so much easier.

Not every software developer writes Apple-specific software, but a large majority of developers these days write freely distributable open source software under the GNU General Public License. Much of this software is written for the UNIX platform, and in most cases, this software can be installed and run under Mac OS X thanks to its UNIX BSD roots. In most cases, this software will not have the slick look and feel of native OS X software, but there are hundreds of specific tasks that many technical users perform that are just not possible without the use of open source tools.

Before reaping the benefits of any piece of software, you’ll first need to get that software installed. If you’re lucky, the developer has taken the time to code the software specifically for the Mac. In this case, the developer often makes a disk image (.dmg) file available, which can be simply downloaded and executed. This type of installation is a very simple point-and-click affair. Unfortunately, most open source tools are not distrib- uted this way. There are two other options for getting the software up and running. The first option is to compile the software from source code, or human-readable format into a format the computer can understand and execute. This requires the use of a compiler, and is often prone to error, as many programs of this type are designed to work on fairly specific platforms, like Linux. A second option involves installing preconfigured ported (modified) software from either source or binary (ready to run) packages. We’ll take a look at the latter two options in fair detail, but we must first install some software to facilitate porting.