En 2021 comme en 2020, nous avons des erreurs de débutants sur la configuration des serveurs contenant des données sensibles. Cette fois, c’est Nissan qui en fait les frais, comme le rapporte ZDNet.com.
« Le code source des applications mobiles et d’outils internes développés et utilisés par Nissan North America a été divulgué en ligne, suite à une mauvaise configuration d’un de ses serveurs Git », expliquent nos confrères.
Et c’est peu de le dire : le couple identifiant et mot de passe était admin/admin… Le fabricant de voitures a évidemment rectifié le tir et lancé une enquête. Il assure qu’aucune donnée personnelle n'était présente. « Nous sommes convaincus qu'il n'y a aucune information dans le code source exposé qui mettrait en danger des clients ou leurs véhicules », ajoute Nissan.
Commentaires (23)
#1
Avec tout ce qui se passe, je me demande comment on peut encore choisir admin / admin, même en provisoire…
#1.1
Mais si en espérant/imaginant que les gentils pirates vont se dire “Non quand même pas ça je tente pas”
#1.2
Ouais c’est comme mettre 0000 sur un cadenas de valise en fait
#1.3
C’est doit être encore un coup du stagiaire, un admin sys compétent ne devrais même pas y pensé une seule seconde.
#1.4
Le cas classique, c’est un serveur de tests, avec admin/admin, en te disant bien que tu mettras un vrai mot de passe en prod. Mais le jour où tu passes en prod, tu recopies intégralement la config de tests, en oubliant qu’il y a de tels identifiants dedans.
#1.5
Faut encore que ce soit un adminsys qui ait fait l’install. Tu sais maintenant on a des “devops” qui te déploient ça en 10 lignes avec terraform/ansible/docker, et qui en réalité ne comprennent pas une seule seconde ce que ça fait en dessous et ce que ça implique réellement.
#1.6
Même pour du provisoire tu peux prendre une variation pour ton entreprise que tout le monde connaît (du type : CeciEstUnMotDePasse), c’est simple à retenir, ça permet de reprendre la suite facilement si le mec sur le projet est malade et ça te protège contre du distant (bot et compagnie).
Après c’est une mauvaise idée pour du non provisoire
#2
Typique.
#3
Perso je n’irai pas juger la compétence des employés, mais j’irai plutôt m’inquiéter des moyens accordés à la DSI de Nissan US.
Ce genre d’histoire démontre généralement un manque total de considération pour l’IT de la part du management d’entreprise.
#3.1
Comme partout, ce n’est pas qu’une question de moyen, la DSI de ma boîte a un budget significatif, mais n’est pilotée que par des gestionnaires sans compétences informatiques, avec comme ligne de conduite sous-traitance totale (comme ça on est pas responsable quand ça merde). Total, des aberrations partout, des insatisfaits et du shadow IT en roue libre…
Du budget oui, sous-traiter oui, mais pour cela il faut être en mesure d’évaluer ce que chiffre / fait le presta.
#3.2
Les moyens ne sont pas que financiers, ils sont aussi humains. Mettre les mauvaises personnes aux postes stratégiques témoigne aussi du manque de moyens alloués à un domaine.
#3.3
Dans ce sens je suis parfaitement d’accord, mais l’acceptation générale du terme se limite souvent au volet financier.
C’est ce qui me fait réagir, d’entendre que tel ou tel sujet manque de moyens financiers alors que le problème est avant tout organisationnel. Si il y a bien une chose que l’on peut constater avec la politique publique et sociale française depuis des décennies, c’est que jeter de l’argent sur les problèmes ne les résout pas.
#3.4
Yep, on est tout à fait d’accord sur ce point.
#4
Quand je pense que même pour des tout petits sites (style blog perso), sans aucune données privées et intéressantes, même en cours de dév, j’utilise des mots de passe de 30 caractères (Maj, min, caractères spéciaux “exotiques”, chiffres…), je me dis que soit je suis un peu trop prudent, soit je ferais un excellent chef de la cybersécurité
#5
Bah, beaucoup de plateforme (opensource ou non) configurent par défaut ce couple d’identifiant lors de leur installation, à l’administrateur de les changer ensuite, ce qui n’est pas toujours fait, la preuve…
D’autant plus que certaines plateformes ne permettent pas de modifier le login “admin”, juste son mot de passe, ce qui simplifie grandement les piratages… (coucou les Livebox)
#6
C’est clairement lourd ça, d’autant que la première action des outils de pentesting c’est généralement de repérer toutes les applis accessibles et de balancer un bon bruteforce/attaque par dico sur le login “admin” et ses variantes connues.
#7
#7.1
Mauvaise langue.
root/Nissan2021!#8
Aucune donnée personnelle, ils développent avec des pseudos comme StopCovid ?
Il y a quand même de très fortes chances pour que les commits contiennent bien les noms et adresses email des développeurs, de même que des indices sur leurs heures de travail.
#9
J’ai testé l’installation d’Alfresco 6.2 Community via Docker, et par défaut, l’administration est accessible par admin / admin (non modifiable par l’installation, cela doit être modifié ensuite), et tous les systèmes ont des mots de passe génériques (postgresql & co), modifiables par contre via le fichier dockerfile.
Et une conteneur, il faut aussi faire attention à mettre à jour son contenu, car il y a des failles dans les outils… ce que beaucoup de devops ne réalisent pas : “c’est un conteneur, il n’y a pas de risque…” (ou une vm dans le cas de déploiements plus traditionnels…)
#9.1
En fait cette vision n’est pas du DevOps mais plus proche du NoOps mal géré où le développeur est “tout puissant” mais n’a aucune notion de sécurité.
Et effectivement, beaucoup oublient qu’une image Docker peut reposer sur une image de base obsolète et complètement trouée … Raison pour laquelle nous les reconstruisons systématiquement dans notre cas.
Dans tous les cas, c’est pour ça aussi que la démarche DevOps évolue en DevSecOps pour implémenter les concepts de sécurité dans toute la chaîne de valeur.
#9.2
Y’a pas que la sécurité, y’a même pas mal de raisonnement sur les logiciels “de base” qui sont manquants (j’ai eu du “développeur wordpress” qui était content de déployer ses sites avec Docker, jusqu’au jour où il a foutu la grouille avec la conf apache sans réussir à comprendre d’où ça venait, et c’est ma pomme qui s’est tapé le debug). Pas pour rien que “ops” est considéré comme un métier à part, quand bien même on voudrait le faire disparaitre ou le noyer dans d’autres concepts.
#9.3
Ces soucis sont surtout causés par une méconnaissance de ce qu’est le DevOps. Le principe est de faire travailler main dans la main les personnes sans silo, pas que l’un remplace l’autre. C’est donc une visu organisationnelle et non technique.
Mais hélas, pour beaucoup DevOps = “on a Jenkins, Docker et Ansible youhouuu”.