Vigilancia de seguridadRepaso a las 10 leyes inmutables de la seguridad, parte 1

Jesper M. Johansson

En el año 2000, Scott Culp publicó un ensayo titulado "Las 10 leyes inmutables de la seguridad". Es uno de los mejores ensayos acerca de la seguridad que he leído. La información que presentaba sigue siendo fundamental en todo trabajo en seguridad de la información y recomiendo consultarlo (e incluso imprimirlo) si todavía no lo ha hecho. Se puede encontrar en microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.

El ensayo tuvo distintas respuestas. Algunos comentan sarcásticamente que era un modo de que Microsoft evitara corregir lo que se consideraban problemas graves. Otros lo consideran uno de los escritos más fundamentales acerca de la seguridad y lo han plagiado debido a su gran importancia. Sin embargo, algunas de mis respuestas favoritas son las de las personas que se han inspirado para crear sus propias listas, como la que está disponible en edgeblog.net/2006/10-new-immutable-laws-of-it-security.

En los ocho años que han transcurrido desde la publicación del ensayo han sucedido muchas cosas en el terreno de la seguridad. Se ha publicado prácticamente todos lo digno de mención. Hemos entrado en un estado de conflicto de información (con crimen organizado, entidades políticas, etc.). Una serie de palabras y frases nuevas han pasado a formar parte del vocabulario común, incluido "phishing", granjas de servidores, botnet, spyware y suplantación de solicitudes entre sitios. Tenemos algunos de los rootkit más sofisticados que se han creado para Windows. Tenemos nuevas publicaciones de sistema operativo que están dedicadas, en gran medida, a la seguridad y otros sistemas operativos en los que la seguridad se ignora por completo.

La ingeniería social ha evolucionado hasta convertirse en una amenaza importante. Las infracciones de datos, como el caso en que un proveedor importante deja expuestos 94 millones de números de tarjeta de crédito, se han convertido en noticias habituales (y la gente sigue comprando en dichas tiendas). Los gobiernos de Estados Unidos y Reino Unido, conjuntamente, han conseguido extraviar información importante de un gran porcentaje de los habitantes del mundo occidental (y la gente sigue teniendo información privada con dichos gobiernos). Y una gran parte de la puesta en escena de la seguridad ha llegado a nuestras vidas, y a nuestros aeropuertos.

Creo que ha llegado el momento de revisar las leyes. En virtud de todos los cambios a los que hemos asistido en la primera parte del siglo, ¿podemos seguir proclamando que estas leyes son inmutables? Si lo son, si han sobrevivido los últimos 8 años, sin duda se puede decir con seguridad que sobrevivirán otros 10.

En esta serie de tres partes examinaré de forma crítica cada una de estas 10 líneas. Este mes traté las leyes 1 a 3. En el número del mes siguiente, examinaré las leyes 4 a 7. Y la entrega final la dedicaré a las leyes 8 a 10 y ofreceré ideas y comentarios adicionales que parecen razonables según lo que ha sucedido desde que las leyes se escribieron originalmente en el año 2000.

Ley 1: Si uno de los malos puede persuadirle para ejecutar un programa en su equipo, deja de ser su equipo.

Esta ley indica, de forma patente, que cualquier software que ejecute en el equipo puede controlar dicho equipo. Cuando aparecieron las leyes inmutables por primera vez, los sistemas operativos Microsoft eran Windows 98, Windows Me y Windows NT 4.0. En la actualidad tenemos Windows Vista y Windows Server 2008.

En Windows 98 y Windows Me, cualquier software ejecutado tenía control completo del equipo. Windows NT 4.0 tenía un modelo de seguridad subyacente muy sólido, pero si se ejecutaba como administrador, se reducía su modelo de aislamiento al de Windows 98 y Windows Me. Se podía ejecutar Windows NT 4.0 sin ser administrador, pero resultaba bastante complicado y muy pocas organizaciones lo hicieron (probablemente se podría contar el número total de organizaciones que lo hicieron sin usar los dedos de los pies).

Supongamos que ejecutaba Windows NT 4.0 sin ser administrador. ¿La ley 1 también era cierta cuando se escribió? La respuesta es sí. En primer lugar, Windows NT 4.0 tenía una gran cantidad de agujeros importantes. Por ejemplo, había permisos que podrían haber sido más estrictos, en concreto en los objetos de kernel y en el Registro. También había muchos tipos de ataques que todavía no se habían descubierto, pero que los expertos esperaban que sugieran. Por ejemplo, en 1999 los usuarios no se habían dado cuenta de que tener procesos que se ejecutaran como usuarios con privilegios elevados en el escritorio interactivo podían poner en peligro el equipo. No fue hasta 2002 cuando Chris Paget publicó sus notas de la versión sobre los ataques destructivos, Vulneración de la API Win32, que se convirtió en un conocimiento estándar (seclists.org/bugtraq/2002/Aug/0102.html).

¿Había previsto Microsoft los ataques destructivos cuando se redactó la ley 1? En realidad, no. Microsoft simplemente reconoció un hecho simple: hay muy pocos límites de seguridad auténticos que impidan que una aplicación que se ejecute en un equipo tome el control del mismo.

Windows Vista y Windows Server 2008 son dos generaciones que se han apartado de Windows NT 4.0. ¿Han invalidado la ley 1? ¿Existen otros sistemas operativos que lo hagan? Depende. Ciertamente, hay límites de seguridad más sólidos en los nuevos sistemas operativos y había algunos sistemas operativos experimentales en 2000 que tenían límites de seguridad adecuados. Sin embargo, sólo quedan algunos de esos límites. Por ejemplo, la seguridad de acceso del código de Microsoft .NET Framework es un límite de seguridad. Se ha diseñado específicamente para que el código que se ejecuta en el recinto de seguridad no afecte al sistema operativo subyacente.

Iframes en Internet Explorer proporciona otro límite de seguridad. Pero Iframes no afecta al acceso al sistema operativo, sólo al acceso entre las partes de contenido en una página web. El modo protegido en Internet Explorer, que se muestra en la figura 1, es un límite de seguridad de nivel de sistema operativo. Su finalidad es impedir que el código que se ejecuta en un explorador afecte al sistema operativo subyacente, sin intervención del usuario. Existen otros, como las cuentas de usuario estándar, que se supone que impiden que una cuenta de usuario afecte al sistema operativo subyacente o a otro usuario.

Figura 1 Internet Explorer 7 usa un límite de seguridad denominado modo protegido (haga clic en la imagen para ampliarla)

Es muy importante comprender lo que significa el término "límite de seguridad". No significa que haya una pared infranqueable que garantice un aislamiento impermeable e indefinido. Lo que el término significa realmente es que el fabricante de software, Microsoft por ejemplo, es responsable de corregir las infracciones de dicho límite mediante una revisión de seguridad. El software siempre tendrá errores y, sin duda, seguiremos descubriendo más infracciones que los fabricantes de software seguirán revisando. Con el tiempo, deben mejorar su software para evitar estas vulnerabilidades en primer lugar. Eso se puede considerar como una confirmación de que la ley 1 todavía sigue vigente.

No obstante, hay un elemento más esencial que debo tener en cuenta. Puede que anteriormente se haya dado cuenta de la frase "sin intervención del usuario". Realmente, la ley 1 no se refiere a defectos o vulnerabilidad del software. Realmente se refiere a las vulnerabilidades de las personas. La frase clave es "convencerle". Si uno de los malos puede convencerle para que ejecute su programa, probablemente le convencerá para que lo haga en un contexto que, por diseño, concede al programa privilegios elevados.

Incluso puede no importar que no tenga privilegios administrativos. Como usuario estándar tendrá acceso a mucha información sustancial: archivos bancarios, cartas de amor, imágenes, vídeos y datos confidenciales de la compañía. Todos estos datos tienen un interés potencial para un atacante y todos se pueden leer sin privilegios elevados. En lo que respecta a la información que administra en su equipo, la ejecución de un programa malintencionado entrega a un atacante todo lo que usted hace. Por lo tanto, si define "su equipo" como "los datos que administra en el equipo", puede ignorar las explicaciones acerca de los privilegios y simplemente concluir que la ley 1 sigue vigente.

Incluso sin hilar muy fino con respecto a la definición del equipo, la ley 1 parece haber resistido la prueba del tiempo. La cuestión de la ley 1 es establecer el hecho de que el usuario, como operador de un equipo, debe asumir la responsabilidad del software que se ejecuta en el equipo. Si instala un controlador malintencionado o un códec de vídeo malintencionado, le está entregando el control completo del equipo a un criminal.

Aunque los fabricantes de software pueden hacer mucho para prevenir los riesgos accidentales, a lo que realmente hacen referencia los límites de seguridad, la ejecución intencionada de software malintencionado por lo general superará todas las medidas de protección. Por este motivo el aprendizaje del usuario es fundamental, además de garantizar que los usuarios no tienen permiso para llevar a cabo tareas administrativas. Por lo tanto, se puede decir sin lugar a dudas que la ley 1 sigue vigente en la actualidad, pero posiblemente con una ligera modificación de la definición de equipo.

Ley 2: Si uno de los malos puede modificar el sistema operativo de su equipo, deja de ser su equipo.

A simple vista, esta ley parece bastante clara. Evidentemente, si uno de los malos puede modificar el sistema operativo de su equipo, ya no podrá confiar en él. Pero el significado de sistema operativo ha cambiado con la evolución de las necesidades de computación. Hace muchos años escribí una definición del término sistema operativo para The Blackwell Encyclopedia of Management (managementencyclopedia.com). En la definición se hablaba de un sistema operativo que administra el acceso a los dispositivos de entrada y de salida, el acceso al hardware y cuestiones similares. Ahora bien, nunca obtuve una copia de la enciclopedia y mi envío original se perdió en la historia, pero estoy seguro de que no mencioné que un sistema operativo incluye el solitario, un sistema de entrada por tableta y transcodificadores de vídeo.

A medida que se ha ido complicando la computación, los sistemas operativos se han ampliado para ofrecer más capacidades. Para complicarlo todo aún más, los OEM suelen incluir su propio surtido de software adicional, que normalmente va desde lo útil hasta lo francamente perjudicial. Y parte de este software adicional duplica la funcionalidad ya integrada en el sistema operativo principal.

Por ejemplo, una instalación predeterminada de Windows Server 2008 Enterprise Edition ocupa en disco más de 5 gigabytes. Windows Vista Ultimate Edition incluye más de 58.000 archivos que ocupan más de 10 gigabytes. Y hay algo más que simples archivos que componen el sistema operativo. Están las miles de opciones de configuración y los demonios o servicios.

Todos ellos forman parte del sistema operativo. Se trata de un término colectivo que incluye todos los archivos, todas las opciones de configuración y todos los servicios, así como todos los objetos de tiempo de ejecución (semáforos, canalizaciones con nombre, extremos de RPC) creados por los archivos y las opciones de configuración. Incluso las construcciones de elevada abstracción, como la hora del sistema y determinados tipos de datos, por ejemplo el contenido de los registros de eventos, se deben considerar parte del sistema operativo.

Si se tiene en cuenta lo que ha crecido y evolucionado el sistema operativo, ¿realmente se considera que al modificar cualquiera de estos archivos se resta confiabilidad al equipo? La respuesta directa es no. Por ejemplo, Windows Vista incluye edlin.exe, el antiguo editor de líneas de MS-DOS. No puedo afirmarlo a ciencia cierta, pero me apuesto un café triple grande que edlin.exe sólo se ha invocado un par de veces en todas las copias instaladas de Windows Vista desde que se publicó el sistema operativo. Ambas veces han sido hace tres minutos, cuando intentaba recordar la sintaxis. ¿Si alguien modifica edlin.exe o algún otro archivo que nadie usa jamás, significa realmente que ya no es su equipo?

Indiscutiblemente edlin.exe forma parte del sistema operativo, pero si nadie ejecuta el archivo, ¿cómo una modificación va a poner en peligro el equipo? Evidentemente, la respuesta es que no lo pondrá. La modificación de una parte del sistema operativo que nunca se usa no pondrá en peligro el equipo. Y hay numerosas partes del sistema operativo que nunca se usan.

No obstante, la respuesta indirecta es sí. No se puede tener en cuenta simplemente el hecho de si alguien ejecuta un archivo para considerar si su modificación puede poner en peligro el equipo. El problema es más sutil. Observe la lista de control de acceso (ACL) de edlin.exe, mostrada en la figura 2.

Figura 2 La ACL de edlin.exe es muy restrictiva (haga clic en la imagen para ampliarla)

La ACL de edlin.exe es muy restrictiva. Sólo el servicio TrustedInstaller tiene derechos para modificar dicho archivo ejecutable. Esto es muy importante: significa que hay un efecto indirecto para uno de los malos que modifique dicho archivo en su equipo. El acto de modificar edlin.exe no significa que ya no sea su equipo. Es el hecho de que el usuario malintencionado tiene la capacidad de modificar edlin.exe, que en este caso es clave. Si uno de los malos puede modificar el archivo, puede modificar cualquier archivo, lo que significa que ya no puede confiar en nada del equipo.

El sistema operativo se protegerá a sí mismo. Los servicios están protegidos contra la modificación no autorizada. Las opciones de configuración están protegidas contra la modificación no autorizada. Los archivos del disco están protegidos contra la modificación no autorizada. Incluso los semáforos y los extremos RPC que usa el sistema operativo están protegidos contra la modificación no autorizada. Si un atacante puede modificar cualquiera de estos objetos protegidos, podrá modificarlos todos y, muy posiblemente, ya lo habrá hecho.

Se trata de un punto crítico. Con varias de las leyes inmutables, no es el acto de hacer algo lo que significa que el equipo está en peligro. Lo que importa es que alguien tiene la capacidad de hacer algo. Esta cuestión no se debe obviar. En todos los aspectos de la seguridad de los equipos, siempre se debe recordar que la capacidad suele ser tan importante como la acción que se realice realmente.

Si un equipo está abierto a Internet y hace meses que no se le aplican revisiones, ¿sigue siendo de confianza? No. Se debe considerar que el equipo está en peligro. No se puede confiar en nada de un sistema que ha estado en peligro. (Dije lo mismo hace cinco años en mi artículo "Socorro. Me han atacado. ¿Qué debo hacer?" disponible en technet.microsoft.com/library/cc512587.) Si se enfrenta a un adversario hábil, puede que el sistema en peligro ni siquiera muestre signo alguno de que haya estado en peligro. El sistema puede parecer perfectamente normal.

Sin duda, la ley 2 todavía sigue vigente. Si un atacante tiene la capacidad de modificar un objeto protegido del equipo, deja de ser su equipo. Recuerde que es la capacidad de modificar estos objetos lo que importa, no si realmente se ha realizado el ataque.

Ley 3: Si uno de los malos tiene acceso físico sin restricción a su equipo, ya no es su equipo.

Esta ley fue esencial en el año 2000. Muchos usuarios no acababan de comprender lo que se podía hacer con el acceso físico a un sistema. De hecho, algunos organismos gubernamentales que debían tener un mejor conocimiento no tuvieron en cuenta esta cuestión fundamental. En aquel tiempo, la orientación de seguridad recomendaba deshabilitar la opción que permitía apagar sin iniciar sesión. Esto provoca que el botón Apagar… de la pantalla de inicio de sesión esté atenuado. La teoría subyacente es que para apagar el equipo, el usuario primero debe iniciar sesión para que haya un registro de auditoría de quién apaga el sistema.

Se trata de un caso práctico de idea errónea. Para tener acceso al botón Apagar… de la pantalla de inicio de sesión, hay que estar realmente delante de la consola. Y si está delante de la consola y realmente desea apagar el equipo, normalmente se usa el gran botón redondo que hay en la parte frontal del equipo o incluso el cable de alimentación. Sistema apagado. Sin seguimiento de auditoría.

Windows 2000 incluye una configuración de seguridad denominada Permitir desacoplamiento sin tener que iniciar sesión y esta opción sigue estando disponible en Windows Vista, tal y como se muestra en la figura 3. El principio es el mismo. Para desacoplar un equipo portátil de su estación de acoplamiento, primero se debe iniciar sesión en el sistema.

Figura 3 ¿Y por qué no robar el equipo y la base de acoplamiento? (haga clic en la imagen para ampliarla)

El valor real de la seguridad de esta configuración es muy dudoso. Pienso que la teoría es que si alguien puede acercarse al equipo portátil y desacoplarlo, le resultaría fácil robarlo. Ahora bien, no es que vaya a robar un equipo portátil, pero si fuera a hacerlo, esta medida preventiva no me disuadiría. Probablemente me llevaría el equipo y la estación de acoplamiento a la vez. Caramba, también robaría el cable de red y el de alimentación. Veamos una optimización de seguridad absurda.

La cuestión del acceso físico realmente me hizo pensar cuando Petter Nordahl-Hagen creó su Offline NT Password & Registry Editor. Su creación era simplemente un disco de arranque Linux con un controlador de sistema de archivos NTFS experimental que permitía el acceso de lectura y escritura a un volumen NTFS. El software del disco de arranque montaba el Registro del equipo local y escribía una nueva contraseña de la cuenta Administrador en la rama SAM (administración de activos de software). Todo lo que se necesitaba era acceso físico al sistema y uno o dos minutos.

La ley 3 se escribió principalmente debido a herramientas como ésta. De hecho, la herramienta de Nordahl-Hagen se usó en numerosas demostraciones. Por desgracia, la cuestión nunca trascendió a la inmensa mayoría de los usuarios. Personalmente he usado la herramienta en algunas demostraciones, pero dejé de usarla después de que me cansé de que me preguntaran, "¿cómo nos aseguramos de que ninguno de nuestros usuarios conoce herramientas como ésta?" y "¿qué hace Microsoft para corregir este problema?" Una parte alarmantemente grande del sector de TI no desea aceptar o comprender que el acceso físico acabaría con todo lo demás.

En ese entorno, la ley 3 constituyó una declaración muy importante. Aunque los críticos arremetieron contra ella sin piedad. Se ridiculizó como el intento de Microsoft para evitar tener que corregir cualquier problema que pudiera estar, incluso del modo más remoto, vinculado con el acceso físico. Realmente la ley 3 se usó en varios casos para descartar informes de vulnerabilidad, incluido el programa Offline NT Password & Registry Editor. No obstante, bloquear a los atacantes que tiene acceso físico al sistema sólo se puede hacer de un modo: garantizar que no puedan llegar.

Ahí es donde posiblemente se encuentre el punto débil de la ley 3. Desde que se escribieron las leyes, la tecnología de cifrado del disco completo se ha convertido en una solución viable. Con dicho cifrado, más correctamente denominado cifrado de volumen completo, se puede cifrar todo un volumen (que se denomina partición en otros sistemas operativos). Por lo tanto, si todo el volumen de arranque (es decir, el volumen que contiene el sistema operativo) está cifrado, nos debemos preguntar si la ley 3 sigue vigente.

La respuesta es un firme probablemente. En primer lugar, las claves de descifrado se tienen que almacenar en algún lugar. El lugar más simple para guardar las claves, y la opción predeterminada en BitLocker, es un chip Trusted Platforms Module en el equipo. De este modo, el equipo arrancará desatendido. Una vez iniciado el equipo, un atacante con recursos y bien financiado con control físico permanente al equipo puede atacarlo de varias formas. Debido a que el equipo ahora se puede conectar a una red arbitraria, puede haber formas relacionadas con la red de atacar el sistema.

Por ejemplo, el atacante puede leer o escribir en la memoria mediante un dispositivo de acceso directo a memoria (DMA), como una unidad flash USB. Una vez que el equipo está en funcionamiento, no hay nada imposible para un atacante con acceso físico al equipo.

Si las claves no están almacenadas en el equipo, el ataque dependerá de si el atacante puede obtenerlas o adivinarlas. Si se usa un código NIP para iniciar el equipo, el atacante probablemente podrá adivinar el código con relativamente poco esfuerzo. Si las claves se almacenan o derivan de un dispositivo de hardware independiente, como una unidad flash USB o un acceso de contraseña única, el atacante debe tener acceso a dicho dispositivo. Ciertamente hay formas de obtener estas claves o de incomodar a la persona que tiene acceso a ellas, aunque el esfuerzo necesario probablemente sea un poco mayor.

También se podría interpretar la ley 3 de un modo ligeramente distinto: "si el atacante tiene acceso físico a su equipo, es probable que haya robado el equipo y, por lo tanto, es improbable recuperarlo". Desde ese punto de vista, realmente ya no es su equipo. Y desde esa perspectiva, al atacante puede no importarle si puede obtener acceso al equipo o no. No obstante, realmente el espíritu de la ley 3 no se refiere a eso. Significa que el atacante ha tenido acceso a los datos del equipo y no sólo al equipo.

Bien mirado, la ley 3 todavía sigue vigente. Es cierto que determinadas tecnologías disponibles hoy en día llegan muy lejos para detener a muchos atacantes con acceso físico y, por lo tanto, reducir el número de atacantes que pueden obtener acceso a los datos de un equipo que emplea una medida de seguridad. Dicho esto, las capacidades del atacante siempre definen lo que realmente puede conseguir y las nuevas tecnologías resuelven muchas de las 10 leyes inmutables, hasta cierto punto. Pero el acceso físico todavía ofrece modos, aunque más complejos, de entrar en un sistema.

Hasta ahora, las leyes inmutables de seguridad han demostrado ser muy resistentes, tanto a los avances tecnológicos como al tiempo. De las tres primeras leyes, la tercera es la más dudosa, aunque todavía sigue vigente en algunos casos. Sin embargo, es a la que se han aplicado más soluciones disponibles inmediatamente y sólidas. Volveré en los dos próximos números de TechNet Magazine para seguir con esta explicación y determinar si las leyes 4 a 10 siguen siendo inmutables.

Jesper M. Johansson es un arquitecto de software que trabaja en el campo del software de seguridad y colabora como editor en TechNet Magazine. Posee un doctorado en sistemas de información de administración, más de 20 años de experiencia en el ámbito de la seguridad y es MVP de Microsoft en seguridad empresarial. Su último libro es Windows Server 2008 Security Resource Kit.