ちょっくら、Naverまとめを使ってみた。
DNS脆弱性に伴う障害の件で、TKEYのnull処理ができていないというダサいバグで、落ちる問題。
手元のコードで試してみたら、さくっとおとせる、addtionalをぶち込むだけの簡単な仕事。
7/30に実験して遊んでたものだけど、結果はこんな感じ。
環境:debian 7.8 + apt標準のbind(9.8.4)
# named -V BIND 9.8.4-rpz2+rl005.12-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' using OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013 using libxml2 version: 2.8.0
攻撃パケットを投げると、さくっとイチコロ。bindコロリ。
30-Jul-2015 15:24:52.719 general: critical: message.c:2311: REQUIRE(*name == ((void *)0)) failed, back trace 30-Jul-2015 15:24:52.719 general: critical: #0 0x7f083aea8dd9 in ?? 30-Jul-2015 15:24:52.719 general: critical: #1 0x7f08397e9f3a in ?? 30-Jul-2015 15:24:52.719 general: critical: #2 0x7f083a71106f in ?? 30-Jul-2015 15:24:52.720 general: critical: #3 0x7f083a79cbd9 in ?? 30-Jul-2015 15:24:52.720 general: critical: #4 0x7f083aeb9615 in ?? 30-Jul-2015 15:24:52.720 general: critical: #5 0x7f083ae9fe71 in ?? 30-Jul-2015 15:24:52.720 general: critical: #6 0x7f0839808e1d in ?? 30-Jul-2015 15:24:52.720 general: critical: #7 0x7f08391bcb50 in ?? 30-Jul-2015 15:24:52.720 general: critical: #8 0x7f0838ba695d in ?? 30-Jul-2015 15:24:52.720 general: critical: exiting (due to assertion failure)
query log には、TKEYとはっきりと残る。
落ちたとしても攻撃を受けたIPはわかるので、攻撃元のIPまでは、追跡できる。とはいいつつも、UDPを使っている以上ステートレスなので、ソースアドレス詐称(IPアドレス偽造)は容易にできるので、まあ、攻撃があったというのはログでわかる&&script kiddyレベルであれば、わかるだろうけど、パケット生成する際に、src詐称されたら追跡不能。ま、それぐらい一発のパケットで落ちるっていう危険な代物。
あれだけ、JPCERT/CCやJPRC、JPNICなどが注意喚起していて、
いまだに対策されていないというのは馬鹿げた事業社で落とされても自業自得というぐらいの物なので、日記に書いている。すでに各社パッチも出回ってるし。
# そういえば、脆弱性対応をしませんといった事業者も私は知っている。そういうところは大体つぶれてる。
ということで、直近でやられたところなどまとめてみたら、面白い傾向が。
実際にやられてしまった事業者は対応、対応予定を記載しているが。
やられてしまったところで書いているところは、まあ、誠実な感じ。
それ以外は対応済など、しれっと書いているところが多いし、下手したら、この件に対するメンテナンスをしますという告知がなく対応されているケースが多い。ゼロデイ攻撃というほどでもないが、リスクがかなり高い緊急性の高く、且つ、、DNSの仕組み上冗長化(複数NSが存在しているという意味で)していれば、名前解決に遅延は発生(いわゆるリトライで別のサーバを参照)する程度なので、即座に対応していると考えられる。また、大手であれば、DNS Anycastなどの実装を使ってると、切り離して対応など、大変ではあるものの容易に対応できることから、アナウンスをしていないとおもわれる。
また、○○日に対応しますよ、と案内を出すと、それまでは対応していない、脆弱性がある状態で運用しているとアピールしているようなものなので、事後アナウンスもしくはアナウンスしていないようにも思えた。
大半は業界で粛々と対応しているなぁと。対応されているかどうかは試すすべは攻撃しかないためやらないけど、対応していると信じています。ね? 某SaaSesさんw