Lisandro Pardo
Los artículos que indican cómo omitir TPM 2.0 y Secure Boot en Windows 11 se han multiplicado en la Web, e incluso ya tenemos herramientas que deshabilitan ambos requerimientos de forma automática al crear un pendrive de instalación. Sin embargo, parte del trabajo de Microsoft es explicar por qué resulta necesario usar TPM 2.0 y Secure Boot en Windows 11. Su canal oficial Microsoft Mechanics publicó un vídeo de 17 minutos a principios de octubre en el que explora ambas tecnologías con mayor profundidad, y que vale la pena ver.
Tabla de contenidos
La otra cara de la moneda
La decisión de Microsoft es controvertida, nadie pone eso en duda. Desde la división instantánea de su base de usuarios hasta la recomendación de comprar nuevos equipos en plena crisis de semiconductores, Windows 11 demostró que los problemas de tacto y comunicación en Redmond siguen vigentes. Pero ahora que el nuevo sistema operativo ya está entre nosotros, Microsoft busca transmitir a sus usuarios las principales razones por las que es necesario usar TPM 2.0 y Secure Boot en Windows 11… o mejor dicho, «recomendado».
Eso nos lleva a un vídeo publicado en Microsoft Mechanics, uno de los canales oficiales de la compañía en YouTube. El canal suele generar contenido pensado para profesionales de IT, sin embargo, este vídeo de 17 minutos hace un trabajo decente al describir los beneficios directos de estas tecnologías de seguridad para un público más amplio, e incluye algunos ataques como demostración.
TPM 2.0 y Secure Boot en Windows 11, explicado por Microsoft
- El primer ataque explota la exposición de RDP a la Web. Primero localiza el blanco con Shodan, luego pasa a Kali Linux, y finalmente utiliza Hydra para realizar un ataque de fuerza bruta usando una base de datos con contraseñas básicas. La simulación toma unos pocos segundos, pero sabemos bien que un ataque de fuerza bruta puede extenderse por días, y es muy poco práctico realizarlo a ciegas. Con acceso completo, el atacante inyecta su payload.
- El segundo ataque se lleva a cabo en forma directa sobre un dispositivo sin seguridad basada en virtualización (VBS). Con la ayuda de un accesorio que utiliza PCILeech, el atacante logra modificar/reemplazar el código de autenticación biométrica para huellas digitales con un parche, de modo que pueda ingresar usando algo tan simple como una gomita. VBS anula esta posibilidad al aislar elementos fundamentales (llaves, firmas, etc.) de la sesión estándar, ambos separados por hardware. Al habilitar la función, el ataque queda neutralizado.
- La siguiente fase explica el rol de TPM 2.0, que es proteger claves de cifrado, credenciales de usuario y otros datos delicados con una barrera de hardware. En este punto debemos recordar que muchos equipos ya cuentan con soporte para TPM 2.0 (el propio vídeo habla de «ordenadores en los últimos cinco años»), pero se encuentra desactivado en el UEFI. Muchos usuarios pueden instalar Windows 11 sin inconvenientes con solo activarlo.
- La combinación de UEFI, Secure Boot y Trusted Boot bloquea ataques como el que observamos en el primer ejemplo, o minimiza el daño si el equipo ya está comprometido. En el vídeo nos enseñan a activar Secure Boot, que a su vez requiere desactivar Legacy Mode o CSM. Las modificaciones en la secuencia de arranque son rechazadas, y el equipo regresa a un login convencional de Windows 11.
Pequeños detalles
Uno de los aspectos más interesantes aparece al final del vídeo, en el que esencialmente admiten que el incremento en las medidas de seguridad puede impactar en el rendimiento del equipo, y ahí es cuando intervienen los nuevos chips de Intel y AMD. Además, todos los requerimientos de seguridad en Windows 11 son opcionales bajo Windows 10, y pueden ser habilitados por el usuario cuando lo desee.
En lo que se refiere a los ataques, me gustaría agregar lo siguiente: Por un lado, muchos de los resultados que presenta Shodan revelan que RDP está expuesto en ordenadores con Windows 8.1 o inferior, o sea que el problema no es un desarrollo reciente. Y por el otro, si un atacante obtiene acceso físico al dispositivo, no es absurdo declararlo comprometido desde el principio. En resumen, nunca está de más recibir información adicional, y la idea es que el usuario tenga mayor poder de decisión, más allá de que prefiera buscar un equipo nuevo, o extender el ciclo de vida en hardware perfectamente funcional.
Fuente: Microsoft Mechanics en YouTube
