Discussion :

[Olivier Famien]

Un serveur mal configuré par SVR Tracking expose plus d’un demi-million de véhicules suivis par l’entreprise,
alerte Kromtech Security Center

À l’heure actuelle où tout est connecté à internet, mettre en place des mesures efficaces de sécurité devrait être la priorité de tous les utilisateurs et toutes les entreprises de la planète qui ont leurs données accessibles à partir de la toile. Il y a quelques jours, l’entreprise de sécurité Kromtech Security Center a découvert qu’un Bucket d’Amazon AWS S3 était mal configuré. Amazon Web Service S3 est le principal service de stockage d’Amazon. Il permet de stocker les données en tant qu’objets dans les ressources appelées buckets, ou compartiments. Dans un bucket ou compartiment, il est possible de stocker, supprimer, lire et écrire des objets dont la taille maximale est fixée à 5 téraoctets. Pour le propriétaire d’un bucket, il est possible de consulter les journaux d’accès au bucket ou encore contrôler l’accès afin de définir qui est autorisé à créer, récupérer, supprimer des objets dans le bucket.

Et c’est sur cette plateforme qu’une base de données découverte par Kromtech Security Center s’est retrouvée avec des accès publics. En analysant les données disponibles, l’entreprise de sécurité a remarqué que le bucket mal configuré contenait un dossier de sauvegarde appartenant à l’entreprise de surveillance SVR Tracking et nommé « Account » avec 540 642 numéros d’identification.

Cette entreprise SVR Tracking met à la disposition de ses clients, des appareils à intégrer dans leurs véhicules afin de suivre en direct ces véhicules à partir d’applications sur mobile, tablette ou ordinateur et de les retrouver facilement au cas où les véhicules pistés venaient à être volés. À noter au passage que le sigle SVR Tracking de l’entreprise signifie « Stolen Vehicle Record » pour enregistrement de véhicules volés.

Sur le serveur mal configuré par l’entreprise, en parcourant ce dossier dont le nom laisse déjà deviner le contenu, les chercheurs Kromtech Security Center ont découvert qu’aux différents numéros d’identification contenus dans le dossier sont rattachés d’autres informations comme des identifiants, des mots de passe, des emails, des numéros d’identification de véhicules, des numéros IMEI d’appareils GPS, et d’autres données. Une des choses qui pourraient au moins rassurer les utilisateurs est que les mots de passe étaient chiffrés. Mais malheureusement, le chiffrement était effectué avec l’algorithme de hachage SHA-1 qui n’est plus considéré comme sûr. En outre, la base de données exposée affichait également l’emplacement où le dispositif de pistage était installé dans le véhicule.

Si une personne malveillante venait à mettre la main sur ces informations de grande valeur, elle pourrait cracker les mots de passe des utilisateurs et les suivre en direct en se connectant à l’application de pistage de SVR Tracking. Cette application reçoit les informations de l’appareil de pistage installé dans le véhicule et qui est suivi en temps réel par satellite. À partir de là, plusieurs scénarios sont possibles. Une personne mal intentionnée pourrait par exemple suivre les différents déplacements en temps réel d’un véhicule et s’inviter dans la maison du propriétaire du véhicule lorsqu’elle constate que le véhicule est loin de la maison.

Par ailleurs, vu que l’application liée à l’appareil de pistage intégré au véhicule enregistre les données du véhicule sur les 120 jours passés, d’autres par exemple pourraient se servir de ces informations pour enquêter sur les déplacements d’une personne. D’autres encore pourraient suivre les déplacements d’un véhicule et attendre la bonne occasion pour le voler. Dans pareil cas, il serait difficile à son propriétaire de le retrouver, car le voleur pourrait facilement retirer l’appareil de pistage du véhicule dans la mesure où il a eu accès aux informations qui lui permettent de savoir où cette unité se trouve avec ce serveur mal configuré.

Après avoir évalué tous ces risques potentiels, Kromtech Security Center a alerté l’entreprise au sujet du bucket mal configuré qui laissait ses données accessibles publiquement. Le bucket a été immédiatement sécurisé, mais entre la découverte de Kromtech et la sécurisation du serveur, qui sait si des personnes malveillantes n’ont pas également eu accès à ces données.

Source : Kromtech Security Center

Et vous ?

Cet incident pourrait-il changer votre perception de ces appareils de pistage ? Et par-delà, des appareils connectés ?

[Invité]

"est que les mots de passe étaient chiffrés"

En l'occurence, on parle ici de hashage et pas de chiffrement car l'algorithme utilisé est un algorithme de hashage, sha1 ... Ren n'est dit sur la base hashée, était-ce uniquement le mot de passe ou y avait-il un sel ?

Le fait que le sha1 soit utilisé n'est pas une faiblesse en soi, la qualité du sel oui.

Ce genre d'approximation est quand même vraiment très limite, pour ne pas dire inacceptable sur un site qui se veut dédié aux professionnelles ... Après, celui-ci est gratuit mais bon ...

[transgohan]

Le fait que le sha1 soit utilisé n'est pas une faiblesse en soi, la qualité du sel oui.

L'algorithme sha1 est considéré comme dépassé depuis 10 ans par tous les experts en sécurité du monde...
Mais bon... C'est pas pour autant qu'il n'est pas utilisé.

Le md5 était dépassé depuis les années ~1990 et pourtant toujours utilisé jusqu'à très récemment.

Un membre en a même fait un rappel dans un article il y a peu :
https://securite.developpez.com/tuto...ptographie/#L6

[Aeson]

Le fait que le sha1 soit utilisé n'est pas une faiblesse en soi, la qualité du sel oui.

"La découverte est majeure pour cette fonction de hachage, qui devient désormais obsolète."

[Invité]

L'algorithme sha1 est considéré comme dépassé depuis 10 ans par tous les experts en sécurité du monde...
Mais bon... C'est pas pour autant qu'il n'est pas utilisé.

Le md5 était dépassé depuis les années ~1990 et pourtant toujours utilisé jusqu'à très récemment.

La découverte est majeure pour cette fonction de hachage, qui devient désormais obsolète."

La question que je me pose est la suivante, est-ce que vous chercher vraiment à lire, comprendre une information avant de la répéter bétement ...

Quand on parle d'algorithme de hashage, les vulnérabilités qui sont principalement remontées sont liées au risque de collision, c'est-à-dire que deux sources différentes vont donner le même hash en sortie. C'est ce qu'a réussi à faire Google avec le SHA1. Cependant, ici le contexte est ici tout différent, il s'agit de réussir à identifier quelle était la valeur originale derrière le hash utilisé. C'est une toute autre perds de manche !

Tu peux avoir un algorithme sha512, si ta valeur initiale est TOTO et que tu n'as mis aucun sel (valeur x ajouté au mot de passe) sur cette valeur, ton système d'obfscutation des mots de passe est NUL. Tout simplement car il existe de nombreux dictionnaires qui possèdent les valeurs de hashs précalculés pour toutes les clés triviales. Et qui va très facilement te ressortir que la valeur associée à 10e06b990d44de0091a2113fd95c92fc905166af147aa7632639c41aa7f26b1620c47443813c605b924c05591c161ecc35944fc69c4433a49d10fc6b04a33611 est toto.

En outre, un autre problème que je vois assez communément est l'utilisation du salage codé en dur pour le traitement des mots de passe. L'un des principaux objectifs du salage est que deux mots de passe identiques soient « hachés » vers des valeurs différentes. Si vous utilisez un salage codé en dur, alors vous perdez cette propriété. Dans ce cas, quelqu'un qui obtient un accès à votre base de données peut facilement trouver des cibles faciles en procédant à une analyse fréquentielle des mots de passe hachés. Les efforts de l'attaquant deviennent soudainement mieux focalisés et plus susceptibles de réussir.

Les anciens algorithmes ont la faiblesse d'avoir une taille petite (la taille est relatif dans le temps), des risques de collisions plus grands et un temps de calcul plus court. Ici, le risque de collision est hors de propos, par contre, la taille et la rapidité à calculer les hashs influent fortement sur la vitesse de la forcebrute utilisée. Le problème étant que si tu arrives à retrouver la valeur initiale d'un seul mot de passe passe, tu peux réussir à déduire l'algorithme de génération du sel utilisé et essayer de réduire la complexité des autres hashs présents.

[Aeson]

a question que je me pose est la suivante, est-ce que vous chercher vraiment à lire, comprendre une information avant de la répéter bétement ...

oui continue a utiliser et a recommender sha1 t'as raison. C'est les autres qui sont con...

[transgohan]

Quand on parle d'algorithme de hashage, les vulnérabilités qui sont principalement remontées sont liées au risque de collision, c'est-à-dire que deux sources différentes vont donner le même hash en sortie. C'est ce qu'a réussi à faire Google avec le SHA1. Cependant, ici le contexte est ici tout différent, il s'agit de réussir à identifier quelle était la valeur originale derrière le hash utilisé. C'est une toute autre perds de manche !

Relis toi...
Si deux mot donnent le même hash, alors on s'en fout d'avoir le véritable mot de passe tant qu'on a l'autre.
Vu que le but est de produire le hash pour accéder au contenu.
C'est un peu utiliser un passe-partout sans avoir la clé.

[Invité]

oui continue a utiliser et a recommender sha1 t'as raison. C'est les autres qui sont con...

Je n'ai jamais dis que je le recommandais, j'ai juste dis que l'utilisation de sha1 dans le cadre d'une compromission d'une base de données de mot de passe n'était pas une faiblesse en soi. Dans quelques années, bien sûr, aujourd'hui, ça passe encore même si c'est limite on va dire.

Relis toi...
Si deux mot donnent le même hash, alors on s'en fout d'avoir le véritable mot de passe tant qu'on a l'autre.
Vu que le but est de produire le hash pour accéder au contenu.
C'est un peu utiliser un passe-partout sans avoir la clé.

Pas nécessairement, l'exploitation d'une bdd mot de passe peut également servir à recueillir des couples user - mot de passe pour les utiliser sur d'autres sites car de nombreux utilisateurs réutilisent le même couple partout. Le passe partout pour le user sur l'applicatif concerné ayant très peu de chance d'être valide ailleurs.

Bon, j'imagine ma phrase sur le fait de répéter bêtement une information n'a pas du plaire à beaucoup et je m'en excuse mais l'animosité rendu à mon égard ne me donne pas envie de partager plus longuement mes connaissances.

[transgohan]

Ce n'est pas que cette phrase qui a fait que vous avez mis un pied dans le plat en fait.
Le fait d'indiquer que la vulnérabilité était hors de propos alors qu'au contraire elle est critique dans un système sécurisé était ce pas de plus pour qu'on ne vous juge pas à vos connaissances.
Quand on parle sécurité il est illusoire d'écarter trop vite certaines vulnérabilités, c'est ce que vous avez fait et c'est ce qui vous a décrédibilisé.
Pensez-y la prochaine fois.
Au plaisir de vous relire.

La moyen le plus simple est en effet d'avoir des couples identifiant/mdp mais ce ne sont pas les seuls vecteurs d'attaques. Je vous en ai cité un qui malgré qu'il ne soit que peu utilisé (car complexe) n'en reste pas moins efficace à l'heure actuelle (même si son efficacité reste dérisoire face à la découverte du couple).

[Aeson]

ne me donne pas envie de partager plus longuement mes connaissances.

Vu ce que tu dis en s'en passera sans probleme... ne te tracasse pas