18 febrero, 2021

Wynis: Checking de auditorías de seguridad para Windows y Active Directory

Wynis es un script de auditoría desarrollado por el usuario Sneakysecdoggo que realiza una evaluación de controles de indicadores del CIS (Center for Internet Security) siguiendo los benchmarks del CIS Best Practices Windows 10 y Windows Server 2016. Los puntos de referencia del CIS son reconocidos internacionalmente como estándares de seguridad para la defensa de sistemas y datos de IT contra ciberataques.

Se trata de una herramienta de script similar a Lynis, usada en sistemas basados en Linux.

Después de ejecutarlo creará un directorio con todos los resultados reportados en formato de texto y csv. El checklist reporta:

  • Lista de puertos, servicios
  • Reglas de firewall 
  • Software instalado 
  • Tareas programadas 
  • Software que se ejecuta al inicio 
  • Información general del sistema 
  • Recursos compartido, 
  • Políticas de seguridad y GPOs
  • Actualizaciones instaladas 
  • Características opcionales instaladas 
  • Lista de usuarios locales, 
  • Entre otros reportes adicionales...

No solo para sistemas Windows 10, sino que también dispone de un versión para realizar este tipo de auditoría en Server 2016 que sea controladores de dominio Active Directory.

Figura 1: Ejecución de Wynis en un sistema Windows.

Saludos!

09 febrero, 2021

Firmar scripts PowerShell: Hardening en la política de ejecución

Por motivos de seguridad Windows PowerShell establece unas políticas de ejecución de scripts. Con el fin de evitar posibles ejecuciones de scripts no deseadas. Para poder ejecutar scripts en PowerShell sin problemas, se tendrá que cambiar la política de ejecución (ExecutionPolicy). Por defecto no están definidas y vienen deshabilitadas (Restricted) para todos los scopes.

En un escenario en el que formemos parte de un dominio y deseemos ejecutar scripts PowerShell para la realización de tareas en los endpoints o servidores del parque equipos de la organización. En la mayoría de los casos me encuentro con la "solución" sencilla y poco idónea. Se trata de aplicar un GPO estableciendo la política de ejecución en modo Unrestricted en las máquinas afectadas. Esto deja vía libre a cualquier usuario para que pueda comprometer la máquina sin ningún tipo de restricción.

Aplicar un hardening en la política de ejecución de scripts PowerShell

Lo más correcto en estos casos sería aplicar esta GPO en un modo AllSigned y firmar con un certificado de confianza todos los scripts que vayan ser ejecutados aplicando así un hardening en la política de ejecución de scripts de forma que sean seguros y confiables en entornos corporativos. 

Si disponemos de una PKI de una entidad de certificación ADCS (Active Directory Certificate Services) podremos generar un certificado específico para este fin y propagar este certificado a través de GPO.

Para los siguientes ejemplos usaré un certificado autofirmado.

Modos de políticas de ejecución (ExecutionPolicy):

  • Restricted: Bloquea todos los scripts en PowerShell y hace que todas las tareas deban ejecutarse de forma interactiva, nada automático. Es la política por defecto.
  • Unrestricted: Puede ejecutar cualquier script, sin restricciones. Si se ejecuta un script sin firmar muestra una advertencia al usuario.
  • RemoteSigned: Puede ejecutar scripts que han sido creados en la máquina local sin ser firmados. Pero los paquetes descargados deben estar firmados antes de poder instalarlos. Conlleva el riesgo de que no es necesario que los scripts locales vayan firmados digitalmente. Para ejecutar scripts descargados de internet (sin firmar) es necesario usar la opción Unblock-File. Es la política por defecto para Windows Server.
  • AllSigned: Solo puede ejecutar paquetes y scripts firmados digitalmente por un publicador de confianza, incluidos los scripts escritos en el equipo local.
  • Bypass: Similar a Unrestricted, con la diferencia de que no alerta de riesgos al usuario. Suele utilizarse en integraciones de PowerShell con otras aplicaciones, en las que funciona en una capa inferior, dado que dichas aplicaciones cuentan con un modelo de seguridad propio.
  • Undefined: No se establece explícitamente ninguna de las directivas anteriores. Por defecto sería Restricted.
  • Default: Establece la política de ejecución predeterminada. Restricted para clientes de Windows y RemoteSigned para Windows Server.
Tipos de scopes:
  • MachinePolicy: Establecido por una política de grupo para todos los usuarios de la máquina.
  • UserPolicy: Establecido por una política de grupo para el usuario actual de la máquina.
  • Process: Afecta solo a la sesión actual de PowerShell.
  • CurrentUser: Afecta solo al usuario actual.
  • LocalMachine: Alcance predeterminado que afecta a todos los usuarios de la máquina.

Get-ExecutionPolicy -List
Set-ExecutionPolicy AllSigned -scope LocalMachine -Force

Figura 1: Políticas de ejecución de scripts PowerShell.


Bypass de la política de ejecución de un solo script

En el caso de que las políticas de ejecución estén en un modo Undefined y por lo tanto es como si estuvieran en Restricted. Si queremos ejecutar un script en esa misma sesión o contexto de ejecución podemos usar el modo Bypass

PowerShell.exe -ExecutionPolicy Bypass -File \.MyScript.ps1

También sería lo mismo.

powershell -ep Bypass .\MyScript.ps1

Figura 2: Bypass para la ejecución de un solo script.


Firmar un script PowerShell

Referencia: Set-AuthenticodeSignature

Firmar con un certificado del almacén de certificados local

$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert
Figura 3: Firmar con un certificado del almacén local.

Firmar un script usando un certificado de un archivo PFX

$cert = Get-PfxCertificate -FilePath C:\Certs\MySign.pfx
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert
Figura 4: Firmar usando un un certificado .pfx.

Agregar una firma que incluya la autoridad certificación raíz (CA)

$cert = Get-PfxCertificate -FilePath C:\Certs\MySign.pfx
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert -IncludeChain All -TimestampServer "http://timestamp.globalsign.com/scripts/timstamp.dll"

  • IncludeChain: Incluye todas las cadenas de confianza de la autoridad raíz.
  • TimeStampServer: Agrega una marca de tiempo a la firma. Esto evita que el script falle cuando caduque el certificado. 
Figura 4: Agregar una firma que incluya la autoridad raíz.


Obtener información de la firma de un script firmado

Referencia: Get-AuthenticodeSignature

Get-AuthenticodeSignature .\MyScript.ps1 | Format-List *

Figura 5: Obtener información de la firma de un script firmado.


Crear un certificado autofirmado para realizar pruebas

Referencia: New-SelfSignedCertificate

New-SelfSignedCertificate -FriendlyName "Zona System ejemplo firma de código" -CertStoreLocation Cert:\CurrentUser\My -Subject "Zona System" -Type CodeSigningCert

Figura 6: Crear certificado autofirmado para pruebas.

Ejemplo de ejecución de script firmado

Estableciendo la política de ejecución de scripts de PowerShell en AllSigned.

Figura 7: Ejemplo de ejecución de script firmado.

Saludos!

Autor: Adrián Lois

07 noviembre, 2020

Instalar características RSAT en Windows 10 cuando WSUS bloquea su descarga

A partir de las últimas versiones de Windows 10 las RSAT (Remote Desktop Services Tools) ya no se descargan e instalan como un paquete de actualizaciones de Microsoft. Sino que se incorporan como características avanzadas independientes que podemos descargar/instalar directamente desde el nuevo panel de configuración del sistema.

En el caso de que estemos trabajando en una máquina Windows 10 bajo un entorno de actualizaciones controladas por WSUS (Windows Server Update Services) es muy probable que el propio servidor WSUS esté bloqueando la descarga de las características RSAT.


Comprobar si las actualizaciones están controladas por WSUS

Para comprobar que el equipo está controlado por un servidor WSUS podemos comprobar la siguiente rama del registro.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Si vemos que los valores "WUServer" y "WUStatusServer" existen y apuntan a una dirección, normalmente HTTP puerto 8530 o HTTPS puerto 8531 con un nombre DNS interno significará que nuestro equipo recibe actualizaciones controladas directamente de un servidor WSUS.


¿Cómo instalar RSAT bajo un entorno controlado por WSUS?

Para poder instalar RSAT desde las características avanzadas del nuevo panel de control, abrimos un regedit en un contexto privilegiado como administradores, siguiendo la rama anterior, localizamos la siguiente rama.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

La clave "AU" nos indica la sección de "Actualización automáticas de Windows Update". Aquí vemos el siguiente valor "UseWUServer" y lo establecemos a un valor 0.

  • 1 = Obtiene actualizaciones de un servidor WSUS.
  • 0 = Obtiene actualizaciones de Microsoft Update.

Abrimos una consola PowerShell como administrador y reiniciamos el servicio wuauserv "Windows Update Agent Service".

Restart-Service wuauserv

Ahora ya podemos añadir las características RSAT que queremos, una vez instaladas ya podemos habilitar de nuevo a través del registro la obtención de actualizaciones a través de WSUS.

Figura 1: Instalar características RSAT deshabilitando WSUS. 

Saludos!

Autor: Adrián Lois

23 septiembre, 2020

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

Cuando nos descargamos parches directamente de Microsoft Update Catalog (Catálogo de Microsoft Update) 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!

Autor: Adrián Lois