Sitios web comprometidos por inyección de código javascript.

En días recientes un administrador de sistemas nos reportó que su sitio había sido bloqueado debido a que el navegador detectaba el sitio como atacante aún cuando éste es legitimo. Por tanto el Equipo de Respuesta a Incidentes del UNAM-CERT procedió a realizar un análisis del mismo.

Además diversas soluciones antivirus identificaban que el sitio alojaba un virus o programa no deseado.

Por tanto se procedió a descargar el sitio en cuestión para revisar los archivos HTML y poder hallar una posible referencia hacia la supuesta descarga de algún archivo malicioso o la redirección a un sitio externo.

Nos encontramos así con el código que se encuentra en la imagen de abajo, el cual resultó ser sospechoso debido a que presentaba las características de utilizar un proceso para ofuscarse a sí mismo.

En la imagen anterior se marcan en color verde las etiquetas entre las que se encuentra el código javascript inyectado. Asimismo se puede apreciar en rojo el conjunto de caracteres en hexadecimal que contiene el código ofuscado a ejecutarse una vez que el usuario accede al sitio.

Además los creadores de éste código cambiaron el nombre de algunas funciones para dificultar el análisis del mismo. Sin embargo, al tratarse de código javascript podemos insertar la función document.write() con la finalidad de imprimir el código en el navegador, para ello se sustituyo la función eval() la cual había sido sustituida por la variable “e”. La sección de código a sustituir viene dada por “e (zas)” la cual se puede observar antes de la etiqueta </script>.

Después de haber realizado lo anterior se logró obtener la impresión del código en pantalla, a continuación se muestra los resultados obtenidos.

Haciendo uso del sitio jsbeautifier se logró realizar el desofuscamiento del código quedando de la siguiente manera.

Se puede observar la declaración de varias funciones que llevan por nombre zzzfff(), SetCookie() y GetCookie().

 La función zzzfff() inyecta un iframe en la página web, el cual lleva consigo un enlace hacía un sitio externo el cual queda identificado por la declaración de la variable csp.src en la línea número 2; las líneas restantes definen el tamaño del mismo.

La función SetCookie() permite crear una cookie la cual se almacenará en el equipo del usuario, esta función recibe como parámetros el nombre de la cookie (cookieName), su valor (cookieValue), el número de días hasta que esta expire (nDays) y la ruta dentro del sitio en la cual se encontrará activa (path).

Finalmente la función GetCookie() permite realizar una búsqueda dentro del conjunto de cookies almacenadas con la finalidad de determinar si la cookie ya se ha establecido en el equipo del usuario.

A partir de la línea 36 se observa el siguiente bloque de código.

En principio el código busca validar que el navegador que utiliza el usuario soporta la persistencia de cookies, si éste es el caso se procede a hacer uso de la función GetCookie() con la finalidad de buscar que la cookie que lleva por nombre “visited_uq” tenga el valor 55, en caso de resultar verdadero entonces se termina la ejecución del código dado, con ello se verifica que el usuario ya ha visitado algún sitio externo o página maliciosa que ha establecido éste valor. En caso de resultar falso entonces se hace uso de la función SetCookie con la finalidad de crear la cookie con los siguientes parámetros: nombre=”visited_uq”, valor=55, duración= 1 (día) y con ruta=”/” éste último parámetro lo que indica es que la cookie será válida para todo el dominio del sitio infectado y no solo para una página del mismo.

Después de haber determinado la naturaleza del código, se procedió a buscar en el dominio completo para determinar si el código había sido inyectado en alguna página diferente a index.html. En el análisis  se halló que los intrusos colocaron el código malicioso en todos los archivos HTML con ello aseguran que cualquier usuario que no visite directamente el sitio a través de la página principal también se vea afectado por la ejecución del código. A continuación los resultados obtenidos.

Cuando un usuario visita un sitio de esta naturaleza no se ve afectado por la explotación de alguna vulnerabilidad en el navegador o la descarga de algún software malicioso. Lo interesante es que los sitios vulnerados sirven como intermediarios para redirigir a los usuarios a sitios donde finalmente se descargue algún tipo de software malicioso o sitios que contengan publicidad para la venta y compra de diferentes artículos.

Debido a que el usuario es redirigido hacía un sitio que fue programado en PHP no es posible conocer el tipo de validaciones que éste realiza pero en general se identificaron dos casos: el primero tiene que ver cuando se accede al sitio directamente sin haber sido redirigido previamente por un sitio vulnerado, en éste caso se logró determinar que el sitio intenta evadir el análisis del mismo no redirigiendo al usuario a la descarga de malware(o publicidad) realizando para ello una redirección hacia el localhost del usuario.

A continuación se muestra parte de la captura de tráfico que se obtuvo cuando se visitó el sitio malicioso directamente.

En la imagen anterior se muestra en rojo la redirección hacia el dominio local del usuario, un patrón muy poco común.

Por otra parte si el sitio confirma que el usuario posee la cookie “visited_uq” con su respectivo valor, entonces se realiza la redirección hacia una página que igualmente puede estar infectada y redirigir al usuario a otro sitio. En la siguiente imagen se observa una de las paginas a las que nos redirigió el sitio http://thry0XXX.jp/clicker.php.

Si por ejemplo se requiere comprobar la presencia de esta cookie, se puede hacer uso del manejador de cookies por parte del navegador web. En la imagen que se muestra abajo es posible apreciar la presencia de esta cookie la cual se estableció a través de la visita a un sitio infectado.

Posteriormente se procedió a realizar un análisis del dominio a través del sitio Sucury SiteCheck, en los resultados que se muestran a continuación vemos que el sitio ha sido añadido a listas negras.

Sin embargo debido a que no se encuentra ningún archivo malicioso dentro del mismo las firmas antivirus lo clasifican como limpio

Mediante la ayuda del sitio web ipdb.at se logró determinar que el servidor malicioso se encuentra en Japón.  

El uso de éste tipo de técnicas para comprometer a los usuarios ha ido en aumento, si se realiza una búsqueda con el patrón de código inyectado se obtienen números realmente significativos, tan solo el buscador Google regresó 34,900 resultados.

En gran parte de estos casos la inyección del código no se llevo adecuadamente por lo que éste se termina mostrando en la página web.

Si nuestros equipos han sido comprometidos es necesario no solo eliminar el código inyectado en los archivos web dado que en muchos casos se puede dar el caso de que la configuración del servidor haya sido alterada.

En el siguiente enlace se puede consultar una excelente guía sobre como identificar y mantener seguros nuestros servidores ante éste tipo de amenaza.

http://evuln.com/hacked/redirect.html

Es importante que constantemente se estén verificando los logs del servidor para así detectar cualquier anomalía.