rPGP c’est un bibliothèque Rust qui va vous permettre de jouer avec OpenPGP comme des grands ! Plus besoin de vous taper des kilomètres de C pour avoir un bout de code qui chiffre trois mails bourrés de fautes. Maintenant, on a le droit à une implémentation 100% Rust, avec une API minimaliste mais qui fait le taf. Et en plus, c’est sous licence libre, donc on peut en faire ce qu’on veut !

Le top du top, c’est que rPGP gère tout ce qu’il faut pour être compatible avec Autocrypt 1.1. Si vous ne connaissez pas, c’est une spécification pour chiffrer les mails qui est censée être facile à utiliser pour monsieur et madame tout-le-monde.

Côté technique, rPGP est mis à jour régulièrement en tant que crate pgp (oui, ils ont pensé à nous, les flemmards qui ne veulent pas taper plus de trois lettres). Et pour la partie RSA, ça vit tranquillou sous le parapluie collectif RustCrypto. Et pour les petits malins qui voudraient se la jouer elliptique, pas de panique : le support ECC est assuré par la crate Curve25519-dalek. J’adore le nom 🙂

Bon, après, faut avouer que la doc de l’API est encore un peu légère mais si vraiment vous séchez, vous pouvez toujours ouvrir une issue sur GitHub. Les devs sont sympas, ils répondent (des fois).

D’ailleurs, rPGP s’est payé un petit audit de sécurité indépendant en 2019, réalisé par les gars d’IncludeSecurity et pas de failles critiques ! Bon, quelques trucs à corriger par ci par là, mais globalement, c’est du solide. Si vous voulez jeter un œil au rapport, c’est par ici.

Notez que rPGP est utilisé en prod par Delta Chat, l’app de messagerie basée sur les mails et ça tourne nickel sur Windows, Linux, macOS, Android et iOS, en 32 et 64 bits. Que demande le peuple ?

Et si vous êtes du genre à tout vouloir faire tourner dans votre navigateur (ou dans Node.js, on ne juge pas), rPGP a même pensé à vous avec une feature wasm ! Par contre, les bindings sont encore expérimentaux, mais tout se trouve dans le repo rpgp/rpgp-js.

Allez, je vous laisse, j’ai des messages secrets à chiffrer moi !

Vous en avez marre de galérer avec la configuration de VPN pour sécuriser votre navigation web et vous cherchez une solution simple et efficace pour protéger votre vie privée en ligne sans vous prendre la tête ?

Avez vous pensé à WireProxy ?

Ce petit logiciel open-source est un client qui se présente sous la forme d’un proxy SOCKS5 ou HTTP et qui permet de se connecter à un serveur WireGuard et d’exposer un proxy sur votre machine. Ça peut être super pratique si vous avez besoin d’accéder à certains sites via VPN mais que vous n’avez pas envie de vous embêter à configurer une nouvelle interface réseau. Une fois que c’est en place chez vous, y’a plus qu’à configurer votre navigateur pour qu’il passe par le proxy. Et pas besoin des droits root pour le configurer.

En plus de ça, y’a tout un tas de fonctionnalités bien cool :

• Routage statique TCP pour le client et le serveur
• Proxy SOCKS5/HTTP (pour l’instant seul CONNECT est supporté)
• Support de l’UDP dans SOCKS5
• Routage statique UDP

Alors pour l’installer :

1. Clonez le dépôt GitHub : git clone https://github.com/pufferffish/wireproxy
2. Allez dans le répertoire : cd wireproxy
3. Compilez le projet : make
4. Puis lancez WireProxy avec votre fichier de config (les détails sont sur Github) :
   ./wireproxy -c chemin/vers/config.conf

Le fichier de configuration utilise une syntaxe similaire à celle de WireGuard, donc si vous êtes déjà familier avec WireGuard, vous ne serez pas dépaysé.

Vous pouvez y définir l’interface et le ou les serveurs (les pairs), mais aussi configurer des tunnels TCP et UDP ainsi que le proxy SOCKS5 ou HTTP. L’outil supporte même l’authentification pour le proxy, il suffit de préciser un nom d’utilisateur et un mot de passe dans la section [Socks5] ou [http].

Et voilà, vous êtes prêt à surfer en toute sécurité !

Autre point fort de WireProxy : il supporte la connexion à plusieurs pairs ! Il suffit de spécifier les AllowedIPs pour chaque pair pour qu’il sache vers quel pairs rediriger le trafic. Et si vous voulez que les pairs puissent se connecter à votre instance WireProxy, c’est possible aussi en précisant le port d’écoute avec ListenPort.

Amusez vous bien !

Vous cherchez un moyen simple et efficace de sécuriser vos fichiers ?

Ça tombe bien, je vous ai déniché un petit outil bien pratique nommé File-Encryptor qui est un programme développé en Rust vous permettant de chiffrer et déchiffrer vos fichiers en un clin d’œil.

Ce programme utilise l’algorithme de chiffrement AES-GCM (Advanced Encryption Standard-Galois/Counter Mode), connu pour être très robuste, avec une clé de 256 bits. Le gros avantage de File-Encryptor, c’est qu’il supporte le chiffrement basé sur un mot de passe. Comme ça, pas besoin de vous trimballer une clé USB avec votre précieuse clé de chiffrement. Il vous suffit de choisir une phrase secrète, et hop, vos fichiers sont chiffrés en un rien de temps. Et si vous voulez rajouter une couche de sécurité supplémentaire, vous pouvez même ajouter des données d’authentification en bonus (comme votre mail par exemple).

Bref, si vous avez des documents sensibles à envoyer par email ou via une clé USB ou si vous voulez faire une sauvegarde bien sécurisée de vos précieux fichiers sur un cloud ou un disque dur externe, et bien un petit tour avec notre ami File-Encryptor et vous pouvez dormir sur vos deux oreilles.

Allez, assez parlé, je vous fais une petite démo pour que vous compreniez comment ça marche.

Première étape : générer une clé de chiffrement.

Ouvrez un terminal et tapez :

file-encryptor keygen > mykey.key

Vous pouvez aussi utiliser l’option -p ou --password pour générer une clé à partir d’un mot de passe de votre choix. Par exemple :

file-encryptor keygen -p "motdepasse123" > mykey.key

Notez bien que la clé AES256 générée est obtenue en hashant votre mot de passe avec l’algorithme SHA256. Bon à savoir !

Maintenant, passons au chiffrement proprement dit. Mettons que vous ayez un fichier texte nommé « secret.txt » à chiffrer. Rien de plus simple :

file-encryptor seal secret.txt < mykey.key > secret.encrypted

Et si vous voulez ajouter des données d’authentification, rajoutez l’option -a suivie d’une chaîne de caractères. Par exemple votre email :

file-encryptor seal secret.txt -a "james@bond.mi6" < mykey.key > secret.encrypted

Pour déchiffrer votre fichier, c’est tout aussi facile. Il vous suffit de taper :

file-encryptor open secret.encrypted < mykey.key > secret.decrypted.txt

Et n’oubliez pas de préciser les données d’authentification si vous en aviez utilisé lors du chiffrement :

file-encryptor open secret.encrypted -a "james@bond.mi6" < mykey.key > secret.decrypted.txt

Et voilà, le tour est joué ! Vous savez désormais comment chiffrer et déchiffrer des fichiers comme un pro avec File-Encryptor. Franchement, c’est pas sorcier et ça peut dépanner dans un tas de situations.

Cliquez ici pour mettre la main sur ce petit outil bien pratique. Et n’oubliez pas : la paranoïa est votre meilleure amie dans ce monde de brute (force) !

Vous en avez ras le bol que vos données personnelles se baladent à poil sur Internet, scrutées par les GAFAM et aspirées par la NSA ?

Alors PrivateBin est fait pour vous ! Cette alternative open source et respectueuse de la vie privée à Pastebin permet de partager du texte et des fichiers de façon ultra sécurisée. Lors de la création d’un paste, le contenu est chiffré directement dans votre navigateur en utilisant AES-256 et même les petits gars de PrivateBin ne peuvent pas mettre leur nez dans vos affaires. C’est ça qu’on appelle le « zero knowledge« , mes amis !

La clé de chiffrement est générée à partir du contenu lui-même et n’est jamais transmise au serveur. Seul le contenu chiffré est stocké. Ainsi, lorsqu’un utilisateur souhaite accéder au paste, il récupère le contenu chiffré et le déchiffre dans son navigateur.

Et l’outil ne fait pas les choses à moitié question sécurité. Il embarque des fonctionnalités de ouf comme le chiffrement des discussions, la protection par mot de passe, des options d’expiration du contenu, et même la possibilité de « burn after reading« . Côté utilisateur, rien de plus simple. Une interface toute bête, tu colles ton texte ou tes fichiers, tu personnalises les options de sécurité et de confidentialité, et bam, t’as un lien à partager. On peut même faire son 007 en scannant un QR code pour transférer direct le lien sur notre smartphone.

De plus, PrivateBin s’installe en deux coups de cuillère à pot grâce à son script d’installation et sa configuration sécurisée par défaut. Pas besoin de sortir de Saint-Cyr pour mettre en place son propre serveur privé et si vous êtes encore plus parano, vous pouvez même l’installer sur un serveur onion (Tor).

D’un point de vue plus technique, c’est écrit en PHP mais pas de panique, les développeurs ont optimisé le bouzin pour le rendre plus rapide et efficace. Ils ont même intégré un système de cache pour améliorer les performances. Et grâce à l’utilisation de bibliothèques éprouvées comme GnuPG pour le chiffrement et Twig pour le templating, le code est propre et maintenable.

Les pastes sont automatiquement supprimés après 30 jours par défaut (mais vous pouvez choisir une durée plus courte) et pour l’utiliser au mieux, il y a même un client CLI (en ligne de commande), qui vous permettra de créer et récupérer de la donnée via PrivateBin sans quitter votre terminal.

Alors, prêt à tester PrivateBin ?

Cryptr, c’est un script bash bien pratique qui va vous permettre de chiffrer et déchiffrer vos fichiers sensibles en deux temps trois mouvements, le tout proprement et avec une sécurité au top grâce à OpenSSL AES-256.

Si comme moi, vous avez tendance à stocker tout un tas de données confidentielles sur votre ordi (mots de passe, documents perso, photos compromettantes de votre dernière soirée déguisée…), vous savez à quel point c’est important de les protéger des regards indiscrets. Bon ok, on n’est pas tous paranos au point d’avoir peur que la NSA ou Gérald vienne fouiller dans nos fichiers, mais on n’est jamais trop prudent !

Avec ce truc, fini de vous prendre la tête avec des solutions de chiffrement compliquées à mettre en place. Il vous suffit de cloner le projet depuis le dépôt GitHub :

git clone https://github.com/nodesocket/cryptr.git

Ensuite, créez un lien symbolique vers le script cryptr.bash pour pouvoir l’utiliser facilement depuis n’importe où :

ln -s "$PWD"/cryptr/cryptr.bash /usr/local/bin/cryptr

Et voilà, vous êtes parés pour chiffrer vos petits secrets comme un pro ! La commande encrypt vous permet de chiffrer un fichier en lui ajoutant l’extension .aes, tandis que decrypt fait l’opération inverse.

➜ cryptr encrypt ./secret-file
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
➜ ls -alh
-rw-r--r-- 1 user group 1.0G Oct 1 13:33 secret-file
-rw-r--r-- 1 user group 1.0G Oct 1 13:34 secret-file.aes

Vous pouvez même définir le mot de passe à utiliser via la variable d’environnement CRYPTR_PASSWORD pour automatiser le processus :

➜ CRYPTR_PASSWORD=motdepasse007 cryptr encrypt ./secret-file

Franchement, c’est tellement simple et efficace que même James Bond Raymonde peut en faire son outil préféré. Bref, si vous cherchez une solution de chiffrement simple et efficace pour protéger vos données sensibles, je vous recommande vraiment de tester Cryptr.

2FAGuard est une application moderne, gratuite et open source qui va vous permettre de centraliser et bien gérer vos codes de double authentification pour ensuite y accéder en un clin d’œil.

Comme ça, vous importez vos tokens 2FA existants depuis d’autres applis (Google Authenticator, Bitwarden et Authenticator Pro) en deux temps trois mouvements et c’est immédiatement utilisable. Vous pouvez même ajouter de nouveaux codes simplement en scannant le QR Code qu’un site vous donner. Et si vous êtes du genre parano (et vous avez bien raison), vous pouvez aussi exporter vos données quand vous voulez pour les mettre à l’abri ailleurs.

Côté sécurité, les gars derrière 2FAGuard n’ont pas fait les choses à moitié puisque les données sont chiffrées en AEGIS-256 et restent bien au chaud sur votre appareil. Et cerise sur le gâteau, l’appli est compatible avec Windows Hello comme ça vous pouvez vous authentifiez avec votre empreinte digitale, votre visage ou une clé de sécurité..

Comme vous le voyez, l’interface de 2FAGuard est plutôt minimaliste, mais c’est voulu. On a accès rapidement à tout ce dont on a besoin : la liste de nos tokens, un bouton pour en ajouter de nouveaux, un autre pour les paramètres, et c’est tout. Simple et efficace. Sachez également que vous pouvez choisir de verrouiller l’appli au démarrage ou après une certaine période d’inactivité. Vous pouvez même activer un mode « incognito » qui masque les codes à l’écran. Pratique si vous utilisez votre PC dans des lieux publics.

Côté téléchargement, vous avez le choix entre deux versions : une app Windows 10 / 11 du Microsoft Store qui se met à jour automatiquement en arrière-plan, et une version classique « desktop » qui a l’avantage d’être portable, pratique pour l’utiliser depuis une clé USB.

A découvrir ici.

ps : Et si vous n’utilisez pas de code 2FA pour vos comptes en ligne, vous feriez mieux de vous y mettre.

OpenCanary, c’est le pot de miel nouvelle génération pour attraper tous ces satanés cybercriminels. Ce petit logiciel va simuler plein de services réseau, comme un serveur web, un partage Windows, un serveur SSH…etc Bref, un vrai buffet à appâts numériques et dès qu’un hacker tombe dans le panneau et interagit avec, paf, vous recevez une alerte !

L’outil est hyper léger et s’installe facilement, même sur un Raspberry Pi ou un VM. Et comme c’est du logiciel libre, vous pouvez l’adapter à vos besoins et surtout vous éviter une solution proprio payante.

Alors comment ça fonctionne ? Et bien c’est simple comme bonjour :

• Vous installez OpenCanary sur une machine de votre réseau interne
• Vous le configurez pour imiter les services qui vous bottent (serveur web, FTP, base de données…)
• Vous attendez patiemment qu’un hacker morde à l’hameçon
• Dès qu’il interagit avec le honeypot, vous recevez une belle alerte qui vous file son IP et plein d’infos sur l’intrusion

C’est pas beau ça ?

En plus, vous pouvez même envoyer les alertes par mail, SMS ou même les agréger dans un outil de monitoring. Bon, je vous cache pas qu’il faut quand même un minimum de connaissances techniques pour faire tourner le bouzin. Mais si vous n’avez pas peur de mettre les mains dans le cambouis et de jouer avec la ligne de commande, c’est à la portée de n’importe quel barbu un peu motivé.

Et puis c’est quand même super fun de tendre des pièges aux méchants hackers et de les voir se faire avoir comme des bleus. Mais attention hein, faut pas non plus tomber dans la paranoïa et transformer son réseau en véritable champ de mines. Faudra doser pour que ça reste digeste sinon, vous allez avoir beaucoup de bruit dans vos alertes.

En tout cas, moi je dis bravo aux petits gars de Thinkst qui nous ont pondu cet outil. Pour les plus motivés, voici le lien Github du projet : https://github.com/thinkst/opencanary.

Amusez-vous bien et happy hacking !

Tracecat est une nouvelle plateforme d’automatisation open source qui propose une alternative à des solutions propriétaires genre Tines ou Splunk SOAR !

Avec cet outil libre et gratuit, vous pourrez créer des workflows d’automatisation complexes, gérer vos incidents comme un chef et garder un œil sur tous vos logs. Tracecat est basé sur des technos open source robustes comme Apache Flink pour l’orchestration et Quickwit pour le stockage des logs et ça a surtout été conçu par des pro de la sécu, qui en ont eu marre de se taper des usines à gaz hors de prix et pas adaptées à leurs besoins. Du coup, ils ont développé leur propre outil, simple mais puissant, avec une UX aux petits oignons pour que même votre grand-mère puisse automatiser la chasse aux menaces. Bon ok, j’exagère un peu, mamie est plutôt experte en chasse aux mauvaises herbes…

Trêve de plaisanterie, si vous voulez voir Tracecat en action, je vous invite à tester ce tutoriel. Vous apprendrez à automatiser une investigation d’email de phishing en un clin d’œil, en extrayant les URLs avec ChatGPT, en analysant leur réputation, en labellisant le niveau de menace, et en générant un joli rapport dans un cas.

Autre bon point (parce que je sais que vous aimez ça) : Tracecat est entièrement auto hébergeable. Vous pouvez l’installer en local sur votre laptop, dans le cloud ou dans un datacenter, bref où vous voulez. Vous gardez ainsi le contrôle total de vos données et de votre infra. Et si un jour vous avez besoin de plus de puissance, pas de panique, l’éditeur propose une version distribuée payante qui scale à l’infini et au-delà.

Alors oui, Tracecat n’est pas (encore) un SIEM à part entière. Mais justement, c’est sa force ! Il se concentre sur l’automatisation et l’orchestration, ce qui lui permet d’être beaucoup plus flexible et facile à intégrer, que vous ayez un SIEM, plusieurs, ou même aucun. C’est vous qui voyez !

Bref, si vous en avez marre de vous coltiner des tâches répétitives et de courir après les incidents dans tous les sens, je vous conseille vraiment de creuser Tracecat.

Reko est une boîte à outils complète qui va vous permettre de décortiquer les binaires et de les traduire en langages de plus haut niveau, que vous soyez sur Windows, Linux ou Mac (c’est codé en .NET).

Ses développeurs ont pensé à tout puisque vous avez le choix entre une interface graphique super intuitive pour les novices, et une interface en ligne de commande pour les pros du terminal qui aiment se la jouer old school.

Reko embarque aussi une bibliothèque qui gère un tas d’architectures processeur (x86, 68k, PowerPC, ARM, MIPS, Z80…), de formats de fichiers binaires (MZ, ELF, AmigaOS Hunk, Classic MacOS…) et de systèmes d’exploitation. Il peut même lancer automatiquement des scripts de décompression écrits en OllyScript.

Génial pour comprendre comment fonctionne un programme et faire un peu de reverse engineering pour se détendre.

A découvrir ici.

Les ransomwares, ces programmes nuisibles qui prennent vos précieux fichiers en otage contre une rançon, font trembler pas mal de monde, même les plus expérimentés. Mais c’était sans compter sur RansomLord qui pourrait peut-être bien vous sauver la mise si vous avez été infecté.

Cet outil open source, conçu par John Page (alias hyp3rlinx), a pour mission de mettre des bâtons dans les roues des cybercriminels en exploitant les failles de sécurité présentes dans le code de ces virus modernes. Et on parle quand même de ransomwares assez balaises comme Conti, REvil ou LockBit, mais aussi de nouveaux venus comme StopCrypt, RisePro, RuRansom, MoneyMessage, CryptoFortress et Onyx.

Pour réussir cet exploit (sans mauvais jeu de mot), RansomLord génère des fichiers « DLL » qui se font passer pour des fichiers légitimes dont les rançongiciels ont besoin. En réalité, ces DLL sont remplis de code malicieux qui court-circuite le processus de chiffrement et met fin à la carrière du malware avant même qu’il n’ait pu crier « Bitcoin » !

Le plus impressionnant, c’est que RansomLord est capable de cibler spécifiquement les rançongiciels qui menacent votre entreprise ou votre secteur d’activité grâce à sa base de données de plus de 49 familles de ransomwares. Comme ça, il vous concocte le DLL parfait pour mettre hors d’état de nuire ces logiciels du démon.

Cette dernière version 3 de RansomLord intègre également une fonction de journalisation qui enregistre le hash SHA256 et le chemin d’accès complet du malware intercepté. Comme ça, vous pouvez garder une trace de l’attaque et communiquer ces détails à des experts cyber qui viendraient mener l’enquête ensuite.

Respect à hyp3rlinx pour cette trouvaille ingénieuse ! Et pour télécharger RansomLord v3 c’est par ici.

Source

Mauvaise nouvelle, les derniers modèles de Tesla ne sont pas épargnés par les voleurs.

Comment ça ? Et bien ces derniers utilisent une technique d’attaque relais pour duper votre voiture en captant le signal de votre clé ou de votre smartphone (si vous utilisez l’app Tesla) et cela même si vous êtes à des dizaines de mètres. Ensuite, ils relaient ce signal jusqu’à votre caisse garée gentiment devant chez vous et là, surprise, la voiture croit que vous êtes à côté avec la clé et hop, elle se déverrouille en moins de deux.

Alors ce genre d’attaques, c’est pas nouveau et la techno Ultra-Wideband, ça devait justement empêcher ça… Mais c’était sans compter sur les chercheurs chinois de GoGoByte ont réussi à pirater une Tesla Model 3 flambant neuve avec du matos radio à moins de 100 balles. Ils ont ainsi pu déverrouiller la voiture et même la démarrer en quelques secondes, et ce jusqu’à une distance de 5 mètres. Une démo de l’attaque est visible en vidéo dans l’article de Wired.

Pourtant, Tesla avait vanté les mérites de l’Ultra-Wideband, censée empêcher ces attaques relais grâce à une mesure ultra-précise de la distance entre la clé et la voiture, mais visiblement, c’est pas encore au point… Et quand les chercheurs ont signalé la faille, Tesla leur a répondu un truc du genre « Ouais, on bosse encore dessus pour améliorer la fiabilité. Pour l’instant c’est normal que ça marche pas« . C’est pas sérieux.

La seule parade pour vous protéger de ça, c’est soit d’avoir une caisse pourrie que personne ne veut voler, soit c’est d’activer le code PIN (désactivé par défaut) pour autoriser le démarrage. Pour l’activer, appuyez sur « Contrôles » > « Sécurité » > « Code PIN pour la conduite ». Vous serez alors invité à créer votre code de vérification à 4 chiffres. Validez, et ne l’oubliez pas !

Bien sûr, Tesla n’est pas le seul constructeur à s’être planté car d’autres marques ont également adopté l’Ultra-Wideband et sont donc tout aussi vulnérables aux attaques relais. Après faut pas oublier que grâce GPS intégré, les Tesla sont statistiquement moins volées que les autres bagnoles même si certains réseaux mafieux les ciblent quand même pour les pièces détachées.

En attendant, soyez vigilants, et le soir, emmenez votre clé le plus loin possible de votre véhicule au lieu de les laisser trainer dans l’entrée de la maison. Vous pouvez même opter pour une petite boite qui fera office de cage de faraday (lien affilié), histoire de bloquer les ondes de la clé.

Source

La bibliothèque JavaScript de visualisation de PDF développée par Mozilla, connue sous le nom de PDF.js, est au centre d’une nouvelle découverte de sécurité assez préoccupante ! Une faille dans le code de rendu des polices permet à un attaquant d’exécuter du JavaScript arbitraire simplement en ouvrant un PDF malveillant. Et attention, cela affecte toutes les applications utilisant PDF.js, y compris Firefox, certains éditeurs de code et navigateurs de fichiers. Aïe aïe aïe !

En gros, lorsque PDF.js affiche une police spéciale, il convertit la description des glyphes en instructions pour dessiner ces glyphes. Cependant, un hacker mal intentionné peut injecter son propre code dans la description de la police, résultant en l’exécution de ce code par le navigateur.

La vulnérabilité, estampillée CVE-2024-4367, repose donc sur une manipulation des commandes de rendu de polices. La commande transform utilisant fontMatrix est exploitée pour insérer du code JavaScript puis PDF.js compile dynamiquement les descriptions de polices pour optimiser les performances. Normalement, ce tableau contient uniquement des nombres, toutefois, cette faille permet d’y injecter des chaînes de caractères. Et en insérant du code JavaScript dans ce tableau, il est possible de déclencher du code lors du rendu d’une police.

Un exploit bien forgé permettrait diverses attaques telles que l’exécution de code arbitraire, le vol de données, ou même la prise de contrôle complète du système via des attaques XSS ou l’exécution de code natif. La vulnérabilité touche actuellement les versions de PDF.js inférieures à 4.2.67.

Selon les chercheurs de Codean Labs, cette vulnérabilité affecte non seulement les utilisateurs de Firefox (<126), mais également de nombreuses applications web et basées sur Electron utilisant indirectement PDF.js pour la fonctionnalité d’aperçu. Ils soulignent également que cette faille exploite une partie spécifique du code de rendu de la police, un segment que les développeurs devraient vérifier attentivement.

Bref, pensez à mettre à jour PDF.js vers une version supérieure à la 4.2.67 et à mettre à jour vos outils vers des version égales ou supérieures à Firefox 126, Firefox ESR 115.11 et Thunderbird 115.11.

Source

Imaginez télécharger un modèle d’IA apparemment inoffensif sur une plateforme de confiance comme Hugging Face et découvrir qu’il ouvre en fait une porte dérobée permettant à des attaquants de prendre le contrôle de votre système ! C’est le risque que pose la faille critique CVE-2024-34359, découverte récemment dans le célèbre package Python llama-cpp-python.

Ce package très utilisé permet d’intégrer facilement des modèles d’IA écrits en C++ dans des projets Python. Pour cela, il utilise la bibliothèque de templates Jinja2 qui est capable de faire un rendu dynamique du HTML à partir des données. Une lib surpuissante mais potentiellement risquée si c’est mal configuré !

Et c’est justement là que le bât blesse. Le package llama-cpp-python utilise Jinja2 pour traiter les métadonnées des modèles au format .gguf, mais sans activer les protections nécessaires comme le bac à sable. Du coup, en injectant un template malicieux dans les métadonnées d’un modèle, un pirate peut exécuter du code arbitraire sur le système hôte !

Les dégâts potentiels sont énormes : vol de données, prise de contrôle totale, interruption de services… Surtout que les systèmes IA manipulent souvent des données ultra sensibles. Et vu la popularité de llama-cpp-python, l’impact est massif : plus de 6000 modèles vulnérables rien que sur Hugging Face ! Selon un article détaillé de Checkmarx, cette faille permet des attaques de la chaîne d’approvisionnement, où un acteur malveillant peut injecter du code dans un modèle téléchargé et redistribuer ce modèle compromis pour attaquer les développeurs d’IA.

Découverte par Patrick Peng (alias retro0reg), cette vulnérabilité repose comme je vous l’expliquait sur une mauvaise implémentation du moteur de templates. Cette faille de score CVSS critique de 9.7, permet l’injection de template côté serveur, conduisant à une exécution de code à distance (RCE). Un proof-of-concept a même été publié sur Hugging Face, démontrant comment un modèle compromis peut exécuter du code arbitraire lorsqu’il est chargé ou lors d’une session de chat.

Cela met en lumière un problème plus large : la sécurité des systèmes d’IA est intimement liée à celle de leur chaîne logicielle. Une vulnérabilité dans une dépendance tierce peut compromettre tout un système. Il faut donc redoubler de vigilance à tous les niveaux. Les modèles d’IA étant souvent utilisés au sein de projets critiques et manipulant des volumes importants de données sensibles, la moindre faille peut avoir des conséquences catastrophiques.

Mais rassurez-vous, une solution existe ! La version 0.2.72 de llama-cpp-python corrige le tir en ajoutant une validation des entrées et un bac à sable robuste autour de Jinja2. Si vous utilisez une version antérieure, la mise à jour est plus que recommandée.

Comment savoir si vos modèles sont touchés ? Regardez s’ils utilisent :

• Le package llama-cpp-python en version < 0.2.72
• Le format de fichier .gguf
• Des templates Jinja2 dans les métadonnées

Si c’est le cas, passez immédiatement à la 0.2.72 ! Vous pouvez aussi auditer le code de vos modèles et regarder les permissions avec vos yeux de lynx.

Bref, comme d’hab, une petite faille peut vite tourner au désastre

Source

Vous utilisez probablement le GPS tous les jours sans y penser, que ce soit sur votre smartphone, dans votre voiture ou même dans un avion. Cette technologie de positionnement par satellites, et ses cousines comme GLONASS, Galileo et Beidou, sont devenues tellement courantes qu’on en oublierait presque qu’elles sont vulnérables. Et quand je dis vulnérables, je ne parle pas d’un bug ou d’un plantage logiciel, non. Je parle de menaces bien réelles qui peuvent rendre votre GPS complètement dingue !

Vous voyez, le GPS repose sur des signaux radio ultra faibles émis par des satellites à des milliers de kilomètres. Pour vous donner une idée, c’est un peu comme si vous essayiez d’entendre quelqu’un vous chuchoter quelque chose depuis l’autre bout d’un stade pendant un concert de rock ! Autant dire que c’est le bordel pour entendre quoi que ce soit.

Du coup, pas besoin d’être un génie pour comprendre qu’il est facile de noyer le signal GPS dans un gros brouhaha radio. C’est ce qu’on appelle le brouillage. Avec quelques watts seulement, on peut rendre le GPS inutilisable dans un rayon de plusieurs kilomètres ! Pas besoin d’un doctorat en électronique, un petit bricolage fait maison peut suffire. Évidemment, c’est complètement illégal, mais ça n’empêche pas certains de s’amuser à le faire.

Mais pourquoi brouiller le GPS ? Eh bien, en cas de conflit par exemple, c’est bien pratique pour empêcher l’ennemi de savoir où il est et où tirer ses missiles et ses drones. C’est d’ailleurs ce qui se passe en ce moment autour de l’Ukraine. Des zones de brouillage apparaissent régulièrement, rendant la navigation aérienne hasardeuse.

Mais le brouillage peut aussi servir à des fins moins guerrières. Tenez, en Chine, il paraît que des boîtes de pub brouillent le GPS des drones de leurs concurrents pendant des shows aériens pour leur faire perdre le contrôle et ruiner le spectacle ! De la concurrence de haut vol, sans mauvais jeu de mots.

Et les dégâts collatéraux dans tout ça ?

Parce que mine de rien, on ne dépend pas du GPS uniquement pour savoir si on doit tourner à gauche ou à droite au prochain croisement. Les réseaux de téléphonie mobile s’en servent également pour synchroniser leurs antennes relais. Ainsi, quand le GPS déconne, c’est toute la 4G/5G qui peut partir en vrille !

Mais si vous trouvez que le brouillage c’est déjà costaud, attendez de découvrir le leurrage ! Là, on passe au niveau supérieur. Le leurrage, c’est carrément une technique qui permet d’envoyer de faux signaux GPS pour faire croire à votre récepteur qu’il est ailleurs. Un peu comme si un petit rigolo changeait les panneaux sur la route pour vous faire croire que vous allez vers le sud de la France, alors que vous roulez vers le Nord.

Alors bien sûr, générer un faux signal GPS crédible, c’est autrement plus coton que simplement brouiller la fréquence. Il faut recréer toute une constellation de satellites virtuels avec les bons timings, les bonnes orbites, cohérents entre eux. Un vrai boulot d’orfèvre ! Mais une fois que c’est au point, imaginez le potentiel de nuisance ! Vous pourriez faire atterrir un avion de ligne à côté de la piste. Téléguidez un drone militaire en territoire ennemi ou envoyer un navire s’échouer sur des récifs. Ça fait froid dans le dos…

Heureusement, il existe des parades pour durcir les récepteurs GPS contre ces attaques : Utiliser des antennes directionnelles qui filtrent les signaux ne venant pas du ciel. Analyser en détail les signaux pour repérer les incohérences et les satellites suspects. Recouper avec d’autres capteurs comme les centrales inertielles. La version militaire du GPS dispose déjà de pas mal de protections dont du chiffrement.

Mais pour le GPS grand public dans nos smartphones et nos bagnoles, on est encore loin du compte. À part quelques modèles haut de gamme, la plupart gobent à peu près tout et n’importe quoi tant que ça ressemble à un signal GPS et il va falloir que ça change, et vite !

Scott Manley, un expert en la matière que vous connaissez peut-être pour ses vidéos sur les fusées, aborde en profondeur ces questions dans une vidéo bien documentée sur le sujet. Non seulement il analyse les risques de brouillage et de leurrage, mais il examine aussi les contre-mesures possibles, comme l’utilisation d’antennes directionnelles et l’analyse détaillée des signaux pour repérer d’éventuelles incohérences. Je vous mets la vidéo ici, ça vaut le coup d’œil :

On a beau être fan des nouvelles technos qui nous rendent la vie plus facile, faut quand même garder à l’esprit qu’elles ont leurs failles et leurs limites. Ça ne veut pas dire qu’il faut revenir à la bonne vieille carte Michelin et à la boussole, mais un petit cours de rattrapage en navigation à l’ancienne, ça ne ferait pas de mal !

Perso, la prochaine fois que mon appli Waze me dira de tourner à gauche direct un lac, je me méfierai…

Source

Les chasseurs de bugs et les experts en sécurité web sont toujours à la recherche d’outils pour optimiser leur boulot et dénicher des vulnérabilités et justement, il y a un nouveau venu qui risque bien de faire parler de lui : WebCopilot !

Open source, cet outil d’automatisation combine les fonctionnalités de dizaines d’autres outils réputés comme Subfinder, Nuclei, Amass ou encore SQLMap histoire de vous faire gagner un temps précieux en prenant en charge de A à Z les tâches répétitives et chronophages de l’énumération des sous-domaines, du filtrage des paramètres à risque et du scan des vulnérabilités les plus critiques.

Pour cela, il suffit de lancer WebCopilot sur un domaine cible et il s’occupe de tout :

• Énumération des sous-domaines via une batterie d’outils (Assetfinder, Sublist3r, Amass, Findomain…)
• Crawl de tous les endpoints des sous-domaines identifiés
• Filtrage des paramètres potentiellement vulnérables aux failles XSS, SQLi, LFI, SSRF, Open Redirect… grâce aux patterns de l’outil gf
• Et enfin, scan des vulnérabilités via des outils comme Nuclei, Dalfox, kxss, SQLMap ou crlfuzz

Vous obtiendrez ensuite un rapport complet qui répertoriera tous les points d’entrée intéressants.

             
                                ──────▄▀▄─────▄▀▄
                                ─────▄█░░▀▀▀▀▀░░█▄
                                ─▄▄──█░░░░░░░░░░░█──▄▄
                                █▄▄█─█░░▀░░┬░░▀░░█─█▄▄█
 ██╗░░░░░░░██╗███████╗██████╗░░█████╗░░█████╗░██████╗░██╗██╗░░░░░░█████╗░████████╗
░██║░░██╗░░██║██╔════╝██╔══██╗██╔══██╗██╔══██╗██╔══██╗██║██║░░░░░██╔══██╗╚══██╔══╝
░╚██╗████╗██╔╝█████╗░░██████╦╝██║░░╚═╝██║░░██║██████╔╝██║██║░░░░░██║░░██║░░░██║░░░
░░████╔═████║░██╔══╝░░██╔══██╗██║░░██╗██║░░██║██╔═══╝░██║██║░░░░░██║░░██║░░░██║░░░
░░╚██╔╝░╚██╔╝░███████╗██████╦╝╚█████╔╝╚█████╔╝██║░░░░░██║███████╗╚█████╔╝░░░██║░░░
░░░╚═╝░░░╚═╝░░╚══════╝╚═════╝░░╚════╝░░╚════╝░╚═╝░░░░░╚═╝╚══════╝░╚════╝░░░░╚═╝░░░
                                                      [●] @h4r5h1t.hrs | G!2m0

Usage:
webcopilot -d <target>
webcopilot -d <target> -s
webcopilot [-d target] [-o output destination] [-t threads] [-b blind server URL] [-x exclude domains]

Flags:  
  -d        Add your target [Requried]
  -o        To save outputs in folder [Default: domain.com]
  -t        Number of threads [Default: 100]
  -b        Add your server for BXSS [Default: False]
  -x        Exclude out of scope domains [Default: False]
  -s        Run only Subdomain Enumeration [Default: False]
  -h        Show this help message

Example: webcopilot  -d domain.com -o domain -t 333 -x exclude.txt -b testServer.xss
Use https://xsshunter.com/ or https://interact.projectdiscovery.io/ to get your server

Fini les heures passées à lancer des dizaines de commandes et à corréler les résultats comme ça, vous pourrez vous concentrer sur l’analyse des vulnérabilités.

Côté utilisation, c’est ultra simple. Il suffit de cloner le repo Github, d’installer les dépendances…

git clone https://github.com/h4r5h1t/webcopilot && cd webcopilot/ && chmod +x webcopilot install.sh && mv webcopilot /usr/bin/ && ./install.sh

…et vous pouvez lancer des scans en une seule commande :

webcopilot -d domain.com -o rapport

Et si vous voulez pousser la configuration plus loin, pas de problème ! WebCopilot propose tout un tas d’options bien pratiques comme :

• -s pour ne faire que de l’énumération de sous-domaines
• -x pour exclure certains domaines du scan
• -b pour spécifier un serveur « blind XSS » externe
• -t pour régler le nombre de threads et accélérer les scans

Bref, c’est l’outil pratique pour industrialiser encore un peu plus votre processus de bug bounty.

A découvrir ici !

Vous pensiez que les vieux Windows étaient devenus inoffensifs avec le temps ? Détrompez-vous ! Le bidouilleur Eric Parker s’est récemment amusé à exposer directement sur Internet des machines tournant sous Windows XP, 2000 et 98, sans aucune protection… et le résultat est franchement flippant.

Parce que oui, même en 2024, quand on branche en direct un vieux Windows sur le net, sans pare-feu matériel pour filtrer les connexions non désirées, c’est le scénario catastrophe assuré. Votre antiquité numérique se retrouve à poil sur les réseaux, à la merci du premier script kiddie venu. Et ça ne fera pas long feu avant que votre bécane ne soit infestée de malwares !

Commençons par Windows 98. Lors de son test, Eric a eu beau patienter, rien ne s’est passé. Pas l’ombre d’un ver, backdoor ou cheval de Troie à l’horizon. Il semblerait que la vieille bécane bénéficie d’une forme de « sécurité par l’obscurité ». Avec si peu de Windows 98 encore connectés, les hackers ne prennent plus la peine d’écrire des exploits dédiés. Ouf !

Passons à Windows 2000. Là, c’est une tout autre histoire ! À peine connecté, les scans de ports ont révélé la présence de SMB, le protocole d’échange de fichiers, réputé pour ses failles béantes. Et quelques minutes plus tard, patatra ! Un bel écran bleu, suivi d’un redémarrage en boucle. En inspectant le système, Eric a découvert une backdoor signée « Shang Xen Smartphone Technology », des modifications de fichiers systèmes et même un mystérieux exécutable caché dans un dossier Temp. De quoi transformer la machine en parfait zombie à la solde des pirates !

Et Windows XP dans tout ça ? Pareil, 10 minutes chrono pour chopper un premier trojan « conhost.exe ». S’en sont suivis la création d’un compte administrateur, l’apparition d’un serveur FTP ouvert aux quatre vents, et tout un tas de saletés en provenance de Russie, le tout bien planqué dans le système. En bonus, un malware s’est même amusé à éjecter Malwarebytes, l’anti-virus qu’Eric avait installé. Bref, un joyeux bazar et une prise de contrôle totale de la machine, malgré un semblant de résistance du pare-feu intégré de XP.

Alors oui, ces expériences peuvent paraître un peu artificielles. Après tout, qui serait assez fou pour connecter directement un Windows préhistorique sur le net aujourd’hui ? Mais elles illustrent bien les progrès en matière de sécurité, et l’importance cruciale des protections réseau modernes (merci le NAT et les pare-feu !).

Et la morale de l’histoire ?

Primo, ne jamais sous-estimer les vieux Windows, ils sont toujours aussi vulnérables qu’à l’époque. Deuxio, faites tourner vos antiquités dans une VM ou un réseau isolé si vous y tenez. Tertio, soyez vigilants même sur les OS récents, les hackers affinent toujours leurs techniques pour exploiter la moindre faille.

Prenez soin de vos ordi, et à demain 🙂

Source

Vous débarquez dans votre laverie automatique préférée, les bras chargés de linge sale, et là, magie magie, grâce à une petite bidouille bien sentie, vous pouvez lancer une lessive gratuite, sans débourser un centime. C’est le rêve, non ? Eh bien, figurez-vous que c’est exactement ce qu’ont réussi à faire des étudiants un peu hackers sur les bords.

Alexander Sherbrooke et Iakov Taranenko, 2 petits génies de l’université de Santa Cruz, ont découvert une faille de sécurité dans le système des laveries connectées de CSC ServiceWorks. Je vous parle quand même d’un réseau de plus d’un million de machines à laver installées un peu partout dans le monde, des campus universitaires aux hôtels en passant par les résidences. Bref, un sacré parc de machines qui tournent à plein régime.

Pour y arriver, ils ont bidouillél’API utilisée par l’appli mobile CSC Go. Pour ceux qui ne sont pas familiers avec le jargon technique, une API c’est un truc qui permet à des applis et des appareils de communiquer entre eux au travers du réseau. Dans le cas présent, l’appli CSC Go permet aux utilisateurs de recharger leur compte, de payer et de lancer un cycle de lavage sur une machine proche. Cependant, les serveurs de CSC ne vérifiaient pas correctement qui avait le droit de faire quoi. N’importe qui peut entrer et faire ce qu’il veut. Et c’est exactement ce qu’ont fait nos deux compères.

En analysant le trafic réseau pendant qu’ils utilisaient l’appli CSC Go, Alexander et Iakov ont réussi à court-circuiter les contrôles de sécurité pour envoyer des commandes directement aux serveurs de CSC. Résultat des courses : ils ont pu modifier leur solde, ajouter des millions de dollars virtuels pour le budget lessive, et même localiser et interagir avec toutes les machines du réseau CSC ServiceWorks.

Bien sûr, avoir la lessive gratuite, c’est cool. Mais Alexander et Iakov ont surtout voulu montrer les dangers d’avoir des appareils connectés à Internet sans une sécurité au top. Le pire dans l’histoire, c’est qu’ils ont prévenu CSC ServiceWorks de la faille à plusieurs reprises depuis janvier, mais la société n’a jamais répondu. Pourtant, un simple petit formulaire de contact pour signaler les problèmes de sécurité, ça ne coûte pas bien cher et ça peut éviter de gros dégâts… J’espère juste que ces derniers ne préparent pas une action en justice…

Évidemment, bidouiller des machines à laver pour avoir des lessives gratuites, ce n’est pas l’attaque du siècle mais cela montre qu’il y a encore du boulot côté sécurité pour tous ces objets connectés. Alors pour se protéger de telles vulnérabilités, il est crucial de sécuriser les API en effectuant la vérification des commandes côté serveur plutôt que côté client et en utilisant des tokens d’authentification sécurisés.

En attendant, si vous croisez Alexander et Iakov sur leur campus, vous pouvez leur donner vos slips sales, ils savent y faire pour vous les rendre plus blanc que blanc. ^^

Source

Vous l’avez peut-être remarqué, mais ces derniers temps, les vulnérabilités dans les routeurs et autres équipements réseau se multiplient comme des petits pains. Et quand je dis petits pains, je parle plutôt du genre rassis et moisi qui traîne depuis des années dans un placard. C’est le cas de deux failles qui touchent les routeurs D-Link DIR-600 et DIR-605, qui viennent d’être ajoutées par la CISA à son catalogue des vulnérabilités activement exploitées par les pirates malveillants.

La première, CVE-2014-100005, permet à un attaquant de changer la configuration du routeur DIR-600 à distance, sans avoir besoin de se connecter. Comment ? Et bien grâce à une bonne vieille faille CSRF (Cross-Site Request Forgery), cette faille bien connue des années 2000 qui fait toujours des ravages en 2024. Il suffit que l’admin du routeur visite une page web piégée, et hop, l’attaquant peut faire ce qu’il veut de la config !

La deuxième, CVE-2021-40655, est une fuite d’informations dans l’interface web du DIR-605. En forgeant une requête HTTP POST vers la page « /getcfg.php », un petit malin peut récupérer en clair le nom d’utilisateur et le mot de passe de l’administrateur. Ça fait rêver, n’est-ce pas ?

La CISA précise que ces failles sont activement exploitées, mais ne donne pas plus de détails.

Le plus rigolo, c’est que la première faille date de 2014 et concerne un modèle qui n’est plus supporté depuis belle lurette. Donc si vous avez encore un DIR-600 qui traîne, il est plus que temps de le mettre à la retraite et de passer à un modèle plus récent. Pour la deuxième, pas de patch connu à ce jour, donc restez vigilants.

Mais ce n’est pas fini puisque d’autres chercheurs de SSD Secure Disclosure ont aussi trouvé des failles 0-day dans le routeur D-Link DIR-X4860. En combinant un contournement d’authentification et une injection de commande, un attaquant pourrait prendre le contrôle total de l’appareil, avec les privilèges root s’il vous plaît. Bref, le routeur est complètement compromis.

D-Link a été prévenu il y a un mois, mais n’a toujours pas réagi. Les détails techniques sont disponibles sur le blog de SSD, avec même un PoC prêt à l’emploi. La faille touche la version de firmware 1.04b03. Donc, si vous avez ce modèle, vérifiez votre version et espérez que D-Link réagisse rapidement et publie un correctif.

En attendant, la meilleure chose à faire est de garder son routeur à jour, de changer les mots de passe par défaut et de désactiver les fonctions dont on n’a pas besoin, comme l’accès à distance. Et pourquoi pas flasher son vieux routeur avec un firmware alternatif comme OpenWrt ou DD-WRT, qui sont généralement plus sûrs et plus à jour que les firmwares constructeurs ?

Allez, au boulot !

Source

Vous pensiez que vos secrets étaient en sécurité dans vos images Docker ? Détrompez-vous ! Une étude de l’Université d’Aix-la-Chapelle a révélé que près de 10% des images publiques sur DockerHub contenait des secrets (donc des identifiants, des clés API, des mots de passe, des endpoints sensibles…Etc).

Ça fait froid dans le dos.

On parle de plus de 50 000 clés d’API et d’identifiants accessibles publiquement. Et ce n’est que la partie émergée de l’iceberg puisque les chercheurs de Redhunt Labs ont aussi trouvé plus de 46 000 Dockerfiles exposant des infos sensibles. Bref, c’est la fête du slip côté sécurité !

Mais comment ces secrets se retrouvent-ils à fuiter comme une passoire ? Et bien c’est souvent, c’est à cause d’opérations de fichiers trop permissives, de secrets mis en dur dans les Dockerfiles…etc

Par exemple, beaucoup de tutos et même la doc officielle de Docker suggèrent d’utiliser COPY . . pour copier tout le répertoire courant dans l’image. Sauf que ça inclut aussi les fichiers sensibles comme .env ou l’historique Git. Pas top pour la confidentialité.

Et même si vous supprimez ces fichiers sensibles après le COPY, ils restent présents dans les couches précédentes de l’image. Un attaquant pourra donc toujours y accéder. Merci les layers 🙂

Autre coup classique : mettre directement les secrets dans le Dockerfile ou les passer en argument au build. Là encore, c’est cadeau pour les hackers. Un simple docker history --no-trunc et hop, vos secrets sont à nu.

Heureusement, il existe des solutions pour sécuriser tout ça. Par exemple, les builds multi-stages permettent d’isoler les secrets dans une étape intermédiaire qui ne sera pas conservée dans l’image finale. Et depuis peu, BuildKit propose une option --secret pour injecter les secrets sans les stocker dans l’image, mais attention aux pièges ! Si votre app log le secret qu’elle utilise, il finira quand même dans l’image. Les builds multi-stages restent donc plus safe de ce côté là.

Bref, vous l’aurez compris, la gestion des secrets dans Docker, c’est pas de la tarte mais en suivant les bonnes pratiques, vous pourrez limiter les risques.

Bref, pensez builds multi-stages, utilisez .dockerignore, oubliez les secrets en dur et n’abusez pas des arguments de build. Et surtout, ayez le réflexe d’auditer vos images avec des outils comme TruffleHog. Parce qu’un secret qui fuite, c’est votre réputation qui coule.

C’est vraiment une histoire incroyable que je découvre là… Un groupe de cyber criminels a réussi l’exploit de pirater plus de 400 000 serveurs Linux / FreeBSD / OpenBSD / SunOS / OSX depuis 15 ans, et tout le monde est passé à côté. Et tout cela grâce à un cheval de Troie appelé Ebury qui se planque discrètement dans le système.

Techniquement, Ebury s’infiltre via OpenSSH, le protocole qui permet de se connecter à distance à un serveur et une fois installé, ce parasite ouvre une porte dérobée pour que les pirates puissent entrer et sortir comme dans un moulin. Et le pire, c’est qu’il est super discret : il efface ses traces et se fait passer pour un processus légitime. Un vrai caméléon !

Très contents de mettre la main sur tous ces serveurs, les hackers ont aussi réussi à récupérer les mots de passe chiffrés de plus de 500 utilisateurs. Un trésor de guerre qui leur a permis de craquer la moitié des comptes et de se balader tranquille sur les machines infectées. D’après les experts en sécurité d’Eset, Ebury aurait commencé à sévir dès 2009, en s’attaquant aux serveurs de kernel.org, le sanctuaire du noyau Linux. Puis au fil des années, il s’est propagé un peu partout, en passant par des fournisseurs d’accès, des hébergeurs web, jusqu’à créer un méga botnet de plus de 400 000 zombies. Un peu flippant quand même…

Mais alors pourquoi personne n’a rien vu pendant tout ce temps ?

Eh bien, en 2011 déjà, des petits malins avaient repéré un truc louche et donné l’alerte. Les boss de kernel.org avaient alors promis de mener l’enquête… mais sans jamais donner de nouvelles. Un silence radio qui en dit long sur l’ampleur de la catastrophe !

Le pire dans tout ça, c’est qu’Ebury est toujours actif et continue de contaminer de nouvelles victimes grâce notamment à des failles 0-day dans des outils d’administration, du phishing, des attaques par dictionnaire sur SSH… Bref, l’attirail classique du parfait petit pirate. Sans oublier une méthode bien vicieuse : le gang vole carrément les identifiants d’autres cybercriminels et les utilise pour louer des serveurs et brouiller les pistes.

Ainsi, une fois qu’ils ont mis la main sur un maximum de machines, ils minent de la cryptomonnaie, volent des données bancaires, envoient du spam et redirigent du trafic web pour se faire du blé. La routine du cybercriminel, quoi… Mais rassurez-vous, il y a quand même des trucs à faire pour éviter de se faire piéger comme un bleu.

Déjà, oubliez le mot de passe unique et passez à l’authentification multi-facteurs sur SSH. Ensuite, surveillez vos logs et les connexions douteuses. Et si vous êtes sysadmin, appliquez direct les patchs de sécurité et surveillez régulièrement vos serveurs. Pour vous dire à quel point ces mecs sont doués, réussir à passer inaperçu pendant 15 piges et pirater autant de serveurs, c’est quand même pas rien ! Alors c’est pas une raison pour baisser la garde en touillant votre petit café !

Pour en savoir plus sur Ebury et ses impacts, n’hésitez pas à consulter ce rapport détaillé disponibles en ligne.

Bon courage 🙂

Source

Vous avez déjà entendu parler de Viginum ?

Alors, non, ce n’est pas un nouveau personnage dans Fortnite, mais le service de vigilance de l’État contre les ingérences numériques étrangères. Et en ce moment, ils ont du pain sur la planche, notamment en Nouvelle-Calédonie !

D’un côté, y’a la Chine, la Russie et l’Azerbaïdjan qui s’amusent à mettre leur grain de sel dans le débat public calédonien, via des campagnes de désinformation sur les réseaux sociaux. De l’autre, une petite équipe de geeks qui chez Viginum essaie de démêler le vrai du faux dans ce joyeux bordel numérique. Pas facile en effet de faire le tri entre les fake news des trolls russes, les mèmes des fermes à clics azerbaïdjanaises et la propagande des membres du « 50 Cent Party » (ou 五毛党 en chinois).

Dans ce contexte tendu, l’actualité brûlante et le blocage unilatéral de TikTok soulèvent des questions plutôt complexes c’est vrai. D’un côté, le réseau social étant détenu par l’entreprise chinoise ByteDance, il existe un risque réel d’ingérence de la part du gouvernement chinois. Bloquer TikTok pourrait donc être vu comme une mesure de protection de la souveraineté numérique. Mais d’un autre côté, couper l’accès à une application aussi populaire, surtout auprès des jeunes, pourrait être perçu comme une atteinte à la liberté d’expression et renforcer la défiance envers l’État.

De plus, les utilisateurs (et les trolls) finiront simplement par se disperser vers d’autres réseaux sociaux, ce qui rendra la mesure inefficace. Plutôt qu’une censure brutale, je pense qu’une approche plus nuancée, axée sur l’éducation aux médias et la lutte contre la désinformation, aurait été préférable. Mais bon, vu la situation d’urgence, c’est surement trop tard… Il aurait fallu se réveiller avant.

Face à ces défis, Viginium dispose d’un arsenal technique impressionnant. Ils collectent des données sur les réseaux sociaux en analysant notamment les métadonnées afin d’identifier les flux massifs d’informations suspectes venant de l’étranger. Par exemple, si un flot soudain de tweets pro-indépendance en Nouvelle-Calédonie provient de comptes basés à l’étranger, c’est un signal d’alarme pour eux. Notez quand même qu’ils ne se posent pas en arbitre de la vérité : leur rôle est simplement de détecter ces anomalies. Leurs alertes permettent ensuite au gouvernement d’étayer ses décisions.

Mais à quoi bon se donner tant de mal ?

L’enjeu est de taille puisqu’il s’agit ni plus ni moins que de la souveraineté nationale. En effet, des campagnes de désinformation bien orchestrées peuvent déstabiliser le débat public et influencer des résultats critiques, comme lors des référendums d’indépendance en Nouvelle-Calédonie. Le dernier, qui a eu lieu en décembre 2021, avait d’ailleurs fait l’objet d’une surveillance étroite de Viginum pour repérer les activités en ligne suspectes.

Bien qu’équipés de technologies avancées (algorithmes de détection de bots, OSINT…), les experts de Viginum opèrent dans un cadre légal bien défini, garantissant ainsi le respect des libertés individuelles. La législation actuelle encadre strictement leur actions : la collecte des données est soumise à décrets, leur conservation est limitée à six mois, et un comité éthique, présidé par un haut conseiller d’État, veille au respect des règles. Cet équilibre entre efficacité et protection des droits des citoyens est essentiel pour maintenir la confiance envers cette institution de notre cybersécurité nationale.

En fin de compte, Viginum joue un rôle plutôt méconnu mais crucial dans la défense de la souveraineté française face aux ingérences étrangères et je trouvais ça intéressant de vous en parler un peu. Vous trouverez plus d’infos ici.

Apple et Google, les deux titans du monde mobile, ont décidé de mettre leurs différends de côté pour unir leurs forces en nous dévoilant un nouveau protocole : le « Detecting Unwanted Location Trackers ». Rien que le nom, ça envoie du lourd !

En résumé, c’est un standard commun qui va permettre à iOS et Android de nous alerter quand un traqueur Bluetooth non associé à notre smartphone tente de nous suivre à notre insu. Fini les ex psychopathes un peu trop collants, les parents pervers narcissiques qui jouent les espions et autres individus mal intentionnés ! Notre téléphone nous avertira directement si un de ces traqueurs se faufile dans nos déplacements. C’est une bonne nouvelle non ?

Dès qu’un accessoire Bluetooth compatible avec ce protocole sera détecté près de vous alors qu’il n’est pas associé à votre appareil, vous recevrez une alerte : « Objet détecté se déplaçant avec vous ». Un message un peu flippant, certes, mais au moins c’est clair ! Et en cliquant sur cette alerte, vous pourrez voir l’identifiant du traqueur, lui ordonner de faire du bruit pour le retrouver (ça, c’est la partie marrante 😄), et même le désactiver directement depuis votre téléphone (moins drôle pour le stalker).

Néanmoins, il faut relativiser car recevoir ce genre d’alerte ne signifie pas forcément que quelqu’un cherche volontairement à vous suivre. Cela pourrait très bien être un objet emprunté ou oublié qui porte un traqueur mais dans le doute, mieux vaut vérifier ! La bonne nouvelle, c’est que de nombreux fabricants d’accessoires se sont déjà engagés à rendre leurs futurs produits compatibles avec ce protocole dont Chipolo, eufy Security, Pebblebee et bien d’autres encore. Mais honnêtement, ils n’avaient pas trop le choix s’ils ne voulaient pas se faire boycotter par Apple et Google ! 😅

Cependant, au-delà de la plaisanterie, c’est une avancée significative pour notre vie privée. Avec la multiplication des objets connectés, il est devenu difficile de distinguer les accessoires légitimes de ceux utilisés par des personnes malveillantes donc ce nouveau standard nous offre plus de clarté et nous aide à surveiller qui pourrait tenter de nous espionner !

De plus, pour les paranos comme moi qui dorment avec un bonnet en alu sur la tête (non, je n’ai pas de problèmes psy…), sachez que ce n’est pas le premier système anti-pistage développé par ces GAFAMs. AirTag chez Apple et les autres accessoires du réseau Find My intègrent déjà de nombreuses protections contre les utilisations malveillantes. Mais cette initiative va encore plus loin en fédérant les deux systèmes mobiles leaders du marché et en incitant de nombreux acteurs à adopter ce protocole commun. Avec un peu de chance, dans quelques années, l’utilisation de traqueurs Bluetooth pour suivre quelqu’un à son insu sera obsolète.

D’ici là, un petit conseil : méfiez-vous des gadgets électroniques offerts soi-disant pour « garder un œil sur vos affaires ». C’est peut-être juste une excuse pour vous garder à l’œil, VOUS ! 👀 Et n’oubliez pas de prévenir les autorités si la situation semble vraiment préoccupante, restez vigilant et surveillez bien vos notifications. Peut-être qu’un tracker se cache déjà dans votre sac…

Pour plus d’informations, consultez les liens officiels : – Annonce Apple et Google dans le newsroom – Document IETF sur les traqueurs de localisation

Tiens, Microsoft nous prépare un nouveau bébé baptisé Zero Trust DNS, ou ZTDNS pour les intimes. Alors c’est quoi encore ce truc ? Eh bien c’est tout simplement un système permettant de sécuriser le DNS sur nos chers Windows.

Pour ceux qui auraient loupé un épisode, le DNS c’est un peu comme l’annuaire téléphonique d’Internet. Il permet de traduire les noms de domaine tout mignons comme korben.info en adresses IP bien moins sexy. Le problème, c’est que jusqu’à présent, le DNS c’était un peu le maillon faible de la sécurité. Les communications n’étaient pas chiffrées, ce qui ouvrait la porte à plein de menaces comme l’espionnage, le détournement de trafic ou même les attaques de type « DNS spoofing« . D’ailleurs, selon une étude de Cisco, plus de 70% des attaques de phishing utilisent des techniques de DNS spoofing pour tromper leurs victimes.

Mais ça, c’était avant ! Avec ZTDNS, Microsoft promet de changer la donne. Déjà, toutes les communications entre les clients Windows et les serveurs DNS seront chiffrées et authentifiées grâce aux protocoles DNS over HTTPS (DoH) ou DNS over TLS (DoT), ce qui devrait rendre la vie plus difficile aux vilains cyber criminels qui voudraient mettre leur nez dans nos petites affaires.

Ensuite, et c’est là que ça devient vraiment intéressant, ZTDNS va permettre aux admins réseau de contrôler finement quels domaines peuvent être résolus par les serveurs DNS. En gros, si un domaine n’est pas sur la liste blanche, et bien le client Windows ne pourra tout simplement pas s’y connecter !

Mais attention, mettre en place un truc pareil, ça ne va pas être une partie de plaisir. Il va falloir bien planifier son coup pour éviter de tout casser, du genre bloquer sans faire exprès l’accès à des services importants ! Mais bon, c’est le prix à payer pour renforcer la sécurité et se rapprocher doucement d’un modèle « Zero Trust » où on ne fait confiance à personne par défaut.

Alors concrètement, comment ça va marcher ?

Eh bien déjà, il faudra que les serveurs DNS supportent les protocoles de chiffrement comme DoH ou DoT. Ça tombe bien, ZTDNS est conçu pour être compatible avec tout ça. Pas besoin de réinventer la roue.

Ensuite, lorsqu’un client Windows aura besoin de résoudre un nom de domaine, il va discuter avec un des fameux serveurs DNS « protecteurs » et si le domaine est autorisé, le serveur lui filera l’adresse IP correspondante. Et hop, le pare-feu Windows sera dynamiquement mis à jour pour autoriser la connexion vers cette IP. Par contre, pour le reste, c’est niet ! Le trafic sera bloqué direct !

Bon après, faut quand même avouer qu’il y aura des trucs qui vont morfler à cause de ZTDNS. Tous les protocoles réseaux un peu exotiques qui n’utilisent pas le DNS, comme le multicast DNS (mDNS) par exemple, ça va être coupé. Pareil pour les partages de fichiers sur le réseau local ou les imprimantes qui utilisent des protocoles de découverte archaïques. Ça risque donc de râler dans les chaumières !

Mais heureusement, les ingénieurs de Microsoft ne sont pas nés de la dernière pluie et ont prévu pas mal de mécanismes pour « mitiger » ces problèmes. Par exemple, on va pouvoir définir des exceptions pour autoriser certaines plages d’adresses IP sans passer par le DNS. Ou encore favoriser des solutions plus modernes et sécurisées, comme l’impression via Universal Print qui passe, lui, gentiment par le DNS.

Un autre truc à prendre en compte, c’est que certaines applications un peu spéciales risquent de ne plus fonctionner du tout avec ZTDNS. Celles qui utilisent des adresses IP codées en dur ou des mécanismes de résolution maison, c’est mort. Mais bon, ce sera l’occasion de faire le ménage et de moderniser tout ça.

Microsoft a d’ailleurs prévu un mode « Audit » qui permet dans un premier temps de voir ce qui serait bloqué par ZTDNS, sans pour autant péter la prod. Comme ça, on peut analyser tranquillement les flux réseau et identifier les applications ou les flux problématiques. C’est un bon moyen d’anticiper les éventuels soucis avant de passer en mode bloquant !

Bon après, faut pas non plus se voiler la face. Même avec ZTDNS, il restera toujours des failles de sécurité potentielles. Les connexions VPN ou SASE/SSE par exemple, qui encapsulent le trafic dans un tunnel chiffré, pourront toujours passer entre les mailles du filet si on n’y prend pas garde. Sans parler des technologies de virtualisation qui court-circuitent carrément la pile réseau de Windows !

Mais bon, rien n’est parfait et il faut bien commencer quelque part… ZTDNS représente déjà une sacrée avancée pour renforcer la sécurité réseau des parcs Windows et avec un peu de rigueur et de persévérance, les admins sys pourront en tirer le meilleur parti.

Pour l’instant, ZTDNS est en preview privée chez Microsoft. On ne sait pas encore exactement quand il débarquera dans nos Home Sweet Home. En attendant, je vous invite à aller jeter un œil à l’article sur le blog Techcommunity qui rentre dans les détails techniques de la bête. C’est dense mais ça vaut le coup de s’y plonger si vous voulez être informé.

Source

Voici une info qui va vous faire voir les VPN sous un autre angle. Bah oui, parce que si vous pensiez que votre petit tunnel chiffré préféré vous mettait à l’abri des regards indiscrets quand vous surfez depuis un réseau public, désolé de casser vos rêves, mais c’est loin d’être le cas !

Une équipe de chercheurs de Leviathan Security a découvert une faille qu’ils ont baptisée TunnelVision qui permet de court-circuiter la protection des VPN à l’aiiise, grâce à une fonctionnalité bien pratique du protocole DHCP, ce bon vieux serviteur qui distribue des adresses IP à tout va.

En gros, quand vous vous connectez à un réseau, votre machine demande gentiment une adresse IP au serveur DHCP local. Jusque là, tout va bien. Sauf que ce protocole a plus d’un tour dans son sac. Il peut notamment pousser des règles de routage sur votre bécane, via une option peu connue appelée « Classless Static Route » ou option 121.

Concrètement, un attaquant qui contrôle le serveur DHCP peut installer des routes par défaut sur votre machine, ce qui lui permet de rediriger tout votre trafic vers sa propre passerelle, même si vous êtes connecté via un VPN ! Et là, c’est le drame, car il peut intercepter toutes vos données en clair. 😱

Bon, rassurez-vous, il y a quand même quelques conditions pour que cette attaque fonctionne :

• 1. L’attaquant doit avoir un accès physique au réseau local ou être en mesure de compromettre un équipement sur ce réseau.
• 2. Le client VPN ne doit pas bloquer les sorties de trafic vers les interfaces réseau locales.

Mais quand même, ça fait froid dans le dos, d’autant que cette faille touche potentiellement tous les réseaux, des petits réseaux domestiques aux gros réseaux d’entreprise. Les chercheurs ont d’ailleurs réussi à l’exploiter sur Windows, macOS, iOS, Android, et même sur des distributions Linux.

Heureusement, il existe des parades pour se prémunir contre TunnelVision :

• Activer les fonctions de DHCP snooping et d’ARP protection sur les commutateurs réseau pour empêcher l’installation de serveurs DHCP non autorisés.
• Configurer des règles de pare-feu strictes pour bloquer le trafic non autorisé.
• Utiliser des protocoles de chiffrement comme HTTPS pour sécuriser les ressources internes.
• Implémenter une isolation réseau robuste via des fonctionnalités comme les espaces de noms réseau (network namespaces) sous Linux.

Les fournisseurs de VPN ont évidemment aussi un rôle à jouer en documentant publiquement les mesures d’atténuation contre TunnelVision et en avertissant leurs utilisateurs des risques.

Bref, en attendant un éventuel correctif, la prudence reste de mise. Mais en appliquant les bonnes pratiques et en restant vigilants, on peut quand même limiter les dégâts ! Si le sujet vous intéresse et que vous voulez aller plus loin, je vous invite à consulter le papier de recherche complet qui détaille le fonctionnement technique de TunnelVision. C’est un peu ardu, mais ça vaut le coup d’œil pour les plus motivés d’entre vous.

Source

Vous pensez que les méthodes d’authentification modernes comme FIDO2 vous protègent efficacement contre le vol de cookies et les attaques de l’homme du milieu (MITM) ? Détrompez-vous ! Une équipe de chercheurs vient de démontrer qu’il est possible de contourner ces protections en s’emparant des précieux sésames que sont les jetons de session.

Vous vous connectez tranquillement à votre appli préférée, en scannant votre empreinte digitale ou en insérant votre clé de sécurité dernier cri, vous vous sentez en sécurité, comme un petit bébé dans les bras de sa maman ou de son papa, protégé par la magie de FIDO2 (et de son absence de mots de passe).

Sauf que dans l’ombre, un vilain pirate que nous appellerons Vladimitch, a réussi à s’immiscer entre vous et le serveur, tel un cyber-ninja. Et là, c’est le drame : il intercepte le fameux jeton de session qui vous permet de rester connecté sans avoir à retaper vos identifiants à chaque clic. Ni vu ni connu, il peut alors se faire passer pour vous et accéder à votre compte !

Mais comment est-ce possible avec une authentification si robuste ? Eh bien figurez-vous que le problème ne vient pas de FIDO2 en lui-même, mais plutôt de la façon dont les applications gèrent les sessions après la phase d’authentification. Une fois que vous êtes connecté, c’est open bar, et votre jeton se balade joyeusement sur le réseau, sans trop de protection.

Les chercheurs ont mis en lumière cette faille en testant plusieurs implémentations de FIDO2, comme le bac à sable Yubico Playground, le système d’authentification unique (SSO) Entra ID de Microsoft ou encore l’adaptateur PingFederate. Et dans chaque cas, ils ont pu démontrer qu’un attaquant pouvait intercepter et réutiliser un jeton de session valide sans posséder la clé d’authentification FIDO2 associée.

Mais rassurez-vous, tout n’est pas perdu. Il existe une parade pour éviter de se faire dérober son précieux jeton : la « liaison de jeton » (ou token binding pour les anglophones). Concrètement, ça consiste à créer un lien indéfectible entre votre jeton de session et la connexion sécurisée (TLS) que vous utilisez. Comme ça, il devient impossible pour l’attaquant d’utiliser votre jeton sur une autre connexion. Malin !

Le hic, c’est que cette protection est encore peu répandue. Et à part Microsoft qui l’a intégrée sur Edge, les autres navigateurs et applications web traînent des pieds. Google a même fini par jeter l’éponge sur Chrome, faute d’adoption. Pourtant, cela pourrait éviter bien des déboires aux utilisateurs et des migraines aux administrateurs système mais que voulez-vous, entre la sécurité et la facilité, le cœur des développeurs balance !

Bref, restez vigilant car même une sécurisation FIDO2 n’est pas infaillible face à une attaque MITM bien pensée. Microsoft a réagi de son côté en introduisant une fonctionnalité de protection des jetons basée sur les modules de plateforme sécurisée (TPM) dans Windows, une variante de la « liaison de jeton ». Mais pour une adoption massive, il faudra que tous les acteurs jouent le jeu.

En attendant, les experts recommandent aux développeurs d’applications d’exiger la « liaison de jeton » sur les authentifications FIDO2 lorsque c’est possible, de limiter l’usage des jetons OIDC et SAML à une seule fois par authentification réussie, et surtout de bien comprendre les menaces pour concevoir des mécanismes d’authentification adaptés.

Et vous, en tant qu’utilisateur, c’est toujours la même chanson, à savoir, évitez de vous connecter à des hotspots Wi-Fi publics douteux, ne cliquez pas sur les liens louches, et méfiez-vous des plugins de navigateur exotiques.

Bref, un peu de jugeotte, comme toujours… Sur ce, bon développement à tous et may the force (4th) be with you ! (On l’a passé, c’était le 4 mai…)

Source

Mauvaise nouvelle, Microsoft vient de mettre en lumière une faille bien vicieuse qui se planque dans un paquet d’applications Android… enfin, quand je dis un paquet, je parle quand même de plus de 4 milliards d’installations concernées.

Cette saleté, baptisée « Dirty Stream« , permet à une app malveillante d’écrire tranquillou dans le répertoire d’une autre app et d’exécuter du code comme bon lui semble.

Mais comment c’est possible ce bazar ?

Eh bien figurez-vous que sous Android, les apps peuvent partager des données entre elles grâce à un système de « fournisseur de contenu ». Jusque là, tout va bien, sauf que certains petits malins ont trouvé le moyen de contourner les contrôles de sécurité en utilisant des « intents personnalisés » mal ficelées.

En clair, une app malveillante envoie un fichier avec un nom ou un chemin trafiqué à une app légitime qui, sans méfiance, l’exécute ou le stocke gentiment dans l’un de ses dossiers critiques. Et paf, l’attaquant peut alors faire mumuse avec les données de l’app cible, voler des infos sensibles comme les identifiants SMB et FTP stockés dans le fichier rmt_i.properties, ou carrément prendre le contrôle de l’app. Bref, c’est le boxon.

Et le pire, c’est que ce genre de boulettes est monnaie courante. Les chercheurs de Microsoft ont épinglé plusieurs apps populaires, comme le gestionnaire de fichiers de Xiaomi (1 milliard d’installations, tout de même) qui utilise un chemin spécifique /files/lib pour sauvegarder les fichiers, ce qui peut être détourné par un attaquant. Autant dire que ça fait un sacré paquet de téléphones exposés.

Heureusement, après avoir prévenu Google et les éditeurs concernés, des correctifs ont été déployés en vitesse. Mais ça la fout mal surtout quand on sait que selon l’équipe de recherche sur la sécurité des applications Android de Google, 20% des apps Android seraient vulnérables à ce type d’attaque. Ouch !

Alors, que faire pour se protéger ?

Et bien commencez par mettre à jour vos apps via le Google Play Store, à vérifier les permissions des app installées et surtout évitez d’installer des appli louches surtout si ça vient d’un store alternatif ou un APK tombé du camion. Et si vous êtes dev Android, il va falloir blinder vos apps en suivant ces bonnes pratiques :

• Ignorer le nom retourné par le fournisseur de fichiers distant lors de la mise en cache du contenu reçu
• Utiliser des noms générés aléatoirement ou assainir le nom de fichier avant d’écrire un fichier en cache
• Vérifier que le fichier en cache se trouve dans un répertoire dédié avant d’effectuer une opération d’écriture
• Utiliser File.getCanonicalPath et valider le préfixe de la valeur retournée pour s’assurer que le fichier est au bon endroit

Voilà, vous savez tout pour ne pas vous faire dirty streamer dans les grandes largeurs !

Source

J’sais pas si vous savez, mais dès que vous créez un fichier, il y a plein de données qui se retrouvent dedans, la plupart du temps à votre insu… Et ça fonctionne avec tout : Photos, documents, morceau de musique et j’en passe. Cela s’appelle des Métadonnées, ça n’a rien de nouveau mais c’est bien utile aux pentesteurs et autres experts OSINT pour mener à bien leurs enquêtes.

Évidemment, les mecs ont autre chose à faire et plutôt que d’aller fouiller tout à la main, ils se reposent sur des outils comme celui que je vous présente aujourd’hui et qui s’appelle MetaDetective.

Développé par des passionnés de cybersécurité, MetaDetective est propulsé par Python et contrairement à certains outils qui dépendent d’une myriade de bibliothèques externes, il est plutôt autonome et simple à utiliser. Seul prérequis : avoir exiftool installé sur votre système. Une fois cette étape franchie, vous êtes prêt à plonger dans l’aventure !

L’une des forces de MetaDetective réside surtout dans sa capacité à catégoriser et à présenter les métadonnées de manière intuitive. Fini le casse-tête des données brutes et désorganisées. Que vous analysiez un fichier unique ou un ensemble de documents, MetaDetective vous offre une vue d’ensemble claire et structurée. Chaque information est minutieusement classée, vous permettant de naviguer aisément dans la richesse des données extraites.

L’outil intègre des fonctionnalités avancées de web scraping et là où d’autres se contentent de gratter la surface, MetaDetective, lui, plonge en profondeur, explorant méticuleusement de nombreux sites web pour en extraire les métadonnées les plus pertinentes. Oubliez les restrictions d’IP et les proxy laborieux à des services tiers, puisqu’il va directement se fournir à la source.

Vous pourrez bien évidemment ajuster la profondeur d’exploration, cibler des types de fichiers spécifiques, et même exclure certains termes pour affiner vos résultats. Et grâce à ses options d’exportation flexibles, vous pouvez générer des rapports clairs au format HTML ou texte.

Mais attention, avec un grand pouvoir vient une grande responsabilité. L’utilisation de MetaDetective doit se faire dans le respect des lois et réglementations en vigueur. Cet outil puissant ne doit pas être utilisé à des fins malveillantes ou illégales.

Pour en savoir plus sur MetaDetective et accéder à sa documentation complète, rendez-vous ici.

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.

J’ai hâte de dévorer tout ça !

Source + Source

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 :

1. Crée un fichier domaines.txt avec tes domaines, un par ligne.
2. 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 :

festin -T 20 -M 8 -B blacklist.txt -dr .mondomaine\.com mon-super-site.com

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 -rr festin.results -rd domaines_filtres.txt -ra domaines_bruts.txt mon-super-site.com

festin -rd domaines_filtres.txt && nmap -Pn -A -iL domaines_filtres.txt -oN nmap-resultats.txt

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 :

festin --index --index-server redis://127.0.0.1:6700 mon-super-site.com

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) :

tail -n +2 cible.com.csv | sort -u | cut -d "," -f 2 >> cible.com.domaines

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.

Source

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.

Source

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 !

Source

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.

Bref, gaffe à vos systèmes…

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 projet c’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 !

Cui ! (ouais, j’étais obligé)

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.

Pour l’installer sous Ubuntu, récupérez les .deb ici et lancez la commande :

sudo apt install ./opensnitch*.deb ./python3-opensnitch-ui*.deb

Et pour le lancer :

opensnitch-ui

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.

Plus d’infos ici !

Article paru initialement le 13 juin 2017 – Mis à jour le 8 avril 2024

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.

Source

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.

Source

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.

Bonne nouvelle non ?

Source

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.

Source

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 :

python secret_pixel.py hide host.png secret.txt mypublickey.pem output.png

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 :

python secret_pixel.py extract carrier.png myprivatekey.pem [extracted.txt]

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é.

Bonne carrière d’agent secret à tous !

Merci à Lorenper

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 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. Fort heureusement, ces versions n’ont pas été intégrées dans les releases stables des principales distributions. Par contre, elles se sont faufilées dans quelques bêtas, notamment Fedora 40, Fedora Rawhide et les distributions testing, unstable et experimental de Debian. Même Arch Linux y a eu droit dans une release stable.

Bref, on l’a échappé belle mais c’était moins une. Comme l’a souligné 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 catastrophe à l’échelle mondiale. Il faut dire que le petit malin qui a pondu ce code malveillant n’y est pas allé de main morte. Non content d’ouvrir une porte dérobée dans l’authentification SSH, il a pris soin de bien planquer son œuvre en l’obfusquant. Un travail de pro, il faut l’avouer.

Mais le plus dingue dans l’histoire, c’est que cette backdoor a été commitée par un certain JiaT75, l’un des deux principaux développeurs de xz Utils, qui bosse sur le projet depuis des années ! Autant dire que ça jette un sacré froid. Soit le gars a pété un plomb, soit il s’est fait méchamment compromettre son système. Quoi qu’il en soit, la pilule est dure à avaler pour la communauté.

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. Comme l’a fait remarquer un mainteneur de Fedora, ce fameux JiaT75 avait pris soin d’approcher l’équipe ces dernières semaines pour les convaincre d’intégrer la version backdoorée à Fedora 40. Un culot monstre ! Du coup, certains se demandent s’il ne faudrait pas regarder de plus près les précédentes contributions de ce développeur… Voire carrément auditer tout xz Utils, sait-on jamais.

En attendant, on ne peut que saluer le flair d’Andres qui a permis d’éviter le pire. Mais cet épisode laisse un goût amer et rappelle cruellement que la sécurité est l’affaire de tous, y compris au sein des projets open source.

Espérons que cette mésaventure servira de piqûre de rappel parce que mine de rien, on parle quand même du système qui fait tourner une bonne partie d’Internet et des infrastructures critiques.

Source

Vous connaissez la dernière ?

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 ?

Alerte rouge dans la galaxie des navigateurs web ! Microsoft vient d’annonce qu’une faille critique 0-day a été découverte dans Edge et corrigée en urgence. Mais attention, cette vulnérabilité ne se limite pas au navigateur de Microsoft puisque c’est toute la famille Chromium qui est touchée !

Google a bien tenté de faire profil bas en publiant discrètement un correctif pour Chrome le 26 mars, sans trop s’étendre sur les détails. Mais c’était sans compter sur la perspicacité de Microsoft qui a mis les pieds dans le plat en confirmant que l’exploit était activement utilisé par des cybercriminels. Aïe !

Baptisée CVE-2024-2883, cette vilaine faille se cache dans le moteur graphique ANGLE (Almost Native Graphics Layer Engine) utilisé par les navigateurs Chromium pour faire tourner le WebGL. En gros, c’est la porte d’entrée parfaite pour exécuter du code malveillant sur votre machine.

Heureusement, Microsoft a réagi au quart de tour en sortant illico presto la version 123.0.2420.65 d’Edge qui colmate la brèche. Mais attention, si vous utilisez un autre navigateur basé sur Chromium comme Chrome, Brave, Vivaldi ou Opera, vous êtes aussi concernés. Alors, foncez vérifier que vous avez bien la dernière version à jour !

Pour ce faire, rien de plus simple : tapez « chrome://settings/help » (ou l’équivalent pour votre navigateur) dans la barre d’adresse et laissez la magie opérer. Si une mise à jour est disponible, elle sera téléchargée et installée automatiquement. Ensuite, relancez le navigateur et le tour est joué !

Ce n’est pas la première fois qu’une faille 0-day fait trembler le monde des navigateurs. En 2021, une vulnérabilité similaire avait été découverte dans Chrome et avait été activement exploitée pendant des semaines avant d’être corrigée. Un vrai cauchemar pour les utilisateurs et les éditeurs !

Source

Saviez-vous qu’une faille de sécurité plus vicieuse qu’un boss de fin de niveau est tapie dans les entrailles de notre cher Linux depuis plus d’une décennie ? Et attention, on ne parle pas d’un vulgaire bug qui fait planter votre distrib’ préférée, non non. Cette saleté, baptisée « WallEscape » par Skyler Ferrante, un chercheur en sécurité un peu barré (on y reviendra), permet ni plus ni moins à un petit malin de vous subtiliser votre précieux mot de passe Admin !

Tout commence avec une commande anodine appelée « wall« , présente dans le package util-linux. Son petit boulot à elle, c’est d’envoyer des messages à tous les utilisateurs connectés sur une même machine. Jusque-là, rien de bien méchant, vous me direz.

Sauf que voilà, un beau jour, ou plutôt un sale jour de 2013, un commit un peu foireux est venu s’immiscer dans le code de wall tel un cheveu sur la soupe. Depuis, cette brebis galeuse s’est gentiment propagée dans toutes les versions de util-linux, tel un virus informatique qui s’ignore.

Mais qu’est-ce qu’il y avait de si terrible dans ce ce commit ? Eh bien, pour faire simple, le dev qui l’a poussé, a tout bonnement oublié de filtrer correctement les fameuses « escape sequences » dans les arguments de la ligne de commande. Résultat des courses : un petit malin un peu bricoleur peut maintenant s’amuser à injecter tout un tas de caractères de contrôle pour faire des trucs pas très catholiques sur votre terminal.

Et c’est là que notre ami chercheur en sécurité dont je vous parlais au début de l’article, entre en scène. Armé de sa curiosité légendaire et de son sens de l’humour douteux, il a flairé le potentiel de la faille et s’est amusé à monter un scénario d’attaque digne d’un film de ma saga préférée : « Die Hard ». L’idée, diaboliquement géniale, est d’utiliser ces fameuses « escape sequences » non filtrées pour créer de fausses invites sudo sur le terminal de la victime. Ainsi, tel un loup déguisé en agneau, l’attaquant peut vous inciter à gentiment taper votre mot de passe administrateur, pensant avoir affaire à une véritable demande d’authentification système.

Bon, je vous rassure tout de suite, il y a quand même quelques conditions à remplir pour que l’attaque fonctionne. Déjà, il faut que l’option « mesg » soit activée sur votre machine et que la commande wall ait les permissions setgid.

Bien sûr, en tant que vrai geek qui se respecte, vous avez probablement déjà mis à jour votre système avec la dernière version de util-linux qui colmate la brèche. Sinon, vous pouvez toujours vérifier que les permissions setgid ne sont pas activées sur wall ou carrément désactiver cette fonctionnalité de messages avec « mesg« .

En attendant, je ne peux que vous encourager à jeter un coup d’œil au PoC de notre ami chercheur, histoire de voir à quoi peut ressembler une fausse invite sudo des familles. C’est toujours ça de pris pour briller en société.

Allez, amusez-vous bien et n’oubliez pas : sudo rm -rf /*, c’est le mal !

Source

Vous pensiez que votre Bluetooth était safe ? Détrompez-vous ! Un chercheur en sécurité vient de dénicher une faille bien vicieuse qui permet d’exécuter du code à distance sur tout un tas d’appareils : smartphones Android, Chromecast, casques VR, TV connectées…

Le principe est diabolique : il suffit de se faire passer pour un clavier Bluetooth et hop, on peut envoyer des frappes de touches à la victime sans même qu’elle ait besoin d’accepter l’appairage. Pas besoin d’être à portée de main, quelques mètres suffisent. C’est ballot hein ?

Mais attendez, ça devient encore plus fort (ou pire, c’est selon). Des petits malins ont créé un outil baptisé BlueDucky qui automatise complètement l’exploitation de cette faille. Ça scanne les appareils vulnérables à proximité, ça les enregistre dans un fichier et ça balance un script Ducky bien sournois pour prendre le contrôle à distance. Le tout depuis un Raspberry Pi ou un smartphone Android !

Autant vous dire qu’ils se sont éclatés à tester ça sur tout ce qui passait : des smartphones, des objets connectés, des ordinateurs… Si c’est pas patché et que ça a du Bluetooth, ça tombe comme des mouches. Ils ont même réussi à ouvrir un navigateur et à envoyer la victime sur une page bien flippante, juste pour le fun.

Bon, vous allez me dire : « OK, mais comment on se protège de ce truc ?« . Eh bien c’est là que ça se gâte. Si vous avez un appareil récent, foncez installer les dernières mises à jour de sécurité. Mais pour les vieux machins sous Android 10 ou moins, c’est cuit, ça ne sera jamais patché. La seule solution : désactiver carrément le Bluetooth. Sinon, vous pouvez dire adieu à votre intimité numérique !

Mais ne cédons pas à la panique pour autant. Les chercheurs en sécurité font un boulot remarquable pour dénicher ces failles et alerter les fabricants. Maintenant, c’est à ces derniers de réagir en proposant des correctifs. Et à nous d’être vigilants en mettant à jour régulièrement nos appareils.

En attendant, si vous voulez jouer avec le feu dans la limite de ce que la loi permet, évidemment, le code de BlueDucky est disponible sur GitHub. Mais attention, c’est à vos risques et périls ! Ne venez pas vous plaindre si votre grille-pain se met à afficher des messages d’insulte au petit-déjeuner.

Pour l’installer :

# update apt
sudo apt-get update
sudo apt-get -y upgrade

# install dependencies from apt
sudo apt install -y bluez-tools bluez-hcidump libbluetooth-dev \
                    git gcc python3-pip python3-setuptools \
                    python3-pydbus

# install pybluez from source
git clone https://github.com/pybluez/pybluez.git
cd pybluez
sudo python3 setup.py install

# build bdaddr from the bluez source
cd ~/
git clone --depth=1 https://github.com/bluez/bluez.git
gcc -o bdaddr ~/bluez/tools/bdaddr.c ~/bluez/src/oui.c -I ~/bluez -lbluetooth
sudo cp bdaddr /usr/local/bin/

Et pour le lancer :

git clone https://github.com/pentestfunctions/BlueDucky.git
cd BlueDucky
sudo hciconfig hci0 up
python3 BlueDucky.py

Comme dirait l’autre, « le Bluetooth c’est comme le nucléaire, c’est génial tant que ça reste dans les mains des gentils« . Alors, soyez sympa et patchez-moi tout ça fissa ! Et si vous avez un appareil trop ancien qui traîne, coupez le Bluetooth et on n’en parle plus.

Pour en savoir plus sur cette faille et son exploitation, je vous invite à lire l’article ici.

Saviez vous que les fichiers Parquet se prenaient pour des bombes ? Alors pas des bombes latines mais plutôt des bombes zip.

Alors, pour ceux qui débarquent de la planète Mars, il faut savoir que Parquet est devenu le format de prédilection pour échanger des données tabulaires. Très utilisé dans tout ce qui est Big Data et qui met une claque à ce bon vieux CSV tout pourri, Parquet, c’est binaire, c’est colonnaire, c’est compressé, c’est top !

Mais attention, derrière cette apparente perfection se cache un danger mortel pour vos disques durs et autres SSD ! En effet, même un fichier Parquet parfaitement valide peut mettre un sacré bordel et faire planter tous vos services.

Comment ? Et bien simplement avec ce fichier de seulement 42 Ko qui contient… tenez-vous bien… plus de 4 PÉTAOCTETS de données !! Oui, on parle bien de 4 millions de gigaoctets dans un malheureux fichier de 42 Ko, fallait oser.

On appelle ça une bombe de décompression ! Alors comment ça fonctionne ?

Eh bien c’est grâce à un petit tour de passe-passe démoniaque appelé « encodage par dictionnaire« . En gros, on lui donne un dictionnaire avec une seule valeur, et ensuite on fait référence à cette valeur en boucle, environ 2 milliards de fois. Résultat, on obtient un fichier minuscule car compressable au maximum mais qui une fois dézippé représente une table monstrueusement gigantesque.

C’est subtil… mais c’est vicieux ! 😈

Imaginez un peu le carnage si vous balancez ce fichier innocent dans votre pipeline Big Data sans faire gaffe… Boom ! 💥 Plantage général, crash systémique, apocalypse nucléaire ! Vos services vont tenter de lire ce fichier en pensant que c’est un gentil petit fichier Parquet de rien du tout, et là… Surprise ! C’est le chaos total. Votre cluster va fondre comme neige au soleil en essayant d’avaler ces pétaoctets de données.

Morale de l’histoire, faites attention à tout, même à ce que vous dézippez.

Et si vous avez un peu de place sur votre disque dur, vous pouvez toujours tenter l’aventure en téléchargeant 42.zip ici. (NON, NE DEZIPPEZ PAS CE TRUC !! MAUVAISE IDEE !!) (le mot de passe du zip est : 42)

Source

Êtes vous correctement sécurisé ?

Enfin, je parle de vous mais surtout de vos données et de votre vie privée.

Alors vous allez me dire « Oui, oui, t’inquiète, je t’ai pas attendu pour mettre un long mot de passe » mais en réalité, vous ignorez peut-être certaines mesures de sécurité qu’il seraient également bon de mettre en place.

Heureusement, l’outil Personal Security Checklist est là pour vous aider à sécuriser votre vie numérique. C’est un site que vous pourrez traduire et proposer pourquoi pas dans votre entreprise. Maintenant, pour le tester, le mieux c’est d’aller sur le site Digital Defense qui propose une version en ligne.

Vous pourrez y naviguer entre des listes thématiques et cocher les contre-mesures que vous avez adoptées. Cerise sur le gâteau, vous verrez de jolis graphiques qui vous motiveront pour progresser sur votre hygiène numérique.

Un autre point fort de cette initiative est la mise à disposition d’une API gratuite pour accéder à toutes les données de la liste de vérification. Comme ça vous pourrez intégrer cette liste dans vos outils.

La Personal Security Checklist est un projet collaboratif et il y a pas mal de documentations et de liens avec des bons petits outils comme je les aime tant.

Pour finir, la Personal Security Checklist est sous licence MIT. C’est un excellent point de départ pour renforcer la sécurité de votre vie numérique. A vous de voir si vous pouvez cocher toutes les cases !

Merci à Lorenper

Les bloqueurs de pubs ont toujours été un souci pour pas mal de sites web. Perso, je ne m’en souci pas, mais d’autres mettent en place des stratégies parfois complexes notamment avec des JavaScript qui les détectent et bloquent l’utilisateur avec une grosse popup « DÉSACTIVE TON BLOQUEUR » ou lui envoie quand même de la publicité bien intrusive.

Et de leur côté, les bloqueurs de pub s’améliorent et se mettent à jour pour bloquer à leur tour ces JavaScript et ainsi de suite… Et cette petite guéguerre ne s’arrête jamais.

Enfin, ça, c’était vrai jusqu’à aujourd’hui puisqu’une nouvelle technique de détection des adblocks vient de voir le jour : la 103 Early Hints.

C’est encore un proof of concept mais l’idée c’est qu’au lieu d’attendre que la page se charge chez l’internaute pour vérifier s’il dispose d’un bloqueur de pub, on lui envoie des 103 Early Hints, c’est-à-dire des « indices » en amont, tel des petits éclaireurs. S’ils sont bloqués par le navigateur, alors le serveur web pourra renvoyer une page différente à l’internaute ou le rediriger, sans même que celui-ci ne s’en rende compte. Cette méthode est particulièrement efficace, car elle ne dépend pas de JavaScript, qui peut être désactivé ou manipulé côté client par les utilisateurs.

Les 103 Early Hints sont un code de statut HTTP informationnel (RFC 8297) qui fonctionne comme ceci : Quand un client fait une requête HTTP à un serveur, le serveur peut envoyer une réponse intermédiaire avec le code 103 Early Hints avant d’envoyer la réponse finale (200 OK par exemple).

Cette réponse 103 contient certains en-têtes que le serveur sait déjà qu’il va inclure dans la réponse finale, comme des en-têtes Link avec des ressources à pré-charger (scripts (de pub), CSS, etc.). En recevant ces en-têtes à l’avance dans le 103, le client peut commencer à télécharger ces ressources liées pendant que le serveur finit de préparer la réponse complète. Cela permet au client d’économiser du temps en parallélisant les téléchargements et au final la page se chargera plus rapidement pour l’utilisateur. Bien sûr, les en-têtes du 103 sont indicatifs et si le client ne gère pas le 103, il l’ignore simplement et attend la réponse finale du serveur.

Vous l’aurez compris, le 103 Early Hints est un mécanisme pour donner rapidement au client des indications sur la réponse à venir, afin qu’il puisse optimiser le chargement en parallèle des ressources liées, sans avoir à attendre la réponse complète du serveur.

Et le détourner comme cela, pour savoir si l’internaute dispose d’un bloqueur de pub, c’est très malin.

Pour mettre ça en place sur votre serveur, clonez donc le repo 103-early-anti-adblock puis installez les dépendances avec npm install. Ensuitz, générez les certificats SSL avec npm run certs (obligatoire pour HTTP/2) et lancez le bazar avec npm run serve

Lancez ensuite Firefox et admirez le résultat avec ou sans bloqueur de pub ! 🤓

Alors pourquoi Firefox ? Et bien pour le moment, cette technique ne fonctionne qu’avec Firefox. En effet, Chrome ne permet pas aux adblockers d’interagir avec les ressources chargées à l’aide des 103 Early Hints, et ne les affiche pas non plus dans la console dev. Et côté Apple, Safari ne prend pas du tout en charge les 103 Early Hints.

Mais ce n’est pas vraiment un souci puisque les navigateurs qui ne prennent pas totalement en charge les 103 Early Hints peuvent être facilement détectés en ajoutant une publicité factice au préchargement, qui ne sera pas bloquée par les bloqueurs de publicité.

Bref, ça risque encore de batailler dur entre les bloqueurs de pub et les sociétés qui s’y opposent.