Re: spoofing of local email sender via a homoglyph attack

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: spoofing of local email sender via a homoglyph attack

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: PromiseLabs Pentest Research &lt;pentest () promiselabs net&gt;

Date: Thu, 23 Apr 2020 19:03:14 +0300

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
I am not sure that the "from" header applies to user probing, as the 
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 &lt;test () target com&gt;: Recipient address rejected: User unknown in 
local recipient table
rcpt to: j??hn.doe () target com
550 5.1.1 &lt;j??hn.doe () target com&gt;: 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.

---
PLPR:
Plamen Dimitrov
Penetration Tester, CEH &amp; OSCP certified

Promise Solutions LTD
Penetration Testing and Managed Security services

https://www.promisedev.com
https://www.promiselabs.net
+359 883 22 05 12

On 2020-04-23 18:14, Solar Designer wrote:
On Thu, Apr 23, 2020 at 05:32:15PM +0300, PromiseLabs Pentest Research 
wrote:
To follow up on your questions:

Thanks!  Now this is specific.

The current configuration actually blocks any non-authorized requests 
as
explained in the description. The use-case of this (from my 
perspective)
is that it could be used to advance a social-engineer attack into
tricking the recipients believing that they are getting an email from 
a
high-level position at the company.

It's related to the from header.

Issuing a regular unauthenticated request, trying to send an email 
from
john.doe, which is a high-level user at the company:
$ nc -v *** OMITTED *** 25
Connection to *** OMITTED *** 25 port [tcp/smtp] succeeded!
220 *** OMITTED *** ESMTP Postfix
mail from: john.doe () server com
250 2.1.0 Ok
rcpt to: existing.user () server com
553 5.7.1 &lt;john.doe () server com&gt;: Sender address rejected: not logged 
in

As you can see, the mail server rejects the request as the existing 
user
hasn't authenticated himself.

My guess is this works when the server is configured to support SMTP
AUTH for potentially relaying mail from local users to other servers,
but as you show under that configuration the authentication requirement
applies even for messages intended for local users.  That's curious.

I don't know whether that behavior is documented and expected, and
whether it is considered a security feature or not.  I hope Wietse can
weigh in on this.

However, issuing a request using a homoglyph character:
$ echo -ne "j\xce\xbfhn.doe () server com" | xclip -selection clipboard
$ nc -v *** OMITTED ***  25
Connection to *** OMITTED ***  25 port [tcp/smtp] succeeded!
220 *** OMITTED ***  ESMTP Postfix
mail from: j??hn.doe () server com
250 2.1.0 Ok
rcpt to: existing.user () server com
250 2.1.5 Ok
data
354 End data with &lt;CR&gt;&lt;LF&gt;.&lt;CR&gt;&lt;LF&gt;

The victim would get an email thinking it's from the actual john.doe
user.

OK.  To me, the real unexpected issue here is not the possibility to
spoof (in fact, it's unexpected to me that it wasn't possible in your
first example), but rather the possibility to probe for valid 
usernames.
That other aspect is more likely CVE-worthy, in my opinion.  There's
precedent that such easy probing for usernames shouldn't work, and is
getting CVEs against services where it does work.

There's probably room for hardening here where in cases when SMTP AUTH
is enforced for local users, mail from other local-looking addresses 
yet
with non-existent usernames be rejected in exactly the same way (and
with the same timings - tricky!) as mail from existing local usernames
when SMTP AUTH is not attempted (like in your example).  There should
also be no visible (and ideally no measurable) difference for existing
and non-existent usernames when SMTP AUTH is attempted but fails.

Alternatively, mail to local users could be accepted consistently
regardless of whether the claimed sender username exists locally or 
not,
thus without requiring authentication.  However, this would leave
unfixed the username probing possibility on attempting to relay mail to
external servers, where bypassing authentication is certainly not an
option.  So overall that isn't a valid fix for the username probing.

I assume the tests above are with postfix-2.10.1-7.el7.x86_64 as you 
had
mentioned previously, and behavior could very well vary between builds.

Whether this is applicable for assigning a CVE it's up to you decide,

No, technically it's up to MITRE, and they've already assigned one - 
but
I complain that they did so without sufficient detail on the issue.

the only actual risk here discovered so far is a social-engineering
attack.

And username probing.

&gt;&gt;&gt; Use CVE-2020-12063.

Alexander

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

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 Wietse Venema (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)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->