GitHub中公开的敏感数据

执行摘要

第42单元《云威胁报告：2020年春季》侧重于DevOps的实践，以确定云中发生错误配置的位置。该博客提供了对GitHub存储库的详细分析，以及对“左移”安全性检查的迫切需求，以使所有团队（DevOps，工程和安全性）能够更早地发现并解决问题。

很少有数据仓库比GitHub更广泛地用于从开发到生产的快速跟踪代码。然而，正如古老的格言所说，“速度越快，风险就越大”。

研究人员发现，组织对公共GitHub帐户的使用以及DevOps泄漏敏感信息的可能性很高，因此数据丢失或持续破坏事件的风险增加。但是，通过正确实施DevSecOps和使用GitHub Event API扫描程序，组织可以大大降低公开暴露危害性信息的风险。

主要发现

第42单元的研究人员通过GitHubs Event API分析了超过24,000个公共GitHub数据上传，发现了数千个包含潜在敏感信息的文件，其中包括：

GitHub的事件API

GitHub为开发人员提供了对Event API搜索功能的访问权限。这允许发布到GitHub服务器的文件和代码的近实时列表。事件API每小时每个帐户最多有5,000个请求，研究人员可以查看和扫描推送到Github的任何文件，这些文件在公共领域都可用，例如公开共享。有几种工具可以利用此功能。在商业方面，GitHub本身负责运行和维护GitHub Token Scanner。这将检查文件中的令牌字符串，以尝试防止欺诈和滥用。在AWS”混帐的秘密由AWS用于扫描用户名和密码以及其他关键字符串以防止其泄露。也有像gitrob和trugglehog这样的开源GitHub Event API扫描程序，红队，钢笔测试人员和恶意用户都使用过这些扫描程序来识别潜在的敏感信息。

ShhGit Live

第42单元的研究人员使用eth0izzle的shhgit读取了近实时的GitHub事件，并试图回答三个问题。

1. 
   

1. 在文件中找到潜在的敏感数据吗？

2. 是否可以将它们追溯到组织？

3. 安全预防措施是否可以防止不必要的潜在敏感数据泄露？

简而言之，对这三个问题的答案都是肯定的。研究人员发现并分析了超过24,000个独特的GitHub文件，这些文件触发了onsshhgit的预制120签名规则以及自定义Unit 42签名规则。研究人员发现了许多潜在的敏感数据条目，包括：

• 
  

• 4109配置文件

• 2464 API密钥

• 2328硬编码的用户名和密码

• 2144私钥文件

• 1089个OAuth令牌

经过对这些发现的分析，第42单元的研究人员证实了这些发现的有效性，并且能够识别文件所有者，项目名称，在某些情况下还可以识别发布此信息的商业公司的名称。

分解结果

硬编码密码

研究人员确定最关键的发现是硬编码密码的存在。总共发现2328个用户名和密码条目，包括880个唯一密码，其中包括797个唯一用户名。这些密码在服务URL API条目和SSH配置文件中找到。研究人员指出，总密码输入中只有18％与前10个最常见的密码相关。密码“ password”以72个条目为首，密码“ secret”以51个位居第二，有关确定的前10个最常见密码的详细信息，请参见表1。

表1：确定的十大最常见密码

也许更有趣的是，880个唯一密码条目中的817个出现了3次或更少，而665个密码仅出现了1次。使这些统计信息非常有趣的是密码本身的唯一性。例如，以下是十个密码条目的示例：

• 
  

• p4ssW0rde

• P @ ## w0rd

• 密码！

• qwerty123456789

• simplepass123

• sqluser2019

• 超级秘密

• wilson1234567

• xxxxxxxxxxxxxxxxxxxx

• Z * NsqgS5 $ @ jHsF2

从主观角度来看，研究人员指出，某些密码被认为在公司中很常见。大多数密码都满足最低密码要求，并且很容易记住，例如前两个“密码”密码。但是，这些密码很容易被恶意行为者猜中，并且经常出现在大多数蛮力词典列表中。提供的样本中的其他条目是非常简单的密码，仅包含小写和数字组合，甚至只是字母“ x”重复了20次。研究人员认为这些密码具有伪造的复杂性模式以及条目的唯一性，因此它们“具有很高的合法性”。这意味着这些可能是工程师在其自己的生产环境中使用的密码。另外，

相比之下，研究人员仅发现了27个独特的实例，其中使用了可变密码输入，表明临时或动态密码使用情况。例如，$ password，{password}或％Password％。在确定的2328个密码中，这27个唯一密码实例仅占67个的总数，不到3％。

硬编码的API密钥和OAuth令牌

第42单元的研究人员在24,000多个触发的GitHub文件中识别出2464个API密钥和1998个OAuth令牌。发现这些元素是唯一的，在所有触发的GitHub文件中，只有15个键或令牌重复了4次以上，只有12个重复次数最多，请参见表2。

表2.前15个API密钥

由于API密钥和OAuth密钥的性质，这些元素可为用户提供对指定云环境的直接访问。如果API密钥或OAuth令牌落入他人之手，恶意参与者可能会冒充工程师并获得对环境的控制权。在最坏的情况下，如果在云环境中使用管理特权创建了API密钥，则使用该API密钥的任何人都将具有对云帐户的完全访问权限。确实发生了合法的API密钥公开。以UpGuard报告的事件为例。通过GitHub公开了将近1GB的数据，包括AWS API密钥，日志文件和IaC模板。此事件详细说明了服务和基础结构配置文件中包含的合法API密钥向公众公开的情况。发现凭据和API密钥与商业组织拥有的根帐户相关联。

与密码一样，密钥和令牌也必须受到保护和控制，以确保只有合法用户才能知道它们。任何丢失或可能泄漏的API密钥或OAuth令牌应立即撤销并重新发布。表3显示了已识别的2464个API密钥和1098个OAuth令牌以及它们所关联的环境。

表3.带有关联的API和OAuth密钥的已识别环境

配置和私钥文件

第42单元的研究人员通过分析配置和私钥文件来完成他们的云深入研究。配置文件代表由sshgit和Unit 42签名规则标识的文件的最高单一类别，在24,000个文件中占将近17％。最常见的配置文件类型是Django配置文件，其中包含已识别的所有配置文件类型中的第3种以上，请参见表4。Django是基于python的Web框架，可促进快速开发和设计。PHP位居第三，它也是Web设计中非常常用的脚本语言。这些基于Web的配置文件可能会暴露组织的云基础架构，从而使攻击者可以轻松访问云服务器内部。这也将使剥削或后期剥削操作更加容易。

表4.十大配置文件类型

研究人员发现环境和外壳配置文件的存在率很高。这些类型的配置文件可建立系统或服务的环境控制。Shell，SSH，配置文件和Git配置文件也位于确定的配置文件的前十名中。与前面的部分相关，服务在配置文件中要求用户名和密码，API密钥或令牌占位符的情况并不少见。研究人员发现，将近80％的配置文件包含用户名或密码，API密钥或OAuth令牌的某些方面。

结论

第42单元的研究人员发现了证据，表明用户将敏感数据上传到GitHub。此敏感数据包含：

• 
  

• 硬编码的用户名和密码

• 硬编码的API密钥

• 硬编码的OAuth令牌

• 内部服务和环境配置

正如我们在最近的DevOps重点关注的云威胁报告中所指出的那样，第42单元研究人员强烈建议对从公共存储库（例如GitHub）提取的每个IaC模板进行彻底扫描，以查找漏洞，作为CI / CD管道的一部分。证据表明，每个扫描的CloudFormation模板（CFT）中几乎有一半包含潜在的易受攻击的配置。部署易受攻击的云模板的可能性很大。此外，组织应使用GitHub Event API扫描程序来帮助防止通过GitHub代码出版物公开敏感的内部信息。

补救措施

研究人员建议将代码发布到GitHub存储库的用户和组织使用以下缓解措施，以确保配置文件不会公开泄漏敏感信息：

• 
  

• 实施基于变量和CLI基于参数的代码编写实践，以从代码示例中删除硬编码的用户名和密码，API密钥和OAuth令牌。

• 实施密码安全策略，强制使用复杂密码

• 实施发布政策，以规范和防止通过外部资源共享内部敏感数据。

• 使用GitHub的企业帐户功能来确保更仔细地审查公共共享做法。

• 使用AWS-git secrets，GitHub的TokenScanner，gitrob或trugglehog之类的工具来识别和删除公开发布的令牌

下载Unit 42云威胁报告：2020年春季，以获取更多研究和最佳实践，以在您的组织中实施。

其他资源

• 单元42云威胁报告：2020年春季博客

• Unit 42 CTR：来自Docker注册表的泄漏代码

翻译自https://unit42.paloaltonetworks.com/github-data-exposed/