Az - Function Apps
Last updated
Last updated
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
Azure Functions est une solution sans serveur qui vous permet d'écrire moins de code, de maintenir moins d'infrastructure et d'économiser sur les coûts. Au lieu de vous soucier du déploiement et de la maintenance des serveurs, l'infrastructure cloud fournit toutes les ressources à jour nécessaires pour faire fonctionner vos applications.
Dans le portail Azure, l'intégration entre Azure Functions et Azure API Management est facilitée, permettant aux points de terminaison de fonction déclenchés par HTTP d'être exposés en tant qu'API REST. Les API exposées de cette manière sont décrites à l'aide d'une définition OpenAPI, fournissant une interface standard, indépendante du langage, pour les API RESTful.
Le plan Flex Consumption offre une mise à l'échelle dynamique et basée sur les événements avec des options de calcul flexibles. Il ajoute ou supprime automatiquement des instances de fonction en fonction de la demande, garantissant une utilisation efficace des ressources et une rentabilité grâce à un modèle de paiement à l'utilisation. Ce plan prend en charge le réseau virtuel pour une sécurité accrue et vous permet de réduire les démarrages à froid en pré-provisionnant des instances. Il est idéal pour les applications qui connaissent des charges de travail variables et nécessitent une mise à l'échelle rapide sans avoir besoin de support de conteneur.
Le plan Consumption traditionnel pour Azure Functions est l'option d'hébergement sans serveur par défaut, où vous ne payez que pour les ressources de calcul lorsque vos fonctions sont en cours d'exécution. Il s'adapte automatiquement en fonction du nombre d'événements entrants, ce qui le rend très rentable pour les applications avec des charges de travail intermittentes ou imprévisibles. Bien qu'il ne prenne pas en charge les déploiements de conteneurs, il comprend des optimisations pour réduire les temps de démarrage à froid et convient à un large éventail d'applications sans serveur nécessitant une mise à l'échelle automatique sans la surcharge de gestion de l'infrastructure.
Le plan Premium pour Azure Functions est conçu pour les applications qui nécessitent des performances constantes et des fonctionnalités avancées. Il s'adapte automatiquement en fonction de la demande en utilisant des travailleurs préchauffés, éliminant les démarrages à froid et garantissant que les fonctions s'exécutent rapidement même après des périodes d'inactivité. Ce plan offre des instances plus puissantes, des temps d'exécution prolongés et prend en charge la connectivité au réseau virtuel. De plus, il permet l'utilisation d'images Linux personnalisées, ce qui le rend adapté aux applications critiques nécessitant des performances élevées et un meilleur contrôle des ressources.
Le plan Dedicated, également connu sous le nom de plan App Service, exécute vos fonctions sur des machines virtuelles dédiées au sein d'un environnement App Service. Ce plan offre une facturation prévisible et permet une mise à l'échelle manuelle ou automatique des instances, ce qui le rend idéal pour des scénarios de longue durée où les Durable Functions ne sont pas adaptées. Il prend en charge l'exécution de plusieurs applications web et de fonctions sur le même plan, offre des tailles de calcul plus grandes et garantit une isolation complète des calculs et un accès réseau sécurisé via des environnements App Service (ASE). Cette option est la meilleure pour les applications qui nécessitent une allocation de ressources constante et une personnalisation étendue.
Container Apps vous permettent de déployer des applications de fonction conteneurisées dans un environnement entièrement géré hébergé par Azure Container Apps. Cette option est parfaite pour créer des applications sans serveur basées sur des événements qui s'exécutent aux côtés d'autres microservices, API et flux de travail. Elle prend en charge l'emballage de bibliothèques personnalisées avec votre code de fonction, la migration d'applications héritées vers des microservices cloud-natifs et l'exploitation d'une puissance de traitement haut de gamme avec des ressources GPU. Les Container Apps simplifient le déploiement en éliminant le besoin de gérer des clusters Kubernetes, ce qui les rend idéales pour les développeurs recherchant flexibilité et évolutivité dans un environnement conteneurisé.
Lors de la création d'une nouvelle Function App non conteneurisée (mais fournissant le code à exécuter), le code et d'autres données liées à la fonction seront stockés dans un compte de stockage. Par défaut, la console web créera un nouveau compte par fonction pour stocker le code.
De plus, chaque fois qu'une nouvelle instance de l'application doit s'exécuter, le code de l'application sera récupéré ici et exécuté.
C'est très intéressant du point de vue d'un attaquant car l'accès en écriture sur ce bucket permettra à un attaquant de compromettre le code et d'escalader les privilèges vers les identités gérées à l'intérieur de la Function App.
Il est possible de donner accès à une fonction à tout Internet sans nécessiter d'authentification ou de donner un accès basé sur IAM.
Il est également possible de donner ou de restreindre l'accès à la Function App depuis Internet en donnant accès à un réseau interne (VPC) à la Function App.
C'est très intéressant du point de vue d'un attaquant car il pourrait être possible de pivoter vers des réseaux internes depuis une fonction Lambda vulnérable exposée à Internet.
Il est possible de configurer des variables d'environnement à l'intérieur d'une application. De plus, par défaut, les variables d'environnement AzureWebJobsStorage et WEBSITE_CONTENTAZUREFILECONNECTIONSTRING (entre autres) sont créées. Celles-ci sont particulièrement intéressantes car elles contiennent la clé de compte pour contrôler avec des permissions COMPLETES le compte de stockage contenant les données de l'application.
À l'intérieur de la sandbox, le code source est situé dans /home/site/wwwroot dans le fichier function_app.py (si Python est utilisé) l'utilisateur exécutant le code est app (sans permissions sudo).
De plus, la Function App peut avoir certains points de terminaison qui nécessitent un certain niveau d'authentification, comme "admin" ou "anonyme". Un attaquant pourrait essayer d'accéder aux points de terminaison autorisés anonymes pour contourner les restrictions et accéder à des données ou des fonctionnalités sensibles.
Notez qu'il n'y a pas de permissions RBAC pour donner accès aux utilisateurs pour invoquer les fonctions. L'invocation de fonction dépend du déclencheur sélectionné lors de sa création et si un déclencheur HTTP a été sélectionné, il pourrait être nécessaire d'utiliser une clé d'accès.
Lors de la création d'un point de terminaison à l'intérieur d'une fonction utilisant un déclencheur HTTP, il est possible d'indiquer le niveau d'autorisation de clé d'accès nécessaire pour déclencher la fonction. Trois options sont disponibles :
ANONYME : Tout le monde peut accéder à la fonction par l'URL.
FONCTION : Le point de terminaison n'est accessible qu'aux utilisateurs utilisant une clé de fonction, d'hôte ou maître.
ADMIN : Le point de terminaison n'est accessible qu'aux utilisateurs avec une clé maître.
Type de clés :
Clés de fonction : Les clés de fonction peuvent être soit par défaut, soit définies par l'utilisateur et sont conçues pour accorder un accès exclusivement à des points de terminaison de fonction spécifiques au sein d'une Function App. Cela permet un contrôle de sécurité granulaire, garantissant que seuls les utilisateurs ou services autorisés peuvent invoquer des fonctions particulières sans exposer l'ensemble de l'application.
Clés d'hôte : Les clés d'hôte, qui peuvent également être par défaut ou définies par l'utilisateur, fournissent un accès à tous les points de terminaison de fonction au sein d'une Function App. Cela est utile lorsque plusieurs fonctions doivent être accessibles à l'aide d'une seule clé, simplifiant la gestion et réduisant le nombre de clés à distribuer ou à stocker en toute sécurité.
Clé maître : La clé maître (_master) sert de clé administrative qui offre des permissions élevées, y compris l'accès aux API REST d'exécution d'une Function App. Cette clé ne peut pas être révoquée et doit être manipulée avec le plus grand soin. Il est crucial de ne pas partager la clé maître avec des tiers ou de l'inclure dans des applications clientes natives pour éviter un accès administratif non autorisé.
Lors de la définition de l'authentification d'une fonction sur ADMIN (et non ANONYME ou FONCTION), il est nécessaire d'utiliser cette clé.
Clés système : Les clés système sont gérées par des extensions spécifiques et sont nécessaires pour accéder aux points de terminaison webhook utilisés par des composants internes. Des exemples incluent le déclencheur Event Grid et les Durable Functions, qui utilisent des clés système pour interagir en toute sécurité avec leurs API respectives. Les clés système peuvent être régénérées via le portail Azure ou les API de clés pour maintenir la sécurité.
Exemple pour accéder à un point de terminaison API de fonction en utilisant une clé :
https://<function_uniq_name>.azurewebsites.net/api/<endpoint_name>?code=<access_key>
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
