Logo Zéphyrnet

S3 Ep136 : Naviguer dans un maelström maniaque de logiciels malveillants

Date :

UN VORTEX DE PERSPECTIVE EN PYTHON

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, 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.  La cybercriminalité après la cybercriminalité, certaines mises à jour Apple et une attaque contre un référentiel de code source.

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, comment vas-tu ?


CANARD.  Très bien merci. Douglas !

Était-ce assez gai ?


DOUG.  C'était plutôt bien.

Comme, un 7/10 sur l'échelle du bonheur, ce qui est une assez bonne base.


CANARD.  Oh, je voulais que ça se sente plus haut que ça.

Ce que j'ai dit, plus 2.5/10.


DOUG.  [ÉTONNEMENT EXAGÉRÉ] Oh, Paul, tu sonnes bien !


CANARD.  [RIRES] Merci, Doug.


DOUG.  Eh bien, cela pourrait vous pousser jusqu'à un 10/10, alors… Cette semaine dans l'histoire de la technologie.

Le 22 mai 1973, au Xerox Palo Alto Research Center [PARC], le chercheur Robert Metcalfe rédige une note proposant une nouvelle façon de connecter des ordinateurs entre eux.

Inspirée de son précurseur, AlohaNet, que Metcalfe a étudié dans le cadre de sa thèse de doctorat, la nouvelle technologie s'appellerait Ethernet, un clin d'œil à la substance «éther luminifère», qui était autrefois considérée comme un moyen de propagation des ondes lumineuses.


CANARD.  C'était certainement beaucoup plus rapide que les disquettes simple face et simple densité de 160 Ko ! [RIRE]


DOUG.  Pourrait être pire!

Quoi qu'il en soit, en parlant de « pire » et de « méchanceté », nous avons notre première mise à jour sur la criminalité de la journée.

Les États-Unis proposent une Prime de 10 millions de dollars pour un suspect de rançongiciel russe.

Les États-Unis offrent une prime de 10 millions de dollars au suspect russe d'un rançongiciel mis en accusation

C'est beaucoup d'argent, Paul !

Ce type a dû faire quelque chose de très mauvais.

La déclaration du DOJ :

[Cette personne et ses compagnons conspirateurs] auraient utilisé ces types de rançongiciels pour attaquer des milliers de victimes aux États-Unis et dans le monde. Ces victimes comprennent les forces de l'ordre et d'autres organismes gouvernementaux, les hôpitaux et les écoles.

Le total des demandes de rançon prétendument faites par les membres de ces trois campagnes mondiales de rançongiciels à leurs victimes s'élève à 400 millions de dollars, tandis que le total des paiements de rançon aux victimes s'élève à 200 millions de dollars.

Big Time Attacks… beaucoup d'argent change de mains ici, Paul.


CANARD.  Lorsque vous essayez de traquer quelqu'un qui fait des choses ignobles à l'étranger et que vous pensez : « Comment diable allons-nous faire cela ? Ils ne se présenteront jamais au tribunal ici »…

Peut-être qu'on offre juste un sale profit aux gens dans le pays de cette autre personne, et quelqu'un va le dénoncer ?

Et s'ils offrent 10 millions de dollars (enfin, c'est le maximum que vous pouvez obtenir), ils doivent être très enthousiastes.

Et ma compréhension, dans ce cas, est la raison pour laquelle ils tiennent à ce que ce suspect particulier soit accusé d'être, sinon le cœur et l'âme, au moins l'une des deux de ces choses pour trois souches de rançongiciels différentes : LockBit, Hive et Babuk.

Babuk a connu une fuite de son code source (si je ne me trompe pas, par un affilié mécontent), et a maintenant trouvé son chemin sur GitHub, où quiconque le souhaite peut récupérer la partie cryptage.

Et même s'il est difficile de ressentir la moindre sympathie pour les personnes qui sont dans le collimateur du DOJ et du FBI pour des attaques de ransomwares…

… s'il restait des gouttelettes de sympathie latentes, elles s'évaporent assez rapidement lorsque vous commencez à lire sur les hôpitaux et les écoles parmi leurs nombreuses victimes.


DOUG.  Oui.


CANARD.  Vous devez donc supposer qu'il est peu probable qu'ils le voient un jour devant un tribunal américain…

… mais je suppose qu'ils ont pensé que c'était trop important pour ne pas essayer.


DOUG.  Exactement.

Nous allons, comme nous aimons le dire, garder un œil là-dessus.

Et en attendant, allez voir notre Rapport sur l'état des rançongiciels 2023.

Il contient un tas de faits et de chiffres que vous pouvez utiliser pour aider à protéger votre organisation contre les attaques.

C'est disponible sur : sophos.fr/ransomware2023.


CANARD.  Un petit indice que vous pouvez apprendre du rapport : « Surprise, surprise ; cela vous coûte environ deux fois moins cher pour récupérer des sauvegardes que pour payer la rançon.

Parce que même après avoir payé la rançon, vous avez encore autant de travail que vous auriez à faire pour restaurer votre sauvegarde.

Et cela signifie également que vous ne payez pas les escrocs.


DOUG.  Exactement!

Très bien, nous avons une autre mise à jour sur la criminalité.

Cette fois, ce sont nos amis d'iSpoof qui, je dois l'admettre, ont une assez bonne équipe marketing.

À l'exception de tout le monde se fait choper et tout ce genre de choses…

Le pivot de l'escroquerie par téléphone obtient 13 ans pour avoir exécuté le service "iSpoof"


CANARD.  Oui, il s'agit d'un rapport de la police métropolitaine de Londres concernant une affaire qui dure depuis novembre 2022, lorsque nous a d'abord écrit à ce sujet sur nakedsecurity.sophos.com.

Un type appelé Tejay Fletcher, et je pense que 169 autres personnes qui pensaient qu'ils étaient anonymes, mais il s'est avéré qu'ils ne l'étaient pas, ont été arrêtés.

Et ce gars de Fletcher, qui en était la cheville ouvrière, vient d'être condamné à 13 ans et 4 mois de prison, Doug.

C'est une assez grosse phrase selon les normes de n'importe quel pays !

Et la raison en est que ce service visait à aider d'autres cybercriminels, en échange de bitcoinage, à arnaquer les victimes de manière très crédible.

Vous n'aviez besoin d'aucune compétence technique.

Vous pouvez simplement vous inscrire au service, puis commencer à passer des appels téléphoniques où vous pouvez choisir le numéro qui s'affichera à l'autre bout.

Donc, si vous avez la moindre idée que quelqu'un a effectué une banque avec XYZ Banking Corporation, vous pouvez faire s'allumer son téléphone en disant "Appel entrant de XYZ Banking Corporation", puis lancer votre schpiel.

Il semble, d'après les rapports de la National Crime Agency à l'époque, que leurs « clients » aient passé des millions d'appels via ce service. et ils avaient quelque chose comme un taux de réussite de 10%, où le succès est mesuré que l'appelant était en ligne pendant au moins une minute.

Et quand vous pensez que quelque chose est un appel frauduleux… vous raccrochez assez rapidement, n'est-ce pas ?


DOUG.  Une minute c'est long !


CANARD.  Et cela signifie qu'ils ont probablement accroché la personne.

Et vous pouvez voir pourquoi, parce que tout semble crédible.

Si vous ne savez pas que le numéro d'identification de l'appelant (ou d'identification de la ligne d'appel) qui s'affiche sur votre téléphone n'est rien de plus qu'un indice, que n'importe qui peut mettre n'importe quoi et que toute personne ayant vos pires intérêts à cœur qui veut vous traquer peuvent, pour une dépense mensuelle modeste, souscrire à un service qui les aidera à le faire automatiquement…

Si vous ne savez pas que c'est le cas, vous allez probablement baisser la garde quand cet appel vous dira : « J'appelle de la banque. Vous pouvez le voir à partir du numéro. Oh là là, il y a eu une fraude sur votre compte », puis l'appelant vous demande de faire tout un tas de choses que vous n'écouteriez pas un instant autrement.

La portée de ce service, le grand nombre de personnes qui l'utilisaient (il avait des dizaines de milliers de "clients", apparemment), et le nombre d'appels et le montant des dommages financiers causés, qui se chiffraient à des millions, est la raison pour laquelle il a obtenu une telle peine grave.


DOUG.  Une partie de la raison pour laquelle ils ont pu attirer autant de clients est que c'était sur un site Web public.

Ce n'était pas sur le dark web, et c'était un marketing assez astucieux.

Si vous vous dirigez vers l'article, il y a une vidéo marketing de 53 secondes avec un acteur voix off professionnel et des animations amusantes.

C'est une vidéo plutôt bien faite !


CANARD.  Oui!

J'y ai repéré une faute de frappe… ils ont écrit «chiffrement de bout en bout» plutôt que «chiffrement de bout en bout», ce que j'ai remarqué parce que c'était assez ironique.

Parce que toute la prémisse de cette vidéo - elle dit : "Hé, en tant que client, vous êtes complètement anonyme."

Ils en ont fait un gros pitch.


DOUG.  Je pense que c'était probablement une "fin du cryptage". [DES RIRES]


CANARD.  Oui… vous avez peut-être été anonyme pour vos victimes, mais vous n'étiez pas anonyme pour le fournisseur de services.

Apparemment, les flics, au moins au Royaume-Uni, ont décidé de commencer avec quiconque avait déjà dépensé plus de 100 £ en Bitcoins avec le service.

Il peut donc y avoir des gens qui se sont essayés à cela, ou qui l'ont utilisé juste pour quelques choses, qui sont toujours sur la liste.

Les flics veulent que les gens sachent qu'ils ont commencé au sommet et qu'ils descendent.

L'anonymat promis dans la vidéo était illusoire.


DOUG.  Eh bien, nous avons quelques conseils, et nous avons déjà dit ces conseils, mais ce sont d'excellents rappels.

Y compris l'un de mes favoris, car je pense que les gens supposent simplement que l'identification de l'appelant est un journaliste précis…. le conseil numéro un est : Traitez l'identification de l'appelant comme rien de plus qu'un indice.

Que veux-tu dire par là, Paul ?


CANARD.  Si vous recevez toujours du courrier postal chez vous, vous saurez que lorsque vous recevez une enveloppe, elle porte votre adresse au recto, et généralement, lorsque vous la retournez, au verso de l'enveloppe, il y a une adresse de retour .

Et tout le monde sait que l'expéditeur peut choisir ce que cela dit… cela peut être authentique ; tout cela pourrait être un paquet de mensonges.

C'est à quel point vous pouvez faire confiance à l'identification de l'appelant.

Et tant que vous gardez cela à l'esprit et que vous y pensez comme un indice, alors vous êtes en or.

Mais s'il apparaît et dit "XYZ Banking Corporation" parce que les escrocs ont délibérément choisi un numéro que vous avez spécialement mis dans votre liste de contacts pour venir vous dire que c'est la banque… cela ne veut rien dire.

Et le fait qu'ils commencent à vous dire qu'ils viennent de la banque ne veut pas dire qu'ils le sont.

Et cela enchaîne bien avec notre deuxième conseil, n'est-ce pas, Doug ?


DOUG.  Oui.

Initiez toujours vous-même les appels officiels, en utilisant un numéro de confiance.

Donc, si vous recevez l'un de ces appels, dites « Je vais vous rappeler tout de suite » et utilisez le numéro au dos de votre carte de crédit.


CANARD.  Absolument.

S'ils vous ont amené à croire que c'est le numéro que vous devriez appeler… ne le faites pas !

Découvrez-le par vous-même.

Comme vous l'avez dit, pour signaler des choses comme des fraudes bancaires ou des problèmes bancaires, le numéro au dos de votre carte de crédit est un bon début.

Donc, oui, soyez très, très prudent.

Il est vraiment facile de croire votre téléphone, car 99% du temps, ce numéro d'identification de l'appelant dira la vérité.


DOUG.  D'accord, le dernier mais non le moindre, pas aussi technique, mais plutôt une compétence plus douce, le conseil numéro trois est : Soyez là pour les amis et la famille vulnérables.

C'en est une bonne.


CANARD.  Il y a évidemment des personnes qui sont plus exposées à ce genre d'escroquerie.

Il est donc important que vous informiez les personnes de votre cercle d'amis et de votre famille qui, selon vous, pourraient être à risque de ce genre de choses… faites-leur savoir que s'ils ont le moindre doute, ils doivent vous contacter et vous demander conseil .

Comme chaque charpentier ou menuisier vous le dira, Douglas, "Mesurez deux fois, coupez une fois."


DOUG.  J'aime ce conseil. [DES RIRES]

J'ai tendance à mesurer une fois, à couper trois fois, alors ne suivez pas mon exemple.


CANARD.  Oui. Vous ne pouvez pas "couper les choses plus longtemps", hein ? [RIRE]


DOUG.  Non, vous ne pouvez certainement pas !


CANARD.  Nous avons tous essayé. [DES RIRES]


DOUG.  C'est deux mises à jour vers le bas; un pour aller.

Nous avons obtenu une mise à jour… si vous vous souvenez, plus tôt ce mois-ci, Apple nous a surpris avec une nouvelle réponse de sécurité rapide, mais il n'a pas dit ce que les mises à jour ont réellement corrigé, mais maintenant nous le savons, Paul.

Le secret d'Apple est sorti : 3 jours zéro corrigés, alors assurez-vous d'appliquer le correctif maintenant !


CANARD.  Oui.

Deux jours 0, plus un jour 0 bonus qui n'a pas été fixé auparavant.

Donc, si vous aviez, qu'est-ce que c'était, macOS 13 Ventura (le dernier), et si vous aviez iOS/iPadOS 16, vous avez obtenu la réponse de sécurité rapide

Vous avez cette mise à jour "numéro de version (a)", et "voici le détail de cette mise à jour : (chaîne de texte vide)".

Vous n'aviez donc aucune idée de ce qui avait été corrigé.

Et vous, comme nous, avez probablement pensé : « Je parie que c'est un jour zéro dans WebKit. Cela signifie une installation au volant. Cela signifie que quelqu'un pourrait l'utiliser pour un logiciel espion.

Et voilà, c'est exactement ce qu'étaient ces deux jours 0.

Et il y avait un troisième jour zéro, qui était, si vous voulez, une autre partie de cette équation, ou un autre type d'exploit qui accompagne souvent les deux premiers jours zéro qui ont été corrigés.

Celui-ci était un truc de Google Threat Response / Amnesty International qui sentait certainement le logiciel espion pour moi… quelqu'un enquêtant sur un incident réel.

Ce bogue était ce que vous appelez dans le jargon une "évasion de bac à sable".

Il semble que les trois jours zéro qui sont désormais fixés pour toutes les plates-formes Apple étaient…

Celui qui pourrait permettre à un escroc de comprendre ce qui se trouvait sur votre ordinateur.

En d'autres termes, ils augmentent considérablement les chances que leurs exploits ultérieurs fonctionnent.

Un deuxième exploit qui exécute du code à distance dans votre navigateur, comme je l'ai dit, aidé et encouragé par cette fuite de données dans le premier bogue qui pourrait vous dire quelles adresses mémoire utiliser.

Et puis un troisième jour zéro qui vous permet essentiellement de sortir du navigateur et de faire bien pire.

Eh bien, je vais dire, Corrigez tôt, corrigez souvent, n'est-ce pas, Doug ?


DOUG.  Fais le!

Oui.


CANARD.  Ce ne sont pas les seules raisons pour lesquelles vous voulez ces correctifs.

Il existe également un tas de correctifs proactifs.

Donc, même s'il ne s'agissait pas des jours zéro, je le répéterais quand même.


DOUG.  D'accord, super.

Notre dernière histoire du jour… J'avais écrit ma petite intro ici, mais je jette ça à la poubelle et je vais suivre ton titre, parce que c'est beaucoup mieux.

Et cela capture vraiment l'essence de cette histoire: Le référentiel de code open source PyPI traite du maelström de logiciels malveillants maniaques.

C'est ce qui s'est passé, Paul !

Le référentiel de code open source PyPI traite du maelstrom de logiciels malveillants maniaques


CANARD.  Oui, je dois admettre que j'ai dû travailler sur ce titre pour qu'il tienne exactement sur deux lignes dans le modèle WordPress nakedsecurity.sophos.com. [RIRE]

L'équipe PyPI a maintenant surmonté cela, et je pense qu'ils se sont débarrassés de tout.

Mais il semble que quelqu'un avait un système automatisé qui ne faisait que générer de nouveaux comptes, puis, dans ces comptes, créer de nouveaux projets…

…et juste télécharger le paquet source empoisonné après le paquet source empoisonné.

Et rappelez-vous que dans la plupart de ces référentiels (PyPI est un exemple), vous pouvez avoir des logiciels malveillants dans le code réel que vous souhaitez télécharger et utiliser plus tard comme module dans votre code (en d'autres termes, la bibliothèque de programmation), et/ ou vous pouvez avoir des logiciels malveillants dans le programme d'installation ou le script de mise à jour qui vous fournit la chose.

Donc, malheureusement, il est facile pour les escrocs de cloner un projet légitime, de lui donner un nom réaliste et d'espérer que si vous le téléchargez par erreur…

… Ensuite, après l'avoir installé, et une fois que vous commencez à l'utiliser dans votre logiciel, et une fois que vous commencez à l'expédier à vos clients, tout ira bien et vous n'y trouverez aucun logiciel malveillant.

Parce que le logiciel malveillant aura déjà infecté votre ordinateur, en étant dans le script qui s'est exécuté pour installer correctement la chose en premier lieu.

Il y a donc un double coup dur pour les escrocs.

Ce que nous ne savons pas, c'est…

Espéraient-ils télécharger tellement de paquets infectieux que certains d'entre eux ne seraient pas repérés, et qu'ils auraient une chance de se battre pour qu'un couple soit simplement laissé pour compte ?

Ou espéraient-ils réellement qu'ils pourraient effrayer l'équipe PyPI au point de devoir retirer tout le site des ondes, et que ce serait une attaque par déni de service complète ?

Ni l'un ni l'autre n'était le résultat.

L'équipe PyPI a pu atténuer l'attaque en fermant seulement certains aspects du site.

À savoir, pendant un certain temps, vous ne pouviez pas créer de nouveau compte et vous ne pouviez pas ajouter de nouveau projet, mais vous pouviez toujours en obtenir d'anciens.

Et cela leur a donné juste assez de marge de manœuvre, sur une période de 24 heures, pour qu'il semble qu'ils aient pu nettoyer entièrement.


DOUG.  Nous avons quelques conseils pour les attaques comme celle-ci où elles ne sont pas nettoyées à temps.

Donc, si vous extrayez des référentiels comme celui-ci, la première chose que vous pouvez faire est de : Ne choisissez pas un package de référentiel simplement parce que le nom semble correct.

C'est une tactique souvent utilisée par les attaquants.


CANARD.  En effet, Douglas.

C'est essentiellement ce que nous avions l'habitude d'appeler dans le jargon "typosquatting" pour les sites Web.

Au lieu de s'inscrire example.com, vous pourriez enregistrer quelque chose comme examole.com, parce que O est à côté de P sur le clavier, dans l'espoir que quelqu'un ira taper "exemple", faites une légère erreur et vous récupérerez leur trafic et les dirigerez vers un site similaire.

Faites attention à ce que vous choisissez.

C'est un peu comme nos conseils sur l'identification de l'appelant : cela vous dit quelque chose, mais pas trop.

Et, pour le reste, il faut vraiment faire preuve de diligence raisonnable.


DOUG.  Telle que : Ne téléchargez pas aveuglément les mises à jour de packages dans vos propres systèmes de développement ou de construction.


CANARD.  Oui, DevOps et l'intégration continue sont tout ce qu'il y a de nos jours, n'est-ce pas, où vous automatisez tout ?

Et il y a quelque chose d'attrayant à dire : "Eh bien, je ne veux pas prendre de retard, alors pourquoi ne dirais-je pas simplement à mon système de construction de prendre mon code de mon référentiel local où je m'en occupe, et puis toujours juste obtenir automatiquement la dernière version du référentiel public de tous les codes d'autres personnes que j'utilise ? »

Le problème est que si l'un de ces packages tiers que vous utilisez est bloqué, votre système de construction va se retrouver en difficulté de manière entièrement automatique.

Alors ne le faites pas si vous pouvez éventuellement l'éviter.


DOUG.  Ce qui nous amène à : Ne facilitez pas l'accès des attaquants à vos propres packages.


CANARD.  Oui.

Personne ne peut vraiment arrêter quelqu'un qui est déterminé à créer, à la main, 2000 nouveaux comptes PyPI et à mettre 1000 nouveaux packages dans chacun d'eux.

Mais vous pouvez faire des attaques où des escrocs prennent le contrôle de packages existants et les compromettent… vous pouvez faire votre part pour aider le reste de la communauté en rendant aussi difficile que possible la compromission de vos projets.

Allez revoir la sécurité que vous avez sur ce compte ou sur ce paquet, juste au cas où quelqu'un déciderait que ce serait un endroit magistral pour insérer des logiciels malveillants qui pourraient affecter d'autres personnes… et bien sûr cela ternirait au moins temporairement votre réputation en même temps temps.


DOUG.  Et notre dernier conseil tombera peut-être dans l'oreille d'un sourd, mais s'il suffit de changer quelques esprits, nous avons fait du bon travail ici aujourd'hui : Ne sois pas un tu-sais-quoi.


CANARD.  Prouver à quel point vous êtes intelligent en nous rappelant à tous les attaques de la chaîne d'approvisionnement en faisant du travail inutile pour les équipes de bénévoles… comme l'équipe du noyau Linux (ils en ont souffert dans le passé), PyPI et d'autres référentiels open source populaires ?

Si vous avez une raison valable pour laquelle vous pensez devoir leur parler d'une faille de sécurité, recherchez leurs coordonnées de divulgation de sécurité et contactez-les de manière appropriée, professionnelle et responsable.

Ne soyez pas un ****.


DOUG.  Excellent.

Très bien, bon conseil, et alors que le soleil commence à se coucher sur notre émission du jour, il est temps d'entendre l'un de nos lecteurs.

Dans l'épisode précédent du podcast, vous vous souviendrez peut-être que nous avons un peu parlé des épreuves et des tribulations de l'ordinateur Apple III. Écoutons :

Je ne sais pas s'il s'agit d'une légende urbaine ou non, mais j'ai lu que les premiers modèles [Apple III] n'avaient pas leurs puces correctement installées en usine, et que les destinataires qui signalaient des problèmes devaient soulever l'avant de l'ordinateur de leur bureau de quelques centimètres et le laissent tomber en arrière, ce qui les remettrait en place comme ils auraient dû l'être en premier lieu. Ce qui a apparemment fonctionné, mais n'était pas le meilleur type de publicité pour la qualité du produit.


DOUG.  En réponse, l'auditeur S31064 (je ne sais pas s'il s'agit d'un vrai nom de naissance) intervient :

Je ne sais pas à ce sujet, mais l'entreprise pour laquelle je travaillais à l'époque les utilisait pour les terminaux de circulation hors ligne de la bibliothèque. Et neuf fois sur dix, s'il y avait un problème, la solution consistait à réinstaller les puces.


CANARD.  Oui, passer en revue votre carte mère et (craquement, craquement) appuyer sur toutes les puces… c'était alors considéré comme un entretien de routine.

Mais il semble que pour l'Apple III, il ne s'agissait pas seulement d'un entretien de routine, d'un entretien préventif, il s'agissait en fait d'une technique de récupération reconnue.

J'étais donc fasciné de lire ça, Doug.

Quelqu'un qui avait réellement été là, et qui avait fait ça !


DOUG.  Eh bien, merci beaucoup, cher auditeur, d'avoir envoyé cela.

Et 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 des 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]


spot_img

Dernières informations

spot_img