Etiqueta: Vulnerabilidad

WordPress 3.2.1, objetivo de un ataque de malware

Un grupo de hackers están comprometiendo blogs basados en WordPress 3.2.1 con la intención de infectar a sus visitantes con el rootkit TDSS. Varias empresas de seguridad, como Websense o M86 Labs, han sido quienes han dado la voz de alerta.

Por el momento no está claro cómo se ven comprometidas las páginas web, pero ya se han publicado exploits para vulnerabilidades que afectan a WordPress 3.2.1, una vieja versión de la plataforma de publicación web.

Una vez que se consigue acceso no autorizado al blog, los atacantes inyectan código JavaScript malicioso en sus páginas para poder cargar un exploit Java de un servidor. La vulnerabilidad Java explotada en el ataque es conocida como CVE-2011-3544 y permite la ejecución remota de código arbitrario. En este caso permite la instalación de una versión del rootkit TDSS en el ordenador de un usuario que visite ese blog.

El rootkit TDSS es uno de los más escurridizos, según las empresas de seguridad, que explican que su objetivo es conseguir el control total de los ordenadores infectados para utilizarlos como zombies de sus botnets.

Por el momento parece que las personas que hay detrás de este ataque están atrayendo con engaños a las víctimas enviando una campaña de correos electrónicos con enlaces maliciosos. El hecho de que estos enlaces lleven a páginas web legítimas permite que se superen sin dificultad los filtros de reputación.

Fuente: itEspresso.es

Enhanced by Zemanta

Programa para cambiar tamaño de imagen compromete un millón de sitios web

Vulnerabilidad en WordPress

Timthumb aún pueden ser atacado, ya que se encuentra en algunos temas de WordPress.

Existe una seria vulnerabilidad de inyección de código que afecta al script timthumb, que permite cambiar el tamaño de imágenes y es utilizado en muchos temas y plugins de WordPress, y ha sido explotado en los últimos meses para comprometer más de 1 millón de páginas Web.

Estimar el impacto no es una tarea fácil, según el sitio web de monitorización de integridad de proveedores de seguridad Sucuri, que supervisó las consecuencias de esta falla desde que se anunció por primera vez a principios de agosto.

Los investigadores de la compañía han ideado un método que consiste en utilizar Google para buscar páginas comprometidas, donde el código malicioso no funciona correctamente.

“Si usted está familiarizado con PHP / WordPress, se dará cuenta de que [el ataque] se suma a la salida de esta función (counter_wordpress, que llama a 91.196.216.30/bt.php) en el encabezado del sitio de peligro”, dijo David Dede, de Securi Security.

“Todo está bien, pero ¿qué pasa cuando el sitio 91.196.216.30 cae Si el sitio tiene “display_errors” habilitado en PHP, mostrará “Warning: file_get_contents (http://91.196.216.30/bt.php?ip = IP y =..'”, explicó.

La búsqueda de este error en Google devuelve más de 1 millón de resultados y el uso de filtros en los últimos 30 días, regresó más de 200.000.

Hay otros factores a considerar así como cuando se trata de estimar el impacto, como el hecho de que los resultados de Google corresponden a páginas comprometidas, no a sitios web. Un sitio web puede tener varias páginas infectadas. Además, no todos los servidores tienen la función “display_errors“ activada en PHP, lo que significa que no hay error dar salida incluso si un sitio se ve afectado.

También vale la pena tener en cuenta que el método de Sucuri se utiliza para estimar el impacto de un ataque en particular. No se sabe cuántos sitios web comprometidos por esta vulnerabilidad están ahí fuera. Dede cree que podría haber un par de millones.

Los Webmasters deben inmediatamente reemplazar el archivo timthumb.php ligado con los temas de su blog o plugins, con la última versión que ya no es vulnerable. Sin embargo, no es suficiente para reparar sólo los componentes activos en la actualidad, ya que dejar viejas versiones timthumb en cualquier lugar en el servidor supone una amenaza similar.

“[Miles] de los sitios fueron atacados porque había temas sin usar (o plugins), que incluyen una versión vulnerable de la escritura. Sí, en muchos casos el script no estaba permitido, incluso, pero estaba allí inactivo en el servidor”, dijo Dede.

Su recomendación es eliminar los scripts viejos o cuentas de prueba que ya no son necesarias, ya que una nueva vulnerabilidad que los afecte se puede presentar en cualquier momento, y esto no se aplica sólo a los blogs de WordPress.

Por ejemplo, muchos webmasters instalan una versión actual de phpMyAdmin, una popular herramienta web de gestión de bases de datos, con el fin de realizar una tarea de una sola vez y luego la dejan en el servidor pensando que está protegida por la contraseña.

Meses más tarde, alguien puede descubrir una vulnerabilidad en la versión y la explotan para inyectar código malicioso en las bases de datos subyacente. Esto no es un ataque teórico. Compromisos como este ocurren todo el tiempo y los atacantes utilizan herramientas automatizadas para la búsqueda de instalaciones vulnerables o sitios web de rastreo de directorios por defecto donde estas herramientas se encuentran normalmente.

“Se debe eliminar todo el software que no sea necesarios en el servidor. Incluso el no-usado, ya que con el tiempo, el riesgo de ser explotado está creciendo”, concluye Dede.

Fuente: IDG News Service

Enhanced by Zemanta