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.