Question:
Le hachage d'un fichier à partir d'un site Web non signé donne-t-il un faux sentiment de sécurité?
Iszi
2011-01-18 04:19:28 UTC
view on stackexchange narkive permalink

Considérez ceci. De nombreux sites Web proposant des téléchargements de logiciels proposent également des hachages MD5 ou SHA1, permettant aux utilisateurs de vérifier l'intégrité des fichiers téléchargés. Cependant, peu de ces sites utilisent réellement le cryptage HTTPS ou les signatures numériques sur le site Web lui-même.

Donc, si vous téléchargez un fichier à partir d'une source non authentifiée et que vous le validez avec un hachage du même source (ou même une autre source non authentifiée), quelle est la valeur réelle du hachage du fichier? Cela ne crée-t-il pas un faux sentiment de sécurité, car (en l'absence de signature numérique) le téléchargement et le hachage auraient pu être falsifiés, à l'insu de l'utilisateur?

Je parierais que le faux sentiment de sécurité est un argument fort pour ne pas fournir de hachages ... jamais. Je ne sais pas la dernière fois que TCP / IP a échoué et j'ai eu un téléchargement corrompu. C'est arrivé ... jamais.
MD5 est un algorithme de résumé de message, et ni MD5 ni SHA1 ne sont destinés à l'authentification de l'auteur; une simple vérification du contenu avec une probabilité élevée en supposant l'absence de malfaiteur. Les collisions MD5 sont tout à fait possibles. Cela seul devrait vous indiquer que ces fonctionnalités ne sont pas destinées à être des fonctionnalités de sécurité (ou, du moins, si elles sont facturées comme telles, la personne qui effectue la facturation est incompétente).
Onze réponses:
#1
+57
yfeldblum
2011-01-18 04:25:57 UTC
view on stackexchange narkive permalink

Donc, si vous téléchargez un fichier à partir de ce qui est effectivement une source non authentifiée et que vous le validez avec un hachage de la même source (ou même d'une autre source non authentifiée), quelle est la valeur réelle du hachage du fichier ?

Le hachage fourni vous permet de vérifier que le fichier que vous avez téléchargé n'a pas été corrompu accidentellement pendant le transport, ou que le fichier que vous avez téléchargé depuis une autre source (un miroir plus rapide) est le même que le fichier est disponible en téléchargement sur ce site.

Cependant, il n'y a pas vraiment beaucoup de sécurité supplémentaire. Un cracker suffisamment expérimenté peut remplacer le fichier par une version malicieusement modifiée et le hachage par une qui correspond au fichier modifié; ou il peut MITM les requêtes sur le réseau et remplacer à la fois le fichier demandé par le sien et le hachage par le sien.

Bonne réponse. Personnellement, je n'ai même jamais pensé à utiliser le hachage pour la sécurité; Je pensais que c'était uniquement pour la vérification des erreurs!
@MatthewRead, Cela n'a pas de sens. Ils sont faits pour la sécurité.
Le hachage @Pacerier n'a certainement pas été créé pour la sécurité. Si vous n'êtes pas d'accord avec cette réponse et la prémisse de la question, mieux vaut y répondre qu'un commentaire désinvolte d'un enfant de 4 ans et plus.
@MatthewRead, La question parlait de SHA1 et MD5. Ceux-ci sont appelés hachages sécurisés qui sont fondamentalement différents des sommes de contrôle CRC.
@Pacerier, comme les autres réponses, par des professionnels de la sécurité, l'ont clairement indiqué, un attaquant peut généralement modifier les hachages également, et les hachages ne sont pas conçus pour être utilisés par eux-mêmes pour signer des choses.De plus, MD5 a été cassé il y a des années.Il est désormais facile de créer deux fichiers avec le même hachage MD5.SHA1 est également suspect et ne répond pas aux exigences modernes.Mais comme indiqué, même le passage à SHA-2 ou SHA-3 en soi, même avec https, n'offrirait pratiquement aucune protection.
#2
+18
Jeff Ferland
2011-05-26 09:54:59 UTC
view on stackexchange narkive permalink

Le bénéfice y est en effet limité. Comme vous l'avez souligné, si vous pouvez remplacer une chose sur un site, vous pouvez probablement remplacer les deux.

Cela présente cependant certains avantages:

  • Cela permet d'autres sites pour héberger des fichiers volumineux avec une intégrité vérifiée. Avec cela, je peux récupérer le fichier auprès d'une tierce partie aléatoire en qui je n'ai aucune raison de faire confiance et toujours vérifier qu'il s'agit d'un bon fichier basé sur le site source (qui peut avoir une bande passante limitée).
  • Si votre site est assez populaire, il est probable qu'il y ait suffisamment de copies de l'ancien hachage pour confirmer rapidement un compromis au public, y compris via archive.org et divers caches des moteurs de recherche.

est une sécurité supplémentaire à gagner en ayant des fichiers de signature avec une paire de clés publique / privée, l'avantage pratique pour la plupart des applications n'est pas plus grand avec une clé que sans. Si je poste ma clé sur le site Web et signe tout au lieu de publier le hachage, un attaquant peut obtenir le même effet en remplaçant la clé qu'en remplaçant le hachage. Les projets à grande échelle qui ont une distribution indépendante ont besoin de cette couche supplémentaire (Debian vient à l'esprit), mais je pense que peu en bénéficieraient.

#3
+10
Thomas Pornin
2012-10-28 02:38:37 UTC
view on stackexchange narkive permalink

Pour que le hachage ait une valeur liée à la sécurité, les deux conditions suivantes doivent toutes les deux être remplies:

  • la valeur de hachage doit être distribuée via un protocole qui garantit l'intégrité (par exemple HTTPS);
  • le fichier téléchargé ne doit pas être distribué via un protocole qui garantit l'intégrité;

car, si le est également servi avec HTTPS, alors le hachage a tendance à être inutile: SSL assure déjà l'intégrité lors du transfert.

Le hachage ne protégera pas contre un attaquant qui prend le contrôle du serveur, car il pourrait alors modifier le hachage comme il pourrait modifier le fichier.

Un exemple de l'utilité du hachage publié est lorsque vous téléchargez le fichier à une certaine date, puis que vous voulez vérifier plus tard sur ce que la copie que vous avez est correcte, parce que vous ne faites pas nécessairement confiance à l'intégrité de votre stockage local (par exemple, il était sur une clé USB qui aurait pu être temporairement volée par une personne mal intentionnée). Un autre exemple est lorsque le téléchargement lui-même provient d'un réseau p2p, car de telles choses sont très efficaces pour distribuer des logiciels en masse à de nombreux clients (c'est ce que fait Blizzard Downloader): utilisez le p2p pour obtenir le fichier, puis obtenez la petite valeur de hachage du site HTTPS principal. Un troisième exemple (que je rencontre professionnellement) est lors de la construction d'un système de confiance dans des conditions d'audit difficiles (par exemple, la création d'une nouvelle autorité de certification racine): vous voulez que l'auditeur puisse vérifier que le logiciel utilisé est authentique . Si un fichier de hachage est distribué (via HTTPS), l'auditeur doit simplement le vérifier par rapport à une archive locale; sinon, l'auditeur doit être témoin de l'intégralité du téléchargement. Compte tenu des tarifs horaires des auditeurs, le hachage est préférable.

#4
+7
nealmcb
2011-05-26 10:46:59 UTC
view on stackexchange narkive permalink

Vous avez raison de dire que le simple fait d'avoir un hachage brut présente un avantage limité, car vous devez également le distribuer en toute sécurité, et la plupart des gens ne savent pas comment le vérifier correctement ou naviguer parmi les nombreux problèmes possibles.

La bonne façon d'obtenir une bonne sécurité est d'utiliser la technologie de clé publique pour signer les hachages et de l'intégrer de manière transparente dans l'ensemble du schéma de distribution de logiciels. Il est toujours nécessaire de distribuer en toute sécurité la clé publique, mais cela peut être fait une fois, par ex. lorsque le système d'exploitation est installé. Je suppose que c'est essentiellement ce qui est fait avec Windows et MacOS pour les mises à jour du système d'exploitation et quelques packages majeurs comme Office.

Le mieux, c'est quand presque tous les logiciels dont vous avez besoin sont couverts par les mêmes clés standard. C'est essentiellement ce qui se passe avec la plupart des distributions de logiciels open source, comme Debian, Ubuntu, Red Hat, Suse, etc. Ils distribuent en toute sécurité des dizaines de milliers de paquets, tous automatiquement signés avec des clés qui sont gérées dans le cadre de la distribution, et donc hautement sécurisé. Et cela se produit généralement sans que personne n'ait besoin de faire de vérifications manuelles.

Cela ne sert à rien si la page était déjà HTTPS, non? Alors un simple SHA2 suffirait.
@Pacerier HTTPS ne protège que les données en transit entre votre client et le site. Il ne vous dit rien sur les fichiers qui sont servis par le site. Étant donné qu'un attaquant peut souvent transférer des fichiers sur un site, via une grande variété de méthodes (initiales, clandestines ou illégales), vous avez vraiment besoin de signatures au niveau des fichiers.
Quand vous dites "un attaquant peut souvent obtenir des fichiers sur un site", voulez-vous dire qu'il peut modifier le binaire? S'ils sont capables de modifier le binaire, ne pourraient-ils pas également modifier la somme de contrôle?
@Pacerier Oui, un attaquant peut modifier le binaire, et il peut modifier une simple somme de contrôle. C'est tout l'intérêt de cette question - de simples sommes de contrôle n'apportent guère de sécurité supplémentaire. Mais les signatures de clé publique offrent beaucoup de sécurité supplémentaire, car si quelqu'un modifie la signature, elle ne sera pas valide une fois vérifiée. Et ils devraient avoir accès à la clé privée des signataires (qui, espérons-le, est hors ligne et peut être sécurisée dans un module de sécurité matériel) pour créer une signature valide pour un binaire modifié.
#5
+6
KeithS
2013-01-09 00:45:39 UTC
view on stackexchange narkive permalink

Donc, si vous téléchargez un fichier à partir de ce qui est effectivement une source non authentifiée et que vous le validez avec un hachage de la même source (ou même d'une autre source non authentifiée), quelle est la valeur réelle du hachage du fichier ?

Dans cette situation, où un hachage se trouve immédiatement à côté d'un lien vers le fichier, la valeur est principalement de s'assurer que le fichier n'est pas endommagé ou corrompu pendant le transport.

Du point de vue de la sécurité, vous avez raison; cela a très peu de valeur pour prouver que le fichier n'a pas été falsifié, car toute personne qui pourrait entrer et télécharger un fichier piraté (ou changer le lien pour pointer vers une copie piratée) pourrait également remplacer le hachage qui se trouve à côté. C'est pourquoi ce n'est presque jamais fait de cette façon lorsque l'objectif est la sécurité.

En général, lorsqu'un condensé de hachage est proposé, il vient directement du producteur du logiciel. Ils proposent des logiciels à télécharger, mais ne sont pas disposés à héberger directement le logiciel sur leurs propres serveurs; ils sont une société de logiciels, pas une société d'hébergement, et n'ont pas la bande passante entrant et sortant de leurs propres serveurs pour permettre des milliers de téléchargements simultanés à large bande. Donc, ils louent de l'espace et de la bande passante à un fournisseur de cloud pour fournir le même service.

Désormais, ils ne contrôlent pas ce cloud; c'est un système différent maintenu par une entreprise différente, "ma maison, mes règles". Le fournisseur de logiciels s'inquiète du piratage et de voir sa réputation ternie par un compromis de la société d'hébergement, et pour de bonnes raisons; il s'agit d'une méthode d'attaque courante, et c'est le nom de la société de logiciels sur le logiciel qui a permis à un attaquant d'accéder au réseau d'un utilisateur d'entreprise et de causer des ravages.

La solution consiste pour le producteur du logiciel à hacher les fichiers proposés au téléchargement sur le site d'hébergement, et à les présenter depuis ses propres systèmes sous son contrôle. Maintenant, vous, l'utilisateur final, pouvez télécharger le logiciel à partir du grand site d'hébergement et vérifier que ce que vous avez obtenu correspond à ce que l'éditeur de logiciels a mis en place en allant sur le site de l'éditeur de logiciels et en comparant son hachage de fichier répertorié avec celui à partir duquel vous calculez. le fichier téléchargé. Cela prend beaucoup moins de bande passante pour l'éditeur de logiciels que l'hébergement du fichier réel à télécharger. Maintenant, il n'y a plus un seul point de vulnérabilité; un attaquant doit pirater à la fois le cloud et le site du producteur du logiciel afin de mettre en place un fichier qui passera le hachage. Ils peuvent gâcher les gens qui ne prennent pas la peine de vérifier les hachages (ce qui est beaucoup de gens) en piratant simplement le site d'hébergement et en remplaçant le fichier, ou ils peuvent gâcher les personnes qui vérifient les hachages en piratant le site du fournisseur de logiciels et en modifiant les hachages pour que le hachage du fichier réel ne corresponde plus, mais ils ne peuvent vraiment faire passer pour un fichier piraté que celui de l'éditeur de logiciels en faisant les deux, ce qui est beaucoup plus difficile.

Bonne réponse. Plus 1 pour l'utilisation de la langue vernaculaire commune pour l'expliquer.
#6
+5
nealmcb
2011-01-18 04:28:08 UTC
view on stackexchange narkive permalink

De manière générale, oui - un hachage d'un site http fournit peu ou pas d'assurance que les données proviennent d'une source fiable.

Mais cela dépend de votre définition de la sécurité, c'est-à-dire de votre modèle de menace . L'un des aspects de la sécurité est l'intégrité des données, et vérifier un hachage vous aidera souvent à éviter de perdre du temps sur un mauvais CD-ROM ou un téléchargement corrompu.

Il est préférable d'obtenir un logiciel à partir d'un système de paquets qui fournit une bonne authentification depuis le programmeur, en passant par le contrôle de version, jusqu'à l'empaquetage et la distribution.

#7
+4
Rory Alsop
2011-01-18 04:28:15 UTC
view on stackexchange narkive permalink

Pour votre utilisateur domestique, il est généralement «suffisant» que le fichier soit correct (et par là je veux dire - le téléchargement a fonctionné et il n'y a pas de corruption) - bien que du point de vue de la sécurité, un attaquant puisse tout aussi facilement remplacer le fichier hashes comme les fichiers s'ils le voulaient s'ils sont stockés au même emplacement.

pour un responsable de la sécurité d'entreprise ou pour quelque chose d'un peu plus sensible, vous voudriez vraiment valider le hachage, probablement par un mécanisme hors bande.

#8
+3
Steve
2011-01-18 04:26:33 UTC
view on stackexchange narkive permalink

Dans la situation que vous avez décrite, la seule utilité d'une signature est simplement de s'assurer que le fichier n'est pas corrompu.

Mais notez qu'un hachage n'est en aucun cas une signature. C'est une fonction à sens unique, une somme de contrôle sécurisée, mais ne contient aucune preuve que quiconque se porte garant de quoi que ce soit.
#9
+2
user2428118
2014-04-14 13:31:03 UTC
view on stackexchange narkive permalink

Il existe quelques cas où la vérification du hachage d'un fichier peut s'avérer un avantage de sécurité, même si le hachage n'a pas été téléchargé via une connexion sécurisée:

  • Si seulement votre connexion est étant falsifié, vous pouvez visiter la page Web contenant le hachage en utilisant une autre connexion (par exemple un VPN sécurisé). Si la page, lorsqu'elle est visualisée via cette autre connexion, affiche le même hachage, il est beaucoup moins probable qu'elle ait été falsifiée.
    Bien sûr, vous pouvez obtenir le même résultat en téléchargeant le même fichier deux fois via différentes connexions, mais ceci est beaucoup plus rapide.
  • Si l'attaquant, humain ou logiciel, ne s'est pas soucié de calculer le hachage du fichier malveillant et de remplacer le hachage d'origine par celui-ci. Attention cependant, se fier au paresseux des attaquants n'est pas la meilleure défense.
  • Si le fichier est téléchargé à partir d'un autre site que le hachage et ce site a été compromis mais le site à condition que le hachage ne soit pas . Par exemple, le fichier peut être distribué via un miroir ou un CDN.
  • Si le hachage fourni est signé numériquement avec une clé de confiance. Par exemple, les hachages signés avec une signature PGP de confiance.

Néanmoins, lorsque vous fournissez des hachages via une connexion non sécurisée, le principal avantage est que vous pouvez vérifier que le fichier transmis n'a pas été corrompu en transit. De nos jours, cela n'arrive pas très souvent, mais cela se produit. La gravure d'un ISO Linux corrompu peut vous donner une installation corrompue que vous ne remarquerez peut-être que lorsqu'il est déjà trop tard. Flasher votre BIOS avec un téléchargement corrompu pourrait être encore pire.

Une autre chose à considérer est que, bien que fournir des hachages puisse effectivement donner un faux sentiment de sécurité, il est très probable que la personne qui télécharge le fichier l'ont quand même téléchargé, même si aucun hachage n'était présent. Dans ce cas, le petit avantage de sécurité fourni par les hachages peut ne compenser rien du tout.

Dans votre troisième puce, vous avez mentionné que si le hachage est hébergé sur un site différent, il serait alors normal d'envoyer le hachage à l'utilisateur via une connexion non sécurisée.Mais un attaquant ne peut-il pas changer le hachage qui est envoyé à l'utilisateur?
@Rads Le scénario auquel je pense pour # 3 n'est pas une attaque active de l'homme du milieu contre un utilisateur, mais un site Web tiers hébergeant le logiciel lui-même en cours de compromission et le site Web contenant des informations sur le logiciel (y compris unhash) non.Par exemple, en août de cette année, le site de logiciels open source [FossHub] (http://www.ghacks.net/2016/08/03/attention-fosshub-downloads-compromised/) a été piraté et certains de leurs téléchargements ont été remplacés parmalware.(Suite dans le prochain commentaire.)
FossHub est utilisé par de nombreux projets open source pour gérer leurs téléchargements, dont la plupart ont leur propre site Web (par exemple [qBittorrent] (http://www.qbittorrent.org/download.php) et de nombreux autres projets).En vérifiant le fichier d'installation téléchargé depuis FossHub par rapport aux hachages fournis sur le site Web de qBittorrent, on aurait pu découvrir que le fichier avait été falsifié. (qBittorrent n'était pas l'un des fichiers qui ont été remplacés par des logiciels malveillants dans ce cas particulier, mais vous avez l'idée. J'ai choisi qBittorrent car ils fournissent en fait des hachages sur leur propre site Web.)
#10
  0
labmice
2011-01-19 21:56:38 UTC
view on stackexchange narkive permalink

@Iszi voici une histoire courte ... (ok, peut-être pas "courte" ... désolé pour ça: P)

disons que vous voulez télécharger VLC . Pour les fenêtres. Dernière version (ver. 1.1.5). OK?

Votre premier endroit où aller serait http://www.videolan.org (site officiel ). Mais vous pouvez trouver et obtenir le "même" prog de 5.780.000 sites. N'est-ce pas? (google "vlc download 1.1.5").

Le site officiel indique que MD5 du fichier est "988bc05f43e0790c6c0fd67118821d42" (voir lien). Et vous pouvez obtenir ce prog (ver. 1.1.5) soit sur le serveur WEB officiel de videolan.org ( PAS de HTTPS ). Ou cliquez sur le lien, redirigez vers Sourceforge et obtenez-le. Et encore une fois avec PAS de HTTPS . Mais Sourceforge est un grand nom. Digne de confiance. Droite? Et devine quoi. Votre oncle qui a VLC, vous envoie un lien Rapidshare par e-mail, pour le télécharger. Et votre ami du travail aussi.

Vous le téléchargez donc à partir de ces " sources fiables ".

Amis, sites, versions, oncles. Vous leur faites tous confiance. Droite ? Je ne pense pas. Au moins tu ne devrais pas.

Il existe un (et un seul) moyen de vérifier que ce que vous avez, est le fichier d'origine . Inaltéré, non modifié. Intacte. Et c'est pour comparer le hash de celui-ci. Mais avec quoi? Avec le hachage de la source officielle.

Pas de HTTP (S), pas de signatures numériques, pas de serveur "sécurisé" ou "de confiance". Rien. Vous n'avez besoin d'aucun de ces éléments. L'intégrité des données est votre ami.

C'est la même chose avec PGP / GnuPG. Vous pouvez détecter si un message a été modifié depuis qu'il a été terminé.

@Justice a dit que

Un cracker suffisamment expérimenté peut remplacer le fichier par une version modifiée de manière malveillante et le hash avec celui qui correspond au fichier modifié

Bien sûr, des collisions MD5 ont été trouvées. Et des collisions SHA-1 existent également. Mais pour citer Wikipédia:

Les fonctions de hachage cryptographique généralement utilisées aujourd'hui sont conçues pour être résistantes aux collisions, mais très peu d'entre elles le sont absolument. MD5 et SHA-1 en particulier ont tous deux publié des techniques plus efficaces que la force brute pour trouver des collisions. Cependant, certaines fonctions de compression ont la preuve que trouver une collision est au moins aussi difficile qu'un problème mathématique difficile (comme la factorisation d'entiers ou le logarithme discret). Ces fonctions sont appelées sécurisées de manière prouvée.

Et je ne pense pas qu’un "cracker suffisamment expérimenté" puisse trouver une "mauvaise version" ou créer un fichier / binaire / quel que soit l ' original que vous voulez et faites qu'il ait le même MD5 / SHA-1 que l'original. Et donnez-lui le même aspect (photo). Ou avec la même taille de fichier, ou même le faire fonctionner ou avoir un sens (texte). Pas même proche. Il peut le rendre non détecté pour l'antivirus (s'il est malveillant). C'est une autre histoire. Mais il y a de très mauvais cas de collisions signalés.

Alors, téléchargez à partir de TOUTE (bonne) source que vous aimez, mais comparez le hachage de la source d'origine . Et il y a toujours une source originale .

Vous semblez avoir le commentaire d'@Justice's confus. Ils ne disaient pas que Mallory pouvait modifier le lecteur VLC de telle sorte que le nouveau fichier (nous l'appellerons VLC-M) correspond au hachage de l'ancien. Ils disaient (et je suis) en train de dire que, comme il n'y a aucune signature numérique impliquée sur les sites ou fichiers en question, Mallory pourrait pirater le site Web de VLC, publier VLC-M à la place de VLC et changer le hachage publié de celui de VLC à celui qui correspond à VLC-M - et l'utilisateur n'aurait aucun moyen de savoir que cela s'est produit.
Hé bien oui. Dans ce cas, tous les paris sont désactivés. Mais ... 1) Zbot Authors Forge Kaspersky Digital Signature (http://news.softpedia.com/news/Zbot-Authors-Forge-Kaspersky-Digital-Signature-150817.shtml)2) Fichier infecté signé par Symantec Outlines Industry Problème (http://news.softpedia.com/news/Infected-File-Signed-by-Symantec-Outlines-Industry-Problem-152120.shtml)3) Nouveau logiciel malveillant lié à Stuxnet signé à l'aide d'un certificat de JMicron http: // news.softpedia.com/news/New-Stuxnet-Related-Malware-Signed-Using-Certificate-from-JMicron-148213.shtml Parlons-nous de la même chose?
Je pense que nous ne parlons toujours pas tout à fait la même langue ici. Je parle de fichier * hashes *, comme votre MD5 et SHA1 de base - en * absence * de signatures numériques. Des liens de nouvelles intéressants, cependant.
Bon point, @iszi. @labmice,, vos liens de nouvelles sont de bons exemples de la façon dont 1) un hachage signé numériquement doit encore être vérifié par rapport au logiciel en question, 2) parfois des éléments erronés sont signés, alors recherchez la dernière copie et 3) les clés de signature peuvent également être volées . Mais heureusement, la plupart des clés de signature sont bien mieux protégées que la plupart des sites, et comparées au grand nombre de sites Web compromis (où les hachages non signés pourraient être modifiés de manière triviale), les signatures numériques sont une énorme victoire.
#11
  0
mincewind
2014-12-18 11:09:41 UTC
view on stackexchange narkive permalink

Si vous y réfléchissiez vraiment, le fait d'avoir plusieurs sites pour héberger votre contenu téléchargeable, ainsi que les clés de hachage, arrêterait la plupart des attaques de remplacement de l'usine. Une fois de plus, l'hypothèse est le modèle de menace dans lequel l'attaquant devrait remplacer in situ plutôt qu'en transit. Même avec une seule source, les copies empêcheraient quiconque de remplacer à la fois le fichier et le hachage.

Et, les sources de fichiers peuvent être corrompues lors du téléchargement.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...