Como todos sabéis o no... los ataques pass the hash se basan en la utilización de credenciales "ajenas" en servicios que requiere autenticación mediante el hash de la contraseña. Esto que quiere decir? En determinados escenarios es posible obtener el hash de un usuario, que no deja de ser una representación matemática, y anteriormente conocida como "única" ( no hay dos elementos distintos con el mismo hash, algo que ha quedado sobradamente comprobado en varios algoritmos, léase MD5, SHA1 etc.) pero por su complejidad puede que sea inviable "descifrar" la clave en claro. En un formulario de login, como pueda ser el inicio de un sistema operativo, no podemos copiar el hash en el apartado de la clave. Sin embargo, hay servicios de red, como el utilizado para
compartir carpetas en sistemas Win, que si aceptan la "clave" con el formato hash. Otras soluciones intermedias, como el caso de los sistemas Single Sing On ( Un programa que enlaza nuestra clave de facebook, de twitter, de windows, del correo,etc bajo un solo elemento de autenticación, como puede ser una clave, un elemento biométrico, etc) son susceptibles de ser empleadas maliciosamente con el hash de un usuario. La utilización de herramientas de terceros, como PSEXEC.exe integradas en el framework Metasploit también facilitan el trabajo xD.
Es importante mitigar el daño que podría hacer en nuestras organizaciones el uso incorrecto por parte de un atacante de los preciados HASHES del sistema.
Como sabéis, las principales vías de obtención de Hashes de cuentas en sistemas win son la obtención de credenciales en "cache" por los procesos del sistema (Local Security Authority Subsystem LSAS), el famoso fichero SAM y NTDS.DIT. La diferencia de estos dos ficheros es que en el caso de SAM se almacenan las claves en Hash de los usuarios locales, mientras que en NTDS se almacenan
las credenciales de los usuarios del Directorio Activo.
Una medida de protección lógica es implementar una política de contraseñas para usuarios locales. Es decir, que si tenemos nuestra empresa montada con una infraestrucutra de Active Directory, debemos fortificar el acceso local, a la LSD (Local Security Database). En un principio con esta medida implantamos una capa de protección, pero debemos crear un proceso en el que la clave no sea la misma para todos los equipos locales. Crear un algoritmo-casero para la clave, usando por ejemplo el nombre del equipo sería una buena idea. De esta manera aislamos el impacto de un ataque de pass the hash, o simplemente de fuerza bruta en un pc, y no sobre la "granja" de cacharros.
Microsoft clasifica las actividades Post PtHash de dos maneras:
Movimientos laterales, en los que un sistema se ve comprometida, se obtienen las credenciales, y se accede a otro sistema usando las mismas.
Escalada de privilegios. Imaginaros el caso en el que accediendo a un pc de la red, mediante claves locales, accedemos a un servicio de red (LSASS) de Active Directory que tiene en cache los tokens de autenticación del administrador del dominio... La medida general para este caso sería la de no utilizar cuentas privilegiadas del dominio para "arreglar el pc" del señor de marketing...
Mas medidas a tomar en cuenta, generales para cualquier proceso de hardening, y para este en concreto son.
No instalar/correr servicios con cuentas privilegiadas. Por ejemplo, cuando instalamos un programa que se arranca como servicio, sea cual sea, se ejecuta con los privilegios del usuario. Imaginaros un programa cual sea dentro de la empresa, un programa de inventario !!! Si ejecutamos el servicio como usuario SYSTEM, y encontramos una vulnerabilidad en el programa, por ejemplo, que
podemos acceder a una ventana de consola, todo lo ejecutado en esa consola tendrá permisos SYSTEM. Crear un usuario "servic_inventario" para arrancar el servicio, y aplicar los permisos NTFS concretos a la carpeta que necesita el programa, y nada más, solucionaría en parte el problema.
Lo mismo ocurre con las tareas programadas. Esa tarea que habilitamos en el pc del usuario, por ejemplo un backup, en la que introducimos un usuario potente. Imaginaros el hipotético caso de que se presenta un error, y se le devuelve al usuario una ventana del sistema...
En los casos de controladores de dominios, en la instalación de A.Driectory se nos muestra la ruta por defecto de la base de datos de credenciales, pudiendo moverla a una ubicación "escondida" pero esta técnica mas que una solución, es una medida de incordio para el atacante ( quien no sabe buscar un fichero...).
Otra medida interesante podría ser la utilización de un proxy, integrado con el servicio de directorio, para denegar la navegación a todos los usuarios con permisos administrativos del dominio. Squid Proxy nos permite dicha integración sin problemas.
Usar todas las opciones de administración remota que nos aportan los sistemas operativos "modernos" como son win7,8, 2008r2 y 2012 como son WMI que emplean Kerberos como mecanismo de autenticación, sin dejar en cache la clave. Por ejemplo, remote desktop, mmc remota,powershell RM, registro remoto, iis "integrated windows authenticatión" no almacenará en
disco ninguna credencial, pero si en LSASS.exe
Reiniciar los sistemas !!!. He visto servidores Windows, de los que hay que reiniciar los segundos martes de cada mes por las Updates, con un uptime de 2 años... Pero encima, los sysadmin orgullosos de ello !!! panda de... No es ningún delito reinicar un servidor en horas de baja productividad. Para que? pues simplemente para evitar ataques persistentes, en los que el atacante consigue entrar al sistema, pero no consigue habilitar un acceso posterior al reinicio del server. Parece una tontería, pero te puedes quitar varios problemas con una politica de reinicio del servidor.
Deshabilitar el acceso remoto para claves locales del equipo. Si bien esto se efectúa por defecto, revisar esta configuración para no descubrir sorpresas.
Una medida para evitar movimientos laterales es usar las reglas del firewall entre los equipos. Si en teoría tenemos una infraestructura en la que todo se comparte mediante el servidor, no necesitamos comunicación entre los equipos. Por cierto, en win8 y 2012 ya se puede bloquear el tráfico out saliente xD.
Evitar entrar en ciertos pc conflictivos. Imaginaros el caso de un pc aislado de la red, una dmz de pc cliente. Por ejemplo en mi anterior empresa se usaba un pc así con una impresora conectada, para los profesionales externos a la organización que querían acceder a un correo en un sitio no autorizado ( hotmail, gmail, yahoo...) o simplemente conectar un usb. No uses el mismo juego de claves que usas para proteger el sistema de la empresa... Esto es válido para sistemas SCADA, máquinas "antiguas" sin posibilidad de hardening, en fin, ya sabéis de lo que hablo ( creeis que no hay máquinas por el mundo con windows 98?).
Deshabilitar la politica de grupo para los LM Hashes. Esta opción está marcada por defecto a partir de windows 2008 creo recordar, pero en casos en los que se realizó una actualización de un sistema previo 2003, puede que no esté operativa dicha política de grupo.Lo mismo para NTLM, en el caso de no contar con ninguna máquina "antigua" que hago uso de este sistema. Microsoft enfatiza
el uso de tecnologías basadas en tickets Kerberos, aunque estos también se pueden "usar maliciosamente" (Pass the Ticket attack). La manera mas sencilla de realizar esto, al menos para las cuentas sensibles es habilitar la opción " Account is sensitive and cannot be delegated".
Espero que os haya servido un poco este artículo para concienciar en la necesidad de "trabajar" los servidores y recursos de la empresa, y marcaros un punto de inicio en esta labor.
Si queréis profundizar un poco más en los aspectos nombrados en el post, os aconsejo varios recursos. En español teneis el magnifico libro de Sergio de los Santos publicado por Informática 64.
En ingles podéis leer este recurso.
Como siempre, gracias por leerme.