CASO STUXNET”

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.
La central iraní usaba 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

1
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.

2
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

3
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.