.
Fraquezas percebidas na segurança do Visual Studio IDE da Microsoft estão sendo levantadas mais uma vez esta semana com uma nova exploração de clique único.
Desenvolvido por Zhiniang Peng, principal pesquisador de segurança e arquiteto-chefe de segurança da Sangfor, a prova de conceito (PoC) explora a implementação padrão do recurso “locais confiáveis” do IDE.
Após a segmentação de pesquisadores de segurança em 2021 pelo grupo cibernético ofensivo patrocinado pelo Estado da Coreia do Norte Lázaroa Microsoft lançou locais confiáveis para evitar que projetos maliciosos do Visual Studio sejam usados para obter execução remota de código (RCE).
Publicado esta semana, o exploit de Peng destaca como esse recurso que poderia impedir um vetor de ataque testado e comprovado ainda não está habilitado por padrão, colocando em risco usuários desavisados.
Peng argumentou que habilitar o recurso por padrão ajudaria muito a proteger os desenvolvedores que abrem projetos na web, mas a Microsoft se recusou a comentar por que a intervenção do usuário ainda é necessária para se beneficiar do recurso.
A Microsoft disse ao pesquisador que não considera o problema equivalente a uma vulnerabilidade de segurança, dizendo que abrir um projeto do Visual Studio baixado de uma plataforma como o GitHub é inerentemente “uma operação insegura”.
A exploração em si envolve um projeto criado com códigos maliciosos que é baixado e aberto na máquina do usuário. Peng desenvolveu uma maneira de obter RCE antes mesmo de um projeto ser compilado.
Envolve usar o .suo arquivo binário, aquele que é criado automaticamente dentro de um .vs pasta quando um projeto é aberto, que pode ser manipulado para acionar a execução do código.
O que torna o ataque especialmente enganoso é o fato de que pastas e arquivos que começam com um ponto final não são exibidos por padrão no explorador de arquivos de um projeto, o que significa que é necessário um esforço manual adicional para encontrá-los e, mesmo quando são encontrados, são mais difícil de ler do que arquivos de texto simples.
“Há também documentação limitada que descreve a estrutura deste arquivo, tornando-o mais fácil de ignorar, mesmo com uma inspeção cuidadosa”, disse Peng.
A íntegra do pesquisador escrever detalha detalhadamente o funcionamento interno da exploração e, embora esteja longe de ser um novo vetor de ataque, Peng fez questão de destacar a posição de longa data da Microsoft sobre o assunto – que não a considera uma vulnerabilidade verdadeira e, portanto, não será corrigida.
Depois Lázaro iniciado visando pesquisadores de segurança com explorações do Visual Studio em 2021, o recurso de locais confiáveis da Microsoft foi projetado para apresentar automaticamente a um usuário que abriu um projeto não confiável do Visual Studio uma janela de diálogo, alertando sobre os riscos de segurança associados à abertura de projetos baixados da web.
Locais confiáveis também receberam uma atualização adicionando um “modo restrito” a essa caixa de diálogo, permitindo aos usuários abrir projetos de uma forma mais segura que não permitiria a execução de nenhum código na máquina.
“Depois de ativar [trusted locations]todo o conteúdo aberto no Visual Studio 2022 é considerado não confiável até que você ou sua organização (por meio da Política de Grupo) o adicione à lista de ‘locais confiáveis’”, disse a Microsoft em um postagem no blog no momento.
“Você pode confiar no local de uma pasta, em um repositório git ou no proprietário de um repositório git diretamente na caixa de diálogo de confiança ou na caixa de diálogo de configurações de confiança.”
A questão levantada por Peng é que locais confiáveis são um recurso que os usuários devem habilitar manualmente e não estão habilitados por padrão, o que ainda é o caso em 2023.
Um porta-voz da Microsoft se esquivou O Registo perguntas sobre por que os locais confiáveis não estão habilitados por padrão e se o PoC mais recente mudaria sua posição sobre o assunto.
No entanto, forneceu a seguinte declaração: “Para reduzir o risco de segurança de trabalhar com código não confiável, recomendamos que os clientes sigam nossas orientações sobre como definir configurações de confiança para melhor se protegerem.
“Além do recurso de segurança melhorias já anunciamos, continuaremos avaliando nossos serviços para ajudar a proteger nossos clientes contra esses tipos de ameaças.”
“Esta configuração precisa ser habilitada manualmente”, disse Peng. “No entanto, mesmo dois anos após a publicação do artigo, essa configuração permanece desabilitada por padrão. Pode haver algo impedindo o Visual Studio de habilitá-la.”
Mark of the Web (MOTW) também não é respeitado no Visual Studio, disse Peng, e os arquivos de solução (.sln) baixados via HTTP podem ser abertos sem quaisquer avisos relacionados ao MOTW.
MOTW é um recurso de segurança implementado pela primeira vez no Internet Explorer que marca arquivos baixados da Internet para que o Microsoft Defender SmartScreen seja acionado para realizar verificações de segurança extras.
“Em suma, podemos contornar a dupla proteção das zonas de confiança e MOTW sem qualquer esforço, o que representa um risco significativo para usuários desavisados”, disse Peng.
“Nenhum aviso do SmartScreen, nenhuma necessidade de confiança, nenhuma interação adicional necessária. Mas não será corrigido, porque a Microsoft considera que não é uma vulnerabilidade.”
No início deste ano, o provedor de serviços da equipe vermelha Outflank Publicados seu próprio exploit pré-construído do Visual Studio e recebeu uma resposta semelhante da Microsoft, aludindo ao fato de que seu próprio PoC simplesmente usou o comportamento pretendido do Visual Studio, o que não justifica uma correção. ®
.
