SCADA: Halcones heridos en tus Infraestructuras Críticas #SCADA #HoneyWell #OSINT

En el presente artículo os voy a contar una parte de mi entretenimiento e inquietudes durante mis ratos libres en  estos últimos meses. Todo empezó con el descubrimiento de herramientas como Zmap y Masscan las cuales ofrecen resultados de escaneo de grandes rangos de direcciones IP en muy poco tiempo. En ese momento me surgió la duda de cuánto de verdad tenían y si los resultados eran fiables o parecidos entre sí, o incluso, porque no, comparados con Nmap y Shodan. Por lo que para validar si realmente que eran datos fiables sin estar repetidos, y sin volverme muy loco, decidí a probarlo sobre un direccionamiento estático eligiendo un proveedor de Internet nacional al azar.

Figura 1: SCADA. Halcones heridos en tus infraestructuras críticas

Mediante la herramienta de Maltego obtuve los bloques de direcciones IP por su código ASN y por si acaso, lo contrasté con el servicio ipinfo.io. Estos son los valores que obtuve para comenzar la investigación.

Figura 2: Rangos de direcciones IP obtenidos con Maltego

Una vez obtenidas las redes tenía que averiguar cuáles eran dinámicas o estáticas. Para ello creé un sencillo script en Bash - no tengo conocimientos de programación en un lenguaje como Python, de ahí la sencillez - al cual le indicaba en un fichero TXT las direcciones IP para realizar la resolución inversa y descartar así los rangos /24 de aquellas que fueran dinámicas (alguno fue /25).

Figura 3: Script en Bash para seleccionar las direcciones IP

Ahora ya tocaba decidir qué puertos escanear, por lo que decidí recopilar toda la información posible acerca de los sistemas SCADA recurriendo al blog de SCADA Stragne Love. Una vez obtenida información sobre dispositivos y puertos útiles a escanear, descarté los puertos UDP y también algunos puertos TCP que me iban a generar demasiados falsos positivos como por ejemplo el 23 y el 80.

Antes, el descubrimiento de dispositivos SCADA en grandes rangos de direcciones IP era lento pero gracias a las herramientas de hoy en día esto está al alcance de cualquiera. El objetivo, como os podéis imaginar, consistía en descubrir dispositivos SCADA en esos rangos de direcciones IP identificándolos por los puertos especiales que ellos utilizan. Algo que cualquiera puede hacer fácilmente con los recursos que he descrito hasta el momento. Y tras lanzar los escaneos los resultados de Zmap, Masscan, Nmap y ShodanCLI han sido los siguientes:

Figura 4: Resultados obtenidos para el descubrimiento de dispositivos SCADA basándonos en sus puertos

Cuando hablo de "Totales" me refiero a los encontrados por cada herramienta de los cuales los "Únicos" son los que sólo esa herramienta ha encontrado y sumando todos hacen el "TOTAL" de 97 resultados positivos, ahora quedaría analizarlos y descartar falsos positivos. Es decir, algunos dispositivos han sido encontrados por más de una herramienta, y algunos han sido encontrados de forma única por una sola herramienta.

Analizando los resultados

- Shodan: Sorprende el número de resultados ya que esperaba un número más amplio. El tiempo de ejecución ya sabemos que es inmediato y con ShodanCLI además tenemos la opción de descargar un JSON con todos los datos.  Hay que comentar que con búsquedas de más de 1000 resultados hay que indicar el parámetro "--limit=XXXXX", es decir, simplemente tiene que ser un número mayor de los resultados para la descarga total ya que si no se hace eso tan sólo descarga 1000.

Figura 5: ShodanCli

Es recomendable antes de hacer una descarga de los datos, ver con Count los resultados de la búsqueda cli.shodan.io. Una vez descargados los visualizamos en pantalla con parse indicando los datos que queremos ver teniendo como referencia las especificaciones para los desarrolladores de Shodan.

- Zmap: a mi parecer queda bastante mal parado pese a ser el que usan en Censys para escanear todo Internet, aunque también es cierto que por una parte entiendo el uso de Zmap por parte de Censys ya que es increíblemente rápido. La ejecución de Zmap fue de alrededor de 1 hora.

- Masscan y Nmap: Hay que decir que comparten algunos parámetros a la hora de lanzarlos pero que Nmap se puede hacer eterno - unas 60 horas aproximadamente - frente a Masscan que tan sólo necesita unas horas 3 a 6 aproximadamente para obtener unos resultados bastantes buenos.

La conclusión que se obtiene es que no es una buena idea limitarse a una sola herramienta ya que como podéis ver hay información que quedaría sin ser analizada solo por no haber probado todas. Al final, lo único que te requerirá es un poco de más tiempo, pero como se ve en le gráfico de la Figura 4, todas las herramientas han aportado, al menos, un resultado único.

Descubriendo dispositivos vulnerables HoneyWell FALCON

Con la lista de dispositivos SCADA descubiertos en los escaneos y siguiendo la idea de Conquistar el mundo con OSINT & Well-Known bugs, apareció información sobre un uno en concreto de la casa Honeywell que usa el puerto 47808. Buscando datos de él en Google me llamó la atención que hubiera un panel indexado, pero como había descartado el puerto 80  en mis escaneos no me había percatado de que esto pudiera pasar. La casa HoneyWell suele tener estos paneles para administrar sus dispositivos, como ya vimos hace años con los sistemas de aire acondicionado de HoneyWell, así que decidí hacer un poco de hacking con buscadores al uso con un dork concreto que se me ocurrió y di con este modelo concreto.

Figura 6: Paneles web de administración del dispositivo indexados en Google

Busqué a ver si en Internet había información de alguna vulnerabilidad relacionada con este dispositivo y fue sencillo localizar la existencia de dos, por lo que me pensé en buscar información detallada de las mismas. En este momento sentí la responsabilidad de no poder dejar esto así. Había encontrado algo que podría estar mal y quería avisar a los responsables si era así, porque me parecía demasiado sencillo si alguien malo buscaba esto.

Una de las vulnerabilidades hacía referencia a usuarios y contraseñas por defecto en este dispositivo - exactamente igual que en el caso de los sistemas de aire acondicionado de HoneyWell que mencioné antes - y probé a ver si estaban así en estos dispositivos concretos o los responsables habían tenido la precaución de cambiarlas. Que estuvieran indexados en Google era ya un mal síntoma, porque eso significaba que no estaban tomando todas las precauciones posibles.

Figura 7: En la propia página de login ofrecen todos los usuarios

Aquí es cuándo vino mi sorpresa al ver lo excesivamente fácil que era explotar este fallo de fábrica, ya que el panel web trae por defecto dos usuarios creados SystemAdmin y Guest y aunque la contraseña de SystemAdmin había sido cambiada, la password de Guest seguía por defecto.

Figura 8: Se puede entrar como Guest al home del sistema

Podemos navegar por las diferentes secciones para hacernos una idea de lo que hay. También al haber iniciado sesión correctamente como el usuario Guest se podría acceder a la parte de administración y cambiar la contraseña para este usuario.

Figura 9: Cambio de contraseña en el panel de administración

Esto entra dentro de lo normal, pero al analizar la construcción de la web podemos descubrir algo mucho peor. Al entrar en la parte de gestión de la contraseña se genera una dirección URL con el ID de usuario correspondiente en un parámetro por GET y tras revisar el código HTML de la página vemos que la password de ese usuario está en MD5 en un campo. ¿En serio? Sí.

Figura 10: Hash de la contraseña del usuario Guest en el código HTML

Según parece, los dispositivos vulnerables de este modelo tienen una vulnerabilidad que fue descubierta en el año 2014 por la que generan un ID correlativo e idéntico en todos los dispositivos. En los sistemas actualizados esto ya no es así, pero en los vulnerables basta con mover uno adelante o uno atrás y llegar al valor del hash de la cuenta de SystemAdmin que es el primero que se crea y ya tenemos el hash de su password.

Figura 11: Hash de la contraseña del usuario SystemAdmin en el código HTML

De esta misma manera si hay mas usuarios sólo hay que aumentar el ID para obtener el hash MD5, aunque como ya he comentado antes en algunos casos son ID diferentes. Pero mi sorpresa viene al revisar la vulnerabilidad  que indica que incluso puedes llegar a esta url sin estar autenticado. Sin comentarios.

Figura 12: Vulnerabilidad en dispositivo permite llegar a la URL sin estar autenticado

Por lo que directamente se puede acceder a otro sistema igual simplemente cambiando la  dirección IP en la URL sin necesidad de que existan o no las contraseñas por defecto en los usuarios. Lo mejor es que, una vez obtenido ese Hash MD5 se puede hacer uso de la contraseña con un ataque de Pass the Hash como se explica en este artículo, pero como es un valor MD5 sin Salt ni nada, es casi más fácil crackearlo. Podemos hacerlo simplemente mediante una búsqueda en Google.

Figura 13: Hash MD5 crackeado e indexado en Google

O en cualquier web que nos permita introducir un listado de todos los hashes de todos los usuarios, o con el clásico John The Ripper en tu equipo para no leakear ninguna información del estudio en la red, o por ejemplo con Hashcat + diccionario propio y aplicando reglas. Vamos, es un MD5, no es tan complicado.

Figura 14: Crackeando "in house" el MD5

Como he dicho antes, no sería necesario ni obtener la contraseña porque el sistema es vulnerable a ataque de Pass the Hash, pero una vez obtenidas las claves de todos los usuarios el sistema quedaría expuesto a cualquier atacante que quisiera entrar como SystemAdmin.

Figura 15: Acceso como SystemAdmin

Como se ha visto, el ataque es muy fácil. Ese es el verdaderos problema, que ha sido demasiado fácil y tal vez sea un poco exagerado. Llegado a este punto, decidí avisar a todos los afectados por este bug que yo había localizado para que lo arreglaran de alguna forma. Pedí a Chema Alonso que llamara a los que conocía - lo cual agradecieron como en la historia del carnicero - y al resto los avisé vía CNPIC, que tiene un contacto en la web para esto.

Figura 16: Control de elementos del sistema

Con un fallo en la seguridad tan fácil de explotar, pienso que se podrían provocar daños reales (económicos o físicos) alterando los valores de funcionamiento ya que los dispositivos donde están instalados pueden ser polideportivos, residencias, fábricas que podrían sufrir una pérdida total o parcial de producción, laboratorios, etcétera.

Figura 17: Control de central térmica

A parte de tener passwords por defecto, de no usar un segundo factor de autenticación en el login, etcétera, lo mejor de todo, es que ninguno de los paneles de administración web usaban HTTPs ni por asomo, así que cualquier dispositivo en la red o atacante haciendo un man in the middle en IPv4&IPv6 podría acceder a las contraseñas con facilidad.

Figura18: Posibilidad de apagar el sistema

Los fallos no son nuevos, y nos agradecieron el reporte para poder solucionarlo, pero es significativo que un fallo tan grave esté más de dos años sin ser descubierto en una implantación funcionando. Creo que los sistemas de pentesting persistente deberían ser obligatorios para todas las industrias y más si son Infraestructuras Críticas de nuestro país, como era el caso de alguno de los sitios.

Autor: Ander Cablallero