Une faille d’Azure Functions permet l’élévation de privilèges

0

Une vulnérabilité d’élévation de privilège de la fonction de conteneur cloud Azure Functions de Microsoft pourrait à terme permettre à un utilisateur d’échapper au conteneur, selon les chercheurs.

Les chercheurs d’Intezer ont surnommé le bug « Royal Flush » après une limitation flush-to-disk qu’un exploit devrait éviter. Le flush-to-disk signifie que les données sont transmises au noyau, où elles sont visibles par d’autres processus mais peuvent ne pas survivre à un redémarrage.

L’entreprise a constaté que les conteneurs Azure Functions fonctionnent avec le Docker privilégié, ce qui signifie que les fichiers d’appareils dans le dossier /dev peuvent être partagés entre l’hôte Docker et l’invité du conteneur. La vulnérabilité provient du fait que ces fichiers d’appareils ont des autorisations de lecture-écriture pour « d’autres ».

« Le laxisme des autorisations sur les fichiers de l’appareil ne sont pas un comportement standard », selon l’analyse.

Cela devient un problème étant donné que l’environnement Azure Functions contient 52 partitions différentes avec des systèmes de fichiers, qui peuvent être visibles entre les utilisateurs, selon Intezer.

« Nous soupçonnions que ces partitions appartenaient à d’autres clients Azure Functions, mais une évaluation plus approfondie a montré que ces partitions n’étaient que des systèmes de fichiers ordinaires utilisés par le même système d’exploitation, y compris pmem0, qui est le système de fichiers de l’hôte Docker », expliquent les chercheurs.

« Cela pourrait devenir dangereux dans le cas où les attaquants auraient accès à l’environnement des victimes, en tant qu’utilisateur à faible privilèges », a déclaré Ari Eitan, vice-président de la recherche à Intezer. « En utilisant cette vulnérabilité, un attaquant peut élever ses privilèges et faire des choses qu’il ne devrait pas pouvoir faire (lire les fichiers du système de fichiers, par exemple). »

En outre, bien que le bogue n’est pas une vulnérabilité d’évasion docker directe, « si un utilisateur est en mesure d’obtenir des privilèges root, ils seraient en mesure d’échapper à l’hôte Docker en utilisant diverses techniques d’évasion Docker, » a-t-il expliqué.

L’exploit Royal Flush d’Azure Functions

Pour sonder les trajectoires d’attaque qui pourraient découler de cette configuration, les chercheurs ont créé un conteneur d’essai local. Ils ont constaté que l’utilisation de l’utilitaire Debugfs (un utilitaire spécial utilisé pour le débogage du noyau Linux, qui peut être utilisé pour examiner et modifier l’état d’un système de fichiers), un utilisateur non privilégié peut facilement traverser le système de fichiers Azure Functions. Et, il s’avère qu’un utilisateur non privilégié peut également modifier directement tous les fichiers trouvés à l’intérieur.

« Au début, nous avons essayé de modifier le contenu du fichier en utilisant la commande zap_block en modifiant directement le contenu des blocs de système de fichiers », selon l’analyse. « En interne, le noyau Linux traite ces modifications au *fichier d’appareil* /dev/sda5, et ils sont mis en cache dans un emplacement différent des modifications apportées au *fichier régulier* /etc/passwd. En conséquence, il est nécessaire d’effacer les modifications du disque, mais cela est géré par l’utilitaire Debugfs. »

Toutefois, les chercheurs ont pu trouver un moyen de contourner cette limite en effectuant des changements directs aux dossiers.

« Tout d’abord, nous avons créé un lien via Debugfs dans le répertoire diff de notre conteneur afin que les changements soient appliqué à notre conteneur », ont expliqué les chercheurs. Le répertoire diff est une énumération complète des objets dans le conteneur.

Ils ont ajouté: « Ce lien nécessite encore des autorisations root pour être modifié, donc nous avons encore dû utiliser zap_block pour modifier son contenu. Nous avons ensuite utilisé posix_fadvise pour demander au noyau de jeter les pages du cache de lecture (flush, d’où le nom de la technique), inspiré par un projet nommé « pagecache management« . Cela a amené le noyau à charger nos modifications et nous avons finalement été en mesure de les propager au système de fichiers hôte Docker.

Debugfs prend également en charge un mode d’écriture, permettant aux utilisateurs d’apporter des modifications au disque sous-jacent, ont noté les chercheurs: « Il est important de noter que l’écriture sur un disque monté est généralement une mauvaise idée car il peut causer une corruption dans le disque, » ont-ils ajouté.

Avec la possibilité de modifier des fichiers arbitraires appartenant à l’hôte Docker, un attaquant peut apporter des modifications au fichier /etc/ld.so.preload, ont expliqué les chercheurs – ce qui permettrait une attaque de « préchargement-détournement » qui propage un objet partagé malveillant à travers le répertoire diff du conteneur.

« Ce fichier pourrait être préchargé dans tous les processus dans le système d’hôte Docker (nous avons précédemment documenté les logiciels malveillants HiddenWasp en utilisant cette technique) et donc l’attaquant serait en mesure d’exécuter du code malveillant sur l’hôte Docker, selon l’analyse.

Intezer a signalé la vulnérabilité de Microsoft Security Response Center (MSRC), mais aucun correctif ne sera disponible. Le géant de l’informatique a déterminé que la vulnérabilité « n’a pas d’impact sur la sécurité des utilisateurs d’Azure Functions », selon l’analyse, car l’hôte Docker utilisé par les chercheurs était en fait un invité HyperV et donc protégé par une autre couche de bac à sable(sanndbox). Cela ne veut pas dire que la faille ne pourrait pas être dangereuse dans une configuration différente.

« Malgré le fait que MSRC dit qu’il n’y a rien à craindre, nous croyons qu’un attaquant avancé pourrait profiter de cette vulnérabilité et qu’il pourrait l’aider dans le cadre d’une attaque », a déclaré Eitan. « C’est pourquoi nous l’avons publié. »

Les chercheurs ont également fourni un code d’exploitation de preuve de concept:

azure functions intezer

Microsoft n’a pas immédiatement répondu aux demandes de commentaire.

« Des cas comme celui-ci soulignent que les vulnérabilités sont parfois inconnues ou hors du contrôle du client du cloud », a déclaré Intezer. « Une approche à deux volets de la sécurité du cloud est recommandée : faites les bases, comme la correction des vulnérabilités connues et le durcissement de vos systèmes pour réduire la probabilité d’être attaqués, ainsi que la mise en œuvre d’une protection contre les runtime pour détecter et répondre à l’exploitation post-vulnérabilité et à d’autres attaques en mémoire au fur et à mesure qu’elles se produisent. »

Si cet article vous a plu, jetez un œil à notre article précédent.

Laisser un commentaire