Continuando la entrada anterior hoy vamos con esas pruebas que he hecho contra Conpot y de cómo éste se ha comportado.
A continuación veremos lo sucedido cuando he accedido por el puerto 80 desde un navegador.
A partir de aquí los log que revelan nuestro acceso.
Hasta aquí podríamos interpretarlo como algo relativamente común. Pero en el ejemplo que sigue requiere conocimientos técnicos y una buena dosis de premeditación y alevosía. Si desde otro equipo ejecutamos un escáner para detectar servicios sobre la IP ejecutando conpot:
Como podemos comprobar el honeypot recoge información como el tipo de paquete, datos del contenido del mismo, IP de origen, etc.
¿Un equipo enviando un paquete a un Honeypot bajo protocolo S7comm? Esto chirría un poco…
Otra de las posibilidades que tenemos es ejecutar alguno de los escáneres disponibles en Metaesploit en auxiliary/scanner/scada
Aquí detectaremos el servicio de Modbus en lugar de S7comm.
Finalmente otras de las pruebas que hice fué sobre SNMP. Desde Metaesploit lancé una enumeración mediante este protocolo.
Y sus respectivos logs.
También podríamos cambiar un OID de SNMP. Por ejemplo la dirección de correo:
Y registro de ello.
Como podemos comprobar Conpot puede ser de gran ayuda para detectar comportamientos anómalos en nuestra red y que vayan dirigidos específicamente a nuestros sistemas de control. Obviamente esta es una Prueba de Concepto y cara a su despliegue en nuestras instalaciones deberemos personalizarla para dar una mayor credibilidad en los resultados.
Con el creciente aumento de las amenazas y publicaciones de vulnerabilidades que afectan a entornos con estos equipos, tener un Honeypot que simule uno de ellos es necesario cara a localizar posibles brechas de seguridad. Obviamente trabajamos para no tenerlas y minimizar los riesgos, pero no estamos exentos de que algo, o alguien, pueda acceder a nuestra red y lleve a cabo algún tipo de acción malintencionada. Para esos casos, aquí tenemos un aliado.
Como es lógico, esta herramienta no nos protege de nuestras vulnerabilidades, pero sí nos avisa. El uso más común será detectar tráfico y comportamientos fuera de lo común en este tipo de redes pero no estaría de más poner uno en la red de oficinas. No sea cosa que el enemigo nos venga por ahí. También nos puede ayudar cara a la realización de auditorias detectando posibles actividades no conocidas en las instalaciones de nuestros clientes y que puedan poner en peligro la disponibilidad de sus instalaciones.
En mi caso he utilizado una máquina virtual pero hay quién lo ha instalado en una RasperryPi, lo cual ya veis los recursos técnicos y económicos que requiere…
Aquí os dejo un enlace del SANS donde encontraréis una guía sobre cómo diseñar e implementar un Honeypot en un entorno SCADA.
Saber las técnicas que emplean los atacantes contra nuestras infraestructuras y sistemas es clave para saber cómo protegernos. Nos da una idea de los métodos, vías, lugares y procedimientos que siguen para alcanzar sus propósitos y desvelar vulnerabilidades, errores en configuraciones, políticas de seguridad mal implementadas y un largo etcétera.
Para ello, una de las estrategias que podemos seguir en la instalación de los que conocemos como “Honeypot” o “Tarro de miel” en la lengua de Cervantes. Un Honeypot es un equipo o software cuya finalidad es atraer a los atacantes simulando ser un equipo vulnerable registrando la actividad llevada a cabo sobre él. Tras un análisis posterior, u online, podremos obtener información sobre los distintos puntos enumerados en el párrafo anterior.
Con la llegada de protocolos basados en Ethernet y servicios basados en TCP/IP en las comunicaciones industriales, la exposición que han sufrido los Sistemas de Control Industrial ha ido en aumento. Esto provoca que haya que adoptar nuevas medidas de seguridad que antes no se contemplaban. Prueba de ello es el paso de estrategias como el “Air gap” a la “Defensa en profundidad”. Dichos sistemas no están exentos de poseer vulnerabilidades que permitan a un atacante llevar a cabo algún tipo de acción que los comprometa, o deniegue su servicio aprovechándose de recursos hardware más limitados. Pero ojo, sin olvidarnos de las estaciones que los gobiernan. PCs con sistemas operativos tradicionales de los que, por un lado pueden no tener soporte, y que si lo tienen no cuentan con los últimos parches; y por otro, software a veces innecesario y si lo es, también no está a la última versión.
Es por esto que hoy hablaremos de un Honeypot para Sistemas de Control Industrial, Conpot. Conpot, como indica la página web del proyecto, es un servidor interactivo de Sistemas de Control Industrial diseñado para ser fácil de desplegar, modificar e implementar, proporcionando un amplio rango de protocolos que permiten construir tu propio entorno capaz de convencer a tu “adversario” de que está frente un enorme y complejo sistema industrial. Para mejorar las capacidades de engaño también se proporciona la capacidad de simular una HMI personalizable y ampliar así la superficie de ataque. El tiempo de respuesta de los servicios también puede ser alterado para imitar el comportamiento de un equipo frente a un aumento de la carga y consumo de recursos. Gracias a una completa pila de protocolos, Conpot puede ser accesible por HMI reales o ampliado el hardware real. Finalmente, todo ello bajo el amparo de Honeynet Project
A continuación os dejo el video presentación:
En el siguiente ejemplo he instalado Conpot en una distribución Kali Linux 2016.1, aunque podremos utilizar la que más nos guste aunque primero debemos resolver algunas dependencias. En mi caso he tomado las requeridas para Ubuntu 14.04 LTS y Debian.
Para empezar añadí los repositorios de la versión Kali 2.0 para poder instalar los paquetes snmp-mibs-downloader que con los que vienen por defecto para 2016.1 no lo hace. Entiendo que al ser “non-free” o los instalamos a mano o recurrimos a otras vías como ésta. Entre una cosa y otra al final el fichero /etc/apt/sources.list quedó con el siguiente contenido:
Descomprimimos el fichero y mediante el siguiente comando lo instalamos:
python setup.py install
Los distintos ficheros y directorios los encontraremos en:
Para su funcionamiento se cuenta con un fichero de configuración nombrado conpot.cfg donde podremos definir, entre otros, algunos parámetros como por ejemplo cambiar la dirección MAC en la interfaz de red que elijamos, o indicar un servidor Syslog para consolidad todos los logs generados en un servidor y así poder llevar a cabo las labores de análisis forense. Al fin y al cabo esta es una de las funciones para las que está pensado, ¿no?
Luego, dentro de las carpetas “templates” encontraremos los distintos escenarios que nos vienen por defecto y que podremos simular.
Para mi ejemplo voy a utilizar el “default” que simula un PLC S7-200, con acceso vía HTTP, Modbus, s7comm y SNMP. A continuación indico el enlace donde se detallan las configuraciones que podremos hacer sobre los mismos bajo este “template”.
Esta herramienta también nos da la posibilidad de hacer de un HMI accesible por HTTP y que nuestro Honeypot lo represente, bien creando una nosotros o copiándola de otra ya creada (hmi_crawler). Las instrucciones las podemos encontrar aquí:
Como decía, en el siguiente caso he utilizado el template “default”. Sin embargo he cambiado algunos parámetros dentro del fichero “template.xml” para darle un toque más personal.
Para que sean visibles vía web deberemos editar el fichero index.html dentro de templates/default/http/htdos e incluir los valores que acabamos de configurar.
Para “lanzar” el honeypot ejecutaremos:
conpot –t default
También podemos ver los sockets abiertos:
A partir de aquí lo que hagamos contra nuestro equipo ficticio quedará registrado en un fichero denominado conpor.log o bien en uno distinto mediante el parámetro –l.
Hasta aquí la entrada de hoy. Para la próxima mostraré los efectos de distintas acciones sobre el honeypot y los resultados obtenidos.
Lo dicho, nos vemos en la próxima, por ahora a instalar conpot y familiarizarse con su capacidades.
Una de las primeras fases de cualquier auditoría es la realización de una fase de escaneo de red con el fin de localizar equipos activos y detectar puertos abiertos, versiones de software, sistemas operativos, etc. Para ello contamos con muchas herramientas, entre ellas de la que hablaré hoy, SPARTA
SPARTA es una aplicación escrita en Python mediante una interfaz gráfica que simplifica la tarea de la que hablábamos anteriormente, permitiendo al auditor ahorrar tiempo teniendo una única aplicación desde la cual poder visualizar los resultados y analizarlos a posteriori.
Entre sus características destacan:
Ejecutar nmap o importar los resultados desde un fichero XML
Plataforma única donde visualizar resultados
Menús contextuales para cada servicio descubierto.
Posibilidad de correr cualquier script o software contra un servicio sobre equipos objetivo.
Definir tareas automatizadas para servicios.
Capacidad para realizar intentos de logueo con credenciales definidas de forma personalizada o por defecto.
Identificación de host sobre los cuales ya se han realizado algún tipo de acción.
Otras muchas más…
Si bien la aplicación ya viene instalada en la distribución Kali Linux el procedimiento de instalación es la siguiente:
Sparta cuenta con un fichero de configuración situado sparta.conf. La aplicación verificará la existencia del mismo y si no lo encuentra lo generará de forma automática. En Kali lo tendremos en /etc/sparta.conf
Allí podemos encontrar las lo que se denominan las “Actions”, esto es aquellos que se ejecutará sobre :
Host Actions: Será la que se ejecutará cuando hagamos “botón derecho” sobre un equipo concreto y cuyo resultado será almacenado y visualizado en la interfaz de Sparta.
Port Actions: Idem pero con un puerto.
Terminal Actions: Lo mismo pero en este caso el resultado será exportado en un terminal ajeno a Sparta.
Si quisiéramos definir una nueva «Action» deberemos seguir la siguiente fórmula, o bien tomamos como ejemplo las ya creadas por defecto.
tool=label, command, services
Donde:
Tool, identificador único, normalmente el nombre de la aplicación.
Label, texto que aparecerá en el menú contextual.
Command, comando que se introduciría en una Terminal si quisiéramos utilizar la herramienta concreta. Los valores como IP, Puerto y Resultado vendrán por los campos [IP], [PORT] y [OUTPUT], respectivamente.
Services, lista de servicios de nmap sobre los cuales Sparta va a realizar una acción concreta. Si hacemos “botón derecho” sobre un servicio concreto la herramienta sólo mostrará aquellos que esté definidos allí.
Por ejemplo si quisiésemos configurar la herramienta Nikto para ejejcutar una acción sobre un puerto concreto deberíamos añadir lo siguiente:
nikto=Run nikto, nikto -o [OUTPUT].txt -p [PORT] -h [IP], “http,https”
Importante tener en cuenta reiniciar la aplicación una vez realizados cambios en el fichero de configuración.
Por otra parte es posible configurar ataques automatizados ejecutando cualquier herramienta que previamente hayamos configurado en el apartado [PortActions]. Estos ataques automatizados están habilitados por defecto aunque podremos deshabilitarlos editando la opción “enable-scheduler” en [GeneralSettings]. Bajo esta última opción también podremos añadir otros siguiendo el siguiente formato:
tool=services, protocol
Tool, identificador único el cual hemos utilizado para definir la herramienta en el apartado [PortActions].
Services, listado de servicios sobre los cuales actuará la herramienta.
Protocol, protocolo del servicio en cuestión, esto es, TCP o UDP.
Pero como todas cosas mejor verlo con un ejemplo.
En mi caso en lugar de llevar un escaneo desde la propia aplicación lo que haré será realizar uno con nmap mediante su interfaz gráfica Zenmap, exportar los resultado en un fichero .xml y luego importarlo a Sparta.
Con el scan hecho:
Abrimos “Aplicaciones – Recopilación de Información – Sparta”
Luego importamos el scaneo previamente guardado:
Pinchando en la pestaña “Host” veremos los equipos y los “Servicios” localizados en él.
Mientras que el pestaña “Services” veremos todos los servicios detectados en el escaneo.
A partir de aquí, clickando con el botón derecho del ratón sobre el servicio podremos ejecutar otras aplicaciones.
Las mismas se verán en la ventana “logs”:
Y el resultado será:
Ahora bien si lo hacemos sobre un dispositivo “Cisco”, en este caso un router, veremos que las pruebas nos revelan resultados distintos entre ellos el requisito de contraseña de nivel 15.
Otra de las posibilidades de la herramienta es lanzar intentos de logueo online con “THC- Hydra”. Haremos la prueba sobre el equipo router Cisco.
Elegiremos dos ficheros donde tendremos almacenadas nuestros diccionarios y no los que trae por defecto Sparta:
Si quisiéramos guardar nuestros proyectos podremos hacerlo en un fichero identificado como:
Como podemos comprobar Sparta es una herramienta donde podremos aglutinar aquellas herramientas que sean de nuestra utilidad cara a una auditoría o pentest. Como todo deberemos de ajustarla según necesidades o circunstancias ya que las configuraciones por defecto pueden no arrojar los resultados que esperamos. Vamos a verlo.
Según el archivo de configuración dispondremos de los siguientes diccionarios para la prueba con THC-Hydra:
Los cuales comprenden:
Este tipo de listados contendrán palabras generalmente en inglés por lo que resulta vital emplear otros con palabras en nuestro propio idioma. De nada nos sirve emplear el usuario «Administrator» cuando lo más probable es que sea «Administrador».
Otro caso es el escaneo con herramientas desde la propia Sparta como es nmap. Los puertos por defecto son:
Nuevamente volvemos a la misma pregunta, y si los puertos que nos interesan no están en la lista? Nuevamente tenemos que editar…
También deberemos comprobar las acciones bajo [PortActions]
Con la entrada de hoy hemos visto una herramienta que bien nos puede ayudar y facilitar mucho el trabajo, en nuestras auditorias. Además podremos ajustarla a nuestras necesidades concretas mediante la edición de su archivo de configuración, todo desde una única interfaz.
Espero que haya sido de vuestro interés y os invito a que dejéis vuestros comentarios.
