BugTraq
APOP vulnerability Apr 02 2007 03:13PM
gaetan leurent ens fr (GaŽtan LEURENT) (1 replies)
Re: APOP vulnerability Apr 03 2007 08:22AM
3APA3A (3APA3A SECURITY NNOV RU) (1 replies)
Re: APOP vulnerability Apr 03 2007 04:18PM
gaetan leurent ens fr (Gaëtan LEURENT) (1 replies)

3APA3A wrote on 03 Apr 2007 10:22:12 +0200:

> While it's really a weakness in APOP protocol, I don't share opinion
> this attack is practical, because there are few factors:

I meant practical in the sense that it does work in practice (it's not
an attack needing 2^80 computations or something like that), but I don't
know what are the practical implications of the attack :-)
(to begin with, I don't know if many people are using APOP).

Anyway, I think it should be enough to
1. discourage use of APOP.
2. ask mail software to be more careful about the message-ids.

> First, it requires stable _active_ Man-in-the-middle attack, that is
> ability to spoof replies from and to server. Under this condition
> attacker can do a lot of harm without APOP, e.g. inject malware into
> content of trusted web page or even attempt to spoof certificates for
> encrypted protocols.

Well, first, an active man-in-the-middle attack is easy to do in an open
WiFi network, for instance. I think an attack against a mail protocol
is more realist than an attack against a web page because many people
configure their mail software to check for new mail on a regular basis
(sometimes as low as 1 minute). It is also much easier than injecting
something into a web page because you only have to redirect the
connections to one particular server (and you can easily find out which
one with a little sniffing).

> Additionally, under these conditions (challenge is choosen by
> attacker) rainbow tables can be used against APOP. Using rainbow
> tables seems more practical for 8-character password.

Good point. However it seems that rainbow tables for 8 characters
password are only practical when limited to lowercase password (plus
numeric).

> Second, under these conditions attacker already has access to the
> mailbox content. After session is authenticated, attacker can inject any
> commands and retrieve any message, even if it's not requested by the
> client.

Yes, in the man-in-the-middle setting, the attacker has an easy access
to the mailbox. But the password should still be secure.

> Cleartext password gives no additional information for the
> attacker, unless the same password is used for something else. In case
> of APOP it's not likely same password is used for something else,
> because this authentication is 1. only used in POP3 and, 2. unlike CRAM-
> and DIGEST- authentications, server must store cleartext or reversable
> password.

That's true. I don't know how many people use APOP with a password that
is also used somewhere else, but I guess most people are not paranoid
enough to have a different password for every account...

> Third, during this attack client can not authenticate with a server. In
> case of active MitM, attacker can hide this fact from the client by
> making false positive response showing an empty mailbox. Depending on
> mailbox usage, it may be detected by the client that messages are
> delayed, even if you allow 50% of authentications to pass.

The attack can be done while the user is not reading his mail, but the
software is checking for new mail periodically. Then he won't notice
anything when he is back.

--
Gaëtan LEURENT

[ reply ]
Re[2]: APOP vulnerability Apr 03 2007 04:50PM
3APA3A (3APA3A SECURITY NNOV RU)


 

Privacy Statement
Copyright 2010, SecurityFocus