AWS - Lambda Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Plus d'infos sur lambda dans :
iam:PassRole
, lambda:CreateFunction
, (lambda:InvokeFunction
| lambda:InvokeFunctionUrl
)Les utilisateurs avec les permissions iam:PassRole
, lambda:CreateFunction
, et lambda:InvokeFunction
peuvent élever leurs privilèges.
Ils peuvent créer une nouvelle fonction Lambda et lui attribuer un rôle IAM existant, accordant à la fonction les permissions associées à ce rôle. L'utilisateur peut ensuite écrire et télécharger du code sur cette fonction Lambda (avec un rev shell par exemple).
Une fois la fonction configurée, l'utilisateur peut déclencher son exécution et les actions prévues en invoquant la fonction Lambda via l'API AWS. Cette approche permet effectivement à l'utilisateur d'effectuer des tâches indirectement via la fonction Lambda, opérant avec le niveau d'accès accordé au rôle IAM qui lui est associé.\
Un attaquant pourrait abuser de cela pour obtenir un rev shell et voler le token :
Vous pourriez également abuser des autorisations du rôle lambda depuis la fonction lambda elle-même. Si le rôle lambda avait suffisamment d'autorisations, vous pourriez l'utiliser pour vous accorder des droits d'administrateur :
Il est également possible de leak les identifiants de rôle de la lambda sans avoir besoin d'une connexion externe. Cela serait utile pour Lambdas isolées du réseau utilisées pour des tâches internes. S'il y a des groupes de sécurité inconnus filtrant vos shells inversés, ce morceau de code vous permettra de leak directement les identifiants en tant que sortie de la lambda.
Impact potentiel : Privesc direct vers le rôle de service lambda arbitraire spécifié.
Notez que même si cela peut sembler intéressant, lambda:InvokeAsync
ne permet pas à lui seul d'exécuter aws lambda invoke-async
, vous avez également besoin de lambda:InvokeFunction
iam:PassRole
, lambda:CreateFunction
, lambda:AddPermission
Comme dans le scénario précédent, vous pouvez vous accorder la permission lambda:InvokeFunction
si vous avez la permission lambda:AddPermission
Impact potentiel : Privesc direct au rôle de service lambda arbitraire spécifié.
iam:PassRole
, lambda:CreateFunction
, lambda:CreateEventSourceMapping
Les utilisateurs avec les permissions iam:PassRole
, lambda:CreateFunction
, et lambda:CreateEventSourceMapping
(et potentiellement dynamodb:PutItem
et dynamodb:CreateTable
) peuvent indirectement escalader les privilèges même sans lambda:InvokeFunction
.
Ils peuvent créer une fonction Lambda avec du code malveillant et lui attribuer un rôle IAM existant.
Au lieu d'invoquer directement la Lambda, l'utilisateur configure ou utilise une table DynamoDB existante, la liant à la Lambda via un mappage de source d'événement. Cette configuration garantit que la fonction Lambda est déclenchée automatiquement lors de l'entrée d'un nouvel élément dans la table, soit par l'action de l'utilisateur, soit par un autre processus, invoquant ainsi indirectement la fonction Lambda et exécutant le code avec les permissions du rôle IAM passé.
Si DynamoDB est déjà actif dans l'environnement AWS, l'utilisateur doit seulement établir le mappage de la source d'événements pour la fonction Lambda. Cependant, si DynamoDB n'est pas utilisé, l'utilisateur doit créer une nouvelle table avec le streaming activé :
Maintenant, il est possible de connecter la fonction Lambda à la table DynamoDB en créant un mappage de source d'événements :
Avec la fonction Lambda liée au flux DynamoDB, l'attaquant peut déclencher indirectement la Lambda en activant le flux DynamoDB. Cela peut être accompli en insérant un élément dans la table DynamoDB :
Impact potentiel : Privesc direct au rôle de service lambda spécifié.
lambda:AddPermission
Un attaquant avec cette permission peut s'accorder (ou accorder à d'autres) toutes les permissions (cela génère des politiques basées sur les ressources pour accorder l'accès à la ressource) :
Impact potentiel : Privesc direct au rôle de service lambda utilisé en accordant la permission de modifier le code et de l'exécuter.
lambda:AddLayerVersionPermission
Un attaquant avec cette permission peut s'accorder (ou accorder à d'autres) la permission lambda:GetLayerVersion
. Il pourrait accéder à la couche et rechercher des vulnérabilités ou des informations sensibles.
Impact potentiel : Accès potentiel à des informations sensibles.
lambda:UpdateFunctionCode
Les utilisateurs détenant la permission lambda:UpdateFunctionCode
ont le potentiel de modifier le code d'une fonction Lambda existante qui est liée à un rôle IAM.
L'attaquant peut modifier le code de la lambda pour exfiltrer les identifiants IAM.
Bien que l'attaquant n'ait peut-être pas la capacité directe d'invoquer la fonction, si la fonction Lambda est préexistante et opérationnelle, il est probable qu'elle soit déclenchée par des workflows ou des événements existants, facilitant ainsi indirectement l'exécution du code modifié.
Impact potentiel : Privesc direct au rôle de service lambda utilisé.
lambda:UpdateFunctionConfiguration
Avec ces permissions, il est possible d'ajouter des variables d'environnement qui provoqueront l'exécution de code arbitraire par la Lambda. Par exemple, en python, il est possible d'abuser des variables d'environnement PYTHONWARNING
et BROWSER
pour faire exécuter des commandes arbitraires par un processus python :
Pour d'autres langages de script, il existe d'autres variables d'environnement que vous pouvez utiliser. Pour plus d'informations, consultez les sous-sections des langages de script dans :
Lambda Layers permet d'inclure du code dans votre fonction lambda mais de le stocker séparément, de sorte que le code de la fonction puisse rester petit et que plusieurs fonctions puissent partager du code.
À l'intérieur de lambda, vous pouvez vérifier les chemins à partir desquels le code python est chargé avec une fonction comme suit :
Ces sont les emplacements :
/var/task
/opt/python/lib/python3.7/site-packages
/opt/python
/var/runtime
/var/lang/lib/python37.zip
/var/lang/lib/python3.7
/var/lang/lib/python3.7/lib-dynload
/var/lang/lib/python3.7/site-packages
/opt/python/lib/python3.7/site-packages
/opt/python
Par exemple, la bibliothèque boto3 est chargée depuis /var/runtime/boto3
(4ème position).
Il est possible d'abuser de la permission lambda:UpdateFunctionConfiguration
pour ajouter une nouvelle couche à une fonction lambda. Pour exécuter du code arbitraire, cette couche doit contenir une bibliothèque que la lambda va importer. Si vous pouvez lire le code de la lambda, vous pourriez le trouver facilement, notez également qu'il pourrait être possible que la lambda utilise déjà une couche et que vous puissiez télécharger la couche et ajouter votre code à l'intérieur.
Par exemple, supposons que la lambda utilise la bibliothèque boto3, cela créera une couche locale avec la dernière version de la bibliothèque :
Vous pouvez ouvrir ./lambda_layer/boto3/__init__.py
et ajouter la porte dérobée dans le code global (une fonction pour exfiltrer des identifiants ou obtenir un shell inversé par exemple).
Ensuite, zippez ce répertoire ./lambda_layer
et téléchargez la nouvelle couche lambda dans votre propre compte (ou dans celui des victimes, mais vous n'aurez peut-être pas les autorisations pour cela).
Notez que vous devez créer un dossier python et y mettre les bibliothèques pour remplacer /opt/python/boto3. De plus, la couche doit être compatible avec la version de python utilisée par la lambda et si vous la téléchargez dans votre compte, elle doit être dans la même région :
Maintenant, rendez la couche lambda téléchargée accessible par n'importe quel compte :
Et attachez la couche lambda à la fonction lambda de la victime :
Le prochain étape serait soit de invoquer la fonction nous-mêmes si nous le pouvons, soit d'attendre qu'elle soit invoquée par des moyens normaux – ce qui est la méthode la plus sûre.
Une manière plus discrète d'exploiter cette vulnérabilité peut être trouvée dans :
Impact potentiel : Privesc direct au rôle de service lambda utilisé.
iam:PassRole
, lambda:CreateFunction
, lambda:CreateFunctionUrlConfig
, lambda:InvokeFunctionUrl
Peut-être qu'avec ces permissions, vous êtes capable de créer une fonction et de l'exécuter en appelant l'URL... mais je n'ai pas trouvé de moyen de le tester, donc faites-le moi savoir si vous le faites !
Certaines lambdas vont recevoir des informations sensibles des utilisateurs dans les paramètres. Si vous obtenez RCE dans l'une d'elles, vous pouvez exfiltrer les informations que d'autres utilisateurs lui envoient, vérifiez-le dans :
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)