Settings

Theme

New GitHub phishing attack due to missing DMARC

twitter.com

26 points by geelen 6 years ago · 6 comments

Reader

jsiepkes 6 years ago

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 6 years ago

    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 6 years ago

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*****

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

geelenOP 6 years ago

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 6 years ago

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...

Keyboard Shortcuts

j
Next item
k
Previous item
o / Enter
Open selected item
?
Show this help
Esc
Close modal / clear selection