Date: 2005-06-11 03:04
From: "Christian Huitema" <huitema(_at_)windows(_dot_)microsoft(_dot_)com>
Steve Bellovin was alluding to the "evil twin" attack on wireless
network. Allow me to elaborate.
The technique allows an attacker to lure unsuspecting travelers to
connect to an un-protected wireless network under the attacker control.
Very often, laptops are programmed to fetch pending e-mail as soon as
they connect to a network. The laptop will try resolve
"mail.example.com", and start a POP3 or IMAP exchange. The attacker
controls the DNS service on the wireless network, and will easily spoof
the server. It will then respond to the connection with a CRAM-MD5
challenge, and harvest the e-mail address of the victim as well as the
answer to the challenge. The attacker is now in a position to obtain the
e-mail and password pair for the victim. The attack lasts a few seconds,
and may not require any particular action by the victim.
Thank you, Christian; we now have a concrete description of a specific
problem.
There is however, a subtle difference between POP3/IMAP and SMTP as
used by the draft under discussion. POP3/IMAP authenticate a user as
authorized to access the contents of one or more mailboxes, whereas
SMTP involves a client host and a server. [while SMTP provides for
specification of a mailbox (for delivery notifications), during multi-
hop transfers that mailbox remains unchanged as the message is
transferred from client to server/client to server, so is not usable
for authentication of a client host]
For the "evil twin" problem, the following seem to apply to SMTP:
o the client cannot be certain of the server's identity. This seems
to be characteristic of the SMTP protocol; the client identifies
itself, but the server does not (at least not other than in optional
text which is (a) easily forged and (b) specifically required to be
disregarded by the client)
o the "evil twin" could harvest client (host) identity and credentials,
that would allow the "evil twin" to spew spam and malware as if it
were the client
o the "evil twin" could harvest mailbox information (but not access
credentials) from SMTP MAIL FROM and RCPT TO commands, and could
collect or modify any unencrypted message (header and body)
content
o TLS doesn't seem to help, as the "evil twin" can certainly use TLS,
either on port 465 or via STARTTLS on either port 25 or 587 to lure
the client into revealing host credentials; worse, it may give
message senders a false sense of privacy if message content is not
encrypted by a separate mechanism such as S/MIME or PGP/MIME.
o As I understand it, control of DNS does not appear to be necessary.
The "evil twin" is in effect a man-in-the-middle, which can "proxy"
the application protocol between the traveler's host and the
legitimate remote server, both for collection of information and
for modification of application-layer content. That could, for
example, be implemented as port-based TCP filtering without the
need to affect DNS transactions. Specifically, even if the
traveler uses a hard-coded IP address of the SMTP server, the
"evil twin" can intercept the session data.
[the assumption in the above analysis is that the attacker can use an
access point implemented as or connected to a router, rather than as
a pure bridge, and that the network configuration behind the AP is
not easily determined by the victim]
o Again, as I understand it, the mode of access need not be wireless;
the same sort of "proxying" could take place via any sort of
network connection (e.g. wired Ethernet connections as provided
by some hotels)
o On a wired network implemented via hubs (as opposed to switches),
eavesdropping is of course possible by third parties. TLS may be
effective against that case and the one immediately below.
o unprotected wireless access opens the communications to attacks
other than man-in-the-middle by eavesdroppers.
o even protected wireless access (for some unspecified meaning of
"protected") is susceptible to attacks by an unscrupulous provider
o Even "protected" wireless access is susceptible to man-in-the-
middle attacks; there exist wireless APs implemented as routers
which are capable of operating in multiple modes, including
as a type of range extender. Firmware modification could
provide for eavesdropping or content replacement or session
redirection, and a no-firmware-modification implementation
could tie two units (one acting as an access point, the other
operating as an AP client to the genuine access point), providing
the man-in-the-middle attacker with access to data via the wired
connections between the two APs.
IETF protocols should not endorse the use of unprotected
challenge-response mechanism. They certainly should not lure clients to
accept challenges from unauthenticated servers.
Has either been codified in an approved RFC (BCP or otherwise)?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf