Compact
true
担当領域:セキュリティ技術センター リスクハンティングチーム
お客様へ納品するサービス・製品の脆弱性診断、リスクアセスメント業務を通して、NECグループのセキュア開発・運用を推進。 RISS、GPEN、CISSP Associate、CCSP Associate、AWS-SAAを保持。

NECサイバーセキュリティ戦略本部セキュリティ技術センターの大家です。本記事では、サーバレスアーキテクチャのセキュリティについて学びたいと考えている方向けに、トレーニング目的のため敢えて脆弱に作られた(いわゆるやられ環境)サーバレスアプリケーションである"DVSA; a Damn Vulnerable Serverless Application"[1][2]をご紹介します。

DVSA; a Damn Vulnerable Serverless Applicationとは

DVSAは、サーバレスアーキテクチャにおける一般的な脆弱性をあらかじめ盛り込んで作成された教育用のアプリケーションです。OWASPのプロジェクトで開発されています。主な利用用途は、システム開発者がサーバレスアプリケーションをセキュアにする方法を学ぶこと、セキュリティ専門家がサーバレスアプリケーションに対する脆弱性診断スキルを磨くことなどです。2020年4月20日時点で、AWSのサービスを使用したサーバレスアプリケーション構築用のレポジトリが公開されています。DVSAのネーミングは、トレーニング用の脆弱なウェブアプリケーションとして有名な"DVWA; Damn Vulnerable Web Application"[3]を意識しているものと思われます。

注意事項

DVSAの構築をサービス開発・公開に使用するAWSアカウントで行わないでください。実際に第三者からの攻撃を受けて被害が生じる、あるいは、別の方への攻撃に利用されるような事態が発生する可能性も否定できません。本環境の利用には細心の注意を払うようにしてください。

環境構築

DVSAはAWS Serverless Application Repository (https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:889485553959:applications~DVSA) からデプロイできます。レポジトリのページ右上にある[Deploy]ボタンをクリックすると、AWS Lambdaのコンソールに遷移します。遷移後のページの右下にある、「このアプリがカスタムIAMロールとリソースポリシーを作成することを承認します。」にチェックのうえ、[デプロイ]ボタンをクリックすると、環境の構築が始まります。

[Deploy]をクリック
[Deploy]をクリック
100
「このアプリが...」にチェックのうえ、[デプロイ]をクリック
「このアプリが...」にチェックのうえ、[デプロイ]をクリック
100

環境の構築が完了後、[CloudFormationスタックの表示]ボタンからCloudFormationの管理コンソールに行き、[出力]タブを表示させると、ウェブサイトのURLを確認することができます。

[CloudFormationスタックの表示]をクリック
[CloudFormationスタックの表示]をクリック
100
[出力]タブにウェブサイトのURLが記載されている
[出力]タブにウェブサイトのURLが記載されている
100

ウェブサイトのURLにアクセスし、アカウント作成ページが表示されれば、DVSAの環境構築は完了です。

URLアクセス直後の画面
URLアクセス直後の画面
50

ウェブサイトの探索・診断

DVSAのベースとなるウェブサイトは、会員制のショッピングサイトです。アカウント作成、商品の閲覧、カートへの追加、購入・支払い手続き、運営への問い合わせなどの一般的なショッピングサイトの機能が実装されています。DVSAのGithubレポジトリには、DVSAに盛り込まれた脆弱性に関する下記10個のチュートリアルが公開[4]されていますので、何から着手すればよいかわからない場合は、このチュートリアルを参考にすると良いと思います。私はひとまずチュートリアルの内容は見ずに取り組みました。なお、本アプリケーションには、チュートリアルで説明されているもの以外の脆弱性も存在するとのことです。

本記事では、私が本アプリケーションを探索・診断するなかで見つけた脆弱性のうち、2つの脆弱性をご紹介します。

1. 認証トークン処理の不備

1つ目は、認証トークンの処理の不備に関する脆弱性です。本アプリケーションは、アカウントの認証をCognitoで行い、Cognitoによって払い出される認証トークンをその後のAPIリクエストの"authorization"ヘッダにセットすることで、利用者に応じた情報の表示や処理を行う実装となっています。

ログイン時の通信
ログイン時の通信
100

この認証トークンはJWT形式のようですので、JWTをデコードできるウェブサイト[5]を使用して中身を確認してみます。デコードした中身を見ると、ペイロードに"username"という項目があることを確認できます。また”username”の値は、ログイン直後に実行されるAPIリクエスト(アカウント情報の取得)のレスポンスに含まれる、"userID"の値と一致します。

認証トークンの内容
認証トークンの内容
100
アカウント情報(ユーザ名: octo@...)
アカウント情報(ユーザ名: octo@...)
100

この"username"の値を改ざんし、別のユーザのアカウント情報が取得できるか検証します。検証のため、別のアカウント(ユーザ名: septem@...)を作成し、"userID"の値を確認します。

アカウント情報(ユーザ名: septem@...)
アカウント情報(ユーザ名: septem@...)
100

次に、認証トークンの"username"の値が、確認した"userID"の値となるように、トークンの内容を書き換えます。

認証トークンの書き換え
認証トークンの書き換え
100

書き換えを行ったトークンを"authorization"ヘッダにセットし、アカウント情報取得のAPIリクエストを送信すると、検証用に作成した別ユーザのアカウント情報が取得できてしまいました。したがって、本アプリケーションには、認証トークンの"username"に該当する部分を総当り攻撃されることでウェブサイトに登録されたアカウント情報を窃取される脆弱性があることが確認できます。

書き換えた認証トークンをセットしAPIリクエストを送信
書き換えた認証トークンをセットしAPIリクエストを送信
100
他ユーザのアカウント情報が取得できた
他ユーザのアカウント情報が取得できた
100

この脆弱性は、認証トークンを検証する箇所の不備が原因と考えられます。AWSの管理コンソールとソースコードを確認したところ、API Gatewayでは認証トークンの検証を行わないままリクエストをLambda関数に渡しており、また、Lambda関数ではトークンの"username"の値が、データベースに登録されていることのみを確認して処理を実行する作りとなっていました。認証トークンの検証には、独自実装ではなくAPI GatewayとCognitoの連携機能[6]を活用すると良いでしょう。

API Gatewayで認証トークンの検証は行っていない
API Gatewayで認証トークンの検証は行っていない
100
トークンの"username"のみが抜き取られている
トークンの"username"のみが抜き取られている
50
トークンの"username"の値でDBを検索し合致した登録内容を返している
トークンの"username"の値でDBを検索し合致した登録内容を返している
50

2. S3バケットのアクセス制御設定の不備

このアプリケーションでは静的コンテンツの格納にS3を使用していることが、URLからも推測できます。まずは、ウェブページのメインコンテンツを格納しているバケットにファイルを置くことができるのか検証してみます。

ウェブサイトのホスト名からS3静的ホスティングと推測される
ウェブサイトのホスト名からS3静的ホスティングと推測される
100
S3バケットへのファイルアップロード試行(失敗)
S3バケットへのファイルアップロード試行(失敗)
100

当然ながら、このバケットには書き込み権限が無いようです。その後、ウェブサイトを探索するなかで、ウェブサイト運営への問い合わせページに、ファイルアップロード機能があることを見つけました。ここからアップロードされたファイルは、S3に保存されるのではないかと考えました。

問い合わせページ
問い合わせページ
100

適当なファイルを添付してメッセージを送信した際のリクエストを確認すると、ファイルを送信しているように見えるAPIリクエストがありました。そのレスポンスを確認してみると、ファイル格納先のS3バケットのURLが記載されていました。

ファイル送信APIのレスポンス
ファイル送信APIのレスポンス
100

このS3バケットにファイルを格納できるか試してみたところ、ファイルの格納ができ、更に格納したファイルにアクセスができることがわかりました。したがって、第三者が任意のファイルをこのS3バケットにアップロードし、アクセスできる状態であるといえます。

S3バケットへのファイル送信試行(削除もできる模様)
S3バケットへのファイル送信試行(削除もできる模様)
100

AWSの管理コンソールを確認したところ、このS3バケットには、ファイルの書き込み権限、アクセス権の変更権限、ファイルの読み取り権限、ファイルの削除権限が付与されていました。問い合わせ時のファイル送信機能においては、Cognitoによって認証されたユーザのみがファイルをアップロードできるようにし、ユーザ側からのファイル取得は制限するようにアクセス制御を行うべきです。

S3バケットのアクセス権限
S3バケットのアクセス権限
100

まとめ

本記事では、サーバレスアーキテクチャにおける脆弱性を盛り込んで作成されたトレーニング用の環境である"DVSA"を紹介しました。比較的新しいアーキテクチャや機能を用いて実装されているトレーニング環境はとても貴重です。ぜひ皆さん挑戦してみてください。

参考資料

[1] https://github.com/OWASP/DVSA

[2] https://owasp.org/www-project-dvsa/

[3] https://www.dvwa.co.uk/

[4] https://github.com/OWASP/DVSA/blob/master/AWS/LESSONS/README.md

[5] https://jwt.io/

[6] https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html

執筆者プロフィール

original
50

大家 政胤(おおや まさつぐ)
セキュリティ技術センター リスクハンティングチーム

お客様へ納品するサービス・製品の脆弱性診断、リスクアセスメント業務を通して、NECグループのセキュア開発・運用を推進。 RISS、GPEN、CISSP Associate、CCSP Associate、AWS-SAAを保持。