InstanceMetaDataV2を分かりやすく解説してみる

技術三課の杉村です。2019年11月、Amazon EC2のInstance Metadata Service v2(IMDSv2)が発表されました。

セキュリティ強化のためのアプデですが、どうして、どのようにしてセキュリティ強化になるのか、ピンとこない方もいたかもしれません。

当投稿では下記の公式ブログを抄訳して、IMDSv2がどのようにセキュリティ強化につながるのか簡単に解説したいと思います。 Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service

基本的に上記ブログの抄訳（抜粋して訳したもの）ですが、一部補足をしています。

1. ポイント

デフォルトではIMDSv1とIMDSv2の両方が使える状態
- v1を無効化、またはv1とv2の両方を無効化することもできる
IMDSv2ではメタデータへのアクセスの前にセッショントークンを取得する必要がある
セッショントークンの取得はメタデータへのHTTP PUTリクエストで行う
これにより以下の攻撃のリスクを下げられる
- 設定に穴のあるWAF経由での、メタデータを利用した攻撃
- 設定に穴のあるリバースプロキシ経由での、メタデータを利用した攻撃
- SSRF脆弱性を突いた、メタデータを利用した攻撃
- 設定に穴のあるL3ファイアウォール又はNAT経由での、メタデータを利用した攻撃

2. v1とv2はどう違う？

2-1. 従来まで（IMDSv1）

ご存知の通り、インスタンスメタデータはEC2内部から http://169.254.169.254/latest/meta-data/ にHTTPリクエストを送ることで誰でも取得できました。

$ curl http://169.254.169.254/latest/meta-data/instance-id
i-0123*************

それは、IAM RoleのCredentialも簡単に取得できることを意味していました。

$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/your-role-name
{
  "Code" : "Success",
  "LastUpdated" : "2019-11-26T07:27:05Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA****************",
  "SecretAccessKey" : "CCZm＜中略＞3w==",
  "Expiration" : "2019-11-26T13:37:29Z"
}

2-2. これから（IMDSv2）

以下のように、まずセッショントークン（期限付き。パスワードのような扱い）を取得します。PUTリクエストでないとトークン取得できない決まりになっているのがキモです。理由は後述。（1行目: セッショントークンをPUTリクエストで取得して、TOKEN変数に代入）

その次に、curlのGETリクエストでメタデータをリクエストしますが、ヘッダには先ほどのトークンを含ませます。（2行目: -Hオプションでヘッダ指定。先ほどのトークンが入った変数を入れている）

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
curl http://169.254.169.254/latest/meta-data/instance-id -H "X-aws-ec2-metadata-token: $TOKEN"

3. IMDSv2は何が嬉しい？

以下の理由から、IMDSv2のほうがセキュアになります。

3-1. 設定に穴のあるWAF経由での、メタデータを利用した攻撃

WAFの設定が誤っている場合、攻撃者がインスタンスメタデータを悪用できてしまう可能性があります。 ※引用元ブログではそのような設定が誤っているWAFのことをopen WAFsと表現していますが、AWS純正WAFである AWS WAF ではそのようなことは発生しないとのこと。（"open WAFとして振る舞うようには設定できない"）

AWSが3rd Party製のWAFを調査したところでは、設定が誤っているWAFでもPUTリクエストが許可されている可能性は低いとのこと。

そのためメタデータへのアクセスの前段としてPUTリクエストでのトークン取得をマストにすることで、設定ミスのあるWAFを介しても、インスタンスメタデータが悪用される危険性を下げられるという理論でした。

3-2. 設定に穴のあるリバースプロキシ経由での、メタデータを利用した攻撃

WAFと同じく、一般的にはPUTリクエストをそのまま通してしまうようなリバプロはない、とのことです。

またIMDSv2ではX-Forwarded-Forヘッダを含んだリクエストを拒否するようになっています。 X-Forwarded-Forは、リバプロなどを介しても元々の接続元IPアドレスが分かるように、元のリクエスト者のIPアドレスを記録するためのヘッダです。リバプロを介した場合、X-Forwarded-Forが付与されている可能性が高いため、このようなリクエストを拒否するようになっています。

3-3. SSRF脆弱性を突いた、メタデータを利用した攻撃

SSRF(Server Side Request Forgery)は、攻撃対象のサーバに対して直接攻撃するのではなく、インターネットに公開されているような"アクセス可能なサーバ"の脆弱性を介することで、攻撃対象のサーバにリーチする攻撃です。端的に言うと、インターネットに公開されているサーバを踏み台として使って非公開領域のサーバに攻撃を仕掛ける方式の総称です。

「1.セッショントークン取得」「2.リクエストヘッダにトークンを含ませてリクエスト」という多段構成にすることが、AWSの分析によると多くのSSRF脆弱性に対して有効であるとのことです。 IMDSv2ではPUTリクエストでセッショントークンを取得して、それをヘッダに含ませる必要があるため、決め打ちのヘッダでのリクエストではメタデータを取得できません。これがSSRFの脆弱性に対して有効です。

3-4. 設定に穴のあるL3ファイアウォール又はNAT経由での、メタデータを利用した攻撃

IMDSv2でのトークン取得時のPUTリクエストに対するレスポンスでは、パケットのTTLが1に設定されています。

IPパケットのTTLは、パケットがネットワーク機器を経由するごとに1ずつ減衰していき、0になるとパケットは破棄されます。パケットがループにはまった時に無限ループしないための設定です。パケットのTTLは通常、パケットを送出する主体が決定します。IMDSv2の仕組みでは、トークンを返すときのパケットのTTLを1にしているというわけです。

これの何が良いのかというと、TTLが1のため、トークンを含むレスポンスのパケットはEC2インスタンスの外に出れないことになります。別の機器にパケットが飛ぶと、TTLが0になりパケットが廃棄されるからですね。これにより、何らかの設定ミスや脆弱性を利用して攻撃者がEC2インスタンスの外からセッショントークンを得ることを防ぐことができます。

4. IMDSv1からIMDSv2への移行

デフォルトではIMDSv1とIMDSv2の両方が使える状態です。 IMDSv2だけ使える状態にすることも、IMDSv1とIMDSv2の両方を無効化することもできます。

下記ドキュメントによると、AWS CLIやSDKを利用することで、既存インスタンスのメタデータの有効化/無効化設定を変更できます。またインスタンスローンチ時にも指定可能です。 Configuring the Instance Metadata Options

aws ec2 modify-instance-metadata-options --instance-id i-1234************* --http-tokens required

また、CloudWatchのMetadataNoTokenメトリクスで、セッショントークン無しのメタデータ呼び出し、すなわちIMDSv1での呼び出しが何回行われたか、ウォッチすることができます。この値を確認することで、そのEC2インスタンスでIMDSv1を無効化するタイミングを計ることが可能です。

さらに、IAM RoleによるAPI呼び出しの際のCredentialのIAM context keyとしてec2:RoleDeliveryが追加されました。値は"1.0"または"2.0"を取ります。これにより、API呼び出しがIMDSv1によって行われたかIMDSv2によって呼ばれたかを判断できるため、例えばS3のバケットポリシーに「ec2:RoleDeliveryが2.0じゃないとDenyする」と書いておけば、IMDSv2によってセキュアに取得されたクレデンシャルだけのアクセスに制限できます。