GCP - AppEngine Privesc

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert Red Team AWS HackTricks)!

Autres façons de soutenir HackTricks :

• Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT !

• Obtenez le swag officiel PEASS & HackTricks

• Découvrez La famille PEASS, notre collection exclusive de NFTs

• Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.

• Partagez vos astuces de piratage en soumettant des PR aux HackTricks et HackTricks Cloud github repos.

App Engine

Pour plus d'informations sur App Engine, consultez :

pageGCP - 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.list

Ce sont les autorisations nécessaires pour déployer une application à l'aide de la CLI gcloud. Peut-être que les autorisations get et list pourraient être évitées.

Vous pouvez trouver des exemples de code Python sur https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine

Par défaut, le nom du service de l'application sera default, et il ne peut y avoir qu'une seule instance avec le même nom. Pour le changer et créer une deuxième application, dans app.yaml, changez la valeur de la clé racine en quelque chose comme service: my-second-app

cd python-docs-samples/appengine/flexible/hello_world
gcloud app deploy #Upload and start application inside the folder

Accordez-lui au moins 10 à 15 minutes, si cela ne fonctionne pas, appelez déployer un autre de fois et attendez quelques minutes.

Il est possible d'indiquer le compte de service à utiliser mais par défaut, le compte de service par défaut de App Engine est utilisé.

L'URL de l'application est quelque chose comme https://<nom-projet>.oa.r.appspot.com/ ou https://<nom_service>-dot-<nom-projet>.oa.r.appspot.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

Avec ces autorisations, il est possible de se connecter via ssh aux instances de App Engine de type flexible (pas standard). Certaines des autorisations de type list et get pourraient ne pas être vraiment nécessaires.

gcloud app instances ssh --service <app-name> --version <version-id> <ID>

appengine.applications.update, appengine.operations.get

Je pense que cela modifie simplement le compte de service en arrière-plan que Google utilisera pour configurer les applications, donc je ne pense pas que vous puissiez en abuser pour voler le compte de service.

gcloud app update --service-account=<sa_email>

appengine.versions.getFileContents, appengine.versions.update

Je ne suis pas sûr de comment utiliser ces autorisations ou si elles sont utiles (notez que lorsque vous modifiez le code, une nouvelle version est créée, donc je ne sais pas si vous pouvez simplement mettre à jour le code ou le rôle IAM d'un, mais je suppose que vous devriez pouvoir le faire, peut-être en changeant le code à l'intérieur du bucket ??).

Accès en écriture sur les buckets

Même avec un accès en écriture sur les buckets où se trouve le code source, il n'était PAS possible d'exécuter du code arbitraire en modifiant le code source et le manifest.json. Peut-être que si vous surveillez le bucket et détectez le moment où une nouvelle version est créée et que le code source et le manifeste sont téléchargés, il pourrait être possible de les modifier pour que la nouvelle version utilise ceux avec une porte dérobée ??

Il semble également que les couches de conteneurs soient stockées dans le bucket, peut-être en les modifiant ?