Aide à la Détection de Faiblesse d'un site web 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 1
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 de recherche active de faiblesse spécifique 2
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 3
Ne pas sous-estimer les enjeux : ADF : contexte 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 4
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 : ADF : contexte 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... 5
ADF : Principales attaques Les principales attaques : SysCall non contrôlés et Server Side Include Traversée de répertoire SQL Injections XSS CSRF 6
Appels système naïf : ADF : principales attaques Server Side Include 7
ADF : principales attaques Traversée de répertoire (directory traversal) Exemple wikipedia 8
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é! 9
XSS ou Cross Site Scripting : ADF : Principales attaques 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. 10
ADF : Principales attaques CSRF : Cross Site Request Forgery 11
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 12
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 13
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 /!\ 14
ADF : défenses passives Configuration Apache (suite) : Espace Web Total = {DocumentRoot VH } + {UserDir VH } + {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 15
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... 16
Conclusion sur Apache ADF : défenses passives 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 17
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 18
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 19
Rôle d'un mandataire (proxy) ADF : Mandataire 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) 20
Rôle d'un mandataire (proxy) ADF : Mandataire 21
ADF : Mandataire Rôle d'un mandataire inverse (reverse proxy) 22
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. 23
Inconvénients d'un mandataire inverse ADF : Mandataire 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 24
Apache en mandataire inverse ADF : mandataire 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 25
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 26
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. 27
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 they need» 28
mod_security permet de : ADF : mandataire filtrant 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 29
mod_security va plus loin! ADF : mandataire filtrant 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 30
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) 31
Audit «passif» : analyse du code ADF : défenses actives 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. 32
Audit «actif» : attaque du site web Wapiti Nikto Webfuzzer Webscan ADF : défenses actives Principes : Renvois des valeurs d'attaques connues Renvois des valeurs aléatoires (fuzzing) Recherche d'outils connus pour des faiblesses 33
Audit «actif» : Conclusion : ADF : défenses actives 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 34
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). 35
Les recommandations fortes : ADF : de bonnes pratiques 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) 36
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... 37
À retrouver sur le web Apache Références 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 38
Références Les documentations officielles de PHP (sécurité) MySQL sont une bonne base 39
ADF ANNEXES 40
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 41
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 42