Hackeando eBay (Validación javascript + XSS + CSRF)

Como todos los sistemas que basan su actividad principal en el movimiento de dinero entre sus clientes, eBay es un lugar muy atractivo para un ciberdelincuente. Un XSS persistente como el que se va a detallar en este post es todo lo que se necesitaría para poder comprometer las acciones y la información de otros usuarios, y sacar provecho material con ello. A pesar de esto, eBay es ya famoso por tomarse con calma los reportes de seguridad y a su equipo le llevó unos ocho meses arreglar el problema desde su comunicación en agosto de 2013. En abril de 2014, después de solucionarse, fui finalmente añadido a su página de agradecimientos "Responsible Disclosure Acknowledgements".

El fallo de seguridad se debe a la concatenación de tres errores en serie. En mi opinión, es un buen ejemplo de cómo algunos problemas pueden no ser demasiado peligrosos ni complicados de explotar de forma aislada, pero juntos pueden dar un buen dolor de cabeza.

Validación javascript

En busca de algún fallo XSS, lo primero que intenté fue introducir algunos caracteres como ", <, >, ', etc. en la creación de nuevas carpetas del sistema de mensajes privados de eBay. Al hacer esto, se mostraba el error "Escribe un nombre de carpeta válido". Sin embargo, llamaba la atención que al enviar uno de estos caracteres problemáticos no se reflejaba ninguna petición web en el historial del navegador, lo que indicaba que la validación se estaba produciendo en el lado del cliente por medio de javascript. Aunque tengamos constancia de que se está produciendo una validación javascript que podríamos saltarnos fácilmente, esto no quiere decir que no haya una segunda validación en el servidor que nos pare los pies.

(¿Self?) XSS

Armado con un proxy, capturé la petición que enviaba mi navegador tras especificar un nombre de carpeta válido, y modifiqué el valor del parámetro por algo “inválido” más interesante como <script>alert(/XSS/)</script>. Ante mi sorpresa, al refrescar la bandeja de entrada apareció la alerta javascript, lo que confirmaba que no se producía ninguna validación del parámetro en el servidor:

XSS en nombres de carpetas

Ok, tenemos un fallo XSS, pero de momento es un triste Self-XSS que solo podemos explotar en nuestra propia cuenta. Para que esto fuera realmente peligroso, necesitaríamos poder crear carpetas de mensajes en las cuentas de otros usuarios sin su permiso y colarles nuestro código javascript en los nombres de carpeta. Uff, ¿estaba pidiendo mucho? Merecía la pena comprobarlo...

Self-XSS + CSRF = Owned!!

Una posibilidad para poder crear carpetas en cuentas ajenas, es que existiera un fallo de tipo CSRF. Si analizábamos la petición, nos fijamos en que existían dos candidatos a aguarnos la fiesta como tokens anti-CSRF: stok y pId:

Petición de creación de carpeta

Sin embargo, para mi segunda sorpresa, cualquier valor de estas variables era válido en una petición exitosa.

Debido a los tres fallos (validación de parámetros en cliente, self-XSS y CSRF), finalmente podemos construir una página maliciosa que fuerce la creación de una carpeta en la cuenta de otro usuario, y ejecutar código javascript arbitrario en su navegador:

eBay solucionó el problema de XSS mostrando las entidades html correspondientes para los caracteres especiales, e incluyendo un nuevo parámetro "srt" como token anti-CSRF dentro de la cadena JSON codificada del parámetro "request".

¡Un saludo!