Performance et sécurité, simplement.

Blog
Doc
Portail

Catégorie : Sécurité

  • Symfony : 8 nouvelles failles de sécurité découvertes – Analyse et recommandations

    Symfony : 8 nouvelles failles de sécurité découvertes – Analyse et recommandations

    Après un an sans faille, Symfony a dévoilé ce 6 novembre 2024 sur son blog huit vulnérabilités d’un coup. Elles affectent différentes versions du framework Symfony. Voici un résumé de ces failles critiques, leurs impacts potentiels, ainsi que les solutions mises en place par Symfony. De quoi comprendre les implications de ces vulnérabilités pour sécuriser vos applications.

    Introduction

    Même les frameworks les plus réputés comme Symfony ne sont jamais à l’abri de failles de sécurité. Quelle que soit la solution applicative retenue, la vigilance est de mise. Des sécurités comme un pare-feu applicatif ModSecurity ainsi que le blocage automatique des attaquants (fail2ban), combiné à une bonne politique de sauvegarde externalisée, sont indispensables.

    Sur les hébergements web sécurisés LRob, nos serveurs Linux aident à votre sécurité applicative grâce à ModSecurity combiné à fail2ban qui bloquent activement les tentatives d’exploitation des failles; des sauvegardes externalisées complètes sont faites chaque jour avec une rétention d’un an. Choisir LRob comme hébergeur, c’est profiter d’une solution d’hébergement simple et sécurisée tout en ajoutant un sysadmin rigoureux, disponible et passionné à votre équipe !

    Failles de sécurité Symfony (novembre 2024)

    CVE-2024-51736 : Détournement d’exécution de commande sur Windows avec la classe Process

    Versions concernées
    Symfony versions <5.4.46; >=6, <6.4.14; >=7, <7.1.7.

    Description
    Cette faille permet un détournement d’exécution sur les systèmes Windows lorsque le fichier exécutable cmd.exe se trouve dans le répertoire de travail actuel. La classe Process pourrait alors exécuter ce fichier, ouvrant la voie à des détournements malveillants.

    Résolution
    Symfony a corrigé ce problème en forçant la classe Process à utiliser le chemin absolu vers cmd.exe.

    Voir l’article officiel de Symfony.

    CVE-2024-50341 : La méthode Security::login ignore le user_checker personnalisé

    Versions concernées
    Symfony versions >=6.2, <6.4.10; >=7.0, <7.0.10; >=7.1, <7.1.3.

    Description
    La méthode Security::login de Symfony ne prenait pas en compte le user_checker personnalisé, ce qui pouvait permettre des connexions non désirées.

    Résolution
    Le correctif implémente désormais un appel au user_checker configuré.

    Voir l’article officiel de Symfony.

    CVE-2024-50340 : Changement d’environnement via une requête

    Versions concernées
    Symfony versions <5.4.46; >=6, <6.4.14; >=7, <7.1.7.

    Description
    En manipulant une chaîne de requête spécifique, des utilisateurs peuvent changer l’environnement ou le mode de débogage du noyau lorsqu’une directive PHP register_argc_argv est activée.

    Résolution
    Le composant SymfonyRuntime ignore désormais les valeurs d’argv pour les environnements non CLI.

    Voir l’article officiel de Symfony.

    CVE-2024-50342 : Énumération d’adresses et de ports internes via NoPrivateNetworkHttpClient

    Versions concernées
    Symfony versions <5.4.46; >=6, <6.4.14; >=7, <7.1.7.

    Description
    Avec NoPrivateNetworkHttpClient, certaines informations internes pouvaient encore être exposées, permettant ainsi une énumération d’adresses IP et de ports.

    Résolution
    Le client NoPrivateNetworkHttpClient applique désormais un filtrage des IP bloquées dès le début de la résolution des hôtes.

    Voir l’article officiel de Symfony.

    CVE-2024-50343 : Réponse incorrecte du Validator avec une entrée se terminant par \n

    Versions concernées
    Symfony versions <5.4.43; >=6, <6.4.11; >=7, <7.1.4.

    Description
    Une validation utilisant une expression régulière pouvait être contournée en introduisant un caractère \n en fin d’entrée, ce qui entraînait une réponse incorrecte de la part du Validator.

    Résolution
    Symfony utilise désormais le modificateur regex D pour garantir une validation de toute l’entrée.

    Voir l’article officiel de Symfony.

    CVE-2024-50345 : Redirection ouverte via des URLs « sanitisées » par le navigateur

    Versions concernées
    Symfony versions <5.4.46; >=6, <6.4.14; >=7, <7.1.7.

    Description
    En exploitant des caractères spéciaux dans une URL, un attaquant pouvait détourner une redirection basée sur la classe Request pour envoyer les utilisateurs vers un autre domaine.

    Résolution
    La méthode Request::create vérifie désormais que les URI ne contiennent pas de caractères invalides.

    Voir l’article officiel de Symfony.

    Twig CVE-2024-51754 : Appels non protégés à __toString() dans un sandbox

    Versions concernées
    Twig versions <3.11.2; >=3.12, <3.14.1.

    Description
    Dans un environnement sandbox, un attaquant pouvait appeler la méthode __toString() d’un objet, même si cette méthode n’était pas autorisée par la politique de sécurité, ouvrant la porte à un contournement des restrictions du sandbox.

    Résolution
    Le mode sandbox vérifie désormais systématiquement l’appel à __toString() sur tous les objets.

    Voir l’article officiel de Symfony.

    Twig CVE-2024-51755 : Appels non protégés à __isset() et aux accès d’objets de type Array dans un sandbox

    Versions concernées
    Twig versions <3.11.2; >=3.12, <3.14.1.

    Description
    Dans un environnement sandbox, des objets ressemblant à des tableaux pouvaient exposer des attributs sans contrôle de sécurité. Cela permettait à un attaquant d’accéder à des propriétés potentiellement sensibles.

    Résolution
    Le mode sandbox contrôle désormais les propriétés des objets de type Array et l’appel à __isset() après vérification de sécurité.

    Voir l’article officiel de Symfony.

    Conclusion et recommandations de LRob

    Ces huit failles montrent que même les frameworks les plus robustes comme Symfony ne sont pas à l’abri de vulnérabilités de sécurité. Heureusement, l’équipe Symfony a réagi rapidement pour fournir des correctifs. Et comme il se doit, les failles n’ont été rendues publiques qu’après leur correctif. Si vous utilisez Symfony, assurez-vous de mettre à jour dès que possible pour protéger vos applications et vos utilisateurs.

    N’oubliez jamais qu’aucune solution logicielle n’est exempte de failles de sécurité. Votre vigilance doit être continue et les mise à jour régulières restent la meilleure ligne de défense face aux failles de sécurité et aux cybermenaces.

    Chez LRob, nos serveurs offrent une sécurité optimale :

    • Pas de faille Windows : Nos serveurs étant sous Linux, ils ne sont pas affectés par les failles spécifiques à Windows.
    • Mise à jour applicatif serveur : Les logiciels serveur sont mis à jour quotidiennement et monitorés en 24/7.
    • Pare-feu ModSecurity : En filtrant activement les requêtes malveillantes, notre pare-feu protège vos applications.
    • Sauvegardes externalisées : Nous disposons de sauvegardes externalisées quotidiennes pour faciliter la récupération de données en cas d’incident, et vous pouvez aussi réaliser vos propres sauvegardes vers le FTP de votre choix (par exemple via un VPS Storage Cloud de PulseHeberg) via Plesk.
    Contactez-nous pour plus d’informations
    Choisissez votre hébergement LRob
  • LRob contribue désormais au reporting des IP malveillantes avec AbuseIPDB

    LRob contribue désormais au reporting des IP malveillantes avec AbuseIPDB

    Depuis longtemps, je cherchais un moyen d’exploiter efficacement les données de hacking bloquées par mes serveurs. Les tentatives d’intrusion sont permanentes, mais grâce à des systèmes de sécurité tels que Fail2ban, les attaques sont stoppées avant de causer des dommages. Cependant, au-delà de la simple protection de mes systèmes et clients, je souhaitais aller plus loin : partager ces informations et rendre l’internet plus sécurisé pour tous.

    Déjà plus de 2000 IP malveillantes reportées en seulement 48 heures !

    C’est dans cette optique que LRob a commencé à contribuer au reporting des attaquants via AbuseIPDB, une plateforme qui permet à chacun de signaler des IP malveillantes. En seulement 48 heures, plus de 2000 IP ont déjà été signalées, ce qui montre à quel point cette initiative peut avoir un impact significatif.

    AbuseIPDB Contributor Badge

    Pourquoi reporter les IP malveillantes ?

    Les hackers attaquent tout, tout le temps. Que vous soyez une petite entreprise, un particulier ou une grande organisation, vous êtes une cible. Toutefois, même si ces attaques sont incessantes, les ressources des cybercriminels sont limitées. En les identifiant, nous avons une chance de mieux les combattre et de limiter leurs capacités d’action.

    Il y a deux principales raisons pour lesquelles reporter les IP malveillantes est crucial :

    1. Identifier et bloquer les attaquants : En reportant ces IP, vous contribuez à la création d’une base de données accessible à tous, facilitant ainsi le blocage de menaces potentielles avant qu’elles n’atteignent d’autres infrastructures.
    2. Informer les hôtes légitimes : Certains hôtes légitimes peuvent être infectés ou détournés à leur insu, servant alors de relais pour des attaques. En signalant ces IP, vous leur donnez une chance de réagir et de corriger la situation.

    Le partage d’informations via des plateformes telles qu’AbuseIPDB permet de rendre le web plus sûr, non seulement pour vous, mais aussi pour toute la communauté.

    Une API simple pour un reporting efficace

    L’une des grandes forces d’AbuseIPDB est sa simplicité d’utilisation. Via une API accessible à tous, il devient très facile de contribuer au signalement des IP malveillantes. En validant votre identité, vous pouvez même augmenter la limite des signalements à 5000 IP par jour, ce qui permet de couvrir un plus large spectre d’attaques.

    J’ai donc décidé de mettre en place un système pour automatiser ces reports, et ainsi faire profiter la communauté de mes données de hacks bloqués. Une bannière est désormais visible en bas de mon site LRob.fr, renvoyant directement vers mon profil AbuseIPDB, où chacun peut voir les IP que j’ai signalées (voir mon profil ici).

    Automatisation du reporting avec Plesk et Fail2ban

    Pour ceux qui, comme LRob, utilisent Plesk pour gérer leurs serveurs, j’ai développé un script permettant de reporter automatiquement les IP malveillantes via l’API d’AbuseIPDB en utilisant les jails de Fail2ban.

    Ce script est librement disponible sur GitHub et peut être utilisé par tout sysadmin souhaitant automatiser ce processus. Il suffit de configurer votre clé API et vous êtes prêt à commencer !

    Vous pouvez le retrouver ici : GitHub – Report AbuseIPDB.

    (N’hésitez pas à proposer des améliorations si vous voyez des moyens d’optimiser ou de rendre le script plus efficace !)

    Il ne vous reste plus qu’à créer un CRON et le tour est joué, par exemple :

    #Run /root/report_abuseipdb.sh every 6 hours
30 */6 * * * /root/report_abuseipdb.sh

    Vers un internet plus sécurisé, ensemble 💪

    Nous avons tous un rôle à jouer pour construire un internet plus sain et sécurisé. Chaque IP signalée est une attaque potentielle en moins pour nos infrastructures, une menace en moins pour les entreprises et les particuliers. Grâce aux efforts conjugués des contributeurs et des plateformes comme AbuseIPDB, nous pouvons réduire l’impact des cyberattaques et rendre le web plus sûr pour tous. 🌐

    Alors, que vous soyez un sysadmin expérimenté ou un utilisateur individuel souhaitant contribuer, je vous encourage à rejoindre cette initiative. Ensemble, nous pouvons faire une vraie différence et rendre le web plus sécurisé. 👊

  • Blacklists (RBL) : Pratiques scandaleuses de SPFBL.net

    Blacklists (RBL) : Pratiques scandaleuses de SPFBL.net

    Il est temps de dénoncer une organisation – SPFBL.net – qui, bien qu’elle prétende lutter contre le spam, semble en réalité adopter des pratiques contraires à cet objectif. Au lieu de remplir son rôle, ce prestataire semble profiter de sa position pour mener des pratiques absolument scandaleuses et inacceptables.

    Toutes les RBL ne sont pas gérées de manière éthique. L’exemple du jour est celui de SPFBL.net, une RBL brésilienne née en 2015 (source MXToolbox), qui est de plus en plus mise en lumière pour ses pratiques largement contestables.

    Info : Qu’est-ce qu’une RBL ?

    Une RBL (Real-time Blackhole List) est une liste d’adresses IP suspectées d’envoyer du spam ou d’autres contenus malveillants. Les serveurs de messagerie s’appuient sur ces listes pour bloquer ou filtrer les e-mails potentiellement dangereux.

    Dans cet article, nous allons décortiquer cette situation et expliquer pourquoi les pratiques de cette entreprise sont non seulement douteuses, mais potentiellement nuisibles à l’ensemble de l’écosystème internet si des administrateurs décident d’utiliser cette RBL. Nous verrons également comment combattre ces pratiques.

    L’avis des utilisateurs et fournisseurs de services confrontés à la blacklist SPFBL

    Commençons par montrer l’avis général ressortant de cette blacklist. Une rapide recherche sur les moteurs de recherche montre que les forums (en anglais) sont remplis de personnes criant au scandale et à l’arnaque au sujet de SPFBL.net.

    Pour avoir contacté leur support (je vous détaille cela ensuite), je serais plutôt de leur avis… Jugez par vous-même.

    « I contacted the operator of this spfbl.net and he threatened me with getting my IP’s blocked throughout the internet, how can something like this be allowed to happen. »

    OPALIT

    « We got flagged because we don’t have a contact email in our whois record (we have privacy turned on for it). Given that google.com also has that, I conclude that these guys are just a scam who want to be paid to have your domain unrestricted. »

    someexgoogler

    Le cas LRob : une blacklist manifestement injustifiée

    Le serveur d’infrastructure LRob est un exemple parfait d’un système configuré et géré avec soin depuis plusieurs années. En tant qu’administrateur système de ce serveur, je peux affirmer avec certitude qu’aucun spam n’a jamais été envoyé depuis cette machine. De plus, tous les paramètres essentiels sont correctement mis en place : Hostname, rDNS, MX, SPF, DKIM, et DMARC.

    Malgré ces mesures exemplaires de conformité, l’IPv6 du serveur s’est retrouvée sur la liste noire de SPFBL.net.

    SPFBL / DNSBL abusive blacklising example

    Check result of IP
    2a01:4f8:171:28e8:0:0:0:2

    This is the rDNS found:

    A domain is considered non-compliant when the WHOIS search result for that domain does not contain the email address of the domain owner. Update the registration data and remove privacy protection for this domain in WHOIS and wait one hour for the cached result of this WHOIS query to expire.

    This IP was flagged due to misconfiguration of the e-mail service or the suspicion that there is no MTA at it.

    For the delist key can be sent, select the e-mail address responsible for this IP:

    • add a PayPal user’s email for 2.00 USD.

    The rDNS must be registered under your own domain. We do not accept rDNS with third-party domains.

    Résumé des échanges avec le support de SPFBL.net

    J’ai bien-sûr contacté la RBL pour vérifier si j’avais bien compris leur politique et s’il était possible de discuter en bonne intelligence. Résultat : oui, j’avais bien compris, et non, il ne me semble pas possible de discuter en bonne intelligence avec eux en l’état.

    Voici un résumé ChatGPT des échanges par mail :

    1. Demande initiale (Robin) : Robin, administrateur système, a contacté SPFBL pour demander de l’aide concernant la suppression de son adresse IPv6 de leur liste noire DNS. Il souhaitait obtenir des précisions sur les raisons de l’inscription et des conseils pour corriger d’éventuelles mauvaises configurations, suspectant un lien avec la protection de la confidentialité WHOIS.
    2. Réponse (Leandro) : Leandro, de SPFBL, a répondu en demandant à Robin de retirer temporairement la protection de la confidentialité WHOIS afin de pouvoir retirer l’IP via leur outil de suppression en ligne.
    3. Préoccupations (Robin) : Robin a exprimé des inquiétudes quant à l’exigence de retirer la protection de la confidentialité WHOIS, invoquant les réglementations du RGPD. Il a remis en question la nécessité d’exposer des données personnelles, soulignant qu’aucun rapport d’abus n’avait été émis sur son domaine.
    4. Explication (Leandro) : Leandro a expliqué que leur système utilisait les données du propriétaire du domaine pour prédire le spam et associer des domaines sous le même titulaire. Il n’a pas fourni d’autres justifications pour cette politique.
    5. Objection (Robin) : Robin a contesté l’utilité des informations WHOIS pour évaluer le comportement d’une IP, qualifiant la politique de SPFBL de contre-productive. Il a réitéré que son IP ne présentait aucun risque et a demandé sa suppression de la liste noire.
    6. Options (Leandro) : Leandro a proposé deux options pour la suppression : retirer temporairement la protection WHOIS ou payer des frais.
    7. Réponse ferme (Robin) : Robin a fermement rejeté les deux options, qualifiant cette pratique de malhonnête et assimilable à une escroquerie. Il a souligné que son IP était conforme et a menacé de prendre des mesures légales si le problème n’était pas résolu.
    8. Réponse finale (Leandro) : Leandro a rejeté les menaces légales de Robin, affirmant que SPFBL respecte les lois américaines et l’invitant à poursuivre toute action légale qu’il jugerait appropriée.
    9. Dernier avertissement (Robin) : Robin a rappelé que l’internet est un système global et qu’aucune localisation ne justifie de nuire à des entreprises légitimes à travers des pratiques éthiques douteuses. Il a confirmé son intention de prendre les mesures nécessaires, en précisant que ses contacts identifieraient les autorités locales compétentes si nécessaire.

    Ces échanges ont eu lieu entre le 8 et le 9 septembre 2024.

    Par ailleurs, je dispose d’un log qui montre qu’ils ont tenté d’envoyer un mail à une adresse inexistante pour test, pouvant vérifier par eux-même la bonne configuration du serveur qui a donc rejeté ce mail :

    Oct  9 14:55:13 ds postfix/smtpd[899530]: connect from matrix.spfbl.net[54.233.253.229]
Oct  9 14:55:14 ds postfix/smtpd[899530]: NOQUEUE: reject: RCPT from matrix.spfbl.net[54.233.253.229]: 550 5.1.1 <inexistent-feature-check-192715907d9@lrob.net>: Recipient address rejected: User unknown in virtual mailbox table; from=<admin@spfbl.net> to=<inexistent-feature-check-192715907d9@lrob.net> proto=ESMTP helo=<matrix.spfbl.net>
Oct  9 14:55:14 ds postfix/smtpd[899530]: disconnect from matrix.spfbl.net[54.233.253.229] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4
Oct  9 14:55:14 ds psa-pc-remote[2023328]: Message aborted.

    Le cas SPFBL.net : une pratique abusive

    Le cas de SPFBL.net met en lumière des pratiques alarmantes qui vont à l’encontre de la protection des données et des standards éthiques que de nombreuses autres RBL respectent.

    En particulier, cette RBL blacklist des IP selon des critères abusifs, puis impose des conditions très problématiques pour le délistage d’adresses IP.

    Décortiquons les « règles pour un délistage gratuit » selon la politique affichée sur leur site le 9 Septembre 2024, qui nous informe également sur les raisons possibles au blacklistage initial :

    Only IP with rDNS pointing to the same mail server IP will be accepted, with FCrDNS validation;❌ Ce critère est certes standard, mais cette vérification devrait être effectuée par le serveur destinataire de l’e-mail, pas par une RBL, qui ici n’apporte aucune valeur ajoutée.
    The rDNS must be in the domain of the MTA administrator, so third-party domains such as the generic rDNS of the data-center or ISP will not be accepted, and its TLD cannot be free and must have a public and accessible WHOIS without privacy obfuscation;❌ L’administrateur peut très bien infogérer les mails d’un tiers, comme dans mon cas où le MTA est « lrob.net » et l’administration est faite via « lrob.fr ». Cela ne devrait pas justifier un blocage.
    ❌ Bloquer les rDNS génériques peut être une bonne pratique, mais cela relève du serveur destinataire, pas d’une RBL.
    ❌ Exiger un WHOIS public contrevient au RGPD en Europe. Le droit d’envoyer des mails ne devrait pas dépendre de la visibilité des informations personnelles dans le WHOIS.
    The postmaster account must be configured for the domain registered on the rDNS and the account must be active and responding;❌ Les rDNS sont souvent des sous-domaines techniques, comme « ds.lrob.net ». Avoir une adresse e-mail du type « postmaster (at) ds.lrob.net » n’a aucun sens. Le postmaster peut être contacté via d’autres canaux plus appropriés, comme un formulaire de contact ou une adresse principale.
    If you are using an IPv6 with SLAAC flag, you must keep port 25 opened to proof the existence of an active SMTP service and❌ Bien que le serveur doive effectivement écouter sur le port 25 pour assurer le bon fonctionnement du SMTP, c’est encore une fois au serveur destinataire de vérifier cela, pas à une blacklist de le contrôler.
    Reputation of IP should be below 25% of negative points per total send volume✅ Ce critère est cohérent avec le principe même d’une RBL, qui évalue la réputation d’une adresse IP en fonction de son comportement réel.

    Voyons aussi les conditions payantes :

    Only static IPs with configured mail server reverse, even if FCrDNS is invalid;❌ Sous prétexte de payer, on permettrait d’avoir un rDNS invalide, ce qui est contraire aux normes de configuration des e-mails. C’est un contournement des bonnes pratiques, qui pourrait permettre l’envoi de courriers mal configurés.
    A PayPal account is required for the email address of this account to be assigned to the IP, as responsible for the abuse;❌ Forcer l’utilisation de PayPal pour attribuer une adresse IP à un compte est une restriction injustifiée. Cela limite les options des utilisateurs et n’a aucune raison légitime dans un cadre technique.
    The PayPal user must agree to have their email address shown publicly on this platform as responsible for the abuses of that IP and❌ Exposer publiquement l’adresse email associée au compte PayPal est une atteinte à la vie privée et peut entraîner des risques de harcèlement ou d’abus. Cela va clairement à l’encontre des principes de confidentialité.
    Reputation of IP should be below 25% of negative points per total send volume.✅ Ce critère est acceptable et s’aligne avec le principe d’évaluation de la réputation d’une adresse IP sur la base de son comportement effectif, comme attendu d’une RBL.

    En somme, cette blacklist me semble tenter de réinventer la roue avec des règles de blocage qui ne font strictement aucun sens d’un point de vue technique.

    Quand aux conditions de délisting, même dans sa version payante, les conditions restent abusives. De mon point de vue, cela devrait déjà, à ce stade, avoir dissuadé tout sysadmin d’utiliser cette RBL.

    Le but semble bien-sûr être de faire du profit sur le dos des utilisateurs tout en récupérant des données personnelles.

    Résumé des problèmes de SPFBL.net

    Plusieurs problèmes majeur remettent en question le bienfondé de leurs pratiques et leur impact négatif sur les entreprises légitimes.

    Voici les principaux points à retenir :

    1. Exposition des données privées WHOIS
      SPFBL.net exige que les administrateurs retirent la protection de leur WHOIS pour être retirés de leur liste noire. Cela signifie que des informations personnelles et sensibles, comme l’adresse email du propriétaire du domaine, doivent être publiquement accessibles pour que l’adresse IP ne soit plus blacklistée. En Europe, cette demande est en totale contradiction avec le RGPD (Règlement Général sur la Protection des Données), qui garantit la protection des données privées des utilisateurs. Les informations contenus dans le WHOIS sont privées par défaut depuis plusieurs années. Cette exigence exposerait les administrateurs système et les entreprises à des risques d’abus ou de spams ciblés, ce qui est contraire aux bonnes pratiques en matière de sécurité et de confidentialité.
    2. Paiement pour la délistage
      En plus de la suppression de la protection WHOIS, SPFBL.net propose également une alternative : payer 2 dollars pour retirer une adresse IP de la liste noire. Cette pratique est perçue par beaucoup comme une forme de chantage. Exiger un paiement pour rétablir la légitimité d’une adresse IP, alors qu’il n’y a aucune preuve d’activité suspecte ou malveillante, remet en question la transparence de leurs opérations. Cette approche pousse probablement de nombreuses entreprises légitimes à payer simplement pour éviter les désagréments causés par le blacklistage.
    3. Un modèle de détection inefficace
      Regrouper les domaines en fonction des informations WHOIS ignore les réalités du web moderne, où de nombreuses entreprises légitimes utilisent des infrastructures partagées, hébergées par des fournisseurs comme Google ou OVH. En conséquence, des adresses IP pourraient être injustement blacklisted simplement parce qu’elles partagent un propriétaire de domaine avec d’autres utilisateurs, sans considération pour leur comportement réel.

    Un impact potentiel très grave

    Les conséquences de ces pratiques sont nombreuses et graves pour l’écosystème internet :

    1. Impact sur les entreprises : Lorsqu’une adresse IP est bloquée à tort, cela peut affecter la capacité d’une entreprise à communiquer par e-mail avec ses clients, partenaires ou prestataires. Les erreurs de détection ou les exigences abusives peuvent ainsi perturber le bon fonctionnement d’une entreprise.
    2. Chantage et extorsion : Demander de l’argent pour supprimer une adresse IP d’une liste noire sans preuve d’activité malveillante s’apparente à de l’extorsion. Cette approche nuit gravement à la confiance entre les fournisseurs de services internet et leurs clients.
    3. Violation de la confidentialité : En demandant la suppression de la protection WHOIS, SPFBL.net viole les principes fondamentaux de la protection des données personnelles, particulièrement en Europe, où le RGPD (Règlement Général sur la Protection des Données) protège les informations privées des utilisateurs. En exposant ces données, SPFBL.net expose les administrateurs système et les entreprises à des risques d’abus.

    Que faire en tant que fournisseur de services sur internet ?

    1. Cessez d’utiliser cette RBL immédiatement

    Nous devons tous enjoindre nos relations chez les grands fournisseurs de services à ne surtout PAS utiliser cette RBL.

    Il est absolument indispensable que les fournisseurs de services internet cessent d’utiliser SPFBL.net et d’autres RBL qui ne respectent pas les standards éthiques. Une autre RBL de ce type est également UCEPROTECT qui blacklist des blocks d’IP complets et demande ensuite de l’argent à chacun des usagers des IP pour les débloquer.

    L’utilisation d’une RBL douteuse peut entraîner des conséquences néfastes pour les utilisateurs finaux, les entreprises et l’ensemble de l’écosystème numérique.

    Il existe de nombreuses alternatives respectables qui se concentrent sur la détection des activités malveillantes en se basant sur des comportements réels, et non sur des informations privées ou des regroupements arbitraires de domaines. Les administrateurs système doivent rester vigilants et choisir des solutions qui respectent la vie privée et qui suivent des pratiques équitables et transparentes.

    2. Ne cédez pas

    Si comme moi vous êtes victime de cette RBL et estimez que ces pratiques sont abusives, ne cédez surtout pas aux prérequis scandaleux de cette RBL. Au contraire, battez-vous à mes côtés.

    3. Dénoncez ces pratiques aux autorités compétentes

    Faites jouer vos relations pour que cela remonte aux CSIRT français (Computer Security Incident Response Team), à l’ANSSI mais également à la CNIL pour non respect de la RGPD. Si vous avez des contacts au niveau européen, relayez l’info. Si vous êtes en dehors de France ou d’Europe, contactez les organismes à votre portée, et n’hésitez pas à vous appuyer sur cet article pour expliquer le problème.

    Si vous n’avez pas de contact mais que vous comprenez l’enjeu, relayez également l’info à des personnes du domaine de l’hébergement et du sysadmin web.

    Conclusion

    L’affaire SPFBL.net est un exemple flagrant des dangers des pratiques douteuses de certaines RBL.

    On comprend que celui qui se prétend combattre les « méchants » n’est pas toujours « gentil » lui-même.

    Pour protéger l’intégrité de l’internet et le respect des utilisateurs, il est impératif que les fournisseurs de services internet cessent d’utiliser cette RBL et privilégient les solutions plus respectueuses disponibles.

    Confrères sysadmin : ne cédez surtout pas aux prérequis grotesques de cette RBL.

    LRob ne cèdera pas, cet article marque d’ailleurs le début d’une lutte qui ne s’arrêtra qu’une fois que la communauté aura eu gain de cause. Cela est possible, en contactant les bonnes personnes. Et vous pouvez aider à ce combat.

    Si vous êtes confronté aux pratiques abusives de SPFBL.net, rejoignez-nous pour dénoncer ces actions et protéger l’intégrité de l’écosystème internet. Contactez les autorités compétentes, partagez cette information dans vos réseaux professionnels, et refusez de céder à ces pratiques déloyales.

  • Faille de sécurité critique dans CUPS sur GNU/Linux septembre-octobre 2024 : Ce que vous devez savoir

    Faille de sécurité critique dans CUPS sur GNU/Linux septembre-octobre 2024 : Ce que vous devez savoir

    Une quadruple faille de sécurité critique vient d’être découverte dans CUPS pour l’ensemble des systèmes GNU/Linux. Cet article sera mis à jour avec les nouvelles informations, pour vous offrir un résumé simple et efficace de ce qu’il faut savoir et des mesures à prendre.

    MAJ 29/09/2024 : Ces failles concernent bien uniquement CUPS, donc très peu de serveurs sont touchés, à moins que vous n’ayez des imprimantes en datacenter… ! Cet article a donc été réécrit en conséquence.

    Une faille critique : qu’est-ce qu’on sait ?

    Le chercheur en sécurité Simone Margaritelli, a découvert cet ensemble de failles début septembre.

    Cela concerne CUPS, le service d’impression de Linux. Le chercheur met en lumière une possible exécution de code à distance (Remote Code Execution, ou RCE) sans authentification. Cela signifie que des attaquants pourraient potentiellement exécuter des commandes sur des machines distantes sans avoir à s’identifier, ce qui rend la faille particulièrement dangereuse. Le score CVSS attribué à ces failles est situé entre 8.3 et 9.0/10 (après avoir été évalué à 9.9).

    Le 26 Septembre, Naïm Aouaichia, ingénieur cybersécurité nous alertait en indiquant avant tout le monde que cela pourrait concerner CUPS :

    « Certaines rumeurs évoquent que cette faille serait liée à des vulnérabilités dans CUPS, le service d’impression. Oui, vos imprimantes sont peut-être au centre de tout ça. À confirmer.

    D’après certaines hypothèses, le problème pourrait être lié à un buffer overflow ou à une race condition. »

    Extrait du post LinkedIn de Naïm Aouaichia, ingénieur cybersécurité

    Update 29/09/2024

    Comme Naïm le remonte le 28 Septembre, cette faille concerne bien CUPS, avec 4 CVE révélées :

    Cela ne concerne donc pas les serveurs dédiés sous firewall et/ou avec un service d’impression non lancé.
    Pour les administrateurs locaux utilisant CUPS, restez bien attentifs.

    Un problème qui date

    Cette vulnérabilité a la peau dure, puisqu’elle a été présente dans les systèmes GNU/Linux pendant plus d’une décennie. Elle affecte toutes les distributions Linux, y compris Debian, Ubuntu, RedHat et autres.

    Malgré l’importance de cette faille, il n’existe pour l’instant aucune correction disponible. Les développeurs continuent de débattre pour savoir quels aspects de la faille affectent réellement la sécurité, ce qui retarde la mise en place d’un correctif.

    Processus de divulgation

    Le chercheur Margaritelli, à l’origine de cette découverte, a travaillé sans relâche pendant trois semaines pour alerter la communauté open source et aider à la coordination des efforts de correction. Cependant, il a rencontré de nombreuses résistances de la part des développeurs, certains étant réticents à accepter l’existence de cette faille dans leur code. Cela souligne les défis auxquels est confrontée la gestion des vulnérabilités dans le monde open source.

    Certains l’accusent de vouloir augmenter sa cote de popularité. Mais il faut se rendre à l’évidence : Le chercheur a bel et bien découvert une grosse faille que tout le monde ignorait depuis plus de 10 ans.

    Canonical (Ubuntu) et RedHat ont confirmé la gravité de la situation et travaillent activement à une solution. La divulgation complète des détails techniques de la faille est prévue le 6 octobre, ce qui augmente la pression pour qu’un correctif soit publié rapidement.

    La roadmap est la suivante :

    • 30 Septembre : Divulgation initiale à la mailing list de sécurité « Openwall »
    • 6 Octobre : Révélation publique avec tous les éléments de la vulnérabilité

    Pourquoi c’est compliqué de corriger la faille ?

    Margaritelli a indiqué dès le début qu’il faudrait probablement au moins trois à six identifiants CVE (Common Vulnerabilities and Exposures) pour couvrir tous les aspects du problème. Cela signifie qu’il y a plusieurs vecteurs d’attaque potentiels, chacun nécessitant une analyse et une résolution spécifiques.

    Quels sont les risques pour vous ?

    De ce que l’on sait désormais, il faut absolument éviter d’exposer vos services IPP sur internet (port 631 à bloquer au niveau des firewalls).

    Bien que cette faille soit critique, elle n’est pas si facilement exploitable. Elle nécessite un haut niveau d’expertise technique, ce qui signifie que, pour l’instant, seuls des attaquants très qualifiés pourraient s’en servir. Les détails de la faille ne sont sont pas encore publics, limitant donc son impact. Mais cela ne doit pas vous rendre complaisant. Il faut rester vigilant, car une fois la divulgation complète effectuée, les tentatives d’exploitation vont se multiplier.

    Que faire en attendant ?

    Dans l’attente d’un correctif officiel, voici les bonnes pratiques à adopter pour limiter les risques :

    1. Surveillez les annonces officielles : Restez informé des mises à jour de sécurité publiées par votre distribution Linux. Ces annonces vous indiqueront quand un correctif est disponible.
    2. Renforcez la configuration de vos firewalls : Assurez-vous que vos serveurs ne sont pas exposés inutilement à Internet. Restreignez les accès aux ports essentiels et surtout, n’exposer pas le port 631 !
    3. Limitez l’exposition des services : Réduisez au minimum le nombre de services qui écoutent publiquement en coupant les services inutiles ou en les faisant écouter sur 127.0.0.1.
    4. Préparez-vous pour un déploiement rapide : Dès qu’un correctif est publié, soyez prêt à l’installer immédiatement pour protéger vos machines.
    5. Ré-évaluez vos sauvegardes : Assurez-vous d’avoir une bonne sauvegarde externalisée (chez LRob c’est déjà le cas mais on incite chacun à disposer de sa propre sauvegarde).

    Conclusion : rester vigilant mais serein

    Cette faille RCE est sans doute une des plus graves découvertes dans l’écosystème GNU/Linux depuis longtemps. Cependant, il est important de ne pas céder à la panique. Aucun système n’est exempt de failles et Linux reste le système d’exploitation le plus fiable et sécurisé. Il faut se rappeler que la plupart des serveurs n’ont pas de service CUPS en route, mais si c’est le cas, alors faites particulièrement attention. En adoptant les mesures de sécurité recommandées et en restant à l’écoute des annonces officielles, vous pouvez minimiser les risques. Le monde open source, réagit généralement rapidement et saura certainement surmonter cette épreuve efficacement, malgré les divergences internes inhérentes au travail collaboratif.

    Gardez un œil sur les correctifs à venir et assurez-vous que vos systèmes sont prêts à les recevoir. La sécurité informatique est un défi permanent, mais en restant proactif, vous vous assurez que vos serveurs et vos clients WordPress restent protégés.

    Chez LRob, on suit ça de très près, et si les serveurs ne sont pas affectés, je vous garantis qu’on corrigera quand même cette faille mondiale à l’instant où le patch sera disponible.

    Enfin, on rappelle à ceux qui vont arguer que « Linux n’est pas sécurisé » un petit comparatif Linux VS Microsoft.

    Comparatif des failles de sécurité Linux VS Microsoft sur 1 an
    Comparatif des failles de sécurité Linux VS Microsoft sur 11 ans

    En vérité : la sécurité à 100% n’existe jamais, quiconque prétend le contraire est un menteur ou un ignorant ! Laissez donc le dogmatisme de côté. Personne n’est épargné par les failles, il s’agit donc de faire au mieux et de rester vigilant pour rendre les intrusions les plus difficiles possibles.

    Sources :

  • Le meilleur gestionnaire de mots de passe gratuit et open-source (KeePass)

    Le meilleur gestionnaire de mots de passe gratuit et open-source (KeePass)

    Sécurisez vos mots de passe avec une solution open-source et auto-hébergée

    Gérer ses mots de passe est un vrai casse-tête ! On sait tous que la sécurité de nos données perso dépend de nos mots de passe, mais franchement, qui n’a jamais fait d’erreur en les gérant ? Voyons ensemble comment éviter les pièges les plus courants et trouver la solution idéale pour garder nos mots de passe en sécurité.

    Les erreurs courantes dans la gestion des mots de passe

    Deux questions simples pour voir où tu en es avec la gestion de tes mots de passe :

    1. Tu te souviens de tes mots de passe ?
      • Si ta réponse est « oui », c’est pas forcément une bonne nouvelle. Ça veut dire que tu utilises probablement le même mot de passe un peu partout ou que tu as un modèle facile à deviner. Un hacker pourrait alors s’amuser à découvrir les autres mots de passe si jamais il en trouve un.
    2. Tu confies tes mots de passe à une entreprise privée ?
      • Là encore, attention ! Beaucoup de gestionnaires de mots de passe commerciaux ont déjà été piratés. Et comme ils sont « closed-source », impossible de savoir ce qu’ils font avec tes données. Et pour ce qui est de sauvegarder les mots de passe dans Chrome… Je pense que tu vois où je veux en venir. 😬

    Pas de panique, si tu as répondu « oui » à une de ces questions, tu n’es pas le seul, tu fais même partie de la majorité. Il est temps de sécuriser tout ça et de rejoindre ceux qui prennent leur sécurité en main !

    KeePass : excellente solution open-source maximale

    La bonne solution pour une sécurité maximale et un contrôle total ?

    KeePass

    Open-source gratuit et indépendant, ce logiciel te permet de stocker tes mots de passe dans une base de données chiffrée, protégée par un seul mot de passe maître. Fini de te souvenir de tous tes mots de passe, ils peuvent être aussi compliqués et aléatoires que tu veux !

    Soyons honnêtes, l’appli originale KeePass n’est pas la plus belle. Mais pas de souci, il y a une super alternative : KeePassXC. Avec KeePassXC, tu as une interface améliorée et une sécurité au top, que tu sois sur Windows, macOS ou Linux.

    Et pour encore plus de confort, pense à installer l’extension navigateur de KeePassXC. Elle te permet de remplir automatiquement tes champs de mot de passe et de sauvegarder facilement les nouveaux.
    Et à activer l’intégration navigateur correspondante dans les réglages KeePassXC.

    Transition simplifiée depuis Chrome

    Comme beaucoup utilisent Chrome et auront forcément la flemme de faire le switch, sachez qu’il est très simple d’exporter vos mots de passe :

    • Rendez-vous des les paramètres de Chrome
    • Puis dans « Mots de passe »
    • Cliquez sur « Exporter les mots de passe »
    • Sauvegardez le .csv
    • Importez-le via KeePass via la fonction « Import… »
    • Supprimez le .csv et videz votre corbeille

    Garde le contrôle avec une solution auto-hébergée

    L’un des gros avantages d’une solution open-source comme KeePass, c’est que tu peux garder un contrôle total sur tes données. Pas besoin de confier ta base de données à une entreprise privée. Tu peux l’héberger toi-même sur une plateforme comme Nextcloud pour un accès même hors connexion. Nextcloud couplé à KeePass te permet donc de synchroniser tes mots de passe entre tous tes appareils tout en gardant la main sur tes données.

    En plus, Nextcloud, ce n’est pas juste un service de stockage. C’est une solution complète pour gérer tes fichiers, collaborer en équipe et bien plus encore. Tu profites de tous les avantages des solutions cloud propriétaires comme celles de Microsoft ou Google, mais avec la souveraineté totale sur tes données.

    Si tu n’as pas encore ton instance Nextcloud, tu peux l’avoir très simplement avec une maintenance complète ici : https://www.lrob.fr/hebergement-web/cloud-prive-nextcloud/

    Mention pour Passbolt

    Une solution axée web auto-hébergeable existe aussi : Passbolt.

    Quelle que soit la solution choisie, Passbolt et KeePass comportent des fonctions d’import/export de mots de passe, pour passer de l’un à l’autre facilement. Une fois que tu es libre, tu es libre.

    Conclusion

    Protéger tes mots de passe est essentiel. Avec une solution open-source et totalement auto-hébergée comme KeePass et Nextcloud, tu es sûr de faire le bon choix. Tu as une sécurité optimale et tu gardes le contrôle de A à Z, sans dépendre de services tiers qui pourraient mettre ta confidentialité en danger.

    Alors, prêt à découvrir la satisfaction d’utiliser un mot de passe de 128 caractères aléatoires, tout en sachant qu’il est super sécurisé ? C’est le moment de te lancer avec KeePass et de reprendre le contrôle de tes données. 💪

  • Une faille sur le serveur web Apache touche des millions de serveurs

    Une faille sur le serveur web Apache touche des millions de serveurs

    Le serveur Apache HTTP est l’un des serveurs web les plus utilisés dans le monde. Cependant, comme tout logiciel, il n’est pas à l’abri des vulnérabilités. Et attention car il s’agit d’une double faille.

    Le 4 juillet, une faille de sécurité critique a été découverte, affectant la version 2.4.60 d’Apache. Cette faille est notée CVE-2024-39884.

    La faille permet la divulgation du code source des fichiers PHP. C’est donc absolument critique car ceux-ci peuvent par exemple contenir des mots de passe des bases de données, ou du code propriétaire confidentiel.

    Un correctif est donc sorti via la version 2.4.61 du serveur Apache… Sauf que ce correctif ne corrigeait correctement pas la faille ! Une deuxième CVE est donc sortie, la CVE-2024-40725 pour ré-identifier cette faille finalement non corrigée.

    Voici une synthèse de ces failles et des corrections apportées.

    Update 30/07/2024 : Il existe une possibilité pour que cette vulnérabilité soit en lien avec une vague de piratages ciblant de sites hébergés chez o2switch. Rien n’est établi avec certitude car les moyens d’exploitation de ces failles et l’envergure du problème ne sont pas encore publics. Je n’ai pas non-plus d’informations de la part mon confrère hébergeur sur les versions Apache utilisées.

    CVE-2024-39884

    • Date de publication : 4 juillet 2024
    • Description : Une régression dans le noyau du serveur Apache HTTP version 2.4.60 fait en sorte que certaines configurations basées sur le type de contenu, telles que « AddType », ne sont pas correctement prises en compte. Dans certains cas, cela peut entraîner la divulgation du code source de fichiers locaux, comme les scripts PHP qui peuvent être affichés en texte brut au lieu d’être interprétés.
    • Solution : Il est recommandé de mettre à jour vers la version 2.4.61, qui corrige ce problème.
    • Lien : CVE-2024-39884

    CVE-2024-40725

    • Date de publication : 17 juillet 2024
    • Description : Cette faille est une correction additionnelle de la CVE-2024-39884. Elle révèle que la version 2.4.61 ne corrige pas complètement le problème initial. En effet, certaines configurations basées sur le type de contenu peuvent encore entraîner la divulgation du code source des fichiers locaux dans certaines circonstances.
    • Solution : Il est recommandé de mettre à jour vers la version 2.4.62, qui corrige définitivement ce problème.
    • Lien : CVE-2024-40725

    Roadmap de Correction pour Debian

    Debian, la mère distribution Linux, utilisée par LRob, a également pris des mesures pour corriger ces vulnérabilités dans ses différentes versions, au travers du repository « security » ou natif en fonction des versions de l’OS. Voici la feuille de route des corrections :

    Source PackageReleaseVersionStatus
    apache2 (PTS)bullseye2.4.59-1~deb11u1vulnérable
    bullseye (security)2.4.61-1~deb11u1corrigé
    bookworm2.4.59-1~deb12u1vulnérable
    bookworm (security)2.4.61-1~deb12u1corrigé
    sid, trixie2.4.62-1corrigé

    État des serveurs LRob

    Les serveurs LRob sont déjà tous à jour et corrigent bien cette faille.

    Conclusion

    Les administrateurs de serveurs Apache HTTP doivent vérifier immédiatement la version de leur serveur et mettre à jour vers les versions corrigées (2.4.61-1[security] ou 2.4.62) pour éviter toute divulgation involontaire de code source.

    La communauté open-source continue de surveiller et de corriger rapidement les vulnérabilités afin de garantir la sécurité et la fiabilité des logiciels utilisés par des millions de serveurs dans le monde. Assurez-vous de suivre les mises à jour de sécurité et de maintenir votre infrastructure à jour pour protéger vos données et celles de vos utilisateurs.

fr_FR
en_US fr_FR