Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Aujourd’hui — 28 mars 2024Flux principal

La moitié des applis pour enfants sur Android récoltent leurs données

Par : Korben
28 mars 2024 à 09:33

— Article en partenariat avec Incogni —

Salut la compagnie. Alors si vous avez l’habitude de me suivre, vous savez que j’ai déjà présenté l’outil Incogni de Surfshark d’un tas de façons différentes. Et mentionné les nombreux services qu’il peut rendre en fonction de votre situation. Mais s’il y a une cible que je n’ai pas abordée, c’est celui de nos marmottes marmots.

Parce que oui, lorsqu’on pense aux informations personnelles récupérées pour le plus grand bonheur des datas brokers (courtiers en données), on pense souvent aux nôtres, celles des « grands ». Et cela afin de créer des profils les plus complets possibles, notamment pour obtenir une image assez précise des sites que nous visitons, de nos achats en ligne, notre situation financière, nos centres d’intérêt, etc.

Sauf qu’il y a une catégorie d’utilisateurs que l’ont a tendance à oublier dans l’histoire, les enfants. Et oui, à notre époque pas mal de gamins passent déjà des heures en ligne (sur un smartphone ou à la maison) sans se préoccuper de savoir s’il y a un danger. Et les parents ne sont pas souvent capables de sécuriser leur environnement et leur apprendre les bons réflexes. Peu vont se renseigner sur les pratiques et les accès accordés aux applications installées (déjà que les parents eux-mêmes utilisent encore des passoires notoires comme Meta & Co …). Or les outils qu’utilisent les enfants, même s’ils semblent aussi peu dangereux que Oui-Oui, n’en sont pas mieux sécurisés pour autant. Ces bases de données centralisent et récupèrent leurs actions et peuvent ensuite tomber entre des mains malhonnêtes.

Le laboratoire de recherche d’Incogni a ainsi analysé 74 applications parmi les plus téléchargées et utilisées au monde par les plus jeunes. Sans surprise cela a permis d’épingler presque 50% de celles-ci (34) dont 2/3 (21) annoncent directement partager leurs données avec des tiers. Quasi 15% récoltent jusqu’à 7 types d’informations différentes : email, historique d’achat, localisation … voire photo. On comprend vite comment les choses peuvent mal tourner. En Europe c’est en moyenne 5 informations qui sont récupérées, la 2e région du monde la plus surveillée.

Incogni applis android pour enfants

Bon après il s’agit la plupart du temps de récolter de la data pour raison marketing, ou pour diagnostiquer des problèmes techniques (bugs & co). Mais encore faut-il faire confiance aux développeurs de l’appli en question. Ainsi Pokémon Quest annonce être clean sur le Google Play Store alors qu’elle récupère des données et les partage. À peine 1 appli sur 7 permet de désactiver cette récolte de données, et 1 sur 3 ne permet pas de supprimer ses infos (pas très RGPD). Une bonne nouvelle s’il faut en trouver une ? 94% chiffrent les données. C’est déjà ça.

Pour différencier les bons des mauvais élèves, vous pouvez vous rendre sur ce lien (onglet « App Rankings » puis cherchez votre pays). En France les cartons rouges sont pour Toca Life World, Kahoot et Avatar World (7 à 12 infos collectées), par contre les jeux des studios YovoGames et BabyBus c’est safe. Ainsi que Pat Partouille à la Rescousse … ouf, je vais mes gosses vont pouvoir continuer à jouer.

Du coup, pour en revenir à Incogni, disposer d’un service qui va nettoyer les bases de données du web des informations liées à vos enfants pourra s’avérer une bonne pratique à mettre en oeuvre. Plus vous commencez tôt et moins les informations se retrouveront dans de multiples bases de données. Si l’adresse mail de votre enfant se retrouve chez un broker, la faire retirer au plus vite est un bon réflexe à avoir, avant qu’elle ne soit reprise à gauche et à droite. N’attendez pas d’intégrer la liste de dizaines de brokers comme je l’ai fait, ça m’apprendra à laisser mon email chez n’importe qui 😉

Encore faut-il se rendre compte que tel ou tel courtier a ces informations en main. C’est le travail d’Incogni, qui va scanner l’ensemble des brokers qu’il surveille afin d’y trouver les éléments que vous voulez faire supprimer. Il contactera alors en votre nom ces derniers et leur demandera des retraits, et répétera l’opération jusqu’à ce qu’ils lâchent l’affaire. Des heures et des heures de recherches économisées et vous aurez l’esprit tranquille en sachant qu’il va s’assurer que ces retraits soient définitifs. Vous pouvez même suivre l’avancée des travaux directement depuis une interface simple.

Mais n’oubliez pas que VOUS êtes le premier rempart de votre progéniture. Eduquez-les, expliquez-leur les conséquences potentielles de tout ce qu’ils font sur la toile, etc. Vous ne les laisseriez pas jouer n’importe où ni avec n’importe qui en extérieur, il n’y a pas de raison que ce soit différent en ligne. Et si vous vous y mettez un peu tard, appelez le soldat Incogni à la rescousse pour vous assurer que les dommages sont limités !

Je découvre Incogni

Mettez à jour Google Chrome pour vous protéger de 7 vulnérabilités, dont 2 zero-day

28 mars 2024 à 06:00

Mardi 26 mars 2024, Google a publié une nouvelle version de son navigateur Chrome dans le but de corriger 7 vulnérabilités, dont 2 failles de sécurité zero-day découvertes lors du Pwn2Own 2024 de Vancouver. Faisons le point sur cette mise à jour !

Les utilisateurs de Google Chrome sur Windows Mac et Linux vont pouvoir passer par la case maintenance : l'entreprise américaine a mis en ligne plusieurs versions pour protéger ses utilisateurs. Tout d'abord, nous allons évoquer les deux failles de sécurité zero-day découvertes et exploitées lors du Pwn2Own 2024, une compétition de hacking.

La première vulnérabilité, associée à la référence CVE-2024-2886, a été découverte par Seunghyun Lee (@0x10n) de KAIST Hacking Lab, le 21 mars 2024. Il s'agit d'une faiblesse de type "use after free" présente dans WebCodecs.

La seconde vulnérabilité, associée à la référence CVE-2024-2887, a été découverte par Manfred Paul de l'équipe Trend Micro Zero Day Initiative. Il s'agit d'une faiblesse de type "type confusion" présente dans le composant WebAssembly. Ces deux vulnérabilités sont considérées comme importantes.

Par ailleurs, d'autres vulnérabilités ont été reportées directement à Google, notamment la faille de sécurité critique CVE-2024-2883, découverte par Cassidy Kim le 3 mars 2024. Il s'agit d'une vulnérabilité de type "use after free" dans ANGLE.

Pour vous protéger, vous devez mettre à jour Google Chrome pour passer sur les versions 123.0.6312.86/.87 pour Windows et Mac, ainsi que la version 123.0.6312.86 pour Linux. Les versions antérieures sont vulnérables. Vous pouvez obtenir plus d'informations dans le bulletin de sécurité de Google.

Pour rappel, suite aux vulnérabilités découvertes à l'occasion de cette compétition de hacking, la Fondation Mozilla a mis en ligne une nouvelle version pour son navigateur afin de combler deux failles de sécurité zero-day : Firefox 124.0.1. Enfin, sachez que Manfred Paul est le grand gagnant de cette édition du Pwn2Own Vancouver 2024 grâce à plusieurs vulnérabilités découvertes dans Mozilla Firefox, Apple Safari, Google Chrome et Microsoft Edge.

The post Mettez à jour Google Chrome pour vous protéger de 7 vulnérabilités, dont 2 zero-day first appeared on IT-Connect.

Hier — 27 mars 2024Flux principal

En 72 heures, le botnet TheMoon a compromis 6 000 routeurs ASUS

27 mars 2024 à 14:00

Une nouvelle variante du botnet "TheMoon" a été repéré dans 88 pays différents sur des milliers de routeurs, notamment de la marque ASUS, et des appareils IoT. Faisons le point sur cette menace.

Les chercheurs en sécurité de Black Lotus Labs ont surveillé de près la dernière campagne de TheMoon, qui s'est déroulée en mars 2024, et les chiffres sont élevés : en 72 heures, ce botnet est parvenu à compromettre 6 000 routeurs ASUS. Plus globalement, voici ce que précise le rapport au sujet de l'activité de TheMoon : "Alors que Lumen a déjà documenté cette famille de logiciels malveillants, notre dernier suivi a montré que TheMoon semble permettre la croissance de Faceless à un rythme de près de 7 000 nouveaux utilisateurs par semaine."

En effet, les appareils compromis par le botnet TheMoon sont ensuite exploités par le service proxy "Faceless" auquel il est lié. Ce service s'appuie sur les appareils infectés pour les utiliser comme proxy afin de masquer le trafic généré par les cybercriminels. Ainsi, ceci permet aux cybercriminels, notamment ceux des groupes IcedID et SolarMarker, de masquer leurs activités malveillantes.

TheMoon n'est pas une nouvelle menace puisqu'il a été repéré pour la première fois en 2014. À cette époque, il ciblait particulièrement les équipements LinkSys. Lors de la première semaine de mars, il y a eu une importante vague d'attaques à destination des routeurs ASUS.

Les routeurs ASUS, une cible privilégiée

Les chercheurs de Black Lotus Labs ne précisent pas comment les routeurs ASUS ont pu être compromis, mais il s'agirait de modèles qui ne sont plus pris en charge par le fabricant. Il est fort probable que des failles de sécurité connues et non corrigées soient exploitées par le botnet, ou que la technique du brute force soit utilisée : ces routeurs sont susceptibles d'être mal configurés et le compte admin par défaut pourrait fonctionner dans certains cas...

Lorsqu'un appareil est compromis, le logiciel malveillant part à la recherche d'un shell avec lequel il est compatible : "/bin/bash," "/bin/ash," ou "/bin/sh". Si c'est le cas, le chargeur télécharge, déchiffre et exécute un payload nommé ".nttpd" sur l'appareil. Ensuite, des règles de filtrage sont créées via iptables pour bloquer les flux entrants sur les ports 8080 et 80 en TCP, sauf pour des plages d'adresses IP spécifiques. Ceci permet aux attaquants d'être les seuls à pouvoir exploiter cet appareil à distance, notamment via le service de proxy. Enfin, TheMoon établit une connexion aux serveurs C2 pilotés par les attaquants et il est en attente de recevoir des instructions.

Si vous constatez des problèmes de stabilité, de performances ou des paramètres qui ont changé sur votre routeur ou un appareil IoT, il se pourrait que vous soyez victime de ce botnet, notamment si vous utilisez un routeur ASUS.

Source

The post En 72 heures, le botnet TheMoon a compromis 6 000 routeurs ASUS first appeared on IT-Connect.

Apex Legends – Un hacker sème le chaos lors d’un tournoi majeur

Par : Korben
27 mars 2024 à 14:54

Est ce que vous avez entendu parler de ce qui s’est passé lors du tournoi ALGS d’Apex Legends ? C’était complètement dingue ! Un hacker qui se fait appeler Destroyer2009 a réussi à s’introduire dans le jeu en plein milieu d’un match et a filé des cheats (aimbot, wallhack…) à des joueurs pro sans qu’ils ne demandent rien.

Déjà, mettez-vous à la place des joueurs concernés, ImperialHal de l’équipe TSM et Genburten de DarkZero. Vous êtes tranquille en train de jouer le tournoi le plus important de l’année et d’un coup, PAF, vous vous retrouvez avec des hacks que vous n’avez jamais demandés ! Voir à travers les murs, avoir un aimbot pour mettre dans le mille à coup sûr… La totale quoi. Évidemment, ils ont dû quitter la partie direct, impossible de continuer à jouer dans ces conditions.

Mais le pire, c’est que ce hacker a fait ça « just 4 fun » ! Il voulait montrer à Respawn qu’il y avait des failles dans leur système de sécurité EAC (EasyAntiCheat). Bah mon gars, t’as réussi ton coup, bravo ! Tout le tournoi a été interrompu et reporté à plus tard. Les organisateurs étaient furax et je les comprends.

Bon après, faut reconnaître que ce Destroyer2009 est un sacré filou. Il a quand même réussi à pirater un des plus gros jeux du moment en plein milieu d’un événement majeur, c’est pas rien. Et en plus, il a fait ça sans toucher aux PC des joueurs, juste en passant par le jeu. Un vrai petit génie du hacking.

Mais quand même, ça fout les jetons de voir que même un mastodonte comme Apex Legends peut se faire avoir comme ça. Ça montre qu’aucun jeu en ligne n’est à l’abri, même avec toutes les protections anti-triche du monde. Et puis ça gâche la compétition pour tout le monde, les joueurs, les spectateurs, les organisateurs…

Après ce bad buzz monumental, Respawn a dû réagir au quart de tour. Ils ont balancé dans la foulée une flopée de mises à jour de sécurité pour colmater les brèches. Espérons que ça suffira à calmer les ardeurs des petits malins qui voudraient s’amuser à reproduire ce genre de coup fourré.

M’enfin, le mal est fait et ce tournoi ALGS restera dans les annales pour cette raison. Ça aura au moins eu le mérite de remettre un coup de projecteur sur l’importance de la sécurité dans l’e-sport. C’est un milieu qui brasse de plus en plus de thunes et forcément, ça attire les hackers en tout genre.

L’essentiel, c’est que le tournoi a fini par reprendre et aller à son terme, même si on a dû attendre un peu. Et puis ça nous aura permis de voir que même les plus grands joueurs peuvent se retrouver démunis face à un hack imprévu. Ça les rend plus humains ! mdrrr.

Allez, amusez-vous bien sur Apex ou ailleurs !

Merci à Ayden et Halioss pour l’info

Source

BlueDucky – Automatiser l’exploitation d’une faille Bluetooth pour exécuter du code à distance

Par : Korben
27 mars 2024 à 14:00

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.

Recrutement dans la cybersécurité en Europe : selon 3 entreprises sur 10, trois à six mois sont nécessaires pour embaucher un professionnel de la sécurité informatique

Par : UnderNews
27 mars 2024 à 11:09

La dernière étude de Kaspersky montre que 30 % des entreprises européennes considèrent qu’il faut entre trois et six mois pour recruter un professionnel qualifié en cybersécurité. L’absence d’expérience concrète des candidats malgré leurs diplômes, constitue un des grands défis cités, tout comme le coût élevé du recrutement et la concurrence mondiale en matière d’acquisition […]

The post Recrutement dans la cybersécurité en Europe : selon 3 entreprises sur 10, trois à six mois sont nécessaires pour embaucher un professionnel de la sécurité informatique first appeared on UnderNews.

VLC dévoile les sombres dessous de la signature d’apps Android

Par : Korben
27 mars 2024 à 09:21

Astuces VLC

La sécurité sur Android et plus particulièrement la signature des applications c’est loin d’être tout beau tout rose. Vous le savez peut-être, notre bon vieux VLC, a quelques soucis pour mettre à jour son app Android sur le Play Store ces derniers temps.

Alors pourquoi ce blocage ? Eh bien tout simplement parce que Google a décidé de rendre obligatoire l’utilisation des App Bundles pour toutes les applications proposant des fonctionnalités TV. Jusque-là, pas de problème me direz-vous. Sauf que ce nouveau format nécessite de fournir sa clé de signature privée à Google. Et ça, c’est juste im-po-ssible pour l’équipe de VLC !

Fournir sa clé privée à un tiers, c’est comme donner les clés de son appartement à son voisin. C’est la base de la sécurité : ce qui est privé doit le rester. Sinon autant laisser sa porte grande ouverte avec un panneau « Servez-vous » ! 😅

Depuis les débuts d’Android, chaque app doit être installée via un fichier APK. Ce fichier contient tout le nécessaire : le code, les ressources, les données… Et pour vérifier qu’un APK est authentique, il doit être signé avec une clé privée générée par le développeur. N’importe qui peut alors vérifier la clé publique utilisée pour signer le fichier.

L’avantage de ce système est de garantir l’intégrité de l’app. Si le développeur perd sa clé privée ou son mot de passe, impossible de publier des mises à jour car la nouvelle signature ne correspondra pas. Et s’il file sa clé à quelqu’un d’autre, cette personne pourra signer ses propres versions qui seront considérées comme légitimes. Vous voyez le problème maintenant ?

Avec les App Bundles, on passe à un système de double signature où une clé de téléchargement (upload key) permet au Play Store de vérifier que celui qui envoie le fichier est légitime. Jusque-là, ça va. Mais où clé de signature (release key), doit être détenue par Google ! Autrement dit, le Play Store signe l’app à la place du développeur. C’est donc cette clé privée que Google réclame aujourd’hui à VLC.

Google a bien tenté de mettre en place des mesures pour atténuer le problème, comme le dual release qui permet sur les appareils récents (Android 11+) d’installer une mise à jour signée différemment si une preuve de rotation de clé est fournie. Mais pour les apps comme VLC qui supportent aussi les vieux appareils et la TV, ça ne fonctionne pas.

Du coup, l’équipe de VLC se retrouve face à un choix cornélien :

  1. Donner sa clé privée à Google et continuer à publier normalement. Bénéfice : aucun. Risque : Google a le contrôle total sur les mises à jour et la sécurité de l’app. Autant dire que pour eux c’est non.
  2. Virer le support TV des APK publiés sur le Play Store. Avantage : pas besoin de donner sa clé privée pour les appareils récents. Inconvénient : plus de support TV pour les vieux appareils sous Android 10 et moins. Pas top.
  3. Passer full App Bundles. Avantage : aucun. Inconvénient : ça rendrait l’app incompatible avec 30% des utilisateurs actuels. Même pas en rêve !

Bref, vous l’aurez compris, l’équipe de VLC est dans une impasse et c’est pour ça qu’aucune mise à jour n’a été publiée ces derniers mois sur le Play Store.

Et ce n’est pas qu’une question de principe. Le Play Store n’est pas le seul store sur Android. VLC est aussi disponible sur le site officiel, l’Amazon AppStore, le Huawei AppGallery… Donc donner sa clé à Google compromettrait toute la chaîne de publication.

Malheureusement, sans modification de la part de Google sur ces nouvelles exigences, il n’y a pas de solution miracle pour continuer à proposer le support TV sur les vieux appareils Android via le Play Store.

C’est rageant pour les développeurs qui se retrouvent pieds et poings liés, mais c’est aussi inquiétant pour nous utilisateurs. Quand le plus gros store d’apps au monde se met à réclamer les clés privées des développeurs, on peut légitimement se poser des questions sur sa conception de la sécurité et de la vie privée.

Espérons que Google entendra les critiques et fera machine arrière sur ce point. En attendant, la seule chose à faire est de soutenir les développeurs comme VLC qui résistent encore et toujours à l’envahisseur et continuent à privilégier la sécurité de leurs utilisateurs avant tout.

Si ça vous interesse, vous pouvez suivre toute l’affaire en détail sur cet article passionnant (si si, je vous jure) : VLC for Android updates on the Play Store

Baromètre de la cybersécurité 2023 : Une prise de conscience croissante mais hétérogène

Par : UnderNews
26 mars 2024 à 16:39

Docaposte, filiale du groupe La Poste et leader français de la confiance numérique, et Cyblex Consulting, cabinet de conseil et d’audit en cybersécurité, présentent la première édition de leur baromètre annuel de la cybersécurité à l’occasion du Forum InCyber 2024. Cette enquête nationale, réalisée auprès de plus de 500 décideurs français*, a vocation à évaluer […]

The post Baromètre de la cybersécurité 2023 : Une prise de conscience croissante mais hétérogène first appeared on UnderNews.

42.parquet – La bombe Zip qui ruine le Big Data

Par : Korben
26 mars 2024 à 16:08

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

À partir d’avant-hierFlux principal

Le kit de phishing Tycoon 2FA contourne le MFA et cible les comptes Microsoft 365 et Gmail !

26 mars 2024 à 13:09

Tycoon 2FA, c'est le nom d'une plateforme de Phishing-as-a-Service (Phaas) utilisée par les cybercriminels pour cibler les utilisateurs de Gmail (Google) et de Microsoft 365, tout en outrepassant l'authentification à deux facteurs. Voici ce qu'il faut savoir sur ce kit redoutable !

En octobre 2023, les analyses de Sekoia ont fait la découverte de Tycoon 2FA pour la première fois. Néanmoins, les pirates du groupe Saad Tycoon en font la promotion sur un canal Telegram privé depuis août 2023.

Comme le soulignent les équipes de Sekoia dans un nouveau rapport, ce kit de phishing prêt à l'emploi est en pleine évolution et une nouvelle version a été publiée en 2024 : plus efficace et plus furtive, notamment l'ajout de capacités de détection et de blocage des bots. Actuellement, Tycoon 2FA exploite 1 100 domaines et a été utilisé pour mettre au point des milliers d'attaques de phishing.

Afin de pouvoir contourner l'authentification multifacteur et voler les informations d'identification des utilisateurs, Tycoon 2FA doit intercepter les données de la victime et les transmettre au service légitime. Pour atteindre cet objectif, la plateforme Tycoon 2FA intègre un reverse proxy qui va se positionner entre l'ordinateur de la victime et le service sur lequel elle va se connecter.

Un processus bien rôdé, en 7 étapes

Ainsi, actuellement en mars 2024, une attaque Tycoon 2FA se déroule en 7 étapes distinctes :

  • Étape 0 : les attaquants diffusent des liens malveillants par l'intermédiaire d'une campagne de phishing (e-mails malveillants) ou des QR codes piégés, dans le but d'amener la victime vers la page falsifiée.
  • Étape 1 : lorsqu'un utilisateur clique sur l'URL contenue dans l'e-mail, ou qu'il scanne le QR code, il est redirigé vers une page intégrant un défi Turnstile de Cloudflare afin de filtrer le trafic indésirable.
  • Étape 2 : cette étape n'est pas visible pour l'utilisateur, car elle exécute un code JavaScript en arrière-plan et redirige ensuite l'utilisateur vers une autre page en fonction de la présence d'une adresse électronique.
  • Étape 3 : cette étape est également invisible pour l'utilisateur qui sera redirigé automatiquement vers une autre page contrôlée par les cybercriminels.
  • Étape 4 : l'utilisateur se retrouve face à une fausse page de connexion Microsoft qui est utilisée par les attaquants pour voler les informations d'identification. WebSockets est utilisé pour l'exfiltration des données.
  • Étape 5 : c'est à ce moment-là que, si nécessaire, Tycoon 2FA va utiliser du code JavaScript pour proposer un défi 2FA à l'utilisateur, en relayant et en prenant en charge plusieurs méthodes (Notification sur Microsoft Authenticator, code à usage unique via une application, SMS ou par appel téléphonique). Il interceptera les informations de validation émises par l'utilisateur pour compléter le challenge MFA.
  • Étape 6 : fin du processus, l'utilisateur est redirigé vers une page déterminée par les cybercriminels. Le site de Microsoft, dans certains cas.

Au sujet de l'étape n°5, Sekoia précise : "À l'aide de serveurs proxy commerciaux, les pages d'hameçonnage Tycoon 2FA transmettent les données de l'utilisateur, notamment l'adresse électronique, le mot de passe et le code 2FA, à l'API d'authentification légitime de Microsoft. La réponse au trafic de l'API Microsoft renvoie les pages et les informations appropriées à l'utilisateur." - Ce qui montre l'efficacité de Tycoon 2FA et prouve que c'est un kit prêt à l'emploi très évolué.

Source : Sekoia

Les affiliés de Tycoon 2FA ont accès à un véritable tableau de bord d'administration au sein duquel ils peuvent visualiser les identifiants collectés avec l'identifiant, le mot de passe, l'état du MFA, ainsi que la possibilité d'obtenir des cookies d'authentification prêts à l'emploi.

Un ensemble de domaines malveillants est associé à l'utilisation du kit Tycoon 2FA. Vous pouvez retrouver la liste sur le GitHub de Sekoia, sur cette page.

Tycoon 2FA, une plateforme massivement utilisée par les pirates

Sekoia a pu analyser le portefeuille de cryptomonnaie utilisé par le groupe de cybercriminels à l'origine du kit Tycoon 2FA. Depuis août 2023, il y a eu 700 transactions entrantes d'une valeur moyenne de 366 dollars, soit plus de 256 000 dollars. Les analystes indiquent également que 530 transactions ont dépassé 120 dollars, ce qui correspond au tarif pour accéder à la plateforme PhaaS pendant 10 jours.

"En supposant que le portefeuille est principalement utilisé pour les opérations PhaaS de Tycoon 2FA depuis août 2023, le montant total des transactions suggère que plusieurs centaines de kits Tycoon 2FA ont été vendus 'as a service' sur une période de six mois.", peut-on lire.

Source

The post Le kit de phishing Tycoon 2FA contourne le MFA et cible les comptes Microsoft 365 et Gmail ! first appeared on IT-Connect.

Les télécommunications face aux défis de l’agilité, l’innovation et la sécurité

Par : UnderNews
26 mars 2024 à 15:13

Le secteur des télécommunications est en constante évolution, façonné par les besoins changeants des entreprises, des consommateurs et de la technologie. Depuis plusieurs mois, la transformation numérique est le principal défi des télécoms, les entreprises et les organisations exploitent la technologie pour innover, rester compétitives et répondre à l’évolution des demandes des clients et du […]

The post Les télécommunications face aux défis de l’agilité, l’innovation et la sécurité first appeared on UnderNews.

10% des entreprises du CAC 40 ont engagé un cyber-expert, bien plus que leurs homologues dans le monde

Par : UnderNews
26 mars 2024 à 15:12

Les cybermenaces devenant de plus en plus fréquentes, sophistiquées et importantes, les conseils d’administration sont soumis à une pression croissante pour préserver les intérêts de leur organisation face à ces défis. Tribune – Pour les aider à identifier les points de vigilance et intérêts à développer une approche cyber, l’Institut Diligent et Bitsight ont entrepris de mieux […]

The post 10% des entreprises du CAC 40 ont engagé un cyber-expert, bien plus que leurs homologues dans le monde first appeared on UnderNews.

Le pack anti-cambriolage de Free et Qiara est-il vraiment une bonne affaire ?

26 mars 2024 à 12:41

Pour 249 euros (199 euros pour les abonnés Freebox), Qiara propose cinq équipements domotiques pour protéger sa maison. S'ajoute au matériel un abonnement optionnel (de 0 à 19,99 euros par mois), pour bénéficier d'un service de télésurveillance 24/7 en cas d'urgence. Est-ce aussi disruptif que ce que Free prétend ?

Comment activer BitLocker sur Windows 10 Famille ?

Par : Le Crabe
26 mars 2024 à 09:50
Excellente nouvelle ! Il est possible d’activer BitLocker sur toutes les éditions de Windows 10. Alors, certes pour l’édition Famille, il s’agit d’une version allégée du logiciel de chiffrement BitLocker appelée Chiffrement de l’appareil. Mais, elle permet déjà de crypter efficacement le disque système. C’est donc une excellente protection contre le vol de données et les … Lire la suite

Source

Construire une entreprise cyber-résiliente de la prévention à la récupération

Par : UnderNews
26 mars 2024 à 10:26

À l’ère de la numérisation accélérée, les entreprises font face à des défis sans précédent en matière de cyber-résilience, s’efforçant de protéger leurs données contre une marée montante d’attaques informatiques sophistiquées. Tribune OpenText Cybersecurity – La cybercriminalité est en hausse. Le nombre d’attaques par ransomware a augmenté de 18 %, tandis que le volume mondial […]

The post Construire une entreprise cyber-résiliente de la prévention à la récupération first appeared on UnderNews.

La checklist ultime pour sécuriser du mieux possible votre vie numérique

Par : Korben
26 mars 2024 à 09:00

Ê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

Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast

26 mars 2024 à 08:00

I. Présentation

Dans cet article, nous allons comprendre, exploiter et corriger une vulnérabilité fréquente sur les environnements Active Directory : ASREPRoast.

Ce nom ne vous dit peut-être rien, mais il s'agit d'un défaut de configuration fréquent dans l'Active Directory. L'attaque ASREPRoast permet à un attaquant situé sur un réseau d'entreprise possédant un domaine de compromettre rapidement un compte utilisateur, et ainsi de passer d'un mode opératoire boite noire (attaque sans identifiants valides, juste une connexion au réseau) à un mode boite grise (attaque depuis un compte valide sur le domaine). Le passage d'un mode boite noire à boite grise change en général la donne de façon très importante lors d'une cyberattaque, car l'accès authentifié au domaine permet d'en extraire beaucoup d'informations.

L'objectif de cet article est de vous expliquer en détail cette vulnérabilité. Nous allons notamment voir comment elle peut être introduite sur un Active Directory, comment un attaquant peut l'exploiter et comment un défenseur peut l'identifier et la corriger.

C'est parti !

II. Qu'est-ce que l'attaque ASREPRoast ?

A. Dans les grandes lignes

Commençons par essayer de comprendre le nom de l'attaque. "ASREP" fait référence au message "KRB-AS-REP" du service Kerberos lors d'une authentification (réponse à un message KRB-AS-REQ, une requête d'authentification Kerberos). "Roast" renvoi simplement au mot "rôtir" ou "cuisiner" car l'on devra ensuite travailler un peu sur la donnée obtenue pour pouvoir l'utiliser.

Au sein d'un domaine, l'authentification Kerberos est assurée par le composant Key Distribution Center (KDC) des contrôleurs de domaine. Lorsqu'un utilisateur souhaite accéder à un service ou à une ressource réseau, il doit d'abord obtenir un Ticket Granting Ticket (TGT) auprès du KDC. Pour cela, l'utilisateur envoie une requête de type "KRB-AS-REQ" (Kerberos Authentication Service Request) au KDC, elle contient notamment des informations d'identification de l'utilisateur et une clé liée à son mot de passe.

Le KDC vérifie alors les informations d'identification fournies par l'utilisateur. Si celles-ci sont correctes et que l'utilisateur existe dans le domaine, le KDC lui délivre un TGT. Ce TGT est ensuite utilisé par l'utilisateur pour obtenir des tickets de session (TGS) auprès des services du domaine, lui permettant d'accéder à ceux-ci sans avoir à fournir à nouveau ses informations d'identification. Ce processus s'appelle pre-authentification.

Schéma d'une authentification Kerberos et de l'émission d'un TGT.
Schéma d'une authentification Kerberos et de l'émission d'un TGT.

Cependant, il existe une configuration spécifique représentée par un attribut sur les comptes utilisateurs appelé "Do not require Kerberos preauthentication". Cet attribut autorise l'envoi d'un TGT pour un compte sans que le demandeur n'ait prouvé son identité au préalable.

Schéma de l'émission d'un TGT pour un utilisteur ayant l'attribut "Do not require Kerberos preauthentication".
Schéma de l'émission d'un TGT pour un utilisteur ayant l'attribut "Do not require Kerberos preauthentication".

En conséquence, n'importe qui sur le réseau peut obtenir un TGT représentant ce compte utilisateur et tenter d'usurper son identité. Il est important de noter que le TGT obtenu ne peut être utilisé que si la personne qui le détient connaît le mot de passe du compte associé. Cependant, en cas d'utilisation d'un mot de passe faible, le contenu du TGT peut être utilisé pour retrouver le mot de passe du compte utilisateur.

Le TGT ne contient pas directement le mot de passe de l'utilisateur. Mais, il contient des informations chiffrées grâce au secret de l'utilisateur, qui sont utilisés pour prouver l'identité de l'utilisateur lorsqu'il demande des tickets de session ultérieurs. Ainsi, des "traces" du mot de passe s'y trouve, ce qui permet de tenter de casser le TGT pour retrouver le mot de passe en clair.

Cette attaque est très connue des attaquants, si bien qu'elle dispose de son propre TTP (Tactics, Technics and Procedures) dans le framework MITRE ATT&CK : T1558.004- Steal or Forge Kerberos Tickets: AS-REP Roasting.

B. Dans le détail

Regardons à présent dans le détail ce qu'il se passe lors d'une authentification via Kerberos. Pour cela, j'ai effectué une capture réseau des échanges dans différents cas de figures.

  • AS-REQ pour un login inexistant

Lorsqu'un utilisateur souhaite s'authentifier auprès du service Kerberos, le client envoi dans un premier temps un message de demande d'authentification ("KRB-AS-REQ"), voici à quoi il ressemble sur une capture réseau (cliquez sur l'image pour zoomer) :

"AS-REQ" suivi d'une erreur "ERR_C_PRINCIPAL_UNKNOWN".
"AS-REQ" suivi d'une erreur "ERR_C_PRINCIPAL_UNKNOWN".

Dans le cas d'une demande d'authentification avec un login incorrect, c'est-à-dire qui n'existe pas dans l'Active Directory, le service Kerberos renvoi un message de type "KRB-ERROR : C-PRINCIPAL-UNKNOWN" en réponse à l'AS-REQ" du client. Le message est clair : l'utilisateur "MMARTIN1" n'existe pas dans l'Active Directory.

  • AS-REQ pour un login existant avec pré-authentification

Si le login est correct, le service renvoi une réponse de type "KRB-ERROR : PREAUTH REQUIRED". Cette réponse du service Kerberos indique que pour obtenir un TGT pour cet utilisateur, il faut au préalable s'authentifier, ce qui est plutôt une bonne nouvelle d'un point de vue sécurité. Rappelons que les TGT sont des tickets qui permettent de demander des TGS (Ticket Granting Service) pour accéder à un service au nom de l'utilisateur présenté dans le ticket. Il est donc préférable de prouver son identité (s'authentifier) au préalable.

À noter que cette différence de comportement dans la réponse du service ("PRINCIPAL_UNKNOWN "ou "PREAUTH REQUIRED") permet une énumération des utilisateurs basée sur un dictionnaire. Sans même connaitre le mot de passe associé à un compte, on peut savoir s'il existe dans l'annuaire, car le service Kerberos nous indiquera clairement cette information dans sa réponse.

Voici à quoi rassemble une réponse "PREAUTH_REQUIRED". Suite à cette réponse, notre client s'authentifie envoyant un message "AS-REQ", encore ? (cliquez sur l'image pour zoomer) :

Réponse "ERR_PREAUTH_REQUIRED" indiquant que le compte utilisateur existe dans l'annuaire.
Réponse "ERR_PREAUTH_REQUIRED" indiquant que le compte utilisateur existe dans l'annuaire.

Ce second message "AS-REQ" contient cependant un nouvel item, il s'agit d'une donnée chiffrée à l'aide d'une clé liée au mot de passe utilisateur. Si le service Kerberos parvient à déchiffrer ce message avec le mot de passe de l'utilisateur (qu'il possède de son côté grâce à l'annuaire et sa base NTDS.DIT) alors, il aura la preuve qu'il s'agit du bon mot de passe, et donc du vrai utilisateur. Tout cela sans que le mot de passe n'ait transité en clair sur le réseau. Pour plus de détails, sachez que la donnée chiffrée est un timestamp : c'est-à-dire la date et l'heure actuelle dans un format précis (notez le "pA-ENC-TIMESTAMP" dans la seconde AS-REQ).

Enfin, si les identifiants sont corrects, le service envoi un message de réponse "AS-REP" contenant notamment un TGT, qui permet de demander ensuite des TGS (cliquez sur l'image pour zoomer) à différents services :

Transmission d'un TGT par le service Keberos suite à une authentification réussie.
Transmission d'un TGT par le service Keberos suite à une authentification réussie.

Voilà à quoi ressemble une authentification "classique" via Kerberos en vue d'obtenir un TGT.

  • AS-REQ pour un login existant sans pré-authentification

Cependant, Microsoft a ajouté un attribut aux objets utilisateur qui permet d'autoriser le service Kerberos à fournir un TGT à quiconque le demande, sans authentification : l'attribut "Do not require Kerberos preauthentication". Dans ce cas, un attaquant peut demander un TGT pour un tel compte sans avoir besoin de fournir de preuve d'identité valide. Voilà alors ce qu'il se passe (cliquez sur l'image pour zoomer) :

Obtention d'un TGT sans authentification préalable pour un utilisateur ayant l'attribut "No preauthentication required".
Obtention d'un TGT sans authentification préalable pour un utilisateur ayant l'attribut "No preauthentication required".

Une "AS-REQ", demandant un TGT pour l'utilisateur "RDUBOIS", puis une "AS-REP" du KDC délivrant TGT, le tout sans preuve d'identité (authentification). N'importe qui peut donc usurper l'identité de l'utilisateur "RDUBOIS" en demandant un TGT à son nom, puis utiliser ce TGT pour demander des TGS aux services du domaine et y accéder.

Pour être plus précis, rappelons que le TGT obtenu dans les messages "AS-REP" est chiffré et ne peut être utilisé sans connaître le mot de passe du compte utilisateur. Cependant, étant donné qu'il est chiffré avec un dérivé du mot de passe utilisateur, l'attaquant pourra tenter de casser ce mot de passe en Offline (localement, sans interactions supplémentaires avec le KDC ou le domaine), pour retrouver le mot de passe de l'utilisateur.

En résumé, quand cet attribut est présent sur un compte utilisateur, n'importe qui peut obtenir une donnée (le TGT) qui utilise un dérivé du mot de passe du compte utilisateur, et donc tenter de retrouver le mot de passe en clair. Même en étant confiant sur l'algorithme de chiffrement et la robustesse du mot de passe utilisé, reconnaissons qu'il est plutôt périlleux de fournir ce genre d'informations à un simple visiteur non authentifié sur notre système d'information.

J'espère que cette vue en détail des échanges Kerberos vous aura permis de mieux comprendre le fonctionnement de l'attaque ASREPRoast.

C. Pourquoi cet attribut ?

Certaines applications ne prennent pas en charge la pré-authentification Kerberos, il est ainsi courant de trouver des utilisateurs avec la pré-authentification Kerberos désactivée, permettant ainsi aux attaquants de demander des TGT pour ces utilisateurs. C'est la raison principale de l'existence de ce paramètre d'après la documentation Microsoft. La pré-authentification Kerberos peut également être désactivée pour d'autres raisons liées à des besoins spécifiques de sécurité ou de compatibilité avec d'autres systèmes.

Dans la réalité, il n'est pas rare de trouver de tels comptes, notamment sur des systèmes d'information qui ont un certain historique...

III. Configuration d'un Lab vulnérable

Attention, dans ce chapitre, nous allons configurer de manière volontaire un Lab vulnérable pour vous exposer le but et le fonctionnement de l'attaque.

NE PAS REPRODUIRE SUR UN ENVIRONNEMENT DE PRODUCTION.

Dans mon Lab de démonstration, j'ouvre la console "Utilisateurs et ordinateurs Active Directory", puis je sélectionne un de mes utilisateurs, ici l'utilisateur "RDUBOIS". Il faut ensuite faire un clic droit "Propriétés" sur cet objet et se rendre dans "Compte" :

Configuration de l'attribut "Do not require Kerberos preauthentication" sur un compte utilisateur.
Configuration de l'attribut "Do not require Kerberos preauthentication" sur un compte utilisateur.

Dans les "Options de compte", il faut trouver et cocher "La pré-authentification Kerberos n'est pas nécessaire" comme sur l'image ci-dessus.

Si vous vous souvenez des explications précédentes, l'attaque ASREPROAST est d'autant plus dangereuse si le mot de passe utilisé est faible, pour avoir un cas d'école, nous allons paramétrer le mot de passe de l'utilisateur "RDUBOIS" à "#1p@ssword" (ce n'est pas un mot de passe faible ? Vous allez voir que si 🙂 ). Il faut à nouveau faire un clic droit sur l'objet puis "Réinitialiser le mot de passe" :

Paramétrage d'un mot de passe faible sur le compte utilisateur.
Paramétrage d'un mot de passe faible sur le compte utilisateur.

Voilà, notre Lab d'entrainement est prêt !

IV. Point de vue de l'attaquant

Soyez vigilant à n'exploiter ou même tenter de découvrir cette vulnérabilité que si vous y êtes autorisé. Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

A. Trouver une liste de noms

Vous l'aurez compris, pour effectuer une attaque ASREPRoast, il faut un login utilisateur à tester, voire plusieurs. Dans un premier temps, l'attaquant doit donc se constituer une liste de login (dictionnaire) qu'il soumettra ensuite au service Kerberos.

  • Dans le cas où l'attaquant n'est pas authentifié sur le domaine (boite noire) :

Si l'attaquant n'a pas de compte sur l'Active Directory, il peut utiliser différentes méthodes pour récupérer des logins valides. L'OSINT (Open Source Intelligence) est une méthode assez commune puisqu'avec quelques requêtes Google ou recherches Linkedin, on peut assez facilement retrouver une liste de personnes travaillant dans une entreprise. La recherche dans des fuites de données, basée sur le nom de l'entreprise ou l'adresse mail, est aussi fréquente.

Depuis l'intérieur du réseau (toujours sans compte valide sur le domaine), il existe un grand nombre de techniques également. Les imprimantes sont mon moyen favori, souvent mal protégées avec des interfaces d'administration exposées et verbeuses, elles stockent des carnets d'adresses qui exposent souvent des logins utilisateur. Les applications web internes, services SNMP, SMB et RPC mal configurés (authentification anonyme) ou même l'interception réseau sont également très efficaces.

Également, il est possible pour l'attaquant d'utiliser des dictionnaires pré-conçus utilisant des couples prénom-noms communs, voir des noms de comptes techniques comme "svc-ldap", "backup", "formation", "accueil", etc. Les dictionnaires que j'utilise souvent sont publics et fonctionnent en général très bien, bien qu'utilisant majoritairement des noms anglophones : https://github.com/insidetrust/statistically-likely-usernames.

Avec toutes ces méthodes, il est souvent très facile de se constituer une liste bien fournie de logins utilisateur potentiels. Il faut enfin savoir les formater grâce à la nomenclature actuelle de l'Active Directory ciblé : est-ce "marc.martin", marc_martin, "m.martin", "mmartin" ? etc.

  • Dans le cas où l'attaquant est authentifié sur le domaine (boite grise) :

Si l'attaquant possède déjà un compte sur le domaine, rien de plus facile. Une simple requête LDAP permettra de récupérer la totalité des logins utilisateur de l'annuaire, il aura alors une liste exhaustive des comptes à cibler, augmentant ses chances d'en trouver un avec l'attribut "Do not require Kerberos preauthentication".

Depuis Linux, une requête "ldapsearch" fera l'affaire :

ldapsearch -v -x -D "[email protected]" -W -b "DC=it-connect,DC=tech"  -H "ldap://ad01.it-connect.tech" "(&(objectClass=user))" sAMAccountName |grep "sAMAccountName:" |cut -d " " -f 2 > /tmp/userlist

J'utilise ici la commande "ldapsearch" pour récupérer les attributs "sAMAccountName" des utilisateurs du domaine, puis la commande "grep" pour isoler les lignes qui m'intéressent et enfin "cut" pour isoler uniquement le login de l'utilisateur. Si vous peinez à comprendre cette commande, n'hésitez pas à la décomposer dans votre environnement et à exécuter les commandes une à une. Le tout est enregistré dans le fichier "/tmp/userlist". Voici un exemple du résultat attendu :

Extraction des utilisateurs de l'Active Directory avec un compte valide sur le domaine via "ldapsearch".
Extraction des utilisateurs de l'Active Directory avec un compte valide sur le domaine via "ldapsearch".

Je me retrouve donc avec une liste de 1000 logins utilisateur valides dans le fichier "/tmp/userlist".

L'outil BloodHound va également récupérer la liste des utilisateurs pour les stocker dans un fichier JSON, qui pourra facilement être parcouru pour en extraire les logins. Je vous oriente sur mon cours sur BloodHound si vous souhaitez en savoir plus : Identifiez les faiblesses de votre Active Directory avec Bloodhound

Une fois cette liste, hypothétique, partielle ou complète à disposition, l'attaquant va pouvoir interroger sur le service Kerberos du domaine afin de voir si :

  • L'utilisateur existe dans l'annuaire;
  • Il dispose de l'attribut "Do not require Kerberos preauthentication".

B. Exploiter ASREPRoast depuis Linux

Depuis Linux, une multitude d'outils offensifs existent pour effectuer cette attaque. Je vais ici vous présenter les outils les plus classiques : "impacket" et "netexec".

Impacket est une bibliothèque Python utilisée pour interagir avec des protocoles de réseau tels que SMB, LDAP et Kerberos. Elle offre des outils pour la manipulation de paquets réseau, la création de serveurs et de clients pour ces protocoles, ainsi que des fonctionnalités avancées pour l'analyse et l'exploitation de vulnérabilités. Impacket est très largement utilisé pour les opérations offensives et de nombreux outils utilisent cette librairie.

En plus d'être une librairie très puissante, les créateurs d'Impacket fournissent des scripts qui l'utilisent afin d'automatiser certaines opérations et attaques, comme ASREPRoast. Je ne peux pas détailler ici la procédure d'installation de "Impacket" et de ses "examples scripts", je vous renvoie pour cela à la documentation officielle : Github - Impacket.

  • ASREPRoast en boite noire

Nous allons notamment utiliser le script "impacket-GetNPUsers" ("NP" pour "NoPreauth"). Dans le cas où nous sommes en boite noire, nous avons au préalable construit notre dictionnaire à partir de différentes sources. Nous pouvons utiliser ce dictionnaire pour réaliser une attaque ASREPRoast. Ici,"192.168.56.102" est l'adresse IP de mon contrôleur de domaine, qui héberge le service Kerberos (KDC)) :

impacket-GetNPUsers -usersfile /tmp/userlist -request -format hashcat -outputfile /tmp/IMPACKET_asreproast_blackbox.txt -dc-ip 192.168.56.102 'it-connect.tech/'

L'outil netexec (NXC), également très présent dans les opérations offensives, peut aussi être utilisé :

netexec ldap 192.168.56.102 -u /tmp/userlist -p '' -d it-connect.tech --asreproast /tmp/NXC-asreproast_blackbox.out
  • ASREPRoast en boite grise

Si l'on dispose d'un accès authentifié au domaine, encore mieux, "impacket-GetNPUsers" peut automatiser à la fois la récupération des utilisateurs dans la base LDAP, et l'envoi d'un "AS-REQ" en leur nom pour voir s'ils sont vulnérables à l'ASREPRoast :

impacket-GetNPUsers -request -format hashcat -outputfile ASREProastables.txt -dc-ip 192.168.56.102 'it-connect.tech/mmartin:MyPassword1!'  -outputfile /tmp/IMPACKET_asreproast_greybox.txt

Même principe pour "netexec", il suffira de spécifier l'utilisateur ("-u") et son mot de passe de ("-p") pour s'authentifier auprès du service LDAP afin de récupérer la liste des utilisateurs :

netexec ldap 192.168.56.102 -u mmartin -p 'MyPassword1!' --asreproast /tmp/NXC-asreproast_greybox.txt

Voici le résultat attendu pour "impacket-GetNPUsers" et "netexec" :

Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast.
Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast authentifiée.

On voit donc que plusieurs logins sont tentés sur le service Kerberos et que, pour certains, un hash au format "$krb5asrep$23$" est obtenu. Il s'agit d'une donnée extraite du TGT obtenu pour chaque utilisateur vulnérable, spécialement formaté pour être interprété par des outils de cassage de mot de passe.

Maintenant que nous avons ces hashs, nous pouvons tenter de les casser, par exemple, à l'aide de "JohnTheRipper" ou "hashcat" et de listes de mots de passe communs comme le dictionnaire de mot de passe "rockyou.txt" :

hashcat -m 18200 -a 0 ASREProastables.txt rockyou.txt
john --wordlist=rockyou.txt ASREProastables.txt

Ce cassage s'effectue totalement en local, sans interactions avec l'Active Directory ou le service Kerberos. Ainsi, aucune détection n'est possible. Également, l'utilisateur a ici tout son temps et la rapidité de l'opération dépendra de la robustesse du mot de passe et des ressources de calcul qu'il a à disposition. Si des mots de passe faibles ont été utilisés par les comptes utilisateurs vulnérables, ils seront retrouvés par ces outils :

Cassage du hash "krb5asrep" extrait du TGT de l'utilisateur obtenu via ASREPRoast.
Cassage du hash "krb5asrep" extrait du TGT de l'utilisateur obtenu via ASREPRoast.

Si les mots de passe sont très robustes, alors il faudra déployer des moyens considérables pour les casser. Ici, le mot de passe semble plutôt correct avec 3 alphabets et une longueur de 10 caractères, mais il se trouve dans le dictionnaire public et très connu "rockyou.txt". Nous venons de retrouver le mot de passe d'un utilisateur de l'Active Directory par l'intermédiaire d'un TGT signé grâce à un dérivé de son mot de passe par le service Kerberos.

C. Exploiter ASREPRoast depuis Windows

Sous Windows, l'outil le plus classique pour effectuer cette attaque est "Rubeus.exe", écrit en C#. Le plus simple est de l'exécuter sur une machine intégrée au domaine ou via un "runas.exe" :

.\Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast

Voici le résultat attendu :

Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.
Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.

Comme pour les outils Linux, le fichier "hashes.asreproast" contiendra les hashs contenus dans les TGT récupérés et pourra être passé à "hashcat" ou "JohnTheRipper" pour cassage.

V. Point de vue du défenseur

A. Lister les comptes utilisateurs avec preauth-notreq

Nous allons maintenant adopter le point de vue du défenseur ou blue team qui souhaite savoir si des utilisateurs vulnérables à ASREPROAST sont présents sur son domaine.

Lorsque nous sommes sur notre propre domaine et contrôleur de domaine, le plus simple est d'utiliser le module PowerShell "ActiveDirectory" qui permet de communiquer avec ADSI (Active Directory Services Interface). Nous pouvons notamment cibler l'attribut "useraccountcontrol" pour extraire les utilisateurs disposant de l'attribut "Do not require Kerberos preauthentication", exemple :

Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol | Format-Table name, DistinguisedName, Enabled

Voici le résultat attendu :

Nous avons la même liste utilisateur qu'obtenue via notre requête "ldapsearch" bien entendu, avec un filtre sur ceux qui ont déjà l'attribut "Do not require Kerberos authentication", mais nous utilisons ici des outils légitimes et plus accessibles pour les administrateurs système. J'ai notamment ajouté le "DN" et l'attribut "Enabled" en sortie de la commande (via le "Format-Table" ou "ft").

B. Corriger les comptes vulnérables

Une fois cette liste à disposition, il convient tout d'abord de déterminer :

  • Pourquoi ils sont/ont été utilisés, pour quels besoins, services et systèmes ?
  • Est-ce ce qu'ils sont toujours utilisés aujourd'hui ? (date de dernière authentification, dernier changement de mot de passe, journaux d'évènements)
  • Est-ce que l'attribut "Do not require Kerberos authentication" est vraiment utile et répond à un besoin fonctionnel ?

Une fois que ces questions ont toutes une réponse claire pour chaque compte, la décision de désactiver cet attribut peut être prise.

  • Corriger ASREPRoast via l'interface graphique

Depuis la console "Utilisateurs et ordinateurs Active Directory", effectuez un clic droit sur le compte utilisateur concerné, puis "Propriétés. Il faut ensuite se rendre dans "Compte" et localiser l'option suivante :

Désactivation de l'attribut "Do not require Kerberos preauthentication" sur l'Active Directory.
Désactivation de l'attribut "Do not require Kerberos preauthentication" sur l'Active Directory.

Une fois décochée, nous pouvons appliquer nos changements. La modification prend effet immédiatement.

  • Corriger ASPREPRoast via Powershell

Il est aussi possible de modifier la valeur de cet attribut en PowerShell via ADSI. Le cmdlet "Set-ADAccountControl" est fournie par le module PowerShell "ActiveDirectory" :

PS C:\> Set-ADAccountControl -Identity rdubois -DoesNotRequirePreAuth $false

À nouveau, la modification est prise en compte immédiatement.

  • Mesure complémentaire en cas de besoin fonctionnel

Si l'attribut "Do not require Kerberos preauthentication" est nécessaire et répond à un besoin identifié et justifié, alors il convient de mettre un mot de passe très, très robuste à ce compte. L'idée est que même si un TGT est récupéré, l'attaquant ne puisse pas casser le hash qu'il contient en vue de récupérer le mot de passe en clair de l'utilisateur. Optez donc pour un mot de passe à plus de 30 caractères.

Dans l'idéal, il est également nécessaire de prévoir un renouvellement périodique de ces mots de passe afin de réduire leur exposition dans le temps. Si l'attaquant dispose de tout le temps disponible devant lui pour casser le hash contenu dans le TGT, alors il finira peut-être par y arriver (peut-être au bout de plusieurs années). Mais si le mot de passe du compte est changé tous les six mois, il n'aura potentiellement pas le temps de l'exploiter une fois qu'il l'aura cassé. Il s'agit d'une mesure de sécurité supplémentaire.

  • Limiter la propagation suite à une compromission

Il convient également de s'assurer que le compte qui dispose légitimement de l'attribut "Dot not require Kerberos preauthentication" possède des droits limités sur le domaine et le système d'information. La revue des ACL, appartenances aux groupes et l'application du principe de moindre privilège (configuration fine et minimaliste des droits pour répondre uniquement aux fonctions métiers) permettra de limiter au maximum les actions possibles de l'attaquant en cas de compromission du compte.

  • Changement de mot de passe

Enfin, il est à noter que si le compte a eu jusque-là cet attribut, n'importe quel utilisateur de votre domaine a peut être déjà récupéré un TGT et obtenu son mot de passe, ou est en train de tenter de le casser. Ces mesures de correction doivent donc s'accompagner d'un changement de mot de passe afin qu'un attaquant exploitant ou ayant exploité cette faiblesse ne puisse pas réutiliser le mot de passe compromis pour ce compte, ce qui sera possible même si l'attribut en question a été décoché.

C. Détecter une attaque ASREPRoast

Du point de vue du défenseur, nous allons également nous intéresser aux possibilités de détection d'une attaque ASREPRoast passée ou en cours sur le système d'information.

  • Détection via les journaux d'évènements

L'exploitation de l'ASREPRoast génère, comme toute interaction avec l'Active Directory, des évènements. Cependant, il n'est pas aisé de les distinguer clairement des activités légitimes et quotidiennes des utilisateurs du domaine. Il faut savoir que lorsqu'un "AS-REQ" est effectué sur un compte non vulnérable à l'ASREPRoast (et donc, échoue), aucun évènement de sécurité n'est généré. Seule l'émission d'un ticket Kerberos génère un évènement avec l'eventID 4768.

L'event ID 4768 est enregistré sur le contrôleur de domaine chaque fois qu'un TGT est émis. Il indique que le KDC a reçu une demande de TGT (AS-REQ) et qu'il a émis un TGT en réponse. L'évènement journalisé contient alors quelques détails intéressants sur la demande.

https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768

Cet évènement apparait donc si :

  • La requête est émise avec une authentification valide, auquel cas un TGT est émis en réponse à l'"AS-REQ".
  • La requête porte sur un utilisateur ayant l'attribut "Do not require Kerberos authentication", auquel cas pas besoin d'authentification, le TGT est tout de même émis en réponse à l'"AS-REQ".

Voici l'évènement tel qu'il apparaitra dans l'observateur d'évènement lors d'une demande de TGT classique, avec authentification (utilisation ici de "impacket-getTGT") :

EventID 4768 suite à une demande et émission de TGT classique, avec authentification.
EventID 4768 suite à une demande et émission de TGT classique, avec authentification.

On voit clairement qu'un TGT a été demandé et émis pour l'utilisateur "IT-CONNECT\mmartin" par le client "192.168.56.104". Nous allons également garder dans un coin de notre mémoire les informations relatives au "Type de pré-authentification" et "Type de chiffrement du ticket". Je réalise maintenant la même opération à destination du compte "IT-CONNECT\rdubois" et avec un outil offensif qui va directement demander un TGT sans authentification préalable (utilisation de "netexec") :

EventID 4768 suite à une demande et émission de TGT à la suite d'une attaque ASREPROast via "netexec"
EventID 4768 suite à une demande et émission de TGT à la suite d'une attaque ASREPROast via "netexec".

Les informations journalisées sont globalement les mêmes lors d'une demande et émission d'un TGT sur un compte ne nécessitant pas la pré-authentification. Cependant, on peut noter deux exceptions (à noter que le résultat est le même lors d'une exploitation avec "impacket-getNPUsers") :

  • Le "Type de chiffrement du ticket" est passé à "0x17" au lieu de "0x12".
  • Le "Type de pré-authentification" est passé à "0" au lieu de "2".

L'utilisation d'un chiffrement à "0x17" (RC4-HMAC) est un comportement typique des outils d'attaque qui downgrade (abaissent) le niveau de chiffrement utilisé pour le chiffrement du TGT afin de rendre le cassage de son contenu plus aisé. Par défaut, le niveau de chiffrement "0x12" entraine l'utilisation du AES256-CTS-HMAC-SHA1-96 (Source : 4768(S, F): A Kerberos authentication ticket (TGT) was requested). Voilà un premier élément caractéristique d'une attaque ASREPRoast avec des méthodes et outils classiques.

Egalement, la documentation Microsoft est limpide concernant les valeurs du "Type de pré-authentification" :

La demande de TGT avec une valeur "0" à "Type de pré-authentification" est donc également un signal intéressant à surveiller. Pour finir sur cette détection, je vous propose une requête KQL (pour ELK) qui permet d'identifier les événements de demande/émission d'un TGT avec un chiffrement faible (RC4) ou sans pré-authentification :

event.code:4768 AND (winlog.event_data.TicketEncryptionType: 0x17 OR winlog.event_data.PreAuthType: 0)

Pour détailler un peu la requête. Il s'agit d'un filtre sur les évènements Windows ayant un évènement ID 4768 et qui ont, soit un "TicketEncryptionType" à "0x17" (RC4), soit un "PreAuthType" à "0". Voici le résultat sur l'ELK de mon lab (avec moins d'activité qu'un vrai SI, bien sûr) :

Visualisation dans ELK des évèenemtn caractértistique d'une attaque ASREPRoast

Pas de doute, il y a eu une activité suspecte sur mon SI entre 17h45 et 18h15, des TGT sans pre-authentification et avec un algorithme de chiffrement faible ont été demandés.

Surveiller les modifications des attributs utilisateurs

Pour aller plus loin, vous pouvez également chercher et surveiller les event ID 4738 (A user account was changed) et 5136 (A directory service object was modified) qui apparaissent lorsqu'un attribut utilisateur est modifié :

Journalisation de la modification d'un attribut utilisateur via l'eventID 4738.
Journalisation de la modification d'un attribut utilisateur via l'eventID 4738.

Plutôt que la compromission, vous visualiserez alors tous les évènements d'activation/désactivation de l'attribut concerné sur des comptes utilisateurs, ce qui permettra de retrouver le moment où la vulnérabilité a été introduite sur le compte concerné. Là aussi, il faudra aller plus loin pour réellement identifier le nom de l'attribut modifié et s'assurer de n'obtenir que les alertes relatives à l'attribut "Do not require Kerberos preauthentication". Egalement, voici un exemple de requête filtre KQL pour cet évènement :

event.code:4738 AND winlog.event_data.UserAccountControl:*2096*

Voici l'aperçu d'un tel évènement dans la console ElasticSearch :

Visualisation de l'eventID 4738 relatif à l'ajout de l'attribut "Do not requiere kebreroas pre-authentication" dans ElasticSearch.
Visualisation de l'eventID 4738 relatif à l'ajout de l'attribut "Do not requiere kebreroas pre-authentication" dans ElasticSearch.
  • Utilisation d'un honey account

Si vous maitrisez correctement la sécurité de votre système d'information, notamment avec un SIEM et un SOC (Security Operation Center) efficaces, alors vous pouvez envisager la mise en place d'un honey account, ou "compte pot de miel". L'idée est de créer un compte utilisateur volontairement vulnérable à ASREPRoast afin que sa compromission génère un évènement de sécurité activement surveillé par la blue team.

Pour cela, il faut notamment être sûr que ce compte ne sera jamais utilisé de façon légitime par un utilisateur ou un service du SI. Ainsi, si une demande de TGT pour ce compte spécifique apparait dans les journaux d'évènement, ce sera forcément dû à une attaque ASREPRoast en cours.

Attention : La création et la gestion d'un compte pot de miel nécessitent une attention particulière. Il faut s'assurer que les politiques de sécurité et les procédures de surveillance sont bien établies pour garantir que le compte reste contrôlé et qu'il ne devienne pas une vulnérabilité supplémentaire. Il faut notamment s'assurer que l'honey account ait un mot de passe très robuste afin que le hash contenu dans son TGT ne soit jamais cassé, ce qui permettrait à l'attaquant d'obtenir un compte valide sur le domaine.

VI. Conclusion

J'espère que cet article vous a plu et que vous avez maintenant une meilleure idée des risques liés à cette attaque et de la façon de s'en protéger. J'ai essayé de faire en sorte qu'il soit complet en abordant le point de vue des attaquants comme des défenseurs.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

The post Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast first appeared on IT-Connect.

Phishing : plus de 100 organisations en Europe et aux États-Unis impactées par StrelaStealer

26 mars 2024 à 06:10

Une centaine d'organisations situées aux États-Unis et en Europe ont été victime d'une nouvelle campagne malveillante visant à déployer le malware StrelaStealer ! Voici ce qu'il faut savoir sur cette menace.

L'Unit42 de Palo Alto Networks a publié un rapport au sujet de la menace StrelaStealer, un logiciel malveillant repéré pour la première fois en novembre 2022. Après avoir infecté une machine, son objectif est de voler les informations d'identification des comptes de messagerie dans les applications Outlook et Thunderbird.

Alors qu'à la base ce malware ciblait principalement les utilisateurs hispanophones, il s'avère que les cybercriminels ont fait évoluer leur plan : désormais l'Europe et les États-Unis sont pris pour cible. Pour cela, les pirates n'hésitent pas à traduire en plusieurs langues les fichiers utilisés par ce malware, ce qui le rend polyglotte et lui permet de s'adapter à la cible.

Comme beaucoup d'autres logiciels malveillants, StrelaStealer est distribué par l'intermédiaire de phishing. Depuis la fin du mois de janvier, l'Unit42 a détecté une forte hausse de l'activité avec un important volume d'e-mails malveillants envoyés par jour. L'Unit42 évoque jusqu'à 500 organisations ciblées par jour et il y a eu des victimes : "Récemment, nos chercheurs ont identifié une vague de campagnes StrelaStealer à grande échelle touchant plus de 100 organisations dans l'UE et aux États-Unis.", peut-on lire dans le rapport. Dans la grande majorité des cas, ce sont les organisations du secteur des nouvelles technologies qui ont été les plus visées.

Source : Unit42

La chaine d'infection de StrelaStealer

Les pirates ont fait évoluer la chaine d'infection du malware StrelaStealer. Désormais, l'e-mail malveillant contient une pièce jointe au format ZIP qui a pour objectif de déposer des fichiers JScript sur la machine de la victime. Dans le cas où ces scripts sont exécutés, ils déposent un fichier batch et un fichier encodé en base64, qui donne lieu à une DLL qui sera exécutée via rundll32.exe afin de déployer le payload StrelaStealer.

Le schéma ci-dessous, issu du rapport d'Unit42 permet de comparer l'ancienne et la nouvelle chaine d'infection.

Source : Unit42

Si le logiciel malveillant est déployé, il vole les identifiants mémorisés dans Outlook et Thunderbird et ces informations sont immédiatement envoyées aux attaquants par l'intermédiaire d'un serveur C2.

Une fois de plus, méfiance avec les e-mails...

Source

The post Phishing : plus de 100 organisations en Europe et aux États-Unis impactées par StrelaStealer first appeared on IT-Connect.

Une nouvelle technique permet de bloquer les bloqueurs de pubs sans JavaScript

Par : Korben
26 mars 2024 à 06:02

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.

❌
❌