Un Zero-Day de Windows, bautizado como
BlueHammer, permite explotar el propio proceso de actualización de Defender para
brindar a los atacantes acceso completo a SYSTEM.
El código de explotación es público y no ha sido parcheado.
Windows Defender, el antivirus integrado que se ejecuta en todas las máquinas
con Windows, tiene un exploit de Zero-Day con el código
fuente completo en GitHub. Sin parche, sin CVE, y se confirmó que funciona en
Windows 10 y 11 completamente actualizado. Un investigador, que dice que
Microsoft incumplió su palabra, simplemente está entregando un escalamiento de
privilegios que lleva cualquier cuenta con pocos privilegios directamente a NT
AUTHORITY\SYSTEM. En Windows Server el resultado es diferente pero sigue
siendo grave: un usuario estándar termina con acceso de administrador elevado.
La vulnerabilidad se llama BlueHammer. El 2 de abril, el investigador publicó
la divulgación pública en un blog personal, y el 3 de abril, el código fuente
completo del exploit se publicó en GitHub. Ambos publicados bajo el
alias
Chaotic Eclipse, también conocido como
Nightmare Eclipse, con un mensaje al Centro de Respuesta de Seguridad de Microsoft que se
reduce a: «Les dije que esto sucedería».
Antes de entrar en el aspecto técnico, hay una historia de fondo que vale la
pena conocer. A finales de marzo, el mismo investigador abrió un blog con una
sola publicación en la que explicaba que no querían volver nunca más a la
investigación pública. Alguien había llegado a un acuerdo con ellos y luego lo
había roto, sabiendo exactamente cuáles serían las consecuencias. La
publicación dice que dejó al investigador sin hogar y sin nada. No es alguien
molesto por un proceso de revisión lento. Es alguien que no tiene nada que
perder.
Pasemos ahora al exploit en sí, porque realmente vale la pena entenderlo.
BlueHammer no es un error tradicional y no necesita código shell,
corrupción de memoria ni un exploit del kernel para funcionar.
Lo que hace es encadenar cinco componentes de Windows completamente legítimos
en una secuencia que produce algo que sus diseñadores nunca pretendieron. Esos
cinco componentes son: Windows Defender, Volume Shadow Copy Service, la API de
archivos en la nube, los bloqueos oportunistas y la interfaz RPC interna de
Defender. Una limitación práctica que vale la pena conocer: el
exploit necesita una actualización pendiente de la firma de Defender
para estar disponible en el momento del ataque. Sin uno en la cola, la cadena
no se activa. Eso lo hace menos confiable que un «exploit de botón»,
pero no hace que sea seguro ignorarlo.
Así es como funciona la cadena de ataque. Cuando Defender ejecuta una
actualización de la definición de antivirus, parte de ese proceso implica la
creación de una instantánea de volumen temporal, que es el mismo mecanismo de
instantánea que utiliza Windows para realizar copias de seguridad y restaurar.
Esa instantánea contiene archivos que normalmente están completamente
bloqueados durante el funcionamiento normal, incluida la base de datos SAM,
que almacena los hash de contraseña para cada cuenta local en la
máquina.
BlueHammer se registra como proveedor de sincronización de Cloud Files, el
mismo tipo de cosas que usan OneDrive o Dropbox para sincronizar archivos.
Cuando Defender toca un archivo específico dentro de esa carpeta, el
exploit recibe una devolución de llamada e inmediatamente coloca un
bloqueo oportunista en ese archivo. El defensor se detiene, bloqueado,
esperando una respuesta que nunca llega. La instantánea que acaba de crear
todavía está montada. La ventana está abierta.
Con Defender congelado, el exploit lee las secciones de registro SAM,
SYSTEM y SECURITY directamente desde la instantánea. Descifra los
hashes de contraseña NTLM almacenados utilizando la clave de arranque
extraída de la sección SYSTEM, cambia la contraseña de una cuenta de
administrador local, inicia sesión con esa cuenta, copia el token de seguridad
del administrador, lo envía al nivel SYSTEM, crea un servicio temporal de
Windows y genera un símbolo del sistema que se ejecuta como NT
AUTHORITY\SYSTEM. Luego, para cubrir sus huellas, devuelve el hash de
la contraseña original. La contraseña de la cuenta local parece completamente
sin cambios. Ningún accidente, ninguna alerta, nada.
Toda la cadena se ejecuta en menos de un minuto desde una sesión de usuario
normal.
El nombre del proveedor de Cloud Files codificado en el código fuente del
exploit es IHATEMICROSOFT. La contraseña de administrador
utilizada durante el escalamiento está codificada como
$PWNed666!!!WDFAIL. Estos no son errores dejados por accidente. Son
mensajes, escritos directamente en el código, y solo hay un lector previsto.
Will Dormann, analista principal de vulnerabilidades de Tharros,
probó el exploit y confirmó que funciona
lo suficientemente bien como para ser una amenaza real.
Microsoft ha estado recortando costos. Los analistas experimentados que sabían
cómo analizar un exploit complejo y comprenderlo realmente han sido
reemplazados por personal que sigue rígidas listas de verificación de
procesos. Uno de esos requisitos de la lista de verificación es una
demostración en video del exploit. Los investigadores que se niegan a grabar
un vídeo cierran sus informes.
Mitigaciones
Hasta que Microsoft emita un parche oficial o un aviso de mitigación, los
equipos de seguridad deben tomar las siguientes medidas preventivas:
-
Monitorear herramientas de detección y respuesta en endpoints (EDR) en busca
de actividad inusual de escalada de privilegios. -
Restringir los permisos de usuarios locales al mínimo necesario para las
operaciones. -
Aplicar un registro mejorado en sistemas Windows para detectar procesos
anómalos a nivel de SYSTEM. -
Monitorear la enumeración de VSS proveniente de procesos de usuario
regulares. Las llamadas a NtQueryDirectoryObject dirigidas a objetos
HarddiskVolumeShadowCopy desde cualquier cosa fuera de la copia de
seguridad o las herramientas del sistema son una señal de alerta que casi no
tiene una explicación inocente. -
Esté atento al registro raíz de sincronización de Cloud Files mediante
procesos desconocidos. Vale la pena comprobar de inmediato que se llama a
CfRegisterSyncRoot desde cualquier otro dispositivo que no sea
OneDrive, Dropbox o Box. Esa llamada es exactamente cómo BlueHammer prepara
su trampa. -
Alerta sobre procesos con pocos privilegios que crean servicios de Windows o
obtienen tokens a nivel de SYSTEM. BlueHammer usa
CreateService para registrar brevemente un servicio malicioso durante
el escalamiento, y eso aparece en la telemetría de EDR. -
Estar atento a los cambios rápidos de contraseña consecutivos en las cuentas
de administrador local. BlueHammer restablece la contraseña, la usa y luego
la restablece. Los ID de eventos de seguridad 4723 y 4724 que se activan dos
veces en rápida sucesión en la misma cuenta no tienen una explicación
normal. -
Mantener estrictos los permisos. BlueHammer necesita una sesión local para
ejecutarse, por lo que cada permiso que un usuario estándar en realidad no
necesita es una superficie de ataque que se puede eliminar. -
Estar atentos a una actualización de seguridad de Microsoft o un aviso que
aborde la vulnerabilidad BlueHammer.
Microsoft aún no ha emitido una declaración pública ni asignado un CVE para
esta vulnerabilidad en el momento de la publicación.
Fuente:
HackingPassion