AppleShare Encryption Security Flaw Discovered
Computer safety firm SecurityFocus has discovered a highly specific but important flaw in Apple’s use of encrypted connections for AppleShare, as well as flaws in the way passwords are managed and encryption keys are confirmed. For certain users, these flaws may require that they bypass some of Apple’s built-in security and encryption options in favor of more robust or less convenient methods. Apple has not yet responded to the report.
AppleShare via SSH — When you connect to an AppleShare server (running Personal File Sharing or a Mac OS X Server) you can choose to connect via SSH (Secure Shell), which encrypts the password, all file transfers, and other data between your machine and the AppleShare server. This connection requires that Remote Login has been enabled on the AppleShare server.
The SSH option, first supported correctly in Mac OS X 10.3.2, creates an encrypted link between a Mac initiating an AppleShare file server connection and a Mac server running Mac OS X 10.3 or Mac OS X Server 10.3. The AppleShare client on the initiating Mac connects via the Remote Login service, which is Apple’s name for SSH. To enable or disable Remote Login, open the Sharing preference pane and click the Services tab.
The SSH option for AppleShare is only available when connecting to an AppleShare volume. Using Connect to Server in the Finder, select a volume or enter a host name or other address. When you click Connect, the login window offers an Options button. Click Options and check the Allow Secure Connections using SSH option. You can set this option as a default. (To learn more about AppleShare file sharing under Panther, you can consult my book, "Take Control of Sharing Files in Panther.")
Four Thousand Holes in Blackburn AppleShare — The primary flaw in AppleShare’s use of SSH is simple: if a secure connection via SSH cannot be made to the AppleShare server, the connection is still made without the encrypted tunnel – and without warning. This means that if you were expecting to send your password and file transfers through an encrypted connection, you would be sending this information in the clear without knowing it.
The SecurityFocus item was written by Chris Adams, a developer at the Salk Institute who also noted a number of serious problems with Apple’s approach to encrypting passwords in AppleShare as well. Some of these flaws require a cryptographer’s understanding, but that shouldn’t understate the concerns of academic institutions and others who rely on AppleShare for encrypted passwords or encrypted connections.
In most SSH systems, an SSH client is prompted on its first connection to an SSH server to confirm the server’s identity. This is performed through fingerprinting: the client software shows a short sequence of numbers that uniquely prove the server’s identity. An astute user checks that fingerprint against one provided for them by a server’s operator or server software "out of band": by phone, graphically on the server’s screen, by fax, or some other method that’s not over the same connection. At the very least, if the fingerprint ever changes, the user is alerted that the server might have had its identity spoofed.
Adams points out that Apple uses a lax method of SSH key exchanges for AppleShare sessions that avoids this complexity, but also makes it possible for a man-in-the-middle attack, so called because a network attacker could install server software on the network that would masquerade as the AppleShare server a user wanted to connect to. Because the user doesn’t confirm the identity of the server at the fingerprint level – and Apple doesn’t provide a facility for this in AppleShare – the man in the middle can act like the server to the client and the client to the server, effectively harvesting user names, passwords in the clear, and other data, while transparently relaying information between AppleShare clients and the real server to hide its own existence.
Adams suggests that Apple provide warnings when an SSH connection is not available to allow a user to opt out of accidentally creating an insecure connection. He also suggests that Apple provide a graphical interface for SSH messages that would allow a user to accept and associate encryption keys with known AppleShare servers. This would prevent a man in the middle from successfully fooling an AppleShare client into thinking that it was the server itself.
Apple could follow PGP Corporation’s lead in allowing server encryption key fingerprinting while avoiding the complexity of working with hexadecimal digits (the way such keys appear). PGP’s software for encrypting messages and virtual disks lets you confirm another user’s PGP key by assigning unique words to each hexadecimal number from 0 to 255. My fingerprint for my PGP key, for instance, starts "soybean drunken stormy uncut Oakland," very much like Beat poetry.
Until Apple chooses a new approach for making its SSH connections actually secure, those of you who use it need to consider three options: make strong efforts to ensure your network’s integrity, switch to virtual private network (VPN) software (well handled in Mac OS X 10.3 and Server 10.3), or create individual SSH tunnels. None of these solutions is ideal, since they take more effort than just checking a box in the current system.