A finales de la semana pasada hubo un gran revuelo porque se publicó una vulnerabilidad que podría estar presente hace más de 8 años y que afecta a aquellos servidores que ejecutan PHP como interfaz de entrada común o CGI. Particularmente, esta vulnerabilidad (CVE-2012-1823) admite la inyección de argumentos debido a que los mismos no son debidamente controlados y permiten acceder a información que no debería ser visible, como por ejemplo, el código fuente de una página PHP, o incluso la ejecución de comandos de forma remota.

¿Qué es CGI o interfaz de entrada común?

Para comprender en qué consiste la vulnerabilidad es importante entender la tecnología CGI. Particularmente, esta tecnología es muy utilizada por los servidores web y permite a un cliente (por ejemplo, un navegador web) solicitar datos e información a dichos servidores que son obtenidos mediante la ejecución de un programa en el mismo. En otras palabras, permite extender las capacidades de HTTP, agregando funcionalidad al servidor web.

Generalmente esta tecnología es utilizada en conjunto con el famoso servidor Apache. A su vez, muchos de los servidores que hoy existen en la red, están configurados para soportar PHP. Es por esto que es importante aclarar algunos detalles que conciernen a estas tecnologías.

A grandes rasgos, Apache cuenta con módulos para el soporte de PHP nativo. Estos módulos están compilados como parte del propio binario de Apache por lo que para atender los requerimientos se utilizan procesos hijos e hilos. Esta configuración es ampliamente utilizada ya que brinda un buen rendimiento a la hora de atender múltiples peticiones.

CGI trabaja de forma un poco diferente. Cada petición que recibe el servidor crea un nuevo proceso para atender la misma, y en el caso de PHP crea un proceso del intérprete PHP por cada petición.

A partir de todo esto, hay que destacar que la vulnerabilidad afecta al segundo método que se explicó anteriormente, es decir, cuando se utiliza PHP mediante CGI. Un detalle que hay que tener en cuenta es que FastCGI (variación de CGI con algunas mejoras) no es vulnerable a este tipo de inyección de parámetros.

A continuación se pueden visualizar las dos configuraciones de las API del servidor que se explicaron anteriormente.

¿Qué versiones son vulnerables y en dónde radica la vulnerabilidad?

Hasta el momento, las versiones conocidas que son vulnerables son:

Versiones de PHP anteriores a 5.3.12
Versiones de PHP anteriores a 5.4.2

Uno de los puntos que llama la atención es que esta vulnerabilidad pudo haber sido explotada durante los últimos ocho años, y su criticidad es realmente alta ya que permite incluso la ejecución de código.

La vulnerabilidad reside en la falta de controles en el pasaje de parámetros. Existen diferentes parámetros para la ejecución de CGI tal como se ve en la siguiente imagen:

Puntualmente el parámetro “-s” permite ver el código fuente de aquella aplicación que se esté ejecutando mediante CGI. Esto puede revelar información muy sensible si alguien, por ejemplo, inserta mediante un navegador este parámetro en el contexto de un archivo PHP. En otras palabras, permitirá ver el código fuente de cualquier archivo que se ejecute mediante la interfaz CGI. Si esto se lo proyecta en archivos de configuración, se puede acceder a información muy sensible, como por ejemplo, contraseñas de bases de datos, entre otros.

En la siguiente imagen, se puede observar cómo es posible visualizar el archivo de configuración de Wordpress "wp-config.php" si este es ejecutado mediante la interfaz CGI haciendo uso de la inyección de parámetros. Este archivo contiene los datos referentes a la conexión de la base de datos del propio Wordpress. Cabe destacar que esta no es una vulnerabilidad de Wordpress, sino que a través de CGI pueden verse los códigos fuentes de los distintos archivos de la plataforma de blogging.

En la segunda entrega de este post se trata más profundamente cuál es el impacto que puede generar esta vulnerabilidad y de qué forma es posible mitigarla para no estar expuestos. Siempre es importante tener en cuenta que se debe gestionar la seguridad ya que es la única forma de estar debidamente preparados para este tipo de problemas.

Fernando Catoira
Analista de Seguridad