DNSゾーンをクリーンに保つ必要がある理由

自分のパソコンに保存されたファイルや文書など、デジタル空間は常に整頓されている状態であるとは限りません。未読のタブを開いたままにして、パソコンの電源を落とさないまま外出したり、書きかけの文章の上にまた新しく文章を書き始めるなど、整頓されていない状態であることがかなりあるのではないでしょうか。混沌は創造性が生まれてくるきっかけになりますが、たいていの場合はただ単に掃除が必要なだけです。

このような混沌としてデジタル空間を考えると、DNSゾーンの片付けの優先度は必然的に低くなってしまうと思います。しかし、以前使用していて今は使用していないレコードがまだ存在するなど、DNSゾーンレコードが散らばった状態ではセキュリティ上の深刻な問題を引き起こしてしまう可能性があります。

起こりうる最悪の事態とは

ライドシェアサービスを提供する Uber は所有するドメイン名を使ってこのようなサブドメインを作成しました : saostatic.uber.com

Uber はサブドメインに Amazon Cloudfront (CDNサービス) を使っていました。

ある時点で、Uberはサブドメイン (saostatic.uber.com) の使用を停止し、Amazon Cloudfront からエンドポイントを削除しました。しかし、Cloudfront が指す “saostatic” CNAME を削除した人は誰もおらず、レコードは存在し続けることになりました。

ある日、バグバウンティハンターが saostatic サブドメインを発見し、ページに移動すると “Bad Request” エラーが表示されますが、サブドメインがまだ Cloudfront を指していることを確認しました。

その後、そのバグバウンティハンターは自分の Cloudfront アカウントからエンドポイントとして saostatic.uber.com を追加することだけで、saostatic.uber.com を完全に制御することができるようになりました。

さらに悪いことに、Uber が新しく実装したシングルサインオンシステムが * .uber.com のセッションクッキーを発行したため、架空の攻撃シナリオでは、認証されたユーザーに saostatic.uber.com に移動させると、架空の攻撃者がそれを乗っ取ることができる可能性がありました。ユーザーのセッションと、様々なUberのサービスでユーザーのアカウントにアクセスすることが可能になります。

ここでは Uber を責めるためにこの事例を紹介しているわけではありません。不具合はどこでも起こりうるものです。重要なのは、DNSゾーンから CNAME を削除するのを忘れるという小さなことのように見えることは、あなたやあなたのユーザーに危害を加えようとしている誰かによって発見された場合、潜在的に大きなセキュリティ上の頭痛の種になる可能性があるということです。

さらに悪いことに、サービス提供側では何も変化しておらず、ネットワークにも問題は発生しないため、この種の攻撃を検出することは事実上不可能です。

同様に、無料のSSLサービスを使用すると、攻撃者はサブドメインのSSL証明書を簡単に取得できるため、顧客も気づきにくい場合があります。

他に何ができること

Uberの例では、バグバウンティハンターがクッキーを使用してこの問題を悪用できることを説明しました。ただし、Oauth などの一部のテクノロジーには、開発者が受け入れるコールバックURIを指定できるサブドメインの許可リストメカニズムがあります。許可リストにあるサブドメインが乗っ取られた可能性がある場合、ユーザーのOauthトークンが盗み取られるされる可能性があります。

こういった攻撃者がサブドメインの乗っ取りを伴う許可リストを利用する方法は他にもいくつかあります。

一部のパスワードマネージャーはサブドメインに基づいてパスワードも保存するため、フィッシングサイトはパスワードマネージャーからのユーザーログイン情報を奪い取ろうとする可能性があります。

どのように問題が起こるか

上記で説明したのは例であり、Amazon Cloudfront は一般的に広く使用されているサービスですが、こういったセキュリティ上の問題が発生しうるのは Amazon Cloudfront だけではありません。

また、Uber のような成功しているサービスだからこのような問題が発生しうるというわけでもありません。誰にでも起こりうる問題です。

例えば、shop.example.com をブラウザに入力すると eコマースサイトにアクセスするようにウェブサイトが構成されているとしましょう。ここで、ショップをexample.com/shop に移動し、ホスティングからshop.example.com を削除するとします。

そして、shop.example.com をホスティングプロバイダで設定した CNAME レコードも削除しないと、他の誰かが shop.example.com のホストを作成して、サブドメインを乗っ取る可能性があります。

ホスティングサービスでは、CNAMEレコードを介して指定したサブドメインに新しいホストを作成できる可能性があることを考慮し、それに応じて行動する必要があります。

Uber の古い CNAME レコードを見つけたバグバウンティハンターは、サブドメインをスキャンするツールを使用していた可能性があります。または、ドメインをGoogleで検索して、どこかにインデックスが付けられたサブドメインを見つけた可能性があります。したがって、admin.example.com や mail.example.com のような明らかなサブドメインではないという理由だけで、脆弱性がないと思わないようにしましょう。