挖洞经验 | 通过GitHub上泄露的dotfile文件获得Zendesk代码项目和网络资产访问权限

zendesk_logo_on_green_rgb.png本文中,Assetnote发现了厂商Zendesk公司泄露在GitHub上的信息,该信息包含了可远程访问Zendesk网络资产的相关密码凭据,可以访问Zendesk公司的大量代码项目和网络资产,影响严重。

Assetnote公司简介

Assetnote是一家澳大利亚初创型安全公司,主要业务为识别消除目标客户网络攻击面。Assetnote产品研发部门下专门有一支团队负责监测分析企业型数据泄露事件,该团队主要通过GitHub、PasteBin 和 Trello等第三方平台应用来识别一些组织机构的信息泄露,案例显示,一些机构个人或承包商会在这些第三方平台中无意泄露包括凭据、源码甚至是原始的客户个人信息等敏感数据。

目前,Assetnote的数据泄露监测团队开发了一种名为第三方平台泄露监测(“ Third-Party Platform Exposure”,TPPE)的模块,并把它应用在了Assetnote的持续安全平台中,迄今为止,该模块在一些公开的漏洞众测中表现不俗,相继发现了多例严重的泄露事件。

Zendesk泄露在GitHub上的 Google Cloud 和 Artifactory 凭据

2月15日,我们的TPPE模块检测到了两个包含有Zendesk配置文件(dotfile)的公开代码仓库,其中一个仓库为便于开发人员对命令行界面CLI和开发工具包SDK的使用进行相关配置。

针对第一个代码仓库,TPPE模块分析报告称,其中存在两种格式的密码凭据信息,一种为Jfroge的仓库服务端软件Artifactory的token凭据,另一种为Google Cloud的传统密码(“legacy-credentials”)相关文件夹。

Jfroge的Artifactory 是一款Maven仓库服务端软件,可以用来在内网搭建maven仓库,供公司内部公共库的上传和发布,以提供公共代码使用的便利性。

经过分析,我们发现这两种密码凭据是有效存在的,甚至可以通过其中列出的信息,结合泄露的用户名和Artifactory token,对环境变量给出的目标主机发起请求:

export ARTIFACTORY_KEY="<REDACTED>”;  # For HTTP repository access
export ARTIFACTORY_USERNAME="<REDACTED>";
curl u $ARTIFACTORY_USERNAME:$ARTIFACTORY_KEY https://<REDACTED>/artifactory/api/build
Response:
{
    "uri": "http://<REDACTED>/artifactory/api/build"

另外,我们还继续验证了其中的Google Cloud凭据。虽然直接用传统的密码格式,结合cURL方式发起对Google Cloud API的身份验证请求微显复杂,但我们发现,可以简单地把代码仓库中的gcloud配置文件夹部署在我们本地的shell环境中,这也意味着,我们就能像正常用户一样去使用其中的gcloud命令界面了。如下:

[email protected]:~|⇒  cp <REDACTED>/.config/gcoud ~/.config/gcloud
[email protected]:~|⇒  gcloud projects list
PROJECT_ID                            NAME                           PROJECT_NUMBER
...
<REDACTED>                       Bime development                <REDACTED>
<REDACTED>                       Bime preproduction                   <REDACTED>
<REDACTED>                       Bime production               <REDACTED>
…
<REDACTED>                  Zendesk Authentication  <REDACTED>
…
<REDACTED>                    Voice Production             <REDACTED>
…
<REDACTED>                       Zendesk Billing               <REDACTED>
...

用泄露的Google Cloud凭据,可以访问Zendesk公司150多个代码项目,只是为了保密,我们隐去了(REDACTED)具体的项目名称。

对不熟悉Google Cloud使用的人来说,删除掉一些敏感信息或添加授权用户的SSH密钥来管理SSH也是非常简单的,这样做,你可以用SSH方式来授权访问某些实例,如下:

gcloud compute ssh <instance>

在此期间,我们没有利用泄露凭据对一些具体实例进行连接,后经分析,其中存在一些可以上述命令访问的外部可访问实例。

针对第二个代码仓库,我们的监测模块高亮显示了这种不同类型的token,它与Artifactory token类似。经过测试分析,我们确定这些token信息仍然有效:

export ARTIFACTORY_USERNAME="<REDACTED>"
export ARTIFACTORY_API_KEY="<REDACTED>"
curl -i -u $ARTIFACTORY_USERNAME:$ARTIFACTORY_API_KEY https://<REDACTED>/<REDACTED>/artifactory/api/
{
...

我们经由HackerOne平台上报了以上发现的漏洞,之后,Zendesk给予了确认,并在12小时内迅速撤销了以上两个代码仓库泄露的所有token信息。基于泄露信息的严重性,Zendesk最终以每个代码仓库中泄露的token信息为一个漏洞,慷概地以奖励了我们 $6,000。

#496414 – Leaked artifactory_key, artifactory_api_key, and gcloud refresh_token via GitHub

#496925 – Leaked artifactory_api_key via GitHub

经验总结

以上两个代码仓库都是无意泄露了重要的token凭据信息,这种案例时常在各大公司企业中发生。大家可以看看这个价值$15,000的Snapchat Github Token泄露漏洞。

这样的问题不可能完全杜绝,对于我们企业来说,需要在开发中做好严格的安全检查,在后期管理维护中持续监测关注。对于赏金猎人来说,一些公开工具,像 michenriksen/gitrob都是非常不错的,可以用它来检查具体仓库中的信息泄露问题。当然,除了密码凭据之外,我们还可以去发现 GitHub 中一些非常有价值的泄露信息。

*参考来源:assetnote,clouds编译,转载请注明来自FreeBuf.COM