本文中，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命令界面了。如下：

ruby@nippon:~|⇒  cp <REDACTED>/.config/gcoud ~/.config/gcloud
ruby@nippon:~|⇒  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