¿Cómo puedo averiguar qué causó el problema?

Los pasos forenses básicos para este tipo de incumplimiento son los siguientes:

1. Establecer tiempo base: cuándo se modificaron los archivos cambiar?
2. Use 'buscar' para buscar en su webroot los archivos que se cambiaron antes basetime pero no más de (digamos) 24 horas antes de basetime - use "toque" para crear archivos con los tiempos de inicio y finalización y use buscar con "-newer" y "! -newer" para buscar dentro de ese período de tiempo. Esta puede identificar cualquier archivo que haya sido cargado o cambiado en su servidor como parte de la interrupción real.
3. Ahora correlacione con los registros de acceso web para ver qué sucedió en ese momento Esos de esos archivos cambiaron. Es muy probable que el atacante abusó de Joomla o de un complemento del mismo para ejecutar código en su sistema, por ejemplo, a las 08:00 engañan a un complemento subiendo un archivo PHP a su webroot, a las 08:05 y 08:10 acceden ese archivo PHP recién cargado a través del servidor web, y a las 08:15 úselo para ejecutar cualquier código que haya pasado y modificado su index.php.
4. Una vez que encuentre cualquier entrada del registro web que identifique al atacante (es decir, acceda a un script que encontró que fue subido por el atacante), puede usar la Dirección IP del atacante para buscar los registros de manera más completa y ver si puedes averiguar qué más hicieron.
5. Si identifica algún archivo que el atacante subió a su sistema, puede ser capaz de entender mejor lo que hicieron. En el ultimo tal El sistema que analicé, sin embargo, su carga era simplemente un archivo PHP que evaluaría () el contenido de los datos publicados en él; Básicamente configurarlo para que puedan enviar código a PHP intérprete mediante POSTing a una página web. Este método no deja ningún rastros del código que realmente corrieron.

Cuando digo "este tipo de violación" me refiero a un ataque de un pozo de agua, donde alguien ingresa a su servidor web e inyecta código en sus archivos web para que sin saberlo los sirva a sus clientes web. Estas infracciones se realizan comúnmente atacando la aplicación web / CMS / plugins, y aunque el atacante ejecuta código en su sistema, es menos probable que utilicen la brecha para construir una puerta trasera completa o para intentar eliminar los rastros de los registros. Sólo estás dentro, modifica tus archivos y desaparece.

Es muy importante que realice el análisis anterior para identificar cómo pudieron ejecutar el código en su sistema; Si no lo haces, ellos o alguien más lo volverán a hacer. A pesar de que las posibilidades de que el atacante se hunda en su sistema es menor (puertas traseras, registros de edición, rootkits), debería fuertemente considerar reconstruir la caja y restaurar su contenido web desde una copia de seguridad limpia.

  

Debajo de la secuencia de comandos hizo el truco

No, eso es lo que quedó atrás después de el ataque.

  

Eliminé el script y el sitio funciona bien.

Pero no has arreglado la vulnerabilidad. La versión actual de Joomla es razonablemente segura (las versiones anteriores no lo son) pero hay una gran cantidad de extensiones mal escritas por ahí. Y tal vez el atacante ni siquiera accedió al sistema a través de Joomla.

Eché un vistazo rápido a mi alrededor, pero no parece haber ninguna pregunta muy votada aquí con respecto al proceso para tratar con un sistema pirateado, pero lea esto en la falla del servidor.

  

cuando haya establecido el permiso de archivo en 644 y el permiso de carpeta en 755

¿Antes o después? Propiedad de quien?

  

¿Cómo puedo averiguar qué causó el problema?

Lee tus registros. Pero suponga que estos también pueden haber sido manipulados, busque espacios y entradas inesperadas. Es posible que todavía no encuentres la respuesta.

@Dasun

  

¿Qué pasos debo tomar para evitar que esto suceda en el futuro?

Primero: Acepte el hecho de que su sitio web nunca será "descifrable".

Después de limpiar el desorden (generalmente significa volver a empezar desde cero), actualice su núcleo de Joomla y actualice todos sus componentes, extensiones, etc. Y manténgalo actualizado. No olvides revisar los permisos de tus archivos.

Un ataque desagradable de Joomla durante los últimos dos (más o menos) meses es uno para una vulnerabilidad de com_jce. Así que compruebe si está utilizando ese componente. Google para más detalles sobre la vulnerabilidad. Además, no hay mucho más que hacer, que estar al día con las versiones de software.

PS: hay mucha información disponible sobre cómo configurar tu archivo .htaccess para bloquear (Reescribir) las vulnerabilidades comunes. Pero tiene que monitorear activamente las vulnerabilidades y sus firmas, que puede incorporar en su archivo .htaccess. Pregunte a su proveedor de alojamiento si ofrecen protección con un servidor de seguridad de aplicaciones web (WAF) como ModSecurity.

Si bien el comando eval() que muestra parece relativamente benigno (aunque hace que el servidor descargue cosas), la presencia de este comando en su archivo index.php indica que el atacante obtuvo un acceso de escritura al menos a algunos archivos en su sitio. Puede que luego lo haya molestado de varias maneras, posiblemente escalando su acceso a un acceso más completo del sistema. Que el sitio "funcione bien" no significa que su servidor no haya estado plagado de puertas traseras y rootkits; solo significa que el atacante se limpió los pies antes de entrar.

Esa es una situación Nuke from orbit , por muy extrema que parezca. Nunca podrás volver a confiar en la integridad de esta máquina, a menos que la limpies con fuego de forma cruzada.

Debes mantener una copia de tu sitio y sistema operativo para el análisis forense, para saber cómo ingresó el atacante en primer lugar; Ver la respuesta de @Gowenfar. Sin embargo, tenga en cuenta que muchos atacantes tienden a cerrar la puerta detrás de ellos: cuando explotan un agujero, instalan una puerta trasera personalizada, y luego arreglan el agujero que les permitió entrar (para mantenerlos). Exclusividad: la mayoría de los atacantes son animales altamente territoriales y se oponen activamente a otros atacantes que intentan alimentarse de la misma presa. Por lo tanto, sugiero realizar una comparación sistemática de un archivo a otro entre el estado actual de su sitio (la copia que tomará antes de dañar la máquina) y su última copia de seguridad limpia conocida (¿tiene copias de seguridad, espero?).

La mayoría de las respuestas anteriores parecen faltar un elemento vital de información, que es que Joomla 1.7 ya no es compatible y está abierto a vulnerabilidades.

Joomla 1.7 fue un lanzamiento a corto plazo y finalizó en febrero de 2012. Mi consejo sería considerar la actualización lo antes posible. Para notas sobre cómo actualizar a 2.5 estable enlace