0
0
Este blog pretende ser um sino de alerta e chamar a atenção para um potencial risco de segurança envolvido na execução de aplicativos sensíveis no utilitário Windows (“Windows Subsystem Linux”).
Como relatado pela Microsoft[aqui], o uso de WSL está crescendo rapidamente (“mais de 3,5 milhões de dispositivos ativos mensais hoje”). Com os aprimoramentos incluídos no próximo WSL 2 e as melhorias planejadas no roteiro da WSL, é razoável esperar que o uso da WSL continue crescendo ainda mais rápido.
O risco de segurança que vou destacar não é causado por qualquer bug de software (no Windows ou Linux), nem é explorado por qualquer técnica de ataque nova e complicada. Em vez disso, baseia-se no uso simples do utilitário WSL como foi projetado.
Se você está usando ou pretende usar o WSL, ou se você é responsável pela segurança dos usuários de ponto final usando wsl, esta pesquisa é uma leitura obrigatória. Quanto ao resto de vocês, você pode continuar lendo por sua conta e risco (😉 ) (lembre-se, não há bugs exploráveis ou novas descobertas técnicas aqui).
TL;DR
- WSL é um utilitário Windows que permite que os usuários executem aplicativos Linux no Windows.
- Qualquer processo padrão (não administrativo) do Windows tem direitos de acesso total a todos os arquivos que compõem a máquina WSL.
- Se um programa malicioso for executado como esse processo padrão, ele pode roubar dados estáticos sensíveis (por exemplo, chaves SSH) simplesmente copiando-os do sistema de arquivos WSL.
- Modificando os programas no sistema de arquivos WSL, nosso programa malicioso também pode capturar dados dinâmicos confidenciais (por exemplo, nomes de usuário, senhas, senhas).
- O design WSL permite a ativação dos processos do Windows por programas rodando dentro da máquina Linux. Portanto, um programa Linux padrão (não raiz) pode assumir completamente a máquina Linux.
- O WSL 2, projetado como um “Utilitário Leve VM”, diminuiu significativamente as superfícies de ataque da WSL, mas ainda é vulnerável à fraqueza de segurança descrita aqui.
- Resumindo: Executar aplicativos confidenciais dentro da WSL é significativamente menos seguro do que executar os aplicativos equivalentes em um sistema de desktop Windows ou Linux autônomo.
Fundo
WSL 2 agora é lançado formalmente (como parte da versão Win-10 2004), e gerou muito burburinho.
A Microsoft vem afirmando regularmente que “ama” o Linux[aqui],e recentemente declarou que suportará a execução de aplicativos GUI Linux na WSL [aqui].
Essas mudanças na atitude da Microsoft e planos intensivos de desenvolvimento para a WSL são uma indicação de uma mudança acentuada no uso esperado da WSL. Inicialmente, ele tinha como objetivo apoiar desenvolvedores (e possivelmente pesquisadores de segurança) que querem desenvolver ou testar aplicativos Linux dentro do Windows, mas agora parece ser um utilitário genérico do Windows que permite que todos os tipos de usuários executem aplicativos Linux em sistemas Windows Desktop.
O WSL 2 é um sistema mais seguro do que o WSL 1 (ou o recurso “bash” legado), mas não elimina os riscos envolvidos na execução de aplicativos sensíveis dentro dele.
Para ser claro: É um fato bem conhecido que o sistema “host” sempre tem controle total sobre o sistema “convidado”. O problema real aqui é que o uso pretendido do utilitário WSL irá expor muitos usuários a um risco de segurança que eles podem não estar cientes. Este provavelmente já é o caso, pois parece que muitos usuários de WSL estão atualmente usando-o para executar um cliente ou servidor SSH ou ambos (programas que processam dados de credenciais confidenciais).
Pesquisar no Google por “Running OpenSSH in WSL” encontra cerca de 270.000 resultados. Claro, nem todas essas referências são relevantes, mas olhando nas primeiras páginas, pode-se ver que a maioria deles discute como instalar e executar o OpenSSH Client ou Server no WSL, ou como interagir os programas Linux SSH com as chaves e programas do Windows SSH.
Figura 1: Dois exemplos de referências on-line ao uso de SSH no WSL
A História da WSL
“bash” – Primeiro, havia o recurso “bash”. Um processo pico chamado bash, lançado por um bash-launcher programa bash.exe. O processo bash pico emula um terminal Linux e executou programas Linux – convertendo APIs do kernel Linux para as APIs equivalentes do kernel do Windows. A arquitetura interna e os mecanismos de trabalho dos processos de pico do Windows não são relevantes para nossa história.
Não tenho certeza de quando se tornou parte integrante do Windows, e duvido que alguém (exceto eu, é claro) ainda esteja usando o comando “bash”, mas está incluído aqui por “completude”. Se por algum motivo você ainda estiver usando-o para executar aplicativos Linux sensíveis, como o OpenSSH – cuidado, pois é fácil de explorar, como você deve ver.
“WSL 1” – Para o Windows 10, o comando “wsl”(wsl.exe lançado inicialmente em agosto de 2016) substituiu o comando “bash”. Um utilitário de suporte (wslhost.exe) também foi ativado, além do processo de bash pico.
Como a infraestrutura do sistema de arquivos WSL 1 é muito semelhante ao aplicativo “bash”, aplicativos sensíveis em execução neste ambiente são expostos a riscos de segurança semelhantes aos aplicativos executados sob “bash”.
“WSL 2” – WSL 2 foi introduzido na versão Win-10 2004. A arquitetura do WSL 2 é drasticamente diferente da da WSL 1. O pacote de distribuição Linux é executado como um “Lightweight Utility VM” sob HyperV, substituindo a técnica de processo pico.
As características do “Lightweight Utility VM” WSL 2, que são relevantes para o nosso caso, são discutidas mais tarde neste blog, mas se você está se perguntando o que exatamente é um “Lightweight Utility VM”, uma excelente explicação pode ser encontrada aqui.
Quando você executa o comando “wsl” para ativar o WSL 2, vmwp.exe (processoHyperV) é executado em vez do processo bash pico.
Uma nota lateral: As alterações arquitetônicas no WSL 2 podem ajudar alguns métodos de ataque. Connor Morley, da F-Secure, publicou um white paper[aqui]que analisa a possibilidade de armar o WSL 2 para alcançar um ataque persistente e furtivo no sistema Windows de hospedagem. Aqui examinamos um alvo muito mais modesto de “roubar” informações confidenciais de aplicativos executados dentro de uma WSL que foi “legalmente” instalada. Nosso ataque é um evento de “tiro único” [do lado do Windows] que modifica programas/arquivos dentro do sistema de arquivos WSL, e nenhuma persistência no lado do Windows é necessária.
Implementações do sistema de arquivos
Sistema de arquivos “bash”
O sistema de arquivos Linux para bash foi implementado como parte integrante do sistema de arquivos Windows.
Normalmente, a pasta raiz do sistema de arquivos
Linux está localizada para cada usuário em:C:\Users\<user>\AppData\Local\lxss\rootfs As configurações
de segurança do Windows para todos os arquivos desta pasta e todas as suas subpastas permitem qualquer programa que esteja sendo executado na sessão completa deste usuário.
Figura 2: Um processo padrão do Windows tem acesso total a um arquivo Linux sensível (servidor sshd-OpenSSH)
Sistema de arquivos “WSL 1”
O sistema de arquivos Linux para WSL 1 é igualmente uma parte integrante do sistema de arquivos Windows.
Normalmente, o caminho para a pasta raiz do sistema de arquivos Linux para cada usuário é algo como:
C:\Users\<user>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\
Como o caso “bash”, as configurações de segurança do Windows para todos os arquivos desta pasta e todas as suas subpastas permitem qualquer programa que esteja sendo executado na sessão deste usuário acesso completo.
Nota: O usuário pode controlar o local onde o Linux DISTRO está instalado. Em alguns dos casos POC, você verá a pasta rootfs em C:\Users\<user fraco>\Documents\Ubuntu\rootfs.
“WSL 2” file system
Como o WSL 2 é um VM executado pela HyperV,todo o sistema de arquivos é implementado em um único arquivo vhdx, tais como:
C:\Users\<user>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\ext4.vhdx
Quando o VM está inativo, qualquer programa que seja executado na sessão de um usuário para o qual o WSL 2 foi instalado tem direitos de acesso total a este arquivo. Modificar dados neste arquivo é possível, embora mais complexo do que modificar arquivos “bash” ou WSL 1. Na próxima sessão, mostrarei um método simples para contornar essa complexidade.
A integração “perfeita” com o sistema de arquivos Windows é alcançada através de um objeto COM que implementa o protocolo “Plan 9 File System” (usando o novo vp9fs.dll). Os programas em execução dentro do VM podem acessar arquivos do Windows usando o prefixo “/mnt/c/” no nome do arquivo (como foi feito em “bash” e “WSL 1”).
Os processos do Windows podem acessar arquivos Linux “legalmente” adicionando o prefixo \\wsl$\\\/lt;nome de distribuição>\ ao nome completo do arquivo. É instrutivo ver que neste tipo de acesso, o processo do Windows não tem privilégios “raiz”, mesmo que seja elevado.
Figura 3: O processo elevado do Windows não pode modificar um arquivo Linux sensível “legalmente”
Atacando aplicativos sensíveis em execução dentro da WSL
Para os três primeiros casos, assumimos as seguintes pré-condições:
– Um programa malicioso está sendo executado em um processo padrão na sessão do Windows de um usuário.
– Este usuário usa o WSL para executar aplicativos sensíveis (não necessariamente agora).
Discuto ataques aos programas SSH Client e SSH Server, mas este mecanismo de ataque se aplica a qualquer aplicativo sensível.
O POC “bash” foi feito em uma máquina Windows-10, versão 1909.
Os POCs WSL foram executados em uma máquina VM (registrado para o programa Windows Insiders) em VMWare (Windows 10, versão 2004, Build 19624.rs_prerelease.200502-1339).
Ataque-A: Atacando aplicativos sensíveis que correm dentro de “bash”.
Este caso é simples, pois o invasor sempre tem acesso completo de leitura/gravação a todo o sistema de arquivos Linux . As ações de ataque em potencial podem incluir:
a) Roubar credenciais do cliente SSH
O comando ssh aceita as credenciais do usuário e as repassa para o servidor que irá autenticar o usuário.
O programa SSH Client (ssh) pode ser modificado para que toda vez que ele é ativado os seguintes dados são “vazados” para o invasor:
– Todos os argumentos de linha de comando.
– Um arquivo de identidade (chave SSH privada identificada pelo argumento da linha de comando “-i”).
– Uma senha solicitada e inserida manualmente.
– Uma “senha” solicitada e digitada manualmente.
Desta forma, o invasor pode acumular (ao longo do tempo) todas as informações necessárias para acessar todos os servidores SSH aos quais este usuário se conecta.
POC-A: Modificação sensível do programa (caso “bash”)
Figura 4: Dentro do ambiente Linux, o programa “ssh” só pode ser modificado por “raiz”
Figura 5: Um programa padrão do Windows modifica ssh (caso “bash”)
b) Roubar credenciais do servidor SSH
Se o usuário configurasse um servidor SSH no WSL, uma quantidade significativa de informações confidenciais poderia potencialmente ser vazada.
Um caso de uso para esse servidor é permitir que o usuário trabalhe em casa. Ele também pode usar este servidor para se conectar a outros servidores na intranet da organização (via “tunelamento”).
Observe que dentro do ambiente Linux, apenas usuários de Linux “raiz” podem acessar as chaves SSH privadas, mas do lado do Windows, eles estão totalmente expostos.
Figura 6: Chaves privadas SSH no Linux são protegidas por “raiz”, os processos padrão do Windows têm acesso total
Todas as informações de credenciais necessárias para se conectar a este servidor podem ser acumuladas por:
– Acesso ao arquivo sshd_config.
– Acesso a arquivos e pastas referenciados pelo arquivo config (por exemplo, AuthorizedKeysFile).
– Modificações no próprio programa sshd para captar informações de credenciais passadas dinamicamente.
Modificando o arquivo de configuração(sshd_config),quaisquer limitações de acesso definidas pelo usuário podem ser removidas (e, claro, qualquer conexão remota pode ser autorizada).
c) Exploração de túneis SSH
O usuário pode configurar um Servidor SSH no WSL e definir o Port-Forwarding em outros servidores (novamente – para suportar o trabalho em casa é um caso de uso possível). Neste caso, o invasor pode obter acesso remoto permanente a esses servidores usando as informações coletadas na etapa “b” acima.
Ataque-B: Atacando aplicativos sensíveis em execução dentro do “WSL 1”.
Uma vez que a implementação do sistema de arquivos Linux é idêntica ao caso “bash”, todos os ataques descritos no Attack-A acima também são aplicáveis aqui.
POC-B: Modificação sensível do programa (caso WSL 1)
Figura 7: Um programa padrão do Windows modifica ssh (caso WSL 1)
Ataque-C: Atacando aplicativos sensíveis em execução dentro do “WSL 2”.
Como mencionado anteriormente, todo o sistema de arquivos de uma máquina WSL 2 é implementado em um único arquivo vhdx. Duas questões dificultam a realização dos ataques descritos acima neste sistema:
a) Modificações neste sistema de arquivos são mais complicadas de implementar do que modificações no sistema de arquivos de “bash” e “WSL 1”, uma vez que você não pode simplesmente abrir e atualizar o conteúdo dos arquivos.
b) Quando a máquina estiver ativa, vmwp.exe tem acesso exclusivo ao arquivo.
Uma maneira simples de contornar ambas as limitações acima é usar o recurso de conversão de versão WSL:
– Converta o sistema de arquivos WSL 2 em um sistema de arquivos WSL 1.
– Execute as modificações necessárias nos arquivos Linux.
– Seja gentil (😉) e converta o sistema de arquivos WSL 1 de volta ao formato WSL 2 [opcional].
Este curso de ação é alcançado executando um lote com os seguintes comandos de console:
1: wsl –set-version <distro name> 12:
<attack program>
3: wsl –set-version <distro name> 2
Felizmente [para o invasor], se o WSL 2 VM estiver atualmente ativo, o primeiro comando encerrará silenciosamente a sessão WSL 2 (mesmo que programas de usuários como o OpenSSH Server estejam sendo executados no momento).
POC-C: Modificação sensível do programa (caso WSL 2 – conversão para WSL 1 e volta)
Figura 8: Estado original WSL 2: passwd é um programa SUID (elevação automática para “raiz”)
– Quando a conversão para WSL 1 é iniciada, a sessão WSL 2 termina “silenciosamente”. Observe que não há mensagens de “saída” ou “logout” na captura de tela acima.
– Após a conclusão da conversão, um programa do Windows (sem privilégios de “administração”) modifica o conteúdo do programa passwd (alterando a string “inalterada” para “1337 1337”).
Figura 9: conversão para WSL 1 / modificação de passwd / Conversão de volta para WSL 2
– Após a conversão de volta para WSL 2, o passwd ainda é um programa SUID, mas dá uma mensagem de erro diferente quando a senha não é modificada (“senha 1337 1337”).
Ataque-D: O ataque Loopback: Ataque por um programa não raiz em execução dentro da WSL 2.
Sendo um “Lightweight Utility VM”, os programas em execução dentro do WSL 2 podem ativar programas do Windows (que serão executados sob o kernel do Windows).
Esse recurso pode ser usado por um programa padrão em execução dentro da WSL para assumir a máquina Virtual Linux.
Para este ataque,
assumimos: – Um programa malicioso está sendo executado em um processo padrão em um WSL VM atualmente ativo.
O ataque consiste nos seguintes passos:
a) Um programa não-raiz malicioso em execução dentro da máquina WSL 2:
- Cria um A>.exe <malicioso e um <maliciosos arquivos B>.exe em uma pasta do Windows.
- Ativa <malicioso A>.exe (por exemplo, por comando “execve”).
b) <malicious A>.exe program cria um processo destacado em execução <malicious B>.exe e termina.
c) <malicious B>.exe executa Attack-C descrito acima.
POC-D: Um programa não raiz dentro do WSL 2 pode modificar qualquer arquivo no sistema de arquivos WSL indo para fora
Figura 10: Em WSL 2- Mostre dados originais sshd_config/execute um programa de ataque não-raiz malicioso
Figura 11:O comando batch (atacando WSL) que queremos executar no Windows
Precisamos dissociar entre o programa ativado de dentro do WSL 2 e o ataque do Windows, uma vez que a tentativa de conversão em WSL 1 terminará imediatamente a sessão WSL 2 (incluindo o processo original “ataque” do Windows). Consegui isso através de comandos básicos de automação KB, que colocaram o caminho completo para o arquivo de lote no Windows “Run-window” e depois o ativaram.
Figura 12: Converter para WSL 1 / Modificar o arquivo de configuração do servidor OpenSSH / Converter para WSL 2
Observe que o programa do Windows ReplaceStringInFile substitui a string “#PermitRootLogin” pela string “PermitRootLogin “.
Figura 13: De volta ao WSL 2, o arquivo de configuração “protegido” foi modificado como esperado
Insegurança WSL em comparação com a implementação autônoma do Windows ou Linux
Até agora, deve ficar claro por que executar aplicativos sensíveis dentro da WSL é significativamente menos seguro do que executar os aplicativos equivalentes em um sistema de Desktop Windows ou Linux autônomo, mas deixe-me soletrar de qualquer maneira.
Os códigos de proteção na tabela a seguir têm os seguintes significados:
Ѵ: O acesso requer privilégios “administradores” ou “raiz”.
–: A
proteção não é necessáriaX: O acesso não requer privilégios “administradores” ou “raiz”.
Cada Entrada é formatada
assim:R: <
Código de proteção>
W: < Código de proteção> (onde ‘R‘ significa “Read Access” e ‘W‘ significa “Write Access”)
| Arquivos de so | Programas sensíveis | Arquivos de dados confidenciais (por exemplo, chaves SSH) | Arquivos de configuração sensíveis | |
|---|---|---|---|---|
| Windows | R: – W: Ѵ | R: – W: Ѵ | R: Ѵ W: Ѵ | R: – W: Ѵ |
| Linux | R: – W: Ѵ | R: – W: Ѵ | R: Ѵ W: Ѵ | R: – W: Ѵ |
| WSL (acesso do Windows, acessando arquivos no WSL File System) | R: – W: X | R: – W: X | R: X W: X | R: – W: X |
Programas de segurança:
Uma consideração adicional são os programas de segurança que podem estar ativos na máquina. Pelo que sei e no momento em que este blog foi publicado, atualmente não há nenhum programa de segurança conhecido do Windows que proteja arquivos Linux (dentro do sistema de arquivos WSL).
Quaisquer programas de segurança que possam ser implementados dentro do WSL VM (por exemplo, talvez protegendo chaves SSH) não estarão ativos enquanto o ataque for realizado.
Resumo
O principal risco de segurança identificado aqui são o roubo de credenciais ou roubo de outros dados confidenciais processados por aplicativos Linux executados dentro da WSL. Pode-se, razoavelmente, argumentar que não há nenhuma vulnerabilidade real de segurança aqui, uma vez que o usuário deve saber que os dados dentro de um VM estão sempre expostos a programas padrão executados na sessão de “hospedagem”.
Mas, neste caso, o risco é mais grave do que o risco “normal” envolvido na execução de um VM sob Windows devido ao uso pretendido de WSL como uma utilidade padrão do Windows. Pode-se inferir esse uso pretendido a partir da definição da Microsoft de WSL 2 como um “Lightweight Utility VM”. Como discutido na seção introdutória, o usuário médio de WSL se tornará menos tecnicamente experiente e o uso de WSL aumentará à medida que a WSL será usada para casos de uso cada vez mais modernos.
Há, no entanto, uma diferença de segurança mais crítica e distinta entre executar um VM completo sob windows e executar um WSL 2 VM. O ataque loopback, para o WSL 2 VM, é uma vulnerabilidade local privilege escalation que é explicitamente habilitada pelos recursos “Lightweight Utility VM” do WSL 2. Essa vulnerabilidade não existe se um sistema Linux equivalente for executado em um VM completo sob Windows.
O que me traz de volta ao título deste blog: (SAFE + SAFE) < SAFE.
A WSL combina dois sistemas seguros (“seguros”) de tal forma que um sistema global menos seguro seja criado.
Nota: Gostaria de agradecer a Gilad Reti por chamar minha atenção para a possibilidade de executar um programa Windows de dentro do WSL VM e para esta apresentação da Microsoft.
FONTE: CYBERARK