Solución a grave vulnerabilidad en PHP-CGI – Parte II

Continuando con la primera parte de este post, donde se explicó detalladamente en qué consistía la vulnerabilidad cuando se utilizaba tecnologías CGI, se explicará el alcance crítico que tiene esta grave falla y cómo a partir de ciertas funcionalidades que el propio módulo CGI brinda se puede lograr comrprometer un servidor. Finalmente se explicará cómo se debe mitigar esta vulnerabilidad.

Muchas veces surge la pregunta de cómo es posible que se comprometan ciertos sitios de prestigio incluso alojando malware en el propio servidor con el fin de poder diseminarlo aprovechando la reputación y el alcance del sitio infectado. Si bien no es posible decir que  solo a través de esta vulnerabilidad, si es posible pensar que es viable debido a que, como se mencionó anteriormente, está vigente hace más de ocho años.

¿Cómo es posible la ejecución de código remoto?

Nuevamente, esto recae sobre la inyección de parámetros aprovechando las funcionalidades de CGI. Existe otro tipo de parámetro, específicamente “-d”, el cual permite la habilitación de ciertas opciones de PHP especificándolas directamente en el comando. Además utilizando esto junto con el parámetro “-n” se puede indicar que se ignore el archivo de configuración “php.ini”. De esta forma, es posible de alguna manera establecer las opciones según se requiera a través de parámetros.

Alguna de las opciones más llamativas para el contexto de esta vulnerabilidad son:

  • Allow_url_include: Permite el uso de fopen con algunas funciones como include, include_once,require, require_once.
  • Auto_prepend_file: Permite especificar un archivo que será interpretado antes del fichero principal.

A través de estos parámetros sería posible realizar lo que se conoce como RFI (remote file inclusion), es decir, ejecutar código desde un sitio remoto en el propio servidor. En la siguiente imagen se puede observar cómo a través de RFI se puede ejecutar el comando “phpinfo()”, el cual permite ver toda la información detallada sobre el PHP instalado en el servidor.

Código de phpinfo

RFI de phpinfo

Entonces, de esta forma, es posible la ejecución de comandos de forma remota, ya que en este caso es posible ejecutar phpinfo(), por lo tanto será posible ejecutar cualquier código que soporte ejecución mediante CGI. Los resultados de estos comandos pueden comprometer seriamente la seguridad e integridad del servidor. Por ejemplo, si se desarrolla un script en PHP que permita ver las contraseñas del servidor y se lo ejecuta remotamente se puede tener una idea del daño que realizaría esta acción. A continuación, vemos unas capturas al respecto:

Código php para ver archivos de contraseñas

Exposición de contraseñas

Como un detalle más, ya existen exploits públicos que aprovechan esta vulnerabilidad y comprometen el sistema vulnerable. Incluso existen módulos de herramientas que permiten realizar un escaneo en la red y determinar si el mismo es vulnerable o no. Todas estas herramientas y exploits utilizan el mismo principio y ejecutan las pruebas contra el servidor para probar si este responde devolviendo el  código fuente. En caso de que la consulta sea exitosa, mediante distintos métodos combinando lo que se explicó anteriormente ejecuta comandos de forma remota.

Código de exploit

Todo esto se puede hacia el contexto del malware. Un atacante podría utilizar esta vulnerabilidad para  alojar de forma ilícita archivos maliciosos con la finalidad de infectar usuarios. Incluso podría modificar el código fuente del sitio con fines similares.

¿Cómo se soluciona?

Existen algunas alternativas para solucionar esta vulnerabilidad. Es posible realizar algunas modificaciones ya sea mediante el código fuente, es decir, descargándolo nuevamente con las modificaciones para que esto no ocurra, así como también es posible modificar uno de los módulos del servidor de Apache.

Si no es posible actualizar, es recomendable que se modifique el módulo mod rewrite de Apache. Para ello se debe agregar la siguiente regla:

RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]

De esta manera se controlan los parámetros que se insertan en las URL y como consecuencia el servidor ya no será vulnerable a este tipo de ataques.

Es más que notorio que la seguridad no puede ser tomada a la ligera. A veces una simple falla o vulnerabilidad que parece sencilla puede tener un gran impacto a nivel de la seguridad de un sistema si se lo utiliza en conjunción con otras técnicas. Es por eso que la seguridad debe ser gestionada para lograr la protección adecuada ante estos eventos y en caso de que un incidente ocurra, reponerse del mismo de la mejor forma posible.

Fernando Catoira
Analista de Seguridad

Autor , ESET

  • joaquín

    es impresionante lo q genial q son como empresa. increíble. están en todo. gracias x toda la info y las soluciones informaticas. los más grandes lejos son. eset debería ampliar su slogan a protegemos su mundo digital y educacional jaj.
    en serio son geniales. saludos!

  • Saioa

    Me gustaría saber donde exactamente debo colocar ese código. ¿Dentro de los .httaccess que tengo en mi web o es algo que tienen que añadir mi proveedor de hosting?

    Gracias :)

    • Fernando Catoira

      Buenos días!
      Ese código permite controlar el paso de parámetros. Posiblemente no tengas acceso al archivo de configuración del servidor en el caso de un servicio de hosting. En estos casos, lo recomendable es que lo añadas en el archivo .htaccess de tu propio sitio web para corregir la vulnerabilidad. Sin embargo sería de gran ayuda que informes del problema al administrador del hosting para que realice la corrección a nivel global.

Síguenos