基本 Github 信息

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

基本结构

大型 company 的基本 github 环境结构通常是拥有一个 enterprise，该 enterprise 拥有 多个 organizations，每个 organization 可能包含 多个 repositories 和 多个 teams。较小的公司可能只 拥有一个 organization 并且没有 enterprises。

从用户角度来看，一个 user 可以是 不同 enterprise 和 organization 的 member。在这些范围内，用户可能拥有 不同的 enterprise、organization 和 repository 角色。

此外，用户可能 属于不同的 teams，在这些 team 中拥有不同的 enterprise、organization 或 repository 角色。

最后，repositories 可能有特殊的保护机制。

权限

Enterprise Roles

  • Enterprise owner：拥有此角色的人可以 管理管理员、管理 enterprise 内的 organizations、管理 enterprise 设置、在 organizations 之间强制执行策略。但他们 不能访问 organization 设置或内容，除非被设为 organization owner 或被授予对某个 organization 所有仓库的直接访问权限。
  • Enterprise members：由你的 enterprise 拥有的 organizations 的成员也会 自动成为 enterprise 的成员。

Organization Roles

在一个 organization 中，用户可以拥有不同的角色：

  • Organization owners：Organization owners 对组织具有 完全的管理访问权限。该角色应当限制分配，但组织中至少不应少于两人拥有该角色。
  • Organization members：对于组织中的人员，默认的非管理角色是 organization member。默认情况下，organization members 拥有若干权限。
  • Billing managers：Billing managers 是能够 管理组织的计费设置（例如支付信息）的用户。
  • Security Managers：这是 organization owners 可以分配给组织中任意 team 的角色。分配后，该 team 的每个成员将获得 管理整个组织的安全警报和设置的权限，以及对组织中所有 repositories 的只读权限。
  • 如果你的组织有一个 security team，可以使用 security manager 角色为该 team 的成员赋予他们在组织中所需的最小访问权限。
  • Github App managers：为了允许额外的用户 管理组织拥有的 GitHub Apps，owner 可以授予他们 GitHub App manager 权限。
  • Outside collaborators：outside collaborator 是指那些 对一个或多个组织仓库有访问权限但并不是明确的组织成员 的人。

你可以在此表格中 比较这些角色的权限：https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Members Privileges

在 https://github.com/organizations/<org_name>/settings/member_privileges 你可以查看 仅因成为该组织的一员而赋予用户的权限。

这里配置的设置将指示组织成员的以下权限：

  • 对组织中所有仓库是管理员、写入者、只读或无权限。
  • 成员是否可以创建 private、internal 或 public 仓库。
  • 是否允许对仓库进行 fork。
  • 是否可以邀请 outside collaborators。
  • 是否可以发布 public 或 private sites。
  • 管理员对仓库的权限范围。
  • 成员是否可以创建新的 teams。

Repository Roles

默认创建的 repository 角色：

  • Read：推荐给希望查看或讨论项目的 非代码贡献者。
  • Triage：推荐给 需要主动管理 issues 和 pull requests 但不需要写权限的贡献者。
  • Write：推荐给 需要主动向项目推送的贡献者。
  • Maintain：推荐给 需要管理仓库但不需访问敏感或破坏性操作的项目经理。
  • Admin：推荐给需要对项目拥有 完全访问权限 的人员，包括管理安全或删除仓库等敏感和破坏性操作。

你可以在此表格中 比较每个角色的权限：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 创建你自己的角色。

Teams

你可以在 https://github.com/orgs/<org_name>/teams/ 列出组织中创建的 teams。注意，要看到作为其他 teams 子团队的 teams，你需要访问每个父团队。

Users

组织的用户可以在 https://github.com/orgs/<org_name>/people. 列出。

在每个用户的信息中，你可以看到该用户 所属的 teams 以及 该用户有权限访问的 repos。

Github Authentication

Github 提供多种方式来验证你的账户并代表你执行操作。

Web Access

访问 github.com 时，你可以使用 用户名和密码 登录（并可能需要 2FA）。

SSH Keys

你可以为你的账户配置一把或多把公钥，允许相应的 私钥代表你执行操作。 https://github.com/settings/keys

GPG Keys

你 不能用这些密钥冒充用户，但如果你不使用 GPG，可能会因为提交没有签名而被发现。更多关于 vigilant mode 的信息在这里。

Personal Access Tokens

你可以生成 personal access token 来 授予一个应用访问你的账户。在创建 personal access token 时，user 需要 指定 该 token 将拥有的 权限。https://github.com/settings/tokens

Oauth Applications

Oauth applications 可能会向你请求权限，以访问你部分 github 信息或以你的身份执行操作。一个常见例子是某些平台上的 login with github 按钮。

一些 安全建议：

  • 一个 OAuth App 应始终 以验证过的 GitHub 用户的身份在整个 GitHub 上执行操作（例如，在提供用户通知时），并且仅能访问指定的 scopes。
  • 通过为已验证用户启用 “Login with GitHub”，OAuth App 可以用作身份提供者。
  • 不要 构建 OAuth App 如果你希望你的应用只作用于 单个仓库。With the repo OAuth scope, OAuth Apps can act on _all_** of the authenticated user’s repositorie**s.
  • 不要 构建 OAuth App 作为你 团队或公司的应用。OAuth Apps 以 单个用户 身份进行认证，所以如果某人为公司创建了 OAuth App，后来离职，则其他人将无法访问该应用。
  • 更多信息 在 这里。

Github Applications

Github applications 可以请求权限以 访问你的 github 信息或以你的身份执行 针对特定资源的操作。在 Github Apps 中，你需要指定该应用将能访问的 repositories。

一些安全建议：

  • 一个 GitHub App 应该 独立于用户采取行动（除非该应用使用 user-to-server token）。为了使 user-to-server 访问令牌更安全，你可以使用将在 8 小时后过期的 access tokens，以及可以换取新 access token 的 refresh token。更多信息，参见 “Refreshing user-to-server access tokens.”
  • 确保 GitHub App 与 特定的 repositories 集成。
  • GitHub App 应该 连接到个人账户或组织。
  • 不要期望 GitHub App 能了解并完成用户能做的所有操作。
  • 如果你仅需要“Login with GitHub”服务，请不要使用 GitHub App。 但 GitHub App 可以使用 user identification flow 来登录用户并执行其他操作。
  • 如果你只是想作为一个 GitHub 用户去做该用户能做的一切，不要构建 GitHub App。
  • 如果你在 GitHub Actions 中使用你的应用并想修改 workflow 文件，必须代表用户使用包含 workflow scope 的 OAuth token 进行身份验证。用户必须对包含 workflow 文件的仓库具有 admin 或 write 权限。更多信息，见 “Understanding scopes for OAuth apps.”
  • 更多信息 在 这里。

Github Actions

这 并不是在 github 中进行身份验证的一种方式，但一个 恶意的 Github Action 可能会获得 未授权的 github 访问，并且根据赋予该 Action 的 权限，可以实施多种 不同的攻击。下面会有更多信息。

Git Actions

Git actions 允许在 某个事件发生时自动执行代码。通常被执行的代码与仓库中的代码 某种程度相关（例如构建 docker 容器或检查 PR 中是否包含 secrets）。

Configuration

在 https://github.com/organizations/<org_name>/settings/actions 可以查看组织的 github actions 的配置。

可以完全禁止使用 github actions、允许所有 github actions，或仅允许特定的 actions。

还可以配置 谁需要批准运行一个 Github Action 以及 Github Action 运行时的 GITHUB_TOKEN 的权限。

Git Secrets

Github Action 通常需要某种 secrets 来与 github 或第三方应用交互。为了 避免将它们以明文放入仓库，github 允许将它们作为 Secrets 存放。

这些 secrets 可以为单个 repo 配置，也可以为整个组织配置。然后，为了让 Action 能够访问该 secret，你需要像下面这样声明它：

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}

使用 Bash 的示例 

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Warning

Secrets 只能从声明了它们的 Github Actions 访问。

一旦在 repo 或组织中配置后，github 的用户将无法再次访问它们，他们只能 更改它们。

因此，窃取 github secrets 的唯一方法是能够访问正在执行该 Github Action 的机器（在这种情况下你只能访问为该 Action 声明的 secrets）。

Git 环境

Github 允许创建 环境，在其中可以保存 secrets。然后，你可以像下面这样给 github action 授予对该环境内 secrets 的访问权限：

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

You can configure an environment to be accessed by all branches (default), only protected branches or specify which branches can access it.
Additionally, environment protections include:

  • Required reviewers: gate jobs targeting the environment until approved. Enable Prevent self-review to enforce a proper four‑eyes principle on the approval itself.
  • Deployment branches and tags: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the “Protected branches only” option applies to classic branch protections and may not behave as expected if using rulesets.
  • Wait timer: delay deployments for a configurable period.

It can also set a number of required reviews before executing an action using an environment or wait some time before allowing deployments to proceed.

Git Action Runner

A Github Action can be executed inside the github environment or can be executed in a third party infrastructure configured by the user.

Several organizations will allow to run Github Actions in a third party infrastructure as it use to be cheaper.

You can list the self-hosted runners of an organization in https://github.com/organizations/<org_name>/settings/actions/runners

The way to find which Github Actions are being executed in non-github infrastructure is to search for runs-on: self-hosted in the Github Action configuration yaml.

It’s not possible to run a Github Action of an organization inside a self hosted box of a different organization because a unique token is generated for the Runner when configuring it to know where the runner belongs.

If the custom Github Runner is configured in a machine inside AWS or GCP for example, the Action could have access to the metadata endpoint and steal the token of the service account the machine is running with.

Git Action Compromise

If all actions (or a malicious action) are allowed a user could use a Github action that is malicious and will compromise the container where it’s being executed.

Caution

A malicious Github Action run could be abused by the attacker to:

  • Steal all the secrets the Action has access to
  • Move laterally if the Action is executed inside a third party infrastructure where the SA token used to run the machine can be accessed (probably via the metadata service)
  • Abuse the token used by the workflow to steal the code of the repo where the Action is executed or even modify it.

Branch Protections

Branch protections are designed to not give complete control of a repository to the users. The goal is to put several protection methods before being able to write code inside some branch.

The branch protections of a repository can be found in https://github.com/<orgname>/<reponame>/settings/branches

Note

It’s not possible to set a branch protection at organization level. So all of them must be declared on each repo.

Different protections can be applied to a branch (like to master):

  • You can require a PR before merging (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
  • Require a number of approvals. It’s very common to require 1 or 2 more people to approve your PR so a single user isn’t capable of merge code directly.
  • Dismiss approvals when new commits are pushed. If not, a user may approve legit code and then the user could add malicious code and merge it.
  • Require approval of the most recent reviewable push. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
  • Require reviews from Code Owners. At least 1 code owner of the repo needs to approve the PR (so “random” users cannot approve it)
  • Restrict who can dismiss pull request reviews. You can specify people or teams allowed to dismiss pull request reviews.
  • Allow specified actors to bypass pull request requirements. These users will be able to bypass previous restrictions.
  • Require status checks to pass before merging. Some checks need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., “@bot-name skip”).
  • Require conversation resolution before merging. All comments on the code needs to be resolved before the PR can be merged.
  • Require signed commits. The commits need to be signed.
  • Require linear history. Prevent merge commits from being pushed to matching branches.
  • Include administrators. If this isn’t set, admins can bypass the restrictions.
  • Restrict who can push to matching branches. Restrict who can send a PR.

Note

As you can see, even if you managed to obtain some credentials of a user, repos might be protected avoiding you to pushing code to master for example to compromise the CI/CD pipeline.

Tag Protections

Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:

  1. On the tag protection rule, enable Require deployments to succeed and require a successful deployment to a protected environment (e.g., prod).
  2. In the target environment, restrict Deployment branches and tags to the release branch (e.g., main) and optionally configure Required reviewers with Prevent self-review.
  3. On the release branch, configure branch protections to Require a pull request, set approvals ≥ 1, and enable both Dismiss approvals when new commits are pushed and Require approval of the most recent reviewable push.

This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.

References

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks