脆弱性としてのソースコード – Twitchの情報流出がもたらす真のセキュリティ脅威を究明

Twitchのソースコードが公開された事により明らかになった情報について、一般的にはストリーマー（動画配信者）の収益に注目が集まっていますが、6,000のGitリポジトリを調査した結果、今回の侵害のみならず、はるかに深刻な問題があることが判明しました。

この記事はGitGuardian社のブログを翻訳したものです。
原題：Source Code as a Vulnerability – A Deep Dive into the Real Security Threats From the Twitch Leak

https://blog.gitguardian.com/security-threats-from-the-twitch-leak/

ここで公開された情報は、Twitchに損害を与えるものではありません。また、GitGuardianは発見された脆弱性の概要を記した詳細レポートをTwitchに提出しました。

2021年の初めに、Twitchは意図せずしてソースコードが公開された企業リストに新たに名を連ねることとなりました。このケースでは、Twitchに属する全てのソースコードが4chanフォーラムに公開され、その中には6,000に及ぶGitの内部レポジトリと、解凍後の合計サイズが200GBに達する3,000,000のドキュメントが含まれていました。

この漏えいには、Twitchの様々な製品、シークレットプロジェクト、子会社、内部ツール、従業員のリポジトリなどのソースコードが含まれていました。また、ストリーマーの収益などのデータベース情報も流出しました。

私たちは、6,000のGitリポジトリにあるシークレットや機密情報について時間をかけて調査しました。今回、流出したストリーマーの収入に注目が集まっていますが、調査の結果、本件の侵害をはるかに超える、より深刻な問題があることがわかりました。

Twitchのコードベースを解明

TwitchのGitリポジトリには、6,600近いシークレットが存在していることがわかりました。その中には194のAWSキー、69のTwilioキー、68のGoogle APIキー、何百ものデータベース接続文字列、14のGitHub OAuthキー、そして4つのStripeキーなどが含まれており、これはほんの一例です。

今回の侵害で最も問題なのは、これだけの量の機密データが見つかっても、実は驚くようなことではないということです。流出したデータの規模を考えると、見つけたシークレットの多さは、私たちの新規顧客に見られるものと比較すると妥当なものです。また、セキュリティツールの使用状況も多く見られ、AppSec（アプリケーションセキュリティ）がある程度成熟していることを示すとともに、ソースコードのシークレットの漏えい問題が、大小問わず全ての組織にとっていかに厄介な問題であるかを示しています。 プライベートコードに攻撃者がアクセスした例は数多くありますが、今回のTwitchの不正アクセスは、悪意ある攻撃者がソースコードを公開したことに特徴があります。このことが、私たちが悪意のある攻撃者の視点に立ち、侵害を調査するきっかけとなりました。そうすることで、シークレットなどの機密情報を始め、実際のプロダクションコードベースのセキュリティの脆弱性を調査することができました。

免責事項：  通常、GitGuardianはリポジトリで見つかったキーを検証し、誤検知を排除しています。しかし今回は、現在進行中の調査が間違いなく行われるため、GitGuardianはフォレンジックチームに誤解を与えないよう、キーの検証を行わないことにしました。このため、流出時に有効だったキーの割合を示すことはできません。

コードへの初期アクセスの取得

現在でも、攻撃者がどのように情報を収集し、その動機は何なのか、正確なことは分かっていません。この件に関するTwitchからの情報は、以下のものだけでした。

「今回のインシデントは、サーバーの構成変更により、権限のない第三者による不適切なアクセスを許してしまったことが原因です。」

これは、彼らが誤ってサーバーを不正にアクセス可能な状態にした可能性があるということ以外、あまり多くの情報を与えてはくれません。バックアップサーバーやGitサーバーの可能性もありますが、わかっているのは、攻撃者がGitリポジトリといくつかのデータベースにアクセスできたということです。

私たちは、他の侵害の例から、攻撃者がプライベートコードにアクセスする方法はたくさんあることを知っています。2016年のUberのケースでは、攻撃者はパスワードの衛生状態が悪いことを利用してアクセスすることができました。インド政府の侵害のケースでは、攻撃者はドメインをファジングすることで誤った構成のGitリポジトリを見つけ、Codecovの侵害では、攻撃者はDockerイメージを悪用してコードリポジトリにアクセスしています。重要なのは、Gitリポジトリは大変価値のある標的となりつつあり、攻撃者が侵入するためには、セキュリティチェーンに小さな亀裂が入るだけで済むのです。

セキュリティとの関係

Twitchの場合、メディアの主な見解は、セキュリティリスクはなく、重要な顧客データは流出していないとしています。我々の調査結果は、これを真っ向から否定するものであり、今回の情報漏えいでは、（ストリーマーの収入以外の）顧客情報は直接的には漏えいしていないかもしれませんが、我々が発見した膨大なシークレットは、この漏えいに関わる大きなセキュリティ上の懸念があることを如実に物語っています。

約6,000のリポジトリのうち、（履歴を含む）1,100以上のリポジトリに少なくとも1つのシークレット候補が含まれていました。では、この情報にアクセスした攻撃者がどのような行動をとるか、見ていきましょう。今回の場合、攻撃者はコードを4chanに公開することにしましたが、攻撃者がこの情報を公開せず、Twitchが侵害に気付くことなく、攻撃者が発見した機密情報を悪用するのに十分な時間があったというシナリオを想像してください。

攻撃のシミュレーション

そこで、悪意ある攻撃者と同じ目線で、彼らが取るであろう手順をシミュレーションしてみることにしました。この例では、整理すべきデータが多すぎて、何千ものキーがあるにもかかわらず、最も興味深いものを素早く特定することが困難かもしれません。私たちの場合、次のようなアプローチをとりました。

1. さまざまなシークレットを識別し、カテゴリーに分類する
2. 高付加価値キーと高付加価値リポジトリを結び付ける

高付加価値シークレットとセカンダリシークレットを識別

攻撃者としての最初のステップは、コードベース全体をスキャンしてシークレットを探ることでしょう。これは、アクセスできるツールによっては、非常に困難な場合があります。AWSキーのように特定のパターンに従ったキーもありますが、ほとんどは単純な高エントロピーの文字列で、見つけるのがより難しく、誤検出も多くなります。幸いなことに、私たちはGitGuardianの強力な検出エンジンを利用して、これらのシークレットを正確に見つけることができるという利点があります。

次にそれらを明らかにした上で、3つのカテゴリーに分類する必要があります。

インフラとサービスキー	データキー	セカンダリ攻撃キー
例 ・クラウドサービスキー ・決済システムキー	例 ・データベースクレデンシャル ・S3バケットキー ・暗号化キー	例 ・reCAPTCHA ・メッセージングシステム（Slack、Twilio）

攻撃者としての目的に応じて、特定のカテゴリーに焦点を当てることができます。サービスを停止させたり、トラフィックを誘導したり、コンピュータの処理能力を自分の邪悪な計画のために利用したい場合、インフラキーにフォーカスすることができます。データの窃取、暗号化、あるいは悪用が目的であれば、データベースへのアクセスに集中すればよいでしょう。しかし、そのキーが関わる範囲を超えて組織に侵入したり、アカウントを乗っ取ったりしたい場合は、セカンダリ攻撃キーと呼ばれるものに焦点を当てることができます。これらのキーは、Twilioなどのツールを使ってユーザーにメッセージを送信したり、reCaptchaなどのセキュリティ機能を回避したり、内部メッセージングシステムを使って権限を昇格させようとする、標的型のスピアフィッシングキャンペーンを展開するためのものです。

Twitchの例では、どんな邪悪な計画にも対応できるキーの発見には事欠きません。キーを見つけて分類した後は、誤検知を除外するようにします。簡単な方法としては、バックエンドを呼び出すスクリプトを使ってキーを検証することができます。今回のケースでは、進行中のフォレンジックを中断させないために、これを行わないことにしました。

そこで、私たちは異なる方法で調査しました。

• 「テスト」のようなテスト目的を示すキーワードを検索する
• リーク日に最も近い侵害を検索する

PayPalのBraintreeキー（決済サービス）を例にとると、プロダクション（本番）で使うキーとSANDBOX環境で使うキーをすぐさま選別することができます。

以下の例では、config.pyファイルに含まれるAWSキーが、情報漏えいが発生した同じ日に侵害されていることがわかり、利用価値のあるシークレットとしてみなされます。

このような情報漏えいは、大量の機密情報を含んでいるため、攻撃者が狙う攻撃パスは種類によって異なります。 以下に例を示します。

もちろん、多数の内部システムやツールにアクセスできる可能性のあるクレデンシャルも山ほどあります。

付加価値の高いシークレットを見つけるもう一つの方法は、単純にリポジトリの名前を探すことです。

この例では、Backend/CloudServicesという名前のリポジトリに14個のAWSキーがあり、これらはおそらく価値の高いレポジトリであると思われます。ビンゴ！これによって、どこに注意を向けるべきか、どのサービスを最初に攻撃すればよいかがよく分かります。あとは、攻撃者として、すぐに成果を上げられそうなシークレットから始めて、セカンダリ攻撃キーを使って、より長く、より複雑な攻撃パスへと、邪悪な計画を実行するのみです。

さらに大きな問題

さて、ここで、問題の核心は、Twitchのソースコードが流出したことにあるかのように見えるかもしれませんが、実はそうではありません。ソースコードが悪用されることはよくあることであり、これはソースコードが漏えいしやすいアセットであり、多くのサーバー、ワークステーション、ネットワークを経由するため、漏えいが起こる可能性が低いとは言えないからです。おそらく、コードが公開されるよりもずっと悪いのは、アクセスした攻撃者が黙っておらず、内部の秘密を搾取するために黙々と作業している場合です。実際、このコードを流出させた人物は、Twitchにとって好都合だったようです。なぜなら、おそらくもっと悪意のある攻撃者も誤った構成のサーバーを発見し、攻撃する可能性を防いでくれたからです。

セキュリティの本当の問題は、ソースコードが流出することではなく、ソースコード自体が脆弱性であるにもかかわらず、セキュリティインシデントが発生するまでそれを受け入れないことです。Twitchのソースコードを深く掘り下げた結果、Twitchはセキュリティを真剣に考えず、アプリケーションセキュリティの観点から成熟の兆しを見せていない組織ではなかったと、改めて断言することができます。問題は組織レベルではなく、業界レベルだと言えます。  私たちは皆、自分たちのソースコードが流出することを想定し、ソースコードが脆弱性にならないようなセキュリティ対策を施さなければならないのです。

シークレットスプロール（機密情報の拡散）の防止

シークレットスプロールとは、Twitchの例で明らかなように、シークレットが不必要に分散されることです。単純な話、シークレットスプロールを完全に防ぐことは非常に難しいと言えます。なぜなら、人為的ミスが伴い、シークレットは高い精度と再現性で検出することが実は非常に難しいからです（これについてはこのブログ記事全体を参照）。しかし、これは、侵害が起こる前に特定し、行動を起こせないことを意味するものではありません。

シークレットスプロールを防ぐには、3つの分野に焦点を当てる必要があります。

1. 開発者がシークレットを犯すことを未然に防ぐために、権限を与えること
2. シークレットが漏れたときに（必ず漏れる）、リアルタイムで検出するツール
3. 従業員が公開しているGitリポジトリなど、組織がコントロールできない場所を監視するツール

GitGuardianは2017年からこの課題に取り組んでおり、ソフトウェア開発ライフサイクル内の全ての人がシークレットスプロールの解決に参加できるようにしています。  GitGuardian Shieldは、オープンソースの開発者向けツールで、開発者自身がシークレットの漏えいを防ぐというシフトレフト戦略をとっています。内部リポジトリモニタリングのためのアプリケーションセキュリティプラットフォームでは、セキュリティ担当者やプロジェクトリーダーがリポジトリにシークレットがないことを確認し、ソースコードが流出しても新たなセキュリティ問題が発生しないようにすることができ、最後にパブリックモニタリングソリューションでは、組織の管轄範囲外でどのようにシークレットが流出しているかを可視化することができます。

詳細はGitGuardianについてテリロジーワークスへお問い合わせください。