Exploit de Windows Sticky Keys: el veterano de guerra que nunca muere

¿Alguna vez has oído hablar de Sticky Keys Exploit? Probablemente lo hiciste, ya que se conoce desde hace mucho tiempo. Se usó como un exploit muchas veces, luchó en muchas versiones de Windows y nunca se eliminó. Por eso lo llamo el “Veterano de Guerra”, aunque nunca se retiró…

En resumen, es un exploit de escalada de privilegios de Windows que le permite obtener una ventana de símbolo del sistema con privilegios administrativos. Desde allí podría, por ejemplo, cambiar la contraseña de usuario e iniciar sesión. Pero te lo explicaré con más detalle más adelante.

la hazaña

Sticky Keys es una accesibilidad GUI del sistema operativo. Fue diseñado para ayudar a las personas con discapacidades específicas. En pocas palabras, permite que las teclas modificadoras ( Ctrl , Shift, etc.) permanezcan presionadas durante algún tiempo.

Déjame contarte rápidamente su historia.

Stickykeys nació en Mac OS System 6 en los años 80. Windows implementó su versión algunos años después en Windows 95, lejos de saber que sería explotada en el futuro. Sucedió por primera vez en Windows XP y más de 15 años después, amenaza con ponerse del lado de otras vulnerabilidades icónicas de Windows.

Pero, ¿cómo funciona el exploit?

Bueno, hay algunas variaciones de esto, pero la más común comienza con una reparación de inicio de Windows, ya sea desde el sistema operativo host o desde un dispositivo de instalación. Desde allí, obtendrá una ventana Cmd y, si todo va bien, debería tener suficientes privilegios para realizar cambios dentro de la carpeta System32 .

Todo lo que tiene que hacer entonces es reemplazar el ejecutable Cmd (cmd.exe) con Sticky Keys (

 sethc.exe

¿Suena bien? Probablemente sí, pero es tan antiguo que te hace preguntarte:

¿Realmente todavía funciona? ¿Hubo algún esfuerzo para corregir la "vulnerabilidad"?

Bueno, primer error. Sticky Keys no es una vulnerabilidad.

Una definición de vulnerabilidad, dada por NIST:

“Debilidad en un sistema de información, procedimientos de seguridad del sistema, controles internos o implementación que podría ser explotada o desencadenada por una fuente de amenaza”.

En este caso, no es una vulnerabilidad del sistema la que está siendo explotada, sino el exploit en sí mismo. Puede ser explotada por falta de medidas de seguridad del usuario, por lo que termina siendo responsabilidad del usuario. Y es más como una característica nativa del sistema operativo.

Ahora podrías preguntar: pero el exploit aún funciona sin necesidad de una configuración incorrecta del usuario, ¿verdad?

¡Seguramente! Pero tal vez no tenga tanta importancia por el hecho de que requiere acceso físico para usarlo.

Entonces, volviendo a la pregunta, creo que, hasta cierto punto, existe la posibilidad de que Windows no quiera solucionar este problema por completo.

Primero, el hecho de que no sea una vulnerabilidad elimina la necesidad de arreglos.

Pero también existe la posibilidad de que esto se haya dejado a propósito como una forma de entrar en la máquina cuando sea necesario. Después de todo, existen otras herramientas capaces de lograr exactamente lo mismo.

La verdad es que he estado siguiendo esta vulnerabilidad durante algún tiempo, y si tú también lo hicieras, dirías que se hicieron pocos o ningún cambio durante largos períodos.

Encontré y sigo encontrando una gran cantidad de material sobre esta vulnerabilidad, desde publicaciones de blog hasta tutoriales de YouTube que enseñan cómo usar el exploit. También descubrí que las personas siguen preguntando formas de protegerse contra esto, e incluso usan los foros de Microsoft.

Además, también puede encontrar algunostutoriales antiguos que explican cómo se ha "documentado por todas partes" esta vulnerabilidad o publicaciones antiguas en las que la gente ya pedía una solución.

Pero después de todo, parece que Microsoft ha tomado algunas medidas para proteger a los usuarios contra este exploit. Reuní algunos (puede haber otros):

• Firewall de Windows que impide que sethc.exe ejecute Cmd.
• SFC restaura el archivo sethc.exe a su estado original.
• Prohibir modificaciones de archivos en la carpeta "System32".
• Eliminando "sethc" de la carpeta "System32" al acceder a través del modo de recuperación.
• Contraseña que protege el acceso a Cmd en el modo de solución de problemas.

Dadas estas medidas y debido a que no encontré ninguna publicación reciente, quería estar seguro de que esta vulnerabilidad aún era explotable en la última versión de Windows 10.

Déjame mostrarte cómo fue porque a todos les gustan las demostraciones. Y antes de que me digas que viste esto cien veces, te digo que esta tuvo giros inesperados...

Demostración

No voy a seguir todos los pasos ya que hay muchas demostraciones y tutoriales sobre este exploit. Y mi propósito en este momento es solo mostrarle las limitaciones actuales que encontré y las soluciones que encontré para explotarlas.

Comencé tratando de explotar directamente a través del modo nativo de solución de problemas del sistema operativo, e inmediatamente me estrellé contra la primera pared, el Cmd protegido por contraseña. Volví a intentar lo mismo usando una imagen de instalación de Windows pero nuevamente tuve el mismo problema:

Después de pensar durante un tiempo en una solución, descubrí que esto podría ser una limitación reciente ya que mi imagen de instalación era la más reciente. Así que volví a intentar el proceso usando una versión anterior de Windows y Voilà:

yo tenia un cmd...

Unos pocos comandos más tarde y también reemplacé las teclas adhesivas...

Todo lo que tenía que hacer ahora era reiniciar Windows, presionar la tecla shift 5 veces y se abrió mi ventana Cmd.

Aquí algunas personas dijeron haber encontrado limitaciones porque el firewall detectaría el exploit. Esto probablemente podría evitarse usando la primera ventana de la línea de comandos para desactivar el firewall, pero no tuve ningún problema con esto.

El verdadero problema apareció entonces.

No se suponía que me solicitara ningún otro permiso para cambiar la contraseña de usuario ya que lo estaba haciendo con privilegios de administrador, pero aún así, Windows lo rechazaba. Supongo que esto es el resultado de alguna configuración que hice anteriormente que deniega el acceso al administrador.

Intenté algunas cosas para solucionar este problema, pero no pude encontrar una solución hasta que recordé...

¿Qué pasa con la cuenta de administrador?

Así que revisé la cuenta de administrador, la activé y pude cambiar su contraseña.

 net user Administrator net user Administrator /Active: Yes net user Administrator *

Al final, no obtuve acceso para acceder al usuario que quería (conejillo de indias), pero pude acceder a la cuenta de administrador, incluso mejor . A partir de ahí, verifiqué que todavía tenía permiso para hacer casi todo, incluso acceder a cualquier archivo personal desde la cuenta de usuario.

Solo por diversión y para mostrarle que hay otras cosas que puede hacer después de obtener acceso a una cuenta de administrador. Desde una terminal, ejecuté el siguiente comando:

 REG ADD HKLM\software\microsoft\windows\currentversion\run /v nc /d “C:\windows\system32\nc.exe -ldp 443 -e cmd.exe

Esto creó un Cmd Shell persistente que me dio acceso remoto a la cuenta de usuario a través del puerto 443, tan pronto como la computadora volvió a arrancar. Por supuesto, esto solo funciona porque netcat se instaló en la computadora de la víctima, si no, no es nada que no pueda hacer usando otros vectores de ataque. Por ejemplo, si ya tengo las manos sucias, simplemente podría tener el ejecutable netcat en una unidad flash y copiarlo en la computadora de la víctima.

protegiéndote

El usuario del conejillo de Indias no fue el mejor ejemplo de protección y no es su culpa que esto sea explotable, pero ahora que sabe esto, cualquier infracción que tenga al usar este exploit, aunque sea muy poco probable, será todo suyo.

Hay algunas formas que encontré para proteger su máquina con Windows:

• Deshabilitar la activación del teclado con teclas adhesivas ( todavía puede activarlo a través de un botón en la pantalla de inicio de sesión).
• Deshabilitar la reparación de inicio ( suena horrible e inseguro)
• Contraseña del BIOS ( buena opción ).

Algunas de estas soluciones funcionarán, algunas mejor que otras y con diferentes dificultades de configuración. Pero, ¿no preferirías una forma más sencilla y segura?

Cifrado de dispositivos.

Esa es tu respuesta. Es el primer y más fácil paso que puede tomar para protegerse contra esto. De esta manera, un atacante primero tendría que conocer su contraseña para descifrar el dispositivo antes de poder usar cualquier exploit.

Hay diferentes formas de lograr este cifrado en máquinas con Windows. En caso de que no conozcas ninguno, te sugiero BitLocker .

Si BitLocker está deshabilitado en su país o de alguna manera no está disponible en su máquina, simplemente busque alternativas de cifrado. Como último recurso, utilice algunos de los métodos que se enumeraron anteriormente. Pero tenga en cuenta que existen variaciones de esto que se pueden usar para explotar otros accesos directos de accesibilidad.

Si todavía es un no, puede buscar la contraseña del BIOS. Es una buena solución también.

Pero sepa que hay más en el cifrado de dispositivos. Los beneficios van mucho más allá de la simple protección contra esta falla de acceso físico.

El cifrado del dispositivo hará que su computadora sea inaccesible sin la contraseña, lo que significa que incluso con acceso físico a su computadora o disco duro, es muy difícil acceder a sus datos.

¿Cuál es tu opinión sobre esto? ¿Estás haciendo algo para protegerte?