¿Verificando que he eliminado por completo un truco de WordPress?

105

Mi blog de WordPress por diversión en http://fakeplasticrock.com (ejecutando WordPress 3.1.1) fue pirateado: mostraba un <iframe>en cada página así:

<iframe src="http://evilsite.com/go/1"></iframe>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

Hice lo siguiente

Actualizado a 3.1.3 a través del sistema de actualización de WordPress incorporado
Instalé el Exploit Scanner (muchas advertencias críticas en archivos inusuales) y AntiVirus (esto mostró todo verde y limpio, así que lo desinstalé y lo eliminé después de ejecutarlo)
Se cambió la contraseña de MySQL.
Cambió todas las contraseñas de usuario de WordPress.
Conectado a través de FTP y descargado todo el sistema de archivos (no es grande, este es un host compartido de Linux solo para WordPress)
Diffed el sistema de archivos en contra de una postal oficial de WordPress 3.1.3 y eliminado o sobrescrito nada que no coincidía.

Estoy bastante seguro de que

todos los archivos en el disco son archivos oficiales de WordPress 3.1.3
no hay archivos "adicionales" en el disco que no sean el mío /theme, el complemento Exploit Scanner (que acabo de descargar), la /uploadscarpeta y un puñado de otros archivos esperados. Mi otro complemento, wp-recaptcha, coincide con la versión oficial descargada actual.
También revisé el .htaccessarchivo y no hay nada mal allí

comparación de archivos de WordPress 3.1.3 en Beyond Compare

No toqué la base de datos , pero me cuesta pensar cómo algo en la base de datos podría ser malicioso sin un código PHP especial para que funcione.

Mi blog de WordPress parece estar bien y sin pirateo ahora (creo), pero ¿hay algo más que deba verificar?

security hacked

— Jeff Atwood
fuente

1

Debes mantener el blog actualizado. :)

— fuxia

80

¿Has identificado el vector de explotación? De lo contrario, es posible que te dejes abierto a futuras hazañas.

Otras cosas a considerar:

Cambiar las contraseñas de usuario administrador de WordPress - hecho
Cambiar la contraseña de usuario de la cuenta de hosting
Cambiar contraseñas FTP
Cambiar la contraseña de usuario de MySQL db - hecho
Cambiar el prefijo de la tabla db
Actualice su wp-config nonces / salt
Verifique los permisos de su directorio / archivo
Bloquee el acceso a la exploración de directorios a través de .htaccess
Revisa todo en la entrada Endurecer WordPress Codex
Ir a través de todo en el FAQ Mi sitio fue hackeado entrada del Codex

— Chip Bennett
fuente

1

lo siento, no mencioné nada, por supuesto cambié las contraseñas de WordPress ¡Publicación actualizada y marcada en la lista aquí! No puedo pensar de ninguna manera en que podrían tener mi contraseña de alojamiento, o la contraseña de FTP, simplemente ingresando a WordPress; esa información no está en ninguna parte del sistema de archivos o la base de datos.

— Jeff Atwood

99

Tienes el probable vector de explotación al revés; no es probable que WordPress -> cuenta de hosting , sino más bien la cuenta de hosting (a través del servidor o FTP) -> WordPress .

— Chip Bennett

2

@Jeff algunos exploits a nivel de servidor sobre los que no tienes control (aparte de encontrar un mejor host). Pero el hecho de que no haya utilizado las credenciales de host / FTP no significa que alguien no las haya robado , al obtener acceso a su cuenta de hosting.

— Chip Bennett

77

Hay un exploit muy común que circula cuando el malware infecta su estación de trabajo (o la estación de trabajo de un contratista), excava sus contraseñas guardadas en su programa FTP (o habilitado para FTP) favorito y las envía al atacante, quien luego compromete su sitio y lo usa para difundir el mismo malware a otros webmasters. Esa es una forma común en la que su contraseña FTP es robada. Lo que es particularmente insidioso es que se propaga a través de sitios normales como el tuyo, no a los de mala muerte donde es probable que tengas cuidado.

— tylerl

3

Para su información, si tiene acceso a la línea de comando, WP-CLI tiene un comando de verificación de sumas de verificación que verificará cada archivo contra wordpress.org

— William Turrell

26

Al mirar el mensaje de "navegación segura" de Google Chrome, está obteniendo el "hack de .cc iFrame" que parece estar dando vueltas MUCHO últimamente. Creo que 3.1.3 solucionará esto, pero verifique su archivo index.php en la raíz de su sitio, ahí es donde me siguió golpeando hasta que TODO estaba actualizado y las contraseñas cambiaron.

Hay algunas cosas MUY complicadas que la gente puede hacer con inyecciones de comentarios y publicaciones. Puede ejecutar las siguientes consultas en su base de datos para ayudar a encontrar algunas de ellas. Blogueé 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!

— Dillie-O
fuente

44

Añadiría SELECT * FROM wp_* WHERE comment_content LIKE '%<?%'y SELECT * FROM wp_* WHERE comment_content LIKE '%<?php%'solo para estar seguro ...

— SeanJA

44

Oh, una nota final. Supongo que tiene herramientas para webmasters de Google vinculadas a este dominio. Una vez que haya limpiado todo, puede enviar una solicitud desde su cuenta de herramientas para webmasters para que Google vuelva a explorar el sitio y elimine el mensaje de advertencia. Procesan las solicitudes de las herramientas para webmasters normalmente en un día. De lo contrario, estarás en la "lista traviesa" por unos buenos 90 días.

— Dillie-O

Encontré muchos resultados, pero se debe a los iframes incrustados para Vimeo.

— tooshel

20

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

Ah, e intente comprender cómo el atacante encontró su camino en su sitio. En cuentas compartidas, a menudo es todo el servidor. Revise 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 próximo descanso.

— fuxia
fuente

¿El Exploit Scanner no encontraría cuentas de usuario ocultas?

— Jeff Atwood

@ Jeff Atwood No confiaría en eso. Su tabla de usuario no es tan grande. Puede leerlo fácilmente sin ningún complemento.

— fuxia

Revisé la wp_userstabla y solo 2 filas, ambas esperadas ... nada en la /uploadcarpeta inusual (solo gifs y pngs y jpegs)

— Jeff Atwood

@Jeff Atwood ¿Buscó en los archivos o solo en las extensiones? ¿Están todos esos archivos listados en la biblioteca de medios?

— fuxia

44

Los archivos de imagen son un método de entrega de carga útil bastante común. Vea aquí , y el Equipo de Revisión de Temas también se ha topado con Temas usando un exploit TIFF similar.) Entonces, sí: comprobaría cada uno, para asegurarme de que sea parte de la Biblioteca de Medios. (Escaneo fácil de alto nivel: busque imágenes que no tengan tamaños de miniatura definidos).

— Chip Bennett

13

Lamento escuchar que fuiste hackeado, ¡parece que has hecho un buen trabajo de recuperación!

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

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

No estoy seguro de si revisa tablas que no sean publicaciones y comentarios, puede valer la pena echarle /wp-admin/options.phpun vistazo para ver si ves algo extraño.

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

— TheDeadMedic
fuente

Definitivamente es una buena idea ejecutar una consulta MySQL en la tabla de usuarios para asegurar que no haya nada inesperado, y lo hice. ¡Buen consejo!

— Jeff Atwood

8

Verifique las herramientas de Google Webmaster para dos cosas:

verifique que su sitio no haya sido marcado como comprometido y solicite una reconsideración si lo ha hecho
verifique su sitio como Googlebot y verifique que no se esté insertando correo no deseado que solo es visible para Googlebot; un ejemplo de esto es el pirateo de WP Pharma

Además, volvería a implementar el tema o lo comprobaría con mucho cuidado. Algunas líneas de PHP pueden redefinir las funciones centrales de PHP para extraer código malicioso de la base de datos, especialmente las tablas de almacenamiento de valores / claves wp_options

— Jon Galloway
fuente

Sí, definitivamente volví a enviar el sitio a través de las Herramientas para webmasters de Google, y ahora parece "borrado".

— Jeff Atwood

6

Buscar en la base de datos a través de phpmyadmin para "iframe" o volcar la base de datos y buscar el texto.

Y busque usuarios invisibles en la tabla de usuarios; He visto usuarios en las tablas que no aparecían en WP Admin >> Usuarios.

Opciones limpias «Los complementos de WordPress mostrarán qué basura de los complementos antiguos y posiblemente vulnerables quedan en la base de datos.

A su tema también le falta la <head>etiqueta, así que lo comprobaré en caso de que haya editado el tema para eliminar los enlaces incorrectos.

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

— markratledge
fuente

5

"¿Hay algo más que deba verificar?" Debe examinar su proceso y descubrir cómo fue pirateado (casi seguramente porque no parchó a tiempo o correctamente) y corregirlo también, no solo los síntomas.

— Tom Chiverton
fuente

55

Dudo que tenga que ver con no actualizar WordPress (aunque es posible , simplemente no es probable ). WordPress en sí mismo casi nunca es el vector de explotación. Los vectores habituales son configuración de host insegura y credenciales FTP robadas.

— Chip Bennett

4

Eso me sucedió una vez, a través de una fuga en el mediotemplo. Tuve que escribir un complemento para verificar los enlaces inyectados en la base de datos. Puedes agarrarlo aquí como una esencia de Github .

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

¡Buena suerte!

— emperador
fuente

4

Tuve un truco muy similar que tuve que arreglar en uno de mis sitios de clientes.

Había scripts maliciosos en el sistema de archivos (cosas de php base64_decode). Sin embargo, las tablas de 'publicaciones' y 'comentarios' de la base de datos se vieron comprometidas y el código del iframe también se dispersó a través de esos datos.

Al menos haría algunas búsquedas en el DB, solo para estar seguro. :)

— Eric Allison
fuente

3

¡Comprueba tus complementos!, En lo que va del año ha habido 60 lanzamientos de exploits de complementos .org, sospecho que el número real es mucho mayor ya que nadie realmente está haciendo esto a tiempo completo.

Usted mencionó que solo tiene un complemento, bueno, tenía un agujero de seguridad (no estoy seguro de cuánto tiempo estuvo fuera, y podría no ser el vector).

wp-recaptcha-plugin
El exploit se lanzó: 2011-03-18
Versión del exploit: 2.9.8

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

http://www.wpsecure.net/2011/03/wp-recaptcha-plugin/

Registro de cambios: http://wordpress.org/extend/plugins/wp-recaptcha/changelog/

— Wyck
fuente

2

Uso un servidor en la nube y tengo números de puerto ssh al azar sin ftp. Las contraseñas son extremadamente difíciles de hackear. Se niega completamente el acceso a la raíz. Estoy de acuerdo en que WordPress no va a ser tu culpable. Otra cosa para verificar es que las sesiones de ftp no se cierren, 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 papel, nunca en un documento de Word o un bloc de notas.

Por último, pregunte a su host si recientemente tuvo una infracción, ya que debería tener una configuración de firewall

— xLRDxREVENGEx
fuente

2

Verifique la fecha de sus 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 falso. La forma más segura de estar seguro sería comparar (por ejemplo, comparar con hash) todos los archivos con los archivos de instalación originales.

— Powtac
fuente