> Date: 2005-06-11 03:04 > From: "Christian Huitema" <huitema@xxxxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf