Livrable semaine

10/03/2010
Mise en place dune solution WAF base de
produits open source







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 .

Rdig par :Nasredine Boujmil
Encadr par : Mr Najib Bazza
Livrable 10/03/2011
2



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
3

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,
Livrable 10/03/2011
4

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
5

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.
Livrable 10/03/2011
6

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 :
VBScript
Flash
DHTML
XML
JavaScript
Applets Java
ActiveX
CSS
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.
Livrable 10/03/2011
7


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

Multifonction ( SIF+WAF)

OS

Marche sut toutes les plates formes Linux/Unix

License Open Source
Developper 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
8

exactes mettre en uvre.

Type du firewall

WAF

OS

inclus

License Open Source
Developper 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

WAF

OS

runs on Linux, windows, Solaris, FreeBSd, openBSd, NetBSd, aIX, Mac
oS X, HP-UX

License Open Source
Developper Trustwave SpiderLabs

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 :
Livrable 10/03/2011
9

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
10

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/