PHP Object Injection

Question

On the website of OWASP It explains this kind of flaw that makes code injection possible. But one part was not clear to me and if anyone who understands can clarify me. The excerpt says the following:

In order to successfully exploit a PHP Object Injection Vulnerability two conditions must be met:

The application must have a class which Implements a PHP Magic method (such as __wakeup or __destruct) that can be used to carry out Malicious Attacks, or to start a "POP chain".

-

All of the classes used During the Attack must be declared when the Vulnerable unserialize() is being called, otherwise Object autoloading must be supported for such classes.

That is, when he says that the application must implement a magic method so that there is success in the exploitation of this failure. He is referring to any and all classes in my application, or only the class of the object being serialized?

Ex:

let’s say I have an object

class Usuario{
   ...
}

and an object

class Setup{
   function __construct() {
     ...
  }

  function __wakeup() {
     ...
  }
}

And I was Serializing my obj $user. An attacker could use the magic methods of the class Setup for a possible attack? or these methods should exist in the class of the object being serialized. In this case the class Usuario?

$user = new Usuario();
echo serialize($user);

Answer 1

The class must already exist, with the magic methods, that’s all it needs, in general.

Suppose you have this:

class Teste {

    public  $nome = '';

    public function __destruct(){
        echo 'Olá, ' . $this->nome;
    }

}

If you do this:

$id = unserialize($_GET['token']);

A user could do this:

pagina.php?token=O:5:"Teste":1:{s:4:"nome";s:28:"Isso%20aqui%20está%20meio%20bugadao";}

Would result in that:

Olá, Isso aqui está meio bugadao

Test it out here.

---

O:5:"Teste":1:{                       Objeto com 5 caracteres, nome de  "Teste" com 1 parâmetro 
s:4:"nome";                           String com 4 caracteres com valor "nome".
s:28:"Isso aqui está meio bugadao";}  String com 28 caracteres com valor "Isso aqui está meio bugadao".

---

The unserialize is not recommended to use in contact with the customer (do not use in POST/GET/COOKIE, anything where the customer can change it), including in the documentation itself:

Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes. Unserialization can result in code being Loaded and executed due to Object instantiation and autoloading, and a Malicious user may be Able to exploit this. Use a safe, standard data Interchange format such as JSON (via json_decode() and json_encode()) if you need to pass Serialized data to the user.

If you need to unserialize externally stored Serialized data, consider to use hash_hmac() for data validation. Make sure data is not modified by anyone, but you.

Not even the DateTime/DateTimeZone escaped with the unserialize.

If this is really the only option make sure that you are checking the integrity of the content to be "unserialized", remember that using openssl_encrypt can guarantee confidentiality, but may not guarantee integrity, making it useless! Make sure the content has not been changed, using HMAC for example.

However, as a better alternative you have the json_decode/json_encode, although there are also some problems (what I remember is that he is vulnerable to Hash-Dos) with the json_* are much less serious, but the unserialize also has been (if not yet) vulnerable there some of.

I believe you can get some information at:

• PHP unserialization vulnerabilities: What are we Missing?

• Code Reuse Attacks in PHP: Automated POP Chain Generation;

• What Do Weblogic, Websphere, Jboss, Jenkins, Opennms, and Your Application Have in Common? This Vulnerability.