S3 Ep146 : Parlez-nous de cette brèche ! (Si tu veux.)

S3 Ep146 : Parlez-nous de cette brèche ! (Si tu veux.)

Horodatage: 3 août 2023 1 h 56
S3 Ep146 : Parlez-nous de cette brèche ! (Si vous le souhaitez.) PlatoBlockchain Data Intelligence. Recherche verticale. Aï.
by Paul Canard

BIZARRE MAIS VRAI

Pas de lecteur audio ci-dessous ? Écouter directement sur Soundcloud.

Avec Doug Aamoth et Paul Ducklin. Musique d'intro et d'outro par Edith Mud.

Vous pouvez nous écouter sur Soundcloud, Podcasts Apple, Podcasts Google, Spotify 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

DOUG.  Mises à jour de Firefox, un autre Bug avec un nom impressionnant, et la SEC exige la divulgation.

Tout cela, et plus encore, sur le podcast Naked Security.

[MODÈME MUSICAL]

Bienvenue sur le podcast, tout le monde.

Je suis Doug Aamoth ; c'est Paul Ducklin.

Paul, j'espère que tu seras fier de moi… Je sais que tu es un passionné de vélo.

Hier, j'ai fait du vélo sur 10 miles américains, ce qui, je crois, représente environ 16 km, tout en tirant un enfant petit mais pas lourd derrière le vélo dans une calèche à deux roues.

Et je suis toujours en vie pour raconter l'histoire.

C'est un long chemin pour faire du vélo, Paul ?

CANARD.  [RIRES] Cela dépend jusqu'où vous deviez vraiment aller.

Comme si c'était en fait 1200 mètres que vous deviez parcourir et que vous vous perdiez… [RIRE]

Mon enthousiasme pour le cyclisme est très élevé, mais cela ne signifie pas que je roule délibérément plus loin que nécessaire, car c'est ma principale façon de me déplacer.

Mais 10 milles, c'est OK.

Saviez-vous que les miles américains et les miles britanniques sont en fait identiques ?

DOUG.  C'est bon à savoir!

CANARD.  Et ce depuis 1959, lorsqu'un groupe de pays, dont, je pense, le Canada, l'Afrique du Sud, l'Australie, les États-Unis et le Royaume-Uni, se sont réunis et ont convenu de normaliser sur un "pouce international".

Je pense que le pouce impérial est devenu très, très légèrement plus petit et que le pouce américain est devenu très, très légèrement plus long, avec pour résultat que le pouce (et donc le yard, et le pied, et le mile)…

… ils sont tous définis en termes de mètre.

Un pouce correspond exactement à 25.4 mm

Trois chiffres significatifs suffisent.

DOUG.  Fascinant!

Eh bien, en parlant de fascinant, il est temps pour notre Cette semaine dans l'histoire de la technologie segment.

Cette semaine, le 01er août 1981, Music Television, également connue sous le nom de MTV, a été mise en ligne dans le cadre des bouquets américains de télévision par câble et par satellite et a présenté au public des vidéoclips.

Le premier a joué [SINGS, RATHER BELL IN FACT] "Video Killed the Radio Star" par The Buggles.

Approprié à l'époque, bien qu'ironique de nos jours car MTV ne joue plus que rarement des vidéoclips et ne diffuse plus aucun nouveau vidéoclip, Paul.

CANARD.  Oui, c'est ironique, n'est-ce pas, que la télévision par câble (en d'autres termes, où vous aviez des fils passant sous le sol dans votre maison) a tué la star de la radio (ou du sans fil), et maintenant il semble que la télévision par câble, MTV… ce genre de choses s'est éteint parce que tout le monde a des réseaux mobiles qui fonctionnent sans fil.

Ce qui se passe revient, Douglas.

DOUG.  Très bien, parlons de ces mises à jour de Firefox.

Nous recevons une double dose de mises à jour de Firefox ce mois-ci, car elles sont sur un cycle de 28 jours :

Firefox corrige une série de failles dans la première des deux versions de ce mois-ci

Pas de zéro jour dans ce premier tour, mais quelques moments propices à l'apprentissage.

Nous en avons répertorié peut-être la moitié dans votre article, et celui qui m'a vraiment marqué était : Contournement potentiel des demandes d'autorisations via le détournement de clics.

CANARD.  Oui, bon vieux clickjacking encore.

J'aime ce terme parce qu'il décrit assez bien ce que c'est.

Vous cliquez quelque part, pensant que vous cliquez sur un bouton ou un lien innocent, mais vous autorisez par inadvertance quelque chose qui n'est pas évident d'après ce que l'écran affiche sous le curseur de votre souris.

Le problème ici semble être que dans certaines circonstances, lorsqu'une boîte de dialogue d'autorisations était sur le point d'apparaître à partir de Firefox, par exemple, dites : « Êtes-vous vraiment sûr de vouloir laisser ce site Web utiliser votre appareil photo ? avoir accès à votre position ? utiliser votre microphone ? »…

… toutes ces choses que, oui, vous voulez qu'on vous demande.

Apparemment, si vous pouviez amener le navigateur à un point de performance (encore une fois, performance contre sécurité) où il avait du mal à suivre, vous pourriez retarder l'apparition de la fenêtre contextuelle des autorisations.

Mais en ayant un bouton à l'endroit où la fenêtre contextuelle apparaîtrait et en incitant l'utilisateur à cliquer dessus, vous pourriez attirer le clic, mais le clic serait alors envoyé à la boîte de dialogue des autorisations que vous n'aviez pas encore vue.

Une sorte de condition de course visuelle, si vous voulez.

DOUG.  OK, et l'autre était: Le canevas hors écran aurait pu contourner les restrictions d'origine croisée.

Vous poursuivez en disant qu'une page Web peut jeter un coup d'œil sur les images affichées sur une autre page d'un site différent.

CANARD.  Ce n'est pas censé arriver, n'est-ce pas ?

DOUG.  Non!

CANARD.  Le terme de jargon pour cela est la « politique de la même origine ».

Si vous utilisez le site Web X et que vous m'envoyez tout un tas de JavaScript qui définit tout un tas de cookies, alors tout cela est stocké dans le navigateur.

Mais seul le JavaScript supplémentaire du site X peut lire ces données.

Le fait que vous naviguiez sur le site X dans un onglet et le site Y dans l'autre onglet ne leur permet pas de voir ce que fait l'autre, et le navigateur est censé garder tout cela à part.

C'est évidemment assez important.

Et il semble ici que, pour autant que je sache, si vous rendiez une page qui n'était pas encore affichée…

… un canevas hors écran, où vous créez, si vous le souhaitez, une page Web virtuelle, puis, à un moment donné, vous dites : « En ce moment, je suis prêt à l'afficher », et bingo, la page apparaît tout à une fois.

Le problème vient d'essayer de s'assurer que les éléments que vous rendez de manière invisible ne divulguent pas de données par inadvertance, même s'ils ne sont jamais affichés à l'utilisateur.

Ils l'ont repéré, ou cela a été divulgué de manière responsable, et il a été corrigé.

Et ces deux-là, je pense, étaient inclus dans les vulnérabilités dites de niveau « élevé ».

La plupart des autres étaient « Modérés », à l'exception du traditionnel de Mozilla : « Nous avons trouvé beaucoup de bogues grâce au fuzzing et à des techniques automatisées ; nous ne les avons pas sondés pour savoir s'ils pouvaient être exploités, mais nous sommes prêts à supposer que quelqu'un qui a suffisamment essayé pourrait le faire.

C'est un aveu que nous aimons tant, Doug… parce que les bogues potentiels valent la peine d'être annulés, même si vous êtes certain dans votre cœur que personne ne trouvera jamais comment les exploiter.

Parce qu'en cybersécurité, il vaut mieux ne jamais dire jamais !

DOUG.  Très bien, vous recherchez Firefox 116, ou si vous êtes sur une version étendue, 115.1.

Pareil avec Thunderbird.

Et passons à… oh, mec !

Paul, c'est excitant !

Nous avons un nouveau BWAIN après un double BWAIN la semaine dernière : un bogue avec un nom impressionnant.

Celui-ci s'appelle Collision+Puissance:

Les performances et la sécurité s'affrontent à nouveau dans l'attaque "Collide + Power"

CANARD.  [RIRES] Oui, c'est intrigant, n'est-ce pas, qu'ils aient choisi un nom avec un signe plus ?

DOUG.  Oui, c'est difficile à dire.

CANARD.  Vous ne pouvez pas avoir de signe plus dans votre nom de domaine, donc le nom de domaine est collidepower.com.

DOUG.  D'accord, permettez-moi de lire les chercheurs eux-mêmes, et je cite :

La racine du problème est que les composants de processeur partagés, comme le système de mémoire interne, combinent les données de l'attaquant et les données de toute autre application, ce qui entraîne un signal de fuite combiné dans la consommation d'énergie.

Ainsi, connaissant ses propres données, l'attaquant peut déterminer les valeurs exactes des données utilisées dans d'autres applications.

CANARD.  [RIRES] Oui, cela a beaucoup de sens si vous savez déjà de quoi ils parlent !

Pour essayer d'expliquer cela dans un anglais simple (j'espère que j'ai bien compris)…

Cela revient aux problèmes de performances par rapport à la sécurité dont nous avons déjà parlé, y compris le podcast de la semaine dernière avec ça Zenbleed bug (ce qui est bien plus grave, soit dit en passant) :

Zenbleed : comment la quête des performances du processeur pourrait mettre vos mots de passe en danger

Il y a tout un tas de données qui sont conservées à l'intérieur du CPU (« mis en cache » est le terme technique pour cela) afin que le CPU n'ait pas besoin d'aller les chercher plus tard.

Il y a donc beaucoup de choses internes que vous n'arrivez pas vraiment à gérer ; le CPU s'en occupe pour vous.

Et le cœur de cette attaque semble aller quelque chose comme ça…

Ce que fait l'attaquant, c'est accéder à divers emplacements de mémoire de manière à ce que le stockage de cache interne se souvienne de ces emplacements de mémoire, de sorte qu'il n'ait pas à les lire à nouveau dans la RAM s'ils sont réutilisés rapidement.

Ainsi, l'attaquant obtient d'une manière ou d'une autre ces valeurs de cache remplies de modèles connus de bits, de valeurs de données connues.

Et puis, si la victime a de la mémoire qu'elle *utilise* fréquemment (par exemple, les octets d'une clé de déchiffrement), si leur valeur est soudainement jugée par le CPU comme étant plus susceptible d'être réutilisée qu'une des valeurs des attaquants, il expulse la valeur de l'attaquant de cet emplacement de cache interne ultra-rapide et y place la nouvelle valeur, la valeur de la victime.

Et ce que ces chercheurs ont découvert (et aussi farfelu que l'attaque sonne en théorie et en pratique, c'est une chose assez étonnante à découvrir)…

Le nombre de bits qui sont différents entre l'ancienne valeur dans le cache et la nouvelle valeur *modifie la quantité d'énergie requise pour effectuer l'opération de mise à jour du cache*.

Par conséquent, si vous pouvez mesurer la consommation d'énergie du processeur avec suffisamment de précision, vous pouvez faire des déductions sur les valeurs de données qui ont été écrites dans la mémoire cache interne, cachée ou invisible à l'intérieur du processeur, ce que le processeur pensait ne pas être votre affaire.

Très intrigant, Doug!

DOUG.  Exceptionnel.

OK, il y a quelques atténuations.

Cette section commence par : "Tout d'abord, vous n'avez pas à vous inquiéter", mais presque tous les processeurs sont également concernés.

CANARD.  Oui, c'est intéressant, n'est-ce pas ?

Il dit "tout d'abord" (texte normal) "you" (en italique) "pas besoin de s'inquiéter" (en gras). [DES RIRES]

Donc, fondamentalement, personne ne vous attaquera avec ça, mais peut-être que les concepteurs de processeurs voudront y réfléchir à l'avenir s'il y a un moyen de contourner cela. [DES RIRES]

J'ai pensé que c'était une façon intéressante de présenter les choses.

DOUG.  OK, donc l'atténuation consiste essentiellement à désactiver l'hyperthreading.

Est-ce ainsi que ça fonctionne?

CANARD.  L'hyperthreading rend cela bien pire, pour autant que je sache.

Nous savons déjà que l'hyperthreading est un problème de sécurité car de nombreuses vulnérabilités en dépendent auparavant.

C'est là qu'un processeur, disons, avec huit cœurs prétend avoir 16 cœurs, mais en réalité ils ne sont pas dans des parties séparées de la puce.

Ce sont en fait des paires de pseudo-cœurs qui partagent plus d'électronique, plus de transistors, plus de condensateurs, ce qui n'est peut-être pas une bonne idée pour des raisons de sécurité.

Si vous utilisez le bon vieux OpenBSD, je pense qu'ils ont décidé que l'hyperthreading est tout simplement trop difficile à sécuriser avec des atténuations ; autant le désactiver.

Au moment où vous avez pris les coups de performance requis par les atténuations, vous pourriez tout aussi bien ne pas l'avoir.

Donc je pense que désactiver l'hyperthreading vous immunisera grandement contre cette attaque.

La deuxième chose que vous pouvez faire est, comme le disent les auteurs en gras : ne t'en fais pas. [RIRE]

DOUG.  C'est une grande atténuation! [DES RIRES]

CANARD.   Il y a beaucoup de choses (je vais devoir lire ça, Doug)…

Il y a une grande partie où les chercheurs eux-mêmes ont découvert que pour obtenir toute sorte d'informations fiables, ils obtenaient des débits de données compris entre 10 bits et 100 bits par heure du système.

Je crois qu'au moins les processeurs Intel ont une atténuation qui, j'imagine, aiderait contre cela.

Et cela nous ramène aux MSR, ces registres spécifiques au modèle dont nous avons parlé la semaine dernière avec Zenbleed, où il y avait un élément magique que vous pouviez activer et qui disait : « Ne faites pas les choses risquées.

Il existe une fonctionnalité que vous pouvez définir appelée Filtrage RAPL, et RAPL est l'abréviation de limite de puissance moyenne courante.

Il est utilisé par les programmes qui veulent voir comment un processeur fonctionne à des fins de gestion de l'alimentation, vous n'avez donc pas besoin de pénétrer dans la salle des serveurs et de mettre un moniteur d'alimentation sur un fil avec une petite sonde sur la carte mère. [DES RIRES]

Vous pouvez en fait demander au processeur de vous dire combien d'énergie il utilise.

Intel a au moins ce mode appelé filtrage RAPL, qui introduit délibérément de la gigue ou de l'erreur.

Ainsi, vous obtiendrez des résultats qui, en moyenne, sont précis, mais où chaque lecture individuelle sera erronée.

DOUG.  Tournons maintenant notre attention vers ce nouvel accord avec la SEC.

La Security and Exchange Commission exige des limites de divulgation de quatre jours sur les violations de la cybersécurité :

La SEC exige une limite de divulgation de quatre jours pour les violations de la cybersécurité

Mais (A) vous décidez si une attaque est suffisamment grave pour être signalée, et (B) la limite de quatre jours ne commence pas tant que vous n'avez pas décidé que quelque chose est suffisamment important pour être signalé, Paul.

Alors, un bon premier départ, mais peut-être pas aussi agressif qu'on le voudrait ?

CANARD.  Je suis d'accord avec votre évaluation, Doug.

Cela sonnait bien quand je l'ai regardé pour la première fois : "Hé, vous avez cette divulgation de quatre jours si vous avez une violation de données ou un problème de cybersécurité."

Mais ensuite, il y avait ce petit quelque chose à propos de « Eh bien, cela doit être considéré comme un problème matériel », un terme juridique qui signifie que cela compte suffisamment pour qu'il vaille la peine d'être divulgué en premier lieu.

Et puis je suis arrivé à ce morceau (et ce n'est pas un très long communiqué de presse de la SEC) qui disait en quelque sorte: "Dès que vous avez décidé que vous devriez vraiment signaler cela, alors vous avez encore quatre jours pour le signaler. »

Maintenant, j'imagine que, légalement, ce n'est pas tout à fait ainsi que cela fonctionnera. Doug

Peut-être sommes-nous un peu durs dans l'article ?

DOUG.  Vous zoomez sur les attaques de rançongiciels, en disant qu'il en existe plusieurs types différents, alors parlons-en… c'est important pour déterminer s'il s'agit d'une attaque matérielle que vous devez signaler.

Alors, à quel type de rançongiciel s'intéresse-t-on ?

CANARD.  Oui, juste pour expliquer, je pensais que c'était une partie importante de cela.

Je ne veux pas pointer du doigt la SEC, mais c'est quelque chose qui ne semble pas encore être tombé dans l'eau dans de nombreux pays ou dans aucun pays…

… que le simple fait de subir une attaque de ransomware soit inévitablement suffisant pour constituer une violation de données matérielle.

Ce document de la SEC ne mentionne pas du tout le "mot R".

Il n'y a aucune mention de trucs spécifiques aux rançongiciels.

Et les rançongiciels sont un problème, n'est-ce pas ?

Dans l'article, je voulais préciser que le mot "ransomware", que nous utilisons encore largement, n'est plus tout à fait le bon mot, n'est-ce pas ?

Nous devrions probablement l'appeler « chantage » ou simplement « cyberextorsion ».

J'identifie trois principaux types d'attaques de ransomwares.

Le type A est celui où les escrocs ne volent pas vos données, ils peuvent simplement les brouiller sur place.

Ils n'ont donc pas besoin de télécharger une seule chose.

Ils brouillent tout de manière à pouvoir vous fournir la clé de déchiffrement, mais vous ne verrez pas un seul octet de données quitter votre réseau comme un signe révélateur que quelque chose de mal se passe.

Ensuite, il y a une attaque de rançongiciel de type B, où les escrocs disent : « Vous savez quoi, nous n'allons pas risquer d'écrire dans tous les fichiers, en nous faisant prendre. Nous allons juste voler toutes les données, et au lieu de payer pour récupérer vos données, vous payez pour notre silence.

Et puis, bien sûr, il y a l'attaque du rançongiciel de type C, c'est-à-dire : « À la fois A et B ».

C'est là que les escrocs volent vos données *et* ils les brouillent et ils disent : "Hé, si ce n'est pas une chose qui va vous causer des ennuis, c'est l'autre."

Et ce serait bien de savoir où ce que je crois que la profession juridique appelle la matérialité (en d'autres termes, la signification juridique ou la pertinence juridique pour une réglementation particulière)…

… où cela entre en jeu, dans le cas d'attaques de ransomwares.

DOUG.  Eh bien, c'est le bon moment pour faire venir notre commentateur de la semaine, Adam, sur cette histoire.

Adam donne son avis sur les différents types d'attaques de ransomwares.

Donc, en commençant par le type A, où il s'agit simplement d'une simple attaque de ransomware, où ils verrouillent les fichiers et laissent une note de rançon pour les déverrouiller…

Adam dit :

Si une entreprise est touchée par un rançongiciel, ne trouve aucune preuve d'exfiltration de données après une enquête approfondie et récupère ses données sans payer la rançon, alors je serais enclin à dire : « Non [divulgation nécessaire] ».

CANARD.  Vous en avez assez fait ?

DOUG.  Oui.

CANARD.  Vous ne l'avez pas tout à fait empêché, mais vous avez fait la meilleure chose suivante, vous n'avez donc pas besoin de le dire à vos investisseurs….

L'ironie est, Doug, si vous aviez fait cela en tant qu'entreprise, vous auriez peut-être voulu dire à vos investisseurs : « Hé, devinez quoi ? Nous avons eu une attaque de ransomware comme tout le monde, mais nous nous en sommes sortis sans payer, sans nous engager avec les escrocs et sans perdre aucune donnée. Donc, même si nous n'étions pas parfaits, nous étions la meilleure chose suivante.

Et cela pourrait en fait avoir beaucoup de poids de divulguer cela volontairement, même si la loi dit que vous n'êtes pas obligé de le faire.

DOUG.  Et puis, pour le Type B, l'angle du chantage, Adam dit :

C'est une situation délicate.

Théoriquement, je dirais "Oui".

Mais cela va probablement conduire à de nombreuses divulgations et nuire à la réputation des entreprises.

Donc, si vous avez un tas d'entreprises qui sortent et disent : « Écoutez, nous avons été touchés par un rançongiciel ; nous pensons que rien de mal ne s'est produit; nous avons payé les escrocs pour qu'ils se taisent ; et nous sommes convaincus qu'ils ne vont pas renverser la mèche », pour ainsi dire…

… cela crée une situation délicate, car cela pourrait nuire à la réputation d'une entreprise, mais s'ils ne l'avaient pas divulgué, personne ne le saurait.

CANARD.  Et je vois qu'Adam ressentait la même chose que vous et moi à propos de l'affaire de "Vous avez quatre jours, et pas plus de quatre jours... à partir du moment où vous pensez que les quatre jours devraient commencer."

Il l'a dit aussi, n'est-ce pas ?

Il a dit:

Certaines entreprises adopteront probablement des tactiques pour retarder considérablement la décision de savoir s'il y a un impact matériel.

Donc, nous ne savons pas très bien comment cela se déroulera, et je suis sûr que la SEC ne le sait pas non plus.

Il leur faudra peut-être quelques cas de test pour déterminer quelle est la bonne quantité de bureaucratie pour s'assurer que nous apprenons tous ce que nous devons savoir, sans forcer les entreprises à divulguer chaque petit problème informatique qui se produit et à nous enterrer tous dans un charge de paperasse.

Ce qui conduit essentiellement à la fatigue des ruptures, n'est-ce pas ?

Si vous avez tant de mauvaises nouvelles qui ne sont pas très importantes, il suffit de vous laver…

… d'une certaine manière, il est facile de passer à côté des choses vraiment importantes qui se trouvent parmi tous les « ai-je vraiment besoin d'en entendre parler ? »

Le temps nous le dira, Douglas.

DOUG.  Oui, délicat !

Et je sais que je le dis tout le temps, mais nous garderons un œil là-dessus, car ce sera fascinant de voir cela se dérouler.

Donc, merci, Adam, d'avoir envoyé ce commentaire.

CANARD.  Oui en effet!

DOUG.  Si vous avez une histoire intéressante, un commentaire ou une question que vous aimeriez soumettre, nous serions ravis de lire sur le podcast.

Vous pouvez envoyer un e-mail à tips@sophos.com, commenter n'importe lequel de nos articles ou nous contacter sur les réseaux sociaux : @nakedsecurity.

C'est notre émission d'aujourd'hui; merci beaucoup pour votre écoute.

Pour Paul Ducklin, je suis Doug Aamoth, je vous rappelle jusqu'à la prochaine fois pour…

TOUS LES DEUX.  Restez en sécurité.

[MODÈME MUSICAL]

Horodatage:

Plus de Sécurité nue