Sitio web infectado con "redirecciones" no deseadas, aparentemente a través de un código javascript

3

Estoy trabajando en el sitio web de un cliente, y me doy cuenta de que han sido comprometidos. A primera hora de hoy hubo un problema importante con un problema de php eval(base64_decode . Se limpió a través de Andy Stratton reparación de clean.php (que busca los archivos infectados y luego los elimina). El sitio web se reconstruyó con un código de Wordpress virgen tema de confianza 12 horas más tarde estoy viendo un montón de redirecciones no deseadas. Las redirecciones van a un sitio extraño en algún lugar del extranjero. De hecho, las redirecciones pueden no ser el término correcto. Puedo ver todo el contenido original de los sitios cargando en las herramientas del desarrollador, y al final de la carga toma una imagen y un reproductor de música y pega una página html simple. La imagen es http://i.hizliresim.com/g4rXl2.png La url mostrada fue el original seleccionado en el sitio.

Como solo hago algunas pruebas, encuentro que el problema parece estar relacionado con JavaScript. Si apago el JS, no hay redirecciones. Aquí están mis preguntas: ¿Puedo usar las herramientas JS en Chrome para identificar qué archivo es el más sospechoso? (pausa en excepciones, etc.) ¿Hay alguna forma de escanear todos los archivos para buscar el código JS malvado? He probado las herramientas comunes y amp; Ubicaciones para revisar, sin ningún resultado. Definitivamente no es un problema .htaccess.

Tengo mucha curiosidad por poder pasar por el código JavaScript en Chrome y ver dónde se desvían las cosas. Sospecho que la solución para esto es borrar el VPS y reinstalarlo, pero mientras tanto, tengo curiosidad. ¿Puedo detectar dónde se encuentra el código del mal?

Y nota, no tengo acceso completo al servidor. Solo tengo cPanel & Acceso FTP. Además, el sitio está siendo servido a través de CloudFlare. Muchas gracias por tu ayuda.

Actualización: hemos descubierto dónde estaba ubicado el código errante ... Estaba en la base de datos mySQL en una celda normalmente reservada para el contenido del widget. El código era bastante grande, 1530 líneas de gook engullido. Algunas palabras en claro, otras en código críptico. Está fuertemente ofuscado con el código con: y; elementos. Al parecer, este cliente ha sido golpeado antes, su tipo de web actual quiere lanzar bandaids en el sitio. Creo que he convencido al dueño del negocio para que ponga su negocio en otro lugar y asegure todo.

Una pregunta. Debido a que la base de datos está en peligro, ¿existe una forma segura de clonar el sitio en un nuevo servidor? Supongo que puedo buscar patrones familiares basados en este bloque de código, pero eso realmente no es sólido. Sé que puedo crear una copia de seguridad de contenido XML desde el panel de control de administración - > Exportar. El formato en realidad se llama WordPress eXtended RSS o WXR, y contendrá publicaciones, páginas, comentarios, campos personalizados, categorías y etiquetas. Puedo revisar esas entradas visualmente, para ver si las cosas tienen sentido.

¿Alguna otra idea sobre la clonación de un sitio con al menos un virus en la base de datos?

Además, ¿hay un repositorio para personas legítimas que buscan virus para enviar este ejemplo de actividad reciente de JavaScript? Obviamente no lo voy a publicar aquí, para evitar darle a otros la oportunidad de crear más. p.ej. ¿Presento el código a personas como sucuri.net o en algún otro lugar?

    
pregunta zipzit 30.01.2015 - 13:29
fuente

2 respuestas

5

Parece que estás preguntando:

¿Es posible aplicar ingeniería inversa al malware de JavaScript

Sí. Y no necesitas acceso al servidor para hacer eso. Sin embargo, es posible que el autor del malware haga que sea más difícil hacerlo. No voy a enumerar los métodos potenciales aquí; están (en su mayoría) bien descritos en otra parte. La mayoría de los atacantes no se molestan con tanta sofisticación, especialmente cuando no es un ataque dirigido con un valor financiero significativo.

¿Es posible identificar dónde se está inyectando el código en el servidor? Sí, pero necesita un conocimiento práctico del CMS, competencia en la programación y acceso al servidor (o una imagen del mismo).

La pregunta que debe hacerse es cuál es la vulnerabilidad en el servicio . Solo ha tratado los síntomas de este problema, no la causa.

    
respondido por el symcbean 30.01.2015 - 13:50
fuente
1

Un vector común para este tipo de ataque es modificar el archivo .htaccess para incluir una declaración de adición automática para PHP. De lo contrario, sospecho que se encuentra en su base de datos, ya que parece activarse después de que se cargue su contenido.     

respondido por el wireghoul 30.01.2015 - 13:33
fuente

Lea otras preguntas en las etiquetas