0
0
Um link de compartilhamento de arquivos excessivamente permissivo permitiu o acesso público a um enorme balde de armazenamento de 38 TB contendo dados privados da Microsoft, deixando uma variedade de segredos de desenvolvimento – incluindo senhas, mensagens do Teams e arquivos das estações de trabalho de dois funcionários – acessíveis aos invasores.
A empresa de segurança de dados em nuvem Wiz emitiu um comunicado sobre o incidente, que disse ter origem no uso de um recurso do Microsoft Azure conhecido como token de assinatura de acesso compartilhado (SAS), que permite aos usuários com um link acessar um repositório de dados privado. O repositório específico em risco pertencia à divisão de pesquisa de IA da Microsoft, que – em seu repositório público GitHub – orientava os usuários a baixar imagens e códigos de código aberto do bucket de armazenamento do Azure por meio do link SAS.
No entanto, o link foi configurado incorretamente e permitiu o acesso a toda a instância de armazenamento privado, tornando públicos os arquivos e dados confidenciais.
O incidente ressalta o potencial de erros de segurança ao usar links SAS, diz Ami Luttwak, diretor de tecnologia e cofundador da empresa de segurança de dados em nuvem Wiz.
“O pesquisador de IA queria apenas compartilhar um banco de dados, o que é bom, mas como posso saber se meus usuários – com quem eles desejam compartilhar algo – compartilham por engano toda a nossa conta de armazenamento”, diz ele. “Eles até deram permissão de gravação, não apenas de leitura, então isso poderia até levar à execução remota.”
Nos últimos cinco anos, os serviços de armazenamento oferecidos pelos principais fornecedores de nuvem tornaram-se um alvo significativo tanto para investigadores como para atacantes. Em 2020, meio milhão de documentos relacionados a um aplicativo financeiro foram expostos devido a um bucket S3 da Amazon Web Services configurado incorretamente. Em 2017, dois buckets AWS S3 expuseram dados confidenciais de milhares de veteranos dos EUA e milhões de assinantes do cabo Time-Warner . O Microsoft Azure não ficou imune: uma empresa de segurança descobriu no ano passado que os dados de clientes em potencial podem ter sido comprometidos devido a um endpoint de armazenamento em nuvem mal configurado .
No último incidente, a Microsoft confirmou os detalhes do comunicado do Wiz , observando que a empresa contatou a Microsoft por meio do processo coordenado de divulgação de vulnerabilidades.
“Os dados expostos nesta conta de armazenamento incluíam backups de perfis de estações de trabalho de dois ex-funcionários e mensagens internas do Microsoft Teams desses dois funcionários com seus colegas”, afirmou o Microsoft Security Response Center (MSRC) em um comunicado. “Nenhum dado do cliente foi exposto e nenhum outro serviço interno foi colocado em risco por causa deste problema. Nenhuma ação do cliente é necessária em resposta a este problema.”
Acesso compartilhado em segredo
A funcionalidade SAS do Azure permite aos utilizadores conceder acesso específico a ficheiros e recursos específicos na sua conta de armazenamento. O usuário tem controle detalhado sobre os recursos que podem ser acessados, as permissões que o link permite e por quanto tempo o token SAS é válido. Existem três tipos diferentes de assinaturas de acesso compartilhado, incluindo delegação de usuário, serviço e tokens SAS de conta.
No entanto, os funcionários que permitem o acesso aos recursos não são facilmente monitorados, diz Luttwak da Wiz.
“Não há nenhuma maneira no Azure de monitorar quais permissões foram concedidas porque o Azure não sabe sobre todos os tokens que foram criados”, diz ele. “Isso significa que as equipes de segurança não têm como monitorar ou fazer qualquer governança sobre esses tokens. E isso é assustador.”
A Wiz não é a única empresa a alertar sobre os perigos do mecanismo de compartilhamento por link do Azure. As avaliações de segurança muitas vezes encontraram contas de armazenamento do Azure inseguras, mesmo que um cliente específico não tivesse problemas para proteger seus buckets de armazenamento do Amazon S3, afirmou Tom Ellson, chefe de segurança ofensiva do Jumpsec Labs, em um comunicado publicado no ano passado .
“As contas de armazenamento do Azure são o equivalente da Microsoft aos buckets do Amazon S3 e são suscetíveis a muitos dos mesmos desafios”, afirmou. “Ou seja, que – como acontece com outros serviços em nuvem – eles são frequentemente implantados por equipes sem o conhecimento de segurança para configurá-los de forma eficaz, e que as implantações padrão muitas vezes não terão o nível necessário de controles para seu ambiente, a menos que sejam explicitamente habilitadas pelo Equipe de TI.”
Apenas diga não?
Existem tantas armadilhas na configuração de tokens SAS que Luttwak da Wiz recomenda nunca usar o mecanismo para compartilhar arquivos de uma conta de armazenamento em nuvem privada. Em vez disso, as empresas deveriam ter uma conta pública a partir da qual os recursos sejam partilhados, diz ele.
“Este mecanismo é tão arriscado que a nossa recomendação é, em primeiro lugar, nunca partilhar dados públicos, dentro da sua conta de armazenamento – crie uma conta de armazenamento completamente separada apenas para partilha pública”, diz Luttwak. “Isso reduzirá bastante o risco de configuração incorreta. Você deseja compartilhar dados públicos, criar uma conta de armazenamento externo de dados públicos e usar apenas isso.”
Para as empresas que continuam desejando compartilhar arquivos específicos de armazenamento privado usando URLs SAS, a Microsoft adicionou o recurso como parte do monitoramento da exposição de credenciais e segredos do GitHub. A empresa digitalizou novamente todos os repositórios, afirmou a empresa em seu comunicado .
A Microsoft recomenda que os usuários do Azure se limitem a tokens SAS de curta duração, apliquem o princípio do menor privilégio e tenham um plano de revogação.
“Como qualquer segredo, os tokens SAS precisam ser criados e tratados de forma adequada”, afirmou a Microsoft no comunicado. “Como sempre, incentivamos fortemente os clientes a seguirem nossas melhores práticas ao usar tokens SAS para minimizar o risco de acesso ou abuso não intencional.”
FONTE: DARKREADING