Cómo verificar que he eliminado completamente un hack en WordPress

Question

Cómo verificar que he eliminado completamente un hack en WordPress

10 jun 2011, 15:31:42

Vistas: 17.9K

Votos: 110

Mi blog personal de WordPress en http://fakeplasticrock.com (ejecutando WordPress 3.1.1) fue hackeado -- mostraba un <iframe> en cada página como este:

<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:

Actualicé a la versión 3.1.3 mediante el sistema de actualización integrado de WordPress
Instalé el Exploit Scanner (muchas advertencias críticas sobre archivos inusuales) y AntiVirus (mostró todo verde y limpio, así que lo desinstalé y eliminé después de ejecutarlo)
Cambié la contraseña de MySQL
Cambié todas las contraseñas de usuarios de WordPress
Me conecté via FTP y descargué todo el sistema de archivos (no es grande, es un hosting compartido Linux solo para WordPress)
Comparé el sistema de archivos con un ZIP oficial de WordPress 3.1.3 y eliminé o sobrescribí cualquier cosa que no coincidiera

Estoy bastante seguro de que:

Todos los archivos en disco son archivos oficiales de WordPress 3.1.3
No hay archivos "extra" en disco aparte de mi único /theme, el plugin Exploit Scanner (que acabo de descargar), la carpeta /uploads y un pequeño puñado de otros archivos esperados. Mi otro plugin, wp-recaptcha, coincide con la versión oficial actual descargada
También revisé el archivo .htaccess y no parece haber nada malo 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 código PHP especial para hacerlo funcionar.

Mi blog de WordPress parece estar bien y libre de hacks ahora (creo), ¿hay algo más que debería verificar?

Jeff Atwood

2.1K

seguridad hackeado

Comentarios

Deberías mantener el blog actualizado. :)

fuxia

20 jul 2014 19:49:51

Todas las respuestas a la pregunta

Comentarios

Lo siento, olvidé mencionar: cambié las contraseñas de WordPress, por supuesto. Actualicé la publicación y marqué la lista aquí. No se me ocurre ninguna forma en que podrían tener mi contraseña de hosting, o la contraseña de FTP, solo por entrar en WordPress; esa información no está en ningún lugar del sistema de archivos o la base de datos.

Jeff Atwood

10 jun 2011 16:18:09

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

Chip Bennett

10 jun 2011 16:20:28

Añadiría "cambiar el nombre de usuario del administrador". ¡Lo cual debería ser obligatorio!

Bainternet

10 jun 2011 16:26:00

@chip ¿cómo es eso? Las contraseñas de hosting y FTP literalmente no las he usado en 12 meses (obviamente las usé hoy), y son ultra-aleatorias como las asignó el host.

Jeff Atwood

10 jun 2011 16:31:13

¿El hecho de que sea un hosting compartido (potencialmente) no te expone a problemas?

Travis Northcutt

10 jun 2011 16:33:56

Mostrar los 4 comentarios restantes

Al ver el mensaje de "navegación segura" de Google Chrome, estás experimentando el "hack de iFrame .cc" que parece estar circulando MUCHO últimamente. Creo que la versión 3.1.3 lo solucionará, pero revisa tu archivo index.php en la raíz de tu sitio, ya que es donde me seguía afectando hasta que actualicé TODO y cambié las contraseñas.

Hay cosas MUY astutas que la gente puede hacer con inyecciones en publicaciones y comentarios. Puedes ejecutar las siguientes consultas en tu 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

1.56K

10 jun 2011 16:00:39

Comentarios

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

SeanJA

10 jun 2011 16:04:40

Oh, una nota final. Asumo que tienes Google Webmaster Tools vinculado a este dominio. Una vez que hayas limpiado todo, puedes enviar una solicitud desde tu cuenta de Webmaster Tools para que Google vuelva a escanear el sitio y elimine el mensaje de advertencia. Normalmente procesan las solicitudes de Webmaster Tools en un día. De lo contrario, estarás en la "lista negra" por unos buenos 90 días.

Dillie-O

10 jun 2011 16:06:09

Encontré un montón de resultados pero es por los iframes incrustados de Vimeo.

tooshel

10 jun 2011 16:19:22

La base de datos también puede contener código malicioso: cuentas de usuario ocultas o valores que se imprimen sin escapado en algún lugar. Además, revisa tu directorio de subidas en busca de archivos que no deberían estar allí.

Ah, e intenta entender cómo el atacante encontró la manera de entrar en tu sitio. En cuentas compartidas, a menudo es todo el servidor. Verifica los otros sitios en el servidor en busca de blogs hackeados u otras páginas también. Lee tu registro FTP. Si no sabes cómo sucedió, no podrás prevenir el próximo ataque.

fuxia

107K

10 jun 2011 15:47:11

Comentarios

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

Jeff Atwood

10 jun 2011 15:52:34

@Jeff Atwood No confiaría en eso. Tu tabla de usuarios no es tan grande. Puedes leerla fácilmente sin ningún plugin.

fuxia

10 jun 2011 15:55:31

Revisé la tabla wp_users y solo hay 2 filas, ambas esperadas... nada inusual en la carpeta /upload (solo gifs, pngs y jpegs)

Jeff Atwood

10 jun 2011 16:00:12

@Jeff Atwood ¿Revisaste los archivos o solo las extensiones? ¿Todos esos archivos están listados en la biblioteca de medios?

fuxia

10 jun 2011 16:02:17

Los archivos de imagen son un método bastante común para entregar carga útil. Mira aquí, y el Equipo de Revisión de Temas también se ha encontrado con Temas que usan una explotación similar de TIFF.) Así que, sí: revisaría cada uno, para asegurarme de que es parte de la Biblioteca de Medios. (Escaneo sencillo de alto nivel: busca imágenes que no tengan tamaños de miniatura definidos.)

Chip Bennett

10 jun 2011 16:16:41

Mostrar los 1 comentarios restantes

Lamento escuchar que fuiste hackeado - ¡aunque parece que hiciste un buen trabajo de recuperación!

Tu sistema de archivos suena impecable, no creo que haya nada más que puedas hacer ahí.

Pensé que Exploit Scanner mostraría una advertencia si encontrara scripts, iframes, código PHP (aunque solo es peligroso si se usa eval) u otro código inusual en tu base de datos.

No estoy seguro si revisa tablas además de entradas y comentarios, podría valer la pena echar un vistazo a /wp-admin/options.php para ver si notas algo extraño.

También revisaría tu tabla de usuarios en un cliente MySQL (puede haber usuarios en la base de datos que no sean visibles en el panel de administración).

TheDeadMedic

36.6K

10 jun 2011 15:49:16

Comentarios

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

Jeff Atwood

6 jul 2011 07:10:03

Revisa las herramientas para webmasters de Google para dos cosas:

verifica que tu sitio no haya sido marcado como comprometido, y solicita reconsideración si es así
revisa tu sitio como Googlebot y verifica que no haya spam insertado que solo sea visible para Googlebot - un ejemplo de esto es el hack WP Pharma

Además, volvería a implementar el tema, o lo revisaría con extremo cuidado. Unas pocas líneas de PHP pueden redefinir funciones principales de PHP para que extraigan código malicioso de la base de datos, especialmente en las tablas de almacenamiento clave/valor wp_options

Jon Galloway

203

10 jun 2011 16:10:41

Comentarios

sí, definitivamente volví a enviar el sitio a través de Google Webmaster Tools, y ahora parece estar "limpio".

Jeff Atwood

11 jun 2011 00:38:30

Busca en la base de datos a través de phpmyadmin por "iframe" o vuelca la base de datos y busca el texto.

Y verifica si hay usuarios invisibles en la tabla de usuarios; he visto usuarios en las tablas que no aparecían en WP Admin>>Usuarios.

Clean Options « WordPress Plugins mostrará qué basura de plugins antiguos y posiblemente vulnerables queda en la base de datos.

A tu tema también le falta la etiqueta <head>, así que lo revisaría por si has editado el tema para eliminar enlaces maliciosos.

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

markratledge

8.74K

10 jun 2011 15:58:58

"¿hay algo más que deba revisar?" Necesitas examinar tu proceso y descubrir cómo fuiste hackeado (casi con certeza porque no parcheaste a tiempo o correctamente) y solucionar eso también, no solo los síntomas.

Tom Chiverton

51

10 jun 2011 16:00:32

Comentarios

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 la configuración insegura del host y las credenciales FTP robadas.

Chip Bennett

10 jun 2011 16:03:42

Eso me pasó una vez, a través de una fuga en mediatemple. Tuve que escribir un plugin para revisar la base de datos en busca de enlaces inyectados. Puedes descargarlo aquí como un gist de github.

Es bastante fácil de usar, tiene varios pasos que proporcionan retroalimentación y vuelve a revisar tu base de datos después de que hayas terminado.

¡Buena suerte!

kaiser

50.8K

10 jun 2011 16:01:11

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

Había scripts maliciosos en el sistema de archivos (cosas con base64_decode en php). Sin embargo, las tablas 'posts' y 'comments' de la base de datos también habían sido comprometidas y el código de iframe estaba disperso en esos datos.

Al menos recomendaría ejecutar algunas búsquedas en la base de datos, solo para estar seguro. :)

Eric Allison

41

10 jun 2011 16:11:06

¡Revisa tus plugins! Hasta ahora este año ha habido 60 exploits publicados de plugins de .org, sospecho que el número real es mucho mayor ya que nadie se dedica a esto a tiempo completo.

Mencionaste que solo tienes un plugin, pues tenía una vulnerabilidad de seguridad (no estoy seguro de cuánto tiempo estuvo expuesta y puede que no sea el vector).

wp-recaptcha-plugin
El exploit fue publicado: 2011-03-18
Versión vulnerable: 2.9.8

El autor declaró que lo reescribió con la versión 3.0, pero no hay mención del parche de seguridad.

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

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

Wyck

18K

11 jun 2011 04:43:24

Utilizo un servidor en la nube y tengo números de puerto SSH aleatorios y nada de FTP. Las contraseñas son extremadamente difíciles de hackear. Todo acceso root está completamente denegado. Estoy de acuerdo en que WordPress no va a ser el culpable. Otra cosa que debes verificar son las sesiones FTP que no se cierran, virus en tu computadora personal (recuerda que puedes subir un archivo a tu sitio y quien lo descargue puede contraer el mismo virus), además no guardes tus contraseñas en sitios públicos o privados, siempre escríbelas en papel, nunca en un documento de Word o en el bloc de notas.

Por último, pregunta a tu proveedor de hosting si recientemente han tenido una brecha de seguridad, ya que deberían tener configurado un firewall.

xLRDxREVENGEx

1.2K

11 jun 2011 05:50:21

Verifica la fecha de tus archivos. ¡Ningún archivo debería tener una fecha de modificación más reciente que tu última edición/instalación!

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

powtac

123

11 jun 2011 12:49:56

Chip Bennett 55.1K · Accepted Answer · 2011-06-10T15:58:31Z

¿Has identificado el vector de explotación? Si no, podrías estar dejándote vulnerable a futuros exploits.

Otras cosas a considerar:

Cambiar las contraseñas de los usuarios administradores de WordPress - hecho
Cambiar la contraseña de la cuenta de hosting
Cambiar las contraseñas de FTP
Cambiar la contraseña del usuario de la base de datos MySQL - hecho
Cambiar el prefijo de las tablas de la base de datos
Actualizar tus nonces/salts en wp-config
Verificar los permisos de directorios/archivos
Bloquear el acceso de navegación de directorios, mediante .htaccess
Revisar todo en la entrada del Codex Reforzando WordPress
Revisar todo en la entrada del Codex FAQ Mi Sitio Fue Hackeado

Chip Bennett

55.1K

10 jun 2011 15:58:31