気遣い（とはいえない）共有：認証情報の共有によって広がる侵害のリスク
目次
はじめに
銀行のログインポータルであれ、オープン・ソース・ソフトウェアであれ、あるいはオペレーティングシステム自体でさえも、現代のテクノロジーに対する依存性によって、技術専門家と一般大衆のどちらも他者のコードに頼るようになっています。すべてのコードを一から書くことはスケーラブルでないため、一貫性と実用性の必要性から、コードライブラリのようなものが生まれました。
環境が複雑になるにつれ、すでに利用可能なツールを自動化して再利用できる場所を見つけることが重要になります。
しかし、開発者がそういった確立済みのライブラリからのコードを独自のコードの基盤として使用する場合、「信頼の問題」が発生します。つまり、セキュリティ専門家が危険と考えるかもしれないレベルの信頼が必要とされます。脆弱性が隠れているのがソースコードのより下層であればあるほど、発見がより困難になります。そしてこれは、そもそも脆弱性があることを知っていて探そうとすることを前提とした場合です。
私たちは自社の開発プロセスで、このようないわゆる信頼の問題の一例に遭遇しました。 外部サービスの 1 つの一見いつも通りの使用が、最終的に複数の重大な攻撃機会の発見につながりました。この情報をベンダーに開示した後、特定された問題は対処されました。 このブログ記事では、私たちが何を、どのように発見したかを詳しく紹介するとともに、攻撃者が自分たちの利益のためにそれをどのように利用する可能性があるかについて説明します。
発見の経緯
ルーチンの最適化テスト中に、DevOps エンジニアの 1 人がサードパーティ製テストツール用の新しいコンテナを作成しました。彼は、非常に使い慣れたコマンド「 apt get update && apt get install XXXX -y」を実行しました。
このコマンドを入力した後、作成プロセスの実行中に、エンドポイントで何が実行されているかを確認したいと思いました。そのため、プロセス一覧を表示するためのシンプルなコマンド「 ps 」をエンドポイントで実行したところ、次のような非常に興味深い行に遭遇しました。
特定された認証情報を使用して、数百もの顧客成果物を含むサイトに対して認証できました。
平文キーがあったという事実は憂慮すべきものでしたが、たとえば、トークンがアプリケーションの 1 回限りの使用によるものであった場合など、適切なユーザー制御によって説明あるいは封じ込めができるものである可能性もありました。しかし、このケースは明らかに違いました。提供されたユーザー名には「default」の文字列が含まれており、これは決して良い兆候ではありません。
少し深く掘り下げ、それらの認証情報を使用して API を認証してみることにしました。すると、機微と思われる情報を、しかも数多く、クエリーすることができたのです。最終的に、「default」ユーザーは、正にデフォルトであることがわかりました。 このユーザーは Akamai 専用ではなく、アプリケーションのクライアントベース全体で使用されていたのです。
この平文の秘密を手に入れたあらゆる攻撃者が、それを使用して、アプリケーションのほとんどの顧客について、内部テストの実行結果、録画、スクリーンショット、内部スクリプトの実行フローなどの機微な情報を取得できたことになります（図 1）。
Fig. 1: Example of improperly accessed sensitive customer data
私たちは、暴露された大量のデータと、丸見えであった脆弱性の性質を踏まえ、コードベースをさらに調べて、他に何が見つかるかを確認したいと考えました。
すべてが共有されてよいものではない
私たちは、このアプリケーションによって重大な誤用が行われていた共有秘密を特定した後、他にも同様の秘密がないか特定を試みました。アプリケーションのソースコード内で何回か検索（とたくさんの整形）をうまく実行した結果、さらに 3 つの秘密を見つけました。
- Coralogix 秘密鍵
- Google API キー
- ngrok トークン
これらの秘密とその悪用の可能性を調べてみましょう。
Coralogix：（非常に公然の）秘密鍵
アプリケーションのコードベースで特定された秘密の 1 つは秘密鍵であり、私たちの好奇心が刺激されたため、この秘密鍵にリンクされている可能性のあるユーザー名を検索しました。ロギング機能の一部として、この鍵の数行下にユーザー名を見つけることができました。残された他のヒントを使用して、この秘密鍵が Coralogix ロギングフレームワークに属していることを突き止めました。
認証情報はハードコードされており、つまり別の顧客によって共有されていたことを意味していました。これは別の潜在的データ漏洩を意味する可能性がありましたが、幸いにも、このユーザー／攻撃者は権限が低く、フレームワークへのログメッセージ書き込みのみが許可されていました。
前のプリミティブほど強力ではありませんが、書き込みのプリミティブはベンダー自身に対していくつかの興味深いベクトルを許してしまう可能性があります。攻撃者がスプーフィングしたログメッセージをベンダーの環境に挿入したり、悪性のログを注入して、クロスサイトスクリプティング（XSS）や構造化クエリー言語（SQL）インジェクションなどの攻撃を試みたりする可能性があります。
Google API キー
OAuth は、Google のあらゆるオペレーションで使用されている認証メカニズムです。アプリケーションやサイトは、ユーザーが OAuth を使用した自身の Google アカウントで、アプリやサイトにログインできるようにすることができます。コードを通じてこのオプションを有効にするためには、開発者が自身の Google アカウントから取得できるいくつかのパラメーター、すなわち API キー： google_name と google_secretが必要となります。
このコードを見ていたところ、Google API への参照が見つかりました。通常「Google API」キーがある場合、それだけが表示される場合が多いですが、今回はそうではありませんでした。今回は、「Google API」キー、 google_client 一意の識別子、そして（最も不可解なことに！） google_secret 識別子も見つかったのです。これら 3 つが揃っていれば、攻撃者はベンダーとして Google に認証リンクを要求することができます。このリンクをフィッシングキャンペーンの一部として使用した場合、被害者をだまして攻撃者に Workspace への許可を与えることができます。
フィッシングによる悪用の可能性
攻撃者は、ベンダーのサイトにそっくりなサイトへのリンクを含む フィッシング メールを作成することができます。このサイトには重要な変更が1 つ加えられており、Google にログインするためのリンクが、攻撃者がベンダーの Google API 情報を使用して取得したリンクに差し替えられています（図 2）。
Fig. 2: Malicious Google login page appears to be legitimate
ログインすると、被害者は自身の Google Workspace アカウント全体に対する許可を攻撃者に付与してしまうことになります。Google ID のような機密性の高いものにアクセスできると、攻撃者ができることが非常に広範になります。悪用に成功すると、攻撃者は被害者の Google Workspace アカウントのあらゆる側面（メールの侵害やファイルのダウンロードなど）を操作できるようになります。これは、組織に対するソーシャルエンジニアリング攻撃の一部として非常に役立つ可能性があります。
ngrok
ネットワークトンネリングは、データ転送のセキュリティを確保するためのほぼ普遍的なソリューションであり、侵害を受けると、攻撃者に悪性の機会を詰め込んだ宝箱を提供することになる可能性があります。欠陥のあるアプリケーションの設定に、 ngrok 設定を含む多くのトンネリング関連のパラメーターが発見されたため、さらに調査を進めました。開発者のコラボレーションを促進するための機能が、脅威アクターにとってまさに魅力的なものとなります。
Ngrok は、サーバーを介して情報をトンネリングするプラットフォームの提供に特化したサービスです。Ngrok を使用すると、サービスをインターネットに公開することが非常に容易になり、デバッグの高速化と開発フィードバックループの効率化が可能になります。しかし残念なことに、攻撃者がトンネルの制御を掌握した場合、攻撃者もそのシンプルさを利用することができます。
シンプルな ps コマンドを呼び出すことで、攻撃者は会社の一意の ID と認証トークンを表示できます。この一意の ID は変更できないため、他のエンドポイントでそのアプリケーションを使用する際も同じままとなります。攻撃者は、これらのパラメーターを利用して、ベンダーのオンラインサーバーに ID とトークンを送信し、その会社の ngrok の詳細な情報を受け取ることができます（図 3）。
Fig. 3: Ngrok token received from the vendor’s server
つまり、最初のアクセス後、 攻撃者は、被害者から一意の ID とトークンをコピーし、それらを使用して、被害者のアプリケーションで送受信されるデータを読み取ることができます （図 4）。
Fig. 4: Example of data being read from ngrok tunnel
結論
脅威は外部のものだけではありません。実際、私たちは進んで内部に脅威を受け入れています。多くの人が、オープン・ソース・ソフトウェアに寄せている多大な信頼を理由に、それが最も危険なものであると考えていますが、サードパーティ製ツールがオープンソースよりも企業にとって大きな課題を生じさせることもあります。
私たちは発見の後に、影響を受けるベンダーにこのブログで取り上げた問題について開示し、問題は修正されました。それにもかかわらず、新たなセキュリティ上の欠陥は常にすぐそこに潜んでいます。
こういった場合、そしてその他多くの場合も、 セキュリティの監視 は、 開発者がセキュリティ意識を持つようトレーニングすることと同じくらい重要であると私たちは考えています。これら 2 つは、マネージドサービスが企業に問題を引き起こさないよう確約するために役立ちます。