Cuadernos de campo: NFS - Impersonalización

Tras comprobar que una máquina trabaja con el protocolo NFS

Escaneo de nuestro objetivo

Hay que comprobar si podríamos conectarnos a los recursos compartidos, para lo cual podemos ejecutar el comando: showmount –e <maquina>.

Resultado de la ejecución del comando: showmount

El asterisco muestra que podríamos conectarnos sin mayores problemas, por lo tanto estamos ante un sistema que implementa la autenticación NFS: UNIX o AUTH_SYS. Cuando se usa la autenticación UNIX, un servidor NFS autentica una solicitud de archivo al autenticar la computadora que realiza la solicitud, pero no al usuario. Por lo tanto, un usuario cliente puede ejecutar el comando: su, y hacerse pasar por el propietario de un archivo. Si se utiliza la autenticación DH, el servidor NFS autentica al usuario, lo que hace que este tipo de suplantación sea mucho más difícil.

NOTA: Existen otros métodos de autenticación más fuertes, como AUTH_DH.

Más información: https://docs.oracle.com/cd/E19683-01/806-4076/rfsrefer-58/index.html

 

Acceso a un recurso compartido para cuyo contenido no tenemos acceso

Para suplantar al usuario (impersonalización) que si tiene permisos sobre los documentos vistos en el recurso, tenemos que:

1.- Averiguar el UID del usuario, para ello sólo tenemos que ejecutar el comando: ls –ld <recurso compartido>

 

Identificamos el UID del usuario con permisos totales para el recurso compartido

2.- Creamos un usuario en nuestro entorno y le otorgamos el SID y el GID encontrado anteriormente. Para ello podemos utilizar los comandos: useradd (crear usuario), usermod (otorgar SID al usuario creado anteriormente) y groupmod (otorgar GID al usuario creado anteriormente)

Creación de usuario y cambio de UID y GID

 

Comprobación del cambio realizado anteriormente

3.- No hacemos pasar por el nuevo usuario creado y accedemos al recurso

Cambio de usuario y acceso al recurso compartido con permisos totales

 

En cualquier caso

Lo que hagas con la información es cosa tuya, no mía... pero ten conciencia

 

Cuadernos de campo: ¿Qué es un archivo con extensión PFX?

 

¿Qué es un archivo con extensión PFX?

 

Un archivo con la extensión PFX es un certificado en formato PKCS#12.

En dicho certificado se encuentra guardado el certificado, el certificado intermedio de la autoridad necesario para una credibilidad del certificado y la clave privada para el certificado. Es decir, puedes imaginarte dicho certificado como un archivo con clave de acceso en el que está guardado todo lo que necesita para instalar el certificado o como una copia de seguridad de un certificado con clave privada de acceso (exportado desde Internet Explorer).

Importante, el archivo PFX está siempre protegido con una contraseña

NOTA:   ¿Cuándo se necesita crear un archivo PFX?

                Sobre todo de las siguientes situaciones:

  

·       Cuando instalamos el certificado en Windows Server (IIS) pero CSR request no fue creado en ISS.

·       Cuando se necesita el certificado para Windows Server pero no disponemos de IIS para generar CSR.

·     Cuando hemos creado CSR y guardado la clave privada, y necesitamos instalar el certificado en Windows Server.

·       Cuando tenemos el certificado Code Signing y necesitamos PFX para firmar.

 

 

¿Es posible averiguar la contraseña del certificado PFX?

 

Si, para ello podemos entre varias cosas realizar un ataque de diccionario con la herramienta: John The Ripper.

Para esto lo primero es preparar el archivo .PFX para que John lo entienda

Y ahora, dejamos que John haga su trabajo

Ahora que ya tenemos la contraseña del certificado, podemos extraer su contenido, para lo cual podemos seguir las indicaciones dadas en el siguiente enlace:

 https[:]//www.ibm.com/docs/en/arl/9.7?topic=certification-extracting-certificate-keys-from-pfx-file

Es decir:

1.- Extraemos la clave privada del certificado contenido en el archivo PFX (sin crackear)

 

NOTA: incluimos la opción: -nodes, la cual indica que no sé solicitará contraseñas de protección

Ahora, para poder manejar la clave privada en conjunción con el certificado, debemos quitarle la información inútil a la clave del mismo, es decir, debemos quitar los atributos que se muestran a continuación remarcados en rojo:

 

Para ello podemos eliminar dicha información del archivo o ejecutar el siguiente comando:

 

 

Con lo que ya nos habremos quitado la información inútil y podremos utilizar dicha clave sin necesidad de crackearla

2.- Extraemos el certificado contenido en el archivo PFX

A partir de aquí ya podremos utilizar el certificado y la clave del mismo, sin haberla crackeado,  para lo que se pueda, como por ejemplo: intentar conectarnos al servicio SSH con el certificado extraído.

 

En cualquier caso

Lo que hagas con la información es cosa tuya, no mía... pero ten conciencia

 

A la suite root mi querido eval()

 

En una máquina de HTB, en la fase de la escalada de privilegios me encontré un código en python que trabaja con la función: eval(), y que podían ser ejecutado como root.

Dicha función “eval()” sin entrar en definiciones académicas, evaluará el contenido de lo pasado, es decir, ejecutará lo que se le pase como parámetro.

Un ejemplo sencillo:

¡Ejecuta la suma!

Pero… ¿evalúa comparaciones?

¡Pues parece que sí!

Y si… ¿a la función “eval()” le metemos código de python?, ¿probamos a importar la librería “os”?

NOTA: la intención de solicitar una shell de bash.

¡Vaya!, no ha funcionado pero… no ha funcionado porque la sintaxis no es la correcta, no porque no se pueda.

 

La forma correcta de importar un librería cuando utilizamos la función: eval(), es: __import__(‘<librería>’)

Comprobemos:

 

 

¡Perfecto!, ahora ya sólo nos queda solicitar nuestra nueva shell de bash

¡¡Conseguido!!

Ok, probemos ahora a simular lo comentado antes, lo recordamos, ejecutamos un código de python con permisos elevados gracias a sudo.

¡¡Ahí esta!!

Como  conclusión… a la hora de programar cuidado con lo que se hace, pero a la hora de elevar privilegios nunca te olvides de nuestro querido ascensorista.

 

En cualquier caso

Lo que hagas con la información es cosa tuya, no mía... pero ten conciencia

 

Silver Ticket Attack

¿Qué es?

Este ataque se basa en construir un TGS (ticket Kerberos) válido para un servicio, una vez se ha obtenido el hash NTLM del propietario del susodicho servicio. De esta manera, es posible acceder a este servicio con un TGS personalizado que contenga los más elevados privilegios.

Ejemplo de este tipo de ataque

El siguiente ejemplo parte de una máquina de HTB (intelligence).

Paso 1.

Tenemos un usuario y su hash NTLMv2, que incluso ha sido posible crackear, pero esto último no es relevante en este caso.

Hash NTLMv2 del usuario Ted.Graves

Paso 2.

Comprobamos si existe algún servicio sobre el cual el usuario sea propietario.

Para comprobar esto se utilizará la herramienta: gMSADumper (https://github.com/micahvandeusen/gMSADumper), ya que la herramienta “impacket”, no trae ninguna herramienta para hacer esto. Al menos hasta dónde mi conocimiento llega.

***** NOTA: *****

Esta herramienta, busca Group Managed Service Accounts (gMSA), pero, ¿qué son?

Los gMSAs son cuentas de servicio que ofrecen una manera segura para ejecutar aplicaciones, servicios y tareas de manera automatizada. Fueron introducidas en Windows Server 2016 pero pueden ser aprovechadas en Windows Server 2012 y versiones anteriores

Las características de estas cuentas son que las contraseñas de las mismas son generadas aleatoriamente, cambian automáticamente y no es necesario que ningún usuario las conozca. Además, estas cuentas de servicio son “instaladas” únicamente en el servidor (por lo tanto será necesario utilizar una cuenta de máquina) que solicitara su uso al AD en tiempo de ejecución. Por lo dicho,

Las  gMSAs son un tipo específico de objeto dentro de Active Directory, concretamente: msDS-GroupManagedServiceAccount. Dentro de este objeto, la propiedad/atributo más importante es: msDS-ManagedPassword, este atributo contiene un BLOB con información de la contraseña actual

Bibliografía:

·         https://stealthbits.com/blog/what-are-group-managed-service-accounts-gmsa/

********************

El uso de la herramienta nos devuelve el siguiente dato:

Es decir, existe un servicio sobre el que el usuario Ted.Graves, tiene permisos.

Paso 3.

Procedemos a utilizar la herramienta de impacket: getST, para generar un ticket de servicio que nos permita elevar permisos sobre la máquina.

El resultado es:

Es decir, tenemos un problema de fecha/hora.

***** NOTA: *****

En un entorno de AD, es muy importante tener la hora sincronizada con el controlador de dominio, ya que Kerberos no funciona correctamente si la fecha y hora de nuestro equipo no va acorde con la fecha y hora del controlador de dominio/servidor

Para mejorar esto, necesitamos configurar el servicio NTP de nuestra máquina para que utilice el servidor NTP del servidor y así corregir el problema

Si tuvieras algún problema con ello, se recomienda seguir las siguientes instrucciones

********************

Repetimos la solicitud para generar un ticket de servicio, y conseguimos nuestro objetivo

Ahora sólo queda utilizar el ticket generado mediante Pass-The-Ticket

 

En cualquier caso

Lo que hagas con la información es cosa tuya, no mía... pero ten conciencia