GCP - AppEngine Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Para mais informações sobre o App Engine, consulte:
appengine.applications.get
, appengine.instances.get
, appengine.instances.list
, appengine.operations.get
, appengine.operations.list
, appengine.services.get
, appengine.services.list
, appengine.versions.create
, appengine.versions.get
, appengine.versions.list
, cloudbuild.builds.get
,iam.serviceAccounts.actAs
, resourcemanager.projects.get
, storage.objects.create
, storage.objects.list
Essas são as permissões necessárias para implantar um App usando gcloud
cli. Talvez as permissões get
e list
possam ser evitadas.
Você pode encontrar exemplos de código em python em https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine
Por padrão, o nome do serviço do App será default
, e pode haver apenas 1 instância com o mesmo nome.
Para alterá-lo e criar um segundo App, em app.yaml
, mude o valor da chave raiz para algo como service: my-second-app
Dê pelo menos 10-15 minutos, se não funcionar, chame deploy outra vez e aguarde alguns minutos.
É possível indicar a Conta de Serviço a ser usada mas, por padrão, a SA padrão do App Engine é utilizada.
A URL da aplicação é algo como https://<proj-name>.oa.r.appspot.com/
ou https://<service_name>-dot-<proj-name>.oa.r.appspot.com
Você pode ter permissões suficientes para atualizar um AppEngine, mas não para criar um novo. Nesse caso, é assim que você poderia atualizar o App Engine atual:
Se você já comprometeu um AppEngine e tem a permissão appengine.applications.update
e actAs sobre a conta de serviço que você poderia modificar a conta de serviço usada pelo AppEngine com:
appengine.instances.enableDebug
, appengine.instances.get
, appengine.instances.list
, appengine.operations.get
, appengine.services.get
, appengine.services.list
, appengine.versions.get
, appengine.versions.list
, compute.projects.get
Com essas permissões, é possível fazer login via ssh em instâncias do App Engine do tipo flexível (não padrão). Algumas das permissões list
e get
podem não ser realmente necessárias.
appengine.applications.update
, appengine.operations.get
Eu acho que isso apenas muda a SA de fundo que o Google usará para configurar as aplicações, então eu não acho que você possa abusar disso para roubar a conta de serviço.
appengine.versions.getFileContents
, appengine.versions.update
Não tenho certeza de como usar essas permissões ou se elas são úteis (note que quando você altera o código, uma nova versão é criada, então não sei se você pode apenas atualizar o código ou o papel IAM de um, mas eu suponho que você deveria ser capaz de, talvez mudando o código dentro do bucket??).
Como mencionado, as versões do appengine geram alguns dados dentro de um bucket com o formato nome: staging.<project-id>.appspot.com
. Note que não é possível assumir o controle desse bucket porque os usuários do GCP não estão autorizados a gerar buckets usando o nome de domínio appspot.com
.
No entanto, com acesso de leitura e escrita sobre esse bucket, é possível escalar privilégios para o SA anexado à versão do AppEngine monitorando o bucket e, sempre que uma alteração for realizada, modificar o código o mais rápido possível. Dessa forma, o contêiner que é criado a partir desse código executará o código com backdoor.
Para mais informações e um PoC, verifique as informações relevantes desta página:
Embora o App Engine crie imagens docker dentro do Artifact Registry. Foi testado que mesmo que você modifique a imagem dentro deste serviço e remova a instância do App Engine (para que uma nova seja implantada), o código executado não muda. Pode ser possível que, realizando um ataque de Condição de Corrida como com os buckets, pode ser possível sobrescrever o código executado, mas isso não foi testado.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)