lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 03 Apr 2007 18:18:04 +0200
From: gaetan.leurent@....fr (Gaëtan LEURENT)
To: 3APA3A <3APA3A@...urity.nnov.ru>
Cc: bugtraq@...urityfocus.com
Subject: Re: APOP vulnerability


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ