Aggiornamento sulla Sicurezza WordPress. Botnet all’attacco di siti WordPress.

Il Defiant Threat Intelligence Team ha recentemente iniziato a tracciare un comportamento anomalo di una campagna di attacchi Brute Force organizzata contro siti WordPress. Questa campagna ha creato una botnet di siti Web WordPress infetti per eseguire ulteriori attacchi verso altri siti WordPress, nel tentativo di bucare l’autenticazione XML-RPC, per accedere agli account con privilegi.

Negli ultimi trenta giorni, sono stati rilevati da alcuni WAF, cinque milioni di tentativi di autenticazione maligni associati a questo tipo di campagna.

Gli autori delle minacce (gli hacker) utilizzano un gruppo di quattro server C2 (command and control) per inviare richieste a oltre 14.000 server proxy forniti da un provider proxy russo chiamato best-proxy.ru. Usano questi proxy per rendere anonimo il traffico C2. Le richieste passano attraverso i server proxy e vengono inviate a oltre 20.000 siti WordPress infetti. Questi siti stanno eseguendo uno script di attacco che attacca altri siti WordPress mirati. Lo schema seguente illustra la catena di sequenza d’attacco.

In questo articolo, descriveremo questa catena di attacco in dettaglio in modo che ricercatori, venditori e team per le operazioni di sicurezza possano beneficiarne. In alcuni casi sono stati omessi o cancellati i dati, perché i server C2 e i siti WordPress infetti sono ancora online e potrebbero essere sfruttati da altri. Attualmente sono in corso manovre di esperti, team organizzati che stanno condividendo i dati con le forze dell’ordine relative a questa indagine. Inoltre si stanno fornendo dati agli stessi host interessati per aiutarli a rimediare alle macchine infette nelle loro reti.

Identificazione di script Brute Force

Nella ricerca di questa campagna è stato determinato che gli IP che eseguivano gli attacchi Brute Force erano quasi tutti associati ai popolari provider di hosting web (italiani e non) e che gli attacchi erano tutti rivolti all’interfaccia XML-RPC di WordPress su /xmlrpc.php.

E’ stato anche notato che le stringhe User-Agent associate a queste richieste corrispondevano a quelle utilizzate dalle applicazioni comunemente viste interagendo con l’interfaccia XML-RPC, come wp-iphone e wp-android. Poiché in genere queste applicazioni memorizzano le credenziali localmente, è stato inusuale vedere da parte loro, una quantità così significativa di accessi non riusciti, il che ha attirato l’attenzione dei team di sicurezza. Sono stati identificati oltre 20.000 siti slave WordPress che stavano attaccando altri siti WordPress.

WordPress che attacca WordPress

Con questi dati in mano, hanno continuato ad identificare gli script di attacco Brute Force presenti su siti WordPress infetti, corrispondenti agli attacchi che stavamo singolarmente monitorando. Gli script mirano all’interfaccia XML-RPC dei siti WordPress per testare le coppie nome utente / password, Utilizzando uno spoof a caso delle stringhe User-Agent di ogni richiesta:

foreach ($request as $i => $id) {
 $xmlualist = array("Poster", "WordPress", "Windows Live Writer", "wp-iphone", "wp-android", "wp-windowsphone");
 $xmlual = $xmlualist[array_rand($xmlualist)];

Lo script brute force accetta l’input di comando e controllo (C2) tramite POST per definire alcune impostazioni di esecuzione, come un array JSON di domini mirati e un wordlist locale da utilizzare:

if ($_POST['secret']=='111'){
    $timer = time();
    libxml_use_internal_errors(true);
    ini_set('memory_limit', '-1');
    ini_set('max_execution_time', 500000000000);
    $request = array();
    if(checkWordsList($_POST['wordsList'], $_POST['path'], $_POST['hash'])){
        $domainsData = json_decode($_POST['domainsData'], true);
        foreach($domainsData as $item){
            $brutePass = createBrutePass($_POST['wordsList'], $item['domain'], $item['login'], $_POST['startPass'], $_POST['endPass']);
            $request[] = array('id'=>$item['id'], 'user'=>$item['login'], 'request'=>createFullRequest($item['login'], $brutePass),'domain'=>'http://' . trim(strtolower($item['domain'])).'/xmlrpc.php', 'brutePass'=>$brutePass);
        }

Generazione dinamica di Wordlist

Le Wordlist associate a questa campagna contengono piccole serie di password molto comuni. Tuttavia, lo script include funzionalità per generare dinamicamente password appropriate basate su modelli comuni. Alcuni esempi di questi modelli sono:

%DomainPattern%
%nome utente%
%Username%1
%Username%123
%Username%2018
%Username%2017
%Username%2016

In altre parole, se lo script Brute Force tenta di accedere a esempio.com come utente, genererà password come esempio, alice1, alice2018 e così via. Anche se è improbabile che questa tattica abbia successo su un determinato sito, può essere molto efficace se utilizzata su larga scala con un numero elevato di obiettivi.

Funzionalità Multicall

L’interfaccia XML-RPC di WordPress ha visto un aumento degli attacchi Brute Force nel 2015, quando gli attacchi che sfruttano la funzionalità multicall sono diventati popolari. In breve, utilizzando questa interfaccia un utente malintenzionato potrebbe inviare un numero elevato di coppie utente/password in una singola richiesta. WordPress testerebbe ogni coppia e restituirebbe un elenco di successi e fallimenti. Questa tecnica ha reso il processo di attacco brute force molto più facile da avviare su scala, dal momento che un dispositivo attaccante avrebbe solo bisogno di inviare un singolo batch di credenziali e attendere una risposta.

Lo script Brute Force in questa campagna è costruito per eseguire questo tipo di attacco multicall di default. Il frammento di codice seguente mostra la funzione che, quando viene fornito un nome utente e una serie di password, assemblerà un singolo oggetto XML contenente tutte le password da tentare di forzare.

function createFullRequest($login, $passwords){
    $xml = createRequestXML();
    for($i = 0; $i < count($passwords); $i++){ $xml = addElementXML($xml, $login, $passwords[$i]); } $request = $xml->saveXML();
    return $request;
}

I sistemi C2 che impartiscono istruzioni allo script Brute Force possono facoltativamente definire variabili $startPass e $endPass, che indicano allo script di tentare solo un sottoinsieme di password su un determinato elenco invece di eseguire l’intero set.

Attacchi Multicall non più efficaci (principalmente)

Molti utenti di WordPress non sanno che questo attacco multicall XML non è più efficace. Una patch per wp-include/class-wp-xmlrpc-server.php è stata introdotta in WordPress 4.4. Con questa patch, se un tentativo di accesso in una richiesta XML-RPC non riesce su un sito Web target, quel sito Web fallirà immediatamente tutti i tentativi successivi nella stessa richiesta, anche se le credenziali sono valide.

La patch XML-RPC per WordPress 4.4 è stata rilasciata in modo silenzioso e non è stata divulgata nelle note di rilascio. Inoltre non è stato sottoposto a backport in precedenti sezioni di WordPress come la maggior parte delle correzioni di sicurezza, nonostante fosse una patch relativamente poco invasiva. Per chiarire, anche se un sito è sull’ultima versione di sicurezza di un ramo WordPress dalla versione 4.3 e precedenti, può essere vulnerabile a questo metodo di attacco.

Gli aggressori di questa campagna sembrano essere consapevoli di questo miglioramento. Un certo numero di richieste da sistemi C2 a siti (precedentemente) infetti sono stati intercettati da WAF esterni, tutte queste richieste definiscono lo stesso valore per i parametri $startPass e $endPass sopra descritti. Ciò significa che gli script di attacco finiscono per tentare l’autenticazione con una combinazione utente/password alla volta, deprecando efficacemente la funzionalità multicall dello script stesso.

Infrastruttura di Attacco rivelata

Come accennato in precedenza, siamo stati in grado di catturare le richieste inviate dai sistemi C2 alla rete di siti WordPress infetti e abbiamo avuto successo nell’acquisire una grande quantità di informazioni da questi dati.

Server C2 centrali identificati

La catena di attacco in questa campagna ha fatto uso di più livelli di astrazione tra l’attaccante e i siti di destinazione. Gli attacchi Brute Force vengono eseguiti da una rete di siti WordPress infetti, che ricevono istruzioni tramite una rete di server proxy, quindi in genere sarebbe molto difficile tenere traccia dei server C2 centrali dietro a tutto il resto. Siamo stati fortunatiLa fortuna sta nel fatto che, chi attacca abbia commesso alcuni errori nella loro implementazione degli script Brute Force.

Poiché gli script utilizzano entrambi elenchi di parole memorizzati nello stesso sito WordPress infetto, includono funzionalità per rigenerare queste liste di parole, se necessario:

function checkWordsList($filename, $path, $hash){
    if(file_exists($_SERVER["DOCUMENT_ROOT"].'/'.$filename) and md5_file($_SERVER["DOCUMENT_ROOT"].'/'.$filename) == $hash){
        return true;
    }else{
        downloadCurlTarg($path, $_SERVER["DOCUMENT_ROOT"].'/'.$filename);
        if(file_exists($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) and md5_file($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) == $hash){
            return true;
        }else{
            return false;
        }
    }
}

 

La funzione checkWordsList() passa un valore $path che definisce un indirizzo remoto contenente la wordlist da utilizzare. Se manca la wordlist locale, lo script scaricherà la lista dall’indirizzo indicato. Questo percorso viene fornito insieme al resto dei dati POST inviati dai server proxy allo script brute force. Le richieste intercettate dai WAF includevano questo percorso, che conteneva un indirizzo IP.

Questo IP indicava un server che conteneva una pagina di accesso, che suggeriva di aver trovato qualcosa di grande.

Sono stati poi identificati un totale di quattro server di comando e controllo attivi coinvolti nella campagna di Brute Force.

Accesso all’interfaccia C2

Una breve analisi dei siti C2 ha rivelato che, nonostante la pagina di accesso, l’autenticazione di questi sistemi non è stata effettivamente applicata. Il tentativo di accedere alle pagine dell’interfaccia C2 attiverebbe un re-indirizzamento 302 alla pagina di accesso, ma l’applicazione ha comunque inviato i dati della pagina accanto al re-indirizzamento.

Richiesta cURL alla home page di un server C2. Notare il re-indirizzamento 302 su /login.php e la risposta HTML che lo segue.

Usando BurpSuite, è stata creata una regola proxy che ignora questo re-indirizzamento dell’accesso, dando la possibilità di esplorare liberamente l’interfaccia dell’applicazione C2. Contenute all’interno dell’interfaccia c’era una serie di funzionalità, inclusa la possibilità di accedere a un elenco di “slave”, che si riferivano ai siti WordPress infetti contenenti script Brute Force.

Una vista disponibile nell’interfaccia C2 che mostra un elenco di log esportati dall’hacker.

Connessione identificata a Best-Proxies.ru

Con l’accesso alle interfacce di questi server C2, sono stati in grado di identificare la relazione tra questi server e i server proxy che inviano comandi ai siti “slave”. Ogni server conteneva un file nel suo webroot denominato proxy.txt. Questo file contiene un elenco di quasi diecimila indirizzi proxy SOCKS, con indirizzi IP e porte. Questi indirizzi IP coincidevano con i server proxy identificati in precedenza, suggerendo che C2 utilizzi questo file per selezionare casualmente un proxy durante l’emissione di ciascun attacco. Sono stati identificati 14.807 server proxy.

È interessante notare che il file proxy.txt su uno dei server C2 non conteneva un elenco di indirizzi proxy, ma conteneva invece un documento HTML. Il documento era una copia di un errore 503 Servizio non disponibile, incluso un collegamento a api.best-proxies.ru. Anche in questo documento c’era il testo russo che si traduce in “Errore di autorizzazione: il periodo di validità di questa chiave è scaduto, è possibile acquistare una nuova chiave”.

Si scopre anche che gli hacker hanno dimenticano di pagare le bollette.

Screenshot del documento di errore memorizzato su un server C2, suggerendo che l’utente malintenzionato non ha rinnovato la chiave API utilizzata per accedere agli elenchi dei proxy.

Date le circostanze, è probabile che il server C2 indirizzi il proprio elenco di proxy SOCKS da api.best-proxies.ru memorizzando direttamente la risposta dell’API in proxy.txt. Quando l’API restituisce un errore, questo errore sovrascrive l’elenco dei proxy.

Collaborazione con le autorità competenti

Una grande quantità di dati preziosi è stata raccolta come parte di questa indagine. A causa della natura del lavoro svolto, sono stati mantenuti i contatti con numerose agenzie di polizia in tutto il mondo. Mentre in generale vengano condivisi dati con la maggior parte dei blog nella rete, come gli indirizzi IP e altri indicatori di compromesso, in questo caso è stato scelto scelto di conservare alcune di queste informazioni al fine di evitare interferenze con possibili indagini future.

Oltre alle forze dell’ordine, sono stati contattati alcuni provider di hosting che identificati con un gran numero di siti “slave” infetti. La speranza è che fornire queste informazioni possa aiutare a limitare l’efficacia di questa campagna riducendo il numero di siti attivi che vengano lanciati ulteriori attacchi.

Cosa dovrebbero fare i proprietari dei siti?

Per evitare che il vostro sito cada vittima di attacchi di Brute Force come questi, è utile implementare restrizioni e blocchi per accessi non riusciti. Esistono sistemi e procedure che offrono una robusta protezione brute force e che bloccano gli IP che lanciano tali attacchi.

Consultate un professionista che sappia indirizzarvi verso le corrette procedure di difesa da adottare in casi come questi.

Se ritenete che il Vostro sito sia infetto e lanci attacchi come descritto di questa campagna, Vi preghiamo di prendere in considerazione l’utilizzo dei nostri servizi di Management su Server Dedicati, VPS e siti. Avendo una certa familiarità con questi casi e possiamo garantire che il Vostro problema possa essere gestito in modo corretto e competente.

Non esitate di contattarci per avere maggiori informazioni, e servizio audit in tempo reale.

In Conclusione

Il Defiant Threat Intelligence Team ha identificato una vasta campagna di attacchi Brute Force contro i siti web di WordPress. Questi attacchi sono stati lanciati da script maligni collocati su altri siti WordPress, che hanno ricevuto istruzioni da una botnet con una sofisticata catena di attacco, utilizzando un provider proxy stanziato in Russia.

Non esitate di contattarci per avere un miglior controllo ed effetto sul vostro sito o applicazione, in modo che non possa rivelarsi dannoso per la vostra attività e il futuro della vostra reputazione in Rete.

 

Nuovo WordPress 5.0: come e quando aggiornare.

wordpress 5.0

WordPress 5.0 è stato già rilasciato il 7 dicembre 2018 in Italiano. Questa versione contiene un’importante modifica all’editor di WordPress. Il nuovo editor, nome in codice Gutenberg, rappresenta un notevole passo in avanti nella funzionalità. Usa un nuovo sistema basato su blocchi per la modifica che ti consente di incorporare una vasta gamma di contenuti nei tuoi post e pagine e consentendo molta flessibilità nel tracciare quei blocchi sulla pagina stessa.

Una volta che Gutenberg e WordPress 5.0 si sono stabilizzati, forniranno benefici a lungo termine agli utenti di WordPress e alla comunità. Ma a breve termine, questo cambiamento potrebbe introdurre delle difficoltà per alcuni proprietari di siti WordPress. In questo articolo discuteremo di alcuni punti che aiuteranno a decidere quando passare a WordPress 5.0 e a formulare una strategia di successo per effettuare efficacemente l’aggiornamento.

Perché WordPress sta cambiando l’editor?

Il team di sviluppo di WordPress ha parlato di Gutenberg per un bel po’ di tempo. L’obiettivo, secondo Matt Mullenweg, è “semplificare la prima esperienza utente con WordPress – per coloro che stanno scrivendo, modificando, pubblicando e progettando pagine web. L’esperienza di editing ha lo scopo di fornire agli utenti una migliore rappresentazione visiva di come appariranno i loro post o pagina quando vengono pubblicati”.

Nel complesso, siamo d’accordo sul fatto che Gutenberg sarà un enorme balzo in avanti nell’uso di WordPress per creare contenuti online. Ma, come dichiarato da Matt, l’obiettivo è semplificare l’esperienza per l’utente principiante. Per il resto di noi che hanno assemblato e sviluppato una serie di strumenti per colmare le lacune nelle carenze del vecchio editor, questo sarà un periodo di adattamento.

Potenziali problemi con i plug-in e i temi legacy

WordPress è attivo da oltre 15 anni e in questo periodo sono stati creati milioni di siti web utilizzando l’attuale framework di editing. Spesso i siti vengono creati e mai aggiornati su temi più moderni. Ci sono un gran numero di plugin abbandonati installati su siti WordPress – plugin che non sono più mantenuti attivamente dai loro sviluppatori. Nessuno sta testando questi plugin abbandonati o temi precedenti per vedere come si comportano con Gutenberg.

Oltretutto in aggiunta alla complessità, molti di questi siti possono essere ospitati su servizi di hosting WordPress gestiti che si aggiorneranno automaticamente alla nuova versione di WordPress.

Alcuni proprietari di siti WordPress potrebbero non essere in grado di modificare in modo efficace le pagine che avevano precedentemente pubblicato. Alcuni potrebbero anche non essere in grado di accedere alla loro schermata di modifica. Possono verificarsi errori del server 500 o schermi bianchi per alcuni utenti. Oppure tutto può funzionare senza problemi, anche con i plugin precedenti o un tema precedente.

Con oltre 60.000 plug-in unici nella directory ufficiale di WordPress, non è possibile testare tutti i plugin con il nuovo editor. I plugin mantenuti attivamente sono, per la maggior parte, testati dagli autori dei plugin stesso. I plugin abbandonati non saranno stati testati, quindi spetta a voi testare se WordPress 5.0 funzionerà con questi plugin.

Lo stesso vale per i temi. Molti temi sono mantenuti attivamente dai loro autori. In altri casi, un tema potrebbe essere stato creato come un singolo progetto per un cliente o creato per la comunità e quindi lasciato e non mantenuto. Questi temi non mantenuti non sono stati testati con Gutenberg e WordPress 5.0.

Se si prevedono problemi di compatibilità con WordPress 5.0, è possibile mantenere l’attuale editor di WordPress installando il plugin WordPress Classic Editor. Vi Consigliamo di farlo prima del tempo, piuttosto che proviate a utilizzare il nuovo editor con codice incompatibile. Ma vale anche la pena sottolineare che Gutenberg e WordPress 5.0 sono un significativo passo avanti che permette di modificare con potenza e flessibilità i suoi contenuti. Vale quindi la pena investire il tempo necessario per rendere il sito compatibile, modificandolo se necessario e sfruttando i vantaggi di un nuovo editor basato su blocchi di contenuto.

Come faccio a sapere se sono pronto?

Hai un ambiente di test per il tuo sito web? Hai provato il nuovo editor Gutenberg? Stai usando una versione moderna di PHP? Ottimo, probabilmente sarai preparato per WordPress versione 5.0. Come per tutte le versioni principali, consigliamo di aggiornare prima in ambiente di test per cercare eventuali problemi.

Cercate anomalie con tutti i layout di pagina. È inoltre opportuno tornare indietro nel tempo nell’ambiente di test e rivedere post e pagine meno recenti per assicurarsi che siano pronti per il nuovo editor.

Come sempre eseguite il backup sia dei file del sito che del database prima di qualsiasi aggiornamento, in particolare con un aggiornamento di questa portata.

Se il vostro provider di hosting auto-aggiorna la versione.

Se il sito fruisce in l’hosting WordPress gestito, molto probabilmente il tuo provider di hosting aggiornerà automaticamente WordPress per voi. Il tuo provider WordPress dovrebbe conservare i backup dei siti precedenti. Rivolgetevi al vostro ISP per vedere quale supporto fornisce a fronte del nuovo editor di WordPress e quando si aggiorneranno a WordPress 5.0. Alcuni provider infatti, attendono fino a gennaio del prossimo anno per eseguire l’aggiornamento.

Quali sono le implicazioni per la sicurezza con Gutenberg?

Al momento non siamo a conoscenza di problemi di sicurezza con WordPress 5.0 o Gutenberg. Il progetto viene spostato in produzione ad un ritmo talmente rapido che incrementa il rischio sulla sicurezza, poiché ciò riduce la quantità di tempo disponibile per il test e il debug.

In questa fase dell’evoluzione di WordPress, ci sono un gran numero di team di sicurezza a livello globale che hanno gli occhi puntati sul codice e stanno conducendo ricerche per determinare se ci sono vulnerabilità nelle nuove versioni di WordPress. Non appena emergerà un problema, si dovranno affrontare tutte le procedure necessarie.

Una volta rilasciato WordPress 5.0, ci sarà probabilmente una serie di piccole versioni che emergeranno nelle settimane successive. Vi consiglio di monitorare il blog ufficiale di WordPress e se verrà annunciato un aggiornamento per la sicurezza, eseguite l’upgrade il prima possibile.

Un punto di vista pratico.

Codice Riscritto

Gutenberg è basato su React, un framework JavaScript molto popolare utilizzato e gestito da aziende come Facebook e Instagram. Gutenberg si avvale di molte altre tecnologie moderne come la REST API, ESnext + JSX, WebPack, ecc.

Per come è strutturato, Gutenberg apre un mondo completamente nuovo per gli sviluppatori, in termini di “sviluppo dei blocchi”. Ricordate, tutto in Gutenberg riguarda i blocchi. Quindi probabilmente sentirete molto spesso questo termine.

Ma questo può anche complicare le cose, dato che in questi casi gli sviluppatori dovrebbero imparare nuovi linguaggi. Tuttavia, per fortuna, la community di WordPress è venuta subito in soccorso e ci sono già ottimi progetti open source come create-guten-block. Si tratta essenzialmente di un dev-toolkit a configurazione zero (#0CJS) che consente sviluppare blocchi di Gutenberg in pochi minuti, senza configurare React, webpack, ES6/7/8/Next, ESLint, Babel, ecc.

L’altro aspetto negativo di tutto questo è che la maggior parte (non tutti) dei temi e dei plugin di WordPress devono essere riscritti per funzionare con Gutenberg. Principalmente quelli che interagiscono con l’editor di WordPress. Yoast SEO è un ottimo esempio di uno sviluppatore di plugin di WordPress sia salito a bordo molto in fretta! Hanno rilasciato il loro primo aggiornamento per Gutenberg a luglio 2017 e da allora ne hanno rilasciati ancora. Anche se all’inizio erano un po’ preoccupati per l’accessibilità di Gutenberg.

WordPress 5.0 comprende anche Twenty Nineteen, il nuovo tema minimal distribuito con supporto completo a Gutenberg, sia dal front che dal back-end.

Cosa Succede ai Contenuti Correnti?

Cosa succede ai contenuti che avete creato nell’editor classico quando vengono aperti nel nuovo editor Gutenberg? Fondamentalmente, l’intero post apparirà come una grande finestra dell’editor TinyMCE. Lo hanno fatto per preservare il formato dei contenuti di tutti i vostri post e delle vostre pagine. Per sfruttare l’editor Gutenberg, dovrete selezionare l’opzione “Converti in blocchi”. Tutto verrà automaticamente convertito nei nuovi blocchi di Gutenberg.

Cosa Succede agli Shortcode?

Lo stesso vale per gli shortcode. È stato inserito un form nell’editor classico utilizzando uno shortcode. Quindi, nell’editor di Gutenberg, selezioniamo nuovamente “Converti in blocchi”. Lo shortcode viene quindi trasformato in un blocco shortcode di Gutenberg. Il modulo di contatto viene così reso correttamente nel front-end.

Risolvere i Problemi di Aggiornamento WordPress

Come avviene con ogni nuova versione di WordPress, c’è sempre qualcuno che incontra dei problemi, e questo è dovuto alle migliaia di temi e plugin che coesistono attualmente sul mercato. Ecco alcuni modi per risolvere problemi comuni:

  1. Vi trovate di fronte allo schermo bianco della morte? Questo problema viene comunemente risolto semplicemente riavviando PHP e cancellando la cache a pagina intera del vostro sito WordPress.
  2. Vedete una schermata con la scritta “Briefly unavailable for scheduled maintenance. Check back in a minute” che non vuole andar via? Il vostro sito potrebbe essere bloccato in modalità di manutenzione.
  3. Provate a disattivare tutti i plugin per vedere se questo risolve il vostro problema. Quindi riattivateli uno per uno finché non trovate il plugin che potrebbe richiedere un aggiornamento dallo sviluppatore.
  4. Provate a passare a un tema WordPress predefinito, ad esempio Twenty Nineteen (una volta che sarà disponibile). Se questo risolve il vostro problema, potrebbe essere necessario contattare lo sviluppatore del tema.
  5. Cercate i problemi ed eseguite una diagnosi delle anomalie JavaScript nel vostro browser. Questo può essere particolarmente utile se si rompe un componente cruciale come il Visual Editor (TinyMCE).

In Conclusione

WordPress 5.0 e Gutenberg costituiscono il più grande aggiornamento di WordPress. Coinvolge tutti, a partire dal modo in cui gli utenti interagiscono con l’editor e scrivono contenuti, al modo in cui gli sviluppatori creano plugin e temi. Solo il tempo dirà quanto successo avrà il progetto Gutenberg. Ma, a parte tutto, è meglio iniziare a testare il prima possibile per evitare interruzioni del vostro sito WordPress.

Rivolgetevi sempre a personale competente in materia, e che sappia intervenire adeguatamente per risolvere i problemi che non sono di poco conto, per chi ricerca un user friendly CMS.

Per ulteriori informazioni contattateci in privato per avere una corretta analisi sulla fattibilità di aggiornamento dei vostri siti WordPress 5.0 e non.

Webmin non funziona dopo il suo aggiornamento

Chi ha l’esigenza di gestire un server Linux da remoto, può risultare una problematica per chi ha poca dimestichezza con strumenti come SSH e la riga di comando o per chi vuole sveltire uniformemente le procedure di gestione.

Con Webmin tutto diventa più semplice: creare nuovi utenti, condividere file, pianificare i backup, impostare le interfacce di rete, ma anche configurare Apache o MySQL. Il software ci fornisce un’intuitiva interfaccia web per le più consuete e affannose operazioni d’amministrazione di un sistema Unix. Basterà un moderno browser per gestire il nostro server a colpi di click.

Webmin in sintesi è costituito da un mini web server indipendente da Apache e dai servizi standard e da un certo numero di script CGI. Questi ultimi agiscono modificando i files di configurazione normalmente modificati a mano, senza alterare il loro standard editor. Webmin viene distribuito con una licenza stile BSD che ci consente non solo di modificarlo liberamente, ma anche di includerlo in applicazioni commerciali.

Ha una struttura modulare che ne permette l’espansione con software scritto da terze parti. I moduli standard, compresi nell’installazione di base, sono sufficienti per le più comuni esigenze. In caso vi troviate a dover gestire programmi un po’ particolari potete sempre consultare l’apposita sezione del sito che riporta i contributi di altri programmatori. Webmin a differenza di altre WebGUI come Plesk CPanell ecc. è freeware senza vincoli di utilizzo certificazione o licenze varie, tutt’ora risulta essere l’unica soluzione professional, per la gestione GUI utile senza intaccare lo standard editing e le prestazioni della macchina.

Dalla pagina di download possiamo scaricare il software in vari formati a seconda delle caratteristiche del nostro sistema operativo. Si va dalla generica tarball, utilizzabile da tutti, ai pacchetti .rpm o .deb per le principali distribuzioni Linux.

http://www.webmin.com/

Quando Webmin non si riavvia correttamente dopo l’aggiornamento

Ultimamente mi segnalano che Webmin dopo le regolari procedure di aggiornamento (assolutamente importanti), sembra scomparire dai browser e/o non funzionare più regolarmente.

Niente paura, è solo un bug che deficie con le ultime versioni di Ubuntu Server durante i processi di aggiornamento.

Una volta che Webmin si è aggiornato dall’apposito click sul pulsante in Dashboard l’installazione automaticamente scarica il nuovo software e lo aggiorna sovrascrivendo ai files precedenti, mantenendo il backup precedente.

Operazione fausta vuole che il processo o servizi non sia aggiornato dal sistema creando un errore come questo:

che impedisce appunto di avviare correttamente il servizio.

La soluzione è semplice!!

Accedere via SSH alla macchina da remoto (o direttamente sulla console) alla shell del sistema.
E digitare questi comandi:

$ sudo service webmin stop 
$ sudo service webmin start

E il gioco è fatto. Webmin ricomparirà magicamente sul nostro Browser.
Ora nella sezione di configurazione Webmin potete controllare e riavviare il servizio in automatico con il riavvio del sistema.

Il mio sito è sotto attacco. Ragioni, Cause e Soluzioni per siti di piccola taglia.

sito sotto attaco

Premetto che sulla base di queste domande, in questo articolo parleremo di quelle motivazioni per cui siti di irrilevante importanza nel web sono più vulnerabili rispetto ad altri, e perché necessitano di maggiore se non di eguale Livello di Sicurezza rispetto altri più rilevanti.

Un utente malintenzionato visualizza un sito Web vulnerabile principalmente per avere una risorsa ed opportunità da sfruttare e rubare a proprio vantaggio:

  • Che sia supportato da un server in modo da favorire l’utilizzo e l’esecuzione di programmi propri
  • Che sia connesso a Internet e probabilmente mantiene una reputazione pulita
  • Potrebbe includere dati utente interessanti e ri-utilizzabili
  • Probabilmente dispone un vasto traffico e banda
  • Mantiene una ragione di imortanza per voi

Il più delle volte, usano queste risorse per fare soldi. E continueranno a trovare nuovi modi creativi per farne altri.

Utilizzo del Server Web per eseguire i propri programmi

Se state utilizzando ad esempio un sito WordPress, il Vostro server web è probabilmente un server Linux pienamente funzionante con MySQL e PHP installati. A seconda della situazione di hosting, potrebbe anche avere una quantità significativa di potenza di elaborazione.

Estrazione di criptovaluta

Mesi addietro ho rilevato nella Rete, attraverso la consultazione di appositi siti mirror, che la maggior parte degli attacchi massicci, sono rivolti maggiormente verso siti WordPress. Nei periodi più intensi di attacchi registrati, un aggressore compromette i siti sfruttando gli stessi per attaccare altri siti WordPress per guadagnare con Monero, una criptovaluta che può essere estratta in modo efficiente utilizzando l’hardware del server web.

Da tali dati si è stati in grado di identificare in che modo gli aggressori controllavano i server compromessi, accumulando un guadagno di circa 100 Mila dollari attraverso i loro sforzi di Estrazione.
Fonti provenienti da:
https://www.wordfence.com/blog/2017/12/massive-cryptomining-campaign-wordpress/
https://www.cryptocompare.com/mining/guides/how-to-mine-monero/
https://www.coin-report.net/it/estrazione-monero/

Sfruttamento della vostra reputazione on line.

Capire che la reputazione del vostro sito vi rende un bersaglio vulnerabile.

Hosting per pagine di phishing

Una pagina di phishing tenta di ingannarvi nella condivisione di informazioni riservate, come la password, il numero della carta di credito o il codice fiscale. Un esempio di pagina di phishing è una pagina di accesso fittizia che vi dà l’impressione di quello che state facendo in modo regolare, ad esempio la schermata di login di GMail. Inserendo le vostre credenziali, l’utente malintenzionato le registra per conto suo, e lo rende ora è in grado di accedere al vostro vero account GMail e di rubare i dati.

Il vostro sito ha una reputazione pulitissima. Quando gli utenti malintenzionati ospitano pagine di phishing nel vostro sito, servizi come Google Safe Browsing normalmente avvisano gli utenti di siti Web sospetti, non sapranno avvisare del pericolo rappresentato da una pagina di phishing ospitata sul vostro sito.

Hosting delle pagine di spam e iniezione di link di spam

Il vostro sito è legittimo, quindi i motori di ricerca come Google presumono che anche i vostri contenuti, inclusi i link in uscita lo siano. Gli hackers amano piazzare spam SEO sotto forma di pagine e link sul vostro sito, aumentando le classifiche SEO per le loro attività illegittime.

Un grande esempio e il Supply Chain Attack, scoperto di recente durato 4,5 anni, ha avuto un disastroso impatto su 9 plugin di WordPress. Acquistati tali plug-in venivano poi utilizzati per incorporare collegamenti di spam nei siti, per poi essere eseguiti. Il malintenzionato ha utilizzato questi collegamenti per migliorare il posizionamento nei motori di ricerca per altri siti web che offrivano prestiti, servizi di scorta e altre operazioni illegali.

È importante comprendere che, mentre il vostro sito da solo non è in grado di aumentare i risultati SEO ottenuti da un hacker, migliaia di siti compromessi possono farlo.

Invio di email spam

Inviare e-mail di spam eludendo i filtri antispam non è un’impresa facile. Oggi i clients di posta elettronica utilizzano una miriade di tecniche per identificare e bloccare lo spam. Quasi tutti i filtri antispam si basano su blacklist di indirizzi IP per bloccare tutti i messaggi provenienti da sorgenti ritenute dannose.

Ed è qui che entra in gioco il Vostro server web. Non solo ha tutto l’hardware e software necessario per inviare spam. La reputazione del vostro indirizzo IP probabilmente è rimasta illibata. Inviando spam con sorgente IP del vostro server, i criminali informatici hanno maggiori possibilità di ottenere risultati.

Alla fine i filtri antispam registreranno tutto ciò che accade e salveranno nella blacklist anche il vostro indirizzo IP del server, così l’hacker passando semplicemente ad una vittima successiva, lascerà la reputazione del vostro server e sito in rovina e di conseguenza danneggerà l’immagine della Vostra azienda.

Attaccare altri siti

A volte gli utenti malintenzionati danneggiano i siti vulnerabili per attaccare altri siti. Abbiamo visto gli hacker utilizzare questo tipo di approccio nell’attacco di Estrazione di criptovaluta di cui abbiamo parlato in precedenza, in cui un utente malintenzionato sia in grado di controllare una botnet composta da migliaia di siti, di altre persone che eseguivano contemporaneamente l’Estrazione di criptovaluta e procedevano all’attacco di altri siti web ancora.

Il Vostro Server Web diventerà così una piattaforma di attacco utile, poiché il Vostro indirizzo IP non essendo probabilmente registrato in alcuna balcklist, sarà in grado di eludere gli anti-Spyware e i sistemi di sicurezza di altri web server.

Hosting di contenuti dannosi

A volte gli hacker utilizzano il server Web per ospitare file dannosi che possono essere richiamati da altri server. Essenzialmente usano il Vostro account di hosting come un file server.

Sfruttamento del traffico del vostro sito

Reindirizzamenti dannosi

Una cosa molto comune che gli hacker fanno con i siti Web violati è l’aggiunta di reindirizzamenti nei contenuti. I visitatori del vostro sito non devono nemmeno cliccare su un collegamento ipertestuale per visitare il sito di spam: il reindirizzamento automatico li porterà direttamente lì.

In alcuni casi, chi genera questo tipo di attacco arriva al punto di reindirizzare tutto l’intero traffico verso siti dannosi. Nella maggior parte dei casi, vengono adottate misure preventive per evitare di essere rilevati, reindirizzando il traffico solo verso URL specifici, sistematicamente, o per browser, o per tipi e fonti di dispositivi specifici.

Siti Defacciati (Ghost pages)

In alcuni casi, l’hacker vuole solo inviare un messaggio pubblico. Prendendo il controllo del vostro sito web, sono in grado di raggiungere i vostri visitatori, almeno fino a quando non capirete che cosa è realmente sta succedendo. Gli attacchi di questa natura vengono orchestrati e rappresentati spesso da un movimento politico o sono solo alla ricerca di “street cred” per costruirsi una notorietà nelle comunità degli hacker.

Distribuire malware

Un modo particolarmente perfido con cui gli aggressori monetizzano i siti Web violati, consiste nell’utilizzarli per diffondere malware. Iniettano codice malevolo nei siti Web, che a loro volta installano malware sui computer o sui dispositivi dei visitatori quando raggiungono le pagine del vostro sito.

In quaità di proprietario del sito, questo status è particolarmente compromettente per la Brand Reputation, in quanto non solo rischiate che il vostro sito sia contrassegnato da motori di ricerca e in altre blacklist, ma i vostri visitatori non saranno felici della vostra condotta nella comunicazione digitale. La Vostra reputazione, sia online che con i visitatori, potrebbe essere compromessa per molto tempo. Inoltre, un sito Web compromesso può avere un impatto negativo a lungo termine sul posizionamento nei motori di ricerca.

Rubare dati

Anche se non si accettano carte di credito sul proprio sito, un utente malintenzionato potrebbe comunque trovare dati preziosi da razziare. Ad esempio, se acquisite dati tramite moduli dal vostro sito, potrebbe esserci qualcosa che valga la pena prendere. Inoltre, gli utenti malintenzionati possono utilizzare coppie di nomi utente e password rubate per tentare di accedere ad altri siti: il tipico furto di identità.

I Ransomware

Abbiamo imparato negli anni che i siti web rappresentano quasi sempre una forma di interesse per le persone, anche se non è un sito aziendale. Sfortunatamente anche i criminali informatici lo sanno e continueranno a usare i loro stratagemmi per servirsi di Agenti di Riscatto.
Per approfondire tale argomento vi rimando agli articoli redatti appositamente sull’argomento:

In Conclusione per risolvere

Indipendentemente dalle dimensioni del pubblico del vostro sito web o dal costo del vostro piano di hosting, i criminali troveranno tranquillamente un modo per monetizzarlo se non risulta opportunamente protetto.

Fortunatamente, non è necessario essere esperti di sicurezza per mantenere un sito sicuro. Con i nostri servizi di Management e Sicurezza nel web, siamo in grado di mantenere una Reputazione Stabile del vostro Brand dando valore al vostro sito, allo stesso livello di competizione con altri concorrenti più rilevanti.

Google Chrome e Symantec, i certificati cesseranno il supporto di sicurezza SSL nel browser

Questo è un annuncio di servizio pubblico ed anche un promemoria per i proprietari di siti.
Il browser Chrome di Google ha già avviato il processo di Cessazione del Supporto per i Certificati SSL SSL/TLS. Ciò include le società di proprietà di Symantec tra cui Thawte, Verisign, Equifax, GeoTrust e RapidSSL.
Chrome 66 interromperà il supporto per i certificati Symantec emessi prima del 1° giugno 2016 secondo il seguente programma:

  • La versione “Canary” ha già terminato il supporto per questi certificati. È stato rilasciato il 20 gennaio 2018.
  • La versione Beta per Chrome 66 sarà rilasciata il 15 marzo sempre di quest’anno.
  • La versione stabile per Chrome 66 sarà rilasciata il 17 aprile.

Se si sta eseguendo un certificato Symantec rilasciato prima del 1° giugno 2016 e non si sostituisce tale certificato, dal 17 aprile in poi, ai visitatori del sito si presenterà questa schermata:

Come potete vedere, l’errore è descritto come NET :: ERR_CERT_SYMANTEC_LEGACY, il che significa che il sito utilizza un certificato Symantec non più supportato o valido. Considerate che il 90% dei certificati a pagamento rilasciati in Italia sono coperti da Symantec e Verisign.

Invece a partire da Google Chrome versione 70, tutti i restanti certificati Symantec cesseranno di funzionare, compresi quelli rilasciati dopo il 1° giugno 2016. Il programma di rilascio di Chrome 70 per Canary, Beta e Stable è previsto rispettivamente per il 20 luglio, 13 settembre ed il 16 ottobre.

Per verificare se il Vostro certificato è interessato da questa modifica, potete visitare questa pagina e inserire l’host del Vostro sito web nel nel campo del modulo fornito su: https://www.websecurity.symantec.com/support/ssl-checker.

Se il Vostro sito risulta affetto dal problema, la pagina dovrebbe segnalare un avvertimento. Assicuratevi di inserire il nome host coretto e rimuovere il prefisso https:// e la barra finale.

Un modo alternativo per verificare se il sito web risulta affetto da tale problema, è quello di scaricare la versione “Canary” di Bleeding Edge e visitare il vostro sito web. Quindi controllare con il DevTools in Chrome per qualsiasi messaggio di avviso riguardante il vostro certificato SSL/TLS direttamente via browser.

Potete trovare maggiori informazioni sul blog ufficiale di Google riguardo la sicurezza.

Aiutatemi a diffondere la notizia in modo che i proprietari dei siti non vengano colti di sorpresa quando questo cambiamento verrà applicato nel prossimo mese.

Fonti

https://www.wordfence.com/blog/2018/03/..
https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html
http://punto-informatico.it/4396854/…