Object
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
Object es una máquina Windows que ejecuta el servidor de automatización Jenkins. Se descubre que el servidor de automatización tiene habilitado el registro y el usuario registrado puede crear compilaciones. Las compilaciones se pueden activar de forma remota configurando un token de API. El punto de apoyo se obtiene descifrando los secretos de Jenkins. Se descubre que el usuario de punto de apoyo tiene permisos ForceChangePassword en otro usuario llamado smith. Este abuso de privilegio nos permite obtener acceso a smith. smith tiene permisos GenericWrite en maria. Abusar de este privilegio nos permite obtener acceso al servidor como este usuario. maria tiene permisos WriteOwner en el grupo Domain Admins, cuyos privilegios explotamos para obtener un shell SYSTEM.
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Object.
Lanzaremos scripts de reconocimiento sobre el puerto encontrado y lo exportaremos en formato oN y oX.
Transformaremos el archivo XML obtenido en el resultado de nmap y lo transformaremos en un archivo HTML. Levantaremos un servidor HTTP con Python3.
Debido que no disponemos de ningún puerto como SMB, LDAP para enumerar al equipo y ver si se trata de un Domain Controller o de un equipo cliente de un dominio, a través de netexec haremos la validación sobre WinRM que hemos comprobado que estaba expuesto (puerto 5985).
Procederemos a añadir las entradas en nuestro archivo /etc/hosts
Procederemos a realizar una enumeración de las páginas webs que hemos encontrado expuestas (8o y 8080).
Probaremos de aplicar Virtual Hosting para verificar si los sitios webs son diferentes accediendo directamente desde la dirección IP o el nombre DNS, en este caso no se aplica Virtual Hosting.
A través de la herramienta de whatweb revisaremos las tecnologías que utilizan estas páginas web.
Jenkins es una herramienta de integración continua y entrega continua (CI/CD) utilizada en el desarrollo de software para automatizar la construcción, prueba y despliegue de aplicaciones. Es de código abierto y permite a los desarrolladores implementar proyectos de manera más rápida y confiable mediante la automatización de procesos repetitivos.
Probaremos de autenticarnos con credenciales por defecto sin éxito ninguno.
Revisamos en Internet y verificamos de las credenciales por defecto de Jenkins, pero tampoco nos permite acceder.
Verificamos que tenemos una opción para crear una nueva cuenta en Jenkins. Procederemos a crearnos una cuenta.
Verificamos que hemos ganado acceso al panel de Jenkins con el usuario recién creado, el siguiente paso será enumerar Jenkins en busca de información relevante.
Revisando el apartado de "People" vemos que aparece nuestro usuario recién creado y el del usuario "admin".
Volviendo al panel de Dashboard, vemos que podemos crear una nueva tarea en Jenkins.
Al intentar crear una nueva tarea, nos permite seleccionar diferentes modos. En nuestro caso, probaremos con la primera opción de "Freestyle project" y le asignaremos de nombre al trabajo "test".
Comprobamos que estas son las opciones que nos proporciona Jenkins para la creación de un nuevo trabajo.
Verificamos que en el apartado de "Build", nos aparece una serie de opciones la cual la que nos parece más interesante es la de "Execute Windows batch command", ya que parece ser que a través de la creación de la tarea en Jenkins, podríamos llegar a indicar alguna instrucción para que sea ejecutada en la máquina víctima.
Indicaremos en el apartado de "command" que nos ejecute la siguiente instrucción para verificar posteriormente en el resultado del output si se ha logrado ejecutar el comando indicado.
Una vez configurado, procederemos a guardar el trabajo dándole a "Save"
Revisamos que efectivamente el proyecto se ha creado correctamente, pero no nos aparece ninguna opción/botón para iniciar el trabajo.
Existen dos métodos para intentar evitar esta restricción e iniciar el proyecto de otra manera.
La primera opción para que el proyecto se ejecute sin tener que nosotros darle al botón de "Build", es a través de Cron Jobs.
A la hora de crear la tarea, en el apartado de "Build Triggers", nos permite la opción de seleccionar "Build periodically" para que se ejecute el trabajo de manera periódica.
Por lo tanto, nuestro objetivo es que se ejecute para verificar si la instrucción es ejecutada en el equipo. Para ello, especificaremos que se ejecute a cada minuto indicando: * * * * *
Al pasar el minuto después de haber guardado nuevamente el proyecto con la tarea programada, verificamos que se ha ejecutado correctamente el trabajo.
La mejor manera para eludior la restricción del permiso por el cual no tengamos disponible el botón "Build" para iniciar el proyecto, es a través de la opción "Authentication Token".
Tal y como indica Jenkins, podemos crear un nuevo Token el cual al acceder a JENKINS_URL/job/test/build=token=TOKEN_NAME, el proyecto se ejecutará.
Por lo tanto, el objetivo es utilizar la herramienta de cURL para hacer la petición a través de GET para que el proyecto sea ejecutado remotamente y nosotros podamos controlar cuando ejecutar el proyecto.
Esto es más práctico que la primera opción, debido que podemos controlar cuando ejecutarlo, etc.
Verificamos que al tratar de hacer el cURL tal y como nos indicaba Jenkins, nos aparece el mensaje de "Authenticacion required".
Cargaremos una nueva instrucción en el proyecto, en este caso para que se ejecute un "ipconfig".
Realizaremos el build de nuestro proyecto remotamente con nuestro usuario, el token de nuestro usuario que hemos generado y el token creado el proyecto.
Por lo tanto, el método para ejecutar los comandos de manera más eficiente será modificar y guardar el proyecto para que ejecute el comando que establezcamos, enviaremos la solicitud del build remoto con cURL e iremos ingresando incrementando el número del build por cada vez que enviemos el proyecto para visualziar el resultado.
Probaremos de compartirnos el binario de "nc.exe" para posteriormente entablarnos una Reverse Shell hacía el equipo.
Modificaremos el proyecto para que ejecute el siguiente comando, para descargarnos el binario de nc.exe que estamos compartiendo desde nuestro servidor web de Kali.
Verificamos que en el output de la salida de la ejecución del comando, nos devuelve error de conexión "Unable to connect to the remote server", lo cual nos hace pensar que hay algunas reglas de Firewall que nos están bloqueando la salida cualquier tráfico en el equipo.
A través del siguiente comando, listamos las reglas del firewall que bloquean el tráfico saliente y que están habilitadas. Esto nos permite identificar las restricciones que están configuradas para el tráfico hacia el exterior, ayudándonos a comprender mejor cómo se gestionan las conexiones salientes en el sistema.
Verificamos que el resultado obtenido en el output nos indica que existe una regla de Firewall llamada "BlockOutboundDC" que no permite la salida de tráfico hacia el exterior, por ese motivo nos rechazaba la conexión anteriormente.
El siguiente comando que ejecutamos está diseñado para listar las reglas del firewall que bloquean el tráfico saliente, mostrando detalles adicionales como el protocolo, puertos locales y remotos, direcciones remotas y otros atributos. Si en los campos como LocalPort, RemotePort o RemoteAddress aparece "Any", esto indica que la regla no está restringida a un puerto o dirección específica, sino que aplica a todo el tráfico saliente que cumpla con las condiciones básicas de la regla (en este caso, dirección Outbound y acción Block).
Esto significa que esas reglas están configuradas para bloquear cualquier tráfico saliente sin discriminar por puerto o dirección, lo que puede implicar restricciones muy amplias en el sistema.
A través del siguiente comando, enumeramos todas las reglas de Firewall que estén configuradas para permitir el tráfico saliente (Outbound), que se encuentren habilitadas y cuya acción sea permitir (Allow).
En el resultado obtenido, verificamos que existe una regla configurada para permitir tráfico ICMP hacia el exterior (Outbound).
Configuraremos el proyecto para que ejecute el comando ping hacia nuestra Kali y con tcpdump procederemos a revisar si recibimos los paquetes ICMP.
Buscando vías potenciales para obtener más privilegios o nuevas credenciales, debido que nos encontramos en un Jenkins, lo que pensamos es en intentar dumpear las credenciales almacenadas y posteriormente desencriptarlas.
Dado que nos encontramos en la ruta C:\Users\oliver\AppData\Local\Jenkins\.jenkins\workspace\test procederemos a listar dos directorios anteriores para ver qué contenido dispone.
En el output mostrado, verificamos que nos aparece los directorios "users" y "secrets" los cuales necesitaremos para intentar buscar los archivos correspondientes para desencriptar la contraseña de Jenkins del usuario "admin".
Al revisar el directorio /users verificamos que nos aparecen dos usuarios creados, el del "admin" y el que hemos creado anteriormente. El usuario que nos interesa obtener su "config.xml" es el del usuario "admin".
Al acceder al directorio /users/admin_17207690984073220035 verificamos que vemos el archivo que necesitamos "config.xml".
Procederemos a verificar el contenido del archivo "config.xml" a través del siguiente comando.
Guardaremos el contenido del archivo de manera local en nuestra Kali.
A continuación, procederemos a listar el directorio /secrets y comprobamos que disponemos del archivo "hudson.util.Secret" y "master.key" necesarios para la desencriptación de la contraseña de Jenkins del usuario "admin".
Listaremos el contenido del archivo "master.key" a través de la siguiente instrucción.
Copiaremos el contenido para obtener el archivo de manera local en nuestra Kali, eliminaremos cualquier salto de línea innecesario y verificaremos que disponemos del contenido del archivo "master.key" de manera local.
Procederemos a intentar comprobar el contenido del archivo "hudson.util.Secret" y al intentar listarlo con "cat", nos aparecen caracteres ilegibles, lo cual parece indicar que el archivo se trata de un binario, por lo tanto, a través de un "cat" no se puede llegar a comprobar su contenido.
Por lo tanto, lo que realizaremos es mostrar el contenido del archivo pero codificado en Base64 para posteriormente descodificarlo en nuestro equipo local.
Procederemos a descodificar y a almacenarlo en un archivo local llamado "hudson.util.Secret".
Nos descargaremos el binario en nuestra Kali a través del siguiente comando.
Al ejecutar el binario, comprobaremos la sintaxis para el uso de la herramienta.
Al intentar desencriptar la contraseña del usuario "admin" de Jenkins a través de la herramienta Jenkins Credentials Decryptor con los tres archivos obtenidos, comprobamos que nos muestra la contraseña del usuario "oliver" en texto plano.
Intentaremos verificar con netexec si este usuario es válido para acceder al WinRM con las credenciales encontradas y verificamos que si.
Accederemos al WinRM a través de evil-winrm y verificaremos que obtenemos la flag del user.txt.
Una vez ganado acceso al equipo, deberemos de buscar maneras para elevar nuestros privilegios y convertirnos finalmente en Domain Admins.
Verificaremos los permisos que disponemos y a qué grupos forma parte el usuario (oliver@object.local), no vemos ningún permiso ni grupo que podamos realizar un PrivEsc.
Ingresaremos al directorio C:\Users\ y comprobaremos que aparecen los siguientes usuarios.
Verificaremos puertos abiertos en la máquina en busca de alguno sospechoso, en este caso, no encontramos nada relevante.
Listaremos los directorios de Program Files en busca de algún programa inusual, en este caso, tampoco encontramos nada relevante.
Enumeramos los usuarios del dominio y los grupos del dominio, pero tampoco podemos sacar nada más relevante para realizar un PrivEsc.
Debido que enumerando manualmente no hemos podido lograr encontrar ninguna vía potencial para elevar nuestro privilegio, lo que realizaremos es realizar la enumeración a través del Collector de SharpHound para posteriormente subir el .zip en el BloodHound en busca de buscar vías potenciales para elevar nuestros privilegios.
Lo primero será subir el binario de SharpHound a través del comando "upload" y posteriormente procederemos a descargar el comprimido obtenido para obtenerlo en nuestro equipo local a través del comando "download" que nos ofrece evil-winrm.
Enumerando desde BloodHound, verificamos que el único usuario Domain Admin del dominio es el mismo usuario Administrator.
Buscando una vía potencial para elevar nuestros privilegios para convertirnos en Domain Admins, nos encontramos con la siguiente ruta la cual parecee ser la más adecuada.
A través del usuario que disponemos actualmente (oliver@object.local), disponemos de permisos de ForceChangePassword sobre el usuario (smith@object.local).
Revisando la información del permiso en Bloodhound, nos informa que el usuario que disponemos actualmente tiene la capacidad de modificarle la contraseña al usuario sobre el cual tenemos permisos sin conocer la contraseña actual de este último.
Dado que nos encontramos en el mismo equipo Windows, procederemos a realizar el apartao de "Windows Abuse".
Para realizar esta explotación, necesitaremos disponer de PowerView en el equipo víctima.
Al tratar de importarlo en memoria con IEX, verificamos que nos aparece el error de "Unable to connect to the remote server" debido a las reglas de Firewall que no permite el tráfico saliente tal como enumeramos anteriormente.
Por lo tanto, procederemos a subir a través del comando "upload" el archivo PowerView.ps1 y lo importaremos en el equipo.
A través de la variable $UserPassword crearemos una SecureString de la contraseña que le asignaremos al usuario (smith@object.local).
Mediante la función Set-DomainUserPassword procederemos a cambiarle la contraseña al usuario (smith).
Verificaremos a través de netexec de que las credenciales se han modificado correctamente y también procederemos a conectarnos al WinRM con estas nuevas credenciales obtenidas.
Volviendo a enumerar desde BloodHound, verificamos que el usuario que disponemos actualmente (smith@object.local) dispone de privilegios GenericWrite sobre el usuario (maria@object.local).
Revisando la información sobre el permiso que nos indica BloodHound, verificamos que este acceso otorga la capacidad de escribir en cualquier atributo no protegido en el objeto de destino, incluidos los "miembros" de un grupo y los servicePrincipalName de un usuario.
Lo que podemos pensar en realizar es un ataque llamado Targeted Kerberoasting desde Windows.
Este ataque lo que realiza es agregar un SPN (Service Principal Name) ficticio a una cuenta. Una vez que la cuenta tenga establecido el SPN, la cuenta se vuelve vulnerable al ataque de Kerberoasting. Lo cual posteriormente podemos obtener el TGS (Ticket Granting Service), es decir un hash que posteriormente podemos intentar crackear de manera offline.
En este caso, el ataque se realiza Set-DomainObject y Get-DomainSPNTicket.
Probando de realizar el Targeted Kerberoast, nos aparece un error de Kerberos, lo cual no nos permite realizar dicho ataque.
Este permiso permite a un atacante modificar las propiedades de un usuario. Un atacante puede llegar a cambiar la ruta del script de inicio de sesión (Script Path Logon) de un usuario para ejecutar un script malicioso al iniciar sesión.
En este caso, lo que realizaremos es crear un script (.ps1) que contenga la instrucción de listar el contenido del directorio C:\Users\Maria\Desktop y lo almacene el resultado en el directorio que estamos actualmente en el archivo "output.txt".
Este script le asignaremos de nombre "test.ps1", una vez creado el script, procederemos a asignarle el script en la ruta de inicio de sesión del usuarioo, para que cuando el usuario acceda al equipo, se ejecute el script.
Verificamos que el contenido obtenido nos muestra que la usuaria dispone de un Excel (Engines.xls) en el directorio Desktop de su usuario.
Una vez sepamos que existe este archivo en el directorio C:\Users\Maria\Desktop. El siguiente paso será realizar una copia de ese archivo al directorio en el que nos encontramos actualmente.
Para ello modificaremos de nuevo el script anterior "test.ps1" e indicaremos que realice la copia del archivo a nuestro directorio actual.
Al volver a comprobar el directorio actual, verificamos que se nos ha copiado correctamente el archivo "Engines.xls" que procederemos a descargarnos a nuestra Kali.
Verificaremos que se nos ha descargado correcamente el archivo en nuestro equipo local. Procederemos a abrirlo a través de LibreOffice.
Al abrir el Excel descargado,verificamos que dispone de credenciales de diferentes sitios sobre la usuaria (maria@object.local).
Guardaremos las credenciales en el archivo "passwords.txt".
Proabremos de validar si alguna de las credenciales obtenidas es válida para la usuaria, una vez verificado, procederemos a conectarnos al WinRM a través de evil-winrm.
Al volver a enumerar desde BloodHound, verificamos que el usuario que disponemos actualmente (maria@object.local) dispone de privilegios de WriteOwner sobre el grupo (Domain Admins@object.local).
Revisando la información proporcionada por BloodHound sobre el privilegio en cuestión, observamos que el permiso WriteOwner sobre un grupo permite a un atacante modificar el propietario del mismo, lo que le otorga la capacidad de tomar control total sobre dicho grupo.
Al cambiar el propietario a su propia cuenta, el atacante podría manipular el grupo de diversas formas, como agregar o quitar miembros, modificar permisos o incluso utilizar el grupo para obtener privilegios más altos dentro del dominio.
Utilizamos el comando Set-DomainObjectOwner para transferir la propiedad del grupo a "maria", lo que nos permitió cambiar cualquier aspecto del grupo, incluidos sus miembros y permisos.
A continuación, utilizamos Add-DomainObjectAcl para otorgar a "maria" permisos completos sobre el grupo y, con Add-DomainGroupMember, la agregamos como miembro del grupo Domain Admins, asegurando su acceso a privilegios de administrador en el dominio.
Finalmente, verificamos la pertenencia de "maria" al grupo mediante el comando net user /domain, confirmando su escalada de privilegios y control completo sobre el dominio.
Volveremos a iniciar una nueva sesión de WinRM a través de evil-winrm para que se apliquen los cambios en la nueva sesión.
Una vez ganado el acceso, verificaremos que podemos eumerar el contenido de la flag root.txt.
Accederemos a y comprobaremos el resultado en un formato más cómodo para su análisis.
Procederemos a acceder a y verificaremos que se trata de un sitio web sobre Jenkins.
Si probamos de acceder a comprobamos que no disponemos de permisos de Administración.
Revisando en la siguiente respuesta de , nos indica que posiblemente sea debido a la restricción de permisos que dispone nuestro usuario creado.
Al acceder a , verificamos que efectivamente el comando que habíamos establecido se ha ejecutado en el servidor . Tambén hemos podido ejecutarlo sin tener que arrancar el proyecto de manera manual (debido a los permisos) a través de las tareas Cron.
Revisando en Internet sobre este mensaje de error para ejecutar el proyecto de manera remota de Jenkins, nos encontramos con el siguiente post donde explican como realizar la configuración con cURL.
El primer paso es obtener un API Token de nuestro propio usuario, para ello accederemos a y generaremos un nuevo Token que deberemos copiarnos en el portapapeles.
Verificaremos que si accedemos nuevamente a verificaremos que el proyecto se ha ejecutado y hemos recibido el output de la ejecución del comando "ipconfig".
Para ello utilizamos la siguiente guía en la cual nos explicaba paso por paso como realizar este dump de las credenciales de Jenkins.
Una vez obtenido los 3 archivos necesarios para desencriptar la contraseña del usuario "admin" de Jenkins, procederemos a utilizar la siguiente herramienta -->
En el siguiente GitHub () nos informa como realizar este tipo de ataque desde Windows.
Debido que no hemos podido realizar el ataque, desde revisamos el ACL de GenericWrite on User en busca de intentar realizar otro tipo de ataque.
