Capital Oneデータ漏洩経路の考察
2019年8月に発生した Capital Oneのデータ漏洩事件に関する各種報道等の情報からそのデータ漏洩経路を考察する。FBIの起訴状、CapitalOneの公式発表のほか、インターネット上で報道されている各種情報から考察をしており、内容には推測も含まれる。
なお本考察は個人的な調査に基づくものであり、いかなる公式発表でもなく、技術的な観点から事象や対策について検討したものである。
漏洩したデータ
S3バケットに保存されていたデータが漏洩した。また非公式な情報では、Twitterで犯行を告知しているメッセージから読み取るに、EBS Volume Snapshotも漏洩した可能性がある。
また漏洩したファイルのリストは、非公式情報ではあるが下記であるといわれている。
主な漏洩の流れ
構成ミスがあったWAF (Reverse Proxyとも)を利用され、その後にS3バケット内にあったデータなどが漏洩した。
WAF EC2インスタンスのインスタンスプロファイルの権限により、これらのデータにアクセス可能であったことが原因とされる。データにアクセスし、その後S3間のコピー等によって、外部へデータが漏洩した。
IaaSとしてCapitalOneが構築したEC2インスタンスのミスコンフィグレーションが大きな要因となっている。
侵入に関する考察
今回のデータ漏洩については、WAFとして存在したEC2インスタンスからIAMロールに必要以上の権限が付与されていたために起こったと考えられる。
1. WAFのミスコンフィグレーション
第一に、WAFのミスコンフィグレーションにより、リンクローカルアドレスへのリクエスト転送が可能になっていた可能性がもっとも高いと推測される。AWSにおけるインスタンスメタデータへのアクセスは 169.254.169.254 で可能である。
クエリパラメータやその他の方法により、WAFが受け付けたリクエストのフォワーディング先として、リンクローカルアドレスを選択してしまい、そのリンクローカルアドレスからのレスポンス(インスタンスメタデータ)を、攻撃者に返してしまったと考えられる。
インスタンスメタデータにアクセス可能な場合、EC2インスタンスに割り当てられているインスタンスプロファイルを通じて、IAMロールの一時的セキュリティクレデンシャルが取得可能である。
> http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]
{
"Code" : "Success",
"LastUpdated" : "2019-08-05T00:00:00Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "[AccessKey]",
"SecretAccessKey" : "[AccessSecret]",
"Token" : "[AccessToken]",
"Expiration" : "2019-08-05T00:00:00Z"
}また、一時的セキュリティクレデンシャルの取得に必要なIAMロール名も同様に取得可能である。
http://169.254.169.254/latest/meta-data/iam/security-credentials/これらのインスタンスメタデータはAWSだけでなく、ほかのパブリッククラウドでも内容の差はあるが、同じように存在している。
ここで取得した一時的セキュリティクレデンシャルを使いAWS APIを呼び出すことで、IAMロールの権限を使ってアクセスが可能になる。
リンクローカルアドレスへクエリを転送できてしまったことによって、このIAMロール権限を奪われてしまい、結果的に正規のIAMロール権限で攻撃者がリソースにアクセス可能となったと考えられる。
[インスタンスメタデータに関する記事]
- https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html
- https://blog.ssrf.in/post/example-of-attack-on-gce-and-gke-instance-using-ssrf-vulnerability/
2. IAMロール権限の問題
今回データが漏洩する最大の要因は、EC2に割り当てられていたIAMロール権限が非常に強力だったことである。
EC2インスタンスにどのような機能を持たせていたかは不明ではあるが、通常考えられる必要最低限な権限とはいえない権限がIAMロールに付与されていたようである。通信を検査およびリレーするだけのインスタンスが、S3をはじめとする各種リソースにアクセスする必要はなかった、もしくは無いようにすべきものであった。
構成としては、WAFで検知をした不正なアクセス等に対して、動的なアクションによって防御アクションをプラットフォームに対して行うようなことをしていた可能性もあるが、今回のようにひとたび侵入を許すとその権限が悪用可能になる可能性があり、適切ではなかったといえる。動的なアクションを行うのではあれば、WAFで検知した情報をもとに内部のほかのサービスに情報を連携し、そこでアクションを行うなどの構成を取っていれば、被害の拡大を防げた可能性はある。
3. リソースポリシーの課題
正規のIAMロール権限を奪われてしまったため、S3バケットをはじめとする各種リソースに対してアクセスを許す結果となった。正規の権限を奪われたため、さまざまな方法でリソースにアクセス可能であったはずではあるが、今回明らかになっている攻撃者の手法としては、S3バケット間コピーを利用して主要なデータを漏洩させたようである。
IAMロール権限によりS3バケットおよびオブジェクトへのアクセス権限を得たため、ソースデータへの正規権限でのアクセスが可能であった。このデータを持ち出すには、コピー先のS3バケットにも権限を持つ必要があるが、あらかじめパブリックアクセス可能なS3バケットを用意し、どのようなユーザーでも書き込みができる権限を付与することによって、書き込みが可能になる。
またS3バケット内に存在したデータだけではなく、EBSボリュームのスナップショットを取得し、Storage Gatewayを経由してS3にボリュームデータをコピーし、データをS3バケットからさらに取得した可能性がある。WAF EC2インスタンスを経由してのデータ漏洩も可能であったと考えられるが、データ転送の容易さを考えたのか、コンソールログインの検知を警戒したのかは不明ではあるが、今回のケースにおいてはS3オブジェクトをバケット間コピーする手法が多く使われているようである。
S3バケット内に存在したデータについては、S3バケットのリソースポリシーをより厳格に制限を行い、特定のVPC/VPCエンドポイントからのアクセスにオブジェクト読み取りを制限することで、オブジェクトのコピーを防げた可能性がある。しかしながら同時にIAMロールの権限によっては、S3バケットポリシーの書き換えが可能であった可能性もあり、特定のVPCからのみオブジェクトアクセスを制限することで、データ漏洩を防げたとは言い切れない。同様にS3 Public Access Blockも、正規のIAMロールによるアクセスであったため、対策として寄与しなかったと考えられる。
4. リソースの追加
データの漏洩という場合、既存のリソースが侵害されるということを考えがちであるが、仮想化された環境においては新しいリソースを追加される、という手段にも考慮する必要がある。
今回の件においては、新しいEC2インスタンスの作成、またStorage Gatewayの作成がIAMロール権限によって行われた可能性がある。停止しているEC2インスタンスの起動や、セキュリティグループの付け替えといった操作により、保護されていたリソースがアクセス可能な構成に変更される、といったこともありえる。
5. KMSキーと暗号化
今回のデータ漏洩にあたって、KMSキーと暗号化が役に立ったかどうかという点については、正規のIAMロール権限が利用されているため、対策として寄与しなかった。
S3オブジェクトにアクセスする権限および必要があったと想定した場合、S3オブジェクトにアクセスするためのKMSキーにもアクセスする必要があり、IAMロールにもKMSキーへのアクセス権限があったと考えるのが妥当である。
KMSキーへのアクセス権限がIAMロールにあれば、S3オブジェクトのアクセス時にKMSを使ってデータの復号化が当然行われるため、オブジェクトが暗号化されているかどうかに関係なく、アクセスが可能である。
IAMロール権限が利用可能であったということから、KMSキーの種別によらず (KMS-CMK, Imported Key Material - BYOK, Custom Key Store - CloudHSMであっても)、今回の攻撃に対する防御策としてKMSが関与するポイントはない。
取りうる防御策
今回のデータ漏洩と同様の攻撃に関して、とりうる防御策をいくつか列挙する。適切な権限を付与するといった以外は副作用を伴う対策も多く、画一的な対策ではなく個々に適切な対策を選択して採用することが必要である。
A. IAMロール権限を限定する
EC2インスタンスプロファイルに付与するIAMロール権限は必要最小限の権限のみとする。またPermission Boundaryを利用し、意図しない権限拡大を制約することも効果的である。
今回奪取されたIAMロールは非常に強い権限を持っていたと想像され、そのようなIAMロールをEC2インスタンスプロファイルに設定することは非常に危険である。
B. OrganizationsによりService Control Policy経由の制約を設定する
AWS Organizationsで管理されている各AWSアカウントについて、SCPを使ってアクセス可能な条件に制約をかけることが有益なケースがありうる。
IAMに関する変更権限をSCPによって特定のIAMロールに制限する、EBS Volume Snapshotを実行するIAMロールをSCPにより限定する、S3 BucketPolicyの変更をCloudFormation等のオートメーションに限定する、といった緩和策が考えられる。
Organizations SCP による Principal 制限拡張は2019年3月に実装
C. リソースへのアクセスをVPC Endpointに制限する
S3バケットやRDSなどのアクセスを、VPC Endpoint経由に制限をするリソースポリシーを設定する。VPC Endpoint経由でのみデータにアクセスできるようリソースポリシーを制限することにより、IAMロール権限を奪われた際も、EC2インスタンス内部にログインしない限り、操作が難しい状況を作ることが可能である。
S3であれば、バケットオペレーションは CloudFormation や AWS Management Console からの操作もできるようにしつつ、オブジェクトオペレーションのみは VPC Endpoint に制限する、などといったポリシー構成も有益であると考えられる。
D. インスタンスメタデータへのアクセスを制限する
インスタンスメタデータのエンドポイントである 169.254.196.254 へのアクセスを、ホスト内のアクセスポリシーにより制限することによって、一時的セキュリティクレデンシャルの取得を防ぐことができる。
WindowsであればWindows Defender Firewallにおいて、Linuxであればiptablesなどでリンクローカルアドレス向けの送信トラフィックをフィルタすることで、アクセスを遮断することができる。
ただしインスタンスメタデータへのアクセスを制限すると、EC2インスタンスプロファイルによるリソースアクセスができなくなることに注意が必要である。AWS CLIはもちろんのこと、各種のリソースアクセス等も制限されるため、極めて限定的な施策とすべき手法である。
ホスト内のアクセス制限の設定を細かく制御し、特定のOSユーザーのみインスタンスプロファイルへアクセス可能とすることで制限を緩和することは可能であるが、cloud-initのような起動時の自動処理のためにrootユーザーがインスタンスプロファイルを利用できる必要がある。また不正アクセスを防ぎたいサービスがインスタンスプロファイルによるリソースアクセスが必要な場合に、そのサービスの実行ユーザーにインスタンスメタデータエンドポイントへアクセス許可を行った場合は、そのサービスを乗っ取ることができた攻撃者はインスタンスメタデータにもアクセスでき、完全な対策とはなりえない。
またAWS Secret Managerといったセキュリティクレデンシャルを可能するサービスについても、そのサービスにアクセスするための権限は必要であり、インスタンスメタデータエンドポイントへのアクセスを完全に遮断することは困難である。
なお 169.254.169.123 はAWS内部の時刻同期サービスのエンドポイントとして利用されているなど、リンクローカルアドレスへのアクセス制限を行う際においても、適切なエンドポイントのみ制限する必要がある。
基本的にはインスタンスメタデータへのアクセスを制限することによって防ぐべき問題ではないことを改めて認識する必要がある。
E. その他のクレデンシャル
インスタンスプロファイルを使わず、アクセスキーをほかの方法でEC2インスタンス内に保管、環境変数への登録などは、インスタンスプロファイルよりもより危険性が増すため、そのような手段を対策とすべきではない。
F. マネージドサービスの利用
IaaSインスタンスとして構築したEC2インスタンスのWAFが今回の侵入口であった。AWSが提供するWAFを利用することで、このような致命的なミスコンフィグレーションを防げた可能性がある、しかしながら、カスタムルールが利用できるようになったのは近年であり、構築当時のベストプラクティスと現在のベストプラクティスが異なっていた可能性もあり、一概に原因といえるわけではない。
またModSecurityによるWAFが構成されていたとされており、クラウドに限らずオンプレミスでも同様の問題は起こるため、クラウド固有の問題というわけではない。
マネージドサービスを利用せずIaaSインスタンスを構築する場合には、責任共有モデルのなかで自らが果たすべき役割を常に注意すべきである。
G. 新しい脅威
今回利用されなかった手法の一つに、AWS Systems Manager経由のインスタンスアクセスがある。Systems Managerを経由してEC2インスタンスのコンソールへのアクセス、SSHアクセスを可能とする機能がある。このような機能は便利ではあるが、インスタンスプロファイルとして権限が与えられるべきではない。IAMポリシー/Permission BoundaryおよびSCPなどを利用して、特定のIAMロールのみに権限が付与されるように制限すべきである。
まとめ
今回のデータ漏洩は、主に2つの要因が大きい。まずひとつにWAF (Reverse Proxy)として利用していたEC2インスタンスから、リンクローカルアドレスへアクセス可能な構成になっていたこと。次にそのEC2インスタンスが持っていたIAMロールの権限が非常に強力だったこと。この組み合わせによってシステム内部に深く侵入を許すことになった。
これらの事象は、クラウドだから起こったことと考えることはミスリーディングを起こしかねない。オンプレミス環境であっても、Reverse ProxyのミスコンフィグレーションによりVMwareコンソール等へのアクセスが可能になる、稼働しているインスタンスの環境変数にアプリの認証情報が登録されていてその認証情報で接続されてしまう、などといったことは容易にありうる。
報道にあるような”元AWS社員”といったラベリングや(実際は2015年-2016年の1年余りの勤務、数年前に退社している。CapitalOneの案件に直積関係したかは不明)、クラウドサービスから漏洩というタイトルだけで、本当に考慮すべきリスクから目を背けないようにすべきであると考えられる。おそらく今回のデータ漏洩に関しては内部情報は必要なかったと考えられる。
クラウド環境に限らずシステムを守っていくため、最小権限の法則と、EC2インスタンスプロファイルも含めたIdentityの確実な保護を、継続的に行っていくことがまず必要である。
