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

Cómo saltarse UAC en WIndows 7 y Windows 10 aprovechándose de WinSxS

WinSxS, Windows Side-by-Side, se introdujo con Windows Server 2008 y es un almacén dónde el sistema contiene componentes de Windows que se pueden utilizar durante las instalaciones o componentes que pueden ser necesarios para la ejecución de una aplicación, por ejemplo, una librería DLL. La gente de FuzzySecurity ha estado investigando sobre un caso de abuso o explotación del mecanismo de protección UAC en Windows. Gracias a este bypass se logra ejecutar código con nivel de integridad alto, es decir, con el máximo privilegio.

Figura 1: Cómos saltarse UAC en Windows 7 & 10 usando WinSxS

Antes de desglosar el bypass vamos a comentar una serie de conceptos que debemos tener claros. Lo primero, sería entender que los procesos creados por el usuario administrador real de la máquina tienen ciertos privilegios que no tienen los procesos creados por los usuarios, aunque pertenezcan al grupo Administrador.  En el instante, en el que un usuario del grupo administrador ejecuta un proceso con “Ejecutar como Administrador” los privilegios serían elevados.

Para ejemplificar esto, en la siguiente imagen hacemos uso de la herramienta Get-TokenPrivs que se puede descargar desde Github útil para hacer Pentesting con Powershell. En la imagen, se puede ver como hay dos ejecuciones de cmd.exe abiertas, una con privilegios elevados y otra sin ellos. Como se puede ver, uno tiene 23 privilegios, incluido el de impersonalización o uso del token SYSTEM, mientas que el otro no.

Figura 2: Ejecución de cmd.exe con dos niveles de privilegios distintos

La utilización del “Ejecutar como Administrador” hace que los usuarios privilegiados puedan realizar acciones diferentes al resto de usuarios. Si evaluamos el uso del sistema operativo por parte de usuarios privilegiados y los que no, la creación de procesos no difiere tanto hasta que los privilegiados utilizan la opción “Ejecutar como Administrador”. En ese instante, el cambio de token requiere que UAC notifique o solicite contraseña, dependiendo de la configuración que haya en la política de seguridad de la máquina.

Figura 3: Opción de Autoelevate a true en el binario wusa.exe

En algunas ocasiones, y dependiendo de la configuración o ajustes de fortificación de Windows que UAC tenga, los programas del sistema se elevan automáticamente si el usuario pertenece al grupo administrador. Estos binarios se pueden identificar observando el manifiesto. Si encontramos la opción AutoElevate con valor igual a Tue, significa que no hay necesidad de pedir la elevación de privilegios, ya que el binario está firmado por Microsoft y debido a esto y a que el usuario es administrador se llevará a cabo la elevación sin solicitar la confirmación.

Figura 4: Opción de Autoelevación solo está disponible en modo "Windows 7"

Esto puede verse como una debilidad, la cual Microsoft configuró para mejorar la usabilidad y las críticas sufridas con UAC en su día al lanzarlo en Windows Vista, y por eso solo está presente de Windows 7 en adelante.

¿Dónde encontraron el fallo?

Analizando diversas aplicaciones firmadas por Microsoft, como es el caso de msra.exe o tcmsetup.exe, se encontraron una operación que realizaba el binario sobre el sistema de archivos en el que se obtenía un resultado NAME NOT FOUND.

Como se puede ver en la imagen, cuando se ejecuta la aplicación tcmsetup.exe se realiza una búsqueda en un directorio que no existe. Analizando las líneas posteriores se ve que se realiza la búsqueda por una DLL, la cual es encontrada en el contenedor WinSxS. De aquí se puede entender que si se lograse crear una DLL maliciosa en la carpeta \Windows\System32\tcmsetup.exe.Local se podría ejecutar dicha DLL y ejecutar código en un nivel de integridad alto, es decir, como Administrator. El binario está firmado por Microsoft, por lo que no hay solicitud de UAC.

Figura 5: Excepción de NAME NOT FOUND

En este punto, está claro que \Windows\System32 es un directorio dónde no se podrá crear dicha carpeta y copiar la DLL maliciosa al directorio. En este punto, se pensó en la auto elevación de los objetos COM. Uno de los objetos COM es muy útil en este caso y es IFileOperation. Este objeto contiene métodos que permiten copiar, mover, eliminar objetos del sistema de archivos como ficheros y carpetas.

El plan es el siguiente: el atacante escriba un DLL que instancia el objeto COM de IFileOperation y ejecuta un método que mueva los archivos al directorio \Windows\System32 o directorio protegido. Para la obtención del objeto COM auto elevado, la DLL se inyecta en un proceso de integridad medio, el cual se ejecuta en un directorio de confianza, posiblemente “explorer.exe”. Se puede encontrar más información en este artículo, realmente interesante.

Hay otra vía, un poco más flexible o sencilla de manejar ésta operativa y es a través de Powershell. Los objetos COM dependen de PSAPI para identificar en qué proceso se están ejecutando. PSAPI analiza el PEB, Process Environment Block, para obtener la información, por lo que un atacante podría sobrescribir el PEB para engañar a PSAPI. Esto se realiza a través de la herramienta Masquerade-PEB en Powershell.

PoC: Bypass UAC con Objetos COM y evitando a WinSxS

Como se vio anteriormente, el problema radica en que la DLL que se intenta cargar está en un directorio que no existe en \Windows\System32, lo cual concatenado con la autoelevación de los objetos COM puede permitirnos lograr mover una DLL maliciosa en dicha carpeta. En el momento de la ejecución de la aplicación legítima, la carpeta y DLL que no eran encontradas, se encontrarán y se ejecutarán, consiguiendo ejecutar código con integridad alta.

Figura 6: Ejecución de bypass UAC con WinSxS con script de FuzzySecurity

Para simplificar esto, los investigadores de FuzzySecurity han hecho un script en Powershell, el cual reúne todo lo necesario para llevar a cabo el bypass de UAC. En la siguiente imagen, se puede ver la ejecución del script y el resultado es una consola de Powershell dónde podemos escribir por ejemplo en la ruta \, lo cual nos indica que ese nuevo proceso se está ejecutando con integridad alta, es decir, como administrador.

¿Dónde poder aprovechar esto?

En las auditorías internas dónde se tenga acceso a una máquina remota y se requiera una elevación de privilegios podemos utilizar éste bypass UAC para lograr un proceso privilegiado, siempre y cuando se cumplan los requisitos. En el siguiente vídeo tienes la demo en funcionamiento.

Figura 7: Bypass de UAC usando WinSxS en Windows 7

Interesante forma de hacer bypass UAC en sistemas Windows desde 7 a 10. Hay que tener en cuenta que existen muchos binarios firmados por Windows y que pueden ser vulnerables a este tipo de técnica, por lo que como siempre os animamos a que echéis un ojo. Os recomiendo que leáis el libro de nuestro compañero y amigo Sergio de los Santos (@ssantosv) para tener Máxima Seguridad en Windows, donde se trata ampliamente este tema desde el punto de vista de la fortificación del sistema.


Figura 8: Bypass de UAC usando WinSxS en Windows 10

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

Te van a hackear por IPv6 por pensar que no lo utilizas

Se acabó la Gira Up To Secure 2013 y tras impartir 10 conferencias de hacking en IPv6 me sigue fascinando que la mayoría de la gente piensa que no usa nunca IPv6. Puede que incluso tú pienses que no usas nunca IPv6, y lo cierto es que en todos los equipos Windows Vista, Windows 7, Windows 8, Windows Server 2008, Windows Server 2008 R2 y Windows Server 2012 viene configurado por defecto.

Para demostrarle a la gente que su Windows utiliza IPv6 por defecto, y que según la configuración por defecto tiene prioridad sobre IPv4, les hago una demo muy sencilla, pero que a muchos sorprende - y que deberías hacerla por ti mismo si aún no has tomado conciencia del riesgo -  paso a paso: La "peligrosa" demo del ipconfig + ping.

Paso 1: Primero hacemos un ipconfig en un Windows, para que se vea que existe la dirección IPv6 de vínculo local. Si te sale esa dirección, entonces continúa con el paso 2 que de momento vamos bien.

Figura 1: ipconfig en un Windows con configuración por defecto. Hay local-link IPv6.

Paso 2: Desde un equipo de tu red haz un ping -a a una dirección de algún equipo de tu red que esté en el mismo segmento físico. Es importante esto, porque por defecto IPv6 no viene configurado con default gateway - eso ya lo haremos a posteriori con un DHCPv6 o un paquete RA para hackear toda la red, pero de momento basta con que esté en tu mismo segmento.

Figura 2: ping -a a una dirección IP del mismo segmento de red

Paso 3: Una vez hecho eso, haz un ping al nombre NetBIOS del equipo que te ha salido. No lo hagas al FQDN por si solo tienes un DNS en la red IPv4. Esto hará que el protocolo LLMNR busque por toda la red todas las direcciones IPv4 e IPv6 asociadas a este nombre, buscando los registros A y AAA usando los DNS en IPv4 e IPv6 - los dos tipos de registros en los dos servidores - y la difusión broadcast. Si todo ha ido bien, te habrá contestado el equipo, pero desde la dirección IPv6.

Figura 3: Ping al nombre del servidor utiliza IPv6

Si esto te ha dado positivo - que te dará - entonces estás vendido a un ataque de Neighbor Spoofing en IPv6 que podrá ser utilizado para robar ficheros SMB y no servirá de nada que monitorices la tabla ARP con arp -a, ya que todo el ataque tiene efecto en la lista de vecinos que puedes ver con netsh interface ipv6 show nei.

Figura 4: Tabla de vecinos IPv6

A partir de ese punto, tu red está preparada para sufrir un ataque de los gordos en los que el atacante use Rogue DHCPv6, SLAAC y DNS Autodiscovery para ownearte toda la infraestructura. Pero eso...ya os lo cuento en la próxima RootedCON.

Mientras tanto, haz un route print y comprueba que no existe ningún gateway en eso que tienes ahí abajo, la tabla de enrutamiento IPv6 de tu red. La puerta de enlace, como ya os conté en los conceptos básicos de IPv6, se denota con la dirección ::0.

Figura 5: Tabla de enrutamiento en IPv6 sin puerta de enlace por defecto configurada

Si he conseguido que prestes atención a "tu" IPv6, tal vez deberías leer algo más y repasar estos artículos, para que conozcas más de lo que se te puede venir encima.

Saludos Malignos!

***************************************************************************************************
- Hacking en redes de datos IPv6: Conceptos básicos IPv6 (1)
- Hacking en redes de datos IPv6: Conceptos básicos IPv6 (2)
- Hacking en redes de datos IPv6: Te hackearán por IPv6 por creer que no lo usas
- Hacking en redes de datos IPv6: Neighbor Spoofing
- Hacking en redes de datos IPv6: Captura de SMB con Neighbor Spoofing
- Hacking en redes de datos IPv6: FC00::1 (Algunos) Ataques en redes de datos
- Hacking en redes de datos IPv6: Man in the middle en redes IPv4 usando IPv6
- Hacking en redes de datos IPv6: Desactivar IPv6 para evitar D.O.S. SLAAC
- Hacking en redes de datos IPv6: Topera - Scanner de puertos sobre IPv6
- Hacking en redes de datos IPv6: Predecir direcciones IPv6 Local-Link de OS X
- Hacking en redes de datos IPv6: Ataques en redes de datos IPv 4 e IPv6 ***************************************************************************************************

From Sticky Keys to PowerShell in Windows Server 2008

Cuando un servidor con Citrix o RDP permite el truco de las Sticky Keys, suelo usar siempre los mismos caminos. Cuando es un Windows Server 2000 o Windows Server 2003, siempre uso el truco de llamar a la ayuda para hacer clic con el botón derecho sobre tooltip informativo y llegar al panel de impresión.

Figura 1: Hacker el jailbreak desde las Sticky Keys de un Windows Server 2003

En Windows Server 2008 y Windows Server 2008 R2 solía utilizar un camino distinto, pidiendo c:\ desde la ventana del panel de control, pero después de pegarme con varios, creo que el camino más corto es pedir Powerhell.exe desde la barra y listo, que de hecho no suele estar bloqueado en ninguno de los que he probado.

Figura 2: Ejecutar PowerShell.exe desde las Sticky Keys en Windows Server 2008

Es un camino rápido, directo, y que no suele estar bloqueado en ningún servidor, así que acuérdate de él.

Saludos Malignos!

Too many consoles, too many (power) shells

Han pasado ya un año y medio desde que el gran Silverhack y yo nos diéramos un paseo por la Defcon 19 para dar la charla de Bosses Love Excel, Hackers Too. Esa charla fue una en la que más hemos trabajado para acabar de montarla, y lo cierto es que los días que pasamos encerrados discutiendo y peleándonos con todo, al final merecieron la pena para nosotros, y cuando lo recordamos con una cerve, Juanito y yo estamos satisfechos de aquello.

Desde entonces, sistematicamente he ido notando una reducción constante del número del ficheros .ica disponibles en Internet en los que se pueden probar muchos de los trucos que os he ido dejando publicados por aquí, para hacer mil cosas para hacer jailbreak, jugar con las cadenas de conexión e incluso algún que otro truco de magia.

Ayer, después de "torturar" un poco a mis alumnos del Master de Seguridad de la UEM con el SQL Injection - y tras echarme una más que merecida siesta - me levanté con ganas de echar uno de esos vistazos que le pego a ver cómo va "el mundo de los .ica" en los buscadores.

Por supuesto, sacando un poco de partido a ser uno de los pocos que hace cuando hace hacking con buscadores lo hace con Bing Hacking, disfruto todavía de un amplio vergel de ficheros disponibles en la red, en los que se pueden probar todos los trucos y técnicas que os he ido contando... y alguna cosa nueva.

Recordando la charla que impartimos, hubo una parte en la que hablamos de "Too many consoles", en la que veníamos a decir eso de que si te bloquean el cmd.exe, siempre puedes usar el WMI, la PowerShell o usar el truco de Didier Stevens y calzar la consolar de ReactOS en un Excel - ¡Excel Rulz! -. 

Os cuento todo esto porque ayer mismo, como os decía, me volví a dar cuenta de que a día de hoy todo sigue muy vigente, y los entornos "fortificados" de Citrix, siguen adoleciendo de los mismos problemas, las sticky keys, demasiadas hot keys, y... too many consoles.

En este caso en concreto, como podéis ver, es un Windows Server 2008 R2 en el que se ha fortificado el entorno, y desde un panel de abrir fichero al que se puede acceder mediante un Ctrl+O, cuando se llama a cmd.exe, aparece el mensaje de la fortificación del entorno.

Figura 1: cmd.exe bloqueado por el administrador

Con cambiar y tirar con PowerShell.exe, ya está listo. Además, como estamos en Windows Server 2008 R2 no hay que saberse ni la ruta ni nada, ya que el path está disponible en cualquier cuadro de diálogo. 

Figura 2: PowerShell.exe disponible para los hackers

Por supuesto, la PowerShell no es solo una shell como cmd.exe, como su propio nombre indica es una Power Shell en la que se pueden hacer mil cosas, y a pesar de ser más peligrosa que el cmd.exe, los administradores todavía no la tienen en consideración. Fail.

De hecho, de nuevo en la fortificación del sistema, la consola de Explorer.exe había sido fortificada, ocultando las rutas a las unidades del sistema, lo que impedía verlas desde la estructura de ficheros mostrada en el Explorador de archivos.

Figura 3: Visualización de disco local bloqueado

Pero para la PowerShell esta medida es algo menos que inexistente, con lo que todo el sistema es tuyo. Para más sorpresas, entre Veritas, Tivoli y SQL Server este sistema tiene disponible ya un Wireshark. ¡Viva la fiesta!

Figura 4: Visualización de archivos y directorios con Power Shell

De hecho, en PowerShell se pueden hacer cosas tan chulas como las que necesitaba hace poco un amigo hacker de Las Vegas que en un pentesting había owneado una máquina y solo tenía una consola. Lo que me pidió por chat fue algo así:

- "¿Cómo puedo buscar en ficheros Excel que están en formato OOXML unos que tuvieran unos valores concretos dentro de las celdas desde la consola".

- "Abrete la consola PowerShell y lánzale un script, K. ¡PowerShell Rulz!" 

- "Bosses Love Excel, Hackers too!"

Realmente creo que la PowerShell se creo para los hackers, que muchos admins no son capaces de salir de las MMCs. }:)) 

Saludos Malignos!

Error 404 en aplicaciones ASP migradas a IIS 7.X

Ya os he contado muchas veces que FOCA analiza los errores 404 de JSP, ASPX, TCL en WebDNA, etcétera, para extraer información valiosa de fingerprinting. Estos errores suelen dar datos que te pueden ayudar a dibujar la red interna, o conocer mejor la estructura de seguridad del sitio. Este es el caso de este error de IIS 7.X que es bastante común encontrar aplicaciones ASP migradas a esta versión.

Figura 1: Error 404 en IIS 6

El Error 404 que aparece en tiene una aplicación ASP sobre IIS 6 suele dar pocos detalles, tal y como se ve en la captura anterior, ya que es bastante sobrio. Pero esto cambió.

Figura 2: Error 404 descubierto buscando aplicaciones asp migradas

Sin embargo, buscando por aplicaciones ASP, y forzando un Not Found, si el sitio ha sido migrado a IIS 7 o IIS 7.5, es probable que el administrador de la aplicación no se haya acordado de fortificar el mensaje de error, por lo que es bastante común encontrar estos mensajes.

Figura 3: Error 404 en otro IIS 7 con una aplicación ASP

Como se puede ver son muy descriptivos, y permiten encontrar la estructura de permisos con los que está corriendo el application pool, el nombre de la aplicación, o rutas locales de acceso a los ficheros del servidor.

Figura 4: Error 404 en un IIS 7.5 con almacenamiento en red y direcciones locales

Por supuesto, esto funciona igual en IIS 7 como en IIS 7.5, así que hay que darle una revisión a las opciones de fortificación si migras una aplicación legacy ASP a un servidor IIS sobre Windows Server 2008 o Windows Server 2008 R2.

En una auditoría de seguridad, siempre revisamos bien todos los mensajes de error, así que si no quieres que tu servidor haga data leak por ellos, revísalos.

Saludos Malignos!

Listado de ficheros en IIS utilizando nombres acortados

No conocía esta vulnerabilidad hasta que la he visto en hackplayers, pero me ha dejado sorprendido la potencia del bug/"característica" para realizar un descubrimiento de ficheros en un servidor IIS por medio del sistema de nombres acortados que aún permite el sistema de ficheros en Microsoft Windows.

La herencia de los 8:3 caracteres en el nombre de los ficheros en un sistema Microsoft Windows, hace que sea posible aún poder acceder a un fichero utilizando ambos métodos, es decir, el del nombre acortado y el del nombre extendido. Aunque esta característica está disponible en Windows, en IIS no es posible, así, tanto si el fichero se encuentra como si no, se generará un error. 

El servidor IIS, cuando se solicita un nombre acortado, va a intentar acceder al mismo, y si lo encuentra, dará un error 404, algo que no debería ser normal. El caso es que cuando el fichero sí está, se continua ejecutando el procesamiento de la URL y si se construye una URL con ingenio, se puede conseguir un error de Bad Request.

Jugando con los errores 404 y los errores Bad Request, es posible hacer un ataque Blind para descubrir el nombre de los ficheros. Esto se puede hacer solo en algunas versiones de IIS y .NET en las que no se ha filtrado el caracter *. Tienes el paper que lo explica aquí, donde además explican cómo acceder a carpetas protegidas o saltar algunas protecciones.

Así, si se llega un servidor IIS 7 con ASPX se debe probar primero que los errores 400 de Bad Request y 404 de Not Found son distintos. Para ello, basta con hacer las dos siguientes pruebas para saber si es vulnerable a este ataque.

Figura 1: Prueba de 404

Figura 2: Prueba de Bad Request

Estas pruebas del ejemplo, darán distintos resultados según se vaya realizando sobre un servidor IIS 5, IIS 6 o IIS 7. La siguiente tabla recoge las pruebas a realizar, y los resultados que se obtienen cuando el nombre del fichero existe (valid) o no existe (invalid):

Figura 3: Tabla de pruebas

Si el sitio no es vulnerable se obtendrá siempre el mismo resultado, o cuando se intente hacer uso de los comodines obtendremos un mensaje como éste:

Figura 4: Servidor IIS NO vulnerable a esta técnica

Si el sitio es vulnerable, se puede proceder a realizar la booleanización haciendo uso del símbolo de acortamiento en el nombre ~1, el caracter comodín *, y tomando el error 404 como un True y el Bad Request como un False.

Figura 5: False. No hay ningún fichero que comience por ab

Figura 6: True. Al menos hay un fichero que comienza por ac

Solo se pueden descubrir los 6 primeros caracteres del nombre, ya que los últimos 2 serán ~1 o ~2, y luego la extensión será de 3 letras.

Figura 7: Nombre de fichero acortado descubierto

Llegados a este punto hay que "adivinar" los últimos caracteres del nombre y la extensión.

Figura 8: Nombre de fichero extendido

Para automatizar este escaneo hay una herramienta como POC llamada IIS Short Name Scanner desarrollada en Java y publicada en Google Code, pero dad por seguro que esto acabará en la FOCA.

Como gracia final, hay que decir que, en .NET las extensiones son de ASPX - 4 caracteres - mientras que el sistema 8:3 almacena los ficheros con extensión ASP, lo que hace que el error 404 sea el de IIS y no el del framework .NET. Para solucionarlo, basta con que hagas que todos los menajes de eror de .NET y de IIS estén controlados y sean iguales.

Saludos Malignos!

Man in the Middle en redes IPv4 por medio de IPv6

En la última sesión del viernes en el SOCtano, estuvimos definiendo los ataques que va a incorporar la herramienta Evil FOCA, y entre ellos, estuvimos hablando de cómo conseguir enrutar tráfico IPv4 a través de un ataque Man in the middle IPv6. Para ello, el primer punto es deshabilitar el protocolo IPv4 y conseguir que el algoritmo de precedencia haga el resto  se reenvíe el tráfico por la conexión IPv6. 

¿Cómo conseguir pasar el tráfico a IPv6?

El problema inicial se da cuando la conexión desde el cliente se hace contra una dirección de Internet IPv4, por lo que la conexión se va a hacer por IPv4 buscando el gateway, que también está en IPv4, por lo cual nuestro ataque man in the middle IPv6 no conseguirá capturar el tráfico.

Paso 1: Anular IPv4

El primer paso consiste en desactivar el tráfico IPv4 de la ecuación, para lo que, si el cliente no tiene ninguna protección tipo Marmita o PatriotNG, bastará con enviar un paquete ARP que configure una dirección MAC falsa a la dirección IP del gateway en el cliente. Esto, si todo va bien, dejará al equipo sin conectividad con el gateway, lo que le hará al sistema evaluar la posibilidad de IPv6. 

Paso 2: Configurar IPv6 en el cliente con Rogue DHCPv6

En segundo lugar habrá que establecer en el cliente una configuración IPv6 que nos sea de utilidad. Si tenemos un servidor Rogue DHCPv6 podremos hacer que el cliente obtenga todo lo necesario de este esquema de ataque:

- Una dirección IPv6 válida
- Una dirección IPv6 de un gateway para la red IPv6
- Las direcciones de los servidores DNSv6

Figura 1: DHCPv6 en Windows Server 2008

Para hacer esto, cualquier servidor Windows Server 2008 o Windows Server 2008 R2 nos permitirá configurar un servidor DHCP para IPv6 y preparar toda la configuración en el equipo víctima para hacer el ataque. Cómo configurar esto se explica en el libro "Ataques de Redes de Datos IPv4 e IPv6"

Paso 3: Configurar IPv6 en el cliente con SLAAC e IPv6 DNS AutoDiscovery 

Otra alternativa sería usar el servicio SLAAC (Stateless Address Auto Configurator) para poder configurar la dirección IPv6 y la dirección del gateway, para que el tráfico IPv6 sea enviado a la máquina del atacante. Sin embargo, el protocolo SLAAC no permite configurar valores como los servidores DNS, algo que complica mucho el esquema si el usuario se conecta a Internet usando nombres de dominios, y el servidor DNS está anulado - tras anular la red IPv4 -

Sin embargo, uno de los servicios de IPv6 que está implementado en las máquinas Windows - no he probado en Linux aún, pero supongo que será similar - es el servicio IPv6 DNS Autodiscovery, propuesto por el Network Working Group del IETF, por el que se realizan peticiones IPv6 a tres direcciones IPv6 fijas para encontrar servidores DNS en la red IPv6.

Figura 2: Ping a un dominio no existente desde un equipo con IPv4 anulado

Para probar esto, basta con hacer un ping a un nombre en la red IPv6 e interceptar el tráfico en el gateway, para ver cómo, en una máquina en la que está anulado IPv4, se lanzan peticiones DNS a las direcciones IPv6 fijas y reservadas, aunque no están configuradas en el cliente.

Figura 3: Peticiones DNS a servidores IPv6 fijados

Las direcciones que se utilizan son las que se ven en la siguiente captura de pantalla, por lo que si se quiere hacer el ataque habría que spoofear esas direcciones para que apunten a la/s maquina/s del atacante. Por supuesto, el documento del IETF se habla en la última sección de las implicaciones de seguridad que puede haber en una red en la que no se haga uso de técnicas para autenticar de manera robusta las direcciones IPv6.

Paso 4: Enrutar el tráfico IPv6 a IPv4 e IPv4 a IPv6

Para lograr que el cliente envíe todo su tráfico con IPv6, tenemos que lograr que toda la resolución de direcciones se haga en formato IPv6, así que hay que contar un servicio DNS64, es decir, un servidor DNS que escuche por IPv6, solicite las queries recursivas por IPv4 y devuelva las respuestas en formato de direcciones IPv4 sobre IPv6.

Figura 4: Esquema de enrutamiento de tráfico IPv4 a IPv6 controlando DNS y Gateway en IPv6

Esto, como se muestra en el esquema hará que las direcciones de servidores IPv4 tengan formato IPv6 y se envíen al gateway IPv6, donde el atacante deberá configurar un servicio NAT64 para enrutar el tráfico por Internet - a través del router IPv4 de la propia red -.

Puedes conocer más sobre esquemas de ataques en red en el libro Ataques en Redes de datos IPv4 e IPv6, y, por supuesto, todo esto se podrá implementar con nuestra querida Evil FOCA.

Saludos Malignos!

***************************************************************************************************
- Hacking en redes de datos IPv6: Conceptos básicos IPv6 (1)
- Hacking en redes de datos IPv6: Conceptos básicos IPv6 (2)
- Hacking en redes de datos IPv6: Te hackearán por IPv6 por pensar que no lo usas
- Hacking en redes de datos IPv6: Neighbor Spoofing
- Hacking en redes de datos IPv6: Captura de SMB con Neighbor Spoofing
- Hacking en redes de datos IPv6: FC00::1 (Algunos) Ataques en redes de datos
- Hacking en redes de datos IPv6: Man in the middle en redes IPv4 usando IPv6
- Hacking en redes de datos IPv6: Desactivar IPv6 para evitar D.O.S. SLAAC
- Hacking en redes de datos IPv6: Topera - Scanner de puertos sobre IPv6
- Hacking en redes de datos IPv6: Predecir direcciones IPv6 Local-Link de OS X
- Hacking en redes de datos IPv6: Ataques en redes de datos IPv 4 e IPv6 ***************************************************************************************************