23 septiembre, 2020

Instalar paquetes de actualizaciones .msu en Windows con expand y dism

Cuando nos descargamos parches directamente de Microsoft Update Catalog normalmente el formato estándar suele ser una extensión .msu (Microsoft Update Standalone Installer) del paquete de actualización con su KB identificativo.

Para instalar un paquete de actualización de forma independiente sin hacerlo través de las Windows Update de Microsoft Windows, es tan sencillo como ejecutar con doble clic el fichero msu de instalación y esperar a que finalice el proceso. Aunque no siempre ocurre así y resulta costoso realizar la instalación.

Recientemente instalado el paquete de actualización que corrige la vulnerabilidad crítica CVE-2020-1472 conocida como "Zerologon" de la cual hablé en Linkedin. Quería aplicar este parche en un Windows Server 2019 el parche correspondiente al KB4565349 encontrándome un error de incompatibilidad con el computador en el momento de aplicar el parche.

Figura 1: Error de instalación Windows Update Standalone "actualización no es aplicable".

Una forma para resolver este tipo de problema de incompatibilidad en la aplicación de Updates. Es realizarlo de forma manual haciendo uso de las herramientas en línea de comandos expand y dism (Deployment Image Servicing and Management). Con expand podemos descomprimir el paquete .msu obteniendo así los ficheros .cab y con dism añadimos el paquete de actualización correspondiente al fichero principal .cab a la imagen de Windows en actual indicando el parámetro /Online.

Aplicar paquetes de actualización .msu con expand y dism

Una vez descargado el fichero .msu lo movemos en un directorio raíz. Por ejemplo "C:\Updates\paquete.msu" (previamente creamos esta nueva carpeta).

Con expand descomprimimos el paquete .msu, veremos varios ficheros y algunos .cab.

expand -f:* C:\Updates\paquete.msu C:\Updates\

El parámetro -f especifica los archivos de un archivo contenedor (. cab) que se desea expandir. Puede usarse caracteres comodín (* o ?).

Con dism añadimos el fichero .cab de mayor tamaño a la imagen de Windows actual y esperamos a que termine el proceso.

# CMD
dism.exe /Online /Add-package /Packagepath:"C:\Updates\paquete.cab"

# PowerShell
Add-WindowsPackage -Online -PackagePath "C:\Updates\paquete.cab"

Una vez hecho esto reiniciamos la máquina. Para comprobar que la actualización se instalado correctamente podemos listar las updates instaladas en el sistema.

# CMD
systeminfo

# PowerShell
Get-HotFix

Restaurar configuración Windows Updates

Esto se escapa del caso particular anterior pero lo comento como información adicional. En el caso de que no sea posible aplicar actualizaciones de Windows de la forma tradicional y automática a través de las Windows Updates, una solución que suele funcionar en la mayoría de casos es renombrar o eliminar, dependiendo el caso y el espacio en disco del que se disponga, la carpeta donde se descargan por defecto los paquetes de actualizaciones SoftwareDistribution.

Cuando buscamos nuevas actualizaciones en Windows estas se descargan por defecto en la carpeta "C:\Windows\SoftwareDistribution" una vez descargas Windows aplica/instala estas actualizaciones en el sistema y después de un reinicio las sigue manteniendo en esta ubicación. Una forma de liberar espacio en disco y también restaurar su configuración en caso de errores en el momento de descarga o aplicación de las updates de Windows es:

1. Renombrar la carpeta SoftwareDistribution
2. Intentar descargar y aplicar las nuevas actualizaciones.
3. Eliminar la carpeta vieja renombrada.

Al renombrar esta carpeta Windows no puede encontrar el directorio por lo que la creará de nuevo y cargará la configuración inicial por defecto en lo relacionado a Windows Update.

Para poder renombrar esta carpeta, previamente es necesario detener los procesos que funcionan como servicios de Windows que hacen uso de ella. Ejecutamos una consola cmd con privilegios administrativos.

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

Ya en consola podemos renombrarla directamente.

ren C:\Windows\SoftwareDistribution SoftwareDistribution_old

Volvemos arrancar nuevamente los servicios.

net start wuauserv
net start cryptSvc
net start bits
net start msiserver

Comprobamos nuevamente si existen nuevas actualizaciones, esperamos a que se descarguen e instalen, reiniciamos el sistema y eliminamos la carpeta renombrado "SoftwareDistribution_old".

Espero que estas dos posibles soluciones puedan resultar de ayuda.

Saludos!

03 septiembre, 2020

Restringir el inicio de sesión a través de escritorio remoto RDP a usuarios Administradores y permitirlo solamente a usuarios específicos

Por defecto para poder usar los Servicios de escritorio remoto RDP Remote Desktop Protocol necesitamos un usuario, ya sea local en la máquina remota o de dominio, que tenga permisos para poder conectarse. Para ello dicho usuario debe ser miembro del grupo "Administradores locales" o bien del grupo "Usuarios de escritorio remoto".

Agregar o quitar usuarios o grupos a través de las Propiedades del sistemas (sysdm.cpl) sería lo mismo que hacerlo a través del propio grupo local "Usuarios de escritorio remoto" que podemos encontrar en la consola lusrmgr.msc.

Figura 1: Administradores locales tienen acceso RDP.

El problema surge cuando necesitamos que en una máquina remota puedan acceder únicamente determinados usuarios pero que las cuentas de usuario miembros del grupo Administradores locales no puedan iniciar sesión a través de RDP.

Evitar el Principio de localidad (Movimiento lateral)

En muchas empresas, por razones principalmente administrativas, es habitual encontrase al usuario Administrador (cuenta integrada) habilitado o simplemente la creación de un nuevo usuario que pertenezca al grupo Administradores locales de la máquina. Suele establecerse la misma contraseña para este usuario en todos las máquinas de la organización lo que se conoce como "Principio de localidad" permitiendo con esto la posibilidad de movimientos laterales de un equipo a otro en un contexto privilegiado y facilitando la capacidad de acceso a través de los Servicios de escritorio remoto a otras máquinas que tengan configurado el mismo usuario y contraseña.

Hardening - Restringir el acceso RDP a los Administradores locales

Para aplicar un poco de hardening y establecer unas buenas prácticas ante esta situación. Añadimos los usuarios específicos ya sean locales o formen parte de un dominio al grupo de "Usuarios de escritorio remoto".

Figura 2: Añadir usuarios de forma nominal al grupo local de Usuarios de escritorio remoto.

Establecemos y modificamos una GPO ya sea nivel local o de de dominio en la consola editor de directivas gpedit.msc o gpmc.msc.

Configuración del equipo > Configuración de Windows > Configuración de seguridad > Asignación de derechos de usuario > "Permitir inicio de sesión a través de Servicios de escritorio remoto"

Quitamos o eliminamos el grupo de usuarios "Administradores". En el caso de un dominio se podría establecer un grupo integrado tipo "Opers. de cuentas" o crear uno específico de dominio el cual también pertenezca al grupo Administradores locales de la máquina (esto se podría realizar de forma masiva mediante una GPO a nivel de dominio). También tendremos la posibilidad de elevarnos a un contexto privilegiado haciendo uso del UAC (User Account Control) ejecutando los procesos como Administrador (Ctrl+Shift) u otro usuario que sea miembro del grupo Administradores locales.

De ese modo no se degradaría la posibilidad de seguir administrando las máquinas e iniciar sesión a través de los servicios de escritorio remoto únicamente para aquellas cuentas de usuario que lo necesiten por su operativa de mantenimiento. Minimizando así el riesgo del principio de localidad comentado anteriormente.

Figura 3: GPO - Limitando el acceso a grupos o usuarios a través de Servicios de escritorio remoto.

En la siguiente captura se puede ver como se denegó el acceso a través de RDP a un usuario adminadrian que es miembro del grupo de "Usuarios" y "Administradores" locales de la máquina que, por defecto tendría acceso al inicio de sesión a través de RDP ya que pertenece al grupo de Administradores locales, independientemente de si pertenece o no al grupo específico "Usuarios de escritorio remoto".