Multiple issues with Mac OS X AFP client Background The standard Apple Filing Protocol[1] (AFP) does not use encryption to protect transfered data. Login credentials may be sent in cleartext or protected with one of several different hashed exchanges or Kerberos[2]. There does not appear to have been any serious third-party security review of Apple's client or server implementations. Mac OS X 10.2 introduced the option of automatically tunneling connections to an Apple file server over SSH - a commendable effort to reuse a well-understood, tested protocol rather than another home-grown design. Unfortunately the current implementation is marred by significant design and implementation flaws. A Backwards Handshake All AFP connections start with a connection to TCP port 548. If enabled the client may subsequently attempt to start an ssh session depending on the server's advertised capabilities. The decision to treat SSH tunneling as a protocol extension leads to several undesirable outcomes, most critically that the user interface gives the impression of using SSH (which has a very good reputation) but provides no way to have a connection fail if SSH cannot be used rather than failing down to a normal insecure AFP connection. In the educational world it is common for AFP servers to be exposed to the general internet to allow users to work remotely. Given AFP's lack of extensive auditing and use in high-security environments it would be preferable for the current design to be reversed and all traffic to be tunneled over a heavily audited protocol such as SSH or SSL. SSH is in many ways preferable given the common habit of configuring non-public SSL services with self-signed certificates and instructions to disable validation. A man-in-the-middle attack can easily be used to collect passwords. Since AFP does not attempt to validate the server's identity it is possible to mount an active attack where the MITM host does not advertise SSH sessions. At this point we run into the next major problem: the client does not distinguish between any of the non-cleartext authentication mechanisms despite significant security implications. The protocol designers were clearly aware of this threat as noted in the protocol documentation for both Diffie-Hellman authentication systems[4]: 'DHX2 is strong against packet sniffing attacks but vulnerable to active attacks such “Man in the Middle.” There is no way for the client to verify that the server knows the password, so the server could easily be spoofed. There is some weakness in using fixed initialization vectors, p and g, which is alleviated by putting the random nonces first in the encrypted portions of the messages. DHX2 is useful when the server requires passwords in cleartext.' Unfortunately the user interface makes no distinction between this and the more secure Random-Number Exchange systems. Combined with the common tendency for users to store passwords in their Keychain or blindly enter them when prompted an automated password collection system could easily be developed and with a relatively modest amount of additional work it could avoid detection by transparently proxying the connection to the real server. Given both the environments where Macs are most commonly used and Apple's aggressive marketing of OS X Server as easy to administer it seems extremely unlikely that the administrators would be monitoring at the level needed to detect this. Implementation Problems In versions of OS X 10.3 prior to 10.3.2 the SSH feature simply did not work: the client will silently connect without attempting to use SSH at all The current design is limited to volumes shared with the server version of OS X. The user interface provides no way to require SSH or warn that while the option is selected it will not be used because the server does not support it. Currently the user must notice that the separate "Opening secure connection" window did not appear and realize that this implies a non-SSH session. The user interface makes no attempt to differentiate between the non-cleartext authentication mechanisms. It would be useful to permanently disable anything other than, say, a hashed exchange or Kerberos. ssh is started with "-o StrictHostKeyChecking no" which makes the SSH session used for file sharing uniquely vulnerable to MITM attacks. This is probably due to the lack of a graphical interface for the usual host key dialogs. Workarounds Use manually-configured SSH tunnels (e.g. ssh -aCN -L 5480:afp-server:548 remote-host) Forgo AFP if possible in favor of SFTP, optionally with a graphical front-end such as Fugu[3] The AFP client may be hardened somewhat by modifying the .GlobalPreferences.plist (the AFP client does not follow Apple's guidelines for preference files). defaults write "Apple Global Domain" com.apple.AppleShareClientCore \ -dict-add \ afp_authtype_show -bool true \ afp_ssh_force -bool true \ afp_ssh_require -bool true Unfortunately this does not prevent MITM attacks and introduces potential support issues because a failed SSH connection will be reported as a bad username/password. Leon Towns-von Stauber reports that Apple is working with him on a bug preventing the current SSH implementation from being used in certain cases. Recommendations SSH should be enabled by default for the file server on both server and client and both the client and server interfaces should strongly encourage its use. The client should allow the user to require SSH and restrict the authentication mechanisms allowed. The client needs a graphical interface for the normal SSH precautions against MITM attacks. A future version of OS X should provide a standard framework which developers could rely on to get a decent GUI to handle host key management and an equivalent for the traditional ssh_askpass similar to similar to Bill Bumgarner's SSHPassKey[5]. Beyond these basics Apple should encourage accepted security best-practices by providing a utility to simplify the process of setting up public key authentication and either provide seamless Keychain support or an integrated ssh-agent. History: Tue Dec 16 09:35:52 10.3.0-10.3.1 client bug reported by Leon Towns-von Stauber[6] December 19, 2003 22:04:11 PST Initial vendor email December 23, 2003 11:06:30 PST Followup email February 26, 2004 0:19:35 PST Pre-release notice to Apple containing this advisory and offering to delay release if requested Vendor Response: None References: [1] [2] [3] [4] [5] [6]