我是如何轻松在 GitHub 上发现关键漏洞的

haidragon
57 阅读4分钟

官网：http://securitytech.cc/

我是如何轻松在 GitHub 上发现关键漏洞的

我的部分漏洞报告示例

引言

GitHub 上有时会包含大量内容 —— 开发者会上传他们的工作、示例、脚本，其中很多人会不小心将敏感信息放入仓库中。你发现的内容可能非常危险，具体取决于信息类型和权限。但要注意：在 GitHub 上发现的内容并不总是问题的终点 —— 有时它可能是通往更大问题的“入口”。它可能只是一个小泄漏，但如果某个密钥或令牌拥有广泛权限，你可能会面临云服务器、数据库或可执行部署的管道。 这里我会讲解 一般应该从哪里寻找，以及一些必须遵循的 实用技巧。

一般寻找的内容

  • 配置文件，如 .env、config.*、settings.*
    • 密钥和令牌：API_KEY、AWS_ACCESS_KEY_ID、Authorization: Bearer ...
    • CI/CD 文件和工作流，如 .github/workflows/*
    • SSH 密钥 / .pem 文件被意外提交
    • 客户或员工的敏感数据（PII）
    • 数据库连接字符串 (postgres://、mysql://、mongodb+srv://)
    • 当然还有更多 —— 总之寻找公司不希望被公开或使用的内容

Dorks（在 GitHub 搜索中使用）

注意： 这些并非全部 —— 你可以根据需要添加或删除；重要的是理解思路。

邮箱

org:(org_name_in_github) "@gmail.com"
org:(org_name_in_github) "@yahoo.com"
org:(org_name_in_github) "@hotmail.com"
org:(org_name_in_github) "@(your_target_email)"

令牌 / 秘钥 / API Keys

org:(org_name_in_github) "AWS_SECRET_ACCESS_KEY"
org:(org_name_in_github) "AWS_ACCESS_KEY_ID"
org:(org_name_in_github) "Authorization: Bearer"
org:(org_name_in_github) "api_key" language:json
org:(org_name_in_github) "secret" language:yaml
org:(org_name_in_github) "PRIVATE_KEY"
org:(org_name_in_github) "api_key"
org:(org_name_in_github) "Token"
org:(org_name_in_github) "secret"
org:(org_name_in_github) "client_secret"
org:(org_name_in_github) "password" language:env
org:(org_name_in_github) filename:.env
org:(org_name_in_github) filename:.npmrc
org:(org_name_in_github) filename:.dockercfg
org:(org_name_in_github) filename:.bash_history
org:(org_name_in_github) "BEGIN RSA PRIVATE KEY"

配置文件

org:(org_name_in_github) filename:config.js
org:(org_name_in_github) filename:settings.py
org:(org_name_in_github) filename:application.properties
org:(org_name_in_github) filename:credentials.json
org:(org_name_in_github) filename:firebase.json

GitHub Actions

org:(org_name_in_github) filename:.github/workflows
org:(org_name_in_github) "secrets." language:yaml
org:(org_name_in_github) "GITHUB_TOKEN"
org:(org_name_in_github) "CI_SECRET"

硬编码凭证（在代码中）

org:(org_name_in_github) "username" "password"
org:(org_name_in_github) "username"
org:(org_name_in_github) "password"
org:(org_name_in_github) "db_password"
org:(org_name_in_github) "mongodb+srv://"
org:(org_name_in_github) "postgres://"
org:(org_name_in_github) "mysql://"

如果你还想找管理员面板

org:(org_name_in_github) "admin"
org:(org_name_in_github) "admin" in:url
org:(org_name_in_github) "admin" in:path
org:(org_name_in_github) "dashboard" in:url
org:(org_name_in_github) "control panel"
org:(org_name_in_github) "login" filename:config.js
org:(org_name_in_github) "admin_url"
org:(org_name_in_github) "site_url"

实用技巧

记住：如果不注意技巧并仔细验证，你可能会被标记为 NA（不受理）。

1. 先检查范围

查看漏洞奖励/计划的范围：许多公司不接受 GitHub 上组织外或超出范围的报告。

2. 聚焦公司的组织

  • 始终在目标公司的 GitHub 组织内搜索。
    • 有些人搜索所有内容 —— 可能是合同开发者或私有开发者上传的仓库（我个人不会处理这些）。

3. 避免示例或演示内容

如果 triager 看到仓库看起来像示例或本地设置，可能会直接标记 NA。

示例：

test、example、dummy、sample、demo、local（有时需要注意）

  • README 或文档中包含类似：
  • “这是一个示例/测试项目” 或 “仅用于演示”
    • 目录如 examples/、sandbox/、docs/examples/ 等

4. 报告前检查历史

如果内容很老（几年之前的提交），仓库看起来不活跃，不确定重要性 —— 不要急于报告。

5. 仔细验证 —— 避免敏感实验

  • 尽量非破坏性验证。
    • 如果太敏感，不要尝试实验 —— 直接提交负责任的报告。

6. 注意重复的密钥

如果同一凭证在多个仓库重复出现，通常不重要。大多数情况下，公司不会在 50 个仓库中都泄露真实生产密钥。通常是占位符、示例或测试值。只关注唯一且看起来真实的生产密钥。

实战示例（逐步演示）

我从探索公司 GitHub 组织开始，并应用之前分享的 dorks，例如：

org:company "password"

我不断浏览仓库，直到几个仓库引起我的注意。 我在新标签页中仔细查看这些仓库。

收集完毕后，我按照前面提到的技巧逐一检查（避开示例、demo/测试项目或非生产环境）。 然后仔细查看暴露的文件和密钥。

确认仓库确实敏感且相关后，我使用 ChatGPT 和 Grok 分析整个仓库，理解它的用途。

avatar
文章
阅读
粉丝