cloud's Blog

La bande passante et les ressources d'une machine constitue un bien qu'il faut conserver afin d'assurer une disponibilité optimale. Cependant certaines actions qui peuvent paraitre anodines influent fortement sur cette bande passante comme par exemple l'utilisation d'images de notre site web directement sur un autre site. Ainsi quand le visiteur arrivera sur la page web de la personne cela viendra directement taper sur notre serveur qui fournira de la bande passante et ralentira donc les connexions directes vers notre site.

Afin de limiter cela il est possible d'utiliser une option d'Apache, le Rewriting. Voici un exemple afin d'empecher le site www.example.com d'afficher nos images en lui affichant l'image de quelqu'un d'autre :

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^.*www.example.com.*$ [NC]
RewriteRule .*\.(gif|jpg|jpeg|bmp|png)$ http://www.unautresite.com/image.jpg [L]

Pensez a bien redémarrer Apache pour que cela soit pris en compte.

Comme je l'ai dit dans le précédent article, un audit de conf est une phase très important afin de se prémunir d'erreurs de code ou de failles au niveau de l'interpréteur. Pour ce 1er article la dessus, je donnerai quelque points à vérifier pour l'interpréteur PHP en controlant le php.ini .

Cacher l'interpréteur

Il est tout a fait possibler d'utiliser une autre extension que .php dans apache pour des pages PHP. Cependant les développeurs ont placés certaines options pour le fun je présume qui peuvent révéler l'utilisation de PHP comme l'exemple suivant :

 http://www.madpowah.org/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 

Pour éviter cela, on peut empécher d'afficher ces pages avec une option :

 expose_php = Off 

Register_globals

Cette options par défaut à off doit le rester si possible. Elle permet d'empêcher l'utilisation de variables globales à mauvais escient, en utilisant par exemple un GET pour surcharger un POST ce qui pourrait conduire à une faille assez importante. Donc ici il vaut mieux avoir :

 register_globals = off 

Safe mode

Le safe mode permet d'empêcher l'accès à tout fichier dont le propriétaire n'est pas l'utilisateur Apache. Cela peut poser parfois des problèmes avec certaines applications mais il faut le laisser actif. Cette option n'est plus présente dans PHP 6.

 safe_mode = on 

Il est possible de laisser l'utilisateur que l'on souhaite et de mettre plutôt un contrôle sur le GID qui lui doit etre le groupe Apache de la manière suivante :

 safe_mode = Off 
safe_mode_gid = On 

Il y a de nombreuses options safe_mode que vous pouvez visualiser ici.

Limiter le champs d'action de fopen()

fopen() est une des fonctions PHP qu'il faut le plus contrôler car elle permet des actions dangereuses :
-ouvrir un fichier sur le serveur
-ouvrir une url
-écrire dans un fichier

Pour contrôler son champs d'action, php.ini propose plusieurs options.

Tout d'abord on peut interdire l'ouverture d'une url avec l'option suivante :

allow_url_fopen = Off

Ensuite on peut limiter là ou il pourra écrire avec l'option suivante :

open_basedir = /var/www/htdocs/files

Enfin pour les memes raisons, il vaut mieux restreindre l'ouverture d'url via la fonction include() :

allow_url_include = Off

Gestion des erreurs

Les erreurs révèlent souvent beaucoup d'informations que l'utilisateur ne doit pas forcèment voir. Les erreurs sont intéressantes en phase de développement mais il est préférable de désactiver leur affichage par la suite et de les stocker dans un fichier texte. Pour arriver à cela il est nécessaire d'utiliser les 2 options suivantes :

display_errors = Off
log_errors = On

Limiter les fonctions

Un dernier point que je traiterai ici (il y'en a beaucoup si on rentre dans le détail) est la possibilité de restreindre certaines fonctions dont on a pas utilité comme les fonctions d'exécution system() ou exec(). On les bloquera de cette maniere :

disable_function = system,exec,passthru,shell_exec,fsockopen

Conclusion

Il est nécessaire de bien connaitre les options de son interpréteur et de limiter au maximum le champs d'action des fonctions quite à les réactiver par la suite en cas de problème. De plus l'offuscation est la 1ere étape de la sécurité. Moins on en dit, plus le pirate aura du mal à cibler son attaque.

Pentest, le test d'intrusion ultime ?

Beaucoup de personnes voient dans le pentest le test ultime pour s'assurer de la sécurité de son applicatif. Hors est ce vraiment le cas ? Personnellement je ne pense pas et je vais vous expliquer pourquoi.

Un pentest consiste à tester les vulnérabilités d'un applicatif à un instant T. Le pentest dépend de plusieurs critère :
-le pentesteur qui va effectuer le test. Celui-ci peut avoir un niveau d'expérience très varié et être efficace avec certaines technologies mais pas toutes. Du coup on risque de se retrouver avec un compte rendu de vulnérabilités assez aléatoire et qui pourra différer selon l'auditeur.
-Le temps attribué pour le test de vulnérabilité. En effet plus on aura de temps et plus on pourra tester en profondeur l'applicatif et faire défilé notre batterie de test.
-Le mode utilisé. Il existe 3 modes : le blackbox (à l'aveugle, sans indication du client), en greybox (avec quelques informations client (infrastructure, règles de filtrage…) ou en whitebox (le client nous donne toutes les informations que l'on souhaite (code source, schéma réseau, habilitations …). Du coup selon le mode on va se retrouver avec des résultats variés.

C'est pour ça que je pense que le pentest n'est qu'une fin en soi d'un ensemble de test afin de déterminer le niveau de sécurité d'une application sans pouvoir le garantir dans le temps.

Pour cela il existe d'autres audits qui vont renforcer la garantie sécuritaire. Une application est un logiciel reposant en général sur un serveur et qui possède des fonctions. Le pentest va permettre d'analyser les fonctions. Il reste à analyser le logiciel ou plus précisément son code source et le serveur par un audit de conf.

En effet l'audit de code va permettre d'analyser en détail le fonctionnement de sécurité de certaines applications. En effet un pentest ou l'utilisation d'un outil d'intrusion ne verra jamais un chiffrement faible (ex : base64) alors que la visualisation du code le montrera directement. De plus les fonctions dites critiques seront immédiatement identifiées et revues.

De meme analyser la configuration d'un serveur permet de se prémunir d'une faille en analysant la version ou le choix des options choisies (modules activés mais non utilisés, interprétation d'une extension d'une manière spéciale ou droits de l'application). Ceci va permettre de se prévenir de futurs attaques que le pentest ne pourra pas forcément voir à l'instant T car le module utilisé pour analyser l'application ne test pas encore l'exploit qui permettrait de rendre vulnérable notre application.

Pour conclure, je dirais qu'un vrai audit d'application ne se résume pas à un test de vulnérabilités mais à analyser son code source, sa configuration et enfin contrôler son fonctionnement via un pentest.

Bon audit :)

Je ne sais pas si la crise a modifié le monde de la sécurité mais je trouve que du coté des pirates, il y a un laissé aller général.

En effet les tendances actuelles vont plus a la rentabilité immédiate qu'a de réelles prouesses techniques. Vous me direz que c'est un peu normal, les systèmes de protection évoluent, la sensibilisation sur le code "sécure" fait son effet meme si les audits de code sont encore trop peu généralisés. Du coup les pirates s'attaquent directement a la base la plus fragile : les utilisateurs. Autrefois il semblait plus normal de s'attaquer a un serveur et d'en récolter le maximum d'information, maintenant ceux ci ne servent plus que de passerelles pour polluer nos boites de messagerie de mails de phishing ou de scam. Sur le tas envoyé, il y aura toujours un client qui va y répondre ... quoi que de moins en moins...

Pourquoi ?
-Tout d'abord les sites de phishing (ou scam) sont souvent créés par des hackers étrangers et apparement ils n'ont pas compris que les gens ne font confiance que si le francais est bien écrit. Donc avis aux pirates turcs, marocains ou russes (et meme francais), avant de faire une attaque apprenez notre langue :)
-Deuxiemement nous, en parlant ici des gens du monde de la sécurité des systemes d'information, sommes un peu habitués a fermer rapidement ces sites et a appliquer tres vite les contre mesures nécessaires pour prévenir les clients impactés (quand il y'en a)
-Les gens sont sensibilisés. En effet a force de recevoir ce genre de mail et bien les gens ont été senbilisés et n'y pretent plus attention. Cette technique marchait tres bien dans les années 90 (me demandez pas comment je le sais :p ) mais de nos jours ...Quoi qu'on voit encore quelques élus américains ou quelques stars se faire piéger donc bon ...
-Enfin 99% des sites de scam proviennent de Cote d'Ivoire. Vafalloir innover un peu car on commence a avoir l'habitude !

Donc pourquoi ces attaques ? Tout simplement car le piratage est devenu un business et non plus un art comme dans le passé. Bizarrement on a l'impression de se retrouver 15ans en arriere avec des affaires de vols d'identité, de phishing, en gros de techniques de Social Engineering qui ont par exemple fait la renommé de célebres Hackers comme Kevin Mitnick alias le Condor, sauf que lui le faisait avec classe et innové dans le genre.

Autre mode de piratage que je constate c'est les pièces jointes comtaminées. En effet on retrouve un nombre incroyable de fichiers dans lesquels on insere du code pour planter la encore un logiciel client. Ainsi les fichiers PDF, XLS, MP3, JPG, et ont été testé pour faire un beau Buffer Overflow sur un logiciel que l'on retrouvera chez Mr tout le monde (Excel, Adobe Acrobat, lecteurs audio/video divers...) et ainsi le comtaminer.

Faute est donc de constater le hack technique est devenu réservé a une certaine élite car de plus en plus complexe. Du coup peu de personnes peuvent prétendre contourner des systemes et si elles le font, ne sont pas intéréssées par une action illégale mais plus par du Proof of Concept et aura plus tendance a publier dans un magasine dédié ou sur le net et finir par se faire embaucher par une boite de sécu :).

Malgré cette phase, je pense que celle ci est transitoire, car en effet une fois les gens sensibilisés et tous les logiciels protégés pour la lecture des différents fichiers contaminés et bien il faudra trouver autre chose :). La on retrouvera surement des hack beaucoup plus techniques et peut etre donc une forte baisse de gamins script kiddies pollueurs d'internet tout juste capable de cliquer sur un bouton !

Heureusement que quelques perles subsistent comme le magnifique Confiker qui malgré le temps continue a faire couler de l'encre ...

Bref affaire a suivre !