Quelles sont les vulnérabilités exploitées ?

3 types de vulnérabilités ont été exploités :
1) lié à des défaillances techniques (SQL injection, Cross Site Scripting),
2) lié à des défaillances organisationnelles (possibilité d’accéder aux pages
d’administration des sites Web)
3) lié à des défaillances dans la logique applicative.

Comment se prémunir de ces vulnérabilités ?

Dans  le  premier  cas  (Injection  SQL, Cross  Site  Scripting ….). Comme  ces  attaques  font  appel  à  des  langages  informatiques  (SQL,  JavaScript),  elles  sont  assez  facilement reconnaissables et elles peuvent être bloquées grâce à un firewall applicatif Web (WAF). Il est  toutefois  recommandé  d’utiliser  un  WAF  qui  est  capable  d’avoir  une  approche pondérée (comme la Scoring List de Deny All) pour reconnaitre ces attaques. En effet, les WAF qui utilisent de simples « black list » ne sont pas assez efficaces contre ces attaques ou bien, bloquent trop fréquemment le trafic légitime (ce qui est inacceptable).

Dans le deuxième cas, il a été possible d’accéder à l’interface d’administration, car celle-ci n’était pas suffisamment sécurisée. Là encore, un WAF aurait été  fort utile, car  il permet d’augmenter le niveau d’authentification. Il est par exemple possible de faire en sorte que les  administrateurs  ne  puissent  accéder  à  l’interface  d’administration  qu’après  une
authentification forte (Certificat client, RSA SecureID, Vasco, Active Card…)  ce qui permet d’être protégé des attaques qui consistent à deviner un mot de passe en faisant des essais
répétés et automatiques.

Dans  le  troisième  cas,  les vulnérabilités exploitées étaient  liées à des problématiques de logique applicative. Ici, les mécanismes de défense traditionnels sont souvent inefficaces.
En effet, L’exploitation de  la vulnérabilité ne passe pas par un vecteur d’attaque comme une  injection  de  code  (qui  est  identifiable), mais  par  exemple  par  la manipulation  d’un
paramètre dans une URL. Il est toutefois possible d’en limiter les risques grâce au modèle de sécurité positive du WAF  (White List :  tout ce qui n’est pas expressément prévu sera
rejeté).

L’article fait état du temps de réaction des différentes entités. Comment réagir rapidement quand une vulnérabilité a été détectée ?

Certains WAF permettent de mettre en œuvre un patch virtuel sans que l’on ait à modifier l’application WEB. Ceci permet de traiter la vulnérabilité qui a été détectée immédiatement
en  laissant  du  temps  aux  équipes  de  développement  pour  corriger  le  problème  en profondeur sans devoir interrompre le service.

Moralité de l’histoire ?

Dans  le meilleur des mondes, ces vulnérabilités n’auraient pas pu être exploitées, car  les aspects de sécurité auraient été pris en compte de façon importante dès la conception de
l’application WEB et tout au long de son cycle de vie (développement, exploitation). Il est toutefois difficile de prendre en  charge  ces aspects de  sécurité en amont : on demande aux développeurs de concentrer leurs efforts sur les fonctionnalités et non sur la sécurité. De plus, il arrive très fréquemment que l’on n’ait aucun contrôle sur le développement de l’application  Web.  C’est  pour  ces  raisons  et  parce  que  les  attaques  Web  sont  très attractives  pour  les  hackeurs  (simplicité  de mise  en œuvre  et  retour  sur  investissement très  fort)  qu’un  WAF  est  un  élément  devenu  maintenant  indispensable  dans  les infrastructures Web.

Un WAF  (Web application Firewall) est un logiciel ou un équipement matériel  placé entre le firewall et les serveurs WEB,  il permet principalement de protéger les applications Web des attaques applicatives (SQL injections, Cross Site Scripting, injection de code …)

J’ai déjà un Firewall réseau. Quelles sont les différences entre un Firewall réseau et un Firewall applicatif Web ?

Le premier offre une protection périmétrique, il a en charge d’autoriser des paquets à le traverser en fonction de leur source et de leur destination. Le firewall applicatif Web est lui en charge du contenu de ces paquets. On peut comparer ces deux fonctionnalités à un contrôle douanier. Dans un premier temps, une vérification sur le passeport est effectuée (ceci peut être assimilé au firewall réseau), puis une fouille est réalisée (ici assimilée à la vérification effectuée par le firewall applicatif WEB). Ces deux actions sont tout à fait complémentaires et indispensables.

Pourquoi un WAF est maintenant un élément indispensable dans mon infrastructure ?

Selon une étude du Gartner, 75% des attaques ciblent les systèmes d’information à travers les applications WEB.  Selon cette même étude, 2/3 des applications Web sont vulnérables. Elles ont donc une sensibilité « naturelle » aux attaques et offrent un large champ d’action aux hackers. Les attaques Web sont très simples à mettre en œuvre (dans bien des cas, un simple navigateur suffit). De plus, le retour sur investissement pour les hackers est élevé. Voilà principalement pourquoi les applications Web sont de plus en plus la cible d’attaques.

Simplicité de mise en œuvre et retour sur investissement très élevé pour les pirates

Quels sont les cibles et les impacts des attaques Web ?

• L’utilisateur : Les attaques vont cibler l’utilisateur principalement pour récupérer les éléments d’authentification tels que les mots de passe. Une fois récupéré par le pirate, ce dernier pourra se faire passer pour l’utilisateur et réaliser toutes les actions que celui-ci aurait pu réaliser.
• Le serveur WEB. Parmi les impacts les plus fréquents, on retrouve :
  • modification de contenu. Les conséquences du « défacement » sont variables en fonction de la sensibilité de l’image de marque de l’entreprise ;
  • Ajout de contenu illicite;
  • Accès à des documents présents sur le serveur et qui ne sont normalement pas accessibles via le serveur Web ;
  • prise de contrôle du serveur Web (exécution de commandes).
• L’application WEB (au sens logique). Dans ce cas, le but sera de faire en sorte que l’application Web ait un comportement différent de celui attendu. Par exemple : modifier le prix d’un produit
• Les bases de données. Elles sont la cible privilégiée des hackers.  Dans ce cas, le serveur Web est utilisé comme un outil pour accéder aux données. Les impacts vont du vol, à la suppression ou l’altération de données. Notons que bien des vols de données passent complètement inaperçus, car celles-ci restent présentes sur le serveur après « l’effraction ».
• Les Web Services n’échappent pas aux attaques. De plus en plus déployés, ils ont une forte interaction avec les bases de données, ce qui fait d’eux une cible de choix.

Quels sont les autres aspects de sécurité qui peuvent être pris en charge par le firewall applicatif Web ?

Le firewall applicatif est en amont des applications Web qu’il protège. Il devient donc naturel de lui demander de réaliser de l’authentification. Ce point est particulièrement utile lorsque l’on souhaite rendre accessible sur internet et de façon sécurisée des applications Web internes.
Le firewall applicatif Web permet également de virtualiser l’infrastructure applicative (il donne la possibilité d’utiliser des noms de serveurs Web différents de ceux utilisés en interne). De plus, un firewall applicatif Web facilite la mise à disposition sur internet d’applications Web internes (il n’est plus nécessaire de déplacer le serveur Web vers une zone spécifique du réseau). Enfin le FireWall applicatif peut également être utilisé pour fournir des preuves de tentatives d’intrusion. En effet, la totalité des requêtes est journalisée (les serveurs Web ne journalisent pas l’intégralité des éléments).

La sécurité de l’application Web est prise en compte durant le développement, ai-je malgré tout besoin d’un WAF ?

Pour que les méthodes qui visent à apporter de la sécurité tout au long du cycle de vie de l’application puissent être efficaces, il faut avoir un contrôle total sur les phases de développement.  Les aspects de sécurité devront être pris en compte dès la conception, tout au long du développement et durant l’exploitation. Il arrive fréquemment que l’on n’ait pas le niveau de contrôle suffisant à ces différents stades pour obtenir un niveau de sécurité suffisant. Ces méthodes doivent donc impérativement être complétées par la mise en œuvre d’un firewall applicatif Web pour diminuer le périmètre de vulnérabilité. De plus, le firewall applicatif Web permet de lutter contre les attaques qui visent le serveur Web par lui-même (Vulnérabilités IIS, apache … comme directory traversal, déni de services tel que Slowloris …). Firewall applicatif Web et méthodes visant à prendre en considération la sécurité applicative durant les phases de développement sont donc complémentaires.

Le firewall applicatif Web offre-t-il d’autres plus values que celles liées à la sécurité ?

Oui, le firewall applicatif permet d’accélérer le trafic Web particulièrement quand les serveurs Web sont surchargés. En effet, une bonne partie du travail qui était réalisé par le serveur Web (délivrer les pages statiques, prise en charge du chiffrement) sera pris en charge par le Firewall applicatif. L’avantage principal est de permettre au serveur Web de disposer de plus de ressources pour effectuer les traitements. Le firewall applicatif Web est également capable de répartir la charge sur plusieurs serveurs Web et d’assurer la haute disponibilité de ces serveurs. Le bénéfice étant de ne pas avoir à implémenter des mécanismes complexes de haute disponibilité et de se passer d’un répartiteur de charge (load balanceur) en aval. Sans oublier les avantages soulignés dans le paragraphe précédent, comme la simplification et la rationalisation de l’infrastructure.

]]> http://johanne.ulloa.org/pourquoi-un-waf.html/feed 0 http://johanne.ulloa.org/waf-and-waf.html http://johanne.ulloa.org/waf-and-waf.html#comments Tue, 28 Apr 2009 20:28:53 +0000 admin http://johanne.ulloa.org/?p=16 Ne pas confondre  WAF (WEB Application Firewall) et  WAF (Women Acceptance factor)

Si l’on s’en réfère à ce  lien, WAF signifie également « We Are the Future » !

Ce type d’attaque cible l’utilisateur en utilisant une vulnérabilité du serveur WEB. Le but étant de forcer le navigateur de la cible (l’utilisateur) à envoyer des requêtes au serveur. Ces requêtes paraitront donc tout à fait légitimes aux yeux du serveur et la cible réalisera donc des actions à son insu.

Comment cette attaque est réalisée ?

Les attaques XSS/CSRF sont généralement exécutées en 4 phases :

Phase 1 :  L’injection de code sur le serveur vulnérable

Lors de cette phase, le pirate injecte le code (qui peut-être html, css ou javascript) sur le serveur Web. Rappelons que si le serveur Web n’est pas sensible à l’injection de code ou qu’il est protégé par un WAF, l’attaque ne pourra être menée. (à bon entendeur …)

Phase 2 : obtention du code malveillant

Le navigateur obtient le code malveillant injecté précédemment par le pirate. Bien souvent, ce code est hébergé sur un serveur tier, dans ce cas, le but de la phase 1 sera d’injecter un lien vers ce code malveillant.

Phase 3 and 4:  Execution du code

Lors de celle phase, le navigateur exécute le code malveillant. Bien souvent, ce code consiste dans un premier temps à récupérer le cookie de session de l’utilisateur de façon à l’utiliser dans les requêtes qui seront forgées par la suite. Ceci permettra de rendre ces requêtes tout à fait légitimes au regard de l’application Web.

Que faire contre ce type d’attaques ?

Il est possible d’agir sur le serveur et sur le client

Côté serveur :

• Il faut prendre en compte la sécurité applicative lors des phases de développement. Principalement en contrôlant les « input » de l’utilisateur. C’est-à-dire que tout ce qui pourra être envoyé à l’application par l’utilisateur devra être « nettoyé » et validé.
• Pour empêcher que le cookie de session soit accessible via javascript, il est possible de les marquer avec le flag : HTTPOnly.
• Utiliser un Firewall Applicatif Web de façon à prémunir le serveur Web des injections de code.

Coté client :

• Je vous recommande fortement l’usage de Firefox et du plugin NoScript. Ce plugin pemet de n’activer javascript qu’à la demande.  Son rapport « Sécurité apporté/Contraintes d’utilisation » est très bon.

Qu’est-ce que Twitter ?

Twitter est un site communautaire dans lequel les membres postent des informations courtes les concernant ou concernant leur communauté. On peut le qualifier de « micro-blogue ». Il est possible de suivre l’actualité de personnes. On devient dans ce cas le « follower » de la personne et l’on a accès aux éléments postés par cette personne.

Peut-on parler d’un ver ?

Un ver est un programme externe qui sera téléchargé puis exécuté sur l’ordinateur. Dans ce cas, le ver profite simplement de certaines faiblesses du navigateur et du serveur WEB pour se « reproduire ». Aucune présence de programme externe n’est donc nécessaire. Il convient donc mieux de parler d’un « ver WEB » ou « ver XSS/CSRF » car ce ver exploite des vulnérabilités de « Cross-site scripting (XSS) » et de « Cross-site request forgery (CSRF) ».

Concrètement que fait-il ?

Les motivations du jeune hacker (17 ans) ne sont pas claires. C’est sans doute pour gagner en notoriété qu’il a mis au point ce ver. Ce dernier poste de façon automatique à la place d’un utilisateur légitime, un message incitant ses « followers » à aller visiter un site Web. Si une personne clique sur ce lien, le même sort lui est réservé. (Ses « followers » verront que cette personne a posté un message incitant à aller visiter ce site WEB)

Quel est son mode opératoire ?

Tout d’abord, le ver utilise une faille XSS. Le XSS ou (cross site scripting) permet à un attaquant de faire exécuter du code javascript ou html au navigateur de l’utilisateur.
Ce type d’attaque est le plus souvent utilisé pour récupérer les cookies de sessions de l’utilisateur ou pour modifier l’apparence du site WEB.
En l’occurrence, dans ce cas li s’agit de récupérer le cookie de session  de l’utilisateur.

Une fois le cookie récupéré une requête Ajax est forgée de façon automatique avec votre cookie session (ce cookie sert de gage au serveur WEB pour déterminer si la requête vient de vous). Cette requête simule totalement ce que vous auriez fait en temps qu’utilisateur pour poster un message incitant vos « followers » à se rendre sur un site WEB.
Dans la deuxième version du ver, le simple fait de visiter la page twitter d’une personne « infectée » permet de déclencher l’attaque.

Quels sont les impacts de ce type d’attaque ?

Dans ce contexte précis, l’impacte pour les utilisateurs était très faible (poste d’un message à la place de l’utilisateur légitime). Toutefois, l’attaquant prend le contrôle du navigateur pour le forcer à réaliser des actions; on peut donc imaginer les dégâts que peuvent réaliser ce type d’attaques sur des sites sensibles, car ce scénario peut également être perpétré sur des sites traditionnels.

Le mécanisme est maintenant bien rodé sur des sites communautaires. Sans être devin, il est fort à parié que ce genre d’attaque sera perpétué sur d’autres type de sites. On imagine bien le potentiel de ces attaques : forcer un utilisateur à acheter ou vendre un bien ou un service … Les hackers ne sont limités que par leur imagination et la robustesse des systèmes de sécurité qu’ils trouveront face à eux.

Le trafic généré par ce type de ver doit aussi être pris en considération, car il peut mettre à mal la disponibilité du site WEB.

Comment se prémunir de ce type de ver ?

Si vous avez un serveur WEB et que vous souhaitez prémunir vos clients de ce type de vers, on peut:

· Prendre en compte les aspects de sécurité lors du développement d’applications WEB (validation des données envoyées par l’utilisateur);

· Renforcer le control des en utilisant des bibliothèques qui épurent les éléments transmis par les l’utilisateur (Par exemple AntiSamy );

· Taguer les cookies de sessions avec le flag HTTPOnly . Ce flag permet d’interdire l’accès au cookie de session via java script rendant les attaques XSS qui ciblent les cookies de session inefficaces.

· Utiliser un Firewall Applicatif WEB (WAF)  .Cet équipement situé devant le serveur WEB permet de bloquer les tentatives d’injections de code.( Il peut aussi flaguer à la volée les cookies de session en HTTPOnly si l’on n’a pas de contrôle sur l’applicatif )

Si vous êtes utilisateur:

· Utiliser noscript sur Firefox (ce module permet de n’activer java script qu’au cas par cas).

Johanne Ulloa