Avisando con Syslog…

Saber si algo anómalo ocurre en nuestra de red resulta de vital importancia para llevar a cabo una correcta administración de nuestra infraestructura. Estas anomalías pueden venir dadas por una gran cantidad de causas pero por citar algunas podríamos hablar de fallo  de una fuente de alimentación para equipos con redundancia eléctrica, reseteo imprevisto de un dispositivo, intentos de accesos fallidos, etc. etc. etc.

Para tener conocimiento de ello, los equipos de red pueden tener disponible el protocolo Syslog para que, en caso de producirse algún suceso digno de ser notificado, envíen un mensaje de registro a una estación central donde los procese una aplicación y podamos visualizarlo. Existen una gran variedad de herramientas bajo los acrónimos SIEM, SIM y SEM. Alguna de ellas pueden ser Kiwi Syslog Server o algunas con una gran variedad de otras funcionalidades entre las que se encuentran las del registro de estos mensajes como puede ser Cisco Prime Lan Management Solution (LMS).

Pues bien, entre una de mis tareas en mi actual cliente estaba la de configurar esta herramienta para que enviase por correo electrónico las alarmas que el conjunto de administradores creímos más relevantes. Para ello en primer lugar configuramos los equipos para habilitar este protocolo mediante los siguientes comandos

Router(config)#logging on 

Habilitamos syslog a nivel global del equipo

Router(config)#logging 192.168.10.53

Indicamos la IP del host donde se enviarán los mensajes.

Router(config)#logging trap x

Indicamos el nivel a un valor determinado entre 0 y 7. La tabla que figura a continuación establece los niveles configurables. Hay que tener en cuenta según el número que indicamos llevará implícito también los números superiores. Esto es, si elegimos el número 5, recibiremos también los mensajes del nivel 6  y 7.

0 Emergencia: el sistema está inutilizable
1 Alerta: se debe actuar inmediatamente
2 Crítico: condiciones críticas
3 Error: condiciones de error
4 Peligro: condiciones de peligro
5 Aviso: normal, pero condiciones notables
6 Información: mensajes informativos
7 Depuración: mensajes de bajo nivel

Por último: 

Router(config)#service timestamps log datetime

El mensaje llevará consigo una marca horaria.

Una vez configurada la aplicación Cisco Prime LMS con un servidor de correo, cuenta de usuario, dirección de envío, etc. estaría listo para recibir correos con el siguiente contenido:

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 10 23:17:53 switch-0001.dominiopruebas.net 2013 Feb 10

23:17:52 GMT +01:00 %SYS-2-PS_FAIL: Power supply 2 failed 

En este caso el mensaje nos dice que la fuente de alimentación (PS, Power Supply) número 2 del switch con nombre switch-001, ha fallado. El mensaje ha sucedido a las 23:17:52 y la aplicación ha mandado el correo a las 23:17:53, un segundo más tarde.  Cabe destacar que se trataba de un switch Cisco 6509-E que poseen dos fuentes de alimentación redundantes, vamos que no estamos hablando de un 2960…

Suponiendo  que a la mañana siguiente nos damos cuenta de ello y la cambiamos por otra nueva, recibiremos el siguiente:

Syslog message generated from device switch-0001: Feb 11 08:15:22 switch-0001.dominiopruebas.net 2013 Feb 11 08:15:21 GMT +01:00 %SYS-2-PS_OK: Power supply 2 okay

Como os habréis podido imaginar los datos horarios son falsos, en realidad lo que hice fue apagarla para ver si lo que había configurado iba bien.

Pero como mi mente es algo inquieta, pensé en lugar de simular una un fallo de hardware fuese víctima de un ataque, por ejemplo de un CAM overflow. Hay más información aqui.

Así que preparé mi Backtrack, configuré el switch  igual que otro cualquiera, lo conecté a la red y venga.

Eché mano de la aplicación macof. Macof lo que hace básicamente es generar tramas con direcciones MAC de origen aleatorias de tal manera que por cada trama que entre en el switch la incluirá en la tabla CAM. Al ser todas distintas la tabla CAM se irá llenando, hasta que al final se sature, porque obviamente la memoria tiene un límite. ¿Y qué pasa cuando eso ocurre? Pues que el switch podría comportarse como un hub. Aparte de ello, también lancé un ataque con THC Hydra similar a lque explico en mis entradas Mejorando acceso por SSH (Parte I) y Mejorando acceso por SSH (Parte II)

Vamos que entre el llenado de la memoria más la carga en la CPU… iba bien servido. Así que lo dejé. Pues bien al cabo de un par de minutos empecé a recibir los siguientes correos:

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001:: Feb 11 16:46:51 switch-0001.dominiopruebas.net 20: Feb 11 15:46:51: %PLATFORM-1-CRASHED: System previously crashed with the following message:

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 21: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(50)SE5, RELEASE SOFTWARE (fc1)

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 22: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Technical Support: http://www.cisco.com/techsupport

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 23: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Copyright (c) 1986-2010 by Cisco Systems, Inc.

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 24: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Compiled Tue 28-Sep-10 13:44 by prod_rel_team 

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 25: Feb 11 15:46:51: %PLATFORM-1-CRASHED:  

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 26: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Debug Exception (Could be NULL pointer dereference) Exception (0x2000)!

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 28: Feb 11 15:46:51: %PLATFORM-1-CRASHED: SRR0 = 0x010469F0  SRR1 = 0x00029230  SRR2 = 0x006548A4  SRR3 = 0x00021000

Resultan claras las palabras %PLATFORM-1-CRASHED: Luego el equipo se reinició y como el ataque continuaba pues vuelta a empezar, y a los dos minutos ¡catapum!, otra vez reinicio y así hasta parar.

Como vemos resultan muy útiles estos protocolos. La verdad que la herramienta de Cisco que pongo como ejemplo es una maravilla, como maravilla es lo que cuesta su licencia. La verdad que para la red que administramos es muy necesaria y el gasto se justifica, no tanto en otros entornos más pequeños. En cualquier caso lo que pretendo hacer ver es los mecanismos de los que podemos disponer para estar avisados en el caso de que algo raro suceda.

Espero haya sido interesante.

Un saludo, seguiremos informando

Peligroso SNMP Parte II

Retomando el hilo de la Parte I vamos a meternos con la aplicación Caín instalada en el equipo con Windows 7. Vamos a utilizar funcionalidad CCDU ya que con ella vamos a conseguir bajarnos la configuración del equipo indicándole la IP, el nombre de comunidad de lectura-escritura y la versión de SNMP, en este caso la 2.

Para ello, con el Firewall de Windows o de nuestro antivirus deshabilitado, ejecutaremos Caín como administrador y nos situaremos en la pestaña CCDU como figura en la imagen siguiente:

Luego pincharemos sobre el símbolo + de color azul y agregaremos la siguiente información:

Y tras darle a OK se nos habrá descargado la configuración del equipo.

Ésta queda almacenada en C:\Program Files\Cain\CCDU . Una vez allí podremos verla con detalle y extraer toda la información que nos sea de utilidad. Por ejemplo, servidores NTP, servidores donde enviar traps SNMP, hashes de usuarios y modo «enable» para posterior crackeo, descripciones de interfaces, servidores de autenticación, prioridades de STP, etc. Aparte si este fuera un equipo con capacidades de routing o conmutación multicapa, ver métodos de enrutamiento, estático o dinámico y de ser éste, protocolo elegido, hashes de autenticación de interfaces tipo HSRP u OSPF, ACL’s si es que las hubiese, etc. etc. etc.

Por poner un ejemplo:

enable secret 5 $1$9bXR$3.AxxK9qo6xda5tzNXv88.

username edorta password 7 045E0F091D354D

Aquí os invito a que echéis un vistazo a otro de mis post en el que hablo sobre el crackeo de contraseñas en dispositivos Cisco. Lo podréis encontrar aquí.

Lo malo del asunto puede es que de la misma manera que podremos descargar la configuración del equipo, podremos subirla. Así que imaginaros si alguien le da por crear un usuario, sustituir los hash de las cuentas de usuarios locales, añadir un «shutdown» a alguna de las interfaces, cambiar la prioridad de Spanning Tree Protocol, etc. etc. etc. Vamos que nos la pueden liar, y bien liada. En el siguiente ejemplo lo que haremos será cambiar sólo el nombre del switch OF_01 por SW_PWD.

Lo que haremos será abrir el fichero de configuración y sustituir el campo hostname OF_01 por SW_PWD. Para ello pincharemos con el botón derecho del ratón sobre el archivo de configuración y seleccionaremos «View». Se nos abrirá el editor bloc de notas , localizaremos la palabra hostname, donde a continuación figurará el nombre del equipo.

Lo cambiamos por lo que queramos (en este caso SW_PWD) y guardaremos los cambios.

Antes del cambio veremos que la consola figura:

Luego nuevamente sobre el archivo de configuración, botón derecho y…. UPLOAD!!!

Y … cambio efectuado!!!

Para evitar esta situación podríamos configurar una ACL (Access Control List) para que sólo permita el tráfico proveniente de la IP de la NMS. Para ello deberemos configurar el equipo de la siguiente manera:

OF_01(config)# access-list 10 permit 192.168.10.250 log
OF_01(config)# access-list 10 deny   192.168.10.0 0.0.0.255 log
OF_01(config)# snmp-server community roedorta ro 10
OF_01(config)# snmp-server community rwedorta rw 10

Con la primera línea creamos una ACL estándar indicando que se permite tráfico con IP de origen 192.168.10.250, y que cada vez que encuentre un paquete que coincida con esta regla lo registre. Obviamente esta IP es la de nuestra NMS. A continuación le indicamos que deniegue todo el tráfico de la red 192.168.10.0 /24 y que si hay alguna coincidencia lo registre también. Hay que decir que las entradas de las ACL se comprueban de forma secuencial y cada vez que un paquete coincida con alguna regla se deja de comprobar las restantes. Por ello aunque la segunda prohíba el tráfico de la red en la que se encuentra la NMS como la primera lo permite la dejará pasar.

Con las otras dos definiremos las comunidades  de lectura y lectura-escritura y aplicaremos la ACL 10, que es la que hemos definido previamente.

Así que si ahora repetimos la operación veremos que no sólo no es posible subir la configuración manipulada:

Sino que además, al ponerle el log quedará registro de ella en la consola del switch. A continuación vemos cómo se ha permitido tráfico de la IP 192.168.10.250, la NMS, y en cambio se ha denegado tráfico de la IP 192.168.10.22 que es desde la que ejecutamos Caín.

Obviamente el mensaje aquí no es cómo hacerle la faena al administrador de turno o comprometer equipos de red, que también, sino mostrar cómo nuevamente, los equipos de red deben ser configurados de forma correcta y que, de no hacerlo, pueden llegar a tener sus «debilidades». Debilidades que alguien puede aprovechar. Aquí hemos puesto un ejemplo tonto, cambiar el nombre del equipo, pero imaginar lo que podríamos haber hecho si configuramos un puerto como puerto espejo de otro al que sabemos que está conectado el equipo de alguien que pueda manejar información sensible o de especial interés, capturando todo el tráfico que nos llegue. Luego con un poco de paciencia, wireshark, sus filtros y otras aplicaciones como Xplico, puees….. tarde o temprano seguro que encontramos algo interesante. O como decía antes, cambiar la configuración de otros protocolos de red como VRRP, HSRP, OSPF, STP, etc. etc. etc. y DoS al canto Pues que nos la pueden preparar, y bien preparada.

En fin, creo que por hoy esto es todo, así que nos vemos en la siguiente entrega.

Seguiremos informando…

Peligroso SNMP Parte I

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