デジタルペンテスト部の鈴木です。
普段はプラットフォーム診断を担当しています。
はじめに
近年、生成AIやAIエージェントの急速な発展により、さまざまな分野で業務の自動化が進んでいます。ソフトウェア開発や運用の分野でもAIの活用が広がっており、セキュリティ領域においてもその流れは加速しています。
こうした背景の中、AWSはAWS Security Agentという新しいセキュリティサービスを発表しました。
本記事では、AWS Security Agentの概要を簡単に紹介した後、実際に検証環境を構築し、Webアプリケーションに対するペネトレーションテストの機能を実行するまでの手順について解説していきます。
また、記事の後半では、AIによって作成されたWebアプリケーションに対してAIによるペネトレーションテストを実行してみた結果もお見せしたいと思います。
AWS Security Agentとは
AWS Security Agentは、AIエージェントを活用してWebアプリケーションのセキュリティ面を自動的に検証するサービスであり、設計・コード・実行中のアプリケーションに対するセキュリティレビューやペネトレーションテストを自動化することができます。
現状以下の3つのサービスが利用できます。
・デザイン・セキュリティ・レビュー
・コードセキュリティレビュー
・ペネトレーションテスト
特に注目すべき機能の一つが、AIによる自動ペネトレーションテストです。AWS Security Agentは複数のAIエージェントを組み合わせた仕組みを利用して、アプリケーションの構造や挙動を理解しながら攻撃シナリオを生成し、実際の攻撃をシミュレーションすることができます。
従来のペネトレーションテストでは、エンジニアが攻撃手法を考えながら手動で検証を行う必要があり、多くの時間と専門的な知識が必要でした。しかし AWS Security Agentを利用することで、これらの作業を自動化し、数週間かかることもあるペネトレーションテストを数時間単位で実行できる可能性があります。
また、AWS Security Agentは単純な脆弱性スキャンツールとは異なり、アプリケーションの設計ドキュメントやソースコード、セキュリティ要件などの情報を理解したうえでテストを実行します。そのため、従来のツールでは見つけにくかった複雑な攻撃経路やロジックの欠陥なども発見できる可能性があります。
ペネトレーションテスト実行までの手順
※ご自身で実行する場合は必ず事前に許可を得た対象にのみ行うようにしてください。
まずはこちらのページにアクセスし「AWSセキュリティエージェントを使い始める」をクリックします。
https://aws.amazon.com/jp/security-agent/
「AWSセキュリティエージェントをセットアップ」をクリックします。
「エージェントスペース名」、「ユーザーアクセス設定」を入力し、「AWSセキュリティエージェントをセットアップ」をクリックします。
エージェントスペースが作成されたことを確認できたら、それをクリックします。
「ペネトレーションテストを有効化」をクリックします。
「ドメインを追加」をクリックし、
ドメインを選択します。その後、「次へ」をクリックします。
※前提として今回の検証では、EC2 上にDVWA(Damn Vulnerable Web Server)を展開しています。
また、AWS Security Agent でペネトレーションテストを実行するためには、対象となるアプリケーションをドメイン名で指定する必要があります。そのため、今回はRoute 53 を利用し、独自ドメインを紐付ける設定を事前に行っています。
他のDNSサービス等で管理している場合でも、DNSテキストレコードかHTTPルートのどちらかで検証する必要があるようです。
ターゲットドメインを選択し「次へ」をクリックします。
ここで様々なオプションを追加できます。
今回は、VPCオプションを選択しました。
対象がパブリック上にない場合は、適切にVPCの情報を入力する必要があります。
入力が終わったら、「保存」をクリックします。
ターゲットドメインを選択して、「One-click verification」をクリックします。
ドメインをRoute53に登録している場合、この手順で簡単にDNS検証レコードを作成できます。
内容を確認して、「DNSレコードを作成」をクリックします。
ステータスが検証済みになっていればOKです。
「ウェブアプリ」をクリックし、「管理者アクセス」をクリックします。
「Create penetration test」をクリックします。
このページで様々なオプションを選択できます。
・Pentest name：こちらは任意の名前を入力します。
・Target URL：対象となるURLを入力します。
・Exclude risk types - optional：リストからチェックをつけることで、除外したいリスクを選択できます。
□Arbitrary File Upload
□Code Injection
□Command Injection
□Cross-Site Scripting(XSS)
□Insecure Direct Object Reference
□JSON Web Token Vulnerabilities
□Local File Inclusion
□Path Traversal
□Privilege Escalation
□Server-Side Request Forgery(SSRF)
□Server-Side Template Injection
□SQL Injection
□XML External Entity
・Out-of-scope URLs - optional：対象外にしたいURL
・Accessible URLs - optional：アプリケーション上アクセスが必要なURLだが、対象からは除外したいURL
・Custom HTTP headers - optional：カスタムしたHTTPヘッダー
・Service role：ペネトレーションテスト実行のためのIAMロール
・CloudWatch log group - optional：ペネトレーションテスト実行時のログ保存場所
・Automatic code remediation：ペネトレーションテストの結果に対してコードの修正を自動で実施してくれるオプション
今回は、以下の入力で「Next」をクリックします。
Target URLにポート指定のURLを入力する場合現状では、80か443にしか対応していないようです。IPアドレス:8080などの入力が含まれているとエラーメッセージが出てきてスキャンの開始ができません。
今回は、「VPC」、「Subnet」、「Security groups」を入力し、「Next」をクリックします。
このページでは、認証情報の登録を行えます。
今回は何も設定せずに「Next」をクリックします。
このページでは、ファイル、GitHubリポジトリ、S3リンクなどの既存のリソースなどを追加でアップロードできます。
今回は、何も設定せずに「Create pentest」をクリックします。
これでペネトレーションテスト開始の準備ができましたので、「Start run」をクリックします。
テスト開始の準備が整っているか聞かれるので、準備OKの場合は「Start run」をクリックしてテストを開始します。
テストが開始されたので、終了まで待ちます。
スキャンが完了するとこのような画面を見ることができます。
参考までに、スキャン時間は2時間48分20秒でした。
ちなみに、今回DVWAのセキュリティレベルは対策が一切されていないとされる「Low」で実行しました。
スキャン結果
「Findings」タブをクリックすると、スキャン結果のレポートを詳細に見ることができます。
DVWAに含まれている代表的な脆弱性は、一通り検出されていることがわかるかと思います。
検出項目を一つずつ確認していきたいところですが、今回はコマンドインジェクションのレポートを軽く見てみたいと思います。
「Description」では、今回の対象のどの部分が原因でコマンドインジェクションに繋がってしまったのかの概要が書かれています。
「Steps to reproduce」では、コマンドインジェクションまでの再現手順が書かれています。
ここで気になるのは、実際に再現手順通りに実行したらコマンドインジェクションが発火するかどうかです。
試しに再現手順通りのやり方で手動で実行してみたいと思います。
Step1、Step2ではどのようにこのエンドポイントを特定したかが書いてありますが、今回はあまり重要ではないのでこの手順は省きます。
Step3には実際に入力したペイロードが書かれているので、それをコピペします。
「ip=127.0.0.1; ls」を入力し「Submit」ボタンで送信すると書いてあるのでその通りに実行します。
すると、無事にディレクトリ一覧の表示つまりlsコマンドの実行結果が確認できました。
簡単なものであればこのように再現手順通りに実施すれば、発火しました。
すべての項目を手動で試した訳ではないので、すべて上手くいくかまでの確証はできておりませんが、この再現手順はわかりやすくて良いと思いました。
「Risk Reasoning」では、CVSSの評価項目を出力してくれています。
続いて、DVWAのセキュリティレベルを「Impossible」にした状態でスキャンをかけた結果をお見せします。
一応Impossibleは、脆弱性が修正されセキュアなコーディングが行われている状態とされていますが、結果を見る限りLowの時よりは少ないものの普通に問題点が検出されています。
問題点の詳細を見てみましょう。
Lowの時にもあったコマンドインジェクションの問題点が検出されています。
しかし、、、再現手順をよく見てみると「脆弱なコマンド実行モジュールにアクセスするには、セキュリティレベルを「Low」に設定してください。」と書かれています。
確かに、DVMAではボタン1つでセキュリティレベルを変更できるのでこの手順が間違っているかと言われたら否定はできませんし、しっかりシステムを全体を見てくれている証拠とも言えます。この再現手順にはとてもAIらしさを感じられる面白い結果となりました。
AI(Claude)によって作成されたWebアプリケーションに対してペネトレしてみる
今回は、このようなプロンプトを投げました。
色々ツッコミどころはあると思いますが、機能は最小限で作成してもらいました。
出来上がったものはこちらになります。
・ログイン画面：トップページでサイトへのログインができます。
・アカウント作成画面：アカウントの新規作成ができます。
・掲示板画面：文字を入力して投稿したり、他人の投稿を見れたりします。また、自分がログインした状態でこのページに遷移すると投稿の削除ができます。
・管理者用のログイン画面：ここからあらかじめ作成されている管理者アカウントでログインすることで管理者用ページへ遷移できます。
・管理者画面：ここからユーザ情報の閲覧、ユーザの削除ができます。
では、このWebアプリケーションに対してAWS Security Agentによるペネトレーションテストをしていきます。
結果は1件だけCriticalが検出されました。
中身を見てみると、サーバ側で認証に関する検証を行っておらず、Javascriptだけで実装しているよと報告されています。
また、認証情報もハードコードされていて、セッション管理もクライアント側で実装されているよと報告されています。
ここまで情報が取れていますが、実際に認証バイパスの成功までは至っていないようです。
一応、ソースコードを見てみると確かに認証情報がハードコードされていることが確認できます。
実際に手動でブラウザでjsを実行して/adminへアクセスしたところ、パスワード入力なしで管理者ページへアクセスできました。
次に、レポートをClaudeに丸投げしてこの問題点に対する対策を取ってもらうことにしました。
結果は、Medium3件で先程のCriticalは対策されているようでした。
今回の対策でClaudeがバックエンドの実装を行っていたので、新たな重大なリスクが発見されるかと思っていましたが以外にも見つかりませんでした。
まとめ
今回は、AWS Security Agentの自動ペネトレーションテストの機能に絞って解説してみました。
個人的に面白かった点は、DVWAのセキュリティレベルをImpossibleの状態でスキャンした際に検出された問題点の再現手順としてセキュリティレベルをLowに落とす手順が記載されていたところです。
この部分は、今のAIらしさを顕著に感じられました。
再現手順やレポートを見ると既存のペネトレーションテストの代替として実務レベルで使用するには、少し物足りなさを感じました。
しかし、学習用として考えればとても有効なサービスだと思います。
環境構築でつまずくことはなかったですし、UIも全体的に見やすく感じました。
また、単純な問題点であれば、手順に沿ってペイロードをコピペするだけで悪用することができるので早い段階でペネトレーションテストのロジックを学べると思いました。
現在AWS Security Agentは、プレビュー期間中で無料で利用できますので気になった方はぜひ触ってみてください。
