1451330 - ar.mozilla.org subdomain Takeover

Status: RESOLVED FIXED

(Websites :: Other, defect)

Description

[Richard Strnad]

Hello Mozilla team.

I was able to complete subdomain takeover of ar.mozilla.org.

This subdomain was pointing on github pages, but wasnt claimed here. 

I redirected index back on mozilla.org.
Proof of takeover: https://ar.mozilla.org/takeover-5548690.html

Attacker could host any content here, including scripts or malware.

Comment 1

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Richard: we received another report on a similar domain using this setup (I'll dig up the bug shortly), but it was using CloudFront as the front end.  At the time we triaged that issue, I checked with edunham and we confirmed the CloudFront origin was set to a github.io alias, which suggests it was not vulnerable.  I can see in this case that you were able to clearly take it over, but I'm going to need to raise this again with edunham again because it is my understanding that CloudFront if setup using github.io as the origin domain (and not ar.mozilla.org), that this isn't possible.  The only way I can justify this working is perhaps the CloudFront distribution is setup differently to carry the origin request's host header into the origin transport comms, which is default behavior is something like Fastly (but not in CloudFront last I checked).

I suspect the vector was simply claiming the CNAME in an alternate GitHub repo to claim the domain, can you please point me to the GitHub repo where you have set this so I can confirm that?

Comment 2

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

This is technically a dup of bug 1449858 and bug 1449863, but when we discussed this before, we didn't believe it was exploitable, because in default CloudFront behavior, this isn't possible.  So I believe there is something odd happening here that makes this unique.

Comment 3

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

edunham: Can you please provide some information about how the CloudFront distribution origin is setup for ar.mozilla.org?  I'm also wondering there is some setting used in that config that instructs it to preserve the original request host headers in the backend transport comms to the origin.  That's the only reasonable explanation I can think of that would result in this outcome.

Comment 4

[Richard Strnad]

(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #1)
> Richard: we received another report on a similar domain using this setup
> (I'll dig up the bug shortly), but it was using CloudFront as the front end.
> At the time we triaged that issue, I checked with edunham and we confirmed
> the CloudFront origin was set to a github.io alias, which suggests it was
> not vulnerable.  I can see in this case that you were able to clearly take
> it over, but I'm going to need to raise this again with edunham again
> because it is my understanding that CloudFront if setup using github.io as
> the origin domain (and not ar.mozilla.org), that this isn't possible.  The
> only way I can justify this working is perhaps the CloudFront distribution
> is setup differently to carry the origin request's host header into the
> origin transport comms, which is default behavior is something like Fastly
> (but not in CloudFront last I checked).
> 
> I suspect the vector was simply claiming the CNAME in an alternate GitHub
> repo to claim the domain, can you please point me to the GitHub repo where
> you have set this so I can confirm that?

Yeah, exactly that. 

Mentioned github repo: https://github.com/NateTheRiver/Ar-mozilla

Comment 5

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Thanks Richard, I very much appreciate you re-raising this issue as it runs against how this worked.  I believe the fix is likely going to be changing the cloudfront behavior to require the github.io origin and not observe the original requests hosts host header, which I believe is making this possible.  The service owner is on the west coast, so in a few hours we'll be able to get some more clarity on this front and get this fixed.  I doubt we'll need you to hand off the CNAME claim using that solution, but if we do, we'll ask you here.

Comment 7

[edunham]

Fixed so the problem subdomains should presently be inoperative. Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1451391 to hopefully get them working correctly.

Comment 9

[Caglar Ulucenk [:cag]]

Hey all,

Are we certain that this is addressed? Over the weekend we have received another bug bounty report for taking over these domains (just dup'ed it above).

Comment 10

[Sergey Bobrov]

Apparently these are different vulnerabilities.
My report is based on an unused alternative name in CloudFront and affects more subdomains.

Comment 11

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

(In reply to Sergey Bobrov from comment #10)
> Apparently these are different vulnerabilities.
> My report is based on an unused alternative name in CloudFront and affects
> more subdomains.

Sergey: We understand them to be the same core issue with a single CloudFront Distribution instance.  If there are issues which affect a different distribution, let us know and we will gladly recognize those as unique issues.  Note that this one distribution did have quite a few CNAMEs assigned and was previously reported, but we understood it was non-exploitable until Richard re-raised the issue with a demonstration of it's exploitability.

Comment 12

[April King [:April]]

ar.mozilla.org still exists and points to nothing. Do we actually need this DNS entry?

If we do want this entry, can we fix it so that properly 302's to mixedreality.mozilla.org and add HTTPS in the process?

Comment 13

[April King [:April]]

There are a handful of domains that are outstanding in this way, including:

ar.mozilla.org
mr.mozilla.org
r.mozilla.org
reality.mozilla.org
xr.mozilla.org

(I may be missing some)

Comment 14

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

April: For clarity, I believe this particular subdomain takeover vector was addressed, but the existing behavior is a result of bug 1453494, which affects the CloudFront tier, where as this one affected the GitHub tier.  Admittedly, yes, this is confusing.

Comment 15

[April King [:April]]

Reporter, how would you like to be credited on our hall of fame? If you have a site you'd like us to link to, we can do that as well.

Comment 16

[Richard Strnad]

Hi, yes, would be nice. (If possible, linking my twitter account suits best for me: https://twitter.com/NateTheRiver )

Btw, do I understand correctly, that some bounty was awarded by "sec-bounty+"? How do I claim it if it is that case?

Thanks,
Richard

Comment 17

[April King [:April]]

Yes, that usually means you've been awarded a cash bounty. I believe that :abillings can contact you for how to receive it.

Comment 18

[Al Billings [:abillings - ex-MoCo]]

I have emailed with a request for necessary paperwork.