Projet PoC de détournement de contenu (données) intersite (XSCH)

Licence

Publié sous licence AGPL (voir LICENSE pour plus d'informations).

Description

Ce projet peut être utilisé pour fournir une preuve de concept pour :

• Exploiter des sites web avec des fichiers de politique non sécurisés (crossdomain.xml ou clientaccesspolicy.xml) en lisant leur contenu.
• Exploiter des fonctionnalités de téléversement de fichiers non sécurisées qui ne vérifient pas correctement le contenu des fichiers ou permettent de téléverser des fichiers SWF ou PDF sans avoir d'en-tête Content-Disposition lors du processus de téléchargement. Dans ce scénario, le fichier SWF, XAP ou PDF créé doit être téléversé avec une extension quelconque telle que .JPG sur le site web cible. Ensuite, la valeur « Object File » doit être définie sur l'URL du fichier téléversé pour lire le contenu du site web cible.
• Exploiter CVE-2011-2461 (voir les références pour plus de détails)
• Exploiter des sites web avec des en-têtes CORS (partage de ressources entre origines) HTML5 non sécurisés

Remarque : les fichiers .XAP peuvent être renommés avec n'importe quelle autre extension, mais ils ne peuvent plus être chargés en cross-domain. Il semble que Silverlight détermine l'extension du fichier en fonction de l'URL fournie et l'ignore si elle n'est pas .XAP. Cela peut néanmoins être exploité si un site web permet aux utilisateurs d'utiliser ";" ou "/" après le nom de fichier réel pour ajouter une extension ".XAP".

Usage

• Exploiter un fichier de politique non sécurisé :
  1. Hébergez le répertoire ContentHijacking avec un serveur web.
  2. Accédez à la page index.html (vous serez redirigé vers ContentHijackingLoader.html).
  3. Modifiez le champ « Object File » dans la page HTML pour pointer vers un objet approprié du répertoire « objects » (« xfa-manual-ContentHijacking.pdf » ne peut pas être utilisé).
• Exploiter un téléversement/téléchargement de fichier non sécurisé :
  1. Téléversez un fichier objet depuis le répertoire « objects » vers le serveur victime. Ces fichiers peuvent également être renommés avec une autre extension lorsqu'ils sont téléversés sur un autre domaine (dans ce but, utilisez d'abord Flash, puis PDF, car les fichiers XAP Silverlight ne fonctionneront normalement pas avec une autre extension depuis un autre domaine).
  2. Le champ « Object File » doit être défini sur l'emplacement du fichier téléversé.
• Exploiter CVE-2011-2461
  1. Le champ « Object File » doit être défini sur le fichier vulnérable.
  2. Sélectionnez l'option « Flash CVE-2011-2461 Only » dans la liste déroulante du champ « Type ».
• Exploiter une politique CORS non sécurisée :
  1. Le champ « Object File » peut être défini sur le fichier local « ContentHijacking.html ». Si vous pouvez téléverser un fichier HTML sur votre domaine cible, vous pouvez exploiter des problèmes XSS beaucoup plus facilement qu'en utilisant CORS.

Remarque : les fichiers .XAP peuvent être renommés avec n'importe quelle autre extension, mais ils ne peuvent plus être chargés en cross-domain. Il semble que Silverlight détermine l'extension du fichier en fonction de l'URL fournie et l'ignore si elle n'est pas .XAP. Cela peut néanmoins être exploité si un site web permet aux utilisateurs d'utiliser ";" ou "/" après le nom de fichier réel pour ajouter une extension ".XAP".

Remarque : lorsque Silverlight demande un fichier .XAP en cross-domain, le type de contenu doit être : application/x-silverlight-app.

Remarque : les fichiers PDF ne peuvent être utilisés que dans le lecteur Adobe Reader (ils ne fonctionneront pas avec les lecteurs PDF intégrés de Chrome et Firefox).

Remarque : la lecture de contenus statiques ou de données accessibles publiquement ne peut pas être considérée comme un problème. Il est important de supprimer les faux positifs de vos bulletins de sécurité. Notez que l'utilisation d'un seul caractère astérisque (« * ») dans l'en-tête « Access-Control-Allow-Origin » n'est pas un problème.

Exemple d'utilisation :

• dans IE avec Adobe Reader : https://15.rs/ContentHijacking/ContentHijackingLoader.html?objfile=https://15.rs/ContentHijacking/objects/ContentHijacking.pdf&objtype=pdf&target=https://0me.me/&postdata=param1=foobar&logmode=all&regex=owasp.*&isauto=1
• dans tout navigateur prenant en charge SWF : http://15.rs/ContentHijacking/ContentHijackingLoader.html?objfile=http://0me.me/ContentHijacking/objects/ContentHijacking.swf&objtype=flash&target=http://0me.me/&postdata=&logmode=result&regex=&isauto=1

Recommandation générale pour résoudre le problème de sécurité

Les types de fichiers autorisés au téléversement devraient être limités à ceux qui sont nécessaires aux besoins de l'activité.

L'application devrait effectuer un filtrage et un contrôle du contenu sur tous les fichiers téléversés sur le serveur. Les fichiers devraient être soigneusement analysés et validés avant d'être mis à la disposition des autres utilisateurs. En cas de doute, le fichier devrait être rejeté.

L'ajout des en-têtes « Content-Disposition: Attachment » et « X-Content-Type-Options: nosniff » à la réponse des fichiers statiques sécurisera le site web contre les attaques de détournement de contenu intersite basées sur Flash ou PDF. Il est recommandé d'appliquer cette pratique à tous les fichiers que les utilisateurs doivent télécharger dans tous les modules qui gèrent un téléchargement de fichier. Bien que cette méthode ne sécurise pas entièrement le site web contre les attaques utilisant Silverlight ou des objets similaires, elle peut atténuer le risque lié à l'utilisation d'objets Adobe Flash et PDF, en particulier lorsque le téléversement de fichiers PDF est autorisé.

Les fichiers de politique cross-domain Flash/PDF (crossdomain.xml) ou Silverlight (clientaccesspolicy.xml) devraient être supprimés s'ils ne sont pas utilisés et si aucune nécessité professionnelle n'impose aux applications Flash ou Silverlight de communiquer avec le site web.

L'accès cross-domain devrait être restreint à un ensemble minimal de domaines de confiance qui nécessiteront un accès. Une politique d'accès est considérée comme faible ou non sécurisée lorsqu'un caractère générique est utilisé, en particulier dans la valeur de l'attribut « uri ».

Tout fichier « crossdomain.xml » utilisé pour des applications Silverlight devrait être considéré comme faible car il ne peut accepter qu'un caractère générique (« * ») dans l'attribut de domaine.

La mise en cache du navigateur devrait être désactivée pour les fichiers corssdomain.xml et clientaccesspolicy.xml. Cela permet au site web de mettre facilement à jour le fichier ou de restreindre l'accès aux services web si nécessaire. Une fois le fichier de politique d'accès client vérifié, il reste en vigueur pour la session du navigateur, de sorte que l'impact de l'absence de mise en cache pour l'utilisateur final est minime. Cela peut être signalé comme un risque faible ou informatif selon le contenu du site web cible, la sécurité et la complexité du ou des fichiers de politique.

Les en-têtes CORS devraient être examinés afin de n'être activés que pour les données statiques ou accessibles publiquement. Sinon, l'en-tête « Access-Control-Allow-Origin » ne devrait contenir que des adresses autorisées. D'autres en-têtes CORS tels que « Access-Control-Allow-Credentials » ne devraient être utilisés que lorsque cela est nécessaire. Les éléments des en-têtes CORS tels que « Access-Control-Allow-Methods » ou « Access-Control-Allow-Headers » devraient être examinés et supprimés s'ils ne sont pas nécessaires.

Remarque : l'utilisation de l'en-tête « Referer » ne peut pas constituer une solution car il est possible de définir cet en-tête, par exemple, en envoyant une requête POST avec Adobe Reader et un PDF (voir le fichier « xfa-manual-ContentHijacking.pdf » dans le répertoire « objects »). Mise à jour : la définition de l'en-tête « referer » a été corrigée par Adobe, sauf si vous trouvez aussi un contournement de cette protection ;)

Page du projet

Consultez la page du projet pour les dernières mises à jour/aide : https://github.com/nccgroup/CrossSiteContentHijacking

Auteur

Soroush Dalili (@irsdl) de NCC Group

Références

Même le téléversement d'un fichier JPG peut mener à un détournement de données cross-domain (attaque côté client) ! https://soroush.secproject.com/blog/2014/05/even-uploading-a-jpg-file-can-lead-to-cross-domain-data-hijacking-client-side-attack/

De multiples vulnérabilités PDF - Texte et images sous stéroïdes http://insert-script.blogspot.co.at/2014/12/multiple-pdf-vulnerabilites-text-and.html

Communication HTTP et sécurité avec Silverlight http://msdn.microsoft.com/en-gb/library/cc838250(v=vs.95).aspx

Explication des fichiers de politique cross-domain et d'accès client pour Silverlight http://www.devtoolshed.com/explanation-cross-domain-and-client-access-policy-files-silverlight

Spécification du fichier de politique cross-domain http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html

Configuration d'un fichier crossdomain.xml pour le streaming HTTP http://www.adobe.com/devnet/adobe-media-server/articles/cross-domain-xml-for-streaming.html

Exploitation de CVE-2011-2461 sur google.com http://blog.mindedsecurity.com/2015/03/exploiting-cve-2011-2461-on-googlecom.html