1
Journée RAISIN 15/10/2009
Restitution de la formation ADF dispensée par l'UREC
Fabrice.Mendes@dr15.cnrs.fr
Développeur d'application web
Aide à la Détection de Faiblesse
d'un site web
ADF : plan
■
Introduction
■
Contexte
■
Principales attaques
■
ASR : défenses passives
■
ASR : défenses actives
■
DÉV : de bonnes pratiques
■
Conclusion
Nota : défenses passives : génériques et statiques, pas
3
ADF : introduction
■
À qui s'adresse cette reconstitution ?
Aux développeurs
Aux ASR qui adaptent des outils web
Aux ASR en blackbox
■
Défauts de cette présentation ?
Rapide survol
Pas de solution magique
Exemples autour de LAMP
ADF : contexte
■
Ne pas sous-estimer les enjeux :
Les sites web sont des portes d'entrées sur des SI internes parfois vitaux (confidentialité)
La réputation de l'établissement est une denrée critique
5
ADF : contexte
■
Ne pas sous-estimer les enjeux :
Les sites web sont des portes d'entrées...
La réputation de l'établissement...
■
Ne pas sous-estimer les méchants :
La cyberdélinquance ne dort jamais
Extrême professionnalisation de la cybercriminalité
➔ Moisson de données : vol ou crypto-chantage
➔ Squat : phishing, vente de pilules magiques
➔ Location de botnets
All your base are belong to us...
ADF : Principales attaques
Les principales attaques :
■
SysCall non contrôlés et Server Side Include
■
Traversée de répertoire
■
SQL Injections
■
XSS
■
CSRF
7
ADF : principales attaques
■
Appels système naïf :
■
Server Side Include
ADF : principales attaques
■
Traversée de répertoire (
directory traversal)
Exemple wikipedia
9
ADF : Principales attaques
■
SQL Injection
SQL Injection courante de bribe de requête
➔ Truc
➔ 'or 1=1 –
➔ => BINGO !
Ne se limite pas aux commentaires... Union
Permet de contourner des protections, lire, détruire...
Permet la prise d'empreinte du SGBDR
Même quand les messages erreurs sont filtrés il est possible d'extorquer des informations grâce au (deep) blind SQL injection.
S'en protéger correctement n'est pas aisé !
ADF : Principales attaques
■
XSS ou Cross Site Scripting :
Comment ça marche et pourquoi...
➔ Pour voler des cookies et donc une session
➔ Rediriger vers un site frauduleux (phishing (cas de hotmail le 01/10/2009 ??))
<IMG SRC=JaVaScRiPt:alert('XSS')>
<IMG """><SCRIPT>alert("XSS")</SCRIPT>">
<IMG
SRC=javascrip&
#116;:alert('XS
;S')>
<BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=alert("XSS")>
title body div img iframe href= etc.
11
ADF : Principales attaques
■
CSRF : Cross Site Request Forgery
ADF : Principales attaques
■
CSRF : Cross Site Request Forgery
Une attaque élégante, sans code « hostile »
Difficilement décelable par l'internaute victime
Difficilement décelable par le site victime si pas de contre-mesures
Avec un peu d'imagination le potentiel est énorme :
➔ Accès informations bancaire, réaliser un paiement ?
➔ Accès à l'infrastructure interne :
- Application ultra-sensible qu'on croyait bien au chaud ex Sirhus
- Accès aux interfaces d'administration d'éléments réseau (box)
Heureusement
➔ le méchant n'a pas forcément de retour
➔ Des contre-mesures simples peuvent être insérées dans le code
13
ADF : défenses passives
■
Scénario de l'ASR en boîte noire (hébergeur) :
Définition et maîtrise du périmètre
➔ S'approprier la configuration du serveur www
➔ Gestion de l'Espace Web Total
➔ Raffiner les droits et les accès du serveur
Ajout de « gardes »
➔ Un mandataire
➔ Un mandataire filtrant
ADF : défenses passives
■
S'approprier la configuration du serveur www
Comprendre la structure de la configuration Apache
➔ Les sections et la syntaxe (directory, files, location, virtualhosts, limit) + inclusion de fichier .conf
➔ Les priorités (par ordre croissant)
- <directory> et .htaccess
- <DirectoryMatch>
- <Files> et <FilesMatch>
- <Location> et <LocationMatch>
Pour des sections de même hiérarchie : ordre d'apparition
/!\ La directive AllowOverride peut permettre à l'hébergé de baisser le niveau de sécurité du serveur /!\
15
ADF : défenses passives
■
Configuration Apache (suite) :
Espace Web Total =
{DocumentRoot VH} + {UserDirVH} + {Alias}+{symlinks}
Gérés par les sysadmin, par les webmasters
Raffiner les droits du serveur Apache :
➔ Compte dédié
➔ Vérifier et limiter les répertoires en écriture voire chrooter
➔ Brider les possibilités des modules/interpréteurs (cf ci-après)
➔ Séparer les services : hôte virtuel et/ou machine virtuelle
➔ Pour aller plus loin, utiliser un RBAC :
- SELinux : complexe, frein à l'évolution
- AppArmor : plus limité que SELinux mais bien plus simple
ADF : défenses passives
■
Configuration Apache (suite) :
Logger... logger... logger
Limiter la fuite d'information due aux affichages des messages d'erreur auprès de l'internaute (en prod)
Se méfier des Handlers de multi-suffixes « .php.fr » ou sans suffixe « password.inc »
logger...
17
ADF : défenses passives
■
Conclusion sur Apache
Assez souple et complexe à la fois. Il faut un peu de temps pour le maîtriser
Peu s'avérer un faux ami :
➔ Règle écrasée par un .htaccess ou autre section
➔ .htaccess piraté et contenant une rewrite rule pernicieuse
La configuration par défaut est assez satisfaisante et la documentation sur la sécurité abondante
ADF : PHP
■
Durcir la configuration PHP :
Bannir php3 et register_globals (existe encore ?)
Utiliser le safe_mode si possible mais ce n'est pas suffisant !
Interdire les inclusions d'URL allow_url_include et allow_url_fopen...
Suppression magic_quotes_gpc
open_basedir
Pas de message d'erreur : display_errors
disable_functions (eval) disable_classes
dl() hardening
19
ADF : PHP
■
Durcir PHP :
Limiter les risques : suExecPHP permet d'avoir un UID par vhost
Patch Suhoshin
➔ Protection du moteur PHP (accès mémoire)
➔ Runtime protection (include, vhosts)
➔ Fonctionnalités de filtrage
➔ Protection transparente des cookies et sessions (chiffrement, anti-hijack)
➔ Fonctionnalités de journalisation
ADF : Mandataire
■
Rôle d'un mandataire (proxy)
Le mandataire peut stocker les réponses pour lees retransmettre directement à la prochaine requête identique. (cache)
Filtrage applicatif : il peut supprimer un contenu non autorisé ou hostile dans sa réponse au client
Anonymat/sécurisation du réseau
Journalisation des requêtes (LCEN)
Implémentations connues : Squid, Apache, SSH (pouvant implémenter SOCK5)
21
ADF : Mandataire
■
Rôle d'un mandataire (proxy)
ADF : Mandataire
■
Rôle d'un mandataire inverse (reverse proxy)
23
ADF : Mandataire
■
Rôle d'un mandataire inverse (reverse proxy)
Point d'entrée unique (un seul port 80 à ouvrir vers l'Internet) => journalisation plus efficace ou pas
Accélération de requêtes aux sites dynamiques (Zope)
Répartition de charge entre plusieurs serveurs web
Cloisonnement des services web (wiki, cms, agenda)
Filtrage et réécritures des requêtes (=> protection en amont contres les failles)
Occultation de la topologie interne du réseau et
« enfouissement » des serveurs web et des bases de données.
ADF : Mandataire
■
Inconvénients d'un mandataire inverse
Point d'entrée unique => s'il faillit, tous les sites tombent
Complexification du réseau
Rupture des communications HTTPS qui ne peuvent plus se faire de bout en bout (par ailleurs problème de https et virtual host)
Gestion des redirections fastidieuse et source d'erreur
25
ADF : mandataire
■
Apache en mandataire inverse
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so ProxyRequests Off
<Proxy *>
Order deny,allow Allow from all
</Proxy>
ProxyPass /wiki http://wiki.monlabo.interne
ProxyPassReverse /wiki http://wiki.monlabo.interne ProxyPass /cms http://cms.monlabo.interne
ProxyPassReverse /cms http://cms.monlabo.interne
■
www.monlabo.fr/cms
ADF : mandataire
■
Pour les cas plus complexes : mod_rewrite
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On
RewriteRule ^/wiki/(.*)http://wiki.monlabo.interne/$1 [P]
ProxyPassReverse /wiki http://wiki.monlabo.interne
RewriteRule ^/cms/(.*) http://cms.monlabo.interne/$1 [P]
ProxyPassReverse /cms http://cms.monlabo.interne
27
ADF : mandataire filtrant
mod_security est un module pare-feu applicatif d'Apache. Il protège les sites web d'une collection d'attaques classiques.
D'un abord assez rugueux il fournit de base un
ensemble de règles très efficace mais quelque
peu consommateur de ressources.
ADF : mandataire filtrant
5 phases pour tout changer
➔ Entre l'entête et le corps
➔ Après le corps requête
➔ Avant en-tête réponse
➔ Avant corps réponse
➔ Durant log
« Empower users to do what
29
ADF : mandataire filtrant
mod_security permet de :
Détecter des violations du protocole HTTP
Réagir aux anomalies comme l'absence du UA ou de la clause Accept
Bloquer des robots
Se protéger d'un coup contre un lot d'attaques génériques :
➔ Injections PHP
➔ Injections SQL
➔ Exposition de fichiers sensibles
➔ Filoutage sur l'encodage des caractères
Bloquer le dépôt de chevaux de Troie sur le serveur
Jouer avec les crawlers
ADF : mandataire filtrant
mod_security va plus loin !
On peut protéger une application contre une injection SQL en créant une liste blanche de valeurs pour id (valeur entière)
http://site.org/appli/index.php?id=3
SecRule ARGS:id "!(^[0-9]*$)" log,deny,status:403
http://site.org/appli/index.php?file=home.php
SecRule ARGS:file "!(^(home|liens)\.php$)"
log,deny,status:403
31
ADF : mandataire filtrant
■
Un WAF permet donc de protéger une application même en blackbox
■
Les WAF sont en plein essor mais déjà attaqués
Wafw00f
Waffun
WIMP (Wafs are for Idiots Management Person)
ADF : défenses actives
■
Audit « passif » : analyse du code
Rats : analyse PHP mais aussi d'autres langages.
Fork de rats : spike_phpSecAudit
■
Pas d'analyse très fine (grep-like) mais permet de mettre le doigt rapidement sur les parties à code dangereux (recherche de fonctions). Fait ressortir le code dupliqué.
■
Ne tient pas compte de la configuration du
serveur, du code mort ou obscurci.
33
ADF : défenses actives
■
Audit « actif » : attaque du site web
Wapiti
Nikto
Webfuzzer
Webscan
■
Principes :
Renvois des valeurs d'attaques connues
Renvois des valeurs aléatoires (fuzzing)
Recherche d'outils connus pour des faiblesses
ADF : défenses actives
■
Audit « actif » : Conclusion :
Wapiti : très convaincant sur un formulaire très simple, beaucoup moins sur une application en ligne qui fait un minimum de tests (application non blindée).
Tests longs souvent pour pas grand-chose.
Nécessite des sites de test car risque de crash
=> si on peut, il vaut mieux éprouver des formulaires représentatifs de l'application à tester que toute
l'application. Ce n'est pas « parfait » mais au moins on avance.
Faire du googlehacking contre soi peut-être tout aussi instructif
35
ADF : de bonnes pratiques
■
Pour les développeurs, les quasi-lois :
Réduire les angles d'attaque : tout filtrer, tout assainir.
Ne jamais faire confiance à la moindre donnée externe (GET/POST/COOKIE)
N'autoriser que les variables attendues et en vérifier la validité
Mettre dans le DR que le strict nécessaire. « include » du reste toujours possible...
Ne mettre dans l'espace de prod que le strict
nécessaire (pas de scripts puissants mais non filtrés de bricolage)
Limiter les espaces rw et les placer hors DR
Gestion intelligente des erreurs (log, pas echo)
Accès en aux données sensibles (mdp) que par authentification forte (mdp ou email fixe).
ADF : de bonnes pratiques
■
Les recommandations fortes :
Limiter l'accès aux populations concernées si possible
Renouveler très souvent les SessionID (chaque fois)
Pas de formulaire sans jeton anti-CSRF
Attention aux race-conditions sur les fichiers générés et leurs droits d'accès
Limiter les dégâts en cas de compromission (pas de stockage de mot de passe en clair par ex)
Favoriser l'usage de frameworks éprouvés (synfony, RoR)
Tests Unitaires !
Envisager la sécurité dès le départ et toujours y songer (se défier des logs produits si on les consulte par le web)
37
ADF : conclusion
■
De nos jours, les machines sont une denrée très précieuse
■
Cette présentation est trop rapide, des solutions ne sont d'effleurer du bouts de lèvres
■
Les sujets sont assez vastes, rien ne vaut la pratique
■
La sécurité est souvent la laissée pour compte !
Ne laissez pas ces informations s'envoler...
Références
■
À retrouver sur le web
Apache
➔ http://math.univ-angers.fr/~charbonnel
➔ http://httpd.apache.org/docs/2.2/misc/security_tips.html
PHP
➔ « Forum PHP 2007, Audit de code, retour d'expérience », Nicolas Collignon et Louis Nyffenegger
➔ « State of the Art Post Exploitation in Hardened PHP Environments », Stefan Esser, Blackhat USA2009
WAF
➔ « Web Application Firewall (WAF) », Sébastien Gioria, FRHACK, Besançon le 7 septembre 2009
39
Références
■
Les documentations officielles de
PHP (sécurité)
MySQL sont une bonne base
ADF
ANNEXES
41
ADF : annexe Wapiti 1-2
http://wapiti.sourceforge.net/example.txt
First I use getcookie.py to login in the restricted area and get the cookie in cookies.txt
bash-3.0$ python getcookie.py cookies.txt http://127.0.0.1/vuln/?page=login Please enter values for the folling form :
url = http://127.0.0.1/vuln/login.php login (on) : toto
password (on) : toto
0 : <Cookie PHPSESSID=8qte5k7jr6ogkocrlcrk9obmj2 for 127.0.0.1/>
Then I scan the vuln website using the cookie and excluding the logout script bash-3.0$ python wapiti.py http://127.0.0.1/vuln/ -c cookies.txt -x
http://127.0.0.1/vuln/index.php?page=logout ...
Attacking urls (GET)...
---
Warning fread (article) in http://127.0.0.1/vuln/
Evil url: http://127.0.0.1/vuln/?article=http%3A%2F%2Fwww.google.fr
%2F&page=articles
ADF : annexe Wapiti 2-2
Attacking forms (POST)...
--- SQL Injection found with
http://127.0.0.1/vuln/login.php
and params = login=%27% 22%2&password=on
coming from http://127.0.0.1/vuln/?page=login SQL Injection found with
http://127.0.0.1/vuln/login.php
and params = login=on&password=%27%22%28
coming from http://127.0.0.1/vuln/?page=login
