Etiqueta: auditoría seguridad

Inyección SQL en WordPress: qué es y por qué es crítica

La inyección SQL es uno de los ataques más peligrosos que he visto en mi carrera profesional analizando sitios comprometidos. Se trata de un vector de ataque que explota la forma en que tu WordPress interactúa con la base de datos, permitiendo a un atacante ejecutar comandos SQL maliciosos directamente en tu base de datos. En la práctica, cuando un plugin o tema vulnerable concatena datos del usuario directamente en una consulta sin sanitizar, el atacante puede alterar esa consulta para robar información, modificar contenidos o incluso obtener acceso administrativo.

Cuando analizo un sitio WordPress infectado por inyección SQL, lo primero que encuentro es acceso no autorizado a la base de datos. Los atacantes suelen extraer hashes de contraseñas de administrador, insertar usuarios ocultos, modificar publicaciones para inyectar redirecciones maliciosas, o robar información de clientes (especialmente en tiendas WooCommerce). El daño es silencioso: el sitio sigue funcionando mientras el atacante opera en la sombra.

Vectores de ataque comunes en WordPress

Plugins y temas desactualizados con vulnerabilidades conocidas

La mayoría de inyecciones SQL en WordPress provienen de plugins populares con vulnerabilidades documentadas en el National Vulnerability Database (NVD). Plugins de formularios, galerías, constructores de páginas y plugins de SEO suelen ser objetivos frecuentes. Lo que recomiendo siempre es revisar el changelog de cada plugin instalado y verificar si tu versión actual contiene parches de seguridad.

He encontrado sitios infectados donde el propietario tenía un plugin de formularios desactualizado desde hace 18 meses. El atacante ni siquiera necesitaba acceso de usuario registrado: simplemente enviaba datos maliciosos a través del formulario y la inyección SQL se ejecutaba automáticamente.

Parámetros GET/POST sin validación en código personalizado

Si tu tema o plugin personalizado accede directamente a $_GET, $_POST o $_REQUEST sin usar las funciones de WordPress como sanitize_text_field() o intval(), estás creando una puerta abierta. Cuando reviso código custom, busco patrones como:

$user_input = $_GET['search'];
$results = $wpdb->query("SELECT * FROM posts WHERE title = '$user_input'");

Esto es vulnerable. Un atacante podría enviar: search=' OR '1'='1 y extraer toda la base de datos.

Búsquedas sin prepared statements

WordPress proporciona $wpdb->prepare() específicamente para esto, pero muchos desarrolladores lo ignoran. La versión segura sería:

$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM $wpdb->posts WHERE post_title = %s",
        $user_input
    )
);

Los placeholders %s (string), %d (integer) y %f (float) escapen automáticamente los datos maliciosos.

Signos de que tu WordPress ha sido atacado por inyección SQL

No siempre es obvio detectar una inyección SQL. A diferencia de un ransomware, el atacante intenta permanecer invisible. Estos son los indicadores que busco cuando analizo un sitio:

• Usuarios administrativos ocultos: Accede a tu base de datos (via phpMyAdmin) y revisa la tabla wp_users. ¿Hay cuentas que no creaste? Especialmente con nombres como «admin2», «test», «support».
• Publicaciones modificadas sin tu participación: Revisa el historial de revisiones en el editor de WordPress. Si hay cambios que no hiciste, algo sucedió.
• Redirecciones o scripts inyectados en el footer: Examina el archivo wp-config.php y los themes activos buscando código de redirección agregado.
• Aumento inexplicable del uso de la base de datos: Sitios atacados suelen tener queries lentas. Usa plugins como Query Monitor para detectarlo.
• Google Search Console muestra «Malware detectado»: Google analiza tu sitio continuamente y alerta sobre contenido malicioso.
• Registros de error del servidor con intentos de acceso a archivos: Revisa los logs (generalmente en /var/log/apache2/) buscando patrones de fuzzing o acceso a ../wp-admin.

Proceso de limpieza correcta de inyección SQL

Paso 1: Identificación y aislamiento

Lo primero que hago es no entrar en pánico y no eliminar datos. Aunque parezca contradictorio, una limpieza apresurada puede destruir evidencia o hacer el sitio peor.

Conéctate a tu base de datos mediante phpMyAdmin (o Adminer) y ejecuta este comando para buscar patrones SQL inyectados comunes:

SELECT * FROM wp_postmeta 
WHERE meta_value LIKE '%union%' 
OR meta_value LIKE '%select%' 
OR meta_value LIKE '%insert%';

También revisa la tabla wp_posts filtrando por post_modified reciente:

SELECT ID, post_title, post_modified, post_author 
FROM wp_posts 
WHERE post_modified > DATE_SUB(NOW(), INTERVAL 7 DAY) 
ORDER BY post_modified DESC;

Esto te mostrará qué contenido fue modificado recientemente por el ataque.

Paso 2: Backup limpio previo al ataque

Antes de tocar nada, necesitas localizar un backup anterior a que el ataque ocurriera. Si usas WordPress.org Backups o un plugin como UpdraftPlus, revisa las fechas. Si no tienes backup limpio, lo mejor es trabajar sobre una copia de la base de datos actual para experimentar sin riesgo.

Paso 3: Eliminación de usuarios maliciosos

Una vez identificados los usuarios sospechosos en wp_users, elimínalos correctamente. No los borres directamente de la base de datos sin revisar primero qué contenido crearon. Desde el panel WordPress:

1. Ve a Usuarios > Todos los usuarios
2. Selecciona el usuario sospechoso
3. Elimina al usuario y asigna su contenido a un usuario legítimo (o elimínalo también)

Si necesitas eliminarlo por base de datos directamente (porque está oculto), usa:

DELETE FROM wp_users WHERE user_login = 'nombre_sospechoso';
DELETE FROM wp_usermeta WHERE user_id = 123;

Reemplaza 123 con el ID real del usuario.

Paso 4: Limpieza de posts comprometidos

Revisa cada post modificado durante el período de ataque. Busca:

• Scripts inyectados en el contenido visible o en campos ocultos
• Cambios de redirecciones en URLs
• Inserciones de iframes maliciosos
• Código base64 o ofuscado

Si encuentras contenido malicioso, edita el post y elimina manualmente el código. WordPress guarda revisiones, así que puedes revertir a una versión anterior si lo necesitas.

Paso 5: Análisis del plugin/tema vulnerable

Ahora necesitas identificar cómo el atacante entró. Revisa los logs del servidor buscando el patrón de la inyección SQL:

grep -i "union|select|insert|drop" /var/log/apache2/access.log | head -20

Esto te mostrará las URLs que contenían comandos SQL. Una vez identificado el plugin vulnerable:

1. Desactívalo inmediatamente
2. Accede a NVD o Wordfence Threat Intelligence para buscar si es una vulnerabilidad conocida
3. Si existe actualización disponible, actualiza el plugin
4. Si no existe parche o el plugin está abandonado, elimínalo permanentemente

Paso 6: Hardening post-limpieza

Una vez limpio el sitio, implementa estas medidas para evitar reinfecciones:

• Cambiar todas las contraseñas: Admin, FTP, base de datos, hosting. El atacante puede haber robado hashes.
• Deshabilitar edición de archivos: Agrega esto a wp-config.php:

  define('DISALLOW_FILE_EDIT', true);

• Proteger wp-login.php: Implementa 2FA usando Two-Factor Authentication o limita intentos de login con reglas .htaccess:

  <Directory /var/www/html/wp-login.php>
  order allow,deny
  allow from all
  </Directory>

• Actualizar WordPress y plugins regularmente: Configura actualizaciones automáticas para parches de seguridad críticos.
• Cambiar prefijo de tablas de base de datos: Por defecto es wp_. Un atacante ya conoce esto. Considera cambiar a algo como abc123_ (requiere herramientas especializadas).
• Implementar CSP (Content Security Policy): Previene ejecución de scripts inyectados. Agrega a .htaccess:

  <IfModule mod_headers.c>
  Header set Content-Security-Policy "default-src 'self';"
  </IfModule>

Paso 7: Monitoreo continuo

Después de la limpieza, establece alertas. Uso herramientas como:

• Wordfence: Monitorea cambios de archivos, intentos de acceso sospechosos y actualiza automáticamente plugins.
• WP Security Audit Log: Registra cada acción en WordPress para detectar comportamiento anómalo.
• Google Search Console: Notifica si Google detecta malware nuevamente.
• HSTS (HTTP Strict Transport Security): Fuerza HTTPS y previene ataques man-in-the-middle que podrían inyectar código.

Herramientas profesionales para análisis forense

Si sospechachas de una inyección SQL pero no sabes dónde buscar, estas herramientas aceleran el proceso:

• WP-CLI: Línea de comandos de WordPress. Usa wp db query para ejecutar búsquedas en la base de datos rápidamente.
• Sucuri SiteCheck: Escanea tu sitio online buscando malware y vulnerabilidades conocidas.
• MalCare: Plugin que busca malware específico de WordPress incluyendo inyecciones SQL.
• Query Monitor: Plugin para desarrolladores que muestra cada query SQL ejecutada en tu sitio (útil para identificar queries anómalas).
• VirusTotal: Sube archivos PHP sospechosos para analizarlos contra múltiples motores de antivirus.

Errores que debes evitar durante la limpieza

En mi experiencia, hay patrones de error que veo repetidamente:

1. Borrar plugins sin verificar primero: Un plugin vulnerable puede tener usuarios que dependen de él. Busca alternativas antes de eliminarlo completamente.

2. No cambiar credenciales de hosting: Si el atacante entró por FTP, necesitas cambiar esas contraseñas también. Revisa los logs FTP para ver qué archivos fueron modificados.

3. No revisar temas child: Un atacante a menudo modifica archivos en el tema child (functions.php, header.php) porque se ejecutan automáticamente. Busca código extraño allí.

4. Asumir que una actualización soluciona todo: La actualización de un plugin cierra la vulnerabilidad, pero no limpia el malware ya instalado. Necesitas ambas cosas.

5. No verificar permisos de archivos: Después de limpiar, asegúrate de que carpetas como /wp-content/uploads/ tengan permisos 755 (no 777). Los permisos 777 permiten que cualquier proceso escriba archivos maliciosos.

Cuándo contactar a un profesional

No todos los casos de inyección SQL requieren ayuda profesional, pero deberías considerar contactar a un especialista si:

• No tienes acceso a logs del servidor o base de datos de forma segura
• El atacante inyectó múltiples usuarios o modificó decenas de posts
• Tu sitio depende de datos críticos (ecommerce, información sensible) que necesita validación forense
• Ya intentaste limpiar por cuenta propia pero el problema persiste
• Necesitas documentación legal de la limpieza (especialmente si estás bajo RGPD y hubo robo de datos)

Cuando trabajo en casos así, mi proceso incluye análisis forense completo, restauración desde backup limpio cuando es posible, y un plan de hardening personalizado según el tipo de ataque detectado.

Prevención futura: checklist de seguridad

Para evitar que esto vuelva a ocurrir, implementa este checklist:

• ☐ Actualizar WordPress, plugins y temas todas las semanas (al menos los parches de seguridad)
• ☐ Eliminar plugins y temas que no uses
• ☐ Usar solo plugins de desarrolladores reputados (verifica número de instalaciones, reviews, fecha última actualización)
• ☐ Implementar backups diarios con retención de 30 días mínimo
• ☐ Cambiar contraseña de admin a algo fuerte (mínimo 16 caracteres, mayúsculas, números, símbolos)
• ☐ Habilitar 2FA en cuenta de administrador
• ☐ Limitar intentos de login fallidos
• ☐ Cambiar prefijo de base de datos (de wp_ a algo aleatorio)
• ☐ Monitorear cambios de archivos con Wordfence
• ☐ Usar HTTPS con certificado SSL válido
• ☐ Implementar WAF (Web Application Firewall) — Cloudflare tiene plan gratuito excelente

Respuesta a ataques recurrentes

Si después de la limpieza detectas que el ataque vuelve a ocurrir (usuarios maliciosos reaparecen, código inyectado regresa), el problema no es la inyección SQL en sí, sino que el atacante mantiene acceso por otra vía. Podría ser:

• Una puerta trasera (backdoor) instalada en una carpeta oculta como /wp-content/.htaccess.php
• Un archivo webshell en /wp-content/uploads/
• Credenciales de base de datos comprometidas (el atacante sigue conectado)
• Acceso FTP o SSH mantenido activo

En estos casos, necesitas una limpieza más profunda: cambiar credenciales de hosting en todos los niveles, buscar archivos ocultos o extraños, y posiblemente migrar a un servidor nuevo si sospechas rootkit.

Si tu WordPress ha sido atacado por inyección SQL y quieres una limpieza profesional con garantía de eliminación completa, te recomiendo que contactes directamente con nosotros. En ManuelFolgar.com ofrecemos análisis forense detallado, limpieza completa de malware y un plan de hardening personalizado para tu sitio. Solicita una auditoría de seguridad sin compromiso — haremos una evaluación inicial para identificar exactamente qué pasó y cómo prevenirlo.