AWS - Secrets Manager Post Exploitation

Reading time: 7 minutes

Secrets Manager

Para mais informações, consulte:

AWS - Secrets Manager Enum

Ler Secrets

Os secrets em si são informações sensíveis, consulte a página de privesc para saber como lê-los.

DoS — Alterar Valor do Secret

Alterando o valor do secret você pode causar DoS em todos os sistemas que dependem desse valor.

# Requires permission secretsmanager:PutSecretValue
aws secretsmanager put-secret-value \
--secret-id MyTestSecret \
--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"

DoS Change KMS key

Se o attacker tiver a permissão secretsmanager:UpdateSecret, o attacker pode configurar o secret para usar uma KMS key de propriedade do attacker. Essa KMS key é inicialmente configurada de forma que qualquer um pode acessá-la e usá-la, então atualizar o secret com a nova key é possível. Se a key não fosse acessível, o secret não poderia ser atualizado.

Depois de alterar a key do secret, o attacker modifica a configuração da sua key para que somente ele possa acessá-la. Dessa forma, nas versões subsequentes do secret, ele será criptografado com a nova key e, como não haverá acesso a ela, a capacidade de recuperar o secret será perdida.

É importante notar que essa inacessibilidade ocorrerá apenas em versões posteriores, após o conteúdo do secret mudar, já que a versão atual ainda está criptografada com a KMS key original.

aws secretsmanager update-secret \
--secret-id MyTestSecret \
--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE

DoS Deletando Secret

O número mínimo de dias para excluir um secret é 7

aws secretsmanager delete-secret \
--secret-id MyTestSecret \
--recovery-window-in-days 7

secretsmanager:RestoreSecret

É possível restaurar um secret, o que permite a restauração de secrets que foram agendados para exclusão, já que o período mínimo de exclusão para secrets é de 7 dias e o máximo é de 30 dias. Juntamente com a permissão secretsmanager:GetSecretValue, isso possibilita recuperar o conteúdo deles.

Para recuperar um secret que está em processo de exclusão, você pode usar o seguinte comando:

aws secretsmanager restore-secret \
--secret-id <Secret_Name>

secretsmanager:DeleteResourcePolicy

Essa ação permite excluir a política de recurso que controla quem pode acessar um segredo. Isso pode levar a um DoS se a política de recurso estiver configurada para permitir acesso a um conjunto específico de usuários.

Para excluir a política de recurso:

aws secretsmanager delete-resource-policy \
--secret-id <Secret_Name>

secretsmanager:UpdateSecretVersionStage

Os estados de um segredo são usados para gerenciar versões de um segredo. AWSCURRENT marca a versão ativa que as aplicações usam, AWSPREVIOUS mantém a versão anterior para que você possa reverter se necessário, e AWSPENDING é usado no processo de rotação para preparar e validar uma nova versão antes de torná-la a atual.

As aplicações sempre leem a versão com AWSCURRENT. Se alguém mover esse rótulo para a versão errada, as aplicações usarão credenciais inválidas e podem falhar.

AWSPREVIOUS não é usado automaticamente. No entanto, se AWSCURRENT for removido ou reatribuído incorretamente, pode parecer que tudo continua rodando com a versão anterior.

aws secretsmanager update-secret-version-stage \
--secret-id <your-secret-name-or-arn> \
--version-stage AWSCURRENT \
--move-to-version-id <target-version-id> \
--remove-from-version-id <previous-version-id>

Mass Secret Exfiltration via BatchGetSecretValue (até 20 por chamada)

Explorar a API Secrets Manager BatchGetSecretValue para recuperar até 20 secrets em uma única requisição. Isso pode reduzir dramaticamente o volume de chamadas de API em comparação com iterar GetSecretValue por secret. Se filtros forem usados (tags/name), a permissão ListSecrets também é necessária. O CloudTrail ainda registra um evento GetSecretValue por secret recuperado no batch.

Permissões necessárias

• secretsmanager:BatchGetSecretValue
• secretsmanager:GetSecretValue para cada secret alvo
• secretsmanager:ListSecrets se estiver usando --filters
• kms:Decrypt nos CMKs usados pelas secrets (se não estiver usando aws/secretsmanager)

Exfiltrate by explicit list

aws secretsmanager batch-get-secret-value \
--secret-id-list <secret1> <secret2> <secret3> \
--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'

Exfiltrar por filtros (tag chave/valor ou prefixo de nome)

# By tag key
aws secretsmanager batch-get-secret-value \
--filters Key=tag-key,Values=env \
--max-results 20 \
--query 'SecretValues[].{Name:Name,Val:SecretString}'

# By tag value
aws secretsmanager batch-get-secret-value \
--filters Key=tag-value,Values=prod \
--max-results 20

# By name prefix
aws secretsmanager batch-get-secret-value \
--filters Key=name,Values=MyApp

Lidando com falhas parciais

Em operações contra Secrets Manager você pode obter sucesso parcial — alguns secrets retornam corretamente enquanto outros falham. Não interrompa todo o processo por causa de falhas parciais; colete resultados bem‑sucedidos e registre os erros para tentativa posterior.

Principais práticas

• Classificar erros: diferencie NotFoundException/ResourceNotFoundException (secret ausente/deletado), AccessDenied/KMSAccessDenied (permissões), ThrottlingException (rate limit), InternalServiceError/ServiceUnavailable e InvalidRequestException.
• Retry para erros transitórios: use retry com backoff exponencial e jitter para ThrottlingException e erros internos.
• Persistir falhas para reprocessamento: salve itens com falha (arquivo, queue) para tentativas agendadas, evitando perda de dados.
• Tratar erros de permissão separadamente: registre o principal e o ARN do secret; não tente forçar acesso sem escalonamento apropriado.
• KMS failures: se a decrypt falhar por KMS, registre a keyId e considere acesso via outras roles/keys se disponível; sem decrypt o secret não é utilizável.
• Paginação e concorrência: pagine ListSecrets e implemente limites de concorrência para reduzir throttling.
• Logs estruturados: armazene secret name/ARN, código de erro, timestamp, operação e contexto para análise e auditoria.
• Manter idempotência e integridade: marque resultados parciais no agregador (quais campos faltam) e evite assumir dados completos.
• Segurança: trate secrets na memória com cuidado; remova e sobrescreva dados sensíveis mesmo em caminhos de erro.

Fluxo recomendado (resumido)

1. ListSecrets paginado.
2. Para cada secret: GetSecretValue com limites de concorrência.
3. Em caso de erro transitório: retry com backoff.
4. Em caso de erro permanente (AccessDenied, NotFound): registrar e continuar.
5. Persistir falhas para retries manuais/automatizados e gerar relatório final com sucesso/falhas.

# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>

Impacto

• Rápido “smash-and-grab” de muitos segredos com menos chamadas de API, potencialmente contornando alertas ajustados para picos de GetSecretValue.
• Os logs do CloudTrail ainda incluem um evento GetSecretValue por segredo recuperado pelo lote.