Livrable semaine 10/03/2010

Mise en place dune solution WAF base de produits open source

Rdig par :Nasredine Boujmil Encadr par : Mr Najib Bazza

Lensemble des livrables raliss chaque semaine reprsente un bilan de taches ralises ainsi que les difficults que jai retrouves au cours de la ralisation et les petites remarques que jai prises .

Livrable 10/03/2011

Cette semaine a t une opportunit pour comprendre les mcanismes des attaques WEB les plus connues, dillustrer chaque attaque par des exemples pour avoir une ide gnrale sur les situations dans lesquelles peut intervenir un WAF ainsi de comparer lensemble des produits open source existants au sein du march pour trancher sur une solution finale qui peut compromettre entre lensemble des fonctionnalits dcrites par le cahier de charges. Comprendre les attaques WEB et leurs mcanismes

Interprtation des URLs

Les URLs utilises dans le cadre dune application Web sont du type : http://www.monserveur.com/chemin/fichier.ext?param1=toto&param2=valaplage Une URL de ce type est compose de plusieurs parties : -http:// : protocole utilis - www.monserveur.com : adresse du serveur (FQDN) - chemin : arborescence de rpertoires sur le serveur Web - fichier.ext : fichier lu ou excut (son extension .ext est trs importante) - param1 et param2 : paramtres dexcution, interprts soit au niveau des composants mtiers, soit directement au niveau de la base de donnes. Chacune de ces parties est susceptible dtre attaque :

Protocole : on peut essayer de remplacer le protocole https:// par http:// par exemple, afin de dsactiver une authentification par certificat client. Serveur : on peut le remplacer par son adresse IP ou par les noms de domaines dautres sites hbergs sur le mme serveur, afin davoir accs dautres parties du site. Chemin : on peut tenter de naviguer dans larborescence pour accder des
parties du site non autorises ou pour remonter dans larborescence par lutilisation de /../../, ou en utilisant des vulnrabilits particulires (le bug Unicode sur IIS, par exemple).

Mauvais Contrle des donnes entres par lutilisateur

Au cours de nos audits et tests dintrusion, nous rencontrons encore trop souvent des applications Web o le contrle des entres par lutilisateur se fait uniquement ct client. Dans ce cas, il faut toujours considrer quun attaquant pourra outrepasser le contrle ct client et donc envoyer les donnes quil dsire au serveur, laide dun proxy intrusif par exemple. La rgle adopter est de ne jamais faire confiance du code tournant ct client, comme des applets Java par exemple. En effet, ce code pourra toujours tre dcompil, analys et modifi pour effectuer les tches voulues par un attaquant.

Livrable 10/03/2011 Considrons le cas dune page Web permettant deffectuer un virement bancaire. Par prcaution, la banque limite les virements par Internet 10000 Dirhams. Dailleurs, un script Javascript contenu dans la page HTML contrle en temps rel le montant saisi et empche toute validation avant que le montant soit correct. Dans ces conditions, il suffit de modifier le script, ou mme simplement de dsactiver Javascript, pour pouvoir saisir un montant de 1 000 000 Dirhams et valider le formulaire. La recommandation qui simpose est donc de toujours contrler la validit des donnes fournies par lutilisateur au moins ct serveur. Ce contrle peut bien sr tre doubl ct client pour des raisons dergonomie, mais le contrle final devra toujours avoir lieu ct serveur. Dautre part, il existe des caractres spciaux dont la signification, au sein dune chane alphanumrique, peut respecter une syntaxe particulire au niveau dun langage de programmation ou dun systme dexploitation, ce qui peut conduire lexcution de commandes hostiles. Ces caractres figurent parmi les suivants : !@$%^&*()-_+`~\|[]{};:'"?/,.><

Injection SQL
Linjection SQL peut tre une consquence directe dun mauvais contrle des donnes entres par lutilisateur. En effet, les caractres et ; peuvent tre utiliss pour enchaner plusieurs requtes SQL la suite. Considrons par exemple une page HTML comprenant un champ de saisie nomm Name permettant dobtenir les coordonnes des clients dune entreprise. La requte SQL tournant sur le serveur est la suivante : SELECT * FROM table_Clients WHERE champ_Nom=Name Si maintenant un attaquant saisit la chane suivante dans le champ Name : toto ; INSERT INTO table_Users VALUES ('Mon_login', 'Mon_password') La requte excute finalement sera la suivante: SELECT * FROM table_Clients WHERE champ_Nom=toto ; INSERT INTO table_Users VALUES ('Mon_login', 'Mon_password') Le rsultat est laffichage des donnes concernant le client toto, suivi par lajout dans la base de donnes dun utilisateur dont le couple login/mot de passe permettra lattaquant de se connecter lapplication comme un utilisateur authentifi. Le cas le plus simple dinjection SQL consiste sauthentifier dans une application Web en saisissant un login existant et nimporte quel mot de passe suivi de OR

1=1 . Attaques sur les identifiants de session

Contrairement au paradigme client/serveur traditionnel, le protocole HTTP est un protocole dconnect. Cest--dire quentre deux requtes successives, la connexion entre le client et le serveur est coupe. Le serveur ne peut donc pas reconnatre un client qui sest dj connect et qui a commenc une transaction dans lapplication Web. Pour remdier cela, la plupart des systmes dauthentification et de maintien du contexte des sessions Web des utilisateurs repose sur un identifiant de session, chang chaque page entre le client et le serveur, que ce soit au niveau du cookie, 3

Livrable 10/03/2011 de lURL ou dun champ cach de formulaire. Le serveur maintient un contexte de transaction pour chaque identifiant de session gnr. Une attaque classique consiste voler la session dun utilisateur qui vient de sauthentifier sur le systme en essayant de deviner la valeur de son identifiant de session. Si la valeur de celui-ci est dcouverte, un attaquant peut alors utiliser lapplication Web en lieu et place de lutilisateur lgitime en injectant lidentifiant rcupr dans sa propre session, laide dun proxy intrusif par exemple. Un identifiant de session se prsente par exemple ainsi :
HTTP/1.1 200 OK Date: Mon, 14 Oct 2002 09:17:22 GMT Server: Apache/1.3.26 Cache-Control: no-cache Pragma: no-cache Expires: Mon, 14 Oct 2002 09:17:22 GMT Set-Cookie: clePwd=deleted; expires=Sun, 14-Oct-01; path=/ Set-Cookie: session=0001WVWSDWAAAAB4EMYPBIB0NXA; path=/ Set-Cookie: SUP_COOKIE=OUI; expires=Tue, 14-Oct-03; path=/ Connection: close Content-Type: text/html

Si on essaie de rcuprer un grand nombre didentifiants successifs, on obtient par exemple les valeurs suivantes :
0001WVWSDWAAAAB4EMYPBIB0NXA 0001WV0WPSQAAACS4MYPBIAQZTY 0001WVXXHLQAAAB4YMYPBIB0NXA 0001WV2FYBYAAACUCMYPBIAQZTY 0001WV2VIRYAAACUKMYPBIAQZTY 0002YEQH5FYAAAPYWMYPBIAQ20I 0002YFAQGDYAAAPWMMYPBIAQ20I 0002YMUBB2AAABS4GMYPBIAQ20I 0003ZAM00NAAABV0AMYPBIA4JZQ

On remarque immdiatement que cet identifiant de session, dont le jeu de caractres est limit, semble cod en base 32, et quil possde de nombreuses parties fixes ou variant lentement. Aprs une analyse plus pousse, les parties fixes sont identifies comme tant des adresses IP et des ports. Enfin, il semble que des parties varient comme une horloge interne. A laide de ces simples constatations, il est possible de dvelopper un outil qui va nous permettre de diminuer considrablement lespace de valeurs de cet identifiant, et qui va automatiser la recherche dune valeur valide de celui-ci. On peut ainsi augmenter les chances de trouver une bonne valeur une sur 1000 3000, ce qui est extrmement peu : quelques minutes seulement permettront de voler la session dun utilisateur authentifi ! Il est donc indispensable de vrifier la qualit du gnrateur alatoire et ltendue de lespace de valeurs des identifiants de session de son application Web. Cette tendue doit tre suffisamment grande pour quune attaque en force brute ne puisse pas tre mene dans un dlai rduit. Il est dconseill dutiliser les fonctions de gnration didentifiants fournies en standard avec certains logiciels ou environnements de dveloppement du march (cf lexemple rel ci-dessus, obtenu avec un logiciel utilis dans le domaine bancaire). Il est parfois prfrable dcrire soi-mme une fonction de gnration des identifiants de session plus robuste, mais qui devra tre vrifie soigneusement.

Livrable 10/03/2011

Cross Site Scripting

Le principe du Cross Site Scripting (CSS ou XSS) est dattaquer les utilisateurs de lapplication plutt que lapplication elle-mme. Pour cela, lattaquant provoque lenvoi la victime, par le site Web lgitime, dune page hostile contenant des scripts ou des composants malveillants. Cette page est excute sur le poste de la victime, dans le contexte du site Web dorigine (Internet, sites de confiance, ), et dans le contexte de scurit de lutilisateur courant. Lexemple le plus simple est celui qui consiste provoquer une erreur HTTP 404 chez les victimes. Si le site www.mabanque.com ne filtre pas de faon correcte les donnes envoyes par les utilisateurs, un attaquant va saisir le texte suivant sur une page accde par dautres utilisateurs : <A HREF=http://www.mabanque.com/<script> alert(document.cookie)</script>">Click Here</a> Les internautes recevront la page suivante sils ont cliqu sur le lien ci-dessus : <HTML>404 Page Not Found:<script>alert(document.cookie) </script></HTML> Le script contenu dans cette page derreur 404 va provoquer laffichage des cookies relatifs au site www.mabanque.com. Il suffit un attaquant de les rcuprer pour se faire passer ensuite pour lutilisateur lgitime auprs du site de la banque.

Dautres attaques traversant les firewalls peuvent tre menes contre des applications Web :

Mcanismes dauthentification bass sur Java, JavaScript ou ActiveX : A viter : les applications utilisant ces technologies sont sujettes des manipulations effectues ct client permettant un attaquant doutrepasser le mcanisme dauthentification. 5

Livrable 10/03/2011 Contrle daccs bas sur le header HTTP_REFERER : A viter : la manipulation des headers laide dun proxy intrusif est facile. Manque de r-authentification : A viter : le manque de r-authentification au niveau de certaines fonctionnalits critiques (comme le changement de mot de passe par exemple) permet souvent un attaquant de prendre le contrle dun compte utilisateur. Mauvaise gestion du contexte utilisateur : La mauvaise gestion du contexte utilisateur peut permettre une augmentation progressive de privilges conduisant la prise de contrle total de lapplication par un attaquant. Il convient de contrler strictement et chaque page le contexte de scurit (lutilisateur est-il authentifi ? Quels droits a-t-il ?). Attaques ct client: Il sagit dattaquer directement les utilisateurs de lapplication plutt que lapplication elle-mme. Ce genre dattaques est rendu possible principalement par les langages excuts ct client :

L encore, il est indispensable de maintenir les navigateurs et clients mail jour et de les scuriser le plus possible. Man in the middle: Une attaque dite man in the middle consiste intercepter les requtes du client et les relayer vers le serveur distant lgitime et inversement intercepter les rponses du serveur et les relayer vers le client. Il est possible au passage, si ncessaire, de modifier la vole les donnes fournies par le client et/ou les rponses du serveur. Cette attaque est mme possible si le serveur de destination utilise un chiffrement par SSL : il suffit que le serveur intercepteur possde lui aussi un certificat serveur et que le client clique sur Accepter lorsque son navigateur lui propose dutiliser ce certificat pour dialoguer avec le serveur distant lgitime. Cest ce que fera tout utilisateur qui ne sera pas au fait des problmes de scurit. Il ne reste plus alors au serveur intercepteur qu dchiffrer dun ct et rechiffrer de lautre, la vole. Le seul moyen de se prmunir contre ce type dattaque est dimposer une authentification ct client par lutilisation de certificats clients X.509. Le serveur intercepteur ne pourra alors plus se faire passer pour le client auprs du serveur distant lgitime car il ne dispose pas de la cl prive du client. 6

VBScript Flash DHTML XML JavaScript Applets Java ActiveX CSS

Livrable 10/03/2011 Comparaison entre les produits WAF open source Les fonctionnalits demandes par un WEB APPLICATION FIREWALL La protection de lapplication ou du site contre les attaques WEB les plus courantes Secure Socket Layer (SSL). Lun des points les plus importants, en particulier pour les commerces en ligne ou toute personne ayant un site sensible, est la manire dont le firewall WAF que vous choisirez grera SSL. Dans la mesure o le trafic SSL est gnralement dlivr directement au serveur Web, Journalisation. Le firewall WAF est-il capable de consigner les connexions tant valides que non valides ainsi que les tentatives de connexion ? Peut-il supprimer des journaux les donnes sensibles telles que les informations personnelles concernant les clients en ligne et les donnes de carte de crdit ? Vous aurez besoin de ces fonctionnalits pour vos propres analyses, en plus de devoir probablement vous conformer diverses rglementations. Encombrement et performances.

Nous allons aborder les diffrentes solutions OPEN SOURCE qui existent sur le march : 1) Netcop NetCop intgre UTM open source, pare-feu, Antivirus ClamAV, cache Web, filtrage de contenu, IPS / IDS,Gestionnaire de liens WAN, gestionnaire de bande passante, anonyme bloqueur proxy, une connexion Wi-Fi contrleur, SSL VPN, et programmes de virtualisation de rseau en un seul pare-feu multifonctions. Type du firewall OS License Developper Multifonction ( SIF+WAF) Marche sut toutes les plates formes Linux/Unix Open Source NetcopProject

2) IronBee
IronBee est une nouvelle collaboration open source dontl'objectif est de construire un pare-feu d'application Web. IronBee mettra en uvre un robuste cadre pour la surveillance de scurit des applications et dfense, avec un ensemble de couches de caractristiques diffrents niveaux d'abstraction, permettant ses utilisateurs de choisir une approche qui fonctionnera le mieux pour le travail dont ils ont besoin pour accomplir. Le cadre fournit le point de dpart pour dterminer les caractristiques

Livrable 10/03/2011 exactes mettre en uvre. Type du firewall OS License Developper WAF inclus Open Source Qualys

dtection des attaques brutes ,(DoS / DoS distribues (DDoS) dtection), tmoin de cryptage / signature, la scurit des contenus, l'application des politiques, analyse des vulnrabilits passive, suivi de l'exprience utilisateur, et d'analyse syntaxique XML / de validation ; prise de dcision politique; adapt la dfense ; interaction avec les systmes de scurit externes (par exemple, les pare-feu) et les changes de donnes. 3) ModSecurity ModSecurity est un WAF open source pour Apache dvelopp par SpiderLabs Trustwave. Il permet de La surveillance du trafic HTTP, l'exploitation forestire et en temps rel. ModSecurity peut prendre en charge une varit de modles de scurit, y compris la scurit ngative modle (liste noire), modle de scurit positive(liste blanche), et les faiblesses connues, ModSecurity comprend un moteur de rgles souples qui implmente des lois qui sappuient sur un langage de programmation permettant de spcifier les rgles de politique pour traiter les donnes de transaction HTTP. ModSecurity est conu d'tre intgrable dans des applications existantes bas sur Apache Web serveurs, et peut tre dploy dans le cadre d'un Apache bas sur serveur proxy inverse. Type du firewall OS WAF runs on Linux, windows, Solaris, FreeBSd, openBSd, NetBSd, aIX, Mac oS X, HP-UX Open Source Trustwave SpiderLabs

License Developper

4) Vulture

Vulture est un reverse-proxy offrant des fonctions Web-SSO et firewall applicatif. Vulture est bas sur Apache2, mod_perl et mod_security. Vuture sinterface entre les applications Web et Internet pour offrir scurit et authentification unifie. Les principales fonctionnalits de Vulture sont les suivantes :
8

Livrable 10/03/2011

Lauthentification unique des utilisateurs avec de nombreuses mthodes supportes o LDAP, SQL, fichier texte, serveur radius, certificats numriques o Conception modulaire qui permet dajouter de nouvelles mthodes dauthentification La propagation de lauthentification sur les applications protges Le chiffrement des flux Le filtrage et la rcriture de contenu Un firewall applicatif bas sur ModSecurity La rpartition de charge

5) Squid Le but premier de SQUID tait de cacher les contenu web pour les petites infrastructures l'poque o les liaisons haut-dbit taient peu courantes et coutaient aussi trs chres. Ce soft permet aussi de faire l'inverse d'un proxy, savoir cacher du contenu gnr par un ou plusieurs serveur web pour des clients (comprendre visiteurs d'un site). L'apport premier de ce mode de fonctionnement est de permettre, par cette mise en cache, de soulager des serveurs web qui gnrent souvent le mme contenu pour diffrent visiteurs. De fait le temps processeur n'est pas gch a refaire continuellement les mmes choses qui n'ont pas t modifi et peut tre employ a d'autre chose (d'autre page gnrer), et permet de diminuer les couts serveurs.

Puisque Vulture contient un module concernant Modsecurity et un module concernant le SSO ( simple sign on ) , nous allons essayer de le configurer et de le tester en parallle avec une autre solution qui serait Squid .

Livrable 10/03/2011 La phase de test serait une opportunit pour tester les fonctionnalits de chaque produit et de trancher sur un solution finale qui va regrouper une ou plusieurs options.

Rfrences Firewalls Seventh Edition May 2 ,2011 http://www.chambet.com/publications/sec-web-apps/ http://www.vultureproject.org/

10