Sorprende ver como las aplicaciones más actuales siguen sufriendo
vulnerabilidades
clásicas. Más aún cuando estas aplicaciones son desarrolladas por
grandes corporaciones en las que el presupuesto disponible es un
problema menor y su negocio reside en su presencia en Internet y el
valor que ofrecen a sus usuarios.
Recientemente, varios miembros del equipo de Auditoría hemos
publicado vulnerabilidades que afectan a LinkedIn (1), la red social
para profesionales que en la actualidad cuenta con más de 200 millones
de usuarios. Cabe recordar que, hasta finales de 2012,
LinkedIn no
disponía de la figura de un CISO, y que dicha figura fue creada a raíz
de que varios millones de cuentas de usuario en LinkedIn fueran
comprometidas como reconocía la propia red de contactos (2). Muchos
blogs se hicieron eco de este hecho, preguntándose como era posible que
una compañía de tecnología digital online no dispusiera de un
CSO o
CISO.
En este caso, se han reportado vulnerabilidades de tipo
XSS (3) y
CSRF (4),
aunque nuestro equipo ha descubierto otras múltiples vulnerabilidades
que, a día de hoy, seguimos gestionando su corrección con LinkedIn. Los
problemas reportados son ampliamente conocidos y llevan con nosotros los
años suficientes como para comprender sus riesgos y las medidas a
adoptar para evitarlos. Aún así, se trata de problemas muy comunes en
aplicaciones web y así queda reflejado al encontrar estas
vulnerabilidades, año tras año, en el
Top 10 de OWASP (5).
La vulnerabilidad de tipo
CSRF fue corregida por
LinkedIn a las 48h de su notificación, lo que revela la predisposición y
nivel de compromiso de este equipo respecto la seguridad. La
explotación de esta vulnerabilidad, que afectaba a la funcionalidad de
envío de invitaciones, permitía incorporar contactos a nuestra red sin
el consentimiento por parte de los afectados. Aprovechando, por ejemplo,
los propios recursos que ofrece LinkedIn, un usuario malicioso podría
explotar de forma masiva esta vulnerabilidad para incorporar,
potencialmente, miles de usuarios a su red de contactos sin la
aprobación de los mismos.
Todo ello gracias a que la información para autenticar al usuario se
encontraba única y exclusivamente en la cookie de sesión que, como
todos sabemos, transmite el navegador de forma automática y transparente
para el usuario cada vez que se accede al dominio en cuestión. Por lo
tanto, resultaba trivial el hecho de forzar un petición autenticada por
parte de otros usuarios (por ejemplo, a través de un simple tag IMG cuyo
atributo SRC apunte al recurso vulnerable se genera una petición GET
que transmitirá la cookie de sesión). A pesar de que la petición de
envío de invitaciones transmitía un parámetro "
csrfToken",
precisamente para ofrecer protección contra este tipo de ataques, la
aplicación no validaba el valor de dicho token por lo que podía ser,
incluso, eliminado de la petición sin que la operativa se viera
afectada.
Por otro lado, se identificaron múltiples recursos vulnerables a
XSS en el dominio "
investors.linkedin.com". La inyección de código se podía realizar a través de la cabecera HTTP "
User-Agent"
y, dado que esta aplicación comparte la cookie de sesión con la
aplicación de contactos, podía ser explotada con el fin de obtener el ID
de sesión ("
JSESSIONID") de otros usuarios. Este hecho sumado a que el token de protección contra CSRF (recordemos, parámetro "
csrfToken")
contiene el mismo valor que el ID de sesión, permitía suplantar la
identidad de otros usuarios y realizar cualquier operativa en su nombre.
Además, con el agravante de que la sesión de los usuarios de LinkedIn
expira en 1 año y no se destruye al cerrar la sesión, con lo que alguien
que quisiera sacar provecho de esta vulnerabilidad dispondría de 1 año
para suplantar a los usuarios.
En definitiva, problemas clásicos y de trivial explotación pero de gran impacto para los usuarios.