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

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

扫描器列表

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

国内的github 扫描器

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

扫描器的问题

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

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

优化方向

  1. 关键字问题

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

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

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

Day047

1.推特的缩放图功能的问题

链接: https://twitter.com/David3141593/status/1368957384471810048

推特的缩放图测试,确实可以利用这个东西来隐藏一些东西。不知道微博有没有这种问题。还没有去测试。

2.复现漏洞-Google的SSRF 旁路

链接: http://omespino.com/write-up-google-vrp-n-a-ssrf-bypass-with-quadzero-in-google-cloud-monitoring/

每日复现一个漏洞的内容会专门发文章

3.一个GraphQL漏洞的报告

链接:https://infosecwriteups.com/somebody-call-the-plumber-graphql-is-leaking-again-654bf1a38d26

4.Github的README项目: 如何管理一个开源项目的安全

链接: https://github.com/readme/octoverse-security

5.Git clone的漏洞

6.发现悬空DNS记录漏洞

链接: https://gist.github.com/TheBinitGhimire/9ebcd27086a11df1d7ec925e5f604e03

主要是自动化了整个步骤

Day046

1.依赖关系混淆攻击

链接: https://redhuntlabs.com/blog/dependency-confusion-attack-what-why-and-how.html

比较有感想,比如 opencv-python 导入的时候 是import cv2 但是很多人会直接pip install cv2 这给了一些人攻击的机会

供应链攻击:https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

2.QuickXSS 新工具

链接: https://github.com/theinfosecguy/QuickXSS

看了一下是一个bash脚本,安装了一些库,然后生成payload

3.目标侦查的一些资源

https://github.com/ffuf/ffuf

https://hackingpassion.com/shodan-com…

https://github.com/tomnomnom

https://github.com/projectdiscovery

https://github.com/michenriksen/aquatone

https://pentest-tools.com/information…

https://github.com/jobertabma/virtual…

https://github.com/EnableSecurity/waf…

https://github.com/danielmiessler/Sec…

https://github.com/yasinS/sandcastle

https://digi.ninja/projects/bucket_fi…

https://youtu.be/1Kg0_53ZEq8

4.API安全测试的一些资料

简单看了一下,发现都是例子,非常好。

5.接管微软账号的那个文章

这篇文章,我在不同的地方看到了几次,5万美元其实不算多。

加密的请求被破解之后,内部的WAF 也是有限制的,看看作者怎么突破限制。

所以需要的是请求的代码必须是同时到达,才不会被WAF封IP,那作者是怎么做的呢

作者攻击的只是凭用户名和密码登录的,二次验证开启的用户是不能完成的。作者用了大量的计算资源和1000个IP才完成了攻击。

其实大多数都会去测试用户名和密码,但是要找到绕过系统的一些限制确实还是很难。

6.查找隐藏登录表达的客户端id

链接:https://ahmdhalabi.medium.com/finding-hidden-login-endpoint-exposing-secret-client-id-88c3c2a1af45

作者开始无意发现了一个登陆表单,但是提示没有clientID,然后作者就直接在google搜索,找到了这种clientID,直接就登陆了。

Dorking:site:accounts.redacted.com inurl:client_id.

作者还从和内部团队的沟通中,发现了存在这个值,才去google搜索出来的,直接把严重程度往上提了一个档次。