おーみんブログ

C#, ASP.NET Core, Unityが大好きです。

【DNS】カミンスキー攻撃について勉強してみた。

はじめに

先日「DNSキャッシュポイズニング」に関する記事を書きました。

oooomincrypto.hatenadiary.jp

その中でDNSキャッシュポイズニングの対策としてTTLを長くすることを挙げましたが、中にはTTLに関係なく攻撃できる「カミンスキー攻撃」というDNSキャッシュポイズニング手法があるということを今更ながら知りました。

(実際には2008年頃からこの問題は公表されており、今ではそれなりに対策案が出てきています)

カミンスキー攻撃」については以下の記事がとても参考になりました! https://jprs.jp/related-info/guide/009.pdf

カミンスキー攻撃とは

先日解説した一般的なDNSキャッシュポイズニングは一度キャッシュDNSサーバに情報が保存された場合、そのキャッシュが削除される(TTLが0になる)までの期間は再度攻撃を行うことができませんでした。

しかしながらカミンスキー攻撃は実在しないランダムなホスト名でDNS問い合わせをキャッシュDNSサーバへ送り、問い合わせが成立した後に「そのホスト名は知らないが、www.example.jp(攻撃対象のFQDN)が知っているので問い合わせてほしい。www.example.jpのIPアドレスはxxx.xxx.xxx.xxx(偽サイトのIPアドレス)である」という偽の応答をキャッシュDNSサーバへ送るようにします。

その結果、一部のキャッシュDNSサーバの実装ではキャッシュが残っていた場合であっても偽の応答で上書きをしてしまうという事態が起きてしまうのです。

この実在しないホスト名で問い合わせをする手法ではTTLに関係なく攻撃できてしまうことから、単純にTTLを長くするだけではDNSキャッシュポイズニングの対策案としては不十分である(というかあまり意味がない)ことが分かります。

カミンスキー攻撃への対策

カミンスキー攻撃への対策としては以下の2点が挙げられます。

キャッシュDNSサーバの問い合わせUDPポートのランダム化

カミンスキー攻撃が公表される前は問い合わせUDPポートは固定で処理ごとに異なるトランザクションID(65536通り)を用いていました。
その場合、トランザクションIDが見つかってしまったら乗っ取りが発生していましたが、UDPポートもランダム化(65536通り)することで乗っ取りへのリスクを大幅に低減することができます。

DNSSECの導入

上記で記載した「キャッシュDNSサーバの問い合わせUDPポートのランダム化」はあくまで乗っ取りへのリスクを低減するのみであり、根本的に防ぐにはDNSプロトコル自体を見直す必要があります。 その目的として開発されたのがDNSSECであり、その仕組みは権威DNSサーバの回答にデジタル署名を付けることで偽の応答を防ぐことができるというものです。

とはいえDNSSECを導入するためには関連するDNSサーバ全てをDNSSEC対応のものへ更新する必要等があり、現状導入の課題となっているとのことでした。 (うーむ、なかなか上手くはいかないみたいですね(;´∀`))

おわりに

以上、カミンスキー攻撃に関するまとめでした。