Categorías
Explotación de Software Hacking Hacking Python

Pentesting sobre Active Directory con CrackMapExec

Vídeo en YouTube

CrackMapExec es una herramienta muy potente para labores de post-explotación, especialmente sobre entornos de Active Directory. Las primeras versiones se enfocaban en la enumeración de servicios SMB, pero actualmente soporta otros protocolos habituales en este tipo de entornos tales como Kerberos, LDAP, MS-SQL, WinRM, entre otros.

Algunas de sus características más interesantes son las siguientes:

  • Es una herramienta open source, basada en Python y con soporte a los principales protocolos que hacen parte de un entorno de Active Directory. Debes tener una versión de Python reciente.
  • Es una herramienta que, dependiendo del protocolo seleccionado, permite ejecutar múltiples pruebas para la post-explotación de sistemas.
  • Puedes utilizar un usuario de dominio para realizar pruebas y, en el caso de no tener uno, permite la ejecución de ataques de fuerza bruta o password guessing.
  • Soporta la autenticación con un usuario de dominio y su contraseña, con un ticket TGT de Kerberos o el usuario y su hash NTLM (Pass The Hash).
  • Cuando ejecutas CrackMapExec por primera vez, se crea un directorio en tu HOME, el cual almacena un histórico de los comandos que has ejecutado y una base de datos que puedes consultar posteriormente con la herramienta «cmedb».
  • Soporta el uso de sesiones y Workspaces, similar a otras herramientas como Metasploit Framework.
  • Todos los protocolos soportados por la herramienta están compuestos por módulos, los cuales, en algunos casos, permiten la identificación de vulnerabilidades y la exfiltración de información sensible.
  • Es una utilidad que se mantiene actualizada y que, poco a poco, va aumentando la cantidad de módulos y protocolos soportados.

Es una herramienta estupenda y, si no la conoces y quieres aprender a usarla, tienes la oportunidad de hacerlo en la comunidad THW.


Recuerda que puedes registrarte en la comunidad THW: https://comunidad.thehackerway.es/registro

En este sitio web recibirás anuncios sobre ofertas de trabajo y novedades del sector, además podrás participar en los foros y ganar premios por ello.
Puedes acceder a los cursos cortos y artículos con una suscripción: https://comunidad.thehackerway.es/suscripcion
Los contenidos a los que tendrás acceso te serán útiles para comprender por qué no consigues trabajo en el sector o mejoras profesionalmente y, por supuesto, proponerte ideas para mejorar esa situación.

Por otro lado, también tienes todas las formaciones y packs de The Hacker Way. Las mejores formaciones en castellano que podrás encontrar. Y no lo digo yo, puedes ver las reseñas en el sitio web. Más de 500 alumnos han aprovechado los cursos online en THW y tú también podrías ser uno de ellos: https://thehackerway.es/cursos

¡Un saludo y Happy Hack!
Adastra.

Categorías
Explotación de Software Hacking Services - Software

Cómo montar un laboratorio de Active Directory con Windows Server 2022 desde cero – Parte 1 de 2

Demostración en vídeo de éste post.

Me resulta muy interesante la evolución de los sistemas Windows, tanto en estaciones de trabajo como servidores. Parece que pocas cosas cambian entre las diferentes versiones, pero lo cierto es que desde la perspectiva de un técnico, cada nueva versión introduce características (y vulnerabilidades) que nos obligan a mantenernos al día y estudiar continuamente. Por poner un ejemplo, en los últimos años gracias a Microsoft Azure, es posible tener controladores de dominio en la nube y contar con servicios distribuidos en diferentes ubicaciones geográficas, algo que mejora la escalabilidad, pero plantea nuevos retos y amenazas que antes no existían.
Precisamente por este motivo, en Securízame hemos creado los entrenamientos 100% prácticos sobre entornos Windows, que esperamos volver a realizar en el 2023, así que si esto te interesa, te recomiendo que estés atento a los anuncios que emitiremos este año.
En éste post y en vídeo que tienes disponible en YouTube (mira un poco más arriba) he decidido explicar cómo montar un laboratorio vulnerable con Windows Server 2022 y al menos una estación de trabajo con Windows 11.
Si bien el procedimiento es prácticamente el mismo que para otras versiones de Windows Server y Windows «Workstation», hay algunos detalles en los que difiere un poco y que explicaré a continuación.

Requisitos

En primer lugar, debes descargar las imágenes de Windows 11 y Windows Server 2022 desde la página web de Microsoft.

Descargar Windows Server 2022

Descargar Windows 11

Aunque puedes utilizar cualquier solución de virtualización, en este caso concreto verás cómo llevar a cabo el proceso con VirtualBox.

Primeros pasos

El proceso de instalación de las máquinas virtuales es básico y lo puedes ver en el vídeo anterior que está subido en YouTube, partiendo de esa base puedes empezar a aplicar algunas configuraciones básicas que explico a continuación.

Configuraciones básicas en el DC

  1. Asignar un nombre al controlador de dominio recién instalado. Para ello, puedes ir a:  Windows -> en el campo de búsqueda escribir «PC Name» y luego, seleccionar la opción «Renombrar ordenador». Tal como aparece en el vídeo de YouTube, se ha asignado el nombre «THW-DC»
  2. Click en «Configuración de red e internet» -> «Opciones de uso compartido» -> «Activar detección de redes» para público, privado y dominio.
  3. Click en «Configuración de red e internet» -> «Centro de redes y recursos compartidos» -> «Cambiar adaptador de red» -> Cambiar configuración para IPv4 y poner como DNS primario la IP del gateway (p.e. 192.168.1.1) y establecer una IP estática.
    A continuación, desde la configuración del adaptador de red pinchar en «Cambiar configuración para IPv6» y poner «obtener automáticamente el servidor DNS».
  4. Llegados a éste punto, es mejor reiniciar.
  5. Ahora se pueden configurar los servicios del Domain Controller
    1. Desde la aplicación de «Server Manager» -> Administrar -> Añadir Roles y características -> Seleccionar siguiente hasta «Roles de Servidor».
    2. En «Roles de Servidor» seleccionar -> «Active Directory Domain Services» o «Servicios de dominio de Active Directory» -> Add Features. Finalmente, Siguiente -> Siguiente -> Install.
    3. Cuando termina la instalación, en la aplicación «Server Manager», se debe pinchar en el botón de «Warning» y comenzar con la configuración del AD seleccionando la opción que pone «Promover el servidor a controlador de dominio.»
    4. Pinchar en «Agregar a un nuevo bosque» e introducir un valor como por ejemplo «thehackerway.local» y Siguiente.
    5. En opciones de controlador, se debe escribir la contraseña para el modo de restauración de servicios de directorio (DSRM).
    6. Continuar con los valores por defecto. Al final del proceso es necesario reiniciar. Se podrá ver en la pantalla de inicio de sesión que ahora aparece thehackerway.local\Administrador

Configuración de los servicios AD CS (Certificate Services).

Los servicios de Active Directory Certificate Services representan la implementación de PKI oficial de Microsoft y están dando mucho de qué hablar desde el 2021, especialmente desde vulnerabilidades como PetitPotam, noPac y una de las más recientes a la fecha de redactar este post, identificada con el CVE-2022-26923 y que le permite a un atacante que ya cuenta con un usuario de dominio, solicitar un certificado para una máquina arbitraria en la red (como un controlador de dominio) y suplantarle, para ello basta simplemente con cambiar el atributo DnsHostName de una cuenta de máquina, la cual se puede crear fácilmente utilizando el script «addmachine.py» de Impacket o una de las tantas utilidades para pentesting sobre sistemas Windows que se encuentran disponibles.
El proceso de instalación de esta implementación de PKI es muy simple y en todo caso,  se realiza sobre el controlador de dominio siguiendo los siguientes pasos:

  1. En la herramienta de administración del servidor -> Agregar características y roles -> Siguiente hasta Roles de servidor. Seleccionar todas las características de «Servicios de Certificado de Active Directory». Siguiente, siguiente, instalar.
  2. Una vez instalado, es necesario configurar los servicios. Se debe pinchar en la advertencia que aparece en la herramienta de «administración del servidor» y a continuación, seleccionar todos los servicios de rol.
  3. En cuenta de servicio para NDES, especificar la cuenta del servicio. Se puede seleccionar la cuenta del Administrador. Siguiente.
  4. En información de RA, se puede dejar todo por defecto y continuar con el asistente hasta el final.
  5. Ahora, se puede abrir una CMD de Powershell con permisos de administrador y se instala el módulo PSPKI además, también se permite la instalación de NuGet y PowerShellGet.Install-Module -Name PSPKI
  6. A continuación, se puede importar el módulo y comprobar la configuración de Enrollment.Import-Module PsPKI
    Get-CertificationAuthority | Select Name, Enroll* | Format-List *

Con los pasos anteriores ya se cuenta con un controlador de dominio con una configuración mínima.

En el siguiente post explicaré cómo habilitar varias características que harán que el dominio sea vulnerable y además, cómo unir una estación de trabajo con Windows 11.

Un saludo y Happy Hack!
Adastra.

Categorías
Explotación de Software Hacking Services - Software

10 Herramientas esenciales para pentesting en Active Directory – Parte 2 de 2

Demostración en vídeo de éste post:

En el post anterior explicaba algunas de las herramientas que a mi juicio, son fundamentales para labores de explotación y post-explotación en sistemas Windows, especialmente aquellos que se encuentran en un entorno de Directorio Activo. En éste post, explicaré cinco herramientas más. Posiblemente ya las conoces (o no), en todo caso aquí van:

6. BloodHound y SilentHound

BloodHound es una utilidad que se me parece mucho a Maltego, al menos visualmente porque sus funcionalidades son completamente distintas. Se trata de una herramienta que recibe un fichero con información de un dominio y te permite hacer consultas interesantes con el objetivo de descubrir malas configuraciones o vulnerabilidades en el entorno. Su funcionamiento es simple, en primer lugar necesitas ejecutar un «Collector» sobre una máquina unida a un dominio. Dicho programa viene en dos formatos: «exe» y «powershell», ambos se encuentran disponibles en su repositorio de GitHub. Una vez se ejecuta dicho componente, se generan ficheros comprimidos que debes descargar a tu máquina como atacante para luego subirlos a tu servidor de BloodHound, el cual hará todo el trabajo de cargar la información para su posterior visualización. Como he mencionado antes, me recuerda a Maltego ya que enseña toda la información en una «paleta» con muchos elementos, por lo que si se trata de un dominio grande puede ser un tanto difícil de visualizar todo, no obstante las consultas que ya trae preparadas permiten extraer información muy valiosa del entorno y tener una idea de por dónde empezar a atacar.
El problema que tiene BloodHound es que es extremadamente invasivo, realiza consultas sobre el dominio que son fáciles de identificar por cualquier mecanismo de seguridad perimetral, en otras palabras: genera mucho ruido. Por este motivo, existe otra herramienta llamada SilentHound que realiza menos consultas y de una forma más sigilosa, evitando generar demasiadas alarmas sobre el objetivo. Es una alternativa que en la mayoría de los casos, resulta más interesante que utilizar el Collector que viene incluido en BloodHound.

7. PingCastle

Se trata de un programa pensado para realizar pentesting sobre entornos de Active Directory partiendo de una estación de trabajo. Tal como se describe en su página oficial, es capaz de ejecutar pruebas al mejor estilo de BloodHound, pero de una forma menos intrusiva. Es un programa que viene unicamente en formato EXE y para poder usarlo se debe subir a la estación de trabajo, aquí no es posible ejecutar el Invoke-Binary de Evil-WinRM ya que no se trata de un Assembly de C#. Cuenta con varias opciones por línea de comandos y cuando finaliza su ejecución, genera un informe en formato HTML muy completo con toda la información recolectada. En mi opinión, los informes generados por PingCastle pueden aportar más valor que las consultas preparadas que incluye BloodHound.

8. Impacket

Probablemente ya has visto la serie de posts sobre Impacket que se han publicado en éste blog, si no es el caso de aconsejo que los leas. Se trata de una de las librerías más potentes que existen en el mundo de Python para pentesting sobre Windows. Si bien un desarrollador le puede sacar el máximo provecho, cuenta con scripts que permiten explotar todo su potencial. Estos scripts se encuentran en el directorio de «examples» y permiten, entre otras cosas, levantar servidores de diferentes tipos, volcar información sensible de una máquina Windows previamente comprometida, generar una shell usando diferentes métodos, entre muchas otras cosas interesantes.

9. WinPEAS

Se trata de otra herramienta de la que ya se ha hablado en éste blog. Es desarrollada y mantenida por Carlos Polop, autor de uno de los mejores recursos disponibles para pentesting: book.hacktricks.xyz. Esta herramienta ejecuta un checklist sobre una estación de trabajo y enseña malas configuraciones que potencialmente pueden representar una brecha de seguridad, así como CVEs o vulnerabilidades que pueden estar presentes en el sistema. Cuenta con un sistema de colores que le hace especialmente interesante, ya que rápidamente puedes enfocarte en lo que con una alta probabilidad puede ser un problema de seguridad, algo que otras herramientas de post-explotación desafortunadamente no tienen. Además de WinPEAS, también tienes otras para Linux y Mac, las cuales siguen la misma filosofía y son especialmente interesantes. Las encuentras disponibles en el proyecto PEAS-Ng

10. Mimikatz

Finalmente tenemos Mimikatz (o Kiwi). Es una herramienta que lleva muchos años en el sector y es poco probable que no lo hayas escuchado antes. En mi opinión es un «must» para las labores de post-explotación en sistemas Windows ya que te permite, entre otras cosas, exportar los tickets de Kerberos que se encuentran cargados en la memoria del proceso LSASS. Solamente por esto ya merece la pena utilizarla. Uno de sus usos más habituales consiste en extraer contraseñas en texto plano que se cargan en la memoria del proceso LSASS en sistemas inferiores a Windows 8,  no obstante, hay que tener en cuenta que para sacarle el máximo provecho necesitas permisos de administrador.

Esto esto, espero que este listado te haya parecido interesante y sobre todo útil. Si conoces alguna otra que merezca la pena incluir en éste post, puedes dejarla en los comentarios.

Un saludo y Happy Hack!
Adastra.

 

Categorías
Cracking Explotación de Software Hacking Services - Software

10 Herramientas esenciales para pentesting en Active Directory – Parte 1 de 2

Demostración en vídeo de éste post:

Hay una gran cantidad y variedad de herramientas que apoyan en el proceso de pentesting sobre sistemas Windows y muy concretamente, sobre entornos de Active Directory. En este post y el siguiente enumeraré 10 herramientas que en mi experiencia, son esenciales cuando se realiza una auditoría de seguridad en éste tipo de entornos. Obviamente hay bastantes más, pero creo que éstas representan un buen punto de partida para tener un «arsenal» lo suficientemente sólido a la hora de ejecutar auditorías sobre sistemas Windows.

1. Evil-WinRM

Evil-WinRM es, con diferencia, una de las herramientas más útiles cuando se trata de realizar labores de post-explotación sobre un sistema Windows. Utiliza el protocolo WinRM para el establecimiento de conexiones remotas con sistemas Windows y genera una shell interactiva. Cuenta con varios comandos que permiten subir y descargar ficheros, ejecutar assemblies de C# en memoria, importar scripts de Powershell, entre muchas otras cosas. Si quieres aprender en detalle cómo funciona, te recomiendo los siguientes vídeos publicados en el canal de YouTube:

Evil WinRM Shell sobre WinRM para pentesting en sistemas Windows Parte 1 de 2
Evil WinRM Shell sobre WinRM para pentesting en sistemas Windows Parte 2 de 2

2. GhostPack

Se trata de un conjunto de herramientas muy potente para labores de pentesting sobre sistemas Windows. Cuenta con utilidades tan conocidas como Rubeus, Seatbelt, SharpDPAPI y SharpUp. Estas herramientas se encuentran desarrolladas en C# y es necesario descargar el código del proyecto y compilar la solución DotNet, lo cual no es nada complejo de hacer aunque puede llevar algo de tiempo. Ya se ha escrito sobre estas herramientas en el blog, así que te recomiendo su lectura en los siguientes posts:

Post-explotación en sistemas Windows con GhostPack – Parte 1 de 3
Post-explotación en sistemas Windows con GhostPack – Parte 2 de 3
Post-explotación en sistemas Windows con GhostPack – Parte 3 de 3

3. CrackMapExec

En este caso es una herramienta que últimamente está ganando popularidad y no es para menos. Permite la ejecución de pruebas sobre servicios comunes en un entorno de Active Directory, tales como SMB, RDP, MSSQL, entre otros. Es una utilidad que se puede ejecutar desde la máquina del atacante y funciona perfectamente. Aunque no hace falta un usuario para que las pruebas se lleven a cabo correctamente, la herramienta permite indicar un usuario y contraseña (local o de dominio) para lanzar pruebas sobre el sistema objetivo de la forma más completa posible. Si quieres aprender un poco más sobre el uso de ésta herramienta, puedes leer el siguiente post y ver el vídeo que le acompaña en YouTube.

4. ADReaper

Es una utilidad orientada a la enumeración remota, permite extraer información variada de un sistema Windows ejecutando consultas LDAP. Tal y como ocurre con CrackMapExec, es posible ejecutar la herramienta sin indicar un usuario de dominio, sin embargo, podrá extraer mucha más información si se especifica uno y por este motivo, puede ser vista como una herramienta orientada a la post-explotación.

5. Certify y Certipy

Estas dos utilidades se han vuelto muy populares tras la aparición de las múltiples vulnerabilidades que afectan a la PKI diseñada por Microsoft para sistemas Windows Server, también conocida como AD CS (Active Directory Certificate Services). Son herramientas que de hecho, no explotan ninguna vulnerabilidad, simplemente realizan consultas sobre los servicios de AD CS y permiten detectar malas configuraciones que le permiten a un atacante la explotación del entorno. La principal diferencia es que Cerify se encuentra desarrollada en C# y es necesario subir el programa a una estación de trabajo unida al dominio o ejecutarla desde memoria con Invoke-Binary de Evil-WinRM, mientras que Certipy es un script en Python que se puede ejecutar desde la máquina del atacante, en donde solamente es necesario indicar las credenciales de un usuario de dominio para su ejecución.

En éste post se han mencionado cinco herramientas fundamentales para entornos de Active Directory, en el siguiente post se mencionarán cinco más que también considero fundamentales.

Un saludo y Happy Hack!
Adastra.

Categorías
Explotación de Software Hacking Services - Software

Spring4Shell: Vulnerabilidad de RCE en Spring Framework

Demostración en vídeo de este post

 

La vulnerabilidad conocida como Spring4Shell ha aparecido hace algunas semanas y según su descripción, le permite a un atacante ejecutar código Java arbitrario en una aplicación que utilice alguna de las versiones afectadas de Spring Framework. Su CVE es el CVE-2022-22963 y tiene asignado un score de 9.8 y aunque ya se encuentra parcheada a partir de la versión 5.3.18 de Spring Framework (core) y la versión de 2.6.6 de Spring Boot, es probable que afecte a aplicaciones Java/J2EE que aún no han actualizado las dependencias de sus ficheros Gradle o POM. Lo más curioso de esta vulnerabilidad es que no es nueva, se trata de un bypass de las medidas de seguridad que se implementaron en su día para mitigar otra vulnerabilidad que apareció en el año 2010 con el identificador CVE-2010-1622.

¿Cómo sé si mi aplicación con Spring Framework es vulnerable?

Si tu aplicación utiliza un JDK igual o superior a la versión 9, en el classpath de la aplicación se encuentra la librería spring-beans*.jar y además, estás utilizando una versión Spring 5.3.0  – 5.3.17 o 5.2.0 – 5.2.20  es probablemente que tu aplicación sea vulnerable. La forma más rápida de comprobarlo es simplemente abrir el fichero spring-beans*.jar y verificar si se encuentra la clase CachedIntrospectionResults.class. Si la aplicación está en ejecución, se puede comprobar realizando una petición HTTP a uno de los endpoints disponibles en la aplicación, ya sea que se encuentre desarrollada con Spring MVC, WebFlux o Spring Rest, el comportamiento será el mismo si la aplicación es vulnerable. Dicha petición HTTP se enseña en la siguiente imagen.

Como se puede ver, en la URL se ha introducido el siguiente payload: ?class.module.classLoader.URLs%5B0%5D=0

En el caso de que la aplicación sea vulnerable, el servidor devolverá un HTTP 400, si la respuesta es un código de estado diferente lo más probable es que la aplicación no sea vulnerable o bien, exista algún tipo de filtro que este impidiendo la explotación, como por ejemplo un WAF capaz de detectar el patrón de ataque.
Otro payload que ayuda a verificar si la aplicación es vulnerable es el siguiente: ?class.module.classLoader.DefaultAssertionStatus=nothing
Nuevamente, si la aplicación es vulnerable, se podrá ver un error HTTP 400.

Prueba de Concepto

Ahora mismo hay múltiples pruebas de concepto disponibles en repositorios de GitHub. Probar la existencia de esta vulnerabilidad y su explotación no es una labor complicada, solo hace falta que la aplicación utilice alguna de las versiones vulnerables del framework y ejecutar peticiones HTTP que obliguen al cargador de clases de Java a ejecutar las instrucciones que se le indiquen, las cuales típicamente, incluirían la carga de la clase java.lang.Runtime y ejecución de los métodos getRuntime() y exec(). Una prueba de concepto interesante se encuentra disponible en el repositorio de reznok la cual cuenta con exploit en Python y una aplicación con Spring MVC simple para probar. La aplicación se encuentra dockerizada, por lo tanto basta con crear una imagen y un contenedor partiendo de dicha imagen para realizar las pruebas. A continuación, se puede ejecutar el fichero exploit.py  indicando la URL donde se encuentra la aplicación y si todo va bien, se encargará de generar un fichero «shell.jsp» en la aplicación «ROOT» de Tomcat.

Solución

Como se ha mencionado anteriormente, para resolver este problema solo hace falta actualizar Spring Framework a una versión superior a la 5.3.17 y si se utiliza Spring Boot, actualizar a una versión superior a la 2.6.5. Es una vulnerabilidad critica, pero no significa que se desaconseje el uso de Spring Framework, de hecho, a diferencia de otras tecnologías, la comunidad de Spring lleva dos décadas de trabajo continuo y los defectos que se reportan, que no solamente son de seguridad, se suelen corregir al cabo de pocos días. Además, las actualizaciones, salvo en casos puntuales, no suelen presentar conflictos con las aplicaciones que utilizan una versión antigua, siempre y cuando sean de la misma rama. Como ya ha ocurrido con otra vulnerabilidad muy sonada en el mundo de Java/J2EE (log4shell), no hay que olvidar que muchos de los componentes que utilizamos en desarrollo de software son mantenidos por comunidades y voluntarios, lo que significa que se espera que este tipo de problemas se presenten con cierta frecuencia y lo mejor que se puede hacer es estar atento a los avisos de seguridad y parchear cuanto antes. Como siempre, es buena idea aportar a estos proyectos a través de donaciones o código, después de todo, son tecnologías que usamos casi a diario ya sea como usuarios finales o como desarrolladores.

Un saludo y Happy Hack!
Adastra.

Categorías
Explotación de Software Hacking Web Applications

Seguridad en APIs Rest: Asignación masiva

Demostración en vídeo del post

En un post anterior se ha descrito el proyecto OWASP Api Security Project el cual se ha publicado en el año 2019 y que describe las principales vulnerabilidades que afectan a las APIs Rest, las cuales después de todo, no dejan de ser aplicaciones web con algunas características particulares. Si quieres aprender en detalle cómo detectar y explotar las principales vulnerabilidades que afectan a las APIs Rest, te recomiendo el curso de Hacking web contra APIs Rest disponible en THW.

Concretamente, la vulnerabilidad de «asignación masiva» o «mass assignment» se encuentra en la posición 6 de la lista y en el proyecto tiene la siguiente descripción:

Vincular los datos proporcionados por el cliente (por ejemplo, en formato JSON) a los modelos de datos en el servidor, sin realizar el filtrado de propiedades adecuado, generalmente conduce a una asignación masiva. Ya sea adivinando las propiedades de los objetos, explorando otros puntos finales de la API, leyendo la documentación o proporcionando propiedades de objetos adicionales en los payloads de las solicitudes, permite al atacantes modificar las propiedades de los objetos que se supone que no debería poder modificar.

Esta descripción significa que el atacante debe tener un conocimiento sobre cómo se asignan los valores enviados en una estructura en formato JSON (o otro formato) a un objeto en el lado del servidor, ya sea por medio de prueba y error o analizando las respuestas que va devolviendo la API Rest. En cualquier caso, es una vulnerabilidad con efectos muy dañinos para la aplicación, ya que puede producir desde un defacement o alteraciones en la estructura de las páginas, hasta elevación de privilegios horizontal o vertical. Aunque es una vulnerabilidad critica, no hay que olvidar que el atacante debe tener saber cómo se realiza la asignación en el backend, lo cual no siempre es tan fácil y precisamente por este motivo, es una vulnerabilidad que no se encuentra en las primeras posiciones de la lista.

¿Cómo probar las vulnerabilidades de Mass Assignment?

Como se ha mencionado anteriormente, en un contexto de caja negra se requiere prueba y error para conseguir el objetivo, es necesario analizar las respuestas emitidas por la aplicación y comprobar si se expone algún atributo que pueda ser susceptible de asignación masiva. En un modelo de caja blanca o gris encontrar este tipo de vulnerabilidades normalmente implica menor esfuerzo, ya que se cuenta con el código fuente de la aplicación y esto ayuda a detectar el defecto mucho más fácilmente. Para realizar algunas pruebas, se puede utilizar una API Rest vulnerable por diseño, existe una buena cantidad de estas aplicaciones en GitHub, sin embargo para este caso se utilizará DVWS (Damn Vulnerable Web Services). Se trata de una aplicación desarrollada en NodeJS y que se encuentra «dockerizada». Solamente hace falta tener instalado Docker y docker-compose y levantar los contenedores.

Aunque se trata de una aplicación que tiene múltiples vulnerabilidades, en este caso se probará la asignación masiva que permite la elevación de privilegios de una forma fácil y rápida, así quedará mucho más claro su impacto.

En primer lugar, se puede apreciar que existe una interfaz web en la que desde el mismo formulario se puede ejecutar el proceso de registro de usuarios y autenticación. No hay que olvidar que es una aplicación de pruebas, es normal que su apariencia y funcionamiento sea poco profesional.

Utilizando una herramienta como Burp o ZAP se pueden capturar ambas peticiones y verificar los campos que devuelve la API Rest en la respuesta. Primero, la petición de registro para poder acceder a la aplicación web.

Se puede apreciar en la respuesta que el código de estado es un HTTP 201, lo que significa que se ha registrado correctamente el usuario. Además, se puede comprobar en la respuesta que la API devuelve el nombre del usuario y el hash de la contraseña. Esto ya representa un problema, si se piensa detenidamente, no hace falta devolverle al cliente dicho hash, basta con indicar que el proceso de registro se ha llevado correctamente. Esto puede verse como una fuga de información, sin embargo de momento no parece que haya una vulnerabilidad de asignación masiva. A continuación, se captura la petición de login, en donde se utilizará el usuario que se ha registrado anteriormente.

Esta respuesta es mucho más interesante, ya que se aprecia una estructura JSON completa, en la que aparecen algunos campos que no estaban antes en el proceso de registro. Llama la atención especialmente el campo «admin», el cual al parecer recibe un valor booleano. Cuando se encuentra algo así, cabe preguntarse ¿Qué pasaría si durante el proceso de registro del usuario envío el campo «admin» con el valor «true»? es una observación simple y se produce por la sospecha de que es un campo que tiene un valor false por defecto y que, posiblemente, se encuentra en el modelo de datos. Si se envía dicho campo en la petición y la aplicación simplemente deserializa la estructura JSON en un objeto en servidor sin hacer ninguna validación, se producirá la asignación masiva.

Y ahora, para comprobar si lo que se sospecha es correcto, basta simplemente con iniciar sesión y comprobar si el usuario tiene permisos de administrador.

Como se puede ver, ahora el usuario «testuser» tiene privilegios de administrador y tendrá la posibilidad de acceder a la consola administrativa de la aplicación web.

En conclusión, se trata de una vulnerabilidad en la que hace falta estar atento a los detalles y contar con experiencia en pentesting web. En una API rest con cientos de endpoints no será tan sencillo como se ha visto en este post (o sí), pero lo que se pretende es que quede claro el concepto para que luego lo tengas en cuenta y puedas realizar estas pruebas en las auditorías web que realizas. Finalmente, si estás interesado en aprender en detalle las vulnerabilidades del OWASP API Security Project y el uso de ZAP para detectar y explotar dichos defectos, te recomiendo apuntarte al curso completo de ZAP y al de Hacking contra APIs Rest.

 

Un saludo y Happy Hack!
Adastra.

Categorías
Explotación de Software Hacking Networking Services - Software

Evil-WinRM: Shell sobre WinRM para pentesting en sistemas Windows – Parte 2 de 2

Demostración en vídeo del post

En el post anterior sobre Evil-WinRM he mencionado cómo funciona, los mecanismos de autenticación que se podrían emplear sobre un sistema Windows y cómo hacerlo con la herramienta. En esta segunda parte es un buen momento para explorar algunas de las características que a mi juicio, son las más interesantes y por las que la herramienta destaca en un proceso de post-explotación sobre sistemas Windows.

Comandos básicos

Para empezar, la herramienta cuenta con algunas funciones que ayudan en los movimientos de ficheros entre el atacante y la víctima. Estas funciones permiten subir o descargar ficheros con facilidad y son upload y download respectivamente.

Otros comandos básicos también permiten lanzar scripts en Powershell que se encuentran en el «path» indicado en la opción «-s». Esto es especialmente útil para ejecutar rutinas de enumeración sobre el sistema comprometido sin necesidad de subir manualmente el script y lanzarlo en la máquina, además son rutinas que se ejecutan en memoria, lo que facilita en algunos casos la evasión de AVs.

El comando «menu» enseña los comandos disponibles de forma «nativa» en la herramienta y los que se cargan por medio de scripts Powershell. Es una buena manera de ver rápidamente cuáles son los comandos que se encuentran disponibles. Además, cuando se carga un script como el de PowerView entre otros, los módulos (cmdlets) de dichas utilidades aparecen en el listado de comandos, lo que también permite apreciar cuáles son los elementos que se encuentran disponibles en los scripts que se van cargando. El comando services también es útil, ya que permite ver los servicios que se encuentran en ejecución en ese momento y además, enseña el path correspondiente del binario lo que permite ver si hay algún servicio que sea vulnerable a Unquoted Service Path.

Por otro lado, hay una serie de labores que son habituales cuando se ejecutan procedimientos de pentesting sobre entornos Windows, entre las que se encuentran la carga y ejecución dinámica de DLLs y binarios (creados utilizando C#). Nuevamente, Evil-WinRM ayuda en estos procedimientos ya que cuenta con rutinas preparadas para ello. Además, soporta la técnica Donut, la cual permite crear un payload utilizando dicho proyecto y luego «enchufarlo» utilizando Evil-WinRM, evidentemente hacerlo así resulta muy cómodo y ahorra tiempo.

Carga dinámica de DLLs y binarios

Para la carga de una DLL que se encuentra ubicada en el sistema del atacante es posible utilizar la instrucción Dll-Loader. Permite indicar la ubicación de dicha DLL, ya sea en un directorio local, en un servidor HTTP o un recurso compartido SMB. Lo único que hay que tener en cuenta es que no es posible subir cualquier DLL, solamente son admitidas aquellas que se han creado a partir de un programa en C# y compilado con el una herramienta como el Visual Studio .Net o el compilador «dotnet» disponible también para sistemas Linux. Un buen candidato para este tipo de rutinas es precisamente el proyecto GhostPack, el cual incluye herramientas tan potentes e interesantes como Rubeus, Seatbealt, SharpUp o SafetyKatz.

Como se puede apreciar, el binario se ejecuta sin problema y no ha sido necesario transferirlo a la máquina comprometida, se ejecuta en memoria y devuelve el flujo de salida correspondiente. Aunque en la documentación disponible en GitHub se indica que los binarios admiten un máximo de 3 parámetros, tal como se puede comprobar en la imagen anterior se pueden especificar más, todos ellos separados por coma.

Carga y ejecución de «Donuts»

Otra característica interesante que tiene Evil-WinRM es el soporte a los payloads que se pueden generar utilizando la herramienta Donut, la cual cuenta entre sus funcionalidades, la posibilidad de inyectar binarios, DLLs y Assemblies de .Net en la memoria de un proceso seleccionado. Donut es una herramienta muy completa, por ese motivo merece la pena dedicar un post independiente a explicar qué tiene para ofrecer en procesos de pentesting.
La instrucción Donut-Loader disponible en Evil-WinRM es de gran ayuda para simplificar la ejecución de un «Donut» en la máquina comprometida, ya que simplemente recibe el identificador del proceso objetivo y el fichero con el payload generado por Donut, a continuación se encarga de cargar y ejecutar dicho payload en el sistema comprometido, utilizando la memoria del proceso anfitrión.

En la imagen anterior se aprecia cómo se ha se ejecutado un payload de meterpreter utilizando la técnica Donut y Evil-WinRM. No obstante, hay que tener en cuenta que en este caso concreto se ha utilizado el script «donut-maker.py» que permite exporta un fichero «bin» partiendo del ejecutable generado por msfvenom o cualquier otra herramienta.

Sin duda Evil-WinRM ha alcanzado un buen nivel de madurez y se puede utilizar con total confianza en procesos de pentesting, su simplicidad y facilidad de uso le convierten en una herramienta fundamental a la hora de realizar conexiones a sistemas Windows con el servicio de WinRM habilitado. De hecho, como se ha podido comprobar dadas sus características no solamente aplica a procedimientos de pentesting, su uso es perfectamente válido por parte de administradores de sistemas que quieran controlar remotamente un servidor Windows sin necesidad de utilizar un protocolo como RDP.
Merece la pena que aprendas a utilizarla y la adaptes en tus pruebas sobre sistemas Windows.

Un saludo y Happy Hack!
Adastra.

 

Categorías
Explotación de Software Hacking Hacking Python MetaSploit Networking

Técnicas y herramientas para ataques de Phishing con MalDocs – Parte 2 de 2

Demostración en vídeo del post

En el post anterior se ha mencionado algunas de las herramientas básicas a la hora de crear documentos ofimáticos maliciosos, los cuales evidentemente pretenden comprometer un sistema objetivo. Este tipo de ataques entran en la categoría de «client-side» dado que es necesaria la interacción con una víctima para que «ejecute» el payload que se le ha enviado y para ello, normalmente son necesarias técnicas de ingeniería social. En este post, se mencionará otras herramientas útiles que servirán para demostrar el impacto de este tipo de ataques.

Captura de Hashes con NTLM_Theft

Hace algunos meses Jesús Rufo nos hablaba en este blog sobre la herramienta NTLM_Theft, la cual se encuentra desarrollada en Python y se enfoca en la generación de diferentes tipos de ficheros maliciosos, entre los que se incluyen documentos en formato DOCX y XLS. Una de las novedades que incorpora esta herramienta es que cada uno de los documentos generados implementa y se aprovecha de características propias del software que procesa el documento con el objetivo de extraer hashes NTLM. Por ejemplo, en el caso de generar un documento DOCX, la herramienta se encarga de hacer una petición SMB a un sistema remoto en busca de una imagen y para esto, se intenta llevar a cabo el típico proceso de «reto-respuesta» del protocolo NTLM. La herramienta permite generar un documento que hace referencia a una supuesta imagen en una IP que, evidentemente, es controlada por el atacante. En el caso de generar un documento XLS se sigue la misma dinámica, pero en ese caso crea una hoja de cálculo e  introduce una celda en ella que tiene la instrucción «externalcell://» la cual obliga a Excel a ejecutar la petición NTLM inicial para el proceso de autenticación en el servidor SMB y nuevamente, el atacante podrá capturar dicha petición utilizando Impacket, Responder.py, Metasploit Framework o cualquier otra utilidad similar.

Cuando el documento XLSX creado se abra en el sistema de la víctima, se podrá ver en la terminal de responder cómo se reciben los hashes del usuario y en ese momento, sería posible aplicar un proceso de cracking con el objetivo de romper dicho hash.

Automatización del ataque con Python

Lo que hace NTLM_Theft está muy bien por varias razones, pero la más interesante de todas es que es difícil de detectar ese tipo de ataques y mejor aún, dada su simplicidad se puede crear un script en cualquier lenguaje que automatice el proceso con pocas instrucciones. Por este motivo he creado un script simple que automáticamente levanta el módulo de captura SMB disponible en Metasploit Framework y gracias a la librería xlswritter, se crea un fichero XLS con una celda que contiene la instrucción «external://». Dicha instrucción hace referencia al servidor donde se está ejecutando el módulo de Metasploit Framework así que cuando se transfiera dicho documento y la víctima lo abra, se recibirán automáticamente los hashes NTLM.

Es un script que he creado en pocos minutos mientras escribía este post y por supuesto, se pueden hacer muchas más cosas pero se trata de una simple prueba de concepto que ayudará a entender la facilidad con la que se pueden ejecutar estos ataques y el impacto que puede suponer para la seguridad.

Si este post y el anterior te han gustado, deja un comentario y si despierta vuestro interés, escribiré más sobre este tipo de técnicas ya que hay muchas más herramientas y alternativas para «jugar» con MalDocs.

Un saludo y Happy Hack!
Adastra.

Categorías
Explotación de Software Hacking MetaSploit Networking

Técnicas y herramientas para ataques de Phishing con MalDocs – Parte 1 de 2

Demostración en vídeo de este post

Las campañas de Red Team suelen tener un componente de Phishing que típicamente brinda el acceso inicial a uno o varios sistemas en el entorno comprometido. Cuando se crea un «Phishing assessment» hay una serie de técnicas y herramientas que apoyan en todo el proceso y cuando todo esto se monta sobre una infraestructura bien pensada y con pretextos orientados al target en cuestión, los resultados suelen ser muy satisfactorios. En este post se proporciona un listado de algunas técnicas y herramientas habituales para campañas de Phishing, concretamente enfocadas al uso de MalDocs (documentos ofimáticos maliciosos).

Gophish

Se trata de un framework opensource para el establecimiento y creación de todo el circuito del que está compuesto una campaña de Phishing. Permite establecer los servidores SMTP que se utilizarán para el envío de los correos electrónicos, definición el mensaje con otros elementos como ficheros adjuntos y enlaces que pueden contener sitios clonados, agrupaciones de los correos a los que se van a enviar los mensajes de phishing y un seguimiento completo de cada campaña. Como ocurre con otras herramientas similares a ésta, el objetivo es el de proporcionar un entorno de pruebas para poder evaluar el riesgo de este tipo de ataques en cualquier empresa y no está diseñada para apoyar en las actividades de un ciberdelincuente. Gophish está desarrollado en GO y como muchos otros proyectos que se han ido creado últimamente en este lenguaje, es posible descargar un binario de la herramienta en diferentes sistemas operativos (Windows, Linux y MacOS).
Una vez se ejecuta el binario correspondiente, aparecerá en la terminal el puerto utilizado para la administración web de la herramienta.

El usuario por defecto es «admin» y la contraseña «gophish», sin embargo esto se puede cambiar en la gestión de usuarios de la aplicación. La herramienta se caracteriza por su simplicidad y lo bien diseñada que se encuentra. Las opciones disponibles en el panel lateral izquierdo ayudan a entender el funcionamiento de la herramienta. Probablemente la opción más importante es precisamente la de «Sending Profiles» ya que es ahí donde se definen los detalles de conexión a los servidores SMTP que utilizará GoPhish para el envío de los correos electrónicos. Las demás opciones permiten definir enlaces maliciosos, los mensajes que se van a enviar (con texto, imágenes, enlaces y adjuntos) y los grupos de emails a los que se dirige la campaña. Finalmente, en la opción  «Campaigns» es en donde se configura todo y gracias a un asistente muy simple, es posible seleccionar el servidor SMTP, grupo de emails, el mensaje a utilizar y planificación de la campaña. Una vez  todos los detalles se encuentran definidos y se lanza la campaña, en la opción «Dashboard» se pueden apreciar todos los detalles.

SI bien es cierto que no es una herramienta orientada a MalDocs, es fundamental en la etapa de «Delivery» de dichos documentos, por ese motivo merece la pena mencionarla.

Macros generadas con Unicorn y Macro_Pack

Una vez se tiene planificado cómo enviar el documento malicioso a la víctima, es el momento de prepararlo. Para ello es posible que el mejor enfoque sea crear una muestra maliciosa desde cero y no utilizar herramientas muy extendidas, con esto la rutina maliciosa tendrá mejores capacidades de evasión ante los mecanismos de seguridad implantados en el objetivo. No obstante resulta interesante conocer algunas de las utilidades que se encuentran disponibles para la generación de documentos maliciosos, tales como Unicorn y Macro_Pack.

Unicorn es una herramienta muy simple que se puede dominar rápidamente leyendo la documentación que se encuentra disponible en el repositorio. Los ejemplos que se encuentran descritos en la documentación son los mismos que aparecen cuando se ejecuta el script «unicorn.py» con la opción «–help» y como se puede apreciar, todos ellos están orientados a ataques «client-side». Se puede ver, entre otras cosas, la generación de macros maliciosas que se pueden incrustar en documentos para Microsoft Office y la generación de instrucciones en PowerShell. Es cualquier caso, es posible incluir un payload de Metasploit Framework, Cobalt Strike o una rutina maliciosa personalizada.

Como se puede apreciar, hay un ejemplo para generar una Macro maliciosa en Cobalt Strike y Metasploit Framework. Cuando se ejecuta dicho comando se genera automáticamente un documento «.txt» en el mismo directorio donde se encuentra la herramienta con todo el código de la Macro, el cual ahora basta con incluirlo en un documento de Office y transmitirlo a la víctima. Si el payload utilizado es del tipo «reverse» evidentemente será necesario levantar el «handler» correspondiente en la máquina del atacante (en la misma IP y puerto que se ha indicado en la ejecución de Unicorn».

Una vez que se ejecuta dicho Macro en la máquina de la víctima, se podrá obtener una reverse shell si es este el payload que se ha indicado en la ejecución de Unicorn.

Por otro lado, Macro_pack es una herramienta que si bien está orientada a la generación de MalDocs como Unicorn, funciona de un modo un poco diferente, ya que se encarga de generar directamente el documento partiendo de una macro dada, la cual ha podido ser generada con Metasploit Framework, Cobalt Strike, Empire Framework o incluso manualmente. Una de las características de esta herramienta es que intenta ofuscar algunas de las instrucciones con el fin de mejorar las capacidades de evasión de la muestra maliciosa. Para ello, aplica las técnicas habituales que consisten en la manipulación de los nombres de variables y funciones, cambiar el orden de ciertas instrucciones o definir alias de aquellas funciones que hacen parte de la API de Windows. Si bien hace un par de años las técnicas aplicadas por Macro_pack funcionaban bien para la evasión de AVs en el objetivo, a día de hoy prácticamente cualquier AV es capaz de detectar el código como malicioso.
Para usar Macro_pack basta con descargar el binario (EXE) disponible en el repositorio de GitHub y ejecutarlo indicando la ubicación del código de la macro y el formato que se debe usar.

Como se puede ver, la herramienta ejecuta varias operaciones antes de generar el documento, el cual ahora se puede transmitir a la víctima. Es importante tener en cuenta que la Macro se ejecutará de forma automática si las macros se encuentran habilitadas en el sistema objetivo, por lo tanto es importante tener el «handler» esperando la conexión antes de enviar el documento malicioso.

En el siguiente post se hablará de otras técnicas y herramientas para la generación de documentos maliciosos y ataques client-side.

 

Un saludo y Happy Hack!
Adastra.

Categorías
Explotación de Software Hacking

Post-explotación en sistemas Windows con WinPEAS

Demostración en vídeo del post

Existen varias utilidades y herramientas que ayudan en los procesos de post-explotación en sistemas Windows, la mayoría de ellas permiten detectar malas configuraciones o vulnerabilidades para la elevación de privilegios, otras parten de la base que ya se ha llevado a cabo el proceso de elevación y ahora se pretende ejecutar diferentes tipos de ataques como es el caso de Mimikatz, GhostPack o muchos de los módulos disponibles en Empire Framework, sin embargo hay una herramienta muy potente que si bien se ha mencionado anteriormente en este blog, merece un post dedicado. Se trata de WinPEAS. Es una herramienta que permite detectar vulnerabilidades típicas en sistemas Windows que pueden conducir a la elevación de privilegios y aunque en este post se hablará de esta utilidad, en el repositorio de Carlos Polop hay utilidades que siguen esta misma dinámica para sistemas basados en Linux y MacOS.

USO DE WINPEAS

En primer lugar, se debe obtener el binario correspondiente o bien compilando el proyecto o utilizando el que ya se encuentra disponible en el repositorio, concretamente en este enlace. La forma recomendada de trabajar es descargando la solución .NET del proyecto y compilarla luego con el Visual Studio .NET, así se tendrá la última versión disponible con todos los cambios y mejoras que se hayan subido al repositorio, además, tal como se indica en la documentación, de esta forma también se puede instalar y ejecutar la herramienta DotFuscator que se integra en Visual Studio .NET y permite comprimir un poco más el binario y alterar sus instrucciones. Aunque el objetivo de DotFuscator es el de ocultar el código para que sea más difícil de decompilar y acceder al código fuente del programa, un efecto lateral de esto es que precisamente ayuda un poco en la evasión de sistemas de AV que pueden estar instalados en el sistema comprometido. Es una utilidad que simplemente recibe el ejecutable que se quiere «ofuscar» y realiza el proceso. Para instalar este complemento hay que escribir en la barra de búsqueda de componentes (CTR+Q) «dotfuscator» y seguir el asistente que se enseña. El proceso puede tardar varios minutos pero es muy sencillo.

Una vez instalada la aplicación se puede abrir dirigiéndose a «Herramientas -> PreEmptive Protection – Dotfuscator Community». Y ahora, basta simplemente con seleccionar el binario de WinPEAS, ya sea que se haya compilado desde la solución .NET o se utilice la versión precompilada disponible en el repositorio.
Una vez se tiene el binario es necesario ejecutarlo en el sistema comprometido y para ello, o bien se puede subir a dicho sistema o aplicar alguna técnica del tipo fileless. Independientemente de la técnica utilizada, cuando se ejecuta la herramienta lo primero por lo que destaca es por su orden y limpieza. Se puede ver que tiene un esquema de colores que permite ver rápidamente información útil desde la perspectiva de un atacante o del administrador, así aunque se produzcan cientos de trazas será distinguir aquellas que pueden resultar más interesantes.

Cuando se ejecuta la herramienta sin ningún argumento se aplican todas las pruebas disponibles, lo que significa que el proceso puede tardar varios minutos en completarse. La herramienta cuenta con varias opciones que se indican desde la terminal y que permiten obtener información muy concreta sobre procesos, servicios, aplicaciones instaladas, componentes de red, entorno del sistema entre otras cosas.  Para ver la lista de opciones completa se puede consultar el siguiente enlace o ejecutar la herramienta con el parámetro «help»

Simplemente leyendo los parámetros es fácil entender para qué sirven, además se pueden ejecutar varios al mismo tiempo, de esta manera se puede consultar información de elementos concretos del sistema. Si se pretende guardar toda la información que aporta la herramienta en un fichero de log, tal como se puede ver en el listado de opciones es posible indicar «log=<fichero>» para que toda la información quede guardada en un fichero y no aparezca en la terminal.
Por otro lado, hay dos opciones que resultan especialmente interesantes, la primera es «quiet» que deshabilita el banner que aparece cuando se ejecuta la herramienta y el segundo es «wait», el cual permite ir analizando los resultados aportados por la herramienta paso a paso, es decir, cuando la herramienta termina de ejecutar las pruebas para una categoría concreta, espera a que el usuario indique que quiere continuar con las siguientes pruebas.

Como se puede ver es una herramienta que está bien hecha y que facilita los procesos de post-explotación, especialmente en aquellos en los cuales la cantidad de información obtenida por parte de otras herramientas o manualmente es difícil de manejar y es como «buscar una aguja en un pajar». Precisamente, por ese motivo utilizar WinPEAS es una de las mejores formas de ver qué técnicas se pueden aplicar o qué vulnerabilidades se pueden explotar para elevar privilegios en sistemas Windows.

Un saludo y Happy Hack!
Adastra.