L’attaque Man in the Cloud

Attaque MITC


Introduction

Vous connaissiez sans doute l’attaque Man in the middle (MITM) qui consiste à intercepter des données sur un flux de communication. Vous connaissiez peut-être également, l’attaque Man in the browser (MITB) qui permet de compromettre les flux (http mais également https) via un code malveillant installé sur le poste client et bien voici maintenant l’attaque Man in the Cloud (MITC) qui permet de compromettre vos données dans le Cloud.

Man in the Cloud, c’est le nom donné à cette attaque par Imperva, la société de sécurité israélienne à l’origine de cette découverte. L’attaque MITC vise exclusivement les applications de stockage en ligne. L’étude d’Imperva porte en particulier sur Box, Dropbox, Google Drive et OneDrive et démontre la possibilité de compromettre intégralement les données hébergées dans le Cloud avec en prime la possibilité d’infecter le poste client et d’exfiltrer des données via le service de synchronisation.

Dans ce type d’application, afin d’éviter que l’utilisateur ne soit obligé de se ré-authentifier à chaque requête, un jeton de synchronisation est créé puis stocké sur le poste client dans le registre (pour Google Drive), dans un fichier (Dropbox) ou dans le gestionnaire d’identités de Windows (pour OneDrive et Box). Deux mécanismes d’authentification différents sont utilisés sur les services testés par Imperva. Alors que Box, Drive et OneDrive s’appuient sur le standard OAuth 2.0, Dropbox utilise un système d’authentification propriétaire.

MITC_0L’utilisation du jeton est très simple. Une fois installé sur le poste client, c’est le seul élément demandé par le service Cloud pour authentifier l’utilisateur et lui donner accès aux données hébergées. Les chercheurs d’Imperva ont remarqué que le jeton de synchronisation n’était pas lié à la machine ni à la session utilisateur en cours. Dans ces conditions, si un même jeton de synchronisation peut être utilisé sur des ordinateurs différents, il suffit de voler le jeton pour accéder au compte de l’utilisateur sans avoir à connaitre son identifiant ou son mot de passe.

Pour démontrer la vulnérabilité des services Cloud et matérialiser l’attaque, Imperva a développé l’outil Switcher. Un attaquant s’authentifie sur le service Cloud et génère un jeton. Switcher prend ce jeton et le stocke dans l’endroit approprié (selon le tableau ci-dessus) sur le poste Client de la victime. Switcher copie également le jeton original (celui de la victime) dans le répertoire de synchronisation. Le hacker peut maintenant récupérer le jeton de l’utilisateur et s’emparer de toutes ses données hébergées dans le Cloud. Une fois l’opération accomplie, Switcher remet en place le jeton original et donne à l’utilisateur l’impression que tout va bien dans le meilleur des mondes…

Dans son rapport, Imperva détaille trois scénarii possibles pour effectuer l’attaque : double échange rapide, double échange permanent et simple échange (rapide ou permanent).


Scénario double échange rapide

Cette attaque assez simple permet à l’attaquant de récupérer le jeton de synchronisation de la victime. L’attaquant est alors en mesure d’accéder aux fichiers qui sont synchronisés par la victime et peut infecter ces fichiers avec un code malveillant. L’attaque est décrite dans la figure suivante :

MITC_1

  1. L’attaquant trompe l’utilisateur par ingénierie sociale (malware dans un email par exemple) ou exploite une faille dans le navigateur ou un de ses plugins (drive-by-download) pour exécuter Switcher sur le poste de la victime. Switcher installe le jeton de synchronisation de l’attaquant dans le système.
  2. Switcher copie le jeton de synchronisation original dans le dossier de synchronisation
  3. L’application synchronise le dossier avec le compte de l’attaquant.
  4. L’attaquant a alors en sa possession le jeton de synchronisation de la victime.
  5. En réutilisant Switcher sur son poste, l’attaquant installe le jeton volé et accède à toutes les données de la victime stockées dans le Cloud.
  6. Switcher est utilisé une seconde fois sur le poste de la victime (double échange) afin de rétablir le jeton de synchronisation d’origine de la victime afin qu’il ne se doute de rien.

C’est la forme « plus propre » de l’attaque. En effet, une fois l’attaque terminée, l’état du dossier de synchronisation de la victime est la même qu’avant l’attaque. Le programme Switcher s’auto détruit et ne laisse aucune trace.

L’attaque en double échange est potentiellement très dangereuse car les services de synchronisation dans le Cloud ne restreignent pas l’accès de plusieurs appareils à partir de plusieurs endroits sur un même compte utilisateur. Ainsi, il est possible pour un attaquant de maintenir une activité de synchronisation fraduleuse avec le compte de la victime à partir de n’importe où, à tout moment et ceci sans qu’aucune notification ne soit envoyée au propriétaire du compte.

En plus d’avoir accès aux données de l’utilisateur, l’attaquant peut manipuler les fichiers dans le dossier de synchronisation sur sa machine de sorte que les modifications se propagent à la machine de la victime. Par exemple, un attaquant peut insérer du code malveillant dans les documents (exemple un macro dans un document Office ou un script dans un document PDF) qui s’exécutera dès que la victime ouvrira un fichier infecté sur son poste. Cerise sur le gâteau, les résultats de l’exécution peuvent être envoyés dans le dossier de synchronisation puis récupérés par l’attaquant. Après l’opération, l’attaquant peut même supprimer les fichiers résultats dans le dossier de synchronisation et restaurer les fichiers originaux de la victime afin d’éliminer toute trace de l’attaque. Il est possible d’imaginer d’autres scénarios d’attaque comme par exemple une nouvelle façon de pratiquer le « Ransomware ». Dans ce schéma, l’attaquant crypte tous les fichiers de la victime. Une fois les fichiers synchronisés avec tous ses autres appareils, la victime se retrouve dans l’impossibilité d’avoir accès à ses propres documents tant qu’il n’accepte de payer une rançon au hacker.

Scénario double échange persistant

Cette attaque est semblable à la précédente, à l’exception que l’attaquant souhaite maintenir l’accès à distance à la victime. Cet accès permet à l’attaquant d’interagir avec la machine de la victime de temps à autre, exécuter du code arbitraire, et de recueillir la sortie de ce code. L’attaque est décrite en deux phases dans les deux figures suivantes :

MITC_2

MITC_3

  1. L’attaquant trompe l’utilisateur par ingénierie sociale (malware dans un email par exemple) ou exploite une faille dans le navigateur ou un de ses plugins (drive-by-download) pour exécuter Switcher sur le poste de la victime. Switcher installe le jeton de synchronisation de l’attaquant dans le système.
  2. Switcher copie le jeton de synchronisation original dans le dossier de synchronisation
  3. L’application synchronise le dossier avec le compte de l’attaquant.
  4. L’attaquant a alors en sa possession le jeton de synchronisation de la victime.
  5. En réutilisant Switcher sur son poste, l’attaquant installe le jeton volé et accède à toutes les données de la victime stockées dans le Cloud.
  6. Switcher est utilisé une seconde fois sur le poste de la victime(double échange) afin de rétablir le jeton de synchronisation d’origine de la victime afin qu’il ne se doute de rien.
  7. Après le second échange, l’attaquant met en place un outil d’accès à distance de type RAT (Remote Access Tool) paramétré pour attendre l’apparition d’un fichier à un endroit particulier dans le dossier de synchronisation afin de l’exécuter.
  8. Un code malveillant est mis dans l’emplacement spécifique dans le dossier de synchronisation de l’ordinateur de l’attaquant
  9. Le dossier est synchronisé avec la machine de la victime. Le RAT l’identifie et l’exécute.
  10. Le résultat de l’exécution est écrit dans le dossier de synchronisation sur la machine de la victime puis récupéré par l’attaquant via une synchronisation.
  11. Une fois les données récupérées, l’attaquant peut alors supprimer le résultat et le code de l’attaque.

Scénario simple échange (rapide ou persistant)

Dans ce type d’attaque, les données de la victime sont synchronisés avec un compte contrôle par l’attaquant.

MITC_4

  • L’attaquant lance l’exécution du programme Switcher sur le poste de la victime (typiquement via une opération d’ingénierie sociale ou une attaque de type drive-by-download). Switcher installe le jeton de synchronisation de l’attaquant dans le système.
  • Le dossier de synchronisation de la victime est synchronisé avec celui de l’attaquant.
  • L’attaque est désormais terminée et l’attaquant a maintenant accès aux données de l’utilisateur. Dans une attaque persistante, l’attaquant met en plus, sur le poste de la victime, un outil d’accès à distance de type RAT (Remote Access Tool) paramétré pour attendre l’apparition d’un fichier à un endroit particulier dans le dossier de synchronisation afin de l’exécuter.
  • Un code malveillant est mis dans l’emplacement spécifique dans le dossier de synchronisation de l’ordinateur de l’attaquant
  • Le dossier est synchronisé avec la machine de la victime. Le RAT l’identifie et l’exécute.

L’avantage de cette technique est que même si le service de synchronisation met en place un mécanisme de contrôle des accès suspicieux (pour détecter par exemple des accès simultanés à partir de deux endroits différents) la notification de l’anomalie sera envoyée à l’attaquant plutôt qu’à la victime puisque c’est le jeton de synchronisation de l’attaquant qui est utilisé. L’inconvénient est que, comme le jeton installé n’est pas celui de la victime, la synchronisation ne va pas s’effectuer correctement sur les autres dispositifs de l’utilisateur. Pour minimiser les soupçons, l’attaquant peut périodiquement revenir réinstaller le jeton original de la victime pour permettre une synchronisation avec le compte d’origine.

Détection et remédiation de l’attaque

L’attaque MITC est difficilement détectable car elle s’appuie sur du code déjà installé (l’agent de synchronisation) et sur des canaux de communication légitimes car nécessaires au bon fonctionnement du service. Pour la détection, Imperva propose 2 approches possibles : La détection de la compromission du compte de synchronisation ou plus important encore la détection d’un usage abusif des données internes de l’entreprise. Imperva pense en effet que les attaquants seront probablement plus intéressés par d’autres données dans l’entreprise que celles situées dans les répertoires de synchronisation des postes clients.

Pour la détection de la compromission du compte de synchronisation, Imperva précise que la tâche risque d’être difficile avec les techniques traditionnelles (détection de code malveillant ou analyse des flux de communication vers le C&C). En conséquence, Imperva recommande d’utiliser des solutions de CASB (Cloud Access Security Broker) afin de surveiller l’utilisation des services de Cloud par les utilisateurs. Toujours, selon Imperva, les solutions de CASB sont tout à fait capables de détecter en temps réel ce type d’attaque. D’autres solutions de CASB déployées en mode SecaaS (dans le Cloud) peuvent également stopper l’attaque en bloquant l’accès aux périphériques non officiellement reconnus par l’entreprise.

Pour la seconde approche, Imperva recommande aux entreprise de déployer des solutions de type DAM (Database Activity Monitoring) ou FAM (File Activity Monitoring) pour détecter tout trafic suspicieux.

Les préconisations d’Imperva ne sont pas vraiment surprenantes puisque la société israélienne commercialise des produits CASB avec Imperva Skyfence Cloud Gateway , DAM avec Securephere Database Security et FAM avec File Activity Monitor. C’est de bonne guerre, les vendeurs de solutions de sécurité cherchent des vulnérabilités et des POC (proof of concept) dans le but d’expliquer en quoi leur offre répond à de véritables problématiques de sécurité. Mais n’y aurait-il pas d’autres solutions plus efficaces et moins chères ? Bien sûr que oui et commençons par traiter l’origine du problème. Et si les fournisseurs de service Cloud en profitaient pour mieux sécuriser leur service ? En mettant tout simplement en œuvre un jeton de synchronisation utilisable sur un seul et même device. C’est facile à faire, radical contre l’attaque et ne coûte pas un Kopeck à l’utilisateur. Une autre solution, tout à fait complémentaire, consisterait à chiffrer systématiquement les données que l’on envoi dans le Cloud. Outre le fait que l’attaquant ne pourra plus les lire, ni y insérer de malware, cela protégera également vos données contre un éventuel administrateur malveillant opérant chez le prestataire. La difficulté étant de trouver une solution de chiffrement fiable, ergonomique et compatible avec les différents OS des dispositifs sur lequel on souhaite partager les informations. Enfin et contrairement à ce qu’affirme Imperva, l’attaque peut être détectée au niveau de poste client. Il suffit pour cela de mettre en œuvre une solution de contrôle d’intégrité. Le lecteur intéressé par cette approche pourra consulter l’article Detecting Man-in-the-Cloud (MitC) Attacks with Adaptive Threat Protection sur le site de Tripwire (éditeur de solutions de contrôle d’intégrité…).

Il est vrai cependant que dans la plupart des cas, l’attaque MITC sera assez difficile à détecter et même si l’utilisateur s’en aperçoit, il lui sera parfois difficile de la stopper. En effet, pour cela il faut impérativement révoquer le jeton de l’attaquant et la tâche n’est pas toujours facile selon le service de Cloud utilisé. La révocation du jeton est particulièrement simple avec Google Drive car il suffit d’effectuer un changement de mot de passe. Cette opération entraine alors la révocation de tous les jetons associés au compte utilisateur et impose pour chaque appareil une nouvelle authentification avec l’identifiant et le mot de passe. D’autre part, comme le changement de mot de passe entraine une révocation immédiate des jetons, toute tentative d’accès au service avec un jeton révoqué sera systématiquement refusée. La situation est assez similaire avec Microsoft Onedrive. La seule différence est toute session déjà en cours et initialisée avec un jeton avant révocation reste active et valide. Il faut donc supprimer manuellement ces périphériques associés dans l’onglet d’administration du compte OneDrive. Avec Box, il faut également changer le mot de passe mais utiliser en plus l’option « révoquer tous les jetons » pour stopper l’attaque. Pour finir, c’est avec Dropbox que la tâche est la plus ardue car un simple changement de mot de passe ne modifie pas le jeton (valeur de la variable host id présente dans le fichier SQLite config.dbx). Pour les détails techniques, on se référera au document d’Imperva. Dans ce dernier cas, il sera sans doute plus simple de supprimer le compte Dropbox existant et d’en créer un nouveau. Bienvenu dans le monde merveilleux du cloud…




Bonnes pratiques SSL/TLS : Les Clouds français sont-ils à la hauteur ?

Titre_SSL_Cloud_French

[ Introduction ]             [ Résultats ]            [ Analyse ]             [ Conclusion ]


Introduction

Pour créer et administrer des machines virtuelles dans un IaaS public, les fournisseurs mettent à disposition de leurs clients des interfaces Web accessibles via le protocole sécurisé https. Ces interfaces sont des éléments particulièrement sensibles car elles sont accessibles publiquement sur Internet et leur compromission permettrait à un attaquant de prendre le contrôle total de nos machines dans le Cloud.

Le problème est que le protocole https utilise des fonctions cryptographiques (SSL/TLS), historiquement développées par Netscape au début des années 90 et que ces fonctions cryptographiques ont subi ces dernières années de nombreuses attaques : attaque sur la renegociation, attaque sur RC4, collision MD5, BEAST, CRIME, POODLE, etc… Il y a également d’autres problèmes non pas liés à la cryptographie SSL elle-même mais plutôt à de mauvaises implémentations logicielles comme par exemple le bug dans OpenSSL (Heartbleed) mais aussi celui dans la librairie open source utilisée par Apple (goto fail). Et les problèmes ne sont pas terminés comme en témoigne l’annonce de 8 nouvelles vulnérabilités dans OpenSSL le 8 janvier 2015 dont l’une d’elles permet de réaliser l’attaque SSL/TLS du moment : FREAK (Factoring attack on RSA-Export Keys).

Nous avons donc décidé de vérifier si les interfaces d’authentification de 4 fournisseurs IaaS français (OVH, Numergy, Cloudwatt et Nuage_Made_in_FranceOutscale) étaient correctement paramétrées d’un point de sécurité. En d’autres termes, les fournisseurs nationaux respectent-ils les bonnes pratiques de sécurité concernant les flux chiffrés SSL/TLS.

Nos tests ont porté exclusivement sur la gestion des flux chiffrés. Il ne s’agit en aucun cas d’un audit de sécurité, ni d’un test d’intrusion mais tout simplement d’une vérification de la configuration SSL/TLS. Les vulnérabilités spécifiques aux applications Web (XSS, CSRF, SQL injection, etc…) n’entrent pas dans le périmètre de notre étude.

Pour ce faire, nous avons utilisé sur www.ssllabs.com, un outil gratuit et disponible publiquement sur Internet proposé par Qualys. Il a été développé par Ivan Ristic, le concepteur du pare-feu applicatif mod_security.

Son utilisation est très simple. On soumet le nom du serveur à tester à ssllabs et le service effectue une vérification approfondie de la configuration SSL/TLS de la cible et délivre une note globale de sécurité sous forme d’une lettre de A à F.

Il faut ensuite interpréter les résultats de la façon suivante :

ssllabs_A+   ssllabs_A   ssllabs_A-
Excellente configuration SSL/TLS
Aucune vulnérabilité connue n’est exploitable

ssllabs_B   ssllabs_C   ssllabs_D   ssllabs_E
Mauvaise configuration SSL/TLS
Une ou plusieurs vulnérabilités peuvent compromettre la session

ssllabs_F
Très mauvaise configuration SSL/TLS
Une ou plusieurs vulnérabilités facile à exploiter peuvent compromettre la session

Compte tenu de la criticité de ces interfaces Web dans l’infrastructure Cloud, il va sans dire que pour un fournisseur de IaaS public, on ne s’attend pas à autre chose que la lettre A. Une note A+ serait bien sûr idéale mais un A- sera tout à fait acceptable. Les lettres B, C, D et E indiquent quelques lacunes en matière de sécurité sur lesquelles le fournisseur doit agir assez rapidement. La lettre F traduisant quant à elle de graves lacunes de sécurité sur lesquelles le fournisseur n’a apparemment réalisé aucune évaluation de sécurité et doit maintenant intervenir dans les plus brefs délais. Précisons enfin qu’il n’y a aucun coût financier pour passer de la lettre F à la lettre A (Pas d’obligation d’acquérir un certificat SSL EV ou un boitier HSM). Il faut simplement effectuer quelques modifications dans les paramètres SSL/TLS des serveurs et l’opération ne prend que quelques minutes.

Nous avons également regardé comment les clients arrivent sur la page d’authentification du service. Si le lien vers la page d’authentification s’effectue via le site Web du fournisseur lui-même accessible uniquement en https alors l’accès à l’interface d’administration est correctement sécurisée. Par contre si l’accès se fait via une page Web en http alors la connexion sera potentiellement vulnérable. Pourquoi ? Parce qu’un site Web accessible via le protocole http signifie qu’aucune authentification du serveur n’est réalisée par le navigateur. L’attaquant peut ainsi très facilement réaliser une attaque de type Man In The Middle (MITM) et substituer ainsi la page d’authentification originale par une page frauduleuse par une simple réécriture d’URL à la volée. Une telle attaque ne pose pas aucune difficulté et plusieurs outils existent pour la réaliser comme par exemple sslsnif et sslstrip de Moxie Marlinspike.

D’autre part, tout site Web accessible via http est beaucoup plus vulnérable aux opérations de phishing toujours en raison de l’absence d’authentification du serveur. En conclusion, même si son contenu n’est pas confidentiel (chiffrement des flux non nécessaire) l’intégralité du site Web du fournisseur doit être uniquement accessible via le protocole https.


Résultat des tests

Classement CSP

Les copies d’écran du test ssllabs.com sont disponibles sur cette page.


Analyse des résultats

CloudwattCloudwatt propose un accès correctement sécurisé pour ses services. Toutes les erreurs classiques de paramétrage d’un serveur https ont été évitées. On regrettera cependant l’absence de certificat à validation étendue (Certificat SSL EV) permettant d’accroître la confiance dans le site. En effet avec un certificat SSL, identifiable par le cadenas en vert dans la barre d’adresse, l’utilisateur connaît immédiatement quelle société se trouve derrière le site par l’affichage de son nom et du pays dans lequel elle réside. D’autre part, la délivrance d’un certificat SSL EV par une autorité de certification fait l’objet de contrôles bien plus rigoureux sur l’organisme demandeur (existence juridique de 3 ans minimum, inscription au RCS, etc…) que pour un certificat SSL classique ou seule la possession du nom de domaine peut s’avérer suffisante.

4 recommandations pour améliorer la sécurité de Cloudwatt :

  • Remplacer les certificats X509 standards par des certificats SSL EV
  • Remplacer la signature sha1 des certificats par une signature sha2
  • Activer le support du Forward Secrecy sur le serveur
  • Ne pas se contenter de faire un http redirect vers https et forcer le protocole sécurisé avec HSTS (Strict Transport Security – RFC 6797)

Outscale

Outscale n’utilise pas non plus de certificat SSL EV. D’autre part, la configuration laisse apparaître la disponibilité du protocole SSL v3 qui est obsolète et surtout extrêmement vulnérable depuis la découverte en octobre 2014 d’une vulnérabilité dénommée POODLE.

5 recommandations pour améliorer la sécurité de Outscale :

  • Corriger immédiatement les problèmes de configuration SSL/TLS sur toutes les interfaces Web en particulier désactiver le protocole SSLv3
  • Remplacer les certificats X509 standards par des certificats SSL EV
  • Remplacer la signature sha1 des certificats par une signature sha2
  • Activer le support du Forward Secrecy sur le serveur
  • Ne pas se contenter de faire un http redirect vers https et forcer le protocole sécurisé avec HSTS (Strict Transport Security – RFC 6797)

OVHOVH dispose d’une configuration SSL correcte et utilise de plus des certificats SSL EV. Dommage que le site www.ovh.com soit toujours accessible via http.

5 recommandations pour améliorer la sécurité du Cloud OVH :

  • Mettre l’intégralité du site accessible uniquement via https
  • Pour les accès en http sur la page d’accueil, faire une redirection (HTTP redirect) vers https
  • Positionner le flag HSTS (RFC 6797) pour forcer le navigateur à utiliser exclusivement https
  • Remplacer la signature sha1 des certificats par une signature sha2
  • Activer le support du Forward Secrecy sur le serveur

Numergy

Pour Numergy, tout commence bien avec l’apparition d’un certificat SSL EV sur la page d’accueil du site (www.numergy.com). On passe ensuite sur la page d’authentification (login.numergy.com) qui elle n’utilise pas de certificat EV. Les choses se compliquent ensuite puisque l’analyse détaillée de la configuration révèle de graves lacunes de sécurité.

Pour la page d’authentification du service (login.numergy.com – 87.255.157.62), on dénombre pas moins de 7 problèmes de sécurité dont 3 très graves :

  • Utilisation d’algorithme asymétrique (DH) vulnérable pour l’échange des clés
  • Support d’anciens algorithmes vulnérables et exploitables via l’attaque FREAK publiée le 3 mars 2015 et découverte par Antoine Delignat Lavaud chercheur à l’INRIA.
  • Le protocole SSL v3 est activé et le site est vulnérable à l’attaque POODLE sans aucune contre-mesure permettant d’en limiter l’impact (TLS_FALLBACK_SCSV)

Devant une telle situation, nous avons souhaité voir ce qui se passait derrière la page d’authentification. Nous avons donc crée un compte utilisateur avec nos informations carte bancaire pour la facturation. Pour la petite histoire, on notera que la saisie des informations carte bancaire s’effectue sur un site de paiement de la société générale (paiement.socgenactif.com) qui n’est pas non plus un modèle de sécurité puisqu’il obtient la même note (F) dans le test ssllabs.

Après le paiement, le service nous indique que notre compte a été créé et que notre mot de passe nous sera envoyé par SMS. Le mot de passe arrive et surprise, il ne tient que sur 8 caractères (6 caractères alphabétiques, un caractère numérique et un seul caractère spécial). Nous essayons alors d’utiliser ce même mot de passe pour la création d’un compte chez le concurrent (Cloudwatt), pour voir ce que ça donne :

Check-PWD

Tiens, il semblerait que les deux fournisseurs n’aient pas la même approche sur la robustesse des mots de passe. On se dit que tout ceci n’est pas bien grave et que Numergy va évidemment nous imposer dès la première connexion de changer ce mot de passe. Et bien pas du tout ! Le mot de passe envoyé par mail est utilisable en permanence sur la console d’administration du service IaaS. Nous avons essayé l’option « j’ai oublié mon mot de passe » et une fenêtre nous demande notre e-mail et nous renvoi un nouveau mot de passe par SMS. Ce mot de passe est toujours aussi faible avec 8 caractères (dont un numérique et un spécial) et toujours permanent.
Ce choix technique n’est évidemment pas judicieux quand on sait que de nombreuses vulnérabilités (sous iOS et Androïd en particulier) permettent de récupérer les SMS des smartphones. On peut par exemple récupérer en quelques secondes l’intégralité des SMS dans un iPhone lorsque celui-ci est jailbreaké. D’autre part, sur de nombreux téléphones, tout SMS reçu s’affiche en clair sur l’écran même si le téléphone est verrouillé. Pour prendre le contrôle d’un compte administrateur sur Numergy, il suffit donc de saisir l’adresse email de la victime et d’avoir l’écran de son téléphone en visuel. Scénario, on ne peut plus simple à réaliser. Ensuite, on constate que le mot de passe a été créé par Numergy et une règle de base en sécurité est qu’il ne faut jamais conserver un mot de passe généré par un algorithme inconnu. D’autre part, ce mot de passe est potentiellement connu de l’opérateur Télécom puisqu’il est envoyé par SMS et éventuellement d’un autre fournisseur Cloud si l’administrateur a synchronisé son smartphone dans le nuage. Ca fait quand même beaucoup de monde qui peuvent potentiellement avoir accès à nos données dans le Cloud Numergy sans pour autant avoir besoin de faire appel aux services du GCHQ ou de la NSA…

Tant qu’à être connecté, nous avons également testé la gestion de session. Nous ouvrons donc une session dans un navigateur que nous laissons ensuite en totale inactivité pendant plus de 4 heures. Nous revenons ensuite sur le navigateur et nous constatons que la session d’administration est toujours active.

Nous vérifions maintenant les mécanismes anti « brute force ». On tente de se connecter avec notre identifiant valide en injectant une trentaine de mots de passe erronés. L’interface réagit à chaque fois immédiatement en nous indiquant l’échec d’authentification et en nous invitant à recommencer. Aucun délai entre les mires de login et aucun CAPTCHA ne viennent perturber notre test. Nous essayons maintenant de nous connecter pour voir si notre compte n’est pas verrouillé et là encore pas de problème, ça passe. Une fois connecté, aucun message d’alerte ne vient nous informer des tentatives infructueuses que vient de subir le compte.

Pour terminer cette très rapide évaluation de sécurité, nous avons lancé deux autres tests ssllabs :

ssllabs_F
Site d’administration des machines virtuelles
mon2.numergy.com – Adresse IP : 87.255.151.7

 

ssllabs_F
API Rest du service Numergy
api2.numergy.com – Adresse IP 87.255.151.6

 

6 recommandations pour améliorer la sécurité SSL/TLS chez Numergy :

  • Corriger immédiatement les problèmes de configuration SSL/TLS sur toutes les interfaces Web du Cloud Numergy et en particulier celles accessibles publiquement via Internet (login.numergy.com, mon2.numergy.com)
  • Même chose avec les API Rest du service (api2.numergy.com)
  • Ne pas se contenter de faire un http redirect vers https et forcer le protocole sécurisé avec HSTS (Strict Transport Security – RFC 6797)
  • Remplacer la signature sha1 des certificats par une signature sha2
  • Activer le support du Forward Secrecy sur les serveurs
  • Généraliser l’usage des certificats SSL EV sur l’ensemble des serveurs

+ 7 recommandations complémentaires pour Numergy :

  • Ne pas générer de mot de passe permanent pour les clients
  • Imposer au strict minimum 10 caractères avec minuscules, majuscules, chiffres et caractères spéciaux
  • Ne jamais envoyer un mot de passe permanent par SMS
  • Gérer un timeout d’inactivité sur la session
  • Intégrer un mécanisme anti brute force et en cas d’attaque verrouiller le compte et informer le client
  • Proposer une option d’authentification à deux facteurs (comme le font tous les leaders mondiaux du Cloud)
  • Prendre en compte plus rapidement les alertes de sécurité en provenance des clients (suivi d’incident détaillé en fin d’article)

Conclusion

Premier constat et ce n’est pas pour nous une véritable surprise : La seule société à ne pas être certifiée ISO 27001, Cloudwatt, est celle qui obtient la meilleure note de sécurité. Rappelons encore une fois qu’une certification ISO 27001 ne garantit pas un niveau de sécurité. Elle ne garantit pas non plus que les solutions de sécurité ont été déployées conformément aux bonnes pratiques et à l’état de l’art. La norme ISO 27001 atteste simplement que le fournisseur a mis en œuvre un processus de gestion de la sécurité de son système d’information (SMSI) conforme à la politique de sécurité qu’il a lui-même défini. Elle ne certifie donc en aucun cas que les données du fournisseur ou celles de ses clients seront correctement sécurisées et notre étude en est une parfaite illustration.

Second constat, de nombreux clients font une confiance aveugle aux fournisseurs de services Cloud. Les labels de sécurité, les discours marketing et l’opacité des infrastructures de Cloud public rendant les audits indépendants impossibles sont d’autant de moyens pour convaincre les clients de la sécurité du service. Nous recommandons donc naturellement à tous les clients d’aller plus loin dans l’évaluation de la sécurité de leur fournisseur avant de leur confier leurs données.

Et pour finir, que faut-il penser de la sécurité des Clouds souverains ? En effet, Numergy est une société française créée en 2012 par SFR, Bull et l’état français dans le cadre du projet de Cloud souverain français (Andromède).
Pour beaucoup de fournisseurs et de médias français, la souveraineté se réduit trop souvent à deux choses. Une menace clairement identifiée : l’USA PATRIOT Act et une réponse imparable : la localisation des datacenters en France. Les fournisseurs français ont-ils bien intégré que le Patriot Act n’était pas la seule menace qui pèse sur les entreprises françaises et qu’il fallait agir en conséquence pour démontrer leur capacité à contrer toutes les menaces potentielles dans le Cloud ?

Et si l’on en revient un instant au Patriot Act et plus généralement à la menace en provenance des USA, posons-nous les bonnes questions :

  • Peut-on véritablement être souverain lorsque l’infrastructure de sécurité réseau s’appuie sur les technologies israélo-américaines de Cisco, F5, Fortinet et Checkpoint ? Qui pourrait imaginer un seul instant un pare-feu Airbus Defense & Space dans un GovCloud AWS ?
  • Peut-on assurer la sécurité de nos données face à une puissance étrangère si les flux de communication chiffrés sont affectés par de multiples vulnérabilités ?
  • Peut-on assurer la sécurité de nos données, si l’on envoie les mots de passe d’administration par SMS que la NSA peut intercepter facilement tant sur le réseau de l’opérateur que sur les terminaux mobiles ?

Note importante

Vendredi 13 mars 2015 à 20h30 : Ouverture Ticket d’incident Numergy
Plus de 3 jours avant la publication de cet article, nous avons ouvert un ticket incident (Priorité 1 : Very high) au support Numergy pour les informer des vulnérabilités sur leurs interfaces Web. Nous réactualiserons ci-dessous cet article dès que Numergy nous fera un retour.

Message dans le ticket d’incident :
En tant que nouvel utilisateur du Cloud Numergy (compte crée ce jour – 13/03/2015), je me suis permis de vérifier si vos interfaces Web étaient correctement paramétrées d’un point de vue sécurité.
A l’aide du service sslabs.com, j’ai testé :
login.numergy.com, mon2.numergy.com et api2.numergy.com.
Il apparait que ces 3 systèmes sont extrêmement mals configurés avec pour conséquence la possible compromission de toutes nos machines virtuelles dans le Cloud Numergy.
Je vous invite à remédier à ces problèmes dans les plus brefs délais et de me tenir au courant dès que cela sera fait.
Je vous remercie de votre compréhension.

Samedi 14 mars 2015 à 12h33 : 1ère réponse de Numergy
Bonjour,
Dans un premier temps nous vous remercions de votre vigilance .
Sachez que Numergy porte une attention particulière à la sécurité .
Tout nos systèmes sont régulièrement scanné pour en vérifier la sécurité .
Dans ce sens , votre remarque a été remontée a notre équipe de supervision et sécurité qui vous recontactera dans les plus brefs délais.
Cordialement,
L’Equipe Numergy

Mercredi 23 mars 2015 à 15h33 : 2eme message de Numergy
Monsieur, je vous remercie de votre retour.

Nous mettons tout en œuvre au quotidien pour assurer la sécurité de la plateforme et des environnements clients.
Certains des points remontés ont été jugés pertinents et les actions associées ont été menées.

Nous vous souhaitons une excellente journée.
 
Cordialement,
Service Support


Suite à la prise en compte de notre message au support Numergy, deux interfaces (mon2.numergy.com et api2.numergy.com) ont été corrigées le 18 mars et sont maintenant classées « A » par ssllabs. La troisième interface (login.numergy.com) a été corrigée le 23 mars et obtient également la même note pour la configuration SSL/TLS. Nous ne pouvons que féliciter le support Numergy qui a pris en compte notre alerte.
Si le comparatif avait lieu aujourd’hui, Numergy obtiendrait désormais la meilleure note avec la lettre A pour configuration SSL/TLS et https pour l’intégralité du site Web.




Encore une faille critique dans l’hyperviseur Xen

Cela fait déjà plusieurs jours que le monde du Cloud s’agite autour d’une nouvelle vulnérabilité critique de l’hyperviseur Xen. De nombreux fournisseurs Cloud sont concernés : Amazon WS, Rackspace, IBM, Linode, etc…
Et ce n’est hélas pas la première fois qu’une faille extrêmement critique nécessite le redémarrage en urgence de l’hyperviseur Xen et donc le reboot de milliers de machine virtuelles. Le dernier problème similaire remonte seulement à septembre 2014 c’est à dire il y a moins de 6 mois (CVE-2014-7188).

Pour cette nouvelle faille, le correctif est disponible depuis plus de 10 jours. Les fournisseurs ont donc pu planifié son déploiement avec une certaine sérénité car ce n’est qu’aujourd’hui que les détails de la vulnérabilité (CVE-2015-2151) sont dévoilés et que d’éventuels Exploit pourraient voir le jour.
Pour les clients, l’impact aura été très variable selon le fournisseur Cloud. Pour certains CSP, le reboot systématique s’impose. Amazon avait annoncé dans un premier temps que seulement 10% des instances EC2 devraient rebooter. Finalement, Amazon a annoncé que grâce à leur Live update seulement 0,1% des instances AWS ont dû redémarrer.

Que risque-t-on si le fournisseur de Cloud n’applique pas le correctif ?
Pour cela, il suffit de lire la section « Impact » du bulletin de sécurité :
A malicious guest might be able to read sensitive data relating to other guests, or to cause denial of service on the host. Arbitrary code execution, and therefore privilege escalation, cannot be excluded.

En d’autres termes dans un Cloud public comme Amazon AWS, un locataire du service IaaS pourrait potentiellement réaliser un « hypervisor escape », c’est à dire accéder à des données dans une VM invitée voisine (i-e celle d’un autre client), faire un deni de service (arrêter des services), exécuter du code et éventuellement réaliser une élévation de privilège.

La faille est donc critique et prend une importance considérable dans un contexte de Cloud public. Il est donc important pour les clients de savoir quels sont les hyperviseurs utilisés par leurs fournisseurs et quels sont leurs engagements en matière de gestion des correctifs.


Autres ressources :




Ciphercloud s’installe en France

Par communiqué de presse en date du 5 février 2015, Ciphercloud annonce l’ouverture de ses bureaux parisiens dans le cadre d’une expansion rapide sur le marché français. Ces nouveaux bureaux couvriront les ventes, les services et l’assistance clientèle.

Mais connaissez-vous Ciphercloud ?
Ciphercloud est une société américaine qui propose d’assurer la sécurité des données dans un cloud public en toute indépendance du fournisseur. Le principe repose un proxy de chiffrement qui sécurise les données sur les flux vers le cloud. Les clés de chiffrement utilisées ne sont jamais accessibles par le fournisseur du service. Les solutions de Ciphercloud permettent par exemple de sécuriser une base de données dans AWS, des emails dans Office365 ou dans Gmail, des données clients chez Saleforce ou bien encore des fichiers dans Box.

Schéma de principe avec Office 365 :CipherCloud-O365

Nous publierons prochainement sur SecuriteCloud.com une présentation détaillée des solutions de Ciphercloud avec les avantages bien sûr mais aussi les limites de ce type de solution. Dans le cadre de ce dossier, nous sommes à la recherche de retours clients. Si vous avez mis en œuvre (ou simplement testé) Ciphercloud dans votre entreprise et si vous souhaitez nous faire part de votre expérience, merci de nous contacter.


Autres ressources :




Key Vault, le HSM enfin disponible dans Azure

Bien plus tardivement que son principal concurrent Amazon avec son offre CloudHSM, Microsoft annonce enfin Key Vault, une solution HSM pour son cloud Azure. Key Vault permet une amélioration sensible de la sécurité des données par le stockage des secrets cryptographiques et des données sensibles dans un module de sécurité matériel (HSM) certifié FIPS 140-2 niveau 2 et Critères Communs EAL4 +.
Rappelons qu’un HSM renforce considérablement la sécurité des opérations cryptographiques asymétriques car la génération des bi-clés a lieu à l’intérieur du dispositif. Avec un HSM, la clé privée n’est jamais directement accessible aux administrateurs ou aux applications. Les opérations asymétriques devant invoquer la clé privée se déroulent donc exclusivement à l’intérieur du boitier HSM. Ainsi, ni un administrateur malveillant, ni même une faille critique comme heartbleed ne peuvent permettre la compromission de la clé privée car elle ne se trouve jamais dans la mémoire utilisée par le système ou les applications.


 Autres ressources :