Traduzione autorizzata da Sucuri che detiene il copyright dell’articolo. Leggi l’articolo originale (in Inglese)
C’è una tendenza ad attivare del Blackhat SEO cercando di verificare account aggiuntivi in qualità di proprietari di siti compromessi in Google Search Console (precedentemente Strumenti per i webmaster).
Google Search Console fornisce informazioni e strumenti veramente utili per i webmaster che desiderano:
- Scoprire come i loro siti web si comportano nei risultati di ricerca (serp)
- Ricevere notifiche relative a prestazioni, configurazione e problemi di sicurezza
- Risolvere efficacemente i problemi relativi alla SEO (Search Engine Optimization)
Contattaci
chiama 339 848 3250
Non c’è davvero alcun motivo per cui qualcuno non dovrebbe registrare il proprio sito su GSC. Contiene informazioni utili per chiunque desideri che il proprio sito web sia indicizzato da Google. Gli hacker ne sono a conoscenza e cercano di accedere alla Search Console per i siti web che colpiscono, specialmente quando aggiungono i propri contenuti spam e tecnicamente sono anche dei webmasters (malevoli).
Ad esempio, questo è stato trovato in un modello di un pharma hack:
<meta name=”verify-v1″ content=”JxC+bn8NTCEfKZIdusC9WQELc8FEwbi8p32wf9q0QGA=”>
Questa linea di codice consente agli hacker di verificare la proprietà del sito in GSC. Utilizzare un meta tag di verifica Google è solo uno dei tanti approcci che gli hacker utilizzano. In questo post mostreremo altri trucchi (più sofisticati) e discuteremo dei risultati di tali hack.
Perché verificare la proprietà per i siti hackerati?
Innanzitutto, ci si dovrebbe rendere conto che la verifica della proprietà di un sito in Search Console non ti rende un vero proprietario del sito. È solo un modo per dimostrare a Google che controlli il sito. Ci sono diversi modi per farlo: puoi dimostrare di avere accesso ai file del server web, controllare i record DNS di dominio o un servizio Google correlato come Analytics.
Una volta verificata l’accesso al sito web come amministratore, Google visualizzerà le informazioni destinate al proprietario del sito. Puoi anche fare alcune cose che potrebbero influenzare il modo in cui Google indicizza il sito e lo mostra nei risultati di ricerca.
Dovreste anche rendervi conto che Google consente a un sito web di avere più proprietari (ad esempio un proprietario reale e un altro webmaster potranno essere verificati come proprietari, nonché altri esperti di SEO di terze parti potrebbero aver bisogno di autorizzazioni complete del proprietario mentre lavorano sul sito). Ogni proprietario verifica se stesso e aggiunge siti web alla propria Search Console. Se gli hacker si verificano come proprietari del tuo sito, NON significa che la Search Console (o il tuo account Google) sia stato colpito.
E allora perché lo fanno?
Beh, in realtà ci sono diverse cose che gli hacker possono realizzare utilizzando Search Console:
- Raccogliere statistiche che possono spiegare come prosegue la campagna Black Hat SEO: clic, impressioni, CTR, posizioni nei risultati di ricerca di Google e altre amenità nella sezione “Ricerca Analytics”.
- Inserire sitemaps delle pagine spam per consentire a Google di scoprirle velocemente, quindi non è necessario attendere che Google scopra le pagine tramite link su altri siti. Gli hacker potrebbero anche pensare che Google consideri le pagine spam come legittime quando vengono inviate come parte di una sitemap direttamente da un proprietario del sito verificato.
- Ricevere notifiche sul rilevamento di hack. Ciò può aiutare a stimare in che modo Google possa rilevare in modo efficiente le doorway inserite e la quantità di danni che comporta nella loro campagna.
- Disconnettere gli account legittimi in modo che non ricevano notifiche (ad esempio sui problemi di sicurezza) da Google Search Console.
Poniamo l’attenzione sull’ultimo punto e vediamo cosa succede quando qualcuno aggiunge un nuovo proprietario a un sito in Search Console e quando qualcuno rimuove altri proprietari del sito (non verifica i propri account).
Notifica del nuovo proprietario
Quando qualcuno verifica un nuovo account Google come proprietario di un sito, tutti i proprietari di siti esistenti ricevono immediatamente un’email di notifica che dice loro: “Google ha registrato che example@gmail.com è stato aggiunto come proprietario dell’account Search Console per http: // www .example.com “. Questa email avvisa inoltre che solo le persone interessate dovrebbero avere questo accesso e fornire collegamenti utili per consentire di gestire gli utenti esistenti ei loro livelli di autorizzazione.

Fin qui tutto bene. Se gli hacker si aggiungeranno come proprietari del tuo sito, ti verrà immediatamente notificato e potrai rapidamente indagare e risolvere il problema della protezione (disconnetti il loro account, stimare i danni, ripulire il tuo sito, chiudere i buchi di sicurezza ecc.). Questo è davvero utile … grazie Google!
Eliminare la proprieta dei proprietari legittimi è semplice
Cosa succede se hai perso quella email?
Supponiamo che in quel momento eri in vacanza e quando sei tornato l’email era nascosta tra tantissime altre email ricevute … Questo scenario dà agli hacker tempo che possono utilizzare, ad esempio, per eliminare la tua proprietà dell’account affinché tu non possa ricevere nuove notifiche sul sito (ad esempio quando Google rileva problemi di protezione causati dall’hack). Puoi indovinare cosa altro possono fare? Non riceverai notifiche da parte di Google visto che non sei più proprietario del tuo sito in Search Console.
Se accedi raramente a Search Console, non avrai idea che non hai più accesso ai dati del tuo sito.
Ora immaginiamo il seguente scenario: Google rileva l’hack e lo notifica i proprietari del sito. Solo gli hacker riceveranno questa notifica. Il proprietario reale del sito ancora non sa nulla dell’ hack e non farà nulla per pulire il sito. Questo dà agli hacker il tempo per mitigare il problema a loro favore. Diciamo che possono temporaneamente rimuovere le loro doorway e richiedere una revisione da parte di Google. Quando il team Google Web Spam non trova nessuna doorway, sblocca il sito e notifica i proprietari del sito (nel nostro caso gli hacker) tramite la Search Console. Dopo questa notifica, gli hacker semplicemente ripristinano le loro pagine spam (forse utilizzando un modello URL leggermente diverso) e continuano a sfruttare le risorse del sito hackerato.
WNC-582.900
Torniamo al mondo reale. Gli hacker veramente si verificano come proprietari di siti in Google Search Console? La risposta è si. Le email di notifica di “nuovo proprietario” di Google ci aiuteranno a dimostrare. L’ultima frase in quella email dice:
〉 〉 Ask questions in our forum for more help – mention message type [WNC-582900].
Le persone fanno domande nel forum webmaster di Google citando questo tipo di messaggio, la maggior parte dei quali sono correlati ad hacks del sito.
Nuovi proprietari
Tipicamente gli hacker aggiungono più di un account proprietario. Alcuni riportano di 2 nuovi proprietari verificati. Un altro webmaster riceve circa 30 nuove notifiche dei proprietari “verificati” in un solo giorno. Un altro webmaster condivide una schermata della sezione “Proprietari verificati” della Search Console con più di 100 voci (estrapolazione in base alla dimensione e alla posizione di una barra di scorrimento su quella schermata).
〉 〉 So it’s started by yesterday evening, where I received a lot of [WNC-582900] new owner notification message, and after that, when I checked my site owners, I had a LOT of listed owners!
Verifica file HTML
Il metodo più popolare di verifica del sito utilizza file HTML con nomi del tipo google [code] .html e il seguente contenuto:
google-site-verification: google<code>.html
Nell’esempio, il codice è un numero esadecimale unico a 15 cifre associato all’account Google dell’utente. Questo file può essere utilizzato per verificare più siti.
Quando gli hacker hanno accesso a un sito web, è facile per loro creare questo file e verificare se stessi come proprietario.
Ecco qualche ulteriore prova del forum:
- Account di search console hackerato: “Un file di verifica HTML viene inserito nel mio server nella directory principale. Non sono io che lo metto lì, e non viene messo lì con il mio account FTP. “
- Verifica non autorizzata dei proprietari del webmaster: “E nel file manager del mio sito, ho scoperto questi file HTML di verifica creati di recente e ho eliminato i file sconosciuti“.
Di solito questi file vengono caricati tramite vulnerabilità nelle applicazioni web o tramite backdoor che gli hacker installano dopo aver colpito i siti web. Ecco perché eliminare il file e modificare le password FTP di solito non è sufficiente:
Così è successo due volte durante la notte. Ho esaminato tutti i registri ed i percorsi di controllo mostrano che non era il mio account compromesso – le uniche azioni nel server FTP che posso vedere sono quelle che ho fatto.
File di verifica misteriosi
Per disattivare questi “proprietari” dannosi, è necessario rimuovere i file (meta tag, record DNS) utilizzati per la loro verifica. Tuttavia, non è sempre così facile come eliminare un file HTML.
Ci sono alcuni casi in cui i webmaster ricevono notifiche sui nuovi proprietari del sito e la sezione “Proprietari verificati” di Search Console ha indicato chiaramente quali file HTML sono stati utilizzati per la loro verifica, ma non è stato possibile trovare e eliminare i file sul server. Nonostante l’assenza dei file di verifica, Google ha rifiutato di annullare la verifica dei proprietari dannosi perché in qualche modo i file sono stati visibili quando si è tentato di aprirli in un browser.
- hackerata proprietà del mio sito: “Dovrei rimuoverlo, ma andando in FTP al mio sito questo file HTML non esiste né la root né altrove”.
- tipo di messaggio [WNC-582900]. Il proprietario non autorizzato ha ottenuto la verifica – COME ?: “Ho lavorato tutto il giorno con l’host del sito web e il FILE NON è trovato in nessun posto sul mio sito web. … non riesco ad eliminare questa proprietà – Google mi dà il messaggio che il “file di verifica ancora esiste” – ma non è vero! “.
- email truffa da sc-noreply @ google.com (presunto Google Search Console Team): “Inoltre, non esiste alcun” file di verifica “citato nella” console
Nell’ultimo caso, il webmaster non crede nemmeno che le notifiche siano reali (nonostante abbia visto questi nuovi “proprietari” nella sua Search Console). Poiché questa incredulità è stata pubblicata sul suo sito web ad accesso pubblico, immagino che non gli dispiacerà se spiego pubblicamente che le email erano autentiche, il suo sito è stato hackerato e perché non ha trovato i file di verifica.
Prima di tutto, Google utilizza l’indirizzo email “sc-noreply @ google.com” per le notifiche di notifica di Search Console. Ma hanno cominciato ad usarlo solo dopo il rebranding di Strumenti per i webmaster. Questo spiega perché non si vedono molti riferimenti sul web.
Spam SEO in giapponese
Nella nostra esperienza, la verifica della proprietà del sito è attualmente utilizzata principalmente in attacchi che creano tonnellate di pagine doorway in giapponese (vediamo decine di migliaia di siti interessati, con oltre un miliardo di doorway create). Lavorano in una nicchia di “beni di marca falsificati” e si rilevano normalmente se si cerca nel tuo sito per parole chiave come “louboutin“, “gucci“, “louis vuitton“, “moncler“, “ray ban” ecc. . Quindi la prima cosa che ho fatto quando ha incontrato quel post di blog era la ricerca del sito per lo spam giapponese SEO. Certo, l’ho trovato lì.

Dopo aver trovato lo spam giapponese, sapevo esattamente perché il webmaster non riusciva a trovare i file di verifica. Questo attacco utilizza un approccio intelligente per la verifica di Google che merita una rassegna dettagliata:
.htaccess Rewrite Rules
Gli attaccanti caricano uno script PHP che genera doorway in una certa sottodirectory e quindi aggiunge le regole di riscrittura a file .htaccess per dare agli URL spam un aspetto più legittimo – come se fossero ad un livello superiore del sito, in alcuni casi come pagine statiche .html , ecc. Tra queste regole di riscrivere le doorway, inoltre, aggiungono una regola specifica di riscrittura per i file di verifica di Google:
…
RewriteRule ^ ([0-9] +) / (. *) – (. *) – ([0-9] +) \. Html $ wp-content / file.php? Uu = $ 2- $ 3- $ 4 [L ]
RewriteRule ^ ([0-9] +) / google (. *) \. Html $ wp-content / file.php? Google = $ 2 [L]
RewriteRule ^ (. *) – (. *) – ([0-9] +) \. Html $ wp-content / file.php? Uu = $ 1- $ 2- $ 3 [L]
…
Come potete vedere, la seconda regola corrisponde al formato dei nomi dei file di verifica di Google e riscrive le richieste a un file corrotto di nome file.php con un parametro “google” il cui valore è uguale a un ID Search Console unico del file di verifica richiesto. Questa regola funziona per qualsiasi file di verifica di Google richiesta indipendentemente dal suo nome. Quindi, se qualcuno cerca di aprire http: // www. esempio. com / dir / google77aa6bc3a2973942.html, dietro le quinte, il server apre http: // www. esempio. com / wp-content / file.php? google = 77aa6bc3a2973942.
Rappresentazioni multiple dello stesso sito in Google Search Console
Si prega di notare che questo file .htaccess prevede che Google richiederà il file di verifica in una sotto-directory, non al livello principale. Non è un errore. Google ti consente di verificare la proprietà di varie sezioni e versioni dello stesso sito. Ad esempio, puoi aggiungere separatamente all’account Search Console:
http: // example.com
http: // www. example.com
https: // example.com
https: // www. example.com
http: // example.com/blog/
eccetera.
Anche se è tecnicamente lo stesso sito, ognuno di loro richiede una verifica separata. Nel nostro caso, gli hacker erano particolarmente interessati a verificare la proprietà delle sottodirectory che avevano creato per la loro campagna di spam.
Generazione di file di verifica dinamica
Ora vediamo come funziona lo script file.php.

È un tipico script doorway che restituisce pagine spam a Googlebot e reindirizza il resto dei visitatori. La parte interessante è l’ultima quattro righe di codice. Questo script genera dinamicamente il contenuto tipico (e il 100% valido) di un file di verifica di Google.
Torniamo al nostro esempio, dove la regola di riscrittura .htaccess ha richiesto la pagina file.php? Google = 77aa6bc3a2973942. In questo caso, la risposta del server sarà:
google-site-verification: google77aa6bc3a2973942.html
Questo è esattamente quello che Google prevede di vedere quando verifica la proprietà.
Questo trucco rende difficile trovare ed eliminare i file di verifica se un vero proprietario del sito desidera eliminare la proprietà gli account hacker. Allo stesso tempo, questo è un approccio molto flessibile per l’aggressore, in quanto non è necessario attenersi a un account Google specifico. Possono utilizzare qualsiasi account Google o comunque molti account che amano verificare la proprietà. Se un account è disattivato, non è necessario modificare nulla sul server per verificare un altro account.
Un simile trucco .htaccess è stato trovato in uno dei thread di cui sopra:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^ ([a-zA-Z0-9 _-] +). Html $ wp-include / themes / good / $ 1.php [L]
RewriteRule ^ index \ .php $ – [L]
RewriteCond% {REQUEST_FILENAME}! -f
RewriteCond% {REQUEST_FILENAME}! -d
RewriteRule. /index.php [L]
</ IfModule>
Qui gli URL dei file di verifica di Google vengono riscritti nei file PHP con gli stessi nomi all’interno della cartella wp-includes / themes / good /. Per esempio. nel caso del nostro esempio precedente, sarebbe wp-include / themes / good / google77aa6bc3a2973942.php.
Questo approccio nasconde anche i file di verifica dagli utenti, ma è una soluzione meno flessibile in quanto richiede l’esistenza di un file [php] di codice [google] sul server. In questo caso, gli hacker possono verificare solo alcuni account predefiniti per i quali hanno già caricato i file di verifica. Probabilmente è una versione più vecchia dello stesso attacco.
Ai webmaster
La verifica di utenti malintenzionati come proprietari di siti in Google Search Console è un fenomeno relativamente nuovo e non è ancora chiaro se questo è qualcosa che gli hacker adotteranno come uno strumento utile nel loro arsenale o abbandoneranno come qualcosa di valore discutibile. In entrambi i casi, i proprietari di siti web devono essere preparati per tali attacchi e soprattutto utilizzare a loro favore il sistema di notifica di Google.
- Assicurati di aver registrato e verificato la proprietà di tutti i tuoi siti (inclusi i sottodomini) in Google Search Console. Se qualcun altro cerca di verificare la proprietà dei tuoi siti (o delle sezioni dei tuoi siti), riceverai immediatamente una notifica da parte di Google e sarà in grado di attenuare rapidamente il problema. Se non aggiungi i tuoi siti alla console di ricerca di Google, non riceverai mai tali notifiche preziose. E, a proposito, questo non è l’unico problema di sicurezza che Google ti informerà.
- Se ricevi le notifiche di “nuovo proprietario” da parte di Google, non prenderle alla leggera. Non solo devi disattivare tutti i conti sconosciuti, ma anche indagare su come sono stati in grado di verificarli. Nella maggior parte dei casi significa che avevano accesso completo al tuo sito, quindi dovresti chiudere tutti i buchi di sicurezza e rimuovere tutti i contenuti dannosi che gli hacker potrebbero aver già creato sul tuo sito.
- Come ho dimostrato in precedenza, è molto facile per gli hacker rimuovere te come proprietario del tuo sito quando qualcuno ha accesso al tuo server. E nemmeno ti verrà notificato. Se non si desidera che gli hacker possano facilmente verificare il tuo account, considerare i seguenti 3 metodi di verifica alternativi:
Tramite un fornitore di nome di dominio;
Tramite un codice di monitoraggio di Google Analytics;
Attraverso un snippet del contenitore di tag Google Tag Manager.
A differenza del file HTML e dei metodi di verifica Meta tag, questi tre richiedono agli hacker di accedere ai tuoi account di registrazione del nome di dominio di Google e di dominio per poter verificare la verifica.
A Google
Sebbene Google faccia un ottimo lavoro per i notificare i proprietari del sito a verifiche potenzialmente dannose di nuovi proprietari e fornir loro tutte le informazioni e gli strumenti necessari per risolvere tali problemi, sembra che non siano preparati per alcuni scenari.
Perché non inviare una notifica “addio” a un proprietario del sito non verificato di recente? Anche se si trattava di una verifica completamente benigna di qualcuno che non lavora più sul sito, queste persone meritano di essere informati. Dal momento che non sono più “proprietari di siti”, non dovrebbe essere alcuna preoccupazione che Google invia troppe notifiche. D’altra parte, se la non-verifica è stata dannosa, il proprietario reale del sito sarà sicuramente voglia di sapere!
Vediamo che gli hacker a volte verificano parecchi account in un tempo molto breve. È bene che tu invii notifiche su ciascuno di essi. Forse dovresti anche considerare una simile attività come segno di compromesso? Questo è un buon motivo per dare un’occhiata più da vicino a un sito (vale a dire i tuoi malware e gli scanner di spam) e contrassegnare i conti aggiunti per ulteriori indagini, specialmente quando appaiono in molti siti non collegati (gli hacker possono riutilizzare i conti quando entrano in migliaia di persone siti e verificare decine di conti per ciascuno di essi).
In conclusione, vorrei invitare i lettori a condividere il tuo pensiero su questo fenomeno di “verifica del proprietario”. Hai mai notato un’attività dannosa in Google Search Console (ex-Strumenti per i webmaster)?
Articolo di Denis Sinegubko, Senior Malware Researcher presso Sucuri.
Lascia un commento