Lancée en 2016, Azure Functions est la plateforme serverless de Microsoft pour automatiser la gestion des événements et la maintenance des infrastructures applicatives. La firme de Redmond est loin d'être seule sur ce créneau porteur, et doit notamment compter sur de sérieux concurrents dont AWS avec Lambda. Outre la concurrence, l'éditeur doit également se battre avec les failles de sécurité dont une qui a été découverte par les chercheurs en sécurité d'Intezer. Après Azure Network Watcher et App Services, une dernière vulnérabilité affectant Functions a ainsi été décelée.

Dans un billet de blog, les chercheurs en sécurité d'Inezer ont tout d'abord expliqué avoir conçu un déclencheur de requêtes HTTP pour interagir avec le container Docker créé sous Azure Functions puis une commande shell inversée pour se connecter à un serveur de commande et de contrôle et identifier des applications ayant des privilèges root. Ce faisant, Inezer a identifié un binaire Mesh pouvant être exploité pour accorder des autorisations de type administrateur. Une fois étendue au niveau du container, cette escalade a permis d'exécuter une commande sur l'hôte Docker ce qui n'est pas possible normalement depuis Azure Functions. « L'escalade vers le root dans un conteneur est une réalisation remarquable, mais l'augmentation des privilèges dans les conteneurs n'est pas la destination finale d'un attaquant », a expliqué le chercheur en sécurité Paul Litvak d'Intezer. « La compromission de l'hôte Docker leur donnerait beaucoup plus de contrôle, leur permettant de se détacher du conteneur qui pourrait être surveillé et se déplacer vers l'hôte Docker qui est souvent négligé en termes de sécurité ».

La sécurité de l'architecture serverless et des microservices en question

Après une évaluation interne, Microsoft a cependant déterminé que la vulnérabilité n'avait aucun impact sur la sécurité d'Azure Functions en lui-même et que l'hôte Docker bénéficie d'une défense de type sandbox apportée par Hyper-V contre l'abus de privilèges. « Après évaluation, ils ont décidé de ne pas corriger le bogue, car ils prétendent qu'il n'affecte pas la sécurité. La raison en est que l'hôte Docker n'est pas l'hôte final en lui-même », précise Intezer. « Cet hôte Docker ne contient que notre propre conteneur Docker, et c'est l'hôte réel qui gère l'infrastructure partagée entre différentes fonctions Azure appartenant à différents clients Azure, auxquelles nous n'avons pas pu accéder ». Toutefois, d'après Intezer, Microsoft a quand même effectué des changements au bloc /etc et aux répertoires /sys sur la base de ses résultats.

« Quels que soient les efforts déployés pour sécuriser votre propre code, les vulnérabilités sont parfois hors de votre contrôle », a noté Paul Litvak. « Il est essentiel de mettre en place des mesures de protection pour détecter et mettre fin à l'exécution par un attaquant de code non autorisé dans votre environnement de production ». Pour Jigar Shah, vice-président du service de sécurité réseau Valtix, à mesure que les entreprises adoptent de nouvelles approches telles que l'architecture serverless et les microservices, se fier simplement à la sécurité sous-jacente de ces services ou de ceux du fournisseur de cloud pose quand même problème. « Le vieux mantra de la réduction de la surface d'attaque et de la défense en profondeur est toujours crucial : contrôle d'accès basé sur les attributs SSE (server side encryption) et application du filtrage d'URL pour tous les flux sortants », prévient Jigar Shah. « Le ba-ba de la sécurité réseau ne disparaît pas quand on passe aux clouds publics ».