46 lines
3.8 KiB
Markdown
46 lines
3.8 KiB
Markdown
# SEC-10 — Une clé SMTP figure dans un fichier suivi
|
||
|
||
**Gravité historique : Moyenne.** Classification : CWE-798.
|
||
|
||
**État au 14 septembre 2026 :** Littéral retiré du fichier courant et remplacé par une variable obligatoire, correction suivie dans Git. État opérationnel NON SOLDÉ : révocation/rotation chez le fournisseur non vérifiée. L'historique contient toujours l'ancienne configuration ; ne pas copier sa valeur dans des tickets, commandes ou captures.
|
||
|
||
## Executive Summary
|
||
|
||
Toute personne obtenant une copie du dépôt ou de sa configuration suivie peut lire un identifiant SMTP présent en clair dans l'ancien `docker/docker-compose.full.yml`. La fiche ne reproduit jamais sa valeur et n'a pas tenté de l'utiliser.
|
||
|
||
Cette fiche repose sur la relecture du code historique accessible et du correctif courant, ainsi que des preuves documentées lors des passes précédentes. Elle ne constate aucun incident réel. La plus ancienne version ici vérifiée est le snapshot `8446f87` ; les corrections historiques figurent dans `c09b8be`. Aucun tag local ni version déployée n'a permis d'établir une première release vulnérable ou corrigée. Voir [METHODOLOGIE.md](../METHODOLOGIE.md).
|
||
|
||
## Background
|
||
|
||
Un dépôt, même privé, est copié et conservé indépendamment du cycle de vie d’un secret. Le droit de lire le code ne doit pas devenir un droit d’utiliser le compte fournisseur.
|
||
|
||
## Vulnerability Details
|
||
|
||
La configuration de la pile de développement injectait un `SMTP_PASS` littéral à côté d'un fournisseur externe et d'un compte SMTP concret. Un secret de fournisseur était ainsi distribué avec le code. Le fait que le fichier serve au développement ne prouve ni que le credential est fictif, ni qu'il reste valide. La suppression dans le dernier snapshot ne supprime pas les anciens commits, clones, archives ou caches.
|
||
|
||
|
||
|
||
Sources à examiner ensemble :
|
||
|
||
- [docker/docker-compose.full.yml](../../docker/docker-compose.full.yml)
|
||
|
||
## Exploitability Analysis
|
||
|
||
Possibilité d'envoi sous les droits du compte SMTP si le fournisseur accepte encore ce credential ; le quota, les permissions et la validité ne sont pas connus. Aucun email usurpé, accès à une boîte mail ou compromission du compte fournisseur n'est démontré. Le constat sûr est la présence historique d'une valeur ressemblant à un secret opérationnel dans un fichier suivi.
|
||
|
||
Le code applicatif établit le chemin décrit, mais ne renseigne pas les protections effectives d'un déploiement donné, sa version en ligne ou les accès déjà exercés par un attaquant. La gravité ci-dessus est celle du mécanisme vulnérable avant correction ; elle n'est pas un score de risque résiduel calculé pour la production.
|
||
|
||
## Proof of Concept
|
||
|
||
Aucun test d'utilisation du credential n'a été lancé : seul le code/configuration est examiné. Une tentative d'authentification fournisseur ne serait pas une vérification documentaire.
|
||
|
||
## Remediation
|
||
|
||
Littéral retiré du fichier courant et remplacé par une variable obligatoire, correction suivie dans Git. État opérationnel NON SOLDÉ : révocation/rotation chez le fournisseur non vérifiée. L'historique contient toujours l'ancienne configuration ; ne pas copier sa valeur dans des tickets, commandes ou captures.
|
||
|
||
Pour solder le constat en exploitation, vérifier le comportement sur la version effectivement déployée et conserver les contrôles légitimes décrits. La présente passe ajoute uniquement de la documentation ; les correctifs mentionnés existaient avant sa rédaction.
|
||
|
||
## Summary
|
||
|
||
Une clé SMTP figure dans un fichier suivi est un constat historique de l'audit, à lire avec son état courant ci-dessus. La preuve porte sur le mécanisme et les contrôles cités ; elle ne constitue ni une attestation d'exploitation réelle ni une certification exhaustive du projet.
|