Vigilancia de seguridadSalto de islas: atenuación de las dependencias no deseadas
Jesper M. Johansson
En la entrega del pasado mes de Vigilancia de seguridad, expliqué los pasos iniciales para usar una unidad flash USB para atacar una red. El ataque se iniciaba con una unidad flash USB infectada que se conectaba a un equipo. A continuación, se ejecutaba el código malintencionado, ya sea automáticamente o con un poco de ayuda del usuario (mediante el uso de algo de ingeniería
social simple). Este ataque permanecía local en la estación de trabajo, pero es evidente que el malware se podía haber propagado al resto de la red. Trataré esta forma de ataque en una red en detalle en mi próximo libro, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008), y voy a adaptar partes de dicho capítulo para esta columna.
Obviamente, una opción para la protección es prohibir las unidades de disco extraíbles. Aunque esta acción pueda parecer prudente, es muy probable que los usuarios le tiendan una emboscada cuando se dirija al coche si intenta llevarla a cabo, y puede ser difícil reprochárselo si actúan así. La mejor opción, en la mayoría de los entornos con datos confidenciales, es intentar administrar el riesgo relacionado y contener la exposición.
Además, las unidades extraíbles no constituyen el único medio de poner en peligro un equipo cliente. ¿Recuerda las “10 leyes inmutables de la seguridad" (disponible en microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)? La idea general de la ley 3 sigue siendo vigente: "Si un intruso tiene acceso físico sin restricción a su equipo, ya no es su equipo." En el contexto de esta explicación, si un atacante tiene acceso a su equipo, se puede considerar que está en peligro. Esto incluso se puede llevar a cabo de forma remota si el atacante puede convencerle para que ejecute el código en el equipo. Puede reconocer esta situación como la ley 1 de las leyes inmutables: "Si un intruso puede persuadirle de ejecutar este programa en su equipo, ya no es su equipo."
Se puede suponer con seguridad que estas leyes siguen vigentes. Se ha demostrado que son realmente resistentes y es muy poco probable que cambien considerablemente hasta que cambiemos de forma sustancial la forma en que funcionan los equipos. Por lo tanto, si se tiene en cuenta el modo en que estas leyes se aplican al escenario descrito, es esencial que quite fuerza a las unidades extraíbles. Y puede hacerlo con unos pocos ajustes del Registro.
Evidentemente, también debe usar capas adicionales de protección. Puede suponer razonablemente que muchos de los equipos cliente ya han estado en peligro o los han usado otros usuarios que no siempre tienen en mente buenas intenciones para su organización. Esto significa que necesita mitigar sus efectos en el resto de la red y que aumenta la importancia de entender, analizar y mitigar las dependencias de seguridad.
Definición de una dependencia de seguridad
Una dependencia de seguridad se produce cuando la seguridad de un equipo depende de la seguridad de otro. Puede haber oído decir que si el controlador de dominio (DC) está atacado también lo está toda la red. Es una forma simple de indicar que todos los miembros de dominio dependen de los DC para su seguridad. Si el DC no está seguro, los equipos miembro no pueden estar seguros. Si un atacante puede cambiar la configuración de seguridad del dominio, puede tomar el control de cualquier equipo de la red, por ejemplo con la agregación de nuevas cuentas al grupo Administradores en un equipo miembro. Cualquier vulnerabilidad que permita que un administrador constituya un peligro no es interesante. Se supone que un administrador tiene acceso completo a lo que está administrando.
Las dependencias en sistemas de equipos son inevitables. De hecho, son habituales y, con frecuencia, deseables. No obstante, no significa que todas las dependencias sean aceptables. En esta columna explico los tipos de dependencias que son aceptables y cuáles no. Después, analizaré los tipos de dependencias y cómo mitigarlas. En Windows Server 2008 Security Resource Kit trato con más detalle las dependencias específicas y explico cómo administrarlas.
Dependencias aceptables
En general, una dependencia es aceptable cuando un sistema menos sensible depende de un sistema más sensible para la seguridad. Los equipos y los sistemas, por lo general, se pueden dividir en clases en función de lo sensibles que sean (el conjunto específico de clases en un entorno concreto no es relevante para la explicación general, lo que importa es que hay clasificaciones inherentes). Para ilustrar la explicación, supongamos que tengo dos clasificaciones: estaciones de trabajo y DC. En este escenario, es aceptable que las estaciones de trabajo dependan de los DC para su seguridad. La clase de DC es con diferencia más sensible que las estaciones de trabajo por lo que, evidentemente, se debe proteger mejor.
El mismo argumento se puede aplicar a las cuentas de usuario. Es aceptable que un administrador pueda poner en peligro los datos que posee un usuario. Esto se debe a que los administradores tienen más responsabilidad y disponen de acceso sin restricciones (aunque no siempre directo o evidente) al equipo y a todo lo que contiene. Si comprende este punto y administra los equipos de forma adecuada, no hay ningún problema con esta dependencia.
Incluso el software se puede analizar de la misma manera. Ciertamente es aceptable para un elemento de software menos sensible, como un explorador web, que usa y depende de un elemento de software más sensible, como el sistema operativo, para su seguridad. Si el sistema operativo tiene un error, no sorprende el hecho de que el explorador web ahora sea vulnerable a problemas nuevos y probablemente ocupa los últimos lugares en la lista de preocupaciones inmediatas. El sistema operativo y otras aplicaciones críticas constituirán el principal foco de atención. Esto corresponde al modo en que los errores se corrigen o al destino de las revisiones. Un error se debe corregir lo antes posible una vez identificado el problema. Al hacerlo así, se maximiza el efecto protector de la corrección. De este modo, en vez de solucionar el problema en el explorador web se debe corregir el sistema operativo.
La dependencia también se puede quitar si se cambia el diseño. Por ejemplo, el explorador web se puede rescribir para reducir sus dependencias del sistema operativo. Este último enfoque resulta adecuado en los casos en que la funcionalidad de los componentes más seguros (el sistema operativo, en este caso) nunca se ha previsto usar realmente en la forma en que el componente menos sensible (el explorador web) la usa.
Dependencias inaceptables
Según mi explicación de dependencias aceptables, la definición de una dependencia inaceptable ahora debe ser evidente. Básicamente, un sistema más sensible nunca debe depender de un sistema menos sensible para su seguridad.
Si el riesgo de una estación de trabajo significa que se ha infringido la seguridad del DC, tiene entre manos un grave problema de seguridad. Es imposible proteger una red si su seguridad agregada depende de la seguridad de cada uno de los equipos de la red.
Considere esto desde el punto de vista estadístico. Si cada equipo de la red es "seguro" el 99,999 por ciento del tiempo, puede considerar que tiene una red muy segura. De hecho, ese porcentaje probablemente está muy alejado de la realidad en la mayoría de las redes más pequeñas de hoy en día. Pero ahora suponga que la red tiene 40.000 equipos y cada uno es vulnerable el 0,001 por ciento del tiempo. Hablando de forma práctica, la red general no estaría segura hasta un posible 40 por ciento del tiempo.
Y, por supuesto, con las dependencias no administradas basta un equipo a ese 0,001 por ciento del tiempo para poner en peligro toda la red. En estos términos, ¿en qué medida es segura la red? Evidentemente, es absolutamente primordial que los sistemas más sensibles estén protegidos de los menos sensibles.
Este argumento se puede aplicar fácilmente a las cuentas de usuario y al software. Por ejemplo, el nuevo cliente de Terminal Services para Windows® permite almacenar los nombres de usuario y las contraseñas para un inicio de sesión en Terminal Services prácticamente transparente. Estas credenciales se almacenan mediante la API del administrador de credenciales, protegida por las credenciales usadas para la sesión de inicio de sesión principal.
Esto puede crear una dependencia de seguridad. Tomemos el caso de una administradora de red que inicia sesión en su estación de trabajo personal. Usa esta estación de trabajo para el correo electrónico, la exploración web y otras tareas típicas de los trabajadores de la información. Naturalmente, usa una cuenta de dominio con pocos privilegios para este fin.
En algún momento durante el día, esta administradora se conecta a uno de los DC para efectuar algunas tareas de administración. Usa el cliente de Terminal Services para ello y decide almacenar su contraseña para facilitar las conexiones futuras. Esto deriva en al menos una y posiblemente dos dependencias de seguridad inaceptables. La primera es que sus credenciales de cuenta administrativa de dominio ahora están protegidas por sus credenciales de trabajador de la información con pocos privilegios. Si esta cuenta de usuario con pocos privilegios está en riesgo, la cuenta de usuario administrativo de dominio también está en riesgo y, por lo tanto, todo el dominio.
La segunda dependencia se deriva del hecho de que ha escrito una credencial administrativa de dominio en un controlador que no es de dominio. A menos que su estación de trabajo personal esté protegida como mínimo como los DC, y probablemente no lo está, hay una dependencia en la que la seguridad de los DC depende de la seguridad de la estación de trabajo personal de este usuario. Por ejemplo, si un empleado descontento en la misma oficina ha instalado un programa de registro de pulsaciones de teclas en la estación de trabajo del administrador de la red, las credenciales administrativas de dominio ahora están capturadas. Siempre que escribe una credencial administrativa de dominio en un controlador que no es de dominio está exponiendo todo el dominio a los defectos de seguridad en dicho controlador.
Ahora suponga que un atacante inserta una unidad extraíble en un equipo donde un administrador de dominio ha iniciado sesión actualmente, en el que ha iniciado sesión alguna vez o en el que iniciará sesión. El administrador de dominio está en peligro y, por extensión, todo el dominio. Es imprescindible que comprenda esta situación para poderla evitar. Y, por supuesto, la misma situación puede suceder con el software cuando una aplicación segura depende de la funcionalidad de una aplicación menos segura para realizar una determinada tarea.
Análisis de un ataque
Anteriormente he descrito lo que puede suceder si una unidad extraíble malintencionada se inserta en un equipo. No obstante, sólo puede ser evidente lo que le sucedería al equipo en el que la unidad se ha insertado inicialmente. Así que suponga que el equipo en cuestión está unido al dominio, tal como se muestra en la Figura 1.
Figura 1** Dependencias de dominio ideales **
La situación presentada aquí representa una dependencia ideal. Las flechas son direccionales e indican de dónde se hereda la dependencia. Por ejemplo, la seguridad de la estación de trabajo depende de la seguridad del DC y la seguridad del usuario depende de la seguridad de la estación de trabajo. El atacante puede poder poner en peligro la estación de trabajo, que pone en peligro cualquier información que el usuario ha guardado en ella, aunque el riesgo quedaría aislado ahí.
Pero suponga que el usuario que ha iniciado sesión en la estación de trabajo es miembro del grupo de administradores locales en el servidor. Y suponga que el administrador de dominio suele iniciar sesión en el servidor. Ahora tenemos las dependencias que se muestran en la Figura 2.
Figura 2** Dependencias de dominio en riesgo **
Al cambiar simplemente el supuesto de quién ha iniciado sesión en el equipo en cuestión, se ha puesto en peligro la seguridad de toda la red. Debido a que un administrador de dominio inicia sesión en el servidor, la seguridad del DC y, por tanto, de todo el dominio depende de la seguridad de dicho servidor.
Esto sería aceptable si el servidor estuviera administrado de forma tan segura como el DC. No obstante, en este caso, un usuario que inicia sesión en la estación de trabajo es un miembro del grupo Administradores en el servidor. Por lo tanto, la seguridad del servidor depende de la seguridad de la estación de trabajo. Esto significa que la seguridad de todo el dominio depende de la seguridad de la estación de trabajo. Y adivine qué pasó: el usuario de esta estación de trabajo ejecutó accidentalmente la herramienta del atacante.
Probablemente pocos conceptos hay en el mundo actual de la seguridad de información que sean más importantes de entender que las dependencias de seguridad. Si empieza por el análisis de la red e intenta comprender cuáles son las dependencias, probablemente encontrará dependencias inaceptables. En el peor de los casos, que es mucho más habitual de lo que se pueda pensar, la seguridad de toda la red depende de toda la red, es decir, la seguridad de un equipo depende, en cierto modo, de la seguridad de otro equipo. Por lo tanto, es imposible crear ningún tipo de estrategia de administración de riesgos razonable y realista en ese tipo de entorno ya que no se pueden controlar las relaciones y la complejidad es inabarcable. La solución es analizar y administrar sus dependencias.
En esta columna, he presentado sólo una breve introducción a las dependencias y cómo las puede analizar y mitigar. Puede encontrar más información en mi libro Windows Server 2008 Security Resource Kit. Contiene un capítulo entero dedicado al tema de la protección de la red mediante el análisis de las dependencias y su administración con técnicas sofisticadas, como el aislamiento de servidor y dominio, y otras más triviales, como la administración de cuentas administrativas.
Me gustaría dar las gracias a David LeBlanc por ayudarme a modelar las ideas embrionarias que han dado lugar a esta columna.
Jesper M. Johansson es un arquitecto de software que trabaja en cuestiones de seguridad de software y colabora con TechNet Magazine. Tiene un doctorado en MIS y más de 20 años de experiencia en el ámbito de la seguridad.
© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.