domingo, 27 de febrero de 2022

¿Puedo saber el PIN/patrón de desbloqueo de un Android?

, siempre y cuando sepas dónde mirar

En el caso del PIN de desbloqueo, deberíamos encontrar el hash de dicho PIN y el SALT que se utilizó en el momento de la definición del PIN.

 

El primero se puede encontrar almacenado en: /data/system/password.key, y el segundo se puede encontrar en: /data/system/locksettings.db

 

Para no perder mucho tiempo en la búsqueda del SALT, concretar que  ejecutando la siguiente consulta podríamos obtenerlo rápidamente: SELECT value FROM locksettings WHERE name=”lockscreen.password_salt”

 

En cuanto al patrón de desbloqueo, su hash, en este caso SHA1, se encuentra almacenado en la ubicación: /data/system/gesture.key

Ahora, ¿cómo se obtiene en texto claro el PIN teniendo el hash y el salt?, o, ¿cómo se obtiene el patrón de desbloqueo teniendo el hash?

Fácil, para ello sólo se necesita una herramienta, dicha herramienta se puede encontrar en el recurso: https://github.com/georgenicolaou/androidlockcracker 

 

Pero, pongamos un par de ejemplos:

 

Ejemplo 1.- Averiguar el PIN de desbloqueo a partir del Hash + SALT

Para ello tenemos los siguientes datos:

Hash del PIN: 1136656D5C6718C1DEFC71B431B2CB5652A8AD550E20BDCF52B00002C8DF35C963B71298
Salt: 3582477098377895419

Ahora sólo nos queda ejecutar la herramienta comentada anteriormente:


Leyenda:

Recuadro naranja: hash del PIN

Recuadro rojo:        salt

Recuadro verde:     contraseña

 

Ejemplo 2.- Averiguar el patrón de desbloqueo

Para ello tenemos el siguiente dato:

Hash del patrón: 82790AD0ADEB07AC2A78AC07038BC93A26691F12

Ahora sólo nos queda ejecutar la herramienta comentada anteriormente:

 

Leyenda:

Recuadro rojo:        salt

Recuadro verde:     números con los que se forma el patrón.

 

Para PINES más complicados, la herramienta tiene la posibilidad de utilizar diccionarios o añadir otros juegos de caracteres además de los numéricos, que es el tipo de caracteres utilizados si no se indica nada.

 

 

En cualquier caso

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

 

 

viernes, 31 de diciembre de 2021

Reto Forense - HTB: EMO

 

Abrimos el archivo comprimido que nos hemos descargado, y vemos que contiene un archivo de tipo ofimático.

Pues como ya comente en alguna otra entrada que no recuerdo, suelo seguir los siguientes pasos:

1.- Abrir el archivo ofimático con un gestor de archivos comprimidos, como por ejemplo: winrar, con lo que analizo la estructura interna del fichero. Aunque en muchos casos la información obtenida no es muy prometedora.

2.- Abrir el documento, y comprobar si el documento tiene macros. Es fácil, si el gestor de archivos ofimáticos con el que abramos el documento no sugiere activar las macros, es que obviamente hay macros dentro del documento.

Si tenemos macros, sugiero la modificación de la/s susodicha/s para así poder analizar el código y, si se considera, ejecutar la macro paso a paso.

En este caso, la macro solicita una contraseña para poder acceder a su contenido, por lo tanto, estamos en vía muerta

3.- Usar la herramienta: oledump, de Didier Steven, para analizar el contenido. Si el contenido tuviera macros, las detectaría e incluso podría extraerlas para su posterior análisis.

 

Para el archivo ofimático que estamos analizado se ha hecho se ha seguido este último punto. Pero tras analizar el archivo, se ha podido ver que el cogollo del asunto reside en alguna variable/propiedad definida dentro del documento, por lo que sin ese contenido, la ejecución que hagamos resulta ineficaz

Por este motivo, pasamos a ejecutar el archivo, teniendo el programa visor de procesos: Process Explorer.exe , en ejecución.

Pues bien, uno de los procesos que se crean y que son hijos del archivo ofimático, es un proceso de PowerShell que si pausamos, podemos ver el comando que se ejecuta… o eso creía

 


Como se ve, el comando a ejecutar viene codificado en base64, pero el problema no es ese, el problema es que no es posible copiar todo el mensaje codificado para decodificarlo. Los campos de texto en Visual Basic tienen limitado en número de caracteres.

¿Y ahora qué?... Pues hay varias opciones:

1.- Un dumpeo de la memoria del proceso anterior, mediante el propio programa: Process Explorer

Para ello sólo tenemos que botón derecho sobre nuestro proceso de PowerShell parado y seleccionar: Create Dump > Create Full Dump > Seleccionar ubicación y nombre del archivo.

 


Ahora ya sólo nos queda abrir un editor hexadecimal y buscar por alguna parte el código en base64 encontrado anteriormente.

 

2.- Si hemos instalado antes de la ejecución la herramienta Sysmon, podemos visualizar dentro de Visor de Procesos los eventos con ID 1.

Pues para eso nos vamos al visor de eventos y buscamos: Registros de aplicaciones y servicios > Microsoft > Windows > Sysmon > Operational.

Tras unos minutos buscando, llegamos hasta el premio.

 


Bueno, tras extraer nuestra preciada materia prima, procedemos a decodificar y obtenemos nuestro ansiado código fuente:


Lo primero que llama la atención es una parte del código en dónde se utiliza la función: downloadfile, que creo que no hace falta explicar lo que hace. Se extraen las distintas URLs que contiene el código pero, ni sus visitas ni la estructura de las URLs nos facilita pistas.

Por lo tanto, nos toma ahondar en el código de nuevo.

Revisandolo vemos que hay una condición que nunca se dará y que depende de la descarga de un archivo desde cualquiera de las anteriores URL. Pero qué ocurre si comentamos dicha condición.


Pues que tras la ejecución del código vemos que se ha creado la estructura de directorio: Jrbevk4/Ccwr_2h. Y que dentro aparece un archivo de nombre: Ale7g_8.conf, que contiene el siguiente texto en base64


Al intentar decodificarlo no obtenemos ningún texto legible, pero eso es porque hay que fijarse en un parte del código que a primera vista se me paso desapercibida. La puedes ver a continuación

 


Ok, pues apliquemos la función XOR con clave: 0xdf, a texto codificación en base64.

 


 

¡Perfecto!, hemos obtenido nuestro premio.

En cualquier caso

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

 

 

domingo, 31 de octubre de 2021

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óna 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

 

viernes, 3 de septiembre de 2021

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