AWS - Persistência em Lambda

Reading time: 7 minutes

Lambda

Para mais informações, consulte:

AWS - Lambda Enum

Persistência em Lambda Layer

É possível introduzir/backdoor uma layer para executar arbitrary code quando a Lambda é executada de forma furtiva:

AWS - Lambda Layers Persistence

Persistência em Lambda Extension

Abusando de Lambda Layers também é possível abusar de extensions e persistir na Lambda, além de roubar e modificar requests.

AWS - Abusing Lambda Extensions

Via resource policies

É possível conceder acesso a diferentes ações do Lambda (como invoke ou update code) para contas externas:

Versões, Aliases & Weights

Uma Lambda pode ter different versions (com different code em cada versão).
Então, você pode criar different aliases apontando para different versions da função e definir diferentes weights para cada um.
Dessa forma, um atacante poderia criar uma backdoored version 1 e uma version 2 com apenas o legit code e executar somente a version 1 em 1% das requests para permanecer furtivo.

Version Backdoor + API Gateway

1. Copy the original code of the Lambda
2. Create a new version backdooring the original code (or just with malicious code). Publish and deploy that version to $LATEST
3. Call the API gateway related to the lambda to execute the code
4. Create a new version with the original code, Publish and deploy that version to $LATEST.
5. This will hide the backdoored code in a previous version
6. Go to the API Gateway and create a new POST method (or choose any other method) that will execute the backdoored version of the lambda: arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1
7. Note the final :1 of the arn indicating the version of the function (version 1 will be the backdoored one in this scenario).
8. Select the POST method created and in Actions select Deploy API
9. Now, when you call the function via POST your Backdoor will be invoked

Cron/Event actuator

O fato de você poder fazer lambda functions rodarem quando algo acontece ou quando passa um intervalo de tempo torna o Lambda uma forma comum de obter persistência e evitar detecção.
Aqui estão algumas ideias para tornar sua presença na AWS mais furtiva criando lambdas.

• Toda vez que um novo user é criado, a Lambda gera uma nova user key e envia para o atacante.
• Toda vez que uma nova role é criada, a Lambda concede permissões de assume role para usuários comprometidos.
• Toda vez que novos cloudtrail logs são gerados, deletar/alterar eles

RCE abusando de AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers

Abuse da variável de ambiente AWS_LAMBDA_EXEC_WRAPPER para executar um wrapper controlado pelo atacante antes do runtime/handler iniciar. Entregue o wrapper via um Lambda Layer em /opt/bin/htwrap, configure AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap e então invoque a função. O wrapper roda dentro do processo do runtime da função, herda a execution role da função e, por fim, faz exec do runtime real para que o handler original ainda seja executado normalmente.

AWS - Lambda Exec Wrapper Persistence

AWS - Lambda Function URL Public Exposure

Abuse de destinations assíncronas do Lambda junto com a configuração de Recursion para fazer uma função se re-invocar continuamente sem um agendador externo (sem EventBridge, cron, etc.). Por padrão, o Lambda termina loops recursivos, mas configurando recursion para Allow reativa-os. Destinations entregam do lado do serviço para invokes async, então um único invoke seed cria um canal stealthy de heartbeat/backdoor sem necessidade de código. Opcionalmente throttle com reserved concurrency para manter o ruído baixo.

AWS - Lambda Async Self Loop Persistence

AWS - Lambda Alias-Scoped Resource Policy Backdoor

Crie uma versão escondida da Lambda com lógica do atacante e aplique uma resource-based policy com escopo para aquela versão específica (ou alias) usando o parâmetro --qualifier em lambda add-permission. Conceda apenas lambda:InvokeFunction sobre arn:aws:lambda:REGION:ACCT:function:FN:VERSION a um principal atacante. Invocações normais via nome da função ou alias primário permanecem inalteradas, enquanto o atacante pode invocar diretamente o ARN da versão backdoored.

Isto é mais furtivo do que expor um Function URL e não altera o alias de tráfego primário.

AWS - Lambda Alias Version Policy Backdoor

Freezing AWS Lambda Runtimes

Um atacante que possui permissions lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, e lambda:GetRuntimeManagementConfig pode modificar a runtime management configuration de uma função. Este ataque é especialmente efetivo quando o objetivo é manter uma função Lambda em uma versão de runtime vulnerável ou preservar compatibilidade com layers maliciosas que podem ser incompatíveis com runtimes mais novos.

O atacante modifica a runtime management configuration para fixar a versão do runtime:

# Invoke the function to generate runtime logs
aws lambda invoke \
--function-name $TARGET_FN \
--payload '{}' \
--region us-east-1 /tmp/ping.json

sleep 5

# Freeze automatic runtime updates on function update
aws lambda put-runtime-management-config \
--function-name $TARGET_FN \
--update-runtime-on FunctionUpdate \
--region us-east-1

Verifique a configuração aplicada:

aws lambda get-runtime-management-config \
--function-name $TARGET_FN \
--region us-east-1

Opcional: Fixar em uma versão específica do runtime

# Extract Runtime Version ARN from INIT_START logs
RUNTIME_ARN=$(aws logs filter-log-events \
--log-group-name /aws/lambda/$TARGET_FN \
--filter-pattern "INIT_START" \
--query 'events[0].message' \
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)

Fixar em uma versão específica do runtime:

aws lambda put-runtime-management-config \
--function-name $TARGET_FN \
--update-runtime-on Manual \
--runtime-version-arn $RUNTIME_ARN \
--region us-east-1