S3 Ep108 : Vous avez caché TROIS MILLIARDS de dollars dans une boîte de pop-corn ?

Nœud source: 1752998

TROIS MILLIARDS DE DOLLARS DANS UNE BOITE DE POPCORN ?

Des ondes radio si mystérieuses qu'elles ne sont connues que sous le nom de rayons X. Y avait-il six jours 0 ou seulement quatre? Les flics qui trouvé 3 milliards de dollars dans une boîte de pop-corn. Insigne bleu confusion. Quand Analyse d'URL va mal. Traquer chaque dernier fichier non patché. Pourquoi même des exploits improbables peuvent atteindre des niveaux de gravité « élevés ».

Cliquez et faites glisser sur les ondes sonores ci-dessous pour passer à n'importe quel point. Vous pouvez également é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, 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

DOUG.  Escroqueries sur Twitter, Patch Tuesday et criminels piratant des criminels.

Tout cela et plus encore sur le podcast Naked Security.

[MODÈME MUSICAL]

Bienvenue sur le podcast, tout le monde.

Je suis Doug.

Il s'agit de Paul Ducklin.

Paul, comment vas-tu aujourd'hui ?


CANARD.  Très bien, Doug.

Nous n'avons pas eu l'éclipse lunaire ici en Angleterre, mais j'ai eu un bref aperçu de la * pleine * pleine lune à travers un petit trou dans les nuages ​​qui a émergé comme le seul trou dans toute la couche nuageuse au moment où je suis sorti pour regarde!

Mais nous n'avions pas cette lune orange comme vous l'aviez dans le Massachusetts.


DOUG.  Commençons le spectacle par Cette semaine dans l'histoire de la technologie… cela remonte à loin.

Cette semaine, le 08 novembre 1895, le professeur de physique allemand Wilhelm Röntgen est tombé sur une forme de rayonnement encore inconnue qui l'a incité à se référer audit rayonnement simplement comme "X".

Comme en radiographie.

Qu'en est-il de ça… la découverte accidentelle des rayons X ?


CANARD.  Assez étonnant.

Je me souviens que ma mère me disait : dans les années 1950 (ce devait être la même chose aux États-Unis), apparemment, dans les magasins de chaussures…


DOUG.  [SAIT CE QUI ARRIVE] Oui ! [DES RIRES]


CANARD.  Les gens emmenaient leurs enfants… vous vous teniez dans cette machine, mettiez les chaussures et au lieu de simplement dire : « Faites le tour, sont-elles serrées ? Est-ce qu'ils pincent ?", vous vous teniez dans une machine à rayons X, qui vous baignait essentiellement dans des rayons X et a pris une photo en direct et a dit : "Oh oui, ils ont la bonne taille."


DOUG.  Oui, des temps plus simples. Un peu dangereux, mais...


CANARD.  UN PEU DANGEREUX ?

Pouvez-vous imaginer les gens qui travaillaient dans les magasins de chaussures ?

Ils ont dû se baigner dans les rayons X tout le temps.


DOUG.  Absolument… eh bien, nous sommes un peu plus en sécurité aujourd'hui.

Et en ce qui concerne la sécurité, le premier mardi du mois est le Patch Tuesday de Microsoft.

So qu'avons-nous appris ce Patch Tuesday ici en novembre 2022 ?

Exchange 0-days corrigé (enfin) - plus 4 tout nouveaux Patch Tuesday 0-days !


CANARD.  Eh bien, ce qui est super excitant, Doug, c'est que techniquement, le Patch Tuesday n'a pas corrigé un, pas deux, pas trois… mais *quatre* jours zéro.

Mais en fait, les correctifs que vous pourriez obtenir pour les produits Microsoft mardi ont corrigé * six * jours zéro.

Souvenez-vous de ces vulnérabilités Exchange zero-day qui n'ont notoirement pas été corrigées mardi dernier : CVE-2002-41040 et CVE-2022-41082, ce qui est devenu connu sous le nom de ProxyNotShell?

S3 Ep102.5 : Bugs Exchange "ProxyNotShell" - un expert parle [Audio + Texte]

Eh bien, ceux-ci ont été corrigés, mais essentiellement dans une "ligne de touche" distincte du Patch Tuesday : l'échange SU de novembre 2022, ou mise à jour logicielle, qui dit simplement :

Les mises à jour logicielles Exchange de novembre 2022 contiennent des correctifs pour les vulnérabilités zero-day signalées publiquement le 29 septembre 2022.

Tout ce que vous avez à faire est de mettre à niveau Exchange.

Eh bien, merci Microsoft… Je pense que nous savions que c'était ce que nous allions devoir faire lorsque les correctifs sont enfin sortis !

Donc, ils * sont * sortis et il y a deux jours zéro corrigés, mais ce ne sont pas de nouveaux, et ils ne sont techniquement pas dans la partie "Patch Tuesday".

Là, nous avons quatre autres zero-days fixés.

Et si vous croyez qu'il faut prioriser les correctifs, alors évidemment ce sont ceux que vous voulez traiter en premier, car quelqu'un sait déjà comment faire de mauvaises choses avec eux.

Celles-ci vont d'un contournement de sécurité à deux élévations de privilèges et à une exécution de code à distance.

Mais il y a plus de 60 patchs au total, et si vous regardez la liste globale des produits et des composants Windows concernés, il y a une énorme liste, comme d'habitude, qui comprend tous les composants/produits Windows dont vous avez entendu parler, et beaucoup dont vous n'avez probablement pas entendu parler.

Microsoft corrige 62 vulnérabilités, dont Kerberos, Mark of the Web et Exchange… en quelque sorte

Alors, comme toujours : Ne tardez pas/faites-le aujourd'hui, Douglas !


DOUG.  Très bon.

Parlons maintenant d'un certain retard...

Vous avez une histoire très intéressante sur le Marché de la drogue de la route de la soie, et un rappel que les criminels qui volent des criminels sont toujours un crime, même si c'est une dizaine d'années plus tard que vous vous faites prendre pour cela.

Le pirate du marché de la drogue de Silk Road plaide coupable et risque 20 ans de prison


CANARD.  Oui, même les personnes novices en matière de cybersécurité ou de connexion en ligne auront probablement entendu parler de « Route de la soie », peut-être le premier marché Web sombre bien connu, important, répandu et largement utilisé où pratiquement tout est permis.

Donc, tout a explosé en 2013.

Parce que le fondateur, connu à l'origine uniquement sous le nom de Le redoutable pirate Roberts, mais finalement révélé être Ross Ulbricht… sa faible sécurité opérationnelle était suffisante pour lier les activités à lui.

Le fondateur de Silk Road, Ross Ulbricht, condamné à perpétuité sans libération conditionnelle

Non seulement sa sécurité opérationnelle n'était pas très bonne, mais il semblerait qu'à la fin de 2012, ils aient eu (tu le crois, Doug ?) une erreur de traitement des paiements en crypto-monnaie…


DOUG.  [GASPS EN FAUSSE HORREUR]


CANARD.  … du type que nous avons vu répété plusieurs fois depuis, qui n'a pas tout à fait fait une comptabilité en partie double appropriée, où pour chaque débit, il y a un crédit correspondant et vice versa.

Et cet attaquant a découvert, si vous mettez de l'argent sur votre compte et que vous le versez très rapidement sur d'autres comptes, que vous pouvez en fait payer cinq fois (voire plus) les mêmes bitcoins avant que le système ne se rende compte que le premier débit a disparu à travers.

Donc, vous pourriez essentiellement mettre de l'argent, puis le retirer encore et encore et encore, et obtenir une plus grande réserve…

… et ensuite vous pourriez revenir dans ce que vous pourriez appeler une "boucle de traite de crypto-monnaie".

Et on estime… les enquêteurs n'étaient pas sûrs, qu'il avait commencé avec entre 200 et 2000 bitcoins (qu'il les ait achetés ou minés, on ne sait pas), et qu'il les a très, très vite transformés en, attends, Doug : 50,0000 XNUMX bitcoins !


DOUG.  Hou la la!


CANARD.  Plus de 50,000 XNUMX bitcoins, juste comme ça.

Et puis, pensant évidemment que quelqu'un allait le remarquer, il a coupé et couru alors qu'il était devant avec 50,000 XNUMX bitcoins…

…chacun vaut 12 $, contre des fractions de cent quelques années auparavant. [DES RIRES]

Alors il s'est enfui avec 600,000 XNUMX $, juste comme ça, Doug.

[PAUSE DRAMATIQUE]

Neuf ans plus tard…

[RIRE]

…presque *exactement* neuf ans plus tard, lorsqu'il a été arrêté et que son domicile a été perquisitionné sous mandat, les flics sont allés chercher et ont trouvé une pile de couvertures dans son placard, sous laquelle était cachée une boîte de pop-corn.

Endroit étrange pour garder votre pop-corn.

A l'intérieur se trouvait une sorte de portefeuille froid informatisé.

A l'intérieur duquel se trouvaient une grande proportion desdits bitcoins !

Au moment où il a été arrêté, les bitcoins coûtaient au nord de 65,535 2 dollars (ou XNUMX16-1 chacun.

Ils avaient été multipliés par mille entre-temps.

Donc, à l'époque, c'était le plus gros buste de cryptocoins de tous les temps !

Neuf ans plus tard, n'ayant apparemment pas été en mesure de disposer de ses gains mal acquis, craignant peut-être que même s'il tentait de les fourrer dans un gobelet, tous les doigts se pointent vers lui…

… il a eu tous ces 3 milliards de dollars de bitcoins qui sont restés dans une boîte de pop-corn pendant neuf ans !


DOUG.  Mon Dieu.


CANARD.  Donc, après s'être assis sur ce trésor effrayant pendant toutes ces années, se demandant s'il allait se faire prendre, il se demande maintenant : "Combien de temps vais-je aller en prison ?"

Et la peine maximale pour l'accusation à laquelle il fait face ?

20 ans, Doug.


DOUG.  Une autre histoire intéressante se passe en ce moment. Si vous avez été sur Twitter récemment, vous saurez qu'il y a beaucoup d'activité. pour le dire diplomatiquement…


CANARD.  [Usurpation d'identité de BOB DYLAN DE QUALITÉ FAIBLE À MOYENNE] Eh bien, les temps changent.


DOUG.  … y compris à un moment donné l'idée de facturer 20 $ pour un chèque bleu vérifié, ce qui, bien sûr, presque immédiatement a provoqué des arnaques.

Escroqueries par e-mail Twitter Blue Badge - Ne tombez pas dans le piège !


CANARD.  C'est juste un rappel, Doug, que chaque fois qu'il y a quelque chose qui suscite beaucoup d'intérêt, les escrocs suivront sûrement.

Et la prémisse de ceci était: «Hé, pourquoi ne pas arriver tôt? Si vous avez déjà une marque bleue, devinez quoi ? Vous n'aurez pas à payer les 19.99 $ par mois si vous vous préinscrivez. Nous vous laisserons le garder.

Nous savons que ce n'était pas l'idée d'Elon Musk, comme il l'a dit, mais c'est le genre de chose que font de nombreuses entreprises, n'est-ce pas ?

De nombreuses entreprises vous offriront une sorte d'avantage si vous restez avec le service.

Ce n'est donc pas tout à fait incroyable.

Comme tu dis… qu'est-ce que tu lui as donné ?

B-moins, c'est ça ?


DOUG.  Je donne au premier e-mail un B-moins… vous pourriez peut-être être trompé si vous le lisiez rapidement, mais il y a quelques problèmes de grammaire ; les choses ne se sentent pas bien.

Et puis une fois que vous avez cliqué, je donnerais aux pages de destination C-moins.

Cela devient encore plus risqué.


CANARD.  C'est quelque part entre 5/10 et 6/10 ?


DOUG.  Oui, disons ça.

Et nous avons quelques conseils, pour que même s'il s'agit d'une arnaque A+, cela n'aura pas d'importance car vous pourrez quand même la déjouer !

A commencer par mon préféré : Utilisez un gestionnaire de mots de passe.

Un gestionnaire de mots de passe résout de nombreux problèmes en matière d'arnaques.


CANARD.  Cela fait.

Un gestionnaire de mots de passe n'a pas d'intelligence humaine qui peut être induite en erreur par le fait que la jolie image est correcte, ou que le logo est parfait, ou que le formulaire Web est exactement au bon endroit sur l'écran avec exactement la même police , donc vous le reconnaissez.

Tout ce qu'il sait, c'est: "Jamais entendu parler de ce site auparavant."


DOUG.  Et bien sur, activez 2FA si vous le pouvez.

Ajoutez toujours un deuxième facteur d'authentification, si possible.


CANARD.  Bien sûr, cela ne vous protège pas nécessairement de vous-même.

Si vous allez sur un faux site et que vous avez décidé, "Hé, c'est parfait au pixel près, ça doit être la vraie affaire", et que vous êtes déterminé à vous connecter, et que vous avez déjà entré votre nom d'utilisateur et votre mot de passe, puis il vous demande de passer par le processus 2FA…

… vous êtes très susceptible de le faire.

Cependant, cela vous donne un peu de temps pour faire le "Stop. Pense. Relier." chose, et dites-vous: "Attends, qu'est-ce que je fais ici?"

Ainsi, d'une certaine manière, le peu de retard introduit par 2FA peut en fait être non seulement très peu de tracas, mais aussi un moyen d'améliorer réellement votre flux de travail de cybersécurité… en introduisant juste assez d'un ralentisseur que vous êtes enclin à prendre la cybersécurité un peu plus au sérieux.

Donc je ne vois pas vraiment quel est l'inconvénient.


DOUG.  Et bien sûr, une autre stratégie difficile à suivre pour beaucoup de gens, mais très efficace, consiste à éviter les liens de connexion et les boutons d'action dans les e-mails.

Donc, si vous recevez un e-mail, ne cliquez pas simplement sur le bouton… allez sur le site lui-même et vous pourrez dire assez rapidement si cet e-mail était légitime ou non.


CANARD.  Fondamentalement, si vous ne pouvez pas totalement faire confiance à la correspondance initiale, vous ne pouvez pas vous fier aux détails qu'elle contient, qu'il s'agisse du lien sur lequel vous allez cliquer, du numéro de téléphone que vous allez appeler, de l'adresse e-mail que vous allez les contacter sur , le compte Instagram auquel vous allez envoyer des DM, quel qu'il soit.

N'utilisez pas ce qu'il y a dans l'e-mail… trouvez votre propre chemin et vous court-circuiterez de nombreuses arnaques de ce type.


DOUG.  Et enfin, last but not least… cela devrait être du bon sens, mais ce n'est pas le cas : Ne demandez jamais à l'expéditeur d'un message incertain s'il est légitime.

Ne répondez pas et ne dites pas : « Hey, êtes-vous vraiment Twitter ? »


CANARD.  Oui, vous avez bien raison.

Parce que mon conseil précédent, "Ne vous fiez pas aux informations contenues dans l'e-mail", comme ne pas appeler leur numéro de téléphone… certaines personnes sont tentées de dire, "Eh bien, je vais appeler le numéro de téléphone et voir si c'est vraiment c'est eux. [IRONIQUE] Parce que, évidemment, si le cuisinier répond, ils vont donner leurs vrais noms.


DOUG.  Comme on dit toujours : En cas de doute / Ne le donnez pas.

Et ceci est un bon récit édifiant, cette histoire suivante : lorsque les analyses de sécurité, qui sont des outils de sécurité légitimes, révéler plus qu'ils ne le devraient, que se passe-t-il alors ?

Outils d'analyse d'URL publiques - lorsque la sécurité mène à l'insécurité


CANARD.  Il s'agit d'un chercheur bien connu du nom de Fabian Bräunlein en Allemagne… nous l'avons déjà présenté plusieurs fois.

Il revient avec un rapport détaillé intitulé urlscan.ioLe spot SOAR de : des outils de sécurité bavards qui divulguent des données privées.

Et dans ce cas, c'est urlscan.io, un site Web que vous pouvez utiliser gratuitement (ou en tant que service payant) où vous pouvez soumettre une URL, ou un nom de domaine, ou un numéro IP, ou quoi que ce soit, et vous pouvez rechercher, "Que sait la communauté à propos de ça?"

Et cela révélera l'URL complète sur laquelle d'autres personnes ont posé des questions.

Et ce ne sont pas seulement des choses que les gens copient et collent de leur propre choix.

Parfois, leurs e-mails, par exemple, peuvent passer par un outil de filtrage tiers qui extrait lui-même les URL, appelle urlscan.io, effectue la recherche, obtient le résultat et l'utilise pour décider s'il faut envoyer du courrier indésirable, bloquer le spam ou transmettre le message.

Et cela signifie que parfois, si l'URL comprenait des données secrètes ou semi-secrètes, des informations personnellement identifiables, alors d'autres personnes qui venaient de chercher le bon nom de domaine peu de temps après verraient toutes les URL recherchées, y compris choses qui peuvent être dans l'URL.

Vous savez, comme blahblah?username=doug&passwordresetcode= suivi d'une longue chaîne de caractères hexadécimaux, et ainsi de suite.

Et Bräunlein a dressé une liste fascinante du type d'URL, en particulier celles qui peuvent apparaître dans les e-mails, qui peuvent être régulièrement envoyées à un tiers pour filtrage, puis indexées pour la recherche.

Le type d'e-mails qu'il pensait être définitivement exploitable comprenait, mais sans s'y limiter : des liens de création de compte ; Liens de livraison de cadeaux Amazon ; Clés API ; demandes de signature DocuSign ; transferts de fichiers dropbox ; suivi des colis; les réinitialisations de mot de passe ; factures PayPal ; Partage de documents Google Drive ; Invitations SharePoint ; et des liens de désinscription à la newsletter.

Ne pas pointer du doigt SharePoint, Google Drive, PayPal, etc.

Ce ne sont là que des exemples d'URL qu'il a rencontrées et qui étaient potentiellement exploitables de cette manière.


DOUG.  Nous avons quelques conseils à la fin de cet article, qui se résument à : lire le rapport de Bräunlein ; lis urlscan.iole billet de blog de ; faites votre propre révision de code ; si vous avez un code qui effectue des recherches de sécurité en ligne ; savoir quelles fonctionnalités de confidentialité existent pour les soumissions en ligne ; et, surtout, apprenez à signaler des données malveillantes à un service en ligne si vous les voyez.

J'ai remarqué qu'il y a trois… sortes de limericks ?

Des mini-poèmes très créatifs à la fin de cet article…


CANARD.  [MOCK HORROR] Non, ce ne sont pas des limericks ! Les Limericks ont une structure très formelle à cinq lignes…


DOUG.  [RIRE] Je suis tellement désolé. C'est vrai!


CANARD.  …pour le mètre et la rime.

Très structuré, Doug !


DOUG.  Je suis tellement désolé, tellement vrai. [DES RIRES]


CANARD.  Ce n'est qu'un canular. [RIRE]

Encore une fois: En cas de doute / Ne le donnez pas.

Et si vous collectez des données : S'il ne devrait pas être dedans/Mettez-le directement dans la poubelle.

Et si vous écrivez du code qui appelle des API publiques susceptibles de révéler des données client : Ne faites jamais pleurer vos utilisateurs/Par la façon dont vous appelez l'API.


DOUG.  [RIRES] C'est nouveau pour moi, et j'aime beaucoup celui-là !

Et le dernier, mais non le moindre sur notre liste ici, nous avons parlé semaine après semaine de ce bogue de sécurité OpenSSL.

La grande question est maintenant, "Comment pouvez-vous dire qu'est-ce qui doit être réparé ? »

L'histoire de la mise à jour de sécurité OpenSSL - comment savoir ce qui doit être corrigé ?


CANARD.  En effet, Doug, comment savons-nous quelle version d'OpenSSL nous avons ?

Et évidemment, sous Linux, il vous suffit d'ouvrir une invite de commande et de taper openssl version, et il vous indique la version que vous avez.

Mais OpenSSL est une bibliothèque de programmation, et aucune règle ne dit qu'un logiciel ne peut pas avoir sa propre version.

Votre distribution utilise peut-être OpenSSL 3.0, et pourtant il y a une application qui dit : « Oh, non, nous n'avons pas mis à niveau vers la nouvelle version. Nous préférons OpenSSL 1.1.1, car il est toujours pris en charge, et au cas où vous ne l'auriez pas, nous apportons notre propre version.

Et donc, malheureusement, tout comme dans cette tristement célèbre affaire Log4Shell, vous avez dû partir à la recherche des trois ? 12 ? 154 ? qui sait combien d'endroits sur votre réseau où vous pourriez avoir un programme Log4J obsolète.

Idem pour OpenSSL.

En théorie, les outils XDR ou EDR pourraient être en mesure de vous le dire, mais certains ne le prendront pas en charge et beaucoup le décourageront : exécutez le programme pour savoir de quelle version il s'agit.

Parce que, après tout, si c'est le buggy ou le mauvais, et que vous devez exécuter le programme pour qu'il signale sa propre version…

…c'est comme mettre la charrue avant les bœufs, n'est-ce pas ?

Nous avons donc publié un article pour les cas particuliers où vous voulez réellement charger la DLL, ou la bibliothèque partagée, et vous voulez en fait appeler la sienne TellMeThyVersion() code logiciel.

En d'autres termes, vous faites suffisamment confiance au programme pour le charger en mémoire, l'exécuter et en exécuter certains composants.

Nous vous montrons comment faire cela afin que vous puissiez être absolument certain que tous les fichiers OpenSSL périphériques que vous avez sur votre réseau sont à jour.

Parce que bien que cela ait été rétrogradé de CRITICAL à HIGH, il s'agit toujours d'un bogue que vous devez et que vous souhaitez corriger !


DOUG.  Au sujet de la gravité de ce bogue, nous avons reçu un question interessante du lecteur de sécurité Naked Svet, qui écrit, en partie :

Comment se fait-il qu'un bogue dont l'exploitation est extrêmement complexe et qui ne peut être utilisé que pour des attaques par déni de service continue d'être classé comme ÉLEVÉ ?


CANARD.  Oui, je pense qu'il a dit quelque chose comme "Oh, l'équipe OpenSL n'a-t-elle pas entendu parler de CVSS ?", qui est une norme du gouvernement américain, si vous voulez, pour encoder le niveau de risque et de complexité des bogues d'une manière qui peut être automatiquement filtré par scripts.

Donc, s'il a un faible score CVSS (qui est le Système commun de notation des vulnérabilités), pourquoi les gens s'enthousiasment-ils ?

Pourquoi devrait-il être ÉLEVÉ ?

Et donc ma réponse a été: "Pourquoi * ne devrait-il pas * être ÉLEVÉ?"

C'est un bogue dans un moteur cryptographique ; cela pourrait faire planter un programme, disons, qui essaie d'obtenir une mise à jour… donc il plantera encore et encore, ce qui est un peu plus qu'un simple déni de service, car cela vous empêche en fait de faire votre sécurité correctement.

Il y a un élément de contournement de sécurité.

Et je pense que l'autre partie de la réponse est, lorsqu'il s'agit de transformer des vulnérabilités en exploits : "Ne jamais dire jamais !"

Lorsque vous avez quelque chose comme un débordement de tampon de pile, où vous pouvez manipuler d'autres variables sur la pile, y compris éventuellement des adresses mémoire, il y aura toujours la possibilité que quelqu'un trouve un exploit exploitable.

Et le problème, Doug, c'est qu'une fois qu'ils ont compris, peu importe à quel point c'était compliqué à comprendre...

… une fois que vous savez comment l'exploiter, *n'importe qui* peut le faire, car vous pouvez leur vendre le code pour le faire.

Je pense que vous savez ce que je vais dire : "Ce n'est pas que j'y sois attaché."

[RIRE]

C'est, encore une fois, l'une de ces choses « damnés s'ils le font, damnés s'ils ne le font pas ».


DOUG.  Très bien, merci beaucoup, Svet, d'avoir écrit ce commentaire et de 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é!


Horodatage:

Plus de Sécurité nue