[33977] in bugtraq
Multiple issues with Mac OS X AFP client
daemon@ATHENA.MIT.EDU (Chris Adams)
Fri Feb 27 13:56:24 2004
Mime-Version: 1.0 (Apple Message framework v612)
To: BUGTRAQ <bugtraq@securityfocus.com>, full-disclosure@lists.netsys.com
Message-Id: <C5A2A566-6949-11D8-9209-000A95703418@improbable.org>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12-811209911; protocol="application/pkcs7-signature"
From: Chris Adams <chris@improbable.org>
Date: Fri, 27 Feb 2004 09:24:17 -0800
--Apple-Mail-12-811209911
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=WINDOWS-1252;
delsp=yes;
format=flowed
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 =93Man in the Middle.=94 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).
=09
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
=09
References:
[1] =20
<http://developer.apple.com/documentation/Networking/Conceptual/AFP/>
[2] =20
<http://developer.apple.com/documentation/Networking/Conceptual/AFP/=20
Chapter_1/chapter_2_section_5.html#//apple_ref/doc/uid/TP30000196/=20
CHBJDAFE>
[3] <http://rsug.itd.umich.edu/software/fugu/>
[4] =20
<http://developer.apple.com/documentation/Networking/Conceptual/AFP/=20
Chapter_1/chapter_2_section_6.html#//apple_ref/doc/uid/TP30000196/=20
CHBBAGCB>
=
<http://developer.apple.com/documentation/Networking/Conceptual/AFP/=20
Chapter_1/chapter_2_section_6.html#//apple_ref/doc/uid/TP30000196/=20
CHDDAIFH>
[5] =
<http://www.codefab.com/unsupported/SSHPassKey_v1.1-1-README.html>
[6] =20
<http://www.omnigroup.com/mailman/archive/macosx-admin/2003-December/=20
034841.html>
--Apple-Mail-12-811209911
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Disposition: attachment;
filename=smime.p7s
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw
ggI+oAMCAQICAwsEJzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDMxMDI4MDkwOTAxWhcNMDQxMDI3MDkwOTAxWjBGMR8wHQYDVQQD
ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRjaHJpc0BpbXByb2JhYmxl
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKxclw61bSx4zLGr9+VBx5P7tdRz
PTMY/6MAwId9pj5vWcv8zQTL9e4PiqLnFTaHaH8KpOOOMpBVbUd8S2wTZTnjEK0nD9KIv7UFB3XY
qULYJZ2G+TN5Yy5ZHNRtCbObawKhPheNtDzXAmR/XwRqh7ef/R3hTMrtrxUBNWubRcgvmUX6zOEp
cqmH14yes6+RfhiuTBZ3xfkCmh6gmP8+8aXgd1xaiQV+0TSvflp2GZQZsy6+ajBhCbOjH+pzNjlp
ThrD53iY+MBLAtvsjT8mLDDdiabummGqZWeVtgkmL+qFUHL+9bc9H/0NIIOWcHnqmLm98In9Ys04
ALIpXLeqU00CAwEAAaMxMC8wHwYDVR0RBBgwFoEUY2hyaXNAaW1wcm9iYWJsZS5vcmcwDAYDVR0T
AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAfC78DQ26soziDOfB79TCceJLNMxfjsALAWWyrpdoq
PWl1m117uV2gusaTOsa1FDeRqPxHGXyYxzuWKTtz5FZhCXIvyEvkGu2E9CvVkcK0oYXxJigKB7bV
4KO+W531zvs/Uip5VkZfXisBEVfDdxGXUjyMJX4JHekBoJR0gAePizCCAz8wggKooAMCAQICAQ0w
DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl
cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe
Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla
HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688
Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg
t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6
Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB
BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF
BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13
41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK
ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQQIDCwQnMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDIyNzE3MjQxOFowIwYJKoZIhvcNAQkEMRYEFH1B
m3vjNTpAEtHvS9rtWRsvDVpmMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLBCcwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCwQnMA0GCSqGSIb3DQEBAQUABIIBACQq
XZfJxpfwcR2agpCNPPyNv+uciz+tBiEZTCRsZmOyYYj7JRgnab+QiT2EXFmwopqUeWbIv592fGG5
tMDW++5I0Zo38TMvxLLDxysl1DEaDC9wyy75oBlkJpcmX5S3/POAaASIKXDXLMbuub2Sho2aHxsL
8+wORsBEttiRUZKkdxPfC4dKsuUZIMHzSJ1naXmx+NKyfwHUZtW9vOX8/L1GgGnEuA6SMJj0LaWL
VmuzXe081BUAVrGA7V6+hx0DeAPOEjXV/c0ek2SCFBqbILW8kHSmUnp5u2P9jC/dqEt3eMbi7U5G
TvUtUpPvZcZvFJ4eeK6a5e/o3T2ETgwyPxwAAAAAAAA=
--Apple-Mail-12-811209911--
