Ho bisogno di aiuto per tracciare una vulnerabilità sul mio server. Per la seconda volta, il mio server è stato compromesso con i file che sono stati sostituiti con download di virus.
Secondo le date del filesystem, in un periodo di 45 minuti 4 file exe sul mio server sono stati sostituiti con versioni rinominate dello stesso virus.
Il mio server web esegue Ubuntu 10.4.3 LTS con la versione del kernel 2.6.32-31-generica, mantenuta completamente aggiornata e aggiornata.
L'unico modo per accedere alla shell è tramite SSH e una chiave privata protetta da password che ho con me su una penna USB. L'accesso SSH della password è disabilitato e i registri del server (che so possono essere modificati, ma ho buone ragioni per credere che non lo siano) indicano che SSH non è stato utilizzato per accedere al server.
Lo stack del software di servizio Web è molto complicato. C'è PHP (5.3.3-1) con Suhosin v0.9.29, nginx 1.0.9 (ora aggiornato alla 1.0.10), Tomcat (in una prigione e sospetto non associato) e MySQL 5.1.41.
Ammetto che, al momento del primo attacco, mi ero tranquillamente accontentato di chmod -R 777 la mia directory web per scopi di mitigazione del mal di testa. Ora eseguo un pasticcio completo di script PHP incluso ma non limitato a WordPress, vBulletin e diversi prodotti fatti in casa; i primi due sono sempre aggiornati e quest'ultimo è stato scritto con estrema cura per evitare o normalizzare qualsiasi valore immesso dall'utente.
Viste le deboli autorizzazioni dei file, ma l'accesso al server strongmente bloccato, ero strongmente tentato di sospettare una vulnerabilità in uno dei tanti script PHP che consentivano l'esecuzione di codice casuale.
Da allora ho bloccato completamente i permessi dei file. nginx / php funzionano come www-data: www-data con tutti i file dati solo autorizzazioni di esecuzione e lettura ( chmod -R 550 /var/www ).
Eppure oggi, dopo tutto questo, il mio server è stato nuovamente compromesso.
Il fatto è che i file che sono stati sostituiti hanno ancora le autorizzazioni 550 , i log SSH non indicano il log in e sono completamente perso su cosa fare o provare dopo.
Ho provato a ricreare l'attacco sui percorsi che sono stati sostituiti con uno script PHP di base:
$file = fopen('/var/www/mysite.com/path/to/file', 'w');
fwrite($file, 'test');
fclose($file)
Ma questo mi ha dato l'errore di autorizzazione appropriato negato.
Qualcuno può, per favore, consigliami dove cercare la fonte di questa vulnerabilità? Mi manca qualcosa con i miei permessi sui file?
So che il server, una volta compromesso, è praticamente "sparito" per sempre. Ma non è davvero un'opzione qui. Ho ricorsivamente aggiornato la mia intera cartella / var / log per i nomi dei file afflitti nella speranza di trovare qualcosa, ma non è venuto fuori nulla.
Ho anche cercato qualsiasi script nella cartella cron o altrove che potrebbe essere stato collocato al momento del primo attacco per attaccare di nuovo in un secondo momento, ma (a) non trova nulla e (b) non dovrebbe trovare qualsiasi cosa come i file in / etc / non sono modificabili da www-data (assumendo un punto di infiltrazione nginx / PHP).
Dovrei aggiungere che entrambe le volte ho grep'd i log di accesso di nginx (stile combinato) per i nomi dei file infetti, ma non ho trovato nulla. Capisco / capisco che esistono molti modi per oscurare i nomi dei file dalla mia greps.