Paper: Evitar las restricciones de Sistema siendo usuario Limitado...

Los administradores de Windows deben estar enterados que si un usuario, incluso en funcionamiento con una cuenta limitada, puede ejecutar un programa de su eleccion, que también pueden evitar muchas de las restriciiones del sistema, incluyendo aquellas dirigidas específicamente a establecer la seguridad de por ejemplo: políticas de restricción del software y del Internet Explorer.

Eso significa que esos usuarios pueden alterar el código o los datos de sus propios procesos, incluyendo explorador e Internet Explorer, y manipulando el código o los datos relacionados con la aplicación de la política de restrincion del sistema, pueden puentear esas limitaciones.

Las políticas de la restricción del software o Software Restriction Policies (SRP) son otro ejemplo de las limitaciones que se pueden derribar por los usuarios limitados si usted permite que utilicen un ejecutable de su eleccion- es decir si usted no aplica la SRP correctamente usándolo para definir a los usuarios que executables pueden usar (whitelisting) en vez simplemente de seleccionar executables que usted no quisiera que se utilizacen en general (blacklisting) que es lo comun. Cuando un usuario lanza un proceso, la SRP comprueba la lista predifinida, para establecer si la ejecución se permite o se bloquea.

Gpdisable es un programa que demuestra la facilidad con la cual SRP se puede inhabilitar por accion un usuario limitado. El programa utiliza las técnicas de la inyección del DLL descritas por Jeff Richter en Programming Applications for Microsoft Windows para cargar un DLL en todos los procesos en el sistema a el cual el usuario que lo utiliza tiene acceso. El DLL coloca un gancho en el NtQueryValueKey API de modo que intercepte cualquier llamada del API hecho por esos procesos o DLLs que ha cargado. El código de Windows SRP utiliza NtQueryValueKey para preguntar el valor HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\TransparentEnabled del registro, que si esta presente y diferente a cero indica que SRP está activado. Aquí está una pista de Cmd.exe, utilizando Regmon, leyendo el valor en respuesta a un intento de ejecución de Notepad.exe, que fue rechazado usando SRP:

Los usuarios no tienen el permiso de modificar claves del registro HKLM, incluyendo los ajustes de SRP, pero Gpdisable engaña el código de SRP volviendo un valor del error, STATUS_OBJECT_NAME_NOT_FOUND, siempre que ve un valor denominado “TransparentEnabled” pasó a NtQueryValueKey:


Este screenshot demuestra que "el sistema no puede ejecutar el programa especificado."segun el alert de SPR, en el intento fallido de querer ejecutar Notepad.exe en una cuenta limitada del usuario ,seguido por la ejecución de Gpdisable y una ejecución posible subsecuente de Notepad.exe (la razón que lanzo otro aviso de alerta para la segunda ejecución es que SRP deposita el valor de TransparentEnabled cuando lanza el primer proceso ):

La imagen de Regmon de la segunda ejecución de notepad.exe, parece similar a la primera con la excepción principal que la pregunta de TransparentEnabled falta: Gpdisable lo interceptó en usuario-modo y así que la llamada nunca progresó en el kernel.

¿Qué otros escenarios del sistema de restricciones son susceptibles a este tipo del ataque? Los escenarios de la seguridad son impuestos por componentes de sistema operativo no accesible a usuarios limitados, pero a la mayor parte de los escenarios en el área de Componentes de Windows, del administrador de la Política de restrincciones del sistema es ineficaz en los ambientes donde usuarios finales pueden correr las aplicaciones de su eleccion tales como Gpdisable.

Es también importante notar que la habilidad de usuarios limitados a hacer caso omiso a estas restricciones no es debido a un ¨BUG¨ en Windows, sino simplemente permitido por decisiones de diseño hechas por el equipo de Microsoft.

Escrito por Marck Russinovich

Traduccion y adaptacion:

Mousehack

Salu2