full-disclosure - User Enumeration Flaw

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200602182341.k1INffln021426@turing-police.cc.vt.edu>
Date: Sat Feb 18 23:42:04 2006
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: User Enumeration Flaw 

On Sat, 18 Feb 2006 17:03:20 EST, Mar.Shatz@...cation.gov.il said:

> helo jojo

Lack of a fully qualified domain name.

> 250 esgeop03.whitehouse.gov Hello [xxx.xxx.xxx.xxx], pleased to meet you
> mail from:bob@....com

mail from:<bob@....com>

> 250 2.1.0 bob@....com... Sender ok
> rcpt to:gbush@...tehouse.gov

rcpt to:<gbush@...tehouse.gov>

Their SMTP server would have been totally within its rights to throw a '501
syntax error' due to the lack of < > characters.  Given that at this point they
have yet to see a command that's correct both syntactically and semantically,
and they're still talking to you, they've obviously decided to try to be as
helpful as possible, rather than being totally strict hard-asses about it.

Of course, they're being self-serving here.  They can either give you a '550
user unknown' reply if the mailbox doesn't exist, or they can give you a '250
user OK' and then try to issue a bounce later - and given that at that point
we're batting 0 for 3 for correct commands, the chances that the MAIL FROM:
will actually work as a bounce destination are slim indeed.

So they get to choose between the small information leak that the 250/550
replies create (said information being extractable via *other* means in most
cases anyhow), or not allowing the leak and getting stuck with the almost
inevitable double bounces that will result.  Obviously, they consider the
security risk of DoS via flooding of double-bounces to be larger than the risk
of leaking information to something that can't get basic SMTP syntax correct...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060218/30d6c4b1/attachment.bin