📜 ⬆️ ⬇️

The 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.imtqy.com domain. This is incredibly convenient for all temporary statics, documentation, small simple sites and so on. No need to think about any 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 something strange 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.ru is 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. As before, I saw there only a certain standard template, 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, very reminiscent of the google validation method (name googlef3e716e930ae1730 , content google-site-verification: googlef3e716e930ae1730.html ). It was here that I was already tense, I ran and changed the NS record to my server and began to think what went wrong.


Surface googling showed the following:



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:


 dig whois.jehy.ru +nostats +nocomments +nocmd ; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> whois.jehy.ru +nostats +nocomments +nocmd ;; global options: +cmd ;whois.jehy.ru. IN A whois.jehy.ru. 6984 IN CNAME jehy.github.io. jehy.github.io. 3384 IN A 185.199.108.153 jehy.github.io. 3384 IN A 185.199.110.153 jehy.github.io. 3384 IN A 185.199.109.153 jehy.github.io. 3384 IN A 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 Ryan Dahl profile for it
2) I got a test repository , specifying for it the custom domain test.jehy.ru. 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 the github tech 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 the 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 found in 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 imtqy.com. It’s pretty easy to do.
2) Next, it filters them, leaving only those that return an error (it seems there is just 404). There are cases when the repositories were not tied, maybe a lot - someone had a misplaced repository, someone deleted it, someone had the binding settings (it seems that this happened to me when I changed the github pages branch).
3) Then the hacker simply creates a new repository with the necessary content and binds it to the “free” domain. Voila!
4) Then everything depends only on the hacker's imagination. 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:



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, he 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:



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 now going to do so” - 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 "its" server ... But "your" server is somehow closer to the body and more predictable. In general, you should always remember about your resources, about their importance, potential losses when intercepting them, and that there can 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.


')

Source: https://habr.com/ru/post/429972/


All Articles