しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

Azure が提供するデフォルトドメイン名を狙った改ざんについて注意喚起

Azure

Twitter でちらほら見かけて自分も軽く反応したんですが、ターゲットが Cloud Services と Traffic Manager だったので多少なりとも書いておいた方が良いかなと思ったので、注意喚起を兼ねて書きます。

今回の件を改ざんと書くのは微妙に違う気がしたのですが、元のツイートは改ざんと表現していたので倣って改ざんとしておきます。このあたりの定義は難しそうです。

要約すると、攻撃者が過去に利用されていた名前の *.cloudapp.net や *.trafficmanager.net を新しく取り直して、利用者が削除し忘れていたドメイン名でのアクセスを通るようにしてしまったという話です。

従って回避する方法は、削除し忘れていた DNS レコードを削除するだけでよいです。簡単な話です。

プラットフォーム側で同じ名前で作れないように、という声もあるかもしれませんが、ARM Template や Terraform を考えると作成する度に別名が必要というのは割と困ります。なので基本は不要な DNS レコードは削除しましょう。

削除後に注意すべきサービス

ターゲットとなりうるサービスは、以下のような機能を提供しているものになると考えています。Cloud Services と Traffic Manager はこの条件を完全に満たしています。

  • サービスが共通のドメイン名を提供している
    • 今回であれば *.cloudapp.net
  • サブドメイン名を自由に入力、かつ使用済みのものを利用できる
  • CNAME を使ってサービスへポイントさせる
  • ドメインの所有確認を行わない、または契約者に固有の情報で行っていない
    • TXT レコードを作成し、ドメイン名をそのまま入力させる、など

他にも Azure のサービスでは CDN や Front Door なども、CNAME で正しくポイントされていればカスタムドメインを追加できるので、同様の攻撃対象となる可能性があります。

今回は Azure についてのみ書いていますが、上の条件を満たせば他のプロバイダーでもターゲットとなる可能性があるので注意してください。

Azure の場合、恐らくは以下のサービスは対象となる可能性があります。

  • Cloud Services
  • Traffic Manager
  • App Service (2020/5 以前に作成したもの)
  • CDN
  • Front Door
  • Blob Storage

ただし SSL / TLS 証明書の取得は行えないため HTTP のみ利用可能になりますが、別サイトにリダイレクトしてしまえば関係ありません。元々のサイトが HSTS を使っていて、かつブラウザに情報が残っていた場合はエラーになりますが、まずあり得ないでしょう。

API Management は *.azure-api.net というドメイン名を提供していて対象となりそうですが、カスタムドメインの追加時に証明書を同時に登録する必要があるので、改ざん向けに使うのは難しいでしょう。

勘違いしてほしくないのですが、サービス側に致命的な問題があるのではなく、不必要な DNS レコードが残っていることが致命的な問題です。忘れないようにしてください。

今回の改ざんの Azure 利用者視点での解説

今回ターゲットとなった Cloud Services は *.cloudapp.net というドメイン名を提供しつつ、サブドメイン部分は空いていれば誰でも取れるようになっています。L4 ロードバランサーは付いていますが、サービスとしてカスタムドメインに関する機能は提供されていません。

そして IP アドレスは厳密には固定ではないので、CNAME を使ってカスタムドメインを割り当てるのが一般的でした。この辺りはドキュメントを参照してもらえばわかると思います。

今回のように Cloud Services だけが削除されて DNS レコードが残った状態が発生した場合には、攻撃者は同じ名前で Cloud Services にデプロイするだけで簡単に新しいサイトにアクセスさせることが出来ます。

そして同じように Traffic Manager も *.trafficmanager.net というドメイン名を提供しつつ、同じ名前で取ることが出来るので攻撃者に新しく Traffic Manager を取得されてしまったようです。

とは言え DNS ベースで動作する Traffic Manager では、どのドメインにアクセスしようとしているかなんて確認しようがないので、使わなくなった DNS レコードは必ず削除するのが正しい解決策です。

この後は攻撃対象とならないために出来ることを 2 点書いておきます。基本は使わなくなった DNS レコードを削除するように徹底することなので、頭に入れておいてください。

新規に App Service を使う

App Service は今回のターゲットとなった Cloud Services 上に構築されていますが、カスタムドメイン周りの仕組みが完全に異なっていて、明示的に使用するカスタムドメインを登録する必要があります。

そもそも Cloud Services は明示的に IIS へ設定しない限りは IP 指定でも通るようなザルさなのと、デプロイ周りもレガシー感があふれているので App Service の利用を第一に検討するべきです。

そして 5 月あたりにカスタムドメインの検証周りがアップデートされて、サブスクリプションに固有の ID を設定しないと検証エラーで追加が行えなくなりました。

ただし変更前は TXT レコードに App Service のドメイン名を設定して所有確認していたので、昔から使っていた場合は Cloud Services と同様の問題が発生します。

既にカスタムドメインを設定済みの App Service に対しては、新しく asuid を使うように変更しても良いですし、一度追加したものに対して再チェックは行われないはずなので削除しておいても良いでしょう。とにかく必要ないものを残しておくことは NG です。

IaC でDNS レコードを同時に管理する

根本的にはアプリケーションやインフラと DNS レコードのライフサイクルが別々に管理されているのが原因なので、Terraform などを利用して DNS レコード自体も一体として管理すれば解決します。サービスに必要なリソースを IaC でドメイン名ごと管理してしまえば、削除忘れは起こりません。

SSL / TLS 証明書の管理と同様に、DNS やドメイン名周りは手作業に頼りがちな部分です。

DNS ゾーンは 1 つを使いまわしたいケースも多いと思いますが、Data Source との組み合わせや DNS だけを別のリポジトリで管理するなど、いろいろな方法はあります。

バージョン管理しないと簡単に破綻する部分でもあるので、活用していきましょう。

追記 : Alias Record Set の利用

公式ドキュメントに今回の攻撃に対する内容が少し前に追加されています。

App Service はこれまでに書いた通りサブスクリプション固有の ID を設定することで回避する方向ですが、CDN と Front Door に関しては Azure DNS の Alias Record Set を使うことで、該当リソースが削除されたタイミングでレコードを引けなくなるので回避可能です。

内部では既に問題として認識されていて、対応を検討しているようなので情報が今後出てくると思います。