Après ma première analyse des répertoires .git exposés, j'ai effectué une autre analyse des fichiers .env exposés. Au cours de cette analyse, j'ai trouvé plus de 200 fichiers .env exposés. Outre les paramètres de configuration inoffensifs, j'ai trouvé 135 utilisateurs et mots de passe de base de données, 48 comptes d'utilisateurs de messagerie avec mots de passe, 11 informations d'identification en direct pour les fournisseurs de paiement (comme Stripe ou Paypal), 98 jetons secrets pour différentes API et 128 secrets d'application (secrets pour générer en toute sécurité une session ids, jetons CSRF et jetons JWT) et quelques informations d'identification d'administrateur codées en dur.
TLDR : Attention aux erreurs dans le processus de déploiement. N'exposez jamais votre fichier .env caché au public.
Je suis SDCat, un développeur de logiciels avec un esprit curieux qui aime regarder partout sous le capot. Après mon analyse des répertoires .git exposés, j'ai décidé d'approfondir ce terrier de lapin. Et j'ai décidé de vérifier les fichiers .env exposés.
Dans cet article, je décris ce qu'est un fichier .env, comment j'ai scanné les domaines et quelques statistiques sur ce qui a été trouvé dans ces fichiers. L'analyse de ces données a parfois révélé de nombreuses informations d'identification pour différents services et comptes.
Chaque logiciel nécessite une certaine configuration et possède différents paramètres. Dans le cas d'un logiciel utilisateur, tel qu'un client de messagerie, ces paramètres, tels que l'adresse e-mail, le nom d'utilisateur et le mot de passe, sont demandés à l'utilisateur lors du premier démarrage du logiciel. Pour les logiciels qui s'exécutent sur un serveur et sont souvent installés automatiquement, l'interaction de l'utilisateur n'est pas possible. Pour certains frameworks logiciels, ces paramètres peuvent être spécifiés via des variables d'environnement et configurés dans un fichier portant le nom .env. Les fichiers .env sont des fichiers cachés, vous ne voyez donc pas ces fichiers par défaut.
Exemple de fichier .env :
ENV= "PRODUCTION"
LOG_LEVEL= "INFO"
SMTP_HOST= "email.example.com"
SMTP_PORT= 25
SMTP_USER= "[email protected]"
SMTP_PASS= "SuperSecurePassword2022"
SMTP_TLS= 1
SMTP_CONNECTION_TIMEOUT_SECONDS= 2
DB_HOST= "dbserver.example.com"
DB_DATABASE_NAME= "important_database"
DB_USER= "my-app-db-user"
DB_PASSWORD= "2022SuperVerySecurePassword"
PAYMENT_GATEWAY= "payment.example.com"
PAYMENT_SECRET= "super-secure-payment-api-secret"
Remarque : Nous recommandons des mots de passe plus sécurisés que ceux mentionnés dans les exemples ci-dessus.
Étant donné que presque toutes les applications Web accèdent à une base de données ou utilisent des API pour communiquer, ces informations d'identification doivent être transmises à l'application. Si cela est fait à l'aide du fichier .env, les informations d'identification sont en texte brut dans ce fichier. Lorsque le serveur Web est mal configuré et que ce fichier .env est fourni par le serveur Web, n'importe qui peut interroger ces données. Pour ce faire, on peut visiter juste une URL avec un navigateur, comme : https://example.com/.env.
L'aspect dangereux est que les mots de passe et les secrets sont sous forme non cryptée dans le fichier .env.
J'ai choisi un pays qui autorise le transfert de zone DNS pour obtenir tous les domaines de ce pays. Le téléchargement du fichier de zone complet prendra un certain temps. Avec un simple script python, j'ai extrait les enregistrements NS et à partir de ces enregistrements les noms de domaine.
Avec un autre script python, je lis les domaines et envoie une requête à http://<domain>/.env . J'ai également vérifié http://www.<domain>/.env, https://<domain>/.env et https://www.<domain>/.env.
Il est important d'ignorer la vérification du certificat SSL. J'ai appris que de nombreux fichiers ont été trouvés sur https mais avec un certificat invalide. En ignorant les certificats SSL invalides, ces répertoires sont accessibles de toute façon.
J'ai scanné 2,6 millions de domaines et j'ai trouvé :
Ce sont les résultats des seuls domaines principaux. Imaginez ce qui se passerait si nous scannions tous les sous-domaines. Je ne doute pas que vous en trouverez beaucoup plus là-bas.
Vous pouvez analyser vos domaines et sous-domaines avec un modèle de noyaux ou vous pouvez utiliser un service comme scan.nan.io pour vérifier automatiquement vos domaines et sous-domaines pour les fichiers sensibles exposés.
À emporter : vérifiez votre serveur et votre déploiement pour ne pas exposer le fichier .env caché.
Également publié ici .