2020年4月24日

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ロールとリソースポリシーを作成することを承認します。」にチェックのうえ、[デプロイ]ボタンをクリックすると、環境の構築が始まります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

参考資料

執筆者の他の記事を読む