Shop & Support

LRob.fr

Author: Robin Labadie

  • WordPress vs WP Engine conflict: analysis of the drama

    WordPress vs WP Engine conflict: analysis of the drama

    Le monde de WordPress, qui alimente plus de 40 % des sites web dans le monde, est en pleine ébullition. Au centre du conflit se trouvent deux acteurs majeurs de l’écosystème : Matt Mullenweg, fondateur de WordPress et CEO d’Automattic, et WP Engine, une des principales entreprises d’hébergement pour WordPress.

    Cet affrontement, qui a pris des proportions juridiques, soulève des questions cruciales sur le contrôle de la marque WordPress, l’open source, et la gouvernance de l’un des projets les plus influents du web. Voici une analyse détaillée de cette affaire et des enjeux qu’elle représente.

    Contexte : WordPress et WP Engine

    WordPress et Automattic : une relation complexe

    WordPress, lancé en 2003 par Matt Mullenweg et Mike Little, est un logiciel open source permettant de créer et gérer des sites web. Il est gratuit et bénéficie du soutien d’une large communauté de développeurs qui contribuent à son amélioration continue. Cependant, la gouvernance du projet repose en grande partie sur Automattic, la société fondée par Mullenweg. Automattic gère notamment WordPress.com et d’autres produits populaires comme WooCommerce et Jetpack.

    Bien que WordPress soit open source, Automattic détient une licence exclusive pour l’utilisation de la marque WordPress, ce qui donne à l’entreprise un rôle central dans l’écosystème. Cela inclut la protection de la marque contre des utilisations perçues comme abusives ou trompeuses.

    WP Engine : un gros acteur de l’hébergement WordPress

    De son côté, WP Engine est l’un des plus grands services d’hébergement spécialisés dans WordPress. L’entreprise propose des solutions d’hébergement optimisées pour WordPress, facilitant la gestion des sites web pour des millions d’utilisateurs. Elle a connu une croissance rapide, attirant des investisseurs de premier plan comme Silver Lake.

    Cependant, WP Engine n’est pas directement affilié à Automattic ni à la WordPress Foundation, bien que son nom et son modèle économique soient étroitement liés à WordPress.

    Le Début du Conflit : Mullenweg vs WP Engine

    En septembre 2024, Matt Mullenweg a publié un billet de blog dans lequel il critiquait ouvertement WP Engine, qualifiant l’entreprise de “cancer pour WordPress”. Il reprochait à WP Engine de désactiver par défaut la fonctionnalité d’historique des révisions des articles, une pratique qui, selon lui, compromettait la protection des données des utilisateurs.

    Mullenweg a également dénoncé l’utilisation par WP Engine de la marque “WP”, estimant que cela créait une confusion chez les utilisateurs, leur faisant croire que WP Engine faisait partie de WordPress ou avait un lien officiel avec la WordPress Foundation.

    La Réaction de WP Engine

    Face à ces accusations, WP Engine a répliqué en envoyant une lettre de cessation et de désistement à Mullenweg et à Automattic, exigeant qu’ils retirent leurs déclarations. WP Engine a défendu son utilisation de la marque « WP », affirmant que cela relevait de l’usage loyal du nom, conformément à la loi sur les marques. La société a également accusé Mullenweg d’avoir menacé d’adopter une “approche nucléaire” contre WP Engine à moins qu’elle n’accepte de payer une redevance substantielle pour l’utilisation de la marque WordPress.

    L’escalade juridique : cessez-le-feu et contre-attaques

    En réponse à la lettre de WP Engine, Automattic a émis sa propre lettre de cessation et de désistement, affirmant que WP Engine violait les règles d’utilisation des marques WordPress et WooCommerce.

    Le conflit a atteint un nouveau sommet lorsque Mullenweg a pris la décision radicale de bannir WP Engine des ressources de WordPress.org. Ce ban a bloqué les sites hébergés sur WP Engine de l’accès aux mises à jour des plugins et des thèmes, exposant de nombreux sites à des risques de sécurité. Cette mesure a été largement critiquée au sein de la communauté WordPress, car elle a laissé de petites entreprises et des sites indépendants sans solution viable.

    WP Engine a dénoncé cette décision, accusant Mullenweg d’abus de pouvoir et de mettre en danger l’ensemble de l’écosystème WordPress.

    Les répercussions pour la communauté WordPress

    Des utilisateurs pris en otage

    L’interruption des services WP Engine a eu un impact majeur sur de nombreux utilisateurs. Bien que les plugins et thèmes WordPress soient sous licence open source, les hébergeurs comme WP Engine doivent gérer des infrastructures pour que leurs clients puissent les utiliser. Le ban temporaire a révélé la fragilité de certaines dépendances techniques et a mis en lumière l’importance d’une gestion équilibrée des ressources open source.

    Mullenweg a toutefois affirmé que le conflit était strictement lié à des questions de marques et non à la gestion globale de WordPress. Le ban a été levé temporairement à la fin du mois de septembre, mais l’incident a semé des doutes dans la communauté.

    Automattic trop dominant ?

    De plus en plus de voix s’élèvent pour questionner la position dominante d’Automattic dans la gestion de WordPress. John O’Nolan, fondateur du CMS open source Ghost, a critiqué la centralisation excessive autour de Matt Mullenweg, affirmant que “40 % du web ne devrait pas être contrôlé par une seule personne”.

    De son côté, David Heinemeier Hansson, créateur de Ruby on Rails, a accusé Automattic de trahir les principes de l’open source en demandant à WP Engine de reverser 8 % de ses revenus. Pour lui, cette pratique pourrait avoir des répercussions bien au-delà de WordPress, menaçant l’ensemble de la communauté open source.

    Les implications juridiques et commerciales

    Le 3 octobre 2024, WP Engine a décidé de passer à l’offensive en déposant une plainte contre Automattic et Mullenweg pour abus de pouvoir et pratiques anticoncurrentielles. WP Engine accuse Automattic de ne pas avoir respecté ses engagements envers l’open source et de nuire aux intérêts des développeurs et des utilisateurs.

    Cette affaire est encore en cours, mais elle pourrait avoir des répercussions profondes sur la manière dont les marques et projets open source comme WordPress sont gérés à l’avenir.

    Un message spécial à la connexion sur WordPress.org

    Lors du login aux forums de WordPress.org, une nouvelle case à cocher est apparue :

    ✅ I am not affiliated with WP Engine in any way, financially or otherwise.

    Message inhabituel qui m’a poussé à rechercher cela et à découvrir cette affaire.

    Questions soulevées pour WordPress

    Cela touche essentiellement deux grandes entreprises américaines qui font une exploitation commerciale de WordPress (dans des modèles à mon avis trop modifiés de la version originale de WordPress). Version originale de WP qui est vraiment libre et que vous pouvez héberger où vous le souhaitez (et on l’espère, vous choisirez un hébergement LRob).

    Les hébergeurs indépendants tels que LRob, sommes pour l’heure totalement à l’abri de ce conflit. Pas de sonnette d’alarme pour nous, même si l’on reste vigilants.

    Ce conflit souligne en tout cas les tensions possibles lors d’une gestion de projet open source à grande échelle. Alors que WordPress reste une technologie essentielle pour des millions de sites, ce débat autour de la propriété des marques, de la gouvernance et de l’éthique de l’open source, soulève des questions.

    En particulier : Jusqu’où l’open source peut-il rester libre quand il est étroitement lié à des intérêts commerciaux massifs ?

    Source: techcrunch.com

  • Critical security flaw in CUPS on GNU/Linux September-October 2024: What you need to know

    Critical security flaw in CUPS on GNU/Linux September-October 2024: What you need to know

    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 :

  • Best practices for your WordPress contact forms

    Best practices for your WordPress contact forms

    Imaginez le drame : seulement 1 chance sur 10 que vos demandes vous parviennent !

    Les formulaires de contact sont indispensables pour acquérir des clients. Pourtant, un certain nombre de ces formulaires sont mal configurés et échouent à faire parvenir les demandes des prospects…

    De plus, les formulaires sont sensés être faits pour vous faire gagner du temps… Et quelques astuces peuvent vous y aider… Par exemple en ne recevant pas de spam ou en pouvant répondre plus rapidement.

    Aujourd’hui, LRob vous fait gagner du temps et des prospects !

    1. L’expéditeur doit appartenir à votre nom de domaine

    Ne mettez pas l’adresse email du client en expéditeur (From).

    L’erreur la plus courante lors de la configuration d’un formulaire de contact consiste à définir le client ou le prospect remplissant le formulaire comme expéditeur du message.

    Cela peut sembler logique (après tout, c’est son adresse email) mais c’est en réalité une très mauvaise pratique. En procédant ainsi, le mail envoyé par votre site usurpe l’identité de l’expéditeur (par exemple : john.doe@microsoft.com. Ce phénomène s’appelle le mail spoofing (ou usurpation d’identité).

    Les serveurs de messagerie modernes vérifient que chaque email provient d’une source authentifiée. Or, votre serveur n’a évidemment pas l’autorisation d’envoyer des messages au nom du domaine du visiteur. Résultat : le message est souvent bloqué, classé comme spam, ou tout simplement jamais livré. Dans la majorité des cas, le mail n’arrivera pas du tout, et votre serveur risque même d’être blacklisté par les grands fournisseurs (Gmail, Outlook, etc.).

    La bonne pratique

    L’expéditeur du mail doit toujours être une adresse associée à votre propre domaine.
    Par exemple : site@votredomaine.fr.

    Ainsi, les emails envoyés depuis votre formulaire seront authentifiés et acceptés par les serveurs destinataires, sans risque d’être considérés comme du spam.

    2. Protégez vos formulaires avec un Captcha

    N’oubliez pas d’ajouter un Captcha pour éviter les spams.

    Le Captcha n’est pas là juste pour embêter le monde : c’est une solution simple et efficace pour filtrer les robots et préserver la qualité des messages reçus.

    Sans cette protection, vous allez recevoir des dizaines voire des centaines de messages non sollicités par jour, ce qui vous fera perdre du temps à trier, en plus de manquer les vraies demandes.

    Pour respecter la vie privée de vos usagers, je conseille hCaptcha.

    3. Configurez SMTP sur votre site

    Votre site web devrait avoir une adresse mail dédiée avec un vrai login SMTP pour vos envois. Pour rappel, SMTP est le protocole standard d’envoi email.

    Si vos mails sont chez Gmail ou Microsoft, cela va être plus compliqué à appliquer car vous payez à chaque boîte mail et SMTP est désactivé par défaut… Mais s’ils sont chez votre hébergeur favori alors aucun souci !

    Pour WordPress, je conseille le plugin Easy WP SMTP ou bien WPMasterToolkit.

    Mais pourquoi s’embêter à utiliser SMTP ?

    • Les envois par défaut via la fonction php mail() sont parfois désactivés pour éviter les envois involontaires de mails et ainsi préserver la réputation des serveurs (bloqué par défaut chez LRob, autorisé au cas par cas).
    • Cela assure que l’envoi se fasse depuis un vrai serveur email plutôt que depuis le serveur du site web, lorsque ces deux serveurs sont distincts.
    • SMTP va améliorer la délivrabilité des mails grâce à des « headers » email (des méta-informations) généralement plus propres que php mail().
    • En cas de problème avec le formulaire (envoi massif de spams par exemple), SMTP permettra de limiter les envois à un quota horaire.
    • En cas de souci de délivrabilité quelconque, si votre hébergeur fournit du support pour cela (c’est le cas de LRob), les envois SMTP sont bien plus facilement traçables dans les logs, ce qui simplifie le diagnostic.

    En résumé, utiliser SMTP n’a que des chances d’améliorer votre délivrabilité et d’éviter les problèmes. Utilisez-le !

    4. Vérifiez la délivrabilité de vos emails du formulaire

    Assurez-vous que vos messages sont bien reçus en effectuant des tests avec des outils comme mail-tester.com.

    Mail-Tester vous permet de mesurer la qualité de vos envois.

    Mettez l’adresse mail s’affichant à la visite de mail-tester.com en destinataire du formulaire, faites votre test, puis vérifiez le score.

    Un score supérieur ou égal à 9/10 est recommandé pour garantir la bonne réception des demandes. Ce score devrait également être atteint lors de vos envois email classiques. Si ce n’est pas le cas, contactez votre hébergeur email pour plus d’infos (ou venez vous héberger chez LRob !).

    5. Faites vos tests en navigation privée

    Lorsque vous testez vos formulaires de contact, faites-le en navigation privée.

    Si vous êtes connecté à votre site, certaines fonctionnalités comme le Captcha peuvent être désactivées, pour ne citer que ça. Cela pourrait fausser vos tests et vous donner une impression erronée de la qualité de votre formulaire.

    6. Utilisez une adresse destinataire liée à votre domaine

    Assurez-vous que l’adresse de réception (destinataire du formulaire) appartient bien à votre domaine (vous@votredomaine.fr) et qu’elle n’est pas redirigée vers une autre adresse.

    En cas de problème avec votre formulaire, par exemple si vous recevez du spam via le formulaire et que le destinataire est un grand fournisseur de messagerie (Gmail, Orange, Yahoo, etc.), vous pourriez être considéré comme spammeur.

    Utiliser votre propre domaine en destinataire du formulaire vous permet donc de protéger votre e-réputation et de réduire les risques de blocage ou de mauvaise gestion des emails par les fournisseurs de messagerie.

    7. Évitez les emails de confirmation

    Envoyer un email de confirmation peut sembler être une bonne idée, mais il faut s’en méfier.

    Si ce message contient le texte soumis par l’utilisateur, votre formulaire peut alors être exploité par des personnes malveillantes pour envoyer du spam à n’importe quelle adresse mail via votre site. Même si le texte n’est pas repris, cela peut quand même générer des mails non sollicités vers des tiers, ce qui n’est jamais bon.

    Cela peut donc ternir la réputation de votre domaine et vous exposer à des sanctions. Préférez donc éviter cette pratique.

    8. Utilisez le champ « Reply-To » pour faciliter vos réponses

    Même si vous ne devez pas mettre l’adresse email du client dans le champ « From », vous pouvez cependant l’ajouter dans le champ « Reply-To ».

    Ainsi, vous pourrez directement répondre au mail du formulaire : l’adresse email de votre prospect sera automatiquement le destinataire de votre mail.

    Une solution simple et efficace pour gagner du temps !

    9. Sauvegardez les demandes sur le site

    Envisagez de sauvegarder les demandes du formulaire en base de données du site.

    Des plugins WordPress comme « Contact Form 7 Database Addon » permettent cela gratuitement. Vous pourrez alors vérifier de temps en temps que vous n’avez pas loupé une demande.

    Pour aller plus loin…

    Si vous avez des doutes sur la configuration de vos formulaires, ou si vous souhaitez un audit personnalisé, n’hésitez pas à me contacter.

    Aussi, le conseil relatif à la délivrabilité email est inclus dans le support LRob pour tous les clients.

    Je n’ai plus qu’à vous souhaiter une belle réussite avec des formulaires au top désormais ! 💪

  • Back to school for adults 2024: New products and special offers from LRob

    Back to school for adults 2024: New products and special offers from LRob

    💥Nouvelles offres & jusqu’à -30% en Septembre 💥
    De quoi booster sa rentrée ! Tous les détails 👇

    En septembre, les adultes font aussi leur rentrée !

    Et ça fait pile 1 an que j’ai quitté mon CDI pour me focaliser totalement sur l’activité LRob. Alors il faut marquer le coup.

    Le planning de septembre est chargé, donc allons à l’essentiel.

    ⭐ Nouveautés ⭐

    🟢 La migration vers LRob peut désormais être commandée depuis le portail LRob ! Avec 3 niveaux de service disponibles de 120 à 499€ (le dernier permet la migration de 50 boîtes mail de nuit !). 😎

    🟢 Les offres de webmastering ont évolué pour plus de flexibilité.
    Choisissez désormais l’hébergement et le niveau de webmastering souhaité séparément. Dans certains cas, cela peut faire de belles économies. 🔀

    🟢 L’offre WP ArticlePro AI se simplifie, à tarif réduit pour Septembre !
    La relecture, amélioration, mise en page de vos articles, avec désormais 2 images incluses, des options multilingue : à partir de 30€/article (au lieu de 40€) ! 🤖

    ℹ️ Les GENERAL TERMS AND CONDITIONS ont été mises à jour en conséquence.

    🌿 Des infos sur les mesures concrètes d’éco-responsabilité LRob sont désormais disponibles.

    🏷️ Réductions jusqu’au 30 septembre 🏷️

    1️⃣ Réduction sur les hébergements annuels WordPress 🚀

    2️⃣ Réduction sur la gestion annuelle de TranslatePress 🎌

    3️⃣ Réparation et sécurisation de votre site WordPress après un piratage.
    Si vous avez subi un piratage mais n’étiez pas encore chez LRob.

    Offres valables pour les commandes via le portail LRob.

    Excellente rentrée à tous ! 🎒

    Pour commander c’est par ici 👉 https://portail.lrob.fr/

  • Increase in URSSAF contributions for 2025 (AE/EI)

    Increase in URSSAF contributions for 2025 (AE/EI)

    Un décret du 30 Mai 2024 fixe depuis le 1er Juillet l’augmentation des cotisations pour 2025 pour les BNC (et Cipav). Pour une meilleure protection sociale. Auto-entrepreneurs (et EI) : préparez-vous.

    Comme indiqué dans cette première actualité :

    Cela concerne les auto-entrepreneurs affiliés au régime général de la Sécurité sociale et déclarant leur chiffre d’affaires dans la catégorie des BNC. Il s’agit de garantir leurs droits à la retraite complémentaire.

    Source : autoentrepreneur.urssaf.fr

    Un mail de l’URSSAF ce 28 août informe de l’évolution du taux global de cotisations.

    Dérouler pour voir le mail

    Bonjour,

    Vous êtes auto-entrepreneur artisan-commerçant ou en profession libérale non réglementée et vous déclarez votre chiffre d’affaires en bénéfices non commerciaux (BNC).

    Ainsi, chaque mois ou chaque trimestre, vous payez des cotisations et contributions sociales calculées selon un taux global de cotisations appliqué à votre chiffre d’affaires.

    Nous vous informons que depuis le 1er juillet 2024, ce taux global de cotisations de 21,1 % augmente sur trois ans, de façon progressive, comme indiqué sur ce tableau (hors bénéficiaires de l’Acre et auto-entrepreneurs exerçant en outre-mer), selon le calendrier suivant :

    AnnéePériodeTaux global
    2024du 1er juillet au 31 décembre 202423,1 %
    2025du 1er janvier au 31 décembre 202524,6 %
    2026à compter du 1er janvier 202626,1 %

    Pourquoi votre taux augmente-t-il ?

    Votre taux augmente pour vous permettre d’acquérir des droits à la retraite complémentaire des travailleurs indépendants et de bénéficier ainsi d’une protection sociale renforcée.

    Qu‘est-ce que la retraite complémentaire des travailleurs indépendants ?

    La retraite complémentaire des travailleurs indépendants est un complément essentiel à votre retraite de base. En payant chaque mois ou chaque trimestre vos cotisations, vous cumulez des points, qui seront convertis en droits retraite le moment venu.

    Vous bénéficiez de l‘Acre ou vous exercez votre activité en outre-mer ?

    Si vous êtes bénéficiaire de l’Acre ou si vous exercez votre activité en outre-mer, nous vous invitons à consulter votre nouveau taux de cotisations sur les pages L’essentiel du statut – Autoentrepreneur.urssaf.fr.

    Bon à savoir

    Pour vos droits à la retraite complémentaire avant le 1er juillet 2024, un dispositif, en cours de définition par les pouvoirs publics, sera mis en place afin de vous permettre, si vous le souhaitez, de cotiser de manière rétroactive et ainsi d’acquérir des droits.

    Une question ?

    Vous retrouverez toute l’information utile concernant :

    L’Urssaf est à votre disposition pour tout renseignement complémentaire.

    Cordialement.

    Cela recoupe l’information du 10 juillet sur le site officiel.

    Résumé des hausses

    🟢 2024, du 1er juillet au 31 décembre 2024 : 23,1 %
    📈 2025, du 1er janvier au 31 décembre 2025 : 24,6 %
    📈 2026, à compter du 1er janvier 2026 : 26,1 %

    Pourquoi le taux augmente-t-il ?

    L’URSSAF explique dans le mail :

    « Votre taux augmente pour vous permettre d’acquérir des droits à la retraite complémentaire des travailleurs indépendants et de bénéficier ainsi d’une protection sociale renforcée. »

    Et sur le site :

    « La retraite complémentaire constitue un complément essentiel à la retraite de base. Grâce aux cotisations versées, les auto-entrepreneurs cumuleront désormais des points qui seront convertis en droits retraite le moment venu, assurant ainsi une meilleure sécurité financière à long terme. »

    Adaptez-vous

    💡 Pensez bien à :

    • Adapter vos grilles de calcul de cotisations
    • Prévoir si besoin l’adaptation de votre tarification
    • Ré-évaluer la pertinence d’un passage en SARL/EURL et dérivés
    • Ne pas vous laisser avoir par les éventuelles campagnes de phishing (faux emails vous demandant des infos personnelles ou vous redirigeant vers de faux sites) qui pourraient avoir lieu suite à cette annonce.

    Conclusion

    Ce n’est pas forcément la meilleure nouvelle pour la rentrée…

    Mais voyons le côté positif :
    Il reste une chance que l’on touche une retraite. 🤞
    (si, si, on y croit…)

    ———–

    Je suis Robin Labadie, hébergeur web spécialiste WordPress.

    Vous cherchez le meilleur pour vos projets web :

    Contactez-moi !
  • Critical security flaw in the LiteSpeed Cache WordPress plugin: 5 million sites affected

    Critical security flaw in the LiteSpeed Cache WordPress plugin: 5 million sites affected

    Le 19 août 2024, une vulnérabilité critique a été identifiée dans le plugin LiteSpeed Cache, utilisé par plus de 5 millions de sites WordPress. Cette faille permet à un attaquant non authentifié de se faire passer pour un administrateur, compromettant ainsi l’intégrité totale du site.

    Détails Techniques

    La faille a été découverte par WordFence.

    Elle affecte toutes les versions du plugin LiteSpeed Cache jusqu’à la version 6.3.0.1. En exploitant un bug dans la fonction de simulation de rôle, un attaquant peut utiliser un hash pour se faire passer pour un administrateur. Une fois ce hash obtenu, il peut créer un compte administrateur via l’API REST de WordPress, ce qui lui permet de prendre le contrôle du site.

    Le hash utilisé est de seulement six caractères, ce qui le rend vulnérable aux attaques par force brute. De plus, s’il est possible d’accéder aux logs de débogage, ce hash peut être récupéré facilement par un attaquant.

    Que Faire ?

    Ne sous-estimez pas cette vulnérabilité. Les menaces de ce type peuvent rapidement se transformer en catastrophes si elles ne sont pas traitées à temps.

    La solution est simple : mettez à jour LiteSpeed Cache vers la version 6.4.1 ou supérieure. Cette mise à jour corrige la faille.

    Si vous utilisez Wordfence Premium, Care ou Response, une règle de pare-feu a été déployée le 20 août 2024 pour vous protéger. Les utilisateurs de la version gratuite recevront cette protection à partir du 19 septembre 2024.

    Comment rester protégé ?

    Avec le WordPress Toolkit sur les hébergements LRob, vous auriez été alerté automatiquement par mail de la vulnérabilité et la mise à jour aurait pu être automatique 😎. La sauvegarde est complète et quotidienne chez LRob, avec une rétention de 1 an complet !
    Un bon moyen de garder une longueur d’avance sur les menaces de sécurité.

  • From self-taught to WordPress host: 12 years of passion summed up 🚀

    D’autodidacte à hébergeur WordPress : 12 ans de passion résumés 🚀

    En 2012, j’ai créé une communauté geek.

    Je voulais l’héberger moi-même sur serveurs Linux. Car tout le monde sait qu’un serveur digne de ce nom est forcément sous Linux !

    J’entrais sans le savoir dans ma véritable vocation : sysadmin 🌱

    📷 Photo by Manon Laterza – 2012 – Je gère mes serveurs, mes amis jouent à la pétanque à côté. 😂

    Le commencement

    En 2012, on avait besoin : d’un site web (d’abord un forum), d’un serveur de voix et de serveurs de jeux.

    Passionné d’informatique pure depuis 10 ans, j’ai été le seul parmi les 25 personnes à l’initiative du projet, à oser se coller sur cette partie technique, devenant de facto l’administrateur système principal de la communauté.

    Il fallait donc apprendre énormément de choses d’un coup, en partant de rien :

    • choisir un fournisseur de serveurs dédiés (à l’époque : online.net / Dedibox)
    • installer et gérer un serveur Linux (ESXI + Debian) via un terminal headless (SSH)
    • gérer les IP multiples (failover)
    • choisir un registrar pour enregistrer et gérer un nom de domaine
    • gérer une zone DNS
    • gérer un firewall
    • installer un serveur web (LAMP)
    • créer des bases de données MySQL à la main, installer et utiliser phpMyAdmin
    • gérer des fichiers de configuration système et CMS
    • à gérer les droits et permissions sur un forum phpBB
    • Et j’en oublie sûrement

    Dans cette découverte, ma curiosité était insatiable. 😋

    J’ai bossé jour et nuit jusqu’à ce que tout fonctionne ! Ça m’a pris 5 à 7 jours.🌛

    J’ai appris bien plus dans ce court laps de temps qu’en un an de fac d’informatique (arrêtée pour me lancer en auto-entrepreneur en 2010 car je m’ennuyais des cours que je trouvais non pertinents).

    Et ce n’était le début…

    J’avais au final une VM (machine virtuelle) pour le serveur web, une VM pour le serveur voix, et une VM pour les serveurs de jeu. J’aurais pu regrouper les deux dernières, mais j’apprenais et je pensais au début qu’il valait mieux tout séparer au maximum, ce qui au final n’est pas plus mal quand on débute.

    Pendant des années, j’ai exploré les multiples facettes des serveurs. Dont la programmation BASH, devenant second contributeur de LinuxGSM en m’investissant profondément dans le projet open-source.

    Découverte de WordPress

    En 2014 j’ai surtout découvert WordPress ! 😍

    Je l’ignorais, mais WordPress allait devenir un élément central de ma vie professionnelle.

    J’ai d’abord transitionné le site de la communauté d’un forum phpBB vers un site WordPress.

    Devant la découverte de ce CMS génial, j’ai eu envie de faire mon site perso LRob dans la foulée, toujours en 2014. J’ai commencé à héberger et faire des sites pour des amis. Sans même avoir conscience qu’en fait, c’était un véritable métier de sysadmin, webmaster et hébergeur web.

    Coup d’accélérateur

    En 2016, j’ai mis un énorme coup de boost à la gestion serveur web.

    Après des migrations serveur toujours plus propres, la création de mes propres outils et process, la mise en place manuelle de certificats SSL/TLS (pour HTTPS) et pas mal de temps à gérer WordPress, je me suis attaqué au maillon manquant !

    Je me suis mis à faire mes premiers serveurs email à la main, en respectant toutes les normes possibles (rDNS, HELO, SPF, DKIM, DMARC). Et à découvrir les questions de délivrabilité vers Microsoft, difficiles la première fois qu’on déploie un serveur.

    J’ai même crée une série de tutos sur les serveurs Linux, celle que j’aurais rêvé d’avoir quand j’ai débuté.
    De quoi aider les administrateurs système Linux et Web en devenir.

    2017 : de passionné à professionnel

    Jusqu’à 2017, il faut dire ce qui est : ma situation pro était chaotique.

    Très enrichissante, mais chaotique.

    J’ai oscillé entre des prestations en tant qu’ingénieur son, du dépannage informatique en freelance, du tournage et montage vidéo, du support en télétravail (j’étais en avance sur mon temps 😎) et de l’intérim’ pour combler les manques. Mais à 27 ans, j’avais mon prêt étudiant à combler, je voulais améliorer mon niveau de vie et je devais donc stabiliser mes revenus.

    Je me suis dit que mine de rien, je commençais à avoir des compétences en informatique valorisables en entreprise… Il y aurait bien une entreprise avec qui on peut mutuellement s’aider !

    Et là, je crois que j’ai eu le coup de chance de ma vie.

    Dès mon début de recherche d’emploi, j’ai découvert un hébergeur web orléanais : HaiSoft.

    Quelle aubaine ! 🤩

    C’est le seul à qui j’ai envoyé mon CV. Le seul avec qui j’ai passé un entretien. Et ce fut, je crois, le coup de foudre professionnel mutuel.

    Ils ont reconnu en moi l’autodidacte passionné que j’étais. Ils m’ont invité à rejoindre l’équipe.
    Cela marquait début d’une aventure géniale de presque 6 ans. 🤝

    Pendant ces années, me suis professionnalisé tout en apportant mes idées et énergies fraîches pour perfectionner chaque aspect des services. 👌

    HaiSoft mettait la barre très haut, mais rien n’est jamais parfait. 🏋️‍♂️

    Dans une synergie exemplaire, on a résolu les problèmes récurrents, amélioré les documentations, boosté les performances, la sécurité, les mises à jour. On a enrichi l’offre et amélioré la communication. J’ai même eu la latitude de de gérer les baies serveurs ! 🎯

    HaiSoft est un superbe modèle d’entreprise IT, le meilleur selon moi. 🤩

    La parole de chacun est écoutée, la hiérarchie est amicale, transparente et accessible.
    Quiconque peut proposer et mettre en place des améliorations.
    L’implication et l’engagement du salarié deviennent naturels.

    C’est d’ailleurs grâce à cette ouverture qu’à l’époque, étant le plus fervent utilisateur de WordPress, je suis naturellement devenu, sans que cela ne soit vraiment acté, le référent support WordPress. J’ai pu pousser des services et prestations spécifiques pour WordPress et former toute l’équipe à ces tâches.

    Les humains derrière tout ça sont géniaux ! 🤗

    J’en profite pour remercier les membres de l’équipe, qui me sont encore chers à ce jour :

    • Frédéric, pour être un patron exceptionnellement droit et soucieux
    • Damien, pour ta vision d’ensemble toujours pertinente
    • Benoît, pour être un éternel mentor, avec ta curiosité, rigueur et droiture consistante
    • Dylan, pour avoir encore amélioré l’idéal de la relation client
    • Arthur, pour être à l’écoute et relever les défis de développement
    • Jérôme, pour la découverte d’un autre univers et les bonnes discussions

    Merci pour tout ! 💖

    👉 HaiSoft continue de briller par sa qualité grâce à tout ce petit monde, et les nouveaux. Chaque fois que j’ai des nouvelles d’eux, j’apprends la mise en place d’évolutions et solutions géniales.

    Alors si mon expertise WordPress ne vous est pas utile : foncez chez eux !
    Vous nous remercierez plus tard. 😉

    🌐 Agence web

    Les années passant, j’ai quand même voulu évoluer et ré-entreprendre.
    Je me suis mis à faire plus de sites web, d’abord pour des amis, puis des pros… A proposer du webmastering WordPress.

    Fin 2022, j’ai pris un risque calculé : quitter HaiSoft pour rejoindre une agence web et remettre d’aplomb leur parc d’hébergement. 🪛

    On sait ce qu’on perd, mais jamais ce qu’on gagne. Alors j’ai préparé mon avenir d’indépendant.

    Dans la courte transition entre les deux jobs, à la vitesse de l’éclair, j’ai déployé ma propre infrastructure de web hosting. ⚡

    Puis, en quelques mois, j’ai rénové les serveurs de l’agence qui m’embauchait : amélioré les performances, la sécurité, les backups, simplifié la gestion, tout en réduisant drastiquement les coûts serveurs. 🔒

    ⏩ Tournant Freelance

    Début 2023, grande surprise : départ en retraite de mes nouveaux patrons !

    L’agence web dans laquelle je mettais en place mes plans à long terme a ainsi été vendue.

    Au début, j’étais enthousiasmé par ce changement, ça ouvrait des portes fabuleuses.
    Sauf que… La nouvelle hiérarchie bloquait tous les budgets des évolutions prévues. J’ai cru que c’était temporaire, mais en discutant avec la hiérarchie en direct, j’ai compris que ça ne mènerait à rien. 😅

    L’équipe se sentait abandonnée, lésée. Certains parlaient de partir. L’ambiance était extrêmement négative et pesante. Je ne pouvais plus faire mon travail correctement et certaines urgences ne pouvaient pas être traitées. Si auparavant j’étais fier du travail accompli et en route, désormais je ne voulais surtout plus mettre mon nom sur le désastre que je voyais se tramer devant nous.

    Mon temps méritait mieux que ça ! ⌚

    Parallèlement, mon activité de freelance commençait à décoller alors même que je ne faisais rien d’autre que d’en parler un peu autour de moi. Me lancer dans cette tâche à fond ne pouvait que marcher !

    Alors, j’ai franchi le cap :

    • Poser ma démission le premier (d’autres ont ensuite suivi)
    • Passer en 100% freelance ! 🚀

    Sûrement la meilleure décision de ma vie !

    Non-seulement j’arrive à en vivre confortablement, mais j’éprouve une satisfaction que je n’aurais jamais oser imaginer !

    J’ai l’infrastructure d’hébergement rêvée : la plus belle, fiable et sécurisée.

    Et j’ai surtout le bonheur d’accompagner chaque jour des clients exceptionnels. 💘

    👉 Pour réussir avec WordPress découvrez mes hébergements WordPress !

    Hébergements web LRob

    PS: Merci Enzo Deniau pour avoir inspiré ce post par tes questions.

    Article enrichi depuis mon post LinkedIn.

  • Free migration to LRob in August!

    Free migration to LRob in August!

    Votre site est trop lent ? Insécurisé ? Vous perdez du temps à le gérer ?
    ▶️ La migration vers LRob est offerte durant le mois d’août ! 👌

    Vous travaillez en plein août au lieu de boire des Mojitos à Ibiza ? 🍸
    Vous profitez de l’accalmie pour vous organiser et vous améliorer ? 💪

    Soyez enfin récompensés ! 🥇

    👉 Pour toute souscription d’hébergement annuel LRob, la migration de vos sites et emails est offerte !

    La migration est complète et comporte :
    ✅ Changements DNS intelligents pour une migration sans coupure
    ✅ Migration des fichiers et de la base de données de votre site
    ✅ Migration jusqu’à 5 boîtes mail
    ✅ Génération des certificats SSL/TLS pour la connexion web et mail sécurisée
    ✅ Vérification de votre instance WordPress et conseils personnalisés

    ℹ️ Vous avez plusieurs sites ou davantage de boîtes mail ?
    Bénéficiez d’une remise de groupe aussi ! 👌

    On rappelle les « plus » LRob :
    ➕ Hautes performances garanties
    ➕ Sécurités anti-robots anti-hack, alertes en cas de faille dans votre site
    ➕ WordPresss Toolkit (login one-click, mises à jour auto, sécurisations, gestion des plugins même en cas de bug sur le site, etc.)
    ➕ Conseil d’expert WordPress et aide au débug
    ➕ Sauvegarde quotidienne externalisée avec 1 an de rétention !

    Qu’entends-je ? Qu’acousticais-je ? 👂
    « 💲hut up and take my money ? »

    Pour un site 👉 https://portail.lrob.fr/produit/hebergement-wordpress/
    Pour 3 à 128 sites 👉 https://portail.lrob.fr/produit/hebergement-web-agency/
    Pour le webmastering inclus 👉 https://portail.lrob.fr/produit/webmastering-wordpress/

    Happy hosting ! 😎

  • A flaw in the Apache web server affects millions of servers

    A flaw in the Apache web server affects millions of servers

    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.

  • [Resolved] o2switch customers targeted by insidious WordPress hack - UPDATE: Hosting provider is handling this in an exemplary manner

    [Résolu] Des clients o2switch ciblés par un hack WordPress insidieux – MAJ : L’hébergeur traite cela de manière exemplaire

    Identification & causes : tout ce qu’il faut savoir 👇

    La semaine dernière, je révélais sur LinkedIn un piratage à priori répandu chez les possesseurs de sites WordPress hébergés chez o2switch. En qualité d’expert sécurité WordPress et grâce à une investigation auprès de quelques confrères touchés et non touchés, nous avons pu en apprendre davantage.

    MAJ 31/07/2024 – En résumé

    Selon une source en interne, l’hébergeur ne serait vraiment pas en cause. L’hypothèse d’un entretien insuffisant des sites piratés resterait ainsi privilégiée. Toujours selon cette source interne, les moyens mis en place par l’hébergeur pour déterminer l’origine précise de ce souci sont remarquables (quelques exemples m’ont été donnés, j’approuve la stratégie). Enfin, même si le nombre de sites impactés peut sembler élevé, il faut mettre cela en perspective avec le parc important d’o2switch : l’impact réel resterait très limité en proportion et la vaste majorité des clients ne devrait pas être impactée par ce souci spécifique.

    De plus, le soir du 30/07/2024, o2switch a fait un geste remarquable et très rare dans le monde des gros hébergeurs, en nettoyant le hack sur les sites impactés. Une réaction courageuse qui m’a surpris de la part d’un hébergeur. En effet, les plus gros hébergeurs ont plutôt tendance à avoir l’habitude inverse, c’est à dire de laisser les clients se débrouiller lorsque le souci vient des sites finaux en eux-même. L’investissement de l’hébergeur est réel ici et suscite mon plus grand respect.

    On rappelle qu’en sécurité, le plus important est la prévention : faites la maintenance de votre site avec les mises à jour automatiques, de bonnes sauvegardes et n’oubliez pas de d’utiliser les dernières versions de PHP compatibles. Si besoin d’aide pour cela, c’est ma spécialité 😉

    📄 Mode opératoire du hack

    Le hack redirige les utilisateurs mobile vers des sites frauduleux, notamment en rapport avec la guerre Ukraine/Russie via un URL shortener hébergé aux Emirats Arabes Unis.

    Techniquement il consiste en une injection de code JavaScript obfusqué dans tous les posts WordPress du site. Il est donc chargé dans les pages et articles et parfois dans d’autres plugins comme les plugins de cookies, les plugins d’avis utilisateurs, etc.

    Voici un aperçu du code pirate après dé-obfuscation, qui permet même sans parler ce langage de comprendre que l’action a lieu lors du clic et qu’une URL aléatoire est sélectionnée en fonction du « UserAgent », c’est à dire du navigateur utilisé :

    Aperçu du code pirate après dé-obfuscation

    Info additionnelle 31/07/2024

    La requête effectuant le hack pourrait être une simple requête POST sur le fichier index.php du site, comme un log le suggère, qui semble correspondre à un hack effectif depuis une IP américaine (IP et site masqués) :

    Jul-2024:213287:199.195.252.[HIDDEN] - - [27/Jul/2024:20:10:59 +0200] "POST /index.php?s=captcha HTTP/1.1" 200 102292 "https://www.[HIDDEN].fr/index.php?s=captcha" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; InfoPath.3; .NET4.0C; .NET4.0E) chromeframe/8.0.552.224"

    On voit ici une requête de 102292 bytes faite sur l’index, ce qui est 100x plus élevé par rapport aux requêtes habituelles de l’ordre de 1000 bytes. D’autant que ce site n’a pas de Captcha… Ce qui est troublant est que la requête résulte en un code 200, ce qui signifie que la requête est acceptée, traitée sans erreur, alors que la visite de cette URL devrait plutôt donner une erreur 404 (Not Found).

    🔍 Identification

    • Le hack est parfois mal inséré dans les articles et s’affiche de manière textuelle dans le corps des pages au lieu de s’exécuter
    • La plupart du temps il est invisible, vous pouvez vérifier si votre site est impacté en recherchant « _0x365b », ou « 0x3023 », ou « function _0x », via l’inspecteur de votre console développeur à la visite du site, ou via une recherche dans phpMyAdmin
    • Les antivirus Eset et Avast bloquent l’accès aux sites touchés
    • Update 31/07/2024 – L’un des sites touchés ne se voit pas via la console développeur, il faut à la place utiliser l’outil en lignes de commandes « curl » pour observer le code malveillant. Il est possible que cela soit dû au cache du site.

    Voici un exemple du code pirate tel que visible depuis la console développeur :

    Exemple code pirate

    🌐 Répartition du hack

    Grâce à une recherche du pattern du hack sur Google et Bing, j’ai trouvé de nombreux sites infectés. J’ai contacté l’ensemble des propriétaires des sites pour les alerter, leur conseiller de contacter leur prestataire et leur proposer mon aide si besoin.

    • Sur 40 domaines impactés, trouvés en France et en Belgique, 2 seulement ne sont pas chez o2switch – update 30/07/2024 : Certains sites chez OVH, Hostinger et divers hébergeurs sont aussi touchés, mais plus rares pour le moment.
    • D’autres fournisseurs de serveurs étrangers sont touchés mais j’en ai trouvé moins qu’en France.
    • Cela laisse penser à une attaque ciblée des sites présents sur les IP o2switch, que le hacker aurait trouvé via des listes publiques qui référencent cela. Ce type d’attaques peut cibler n’importe quel hébergeur qui n’y peut strictement rien. C’est pour cela qu’il faut être pro-actif dans votre sécurité.

    💡 Des causes toujours incertaines

    Voici ce qu’on a pu voir et déduire en recoupant les infos entre confrères :

    • Comme le hack est insidieux, beaucoup ne sont pas diagnostiqués et détectés rapidement, mais la plus ancienne occurrence semble avoir eu lieu en Mai – update 30/07/2024 potentiellement plutôt en Juillet
    • Cela ne touche pas un plugin ou un thème spécifique
    • Le plugin Tiger d’o2switch ne semble donc pas non-plus être la cause du problème, car des sites sans ce plugin sont touchés
    • Les sites touchés semblent généralement moins entretenus que les autres, mais c’est le cas de la plupart des sites; et des sites assez bien suivis (peut-être pas assez) sont aussi touchés
    • La faille exploitée a pu provenir du core de WordPress lorsque non mis à jour assez rapidement
    • Il est possible que cela provienne de l’utilisation d’une version PHP obsolète définie par le gestionnaire de l’hébergement (client final)
    • Il est possible que la présence d’une seconde instance WordPress (une instance de dev par exemple) dans l’hébergement, qui elle, ne serait pas à jour, puisse déteindre sur l’instance principale, par manque d’isolation (c’est le même hébergement, le même utilisateur système, les mêmes droits, et il ne semble pas y avoir de règle open_basedir pour restreindre le répertoire au niveau de PHP chez o2switch)
    • Cela ne touche pas les clients d’un serveur spécifique d’o2switch, ils sont répartis sur de plusieurs serveurs mutualisés, et certains serveurs ne sont pas du tout touchés, laissant entendre un souci marginal (donc pas d’intrusion serveur ou hébergeur global)
    • Il y a une minuscule probabilité pour qu’une intrusion ou une faille hébergeur plus globale aie eu lieu (par exemple une faille dans un paquet système qui permet le hack), mais nous n’avons aucun élément pour le vérifier et dans la mesure où o2switch n’a rien signalé, il est plus raisonnable de penser que le souci provient de l’applicatif final (WordPress) ou de la version de PHP utilisée par le client final.
    • – Update 29/07/2024 Il est enfin possible qu’une faille du serveur web Apache aie été exploitée, soit lorsqu’elle n’était pas encore correctement corrigée, soit car o2switch a trop tardé à mettre à jour ses versions logicielles. Les dates semblent concorder pour les hacks les plus récents. Là encore aucune certitude sans une annonce officielle de l’hébergeur.
    • – Update 31/07/2024 Des failles dans des sous-versions de PHP, notamment dans certaines révisions de PHP 8.0 pourraient expliquer le piratage. Cela concorde avec les requêtes observées pouvant causer un buffer overflow et permettre un injection de code. Si les sous-versions de PHP 8.0 de l’hébergeur ne sont pas à jour, cela explique la possibilité du hack. Quoi qu’il en soit, le client est fautif si c’est la cause, car on rappelle que PHP 8.0 est dans tous les cas obsolète et ne devrait plus du tout être utilisé. Il n’est d’ailleurs plus disponible à la sélection sur les hébergements LRob.
    • Aucun hack à déplorer sur les hébergements LRob.

    🔨 Réparation du hack

    La réparation consiste à nettoyer la base de données en effaçant les lignes correspondant au pattern du hack. Avant toute opération, sauvegardez votre base de données. Les fichiers des sites web ne semblent pas impactés sur ce hack, mais une vérification manuelle complète est toujours recommandée comme pour tout hack. Pensez aussi à vider les différents caches pour que le code malveillant en soit également retiré.

    Besoin d’aide pour réparer vos sites et rester sécurisé à l’avenir ? Découvrez mes services de réparation et sécurisation WordPress ainsi que mes hébergements WordPress sécurisés.

    Si vous avez plus d’infos, partagez-les en commentaires ou MP !