Objetivos
El objetivo principal de este documento consiste en concienciar a todas aquellas organizaciones de la importancia de la confidencialidad de sus relaciones corporativas, más allá del contenido de las mismas.
El hecho de que su empresa pueda conocer que la competencia directa establece comunicaciones electrónicas con sus principales clientes, proveedores y/o socios, así como estadísticas de la frecuencia de las comunicaciones, puede desencadenar, en primera instancia, cierta desconfianza, pero en cualquier caso a nadie le interesa que esta información esté disponible a terceros sin autorización. Se puede tomar la información de este documento como referencia para el estudio de las relaciones sociales, mediante correo electrónico, y la consiguiente obtención de un arbol de relaciones entre una organización y sus posibles clientes. Esta información puede ser crítica según en qué manos caiga, para un posterior análisis off-line y estrategia comercial aplicada en base a dicha información.
No está de más insistir otra vez en que cualquier atacante puede obtener dicha información si no se toman las medidas oportunas.
Consideraciones previas
El DNS (acrónimo de Domain Name System), es un sistema jerarquico para traducir los nombres de los ordenadores en direcciones IP numéricas, realizando búsquedas de datos de uso general y distribuido.
Es norma habitual que las organizaciones con un mínimo de infraestructura IT gestionen sus propios dominios, utilizando así sus propios servicios de DNS. En este marco los usuarios de la organización utilizarán frecuentemente dichos servicios cada vez que necesiten resolver algún dominio:
- Ver una página web
- Intercambio de correo electrónico (En el análisis de este servicio se centra este documento)
- Cualquier otra aplicación de usuario que requiera comunicarse con un dominio concreto.
Como nota de interés, hay aplicaciones de sistema bien conocidas que requieren acceso a Internet periódicamente, como pueden ser:
- Actualizaciones de antivirus
- Actualizaciones de sistemas
- Algunos tipos de Malware, etc.
Con lo que la explotación con éxito del acceso a los registros DNS de una empresa puede hacerse una idea de qué antivirus utiliza la organización atacada, que sistemas operativos emplea, con qué frecuencia se actualizan, etc.
Un dominio sólo es conocido de forma permanente por uno o más servidores de DNS.
Veamos un ejemplo:
cluster1_node22:~ rblacb16$ dig hotmail.com NS
; <<>> DiG 9.2.2 <<>> hotmail.com NS
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28123
<br>;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5
;; QUESTION SECTION:
;hotmail.com. IN NS
;; ANSWER SECTION:
hotmail.com. 85515 IN NS ns4.msft.net.
hotmail.com. 85515 IN NS ns5.msft.net.
hotmail.com. 85515 IN NS ns1.msft.net.
hotmail.com. 85515 IN NS ns2.msft.net.
hotmail.com. 85515 IN NS ns3.msft.net.
;; ADDITIONAL SECTION:
ns4.msft.net. 118368 IN A 207.46.66.75
ns5.msft.net. 118368 IN A 65.55.238.126
ns1.msft.net. 118368 IN A 207.68.160.190
ns2.msft.net. 118368 IN A 65.54.240.126
ns3.msft.net. 118368 IN A 213.199.144.151
;; Query time: 137 msec
;; SERVER: 80.58.61.250#53(80.58.61.250)
;; WHEN: Sun Apr 16 13:28:53 2006
;; MSG SIZE rcvd: 207
Podemos comprobar que el dominio hotmail.com posee 5 servidores de DNS los cuales conocen permanentemente la información relativa al servicio.
Cuando desde una organización corporativa con servidor de DNS propio se envía un e-mail a alguna cuenta de correo electrónico bajo el dominio hotmail.com, pueden distinguirse dos casos de estudio:
1.- Que la información necesaria ya se encuentre almacenada en el DNS corporativo, con lo cual el sistema no aplicará recursividad hacia otros servidores de DNS para obtener la información requerida.
2.- Que la información requerida no se encuentre en el DNS corporativo, con lo cual se realizará una búsqueda recursiva en otros servidores de DNS. Una vez encontrada esta información, será propagada hacia nuestro DNS corporativo por un tiempo finito.
Podemos saber durante cuánto tiempo permanecerá la información solicitada en nuestro servidor de DNS preguntándole directamente a un servidor DNS autoridad del dominio hotmail.com:
cluster1_node22:~ rbclab16$ dig @ns1.msft.net hotmail.com MX +norecursive
; <<>> DiG 9.2.2 <<>> @ns1.msft.net hotmail.com MX +norecursive
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1890
<br>;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 16
;; QUESTION SECTION:
;hotmail.com. IN MX
;; ANSWER SECTION:
hotmail.com. 3600 IN MX 5 mx3.hotmail.com.
hotmail.com. 3600 IN MX 5 mx4.hotmail.com.
hotmail.com. 3600 IN MX 5 mx1.hotmail.com.
hotmail.com. 3600 IN MX 5 mx2.hotmail.com.
;; ADDITIONAL SECTION:
mx3.hotmail.com. 3600 IN A 65.54.244.72
mx3.hotmail.com. 3600 IN A 65.54.245.72
mx3.hotmail.com. 3600 IN A 65.54.244.200
mx3.hotmail.com. 3600 IN A 64.4.50.179
mx4.hotmail.com. 3600 IN A 65.54.244.232
mx4.hotmail.com. 3600 IN A 65.54.245.104
mx4.hotmail.com. 3600 IN A 65.54.190.179
mx4.hotmail.com. 3600 IN A 65.54.244.104
mx1.hotmail.com. 3600 IN A 65.54.244.136
mx1.hotmail.com. 3600 IN A 65.54.244.8
mx1.hotmail.com. 3600 IN A 64.4.50.50
mx1.hotmail.com. 3600 IN A 65.54.245.8
mx2.hotmail.com. 3600 IN A 65.54.244.168
mx2.hotmail.com. 3600 IN A 65.54.244.40
mx2.hotmail.com. 3600 IN A 65.54.190.50
mx2.hotmail.com. 3600 IN A 65.54.245.40
;; Query time: 233 msec
;; SERVER: 207.68.160.190#53(ns1.msft.net)
;; WHEN: Sun Apr 16 13:35:06 2006
;; MSG SIZE rcvd: 365
La respuesta a esta consulta nos devuelve un listado de los servidores de correo que gestionan el dominio hotmail.com:
mx1.hotmail.com.
mx2.hotmail.com.
mx3.hotmail.com.
mx4.hotmail.com.
Los cuales permanecerán almacenados en nuestro servidor de DNS corporativo durante el tiempo indicado: en este caso, 3600 segundos (1 hora).
Una vez sabemos a qué servidores preguntar, de primera mano, la información relativa al dominio hotmail.com, podemos ir un poco mas allá.
Metodología
En el marco descrito en este documento, cualquiera puede realizar una consulta contra la caché de nuestro servidor de DNS, con estas premisas base de antemano:
1.- Si no hay indicios del registro MX del dominio rastreado (en nuestro ejemplo hotmail.com), podemos afirmar que en la última hora no se ha enviado e-mail alguno desde la organización objetivo del estudio a ninguna cuenta del dominio hotmail.com:
cluster1_node22:~ rbclab16$ dig @ns0.universalchem.com hotmail.com MX +norecursive
; <<>> DiG 9.2.2 <<>> @ns0.universalchem.com hotmail.com MX +norecursive
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45932
<br>;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; QUESTION SECTION:
;hotmail.com. IN MX
;; AUTHORITY SECTION:
com. 171485 IN NS K.GTLD-SERVERS.NET.
com. 171485 IN NS L.GTLD-SERVERS.NET.
com. 171485 IN NS M.GTLD-SERVERS.NET.
com. 171485 IN NS A.GTLD-SERVERS.NET.
com. 171485 IN NS B.GTLD-SERVERS.NET.
com. 171485 IN NS C.GTLD-SERVERS.NET.
com. 171485 IN NS D.GTLD-SERVERS.NET.
com. 171485 IN NS E.GTLD-SERVERS.NET.
com. 171485 IN NS F.GTLD-SERVERS.NET.
com. 171485 IN NS G.GTLD-SERVERS.NET.
com. 171485 IN NS H.GTLD-SERVERS.NET.
com. 171485 IN NS I.GTLD-SERVERS.NET.
com. 171485 IN NS J.GTLD-SERVERS.NET.
;; Query time: 119 msec
;; SERVER: 217.149.150.133#53(ns1.universalchem.com)
;; WHEN: Sun Apr 16 13:00:48 2006
;; MSG SIZE rcvd: 253
Podemos comprobar que no hay respuesta alguna a nuestra petición.
2.- Si existen rastros del registro MX del dominio rastreado en la caché del servidor de DNS comprometido, podemos asegurar que al menos se ha enviado un e-mail, en nuestro ejemplo a una cuenta del dominio hotmail.com.
cluster1_node22:~ rbclab16$ dig @ns0.universalchem.com hotmail.com MX +norecursive
; <<>> DiG 9.2.2 <<>> @ns0.universalchem.com hotmail.com MX +norecursive
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44174
<br>;; flags: qr ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 19
;; QUESTION SECTION:
;hotmail.com. IN MX
;; ANSWER SECTION:
hotmail.com. 3217 IN MX 5 mx4.hotmail.com.
hotmail.com. 3217 IN MX 5 mx1.hotmail.com.
hotmail.com. 3217 IN MX 5 mx2.hotmail.com.
hotmail.com. 3217 IN MX 5 mx3.hotmail.com.
;; AUTHORITY SECTION:
hotmail.com. 62098 IN NS ns4.msft.net.
hotmail.com. 62098 IN NS ns5.msft.net.
hotmail.com. 62098 IN NS ns1.msft.net.
hotmail.com. 62098 IN NS ns2.msft.net.
hotmail.com. 62098 IN NS ns3.msft.net.
;; ADDITIONAL SECTION:
mx1.hotmail.com. 3217 IN A 65.54.244.136
mx1.hotmail.com. 3217 IN A 65.54.245.8
mx1.hotmail.com. 3217 IN A 64.4.50.50
mx1.hotmail.com. 3217 IN A 65.54.244.8
mx2.hotmail.com. 3217 IN A 65.54.245.40
mx2.hotmail.com. 3217 IN A 65.54.190.50
mx2.hotmail.com. 3217 IN A 65.54.244.40
mx2.hotmail.com. 3217 IN A 65.54.244.168
mx3.hotmail.com. 3217 IN A 65.54.244.72
mx3.hotmail.com. 3217 IN A 65.54.244.200
mx3.hotmail.com. 3217 IN A 65.54.245.72
mx3.hotmail.com. 3217 IN A 64.4.50.179
mx4.hotmail.com. 3217 IN A 65.54.245.104
mx4.hotmail.com. 3217 IN A 65.54.190.179
mx4.hotmail.com. 3217 IN A 65.54.244.104
mx4.hotmail.com. 3217 IN A 65.54.244.232
ns1.msft.net. 172417 IN A 207.68.160.190
ns2.msft.net. 172417 IN A 65.54.240.126
ns3.msft.net. 172417 IN A 213.199.144.151
;; Query time: 209 msec
;; SERVER: 217.125.31.138#53(ns0.universalchem.com)
;; WHEN: Sun Apr 16 13:09:41 2006
;; MSG SIZE rcvd: 511
Como vemos, encontramos evidencias de que en la caché del servidor de DNS comprometido, se ha enviado correo electrónico desde la organización comprometida a algún email de hotmail.
Pero no solo tenemos acceso a este dato; además podemos saber a que hora exacta fue enviado:
En efecto, dado que conocemos que dicha información permanece 3600 segundos en el servidor de DNS comprometido, y vemos que dicha información expira en 3217 segundos, podemos asegurar que al menos un e-mail fue enviado hace exactamente 383 segundos (6 minutos y 23 segundos).
Explotación
Una vez tenemos identificados los siguientes puntos:
- Servidores de DNS corporativos de las organizaciones a analizar. A partir de ahora S.
- Listado de dominios de potenciales clientes, proveedores, socios, etc. A partir de ahora C.
- Tiempo en segundos durante los cuales los registros MX de C permanece en la caché de un servidor de DNS. A partir de ahora T
A modo de prueba de concepto, he diseñado una aplicación respaldada por una BBDD donde se almacenan cíclicamente las variables S, C y T, desde la que se realiza una correlación de existencias de C en S, muestreando periódicamente (según el margen de error que se quiera tener) cada tiempo T transcurrido.
Tanto si no existe ninguna referencia de C en S, como cuando ha expirado T, muestreando periódicamente la cache de S y calculando los tiempos transcurridos hasta detectar una nueva entrada de C en S, se obtiene con qué frecuencia S se comunica con C, variable F de aquí en adelante.
Mientras no haya expirado T, no es necesario realizar el muestreo, ya que T no se actualiza cuando aún no ha expirado.
Bajo este marco, analizando la situación durante un tiempo suficiente para garantizar unas estadísticas con medias lo mas exactas posibles, obtenemos un árbol de relaciones cruzadas entre diversas organizaciones, para un posterior análisis de seguridad.
Dentro de cada relación se pueden establecer pesos, en función de la frecuencia con la que dos organizaciones intercambian e-mail, y así extrapolar hasta que punto esta relación es más o menos intensa.
Soluciones Propuestas
Limitar el acceso a la caché del servidor de DNS corporativo a un ámbito local, con el fin de reducir la exposición a este tipo de ataques.
Denegar cualquier tipo de petición no autoritativa
Conclusiones
El objetivo de este documento se limita sólo al ámbito del intercambio de correo electrónico, pero bajo este mismo sistema, sería trivial realizar un estudio social global sobre las relaciones entre diferentes organizaciones u otras entidades, no solamente en el ámbito del correo electrónico.
Ninguna de las acciones mencionadas acarrea sanción legal, por realizarse un proceso de data-mining sobre datos expuestos públicamente en servicios con acceso público desde el exterior de una red corporativa hacia Internet, por lo que una organización sometida a este tipo de ataques no podrá emprender acciones legales con fundamento de ningún tipo.
Referencias
1. http://www.ietf.org/rfc/rfc1035.txt
2. http://www.openbsd.org/cgi-bin/man.cgi?query=dig
