Message-ID: <C5A2A566-6949-11D8-9209-000A95703418@improbable.org>
From: chris at improbable.org (Chris Adams)
Subject: Multiple issues with Mac OS X AFP client

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]  
<http://developer.apple.com/documentation/Networking/Conceptual/AFP/>
	[2]  
<http://developer.apple.com/documentation/Networking/Conceptual/AFP/ 
Chapter_1/chapter_2_section_5.html#//apple_ref/doc/uid/TP30000196/ 
CHBJDAFE>
	[3] <http://rsug.itd.umich.edu/software/fugu/>
	[4]  
<http://developer.apple.com/documentation/Networking/Conceptual/AFP/ 
Chapter_1/chapter_2_section_6.html#//apple_ref/doc/uid/TP30000196/ 
CHBBAGCB>
		<http://developer.apple.com/documentation/Networking/Conceptual/AFP/ 
Chapter_1/chapter_2_section_6.html#//apple_ref/doc/uid/TP30000196/ 
CHDDAIFH>
	[5] <http://www.codefab.com/unsupported/SSHPassKey_v1.1-1-README.html>
	[6]  
<http://www.omnigroup.com/mailman/archive/macosx-admin/2003-December/ 
034841.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040227/12ea88f5/smime.bin

Powered by blists - more mailing lists