Durante semanas, los ataques a casi 1,000 switches Zyxel GS1900 se atribuyeron a un fallo que Zyxel había corregido en junio. No era así. La empresa de seguridad Binarly encontró el exploit que usaban los atacantes y descubrió que funcionaba igual en los equipos ya actualizados: aprovechaba otro fallo, desconocido hasta entonces, que ahora se registra como CVE-2026-107441. Zyxel lo corrigió con el firmware 2.90 Patch 3 y publicó su aviso el 3 de noviembre.
Los GS1900 son switches administrables pensados para oficinas y pequeñas empresas, y se configuran desde una página web que corre dentro del propio equipo. El 16 de junio, Zyxel corrigió en esa página el CVE-2026-7273, un desbordamiento de búfer que permitía ejecutar órdenes sin contraseña. A partir del 17 de agosto, la firma GreyNoise empezó a ver ataques contra estos switches: un grupo de habla china, al que llama Kapibala y vincula con la campaña Red Heron, tomó el control de 996 equipos en 48 países y, tras entrar, ejecutaba un script que copiaba su configuración, el hash de la contraseña de administrador y datos de la red. El 21 de septiembre, GreyNoise atribuyó los ataques al fallo de junio y la agencia de ciberseguridad de Estados Unidos, CISA, lo agregó a su lista de fallos explotados. Para muchos administradores, el mensaje fue claro: con el parche de junio, sus equipos estaban protegidos.
Binarly llegó por otro camino. Mientras investigaba los servidores de Red Heron, relacionados con la puerta trasera JITTERLY y el rootkit SIXZUT, encontró en uno de ellos un archivo expuesto con el exploit: un programa en Python ofuscado que primero revisaba si el switch tenía el parche de junio. Lo probó y confirmó el 28 de septiembre que funcionaba en las diez versiones de firmware ya parchadas. Avisó a Zyxel al día siguiente, Zyxel confirmó el 11 de octubre que se trataba de un fallo distinto y el 22 de octubre publicó el firmware que lo corrige. Para Binarly, «el parche de junio dio a los clientes una falsa sensación de seguridad».
Claves del zero-day de los Zyxel GS1900
- Dónde está el fallo. En dispatcher.cgi, el programa que atiende las peticiones de la página de administración. Copia cada parámetro de la petición a un búfer de memoria de tamaño fijo sin revisar cuánto mide ni cuántos son. Es una escritura fuera de límites: un dato demasiado largo sigue escribiendo más allá del espacio que le toca.
- Por qué el parche de junio no sirvió. Zyxel añadió una revisión del número de parámetros, pero se hacía después de copiarlos. Un parámetro enorme se desborda y altera el contador de parámetros antes de que la revisión lo lea, así que el control ve un número falso y deja pasar la petición.
- Qué gana el atacante. Con peticiones HTTP preparadas, y sin contraseña, puede ejecutar órdenes en el sistema del switch. Zyxel le da una gravedad de 8.8 sobre 10 y dice que el atacante debe estar en la red local; Binarly la califica con 9.8, dice que funciona desde cualquier red que llegue a la página del switch y que da acceso de administrador total.
- Diez modelos afectados. GS1900-8, -8HP, -10HP, -16, -24, -24E, -24EP, -24HPv2, -48 y -48HPv2. Las versiones Patch 2 y anteriores siguen expuestas.
- Contraseñas de fábrica. De los 996 equipos atacados, 564 conservaban las credenciales con las que salieron de fábrica, según eSecurityPlanet.
- ¿Un exploit hecho con IA? Binarly cree que el programa del atacante se generó con un modelo de lenguaje, y anunció que publicará una prueba de concepto reducida.
Qué deben hacer quienes administran estos switches
Lo primero es instalar el firmware 2.90 Patch 3 del modelo exacto y comprobar en cada equipo la versión que de verdad está corriendo: un inventario que solo diga «tiene el parche de junio» ya no sirve. Después, conviene que la página de administración no sea accesible desde redes en las que no se confía, cambiar las contraseñas, sobre todo si siguen siendo las de fábrica, y comparar la configuración con un respaldo conocido. Actualizar cierra la puerta, pero no echa a quien ya entró: un switch que estuvo expuesto entre agosto y octubre debe revisarse como posiblemente comprometido.
El caso deja una lección que va más allá de Zyxel. Un parche puede revisar lo correcto en el momento equivocado, y las herramientas que solo comparan números de versión dirán que un equipo está protegido cuando no lo está. Esta vez, el error se descubrió porque alguien analizó el exploit real de los atacantes, en lugar de dar por hecho cuál fallo usaban. Si se confirma que ese exploit lo escribió una IA, también será una muestra de lo rápido que se pueden encontrar las grietas de un parche apresurado.
Fuente: SecurityWeek; BleepingComputer; eSecurityPlanet; Daily Security Review; Binarly. Imagen de portada: Zyxel.