Bem-vindo ao nosso blogue.

Prevenir a tomada total da nuvem através de ataques SSRF

Esta é a história de um atacante que obteve acesso aos buckets Amazon S3 de uma startup, variáveis de ambiente e vários segredos internos de API, tudo através de um simples formulário que envia um e-mail. Apesar de ser uma história verídica, estou a manter o nome da startup em segredo.

Como entraram

Tudo começa com uma aplicação PHP a enviar uma mensagem de correio eletrónico. Para carregar algumas das imagens de fantasia para o e-mail como anexos, a aplicação precisa de as descarregar. Em PHP, isto é fácil. Utiliza-se a função file_get_contents e é aí que começa a diversão.

É claro que algumas das entradas do utilizador para esta mensagem de correio eletrónico não foram totalmente verificadas ou codificadas em HTML, pelo que um utilizador poderia incluir uma imagem como <img src=’evil.com’/>. Agora, em teoria, isto não é assim tão mau, mas infelizmente esta função do PHP é muito poderosa e pode fazer muito mais do que carregar imagens através da Internet. Também pode ler ficheiros locais e, mais importante ainda: ficheiros através da rede local em vez da Internet.

Em vez de evil.com, o atacante inseriu um URL local especial. Pode utilizar este URL para obter as credenciais IAM associadas à função do servidor AWS EC2 que está a executar com um simples pedido GET.

<img src=’http://169.254.169.254/latest/meta-data/'>

O resultado foi que o atacante recebeu um e-mail que incluía as credenciais IAM do servidor EC2 num anexo da caixa de correio. Essas chaves dão ao atacante a capacidade de se fazer passar por esse servidor ao falar com vários serviços AWS. A partir daí, tudo vai por água abaixo...

Porque é que isto é possível?

O sistema que carrega essas chaves IAM é chamado IMDSv1 e a Amazon lançou uma nova versão em 2019 chamada IMDSv2. Com o IMDSv2, você precisa enviar uma solicitação PUT com um cabeçalho especial para obter suas credenciais de IAM. Isso significa que uma simples função de carregamento de URL baseada em GET, como file_get_contents, não pode mais causar tantos danos.

Não é claro qual será a adoção do IMDSv2 a partir de 2023, mas é evidente que a Amazon ainda está a tomar medidas para aumentar a sua adoção e estamos a ver que o IMDSv1 ainda está a ser utilizado na natureza.

O comprometimento das chaves IAM leva a outros comprometimentos: Os buckets S3 podiam ser listados e o seu conteúdo lido. Para piorar a situação, um dos buckets S3 continha um modelo de cloudformation, que continha variáveis de ambiente sensíveis (por exemplo, chaves da API Sendgrid).

Como é que defendo a minha infraestrutura de nuvem contra isto?

Agora, o que poderia ser feito para evitar essa perda total de dados? Os seus programadores poderiam ser extremamente cuidadosos e ter o cuidado de utilizar uma lista de permissões para os URLs que passam para file_get_contents. Podem até verificar se o conteúdo que recebem é uma imagem, se estiverem à espera de uma imagem. No entanto, a realidade é que este tipo de erros é difícil de evitar enquanto programador.

Seria muito melhor garantir que a sua infraestrutura tem defesas adicionais contra estes ataques. A nossa nova integração com a AWS dentro da segurança Aikido irá alertá-lo se a sua nuvem não tomar ativamente nenhuma das seguintes medidas. Cada uma destas medidas, por si só, teria impedido este ataque específico, mas recomendamos a implementação de todas elas. Utilize a nossa conta de avaliação gratuita para ver se a sua nuvem já está protegida contra estas ameaças. Veja como o Aikdido protege a sua aplicação contra vulnerabilidades aqui.

Medidas a adotar:

1. Migrar os nós EC2 IMDSv1 existentes para utilizar o IMDSv2
2. Não armazene nenhum segredo no ambiente dos seus servidores Web ou em modelos de formação de nuvem. Use uma ferramenta como o AWS Secrets Manager para carregar os segredos em tempo de execução.
3. Ao atribuir funções de IAM aos seus servidores EC2, certifique-se de que têm condições adicionais, como restringi-las a serem utilizadas apenas a partir da sua rede AWS local (a sua VPC). O exemplo abaixo permite que o seu servidor leia do S3, mas apenas se o servidor EC2 estiver a comunicar através de um ponto de extremidade VPC específico. Isto só é possível a partir da sua rede, pelo que o atacante não teria sido capaz de aceder aos buckets S3 a partir da sua máquina local.

{
"Version": "2012-10-17",
"Statement": [
       {
"Sid": "rule-example",
"Effect": "Allow",
"Action": "s3:getObject",
"Resource": "arn:aws:s3:::bucketname/*",
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1s0d54f8e1f5e4fe"
               }
           }
       }
   ]
}

Sobre "The Kill Chain"

The Kill Chain é uma série de histórias reais de atacantes que chegam às jóias da coroa de empresas de software encadeando várias vulnerabilidades. Escrito por Willem Delbare, aproveitando os seus dez anos de experiência na construção e apoio a startups SaaS como CTO. As histórias vêm diretamente da rede de Willem e todas elas aconteceram realmente.

A startup belga de SaaS Aikido Security angariou 2 milhões de euros em financiamento pré-semente de investidores-anjo de renome que apoiam a sua missão de simplificar a segurança do software para os programadores.

Nos últimos anos, tem havido uma mudança na indústria do software para o desenvolvimento "shift left", o que tem empurrado a responsabilidade pela segurança cada vez mais para os programadores. Infelizmente, as actuais plataformas de segurança de software são difíceis de utilizar pelos programadores, desperdiçando muito do seu tempo. A Aikido Security foi fundada para responder a este desafio.

A ronda de pré-semente tem a sorte de contar com o apoio de uma série de investidores (anjos) qualificados. Syndicate One, Pieterjan Bouten (Showpad), Louis Jonckheere (Showpad), Christophe Morbee (Besox), Mathias Geeroms (OTA Insight) decidiram juntar-se a nós. A Aikido Security tem a sorte de poder contar com o seu apoio e experiência.

"As ferramentas de segurança de software tornaram a minha vida de CTO mais difícil"

afirma o fundador e CTO da Aikido Security, Willem Delbare. "Testei muitos deles e todos sofrem dos mesmos problemas. Sobrecarregam-nos com falsos positivos, enviam-nos spam com notificações e dificultam a triagem. Achei que era muito cansativo. Decidimos resolver este problema".

A equipa é constituída por empresários experientes que criaram produtos de sucesso em vários sectores antes de se juntarem na Aikido Security. A equipa fundadora é constituída por Willem Delbare (Teamleader, Officient), Roeland Delrue (Showpad, Officient), Amber Rucker (Veriff, Cloudbees) e Felix Garriau (nexxworks, AREA42).

A Aikido completou recentemente a versão alfa do seu produto, que está a testar ativamente com os primeiros clientes. O financiamento permite à empresa aumentar a sua equipa e completar as funcionalidades do produto, para além de aumentar a sua base de clientes.

Acerca da Segurança Aikido

Aikido Security é uma plataforma de segurança de software que coloca o desenvolvedor em primeiro lugar. Analisamos o seu código-fonte e a nuvem para lhe mostrar quais as vulnerabilidades que são realmente importantes para resolver. A triagem é acelerada através da redução massiva de falsos positivos e tornando os CVEs legíveis por humanos. O Aikido torna simples manter o seu produto seguro e devolve-lhe tempo para fazer o que faz melhor: escrever código.

Os ficheiros de bloqueio desempenham um papel vital na segurança da cadeia de fornecimento de software através de uma gestão consistente das dependências. Especificam as versões exactas das dependências utilizadas, assegurando a reprodutibilidade e evitando alterações inesperadas.

Num ambiente de desenvolvimento acelerado, repleto de bibliotecas de código aberto e pacotes de terceiros, os ficheiros de bloqueio funcionam como uma defesa contra ataques à cadeia de fornecimento. Ao bloquear dependências para versões específicas, impedem actualizações automáticas para versões potencialmente comprometidas.

Muitas equipas de desenvolvimento ignoram os ficheiros de bloqueio, não conseguindo utilizar todo o seu potencial. Este artigo destaca a importância dos ficheiros de bloqueio para garantir a integridade e a segurança do projeto de software.

Compreender os ficheiros de bloqueio

Os arquivos de bloqueio são arquivos que capturam as versões exatas de cada dependência e suas subdependências em um projeto. Garantem a uniformidade das versões das dependências em todas as instâncias de um projeto, evitando o "inferno das dependências" e potenciais riscos de segurança.

Os ficheiros de bloqueio são diferentes para cada língua e podem diferir consoante as estruturas, mas geralmente seguem formatos semelhantes.

Javascript - yarn.lock

lodash@^4.17.15:
  versão "4.17.21"
 resolvido "https://registry.yarnpkg.com/lodash/-/lodash-4.17.21.tgz#acfcd7438b5d260f06a1d052c2a3b32ddc91c6b8"
 integridade sha512-v2kDE6syb5rK+X8bykjh3W7n4P3NV8axFypa8DwO8DK+RVZk9vft6xEhjxzIlc6DCwCPkMKSk4eQF6QNHOu9pw==

react@^17.0.1:
  versão "17.0.2"
 resolvido "https://registry.yarnpkg.com/react/-/react-17.0.2.tgz#cdc8d94b0d7091f440c51d1427ff2a3d6e14e664"
 integridade sha512-y8vQ43+qMOpbD/3k1Vw4E4i4UgFqxMwI0AZc5fxyIfZK4kHRZ5Klg5zh/5Nq1Nk3JZqf6byFAkyoGZkbSnYt9w==

Python - poetry.lock

[[package]]
name = "requests"
version = "2.25.1"
description = "Python HTTP for Humans."
category = "main"
optional = false
python-versions = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4"

[package.dependencies]
certifi = ">=2017.4.17"
chardet = ">=3.0.2,<5"
idna = ">=2.5,<3"
urllib3 = ">=1.21.1,<1.27"

Esta entrada especifica o nome do pacote (clique), os hashes aceites e a versão exacta (8.0.3). Essa especificidade garante instalações consistentes em ambientes de desenvolvimento, teste e produção.

Os gestores de pacotes geram ficheiros de bloqueio durante a instalação de dependências ou actualizações. É essencial submeter estes ficheiros ao controlo de versões com o código-fonte do projeto. Esta prática garante que todos os colaboradores do projeto utilizam dependências idênticas, reduzindo as inconsistências e tornando as compilações mais previsíveis.

Diferentes linguagens e gerenciadores de pacotes têm seus próprios formatos de arquivo de bloqueio: O Node.js usa o package-lock.json para o npm, o Python usa o Pipfile.lock para o Pipenv e o Ruby usa o Gemfile.lock para o Bundler. O uso de lockfiles ajuda a manter uma base de projeto consistente e segura, reduzindo os riscos associados ao gerenciamento de dependências.

Defesa contra ataques à cadeia de abastecimento

Os ataques à cadeia de abastecimento em dependências de código aberto são cada vez mais comuns. Os atacantes podem comprometer uma biblioteca popular, injectando código malicioso que se espalha para projectos dependentes. Os arquivos de bloqueio fornecem uma forte defesa contra esses ataques.

Ao especificar as versões exactas das dependências, os ficheiros de bloqueio evitam actualizações automáticas para versões potencialmente comprometidas. Isto é crucial quando são identificadas vulnerabilidades nas dependências. Com os ficheiros de bloqueio, os projectos permanecem estáveis com versões seguras conhecidas até que a equipa decida atualizar após testes exaustivos.

Abaixo está um exemplo de um package-lock.json usado em projetos Node.js para bloquear versões específicas de dependências. Isso garante que todos que trabalham no projeto instalem exatamente as mesmas versões, promovendo consistência e segurança.

{
  "name": "my-project",
  "version": "1.0.0",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {
      "name": "my-project",
      "version": "1.0.0",
      "dependencies": {
        "lodash": "4.17.21",
        "axios": "0.21.1"
      }
    },
    "node_modules/lodash": {
      "version": "4.17.21",
      "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "integrity": "sha512-v2kDE6syb5rK+X8bykjh3W7n4P3NV8axFypa8DwO8DK+RVZk9vft6xEhjxzIlc6DCwCPkMKSk4eQF6QNHOu9pw=="
    },
    "node_modules/axios": {
      "version": "0.21.1",
      "resolved": "https://registry.npmjs.org/axios/-/axios-0.21.1.tgz",
      "integrity": "sha512-pbkHfFgC6F4ltGeoyTeHRtUkZo/FZ9EoElV3MzDLeO2uYxLqGm6Qcbx93jUOJISyYSC/tzjK4NHH3MAYsDKUTA==",
      "dependencies": {
        "follow-redirects": "^1.10.0"
      }
    },
    "node_modules/follow-redirects": {
      "version": "1.14.1",
      "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.14.1.tgz",
      "integrity": "sha512-0gh4nEbdUdDra9mJKpAB+Y4gG61sQiKsbiqS8c5LEnFOh8fbov3/xp0FnWE2+IxKTozhJSdEV8ujvQjU+Ub3dg=="
    }
  },
  "dependencies": {
    "lodash": {
      "version": "4.17.21",
      "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "integrity": "sha512-v2kDE6syb5rK+X8bykjh3W7n4P3NV8axFypa8DwO8DK+RVZk9vft6xEhjxzIlc6DCwCPkMKSk4eQF6QNHOu9pw=="
    },
    "axios": {
      "version": "0.21.1",
      "resolved": "https://registry.npmjs.org/axios/-/axios-0.21.1.tgz",
      "integrity": "sha512-pbkHfFgC6F4ltGeoyTeHRtUkZo/FZ9EoElV3MzDLeO2uYxLqGm6Qcbx93jUOJISyYSC/tzjK4NHH3MAYsDKUTA==",
      "requires": {
        "follow-redirects": "^1.10.0"
      }
    },
    "follow-redirects": {
      "version": "1.14.1",
      "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.14.1.tgz",
      "integrity": "sha512-0gh4nEbdUdDra9mJKpAB+Y4gG61sQiKsbiqS8c5LEnFOh8fbov3/xp0FnWE2+IxKTozhJSdEV8ujvQjU+Ub3dg=="
    }
  }
}

O que faz este ficheiro

• Bloqueia versões específicas:
  Bloqueia chicote na versão 4.17.21 e áxis em 0.21.1. Independentemente de quando ou onde instalar este projeto, serão utilizadas estas versões exactas - evitando actualizações acidentais para versões que possam conter alterações de rutura ou problemas de segurança.
• Captura a árvore de dependências:
  Inclui dependências aninhadas, como seguir-redirecções, que é utilizado internamente por áxis.
• Suporta ferramentas de segurança:
  Ferramentas como Aikido utilizam este ficheiro de bloqueio para procurar vulnerabilidades conhecidas. Uma vez que o ficheiro contém URLs resolvidos e hashes de versão, os scanners podem:
  • Identificar com exatidão os pacotes de risco.
  • Recomendar alternativas corrigidas ou seguras.
  • Acompanhar as alterações às dependências ao longo do tempo.

Riscos de ignorar os ficheiros de bloqueio

Negligenciar os ficheiros de bloqueio pode desestabilizar e comprometer os projectos de software. Sem lockfiles, as versões de dependência podem variar entre ambientes, levando a inconsistências que complicam a depuração. Estas variações podem causar bugs evasivos, atrasando projectos e aumentando os encargos de manutenção.

Sem um ficheiro de bloqueio, o acompanhamento das dependências torna-se um desafio. A ausência de um registo claro torna difícil determinar que versões são utilizadas, complicando a gestão da cadeia de fornecimento. No caso de uma vulnerabilidade, os programadores têm dificuldade em identificar rapidamente as dependências de risco, atrasando os tempos de resposta.

As actualizações automáticas representam riscos significativos quando os ficheiros de bloqueio estão ausentes. As actualizações não controladas podem introduzir pacotes comprometidos, expondo os projectos a falhas de segurança. Até mesmo bibliotecas respeitáveis podem abrigar ameaças ocultas, tornando a supervisão dos arquivos de bloqueio crucial para manter uma base de código segura.

Melhores práticas para a utilização de ficheiros de bloqueio

Integre os ficheiros de bloqueio no seu fluxo de trabalho de desenvolvimento para tirar o máximo partido dos mesmos. A inclusão de ficheiros de bloqueio no controlo de versões estabelece uma única fonte de verdade para as dependências, promovendo um ambiente de desenvolvimento consistente. Esta abordagem reduz as variações indesejadas e aumenta a fiabilidade da produção.

A atualização e revisão regular dos ficheiros de bloqueio é vital para a deteção precoce de ameaças. Esta estratégia proactiva ajuda as equipas a resolver rapidamente as vulnerabilidades, mantendo uma forte postura de segurança. Utilize ferramentas para avaliação contínua de dependências para automatizar a deteção de riscos na cadeia de fornecimento de software.

A ancoragem de dependências a versões específicas em ficheiros de manifesto aumenta a segurança. Essa prática complementa os arquivos de bloqueio e serve como uma rede de segurança em caso de discrepâncias. Educar as equipas de desenvolvimento sobre a importância dos ficheiros de bloqueio reforça a gestão diligente das dependências, aumentando a segurança geral.

Mantendo as Dependências Atualizadas com Lockfiles

Manter as dependências actualizadas requer a combinação da automatização com uma revisão minuciosa. As actualizações de rotina dos ficheiros de bloqueio devem fazer parte dos ciclos de desenvolvimento, incorporando as últimas melhorias e correcções de segurança, preservando a consistência. As actualizações regulares minimizam as interrupções inesperadas e reforçam a segurança.

Ferramentas automatizadas como o Dependabot ajudam a gerir as actualizações, gerando pedidos pull para novas versões de dependências. Estas ferramentas fornecem monitorização contínua, permitindo actualizações atempadas e permitindo que as equipas se concentrem noutras tarefas. No entanto, é crucial rever as alterações para garantir que satisfazem as necessidades do projeto e evitar problemas.

O desenvolvimento de um processo de atualização manual de ficheiros de bloqueio é também essencial. Implementar dependências actualizadas num ambiente de teste para avaliar o impacto e a compatibilidade. Esta abordagem evita interrupções e mantém a coerência, minimizando os riscos de mudanças frequentes de versão.

A incorporação de ficheiros de bloqueio no seu processo de desenvolvimento reforça a sua cadeia de fornecimento de software contra ameaças de segurança em evolução. A adoção de melhores práticas e a promoção da consciência de dependência na sua equipa são fundamentais para manter uma base de código robusta. Pronto para melhorar a segurança da sua cadeia de fornecimento? Comece gratuitamente com o Aikido e simplifique o seu percurso de segurança.