mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 03:16:37 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-persistence/aws-lambd
This commit is contained in:
@@ -4,7 +4,7 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
Para mais informações consulte:
|
||||
Para mais informações veja:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
@@ -12,7 +12,7 @@ Para mais informações consulte:
|
||||
|
||||
### Lambda Layer Persistence
|
||||
|
||||
É possível **introduzir/backdoor uma Layer para executar código arbitrário** quando a lambda é executada de forma furtiva:
|
||||
É possível **introduzir/backdoor um layer para executar código arbitrário** quando a Lambda é executada de forma furtiva:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
|
||||
|
||||
### Lambda Extension Persistence
|
||||
|
||||
Abusando de Lambda Layers também é possível abusar de extensions e persistir no lambda, além de roubar e modificar requests.
|
||||
Abusando de Lambda Layers, também é possível abusar de extensions e persistir na lambda, além de roubar e modificar requisições.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
@@ -28,42 +28,42 @@ aws-abusing-lambda-extensions.md
|
||||
|
||||
### Via resource policies
|
||||
|
||||
É possível conceder acesso a diferentes ações do lambda (como invoke ou update code) para contas externas:
|
||||
É possível conceder acesso a diferentes ações da lambda (como invoke ou update code) para contas externas:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versions, Aliases & Weights
|
||||
|
||||
Uma Lambda pode ter **diferentes versões** (cada versão com código diferente).\
|
||||
Então, você pode criar **diferentes aliases com diferentes versões** da lambda e definir pesos diferentes para cada um.\
|
||||
Dessa forma um atacante poderia criar uma **backdoored version 1** e uma **version 2 com apenas o código legítimo** e **executar a version 1 em apenas 1%** das requisições para permanecer furtivo.
|
||||
Uma Lambda pode ter **versões diferentes** (com código diferente em cada versão).\
|
||||
Então, você pode criar **aliases diferentes com versões diferentes** da Lambda e definir pesos diferentes para cada.\
|
||||
Dessa forma um atacante poderia criar uma **versão 1 backdoored** e uma **versão 2 com apenas o código legítimo** e **executar a versão 1 em apenas 1%** das requisições para permanecer furtivo.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Version Backdoor + API Gateway
|
||||
|
||||
1. Copie o código original da Lambda
|
||||
2. **Create a new version backdooring** o código original (ou apenas com código malicioso). Publique e **implante essa versão** para $LATEST
|
||||
1. Chame o API Gateway relacionado à lambda para executar o código
|
||||
3. **Crie uma nova versão com o código original**, Publique e implante essa **version** para $LATEST.
|
||||
2. **Create a new version backdooring** o código original (ou apenas com código malicioso). Publish e **deploy that version** para $LATEST
|
||||
1. Chame o API Gateway relacionado à Lambda para executar o código
|
||||
3. **Create a new version with the original code**, Publish e deploy essa **version** para $LATEST.
|
||||
1. Isso esconderá o código backdoored em uma versão anterior
|
||||
4. Vá ao API Gateway e **crie um novo método POST** (ou escolha qualquer outro método) que executará a versão backdoored da lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Observe o final :1 do arn **indicando a versão da função** (version 1 será a backdoored neste cenário).
|
||||
4. Vá ao API Gateway e **create a new POST method** (ou escolha qualquer outro método) que executará a versão backdoored da lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Note o final :1 do arn **indicando a versão da função** (version 1 será a backdoored neste cenário).
|
||||
5. Selecione o método POST criado e em Actions selecione **`Deploy API`**
|
||||
6. Agora, quando você **chamar a função via POST seu Backdoor** será invocado
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
O fato de que você pode fazer **funções lambda serem executadas quando algo acontece ou quando passa algum tempo** torna o lambda uma forma comum e eficiente de obter persistência e evitar detecção.\
|
||||
O fato de você poder fazer **funções Lambda rodarem quando algo acontece ou quando algum tempo passa** torna a Lambda uma forma comum e interessante 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 usuário for criado, a lambda gera uma nova chave de usuário e a envia ao atacante.
|
||||
- Toda vez que uma nova role for criada, a lambda concede permissões de assume role a usuários comprometidos.
|
||||
- Toda vez que novos logs do cloudtrail forem gerados, deletá-los/alterá-los
|
||||
- Toda vez que um novo usuário é criado a Lambda gera uma nova user key e a envia para o atacante.
|
||||
- Toda vez que um novo role é criado a Lambda concede permissões de assume role a usuários comprometidos.
|
||||
- Sempre que novos logs do CloudTrail são gerados, delete/altere-os
|
||||
|
||||
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
|
||||
|
||||
Abuse a variável de ambiente `AWS_LAMBDA_EXEC_WRAPPER` para executar um script wrapper controlado pelo atacante antes do runtime/handler iniciar. Entregue o wrapper via um Lambda Layer em `/opt/bin/htwrap`, defina `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 função de execução (function execution role) e por fim `exec`s o runtime real para que o handler original ainda seja executado normalmente.
|
||||
Abuse a variável de ambiente `AWS_LAMBDA_EXEC_WRAPPER` para executar um script wrapper controlado pelo atacante antes do runtime/handler iniciar. Entregue o wrapper via um Lambda Layer em `/opt/bin/htwrap`, defina `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 o role de execução da função e finalmente `exec`s o runtime real para que o handler original ainda seja executado normalmente.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Abuse as asynchronous destinations do Lambda juntamente com a configuração 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 definir a configuração de recursion para Allow os reativa. Destinations entregam no lado do serviço para invocações assíncronas, então um único invoke semente cria um canal stealthy, sem código, de heartbeat/backdoor. Opcionalmente faça throttle com reserved concurrency para manter o ruído baixo.
|
||||
Abuse destinos assíncronos do Lambda juntamente com a configuração de Recursion para fazer com que uma função se re-invoque continuamente sem um agendador externo (sem EventBridge, cron, etc.). Por padrão, o Lambda termina loops recursivos, mas definir a config de recursion para Allow reativa-os. Destinations entregam do lado do serviço para invocações assíncronas, então uma única seed invoke cria um canal furtivo, sem código, de heartbeat/backdoor. Opcionalmente regule com reserved concurrency para manter o ruído baixo.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
@@ -79,13 +79,55 @@ aws-lambda-async-self-loop-persistence.md
|
||||
|
||||
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
|
||||
|
||||
Crie uma versão oculta da Lambda com lógica do atacante e aplique uma resource-based policy a essa versão específica (ou alias) usando o parâmetro `--qualifier` em `lambda add-permission`. Conceda apenas `lambda:InvokeFunction` em `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` para um principal atacante. Invocações normais via o nome da função ou alias primário permanecem inalteradas, enquanto o atacante pode invocar diretamente o ARN da versão backdoored.
|
||||
Crie uma versão oculta da Lambda com lógica do atacante e escopo uma resource-based policy para essa versão específica (ou alias) usando o parâmetro `--qualifier` em `lambda add-permission`. Conceda apenas `lambda:InvokeFunction` em `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` a um principal atacante. Invocações normais via o nome da função ou alias primário permanecem inalteradas, enquanto o atacante pode invocar diretamente o ARN da versão backdoored.
|
||||
|
||||
Isso é mais furtivo do que expor uma Function URL e não altera o alias de tráfego primário.
|
||||
Isso é mais furtivo do que expor um Function URL e não altera o alias de tráfego primário.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### Freezing AWS Lambda Runtimes
|
||||
|
||||
Um atacante que possui permissões lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig e lambda:GetRuntimeManagementConfig pode modificar a runtime management configuration de uma função. Este ataque é especialmente eficaz quando o objetivo é manter uma função Lambda em uma versão de runtime vulnerável ou preservar compatibilidade com layers maliciosos que podem ser incompatíveis com runtimes mais novos.
|
||||
|
||||
O atacante modifica a runtime management configuration para fixar a versão do runtime:
|
||||
```bash
|
||||
# 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:
|
||||
```bash
|
||||
aws lambda get-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--region us-east-1
|
||||
```
|
||||
Opcional: Fixar em uma versão específica do runtime
|
||||
```bash
|
||||
# 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:
|
||||
```bash
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on Manual \
|
||||
--runtime-version-arn $RUNTIME_ARN \
|
||||
--region us-east-1
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user