Una de las principales fortalezas de z/OS es su arquitectura de aislamiento entre servicios. Cada programa ejecuta en su propio espacio de direcciones, lo que permite que un fallo en un Job batch, por ejemplo, se limite a la cancelación con un código S0C4, sin afectar al resto del sistema. Este diseño asegura que servicios críticos, como seguridad, CICS, bases de datos o comunicaciones, sigan funcionando normalmente.

Sin embargo, desde la aparición del sistema XA en los años 80, existe una zona de memoria compartida entre espacios: la CSA (Common Storage Area) y su equivalente en 64 bits, la ECSA (Extended CSA).

Estas áreas permiten compartir datos entre espacios, como ocurre en CICS, donde los controladores de terminal y el maestro intercambian información a través de memoria compartida, logrando así el altísimo rendimiento característico de los mainframes.

El problema: escribir en CSA con claves de usuario

Para escribir en estas áreas, los programas deben ejecutarse desde librerías APF y estar linkeditados con el atributo AC=1. Pero durante décadas bastaba con saber hacer un GETMAIN desde el assembler para reservar memoria en la CSA usando claves de usuario.

Esta vulnerabilidad fue ampliamente conocida entre los programadores de sistemas, pero nunca documentada oficialmente ni resuelta en nuevas versiones de z/OS durante más de 30 años.

Casos reales de explotación

El primer incidente que detectamos fue en 2002. Un cliente sufrió una intrusión que aprovechaba otra vulnerabilidad relacionada con VTAM. Al analizar el código malicioso, descubrimos que podía provocar un Software Stop: escribía ceros en toda la CSA, congelando el LPAR al completo.

El atacante había dejado dos programas disfrazados en librerías de APF: uno para escalar privilegios a SPECIAL & OPERATIONS , y otro para detener todo el sistema. Aunque se resolvió el problema de VTAM y se investigó a fondo, no se pudo determinar si hubo fuga de datos porque no se auditaban los accesos autorizados.

El segundo caso lo encontramos en un foro técnico, donde se compartió un código casi idéntico. Solo añadimos un aviso como WTO: si este código llega a ejecutarse, alguien deberá responder profesionalmente por ello.

¿Y si se convierte en una bomba lógica?

Convertir este código en una bomba lógica es simple: basta con propagarlo a las librerías de arranque y a los procedimientos. Se ejecutará cada vez que se haga un IPL, afectando también al centro alternativo por replicación síncrona. El sistema se volverá inservible.

Si esto ocurre, es porque el atacante sabe más que quienes administran la seguridad del sistema. Y eso tiene consecuencias.

Solución tardía pero efectiva

Con z/OS 1.9 apareció el parámetro VSM ALLOWUSERKEYCSA(YES/NO) en DIAGxx, con valor recomendado NO. Sin embargo, muchas casas de software tardaron años en adaptar sus productos, lo que retrasó la adopción generalizada del cambio.

A partir de z/OS 2.3, el parámetro desaparece y el comportamiento por defecto es impedir el uso de claves de usuario en CSA. La vulnerabilidad queda oficialmente cerrada.

¿Qué hacemos ahora con este código?

Ahora podemos usar este código como herramienta de prueba en entornos controlados. Si todo está bien configurado, el sistema no permitirá su ejecución. Es una prueba de fuego para verificar si los controles están activos.

¿Y quedan más vulnerabilidades?

Sí. Aunque algunas se cierran después de décadas, otras nacen hoy. Las auditorías de seguridad en entornos z/OS deberían indicar si los controles relevantes están activos y si el riesgo está documentado.

Esta vulnerabilidad demuestra que un pequeño descuido técnico puede tener consecuencias catastróficas. Afortunadamente, hoy se puede mitigar. Pero la clave sigue siendo la vigilancia activa, las auditorías periódicas y la formación especializada.

¿Quiere saber si su instalación es vulnerable? ¿Desea probar este código en un entorno seguro? Contáctenos y se lo facilitaremos.