Web Cache Deception Burp Extension

Une extension Burp pour tester les applications contre la vulnérabilité de l'attaque Web Cache Deception.

Une fois l'extension chargée, elle est accessible dans l'onglet Target - Sitemap en faisant un clic droit sur la ressource à tester. Un élément de menu contextuel nommé "Web Cache Deception Test" s'affiche et peut être utilisé pour effectuer le test. Si la ressource est vulnérable, un Issue est créé détaillant la vulnérabilité.

L'élément de menu contextuel est également disponible pour les requêtes dans l'onglet Proxy - Http History.

Installation

• Téléchargez le fichier WebCacheDeceptionScanner.jar.
• Dans Burp Suite, ouvrez l'onglet Extender. Dans l'onglet Extensions, cliquez sur le bouton Ajouter.
• Choisissez le fichier jar téléchargé -> Suivant.
• Vérifiez qu'il n'y a pas de messages d'erreur lors de l'installation.

Vulnérabilité

En février 2017, le chercheur en sécurité Omer Gil a dévoilé un nouveau vecteur d'attaque appelé « Web Cache Deception » (https://omergil.blogspot.co.il/2017/02/web-cache-deception-attack.html).

L'attaque Web Cache Deception peut avoir des conséquences dévastatrices, mais elle est très simple à exécuter :

1. L'attaquant force la victime à ouvrir un lien sur le serveur d'application valide contenant la charge utile.
2. L'attaquant ouvre la page nouvellement mise en cache sur le serveur en utilisant le même lien, pour voir exactement la même page que la victime.

** Bien sûr, cette attaque n'a de sens que lorsque la ressource vulnérable accessible à l'attaquant renvoie des données sensibles.

L'attaque dépend d'un ensemble très spécifique de circonstances pour rendre l'application vulnérable : 1. L'application ne lit que la première partie de l'URL pour déterminer la ressource à renvoyer.
Si la victime demande :

https://www.example.com/my_profile

L'application renvoie la page de profil de la victime. L'application utilise uniquement la première partie de l'URL pour déterminer que la page de profil doit être renvoyée. Si l'application reçoit une requête pour

https://www.example.com/my_profile_test

Elle renverrait toujours la page de profil de la victime, ignorant le texte ajouté. Il en va de même pour d'autres URL comme

https://www.example.com/my_profile/test

2. La pile applicative met en cache les ressources selon leurs extensions de fichier, plutôt que selon les valeurs des en-têtes de cache. Si la pile applicative a été configurée pour mettre en cache les fichiers image. Elle mettra en cache toutes les ressources avec les extensions .jpg .png ou .gif. Cela signifie que, par exemple, l'image à

https://www.example.com/images/dog.jpg

Sera récupérée depuis le serveur d'application la première fois que l'image est demandée. Toutes les demandes ultérieures pour l'image sont servies depuis le cache, répondant avec la même ressource qui a été initialement mise en cache (aussi longtemps que le délai d'expiration du cache est défini).

Attaque

Ces préconditions peuvent être exploitées pour l'attaque Web Cache Deception de la manière suivante :  

Étape 1 : Un attaquant incite la victime à ouvrir un lien malveillant :

  https://www.example.com/my_profile/test.jpg  

• L'application ignore la partie 'test.jpg' de l'URL, la page de profil de la victime est chargée.
• Le mécanisme de mise en cache identifie la ressource comme une image, la mettant en cache.  

Étape 2 : L'attaquant envoie une requête GET pour la page mise en cache :

https://www.example.com/my_profile/test.jpg  

• La ressource mise en cache, qui est en fait la page de profil de la victime, est renvoyée à l'attaquant (ainsi qu'à toute autre personne qui la demande).

CERVEAU EXPLOSÉ Comme c'est facile ?

Changelog

1.1

• Changé pour que l'analyse de ce problème soit incluse lors d'un scan actif.
• Analyse mise à jour pour inclure les leçons apprises dans des environnements réels.
• Le rapport se fait désormais uniquement en ajoutant

1.0 Release