Urgent : Connexion sans mot de passe OwnID (<= 1.3.4) — Contournement d'authentification (CVE-2025-10294)

Avis et conseils de mitigation — publié le 15 octobre 2025. Écrit du point de vue d'un expert en sécurité de Hong Kong : direct, pratique et axé sur la containment et la récupération.

Résumé exécutif

• CVE-2025-10294 est un contournement d'authentification dans la connexion sans mot de passe OwnID (≤ 1.3.4).
• Exploitable par des attaquants non authentifiés — aucun accès préalable requis.
• Impact : usurpation d'identité des utilisateurs (y compris des administrateurs), prise de contrôle complète du site, portes dérobées persistantes, vol de données.
• Aucun correctif du fournisseur disponible au moment de la publication — des mesures de mitigation immédiates sont nécessaires.
• Actions principales : désactiver le plugin ou bloquer ses points de terminaison, appliquer des correctifs virtuels ou des règles serveur, faire tourner les sels d'authentification et les identifiants sensibles, auditer les comptes et les fichiers, et restaurer à partir de sauvegardes propres si une compromission est détectée.

Quel est le problème (technique, simplifié)

Les flux de connexion sans mot de passe reposent sur une validation minutieuse côté serveur des preuves d'authentification (liens magiques, réponses WebAuthn, rappels signés). La vulnérabilité ici est un échec de logique/validation dans les gestionnaires de rappels d'authentification d'OwnID : certains points de terminaison ou chemins de code ne vérifient pas suffisamment la preuve avant de créer une session WordPress. En conséquence, des requêtes élaborées peuvent être acceptées comme légitimes et amener WordPress à traiter le demandeur comme l'utilisateur ciblé.

Attributs clés :

• Privilège de l'attaquant : non authentifié.
• Vecteur d'attaque : requêtes HTTP vers les points de terminaison REST/AJAX/callback du plugin.
• Impact : usurpation complète de compte, prise de contrôle potentielle de l'administrateur, compromission du site.

Comment les attaquants sont susceptibles d'exploiter cela

1. Découvrir les sites exécutant le plugin vulnérable en scannant les actifs du plugin, les espaces de noms REST connus ou les en-têtes caractéristiques.
2. Interroger les points de terminaison liés à OwnID pour déterminer le comportement.
3. Envoyer des charges utiles conçues qui déclenchent la logique de validation défectueuse, provoquant la création de session ou le réglage de cookies pour un utilisateur cible (souvent un administrateur).
4. Utiliser l'accès pour créer des comptes administrateurs, télécharger des webshells, modifier du contenu et exfiltrer des données.

L'exploitation est simple à automatiser ; le scan et l'exploitation de masse peuvent entraîner des compromissions rapides et généralisées.

Risque immédiat pour votre site

Si votre site WordPress accessible au public exécute OwnID Passwordless Login ≤ 1.3.4, supposez un risque élevé. Les attaquants automatisés cibleront d'abord les comptes administrateurs. N'attendez pas une mise à jour officielle du plugin — agissez maintenant.

Détection — signes que votre site pourrait déjà être compromis

Vérifiez ces indicateurs immédiatement :

• Nouveaux comptes administrateurs dans la base de données. Exemple de requête :

  SELECT ID, user_login, user_email, user_registered
  FROM wp_users
  WHERE ID IN (
    SELECT user_id
    FROM wp_usermeta
    WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%'
  )
  ORDER BY user_registered DESC;

• Journaux du serveur web montrant des POST répétés vers des points de terminaison REST/AJAX liés à ownid ou des chaînes de requête inhabituelles contenant “ownid”, “passwordless”, “magic-link”, etc.
• Cookies de session ou d'autorisation étant définis après des requêtes vers des points de terminaison du plugin.
• Modifications inattendues de wp_options, wp_posts, fichiers de plugin ou de thème.
• Fichiers PHP dans uploads ou d'autres répertoires non codés.
• Connexions sortantes initiées par des processus PHP vers des domaines inconnus.
• Tâches cron programmées inattendues dans wp_options.

Si vous observez l'un des éléments ci-dessus, considérez le site comme potentiellement compromis et procédez d'urgence aux étapes de confinement et d'analyse judiciaire.

Étapes de confinement immédiates (priorisées)

1. Désactivez le plugin immédiatement.
   • Si vous avez accès à WP Admin : désactivez OwnID Passwordless Login via l'écran des plugins.
   • Si WP Admin n'est pas disponible : renommez ou supprimez le dossier du plugin via SFTP/SSH (par exemple, renommer wp-content/plugins/ownid à ownid.désactivé), ce qui empêche le code vulnérable de s'exécuter.
2. Bloquez les points de terminaison du plugin au niveau du serveur web ou via WAF.

   Si vous ne pouvez pas désactiver le plugin pour des raisons de disponibilité, bloquez immédiatement l'accès HTTP aux points de terminaison REST/AJAX/callback du plugin. Voir des exemples de règles ci-dessous.

3. Faites tourner les sels et les clés d'authentification.

   Générez de nouvelles valeurs AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY et NONCE_KEY dans wp-config.php (utilisez le générateur de clés secrètes de WordPress.org). Cela invalide les cookies existants et force la ré-authentification.

4. Forcez la réinitialisation du mot de passe et faites tourner les identifiants critiques.
   • Réinitialisez les mots de passe de tous les comptes administrateurs.
   • Faites tourner les identifiants de service, les clés API et les jetons OAuth stockés sur le serveur.
5. Auditez et supprimez les comptes inconnus. Examinez attentivement tous les comptes utilisateurs et supprimez les administrateurs non autorisés. Enregistrez les ID utilisateurs et les artefacts associés pour enquête.
6. Scannez à la recherche de logiciels malveillants et de portes dérobées. Utilisez un scanner d'intégrité des fichiers et un scanner de malware réputé pour trouver des fichiers de cœur/plugin/thème modifiés et des fichiers PHP dans les téléchargements.
7. Prenez des instantanés judiciaires. Dans la mesure du possible, prenez un instantané du système de fichiers et de la base de données avant d'apporter des modifications destructrices. Si une action immédiate est nécessaire, priorisez la containment et notez les horodatages et les journaux pour une analyse ultérieure.
8. Si la compromission est confirmée — restaurez à partir d'une sauvegarde propre. Restaurez à partir d'une sauvegarde effectuée avant la compromission. Après la restauration, réappliquez les étapes de containment et faites tourner les secrets.
9. Informez votre hébergeur et augmentez la journalisation. Activez les journaux d'accès détaillés et la surveillance des processus. Informez votre fournisseur d'hébergement afin qu'il puisse aider à bloquer les IP offensantes et à la containment au niveau du réseau.

Règles de patch virtuel / WAF recommandées (appliquez maintenant)

Le patch virtuel (blocage des points de terminaison vulnérables à la périphérie) est la mitigation la plus rapide jusqu'à ce qu'un correctif officiel du plugin soit publié. Testez d'abord les règles en staging pour éviter de casser le trafic légitime.

Exemple de règle Nginx pour bloquer l'espace de noms REST OwnID :

# Refuser les requêtes à l'espace de noms REST OwnID

Exemple de règle Apache/.htaccess :

# Bloquer les points de terminaison REST OwnID

Exemple de snippet ModSecurity (SecRule) :

SecRule REQUEST_URI "@rx ^/wp-json/(ownid|ownid-.*)"

Bloquez les actions AJAX connues (si le plugin utilise les paramètres d'action admin-ajax.php) :

# Exemple : bloquer les requêtes admin-ajax qui contiennent des actions ownid

Autres mesures de protection à mettre en œuvre au niveau de la périphérie ou du serveur :

• Limitez le taux des requêtes vers les points de terminaison spécifiques au plugin et vers les chemins de connexion administratifs.
• Bloquez les requêtes qui manquent des en-têtes nonce ou de signature attendus.
• Restreindre l'accès POST aux points de terminaison du plugin aux plages IP connues lorsque cela est applicable.
• Refuser les demandes avec des charges utiles suspectes (tokens vides, paramètres trop volumineux ou motifs cohérents avec des tentatives d'exploitation).
• Surveiller et alerter sur les pics de demandes vers les chemins liés à ownid/passwordless.

Contre-mesures pratiques au niveau du serveur (règles rapides que vous pouvez ajouter maintenant)

• Restreignez l'accès à wp-login.php et /wp-admin par IP lorsque cela est faisable.
• Ajouter une règle de serveur web pour refuser les demandes contenant des chaînes liées à l'espace de noms REST du plugin (ownid, passwordless, etc.).
• Désactiver temporairement l'accès à l'API REST non authentifié en utilisant un mu-plugin léger qui refuse les demandes vers des points de terminaison suspects (tester soigneusement pour éviter de casser les consommateurs légitimes de l'API).

Exemple de mu-plugin pour bloquer les appels REST communs d'ownid (solution temporaire) :

<?php;

Remarque : testez tout mu-plugin en staging avant la production. Supprimez le mu-plugin une fois que le plugin officiel est corrigé et que vous avez validé le comportement.

Comment valider que votre site est propre (post-confinement)

Après avoir désactivé le plugin et appliqué des blocs edge/serveur, exécutez ces vérifications :

1. Rechercher des comptes administrateurs inconnus et les supprimer.
2. Confirmer wp-config.php que les sels/clés ont été mis à jour.
3. Scanner le système de fichiers pour les fichiers récemment modifiés (utiliser trouver avec les paramètres appropriés -mtime).
4. Trouvez des fichiers PHP dans les téléchargements : trouver wp-content/uploads -type f -name "*.php"
5. Vérifiez les tâches planifiées inattendues (inspectez l'interface utilisateur cron de WP Admin ou wp_options l'entrée cron).
6. Inspectez la base de données pour des options suspectes, des widgets indésirables ou du contenu injecté.
7. Examinez les journaux du serveur web pour des POSTs continus ou des agents utilisateurs inhabituels liés aux points de terminaison ownid.
8. Re-scanner avec un scanner de malware de confiance et effectuer des vérifications d'intégrité des fichiers.

Si vous trouvez des portes dérobées ou des preuves de persistance, restaurer à partir d'une sauvegarde connue comme propre est l'approche de récupération la plus fiable. Après la restauration, réappliquez les mesures de confinement et faites tourner tous les secrets.

Étapes de récupération et durcissement à long terme

• Restaurez à partir d'une sauvegarde propre si la compromission est confirmée.
• Gardez immédiatement le plugin vulnérable désactivé après la récupération jusqu'à ce qu'un correctif du fournisseur soit disponible et vérifié.
• Faites tourner toutes les identifiants et générez de nouveaux sels d'authentification dans wp-config.php.
• Exigez l'authentification à deux facteurs (2FA) pour tous les comptes administrateurs.
• Appliquez des politiques d'administration avec le moindre privilège et limitez le nombre de comptes administratifs.
• Activez la surveillance des changements de fichiers et des analyses régulières de malware.
• Utilisez des sauvegardes automatisées hors site et validez régulièrement l'intégrité des sauvegardes.
• Surveillez les journaux et l'activité des utilisateurs pendant au moins 30 jours après l'incident pour détecter des signes de réinfection.

Conseils aux développeurs (pour les auteurs de plugins/thèmes et les intégrateurs)

• Validez toujours les preuves d'authentification côté serveur ; ne faites pas confiance aux assertions côté client.
• Validez strictement les signatures numériques, les nonces, les tokens CSRF et les horodatages.
• Assurez-vous que les cookies d'authentification ne sont définis qu'après une vérification cryptographique complète.
• Minimisez les points de terminaison personnalisés qui peuvent définir l'état d'authentification ; lorsque cela est possible, réutilisez les flux de connexion du cœur de WordPress.
• Ajoutez une journalisation complète pour les flux d'authentification et limitez le taux des points de terminaison qui peuvent être abusés.

Liste de contrôle des indicateurs de compromission (scan rapide)

• Utilisateurs de niveau administrateur inattendus créés au cours des 30 derniers jours.
• Horodatages de modification récents sur des fichiers de thème/plugin actifs que vous ne vous attendiez pas à voir.
• Fichiers PHP dans wp-content/uploads ou d'autres répertoires non codés.
• Connexions réseau sortantes des processus PHP vers des hôtes inconnus.
• Nouvelles tâches cron planifiées que vous n'avez pas configurées.
• Pics de requêtes vers des points de terminaison de l'API REST correspondant à des chemins liés à ownid.

Liste de contrôle finale priorisée

1. Si OwnID Passwordless Login est installé : désactivez-le ou supprimez-le immédiatement.
2. Si vous ne pouvez pas le désactiver : bloquez ses points de terminaison REST/AJAX via des règles de serveur web ou de périphérie.
3. Faites tourner les clés/salages de WordPress dans wp-config.php pour invalider les sessions.
4. Forcez les réinitialisations de mot de passe pour les administrateurs et faites tourner les identifiants critiques.
5. Auditez les utilisateurs, les plugins, les thèmes et les fichiers de base pour détection de falsification.
6. Analysez et, si nécessaire, restaurez à partir d'une sauvegarde connue comme propre.
7. Déployez des règles de périphérie/serveur et activez la surveillance continue et les vérifications d'intégrité des fichiers.
8. Renforcez l'accès administrateur : 2FA, privilège minimal, sauvegardes de routine et surveillance.

Réflexions finales

Les contournements d'authentification dans les plugins qui retravaillent les flux de connexion sont parmi les risques les plus graves pour les sites WordPress — ils convertissent le code d'authentification en un vecteur d'accès direct. Dans le climat de menace actuel, une containment rapide (désactiver ou bloquer) et une validation judiciaire sont essentielles. Priorisez d'abord les sites à forte valeur (eCommerce, fort trafic). En cas de doute, supposez un compromis et suivez les procédures de containment, de nettoyage et de récupération.

Si vous avez besoin d'aide pour mettre en œuvre les étapes de containment ci-dessus, engagez des ressources de réponse aux incidents ou votre fournisseur d'hébergement pour des blocages au niveau du réseau et un soutien judiciaire.