22 junio, 2022

Segundo factor de autenticación 2FA en conexiones SSH

Implementar un segundo factor de autenticación 2FA en servicios SSH sin duda es una muy buena opción de seguridad no solo para servidores expuestos a internet sino para aquellos usuarios que pueden elevarse a un contexto privilegiado de sudo y servidores críticos en una red interna corporativa. 

Con este mecanismo de autenticación en dos pasos se estaría reduciendo en gran medida la superficie de ataque de los vectores de entrada a estos sistemas por parte de un posible atacante.

Implementación 2FA en SSH (Google Authenticator)

Instalar el paquete del módulo PAM para 2FA libpam-google-authenticator de Google Authenticator, también se instalará el paquete libqrencode4 que permite generar códigos QR en la propia terminal. 

sudo apt install libpam-google-authenticator -y

Configurar SSH para que haga uso de este módulo PAM. Añadir la siguiente línea en el fichero /etc/pam.d/sshd.

auth required pam_google_authenticator.so

Habilitar esta configuración el fichero de configuración del servicio de SSH /etc/ssh/sshd_config. Añadimos o modificamos si ya existe la siguiente política a un valor "yes".

ChallengeResponseAuthentication yes

Reiniciamos el servicio sshd para aplicar los cambios realizados en el servicio de SSH.

sudo systemctl restart sshd

Finalmente vinculamos la cuenta de usuario en la que queremos habilitar 2FA. Se nos mostrará un código QR el cual debemos vincular con nuestra App de doble factor, ya sea Google Authenticator u otra que utilicemos para generar códigos de un solo uso basado en tiempo TOTP.

google-authenticator

Se lanzará el asistente de configuración donde asociaremos la clave secreta con nuestra App de segundo factor. También se generarán "5 códigos de emergencia de un solo uso" los cuales los almacenaremos de forma segura en caso de perder el acceso a nuestra App de TOTP instalada en un dispositivo físico.

Figura 1: Creación de código QR - Asistente de vinculación para habilitar 2FA. 

Una vez finalizado el asistente de vinculación. Si nos intentamos autenticar en el servidor nos solicitará la contraseña de usuario y un código de verificación TOTP.

Figura 2: Verificación del uso de 2FA en la autenticación SSH al servidor. 

En este caso se ha vinculado con la App de Google Authenticator donde cada 30 segundos se generará un nuevo código TOTP. 

Figura 3: Código TOTP en la App de Google Authenticator.

Aclarar que aunque tengamos la política de "PasswordAuthentication no" establecida en nuestro fichero de servicio SSH al implementar 2FA será ignorada y será exigido introducir la contraseña de usuario para autenticarse en el servidor.

Paranoid Mode 3FA: Combinar autenticación SSH Public Key + Password + TOTP 

¿Qué pasa si previamente tenemos configurado una autenticación de clave pública en nuestro servicio de conexión SSH hacia el servidor y añadimos 2FA TOTP?

Si ya tenemos configurado un tipo de autenticación asimétrico de clave pública y añadimos un segundo factor bastado en TOTP a priori con esta configuración actual, no nos funcionará.

Si queremos combinar un tipo de factor TOTP junto con nuestra autenticación de clave pública en SSH debemos añadir la siguiente política en el fichero de configuración del servicio de SSH /etc/ssh/sshd_config

AuthenticationMethods publickey,keyboard-interactive

Reiniciamos el servicio SSH para aplicar los cambios.

sudo systemctl restart sshd

De este modo cuando nos conectamos al servidor SSH no solo estaremos combinando SSH Public Key y TOTP sino que también debemos introducir la contraseña de usuario. Por lo que estaremos usando tres factores de autenticación (3FA) para acceder al servidor vía SSH.

  • Autenticación con clave pública/privada.
  • Autenticación password de la cuenta de usuario.
  • Autenticación con código de verificación TOTP.
Aunque en el fichero de configuración del servicio SSH tengamos establecida la política "PasswordAuthentication no" al combinarla con "keyboard-interactive" nos obligará a introducir la password de la cuenta de usuario con el que nos autenticamos.

Figura 4: Verificación del uso de 3FA en la autenticación SSH al servidor.

Si en la máquina servidor disponemos de más usuarios que necesiten autenticarse vía SSH y por el momento estos usuarios aún no han configurado 2FA para sus cuentas o simplemente sean usuarios sin privilegios en los que no se considere la implementación de 2FA pero que igualmente pueda autenticarse e iniciar sesión en el servidor sin necesidad de utilizar TOTP como segundo factor.

Podemos añadir el valor nullock a la siguiente directiva del módulo de PAM editando el fichero /etc/pam.d/sshd.

auth required pam_google_authenticator.so nullok

Saludos!

Autor: Adrián Lois

11 mayo, 2022

KrbRelayUp PrivEsc: Escalada de privilegios local en entornos Active Directory y mitigación

KrbRelayUp es una herramienta que nos permite en una post-explotación la escala de privilegios locales en máquinas unidas a un dominio Active Directory y persistencia para realizar este privesc en cualquier máquina del dominio a través de movimientos laterales hasta llegar a la máquina objetivo, de ahí su criticidad y riesgo alto.

No se trata de una vulnerabilidad en sí con un CVE asignado, sino del aprovechamiento de un fallo de configuración por defecto de Windows por parte de los controladores de dominio.

Esta explotación es exitosa en cualquier máquina cliente Windows 10 bajo controladores de dominio Window Server 2012, 2016 y 2019. Actualmente Microsoft no ha dando solución con ningún parche de actualización. 

Más información en el repositorio del autor Mor Davidovich @dec0ne:


Explotación (PoC)

Previamente debemos compilar el proyecto, dejo referencia del binario ya compilado KrbRelayUp.exe (fuente de la descarga: https://kb.offsec.nl/). La explotación es sumamente sencilla, una vez comprometida la máquina y descargado el ejecutable lanzamos el exploit. Hasta el momento el servicio de protección para ejecución malware de Windows no lo detecta.

Primera fase del ataque, el usuario de dominio autenticado y sin privilegios retransmitirá una petición Kerberos a LDAP y creará una máquina de control sobre la máquina local usando RBCD.

.\KrbRelayUp.exe relay -Domain <Domain> -CreateNewComputerAccount -ComputerName <hostName>$ -ComputerPassword <Password>

Segunda fase del ataque, utilizará la máquina creada de control para obtener un ticket de servicio de Kerberos y lo utilizará para crear un nuevo servicio que se ejecute como SYSTEM (en este caso está desarrollado para lanzar un cmd.exe).

.\KrbRelayUp.exe spawn -d <Domain> -cn <HostName>$ -cp <Password>

Figura 1: Escalada de privilegios local a SYSTEM usando KrbRelayUp.exe.


Si verificamos en la consola de Active Directory (dsa.msc) vemos como se ha creado una nueva máquina "host01". 

Aclarar que esta máquina será usada como persistencia en el dominio un posible atacante podría moverse lateralmente entre máquinas aprovechando el principio de localidad hasta llegar a una máquina servidor objetivo donde estuviese autenticado un usuario del grupo administradores de dominio o el propio administrador de dominio. Al poder escalar privilegios a SYSTEM sería más que posible realizar un volcado de hashes en memoria de dicha cuenta.

Por esta razón considero que se trata de algo crítico, con un alto riesgo de seguridad y que se debería subsanar lo antes posible. Más adelante veremos como mitigar esto.

Figura 2: Creación de la máquina maliciosa por parte de un usuario del dominio en Active Directory.

Detección

Este artículo no está enfocado al detalle de detección, sino más bien a la explotación y mitigación de esta vulnerabilidad. Considero que en este caso es más eficiente realizar una mitigación para este fallo de configuración que generar las alertas de detección en nuestro SIEM.

La mitigación para esta vulnerabilidad tiene una sencilla implementación a nivel global de todo el dominio, sin embargo en las reglas de detección se nos puede escapar algo nuevo y que no se estaría alertando.

Uno de los logs que podemos registrar (en una configuración de Auditoría por defecto de AD) sería el evento 4768 "Solicitud de ticket de autenticación de Kerberos (TGT)". Donde el Account Name sería la creación de máquina en AD.

Figura 3: EventID 4768 - Autenticación Kerberos solicitud de ticket TGT del host malicioso

También he intentado buscar un evento estado buscando un evento 4741 "Creación de una cuenta de máquina", sin éxito. Es posible que la incorporación de Sysmon nos pueda dar más detalles para su detección y poder crear un indicador de compromiso válido.

Para el uso de reglas Sigma y otros eventos de Windows aconsejo consultar el repositorio donde se mantiene actualizada esta información.

Mitigación y verificación

Para evitar el aprovechamiento de esta mala configuración por defecto en entornos de dominio, podemos elegir diversas opciones de mitigación:

  • Opción 1. Requerir firma LDAP del servidor.
  • Opción 2: Eliminar los permisos de los "usuarios autenticados" para que no puedan unir máquinas al dominio.
  • Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota.

Opción 1. Requerir firma LDAP del servidor

Debemos aplicar únicamente la siguiente política en la GPO "Default Domain Controllers Policy":

Polices > Windows Settings > Security Settings > Local Polices > Security Options > "Domain controller: LDAP server signing requirements" y establecerla como "Require signing"

De esta forma se rechazan las solicitudes de LDAP simples y solicitudes LDAP a través de SSL. Esto puede tener impacto en sistemas Windows XP o Server 2003.

No es necesario aplicar ambas políticas: "Network Security: LDAP client signing requirements" y "Domain controller: LDAP server signing requirements" en la GPO Default Domain Policy.

Figura 4: Mitigación KrbRelayUp - Aplicar política "Domain controller: LDAP server signing requirements".

Verificamos la mitigación y vemos que al aplicar esta política la conexión LDAP falla. En la segunda fase del exploit tampoco es posible realizar la conexión solicitando el ticket Kerberos TGT para autenticarnos en la máquina creada y poder levantar la terminal privilegiada SYSTEM.

Aunque el ataque no fue exitoso, si ha sido posible crear una nueva máquina en el dominio, no nos daría persistencia ya que la autenticación no se va poder realizar en ningún caso, pero en caso de ejecutar el ataque se estarían creando de forma residual estas máquinas en la OU por defecto de "Computers".

Figura 5: Verificación mitigación - LDAP server signing requirements.

Opción 2. Eliminar los permisos de los "usuarios autenticados" para que no puedan unir máquinas al dominio

De todas las opciones de mitigación que se comentan en este artículo, es la que aplicaría por escalabilidad y gestión centralizada de permisos a través de grupos de seguridad de Active Directory.

Debemos aplicar únicamente la siguiente política en la GPO "Default Domain Controllers Policy":
Polices > Windows Settings > Security Settings > Local Polices > User Rights Assignment > "Add workstations to domain"
Por defecto esta política establece que todos los "usuarios autenticados" tienen la capacidad de unir máquinas al dominio. Un solución sería eliminar este grupo y agregar los grupos que autorizados para realizar esta tarea. En este caso agregué "Domain Admins" y un grupo específico creado en AD de este modo podremos agregar otros grupos o usuarios específicos y autorizados pudiendo así granular los permisos para realizar esta tarea.

Figura 6: Mitigación KrbRelayUp - Limitar permisos para la política "Add worksations to domain".

Con esta política propagada y aplicada en los DCs, si probamos a ejecutar nuevamente el exploit vemos que falla mostrando un mensaje de que el usuario no tiene permisos suficientes (esto se refiere a que no es posible que este usuario pueda crear máquinas unidas al dominio).

Lógicamente esta opción no llegará ni si quiera a crear la máquina en AD. Por lo que ya estaríamos eliminando una posible persistencia en el dominio por parte del atacante.

Figura 7: Verificación mitigación - Permisos insuficientes para poder unir máquinas al dominio.

Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota

Otra mitigación que dificultaría los requisitos del ataque sería limitar limitar el número de máquinas que un usuario pueda unir al dominio. Si optamos por esta opción debemos establecer un valor 0 al atributo del dominio ms-DS-MachineAccountQuota.

Este atributo lo podemos encontrar y editar directamente desde las propiedades del dominio en una consola de Active Directory (dsa.msc) o también acceder a él a través desde la consola de editor ADSI (adsiedit.msc).

Figura 8: Mitigación KrbRelayUp - Limitar el valor del atributo ms-DS-MachineAccountQuota.

Si verificamos la aplicación de este cambio vemos como al intentar ejecutar el exploit el servidor no puede gestionar esta solicitud, esto estaría bloqueando el ataque y tampoco crearía la máquina en AD evitando así, al igual que la opción anterior, una posible persistencia en el dominio.

Figura 9: Verificación mitigación - ms-DS-MachineAccountQuota = 0.

Si con el mismo usuario, desde otra máquina nueva, intentamos unirla al dominio de modo gráfico nos muestra el siguiente error indicando que "hemos superado el número máximo de cuentas de máquina que puedes crear o unir en este dominio".

Figura 10: Verificación mitigación - Mensaje de error al intentar unir una máquina al dominio.

¿Cómo identificar quién agregó un nueva maquina al dominio?

El usuario "user.sinpriv" es un usuario de dominio sin ningún otro privilegio otorgado, sin embargo el exploit hace uso del cmdlet New-AddComputer sumado a esta configuración por defecto en entornos de dominio este usuario puede crear máquinas en Active Directory. 

Podemos identificar y verificar quien a creado una máquina en AD examinando el atributo ms-DS-CreatorSID.

Get-ADComputer <Host> -Properties mS-DS-CreatorSID | Select-Object -Expandproperty mS-DS-CreatorSID | Select-Object -ExpandProperty Value | Foreach-Object {Get-ADUser -Filter {SID -eq $_}}
Figura 10: Identificar al usuario en la creación de nuevas máquinas unidas al dominio.

Saludos!

Autor: Adrián Lois

11 enero, 2022

Instalar y configurar Microsoft LAPS para evitar movimientos laterales (Local Administrator Password Solution)

Microsoft LAPS (Local Administrator Password Solution) se trata de una herramienta de Microsoft que pone solución a la gestión de contraseñas administrador local de los equipos unidos a un dominio. 

Entendiendo el riesgo de seguridad y escenarios comunes en las organizaciones

En la mayoría de compañías es una práctica común establecer la misma contraseña para la cuenta del administrador local en todos los equipos que forman parte de un dominio, principio de localidad entre máquinas, ya puedan ser clientes o servidores (exceptuando los Domain Controller que por defecto carecen de una cuenta de administrador local).

Se considera una reducción del riesgo alto la implementación de este tipo de soluciones que evita configurar una misma contraseña para la cuenta de administrador local en todas las máquinas, al hacer que cada máquina use una contraseña diferente y compleja para la cuenta de administrador local se establece una importante medida defensiva que evita principalmente el movimiento lateral entre equipos (pivoting), una vez se obtuviese una contraseña o un hash NTLM válido en el que poder realizar técnicas de Pass the Hash (PtH).

Este tipo de soluciones es conocida por muchas empresas pero implementada por muy pocas en la realidad, no tanto por su complejidad sino por el impacto significativo que supone en la operativa diaria de gestión del cambio en la administración remota de los equipos, despliegues automáticos mal configurados en las que se haga uso de la contraseña de administrador local parametrizada, mantenimiento en los posibles endpoints que se encuentren fuera de la oficina en la que la conexión con la VPN a la red central se realice en pocas ocasiones y sea necesario gestionarlo a través de una cuenta local privilegiada, etc. 

En cualquier caso para entornos on-premise existen alternativas de gestión remota para estos equipos como puede ser la creación de un grupo en AD en el cual se añada a través de GPO al grupo administradores locales de las máquinas de modo que cada usuario que pertenezca a ese grupo principal pueda autenticarse en el equipo con su contraseña de dominio de forma nominal. En el caso de disponer de un entorno híbrido integrado con algún proveedor cloud MDM no solo se simplifica la gestión de los equipos sino que se gana en monitorización y administración de seguridad de los mismos.

Características de LAPS

LAPS determina si la contraseña de la cuenta del administrador local ha caducado. Si la contraseña ha caducado, cambia la contraseña del administrador local a un nuevo valor aleatorio y transmite la nueva contraseña y la fecha de caducidad a Active Directory donde se almacena en unos atributos especiales asociados con el objeto de equipo de AD. Las contraseñas se almacenan en Active Directory y están protegidas por listas de control de acceso (ACLs) por lo que solo los usuarios elegibles pueden leerlas o solicitar su restablecimiento.
  • Gestión centralizada y almacenamiento de las contraseñas de los administradores locales de forma segura dentro de AD DS.
  • Las contraseñas se almacenan en valores de atributos que sólo estarán visibles para los usuarios o grupos de seguridad que se definan a través de Active Directory.
  • Las contraseñas de los administradores locales son únicas en cada máquina.
  • Las contraseñas se cambian de forma automática, estableciendo contraseñas aleatorias y complejas en base a patrones que previamente estén definidos en su propia plantilla GPO (AdmPwd.admx).
  • Transmite las contraseñas al cliente de manera segura y cifrada.
  • Permite controlar los permisos en usuarios o grupos para el acceso a la visualización y restablecimiento de las contraseñas.
  • Dispone de sus propios ID de eventos para su análisis en auditorías.

Instalación de LAPS

Instalador de LAPS (Local Administrator Password Solution).

En uno de los controladores de dominio, preferiblemente un PDC (Primary Domain Controller), instalamos y agregamos las características del cliente pesado, módulo de PowerShell y las plantillas del editor de políticas de grupo.

GPO CSE (Client-Side Extension) solo deberá estar presente en cada endpoint gestionado.

Figura 1: Instalar características para la gestión LAPS.

Figura 2: LAPS instalado.

Importamos el módulo AdmPwd.ps, se actualiza el esquema de Active Directory, y se definen las unidades organizativas donde se quieran aplicar los permisos para la gestión de LAPS.

Import-Modulo AdmPwd.ps
Update-AdmPwdADSchema
Set-AdmPwdComputerSelfPermission -Identity "<OU_AD>"

Figura 3: Importar módulo AdmPwd y actualizarlo en el esquema de AD.

El permiso de escritura en los atributos ms-Mcs-AdmPwdExpirationTime y ms-Mcs-AdmPwd de todas las cuentas del equipo tiene que ser añadido a la cuenta integrada. Esto es necesario para que la máquina pueda actualizar la contraseña y la fecha de caducidad de su propia contraseña de administrador local gestionada.

Para visualizar todos los cmdlets disponibles de un módulo podemos usar Get-Command y especificar el módulo.
Get-Command -Module AdmPwd.ps
Figura 4: Ver todos los cmdlets disponibles de un módulo.

Configuración GPO LAPS en Active Directory

Se crea una nueva GPO desde el editor de administrador de políticas de grupo (gpmc.msc). Al instalar la plantilla AdmPwd.admx de LAPS se añaden las nuevas políticas para establecer su configuración.
Computer Configuration > Polices > Administrative Templates > LAPS
Se habilita la política y en el caso de que el administrador local no sea el nombre por defecto (Administrator o Administrador) indicamos el nombre de la cuenta local tipo administrador que esté configurada en los equipos del dominio y los parámetros de las passwords como la: complejidad, longitud y expiración.

Figura 5: Crear y configurar GPO LAPS.

Desplegar el MSI de LAPS al resto de equipos del dominio a través de GPO

Es necesario desplegar el mismo instalador al resto de los equipos del dominio donde se necesite implementar LAPS ya sea en su versión de x64 o x86 y solamente con la característica por defecto habilitada.

La operativa de despliegue dependerá de la herramienta que se estemos usando para la gestión de endpoints de la infraestructura ya sea con SCCM System Center, Microsoft Intune, Puppet, etc.
msiexec /i <PATH>\LAPS.x64.msi /quiet
msiexec /i <PATH>\LAPS.x86.msi /quiet
Para este ejemplo al tratarse de un fichero Microsoft Installer .msi se puede desplegar directamente a través de otra GPO.
Computer Configuration > Policies > Software Settings > Software installation
Se indica la ruta donde está el instalador, el tipo de deployment será "Assigned" (sin modificaciones en sus características de instalación) ya que con la configuración por defecto solo instalaría la característica del cliente (GPO CSE).

Figura 6: Desplegar LAPS a los equipos del dominio a través de GPO. 

Funcionamiento y administración de LAPS

En los objetos tipo "Computer" de la unidad organizativa de Active Directory donde se delegaron los permisos para LAPS podemos comprobar que se han añadido dos nuevos atributos: 
  • ms-Mcs-AdmPwd: Almacena la password local del equipo.
  • ms-Mcs-AdmPwdExpirationTime: Tiempo en la que la password expirará y será renovada por otra password aleatoria cumpliendo los requisitos establecidos en la GPO.
A través del Editor de interfaces de servicios de Active Directory ADSI (adsiedit.msc) comprobamos como se han creado estos atributos y ver su valor desde la pestaña de editor de atributos de la propia ficha del objeto en la consola de Active Directory (dsa.msc).

Figura 7: Atributos de objeto donde se almacenará la password local aleatoria y rotatoria.

LAPS UI es la interfaz gráfica para una gestión más sencilla de LAPS donde podemos buscar por hostname un equipo del dominio para visualizar su password de administrador local, fecha de expiración y también restablecer su password (en caso de que tengamos permisos de escritura sobre los atributos comentados anteriormente).

Otra forma de visualizar la passwords es a través de PowerShell haciendo uso de los cmdlets que se importan a través del módulo AdmPwd.ps en la instalación de LAPS.
Get-AdmPwdPassword <HOSTNAME> | fl
Get-AdmPwdPassword <HOSTNAME>.Password
Figura 8: LAPS UI para ver y restablecer las passwords locales de los equipos de AD.

También es posible restablecer la password de administrador local de un equipo del dominio desde PowerShell.
Reset-AdmPwdPassword -ComputerName:<HOSTNAME>

Establecer permisos específicos según roles (RBAC)

Solo los usuarios privilegiados del dominio como los Domain Admins tienen permisos de lectura y escritura sobre los valores de los atributos donde se almacena la password y la fecha de expiración. 

En el caso de que se necesite conceder la capacidad de poder ver o editar estos valores de atributos a usuarios que no sean administradores, sino usuarios menos privilegiados a nivel de dominio que proporcionen mantenimiento y soporte a otros empleados de la compañía, se pueden crear grupos de seguridad en Active Directory de solo lectura (LAPS_R) y otro de lectura y escritura (LAPS_RW) donde se puedan asignar estos usuarios de soporte y de esta manera tener un control de permisos más granular.

En este caso asignamos el permiso de solo lectura sobre estos atributos al grupo "LAPS_R". Es posible conceder estos permisos de dos modos: 

Una forma automática a través del siguiente cmdlet donde se hará referencia el grupo de AD y la OU.
Set-AdmPwdReadPasswordPermission -Identity "<OU_AD>" -AllowedPrincipals "<Grupo_Solo_Lectura>"
Con el siguiente cmdlet verificamos la asignación de permisos asignados a la OU.
Find-AdmPwdExtendedRights -Identity "<OU_AD>"
Figura 9: Establecer un grupo de permiso de lectura para LAPS. 

La otra opción sería hacerlo de manera manual estableciendo las DACLs de la OU. En este caso agregando el grupo LAPS_R a las propiedades de seguridad de la OU y en los permisos avanzados permitir las siguientes ACEs "Read ms-Mcs-AdmPwd" y "Read ms-Mcs-AdmPwdExpirationTime".

Figura 10: LAPS - ACEs de lectura establecida a un grupo en una OU de AD.

En el caso que necesitemos agregar un grupo de usuarios para poder restablecer passwords, es decir otorgar permisos de escritura sobre los valores de los atributos de LAPS, usaremos el siguiente cmdlet.
Set-AdmPwdResetPasswordPermission -Identity "<OU_AD>" -AllowedPrincipals "<Grupo_Lectura_Escritura>"

Comprobar los permisos establecidos

Para comprobar de los permisos asignados anteriormente, el usuario de dominio "user2" no forma parte del grupo "LAPS_R" por lo tanto desde la consola de Active Directory no podrá visualizar los atributos de LAPS del equipo "PC10D2".

Figura 11: Comprobación de lectura sin permisos en el atributo de password de AD.

Para cambiar esto y conceder permisos de lectura. Se asigna el usuario "user2" al grupo "LAPS_R" de AD, se reinicia sesión con este usuario para aplicar los cambios y vemos como es posible visualizar desde el editor de atributos del tipo de objeto equipo el valor de la contraseña y la fecha de expiración. 

Figura 12: Comprobación de lectura correcta en el atributo de password de AD

Auditoría de eventos LAPS

La activación de auditoría de los usuarios que consultan y leen con éxito la contraseña de Administrador local de un equipo se puede activar mediante el siguiente cmdlet parte del módulo de AdmPwd.ps. 
Set-AdmPwdAuditing -OrgUnit: <OU_AD> -AuditedPrincipals: <GRUPO/USUARIO>
Cuando una contraseña se lee con éxito, se registra un ID de evento 4662 en el registro de seguridad del controlador de dominio.

Figura 13: Auditar eventos LAPS de consulta y lectura exitosa de la contraseña.

Saludos!

Autor: Adrián Lois

24 diciembre, 2021

Apache Log4j: Resumen de vulnerabilidades asociadas a Log4Shell

No suelo realizar publicaciones de este tipo pero considero este caso como una excepción.

"Log4j" o "Log4Shell" se han convertido en trending topic no solo en las comunidades de Ciberseguridad sino también en los entornos tecnológicos en general. 

Si hablásemos de un "Top Vulnerabilidades 2021" está claro que se lo llevarían las asociadas a Apache Log4j, el revuelo de esto no está tanto por el número de vulnerabilidades publicadas y su gravedad, sino por el impacto de afectación que está teniendo en una enorme cantidad de productos y servicios. El mayor problema es identificar las aplicaciones que lo usan, en muchos casos las empresas carecen de un inventario actualizado de las aplicaciones que utilizan. El inventario es fundamental en materia seguridad.

Por esta razón he realizado un resumen de las vulnerabilidades asociadas a Log4j publicadas hasta la fecha. (Este post se irá actualizado según se vayan publicando nuevas vulnerabilidades relacionadas)

CVE-2021-44228

  • Base Score: Crítico, 10.0
  • Publicación: 10/12/2021
  • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  • Versiones afectadas: Apache Log4j2 2.0-beta9 a 2.12.1 y 2.13.0 a 2.15.0.
  • CWE: Deserialización de datos, validación de entrada incorrecta, consumo incontrolado de recursos.
Vulnerabilidad Log4Shell original es una falla de deserialización. Otorga capacidades de ejecución remota de código (RCE) a atacantes no autenticados. Se encuentra explotable en componentes log4j-core, limitado a las versiones 2.x: desde la 2.0-beta9 hasta la 2.14.1 inclusive.

Se implementó una solución para Log4Shell en la versión 2.15.0, pero actualmente se considera incompleta.

CVE-2021-45046

  • Base Score: Crítico, 9.0
  • Publicación: 14/12/2021
  • Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
  • Versiones afectadas: 2.0.1 - 2.12.2 (excluido) y 2.13.0 - 2.16.0 (excluido).
  • CWE: Deserialización de datos.
Tras la explotación provoca una denegación de servicio (DoS). Log4j 2.16.0 soluciona este problema eliminando la compatibilidad con los patrones de búsqueda de mensajes y desactivando la funcionalidad JNDI de forma predeterminada.

CVE-2021-4104

  • Base Score: Alto, 8.1
  • Publicación: 14/12/2021
  • Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
  • Versiones afectadas: JMSAppender en Log4j 1.2.
  • CWE: Deserialización de datos.
Aunque anteriormente se pensaba que Log4j 1.x era seguro, ya no es así. Esencialmente, la configuración no predeterminada de las instancias de Log4j 1.x que utilizan la clase JMSAppender también se vuelve susceptible a la falla de deserialización que no es de confianza. 

Este CVE afecta todas las versiones de los componentes log4j:log4j y org.apache.log4j:log4j para los cuales solo existen versiones 1.x. Debido a que estas son versiones al final de su vida útil, no existe una solución para la rama 1.x en ninguna parte, y se debe actualizar a Log4j-core 2.16.0 o superior. 

Es posible protegerse eliminando JMSAppender por completo de log4j-1.2.17.jar, con el siguiente comando. https://www.slf4j.org/log4shell.html
zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

 

CVE-2021-42550

  • Base Score: Medio, 6.6
  • Publicación: 16/12/2021
  • Vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
  • Versiones afectadas: Versión 1.2.7 de Logback y versiones anteriores.
  • CWE: Deserialización de datos.
Esta es una vulnerabilidad en el framework Logback, un sucesor de la biblioteca Log4j 1.x. Se han publicado versiones más recientes de Logback v1.3.0-alpha11 y v1.2.9 que abordan esta vulnerabilidad menos grave.

CVE-2021-45105

  • Base Score: Alto, 7.5
  • Publicación: 18/12/2021
  • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
  • Versiones afectadas: Log4j2 2.0-alpha1 hasta 2.16.0 (incluido).
  • CWE: Validación de entrada incorrecta, recurrencia incontrolada.
Se descubrió que Log4j 2.16.0 era vulnerable a una falla DoS calificada como Alta. Apache ha lanzado una versión log4j 2.17.0 que corrige esta vulnerabilidad. 

CVE-2021-44832

  • Base ScoreMedio, 6.6
  • Publicación28/12/2021
  • VectorCVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
  • Versiones afectadas: Log4j2 2.0-beta7 hasta la 2.17.0 (excluyendo las versiones de corrección de seguridad 2.3.2 y 2.12.4).
  • CWE: Validación de entrada incorrecta, RCE (Ejecución remota de código).
Vulnerabilidad de ejecución remota de código (RCE) en el que un atacante con permiso para modificar el archivo de configuración de registro puede construir una configuración maliciosa utilizando un JDBC Appender con una fuente de datos que haga referencia a un URI JNDI que pueda ejecutar código remoto. Se trata una vulnerabilidad RCE con un score medio debido a su complejidad de explotación y al nivel de alto privilegio que el atacante debería conseguir previamente para explotar esta vulnerabilidad de forma exitosa.

Este problema se soluciona limitando los nombres de fuentes de datos JNDI al protocolo java en las versiones 2.17.1, 2.12.4 y 2.3.2 de Log4j2.

Saludos!

Autor: Adrián Lois