FW: [Full-Disclosure] Multiple issues with Mac OS X AFP client

[Howell, Paul]

-----Original Message-----
From: full-disclosure-admin@lists.netsys.com
[mailto:full-disclosure-admin@lists.netsys.com] On Behalf Of Chris Adams
Sent: Friday, February 27, 2004 12:24 PM
To: BUGTRAQ; full-disclosure@lists.netsys.com
Subject: [Full-Disclosure] 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>

------------------------------------------------------------------------
To unsubscribe from netsec, send mail to majordomo@merit.edu
with a body consisting of the words "unsubscribe netsec" --
without the quotes. For more help, send a message to majordomo@merit.edu
with the word "help" as the body.
------------------------------------------------------------------------