前回の記事では、さまざまなDNSトリックを使用した.na 、 .co.aoおよび.it.aoドメイン拡張子のキャプチャについて説明しました。 次に、トップレベルドメイン（TLD）の侵害の脅威と、目標を達成するために攻撃者がどのように行動するかを検討します。 かなり単純な方法の1つは、このTLDの権限のあるネームサーバーの 1つのドメイン名の登録のようです。 権限のあるサーバーはTLDの任意のドメインでホストできるため、不適切な構成、有効期限、またはその他のエラーによるエラーを使用して、そのようなドメインを登録することができます。 次に、このサーバーを使用して、ドメインゾーン全体で新しいDNSレコードを発行できます。
前の記事の対応する引用を引用します。
そのような選択肢は勝利への確実な道のように思えたので、このタイプのエラーをチェックするツールキットの開発に多くの時間を費やしました。 本質的に、このプロセスは、特定のドメインのすべてのホストネームサーバーを記録することと、ルートドメインの有効期限が切れて登録が可能になる時期を確認することで構成されます。 主な問題は、多くのレジストラが、あなたが本当にそれを購入しようとするまで、ドメインが完全に無料であると言っていないことです。 さらに、サーバーの登録が不足しているいくつかのケースがありましたが、何らかの理由で、ドメインは登録済みとしてマークされていませんでしたが、登録できませんでした。 このようなスキャンの結果、多くのドメインインターセプトをクローズドゾーン（.gov、.edu、.intなど）に記録できましたが、TLD自体は記録できませんでした。
結局のところ、この方法はTLD攻撃に適しているだけでなく、実際にはこれまでで最大のTLDキャプチャをもたらしました。
異常.io
金曜日の夜、さまざまなTLDのDNS委任パスをプロットすると、スクリプトは.ioゾーンに対して予期しない結果を返しました。
このスクリプトの機能の1つ（ TrustTreesと呼ばれる）は、Gandi APIキーを渡すことができることです-そして、委任チェーンに空きドメイン名を持つネームサーバーがあるかどうかをチェックします。 スクリプトは、.ioゾーンでドメインの多くのドメイン名を購入できることを示しました！ ただし、これは実際に購入できるという意味ではありません。 以前は、無料のドメイン名は「予約済み」であるため登録できないという事実に繰り返し遭遇しました。 NIC.IOレジストラのWebサイトにアクセスして確認することにしました。 ドメイン名ns-a1.ioをすばやく検索すると、 90.00ドルの価格で販売されていることに驚いた。 真夜中ごろだったので（ おそらく、著者はこれを「子供の頃」の時間と見なします-約）。私はこのドメインを継続して購入しようと決めました。 間もなく、ドメイン名の登録が「処理中」であることを確認する手紙が届きました。
101Domainからの手紙の理由は明らかではありません。 彼女は、おそらく.ioゾーンのドメインの登録に関与しています（レジストリ全体を管理している可能性がありますか？）。 この時点で、真夜中を過ぎてから、肩をすくめて寝ましたが、水曜日の朝、仕事に出かけようとしているそのような手紙が届くまで、この事件を忘れていました。
それから私は金曜日の調査と登録のすべての詳細を思い出しました。 コンピューターに戻らなければなりませんでした。本当に.ioドメインゾーンネームサーバーを制御できたのでしょうか。 ドメインに対して
dig
コマンドをすばやく実行し、テストDNSネームサーバー（ ns1 / ns2.networkobservatory.com ）が実際にns-a1.ioに記録されていることを確認しました ：
bash-3.2$ dig NS ns-a1.io ; <<>> DiG 9.8.3-P1 <<>> NS ns-a1.io ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8052 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns-a1.io. IN NS ;; ANSWER SECTION: ns-a1.io. 86399 IN NS ns2.networkobservatory.com. ns-a1.io. 86399 IN NS ns1.networkobservatory.com. ;; Query time: 4 msec ;; SERVER: 2604:5500:16:32f9:6238:e0ff:feb2:e7f8#53(2604:5500:16:32f9:6238:e0ff:feb2:e7f8) ;; WHEN: Wed Jul 5 08:46:44 2017 ;; MSG SIZE rcvd: 84 bash-3.2$
ルートDNSサーバーの1つを要求し、このドメインが最初のレベルの.ioドメインゾーンの信頼できるネームサーバーとしてリストされていることを確認しました。
bash-3.2$ dig NS io. @k.root-servers.net. ; <<>> DiG 9.8.3-P1 <<>> NS io. @k.root-servers.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19611 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 12 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;io. IN NS ;; AUTHORITY SECTION: io. 172800 IN NS ns-a1.io. io. 172800 IN NS ns-a2.io. io. 172800 IN NS ns-a3.io. io. 172800 IN NS ns-a4.io. io. 172800 IN NS a0.nic.io. io. 172800 IN NS b0.nic.io. io. 172800 IN NS c0.nic.io. ;; ADDITIONAL SECTION: ns-a1.io. 172800 IN AAAA 2001:678:4::1 ns-a2.io. 172800 IN AAAA 2001:678:5::1 a0.nic.io. 172800 IN AAAA 2a01:8840:9e::17 b0.nic.io. 172800 IN AAAA 2a01:8840:9f::17 c0.nic.io. 172800 IN AAAA 2a01:8840:a0::17 ns-a1.io. 172800 IN A 194.0.1.1 ns-a2.io. 172800 IN A 194.0.2.1 ns-a3.io. 172800 IN A 74.116.178.1 ns-a4.io. 172800 IN A 74.116.179.1 a0.nic.io. 172800 IN A 65.22.160.17 b0.nic.io. 172800 IN A 65.22.161.17 c0.nic.io. 172800 IN A 65.22.162.17 ;; Query time: 70 msec ;; SERVER: 2001:7fd::1#53(2001:7fd::1) ;; WHEN: Wed Jul 5 08:46:14 2017 ;; MSG SIZE rcvd: 407
わあ！ 私はすぐに、このドメインがバインドされているテストDNSサーバーにSSH経由で接続し、動作中のBINDサーバーをすぐに殺しました。 DNSトラフィックが私を怒らせたら、間違いなく、.ioドメインへの正当なアクセス権を持つ人々に悪い答えを返したくありません。 BINDサーバーはポート53の要求を処理しなくなったため、すべてのDNSクエリはこのTLDの他のネームサーバーに自動的にリダイレクトされ、トラフィックにあまり影響を与えません（DNSクライアントが作業中のネームサーバーに到達する間の解決時のわずかな遅延を除く）。 DNSクエリが本当に私に届いたかどうかを確認するために、私はすぐにすべてのDNSトラフィックのtcpdumpのダンプをファイルに記録し始めました。インターネット上のランダムIPからの何百ものクエリが画面に注がれました。 ドメインゾーン全体のトラフィックを本当に処理したようです。 さらに悪いことに、多くのDNSクライアントは、すぐに更新される古いDNSレコードにガイドされているため、おそらくほんの始まりに過ぎませんでした。
TLDのセキュリティ問題を報告する
サーバーがDNSクエリに応答しなくなったため、状況をすばやく修正する方法についてのみ考えました。 何よりも、お金と知識を持っている人なら誰でも登録できるネームサーバーのドメインがまだたくさんあるのではないかと心配しました。 IANAルートデータベースで.io TLD管理者の連絡先を探しました：
その後、彼は問題の説明を行い、両方のアドレスに手紙を送り、緊急の解決策の必要性を指摘しました。 彼は、他のTLDネームサーバーのドメインは引き続き登録可能であり、数時間以内に問題が解決しない場合は、それらを登録してゾーンを保護することを指摘しました。 手紙を送った直後に、アドレスadminstrator@nic.ioが存在しないことを示すメールをメールサーバーから受け取りました。
これは明らかに誰かが私の手紙を読むだろうという自信を加えませんでした。 だから誰もTLDをハッキングしないように、お金をかけてネームサーバーの残りのドメインを購入することにしました。 最初の場合と同様に、着信要求を受け入れないようにDNSサーバーを明示的に構成したため、通常の.ioトラフィックに干渉しませんでした。 これらの注文書は十分に迅速に発行されます。
ふう！ 少なくとも一部のランダムなハッカーはそれらをクラックしないため、純粋な心で仕事に行くことができます。
その日遅くに、NIC.IOサポートに電話し、有効なTLDセキュリティメールアドレスを求めました。 エージェントは、このようなリクエストに対してabuse@101domain.comが適切なアドレスになることを保証しました（確実にこのアカウントで再確認しました）。 このアドレスは適切ではないように見えますが、問題の説明を記載したレポートを送信し、少なくとも有能な専門家に送信されることを希望しました。 他の住所を見つけることができなかったので、私は答えを待っていました。
「エラー」-ドメイン登録をキャンセルして修正
翌日の正午頃、101Domainsから、ドメイン登録がキャンセルされ、お金がカードに戻され、私の「サポート中のチケット」が返事をされたという一連の通知が来ました。
驚くべきことに、問題を解決するために悪用@アドレスが本当に正しいアドレスであることが判明したようです。 101Domainアカウントにログインした後、101Domain法務部からのこの手紙を見つけました。
すべてが非常に迅速かつ正確に行われました（通常、法務部からの応答ではなく、通知書のみを受け取ります）。 指定されたドメインが登録に使用できないことを確認した後、状況が完全に修正されたと結論付けることができました。
考えられる結果
.ioドメインゾーンの7つの信頼できるネームサーバーのうち4つを登録した場合、登録されたすべての.ioドメインのDNSレコードを変更/リダイレクトできます。 さらに、ネームサーバーの半分以上を制御しているため、DNSクエリは、 長いTTL応答やその他の可能性を高めるその他のトリックを追加することなく、私たちに届きやすくなります。 この種の攻撃に対する即時の反応があったとしても、キャッシュされたレコードが世界中のDNSリゾルバーから完全に消去されるまでには時間がかかります。
この状況を修正するには、DNSSECテクノロジーが.ioドメインゾーンでサポートされている場合に役立ちます。 つまり、リゾルバーがこのテクノロジーもサポートしている場合、偽のDNSレコードを使用してこのような攻撃から身を守ることができます。 しかし、前の記事で述べたように、 DNSSECを使用する人はほとんどいません 。 リゾルバを自分で具体的に設定しない限り、少なくともこのテクノロジーのサポートはほとんどありません。
*トピックに関係のない発言：開始後にtcpdumpを停止することを忘れないことが重要です。 これが行われない場合、VPSディスク上のすべてのスペースをDNSデータで埋めるチャンスがあります。 デバッグ目的で記録されたすべてのDNSデータは、ユーザーの機密情報が消去されることに注意してください。
保護およびセキュリティTLD
TLDがこれらの問題のいくつかをどのように回避できるかについて詳しく書きました（詳細については、「 ルーティングのハッキングナショナルTLD-ドメイン名拡張の隠れたリスク 」の記事の「結論と最近の考え」を参照してください。）そのような状況を監視および防止するためのTLDおよびドメイン名拡張演算子。
あいさつ
私は友人に次のブログ投稿でハッカーに挨拶することを約束したので、約束を果たす必要があります:)。 彼らの道徳的および「不道徳」なサポートに感謝します（唯一のHackerBadgerが言ったように ）。
こんにちは、 HackerBadger 、EngSec（あなたが誰であるかは知っています）、 Hacke the planet 、 ギブソンなど。