Ciberseguridad Industrial, breve introducción…

Cuando hablamos de Ciberseguridad, generalmente lo hacemos desde el punto de vista tradicional de los entornos IT. Esto es, proteger de ciberamenazas, ciberdelincuentes, y demás términos de similar índole; la información contenida dentro de los sistemas información interconectados por medio de redes de comunicaciones de mayor o menor alcance. El objeto principal de custodia aquí es la información. Ésta puede venir de muy diversas maneras y formatos, desde un documento, hasta los registros en una Base de Datos, pasando por comprometedores correos electrónicos que por una razón u otra no interesa que salgan a luz.

Como decía, esto es el mundo IT. Ahora bien, ¿qué ocurre con los entornos OT? Aquí el principal activo no es la información sino la disponibilidad de las infraestructuras y la continuidad operacional de las instalaciones. Aquí los equipos a proteger no serán los servidores de ficheros, Bases de Datos, correo electrónico; sino los sistemas de Control y Automatización (IACS); Supervisión, Control y Adquisición de Datos (SCADA); Sensores, Actuadores, Autómatas Programables, etc. Aquí ya no es si se pierde o se compromete un dato; es qué pasa si las instalaciones dejan de funcionar por tal o cual motivo.

Así pues las “Operational Technologies”, o Tecnologías de Operación son los términos con los que nos referimos al conjunto de dispositivos, funcionalidades y procesos que participan en el desarrollo de la actividad de un determinado sector. Su indisponibilidad puede provocar no sólo un impacto significativo a la empresa que las posee y al entorno donde ésta pueda estar ubicada.

¿Por qué esto es así? Los Sistemas de Control y Automatización Industrial están presentes no sólo en fábricas de producción en serie de un determinado producto sino también en lo que conocemos como Infraestructuras Críticas. Entendiendo por estas últimas:

“Las infraestructuras estratégicas (es decir, aquellas que proporcionan servicios esenciales) cuyo funcionamiento es indispensable y no permite soluciones alternativas, por lo que su perturbación o destrucción tendría un grave impacto sobre los servicios esenciales”. 

Dentro de la Legislación española se han definido 12 sectores estratégicos, los cuales son:

  1. Administración.
  2. Agua.
  3. Alimentación.
  4. Energía.
  5. Espacio.
  6. Industria Química.
  7. Industria Nuclear.
  8. Instalaciones de Investigación.
  9. Salud.
  10. Sistema Financiero y Tributario.
  11. Tecnologías de la Información y las Comunicaciones (TIC).
  12. Transporte.

Una indisponibilidad de una cadena de montaje como la que puede ser la del sector de la Automoción puede generar una pérdida económica de equis miles o millones de euros; sin embargo si esto sucede en una central nuclear las consecuencias pueden ser bien distintas. No sólo por la pérdida de servicio eléctrico sino por el impacto que puede tener sobre la población civil y medioambiental.

Así pues podríamos definir algunas posibles consecuencias:

  1. Reducción o pérdida de la producción.
  2. Daños en el equipamiento.
  3. Lesiones de personas.
  4. Liberación, desvío o robo de materiales peligrosos (tóxicos, combustibles, etc.)
  5. Daños ambientales.
  6. Violación de normativa y legislación vigente.
  7. Contaminación de productos y entornos.
  8. Responsabilidades legales, penales o civiles.
  9. Pérdida de información confidencial o de propiedad intelectual.
  10. Pérdida de imagen o de la confianza.

Estas consecuencias tendrán su origen en algún tipo de incidencia. Éstas podrán ser catalogadas como no intencionadas, esto es, fallo o anomalía natural en los dispositivos; o bien, de carácter intencionado, es decir por la acción hostil de un software o actividad humana sobre los equipos. A continuación se citan alguna de ellas:

  1. Denegación de Servicio en los servicios activos en las redes de control o causando cuellos de botella a la hora de transferir información.
  1. Cambios no autorizados realizados en instrucciones de programas en PLCs, RTUs, DCS o controladores SCADA, parámetros de alarmas, ejecución de comandos no autorizados en equipos de control que lleguen a dañar el propio equipo, paradas no contempladas en procesos o incluso deshabilitar el equipo de control.
  1. Falsificación de información y visualización incorrecta a los operadores encargados de controlar el sistema.
  1. Modificación de software, configuración y parámetros de sistemas.
  1. Introducción en el sistema de malware (por ejemplo virus, gusanos, troyanos).

 

Así pues urge la necesidad de proteger los procesos, dispositivos y elementos que intervienen en todos procesos de automatización y control, de esos riesgos y amenazas de las que pueden ser objeto.

Como todo elemento tecnológico pueden disponer de errores en su diseño, programación o instalación; poseyendo vulnerabilidades y “bugs” que faciliten enormemente el éxito de las operaciones.

El gusano Stuxnet hizo abrir los ojos a muchas Naciones y empresas en los distintos sector de los riesgos que corrían si no tomaban las precauciones necesarias y sin duda supuso un antes y un después:

Stuxnet

Pero no ha sido el único, tiene otros hermanos con igual mala leche como Duqu, DragonFly, Havex, Black Energy, etc. y seguirán apareciendo más en los próximos meses. Esto va en aumento…

¿Quién puede tener interés en atacar esto tipo de entornos? Las respuestas pueden ser muy distintas, desde empleados descontentos, empresas de la competencia, grupos Hacktivistas, terroristas y delincuencia organizada, Agencias de Inteligencia, Gobiernos, etc. Obviamente hay un móvil y una razón por la cual llevar a cabo dichos propósitos.

Como contramedida a estos riesgos en materia de Infraestructuras Críticas existe por un lado el CNPIC (Centro Nacional de Protección de Infraestructuras Críticas), cuyo objetivo es  impulsar, coordinar y supervisar todas las actividades que tiene encomendadas la Secretaría de Estado de Seguridad del Ministerio del Interior en relación con la protección de las infraestructuras críticas españolas según la Ley 8/2011 y Real Decreto 704/2011

Además de ello existen otros organismos de carácter público y privado encargados de llevar a cabo distintas acciones sobre este ámbito. Algunos de ellos son:

España:

INCIBE, Instituto de Ciberseguridad de España.

CCI, Centro de Ciberseguridad Industrial

A nivel Europeo:

ENISA, European Union Agency for Network and Information Security

EE.UU:

ICS-CERT, Industrial Control System Cyber Emergency Response Team.

Así pues ya tenemos na primera aproximación a lo que conocemos como “Ciberseguridad Industrial” e iremos desarrollando en artículos sucesivos. Todo es empezar…

Un saludo.

Publicado artículo sobre “Cybermaps” en Tic Tac Blogs

Hola de nuevo.

Desde hace algún tiempo un amigo me había invitado a publicar alguna entrada en el blog que lleva junto con otros colaboradores.

Entre una cosa y otra, no había sido posible hasta ahora y para la ocasión elaboré una sobre los llamados “Cybermaps”. Esas representaciones gráficas de ataques, amenazas y acciones diversas que suceden en “la red” en tiempo real (o casi…).

Aquí os dejo el link donde podéis encontrarlo y, aprovechando que andáis por la zona os invito a que echéis un vistazo al resto de artículos que tienen publicados la gente de TIC TAC BLOGS. Os vais a reir, descubrir nuevos grupos musicales, novedades tecnológicas de lo más variadas, entre otras muchas cosas…. No os doy más pistas, pasaros y descubrirlo por vosotros mismos.

A lo dicho, un saludo y dentro de poco nos vemos en la siguiente con otra entrada de Wi-Fi….

Teoría del Pentesting

En esta entrada voy a explicar un poco de teoría sobre lo que conocemos, o referimos como “Pentest”, “Pentesting” “Prueba de penetración” o conceptos similares.

Tenemos claro que todo administrador debe ser consciente del nivel de seguridad que tiene aquello que gestiona y de si se cumplen, o no, las políticas de la organización a la que pertenece. Esto no es sólo un trabajo a realizar cada equis cantidad de tiempo sino que debe estar acompañado de un trabajo diario, concienciación de usuario, buena labor del personal de IT, compromiso, colaboración entre sectores, y un largo etcétera.

Actualmente existen estándares definidos como OSSTMM ; ISSAF ; OWASP ; WASC-TC ; PTES ; OWISAM ; que abordan los pasos, técnicas y tecnologías para llevar a cabo auditorias en distintas ámbitos, ya que como es lógico cada cual tiene sus propias características y necesidades.

Lo ideal sería contratar los servicios de empresas especializadas en el área concreta, pero por desgracia esto no siempre es posible y por tanto, al margen que nuestra profesión nos lo requiera, tenemos que tener claro el marco general sobre el que se llevan a cabo las auditorías de seguridad o pruebas de penetración para conocer el “nivel de salud” de nuestra organización.

Antes de abordar ese marco han de definirse qué se entiende por “Pentesting”, “Penetration Testing” o “Pentest”. Dichos palabras hacen referencia al proceso que se sigue para evaluar en profundidad los niveles de seguridad de algún elemento “TIC”. Así mismo, una metodología consiste en el conjunto de  reglas, prácticas y procedimientos  que se emplean  y utilizan durante el transcurso de una auditoría. Si unificamos ambos términos, obtendríamos lo que denominamos “Metodología de Pentesting” que no es más que los pasos a seguir empleando técnicas, ideas, herramientas y prácticas para evaluar el nivel real de seguridad del que disponen redes, aplicaciones, sistemas o combinación de todas, o parte, de ellas en un entorno definido. Bien de forma puntual o dentro de un plan de evaluación de riesgos, un ejercicio de Pentesting puede considerarse como la forma más agresiva de conocer los niveles de segurida. No podemos pensar que todo son cuestiones técnicas o tecnológicas. También existe un factor de psicología, en todo esto. También hay que poner en práctica métodos que nos permitan obtener información de los empleados o responsables que nos puedan facilitar el acceso a la información que buscamos.

Dicho esto, el “Pentesting” puede realizarse  siguiendo dos enfoques. No sabemos nada de nuestra organización ni de los posibles objetivos, y poco a poco vamos descubriendo los sistemas, equipos, mapas de red, etc. hasta detectar posibles vulnerabilidades o deficiencias que puedan ser explotadas. Esto es lo que se conoce como “Black Box”, (Caja Negra). Por el contrario tenemos la “White Box” (Caja Blanca) que es justamente lo contrario. Previo al test, conocemos o tenemos información que nos puede facilitar mucho las cosas. A mitad de camino tenemos el “Grey Box” (Caja Gris) que no es más que una unión entre ambas.

Así mismo debemos tener presente que estas pruebas pueden realizarse de forma “interna”, esto es desde dentro de la propia organización o “externa”, desde fuera (Internet) hacia  dentro de ella.

En cualquier caso no debemos confundir los términos “Pentesting” con “Evaluación de vulnerabilidades”. Evaluar vulnerabilidades consiste en detectar aquellos “agujeros” en los sistemas, dispositivos de comunicaciones, aplicaciones, etc. que puedan ser explotadas por un posible atacante o programa malicioso (malware). Se constata que existen deficiencias y de cómo éstas deben ser corregidas, mediante actualizaciones, parches o configuraciones adicionales. Sin embargo el “Pentester” irá un paso más allá y tratará de explotarlas, escalará privilegios y mantendrá el acceso para un uso continuado o como puente a otras acciones.

A continuación abordaremos, de forma teórica, los pasos generales a seguir para llevar a cabo un “pentesting” y explicaré brevemente en qué consiste cada uno de ellos.

  • Definición de objetivos

Antes de ponernos a hacer nada tenemos que conocer el alcance de nuestras acciones, hasta donde vamos a llegar  y cuáles son nuestros intereses y los de la organización a la que vamos a realizar la prueba. Por ejemplo debemos dar respuesta a preguntas como:

¿El qué y cómo debería ser testeado?

¿Cómo de largo y profundo debe de ser la prueba?

¿Cuáles son los activos que más criticidad tienen para la organización a auditar?

  • Recolección de información

Una vez que ya sabemos hasta dónde vamos a llegar, contra qué, cómo de profunda va a ser la cosa, que elementos son los más importantes o relevantes para la empresa, es hora de ponerse a buscar información acerca de ella. En este punto el “Pentester” echará mano de foros, boletines, redes sociales, páginas web, registros públicos, buscadores, etc. etc. Esta información podrá ser desde dominios, subdominios, correos electrónicos, números de teléfono, cuentas de usuario, etc.

Descubrimiento de los objetivos

En esta fase tendremos que identificar el estado de la red, sistemas operativos,  aspectos relativos a la arquitectura de la red. Esto nos proporcionará una idea de las tecnologías y dispositivos que en ella se encuentran, así como qué equipo están activos y el papel que juegan en la red. Esto puede realizarse de forma activa, por ejemplo realizando un escaneo de la red;  o de forma pasiva conectando un esnifer de red como wireshark y ver el tráfico que llega y poder identificar o deducir el entorno en el que nos encontramos.

  • Enumeración de los objetivos

Aquí ya la cosa cambia, y vamos un paso adelante del paso anterior. Ahora tocará localizar los puertos abiertos (o cerrados, que también nos arroja información) y los servicios que en ellos se ejecutan. Conocido esto, se tratará de identificar sus respectivas versiones lo cual nos permitirá buscar posibles vulnerabilidades. Otra tarea de este puntos es identificar posibles equipos de seguridad como Firewalls o IDS/IPS que puedan detectar y anunciar nuestra presencia, con lo que un buen “Pentester” debe tener presente andar con sigilo y prudencia y no lanzar aplicaciones muy ruidosas que hagan saltar todas las alarmas.

  • Mapa de vulnerabilidades

Conociendo los equipos que hay, sistemas operativos, qué puertos tiene  abiertos, que servicios corren en ellos, sus versiones, etc. ahora toca saber si existen vulnerabilidades acerca de ellos. Aquí podremos consultar bases de datos públicas donde se publican muchas  todas ellas, para obtener más y lanzar algún escáner que otro.  Será la suma de ambas la que nos proporcione una visión más completa, ya que a partir de ahí podremos localizar algún tipo de exploit para poder explotarlas.

  • Ingeniería Social

Como decía en párrafos anteriores, no se trata sólo de cuestiones puramente técnicas, y es aquí cuando lo demostramos. El factor humano también es otro vector de ataque. El arte del engaño, de la persuasión, de la picaresca para obtener información o acceso a redes y sistemas es otro de los procedimientos a aplicar. Por ejemplo llamar por teléfono a algún técnico o administrador para obtener correos electrónicos, teléfonos o solicitar un reseteo de una contraseña que se “creía olvidada”.

  • Explotación de objetivos

Esta es una de las partes donde después de todo lo que nos lo hemos “currado”, empezamos a sacarle un partido practico. Trataremos, mediante el uso de algún exploit o bug, penetrar en algún sistema o equipo con el fin llevar a cabo una determinada acción como puede ser obtener abrir conexiones contra otros equipos, listado de usuarios, contraseñas, o lo que sea.

  • Escalada de privilegios

Una vez que hemos accedido a un sistema, el siguiente paso entre otros es escalar privilegios. Si robamos las credenciales de un usuario, lo más probable es que tenga limitados los accesos o permisos. Por ello, es importante tratar de adquirir los del “super usuario” o “root” para tratar de hacer o llegar donde los usuarios con menos no pueden.

  • Mantenimiento de acceso

Bien, ya tenemos todo, el acceso y todo lo demás. Pero una cosa que nos interesa es poder acceder a este sistema siempre que queramos o necesitemos, ¿no? Por ello garantizar el acceso es muy importante ya que con esto nos aseguraríamos la permanencia en él. ¿Cómo conseguirlo? Por ejemplo tratando de instalar alguna puerta trasera, tunelizando tráfico, etc.

  • Documentación e informes

Y aquí toca escribir. Obviamente todo lo hecho hasta ahora, tanto si hemos tenido éxito, o no, todo esto hay documentando y presentarlo tanto al cliente que ha contratado nuestros servicios o como informe para uso interno. En él dejaremos patente los métodos, técnicas, tecnologías, registros, tiempos de actuación, etc. Etc. Etc.

Para todos estos puntos anteriores existen un verdadero arsenal de herramientas y aplicaciones que podemos encontrar en distribuciones como Kali Linux o Bugtraq entre otras. No podemos decir que exista una varita mágica, cada cual hace lo suyo y ofrecen distintos resultados aunque hay muchas que son muy parecidas.

Ahora a buscar cuales pueden ser, practicar con ellas, y a seguir aprendiendo.

Distribuciones para seguridad y servicios de red

Que la seguridad es un elemento clave en cualquier entorno sea en infraestructuras de comunicaciones, informática o entornos industriales es algo que a esta altura del partido nadie se cuestiona.  Controlar el acceso a la red, los ficheros, gestionar los permisos y derechos de los usuarios, cifrado de comunicaciones, filtrado de contenidos, etc. etc. son algunas de tantas medidas que podremos adoptar para garantizar una seguridad global y proteger así nuestra información.

Como es costumbre no voy hablar de las configuraciones que nos ofrecen los Sistemas Operativos o aplicaciones sino que nos ceñiremos, como siempre, a las comunicaciones. Desde este punto de vista los firewalls e IDS/IPS juegan un papel clave. Deberemos empezar por tener muy claro dónde situarlos para proteger unos u otros segmentos de red en función de lo que allí tengamos. Mientras que los Cortafuegos permitirán o denegarán el tráfico dirigido equipos que prestan algún tipo de servicio; los IDS/IPS se encargarán de analizarlo y detectar posibles patrones de ataques o “movimientos” hostiles en nuestra red. Y si es posible, tomar alguna medida para bloquearlo.

Cada uno de nosotros tenemos una disciplina profesional definida, lo cual no quita que tengamos que saber de otras que circulan a nuestro alrededor. Todo lleva un aprendizaje previo, y con él un tiempo que puede no tengamos, al menos, para especializarnos todo que quisiéramos. Da igual si hablamos de tecnologías, comunicaciones, sistemas, aplicaciones, entornos,… todo lleva lo suyo. Por no hablar de las soluciones propietarias de fabricantes, que si Cisco saca tal o cual prestación, Juniper hace algo parecido con distinto nombre, etc. etc. vamos, la historia de nunca acabar.

Para facilitarnos las cosas, por suerte, existen algunos proyectos e iniciativas con los que podemos contar para que, con una menor inversión de tiempo y conocimientos, podamos acceder a ciertos sistemas, aplicaciones y funcionalidades. Tal es el caso de las distribuciones con un conjunto de herramientas dispuestas a cumplir con un fin concreto. Así como dentro del mundo de la seguridad y pentesting tenemos a “Kali” existen otras, las cuales están orientadas a la seguridad o servicios de red, que presento a continuación.

Firewalls

SmoothWall Firewall

M0n0wall

BrazilFW, Firewall and Router

IDS

SmoothSec

EasyIDS

Monitorización de redes

FAN, Fully Automated Nagios

Seguridad de redes

NST, Network Security Toolkit

Router

BSD Router Distribution

En el siguiente enlace os dejo un listado que podréis encontrar en Wikipedia donde se incluyen bastantes más, algunos incluso descontinuados. Pinchar aqui.

Almacenamiento

FreeNAS

Openfiler

Aparte de la facilidad de su despliegue y su uso gracias a sus interfaces gráficas, otra de las ventajas a destacar es su costo. Al estar basados en software libre, se hacen propicios en entornos donde no se cuente con recursos económicos para adquirir otro tipo de soluciones comerciales, o incluso sustituirlas según sean los casos. Pensemos, por ejemplo, en una PYME que pueda reutilizar un equipo reemplazado y que dotándolo con unas tarjetas de red adicionales pueda convertirse en un cortafuegos, router, web proxy, servidor VPN, o lo que sea. Lo que quiero decir es que no necesitamos invertir una cantidad de dinero más o menos considerable para garantizar la seguridad sino que además no tenemos que renunciar a ella en caso de no disponer de un capital para adquirir algún producto de los tantos que hay en el mercado.

En fin, bien por falta de tiempo o recursos económicos, no tenemos porqué perder unos servicios o funcionalidades en nuestras redes de datos. Tenemos a nuestra disposición un gran número de distribuciones, que sin tener un conocimiento exhaustivo de los sistemas sobre los cuales están basados, pueden cumplir con nuestras necesidades.

Liberada Guía avanzada de nmap 6

El pasado día 13 de diciembre se liberó una guía sobre el uso de la archiconocida herramienta para el descubrimiento y análisis de equipos, servicios, S.O. etc. en una red para propósitos de auditoría o pentesting; NMAP. La misma no sólo abarca su funcionamiento sino además las técnicas más empleadas en su uso y sus  características más avanzadas como el motor de scripting NSE. Fruto de la colaboración del Centro Criptológico Nacional (CCN) y el Centro de Seguridad TIC de la comunidad Valenciana (CSIRT-CV) ve la luz un excelente documento que hay que dedicarle su tiempo para sacarle todo lo que nos ofrece en sus 112 hojas.

Para su descarga pincha aquí.

Transferencia de Zona en DNS

Aquí estamos con otra entrada, la primera en este 2013. A ver si gusta y se convierte en un buen presagio para el resto del año.

 En esta ocasión vamos a meternos con DNS. Como muchos sabréis DNS es un protocolo que permite asociar, de forma jerárquica, nombres de dominio a IPs así como identificar hosts dentro de estos dominios. Para los que no lo conozcan os dejo el enlace de la Wikipedia donde se habla de este protocolo, pinchar aquí.

Dejando de lado el servicio que presta en Internet, vamos a ceñirnos esta vez al ámbito empresarial. Muchas organizaciones contarán con su propio servidor DNS para resolver los nombres de equipos en direcciones IP para un dominio concreto, que es al fin y al cabo, lo que emplean los sistemas operativos y las aplicaciones para establecer conexiones contra otros hosts, principalmente servidores. En este caso se utilizará DNS sobre protocolo UDP y el puerto 53. Cabe mencionar que en muchos casos el servidor DNS presta servicios de DHCP, o viceversa. Si bien servidores, impresoras, u otros equipos tendrán un direccionamiento estático, los equipos finales podrán emplear un direccionamiento asignado mediante DHCP. Si ambos servicios son prestados por el mismo equipo, cuando la parte de DHCP asigne una dirección IP, automáticamente se generará un registro DNS para ese equipo.

Sin embargo también existe la posibilidad de utilizarlo sobre TCP y en el mismo puerto. Pero ¿para qué se emplea? Pues para realizar Transferencias de Zona, por ejemplo de un servidor primario a uno secundario. Es decir, habrá un servidor primario DNS al que le llegan todas las consultas de los clientes (UDP:53); pudiendo existir otro, para que el caso de que el primero caiga, sea el secundario el que continúe resolviendo los nombres de máquina y así garantizar el servicio. Lógicamente el servidor secundario tiene que saber en todo momento las entradas de IPs, nombres de máquina, etc. que maneja el servidor primario. Esto se realiza mediante lo que se denomina “Transferencia de Zona”. Esto es, el servidor secundario abre una conexión mediante TCP al puerto 53 del servidor primario y le solicita todos los registros de nombres para el dominio de la empresa.

Como se puede ver un servidor DNS es una gran fuente de información, y como tal también hay que tomar medidas en lo que a la seguridad se refiere. ¿Por qué? Porque si no restringimos de alguna forma y mantenemos el servidor primario con el puerto TCP:53 abierto, “alguien” con no muy buenas intenciones podría detectarlo y solicitar realizar una trasferencia de zona y hacerse con todo el direccionamiento de nuestro dominio sin necesidad de lanzar ni un solo escaneo para detectar hosts o servicios. Aparte hay que tener en cuenta que DNS permite asociar un texto a un registro de equipo, generalmente utilizado para añadir una descripción a éste.

A continuación veremos cómo se podría desarrollar esto mismo, por supuesto en un entorno de test.

Para ello tendremos un laboratorio virtual creado con GNS3 y VMware. Tendremos 3 switches, dos de core y uno de acceso. A este último irán conectados 3 máquinas, un XP, un Windows 7 y la máquina atacante que será un Backtrack 5 R3. Y por supuesto un servidor DHCP/DNS para asignación de IPs y resolución de nombres. Quedaría algo así:

escenario

Si mantenemos nuestro Wireshark arrancado mientas ejecutamos “dhclient eth0” para solicitar una IP y capturamos el tráfico resultante veremos entre otros datos que nos proporciona DHCP el nombre del dominio en el que nos encontramos, es decir edorta.lcl.

nombre_dominio y servidor

Como podemos apreciar nuestro servidor de nombres (DNS) tiene la IP 192.168.10.5, que curiosamente es la misma IP desde la cual se nos asigna la nuestra, la 192.168.10.20. O sea, DHCP y DNS están el mismo equipo. A continuación lanzaremos nmap para saber sobre qué protocolos de Capa 4 tiene abierto el puerto 53.

root@bt:~# nmap -sU -sS -p53 192.168.10.5Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-05 19:47 CET
Nmap scan report for XXXXXXXX.edorta.lcl (192.168.10.5)
Host is up (0.00099s latency).
PORT   STATE SERVICE
53/tcp open  domain
53/udp open  domain
MAC Address: 00:0C:29:FB:52:A8 (VMware) 
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds 

¡Perfecto! Tenemos el TCP:53 “open” con lo que vamos a tratar si podemos llevar a cabo la transferencia de zona. Para ello utilizaremos la herramienta “dig”. Dig, es una utilidad que nos permitirá realizar consultas DNS de distintas formas y ajustar las opciones que nosotros deseemos. Entre ellas está la de llevar a cabo una transferencia de zona. Esto se realiza ejecutando:

root@bt:~# dig edorta.lcl axfr 
; <<>> DiG 9.7.0-P1 <<>> edorta.lcl axfr
;; global options: +cmd
edorta.lcl.                 259200   IN       SOA      XXXXXXX.edorta.lcl. hostmaster.edorta.lcl. 2012123076 28800 7200 2419200 86400
edorta.lcl.                 259200   IN       NS       XXXXXXX.edorta.lcl.
edorta.lcl.                 259200   IN       A        192.168.10.5
edorta.lcl.                 259200   IN       A        192.168.11.5
bt.edorta.lcl.              900      IN       A        192.168.10.20
bt.edorta.lcl.              900      IN       TXT      “00445d89f28c340342881e7f7a4605c117”
core-of-01.edorta.lcl.      259200   IN       A        192.168.5.10
core-of-01.edorta.lcl.      259200   IN       TXT      “switch” “01” “de” “core” “de” “oficinas”
core-of-02.edorta.lcl.      259200   IN       TXT      “switch” “02” “de” “core” “de” “oficinas”
core-of-02.edorta.lcl.      259200   IN       A        192.168.5.11
core-srv-01.edorta.lcl.     259200   IN       TXT      “switch” “01” “de” “core” “de” “servidores”
core-srv-01.edorta.lcl.     259200   IN       A        192.168.5.13
core-srv-02.edorta.lcl.     259200   IN       TXT      “switch” “02” “de” “core” “de” “servidores”
core-srv-02.edorta.lcl.     259200   IN       A        192.168.5.12
fw-01.edorta.lcl.  259200   IN       TXT      “Firewall” “Granja” “Servidores”
fw-01.edorta.lcl.  259200   IN       A        192.168.100.254
IPS-01.edorta.lcl. 259200   IN       TXT      “IPS” “Granja” “de” “servidores”
IPS-01.edorta.lcl. 259200   IN       A        192.168.100.253
of-01.edorta.lcl.  259200   IN       A        192.168.10.10
srv-01.edorta.lcl. 259200   IN       TXT      “switch” “de” “la” “granja” “de” “servidores”
srv-01.edorta.lcl. 259200   IN       A        192.168.100.10
srvficheros.edorta.lcl.     259200   IN       TXT      “Servidor” “de” “ficheros”
srvficheros.edorta.lcl.     259200   IN       A        192.168.100.5
XXXXXXX.edorta.lcl.         259200   IN       A        192.168.1.1
XXXXXXX.edorta.lcl.         259200   IN       A        192.168.10.5
XXXXXXX.edorta.lcl.         259200   IN       A        192.168.11.5
edorta.lcl.                 259200   IN       SOA      XXXXXXX.edorta.lcl. hostmaster.edorta.lcl. 2012123076 28800 7200 2419200 86400
;; Query time: 13 msec
;; SERVER: 192.168.10.5#53(192.168.10.5)
;; WHEN: Sat Jan  5 19:47:19 2013
;; XFR size: 27 records (messages 1, bytes 835) 

¡Tranferencia realizada! A continuación os dejo la captura en la que se puede apreciar el “Three Way Handshake” de TCP desde Backtrack hacia el servidor, paquetes 6 al 8. Una vez establecida la conexión el PC  realiza la consulta para la transferencia de zona, paquete 9. Y finalmente la respuesta del servidor, paquete 11, y que corresponde con la información que sale en la ventana de abajo y donde se pueden ver listados todos los equipos. 

axfr_dig

Como podemos ver tenemos los registros de los equipos que figuran en la imagen del escenario y alguno más que he metido a propósito para agregar más contenido al ejemplo. A partir de aquí un atacante podría saber los nombres de equipos, su descripción si la hubiese, IPs, redes implementadas, y otra información proporcionada por los distintos registros que emplea DNS como CNAME, MX, NS, etc.

Fijaros de qué manera más tonta, un atacante se ha ahorrado tener que lanzar escaneos para localizar equipos, servicios, etc. y así seguir avanzando en sus propósitos. Aparte, ha minimizado el riesgo de ser detectado por algún IPS o que se logue en algún firewall el descarte de paquetes de las sondas que envía NMAP. Ahora podrá ir a tiro fijo sobre un equipo. Como decía, existen algunos registros que nos indican la funcionalidad de los equipos. Tal es el caso de MX que se emplea para identificar los servidores de correo electrónico asociados a ese dominio. Por tanto, ¿tiene mucho sentido lanzar a destajo sondas para ver si tiene otros servicios abiertos con el riesgo que esto supone? Si sabemos que es un servidor de correo, lanzará las sondas a los puertos que sabemos emplea ese servicio. A ver, un servidor puede tener varios servicios corriendo en un mismo equipo, pero bueno primero vayamos contra los puertos que sabemos que puede estar utilizando. ¿Que no puede cumplir con sus objetivos? pues entonces ya realizará un escaneo para ver si corre otro servicio más vulnerable, comprometerlo y llevar a cabo otras acciones. Otro ejemplo, en la captura vemos que hay un equipo llamado “srvficheros” con una descripción acorde a su nombre. Por tanto, ¿tiene mucho sentido lanzar escaneos contra un servicio IPSEC, aplicación OpenVPN, detección de Web Proxy, etc? Mejor hacerlo al TCP:139,445; ¿no? A partir de estos detectar el sistema operativo, número de saltos, etc.

En cualquier caso lo que se pretende mostrar es la manera cómo, a partir de una mala configuración, o no afinada como debiera, un atacante podría hacerse con multitud de información que revelaría nombres de equipos, IPs, funcionalidades de servidores, si éstos corren más servicios, etc. Si además esto lo complementamos con otras técnicas mejor que mejor.

Así que, de una forma u otra deberemos proteger este servicio que de lo contrario, podría suponer una desagradable sorpresa.

Un saludo, seguiremos informando.