Cross Site Request Forgery par l'image!

Cross Site Request Forgery est aussi connu sous l'abbréviation CSRF. Le CSRF exploite un site web pour lequel des commandes non autorisées sont transmises par un utilisateur en qui le site web à confiance.



A la différence du XSS (Cross Site Scripting) qui exploite la confiance d'un utilisateur pour un site web particulier, le CSRF exploite la confiance qu'un site web à dans le browser de l'utilisateur.




Prenons un exemple pour nous permettre de mieux comprendre la mécanique du CSRF.

Bertrand se connecte comme tout les matins sur son site bancaire pour effectuer les opérations nécessaires à son activité professionnelle. Il commence par s'authentifier auprès de sa banque et réalise quelques transferts de fonds. Puis il va consulter ses mails personnels sur son web mail favori en oubliant de fermer la session avec son site bancaire. Il est impatient de recevoir la confirmation de la réservation d'un séjour d'une semaine en Guadeloupe. Il aimerait annoncer la bonne nouvelle à sa famille en rentrant ce soir. Bertrand trouve de nombreux mails dans sa boîte aux lettres, mais pas de confirmation de réservation. Déception!Par contre, un de ces mails non attendus lui propose d'obtenir la liste des salaires de son entreprise (un grand groupe international). Intrigué, il ne résiste pas à la tentation et clique sur l'URL proposée. Il obtient effectivement une liste de salaires mais l'information ne lui semble pas très fiable. Tant pis! Bertrand reprend consciencieusement son travail.

Ce que Bertrand ne sait pas encore c'est qu'en cliquant sur l'URL pour accèder à la liste des salaires, il a ouvert la boîte de Pandore: un script malicieux s'est exécuté pour réaliser un transfert de fonds de son compte bancaire vers un compte tiers.


Ce scénario est bien entendu une fiction et la ficelle semble bien grosse. Mais il permet, me semble t'il, de bien comprendre ce qu'est le CSRF.


La vidéo ci-dessous explique plus en détails les arcanes du CSRF à partir d'un exemple similaire.

Quelques conseils pour essayer d'éviter ce type d'attaque:

• Demander des confirmations à l'utilisateur pour les actions critiques au risque d'alourdir l'enchaînement des formulaires. La demande de confirmation peut être basée sur une ré-authentification de l'utilisateur avec la même méthode d'authentification, ou une méthode d'authentification plus forte si l'action requise est critique.
• Vérifier l'adresse URL du script appelant (referrer) au risque également d'alourdir le développement des formulaires.
• Utiliser des jetons de validité dans les formulaires pour faire en sorte qu'un formulaire posté ne soit accepté que s'il a été produit quelques minutes auparavant : le jeton de validité en sera la preuve. Le jeton de validité doit être transmis en paramètre et vérifié côté serveur.

A bientôt...

Comment détecter les PDFs malveillants?

Avant de vous présenter comment on peut détecter les PDFs (Portable Document Format) malveillants un bref rappel du format PDF me semble nécessaire.

Un document PDF peut être défini comme un ensemble d’objets qui décrivent comment une ou plusieurs pages peuvent être affichées. Ces objets et autres composants additionnels sont gérés par une combinaison d'opérandes (objets) et opérateurs qui constituent un véritable langage dédié à la description de pages PDF.

Cette description de page se fait en 2 étapes:

• l'application génére une description du document en langage PDF indépendante du matériel
• un interpréteur assure ensuite le rendu et l'affichage du document à partir de la description précédente.
  
  

Tout fichier PDF contient les sections suivantes:

• Le « Header » contient la version du fichier PDF.



• L’ « Object » racine contient le catalogue qui décrit le contenu du fichier.



• Les autres « Object » décrivent le type des données et leur format. Par exemple le type peut être du texte et la police « Helvetica ».



• La table « Cross References » contient la liste des objets utilisés et les objets supprimés (ce qui signifie que lorsque vous créez un fichier PDF puis en supprimez une partie, cette partie supprimée n’est plus affichée mais elle est toujours présente dans le fichier PDF et peut donc être récupérée; danger!). La table de référence croisée (alias Cross References) permet d'accéder directement aux objets sans avoir à parcourir tout le code.



• Le « Trailer » contient des informations essentielles à la lecture du fichier dont entre autres choses le nombre d'objets contenus dans le fichier et l'offset de la table de référence croisée (alias Cross References). Cette section bien que située à la fin du fichier est la première lue.

Maintenant que les présentations sont faites, nous allons voir comment détecter un PDF contenant un script malveillant.

Une fois de plus nous utilisons le framework «Origami 1.0.0. Beta 0» non pas cette fois pour créer un PDF malveillant mais pour détecter les PDFs malveillants.
Pour cela nous lançons le script Ruby appelé pdfscan.rb situé dans le répertoire «scripts/scan» en ligne de commande et nous obtenons le résultat suivant :

La première chose à remarquer est qu’il y a plusieurs sections dans le résultat de l’analyse:

File ID : permet de se souvenir du fichier analysé

Structure : permet d’avoir une vue rapide sur la structure du PDF (la version, les «object»,…). Chacun de ces éléments permet d'obtenir des indices pour mieux comprendre le résultat

Properties : permet de savoir si le fichier est encrypté (afin de cacher un code malveillant) ou s’il contient des fichiers embarqués (qui peuvent contenir un «malware»)

Triggers : un contenu malicieux est inutile s’il n’est pas utilisé, c’est pourquoi il est intéressant de connaître les moyens de générer des événements.

Actions : même si les actions ne sont pas nécessaires pour exploiter une faille, elles sont à suspecter car la plupart du temps un fichier PDF ne contient pas d’actions dynamiques.

Revenons aux résultats de l’analyse de notre fichier suspicieux! Si le résultat de l’analyse est suspect il apparaît en rouge. Cela signifie que vous devez vous méfier de ce PDF et l’analyser plus en détails.

A bon entendeur...

Sources: « Origami in PDF » (http://www.security-labs.org/origami/), “Blog de l’équipe R&D Essec” (http://esec.fr.sogeti.com/blog) et MISC n°38 (je ne saurais que trop vous recommander de vous y abonner) avec l'article "Les nouveaux malwares de document" d'Alexandre Blonce, Eric Filiol et Laurent Frayssignes.