Stuxnet: historia del primer arma de la ciberguerra

En 2010 salía a la luz Stuxnet, un malware que había infectado la central nuclear Natanz, en Irán. El grupo de seguridad Langner ha estado durante todo este tiempo investigando qué hacía y cómo burló los sistemas de seguridad, y finalmente han publicado un análisis exhaustivo de lo que ha pasado.

Stuxnet viene con sorpresas. Hoy vamos a repasar ese análisis y tratar de explicar la historia de lo que ya se considera el primer ciber-arma, un precedente de lo que los gobiernos tendrán que enfrentar durante los años venideros.

¿Qué hacía Stuxnet?

Esquema del ataque de Stuxnet: A través de los sistemas informáticos, manipulamos los sistemas de control para aprovechar vulnerabilidades a nivel físico.

Siempre que hemos oído hablar de Stuxnet hemos oído que “infectó una central nuclear”. ¿Qué significa exactamente eso? ¿Qué conseguían los creadores de Stuxnet al infectar la central?

Según la investigacion de Langner, el propósito de Stuxnet era retrasar el programa nuclear iraní. Para entenderlo mejor tenemos que hablar del diseño de la central de Natanz. No profundizaremos demasiado, pero si os interesa el análisis en PDF tiene toda una sección dedicada al funcionamiento de la central.

La central iraní usa centrifugadoras para enriquecer uranio. El diseño es el IR-1, originalmente desarrollado en Europa en los años 60, robado por A.Q. Khan, un traficante de secretos nucleares, que lo entregó a Irán en los 80. Los ingenieros iraníes no lograron dominar la complejidad del sistema por completo y no lo pudieron poner a funcionar pleno rendimiento. Sin embargo, sí consiguieron producir esas centrifugadoras a escala industrial, de tal forma que podían sustituirlas más rápido de lo que se rompían.

Y es que otro de los problemas de esas centrifugadoras que fabricaba Irán es que no eran muy robustas. Se rompían con relativa facilidad, así que idearon un sistema que las aislaban y permitían a los ingenieros reemplazarlas. Sin embargo, para poder hacer eso había que parar las centrifugadoras de la siguiente etapa a la que hubiese fallado.

El diseño de la central de Natanz tenía dos puntos débiles: la resonancia en los rotores y las válvulas de escape

Al parar las centrifugadoras, la presión del sistema subía y los rotores sufrían más daño. Si la presión superaba un límite máximo podría llegar a explotar la instalación. Hubo que diseñar válvulas que liberasen la presión si subía por encima de un límite. Estas válvulas son el primer punto débil del diseño de la central de Natanz.

El otro punto débil eran los rotores de las centrifugadoras. El diseño del IR-1 es supercrítico: para llegar a la velocidad normal de operación (63.000 rpm), los rotores pasaban por varias velocidades críticas o armónicos. A estas velocidades se producía un fenómeno de resonancia que hacía vibrar los rotores. Como podréis imaginar, esto no les sentaba muy bien. Estas velocidades son el segundo punto débil de la central.

Primera versión de Stuxnet: agresiva pero discreta

La primera versión de Stuxnet tenía como objetivo los controladores industriales Siemens S7-417, los encargados de controlar las válvulas y sensores de presión de las centrifugadoras. En aquel entonces, Stuxnet venía en forma de un archivo de configuración para el software de Siemens. Por fuera parecía normal, pero explotaba algunos fallos para poder ejecutar sus acciones.

La infección de esos controladores fue muy poco glamurosa: alguien tuvo que abrir manualmente ese archivo de configuración, ya fuese a través de un USB o llevándolo guardado en uno de los portátiles que se usaban para configurar los sistemas. Stuxnet no tenía por aquel entonces ningún método de autopropagación.

Cuando el archivo malicioso se cargaba, se saltaba el código propio de la ejecución y tomaba el control del sistema, pero de forma muy discreta. Reemplazaba las funciones del sistema que permitían al código legítimo acceder a las lecturas de los sensores, y despúes dejaba que todo se ejecutase normalmente como si no pasara nada.

Sin embargo, cuando se daban una serie de condiciones, Stuxnet entraba en acción. Grababa 21 segundos de lecturas de los sensores y entonces los reproducía en bucle. Más concretamente, sobreescribía las regiones de memoria en las que se almacenaban los datos leídos con los que había grabado. De esta forma, cuando el sistema de control SCADA (en otro ordenador, externo al controlador Siemens) pidiese las lecturas, el controlador devolvería las lecturas reproducidas de Stuxnet y ni los ingenieros ni los sistemas automáticos verían nada anormal.

Una vez que Stuxnet había echado el telón, se ponía a trabajar aislando etapas de las centrifugadoras, de tal forma que la presión del sistema comenzaba a subir. En este momento, las válvulas de escape deberían actuar y dejar salir el exceso de presión. Pero no lo hacían.

Estas válvulas tienen sensores de presión analógicos: para traducir esa señal a una digital que pueda entender un ordenador tienen que calibrarse manualmente. Stuxnet los descalibraba, de tal forma que las válvulas no detectaban presiones anormalmente altas y por lo tanto no se abrían. La presión dentro del sistema empezaba a subir hasta que Stuxnet decidía parar el ataque. ¿Por qué?

Stuxnet aprieta pero no ahoga

Los creadores de Stuxnet podrían haber destrozado totalmente las instalaciones nucleares de Natanz. Sin embargo, no lo hicieron porque había otra forma mejor de conseguir sus propósitos: retrasar el programa nuclear iraní.

Stuxnet sólo dañaba discretamente los sistemas para reducir su vida útil.

Un fallo catastrófico en la central habría llevado a los ingenieros a analizar exhaustivamente qué había pasado, y probablemente habrían detectado y corregido el problema. Esto, junto con la capacidad iraní de producción de centrifugadoras, habría supuesto un retraso no demasiado grande.

Stuxnet simplemente modificaba periódicamente las condiciones de las centrifugadoras, causando mucho más estrés a los rotores y provocando fallos y reemplazos más frecuentes. De esta forma, lograban tener a los ingenieros frustrados buscando qué provocaba una tasa de fallos tan grande en los sistemas (obviamente, no buscaban malware sino fallos en el diseño o construcción) en lugar de avanzar para mejorar el rendimiento de la central.

Versión 2: la NSA toma las riendas

Langner menciona en el análisis que mientras la primera versión de Stuxnet parece hecha por un grupo de expertos industriales y programadores, en la segunda se aprecia la influencia de gente muy relacionada con el mundo de la seguridad. Los sospechosos principales son los ingenieros de la NSA .

La primera diferencia de la versión 2 es el método de propagación. Parece ser que perdieron el acceso directo a los sistemas de la central, así que tuvieron que inventar otro método para infiltrarse.

Usando cuatro vulnerabilidades 0-day (no descubiertas previamente), Stuxnet infectaba unidades USB para transmitirse de un ordenador a otro. Además, usaba una vulnerabilidad en el sistema RPC de Windows para infectar a los ordenadores de una misma red privada (conectados por un mismo router).

Y por si esas cuatro vulnerabilidades fueran pocas, Stuxnet también había sido firmado con certificados digitales robados. De esta forma, Windows lo detectaba como un driver legítimo y confiable y no notificaba al usuario de la infección.

Stuxnet se movía ahora por redes privadas y confiables. Pero sigue habiendo un problema: ¿cómo llevarlo hasta la central de Natanz? Desde luego, pasar todos los sistemas de seguridad no era fácil. Pero había otro punto débil: contratistas externos que trabajaban en la central. Infectando uno de sus ordenadores, menos protegidos, Stuxnet acabaría entrando más tarde o más temprano en los sistemas de Natanz: sólo hace falta que ese contratista conecte su portátil o su USB a un ordenador de la central. Entonces sería cuestión de tiempo que Stuxnet llegase a su objetivo, los controladores Siemens S7-315.

Stuxnet hacía pasar a los rotores por varias velocidades críticas una vez cada mes para aumentar el estrés que sufrían

Estos controladores se encargaban de los rotores, el segundo punto débil que habíamos comentado antes. Más o menos una vez al mes, Stuxnet tomaba el control del sistema que se encargaba de gestionar la velocidad de los rotores. Reducía la velocidad hasta casi pararlos (120 rpm) y después los llevaba de nuevo a la velocidad normal. Como comentamos antes, para llegar ahí los rotores pasan por varias velocidades críticas que los hacen vibrar y por lo tanto los dañan reduciendo su vida útil.

En este caso, Stuxnet no necesitaba falsificar las lecturas de velocidad de los rotores. Como normalmente los rotores operan a un número constante de revoluciones por minuto, no hacía falta reproducir lecturas anteriores. El malware simplemente se encargaba de que no se ejecutase el código que actualiza en memoria las lecturas de velocidad.

Como el software de control SCADA obtenía los valores de las lecturas de la memoria y no comunicándose con los sensores del rotor, siempre obtendría la misma lectura, la de la última vez que se actualizó. Por lo tanto todo parecería normal a ojos de cualquier sistema de monitorización, automático o humano.

¿Sigilo? ¿Para qué?

Tráfico sospechoso de Stuxnet

La segunda versión de Stuxnet no era precisamente sigilosa. Como alguno ya se habrá imaginado, llevar varios cientos de rotores de 63.000 rpm a 120 rpm no es algo que pase desapercibido si estamos atentos al ruido que hacen. Sin embargo, los ingenieros iraníes llevaban auriculares protectores siempre y no oían los cambios de velocidad.

Además, Stuxnet se comunicaba a través de la red para sincronizar los ataques en varios controladores al mismo tiempo, lo que generaba un tráfico sospechoso y fácilmente detectable si se estuviese monitorizando.

La NSA no podía desactivar Stuxnet ni evitar su expansión a otros ordenadores fuera de Natanz

El análisis de Langner también ha revelado que Stuxnet no tenía ningún tipo de “interruptor” que permitiese a sus controladores desactivarlo. De hecho, en agosto de 2010, el ISP nacional iraní bloqueó las direcciones IP de los servidores de control de Stuxnet, de tal forma que el malware pasó a ejecutarse autónomamente desde entonces.

Tal y como estaba diseñado Stuxnet, se transmitía entre redes privadas sin ningún tipo de discriminación. Precisamente a través de esos contratistas externos con los que entró a Natanz, también logró salir y expandirse cada vez un poco más, con pequeños saltos que lo hicieron llegar finalmente a las compañías de seguridad informática que lo sacaron a la luz.

Todo esto nos hace pensar que los creadores no estaban ya tan preocupados por no ser detectados, sino que estaban viendo hasta dónde podían llegar con esta creación. Estaban experimentando con lo que ya sabían que sería el primer paso de la ciberguerra.

El pionero de la ciberguerra

Stuxnet se puede considerar el primer ciberarma. Es el pionero en este mundo, y señala varios puntos e ideas en los que centrarán sus sucesores en el futuro.

Lo primero es la muestra de lo vulnerables que pueden llegar a ser los sistemas industriales. Los fallos de los que se aprovechó para introducirse en los controladores Siemens son fallos de diseño de software, no simples bugs, y por lo tanto es más difícil que se corrijan con un parche aplicado rápidamente. El fabricante de ese software de control se mostró muy reacio a reconocer y corregir esos fallos, lo que nos da una idea de hasta qué punto pueden llegar a ser vulnerables los sistemas de control industriales.

Por otra parte, también tenemos el problema de la seguridad y el control de acceso a esos sistemas. La segunda versión usó varias vulnerabilidades 0-day en Windows, pero la primera se introdujo manualmente y sin tanta virguería informática. Hay muchos puntos de acceso a esos sistemas vulnerables y es muy difícil controlarlos todos.

Y todo esto ha ocurrido en una central nuclear. Imaginad qué puede ocurrir en otro tipo de infraestructuras civiles menos protegidas. Este tipo de infraestructuras también son mucho más vulnerables por la estandarización: es mucho más fácil conseguir los diseños y encontrar fallos de los sistemas en ellas que en centrales nucleares ultrasecretas.

¿Y los recursos necesarios para preparar Stuxnet? En este caso específico sólo un Estado ha podido crear el malware, ya que según Langner se habría necesitado hasta una copia real de la planta de enriquecimiento para probar los efectos de las modificaciones ejecutadas por Stuxnet. Pero si un atacante no quiere ser tan sigiloso como fueron los creadores de Stuxnet y no quiere atacar una planta de enriquecimiento secreta, no necesitará tantos recursos. La capacidad de crear ciberarmas similares a Stuxnet no es exclusiva de las agencias de seguridad estatales.

Como decíamos, Stuxnet es todo un pionero y el que ha marcado los pasos a seguir para las futuras ciberarmas. Veremos cómo reaccionan los Estados y los fabricantes de sistemas de control industriales frente a esta nueva amenaza.

Más información | Ralph Langner

The post Stuxnet: historia del primer arma de la ciberguerra appeared first on i-RME.es.

from i-RME.es http://i-rme.es/2013/stuxnet-historia-del-primer-arma-de-la-ciberguerra/

Este articulo pertenece a sus respectivos autores y se distribuye bajo licencia Creative Commons Reconocimiento 3.0. Algunos articulos pertenecen a BlogdeBlogs quien es el responsable de definir la licencia aplicable.