Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Amazon DynamoDB é apresentado pela AWS como um banco de dados NoSQL, chave-valor, totalmente gerenciado e sem servidor, projetado para alimentar aplicações de alto desempenho, independentemente de seu tamanho. O serviço garante recursos robustos, incluindo medidas de segurança inerentes, backups ininterruptos, replicação automatizada em várias regiões, cache em memória integrado e utilitários convenientes de exportação de dados.
No contexto do DynamoDB, em vez de estabelecer um banco de dados tradicional, tabelas são criadas. Cada tabela exige a especificação de uma chave de partição como um componente integral da chave primária da tabela. Essa chave de partição, essencialmente um valor hash, desempenha um papel crítico tanto na recuperação de itens quanto na distribuição de dados entre vários hosts. Essa distribuição é fundamental para manter tanto a escalabilidade quanto a disponibilidade do banco de dados. Além disso, há a opção de incorporar uma chave de ordenação para refinar ainda mais a organização dos dados.
Por padrão, o DynamoDB usa uma chave KMS que pertence ao Amazon DynamoDB, nem mesmo a chave gerenciada pela AWS que pelo menos pertence à sua conta.
É possível agendar a geração de backups de tabelas ou criá-los sob demanda. Além disso, também é possível habilitar a recuperação ponto-a-ponto (PITR) para uma tabela. A recuperação ponto-a-ponto fornece backups contínuos dos seus dados do DynamoDB por 35 dias para ajudar a proteger contra operações de escrita ou exclusão acidentais.
Também é possível exportar os dados de uma tabela para o S3, mas a tabela precisa ter PITR habilitado.
Há uma GUI para serviços locais do Dynamo, como DynamoDB Local, dynalite, localstack, etc, que pode ser útil: https://github.com/aaronshaf/dynamodb-admin
Existem maneiras de acessar dados do DynamoDB com sintaxe SQL, portanto, injeções SQL típicas também são possíveis.
No DynamoDB, diferentes condições podem ser usadas para recuperar dados, como em uma injeção NoSQL comum. Se for possível encadear mais condições para recuperar dados, você pode obter dados ocultos (ou despejar toda a tabela). Você pode encontrar aqui as condições suportadas pelo DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html
Observe que diferentes condições são suportadas se os dados estiverem sendo acessados via query ou via scan.
Na verdade, as ações de Query precisam especificar a condição "EQ" (igual) na chave primária para funcionar, tornando-a muito menos propensa a injeções NoSQL (e também limitando muito a operação).
Se você puder mudar a comparação realizada ou adicionar novas, poderá recuperar mais dados.
Essa vulnerabilidade é baseada no Filtro de Varredura do dynamodb, que agora está obsoleto!
DynamoDB aceita objetos Json para pesquisar dados dentro do DB. Se você descobrir que pode escrever no objeto json enviado para pesquisa, você pode fazer o dump do DB, todo o conteúdo.
Por exemplo, injetando em uma solicitação como:
um atacante poderia injetar algo como:
1000"}],"ComparisonOperator": "GT","AttributeValueList": [{"N": "0
corrija a condição "EQ" buscando o ID 1000 e, em seguida, procurando todos os dados com uma string de Id maior que 0, que é tudo.
Outro exemplo vulnerável usando um login poderia ser:
Isto seria vulnerável a:
Alguns SDKs permitem usar uma string indicando o filtro a ser realizado, como:
Você precisa saber que, ao pesquisar no DynamoDB para substituir um valor de atributo em expressões de filtro enquanto escaneia os itens, os tokens devem começar com o caractere :. Esses tokens serão substituídos pelo valor do atributo real em tempo de execução.
Portanto, um login como o anterior pode ser contornado com algo como:
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
