Durante el proceso de una revisión de seguridad, es preciso utilizar diversas herramientas que, de forma automática, ayudan notablemente a detectar vulnerabilidades e incluso errores de configuración. Es importante saber utilizar dichas herramientas así como comprender y conocer todas sus funcionalidades y el fundamento técnico que hay detrás de cada una de ellas. La mayoría de las veces, estas aplicaciones están diseñadas para un fin y usos específicos pero, aún así, presentan la flexibilidad y potencia suficientes como para permitir modificarlas y adaptarlas a las necesidades de la revisión de seguridad en cuestión.

Metasploit (http://www.metasploit.com/) es una de esas herramientas que permite modificar su código para adaptarla y conseguir el objetivo deseado y necesario en el transcurso de cualquier revisión.

A modo de ejemplo, recientemente, tras comprometer un equipo con Windows 2003, se disponía de un usuario pero que no era administrador local. En Metasploit, existen diferentes métodos para la elevación de privilegios todos ellos incluidos en "post/windows/escalate". En este escenario, el Sistema Operativo Windows 2003 estaba perfectamente actualizado y parcheado por lo que las opciones de Metasploit para las vulnerabilidades MS10-073 (kb layout), MS10-092 (scheduler) o MS10-015 (kitrap0d) no eran válidas. Incluso el script “getsystem” de Metasploit para elevación de privilegios a nivel de SYSTEM, tampoco era de mucha utilidad.

Era necesario escalar privilegios para obtener una cuenta de administrador o como mínimo con privilegios de Sistema (NT AUTHORITY\SYSTEM) y así poder acceder al fichero de contraseñas de Windows (SAM) o poder ejecutar determinados comandos en el sistema para obtener toda la información del mismo. Como se ha comentado anteriormente, se dispone de una sesión "Meterpreter" abierta corriendo con un usuario regular con privilegios limitados.

Otros vectores de ataque podrían ser:

- Buscar archivos en texto o de configuración que puedan contener passwords.
- Buscar por el registro de Windows para obtener contraseñas en claro.
- Realizar una evaluación del control de acceso a ficheros como System32 o archivos de inicialización.
- Revisar la configuración de los servicios.

Con la herramienta windows-privesc-check2 (http://pentestmonkey.net/tools/windows-privesc-check) se obtuvieron servicios que sí podían ser controlados con el usuario obtenido. Metasploit también incluye la opción de analizar los servicios existentes en el servidor para encontrar aquellos que permitan al usuario controlar el servicio y ejecutarlo con los permisos con los que se configuraron originalmente, posiblemente SYSTEM.

Según Metasploit, el servicio fue reconfigurado de forma satisfactoria y una sesión de "Meterpreter" para reverse shell debería conectarse a nuestro listener local en el puerto 444 (que es el que se ha configurado). Para complicar aún más esta revisión de seguridad, entre el equipo con Metasploit y la máquina atacada con Windows 2003 existía un firewall que no permitía "conexiones en modo reverse". Una posible solución era modificar el payload usado por el módulo de Metasploit para ver de qué forma se establece la sesión remota.

Revisando las opciones del módulo, se observa que no se hace referencia a la configuración del payload en la implementación de Meterpreter reverse shell. Una de las principales ventajas de Metasploit es que se puede leer el código de los diferentes módulos y scripts fácilmente y, por extensión, modificarlo y cambiarlo para cumplir con un determinado objetivo.

El fichero que controla los módulos de elevación de privilegios para Windows en Metasploit se encuentra en "/msf3/modules/post/windows/escalate/service_permissions" donde es el directorio donde se encuentre instalado Metasploit.

Tras revisar el código fuente, se encontró que el payload estaba controlado por la siguiente línea:

Substituyendo este payload por el Meterpreter bind shell permitiría cambiar el comportamiento y obtener el objetivo deseado, una sesión remota que no fuera “reverse shell” y que no bloqueara el firewall:

También se deshabilitó la creación del listener comentando las líneas que hacen referencia y se utilizó el comando msfcli para la creación del bind handler.

Las líneas comentadas son:

Para no alterar el módulo original, se creó una copia que fue la que se modificó. Sin realizar ninguna modificación a Metasploit y para que pueda reconocer el nuevo módulo modificado es necesario reiniciar la consola de Metasploit. Una vez reiniciada “msfconsole” se puede ejecutar el nuevo módulo que en este caso se llamó “service_permissions_bind”.

Una vez lanzado el nuevo módulo modificado ya es posible ejecutar el otro módulo "bind handler" para conectar a la shell cuando el servicio sea reiniciado y así obtener privilegios de SYSTEM que era lo que se necesitaba originalmente y que, antes de modificar Metasploit, no se podía:

En definitiva, las herramientas deben servir como punto de partida y son de gran ayuda pero es fundamental comprender su funcionamiento. No se ha comentado cómo el modulo realiza la escalada de privilegios aunque el código que ofrece Metasploit ayuda a entender el proceso. La modificación del modulo quizás no es la más óptima pero cumple el objetivo y con las necesidades surgidas durante esta revisión de seguridad.

El siguiente paso es modificar el módulo original para permitir la elección del tipo de payload y enviarlo a Metasploit para que evalúen si los cambios merecen ser añadidos a la versión actual. Cabe destacar también que todo el proceso se puede realizar de forma manual aunque por eficiencia es recomendable acudir a este tipo de técnicas con herramientas automáticas que ahorran tiempo a pesar de que conlleven algún que otro inconveniente.