oss-sec mailing list archives
Re: spoofing of local email sender via a homoglyph attack
From: Solar Designer <solar () openwall com>
Date: Thu, 23 Apr 2020 20:12:34 +0200
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
Current thread:
- spoofing of local email sender via a homoglyph attack PromiseLabs Pentest Research (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack Solar Designer (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack PromiseLabs Pentest Research (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack Solar Designer (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack PromiseLabs Pentest Research (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack Solar Designer (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack Jeremy Stanley (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack John Haxby (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack PromiseLabs Pentest Research (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack Wietse Venema (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack Solar Designer (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack Claus Assmann (Apr 23)
- Re: spoofing of local email sender via a homoglyph attack Stuart D. Gathman (Apr 23)