Seis zero-days dan root sin login en los Danfoss AK-SM 800A al día

«In less than an hour with casual manual inspection» (en menos de una hora de inspección manual por encima). Con esa frase presenta Midnight Blue el informe que publicó el 11 de noviembre de 2026 sobre el Danfoss AK-SM 800A, el controlador que gobierna las cámaras de frío de los supermercados atacados en Europa desde octubre: seis desbordamientos de pila que dan ejecución remota de código como root, sin credenciales, en cualquier firmware hasta la 5.3.2, la actualización de octubre. Danfoss colgó la versión 5.4.0 el 12 de noviembre sin aviso de seguridad, el BSI alemán puso el caso en naranja el día 13 y nadie ha confirmado todavía que el firmware nuevo cierre ninguno de los seis fallos.

• Hecho: Midnight Blue publicó el 11 de noviembre de 2026 seis desbordamientos de pila explotables sin autenticación en el Danfoss AK-SM 800A, con ejecución de código como root, y la CCB belga y el BSI alemán los confirmaron en avisos del 12 y el 13.
• Afectados: todos los AK-SM 800A hasta la versión 5.3.2 incluida, también los que ya aplicaron los parches de 2025 y tienen activado el modo Strict, si responden desde internet.
• Estado del parche: sin CVE y sin corrección confirmada. Danfoss publicó la 5.4.0 el 12 de noviembre sin aviso de seguridad, Midnight Blue sostiene que no cierra los fallos y el BSI no lo descarta.
• Acción urgente: inventariar los controladores expuestos, incluidos los módems 4G del instalador, sacarlos de internet hoy y hacer copia de la base de datos antes de instalar la 5.4.0, que no permite volver atrás.

Esta noticia continúa el hilo que abrimos con la segunda oleada de deshielos del 2 de noviembre y seguimos con la hoja de medidas de CISA del día 5. La novedad está en el diagnóstico: hasta esta semana, parchear a R4.3.1 y activar el modo Strict era la receta oficial para el AK-SM 800A, y Midnight Blue sostiene que esa receta deja el equipo igual de abierto.

Una hora con el firmware 5.3.2 y seis desbordamientos de pila que no piden sesión

El investigador de Midnight Blue Carlo Meijer descargó la imagen de firmware de la web de Danfoss, que contiene binarios ARM comprimidos con 7-zip. El controlador ejecuta Danux, una distribución Linux propia basada en Yocto, sobre un procesador i.MX6, y casi toda la lógica vive en un único binario monolítico, sm_app, que arranca 52 tareas internas (Modbus, Ethernet, entradas y salidas, servidor web). En lugar de emular el sistema entero, Meijer montó el sistema de ficheros, metió qemu-armel-static en un chroot y usó una biblioteca cargada con LD_PRELOAD para secuestrar el flujo al llegar a main() y arrancar solo la tarea web. Con eso, un POST vacío a xml.cgi devolvía ya una respuesta XML firmada como Danfoss SM800A.

Lo primero que buscó fueron llamadas a strcpy, la función de copia sin límite de tamaño que lleva décadas desaconsejada. La lista del desensamblador que publica el informe tiene 839 referencias, y cientos de ellas están en manejadores accesibles desde la red sin autenticar. En el primer manejador CGI que abrió, un POST con 768 letras A bastó para tumbar el proceso con un fallo de segmentación. El informe lo resume así: hay «at least 5 different vulnerabilities of this kind» (al menos cinco vulnerabilidades distintas de este tipo) en el poco código que llegó a mirar.

Pasar de un crash a ejecutar código no le llevó mucho más. El único obstáculo es que strcpy se detiene en el primer byte nulo, lo que obliga a montar direcciones que lo contienen, y Midnight Blue no explica cómo lo resolvió mientras dure la divulgación coordinada. La captura de la demo muestra el resultado contra un equipo con la versión 3.3.0: el script detecta la versión remota, escribe una cadena ROP, pivota la pila y abre una shell inversa en la que id devuelve uid=0 y /proc/cpuinfo identifica un Freescale i.MX6 Quad/DualLite con 121 días de uptime. La aplicación explotada corre como root, apunta el informe, «because of course it does» (porque, claro, cómo iba a ser de otra forma). Los fallos, insiste Midnight Blue, siguen presentes en la 5.3.2.

Sin canarios, sin PIE y sin secure boot, por qué el modo Strict de Danfoss tampoco cierra la puerta

Midnight Blue publica la salida de checksec sobre el binario sm_app de un firmware 4.2.4, y el resultado explica por qué un desbordamiento de pila en 2026 sigue siendo tan explotable como en 2006:

Arch:     arm-32-little
RELRO:    Partial RELRO
Stack:    No canary found
NX:       NX enabled
PIE:      No PIE (0x10000)

Ni canarios de pila ni ejecutable independiente de posición, dos defensas que son opción por defecto del compilador desde Ubuntu 17.10 y que no exigen reescribir una línea. El informe lo contrasta con el certificado IEC 62443-4-1 que TÜV SÜD concede a Danfoss A/S para su proceso de desarrollo seguro de producto, el mismo que el fabricante exhibe en su web para la unidad de Climate Solutions y controladores electrónicos.

El segundo hallazgo afecta a la mitigación que todas las autoridades recomendaban. Desde la versión 4.0, Danfoss aplica por defecto el nivel de seguridad Strict de su control de sesiones, que fuerza HTTPS y obliga a que las peticiones XML de terceros lleven un token de sesión en la cabecera AKSM-auth en lugar de usuario y contraseña. Lo implementa un binario aparte, sm_fcgi_app, que actúa como WAF: solo deja pasar a NGINX el comando getauth hasta que considera que el usuario está autenticado. CERT-FR incluyó activar Strict entre sus mitigaciones oficiales y la alerta CERTFR-2026-ALE-012 sigue en la versión del 16 de octubre. Midnight Blue encontró en ese mismo filtro otro strcpy sin comprobar: una cabecera User-Agent de 1.536 bytes contra el puerto 3443 del firmware más reciente, con Strict activado, produce el mismo fallo de segmentación. Tampoco sm_fcgi_app tiene canarios ni PIE.

El tercer punto es el que el BSI recoge con más alarma. Midnight Blue comprobó en los registros de fusibles OTP del i.MX6 que el controlador no usa el arranque seguro del procesador. Sin secure boot, quien consigue ejecutar código puede dejar un implante que sobreviva a un restablecimiento de fábrica y a una actualización, como hicieron SALTWATER y SEASPY en las pasarelas de correo de Barracuda o FIRESTARTER en los firewalls ASA de Cisco, o puede borrar la flash y empujar un firmware malformado que convierta el equipo en un ladrillo. En un supermercado eso se traduce en días sin control de frío hasta que llega el recambio.

La 5.4.0 del 12 de noviembre, el naranja del BSI y el aviso de la CCB

El Centre for Cybersecurity Belgium fue el primero en mover ficha. Su aviso del 12 de noviembre, titulado Warning: Six New Danfoss Vulnerabilities, recoge producto, versiones y tipo de fallo tal como los describe Midnight Blue y añade que la agencia belga ha recibido múltiples incidentes en sistemas de refrigeración del país. Sobre los parches dice que no había ninguno disponible en el momento de publicar y que retirar la exposición directa a internet «must not be delayed while awaiting patches» (no debe retrasarse mientras se esperan los parches).

El BSI alemán publicó el 13 de noviembre el aviso BITS-H 2026-306525-10e2, versión 1.0, con criticidad 3 sobre 4 (naranja, medidas inmediatas) y marcado TLP:CLEAR. Su cuadro resumen deja la casilla de versiones corregidas con un guion y la de CVE sin números. En la valoración afirma que «Über eine bereits aktive Ausnutzung der gefundenen Schwachstellen ist nichts bekannt» (no se sabe nada de una explotación activa de las vulnerabilidades encontradas), pero avisa de que el informe puede contener pistas suficientes para un atacante y de que, sin secure boot, el peor escenario es un firmware malicioso que deje los equipos inservibles y obligue a recuperarlos a mano o a sustituirlos, con una parada que duraría bastante más si cayeran muchos a la vez. Las medidas son las de siempre: comprobar si los equipos responden desde internet, desconectarlos o meterlos detrás de una VPN, revisar el nivel de parche y, ante cualquier sospecha, cambiar todas las credenciales y comprobar que los equipos conectados al controlador funcionan con normalidad.

Entre uno y otro aviso, Danfoss publicó el 12 de noviembre la versión 5.4.0 en su página de descargas del AK-SM 800A, junto a un nuevo paquete Danux 4.14.017.194. La ficha avisa de que antes de descargar hay que pasar por una página readme y aceptarla, porque «This step ensures awareness of cybersecurity enhancements introduced in earlier releases» (este paso garantiza que se conocen las mejoras de ciberseguridad introducidas en versiones anteriores). No hay aviso DSA que acompañe al paquete, y a las 18:06 UTC del 13 de noviembre la página de avisos de seguridad de Danfoss devolvía un error de su WAF en lugar de la lista.

Lo que piensa Midnight Blue del paquete lo publicó el medio Bytes Europe el 13 de noviembre: según su crónica del aviso belga, la firma neerlandesa sostiene que la 5.4.0 no corrige los fallos que ha notificado y que, por la marca de tiempo del fichero, el firmware se compiló hacia el 29 de octubre, antes de la segunda oleada de ataques y antes de sus propios informes. El BSI, por su parte, dijo a heise el mismo día 13 que no puede descartar que la 5.4.0 también sea vulnerable. Y Danfoss advierte desde la rama 5.x de que la actualización es un viaje de ida: en su boletín técnico de junio ya explicaba que, con R5.1.x, «it will no longer be possible to downgrade to an earlier software version» (dejará de ser posible volver a una versión anterior del software) por los cambios en la estructura de la base de datos, y pedía una copia completa antes de empezar. Quien instale hoy la 5.4.0 lo hace sin saber qué cierra y sin poder volver atrás.

687 paneles StoreView en Censys el 10 de noviembre y ninguna cifra nueva para España

Midnight Blue acompaña su informe con cuatro búsquedas en Censys hechas el 10 de noviembre. Devuelven 687 hosts con Danfoss StoreView, 912 con Copeland XWEB, 297 con Dixell XWEB y 364 con Eliwell Televis, un fabricante que nadie ha atacado todavía y que la firma añade como aviso. El propio informe reconoce que una parte apreciable de los Danfoss que quedan a la vista son ya honeypots, lo que encaja con la caída del 76 % que Censys midió entre el 9 de octubre y el 5 de noviembre.

Para España no hay recuento nuevo. Las últimas cifras siguen siendo las que contamos en noviembre: 63 paneles StoreView expuestos el 11 de octubre y 58 el día 14 según Censys, 193 direcciones IP con interfaz Danfoss el 13 de octubre según ONYPHE y 157 supervisores Copeland y Dixell XWEB el 5 de noviembre. A la hora de publicar esta pieza, INCIBE-CERT no ha publicado nada sobre los seis fallos nuevos. Su último aviso sobre el producto es el INCIBE-2025-0253 de mayo de 2025, actualizado el 27 de agosto de ese año, que cubre la contraseña derivada de la fecha y los dos fallos posteriores de Claroty, y su bitácora del 20 de octubre se limita al caso francés. Tampoco hemos encontrado aviso del CCN-CERT.

Conviene no confundir los fallos. Los tres CVE de Claroty Team82 de 2025 (CVE-2025-41450, CVE-2025-41451 y CVE-2025-41452) tienen parche desde R4.2 y R4.3.1, el registro de NVD sigue en estado Deferred y ninguno figura en el catálogo KEV de CISA a 13 de noviembre de 2026. Los seis de Midnight Blue son otros, no tienen número y afectan también a los equipos que ya aplicaron aquellos parches. Un AK-SM 800A en 5.3.2 con Strict activado y contraseñas cambiadas es, a efectos de esta noticia, un equipo vulnerable si responde desde internet. La exposición no la decide solo el rango de IP de la empresa: Midnight Blue insiste en los módems 4G que los instaladores enchufan al controlador, los mismos que vimos en Suecia colgando de Telia y Telenor, y que no aparecen en ningún inventario del departamento de TI. Es el patrón de la industria 4.0 conectada sin red de seguridad que describimos hace años y que ahora tiene factura.

Inventariar los módems 4G, cortar la exposición y hacer copia antes de tocar la 5.4.0

El servidor web del AK-SM 800A se identifica en la cabecera Server como Danfoss SM800A, según la respuesta que Midnight Blue obtuvo del firmware emulado, así que una petición desde fuera de la red de la tienda basta para saber si el tuyo responde a cualquiera:

curl -sk -m 10 -D - -o /dev/null https://IP_PUBLICA/ | grep -i -E "^Server: Danfoss|SM800A|StoreView"

Si devuelve algo, el panel está a la vista y hay que tratarlo como lo que es. Con los avisos de la CCB, el BSI y CERT-FR y las mitigaciones de Midnight Blue sobre la mesa, este es el orden de trabajo para quien opera cámaras de frío en España:

1. Inventaría hoy qué controladores de Danfoss, Copeland, Dixell o Eliwell responden desde internet, y no únicamente en las IP públicas de la empresa: pregunta al frigorista qué módems 4G tiene enchufados a cada equipo y qué operador los sirve, el inventario que ya pedíamos en nuestras recomendaciones de seguridad en IoT.
2. Saca de internet todo lo que aparezca, con 5.3.2 o sin ella. El acceso remoto del instalador vuelve por VPN, por una APN privada o, como mucho, por una lista blanca de IP en el firewall, que CERT-FR y Midnight Blue consideran una medida intermedia y no una solución.
3. Da por comprometido cualquier equipo que haya estado expuesto. CERT-FR recuerda que un restablecimiento de fábrica no basta en un equipo sin parche expuesto a internet, y el BSI pide cambiar todas las credenciales y comprobar que los equipos aguas abajo del controlador funcionan con normalidad.
4. Si decides instalar la 5.4.0, haz antes una copia completa de la base de datos del sistema, porque Danfoss no permite volver a una versión anterior desde la rama 5.x, e instala primero el paquete Danux 4.14.017.194. Mantén el nivel Strict aunque Midnight Blue haya demostrado que no cierra todo, porque sigue cortando la mayor parte de la superficie sin autenticar. Y no des el equipo por protegido por haber actualizado.
5. Vigila la temperatura con un registro independiente del controlador y guarda el tráfico web de la VLAN de frío, como contamos en las medidas de CISA. En España, las empresas notifican a INCIBE-CERT y el sector público al CCN-CERT, y una cadena de alimentación de cierto tamaño está dentro de NIS2.

Un certificado IEC 62443-4-1, 839 llamadas a strcpy y la lectura del blog

A nuestro juicio, el dato que más pesa es el certificado. Danfoss tiene un sello IEC 62443-4-1 de ciclo de desarrollo seguro y, al mismo tiempo, un binario de red actualizado este otoño sin canarios, sin PIE, sin secure boot y con cientos de strcpy en manejadores sin autenticar. El certificado audita el proceso, no el producto, y quien compra o prescribe controladores de frío debería leerlo así. Ya vimos el 5 de noviembre cómo el parche de junio de Zyxel no cerraba el fallo que decía cerrar, y la 5.4.0 de Danfoss llega con menos información todavía: sin aviso ni CVE, y con un readme que no dice qué corrige.

Midnight Blue titula su informe Don't bother patching (no te molestes en parchear) y defiende que dedicar recursos escasos a instalar parches en un código así es malgastarlos: «asset owners need to remove internet exposure as soon as possible» (los propietarios de los activos tienen que eliminar la exposición a internet lo antes posible). El BSI, en cambio, pide instalar las actualizaciones disponibles y, a la vez, desconectar. Las dos cosas son compatibles, pero el orden importa. Un equipo detrás de una VPN con 5.3.2 está hoy mejor que uno en 5.4.0 abierto a internet, y nadie, ni el fabricante, ha dicho lo contrario.

Hay un tercer plano que Midnight Blue plantea y ninguna autoridad ha medido: la persistencia. Hasta ahora las dos oleadas se han limitado a subir consignas y forzar deshielos, un daño que se repara en horas. Un implante que sobreviva al restablecimiento de fábrica o un firmware que inutilice el controlador convierten el incidente en semanas sin frío y en una factura de hardware, y el Cyber Resilience Act no obligará al fabricante a dar soporte durante la vida útil del producto hasta el 11 de diciembre de 2027. Mientras llegan los CVE y, si llega, un parche con nombre, lo único que no depende de Danfoss es el cable: si tu AK-SM 800A responde desde internet esta noche, desconéctalo antes de instalar nada.