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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvyjAczJho1iZAbD-UaJOHsmhisdjT6UIrMVmUk4aqRZWLK2M7u2DRnHkhPZAS037inp9UuvzVoyNB41n3vd1IWs1e-MwZ7cG3q8O_DhYNEBVSeOgEdgIGdAuPYiNecflHagCK/s640/s0.jpg) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJA-w0dcgqaOE1IVermnlVStjeQ7URAxbMEqbkMoTthALWw_EOczpxqj9BaZur7B5uc4bHz7aYcdnyxUNoV8-zOVC_PRwHOtKRzHNhR4XzVx6eWNgudBuonMeM03u9D2Kw14Es/s1600/s1.png) |
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).
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivtX8cE3UzPmF1DepmXF1-Q9QnK2J6jd_Qaq2T0sPr4s99-OV7TTd_T-wmig3nFqv0R740CpTFjFWPkyt4YdFOUVycKckQNoL7lKhyphenhyphenJsYjwnuLOprcLh5Jag4XiTGzo_lJQuid/s1600/s2.png) |
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:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrVTRn2ddjn2tT2LV9Sh44Qe9bJzGKUdfkRpRpoBrealamhS7IXCuqpblBwxISTUqk3dfo2pstW1J3KvhSWm0t7z35yR-O0tcX21zZtl03WHlCkpJPPkBZi55pCJoJ5qsqyBqv/s1600/s4.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_lqk_J8_iaeqzzFZ2vPZA9_2qMGDJWxfzMsaCigE-gsPHarzCgzVBAbTov38n5caX6BgVe2VrdWjjGq2od_v0HAkZVaWDKqYRauvsX2G3ng3GzTWSH3etxNBYfiVOYq_2k2ch/s640/s5.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgHJ2m3zTvYx9Cwmcv9poCXYPmTibwhIFrV531AU3Upw_ckT-LwLeCNFF0MVDrLfenEhlsX5NYHHyCztP_It5OK5_KpLrrGGzjAPK-sgRjJE2k2Np05Tv9SULN6ZP6vUrmBrZVK/s1600/s6.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhwsROyOrzcXrnJ3HOq0HsIRfJtiYXPc9YKdQ2FfmzL42-KLRwJOS_sgAbXmSchxk1ZQ31eSuKwyW6cXe0jKgZwgDsNCFT_fHm8TTlxVr6PbK1xrbXKC-DVOL8pfWrLn0Y15hR/s1600/s7.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMfRB8RCSRRWIre9IAzGcdAmQQWUf0_n8gvYhGu2Kaz13cZSm4Eh0GmjT05Yz_5SoFkLFVKH942Ly6AdoQD4uITszOxiK-AI4lxRYDDOrUA2JTrKRRkJzaJinAF1cW_1zaUf_t/s640/s8.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZtrY3BCnRrE1xCt9ROCZRpV2Ktex42LSVpxoH-bm7M0oR7q9v2CS4BXzj4ghvmdMjsvBthuf6HLunImi1e1MMZEhyphenhyphenZotmmdjhMPeIinYEs4fwNIT6knERAxoEHSx_YL7FZNZH/s1600/s9.png) |
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í.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhuDJ9LDcop3KTi4v6Av6ft8-HEFa-Tnko81UBwbSq7t7d-BTPWHuKU7GAa532tu9SlyAGVhf1P1KV8z_L-5HZ_hdm2jEQnZutkWYf_N7qn-FKPCNPZ1hoH4drnEumJ_snXObsl/s640/s10.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhA4Wl4HfTlcLLs8arRPfyHFV8m_HPbEr4pQOjSR1AM9aIEmX-L_kc4sO21gBYAiVF-qjsIeeLYEWEereqOZpnlNEH9-oWa94vVJbU3VlAQ7ITQD3GG7K7O65qwcc0W5lIMhzSD/s640/s11.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgXvGgX2MAaFGn0CmhT6i3ETIXfM7rAYU2MMvl7oEZAKeKSdqXDvnepdqsu-V68xNePR54uOH7Q-YgSlukoQyDkFE9e1FuR7kA4rNE7GcsdAWfi1GerLfDywBdxEK3wITl1-yPr/s640/s12.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOstLdoWFHjAkVa8bQbjpRqdaqlAqoJ46AxBt9cZjVshwOACBuOezuXkVOWmHzbrttqejgBczqYuIFfS_VBW1aH-h7dxStgGfFVoKMf780_9bwYwRDDwCQKufrmhhF58qTbi3n/s640/s13.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhteqBEll9eO3VjzFG66ZxAr2V2Rm1jBmCBw4CZMv-6U_4W9m4Vr3RIUjexPmH-fnG4oYlegTyi8mprYuWva3APUQ67meeN5Pa13CLpuBdsI9PFNGSsMz5JcNsHr1swarS8AmfP/s1600/s15.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWx3pSfNH2Aa6ta-SWUg8IUCVnauBG3tUkZlzV4R6arndG5ALJ7Y1hYLlWt2RJcSllmm90fvfiTbsCj06TMdywfnHreCgwKcBjucLP3TN82oPAiL6giYdXw32RWACom87fkQwN/s640/s16.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmeqYd26S5kp3RmuTzTUu3RMUuTik7imNxKmF6ng51w32pQ6rgQ2bwFd73RQJYgrUGVHvOr2aC29dB653MtmrTRCRhJMxvtJ4s_RUmGHMzQlwcKC_HLW9zaSKcfeDHtFYQyf_g/s640/s17.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiehB6HcdLbmFieUSXbZwiz7jrZyXc3b6jyVdWO5mR52-a7SCI3H7guEj4cv8derhU7NNewRhjp-kJAEjiziK7R8X7YlNg78FSfoN0NsC_2SkVtQEl9Y-NfKyVQQ4nbZTN4BUw/s640/s18.png) |
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQoB_TCFtEpxkmWVNq0Sh-QlL7nl9O1C5KXih8gHQo6TDlbLiIsRVEoQMwD7NLkhZKqwYKkCkGzWGcipynaWZPIqCZ0wY81eyaS2m4qHrY4SHkw1k8ZwZHiIJsBCXKvU97XsWI/s400/s19.png) |
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.
No hay comentarios:
Publicar un comentario