Hackers descongelan tu supermercado: lecciones de seguridad OT

Imagina que eres el encargado del turno de noche de un supermercado en Lyon. A las 3 de la mañana, el equipo nocturno ve que la escarcha se derrite de los expositores de congelados. Luego empiezan a saltar las alarmas de los compresores, no en un pasillo sino en toda la tienda. Cuando alguien entiende qué pasa, las cámaras frigoríficas han recibido por control remoto la orden de entrar en descongelación, y miles de euros en productos congelados se van calentando sin ruido hacia el umbral legal de descarte. Más o menos esto fue lo que pasó este año cuando atacaron los controladores de refrigeración de cadenas de supermercados franceses, y es un buen toque de atención para cualquiera que piense que la seguridad de la tecnología operacional es problema de otro.

El ataque no fue una cadena de exploits de película. Según los informes, los atacantes activaron ciclos automáticos de descongelación en controladores de refrigeración expuestos a internet, equipos comerciales de un gran fabricante industrial, y el daño se extendió a tiendas de varios países. Por esas mismas fechas, otro incidente obligó a un grupo de supermercados belga-neerlandés a desconectar parte de sus sistemas de TI, lo que afectó a la distribución y a las entregas. Casualidad o coordinación, el resultado fue el mismo: el mundo físico fue hackeado a través del digital.

¿Y por qué una nevera está en internet?

La reacción más habitual ante esta historia, y que inundó los comentarios por todas partes, fue algo como «¿pero por qué demonios conectarías una nevera a internet?». Suena retórico, pero tiene una respuesta real, y fingir lo contrario es la razón por la que volvemos a tener esta conversación cada pocos años.

La refrigeración comercial no es una nevera. Un supermercado mediano opera un sistema térmico distribuido: decenas de expositores, cámaras frigoríficas y congeladores, racks de compresores y condensadores, todo coordinado por controladores que equilibran la temperatura con el coste energético. El argumento de negocio para la conectividad remota es genuino:

• Diagnóstico remoto. Un contratista de refrigeración que atiende cientos de tiendas puede detectar la firma de un compresor en fallo días antes de que se averíe. Mandar a un técnico a pulsar un botón físico para un descongelado rutinario cuesta dinero; un comando remoto no cuesta nada.
• Optimización energética. Los supermercados están entre los edificios que más energía consumen por metro cuadrado. Las cadenas ajustan las temperaturas de los expositores y los calendarios de descongelación en toda su red, y algunas participan en programas de respuesta a la demanda en los que la compañía eléctrica les paga por reducir carga en momentos de estrés de la red.
• Registro para cumplimiento. La normativa de seguridad alimentaria exige registros continuos de temperatura. Los controladores en red generan un registro de auditoría automático: sin portapapeles y sin registros en papel falsificados.
• Comparación de flota. Cuando gestionas 2.000 tiendas, detectar que los compresores de una de ellas consumen un 15% más que los de sus homólogas es la forma de encontrar fugas de refrigerante antes de que se conviertan en reparaciones de cinco cifras.

Así que la conectividad no es una estupidez. Lo que es una estupidez es la implementación. Los primeros informes sugieren que muchos de esos controladores eran accesibles directamente desde internet: algunos con sus propios módems celulares y tarjetas SIM, en direcciones IP públicas y sin VPN, sin pasarela y sin lista de permitidos. Y la historia de la autenticación, según una cuenta muy compartida, era un usuario admin con una contraseña derivada de la fecha actual. Eso no es una superficie de ataque; es una puerta abierta con alfombra de bienvenida.

Así es realmente un ataque OT

Los ingenieros de software tendemos a imaginar los ciberataques como robo de datos: bases de datos exfiltradas, credenciales filtradas, notas de ransomware. Los ataques OT son distintos en esencia, no solo en grado. El objetivo no es la información, sino un proceso físico. La carga no es un cifrado; es un comando con apariencia legítima enviado a un dispositivo que confía en quien aparezca.

Fíjate en lo elegante que es el ataque de descongelación. Los atacantes no necesitaron escribir malware, escalar privilegios ni siquiera entender del todo el protocolo. Un ciclo de descongelación es una función normal y autorizada del controlador: existe porque la escarcha se acumula en las bobinas del evaporador y hay que derretirla periódicamente. El atacante simplemente la invocó fuera de horario, a gran escala. Ningún interbloqueo de seguridad se activó, porque desde la perspectiva del controlador no se pidió nada anormal. Es el equivalente OT del problema del «diputado confundido»: el dispositivo ejecuta fielmente comandos que nunca debió recibir.

Ese patrón se generaliza de forma deprimente. Se han «atacado» plantas de tratamiento de agua porque alguien movió el control deslizante de dosificación química. Sistemas de gestión de edificios han sido tomados a través del acceso remoto de su proveedor de climatización. En casi todos los casos, la capacidad peligrosa no es un bug sino una funcionalidad, accesible para personas que nunca debían alcanzarla. Por eso la solución no es una mejor revisión de código, sino arquitectura.

Las vulnerabilidades OT más peligrosas no son bugs de corrupción de memoria. Son funciones legítimas expuestas a llamadores ilegítimos.

El parche que nadie aplicó

Este es el detalle que debería hacer estremecer a cualquier ingeniero de seguridad: la vulnerabilidad subyacente en esos controladores se había hecho pública meses antes, mediante un proceso coordinado con el fabricante. Los investigadores publicaron un análisis detallado. Existían parches para al menos algunos modelos. Y el ataque ocurrió igualmente.

Este es el sucio secreto de los parches industriales. En la TI empresarial estamos malacostumbrados: sale un CVE crítico y en unos días tus herramientas de gestión de flota han avisado, preparado y desplegado la corrección. En OT no funciona así. El controlador de un expositor de congelados puede funcionar quince años. Es propiedad de la tienda, lo mantiene un contratista externo de refrigeración, lo fabrica un proveedor y lo configuró un instalador que dejó la empresa hace seis años. ¿Quién, exactamente, es responsable de aplicar una actualización de firmware en 2.400 locales de nueve países? En la práctica: nadie.

Peor aún, el fabricante aparentemente publicó la corrección sin marcarla claramente como crítica para la seguridad. Para un contratista de mantenimiento con una lista de equipos realmente averiados, «actualización de firmware disponible» suena a trabajo opcional. Es tanto un fallo de comunicación como técnico. Si publicas un parche para una vulnerabilidad que permite a extraños descongelar la comida de un país, las notas de la versión deberían decirlo con palabras que un responsable de instalaciones no pueda pasar por alto. La brecha entre especificación e implementación no solo crea bugs: crea flotas enteras de dispositivos sin parchear cuyos operadores ni saben que son vulnerables.

Valores seguros por defecto: diseñar para el peor día

Hablemos de cómo es lo correcto, porque los principios no son exóticos. Son las mismas ideas de diseño defensivo que aplicamos en software crítico para la seguridad, solo que rara vez se exigen en el mundo OT. Ya he escrito antes sobre ingeniería defensiva que resiste las catástrofes, y los controladores de refrigeración son un caso de libro para ello.

Limita la frecuencia de los cambios de estado peligrosos

Un ciclo de descongelación es físicamente seguro si se ejecuta de vez en cuando y destructivo si se ejecuta sin parar. Así que haz que la física se imponga en el firmware: tras completarse una descongelación, rechaza otra durante un intervalo mínimo, independientemente de lo que diga cualquier comando remoto. El atacante que puede enviar una petición de descongelación puede enviar mil; el dispositivo no debería aceptar más de lo que permite la física. Esto cuesta unas pocas líneas de código y un temporizador, y limita el radio de daño de cualquier compromiso del plano de control.

Los interbloqueos locales pesan más que la autoridad remota

Si la temperatura de la cámara ya supera un umbral, o los sensores de producto marcan calor, un comando remoto de descongelación debería rechazarse y registrarse con claridad. El controlador tiene los datos de sensores para saber que un comando es absurdo. Haz que los use. Un comando que empujaría el sistema hacia un estado conocido como malo no es un comando; es un error.

Comandos firmados, no contraseñas

Las contraseñas en dispositivos embebidos son una causa perdida: serán las de fábrica, compartidas, escritas en un post-it o derivadas de la fecha. El modelo más sólido es asimétrico: los controladores verifican una firma en cada comando remoto contra una clave pública del proveedor o del operador, grabada en el aprovisionamiento. Así, robar una contraseña no sirve de nada; necesitas la clave de firma, que vive en un HSM en el centro de operaciones, no en 2.400 expositores. Sí, esto implica infraestructura de gestión, rotación y revocación de claves. Sí, merece la pena. Resolvimos este problema para las actualizaciones de software hace una década; los canales de comandos merecen el mismo trato.

Asume que la red es hostil

Si un dispositivo sale de fábrica con un módem celular y una credencial por defecto, acabará en un buscador de dispositivos expuestos en cuestión de semanas desde su despliegue. La única solución duradera es diseñar asumiendo que eso está garantizado: conexiones entrantes rechazadas por defecto, telemetría solo saliente hacia un broker y el plano de gestión accesible únicamente a través de un túnel con autenticación mutua. «No lo expongas a internet» es un consejo; «haz que la exposición sea sobrevivible» es ingeniería.

La segmentación no es opcional: hazla bien

Todos los marcos de seguridad OT (IEC 62443, las guías del NIST, el clásico modelo de Purdue) dicen lo mismo: mantén los sistemas de control fuera de redes planas. Y aun así, el módem celular del expositor es el antipatrón hecho realidad. Se salta por completo el cortafuegos corporativo, creando miles de puntos de entrada individualmente direccionables y sin monitorizar, que quizá el equipo de seguridad ni sabe que existen.

La arquitectura que realmente funciona se parece a esto:

1. Los controladores viven en una VLAN OT dedicada sin ruta a internet ni a la TI corporativa. Solo una pasarela puede comunicarse con ellos.
2. La pasarela aplica listas de protocolos permitidos: el controlador habla Modbus o el protocolo del proveedor con la pasarela y nada más. Las anomalías aquí son alertas de alta señal, porque el tráfico legítimo es aburrido y predecible.
3. El acceso remoto pasa por un jump host con MFA, grabación de sesiones y credenciales con caducidad. El contratista de refrigeración obtiene una ventana de cuatro horas a una tienda concreta, no una VPN permanente a toda la red.
4. Telemetría solo saliente. Si la nube del proveedor necesita datos de temperatura, la pasarela los envía. Nada tira de datos desde dentro.
5. Inventaría todo. No puedes segmentar lo que desconoces. Ese módem celular del expositor es exactamente el tipo de conectividad paralela que los inventarios no detectan, hasta que Shodan la encuentra por ti.

Nada de esto es hipotético ni caro en comparación con la alternativa. La parte difícil es organizativa, no técnica: exige que el equipo de instalaciones, el de seguridad de TI y los proveedores se pongan de acuerdo sobre quién es responsable de qué. En la mayoría de organizaciones de retail, OT cae en la grieta entre esos equipos: demasiado físico para TI, demasiado conectado para instalaciones. Esa ambigüedad es la verdadera vulnerabilidad, y es la misma que convierte las lagunas de autenticación en la nube en brechas invisibles, como vimos en los puntos ciegos del registro de autenticación en la nube: si nadie es dueño de la telemetría, nadie ve el ataque.

Lo que los ingenieros de software deberían sacar de todo esto

Quizá nunca toques un controlador de refrigeración, pero los modos de fallo aquí son los de cualquier sistema conectado, y cada vez son más tu problema. La línea entre TI y OT se sigue difuminando: tus robots de almacén, el HVAC de tu oficina, tus instrumentos de laboratorio y tu edificio inteligente ejecutan Linux embebido y hablan con la nube. Algunas máquinas de laboratorio de hospitales ya se niegan a ejecutar pruebas si su cuenta de suscripción no tiene saldo, lo que significa que una caída de facturación o una brecha conectada a internet puede paralizar diagnósticos médicos. Construimos ese mundo, una función de comodidad cada vez.

Así que las lecciones se transfieren directamente. Inventaría tu exposición: si no sabes qué está escuchando, alguien más lo encontrará. Trata las operaciones peligrosas como privilegiadas aunque sean «funciones normales», porque el atacante que llegue a tu plano de control usará tus funciones contra ti. Firma lo que importa y haz caducar todo lo demás. Diseña el estado de fallo como estado seguro: un controlador que pierde conectividad debería seguir enfriando, no dar por buenos todos los comandos en cola. Y cuando publiques una corrección de seguridad, dilo alto y claro: un parche que nadie aplica es indistinguible de no tener parche.

El ataque al descongelado de supermercados se recordará sobre todo por lo absurdo: hackers contra guisantes congelados. Pero el siguiente no apuntará a los helados. Apuntará a la misma clase de controladores expuestos, sin parchear y con autenticación débil, en un almacén farmacéutico de frío, en la planta de refrigeración de un centro de datos o en un sistema municipal de agua. El hardware es el mismo. Las credenciales son igual de malas. La única variable es qué se calienta, se inunda o se apaga cuando alguien escribe la contraseña del día.