How can I figure out what caused the problem?

I passaggi forensi di base per questo tipo di violazione sono i seguenti:

1. Stabilire basetime - quando sono stati modificati i file cambiare?
2. Usa "trova" per cercare il webroot per i file che sono stati modificati in precedenza tempo di base, ma non più di (diciamo) 24 ore prima di tempo di base - utilizzare "touch" per creare file con le ore di inizio e di fine e utilizzare find con "-newer" e "! -newer" per cercare all'interno di quel periodo di tempo. Questo potrebbe identificare qualsiasi file che è stato caricato o modificato sul tuo server come parte dell'effrazione effettiva.
3. Ora correlare con i log di accesso Web per vedere cosa è successo in quel momento quelli di quei file cambiati. È molto probabile che l'aggressore ha abusato di Joomla o di un suo plug-in per eseguire il codice il tuo sistema, ad esempio alle 08:00 ingannano un plug-in caricando un file PHP sul tuo webroot, alle 08:05 e alle 08:10 accedono quel file PHP appena caricato tramite il server web e alle 08:15 di loro usalo per eseguire qualsiasi codice e modifica il tuo index.php.
4. Una volta individuata una voce del registro Web che identifica l'autore dell'attacco (ad esempio, accede a uno script che hai rilevato che è stato caricato dall'utente malintenzionato), puoi utilizzare Indirizzo IP dell'aggressore per cercare i log in modo più completo e vedi se riesci a capire cos'altro hanno fatto.
5. Se identificherai i file che l'utente malintenzionato ha caricato sul tuo sistema, tu potrebbe essere in grado di capire meglio cosa hanno fatto. Nell'ultimo tale il sistema che ho analizzato, tuttavia, il loro caricamento era semplicemente un file PHP che eval () il contenuto dei dati inviati ad esso - loro essenzialmente impostato in modo da poter inviare il codice al PHP interprete tramite POST a una pagina web. Questo metodo non ne lascia nessuno tracce del codice che hanno effettivamente eseguito.

Quando dico "questo tipo di violazione" mi riferisco ad un attacco da buca d'acqua, in cui qualcuno si rompe nel tuo server web e inietta il codice nei tuoi file web in modo che tu possa involontariamente servirli ai tuoi client web. Tali violazioni vengono comunemente eseguite attaccando l'applicazione web / CMS / plug-in e, mentre l'autore dell'attacco esegue il codice sul sistema, è meno probabile che utilizzino la violazione per costruirsi una backdoor completa o per provare a rimuovere le tracce dai registri: stai solo, modifica i tuoi file e sparisci.

È molto importante eseguire l'analisi sopra per identificare come sono stati in grado di eseguire codice sul sistema; se non lo fai, loro o qualcun altro lo faranno di nuovo. Anche se le probabilità che l'attaccante si tuffi nel tuo sistema (backdoor, log edit, rootkit) sono basse, dovresti strongmente prendere in considerazione la ricostruzione della scatola e il ripristino del contenuto web da un backup pulito.

Below script did the hack

No - questo è ciò che è rimasto indietro dopo l'attacco.

I removed the script and site happens to work fine.

Ma non hai risolto la vulnerabilità. L'attuale versione di Joomla è ragionevolmente sicura (le versioni precedenti non lo sono) ma ci sono un gran numero di estensioni scritte male là fuori. E forse l'aggressore non ha nemmeno accesso al sistema tramite Joomla.

Ho dato una rapida occhiata in giro, ma non sembrano esserci domande molto votate in merito alla procedura per gestire un sistema compromesso, ma leggi questo su serverfault.

when I have set the file permission to 644 and folder permission to 755

Prima o dopo? Di proprietà di chi?

How can I figure out what caused the problem?

Leggi i tuoi registri. Ma supponiamo che anche questi possano essere stati manomessi: cerca lacune e voci inaspettate. È ancora possibile che non trovi la risposta.

@Dasun

What steps should I take to prevent happening this in the future?

Primo: accetta il fatto che il tuo sito web non sarà mai "disabile".

Dopo aver ripulito il casino (di solito significa ricominciare da zero), aggiorna il tuo core Joomla e aggiorna tutti i tuoi componenti, estensioni eccetera. E tienilo aggiornato. Non dimenticare di ricontrollare le autorizzazioni dei file.

Uno spiacevole exploit di Joomla che si aggira per gli ultimi due (o così) mesi è uno per una vulnerabilità com_jce. Quindi controlla se stai usando quel componente. Google per ulteriori dettagli sulla vulnerabilità. Inoltre, non c'è molto altro da fare che rimanere aggiornati con le versioni del software.

PS: Ci sono molte informazioni disponibili su come configurare il tuo file .htaccess per bloccare (Riscrivere) gli exploit comuni. Ma devi monitorare attivamente gli exploit e le loro firme, che puoi incorporare nel tuo file .htaccess. Chiedi al tuo provider di hosting se offre protezione con un Web Application Firewall (WAF) come ModSecurity.

Mentre il comando eval() che mostri sembra relativamente benigno (anche se rende il tuo server scaricabile), la presenza di questo comando nel tuo file index.php indica che l'autore dell'attacco ha accesso in scrittura almeno alcuni file nel tuo sito. Potrebbe quindi averlo infastidito in vari modi, eventualmente intensificando il suo accesso a un accesso più completo al sistema. Il fatto che il sito "funzioni bene" non significa che il tuo server non sia stato invaso da backdoor e rootkit; significa solo che l'attaccante si è asciugato i piedi prima di entrare.

Questa è una situazione nuke from orbit , per quanto possa sembrare estremo. Non sarai mai più in grado di fidarti dell'integrità di questa macchina, a meno che non la pulisci con il fuoco, in modo crociato.

Dovresti comunque conservare una copia del tuo sito e del sistema operativo per l'analisi forense, al fine di sapere in che modo l'autore dell'attacco è entrato in primo luogo; vedi la risposta di @ gowenfar. Tuttavia, sappi che molti attaccanti hanno la tendenza a chiudere la porta dietro di loro: quando sfruttano un buco, installano una backdoor personalizzata, e quindi riparano il buco che ha permesso loro di entrare (in modo da mantenere esclusività: la maggior parte degli attaccanti sono animali altamente territoriali e si oppone attivamente ad altri aggressori che cercano di nutrirsi della stessa preda). Pertanto, suggerisco di fare un confronto sistematico, da file a file, tra lo stato attuale del tuo sito (la copia che utilizzerai prima di nuking la macchina) e l'ultimo backup pulito noto (hai backup, spero?). / p>     

La maggior parte delle risposte sopra sembrano mancare di un'informazione fondamentale, ovvero che Joomla 1.7 non è più supportato ed è aperto alle vulnerabilità.

Joomla 1.7 è stato rilasciato a breve termine ed è stato revocato alla fine del febbraio 2012. Il mio consiglio è di considerare l'aggiornamento il prima possibile. Per le note su come aggiornare a 2.5 stable link