El viejo truco de las sticky keys sigue funcionado

El "exploit" de las sticky keys sigue sin parchearse y funciona incluso en Windows 7, Windows 8 Consumer Preview y Windows Server 2008 R2.


A pesar de que el truco se conoce desde hace ya bastante tiempo, Microsoft todavía sigue sin parchear este agujero de seguridad. Además explotarlo es bastante fácil, cualquiera puede hacerlo sólo sustituyendo el ejecutable sethc.exe (o utilman.exe) por cmd.exe. Para ello necesitaremos permisos sobre la ruta ‘c:\Windows\System32' o arrancar el sistema con un Live CD, aunque existe una opción aún mejor con la que obtendríamos los mismos resultados, simplemente introduciendo unas pocas líneas en la consola (recordar que necesitaremos que el usuario tenga permisos de admin):

REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t REG_SZ /d "C:\windows\system32\cmd.exe"

Si un usuario malintencionado aprovechara un despiste de su víctima y consiguiera cambiar la entrada de registro podría volver más tarde y sólo tendría que presionar la tecla shift cinco veces para acceder al símbolo del sistema con permisos elevados (system).

Claro, ahora pensaréis que volver más tarde implica tener otra vez acceso físico al equipo y estar delante del mismo durante el tiempo necesario para llevar a cabo las "malvades" oportunas. Pues el truco de las sticky keys también funciona por Escritorio Remoto. Eso sí, tendríamos que desactivar primero NLA, también mediante el registro:


reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f

Fuentes:
Hack allows any application to run on top of Windows 7 login screen
Privilege Escalation via "Sticky" Keys
Sticky Keys and Utilman against NLA

16 comentarios :

  1. Muy bueno, lo de hacerlo por remoto me mato!!! XD

    ResponderEliminar
  2. Pero putos noobs, me parece ridiculo que vosotros, que teneis cierto nivel, os rebajeis a ese nivel. A ver cuando os enterais de que eso no es un puto exploit, gilipollas.

    Vergonzoso... ¿.?

    ResponderEliminar
  3. Es posible paliar sus efectos si por una GPO Preference se establece, mediante una opción de Replace, el valor del registro Reg_SZ "Flags" de S-1-5-18\Control Panel\Accessibility\StickyKeys.

    De esa forma al menos se desactiva la posibilidad de su uso en la pantalla de login.

    Salu2!

    ResponderEliminar
  4. Perdón, se me olvidó añadir antes que es una GPO Preference a nivel de máquina, no de usuario.

    Salu2!

    ResponderEliminar
  5. para el primer @anónimo:

    un exploit puede ser simplemente una secuencia de comandos que se aprovecha de un fallo en una aplicación para provocar un comportamiento no deseado o no contemplado por la misma.

    Si bien estamos de acuerdo que llamar a ésto exploit se queda grande, por eso está entrecomillado "exploit".

    No obstante te animo a que propongas otra palabra y la sustituimos de buen agrando.

    De igual forma agradezco tu comentario y efusividad, si bien te pediría que omitieras los insultos. Recuerda que los que escribimos aquí y en otros blogs lo hacemos sólo con el ánimo de compartir y seguir aprendiendo.

    ResponderEliminar
  6. Bueno, a mi también me gustaría comentar la entrada poniendo un ejemplo, la construcción de una nave espacial. Nos centramos tanto tanto en las cosas más complejas de su desarrollo que a lo mejor el cohete no despega porque ha faltado apretar una simple tuerca y todo el proyecto va al traste. Ahora lease este ejemplo en lo referente a la entrada, te puedes centrar en desarrollo de sistemas y app más seguras, pero si pasas por alto "la tuerca" del registro que señala esta entrada.... pues eso.
    Excelente entrada como siempre.
    Saludos

    ResponderEliminar
  7. RTS, el problema no es la entrada del registro, el problema son los privilegios con los que se ejecuta el proceso. Y sirva recalcar, que como siempre, la seguridad física del equipo, por muy olvidada o nimia que parezca estar, es la primera línea que debería estar menos expuesta, o por lo menos, tener conciencia de ello, que la gente parece que no se percata de que por mucho que tú securices algo, si alguien tiene acceso físico , y arranca por ejemplo con un LiveCD, el resto de medidas dadas pueden irse al traste si no se ha pensado en ello.
    Salu2!

    ResponderEliminar
  8. Siempre se publica este "exploit" pero nunca se habla del de Linux, que al reiniciar se puede acceder en modo single y ya entras sin contraseña.

    Lo que comentais de la entrada de registro...indicar que ese usuario tiene que tener permisos de administrador.

    Y en el otro caso, si se despista un usuario de Linux que en ese momento esté como root, te marcas un visudo y ale...pones un usuario con todos los permisos.

    Os comento todo esto, por que yo el tema de las sticky keys me parece una buena solución para la administración, ya que siempre funciona (igual que el modo single de Linux)....y si te enmarronan un equipo sin contraseñas y tienes que entrar, tienes un método muy sencillo...de hecho, lo usé hace 1 semana XD

    Recordemos, que en ambos casos, Windows y Linux, hay que reiniciar la máquina, si no, esto no se puede hacer, salvo el tema de la entrada del registro....

    Pero como ya indico..si pillas solo si pillas al usuario despistado y que esté como administrador.

    Así que chavales!! en cuanto os levantéis de la mesa, bloquear vuestros PCs, que tenemos mucho poder.

    Un saludo.

    ResponderEliminar
  9. gracias @madrikeka. Hemos recalcado la necesidad de tener permisos para modificar el registro.

    Eso sí, que miedito tener el rollo de las sticky keys como solución de administración ;)

    ResponderEliminar
  10. De "ná"!

    Pues es que aparte del password renew, que en ese momento no lo tenía a mano, no se me curre otra forma sencilla de recuperar la administración de un equipo que no tienes la contraseña.

    Si sabes de otras formas, así de simples, cuéntamelo que me las apunto todas!!! :D

    ResponderEliminar
  11. Sólo se usan los permisos de adminsitrador con las sticky en la pantalla de login sin haber iniciado sesión; si el usuario está logueado, y es usuario, y se hace uso de ello corre con los permisos del usaurio -si es administrador, mal vamos ya :-P.
    Lo que se debería corregir en este caso, es el supuesto de que sin nadie estar logueado, o al hacer un fast user switch, que el proceso corra con privilegios mínimos, como como la Local system...eso es lo que está mal hecho y deberían subsanar.

    La única forma de coger la administración la máquna en casos como los comentados, pasa por el LiveCD o toca tirar de exploit remoto si es viable y nos gusta ponernos a prueba un rato :-P
    Salu2!

    ResponderEliminar
  12. Siempre es bueno recordar también este que también tiene ya sus añitos:
    El Sticky Keys (sethc.exe) de GNU/Linux
    http://www.flu-project.com/el-sticky-keys-sethc-exe-de-gnulinux.html

    ResponderEliminar
  13. Creo recordar que fue en el Asegur@IT Camp 3 cuando pregunté precisamente esto. Y la respuesta fue, más o menos:

    "Eso no lo han solucionado. Y no lo entienden como un problema. La razón es...". Más o menos fue eso. Y sí. Saben que es un problema pero, hay otro que para Microsoft es fundamental: La accesibilidad. Fundamentalmente, lo que me querían decir, es que no podían quitar la posibilidad de activar la accesibilidad desde el login, porque ésta se perdería. Supongo que alguna certificación rara de accesibilidad depende de ello o algo parecido. Pero vamos, que sigue siendo vulnerable.

    Lo que no sabía era la parte de modificarlo por el registro. Esa me la apunto.

    ResponderEliminar
  14. mi hermano no se como lo hizo perono necesito cd ni mierdas
    alguen q me ayude metido en permisos de administrador tampoco me deja

    ResponderEliminar
  15. Sigue funcionando en Windows 10, el truco del stickykeys.
    XD!

    ResponderEliminar