<\/a>Introduction<\/h2>\nLe serverless est un mod\u00e8le cloud o\u00f9 des fournisseurs comme AWS (Lambda), Azure (Functions) et Google\u00a0Cloud (Functions) g\u00e8rent l\u2019infrastructure, la mise \u00e0 l\u2019\u00e9chelle et la maintenance. Ce mod\u00e8le permet aux organisations et \u00e0 leurs d\u00e9veloppeurs de se concentrer uniquement sur le code, tandis que le fournisseur de services cloud s\u2019occupe des t\u00e2ches en arri\u00e8re-plan.<\/p>\n
Fonctionnant sur une base \u00e9v\u00e9nementielle, les fonctions serverless s\u2019ex\u00e9cutent en r\u00e9ponse \u00e0 des d\u00e9clencheurs tels que des requ\u00eates HTTP, des modifications de bases de donn\u00e9es ou des \u00e9v\u00e9nements programm\u00e9s. La mise \u00e0 l\u2019\u00e9chelle automatis\u00e9e du service fonctionnel permet d\u2019ajuster les ressources \u00e0 la demande, ce qui garantit un bon rapport co\u00fbt-efficacit\u00e9, le fournisseur de services cloud facturant uniquement le temps d\u2019ex\u00e9cution et les ressources utilis\u00e9es.<\/p>\n
Bien que le serverless simplifie le d\u00e9veloppement et le d\u00e9ploiement, il est important de comprendre les risques potentiels associ\u00e9s \u00e0 ces services. Certains de ces risques d\u00e9coulent du fait que les d\u00e9veloppeurs peuvent attribuer des identit\u00e9s aux fonctions serverless, et que ces identit\u00e9s se manifestent sous la forme d\u2019ensembles de mat\u00e9riels d\u2019authentification accessibles au code s\u2019ex\u00e9cutant dans la fonction. Ces mat\u00e9riels d\u2019authentification sont utilis\u00e9s pour authentifier et autoriser l\u2019ex\u00e9cution d\u2019op\u00e9rations dans le cloud.<\/p>\n
Ces mat\u00e9riels d\u2019authentification sont appliqu\u00e9s avec un ensemble d\u2019autorisations qui dictent leur utilisation. En fonction des autorisations associ\u00e9es \u00e0 l\u2019identit\u00e9 attach\u00e9e \u00e0 la fonction, ces mat\u00e9riels d\u2019authentification peuvent permettre l\u2019acc\u00e8s \u00e0 des ressources cloud et \u00e0 des donn\u00e9es sensibles.<\/p>\n
Les fonctions serverless sont des cibles attractives pour les attaquants pour plusieurs raisons\u00a0:<\/p>\n
\n- Les fonctions serverless peuvent \u00eatre vuln\u00e9rables aux attaques par ex\u00e9cution de code \u00e0 distance (RCE) ou falsification de requ\u00eate c\u00f4t\u00e9 serveur (SSRF) en raison de pratiques de d\u00e9veloppement non s\u00e9curis\u00e9es<\/li>\n
- Elles sont souvent expos\u00e9es publiquement (par conception ou en raison d\u2019une mauvaise configuration) ou traitent des entr\u00e9es provenant de sources externes<\/li>\n
- Les attaquants peuvent exploiter les jetons serverless pour obtenir un acc\u00e8s non autoris\u00e9 en lecture\/\u00e9criture, ce qui peut mettre en danger les infrastructures critiques et les donn\u00e9es sensibles<\/li>\n<\/ul>\n
Lorsqu\u2019on utilise des fonctions serverless, il est important de prendre en compte les risques encourus lorsque les d\u00e9veloppeurs d\u2019applications d\u00e9ploient du code non s\u00e9curis\u00e9 dans les fonctions cloud, et de bien comprendre les menaces qui ciblent ces fonctions.<\/p>\n
<\/a>Comment fonctionne l\u2019authentification serverless sur les principales plateformes Cloud<\/h2>\nAvec l\u2019approche serverless, les applications sont d\u00e9ploy\u00e9es en ex\u00e9cutant des fonctions \u00e0 la demande. Le principal avantage de cette approche est que les applications ou les composants sp\u00e9cifiques peuvent \u00eatre ex\u00e9cut\u00e9s en fonction des besoins, ce qui \u00e9limine la n\u00e9cessit\u00e9 d\u2019un environnement d\u2019ex\u00e9cution continu.<\/p>\n
Chacun des principaux fournisseurs de cloud partage des concepts similaires pour les fonctions serverless, par exemple\u00a0:<\/p>\n
\n- La prise en charge de plusieurs langages de programmation<\/li>\n
- L\u2019absence d\u2019acc\u00e8s SSH en raison de leur architecture enti\u00e8rement manag\u00e9e<\/li>\n
- L\u2019utilisation de r\u00f4les, de comptes de service ou d\u2019identit\u00e9s manag\u00e9es pour contr\u00f4ler de mani\u00e8re s\u00e9curis\u00e9e l\u2019acc\u00e8s aux ressources<\/li>\n<\/ul>\n
<\/a>AWS\u00a0Lambda<\/strong><\/h3>\nLe service IAM d\u2019AWS permet de cr\u00e9er et de g\u00e9rer des utilisateurs, des autorisations, des groupes et des r\u00f4les. Ce service est responsable de la gestion des identit\u00e9s et de leur niveau d\u2019acc\u00e8s aux comptes et services AWS, ainsi que du contr\u00f4le de diverses fonctionnalit\u00e9s au sein d\u2019un compte AWS.<\/p>\n
Les fonctions serverless utilisent des r\u00f4les Lambda, qui n\u2019ont pas d\u2019autorisations par d\u00e9faut\u00a0; des politiques IAM doivent \u00eatre utilis\u00e9es pour g\u00e9rer les autorisations et s\u00e9curiser l\u2019acc\u00e8s \u00e0 d\u2019autres services AWS.<\/p>\n
Pour simplifier la gestion des autorisations, AWS propose des politiques g\u00e9r\u00e9es (comme AWSLambdaBasicExecutionRole) que les d\u00e9veloppeurs associent souvent \u00e0 ces r\u00f4les pour activer rapidement des fonctionnalit\u00e9s de base.<\/p>\n
Lorsqu\u2019un r\u00f4le IAM est associ\u00e9 \u00e0 une fonction Lambda, le service AWS Security Token Service (STS)<\/a> g\u00e9n\u00e8re automatiquement des identifiants de s\u00e9curit\u00e9 temporaires<\/a> pour ce r\u00f4le.<\/p>\nIl s\u2019agit d\u2019un moyen s\u00fbr d\u2019acc\u00e9der aux mat\u00e9riels d\u2019authentification au moment de l\u2019ex\u00e9cution, sans les risques associ\u00e9s aux mat\u00e9riels d\u2019authentification cod\u00e9s en dur \u00e0 long terme.<\/p>\n
Ces mat\u00e9riels d\u2019authentification sont limit\u00e9s aux autorisations d\u00e9finies dans la politique d\u2019acc\u00e8s associ\u00e9e au r\u00f4le. Il s\u2019agit d\u2019un identifiant de cl\u00e9 d\u2019acc\u00e8s, d\u2019une cl\u00e9 d\u2019acc\u00e8s secr\u00e8te et d\u2019un jeton de session.<\/p>\n
Au moment de l\u2019ex\u00e9cution, le service d\u2019ex\u00e9cution Lambda charge les mat\u00e9riels d\u2019authentification du r\u00f4le dans l\u2019environnement d\u2019ex\u00e9cution de la fonction et les stocke en tant que variables d\u2019environnement, telles que AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY<\/span> et AWS_SESSION_TOKEN<\/span>. Ces variables sont accessibles au code de la fonction pendant l\u2019ex\u00e9cution, ce qui permet \u00e0 la fonction d\u2019interagir en toute s\u00e9curit\u00e9 avec d\u2019autres services AWS.<\/p>\n<\/a>Google\u00a0Cloud\u00a0Functions<\/strong><\/h3>\nGoogle\u00a0Cloud\u00a0Functions utilise des jetons de compte de service pour authentifier et autoriser l\u2019acc\u00e8s \u00e0 d\u2019autres services Google\u00a0Cloud. Un compte de service est un compte Google sp\u00e9cialis\u00e9 li\u00e9 \u00e0 un projet<\/a> et repr\u00e9sente une identit\u00e9 non humaine, plut\u00f4t qu\u2019un utilisateur individuel.<\/p>\nLors du d\u00e9ploiement d\u2019une fonction cloud, les d\u00e9veloppeurs peuvent l\u2019associer \u00e0 un compte de service personnalis\u00e9 ou au compte de service par d\u00e9faut<\/a>. Lorsqu\u2019ils utilisent un compte de service personnalis\u00e9, les d\u00e9veloppeurs peuvent attribuer des r\u00f4les IAM sp\u00e9cifiques afin de d\u00e9finir les autorisations exactes dont la fonction a besoin pour accomplir ses t\u00e2ches.<\/p>\nLes comptes de service par d\u00e9faut sont des comptes g\u00e9r\u00e9s par l\u2019utilisateur<\/a> que Google\u00a0Cloud cr\u00e9e automatiquement lorsque les utilisateurs activent des services sp\u00e9cifiques. Par d\u00e9faut, Google\u00a0Cloud\u00a0Functions utilise diff\u00e9rents comptes de service en fonction de la g\u00e9n\u00e9ration<\/a>\u00a0:<\/p>\n\n- Les fonctions Cloud\u00a0Run de premi\u00e8re g\u00e9n\u00e9ration utilisent le compte de service par d\u00e9faut d\u2019App\u00a0Engine (<project_id>@appspot.gserviceaccount.com<\/span> ).<\/li>\n
- Les fonctions Cloud\u00a0Run de deuxi\u00e8me g\u00e9n\u00e9ration utilisent le compte de service Compute par d\u00e9faut (<num\u00e9ro_de_projet>-compute@developer.gserviceaccount.com<\/span>).<\/li>\n<\/ul>\n
Ces comptes de service par d\u00e9faut disposent souvent d\u2019autorisations d\u2019\u00e9diteur lorsque les d\u00e9veloppeurs utilisent GCP sans rattachement organisationnel, ce qui leur permet de cr\u00e9er, de modifier et de supprimer des ressources au sein du projet. Toutefois, dans les projets relevant d\u2019une organisation GCP, les comptes de service par d\u00e9faut sont cr\u00e9\u00e9s sans aucune autorisation. Dans ce cas, ils ne peuvent effectuer que les actions explicitement autoris\u00e9es par les r\u00f4les qui leur sont attribu\u00e9s.<\/p>\n
Bien qu\u2019une fonction GCP fonctionne dans un environnement serverless, lorsqu\u2019il s\u2019agit d\u2019acc\u00e9der aux mat\u00e9riels d\u2019authentification associ\u00e9s \u00e0 la fonction, elle se comporte de la m\u00eame mani\u00e8re qu\u2019un serveur traditionnel, tel qu\u2019une instance de machine virtuelle (VM), en r\u00e9cup\u00e9rant ses jetons de compte de service \u00e0 partir du serveur de m\u00e9tadonn\u00e9es d\u2019instance (IMDS)<\/a> au moment de l\u2019ex\u00e9cution. L\u2019IMDS \u00e0 l\u2019adresse hxxp:\/\/metadata.google[.]internal\/<\/span> fournit des jetons d\u2019acc\u00e8s de courte dur\u00e9e pour le compte de service associ\u00e9 \u00e0 la fonction. Ces jetons permettent \u00e0 la fonction de s\u2019authentifier aupr\u00e8s des services GCP.<\/p>\n<\/a>Azure\u00a0Functions<\/strong><\/h3>\nLes identit\u00e9s g\u00e9r\u00e9es par Azure permettent aux ressources Azure de s\u2019authentifier et d\u2019interagir avec d\u2019autres services Azure de mani\u00e8re s\u00e9curis\u00e9e et transparente, sans qu\u2019il soit n\u00e9cessaire de coder des mat\u00e9riels d\u2019authentification en dur. \u00c0 l\u2019instar des services fonctionnels d\u2019AWS et de GCP, ces identit\u00e9s \u00e9liminent les risques li\u00e9s \u00e0 la gestion des mat\u00e9riels d\u2019authentification dans le code.<\/p>\n
Les identit\u00e9s manag\u00e9es attribu\u00e9es par le syst\u00e8me sont li\u00e9es \u00e0 une ressource unique et sont automatiquement supprim\u00e9es lors de la suppression de la ressource. D\u2019autre part, les identit\u00e9s manag\u00e9es attribu\u00e9es par l\u2019utilisateur sont des ressources ind\u00e9pendantes qui peuvent \u00eatre attribu\u00e9es \u00e0 plusieurs services, ce qui offre une plus grande souplesse pour les sc\u00e9narios d\u2019authentification partag\u00e9e.<\/p>\n
Une fonction Azure \u00e0 laquelle est associ\u00e9e une identit\u00e9 manag\u00e9e doit utiliser son jeton d\u2019identit\u00e9 manag\u00e9e pour s\u2019authentifier aupr\u00e8s d\u2019une ressource Azure. Ci-dessous la proc\u00e9dure d\u2019authentification d\u00e9taill\u00e9e:<\/p>\n
\n- La fonction interroge ses variables d\u2019environnement pour r\u00e9cup\u00e9rer les valeurs de IDENTITY_ENDPOINT<\/span> et IDENTITY_HEADER<\/span>.\n
\n- IDENTITY_ENDPOINT<\/span>\u00a0: Une variable d\u2019environnement<\/a> qui contient l\u2019adresse du terminal local de l\u2019identit\u00e9 manag\u00e9e fourni par Azure. Il s\u2019agit d\u2019une URL locale \u00e0 partir de laquelle une application peut demander des jetons.<\/li>\n
- IDENTITY_HEADER<\/span>\u00a0: Param\u00e8tre obligatoire lors de l\u2019interrogation du terminal local de l\u2019identit\u00e9 manag\u00e9e. Cet en-t\u00eate est utilis\u00e9 pour att\u00e9nuer les attaques SSRF.<\/li>\n<\/ul>\n<\/li>\n
- La fonction envoie une requ\u00eate HTTP GET au terminal local de l\u2019identit\u00e9 manag\u00e9e avec l\u2019en-t\u00eate IDENTITY_HEADER<\/span> inclus dans l\u2019en-t\u00eate HTTP. (Pour plus de d\u00e9tails sur la structure de la demande, voir la documentation d\u2019Azure sur l\u2019acquisition de jetons pour les App\u00a0Services<\/a>)<\/li>\n
- Microsoft\u00a0Entra\u00a0ID<\/a> (anciennement Azure\u00a0Active\u00a0Directory) v\u00e9rifie l\u2019identit\u00e9 de la fonction et \u00e9met un jeton OAuth\u00a02.0 temporaire qui est limit\u00e9 sp\u00e9cifiquement \u00e0 la ressource cible.<\/li>\n
- La fonction inclut le jeton \u00e9mis dans sa demande \u00e0 la ressource Azure (par exemple, Azure\u00a0Key\u00a0Vault<\/a>, compte de stockage<\/a>).<\/li>\n
- La ressource Azure valide le jeton et v\u00e9rifie les autorisations de la fonction \u00e0 l\u2019aide du contr\u00f4le d\u2019acc\u00e8s bas\u00e9 sur les r\u00f4les<\/a> ou des politiques d\u2019acc\u00e8s sp\u00e9cifiques aux ressources<\/a>.<\/li>\n<\/ul>\n
Si elle est autoris\u00e9e, la ressource accorde l\u2019acc\u00e8s pour effectuer l\u2019op\u00e9ration demand\u00e9e. Cela garantit une authentification s\u00fbre et transparente sans qu\u2019il soit n\u00e9cessaire d\u2019utiliser des secrets cod\u00e9s en dur dans le code.<\/p>\n
<\/a>Vecteurs d\u2019attaque pour l\u2019exfiltration de jetons<\/h2>\nCette section aborde les risques et les menaces li\u00e9s \u00e0 l\u2019utilisation de fonctions serverless. Lorsqu\u2019ils d\u00e9veloppent et configurent des fonctions, les d\u00e9veloppeurs d\u2019applications doivent veiller \u00e0 s\u00e9curiser ces fonctions contre des attaques telles que SSRF et RCE. En l\u2019absence d\u2019une telle s\u00e9curit\u00e9, les attaquants pourraient manipuler les fonctions serverless qui sont vuln\u00e9rables au SSRF, ce qui am\u00e8nerait les fonctions \u00e0 envoyer des requ\u00eates non autoris\u00e9es aux services internes. Cela peut conduire \u00e0 un acc\u00e8s involontaire ou \u00e0 l\u2019exposition d\u2019informations sensibles au sein du syst\u00e8me, telles que les jetons d\u2019acc\u00e8s, le contenu de la base de donn\u00e9es interne ou les configurations de service. Il est important de souligner que ces risques surviennent principalement lorsque les fonctions sont publiques ou qu\u2019elles traitent des donn\u00e9es provenant d\u2019utilisateurs externes et d\u2019autres sources.<\/p>\n
Dans les attaques SSRF, un attaquant trompe un serveur (comme une fonction serverless) en effectuant des requ\u00eates HTTP vers des ressources internes ou externes auxquelles l\u2019attaquant ne devrait pas avoir acc\u00e8s. Comme c\u2019est le serveur lui-m\u00eame qui fait la demande, il peut acc\u00e9der \u00e0 des services internes qui ne sont pas expos\u00e9s \u00e0 Internet. Une fonction serverlessr vuln\u00e9rable prend une URL en entr\u00e9e et r\u00e9cup\u00e8re les donn\u00e9es \u00e0 partir de celle-ci.<\/p>\n
Dans GCP, SSRF peut \u00eatre utilis\u00e9 pour acc\u00e9der \u00e0 l\u2019IMDS \u00e0 l\u2019adresse hxxp:\/\/metadata.google[.]internal\/<\/span>, en extrayant des jetons temporaires de compte de service. Un attaquant peut alors utiliser ces jetons pour se faire passer pour la fonction et effectuer des actions non autoris\u00e9es dans le cadre des autorisations de son r\u00f4le IAM. Les vuln\u00e9rabilit\u00e9s li\u00e9es \u00e0 l\u2019ex\u00e9cution de code \u00e0 distance permettent aux attaquants d\u2019ex\u00e9cuter du code arbitraire dans l\u2019environnement d\u2019une fonction.<\/p>\nPour AWS\u00a0Lambda, les attaques RCE pourraient exposer des mat\u00e9riels d\u2019authentification temporaires stock\u00e9es dans des variables d\u2019environnement, telles que AWS_ACCESS_KEY_ID<\/span> et AWS_SESSION_TOKEN<\/span>.<\/p>\nIl est essentiel de noter que ces vecteurs d\u2019attaque ne sont pas des failles inh\u00e9rentes aux plateformes cloud elles-m\u00eames, mais d\u00e9coulent plut\u00f4t d\u2019un d\u00e9veloppement non s\u00e9curis\u00e9 r\u00e9dig\u00e9 par les d\u00e9veloppeurs d\u2019applications qui pourrait introduire des vuln\u00e9rabilit\u00e9s, telles que SSRF ou RCE. Les d\u00e9veloppeurs d\u2019applications peuvent att\u00e9nuer ces risques en mettant en \u0153uvre des pratiques de d\u00e9veloppement s\u00e9curis\u00e9 telles que la validation des entr\u00e9es.<\/p>\n
<\/a>Simulations de vecteurs d\u2019attaque<\/strong><\/h3>\nLes simulations suivantes montrent comment les attaquants pourraient extraire les jetons serverless et les utiliser pour des activit\u00e9s malveillantes dans diff\u00e9rents fournisseurs de services cloud (CSP). Ces attaques pourraient tirer parti d\u2019un code de fonction non s\u00e9curis\u00e9 d\u00e9ploy\u00e9 par les d\u00e9veloppeurs d\u2019applications.<\/p>\n
<\/a>Simulation\u00a01\u00a0: Acc\u00e8s direct \u00e0 l\u2019IMDS \u00e0 partir d\u2019une fonction BPC<\/h4>\nPour r\u00e9aliser cette simulation, nous avons d\u00e9ploy\u00e9 deux fonctions Google\u00a0Cloud\u00a0Run qui acc\u00e8dent au service de m\u00e9tadonn\u00e9es des fonctions et extraient les jetons des deux diff\u00e9rents comptes de service associ\u00e9s \u00e0 partir du chemin suivant\u00a0:<\/p>\n
\n- hxxp[:\/\/]metadata.google[.]internal\/computeMetadata\/v1\/instance\/service-accounts\/default\/token<\/span><\/li>\n<\/ul>\n
Le premier exemple illustre l\u2019extraction d\u2019un compte de service par d\u00e9faut. Le deuxi\u00e8me exemple illustre l\u2019extraction d\u2019un compte de service personnalis\u00e9. Ces exemples montrent comment le code peut acc\u00e9der directement au service de m\u00e9tadonn\u00e9es, tout comme une application vuln\u00e9rable \u00e0 une attaque SSRF pourrait \u00e9galement y acc\u00e9der.<\/p>\n
<\/a>Exemple\u00a01\u00a0: Extraction d\u2019un compte de service par d\u00e9faut dans GCP<\/strong><\/h5>\nComme le montre la figure\u00a01, le compte de service associ\u00e9 \u00e0 la fonction \u00e9tait le compte de service serverless par d\u00e9faut. La figure\u00a02 montre que le jeton d\u2019acc\u00e8s renvoy\u00e9 appartient au m\u00eame compte de service.<\/p>\n![\"Capture]()
Figure 1. Informations g\u00e9n\u00e9rales sur la fonction, y compris le nom de compte de service associ\u00e9 (le compte de service par d\u00e9faut).<\/figcaption><\/figure>\n![\"Capture]()
Figure 2. Commande utilis\u00e9e pour extraire le jeton d\u2019acc\u00e8s au compte de service, y compris le r\u00e9sultat.<\/figcaption><\/figure>\n<\/a>Exemple\u00a02\u00a0: Extraction d\u2019un compte de service personnalis\u00e9 dans GCP<\/strong><\/h5>\nLa figure\u00a03 montre le compte de service personnalis\u00e9 que nous avons associ\u00e9 \u00e0 la fonction. La figure\u00a04 montre le jeton d\u2019acc\u00e8s renvoy\u00e9 appartenant au compte de service personnalis\u00e9. Nous avons ensuite utilis\u00e9 le jeton renvoy\u00e9 pour effectuer des op\u00e9rations dans l\u2019environnement.<\/p>\n![\"Capture]()
Figure 3. Informations g\u00e9n\u00e9rales sur la fonction, y compris le nom du compte de service associ\u00e9 (un compte de service personnalis\u00e9).<\/figcaption><\/figure>\n![\"Capture]()
Figure 4. Commande utilis\u00e9e pour extraire le jeton d\u2019acc\u00e8s au compte de service, y compris le r\u00e9sultat.<\/figcaption><\/figure>\nLa figure\u00a05 ci-dessous montre un exemple de commande permettant de lister les buckets.<\/p>\n![\"Capture]()
Figure 5. Utilisation du jeton renvoy\u00e9 pour lister les buckets du compte de service.<\/figcaption><\/figure>\nSi des attaquants peuvent r\u00e9pertorier et lire le contenu des buckets dans GCP, ils peuvent acc\u00e9der \u00e0 des fichiers sensibles tels que des mat\u00e9riels d\u2019authentification, des sauvegardes ou des configurations internes. Cela leur permet de voler des donn\u00e9es, de compromettre le syst\u00e8me ou de se d\u00e9placer lat\u00e9ralement au sein de l\u2019environnement.<\/p>\n
Une fois que les attaquants obtiennent un jeton d\u2019acc\u00e8s pour un compte de service avec des autorisations d\u2019\u00e9diteur dans GCP (comme le compte de service Compute\u00a0Engine par d\u00e9faut), ils peuvent modifier, supprimer ou cr\u00e9er des ressources dans la plupart des services. Il peut s\u2019agir d\u2019acc\u00e9der \u00e0 des donn\u00e9es sensibles, de d\u00e9ployer des workloads malveillants, d\u2019escalader des privil\u00e8ges ou de perturber des services. L\u2019acc\u00e8s de l\u2019\u00e9diteur permet un contr\u00f4le quasi total du projet.<\/p>\n
<\/a>Simulation\u00a02\u00a0: Utilisation de RCE pour r\u00e9cup\u00e9rer les jetons stock\u00e9s dans les variables d\u2019environnement de la fonction AWS\u00a0Lambda<\/h4>\nDans cette simulation, nous avons acc\u00e9d\u00e9 aux variables d\u2019environnement de la fonction Lambda et en avons extrait l\u2019AWS_ACCESS_KEY_ID<\/span>, l\u2019AWS_SECRET_ACCESS_KEY<\/span> et l\u2019AWS_SESSION_TOKEN<\/span>.<\/p>\nLa figure\u00a06 montre la sortie du code de la fonction Lambda.<\/p>\n![\"Capture]()
Figure 6. Valeurs des variables d\u2019environnement renvoy\u00e9es.<\/figcaption><\/figure>\nLa figure\u00a07 montre la configuration des identifiants AWS temporaires obtenus \u00e0 l\u2019\u00e9tape pr\u00e9c\u00e9dente (les variables d\u2019environnement Lambda).<\/p>\n![\"\u00c9cran]()
Figure\u00a07. Extrait de code des commandes utilis\u00e9es pour lister les buckets\u00a0S3.<\/figcaption><\/figure>\nNous avons ensuite utilis\u00e9 la commande suivante pour dresser la liste de tous les buckets\u00a0S3 auxquels la session authentifi\u00e9e peut acc\u00e9der.<\/p>\n
aws s3 ls<\/pre>\n<\/a>Simulation\u00a03\u00a0: Utilisation de RCE pour r\u00e9cup\u00e9rer des jetons \u00e0 partir d\u2019un terminal d\u2019identit\u00e9 local d\u2019une fonction Azure<\/h4>\nDans cette simulation, nous avons acc\u00e9d\u00e9 aux variables d\u2019environnement de la fonction Azure et extrait l\u2019IDENTITY_ENDPOINT et l\u2019IDENTITY_HEADER en ex\u00e9cutant des commandes \u00e0 distance. Nous avons ensuite extrait le jeton d\u2019identit\u00e9 manag\u00e9e via le terminal d\u2019identit\u00e9 local, en fournissant les param\u00e8tres indiqu\u00e9s ci-dessous dans la figure\u00a08\u00a0:<\/p>\n
\n- Ressource<\/li>\n
- version de l\u2019API<\/span><\/li>\n
- X-IDENTITY-HEADER<\/span><\/li>\n<\/ul>\n
![\"Capture]()
Figure 8. La sortie du script, y compris le jeton d\u2019acc\u00e8s.<\/figcaption><\/figure>\n<\/a>D\u00e9tection et pr\u00e9vention de l\u2019exfiltration de jetons<\/h2>\n<\/a>D\u00e9tection de l\u2019exfiltration de jetons dans les environnements sans serveur<\/strong><\/h3>\nDes m\u00e9canismes de d\u00e9tection efficaces sont essentiels pour identifier l\u2019exfiltration de jetons dans les environnements sans serveur. Ces m\u00e9canismes se concentrent sur les anomalies de comportement pour signaler les activit\u00e9s non autoris\u00e9es. Voici quelques-unes des principales strat\u00e9gies de d\u00e9tection mises en \u0153uvre sur les principales plateformes cloud.<\/p>\n
La d\u00e9tection se fait en deux \u00e9tapes\u00a0:<\/p>\n
\n- Valider que l\u2019identit\u00e9 est associ\u00e9e \u00e0 une fonction serverless.<\/li>\n
- Identifier les comportements anormaux des identit\u00e9s sans serveur. Ces comportements peuvent inclure\u00a0:\n
\n- Les adresses IP source qui ne correspondent pas au contexte dans lequel la fonction est ex\u00e9cut\u00e9e, telles que les adresses provenant de num\u00e9ros de syst\u00e8mes autonomes (ASN) qui ne sont pas associ\u00e9s \u00e0 un fournisseur de services cloud.<\/li>\n
- Les identit\u00e9s serverless effectuant des requ\u00eates avec des user-agents suspects.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
<\/a>\u00c9tape\u00a01\u00a0: Identifier les identit\u00e9s serverless<\/h4>\nPour identifier les comptes de service associ\u00e9s aux fonctions sans serveur dans GCP, nous analysons la section serviceAccountDelegationInfo<\/span> dans les journaux. Ces informations fournissent des indications cruciales sur la cha\u00eene de d\u00e9l\u00e9gation des comptes de service. Plus pr\u00e9cis\u00e9ment, lorsqu\u2019un compte de service est associ\u00e9 \u00e0 une fonction, il d\u00e9l\u00e8gue son autorit\u00e9 \u00e0 un compte de service sans serveur par d\u00e9faut\u00a0:<\/p>\n\n- Google\u00a0Cloud\u00a0Run\u00a0Service\u00a0Agent (service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>)<\/li>\n
- gcf-admin-robot.iam.gserviceaccount[.]com<\/span> (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com<\/span>)<\/li>\n<\/ul>\n
Ces comptes de service ex\u00e9cutent des t\u00e2ches au nom de la fonction.<\/p>\n
Par exemple, dans l\u2019entr\u00e9e de journal de la figure\u00a09, nous voyons le compte de service personnalis\u00e9 associ\u00e9 \u00e0 une fonction (sa-test@<project-id>.iam.gserviceaccount[.]com<\/span>) d\u00e9l\u00e9guer son autorit\u00e9 \u00e0 l\u2019agent de service Cloud\u00a0Run.<\/p>\n![\"Capture]()
Figure 9. Entr\u00e9e de journal montrant un compte de service personnalis\u00e9.<\/figcaption><\/figure>\nDans la figure\u00a09 ci-dessus, le champ principalEmail<\/span> sous authenticationInfo<\/span> sp\u00e9cifie le compte de service utilis\u00e9 (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com<\/span>).<\/p>\nLe serviceAccountDelegationInfo indique<\/span> le principal de premi\u00e8re partie (dans ce cas\u00a0: service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>), ce qui indique que le compte de service fonctionne dans un environnement sans serveur comme Cloud\u00a0Functions ou Cloud\u00a0Run.<\/p>\nUne approche efficace pour d\u00e9couvrir les identit\u00e9s serverless consiste \u00e0 \u00e9tablir le profil des comptes de service qui ont pr\u00e9c\u00e9demment d\u00e9l\u00e9gu\u00e9 leur autorit\u00e9 \u00e0 des comptes de service sans serveur par d\u00e9faut. Cela garantit que m\u00eame si des comptes de service autres que ceux par d\u00e9faut sont associ\u00e9s \u00e0 des fonctions, ils sont identifi\u00e9s.<\/p>\n
Dans AWS, les fonctions Lambda s\u2019appuient sur les r\u00f4les IAM pour s\u00e9curiser l\u2019acc\u00e8s aux services AWS. Ces r\u00f4les g\u00e9n\u00e8rent des mat\u00e9riels d\u2019authentification temporaires. Nous pouvons identifier l\u2019identit\u00e9 Lambda par son nom de r\u00f4le.<\/p>\n
Dans Azure, les identit\u00e9s manag\u00e9es associ\u00e9es aux Azure\u00a0Function\u00a0Apps sont utilis\u00e9es pour l\u2019authentification.<\/p>\n
<\/a>\u00c9tape\u00a02\u00a0: Identifier les comportements inhabituels pour les identit\u00e9s serverless<\/h4>\nDans un environnement cloud s\u00e9curis\u00e9, les fonctions serverless sont g\u00e9n\u00e9ralement destin\u00e9es \u00e0 ex\u00e9cuter des t\u00e2ches automatis\u00e9es et circonscrites, telles que la r\u00e9ponse \u00e0 des requ\u00eates API ou le traitement d\u2019\u00e9v\u00e9nements. Ces fonctions ne doivent pas \u00eatre utilis\u00e9es de mani\u00e8re interactive. Cependant, si des attaquants obtiennent l\u2019acc\u00e8s \u00e0 l\u2019environnement d\u2019une fonction sans serveur ou \u00e0 son identit\u00e9, ils peuvent l\u2019utiliser \u00e0 mauvais escient pour ex\u00e9cuter des commandes d\u2019interface de ligne de commande (CLI) (par exemple, gcloud<\/span> CLI<\/span> ou curl<\/span>) afin d\u2019interagir directement avec les ressources du cloud.<\/p>\nUne m\u00e9thode de d\u00e9tection consiste \u00e0 examiner le user-agent des appels API. Si l\u2019agent utilisateur correspond \u00e0 des outils CLI connus (par exemple, gcloud CLI<\/span>) ou \u00e0 des cadres de test d\u2019intrusion, il est signal\u00e9 comme suspect, car les CLI ne devraient g\u00e9n\u00e9ralement pas \u00eatre utilis\u00e9es par les identit\u00e9s serverless. Cela indique une exploitation potentielle de l\u2019environnement ou des jetons de compte de service.<\/p>\n\u00c0 noter que cette m\u00e9thode d\u2019identification de l\u2019utilisation \u00e0 distance des jetons sans serveur en fonction de l\u2019agent utilisateur ne peut pas \u00eatre r\u00e9alis\u00e9e dans Azure, car les informations relatives au user-agent n\u2019apparaissent pas dans les journaux Azure.<\/p>\n
Une autre approche pour d\u00e9tecter l\u2019utilisation \u00e0 distance d\u2019un jeton d\u2019identit\u00e9 sans serveur consiste \u00e0 corr\u00e9ler l\u2019emplacement de l\u2019utilisation d\u2019un jeton avec des plages ASN d\u2019adresses IP de fournisseurs de cloud connus. Si une demande provient d\u2019une adresse IP externe non associ\u00e9e au CSP, une alerte est d\u00e9clench\u00e9e, mettant en \u00e9vidence une \u00e9ventuelle utilisation non autoris\u00e9e du jeton en dehors de l\u2019environnement cloud.<\/p>\n
<\/a>Strat\u00e9gies de pr\u00e9vention<\/h3>\nLa s\u00e9curisation des jetons serverless n\u00e9cessite une combinaison de mesures proactives, de gestion de la posture et de pratiques de s\u00e9curit\u00e9 de surveillance de l\u2019ex\u00e9cution pour minimiser le risque d\u2019exploitation. Tout d\u2019abord, mettez en \u0153uvre le principe du moindre privil\u00e8ge en attribuant des r\u00f4les avec les autorisations minimales requises pour les fonctions sans serveur. Cela r\u00e9duit l\u2019impact potentiel d\u2019une mauvaise utilisation des jetons.<\/p>\n
En outre, pour prot\u00e9ger les environnements d\u2019ex\u00e9cution sans serveur dans GCP et Azure, restreignez l\u2019acc\u00e8s \u00e0 l\u2019IMDS en configurant des contr\u00f4les au niveau du r\u00e9seau et en appliquant des m\u00e9canismes de validation des demandes. Assurer une validation robuste des entr\u00e9es pour emp\u00eacher les attaquants d\u2019utiliser des techniques d\u2019exploitation comme le SSRF pour acc\u00e9der aux m\u00e9tadonn\u00e9es sensibles, aux jetons et \u00e0 d\u2019autres ressources cloud comme les API et les bases de donn\u00e9es.<\/p>\n
<\/a>Conclusion<\/h2>\nL\u2019informatique serverless est le choix privil\u00e9gi\u00e9 pour le d\u00e9veloppement d\u2019applications modernes, car elle offre des avantages significatifs en termes d\u2019\u00e9volutivit\u00e9, de rentabilit\u00e9 et de gestion simplifi\u00e9e de l\u2019infrastructure.<\/p>\n
Les mat\u00e9riels d'authentification permettant \u00e0 ces fonctions d\u2019interagir avec les services cloud constituent un \u00e9l\u00e9ment de s\u00e9curit\u00e9 essentiel et une cible de choix pour les attaquants. La compromission de ces mat\u00e9riels d\u2019authentification peut avoir de graves cons\u00e9quences, notamment l\u2019acc\u00e8s non autoris\u00e9 \u00e0 des ressources cloud et l\u2019exfiltration de donn\u00e9es.<\/p>\n
La mise en \u0153uvre d\u2019une gestion proactive de la posture et de protections de surveillance de l\u2019ex\u00e9cution est une strat\u00e9gie cruciale pour la protection des environnements cloud.<\/p>\n
Les organisations peuvent mieux prot\u00e9ger leurs environnements sans serveur en\u00a0:<\/p>\n
\n- Comprenant les m\u00e9canismes des r\u00e9f\u00e9rences serverless et les meilleures pratiques pour les provisionner et les g\u00e9rer dans AWS, Azure et GCP<\/a><\/li>\n
- Reconnaissant les vecteurs d\u2019attaque courants tels que l\u2019exfiltration de jetons via l\u2019exploitation de l\u2019IMDS ou l\u2019acc\u00e8s aux variables d\u2019environnement<\/li>\n<\/ul>\n
<\/a>Protection et mitigation des risques par Palo\u00a0Alto\u00a0Networks<\/h2>\nLes clients de Palo\u00a0Alto\u00a0Networks sont mieux prot\u00e9g\u00e9s contre les menaces mentionn\u00e9es ci-dessus gr\u00e2ce aux produits suivants\u00a0:<\/p>\n
Si vous pensez que votre entreprise a pu \u00eatre compromise ou si vous faites face \u00e0 une urgence, contactez l\u2019\u00e9quipe Unit\u00a042 de r\u00e9ponse aux incidents<\/a> ou composez l\u2019un des num\u00e9ros suivants\u00a0:<\/p>\n\n- Am\u00e9rique du Nord Par t\u00e9l\u00e9phone\u00a0: 866.486.4842 (866.4.UNIT42)<\/li>\n
- EMEA\u00a0: +31\u00a020\u00a0299\u00a03130<\/li>\n
- APAC\u00a0: +65\u00a06983\u00a08730<\/li>\n
- Japon\u00a0: +81\u00a050\u00a01790\u00a00200<\/li>\n<\/ul>\n
Palo\u00a0Alto\u00a0Networks a partag\u00e9 ces conclusions avec les autres membres de la Cyber\u00a0Threat\u00a0Alliance (CTA). Les membres de la CTA s\u2019appuient sur ces renseignements pour d\u00e9ployer rapidement des mesures de protection aupr\u00e8s de leurs clients et perturber de mani\u00e8re coordonn\u00e9e les activit\u00e9s des cybercriminels. Cliquez ici pour en savoir plus sur la Cyber Threat Alliance.<\/a><\/p>\n<\/a>Pour aller plus loin<\/h2>\n\n- Utilisation des variables d\u2019environnement Lambda<\/a> - Guide du d\u00e9veloppeur AWS\u00a0Lambda<\/li>\n
- S\u00e9curisation de variables d\u2019environnement Lambda<\/a> - Guide du d\u00e9veloppeur AWS\u00a0Lambda<\/li>\n
- Gestion des autorisations dans AWS\u00a0Lambda<\/a> - Guide du d\u00e9veloppeur AWS\u00a0Lambda<\/li>\n
- Identit\u00e9 de fonction<\/a> - Google\u00a0Cloud<\/li>\n
- Que sont les identit\u00e9s manag\u00e9es pour les ressources Azure\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- S\u00e9curisation d\u2019Azure\u00a0Functions<\/a> - Microsoft\u00a0Learn<\/li>\n
- Qu\u2019est-ce que c\u2019est, AWS\u00a0Secrets\u00a0Manager\u00a0?<\/a> - Guide de l\u2019utilisateur AWS\u00a0Secret\u00a0Manager<\/li>\n
- Concepts de base d\u2019Azure\u00a0Key\u00a0Vault<\/a> - Microsoft\u00a0Learn<\/li>\n
- Pr\u00e9sentation de Secret\u00a0Manager<\/a> - Documentation de Google\u00a0Cloud Secret\u00a0Manager<\/li>\n
- Qu\u2019est-ce que la gestion des identit\u00e9s et des acc\u00e8s (IAM)\u00a0?<\/a> - Microsoft\u00a0Security<\/li>\n
- Que sont les identit\u00e9s manag\u00e9es pour les ressources Azure\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- Contr\u00f4le des identit\u00e9s et des acc\u00e8s<\/a> - Introduction \u00e0 la s\u00e9curit\u00e9 AWS - Livre blanc AWS<\/li>\n
- Identifiants du compte de service<\/a> - Documentation Google\u00a0Cloud\u00a0IAM<\/li>\n
- Identifiants de s\u00e9curit\u00e9 temporaires dans IAM<\/a> - Guide de l\u2019utilisateur de AWS\u00a0Identity et Access\u00a0Management<\/li>\n
- R\u00e9f\u00e9rence API du service de jetons de s\u00e9curit\u00e9 AWS<\/a> - Documentation du service de jetons de s\u00e9curit\u00e9 AWS<\/li>\n
- Instances Compute\u00a0Engine<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- Projets Google\u00a0Cloud<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- Comptes de service g\u00e9r\u00e9s par l\u2019utilisateur<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- Comparer les fonctions Cloud\u00a0Run<\/a> - Documentation Google\u00a0Cloud\u00a0Run<\/li>\n
- Comptes de service par d\u00e9faut<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- R\u00e9f\u00e9rence du terminal REST<\/a> - Identit\u00e9s manag\u00e9es pour App\u00a0Service et Azure\u00a0Functions<\/li>\n
- Variables d\u2019environnement et param\u00e8tres d\u2019application dans Azure\u00a0App\u00a0Service<\/a> - Microsoft\u00a0Learn<\/li>\n
- Guide pratique de l\u2019utilisation d\u2019identit\u00e9s manag\u00e9es pour ressources Azure sur une machine virtuelle Azure afin d\u2019acqu\u00e9rir un jeton d\u2019acc\u00e8s<\/a> - Microsoft\u00a0Learn<\/li>\n
- Qu\u2019est-ce que l\u2019identifiant Microsoft\u00a0Entra\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- \u00c0 propos d\u2019Azure\u00a0Key\u00a0Vault<\/a> - Microsoft\u00a0Learn<\/li>\n
- Autoriser l\u2019acc\u00e8s aux objets blobs \u00e0 l\u2019aide de l\u2019identifiant Microsoft\u00a0Entra<\/a> - Microsoft\u00a0Learn<\/li>\n
- Pr\u00e9sentation du compte de stockage<\/a> - Microsoft\u00a0Learn<\/li>\n
- Qu\u2019est-ce que le contr\u00f4le d\u2019acc\u00e8s en fonction du r\u00f4le Azure (RBAC Azure)\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- Politiques d\u2019acc\u00e8s sp\u00e9cifiques aux ressources<\/a> - Microsoft\u00a0Learn<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.<\/p>\n","protected":false},"author":366,"featured_media":143160,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[8724,8832],"tags":[9293,9341,9342,9228],"product_categories":[9041,9046,9151],"coauthors":[4194],"class_list":["post-146708","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-cybersecurity-research-fr","category-threat-research-fr","tag-aws-fr","tag-google-cloud-fr","tag-microsoft-azure-fr","tag-serverless-fr","product_categories-cortex-fr","product_categories-cortex-cloud-fr","product_categories-unit-42-incident-response-fr"],"yoast_head":"\n
Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection<\/title>\n<meta name=\"description\" content=\"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection\" \/>\n<meta property=\"og:description\" content=\"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:site_name\" content=\"Unit 42\" \/>\n<meta property=\"article:published_time\" content=\"2025-06-13T16:31:03+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-07-14T17:31:16+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"900\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Zohar Zigdon\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","description":"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","og_locale":"fr_FR","og_type":"article","og_title":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","og_description":"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.","og_url":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","og_site_name":"Unit 42","article_published_time":"2025-06-13T16:31:03+00:00","article_modified_time":"2025-07-14T17:31:16+00:00","og_image":[{"width":1920,"height":900,"url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","type":"image\/jpeg"}],"author":"Zohar Zigdon","twitter_card":"summary_large_image","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#article","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/"},"author":{"name":"Sheida Azimi","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"headline":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","datePublished":"2025-06-13T16:31:03+00:00","dateModified":"2025-07-14T17:31:16+00:00","mainEntityOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/"},"wordCount":5063,"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","keywords":["AWS","Google Cloud","Microsoft Azure","serverless"],"articleSection":["\u00c9tudes sur la cybers\u00e9curit\u00e9 du cloud","Recherche sur les menaces"],"inLanguage":"fr-FR"},{"@type":"WebPage","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","url":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","name":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage"},"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","datePublished":"2025-06-13T16:31:03+00:00","dateModified":"2025-07-14T17:31:16+00:00","author":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"description":"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.","breadcrumb":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/"]}]},{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","width":1920,"height":900,"caption":"Pictorial representation of serverless tokens in the cloud. East Asian woman examining data on multiple screens in a high-tech environment, surrounded by digital graphics and code."},{"@type":"BreadcrumbList","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/unit42.paloaltonetworks.com\/"},{"@type":"ListItem","position":2,"name":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection"}]},{"@type":"WebSite","@id":"https:\/\/unit42.paloaltonetworks.com\/#website","url":"https:\/\/unit42.paloaltonetworks.com\/","name":"Unit 42","description":"Palo Alto Networks","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/unit42.paloaltonetworks.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Person","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639","name":"Sheida Azimi","image":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/image\/4ffb3c2d260a0150fb91b3715442f8b3","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","caption":"Sheida Azimi"},"url":"https:\/\/unit42.paloaltonetworks.com\/fr\/author\/sheida-azimi\/"}]}},"_links":{"self":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts\/146708","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/users\/366"}],"replies":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/comments?post=146708"}],"version-history":[{"count":3,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts\/146708\/revisions"}],"predecessor-version":[{"id":146811,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts\/146708\/revisions\/146811"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/media\/143160"}],"wp:attachment":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/media?parent=146708"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/categories?post=146708"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/tags?post=146708"},{"taxonomy":"product_categories","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/product_categories?post=146708"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/coauthors?post=146708"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Lorsqu\u2019on utilise des fonctions serverless, il est important de prendre en compte les risques encourus lorsque les d\u00e9veloppeurs d\u2019applications d\u00e9ploient du code non s\u00e9curis\u00e9 dans les fonctions cloud, et de bien comprendre les menaces qui ciblent ces fonctions.<\/p>\n
<\/a>Comment fonctionne l\u2019authentification serverless sur les principales plateformes Cloud<\/h2>\nAvec l\u2019approche serverless, les applications sont d\u00e9ploy\u00e9es en ex\u00e9cutant des fonctions \u00e0 la demande. Le principal avantage de cette approche est que les applications ou les composants sp\u00e9cifiques peuvent \u00eatre ex\u00e9cut\u00e9s en fonction des besoins, ce qui \u00e9limine la n\u00e9cessit\u00e9 d\u2019un environnement d\u2019ex\u00e9cution continu.<\/p>\n
Chacun des principaux fournisseurs de cloud partage des concepts similaires pour les fonctions serverless, par exemple\u00a0:<\/p>\n
\n- La prise en charge de plusieurs langages de programmation<\/li>\n
- L\u2019absence d\u2019acc\u00e8s SSH en raison de leur architecture enti\u00e8rement manag\u00e9e<\/li>\n
- L\u2019utilisation de r\u00f4les, de comptes de service ou d\u2019identit\u00e9s manag\u00e9es pour contr\u00f4ler de mani\u00e8re s\u00e9curis\u00e9e l\u2019acc\u00e8s aux ressources<\/li>\n<\/ul>\n
<\/a>AWS\u00a0Lambda<\/strong><\/h3>\nLe service IAM d\u2019AWS permet de cr\u00e9er et de g\u00e9rer des utilisateurs, des autorisations, des groupes et des r\u00f4les. Ce service est responsable de la gestion des identit\u00e9s et de leur niveau d\u2019acc\u00e8s aux comptes et services AWS, ainsi que du contr\u00f4le de diverses fonctionnalit\u00e9s au sein d\u2019un compte AWS.<\/p>\n
Les fonctions serverless utilisent des r\u00f4les Lambda, qui n\u2019ont pas d\u2019autorisations par d\u00e9faut\u00a0; des politiques IAM doivent \u00eatre utilis\u00e9es pour g\u00e9rer les autorisations et s\u00e9curiser l\u2019acc\u00e8s \u00e0 d\u2019autres services AWS.<\/p>\n
Pour simplifier la gestion des autorisations, AWS propose des politiques g\u00e9r\u00e9es (comme AWSLambdaBasicExecutionRole) que les d\u00e9veloppeurs associent souvent \u00e0 ces r\u00f4les pour activer rapidement des fonctionnalit\u00e9s de base.<\/p>\n
Lorsqu\u2019un r\u00f4le IAM est associ\u00e9 \u00e0 une fonction Lambda, le service AWS Security Token Service (STS)<\/a> g\u00e9n\u00e8re automatiquement des identifiants de s\u00e9curit\u00e9 temporaires<\/a> pour ce r\u00f4le.<\/p>\nIl s\u2019agit d\u2019un moyen s\u00fbr d\u2019acc\u00e9der aux mat\u00e9riels d\u2019authentification au moment de l\u2019ex\u00e9cution, sans les risques associ\u00e9s aux mat\u00e9riels d\u2019authentification cod\u00e9s en dur \u00e0 long terme.<\/p>\n
Ces mat\u00e9riels d\u2019authentification sont limit\u00e9s aux autorisations d\u00e9finies dans la politique d\u2019acc\u00e8s associ\u00e9e au r\u00f4le. Il s\u2019agit d\u2019un identifiant de cl\u00e9 d\u2019acc\u00e8s, d\u2019une cl\u00e9 d\u2019acc\u00e8s secr\u00e8te et d\u2019un jeton de session.<\/p>\n
Au moment de l\u2019ex\u00e9cution, le service d\u2019ex\u00e9cution Lambda charge les mat\u00e9riels d\u2019authentification du r\u00f4le dans l\u2019environnement d\u2019ex\u00e9cution de la fonction et les stocke en tant que variables d\u2019environnement, telles que AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY<\/span> et AWS_SESSION_TOKEN<\/span>. Ces variables sont accessibles au code de la fonction pendant l\u2019ex\u00e9cution, ce qui permet \u00e0 la fonction d\u2019interagir en toute s\u00e9curit\u00e9 avec d\u2019autres services AWS.<\/p>\n<\/a>Google\u00a0Cloud\u00a0Functions<\/strong><\/h3>\nGoogle\u00a0Cloud\u00a0Functions utilise des jetons de compte de service pour authentifier et autoriser l\u2019acc\u00e8s \u00e0 d\u2019autres services Google\u00a0Cloud. Un compte de service est un compte Google sp\u00e9cialis\u00e9 li\u00e9 \u00e0 un projet<\/a> et repr\u00e9sente une identit\u00e9 non humaine, plut\u00f4t qu\u2019un utilisateur individuel.<\/p>\nLors du d\u00e9ploiement d\u2019une fonction cloud, les d\u00e9veloppeurs peuvent l\u2019associer \u00e0 un compte de service personnalis\u00e9 ou au compte de service par d\u00e9faut<\/a>. Lorsqu\u2019ils utilisent un compte de service personnalis\u00e9, les d\u00e9veloppeurs peuvent attribuer des r\u00f4les IAM sp\u00e9cifiques afin de d\u00e9finir les autorisations exactes dont la fonction a besoin pour accomplir ses t\u00e2ches.<\/p>\nLes comptes de service par d\u00e9faut sont des comptes g\u00e9r\u00e9s par l\u2019utilisateur<\/a> que Google\u00a0Cloud cr\u00e9e automatiquement lorsque les utilisateurs activent des services sp\u00e9cifiques. Par d\u00e9faut, Google\u00a0Cloud\u00a0Functions utilise diff\u00e9rents comptes de service en fonction de la g\u00e9n\u00e9ration<\/a>\u00a0:<\/p>\n\n- Les fonctions Cloud\u00a0Run de premi\u00e8re g\u00e9n\u00e9ration utilisent le compte de service par d\u00e9faut d\u2019App\u00a0Engine (<project_id>@appspot.gserviceaccount.com<\/span> ).<\/li>\n
- Les fonctions Cloud\u00a0Run de deuxi\u00e8me g\u00e9n\u00e9ration utilisent le compte de service Compute par d\u00e9faut (<num\u00e9ro_de_projet>-compute@developer.gserviceaccount.com<\/span>).<\/li>\n<\/ul>\n
Ces comptes de service par d\u00e9faut disposent souvent d\u2019autorisations d\u2019\u00e9diteur lorsque les d\u00e9veloppeurs utilisent GCP sans rattachement organisationnel, ce qui leur permet de cr\u00e9er, de modifier et de supprimer des ressources au sein du projet. Toutefois, dans les projets relevant d\u2019une organisation GCP, les comptes de service par d\u00e9faut sont cr\u00e9\u00e9s sans aucune autorisation. Dans ce cas, ils ne peuvent effectuer que les actions explicitement autoris\u00e9es par les r\u00f4les qui leur sont attribu\u00e9s.<\/p>\n
Bien qu\u2019une fonction GCP fonctionne dans un environnement serverless, lorsqu\u2019il s\u2019agit d\u2019acc\u00e9der aux mat\u00e9riels d\u2019authentification associ\u00e9s \u00e0 la fonction, elle se comporte de la m\u00eame mani\u00e8re qu\u2019un serveur traditionnel, tel qu\u2019une instance de machine virtuelle (VM), en r\u00e9cup\u00e9rant ses jetons de compte de service \u00e0 partir du serveur de m\u00e9tadonn\u00e9es d\u2019instance (IMDS)<\/a> au moment de l\u2019ex\u00e9cution. L\u2019IMDS \u00e0 l\u2019adresse hxxp:\/\/metadata.google[.]internal\/<\/span> fournit des jetons d\u2019acc\u00e8s de courte dur\u00e9e pour le compte de service associ\u00e9 \u00e0 la fonction. Ces jetons permettent \u00e0 la fonction de s\u2019authentifier aupr\u00e8s des services GCP.<\/p>\n<\/a>Azure\u00a0Functions<\/strong><\/h3>\nLes identit\u00e9s g\u00e9r\u00e9es par Azure permettent aux ressources Azure de s\u2019authentifier et d\u2019interagir avec d\u2019autres services Azure de mani\u00e8re s\u00e9curis\u00e9e et transparente, sans qu\u2019il soit n\u00e9cessaire de coder des mat\u00e9riels d\u2019authentification en dur. \u00c0 l\u2019instar des services fonctionnels d\u2019AWS et de GCP, ces identit\u00e9s \u00e9liminent les risques li\u00e9s \u00e0 la gestion des mat\u00e9riels d\u2019authentification dans le code.<\/p>\n
Les identit\u00e9s manag\u00e9es attribu\u00e9es par le syst\u00e8me sont li\u00e9es \u00e0 une ressource unique et sont automatiquement supprim\u00e9es lors de la suppression de la ressource. D\u2019autre part, les identit\u00e9s manag\u00e9es attribu\u00e9es par l\u2019utilisateur sont des ressources ind\u00e9pendantes qui peuvent \u00eatre attribu\u00e9es \u00e0 plusieurs services, ce qui offre une plus grande souplesse pour les sc\u00e9narios d\u2019authentification partag\u00e9e.<\/p>\n
Une fonction Azure \u00e0 laquelle est associ\u00e9e une identit\u00e9 manag\u00e9e doit utiliser son jeton d\u2019identit\u00e9 manag\u00e9e pour s\u2019authentifier aupr\u00e8s d\u2019une ressource Azure. Ci-dessous la proc\u00e9dure d\u2019authentification d\u00e9taill\u00e9e:<\/p>\n
\n- La fonction interroge ses variables d\u2019environnement pour r\u00e9cup\u00e9rer les valeurs de IDENTITY_ENDPOINT<\/span> et IDENTITY_HEADER<\/span>.\n
\n- IDENTITY_ENDPOINT<\/span>\u00a0: Une variable d\u2019environnement<\/a> qui contient l\u2019adresse du terminal local de l\u2019identit\u00e9 manag\u00e9e fourni par Azure. Il s\u2019agit d\u2019une URL locale \u00e0 partir de laquelle une application peut demander des jetons.<\/li>\n
- IDENTITY_HEADER<\/span>\u00a0: Param\u00e8tre obligatoire lors de l\u2019interrogation du terminal local de l\u2019identit\u00e9 manag\u00e9e. Cet en-t\u00eate est utilis\u00e9 pour att\u00e9nuer les attaques SSRF.<\/li>\n<\/ul>\n<\/li>\n
- La fonction envoie une requ\u00eate HTTP GET au terminal local de l\u2019identit\u00e9 manag\u00e9e avec l\u2019en-t\u00eate IDENTITY_HEADER<\/span> inclus dans l\u2019en-t\u00eate HTTP. (Pour plus de d\u00e9tails sur la structure de la demande, voir la documentation d\u2019Azure sur l\u2019acquisition de jetons pour les App\u00a0Services<\/a>)<\/li>\n
- Microsoft\u00a0Entra\u00a0ID<\/a> (anciennement Azure\u00a0Active\u00a0Directory) v\u00e9rifie l\u2019identit\u00e9 de la fonction et \u00e9met un jeton OAuth\u00a02.0 temporaire qui est limit\u00e9 sp\u00e9cifiquement \u00e0 la ressource cible.<\/li>\n
- La fonction inclut le jeton \u00e9mis dans sa demande \u00e0 la ressource Azure (par exemple, Azure\u00a0Key\u00a0Vault<\/a>, compte de stockage<\/a>).<\/li>\n
- La ressource Azure valide le jeton et v\u00e9rifie les autorisations de la fonction \u00e0 l\u2019aide du contr\u00f4le d\u2019acc\u00e8s bas\u00e9 sur les r\u00f4les<\/a> ou des politiques d\u2019acc\u00e8s sp\u00e9cifiques aux ressources<\/a>.<\/li>\n<\/ul>\n
Si elle est autoris\u00e9e, la ressource accorde l\u2019acc\u00e8s pour effectuer l\u2019op\u00e9ration demand\u00e9e. Cela garantit une authentification s\u00fbre et transparente sans qu\u2019il soit n\u00e9cessaire d\u2019utiliser des secrets cod\u00e9s en dur dans le code.<\/p>\n
<\/a>Vecteurs d\u2019attaque pour l\u2019exfiltration de jetons<\/h2>\nCette section aborde les risques et les menaces li\u00e9s \u00e0 l\u2019utilisation de fonctions serverless. Lorsqu\u2019ils d\u00e9veloppent et configurent des fonctions, les d\u00e9veloppeurs d\u2019applications doivent veiller \u00e0 s\u00e9curiser ces fonctions contre des attaques telles que SSRF et RCE. En l\u2019absence d\u2019une telle s\u00e9curit\u00e9, les attaquants pourraient manipuler les fonctions serverless qui sont vuln\u00e9rables au SSRF, ce qui am\u00e8nerait les fonctions \u00e0 envoyer des requ\u00eates non autoris\u00e9es aux services internes. Cela peut conduire \u00e0 un acc\u00e8s involontaire ou \u00e0 l\u2019exposition d\u2019informations sensibles au sein du syst\u00e8me, telles que les jetons d\u2019acc\u00e8s, le contenu de la base de donn\u00e9es interne ou les configurations de service. Il est important de souligner que ces risques surviennent principalement lorsque les fonctions sont publiques ou qu\u2019elles traitent des donn\u00e9es provenant d\u2019utilisateurs externes et d\u2019autres sources.<\/p>\n
Dans les attaques SSRF, un attaquant trompe un serveur (comme une fonction serverless) en effectuant des requ\u00eates HTTP vers des ressources internes ou externes auxquelles l\u2019attaquant ne devrait pas avoir acc\u00e8s. Comme c\u2019est le serveur lui-m\u00eame qui fait la demande, il peut acc\u00e9der \u00e0 des services internes qui ne sont pas expos\u00e9s \u00e0 Internet. Une fonction serverlessr vuln\u00e9rable prend une URL en entr\u00e9e et r\u00e9cup\u00e8re les donn\u00e9es \u00e0 partir de celle-ci.<\/p>\n
Dans GCP, SSRF peut \u00eatre utilis\u00e9 pour acc\u00e9der \u00e0 l\u2019IMDS \u00e0 l\u2019adresse hxxp:\/\/metadata.google[.]internal\/<\/span>, en extrayant des jetons temporaires de compte de service. Un attaquant peut alors utiliser ces jetons pour se faire passer pour la fonction et effectuer des actions non autoris\u00e9es dans le cadre des autorisations de son r\u00f4le IAM. Les vuln\u00e9rabilit\u00e9s li\u00e9es \u00e0 l\u2019ex\u00e9cution de code \u00e0 distance permettent aux attaquants d\u2019ex\u00e9cuter du code arbitraire dans l\u2019environnement d\u2019une fonction.<\/p>\nPour AWS\u00a0Lambda, les attaques RCE pourraient exposer des mat\u00e9riels d\u2019authentification temporaires stock\u00e9es dans des variables d\u2019environnement, telles que AWS_ACCESS_KEY_ID<\/span> et AWS_SESSION_TOKEN<\/span>.<\/p>\nIl est essentiel de noter que ces vecteurs d\u2019attaque ne sont pas des failles inh\u00e9rentes aux plateformes cloud elles-m\u00eames, mais d\u00e9coulent plut\u00f4t d\u2019un d\u00e9veloppement non s\u00e9curis\u00e9 r\u00e9dig\u00e9 par les d\u00e9veloppeurs d\u2019applications qui pourrait introduire des vuln\u00e9rabilit\u00e9s, telles que SSRF ou RCE. Les d\u00e9veloppeurs d\u2019applications peuvent att\u00e9nuer ces risques en mettant en \u0153uvre des pratiques de d\u00e9veloppement s\u00e9curis\u00e9 telles que la validation des entr\u00e9es.<\/p>\n
<\/a>Simulations de vecteurs d\u2019attaque<\/strong><\/h3>\nLes simulations suivantes montrent comment les attaquants pourraient extraire les jetons serverless et les utiliser pour des activit\u00e9s malveillantes dans diff\u00e9rents fournisseurs de services cloud (CSP). Ces attaques pourraient tirer parti d\u2019un code de fonction non s\u00e9curis\u00e9 d\u00e9ploy\u00e9 par les d\u00e9veloppeurs d\u2019applications.<\/p>\n
<\/a>Simulation\u00a01\u00a0: Acc\u00e8s direct \u00e0 l\u2019IMDS \u00e0 partir d\u2019une fonction BPC<\/h4>\nPour r\u00e9aliser cette simulation, nous avons d\u00e9ploy\u00e9 deux fonctions Google\u00a0Cloud\u00a0Run qui acc\u00e8dent au service de m\u00e9tadonn\u00e9es des fonctions et extraient les jetons des deux diff\u00e9rents comptes de service associ\u00e9s \u00e0 partir du chemin suivant\u00a0:<\/p>\n
\n- hxxp[:\/\/]metadata.google[.]internal\/computeMetadata\/v1\/instance\/service-accounts\/default\/token<\/span><\/li>\n<\/ul>\n
Le premier exemple illustre l\u2019extraction d\u2019un compte de service par d\u00e9faut. Le deuxi\u00e8me exemple illustre l\u2019extraction d\u2019un compte de service personnalis\u00e9. Ces exemples montrent comment le code peut acc\u00e9der directement au service de m\u00e9tadonn\u00e9es, tout comme une application vuln\u00e9rable \u00e0 une attaque SSRF pourrait \u00e9galement y acc\u00e9der.<\/p>\n
<\/a>Exemple\u00a01\u00a0: Extraction d\u2019un compte de service par d\u00e9faut dans GCP<\/strong><\/h5>\nComme le montre la figure\u00a01, le compte de service associ\u00e9 \u00e0 la fonction \u00e9tait le compte de service serverless par d\u00e9faut. La figure\u00a02 montre que le jeton d\u2019acc\u00e8s renvoy\u00e9 appartient au m\u00eame compte de service.<\/p>\n![\"Capture]()
Figure 1. Informations g\u00e9n\u00e9rales sur la fonction, y compris le nom de compte de service associ\u00e9 (le compte de service par d\u00e9faut).<\/figcaption><\/figure>\n![\"Capture]()
Figure 2. Commande utilis\u00e9e pour extraire le jeton d\u2019acc\u00e8s au compte de service, y compris le r\u00e9sultat.<\/figcaption><\/figure>\n<\/a>Exemple\u00a02\u00a0: Extraction d\u2019un compte de service personnalis\u00e9 dans GCP<\/strong><\/h5>\nLa figure\u00a03 montre le compte de service personnalis\u00e9 que nous avons associ\u00e9 \u00e0 la fonction. La figure\u00a04 montre le jeton d\u2019acc\u00e8s renvoy\u00e9 appartenant au compte de service personnalis\u00e9. Nous avons ensuite utilis\u00e9 le jeton renvoy\u00e9 pour effectuer des op\u00e9rations dans l\u2019environnement.<\/p>\n![\"Capture]()
Figure 3. Informations g\u00e9n\u00e9rales sur la fonction, y compris le nom du compte de service associ\u00e9 (un compte de service personnalis\u00e9).<\/figcaption><\/figure>\n![\"Capture]()
Figure 4. Commande utilis\u00e9e pour extraire le jeton d\u2019acc\u00e8s au compte de service, y compris le r\u00e9sultat.<\/figcaption><\/figure>\nLa figure\u00a05 ci-dessous montre un exemple de commande permettant de lister les buckets.<\/p>\n![\"Capture]()
Figure 5. Utilisation du jeton renvoy\u00e9 pour lister les buckets du compte de service.<\/figcaption><\/figure>\nSi des attaquants peuvent r\u00e9pertorier et lire le contenu des buckets dans GCP, ils peuvent acc\u00e9der \u00e0 des fichiers sensibles tels que des mat\u00e9riels d\u2019authentification, des sauvegardes ou des configurations internes. Cela leur permet de voler des donn\u00e9es, de compromettre le syst\u00e8me ou de se d\u00e9placer lat\u00e9ralement au sein de l\u2019environnement.<\/p>\n
Une fois que les attaquants obtiennent un jeton d\u2019acc\u00e8s pour un compte de service avec des autorisations d\u2019\u00e9diteur dans GCP (comme le compte de service Compute\u00a0Engine par d\u00e9faut), ils peuvent modifier, supprimer ou cr\u00e9er des ressources dans la plupart des services. Il peut s\u2019agir d\u2019acc\u00e9der \u00e0 des donn\u00e9es sensibles, de d\u00e9ployer des workloads malveillants, d\u2019escalader des privil\u00e8ges ou de perturber des services. L\u2019acc\u00e8s de l\u2019\u00e9diteur permet un contr\u00f4le quasi total du projet.<\/p>\n
<\/a>Simulation\u00a02\u00a0: Utilisation de RCE pour r\u00e9cup\u00e9rer les jetons stock\u00e9s dans les variables d\u2019environnement de la fonction AWS\u00a0Lambda<\/h4>\nDans cette simulation, nous avons acc\u00e9d\u00e9 aux variables d\u2019environnement de la fonction Lambda et en avons extrait l\u2019AWS_ACCESS_KEY_ID<\/span>, l\u2019AWS_SECRET_ACCESS_KEY<\/span> et l\u2019AWS_SESSION_TOKEN<\/span>.<\/p>\nLa figure\u00a06 montre la sortie du code de la fonction Lambda.<\/p>\n![\"Capture]()
Figure 6. Valeurs des variables d\u2019environnement renvoy\u00e9es.<\/figcaption><\/figure>\nLa figure\u00a07 montre la configuration des identifiants AWS temporaires obtenus \u00e0 l\u2019\u00e9tape pr\u00e9c\u00e9dente (les variables d\u2019environnement Lambda).<\/p>\n![\"\u00c9cran]()
Figure\u00a07. Extrait de code des commandes utilis\u00e9es pour lister les buckets\u00a0S3.<\/figcaption><\/figure>\nNous avons ensuite utilis\u00e9 la commande suivante pour dresser la liste de tous les buckets\u00a0S3 auxquels la session authentifi\u00e9e peut acc\u00e9der.<\/p>\n
aws s3 ls<\/pre>\n<\/a>Simulation\u00a03\u00a0: Utilisation de RCE pour r\u00e9cup\u00e9rer des jetons \u00e0 partir d\u2019un terminal d\u2019identit\u00e9 local d\u2019une fonction Azure<\/h4>\nDans cette simulation, nous avons acc\u00e9d\u00e9 aux variables d\u2019environnement de la fonction Azure et extrait l\u2019IDENTITY_ENDPOINT et l\u2019IDENTITY_HEADER en ex\u00e9cutant des commandes \u00e0 distance. Nous avons ensuite extrait le jeton d\u2019identit\u00e9 manag\u00e9e via le terminal d\u2019identit\u00e9 local, en fournissant les param\u00e8tres indiqu\u00e9s ci-dessous dans la figure\u00a08\u00a0:<\/p>\n
\n- Ressource<\/li>\n
- version de l\u2019API<\/span><\/li>\n
- X-IDENTITY-HEADER<\/span><\/li>\n<\/ul>\n
![\"Capture]()
Figure 8. La sortie du script, y compris le jeton d\u2019acc\u00e8s.<\/figcaption><\/figure>\n<\/a>D\u00e9tection et pr\u00e9vention de l\u2019exfiltration de jetons<\/h2>\n<\/a>D\u00e9tection de l\u2019exfiltration de jetons dans les environnements sans serveur<\/strong><\/h3>\nDes m\u00e9canismes de d\u00e9tection efficaces sont essentiels pour identifier l\u2019exfiltration de jetons dans les environnements sans serveur. Ces m\u00e9canismes se concentrent sur les anomalies de comportement pour signaler les activit\u00e9s non autoris\u00e9es. Voici quelques-unes des principales strat\u00e9gies de d\u00e9tection mises en \u0153uvre sur les principales plateformes cloud.<\/p>\n
La d\u00e9tection se fait en deux \u00e9tapes\u00a0:<\/p>\n
\n- Valider que l\u2019identit\u00e9 est associ\u00e9e \u00e0 une fonction serverless.<\/li>\n
- Identifier les comportements anormaux des identit\u00e9s sans serveur. Ces comportements peuvent inclure\u00a0:\n
\n- Les adresses IP source qui ne correspondent pas au contexte dans lequel la fonction est ex\u00e9cut\u00e9e, telles que les adresses provenant de num\u00e9ros de syst\u00e8mes autonomes (ASN) qui ne sont pas associ\u00e9s \u00e0 un fournisseur de services cloud.<\/li>\n
- Les identit\u00e9s serverless effectuant des requ\u00eates avec des user-agents suspects.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
<\/a>\u00c9tape\u00a01\u00a0: Identifier les identit\u00e9s serverless<\/h4>\nPour identifier les comptes de service associ\u00e9s aux fonctions sans serveur dans GCP, nous analysons la section serviceAccountDelegationInfo<\/span> dans les journaux. Ces informations fournissent des indications cruciales sur la cha\u00eene de d\u00e9l\u00e9gation des comptes de service. Plus pr\u00e9cis\u00e9ment, lorsqu\u2019un compte de service est associ\u00e9 \u00e0 une fonction, il d\u00e9l\u00e8gue son autorit\u00e9 \u00e0 un compte de service sans serveur par d\u00e9faut\u00a0:<\/p>\n\n- Google\u00a0Cloud\u00a0Run\u00a0Service\u00a0Agent (service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>)<\/li>\n
- gcf-admin-robot.iam.gserviceaccount[.]com<\/span> (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com<\/span>)<\/li>\n<\/ul>\n
Ces comptes de service ex\u00e9cutent des t\u00e2ches au nom de la fonction.<\/p>\n
Par exemple, dans l\u2019entr\u00e9e de journal de la figure\u00a09, nous voyons le compte de service personnalis\u00e9 associ\u00e9 \u00e0 une fonction (sa-test@<project-id>.iam.gserviceaccount[.]com<\/span>) d\u00e9l\u00e9guer son autorit\u00e9 \u00e0 l\u2019agent de service Cloud\u00a0Run.<\/p>\n![\"Capture]()
Figure 9. Entr\u00e9e de journal montrant un compte de service personnalis\u00e9.<\/figcaption><\/figure>\nDans la figure\u00a09 ci-dessus, le champ principalEmail<\/span> sous authenticationInfo<\/span> sp\u00e9cifie le compte de service utilis\u00e9 (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com<\/span>).<\/p>\nLe serviceAccountDelegationInfo indique<\/span> le principal de premi\u00e8re partie (dans ce cas\u00a0: service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>), ce qui indique que le compte de service fonctionne dans un environnement sans serveur comme Cloud\u00a0Functions ou Cloud\u00a0Run.<\/p>\nUne approche efficace pour d\u00e9couvrir les identit\u00e9s serverless consiste \u00e0 \u00e9tablir le profil des comptes de service qui ont pr\u00e9c\u00e9demment d\u00e9l\u00e9gu\u00e9 leur autorit\u00e9 \u00e0 des comptes de service sans serveur par d\u00e9faut. Cela garantit que m\u00eame si des comptes de service autres que ceux par d\u00e9faut sont associ\u00e9s \u00e0 des fonctions, ils sont identifi\u00e9s.<\/p>\n
Dans AWS, les fonctions Lambda s\u2019appuient sur les r\u00f4les IAM pour s\u00e9curiser l\u2019acc\u00e8s aux services AWS. Ces r\u00f4les g\u00e9n\u00e8rent des mat\u00e9riels d\u2019authentification temporaires. Nous pouvons identifier l\u2019identit\u00e9 Lambda par son nom de r\u00f4le.<\/p>\n
Dans Azure, les identit\u00e9s manag\u00e9es associ\u00e9es aux Azure\u00a0Function\u00a0Apps sont utilis\u00e9es pour l\u2019authentification.<\/p>\n
<\/a>\u00c9tape\u00a02\u00a0: Identifier les comportements inhabituels pour les identit\u00e9s serverless<\/h4>\nDans un environnement cloud s\u00e9curis\u00e9, les fonctions serverless sont g\u00e9n\u00e9ralement destin\u00e9es \u00e0 ex\u00e9cuter des t\u00e2ches automatis\u00e9es et circonscrites, telles que la r\u00e9ponse \u00e0 des requ\u00eates API ou le traitement d\u2019\u00e9v\u00e9nements. Ces fonctions ne doivent pas \u00eatre utilis\u00e9es de mani\u00e8re interactive. Cependant, si des attaquants obtiennent l\u2019acc\u00e8s \u00e0 l\u2019environnement d\u2019une fonction sans serveur ou \u00e0 son identit\u00e9, ils peuvent l\u2019utiliser \u00e0 mauvais escient pour ex\u00e9cuter des commandes d\u2019interface de ligne de commande (CLI) (par exemple, gcloud<\/span> CLI<\/span> ou curl<\/span>) afin d\u2019interagir directement avec les ressources du cloud.<\/p>\nUne m\u00e9thode de d\u00e9tection consiste \u00e0 examiner le user-agent des appels API. Si l\u2019agent utilisateur correspond \u00e0 des outils CLI connus (par exemple, gcloud CLI<\/span>) ou \u00e0 des cadres de test d\u2019intrusion, il est signal\u00e9 comme suspect, car les CLI ne devraient g\u00e9n\u00e9ralement pas \u00eatre utilis\u00e9es par les identit\u00e9s serverless. Cela indique une exploitation potentielle de l\u2019environnement ou des jetons de compte de service.<\/p>\n\u00c0 noter que cette m\u00e9thode d\u2019identification de l\u2019utilisation \u00e0 distance des jetons sans serveur en fonction de l\u2019agent utilisateur ne peut pas \u00eatre r\u00e9alis\u00e9e dans Azure, car les informations relatives au user-agent n\u2019apparaissent pas dans les journaux Azure.<\/p>\n
Une autre approche pour d\u00e9tecter l\u2019utilisation \u00e0 distance d\u2019un jeton d\u2019identit\u00e9 sans serveur consiste \u00e0 corr\u00e9ler l\u2019emplacement de l\u2019utilisation d\u2019un jeton avec des plages ASN d\u2019adresses IP de fournisseurs de cloud connus. Si une demande provient d\u2019une adresse IP externe non associ\u00e9e au CSP, une alerte est d\u00e9clench\u00e9e, mettant en \u00e9vidence une \u00e9ventuelle utilisation non autoris\u00e9e du jeton en dehors de l\u2019environnement cloud.<\/p>\n
<\/a>Strat\u00e9gies de pr\u00e9vention<\/h3>\nLa s\u00e9curisation des jetons serverless n\u00e9cessite une combinaison de mesures proactives, de gestion de la posture et de pratiques de s\u00e9curit\u00e9 de surveillance de l\u2019ex\u00e9cution pour minimiser le risque d\u2019exploitation. Tout d\u2019abord, mettez en \u0153uvre le principe du moindre privil\u00e8ge en attribuant des r\u00f4les avec les autorisations minimales requises pour les fonctions sans serveur. Cela r\u00e9duit l\u2019impact potentiel d\u2019une mauvaise utilisation des jetons.<\/p>\n
En outre, pour prot\u00e9ger les environnements d\u2019ex\u00e9cution sans serveur dans GCP et Azure, restreignez l\u2019acc\u00e8s \u00e0 l\u2019IMDS en configurant des contr\u00f4les au niveau du r\u00e9seau et en appliquant des m\u00e9canismes de validation des demandes. Assurer une validation robuste des entr\u00e9es pour emp\u00eacher les attaquants d\u2019utiliser des techniques d\u2019exploitation comme le SSRF pour acc\u00e9der aux m\u00e9tadonn\u00e9es sensibles, aux jetons et \u00e0 d\u2019autres ressources cloud comme les API et les bases de donn\u00e9es.<\/p>\n
<\/a>Conclusion<\/h2>\nL\u2019informatique serverless est le choix privil\u00e9gi\u00e9 pour le d\u00e9veloppement d\u2019applications modernes, car elle offre des avantages significatifs en termes d\u2019\u00e9volutivit\u00e9, de rentabilit\u00e9 et de gestion simplifi\u00e9e de l\u2019infrastructure.<\/p>\n
Les mat\u00e9riels d'authentification permettant \u00e0 ces fonctions d\u2019interagir avec les services cloud constituent un \u00e9l\u00e9ment de s\u00e9curit\u00e9 essentiel et une cible de choix pour les attaquants. La compromission de ces mat\u00e9riels d\u2019authentification peut avoir de graves cons\u00e9quences, notamment l\u2019acc\u00e8s non autoris\u00e9 \u00e0 des ressources cloud et l\u2019exfiltration de donn\u00e9es.<\/p>\n
La mise en \u0153uvre d\u2019une gestion proactive de la posture et de protections de surveillance de l\u2019ex\u00e9cution est une strat\u00e9gie cruciale pour la protection des environnements cloud.<\/p>\n
Les organisations peuvent mieux prot\u00e9ger leurs environnements sans serveur en\u00a0:<\/p>\n
\n- Comprenant les m\u00e9canismes des r\u00e9f\u00e9rences serverless et les meilleures pratiques pour les provisionner et les g\u00e9rer dans AWS, Azure et GCP<\/a><\/li>\n
- Reconnaissant les vecteurs d\u2019attaque courants tels que l\u2019exfiltration de jetons via l\u2019exploitation de l\u2019IMDS ou l\u2019acc\u00e8s aux variables d\u2019environnement<\/li>\n<\/ul>\n
<\/a>Protection et mitigation des risques par Palo\u00a0Alto\u00a0Networks<\/h2>\nLes clients de Palo\u00a0Alto\u00a0Networks sont mieux prot\u00e9g\u00e9s contre les menaces mentionn\u00e9es ci-dessus gr\u00e2ce aux produits suivants\u00a0:<\/p>\n
Si vous pensez que votre entreprise a pu \u00eatre compromise ou si vous faites face \u00e0 une urgence, contactez l\u2019\u00e9quipe Unit\u00a042 de r\u00e9ponse aux incidents<\/a> ou composez l\u2019un des num\u00e9ros suivants\u00a0:<\/p>\n\n- Am\u00e9rique du Nord Par t\u00e9l\u00e9phone\u00a0: 866.486.4842 (866.4.UNIT42)<\/li>\n
- EMEA\u00a0: +31\u00a020\u00a0299\u00a03130<\/li>\n
- APAC\u00a0: +65\u00a06983\u00a08730<\/li>\n
- Japon\u00a0: +81\u00a050\u00a01790\u00a00200<\/li>\n<\/ul>\n
Palo\u00a0Alto\u00a0Networks a partag\u00e9 ces conclusions avec les autres membres de la Cyber\u00a0Threat\u00a0Alliance (CTA). Les membres de la CTA s\u2019appuient sur ces renseignements pour d\u00e9ployer rapidement des mesures de protection aupr\u00e8s de leurs clients et perturber de mani\u00e8re coordonn\u00e9e les activit\u00e9s des cybercriminels. Cliquez ici pour en savoir plus sur la Cyber Threat Alliance.<\/a><\/p>\n<\/a>Pour aller plus loin<\/h2>\n\n- Utilisation des variables d\u2019environnement Lambda<\/a> - Guide du d\u00e9veloppeur AWS\u00a0Lambda<\/li>\n
- S\u00e9curisation de variables d\u2019environnement Lambda<\/a> - Guide du d\u00e9veloppeur AWS\u00a0Lambda<\/li>\n
- Gestion des autorisations dans AWS\u00a0Lambda<\/a> - Guide du d\u00e9veloppeur AWS\u00a0Lambda<\/li>\n
- Identit\u00e9 de fonction<\/a> - Google\u00a0Cloud<\/li>\n
- Que sont les identit\u00e9s manag\u00e9es pour les ressources Azure\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- S\u00e9curisation d\u2019Azure\u00a0Functions<\/a> - Microsoft\u00a0Learn<\/li>\n
- Qu\u2019est-ce que c\u2019est, AWS\u00a0Secrets\u00a0Manager\u00a0?<\/a> - Guide de l\u2019utilisateur AWS\u00a0Secret\u00a0Manager<\/li>\n
- Concepts de base d\u2019Azure\u00a0Key\u00a0Vault<\/a> - Microsoft\u00a0Learn<\/li>\n
- Pr\u00e9sentation de Secret\u00a0Manager<\/a> - Documentation de Google\u00a0Cloud Secret\u00a0Manager<\/li>\n
- Qu\u2019est-ce que la gestion des identit\u00e9s et des acc\u00e8s (IAM)\u00a0?<\/a> - Microsoft\u00a0Security<\/li>\n
- Que sont les identit\u00e9s manag\u00e9es pour les ressources Azure\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- Contr\u00f4le des identit\u00e9s et des acc\u00e8s<\/a> - Introduction \u00e0 la s\u00e9curit\u00e9 AWS - Livre blanc AWS<\/li>\n
- Identifiants du compte de service<\/a> - Documentation Google\u00a0Cloud\u00a0IAM<\/li>\n
- Identifiants de s\u00e9curit\u00e9 temporaires dans IAM<\/a> - Guide de l\u2019utilisateur de AWS\u00a0Identity et Access\u00a0Management<\/li>\n
- R\u00e9f\u00e9rence API du service de jetons de s\u00e9curit\u00e9 AWS<\/a> - Documentation du service de jetons de s\u00e9curit\u00e9 AWS<\/li>\n
- Instances Compute\u00a0Engine<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- Projets Google\u00a0Cloud<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- Comptes de service g\u00e9r\u00e9s par l\u2019utilisateur<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- Comparer les fonctions Cloud\u00a0Run<\/a> - Documentation Google\u00a0Cloud\u00a0Run<\/li>\n
- Comptes de service par d\u00e9faut<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- R\u00e9f\u00e9rence du terminal REST<\/a> - Identit\u00e9s manag\u00e9es pour App\u00a0Service et Azure\u00a0Functions<\/li>\n
- Variables d\u2019environnement et param\u00e8tres d\u2019application dans Azure\u00a0App\u00a0Service<\/a> - Microsoft\u00a0Learn<\/li>\n
- Guide pratique de l\u2019utilisation d\u2019identit\u00e9s manag\u00e9es pour ressources Azure sur une machine virtuelle Azure afin d\u2019acqu\u00e9rir un jeton d\u2019acc\u00e8s<\/a> - Microsoft\u00a0Learn<\/li>\n
- Qu\u2019est-ce que l\u2019identifiant Microsoft\u00a0Entra\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- \u00c0 propos d\u2019Azure\u00a0Key\u00a0Vault<\/a> - Microsoft\u00a0Learn<\/li>\n
- Autoriser l\u2019acc\u00e8s aux objets blobs \u00e0 l\u2019aide de l\u2019identifiant Microsoft\u00a0Entra<\/a> - Microsoft\u00a0Learn<\/li>\n
- Pr\u00e9sentation du compte de stockage<\/a> - Microsoft\u00a0Learn<\/li>\n
- Qu\u2019est-ce que le contr\u00f4le d\u2019acc\u00e8s en fonction du r\u00f4le Azure (RBAC Azure)\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- Politiques d\u2019acc\u00e8s sp\u00e9cifiques aux ressources<\/a> - Microsoft\u00a0Learn<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.<\/p>\n","protected":false},"author":366,"featured_media":143160,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[8724,8832],"tags":[9293,9341,9342,9228],"product_categories":[9041,9046,9151],"coauthors":[4194],"class_list":["post-146708","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-cybersecurity-research-fr","category-threat-research-fr","tag-aws-fr","tag-google-cloud-fr","tag-microsoft-azure-fr","tag-serverless-fr","product_categories-cortex-fr","product_categories-cortex-cloud-fr","product_categories-unit-42-incident-response-fr"],"yoast_head":"\n
Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection<\/title>\n<meta name=\"description\" content=\"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection\" \/>\n<meta property=\"og:description\" content=\"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:site_name\" content=\"Unit 42\" \/>\n<meta property=\"article:published_time\" content=\"2025-06-13T16:31:03+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-07-14T17:31:16+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"900\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Zohar Zigdon\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","description":"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","og_locale":"fr_FR","og_type":"article","og_title":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","og_description":"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.","og_url":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","og_site_name":"Unit 42","article_published_time":"2025-06-13T16:31:03+00:00","article_modified_time":"2025-07-14T17:31:16+00:00","og_image":[{"width":1920,"height":900,"url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","type":"image\/jpeg"}],"author":"Zohar Zigdon","twitter_card":"summary_large_image","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#article","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/"},"author":{"name":"Sheida Azimi","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"headline":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","datePublished":"2025-06-13T16:31:03+00:00","dateModified":"2025-07-14T17:31:16+00:00","mainEntityOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/"},"wordCount":5063,"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","keywords":["AWS","Google Cloud","Microsoft Azure","serverless"],"articleSection":["\u00c9tudes sur la cybers\u00e9curit\u00e9 du cloud","Recherche sur les menaces"],"inLanguage":"fr-FR"},{"@type":"WebPage","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","url":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","name":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage"},"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","datePublished":"2025-06-13T16:31:03+00:00","dateModified":"2025-07-14T17:31:16+00:00","author":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"description":"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.","breadcrumb":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/"]}]},{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","width":1920,"height":900,"caption":"Pictorial representation of serverless tokens in the cloud. East Asian woman examining data on multiple screens in a high-tech environment, surrounded by digital graphics and code."},{"@type":"BreadcrumbList","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/unit42.paloaltonetworks.com\/"},{"@type":"ListItem","position":2,"name":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection"}]},{"@type":"WebSite","@id":"https:\/\/unit42.paloaltonetworks.com\/#website","url":"https:\/\/unit42.paloaltonetworks.com\/","name":"Unit 42","description":"Palo Alto Networks","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/unit42.paloaltonetworks.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Person","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639","name":"Sheida Azimi","image":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/image\/4ffb3c2d260a0150fb91b3715442f8b3","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","caption":"Sheida Azimi"},"url":"https:\/\/unit42.paloaltonetworks.com\/fr\/author\/sheida-azimi\/"}]}},"_links":{"self":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts\/146708","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/users\/366"}],"replies":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/comments?post=146708"}],"version-history":[{"count":3,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts\/146708\/revisions"}],"predecessor-version":[{"id":146811,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts\/146708\/revisions\/146811"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/media\/143160"}],"wp:attachment":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/media?parent=146708"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/categories?post=146708"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/tags?post=146708"},{"taxonomy":"product_categories","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/product_categories?post=146708"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/coauthors?post=146708"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
<\/a>AWS\u00a0Lambda<\/strong><\/h3>\nLe service IAM d\u2019AWS permet de cr\u00e9er et de g\u00e9rer des utilisateurs, des autorisations, des groupes et des r\u00f4les. Ce service est responsable de la gestion des identit\u00e9s et de leur niveau d\u2019acc\u00e8s aux comptes et services AWS, ainsi que du contr\u00f4le de diverses fonctionnalit\u00e9s au sein d\u2019un compte AWS.<\/p>\n
Les fonctions serverless utilisent des r\u00f4les Lambda, qui n\u2019ont pas d\u2019autorisations par d\u00e9faut\u00a0; des politiques IAM doivent \u00eatre utilis\u00e9es pour g\u00e9rer les autorisations et s\u00e9curiser l\u2019acc\u00e8s \u00e0 d\u2019autres services AWS.<\/p>\n
Pour simplifier la gestion des autorisations, AWS propose des politiques g\u00e9r\u00e9es (comme AWSLambdaBasicExecutionRole) que les d\u00e9veloppeurs associent souvent \u00e0 ces r\u00f4les pour activer rapidement des fonctionnalit\u00e9s de base.<\/p>\n
Lorsqu\u2019un r\u00f4le IAM est associ\u00e9 \u00e0 une fonction Lambda, le service AWS Security Token Service (STS)<\/a> g\u00e9n\u00e8re automatiquement des identifiants de s\u00e9curit\u00e9 temporaires<\/a> pour ce r\u00f4le.<\/p>\nIl s\u2019agit d\u2019un moyen s\u00fbr d\u2019acc\u00e9der aux mat\u00e9riels d\u2019authentification au moment de l\u2019ex\u00e9cution, sans les risques associ\u00e9s aux mat\u00e9riels d\u2019authentification cod\u00e9s en dur \u00e0 long terme.<\/p>\n
Ces mat\u00e9riels d\u2019authentification sont limit\u00e9s aux autorisations d\u00e9finies dans la politique d\u2019acc\u00e8s associ\u00e9e au r\u00f4le. Il s\u2019agit d\u2019un identifiant de cl\u00e9 d\u2019acc\u00e8s, d\u2019une cl\u00e9 d\u2019acc\u00e8s secr\u00e8te et d\u2019un jeton de session.<\/p>\n
Au moment de l\u2019ex\u00e9cution, le service d\u2019ex\u00e9cution Lambda charge les mat\u00e9riels d\u2019authentification du r\u00f4le dans l\u2019environnement d\u2019ex\u00e9cution de la fonction et les stocke en tant que variables d\u2019environnement, telles que AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY<\/span> et AWS_SESSION_TOKEN<\/span>. Ces variables sont accessibles au code de la fonction pendant l\u2019ex\u00e9cution, ce qui permet \u00e0 la fonction d\u2019interagir en toute s\u00e9curit\u00e9 avec d\u2019autres services AWS.<\/p>\n<\/a>Google\u00a0Cloud\u00a0Functions<\/strong><\/h3>\nGoogle\u00a0Cloud\u00a0Functions utilise des jetons de compte de service pour authentifier et autoriser l\u2019acc\u00e8s \u00e0 d\u2019autres services Google\u00a0Cloud. Un compte de service est un compte Google sp\u00e9cialis\u00e9 li\u00e9 \u00e0 un projet<\/a> et repr\u00e9sente une identit\u00e9 non humaine, plut\u00f4t qu\u2019un utilisateur individuel.<\/p>\nLors du d\u00e9ploiement d\u2019une fonction cloud, les d\u00e9veloppeurs peuvent l\u2019associer \u00e0 un compte de service personnalis\u00e9 ou au compte de service par d\u00e9faut<\/a>. Lorsqu\u2019ils utilisent un compte de service personnalis\u00e9, les d\u00e9veloppeurs peuvent attribuer des r\u00f4les IAM sp\u00e9cifiques afin de d\u00e9finir les autorisations exactes dont la fonction a besoin pour accomplir ses t\u00e2ches.<\/p>\nLes comptes de service par d\u00e9faut sont des comptes g\u00e9r\u00e9s par l\u2019utilisateur<\/a> que Google\u00a0Cloud cr\u00e9e automatiquement lorsque les utilisateurs activent des services sp\u00e9cifiques. Par d\u00e9faut, Google\u00a0Cloud\u00a0Functions utilise diff\u00e9rents comptes de service en fonction de la g\u00e9n\u00e9ration<\/a>\u00a0:<\/p>\n\n- Les fonctions Cloud\u00a0Run de premi\u00e8re g\u00e9n\u00e9ration utilisent le compte de service par d\u00e9faut d\u2019App\u00a0Engine (<project_id>@appspot.gserviceaccount.com<\/span> ).<\/li>\n
- Les fonctions Cloud\u00a0Run de deuxi\u00e8me g\u00e9n\u00e9ration utilisent le compte de service Compute par d\u00e9faut (<num\u00e9ro_de_projet>-compute@developer.gserviceaccount.com<\/span>).<\/li>\n<\/ul>\n
Ces comptes de service par d\u00e9faut disposent souvent d\u2019autorisations d\u2019\u00e9diteur lorsque les d\u00e9veloppeurs utilisent GCP sans rattachement organisationnel, ce qui leur permet de cr\u00e9er, de modifier et de supprimer des ressources au sein du projet. Toutefois, dans les projets relevant d\u2019une organisation GCP, les comptes de service par d\u00e9faut sont cr\u00e9\u00e9s sans aucune autorisation. Dans ce cas, ils ne peuvent effectuer que les actions explicitement autoris\u00e9es par les r\u00f4les qui leur sont attribu\u00e9s.<\/p>\n
Bien qu\u2019une fonction GCP fonctionne dans un environnement serverless, lorsqu\u2019il s\u2019agit d\u2019acc\u00e9der aux mat\u00e9riels d\u2019authentification associ\u00e9s \u00e0 la fonction, elle se comporte de la m\u00eame mani\u00e8re qu\u2019un serveur traditionnel, tel qu\u2019une instance de machine virtuelle (VM), en r\u00e9cup\u00e9rant ses jetons de compte de service \u00e0 partir du serveur de m\u00e9tadonn\u00e9es d\u2019instance (IMDS)<\/a> au moment de l\u2019ex\u00e9cution. L\u2019IMDS \u00e0 l\u2019adresse hxxp:\/\/metadata.google[.]internal\/<\/span> fournit des jetons d\u2019acc\u00e8s de courte dur\u00e9e pour le compte de service associ\u00e9 \u00e0 la fonction. Ces jetons permettent \u00e0 la fonction de s\u2019authentifier aupr\u00e8s des services GCP.<\/p>\n<\/a>Azure\u00a0Functions<\/strong><\/h3>\nLes identit\u00e9s g\u00e9r\u00e9es par Azure permettent aux ressources Azure de s\u2019authentifier et d\u2019interagir avec d\u2019autres services Azure de mani\u00e8re s\u00e9curis\u00e9e et transparente, sans qu\u2019il soit n\u00e9cessaire de coder des mat\u00e9riels d\u2019authentification en dur. \u00c0 l\u2019instar des services fonctionnels d\u2019AWS et de GCP, ces identit\u00e9s \u00e9liminent les risques li\u00e9s \u00e0 la gestion des mat\u00e9riels d\u2019authentification dans le code.<\/p>\n
Les identit\u00e9s manag\u00e9es attribu\u00e9es par le syst\u00e8me sont li\u00e9es \u00e0 une ressource unique et sont automatiquement supprim\u00e9es lors de la suppression de la ressource. D\u2019autre part, les identit\u00e9s manag\u00e9es attribu\u00e9es par l\u2019utilisateur sont des ressources ind\u00e9pendantes qui peuvent \u00eatre attribu\u00e9es \u00e0 plusieurs services, ce qui offre une plus grande souplesse pour les sc\u00e9narios d\u2019authentification partag\u00e9e.<\/p>\n
Une fonction Azure \u00e0 laquelle est associ\u00e9e une identit\u00e9 manag\u00e9e doit utiliser son jeton d\u2019identit\u00e9 manag\u00e9e pour s\u2019authentifier aupr\u00e8s d\u2019une ressource Azure. Ci-dessous la proc\u00e9dure d\u2019authentification d\u00e9taill\u00e9e:<\/p>\n
\n- La fonction interroge ses variables d\u2019environnement pour r\u00e9cup\u00e9rer les valeurs de IDENTITY_ENDPOINT<\/span> et IDENTITY_HEADER<\/span>.\n
\n- IDENTITY_ENDPOINT<\/span>\u00a0: Une variable d\u2019environnement<\/a> qui contient l\u2019adresse du terminal local de l\u2019identit\u00e9 manag\u00e9e fourni par Azure. Il s\u2019agit d\u2019une URL locale \u00e0 partir de laquelle une application peut demander des jetons.<\/li>\n
- IDENTITY_HEADER<\/span>\u00a0: Param\u00e8tre obligatoire lors de l\u2019interrogation du terminal local de l\u2019identit\u00e9 manag\u00e9e. Cet en-t\u00eate est utilis\u00e9 pour att\u00e9nuer les attaques SSRF.<\/li>\n<\/ul>\n<\/li>\n
- La fonction envoie une requ\u00eate HTTP GET au terminal local de l\u2019identit\u00e9 manag\u00e9e avec l\u2019en-t\u00eate IDENTITY_HEADER<\/span> inclus dans l\u2019en-t\u00eate HTTP. (Pour plus de d\u00e9tails sur la structure de la demande, voir la documentation d\u2019Azure sur l\u2019acquisition de jetons pour les App\u00a0Services<\/a>)<\/li>\n
- Microsoft\u00a0Entra\u00a0ID<\/a> (anciennement Azure\u00a0Active\u00a0Directory) v\u00e9rifie l\u2019identit\u00e9 de la fonction et \u00e9met un jeton OAuth\u00a02.0 temporaire qui est limit\u00e9 sp\u00e9cifiquement \u00e0 la ressource cible.<\/li>\n
- La fonction inclut le jeton \u00e9mis dans sa demande \u00e0 la ressource Azure (par exemple, Azure\u00a0Key\u00a0Vault<\/a>, compte de stockage<\/a>).<\/li>\n
- La ressource Azure valide le jeton et v\u00e9rifie les autorisations de la fonction \u00e0 l\u2019aide du contr\u00f4le d\u2019acc\u00e8s bas\u00e9 sur les r\u00f4les<\/a> ou des politiques d\u2019acc\u00e8s sp\u00e9cifiques aux ressources<\/a>.<\/li>\n<\/ul>\n
Si elle est autoris\u00e9e, la ressource accorde l\u2019acc\u00e8s pour effectuer l\u2019op\u00e9ration demand\u00e9e. Cela garantit une authentification s\u00fbre et transparente sans qu\u2019il soit n\u00e9cessaire d\u2019utiliser des secrets cod\u00e9s en dur dans le code.<\/p>\n
<\/a>Vecteurs d\u2019attaque pour l\u2019exfiltration de jetons<\/h2>\nCette section aborde les risques et les menaces li\u00e9s \u00e0 l\u2019utilisation de fonctions serverless. Lorsqu\u2019ils d\u00e9veloppent et configurent des fonctions, les d\u00e9veloppeurs d\u2019applications doivent veiller \u00e0 s\u00e9curiser ces fonctions contre des attaques telles que SSRF et RCE. En l\u2019absence d\u2019une telle s\u00e9curit\u00e9, les attaquants pourraient manipuler les fonctions serverless qui sont vuln\u00e9rables au SSRF, ce qui am\u00e8nerait les fonctions \u00e0 envoyer des requ\u00eates non autoris\u00e9es aux services internes. Cela peut conduire \u00e0 un acc\u00e8s involontaire ou \u00e0 l\u2019exposition d\u2019informations sensibles au sein du syst\u00e8me, telles que les jetons d\u2019acc\u00e8s, le contenu de la base de donn\u00e9es interne ou les configurations de service. Il est important de souligner que ces risques surviennent principalement lorsque les fonctions sont publiques ou qu\u2019elles traitent des donn\u00e9es provenant d\u2019utilisateurs externes et d\u2019autres sources.<\/p>\n
Dans les attaques SSRF, un attaquant trompe un serveur (comme une fonction serverless) en effectuant des requ\u00eates HTTP vers des ressources internes ou externes auxquelles l\u2019attaquant ne devrait pas avoir acc\u00e8s. Comme c\u2019est le serveur lui-m\u00eame qui fait la demande, il peut acc\u00e9der \u00e0 des services internes qui ne sont pas expos\u00e9s \u00e0 Internet. Une fonction serverlessr vuln\u00e9rable prend une URL en entr\u00e9e et r\u00e9cup\u00e8re les donn\u00e9es \u00e0 partir de celle-ci.<\/p>\n
Dans GCP, SSRF peut \u00eatre utilis\u00e9 pour acc\u00e9der \u00e0 l\u2019IMDS \u00e0 l\u2019adresse hxxp:\/\/metadata.google[.]internal\/<\/span>, en extrayant des jetons temporaires de compte de service. Un attaquant peut alors utiliser ces jetons pour se faire passer pour la fonction et effectuer des actions non autoris\u00e9es dans le cadre des autorisations de son r\u00f4le IAM. Les vuln\u00e9rabilit\u00e9s li\u00e9es \u00e0 l\u2019ex\u00e9cution de code \u00e0 distance permettent aux attaquants d\u2019ex\u00e9cuter du code arbitraire dans l\u2019environnement d\u2019une fonction.<\/p>\nPour AWS\u00a0Lambda, les attaques RCE pourraient exposer des mat\u00e9riels d\u2019authentification temporaires stock\u00e9es dans des variables d\u2019environnement, telles que AWS_ACCESS_KEY_ID<\/span> et AWS_SESSION_TOKEN<\/span>.<\/p>\nIl est essentiel de noter que ces vecteurs d\u2019attaque ne sont pas des failles inh\u00e9rentes aux plateformes cloud elles-m\u00eames, mais d\u00e9coulent plut\u00f4t d\u2019un d\u00e9veloppement non s\u00e9curis\u00e9 r\u00e9dig\u00e9 par les d\u00e9veloppeurs d\u2019applications qui pourrait introduire des vuln\u00e9rabilit\u00e9s, telles que SSRF ou RCE. Les d\u00e9veloppeurs d\u2019applications peuvent att\u00e9nuer ces risques en mettant en \u0153uvre des pratiques de d\u00e9veloppement s\u00e9curis\u00e9 telles que la validation des entr\u00e9es.<\/p>\n
<\/a>Simulations de vecteurs d\u2019attaque<\/strong><\/h3>\nLes simulations suivantes montrent comment les attaquants pourraient extraire les jetons serverless et les utiliser pour des activit\u00e9s malveillantes dans diff\u00e9rents fournisseurs de services cloud (CSP). Ces attaques pourraient tirer parti d\u2019un code de fonction non s\u00e9curis\u00e9 d\u00e9ploy\u00e9 par les d\u00e9veloppeurs d\u2019applications.<\/p>\n
<\/a>Simulation\u00a01\u00a0: Acc\u00e8s direct \u00e0 l\u2019IMDS \u00e0 partir d\u2019une fonction BPC<\/h4>\nPour r\u00e9aliser cette simulation, nous avons d\u00e9ploy\u00e9 deux fonctions Google\u00a0Cloud\u00a0Run qui acc\u00e8dent au service de m\u00e9tadonn\u00e9es des fonctions et extraient les jetons des deux diff\u00e9rents comptes de service associ\u00e9s \u00e0 partir du chemin suivant\u00a0:<\/p>\n
\n- hxxp[:\/\/]metadata.google[.]internal\/computeMetadata\/v1\/instance\/service-accounts\/default\/token<\/span><\/li>\n<\/ul>\n
Le premier exemple illustre l\u2019extraction d\u2019un compte de service par d\u00e9faut. Le deuxi\u00e8me exemple illustre l\u2019extraction d\u2019un compte de service personnalis\u00e9. Ces exemples montrent comment le code peut acc\u00e9der directement au service de m\u00e9tadonn\u00e9es, tout comme une application vuln\u00e9rable \u00e0 une attaque SSRF pourrait \u00e9galement y acc\u00e9der.<\/p>\n
<\/a>Exemple\u00a01\u00a0: Extraction d\u2019un compte de service par d\u00e9faut dans GCP<\/strong><\/h5>\nComme le montre la figure\u00a01, le compte de service associ\u00e9 \u00e0 la fonction \u00e9tait le compte de service serverless par d\u00e9faut. La figure\u00a02 montre que le jeton d\u2019acc\u00e8s renvoy\u00e9 appartient au m\u00eame compte de service.<\/p>\n![\"Capture]()
Figure 1. Informations g\u00e9n\u00e9rales sur la fonction, y compris le nom de compte de service associ\u00e9 (le compte de service par d\u00e9faut).<\/figcaption><\/figure>\n![\"Capture]()
Figure 2. Commande utilis\u00e9e pour extraire le jeton d\u2019acc\u00e8s au compte de service, y compris le r\u00e9sultat.<\/figcaption><\/figure>\n<\/a>Exemple\u00a02\u00a0: Extraction d\u2019un compte de service personnalis\u00e9 dans GCP<\/strong><\/h5>\nLa figure\u00a03 montre le compte de service personnalis\u00e9 que nous avons associ\u00e9 \u00e0 la fonction. La figure\u00a04 montre le jeton d\u2019acc\u00e8s renvoy\u00e9 appartenant au compte de service personnalis\u00e9. Nous avons ensuite utilis\u00e9 le jeton renvoy\u00e9 pour effectuer des op\u00e9rations dans l\u2019environnement.<\/p>\n![\"Capture]()
Figure 3. Informations g\u00e9n\u00e9rales sur la fonction, y compris le nom du compte de service associ\u00e9 (un compte de service personnalis\u00e9).<\/figcaption><\/figure>\n![\"Capture]()
Figure 4. Commande utilis\u00e9e pour extraire le jeton d\u2019acc\u00e8s au compte de service, y compris le r\u00e9sultat.<\/figcaption><\/figure>\nLa figure\u00a05 ci-dessous montre un exemple de commande permettant de lister les buckets.<\/p>\n![\"Capture]()
Figure 5. Utilisation du jeton renvoy\u00e9 pour lister les buckets du compte de service.<\/figcaption><\/figure>\nSi des attaquants peuvent r\u00e9pertorier et lire le contenu des buckets dans GCP, ils peuvent acc\u00e9der \u00e0 des fichiers sensibles tels que des mat\u00e9riels d\u2019authentification, des sauvegardes ou des configurations internes. Cela leur permet de voler des donn\u00e9es, de compromettre le syst\u00e8me ou de se d\u00e9placer lat\u00e9ralement au sein de l\u2019environnement.<\/p>\n
Une fois que les attaquants obtiennent un jeton d\u2019acc\u00e8s pour un compte de service avec des autorisations d\u2019\u00e9diteur dans GCP (comme le compte de service Compute\u00a0Engine par d\u00e9faut), ils peuvent modifier, supprimer ou cr\u00e9er des ressources dans la plupart des services. Il peut s\u2019agir d\u2019acc\u00e9der \u00e0 des donn\u00e9es sensibles, de d\u00e9ployer des workloads malveillants, d\u2019escalader des privil\u00e8ges ou de perturber des services. L\u2019acc\u00e8s de l\u2019\u00e9diteur permet un contr\u00f4le quasi total du projet.<\/p>\n
<\/a>Simulation\u00a02\u00a0: Utilisation de RCE pour r\u00e9cup\u00e9rer les jetons stock\u00e9s dans les variables d\u2019environnement de la fonction AWS\u00a0Lambda<\/h4>\nDans cette simulation, nous avons acc\u00e9d\u00e9 aux variables d\u2019environnement de la fonction Lambda et en avons extrait l\u2019AWS_ACCESS_KEY_ID<\/span>, l\u2019AWS_SECRET_ACCESS_KEY<\/span> et l\u2019AWS_SESSION_TOKEN<\/span>.<\/p>\nLa figure\u00a06 montre la sortie du code de la fonction Lambda.<\/p>\n![\"Capture]()
Figure 6. Valeurs des variables d\u2019environnement renvoy\u00e9es.<\/figcaption><\/figure>\nLa figure\u00a07 montre la configuration des identifiants AWS temporaires obtenus \u00e0 l\u2019\u00e9tape pr\u00e9c\u00e9dente (les variables d\u2019environnement Lambda).<\/p>\n![\"\u00c9cran]()
Figure\u00a07. Extrait de code des commandes utilis\u00e9es pour lister les buckets\u00a0S3.<\/figcaption><\/figure>\nNous avons ensuite utilis\u00e9 la commande suivante pour dresser la liste de tous les buckets\u00a0S3 auxquels la session authentifi\u00e9e peut acc\u00e9der.<\/p>\n
aws s3 ls<\/pre>\n<\/a>Simulation\u00a03\u00a0: Utilisation de RCE pour r\u00e9cup\u00e9rer des jetons \u00e0 partir d\u2019un terminal d\u2019identit\u00e9 local d\u2019une fonction Azure<\/h4>\nDans cette simulation, nous avons acc\u00e9d\u00e9 aux variables d\u2019environnement de la fonction Azure et extrait l\u2019IDENTITY_ENDPOINT et l\u2019IDENTITY_HEADER en ex\u00e9cutant des commandes \u00e0 distance. Nous avons ensuite extrait le jeton d\u2019identit\u00e9 manag\u00e9e via le terminal d\u2019identit\u00e9 local, en fournissant les param\u00e8tres indiqu\u00e9s ci-dessous dans la figure\u00a08\u00a0:<\/p>\n
\n- Ressource<\/li>\n
- version de l\u2019API<\/span><\/li>\n
- X-IDENTITY-HEADER<\/span><\/li>\n<\/ul>\n
![\"Capture]()
Figure 8. La sortie du script, y compris le jeton d\u2019acc\u00e8s.<\/figcaption><\/figure>\n<\/a>D\u00e9tection et pr\u00e9vention de l\u2019exfiltration de jetons<\/h2>\n<\/a>D\u00e9tection de l\u2019exfiltration de jetons dans les environnements sans serveur<\/strong><\/h3>\nDes m\u00e9canismes de d\u00e9tection efficaces sont essentiels pour identifier l\u2019exfiltration de jetons dans les environnements sans serveur. Ces m\u00e9canismes se concentrent sur les anomalies de comportement pour signaler les activit\u00e9s non autoris\u00e9es. Voici quelques-unes des principales strat\u00e9gies de d\u00e9tection mises en \u0153uvre sur les principales plateformes cloud.<\/p>\n
La d\u00e9tection se fait en deux \u00e9tapes\u00a0:<\/p>\n
\n- Valider que l\u2019identit\u00e9 est associ\u00e9e \u00e0 une fonction serverless.<\/li>\n
- Identifier les comportements anormaux des identit\u00e9s sans serveur. Ces comportements peuvent inclure\u00a0:\n
\n- Les adresses IP source qui ne correspondent pas au contexte dans lequel la fonction est ex\u00e9cut\u00e9e, telles que les adresses provenant de num\u00e9ros de syst\u00e8mes autonomes (ASN) qui ne sont pas associ\u00e9s \u00e0 un fournisseur de services cloud.<\/li>\n
- Les identit\u00e9s serverless effectuant des requ\u00eates avec des user-agents suspects.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
<\/a>\u00c9tape\u00a01\u00a0: Identifier les identit\u00e9s serverless<\/h4>\nPour identifier les comptes de service associ\u00e9s aux fonctions sans serveur dans GCP, nous analysons la section serviceAccountDelegationInfo<\/span> dans les journaux. Ces informations fournissent des indications cruciales sur la cha\u00eene de d\u00e9l\u00e9gation des comptes de service. Plus pr\u00e9cis\u00e9ment, lorsqu\u2019un compte de service est associ\u00e9 \u00e0 une fonction, il d\u00e9l\u00e8gue son autorit\u00e9 \u00e0 un compte de service sans serveur par d\u00e9faut\u00a0:<\/p>\n\n- Google\u00a0Cloud\u00a0Run\u00a0Service\u00a0Agent (service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>)<\/li>\n
- gcf-admin-robot.iam.gserviceaccount[.]com<\/span> (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com<\/span>)<\/li>\n<\/ul>\n
Ces comptes de service ex\u00e9cutent des t\u00e2ches au nom de la fonction.<\/p>\n
Par exemple, dans l\u2019entr\u00e9e de journal de la figure\u00a09, nous voyons le compte de service personnalis\u00e9 associ\u00e9 \u00e0 une fonction (sa-test@<project-id>.iam.gserviceaccount[.]com<\/span>) d\u00e9l\u00e9guer son autorit\u00e9 \u00e0 l\u2019agent de service Cloud\u00a0Run.<\/p>\n![\"Capture]()
Figure 9. Entr\u00e9e de journal montrant un compte de service personnalis\u00e9.<\/figcaption><\/figure>\nDans la figure\u00a09 ci-dessus, le champ principalEmail<\/span> sous authenticationInfo<\/span> sp\u00e9cifie le compte de service utilis\u00e9 (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com<\/span>).<\/p>\nLe serviceAccountDelegationInfo indique<\/span> le principal de premi\u00e8re partie (dans ce cas\u00a0: service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>), ce qui indique que le compte de service fonctionne dans un environnement sans serveur comme Cloud\u00a0Functions ou Cloud\u00a0Run.<\/p>\nUne approche efficace pour d\u00e9couvrir les identit\u00e9s serverless consiste \u00e0 \u00e9tablir le profil des comptes de service qui ont pr\u00e9c\u00e9demment d\u00e9l\u00e9gu\u00e9 leur autorit\u00e9 \u00e0 des comptes de service sans serveur par d\u00e9faut. Cela garantit que m\u00eame si des comptes de service autres que ceux par d\u00e9faut sont associ\u00e9s \u00e0 des fonctions, ils sont identifi\u00e9s.<\/p>\n
Dans AWS, les fonctions Lambda s\u2019appuient sur les r\u00f4les IAM pour s\u00e9curiser l\u2019acc\u00e8s aux services AWS. Ces r\u00f4les g\u00e9n\u00e8rent des mat\u00e9riels d\u2019authentification temporaires. Nous pouvons identifier l\u2019identit\u00e9 Lambda par son nom de r\u00f4le.<\/p>\n
Dans Azure, les identit\u00e9s manag\u00e9es associ\u00e9es aux Azure\u00a0Function\u00a0Apps sont utilis\u00e9es pour l\u2019authentification.<\/p>\n
<\/a>\u00c9tape\u00a02\u00a0: Identifier les comportements inhabituels pour les identit\u00e9s serverless<\/h4>\nDans un environnement cloud s\u00e9curis\u00e9, les fonctions serverless sont g\u00e9n\u00e9ralement destin\u00e9es \u00e0 ex\u00e9cuter des t\u00e2ches automatis\u00e9es et circonscrites, telles que la r\u00e9ponse \u00e0 des requ\u00eates API ou le traitement d\u2019\u00e9v\u00e9nements. Ces fonctions ne doivent pas \u00eatre utilis\u00e9es de mani\u00e8re interactive. Cependant, si des attaquants obtiennent l\u2019acc\u00e8s \u00e0 l\u2019environnement d\u2019une fonction sans serveur ou \u00e0 son identit\u00e9, ils peuvent l\u2019utiliser \u00e0 mauvais escient pour ex\u00e9cuter des commandes d\u2019interface de ligne de commande (CLI) (par exemple, gcloud<\/span> CLI<\/span> ou curl<\/span>) afin d\u2019interagir directement avec les ressources du cloud.<\/p>\nUne m\u00e9thode de d\u00e9tection consiste \u00e0 examiner le user-agent des appels API. Si l\u2019agent utilisateur correspond \u00e0 des outils CLI connus (par exemple, gcloud CLI<\/span>) ou \u00e0 des cadres de test d\u2019intrusion, il est signal\u00e9 comme suspect, car les CLI ne devraient g\u00e9n\u00e9ralement pas \u00eatre utilis\u00e9es par les identit\u00e9s serverless. Cela indique une exploitation potentielle de l\u2019environnement ou des jetons de compte de service.<\/p>\n\u00c0 noter que cette m\u00e9thode d\u2019identification de l\u2019utilisation \u00e0 distance des jetons sans serveur en fonction de l\u2019agent utilisateur ne peut pas \u00eatre r\u00e9alis\u00e9e dans Azure, car les informations relatives au user-agent n\u2019apparaissent pas dans les journaux Azure.<\/p>\n
Une autre approche pour d\u00e9tecter l\u2019utilisation \u00e0 distance d\u2019un jeton d\u2019identit\u00e9 sans serveur consiste \u00e0 corr\u00e9ler l\u2019emplacement de l\u2019utilisation d\u2019un jeton avec des plages ASN d\u2019adresses IP de fournisseurs de cloud connus. Si une demande provient d\u2019une adresse IP externe non associ\u00e9e au CSP, une alerte est d\u00e9clench\u00e9e, mettant en \u00e9vidence une \u00e9ventuelle utilisation non autoris\u00e9e du jeton en dehors de l\u2019environnement cloud.<\/p>\n
<\/a>Strat\u00e9gies de pr\u00e9vention<\/h3>\nLa s\u00e9curisation des jetons serverless n\u00e9cessite une combinaison de mesures proactives, de gestion de la posture et de pratiques de s\u00e9curit\u00e9 de surveillance de l\u2019ex\u00e9cution pour minimiser le risque d\u2019exploitation. Tout d\u2019abord, mettez en \u0153uvre le principe du moindre privil\u00e8ge en attribuant des r\u00f4les avec les autorisations minimales requises pour les fonctions sans serveur. Cela r\u00e9duit l\u2019impact potentiel d\u2019une mauvaise utilisation des jetons.<\/p>\n
En outre, pour prot\u00e9ger les environnements d\u2019ex\u00e9cution sans serveur dans GCP et Azure, restreignez l\u2019acc\u00e8s \u00e0 l\u2019IMDS en configurant des contr\u00f4les au niveau du r\u00e9seau et en appliquant des m\u00e9canismes de validation des demandes. Assurer une validation robuste des entr\u00e9es pour emp\u00eacher les attaquants d\u2019utiliser des techniques d\u2019exploitation comme le SSRF pour acc\u00e9der aux m\u00e9tadonn\u00e9es sensibles, aux jetons et \u00e0 d\u2019autres ressources cloud comme les API et les bases de donn\u00e9es.<\/p>\n
<\/a>Conclusion<\/h2>\nL\u2019informatique serverless est le choix privil\u00e9gi\u00e9 pour le d\u00e9veloppement d\u2019applications modernes, car elle offre des avantages significatifs en termes d\u2019\u00e9volutivit\u00e9, de rentabilit\u00e9 et de gestion simplifi\u00e9e de l\u2019infrastructure.<\/p>\n
Les mat\u00e9riels d'authentification permettant \u00e0 ces fonctions d\u2019interagir avec les services cloud constituent un \u00e9l\u00e9ment de s\u00e9curit\u00e9 essentiel et une cible de choix pour les attaquants. La compromission de ces mat\u00e9riels d\u2019authentification peut avoir de graves cons\u00e9quences, notamment l\u2019acc\u00e8s non autoris\u00e9 \u00e0 des ressources cloud et l\u2019exfiltration de donn\u00e9es.<\/p>\n
La mise en \u0153uvre d\u2019une gestion proactive de la posture et de protections de surveillance de l\u2019ex\u00e9cution est une strat\u00e9gie cruciale pour la protection des environnements cloud.<\/p>\n
Les organisations peuvent mieux prot\u00e9ger leurs environnements sans serveur en\u00a0:<\/p>\n
\n- Comprenant les m\u00e9canismes des r\u00e9f\u00e9rences serverless et les meilleures pratiques pour les provisionner et les g\u00e9rer dans AWS, Azure et GCP<\/a><\/li>\n
- Reconnaissant les vecteurs d\u2019attaque courants tels que l\u2019exfiltration de jetons via l\u2019exploitation de l\u2019IMDS ou l\u2019acc\u00e8s aux variables d\u2019environnement<\/li>\n<\/ul>\n
<\/a>Protection et mitigation des risques par Palo\u00a0Alto\u00a0Networks<\/h2>\nLes clients de Palo\u00a0Alto\u00a0Networks sont mieux prot\u00e9g\u00e9s contre les menaces mentionn\u00e9es ci-dessus gr\u00e2ce aux produits suivants\u00a0:<\/p>\n
Si vous pensez que votre entreprise a pu \u00eatre compromise ou si vous faites face \u00e0 une urgence, contactez l\u2019\u00e9quipe Unit\u00a042 de r\u00e9ponse aux incidents<\/a> ou composez l\u2019un des num\u00e9ros suivants\u00a0:<\/p>\n\n- Am\u00e9rique du Nord Par t\u00e9l\u00e9phone\u00a0: 866.486.4842 (866.4.UNIT42)<\/li>\n
- EMEA\u00a0: +31\u00a020\u00a0299\u00a03130<\/li>\n
- APAC\u00a0: +65\u00a06983\u00a08730<\/li>\n
- Japon\u00a0: +81\u00a050\u00a01790\u00a00200<\/li>\n<\/ul>\n
Palo\u00a0Alto\u00a0Networks a partag\u00e9 ces conclusions avec les autres membres de la Cyber\u00a0Threat\u00a0Alliance (CTA). Les membres de la CTA s\u2019appuient sur ces renseignements pour d\u00e9ployer rapidement des mesures de protection aupr\u00e8s de leurs clients et perturber de mani\u00e8re coordonn\u00e9e les activit\u00e9s des cybercriminels. Cliquez ici pour en savoir plus sur la Cyber Threat Alliance.<\/a><\/p>\n<\/a>Pour aller plus loin<\/h2>\n\n- Utilisation des variables d\u2019environnement Lambda<\/a> - Guide du d\u00e9veloppeur AWS\u00a0Lambda<\/li>\n
- S\u00e9curisation de variables d\u2019environnement Lambda<\/a> - Guide du d\u00e9veloppeur AWS\u00a0Lambda<\/li>\n
- Gestion des autorisations dans AWS\u00a0Lambda<\/a> - Guide du d\u00e9veloppeur AWS\u00a0Lambda<\/li>\n
- Identit\u00e9 de fonction<\/a> - Google\u00a0Cloud<\/li>\n
- Que sont les identit\u00e9s manag\u00e9es pour les ressources Azure\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- S\u00e9curisation d\u2019Azure\u00a0Functions<\/a> - Microsoft\u00a0Learn<\/li>\n
- Qu\u2019est-ce que c\u2019est, AWS\u00a0Secrets\u00a0Manager\u00a0?<\/a> - Guide de l\u2019utilisateur AWS\u00a0Secret\u00a0Manager<\/li>\n
- Concepts de base d\u2019Azure\u00a0Key\u00a0Vault<\/a> - Microsoft\u00a0Learn<\/li>\n
- Pr\u00e9sentation de Secret\u00a0Manager<\/a> - Documentation de Google\u00a0Cloud Secret\u00a0Manager<\/li>\n
- Qu\u2019est-ce que la gestion des identit\u00e9s et des acc\u00e8s (IAM)\u00a0?<\/a> - Microsoft\u00a0Security<\/li>\n
- Que sont les identit\u00e9s manag\u00e9es pour les ressources Azure\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- Contr\u00f4le des identit\u00e9s et des acc\u00e8s<\/a> - Introduction \u00e0 la s\u00e9curit\u00e9 AWS - Livre blanc AWS<\/li>\n
- Identifiants du compte de service<\/a> - Documentation Google\u00a0Cloud\u00a0IAM<\/li>\n
- Identifiants de s\u00e9curit\u00e9 temporaires dans IAM<\/a> - Guide de l\u2019utilisateur de AWS\u00a0Identity et Access\u00a0Management<\/li>\n
- R\u00e9f\u00e9rence API du service de jetons de s\u00e9curit\u00e9 AWS<\/a> - Documentation du service de jetons de s\u00e9curit\u00e9 AWS<\/li>\n
- Instances Compute\u00a0Engine<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- Projets Google\u00a0Cloud<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- Comptes de service g\u00e9r\u00e9s par l\u2019utilisateur<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- Comparer les fonctions Cloud\u00a0Run<\/a> - Documentation Google\u00a0Cloud\u00a0Run<\/li>\n
- Comptes de service par d\u00e9faut<\/a> - Documentation Google\u00a0Cloud<\/li>\n
- R\u00e9f\u00e9rence du terminal REST<\/a> - Identit\u00e9s manag\u00e9es pour App\u00a0Service et Azure\u00a0Functions<\/li>\n
- Variables d\u2019environnement et param\u00e8tres d\u2019application dans Azure\u00a0App\u00a0Service<\/a> - Microsoft\u00a0Learn<\/li>\n
- Guide pratique de l\u2019utilisation d\u2019identit\u00e9s manag\u00e9es pour ressources Azure sur une machine virtuelle Azure afin d\u2019acqu\u00e9rir un jeton d\u2019acc\u00e8s<\/a> - Microsoft\u00a0Learn<\/li>\n
- Qu\u2019est-ce que l\u2019identifiant Microsoft\u00a0Entra\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- \u00c0 propos d\u2019Azure\u00a0Key\u00a0Vault<\/a> - Microsoft\u00a0Learn<\/li>\n
- Autoriser l\u2019acc\u00e8s aux objets blobs \u00e0 l\u2019aide de l\u2019identifiant Microsoft\u00a0Entra<\/a> - Microsoft\u00a0Learn<\/li>\n
- Pr\u00e9sentation du compte de stockage<\/a> - Microsoft\u00a0Learn<\/li>\n
- Qu\u2019est-ce que le contr\u00f4le d\u2019acc\u00e8s en fonction du r\u00f4le Azure (RBAC Azure)\u00a0?<\/a> - Microsoft\u00a0Learn<\/li>\n
- Politiques d\u2019acc\u00e8s sp\u00e9cifiques aux ressources<\/a> - Microsoft\u00a0Learn<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.<\/p>\n","protected":false},"author":366,"featured_media":143160,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[8724,8832],"tags":[9293,9341,9342,9228],"product_categories":[9041,9046,9151],"coauthors":[4194],"class_list":["post-146708","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-cybersecurity-research-fr","category-threat-research-fr","tag-aws-fr","tag-google-cloud-fr","tag-microsoft-azure-fr","tag-serverless-fr","product_categories-cortex-fr","product_categories-cortex-cloud-fr","product_categories-unit-42-incident-response-fr"],"yoast_head":"\n
Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection<\/title>\n<meta name=\"description\" content=\"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection\" \/>\n<meta property=\"og:description\" content=\"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:site_name\" content=\"Unit 42\" \/>\n<meta property=\"article:published_time\" content=\"2025-06-13T16:31:03+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-07-14T17:31:16+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"900\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Zohar Zigdon\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","description":"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","og_locale":"fr_FR","og_type":"article","og_title":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","og_description":"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.","og_url":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","og_site_name":"Unit 42","article_published_time":"2025-06-13T16:31:03+00:00","article_modified_time":"2025-07-14T17:31:16+00:00","og_image":[{"width":1920,"height":900,"url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","type":"image\/jpeg"}],"author":"Zohar Zigdon","twitter_card":"summary_large_image","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#article","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/"},"author":{"name":"Sheida Azimi","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"headline":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","datePublished":"2025-06-13T16:31:03+00:00","dateModified":"2025-07-14T17:31:16+00:00","mainEntityOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/"},"wordCount":5063,"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","keywords":["AWS","Google Cloud","Microsoft Azure","serverless"],"articleSection":["\u00c9tudes sur la cybers\u00e9curit\u00e9 du cloud","Recherche sur les menaces"],"inLanguage":"fr-FR"},{"@type":"WebPage","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","url":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/","name":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage"},"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","datePublished":"2025-06-13T16:31:03+00:00","dateModified":"2025-07-14T17:31:16+00:00","author":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"description":"Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications. Comprendre les m\u00e9canismes de l\u2019authentification serverless : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.","breadcrumb":{"@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/"]}]},{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#primaryimage","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","width":1920,"height":900,"caption":"Pictorial representation of serverless tokens in the cloud. East Asian woman examining data on multiple screens in a high-tech environment, surrounded by digital graphics and code."},{"@type":"BreadcrumbList","@id":"https:\/\/unit42.paloaltonetworks.com\/fr\/serverless-authentication-cloud\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/unit42.paloaltonetworks.com\/"},{"@type":"ListItem","position":2,"name":"Jetons sans serveur dans le cloud\u00a0: Exploitation et d\u00e9tection"}]},{"@type":"WebSite","@id":"https:\/\/unit42.paloaltonetworks.com\/#website","url":"https:\/\/unit42.paloaltonetworks.com\/","name":"Unit 42","description":"Palo Alto Networks","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/unit42.paloaltonetworks.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Person","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639","name":"Sheida Azimi","image":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/image\/4ffb3c2d260a0150fb91b3715442f8b3","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","caption":"Sheida Azimi"},"url":"https:\/\/unit42.paloaltonetworks.com\/fr\/author\/sheida-azimi\/"}]}},"_links":{"self":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts\/146708","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/users\/366"}],"replies":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/comments?post=146708"}],"version-history":[{"count":3,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts\/146708\/revisions"}],"predecessor-version":[{"id":146811,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/posts\/146708\/revisions\/146811"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/media\/143160"}],"wp:attachment":[{"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/media?parent=146708"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/categories?post=146708"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/tags?post=146708"},{"taxonomy":"product_categories","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/product_categories?post=146708"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/fr\/wp-json\/wp\/v2\/coauthors?post=146708"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Il s\u2019agit d\u2019un moyen s\u00fbr d\u2019acc\u00e9der aux mat\u00e9riels d\u2019authentification au moment de l\u2019ex\u00e9cution, sans les risques associ\u00e9s aux mat\u00e9riels d\u2019authentification cod\u00e9s en dur \u00e0 long terme.<\/p>\n
Ces mat\u00e9riels d\u2019authentification sont limit\u00e9s aux autorisations d\u00e9finies dans la politique d\u2019acc\u00e8s associ\u00e9e au r\u00f4le. Il s\u2019agit d\u2019un identifiant de cl\u00e9 d\u2019acc\u00e8s, d\u2019une cl\u00e9 d\u2019acc\u00e8s secr\u00e8te et d\u2019un jeton de session.<\/p>\n
Au moment de l\u2019ex\u00e9cution, le service d\u2019ex\u00e9cution Lambda charge les mat\u00e9riels d\u2019authentification du r\u00f4le dans l\u2019environnement d\u2019ex\u00e9cution de la fonction et les stocke en tant que variables d\u2019environnement, telles que AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY<\/span> et AWS_SESSION_TOKEN<\/span>. Ces variables sont accessibles au code de la fonction pendant l\u2019ex\u00e9cution, ce qui permet \u00e0 la fonction d\u2019interagir en toute s\u00e9curit\u00e9 avec d\u2019autres services AWS.<\/p>\n Google\u00a0Cloud\u00a0Functions utilise des jetons de compte de service pour authentifier et autoriser l\u2019acc\u00e8s \u00e0 d\u2019autres services Google\u00a0Cloud. Un compte de service est un compte Google sp\u00e9cialis\u00e9 li\u00e9 \u00e0 un projet<\/a> et repr\u00e9sente une identit\u00e9 non humaine, plut\u00f4t qu\u2019un utilisateur individuel.<\/p>\n Lors du d\u00e9ploiement d\u2019une fonction cloud, les d\u00e9veloppeurs peuvent l\u2019associer \u00e0 un compte de service personnalis\u00e9 ou au compte de service par d\u00e9faut<\/a>. Lorsqu\u2019ils utilisent un compte de service personnalis\u00e9, les d\u00e9veloppeurs peuvent attribuer des r\u00f4les IAM sp\u00e9cifiques afin de d\u00e9finir les autorisations exactes dont la fonction a besoin pour accomplir ses t\u00e2ches.<\/p>\n Les comptes de service par d\u00e9faut sont des comptes g\u00e9r\u00e9s par l\u2019utilisateur<\/a> que Google\u00a0Cloud cr\u00e9e automatiquement lorsque les utilisateurs activent des services sp\u00e9cifiques. Par d\u00e9faut, Google\u00a0Cloud\u00a0Functions utilise diff\u00e9rents comptes de service en fonction de la g\u00e9n\u00e9ration<\/a>\u00a0:<\/p>\n Ces comptes de service par d\u00e9faut disposent souvent d\u2019autorisations d\u2019\u00e9diteur lorsque les d\u00e9veloppeurs utilisent GCP sans rattachement organisationnel, ce qui leur permet de cr\u00e9er, de modifier et de supprimer des ressources au sein du projet. Toutefois, dans les projets relevant d\u2019une organisation GCP, les comptes de service par d\u00e9faut sont cr\u00e9\u00e9s sans aucune autorisation. Dans ce cas, ils ne peuvent effectuer que les actions explicitement autoris\u00e9es par les r\u00f4les qui leur sont attribu\u00e9s.<\/p>\n Bien qu\u2019une fonction GCP fonctionne dans un environnement serverless, lorsqu\u2019il s\u2019agit d\u2019acc\u00e9der aux mat\u00e9riels d\u2019authentification associ\u00e9s \u00e0 la fonction, elle se comporte de la m\u00eame mani\u00e8re qu\u2019un serveur traditionnel, tel qu\u2019une instance de machine virtuelle (VM), en r\u00e9cup\u00e9rant ses jetons de compte de service \u00e0 partir du serveur de m\u00e9tadonn\u00e9es d\u2019instance (IMDS)<\/a> au moment de l\u2019ex\u00e9cution. L\u2019IMDS \u00e0 l\u2019adresse hxxp:\/\/metadata.google[.]internal\/<\/span> fournit des jetons d\u2019acc\u00e8s de courte dur\u00e9e pour le compte de service associ\u00e9 \u00e0 la fonction. Ces jetons permettent \u00e0 la fonction de s\u2019authentifier aupr\u00e8s des services GCP.<\/p>\n Les identit\u00e9s g\u00e9r\u00e9es par Azure permettent aux ressources Azure de s\u2019authentifier et d\u2019interagir avec d\u2019autres services Azure de mani\u00e8re s\u00e9curis\u00e9e et transparente, sans qu\u2019il soit n\u00e9cessaire de coder des mat\u00e9riels d\u2019authentification en dur. \u00c0 l\u2019instar des services fonctionnels d\u2019AWS et de GCP, ces identit\u00e9s \u00e9liminent les risques li\u00e9s \u00e0 la gestion des mat\u00e9riels d\u2019authentification dans le code.<\/p>\n Les identit\u00e9s manag\u00e9es attribu\u00e9es par le syst\u00e8me sont li\u00e9es \u00e0 une ressource unique et sont automatiquement supprim\u00e9es lors de la suppression de la ressource. D\u2019autre part, les identit\u00e9s manag\u00e9es attribu\u00e9es par l\u2019utilisateur sont des ressources ind\u00e9pendantes qui peuvent \u00eatre attribu\u00e9es \u00e0 plusieurs services, ce qui offre une plus grande souplesse pour les sc\u00e9narios d\u2019authentification partag\u00e9e.<\/p>\n Une fonction Azure \u00e0 laquelle est associ\u00e9e une identit\u00e9 manag\u00e9e doit utiliser son jeton d\u2019identit\u00e9 manag\u00e9e pour s\u2019authentifier aupr\u00e8s d\u2019une ressource Azure. Ci-dessous la proc\u00e9dure d\u2019authentification d\u00e9taill\u00e9e:<\/p>\n Si elle est autoris\u00e9e, la ressource accorde l\u2019acc\u00e8s pour effectuer l\u2019op\u00e9ration demand\u00e9e. Cela garantit une authentification s\u00fbre et transparente sans qu\u2019il soit n\u00e9cessaire d\u2019utiliser des secrets cod\u00e9s en dur dans le code.<\/p>\n Cette section aborde les risques et les menaces li\u00e9s \u00e0 l\u2019utilisation de fonctions serverless. Lorsqu\u2019ils d\u00e9veloppent et configurent des fonctions, les d\u00e9veloppeurs d\u2019applications doivent veiller \u00e0 s\u00e9curiser ces fonctions contre des attaques telles que SSRF et RCE. En l\u2019absence d\u2019une telle s\u00e9curit\u00e9, les attaquants pourraient manipuler les fonctions serverless qui sont vuln\u00e9rables au SSRF, ce qui am\u00e8nerait les fonctions \u00e0 envoyer des requ\u00eates non autoris\u00e9es aux services internes. Cela peut conduire \u00e0 un acc\u00e8s involontaire ou \u00e0 l\u2019exposition d\u2019informations sensibles au sein du syst\u00e8me, telles que les jetons d\u2019acc\u00e8s, le contenu de la base de donn\u00e9es interne ou les configurations de service. Il est important de souligner que ces risques surviennent principalement lorsque les fonctions sont publiques ou qu\u2019elles traitent des donn\u00e9es provenant d\u2019utilisateurs externes et d\u2019autres sources.<\/p>\n Dans les attaques SSRF, un attaquant trompe un serveur (comme une fonction serverless) en effectuant des requ\u00eates HTTP vers des ressources internes ou externes auxquelles l\u2019attaquant ne devrait pas avoir acc\u00e8s. Comme c\u2019est le serveur lui-m\u00eame qui fait la demande, il peut acc\u00e9der \u00e0 des services internes qui ne sont pas expos\u00e9s \u00e0 Internet. Une fonction serverlessr vuln\u00e9rable prend une URL en entr\u00e9e et r\u00e9cup\u00e8re les donn\u00e9es \u00e0 partir de celle-ci.<\/p>\n Dans GCP, SSRF peut \u00eatre utilis\u00e9 pour acc\u00e9der \u00e0 l\u2019IMDS \u00e0 l\u2019adresse hxxp:\/\/metadata.google[.]internal\/<\/span>, en extrayant des jetons temporaires de compte de service. Un attaquant peut alors utiliser ces jetons pour se faire passer pour la fonction et effectuer des actions non autoris\u00e9es dans le cadre des autorisations de son r\u00f4le IAM. Les vuln\u00e9rabilit\u00e9s li\u00e9es \u00e0 l\u2019ex\u00e9cution de code \u00e0 distance permettent aux attaquants d\u2019ex\u00e9cuter du code arbitraire dans l\u2019environnement d\u2019une fonction.<\/p>\n Pour AWS\u00a0Lambda, les attaques RCE pourraient exposer des mat\u00e9riels d\u2019authentification temporaires stock\u00e9es dans des variables d\u2019environnement, telles que AWS_ACCESS_KEY_ID<\/span> et AWS_SESSION_TOKEN<\/span>.<\/p>\n Il est essentiel de noter que ces vecteurs d\u2019attaque ne sont pas des failles inh\u00e9rentes aux plateformes cloud elles-m\u00eames, mais d\u00e9coulent plut\u00f4t d\u2019un d\u00e9veloppement non s\u00e9curis\u00e9 r\u00e9dig\u00e9 par les d\u00e9veloppeurs d\u2019applications qui pourrait introduire des vuln\u00e9rabilit\u00e9s, telles que SSRF ou RCE. Les d\u00e9veloppeurs d\u2019applications peuvent att\u00e9nuer ces risques en mettant en \u0153uvre des pratiques de d\u00e9veloppement s\u00e9curis\u00e9 telles que la validation des entr\u00e9es.<\/p>\n Les simulations suivantes montrent comment les attaquants pourraient extraire les jetons serverless et les utiliser pour des activit\u00e9s malveillantes dans diff\u00e9rents fournisseurs de services cloud (CSP). Ces attaques pourraient tirer parti d\u2019un code de fonction non s\u00e9curis\u00e9 d\u00e9ploy\u00e9 par les d\u00e9veloppeurs d\u2019applications.<\/p>\n Pour r\u00e9aliser cette simulation, nous avons d\u00e9ploy\u00e9 deux fonctions Google\u00a0Cloud\u00a0Run qui acc\u00e8dent au service de m\u00e9tadonn\u00e9es des fonctions et extraient les jetons des deux diff\u00e9rents comptes de service associ\u00e9s \u00e0 partir du chemin suivant\u00a0:<\/p>\n Le premier exemple illustre l\u2019extraction d\u2019un compte de service par d\u00e9faut. Le deuxi\u00e8me exemple illustre l\u2019extraction d\u2019un compte de service personnalis\u00e9. Ces exemples montrent comment le code peut acc\u00e9der directement au service de m\u00e9tadonn\u00e9es, tout comme une application vuln\u00e9rable \u00e0 une attaque SSRF pourrait \u00e9galement y acc\u00e9der.<\/p>\n Comme le montre la figure\u00a01, le compte de service associ\u00e9 \u00e0 la fonction \u00e9tait le compte de service serverless par d\u00e9faut. La figure\u00a02 montre que le jeton d\u2019acc\u00e8s renvoy\u00e9 appartient au m\u00eame compte de service.<\/p>\n La figure\u00a03 montre le compte de service personnalis\u00e9 que nous avons associ\u00e9 \u00e0 la fonction. La figure\u00a04 montre le jeton d\u2019acc\u00e8s renvoy\u00e9 appartenant au compte de service personnalis\u00e9. Nous avons ensuite utilis\u00e9 le jeton renvoy\u00e9 pour effectuer des op\u00e9rations dans l\u2019environnement.<\/p>\n La figure\u00a05 ci-dessous montre un exemple de commande permettant de lister les buckets.<\/p>\n Si des attaquants peuvent r\u00e9pertorier et lire le contenu des buckets dans GCP, ils peuvent acc\u00e9der \u00e0 des fichiers sensibles tels que des mat\u00e9riels d\u2019authentification, des sauvegardes ou des configurations internes. Cela leur permet de voler des donn\u00e9es, de compromettre le syst\u00e8me ou de se d\u00e9placer lat\u00e9ralement au sein de l\u2019environnement.<\/p>\n Une fois que les attaquants obtiennent un jeton d\u2019acc\u00e8s pour un compte de service avec des autorisations d\u2019\u00e9diteur dans GCP (comme le compte de service Compute\u00a0Engine par d\u00e9faut), ils peuvent modifier, supprimer ou cr\u00e9er des ressources dans la plupart des services. Il peut s\u2019agir d\u2019acc\u00e9der \u00e0 des donn\u00e9es sensibles, de d\u00e9ployer des workloads malveillants, d\u2019escalader des privil\u00e8ges ou de perturber des services. L\u2019acc\u00e8s de l\u2019\u00e9diteur permet un contr\u00f4le quasi total du projet.<\/p>\n Dans cette simulation, nous avons acc\u00e9d\u00e9 aux variables d\u2019environnement de la fonction Lambda et en avons extrait l\u2019AWS_ACCESS_KEY_ID<\/span>, l\u2019AWS_SECRET_ACCESS_KEY<\/span> et l\u2019AWS_SESSION_TOKEN<\/span>.<\/p>\n La figure\u00a06 montre la sortie du code de la fonction Lambda.<\/p>\n La figure\u00a07 montre la configuration des identifiants AWS temporaires obtenus \u00e0 l\u2019\u00e9tape pr\u00e9c\u00e9dente (les variables d\u2019environnement Lambda).<\/p>\n Nous avons ensuite utilis\u00e9 la commande suivante pour dresser la liste de tous les buckets\u00a0S3 auxquels la session authentifi\u00e9e peut acc\u00e9der.<\/p>\n Dans cette simulation, nous avons acc\u00e9d\u00e9 aux variables d\u2019environnement de la fonction Azure et extrait l\u2019IDENTITY_ENDPOINT et l\u2019IDENTITY_HEADER en ex\u00e9cutant des commandes \u00e0 distance. Nous avons ensuite extrait le jeton d\u2019identit\u00e9 manag\u00e9e via le terminal d\u2019identit\u00e9 local, en fournissant les param\u00e8tres indiqu\u00e9s ci-dessous dans la figure\u00a08\u00a0:<\/p>\n Des m\u00e9canismes de d\u00e9tection efficaces sont essentiels pour identifier l\u2019exfiltration de jetons dans les environnements sans serveur. Ces m\u00e9canismes se concentrent sur les anomalies de comportement pour signaler les activit\u00e9s non autoris\u00e9es. Voici quelques-unes des principales strat\u00e9gies de d\u00e9tection mises en \u0153uvre sur les principales plateformes cloud.<\/p>\n La d\u00e9tection se fait en deux \u00e9tapes\u00a0:<\/p>\n Pour identifier les comptes de service associ\u00e9s aux fonctions sans serveur dans GCP, nous analysons la section serviceAccountDelegationInfo<\/span> dans les journaux. Ces informations fournissent des indications cruciales sur la cha\u00eene de d\u00e9l\u00e9gation des comptes de service. Plus pr\u00e9cis\u00e9ment, lorsqu\u2019un compte de service est associ\u00e9 \u00e0 une fonction, il d\u00e9l\u00e8gue son autorit\u00e9 \u00e0 un compte de service sans serveur par d\u00e9faut\u00a0:<\/p>\n Ces comptes de service ex\u00e9cutent des t\u00e2ches au nom de la fonction.<\/p>\n Par exemple, dans l\u2019entr\u00e9e de journal de la figure\u00a09, nous voyons le compte de service personnalis\u00e9 associ\u00e9 \u00e0 une fonction (sa-test@<project-id>.iam.gserviceaccount[.]com<\/span>) d\u00e9l\u00e9guer son autorit\u00e9 \u00e0 l\u2019agent de service Cloud\u00a0Run.<\/p>\n Dans la figure\u00a09 ci-dessus, le champ principalEmail<\/span> sous authenticationInfo<\/span> sp\u00e9cifie le compte de service utilis\u00e9 (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com<\/span>).<\/p>\n Le serviceAccountDelegationInfo indique<\/span> le principal de premi\u00e8re partie (dans ce cas\u00a0: service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>), ce qui indique que le compte de service fonctionne dans un environnement sans serveur comme Cloud\u00a0Functions ou Cloud\u00a0Run.<\/p>\n Une approche efficace pour d\u00e9couvrir les identit\u00e9s serverless consiste \u00e0 \u00e9tablir le profil des comptes de service qui ont pr\u00e9c\u00e9demment d\u00e9l\u00e9gu\u00e9 leur autorit\u00e9 \u00e0 des comptes de service sans serveur par d\u00e9faut. Cela garantit que m\u00eame si des comptes de service autres que ceux par d\u00e9faut sont associ\u00e9s \u00e0 des fonctions, ils sont identifi\u00e9s.<\/p>\n Dans AWS, les fonctions Lambda s\u2019appuient sur les r\u00f4les IAM pour s\u00e9curiser l\u2019acc\u00e8s aux services AWS. Ces r\u00f4les g\u00e9n\u00e8rent des mat\u00e9riels d\u2019authentification temporaires. Nous pouvons identifier l\u2019identit\u00e9 Lambda par son nom de r\u00f4le.<\/p>\n Dans Azure, les identit\u00e9s manag\u00e9es associ\u00e9es aux Azure\u00a0Function\u00a0Apps sont utilis\u00e9es pour l\u2019authentification.<\/p>\n Dans un environnement cloud s\u00e9curis\u00e9, les fonctions serverless sont g\u00e9n\u00e9ralement destin\u00e9es \u00e0 ex\u00e9cuter des t\u00e2ches automatis\u00e9es et circonscrites, telles que la r\u00e9ponse \u00e0 des requ\u00eates API ou le traitement d\u2019\u00e9v\u00e9nements. Ces fonctions ne doivent pas \u00eatre utilis\u00e9es de mani\u00e8re interactive. Cependant, si des attaquants obtiennent l\u2019acc\u00e8s \u00e0 l\u2019environnement d\u2019une fonction sans serveur ou \u00e0 son identit\u00e9, ils peuvent l\u2019utiliser \u00e0 mauvais escient pour ex\u00e9cuter des commandes d\u2019interface de ligne de commande (CLI) (par exemple, gcloud<\/span> CLI<\/span> ou curl<\/span>) afin d\u2019interagir directement avec les ressources du cloud.<\/p>\n Une m\u00e9thode de d\u00e9tection consiste \u00e0 examiner le user-agent des appels API. Si l\u2019agent utilisateur correspond \u00e0 des outils CLI connus (par exemple, gcloud CLI<\/span>) ou \u00e0 des cadres de test d\u2019intrusion, il est signal\u00e9 comme suspect, car les CLI ne devraient g\u00e9n\u00e9ralement pas \u00eatre utilis\u00e9es par les identit\u00e9s serverless. Cela indique une exploitation potentielle de l\u2019environnement ou des jetons de compte de service.<\/p>\n \u00c0 noter que cette m\u00e9thode d\u2019identification de l\u2019utilisation \u00e0 distance des jetons sans serveur en fonction de l\u2019agent utilisateur ne peut pas \u00eatre r\u00e9alis\u00e9e dans Azure, car les informations relatives au user-agent n\u2019apparaissent pas dans les journaux Azure.<\/p>\n Une autre approche pour d\u00e9tecter l\u2019utilisation \u00e0 distance d\u2019un jeton d\u2019identit\u00e9 sans serveur consiste \u00e0 corr\u00e9ler l\u2019emplacement de l\u2019utilisation d\u2019un jeton avec des plages ASN d\u2019adresses IP de fournisseurs de cloud connus. Si une demande provient d\u2019une adresse IP externe non associ\u00e9e au CSP, une alerte est d\u00e9clench\u00e9e, mettant en \u00e9vidence une \u00e9ventuelle utilisation non autoris\u00e9e du jeton en dehors de l\u2019environnement cloud.<\/p>\n La s\u00e9curisation des jetons serverless n\u00e9cessite une combinaison de mesures proactives, de gestion de la posture et de pratiques de s\u00e9curit\u00e9 de surveillance de l\u2019ex\u00e9cution pour minimiser le risque d\u2019exploitation. Tout d\u2019abord, mettez en \u0153uvre le principe du moindre privil\u00e8ge en attribuant des r\u00f4les avec les autorisations minimales requises pour les fonctions sans serveur. Cela r\u00e9duit l\u2019impact potentiel d\u2019une mauvaise utilisation des jetons.<\/p>\n En outre, pour prot\u00e9ger les environnements d\u2019ex\u00e9cution sans serveur dans GCP et Azure, restreignez l\u2019acc\u00e8s \u00e0 l\u2019IMDS en configurant des contr\u00f4les au niveau du r\u00e9seau et en appliquant des m\u00e9canismes de validation des demandes. Assurer une validation robuste des entr\u00e9es pour emp\u00eacher les attaquants d\u2019utiliser des techniques d\u2019exploitation comme le SSRF pour acc\u00e9der aux m\u00e9tadonn\u00e9es sensibles, aux jetons et \u00e0 d\u2019autres ressources cloud comme les API et les bases de donn\u00e9es.<\/p>\n L\u2019informatique serverless est le choix privil\u00e9gi\u00e9 pour le d\u00e9veloppement d\u2019applications modernes, car elle offre des avantages significatifs en termes d\u2019\u00e9volutivit\u00e9, de rentabilit\u00e9 et de gestion simplifi\u00e9e de l\u2019infrastructure.<\/p>\n Les mat\u00e9riels d'authentification permettant \u00e0 ces fonctions d\u2019interagir avec les services cloud constituent un \u00e9l\u00e9ment de s\u00e9curit\u00e9 essentiel et une cible de choix pour les attaquants. La compromission de ces mat\u00e9riels d\u2019authentification peut avoir de graves cons\u00e9quences, notamment l\u2019acc\u00e8s non autoris\u00e9 \u00e0 des ressources cloud et l\u2019exfiltration de donn\u00e9es.<\/p>\n La mise en \u0153uvre d\u2019une gestion proactive de la posture et de protections de surveillance de l\u2019ex\u00e9cution est une strat\u00e9gie cruciale pour la protection des environnements cloud.<\/p>\n Les organisations peuvent mieux prot\u00e9ger leurs environnements sans serveur en\u00a0:<\/p>\n Les clients de Palo\u00a0Alto\u00a0Networks sont mieux prot\u00e9g\u00e9s contre les menaces mentionn\u00e9es ci-dessus gr\u00e2ce aux produits suivants\u00a0:<\/p>\n Si vous pensez que votre entreprise a pu \u00eatre compromise ou si vous faites face \u00e0 une urgence, contactez l\u2019\u00e9quipe Unit\u00a042 de r\u00e9ponse aux incidents<\/a> ou composez l\u2019un des num\u00e9ros suivants\u00a0:<\/p>\n Palo\u00a0Alto\u00a0Networks a partag\u00e9 ces conclusions avec les autres membres de la Cyber\u00a0Threat\u00a0Alliance (CTA). Les membres de la CTA s\u2019appuient sur ces renseignements pour d\u00e9ployer rapidement des mesures de protection aupr\u00e8s de leurs clients et perturber de mani\u00e8re coordonn\u00e9e les activit\u00e9s des cybercriminels. Cliquez ici pour en savoir plus sur la Cyber Threat Alliance.<\/a><\/p>\n Comprendre les m\u00e9canismes de l\u2019authentification sans serveur : trois attaques simul\u00e9es sur les principaux CSP proposent des approches efficaces pour les d\u00e9veloppeurs d\u2019applications.<\/p>\n","protected":false},"author":366,"featured_media":143160,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[8724,8832],"tags":[9293,9341,9342,9228],"product_categories":[9041,9046,9151],"coauthors":[4194],"class_list":["post-146708","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-cybersecurity-research-fr","category-threat-research-fr","tag-aws-fr","tag-google-cloud-fr","tag-microsoft-azure-fr","tag-serverless-fr","product_categories-cortex-fr","product_categories-cortex-cloud-fr","product_categories-unit-42-incident-response-fr"],"yoast_head":"\n<\/a>Google\u00a0Cloud\u00a0Functions<\/strong><\/h3>\n
\n
<\/a>Azure\u00a0Functions<\/strong><\/h3>\n
\n
\n
<\/a>Vecteurs d\u2019attaque pour l\u2019exfiltration de jetons<\/h2>\n
<\/a>Simulations de vecteurs d\u2019attaque<\/strong><\/h3>\n
<\/a>Simulation\u00a01\u00a0: Acc\u00e8s direct \u00e0 l\u2019IMDS \u00e0 partir d\u2019une fonction BPC<\/h4>\n
\n
<\/a>Exemple\u00a01\u00a0: Extraction d\u2019un compte de service par d\u00e9faut dans GCP<\/strong><\/h5>\n
![\"Capture](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-779752-146708-1.png\")
![\"Capture](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-781900-146708-2.png\")
<\/a>Exemple\u00a02\u00a0: Extraction d\u2019un compte de service personnalis\u00e9 dans GCP<\/strong><\/h5>\n
![\"Capture](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-785198-146708-3.png\")
![\"Capture](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-787944-146708-4.png\")
![\"Capture](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-791287-146708-5.png\")
<\/a>Simulation\u00a02\u00a0: Utilisation de RCE pour r\u00e9cup\u00e9rer les jetons stock\u00e9s dans les variables d\u2019environnement de la fonction AWS\u00a0Lambda<\/h4>\n
![\"Capture](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-793232-146708-6.png\")
![\"\u00c9cran](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-795855-146708-7.png\")
aws s3 ls<\/pre>\n
<\/a>Simulation\u00a03\u00a0: Utilisation de RCE pour r\u00e9cup\u00e9rer des jetons \u00e0 partir d\u2019un terminal d\u2019identit\u00e9 local d\u2019une fonction Azure<\/h4>\n
\n
![\"Capture](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-798695-146708-8.png\")
<\/a>D\u00e9tection et pr\u00e9vention de l\u2019exfiltration de jetons<\/h2>\n
<\/a>D\u00e9tection de l\u2019exfiltration de jetons dans les environnements sans serveur<\/strong><\/h3>\n
\n
\n
<\/a>\u00c9tape\u00a01\u00a0: Identifier les identit\u00e9s serverless<\/h4>\n
\n
![\"Capture](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-800643-146708-9.png\")
<\/a>\u00c9tape\u00a02\u00a0: Identifier les comportements inhabituels pour les identit\u00e9s serverless<\/h4>\n
<\/a>Strat\u00e9gies de pr\u00e9vention<\/h3>\n
<\/a>Conclusion<\/h2>\n
\n
<\/a>Protection et mitigation des risques par Palo\u00a0Alto\u00a0Networks<\/h2>\n
\n
<\/a>Pour aller plus loin<\/h2>\n
\n