IX Congreso Internacional de Ciberseguridad Industrial. Fortinet & Nozomi Networks.

Los pasados 4 y 5 de octubre se celebró en Madrid el IX Congreso Internacional de Ciberseguridad Industrial organizado por el Centro de Ciberseguridad Industrial. En él, un año más, se dieron cita profesionales, expertos e instituciones con el fin de compartir dos jornadas cargadas de puntos de vista, investigaciones, nuevas líneas de productos, casos de éxito, mesas redondas y momentos para el networking empresarial donde intercambiar y hacer nuevos contactos.

A diferencia de las dos ediciones anteriores, este año acudía no sólo como espectador sino, además, como ponente. Allá por el mes de mayo tuve la oportunidad de participar en “La voz de la Industria”, pero esta vez tocaba hacerlo con proyección internacional.

Dicha ponencia se hizo en conjunto con miembros del equipo de profesionales de  GrupoCMC,  Fortinet y Nozomi Networks siendo cada uno de ellos Jose Luis Laguna, Director Técnico de Fortinet Iberia; Antonio Navarrete, Ingeniero Pre-venta; y Edgar Capdevielle, como CEO de ésta última y un servidor como GrupoCMC.

CCI_01

El tema de nuestra presentación era “Demostración práctica de protección de un escenario de automatización industrial” donde simulamos el funcionamiento de una presa hidroeléctrica empleando para securizarla con equipos específicos como Fortinet Fortigate Rugged 90D y solución SCADAGuardian. Ahora bien, ¿cuál fue nuestro discurso para ver la necesidad de ambos? Comencemos.

Bajo mi punto de vista y basándome en lecciones aprendidas (prácticas, no teóricas) en proyectos planteamos que la actualización de equipamiento porque sea más seguros no es una prioridad. Las empresas no los cambian porque incorporen tal o cual medida de seguridad, lo hacen porque la función que realicen lo requiera. Además, puede no es fácil llevarlas a cabo ya que la implementación de unas u otras tecnologías puede necesitar ventanas de tiempo amplias. Por ejemplo, pensemos una migración de una arquitectura RS-485 a una Ethernet. En otro orden, por muy planificados que estén los trabajos, cualquier intervención no deja de introducir un riesgo que desemboque en un impacto en la actividad siendo éste inasumible.

Es por ello que la Seguridad Perimetral sigue siendo la primera medida. ¿Por qué? Porque permite reducir los riesgos en una primera instancia sin la necesidad de actuar sobre esos equipos finales desactualizados, sin soporte en algunos casos, sin compatibilidad con soluciones de seguridad, con largos ciclos de vida, que por su criticidad sea inviable actuar sobre ellos para aplicar parches, con desarrollo de aplicaciones propias, y un largo etcétera. Además, permite atajar la propagación de amenazas o incidentes a través de filtrado de tráfico junto con funciones avanzadas como Control de Aplicación, Antivirus, Filtrado Web o IDS/IPS. Sí filtrado web. Hay equipos que permiten ciertas funcionalidades a través de servidores web embebidos a los que les pueden afectar las mismas vulnerabilidades con la dificulta que, o no pueden ser corregidas, o supone la actualización completa de firmware o software.

Por supuesto, esto último respaldado con un buen diseño y arquitectura de red ya que de nada nos sirve incorporar un equipo último modelo, si luego tenemos una red plana o enrutada…

Aparte de lo anterior, otra de las necesidades que veíamos era la inclusión de medidas en materia de visualización y monitorización. No me refiero a solucione SCADA, sino a nivel de red. De tráfico.

La Industria 4.0 trae consigo una buena cantidad de beneficios no sólo por los avances tecnológicos como fabricación aditiva, robótica colaborativa, simulación, etc. sino la inclusión de las Tecnologías de Información para mejorar los procesos convirtiendo las fábricas en más productivas, competitivas, eficientes energéticamente, etc. Esto requiere tener una visión de lo que ocurre en nuestras instalaciones, consiguiéndose mediante la recolección de información tanto en tiempo real como en cortos espacios de tiempo y a partir de ahí corregir desviaciones o tomar otro tipo de medidas. Ahora bien, para alcanzar ese propósito los equipos deben de estar interconectados y en el momento que esto se produce, todos comienzan a estar expuestos. Y como bien sabemos, una medida para reducir los riesgos es reducir justamente el grado de exposición.

Junto con ello los flujos de tráficos deben ser un reflejo del proceso. Nada que no forme parte de la actividad propia, debe existir. Sólo lo estrictamente necesario.

La contextualización de la información también debe estar presente. Tenemos que tener una visión amplia de lo que sucede. Si hablamos de una fábrica de producción en serie, el fallo en un equipo instalado en una línea a priori no debería afectar a otra. Pero si ese problema no se resuelve dentro de los tiempos máximos podría dejar de suministrar piezas o material a esta última provocando unas consecuencias mayores.

Finalmente, conviene diferenciar entre información e inteligencia sobre amenazas. Debemos pararnos a pensar que no toda la información que obtenemos con esta monitorización puede ser del todo útil. Por ello cara a recolectar datos debemos analizar la calidad de la información; su origen; cantidad; relevancia para la organización, sistemas y entorno; capacidad para recolectar, correlar o analizar; y finalmente, cómo la aplico. Es decir, si no hago nada con ella, ¿para qué conseguirla?

Si sumamos ambos aspectos, por un lado, la seguridad perimetral y por otro la necesidad de monitorización, es que encontramos el beneficio de contar ambos productos destacando entre otros aspectos:

Fortinet Fortigate:

  • Gama productos específicos para entornos industriales.
  • Diseño rugerizado capaz de soportar entornos hostiles con polvo, humedad y temperatura muy superiores a entorno IT tradicional.
  • Electrónica de alto rendimiento.
  • Integración con soluciones de gestión centralizada.
  • Deep Packet Inspection sobre protocolos industriales.
  • Montaje sobre carril DIN y alimentación por fuentes de alimentación externas.

Nozomi SCADAguardian:

  • Solución diseñada para entornos industriales.
  • Identificación de activos y protocolos
  • Detección de anomalías en flujos y tipos de tráficos.
  • Instalación pasiva no introduciendo latencias adicionales.
  • Evaluación de vulnerabilidades a partir de información recolectada.
  • Detección de amenazas, riesgos e incidentes.
  • Variedad de paneles de control y generación de informes para análisis y labores forenses.

Sin embargo, el mayor de los beneficios está por anunciar. Y es que a pesar de los beneficios de ambos por separado, tanto Fortinet  como Nozomi Networks han alcanzado un grado de integración tal que, en caso de SCADAguardian detecte una anomalía a partir del análisis de tráfico, puede interactuar de forma automática con los equipos Fortigate configurando una regla en los firewalls que deniegue el tráfico anómalo identificado.

Esto introduce un grado adicional de protección ya que permite atajar cualquier incidente en el mismo instante que se produce reduciendo así el tiempo transcurrido desde que una amenaza es detectada, interpretada, valorado el alcance, puesta en marcha su mitigación, resolución y extraídas las conclusiones. Sin embargo, esto no es fácil ya que lleva aparejado una importante labor desde el punto de vista que debemos conocer qué activos y protocolos tenemos en nuestra organización para saber cuáles son legítimos o cuales no; definir tendencias y patrones; sopesar de qué forma SCADAguardian va interactuar con los Firewalls, esto es, bloquear IPs, cerrar sesiones, y un largo etcétera.

Como decía anteriormente para demostrar este valor añadido, ideamos una réplica de lo que podría ser una presa hidroeléctrica. En la imagen siguiente se ve el esquema de la simulación en la que aparece un taque donde se acumula el agua. Luego, se abre una electroválvula que, al abrirse, deja pasar el agua haciendo mover una turbina que es la que genera electricidad para  ser almacenada en el tanque inferior. Finalmente, se acciona una bomba que impulsa de nuevo el agua al tanque superior, para volver a repetir el proceso.

Escenario lógico

La lógica está gestionada por un equipo TRIDIUM JACE el cual cuenta con una interfaz web para labores de administración. Tanto la electroválvula como la bomba están conectadas al equipo TRIDIUM SEDONA el cual recibe las órdenes de abrir/cerrar y paro/arranque del JACE por medio del protocolo ModbusTCP.

Escenario lógico_01

Y todo ello en la realidad quedó en….

CCI_03

Así pues, lo que se hizo en vivo y en directo fue llevar a cabo un ataque sobre el TRIDIUM Sedona enviando paquetes específicos ModbusTCP desde un PC que provocada el paro de la bomba o el cierre de la electroválvula. Esto es posible debido a la falta de medidas de seguridad nativas de dicho protocolo.

Más tarde, para ver la efectividad de ambas soluciones trabajando conjuntamente se incorporó el equipo SCADAguardian el cual recibía el tráfico desde un puerto espejo de un FortiSwitch. Luego tras la integración de Fortigate Rugged 90D en aquél, se repitió nuevamente el ataque no teniendo éxito ya que al considerarse que provenía de un equipo no legítimo, SCADAguardian lo consideraba como “malicioso” enviando la orden al Firewall de la generación de una regla que lo cortase. Impedía así que llegase el paquete al TRIDIUM Sedona y por tanto evitando el cierre o paro de los dispositivos.

Obviamente este fue una prueba de concepto, sin embargo en un entorno real esta tarea llevaría más tiempo. Sería necesario dejar aprender durante unos días o semanas el comportamiento de la red para poder establecer qué tráficos son buenos y cuáles no. También la manera en la que queremos que se comporte el Cortafuegos, esto es, cortar sesiones, bloquear IP, etc. etc.

A continuación os dejo un video elaborado por Fortinet donde se explica todo ello. ¡Excelente!

Quedamos muy satisfechos con la exposición ya que aparte de lo original, práctico y puesta en escena todo salió muy bien. No quería pasar por alto agradecer a mis compañeros de GrupoCMC que diseñaron la interfaz gráfica y metieron horas para que todo saliese en esta línea. Sin ellos, su conocimiento, experiencia y sobre todo su actitud; esto no hubiera sido posible. Como no, a Jose Luis, Antonio y Edgar por los esfuerzos, trabajo e iniciativa; a Jose Valiente, Miguel García-Menéndez y Susana Asensio por la organización de este congreso de referencia; y finalmente a los asistentes que esperamos fuese de su agrado esta exposición en la que se invirtió tanto tiempo como ganas de haber proporcionado una forma automática, rápida y eficiente de proteger nuestros entornos de control y automatización industrial sea cual sea su naturaleza o criticidad.

CCI_02

Un abrazo!!

Puerto espejo, un aliado a veces olvidado.

Como hemos hablado en otras ocasiones, poco a poco se va extendiendo el uso de protocolos industriales basados en tecnología Ethernet en lugar de los tradicionales serie. Esto, si bien permite otra manera de interconexión, también abre nuevas posibilidades en la denominada Industria 4.0. Sin embargo, obliga a tomar cierto tipo de medidas en cuanto a Ciberseguridad se refiere ya que los dispositivos y sistemas que intervienen en los procesos de control y automatización no sólo comienzan a estar más expuestos sino que son susceptibles de sufrir los mismos problemas con ciertos agravantes.

No obstante, aunque se trate de comunicaciones Ethernet, los equipos de networking industrial no sólo conservan funcionalidades tradicionales, sino además otras propias de estos entornos como MRP en contraposición a STP, Spanning Tree Protocol.

Una que puede sernos de mucha utilidad, sin menospreciar a otras tantas, es la de “Port Mirroring” o Puerto Espejo. Esto es, la capacidad de un Switch para poder replicar el tráfico que pasa por dos o más puertos y enviarlo por un tercero. Para entender mejor este concepto haré un repaso sobre cómo funciona un switch. Aunque sea algo bastante obvio para Técnicos de Comunicaciones o Administradores, seguramente no lo sea tanto para otros de Mantenimiento o Ingenieros de Procesos.

Esquema_01

Pongamos un ejemplo con dos equipos llamados “HMI” y “PLC”. Para comunicarse el equipo “HMI” con el “PLC” deberá conocer la IP del de “destino” y, al darse cuenta que está dentro de su misma red, deberá obtener entonces la MAC de éste. Para ello echará mano del protocolo ARP. El protocolo ARP permite conocer la dirección MAC de un equipo a partir de una IP conocida. Por tanto, si “HMI” no la tiene almacenada en su caché ARP  deberá realizar un ARP request. Es decir, preguntará a toda su red sobre cuál es la MAC del equipo con IP XXX.XXX.XXX.XXX. En este caso la dirección MAC de destino será ff:ff:ff:ff:ff:ff, un broadcast de capa 2. Todos los equipos la recibirán y la procesarán pero sólo el que tenga la IP por la cual se pregunta contestará con un ARP Replydiciendo “–La MAC de la IP XXX.XXX.XXX.XXX es XX:XX:XX:XX:XX:XX. Conocida por “HMI” tanto la IP y MAC de “destino”, se producirá la comunicación. Si por el motivo que sea no se conocen algunos de estos campos, la comunicación no se produce.

Así pues, un Switch, a diferencia, de los Hubs introduce un nivel de “inteligencia”. Un switch contiene una tabla, denominada CAM (Content-Addresseable Memory) en la cual se incluyen las direcciones MAC de cada uno de los equipos conectados a los distintos puertos del switch. Para realizar las tareas de conmutación, acudirá a ella para saber por cuál de ellos deberá enviar el tráfico en función de la MAC de destino. Esta asignación de direcciones MAC podrá hacerse de forma dinámica o manual. La forma manual implica que el administrador asigne a cada puerto del switch la MAC del equipo conectado; mientras que la forma dinámica se basa en que por cada trama que ingrese por cada boca del switch, éste mirará la MAC de origen y la incluirá en la CAM. Pasado cierto tiempo, si no se recibe tráfico se borrará dicho registro. Así, a la hora de efectuar la comunicación, los switches se fijarán en la MAC de destino, consultarán dicha tabla para saber por qué puerto deben enviarla y la “despacharán”.

Ahora bien, si por distintas razones necesitásemos conocer el tráfico que pasa en entre “HMI” y “PLC”, no podríamos conseguirlo ya que el switch sólo conmuta el tráfico por los puertos involucrados. Aquí es donde aparece el concepto de “Port Mirroring” o “Puerto Espejo”. Mediante esta funcionalidad lo que conseguimos es que el switch haga una copia de dicho tráfico y lo envíe por un tercer puerto. ¿Con qué finalidad? Por ejemplo, si en este último conectamos un analizador de tráfico, podremos estudiar todo aquello que suceda entre “HMI” y “PLC” y detectar posibles anomalías sin interferir entre el flujo de comunicaciones. Obviamente el switch tiene que tener esta capacidad para hacerlo, sino… no hay nada que hacer.

Si bien las tasas de transferencia en entornos OT son menores que en entornos IT, esto no quita que debamos tener presente algunas consideraciones. Por ejemplo, si las comunicaciones son Full-Duplex (enviar y recibir a la vez) y el enlace es de 100 Mbps, el tráfico que puede llegar a recibir un equipo es de 200 Mbps, 100 Mbps para enviar y otros 100 Mbps para recibir. Si el enlace del puerto espejo es también a 100 Mbps el consumo de ancho de banda entre “HMI” y “PLC” no puede ser superior al 50%, ya que estaríamos superando la capacidad del mismo. O bien, que sea de una velocidad inferior, por ejemplo, a 10 Mbps. En esos casos, el switch descartaría paquetes con lo que el tráfico capturado no se correspondería con la realidad. Aparte, claro está, de la carga computacional que supone para la CPU del propio switch la copia de las tramas. A esto hay que sumar otras limitaciones que cada fabricante pueda considerar en sus productos.

Sin duda es un buen recurso, pero como comento, hay que tener en cuenta algunos aspectos técnicos.

A continuación, pondré ejemplos sobre su implementación en equipos. En la siguiente imagen se muestra una captura de la configuración de un switch Mikrotik RouterBoard 260GS, el cual dispone de 5 puertos RJ-45 10/100/1000 + 1 SFP.

config Mikrotik RouterBoard_01

Según cómo está configurado, estaríamos haciendo una copia del tráfico tanto saliente como entrante del puerto 1 que es dónde en teoría habría conectado un PLC y la enviaríamos por el puerto 2 donde conectaríamos un sniffer que lo recogería para un posterior análisis. Un clásico de este tipo de funciones es el archiconocido Wireshark. También podríamos seleccionar sólo uno de los sentidos, o bien el saliente o entrante según sean nuestras necesidades.

Captura Wireshark_01

Lo cierto es que ese dispositivo resulta de mucha utilidad ya que por su pequeño formato puede ser utilizado en tareas sobre equipos finales como supervisión, diagnóstico, troubleshooting, etc. Aparte, al disponer de un módulo SFP podremos conectarlo a enlaces de fibra o par de cobre.

Ya sobre equipos de red tradicionales, podemos poner un ejemplo con switches Cisco. La funcionalidad la recoge este fabricante como puerto SPAN (Switched Port Analyzer). Aquí las posibilidades, como es lógico, son mayores y pasamos a la interfaz de consola. Podéis encontrar más información en este enlace.

Hasta ahora hemos visto switches “tradicionales”, sin embargo otros específicos de entornos OT también poseen esta funcionalidad como los muestra SIEMENS en este enlace y de donde se extraen las siguientes imágenes.

SIEMENS_Port_Mirroring_01

SIEMENS_Port_Mirroring_02

Sin embargo esto no es exclusivo de equipos de networking. Por ejemplo, el fabricante Fortinet la incluye en sus dispositivos. A continuación se muestran capturas sobre un FortiWifi 60D con versión de FortiOS 5.4.5. Como podemos ver la forma de acceder a ella es a través del apartado de “Interfaces”.

Fortigate SPAN_01

En mi caso “HW_SW_01”, y ya en su configuración veremos el campo correspondiente:

Fortigate SPAN_02

Como vemos el criterio es similar, interfaz a monitorizar y a hacia cuál queremos enviar la copia de los paquetes. Haciendo una prueba, he conectado en el puerto “internal1” un servidor Modbus (10.10.10.100) y desde el puerto “internal2” (10.10.10.200) el cliente desde cual hacer las lecturas. Finalmente, un equipo con Wireshark en el puerto “internal3” donde capturar el tráfico.

Wireshark_Modbus_01

Un caso de uso podría ser en un equipo donde se le aplique una estrategia de “Virtual Patching” y necesitemos saber qué es lo que está sucediendo desde, hacia, él. Hace tiempo escribí a este respecto, os dejo los enlaces:

Hasta aquí la entrada de hoy con la que espero hayáis podido descubrir una nueva funcionalidad de vuestros equipos. Puede que escondida, pero seguro de utilidad en un futuro. Las aplicaciones pueden ser varias, espero poder escribir sobre alguna de ellas. Sólo falta tiempo.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta

Syslog, ¿amigo o enemigo? Parte II

Aquí volvemos con la segunda parte. Como dijimos en el post anterior Syslog, ¿amigo o enemigo? Parte I, a continuación veremos que también puede tener inconvenientes …

Ahí va la primera!

Syslog emplea UDP, concretamente el puerto 514. Al emplear UDP podríamos generar fácilmente paquetes manipulados haciéndonos pasar por el equipo legítimo. Éstos los enviamos al servidor y conseguiríamos confundir, o engañar, a los administradores informando de supuestas actividades en los equipos que en realidad no están sucediendo. Y ¿con qué fin? Por ejemplo obligar a un administrador a que se conecte al supuesto equipo que está fallando. Ahí podríamos llevar a cabo un MITM o cualquier otro ataque factible que nos permitiese capturar, por ejemplo, las credenciales de este administrador que por otro medio no podríamos. Y aquí es donde quedaría incluida la idea que hablaba al inicio, la 1. Es decir, si directamente no podemos hacernos con ese usuario y contraseña, vamos a generar falsas alarmas para obligarle a que se conecte y mediante otro ataque cumplir con el objetivo inicial.

Vale, y esto, ¿cómo lo hacemos?

Pues con el generador de paquetes Mausezahn. No viene instalado por defecto en Kali, pero desde el instalador de software lo podemos hacer fácil.

Aquí os dejo algunos tutoriales que he encontrado, Link 1 , Link 2 , Link 3

Supuesto apagado de varias interfaces.

Captura de pantalla de 2015-03-22 15^%30^%37

Captura_Syslog_05

O bien podríamos decir que un Switch tiene una temperatura > 70º C. Aquí le introduciremos un retardo de 60 segundos entre mensaje y mensaje de forma indefinida. Ver columna de tiempo, la diferencia es de un minuto.

Captura de pantalla de 2015-03-22 15^%30^%04

Captura_Syslog_06

La segunda desventaja…

Basándonos en la primera, ¿qué pasaría si en lugar de mandar paquetes sueltos mandásemos 30, 50, 100, 200? ¿y si encima lo hiciésemos a intervalos distintos? Y para más difícil, que pasa si además lo hacemos supuestamente desde equipos distintos? Pues yo me volvería loco. Imaginaros la situación, empezar a recibir mensajes (que de normal no llegan) desde distintos equipos de la red. Vamos sembramos la confusión, y entre esa confusión un atacante podría iniciar otro ataque contra otro equipo. Es decir, el atacante desvía la atención del administrador hacia unos equipos que se supone están fallando, pero que en realidad no es así, y de mientras inicia un ataque contra otro sistema. Y además si éste equipo atacado genera algún tipo de alarma es más probable que pase desapercibida ya que estaremos generando un montón de otras falsas. Y aquí es donde incluiría la segunda idea, la 2. Esto es, generamos mucho ruido, provocamos que salten las alarmas y entre todas ellas nos camuflamos.

Captura de pantalla de 2015-03-22 15^%37^%00

Captura_Syslog_07

Estos ejemplos los he hecho utilizando un router que es lo que tengo más a mano, pero bien podría ser otros dispositivos.

Por ejemplo, los autómatas industriales también soportan Syslog. En el siguiente enlace podréis encontrar como lo aplican los de la gama Siemens S7-300.

Autómatas S7-300

Envío de mensajes Syslog en S7 CPUs

Library description: Sending SYSLOG messages with a SIMATIC S7 CPU

¿Y si en lugar de mensajes de un router mandamos haciéndonos pasar por un autómata? Os imagináis que pasaría si en una estación de transformación llegasen mensajes diciendo que una línea eléctrica se ha caído cunado no es así? ¿O que una entrada de un autómata está DOWN mientras que todo sigue funcionando?

Por ejemplo podríamos hace pensar que se podría estar llevando un ataque aprovechando un vulnerabilidad de los autómatas cuando no es así. Esto seguramente cuando poco sembraría una confusión que conllevaría un revuelo en mayor o menor medida y quién sabe si la toma de alguna decisión si haber ninguna necesidad. Ni qué hablar que tal vez paralelamente  sí que estuviesen llevando un ataque en sí mismo.

En fin es para pensarlo, bueno o malo que cada cual emplee Syslog según sus criterios y decida si es un amigo un enemigo.

Un saludo.

Syslog, ¿amigo o enemigo? Parte I

Hola de nuevo, aquí estamos con otra entrada. A decir verdad, me cuesta un poco la manera de catalogarla si como un ataque en sí mismo o bien como como un ataque que sirva de pantalla a otro. Bueno, principio quieren las cosas, así que vamos a ello.

Vamos a dejar momentáneamente las cuestiones técnicas a un lado para charlar un poco de otros conceptos. Cuando se trata de auditar o realizar un test de penetración no siempre hemos de ir directos contra nuestro objetivo. Esto es, quizás debemos comprometer primero un equipo o sistema y luego desde éste, dirigirnos al objetivo en cuestión. ¿Qué es lo que quiero decir con esto? Que muchas veces deberemos dar un “rodeo” o dar pasos “intermedios” para conseguir nuestro fin. Este es el concepto número 1.

Una vez dentro de ese proceso de “pentesting” una premisa es hacer el menor “ruido” posible para no ser descubierto ya que eso mismo es lo que trataría de hacer un atacante. Un atacante, procurará ser sigiloso, discreto, cauto, no sólo para no levantar sospechas sino para que las distintas medidas y equipos de seguridad no hagan saltar alarmas y delaten su presencia. Obviamente, no empleará configuraciones “por defecto” sino que modificará los parámetros, campos, según sus necesidades. Sin embargo, esto no tiene por qué ser siempre así. Me explico. La idea es que no te detecten, pero esto también puede lograse haciendo mucho ruido y colándote entre la multitud. Imaginemos a un ladrón que ha conseguido burlar las medidas de seguridad de un banco; se hace con el botín; tira una bomba de humo o gas lacrimógeno y hace que todos los clientes entren en “modo pánico” y salgan despavoridos de la oficina, entre ellos, el ladrón. Este es el concepto número 2.

Bueno, se me olvidaba. Para que el ladrón burle las medidas de seguridad una buena opción podría ser suplantar la identidad (spoofear) de algún miembro del personal del banco. Este es el concepto número 3.

Vale, vale, tanto rollo ¿para qué? ¿Qué tiene que ver esto con Syslog? Venga va, ahora sí nos metemos con las cuestiones técnicas.

Syslog es un protocolo con el que podemos hacer que un equipo o sistema (cliente) envíe a un servidor mensajes que informen sobre eventos en él. Entre otras cosas, podría ser:

1.- Acceso correcto o incorrecto al sistema.

2.- Anomalías de algún tipo.

3.- Cambios en las configuraciones.

4.- Errores en los sistemas.

5.- Otros…

Existen servidores de pago y también algunas versiones gratuitas como Free Kiwi Syslog Server u otros que podréis encontrar en Sourceforge. Iros allí y buscar por la palabra, como es lógico, Syslog.

Para esta entrada voy a tener 3 equipos. Un router virtualizado con GNS3, un servidor Syslog con el software Free Kiwi Syslog Server y un equipo con Kali Linux. Estos últimos en máquinas virtuales.

Esquema Blog Syslog

Aquí os dejo una muestra de lo que sería mensaje de un login del usuario “netadmin” al router.

Captura_Syslog_02

Deshabilitar y habilitar de la interfaz Fastethernet 1/1.

Captura_Syslog_03

El tipo de mensaje que recibamos irá en función del nivel de aviso que queramos que se nos comunique. A más nivel, mayor control de lo que pasa pero también tendremos más cantidad de mensajes y, dependiendo el número de equipos, que tengamos pues puede llegar a ser un poco caótico.

Esto es yendo a buenas pero ¿qué pasaría si alguien intentase lanzar un ataque para ganar acceso a nuestro equipo mediante la herramienta THC-Hydra?

Por cada intento de conexión recibiremos un aviso.

Captura_Syslog_04

Una de las posibilidades que nos puede ofrecer el software de servidor Syslog es que cada aviso que recibamos podremos enviarlo a su vez por correo electrónico, lo cual puede llegar a ser de gran utilidad si creamos una cuenta específica para el servidor y recibimos los avisos a nuestro correo. Lo digo no para dar más trabajo sino para esos puestos que requieran hacer guardias o disponibilidad 24×7, etc.

Sin embargo, ¿son todo ventajas? Tal vez no, puede haber algún inconveniente. Eso lo dejamos  para la próxima….

 

 

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