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.

Patcher vos applicatifs avec Secunia

Secunia est un fournisseur de services pour la sécurité des ordinateurs permettant de traquer les vulnérabilités de plus de 12.400 logiciels applicatifs et systèmes d'exploitations.

De nombreux ordinateurs possèdent des versions non-patchées des applications les plus populaires. Et les utilisateurs oublient souvent de les mettre à jour. Secunia se charge pour vous de vérifier les versions de vos applications et vous propose les patchs de sécurité lorsqu'ils existent.

Secunia permet de scanner votre ordinateur à partir de leur site web. Mais il propose également un petit logiciel gratuit appelé Secunia PSI à installer sur votre poste client qui fonctionne en tâche de fond et qui scanne periodiquement vos applications vous permettant ainsi d'avoir un statut clair de la sécurité de votre ordinateur. Secunia permet via Secunia PSI de mettre à jour vos applicatifs.

Secunia s'est fait connaître en découvrant des vulnérabilités '"0-day" majeures dans Internet Explorer et de nombreux autres applicatifs.


Source: http://secunia.com/

Du rififi dans le Wifi! Le WPA malmené!

Depuis le récent article des scientifiques japonais concernant la possibilité de craquer WPA (Wifi Protected Access) en 1 minute (http://blogs.zdnet.com/BTL/?p=23384), je ne sais pas pour vous, mais pour moi, quelques éclaircissements s'imposent!

Un peu d'histoire...

En 2003, Moskowitz a montré une faiblesse de WPA devant une attaque par dictionnaire. Mais cette faiblesse peut être facilement évitée en générant la clef maître à partir d'une chaîne de caractères longue et aléaoire.

En 2008, Beck et Tews ont proposé une attaque pratique sur les implémentations de WPA qui supportent IEEE802.11e QoS (Quality of Services). Cette attaque appelée l'attaque Beck-Tews (c'est original!) permet de récupérer la clef MIC et un texte en clair à partir d'un paquet encrypté court tel qu'un paquet ARP ou DNS. Ces paquets courts de type ARP ou DNS sont intéressants car ils ne nécessitent pas de fragmentation en plusieurs messages et réduisent le temps de calcul. L'objectif de l'attaque Beck-Tews n'est pas d'obtenir le texte en clair mais de retrouver la clef MIC et de l'utiliser pour falsifier un paquet.

En 2009, Ohogashi et Morii (de l'université d'Hiroshima) généralisent l'attaque Beck-Tews à toutes les implémentations de WPA. En appliquant l'attaque Beck-Tews à une attaque MITM (Man In The Middle), ils réduisent le temps d'exécution de l'attaque à 1minute. Pour plus de détails vous pouvez jeter un oeil à l'article de Ohogashi et Morii.

Détaillons un peu le scénario de l'attaque Ohogashi-Morii

Ohogashi et Morii affirment que leur attaque s'applique à toutes les implémentations WPA. La pré-condition pour exécuter l'attaque Beck-tews sur WPA est d'obtenir une trame encryptée dont la valeur de l'IV (Initialization Vector) est plus grande que la valeur courante du compteur TSC (TKIP Sequence Counter). Beck-Tews satisfont cette condition en utilisant les caractéristiques de IEEE802.11e QoS.

Les caractéristiques de IEEE802.11e QoS autorisent 8 canaux différents pour des flots de données différents, et dans ce cas chaque canal à un compteur TSC indépendant. Supposons qu'un attaquant à récupéré un paquet encrypté avec un IV = 15 pour le canal 0. Alors l'attaquant ne peut pas réaliser son attaque sur le canal 0 car le compteur TSC a été mis à jour avec la valeur 15. Cependant ce même attaquant peut exécuter son attaque sur un autre canal, si le compteur TSC de ce canal est inférieur à 15.

Dans l'attaque Ohogashi-Morii, les auteurs utilisent l'attaque MITM pour d'obtenir une trame encryptée dont la valeur de l'IV est plus grande que la valeur courante du compteur TSC. L'attaquant intercepte les trames encryptées du destinataire (Access Point /client). Ainsi une trame encryptée dont la valeur de l'IV est plus grande que la valeur courante du compteur TSC peut être obtenue puisque le paquet capturé n'a pas atteint le destinataire.

L'attaquant se place entre le client et l'AP en utilisant une antenne directionnelle ou une plus forte puissance de transmission. Pour établir le MITM entre le client et l'AP (Access point), l'attaquant transmet des "Beacons" et des "Probe Responses" sur un canal différent et utilisant le même SSID que l'AP légitime.

L'attaquant doit ensuite obtenir la clef MIC pour générer et injecter des trames modifiées.


Quelques détails techniques...

WPA s'appuie sur des mécanismes de confidentialité basés sur TKIP ou CCMP, et sur deux mécanismes d'authentification: EAP pour le marché entreprise et hotspot, et PSK (Pre-Shared Key) pour le marché résidentiel (clef partagée entre tous les utilisateurs et les APs).

Le standard 802.1x est une solution de sécurisation, mise au point par l'IEEE, permettant d'authentifier un utilisateur souhaitant accéder à un réseau (filaire ou non) grâce à un serveur d'authentification. Le standard 802.1x repose sur le protocole EAP (Extensible Authentication Protocol), défini par l'IETF, dont le rôle est de transporter les informations d'authentification des utilisateurs.

Le tableau ci-dessous résume les différentes méthodes EAP (Extensible Authentication Protocol):

Le tableau ci-dessous décrit les méthodes d'encryption utilisées par les WLAN en 802.11:

TKIP signifie Temporary Key Integrity Protocol. Il utilise un message de vérification d'intégrité appelé "Michael" alias "Mike". Comme WEP, TKIP utilise l'algorithme d'encryption RC4.

Avec un mécanisme de confidentialité basé sur TKIP, un clef maître (PMK) est partagée entre le point d'accès (AP) et le client. Soit la clef maître est partagée en suivant le modèle du WEP comme dans le modèle WPA-Personal du tableau ci-dessus, soit la clef maître est dérivée dans le contexte de l'authentification EAP (avec un serveur d'authentification 802.1x) comme dans le modèle WPA-Entreprise du tableau ci-dessus.

En d'autres termes, le standard fournit 2 méthodes de distributions des PMKs. Quand un serveur d'authentification 802.1x est utilisé, la PMK est dérivée lorsqu'un client s'authentifie sur le serveur. Pour les réseaux qui ne supportent pas 802.1x, une clef partagée appelée PSK (Pre-Shared Key) est "distribuée" à tous les clients et les APs. Cette PSK est la PMK.

La PMK permet de générer la clef MIC (64 bits) et une clef d'encryption (128 bits). Un MIC (Message Integrity Check) est généré à partir de la clef MIC et d'une donnée; ce MIC est utilisé pour détecter la falsification du message (i.e. son intégrité). La clef d'encryption permet d'encrypter et de décrypter les paquets.

CCMP signifie CTR (Counter mode) with CBC-MAC (Cipher Block Chaining Message Authentication Code) Protocol. CTR est un attribut de la méthode d'encryption. CBC-MAC est utilisé pour l'intégrité des messages et l'authentification. CCMP utilise l'algorithme d'encryption AES (Advanced Encryption Standard).

TKIP et CCMP utilisent une clef maître séparée appelée PMK (Pair-wise Master Key) pour chaque couple de noeuds e.g. un client et un AP ou deux clients. La clef maître est utilisée pour dériver d'autres clefs qui sont utilisées pour encrypter/décrypter le trafic entre le couple de noeuds. Cette approche permet de moins exposer la clef maître.

L'association entre 2 noeuds du réseau est créée par l'échange de 4 paquets appelés "4 way handshake". Pendant cette transaction les noeuds dérivent la PTK (Pair-wise Transient Key) qui est ensuite partitionnée pour produire les autres clefs qui seront utilisés pour l'encryption et l'intégrité. La PTK est dérivée à partir de la PMK et de valeurs aléatoires fournit par le client (SNonce) et l'AP (ANonce).

Quand TKIP ou CCMP sont utilisés, le traffic "broadcast" et "multicast" est encrypté en utilisant une clef de groupe. La clef de groupe appelé GTK (Group Temporal Key) est distribuée pendant le "4 way handshake".

Le tableau ci-dessous compare WEP, TKIP et CCMP:

Si nous devions conclure...

Les attaques Beck-Tews et Ohogashi-Morii se basent sur le mécanisme de confidentialité TKIP. Pour plus de sécurité il est donc conseillé d'utiliser le mécanisme de confidentialité CCMP. Mais pour cela le matériel doit implémenter AES.

On remarque cependant qu'un IDS (Intrusion Detection System) convenablement configuré peut détecter la tentative de MITM nécessaire à la réalisation de l'attaque.

A bientôt...

Source: "Analysis of MITM based TKIP attack described in paper titled - "A Practical Message Falsification Attack on WPA" by Robbie Gill et le cours de Laurent Butti sur la sécurité des réseaux (France Telecom).