Flatt Security Blog

株式会社Flatt Securityの公式ブログです。情報漏洩等につながる脆弱性がないか調査する「セキュリティ診断」とWeb開発者向けセキュアコーディングのeラーニング「KENRO」を提供しています。」

株式会社Flatt Securityの公式ブログです。
技術的な知見や社内の雰囲気を伝える記事を発信しています。

EDoS Attack: クラウド利用料金でサービスを止められるって本当?

どうもお久しぶりです。株式会社 Flatt Security セキュリティエンジニアの Azara(@a_zara_n)です。普段は Web やプラットフォームの診断やクラウド関連の診断と調査、Twitter ではご飯の画像を流す仕事をしています。 よろしくお願いします。

セキュリティ診断にご興味のある方は是非「料金を自分で計算できる資料」を公開しているので、ダウンロードしてみてください。

DoSやDDoSといったサイバー攻撃はみなさん聞いたことがあると思いますが、クラウド時代において、これらと並びサービスの継続に非常に関わってくる攻撃があるのはご存じでしょうか?

世の中ではEDoS(Economic Denial of Sustainability)攻撃と呼ばれるもので、読んでの通り、経済的にサービスを停止させるといった攻撃です。

過去の事案であれば、2022年の06月に発生した、”NHK厚生文化事業団が運営する寄付サイトへの偽計業務妨害事案1 でNHK厚生文化事業団が決済代行サービスの利用で手数料として50万円の経済的負担をかけられたというものもあり、クラウドを始め従量課金が進む時代だからこそ頭の片隅に留めておく必要がある攻撃であると筆者は考えています。

本稿ではこの”EDoS“についてどのような時に発生し、いかなる対応を施すと緩和することができるのかについて書いていきたいと思います。

免責事項

本稿は、クラウドサービスをはじめとした従量課金制を取るサービスへのEDoS攻撃に対する注意喚起を目的とした記事となっています。記事の内容を悪用などの攻撃行為を推奨するものではありません。許可なくプロダクトに攻撃を加えることは、犯罪になる可能性があります。また、当社が記載する情報を参照・模倣して行われた行為に関して当社は一切責任を負いません。

クラウド時代におけるサービス継続の重要性と停止を狙った攻撃

クラウドを利用することによる利便性について

NIST SP800-145^2の定義ではクラウドコンピューティングの特性は以下の通り述べられています。

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

引用: SP 800-145 The NIST Definition of Cloud Computing(原文)

ユーザは、各サービスの提供者と直接やりとりすることなく、必要に応じ、自動的に、サーバーの稼働時間やネットワークストレージのようなコンピューティング能力を一方的に設定できる。

引用: SP 800-145 NISTによるクラウドコンピューティングの定義(IPA訳文)

上記の特徴のように、組織が必要とするコンピュータリソースを必要に応じてオンデマンドに利用できるようになったクラウド時代、急にトラフィックが増加した場合やコンピュータリソースの不足というのは一定回避や追加を行うことがオンプレ時代に比べ容易になりました。

攻撃に対する防御の視点であっても、サービスを停止させるDoSやDDoSのような攻撃に対して、一定の緩和方法や対策方法が提示されるようになり、サービスを止めないという目的に対して複数の手段を選択できるようになりました。

これによりサービスの提供者としては、サービスの停止による機会損失や信頼の低下などをできる限り低く抑えられるようになったとも言えます。

利便性の一方で気にすることも

一方、オンデマンドで利用できるクラウドだからこそ、制限をかけないかぎり際限なく、そのクラウドのリソースを利用できる利便性からくる欠点も発生するようになりました。

冒頭で述べた事案のように、従量課金のサービスは利用されることにより、都度顧客に利用料を請求します。つまり、悪意のあるなしに関係なく、特定のサービスを利用するたびに発生する利用料金が存在し、意図せずともサービスを止めてしまう可能性があります。

EDoSから逸れるのですが、利用料金が過剰に発生したことによりサービスが停止、いや企業自体が破産しかけた事例を一つリンクとして貼っておきますのでもしよければ皆さんも読んでみてください。この事例からの学びとして、サービスの料金体系の確認とその料金体系の切り替えタイミングについてや、通知やモニタリングの重要性について学べるでしょう。

閑話休題、ここからはEDoSについて話していきましょう。

金銭的にサービスを止めるEDoSとは?

先にも記述したように、クラウドサービスをはじめとした従量課金制のサービスは利用するたびに課金され、その実績に合わせて請求がなされます。

最悪のケースを考えると、この課金体系を利用した攻撃はサービスを提供する事業者が破産や数ヶ月の事業停止になるほどのインパクトを持っています。

この章ではAWSの課金体系をもとにしながら、このEDoSについて考えていきましょう。

本稿の課金額計算の例題として利用するサービスは Amazon S3AWS LambdaAmazon Cognito User Poolになります。まずはこれらサービスの課金体系や各種Quotasの復習、どのような時にEDoSが発生しうるのかという観点の順でお話ししていきます。

本章の構成 本章では、下記のような流れで各サービスごとに情報をまとめていきたいと思います。

  • 料金体系
    • 本稿の解説で利用するサービスの料金体系においてEDoSに関わる可能性のある箇所に絞り解説を行います。
  • サービスクォータ
    • 本稿の解説で利用するサービスのサービス上限において、料金と同様にEDoSに関わる可能性のある箇所に絞り解説を行います。
  • どのような時にEDoSが起こるのか?
    • 実際にEDoSが起こるとして、どのような場面で発生しうるのかについて解説を行います。
  • 固有の対策
    • 該当サービスにおいてどのような対策を行うべきなのかについて解説を行います。

また、料金体系およびドル円相場2に関しては執筆時の2022年9月2日時点でのものを利用しておりますのでご了承ください。

Amazon S3

まずは、AWSを触っている人ならお馴染みのオブジェクトストレージサービスのAmazon S3から見ていきましょう。

料金体系

料金 - Amazon S3 |AWS

Amazon S3課金要素は大別して6つになります。

  • ストレージ(保存に関わる課金)
  • リクエストとデータ取り出し(リクエスト回数とデータの取り出しに係る課金)
  • データ転送
  • 管理と分析
  • レプリケーション
  • S3 Object Lambda

今回主に触れるのは3つで、ストレージ、リクエスト、データ転送になります。また料金体系の復習に際しては、S3 標準3 のBucketを、リージョンはアジアパシフィックの東京を元に解説を進めていきたいと思います。

まずはストレージの課金体系から見ていきましょう。

保管データ容量 料金
50 TB/月 0.025USD/GB
450 TB/月 0.024USD/GB
500 TB/月以上 0.023USD/GB

S3バケットで保管するデータの総量で料金が変わっていきます。データの量が増えるほどGBあたりの料金が下がるのが特徴的です。

次にリクエストの課金体系を見ていきましょう。

課金項目 料金
PUT、COPY、POST、LIST リクエスト (1,000 リクエストあたり) 0.0047USD
GET、SELECT、他のすべてのリクエスト (1,000 リクエストあたり) 0.00037USD

リクエストに関しては1000リクエストあたりでの課金となり、リクエストの回数が増えても料金に変動はありません。ただし、GETの場合は転送データの料金も加算されるため、その点は確認が必須です。

最後にデータ転送の課金体系についてみていきましょう。

インターネット上からAmazon S3へのデータ転送受信は一律0USD/GBであり、一切課金がされません。ただ、これとは逆にS3からインターネットへのデータ転送は料金が発生します。

転送データ量 料金
10 TB/月 0.114USD/GB
40 TB/月 0.089USD/GB
100 TB/月 0.086USD/GB
150 TB/月以上 0.084USD/GB

こちらもデータ保管時の課金と同様に転送データの総量が増えることで料金が減少する傾向にあります。また、AWS内でのデータ転送に関する料金体系などがありますが、今回は割愛します。

サービスクォータ

Amazon Simple Storage Service エンドポイントとクォータ - AWS 全般のリファレンス

S3のファイルのアップロードに関しては、サービスクォータが設定されており、5TBを超えるサイズのファイルは送信することができません。また、このファイルアップロードのサイズに関しては上限を変更することができず、どのようなユーザーであってもS3の標準バケットを利用する上ではこのサイズが上限となります。

S3のリクエストに関しては、特にクォータが設定されていません。

どのような時にEDoSが起こるのか?

料金体系やクォータをもとに、どのような時に過剰な課金を引き起こせるのか考えていきましょう。

まずは、攻撃者の視点に立ってどのようにすれば攻撃ができるか読者のみなさんも考えてみてください。

上記項目の振り返り

  1. 料金体系
    1. バケットに保存されるデータの総量で料金が発生する
    2. 1000リクエストごとに一定額の課金が発生する
    3. インターネット経由でのデータの取り出しにより料金が発生する
  2. クォータ
    1. アップロードできるファイルの最大サイズは5TB
    2. それ以外には料金体系に関わるクォータは現時点では存在しない

攻撃者の見る観点としては3つで、「月の保存データの総量」「月のリクエストの回数」「月のデータ転送量」になります。

まず「月の保存データの総量」から見ていきましょう。 攻撃者としては、いかにS3バケットに効率良くデータをアップロードすることができるかを見ており、保存される量が多ければ多いほど標的としたクラウドサービスの利用者に利用料金の負担をかけることができます。

例えば攻撃者が500TBのデータをS3に保存していたとします。このデータの保存量の場合、料金としては500TB* 0.023USD/GB = 11,500USD(1,610,000円/月)となります。

※ 計算の単純化のために、1TBを1000GBとします

攻撃の例: 月の保存データの総量を増加させる

不正に引き上げられた料金として、150万円を超える金額を請求されてしまうと、企業の体力によって異なる部分もありますが事業を展開する上で一定の打撃を与えるには十分な金額でしょう。

次に「月のリクエストの回数」を見ていきましょう。 攻撃者としては、この観点はどのくらいリクエスト数を増やせるかという点を見ています。

S3のリクエストに対する課金としては、一定リクエスト数に対して料金が発生する料金体系をしており、単価の高いPUTでは、1000リクエストに対して、0.0047USDが発生します。例として10,000,000回リクエストを行った場合の料金を出してみましょう。10,000,000リクエスト / 1,000(課金単位) * 0.0047USDなので 47USD(6,580円)となります。

攻撃の例: 大量アクセスによるリクエスト単位の課金金額増加

確かに料金自体は発生しますが、この観点でEDoSを引き起こそうとすると、尋常ならない回数のリクエストを必要とするため攻撃者にとってある一定の労力を必要とし、データの保管や取得に比べると大きく金額を上げる要素にはなりえません。

最後に「月のデータ転送量」を見ていきましょう。 攻撃者としては、いかに大きなサイズのデータをインターネット経由で取得できるかを見ており、その総量を効率良く上げることが攻撃者にとっての関心事となります。

もし攻撃者がこの観点を利用しEDoS攻撃を利用したとして、月の最大料金テーブルとなる転送量の150TBを取得したとします。この場合、150TB* 0.084USD/GB = 12,600USD (1,764,000円)となります。

※ 計算の単純化のために、1TBを1000GBとします

攻撃の例: 累積のデータの転送量による課金金額の増加

上記の観点を基に攻撃者がどのようなEDoS攻撃をおこなってくるか考えてみましょう。 1つとしては、S3バケットへの大量ファイルアップロードで料金を増加させることが考えられます。2つ目として、既存の大きめのファイルをCDNを介さずに断続的または、多くの端末から取得することにより、大量のデータ取得を行い料金を増加させることも考えられます。

固有の対策

上記の攻撃にいかにして対応するかについて見ていきましょう。

ファイルアップロードにおける対策

攻撃者はS3のようなオブジェクトストレージに対してより大きなサイズのファイルをアップロードができるかを考えています。そのような脅威に対して下記のような対策が考えられます。

  • 署名付きURLのcontent-length-rangeを用いたサイズ制限ありのアップロード
  • S3のトリガーによるサイズの検証

署名付きURLのcontent-length-rangeを用いたサイズ制限ありのアップロードは読んで字の如く、S3へのアップロードを行う際に署名付きURLのPOSTポリシーを用いて、ファイルサイズの制限を行うことが可能で、EC2やLambdaなどを介さずにファイルの検証をS3側で行ってくれます。

S3のトリガーによるサイズの検証は、特定のPrefixに対してファイルに変更や追加があった際に、Lambdaを用いてファイルサイズを確認する方法で、POSTで署名付きURLを何らかの事情で利用できない際に使用する対策です。

この対策方法を用いる場合、S3へのアップロード後の動作になるので、アップロード自体の阻止を行うことはできないので注意してください。また、サービスの特性によってアップロードが頻繁に行われることから、ボトルネックになる恐れもありますので、その点も留意して利用してください。

ファイル取得における対策

アップロードと対として存在するファイルの取得ですが、攻撃者がアップロードせずともサービス提供者が大きなファイルをホストしている場合に、攻撃者が幾度も取得を行うことで、攻撃が成立してしまう恐れがあります。そのような脅威に対して下記のような対策が考えられます。

  • 大きなサイズのファイル配信を行う場合のCDNの利用
  • ファイルのダウンロード回数制限

CDN(Contents Delivery Network)を用いることで、ファイルのキャッシュが可能になり、S3に対して直接のリクエストを低減させることが可能です。

しかし、個人情報等の機微な情報が含まれるファイルやキャッシュを望まないファイルに関してはCDNを利用した対策は行えません。そのような場合は、短時間でのファイルのダウンロード回数を制限をするなどの対策を行ってください。

その他

各種直接的な対策以外に、監視やメトリクスの取得などを行い、不自然なリクエストの情報収集や、検知のためのルールを設定し、検知した際に通知を送るようにすることもお勧めします。

AWS Lambda

Lambdaは、AWSの提供するコンピューティングリソースで、FaaSというサービス形態で別のリソースによって発生したイベントに対して駆動しコードを実行するサービスです。類似サービスとして、Google Cloud Functions や Azure Functionsなどが存在します。

料金体系

料金 - AWS Lambda |AWS

主にLambdaの料金に関わる要素として、利用アーキテクチャ、リクエスト数、実行秒数、マシンスペックが存在します。今回の解説では x86 のLambdaを利用すると仮定し解説していきます。また、Lambda@edgeやProvisioned Concurrencyには触れないのでその点ご了承ください。

はじめにリクエストあたりに関する料金体系ですが、リクエストは100 万件あたり 0.20USDで特に上下するものではありません。

次にマシンスペックと実行秒数についてです。Lambdaではメモリに対してms単位で課金が発生します。

メモリ (MB) msあたり
128 0.0000000021USD
512 0.0000000083USD
1,024 0.0000000167USD
1,536 0.0000000250USD
2,048 0.0000000333USD
3,072 0.0000000500USD
4,096 0.0000000667USD
5,120 0.0000000833USD
6,144 0.0000001000USD
7,168 0.0000001167USD
8,192 0.0000001333USD
9,216 0.0000001500USD
10,240 0.0000001667USD

サービスクォータ

Lambda クォータ - AWS Lambda AWS Lambda エンドポイントとクォータ - AWS 全般のリファレンス

続いて、サービスクォータです。 料金体系に関わるものとして、実行時間と同時実行数が存在しており、このクォータに焦点を当てて見ていきます。

まずは、実行時間についてです。クォータの上限として最大時間は15分で設定可能で、デフォルトの実行時間の状態で利用している場合は3秒で打ち切られます。

次に、同時実行数についてです。クォータの上限としてはリージョンごとに異なりますが、ap-northeast-1(東京)ではアカウントに対して1000がクォータとして設定されています。

どのような時にEDoSが起こるのか?

Lambdaはイベントの処理が完了しない場合、Lambda関数を自動でスケールさせ、同時実行を行います。LambdaでEDoSを引き起こすためには、実行時間を伸ばし、同時に複数のリクエストを行うことで、Lambda関数の実行台数を増やすことが有効と言えます。

このことから2つの方法でEDoSを引き起こすことが可能です。1つは、継続的にLambdaを実行させることによる実行時間の累積、1つはLambdaで実行されるアプリケーションの処理を長時間行わせるというものです。

1つ目の継続的にLambdaを実行させることによる実行時間の累積は、攻撃としては読んで字の如く実行時間を累積することにより実行時間を増加させるものです。

例えば、 APIを実装する際に用いられる、API GatewayとLambdaの組み合わせやS3のイベントに連携されたLambdaなどのような構成において、攻撃者が継続的にアクセスを行ったり断続的なアップロードを行うことでLambdaを常に実行させる状態を作り出すことができます。

構成例: Amazon Web Service Japan - 形で考えるサーバーレス設計 動的 Web / モバイルバックエンド

構成例: Amazon Web Service Japan - 形で考えるサーバーレス設計 画像処理 / シンプルなデータ加工

攻撃の例: 大量アクセスによる累積実行時間の増加

2つ目のLambdaで実行されるアプリケーションの処理の長時間実行は、本来のアプリケーションの動作内でSleepなどを用いてアプリケーションの処理を停止させたり、時間のかかる処理を行わせる必要があります。

例えばOS Command injectionやSSTIなどを用いsleep コマンドや言語における待機を行う関数をLambda上で実行することで、長時間Lambdaを実行することが可能です。ただし、Lambda上でOS Command injection 等の脆弱性がある場合、別の攻撃を受ける可能性があるのでEDoS以外にも目を向ける必要があるでしょう。4

攻撃の例: 脆弱性を用いた実行時間の増加

他には正規表現の処理を悪用し、過剰な処理を行わせる攻撃であるReDoS5を用いることでもLambdaを長時間実行することが可能です。

これらの上記2つの方法で実行時間を増やすことが可能ですが、Lambdaにおいては実行時間の制約もあり、デフォルトでの実行時間が3秒と短いことや、サービスの提供者が任意の実行時間に制限を行うことが可能であることから、Lambdaを用いているサービスが一概に、上記の方法でEDoSが実施できるわけではないことも事実です。

固有の対策

攻撃の最後でも述べましたが、シンプルなコードを実行することで実行時間を短くすることが可能であると考えます。他にも下記のような対策を施すことでより安全な実行ができると考えています。

  • 実行時間を無闇に青天井に設定しない
  • 過剰なメモリを設定しない
    • 実行時間が不確定な場合は、できる限り小さく処理を行う方法がないか模索をしてください
  • アクセスに関するログを取得し、継続的にモニタリングを行い以上な傾向をルール化する
    • 同一IPへの断続的なアクセス
    • 同一エンドポイントへの断続的なアクセス
    • 不自然なサイズのリクエスト

Amazon Cognito User Pool

Cognito User Poolはウェブやモバイルのアプリケーションのユーザーへのサインインおよびサインアップ機能などの認証における機能を提供するクラウドサービスです。類似のサービスとしてAzure AD B2Cや、Firebase Authenticationなどが存在します。

料金体系

料金 - Amazon Cognito | AWS

Cognitoは月次のアクティブユーザー(MAU)6単位で料金が加算されます。

このMAUは2つのタイプに分かれ、1つはCognito User Poolの認証情報やソーシャルID プロバイダで直接サインインするタイプのユーザー、もう1つはSAMLやOIDCなどを用いてフェデレーションされるユーザーです。

前者のUser Poolの認証情報、またはソーシャル ID プロバイダーで直接サインインするユーザーは、サインアップ時点からMAUに加算され下記の料金体系で課金がなされます。

MAU MAUあたりの料金
~ 100,000 0.0055USD
90万 0.0046USD
900万 0.00325USD
1,000万超 0.0025USD

また、このMAUは削除を行なっても無効化されずそのままMAUとして換算されます。

一方、SAML または OIDC フェデレーションを使用してサインインするユーザーに関しては一律で MAUあたり0.015USDの料金が加算されます。

※ただし、無料枠が存在する場合、50MAUが無料で提供されます。

また、Advanced Security 機能を利用している場合、下記のような料金体系で課金されます。

MAU MAUあたりの料金
~ 50,000 0.050USD
50,000 0.035USD
90万 0.020USD
900万 0.015USD
1,000万超 0.010USD

サービスクォータ

Amazon Cognito のクォータ - Amazon Cognito

サインアップに関してサービスクォータが設定されており、デフォルトで1秒あたり50の操作が可能になっています。このクォータは調整可能ではありますが、100万MAUごとに引き上げのリクエストが可能で、それまではデフォルトの設定のままになります。

どのような時にEDoSが起こるのか?

Cognito User Poolは料金において、月間のアクティブユーザー数に対して課金を行います。このアクティブユーザーの判定として、新規登録(サインアップ)時点からアクティブなユーザーとして判定することから、攻撃者はこのポイントを目掛けて攻撃を実施する可能性があります。

また、Cognito User Poolにおけるユーザーの登録は自己サインアップを有効化している場合や特に対策を行なっていない場合、極めて小さな労力で重大な被害を引き起こす可能性があります。

また、CognitoにはAdvanced Securityと呼ばれるセキュリティ機能が存在することを料金体系の際に述べましたが、この機能が有効化されている場合、MAUが増えることで更なる料金が加算されることになります。

固有の対策

アカウントの作成において必要なメールアドレスに制約を設けることは有効な対策と言えます。例えば、サインアップ前トリガーにLambda関数を呼び出し、メールアドレスのエイリアスを許可しない処理を記述しバリデーションをかけることやCloudTrailとCloudWatch Logsを用いて特定のドメインのアカウントが短期間に登録された場合にアラートを出したりし、検知や対策の自動化を施すこともできます。

reCAPTCHA等を用いた自動化の対策を行うことも有効的です。Cognito User Poolには、signupの前にpre-signupと呼ばれるトリガーがあるのでvalidationDataとしてrecaptchaTokenを送信することにより、自動化された大量なユーザー作成を防ぐことが可能です。

また、CloudTrailのLogをCloud Watch Logsなどを用いて監視し、不審な振る舞いをするIPへのルールを設定、AWS WAFを用いてIPの制限を実施するなどのセキュリティオートメーションの実施も可能です。

対策についてのまとめ

上記で例として挙げた各サービスでは個々のサービス固有の対策について触れてきましたが、ここからは一歩引いてどのようなサービスでも対応できるような普遍的な対策に触れていきたいと思います。

請求に関する通知

EDoSの特徴として、課金が発生することで経済的に事業運営ができなくなるというものがありました。これらへの対策としては、請求に関するAlertを設定することで、利用者(サービス提供者)が気づけるようにすることが有効です。 ただし、しきい値の取得タイミング次第では攻撃の停止は間に合わない可能性があるため、「気づく」ために設定するものであると考えた方が良いでしょう。

全ての対策において言えることですが、“これだけ”すれば安心というわけではないので、他の対策と併せて行い、一つもれても次にと多層防御的に対策をおこなってください。

料金項目に関連する値のモニタリング

障害対応やボトルネック解消のためにモニタリングやログの収集を行うケースがありますが、EDoSでもモニタリングを行うことは重要な対策であると考えています。

料金増加の起因になる項目を適切にモニタリングすることで、その値が異常値になった場合は管理者に適切に通知を行ったり、自動で対策を行うことも可能になるので実施を行うことを推奨します。

対策例

実行時間の制限

Lambdaをはじめとして、実行時間に対して課金が発生するようなサービスに対しては実行時間の制限をかけることにより、料金の増大を防ぐことが可能になります。ただし、実行時間を極端に抑制することはサービスの特性次第ではサービスの停止や障害につながる恐れもあるので、その点に留意して設定をおこなってください。

対策例

  • LambdaのTime out時間の設定

実行台数の制限

多くのアクセスに対応するためにコンピュータリソースをスケーリングし、可用性を高めるための構成が多々あります。このスケーリングに関しても、実行可能台数の制限や短時間に大きくスケールした場合にAlertなどを通知する設定が重要です。

対策例

  • 想定できる最大値を上限値に設定する
  • またはモニタリングをベースに連続時間、大規模なスケールやアクセスが続くようならAlertを通知する

サイズの制限

保存されたファイルの保管や取り出したファイルのサイズにより課金が行われるサービスに関しては、サイズの上限を設定する必要があります。

例として、S3の料金体系において、オブジェクトのサイズに起因して発生する脅威についておさらいしていきましょう。

S3においては、オブジェクトのサイズによって料金が発生します。 一つは、データ保管で、これはアップロードされたオブジェクトのサイズが直接的に課金に反映されます。 もう一つは、オブジェクトのデータ転送の下り(ダウンロード)で、これはファイル取得の際に課金が反映されます。

S3を用いてアップロードとダウンロード機能を有するアプリケーションの機能を実装する場合、巨大なファイルをアップロードされた時にまず保管するだけで課金が大きく発生しますし、その巨大なファイルを複数回ダウンロードされることにより課金が大量に発生するので注意が必要です。

対策例

  • CDNを用いてデータ転送の必要な巨大なファイルに関してはキャッシュを行う
  • キャッシュの行えないファイルであればモニタリングを元に、不自然に増加するリクエストを検知する
  • アップロードを行う際は必ずサイズを確認する
    • Lambda Hookなどを用いてサイズの制限を行うなどもできる
  • もしくはアップロードを行う際に利用する署名URLのpolicy_documentを指定することで対策が行える

回数の制限

DoSやDDoS対策でも同様ですが過剰なリクエストに対しては回数制限を設けることによって対策を行えます。Cognitoなどは、利用するユーザーに対して課金が発生する関係上、無数のリクエストでユーザーを作成されることにより過剰な課金が発生する可能性があるので注意が必要です。

対策例

  • WAFやCDNなどによってアクセスの回数や同一のIPからの対策を行う
  • 不審なリクエストの検知を行う

自動化対策

攻撃者もプログラマーもできる限り自動化したいという気持ちはおなじで、攻撃者も攻撃を自動化を行い攻撃してきます。この攻撃の自動化に対してはreCAPTCHAなどを導入し、自動化の難易度を上げることが対策になります。

対策例

  • Cognitoのpre-signupトリガーを用いたreCAPTCHAの検証

総括

AWSやGCP、Azureのようなサービスのインフラとして、クラウドが一般的に活用されるようになり、無尽蔵なコンピュータリソースを誰しもが利用できるようになりました。これらクラウドと呼ばれるものは、利用した分を料金として支払う従量課金と呼ばれる料金体系を採用しています。

オンプレミスの時代はコンピュータリソースが物理的な制約となっていましたが、その制限がなくなり、誰しもが強力なマシンを利用しサービスを提供できるようになりました。

そのような時代背景の中、攻撃者はリソースの利用に対して従量課金の料金方式を取るクラウドサービスの仕組みを悪用し、意図的にリソースを大量利用しクラウドサービス利用者に金銭的負担をかけさせることも可能になりました。

この金銭的負担は場合によってはサービスの継続が数ヶ月以上、もしくはサービスそのものの継続が困難になりうる打撃を受ける可能性も十分に秘めており、サービスの提供者にとって大変脅威度の高いものになりつつあると私は感じています。

これらEDoSと呼ばれる脅威に対しての対策としては、少し抽象的な表現になりますが制限をかけることが過剰課金の抑制になります。しかし、その制限はプロダクトにおいて場合によってはボトルネックとなり障害を引き起こす可能性も一緒に抱えている代物です。

このような対策において一定の指標として、最大値が明確な場合は、その値を上限の値にする、万が一最大値が明確でない場合は、甘めの見積もりでもいいので上限値を設定するなどをあらかじめ要件として定義しておくとよいでしょう。

また、Logやメトリクスをモニタリングすることも重要であり、異常値や大量なアクセスを検知することにより、攻撃の抑制につなげることも可能になります。

そして、対策に関しては一つの対策だけではなく、多層防御的な観点から「もし回避されたら」の思考で、複数の対策を施す必要性がますます増しています。

もちろんIAMをはじめとした認証情報やサービスで利用されているミドルウェアの既知の脆弱性のアップデートなども大事ではあるものの、事業を継続する上で手持ちの資金はとてつもなく大事です。このお金という観点で事業に打撃を与える攻撃の存在についてブログを読んだ皆様が自らの職場などに持ち帰り、議論してほしいとお伝えして本稿のむすびとさせていただきます。

ご拝読いただきありがとうございました。

さいごに

Flatt Security では AWS・GCP・Azure診断Firebase診断 | Flatt Securityというサービスにおいて、クラウドサービスの設定不備のみを確認する一般的なクラウドセキュリティ診断だけでなく、アプリケーションの仕様やお客様のクラウドセキュリティに対する懸念事項などを踏まえ、クラウドとアプリケーションを総合的に診断するメニューも提供しています。

もし本稿を読み、少しセキュリティの専門家に相談をしたいという方はご連絡いただければ幸いです。

また、Flatt Security では一緒に働く仲間を募集しています。本稿のようなクラウドセキュリティに関わる業務や脆弱性診断、セキュリティプロダクトの開発に興味のある方は採用情報 をご確認ください!

参考資料


  1. piyokango氏のハッカー志望の男が起こした大量の虚偽申請による業務妨害事案についてまとめてみた - piyolog を読んでいただけるとより詳しい内容が把握できるかと思います。

  2. 2022/09/02 09:00 時点でのドル円相場は140.0円(小数第一位以下の切り捨て)

  3. S3 標準 - 頻繁にアクセスするデータに一般的に使用される、あらゆるタイプのデータの汎用ストレージのことを指します。

  4. Lambdaにおいてきにすべき脆弱性への攻撃については弊社森岡が執筆した サーバーレスのセキュリティリスク - AWS Lambdaにおける脆弱性攻撃と対策 - Flatt Security Blogをご覧ください。

  5. ReDoSに関しては A Rough Idea of Blind Regular Expression Injection Attack – やっていく気持ち やyamoryのその正規表現の書き方で大丈夫? ReDoS 攻撃の怖さと対策方法 | yamory Blogをご覧いただければわかりやすいかと思います。

  6. 暦月内に、サインアップ、サインイン、トークンの更新、パスワード変更、ユーザーアカウント属性の更新など、ユーザーに関連した ID オペレーションがある場合、そのユーザーは MAU としてカウントされます。Amazon Cognito のクォータ #月次のアクティブユーザー (MAU)- Amazon Cognito