Sin duda, uno de los descubrimientos de más trascendencia de este año fue la publicación primero por parte de
PentestMonkey y posteriormente por
PaulDotCom de la existencia de una herramienta llamada
Mimikatz mediante la cual era posible obtener las contraseñas en texto claro de los usuarios de Windows directamente desde la memoria, y de la que ya hablé en este mismo blog
AQUÍ.
Desde que apareció esta nueva técnica, tanto yo como cualquier Pentester, la hemos usado ampliamente durante nuestras auditorías, ya que conocer la contraseña en texto claro nos da la oportunidad de usarla en sistemas o aplicaciones no-Microsoft, algo que con otras técnica como el Pass-the-Hash o el Pass-the-Token no sucede. Esto ha llevado a dos cosas, la primera es una gran sorpresa por parte de los clientes cuando ven en el informe de auditoría que se pueden recuperar las contraseñas en texto claro, con una conversación que suele ser algo así:
Pentester: ... Y entonces volcamos esta contraseña en texto claro y la utilizamos para entrar en la aplicación XXX y...
Cliente: Espera, espera, espera ¿Windows se guarda mi contraseña en texto plano en la memoria?
Pentester: Sí, exactamente.
Cliente: Uffff.... ¡Menuda cagada!
Pues sí, menuda cagada... pero a continuación viene la pregunta obligada:
Cliente: Y qué hacemos?
Esta es una pregunta que me han hecho en numerosas ocasiones ya, tanto clientes como amigos del mundo de la seguridad, ya que esto, como ocurre con el Pass-the-Hash, se considera una feature y no un bug, así que en principio Microsoft no va a sacar ningún tipo de parche de seguridad que lo corrija.
Ya que parece que vamos a tener que vivir con ello mucho tiempo, vamos a ver algunas aproximaciones que nos pueden ayudar a luchar contra esta técnica:
Deshabilitar los Security Packages
Sabemos que la causa de que Windows se guarda nuestras credenciales en texto plano (en realidad, con un cifrado reversible, pero a efectos prácticos da igual) es que la emplea para algunos servicios de SSO a través de los llamados Security Packages:
 |
| Imagen "prestada" del artículo que escribió mi compañero Ramón Pinuaga en el blog de S21sec |
Estos Security Packages pueden ser desactivados editando el registro HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages, por lo que la mejor opción para protegernos de esta técnica sería deshabilitarlos todos. No obstante, yo no soy sysadmin ni security admin y no tengo acceso a una red REAL en la que probar si esta solución puede ocasionar problemas de funcionamiento, por lo que recomiendo aplicarlo con cautela y con las pruebas previas adecuadas.
Como esto no va a ser siempre posible, y además no tenemos la certeza de que solo almacenen las contraseñas estos módulos, vamos a ver algunas otras mitigaciones.
Borrarlo de la Memoria
Una opción "para valientes" es, igual que estas herramientas se van a la memoria y recuperan la información, modificar el código fuente para que la sobreescriban. En el caso de WCE tendríamos que hacer Ingeniería Inversa de la herramienta, pero en el caso de Mimikatz, su código fuente está disponible
AQUÍ, así que
podemos cogerlo e intentar hacer nuestra propia versión que lo que haga sea sobreescribir las credenciales encontradas. Os adelanto que el código de donde se obtiene la información está en el directorio "sekurlsa/Security Packages":
Los offsets de donde está la información están referenciados dentro de la función "searchWDigestEntryList", según he podido ver. Esta es una solución que no me he metido a fondo a probar, ya que me parece aún más arriesgada que la primera, por aquello de sobreescribir repetidamente la memoria de un sistema en producción, además de que solo nos protege de que se obtengan las credenciales de aquellos lugares en los que se conoce que están, pero no tenemos la certeza de que existan en más sitios. En cualquier caso, es una alternativa que se podría estudiar más en profundidad si fuera necesario, a ver si tiene repercusiones de estabilidad en las máquinas o no, y si tiene ventajas con respecto a la primera.
Reiniciar los Equipos de Usuario
Uno de los sitios donde no merece mucho la pena centrar esfuerzos en mitigar estas técnicas es en los equipos de usuario ¿por qué? Porque generalmente en los equipos de usuario... suele haber usuarios, y los usuarios tienen la fea costumbre de teclear sus contraseñas, con lo que al final vamos a poder obtener su contraseña en texto claro de todos modos. La única diferencia va a ser que con Mimikatz/WCE las obtendremos directamente, y si no podemos usar esta técnica tendremos que "motivar" al usuario a que la vuelva a teclear, cerrándole la sesión o poniéndole delante una ventana que parezca un bloqueo de sesión para que introduzca su contraseña, pero al final la contraseña se obtendrá.
El único peligro extra con los equipos de usuario es que obtengamos más credenciales además de la del usuario que lo está utilizando, por ejemplo un administrador que conectó para tareas de mantenimiento. Por esto es recomendable que el administrador, después de realizar sus tareas de mantenimiento, no cierre sesión y deje que el usuario continue trabajando, sino que realice un reinicio del equipo. No estaría de más tampoco que los equipos de usuario tuvieran programado un reinicio periódico nocturno, que por otra parte es necesario para que se apliquen los parches de seguridad, así que es una medida muy recomendable.
Reiniciar los Servidores
Como comentábamos, uno de los mayores peligros de esta técnica es que las credenciales permanecen en la memoria todo el tiempo que el sistema esté sin reiniciarse. Esto puede provocar que encontremos en ella credenciales de usuarios que accedieron al sistema meses antes de producirse la intrusión:
Evidentemente, un sistema servidor no es lo mismo que un equipo de usuario, y no podemos reiniciarlo cada vez que realizamos una tarea de administración, ya que ofrece servicios al resto de la empresa que en la mayoría de los casos no se pueden detener. Aún así, planificar reinicios periódicos (manuales o automáticos) minimizaría la cantidad de información que se puede obtener con estas técnicas. Si reiniciamos cada semana, pues solo se podrán obtener las credenciales de los usuarios que accedieron esa semana. No es una corrección definitiva pero es una manera de mitigar los efectos del uso de estas técnicas.
Usar Autenticación por Red
En entornos Microsoft, se diferencian básicamente tres clases de autenticación. La primera de ellas es el login en el terminal físico, la segunda de ellas es el login por escritorio remoto/terminal server, y la tercera es el acceso por red. Mucha gente con la que he hablado pensaba que con Mimikatz/WCE era posible obtener las credenciales de cualquier tipo de autenticación, es decir, que si comprometes un servidor de ficheros automáticamente obtienes las credenciales de todos los usuarios que tienen montadas carpetas de red. Esto no es así en absoluto.
Si pensamos de una manera más abstracta... para que estas herramientas puedan extraer mi contraseña en claro, tiene que haber estado en algún momento en la memoria del sistema ¿cierto? ¿Y en cuales de estos mecanismos lo hacemos? En el caso del acceso físico está claro que sí, y en el caso del acceso por escritorio remoto también, porque lo que se nos muestra es una ventana de login que es ofrecida por el sistema al que conectamos, así que pasará lo mismo.
En el caso de la autenticación a través de red, esto es radicalmente distinto. Microsoft utiliza los protocolos NTLM o Kerberos, que están basados en mecanismos de reto-respuesta. Veamos un ejemplo de como sería empleando NTLM:
 |
| http://www.defenceindepth.net/ |
Todos los mecanismos de reto-respuesta consisten, de forma básica, en que el servidor al que quieres generar te envía un número grande y aleatorio (el resto) que tu debes cifrar con algún tipo de clave precompartida. Este resultado del cifrado (la respuesta) se enviará al servidor para que este compruebe, realizando el mismo proceso, si la respuesta que a él le sale coincide con la tuya. Si es así, es porque ambos conocéis la misma clave, y por tanto te autentica. En los sistemas Microsoft, esta clave con la que realiza el cifrado no es la clave en si, sino el Hash de ella, que es lo que se almacena en los sistemas. Entonces... ¿cómo se va a poder obtener en este caso la contraseña en claro? Sencillo, NO se puede, porque esta contraseña en claro NUNCA ha sido tecleada en el servidor, por lo que "solo" podrá obtenerse el hash.
Debido a esto, todas las herramientas de administración que funcionen a través de la red no van a dejar ningún rasto en el sistema, por lo que deberemos usarlas siempre que sea posible para evitar dejar las contraseñas de administración en claro en el servidor. Esta puede ser una de las mejoras soluciones (aparte de deshabilitar los security packages), ya que podemos realizar la gran mayoría de gestiones de administración (usuarios, servicios, disco, ficheros, etc) sin necesidad de hacer login en el equipo:
 |
| El Administrator está porque es con el que hice el login físico para hacer el volcado, pero el resto no aparecen |
Cambiar las Contraseñas
Hemos estado hablando todo el rato de la aproximación de "que no me puedan capturar las contraseñas en texto claro", pero en realidad existe otra aproximación igual de buena: "que no les sirvan para nada las contraseñas que me capturen". La aproximación más "artesanal" de esta idea es cambiar la contraseña de Administrador con frecuencia, de tal forma que si dejé rastro en un sistema de la contraseña del mes pasado, este mes ya no les sirva esa contraseña. OJO, no vale el famoso truco de usar la misma palabra e ir cambiando el número final, porque es algo que sin duda va a probar un atacante. Tiene que ser una contraseña completamente diferente.
En algunos clientes a los que he tenido la oportunidad de visitar he visto sistemas que cumplen perfectamente esta función. Estos sistemas tienen control sobre una serie de usuarios que se pueden emplear para administrar los sistemas, los cuales se mantienen deshabilitados. En el momento que un administrador, a través del interface web, solicita el acceso al sistema para administrarlo, el sistema le asigna una contraseña aleatoria y se la proporciona al administrador, y habilita el usuario. Pasado el tiempo que éste ha solicitado, el usuario se deshabilita de nuevo automáticamente.
Este tipo de sistemas, aunque fueron diseñados como medio de control sobre los usuarios administradores en entornos donde existe mucho proveedor externo, proporciona una protección muy buena ante el tipo de ataques que comentamos, ya que las contraseñas robadas no van a tener ninguna utilidad.
Estas son todas las contramedidas que se me han ocurrido a mi y que he recomendado cuando me han preguntado sobre el tema, pero si tienes tu propia solución... es el momento de que dejes un comentario :)
.png "English"){kind=small}
Entradas
