はじめに
プロフェッショナルサービス部の鈴木です。今回は私が担当しているRedTeamサービスにおける事例紹介をしたいと思います。
本記事で紹介するのは、脆弱性診断をすでに実施していたシステムに対してRedTeam演習を行った結果、いくつか指摘事項が見つかり、侵入可能な脆弱性も見つかった事例です。本事例を通じて、脆弱性診断では見えにくいリスクと、RedTeam演習によって得られる気づきについて解説していきます。脆弱性診断をすでに実施している組織にとっても、参考となる内容になれば幸いです。
RedTeamサービスについて
概要
事例紹介の前に、まず簡単にRedTeamサービスについて紹介させていただきます。RedTeamサービスは、本番システムに影響を与えないなどの禁則事項を決めておき、それ以外は自由に疑似攻撃することで、お客様のシステムの弱点を発見するサービスで、弊社では主に２つの演習形式があります。
- 公開システムからの侵入
- 侵入された前提で、内部システムから重要システムへの展開
実際のRedTeam演習では、事前にお客様と十分に相談したうえで実施内容を決定します。ここに記載した内容にとらわれず、柔軟に内容を調整することも可能です。
RedTeamと脆弱性診断
RedTeamについてもう少し深く知るために、類似サービスである脆弱性診断との違いを考えてみます。RedTeamと脆弱性診断には様々な違いがありますが、ここでは広さと深さの２つの側面で考えてみます。
まず、広さの観点について考えます。脆弱性診断では、お客様の指定したWebアプリケーションや公開サーバを対象に、ツールや手動分析で脆弱性の有無や設定不備などを洗い出します。一方で、RedTeam演習では、対象スコープや禁止事項だけを定めて様々な攻撃を試行します。つまり、脆弱性診断ではお客様が認識しているシステムに対してのみ調査していくのに対して、RedTeamではお客様が認識していないシステムも調査対象に含めるという違いがあります。
組織がある程度大きくなると、システムの更改などで組織の管理から漏れてしまうサーバーなどが発生しがちです。そうしたシステムは脆弱性が放置されていたりするため、攻撃の起点となってしまう恐れがあります。RedTeamでは、そうしたお客様が把握していないシステムも含めて、穴がないかを調査します。
深さの観点では、脆弱性診断では見つかった脆弱性を使って更なる深堀調査をしないのに対して、RedTeamでは見つかった脆弱性を悪用された場合にどこまで侵害が広がるリスクがあるかを実際に攻撃を行って評価します。実際に見つかった脆弱性を使って攻撃を実施することで、発見された脆弱性が真に悪用できるかや、悪用された場合に被害や影響がどの程度なのかということが詳細にわかります。
このような違いがあるため、脆弱性診断を受けていても、RedTeam演習を実施する意義があると言えます。
次の章から脆弱性診断をすでに受けていたお客様の事例を紹介したいと思います。
案件の概要とOSINT
今回紹介する事例ではお客様の公開システムが対象の案件でした。
公開システムに対してRedTeam演習を実施する場合、まずは、攻撃対象となるシステムを列挙する必要があります。
OSINTではお客様に関連するキーワードをもとにして、WHOISやcrt.shでの検索、ホームページのクローリングによるリンク収集、サブドメインの辞書攻撃など、さまざまな手法を駆使して、関連するサーバーを列挙しました。見つかった公開サーバーのうち、関連度の高そうなものをピックアップし、それらのサーバーがお客様の所有システムであるか確認を取ってから、各サーバーに対して調査を行いました。
次の章から各サービスに行った調査や見つかった脆弱性を紹介していきます。
バックアップディレクトリの残置
外部からアクセスできるページにWordPressのバックアップが残置されており、任意コマンドの実行が可能な状態でした。
WordPressが運用されているサイトの、とあるページにアクセスすると、WordPressをインストールするための画面が表示されました。WordPressをアップデートした際に、古いバージョンを /old/ に移動して放置していたようです。
.png)
攻撃者は、WordPressを勝手にインストールしてしまえば、管理者としてログインできるようになります。そして、管理画面から悪性のプラグインをインストールすることで、サーバー上で任意のコマンドを実行することができます。
実際にセットアップを進めるとDBを指定する画面になります。
データベースの接続先として我々が管理するサーバを指定して待ち受けていると、このサーバーから通信が来ていることが確認できました。 (ポート443以外はアウトバウンドの通信が禁止されていました)
お客様の希望でこれ以上は実施しませんでしたが、以下の手順でインターネットからサーバに侵入し、さらなる攻撃を展開できます。
- DBを構築し、ポート443で待ち受ける
- 構築したDBを指定して、WordPressをインストール
- WordPressに管理者としてログイン
- 悪性プラグイン(WebShell)をインストール
- WebShellでコマンド実行
公開サーバーにおいて任意コマンド実行が可能であったため、とても危険な状態だったと言えます。以下のような対策が効果的です。
- 不要なファイルは削除する
- 定期的なセキュリティ診断を実施する
この脆弱性はwebページの調査中にディレクトリファジングツールを使って発見しました。
脆弱性診断では具体的な診断対象を決定する際に、顧客から提供された資料やブラウザからの通常操作でのアクセスをもとに範囲を決めることが多く、この例は通常のブラウザアクセスでたどり着かないページなので、見逃されてしまったのではないかと思われます。
モバイルアプリ解析
お客様がモバイルアプリを公開している場合はモバイルアプリを対象に含めることもあります。
モバイルアプリの分析中にアプリとOAuthの認可サーバーの通信を調査したところ、以下のような通信を発見しました。
認可サーバーに対してBASIC認証でユーザー名とパスワードを送っています。こちらはbase64でエンコードされているだけだったので、平文のユーザー名 (Client ID) とパスワード (Client Secret) を入手することができました。
こうなってしまったのはモバイルアプリ用ではなく、サーバー用の認証方法を使ってしまったからだと推測できます。
OAuthでのクライアント認証には複数の方法があります。
- Publicクライアント：Client IDのみで認証、権限が弱い
- Confidentialクライアント：Client ID/Client Secretで認証、権限が強い
- etc
このうち、モバイルアプリではPublicクライアントが使用されるべきですが、このアプリではConfidentialクライアントが使用されていました。クライアントに付与されている権限次第では、システムの乗っ取りも可能となってしまいます。
モバイルアプリは、保護されているように考えてしまいがちですが、だれからでも閲覧できる公開エリアと捉えるべきです。
- Webアプリのフロントエンドやモバイルアプリなどでは、Publicクライアントを使用する
- モバイルアプリが解析されることを考慮にいれて実装する
クレデンシャルの漏洩と影響範囲調査
Next.js製のWebアプリでJavaScriptソース内にAWSクレデンシャルが埋め込まれているのを発見しました。
Webアプリ自体はログインしないと使えないようになっていましたが、フロントエンドのJavaScriptコードから、アプリの機能やバックエンドサーバーとの通信方法などの情報を得ることができました。管理機能としてAWSからログの取得を行う機能が実装されていて、AWSのクレデンシャルが埋め込まれていました。
Next.jsにはサーバーコンポーネントとクライアントコンポーネントがあり、サーバーコンポーネントはサーバーのみで使われるため外から見えません。一方で、クライアントコンポーネントはフロント側で使われるためソースコードやインポートされているファイルも外から見えてしまいます。サーバー側で使用するつもりのコードが、意図せずクライアントコンポーネントとなってしまったために、AWSのクレデンシャルが漏洩したのではないかと考えられます。
漏洩したAWSクレデンシャルを使用してさらに調査を行ったところ、 ReadOnlyAccess 権限が割り当てられていることがわかりました。 これは、ほぼ全てのAWSリソースを読み取ることができる権限です。サーバーを構築するためのIaCコードやWebアプリのソースコード、アクセスログなどを全てダウンロードできることになります。実際にこの権限を使って、どこまで侵害が可能か調査したところ、利用者の個人情報の漏洩まで可能であることが発覚しました。
Next.jsをはじめ、JavaScriptをベースにしたWebフレームワークは人気がありますが、予期せぬ形でソースコードが露出することがよくあります。Next.jsに限らず、以下のような対策が効果的です。
- 認証情報をソースコード内に埋め込むような実装は避ける
- クライアント・サーバーの境界をきちんと理解し、実装する
- 認証情報の漏洩をチェックするスキャンツールで確認する
おわりに
今回はRedTeamサービスにおける事例紹介をしました。
見つかった脆弱性は技術的にはどれも単純なものでしたが、脆弱性診断の範囲外にこうした脆弱性が残っている可能性は十分にあります。また、実際のサイバー攻撃ではこのような認知していない部分の脆弱性が起点になってしまいがちです。
本記事を読んで、弊社のRedTeamサービスにご興味を持っていただけましたら幸いです。
.png)
