Github Security

Reading time: 25 minutes

What is Github

(From here) 高いレベルで言うと、GitHubは開発者がコードを保存・管理し、コードの変更を追跡・制御するのを助けるウェブサイトおよびクラウドベースのサービスです。

Basic Information

Basic Github Information

External Recon

Githubリポジトリは、公開、非公開、内部として設定できます。

• 非公開は、組織の人だけがアクセスできることを意味します。
• 内部は、エンタープライズの人（エンタープライズには複数の組織がある場合があります）だけがアクセスできることを意味します。
• 公開は、全インターネットがアクセスできることを意味します。

ターゲットにしたいユーザー、リポジトリ、または組織を知っている場合、github dorksを使用して、各リポジトリで機密情報や機密情報の漏洩を検索できます。

Github Dorks

Githubは、ユーザー、リポジトリ、または組織を指定して何かを検索することを許可します。したがって、機密情報の近くに表示される文字列のリストを使用して、ターゲット内の潜在的な機密情報を簡単に検索できます。

ツール（各ツールにはそのdorkのリストがあります）：

• https://github.com/obheda12/GitDorker (Dorks list)
• https://github.com/techgaun/github-dorks (Dorks list)
• https://github.com/hisxo/gitGraber (Dorks list)

Github Leaks

github dorksは、githubの検索オプションを使用して漏洩を検索するためにも使用されることに注意してください。このセクションは、各リポジトリをダウンロードし、その中で機密情報を検索するツールに専念しています（特定のコミットの深さをチェックすることも含まれます）。

ツール（各ツールにはその正規表現のリストがあります）：

• https://github.com/zricethezav/gitleaks
• https://github.com/trufflesecurity/truffleHog
• https://github.com/eth0izzle/shhgit
• https://github.com/michenriksen/gitrob
• https://github.com/anshumanbh/git-all-secrets
• https://github.com/kootenpv/gittyleaks
• https://github.com/awslabs/git-secrets

External Forks

プルリクエストを悪用してリポジトリを妥協することが可能です。リポジトリが脆弱かどうかを知るには、主にGithub Actionsのyaml設定を読む必要があります。この下に詳細があります。

Github Leaks in deleted/internal forks

削除されたリポジトリや内部リポジトリから機密データを取得することが可能な場合があります。ここで確認してください：

Accessible Deleted Data in Github

Organization Hardening

Member Privileges

組織のメンバーに割り当てることができるデフォルトの権限があります。これらは、ページ https://github.com/organizations/<org_name>/settings/member_privileges または Organizations API から制御できます。

• 基本的な権限: メンバーは、組織のリポジトリに対してNone/Read/write/Adminの権限を持ちます。推奨はNoneまたはReadです。
• リポジトリのフォーク: 必要でない場合、メンバーが組織のリポジトリをフォークすることを許可しない方が良いです。
• ページの作成: 必要でない場合、メンバーが組織のリポジトリからページを公開することを許可しない方が良いです。必要な場合は、公開または非公開のページを作成することを許可できます。
• 統合アクセス要求: これを有効にすると、外部のコラボレーターがこの組織とそのリソースにアクセスするためのGitHubまたはOAuthアプリへのアクセスを要求できるようになります。通常は必要ですが、必要でない場合は無効にする方が良いです。
• この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。
• リポジトリの可視性変更: 有効にすると、リポジトリの管理者権限を持つメンバーが可視性を変更できるようになります。無効にすると、組織の所有者のみがリポジトリの可視性を変更できます。人々に公開にすることを望まない場合は、これを無効にしてください。
• この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。
• リポジトリの削除と移行: 有効にすると、リポジトリの管理者権限を持つメンバーが公開および非公開のリポジトリを削除または移行できるようになります。
• この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。
• メンバーがチームを作成することを許可: 有効にすると、組織のメンバーは新しいチームを作成できるようになります。無効にすると、組織の所有者のみが新しいチームを作成できます。これを無効にしておく方が良いです。
• この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。
• このページで他の設定も可能ですが、前述のものが最もセキュリティに関連しています。

Actions Settings

いくつかのセキュリティ関連の設定は、ページ https://github.com/organizations/<org_name>/settings/actions から構成できます。

• Github actionsポリシー: どのリポジトリがワークフローを実行でき、どのワークフローが許可されるべきかを指定できます。許可されるリポジトリを指定することを推奨し、すべてのアクションを実行することを許可しない方が良いです。
• API-1, API-2
• 外部コラボレーターからのフォークプルリクエストワークフロー: すべての外部コラボレーターに対して承認を要求することを推奨します。
• この情報を持つAPIは見つかりませんでした。知っている場合は共有してください。
• フォークプルリクエストからのワークフローの実行: プルリクエストからのワークフローを実行することは非常に推奨されません。フォーク元のメンテナーに、ソースリポジトリに対する読み取り権限を持つトークンを使用する能力が与えられるためです。
• この情報を持つAPIは見つかりませんでした。知っている場合は共有してください。
• ワークフローの権限: リポジトリの読み取り権限のみを付与することを強く推奨します。GITHUB_TOKENが実行中のワークフローに与えられることを避けるために、書き込みやプルリクエストの作成/承認権限を与えることは推奨されません。
• API

Integrations

この情報にアクセスするためのAPIエンドポイントを知っている場合は教えてください！

• サードパーティアプリケーションアクセスポリシー: すべてのアプリケーションへのアクセスを制限し、必要なもののみを許可することを推奨します（レビュー後）。
• インストールされたGitHubアプリ: 必要なもののみを許可することを推奨します（レビュー後）。

Recon & Attacks abusing credentials

このシナリオでは、githubアカウントへのアクセスを取得したと仮定します。

With User Credentials

もし何らかの方法で組織内のユーザーの資格情報を持っている場合、ただログインして、どのエンタープライズおよび組織の役割を持っているかを確認できます。生のメンバーであれば、生のメンバーが持つ権限、どのグループに属しているか、どのリポジトリに対してどの権限を持っているか、およびリポジトリがどのように保護されているかを確認できます。

2FAが使用されている可能性があることに注意してください。したがって、そのチェックを通過できる場合にのみ、この情報にアクセスできます。

役立つ場合に備えて、以下のセクションでブランチ保護のバイパスについて確認してください。

With User SSH Key

Githubは、ユーザーがSSHキーを設定し、コードをデプロイするための認証方法として使用できるようにしています（2FAは適用されません）。

このキーを使用して、ユーザーがいくつかの権限を持つリポジトリで変更を行うことができますが、github APIにアクセスして環境を列挙するために使用することはできません。ただし、ローカル設定を列挙して、アクセスできるリポジトリやユーザーに関する情報を取得できます。

# Go to the the repository folder
# Get repo config and current user name and email
git config --list

ユーザーが自分のGitHubユーザー名としてユーザー名を設定している場合、https://github.com/<github_username>.keys で彼のアカウントに設定された公開鍵にアクセスできます。これを確認して、見つけた秘密鍵が使用できるかどうかを確認できます。

SSH鍵はリポジトリにデプロイ鍵としても設定できます。この鍵にアクセスできる人は、リポジトリからプロジェクトを起動できるようになります。通常、異なるデプロイ鍵を持つサーバーでは、ローカルファイル**~/.ssh/config**が関連する鍵に関する情報を提供します。

GPG鍵

こちらで説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。

現在のユーザーが任意の鍵を持っているかどうかをローカルで確認してください:

gpg --list-secret-keys --keyid-format=long

With User Token

ユーザートークンの基本情報については、こちらを確認してくださいの紹介。

ユーザートークンは、HTTPS経由のGitのパスワードの代わりに使用できるか、または基本認証を介してAPIに認証するために使用できます。付与された権限に応じて、さまざまなアクションを実行できる場合があります。

ユーザートークンは次のようになります: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123

With Oauth Application

Github Oauthアプリケーションの基本情報については、こちらを確認してくださいの紹介。

攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある悪意のあるOauthアプリケーションを作成して、特権データやアクションにアクセスすることがあります。

これらは、Oauthアプリケーションが要求できるスコープです。常に要求されたスコープを確認してから受け入れるべきです。

さらに、基本情報で説明されているように、組織はサードパーティアプリケーションに対して情報/リポジトリ/アクションへのアクセスを与えたり拒否したりできます。

With Github Application

Githubアプリケーションの基本情報については、こちらを確認してくださいの紹介。

攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある悪意のあるGithubアプリケーションを作成して、特権データやアクションにアクセスすることがあります。

さらに、基本情報で説明されているように、組織はサードパーティアプリケーションに対して情報/リポジトリ/アクションへのアクセスを与えたり拒否したりできます。

Compromise & Abuse Github Action

Github Actionを妨害し悪用するためのいくつかの技術があります。ここで確認してください:

Abusing Github Actions

Branch Protection Bypass

• 承認の数を要求: 複数のアカウントを妨害した場合、他のアカウントから自分のPRを承認することができます。PRを作成したアカウントしか持っていない場合、自分のPRを承認することはできません。しかし、リポジトリ内のGithub Action環境にアクセスできる場合、GITHUB_TOKENを使用してPRを承認し、この方法で1つの承認を得ることができるかもしれません。
• この点とCode Owners制限についての注意: 通常、ユーザーは自分のPRを承認できませんが、もしできる場合は、それを悪用して自分のPRを承認できます。
• 新しいコミットがプッシュされたときに承認を取り消す: これが設定されていない場合、正当なコードを提出し、誰かが承認するのを待ってから、悪意のあるコードを追加して保護されたブランチにマージできます。
• Code Ownersからのレビューを要求: これが有効になっていて、あなたがCode Ownerであれば、Github ActionがあなたのPRを作成し、その後自分で承認することができます。
• CODEOWNERファイルが誤設定されている場合: Githubは文句を言いませんが、それを使用しません。したがって、誤設定されている場合は、Code Ownersの保護が適用されません。
• 指定されたアクターがプルリクエストの要件をバイパスできるようにする: あなたがこれらのアクターの1人であれば、プルリクエストの保護をバイパスできます。
• 管理者を含める: これが設定されていない場合、リポジトリの管理者であれば、このブランチの保護をバイパスできます。
• PRハイジャック: 他の誰かのPRを変更して悪意のあるコードを追加し、結果として得られたPRを自分で承認してすべてをマージできるかもしれません。
• ブランチ保護の削除: あなたがリポジトリの管理者であれば、保護を無効にし、PRをマージして保護を再設定できます。
• プッシュ保護のバイパス: リポジトリが特定のユーザーのみがブランチにプッシュ（コードをマージ）できるようにしている場合（ブランチ保護がすべてのブランチを保護している可能性がありますが、ワイルドカード*を指定しています）。
• リポジトリに対する書き込みアクセスがあるが、ブランチ保護のためにコードをプッシュできない場合、新しいブランチを作成し、その中でコードがプッシュされたときにトリガーされるGithub Actionを作成できます。ブランチ保護はブランチが作成されるまで保護しないため、この最初のコードプッシュはGithub Actionを実行します。

Bypass Environments Protections

Github環境の基本情報については、こちらを確認してください。

環境にすべてのブランチからアクセスできる場合、それは保護されていないため、環境内のシークレットに簡単にアクセスできます。すべてのブランチが保護されているリポジトリ（名前を指定するか、*を使用することによって）を見つけることがあることに注意してください。その場合、コードをプッシュできるブランチを見つけ、新しいGithub Actionを作成することでシークレットを抽出できます（または1つを変更することができます）。

すべてのブランチが保護されている（ワイルドカード*を介して）場合、誰がブランチにコードをプッシュできるかが指定されているエッジケースがあることに注意してください（これはブランチ保護で指定できます）し、あなたのユーザーは許可されていません。それでもカスタムGithub Actionを実行できます。なぜなら、ブランチを作成し、その上でプッシュトリガーを使用できるからです。ブランチ保護は新しいブランチへのプッシュを許可するため、Github Actionがトリガーされます。

push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch

注意してください。ブランチの作成後、ブランチ保護が新しいブランチに適用され、変更することはできませんが、その時点で既に秘密をダンプしているでしょう。

永続性

• ユーザートークンを生成
• シークレットからgithubトークンを盗む
• ワークフローの結果とブランチの削除
• 全ての組織に対してより多くの権限を付与
• 情報を外部に流出させるためのウェブフックを作成
• 外部コラボレーターを招待
• SIEMで使用されているウェブフックを削除
• バックドアを持つGithub Actionを作成/変更
• シークレット値の変更を通じてコマンドインジェクションに脆弱なGithub Actionを見つける

偽のコミット - リポジトリコミットを介したバックドア

Githubでは、フォークからリポジトリにPRを作成することが可能です。PRが受け入れられなくても、元のリポジトリ内にフォーク版のコードのコミットIDが作成されます。したがって、攻撃者はリポジトリの所有者によって作成されていない、見た目上正当なリポジトリから特定のコミットを使用するようにピン留めすることができます。

これのように：

name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'

詳細については、https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cdを確認してください。