Github Security

htARTE(HackTricks AWS Red Team Expert) でAWSハッキングをゼロからヒーローまで学ぶ

HackTricksをサポートする他の方法:

Githubとは

こちらから)GitHubは、開発者がコードを保存および管理し、コードの変更を追跡および制御するのを支援するウェブサイトおよびクラウドベースのサービスです。

基本情報

pageBasic Github Information

外部リコン

Githubリポジトリは、公開、非公開、内部の設定ができます。

  • 非公開は、組織の人々だけがアクセスできることを意味します

  • 内部は、企業の人々だけがアクセスできることを意味します(企業には複数の組織がある場合があります)

  • 公開は、インターネット全体がアクセスできることを意味します。

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

Github Dorks

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

ツール(各ツールにはそれぞれのdorksリストが含まれています):

Githubの漏洩

Github dorksは、githubの検索オプションを使用して漏洩を検索するためにも意図されています。このセクションは、これらのツールに各リポジトリをダウンロードし、それらの中で機密情報を検索するために捧げられています(一定のコミットの深さをチェックすることもあります)。

ツール(各ツールにはそれぞれの正規表現のリストが含まれています):

リポジトリで漏洩を探すときにgit log -pなどを実行する際には、他のコミットを含む他のブランチにも秘密が含まれている可能性があることを忘れないでください!

外部フォーク

プルリクエストを悪用してリポジトリを侵害することができます。リポジトリが脆弱かどうかを知るためには、主にGithub Actionsのyaml構成を読む必要があります。詳細は以下を参照

組織の強化

メンバー権限

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

  • ベース権限:メンバーは、組織のリポジトリに対して権限なし/読み取り/書き込み/管理の権限を持ちます。推奨されるのは権限なしまたは読み取りです。

  • リポジトリのフォーク:必要ない場合は、組織のリポジトリをメンバーがフォークすることを許可しない方が良いです。

  • ページの作成:必要ない場合は、組織のリポジトリからページを公開することを許可しない方が良いです。必要な場合は、公開または非公開のページを作成することができます。

  • 統合アクセスリクエスト:これを有効にすると、外部コラボレーターがこの組織とそのリソースにアクセスするためにGitHubまたはOAuthアプリのアクセスをリクエストできます。通常は必要ですが、必要ない場合は無効にする方が良いです。

  • APIのレスポンスにこの情報が見つかりませんでした。見つけた場合は共有してください

  • リポジトリの可視性の変更:有効にすると、リポジトリ管理者権限を持つメンバー可視性を変更できます。無効にすると、リポジトリの可視性を変更できるのは組織の所有者だけです。公開を避けたい場合は、これが無効になっていることを確認してください。

  • APIのレスポンスにこの情報が見つかりませんでした。見つけた場合は共有してください

  • リポジトリの削除と移動:有効にすると、リポジトリの管理者権限を持つメンバーが公開および非公開のリポジトリを削除または移動できます。

  • APIのレスポンスにこの情報が見つかりませんでした。見つけた場合は共有してください

  • メンバーがチームを作成できるようにする:有効にすると、組織のメンバーは新しいチームを作成できます。無効にすると、チームを作成できるのは組織の所有者だけです。無効にしておく方が良いです。

  • APIのレスポンスにこの情報が見つかりませんでした。見つけた場合は共有してください

  • このページで設定できるものは他にもたくさんありますが、前述のものがセキュリティに関連するものです。

アクションの設定

アクションに関連するいくつかのセキュリティ関連の設定をページhttps://github.com/organizations/<org_name>/settings/actionsから設定できます。

これらの設定は、すべてのリポジトリで独立して設定することもできることに注意してください

  • Githubアクションポリシー:どのリポジトリでワークフローを実行できるか、どのワークフローを許可するかを指定できます。許可するリポジトリを指定し、すべてのアクションを実行しないようにすることが推奨されます。

  • 外部コラボレーターからのフォークプルリクエストワークフロー:すべての外部コラボレーターに承認を要求することが推奨されます。

  • この情報を含むAPIが見つかりませんでした。見つけた場合は共有してください

  • フォークプルリクエストからのワークフローの実行:フォーク元のメンテナーに、ソースリポジトリの読み取り権限を持つトークンを使用する権限が与えられるため、フォークプルリクエストからのワークフローの実行は強く推奨されません

  • この情報を含むAPIが見つかりませんでした。見つけた場合は共有してください

  • ワークフローの権限読み取りリポジトリ権限のみを与えることを強く推奨します。GITHUB_TOKENの悪用を避けるために、書き込みおよび作成/承認プルリクエスト権限を与えることは避けることが推奨されます。

統合

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

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

  • インストールされたGitHubアプリ:必要なもののみを許可することが推奨されています(レビュー後)。

偵察と資格情報を悪用した攻撃

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

ユーザー資格情報を使用する場合

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

2段階認証(2FA)が使用されている場合があるため、そのチェックをパスできる場合にのみこの情報にアクセスできます。

user_sessionクッキーを盗むことに成功した場合(現在はSameSite: Laxで構成されています)、資格情報や2FAを必要とせずにユーザーを完全になりすますことができます。

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

ユーザーSSHキーを使用する場合

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

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

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

ユーザーがユーザー名をgithubのユーザー名として構成している場合、彼がアカウントで設定した公開鍵にアクセスできます。これを確認して、見つけたプライベートキーを使用できるかどうかを確認できます。

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

GPG鍵

こちらで説明されているように、時にはコミットに署名する必要があるかもしれません。そうしないと発見されるかもしれません。

現在のユーザーがどのような鍵を持っているかをローカルで確認するには、以下をチェックしてください:

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

ユーザートークンを使用する場合

ユーザートークンに関する基本情報を確認する

ユーザートークンは、Git over HTTPSのパスワードの代わりとして使用することができるか、Basic Authenticationを介してAPIに認証するために使用できます。それに付随する権限に応じて、さまざまなアクションを実行できるかもしれません。

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

OAuthアプリケーションを使用する場合

Github OAuthアプリケーションに関する基本情報を確認する

攻撃者は、特権データ/アクションにアクセスするために悪意のあるOAuthアプリケーションを作成し、それをおそらくフィッシングキャンペーンの一環として受け入れるユーザーの特権データ/アクションにアクセスするかもしれません。

これらはOAuthアプリケーションがリクエストできるスコープです。受け入れる前にリクエストされたスコープを常に確認する必要があります。

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

Githubアプリケーションを使用する場合

Githubアプリケーションに関する基本情報を確認する

攻撃者は、特権データ/アクションにアクセスするために悪意のあるGithubアプリケーションを作成し、それをおそらくフィッシングキャンペーンの一環として受け入れるユーザーの特権データ/アクションにアクセスするかもしれません。

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

Githubアクションの侵害と悪用

Githubアクションを侵害および悪用するためのいくつかのテクニックがあります。こちらをチェックしてください:

pageAbusing Github Actions

ブランチ保護のバイパス

  • 承認数を要求する: 複数のアカウントを侵害した場合、他のアカウントからのPRを承認することができます。PRを作成したアカウントしか持っていない場合、自分のPRを承認することはできません。ただし、リポジトリ内のGithubアクション環境にアクセスできる場合、GITHUB_TOKENを使用して自分のPRを承認し、この方法で1つの承認を取得することができるかもしれません。

  • この点と通常、ユーザーは自分自身のPRを承認できないというコード所有者の制限について、自分のPRを承認することはできませんが、できる場合は、自分のPRを受け入れるために悪用することができます。

  • 新しいコミットがプッシュされると承認を取り消す: これが設定されていない場合、正当なコードを提出し、誰かが承認するのを待ってから悪意のあるコードを追加し、保護されたブランチにマージすることができます。

  • Code Ownersからのレビューを要求する: これが有効になっており、Code Ownersである場合、Githubアクションを作成して自分のPRを作成し、自分で承認することができます。

  • CODEOWNERファイルが誤構成されている場合、Githubは警告を出しませんが、それを使用しません。したがって、誤構成されている場合、Code Ownersの保護が適用されません

  • 指定されたアクターがプルリクエスト要件をバイパスできるようにする: これらのアクターの1人である場合、プルリクエストの保護をバイパスできます。

  • 管理者を含める: これが設定されていない場合、リポジトリの管理者である場合、このブランチ保護をバイパスできます。

  • PRハイジャック: 他の誰かのPRを変更して悪意のあるコードを追加し、結果のPRを自分で承認してすべてをマージすることができるかもしれません。

  • ブランチ保護の削除: リポジトリの管理者である場合、保護を無効にでき、自分のPRをマージしてから保護を再設定できます。

  • プッシュ保護をバイパスする: リポジトリが特定のユーザーのみにプッシュを許可している場合(ブランチ保護がワイルドカード*を指定してすべてのブランチを保護しているかもしれません)。

  • リポジトリに書き込みアクセス権があるが、ブランチ保護のためにコードをプッシュすることができない場合、新しいブランチを作成し、その中でコードがプッシュされるとトリガーされるgithubアクションを作成することができます。ブランチ保護は作成されるまでブランチを保護しないため、最初のコードプッシュがブランチに対してgithubアクションを実行します。

環境保護のバイパス

Github環境に関する基本情報を確認する

環境がすべてのブランチからアクセス可能である場合、それは保護されていないため、環境内のシークレットに簡単にアクセスできます。すべてのブランチが保護されている可能性があることに注意してください(その名前を指定するか、*を使用しているか)。その場合、コードをプッシュできるブランチを見つけて、新しいgithubアクションを作成(または変更)してシークレットを外部に出すことができます。

すべてのブランチが保護されている可能性があるエッジケースがあるかもしれません(ワイルドカード*を使用して)、誰がブランチにコードをプッシュできるかが指定されているこれをブランチ保護で指定できます)が、あなたのユーザーは許可されていないかもしれません。それでも、カスタムgithubアクションを実行できます。新しいブランチを作成し、自分自身にプッシュトリガーを使用できるためです。ブランチ保護は新しいブランチへのプッシュを許可するため、githubアクションがトリガーされます

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トークンを盗む

  • ワークフローの結果ブランチ削除する

  • 組織全体により多くの権限を与える

  • 情報を外部に持ち出すためのWebhookを作成する

  • 外部コラボレーターを招待する

  • SIEMによって使用されているWebhook削除する

  • バックドアを持つ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!'

詳細については、こちらをチェックしてください。

**htARTE (HackTricks AWS Red Team Expert)**を使用して、ゼロからヒーローまでAWSハッキングを学びましょう!

HackTricksをサポートする他の方法:

最終更新