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\u00f3n con un c\u00f3digo S0C4, sin afectar al resto del sistema. Este dise\u00f1o asegura que servicios cr\u00edticos, como seguridad, CICS, bases de datos o comunicaciones, sigan funcionando normalmente.<\/p>\r\n
Sin embargo, desde la aparici\u00f3n del sistema XA en los a\u00f1os 80, existe una zona de memoria compartida entre espacios: la CSA (Common Storage Area) y su equivalente en 64 bits, la ECSA (Extended CSA).<\/p>\r\n
Estas \u00e1reas permiten compartir datos entre espacios, como ocurre en CICS, donde los controladores de terminal y el maestro intercambian informaci\u00f3n a trav\u00e9s de memoria compartida, logrando as\u00ed el alt\u00edsimo rendimiento caracter\u00edstico de los mainframes.<\/p>\r\n\r\n
Para escribir en estas \u00e1reas, los programas deben ejecutarse desde librer\u00edas APF y estar linkeditados con el atributo AC=1. Pero durante d\u00e9cadas bastaba con saber hacer un GETMAIN desde el assembler para reservar memoria en la CSA usando claves de usuario.<\/p>\r\n
Esta vulnerabilidad fue ampliamente conocida entre los programadores de sistemas, pero nunca documentada oficialmente ni resuelta en nuevas versiones de z\/OS durante m\u00e1s de 30 a\u00f1os.<\/p>\r\n\r\n
El primer incidente que detectamos fue en 2002. Un cliente sufri\u00f3 una intrusi\u00f3n que aprovechaba otra vulnerabilidad relacionada con VTAM. Al analizar el c\u00f3digo malicioso, descubrimos que pod\u00eda provocar un Software Stop: escrib\u00eda ceros en toda la CSA, congelando el LPAR al completo.<\/p>\r\n
El atacante hab\u00eda dejado dos programas disfrazados en librer\u00edas de APF: uno para escalar privilegios a SPECIAL & OPERATIONS , y otro para detener todo el sistema. Aunque se resolvi\u00f3 el problema de VTAM y se investig\u00f3 a fondo, no se pudo determinar si hubo fuga de datos porque no se auditaban los accesos autorizados.<\/p>\r\n
El segundo caso lo encontramos en un foro t\u00e9cnico, donde se comparti\u00f3 un c\u00f3digo casi id\u00e9ntico. Solo a\u00f1adimos un aviso como WTO: si este c\u00f3digo llega a ejecutarse, alguien deber\u00e1 responder profesionalmente por ello.<\/p>\r\n\r\n
Convertir este c\u00f3digo en una bomba l\u00f3gica es simple: basta con propagarlo a las librer\u00edas de arranque y a los procedimientos. Se ejecutar\u00e1 cada vez que se haga un IPL, afectando tambi\u00e9n al centro alternativo por replicaci\u00f3n s\u00edncrona. El sistema se volver\u00e1 inservible.<\/p>\r\n
Si esto ocurre, es porque el atacante sabe m\u00e1s que quienes administran la seguridad del sistema. Y eso tiene consecuencias.<\/p>\r\n\r\n
Con z\/OS 1.9 apareci\u00f3 el par\u00e1metro VSM ALLOWUSERKEYCSA(YES\/NO) en DIAGxx, con valor recomendado NO. Sin embargo, muchas casas de software tardaron a\u00f1os en adaptar sus productos, lo que retras\u00f3 la adopci\u00f3n generalizada del cambio.<\/p>\r\n
A partir de z\/OS 2.3, el par\u00e1metro desaparece y el comportamiento por defecto es impedir el uso de claves de usuario en CSA. La vulnerabilidad queda oficialmente cerrada.<\/p>\r\n\r\n
Ahora podemos usar este c\u00f3digo como herramienta de prueba en entornos controlados. Si todo est\u00e1 bien configurado, el sistema no permitir\u00e1 su ejecuci\u00f3n. Es una prueba de fuego para verificar si los controles est\u00e1n activos.<\/p>\r\n\r\n
S\u00ed. Aunque algunas se cierran despu\u00e9s de d\u00e9cadas, otras nacen hoy. Las auditor\u00edas de seguridad en entornos z\/OS deber\u00edan indicar si los controles relevantes est\u00e1n activos y si el riesgo est\u00e1 documentado.<\/p>\r\n\r\n
Esta vulnerabilidad demuestra que un peque\u00f1o descuido t\u00e9cnico puede tener consecuencias catastr\u00f3ficas. Afortunadamente, hoy se puede mitigar. Pero la clave sigue siendo la vigilancia activa, las auditor\u00edas peri\u00f3dicas y la formaci\u00f3n especializada.<\/p>\r\n