The Mac Hacker's Handbook - Part 2(3-4-5-6 главы)

Attack Surface

When looking for vulnerabilities or trying to secure a system, the first step is always to consider what parts of the system are exposed to attackers. This exposed part of a system is called the attack surface. In this chapter you will learn to look at the Mac OS X system and determine the code available to attackers, including attackers able to send packets to the system in question (server-side attacks) as well as attackers who can convince a Mac OS X user to connect to them with some piece of software (client-side attacks). Special consideration will be given to applications and pieces of the operating system that are exposed out of the box or by default in Mac OS X.

Searching the Server Side

There are many interesting services and listening ports on Mac OS X Server. Because so few computers in the world are running this operating system, however, this book will stick to looking at the attack surface of the standard Mac OS X.

At the lowest level, Mac OS X processes network traffic. That is to say, there may be bugs lurking in the IP stack in the operating system. Out of the box, Mac OS X consumes TCP, UDP, ICMP, and other types of packets. Since this low-level code is based on FreeBSD, it will probably be tough to find a vulner¬ability in it, but you never know. Besides the wired protocol stack, there are

also the drivers associated with Bluetooth and the wireless card. The associ¬ated code was all written by Apple, so perhaps there are vulnerabilities to find in it. Recall the big 2006 scandal in which David Maynor and Johnny "Cache" Ellch allegedly found some bugs in the MacBook wireless drivers that allowed them to take over any MacBook remotely. While the validity of this story was never confirmed, the best thing about attacking at these lowest levels is that if it works, you automatically get root.

Since not everyone is into kernel-level bugs and exploits, the more obvious place to look is at the applications that run in Mac OS X. In other words, look for the open TCP and UDP ports and determine what applications are associated with them. Out of the box, not many things are exposed to remote attackers. The command in the following code snippet will list the processes that are listening by default.

$ sudo lsof -P | grep IPv | grep -v localhost

ntpd 14 root 20u IPv4 0t0 UDP *:123

ntpd 14 root 21u IPv6 0t0 UDP *:123

ntpd 14 root 26u IPv4 0t0 UDP 192.168.1.4:123

mDNSRespo 21 _mdnsresponder 7u IPv4 0t0 UDP *:5353

mDNSRespo 21 _mdnsresponder 8u IPv6 0t0 UDP *:5353

configd 33 root 8u IPv4 0t0 UDP *:*

configd 33 root 11u IPv6 0t0 ICMPV6 *:*

SystemUIS 87 cmiller 9u IPv4 0t0 UDP *:*

cupsd 601 root 9u IPv4 0t0 UDP *:631

By examining the output, you can observe there are no open TCP ports. There are three open UDP ports, however, which have ntpd, mDNSResponder, and cupsd listening, respectively. Configd and SystemUIServer are not bound to any particular port. The Network Time Protocol daemon, ntpd, is a well-known open-source server. cupsd is the daemon responsible for printing on many UNIX systems. It too is a well-known open-source server; however, the Common Unix Printing System (CUPS) has a long history of security bugs. Looking closer at the lsof output in the code example shows that cupsd is listening only on the external interface on UDP port 631. This implies that only a small subset of the functionality of CUPS is exposed by default (for instance, the administrative web interface is not accessible). The remaining service, mDNSResponder, is the only one of the three that is written by Apple and not widely used.

Because mDNSResponder is the only Apple-written daemon that processes packets out of the box, the previous chapter looked briefly at the protocol used by it, as well as some of the source code from it. Apple is committed to having Bonjour running out of the box on their systems, but they have done what they can to mini¬mize the resulting exposure. First, Bonjour doesn't run as root, but rather as the unprivileged _mdnsresponder user. Even more critically, though, this program is run within a tightly controlled sandbox. ntpd is also run in a sandbox. (Curiously, cupsd is not.) The following is the sandbox file for mDNSResponder.

непереводимые исходники

This code uses a deny-by-default policy. It does allow arbitrary network con¬nections to and from the application. The main restriction is that it carefully controls which files can be read and written. Therefore, even if you could run arbitrary code within the application, you couldn't do many interesting things. A similar sandbox exists for ntpd. These sandboxes (if implemented correctly) effectively remove these applications from consideration by an attacker, or at the very least, make exploitation much more challenging.

There is one caveat to the sandboxes. The sandbox prevents the program in the sandbox and any of its children from doing anything interesting. It does not prevent them from passing data to applications that are not in a sandbox. This is one way it might be possible to escape from such a sandbox. Consider the following scenario. A system advertises, via the Bonjour protocol, that a new printer is available on the network. mDNSResponder notifies CUPS (not in a sandbox) to add the printer. If there is a vulnerability in the way CUPS adds printers, you have just gotten access to a nonsandboxed application through the mDNSResponder sandbox!

Taking all of this into consideration, if you're looking for a server-side attack against a stock install of Mac OS X, your best bet is probably something like wireless drivers or a UDP-only attack against CUPS.

Before we conclude this discussion, please note that sometimes client pro¬grams open up ports which then become susceptible to remote attack, even if the user doesn't connect to the attacker. iTunes is an example of this. When iTunes is launched, it listens on port 3689 (DAAP). This is the port iTunes uses for sharing music files. The interesting thing is that iTunes opens and listens on this port even if it is not configured for sharing music. The difference between music sharing being on and being off is that when it is off, iTunes doesn't do much on that port. The following shows that with music sharing disabled, but iTunes running, it still listens on a port.

$ lsof -P | grep iTunes | grep LISTEN

iTunes 7662 cmiller 17u IPv4 0x5e0da68 0t0 TCP *:3689

(LISTEN)

However, the following is an exchange between a DAAP client and this port when music sharing is off.

GET /server-info HTTP/1.1 TE: deflate,gzip;q=0.3

Keep-Alive: 300 Connection: Keep-Alive, TE Host: localhost:3689

User-Agent: libwww-perl/5.813 HTTP/1.1 501 Not Implemented

Date: Thu, 28 Aug 2008 01:39:15 GMT

DAAP-Server: iTunes/7.7.1 (Mac OS X) Content-Type: application/x-dmap-tagged Content-Length: 0

In this case, iTunes returns a 501 error regardless of the input. However, it still offers the possibility for an attacker to have the Mac remotely process some data that relies only on the user having the iTunes process running.

Nonstandard Listening Processes

By accessing the Sharing pane in the System Preferences, users often turn on other services; see Figure 3-1.

The first option listed is DVD or CD Sharing. This option shares out the user's DVD or CD drive to the subnet. This service is advertised using Bonjour and resides on some

Картинка 3-1

$ dns-sd -B _odisk._tcp Browsing for _odisk._tcp

Timestamp A/R Flags if Domain Service Type Instance Name

20:37:29.601 Add 3 9 local. _odisk._tcp. Charlie Miller's

Computer

In this case, a look at netstat reveals that a new port has opened on 63378. Following up with lsof, we can see what application has been spawned by acti¬vating this option in the Sharing pane.

$ sudo lsof | grep 53358

ODSAgent 40560 root 3u IPv6 0x3e78984 0t0 TCP *:53358 (LISTEN)

It is /System/Library/CoreServices/ODSAgent.app. This program basically uses an HTTP-based protocol, but it does some authentication; see Figure 3-2.

Картинка 3-2

The client grabs what appears to be a .dmg or .iso image, whose name was provided by the server in the initial response. Within the data, you can see things like names of directories and files; see Figure 3-3.

The next item from the Sharing pane is Screen Sharing. This simply opens a VNC server on port 5900 and a Kerberos server on port 88. The Kerberos server is the standard krb5kdc application and is opened by the operating system the first time it is needed. The VNC server is AppleVNCS. If you notice this running on a Mac, you may want to look for bugs in it.

Next is the File Sharing option. This opens a server on port 548 (afpovertcp). Looking at lsof, you see that launchd is listening on that port. That doesn't tell you much, though, because like inetd/xinetd, launchd hands off inbound con¬nections to another application.

Картинка 3-3

To see what will be launched, look in the LaunchDaemons directory for configuration files containing the afpovertcp port.

$ cd /System/Library/LaunchDaemons/ $ grep -h -B 11 afpovertcp *

<key>ProgramArguments</key>

<array>

<string>/usr/sbin/AppleFileServer</string> </array>

<key>Sockets</key> <dict>

<key>Listener</key> <dict>

<key>Bonjour</key> <true/>

<key>SockServiceName</key> <string>afpovertcp</string>

You see that AppleFileServer is the application that will be launched.

$ /usr/sbin/AppleFileServer -v afpserver-530.8.3

AppleFileServer speaks Apple Filing Protocol (AFP), which functions much like the Network File System (NFS) protocol used by many UNIX systems, or the Server Message Block (SMB)/Common Internet File System (CIFS) used by Windows systems.

Графический элемент

Launchd will launch /usr/libexec/cups/daemon/cups-lpd on port 515 (printer, and /user/sbin/smbd (netbios-ssn 139, microsoft-ds 445). CUPS will now listen on the external interface. If the client is sharing a printer, the avail¬able attack surface becomes quite large.

The Web Sharing check box enables a standard Apache service on port 80. The webroot for this installation is at /Library/WebServer/Documents and the CGIs are in /Library/WebServer/CGI-Executables. By default, the CGI directory is empty, so no help there for an attacker.

The Remote Login option is a standard OpenSSH handled by launchd. The binary is at /usr/sbin/sshd. As of the writing of this book, the version string is OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006.

The final option we'll discuss is Remote Apple Events. There are a few other options available in the Sharing pane, but they are relatively obscure or benign. Remote Apple Events enables the AEServer handled by launchd on port 3031 (eppc). This server allows remote users to run AppleScript programs on the computer running the AEServer. For example, on another computer, start the script editor (/Applications/AppleScript/Script Editor.app). Enter the following into the editor:

set remoteMac to "eppc://user:password@MachineName.local"

using terms from application "Finder"

tell application "Finder" of machine B

get name of every disk

end

end

When that code is executed, it will return the names of the disks from the computer that is allowing remote Apple events. Note that this server does require authentication. That doesn't mean there couldn't be a pre-authentication bug, though!

Cutting into the Client Side

The attack surface when attacking Mac OS X clients is much larger than when restricting yourself to the server side. Any application that accesses the Internet is a potential target (as are many that don't). Mac OS X is founded on the principle that things should be easy for the user; they should just work. For an attacker, this means the operating system is designed to handle a large number of formats and protocols automatically. For example, Safari will view just about any file format you can imagine. The key to determining the client-side attack surface is to understand exactly what types of files and protocols each applica¬tion is willing to consume. And understanding that relies on understanding the relationship between the applications and the files they process.

Each application has an Info.plist file that declares the known URL protocols, extensions, MIME types, and file types the application can handle. In Mac OS X, LaunchServices is responsible for determining what application is associ¬ated with a given file type or extension. An application will get registered with LaunchServices whenever it is first put on disk and its Info.plist file is processed. Note that, typically, downloading an application from the Internet will present the user with a warning, which prevents an attacker from automatically regis-tering application associations without the user's knowledge.

The prototypical client-side application is Safari, the default web browser in Mac OS X. Look at its Info.plist file, which you can find at /Applications/Safari. app/Contents/Info.plist. What follows is the beginning of this file.

plist

The first important key is CFBundleDocumentTypes. This indicates the types of documents supported by the bundle. In this case it is an array of such types. The first is a CSS style sheet. This type of document has a file extension of .css and a MIME type of text/css. Based on the CFBundleTypeRole, Safari is regis¬tered as a viewer of this type. The next entry in the array is a PDF document, for which Safari is also a viewer.

The following list reveals what each key means in the CFBundleDocumentTypes array.

CFBundleTypeExtensions: The file name extension for the file

CFBundleTypeIconFile: The icon in the bundle that Finder should associate with the file type

CFBundleTypeMIMETypes: The MIME type for the file

CFBundleTypeName: The text that will be shown in Finder to describe the file

CFBundleTypeRole: Specifies whether the program can open (Viewer), open and save (Editor), or is simply a shell to another program

LSIsAppleDefaultForType: Specifies whether the bundle should be the default application for this type

As we mentioned earlier, LaunchServices compiles all of this application information and stores it in a database. Querying this database, for example, determines what application is launched when a file is double-clicked in a Finder window. This database can be viewed by the lsregister program, as seen in the following output.

$/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks /LaunchServices.framework/Versions/A/Support/lsregister -dump

Checking data integrity done.

Status: Database is seeded.

...

The information from Info.plist is seen in the database. A graphical tool called RCDefaultApp (http://www.rubicode.com/Software/RCDefaultApp/) queries the LaunchServices database and presents the information in a more coherent form; see Figure 3-4.

Картинка 3-4

In this figure, RCDefaultApp indicates that any file with the extension ".atr" will be opened by the QuickTime Player. This particular file format is not used very often and therefore the code may not be well tested. Such obscure file formats can be fertile grounds for fuzzing; see Chapter 5, "Finding Bugs." RCDefaultApp can be used to find the application for each file format that the operating system recognizes.

Safari

Safari is the most feature-rich web browser in existence. Features, of course, require code, and additional code increases the attack surface. In this section you will see how to determine all the functionality accessible to an attacker when a Safari web browser visits the attacker's website.