Renaud Bidou (Deny All) : « Notre technologie de Scoring List détecte 100% des XSS, 100% des injections HTML et 98% des injections SQL »

Par Ludovic Blin, secuobs.com
Le 24/08/2009

---

Résumé : Renaud Bidou, CTO du spécialiste français du WAF (Web Application Firewall) Deny All, nous détaille quelques technologies utilisées par sa société pour protéger les applications web des diverses menaces qui peuvent peser sur elles. - Lire l'article



Alors que les différents types d’attaques contre les applications web sont de mieux en mieux maitrisés par les attaquants, et tandis que le développement d’applications sécurisées entraîne des contraintes importantes, de nombreuses entreprises se tournent vers des solutions externes, tels les reverse proxy ou WAF (Web Application Firewall) pour protéger leurs applicatifs. La société française Deny All est spécialisée depuis longtemps dans ce type de produits, et utilise différentes méthodes pour filtrer le trafic malveillant avant qu’il n’atteigne sa cible. Nous faisons le point avec Renaud Bidou, directeur technique (CTO) chez Deny All.


[SecuObs] Pouvez nous présenter brièvement les produits Deny All ? dans quels cas sont ils utilisés ?

[Renaud Bidou] Le produit phare de DenyAll est rWeb. Il s'agit d'un Web Application Firewall proposant des fonctionnalités de sécurité, d'authentification et d'accélération pour les applications Web ainsi que les Web Services.

Ce produit est développé depuis près de 10 ans et est déployé dans les grandes entreprises mondiales, dont plus de 35% de l'EuroStoxx 50 et plus de 30% de l'indice CAC 40, dans tous les secteurs.

Il est utilisé pour protéger aussi bien des applications internes que des applications publiques.

DenyAll édite également sProxy, une version plus orientée PME de rWeb, offrant moins de fonctionnalités et de flexibilité que ce dernier.

Enfin le produit rFTP applique le concept de reverse proxy filtrant au protocole FTP afin d'offrir des fonctionnalités de sécurité similaires aux serveurs de transfert de fichiers.


Quels sont les technologies utilisées pour assurer le filtrage des requêtes vers les applications web ? sur quelle base technologique ?

rWeb utilise une base Apache comme technologie de reverse proxy. A partir de ce composant nous avons développé de nombreux modules afin de mettre en œuvre différentes technologies de sécurisation.

Les principales fonctionnalités offertes par ces modules sont les suivantes:

- canonisation des requêtes (URL, en-têtes, paramètres);
- transformation des contenus entrants et sortants;
- suivi des cookies;
- filtrage par signatures;
- filtrage par "scoring";
- filtrage par liste blanche;
- analyse comportementale;
- lutte contre les dénis de service;
- validation de modèles XML.

Dans tous les cas les modules sont des développements 100% DenyAll.


Pouvez vous nous en dire un peu plus sur les différentes listes utilisées par votre technologie ?

Tout d’abord la Black list ? Le centre de veille ?

La BlackList est le composant le plus standard de rWeb. Il s'agit d'une liste de signatures plus ou moins génériques permettant aussi bien d'identifier des modèles standards (injection SQL, XSS, injection xPath) que des attaques ciblées sur une application précise (Oracle, SAP NetWeaver etc.).

Le centre de veille de DenyAll est le DARC (DenyAll Research Center), qui dépend de la R&D. La mission du DARC est double:
- effectuer une veille quotidienne permettant d'identifier et de "signer" les nouvelles attaques;
- mener des travaux de recherche à plus long terme sur les différentes technologies émergentes, tant en termes d'attaques que de protection.

Comment fonctionne la scoring list ?

La ScoringList est la dernière innovation de DenyAll. Il s'agit de la mise en œuvre d'un nouveau modèle de sécurité, basé sur le calcul de poids dans les URL, paramètres et en-têtes d'une requête.

Cette technologie comble les limites des modèle négatifs (blacklist) et positifs (whitelist) en offrant un niveau de sécurité excellent sans aucun apprentissage ni mise à jour. Les tests ont démontré que plus de 85% des attaques étaient bloquées uniquement par ce module, dont 100% des XSS, 100% des injections HTML, 98% des injections SQL etc, ce sans aucun paramétrage spécifique. La méthodologie et l'intégralité des tests effectués sont disponibles dans un White Paper: "Scoring Model Efficiency", ( lien )

La ScoringList est le fruit de deux ans de R&D et de tests chez nos plus grands clients et est actuellement unique sur le marché.

Et la White list ?
La WhiteList impémentée dans rWeb présente la particularité d'offrir quatre niveaux de granularité.

Un premier niveau définit simplement de manière globale les extensions autorisées, la taille maximum du nom d'un répertoire et la profondeur maximum dans l'arborescence.
Un deuxième niveau permet de limiter de manière unique la taille maximale des arguments passés via les paramètres d'une URL.
Le troisième niveau offre la possibilité de préciser un type et une longueur pour un paramètre nommé.
Enfin le quatrième précise pour chaque URL les paramètres et combinaisons de paramètres autorisés ainsi que le type et la taille de ces derniers.

Cette flexibilité permet de mettre rapidement un premier niveau de protection puis de l'affiner au fur et à mesure que l'apprentissage est effectué. Il est par conséquent possible d'atteindre un niveau de sécurité optimal par pallier en fonction du degré de complétion de l'apprentissage.


Comment est réalisé le virtual patching ?
La notion de virtual patching dans le domaine des WAF est un petit peu différente de celle que l'on trouve dans d'autres environnements. En effet, qu'une application soit vulnérable ou non à une attaque un WAF bloquera cette dernière, ne serait-ce que parce qu'un trafic malicieux n'a aucune raison de se trouver sur le réseau.

En revanche certaines applications présentent des erreurs de conception permettant d'accéder directement à certaines ressources privées sans avoir effectué d'authentification, ou de ne pas suivre le chemin logique de parcours du site. Il s'agit alors de patcher la logique de l'application.

Dans ce schéma nous avons développé un module d'analyse comportemental l'UBT (User Behaviour Tracking) permettant, entre autres, d'effectuer ce type de vérifications.

Si l’on entend le terme virtual patching comme la possibilité de filtrer le trafic en fonction de certaines faiblesses révélées sur une application donnée, par exemples des injections SQL, cela est géré nativement par notre technologie, via la ScoringList.


Pouvez-vous nous en dire plus sur l’analyse comportementale ? Est-ce compliqué à paramétrer ?

Notre module d'analyse comportementale (UBT - User Behaviour Tracking), est également une innovation qui nous distingue des autres acteurs du WAF. Il est essentiellement basé sur le calcul de statistiques sur des critères tels que la source la destination, l'URL, la taille ou le contenu des requêtes.

L'objectif est de fournir un mécanisme à même de bloquer les attaques basées sur des requêtes légitimes que les modèles positifs, négatifs ou de scoring ne peuvent identifier. Il s'agit en particulier des dénis de service, du vol de cookies, de la récupération de données (crawling), de l'accès à des pages non autorisées ou encore de l'attaque par brute force de pages d'authentification.

En termes d'utilisation, nous avons simplifié au maximum l'interface de paramétrage du moteur d'analyse comportemental. Ainsi nous avons défini une dizaine de modèles qui peuvent être mis automatiquement en production sans modification de la configuration. Il s'agit par exemple de mécanismes de lutte contre les dénis de service, le crackage de mots de passe par force brute etc.

Dans les autres cas nous avons considérablement limité le nombre et la complexité des paramètres à positionner, généralement au nombre de un ou deux.


Comment fonctionne le mode diode ?

Le fonctionnement en mode diode est également une fonctionnalité unique dans le monde du WAF.

Le principe est simple, rWeb est composé de deux éléments:
- le RPC (Reverse Proxy Cache), en charge des opérations de gestion du cache, de la compression ou encore de l'UBT;
- le SFP (Security Filtering Proxy), qui effectue la plupart des opérations de filtrage ainsi que le load-balancing de serveurs.

En mode "normal", les requêtes sont adressées au RPC qui les transmet au SFP. Ce dernier effectue alors la requête auprès du serveur protégé.
En mode "diode", les requêtes sont adressées au RPC. Le SFP vient ensuite interroger régulièrement le RPC afin de récupérer les requêtes en attente et de les transmettre ensuite au serveur protégé.

Le principal intérêt du mode diode est de maintenir l'étanchéité des zones de sécurité. En effet le RPC peut ainsi se trouver dans une DMZ publique et le SFP dans une zone privée. Les connexions étant initiées depuis le SFP, aucune session n'est ouverte depuis une zone incontrôlée ou exposée vers les zones privées du réseau de l'entreprise.


Quel est le temps de déploiement de vos produits ?

Si l'application à protéger est bien maîtrisée par le client et que les besoins en termes de sécurité sont définis un déploiement est l'affaire de quelques heures.

Bien entendu il faut rajouter à ce délai les phases de spécifications et de test inhérentes à tout projet de ce type.



Sont – ils armés pour lutter efficacement contre une attaque DdoS (voir par exemple la récente attaque slowloris) ?

Cela dépend du type de dénis de service. En effet le module UBT offre une protection efficace contre les dénis de service applicatifs. En revanche la protection contre les dénis de service réseau (synfloods, anomalies, réflexion etc.) n’est pas du ressort d'un WAF, mais plutôt de celui d'un IPS.

Le cas de slowloris est un petit peu particulier. En effet il s'agit d'une attaque qui se base sur des requêtes incomplètes, ou plus précisément qui ne sont jamais complétées. Par conséquent ces requêtes ne sont pas transmises aux modules Apache, ce qui nous prive de la capacité d'utiliser nos modules de sécurité.

Afin de garantir la sécurité de nos clients, le DARC a immédiatement fourni un mécanisme de protection basé sur le filtrage de paquets, par des iptables par exemple. Quelques jours plus tard nous avons publié un patch pour rWeb qui modifie le coeur d'Apache et permet de bloquer l'attaque sans faire appel au moindre composant externe.

Il s'agit du seul patch réellement efficace actuellement développé pour Apache, comme l'indique clairement une recherche sur les mots "slowloris patch" sur google...


Quelles vont être les prochaines évolutions technologiques ?

En termes de sécurité nous allons considérablement étendre le spectre de protection des Web Services en y appliquant le concept de notre moteur d'analyse comportementale.

Nous allons également enrichir nos capacités de contrôle et de transformation des données sortantes (HTML ou XML) afin d'éviter la fuite d'informations, volontaire ou non.

Enfin nous envisageons d'étendre la protection de l'application sur toute la chaine de communication, c'est-à-dire en incluant le poste client. Cela permettrait de garantir que le navigateur connecté à l'application n'est pas compromis et ne peut être utilisé comme relais pour le vol d'information ou la modification des transactions.

Nos efforts de recherche sont également portés sur la simplification de l'utilisation et l'amélioration des performances. Ces deux axes répondent à des besoins légitimes du marché et nous allons y apporter une réponse sans ambiguité.



Renaud Bidou est directeur technique et R&D chez Deny All. Il a précedemment occupé le poste de Spécialiste Technique Stratégique chez le constructeur d'équipements réseaux israelien Radware.Il est également fondateur de la société Intexxia, au sein de laquelle il a conçu le premier SOC (Security Operation Center) français en 2000.
Diplomé de l'INSEP (Institut Supérieur d’Electronique de Paris), Renaud Bidou publie régulièrement des articles dans le magazine MISC, intervient dans des conférences telles que BlackHat, SSTIC ou IT Underground, et est également co-auteur du livre Maîtrise des Risques Informatiques, paru aux éditions WEKA.