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.
- Crea un fichero UpdateTask.job en %SystemRoot%\Tasks, donde cualquier usuario (guest incluido) puede escribir para poder crear tareas programadas. Este fichero, sin embargo, es un enlace apuntando a PrintConfig.dll, nuestra dll objetivo
- Utiliza el método SchRpcSetSecurity del Programador de Tareas para cambiar los permisos de UpdateTask.job, que en realidad se trata de un enlace a PrintConfig.dll, para que cualquiera en el sistema pueda modificarlo. Esto es posible gracias a que esta modificación, recordemos, no se ejecuta con los permisos del usuario, sino con los permisos de SYSTEM asociados al Programador de Tareas.
- Acto seguido, se modifica nuestra dll objetivo (PrintConfig.dll) ya que a estas alturas puede ser modificada por cualquiera, y se sustituye con una dll maliciosa de nuestro interés.
- Provocamos que el servicio Cola de Impresión cargue y ejecute la dll maliciosa. Finalmente, la carga maliciosa de nuestra dll se está ejecutando con permisos de SYSTEM, los permisos asociados al servicio de Cola de Impresión.
- Primero, pensaban que no se encontrarían con código de impersonalización, uno de los principales errores detectados en esta vulnerabilidad. Sin embargo, se han encontrado con que sí existe este código. El problema reside en que esta llamada de impersonalización se realiza incorrectamente justo después de hacer la llamada que asigna los permisos. ¿La solución? Han subido la llamada a RpcImpersonateClient para que se ejecute antes de que se inicie el proceso de asignación de permisos.
- Segundo, una vez añadido este primer parche el exploit seguía funcionando. ¿El motivo? También existe una llamada a RpcRevertToSelf, que sirve para revertir la impersonalización, pero que de nuevo está incorrectamente situada y se ejecuta antes de la llamada que asigna los permisos. Por tanto, se elimina la impersonalización demasiado pronto. ¿La solución? Han eliminado esa llamada del código y la colocan más tarde, después de que los permisos se hayan asignado correctamente.
0 comentarios:
Publicar un comentario