Revue de l’audit de sécurité de Mullvad VPN
(x41-dsec.de)- X41 a examiné l’application Mullvad VPN via un test d’intrusion en boîte blanche incluant l’accès au code source, et a également établi un modèle de menace léger
- Le périmètre de l’audit couvrait le code Android 2024.8-beta1, iOS 2024.8 et Desktop 2024.6, en partant du principe d’un fonctionnement sur cinq plateformes : Linux, Windows, macOS, Android et iOS
- Six vulnérabilités ont été découvertes lors des tests, mais l’application Mullvad VPN présente globalement un niveau de sécurité élevé au regard du modèle de menace du rapport
- Le problème le plus grave est une corruption mémoire due à une condition de concurrence dans le gestionnaire de signaux et à une violation de la sûreté temporelle, mais sa gravité est réduite car l’attaquant doit d’abord déclencher le signal via une autre faille
- Certaines vulnérabilités pouvaient entraîner une fuite d’informations d’identification utilisateur pour un attaquant sur le réseau local, ou permettre des attaques par canal auxiliaire dans certaines conditions, et Mullvad VPN AB a rapidement appliqué les correctifs
Périmètre de l’audit et caractéristiques de la cible
- X41 a réalisé un test d’intrusion en boîte blanche sur l’application VPN de Mullvad
- L’audit incluait l’accès au code source ainsi que l’élaboration d’un modèle de menace léger
- Les versions du code source audité étaient les suivantes
- L’application auditée est de grande taille et fonctionne sur cinq plateformes, ce qui rend l’audit plus difficile
- Les plateformes prises en charge sont Linux, Windows, macOS, Android et iOS
- Mullvad VPN fait l’objet d’audits réguliers, et la découverte de nouvelles vulnérabilités dans le code existant montre qu’un examen de sécurité continu reste nécessaire au vu de la complexité du produit
- Sur des cibles matures, les constats ont tendance à se déplacer vers des zones hors du contrôle direct ou du périmètre principal de l’équipe de développement de l’application
- Caractéristiques de fonctionnement du système d’exploitation
- Interactions entre différentes couches réseau et différents protocoles
Résultats des découvertes et évaluation de la sécurité
- Les tests de X41 ont mis au jour un total de six vulnérabilités
- L’application Mullvad VPN affiche un niveau de sécurité élevé selon le modèle de menace du rapport
- Pratiques de développement et modèles de conception sûrs
- Audits réguliers et tests d’intrusion
- Environnement d’exécution renforcé
- La vulnérabilité la plus grave est une corruption mémoire causée par une condition de concurrence dans le code du gestionnaire de signaux et par une violation de la sûreté temporelle
- Une fois le code du gestionnaire de signaux déclenché, les possibilités d’exploitation ne semblent pas faibles
- Toutefois, l’attaquant doit d’abord provoquer le signal via une autre faille, ce qui réduit la gravité globale
- D’autres vulnérabilités pouvaient permettre à un attaquant sur le réseau adjacent d’exfiltrer des informations sur l’identité de l’utilisateur, ou rendre possibles des attaques par canal auxiliaire révélant le site actuellement consulté par le client dans certaines conditions
- Les attaques par canal auxiliaire sont pour la plupart atténuées
- L’exception concerne des attaques au niveau du protocole résultant de la combinaison de plusieurs technologies, comme le NAT et les variantes récentes du protocole HTTP, ce qui dépasse le champ de contrôle de Mullvad VPN AB
- Les utilisateurs ayant des besoins plus élevés en matière de sécurité et de confidentialité peuvent envisager des techniques d’obfuscation à l’intérieur du VPN protégé ainsi que des services proxy
- Mullvad VPN AB a corrigé rapidement les problèmes identifiés, et l’audit a confirmé que les correctifs fonctionnaient normalement
1 commentaires
Avis sur Hacker News
Les problèmes relevés portent notamment sur l’absence de pile alternative pour les gestionnaires de signaux, l’utilisation de fonctions non sûres en contexte asynchrone, la fuite de l’adresse IP virtuelle de l’interface de tunnel, la désanonymisation via NAT, la désanonymisation via MTU, et le sideloading pendant l’installation.
Dans l’ensemble, c’est assez direct, et cela s’appuie beaucoup sur DAITA (défense contre l’analyse de trafic par IA) ; je ne l’ai pas encore complètement compris, mais cela semble valoir la peine d’être lu davantage : https://mullvad.net/en/vpn/daita
Même OpenSSH a eu un problème lié à cela https://blog.qualys.com/vulnerabilities-threat-research/2024..., et sans mécanisme explicite de marquage des fonctions (function coloring), il semble difficile de créer une bonne abstraction dans quelque langage que ce soit.
Peut-être qu’un langage fonctionnel pur comme Haskell pourrait le permettre.
L’utilisation de fonctions non sûres en contexte asynchrone est un problème courant, mais difficile à exploiter en pratique ; tout développeur ayant déjà manipulé des gestionnaires de signaux a probablement commis cette erreur au moins une fois à cause de problèmes de timing extrêmement difficiles à reproduire.
La fuite d’adresse ARP n’est pas vraiment un problème propre à Mullvad et n’est exploitable que sur le réseau local ; les attaques de désanonymisation s’appliquent à tous les VPN et peuvent être davantage atténuées, mais cela a un coût.
Le sideloading est probablement le problème le plus grave, mais il n’est pas exploitable seul.
Cela dit, avoir trouvé une vulnérabilité de corruption du tas dans un programme Rust réellement déclenchable est une bonne découverte.
En revanche, attribuer une gravité élevée à la vulnérabilité suivante me paraît relever de l’inflation des notes : elle semble théorique, sans preuve de concept, et ce n’est même pas une corruption mémoire.
La section distincte sur le modèle de menace est quelque chose que beaucoup de cabinets d’audit omettent dans leurs rapports.
Je suis certain que les auditeurs précédents comme Cure53, Assured et Atredis avaient établi au préalable un modèle de menace approprié avec Mullvad, mais s’il n’est pas explicitement présenté au lecteur, les résultats peuvent être mal interprétés.
Si la cible a son mot à dire sur l’audit ou sur les méthodes d’attaque, il est difficile d’éviter que les résultats soient biaisés en sa faveur.
La méthode la moins biaisée serait que la cible ne sache absolument pas ce que l’auditeur va faire.
Si Mullvad a participé à la méthodologie ou limité le périmètre des tests, les résultats n’ont de toute façon aucune valeur.
L’abandon de la prise en charge d’OpenVPN ne me plaît pas non plus, car j’ai quelques cas d’usage qui en ont besoin, donc je vais migrer ailleurs.
C’est dommage, parce que ce service a été bon pendant longtemps.
La suppression du port forwarding réduit fortement les abus à gérer, et n’affecte qu’une infime minorité d’utilisateurs très nerds.
J’utilise Mullvad pour les torrents depuis un moment ; les torrents avec peu de seeders mettent parfois longtemps à démarrer, mais finissent par se télécharger.
Pour des médias plus confidentiels, il faut parfois s’y prendre quelques jours à l’avance.
Honnêtement, je pense que je ne considérerais même pas un fournisseur qui ne prend pas en charge OpenVPN, donc je ne vois pas bien l’intérêt.
Pour une raison quelconque, sur mon routeur, cela fonctionne beaucoup mieux et de manière plus stable comme VPN site-à-site.
man wg).Cela fonctionne bien, et il est aussi possible de payer au mois en Bitcoin pour préserver son anonymat.
Ai-je mal compris quelque chose ?
Je ne cherche pas à cacher le fait que j’utilise parfois un VPN : mon FAI voit le tunnel, les sites web visités voient l’IP du VPN, et les flux réseau conservent l’heure, la durée, le volume transféré, etc.
L’utilisation même d’un VPN n’est pas un secret.
Je pense que la plupart des utilisateurs de VPN sont, comme moi, des gens ordinaires qui veulent protéger leur vie privée contre les régies publicitaires en ligne et les collecteurs de données.
Je ne souhaite ni n’attends de confidentialité vis-à-vis du fournisseur de VPN
De toute façon, je me connecte à leur service VPN depuis l’adresse IP de mon FAI domestique, avec un compte à mon nom
Quelle que soit la manière dont vous masquez le paiement du VPN, ils sauront qui vous êtes
Les techniciens, en particulier ceux de la sécurité, vont souvent trop loin sur ce genre de questions au point de devenir irréalistes, et donnent l’impression de s’éloigner des modèles de menace et des cas d’usage réels
Le court texte de James Mickens, « This World of Ours », traite bien ce sujet : https://www.usenix.org/system/files/1401_08-12_mickens.pdf
C’était l’application VPN la plus stable parmi celles que j’ai testées, et on peut l’utiliser sur jusqu’à 5 appareils par compte
S’ils ne conservent pas de logs comme ils l’affirment, quoi qu’ils sachent sur vous, l’IP demandée par la police pourrait avoir été utilisée par n’importe lequel de leurs milliers de clients, donc ils ne pourraient pas la transmettre aux autorités même s’ils le voulaient
Est-ce que je rate quelque chose ?
Il semble y avoir pas mal de baratin, et aussi une sorte d’idée selon laquelle un VPN « cool » devrait venir d’un pays scandinave, alors qu’en réalité ce n’est généralement pas le cas
Au mieux, elle n’a qu’un rapport périphérique avec l’article, et sa formulation est vague au point de laisser entendre que Mullvad ferait quelque chose de mal
Mullvad indique être basé en Suède ; est-ce que ce n’est pas le cas ? Ils publient aussi l’emplacement des serveurs et leurs propriétaires
Ils fournissent pas mal d’informations sur les raisons d’utiliser ou non un VPN, ne journalisent pas les données des clients, sont passés à une infrastructure uniquement en RAM, et proposent un tarif forfaitaire unique peu élevé
J’aimerais savoir ce qui relève exactement du baratin, et ce que vous voudriez qu’ils fassent différemment
Je ne comprends ni pourquoi cela devrait être le cas, ni pourquoi ce serait faux
Pour être juste, parmi les VPN fortement orientés confidentialité que je connais, le seul qui ne soit pas scandinave est à peu près ProtonVPN
Il y a quelques années, en utilisant Nord, j’ai découvert une défaillance silencieuse où l’application indiquait être connectée alors qu’en réalité elle ne l’était pas au VPN ; quand je l’ai signalé, on m’a répondu que c’était un problème connu et qu’il ne fallait pas s’inquiéter
À ma connaissance, ils n’ont pas publié d’avis de sécurité
Le fait qu’ils ne dépensent pas des sommes énormes en publicité sur YouTube ou sur des sites d’affiliation me rassure plutôt
Je préfère aussi qu’ils ne soient pas dans une juridiction qui sert de refuge à des entreprises douteuses
En résumé, j’aime bien parce qu’ils semblent corrects et avec moins de baratin
Je ne pense pas pouvoir faire confiance à PIA ou à des sociétés de ce genre
Je suis assez convaincu que ces blocages agressifs ne sont pas dus aux abus, mais au fait que les VPN posent un vrai problème au pistage et à l’extraction de données
Souvent, un serveur de sortie fonctionne avec l’un des deux mais pas avec les deux, ce qui me fait soupçonner une certaine coordination du blocage d’IP entre YouTube et Reddit pour rendre l’usage des VPN pénible et le décourager
Entraver le ping-pong des réseaux sociaux pour les utilisateurs de VPN me semble être une stratégie efficace pour influencer les comportements, et comme les deux sont de fait des monopoles naturels, ils ne risquent presque pas de perdre des utilisateurs en procédant ainsi
C’est un peu comme l’exploitation des bannières de cookies pour retourner l’opinion des gens contre les règles de confidentialité alors qu’elles servent l’extraction de données
Même beaucoup de techniciens croient que les bannières de cookies agaçantes sont la faute de l’UE, alors que dans la pratique il s’agit souvent de conformité malveillante, de mesures inutiles ou de pratiques franchement illégales
En tout cas, c’est vraiment agaçant, et cela ressemble à un aspect de l’enshittification générale du Web et du mécontentement qui grandit rapidement
On est pratiquement traité comme une persona non grata, et beaucoup de captchas ne sont en fait que des blocages, tout en semblant attendre de l’entraînement gratuit