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:
GCP - App Engine Enum
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.listEssas 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 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.getCom 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.getEu 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.updateNã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 esse bucket antecipadamente 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 backdoored.
Para mais informações e um PoC, verifique as informações relevantes desta página:
GCP - Storage PrivescEmbora 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)
