Páginas

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-Module 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!

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!

Entradas Populares