Atacar un sitio web usando sus estadísticas: Pentesting, Hacking & doxing

Cuando se está analizando la seguridad de una aplicación web en un proceso de pentesting, las fugas de información son muy útiles y pueden llegar a abrir la puerta de par en par. Desde un simple directory listing, pasando por los múltiples juicy files que te puedas encontrar - .DS_Store, thumbs.db, .svn/entries, etcétera, etcétera - hasta llegar a los paneles de monitorización o administración "ocultos" por unos robots.txt muy "verbose".

Figura 1: Atacar un sitio web usando sus estadísticas

La gestión de las estadísticas de tráfico puede convertirse también en una fuga de información jugosa que utilizar a la hora de hacer crawling de URLs ocultas, de descubrir el direccionamiento interno de la red una organización, a la hora de hacer un ataque de watering hole esperando la conexión de un determinado cliente o simplemente como fase de recogida de información útil para ataques dirigidos. Pero puede dar más juego.

1.- Estadísticas como servicio: Contenido externo, Watering Hole y Doxing

Hoy en día muchos sitios web tienden a utilizar servicios en cloud para gestionar sus estadísticas. Para ello, en cada web se hace una carga de un contenido externo en forma de fichero JavaScript que va recapitulando todos los datos de navegación. Después el dueño de la web visita un panel de control en el servicio de estadísticas y revisa el tráfico de su sitio.

Figura 2: Esquema de ataque a visitantes de RSA Conference vía servidor de estadísticas

Cuando se tiene este esquema al final, la seguridad del sitio web está delegada a un tercero, por lo que como se vio en el caso de la RSA Conference, atacar el servicio de estadísticas podría llegar a ser más sencillo que atacar la web oficial. 

No solo se pueden utilizar las estadísticas para atacar a los visitantes del sitio como en el caso de la RSA Conference, sino que podrían utilizarse los paneles de administración de estadísticas para atacar a los administradores del sitio web, por medio de ataques CSRF, Tabnabbing, XSS o ClickJacking. Por ejemplo yo me topé con que el panel público del contador de visitas que usa El lado del mal es vulnerable a ataques XSS, y además por defecto es público, así que se puede atacar a curiosos con él.

Figura 3: XSS en Bravenet

En el caso del famoso Google Analytics, muy utilizado para hacer el seguimiento de estadísticas en muchos sitios web, el identificador que se usa para recoger los datos permite saber cuántos sitios están controlados por la misma persona, lo que ayudaría a saber quién está posiblemente detrás de un blog si gestiona las estadísticas con el mismo ID.

Figura 4: IDs de Google Analytics

Esto es sencillo ya que si una misma persona quisiera tener más de un sitio web dentro del mismo panel de control de Google Analytics, el código que genera el servicio es igual, pero con un valor consecutivo tras el guión. Es decir -2, -3, -4 y subsiguientes, lo que ayudaría a hacer doxing de bloggers.

2.- Estadísticas como módulo parseador de logs

En muchos sitios aún se pueden ver las estadísticas de una web como un módulo que parsea logs. Lejos del concepto de aplicación en sí mismo, se usan programas que filtran los logs y los muestran de forma gráfica. Estos módulos de parseo de log carecen de una estructura completa de aplicación con gestión de usuarios y similares, por lo que la seguridad del acceso a ellos está restringida a la configuración que haga el administrador en el servidor web.

Figura 5: Awstats. Datos de clientes con conexiones IPv6 incluso

Clásicos que se pueden encontrar son Awstats, fácil de localizar filtrado en ficheros robots.txt, que muestra información detallada de clientes, partes de la web y datos transmitidos. De siempre, este fichero ha sido un jugoso aliado a la hora de hacer una fase de footprinting/fingerprinting en un proceso de pentesting.

Figura 6: Clientes mostrados con WebAlyzer

Por supuesto, Webalyzer es otro clásico a localizar, que también suele estar publicado en las webs bajo rutas como /stats/, /webalyzer/, /mystats/ o /sitestats/, y donde se puede sacar un poco de todo para analizar una web.

Figura 7: Datos de tráfico con WebAlyzer

Algún dato tan curioso como la web que más datos transmite en una petición GET, lo que puede ayudar a alguien que quiera planear un ataque DDOS a saber cuál es la parte de la web que hace enviar más datos desde ese servidor, por si alguien quiere enlazarlo con una amplificación.

Figura 8: Wusage aún se usa en muchas webs

El último de los que quería hablar en esta categoría es Wusage, un parseador de estadísticas muy antiguo, pero que todavía está disponible en muchas webs, y que buscando en robots.txt se encuentra abierto para todo el mundo.

3.-Estadísticas como aplicación web

La última de las partes que quería citar en este artículo, es cuando en lugar de utilizar un parseador como los citados anteriormente se utiliza una aplicación web completa. Esto quiere decir que dentro del servidor se mete un software con su base de datos, su gestión de usuarios, su código server-side, etcétera.

Figura 9: Trace Watch se publica en /twatch/. Arquitectura LAMP.

Para esta categoría hay muchas, desde módulos de frameworks de Internet hasta aplicaciones más o menos maduras. En ellas hay que tener mucho cuidado con la gestión de la seguridad, ya que hay nuevas identidades que proteger que dan acceso a un motor de bases de datos que podría ser utilizado por un atacante. Un ejemplo de esto es el exploit de Time-Based Blind SQL Injection para Solar Empire usando el campo de User-Agent en las estadísticas de los visitantes.

Figura 10: Piwik, otro ejemplo de aplicación para estadísticas

Algunos de estas implantaciones adolecen de problemas habituales como contraseñas por defecto, no protección contra ataques de fuerza bruta o software no actualizado con bugs conocidos. Mucho cuidado si haces uso de alguno de ellos.

Saludos Malignos!