| /JPRS /KDDI /bind-9.9.0 /bind-test /crimson /ghost2 /unbound /危険性 /活用法 /調査 |
1. DNS/GhostDomainNames
2022年 Ghost Domain Reloaded https://lixiang521.com/publication/ndss23/
- 2012年の緩和策では不十分であることがはっきりした。
スライド https://indico.dns-oarc.net/event/44/contributions/953/attachments/916/1702/OARC39_phoenix_li.pdf
CVE-2022-30698 Detail /CVE-2022-30698 https://nvd.nist.gov/vuln/detail/CVE-2022-30698
CVE-2022-30699 Detail /CVE-2022-30699 https://nvd.nist.gov/vuln/detail/CVE-2022-30699
1.1. 2012
https://dnsops.jp/bof/20120425/20120425-DNSOPS.jp-BoF_Ghost_Domain_Names_v02.pdf
リゾルバーではTTLの上限を設定することを勧める。
そして、キャッシュにある項目は上書きしないことが重要だ。特にNSは。
解決したという話は聞かない。(緩和策はある。) -- ToshinoriMaeno 2021-04-10 00:32:54
Contents
「鬼域名」と呼ぶことにした。（幽霊ドメイン名はしっくりこない）
DNS/毒盛/AncillaryDataAttacksと密接に関連する。
- NS TTLの扱いが問題だという立場もあるが、それでいいのだろうか。
NS TTlだけではないだろう。
DNSの「根本的欠陥」のひとつが公表された。https://www.isc.org/software/bind/advisories/cve-2012-1033
- ISC (BIND製作元）はprotocolの問題だとして、その議論が決着するまで修正しないと表明している。
- (いつまで放置するか、責任が問われる) DNSSECを推進するための脅しの材料にするつもりのようだ。
CVE: CVE-2012-1033 Document Version: 2.0 Posting date: 07 Feb 2012 Program Impacted: BIND Versions affected: All versions of BIND 9 Severity: High Exploitable: remotely
幽霊ドメイン名脆弱性：「本来、名前解決が失敗するドメイン名を解決可能つまり使用可能に保つ裏技」ー＞ドメイン管理組織にとっては非常に都合の悪い欠陥です。抹殺したいのにできないから。
すでに対策されたBIND 9.9.0 が公開されているので、BINDユーザは9.9.0 に更新することを検討すべきである。
- 対策したとのアナウンスはない。（論文にある攻撃法への対症療法だという言い訳をしそう。）
- Changes の [bug] に修正の記述がある。
When replacing an NS RRset, BIND now restricts the TTL of the new NS RRset to no more than that of the NS RRset it replaces. [RT #27792]
- BIND * rc2 で各バージョンに対策が組み込まれた。もうすぐ、公開されるはず。JPRSからもプッシュしたらしい。
Kaminsky 攻撃に対してDNSSECしか対策がないような警告をしていたのと、よく似ている。
http://www.e-ontap.com/dns/bindmatrix.html BIND各バージョンへの毒入れ実験
真実を語らず、対策もでているのに明示せず、脅威を煽るのはいかがなものか。
1.2. BIND 9.9.0 での対応でも不十分
max-cahce-ttl の設定は必須だと考えられる。-- ToshinoriMaeno 2012-05-20 14:44:37
- max-cache-ttl を長くても1日程度にしておけば、影響範囲が狭められる。
BIND 9.9.0 などでの対策の効果はNSレコードのTTLだけなので、
- AレコードなどのTTLを長くされると、影響が続く。
Unboundでは cache-max-ttl のデフォルト値は1日（86400）です。 http://unbound.jp/unbound/unbound-conf/
BIND 9では1週間（604800）です。前野さんがtwitterでも指摘されていますが、 攻撃者が悪意をもって攻撃してくることを考えると、このデフォルト値はいただけないですね。
-- OrangeMorishita 2013-08-22 03:15:30
警告があってもいいのではないですか。-- ToshinoriMaeno 2013-08-22 14:39:28
JPRS からはまだ公式の警告がない。すでに一週間が過ぎたから、警告しないのだろう。
JPRSからの警告が出た。2012-02-17 (長い。でも、一通りは読んで欲しい。当面の回避策も書かれている。) http://jprs.jp/tech/notice/2012-02-17-ghost-domain-names.html
http://www.jpcert.or.jp/wr/2012/wr120601.html (JPCERT) 参考にならない。
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1192 unbound についての脆弱性
The resolver in Unbound before 1.4.11 overwrites cached server names and TTL values in NS records during the processing of a response to an A record query, which allows remote attackers to trigger continued resolvability of revoked domain names via a "ghost domain names" attack.
「この脆弱性の影響を受けるのは..キャッシュDNSサーバだけ」... という文面はいただけない。脆弱性を引き起こしているのがキャッシュサーバだから。
キャッシュサーバだけが問題であるかのように書いてあるが、脆弱性の影響はキャッシュサーバの利用者に及ぶ。
- DNSサーバの管理者しか目に入らない解説である。JPRSの姿勢が疑われる。
1.3. ところが
３月初めに公開されたISC BIND 9.9.0 のリリースノートをみると、
- feature change にしっかりghost 対策の項目がある。（CHANGESにはbugと明記されている。）
にもかかわらず、Ghost Domain Names 脆弱性についての説明はまったくない。
- 重大な脆弱性とか、プロトコルの欠陥とか言った手前、収集がつかないのかもしれない。
- Kaminky 型攻撃のときと似た対応だ。 DNSSECを勧める手段に利用しようとしているようだ。
bugだと認めれば、9.6-ESVなどの修正が必要になるが、まだ修正はでていない。-- ToshinoriMaeno 2012-03-03 09:30:57
1.4. 影響
/危険性 /活用法 https://twitter.com/#!/beyondDNS/status/171377388402388992
1.5. 当面の対策
BIND 9.9.0 へ更新する。-- ToshinoriMaeno 2012-03-03 09:19:14
unbound (1.4.8 以降）にはこの欠陥に起因する脆弱性を回避する対策がほどこされている。
- BINDキャッシュサーバの管理者はunboundに乗り換えることを検討するのがよい。放置するのは無責任だ。
ユーザはGoogle Public DNSを使うという手段もある。
キャッシュサーバの変更ができない場合にはキャッシュを頻繁にクリアする。
dnscache での対応: DNS/ghost2/dnscache (ログインして見てください。）
1.6. 論文
DNS/GDN 鬼域名（Ghost Domain Name）：删除了但仍可以解析 http://netsec.ccert.edu.cn/duanhx/archives/1656?lang=zh-hans
上位サーバの権限により強制削除したはずのドメイン(の委譲)がキャッシュでは検索可能なままで残存する状態をさす。
Ghost Domain Namesで明らかにされた。 いわゆるDNS/浸透問題と同種のキャッシュサーバの動作を悪用するものである。
上位権威サーバからの委譲はTTLで指定された時間しか有効ではないはずなのに、 キャッシュサーバが委譲を受けた側の権威サーバの返答(やそのTTL)をキャッシュして、クライアントに返答することで発症する。
キャッシュサーバのTTLの扱いの不良に起因する脆弱性である。 それにも関わらず、DNS protocol (RFC) には規程がないために、いまだBINDなどを作成するISCからは修正情報が出されていない。
1.7. 対応策
現時点での対策はキャッシュサーバ運用者は定期的にキャッシュをクリアするか、 この脆弱性が見つかっていない最新版のunbound (1.4,16)を使うかである。-- ToshinoriMaeno 2012-02-16 03:19:00
キャッシュユーザにはGoogle Public DNSを使うという手段もある。
-- ToshinoriMaeno 2012-02-14 06:53:51
指摘の重要性、問題の深刻さに気づいたひとが増えている。結構なことです。
ISCの対応：
Solution:
On further review, ISC has determined that this is not an issue which needs an immediate patch. The issue is being reviewed at the protocol level and will be addressed there. Implementing DNSSEC is the safest mitigation measure.
すぐには対応できない。protocol が悪い。DNSSECで対応してくれ。（対応できるとは思えないが -- ToshinoriMaeno 2012-02-16 02:15:37）
1.8. その後
ISCはGhost Domain Names脆弱性への対応だとは言わないが、JPRSは対応したと言っている新版がリリースされた。
- このあたりの食い違いを指摘しても、JPRSは無視している。
Ghost Domain Names脆弱性が完全に回避できるとも思えないのだが。-- ToshinoriMaeno 2012-05-26 09:40:36
http://www.matsuyuku.com/keniamemo/2012/04/iscbind--internet-watch.html
unboundではどういう対応がされたか。
- 「RRSetの置き換え時にRRSetそのものを上位サーバに問い合わせ直す」ということだと、
- 名前解決が「解決しない」こともあり得るので、
-- ToshinoriMaeno 2014-03-02 04:07:35
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1192
http://dnsops.jp/bof/20120425/20120425-DNSOPS.jp-BoF_Ghost_Domain_Names_v02.pdf
Copyright © 2012 Japan Registry Services, all rights reserved. 1 10分でわかる幽霊ドメイン名と浸透問題の関係
「NSレコードの内容（ホスト名）は違うが、 NSで指定されているホスト名のA／AAAAレコードの内容（IPアドレス）は同じ 」設定を意図的に作成