Corregido fallo en PayPal que permitiría ejecución remota de código

Un experto en ciberseguridad -cuyo nombre es Vikas Anil Sharma- ha descubierto recientemente una vulnerabilidad en la popular web de pagos online PayPal, utilizada por millones de personas en todo el mundo. El fallo ha sido detectado en un servidor concreto, mientras el experto realizaba un test de penetración con Burp Suite.

Vikas se dió cuenta del fallo mientras visitaba la página PayPal Bug Bounty, donde la compañía ofrece recompensas precisamente por esto, detectar fallo mediante pentesting que podrían ser aprovechados por un atacante. Su análisis de vulnerabilidades se centraba en comprobar la lista de dominios de PayPal, citada en Content Security Policy: Response Header, en particular https://*.paypalcorp.com.

Detectada vulnerabilidad en servidor de PayPal

En la primera fase, el hacker de sombrero blanco estaba interesado en encontrar la mayor cantidad de subdominios posibles para explotar el ataque, utilizando herramientas como Subrute, Knockpy o enumail, útiles para estos menesteres.

Estas son herramientas que uso normalmente, pero estando algo perezoso durante el fin de semana hice uso esta vez de Virustotal para enumerar los subdominios.

La lista de dominios está disponible aquí: https://www.virustotal.com/en/domain/paypalcorp.com/information

Entonces, copió la lista de subdominios a su máquina local y ejecutó el siguiente comando para comprobar a dónde estaban apuntando todos los subdominios:

dig -f paypal +noall +answer

El experto se dio cuenta entonces de que el dominio brandpermission.paypalcorp.com apuntaba a https://www.paypal-brandcentral.com, que es un sitio donde se aloja el sistema de ticketing para Soporte Online de partners de PayPal, así como de suministradores y otros colaboradores, donde efectúan peticiones.

PayPal Brand Central

Este sitio permite a los usuarios cargar mockups o creaciones de logotipos y otros gráficos relacionados. Entonces, se propuso comprobar si subiendo una imagen podría causar algo de daño, analizando después la carpeta destino de la imagen.

La imagen, de nombre finished, fue almacenada como finished_thum.jpg en el directorio que sigue: /content/helpdesk/368/867/finishedthumb.jpg

Finished_thumb.jpg fue la nueva imagen creada en el directorio /867/ y rápidamente comprobé si dicho archivo también existía en el directorio o no. Por suerte (verás por qué más adelante en el post) «finished.jpg» también existía en el mismo directorio.

Vikas descubrió que el enlace anterior incluye el número de ticket, en este caso específico era «368», mientras que «867» es el identificador de la carpeta  donde se almacenaban todos los ficheros relacionados con los tickets de proveedores.

Entonces, procedió a crear un nuevo ticket y descubrió que estos identificadores de ticket y de archivo son generados de forma secuencial y por tanto predecible. Por tanto, cargó un archivo con extensión .PHP en lugar de una imagen, descubriendo, para sorpresa general, que no se validaba el tipo de fichero cargado de forma alguna.

Como explica, tan pronto como vio una respuesta 302 (significa redirección temporal), intentó abrir el ticket y replicar los pasos realizados con la imagen anterior, pero esta vez cargando el PHP como archivo «mockup». Sin embargo en este caso no ocurrió lo mismo, dado que lo único que obtuvo fue un número de ticket, sin poder ver la ruta del archivo php. No era posible aparentemente obtener la ruta.

Lo siguiente que hizo fue cargar un archivo de nombre success.php para, por similitud con el archivo de imagen antes cargado, suponer que el archivo sería guardado como success_thumb.php. Llegados aquí, lanzó un ataque de fuerza bruta para obtener el ID de la carpeta de archivos.

Una vez obtenido el ID de carpeta para los archivos, ejecutó el siguiente código:

https://www.paypal-brandcentral.com/content/_helpdesk/366/865/success.php?cmd=uname-a;whoami

Conclusiones

Se había obtenido un RCE (ejecución remota de código) más, para alegría del descubridor, que la certificó lanzando un comando cat + /etc/passwd para terminar de cerciorarse de que realmente era así.

La vulnerabilidad fue informada de forma privada a PayPal el día 8 de Julio de 2017 y corregida 3 días después. Toda la información está disponible en el artículo original del autor.