Apuntes sobre el Referer spoofing, el Referer spam y otros problemas de seguridad relacionados

Los problemas de seguridad relacionados con el mal uso de campo de encabezado de petición HTTP/1.1 Referer son muy diversos. Algunos son de tipo “molestos” y otros son francamente dañidos,  algunas son vulnerabilidades resultantes de malas prácticas de programación y otras son abiertamente intencionadas. En esta entrada abordaremos estos temas.

Esta entrada fue escrita mano a mano con mis estimados colegas y excelentes ingenieros de la Dirección de Seguridad Informática de la UCI, Yailin Sánchez Borrell y Dennis Barrera Pérez, los cuales tienen amplia experiencia al respecto. Si no conoces que es el Referer te invito a leer el artículo anterior que funciona como una primera parte de este.

Problema 0. Referer spoofing

El problema primario consiste en que el user-agent es el único que puede enviar el Referer y como todos sabemos, cualquier cosa que provenga del user-agent puede ser modificada. Los debates alrededor del uso del Referer como medio de seguimiento de los cibernautas han hecho posible que los user-agent tengan sencillos mecanismos para enmascarar (spoof) el Referer. Realicemos un pequeño experimento con la VM del proyecto BWA de OWASP:

Simulemos que desde la famosa estación espacial Mir, destruida de forma controlada en el 2001, están visitando una aplicación web de la BWA, por ejemplo Mutillidae. Primero, veamos cómo se registran las peticiones HTTP en el log de Apache2 en /var/log/apache2/access.log.

1

Figura 1. Logs registrados por Apache2 donde se aprecian el contenido del Referer correspondientes por cada petición HTTP.

Por cada traza está señalado el Referer, vemos como las peticiones HTTP se están realizando entre funcionalidades de la aplicación web Mutillidae.

Ahora vamos a hacer un poco de  Referer spoofing y vamos a crear un dominio imaginario para que nadie se sienta aludido, por ejemplo mir-station.kosmos.cccp. Simulemos entonces que en este dominio hay una aplicación web que enlaza a nuestra discreta Mutillidae. Para ello tenemos muchas opciones, vamos a utilizar en este caso el programa cURL (figura 2):

2

Figura 2. Utilización de un Referer falso (mir-station.kosmos.cccp) en una petición HTTP a la aplicación web Mutillidae a través de cURL.

Podemos ver como se pudo establecer un Referer falso para que cURL añadiera a la petición HTTP del recurso /mutillidae/index.php?page=user-info.php y esto lo confirma la figura 3, donde se muestra como el servidor Apache2 lo registra sin problema alguno:

3

Figura 3. El Referer falso es registrado por el servidor Apache2.

Este simple experimento demostró lo fácil que es enmascarar el Referer y es la base para comprender los demás problemas que se presentarán en esta entrada.

Problema 1. Referer spam.

El posicionamiento SEO (Search Engine Optimization) tiene como objetivo situar una aplicación web en los primeros puestos de los resultados que muestran los buscadores de Internet como Google, Yahoo, Bing, Altavista, entre otros. Por lógica, las aplicaciones web que aparezcan en los primeros puestos, tienen más posibilidades que sean visitadas que las últimas. Yo por ejemplo, casi nunca visito la tercera página de resultados que devuelve Google.

Los buscadores tienen complejos algoritmos para hacer estos rankings pero la inferencia de su funcionamiento puede dar pistas de cómo mejorar la posición de un sitio web. No quiero profundizar en este tema pues hay muchos libros, portales y cursos dedicados al posicionamiento SEO, sobre cómo implementarlo correctamente y también cómo algunos tuercen estas técnicas para realizar prácticas desleales o francos ataques a organizaciones. Solo mencionar que la vinculación, mediante referencias entre aplicaciones web, es un componente fundamental para que los algoritmos de los buscadores decidan quién debe ir primero y quien después.

El Referer spam, por tanto, dentro de todo el universo de técnicas SEO, es una práctica agresiva que se utiliza para intentar mejorar el posicionamiento SEO de una aplicación web o para atacar el posicionamiento SEO  alcanzado por una aplicación web. Analicemos entonces, paso a paso, como se puede manifestar cada una de estas amenazas:

1.1   Referer spam básico para mejorar el posicionamiento SEO

Existen aplicaciones web y servicios vinculados que se encargan de facilitar a los internautas información sobre los vínculos que reciben de otras aplicaciones en Internet. Esto se hace con propósitos de reconocimiento, publicidad y también para mejorar el posicionamiento SEO. Para extraer esta información se parsean los registros de acceso (logs) a la aplicación web conteniendo los Referer correspondiente, como vimos en la figura 1.

“Oscuras” y “grises” empresas “consultoras de posicionamiento SEO” conocen esto y aprovechan la técnica de Referer spoofing para bombardear a las aplicaciones web con falsos Referer con la esperanza de que los webmaster y otros responsables, visiten estos enlaces para comprobarlas. También esperan que la aplicación web tenga una funcionalidad para mostrar cuales son los dominios desde el cual es referenciado. Al fin y al cabo, los bot spider indexadores no necesariamente tiene que contar con un motor semántico para hacer su trabajo y recordemos que no existe la “mala publicidad”, un ejemplo evidente de esto lo encontramos en la aplicación web http://www.fedak.net/ donde se alertan los dominios (no necesariamente generadores de spam) desde los cuales estaban tratando de indexar el archivo robots.txt. Parece que con el tiempo se percataron que esto servía a los intereses de los generadores de Referer spam y dejaron de publicar los dominios correspondientes. Aquí les dejo otro mal ejemplo: http://www.royalsomlo.com/.

Muchos de los bot que se utilizan para el envío de SPAM usan los siguientes User-Agent:

  • Opera/9.01 (Windows NT 5.1; U; en)
  • Opera/8.00 (Windows NT 5.1; U; en)
  • Opera/7.11 (Windows NT 5.1; U) [en]
  • Mozilla/6.0 (compatible; MSIE 7.0a1; Windows NT 5.2; SV1)
  • Mozilla/4.79 [en] (Windows NT 5.0; U)
  • Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Media Center PC
  • Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Netscape/8.0.4
  • Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MyIE2; Deepnet Explorer)
  • Mozilla/4.0 (compatible; MSIE 6.0; Update a; AOL 6.0; Windows 98)
  • Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 6.01 [en]
  • Mozilla/4.0 (compatible; Powermarks/3.5; Windows 95/98/2000/NT)

Muchos de estos User-Agent además están mal formados y referencian a plataformas inexistentes como por ejemplo ¿IBM EVV/3.0/EAK01AG9/LE?, ¿MSIE6.00?, ¿Windows 2007?:

  • Opera/7.60 (Windows NT 5.2; U) [en] (IBM EVV/3.0/EAK01AG9/LE)
  • Mozilla/6.0 (compatible; MSIE6.00; Windows 2007)

Mi teoría es que los User-Agent mal formados representan una especie de marca para la realización de tareas posteriores porque no me cabe la menor duda que los programadores de los spam bot tienen la inteligencia suficiente para darse cuenta que esos User-Agent  tienen más agujeros que un barco haciendo aguas.

Este Referer spam es el más básico y el menos efectivo, digámoslo así,  porque no está muy difundido que las aplicaciones web hagan públicas este tipo de referencias.

No obstante los webmaster muchas veces visitan estos enlaces para saber de qué trata y en este momento generan el tráfico esperado por los spammers. En ocasiones se utilizan bot propios para automatizar el proceso de comprobación de los Referer y también se genera tráfico, pero quizás no tan valioso como el que pueden producir otras técnicas, desafortunadamente, más efectivas que veremos a continuación:

1.2   Referer spam con Google Analytic para mejorar el posicionamiento SEO

Google Analytic es un servicio que brinda diversas estadísticas sobre el acceso a las aplicaciones web en Internet y es ampliamente utilizado por los webmaster para comprobar el uso de la aplicación web y tomar medidas para incrementar su posicionamiento.

Hay varios conceptos técnicos vinculados que no me detendré en explicar acá, lo importante es saber que Google te asigna un código universal de seguimiento de Universal Analytic (UA) y un script que debes colocar en cada página que quieras supervisar. A través del código de seguimiento de UA, se envía una notificación a Google cada vez que es accedido el recurso supervisado.

En la figura 4 se muestra el código de seguimiento que solicité para el blog, es una pena que no haya podido aplicarlo porque el plan gratuito de WordPress.com no permite que se modifiquen los headers de las páginas del blog y mucho menos instalar algún plugin que lo haga por ti. Pero vemos que es muy fácil en un dominio donde se tenga más control hacer esto:

4

Figura 4. Instrucciones para aplicar el código de seguimiento de Universal Analytic.

El código de seguimiento de UA no es para nada secreto y cualquier bot indexador puede obtenerlo o simplemente los spammers se ahorran todo ese trabajo y prueban con diferentes combinaciones de códigos UA.

El objetivo es el mismo, poblar las estadísticas de tráfico de tu aplicación web con referencias falsas realizadas por bot, afectando tu análisis de la situación real de la aplicación web. En este caso las trazas o log son gestionadas por Google y deben ser analizadas para evitar que tu aplicación web se asocie a otras de reprobable reputación.

Imagina un webmaster o una empresa consultora que presente un informe trimestral del tráfico generado por un sitio web que promociona una línea de ropas de bebé a los inversores y cuando estos visiten las páginas web donde “supuestamente” los están referenciando, se encuentren con un sitio de venta de Viagras al por mayor, pasando por otro de alquiler de películas “hot” y terminando en un sitio donde te invitan a unirte a grupos que andan con la cabeza tapada y que ni siquiera quiero mencionar aquí. ¿Qué pensarían los inversores? Cómo mínimo que el informe no sirve y el que lo generó es un incompetente total. No obstante recuerda, durante este proceso se generaron clic y es lo que persiguen los spammers con todo esto.

Quizás la peor manifestación de este fenómeno es el conocido por el término de Ghost Referral Spam o spam a través de referencias fantasmas. En este caso, los bot ni siquiera tienen que visitar tu aplicación web para generar la traza en Google Analytic. Con tu código de seguimiento de UA en la mano, utilizan el Google Analytics Measurement Protocol para enviar los datos directamente y por mucho que busques en tu servidor web, jamás encontrarás una traza de su visita pues nunca ocurrieron.

No existen muchas variantes para frenar los Referer spam, quizás una de las más efectivas es la especificación, en los archivos .htaccess, web.config o nginx.conf, que se bloqueen los dominios conocidos por generar Referer spam. Listas como  las de Perishablepress.com y Piwik se actualizan periódicamente y pueden servir muy bien para estos propósitos.

En el caso de los de Ghost Referral, la única solución es configurar filtros efectivos en Google Analytic para que descarten estas referencias en los reportes visualizados.

1.3   Referer spam para atacar el posicionamiento SEO  alcanzado por una aplicación web.

El posicionamiento SEO está dirigido a humanos (SEO orgánico o natural), por ese motivo, la utilización de técnicas fraudulentas y basadas en bot para mejorar este posicionamiento es rechazados por todos y los buscadores penalizan estas acciones, colocando en listas negras a los dominios y aplicaciones web que se dediquen a estas prácticas.

Como parte de ilegales prácticas comerciales y otros propósitos, ciberatacantes se hacen pasar por aplicaciones web legítimas para invadir de Referer spam los servidores y servicios como Google Analytic con el objetivo de que estas aplicaciones web sean reportadas y bloqueadas del ranking de los buscadores. Un ejemplo de esto son los ataques realizados contra el portal Noblego.de, un sitio alemán de comercio electrónico especializado en la venta de puros. Siempre hay métodos para recuperarse de estos ataques pero las pérdidas de venta y oportunidades no se recuperan nunca.

Problema 3. Malas prácticas de programación

Las malas prácticas de programación se aplican cotidianamente y muchas veces son causadas por carencias de conocimientos sobre programación segura. Cosas tan básicas como dominar las configuraciones de seguridad que soportan las cookies o conocer que el método POST es totalmente inseguro si no es utilizado sobre HTTPS son poco divulgadas. En esta lista no podía quedar fuera el Referer y aquí están algunos de los problemas asociados:

Aplicaciones web que pasan los ID de sesión como parámetros de la URL: Esto aunque no se crea, es más común de lo que pudiera pensarse y en estos casos, el ID de sesión y otros datos viajan como parte del Referer a otro servidor. Un ejemplo muy sencillo puede ser una aplicación web para gestionar correos electrónicos. Cuando el usuario visita el enlace contenido en un correo, como este enlace se abrió con la aplicación web  de correo electrónico, todos los datos que aparecen en la URL se transmiten en el Referer en texto plano por supuesto y queda registrado entonces en las trazas de la aplicación web visitada. En el blog de Samuel Parra se reportó un ejemplo real de este problema de una empresa bien conocida.

Inyección de código dañino para la realización de ataques XSS (entre otros): Supongamos que estamos en presencia de una aplicación web que publica los Referer. Puede ser una aplicación tan básica como la utilizada por un administrador de red para ver los registros(logs) del servidor web. Como el Referer apenas se gestiona por los desarrolladores, un atacante puede realizar una inyección de código con la esperanza de que el Referer sea publicado y por tanto el script ejecutado. En este enlace pueden ver un ejemplo de esto.

Utilización del Referer para controles de seguridad: El Referer nunca se implementó para garantizar la seguridad de las aplicaciones web, sin embargo, muchos desarrolladores quieren usarlo para este propósito. Por ejemplo, proveer determinadas funcionalidades si la petición es enlazada desde cierta página o dominio o evitar ataques de clickjacking. No creo que deba explicar las razones por lo que esta es una pésima idea si desde el comienzo se demostró lo fácil que es hacer un Referer spoofing.

Conclusiones

En la entrada se abarcaron una serie de problemas de seguridad asociados al Referer. Es importante siempre tener en cuenta que el Referer forma parte de los campos de encabezado HTTP (entiéndase datos y puntos de entrada) enviados y que por tanto hay que gestionarlo correctamente porque sino podemos ser víctima de diversos ataques.

Es muy complicado en una entrada abordar en detalle todas las implicaciones de seguridad del Referer pero si has conocido algo nuevo o has decidido replantearte algunas cuestiones que dabas por sentado con respecto a la seguridad de las aplicaciones web, pues entonces esta entrada cumplió su objetivo.

Como siempre, espero que te haga gustado el artículo. Esta es la segunda colaboración con Dennis y la primera con Yailin y se auguran otros trabajos similares. Tengo la suerte de trabajar con personas muy talentosas y dedicadas que están haciendo investigaciones muy interesantes y que poco a poco irán apareciendo en este espacio.

S4lud0s y h4st4 el próx1m0 p0st!!!

Anuncios

3 comentarios en “Apuntes sobre el Referer spoofing, el Referer spam y otros problemas de seguridad relacionados

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s