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

DOUG.  Exécution de code à distance, exécution de code à distance et codes 2FA dans le cloud.

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.

[IRONIQUE] Paul, heureux Jour d'exécution du code à distance à toi, mon ami.

CANARD.  Jour, semaine, mois, année, semble-t-il, Doug.

Tout un groupe d'histoires RCE cette semaine, de toute façon.

DOUG.  Bien sûr…

Mais avant d'entrer dans le vif du sujet, approfondissons notre Histoire de la technologie segment.

Cette semaine, le 26 avril 1998, le monde informatique a été ravagé par la Virus CIH, également connu sous le nom de SpaceFiller.

Ceci Remplisseur d'espace nom est probablement le plus approprié.

Au lieu d'écrire du code supplémentaire à la fin d'un fichier, qui est une signature révélatrice d'une activité virulente, ce virus, qui s'est cadencé à environ 1 Ko, a plutôt comblé les lacunes du code existant.

Le virus était un exécutable Windows qui remplissait le premier mégaoctet d'espace disque avec des zéros, effaçant ainsi la table de partition.

Une deuxième charge utile essaierait alors d'écrire dans le BIOS afin de le détruire.

Ça a l'air malveillant, Paul !

Il y a 20 ans aujourd'hui ! Ce que nous pouvons apprendre du virus CIH…

CANARD.  C'est certainement le cas.

Et ce qui est fascinant, c'est que le 26 avril a été le seul jour où ce n'était en fait *pas* un virus – le reste de l'année, il s'est propagé.

Et, en effet, non seulement, comme vous le dites, a-t-il essayé d'effacer le premier morceau de votre disque dur…

… vous pourriez probablement ou peut-être récupérer, mais cela a supprimé votre table de partition et généralement une grande partie de votre table d'allocation de fichiers, donc votre ordinateur n'a certainement pas pu démarrer sans une aide sérieuse.

Mais s'il a réussi à écraser votre BIOS, il a délibérément écrit des ordures juste au début du micrologiciel, de sorte que lorsque vous allumez votre ordinateur la prochaine fois, la deuxième instruction de code machine qu'il a essayé d'exécuter à la mise sous tension le ferait accrocher.

Vous ne pouviez donc pas du tout démarrer votre ordinateur pour récupérer le micrologiciel ou le reflasher.

Et c'était à peu près au début de l'ère où les puces BIOS ont cessé d'être dans des sockets, où vous pouviez les retirer de votre carte mère si vous saviez ce que vous faisiez, les reflasher et les remettre en place.

Ils ont été soudés sur la carte mère.

Si vous aimez, "Aucune pièce réparable par l'utilisateur à l'intérieur."

Ainsi, un certain nombre d'âmes malchanceuses qui ont été touchées ont non seulement vu leurs données effacées et leur ordinateur rendu physiquement impossible à démarrer, mais elles n'ont pas pu le réparer et ont dû acheter une nouvelle carte mère, Doug.

DOUG.  Et à quel point ce type de virus était-il avancé ?

Cela ressemble à beaucoup de choses que les gens n'avaient peut-être jamais vues auparavant, ou qui étaient vraiment extrêmes.

CANARD.  L’idée de remplir l’espace n’était pas nouvelle…

… parce que les gens ont appris à mémoriser la taille de certains fichiers système clés.

Vous pourriez donc mémoriser, si vous étiez un utilisateur DOS, la taille de COMMAND.COM, juste au cas où il augmenterait.

Ou vous pourriez mémoriser la taille de, disons, NOTEPAD.EXE, puis vous pourriez y revenir de temps en temps et vous dire : « Cela n'a pas changé ; ça doit être OK.

Parce que, évidemment, en tant qu'analyseur antivirus humain, vous n'étiez pas en train de fouiller dans le fichier, vous ne faisiez que le regarder.

Cette astuce était donc assez connue.

Ce que nous n'avions pas vu auparavant, c'était cette tentative délibérée et calculée non seulement d'effacer le contenu de votre disque dur (ce qui était étonnamment, et malheureusement, très courant à l'époque comme effet secondaire), mais en fait de zapper tout votre ordinateur , et rendre l'ordinateur lui-même inutilisable.

Irrécupérable.

Et de vous forcer à vous rendre en quincaillerie et à remplacer un des composants.

DOUG.  Pas drôle.

Pas amusant du tout !

Alors, parlons de quelque chose d'un peu plus joyeux.

Je souhaite sauvegarder mon Google Authenticator Séquences de code 2FA au Cloud de Google…

… et je n'ai rien à craindre car ils sont cryptés en transit, n'est-ce pas, Paul ?

Google divulgue des secrets 2FA - les chercheurs déconseillent pour l'instant la nouvelle fonctionnalité de "synchronisation de compte"

CANARD.  C'est une histoire fascinante, car Google Authenticator est très largement utilisé.

La seule fonctionnalité qu'il n'a jamais eue est la possibilité de sauvegarder vos comptes 2FA et leurs soi-disant graines de départ (les éléments qui vous aident à générer les codes à six chiffres) dans le cloud afin que si vous perdez votre téléphone ou que vous en achetiez un nouveau téléphone, vous pouvez les synchroniser avec le nouvel appareil sans avoir à tout configurer à nouveau.

Et Google a récemment annoncé : "Nous allons enfin proposer cette fonctionnalité".

J'ai vu une histoire en ligne dont le titre était Google Authenticator ajoute une fonctionnalité essentielle et attendue depuis 13 ans.

Alors tout le monde était terriblement excité à ce sujet !

[RIRE]

Et c'est bien pratique.

Ce que les gens font, c'est…

… vous savez, ces codes QR qui vous permettent d'établir la graine en premier lieu pour un compte ?

DOUG.  [RIRES] Bien sûr, je prends tout le temps des photos du mien.

CANARD.  [GROANS] Yessss, vous pointez votre appareil photo vers lui, il le scanne, puis vous pensez : "Et si j'en ai encore besoin ? Avant de quitter cet écran, je vais en prendre une photo, puis j'ai une sauvegarde.

Eh bien, ne faites pas ça !

Parce que cela signifie que quelque part parmi vos e-mails, parmi vos photos, parmi votre compte cloud, se trouve essentiellement une copie non cryptée de cette graine.

Et c'est la clé absolue de votre compte.

Ce serait donc un peu comme écrire votre mot de passe sur un morceau de papier et le prendre en photo - ce n'est probablement pas une bonne idée.

Donc, pour Google, l'intégration de cette fonctionnalité (vous l'espérez en toute sécurité) dans son programme Authenticator a finalement été considérée par beaucoup comme un triomphe.

[PAUSE DRAMATIQUE]

Entrez @mysk_co (notre bon ami Tommy Mysk, dont nous avons déjà parlé plusieurs fois sur le podcast).

Ils se sont dit : « Il y a sûrement une sorte de cryptage qui vous est propre, comme une phrase de passe… pourtant, quand j'ai fait la synchronisation, l'application ne m'a pas demandé de mot de passe ; il ne m'a pas offert le choix d'en mettre un, comme le fait le navigateur Chrome lorsque vous synchronisez des choses comme les mots de passe et les détails du compte.

Et, ô surprise, @mysk_co a découvert que lorsqu'ils ont pris le trafic TLS de l'application et l'ont déchiffré, comme cela se produirait lorsqu'il arriverait chez Google…

… il y avait les graines à l'intérieur !

Je suis surpris que Google n'ait pas intégré cette fonctionnalité : "Voulez-vous crypter cela avec un mot de passe de votre choix afin que même nous ne puissions pas accéder à vos graines ?"

Parce que, sinon, si ces graines sont divulguées ou volées, ou si elles sont saisies en vertu d'un mandat de perquisition légal, quiconque obtient les données de votre cloud pourra avoir les graines de départ pour tous vos comptes.

Et normalement, ce n'est pas ainsi que les choses fonctionnent.

Vous n'avez pas besoin d'être un scélérat sans foi ni loi pour vouloir garder des choses comme vos mots de passe et vos graines 2FA secrètes de tout le monde et de n'importe qui.

Donc, leur conseil, le conseil de @ mysk_co (et je le seconderais) est : "N'utilisez pas cette fonctionnalité tant que Google n'est pas venu à la fête avec une phrase de passe que vous pouvez ajouter si vous le souhaitez."

Cela signifie que le contenu est crypté par vous * avant * qu'il soit crypté pour être mis dans la connexion HTTPS pour l'envoyer à Google.

Et cela signifie que Google ne peut pas lire vos graines de départ, même s'il le souhaite.

DOUG.  D'accord, ma chose préférée au monde à dire sur ce podcast : nous garderons un œil là-dessus.

Notre prochaine histoire concerne une entreprise appelée PaperCut.

Il s'agit aussi d'un exécution de code à distance.

Mais c'est vraiment plus un tip-of-the-cap pour cette entreprise d'être si transparente.

Il se passe beaucoup de choses dans cette histoire. Paul… creusons et voyons ce que nous pouvons trouver.

Vulnérabilités de sécurité PaperCut sous attaque active - le fournisseur exhorte les clients à corriger

CANARD.  Laissez-moi faire un mea culpa à PaperCut-la-société.

Quand j'ai vu les mots PaperCut, puis j'ai vu des gens parler: «Ooohh, vulnérabilité; exécution de code à distance ; attaques ; cyberdrame »…

DOUG.  [RIRES] Je sais où cela mène !

CANARD.  … Je pensais que PaperCut était un BWAIN, un bogue avec un nom impressionnant.

J'ai pensé : « C'est un nom cool ; Je parie que ça a à voir avec les imprimantes, et ça va être comme un Heartbleed, ou un LogJam, ou un ShellShock, ou un PrintNightmare – c'est un PaperCut !

En fait, ce n'est que le nom de l'entreprise.

Je pense que l'idée est qu'il est destiné à vous aider à réduire le gaspillage, les dépenses inutiles et la non-vertualité dans votre utilisation du papier, en fournissant l'administration de l'imprimante dans votre réseau.

La «coupe» signifie que vous réduisez vos dépenses.

Malheureusement, dans ce cas, cela signifiait que les attaquants pouvaient se frayer un chemin dans le réseau, car il y avait une paire de vulnérabilités découvertes récemment dans les outils d'administration de leur serveur.

Et l'un de ces bogues (si vous voulez le retrouver, c'est CVE-2023-27350) permet l'exécution de code à distance :

Cette vulnérabilité permet potentiellement à un attaquant non authentifié d'obtenir l'exécution de code à distance sur un serveur d'application Papercut. Cela pourrait être fait à distance et sans avoir besoin de se connecter.

En gros, dites-lui la commande que vous souhaitez exécuter et il l'exécutera pour vous.

Bonne nouvelle : ils ont corrigé ces deux bugs, y compris celui qui est super dangereux.

Le bogue d'exécution de code à distance… ils ont corrigé fin mars 2023.

Bien sûr, tout le monde n'a pas appliqué les patchs.

Et, ô surprise, au milieu d'avril 2023 environ, ils ont reçu des informations selon lesquelles quelqu'un était au courant.

Je suppose que les escrocs ont regardé les correctifs, ont compris ce qui avait changé et ont pensé : « Oooh, c'est plus facile à exploiter que nous ne le pensions, utilisons-le ! Quelle manière pratique d'entrer !

Et les attaques ont commencé.

Je crois que le premier qu'ils ont trouvé jusqu'à présent était le 14 avril 2023.

Et donc la société a fait tout son possible, et a même placé une bannière en haut de son site Web disant : "Message urgent pour nos clients : veuillez appliquer le patch".

Les escrocs ont déjà atterri dessus, et ça ne va pas bien.

Et selon les chercheurs en menaces de l'équipe Sophos X-Ops, nous avons déjà des preuves que différents gangs d'escrocs l'utilisent.

Je pense donc que nous sommes au courant d'une attaque qui semble être celle de l'équipe du rançongiciel Clop ; un autre qui, je crois, était dû au gang de rançongiciels LockBit ; et une troisième attaque où l'exploit a été abusé par des escrocs pour le cryptojacking - où ils brûlent votre électricité mais ils prennent les cryptocoins.

Et pire encore, j'ai reçu une notification de l'un de nos chercheurs sur les menaces ce matin [2023-04-26] que quelqu'un, bénisse leur cœur, a décidé que "à des fins défensives et pour la recherche universitaire", il est vraiment important que nous ayons tous accès à un script Python de 97 lignes…

… qui vous permet d'exploiter cela à volonté, [IRONIC] juste pour que vous puissiez comprendre comment cela fonctionne.

DOUG.  [GÉMISSEMENT] Aaaaargh.

CANARD.  Donc si vous n'avez pas patché...

DOUG.  Accélère s'il te plaît!

Ça sonne mal !

CANARD.  "Veuillez vous dépêcher"... Je pense que c'est la façon la plus calme de le dire, Doug.

DOUG.  Nous resterons sur le train d'exécution de code à distance, et le prochain arrêt est Chromium Junction.

A double jour zéro, une impliquant des images et une impliquant JavaScript, Paul.

Double zero-day dans Chrome et Edge - vérifiez vos versions maintenant !

CANARD.  En effet Doug.

Je vais les lire au cas où vous voudriez les retrouver.

Nous avons CVE-2023-2033, et c'est, dans le jargon, Tapez confusion dans V8 dans Google Chrome.

Et nous avons CVE-2023-2136, Débordement d'entier dans Skia dans Google Chrome.

Pour expliquer, V8 est le nom du "moteur" JavaScript open-source, si vous voulez, au cœur du navigateur Chromium, et Skia est une bibliothèque de gestion graphique utilisée par le projet Chromium pour le rendu du contenu HTML et graphique.

Vous pouvez imaginer que le problème des bugs déclenchables soit dans la partie rendu graphique soit dans la partie traitement JavaScript de votre navigateur…

… c'est que ce sont les parties mêmes qui sont conçues pour consommer, traiter et présenter des éléments qui * arrivent à distance à partir de sites Web non fiables *, même lorsque vous les regardez simplement.

Et donc, rien que par le navigateur qui le prépare pour que vous le voyiez, vous pourriez chatouiller non pas un, mais les deux bogues.

Je crois comprendre que l'un d'eux, celui de JavaScript, donne essentiellement l'exécution de code à distance, où vous pouvez faire en sorte que le navigateur exécute du code qu'il n'est pas censé exécuter.

Et l'autre permet ce qu'on appelle généralement une évasion de bac à sable.

Ainsi, vous faites exécuter votre code, puis vous sautez en dehors des restrictions censées limiter l'exécution du code dans un navigateur.

Bien que ces bogues aient été découverts séparément et qu'ils aient été corrigés séparément le 14 avril 2023 et le 18 avril 2023 respectivement, vous ne pouvez pas vous empêcher de vous demander (car ce sont des jours zéro) s'ils étaient réellement utilisés en combinaison par quelqu'un.

Parce que vous pouvez imaginer : l'un vous permet de pénétrer *dans* le navigateur, et l'autre vous permet de *sortir* du navigateur.

Vous êtes donc dans le même genre de situation que lorsque nous parlions récemment de ces Jours zéro Apple, où l'on était dans WebKit, le moteur de rendu du navigateur, ce qui signifiait que votre navigateur pouvait être piraté pendant que vous regardiez une page…

… et l'autre était dans le noyau, où le code du navigateur pouvait soudainement sortir du navigateur et s'enfouir directement dans la partie contrôle principale du système.

Extension des correctifs de logiciels espions Apple Zero Day pour couvrir les anciens Mac, iPhone et iPad

Maintenant, nous ne savons pas, dans les cas de bogues Chrome et Edge, si ceux-ci ont été utilisés ensemble, mais cela signifie certainement qu'il vaut vraiment la peine de vérifier que vos mises à jour automatiques ont vraiment été effectuées !

DOUG.  Oui, je noterais que j'ai vérifié mon Microsoft Edge et qu'il s'est mis à jour automatiquement.

Mais il se peut qu'il y ait une bascule de mise à jour désactivée par défaut - si vous avez des connexions mesurées, c'est-à-dire si votre FAI a un plafond, ou si vous utilisez un réseau mobile - de sorte que vous n'obtiendrez pas les mises à jour automatiquement à moins que vous l'activez de manière proactive.

Et la bascule ne prend effet qu'une fois que vous avez redémarré votre navigateur.

Donc, si vous faites partie de ces personnes qui gardent simplement votre navigateur ouvert en permanence, et ne l'éteignent ni ne le redémarrent jamais, alors…

… oui, ça vaut le coup de vérifier !

Ces navigateurs font du bon travail avec les mises à jour automatiques, mais ce n'est pas acquis.

CANARD.  C'est un très bon point, Doug.

Je n'avais pas pensé à ça.

Si vous avez désactivé ces connexions mesurées, vous ne recevrez peut-être pas les mises à jour après tout.

DOUG.  OK, donc les CVE de Google sont un peu vagues, comme ils le sont souvent de n'importe quelle entreprise.

Donc, Phil (un de nos lecteurs) a demandé… il dit qu'une partie de la CVE dit que quelque chose peut arriver « via une page HTML spécialement conçue ».

Il dit que c'est encore trop vague.

Ainsi, en partie, il dit :

Je suppose que je devrais supposer que, puisque V8 est là où réside la faiblesse, JavaScript-plus-HTML, et pas seulement du HTML corrompu en soi, peut mettre la main sur le pointeur d'instruction du processeur ? Vrai ou faux?

Et puis il poursuit en disant que les CVE sont "inutile pour moi, jusqu'à présent, d'obtenir un indice à ce sujet."

Alors Phil est un peu confus, comme le sont probablement beaucoup d'entre nous ici.

Paul?

CANARD.  Oui, je pense que c'est une excellente question.

Je comprends dans ce cas pourquoi Google ne veut pas trop en dire sur les bugs.

Ils sont à l'état sauvage; ce sont des jours zéro ; les escrocs les connaissent déjà ; essayons de le garder sous notre chapeau pendant un moment.

Maintenant, je présume que la raison pour laquelle ils viennent de dire qu'une "page HTML conçue" n'était pas de suggérer que le HTML seul (code HTML pur "crochet/balise/crochet", si vous voulez) pourrait déclencher le bogue.

Je pense que ce que Google essaie de vous avertir, c'est que le simple fait de regarder - la navigation en "lecture seule" - peut néanmoins vous causer des ennuis.

L'idée d'un bogue comme celui-ci, parce qu'il s'agit d'une exécution de code à distance, est : vous regardez ; le navigateur tente de présenter quelque chose de sa manière contrôlée ; il devrait être 100% sûr.

Mais dans ce cas, cela pourrait être 100% *dangereux*.

Et je pense que c'est ce qu'ils essaient de dire.

Et malheureusement, cette idée que "les CVE sont" inutiles pour moi ", malheureusement, je trouve que c'est souvent le cas.

DOUG.  [RIRES] Tu n'es pas seul, Phil !

CANARD.  Ce ne sont que quelques phrases de jargon et de jargon de cybersécurité.

Je veux dire, parfois, avec les CVE, vous accédez à la page et il est simplement écrit : "Cet identifiant de bogue a été réservé et les détails suivront plus tard", ce qui est presque pire qu'inutile. [RIRE]

Donc, ce que cela essaie vraiment de vous dire, d'une manière jargoniste, c'est que *regarder simplement*, simplement visualiser une page Web, qui est censée être sûre (vous n'avez pas choisi de télécharger quoi que ce soit ; vous n'avez pas choisi de exécuter quoi que ce soit ; vous n'avez pas autorisé le navigateur à enregistrer un fichier) ... le simple fait de préparer la page avant de la voir pourrait suffire à vous mettre en danger.

C'est, je pense, ce qu'ils entendent par "contenu HTML conçu".

DOUG.  D'accord, merci beaucoup, Paul, d'avoir éclairci cela.

Et merci beaucoup, Phil, de nous l'avoir envoyé.

Si vous avez une histoire intéressante, un commentaire ou une question que vous aimeriez soumettre, nous serions ravis de le 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]