DNS al Descubierto: Una Guía Esencial de Seguridad para Analistas 2

En la entrada anterior se vió información general del funcionamiento de DNS. A continuación, se describen las técnicas de análisis y los ataques DNS más comunes:

Desglose y Análisis de Nombres de Dominio

Para evaluar una solicitud de nombre de dominio, se puede separar el nombre de host en sus componentes principales: el Dominio de Nivel Superior (TLD), el nombre de dominio principal (como "Google" en google.com), y el subdominio (cualquier cosa por encima del dominio principal). Desglosar estos elementos individualmente puede ser muy útil para la detección.

• TLDs Maliciosos y Anómalos:

  • Algunos TLDs son inherentemente más propensos a ser maliciosos. TLDs como ".tk", ".ml", ".ga", ".cf", ".gq", ".win", ".vip" son ejemplos de aquellos que, aunque no son frecuentemente usados, están mucho más correlacionados con actividades maliciosas que TLDs comunes como ".com".
  • Los autores de malware a menudo utilizan estos TLDs menos frecuentes.
  • Los defensores pueden recopilar todos los TLDs visitados en su organización, ponerlos en un gráfico circular o tabla, e identificar cuáles son los más comunes (como ".com", ".net", ".gov"). Los TLDs que aparecen en la parte inferior de la lista, o aquellos que son "más raros", son los que merecen investigación.
  • Se pueden crear paneles de control en un SIEM (Security Information and Event Management) para mostrar todos los dominios que la gente visita que no son comunes (ej. excluyendo .edu, .gov), lo que actúa como una técnica de detección de anomalías.

• Reputación y Antigüedad del Dominio:

  • Los dominios más nuevos son generalmente más propensos a ser maliciosos. Un dominio visitado que fue creado en el último mes podría ser una señal de "malware".
  • Se puede consultar la fecha de creación de un dominio padre (usando servicios WHOIS, que proporcionan información del registrador). Aunque la Privacy Guard puede ocultar parte de la información, la fecha de creación generalmente no está cubierta y es útil.
  • Herramientas como domain_stats.py de Mark Baggett (disponible en GitHub de SANS Blue Team) pueden automatizar estas comprobaciones de edad y reputación.
  • Se pueden usar fuentes externas como VirusTotal, ThreatCrowd o TrustedSource para consultar la reputación de un dominio (categorización, nivel de riesgo). Los dominios categorizados como "maliciosos" o de "alto riesgo" deben ser bloqueados.

• Aleatoriedad y Longitud del Dominio:

• Los dominios que parecen aleatorios son casi siempre maliciosos. El malware a menudo utiliza algoritmos de generación de dominios (DGA) para eludir las listas de bloqueo y evitar ser dado de baja.
• La longitud del dominio también es un indicador: dominios más largos son más propensos a ser generados de forma procedimental y ser maliciosos. Pocas personas escriben manualmente nombres de dominio de 64 caracteres.
• Herramientas como FREAK.PY y Freak Server de Mark Baggett pueden evaluar la aleatoriedad de los nombres de dominio comparándolos con datos de entrenamiento (ej. un lenguaje como el inglés). Un SIEM puede enviar solicitudes a FREAK Server y recibir un puntaje de aleatoriedad.
• Se puede hacer un análisis retrospectivo volcando los registros DNS de una semana del SIEM y procesándolos con FREAK.PY para encontrar los dominios más aleatorios o más largos.

Técnicas de Ataque DNS

Los atacantes emplean varias tácticas que abusan de la infraestructura DNS:

• Búsquedas Inversas Basadas en IP y DNS Pasivo:

  • Las búsquedas de registros PTR (puntero) para direcciones IP (buscando el nombre de dominio asociado a una IP) a menudo no son muy útiles o pueden ser engañosas, ya que las relaciones entre IP y dominio son de "muchos a muchos" y pueden cambiar. Es decir, una IP puede apuntar a cualquier dominio y esto puede cambiar en cualquier momento.
  • El DNS Pasivo es una técnica más efectiva. Consiste en consultar una fuente que ha registrado muchas búsquedas de registros A (que mapean un dominio a una IP) en el pasado. Esto permite ver a qué direcciones IP resolvió un dominio en un momento dado en el pasado. Esto es crucial para investigaciones retrospectivas, si una IP o dominio malicioso ha cambiado su mapeo desde el momento de un incidente.
  • Precaución con IPs Compartidas: Los atacantes pueden apuntar sus dominios maliciosos a direcciones IP "buenas", como las de Google. Bloquear la IP de un sitio malicioso sin verificar qué otros dominios comparten esa IP podría resultar en el bloqueo accidental de servicios legítimos y críticos.
  • La identificación de la Organización de un Sistema Autónomo (ASN) al que pertenece una dirección IP puede ser una pista para determinar si una IP es confiable (ej. si una IP está asociada con Google o Netflix, es menos probable que deba ser bloqueada que una desconocida). Sin embargo, incluso IPs de Amazon o Microsoft podrían ser potencialmente maliciosas.

• Alojamiento Compartido (Shared Hosting):

  • El alojamiento compartido permite que miles de sitios web compartan una misma dirección IP. Si un sitio en un alojamiento compartido es malicioso, bloquear su IP también bloquearía a otros miles de sitios web.
  • Generalmente, los servicios empresariales legítimos no se alojan en servidores compartidos. Por lo tanto, en la mayoría de los casos, es seguro bloquear la dirección IP completa de un sitio malicioso en un alojamiento compartido, especialmente si sus propios registros de proxy muestran que no se utiliza ninguno de los otros dominios en esa IP. Se debe revisar el registro de proxy para evaluar el impacto. Las Redes de Distribución de Contenido (CDNs), sin embargo, son una situación diferente y requieren más cuidado al bloquear IPs, ya que pueden alojar contenido legítimo importante.

• Descubrimiento (Enumeración) DNS:

  • Los atacantes realizan un descubrimiento activo intentando un diccionario de palabras como subdominios (ej. vpn.wifilab.com) y buscando registros A para identificar hosts activos. Cualquier host en línea es un objetivo.
  • Los defensores pueden detectar esto buscando cientos o miles de búsquedas DNS en un período muy corto, probablemente desde una única IP de origen, y la mayoría de ellas terminando en respuestas NXDOMAIN (dominio inexistente). Esto puede ser un indicio de que un atacante está "interesado" en la organización.
  • Los intentos de transferencia de zona (Zone Transfer) son una técnica de enumeración de DNS antigua y es poco probable que aún funcionen en entornos modernos.

• Uso de Servidores DNS No Autorizados:

  • Es una mala práctica que los usuarios configuren sus dispositivos para usar servidores DNS públicos externos (como 8.8.8.8 de Google o 1.1.1.1 de Cloudflare) en lugar de los servidores DNS internos de la empresa. Esto puede permitirles eludir los controles de seguridad de la red.
  • La detección se puede realizar monitoreando el tráfico UDP al puerto 53 hacia direcciones IP externas que no sean los servidores DNS de la organización. Las fuentes de datos para esto incluyen registros de firewall de punto final, Netflow, IDS, y EDR. Las alertas generadas deben ser investigadas.

• Domain Shadowing (Modificación de Registros DNS):

  • Los atacantes pueden comprometer la cuenta de un administrador de DNS para modificar o agregar registros DNS maliciosos.
  • Esto es extremadamente peligroso, ya que pueden cambiar el registro A de un dominio principal de una organización (ej. wifilab.com) para que apunte a un servidor malicioso que aloja una página clonada (ej. un portal VPN falso).
  • La autenticación de dos factores (2FA) para los administradores de DNS es crucial.
  • La detección se puede lograr monitorizando los cambios en el archivo de zona DNS (usando un IDS de host como Tripwire). Alternativamente, se pueden usar reglas en el SIEM para alertar cuando se vean nuevos subdominios que nunca antes se habían registrado para un dominio específico.

• DNS Tunneling:

  • El DNS tunneling es una técnica muy efectiva y difícil de detectar donde el malware codifica datos (ej. archivos, salida de comandos) en la porción de subdominio de una solicitud DNS y los envía a un servidor de nombres controlado por el atacante. La respuesta también puede contener datos codificados.
  • Es un canal de exfiltración de datos perfecto porque el DNS siempre tiene que funcionar. Aunque es un canal lento debido a las limitaciones de datos por solicitud, está garantizado que funciona.
  • Herramientas como DNS Cat 2 e Iodine son utilizadas para este tipo de ataque.
  • Detección de DNS Tunneling:
    • Solicitudes muy largas y de aspecto aleatorio: Los atacantes intentan "meter" la mayor cantidad de datos posible en cada solicitud.
    • Alta frecuencia de solicitudes: Para compensar la baja cantidad de datos por solicitud, el malware realiza miles de solicitudes constantes. Un aumento repentino y masivo en las solicitudes DNS de una fuente es sospechoso.
    • Subdominios únicos excesivos: Cada subdominio en el túnel debe ser único porque codifica diferentes partes de los datos. Se pueden visualizar los dominios padre que tienen la mayor cantidad de subdominios únicos en un SIEM para detectarlo.
    • Tipos de consulta inusuales: Aunque el tipo de registro (A, CNAME, TXT) no importa para la tunelización, el uso de registros NULL es una señal inmediata de problema, ya que nadie los utiliza salvo Iodine. Las laptops suelen hacer un 99% de solicitudes de registro A; cualquier otro tipo de consulta excesiva es anómala.
    • Dominio padre desconocido o cuestionable: La clave es si el dominio padre es desconocido o se sabe que es malicioso. Los controles de antivirus a veces usan tunelización DNS legítima (ej. Sophos Live Protection), que se diferencia por el dominio padre legítimo y el bajo volumen de consultas.

• Nombres de Dominio Internacionalizados (IDN) y Ataques Homoglifos:

• Los IDN permiten el uso de caracteres de otros idiomas en los nombres de dominio. El DNS subyacente solo soporta caracteres ASCII (a-z, 0-9, guion), por lo que los caracteres Unicode se codifican a un formato ASCII llamado Punycode.
• El peligro surge porque algunos caracteres de otros idiomas se parecen exactamente a los caracteres ASCII en inglés (ej. la "O" cirílica o griega que parece una "O" inglesa). Esto permite crear dominios de "apariencia idéntica" para ataques de phishing (ej. yоutube.com que en Punycode es xn--yutube-wqf.com).
• Todos los IDN codificados en Punycode comienzan con el prefijo xn--. Buscar este prefijo en los registros DNS y de proxy es una forma efectiva de identificar posibles ataques de homóglifos.
• El problema es que las aplicaciones de correo electrónico (Outlook, Gmail, móvil) suelen mostrar la versión Unicode (la de "apariencia idéntica"), y para cuando el usuario hace clic, puede ser demasiado tarde, incluso si el navegador muestra la versión Punycode.
• Incluso se pueden registrar dominios con emojis utilizando Punycode.

Consideraciones sobre el Registro y el Futuro del DNS

• Registro de Tráfico DNS:

  • La ubicación del registro es crucial. Si los registros se toman "upstream" (por ejemplo, desde un servidor de caché DNS más arriba en la cadena), la IP de origen registrada será la del servidor de reenvío, no el dispositivo original del cliente.
  • Para identificar el host infectado original, incluso si solo se tienen registros "upstream", se pueden correlacionar las solicitudes DNS con los registros de flujo de red (NetFlow) o de proxy que muestren conexiones inmediatas a la dirección IP resuelta.
  • Es recomendable crear una base de datos propia de DNS Pasivo a partir de los registros internos.

• El Futuro del DNS (DoH y DNSSEC):

  • DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT) son estándares emergentes que cifran las consultas DNS. DoH utiliza tráfico HTTP/2 sobre el puerto 443.
  • Esto es beneficioso para la privacidad, pero perjudicial para la visibilidad de la seguridad de la red, ya que el tráfico DNS se vuelve opaco sin la desencriptación de TLS.
  • Aunque el tráfico esté cifrado con DoH, los registros del propio servidor DNS seguirán mostrando lo que la gente está buscando.
  • DNSSEC (DNS Security Extensions) es un estándar que firma las respuestas DNS digitalmente para verificar su autenticidad e integridad. Esto asegura que la respuesta provenga del dominio real y no haya sido manipulada.

Herramientas y Metodología para el Análisis DNS

• dig: Una herramienta de línea de comandos para realizar solicitudes DNS manuales y ver los resultados.
• @1.1.1.1 para usar este servidor para la resolución.
• dell.com el dominio que queremos resolver.
• A queremos la resolucion en formato IPv4

    

    Podemos intentar hacer al busqueda inversa, encontrar el dominio desde la IP, aunque como se comentaba anteriormente este método no es siempre fiable por que la resulución depende del propietario de la IP:

• Wireshark: Para visualizar y analizar capturas de paquetes (PCAPs) de tráfico DNS. Permite ver los detalles de los paquetes en cada capa de red.

Vamos analizar la peticion anterior. Para ellos podemos aplicar el siguiente filtro:

dns.qry.name == "dell.com" && (dns.qry.type == 1

Mediante esos valores hexadecimales podemos determinar la respuesta de la petición.

Podemos hallar diferentes tipos de registra modificado el valor correspondiente. Para encontrar registros TXT podemos aplicar este filtro:

(dns.qry.type == 16)

En resumen, los defensores deben entender la arquitectura de su red y los puntos de visibilidad, así como las múltiples formas en que el DNS puede ser explotado. La capacidad de desglosar y analizar los componentes de un dominio, junto con el uso de herramientas de registro, análisis y visualización, es fundamental para detectar y responder a los ataques basados en DNS.