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

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

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

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

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

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

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

免責事項
クラウド時代におけるサービス継続の重要性と停止を狙った攻撃
- クラウドを利用することによる利便性について
- 利便性の一方で気にすることも
金銭的にサービスを止める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 S3 、AWS Lambda、Amazon Cognito User Poolになります。まずはこれらサービスの課金体系や各種Quotasの復習、どのような時にEDoSが発生しうるのかという観点の順でお話ししていきます。

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

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

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

Amazon S3

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

料金体系

料金 - Amazon S3 ｜AWS

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

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

今回主に触れるのは3つで、ストレージ、リクエスト、データ転送になります。また料金体系の復習に際しては、S3 標準³ の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. バケットに保存されるデータの総量で料金が発生する
2. 1000リクエストごとに一定額の課金が発生する
3. インターネット経由でのデータの取り出しにより料金が発生する
クォータ
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