
New GitHub phishing attack due to missing DMARC - geelen
https://twitter.com/glenmaddern/status/1278252319646367744
======
jsiepkes
When I received a DMCA takedown request it didn't come from a "github.com"
mail address but from "support@githubsupport.com". At first I thought I was
being phissed but after some digging I found out it was actually an address
they use.

By doing this your basically training your users to just accept mail from any
address that vaguely resembles GitHub. So I can't say I'm really surprised
about this. They don't seem to have given a lot of thought about issues like
these.

~~~
pixl97
Always fun when my company sends out phishing tests and I have to figure out
if it's real, then turns out we have a ton of legit domains mail can come
from.

------
narad
Microsoft should shutdown these domains. I see that this domain was setup
recently 21-Jun-2020. A similar domain with CN TLD is there.

[https://who.is/whois/****gltnub.com*****](https://who.is/whois/****gltnub.com*****)

This could have been setup to do target a large private project and steal the
source code.

------
geelen
This is more a discussion topic, really interested if someone can explain to
me how this email looks legitimate (beyond the information in the replies
already)

------
ryan29
My guess on this is that SendGrid isn't strict enough about the `FROM` header
when the message is being written. It's tough to say though without seeing the
full set of headers.

Note the mail is sent from @sendgrid.net. DKIM even lists it as `with domain
sendgrid.net`. Also note the `via sendgrid.net`. I'm not positive how that
works on GMail, but I'm guessing that means the Return-Path (aka envelope
from) is @sendgrid.net while the `FROM` in the mail header is set to
@support.github.com.

That explains why SPF and DKIM pass, but DMARC fails. Both SPF and DKIM are
aligned to sendgrid.net, but the FROM address the receiver sees is aligned to
github.com (relaxed by default uses the organizational domain). AFAIK, that's
exactly the scenario DMARC was made to catch.

The problem is that (I think) sending mail like that is sort of acceptable,
and a strict DMARC policy breaks it. My guess for that type of mail is you
need to trust the via party (ex: via sendgrid.net) to trust that email. Is
that right? How many people know that? I had to refresh my memory on how DMARC
works to figure out what was going on.

I've never used SendGrid, but I think they support sending from custom domains
[1]. IIRC correctly they even let you delegate a subdomain to them which makes
the setup simple since they handle all the NS. For example, point
sendgrid.github.com DNS to them and all of the SPF / DKIM / DMARC alignment
gets dealt with automatically.

For a high value domain like github.com they should probably be using a
stricter DMARC policy. It's tough because you can impact deliverability, but
all the transactional / cloud providers use similar strategies to improve
deliverability and users don't have a chance understanding even a tiny portion
of it. Ex: (IIRC) MS365 will DKIM sign and ARC seal messages using their
`onmicrosoft.com` domain if you don't configure DKIM for a tenant. It's been a
while since I thought I saw that somewhere and I only noticed in in passing
once when diagnosing a different issue for someone, so don't take it as fact.

TLDR; SendGrid probably needs to be stricter when writing the FROM address.
GitHub probably needs to send from a custom domain so they can be stricter
about DMARC.

1) [https://sendgrid.com/docs/ui/account-and-settings/how-to-
set...](https://sendgrid.com/docs/ui/account-and-settings/how-to-set-up-
domain-authentication/)

