¿PHP unserialize () se puede explotar sin ningún método 'interesante'?

8

Diga que había una página web de acceso público con el siguiente código PHP:

<?php
class NotInteresting
{
    public function noExploits() {
        echo "Whatever.";
    }
}
$unsafe = unserialize($_GET['data']);
$unsafe->noExploits();
?>

El código esperaría que el parámetro data URL contenga una instancia serializada de NotInteresting , pero, por supuesto, el parámetro data puede ser manipulado. Cuando se utiliza unserialize() en los datos proporcionados por el usuario, a menudo lleva a PHP Object Injection .

Sin embargo, todos los ejemplos de Inyección de Objetos PHP que he visto hasta ahora ( 1 , 2 , 3 ) ha sido peligroso por una de dos razones:

  1. Hubo algunas clases explotables con métodos peligrosos (que solo estaban destinadas a ser llamadas internamente) que se aprovecharon para ejecutar código arbitrario, a menudo el caso de un CMS.
  2. La versión de PHP era antigua u obsoleta y se explotaron las vulnerabilidades en el código PHP.

Dado que la versión de PHP es actual, es decir, no existen vulnerabilidades conocidas en la función unserialize() - y que no hay clases personalizadas definidas (solo las predeterminadas - Exception , stdClass etc.), ¿Es posible aprovechar el código anterior para un ataque exitoso en una instalación predeterminada de PHP?

Información adicional:

Por lo que sé, solo hay cuatro métodos mágicos explotables al construir una clase arbitraria a partir de una llamada unserialize() : __call() , __wakeup() , __destruct() y __toString() :

  • __wakeup () se llama cuando un objeto no está serializado.
  • Se llama a __call () cuando se invocan métodos inaccesibles (o que no existen).
  • __destruct () siempre se llama después de que no existen más referencias al objeto.
  • Se llama a __toString () cuando un objeto se trata como una cadena.

Así que escribí un script PHP para generar rápidamente una lista de las clases que contienen estos métodos "interesantes": Consulte aquí para obtener un pastebin . Algunos de estos se ven muy 'interesantes':

  • Las clases XML (podrían llevar a XXE )
  • Las clases Phar

Sin embargo, hasta el momento no puedo construir un ataque solo con estos: necesitaré a alguien más experimentado para que participe.

    
pregunta Tryth 06.01.2015 - 11:53
fuente

2 respuestas

2

La explotabilidad de la deserialización de objetos PHP depende únicamente de las clases disponibles (clases estándar y clases personalizadas), sus métodos y comportamiento, y si es posible activar uno de estos métodos explotables.

Tenga en cuenta que los métodos explotables pueden no ser tan triviales. Es posible que deba crear estructuras de objetos complejas utilizando múltiples objetos anidados para desencadenar un determinado comportamiento. El número de métodos explotables o su comportamiento también puede cambiar durante el tiempo. Así que incluso si no puedes explotarlo hoy, a veces alguien puede hacerlo.

    
respondido por el Gumbo 06.01.2015 - 13:01
fuente
1

OK, para que esto sea seguro para una configuración particular, deberías estar absolutamente seguro de que no hay clases con un comportamiento explotable. Dado que esto probablemente incluye varios módulos (acceso a DB, lo que sea), y su comportamiento podría incluir "métodos mágicos" como captadores o __wakeup() , esto es algo difícil de saber por completo.

También debes pensar en tus compañeros desarrolladores / mantenedores (incluido tu futuro). En primer lugar, es posible que no recuerden que deberían escribir cada clase con esta restricción de seguridad en mente (lo que parece fácil de olvidar). En segundo lugar, el código parece inseguro, y no tiene sentido que constantemente haya personas a su cargo para que le explique cuidadosamente cómo desinfecta todas las demás partes del sistema para hacer que esto funcione.

Un mejor plan sería serializar a / desde algo como JSON, que no solo es más seguro, sino que también hace que su API sea compatible con otros idiomas.

    
respondido por el cloudfeet 06.01.2015 - 12:25
fuente

Lea otras preguntas en las etiquetas