La vulnérabilité ne concerne pas directement les transactions PayPal ou les données du client, mais peut être configurée de façon à diffuser du contenu ou des fichiers malveillants aux utilisateurs, ce qui peut permettre la mise en place d’un large éventail d'attaques pouvant s’avérer encore plus dangereuses.

PayPal a corrigé la vulnérabilité suite à la divulgation responsable de Bitdefender, rendant inefficaces les attaques potentielles exploitant cette vulnérabilité.

Le problème

Le problème réside dans la façon dont PayPal traite et chiffre les URL qui vont chercher les fichiers uploadés. Notre Proof of Concept utilise un fichier XML au format HTML, l’uploade via la rubrique « Créer une facture » et effectue un CBC (Cypher Block Chaining, chaînage de blocs de chiffrement), puis attaque les URL qui obtiennent les fichiers uploadés depuis les serveurs de PayPal.

Parce que le paramètre « ID » pour chaque fichier uploadé prend la valeur d'un texte chiffré codé en base64 et utilise le mode de chiffrement CBC, l'attaque implique de changer une série d'octets de chaque bloc de chiffrement afin de forcer le serveur PayPal à exécuter la charge utile malveillante.

L'attaque

Chaque fois qu'un fichier est uploadé via le formulaire « Créer une facture », l'URL générée prend la forme suivante :

Le paramètre « ID » semble prendre comme valeur un texte chiffré codé en base64. Le premier test a consisté à inclure un nom de fichier avec différentes longueurs pour voir s’il se reflétait dans le texte chiffré et si c’était un mode de chiffrement par bloc.

Une fois ceci prouvé, la prochaine étape consistait à utiliser un grand nom de fichier, pour comprendre quel mode de chiffrement avait été utilisé.

En ayant conscience que le mode CBC pourrait être utilisé par le chiffrement, nous avons ensuite modifié la valeur du paramètre « ID » en changeant le troisième octet du premier bloc chiffré, puis nous l'avons envoyé au serveur de PayPal. Nous avons reçu la réponse suivante :

Puisque nous avons reçu « cyntent » au lieu de « content », nous nous sommes rendus compte que chaque bloc faisait 16 octets.

Nous avons ensuite pris la valeur de « ID » (base64) et réalisé un décodage d'URL. En effet, dans une URL, "/" peut être confondu avec « autre dossier dans » et « + » peut être confondu avec « espace ». Nous l’avons décodé, puis utilisé un script pour convertir à nouveau l’hexadécimal en base64.

Après quelques uns de ces tests, nous avons pu extraire la valeur de l'ensemble du texte chiffré. Voici un exemple de ce à quoi ressemblait le texte déchiffré :

Parce que le serveur accepterait du texte jusqu'à ce qu'il trouve le séparateur « ~ », nous avons confirmé qu'il nous retournerait l'erreur ou le fichier en pièce jointe.

D'autres tests ont révélé que si il n'y avait pas de « ~ » séparateur dans le texte, le navigateur affichait la réponse, au lieu d’afficher un message proposant de la télécharger en pièce jointe.

Cela est lié au fait que le serveur PayPal avait récupéré des informations du User Agent et détecté que notre paramètre Content-Disposition dans Firefox – responsable de l'affichage de contenu – n'avait pas été configuré.

Tel est le principe de base de création d'une attaque XSS Permanente. Voici le processus réel étape par étape pour mener à bien une attaque XSS Permanente.

1. Créez un fichier XML ayant un contenu HTML, mais respectant une structure XML ;

2. Uploadez-le sur le serveur ;

3. Copiez le lien vers ce fichier ;

4. Modifiez le deuxième octet du chiffrement pour produire une erreur ;

5. Maintenant, vous avez le chemin complet vers la XSS Permanente ;

6. À présent, vous devez effectuer un deuxième upload, mais cette fois il vous faut contourner une restriction en modifiant quelques octets du texte chiffré.

 Vous ne pouvez pas utiliser « / » dans le nom du fichier et vous devez choisir un autre caractère. Par exemple, choisissez le caractère « . ».

7. Ajoutez un nouveau fichier et comme nom de fichier, insérez ceci :

8. Divisez-le en 16 blocs qui ressembleront à ceci :

9. Utilisez des blocs « aaaaaaaaaaaaaaaa », « bbbbbbbbbbbbbbbb » et «cccccccccccccccc » pour changer les octets des blocs suivants, changeant les « . » en « / », ce qui a pour résultat de créer les blocs suivants :

Les 3 blocs où vous avez changé quelques octets ne s’afficheront pas comme précédemment: au lieu de « aaaaaaaaaaaaaaaa » vous verrez apparaître quelque chose comme :

10. Sur l'image ci-dessus, vous avez utilisé un script qui agit comme un proxy pour qu’il vous envoie la réponse de PayPal.

11. Maintenant, il vous reste simplement à copier le lien et à l'utiliser pour d'autres attaques. La page Web générée par notre Proof of Concept ressemblait à ceci :

Ce que cela implique

D'autres attaques pourraient permettre l’exploitation de failles du type RFD (Reflected File Download), en créant des fichiers PayPal ayant la forme de « ~ test.bat ». En téléchargeant et en exécutant ces fichiers, les attaquants pourraient inciter les utilisateurs à installer des logiciels malveillants ou d'autres types de menaces.

L'attaque XSS Permanente ne fonctionne que sur Mozilla Firefox, puisque quand le User Agent contient le mot « Firefox », le formulaire de réponse ne configure aucun paramètre Content-Disposition.
Bien que ce type d'attaque n’ait pas été signalé comme étant en circulation, il aurait pu permettre à des pirates de manipuler les URL PayPal et inciter les utilisateurs à télécharger des fichiers malveillants ou visiter des sites Web frauduleux.

Note : Cet article est basé sur des informations techniques fournies gracieusement par Ionut Cernica, chercheur chez Bitdefender.