AppleTalk Security Secrets

by Steven Kreuzer  (skreuzer@mac.com)

By most accounts, Apple clients and servers make up a small portion of the types of systems on any given network.

However, Apple hardware and software have carved out a niche in certain areas such as design and multimedia along with the educational field.  AppleTalk networks do exist.  It is just that hackers and system administrators tend to overlook them.

In mixed environments, the network managers tend to be highly proficient with UNIX or Windows NT but don't know, or care to know, about how AppleTalk networks actually work.  They will take the minimum steps necessary to ensure that Apple clients can connect to network resources and once that is complete all is well and good.

However, this lack of understanding can be used as a possible entry point into your network.  This article was written using a Power Mac G4 running Mac OS 9.2.2 and a dual-processor Power Mac G4 running OS 9.1 and AppleShare IP 6.3.3.  It will address potential security holes and what you can do to harden both the client and server side of an AppleTalk network.

We will start off by examining the client side and one of the most common problems which also plagues other network protocols as well.

Older Macintosh clients connecting to servers will send their password in cleartext across the network.  It is also possible that the server will force the client to send their password as cleartext if it does not support other authentication algorithms.  (Windows 2000 with AppleTalk support will do this.)

This is one of the easiest problems to fix, and you have two very good solutions at hand.  The first is to download an updated version of the AppleShare client that is available at www.apple.com/appleshareip/text/downloads.html

The second solution is a little more complex.  If you open the AppleShare client in ResEdit and locate the FSMNT resource you will see a sub-resource labeled ApShare Mounter.

Open up that resource and do a search in ASCII for Cleartxt.  Once found, replace the C in Cleartxt with any other letter.  Once that is complete, do the same for the ApShare ExFS in the EXFS resource.

Once that is complete, save your changes and move the file back into the Extensions folder on the client machine.  This will prevent the user from sending their password in cleartext.

Another problem is allowing users to save their login name and password.  This creates an alias to the file server located in the "Servers" boots up, it will mount all file servers listed in that folder.  This can become a problem if an attacker has physical access to a client machine.

It is possible to modify the AppleShare client so that the Save My Name and Password feature is disabled.  A patch for that is available at: homepage.mac.com/skreuzer

The last problem I will address on the client side is personal file sharing.

Every Mac OS since version 7.0 has the ability to allow the end user to share his or her hard drive and allow remote connections.  Most of the time when a person enables file sharing they don't assign a password to the system owner, thus allowing remote logins with full read and write privileges to the entire hard drive.  Or a person will share the entire hard drive rather then make share points and give regular users read and write privileges to the whole hard drive, including the System folder.

This will allow an attacker access to vital system resources and also exposes things like preference files which can contain passwords used by different applications.  It would also be possible to install a Trojan or virus that will execute upon next start-up by placing the file in the Startup Item folder.  An attacker with malicious intent could erase certain parts of the hard drive, or the entire hard drive.

To prevent this from occurring, you can remove the File Sharing Extension from the Extensions folder in the System folder.  This will remove the ability to start personal file sharing.

On both AppleShare IP servers and Macintosh workstations running personal file sharing store usernames, passwords and group data in a file called Users and Groups Data File which is located in the Preferences folder of the System folder.

The encryption algorithm is very simple and it is possible to decode passwords stored in this file.  AppleShare IP does not allow you to share the System folder, so unless an attacker had physical access to the server or was able to execute a Trojan on the server side, you should not have to worry about the trivial encoding scheme used.  macfspwd.c, the UNIX utility to decode the password is available from happiness.dhs.org/software/macfspwd/macfspwd.c

The perceived simplicity of AppleShare IP (ASIP) makes it appealing to novice administrators who typically have little appreciation for security.  Out of the box, ASIP is very secure but certain steps can be taken to harden the out of the box configuration.  One of the biggest drawbacks of ASIP is its inability to keep access logs.  (The web and mail server do log activity, but file sharing does not.)  It is possible to get a list of users currently connected to the server, the connection method, and when they logged on, but this data is not written to any file so once they log off, all this information is lost.

ASIP makes the enumeration of valid usernames a trivial task due to the fact that security was sacrificed for ease of use.  When you use the AppleShare client to log onto a server, the return result from the server can be used to brute force valid usernames.

When an invalid username is entered, the server responds with a kOAMErrMemberObjectNotFound (error 29312) which translates to "The specified group member does not exist in the Registry," but when a valid username with an invalid password is sent, the server responds with kOAMErrAuthenticationError (error 29360) which translates to "Sorry, the password you entered is incorrect."

With this it would be possible to write a script to read in usernames from a file and mimic the login process and parse the result to brute force enumerate valid usernames.  To protect yourself against this, make sure that the server disables accounts after multiple failed login attempts.  With this feature and a secure user password in place, brute-forcing becomes much more difficult, if not impossible.  The drawback is that ASIP only allows you to configure the minimum characters in a password.  You are unable to force a user to mix numbers and letters, and you are unable to "blacklist" certain words like password.

The final topic I will address in this article is related to user authentication.  The algorithms for all of the AppleShare authentication methods are public.  The most widely used authentication method is 2-way random that sends two 8-byte DES encrypted random numbers over the network.

From a computational standpoint the algorithm is exactly as strong as 56-bit DES and it has a password length limit of eight characters.  It is vulnerable to an offline password guessing attack similar to running crack against a UNIX password file.  Apple has developed a new authentication method that addresses the weaknesses of 2-way random, called DHX.  DHX uses Diffie-Hellman Key Exchange to create a 128-bit session key and then sends a 64-character password to the server encrypted with CAST-128.  Its strength is approximately equivalent to 128-bit SSL.

I have only scratched the surface of the numerous potential vulnerabilities of AppleTalk networks.  in reality, on a well-configured AppleTalk network, it can be incredibly difficulty to bypass security.  But certain tools and techniques can create access paths into your systems.

I hope this article has sparked an interest, and system administrators will take a closer look at their networks.

Return to $2600 Index