Mercredi, 8 heures 50 sonnantes et trébuchantes, l'auditorium 1 du centre de conférences Magna à l'Université de Stockholm accueille les premiers participants pour l'édition 2010 de la conférence OWASP Appsec Research Europe, où seront discutés les résultats d'études et travaux de recherche en sécurité des applications web.

9 heures: Les nouveaux enjeux de sécurité pour les éditeurs de navigateurs web

Les hostilités débutent avec un discours d'ouverture par John Wilander, responsable du chapitre OWASP Suède, avant d'enchaîner très rapidement sur la première session dédiée aux travaux de recherche sur lesquels les chercheurs Chris Evans et Ian Fette (team sécurité, Google Chrome) s'affairent en ce moment.

Les pirates délaissent de plus en plus les couches systèmes et réseau pour se concentrer sur les navigateurs et leurs composants, utilisés comme vecteurs techniques d'intrusion. Les navigateurs de leur côté font face à trois grandes catégories de menaces:

• l'exécution de code arbitraire (traduction: exécution de programmes créés par le pirate)
• la fuite de données entre les pages ouvertes (cross-domain security)
les attaques sociales (phishing/ ingénierie sociale)

Trois mesures techniques de défense ont vu le jour afin de réduire ces risques:

• La mise à jour automatique des navigateurs, que les éditeurs cherchent aujourd'hui à étendre également aux composants installés, ceci afin de maintenir le navigateur doté des dernières défenses au sein du code.
• Le renforcement des bacs à sable (sandboxing), ou isolants, créant ainsi des environnements d'exécution sécurisée pour chaque page ouverte dans le navigateur et empêchant la modification d'intégrité du système d'exploitation.
• Les listes noires (blacklists), utilisées pour prévenir l'utilisateur d'éventuels risques s'il/elle décide de continuer la visite sur un site réputé hostile.

Suite au déploiement de ces défenses depuis l'année 2009, on constate que la tendance va vers l'exploitation des composants installés dans le navigateur (plug-ins) tels que Flash, Adobe Reader, Java, etc. En effet, ces composants s'exécutent souvent avec des privilèges supérieurs, sont rarement maintenus à jour par leurs utilisateurs et permettent de contourner les mécanismes de défense, en particulier les bacs à sable, mis en oeuvre par le navigateur.

Les éditeurs de navigateurs considèrent l'intégration des fonctionnalités 'fondamentales' recherchées par les utilisateurs dans les composants tiers (affichage de vidéos, afficheur PDF, machine d'exécution Java, etc.) afin de contrôler l'environnement d'exécution 'web' de façon plus stricte.

Aujourd'hui, les concepteurs de routines d'infection doivent donc planifier une intrusion en deux phases: réussir à forcer l'exécution de code arbitraire au sein du navigateur puis contourner les mécanismes d'isolement (sandbox) pour remonter au sein du système. La réorientation de la scène vers des modes d'exploitation plus sophistiqués (attaques directes sur le noyau) est donc à prévoir.


Autre sujet abordé: les listes de filtrage (blacklists), recensant les adresses (URL) pointant vers des sites hostiles. Première problématique: la diffusion. Comment s'assurer que plusieurs millions de navigateurs sont en permanence équipés de la dernière version de listes pouvant elles-aussi comporter plusieurs millions d'entrées?

Seconde problématique: l'autorité. A ce jour, les navigateurs affichent généralement un avertissement de sécurité particulièrement clair (grande police, messages centrés, couleur de fond rouge sang-mort-Lucifer) à l'utilisateur lui conseillant vivement de rebrousser chemin.

Les statistiques collectées par l'équipe de sécurité du navigateur Google Chrome indiquent que la mesure n'est pas aussi efficace qu'on ne pourrait le penser. L'audience dans la salle estime à environ 10 à 20% le nombre d'internautes ignorant ces avertissements.

La réalité est toute autre: 50% des internautes cliquent sur "continuer", même suite à un avertissement de haut risque. Les chercheurs associent cela à la "soif du porno..."


Autre menace importante pointant le bout de son nez: l'intégration très prochaine de la cinquième version d'HTML, le langage du web dira-t-on, apportant en particulier de nouveaux accès aux périphériques du système (cellule GPS, lecteurs vidéo, accélérateurs graphiques, etc.)

10 heures: Défense contre les attaques CSRF, présentation de l'outil CSFire

(A ce stade, la conférence se sépare en 3 pistes simultanées. Les résumés ci-après ne concernent donc que la piste que j'ai suivie tout au long de la journée.)

Présenté par Lieven Desmet (KU Leuven), CSFire est une extension Firefox capable de détecter et prévenir des attaques CSRF provoquées sur le navigateur de l'utilisateur. J'ai tenté de faire marcher le wifi sur mon téléphone alors je n'ai pas retenu grand chose....

11 heures: Réflexions autour des attaques de type clickjacking

Travaux de recherche présentés par Marco Balduzzi (Eurecom) pour l'élaboration d'un outil de prévention d'attaques clickjacking côté client (extension Firefox).

J'ai trouvé très intéressante leur approche consistant à analyser plus de 70'000 sites web (dont le top 1000 du classement mondial Alexa) pour évaluer la diversité des implémentations faisant l'usage de techniques de présentation web proches des attaques clickjacking:

• 143 millions de pages ont été analysées
• 3.3% des sites analysés implémentent des objets de type FRAME
• 37% des sites analysés implémentent des objets de type IFRAME
• 0.16% des sites analysés implémentent la transparence dans leurs objets FRAME/IFRAME.

L'analyse des sites activement exploités pour leur vulnérabilité à des attaques de type clickjacking a relevé deux scénarios majeurs mis en oeuvre par les pirates:

• La fraude aux clics sponsorisés: contraignant l'utilisateur à cliquer sur des bannières publicitaires qu'il ne voit pas à l'écran
• Les vers sociaux, tels que la Tweetbomb, dont la charge consiste à placer des messages de statut au sein du compte Twitter de l'utilisateur sans qu'il ne s'en rende compte.

Autre élément anecdotique: l'analyse a permis d'identifier deux sites de sociétés de services de sécurité informatique activement attaqués via des mécanismes de types clickjacking.

Finalement, l'étude a également permis d'identifier une large diversité d'implémentations des mécanismes de type frame-busting, censés protéger les sites contre les attaques clickjacking. Une autre session abordait plus tard la question de l'efficacité de ces mesures, qui, à de rares exceptions près, étaient toutes vulnérables à des techniques de contournement. (rassurant!!!)

12 heures: Les Frameworks: tueurs d'analyseurs automatiques?

Présenté par Hang & Andren (Armorize Tech), une réflexion très intéressante sur l'adéquation des outils d'analyse automatisée de code source avec les frameworks de développement de plus en plus complexes.

D'un côté, les éditeurs logiciels sont souvent dotés de frameworks internes particulièrement personnalisés et partageant certaines particularités:

• ils opèrent une très forte séparation entre la couche métier et les vues utilisateur
• ils prennent généralement en charge la collecte des entrées utilisateur et leur diffusion au sein des composants métier
• ils font souvent usage de fonctionnalités d'instanciation dynamique / réflexion
• ils sont magiques: ça marche mais l'éditeur n'a pas la maîtrise technique de son propre framework, seuls un ou deux architectes dans la société sont en mesure d'en comprendre les rouages
• ils sont difficilement testables dès que les différentes briques sont combinées entre elles
• chez de nombreux éditeurs, le framework a été acquis lors du rachat antérieur d'une société, possède une énorme quantité de code 'mort' ou 'legacy' (quel est le terme français pour cela??)
• les nouveaux frameworks de développement ont des flux implémentés (code source) et décrits (descripteurs XML) souvent complexes à analyser

D'un autre côté, les analyseurs de code statique ont d'autres modes de fonctionnement:

• ils sont orientés flux de données et ligne de code
• ils interviennent lors de la compilation
• ils sont souvent intégrés à l'environnement d'implémentation (IDE)
• ils ont de la difficulté à surveiller les flux entre types dynamiques/réfléchis/variants
• les chemins d'exécution sont flous (qui exécute quoi avant qui?)
• ils leur faut le code complet (les éditeurs utilisent de plus en plus des composants externes intégrés en phase finale du cycle de vie)

Au final, deux mondes qui peinent à s'entendre pour des raisons économiques: l'éditeur ne veut pas passer six mois à configurer son outil d'analyse de code source et ce n'est pas rentable pour le fournisseur de prendre en charge la diversité des frameworks présents au sein des entreprises.

Trois stratégies possibles:

• (réaliste, indésirable) L'éditeur configure l'outil d'analyse de code pour son propre framework et supporte l'intégralité des coûts d'intégration.
• (utopique, désiré) Le fournisseur de l'outil d'analyse prend en charge un maximum de frameworks au sein de son outil.
• (tendance) Le fournisseur prend en charge les frameworks majeurs du marché et créé des convertisseurs de code descriptif en code déclaratif (ex: conversion automatique des descripteurs XML pour la collaboration servlets/jsps dans des templates MVC en vrai code Java)

Dans la majorité des cas, c'est l'éditeur qui finit par supporter les coûts d'adaptation au produit.

13 heures: je ne sais plus...

C'est sérieux. J'ai juste noté l'heure....je ne me souviens pas de ce que j'ai entendu. La digestion certainement... :)

14 heures: Boîte à outil pour le développement sécurisé avec .Net

Présentée par Lindförs et König (Microsoft Suède), les participants à cette session ont pu avoir un aperçu de la panoplie d'outils mis à disposition par Microsoft afin d'assister les équipes de développement dans leurs tâches de sécurisation tout au long du cycle de vie projet.

Version 5.0 de la méthodologie de développement sécurisé (Security Development Lifecycle):

• (tout au long du cycle de vie)
• présentation du modèle dédié aux structures de développement agile
• outils intégrés à Visual Studio Team System pour la collaboration
• tâches automatisées pour le maintien de la sécurité (tâches uniques, tâches récurrentes, tâches facultatives)
• modèles de documents de sécurité
• conditions d'acceptation de code source (commit conditions), par exemple: possibilité de demander l'approbation du responsable sécurité applicative lorsque certaines classes sensibles sont modifiées, possibilité d'exiger une passe de l'analyseur statique de code source avant d'autoriser le commit, etc.

Threat Analysis and Modeling Tool (TAM):

• (phase 'conception' du cycle de vie)
• (c'est mon outil préféré! Enfin quelqu'un en parle! Youhouuu!)
• Outil d'assistance à la génération de modèles de menaces/contre-mesures pour les applications web lors de la phase de conception

Web Protection Library:

• (phases 'implémentation' et 'déploiement' du cycle de vie)
• WPL – AntiXSS: encodeurs sécurisés pour le contenu sortant vers le client
• WPL – Security Runtime Engine: module de filtrage transparent contre les attaques XSS et injections de type SQL

Analyseurs de code source:

• (phases 'implémentation' et 'vérification' du cycle de vie)
• FxCOP: analyseur de code statique avec règles de contrôle, orienté fonctionnalités de sécurité (security features)
• Cat.Net: analyseur de code statique avec règles de contrôle, orienté code sécurisé (secure features)

PEX:

• (phase 'vérification' du cycle de vie)
• Générateur dynamique de tests unitaires (couverture de code proche du 99%)
• Intégration facilitée dans les projets VS.Net/TFS

Moles:

• (phase 'vérification' du cycle de vie)
• Convertisseur de méthodes en delegates facilitant l'intégration du mock testing (je n'ai rien compris à la démo...)

Web Configuration Analyzer (WCA)

• (phases 'implémentation', 'vérification' et 'déploiement' du cycle de vie)
• Analyseur des configurations de sécurité des composants sous-jacents à l'environnement du produit
• Analyseur de la configuration de l'outil d'analyse de code source (relisez si vous ne comprenez pas!)
• Analyseur de la configuration de sécurité du service IIS et du Framework Dotnet
• Analyseur de la configuration de sécurité des services SQL Serveur
• Analyseur des permissions de sécurité sur le système de fichiers sous l'application web

Code Contracts

• (phases 'déploiement' du cycle de vie)
• Insertion assistée d'assertions (préconditions, postconditions) de sécurité au sein du code dans sa version compilée (IL)

En conclusion, une session très intensive avec démos 'éclair' à l'appui. Nous n'avons pas eu le temps de poser des questions et j'aurais bien aimé avoir des feedbacks sur la façon dont Microsoft arrive à utiliser tous ces outils au sein de ses propres structures de développement.

Tous les outils sont gratuits et disponibles en téléchargement. J'ai la flemme d'aller chercher les liens mais si vous saisissez les en-têtes de section dans un moteur de recherche pas trop foireux, cela devrait jouer.

15 heures: L'efficacité des tests automatisés face aux 'abrutis'

A mon sens, l'une des sessions les plus intéressantes dans un contexte où de nombreuses sociétés éditrices de logiciels " tout en un automatique ultra intelligents" étaient présentes.

Byrne & Enderson de la société Trustwave nous ont décrit une vingtaine de vulnérabilités critiques identifiées lors de récents tests d'intrusion et analyses de code source qu'un outil d'analyse automatique n'aurait pu identifier.

La conclusion assez sévère: les outils du commerce sont aujourd'hui très forts pour identifier des failles techniques standards (type Top 10 OWASP ou Top 25 SANS) mais restent complétement impuissants devant des cas typiquement conçus par la caste des " Stupid" tels que:

• Vulnérabilités " Salami Slicers": la faille réside dans le fait qu'un petit malin va exploiter une faiblesse du modèle plusieurs milliers ou dizaines de milliers de fois d'affilée pour que l'impact devienne critique pour la société / intéressant pour l'attaquant (cible privilégiée: site de jeu en ligne, trading, enchères, etc.)
• Vulnérabilités "Complex SQL injections": cas d'étude où les développeurs cherchent la présence de caractères hostiles dans les n premiers éléments de la requête. Il suffit d'inscrire l'injection à la n+1ème position.
• Vulnérabilités de type "Euromillion": la faille n'est présente que lorsque certaines conditions magiques sont remplies (cas présenté: après un nombre variable de 10 à 20 tentatives infructueuses d'authentification, l'utilisateur est tout de même accepté pour éviter qu'il n'appelle le support technique)
• Vulnérabilités de type "Confidentialité côté client": des données hautement sensibles sont envoyées vers le navigateur mais cachées à l'utilisateur (ex: librairies AJAX renvoyant l'intégralité des attributs d'un compte utilisateur, dont ses données financières, pour simplement afficher son nom à l'écran)
• Vulnérabilités de type " Stockage sécurisé de données": les données semblent toutes êtes superbement chiffrées lorsque l'on voit depuis le client mais la lecture du code source indique l'utilisation 'dynamique' d'une clé ne changeant jamais entre les implémentations.
• Vulnérabilités dans les flux inter-commerçants: sur ordre de l'internaute, des transactions ont lieu entre plusieurs acteurs (typiquement: achat en ligne) et des contrôles d'intégrité sont déficients dans la chaîne.
etc.

Beaucoup de rires dans la salle, à défaut de pleurer, et quelques frayeurs lorsque l'on devine quelle société se cache derrière l'extrait de code projeté au mur.

Au final, un constat clair et sans ambiguïté: la revue de code et les tests d'intrusion manuels ont de beaux jours devant eux pour les sociétés ne cherchant pas simplement le tampon " a passé l'audit XXX avec succès."

16 heures: Panel " La sécurité logicielle est-elle aujourd'hui en échec?"

Animé par John Wilander (OWASP Suède). J'ai un peu dormi tout le long. Juste quelques éléments intéressants collectés par l'un des intervenants: la société vend des formations au "développement sécurisé" et les feedbacks collectés à l'entrée et à la sortie des formations sur plus d'une centaine de développeurs ont été analysés:

• 5% des développeurs estiment intervenir dans du code posant un risque sécuritaire pour leur employeur avant la formation
• La proportion augmente à 45% après la sortie du cours.
• 72% des développeurs n'ont jamais eu de formation à la sécurité avant d'assister à cette formation. Aucun n'était titulaire d'une certification en matière de sécurité. 19% ont eu une introduction à la sécurité informatique lors de leurs études.

Une question qui a retenu toute mon attention: les universités font-elles leur travail? Faut-il enseigner le développement sécurisé dans les cursus bachelor/master?

Argument majeur: pas nécessairement. La majorité des développeurs en fonction sur le marché du logiciel n'ont pas étudié l'informatique à l'université. Les établissements doivent plutôt proposer des formations continues permettant la spécialisation dans ces problématiques.


Finalement: l'analogie avec le marché du citron. Beaucoup de consommateurs sont incapables de discerner un bon citron d'un mauvais citron lors de leur achat. Dès lors, les vendeurs sont les seuls " informés" et non pas d'intérêt financier ou compétitif à vendre des produits de qualité supérieure. Similaire également au marché des voitures d'occasion, où la majorité des acheteurs est totalement incapable de discerner une bonne affaire d'une mauvaise. Dès lors, les bons vendeurs ne sont pas avantagés par le marché.

Ce modèle semble se présenter dans l'édition logicielle: les acheteurs ne savent pas encore déterminer le niveau de sécurité d'un logiciel qu'ils achètent et déploient dans leur infrastructure. L'une des missions de la communauté est d'apporter de la transparence sur ce point. Objectif rêvé: pouvoir choisir un logiciel/service web de la même façon que l'on regarde le tableau des valeurs nutritionnelles d'un aliment. L'on y trouverait des indicateurs-clés tels que:

• Pourcentage des développeurs formés au développement sécurisé: 36%
• Pourcentage de vulnérabilités de sécurité corrigées et déployées moins de 3 mois après leur découverte: 67%
• Niveaux de maturité respectifs des 3 fonctions de sécurité (conception, vérification, déploiement): 3,3,2.
etc.

Dernière question posée: les experts en sécurité logicielle sont-ils une bande de nerds dont personne ne comprend les préoccupations?

Je ne vous citerai pas les arguments, on s'est promis de garder confidentiel le fruit de cette discussion ;)

18 heures: dîner à l'Hôtel de Ville

(bien mérité!!)

Bon, sur ces belles paroles, je m'en vais récupérer un peu d'ici demain tout à l'heure pour la seconde session!!!



PS: C'est le 200ème billet sur ce blog. J'en profite pour remercier chaleureusement tous mes lecteurs et lectrices les plus fidèles!!! Hop, un gros bisou baveux bien mérité!