Attention, ça va faire mal surtout si vous pensiez que vos conversations sur Discord étaient à l’abri des regards indiscrets. Désolé de casser l’ambiance, mais c’est loin d’être le cas.
Un petit malin a eu la bonne idée de créer un service en ligne baptisé « Spy Pet » qui s’amuse à aspirer en masse les données des serveurs Discord dont vos messages publics, les canaux vocaux que vous rejoignez, et les données liées à votre activité sur les différents serveurs. Et le pire, c’est que ces données sont ensuite revendues à bon prix (5$) à qui veut bien les acheter. De quoi être un brin parano !
Normalement, avec Discord, notre activité est éparpillée façon puzzle sur tout un tas de serveurs, et personne à part Discord lui-même ne peut voir ce qu’ont fait sur la plateforme dans son ensemble. Mais avec Spy Pet, n’importe qui peut potentiellement mater une partie de vos faits et gestes numériques pour une poignée de dollars. Le site se targue de pister plus de 14 000 serveurs et d’avoir en stock pas moins de 3 milliards de messages, de plus de 600 millions de comptes, mais difficile de vérifier ces chiffres.
Finalement, Discord n’est pas aussi privé qu’on pourrait le croire puisque les messages postés publiquement sur les serveurs sont à la merci du premier scraper venu. Heureusement, tout n’est pas perdu. Pour limiter les dégâts, voici quelques conseils :
Ouvrez l’œil sur les bots qui essaient de rejoindre vos serveurs. C’est souvent comme ça que les scrapers s’infiltrent mine de rien. Méfiez-vous des nouveaux venus sans photo de profil ni historique.
Si vous êtes admin, virez sans pitié les comptes louches qui traînent dans le coin.
Et surtout, partez du principe que tout ce que vous postez publiquement sur Discord peut potentiellement être vu par n’importe qui. Ça vaut pour tous les services en ligne d’ailleurs.
Bref, restez vigilants, sécurisez vos serveurs et réfléchissez avant de poster des trucs trop perso sur Discord ! Et si vous tenez vraiment à ce que vos échanges restent privés, passez plutôt par des apps de messagerie sécurisées de bout en bout, genre Signal ou Telegram. Ça évitera les mauvaises surprises !
Mateusz Jurczyk, un nom qui ne vous dit peut-être rien, mais retenez-le bien, car le bonhomme est fort. Ce chercheur en sécurité bien intentionné bosse pour Google Project Zero, une équipe de choc qui traque les failles dans tous les recoins depuis des années déjà. Et pendant quasi 2 ans, de mai 2022 à décembre 2023, il s’est lancé le défi d’ausculter un des organes les plus vitaux de Windows : sa base de registre.
Pour ceux qui débarquent, le registre, c’est un peu le cerveau de Windows. Une méga base de données qui stocke tous les réglages, options et préférences du système et des applis, organisés de manière hiérarchique avec des clés, des sous-clés et des valeurs. Bref, un truc super sensible et stratégique. Si un pirate arrive à mettre ses mains là dedans, bonjour les dégâts !
Mais notre Mateusz, c’est pas le genre à se dégonfler. Armé de ses outils et de ses connaissances en reverse engineering, il a plongé dans les millions de lignes de code de ce monolithe vieux de 30 ans et croyez-moi, il a frappé fort : pas moins de 50 failles critiques déterrées, dont 39 qui permettent une élévation de privilèges ! En gros, la totale pour passer de simple clampin à admin suprême sur une machine.
La force de son taf, c’est d’avoir exploré des endroits de la base de registres que personne n’avait vu avant. Des trucs bien planqués comme la récupération des transactions avortées, le chargement de ruches extraites ou les bails de virtualisation du registre (une fonctionnalité qui permet aux vieilles applis de tourner sans broncher sur les Windows récents). Bref, un vrai boulot de fourmi avec une grosse dose de persévérance.
Et le plus flippant, c’est que la moitié de ces failles seraient plutôt faciles à exploiter notamment via des techniques de corruption de mémoire ou de cassage des garanties de sécurité comme les ACL (les listes qui contrôlent qui a le droit de faire quoi dans le registre). Pour vous donner une idée, Mateusz a même créé des exploits de démo pour deux vulnérabilités, montrant comment détourner le registre à son avantage.
Heureusement, c’est un White Hat avec un grand cœur et toutes ses trouvailles ont été balancées en temps et en heure à Microsoft via le programme de divulgation responsable de Project Zero. Les ingés de Redmond ont évidemment remédié au boxon en patchant, avec des délais moyens de correction de 80 jours. Vous pouvez donc souffler !
Mais l’histoire est loin d’être finie. Il a tellement kiffé son voyage dans les méandres du registre, qu’il prévoit d’en faire une série de posts de blog pour partager son savoir. Au menu, des analyses bien poussées des bugs, des techniques d’exploit et plein de tips pour mieux protéger nos bécanes, comme :
Toujours avoir une sauvegarde du registre avant d’installer un nouveau soft : regedit.exe /e sauvegarde.reg
Scanner régulièrement le registre avec des outils comme CCleaner Registry Cleaner, Wise Registry Cleaner ou Glarysoft Registry Repair.
Se méfier des applis louches qui veulent mettre leur nez dans le registre et les virer en cas de doute.
Garder son Windows et ses drivers à jour pour bénéficier des derniers patchs de sécurité.
Utiliser les outils de monitoring comme l’Observateur d’événements ou les Performances Windows pour garder un œil sur l’activité du registre.
Aujourd’hui on va parler d’un outil de ouf pour trouver des buckets S3 ouverts : FestIn !
C’est le genre d’outil dont raffolent les chercheurs en sécurité puisqu’il qui explore tous les recoins du web pour dénicher des trucs que vous n’auriez jamais trouvé.
FestIn c’est la grosse artillerie de l’énumération de buckets S3 puisqu’il a tellement d’options que les autres outils à côté c’est de la gnognotte. Attention, c’est bien sûr à utiliser uniquement sur vos propres noms de domaines ou dans le cadre de missions d’audit pour lesquelles vous avez toutes les autorisations.
Avec lui, vous allez pouvoir :
Utiliser différentes techniques pour trouver des buckets : crawling du DNS et des pages web, analyse des réponses S3
Faire vos requêtes en passant par un proxy, no stress 🕶
Vous passer des credentials AWS, puisque ça marche avec n’importe quel provider compatible S3
Configurer vos propres serveurs DNS, parce que vous êtes trop beau gosse.
Profiter d’un crawler HTTP de compétition qui va retourner le web pour vous
Faire des recherches récursives et avoir du feedback entre les différents modules pour un max d’efficacité
Faire tourner le schmilblick en mode « watch » pour choper les nouveaux domaines en temps réel, ce qui est assez ouf quand on y pense.
Sauvegarder tous les domaines découverts dans un fichier, pour faire joujou avec plus tard
Indexer direct le contenu des objets des buckets pour faire des recherches full text de la mort, mieux que Google ! 😎
Cibler votre recherche sur des domaines spécifiques si vous voulez pas vous éparpiller
Pour l’installer c’est fastoche, au choix :
pip install festin
Ou en mode Docker :
docker run --rm -it cr0hn/festin -h
C’est du brut, du bourrin, puisqu’on va envoyer des requêtes en masse et gratter un max d’infos. Attention cependant, on reste fair-play, on ne veut pas faire planter le serveur non plus.
Par défaut, FestIn prend un unique domaine en argument :
festin mon-super-site.com
Mais on peut aussi lui filer un fichier texte contenant une liste de domaines, histoire d’être plus productif :
Crée un fichier domaines.txt avec tes domaines, un par ligne.
Lance la commande :
cat domaines.txt | festin -f -
FestIn balance plusieurs tests en même temps pour aller plus vite. Par défaut, il en lance 5. Si vous êtes pressé et que votre machine encaisse, vous pouvez augmenter ce nombre avec l’option -c :
festin -c 10 mon-super-site.com
Attention cependant, ne balancez pas un truc de fou, ça risque de faire bugger le site ciblé. On est là pour glaner des infos, pas pour casser du serveur.
L’outil dispose également d’un petit bot intégré qui va scanner le site à la recherche de liens pouvant mener à des buckets S3. On peut le configurer avec plusieurs options :
Timeout (-T ou –http-timeout) : Si le site est lent, on augmente le timeout pour pas que le scan plante. Par défaut, c’est 5 secondes.
Récursion max (-H ou –http-max-recursion) : On limite la profondeur du scan pour éviter de partir en vadrouille sur tout le net. Par défaut, c’est 3 niveaux, genre site.com -> lien -> site2.com -> lien -> site3.com.
Limite de domaine (-dr ou –domain-regex) : On peut dire au robot de se focaliser uniquement sur les sous-domaines qui correspondent à une expression régulière.
Liste noire (-B) : Fich un fichier texte contenant des mots clés. Si un domaine contient un de ces mots, on l’ignore.
Liste blanche (-W) : Même principe, mais à l’envers. On scanne uniquement les domaines contenant des mots clés de la liste blanche.
Pour cela, vous devez créer un fichier blacklist.txt contenant « cdn » et « photos » (on ignore les liens vers des CDN et des images) puis lancer la commande :
Attention : l’option -dr attend une expression régulière valide au format POSIX. Par exemple, mondomaine.com est invalide, alors que \.mondomaine\.com est correct.
FestIn crache un paquet d’infos intéressantes, pas seulement sur les buckets S3, mais aussi sur d’autres éléments identifiés. Ces infos peuvent ensuite être utilisées avec d’autres outils comme nmap.
Pour récupérer les résultats, FestIn propose trois modes qu’on peut combiner :
Fichier de résultats FestIn (-rr ou –result-file) : Ce fichier contient une ligne JSON par bucket trouvé, avec le nom de domaine d’origine, le nom du bucket et la liste des objets qu’il contient.
Fichier de domaines découverts filtrés (-rd ou –discovered-domains) : Celui-là liste un domaine par ligne. Ce sont des domaines trouvés par le crawler, le DNS ou les tests S3, mais qui ont été filtrés selon les options définies.
Fichier brut de tous les domaines découverts (-ra ou –raw-discovered-domains) : Comme son nom l’indique, c’est la liste brute de tous les domaines identifiés par FestIn, sans aucun filtre. Idéal pour du post-traitement et de l’analyse.
récupérer les résultats dans trois fichiers distincts et enchaîner avec nmap :
FestIn peut utiliser Tor pour plus de discrétion. Il faut juste avoir un proxy Tor lancé en local sur le port 9050 (configuration par défaut). Activez-le avec l’option --tor :
tor & festin --tor mon-super-site.com
Et il peut aussi effectuer des recherches DNS. Voici les options dispo :
Désactiver la découverte DNS (-dn ou –no-dnsdiscover) : Si on a pas besoin de ce type de recherche.
Serveur DNS personnalisé (-ds ou –dns-resolver) : Pratique si on veut utiliser un serveur DNS différent de celui par défaut.
Comme ceci :
festin -ds 8.8.8.8 mon-super-site.com
Ce script ne se contente pas de dénicher les buckets S3 ouverts, il peut aussi télécharger leur contenu et l’indexer dans un moteur de recherche plein texte. Ça permet ensuite de lancer des recherches directement sur le contenu des buckets ! Pour activer l’indexation, FestIn utilise Redis Search, un projet Open Source.
Il faut deux options :
Activer l’indexation (–index) : Indispensable pour que le contenu soit stocké dans le moteur de recherche.
Configuration du serveur Redis Search (–index-server) : Uniquement si votre serveur Redis Search est sur une IP/port différent de localhost:6379 par défaut.
Lancez d’abord Redis Search en tâche de fond :
docker run --rm -p 6700:6379 redislabs/redisearch:latest -d
Puis lancez FestIn avec l’indexation et le serveur distant :
Attention : l’option --index-server doit obligatoirement commencer par le préfixe redis://.
Bien sûr, on a pas forcément envie de relancer FestIn à chaque nouveau domaine à analyser. C’est pour ça qu’il existe le mode surveillance. FestIn se lance et attend l’ajout de nouveaux domaines dans un fichier qu’il surveille. Pratique pour l’utiliser avec d’autres outils comme dnsrecon.
Lancez FestIn en mode surveillance avec le fichier domaines.txt :
festin --watch -f domaines.txt
Dans un autre terminal, ajoutez des domaines à domaines.txt :
echo "encore-un-autre-site.com" >> domaines.txt
Dès qu’un nouveau domaine est ajouté au fichier, FestIn le scanne automatiquement à la recherche de buckets S3 ouverts. Pour aller plus loin, on peut combiner FestIn avec un outil de reconnaissance DNS comme DnsRecon. L’idée est de récupérer des sous-domaines potentiels liés au domaine principal et de les balancer ensuite à FestIn pour scanner d’éventuels buckets S3 cachés.
Etape 1 : Scruter le domaine cible avec DnsRecon
On va utiliser DnsRecon pour trouver des sous-domaines associés à cible.com. Sauvegardez la sortie dans un fichier CSV :
dnsrecon -d cible.com -t crt -c cible.com.csv
Etape 2 : Préparer le fichier pour FestIn
On isole les sous-domaines du fichier CSV pour les injecter dans FestIn (un domaine par ligne) :
Etape 3 : Lancer FestIn et récupérer les résultats
On balance le fichier de sous-domaines à FestIn en activant la recherche Tor, la concurrence à 5, un serveur DNS personnalisé et en sauvegardant les résultats dans des fichiers distincts :
festin -f cible.com.domaines -
Et pour automatiser tout ça sur plein de domaines à la chaîne, on a même un petit script loop.sh bien pratique dans les examples du repo GitHub.
Voilà les amis, vous avez toutes les clés pour utiliser FestIn comme un pro et aller secouer les buckets S3 qui traînent ! C’est quand même un outil hyper complet et puissant, pensez à l’utiliser avec un proxy ou Tor pour pas vous faire bloquer, et amusez vous bien mais toujours de manière éthique et responsable hein !
Les grands modèles de langage (LLM), comme le célèbre GPT-4 d’OpenAI, font des prouesses en termes de génération de texte, de code et de résolution de problèmes. Perso, je ne peux plus m’en passer, surtout quand je code. Mais ces avancées spectaculaires de l’IA pourraient avoir un côté obscur : la capacité à exploiter des vulnérabilités critiques.
C’est ce que révèle une étude de chercheurs de l’Université d’Illinois à Urbana-Champaign, qui ont collecté un ensemble de 15 vulnérabilités 0day bien réelles, certaines classées comme critiques dans la base de données CVE et le constat est sans appel. Lorsqu’on lui fournit la description CVE, GPT-4 parvient à concevoir des attaques fonctionnelles pour 87% de ces failles ! En comparaison, GPT-3.5, les modèles open source (OpenHermes-2.5-Mistral-7B, Llama-2 Chat…) et même les scanners de vulnérabilités comme ZAP ou Metasploit échouent lamentablement avec un taux de 0%.
Heureusement, sans la description CVE, les performances de GPT-4 chutent à 7% de réussite. Il est donc bien meilleur pour exploiter des failles connues que pour les débusquer lui-même. Ouf !
Mais quand même, ça fait froid dans le dos… Imaginez ce qu’on pourrait faire avec un agent IA qui serait capable de se balader sur la toile pour mener des attaques complexes de manière autonome. Accès root à des serveurs, exécution de code arbitraire à distance, exfiltration de données confidentielles… Tout devient possible et à portée de n’importe quel script kiddie un peu motivé.
Et le pire, c’est que c’est déjà rentable puisque les chercheurs estiment qu’utiliser un agent LLM pour exploiter des failles coûterait 2,8 fois moins cher que de la main-d’œuvre cyber-criminelle. Sans parler de la scalabilité de ce type d’attaques par rapport à des humains qui ont des limites.
Alors concrètement, qu’est ce qu’on peut faire contre ça ? Et bien, rien de nouveau, c’est comme d’hab, à savoir :
Patcher encore plus vite les vulnérabilités critiques, en priorité les « 0day » qui menacent les systèmes en prod
Monitorer en continu l’émergence de nouvelles vulnérabilités et signatures d’attaques
Mettre en place des mécanismes de détection et réponse aux incidents basés sur l’IA pour contrer le feu par le feu
Sensibiliser les utilisateurs aux risques et aux bonnes pratiques de « cyber-hygiène »
Repenser l’architecture de sécurité en adoptant une approche « zero trust » et en segmentant au maximum
Investir dans la recherche et le développement en cybersécurité pour garder un coup d’avance
Les fournisseurs de LLM comme OpenAI ont aussi un rôle à jouer en mettant en place des garde-fous et des mécanismes de contrôle stricts sur leurs modèles. La bonne nouvelle, c’est que les auteurs de l’étude les ont avertis et ces derniers ont demandé de ne pas rendre publics les prompts utilisés dans l’étude, au moins le temps qu’ils « corrigent » leur IA.
Voici une histoire qui va vous donner des sueurs froides dans le dos juste avant d’aller faire dodo ! Figurez-vous que Raspberry Robin, ce satané malware plus fourbe qu’un présentateur de C8, est de retour pour une nouvelle tournée de piratage en 2024 façon Taylor Swift. Les chercheurs en cybersécurité de chez HP Wolf Security ont repéré ses traces et croyez-moi, il a plus d’un tour dans son sac pour passer entre les mailles du filet !
Ce petit malin utilise des fichiers WSF (Windows Script Files) bien planqués sur différents domaines et sous-domaines pour se faufiler incognito. Et le pire, c’est qu’il arrive à berner ses victimes pour qu’elles aillent d’elles-mêmes sur ces pages web piégées. Une fois que le fichier WSF est exécuté, bim ! Il télécharge son payload principal, un DLL bien vicieux qui peut être n’importe quoi : du SocGholish, du Cobalt Strike, de l’IcedID, du BumbleBee, du TrueBot ou même du ransomware.
Mais avant de télécharger son précieux DLL, il va mener une série de reconnaissances pour vérifier s’il n’est pas en train de se faire piéger dans un environnement d’analyse ou une machine virtuelle. Et si jamais il détecte la présence d’un antivirus comme Avast, Avira, Bitdefender, Check Point, ESET ou Kaspersky, il se met direct en mode furtif et reste planqué.
Et comme si ça suffisait pas, il est même capable de bidouiller les règles d’exclusion de Microsoft Defender pour être sûr de passer entre les gouttes. C’est vraiment le Solid Snake des malwares ! Les scripts qu’il utilise ne sont même pas reconnus comme malveillants par les scanneurs sur VirusTotal, c’est dire à quel point il est balèze en infiltration.
Alors c’est sûr, avec Raspberry Robin dans la nature, faut être sur ses gardes. Ce malware est une vraie plaie depuis qu’il a été découvert en 2021. Au début, il se planquait sur des clés USB avec un fichier LNK qui pointait vers son payload hébergée sur un appareil QNAP compromis. Mais maintenant, il a évolué et il est devenu encore plus sournois.
Bref, gaffe à vous… Assurez-vous d’avoir un bon antivirus à jour, ne cliquez pas n’importe où et méfiez-vous comme de la peste des clés USB inconnues qui traînent.
Les arnaques vocales à base de deep fake comment à se démocratiser. Même les employés des boîtes de sécurité comme LastPass peuvent se faire avoir. Enfin, presque…
Car oui, récemment, un des leurs s’est fait appeler par un escroc qui imitait à la perfection la voix du big boss, Karim Toubba. Le gars a utilisé un deepfake audio assez sophistiqué pour se faire passer pour le PDG. Mais heureusement, l’employé a flairé l’entourloupe parce que le pirate a fait l’erreur d’utiliser WhatsApp pour son petit numéro de magie, ce qui n’est pas très corporate et bien vu chez Lastpass.
En plus, il mettait la pression avec une fausse urgence. Bref, tous les voyants étaient au rouge.
L’employé a donc envoyé balader l’arnaqueur et a prévenu la sécurité interne, comme ça, pas de dégâts, mais ça montre bien que ces attaques à base d’IA sont de plus en plus sophistiquées. Pour générer la voix du PDG, le pirate a sûrement dû s’entraîner sur des enregistrements publics, comme cette interview du CEO sur YouTube.
En tout cas, si vous recevez un appel de ma part, sachez que ce ne sera pas moi, car la somme d’argent que vous demandera l’escroc ne sera pas assez élevée par rapport à ce que je vous aurais demandé en vrai. Donc méfiance !
Plus sérieusement, le ministère américain de la Santé a tiré la sonnette d’alarme la semaine dernière sur ces arnaques ciblant les services d’assistance IT. Pour se protéger, ils conseillent de :
Rappeler systématiquement pour vérifier une demande de réinitialisation de mot de passe
Surveiller les changements suspects de coordonnées bancaires
Revalider tous les accès aux sites de paiement
Privilégier les demandes en personne pour les sujets sensibles
Faire valider les requêtes par un superviseur
Former les équipes support à repérer l’ingénierie sociale et vérifier l’identité des appelants
Bref, la vigilance est de mise, alors faites tourner !
Dans le monde de la cybersécurité, la découverte de failles 0day critiques est un enjeu important, car elles peuvent être exploitées par des acteurs malveillants pour compromettre des systèmes qui n’ont pas encore eu le temps d’être mis à jour.
Récemment, un chercheur en sécurité a fait une découverte plutôt alarmante : 2 failles 0day sont présentes dans les noyaux Linux 6.4 à 6.5. Cependant, cette histoire a pris une tournure inattendue… En effet, il y a quelques jours, le chercheur en sécurité, connu sous le pseudonyme YuriiCrimson, a publié sur GitHub les détails de 2 exploits pour des failles 0day qu’il avait découverts dans le pilote n_gsm des noyaux Linux.
Sauf que l’une de ces 2 failles avait en réalité déjà été divulguée par un autre chercheur, Jmpeax. D’après YuriiCrimson, celui-ci lui aurait racheté pour la publier comme si c’était sa propre découverte. Il explique sur sa page Github qu’ignorant cette divulgation, il a involontairement « re-divulgué » sa propre découverte.
Face à cette situation assez malaisante, YuriiCrimson a alors décidé de « riposter » en publiant immédiatement un second exploit, encore inconnu, affectant une plage plus large de noyaux Linux, des versions 5.15 à 6.5. Cette nouvelle divulgation un peu précipitée ayant pour but de couper l’herbe sous le pied de Jmpeax et de prouver à tout le monde que c’était bien lui, le papa de la première vuln.
Ah l’égo !
Si tout cela se confirme, ça met en lumière plusieurs problématiques. Tout d’abord, racheter le travail d’un autre chercheur pour se l’attribuer c’est très moche. Et vendre son travail pour ensuite le rendre public, c’est très moche aussi.
De plus, la divulgation non coordonnée de failles 0day peut avoir des conséquences désastreuses. En rendant publics les détails d’exploitation avant que les éditeurs n’aient pu corriger les vulnérabilités, on expose les systèmes à des attaques immédiates. Une divulgation responsable, en collaboration avec les éditeurs concernés, permet donc de laisser le temps nécessaire pour développer et déployer des correctifs, protégeant ainsi les utilisateurs.
Voilà, c’était l’histoire cybersec moche du jour, dont nous sommes maintenant tous victimes, car il y a 2 jolis 0day non encore patchés qui se baladent.
Si vous me lisez assidument, vous avez surement tout capté à la fameuse backdoor XZ découverte avec fracas la semaine dernière. Et là je viens de tomber sur un truc « rigolo » qui n’est ni plus ni moins qu’une implémentation de la technique d’exploitation de cette backdoor XZ, directement à l’intérieur d’un agent SSH.
Pour rappel, un agent SSH (comme ssh-agent) est un programme qui tourne en arrière-plan et qui garde en mémoire les clés privées déchiffrées durant votre session. Son rôle est donc de fournir ces clés aux clients SSH quand ils en ont besoin pour s’authentifier, sans que vous ayez à retaper votre phrase de passe à chaque fois.
Cet agent démoniaque s’appelle donc JiaTansSSHAgent, en hommage au cybercriminel qui a vérolé XZ, et ça implémente certaines fonctionnalités de la fameuse backdoor sshd XZ. En clair, ça vous permet de passer par cette backdoor en utilisant votre client SSH préféré.
Ce truc va donc d’abord générer sa propre clé privée ed448 avec OpenSSL puis, il faudra patcher la liblzma.so avec la clé publique ed448 correspondante. Là encore, rien de bien méchant, c’est juste un petit script Python et enfin, dernière étape, faudra patcher votre client SSH pour qu’il ignore la vérification du certificat.
Et voilà !
Une fois que vous avez fait tout ça, vous pouvez vous connecter à cœur joie avec n’importe quel mot de passe sur n’importe quel serveur qui dispose de cette faille. Bon après, faut quand même faire gaffe hein, c’est pas un truc à utiliser n’importe comment non plus. Vous devez respecter la loi, et expérimenter cela uniquement sur votre propre matériel ou avec l’autorisation de votre client si vous êtes par exemple dans le cadre d’une mission d’audit de sécurité. Tout autre utilisation vous enverra illico en prison, alors déconnez pas !
Vous n’allez pas en croire vos yeux ! Je viens de tomber sur un truc de malade qui s’appelle SharpCovertTube et qui permet de contrôler des systèmes Windows à distance en uploadant des vidéos sur Youtube. Si si, je vous jure, c’est pas une blague !
En gros, le programme surveille en permanence une chaîne Youtube jusqu’à ce qu’une nouvelle vidéo soit uploadée. Et là, attention les yeux, il décode un QR code planqué dans la miniature de la vidéo et exécute la commande cachée dedans. Franchement, les mecs qui ont pondu ça sont des génies du mal ! Ce projetc’est en fait un portage d’un autre projet vachement cool réalisé en Python en 2021 qui s’appelle covert-tube.
Le plus dingue, c’est que les QR codes dans les vidéos peuvent contenir du texte en clair ou même des valeurs chiffrées en AES. Autant vous dire que ça rigole pas niveau sécurité. Et en plus, y a même deux versions du programme : un binaire classique et un binaire qui s’installe comme un service. Ils ont vraiment pensé à tout ces petits malins.
Ah oui, j’oubliais de vous dire, y a même un script Python fourni avec pour générer les vidéos piégées. En gros, ce truc est une méthode de persistance qui utilise juste des requêtes web vers l’API Google. C’est quand même super vicieux comme technique !
Bon, je vous explique un peu comment ça marche. Déjà, faut lancer le listener sur votre système Windows. Ensuite, il va checker la chaîne Youtube toutes les 10 minutes par défaut, jusqu’à ce qu’une nouvelle vidéo soit uploadée.
Et devinez quoi ? Dès qu’il a détecté la nouvelle vidéo sur la chaîne, il décode directement le QR code planqué dans la miniature, exécute la commande et tadaaaa : la réponse a été encodée en base64 puis exfiltrée par une requête DNS. Sérieux, c’est super smart comme méthode d’exfiltration !
Ça fonctionne aussi avec des QR codes qui contiennent des payloads.
Bon après, c’est sûr, y a quelques petits trucs à configurer pour que ça marche nickel. Déjà faut renseigner son ID de chaîne Youtube et sa clé API dans un fichier de configuration. Là c’est obligatoire sinon vous pouvez aller vous brosser. Après si vous voulez utiliser le chiffrement AES pour vos QR codes, faudra aussi mettre une clé et un IV (Initialization Vector), mais c’est optionnel, on n’est pas non plus obligés d’être parano.
Autre détail qui peut être pratique : on peut choisir le délai en secondes entre chaque check de nouvelle vidéo sur la chaîne. Par défaut c’est 10 minutes, mais faut pas trop abuser non plus, sinon on va vite se prendre un gros râteau par l’API à cause du nombre de requêtes.
Plein d’autres petits paramètres sont configurable comme la journalisation dans un fichier, l’exfiltration par DNS, le nom d’hôte pour l’exfiltration, etc. Bref, c’est du solide, bien pensé. Et même si on a les droits admin, on peut installer une version « service » pour plus de discrétion. Bien vu les artistes !
Le seul petit hic, c’est qu’il faut que le binaire soit en 64 bits à cause du code utilisé pour décoder les QR codes. Mais bon, on va pas chipoter, ça reste quand même mega impressionnant comme outil.
Bref, j’espère que cet article vous aura donné envie de tester ! Perso je trouve ça fascinant ce genre de projets un peu border-line. Évidemment, n’allez pas utiliser ce genre de trucs à des fins malveillantes hein ? Mais bon, avouez que d’un point de vue techno et créativité, c’est quand même hyper cool !
Allez, la bonne journée, et la prochaine fois, essayez de mater d’un peu plus près les miniatures des vidéos Youtube, on sait jamais sur quoi vous allez tomber !
Et encore une magnifique journée dans le monde merveilleux de la cybersécurité !
Je vais vous parler aujourd’hui d’un truc plutôt sympa qui s’appelle « Indicator of Canary« . En gros, c’est une collection de proofs of concept (PoC) issue d’une recherche sur la détection des « canaris » planqués dans différents formats de fichiers.
cui-cui !
Mais attends, c’est quoi un canari ? En fait, c’est un peu comme un cheval de Troie, sauf que là, on parle de fichiers piégés avec des indicateurs de compromission (IoC) bien vicieux et des URLs de callback qui n’ont rien à faire là où elles sont. L’objectif peut-être bienveillant, à savoir détecter l’origine d’un vol de documents par exemple ou malveillant pour obtenir des informations sur une future victime.
Le but du jeu d’Indicator of Canary, c’est donc de les débusquer.
Alors ok, y a déjà des outils sur GitHub qui font des recherches par expressions régulières pour trouver les domaines en *.canarytoken.org, mais bon… C’est pas franchement l’approche la plus robuste, surtout quand on a affaire à des canaris auto-hébergés ou provenant d’autres fournisseurs. Les scripts d’Indicator of Canary, eux, mettent en rouge les trucs vraiment louches et en jaune les trucs potentiellement suspects, le tout accompagné de métadonnées pour comparer avec les autres documents de l’environnement.
Et en bonus, on a même droit à un script qui convertit les clés d’accès AWS en ID de compte. Comme ça, si vous avez accès à plusieurs clés, vous pouvez repérer les valeurs aberrantes qui ont des ID de compte bizarres. Ça peut valoir le coup de creuser un peu pour voir si c’est legit. En plus, les fournisseurs de canaris utilisent souvent le même ID de compte pour toute leur flotte, donc c’est un bon moyen de les démasquer !
Tiens, d’ailleurs, quand on parle de démasquer, ça me fait penser à un cas rigolo. Imaginez que vous bossez pour une grosse boîte et que d’un coup, vous tombez sur un fichier Excel qui a l’air normal, sauf qu’il contient une URL bizarre du genre « http://notavirus.totallylegit.biz/callback« . Là, ça pue un peu, non ? Avec le script xlsx_canary.py, hop, direct, on extrait le canari du fichier et on peut voir d’où il vient. Si ça se trouve, c’est un stagiaire qui a voulu faire une blague, ou alors c’est un vrai incident de sécurité et faut remonter ça illico à la hiérarchie !
Autre exemple : admettons que vous récupériez un dump MySQL qui traîne sur un serveur. Vous le passez à la moulinette de mysql_canary.py et paf, ça vous ressort une belle liste d’IoC et d’URLs de callback qui n’ont rien à faire dans une base de données de prod. Là, vous pouvez être sûr que quelqu’un a mis son nez où il fallait pas !
Bref, comme vous l’aurez compris, Indicator of Canary c’est top pour traquer les canaris dans une infrastruture. Que ce soit pour des fichiers .docx, .pptx, .pdf ou même des dumps MySQL, y a un script pour chaque occasion (plaisir d’offrir, tout ça, tout ça). Et le plus beau dans tout ça, c’est que ça fonctionne pour les canaris de plusieurs fournisseurs différents.
Si jamais vous voulez jeter un oeil au code, c’est par ici que ça se passe. Y a même les IoC de différents fournisseurs dans le fichier static_iocs.txt, c’est cadeau. Amusez-vous bien et restez à l’affût, on sait jamais quand un canari va se pointer !
Allez, ce matin avec Incogni on va continuer notre exploration des différents services qui récupèrent nos données à notre insu pour les revendre aux datas brokers. Il y a seulement quelques jours je vous parlais des applications Android visant spécialement nos bambins, aujourd’hui ce sont les applications de shopping. Histoire que vous sachiez de quoi il retourne d’ici les prochaines soldes.
Ces dernières années nous avons vu une explosion des applications mobiles pour l’e-commerce. Temu, Shein, Ali Express … même les grandes enseignes historiques comme Nike, The North Face & co poussent à utiliser l’app plutôt que passer par le site web classique. Je vous entends vous demander « mais pourquoi donc ? ». Si si, je l’ai entendu jusqu’ici, ne niez pas.
La réponse : car il est plus simple d’y récolter un max de données ciblées. Une app peut accéder à un tas d’informations différentes sur votre téléphone alors qu’un site web aura plus de mal. Dans son étude, le laboratoire de recherches Incogni a analysé 180 applications de shopping différentes et comme chaque fois les résultats ne sont pas glorieux. Vous êtes habitués maintenant, l’idée c’est d’extraire des infos pour ensuite les revendre et créer des profils les plus complets possibles de qui nous sommes, nos habitudes, etc.
Ce qui est intéressant c’est de voir que ces applis shopping abusent un peu moins que celles dédiées aux gamins, ou même que votre voiture intelligente. En toute logique, l’énorme majorité va stocker ce dont elle a besoin pour vous offrir le service promis : mail, adresse de livraison, numéro de téléphone, etc. Bref là rien de spécial, difficile de vous livrer un colis sans demander au moins le point de livraison. Par contre 1/4 d’entre elles (cela reste énorme) vont récolter votre galerie photo, 6-7% vos vidéos, 5% votre historique web ou la liste des applis installées et 3.3% votre orientation sexuelle ou votre liste de contacts. 22 sur 180 vont cibler précisément vos différentes localisations (dont Adidas). De plus la moitié partagent vos données directement avec des tiers (autrement dit les data brokers) et l’Europe est la seconde zone la plus touchée.
En France nous avons la chance de n’avoir quasi que de mauvais élèves, comme en politique. Les apps H&M, Hacoo (jamais entendu parler), Shein et Nike collectent à peu près tout ce qu’ils peuvent dont vos messages (pour Nike). Spéciale dédicace à ASOS, Vinted et Zalando qui non seulement récoltent un max de choses, mais en plus en revendent la moitié. Le seul bon élève ? Zara. Vous pouvez creuser la liste complète ici en fonction de votre pays de résidence.
Bref une fois encore nous sommes de bonnes vaches à lait. Pas de surprises malheureusement. Mais c’est là qu’intervient Incogni pour nous remonter un peu le moral. Grâce au service de Surfshark, il est possible de faire retirer les données que nous jugeons trop sensibles (toutes ?) des bases de données des courtiers en informations. Ce qui va couper certaines sources d’approvisionnement et fera tourner vos infos un peu moins rapidement dans les méandres du web.
Nom, prénom, adresse mail, numéro de téléphone, etc. Il suffit de dire à Incogni quoi supprimer et il va alors consulter tous les brokers qu’il connait pour leur demander de vous effacer de leurs listes. Et cela sur le long terme puisque le service va vérifier régulièrement que vous n’êtes pas rajouté par la suite (des fois que le broker aurait acheté une nouvelle base avec vous dedans). Vous pouvez aller jeter un oeil à mon test Incogni pour voir comment cela fonctionne concrètement et les résultats.
Maintenant qu’est-ce que l’on peut faire de notre côté pour limiter tout cela et agir de manière proactive ? Et bien déjà passer par la version web classique d’une boutique plutôt que via son appli. Point bonus si votre navigation est un minimum sécurisée (VPN, bloqueur de traqueur, etc.). Oui je sais, il faudra refuser l’offre promo exclusive de 3€ offerts sur votre première commande après avoir installé l’appli. Ou alors, soyons fous, tout simplement résister aux sirènes du consumérisme et arrêter d’acheter des choses inutiles en ligne. Dur.
Si vous n’êtes mentalement pas encore prêt à franchir le cap, vous pouvez déjà enclencher la solution Incogni pour moins de 95€ TTC/an. Et cela sans risques grâce à la garantie satisfait ou remboursé de 30 jours.
Vous êtes-vous déjà demandé ce que vos applications faisaient dans votre dos ? Quelles données elles envoyaient sur Internet à votre insu ? Je suis sûr que oui !
C’est pourquoi, si vous êtes soucieux de votre confidentialité et de la sécurité de vos informations, il est temps de faire connaissance avec OpenSnitch, le pare-feu interactif qui va vous permettre de mieux sécuriser et gérer les connexions sur votre ordinateur Linux.
Inspiré du célèbre Little Snitch sur macOS, OpenSnitch agit comme un garde-fou en vous alertant chaque fois qu’un programme tente d’établir une connexion sortante. Comme ça, plus besoin de laisser les applications communiquer sans votre consentement, vous avez le contrôle !
OpenSnitch utilise évidemment iptables couplé à NFQUEUE et ftrace présent par défaut dans le noyau pour détecter et alerter l’utilisateur d’un poste client Linux que quelque chose ne tourne pas rond. Top pour détecter les trucs louches comme l’exploitation d’une faille ou une fuite de données.
L’interface d’OpenSnitch est simple à prendre en main. Lorsqu’une application essaie d’accéder à Internet, une pop-up apparaît, vous donnant toutes les informations nécessaires pour prendre votre décision : le nom de l’application, l’adresse IP et le port de destination, et même le chemin de l’exécutable. Vous pouvez alors choisir d’autoriser ou de bloquer la connexion, de manière ponctuelle ou permanente.
OpenSnitch ne se contente pas de filtrer les connexions puisqu’il vous permet également de garder un œil sur l’activité réseau de votre système. Via son interface graphique, vous pourrez consulter l’historique des connexions, voir quelles applications communiquent le plus, et même exporter les données pour une analyse plus poussée.
OpenSnitch est disponible dans les dépôts de la plupart des distributions Linux, et son installation se fait en quelques commandes. Vous pouvez même l’essayer dans une machine virtuelle pour vous faire une idée avant de l’adopter sur votre système principal.
Mauvaise nouvelle ! Un chercheur en sécurité du nom de « Netsecfish » vient de dénicher une faille bien vicieuse dans les NAS D-Link. C’est pas un petit bug de rien du tout puisque c’est une backdoor (porte dérobée) qui permet carrément d’exécuter des commandes à distance sur votre NAS ! Ce qui est flippant, c’est qu’il y aurait plus de 92 000 appareils exposés sur Internet qui seraient vulnérables à cette RCE.
D’après Netsecfish, la faille se planque dans le script « /cgi-bin/nas_sharing.cgi », qui gère les requêtes HTTP GET et qui autorise un compte caché avec le nom d’utilisateur « messagebus » et un mot de passe vide. Et en plus de cette porte dérobée, il y a également une faille d’injection de commande via le paramètre « system » qui permet d’exécuter tout et n’importe quoi sur le NAS. Une vraie passoire donc !
Quand on sait que sur nos NAS, on stocke à peu près tout, de nos photos perso à nos backups, je pense que là, on peut dire que ça craint. Bien sûr, vous vous dites sûrement : « Pas de panique, D-Link va corriger ça vite fait bien fait« .
Ah ah, que vous êtes drôles vous. Bah oui, parce que les modèles concernés sont en fin de vie, obsolètes, has been (comme vos t-shirts), donc D-Link ne compte pas développer de patch. Bouuuh les affreux ! La seule solution, c’est donc remplacer votre vieux NAS par un modèle plus récent. Ouin… Cela dit, je pense que les clients D-Link passeront à la concurrence… Au hasard Synology ????
92 000 appareils exposés, ça fait une belle brochette et même si c’est du vieux matos, ça doit trainer chez pas mal de monde et d’entreprises qui doivent encore l’utiliser et qui ne seront même pas au courant de ce problème, sauf s’ils lisent mon site évidemment ^^.
Bref, si vous avez un vieux NAS D-Link qui traîne dans un coin, éteignez-moi ça vite fait. Et par pitié, ne le laissez pas exposé sur Internet, sauf si vous aimez vivre dangereusement.
Les emails HTML, c’est vraiment la plaie. Les clients mails ne les gèrent pas forcement bien et en plus, ils peuvent carrément être dangereux pour votre sécurité.
Histoire de vous expliquer ça plus clairement, on va prendre un exemple assez courant en entreprise. Votre chef reçoit un email tout a fait anodin, du style qu’il n’y a plus d’encre dans l’imprimante et vous le transfère pour que vous vous en occupiez. Vous recevez son mail, il est bien envoyé depuis la boite mail de ce dernier, et il est même signé cryptographiquement… Tout va bien. Sauf qu’une fois qu’il arrive dans votre boite mail, le contenu inoffensif disparait pour laisser place à un bon vieux mail de phishing, genre demande de changement de mot de passe sur un serveur, un certificat à installer, voire une demande de virement… On peut tout imaginer.
Cette mauvais surprise est possible grâce au CSS contenu dans les emails HTML. Ainsi, quand un mail est transféré, sa position dans le DOM change, ce qui permet d’appliquer des règles CSS spécifiques. Un petit malin peut alors planquer dedans des éléments qui n’apparaitrons que dans certaines conditions. C’est ce qu’on appelle des « kobold letters« , en référence à ces bestioles mythologiques fourbes et insaisissables.
Malheureusement, quasiment tous les clients mails qui supportent le HTML sont vulnérables à ce genre de coup fourré. Par exemple, Thunderbird se fait avoir en beauté. Il suffit de jouer avec les sélecteurs CSS en fonction de la position de l’email dans le DOM après transfert. Hop, l’attaquant planque le kobold letter avec un display: none, et quand le mail est transféré, il le fait apparaître à nouveau avec un display: block !important.
Et voilà, le piège est tendu !
<!DOCTYPE html>
<html>
<head>
<style>
.kobold-letter {
display: none;
}
.moz-text-html>div>.kobold-letter {
display: block !important;
}
</style>
</head>
<body>
<p>This text is always visible.</p>
<p class="kobold-letter">This text will only appear after forwarding.</p>
</body>
</html>
Côté Outlook en version web app (OWA), c’est un poil plus tordu vu que c’est un webmail. Mais en bricolant un peu les sélecteurs CSS en fonction des classes ajoutées par OWA, on arrive à nos fins de la même manière. Comme pour Thunderbird, le kobold letter ne se pointera alors qu’après un transfert d’email, ni vu ni connu je t’embrouille !
Gmail, quand à lui, a une parade intéressante : il vire tout le CSS quand on transfère un mail. Donc techniquement, pas de kobold letters possibles. Enfin presque… on peut quand même planquer un kobold letter en CSS, et il apparaîtra directement après transfert vu que le style sera dégagé. Par contre, impossible de faire l’inverse, càd afficher un truc dans le mail original et le planquer après transfert. C’est déjà ça de pris !
Voilà… ce genre de failles n’est pas nouveau puisque des trucs similaires ont déjà été signalés mais l’idée des kobold letters, c’est de se concentrer sur un scénario d’attaque spécifique en observant plusieurs clients mails qui pourraient laisser passer ce type de phishing.
Alors, que faire ? Bah déjà, si vous pouvez vous passer complètement des emails HTML ou les afficher dans un mode restreint, foncez ! Sinon, les clients mails pourraient faire des compromis à la Gmail comme virer le CSS au transfert. Ça casserait pas mal de trucs niveau mise en page mais ça limiterait bien les risques.
Voilà, y’a pas vraiment de remède miracle tant que les clients mail n’auront pas évolué. Donc soyez extrêmement vigilant car ce genre d’attaque de phishing ciblée n’arrive pas qu’aux autres.
Imaginez un monde où vos précieux cookies d’authentification, ces petits fichiers qui vous permettent de rester connecté à vos sites préférés, seraient à l’abri des vilains pirates informatiques. Et bien, mes chers amis geeks, ce monde est sur le point de devenir réalité grâce à notre cher Google et sa nouvelle fonctionnalité révolutionnaire pour Chrome : Device Bound Session Credentials (DBSC) !
Fini le temps où ces satanés cybercriminels pouvaient subtiliser nos cookies et prendre le contrôle de nos comptes en un clin d’œil. Avec cette nouvelle fonctionnalité qui arrive dans Chrome et qui s’appelle Device Bound Session Credentials (DBSC), vos cookies seront liés cryptographiquement à votre appareil, rendant leur vol aussi utile qu’un sabre laser sans piles.
Lors d’un processus d’authentification, une paire de clés publique/privée unique est générée en utilisant la puce TPM (Trusted Platform Module) de votre appareil. Ainsi, la clé privée reste bien au chaud dans votre machine, impossible à exfiltrer, tandis que la clé publique est partagée avec le serveur. Comme ça, même si un hacker met la main sur vos cookies, sans la clé privée associée, il ne pourra pas accéder à vos comptes.
Bien sûr, DBSC ne sera pas parfait dès le départ et les chercheurs en sécurité tenteront sûrement de trouver un moyen de contourner cette protection comme à chaque fois, mais Google est confiant.
Kristian Monsen, ingénieur de l’équipe Chrome Counter Abuse, affirme que DBSC devrait « considérablement réduire le taux de réussite des malwares voleurs de cookies« . Les attaquants seront donc obligés d’agir localement sur l’appareil, ce qui rendra la détection et le nettoyage plus efficaces. En gros, ça va leur mettre des bâtons dans les roues comme jamais !
Selon leur calendrier prévisionnel, DBSC devrait être pris en charge, fin 2024, par environ la moitié des appareils Desktop équipés de Chrome. En attendant le grand jour, vous pouvez déjà tester DBSC en allant dans chrome://flags/ et en activant le flag « enable-bound-session-credentials » sur Windows, Linux et macOS.
C’est vachement pratique de pouvoir récupérer sa chambre d’hôtel après une grosse journée, simplement en passant par le terminal qui se trouve dans l’entrée de l’hôtel. On tape son nom, on paye et paf, on récupère son numéro de chambre et le code pour y accéder. Sauf que ce que vous ignorez peut-être, c’est que ce même terminal vient potentiellement d’exposer votre code d’accès à des personnes mal intentionnées…
C’est exactement ce qui s’est passé dans un hôtel IBIS Budget à Hambourg, en Allemagne. Lors d’un congrès de hackers, la société Pentagrid a remarqué une faille de sécurité pour le moins inquiétante dans le terminal de check-in. Ainsi, en entrant une série de tirets à la place du numéro, le terminal liste toutes les réservations avec leur numéro, la date d’arrivée prévue et le prix total du séjour. Puis en sélectionnant une réservation, on accède directement au numéro de chambre et au code d’accès de la porte.
Dans l’hôtel en question, pas moins de 87 réservations étaient ainsi exposées, soit près de la moitié des 180 chambres de l’établissement !
Vous imaginez le désastre si ces codes tombaient entre de mauvaises mains ? Adieu vos effets personnels, surtout dans un hôtel bas de gamme comme celui-ci qui n’est pas équipé de coffres-forts dans les chambres. Et je vous parle pas des agressions en pleine nuit ! C’est la porte ouverte à toutes les fenêtres comme dirait l’autre.
Fort heureusement, Pentagrid a immédiatement signalé cette faille à la chaîne hôtelière Accor, propriétaire des hôtels IBIS. Le problème a depuis été corrigé, mais il aura fallu quand même plusieurs échanges et relances de la part des hackers pour que des actions soient entreprises de la part d’Accor.
Mais comment une telle faille a-t-elle pu se produire ? Et bien d’après les informations fournies par Pentagrid sur leur blog, il semblerait que le terminal de check-in ait une fonction de recherche des réservations qui nécessite uniquement le numéro de réservation pour afficher le numéro de chambre et le code d’accès. Donc c’est pas un bug, c’est une feature qui a mal tournée…
Le pire dans tout ça, c’est que de base, les numéros de réservation ne sont pas une donnée très sécurisée puisqu’on les retrouve sur toute la paperasse comme les factures…etc qui peuvent ensuite être récupérées dans une poubelle par exemple. Donc n’importe qui pourrait mettre la main dessus et accéder à votre chambre.
C’est pourquoi les auteurs de cette découverte recommandent aux hôtels de mettre en place une vérification supplémentaire pour accéder aux informations de réservation, comme un code PIN qui serait communiqué séparément au client. Les terminaux devraient aussi supprimer automatiquement les réservations dès que les informations ont été imprimées ou consultées.
En attendant, si vous séjournez dans un hôtel IBIS Budget prochainement, n’allez pas vous amuser à vérifier que la faille a été corrigée sur le terminal de check-in parce que vous ne voulez pas finir en prison pour piratage (lol).
En tout cas, sachez-le, la prochaine fois que je dors à l’IBIS, je vous attendrais de pied ferme en embuscade dans mon peignoir façon biopic DSK par Liam Neeson.
Vous en avez marre des logiciels de stéganographie qui ne tiennent pas vraiment leurs promesses en matière de sécurité et de furtivité ?
Ne cherchez plus, voici SecretPixel, un excellent outil pour planquer vos données sensibles dans des images afin de pouvoir ensuite les transmettre en toute discrétion.
Alors qu’est-ce qui fait de SecretPixel un outil si balèze comparé aux autres ? Déjà, il combine un chiffrement AES-256 de ouf pour vos données, avec une clé de session elle-même chiffrée avec RSA. Rien que ça, ça veut dire que seul le détenteur de la clé privée RSA pourra déchiffrer vos infos cachées. Niveau sécurité, on est donc au top.
Mais ce n’est pas tout ! Avant d’être chiffrées, vos données sont compressées avec zlib, ce qui réduit leur taille et minimise les schémas détectables par les outils de stéganalyse (oui c’est comme ça qu’on dit). Et pour vraiment brouiller les pistes, SecretPixel utilise un générateur de nombres pseudo-aléatoires pour déterminer les pixels qui vont accueillir vos bits cachés. Vos données sont ainsi éparpillées dans toute l’image, rendant leur détection quasi impossible, même avec des outils comme zsteg.
Le processus de chiffrement garantit que les données cachées restent confidentielles, tandis que la compression et la distribution aléatoire des données rendent extrêmement difficile pour les outils de stéganalyse de détecter la présence d’informations intégrées. L’utilisation d’un générateur de nombres aléatoires avec amorçage ajoute une couche de sécurité supplémentaire, car le schéma des données intégrées ne peut pas être prédit sans connaître l’amorce.
En prime, SecretPixel stocke aussi le nom original de votre fichier caché dans l’image. Comme ça, quand vous l’extrairez, il aura toujours son petit nom. Pratique non ?
Et vu qu’il est écrit en Python, vous pouvez l’utiliser sur n’importe quel système, tant que vous avez Python d’installé.
SecretPixel est conçu pour fonctionner avec une variété de formats de fichiers image : PNG, BMP, TGA et TIFF. Il est important de noter que le format d’image hôte choisi peut avoir un impact sur l’efficacité du processus de stéganographie. Les formats sans perte comme PNG et TIFF sont préférables pour garantir qu’aucune donnée n’est perdue pendant le processus d’intégration.
Maintenant, pour mettre la main sur ce petit bijou, rien de plus simple. Clonez le dépôt GitHub ou téléchargez le code source. Assurez-vous d’avoir Python 3 et les packages requis, et c’est parti !
git clone https://github.com/x011/SecretPixel.git
cd SecretPixel
pip install -r requirements.txt
Avant de jouer à cache-cache avec vos données, vous allez avoir besoin d’une paire de clés RSA – une clé privée et une clé publique. Pas de panique, les dev ont pensé à tout avec un script Python pour vous faciliter la tâche. Lancez donc generate_keys.py qui va vous générer une paire de clés RSA de 4096 bits en un clin d’oeil.
python generate_keys.py
Choisissez une phrase de passe bien corsée pour votre clé privée. Elle sera chiffrée avec AES-256 pour une protection maximale. Une fois le script terminé, vous aurez deux fichiers tout beaux tout chauds : myprivatekey.pem (votre clé privée chiffrée) et mypublickey.pem (votre clé publique, à partager sans modération).
Maintenant, passons aux choses sérieuses. Pour planquer un fichier dans une image, lancez cette commande :
Avant d’intégrer des données, l’image hôte ne doit pas contenir de contenu stéganographique antérieur ou de métadonnées sensibles qui pourraient entrer en conflit avec les nouvelles données ou révéler leur présence. En sélectionnant et en préparant soigneusement l’image hôte, vous améliorerez considérablement la sécurité et l’indétectabilité des données intégrées dans l’image.
De plus, l’image hôte servant de support pour les données cachées, afin de maintenir l’intégrité du processus de stéganographie et éviter la détection, il est crucial que l’image hôte soit suffisamment grande pour accueillir le fichier caché. En règle générale, l’image hôte doit avoir une capacité (en octets) au moins trois fois supérieure à la taille du fichier à cacher pour garantir que les modifications sont subtiles et largement dispersées.
Et hop, votre secret.txt est incrusté incognito dans host.png en utilisant votre clé publique mypublickey.pem. L’image résultante output.png a l’air innocente, mais elle cache bien son jeu !
Pour exfiltrer votre fichier caché d’une image, c’est tout aussi simple :
Votre fichier caché ressort de carrier.png grâce à votre clé privée myprivate.pem. Si vous ne fournissez pas de nom de fichier pour le .txt se sortie (extracted.txt), l’outil utilisera le nom du fichier qu’il aura conservé.
Aïe aïe aïe, ça sent le roussi ! Une vilaine backdoor a été dénichée dans l’utilitaire xz Utils, un outil de compression présent dans un paquet de distributions Linux. Et attention, c’est du lourd : cette saloperie est capable de contourner l’authentification SSH et donc de permettre un accès non autorisé aux systèmes. Autant vous dire que c’est la panique générale !
La faille a été découverte le 29 mars 2024 par un dénommé Andres Freund, un développeur qui a flairé l’embrouille dans les versions 5.6.0 et 5.6.1 de xz Utils dont la liblzma. La backdoor se planque dans les fichiers de test bad-3-corrupt_lzma2.xz et good-large_compressed.lzma, et utilise un script appelé par build-to-host.m4 pour s’incruster dans le processus de build. Cerise sur le gâteau, elle exploite le mécanisme IFUNC de la glibc pour détourner l’authentification d’OpenSSH à l’exécution. Machiavélique !
En fait, le code malveillant ne se trouve pas directement dans le dépôt mais uniquement dans les archives de release 5.6.0 et 5.6.1. Un examen du code source ne révèle donc rien de suspect, il faut télécharger les tarballs pour chopper la version vérolée. Vicieux !
Mais le plus dingue dans l’histoire, c’est que cette backdoor a été commitée par un certain JiaT75, aka Jia Tan, l’un des deux principaux développeurs de xz Utils, qui bosse sur le projet depuis 2022 ! En fait, ce type a commencé par introduire une vulnérabilité dans libarchive en 2021 avant de s’attaquer à xz.
Quand des problèmes sont apparus avec Valgrind sur la liblzma juste après la release 5.6.0 en février, ce cher Jia Tan a suggéré qu’il s’agissait d’un bug de GCC. Il a même poussé un commit bidouillant le code pour contourner les erreurs Valgrind, en pointant vers un rapport de bug GCC n’ayant rien à voir. À ce stade, il n’y a plus de doute possible : le compte JiaT75 est contrôlé par un acteur malveillant, point barre. Reste à savoir si Jia Tan a toujours été un méchant ou si son compte a été compromis.
Depuis son entrée en scène, JiaT75 n’a pas chômé. Infrastructure de test vérolée, prise de contrôle progressive du projet, jusqu’à tenter de refiler la version backdoorée à Debian, Fedora et Ubuntu. Et dire que GitHub a attendu le dernier moment pour lui mettre le grappin dessus et bloquer l’accès au dépôt, bien joué les gars. Heureusement qu’Andres veillait au grain, sinon on n’imagine même pas le bordel.
Parce que oui, ces versions 5.6.0 et 5.6.1 ont failli se faufiler dans les releases stables des principales distribs. Par chance, elles ne se sont glissées que dans quelques bêtas, notamment Fedora 40, Fedora Rawhide et les distribs testing, unstable et experimental de Debian. Même Arch Linux y a eu droit dans une release stable. Bref, ça a failli faire très mal !
Comme le souligne Will Dormann, un analyste en sécu chez Analygence, si la backdoor n’avait pas été repérée à temps, ça aurait pu être une véritable hécatombe. Les systèmes les plus à risque sont ceux qui tournent avec glibc et xz 5.6.0 ou 5.6.1, surtout s’ils exposent un serveur SSH public. Là c’est défcon 1, faut mettre à jour TOUT DE SUITE MAINTENANT ! Pour les autres, pas de panique, mais mieux vaut jouer la prudence et updater fissa. Plus d’infos sur les systèmes touchés et comment les patcher dans cet article.
Mais qu’est-ce que SSH vient faire dans cette galère ? En fait, beaucoup de distribs Linux patchent sshd pour ajouter des fonctionnalités systemd, et libsystemd utilise la liblzma. Résultat, le code d’initialisation de liblzma est exécuté au démarrage de sshd. Et devinez quoi ? La backdoor vérifie si le programme lancé est /usr/bin/sshd et remplace des fonctions comme RSA_public_decrypt, utilisée pour valider les clés SSH. On vous laisse imaginer la suite… Une analyse complète est en cours, attendez-vous à d’autres révélations dans les prochains jours.
Depuis, c’est le branle-bas de combat. Les mainteneurs de Fedora et Debian se sont empressés de retirer les versions vérolées et de revenir à une release clean de xz Utils. Et les utilisateurs sont appelés à vérifier s’ils sont affectés en utilisant un script de détection mis à dispo par Andres himself. Mais le mal est fait et la confiance est ébranlée.
L’avenir du projet xz est incertain et il faut s’attendre à un ou plusieurs hard forks et à un gros nettoyage. Pour plus d’infos, jetez un œil aux alertes de sécurité de Redhat et Debian, ainsi qu’au thread oss-security sur le sujet.
Cet épisode rappelle cruellement qu’en matière de sécurité, la vigilance est mère de sûreté, même au sein des projets open source. Il met aussi en lumière la fragilité de notre écosystème, où des pans entiers reposent sur les épaules fatiguées de quelques mainteneurs débordés. Il est grand temps d’avoir une prise de conscience collective et de mieux soutenir ces projets critiques. Parce que mine de rien, on parle quand même des fondations qui font tourner une bonne partie d’Internet et des infrastructures critiques.
Des petits malins ont eu l’idée de distribuer des logiciels de triche pour Call of Duty et d’autres jeux sur Battle.net. Sauf que… surprise ! En réalité, ces soi-disant « cheats » étaient bourrés de malwares qui aspirent les Bitcoins des joueurs ! Un coup de maître digne d’un scénario de Mr Robot.
D’après les experts en cybersécurité de VX Underground, cette attaque d’hameçonnage ciblée aurait potentiellement compromis près de 5 millions de comptes, rien que ça ! Une fois installé sur l’ordi de la victime, le malware s’attaque direct au portefeuille Bitcoin Electrum pour siphonner les précieuses crypto. On parle de presque 3,7 millions de comptes Battle.net, plus de 560 000 comptes Activision et environ 117 000 comptes ElitePVPers. Autant dire que les cybercriminels se sont fait plaisir.
Bon, Activision affirme que ses serveurs n’ont pas été directement compromis. Mais quand même, ça la fout mal. La boîte conseille à tous les joueurs qui auraient pu cliquer sur un lien louche de changer rapidement leur mot de passe et d’activer l’authentification à deux facteurs ce qui est un minimum.
Bref, méfiez-vous comme de la peste des logiciels de triche. Comme dirait l’autre, si c’est trop beau pour être vrai, c’est que ça cache sûrement une entourloupe !
Puis où est passé le plaisir de jouer à la loyale, de progresser à la sueur de son front et de laminer ses adversaires à la régulière ?
Connexion
