Segurança das informações da Netflix: impedindo o comprometimento de credenciais na AWS

Netflix Technology Blog Blocked Unblock Seguir Seguindo 28 de novembro de 2018

por Will Bengtson

Anteriormente, escrevemos sobre um método para detectar comprometimento de credenciais em seu ambiente da AWS. A metodologia focada em um modelo de aprendizagem contínua e primeiro princípio de uso. Essa solução ainda é reativa por natureza – só detectamos comprometimento de credenciais depois que isso já aconteceu. Mesmo com os recursos de detecção, existe o risco de que as credenciais expostas possam fornecer acesso a dados confidenciais e / ou a capacidade de causar danos em nosso ambiente.

Hoje, gostaríamos de compartilhar duas camadas adicionais de segurança: aplicação da API e proteção de metadados. Essas camadas podem ser usadas para ajudar a evitar comprometimento de credenciais em seu ambiente.

Escopo

Neste post, discutiremos como evitar ou reduzir o comprometimento de credenciais devido a certas classes de vulnerabilidades, como a injeção SSRF (Server Side Request Forgery) e a External Entity (XXE) XML. Se um invasor tiver execução remota de código (RCE) ou presença local no servidor da AWS, esses métodos discutidos não impedirão o comprometimento. Para obter mais informações sobre como os serviços da AWS mencionados funcionam, consulte a seção Background no final deste post.

Protegendo Suas Credenciais

Há várias maneiras de proteger suas credenciais temporárias da AWS. Os dois métodos abordados aqui são:

  • Impondo onde as chamadas de API podem ser originadas.
  • Proteger o serviço de Metadados EC2 para que as credenciais não possam ser recuperadas por meio de uma vulnerabilidade em um aplicativo, como SSRF (Server Side Request Forgery).

Aplicação Credencial

A imposição de credenciais só permite que chamadas de API sejam bem-sucedidas se forem originadas de um ambiente conhecido. Na AWS, isso pode ser obtido com a criação de uma política do IAM que verifica a origem da chamada da API. Para conseguir isso, é importante entender de onde vêm as chamadas de API (descritas abaixo em Background). Uma política de exemplo é mostrada abaixo.

Uma maneira de implantar isso é criar uma política gerenciada que englobe toda a sua conta em todas as regiões. Para fazer isso, descreva cada região e colete seus IPs de gateway NAT, IDs de VPC e IDs de terminal VPC para criar o idioma da política gerenciada (semelhante ao exemplo acima) que pode ser anexada às funções do IAM que você deseja proteger. . A limitação desse método é que você só pode proteger as Funções do IAM que são usadas em instâncias do EC2 implantadas na sub-rede interna. IAM As funções associadas às instâncias do EC2 na sub-rede externa devem ser excluídas. Expor seu serviço publicamente por meio de um Load Balancer permitiria que você implantasse sua instância do EC2 na sub-rede interna e permitisse que você anexasse essa política à sua função do IAM.

Outra limitação a esse método é que a AWS geralmente faz chamadas em seu nome que são acionadas por determinadas chamadas da API. Por exemplo, quando você restaura uma instância do RDS criptografada, a AWS fará chamadas do KMS em seu nome para descobrir qual chave deve ser usada no processo de restauração. Quando esses serviços fazem chamadas para você, as credenciais da AWS vinculadas à função do IAM que fez a primeira chamada são usadas. O endereço IP de origem será um da AWS e não refletirá o que está na sua política. Você pode ver isso no CloudTrail procurando por eventos com sourceIPAddress parecido com <service> .amazonaws.com . Mesmo com essa limitação, você descobrirá que pode proteger a maioria das funções do IAM e encontrar soluções alternativas para resolver isso.

Proteção de Serviço de Metadados

Conforme descrito acima, o serviço de Metadados do EC2 é o mecanismo para fornecer credenciais ao seu aplicativo em execução em uma instância do EC2 na AWS. Está disponível fazendo uma solicitação para o endereço IP 169.254.169.254. O atual serviço de Metadados da AWS não exige que nenhum cabeçalho HTTP esteja presente e permite que qualquer processo faça solicitações HTTP.

A SSRF (Server Side Request Forgery) é uma vulnerabilidade que permite que um invasor engane o aplicativo para fazer solicitações HTTP / HTTPS em seu nome. Um dos ataques mais comuns contra aplicativos vulneráveis ao SSRF é o destino do caminho da credencial do serviço de metadados. Quando um invasor explora uma vulnerabilidade do SSRF, ele não pode controlar quais cabeçalhos HTTP são enviados na solicitação. A falta de controle de cabeçalho por um invasor permite um cabeçalho obrigatório no serviço de metadados para atenuar essa classe de vulnerabilidade. Se um invasor puder definir cabeçalhos HTTP, como ter um shell no servidor e controlar cabeçalhos em um comando curl, a proteção de cabeçalho será útil na proteção contra um invasor que não perceba que há um cabeçalho necessário.

Se o serviço de Metadados exigisse um cabeçalho HTTP ao falar com ele, o vetor de ataque do SSRF que visa roubar suas credenciais da AWS pode ser atenuado. No passado, não era possível criar seu próprio proxy de metadados para proteger o serviço de metadados contra ataques como o SSRF. Os proxies de metadados que você pode encontrar em código-fonte aberto geralmente têm como escopo fornecer credenciais para contêineres em execução em seus hosts e não proteger contra esses ataques. Temos trabalhado com a AWS para habilitar a capacidade de proteção contra esse ataque definindo o cabeçalho HTTP do agente do usuário ao fazer solicitações ao serviço de metadados a partir dos SDKs da AWS para algo conhecido. Sabendo quais User-Agents serão definidos quando os SDKs oficiais da AWS fizerem solicitações ao serviço de metadados e combinando isso com o fato de que no cenário de vulnerabilidade do SSRF você não pode controlar cabeçalhos HTTP, agora podemos direcionar tráfego para o serviço de metadados e rejeitar solicitações sem o cabeçalho HTTP do agente do usuário apropriado, reduzindo assim o vetor de ataque do SSRF nas credenciais do AWS.

Os User-Agents atuais que você verá quando o tráfego de proxy dos SDKs começar com as seguintes strings:

Resumo

A configuração padrão na nuvem deixa seu ambiente sob maior risco no caso de exposição / comprometimento de credenciais. Acoplar um proxy de metadados com a imposição de API aumenta a postura de segurança do seu ambiente da AWS, implementando proteções de defesa em profundidade. Combinar essa abordagem com o Detecting Credential Compromise na AWS abre caminho para a proteção do IAM em seu ambiente de nuvem.

Não deixe de nos informar se você implementar isso, ou algo melhor, em seu próprio ambiente.

Will Bengtson, pelas ferramentas e operações de segurança da Netflix