Home Security MITM (DNS Spoofing) Parte I ENTENDER DNS queries y ARP

MITM (DNS Spoofing) Parte I ENTENDER DNS queries y ARP

by José Luis Sánchez Borque

DNS spoofing es un método para alterar las direcciones de los servidores DNS que utiliza la potencial víctima y de esta forma poder tener control sobre las consultas que se realizan

Objetivos

  • Entender cómo funcionan las peticiones DNS y ARP
  • Entender la técnica de Man-In-The-Middle (MITM)
  • Trabajar con Kali 2017.1
  • Trabajar con técnicas de arp spoofing
  • Trabajar con técnicas de dns spoofing
  • Trabajar con Ettercap

Veamos en primer lugar el escenario del laboratorio de prácticas. En mi caso todas las máquinas están virtualizadas. La máquina Windows es un Controlador de Dominio que gestiona el dominio profe.local. Ahora no tiene ninguna relevancia, pero me servirá para próximos post. El router es un pfsense ( gran descubrimiento que requerirá mi atención en próximos post)

Los que quieran instalar Kali en entorno virtualizado, tienen un excelente Post para instalarlo sobre vmware workstation en el enlace adjunto, realizado por el gran Xavi Genestos @sysadmit, gracias Xavi y Pol Padrisa

http://www.sysadmit.com/2017/04/vmware-kali-linux-instalar.html

Esquema del laboratorio

Tengamos bien a mano las IP’s y direcciones MAC de todos los actores implicados.

Máquina                  Internet Address      Physical Address
wsrv12.profe.local       192.168.50.1          00:0c:29:5a:a6:c5
gkali.profe.local        192.168.50.100        00-0c-29-d9-f8-31
pfsense.profe.local      192.168.50.254        00-0c-29-a6-aa-24

Antes de intentar la técnica de spoofing, y como siempre me gusta decir, hay que entender los protocolos.

¿Cómo funcionan las peticiones DNS de un cliente?

Las peticiones dns de clientes -dns query/dns response-, utilizan el puerto udp/53.  

En otros capítulos veremos que DNS también utiliza el protocolo TCP/53 para comunicaciones entre servidores. Por ejemplo, transferencias de zonas.

Veamos cómo funciona la típica consulta de un cliente preguntando por una dirección lógica (IP) de un nombre FQDN (por ejemplo www.cocacola.com , no tengo nada contra la pepsi). En primer lugar, y dado que nuestra intención es capturar las peticiones dns query del cliente, borraremos la Cache local DNS de la máquina Windows, o no obtendremos nada, ya que está en estaría en caché local y la consulta nunca se produciría. A menos que expiré el Time To Live del registro almacenado.

Podemos ver con la orden ipconfig /displaydns,  las entradas que tenemos almacenadas en nuestro ordenador, y su tiempo de vida. Una vez transcurrido el tiempo de vida, se borra el registro y se produciría una consulta dns de necesitarse.

C:\>ping -n 1 www.cocacola.com

Pinging a1128.g2.akamai.net [84.53.133.80] with 32 bytes of data:

Reply from 84.53.133.80: bytes=32 time=102ms TTL=55

Ping statistics for 84.53.133.80:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 102ms, Maximum = 102ms, Average = 102ms

C:\>ipconfig /displaydns

Windows IP Configuration

    www.cocacola.com
    Record Name . . . . . : www.cocacola.com
    Record Type . . . . . : 5
    Time To Live  . . . . : 9
    Data Length . . . . . : 8
    Section . . . . . . . : Answer
    CNAME Record  . . . . : globalcokesites.edgesuite.net

 

Al final, lo que intentaremos con esta técnica es que el cliente aprenda una respuesta adecuadamente “tuenada”, que llevará al cliente donde nos interese.

 

Borramos la Cache DNS del servidor Windows  wsrv12.profe.local

C:\>ipconfig /flushdns

Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

A continuación realizaremos una consulta DNS. La petición en este caso la realizaremos utilizando el comando nslookup. Lo hacemos de esta manera para tener más recursos que el simple ping de toda la vida.

Preguntamos directamente al servidor dns de google (8.8.8.8) por el registro www.sport.es.

Muy Importante!!!!: antes de generar estos comandos, activaremos Wireshark en el propio Servidor Windows. De esta forma podremos capturar todas las tramas generadas.

C:\>nslookup www.sport.es 8.8.8.8

Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    a1726.g1.akamai.net
Addresses:  84.53.132.200
            84.53.132.203
Aliases:  www.sport.es
          www.grupozeta.es.edgesuite.net

Como siempre, veremos infinidad de tramas. Adecuadamente filtradas obtendremos el resultado deseado:

Filtro wireshark:

(ip.addr eq 192.168.50.1 and ip.addr eq 8.8.8.8) and (udp.port eq 55407 and udp.port eq 53)

DNS query (la pregunta)

Aquí podemos ver una consulta estándar DNS. A parte de las MAC’s, IP’s y puerto UDP, es interesa ver la información que aparece en la capa de aplicación, donde vemos claramente que está preguntando por la dirección IP de www.sport.es.

 

DNS response (la respuesta)

Aquí vemos la respuesta. También de forma clara vemos que en la información de la capa de aplicación, aparece la respuesta (Answers) con la información. Recordar que la respuesta puede ser múltiple, es decir, varias IP’s asignadas a un mismo nombre lógico. Esto sucede en caso de tener las máquinas redundadas.

El objetivo… ser capaces de inyectar una respuesta dns adecuadamente preparada. Con una IP de un servidor nuestro, sobre el que colocaremos una Web falsa para que el usuario despistado coloque sus datos: nombre y contraseña.

¿Cómo funcionan ARP?

ARP, o Addres Resolution Protocol, tiene un función clave en la entrega de paquetes IP a nivel de red.

Sabemos que una dirección IP, es una dirección de capa 3 –Red-.  Es necesaria para cualquier proceso de comunicación IP. Ahora bien, cuando un dispositivo de red debe entregar un paquete IP a otro dispositivo de su misma red (recalco, de su misma red), necesita la dirección MAC del ordenador destino, dirección de capa 2 o enlace, para poder entregarle el paquete.

Aquí es donde entra en funcionamiento el protocolo ARP.  Si la dirección MAC no la tenemos en la tabla Arp Cache, datos que podemos comprobar con el comando arp -a en Windows , el ordenador origen lanzará una petición ARP Request a toda su red,  MAC destino a FF:FF:FF:FF:FF:FF de capa 2, esperando que el ordenador destino le responda con una trama ARP reply, con la MAC. El resto de ordenadores no responderá a dicha petición.

Veamos la secuencia de tramas generadas por el siguiente, y sencillo, script de Windows, que ejecutaremos desde wsrv12.profe.local

arpsample.bat 

@echo off
cls
ipconfig /flushdns
arp -d
ping -n1 gkali.profe.local
ping -n1 www.cocacola.com
arp -a

Este simple y pequeño script borra la tabla arp, y genera dos peticiones arp. La primera por la MAC del servidor gKali, la segunda por la MAC del Gateway, ya que la máquina www.cocacola.com está fuera de nuestra red, y por lo tanto el destinatario de entrega del paquete es el Gateway de nuestra red.

C:\MITM>arpsample.bat

Haciendo ping a gkali.profe.local [192.168.50.100] con 32 bytes de datos:

Respuesta desde 192.168.50.100: bytes=32 tiempo<1m TTL=64

Estadísticas de ping para 192.168.50.100:

    Paquetes: enviados = 1, recibidos = 1, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 0ms, Máximo = 0ms, Media = 0ms

Haciendo ping a a1128.g2.akamai.net [185.43.180.160] con 32 bytes de datos:

Respuesta desde 185.43.180.160: bytes=32 tiempo=10ms TTL=58

Estadísticas de ping para 185.43.180.160:

    Paquetes: enviados = 1, recibidos = 1, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 10ms, Máximo = 10ms, Media = 10ms

Interfaz: 192.168.50.1 --- 0xb

  Dirección de Internet   Dirección física      Tipo
  192.168.50.254          00-0c-29-a6-aa-24     dinámico
  192.168.50.100          00-0c-29-d9-f8-31     dinámico

La simple de todo, es que muchos de los protocolos de red siguen siendo el estándar de hace años, sin mejoras, y por definición inseguros.

Todo el truco del MITM está por aprovechar el funcionamiento poco seguro de ARP, ya que si generamos tramas ARP Reply diciendo que la MAC del Gateway es nuestra máquina ( el gKali atacante ), la victima aprende sin más… Sin pedir ningún tipo de credencial a la trama que le llega. Por lo tanto, conseguimos cambiar todo el tráfico de salida hacía Internet vía Gateway, hacia nuestra máquina (gKali) donde lo trataremos adecuadamente… Es un decir J

Próximo capítulo toca aplicar todos estos conocimientos en bien de entender las cosas,  protegerlas, y no aprovecharlas para delitos tipificados por ley.

En breve  MITM (DNS Spoofing) Parte  II Ataque DNS Spoofing con Kali.2017

 

You may also like

Leave a Comment