Abusando da tabela curl do osquery para movimentação lateral na nuvem

Sobre o osquery

Muitas vezes precisamos responder algumas perguntas sobre o que está acontecendo em nosso Sistema Operacional, seja Linux, Mac, Windows, tanto para análise de performance, software rodando ou instalado, bem como uma resposta e análise de um incidente. Pensando em ter “todas as respostas” através de um formato simples, o Facebook criou a ferramenta osquery em 2014 e disponibilizou a mesma com uma licença open source.

O osquery basicamente consiste de tabelas (algumas estão em todos sistemas e outras são específicas) onde através de consultas SQL você consegue responder de forma simples a perguntas sobre um host, que de outra forma envolveriam diversas informações complexas e que teriam que ser obtidas em diferentes fontes.

Atualmente existem 257 tabelas que podem ser analisadas em https://osquery.io/schema/. A combinação das queries e tabelas te proporciona centenas de perguntas simples que poderão serem monitoradas continuamente (utilizando scheduled queries) e alertando em caso de mudanças nos resultados.

Uma grande premissa, porém, é que o osquery toma grandes cuidados para evitar que qualquer dado potencialmente confidencial armazenado pelo host seja exposto nas queries. Por exemplo, funcionalidades que permitem a leitura do conteúdo de arquivos nas máquinas não está habilitado por default. Esse é um ótimo princípio a seguir.

Por fim, é importante ressaltar que, por ser open source, o osquery é usado de forma explícita ou oculta em diversas ofertas de gerenciamento e segurança, como provedores de MDR, MSSP e EDR.

Explorando a tabela curl

Mas aí vale mencionar a existência da tabela curl. Esta tabela permite que você faça consultas que envolvem requisições HTTP, em efeito viabilizando o uso remoto de um equivalente limitado desta esta versátil ferramenta de linha de comando.

Estávamos fazendo alguns testes para o curso de osquery e Kolide que faremos dia 16/05/2020 e me veio o pensamento: O que aconteceria se eu usasse a tabela curl para pegar dados de um cluster Elasticsearch na rede interna da organização? E se fizermos requisições ao serviço EC2 instance metadata? E a resposta foi que sim, conseguimos obter acesso a dados sensíveis em uma configuração típica destes serviços.

Contextualizando a importância disso, nós aqui na Tenchi Security somos focados em segurança de nuvem. Portanto, imediatamente fomos investigar o uso desta tabela para acessar o EC2 instance metadata da AWS, que é descrito na documentação da seguinte forma: “Os metadados da instância são dados sobre sua instância que você pode usar para configurar ou gerenciar a instância em execução. Os metadados de instância são divididos em categorias, por exemplo, nome do host, eventos e grupos de segurança.”

Um dos usos mais importantes e frequentes deste serviço é para permitir que sejam concedidos privilégios a instâncias (máquinas virtuais) no serviço EC2 da AWS. Qualquer processo dentro da instância pode acessar o metadata service em http://169.254.169.254/. Quando são associadas permissões a uma instância, este serviço pode ser usado para obter credenciais temporárias (Access Key, Secret Key e Session Token) que podem ser usadas para realizar chamadas de API da AWS com os privilégios da instância.

Logo, um atacante que obtenha acesso de execução de consultas num parque de osquery pode fazer com que o osquery gere consultas ao metadata service. Obteria assim credenciais válidas de acesso às APIs da AWS, de forma conveniente e escalável, com os privilégios concedidos às diferentes instâncias. É, portanto, muito útil para um atacante buscando realizar movimentação lateral.

Vide abaixo um exemplo de consulta no osquery demonstrando esta técnica:

Uma vez em posse destas credenciais, um atacante poderia simplesmente criar um novo perfil no AWS CLI e começar a utilizá-las para explorar o nível de privilégios que conseguiu e dados interessantes para exfiltrar. Estes são alguns exemplos de comandos que poderiam ser utilizados para esta finalidade:

É importante notar que estas credenciais temporárias podem tipicamente ser utilizadas de qualquer lugar que tenha conectividade com as APIs da AWS, que estão expostas à Internet. Não há qualquer enforcement por padrão que impeça o atacante de usar estas credenciais em uma máquina externa sob seu controle para acessar suas contas de AWS e exfiltrar dados. Exemplos de ações de exfiltração que dependem apenas de chamadas de APIs de AWS incluem download de arquivos de buckets S3, ou queries em bases de dados DynamoDB ou RDS.

Mitigações

Uma maneira efetiva de mitigar essa ameaça na AWS é forçar o uso da versão 2 do serviço de instance metadata. Dado que ele exige o uso de cabeçalhos HTTP customizados, que a tabela curl do osquery não permite especificar, ele protege adequadamente contra esta técnica. Vale porém se certificar de que todo o software rodando no seu parque usa SDKs atualizados que funcionam corretamente com esta nova versão do serviço, porque nem a própria AWS parece conseguir fazer isso.

Caso não faça uso dessa tabela no osquery, sugerimos desabilitá-la no seu osquery (–disable_tables curl), diminuindo essa possibilidade de movimentação.

Em nossa opinião os mantenedores do projeto osquery deveriam desabilitar esta tabela desabilitada por padrão por motivos de segurança, similar ao que foi feito com as tabelas de carving. Nós abrimos um issue no repositório GitHub do projeto que você pode ver e acompanhar aqui.

Alternativamente poderia ser implementada uma filtragem por padrão para bloquear acessos às URLs envolvidas na obtenção de credenciais usando o EC2 intance metadata service. Mas esta seria uma abordagem de default allow que ainda permitiria ataques a outros serviços internos não autenticados como Elasticsearch e MongoDB para citar apenas dois.

Segundo Guillaume Ross, Principal Product Manager na Uptycs, “Yes, the curl table can be used to target other systems, like AWS in your example, but also other local systems. Hypothetically, it could be used by someone to query IoT devices on home networks of employees. Of course, granting access to osquery data period provides those analysts with privileged data, which is the same with most other security tools. To help manage this responsibility, we believe some tables, like curl, should be off by default so it’s a conscious decision by an administrator to grant access. We’ve updated our version of osquery to disable the curl table by default, just like the file carving table. The use of the enable_curl flag is now required to turn it on. The Uptycs platform itself also allows the use of roles, so that not everyone with access to osquery data can change the configurations.”

Em resumo, assegure-se de estar controlando adequadamente o acesso e privilégios de consulta à sua plataforma de gestão de osquery. Dependendo de qual solução de gerenciamento você usa para os agentes osquery, é possível que você tenha capacidades de controle de acesso e monitoramento que te permitam reduzir os riscos associados à tabela curl.

Se você é cliente de um fornecedor de serviços gerenciados (MSSP, MDR ou solução SaaS) com acesso de consulta ao seu parque osquery, a existência da tabela curl viola a expectativa de que este acesso é apenas de leitura e não pode ser utilizado para fazer movimentação lateral ou ganhar acesso indevido ao seu ambiente. Portanto, é essencial levar isto em consideração em sua gestão de risco.

Happy Detection!

Este blog post foi escrito por Rodrigo Montoro e Alexandre Sieira, com base em pesquisa realizada por Rodrigo Montoro.

Atualizado em 21 de maio para incluir declaração dada pela Uptycs.