Unit 42 クラウド脅威レポート: GitHub上に公開された機密データ

This post is also available in: English (英語)

概要

Unit 42クラウド脅威レポート: 2020年春版では、クラウド内のどこで設定ミスが発生しているのかをDevOps上のプラクティスにとくに注目して確認しました。本稿では、GitHubリポジトリに関する詳細分析を提供し、すべてのチーム（DevOpsチーム、エンジニアリング チーム、セキュリティ チーム）が問題を早期発見・修正できるよう、セキュリティ チェックを「シフトレフト」する必要性について論じます。

GitHubは、開発から生産まで、コードをすばやくトラッキングするために広く活用されているデータリポジトリで、これほど活用されているレポジトリもそうありません。ですが、以前から言われるとおりで「採用スピードが速いものはそれだけリスクも高い」と言えます。

弊社のリサーチャーは、「組織による公開GitHubアカウント利用にDevOpsによる機密情報漏えいの可能性の高さが合わされば、データ損失や持続的な侵害インシデントのリスクが高まる」ということを発見しています。ただし、DevSecOpsを適切に実施し、GitHub Event APIスキャナを使用すれば、侵害につながる情報を公開してしまうリスクを大幅に低減することができます。

本調査で得られた主な知見

Unit 42 リサーチャーは、GitHubs Event API経由で24,000件以上の公開GitHubデータアップロードを分析しました。これにより機密情報を含む可能性のある数千個のファイルを発見しました。以下は見つかったファイル種別の一例です。

GitHub Event API

GitHubは開発者にEvent API検索機能へのアクセスを提供しています。これによりGitHubサーバーに投稿されたファイルとコードをほぼリアルタイムで一覧表示することができます。アカウントごとに1時間あたり5,000件という制限はありますが、Event APIを使用することで、Githubにプッシュされたパブリックドメインで利用可能なファイル（公開された共有など）を表示・スキャンすることができます。この機能を利用するツールはいくつかあり、商業的なものではGitHub自身が運営・メンテナンスするGitHub Token Scannerがあげられます。このツールは、ファイルのトークン文字列を検査し、詐欺や悪用を防いでいます。AWS git-secretsはAWSで使うツールで、ユーザー名やパスワードをはじめとする重要文字列の有無がスキャンされ、それらが公開されないようにします。このほかにオープンソースのGitHub Event APIスキャナもあります。たとえばgitrobやtrugglehogなどがその例で、レッドチームやペンテスターにくわえ悪意のあるユーザーもこれらオープン ソース ツールを潜在的機密情報の識別に利用しています。

ShhGit Live

図 1 shhgitのロゴ

今回Unit 42のリサーチャーはeth0izzle氏によるshhgitを使い、ほぼリアルタイムでGitHubイベントを読み出して次の3つの質問に答えてみることにしました。

• 1. ファイル内に潜在的な機密データは見つかったか
  2. それらをつかって特定組織にたどり着くことができたか
  3. 予防的なセキュリティ メカニズムにより潜在的な機密性の高いデータの意図せぬ公開を防げたか

端的に言えば上記の3つの質問の答えはすべて「Yes」でした。リサーチャーは、重複なしで24,000個以上のGitHubファイルの発見・分析に成功しました。これらのファイルは、shhgitによる120件の組み込み済みシグネチャ ルールと、Unit 42が独自に定義したシグネチャ ルールによってトリガーされたものです。今回のケースでは、以下のように潜在的に機密性の高いデータ エントリが多数発見されました。

• • 4,109個の設定ファイル
  • 2,464個のAPIキー
  • 2,328個のハードコードされたユーザー名とパスワード
  • 2,144個の秘密鍵ファイル
  • 1,089個のOAuthトークン

これらを分析することで、調査結果の有効性を確認することができました。また、ファイルの所有者、プロジェクト名、場合によっては情報を投稿した企業名を特定することもできました。

調査結果の内訳

ハードコードされたパスワード

「本調査結果で最も重要な発見はハードコードされたパスワードの存在だ」とリサーチャーは判断しています。合計で2,328 件のユーザー名とパスワードのエントリが見つかりました。そのうち重複なしのパスワードは880件、同じく重複なしのユーザー名は797件でした。これらのパスワードは、サービスへのURL APIエントリと、SSHの設定ファイル内で見つかったものです。ここでリサーチャーは「最も一般的なパスワードのトップ10に入るパスワード エントリは全体の18%のみ」という点に注目しました。パスワード「password」は合計72件で首位、次点はパスワード「secret」で51件でした。識別された最も一般的なトップ10パスワードの内訳については表1を参照してください。

表1: 識別された最も一般的なパスワード トップ10

さらに興味深いのは、重複なしの880個のパスワード エントリのうち、817個は3回以下、665個はその1回のみで利用されている点です。つまり、この統計を非常に興味深いものにしているのは、パスワード間にさほど重複が見られないという点です。たとえば、以下はそのなかから10個のパスワード エントリをサンプリングしたものです。

• • p4ssW0rde
  • P@##w0rd
  • Password!
  • qwerty123456789
  • simplepass123
  • sqluser2019
  • supersecret
  • wilson1234567
  • xxxxxxxxxxxxxxxxxxxx
  • Z*NsqgS5$@jHsF2

「主観的観点から、パスワードのなかには企業間で共通と考えられるものもある」とリサーチャーたちは指摘しています。そのほとんどは最小パスワード要件を満たしており、最初の2つの「password系」パスワードは覚えやすくもあります。ただし、これらパスワードは、悪意のある攻撃者に容易に推測される可能性があり、その多くがほとんどのブルートフォース辞書リストに含まれています。提供されたサンプルの他のエントリは、小文字と数字の組み合わせのみの非常に単純なパスワードや、20回「x」を繰り返しただけのものなどがありました。リサーチャーは、これらパスワードが「正規のパスワードである可能性が高い」としています。その根拠となるのが、これらのパスワードの示す擬似的な複雑性のパターン、そしてこれらのエントリのもつ一意性です。つまりこれらのパスワードは、エンジニアたちが自社の本番環境で実際に使用している可能性が高いパスワード、といえるのです。また、Redis、PostgreSQL、MongoDB、AMPQなど、広く使われているクラウドサービスへのURL APIリクエスト内でこれらパスワードの出現頻度が高いことから、リサーチャーたちは「似たような擬似的複雑性をもつパスワードがクラウド環境自体で使われている可能性が高い」と見ています。

これと対照的に、一時パスワードや動的パスワードの使用をうかがわせる可変パスワード エントリが使用されていたのは、重複なしで27件のみでした。その一例が$password、{password}、%Password%などです。これら27個の一意なパスワードは、識別された2,328個のパスワードのうち合計で67個でこれは全体の3％未満でしかありません。

ハードコードされたAPIキーとOAuthトークン

Unit 42 のリサーチャーは、トリガーされた24,000件以上のGitHubファイルの中から、2,464個のAPIキーと1,998個のOAuthトークンを特定しました。これらはほぼ一意であることが分かっています。トリガーされたGitHubファイル全体で見て、4回以上繰り返し使われたキーやトークンは15件のみ、最も多い12回繰り返し使われていたキーは1件のみでした（表2参照）。

表2 トップ15に入ったAPIキー

APIキーとOAuthキーの特質上、これらを使えば指定されたクラウド環境にユーザーが直接アクセスできるようになります。つまりAPIキーやOAuthトークンが攻撃者の手に渡ってしまえば、彼らはエンジニアになりすましてその環境をコントロールできるということです。クラウド環境で管理者権限でAPIキーが作成されていれば、最悪の場合、そのAPIキーさえ使用すれば誰でもクラウド アカウントに対する完全なアクセス権限を得られることになります。正当なAPIキーを意図せず公開してしまうインシデントは実際に発生しており、たとえばUpGuardが報告したインシデントはその好例でしょう。同社の報告書では、AWSのAPIキー、ログファイル、IaCテンプレートを含む1GBに近いデータがGitHubを介して公開されていたこと、サービスやインフラストラクチャの設定ファイルに含まれている正当なAPIキーが公開されていたことを詳細に報告しています。またこの資格情報とAPIキーは、ある営利組織が保有するルートアカウントに紐づくものであることもわかっています。

パスワード同様、キーやトークンも、正当なユーザーのみが知っておくための保護やコントロールが必要です。APIキーやOAuthトークンがロストしたり漏えいしたりした可能性があれば、ただちにそれらを失効させて再発行しなくてはいけません。表3は、識別された2,464個のAPIキーと1,098個のOAuthトークン、それらに対応する環境を示しています。

表3 API・OAuthキーとの対応が確認された環境

設定ファイルと秘密鍵ファイル

Unit 42のリサーチャーは、クラウドの実態調査を設定ファイルと秘密キーファイルの分析でしめくくっています。設定ファイルは、sshgit、Unit 42の両シグネチャ ルールで識別したファイル種別のうち、単独で最も多数を占めるカテゴリで、24,000個のファイルのほぼ17％を占めていました。なかでも最も多かった設定ファイル種別はDjangoのもので、識別済み設定ファイル全体の1/3をしめていました (表4参照)。Djangoはスピーディな開発・設計を支援するPythonベースwebフレームワークです。このほか、webデザインで広く利用されるスクリプト言語、PHPの設定ファイルも3位につけました。これらwebベースの設定ファイルによって組織のクラウド インフラストラクチャが公開されてしまえば、そこから容易にクラウド サーバーの内部への攻撃者によるアクセスを許してしまう可能性が生じます。これにより、エクスプロイトはもちろん、エクスプロイト後のオペレーションも容易になります。

表4 設定ファイルの種類トップ10

リサーチャーは環境設定ファイルやシェル設定ファイルの存在感が増していることを確認しています。こうした種類の設定ファイルは、システム環境やサービス環境に対するコントロールを提供するものです。シェルやSSH、プロファイル、Gitの設定ファイルなども、識別済み設定ファイルのトップ10リストに入っています。1つ前に説明したAPIキーやAOathキーとの関連で、サービスがユーザー名やパスワード、APIキー、トークン プレース ホルダを設定ファイルに含めることを要求することはさほど珍しいことではありません。リサーチャーは、設定ファイルの80％近くにユーザー名やパスワード、APIキー、OAuthトークンに関するなにがしかの情報が含まれていることを確認しています。

結論

Unit 42のリサーチャーは、ユーザーによりGitHubに機密データがアップロードされている実態を確認しました。こうした機密データには、次のようなものが含まれていました。

• • ハードコードされたユーザー名やパスワード
  • ハードコードされたAPIキー
  • ハードコードされたOAuthトークン
  • 内部サービスや環境の設定情報

先日公開済みのDevOpsに特化したクラウド脅威レポートでも指摘されているとおり、Unit 42はGitHubなどの公開リポジトリから取得するすべてのIaCテンプレートについて、CI/CDパイプラインの一環として脆弱性スキャンを徹底するよう強く推奨しています。これはスキャンしたほぼ半数のCloudFormationテンプレート(CFT)に、潜在的に脆弱な設定が含まれているためです。脆弱なクラウドテンプレートをデプロイしてしまう確率はかなり高いことから、GitHubコードの公開で組織内の機密情報をうっかり公開しないためにも、組織はGitHub Event APIスキャナを活用すべきでしょう。

緩和策

Unit 42のリサーチャーは、設定ファイルの機密情報を漏えいしないよう、GitHubリポジトリにコードを公開しているユーザーや組織が次の緩和策を取ることを推奨しています。

• • コードを記述するさいは、変数やコマンドライン引数を使う習慣を身につける。これによりコード サンプル内にハードコードされたユーザー名やパスワード、APIキー、OAuthトークンなどをなくすことができる。
  • 複雑なパスワードの使用を義務付けるパスワード セキュリティ ポリシーを導入する。
  • 公開ポリシーを導入し、外部ソース経由での内部機密データ共有を規制・防止する。
  • GitHub エンタープライズ アカウントの機能を活用し、公開共有のプラクティスをしっかり精査する。
  • AWS git-secrets、GitHub TokenScanner、gitrob、trugglehogなどのツールを活用し、トークンを識別・削除して公開されないようにする。

Unit 42クラウド脅威レポート: 2020年春版をダウンロードして、皆さんの組織に活用できる調査内容やベストプラクティスを学びましょう。

追加資料

• Unit 42 クラウド脅威レポート: 2020年春
• Unit 42 クラウド脅威レポート: Dockerレジストリから漏洩したコード