Sécurité : le meilleur et le pire d’Azure

L’importance de la surveillance et de la gestion des logs

Pour illustrer de tels problèmes, Russinovich a présenté plusieurs exemples d’incidents ayant concerné des clients d’Azure l’an passé. Le premier a commencé avec Microsoft recevant des alertes indiquant que certaines machines virtuelles au sein d’Azure attaquaient des clients à l’extérieur de son Cloud. Certes, l’éditeur ne surveille pas les VM et les applications de ses clients sans leur permission expresse, mais il surveillance le trafic global à la recherche de pics d’activité anormaux ou de connexions suspectes.

« Lorsque nous observons une explosion du trafic provenant d’un endroit, cela peut être un problème lié à notre infrastructure, un bug logiciel, ou encore un attaquant qui a infiltré le cloud d’un client ou notre infrastructure Cloud », explique le directeur technique.

Dans ce cas précis, Microsoft a déterminé que le code d’attaque se trouvait au sein d’une VM client et non pas dans l’infrastructure d’Azure. L’éditeur a dès lors notifié son client, qui s’en est avéré très satisfait et a pu enquêter sur l’incident. A cette occasion, Microsoft a découvert que si le client stockait ses logs, il n’en avait pas analysé les données ni configuré d’alertes ou encore intégré les données de ces logs à son système de gestion des informations et des événements de sécurité (SIEM) déployé en interne : « il s’est avéré que le client ne prêtait pas réellement attention aux logs et aux alertes provenant de ses machines virtuelles ».

A cette occasion, le client d’Azure a également découvert que l’anti-virus de ses VM avait été désactivé. Pour Russinovich, si ce client avait surveillé les logs de ses machines virtuelles, il aurait remarqué l’activité malicieuse quelques jours avant que Microsoft ne la lui signale. Et cela recouvrait notamment la création d’un nouveau compte utilisateur de type administrateur : « cet exemple montre que, lorsque vous passez au Cloud, vous devez conserver les pratiques de référence que vous appliquez en local. Sinon, vous passez à côté de choses comme celles-ci. Et qui sait combien de temps il aurait pu s’écouler avant que ce client réalise ce qui se passait si on ne l’avait alerté ».

Gérer les vulnérabilités dans le Cloud

Russinovich a également évoqué la question de la gestion des vulnérabilités et présenté deux exemples illustrant la manière dont l’approche adoptée pour Azure peut varier selon celui qui est in fine responsable.

Et de commencer par Shellshock, la vulnérabilité affectant le shell Bash dévoilée en septembre dernier. Les attaques visant Azure et l’exploitant ont commencé presqu’immédiatement : « alors que nous scannions nos systèmes, nous avons observé de nombreuses machines virtuelles Linux devenus des zombies au service d’attaquants ».

Microsoft a immédiatement averti ses clients visés et alerté ceux dont les VM avaient été compromises. A charge pour les clients d’appliquer des correctifs sous 48h : « nous leur laissons le temps de nettoyer, mais ils mettent véritablement tout le monde en danger. Nous nous sentons dès lors obligés de réagir s’ils ne le font pas ».

Et justement, dans une telle situation, Microsoft peut suspendre le déploiement Azure et l’abonnement du client jusqu’à la résolution de l’incident. Pour l’heure, l’éditeur n’a pas eu à aller jusqu’à cette extrémité. Mais celle-ci n’est pas exclue : « les clients peuvent faire ce qu’ils veulent tant que cela ne pénalise pas les autres clients ou le service. Ce n’est pas une discussion plaisante à avoir avec un client, mais il n’est pas plaisant non plus de les voir utiliser Azure d’une façon qui risque de pénaliser les autres clients ».

Mais Russinovich s’est également penché sur un autre exemple, où Microsoft était en faute, en introduisant un bug dans une mise à jour logicielle pour l’un de ses services. En cas d’exploitation, ce bug aurait permis à un client Azure d’accéder aux données transférées par FTP par un autre client. Un client a informé Microsoft et l’éditeur a rapidement activé son processus de réaction aux incidents de sécurité – un processus en neuf étapes recouvrant détection d’événement, implication des équipes de sécurité et de DevOps, confirmation de l’événement, identification des clients affectés, détermination de l’impact, et notification des clients.

Russinovich a présenté une chronologie de réaction à ce bug FTP, commençant par la première notification de client. Une fois qu’un second eut rapporté ce même bug, les équipes sécurité et DevOps ont été impliquées ; en l’espace de quelques heures, un événement de sécurité a été déclaré et le processus de remédiation a été engagé, commençant par la désactivation des capacités FTP d’Azure. L’équipe de sécurité a ensuite déterminé l’étendue du problème et notifié les clients tout en déployant un correctif. Russinovich indique qu’il a fallu pour cela environ 24h, entre la notification du second client et le déploiement du correctif. Heureusement, aucun client n’a rencontré d’activité malicieuse en raison du bug.

Les attaques de Cloud à Cloud

Enfin, Russinovich s’est penché sur les problèmes de sécurité trouvant leur origine dans d’autres Clouds et sur la manière dont ils peuvent affecter Azure. En particulier, il a détaillé un cas où Azure a été atteint par une attaque en déni de service distribué (DDoS) menée à partir d’un autre cloud compromis : « dans ce cas, nous avons observé des pics de trafic entrant sur notre Cloud – 35 millions de paquets par seconde de trafic malicieux ». Heureusement, les systèmes périphériques d’Azure ont été conçus pour gérer ce type d’attaque : « 90 % du trafic DDoS n’entre même pas dans notre Cloud ».

Russinovich explique que l’équipe sécurité d’Azure a enquêté sur le pic de trafic et découvert que l’attaque ne provenait pas d’une Cloud, mais de deux, qu’il n’a pas nommés. Travaillant avec les opérateurs de ces Clouds, Microsoft a alors découvert qu’ils avaient été compromis de manières complètement différentes. Pour le premier, les VM de plusieurs clients ont été compromises avec la vulnérabilité Shellshock et transformées en un botnet. Pour le second, c’est une vaste compromission de comptes utilisateurs qui a permis aux attaquants de prendre le contrôle de pans entiers de l’infrastructure pour les utiliser comme une plateforme d’attaque en DDoS.

Selon Russinovich, la majorité des incidents de sécurité affectant Azure sont le résultat d’erreurs de clients ou de tiers : « nombre de ces brèches que nous avons observées sont liées à la compromission d’identifiants. Du coup, nous prêchons très fortement pour l’authentification à double-facteur ».

De fait, pour lui, les identifiants faibles constituent l’une des principales causes de brèches dans Azure, avec l’absence de correctifs de sécurité, l’insuffisance de la surveillance, ou encore l’exposition sur Internet de services RDP et SSH.

Reste que les utilisations abusives d’Azure ont plus doublé en nombre au cours du second semestre 2014 ; une statistique qui recouvre le hameçonnage, les attaques en DDoS, la violation de copyright, et autres activités illégales.

Et Russinovich d’appeler son auditoire à appliquer les pratiques de référence, comme la supervision, l’application rapide de correctifs, ou encore le renforcement de protection des identifiants : « les utilisations abusives continuent de progresser, bien sûr, parce que l’utilisation du Cloud progresse. Mais également parce que les attaquants deviennent de plus en plus futés ».

Adapté de l’anglais.