Una vulnerabilidad de seguridad de PayPal de alta gravedad fue capaz de exponer las contraseñas de los usuarios a los piratas informáticos

Con más de 286 millones de cuentas activas, PayPal es, con mucho, el procesador de pagos más grande y popular del mundo. Ha logrado ese título no solo porque proporciona un servicio confiable y fácil de usar, sino también porque sus desarrolladores e ingenieros de software han implementado una serie de características de seguridad que brindan a los usuarios la tranquilidad que buscan cuando procesan pagos en línea. Irónicamente, una de estas características de seguridad tenía un error que podía dejar a los usuarios expuestos a ataques de adquisición de cuentas.

Un experto en seguridad descubre una grave vulnerabilidad de PayPal

La vulnerabilidad fue descubierta por Alex Birsan, un consultor rumano de seguridad de la información e ingeniero de software que también pasa tiempo buscando errores. Estaba hurgando en el proceso de inicio de sesión de PayPal cuando notó un archivo JavaScript que contenía un token de falsificación de solicitudes entre sitios (CSRF) y un ID de sesión. Birsan estaba intrigado.

Mencionó en su divulgación pública que dejar este tipo de datos en un archivo JS podría exponerlo a los piratas informáticos. Efectivamente, utilizando una técnica conocida como Cross-Site Script Inclusion (XSSI), creó un escenario en el que un atacante podría haber robado el token CSRF y la ID de sesión de un usuario que había sido engañado para visitar un malicioso página.

Inicialmente, Alex Birsan pensó que esta era una noticia terrible. Supuso que el token y la ID de sesión eran suficientes para hacerse pasar por un usuario. Sin embargo, después de numerosos intentos de hacerse cargo de su propia cuenta, se dio cuenta de que un ataque exitoso requeriría más trabajo. Sin embargo, siguió adelante.

La vulnerabilidad se esconde en una característica de seguridad diseñada para detener los ataques de fuerza bruta

Después de más investigación, Birsan descubrió que el token CSRF y la ID de la sesión en realidad fueron utilizados por el mecanismo CAPTCHA de PayPal. CAPTCHA, que significa prueba de Turing pública completamente automatizada para distinguir a computadoras y seres humanos, es una de las formas más simples de protección contra ataques de fuerza bruta.

A diferencia de muchos otros servicios en línea, PayPal ha decidido no incluir un desafío CAPTCHA debajo del formulario de inicio de sesión principal. En cambio, aparece en una página en blanco después de un número predeterminado de intentos fallidos de inicio de sesión. Una vez que el usuario resuelve con éxito el desafío CAPTCHA, se envía una solicitud HTTP POST a PayPal, que, además del token CSRF mencionado anteriormente y la ID de sesión, también contiene el nombre de usuario y la contraseña que el usuario ingresó durante el intento de inicio de sesión más reciente en texto sin formato. Un poco más de rascarse la cabeza después, Alex Birsan estaba listo con la prueba de concepto.

Un atacante usaría primero XSSI para extraer el token CSRF y la ID de sesión válida para el navegador del usuario. Luego, harían algunos intentos de inicio de sesión utilizando credenciales aleatorias, lo que desencadenaría el desafío CAPTCHA. Cuando el usuario inicia sesión en su cuenta utilizando el mismo navegador, las credenciales válidas sobrescribirán los nombres de usuario y las contraseñas al azar. Entonces, todo lo que necesitaría un atacante es otro token CAPTCHA (que se puede recuperar con relativa facilidad utilizando un servicio de resolución CAPTCHA) para revelar los datos de inicio de sesión del objetivo en texto sin formato.

PayPal se mueve rápidamente para parchear la vulnerabilidad

Como puede ver, encontrar una manera de explotar el insecto no fue una caminata en el parque. Sin embargo, el ataque de prueba de concepto mostró que si se deja desatendido, la vulnerabilidad podría causar graves pérdidas financieras a algunas personas, por eso, cuando Birsan presentó su informe a través del programa de recompensas de errores de PayPal en la plataforma HackerOne, le dio un alto Puntuación CVSS.

El primer informe se envió el 18 de noviembre y, después de 18 días, HackerOne finalmente validó los hallazgos de Birsan. PayPal reconoció el problema y acordó que es bastante grave. El 10 de diciembre, Birsan recibió una recompensa de poco más de $ 15,300 (la suma recompensada solo por errores de alta gravedad), y solo 24 horas después, la vulnerabilidad ya se había reparado. Birsan describió la velocidad con la que PayPal resolvió el problema como "impresionante", un elogio que rara vez se da hoy en día.