この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、脅威検知してますか？(挨拶
少し前になりますが、GuardDutyが新しいFindings TypeとしてUnauthorizedAccess:EC2/MetaDataDNSRebindをサポートしました。重要度が高の脅威です。
Amazon GuardDuty に 3 個の新たな脅威検出が追加
これは、DNS Rebindingという手法でEC2インスタンスのメタデータを搾取するような攻撃を検知することが可能です。この動作を行い実際検知するか確認してみました。
DNS Rebindingとは
徳丸先生のブログに下記のように書かれています。
DNS Rebindingは、DNSの返すIPアドレスを巧妙に変化させることにより、JavaScriptやJavaアプレットなどのsame origin policyを破り、インターネットからローカルネットワーク(通常外部からはアクセスできない)などに対してアクセスする手法をいう。
このブログの攻撃のシナリオを読むとより理解が進むと思います。
この攻撃がAWS上でどう使われるかというと、上記にローカルネットワークと書かれているところでピンとくる方もいるかも知れませんが、
EC2等のインスタンスメタデータ(169.254.169.254)から情報を取得するのに使われます。
EC2インスタンス上でブラウザを利用することはあまり多くはありませんが、ヘッドレスブラウザを利用してコンテンツを取得するような処理を行っている場合などで攻撃が成り立つこともあり、某セキュリティ企業でもこの件についての記事が書かれていました。
やってみた
というわけで実際に検知するかやってみました。
細かくは説明しませんが、DNS Rebindingを行うために自分の所持しているドメインを用意し、RebindするためのツールをEC2上に立て、WebサーバとDNSサーバをセットアップします。もう一つブラウザを利用するEC2を立てます。ヘッドレスブラウザでいろいろするのは面倒だったので今回はWindows ServerでGUIブラウザを利用しました。
再現のフローは下記のようになります。
これで見事GuardDutyが検知しました。下記のようにUnauthorizedAccess:EC2/MetaDataDNSRebindとして検知しています。
実際の対応方法の詳細はLearn Moreから確認できます。結果IDをクリックするとjsonで詳細が確認できますが、リクエストしているドメイン名はこちらで詳細に確認できます。実際の確認画面は下記のようになります。
対応方法
実際にこの脆弱性を検知したら、AWSのドキュメントを参考にしつつ対処しましょう。
重要度が高であるように、殆どの場合攻撃を受けていて該当EC2に割り当てられたIAM Roleの権限を持ったクレデンシャルが搾取されていると考えられます。
リクエスト元やリクエスト先を確認して想定外のものであれば、下記のような手順でクレデンシャルを無効化しつつ、影響範囲の調査を行う必要があります。
CloudTrailで該当クレデンシャルを指定して挙動を確認すると影響がわかります。
まだプレビュー中ですが、Amazon Devectiveが登場すると、この調査はかなり捗るでしょう。
また、根本的に割り当てる権限を最小限にしておくことも必要です。
まとめ
GuardDutyの新しいFindingsであるDNS Rebindingの検知を試してみました。
攻撃が成功する条件は限定的ですが、いざクレデンシャルが抜かれてしまうと大変なので気をつけましょう。
5
