# AWS - Voler des requêtes Lambda {{#include ../../../../banners/hacktricks-training.md}} ## Flux Lambda

https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/lambda_poc_2_arch.png

1. **Slicer** est un processus en dehors du conteneur qui **envoie** des **invocations** au processus **init**. 2. Le processus init écoute sur le port **9001** exposant quelques points de terminaison intéressants : - **`/2018-06-01/runtime/invocation/next`** – obtenir le prochain événement d'invocation - **`/2018-06-01/runtime/invocation/{invoke-id}/response`** – retourner la réponse du gestionnaire pour l'invocation - **`/2018-06-01/runtime/invocation/{invoke-id}/error`** – retourner une erreur d'exécution 3. **bootstrap.py** a une boucle récupérant les invocations du processus init et appelle le code des utilisateurs pour les gérer (**`/next`**). 4. Enfin, **bootstrap.py** envoie au processus init la **réponse** Notez que bootstrap charge le code utilisateur en tant que module, donc toute exécution de code effectuée par le code des utilisateurs se produit en réalité dans ce processus. ## Voler des requêtes Lambda L'objectif de cette attaque est de faire exécuter un processus **`bootstrap.py`** malveillant par le code des utilisateurs à l'intérieur du processus **`bootstrap.py`** qui gère la requête vulnérable. De cette manière, le processus **bootstrap malveillant** commencera à **communiquer avec le processus init** pour gérer les requêtes pendant que le bootstrap **légitime** est **piégé** à exécuter le malveillant, donc il ne demandera pas de requêtes au processus init. C'est une tâche simple à réaliser car le code de l'utilisateur est exécuté par le processus **`bootstrap.py`** légitime. Ainsi, l'attaquant pourrait : - **Envoyer un faux résultat de l'invocation actuelle au processus init**, de sorte que init pense que le processus bootstrap attend plus d'invocations. - Une requête doit être envoyée à **`/${invoke-id}/response`** - L'invoke-id peut être obtenu à partir de la pile du processus **`bootstrap.py`** légitime en utilisant le module python [**inspect**](https://docs.python.org/3/library/inspect.html) (comme [proposé ici](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)) ou en le demandant à nouveau à **`/2018-06-01/runtime/invocation/next`** (comme [proposé ici](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)). - Exécuter un **`boostrap.py`** malveillant qui gérera les prochaines invocations - Pour des raisons de discrétion, il est possible d'envoyer les paramètres d'invocation lambda à un C2 contrôlé par l'attaquant et ensuite de gérer les requêtes comme d'habitude. - Pour cette attaque, il suffit d'obtenir le code original de **`bootstrap.py`** du système ou de [**github**](https://github.com/aws/aws-lambda-python-runtime-interface-client/blob/main/awslambdaric/bootstrap.py), d'ajouter le code malveillant et de l'exécuter à partir de l'invocation lambda actuelle. ### Étapes de l'attaque 1. Trouver une vulnérabilité **RCE**. 2. Générer un **bootstrap** **malveillant** (par exemple, [https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py](https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py)) 3. **Exécuter** le bootstrap malveillant. Vous pouvez facilement effectuer ces actions en exécutant : ```bash python3 <