KeePass est-il troué ?

KeePass est-il troué ?

Keep cool, ne nous affolons pas et réfléchissons

113

KeePass est-il troué ?

Bon, ça commence à bien faire : après Boxcryptor qui se fait racheter et, de facto, abandonner sous sa forme actuelle, voici qu’un autre de nos outils de sécurité préférés est sous le feu des critiques : KeePass, le gestionnaire de mots de passe (nous parlons de la version originale sous Windows) !

Une vulnérabilité a été déclarée sous la référence CVE-2023-24055, et déjà les actualités fleurissent en nous suggérant qu’une faille critique affecte notre bel outil de sécurité.

Critique, vraiment ?

Déjà, à l’heure de la publication de cet article, aucun score de criticité n’a été officiellement calculé pour cette vulnérabilité. Pour en savoir un peu plus, vous pourrez jeter un œil dans le Mag #4 où on vous explique tout ça, mais sachez que ce score (CVSS) est une note sur 10, 10 étant la plus grave.

Donc tout ce qui a pu être publié avant ce week-end indiquant que KeePass était frappé d’une faille critique est prématuré, aucune évaluation n’ayant été faite à cette date (on suivra évidemment l’évolution de la situation).

Or, et le fait est plutôt rare lors de publication de CVE, une mention « disputed » apparaît, indiquant que cette vulnérabilité n’est pas clairement établie. Un tel cas de figure peut se produire quand un problème de sécurité apparaît à l’usage d’un produit, mais qu’il n’est pas certain que le produit soit directement en cause. En l’occurrence, KeePass a déjà eu son lot de « failles » dont la cause provenait de son environnement.  Comme l’indique l’auteur de KeePass : « KeePass cannot magically run securely in an insecure environment » (KeePass ne peut pas comme par magie fonctionner en toute sécurité dans un environnement non sécurisé).

Par exemple, en 2019, plusieurs gestionnaires de mots de passe avaient été épinglés pour ne pas effacer de la mémoire vive des mots de passe utilisés. Cela ne concernait pas le mot de passe maître, mais uniquement les mots de passe gérés. Sauf que, sous Windows, un programme n’avait pas de moyen de réaliser cette opération (en tout cas à l’époque).

Le problème ne venait pas tant des gestionnaires de mots de passe que du système d’exploitation sous-jacent. Sous Windows, si la mémoire virtuelle est utilisée, sachez qu’elle ne s’efface pas automatiquement à l’extinction de la machine : il faut parfois le préciser dans les paramètres de Windows, ce qui est hors de portée d’un programme « normal » (et heureusement). Vous pouvez avoir un aperçu du mode opératoire ici.

D’autres critiques avaient été émises sur la gestion du presse-papier, mais KeePass fait partie des bons élèves de ce côté. Il va même jusqu’à effacer un mot de passe du presse-papier après un délai de 10 secondes (tant que CTRL+C est réalisé avec un mot de passe non affiché dans KeePass : s’il est affiché en clair et copié via le mécanisme de copie gérée par Windows, KeePass perd le contrôle de la donnée).

KeePass
KeePass prend en compte la problématique du presse-papier

Le coupable présumé

Premier point : KeePass permet l’utilisation de plugins, comme de nombreux outils modernes : si vous utilisez un CMS tel que WordPress, vous en connaissez bien le principe. Vous savez également que généralement, lorsqu’on crie à la vulnérabilité critique dans WordPress, il s’agit la plupart du temps d’une faille dans un plugin, qui n’est donc pas dans le cœur de l’outil WordPress : il est géré par un tiers, et n’est pas inclus par défaut dans une distribution native.

KeePass est donc aussi sensible à cette problématique, et il incombe à l’utilisateur de savoir si le plugin qu’il souhaite utiliser est sûr ou non. À défaut, savoir s’il est capable de gérer le risque induit par l’utilisation d’un bout de code écrit par un tiers, par exemple en se protégeant via des solutions de sécurité adaptées (pare-feu applicatif, anti-virus, solution spécifique comme WordFence en ce qui concerne WordPress).

KeePass

Maintenant, KeePass propose aussi un mécanisme de triggers, justement cités comme un des éléments clés dans le CVE :

« KeePass jusqu’à la version 2.53 [la dernière en date, ndlr] (avec une installation par défaut) permet à un attaquant, disposant d'un accès en écriture au fichier de configuration XML, d'obtenir les mots de passe en clair en ajoutant un trigger d'exportation. REMARQUE : la position du fournisseur est que la base de données de mots de passe n'est pas destinée à être sécurisée contre un attaquant disposant de ce niveau d'accès en local sur le PC ». 

Voyons leur fonctionnement. Allons dans l’interface : on commence tout naturellement par lui donner un petit nom.

KeePass

On choisit ensuite un événement déclencheur, parmi la liste proposée (qui est donc limitative) :

KeePass

Et pour terminer, on choisit l’action voulue à déclencher, également dans une liste prédéfinie :

KeePass

Parmi ces actions, vous pouvez exporter la base des mots de passe dans différents formats, dont certains en clair. 

Une fois votre trigger créé, vous pouvez le retrouver sous forme de paramètre dans un fichier de configuration situé dans C:\Users\User Name\AppData\Roaming\KeePass\KeePass.config.xml. Ici un exemple où on se contente d’afficher une fenêtre d’information (à l’ouverture de l’outil) :

KeePass

Ainsi, on se retrouve avec un fichier texte de configuration, situé dans le domaine des données de l’utilisateur actif (sous Windows). Un petit coup de WordPad pour le modifier :

KeePass

Le résultat est impitoyable, à l’ouverture de KeePass :

KeePass

Nous avons donc bel et bien modifié la configuration avec un simple edit du fichier, à partir des droits de l’utilisateur courant. On peut s’aider du support en ligne (Configuration - KeePass) pour chercher tout ce qu’il est possible de faire par cette méthode. Cela peut également se scripter : une fois les droits utilisateurs acquis, on peut faire modifier le fichier de configuration de KeePass avec les actions que l’on veut.

Est-ce inquiétant ?

Faisons nous-même une évaluation du score de gravité CVSS, en prenant les hypothèses les plus graves en termes d’impact (en partant du principe qu’une fois l’ensemble des mots de passe acquis, on peut faire ce qu’on veut dans l’univers de l’utilisateur).

Il faut garder à l’esprit deux éléments importants : d’abord, il faut un compte local pour pouvoir éditer le fichier de configuration, et ensuite, il faut une interaction utilisateur pour que cela fonctionne.

Les triggers de KeePass fonctionnent une fois l’outil lancé. Tout dépend ensuite de l’usage qu’on fait de KeePass, par exemple si on le laisse ouvert en tâche de fond, etc. Mais on imagine qu’un attaquant voudra exporter le fichier dès l’ouverture de KeePass et qu’il aura pu modifier le fichier de configuration avant ouverture. Avec ces hypothèses, on arriverait à un score de gravité de 7,3 sur 10, ce qui est élevé. Pour rappel, log4j atteignait 10.  

KeePass

Le nœud de l’affaire consiste à savoir à quel point il est compliqué d’obtenir le droit utilisateur permettant la modification du fichier de configuration. Il faut donc une autre attaque pour pouvoir exploiter la faille de KeePass. C’est en partie ce qui explique la note de gravité que nous calculons : il est nécessaire d’avoir un accès local (les privilèges de l’utilisateur de KeePass) mais, une fois obtenu, l’exploitation de la vulnérabilité est extrêmement simple.

Que peut-on faire ?

En tant qu’utilisateur de KeePass : pas grand-chose. Pour les plus paranoïaques, un contrôle d’intégrité de fichiers qui hurle si une modification est apportée au fichier de configuration est une possibilité, mais pas des plus simple pour l’utilisateur lambda. C’est très gênant, car on dépend alors de la réaction de l’éditeur du produit.

Autre voie possible, via l’éditeur, donc : ajouter un avertissement dans KeePass lorsque des triggers déclenchent des actions sensibles comme un export de la base.

Dans le contenu de la CVE, il est indiqué que l’auteur (Dominik Reichl) pense que si un attaquant possède les privilèges de modification du fichier de configuration, il aura de toute façon une multitude d’autres moyens d’arriver à ses fins. Il a également déjà répondu au risque de modification de ce fichier de configuration ici : Enforced Configuration - KeePass.

Il existe en effet des possibilités d’améliorer les choses, mais la vulnérabilité CVE-2023-24055 repose essentiellement sur le fait que l’utilisateur n’a pas conscience de l’export, réalisé automatiquement, sans avertissement. Or un message d’avertissement semble une bonne solution, à la fois simple à mettre en œuvre, et permettant d’éviter le principal danger, à savoir l’exécution transparente de l’export.

Il y a des discussions en ce moment sur le forum de KeePass, mais même si la « faute » est du côté de Windows, s’il existe un moyen simple et efficace de contrer la menace, alors pourquoi ne pas le mettre en œuvre, surtout que la marge de manœuvre du côté des utilisateurs est quasi-nulle ?

Comme beaucoup de spécialistes dans ce domaine, Dominik Reichl ne semble pas vouloir endosser la responsabilité des autres. S’il a raison sur le principe, un logiciel proposant de sécuriser les mots de passe de ses utilisateurs ne peut pas faire comme si la problématique n’existait pas. C’est une des bases de la défense en profondeur, concept qu’il faut désormais intégrer tant la surface d’attaque sur un PC moderne est vaste.

Commentaires (113)


Merci pour cet article bien détaillé.
Utilisant KeePass depuis des années et faisant la promotion de son utilisation, je suis assez perplexe par les réponses de son créateur sur le sujet.



Sur le fond, il n’a pas tord mais il devrait changer le paradigme sur les exports en forçant la demande du mot de passe de façon systématique et que cela ne soit pas possible de changer ce comportement en configuration.



Une autre solution serait que le fichier de base de donnée puisse embarquer aussi une partie de la configuration qui serait plus prioritaire.



Je préfère la 1ère solution car simple à mettre en œuvre et tout le monde en profite.


mais il faut comprendre la réaction de Reichl: on part du principe que l’acteur malveillant a accès à la machine. rien ne l’empêche de mettre un keylogger pour récupérer la phrase de passe maitre et par conséquent d’obtenir un accès à la base en clair.
pourquoi ne pas effectivement générer une alerte. mais il faut à ce moment que ça soit en dur dans le programme, et pas un élément de configuration.
C’est pas la 1ere faille signalée dans keepass ou un de ses plugins, mais si l’attaquant a accès à la machine, c’est échec et mat.


Bonjour,
Savez-vous si KeePassXC est également touché ou si cela ne concerne que KeePass ?



eupalynos a dit:


Savez-vous si KeePassXC est également touché ou si cela ne concerne que KeePass ?




Non, il n’a pas ce système de trigger.
Ceci dit il a aussi un fichier de config avec quelques infos en clair donc peut être qu’on peut envisager une variante de cette attaque mais il me semble aussi qu’il stock une partie des config dans la base (par exemple les navigateur autorisé a y accéder).


Merci pour cet article clair et complet :)


Mouais… un peu trop facile de se défendre sur le fait que c’est une faille dont on n’est pas responsable. La sécurité doit se faire en profondeur et en multi-couche. Si l’auteur peut faire en sorte de protéger ce fichier ou a minima d’avertir quand il est modifié c’est quand même mieux.


Bonjour, merci pour cet article.
De ce que j’en comprends à un moment il faut créer un trigger sur l’archive concernée Keepass concernée.
Mais faut-il y être authentifié ? Ou n’importe quel XML correctement forgé peut servir de trigger à l’insu de Keepass ?
D’ailleurs quels sont vos usages des triggers ?


Je n’ai vu personne dans les commentaires disent qu’ils utilisent les triggers, je vais être le premier : au boulot nous avons plusieurs KeePass selon les projets et les équipes + chacun a son KeePass perso, avec mdp des autres KeePass dedans. Les triggers ici me servent à ouvrir tous les autres dès que j’ouvre mon perso (ce qui me permet d’économiser 60 secondes chaque matin…)


Ailothaen

Je n’ai vu personne dans les commentaires disent qu’ils utilisent les triggers, je vais être le premier : au boulot nous avons plusieurs KeePass selon les projets et les équipes + chacun a son KeePass perso, avec mdp des autres KeePass dedans. Les triggers ici me servent à ouvrir tous les autres dès que j’ouvre mon perso (ce qui me permet d’économiser 60 secondes chaque matin…)


Merci du retour


Pourquoi ne pas désactiver les Triggers par défaut ? est-ce quelque chose de beaucoup utilisé ?



(reply:2117416:Xanatos)
Oui, il faut avoir un compte local permettant d’écrire sur le fichier .xml de configuration (d’ailleurs ça rentre en ligne de compte pour le calcul de la gravité CVSS). Ensuite il n’est pas difficile de rajouter ce qu’il faut pour créer un trigger (les paramètres sont assez simples). KeePass n’active aucun trigger par défaut, mais il suffit de pouvoir écrire dans ce fichier pour le faire…



Jean_G


(reply:2117416:Xanatos)
Oui, il faut avoir un compte local permettant d’écrire sur le fichier .xml de configuration (d’ailleurs ça rentre en ligne de compte pour le calcul de la gravité CVSS). Ensuite il n’est pas difficile de rajouter ce qu’il faut pour créer un trigger (les paramètres sont assez simples). KeePass n’active aucun trigger par défaut, mais il suffit de pouvoir écrire dans ce fichier pour le faire…



Disons que je sous entendais : pourquoi ne pas supprimer cette fonctionnalité ? D’où ma question de : qui s’en sert et pourquoi ? ^^


Jean_G


(reply:2117416:Xanatos)
Oui, il faut avoir un compte local permettant d’écrire sur le fichier .xml de configuration (d’ailleurs ça rentre en ligne de compte pour le calcul de la gravité CVSS). Ensuite il n’est pas difficile de rajouter ce qu’il faut pour créer un trigger (les paramètres sont assez simples). KeePass n’active aucun trigger par défaut, mais il suffit de pouvoir écrire dans ce fichier pour le faire…



Merci pour l’éclaircissement.



hellmut a dit:


si l’attaquant a accès à la machine, c’est échec et mat.




Je suis d’accord sur le fond mais là c’est vraiment beaucoup trop simple. On peut laisser quelqu’un faire des trucs sur son PC mais sans pour autant vouloir qu’il puisse déchiffrer un keepass easy peasy. On parle d’une solution de sécurité, défense en profondeur toussa…


oui je suis d’accord que la simple modification d’un fichier de config ouvert aux 4 vents est trop facilement accessible pour n’importe qui/quoi a accès à la machine.


Je sais pas si l’article est suffisamment clair, en tout cas je suis pas sur de comprendre. Est ce que quelqu’un qui récupère le fichier database est capable d’exporter en clair sans avoir taper le mdp principal ?
Ou est ce que il faut s’infiltrer sur un ordi de quelqu’un, avoir les droits en écriture pour modifier le fichier xml de config de la personne, et attendre que cette personne tape son mdp ?



Et est ce que ça serait possible d’avoir des captures d’écrans lisible svp, notamment la 7 qui fait genre 50pxl de haut…


Il faut avoir accès au PC et attendre que la personne entre son MDP pour que la BDD soit exportée dans un fichier en clair. Puis récupérer ce fichier export.



Personnellement que comprend les deux points de vue. Les trigger dans le config c’est un peu trop facile. Mais en même temps, avec un accès en écriture on peut aussi lancer un keylogger, potentiellement modifier directement l’executable keypass (Et donc un attaquant peut rebuild keypass et le modifier même si une correction est faite), etc etc.



Donc oui c’est une faille pourrie mais la corriger protège pas grand chose. Si la session est vérolée, c’est game over comme déjà dit.


YonX

Il faut avoir accès au PC et attendre que la personne entre son MDP pour que la BDD soit exportée dans un fichier en clair. Puis récupérer ce fichier export.



Personnellement que comprend les deux points de vue. Les trigger dans le config c’est un peu trop facile. Mais en même temps, avec un accès en écriture on peut aussi lancer un keylogger, potentiellement modifier directement l’executable keypass (Et donc un attaquant peut rebuild keypass et le modifier même si une correction est faite), etc etc.



Donc oui c’est une faille pourrie mais la corriger protège pas grand chose. Si la session est vérolée, c’est game over comme déjà dit.


Ok merci.
Donc “it’s not a bug, it’s a feature”


Quand t’as base Keepass est ouverte, tu as une fonction d’export en clair.



Il y a une fonctionnalité de “trigger” aussi, quand certains pré-requis sont remplis, cela effectue une action, donc si j’ai compris, ça “trigger” l’export en clair.



Le problème n’est pas sur les clients alternatifs pour les bases kdbx comme KeepassXC car pas de fonction de trigger.



Je pense que quelqu’un qui a accès à l’ordinateur modifie le fichier de configuration (et donc pas la base elle-même) pour ajouter un trigger et déclencher cet export (quand tu déverrouille ta base par exemple), du coup c’est les modifications des fichiers de configuration Keepass que tu veux surveiller et avoir une alerte.



Ce qui me parait bizarre, c’est que j’avais déjà entendu parler de cette méthode (export en clair) pour récup les infos et que seulement maintenant que ça sort.


Je comprends la position de l’auteur. Ce n’est pas un bogue (pas une erreur de codage). Il faut un accès à la machine, avec un compte.



A ce niveau là, autant crier à la faille de sécu taille XXL pour Firefox par exemple, et sa fonctionnalité de stockage des identifiants et mot de passe : il n’y a même pas besoin d’attendre l’interaction d’un utilisateur ni de fichier de configuration à modifier, il suffit d’aller dans les paramètres pour voir les couples identifiants / mot de passe ! Chrome a au moins le mérite de redemander le mot de passe de l’utilisateur de la session.



Pour en revenir à l’auteur de KeePass, même si ce n’est pas sa faute, afficher une volonté et proposer un mécanisme pour permettre de bloquer ce type d’attaque ne ferait que renforcer l’image du logiciel…


S’il y a un mot de passe maître (facultatif il est vrai mais je crois que c’est le cas aussi pour Chrome, à confirmer), Firefox le redemande aussi avant d’afficher les mots de passe enregistrés donc ça reste au même niveau pour tout le monde..


Triton

S’il y a un mot de passe maître (facultatif il est vrai mais je crois que c’est le cas aussi pour Chrome, à confirmer), Firefox le redemande aussi avant d’afficher les mots de passe enregistrés donc ça reste au même niveau pour tout le monde..


Sur mobile il faut le mot de passe (ou empreinte, …).



Mais sur desktop si la session est ouvert on fait ce que l’on veut. (il est peut être possible d’ajouter une sécurité



Pour chrome (desktop) il faut le mot de passe (ou autre méthode d’identification).


misocard

Sur mobile il faut le mot de passe (ou empreinte, …).



Mais sur desktop si la session est ouvert on fait ce que l’on veut. (il est peut être possible d’ajouter une sécurité



Pour chrome (desktop) il faut le mot de passe (ou autre méthode d’identification).


Sur PC, Firefox demande le mot de passe principal une seule fois par session pour l’utilisation d’un mot de passe ou l’affichage la liste des identifiants enregistrés.
Mais pour avoir accès aux mots de passe en clair dans la liste des identifiants enregistrés, il demande le mot de passe principal à chaque fois.


Mihashi

Sur PC, Firefox demande le mot de passe principal une seule fois par session pour l’utilisation d’un mot de passe ou l’affichage la liste des identifiants enregistrés.
Mais pour avoir accès aux mots de passe en clair dans la liste des identifiants enregistrés, il demande le mot de passe principal à chaque fois.


Je viens de vérifier, et c’est configurable. Il faut aller dans les options et activer l’utilisation d’un mot de passe principal.



Et je viens de trouver dans la documentation la ligne suivante :




Using a master password is not selected by default; you will need to set one in the Password Manager…




Traduction :




L’utilisation d’un mot de passe principal n’est pas activé par défaut. Vous devez en renseigner un dans le Gestionnaire de Mot de Passe…




Voilà, donc tout est dit : par défaut, Firefox n’est pas du tout sécurisé pour la gestion des mots de passe.


fdorin

Je viens de vérifier, et c’est configurable. Il faut aller dans les options et activer l’utilisation d’un mot de passe principal.



Et je viens de trouver dans la documentation la ligne suivante :




Using a master password is not selected by default; you will need to set one in the Password Manager…




Traduction :




L’utilisation d’un mot de passe principal n’est pas activé par défaut. Vous devez en renseigner un dans le Gestionnaire de Mot de Passe…




Voilà, donc tout est dit : par défaut, Firefox n’est pas du tout sécurisé pour la gestion des mots de passe.


J’avais complètement zappé, merci. :inpactitude:


Mihashi

Sur PC, Firefox demande le mot de passe principal une seule fois par session pour l’utilisation d’un mot de passe ou l’affichage la liste des identifiants enregistrés.
Mais pour avoir accès aux mots de passe en clair dans la liste des identifiants enregistrés, il demande le mot de passe principal à chaque fois.


La même que pour fdorin, les mots de passe sont accessibles facilement si ma session est déverrouillée.



Du coup si tu connais l’option pour qu’il y ait une demande l’identification de la session pour afficher les mots de passe en clair je prends. (le mot de passe principal est unique à chaque machine)



Sur chrome il demande le pass de la session. Firefox sur windows c’est un truc à part


misocard

La même que pour fdorin, les mots de passe sont accessibles facilement si ma session est déverrouillée.



Du coup si tu connais l’option pour qu’il y ait une demande l’identification de la session pour afficher les mots de passe en clair je prends. (le mot de passe principal est unique à chaque machine)



Sur chrome il demande le pass de la session. Firefox sur windows c’est un truc à part


Sous chrome, il ne me demande rien du tout, les mots de passe sont accessibles directement en clair.
Mais je ne suis pas sous windows.




misocard a dit:


Du coup si tu connais l’option pour qu’il y ait une demande l’identification de la session pour afficher les mots de passe en clair je prends. (le mot de passe principal est unique à chaque machine)




Session windows (elle unique à chaque machine aussi, hein) ?
Regardes du côté de about:config puis signon.management.page.os-auth.enabled



Sinon avec un compte firefox, c’est peut-être possible d’avoir le même mot de passe partout (j’en sais rien, c’est à tester).


Mihashi

Sur PC, Firefox demande le mot de passe principal une seule fois par session pour l’utilisation d’un mot de passe ou l’affichage la liste des identifiants enregistrés.
Mais pour avoir accès aux mots de passe en clair dans la liste des identifiants enregistrés, il demande le mot de passe principal à chaque fois.


pas réellement de débat puisque sans passe maitre un simple passage de firefox_decrypt sur le dossier de profile permet d’exporter tous les mots de passe stocké


misocard

Sur mobile il faut le mot de passe (ou empreinte, …).



Mais sur desktop si la session est ouvert on fait ce que l’on veut. (il est peut être possible d’ajouter une sécurité



Pour chrome (desktop) il faut le mot de passe (ou autre méthode d’identification).


Je parlais sur Desktop (je n’enregistre pas les mots de passe sur mobile), le mot de passe maître est nécessaire pour lire le mot de passe (pas pour l’authentification sur le site).


Je comprends l’éditeur et il a raison sur le fond. Néanmoins, je rendrai non configurable l’obligation de saisie pour l’export de base en clair qui est une opération à risque.



eglyn a dit:


Disons que je sous entendais : pourquoi ne pas supprimer cette fonctionnalité ? D’où ma question de : qui s’en sert et pourquoi ? ^^




Tout pareil, je ne connaissais pas cette fonctionnalité, utilisant keepassXC.
En tout cas je comprends que cela en alerte plus d’un.



YonX a dit:


Il faut avoir accès au PC et attendre que la personne entre son MDP pour que la BDD soit exportée dans un fichier en clair. Puis récupérer ce fichier export.



Personnellement que comprend les deux points de vue. Les trigger dans le config c’est un peu trop facile. Mais en même temps, avec un accès en écriture on peut aussi lancer un keylogger, potentiellement modifier directement l’executable keypass (Et donc un attaquant peut rebuild keypass et le modifier même si une correction est faite), etc etc.



Donc oui c’est une faille pourrie mais la corriger protège pas grand chose. Si la session est vérolée, c’est game over comme déjà dit.




Je ne connais pas bien Windows, mais ajouter un keylogger sur macOS n’est pas transparent (il faut une autorisation supplémentaire de l’utilisateur, tout comme il faut explicitement autoriser le programme à accéder aux documents).
J’imagine qu’un système similaire est disponible sur Windows.


Tu imagines mal.
Et c’est pour ça que Keepass permet de taper sa clef en “secure mode”, qui interdit tout keylogger logiciel.


patos

Tu imagines mal.
Et c’est pour ça que Keepass permet de taper sa clef en “secure mode”, qui interdit tout keylogger logiciel.


Je n’ai jamais tenté mais je suis 99% sûr qu’il est assez facile de contourner le “secure mode” (c’est comme ça qu’ils l’appellent ?).
Son problème étant qu’il repose sur le même système qu’UAC utilise depuis Vista, et winlogon sûrement depuis nt 3.5 (et certainement depuis 2000, j’ai écrit des programmes qui l’utilisaient sous cet OS).
La différence avec UAC et Winlogon ? Eux ne s’exécutent pas avec les droits utilisateurs.



Ceci dit, pour ma part, je l’active. Je regrette que d’autres programmes (genre le client RDP, explorer pour les accès réseaux, ou puisque quelqu’un le mentionnait, la demande mot de passe de session dans Chrome, même si pour autant que je sache elle n’émane pas de Chrome) demandent la saisie de mot de passe compte utilisateur sur le “desktop” principal.


xlp

Je n’ai jamais tenté mais je suis 99% sûr qu’il est assez facile de contourner le “secure mode” (c’est comme ça qu’ils l’appellent ?).
Son problème étant qu’il repose sur le même système qu’UAC utilise depuis Vista, et winlogon sûrement depuis nt 3.5 (et certainement depuis 2000, j’ai écrit des programmes qui l’utilisaient sous cet OS).
La différence avec UAC et Winlogon ? Eux ne s’exécutent pas avec les droits utilisateurs.



Ceci dit, pour ma part, je l’active. Je regrette que d’autres programmes (genre le client RDP, explorer pour les accès réseaux, ou puisque quelqu’un le mentionnait, la demande mot de passe de session dans Chrome, même si pour autant que je sache elle n’émane pas de Chrome) demandent la saisie de mot de passe compte utilisateur sur le “desktop” principal.


Oui, rien n’est parfait.
Pilote logiciel foireux / Vérolage USB / Firmware modifié / UEFI compromise



Mais ça aide quand même pas mal je trouve ;) Parce qu’aujourd’hui, hormis un piratage ciblé en bonne et due forme, c’est essentiellement du vérolage niveau utilisateur qu’on trouve.


patos

Oui, rien n’est parfait.
Pilote logiciel foireux / Vérolage USB / Firmware modifié / UEFI compromise



Mais ça aide quand même pas mal je trouve ;) Parce qu’aujourd’hui, hormis un piratage ciblé en bonne et due forme, c’est essentiellement du vérolage niveau utilisateur qu’on trouve.


Tout à fait d’accord, je suis content de l’avoir même si je n’ai jamais eu de ransomware (et pas de virus/attaque détectée en plus de 15 ans, les antivirus se contente juste de virer MES programmes à cause de leur heuristiques).



Après ce qui m’embête c’est :




  • Moins de 10 minutes de réflexion pour imaginer comme t contourner.

  • 1h pour l’implémentation (ça inclus la création d’un truc qui chiffre les fichiers en masse pour que l’anti-ransomware le détecte, puis l’ajout de la méthode pour passer inaperçu, avec arrêt à l’étape 13 de ce que j’avais imaginé puisque succès)

  • J’ai contacté l’éditeur, aucune réponse. Bien sûr il ne s’agit pas d’une vulnérabilité.


Un fichier (comme ce XML) peut être lu ou écrit si une autre application vulnérable (ex: un navigateur, un lecteur PDF dont le code ne présume pas que le contenu des fichiers peut être malicieux) permet de le faire sans qu’un attaquant ait accès directement à la machine. Les attaques peuvent se baser sur plusieurs failles (ex: remote code execution + élévation de privilège).



fdorin a dit:



A ce niveau là, autant crier à la faille de sécu taille XXL pour Firefox par exemple, et sa fonctionnalité de stockage des identifiants et mot de passe : il n’y a même pas besoin d’attendre l’interaction d’un utilisateur ni de fichier de configuration à modifier, il suffit d’aller dans les paramètres pour voir les couples identifiants / mot de passe ! Chrome a au moins le mérite de redemander le mot de passe de l’utilisateur de la session.




Ce n’est plus le cas, dans Firefox il taper son mot de passe de la session windows pour afficher les mots de passe stocké.



Ce qui me dérange c’est que
Keepass a été audité par l’ANSSI
Je trouve cela étonnant qu’une simple modification du fichier de configuration n’ai pas été relevé lors de l’audit (après je ne l’ai pas lu).



Ce n’est plus le cas, dans Firefox il taper son mot de passe de la session windows pour afficher les mots de passe stocké.




Ce n’est pas le comportement que j’ai. Aucun mot de passe de demandé sous Firefox, mais sous Chrome oui.



Pour l’audit de KeePass, oui, cela a été audité et certifié par l’ANSSI en 2011, pour la version 2.10 Portable. L’audit ne concerne que cette version spécifique, et je ne sais pas si cette version dispose des plugins et triggers en cause dans l’affaire.


à priori l’utilisation des triggers n’ait pas été testée dans le cadre de l’audit.
en tout cas je n’en trouve pas trace dans le rapport.



Sur le fond, il n’a pas tord mais il devrait changer le paradigme sur les exports en forçant la demande du mot de passe de façon systématique et que cela ne soit pas possible de changer ce comportement en configuration.




Tout à fait. C’est le comportement de 1Password par exemple : même déverrouillé, l’export doit être confirmé par le mot de passe maître.


Si j’ai suivi, pour que l’export fonctionne via le déclencher fonctionne, il faut que




  1. L’attaquant ait accès au PC et au fichier de configuration.

  2. La base de donnée doit être active, c’est à dire ouverte et affichée.



Si par hasard je récupère une base de donnée, aucun risque que via un déclencheur j’ouvre ou j’exporte la base sans connaitre sont mdp ?


Bonne question. Je suppose qu’il faut que la base soit ouverte, donc déchiffrée, ça paraît logique, mais aussi que le trigger se déclenche après l’ouverture de la base (par exemple l’attaquant devrait choisir l’événement “Open database file”)


Une solution la plus simple, est que cette conf soit stockée dans un format binaire uniquement lisible de l’exécutable, voir que de l’application. Pour le coup, toute modification nécessiterait un passage via l’exécutable.
A moins que l’auteur n’ait un cas pratique d’éditer ce fichier par un programme tiers.



Une vuln, oui (conception de merde).
Mais score à 10, juste une question de POV.
C’est équivalent de dire que bitlocker a une cvss de 10 parce que l’utilisateur peut enregistrer sa clé de sauvegarde dans sa session…


“security by obscurity is no security” et keepass est open source.


xlp

“security by obscurity is no security” et keepass est open source.


Rien à voir, je parle juste de conception d’architecteur applicatif.
Par exemple, que la conf soit stocké dans le kbdx.


Raknor

Rien à voir, je parle juste de conception d’architecteur applicatif.
Par exemple, que la conf soit stocké dans le kbdx.


Pas sûr de comprendre. Format binaire vs XML, ça change juste la difficulté de compréhension. Quant à ce que le fichier ne puisse être modifié que depuis l’exe ou l’application, je ne vois pas trop comment tu fais pour ça. Windows n’a pas de telle fonction de sécurité, en tout cas sur les applis Win32. Tout est basé sur l’utilisateur.



Mihashi a dit:


Sur PC, Firefox demande le mot de passe principal une seule fois par session pour l’utilisation d’un mot de passe ou l’affichage la liste des identifiants enregistrés. Mais pour avoir accès aux mots de passe en clair dans la liste des identifiants enregistrés, il demande le mot de passe principal à chaque fois.




Je peux confirmer que non. Sur mon poste, ce n’est absolument pas le cas. Il ne demande absolument aucun mot de passe, même après avoir redémarré l’ordinateur.



Idem pour l’ordinateur de mes parents, où j’ai malheureusement dû aller voir les mots de passe suite au décès de mon papa, pour accéder à différents services.



Je ne dis pas que ce n’est pas possible de configurer Firefox pour avoir un mot de passe pour accéder à cette fonctionnalité. Je constate juste que ce n’est pas le cas par défaut.


Ah bah oui, si tu n’as pas mis de mot de passe principal évidemment…



Mais c’est exactement pareil sous chrome.


Mihashi

Ah bah oui, si tu n’as pas mis de mot de passe principal évidemment…



Mais c’est exactement pareil sous chrome.


Sous Chrome, je n’ai rien fait, et je dois pourtant saisir le nom d’utilisateur et le mot de passe de ma session Windows. Donc non, ce n’est pas pareil ;)



KeePass cannot magically run securely in an insecure environment

Comme beaucoup de spécialistes dans ce domaine, Dominik Reichl ne semble pas vouloir endosser la responsabilité des autres




Quand on fait un TRA (Threat and Risk Assessment) on ne cherche pas à savoir qui est responsable: on évalue le niveau de risque.



De même, si c’est Keypass le vecteur de la menace, alors la meilleure mitigation à court terme c’est de supprimer keypass. Et la meilleure à long terme c’est de modifier la conception de keypass pour qu’il ne puisse plus servir de vecteur.



On peut trouver cela injuste, mais l’état de l’art sur la sécurité des systèmes se fiche de savoir si c’est injuste: on corrige au plus prêt du vecteur car c’est le maximum d’éfficacité.


Oui enfin, la menace initiale était l’utilisateur peu respectueux de l’utilisation des mots de passe et des politiques associées.



Sachant que les tendances actuelles tournent au 2FA.



Après, pour exploiter ce travers de keepass, il faut que l’attaquant accès à la session utilisateur:
-soit session laissée ouverte (pb utilisateur)
-db récupéré du disque (défaut de conf de chiffrement disque)
-accès à distance (autre vuln ou défaut de conf)
-accès aux fichiers utilisateurs non protégées (défaut de conf)
-code malveillant (défaut EDR?)
-RCE (défaut MCS)
-etc



Quel threat est prioritaire? keepass? ou le fait qu’un autre défaut l’exposer?



Mihashi a dit:


Sous chrome, il ne me demande rien du tout, les mots de passe sont accessibles directement en clair. Mais je ne suis pas sous windows.




[Mode troll ON]
Bon ben Linux (ou Mac, je ne sais pas sous quoi tu es :p), c’est troué. Windows est plus sécurisé :mdr2:
[/Mode troll ON]



Mihashi a dit:


Session windows (elle unique à chaque machine aussi, hein) ?




Disons qu’avec un compte windows ce n’est pas obligatoire (mais je crois qu’ils recommandent un mot de passe par machine).



Ça semble être ça dans le bon paramètre dans about:config, mais il semblerait que de toutes façons ça ne suffit pas (donc même sur chrome).
On peut aller sur le site, attendre que le mot de passe soit mis automatiquement et le récupérer via les outils dev.



https://bugzilla.mozilla.org/show_bug.cgi?id=1626778



Ce n’est pas possible avec un compte firefox (j’ai quand même regardé un peu).



Mais ce n’est pas très important, si je voulais réellement sécuriser ma session j’aurai d’autres choses à faire.



Raknor a dit:


Quel threat est prioritaire? keepass? ou le fait qu’un autre défaut l’exposer?





  • La menace c’est la divulgation non-autorisée des mdp.

  • La faille c’est que Keypass permet de réaliser un export en clair de mdp sans le consentement de l’utilisateur.



Peu importe la monstrueuse liste des pré-requis nécessaires pour exploiter cette faille. Tu vires la fonction d’export de Keypass et cette menace disparait… Quant bien même ton PC serait en libre-service pour les hackers :)


“Peu importe la monstrueuse liste des pré-requis nécessaires pour exploiter cette faille. Tu vires la fonction d’export de Keypass et cette menace disparait… Quant bien même ton PC serait en libre-service pour les hackers :)”



Bah non, tu résous le souci du hacker présent illégitimement dans une session, et tu résous toutes les menaces cyber associés, et pas que l’export keepass
-usurpasion moyen de communications
-vol document de travail dans la session
-accès ressources entreprises
-pivot attaque réseau
-vecteur ransomware
-…



Mais vasy, la priorité est de virer keepass.


Du coup, il faut remplacer Keepass si tu t’en débarrasses :




  • apprendre tous les mots de passes et donc limiter le nombre de mot de passe et leurs complexité.
    OU

  • les écrire sur une feuille de papier.
    OU

  • trouver une autre solution de gestion de mot de passe. Laquelle ?


nikogaug

Du coup, il faut remplacer Keepass si tu t’en débarrasses :




  • apprendre tous les mots de passes et donc limiter le nombre de mot de passe et leurs complexité.
    OU

  • les écrire sur une feuille de papier.
    OU

  • trouver une autre solution de gestion de mot de passe. Laquelle ?


on parle juste de la fonction d’export qu’il serait judicieux de rendre un peu plus complexe à activer et modifier.
rappel: sans accès à Keepass on peut silencieusement déclencher l’export en clair de la DB.
le souci ici c’est pas l’export en lui-même. c’est que quelqu’un d’autre que le propriétaire de la base peut déclencher l’export de cette même base sans que le propriétaire soit consentant (c’est important le consentement en 2023).


hellmut

on parle juste de la fonction d’export qu’il serait judicieux de rendre un peu plus complexe à activer et modifier.
rappel: sans accès à Keepass on peut silencieusement déclencher l’export en clair de la DB.
le souci ici c’est pas l’export en lui-même. c’est que quelqu’un d’autre que le propriétaire de la base peut déclencher l’export de cette même base sans que le propriétaire soit consentant (c’est important le consentement en 2023).


Pas exactement. Il faut également que ta base soit ouverte.
Perso, j’ai une base KeePass qui me sert de vault, et un firefox avec Mdp qui gère les mots de passe. Je ne laisse pas KeePass ouvert, donc la base n’est pas déchiffrée lors de l’ouverture de session.



Bien sûr, si mon fichier XML est modifié, lors de l’ouverture, mes MDPs seront exportés en clair. Mais ca veut dire que quelqu’un qui récupère mon .kbdx ne peut pas en faire grand chose.



Je trouve la faille impactante. Elle permet effectivement, dans certaines conditions relativement facile à réunir (kikooo l’ordi du taff avec les admins qui peuvent plus ou moins intervenir dessus) d’avoir accès à tous les mdps. Le correction et la shitstorm autour devrait cependant forcer l’auteur à réagir.



C’est pour ça que je ne jette pas le bébé avec l’eau du bain. KeePass est un excellent logiciel, qui a un problème majeur, mais que l’on peut raisonnablement espérer voir résolu.


nikogaug

Du coup, il faut remplacer Keepass si tu t’en débarrasses :




  • apprendre tous les mots de passes et donc limiter le nombre de mot de passe et leurs complexité.
    OU

  • les écrire sur une feuille de papier.
    OU

  • trouver une autre solution de gestion de mot de passe. Laquelle ?


Je me suis personnellement débarrassé du soucis en n’utilisant plus de mots de passe.
J’ai une méthode de calcul du mot de passe en fonction du site/app plus divers éléments que je garde pour moi.



Du coup je ne mémorise plus de mot de passe, ils sont différents partout, et vu que ma logique est relativement complexe, je doute que quiconque puisse la comprendre.


Mcpanch

Je me suis personnellement débarrassé du soucis en n’utilisant plus de mots de passe.
J’ai une méthode de calcul du mot de passe en fonction du site/app plus divers éléments que je garde pour moi.



Du coup je ne mémorise plus de mot de passe, ils sont différents partout, et vu que ma logique est relativement complexe, je doute que quiconque puisse la comprendre.


Par contre si un de tes mots de passe leak et que la personne reverse ton algorithme, tu peux serrer les fesses :D



Peut-être qu’un seul ne sera pas suffisant, mais quelques uns…
Bref une fausse bonne idée je pense.


Mcpanch

Je me suis personnellement débarrassé du soucis en n’utilisant plus de mots de passe.
J’ai une méthode de calcul du mot de passe en fonction du site/app plus divers éléments que je garde pour moi.



Du coup je ne mémorise plus de mot de passe, ils sont différents partout, et vu que ma logique est relativement complexe, je doute que quiconque puisse la comprendre.


Je doute q’un tel algo soit réellement efficace. Quid d’une fuite de mots de passe d’un des sites ? Est-ce impossible de déduire les autres ? En plus, il est parfois compliqué d’utilisee “son algo” : il suffit d’utiliser un caractère spécial qui sera refusé par le site pour devoir retenir des subtilités pour chaque cas qui sort de l’ordinaire. En tout état de cause, aucun algorithme mémorisable ne sera aussi efficace qu’une suite de caractères aléatoires. Un gestionnaire de mots de passe reste certainement la solution la plus sécurisée.


je viens de vérifier, on a un bouton radio “activer le système de déclencheurs”, qui est activé par défaut.
du coup si une v2.54 décoche ce bouton par défaut le problème me semble réglé.
c’est pas modifiable dans le config.xml.


Et c’est modifiable où ? De toute évidence modifiable par l’utilisateur…


Merci pour le tip, je viens de le désactiver sur ma base. Je pense en effet que la manière la plus simple d’atténuer l’embrasement autour du sujet serait de simplement décocher par défaut l’option d’activer les triggers.



De cette manière, les triggers n’auraient un potentiel effet que pour ceux qui les utilisent et les auront activés. Soit (j’imagine) une grande minorité.



Raknor a dit:


Bah non, tu résous le souci du hacker présent illégitimement dans une session, et tu résous toutes les menaces cyber associés, et pas que l’export keepass -usurpasion moyen de communications -vol document de travail dans la session -accès ressources entreprises -pivot attaque réseau -vecteur ransomware -…




J’avais naïvement la meme approche que toi avant: si le hacker ne peut pas rentrer dans mon système, pourquoi je sécuriserais mes données ?



Sauf qu’une analyse de risque s’occupe de probabilité. Qu’est-ce qui est le plus probable ?




  1. Qu’un hacker rentre dans ton système par une faille 0-day ?

  2. Qu’un hacker déchiffre ta base de mdp chiffrée en AES-256 ?



Certainement le 1er point. Donc le mantra “pas la peine de sécuriser mes donnés, le hacker ne peut pas rentrer” n’est pas la meilleure option en terme de sécurité.


Je ne parle pas de sécuriser les données (qu’il faut faire), je parle de rationaliser un plan d’action pour couvrir les menaces.
Parce que dire que la solution du pb de keepass (rappel, exploitable si un attaquant atteint la session utilisateur), c’est de ne pas utiliser keepass, ce n’est que 10% du pb.



Si tu veux un autre parallèle, c’est de trouver une sqli dans une app web. Avec cette sqli, voir que les mdp user sont stockés en clair dans la bdd. Ton plan d’action premier serait de hasher/saler les mdp dans la bdd et laisser la sqli. LOL.



nikogaug a dit:


Du coup, il faut remplacer Keepass si tu t’en débarrasses :




  • apprendre tous les mots de passes et donc limiter le nombre de mot de passe et leurs complexité. OU

  • les écrire sur une feuille de papier. OU

  • trouver une autre solution de gestion de mot de passe. Laquelle ?




Lancer keypass en admin (ou autre compte dédié) => les fichiers créés par keypass (dont la config) seront seulement modifiables par ce compte et pas par le compte habituel.



(quote:2117629:127.0.0.1)




  • les écrire sur une feuille de papier. OU

  • trouver une autre solution de gestion de mot de passe. Laquelle ?



Lancer keypass en admin (ou autre compte dédié) => les fichiers créés par keypass (dont la config) seront seulement modifiables par ce compte et pas par le compte habituel.




C’est KeePass. Respecte un peu le taff de l’auteur



Mihashi a dit:


Sous chrome, il ne me demande rien du tout, les mots de passe sont accessibles directement en clair. Mais je ne suis pas sous windows.




Si je ne dis pas de bêtise, c’est l’ouverture de ta session qui déverrouille Chrome et le “Mots de passe et clés (SeaHorse en anglais)”
Pour le confirmer, tu peux effacer (sauvegarde avant ! ) tes fichiers dans ~/.local/share/keyrings/ et redémarrer.
Je dis ça pour linux, je ne sais pas sous mac.



(quote:2117629:127.0.0.1)
Lancer keypass en admin (ou autre compte dédié) => les fichiers créés par keypass (dont la config) seront seulement modifiables par ce compte et pas par le compte habituel.




Je suis surpris que cette idée n’ait pas été évoquée plus tôt. Sur linux si je veux que personne ne touche à mon fichier, je le met sous root en 755 et du coup il faut des accès admin pour le changer.
Après, reste le problème des postes entreprise sur lesquels on n’a pas les droits d’admin mais là on peut imaginer que le keepass et sa config est à fournir par les admins de toute manière.



(quote:2117629:127.0.0.1)




  • les écrire sur une feuille de papier. OU

  • trouver une autre solution de gestion de mot de passe. Laquelle ?



Lancer keypass en admin (ou autre compte dédié) => les fichiers créés par keypass (dont la config) seront seulement modifiables par ce compte et pas par le compte habituel.




D’après l’article, le fichier est stocké dans roaming. L’utilisateur a les droits d’écriture sur tous les fichiers du dossier, même si le programme qui les a créé était lancé en admin (à moins bien sûr qu’il override les ACL du fichier).



hellmut a dit:


je viens de vérifier, on a un bouton radio “activer le système de déclencheurs”, qui est activé par défaut. du coup si une v2.54 décoche ce bouton par défaut le problème me semble réglé. c’est pas modifiable dans le config.xml.




J’ai même vu plus fin, juste en dessous : on peut forcer à retaper le mot de passe de la base pour un export (ou une impression). C’est dans Options > Policy. Hélas, par défaut, la case est cochée pour ne rien demander (donc par défaut l’export est invisible), mais surtout ce paramétrage est indépendant du fichier : un utilisateur malveillant peut ouvrir KeePass à vide (= sans saisir de mot de passe maître), mettre les options qui lui conviennent, et refermer sans que l’utilisateur ne voie rien. C’est un chouïa plus compliqué qu’un simple script, mais c’est faisable avec les mêmes droits que pour modifier le fichier de configuration.


Bon, j’imagine que j’ai dû modifier ça il y a fort longtemps parce que les 2 cases Export sont décochées sur ma conf. Mais j’avoue que si je peux le comprendre d’une personne lambda, je saisis mal comment des pro comme ceux qui commentent ici peuvent ne pas lire les options du tel logiciel. C’est comme laisser les options par défaut sur un dashlane/lastpass/bitwarden…


cacadenez

Bon, j’imagine que j’ai dû modifier ça il y a fort longtemps parce que les 2 cases Export sont décochées sur ma conf. Mais j’avoue que si je peux le comprendre d’une personne lambda, je saisis mal comment des pro comme ceux qui commentent ici peuvent ne pas lire les options du tel logiciel. C’est comme laisser les options par défaut sur un dashlane/lastpass/bitwarden…


Bonjour, il fallait modifier des paramètres sur Lastpass ? :D



Et question, quand on installe une nouvelle version de Keepass, ca remplace juste et garde tous les paramètres et plugins de l’ancienne version ?


cacadenez

Bon, j’imagine que j’ai dû modifier ça il y a fort longtemps parce que les 2 cases Export sont décochées sur ma conf. Mais j’avoue que si je peux le comprendre d’une personne lambda, je saisis mal comment des pro comme ceux qui commentent ici peuvent ne pas lire les options du tel logiciel. C’est comme laisser les options par défaut sur un dashlane/lastpass/bitwarden…


Même si tu modifies la config. Elle peut être modifiée en cas de corruption du poste. A moins que ce fichier de configuration soit protégé autrement.


De toute façon ses options sont stockées dans le fichier de conf de l’utilisateur (dans AppData\Roaming\KeePass\KeePass.config.xml)





	<Enabled>false</Enabled>
<Triggers />





	<Export>false</Export>
<ExportNoKey>false</ExportNoKey>




Du coup on peut les modifier en même temps qu’on ajoute les triggers ça ne sert donc pas à grand chose de les modifier.


Arwendil

De toute façon ses options sont stockées dans le fichier de conf de l’utilisateur (dans AppData\Roaming\KeePass\KeePass.config.xml)





	<Enabled>false</Enabled>
<Triggers />





	<Export>false</Export>
<ExportNoKey>false</ExportNoKey>




Du coup on peut les modifier en même temps qu’on ajoute les triggers ça ne sert donc pas à grand chose de les modifier.


À noter qu’avec la fonctionnalité de configuration forcée, il est possible de désactiver les déclencheurs voire de tous les supprimer.



Sur un système bien configuré, le fichier KeePass.config.enforced.xml n’étant modifiable que par un administrateur du système, on gagne un peu en sécurité. La page susmentionnée fournit même deux exemples, je cite :
*Disable trigger system.
The following disables the trigger system. Triggers in the user configuration are preserved, but they are not executed.



<?xml version=“1.0” encoding=“utf-8”?>



<Application>
<TriggerSystem>
<Enabled>false</Enabled>
</TriggerSystem>
</Application>


*



et



*Disable trigger system, delete user triggers.
The following disables the trigger system and additionally deletes all triggers in the user configuration.



<?xml version=“1.0” encoding=“utf-8”?>



<Application>
<TriggerSystem>
<Enabled>false</Enabled>
<Triggers MergeContentMode="Replace" />
</TriggerSystem>
</Application>


*


Arwendil

De toute façon ses options sont stockées dans le fichier de conf de l’utilisateur (dans AppData\Roaming\KeePass\KeePass.config.xml)





	<Enabled>false</Enabled>
<Triggers />





	<Export>false</Export>
<ExportNoKey>false</ExportNoKey>




Du coup on peut les modifier en même temps qu’on ajoute les triggers ça ne sert donc pas à grand chose de les modifier.


bien vu.
en effet il faut quitter keepass pour que la conf s’enregistre, j’avais raté ça.


Il serait possible de désactiver l’héritage dans les droits avancés sur le fichier, de modifier le propriétaire et de ne laisser que les droits de lectures à tous les utilisateurs ou groupes qui ont un accès.
Ceci devrait atténuer le problème à condition que l’utilisateur courant ne soit pas administrateur.



Raknor a dit:


Une solution la plus simple, est que cette conf soit stockée dans un format binaire uniquement lisible de l’exécutable, voir que de l’application




En fait, il faudrait que les triggers du logiciel (en clair) ne puisse pas accéder au contenu du fichier kdbx actuellement ouvert.
Et que si on souhaite préserver ces triggers d’exportation, ils soient liés au kdbx ou stockés dedans, avec la même clé de chiffrement ou au moins une clé de signature.



Car en fait, mine de rien, ça permet de transformer keepass en programme à déclencher une charge virale, pas juste une faille de fuite de mots de passes…


C’est même pire que ça.
Je ne suis pas certain si le fichier de conf est lié au kbdx.
Imagine le scénario où il suffirait de copier un kbdx “volé” dans une session avec le trigger configuré.
Sans ouvrir le kbdx, rien qu’en lançant l’app, tu exportes les mdp en clair (si la bdd est déja ouverte, l’attaquant a déja accès aux données).
Donc oui, cette conf des triggers doit être lié au kbdx. Mais surtout, que cette conf ne soit modifiable que via l’app avec la bdd ouverte (et non avec un éditeur de texte).


Si j’ai bien compris : Pour exploiter cette “vulnérabilité”, il faut que l’utilisateur ait les droits d’écriture du fichier de conf -> vulnérabilité de configuration des exploitants, pas du logiciel lui même.
Dans le cas contraire, il y a déjà eu une élévation de privilège sur la machine qui permet de modifier le fichier de conf pour configurer un trigger -> un admin a tout les droits sur la machine, il peut tout voir et entendre de ce que fait l’utilisateur. D’autres choses sont plus inintéressantes à faire alors, sauf si c’est le poste d’un exploitant informatique qui dispose d’un grand nombre de comptes.
Les applis portables, avec l’utilisateur qui a les droits d’écriture sur les binaires / fichier de conf c’est pas bien pour n’importe quelle application.



Je trouve qu’on fait bcp de bruit pour pas grand chose avec cette soi-disant vulnérabilité de Keypass. Plusieurs SGBD, et des applis comme Gitlab a aussi des trigger e on peut faire des choses pas jolies sans élévation de privilège. Y aurait-il des conflits d’intérêts à faire de la mauvaise pub à Keepass par ses concurrents qui veulent gagner des parts de marcher ?



Si on a un accès distant avec un privilège utilisateur le plus simple d’exécuter un keylogger pour attraper son mot de passe de coffre ou de capturer les copier/coller des mdps qu’il utilise ou la sortie écran pour voir l’usage qu’en fait l’utilisateur connecté, avec un peu de chance l’IHM Keepass a été configurée par l’utilisateur pour afficher les MDP en visible.
Donc on n’a même pas besoin de configurer le fichier de conf pour retrouver ces mots de passe, avec un baecon fait-maison on passe sous les alertes antivirales et si l’EDR n’est pas trop bien configuré (~90% des cas) on peut pivoter et se rapprocher de la cible en quelques heures / jours.


Tu oublis que en entreprise, le helpdesk et les ops ont généralement un compte avec élévation de privilège. Ils peuvent donc devenir admin pendant un temps donné sur une/des machines en fonction de l’implémentation. Pendant ce temps, même si il dépanne la personne, il peut tout à fait faire une manip pour compromettre le fichier de configuration.



La faille ne vient pas toujours forcément de l’externe. Elle peut venir de l’interne via exfiltration par un tiers soit disant de confiance. Si des keypass de SI ce font sortir par ce biais c’est vraiment très moche.


Kiroha

Tu oublis que en entreprise, le helpdesk et les ops ont généralement un compte avec élévation de privilège. Ils peuvent donc devenir admin pendant un temps donné sur une/des machines en fonction de l’implémentation. Pendant ce temps, même si il dépanne la personne, il peut tout à fait faire une manip pour compromettre le fichier de configuration.



La faille ne vient pas toujours forcément de l’externe. Elle peut venir de l’interne via exfiltration par un tiers soit disant de confiance. Si des keypass de SI ce font sortir par ce biais c’est vraiment très moche.


Oui exactement, les ops et les utilisateurs à privilège bureautique (helpdesk) ont déjà tous les outils et bcp de comptes pour compromettre leur SI et tout dépend de l’objectif qu’ils se fixent. Perso je préfère chercher des bases de remoteNG et autres leurs MDP inscrits dedans pour faire de l’élévation de privilège horizontale.
-> je trouve l’utilisation de Keepass (bien installé) bcp moins risquée que l’usage des outils d’exploit au mdp chiffrés symétriquement, ou des clefs ssh sans MDP, certains scripts / outils de connexions RDP qui tracent le user et mdp dans l’historique du powershell, etc.


Pour Chrome je vais m’avancer à dire (de par le look que j’ai vu) qu’il utilise une API Windows pour vérifier le mot de passe.



Par ailleurs il a accès aux mot de passe “sans mot de passe”, c’est à dire qu’il ne vous permettra pas de voir le mot de passe, mais il l’enverra à un site Web.



Donc pareil que pour le secure desktop, sûr à 99% que ça se contourne facilement. Bien sûr ça implique de cibler Chrome (encore que, même pas forcément vraiment). De même qu’ici ça implique de cibler KeePass.



Dans la même veine, 1h de boulot m’a suffit pour pondre un soft qui arrive à chiffrer mes fichiers en tâche de fond, au nez et à la barbe de la fonction “anti ransomware” d’un célèbre logiciel de backup.
J’avais prévu plusieurs étapes, mais il n’a pas résisté à la 1ère. Ceci dit il semble résister aux ransomwares, qui n’ont de toute évidence pas été prévu pour l’éviter.



KooKiz a dit:


D’après l’article, le fichier est stocké dans roaming. L’utilisateur a les droits d’écriture sur tous les fichiers du dossier, même si le programme qui les a créé était lancé en admin (à moins bien sûr qu’il override les ACL du fichier).




J’installe tous mes programmes en mode portable (quand c’est possible). Et pour keepassxc il est possible d’indiquer l’emplacement du fichier de config.



Usage: keepassxc.exe [options] [filename(s)]
KeePassXC - cross-platform password manager

Options:
-?, -h, --help Displays help on commandline options.
--help-all Displays help including Qt specific options.
-v, --version Displays version information.
--config {config} path to a custom config file
--localconfig {localconfig} path to a custom local config file
--lock lock all open databases
--keyfile {keyfile} key file of the database
--pw-stdin read password of the database from stdin
--debug-info Displays debugging information.
--allow-screencapture Allow screen recording and screenshots

Il n’aura pas fallu longtemps : voilà un script qui exploite la faille, via les partages SMB: https://github.com/Orange-Cyberdefense/KeePwn


Ce que je ne comprends pas parmi ceux qui réfutent la faille : si vous trouvez normal qu’un utilisateur privilégié ait accès à votre vault en clair, dans ce cas, pourquoi s’embêter avec un pass manager+master password? C’est le même niveau de sécurité qu’un fichier plain text, en clair, stocké dans un emplacement non accessible aux utilisateurs lambda (mais toujours accessible à un utilisateur privilégié)


Une solution possible serait le stockage d’un hash du fichier de config dans la base. Celui-ci sera utilisé pour valider le fichier de config avant application.



À voir si cela peut être appliqué avec plusieurs bases…