Question:
Le Wi-Fi public est-il une menace de nos jours?
Ay0
2017-12-04 21:15:55 UTC
view on stackexchange narkive permalink

À mon avis, les arguments que nous utilisons depuis des années pour dire que les points d'accès Wi-Fi publics ne sont pas sécurisés ne sont plus valables, tout comme les remèdes recommandés (par exemple, utiliser un VPN).

De nos jours , la plupart des sites utilisent HTTPS et définissent des en-têtes HSTS, de sorte que les chances que quelqu'un puisse espionner la connexion de quelqu'un d'autre sont très faibles, au point de s'attendre à une vulnérabilité zero-day dans TLS.

Alors, quelles autres menaces peuvent quelqu'un est actuellement confronté sur un réseau public?

Je ne sais pas si j'appellerais cela une menace autant qu'une vulnérabilité.Même si «la plupart» des sites utilisent HTTPS et définissent HSTS, «la plupart» n'est pas «tout».
@yzT Je ne peux penser à aucun argument des 10 dernières années qui a été utilisé par les gars de la sécurité grand public qui n'est plus valide.Oui HTTPS est utilisé.mais cela ne supprime pas tous les risques, pas plus que les en-têtes HTST (qui ne sont pas entièrement pris en charge par tous les navigateurs).
* "la plupart des sites utilisent HTTPS et définissent des en-têtes HSTS" * - il s'agit d'une réclamation sans preuve.Selon builtwith.com [seuls 12% des 10k meilleurs sites utilisent HSTS] (https://trends.builtwith.com/docinfo/HSTS).
pas pris en charge par tous les navigateurs?https://caniuse.com/#feat=stricttransportsecurity qui se soucie de netscape?
Un WiFi public cesse d'être une menace au moment où brancher un câble réseau de pirates sur votre ordinateur portable cesse d'être une menace.
@dandavis, all andriod pre 4.4 (encore courant sur les marchés de l'occasion et sur certaines parties du monde) IE pre 11 (donc gagnez 7 entre autres).2 groupes en utilisation active.
Les points d'accès Wifi que vous ne gérez pas ne sont pas sécurisés, ceci est toujours valide.(Ce que vous en faites est une question totalement différente.)
@PlasmaHH C'est un bon commentaire, même si je voudrais simplement noter que, à certains égards, le WiFi public peut être moins sécurisé que d'avoir un câble qui vous connecte directement aux pirates.Vous pouvez ignorer le trafic sur ce câble, et vous pouvez bloquer l'envoi de données sur ce câble, mais vous ne pouvez pas empêcher quiconque d'accéder à vos diffusions sur le réseau sans fil ni les empêcher de vous fournir une entrée.
Proposez-vous que les utilisateurs se limitent uniquement aux sites qu'ils ont déjà visités lorsqu'ils sont sur le WiFi public?
Cette position, comme indiqué, équivaut à dire "Tout le trafic réseau est désormais sécurisé car un protocole de publication anonyme a été piraté pour être légèrement plus difficile à manipuler le trafic."Ce qui est, bien sûr, une idée ridicule.Internet est beaucoup plus large que le Web et tout le trafic peut être effrayant (et HTTPS et HSTS sont des solutions incomplètes d'un point de vue de sécurité sérieux - et c'est généreux).Les réseaux ne seront jamais sécurisés (derrière NAT, VPN, peu importe), seul votre système peut être plus avancé ou derrière l'horizon du cracker.Le wifi public vous expose simplement * plus *.
Les pirates peuvent usurper HTTPS s'ils contrôlent le point d'accès Wi-Fi.C'est ainsi que fonctionne l'empoisonnement du cache.Où les fichiers JS sont remplacés dans le cache du navigateur par les propres fichiers JS du pirate.
@Aaron Comment «ignorer le trafic sur ce câble»?
@zxq9 Je ne sais pas ce que vous voulez dire: "Les réseaux ne seront jamais sécurisés"
@jpmc26 Passer à une URL HTTPS que vous avez reçue d'un canal sécurisé, vers un site Web d'une autre URL HTTPS doit être sécurisé
-1
@curiousguy Tout réseau connecté à Internet ne sera jamais sécurisé.Un réseau complètement isolé * peut * être (mais ne l'est généralement pas).Il y a toujours * un * moyen d'entrer, bien que le profil de menace auquel la plupart des utilisateurs sont confrontés n'inclut pas d'attaquants déterminés utilisant des ponts de type tempête ou sneakernet.En règle générale, «les réseaux ne seront jamais sécurisés» est exact.Supposer que des bits malveillants ne peuvent pas atteindre un système parce que le «réseau est sécurisé» est une mauvaise pensée - démontrée amplement à travers l'histoire.
@curiousguy En ignorant toutes les données qu'il contient.Si j'avais un port réseau supplémentaire directement connecté à un hôte malveillant connu, s'il était dans un environnement de type Unix, en particulier dans un système d'exploitation open source, il y aurait probablement plusieurs façons: refuser l'accès en écriture au fichier de cet appareil pour tousles utilisateurs, ou bloquer par pare-feu, ou modifier le système d'exploitation pour ignorer complètement cet appareil, ou tout ce qui précède et tout ce à quoi vous pourriez penser.Dans cette situation, quelqu'un déplacerait une montagne pour y arriver.Rien de tout cela ne diminue le point de PlasmaHH cependant;J'étais juste en train de choisir des lentes.
@curiousguy Là encore, malgré mon commentaire précédent, cette question est du point de vue d'une personne aléatoire qui est suffisamment compétente pour se préoccuper des problèmes de sécurité valides (c'est-à-dire: plus compétent que votre utilisateur moyen) mais probablement moins que la compétence professionnelle de l'informatique,qui se connecte juste à un réseau wifi aléatoire.Pour votre défense, une personne aussi aléatoire peut avoir du mal à faire ce que j'ai suggéré.
** HTTPS n'est plus une solution de sécurité **.Les proxys d'interception TLS sont monnaie courante: universités, entreprises, écoles, bureaux, FAI, cafés, etc. HTTPS ne peut pas être considéré comme «sécurisé» lorsqu'il est régulièrement pénétré à votre insu ou sans votre consentement.
Douze réponses:
Anders
2017-12-04 21:31:36 UTC
view on stackexchange narkive permalink

Le WiFi public n'est toujours pas sécurisé, et il le sera toujours s'il n'est pas utilisé avec quelque chose comme un VPN.

  • De nombreux sites Web utilisent HTTPS, mais pas presque tous. En fait, plus de 30% ne le font pas.
  • Seuls 5% environ des sites Web utilisent le HSTS. Et c'est toujours la confiance lors de la première utilisation. Si l'âge maximum est court, cette première utilisation peut être assez fréquente. Avouons-le, même si vous êtes un pro de la sécurité, il y a de fortes chances que vous tombiez de toute façon pour la bande SSL. Je sais que je le ferais.
  • Ce n'est pas parce que vous utilisez HTTPS que vous le faites correctement. Il y a encore beaucoup de contenu mixte là-bas. De nombreux clients prennent toujours en charge les anciennes versions avec des vulnérabilités connues, donc une attaque n'a pas besoin d'être un jour zéro pour réussir.
  • Même si vous utilisez HTTPS, vous perdez de toute façon beaucoup d'informations, telles que le domaine que vous visitez, tout votre trafic DNS, etc.
  • Un ordinateur ou un téléphone utilise Internet pour plus que la simple navigation:
    • Il suffit d'une application qui est défectueuse (ou non ) crypto pour sa fonction de mise à jour et vous êtes la propriété.
    • Toutes ces applications que vous avez autorisées à accéder à toutes sortes de données personnelles ... Ils téléphonent constamment à la maison et vous n'avez probablement aucune idée des données qu'ils envoient et que se passe-t-il s'il y a des crypto-monnaies qu'ils utilisent?
    • Dancrumb a plus d'exemples dans sa excellente réponse.
  • Défense en profondeur.

Un VPN est bon marché et c'est toujours un fruit à portée de main en matière de sécurité.

Un VPN ne résout pas vraiment ces choses.Cela ne fait que pousser l'exposition du FAI / point d'accès local au fournisseur de VPN, et de nombreux fournisseurs de VPN aujourd'hui ne sont pas vraiment très dignes de confiance à propos de ces choses en fin de compte.
@JoelCoehoorn Oui, bien sûr.Mais être le MITM sur un wifi public est simple.Etre un MITM à la sortie d'un tunnel VPN ... eh bien, cela demande du travail.Ne laissez pas le parfait être l'ennemi du bien.
@JoelCoehoorn Vous pouvez exécuter votre propre VPN si vous avez peur des autres fournisseurs de VPN.Et si vous ne pouvez pas faire confiance à votre propre FAI, le WiFi public n'est pas vraiment votre principal problème.
@JoelCoehoorn c'est essentiellement pourquoi vous avez des serrures sur une porte que vous pouvez ouvrir en 10 secondes.Vous voulez toujours que ce type passe ces 10 secondes d'effort et fasse beaucoup de bruit au lieu de simplement rentrer chez vous comme s'il était propriétaire de l'endroit.
Firefox bloque désormais le contenu mixte, ce qui est une bonne étape ici.
La solution à tout cela est évidemment Tor, mais cela a ses propres problèmes.Pas de problèmes techniques, autant que des problèmes d'utilisabilité dus à l'ignorance générale des administrateurs Web quant à ses cas d'utilisation pratiques.Bien que, même avec Tor, il puisse être difficile de rester complètement anonyme, mais loin d'être aussi difficile.
La plupart de ces «problèmes» ne dérangeront pas la plupart des gens.Même si je fais des opérations bancaires en ligne sur le wifi public, je me fiche que les gens sachent que je suis bancaire, quelle banque j'utilise, voir des images non chiffrées, etc. Tant que personne ne peut se connecter en tant que moi et prendre monl'argent, je m'en fiche.Même chose pour les achats chez Amazon, etc. Je me fiche de savoir si les gens peuvent voir ce que j'achète, tout comme je ne déguise pas ce que j'ai acheté quand je le ramène à la maison dans le train.Il serait bon de décrire les problèmes réels du monde réel pour les gens ordinaires, plutôt que "vous pourriez perdre des recherches DNS".
@DrEval Je pense que la plupart des points s'appliquent assez directement aux utilisateurs ordinaires.Les utilisateurs ordinaires visitent des sites qui n'utilisent ni HTTPS ni HSTS.Les utilisateurs ordinaires ont des applications qui ne déchiffrent pas correctement leurs mises à jour.Faire transmettre votre mot de passe en texte clair parce que vous avez été dépouillé de SSL ou que vous recevez des logiciels malveillants sur votre téléphone est un problème très réel pour les utilisateurs ordinaires.
Presque toutes les questions de sécurité VPN peuvent être résolues avec "Utiliser un VPN signifie que vous avez 2 fournisseurs d'accès Internet au lieu d'un seul".Quand on est extrêmement peu fiable (WiFi public), c'est une victoire évidente.
@WilliamTFroggard Tor est un outil d'obscurcissement - il ne vérifie pas que le site que vous consultez est bien celui qu'il prétend être.Vous pouvez le considérer comme un vaste réseau de serveurs proxy.Le FBI a [exploité avec succès Tor] (https://arstechnica.com/tech-policy/2016/06/fbis-use-of-tor-exploit-is-like-peering-through-broken-blinds/) et ila [de nombreuses faiblesses connues] (https://en.wikipedia.org/wiki/Tor_ (anonymity_network) #Weaknesses), donc je ne lui ferais pas confiance pour masquer votre trafic d'un attaquant déterminé et bien financé.
Assurez-vous d'utiliser un VPN sécurisé qui n'enregistre pas.
J'ai un routeur à la maison avec VPN et DynDNS intégrés - tous deux faciles à configurer pour les utilisateurs à domicile.Un domaine est très bon marché, donc ... profit.(juste pour mentionner que vous pouvez éviter les services VPN tiers généralement assez faciles).
Même les sites qui nécessitent HTTPS redirigeront généralement depuis HTTP, ce qui signifie qu'un attaquant MITM peut rediriger vers un site similaire à la place ...
@DrEval Le problème avec votre logique est que tout contenu chargé de manière non sécurisée dans une page peut être remplacé par n'importe quoi d'autre par un attaquant MITM.Un attaquant pourrait remplacer le contenu non sécurisé par du JavaScript qui peut faire des choses en utilisant votre session authentifiée ... comme en cliquant sur des boutons dans Amazon ou votre portail de compte bancaire ...
Dancrumb
2017-12-05 04:22:40 UTC
view on stackexchange narkive permalink

Je suis un peu surpris que personne n'ait signalé qu'il y a plus sur Internet que HTTP.

Même si vos affirmations sur HTTP (S) et HSTS étaient correctes (et d'autres réponses en parlent) , vous oubliez POP, SMTP, IMAP, FTP, DNS, etc. Aucun de ces protocoles n'est intrinsèquement sécurisé.

Votre point est très valide, et ce qui suit ne change pas vraiment cela, mais POP, SMTP, IMAP et FTP ont tous TLS intégré maintenant soit tunnelisé (POPS, IMAPS, etc.), soit intégré au protocole (STARTTLS, etc.), et DNS a DNSSEC qui ne cachera pas votre communication mais peut la protéger contre la falsification. Un VPN reste une solution appropriée au problème du wifi public.
Une attaque DNS MITM peut être particulièrement désagréable dans un environnement wifi public.Vous pouvez rediriger des groupes entiers de personnes vers de faux sites (ou envoyer tout le trafic via un proxy)
@fjw Les principaux systèmes d'exploitation effectuent-ils désormais la validation DNSSEC immédiate?Ce serait une victoire majeure, mais je ne peux pas imaginer que cela se produise réellement, étant donné à quel point il est encore floconneux sur mon Linux.À part cela, je ne ferais pas confiance aux clients de messagerie pour ne pas tomber dans le décapage STARTTLS, vraiment.
Bien que la plupart des gens ne lisent pas leurs e-mails via un client Web de nos jours?
@Shadur Pas si un utilisateur de messagerie PGP ne souhaite pas divulguer sa clé privée à l'opérateur du silo de messagerie Web.
@Shadur apparemment pas: https://emailclientmarketshare.com/
En fonction du système d'exploitation et des divers programmes d'arrière-plan (pilotes, etc.), votre ordinateur pourrait se rendre massivement vulnérable sans que vous sachiez le moment où vous vous connectez à un point d'accès.Il était une fois nos ordinateurs portables de travail (connexion réseau sécurisée protégée par clé RSA, etc.) MSN Messenger fonctionnait parfaitement avant même que vous ayez commencé le processus de connexion sécurisée au réseau car son protocole n'était pas capturé / filtré / etc.par la connexion supposée très sécurisée.
entrop-x
2017-12-04 21:49:35 UTC
view on stackexchange narkive permalink

Une autre difficulté de l'accès wifi public est que vous êtes sur le même réseau local que d'autres acteurs inconnus. Toute mauvaise configuration de vos autorisations de réseau local peut conduire à une intrusion dans votre appareil. Peut-être chez vous, vous avez configuré des données partagées sur votre réseau local. Désormais, tout le monde sur le même point d'accès wifi peut avoir accès à ces données partagées. Le plus souvent, cette protection est assurée par un pare-feu (que ce soit au bureau ou à domicile), et vous considérez le réseau local plus sécurisé que l'Internet nu. Mais cette fois, vous êtes peut-être sur le même réseau local qu'un attaquant.

Le problème avec ce point de vue est que le WiFi est si généralement peu sûr, sur une base régulière, qu'il est probablement bon de supposer que toute personne avec une motivation plus que minimale a accès à votre réseau WiFi domestique.Cela change la question en "quel est le compromis de coût de l'attaquant pour s'attaquer aux utilisateurs aléatoires sur des ordinateurs portables uniques sur le WiFi public par rapport aux réseaux domestiques?"
@Curt: un Wifi domestique bien configuré est normalement assez sûr.Bien sûr, si vous parlez de zéro jour, il peut y avoir des moyens, mais je ne vois pas pourquoi vous choisissez le wifi.Les jours zéro dans les routeurs câblés vous donnent également accès, et au moins, vous pouvez les utiliser à travers le monde.Avec un wifi public, ils sont déjà sur le réseau.Vous avez besoin d'un zero-day dans un routeur ou un wifi domestique, pour obtenir la même chose.
Je ne parle pas de Zero-days.En supposant que les réseaux WiFi sont généralement mal configurés dès le départ: une bonne sécurité prend en compte les utilisateurs et leurs compétences;la plupart des réseaux WiFi domestiques ne sont pas configurés par des ingénieurs réseau.De plus, même un réseau WiFi bien configuré a régulièrement eu des vulnérabilités, y compris, à plusieurs reprises, des problèmes dans les protocoles WiFi eux-mêmes.(Le dernier, il y a à peine deux mois, est KRAK.) Il n'y a pas de place ici pour entrer dans une analyse plus approfondie, mais je maintiens ma déclaration selon laquelle il est bon de travailler à partir de l'hypothèse que les attaquants ont accès à votre réseau WiFi.
(En passant, je vous suggère également de supposer que les attaquants ont un accès facile à votre réseau filaire à moins que vous n'ayez pris des précautions spéciales dans ce domaine. Cela aide peut-être à comprendre ce que je veux en venir ici.)
Gartral
2017-12-05 01:41:29 UTC
view on stackexchange narkive permalink

Je dirais que chaque fois que vous vous connectez à un réseau accessible au public, vous vous exposez à des risques, les VPN sont excellents, mais ne faites rien pour protéger votre machine contre les menaces sur le réseau local si vous, l'utilisateur, vous trompez et ouvrez dire: votre dossier privé pour le partager avec n'importe qui d'autre.

Une stratégie que j'ai employée et avec laquelle j'ai joué dans le passé lorsque sur un réseau public est le pot de miel à l'ancienne, partager un dossier avec un fichier et surveiller l'accès à ce fichier, déconnectez-vous immédiatement lorsqu'il y accède et vous savez que vous n'y avez pas accédé.

Je ne suis pas sûr de ce que gagne la procédure de votre dernier paragraphe ...
@GnP Fondamentalement, il suppose qu'un attaquant sur le réseau ira d'abord chercher les choses faciles (un dossier partagé public) et quand il (Gartral) voit que le fichier a été accédé, il se déconnecte de ce WiFi, sachant qu'il y a un attaquant dessus.
Je pense que c'est une grande hypothèse que la première chose qu'un attaquant va faire est de fouiner en utilisant SMB / CIFS, et même si c'est le cas, ils iraient demander les fichiers qu'ils voient sur le partage réseau.
Vous êtes sûr que cet attaquant ne commencera pas par exploiter un autre bogue de 0 jour dans SMB / CIFS?
J'ai _did_ dit "employé" Je n'utilise plus cette technique, elle a été conçue comme un point de départ pour réfléchir à l'analyse des menaces et commencer des recherches par lui-même pour la détection et l'atténuation des intrusions.@user1643723, chaque fois que vous installez un pot de miel, vous invitez essentiellement l'attaquant à creuser ses griffes dans votre système avec une grande enseigne au néon qui dit "Regardez! Shiny Data! Come'n get it!"
bobstro
2017-12-04 22:17:24 UTC
view on stackexchange narkive permalink

Une partie de l'inquiétude concerne les attaques MiTM et la tendance des ordinateurs portables à être configurés pour se connecter aveuglément à des réseaux ouverts basés sur le SSID après la connexion initiale. Rien n'empêche une partie inconnue de déclencher un point d'accès avec le même SSID que celui utilisé à d'autres endroits. Ainsi, même si une partie de votre trafic peut être protégée, une bonne partie ne le sera pas, et l'attaquant aura un chemin sur lequel il pourra tenter de compromettre votre ordinateur portable.

Dans la pratique, "une partie inconnue allumant un point d'accès" pourrait être un exploit / crime risqué relativement coûteux dont il pourrait tirer profit.Il faut noter que les attaques MiTM ont néanmoins proliféré, au moins dans certains domaines: parce que les points d'accès W-Fi sans mises à jour de sécurité (par exemple, qui sont anciens ou ne se mettent pas à jour automatiquement) sont un point faible énorme.https://arstechnica.com/information-technology/2019/07/website-driveby-attacks-on-routers-are-alive-and-well-heres-what-to-do/
Rui F Ribeiro
2017-12-05 20:27:19 UTC
view on stackexchange narkive permalink

À propos de l'utilisation des services Wifi publics, Tor et VPN peuvent toujours divulguer des informations.

Outre les implications de sécurité de Tor et VPN, vous devez toujours obtenir au moins les services DHCP du Wifi public.

En fonction des paramètres Wi-Fi, le service d'offre peut toujours ouvrir une fenêtre de navigateur (limitée) directement dans votre appareil, même lorsque vous utilisez un VPN si vous utilisez des technologies de réseau captif, et votre appareil sera exposé et parler en dehors du VPN dans une certaine mesure jusqu'à ce que vous vous authentifiiez dans le portail réseau captif.

IMO, c'est le plus gros éléphant dans la pièce de nos jours auquel les gens ne pensent pas - j'ai écrit une preuve de concept dans FreeBSD qui ouvre une photo du crâne dans le client, avant de vous rendre sur la route VPN, mes collègues n'étaient pas si amusés.

Je conseillerais que selon l'appareil, en plus de Tor ou / et VPN, vous devez au moins avoir les dernières mises à jour du système d'exploitation et un pare-feu finement réglé sur votre appareil

Donc en fait, non, HTTPS et les technologies associées ne sont qu'une (petite) partie de l'équation dans un paramètre de sécurité et ne vous offrent qu'un faux sentiment de sécurité lorsqu'ils sont utilisés en soi .

La plupart de ces réponses, jusqu'à la dernière phrase environ, se concentrent sur les limites de l'utilisation d'un VPN alors que la question porte vraiment sur les limites de l'utilisation de HTTPS.Bien que tout ce que vous dites semble correct, je ne suis pas sûr que ce soit pertinent pour la question.
@Anders Assez juste.Cependant, la question demande d'autres menaces en plus d'utiliser HTTPS
rackandboneman
2017-12-05 16:16:55 UTC
view on stackexchange narkive permalink

C'est exactement un scénario dans lequel le chiffrement semi-"opportuniste" (comme l'écosystème mixte en clair / chiffré HTTP / HTTPS) peut vous échouer - à tout le moins, vous devez compter sur votre navigateur pour ne pas ouvrir de manière inattendue une ressource intégrée dans un page Web via un protocole non sécurisé (même si un homme du milieu le rétrograde pour vous), et aussi sur les certificats douteux non acceptés. Pour chaque page, et pour tout ce que chaque page se charge.

Un VPN, comme mentionné, peut encore canaliser toutes sortes de trafic malveillant vers un point de terminaison vulnérable - et inversement.

En l'absence des logiciels malveillants vraiment problématiques comme les enregistreurs de frappe et les logiciels de contrôle à distance illicites, la configuration la plus sûre serait de contrôler un ordinateur distant de confiance via quelque chose comme un bureau à distance ou ssh (avec ou sans transfert X11), ce qui ferait passer tout le trafic pertinent via un canal crypté. L'établissement de ce canal nécessiterait toujours une diligence supplémentaire (par exemple, vérifier manuellement les empreintes de certificats) pour éviter tout risque restant d'attaques MITM (qui pourraient obtenir les informations de connexion d'un attaquant dans le pire des cas).

Emanuel Pirovano
2017-12-05 17:27:54 UTC
view on stackexchange narkive permalink

Comme le dit Norton, une entreprise de sécurité:

Quels sont les risques?

Le problème avec le Wi-Fi public est que il existe un nombre considérable de risques qui accompagnent ces réseaux. Alors que les propriétaires d'entreprise peuvent penser qu'ils fournissent un service précieux à leurs clients, il y a de fortes chances que la sécurité sur ces réseaux soit laxiste ou inexistante.

Attaques de l'homme du milieu

L'une des plus Les menaces courantes sur ces réseaux sont appelées une attaque de type Man in the Middle (MitM). Essentiellement, l'attaque aMitM est une forme d'écoute clandestine. Lorsqu'un ordinateur se connecte à Internet, les données sont envoyées du point A (ordinateur) au point B (service / site Web), et des vulnérabilités peuvent permettre à un attaquant de se placer entre ces transmissions et de les «lire». Donc, ce que les jeunes pensaient n'était plus privé.

Réseaux non chiffrés

Le chiffrement signifie que les messages envoyés entre votre ordinateur et le routeur sans fil sont sous la forme d'un "code secret", afin qu'ils ne puissent être lus par quiconque ne possède pas la clé pour déchiffrer le code. La plupart des routeurs sont expédiés de l'usine avec le cryptage désactivé par défaut, et il doit être activé lorsque le réseau est configuré. Si un professionnel de l'informatique configure le réseau, il y a de fortes chances que le cryptage ait été activé.Cependant, il n'y a pas de moyen sûr de savoir si cela s'est produit.

Distribution de logiciels malveillants

Merci à vulnérabilités logicielles, il existe également des moyens par lesquels les attaquants peuvent glisser des logiciels malveillants sur votre ordinateur sans même que vous le sachiez. Une vulnérabilité logicielle est une faille de sécurité ou une faiblesse trouvée dans un système d'exploitation ou un logiciel. Les pirates peuvent exploiter cette faiblesse en écrivant du code pour cibler une vulnérabilité spécifique, puis en injectant le malware sur votre appareil.

Snooping et sniffing

Le snooping et le sniffing Wi-Fi sont ce à quoi cela ressemble. Les cybercriminels peuvent acheter des kits logiciels spéciaux et même des appareils pour les aider à écouter les signaux Wi-Fi. Cette technique peut permettre aux attaquants d'accéder à tout ce que vous faites en ligne, de la visualisation de pages Web entières que vous avez visitées (y compris les informations que vous avez éventuellement remplies en visitant cette page Web) à la possibilité de capturer vos informations de connexion, et même de pouvoir détourner vos comptes. / p>

Hotspots malveillants

Ces «points d'accès non fiables» incitent les victimes à se connecter à ce qu'elles pensent être un réseau légitime car le nom semble réputé. Supposons que vous séjournez au Goodnyght Inn et que vous souhaitez vous connecter au Wi-Fi de l'hôtel. Vous pensez peut-être que vous avez sélectionné le bon lorsque vous cliquez sur "GoodNyte Inn", mais vous ne l'avez pas fait. Au lieu de cela, vous venez de vous connecter à un point d'accès non autorisé configuré par des cybercriminels qui peuvent désormais consulter vos informations sensibles.

Quand tout le monde connaît ces risques, la chose minimale à faire est de réduire les risques.

À ce sujet, vous pouvez lire quelques articles:

Bien que la citation de Norton soit intéressante, elle ne se concentre pas directement sur la question.La question est de savoir si HTTPS et HSTS ne répondent pas à ces préoccupations.La citation ne le mentionne pas vraiment.
Ce n'est pas l'objectif, mais la première question de cet article ne porte pas sur ce protocole, non?
La question pourrait être reformulée comme suit: "Quels sont les problèmes avec le wifi public que HTTPS ne résout pas?"J'ai l'impression que vous répondez à la question "Quels problèmes y a-t-il avec le wifi public?"
Donc cette question est une duplication de: https://security.stackexchange.com/questions/1525/is-visiting-https-websites-on-a-public-hotspot-secure
Personnellement, je dirais étroitement liés, mais pas en double.«Utiliser le wifi public» est une activité qui implique bien plus que «visiter des sites Web HTTPS sur le wifi public».Si vous n'êtes pas d'accord, vous pouvez marquer la question comme un doublon.
Je suis d'accord, je demandais seulement de comprendre le point.Merci
Damon
2017-12-07 17:35:07 UTC
view on stackexchange narkive permalink

Je ne suis pas sûr à 100% de votre préoccupation.

Les points d'accès Wi-Fi publics ne sont pas dignes de confiance, c'est vrai. Mais Internet n'est pas digne de confiance. Les sites que vous visitez ne sont pas dignes de confiance. Les sites que vous utilisez pour effectuer des recherches sur le Web ne sont particulièrement pas dignes de confiance.

Quelqu'un sur un point d'accès Wi-Fi public pourrait être en mesure d'écouter vos connexions. Quelqu'un , sans aucun doute écoutera toutes vos communications. Cela se produit régulièrement au sein de l'infrastructure du fournisseur, au CIX, aux frontières des pays et au niveau des câbles transocéaniques (et parfois transcontinentaux). Votre fournisseur de confiance peut très bien être autorisé et tenu par la loi (ils sont ici!) D'enregistrer et de stocker des statistiques détaillées sur chaque connexion que vous avez établie, toutes les requêtes DNS, peu importe, et de partager ces informations avec certains moyennement dignes de confiance et certains définitivement pas. des parties dignes de confiance, parmi lesquelles des organisations de pays hostiles.
Tous les principaux États du secteur (pas seulement les États-Unis) ont des organisations d'écoute de dix à cent mille personnes chacune, qui ne font qu'écouter vos communications et créer des profils sur vous en fonction de avec qui vous communiquez, lorsque vous communiquez, quels noms DNS vous résolvez, etc.

Est-ce un problème pour vous? Eh bien, si c'est le cas, n'utilisez pas vraiment Internet.

Quelqu'un sur un hotspot WiFi public pourrait essayer d'exploiter votre ordinateur. Eh bien, devinez quoi, quelqu'un pourrait également le faire via votre connexion Internet domestique. Ce n'est certainement pas aussi simple que d'être sur le même réseau local, mais c'est loin d'être impossible.
Mon vénérable ancien Windows 7 considérait déjà que faire confiance aux hotspots n'était pas une si bonne idée et considère que tous les hôtes ne sont pas approuvés dans ce cadre (à moins que vous ne lui disiez explicitement quelque chose de différent). Cela n'arrive pas sans raison. Mais avec des paramètres raisonnables, être sur un réseau local complètement hostile serait néanmoins raisonnablement sûr. Aucun des services qui ont été exploités au cours des deux dernières années ne fonctionne même sur mon ordinateur (indépendamment de la chute du trafic par le pare-feu). Ne fais pas de merde dont tu n'as pas besoin Moins il y a de services accessibles au réseau, moins il y a d'exploits (plus de RAM disponible et un démarrage plus rapide en bonus gratuit).

Il n'y a pas vraiment beaucoup de raisons d'utiliser un point d'accès WiFi public de toute façon (je ne me souviens pas avoir utilisé un). Une des raisons pourrait être que vous êtes sur la route et que vous devez faire quelque chose de vraiment important en ligne de toute urgence. OK, j'avoue, dans ce contexte, le WiFi public peut provoquer une mauvaise sensation dans l'estomac, mais à quelle fréquence cela se produit-il de toute façon. De plus, votre banque espérons-le utilise https: et vous pouvez vérifier si c'est le cas avant de saisir les informations de votre compte.

Bien que les gens le perçoivent de nos jours. ils doivent être en ligne et joignables toute la journée (soyez honnête, quand avez-vous éteint votre téléphone portable pour la dernière fois?) Ce n'est en fait pas vrai. Vous pouvez très bien effectuer vos opérations bancaires à domicile et vous n'avez pas vraiment besoin d'être en ligne 24h / 24 et 7j / 7 lorsque vous êtes en déplacement. En général, du moins.
Non, être chez Starbucks ne signifie pas que vous devez gazouiller à ce sujet et publier une photo de votre café sur Facebook. Qui s'en soucie de toute façon? Mais si vous pensez que cela est absolument nécessaire et que le WiFi public est trop effrayant, eh bien, utilisez la connexion LTE de votre smartphone (qui est légèrement plus sûre). Ce n'est pas comme si vous deviez utiliser le Wi-Fi public.

Une autre raison d'utiliser un WiFi public serait que vous envisagez de faire quelque chose d'illégal où vous ne voudriez pas que votre identité soit trop facilement identifiée. Bien sûr, vous ne voudriez pas faire des trucs illégaux lourds (vente d'armes, de drogue, de tabac à priser? Terrorisme?) De chez vous. Mais bon, dans ce cas, quel est le problème avec le hotspot qui n'est pas digne de confiance? Je veux dire, sérieusement? Un adolescent reniflant votre trafic sur le hotspot est le moindre de vos problèmes dans ce contexte.

Bon point indiquant que "Internet n'est pas digne de confiance".Mais pour être clair, le simple fait que votre banque utilise `` https: '' ne rend pas la connexion plus sécurisée, pas avec la prolifération des ** proxies d'interception TLS ** que nous avons, et l'état d'esprit selon lequel il est acceptable de pénétrer des connexions sécuriséesarbitrairement.
@Mac: C'est vrai, mais l'interception TLS se produit via un malware que vous _choisissez_ d'installer sur votre ordinateur (et pour lequel vous payez même généralement de l'argent).Les certificats racine installés sur la plupart des ordinateurs d'entreprise sont similaires, c'est délibéré.En gros, vous dites que vous êtes d'accord avec Kaspersky / Avast / Norton (ou un autre) pour lire votre trafic, tout comme vous êtes d'accord avec leur malware qui rend votre ordinateur inutilisable.Cela n'a rien à voir avec le Wifi ou Internet en tant que tel.C'est un choix personnel que vous pouvez faire ou non.TLS en tant que tel est, pour l'utilisateur ordinaire, assez sûr.
Point pris, mais je faisais référence à l'interception HTTPS qui se produit via des _hardware appliances_ comme le proxy Blue Coat de Symantec.
@Mac: Eh bien oui, étant une autorité de certification racine, Symantec peut, comme la plupart des gouvernements, voir à peu près tout.C'est, malheureusement, une partie de "l'Internet n'est pas digne de confiance" parce que toute confiance que nous avons est vraiment juste _une instance aléatoire_ disant qu'ils sont dignes de confiance, et tout le monde s'appuie sur cela.Cependant, je ne connais pas un meilleur système pour résoudre les problèmes de distribution des clés.Ce que PGP a inventé dans les années 90 n'était pas pratique, et l'échange d'enveloppes espion-espion dans une ruelle sombre est encore moins pratique.Vous devrez juste espérer que Symantec ne volera pas votre compte bancaire.
Blue Coat est fondamentalement la même chose que «installer un certificat racine personnalisé» comme sur les ordinateurs portables d'entreprise ou avec un antivirus, mais vous n'avez plus besoin de le faire car l'adversaire est déjà une autorité de certification (ou achète ce service auprès de cette autorité de certification) etainsi capable de générer n'importe quel certificat de montage qu'ils aiment.Alors oui, c'est pas de chance.Pourtant, l'utilisation de `https: //` le rend raisonnablement sûr contre les criminels _ normaux_.De plus, le gouvernement vole votre argent de toute façon (expropriation à froid), même si vous ne vous connectez jamais à votre banque.Il n'y a donc rien à craindre.
Mac
2017-12-06 10:20:53 UTC
view on stackexchange narkive permalink

De nos jours, la plupart des sites utilisent HTTPS et définissent des en-têtes HSTS, de sorte que les chances que quelqu'un puisse écouter la connexion de quelqu'un d'autre sont très faibles

Cette hypothèse est effrayante. Le nombre de sites qui définissent les en-têtes HSTS n'a pas d'importance si l'on ne peut pas compter sur HTTPS lui-même pour fournir une sécurité de point final à point final. Et ça ne peut pas. Malheureusement.

Avez-vous entendu parler d'un proxy d'interception TLS? Ils sont monnaie courante. Déployés dans les écoles, les universités et les bibliothèques et utilisés par les employeurs et les cafés, ces proxys matériels (tels que WebTitan Gateway ou Cisco ironPort WSA) rendent le HTTPS nul et non avenu, car lors de la connexion «sécurisée», ils introduisent un certificat dynamique prétendant être le certificat officiel du site Web de destination. Mon navigateur ne connaît pas la différence, et si je ne savais pas mieux, je ferais confiance à chaque connexion HTTPS sur son visage.

Au départ, HTTPS a été conçu pour empêcher les attaques MiTM. Aujourd'hui, le proxy TLS EST l'attaque MiTM! Que vous lisiez vos e-mails ou que vous vérifiiez le solde de votre compte bancaire, vous ne devriez pas vous faire d'illusions sur le fait que HTTPS fait réellement quoi vous vous attendez à ce qu'il fasse, c'est-à-dire sécuriser votre connexion contre les écoutes clandestines. Et à moins que vous ne vous connectiez via votre routeur WIFI domestique &, ou à moins que vous n'utilisiez un VPN décent, habituez-vous au fait que votre connexion est probablement décryptée et rechiffrée à la volée, à votre insu ou sans votre consentement.

Il n'y a guère besoin de considérer les "autres menaces" suggérées par l'OP jusqu'à ce que des connexions cryptées de bonne foi soient la norme. Actuellement, ils ne le sont pas, et HTTPS est une farce. (Pour éviter les écoutes clandestines, utilisez un VPN fiable géré par une entreprise qui ne stockera ni ne publiera aucun enregistrement. Utilisez TOR pour améliorer encore la connexion.)

Pourquoi est-ce que j'affirme que HTTPS / HSTS n'est pas vraiment la couverture de sécurité d'un navigateur Web? Parce que 3 ans avant que OP ne pose la question, elle était déjà exploitée et vaincue. Et juste 2 ans auparavant, il a été subverti. En outre, certaines implémentations populaires de SSL se sont avérées défectueuses dès 1998. Même les autorités de certification (CA) ne sont pas dignes de confiance. Une brève chronologie:

  • 1998 - Daniel Bleichenbacher décrit une attaque réussie sur PKCS # 1 v1.5, le (alors) RSA Encryption Standard (à CRYPTO 98); une attaque supposée nécessiter un million de messages d'attaque pour être exploitée
  • 2009 - Moxie Marlinspike crée SSLStrip pour attaquer HTTPS ( démo à Black Hat DC 2009)
  • 2012 - L'IETF nous donne la RFC 6797, qui implémente le HSTS, conçu pour contrecarrer le stripping SSL
  • 2012 - Graham Steel publie un article (au CRYPTO 2012) démontrant que l'attaque d'oracle de remplissage de Bleichenbacher nécessite moins de 15 000 messages - pas un million comme on le supposait à l'origine
  • 2014 - Leonardo Nve crée SSLStrip + pour éviter le HSTS ( démo à Black Hat Asia 2014)
  • 2015 - Sam Greenhalgh présente les Super Cookies HSTS, montrant comment le mécanisme de sécurité HSTS est facilement contourné être une atteinte à la vie privée
  • 2015 - Google se rend compte que Symantec et ses filiales ont frauduleusement émis plus de 30 000 certificats de sécurité sans audits ni divulgations appropriés
  • 2016 - Google institue une liste noire publiée de certificats non fiables les autorités, surnommé Submariner
  • 2017 - Ars Technica a rapporté que des sites majeurs tels que Facebook et PayPal ont été testés positifs pour la critique de Bleichenbacher, âgée de 19 ans vulnérabilité permettant aux attaquants de déchiffrer les données chiffrées et de signer des communications en utilisant la propre clé de chiffrement secrète des sites
  • 2018 - Google met à jour Chrome vers la version 70, afin de déprécier la confiance dans l'autorité de certification Symantec (y compris les marques appartenant à Symantec comme Thawte, VeriSign, Equifax, GeoTrust & RapidSSL); et Mozilla emboîte le pas
  • 2018 - Adi Shamir publie un article détaillant que les implémentations modernes de PKCS # 1 v1.5 sont tout aussi peu sûres contre le padding oracle attaques; affectant les protocoles Les services & comme AWS, WolfSSL et la dernière version de TLS 1.3 publiée en août 2018

Actuellement, pour lutter contre des problèmes tels que la "confiance transitive", les sous-CA et les manigances des CA qui les émettent, par exemple GeoTrust, etc., nous avons le protocole DANE, conçu pour "sécuriser" le certificat de sécurité - l'ironie est à ne pas manquer ici - via DNSSEC en permettant aux administrateurs de domaine de créer un TLSA Enregistrement DNS.

Si DANE était largement mis en œuvre, je serais peut-être plus enclin à être d'accord avec l'évaluation de la faible menace du PO, mais l'utilisation de DANE signifie qu'un site doit signer DNSSEC sa zone, et à partir du 2016, seulement environ 0,5% des zones en .com sont signées.

Comme alternative au DANE mal adopté, il existe des enregistrements CAA, conçus pour faire la même chose, mais ce dernier mécanisme n'est pas plus ancré que le premier.

C'est la fin de 2017, et les chances sont extrêmement bonnes quelqu'un peut espionner votre Connexion protégée HTTPS / HSTS.

MISE À JOUR DÉC 2018: Qu'il s'agisse de protocoles non sécurisés, de protocoles sécurisés mal mis en œuvre hors de la portée de l'utilisateur, d'une technologie sécurisée en attente d'adoption par le grand public, d'autorités frauduleuses délivrant des certificats non vérifiés, ou goo d ancienne écoute assistée par le matériel, nous sommes à la fin de 2018 et je maintiens toujours les chances sont extrêmement bonnes que votre connexion HTTPS ne vous protège pas.

Le certificat introduit par un proxy d'interception est rarement signé par une autorité de certification de confiance mondiale.Si tel était le cas, cette autorité de certification fait quelque chose de mal et ne devrait pas être approuvée.Si HPKP ou toute autre méthode d'épinglage de clé / certificat était utilisée avec HSTS, le proxy ne fonctionnerait pas de toute façon.
Pour les électeurs anonymes, je réfute simplement la base de l'affirmation du PO selon laquelle l'utilisation du HTTPS et du HSTS fait de l'écoute clandestine une possibilité "très faible".
Attendez ** quoi? ** Les chances sont * extrêmement * bonnes?Si vous ne pouvez pas faire confiance aux autorités de certification installées sur votre machine, veuillez les désinstaller et épingler vous-même les clés pour celles qui sont nécessaires.Avoir un vote défavorable * non * anonyme.
jonna_983
2017-12-05 13:31:51 UTC
view on stackexchange narkive permalink

Votre argument serait valable si tous les utilisateurs sans fil étaient conscients des implications en matière de sécurité associées à la navigation Web et aux réseaux wifi publics, donc non fiables. Le Wi-Fi n'est pas une menace autant que l'ingénierie sociale ne l'est pas non plus.

En un mot, WiFi&HTTPS ne comporte pas de vulnérabilités , mais cela ne signifie pas qu'ils ne constituent pas une menace .

vous semblez ne pas avoir compris la question - le problème posé ne concerne pas le wifi en lui-même, mais les utilisateurs malveillants partageant le réseau avec d'autres - et la question concerne la menace - vous dites qu'il pourrait y en avoir mais n'en parlez pas
également le wifi et https comportent des vulnérabilités
Je ne suis pas d'accord. OP affirme que les protocoles sont sûrs, donc le WiFi public est sûr. Les protocoles sont en effet sûrs (pas de vulnérabilités non corrigées pour 802.11 ou HTTPS atm - même KRACK est presque pris en charge) donc tous les problèmes proviennent d'utilisateurs qui ignorent involontairement ou négligemment les erreurs de sécurité ou les messages que les développeurs ont très soigneusement placés dans les navigateurs ou les systèmes d'exploitation.
@jonna_983 krack est loin d'être "pris en charge".De nombreux fabricants de téléphones ou de routeurs ne publient tout simplement pas de mises à jour, de nombreuses personnes ne mettent pas à jour, de nombreuses personnes utilisent d'anciens systèmes d'exploitation.Krack ne sera probablement presque «pris en charge» que dans une dizaine d'années.
@Avery, Je crois que votre réponse s'inscrit dans mon propos.Les utilisateurs ont été informés des implications en matière de sécurité de l'utilisation d'appareils non corrigés (par KRACK), mais ils choisissent toujours d'utiliser des moyens insuffisants. Quoi qu'il en soit, mon point général est que les utilisateurs reçoivent toutes sortes de notifications de sécurité lors de la navigation, ce qu'ils refusent de prendre en compte.
@jonna_983 1) vous supposez que les utilisateurs sont suffisamment avertis en technologie pour comprendre et patcher tous les périphériques 2) vous ignorez mon point de vue "certains sinon la plupart des périphériques ne reçoivent pas de correctifs de sécurité, en particulier les routeurs".3) Je n'ai jamais vu une telle notification.Je garde mon système à jour, mais je n'en ai quand même vu aucun, même sur les appareils de personnes qui ne mettent pas à jour leurs systèmes.
@jonna_983 Rien n'empêche quelqu'un d'abuser de l'UTF-8 (support punycode) pour rediriger vers un [site Web d'apparence identique] (https://www.xudongz.com/blog/2017/idn-phishing/) qui possède son propre certificat.Ce site Web Apple du PoC a une signature valide, mais ce n'est certainement pas celui d'Apple!Comparez https: //www.аррӏе.com avec https://www.apple.com et dites-moi si vous pouvez faire la différence avec les URL.
@forest Merci, j'en étais complètement inconscient.Il me manque peut-être quelque chose, mais il semble étrange que les autorités de certification racine n'empêchent pas ce type d'attaque car cela semble trivial à faire.
Comment pourraient-ils empêcher ce genre d'attaque?Il serait plus facile pour les navigateurs d'atténuer cela en affichant le punycode (c'est-à-dire https: //www.аррӏе.com vs https://www.xn--80ak6aa92e.com, bien que les deux soient identiques) pour les navigateurs avec une languequi ne nécessite pas unicode.
@forest OK, voilà. Quelqu'un essaie de délivrer un nom de domaine punycode: Si decode (punycode)! = Un nom de domaine connu pour lequel un certificat valide existe, enregistrez le domaine.
Ils ne décodent pas dans le même domaine, ils _spectent_ simplement la même chose.Il y a pas mal de personnages comme ça.Il est peut-être possible de conserver une table de caractères d'aspect identique et d'indiquer les domaines qui auraient autrement l'air identiques, mais ce n'est pas le travail des autorités de certification.Avoir une police de CA quelque chose comme ça pose des problèmes.De plus, ce serait le travail d'un serveur de noms, pas d'un CA.
Stilez
2017-12-05 12:15:30 UTC
view on stackexchange narkive permalink

Un protocole comme https ne peut être aussi sécurisé que le support sur lequel il est transmis, le permettra.

Cela signifie que même si tout ce que vous faites utilise HTTPS (ce n'est probablement pas le cas pour la plupart des gens) , et même si rien de votre côté n'est non sécurisé (c'est probablement le cas), l'attaquant peut cibler votre connexion au WiFi, votre connexion, rechercher des ports ouverts sur votre appareil et faire beaucoup pour contrôler la communication ou l'appareil, ce qui https aussi efficace qu'une serrure sur une porte avec une porte ouverte à côté.

Je ne comprends pas le point.Si rien de mon côté n'est dangereux, alors pourquoi une analyse de port est-elle une menace?Et que signifie «cibler votre connexion»?
Je pense que ce que vous voulez dire, c'est qu'être connecté au wifi en lui-même pose des menaces pour la sécurité et que les VPN et HTTP sont secondaires par rapport à ces autres menaces locales.Mais est couvert par d'autres réponses.
Que peut faire exactement l'attaquant si seul HTTPS est utilisé?
Faux / empoisonner le DNS pour une chose.Simulation du port captif.Modification des en-têtes pour forcer une forme de cryptage plus faible avant que https puisse être complètement établi.Utilisations qui reposent uniquement sur des métadonnées, telles que le harcèlement (si vous voulez suivre une personne ou vérifier si elle est dans la pièce, vous n'avez pas besoin de casser https, bien qu'il s'agisse strictement d'un problème de WiFi et non d'un problème d'AP).DoS sur leur VPN ou autre accès sécurisé qui peut revenir à une route moins sécurisée.Tentatives illimitées de recherche de vulnérabilités (le périphérique final n'est pas derrière un pare-feu séparé).


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 3.0 sous laquelle il est distribué.
Loading...