脆弱性診断環境におけるクラウドの登場と分科会での診断技術の標準化の取り組み
Network Security Forum 2024
ISOG-J WG1 新技術に対する診断手法分科会
株式会社Flatt Security 齋藤 徳秀

自己紹介株式会社 Flatt Security
プロフェッショナルサービス事業部齋藤 徳秀
主な業務● Webアプリケーション診断● クラウド診断● その他各種社内業務やリサーチスライドの流れ● クラウドとセキュリティにおける潮流と背景の補足○○○○

診断環境におけるパブリッククラウドの登場
脅威への理解現実に発生している設定ミスなどの事例
今後考えられる脅威● パターン化される攻撃手法● 分科会で整理した診断手法についての例○

代表的なサービスを中心にした発表背景background: 診断環境におけるパブリッククラウドの登場● Webアプリケーションの近代化により、各種技術スタックも変化を続けており、インフラの構成についてもオンプレからクラウドへと変化しています。
● そのような環境下でWebやモバイル等の脆弱性診断においても、開発現場の技術変革に伴い、環境の変化が発生しています。
○例■■■

ディスクストレージから外部のオブジェクトストレージサービスへ
アプリに実装された認証やユーザー管理機能からIdP サービスへ
オンプレからIaaS、そしてPaaSやCaaS(container as a service)、FaaS(function as aservice)へ● クラウドサービス間での操作を行う場合は、権限の定義や、それに基づき発行された認証情報を元におこないます。
○例:■

IaaSから外部のオブジェクトストレージの操作を行うなどの行為

background: クラウドを標的とした脅威
現時点で、クラウドを標的とした攻撃がAPT等から、大々的に行われている報告例は少ないです。
また報告されている多くに関しては、IMDSを標的とした認証情報の取得に力を入れています。

https://attack.mitre.org/groups/G0139/

https://www.mandiant.jp/resources/blog/cloud-metadata-abuse-unc2903

background: 設定ミスによる情報の漏洩の可能性
Amazon S3やGoogleの提供するFirestoreのようなサービスにおいては、設定次第でユーザーの情報が認証なしで見られる可能性があります。

https://www.databreaches.net/japanese-medical-online-consultation-site-leaking-consumer-submitted-images-of-symptoms

background: 今後考えられる攻撃と備え
クラウドの利活用やクラウドネイティブというものは、登場から提唱まで一定の時間が経過し、実際の運用にたりうる状況になりつつある。その中で、企業や開発現場の技術選定においても、十分考慮され、採用に至るケースも多くなっている。その中で、今後はより多くのクラウドサービスが、プロダクトに組み込まれるようになると考えます。
そのような背景から、攻撃者もクラウド環境への慣れや標的をオンプレとクラウド双方に向ける可能性も存在します。

https://sysdig.com/blog/cloud-breach-terraform-data-theft/background: 今後考えられる攻撃と備え備えとして、脆弱性診断を行うセキュリティエンジニアにおいても、侵入の起点となる脆弱性や設定ミスの発見を行えるように、日々自己研鑽をする必要です。
また、事業会社においては、クラウド等の資産の把握や、保有している資産から想定される攻撃経路などを洗い出し、優先度を決めた上で、適切な対策を施す必要があると考えられます。

パターン化される攻撃手法● 公然の知識としての設定ミス○○公開されたドキュメントに記載された「デフォルト設定」などを考慮しないことによって発生するアプリケーションとの不整合
Amazon Cognito User Poolにおける暗黙的なデフォルト値● 非公然の設定ミス○○○○

明示的に設定が変更されており、その設定値が脆弱な状態
クラウドサービス多用するアプリケーションにおける設計の不備
Amazon S3 bucketにおけるObjects Listing
CNAMEにクラウドサービスのドメイン・IPを指定する● 実装によるクラウドサービスの悪用○○

アプリケーションの実装に埋め込まれた脆弱性やそれらを利用したクラウドサービスの利用
SSRFなどの脆弱性を用いたIMDSへのアクセス

診断の手法の例

Webアプリケーションの脆弱性を利用した認証情報の窃取パターン化される攻撃手法の区分
実装によるクラウドサービスの悪用
概要
クラウド環境を利用してWebサービスなどを提供するシステムにおいて、アプリケーションの脆弱性を利用し、クラウドサービス側の仕様などをもとに、認証情報を窃取される可能性があります。そのため、WG1 NewTechでは、クラウドサービスの仕様などを元に、いかに脆弱性を発見できるかについて、整理をしました。

https://webapppentestguidelines.github.io/newtechtestdoc/docs/cloudsec/cloud_credential/

Webアプリケーションの脆弱性を利用した認証情報の窃取
EC2に代表されるIaaSの場合は、Identity Meta Data Service(IMDS)と呼ばれるインスタンスに関連する情報を取得可能なエンドポイント(169.254.169.254に代表されるIPなど)へアクセスすることで、IAMから払い出された認証情報を取得しています。他にもAWS Lambdaの場合は、認証情報を環境変数に保存している特性があるなど、各サービスによって異なるものの、脆弱性を用いてこれら特定のファイルなどにアクセスすることで認証情報を取得することが可能になります。
例:
●
●
●

SSRFを用いたIMDSへのアクセス
OS Command Injectionを用いた環境変数等へのアクセス
Path Traversalを用いた/proc/self/environなどへのアクセス

Webアプリケーションの脆弱性を利用した認証情報の窃取

Webアプリケーションの脆弱性を利用した認証情報の窃取対策としては、従来の脆弱性への対策と共に、提唱される緩和策や、認証情報のポリシーを最小権限の原則に基づき設定することで、漏洩した場合のリスクを軽減することが可能になります。
例:●●

AWSの場合IMDSv1をIMDSv2へ変更することで、GETのみのSSRFではアクセスできなくなるため、緩和策として利用可能
LambdaやEC2へ付与するIAMが利用される場所を限定して、外部からの利用や、異なるアカウントからの利用をできないようにする○ IAM ポリシーのリソースやConditionのPrincipalAccountなどを用いて制約を設定する

意図しないサインアップ経路の存在
パターン化される攻撃手法の区分
公然の知識としての設定ミス
概要
パブリッククラウドでは、ある機能に特化したサービスというものが多く存在します。その中でもWebサービスに欠かせない認証機能においても、サービスとして存在しており、それらをIDaaS(IdP)と呼びます。
このようなサービスにおいて、多くのユースケースに対応するために、自らユーザー登録を行えるようにする機能が提供されているケースが多数です。このような機能はECサイトなどの公に公開されたWebサービスであれば、特に問題にはなりませんが、これが管理者画面などの限られた利用者しかいないアプリケーションでは話が別です。

https://webapppentestguidelines.github.io/newtechtestdoc/docs/cloudsec/idaas/presence_of_unintended_signup_paths/

意図しないサインアップ経路の存在 - 構成やユースケース

意図しないサインアップ経路の存在 - 攻撃の手法と診断へ

意図しないサインアップ経路の存在対策としては、限定されたサインアップの場合、自己サインアップをはじめとした、利用者が自らユーザを作成できる機能の無効化してください。また、自己サインアップ機能を無効化できない場合、それに準ずる対策が必要となります。
自己サインアップを許可しない設計や要件の場合、根本的対策として該当する機能を無効化し、ユーザによるサインアップを許可しないようにしてください。 無効後に新規作成する際は、RBAC等のアクセス制御を用いて、操作が可能なユーザを限定してください。
自己サインアップを無効化できない場合は、管理者による新規作成フローにおいて、利用者から操作できないカスタム属性などを用いて該当アカウントが管理者作成のアカウントであることを証明する属性を追加し、認可やアクセス制御の際に確認してください。

まとめ

まとめ●

●
●
●

クラウドサービスに対しての組織的な脅威については現時点では多くは見られない。一方で、個人や特定の目的を持った犯罪者が、クラウドサービスの認証情報を標的に攻撃をするケースは報告されている。
サービスの提供環境の変遷に伴い、今後攻撃者においても標的にする「モチベーション」も増加してきている
このような背景から、ISOG-J WG1 Newtech分科会では、クラウドサービスでの脆弱性をいかに見つけ出すのかについてまとめました
実環境で発生する脆弱性のパターンを元に、現在利用が多いサービスを中心に診断手法を公開しました。

まとめ - パターン化される攻撃手法● 公然の知識としての設定ミス○○公開されたドキュメントに記載された「デフォルト設定」などを考慮しないことによって発生するアプリケーションとの不整合Amazon Cognito User Poolにおける暗黙的なデフォルト値● 非公然の設定ミス○○○○

明示的に設定が変更されており、その設定値が脆弱な状態
クラウドサービス多用するアプリケーションにおける設計の不備
Amazon S3 bucketにおけるObjects Listing
CNAMEにクラウドサービスのドメイン・IPを指定する● 実装によるクラウドサービスの悪用○○

アプリケーションの実装に埋め込まれた脆弱性やそれらを利用したクラウドサービスの利用
SSRFなどの脆弱性を用いたIMDSへのアクセス

ISOG-J WG1
新技術に対する診断手法分科会
運営と診断技術のご紹介
三井物産セキュアディレクション株式会社 廣田一貴
三井物産セキュアディレクション株式会社 山本健太
株式会社 Flatt Security

齋藤 徳秀

Agenda• 20-30代の非営利コミュニティ運営
運営• 継続のための仕組み• WebCache

診断手法紹介• クラウド関連

自己紹介
三井物産セキュアディレクション株式会社
診断サービスチーム・レッドチーム

廣田 一貴

業務：Web脆弱性診断・ペネトレ
主な社外活動：ISOG-J WG1 NewTech リーダーセキュリティキャンプ 地域連携Gr（ミニキャンプの企画）

ISOG-J/WG1
日本セキュリティオペレーション事業者協議会（ISOG-J）● セキュリティオペレーションサービスの普及● サービスレベルの向上
セキュリティオペレーションガイドラインWG(WG1)● 主に脆弱性診断に関するドキュメントを作成● To診断員、To開発者、To診断発注企業 等様々

新技術に関する診断手法検討部会
WG1内の部会

新技術に関する20～30歳前後

通称NewTech

調査・研究

紹介制

非営利かつ若手？の技術コミュニティ

何故産まれたか
構成の変容• Slack総数80名• 平均年齢+1歳化

本職の方向転換• Penシフト• 経営シフト

若手に任せる• リーダーを指名• 後はリーダーが運営する• メンバーもリーダー次第何故産まれたか
構成の変容

丸投げ

• Slack総数80名• 平均年齢+1歳化

本職の方向転換• Penシフト• 経営シフト

若手に任せる• リーダーを指名• 後はリーダーが運営する• メンバーもリーダー次第継続の仕組み
面白そう
楽しそう
やりたい けどできない
オンライン
オフライン

モチベーション成果物へのシステム
コミュニケーション

面白そう
楽しそう
面白そう
• まだ触ったことが無い• 知らなかった• “比較的新しい”ならOK
楽しそう• まだ良い資料が無い• ニーズがあるか不明• "エンジニア"から見て俺得/私得ならOKやりたいけどできない• 強制的に時間をとることで進捗を作る• 月1回1時間MTG• タスクと締め切りを小さく短く• 忙しい時はSlackに進捗書込• 他のイベント等が被っている時期• 繁忙期（まさに今）• 自動化できるところは自動化• ビルドやLintの自動化• Issue通知等のSlack連携

オンラインオフライン
オンライン• 東京にいないメンバー• ほぼ全員リモートワーク• Skype+GoogleDrive議事録

オフライン• 飲み食いと共に実施• 新年会・リリース記念など

現状と課題• 企画～作成までは順調• 定期的にドキュメントを出せるようになっている• スケールしないが十分• 興味ベースの企画なので完成まで持っていきやすい• レビューや保守が課題• あまりシステム化出来ていない• 何を/どこまでチェックするか等が曖昧• 自動化できるところは自動化を進めていく細かすぎるけど伝わってほしい脆弱性診断手法ドキュメント
https://webapppentestguidelines.github.io/newtechtestdoc/

Web Cache Poisoning
Network Security Forum 2024
三井物産セキュアディレクション株式会社
山本 健太

自己紹介
三井物産セキュアディレクション株式会社
診断サービス・Webアプリケーション診断

山本 健太
主な業務
○ Webアプリケーション診断○ 教育○ セキュア設計支援

リッチコンテンツ時代の効率的なコンテンツ配信が必要● 繰り返し利用される静的コンテンツはWebアプリケーションの負荷軽減のため事前に生成したファイルを配信する仕組みとしてキャッシュが採用される● 更にリッチなコンテンツ、グローバル化によってCDNが広まりキャッシュの重要性が変化している

リクエスト

WEBアプリケーション

処理開始
クライアント

処理結果
レスポンス

Web Cache Poisoning とは攻撃者が不正なデータを含んだキャッシュを生成させるよう仕向けて様々な悪用を行う脆弱性の総称

攻撃者①リクエスト④レスポンス⑤リクエスト

②処理開始
③処理結果

悪意のあるキャッシュを生成⑥レスポンス

キャッシュデータを返却
クライアントWEBアプリケーション

Web Cache Poisoning とはCDNの台頭などよりキャッシュが重要になる潮流の中でも、Web Cache Poisoning はメジャーな脆弱性より名前も診断方法もあまり知られていない

Google Trends 2015〜2024原因● 動的機能でのキャッシュ設定が不適切● 動的機能での悪用可能な挙動が存在する

影響

Web Cache Poisoning は本来、悪意のあるコンテンツを配信させる手法に当たるため、影響は配信させるコンテンツの内容による●●●●XSS (クロスサイトスクリプティング)
オープンリダイレクト
DoS
etc…

実例
● 不正なリソース読み込み先をキャッシュさせ、キャッシュが有効な間はWebサイトを利用できなくなる（DoS）● 多くの報告ではXSSは再現できておらず、懸念を記載するにとどまっている● Web Cache Poisoning ではないが、キャッシュ設定のミスにより起こったインシデントなどは少数ながらも報告されている

診断方法

前提概念
キーあり入力キャッシュサーバがコンテンツの同一性を解釈するパラメータやヘッダのこと（？？）

キーなし入力キャッシュサーバが解釈しないパラメータやヘッダのこと（？？？）

前提概念
GET /search?query=books HTTP/1.1
Host: example.com
Accept: */*Accept-Encoding: gzip, deflate, br
Accept-Language: ja,en;q=0.9,en-GB;q=0.8,en-US;q=0.7
X-Forwarded-For: https://10.0.0.1:8080

前提概念

キーあり入力のケースが多い

GET /search?query=books HTTP/1.1
Host: example.com
Accept: */*Accept-Encoding: gzip, deflate, br
Accept-Language: ja,en;q=0.9,en-GB;q=0.8,en-US;q=0.7
X-Forwarded-For: https://10.0.0.1:8080
キーなし入力のケースが多い

診断方法(リリースドキュメントより)
1. キャッシュに影響のない「キーなし入力」を探す○ データをキャッシュするかどうかを判断する「キャッシュキー」ではない入力となるパラメータを探す○ サーバはその他のキャッシュキーでキャッシュするかどうかを判断するため、それに影響されない入力パラメータを探す必要があります2. 「キーなし入力」を送信して、コンテンツ内に出力している箇所を探す○ キーなし入力を悪意のあるコンテンツを生成するために使用します○ キーなし入力であっても悪意のあるコンテンツが生成できなければ悪用できません

3. 「キーなし入力」を除去して、コンテンツ内に出力しているかを確認○ キーなし入力はキャッシュを返却するかどうかの判断には使用されないので、キーなし入力を除去しても手順2で確認したコンテンツが返却されるはずです診断方法(リリースドキュメントより)

診断方法(リリースドキュメントより)

診断方法(リリースドキュメントより)

X-Forwarded-Hostを消してもキャッシュされたレスポンスが返却されている

対策/まとめ
1. Web Cache Poisoning 不正なキャッシュを生成させ、被害者に配信する攻撃2. 診断方法やメカニズムを解説した日本語の情報が少ない
3. 対策：キャッシュを無効化○

機能そのものを無効化すればWeb Cache Poisoningの脅威はなくなるが、キャッシュの恩恵はなくなる

4. 対策：キャッシュの設定を見直す○

悪意のあるコンテンツは動的機能によって生成される○

本来キャッシュは繰り返し利用される静的コンテンツに適用されるべきであり、運用はキャッシュ対象を精査するべきである○

Webサーバだけでなく、CDNの設定を見直す。CDNのキャッシュ挙動はサービスによって異なり、解釈するヘッダも異なる