Pourquoi le réseau NordVPN est toujours sûr en dépit d’une brèche chez un fournisseur

Chronologie

• Le serveur affecté a été mis en ligne le 31 janvier 2018.
• Des preuves d’une brèche sont d’abord apparues le 5 mars 2018, mais nous n’avons alors pas été mis au courant. D’autres éléments suggèrent que c’est à peu près à cette date que la brèche est vraisemblablement survenue.
• La brèche a été contenue lorsque le data center a effacé le compte de gestion non dévoilé et non sécurisé le 20 mars 2018.
• Nous avons été informé de la brèche le 13 avril 2019. Nous avons détruit le serveur le jour même.

Éléments clés

• Un serveur a été affecté en Finlande en mars 2018. Le reste de notre service n’a pas été affecté. Aucun autre serveur de quelque type que ce soit n’a couru de risque. Il s’agissait d’une attaque sur notre serveur, et non pas sur notre service entier.
• La brèche a été rendue possible par la mauvaise configuration d’un data center partenaire qui ne nous a jamais été notifiée. Les éléments à notre disposition suggèrent que lorsque le data center a pris connaissance de l’intrusion, il a effacé les comptes qui avaient causé les vulnérabilités au lieu de nous informer de leur erreur. Dès que nous avons été mis au courant de la brèche, le serveur a été détruit, le contrat nous liant à ce fournisseur a été résilié et nous avons débuté un audit étendu de notre service.
• Aucune information utilisateur n’a été affectée.
• Il n’y a aucun signe que l’intrus ait tenté d’accéder au trafic de nos utilisateurs de quelque façon que ce soit. Et quand bien même il avait essayé, il n’aurait pas eu accès aux données de ces utilisateurs.
• L’assaillant est bien parvenu à obtenir une clé TLS qui, sous certaines circonstances extraordinaires, pourrait être utilisée pour attaquer un utilisateur singulier sur le web en utilisant une attaque spécialement ciblée et hautement sophistiquée de type Man In The Middle que nous détaillons plus bas. Ces clés n’ont pas pu et ne pourraient pas être utilisées pour déchiffrer le trafic chiffré de NordVPN sous quelque forme que ce soit.
• Deux autres fournisseurs VPN ont été touchés par des attaques lancées par le même assaillant. Nous ne croyons pas qu’il s’agisse d’une attaque ciblée contre NordVPN.
• L’incident a clairement montré que le serveur affecté ne contenait aucun log d’activité des utilisateurs. Pour prévenir tout incident similaire, entre autres moyens, nous chiffrons le disque dur de tout nouveau serveur que nous lançons. La sécurité de nos clients est notre plus haute priorité et nous continuerons encore et toujours à élever nos standards.

Voici l’histoire complète ainsi que plus d’informations techniques:

Il y a quelques mois, nous avons appris qu’un incident était survenu en Mars 2018 lorsqu’un serveur d’un datacenter situé en Finlande auprès duquel nous avions loué des serveurs avait été accédé sans autorisation. L’assaillant y est parvenu en exploitant un compte de système de gestion à distance non-sécurisé que le data center avait ajouté sans nous en informer. Le data center a effacé les comptes utilisateurs que l’intrus a exploité plutôt que de nous informer.

L’intrus n’a trouvé aucun journal d’activité des utilisateurs parce qu’ils n’existent pas. Il n’a pas pu découvrir l’identité, le nom d’utilisateur, ou le mot de passe des utilisateurs parce qu’aucune de nos applications ne se sert des informations créées par l’utilisateur pour son authentification.

L’intrus a bien trouvé et acquis une clé TLS qui avait déjà expiré. Avec cette clé, une attaque pourrait seulement être lancée sur internet contre une cible spécifique et nécessiterait un accès extraordinaire à l’appareil ou au réseau de la victime (par exemple un appareil préalablement compromis, un administrateur réseau malveillant, ou un réseau compromis). Une telle attaque serait extrêmement difficile à réussir. Expirée ou non, cette clé TLS ne pourrait dans tous les cas pas avoir été utilisée pour déchiffrer le trafic de NordVPN. Ce n’est pas son rôle.

Une fois que nous avons découvert l’incident, nous avons tout d’abord mis fin au contrat avec ce fournisseur et éliminé le serveur, qui était en opération depuis le 31 janvier 2018. Nous avons ensuite lancé immédiatement un audit interne complet de notre entière infrastructure. Nous devions nous assurer qu’aucun autre serveur ne pouvait être exploité de cette manière. Malheureusement, complètement passer en revue les fournisseurs et configurations de plus de 5000 serveurs autour du monde prend du temps. En conséquence, nous avons décidé que nous ne devrions pas informer le public avant que nous puissions être certains qu’une telle attaque ne pouvait pas être reproduite où que ce soit sur notre infrastructure. Enfin, nous avons encore amélioré nos standards concernant les data center présents ou futurs avec lesquels nous travaillons pour assurer qu’aucune brèche similaire ne puisse jamais survenir à nouveau.

Nous voulons que nos utilisateurs et le public comprennent précisément l’étendue de l’attaque et ce qui a été ou n’a pas été mis en danger. La brèche a affecté l’un de plus de 3000 serveurs que nous avions alors pour une période de temps limitée, mais ça n’est pas une excuse pour une erreur flagrante qui n’aurait jamais dû être commise. Notre but n’est pas de diminuer la sévérité ou l’importance de cette brèche. Nous aurions dû en faire plus pour filtrer les fournisseurs de serveurs peu fiables et assurer la sécurité de nos clients.

Depuis la découverte, nous avons pris toutes les mesures nécessaires pour améliorer notre sécurité. Nous nous sommes soumis à un audit de sécurité de nos applications, nous travaillons sur un second audit de notre politique de no-logs à l’heure actuelle, et nous préparons un programme visant à récompenser la découverte de bugs. Nous ferons tout pour maximiser la sécurité de tous les aspects de notre service, et l’an prochain nous lancerons un audit externe indépendant de l’ensemble de notre infrastructure.

Notre but ici est d’informer et d’éduquer le public au sujet de cette brèche. C’est la seule manière pour nous d’être capable de nous remettre de ce recul significatif et de rendre notre sécurité plus hermétique encore.

NOTE: article mis à jour le 25/10.