Siempre había oído hablar de las debilidades del protocolo SNMP en su versión 1 y 2, pero hasta ahora no me había puesto a trastear con ellas, así que preparado un laboratorio virtual, me puse manos a la obra.

De forma muy resumida diremos que SNMP (Simple Network Management Protocol) es un protocolo que nos va a permitir monitorizar los dispositivos de red y su comportamiento, pudiendo detectar posibles fallos, irregularidades o corroborar que nuestra red funciona correctamente. Empleando UDP y los puerto 161 y 162, cada equipo de red configurado para ser administrado o monitorizado mediante este protocolo, tendrá un agente que irá recogiendo información y la guardará en una base de información interna denominada MIB (Management Information Base). Cada entrada de esa MIB constituirá un objeto, el cual será identificado mediante una sucesión única de números, denominado OID (Object Identifier). Por ejemplo si monitorizamos la memoria en uso de un switch Cisco, el objeto será “ciscoMemoryPoolUsed“; el OID, 1.3.6.1.4.1.9.9.48.1.1.1.5; y el valor será un número entero no negativo.

Por otro lado tendremos una estación (PC o servidor) denominada NMS (Network Management System) la cual tendrá instalada un software de monitorización. Este software preguntará o escribirá al, o en el equipo, por el valor de un OID concreto. El equipo, sea un switch, router, etc; responderá a la NMS con el citado valor. Luego dependiendo de éste y de la configuración del propio software, éste nos podrá mostrar en pantalla lo que sea, por ejemplo una casilla en verde si todo va bien, en amarillo si hay algo raro o en rojo si algo ha fallado y tenemos que salir a toda pastilla a arreglarlo.

Para que el equipo administrado y la estación de monitorización se entiendan se han de definir lo que se denomina “comunidades“. Un comunidad es una palabra clave utilizada como autenticación entre uno y otro. Las hay de lectura y de lectura-escritura. Con la primera  la NMS leerá valores de los objetos en la MIB del equipo, mientras que con la segunda podrá escribir en ella. Obviamente la NMS deberá tener definidas las MIB, sean estándar o propietarias, de los equipos a monitorizar o bien los plugins que los interpreten.

Para este post he montado un laboratorio con GNS3 y algunas máquinas virtuales VMWare comunicadas mediante los switches que previamente he configurado en el simulador. A continuación os pongo una captura con parte de la topología que nos interesa:

Como vemos el switch OF_01 es un switch de acceso al que están conectados 4 equipos, W7001, un Windows 7; XP001, un Windows XP; NST, distribución Network Security Toolkit y BT5R2, con un Backtrack 5, todos ubicados en la misma VLAN, en este caso la 10. W7001 lo utilizaremos para correr Cain; NST, un Nagios con unos plugin instalados para monitorizar la carga de CPU, memoria usada de los switches y un “ping” a la IP de gestión de los equipos para ver si siguen “vivos”; y BT5R2 para ejecutar algunas aplicaciones para SNMP, nmap y wireshark.

El switch “OF_01” tiene dos uplinks hacia dos switches de capa 3 que harán las funciones de distribución/core denominados “CORE_OF_01” y “CORE_OF_02”. Tendrán HSRP configurado para la interfaz VLAN 10, OSPF como protocolo de enrutamiento y SNMP igualmente para la monitorización.

Para utilizar SNMP en los switches, los habremos configurado de la siguiente manera para las comunidades de lectura y lectura-escritura, respectivamente.

OF_01(config)# snmp-server community roedorta ro
OF_01(config)# snmp-server community rwedorta rw

Una de las medidas más comunes para “proteger” nuestros equipos es configurar sólo la comunidad de sólo lectura. De esta manera evitaremos que si alguien nos compromete nuestros equipos no podrá hacer cambios en ellos, sólo leer los objetos de la MIB. Lo malo es que en ciertos escenarios es necesario utilizar también la de lectura-escritura ya que es empleada por algunas aplicaciones de gestión, como CiscoWorks, para hacer cambios en nuestros equipos.

Para saber si un equipo está ejecutando SNMP podremos hacer un escaneo de nuestra red mediante nmap:

nmap -sU -sV -p 161 192.168.10.0/24

Con los resultados arrojados, si además lo acompañamos de una captura con Wireshark nos podemos encontrar con otra información extra analizando protocolos como CDP, en el caso de estar activado, o HSRP. En nuestro caso nos centraremos en la IP 192.168.10.10 ya que el escaneo con nmap nos indica que la versión de SNMP es “Cisco SNMP service”.

Nmap scan report for 192.168.10.10
Host is up (0.021s latency).
PORT    STATE SERVICE VERSION
161/udp open  snmp    Cisco SNMP service
MAC Address: C2:05:18:1C:00:00 (Unknown)

Por otra parte la captura de Wireshark nos dice que la IP 192.168.10.2 y 192.168.10.3 son el nodo “Active” y “Standby” en HSRP. A priori podemos pensar que sería mejor ir a por ellos, pero para empezar iremos a los más cercanos y cuando obtengamos más información ya iremos escalando…

Aquí partiremos que tenemos en nuestro poder el nombre de las comunidades. Podremos tener varios métodos para obtenerlas por ejemplo un MITM, ya que la el nombre de comunidad va en texto plano y por tanto fácilmente interpretable. Sin embargo esto no siempre surtirá efecto ya que la NMS debería estar situada en una granja de servidores detrás de algún cortafuegos. Otras métodos podrán ir desde una archivo de configuración antiguo (habrá quien cambia las contraseñas y los usuarios de los equipos pero no el nombre de comunidad), ingeniería social o simple picaresca.

Otra alternativa será realizar un ataque por fuerza bruta empleando la herramienta onesixtyone incluida dentro de la distribución BackTrack, y que como ejemplo de ejecución tenemos:

root@bt:/pentest/enumeration/snmp/onesixtyone#./onesixtyone -w <espera en milisegundos entre paquete y paquete> -c <diccionario con nombres de comunidad> -i <lista con host objetivo>

Bien sea por un método u otro, el caso es que como digo tendremos los nombres de comunidad, en nuestro ejemplo roedorta como lectura y rwedorta para lectura-escritura.

A partir de aquí podremos con aplicaciones como snmpenum.pl y snmpcheck.pl, incluidas también en Backtrack, recolectar información de nuestro obejtivo y conocer algo más de él.

Para ello:

root@bt:/pentest/enumeration/snmp/snmpenum# ./snmpenum.pl 192.168.10.10 roedorta cisco.txt > /root/Desktop/switch.txt

root@bt:/pentest/enumeration/snmp/snmpcheck# ./snmpcheck-1.8.pl -t 192.168.10.10 -v 2 -c roedorta > /root/Desktop/switch01.txt

Como podemos ver SNMP puede ser muy útil si los administradores no han tomado algunas precauciones en cuanto a la configuración de este protocolo se refiere. Pero llegados a este punto y visto las distintas aplicaciones incluidas en BackTrack nos vamos a ir ahora a Caín, instalada en el equipo W7001. Caín es una aplicación que nos va a permitir llevar a cabo una gran cantidad de tareas, desde generar certificados falsos, ataques MITM, crackeo de contraseñas, arpspoofing, sniffer, etc.

Pero … ¿para qué la utilizaremos?

Esto lo dejamos para la siguiente entrega que será dentro de poco, que por ahora hay con qué practicar un poco.

Un saludo y…. seguiremos informando….