En la primera entrada sobre la reciente vulnerabilidad de escalada de privilegios local en Windows 10 comentábamos como a través de un enlace duro (hard link), y gracias a la falta de control sobre los permisos, era posible modificar los permisos de forma arbitraria en cualquier objeto del sistema.

Entrando un poco más en detalle, podemos observar que el primer problema reside en que el método SchRpcSetSecurity del Task Scheduler, accesible de forma externa a través de ALPC, no realiza una correcta impersonalización antes de establecer el descriptor de seguridad que define los permisos sobre el objeto que se quiere modificar. Lo lógico sería que, antes de realizar esta acción, el método impersonalizase al proceso que ha llamado a la función, usándose así por tanto los privilegios de dicho proceso para decidir sobre la capacidad de definir descriptores de seguridad sobre cualquier objeto. Sin embargo, esta acción no es realizada correctamente y por tanto se utilizan los propios permisos del Task Scheduler, con la suerte de que este proceso corre con permisos de SYSTEM. Por tanto, tenemos capacidad de asignar cualquier tipo de permiso sobre cualquier tipo de objeto.

Como ya hemos comentado, el segundo problema reside en que además esta acción se puede ejecutar no sólo sobre un objeto final, sino sobre una suerte de enlace simbólico. Gracias a esta incorrecta elección de diseño, es posible utilizar enlaces para redirigir esta modificación de permisos a cualquier objeto del sistema.

Con estos elementos encima de la mesa se repite la historia de siempre. Somos capaces de modificar cualquier ejecutable del sistema, que normalmente estaría protegido frente a modificaciones, y sólo tenemos que esperar a que un proceso privilegiado lo ejecute por error.

SandboxEscaper simplemente encontró una posible vía de ataque, aunque ella misma reconoce en su WriteUp que pueden existir más. Durante su investigación comprobó que al ejecutar la impresora XPS a través del servicio SpoolSv, se ejecutaba una dll del sistema llamada PrintConfig.dll. Además, teníamos la suerte de que habitualmente esa dll no estaba cargada directamente en el sistema, ya que de lo contrario intentaríamos modificar una dll ya cargada y nos encontraríamos con problemas de violaciones de acceso.

Por tanto, su demostración sigue los siguientes pasos:

Es importante darse cuenta de que, como comentamos en la primera entrada, es trivial modificar el exploit para que en vez de ejecutar notepad utilicemos una dll maliciosa con meterpreter o cualquier otra carga dañina.

Mientras Microsoft sigue analizando el problema, una empresa ya ha sacado una solución que parchea al vuelo los binarios del sistema afectados. En esencia han analizado el código y se han dado cuenta de varios problemas.

En el siguiente vídeo podéis ver en el process monitor, como las llamadas que anteriormente eran permitidas por una incorrecta gestión de los permisos pasan a estar completamente bloqueadas.