Nissan : du code source fuite sur Internet, les identifiants du serveur étaient… « admin/admin »
Le 08 janvier 2021 à 09h20
1 min
Internet
Internet
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.
Le 08 janvier 2021 à 09h20
Commentaires (23)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 08/01/2021 à 10h03
Avec tout ce qui se passe, je me demande comment on peut encore choisir admin / admin, même en provisoire…
Le 08/01/2021 à 10h10
Mais si en espérant/imaginant que les gentils pirates vont se dire “Non quand même pas ça je tente pas”
Le 08/01/2021 à 10h12
Ouais c’est comme mettre 0000 sur un cadenas de valise en fait
Le 08/01/2021 à 10h12
C’est doit être encore un coup du stagiaire, un admin sys compétent ne devrais même pas y pensé une seule seconde.
Le 08/01/2021 à 10h56
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.
Le 08/01/2021 à 17h37
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.
Le 09/01/2021 à 11h59
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
Le 08/01/2021 à 10h11
Typique.
Le 08/01/2021 à 10h55
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.
Le 08/01/2021 à 11h36
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.
Le 08/01/2021 à 12h09
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.
Le 08/01/2021 à 12h28
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.
Le 08/01/2021 à 13h42
Yep, on est tout à fait d’accord sur ce point.
Le 08/01/2021 à 10h57
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é
Le 08/01/2021 à 12h52
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)
Le 08/01/2021 à 13h52
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.
Le 08/01/2021 à 19h04
Le 08/01/2021 à 20h48
Mauvaise langue.
root/Nissan2021!Le 08/01/2021 à 23h50
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.
Le 09/01/2021 à 11h50
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…)
Le 09/01/2021 à 12h54
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.
Le 09/01/2021 à 13h23
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.
Le 09/01/2021 à 14h13
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”.