XSS攻撃から考察するAWS設定不備の恐怖 / 20241220 Hironobu Otaki

2024/12/20 NCA Annual Conference2024
https://annualconf.nca.gr.jp/
株式会社SHIFT
セキュリティサービス部 AWSセキュリティコンサルタント
大瀧 広宣

Transcript

1. XSS攻撃から考察するAWS設定不備の恐怖 株式会社SHIFT 大瀧 広宣（おおたき ひろのぶ）
2. 1 自己紹介 • 大瀧広宣（おおたきひろのぶ） • 経歴 • IT業界歴30年以上、時代のトレンドに沿ったカテゴリーを選んで転職 • ソフトウエアエンジニア（JavaとかHTMLの創成期にWebシステム構築） • ネットワークエンジニア（R&D、自社ネットワークアプリ開発） • “カー！と言えばグー”でお馴染みの会社でAWS事業責任者（データセンターのAWS延伸） • クラウド会計のfreeeでCIO補佐（コロナ禍による情シスのクラウド化、モダン情シス化） • Serverworks（AWSプレミアパートナー）で急成長顧客を担当するPM兼マネージャー • 副業で”なんぼや“でお馴染みの企業でAWSのセキュリティ対策PM（DLP対策、個人情報保護） • AWSセキュリティコンサル、CCoE推進リーダー（株式会社SHIFT セキュリティサービス部） • 個人資格 • 2024 Japan AWS All Certifications Engineers • 企業資格 • AWS アドバンストティアサービスパートナー認定 • APN Certification Distinction 200 • AWS公共部門パートナープログラム認定
3. 2 まずは基本的なこと
4. 3 XSSとは • クロスサイトスクリプティング（XSS）攻撃とは、Webサイトのセキュリティ上 の欠陥（脆弱性）につけこんで不正なスクリプト（簡易プログラム）を埋め込み、 サイトを閲覧した不特定多数のユーザーにスクリプトを実行させることで不正サ イトへの誘導、またはサイトからの情報搾取などを目的とした、悪質なサイバー 攻撃のことです。 • いつ頃からあるか？ • 少なくとも10年以上前(2009年ぐらいから？）からある攻撃手法 出典：IPA（安全なウェブサイトの作り方） https://www.ipa.go.jp/security/vuln/websecurity/cross-site-scripting.html?_fsi=DQmKIvAm
5. 代表的な手口 4 〇〇掲示板 ニックネーム メッセージ 太郎 Jawsfesta最高！ 投稿 キャンセル 太郎 Jawsfesta最高！ ①正規ユーザーがJawsfesta 最高！と入力 ②投稿ボタンを押す 正常な入力 ③入力内容が表示 される 〇〇掲示板 ニックネーム メッセージ 太郎 <script>window Open(“http://悪者 サイト”)</script> 投稿 キャンセル ①悪いやつがポップアップする悪意の あるサイトを開くスクリプトを投稿 ②投稿ボタンを押す 悪意のある入力 ③スクリプトが埋め込まれる 入力内容をサニタイズし ていない（文字列チェッ クしてない） クレジットカード 番号を入力してく ださい ④正規ユーザーが掲示板開いただけで 悪意あるサイトがポップアップされる ポップアップ • 脆弱性があるサイトから不正なスクリプトを仕込む • ECサイトの投稿欄とか外部からのユーザーがデータを入力できるところから仕込む • そもそも脆弱性があるサイトとはなにか？ • ユーザー入力のバリデーション不足（入力内容をサニタイズしていないとか、エスケー プ文字列処理の不備でスクリプトが実行されてしまう）
6. 5 代表的な防御策 • AWS WAFによるブロック • XSSを検知するルールセットを活用することでサーバーにリクエストを到達させない • そもそも脆弱性のあるコードを開発段階でDeployさせない • SAST製品の導入 • SAST（Static Application Security Testing）とは、アプリケーションのソースコードを静的に解析し、脆弱性を特定するための検査 手法です。 アプリケーションが動作していなくても実施可能で、開発の初期段階で脆弱性を検出するために実施されます。 • OSSならSonerQubeが有名、製品版ならSnykが有名 出典:https://aws.amazon.com/jp/builders-flash/202207/start-for-security/ Elastic Load Balancing Developer 運用管理者 Users Internet AWS WAF AWS WAF
7. 6 それでもなくならないXSS被害
8. 7 IPAからの考察① 出典：脆弱性対策情報データベース「JVN iPedia」より2020年以降のAWSのXSS事例を検索 • 事例その１：IPAのサイトから 脆弱性対策情報データベース「JVN iPedia」より2020年以降のAWSの XSS事例を検索
9. 8 IPAからの考察② ①https://www.cve.org/CVERecord?id=CVE-2023-2452 一Wordpressプラグインの入力のサニタイズ、エスケープ出力の不備に原因 ②https://www.cve.org/CVERecord?id=CVE-2023-41944 一Jenkins AWS CodeCommit トリガープラグイン 3.0.12 以前では、エラーメッセージをレン ダリングするときに、フォーム検証 URL に渡されるキュー名パラメータをエスケープしない ため、HTML インジェクションの脆弱性が発生します。 ③https://www.cve.org/CVERecord?id=CVE-2022-24709 一awsui/components-react は、ユーザーインターフェイス開発用に設計された TypeScript 定義を含む React コンポーネントを含むメインの AWS UI パッケージです。3.0.367 より前 のバージョンの複数のコンポーネントでは、ユーザー入力が適切に無効化されず、JavaScript インジェクションが許可される可能性があることが判明。 出典：脆弱性対策情報データベース「JVN iPedia」より2020年以降のAWSのXSS事例を検索 • ほぼOSSの脆弱性が起因、、、 • OSSを利用する以上、自社開発部分のセキュアコーディングを実施 だけでは防げない • 機能リリースの時間経過とともに脆弱性対策の強度も低下する
10. 9 IPAからの考察③ 出典：IPA：ソフトウェア等の脆弱性関連情報に関する届出状況[2024年第2四半期（4月～6月）https://www.ipa.go.jp/security/reports/vuln/software/2024q2.html IPA：ソフトウェア等の脆弱性関連情報に関する届出状況[2024年第2四 半期（4月～6月） ウエブアプリケーションの脆弱性 が圧倒的 インジェクション系が圧倒的
11. 10 IPAからの考察④ 所感 利用しているOSS,ツールの脆弱性から被害 を受けるパターンが大多数と見える。自社 内の開発スキームがしっかり実施されてい ても、放置された脆弱性からＸＳＳ被害を 受けると思われる。 SecurityHubで検出される脆弱性をしっか り把握し、世の中的に発生している脆弱性 にアンテナを張り、自社のAWS環境に影響 がないか定期的な棚卸（精査）を実施して いくことが大切といえそうです。 IPA：ソフトウェア等の脆弱性関連情報に関する届出状況[2024年第2四 半期（4月～6月） オープンソース起因が圧倒的 出典：IPA：ソフトウェア等の脆弱性関連情報に関する届出状況[2024年第2四半期（4月～ 6月）https://www.ipa.go.jp/security/reports/vuln/software/2024q2.html
12. 11 AWS WAFとは • AWS WAFとはロードバランサー、CloudFront、API GWなど外部とや り取りする部分にアタッチするAWS製のWAFのこと • マネージドルールとしてXSSを検知、ブロックするルールも提供されている • 例えば、AWS WAF Web ACLにおけるAWS マネージドルール ルールグループリストの中の一つ である、コアルールセット (CRS) マネージドルールグループは、XSSパターンがリクエストボ ディに存在しないかを調べてくれるルール。 ②XSSのペイロードパターンと検知してブロック AWS WAF Managed rule ①怪しいペイロード <script>alert(1)</script> User ③Reject WEB Server(Amazon EC2) 怪しいペイロードは到達しない
13. 12 AWS WAFをすり抜けるパターンもある • AWS WAFをバイパスする事例（コアルールセット、XSSルールセットだけ では安心できない） • WAFが解析できないペイロードでスクリプトを書く • リクエストボディにWAFが認識できない形でスクリプトを書けばWAFをバイパスできる • 例：Unicodeでエンコードを行う（注：今では改修されているかもしれません） ②XSSのペイロードパターンとして検 知ができず、Bypassされる AWS WAF Managed rule ①Unicodeでエンコード エンコード前 <script>alert(1)</script> エンコード 後 ¥u003C¥u0073¥u0063¥u0072¥u0069¥ u0070¥u0074¥u003E¥u0061¥u006C¥u 0065¥u0072¥u0074¥u0028¥u0031¥u0 029¥u003C¥u002F¥u0073¥u0063¥u00 72¥u0069¥u0070¥u0074¥u003E 悪意のある ユーザー ③スクリプト実行してしまう WEB Server(Amazon EC2)
14. 13 AWS WAFをすり抜けるパターンもある その他にもAWS WAFをバイパスするには多数の方法が存在するし、 OWASPが公開しているやり方もある。 過信は危険。 出典：https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF
15. 14 AWS WAFをすり抜けるパターンもある • AWS WAFの設定はユーザーの責任 • 設定するルールによって、XSS攻撃がすり抜けるパターンも出てくる • そこはオンプレのWAF（F5みたいな製品）とはノリが違うので注意が必要といえそうです。 出典：https://aws.amazon.com/jp/compliance/shared-responsibility-model/ セキュリティに関する設定はユーザーが責任を持つ
16. 15 AWSでの防御策ってなんだろう？
17. よくあるケース 16 User Internet Firewall Server OS ミドルウエア アプリケーション OSS アプリチーム担当 インフラチーム担当 この辺で発生したOSSとかミ ドルウエアの脆弱性が問題 OSSの脆弱性の問題はインフラチー ムからボトムアップでアプリチーム へ連絡し対応をお願いする OSSの脆弱性の問題は大抵パッチあて かVerUpが必要で機能確認含め時間が かかる。ミドルエアも同様（アプリの 開発スケジュールにも影響が出る） • OSSの脆弱性が検知されても、簡単にパッチを充てるわけにはいかない ケースが多い • 脆弱性を検知するのはインフラチームだが対応するのはアプリチーム • パッチあて、VerUpが大抵必要 • アプリが動かなくなるケースもある • アプリの改修が発生するパターンもある • 時間がかかるので放置され気味という悪循環（放置している間に被害が進む） • 有事の際に責任を取るのはインフラチームであるというケースも多い • なので、インフラチームとしても放置はできない。。
18. 17 放置すればなにが起こるか • 一番怖いのはSSRF • SSRF（＝Server Side Request Forgery）といわれる攻撃です。 SSRFは、例えばクラウド上にあ る外部に公開されているサーバから、内部のサーバに送られるリクエストを偽造し、本来公開され てないサーバにアクセスするという手法。 Virtual private cloud (VPC) Public subnet Private subnet 脆弱性放置の サーバー (Amazon EC2) 個人情報が入っ てるサーバー (Amazon EC2) IMDSv1.0でサーバー情報取得 クレデンシャル入手 悪意のある ユーザー 脆弱性をついて 不正アクセス、 情報詐取 強力なRole どこでもい けるルート がある
19. 18 AWSの設定を見直そう その① • WAFのルールセットを定期的に見直そう • 無理ならWafCh〇〇mなど外部ベンダーに運用を依頼しましょう • 脆弱性のあるサーバーには以下を実施 • アタッチされているRoleを必要最小限の権限に絞る • Adminは最悪 • アタッチされているルートテーブルのルートを最小限に絞る • アウトバウンド通信を必要最低限に絞る • できなければ不正なアウトバウンド通信を監視する • 最悪でもGuardDuty,DNSfireWallはＯＮにしてログを取り監視 • 侵入されれば不審なところに必ずアクセスするはず • IMDSｖ1.0は無効にする（ｖ2.0に変更する） • 認証なしで簡単にサーバーの認証情報がとれてしまう • CloudTrailのデータイベントはONになっているか確認 • 管理イベントしかとってないと、悪意のある挙動はわかりません • CloudTrailのイベントを確りS3に保存しておく • 悪意のある攻撃は長期目線でやってきます。CloudTrailはデフォルト90日しか保持してな いのでS3にしっかり保存しておきましょう • S3の暗号化キーを分離するのも有効な手段 • 大事なデータの暗号化キーは管理者しかアクセスできないキーで暗号化
20. 19 AWSの設定を見直そう その② • バックアップをしっかりとって有事に備える • 不正が見つかったら正常な状態に復元できるようにしておく • 攻撃者がアクセスできない形で保存 • S3のバージョニング、オブジェクトロック • EBSスナップショットのごみ箱機能のルールロック • 攻撃者がデータをすててもゴミ箱から復旧できるから • AWS Backup(コンプライアンスモードで利用） • これらは最近なにかと話題のランサムウエア対策にも有効です。 • イミューダブルバックアップ • S3の暗号化キーをできるだけ分離する（管理者しかアクセスできないキーで暗号化） ～結局はAWSの設計原則の原点に立ち戻って設定を再度見直すのが一番～ ①最小権限付与の原則に立ち戻る ②ネットワークのマイクロセグメンテーションに立ち戻る ③いつから不正が起こったかトレースできるよう準備をする （もしかしたらAWSに相談したら不正操作によって立ち上げられたリソース分の課金免除を ログをエビデンスにお願いできるかもしれません、ログがなければそのお願いもできません）
21. 20 包括的なセキュリティ対策も重要
22. 21 AWS環境のセキュリティ状況を可視化してみよう • “AWSセキュリティ成熟度モデル“をフル利用しよう！！ • 64個の質問に答える（実際は調査になるけど）だけでAWSのセキュリティ状況のウ イークポイントが可視化できる • Wellアーキほど大変じゃない。Wellアーキでよくお客様から“よし なにやっといて”の要望にも応えてくれる優れもの AWS環境のセキュリティ状況を可視化してみよう！ （どこが不足しているか気が付ける） AWS環境のセキュリティ対策は脆弱性だけじゃない 局所的に設定をみていても気が付けないウイークポイントが発生する
23. 22 AWSセキュリティ成熟度モデルv1（Step1） 64項目の調査内容の抜粋（例 • QuickWin（最初にすべきこと Basic設定） • アイディンティティとアクセス管理 • Root権限の扱いや多要素認証をどうしているか？ • Foudational（基本となる実装がどこまでできているか) • インフラ保護 • Ssh,RDP接続の管理をどうしているか？ • インターネットにさらされているリソースの管理をどうしているか？ • Efficient（効率化自動化） • 複数AWSアカウントの連携やオンプレとの連携はどうしている？ • Optimized（最適化） • 運用の自動化及び最適化、DevSecOpsなど開発環境の最適化をどうしているか？ ６４項目の調査実施 Step1：提供されるエクセルのチェックシートでAWS環境アセスメント実施する ＜4つのフェーズ＞ 1.クイックウィン(Quick Wins) 2.基礎(Foundational) 3.効率化(Efficient) 4.最適化(Optimized) ＜9つのカテゴリ＞ 1.セキュリティ ガバナンス 2.セキュリティ保証 3.アイデンティティとアクセス管理 4.脅威検出 5.脆弱性管理 6.インフラ保護 7.データ保護 8.アプリケーションセキュリティ 9.インシデント対応 出典：https://v1.maturitymodel.security.aws.dev/en/
24. 23 AWSセキュリティ成熟度モデルv1（Step2） Step2：エクセルのマクロを実行しAWS環境のセキュリティ状況を可視化する グラフの凹みの大きい箇所がボトルネックとなります 64個の質問に回答し、エクセルのマク ロを実行すると、こんな風に可視化さ れます 黄色と赤のマーク部分が改善ポイントになります。 出典：https://maturitymodel.security.aws.dev/en/model/
25. 24 AWSセキュリティ成熟度モデルv1（Step3） Step3：可視化結果を分析、考察しウイークポイントをどうするか検討しよう • 複数のAWSアカウントの統制が取れていない • ガードレール的な仕組みが実装されていない • アカウント間を横串で監視する仕組みがない • L3/L4ベルのセキュリティがない • SOAR的な仕組みがない • 運用工数の削減対策がない • 複数AWSアカウントの統制 • SIEM On AWSの導入 • AWS ControlTowerの導入 • L3/L4監査サービスの導入 • DNSfireWall,NetWorkFireFallの導入 • SOAR的な仕組みの推進 • 頻度が高いインシデントに対する自動復旧による工数削減 • AWSConfigRule,SystemsManagerのPlayBookによる自動普及 可視化結果からの改善提案、実装の推進（前ページの可視化結果からのサンプル） 可視化結果からの考察（前ページの可視化結果からのサンプル）
26. 25 AWSセキュリティ成熟度モデルv1（改善例） アセスメント結果で見えた課題（Before） ・複数AWSアカウント間を横串で監視する仕組みがない（OU構成をと れない事情があり、AWSアカウント毎に監視を実施） ・機能リリースの時間経過とともに脆弱性対策の強度が低下する ・脆弱性の対応状況が可視化されていない 解決/効果（After） ・SIEM on AWSの導入による複数AWSアカウントのリソース状況の可視化と監 視を実装 ・AWSサービスに特化した豊富な監視ダッシュボードの早期実装 ・低コスト、内製化運用可能なSIEMの実装（市販メジャー製品の10％以下） ＜構築構成＞ ＜監視ダッシュボードの一例＞ 出典：https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/README_ja.md
27. こちらで紹介したAWSセキュリティ成熟度モデルv1を利用したアセ スメントは当社でも支援しておりますので、ご興味のある方は是非 お問い合わせください！ 26 AWSセキュリティ成熟度モデルv1（当社ソリューションの紹介） 会場ブースにて右記パンフ レットの配布、説明もして おりますので、SHIFTブー スにお立ち寄りくださ い！！ ソリューション紹介ページ：https://service.shiftinc.jp/security/aws-security-maturity-model/
28. 27 まとめ
29. 28 まとめ • AWS WAFを過信しない、ルールセットは定期的に改善しよう • 脆弱性を解決できないサーバーがいたら最小権限付与の原則、ネッ トワークのマイクロセグメンテーションの原点に立ち戻って設定を 見直してみよう • 有事の際にいつから事象が発生したかしっかりトレースできるよう、 ログの設定を見直してみよう • バックアップを改ざん削除できない形で定期的に保存しよう • S３の暗号化キーはできるだけ権限別に分離しましょう • AWSセキュリティ成熟度モデルを活用し、全体的にどこがウイー クポイントなのか考察してみよう 特に脆弱性のある部分については、AWSのベストプラクティスに沿っている か再度見直し、今できることをしっかり実施しておきましょう！
30. 29 ブースにも是非お立ち寄りください。 SHIFT主催イベントの ご参加もお待ちしております。 connpass →