A3: Sensitive Data Exposure 2017 OWASP

本記事では、デバッグ情報から管理者パスワードまで、さまざまな情報漏洩の種類について解説します。

情報漏洩とは

この問題は、過剰な情報が漏れることで深刻なセキュリティリスクとなる状況を指します。機密情報が存在する場所は多岐にわたるため、まずは情報漏洩が起こり得るパターンを列挙します.

• モニターに貼られたパスワードの付箋（明白な例）
• デバッグ情報は、ペンテスターやバグバウンティハンターにとって非常に有用です
• パスワードやその他の機密情報が直接コミットされたGithubリポジトリ。Githubは、使用されるコードの全体像を把握するためにも利用されます
• 従業員による、機密情報を含むツイートが投稿されたTwitter
• Webサーバ自体に、訪問者から閲覧可能な設定ファイルが残されている場合
• LinkedInの従業員のタイムラインに、本来隠すべき情報が記載されている場合
• 開発者が残したコメント
• Javascriptファイル
• ディレクトリリスティングが公開され、サイト内部の構造が閲覧可能な場合。さらに、全く保護されず攻撃者が自由にファイルを閲覧できるケースは特に危険です
• ディレクトリリスティングにより、バックアップファイルが露出する場合。攻撃者がこれをダウンロード・解析することで、ソースコードやアプリの仕組み、さらには秘密情報を把握する恐れがあります

機密情報はどれほど脆弱か

この問いに対する答えは組織ごとに異なります。すべてのデータとその管理・転送方法を把握するデータプランの策定が必要です。情報が平文で送信されている場合、中間者攻撃のリスクが高まるため好ましくありません.

データが暗号化されている場合でも、弱いまたは古いアルゴリズムが使われていないか確認が必要です。不適切な場合、攻撃者がデータを解析したり、場合によっては復号鍵を盗む可能性があるため、鍵の管理にも十分注意してください.

また、アプリがデバッグメッセージやログ、過剰な情報開示によってAPIのセキュリティを低下させていないかも確認する必要があります.

‍

情報漏洩のテスト方法

定義は難しいですが、以下に一般的な戦略を示します:

• 一点に固執せず、全体を俯瞰することで他の明白な問題を見逃さないようにする
• 機密データを探す際、この記事の内容にとどまらず、他の潜在的な場所も探索方法に加える
• 狙いを絞って探すと情報は見つかりにくい場合が多く、対象の仕組みを深く理解した上で、機密情報の特徴を見抜くことが重要である

チェックリスト

• 可能であれば、物理的な脅威も確認する
• 対象がデバッグ情報を漏らしている場合、その情報を詳しく調べる
• 会社および従業員のGitリポジトリを調査する
• Twitter、Facebook、LinkedInなどのSNSを、会社および従業員双方について調査する
• HTMLやJavascriptファイル内のコメントを確認する
• ディレクトリリスティングを調査する
• ディレクトリ構造の確認やブルートフォース、fuzzingを活用し、.bakファイルなどのバックアップを探す

情報漏洩の例

デバッグ情報

開発者はアプリ作成時にデバッグ情報を有効にするオプションがあり、この情報は不具合の発見・修正に役立ちます。しかし、本番環境で無効にするのを忘れると、情報収集に悪用される可能性があります。

場合によっては、全く役に立たない単純な情報の場合もあります。例:

```bash
DEBUG メールアドレスまたはパスワードが間違っています
```

‍
しかし、時にはデバッグメッセージから有用な情報が得られることもあります。例えば、userTypeパラメータを「user」から「administrator」に変更しようとした際、以下のメッセージが表示されました。

```bash
DEBUG userTypes列挙型に「administrator」が見つかりません。利用可能な値は
- Admin
- User
- Reporter
```

もちろん、ミスは修正し報奨を得た。対象が明示的に示してくれると助かる。状況に応じ、影響が確認できる場合はバグバウンティハンターとして報告し、ペンテスターの場合は情報漏洩を発見したら必ず報告すべきである。

デバッグメッセージからは、以下の情報も得られる可能性がある。

・ユーザー入力で操作可能なセッション変数の値（例：JWT暗号化鍵によって自作JWTが作成可能な場合）

・バックエンドのホスト名や認証情報（例：管理者ログイン情報）。ホスト名は記録し、認証情報はバグバウンティハンターに報告する。なお、ペンテスターは情報漏洩全般を報告すべきだが、ホスト名は中～低リスク、認証情報は利用条件により高～致命的、もしくは利用不可の場合は低リスクとなる。

・サーバ上のファイルやディレクトリ名。バグバウンティハンターは必ずしも報告する必要はないが、ペンテスターは報告すべき事項であり、LFI (Local File Inclusion) のファイル探索に役立つ。

・クライアント経由で送信されるデータ暗号化に用いられる鍵。これによりデータの復号が可能となる可能性があるが、攻撃者が既に該当データにアクセスしている必要があるため、バグバウンティハンターは通信内容の解析の参考程度となり、ペンテスターは中～高リスクの脆弱性として報告する可能性がある。

Git Gud

Gitは情報漏洩の非常に有用な情報源であり、Githubの奥深さに気付かない人も多い。多くの場合、対象の開発者は誤って機密情報を含むリポジトリを公開してしまう。

一般的に、設定ファイルはバックエンドのパスワードやAPIキーが記載されるため興味深い。しかし、最近の開発者はより賢明で、パスワードをCI/CDパイプラインの環境変数に格納するため、設定ファイルには単なる参照のみが記録される場合が多い。

また、ソースコードが公開されることも有用で、まるで宝の地図のようにアプリの内部構造を理解する手がかりとなる。

多くのハンターは、Githubや公開されているプライベートなGitインスタンスが情報源として有用であると認識しているが、特に見落とされがちなのはコミット履歴である。たとえ一度機密情報を含むコミットを修正しても、最初のバージョンは履歴に残るからである。

JavaScriptのコメント

開発者が残したコメントは、アプリの動作に関する貴重な情報源となる。中には、APIキーや認証情報がコメント内に記載されたままコミットされる場合もある。

これらのコメントは、Webページのソースコードを確認するか、Burp Suite Professionalのエンゲージメントツールを使用し、サイトマップ上で対象を右クリックして『Engagement tools > Find comments』を選択することで見つけることができる。

ペンテスターの場合、極秘情報や認証情報に関わらない限り、通常は報告対象外となる。

一方、バグバウンティハンターにとっては、これらのコメントはアプリの仕組みを理解する上で非常に有用な情報源となる。コメントを丹念に確認することで、対象の全体像をより正確に把握できるため、面倒でもチェックする価値がある。

これらのコメントは、HTML内だけでなく、Javascriptファイルなどにも見受けられる。

Javascript内では、APIキーや認証情報が記載されている場合もあるが、多くのAPIキーは公に使用されるべきものである。しかし、サードパーティのキーが存在する場合は注意が必要である。

もし、リクエストごとに料金が発生するサードパーティとの接続があるなら、ユーザーのリクエスト数を制限する必要があります。さもなければ、攻撃者が自動化された大量のリクエストを送り、コストが膨らむ恐れがあります。このような問題は、ペンテスターやバグバウンティハンターが明確なPoCと事例を示した上で報告すべきです.

この問題の深刻度は企業にとって甚大であり、例えば創業間もない企業に突如10万ドルの請求が来るような事態は避けねばなりません.

リストを作成し、再確認する

一部のWebサーバは、初期設定でディレクトリリスティングが有効になっています。この場合、攻撃者はサイトの内部構造を把握し、新たなエンドポイントを容易に発見できる可能性があります. 

バックアップ！これが最後の警告です！

ディレクトリリスティングから、ソースコードを含むバックアップファイルが露出する可能性があります。これはペンテスターやバグバウンティハンターにとって非常に有用な情報源ですが、直接悪用されるケースは稀です。この情報により、攻撃者はアプリの内部構造をより正確に把握できます。ハッキングにおいて、情報は最も重要な要素の一つです.

実例

本脆弱性が深刻な影響を及ぼす可能性があることを示す実例を紹介します。最初の例は、ユーザーのクライアントリストがSMBを通じ平文で送信される脆弱性です。攻撃者がそのSMBリストを取得するためには、中間者攻撃（MiTM）を実施するか、ネットワーク内部にいる必要があります.

https://nvd.nist.gov/vuln/detail/CVE-2018-11338

次の例は、一見影響が小さいように思われますが、今回影響を受けた組織がDoDである点に注目すべきです。JIRAのエンドポイントを通じ、カスタムフィールド名やカスタムSLA名が漏洩しており、正しいURLにアクセスするだけで望ましくない結果を招きました.

https://hackerone.com/reports/1067004

‍

情報漏洩を防ぐには

この脆弱性を防ぐには、データを慎重に守る必要があります。全データとその機密性を把握する計画を策定し、規制、プライバシー（例：GDPR）およびビジネス上重要な情報を考慮することが大切です.

データを扱う際、特にデバッグやログでの出力については、データタイプごとに設定した戦略を遵守してください.

機密データについては、不要な場合速やかに削除し、記録・ログに残さないことで、情報漏洩のリスクを大幅に低減できます.

どうしても機密データを保存する必要がある場合、平文ではなく、適切に暗号化されていることを確認してください。これにより、仮にデータが盗まれても、攻撃者にとって利用が困難または無意味となります.

暗号化は、安全かつ最新の強力なアルゴリズムを用いて実施する必要があります. 

また、どのネットワーク上でも送信されるデータは漏洩防止のため暗号化すべきであることは言うまでもありません.

加えて、Wallarmはセキュリティ管理を徹底し、機密情報を含むゴーストリポジトリが放置されないよう注意すべきです。リポジトリの場合、コメントやコミットも対象となります.

キャッシュにも特に注意を払い、機密データが残っていないか確認する必要があります.

すべてのパスワードは、適切な暗号化アルゴリズムを使用したパスワードマネージャーによって安全に保管されるべきです.

‍

結論

機密情報の漏洩は、バグバウンティハンターからは中～低リスクとして報告されることが多く、必ずしも重い脆弱性として扱われない問題です。漏洩対象となるのは、

• アカウント情報
• 認証情報
• APIキー

情報漏洩は、より大きな影響を及ぼす脆弱性への足がかりとして利用されることが多いです。結局、利用できなければ情報自体は意味がないため、企業の内部、Web、またはAPIセキュリティにおける評判や技術力が、機密情報漏洩により危険にさらされる可能性があります.