¿Verificando que he eliminado completamente un hack de WordPress?

¿Has identificado el vector de explotación? Si no es así, puede que te estés dejando abierto a futuras vulnerabilidades.

Otras cosas a considerar:

1. Cambiar las contraseñas de usuario de administrador de WordPress - hecho
2. Cambiar la contraseña del usuario de la cuenta de alojamiento
3. Cambiar contraseñas de FTP
4. Cambiar la contraseña de usuario de MySQL db - hecho
5. Cambiar el prefijo de tabla db
6. Actualice su wp-config nonces / salt
7. Verifique sus permisos de directorio / archivo
8. Bloquee el acceso a la navegación de directorios, a través de .htaccess
9. Repase todo lo que se encuentra en Hardening WordPress Entrada del códice
10. Repase todo lo que se encuentra en Preguntas frecuentes Mi sitio fue hackeado entrada del Códice

Mirando el mensaje de "navegación segura" de Google Chrome, está recibiendo el ".cc iFrame hack" que parece estar rodeando MUCHO últimamente. Creo que 3.1.3 solucionará esto, pero revise su archivo index.php en la raíz si su sitio, allí es donde me golpeó hasta que actualizé TODO y cambié las contraseñas.

Hay algunas cosas MUY difíciles que la gente puede hacer con las inyecciones de comentarios y publicaciones. Puede ejecutar las siguientes consultas en su base de datos para ayudar a encontrar algunas de ellas. Blogué el resto de mi "seguimiento" aquí .

SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%display:%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?php%'

SELECT * FROM wp_comments WHERE comment_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%display:%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?php%'

Espero que esto ayude!

La base de datos también puede contener código malicioso: cuentas de usuario ocultas o valores que se imprimen sin escapar en algún lugar. Además, revise su directorio de carga para los archivos que no pertenecen allí.

Ah, y trata de entender cómo el atacante encontró su camino hacia tu sitio. En las cuentas compartidas suele ser todo el servidor. Consulte los otros sitios en el servidor para buscar blogs pirateados u otras páginas también. Lea su registro de FTP. Si no sabe cómo sucedió, no puede evitar el siguiente salto.

Lamento escuchar que te piratearon. ¡Aunque parece que has hecho un buen trabajo de recuperación!

Su sistema de archivos suena dorado, no diría que hay algo más que pueda hacer aquí.

Creo que Exploit Scanner emitiría una advertencia si encuentra algún script, iframes, PHP (aunque solo es peligroso si se evalúa) u otro código inusual en su base de datos.

No estoy seguro de que compruebe las tablas que no sean publicaciones & Puede que valga la pena echarle un vistazo a los comentarios, /wp-admin/options.php para una mirada rápida y ver si encuentras algo extraño.

También revisaría la tabla de usuarios en un cliente MySQL (los usuarios pueden estar en la base de datos pero no están visibles en el administrador).

Comprueba las herramientas de Google Webmaster para dos cosas:

• verifique que su sitio no haya sido marcado como comprometido, y solicite reconsideración si lo ha hecho
• revise su sitio como Googlebot y verifique que no se haya insertado ningún spam que solo sea visible para Googlebot; por ejemplo, el truco de WP Pharma

También, volvería a implementar el tema o lo verificaría con mucho cuidado. Unas pocas líneas de PHP pueden redefinir las funciones principales de PHP para que extraigan código malicioso de la base de datos, especialmente las tablas de almacén de valor / clave wp_options

Busque "iframe" en la base de datos a través de phpmyadmin o descargue la base de datos y busque el texto.

Y compruebe si hay usuarios invisibles en la tabla de usuarios; He visto usuarios en las tablas que no se mostraron en WP Admin > > Usuarios.

Opciones de limpieza «Complementos de WordPress mostrarán qué basura de complementos antiguos y posiblemente vulnerables queda en la base de datos .

A tu tema también le falta la etiqueta <head> , así que verifico que en caso de que hayas editado el tema para eliminar los enlaces defectuosos.

Y lo habitual: y Cómo encontrar una puerta trasera en un WordPress pirateado y Hardening WordPress «WordPress Codex

"¿hay algo más que deba revisar?" Debe examinar su proceso y descubrir cómo fue hackeado (casi con seguridad porque no realizó parches a tiempo, o correctamente) y corregirlo también, no solo los síntomas.

Eso me sucedió una vez, a través de una filtración en el elemento de media. Tuve que escribir un plugin para revisar la base de datos de enlaces inyectados. Puede grabarlo aquí como una gitubista .

Es bastante fácil de usar, tiene varios pasos que envían comentarios y vuelven a revisar su base de datos una vez que haya terminado.

¡Buena suerte!

Tuve un hack muy similar que tuve que corregir en uno de los sitios de mis clientes.

Hubo scripts maliciosos en el sistema de archivos (php base64_decode stuff). Sin embargo, la base de datos 'posts' & Las tablas de 'comentarios' se habían comprometido y el código iframe también se había dispersado a través de esos datos.

Por lo menos ejecuté algunas búsquedas en la base de datos, solo para estar seguro. :)

¡Revisa tus complementos! En lo que va del año, ha habido 60 lanzamientos de vulnerabilidades de los complementos .org, sospecho que el número real es mucho mayor ya que nadie lo hace a tiempo completo.

Listaste que solo tienes un complemento, bueno, tenía un agujero de seguridad (no estoy seguro de cuánto tiempo estuvo fuera y puede que no sea el vector).

  

wp-recaptcha-plugin
  El exploit fue lanzado: 2011-03-18
  Explotación de la versión: 2.9.8

El autor declaró que volvió a escribir con la versión 3.0, pero no se menciona el parche de seguridad.

enlace

Registro de cambios: enlace

Utilizo un servidor en la nube y tengo números aleatorios aleatorios de ssh, sin ftp en absoluto. Las contraseñas son extremadamente difíciles de hackear. Todo acceso root es completamente denegado. Estoy de acuerdo en que WordPress no va a ser tu culpable. Otra cosa que debe verificar es si las sesiones ftp no se cierran, el virus en su computadora personal (recuerde que puede cargar un archivo en su sitio y quien cargue ese archivo puede obtener el mismo virus), tampoco guarde sus contraseñas en sitios públicos o privados. los sitios siempre los colocan en un papel, nunca en un documento de Word o en una libreta.

Por último, pregúntale a tu anfitrión si recientemente tuvo una falla, ya que deberían tener una configuración de firewall

Comprueba la fecha de tus archivos. Ningún archivo debe tener un cambio de datos más reciente que su última edición / instalación.

Pero también esto puede ser fingido. La única forma de estar seguro sería comparar (por ejemplo, hash compare) todos los archivos con los archivos de instalación originales.