Haciendo hacking a un DNS

Muchas veces durante un Pentest, se pasa por alto consultar los servidores DNS de la organización, con el objetivo de obtener información útil o en el mejor de los casos obtener una transferencia de zona.

El cometido del servidor DNS no es más que convertir dominios en direcciones ip a través de la caché local o de un fichero de zona ubicado en los servidores DNS jerárquicos.

A continuación vamos a ver unas técnicas para exprimir un poco más los servidores DNS y obtener información interesante.

Búsquedas DNS reversas

Una búsqueda DNS (registro A) es una consulta que transforma un nombre de dominio en una dirección IP. El caso contrario es la búsqueda DNS reversa, reverse DNS o rDNS que es una consulta que transforma una dirección IP en un nombre de dominio.

Vamos a imaginar que sabemos de una organización que tiene registros PTR configurados y hacemos una consulta su dirección ip:

  • Solicitamos una consulta DNS reversa para la dirección 192.168.100.200 .
  • El resolver del DNS le da la vuelta a la dirección ip que estamos consultando y le añade “in-addr.arpa”, por lo que la dirección ip 192.168.100.200 se convertirá en la 200.100.168.192.in-addr.arpa . Después pregunta al servidor raíz por el registro PTR para 200.100.168.192.in-addr.arpa .
  • El servidor raíz devuelve al resolver una referencia apuntando al servidor DNS encargado del rango de clase A 192.in-addr.arpa que cubre todas las ips que empiezan por 192 , que suele ser la organización que aloja las direcciones ip (RIR o Regional Internet Registry):
    • ARIN: direcciones ip en Norte América.
    • APNIC: direcciones ip de Asia y Pacífico.
    • RIPE: direcciones ip de Europa.
  • El resolver preguntará al RIPE (en este caso que estamos en Europa) por el registro PTR para 200.100.168.192.in-addr.arpa .
  • El servidor RIPE referenciará al servidor DNS de la organización del rango ip original, que suele ser el servidor DNS del proveedor de servicios.
  • El resolver preguntará al DNS del proveedor de servicios por el registro PTR para 200.100.168.192.in-addr.arpa .
  • El servidor DNS del proveedor de servicios referenciará al servidor ´dns de la organización.
  • El resolver preguntará al servidor DNS de la organización por el registro PTR para 200.100.168.192.in-addr.arpa .
  • El servidor DNS de la organización responderá con “host.example.com”.

Para intentar hacer un resumen del orden de llamadas

  1. Consulta DNS reversa para 192.168.100.200
  2. DNS resolver pregunta a DNS raíz por registro PTR de 200.100.168.192.in-addr.arpa.
    1. DNS raíz responde con DNS RIPE.
  3. DNS Resolver pregunta a DNS RIPE por registro PTR de 200.100.168.192.in-addr.arpa.
    1. DNS RIPE responde con DNS ISP.
  4. DNS resolver pregunta a DNS ISP por registro PTR de 200.100.168.192.in-addr.arpa.
    1. DNS ISP responde con DNS organización.
  5. DNS resolver pregunta a DNS organización por registro PTR de 200.100.168.192.in-addr.arpa.
    1. DNS organización responde con “host.example.com”.

Como podemos ver en el ejemplo, la consulta reversa ha devuelto el nombre de host host.example.com. Debido a esto, podemos conectarnos a su servidor DNS y realizar un escaneo manual para descubrir registros.

Escaneo de registros PTR

Para no estar buscando dominios que tengan esta configuración, vamos a hacer un google dork que, utilizando un sitio de herramientas online, nos liste organizaciones que tienen estos ficheros configurados para la resolución inversa a través de registros PTR:

De todos los registros que aparecen, vamos a seleccionar (por ejemplo) el tercero que aparece en la imagen anterior. Al hacer click sobre él, accederemos a la página en la que observaremos el resto de datos necesarios como son los servidores DNS aunque esto se podría hacer de forma manual:

Con los datos necesarios, procederemos a realizar las consultas.

Nslookup desde Windows

Abriremos una consola de windows ejecutando el comando nslookup, en el que estableceremos como servidor DNS la dirección ip que se mostraba anteriormente. Después haremos un escaneo manual de direcciones ip que se encuentran en el rango:

thf_dns_rdns_ejemplo_nslookup

Para comprobar que este servidor que hemos establecido es el que gestiona la configuración de la zona in-addr.arpa, comenzaremos a hacer un escaneo manual de algunas direcciones ip del segmento:

thf_dns_rdns_ejemplo_nslookup_2

En este caso no hemos tenido suerte pues ninguna de las direcciones anteriores ha resuelto en un nombre de host (hemos probado pocas). Cambiaremos entonces al servidor DNS secundario:

thf_dns_rdns_ejemplo_nslookup_cambio_server

Realizaremos la misma prueba que hemos hecho en el paso anterior:

thf_dns_rdns_ejemplo_nslookup_4

Bingo, este servidor si nos ha hecho dos resoluciones para tres direcciones ip diferentes dentro del segmento.

La transferencia de zona

En la mayoría de las empresas existe más de un servidor DNS por el mero hecho de que si uno no puede dar servicio, el servidor secundario pueda resolver las peticiones. Normalmente a uno de esos servidores se le conoce como servidor primario o maestro y a los demás como servidores secundarios o esclavos.

Para que los datos en ambos servidores estén actualizados, los servidores esclavo realizan consultas al servidor maestro cada x tiempo (este tiempo está definido en el fichero de zona) solicitando los últimos registros de recursos disponibles para la replicación de bases de datos. A este tipo de operaciones también se las conoce como consultas AXFR.

Normalmente los servidores DNS de una organización están configurados para bloquear una transferencia de zona desde equipos que no pertenezcan al dominio aunque se puede dar la casuística de que no estén bien configurados o de que el servidor DNS primario de una organización no permita una transferencia de zona pero sí el servidor DNS secundario o terciario.

Por lo tanto, los servidores de nombres deberían estar configurados para responder sólo a los servidores de nombre de ese dominio.

Para realizar esta prueba hemos configurado previamente un servidor DNS en local con Bind9. Podrás encontrar la sección más adelante.

Nslookup desde Windows

En la siguiente prueba de concepto, ejecutamos nslookup para hacer consultas a servidores DNS, estableceremos el tipo de respuesta a NS (para obtener el servidor de nombres primario) y solicitaremos de nuevo el dominio en cuestión:

thf_dns_nslookup

Como ya tenemos el servidor de nombres primario, lo utilizaremos a través del comando server, para volver a realizar la consulta, y le diremos esta vez que queremos que nos devuelva toda la información con set type=all :

Ahora volvemos a solicitar el dominio en cuestión con el comando ls :

thf_dns_nslookup_transfer

Se puede observar que el servidor DNS del dominio utilizado tiene transferencia de zona. Entre los resultados que se devuelven tenemos nombres de hosts, servidores DNS y las direcciones ip internas correspondientes.

Dig desde Linux

Utilizaremos el comando dig desde Linux para realizar consultas a los DNS. En este caso estamos solicitando los servidores de nombres de un dominio (que nos hemos creado nosotros configurando bind):

thf_dns_dig_ns

Sabiendo cual es el servidor de nombres utilizado, comprobaremos si tiene transferencia de zona haciendo con el comando dig una consulta AXFR de esta otra forma:

thf_dns_dig_transfer_zona

Se muestran todos los equipos que hemos configurado en bind con equipos ficticios de nuestro dominio ficticio.

Ataque de fuerza bruta sobre el DNS

Para realizar esta prueba hemos configurado previamente un servidor DNS en local con Bind9. Podrás encontrar la sección más adelante.

Existen numerosas herramientas para realizar ataques de fuerza bruta sobre el DNS (dnsrecon, dnsenum, etc..) . Nosotros vamos a utilizar nmap junto al parámetro –script en el que indicaremos el nombre del mismo dns-brute seguido del dominio a consultar:

thf_dns_brute_force

El proceso de fuerza bruta ha descubierto nombres de hosts configurados en los registros PTR.

 DNS Cache Snooping

Esta técnica permite descubrir aquellos dominios que ha resuelto el servidor DNS que se corresponden con los dominios por los que navegan los empleados de la organización. Primeramente obtenemos los servidores DNS de la organización en cuestión set type=NS:

thf_dns_cache_snoop_server
Seleccionamos uno de ellos server xxxxxx.xx y estableceremos que nos devuelva registros no recursivos con set norecurse . Al solicitar, por ejemplo, el dominio nmap.org obtenemos la siguiente respuesta:

thf_dns_cache_snoop_request

Esta respuesta confirma que se ha visitado este dominio. Por el contrario, si solicitamos www.youtube.com la respuesta es diferente:

thf_dns_cache_snoop_request_no

Esta otra respuesta confirma que no se ha navegado por este otro dominio. Con una lista de dominios grande (y mejor si utilizamos un script como el de nmap –script dns-cache-snoop.nse) conseguiremos descubrir que dominios se visitan en la organización.

Configuración de un servidor DNS: Bind9

Vamos a montar un “laboratorio” para poder hacer las pruebas de DNS en local. Instalaremos el conocido servidor DNS Bind que se encuentra disponible para un gran número de sistemas operativos (sobre todo UNIX):

thf_dns_laboratorio_install_bind

En la configuración del servidor Bind tenemos que tener en cuenta los principales ficheros:

  • /etc/bind/named.conf que contiene la configuracion general de arranque
  • /etc/resolv.conf que contiene los datos de configuracion del cliente

Para el laboratorio vamos a crear un dominio con los siguientes datos:

El fichero de zona

Es un fichero de texto formado por comentarios, directivas y registros de recursos que contiene información acerca del dominio en cuestión. El fichero de zona debe comenzar con un registro SOA que contiene:

  • Servidor de nombres autorizado para el dominio.
  • Dirección de correo de administrador.

Los registros de recursos tienen la siguiente estructura:

  • owner-name: nombre del propietario al que pertenece este registro. También puede ser una etiqueta.
  • ttl: indica el tiempo de vida en segundos, que una vez alcanzado el servidor realiza una consulta y refresca los datos, y durante cuánto tiempo debe ser cacheado el registro.
  • class: indica la familia del protocolo cuyo valor por defecto es IN (Internet Protocol).
  • type: indica el tipo de registro, lo que determinará el valor en el siguiente campo. Algunos de los posibles valores son:
    • A (Address): utilizado para traducir nombres de dominio a direcciones ip.
    • CNAME (Canonical Name): utilizado para crear alias para los hosts de un dominio.
    • NS (Name Server): contiene información de los servidores DNS del dominio.
    • MX (Mail Exchange): contiene la lista de servidores de correo.
    • PTR (Pointer): utilizado para traducir de dirección IP a nombre de dominio.
    • SOA (Start of Authority): contiene información acerca de la zona.
    • TXT (Text): contiene identificación del dominio.
    • SPF (Sender Policy Framework): identifica los hosts autorizados a enviar correos desde el dominio.
  • type-specific-data: contenido de los datos que viene definido por los campos class y type.

El fichero de zona que vamos a crear para nuestra prueba de concepto tendrá los datos siguientes:

Dominio

  • Nombre: thehackingfactory.com
  • Responsable: admin.thehackingfactory.com

Servidores DNS dominio:

  • Primario: ns1.thehackingfactory.com (192.168.5.5).
  • Autorizado: ns2.thehackingfactory.com (192.168.5.6).

Hosts dominio:

  • Rango: 192.168.5.0/24

Con todos los datos listos, comenzaremos creando el fichero de configuración general /etc/bind/named.conf.local en el que especificaremos los ficheros que se van a utilizar:

thf_dns_lab_named_local

Posteriormente generaremos el fichero de zona thehackingfactory que tendrá la siguiente estructura:

thf_dns_lab_thehackingfactory

Finalmente crearemos también su correspondiente fichero de zona reverso reverse.thehackingfactory para que se puedan realizar resoluciones inversas con los registros PTR:

thf_dns_lab_reverse_thf
Como herramienta adicional instalaremos resolvconf  de forma que nos genere el fichero /etc/resolv.conf de forma automática en función de la configuración definida:

thf_dns_lab_resolvconf

Recién instalado, nos moveremos al directorio donde se alojan los ficheros de configuración /etc/resolvconf/resolv.conf.d/ y modificaremos el contenido del fichero original, al que le añadiremos la linea nameserver <dirección ip del equipo> :

thf_dns_lab_resolvconf_config

Generaremos el fichero /etc/resolv.conf con esta nueva herramienta a través del comando resolvconf -u y haremos un dig para comprobar que todo funciona:

thf_dns_lab_resolvconf_u

Ya podemos realizar pruebas contra nuestro propio servidor DNS !!!

Esperamos que os haya gustado el artículo que aunque son cosas básicas, merece la pena repasarlas.

Saludos.

“Don’t give up, great things take time”.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *