Re: [dmarc-ietf] Understanding Ale's Abuse research

[Douglas Foster <[e-mail]>]

No, Scott.   We do not get angry at white-hat researchers.   We try to
learn from them before the black-hat researchers learn to do the same and
begin deployment.

Ale's message was a very impressive fake, and it obviously did not take
nation-state resources to produce it.   This is alarming.   Among the
problems:

1) I thought IETF had best practices for secure list management.   On my
original account, I would get a challenge-response sequence.   After every
post, I would get a "did you send this message".   I never knew for sure
what made it go away, but it did.   Was it DMARC-related?    Was it
participation-related?   Or was it because my old account used a MailFrom
address with the Barracuda version of BATV?    Whatever the reason, it
becomes clear that IETF does not protect us from impersonated posts.

2) As Wei Chang reminded us recently, SPF is vulnerable to a shared-tenancy
attack.   With huge hosting service like Outlook.com and Gsuite, SPF is a
very weak form of authentication unless the hosting service can prevent
tenants from impersonating each other.   Of course, if the hosting service
allows forwarding without MailFrom rewrite, they may not be able to protect
against the shared-tenancy attack disguised as a forward.

3) The Authentication-Results header mislead when used outside of the
organization that creates it, so those headers are supposed to be discarded
upon entry to a new organization.   This clearly was not done.   IETF did
not strip the Microsoft results, and Google did not strip the IETF results.

4) The Microsoft ARC set indicates that the message produced SPF PASS, but
it does not tell us the IP address which was tested.   When I check SPF on
the combination of "comcast.com" and the previous Recevied address of
(2603:10b6:208:193::31), I get SPF FAIL, not SPF PASS.  The only other
earlier received entry was fe80::5acd:7431:27b0:8d40, which I think is also
a IPV6 private IP.   So Ale's deception appears to be aggravated by
Microsoft's deception.

5) IETF does not document the From and MailFrom addresses that it saw
before it performed rewrite on both, so I don't know what identifiers IETF
saw, which means that I don't understand how the attack was accomplished or
why IETF was duped.

6) Apparently the  headers prior to "tana.it" were fraudulent, having been
inserted from an actual message received previously.   They effectively
confuse the question of where did the message originate.   Did IETF trust
information in those fake headers, or are they merely there to confuse
human readers like me?

7) Is this attack unique to mailing lists, or is it symptomatic of a bunch
of other vulnerabilities that can occur with header manipulation.

In short, I want to know how to defend this attack because defending
against attacks is my job.    Pretending that it will not happen in the
real world does not work for me.

Doug Foster



On Thu, Apr 6, 2023 at 12:54 PM Brotman, Alex <Alex_Brotman=
[e-mail]> wrote:

> I hope Alex won't get offended by this innocent DMARC test.
>
> Are we sure that it is all right for mailing lists to allow spoofs and
> impersonation?  I don't think Comcast has p=reject to safeguard Alex's
> contribution to this list, but what if he can't stand being impersonated?
> What
> else is he supposed to do besides setting p=reject?
>
> THIS LIST TAKES ALL OF THE BAD OF DMARC, NONE OF THE GOOD.
>
> Best
> Ale
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>