Fabien Fontich

Bitwarden - SaaS vs Self-hosted

Bitwarden - Cloud centralisé vs auto-hébergé

La difficulté en sécurité ce n’est pas d’appliquer la plus extrême et complexe des solutions. Maintenir son propre gestionnaire de mots de passe, patcher le serveur, son OS, ses services, contrôler son exposition sur internet, ses backups, sa redondance, etc. C’est beaucoup de temps que vous préfèreriez assigner à des activités plus gratifiantes. C’est aussi une recommendation inaccessible pour 99% des personnes sur Terre.

Non, la difficulté en sécurité c’est d’appliquer le meilleur compromis pour se protéger sans détruire la productivité de l’utilisateur ou l’attraction du service. Dans ce sens, concernant les password vaults et la centralisation : le vecteur d’attaque contre lequel on souhaite se protéger est le vol de la database. Une seule attaque permettra de récolter beaucoup de données sensibles, un investissement de moyens élevé (ressources techniques, humaines, etc.) sera justifié et il est fort probable que le vol de votre vault ne soit qu’une affaire de temps. A ceci il faut ajouter le fait qu’un fournisseur de service n’est pas forcément au courant que les données ont fuité avant que l’attaquant ne fanfaronne ou que son système de monitoring ne le détecte, ce qui peut prendre plusieurs jours, semaines ou mois selon ses outils (SIEM, XDR, etc.).

Comment répondre à ce type de menace ?

Auto-hébergement (IaaS)

Première solution, héberger vous même votre vault. Ainsi, vous écartez une menace à forte puissance de frappe et une quasi certitude que votre vault sera dérobé un jour. Mais à quel prix ? Comme abordé en tout début, c’est une solution très contraignante mais pas seulement : si elle vous protège d’un vecteur d’attaque, elle en invite de nouveaux contre lesquels vous devrez vous protéger, chose habituellement gérée par le fournisseur de service avec de plus gros moyens que vous. L’auto hébergement ne vous protègera pas d’une faille dans nginx, docker, TLS, SSH, linux kernel, et les innombrables services de votre serveur qu’un bot de passage pourrait exploiter en un clin d’oeil dans les jours qui suivent la publication d’une RCE 0-day. Vous vous ferez néanmoins suer pour gérer votre propre serveur VPN ou bastion pour accéder au port 22 de votre serveur sans l’exposer sur internet, idéalement depuis un 2ème machine physique, paramétrer un fail2ban, gérer vos clés SSH, paramétrer le MFA, patcher les différents services régulièrement sans compter les updates du vault elles-mêmes qui pourraient s’avérer parfois plus complexes qu’un apt upgrade. Quid de la résilience en cas de perturbation de votre ligne ou plantage pendant vos vacances ? Quid du monitoring des logs pour vérifier une activité suspecte ? Etes-vous bien sûr de vouloir passer un weekend à restaurer un service planté suite à la mise à jour d’une dépendance ? La réponse est non ; c’est une perte sèche de temps.

Dernier point, cette solution ne vous protège pas plus des “supply chain attacks” que le cloud managé. Dans les 2 cas vous utiliserez les extensions et clients proposés par Bitwarden. Si l’un de ces éléments venait à être modifié par un attaquant, celui-ci récoltera votre mot de passe maitre ainsi que l’URL de votre serveur. Il n’aura même pas besoin de la base de données et pourra se connecter directement sur votre serveur par les voies normales pour exporter vos données tel que vous le feriez vous-même lorsque vous réalisé votre backup saisonnier.

Pour terminer sur les supply chain attacks, il est important de gérer le second facteur d’authentification via une autre application que votre gestionnaire de mot de passe. De la sorte si celui-ci est compromis, le second facteur n’est pas utilisable dans la foulée. L’authentification forte (MFA/2FA) est en effet la seule manière de se protéger efficacement de ce type d’attaque.

Cloud centralisé (SaaS)

Deuxième solution, laisser votre vault au sein d’un service managé, mais avec quelques précautions d’emploi qui visent à se protéger en cas de compromission de votre vault. Tout simplement. Alors comment se prémunir ?

1. utiliser un vault chiffré à 100%, c’est à dire avec la totalité des champs d’informations stockées de manière chiffrée (ce n’était pas le cas des vaults LastPass mais c’est le cas des vaults Bitwarden ou KeePass par exemple)

2. rendre le chiffrement bullet proof :

1. paramétrer un nombre d’itérations personnalisé de sorte que l’attaquant n’ait pas d’autre choix que de réaliser un bruteforce unique dédié à votre seul vault parmi la myriade de vaults dérobés. Si 80% des vaults ont le même nombre d’itérations, il est extrêmement probable que l’attaquant force ces vaults en premier lieu et laisse tomber ceux qui nécessitent une approche unique. En effet, une table de hashs doit être générée pour chaque nombre d’itérations. Il sera donc plus rentable de générer une table pour le nombre d’itération le plus fréquent soit très probablement celui laissé par défaut (100 000 cf. https://bitwarden.com/help/bitwarden-security-white-paper/).

2. dériver la clé de chiffrement à partir d’un mot de passe maitre robuste c’est à dire dont l’entropie est égale ou supérieure à 130bits pour une clé AES256. A ce stade il n’est pas nécessaire de se prémunir contre les bruteforce post-quantiques car ce n’est pas encore d’actualité et si votre vault s’envole dans la nature vous aurez eu quelques années pour changer vos mots de passe sur les services les plus sensibles (protégez également ces services avec du MFA pour être totalement serein au passage). Si toutefois votre mot de passe maitre est généré aléatoirement et non-mémorisé, autant y aller franco et partir sur du 42 caractères complexes (entropie 250bits = post-quantum resistant en AES256).

Que se passera-t-il en cas de compromission de votre vault avec cette solution ? Rien. Tout du moins absolument rien dans l’urgence. Vous irez simplement changer le mot de passe de vos services sensibles sans craindre de danger immédiat :

- messagerie (GMail, Outlook, Proton, Wanadoo, AOL, Caramail, Lycos, Voilà, etc.)
- sites qui hébergent votre numéro de CB parce que vous y commandez 2 fois par semaine et que le one-tap to order c’est quand même vachement pratique (Amazon, Auchan Drive, etc.)
- vos quelques sites administratifs officiels liés à votre véritable identité (partenaires France Connect) - vos réseaux sociaux
- le PIN de vos banques en ligne si vous les stockez dans le vault et… voilà.

Quels bénéfices pour cette seconde solution ? Et bien vous pouvez continuer à profiter de votre temps libre et d’un service maintenu pour vous tant en terme de sécurité qu’en mises à jour de fonctionnalités. Vous n’êtes pas dépendant de votre OS et de vos navigateurs car chacun bénéficie d’une extension ou d’un client riche pour fixe ou mobile. Vous n’avez pas à vous soucier de compatibilité ou de trust en utilisant des clients tiers.

Pour finir Bitwarden est open source, son code est accessible à tous et régulièrement vérifié / audité. Une supply chain attack reste possible donc pensez bien à activer le MFA sur vos comptes sensibles (cf. liste plus haut).

Wake On Lan issues recap and how to resolve them

Use case resolved here: waking up a computer on your home LAN from internet involving a Wireguard VPN and Windows devices above Windows 7 (i.e. Win10 and Win11).

I feel like it's my duty to write this article so Google can find it and suggest it to every one who like me was for the previous year: having a hard time with Wake On Lan (WOL).

WOL is useful for people working away from home while still wishing to access his computer/server using remote control protocols such as RDP. Most of the data nowadays in stored in "someone else computer" also know as " the Cloud". So it is not the most common scenario since you won't need to turn on your computer at home to reach your data but simply have to connect to your OneDrive / Google Drive / Box / Dropbox to get that personal document you have to print at work.

Anyway, in my scenario I have a VPN gateway hosted at home to reach my LAN from internet (work, while traveling, etc.). Since there is no way I open my RDP port on the internet (0-days, ya know) I chose to use a VPN gateway to grant me access to my home network. That VPN server is a raspberry running Wireguard. It used to be OpenVPN but years after years Wireguard earnt my trust while being so much faster and lighter on hardware ressources (smartphone battery) than OpenVPN.

So here comes one thing you have to know while testing WOL over a VPN: WOL is layer 2, Wireguard is layer 3. So there is no way your magic packet will go through the VPN gateway and reach the sleepy device.

While the previous point is quite a hint when testing your WOL setup, you also have to know that WOL has evolved from Windows 7 to Windows 8. I have found very few articles on the web about this (hence this article) and I wish I knew that years ago. Windows 7 was fine with waking up turned off computers. A setting on a your network card and the BIOS allowed the network interface to stay on while the computer was off. A small part the the motherboard dedicated to the network was kept awake and it allowed WOL to work on computers whatever their status was.

It changed in Windows 8 and therefore Windows 10 and 11.

WOL will only work on devices in sleep modes (until hibernate aka S4 sleeping state). Shut down power state is not part of the fair. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/system-sleeping-states

so here we are, if you are away from home and wish to wake up a Windows 10/11 computer you want to access through VPN then RDP, you have to know all the above to understand it will only work if:

1) Your computer is in one of the sleep modes only.

2) The device broadcasting the magic packet is on you LAN and not the remote device. For this specific point I have chosen to use etherwake on the very same raspberry I use to host Wireguard.

Therefore this is how I proceed to connect to my home server from the internet (e.g. my smartphone connected using 4G/LTE or a buddy's WiFi):

1) I launch Wireguard and connect to my LAN

2) I connect to my raspberry using SSH (Termius is great on iOS) and launch that command using etherwake: wakeonlan xx:xx:xx:xx:xx:xx (where xx:xx... is you sleepy device's network interface mac address)

3) Wait 5-10s for the computer to wake up then connect using RDP (RD Client is doing a great job on iOS).

This is it.

Of course I won't explain how to configure WOL on your network interface and in your BIOS / UEFI. If you need that well Google has plenty of articles to suggest while it has no article about how "to WOL" from Internet.

One last thing: some ISP routers offer the possibility to forward magic packets to your LAN from internet. In this scenario you only have to send the magic packet to your public IP address. This could be a possibility but I prefer my way. Why? Because most ISPs will offer you a dynamic IP so you would have to rely on a DNS and a script to update the DNs record. I actually such a script running every 5min at home because I have a dynamic IP but I use this for other reasons and using this for WOL sounds unreliable. And if you IP is static, it's still your ISP router i.e. something you don't control as opposed to your raspberry.