Nmap Scripting Engine para ICS

Muchos sabemos que Nmap es una de las herramientas estrella para identificar host, servicios, redes  y poder llevar a cabo tareas de recolección de información (Information Gathering) dentro de procesos de auditoría o pentesting. Hablando más concretamente de entornos industriales, hemos de tomar ciertas precauciones ya que podremos afectar a la operativa del equipo, algo que en ningún caso puede producirse. Nmap posee además algunas funcionalidades extra de la mano de su motor NSE (Nmap Scripting Engine) que nos permite llevar a cabo tareas más concretas. Éste se basa en un conjunto de scripts que se organizan en distintas categorías dependiendo de la finalidad, como son:

  • auth
  • broadcast
  • brute
  • default
  • discovery
  • dos
  • exploit
  • external
  • fuzzer
  • intrusive
  • malware
  • safe
  • version
  • vuln

Hace un tiempo hablé sobre algunos aspectos de Nmap, tanto de su  motor de Scripting NSE como de sus uso sobre sistemas de control industrial. Por no repetir contenido os dejo los enlaces para que las podáis consultar.

  1. Nmap Scripting Engine
  2. Nmap sobre SCI sí, pero con cuidado…

Sin embargo, en el día de hoy voy a hablar de una serie de Scripts dirigidos específicamente a identificar y enumerar dispositivos y aplicaciones que pueden ser encontrados en entornos de control y automatización. Para ello se basan en protocolos y comandos de la propia aplicación para obtener información del objetivo. Sólo se trata de “recolectar”, no de “explotar”.

El primer conjunto de ellos podemos encontrarlo en el siguiente enlace de Github. Los mismos han sido desarrollados dentro de un proyecto de investigación llamado “Redpoint” de Digital Bond, consultora fundada en 1998 por Dale Peterson especializada en seguridad en entornos industriales.

redpoint_01

Para un mejor uso podemos descargarlos y copiarlos en la carpeta de “Scripts” que emplea nmap y que en la distribución Kali Linux está ubicados en:

/usr/share/nmap/scripts 

Luego es necesario actualizar la base de datos para que podamos verlos por ejemplo con la interfaz gráfica “Zenmap”.

root@kali:/usr/share/nmap/scripts# nmap –script-updatedb
Starting Nmap 7.25BETA2 ( https://nmap.org ) at XXXX-XX-XX 07:00 EST
NSE: Updating rule database.
NSE: Script Database updated successfully.
Nmap done: 0 IP addresses (0 hosts up) scanned in 1.37 seconds

Para diferenciarlos los he renombrado como “Redpoint_XXXXXXXX.nse” y así identificarlos más claramente.

zenmap-redpoint-scripts_01

Nmap cuenta de forma nativa con algunos scripts orientados a estos fines como Modbus, OMRON, incluso alguno creado por el propio “DigitalBond” como puede ser para el protocolo “BACnet”. Como ejemplo utilizaré esté último para ver los resultados arrojados y hacernos una idea. Para facilitar la tarea he hecho una primera búsqueda con ZoomEye, del que hablaba en mi último post llamado  “Buscando ICS en la red, ZoomEye”.

En el primero de los ejemplos podemos ver los siguiente:

zenmap-redpoint-scripts_02

Analizando la información podemos seguir buscando y ver las características de los equipos que responden a ese perfil, como puede ser:

nae-55xx_01

Y mira por dónde, yendo un poco más allá localizar vulnerabilidades de ese fabricante:

jhonson-vulnerability_01

Por otro lado, en el siguiente ejemplo podemos observar otro resultado.

zenmap-redpoint-scripts_03

Al igual que el caso anterior localizamos que se trata de un equipo del fabricante Kieback & Peter cuya web es la siguiente:

kieback-peter_01

Y vemos que se trata de un equipo destinado al control de estaciones de ventilación, refrigeración de edificios pequeños y medianos:

kieback-peter-ddc420

El segundo de los repositorios también lo encontramos en GitHub en el siguiente enlace,  haciendo referencia sólo a productos del fabricante SIEMENS. Los mismos han sido desarrollados por la empresa DrainWare, apreciándose que el nombre de la cuenta de GitHub coincide con su fundador “jpalanco”.

github-scripts-drainware_01

El funcionamiento es similar a lo planteado en los casos anteriores, con lo que explicado uno, explicados todos. Sí que es cierto que dependiendo del script que ejecutemos deberemos especificar uno u otros puertos, pudiendo indicar  además ciertos argumentos asociados a HTTP o SMB y así perfeccionar la ejecución.

github-scripts-drainware_02

La idea en el día de hoy es ofrecer cómo ampliar y ajustar las funcionalidades de Nmap para su uso concreto sobre sistemas de control y automatización, mediante la inclusión de Scripts específicos ya desarrollados. Como decía, son especialmente útiles cara a realizar labores de auditoría o pentesting ya que permite, no sólo, la recolección y enumeración de información sino definir la forma y modo de hacerlo mediante la parametrización de la herramienta para que sea más o menos intrusiva.

No obstante, conviene recordar que el uso ha de hacerse teniendo en cuenta el equipo final sobre el que lancemos los scripts ya que podremos afectar a su funcionamiento. Esto es debido a los limitados recursos hardware que poseen con lo que es probable dejarlos “offline”, por lo que resulta necesario, o al menos aconsejable, hacerlo en un entorno controlado o de pruebas. Me refiero por supuesto a equipos de sistema de control y automatización. En cualquiera de los casos mucho, mucho cuidado.

¡Un saludo, nos vemos en la próxima!

 

Virtual Patching en funcionamiento (Parte I)

Siguiendo con el tema de Virtual Patching ahora toca ver cómo funciona y los beneficios que puede aportarnos.

Para ello he creado un entorno con dos PCs interconectados por medio de un Fortinet Fortigate Rugged 60D configurándolo con motores Antivirus, IDS/IPS y Control de Aplicación. La parte de firewall la he dejado con un “permit any any any” (IP origen, destino y puerto, respectivamente) Hay que recordar que cada una de ellos lo podemos configurar en dos modos, “Monitor” o “Block”. Con el primero, en caso de que se detecte algún patrón que puda quedar recogido dentro de las reglas y firmas, no se tomará ninguna acción, sólo se registrará el evento y se dejará pasar. En cambio con “Block”, valga la redundancia se bloqueará y la amenaza será paralizada.

Luego, estas características han de aplicarse, o no, a las reglas de Firewall en él configuradas.

En cada uno de estos PCs he virtualizado un total de 3 máquinas.

Una con Kali Linux desde la cual simularemos la actividad de un atacante. Lanzaremos un escaneo de puertos con Nmap, escáner de vulnerabilidades con Nessus, intento de intrusión con Metaesploit y Armitage y por último copiar en un recurso de red el fichero EICAR.

Otra con un Windows XP vulnerable, el objetivo. Se ha elegido este ya que posee vulnerabilidades que para un ejemplo pueden ser fácilmente explotables. Aparte porque su uso en entornos industriales y o vida prolongada es aún bastante común.

Por último un Fortinet FotiManager con funciones FortiAnalyzer desde donde gestionaremos el equipo Fortigate Rugged 60D. Lo he querido utilizar ya que con un despliegue de varios equipos resulta aconsejable no sólo por la gestión centralizada sino porque nos permite almacenar los logs, analizar tráfico, sacar informes, ver registros, etc.

Todo queda resumido de la siguiente manera:

 

Esquema 01

En la imagen siguiente se muestra cómo el equipo Fortigate bloquea un total de 9965 amenazas catalogadas en un total de 1993 incidentes, provenientes de la IP XX.XX.XX.15 de la máquina Kali Linux. Esto es debido a que la aplicación Nmap envía sucesivamente paquetes para que en función de las respuestas obtenidas se pueda determinar si un equipo está activo, o no, puertos abiertos; versiones de aplicaciones, servicios; etc.

Para conocer un poco más recomiendo la siguiente lectura, pincha aquí.

Imagen 01

En esta otra se puede ver que el equipo destino tiene la IP XX.XX.XX.17.

Imagen 02

En la siguiente imagen se muestra las “sondas” enviadas desde el equipo Kali Linux identificando alguna aplicación que otra:

Imagen 03

Como se puede apreciar éstas han sido bloqueadas no pudiéndose obtener datos sobre el equipo objetivo, el XP. Esto mitigaría la etapa inicial de recolección de información que un atacante llevaría a cabo y poder, a partir de ahí, realizar otro tipo de acciones sobre nuestros sistemas.

Obviamente habría que configurar las reglas del firewall del modo más restrictivo posible y sobre el tráfico que dejamos pasar aplicar el análisis de los motores Antivirus, IPS y Control de Aplicación. Sin embargo para este ejemplo se ha querido dejar así para ver el comportamiento de la aplicación Nmap y qué es lo que sucede si no empleamos un cortafuego. Pero como como digo, siempre, siempre, siempre, ha de restringirse el tráfico sólo al estrictamente permitido por medio de estos firewalls.

Esto es todo por hoy, pero os debo las siguientes entradas sobre escáner de Vulnerabilidades, Metaesploit y EICAR Test File.

No s vemos en la próxima, y como siempre digo, se agradece cualquier comentario al respecto.

Muchas gracias!

Nmap Scripting Engine

En mayor o menor medida,  todos hemos oído hablar de NMAP, esa herramienta creada por Fyodor  y con la que podremos, entre otras cosas, detectar equipos activos, sistemas operativos, servicios, versiones, etc. ¿Sus finalidades? Bueno, de lo más variopinta, desde la exploración de redes y sistemas,  auditorias de seguridad, procesos de pentesting, etc. Es una herramienta multiplataforma, de la que existe además una buena y abundante información. Su interfaz tanto por línea de comandos como una GUI denominada Zenmap la hacen asequible para todos los gustos de quien la utilice.

Pero  en este caso quiero habla de una de sus funcionalidades. La forma más común de emplear sería:

nmap dominioencuestion.com

Nmap tiene establecidas unas configuraciones por defecto, las cuales podremos ajustar con las distintas opciones que nos ofrece. Por ejemplo el rango de puertos a escanear, protocolos (TCP, UDP, etc.), técnicas para detección de cortafuegos con o sin estado, resolución DNS de los objetivos, cantidad de sondas enviadas, spoof de direcciones, etc.

Sin embargo una de las opciones más potentes de NMAP es lo que se denomina NSE (Nmap Scripting Engine). NSE es una funcionalidad que nos permite  por medio de scripts automatizar ciertas tareas según el script en cuestión. Estos scripts se dividen en varias categorías, como son:

auth: Scripts que gestionan procesos de autenticación.

broadcast: Orientado a la obtención de información por medioo de peticiones Broadcast.

brute: Scripts destinados a la auditoria a de contraseñas por medio de fuerza bruta.

default: Ejecución de scripts “by default”. Se ejecuta por medio de la oción –sC.

discovery: Scripts para el descubrimiento de equipos.

dos: Scripts relacionados con ataques tipo DoS.

exploit: Scripts que explotan vulnerabilidades.

external: Scripts que utilizan servicios externos o de terceros.

fuzzer: Scripts orientados a tareas de fuzzing, por ejemplo envío de datos malformados o inesperados.

intrusive: Scripts que podrían colapsar algunos sistemas o generar una gran cantidad de tráfico.

malware: Scripts relacionados con la detección de malware diverso.

safe: Scripts que pueden considerarse como “seguros” a diferencia por ejemplo de los catalogados como “intrusive”

version: Scripts para consultas avanzadas de distintos tiposd e versiones

vuln: Scripts que notifican si existe, o no, vulnerabilidades conocidas.

Una de las primeras tareas que deberemos hacer es actualizar nuestra base de datos.

nmap –script-updatedb 

Cada Script está catalogado dentro de cada una de las categorías según sea su utilidad. SI quisiéramos lanzar todos los scripts de una categoría concreta, deberíamos  utilizar:

nmap –sV –script auth <OBJETIVO> 

O sin queremnos más de una categoría:

nmap -sV –script=”version,discovery” <OBJETIVO>

Según sea nuestra distribución podremos encontrarlos en,

Kali:

/usr/share/nmap/scripts

Bugtraq:

/usr/local/share/nmap/scripts

Estos scripts no son “cerrados”, soportan la inclusión de argumentos, o variables que serán utilizadas para su ejecución. Por ejemplo quisiéramos realizar un ataque por fuerza bruta empleando HTTP y proporcionando un listado de usuarios y contraseñas concretos deberíamos utilizar:

nmap -p80 –script http-brute –script-args userdb=/var/usernames.

txt,passdb=/var/passwords.txt <OBJETIVO>

 Dado que son tareas automatizadas tenemos que tener en cuenta que su actividad podría ser detectada por IDS/IPS o firewalls que loguen el tráfico generado.

Como hemos dicho, Nmap cuenta con una interfaz gráfica denominada Zenmap, en la que también encontraremos estas funcionalidades.

 

Captura_01

Deberemos crear un “Profile”, por lo que pincharemos sobre él y una vez allí sobre “New Profile or Command”.

Captura_02

Allí en “Scripting” encontraremos todos los scripts disponibles.

Captura_03

 

Además podremos definir otros valores y sus respectivos valores y variantes para luego presionando “Scan” lanzarlo.

Como digo, esto es sólo el comienzo de Namp Scripting Engine, como todas las cosas luego nos toca a nosotros meter horas y horas para sacarle todo el provecho.

Un saludo.

 

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í.

Switching Multicapa y SVI

Aquí estamos  de nuevo. Esta vez nos vamos a meter con una característica de los switches multicapa.

Para empezar definiremos qué es esto de los switches multicapa cuando, es posible, que hasta la fecha nos hayan contado que los switches son equipos de Capa 2 dentro del modelo OSI.  En origen, los switches sí que lo eran, pero como todo en esta vida, las cosas cambian y evolucionan. A veces a mejor, a veces a peor, pero en nuestro caso, y como no podía ser de otra manera, a mejor J. Como ya sabemos, los switches en el sentido tradicional de la palabra, efectúan los envíos de tramas considerando las direcciones MAC de los equipos que tiene conectados a cada una de sus bocas, permitiendo así las comunicaciones de la misma red, subred o VLAN. En el momento que queramos hacerlo contra otros fuera de éstas, por ejemplo una granja de servidores, con otro direccionamiento IP y VLAN (es lo suyo), necesitamos, entonces, un equipo de Capa 3 como puede ser un router o un switch multicapa. En un switch multicapa, la principal diferencia con los de Capa 2, es que ahora ya no se va a considerar la dirección MAC del equipo final sino la IP. Es decir, el direccionamiento de Capa 3; o sea, como lo hace un router. Y claro alguien preguntará ¿y en qué más se diferencian un router y un switch multicapa? Una de ellas es el rendimiento. Un switch multicapa está orientado a entornos LAN, pudiendo ofrecer rendimientos a la velocidad del medio que tengan conectado, ya sea 100 Mbps, 1Gbps o 10 Gbps. Esto se consigue gracias a una electrónica especializada denominada ASIC en lugar de un microprocesador que es lo que emplea un router.  Además como buen switch poseen una densidad de puertos mayor pudiendo ser de 12, 24, 48, puertos con medios de transmisión como cable UTP o Fibra Óptica dependiendo de fabricante, gama, modelo, etc. Y ni qué decir que puesto que son equipos que operan en capa 3 también dispondrán de funciones de enrutamiento, tanto estático como dinámico (OSPF, EIGRP, RIP, etc.).

Ahora bien, si tenemos un switch de estas características ¿cómo los echamos a andar? Esta vez tiraré de Packettracer, simulador de redes de Cisco, y tomaré el de capa de capa 3, el 3560.

Aquí tendremos un par de opciones.

Una de ellas es asignar a cada interfaz física del switch una dirección IP. Para ello deberemos configurar dicho puerto como uno de capa 3 en lugar de capa 2 que es como suelen venir por defecto. Para ello:

Switch>enable

Switch#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

Switch(config)#interface fastEthernet 0/1

Switch(config-if)#no switchport

Switch(config-if)#ip address 192.168.1.1 255.255.255.0

Switch(config-if)#exit

Switch(config)#ip routing 

Una vez que entramos en el modo de configuración de la interfaz con “no switchport” indicamos que ese puerto (fastethernet 0/1) no tendrá capacidades L2 (Layer 2, Capa 2) sino L3. Luego con “ip address 192.168.1.1 255.255.255.0” le asignamos la IP y finalmente con “ip routing” habilitamos la capacidad de enrutamiento entre las distintas interfaces que tenga.

Esta es una opción, pero no la única. La otra es definir interfaces virtuales, lo que se denomina como SVI (Switch Virtual Interface). Una SVI es una interfaz definida en el quipo y asociada a una VLAN concreta. Uno de los requisitos es que tiene que haber un puerto activo en esa VLAN para que la SVI correspondiente se habilite. Un enlace troncal también vale. Aunque sea virtual podremos configurar en ella los mismos protocolos y funcionalidades que a una interfaz física como pueden ser HSRP, VRRP, GLBP, ACL´s, etc.

Para ponerlo en funcionamiento, tenemos que definir las VLANs, crear las SVI correspondientes a cada VLAN y asignar una IP, configurar las interfaces físicas bien en modo troncal o de acceso asociada a una VLAN, y habilitar el enrutamiento como en el paso anterior

Esto es:

Entramos en modo configuración:

Switch>ena

Switch>enable

Switch#conf t

Definimos las VLAN 10 y 20:

Switch(config)#vlan 10

Switch(config-vlan)#name VLAN_10

Switch(config-vlan)#exit

Switch(config)#vlan 20

Switch(config-vlan)#name VLAN_20

Switch(config-vlan)#exit

Configuramos las interfaces físicas:

Switch(config)#interface fastEthernet 0/1

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 10

Switch(config-if)#exit

Switch(config)#interface fastEthernet 0/2

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 20

Switch(config-if)#exit

Definimos las SVIs:

Switch(config)#interface vlan 10

Switch(config-if)#

Switch(config-if)#ip address 192.168.10.1 255.255.255.0

Switch(config-if)#exit

Switch(config)#interface vlan 20

Switch(config-if)#ip address 192.168.20.1 255.255.255.0

Switch(config-if)#exit

Habilitamos el enrutamiento:

Switch(config)#ip routing

Otra funcionalidad aparte de la comunicación entre redes,  es utilizarlas para la gestión de los propios equipos mediante protocolos como SSH, Telnet, monitorización, etc. para lo cual deberemos definir también una puerta de enlace para la comunicación con otras redes. No nos debemos olvidar que aún en este caso nuestros equipos de red al estar dotados con una IP aunque sea la de gestión, también puede ser objeto de escaneos de red con objeto de recolectar información, y realizar a posteriori algún tipo de explotación contra alguno de los servicios que puedan correr en ellos.

A continuación os dejo una captura de un escaneo sencillo contra un switch Catalyst 6509 dotado con sistema operativo CatOS.

Scan a IP de gestión

Como se puede ver nmap lo ha detectado sin problemas. Para evitarlo es aconsejable definir algún tipo de ACL donde se permita algún tipo de tráfico desde una estación central de gestión. Pero eso lo dejamos para otro rato, por hoy lo dejamos.

Seguiremos informando…

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.