Cybersecurity News
Mostrando entradas con la etiqueta privesc. Mostrar todas las entradas
Mostrando entradas con la etiqueta privesc. Mostrar todas las entradas

Escalando privilegios en Windows 10: Segunda Parte



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:

  1. 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
  2. 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.
  3. 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. 
  4. 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.
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.

  • 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.

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.

Escalando privilegios en Windows 10

El pasado 27 de agosto, la experta en ciberseguridad "SandboxEscaper" liberó en Github un exploit de escalada de privilegios local en Windows 10. El exploit, el cual enlazó desde un tweet publicado en la red social Twitter, se hizo viral rápidamente, saltando la noticia hasta varios medios generalistas:



El exploit aún se encuentra accesible, y puede ser descargado desde el siguiente enlace:
https://github.com/SandboxEscaper/randomrepo/blob/master/PoC-LPE.rar

Dentro del mismo se encuentra un completo Write-up explicando la vulnerabilidad. En concreto, el programador de tareas de Windows tiene una vulnerabilidad en la interfaz de la Llamada a Procedimiento Local Avanzada, o Advanced Local Procedure Call (ALPC), que permite a cualquier usuario elevar privilegios hasta SYSTEM.

En esta interfaz hay una llamada a la API (SchRpcSetSecurity) que no verifica correctamente los permisos. De este modo, es posible asignar permisos de forma arbitraria a través de un hard link a cualquier objeto del sistema de forma local.


El funcionamiento de la PoC es muy sencillo. En primer lugar decidiremos que proceso deseamos escalar y seleccionaremos su PID. Para ello nosotros utilizaremos el software Process Explorer:


A continuación, lanzaremos el exploit usando por ejemplo el proceso del bloc de notas (PID 4324)


Si volvemos a Process Explorer veremos como el bloc de notas es ejecutado a través del servicio de cola de impresión, esta vez, con privilegios de SYSTEM:


Ahora si intentamos realizar alguna acción que requiera privilegios, como por ejemplo abrir el archivo "hosts" situado en la ruta "C:\Windows\System32\drivers\etc", no tendremos ningún problema:


Obviamente, modificando un poco el exploit podemos olvidarnos del notepad, y ejecutar algo mucho más interesante como podría ser un Meterpreter. Después de generar nuestra propia DLL maliciosa con msfvenom, adaptamos el proyecto de Visual Studio, lo compilamos y volvemos a ejecutar...


Sin embargo, esta vez tenemos nuestro listener preparado y podemos observar como inmediatamente nos llega la sesión de Meterpreter sin problemas, y por supuesto corriendo como SYSTEM.




Os confirmamos que esta PoC ha sido realizada en un sistema Windows 10 Pro x64, actualizado con los últimos parches de seguridad, y se sabe que también afecta a Windows Server 2016. Sin embargo, con modificaciones menores es posible ejecutarlo en la versión 32 bits de Windows 10, y probablemente sea posible hacerlo funcionar en otros sistemas de Microsoft que dispongan de esta funcionalidad.

Microsoft ha reconocido la vulnerabilidad y ha anunciado que se encuentran trabajando para resolver el problema lo antes posible. Hasta entonces, cuidado con lo que ejecutáis... :)

Podéis consultar más información sobre esta vulnerabilidad en la segunda entrada que hemos realizado en nuestro blog.

¡Saludos!