Last updated
学习与实践 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) 学习与实践 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
大型 公司 的基本 github 环境结构是拥有一个 企业，该企业拥有 多个组织，每个组织可能包含 多个仓库 和 多个团队。较小的公司可能只 拥有一个组织而没有企业。
从用户的角度来看，用户 可以是 不同企业和组织的成员。在这些组织中，用户可能拥有 不同的企业、组织和仓库角色。
此外，用户可能是 不同团队的一部分，并拥有不同的企业、组织或仓库角色。
最后，仓库可能具有特殊的保护机制。
企业所有者：拥有此角色的人可以 管理管理员、管理企业内的组织、管理企业设置、在组织间强制执行政策。但是，他们 无法访问组织设置或内容，除非他们被指定为组织所有者或被直接授予对组织拥有的仓库的访问权限。
企业成员：由您的企业拥有的组织的成员也是 自动成为企业成员。
在一个组织中，用户可以拥有不同的角色：
组织所有者：组织所有者对您的组织拥有 完全的管理访问权限。此角色应限制，但不应少于两人。
组织成员：在 组织中的人 的默认非管理角色是组织成员。默认情况下，组织成员 拥有一定数量的权限。
账单管理员：账单管理员是可以 管理您组织的账单设置 的用户，例如支付信息。
安全管理员：这是组织所有者可以分配给组织中任何团队的角色。应用后，它赋予团队的每个成员权限，以 管理组织内的安全警报和设置，以及对组织中所有仓库的读取权限。
如果您的组织有安全团队，您可以使用安全管理员角色为团队成员提供他们所需的最低访问权限。
Github 应用管理员：为了允许其他用户 管理组织拥有的 GitHub 应用，所有者可以授予他们 GitHub 应用管理员权限。
外部合作者：外部合作者是指 访问一个或多个组织仓库但不是该组织的明确成员 的人。
您可以在此表中 比较这些角色的权限：https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles
在 https://github.com/organizations/<org_name>/settings/member_privileges 您可以查看 用户仅因是组织的一部分而拥有的权限。
此处配置的设置将指示组织成员的以下权限：
对所有组织仓库拥有管理员、写入、读取或无权限。
成员是否可以创建私有、内部或公共仓库。
是否可以对仓库进行分叉。
是否可以邀请外部合作者。
是否可以发布公共或私有网站。
管理员对仓库的权限。
成员是否可以创建新团队。
默认情况下创建仓库角色：
读取：推荐给 非代码贡献者，希望查看或讨论您的项目。
分类：推荐给 需要主动管理问题和拉取请求的贡献者，但没有写入权限。
写入：推荐给 积极推送到您的项目的贡献者。
维护：推荐给 需要管理仓库的项目经理，但不需要访问敏感或破坏性操作。
管理员：推荐给需要 完全访问项目 的人，包括管理安全或删除仓库等敏感和破坏性操作。
您可以在此表中 比较每个角色的权限：https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role
您还可以在 https://github.com/organizations/<org_name>/settings/roles 中 创建自己的角色。
您可以在 https://github.com/orgs/<org_name>/teams 中 列出组织中创建的团队。请注意，要查看其他团队的子团队，您需要访问每个父团队。
组织的用户可以在 https://github.com/orgs/<org_name>/people 中 列出。
在每个用户的信息中，您可以看到 用户是哪些团队的成员，以及 用户可以访问哪些仓库。
Github 提供不同的方式来验证您的帐户并代表您执行操作。
访问 github.com，您可以使用 用户名和密码（以及 可能的 2FA）登录。
您可以使用一个或多个公钥配置您的帐户，允许相关的 私钥代表您执行操作。https://github.com/settings/keys
您 无法使用这些密钥冒充用户，但如果您不使用它，可能会导致您 因发送未签名的提交而被发现。了解更多关于 警惕模式的信息。
您可以生成个人访问令牌，以 授予应用程序访问您的帐户。创建个人访问令牌时，用户 需要 指定 令牌将拥有的 权限。https://github.com/settings/tokens
Oauth 应用程序可能会请求您 访问部分 GitHub 信息或冒充您 执行某些操作。此功能的一个常见示例是您可能在某些平台上找到的 使用 GitHub 登录按钮。
您可以在 https://github.com/settings/developers 中 创建 您自己的 Oauth 应用程序。
您可以在 https://github.com/settings/applications 中查看所有 访问您帐户的 Oauth 应用程序。
您可以在 https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps 中查看 Oauth 应用程序可以请求的范围。
您可以在 https://github.com/organizations/<org_name>/settings/oauth_application_policy 中查看组织中应用程序的第三方访问。
一些 安全建议：
OAuth 应用程序 应始终 在 GitHub 的所有地方作为经过身份验证的 GitHub 用户操作（例如，在提供用户通知时），并仅访问指定的范围。
OAuth 应用程序可以通过为经过身份验证的用户启用“使用 GitHub 登录”作为身份提供者。
不要 构建 OAuth 应用程序，如果您希望您的应用程序在 单个仓库 上操作。使用 repo OAuth 范围，OAuth 应用程序可以 在所有 经过身份验证的用户的仓库上操作。
不要 构建 OAuth 应用程序以作为您 团队或公司的 应用程序。OAuth 应用程序作为 单个用户 进行身份验证，因此如果一个人创建了一个供公司使用的 OAuth 应用程序，然后他们离开公司，其他人将无法访问它。
更多 信息见 这里。
Github 应用程序可以请求权限以 访问您的 GitHub 信息或冒充您 执行特定操作。在 GitHub 应用程序中，您需要指定应用程序将访问的仓库。
要安装 GitHub 应用程序，您必须是 组织所有者或在仓库中拥有管理员权限。
GitHub 应用程序应 连接到个人帐户或组织。
您可以在 https://github.com/settings/apps 中创建您自己的 GitHub 应用程序。
您可以在 https://github.com/settings/apps/authorizations 中查看所有 访问您帐户的 GitHub 应用程序。
这些是 GitHub 应用程序的 API 端点 https://docs.github.com/en/rest/overview/endpoints-available-for-github-app。根据应用程序的权限，它将能够访问其中的一些。
您可以在 https://github.com/organizations/<org_name>/settings/installations 中查看组织中的已安装应用程序。
一些安全建议：
GitHub 应用程序应 独立于用户采取行动（除非应用程序使用 用户到服务器 令牌）。为了使用户到服务器的访问令牌更安全，您可以使用将在 8 小时后过期的访问令牌，以及可以交换为新访问令牌的刷新令牌。有关更多信息，请参见“刷新用户到服务器的访问令牌”。
确保 GitHub 应用程序与 特定仓库 集成。
GitHub 应用程序应 连接到个人帐户或组织。
不要期望 GitHub 应用程序知道并做用户可以做的所有事情。
不要使用 GitHub 应用程序，如果您只需要“使用 GitHub 登录”服务。但是，GitHub 应用程序可以使用 用户识别流程 来登录用户 并 执行其他操作。
如果您在使用 GitHub Actions 的应用程序中希望修改工作流文件，您必须代表用户使用包含 workflow 范围的 OAuth 令牌进行身份验证。用户必须对包含工作流文件的仓库具有管理员或写入权限。有关更多信息，请参见“理解 OAuth 应用程序的范围”。
更多 信息见 这里。
这 不是在 GitHub 中进行身份验证的方法，但 恶意 GitHub Action 可能会获得 未经授权的访问 GitHub，并且 根据 赋予 Action 的 权限，可能会进行几种 不同的攻击。有关更多信息，请参见下文。
Git actions 允许在 事件发生时自动执行代码。通常执行的代码与 仓库的代码有某种关系（可能构建一个 docker 容器或检查 PR 是否包含秘密）。
在 https://github.com/organizations/<org_name>/settings/actions 中，可以检查组织的 GitHub Actions 配置。
可以完全禁止使用 GitHub Actions，允许所有 GitHub Actions，或仅允许某些操作。
还可以配置 谁需要批准才能运行 GitHub Action 以及运行时 GitHub Action 的 GITHUB_TOKEN 权限。
GitHub Action 通常需要某种秘密与 GitHub 或第三方应用程序进行交互。为了 避免将它们以明文形式放入仓库，GitHub 允许将它们作为 Secrets 放置。
这些秘密可以为 仓库或整个组织 配置。然后，为了让 Action 能够访问秘密，您需要将其声明为：
Secrets 只能从声明它们的 Github Actions 访问。
一旦在仓库或组织中配置，github 用户将无法再次访问它们，他们只能更改它们。
因此，窃取 github secrets 的唯一方法是能够访问执行 Github Action 的机器（在这种情况下，您将只能访问为该 Action 声明的 secrets）。
Github 允许创建 环境，您可以在其中保存 secrets。然后，您可以通过类似以下方式授予 github action 访问环境内的 secrets：
您可以配置一个环境，使其被所有分支访问（默认）、仅受保护的分支或指定可以访问的分支。 它还可以设置执行某个操作之前所需的审核数量，或者等待一段时间后再允许部署继续。
Github Action可以在github环境中执行，也可以在用户配置的第三方基础设施中执行。
许多组织允许在第三方基础设施中运行Github Actions，因为这通常更便宜。
您可以在 https://github.com/organizations/<org_name>/settings/actions/runners 列出组织的自托管运行器。
查找在非github基础设施中执行的Github Actions的方法是搜索Github Action配置yaml中的 runs-on: self-hosted。
不可能在不同组织的自托管环境中运行组织的Github Action，因为在配置Runner时会生成一个唯一的令牌以知道该运行器属于哪里。
例如，如果自定义Github Runner配置在AWS或GCP中的机器上，该Action可能会访问元数据端点并窃取运行该机器的服务帐户的令牌。
如果允许所有操作（或恶意操作），用户可能会使用一个恶意的Github Action，这将危害正在执行的容器。
一个恶意的Github Action运行可能会被攻击者滥用以：
窃取所有秘密，该Action可以访问
横向移动，如果该Action在可以访问用于运行机器的SA令牌的第三方基础设施中执行（可能通过元数据服务）
滥用工作流使用的令牌，以窃取执行该Action的repo的代码或甚至修改它。
分支保护旨在不将完整控制权授予用户。目标是在能够在某些分支中编写代码之前设置多个保护方法。
可以在 https://github.com/<orgname>/<reponame>/settings/branches 找到存储库的分支保护。
不可能在组织级别设置分支保护。因此，所有保护必须在每个repo中声明。
可以对分支（如master）应用不同的保护：
您可以要求在合并之前进行PR（因此您不能直接将代码合并到该分支）。如果选择此项，则可以实施其他不同的保护：
要求一定数量的批准。通常需要1或2个其他人批准您的PR，以便单个用户无法直接合并代码。
在推送新提交时撤销批准。否则，用户可能会批准合法代码，然后用户可以添加恶意代码并合并。
要求代码所有者进行审核。至少需要1个代码所有者批准PR（因此“随机”用户无法批准）。
限制谁可以撤销拉取请求审核。您可以指定允许撤销拉取请求审核的人员或团队。
允许指定的参与者绕过拉取请求要求。这些用户将能够绕过先前的限制。
要求状态检查在合并之前通过。某些检查需要在能够合并提交之前通过（例如，检查没有明文秘密的github action）。
要求在合并之前解决对话。所有代码上的评论需要在PR合并之前解决。
要求签名提交。提交需要签名。
要求线性历史。防止将合并提交推送到匹配的分支。
包括管理员。如果未设置此项，管理员可以绕过限制。
限制谁可以推送到匹配的分支。限制谁可以发送PR。
如您所见，即使您设法获得某个用户的凭据，repos可能受到保护，避免您将代码推送到master，例如，以危害CI/CD管道。
学习和实践AWS黑客攻击：HackTricks Training AWS Red Team Expert (ARTE) 学习和实践GCP黑客攻击：HackTricks Training GCP Red Team Expert (GRTE)
