?

Log in

No account? Create an account

July 3rd, 2018

No hay mucho escrito sobre la mejor forma de atacar un sistema de mando y control, lo que sería aplicable a entornos militares, o civiles, como infraestructuras críticas, sistemas de control industrial, o incluso, barcos o aeronaves.

Ahora que el CCN ha publicado un informe sobre ciberamenazas en el sector salud, en el que se destaca la enorme vulnerabilidad que supone la obsolescencia en estos sistemas críticos (principalmente por el uso masivo de sistemas operativos obsoletos y sin soporte del fabricante, como Windows XP), creo que puede ser interesante hablar sobre los ataques al decisor, o el síndrome de la UVI conectada.

Imaginemos una UVI en la que todos los sistemas de monitorización médica disponen de interfaz de red, y se encuentran conectados a un sistema de mando y control, donde el personal de guardia vigila a los pacientes.

Para hacer más realista el entorno, dicho sistema está conectado también a la red de propósito general del hospital, para acceder a otros servicios básicos del hospital, como la farmacia, historiales clínicos, administración, etc. En este entorno tan exigente, hay protocolos médicos, con unos tiempos de reacción muy definidos, y que en muchos casos, son públicos, lo que podría facilitar las cosas a un posible atacante.

Supongamos que el tiempo que transcurre entre que salta una alarma de azúcar alto en un paciente, hasta que el médico de guardia le inyecta una dosis masiva de insulina, son 20 segundos. Ese es el tiempo preciso que ha de estar activo el malware en el sistema.

Hablamos de un malware sin archivo y sin persistencia, ya que los sistemas de la UVI, como es lógico, están permanentemente conectados a la red eléctrica y a la red de monitorización, por lo que también se puede autoeliminar del sistema sin dejar rastro.

Supongamos también, que ese malware genera una alarma de azúcar alto en un paciente y que a los 20 segundos exactos, modifica el histórico de lecturas de azúcar a valores normales y finalmente, se autoelimina de la memoria del sistema.

En ese tiempo de 20 segundos, el médico de guardia habrá activado el protocolo de emergencia, e inyectado una dosis adecuada de insulina al paciente, lo que le habrá provocado un grave coma diabético.

Una vez abierta la investigación, para los responsables de la misma, parecerá claro que el médico se ha equivocado, o que ha intentado matar al paciente, minando gravemente su prestigio y credibilidad.

Los ataques de decepción, orientados a atacar al decisor, son muy peligrosos ya que provocan un daño, encubren el origen y pueden repetirse varias veces, hasta que haya datos suficientes como para considerar que está ocurriendo una anomalía estadísticamente poco probable.

Está claro que es mucho mejor atacar a un sistema de mando y control aéreo engañando sobre la posición real de los aviones, que bloqueando completamente el sistema, ya que en primer caso, se puede usar el ataque varias veces sin que el decisor sea consciente de que está ocurriendo algo raro y que está tomando decisiones equivocadas.

Alguien puede pensar que ese escenario de la UVI conectada es improbable, pero se tiene la certeza de que se ha utilizado en la central nuclear de Natanz (Irán) y se tiene la sospecha de que puede haber sido utilizado en otra ocasión, provocando varios choques de buques de guerra estadounidenses en el Pacífico, algo que estadísticamente era improbable.

Tal como narra la periodista Yolanda Quintana, en el capítulo 4 de su excelente libro titulado "Ciberguerra", hubo un Stuxnet 0.5, que poca gente conoce. Dicho malware tenía como misión retrasar el programa nuclear iraní, y socabar el prestigio de los científicos responsables del mismo, lo que lo retasaría todavía más. Desde mi punto de vista, algo más sutil, refinado y efectivo que, lo que hizo la versión 1.0 de Stuxnet destruyendo físicamente las centrifugadoras, algo muy evidente y que hizo sospechar rápidamente que algo raro estaba pasando en la planta.

Stuxnet 0.5, fue subido de forma anónima a la plataforma de análisis de malware VirusTotal en 2007, pasando desapercibido por todo el mundo. La versión 0.5 de Stuxnet, que como la versión 1.0, iba dirigido a los sistemas SCADA de Siemens que controlaban la instalación nuclear iraní, variaba la presión del gas de hexafluoruro de uranio en las centrifugadoras, para reducir drásticamente la producción de uranio enriquecido de la central. En julio de 2009, el Presidente de Irán aceptó la dimisión de Gholam Reza Aghazadeh, que era el jefe del programa nuclear de Irán, al parecer, por el fracaso de su gestión.

Es decir, Stuxnet 0.5, además de lograr un retraso de dos años en el programa nuclear de Irán y sin que nadie se diera cuenta de que estaba pasando algo raro en la planta, también logró minar, de forma drástica y definitiva, la credibilidad del decisor, lo que lo retrasó todavía más el programa nuclear iraní, mientras se buscaba un sustituto.

Este malware tan sofisticado y sutil, estaba diseñado para desactivarse automáticamente el 4 de julio de 2009, fecha muy cercana a la dimisión de Gholam Reza. Es decir, que nos encontramos en un caso que bien lo podemos asimilar al síndrome de la UVI conectada del que hemos hablado al principio.

Este tipo de ataques también son muy peligrosos en el entorno aeronáutico, cuando los pilotos (decisores), están acostumbrados a la enorme fiabilidad del vuelo automático.

Si un malware logra engañar al piloto, por ejemplo, desconectando el piloto automático sin que él lo sepa, o desconectando inadvertidamente el sistema automático de control de potencia de los motores, hay muchas probabilidades de que el piloto no se cuestione ese hecho, y el vuelo acabe en desastre. Hay un caso documentado de este tipo de comportamiento de los pilotos, que aunque no fue provocado por malware, ilustra muy bien lo que puede pasar cuando el decisor es "engañado" y tiene una fe absoluta en la fiabilidad del sistema.

Se trata del vuelo 214 de Asiana Airlines, que se estrelló el 6 de julio de 2013 en la aproximación al aeropuerto internacional de San Francisco. La investigación de la NTSB demostró que el piloto había usado una secuencia de comandos inusual, que tuvo como consecuencia la desconexión del sistema que controla automáticamente la potencia de los motores. Dicho sistema mantiene una determinada velocidad del avión, a un determinado ángulo de ataque, haciendo que el piloto pueda volar por posiciones de morro y se pueda olvidar del mando de gases.

El piloto de Asiana, que había realizado la mayoría de sus horas de vuelo en modo automático, tenía fe absoluta en el sistema, y no fue consciente de que el avión no iba a corregir la potencia de los motores, hasta que fue demasiado tarde, y tocó el suelo de forma catastrófica antes de llegar a la pista.

Ese mismo efecto ocurría si un determinado malware desconecta el sistema de control automatico de potencia y además, como hizo Stuxnet 0.5, falsea la información visual del estado de los sistemas, para que el piloto no sea consciente de que se ha desconectado dicho sistema.

Para complicar las cosas, el malware podría forzar que dicha información no se refleje en las cajas negras, para que en la investigación parezca que el accidente ha sido un fallo del piloto.

Es evidente que tendrían que ocurrir varios accidentes similares, en un determinado tiempo, para que alguien sospechase que algo raro estaba pasando y se pusiera a investigar.

Por ello, es muy importante que los sistemas críticos estén debidamente actualizados, con todo el hardware y software con soporte de los fabricantes , que dispongan de los mecanismos de seguridad adecuados, y que sus usuarios sigan escrupulosamente los procedimientos operativos de seguridad, de forma que se minimice la posibilidad de ser afectados por una amenaza desconocida, especialmente dirigida a nuestro sistema y que no pueda ser detectada o neutralizada por los sistemas automáticos de seguridad.

También hay que tener en cuenta que un ataque al decisor que esté bien diseñado, es casi tan complicado de detectar para un equipo de ciberseguridad, como los sucesos aleatorios de corta duración. Por ejemplo, exfiltraciones de datos mediante peticiones DNS falsas. Por lo que es necesario arbitrar mecanismos de detección eficaces, que pongan en evidencia este tipo de anomalías en sistemas críticos.

Mi recomendación es mantener unas estadísticas precisas de la normalidad y e investigar a fondo, cualquier cosa que se desvíe de dicha situación de normalidad. Los valores simulados de normalidad, no se van a corresponder con valores reales de esa misma normalidad, lo que nos puede hacer sospechar.

En otra ocasión hablaré de la ley de Benford, o la Ley del primer dígito, que se puede extender a tercero, al cuarto, etc y que nos puede ayudar a encontrar este tipo de anomalías altamente escurridizas en nuestros sistemas de mando y control.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Latest Month

July 2018
S M T W T F S
1234567
891011121314
15161718192021
22232425262728
293031    
Powered by LiveJournal.com
Designed by Tiffany Chow