Sono stato violato. Vuoi capire come

Qualcuno ha, per la seconda volta, aggiunto un pezzo di javascript a un sito che aiuto a eseguire. Questo javascript dirotta Google Adsense, inserendo il proprio numero di account e inserendo annunci ovunque.

Il codice viene sempre aggiunto, sempre in una directory specifica (quella utilizzata da un programma di annunci di terze parti), influisce su un numero di file in un numero di directory all'interno di questa directory annuncio (circa 20) e viene inserito all'incirca nello stesso giorno tempo. L'account AdSense appartiene a un sito Web cinese (situato in una città a non un'ora da dove sarò in Cina il mese prossimo. Forse dovrei andare a testa in giù ... scherzando, una specie di), a proposito ... ecco le informazioni su il sito: http://serversiders.com/fhr.com.cn

Quindi, come hanno potuto aggiungere testo a questi file? È correlato alle autorizzazioni impostate sui file (che vanno da 755 a 644)? Per l'utente del server web (è su MediaTemple, quindi dovrebbe essere sicuro, sì?)? Voglio dire, se hai un file con autorizzazioni impostate su 777, non posso ancora aggiungere il codice a piacimento ... come potrebbero farlo?

Ecco un esempio del codice reale per il tuo piacere di visione (e come puoi vedere ... non molto. Il vero trucco è come l'hanno inserito lì):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

Dato che diverse persone lo hanno menzionato, ecco cosa ho controllato (e per segno di controllo intendo che mi sono guardato intorno nel momento in cui i file sono stati modificati per qualsiasi stranezza e ho greppato i file per istruzioni POST e traversal di directory:

• access_log (niente nel tempo tranne traffico normale (es. eccessivo) msn bot)
• error_log (nient'altro che il solito file non esiste errori per file dall'aspetto innocuo)
• ssl_log (nient'altro che il solito)
• message_log (nessun accesso FTP qui tranne me)

* AGGIORNAMENTO: ** OK, risolto. Gli hacker dalla Cina avevano fisicamente inserito un file nel nostro sito che consentiva loro di fare ogni sorta di cose amministrative (accesso al database, eliminazione e creazione di file e directory, tu lo chiami, loro avevano accesso). Siamo stati fortunati a non aver fatto qualcosa di più distruttivo. Non c'era nulla nei normali file di log di Apache, ma ho trovato un diverso set di file di log in un analizzatore di log del server Web e le prove erano lì. Stavano accedendo a questo file con il proprio nome utente e password di amministratore e quindi modificando tutto ciò di cui avevano bisogno proprio lì sul server. Il loro file ha "apache" impostato come utente mentre tutti gli altri file sul nostro sito hanno un nome utente diverso. Ora ho bisogno di capire come hanno fisicamente ottenuto questo file sul nostro sistema. Ho il sospetto che la colpa sia dovuta al nostro host web (Media Temple),

Prima di tutto chmod 744NON è quello che vuoi. Il punto di chmod è revocare l'accesso ad altri account sul sistema. Chmod 700è molto più sicuro di chmod 744. Tuttavia Apache necessita solo del bit di esecuzione per eseguire l'applicazione php.

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data è comunemente usato come account Apache che viene utilizzato per eseguire il php. È inoltre possibile eseguire questo comando per visualizzare l'account utente:

`<?php
print system("whoami");
?>`

FTP è terribilmente insicuro ed è molto probabile che tu sia stato violato da questo metodo. Usando FTP puoi rendere i file scrivibili e quindi infettarli di nuovo. Assicurati di eseguire un antivirus su tutte le macchine con accesso FTP. Esistono virus che annusano il traffico locale per i nomi utente e le password FTP e quindi accedono e infettano i file. Se ti interessa la sicurezza, utilizzerai SFTP, che crittografa tutto. L'invio di codice sorgente e password via cavo in chiaro è una follia totale.

Un'altra possibilità è che stai utilizzando una vecchia libreria o applicazione. Visita il sito del fornitore del software e assicurati di utilizzare la versione più recente.

Gli account My Media Temple Grid Server sono stati "hackerati" in questo modo diverse volte. La loro sicurezza è molto scarsa ... è iniziata con PASSWORD DI TESTO NORMALE l'anno scorso e continua ancora oggi (potresti chiamare l'assistenza tecnica e dire "qual è la tua password?"). Lo so perché ricevo email mensili su come hanno cambiato tutte le password del mio account e in realtà entrano e cambiano le password del database per te ogni volta che vengono hackerate. Quell'azienda sembra lucida in superficie, ma il server della griglia è un casino. Consiglio di passare immediatamente .

Si prega di vedere questo post dello scorso anno sul fiasco originale (attenzione, ti farà incazzare). È andato in discesa da lì. L'anno scorso ho trascorso il giorno del ringraziamento lontano dalla mia famiglia e ho rimosso i collegamenti porno dai miei siti Web. Bello.

Tieni traccia del divertimento sulla loro pagina di stato : ti dirà tutto sugli ultimi exploit (e sì sì, c'è un "possibile exploit" lassù in questo momento).

In base alla mancanza di attività nei registri di accesso, ecc. E al fatto che sta accadendo all'incirca nello stesso momento, sembra che abbiano compromesso il server e che abbiano uno script shell di qualche tipo in esecuzione per eseguire l'aggiunta.

Hai controllato crontab per qualcosa di strano?

Hai provato a rinominare la directory e i riferimenti ad essa (questo potrebbe interrompere lo script della shell)?

Sì, potrebbe sicuramente essere correlato alle autorizzazioni dei file. Avendo i file che sono scrivibili dal processo Web, sei aperto a qualsiasi vulnerabilità di sicurezza nelle applicazioni Web che stai eseguendo. Blocca tutto in modo che il processo Web non possa leggere o scrivere nulla di più di quanto sia necessario.

L'altro componente sta rintracciando esattamente come stanno modificando i tuoi file. Controllare i log di accesso del server Web è un buon punto di partenza. Controlla gli ultimi orari di accesso per vari utenti. Potresti anche impostare uno script che monitora i file per le modifiche e ti avvisa in modo da poter provare a catturare i criminali in flagrante!

Questo suona terribilmente familiare agli hack di Wordpress che hanno colpito recentemente una serie di siti di Network Solutions. Dato che sei su Media Temple, è possibile che tu abbia lasciato alcuni file visibili ad altri utenti che condividono il tuo computer. Ciò spiegherebbe la mancanza di tracce di log POST o Eery Apache. In tal caso, sarebbe estremamente semplice iniettare codice dalla riga di comando.

Il codice viene sempre aggiunto, sempre in una directory specifica

È correlato alle autorizzazioni impostate sui file (che vanno da 755 a 644)? Per l'utente del server web

Sei su un server condiviso? In tal caso (o anche in caso contrario), qualcuno potrebbe aver forzato una password FTP e aver caricato uno script che ha aggiunto tutti i file su cui è riuscito a mettere le mani.

uno utilizzato da un programma di annunci di terze parti

O forse questo programma ha un exploit.

Se si dispone dell'accesso appropriato (e del supporto del kernel), si potrebbe provare a montare un demone di monitoraggio basato su inotify o dnotify per controllare le modifiche ai propri file, quindi (rapidamente) usare "lsof" per vedere con quale processo ha aperto il file accesso in scrittura. Potresti anche essere in grado di utilizzare strace per il monitoraggio. Ciò dovrebbe fornire un indizio su quale eseguibile viene sfruttato.

I log di ispezione FTP sono il primo punto da cui iniziare. Il registro dovrebbe contenere la maggior parte se non tutte le attività insieme ai timestamp, quindi se sai a che ora sono stati modificati i tuoi file puoi determinare se il tuo account FTP è compromesso o meno.

Successivamente, potrebbe essere uno script sul tuo server web che sta iniettando quel codice. In uno scenario di hosting condiviso, penso che sia possibile fare un cat /web/malicious.com/script.js >> /web/innocent.com/index.php. Questo potrebbe funzionare in determinate condizioni, come il comando eseguito dall'utente httpd e il file index.php è anch'esso di proprietà / scrivibile da quell'utente. In tal caso dovresti avere il tuo provider di hosting per tracciare l'account utilizzato per iniettare gli script.

La maggior parte dei file del sito deve essere leggibile dal server web. Su un sito di sola lettura, solo i log devono essere scrivibili dal server web. impostare il proprietario su un utente diverso da quello utilizzato dal server Web. Impostare la protezione 640 su tutti i file tranne gli script. Imposta script e directory 750. Per i file o le directory che devono essere scritti dal websever è possibile modificare il proprietario sul server Web o impostare chmod g + 2 i file o le directory pertinenti.

Ci sono molti miliardi di modi per craccare un sito. Avrebbero potuto usare una vulnerabilità nel tuo script, rubare la tua password, usare una vulnerabilità di un sito ospitato congiuntamente (se ti trovi in ​​un host economico), usare una vulnerabilità di alcuni servizi non legati al web sul computer server. .

Come primo passo, controlla la data di modifica del file e controlla i log di accesso, errore e ftp per eventuali attività sospette in quel momento.

La stessa cosa mi è successa qualche tempo fa. Wordpress era l'unico software che avrebbe causato qualcosa del genere per quanto ne so.