Seguridad

Descripción de la administración de contraseñas de cuentas compartidas

Chris Stoneff

De un vistazo:

• Riesgos en contraseñas de cuentas compartidas y con privilegios
• Cómo se almacenan las contraseñas
• Administración y protección de las contraseñas compartidas
• Cumplimiento

Contenido

Descripción del problema
Cuanto más larga, mejor
Violencia del dominio
Excusas, excusas y más excusas
Lo que quieren los entes reguladores
Un método automatizado
Piénselo

Uno de los problemas más comunes que deben enfrentar los administradores con una frecuencia cada vez mayor es el cambio periódico de la contraseña de cuentas compartidas y con privilegios, por ejemplo las cuentas predefinidas

Administrador o root, una cuenta firecall, o incluso una cuenta de proceso. Por definición, la cuenta predefinida Administrador o root es la cuenta provista en cada versión de Windows®, Linux y Unix, y siempre tiene el mismo identificador de seguridad (SID) o identificador de usuario (UID). Las cuentas firecall son aquellas otras cuentas que se crean para facilitar el acceso de emergencia a un sistema seguro. Algunas veces, los usuarios sin privilegios usan estas cuentas firecall o del administrador para obtener acceso a sistemas clave cuando surgen problemas. Por último, las cuentas de procesos son cuentas que se usan para ejecutar servicios, tareas, aplicaciones COM+ y elementos incrustados, tales como scripts y otros archivos binarios que deben iniciar sesión.

Ahora, quizás implementa los sistemas mediante scripts o imágenes de instalación. Además, probablemente todas las estaciones de trabajo o los servidores tienen el mismo nombre de cuenta de administrador y la misma contraseña de ocho caracteres, y lo más probable es que no se haya cambiado desde que los sistemas se implementaron originalmente. Por este motivo, uso el término en singular "contraseña" en contraposición con "contraseñas".

Tal vez un administrador se vea obligado a cambiar estas contraseñas para seguir recomendaciones o para cumplir disposiciones legales tales como las que exigen Sarbanes-Oxley (SOX), el Payment Card Industry (PCI) o la Ley de transferencia y responsabilidad de seguros de salud (HIPAA). A veces un administrador se siente motivado cuando un antiguo administrador o técnico con conocimiento de estas contraseñas abandona la compañía, por el temor a que se publique alguna infracción de seguridad o se pierda la capacidad de procesar tarjetas de crédito. A pesar de estos factores, en realidad todo se reduce a que el administrador tiene que cambiar esas contraseñas sencillamente por la propia seguridad de la compañía y de los datos que la compañía necesita proteger.

Descripción del problema

Hay una serie de factores que deben entenderse cuando se trabaja con estas cuentas y sus contraseñas.

1. Las contraseñas, cuanto más antiguas, menos seguras.
2. Como regla general, las contraseñas más largas son más difíciles de descifrar.
3. El modo en que se autentican los equipos no cambia simplemente porque pertenezcan a un dominio. En cada dominio reside el centro de un grupo de trabajo.

"Las contraseñas, cuanto más antiguas, menos seguras" es una afirmación engañosa. Lo que en realidad significa es que dada la voluntad de forzar un equipo, todo lo que se necesita es tiempo. Si alguien me pregunta, "¿cuánto tiempo lleva descifrar una contraseña?" Generalmente digo que no hay una respuesta definitiva y, en su lugar, pido que se me ofrezcan algunas pistas que ayuden a determinar la respuesta para un sistema dado:

• ¿Cuántas personas conocen la contraseña?
• ¿Todas esas personas todavía trabajan para la compañía?
• Si algunas de las personas que conocen la contraseña de la cuenta ya no trabajan para la compañía, ¿dejaron el trabajo en buenos términos?
• ¿Se deniega el acceso para iniciarse desde disquete, unidades de CD, unidades de DVD o desde la red?
• ¿Los usuarios de los equipos son también administradores locales?
• ¿Todos los sistemas usan exactamente la misma contraseña para sus cuentas con privilegios?

Comenzando por el principio de esta lista, se puede decir que cuantas más personas conozcan un secreto, mayor probabilidades habrá de que el secreto se vuelva de dominio público. Recuerdo que en algunas compañías donde trabajé los administradores creían que era más práctico establecer un mismo valor para la contraseña compartida y revelar las contraseñas al personal de TI y a los internos que escribir las contraseñas para ellos cuando fuera necesario. Por supuesto, con el transcurso del tiempo, la compañía comenzó a encontrar equipos con diversas configuraciones no autorizadas y usuarios de red habituales que podían iniciar sesión con estas cuentas.

Si todas esas personas que conocen las contraseñas siguen trabajando para la compañía o bien son empleados felices y cumplidos, este riesgo de acceso se atenúa un poco. Pero nunca se sabe cuándo habrá que enfrentarse a un usuario malintencionado. Si alguno de esos usuarios dejó la compañía en malos términos, tendrá un elemento libre y hostil que conoce cómo forzar su red mediante una cuenta imposible de rastrear.

Si no deniega el acceso para iniciar el sistema desde ningún otro dispositivo que no sea el disco duro, también permitirá que los usuarios arranquen el sistema mediante imágenes no autorizadas, tales como Windows PE o diversos sistemas Linux que pueden leer directamente del sistema de archivos del equipo y obtener acceso al almacenamiento protegido del equipo. (Cabe resaltar que muchas de las infracciones no ocurren a causa de factores internos. Incluso si todos los empleados e internos todavía trabajan para la compañía, de ninguna manera esto es una garantía de que las contraseñas y los sistemas sean seguros.)

Conozco muchas personas que han seguido iniciando sesión en la red de un empleador anterior, por la sencilla razón de que podían hacerlo. No es gracioso que simplemente pongan de manifiesto la mala costumbre de no cambiar las contraseñas del sistema, sino que además es aterrador considerar el daño que podrían hacer si tuvieran malas intenciones.

Si habilita la opción de iniciar desde un DVD o la red, entonces no podrá auditar qué personas lo hacen. Es decir, un disco de inicio de Linux o una imagen de red a menudo pueden obtener acceso directo al sistema de archivos. Si los sistemas usan el mismo nombre de usuario y la misma contraseña para las cuentas con privilegios, entonces habrá configurado sus sistemas para una desastre de mayor alcance. No obstante, más adelante se ofrece más información sobre estos elementos.

La vigencia y longitud de la contraseña son relevantes según el método que se use para descodificar una contraseña. Si trabaja con un método de fuerza bruta para determinar las contraseñas, contra lo que en realidad tiene que luchar es contra el tiempo. Cuanto menor sea la frecuencia con la que se cambia una contraseña, más tiempo necesitará el cracker para obtenerla.

Del mismo modo, las contraseñas más largas tienen más variaciones de caracteres de modo exponencial y, por lo tanto, se necesita más tiempo para descifrarlas. Así que es importante considerar si la longitud de las contraseñas es menor de 7 caracteres, de 8 a 14 caracteres o de 15 o más caracteres. Y si la longitud de las contraseñas es menor de 15 caracteres y usa Windows, ¿los hash de LAN Manager (LM) están deshabilitados como parte de la configuración del sistema o por la directiva de grupo?

¿De qué modo afecta la longitud de la contraseña? En el caso de Windows, la respuesta es sencilla. Si omitimos el historial de los procesos hash de Microsoft, Microsoft implementa dos tipos de hash para contraseñas, los hash de LM y los hash de MD4 (Message Digest 4). De forma predeterminada, Microsoft usa los hash de LM y se almacenan los valores de todas las contraseñas de hasta 14 caracteres, a menos que el almacenamiento de los hash se desactive explícitamente. Estas contraseñas se dividen en dos valores de 7 caracteres, el primer valor se destina a los primeros 7 caracteres y el segundo a los últimos 7 caracteres, tal como se muestra en la figura 1.

Figura 1 Tabla hash de ejemplo

De esta manera, si la longitud de la contraseña fuera de sólo 7 caracteres, estaría contenida en un solo hash de LM. Desde hace años Microsoft recomienda usar por lo menos 8 caracteres en las contraseñas. El motivo para esto era que el octavo carácter exigiría que la contraseña se divida en dos valores hash de LM.

Sin embargo, es importante tener en cuenta que los hash de LM son ampliamente comprendidos y muy fáciles de esquivar. En las soluciones actuales, su único propósito es mantener la compatibilidad con versiones anteriores con sistemas de nivel inferior, tales como Windows NT® 4.0.

En la actualidad, debería usar contraseñas (en realidad, frases de contraseña) de una longitud de 15 caracteres como mínimo o preferentemente más largas porque, por definición, no generarán un hash de LM. Si exigir el uso de contraseñas de 15 caracteres no es una opción viable en el entorno, deberá deshabilitar el almacenamiento de los hash de LM en el proceso de creación de imagen (mediante directiva local) y en la directiva de grupo de Active Directory®.

Esta directiva se puede encontrar en Configuración del equipo\Configuración de Windows\Configuración de seguridad\Directivas locales\Opciones de seguridad. Simplemente establezca la directiva "Seguridad de red: no almacenar valor de hash de LAN Manager en el próximo cambio de contraseña" en HABILITADO.

Es importante recordar que aunque una buena directiva impondrá el uso de letras mayúsculas y minúsculas, así como de caracteres numéricos o especiales, una directiva mejor también impondrá una longitud de 15 caracteres como mínimo.

Cuanto más larga, mejor

Un método actual empleado para forzar los equipos se denomina tablas de cadenas arco iris usa los hash de LM como vulnerabilidad. Pero las contraseñas más largas pueden anular la eficacia de las tablas de cadenas arco iris.

Me sorprende ver cuántos administradores a cargo de la seguridad hay que parecen saber muy poco (o nada) de las tablas de cadenas arco iris. Hay varias maneras de crear tablas de cadenas arco iris para tratar distintos algoritmos. Pero éstos son sólo una lista de todos los hash de LM de 0 a 14 caracteres previamente calculados.

La salvedad de las tablas de cadenas arco iris es que el atacante debe obtener los hash de LM desde el principio. Esto conduce a las preguntas anteriores acerca de cómo se puede arrancar el sistema (mediante CD o DVD) o si los usuarios son administradores locales. Por último, estos hash de LM se pueden extraer en pocos segundos mediante herramientas gratuitas, tales como pwdump. Mediante el uso de tablas de cadenas arco iris, a continuación se busca en los hash para determinar la contraseña.

Para saciar mi propia curiosidad, establecí una contraseña en una cuenta predefinida Administrador del sistema. Tenía 14 caracteres y contenía varias mayúsculas y minúsculas así como caracteres y números especiales. Después, usé tablas de cadenas arco iris que descargué de forma gratuita de Internet y pude extraer los hash de las contraseñas de todas las cuentas de mi sistema y determinar la contraseña del administrador en menos de dos minutos.

He de admitir que es estupendo observar cómo el primer hash de LM es derrotado, seguido por el segundo hash y cómo luego, al juntarlos, se obtiene la contraseña. Insisto en que si hubiera deshabilitado los hash de LM mediante la directiva que mencioné anteriormente, este vector de ataque concreto estaría gravemente limitado o totalmente bloqueado.

Violencia del dominio

Estar dentro de un dominio no soluciona el problema. Los equipos de un dominio se autentican de la misma manera. Y, como apunté antes, en cada dominio reside el centro de un grupo de trabajo. Esta sencilla afirmación no siempre es tan evidente. He tenido muchas conversaciones acerca de este asunto y con frecuencia me veo recordando a los administradores lo que se necesita para tener acceso a un equipo: un nombre de usuario y una contraseña. Y después tengo que sumergirme en un debate sobre cómo funciona Windows en un grupo de trabajo.

Si intenta tener acceso a un sistema, tendrá que proporcionar un nombre de usuario y una contraseña para el sistema remoto. Windows tratará de hacerlo automáticamente mediante un sistema de autenticación integrada. Esto significa que si obtiene acceso a otro sistema de Windows, Windows usará el nombre de usuario y la contraseña con los que se ha iniciado la sesión. De este modo, cuando intente tener acceso a otro sistema de Windows, nunca se le solicitarán el nombre de usuario y la contraseña si el sistema remoto tiene el mismo nombre de usuario y la misma contraseña.

Ese proceso también se conoce como autenticación de paso a través. El proceso funciona tanto en grupos de trabajo como entre dominios. En el peor de los casos, el sistema solicitará un nombre de usuario y una contraseña, lo que significa que simplemente habrá que volver a escribir la información de inicio de sesión.

Ahora, aunque se conecte una estación de trabajo o un servidor a un dominio, y Active Directory pase a ser el repositorio central de cuentas, todos los Administradores de cuentas de seguridad (SAM) locales o almacenes de cuentas locales de esos sistemas no desaparecerán por arte de magia. Lo único que parece suceder en esos SAM locales es que ya no están administrados ni protegidos, he ahí la raíz del problema. ¿Cuándo fue la última vez que cambió la cuenta predefinida Administrador o la cuenta root de sus sistemas? Mejor aún, descargue cualquier utilidad de generación de informes que le muestre la vigencia de contraseña de todas las cuentas y compruebe si los resultados pasarían una auditoría.

Si aún no sabe lo que quiero decir, tome cualquiera de las estaciones de trabajo del dominio e inicie sesión con una cuenta de dominio con privilegios de administrador. Abra en su sistema la Administración de equipos y cree un usuario local denominado SeLoDije. Establezca una contraseña para la cuenta y agréguela al grupo de administradores locales del sistema. Repita este proceso en un segundo sistema del dominio.

Ahora, desde cualquiera de esos sistemas, inicie sesión con la cuenta SeLoDije e intente obtener acceso al segundo equipo; para hacerlo, vaya a \\systemName\c$. ¡Podrá tener acceso al recurso compartido administrativo, y ni siquiera se le solicitó una contraseña! Espero que este ejemplo no sea algo nuevo para usted. Pero si lo es, aprenda de él y permítame insistir: el simple hecho de que un sistema pertenezca a un dominio no significa que todos estos sistemas funcionen igual que si pertenecieran a un grupo de trabajo.

Lo que intento decir es que si se usan contraseñas para cuentas compartidas y con privilegios que rara vez o quizás nunca se cambien, dichas cuentas compartidas y con privilegios estarán expuestas a un peligro. Todo lo que hará falta para poner en peligro la red entera es tiempo.

Excusas, excusas y más excusas

A menudo, cuando hablo con administradores e incluso con directores de tecnologías de información, escucho los mismos motivos por los que no se cambian las contraseñas de estas cuentas:

• Tenemos miles de sistemas y no disponemos de tiempo suficiente ni mano de obra para cambiar esas cuentas.
• No tenemos el presupuesto necesario.
• Hemos deshabilitado completamente nuestras cuentas de administrador.
• Nuestros sistemas aún no están en peligro, así que no creemos que sea un problema.
• Los auditores se dieron cuenta.

Aunque me identifico con los dos primeros motivos, éstos no son excusas válidas. Me dan escalofríos de tan solo pensar que puede haber compañías que tengan información mía almacenada y que no aborden este problema por la razón que sea.

Si bien es cierto que no todos los sistemas de red almacenan información confidencial, los usuarios de estos equipos podrían tener acceso a información confidencial, como el número de la seguridad social, historiales médicos o datos financieros. Como administrador del sistema, un usuario puede instalar registradores de pulsaciones de teclas y utilidades de captura de pantalla, detener la aplicación de directivas de grupo, introducir correcciones de compatibilidad (shim) en distintos subsistemas para capturar y transmitir datos, etc. Y cuando el usuario hace esto a nivel del equipo individual, se hace mucho más difícil identificar a ese usuario malintencionado porque se llama Administrador.

¿Sabía que después de deshabilitar la cuenta predefinida Administrador en Windows se puede seguir iniciando sesión con esa cuenta? Pruebe a hacer lo siguiente: reinicie su sistema en modo seguro e inicie sesión con la cuenta predefinida Administrador. Es posible que le permita usar la contraseña emitida para la cuenta desde la imagen original e iniciar sesión correctamente. Para obtener más información sobre este comportamiento, consulte el artículo de Microsoft® Knowledge Base "Cómo obtener acceso al equipo después de deshabilitar la cuenta de administrador" (support.microsoft.com/kb/814777).

Lo que desean los entes reguladores

Trabajar con SOX, PCI, HIPAA y otras disposiciones legales puede llegar a marear la cabeza. Comprender los requisitos puede ser una tarea complicada, ya que son extensos y no están claramente definidos. Generalmente, el objetivo que persiguen todas estas reglamentaciones se puede resumir del modo en que se hace a continuación.

En primer lugar, hay que garantizar en todo momento quién tiene acceso a todas las cuentas con privilegios y a la información, además de facilitar un método que lo pruebe. Esta es una buena práctica en todos los casos, ya que una cuenta con privilegios es una cuenta con derechos para realizar cualquier acción en cualquier sistema. Esta es la cuenta predefinida Administrador. Esta es la cuenta firecall. Estas son cuentas que quizás son conocidas por todo el personal de servicios de soporte técnico y por cada administrador con los que trabaja.

Cuando decide implementar una solución para administrar las contraseñas de cuentas compartidas, se crea una pista de auditoría que hasta ese momento no existía para la cuenta predefinida Administrador. Obtendrá una contraseña que es variable. Y como la solución es automatizada, no se perderán semanas de tiempo de productividad cambiando las contraseñas. Por último, como la solución ofrece capacidades para auditoría, la compañía estará más cerca de pasar la auditoría.

Un método automatizado

La manera más eficaz de trabajar con estas cuentas es modificarlas regularmente para que dos cuentas jamás compartan la misma contraseña. Con las contraseñas compartidas, el acceso no autorizado a un sistema podría significar un acceso no autorizado a otro. Es decir, no debe haber cuentas de dominio ni cuentas locales comunes.

Al trabajar con soluciones automatizadas que pueden administrar y generar estas contraseñas de manera aleatoria evite hacer solamente lo mínimo indispensable que requieren los auditores. Por ejemplo, ¿por qué usar sólo 8 caracteres para las contraseñas cuando puede usar 15, 20 o 127 sin ningún esfuerzo adicional (consulte la figura 2)?

Figura 2 Uso de la automatización para crear contraseñas muy largas (haga clic en la imagen para ampliarla)

Además, considere la posibilidad de generar todos los días contraseñas aleatorias para las cuentas con privilegios, como se muestra en la figura 3. No hay motivos para hacerlo solamente cada 90 días cuando puede hacerlo de manera mensual, bimestral o incluso diaria. Después de todo, si el procedimiento es automatizado, no debería suponer ningún trabajo adicional para el usuario. Además, si se ejecuta con regularidad, obligará a los usuarios a recuperar las contraseñas de la interfaz de recuperación auditada de la herramienta, lo que proporciona otra pista de auditoría que hasta ese momento no existía. (Si actualmente guarda contraseñas escritas dentro de un sobre que conserva en un lugar seguro en algún rincón perdido de una oficina, no tendrá una pista de auditoría para esas contraseñas como la que tendría si usara una solución de administración de contraseñas.)

Figura 3 Generación aleatoria diaria de cuentas con privilegios (haga clic en la imagen para ampliarla)

Por último, asegúrese de que, una vez recuperadas, las contraseñas se puedan volver a generar (y que efectivamente lo hagan) de manera aleatoria después de un tiempo fijo posterior a la recuperación. No me refiero a los trabajos de generación aleatoria programados que se hayan creado, hablo de crear contraseñas de un solo uso, que pierdan validez en cuestión de horas, no de algunos meses. Una vez más, este método obligará a los usuarios a recuperar las contraseñas de la interfaz de recuperación auditada de la herramienta, proporcionando así una pista de auditoria.

Piénselo

Es necesario abordar el problema de la administración de contraseñas de cuentas compartidas. Esto significa que debe establecer un método para cambiar las contraseñas de forma segura y periódica. La solución tiene que ser escalable y flexible. También debe ofrecer acceso protegido a las contraseñas, y necesita auditar cada acción que toma la herramienta así como cada acción que toma cada usuario de la herramienta. Además, las contraseñas generadas deben ser únicas en cada sistema para evitar accesos no autorizados a causa de información de cuentas compartida.

Son muchos los proveedores que llevan años tratando de solucionar este problema, y a estos se les han unido otros recientemente. Asegúrese de investigar bien y probar las herramientas nuevas antes de decidirse por una solución, para así garantizar que el producto por el que opta sea el más adecuado para su entorno.

Chris Stoneff es administrador de producto en Lieberman Software (liebsoft.com), un desarrollador de software de seguridad y administración de sistemas. Su mayor virtud no es sólo saber cómo funciona algo de una cierta manera, sino también saber por qué.