Re: spoofing of local email sender via a homoglyph attack

[Solar Designer <solar () openwall com>]

On Thu, Apr 23, 2020 at 07:03:14PM +0300, PromiseLabs Pentest Research wrote:
> I am not sure that the "from" header applies to user probing, as the 

You mean the MAIL FROM aka envelope-from.

> actual mail server configuration on which I'm testing would accept any 
> user as a sender:
>
> # nc -v *** OMITTED *** 25
> Connection to *** OMITTED *** 25 port [tcp/smtp] succeeded!
> 220 *** OMITTED *** ESMTP Postfix
> mail from: userdoesnotexists () target com
> 250 2.1.0 Ok
> rcpt to: test () target com
> 550 5.1.1 <test () target com>: Recipient address rejected: User unknown in 
> local recipient table
> rcpt to: j??hn.doe () target com
> 550 5.1.1 <j??hn.doe () target com>: Recipient address rejected: User 
> unknown in local recipient table
> rcpt to: existing.user () target com
> 250 2.1.5 Ok
>
> However, a non-existing user would not be accepted in the "rcpt-to" 
> header, so this is another possible vector. This was discovered while 
> doing a black box test on one of our clients, and it should be noted 
> that the VRFY command has been enabled on the server, hence there was no 
> reason to look for another way. However I'm unaware whether disabling 
> VRFY would alter this behaviour. As you can see, the reported issue 
> itself is may be actually due to the possibility of relaying a local 
> email from a non-existing user.
>
> Having said this, if not then I assume then you are correct, in case we 
> take the "to" header into consideration in relation to user probing, 
> unless I'm missing your logic.

I actually meant probing via the "Sender address rejected: not logged
in" messages, which while delivered in response to a RCPT TO depend on
the MAIL FROM address.  However, as Wietse tells us this merely probes
the smtpd_sender_login_maps table, so is very limited and
configuration-specific.  Besides, as Wietse and you correctly remind us,
the possibility to probe for valid addresses via RCPT TO is in practice
unavoidable on modern Internet.  So the point of blocking probing of
which sender addresses can vs. can not (do not need to) authenticate is
moot given that in typical setups those addresses are also potential
recipient addresses and thus could also be probed via RCPT TO.

What you reported originally, where you bypass something that just
happens that way in some configurations and wasn't meant to provide any
security against sender address spoofing, looks like even less of an
issue to me.

Does anyone see any reasonable action on these (non-)issues?  If not, I
think the CVE should be rejected.  It's a case of "works as intended."

> > > > > > Use CVE-2020-12063.

Alexander