LE PRIX DE LA FAST FASHION
Lucky Treize ! Le prix de fast fashion. Firefox correctifs. Fonction fluage échec réduit dans Patch mardi.
Pas de lecteur audio ci-dessous ? Écouter directement sur Soundcloud.
Avec Paul Ducklin et Chester Wisniewski. Musique d'intro et d'outro par Edith Mud.
Vous pouvez nous écouter sur Soundcloud, Podcasts Apple, Podcasts Google, Spotify, piqueur et partout où l'on trouve de bons podcasts. Ou déposez simplement le URL de notre flux RSS dans votre podcatcher préféré.
LIRE LA TRANSCRIPTION
[MODÈME MUSICAL]
CANARD. Bonjour tous le monde.
Bienvenue dans le podcast Sophos Naked Security.
Comme vous pouvez l'entendre, je suis Duck ; Je ne suis pas Doug (Doug est en vacances).
Je suis donc une fois de plus rejoint par mon ami et collègue Chester Wisniewski.
Bienvenue, Chester.
C'est super de t'avoir !
CHET. Merci, canard.
Je pensais juste… en fait, je regarde mon écran pendant que vous présentez le podcast, et j'ai réalisé qu'aujourd'hui est le 13e anniversaire du lancement du podcast ChetChat, avant qu'il ne se retire et ne devienne finalement ce podcast.
Donc vous et moi sommes là depuis 13 ans !
CANARD. Chanceux 13, hein ?
CHET. Oui!
CANARD. Eh bien, comme le temps passe vite quand on s'amuse.
CHET. Oui, et c'est * amusant *.
Et je me sens vraiment honoré d'être à la place d'Andy Greenberg.
Vous avez vraiment intensifié le jeu depuis ma dernière apparition sur le podcast [RIRES].
CANARD. [RIRES] C'était un type très amusant à qui parler.
Je ne sais pas si vous avez lu ce livre que nous avons présenté sur le podcast avec lui : Traceurs dans le noir?
Tracers in the Dark : la chasse mondiale aux seigneurs du crime de la crypto
CHET. Absolument oui.
CANARD. C'est juste une histoire fascinante, très bien racontée.
CHET. Oui, je veux dire, c'était certainement le meilleur livre sur ce sujet que j'ai lu…
…probablement depuis Countdown to Zero Day, et c'est un très grand éloge de ma part.
CANARD. Chester, commençons par notre premier sujet d'aujourd'hui, qui est... Je vais juste lire le titre de l'article de Naked Security : L'application d'achat SHEIN devient malveillante, récupère les données de prix et d'URL de votre presse-papiers.
Un rappel que même les applications qui ne sont pas ouvertement malveillantes peuvent faire des choses dangereuses qui collectent des données qui étaient une bonne idée à l'époque…
… mais ils n'auraient pas dû.
CHET. Oui - tout ce qui touche mon presse-papiers déclenche immédiatement toutes sortes de sonnettes d'alarme dans ma tête à propos des choses terribles que j'imagine qu'ils font.
Et cela soulève en quelque sorte la question, si j'étais un développeur, même si je faisais quelque chose d'innocent… ce que je suppose que nous y reviendrons dans une seconde.
Il est difficile de dire à quel point ce qu'ils essayaient de faire était innocent.
CANARD. Exactement.
CHET. Lorsque vous demandez ce genre de permission, toutes sortes de sonnettes d'alarme se déclenchent dans ma tête.
C'est un peu comme sur un téléphone Android, pendant longtemps, pour utiliser Bluetooth pour trouver un appareil IoT, l'autorisation dont vous aviez besoin était "Accéder aux appareils à proximité", ce qui nécessitait Bluetooth.
Et vous obtenez cet avertissement poilu sur l'écran, "Ceci veut connaître votre position."
Et vous allez, "Pourquoi cette ampoule intelligente a-t-elle besoin de connaître ma position?"
Lorsque vous dites que vous accédez à mon presse-papiers, mon esprit se demande : "Pourquoi cette application essaie-t-elle de voler mes mots de passe ?"
C'est peut-être quelque chose que nous devrions clarifier pour les gens…
… parce que je pense que lorsque vous dites "Mettre le contenu du presse-papiers dans l'application", il y a des moments où * vous * le faites (vous pouvez choisir de copier votre mot de passe, ou peut-être que le code SMS à deux facteurs des Messages app, puis collez-le dans l'application dans laquelle vous vous authentifiez)…
CANARD. Oui.
CHET. Ce n'est *pas* ce dont nous parlons lorsque nous parlons de cette autorisation, n'est-ce pas ?
Cette autorisation est l'application elle-même qui ne fait que jeter un coup d'œil sur le contenu de votre presse-papiers existant à tout moment...
… pas lorsque vous interagissez activement avec l'application et que vous appuyez longuement et que vous dites "Coller".
CANARD. Exactement.
Fondamentalement, c'est faire une pâte quand vous ne l'avez pas voulu.
Peu importe à quel point les données que vous avez choisi de copier dans le presse-papiers peuvent être innocentes, il ne devrait vraiment pas appartenir à une application aléatoire de décider : « Hé, je vais juste le coller parce que j'en ai envie. ”
Et il est particulièrement difficile de le coller dans une requête Web qu'il a envoyée à une API marketing RESTful au siège social !
CHET. Ce n'est même pas un comportement attendu, n'est-ce pas, Duck ?
Je veux dire, si je suis dans mon application bancaire et qu'elle demande le code du SMS…
… Je pourrais voir comment il demanderait à l'application de messagerie texte de le copier dans le presse-papiers et de le coller automatiquement, pour simplifier ce flux.
Mais je ne m'attendrais jamais à ce que quoi que ce soit de mon presse-papier se retrouve dans une application de mode !
Eh bien, n'utilisez pas d'applications si vous n'en avez pas besoin.
C'est, je pense, un gros problème ici.
Je vois constamment, quand je vais sur n'importe quel type de site d'achat maintenant, je reçois des pop-up horribles dans mon Firefox sur mon téléphone en disant : « Est-ce que je veux installer l'application ? Pourquoi est-ce que je n'accède pas au site via l'application ? Est-ce que je préférerais utiliser l'application ? »
Et la réponse est NON, NON et NON, car c'est le genre de chose qui se produit lorsque vous avez du code non fiable.
Je ne peux pas faire confiance au code simplement parce que Google dit que c'est OK.
Nous savons que Google n'a pas de véritables applications de dépistage humain… Google est géré par une monstruosité Google Chat-GPT ou quelque chose du genre.
Ainsi, les choses sont simplement filtrées de la manière que Google juge appropriée pour les filtrer, puis elles se retrouvent dans le Play Store.
Donc, je n'aime tout simplement aucun de ces codes.
Je veux dire, il y a des applications que je dois charger sur mon appareil, ou des choses auxquelles je pense avoir plus confiance en fonction des éditeurs…
… mais en général, il suffit d'aller sur le site internet !
CANARD. Quiconque écoute le podcast Naked Security sait, à partir du moment où nous parlons de choses comme les jours zéro du navigateur, à quel point les fabricants de navigateurs déploient des efforts pour trouver et supprimer les bogues de leur code.
CHET. Et les gens peuvent également se rappeler que vous pouvez également faire en sorte que presque tous les sites Web se comportent comme une application de nos jours.
Il y a ce qu'on appelle les Progressive Web Apps, ou PWA.
CANARD. Chester, passons à la prochaine histoire de la semaine dernière, une histoire que j'ai trouvé intéressante.
J'ai écrit ceci simplement parce que j'aimais le numéro, et qu'il contenait des problèmes intéressants, à savoir: La version 111 de Firefox a corrigé 11 trous CVE, mais il n'y avait pas 1 zero-day.
(Et c'est mon excuse pour avoir un titre avec le chiffre 1 répété six fois.) [RIRES]
Firefox 111 corrige 11 trous, mais pas 1 zero-day parmi eux…
CHET. [RIRES] Je suis un fan de Firefox et c'est agréable de voir qu'il n'y a rien découvert qui soit activement exploité.
Mais la meilleure partie à ce sujet est qu'ils incluent ces problèmes de sécurité de la mémoire qui ont été découverts de manière préventive, n'est-ce pas ?
Ils ne les attribuent pas à une personne ou à une partie extérieure qui a découvert quelque chose et le leur a signalé.
Ils sont juste en train de chasser activement et nous font savoir qu'ils travaillent sur des problèmes de sécurité de la mémoire…
… ce que je trouve vraiment bien.
CANARD. Ce que j'aime avec Mozilla, c'est que toutes les quatre semaines, quand ils font la grosse mise à jour, ils prennent tous les bogues de sécurité de la mémoire, les mettent dans un petit panier et disent : « Vous savez quoi ? Nous n'avons pas vraiment essayé de déterminer si ceux-ci étaient exploitables, mais nous allons quand même leur donner un numéro CVE…
… et admettre que bien que ceux-ci ne soient peut-être pas réellement exploitables, il vaut la peine de supposer que si quelqu'un a essayé assez fort, ou avait la volonté, ou avait l'argent derrière lui, ou voulait juste assez mal pour le faire (et il y a des gens dans tous ces catégories), vous devez supposer qu'ils trouveraient un moyen d'exploiter l'une d'entre elles d'une manière qui serait à votre détriment. »
Et vous avez une petite histoire sur quelque chose que vous avez aimé, en dehors de Firefox, ou Mozilla, stable…
CHET. Absolument - je pensais justement à ça.
Nous parlions, avant le podcast, d'un projet appelé Servo que Firefox (ou la Fondation Mozilla, finalement) a créé.
Et, comme vous le dites, c'est un moteur de rendu de moteur de navigateur (actuellement celui de Mozilla Firefox s'appelle Gecko)... l'idée était d'écrire le moteur de rendu entièrement en Rust, et en fait c'était l'inspiration pour créer le langage de programmation Rust.
Le point important ici est que Rust est un langage sécurisé en mémoire.
Vous ne pouvez pas commettre les erreurs corrigées dans ces CVE.
Ainsi, dans un monde de rêve, vous feriez ce blog de mise à jour de Firefox sans les CVE de sécurité de la mémoire.
Et j'étais assez excité de voir que des fonds allaient à la Fondation Linux pour continuer à développer Servo.
Peut-être que, dans le futur, ce sera un nouveau moteur Firefox qui nous rendra encore plus sûrs ?
CANARD. Oui!
Soyons clairs - ce n'est pas parce que vous écrivez du code dans Rust qu'il est correct, et cela ne le rend pas immunisé contre les vulnérabilités.
Mais, comme vous le dites, il y a toutes sortes de problèmes, en particulier liés à la gestion de la mémoire, qui sont, comme vous le dites, beaucoup, beaucoup plus difficiles à résoudre.
Et dans un code bien écrit, même au moment de la compilation, le compilateur devrait être capable de voir que "ce n'est pas correct".
Et si cela peut être fait automatiquement, sans tous les frais généraux dont vous avez besoin dans un langage de script qui fait quelque chose comme le ramasse-miettes, donc vous obtenez toujours de bonnes performances, ce sera intéressant.
Je me demande juste combien de temps cela prendra?
CHET. On dirait qu'ils le prennent par petites bouchées.
Le premier objectif est de faire fonctionner le rendu CSS2, et c'est comme si vous deviez prendre chaque chose comme un petit bloc de travail, et le séparer de la monstruosité géante qu'est un moteur de rendu moderne... et prendre quelques petites bouchées.
Et le financement de ces projets est vraiment important, non ?
Beaucoup de choses intègrent des moteurs de navigateur ; de nombreux produits sont basés sur le moteur Gecko, ainsi que Blink de Google et Webkit d'Apple.
Et donc plus de compétition, plus de performances, plus de sécurité mémoire… c'est tout bon !
CANARD. Alors, passons au dernier sujet de la semaine, qui, je suppose, est la grande histoire…
… mais la bonne chose à ce sujet, comme le disent les grandes histoires, c'est que même s'il contient des bogues fascinants, et bien que les deux bogues dont nous finirons probablement par parler étaient techniquement des jours zéro, ils ne sont pas catastrophiques .
Ils ne sont qu'un bon rappel du type de problèmes que les bogues peuvent causer.
Et ce sujet, bien sûr, est Patch Tuesday.
Microsoft corrige deux 0 jours sur Patch Tuesday – mettez à jour maintenant !
CHET. Eh bien, je vais être controversé et parler de la Marque du Web bogue d'abord.
CANARD. [RIRES] C'est un nom tellement accrocheur, n'est-ce pas ?
Nous savons tous qu'il s'agit de « zones Internet », comme au bon vieux temps d'Internet Explorer.
Mais "Mark of the Web"... ça sonne tellement plus grandiose, et plus excitant, et plus important !
CHET. Eh bien, pour vous, les administrateurs d'Internet Explorer (IE), vous vous souvenez probablement que vous pouviez définir cela dans la zone de confiance ; que dans la Zone Intranet ; l'autre dans la zone Internet.
C'est de ce paramètre dont nous parlons.
Mais cela ne vit pas seulement dans Internet Explorer, il est également observé par de nombreux autres processus Microsoft, pour donner la provenance d'où provient un fichier…
…sur le concept que les fichiers extérieurs sont bien plus dangereux que les fichiers intérieurs.
Et donc cette prémisse même avec laquelle je ne suis pas d'accord.
Je pense que c'est une chose stupide!
Tous les fichiers sont dangereux !
Peu importe où vous les avez trouvés : dans le parking sur une clé USB ; sur le réseau local ; ou sur un site Internet.
Pourquoi ne les traiterions-nous pas tous comme s'ils n'étaient pas dignes de confiance, et ne ferions-nous pas des choses terribles ?
CANARD. Je pense que je peux voir où Microsoft vient d'ici, et je sais qu'Apple a une chose similaire… vous téléchargez un fichier, vous le laissez traîner dans un répertoire quelque part, puis vous y revenez trois semaines plus tard.
Mais je pense que je suis enclin à être d'accord avec vous sur le fait que lorsque vous commencez à dire "Eh bien, ce fichier vient de l'intérieur du pare-feu, il faut donc lui faire confiance"…
… c'est encore une fois le bon « intérieur moelleux et moelleux » à l'ancienne !
CHET. Oui.
C'est pourquoi ces types de bugs qui vous permettent de contourner Mark of the Web sont problématiques, n'est-ce pas ?
De nombreux administrateurs auront une stratégie de groupe qui dit: "Microsoft Office ne peut pas exécuter de macros sur des fichiers avec Mark of the Web, mais sans Mark of the Web, nous vous permettons d'exécuter des macros, car le service financier les utilise dans des feuilles de calcul Excel et tout les gestionnaires doivent y accéder.
Ce genre de situation… cela dépend du fait que ce fichier provient de l'intérieur ou de l'extérieur, malheureusement.
Et donc je suppose que ce à quoi je voulais en venir, ce dont je me plaignais, c'est de dire : cette vulnérabilité permettait aux gens de vous envoyer des fichiers de l'extérieur, et de ne pas les faire marquer comme s'ils provenaient de l'extérieur.
Et parce que ce genre de choses peut arriver, et arrive, et parce qu'il y a d'autres façons que cela peut arriver aussi, que vous avez gentiment souligné dans votre article sur la sécurité nue…
… cela signifie que votre politique devrait être : si vous pensez que les macros peuvent être dangereuses, vous devez les bloquer ou forcer l'invite à les activer, *quelle que soit leur origine*.
Vous ne devriez pas avoir une politique qui fait la distinction entre l'intérieur et l'extérieur, car cela vous expose simplement au risque qu'elle soit contournée.
CANARD. Absolument.
Je suppose que l'essentiel ici est que bien qu'un contournement de cette "marque" du Web (l'étiquette de la zone Internet sur un fichier)… bien que ce soit quelque chose qui est évidemment utile aux escrocs, car ils savent que certaines personnes comptent sur, * c'est le type d'échec que vous devez prévoir de toute façon*.
Je comprends l'idée de Mark of the Web, et je ne pense pas que ce soit une mauvaise idée.
Je ne l'utiliserais tout simplement pas comme un discriminateur significatif ou important en matière de cybersécurité.
CHET. Eh bien, et pour rappeler aux administrateurs informatiques…
… la meilleure approche pour résoudre ce problème n'est pas de regarder Mark of the Web.
La meilleure approche consiste à signer vos macros internes, afin de savoir lesquelles faire confiance et de bloquer toutes les autres.
CANARD. Absolument.
Pourquoi n'autorisez-vous pas simplement les choses dont vous savez que vous avez absolument besoin, et auxquelles vous avez une bonne raison de faire confiance…
… et comme vous le dites, interdire tout le reste ?
Je suppose qu'une réponse est : « C'est un peu plus difficile », n'est-ce pas ?
Ce n'est pas aussi pratique…
CHET. Eh bien, cela enchaîne avec l'autre vulnérabilité, qui permet aux criminels d'exploiter Microsoft Outlook d'une manière qui pourrait permettre…
… Je suppose, une attaque par usurpation d'identité ?
C'est comme ça que tu l'appellerais, Duck ?
CANARD. Je pense à celui-ci comme une sorte d'attaque de manipulateur au milieu (MitM).
Le terme que j'ai généralement entendu utilisé, et que Microsoft utilise… ils l'appellent un attaque de relais, essentiellement où vous incitez quelqu'un à s'authentifier auprès de * vous *, tandis que * vous * vous authentifiez en son nom, en tant qu'eux, dans les coulisses, avec le vrai serveur.
C'est l'astuce - en gros, vous obtenez quelqu'un, sans vous en rendre compte, pour dire: «Hé, j'ai besoin de me connecter à ce serveur dont je n'ai jamais entendu parler auparavant. Quelle bonne idée! Laissez-moi leur envoyer un hachage de mon mot de passe !
Qu'est ce qui pourrait aller mal?
Beaucoup…
CHET. C'est un autre excellent exemple d'une politique restrictive par rapport à une politique permissive, n'est-ce pas ?
Si votre pare-feu n'est pas configuré pour autoriser le trafic SMB (blocage des messages du serveur) sortant, vous n'êtes pas exposé à cette vulnérabilité.
Non pas que vous ne devriez pas le patcher… vous devriez quand même le patcher, parce que les ordinateurs vont dans beaucoup d'endroits où toutes sortes de choses loufoques se produisent sur le réseau.
Cependant, l'idée est que si votre politique est « Bloquez tout et n'autorisez que les choses qui devraient se produire », alors vous êtes moins à risque dans ce cas que si elle est permissive, et vous dites : « Nous allons tout autoriser, sauf les choses que nous avons déjà identifiées comme étant mauvaises.
Parce que lorsqu'un jour zéro arrive, personne ne l'a identifié comme étant mauvais.
C'est pourquoi c'est un jour zéro !
CANARD. Exactement.
Pourquoi voudriez-vous que les gens se connectent à des serveurs externes aléatoires, de toute façon ?
Même s'ils n'étaient pas malveillants, pourquoi voudriez-vous qu'ils passent par une sorte d'authentification de type entreprise, avec leurs informations d'identification d'entreprise, sur un serveur qui ne vous appartient pas ?
Cela dit, Chester, je suppose que si vous pensez au "centre moelleux", il y a un moyen pour les escrocs qui sont déjà dans votre réseau et qui ont un peu de prise de pied, de l'utiliser à l'intérieur du réseau …
… en configurant un serveur de fichiers malveillant et en vous incitant à vous y connecter.
CHET. [RIRES] Est-ce un BYOD ?
Un conteneur Docker Apportez votre propre ?
CANARD. [RIRES] Eh bien, je ne devrais pas vraiment rire là, mais c'est assez populaire auprès des escrocs ces jours-ci, n'est-ce pas ?
S'ils veulent éviter que des choses comme leurs logiciels malveillants ne soient détectés, ils utiliseront ce que nous appelons des techniques de « vivre de la terre » et emprunteront simplement des outils que vous avez déjà installés…
… comme curl, bash, PowerShell et des commandes qui sont absolument partout de toute façon.
Sinon, s'ils le peuvent, ils lanceront simplement une VM [machine virtuelle]…
… s'ils ont accès d'une manière ou d'une autre à votre cluster de machines virtuelles et qu'ils peuvent configurer une machine virtuelle d'apparence innocente, ils exécuteront le logiciel malveillant à l'intérieur.
Ou leur conteneur Docker sera simplement configuré complètement différemment de tout ce que vous avez.
Donc, oui, je suppose que vous avez raison : c'est une façon d'exploiter cela en interne.
Mais je pensais que c'était un bogue intrigant, parce que généralement, quand les gens pensent aux attaques par e-mail, ils pensent normalement : "Je reçois l'e-mail, mais pour être pwné, je dois soit ouvrir une pièce jointe, soit cliquer sur un lien".
Mais celui-ci, je crois, peut se déclencher pendant qu'Outlook prépare l'e-mail, avant même qu'il ne vous l'affiche !
Ce qui est assez méchant, n'est-ce pas ?
CHET. Oui.
Je pensais que l'époque de ce genre de bugs était révolue lorsque nous nous sommes débarrassés des plugins JavaScript et ActiveX dans nos clients de messagerie.
CANARD. J'ai pensé que tu allais dire "Flash" pendant un moment, Chester. [DES RIRES]
CHET. [DES RIRES]
Eh bien, pour les développeurs, il est important de se rappeler que ces types de bogues proviennent du fluage des fonctionnalités.
Je veux dire, la raison pour laquelle les e-mails sont devenus plus sûrs est que nous avons en fait supprimé des fonctionnalités, n'est-ce pas ?
CANARD. Correct.
CHET. Nous nous sommes débarrassés d'ActiveX et de JavaScript, et de toutes ces choses…
…et puis ce pépin était déclenché par le son « reçu un nouvel e-mail » étant une variable qui peut être envoyée par l'expéditeur d'un e-mail.
Je ne sais pas qui, sur quelle planète, a pensé : "Cela semble être une bonne fonctionnalité."
CANARD. La preuve de concept que j'ai vue pour cela, qui est produite par (je pense) une société de tests d'intrusion… c'est comme ça qu'ils l'ont fait.
Il semble donc que les escrocs qui exploitent cela, c'est comme ça * ils * le faisaient.
Mais il n'est en aucun cas clair que c'est la seule fonctionnalité qui pourrait être abusée.
Si j'ai bien compris, si vous pouvez dire "Voici un nom de fichier que je veux que vous utilisiez", alors ce nom de fichier, apparemment…
… eh bien, vous pouvez simplement mettre un chemin UNC là-dedans, n'est-ce pas ?
\SOMEBODY.ELSES.SERVER.NAME… et qui sera accessible par Outlook.
Donc, vous avez raison : cela ressemble effectivement à un fluage de fonctionnalités.
Et, comme je l'ai dit, je me demande à combien d'autres fonctionnalités manquantes cela pourrait s'appliquer, et si celles-ci ont également été corrigées ?
Microsoft était un peu discret sur tous les détails, probablement parce que cette chose était exploitée à l'état sauvage.
CHET. Je peux résoudre ce problème en un mot.
Cabot. [Un client de messagerie historique en mode texte uniquement.]
CANARD. Oui, Mutt !
Orme, pin, mailx, mail…
…netcat, Chester !
CHET. Vous avez oublié le chat.
CANARD. Je pensais à netcat, où vous parlez en fait de manière interactive au serveur de messagerie à l'autre bout.
CHET. [RIRES] Vous ne pouvez recevoir des e-mails que lorsque vous êtes au clavier.
CANARD. Si vous corrigez, espérons qu'il traite réellement de tous les endroits d'Outlook où un fichier peut être consulté, et que ce fichier se trouve simplement sur un serveur distant…
…Alors Outlook dit : "Hé, pourquoi n'essaierais-je pas de me connecter au serveur pour vous ?"
Maintenant, Chester, lorsque nous en parlions avant le podcast, vous avez fait une observation intéressante : vous avez été surpris que ce bogue apparaisse dans la nature, car de nombreux FAI bloquent le port SMB 445, n'est-ce pas ?
Pas à cause de ce bogue d'authentification, mais parce que c'était l'un des principaux moyens de propagation des vers de réseau…
… et tout le monde en a eu tellement marre il y a 10, 15, 20 ans que les FAI du monde entier ont simplement dit : « Non. Je ne peux pas le faire. Si vous voulez débloquer le port 445, vous devez sauter à travers des cerceaux ou nous payer de l'argent supplémentaire.
Et la plupart des gens ne se sont pas donné la peine.
Vous pourriez donc être protégé contre cela par accident plutôt que par conception.
Serais-tu d'accord avec ça?
CHET. Oui, je pense que c'est probable.
La plupart des FAI dans le monde le bloquent.
Je veux dire, vous pouvez imaginer dans Windows XP, il y a des années, combien d'ordinateurs étaient sur Internet, sans mot de passe, assis directement sur leurs connexions Internet avec le partage C$ exposé.
On ne parle même pas d'exploits ici.
Nous ne parlons que de personnes avec ADMI|N$ et C$ flottant au vent !
CANARD. Si c'est ainsi que vous êtes protégé (c'est-à-dire que cela ne fonctionne pas parce que votre FAI ne le laisse pas fonctionner)…
… n'utilisez pas cela comme excuse pour ne pas appliquer le patch, n'est-ce pas ?
CHET. Oui, absolument.
Vous ne voulez même pas que les tentatives se produisent, et encore moins qu'elles réussissent.
La plupart d'entre nous voyageons, n'est-ce pas ?
J'utilise mon ordinateur portable au café ; puis j'utilise l'ordinateur portable au restaurant ; puis j'utilise l'ordinateur portable à l'aéroport.
Qui sait ce qu'ils bloquent ?
Je ne peux pas compter sur le port 445 bloqué…
CANARD. Chester, je pense qu'on ferait mieux de s'arrêter là, parce que je suis conscient du temps.
Donc, merci beaucoup d'avoir pris le micro au pied levé.
Serez-vous de retour la semaine prochaine ?
Vous l'êtes, n'est-ce pas ?
CHET. Je prévois certainement d'être la semaine prochaine, à moins qu'il n'y ait des circonstances imprévues.
CANARD. Excellent!
Il ne nous reste plus qu'à dire, comme nous le faisons habituellement...
CHET. Jusqu'à la prochaine fois, restez en sécurité.
[MODÈME MUSICAL]
- Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
- Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
- La source: https://nakedsecurity.sophos.com/2023/03/16/s3-ep-126-the-price-of-fast-fashion-and-feature-creep-audio-text/
