【转载】【漏洞分析】Github access token exposure

2021年8月16日2021年8月31日 P小二留下评论

hackerone公开了一个五万美元的报告，今天想谈谈这个报告。

链接： https://hackerone.com/reports/1087489

其实这个报告很简单，就是一个Shopify的员工开发了一个应用，但是不小心把.env 文件发布了。但是这个.env文件中有shopify Github仓库的token，这就拿到了github仓库的权限。

这里为什么没有发现这个github token呢，其实主要是因为这个员工开发的是Electron应用，发布到了公网，而且还有人去分析这个Electron应用并在文件系统中找到这个.env文件夹。

这个漏洞发生的几率是非常小的，第一是员工用了工作电脑，还发布了一个应用，而且这个应用还打包了本地的.env文件夹，最后还得安全人员去分析这个应用。

但是我们可以从这个例子中尝试一下怎么去扫描github token等这种验证信息。

目前，github 通过密码扫描服务，会去提醒公共仓库的用户这个安全点。链接：https://docs.github.com/cn/code-security/secret-security/about-secret-scanning

扫描器列表

Gittyleaks 看着不行
scanning feature github官方扫描
Git Secrets AWS发布的，用来阻止提交AWS密钥
Repo Supervisor 找到错误的配置和密码
Truffle Hog 这个工具使用正则表达式进行搜索，包括了分支和提交历史。（推荐使用）
Git Hound go写的检查工具
Gitrob go写的，已经停止维护
Watchtower Radar API AI驱动的检测，发现是个商业项目，可以研究一下
Repo security scanner 是一个命令行工具
GitGuardian 也是一个商业产品
Shhgit 这个很牛b
yar
GitGot
git-wild-hunt

国内的github 扫描器

GSIL
Hawkeye
码小六推荐使用 https://github.com/4×99/code6

扫描器的问题

传统的扫描器其实就是去用关键字去匹配，而且还是使用的Github自己的查询结果，这种关键字查询的问题和官方的服务是重复的，收货不会多。

这和账号本身出发是冲突的，我们要找的这种类型的泄露，其实是和账户人的公司，职位有关系。

优化方向

关键字问题

其实是需要自己来定制规则，很多漏洞都需要很敏感，而且需要深度扫描，还需要和别人抢时间，确实很难。

dotfile 文件例子：https://www.freebuf.com/articles/web/201871.html

2.扫描的范围

包括下面的例子，提交的记录也是需要扫描

3.从人出发和从项目出发

从人出发，可以全网扫描，把github的账户按照公司归类并从账户的其他项目中寻找公司信息

从项目出发，可以通过一个项目，去得到所有的提交者的所有repo，并针对性的寻找信息

监控来讲，其账户的最新的star记录也是有用的，我们已经知道了账号属于的公司，就可以判断这个人，这个公司的技术栈，也知道最近在关注什么样的技术，其实可以干的事情是非常多的。

4.AI的角色

其实这里还是用很多NLP的东西，还有一些分类算法，聚类算法，还是看数据的多少，全网爬github应该不难，重点是需要关注的点是什么，当然用账号信息做数据挖掘也是可以的。

参考资源：

1.Building a GitHub Secrets Scanner https://developer.okta.com/blog/2021/02/01/building-a-github-secrets-scanner

2. 自己动手打造Github代码泄露监控工具 https://www.freebuf.com/articles/web/173479.html

3. 自己动手打造Github代码泄露监控工具之改进篇 https://www.freebuf.com/sectool/188102.html

4.如何利用GitHub搜索敏感信息 https://www.freebuf.com/articles/network/192643.html

Day048

2021年4月5日2021年4月5日 P小二留下评论

1.为什么侦察是漏洞挖掘挣钱的关键？

链接： https://twitter.com/osiryszzz/status/1378540350281687044

步骤：

1 – the sqlis were damn easy to identify – discovering the resources affected, not so much. lots of recon (gau, google dorking, spidering, url guessing) on target. discovered a number of web services, however no vulns

SQL注入非常容易识别，发现受影响的资源不容易。大量的侦察(gau,google daring, spidering ， url guessing ) ，发现一些网络服务，但是不会有漏洞。

2 – kept URL guessing and found a zip file containing web.config – several creds leaked – more interesting was the URLs disclosed in there as they point to asmx web services – turns out 90% of these are on sites out of scope

继续进行网址猜测，发现了一个包含web.config的zip文件。有几个信息泄露，包括了指向asmx的网络服务。但是多数不在测试范围内。

3 – the paths of these web services were somehow similar to other folders and couple web services that existed on the main target, so I created several dictionaries to be used in an attack with permutations to see if the site had these endpoints just in different folders

发现web服务的路径在某种程序上与其他的文件夹类似，并存在于主目标的几个web服务上。所以我创建了一个字典用于攻击，看看是否存在不同的文件夹的端点。

4.- dict1 known folders on target. dict2, dict3 both had paths extracted from the urls in web.config, with some permutations based on names similarities I inferred; dict4 endpoints from web.config. ran ffuf cluster-bomb style out of 35k possibilities, found 10+

测试了3个文件夹的，从web.config中的url提取路径，还有一些推断的相似的排列，从35000中可能性中使用ffuf找到了10+以上。

5.- 10+ web services that supposedly were on OOS sites, however available in different locations on target in scope. each web service had many endpoints (some even 30-40). moral of the story, these had more holes than swiss cheese. that’s were all sqlis were

在10个以上的web服务中，有OOS网站，但是不在可接受范围内。每一个web服务有很多的端点，意味着漏洞比较多。

6 – TLDR; would i have reported the web.config finding immediately, other people would have seen the URLs and perhaps locate these web services on the target; i didn’t report it and worked until i found their location and reported as many sqlis as i could.

我立即报告了web.config查找的结果，其他人可能看到了url，并在目标上定位这些web服务。我主要是想找到竟可能多的SQL注入。

7 – my take away and tip for the reader: don’t report a bug as soon as you find it, especially if it shows that it can be used to further own a target. keep the intel for yourself and hack. if after a while it doesn’t lead to anything, report the bug and move on.

给读者的建议，一旦发现了bug，不要马上报告。特别是有可能有收获的时候，把情报留给自己。如果没有进展，过一段时间再报告。

2.I Built a TV That Plays All of Your Private YouTube Videos

链接： https://bugs.xdavidhu.me/google/2021/04/05/i-built-a-tv-that-plays-all-of-your-private-youtube-videos/

3.Breaking GitHub Private Pages for $35k

链接： https://robertchen.cc/blog/2021/04/03/github-pages-xss

4.BugBountyTip

链接： https://twitter.com/intigriti/status/1379044920074375175