Falha de ‘Dirty Sock’ no snapd permite acesso root aos servidores Linux

Falha de ‘Dirty Sock’ no snapd permite acesso root aos servidores Linux. O problema afeta as instalações padrão do Ubuntu Server e Desktop e provavelmente está incluído em muitas distribuições Linux do tipo Ubuntu.

O Ubuntu e algumas outras distribuições Linux sofrem uma vulnerabilidade severa de escalonamento de privilégios que pode permitir que um atacante local ou um programa malicioso obtenha privilégios de root e controle total sobre o sistema alvo.

A vulnerabilidade de escalonamento de privilégio local no pacote snapd da Canonical, permite a qualquer usuário obter privilégios de administrador e acesso imediato a servidores de sistema Linux afetados.

Apelidado de “Dirty_Sock” e identificado como CVE-2019-7304, a vulnerabilidade foi descoberta pelo pesquisador de segurança Chris Moberly, que a divulgou em particular à Canonical, fabricante do Ubuntu, no final do mês passado.

A vulnerabilidade reside na API REST para o serviço snapd, um sistema de empacotamento universal do Linux que torna um aplicativo compatível para várias distribuições do Linux sem exigir qualquer modificação.

O Snapd é usado por usuários do Linux para baixar e instalar aplicativos no formato de arquivo .snap.

Chris Moberly, da Missing Link Security, encontrou o problema (CVE-2019-7304) e disse que ele reside na API snapd. Isso é instalado por padrão no Ubuntu.  Moberly disse em seu relatório de bug que suas explorações de prova de conceito funcionam “100% do tempo em instalações novas e padrão do Ubuntu Server e Desktop.” Ele também notou que a falha “provavelmente está incluída em muitas distribuições Linux do tipo Ubuntu.”

Moberly apelidou o problema “Dirty Sock”, uma vez que o problema gira em torno do manuseio de soquetes.

As versões 2.28 a 2.37 do snapd validaram incorretamente e analisaram o endereço do soquete remoto ao executar controles de acesso em seu soquete UNIX”, explicou a Canonical em seu comunicado do Ubuntu, que fornece patches para os pacotes afetados. “Um invasor local poderia usar isso para acessar APIs de soquete privilegiado e obter privilégios de administrador.

Moberly elaborou um post de seu blog explicando os detalhes técnicos da questão. “O snapd exibe uma API REST anexada a um soquete UNIX_AF local. O controle de acesso a funções restritas da API é realizado consultando o UID associado a quaisquer conexões feitas a esse soquete. Os dados do ponto de soquete controlados pelo usuário podem ser afetados para sobrescrever uma variável UID durante a análise de cadeia de caracteres em um loop for. Isso permite que qualquer usuário acesse qualquer função da API.

Com acesso à API, existem vários métodos para obter o acesso root. O pesquisador desenvolveu PoCs para dois deles que envolvem a criação de contas de usuários no nível root. Mas é provável que muitas outras abordagens possam ser tomadas, observou ele.

dirty_sockO primeiro, dirty_sockv1, ignora as verificações de controle de acesso para usar uma função de API restrita (POST / v2 / create-user) do serviço snapd local. “Isso questiona o SSO do Ubuntu em busca de um nome de usuário e chave SSH pública de um endereço de e-mail fornecido e cria um usuário local com base nesses valores”, explicou Moberly.

O lado ruim é que a exploração bem-sucedida requer uma conexão de Internet de saída e um serviço SSH acessível via host local.

O segundo, apropriadamente chamado dirty_sockv2, também ignora as verificações de controle de acesso do serviço snapd local para usar uma função API restrita, desta vez POST / v2 / snaps. “Isso permite a instalação de snaps arbitrários“, disse o pesquisador. “Snaps em ‘devmode’ ignoram a sandbox e podem incluir um hook de instalação que é executado no contexto da raiz no momento da instalação. O dirty_sockv2 aproveita a vulnerabilidade para instalar um snap ‘devmode’ vazio, incluindo um hook que adiciona um novo usuário ao sistema local. Este usuário terá permissões para executar comandos sudo. ”

Ao contrário da versão 1, o dirty_sockv2 não requer que o serviço SSH esteja em execução. Ele também funcionará em versões mais recentes do Ubuntu sem conexão com a Internet, tornando-o resiliente a mudanças e efetivo em ambientes restritos.

O exploit dois também é eficaz em sistemas não Ubuntu que instalaram snapd, mas que não suportam a API “create-user” que o primeiro exploit aproveita.

Moberly encontrou a vulnerabilidade em janeiro e elogiou a rápida equipe que corrigiu o problema rapidamente. “Fiquei muito impressionado com a resposta da Canonical a esse problema“, disse ele. “A equipe foi incrível para trabalhar e, no geral, a experiência me faz sentir muito bem em ser um usuário do Ubuntu.”

Nos sistemas Ubuntu com snaps instalados, snapd “normalmente já terá se atualizado automaticamente para o snap 2.37.1 que não é afetado”, disse a Canonical. Quanto a outras distribuições Linux que usam o snapd, como o Linux Mint, o Debian e o Fedora, os administradores devem verificar se a falha está presente e aplicar as correções de acordo.

Fonte: The Hacker News  &  Threat Post

Veja também:

Sobre mindsecblog 2399 Artigos
Blog patrocinado por MindSec Segurança e Tecnologia da Informação Ltda.

2 Trackbacks / Pingbacks

  1. 8 coisas para incluir na política de segurança cibernética
  2. Os desafios da diversidade de gênero na Segurança da Informação

Deixe sua opinião!