Attack on Github Pages with the interception of the site on your domain

Most developers know and love github pages. In case you haven't met them, this service allows you to create a static site from your repository, which will be available on the smth.github.io domain. This is incredibly convenient for all temporary statics, documentation, small simple sites and so on. No need to think about some kind of additional web server.

Also, there is an opportunity to link your domain to the repository - then everything will be quite beautiful. Even SSL support is available.

After this small introduction, let's move on to the actual topic of the article. Most recently (November 9th) I had an interesting story. I recommend not to read it in one gulp, but periodically stop and figure out what all the input data currently received mean. I think an interesting training session will come out of this, although the plot of my detective turned out to be not very long and twisted.

I decided in the next profile to add the address of my resume. The summary just lies on github pages, because why not. Out of habit, I clicked to check whether everything works ... And suddenly I found a strange thing there:

Very surprised. I went to the repository settings. I saw that at the moment it is not tied to the domain to which it should be tied. I tried to tie. Suddenly got the error:

The CNAME whois.jehy.ruis already taken. Check out https://help.github.com/articles/troubleshooting-custom-domains/#cname-already-taken for more information

A little tense and surprised. After that I went to look more attentively at this sudden page. I still saw there only a certain standard template, a copyright from 2013, and suddenly a link to the sitemap. The sitemap contains the date of its generation from the current date, as well as a static html document with the name and content, which is extremely reminiscent of the google validation method (name googlef3e716e930ae1730, content google-site-verification: googlef3e716e930ae1730.html). It was here that I was already very tense, I ran and changed the NS record to my server and began to think what went wrong.

Surface googling showed the following:

• It seems that domain hijacking is a potentially known problem, and it has already been solved - it is enough to register the address of your repository in CNAME .
• Despite this, many instructions for linking a githaba to a domain (including those from the top 10 searches) directly write IPs, or simply github.io.

Then I thought that, probably, I had a curve CNAME record. So I changed it to the correct one, with reference to my repository. Now the record looked like this:

digwhois.jehy.ru +nostats +nocomments +nocmd                 
; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> whois.jehy.ru +nostats +nocomments +nocmd 
;; globaloptions: +cmd 
;whois.jehy.ru.                 INAwhois.jehy.ru.          6984    INCNAMEjehy.github.io. 
jehy.github.io.         3384    INA       185.199.108.153jehy.github.io.         3384    INA       185.199.110.153jehy.github.io.         3384    INA       185.199.109.153jehy.github.io.         3384    INA       185.199.111.153

And what my amazement was when I saw this wonderful “Coming Soon” landing again!

To check, I even did another test:

1) I got a new CNAME record test.jehy.ru and pointed out the profile of Ryan Dala for it
2) I got a test repository , specifying the test.jehy.ru custom domain for it. It seems that everything is correct, according to the instructions, and the binding should not work. But alas, the result is obvious .

Next, I contacted tech github support via a strange form on the site . They told me that they could untie an alien repository from my domain if I added myself another NS record. I did this, wrote back - and from Friday until Monday I did not get an answer. Perhaps it was necessary to re-write in this form - but this was already above my strength. So I just left my static site on my server.

At that time I had three options for what happened:

1) Someone accidentally registered in his repository the address of “whois.jehy.ru” in 2018, while laying out a landing page from “coming soon” from 2013, where for some reason lies the html for checking the rights. Well, hardly.
2) Some crazy bug has happened. Also unlikely. He repeated on the second test site.
3) Focus with a binding on CNAME either never worked, or broke, and attackers use this to attack. So far it seemed to me the most likely option.

Next, I remembered that in the case of a domain binding, github itself makes a file named CNAME in your repository. And I went to look for, who added my domain. And - bingo!

The attacker was found in the search:

Here is my domain:

And here is a bunch of others:

As you can see, it was not an accident at all. Someone has stolen a decent amount of domains - including the second level! And I got full power over their content, including confirming in Google the right to own these domains!

By the way, you can also add that sometimes a hacker does not just replace the site content, but forks the source repository, after which it adds verification files. And it has been having fun for at least a month already (found commits from October 6). Well, there are similar followers.

Further, my assumptions about how this attack occurs, and why it is needed.

1) First, the hacker finds sites that are resolved on github.io. It’s pretty easy to do.
2) Next, it filters them, leaving only those that return an error (it seems there is just 404). Cases when the repositories were not tied, maybe a lot - someone had a wrong repository, someone deleted it, someone had the binding settings (it seems that this happened to me when I changed the branch for github pages).
3) Then the hacker simply creates a new repository with the content he needs and links it to the “free” domain. Voila!
4) Then everything depends on the hacker's fantasy. Doorway, linking, data interception, Google access to Google Apps management ... There are a lot of options.

What did I do next, having in my hands all the evidence of the malicious use of the binding:

• Described in the correspondence with support@github.com all the details;
• Once again, rewrote them in the form of contacts;
• Added a ticket on hackerone.com . I must say, it says that githubpages.io is not included in the reward program, but there were no other options. Therefore, I had to ignore this warning, and even a robot who gently advised me not to send this report for the same reasons.

I haven’t been answered to the contact form to this day, but two days later I was answered by hackerone. In short, the answer was that this is a well-known feature of the service, it is not a vulnerability, and the spam team deals with such things. The report was closed as “informative”, so I write about everything with a clear conscience. I was also informed that the account I had indicated was banned. I checked - yes, it is no more. His followers disappeared after a few days (it is not clear why not immediately).

At this one could finish and say that everything is in order ... But in fact, I am extremely embarrassed by this situation:

• Why are these accounts are not months? There is identical content, there are google validation files everywhere, on one account a bunch of such sites ... Common signs are a car and a small cart.
• Why didn't the spam team check related repositories?
• Why do the domain binding instructions show you the illusion of security by offering to set the name of your repository in CNAME if it doesn’t affect anything?
• Why is there no warning mechanism that would say that the domain that was previously tied to your account is now tied to another?
• Why is it impossible not to respond to calipers emails in a githaba? Or maybe I fell under some kind of filter?

But the main question that confuses me is why the github does not check the NS records of the domains that are listed on the github pages for the presence of the specific repository in the CNAME? This is the simplest operation that can be performed with domain binding, and does not take time ... Moreover, the instructions give the impression that it was meant to be so ... So why is this check broken?

In general, I am writing this post with the hope that in some form it will reach the githab, and the guys will take action. Ahead of the question, “why talk about it, everyone is going to do it now,” I will answer that the hole is already well known and is being actively exploited. And so now it is obviously going on constantly scanning the “abandoned” domains, so that several new participants will not change the picture.

Usually I don’t do that, but it would be great if you pat the translation of this article that I put on the medium. Yes, I know that Habr is now multilingual, but for all the time I have seen one and a half posts in English, and I do not think that anyone can pay attention to them. And on the medium there are often good technical posts. So it will be great if you help to pay attention to this hole. If I don’t receive any money for it, there is no USA card, the one that is purely altruistic.

What else can you think of at the end? Probably, that it is always necessary to remember when you place something on third-party capacities. Of course, there is nothing personal on the Internet, and everything is external - “your” domains belong to the registrar, “your” servers - Google, Amazon, or someone else ... Can not say that the githab is less reliable than any "own" server ... But "your" server is somehow closer to the body and more predictable. In general, you should always remember about your resources, their importance, potential losses when intercepting them, and that there may be very sudden specifics of work in third-party services.

PS Thanks to cavin for the picture and pndpnd for translating the article into English.