The blackout (II)

Al hilo de lo que comentamos en el anterior artículo The blackout, ¿puede que todo lo que sucedió en Turquía el 31 de Marzo no se debería estrictamente a causas técnicas y fallos humanos?

Atacar un sistema eléctrico nacional para provocar un cero de tensión no es trivial, a pesar de que en el imaginario colectivo del siglo XXI tales sistemas son la infraestructura crítica por excelencia y aparentemente constituyen el primer objetivo de cualquier terrorista. Podemos pensar en dos aproximaciones. La primera, que está en la línea del artículo del Observer, consiste en desconectar una a una las infraestructuras que abastecen a todos los clientes: o abrimos interruptores en todas las líneas de transporte, o disparamos todos los grupos de las centrales de generación, o las desconectamos de la red abriendo los interruptores en las líneas de evacuación, o abrimos todos los interruptores de cabecera de las líneas de distribución.

Esto supone un grado de infiltración del sistema eléctrico de un país absolutamente total, requiriendo, además, tener capacidad de control y mando para coordinar todas las actuaciones simultáneamente (en realidad no hace falta llegar al 100% de infiltración, ya que eventualmente se inducirá un desequilibrio tal en el sistema que el efecto dominó facilitará el trabajo).

[Read more…]

The blackout (I)

El pasado 31 de marzo una de las peores pesadillas de nuestra civilización tecnológica se hizo realidad en Turquía (no, no hablamos de Sálvame): gran parte del país quedó sin suministro eléctrico durante horas, lo que provocó la inevitable cascada de caídas en otros servicios esenciales: transportes, comunicaciones, abastecimiento de agua potable, etc. Casi inmediatamente, especialmente en ciertos ambientes, se abrió paso la idea de que el incidente se debió a un ciberataque. Esta idea se vio reforzada, inevitablemente, por el secuestro y asesinato de un fiscal por un grupo terrorista. Han pasado ya casi dos meses y, como suele ocurrir, apenas se ha vuelto a hablar de este asunto (lo que para ciertas mentes propensas a la conspiranoia es, sin duda, la mejor confirmación posible de esta hipótesis).

A los pocos días la primera explicación oficial atribuía el suceso a una gestión deficiente de ciertas operaciones de mantenimiento en la red que dejaron el sistema eléctrico turco expuesto a un riesgo grave, riesgo que a la postre acabó materializándose. Según esta explicación se habría tratado de un fallo exclusivamente técnico que acabó costando el puesto a Kemal Yildir, máximo responsable de la compañía estatal TEIAS. TEIAS es la empresa que gestiona el transporte de energía eléctrica en Turquía. He estado buscando algún informe oficial al respecto con el fin de cotejar los datos técnicos que sustentan esta hipótesis, sin resultado. Pero sí he encontrado dos artículos relativamente recientes que sostienen dos visiones absolutamente contrapuestas resumidas en titulares:

[Read more…]

Denegación de servicio a un PLC Omron con comandos legítimos en FINS

Hace poco leí un artículo en el blog de Shodan titulado “Why control systems are on the Internet” escrito por John Matherly (fundador de Shodan), en el que comentaba un párrafo de la documentación oficial de Omron donde se explica porqué la conexión a internet de los PLCs de esta marca es completamente segura.

Su robusta teoría se basa (o se basaba, desconozco si han cambiado su punto de vista) en que sus PLCs no tenían un sistema operativo basado en Windows ni se comunicaban a través de un puerto conocido con un protocolo estándar de Ethernet, lo que los haría invisibles a los malvados ojos de los atacantes.

Según esta curiosa pero extendida manera de concebir la seguridad, sería extremadamente extraño que, por ejemplo, alguien se descargara la especificación oficial del protocolo FINS (protocolo industrial de Omron) de la página web oficial e intentara comunicarse con un PLC.

Para ponernos en contexto, la manera legítima de configurar y trabajar con los componentes industriales de la marca Omron es con el software de esta marca CX-One, que comprende distinto software como el CX-Programmer, diseñado para la configuración y programación de los PLCs.

Aunque estos PLCs pueden disponer de diferentes módulos de comunicación como Ethernet, están diseñados con la idea de que bajo cualquier problema que surja, siempre sea posible una conexión en serie de manera física.

[Read more…]

Un arma muy poderosa de ciberataque: conocimiento IT + conocimiento industrial

Cada vez son más frecuentes los ciberataques producidos por equipos multidisciplinares en los cuales sus integrantes disponen de conocimientos IT y conocimientos del funcionamiento del sistema industrial al cual pretenden atentar. Esto se ha convertido en un arma muy poderosa, ya que los atacantes no solo son capaces de acceder al sistema de control industrial, sino que pueden identificar qué parte del proceso industrial es crítica y delicada y que saboteando su sistema de control, pueden producir graves daños que afecten tanto a la producción de la planta como a la propia instalación.

Todos recordamos el caso del malware Stuxnet que en 2010 atacó una instalación industrial dañando más de 3000 centrifugadoras en Irán. Recientemente, según un informe de la oficina federal alemana para la seguridad de la información, una planta de acero sufrió un ciberataque a sus sistemas de control industrial ocasionando graves daños. Según un informe anual publicado por la oficina federal alemana para la seguridad de la información, conocida como BSI (Bundesamt für Sicherheit in der Informationstechnik), existe evidencia de un ataque cibernético dirigido a los sistemas de control en una acería alemana que resultaron en daños “masivos” a un alto horno.

El informe BSI describe las destrezas técnicas de los atacantes como “muy avanzadas“. Tenían “know-how avanzado no sólo de la seguridad IT convencional, sino también el conocimiento técnico detallado de los sistemas de control industrial y procesos de producción de la planta“. Diferentes sistemas internos y componentes industriales fueron comprometidos. El informe describe el ataque a la acería, pero no identifica a la empresa afectada ni revela cuando se produjo el ataque.

La planta fue atacada combinando un ataque “spear phishing” y la ingeniería social para acceder a la red de oficinas de la institución. A partir de ahí, el ataque continuó su camino a través de la red de producción causando un gran daño en un alto horno.

[Read more…]

YOU ARE BEING WATCHED

“You are being watched. The government has a secret system: a machine that spies on you every hour of every day.”

Un mundo donde estamos vigilados por un juez supremo que controla cada uno de nuestros movimientos. Podemos ser localizados en todo momento. Se puede predecir de manera estadística el futuro. Prevenir crímenes o actos terroristas es factible. Todo está controlado por una suerte de Gran Hermano, sólo que éste no es de carne y hueso. Es una máquina. Una máquina que recoge toda la información de internet, telefonía, imágenes de vigilancia, etc., la procesa y es capaz de entenderla y tomar decisiones.

Hablamos de la historia que nos cuenta “Person of Interest” (“Vigilados” en su versión para España), una serie en emisión desde septiembre de 2011 producida por el conocido J.J. Abrams. Aunque el argumento principal es ficticio e introduce elementos que se podrían calificar de ornamentales para darle ritmo y hacerla más atractiva, la serie juega con componentes del mundo real que hacen verosímil la historia.

[Read more…]

Los sistemas de control aislados o el móvil perpetuo de primera especie

Existen ideas que se resisten a desaparecer. Y entre ellas hay un tipo especial, las que se basan en la confusión entre los propios deseos y la realidad. En ocasiones estas ideas se convierten en entes que sobreviven a su propia refutación. Durante siglos el ser humano ha ambicionado construir una máquina que sea capaz de funcionar continuamente, produciendo trabajo y sin aportes energéticos del exterior. Tanto la ha buscado que tiene hasta nombre: el móvil perpetuo de primera especie.

Durante siglos mentes por lo demás lúcidas han luchado contra la implacable realidad construyendo modelos que, una y otra vez, han fallado en el momento de ponerlos a prueba. Pero claro, sería tan maravilloso que semejante máquina pudiese existir… Tal vez con esta o aquella mejora pudiese funcionar. Hay que pulir esto y esto, refinar aquello. Todo en aras de la promesa de la liberación energética. Pero no. Es imposible una máquina tal en nuestro universo porque su mera existencia violaría una ley esencial del mismo: el primer principio de la termodinámica. Ante esta evidencia la Academia Nacional de las Ciencias de Paris decidió en 1775 que no aceptaría más proyectos de móviles perpetuos. Tal era el grado de consolidación de la termodinámica entonces que se adoptó como criterio infalible, ahorrando la necesidad de poner a prueba una y otra vez los dispositivos surgidos de la mente de gente con más buena intención que conocimientos físicos.

El caso es que hoy en día nos encontramos ante un caso similar. Cuando se trata de auditar la ciberseguridad de un sistema de control industrial, no importa el propietario, la tecnología o su propósito, en un gran número de casos acabamos topando con un ente al que podríamos denominar ‘el móvil perpetuo de los sistemas de control’ pero que se conoce habitualmente como ‘el sistema de control industrial aislado’. Y es que, efectivamente, si mi sistema de control estuviese efectivamente aislado y funcionase produciendo trabajo sin intercambiar información con el exterior, no tendría que preocuparme por su ciberseguridad, ¿no es cierto? Estaría asegurada de forma intrínseca.

Una y otra vez los ‘móviles perpetuos de los sistemas de control’ no resisten una investigación en profundidad. En el caso de los sistemas físicos basta definir un volumen de control en torno a nuestro móvil perpetuo y verificar si existe intercambio de energía con el exterior a través de esa frontera. En el caso de los sistemas industriales el concepto es el mismo, pero lo que buscamos son intercambios de información, de un tipo u otro. Siempre los hay: permanentes o temporales, síncronos o asíncronos, cableados o no, tontos (pendrives) o inteligentes (portátiles de mantenimiento). Y es que, ¿para qué sirve un sistema con el que no me puedo comunicar y que no puedo modificar de forma alguna?

La refutación caso por caso supone un importante gasto de energía desde el principio mismo del proyecto. Sería bastante útil que se adoptase un criterio equivalente al de la Academia de las Ciencias de Paris. De esta forma podríamos rechazar a priori cualquier reivindicación de aislamiento y podríamos ponernos a trabajar desde el principio.

Aunque, por otra parte, si configurase mi sistema de esa manera quizá entonces… sí, quizá…

Nota: la ilustración reproduce el ‘recipiente de flujo continuo’ de Robert Boyle. A nuestros ojos modernos puede producir hasta risa, que sin duda se tornará en sonrojo al pensar la opinión que tendrán los humanos del futuro al rememorar como en el siglo XXI se podía intentar defender el concepto de ‘sistema de información digital aislado’ (IMHO).

Algunas conclusiones del #CyberCamp (II)

Como todos a estas alturas ya sabemos, del 5 al 7 del pasado diciembre, el Instituto Nacional de Ciberseguridad (INCIBE) organizó la primera edición de Cybercamp, un congreso de ciberseguridad orientado a todo tipo de público: desde expertos en seguridad informática hasta familias con niños pequeños. Junto con algunos compañeros de S2 Grupo, tuve la oportunidad de participar y tratar de compartir con personas con perfiles muy dispares nuestra visión e inquietudes sobre ciberseguridad industrial.

[Read more…]

Algunas conclusiones del #CyberCamp: S2 Cibercity

Como muchos de vosotros sabréis, hace unas semanas se celebró la primera edición de CyberCamp, el evento de ciberseguridad organizado por el Instituto Nacional de Ciberseguridad (INCIBE). Este evento se diferencia de los existentes congresos dedicados a la ciberseguridad en que pone en el punto de mira tanto a los expertos en seguridad como a las familias, gastando gran parte de esfuerzos en concienciar al “ciudadano de a pie” sobre las ventajas y peligros de Internet.

Como no iba a ser menos nosotros estuvimos allí, y con nosotros, nuestra preciada maqueta: S2 CiberCity.

En un mundo como el nuestro lleno de terminales con fondos negros y letras blancas (o verdes para los más retros), no es de extrañar que desde el primer momento causara gran curiosidad en los asistentes, y aunque eran pocos los que se atrevían a preguntar, eran muchos los que se acercaban lenta y sigilosamente intentando descubrir cuál era la función de semejante artefacto.

Como toma de contacto, decidimos adoptar el papel inverso y preguntar nosotros a un curioso técnico de sonido que curioseaba:

—¿Sabes lo que es?

Como informático, la primera respuesta me dejó de piedra:

—Estáis generando electricidad por ósmosis del agua destilada.

Tras un largo silencio y después de preguntarle “por lo bajini” a mi compañero Armand (Ingeniero Industrial) si tal respuesta tenía algún tipo de sentido, le explicamos por primera vez qué era aquella maqueta y por qué la teníamos allí:

—Esta maqueta representa procesos de control industrial críticos para el buen funcionamiento de nuestra ciudad, como es el sistema de suministro de agua o el sistema de generación y transporte de energía eléctrica. Aunque como podéis ver la parte de los arbolitos es una maqueta, toda la instrumentación y el sistema de control industrial es un sistema real como el que podemos encontrar en instalaciones reales. Esto nos permite utilizar esta maqueta como campo de pruebas de ataque y diseño de estrategias de defensa sobre sistemas de control industrial, así como poder visualizar las consecuencias.

Teníamos preparada una pequeña presentación al estilo clásico, con sus Powerpoints y su ronda de preguntas, donde combinábamos mis conocimientos como informático y los conocimientos de mi compañero sobre procesos de control industrial para atacar nuestra ciudad, pero debido al goteo constante de grupos de personas interesados en saber más sobre la maqueta y a la gran diversidad entre ellos, acabamos optando por hacer explicaciones más directas y personalizadas a cada grupo que se acercaba.

El perfil de estos grupos los podemos dividir según la profundidad de la primera pregunta que hacían:

¿Esto qué es?
Esto es un SCADA, ¿no?
¿Qué protocolos tenéis implementados?
¿Aquí regaláis bolis? (Es lo que tienen los eventos gratuitos y en fin de semana)

Después de una explicación adaptada a cada perfil (cuando era posible) y de demostrar cómo éramos capaces de atacar el sistema de bombeo de agua o de provocar un mal funcionamiento en la red de transporte de energía, venían las preguntas, que nos ayudaron a evaluar el nivel de interés y de concienciación en la materia de ciberseguridad industrial, sacando las siguientes conclusiones:

  • Los menores y las familias, ajenas al mundo de la seguridad, van tomando conciencia de que muchos procesos necesarios para el buen funcionamiento de una ciudad o infraestructura son vulnerables a ciberataques, y que hay gente que se dedica a ver como se puede atacar para saber defenderlos.
  • Respecto a los estudiantes de Ingeniería industrial y profesionales de los sistemas industriales, os remitiré a las conclusiones mi compañero Armand (cuya entrada publicaremos en unos días), que fue quien más intimó con los de su especie (con todo el cariño).
  • Profesionales y aprendices de la ciberseguridad: debido a las nuevas oportunidades laborales que ofrece el crecimiento de la ciberseguridad industrial, se ha incrementado el interés en este sector, y aunque la mayoría eran conscientes de la escasez de seguridad de estos sistemas pocos lo habían visto aplicado a un sistema real.

Como demostramos, ataques muy sencillos que hoy en día no son funcionales en los sistemas en nuestros ámbitos informáticos, sí lo son en estos sistemas, pero muchos no somos conscientes de que las soluciones típicas a los problemas de seguridad aplicadas al ámbito de las TIC no son directamente aplicables en el ámbito industrial.

En conclusión, tanto los profesionales de la seguridad como los profesionales de los SCI, tenemos que aprender los unos de los otros. Es imposible aplicar soluciones estos sistemas sin conocer en profundidad la manera de trabajar de quien los utiliza, cuáles son sus necesidades o sus limitaciones.

Lo de los “buscabolis”, un tema mucho más complejo y profundo, lo dejaré para otra entrada.

Descubriendo vulnerabilidades tradicionales en sistemas ICS

Recordarán que en un post anterior, titulado La odisea de (intentar) hacer las cosas bien…, les daba los detalles del tortuoso camino que he tenido que atravesar desde el descubrimiento de una vulnerabilidad hasta su publicación. Dado que la vulnerabilidad ya es pública (véase Advisory (ICSA-14-203-01), Omron NS Series HMI Vulnerabilities), es el momento de hablarles de ella. Aunque lo cierto es que la publicación de esta entrada, tras unos 10 meses de espera, estaba ya previamente planificada.

Las vulnerabilidades que les comento fueron encontradas en el NS15 versión 3.19 (aunque desconozco si otras versiones están afectadas), un HMI de la marca OMRON.

La primera de ellas es un XSS persistente que permitiría inyectar código malicioso a través del formulario de configuración, concretamente en el parámetro “Page Title”, que se encarga de modificar el título de las páginas web del sistema. No obstante, para aprovecharse de ella, el atacante deberá estar autenticado en el sistema. Sin embargo…

Cuando el sistema almacena todas las opciones y sus valores, se puede comprobar como los valores introducidos en el formulario de configuración se transmiten mediante método “GET”, apareciendo todos los parámetros en la barra de navegación. Como no existe ningún parámetro que haga de token, un atacante podría aprovechar esta vulnerabilidad de tipo CSRF y crear una URL que permitiese cambiar la configuración del sistema HMI.

Aunque en un primer lugar ambas vulnerabilidades pueden parecer más bien simples e incluso irrelevantes, de explotarse en un sistema crítico los resultados podrían ser devastadores.

Imaginemos que un atacante decide realizar un ataque dirigido contra el operario que se encarga de controlar el sistema HMI. Para ello, el atacante le enviará un enlace que, aprovechándose del CSRF, inyecte un payload que aproveche la vulnerabilidad XSS. En este caso, la finalidad del payload será la de suplantar la página web de control por otra.

De este modo el atacante podría conseguir que el operario modificase el estado del sistema a partir de una información falsa (escogida por el atacante para sus propios propósitos). En otro escenario, si el atacante consiguiese atacar con éxito el sistema, el ataque resultaría invisible para el operador, a cuyos ojos todo estaría en perfecto estado. Algo, que si no recuerdo mal, también realizaba Stuxnet en su día.

La odisea de (intentar) hacer las cosas bien…

Hace unos días, Antonio Sanz comentaba en su post “He descubierto una vulnerabilidad: ¿Y ahora qué?” las distintas opciones que existen cuando se encuentra una vulnerabilidad de seguridad.

En este post, pretendo contar mi experiencia acerca de un responsible-disclosure que llevo coordinando desde octubre de 2013. Para situar al lector en contexto, decir que en dicho mes encontré un par de fallos de seguridad en un dispositivo HMI (Human-Machine-Interface) perteneciente a un sistema de control industrial. Explotando las dos vulnerabilidades de manera simultánea, la situación se puede volver algo “peliaguda” para el operador del sistema, lo que no es ningún tipo de consuelo si tenemos en cuenta la finalidad de los sistemas que son vulnerables.

Nada más encontrar la vulnerabilidad, realicé una pequeña búsqueda de buzones de contacto de la empresa, para ponerme a hablar directamente con ellos y agilizar el trámite. A día de hoy, todavía espero respuesta.

La segunda opción fue contactar con el ICS-CERT, la organización encargada de lidiar con este tipo de problemas en cuanto a sistemas industriales se refiere. Amablemente, al día siguiente nos comunicaron que se iban a poner en contacto con el fabricante para poder solucionar el problema.

Sin embargo, no es oro todo lo que reluce, y tras varios intentos infructuosos de contactar con el fabricante, ICS-CERT decidió gestionar el incidente con otro CERT, ya que sería más fácil para este último ponerse en contacto con la empresa en cuestión. Tras verificar qué versiones del dispositivo son vulnerables, miramos el reloj y nos damos cuenta de que ya estamos en Navidades, con lo que entre vacaciones y fiestas, retomamos las conversaciones un 8 de enero de 2014, cuando nos dicen que van a preguntar al otro CERT para ver el estado de la vulnerabilidad.

La siguiente noticia que tenemos es un 13 de febrero, cuando nos confirman que el fabricante ha verificado la existencia de la vulnerabilidad y nos comunican que van a investigar si ésta afecta a más equipos, mientras trabajan para solucionarla; contactamos con otro CERT, gubernamental, para ver si a ellos les hacen más caso, pero parece que no… Nosotros, por nuestra parte seguimos insistiendo para conocer el estado del incidente, hasta que un 29 de abril nos confirman que el estado sigue siendo el mismo que en febrero.

Más tarde, en mayo nos informan de que el fabricante ha hecho públicas las vulnerabilidades, y que ICS-CERT va a crear un advisory (toma ya, nosotros callados y estos van y…). Ya en junio, el mismo ICS-CERT nos comunica que las vulnerabilidades sólo afectan a los productos vendidos internacionalmente (si yo fuera desconfiado, sospecharía…), y que el fabricante no notificará a sus clientes nacionales, pero sí a los extranjeros; la fecha estimada para ello es mitad de junio o principios de julio (por suerte para ellos, en el correo no dicen si será este julio, o el de dentro de diez años, cuando el producto ya esté obsoleto, y por tanto, nadie lo tenga).

En resumen, llevamos desde octubre de 2013 y hemos llegado a julio de 2014 y la vulnerabilidad es conocida desde hace nueve meses por parte del fabricante. Sin embargo, el cliente final, quien es realmente vulnerable, no lo sabe. Por estos motivos, hemos decidido hacer pública la vulnerabilidad en los próximos días. Seguid conectados. Para animar la espera, podéis comentar vuestras experiencias al reportar vulnerabilidades en los comentarios de esta entrada.

PD Nada que reprochar ni al ICS-CERT ni a ningún otro de los CERT que han intentado, junto a nosotros, hacer las cosas bien… creemos que el principal, y único, problema, lo ha aportado el fabricante…