Security bugs hunter =)

    août 25th, 2009

    Depuis quelques semaines à raison d’une à deux heures par jour, je me suis lancé dans un petit projet histoire de me faire un peu la main avec jQuery et la programmation objet en PHP5. J’ai donc décidé, dans le cadre d’un audit (un script troué de partout dont je dévoilerai le nom dans quelques temps) de réaliser un script permettant l’indexation des failles trouvées lors d’audit d’applications WEB.

    Ce script s’appelle Security Bugs Hunter et permet donc l’indexation de vulnérabilités suivant des scripts, avec la possibilité d’enregistrer le code vulnérable, le Proof of Concept de la vulnérabilité, des combos de vulnérabilités etc. Il possède par ailleurs un système de membres ayant plusieurs permissions, permettant ainsi au super administrateur de les régler suivant la confiance qu’il possède envers les abonnés.

    Bref, le script aujourd’hui est beau certes, mais très pauvre en fonctionnalités (au pire, c’était juste pour me faire la main sur jQuery pour passer ensuite à autre chose…). Bref, je pense rajouter différentes petites choses telles que la possibilité d’Uploader l’application à auditer (et d’indexer ensuite par versions), de rechercher dans son code des vulnérabilités potentielles à grand coup de Regex (ce qui va ralentir un max.) et différentes choses.

    Si vous voulez voir ce que cela donne, c’est par ici. Je mettrai le code source à télécharger dans quelques jours, histoire de bien le commenter et de l’alléger avec un peu de docs. (en y allant, vous gagnerez des 0dayz sur un script =)

    Jolicloud, installation sur VMware et premières impressions

    août 21st, 2009

    Jolicloud est un système d’exploitation orienté web basé cloud computing et réseaux sociaux, multimédia. Il est développé sur une base Ubuntu et est depuis quelques temps disponible en version Alpha (privée) permettant ainsi à diverses personnes de le tester, de déceler des bugs et de dire leur avis sur le système. Bref, le système en lui-même est sympa même si je trouve qu’il ressemble encore trop à Ubuntu sans parler de quelques défauts dans le graphisme (qui j’espère vont changer, car le menu sur fond noir est vraiment moche). Au pire ce n’est qu’une alpha donc il y a encore du temps avant sa vraie sortie donc je ne m’inquiète pas trop pour cela.

    Personnellement, j’ai installé jolicloud sur une VMware permettant ainsi de faire différents tests sans réellement l’installer en dur et pouvoir ainsi facilement faire des tests réseaux, sécurité (je vous en parlerai plus tard, après que certaines découvertes soient corrigées) etc. Donc, vu que beaucoup de personnes se demandent comment l’installer sur une VMware et bien je vais vous montrer comment faire (c’est simple…). Mais le mieux est tout de même de le tester sur un netbook, afin de voir réellement la qualité de ce dernier comparé aux autres « Netbook os ».

    Donc pour l’installer sur une VMware, vous créez tout d’abord une nouvelle machine avec un Linux 2.6 lambda, environ 512Mo de mémoire vive histoire que cela aille vraiment vite pendant le Boot. Après avoir créé votre machine, vous allez dans les préférences (settings) afin de changer les options de disques durs, vous supprimez l’ancien que vous avez créé. Enfin, vous en rajoutez un avec l’option « use physical disk » et sélectionnez votre clé USB, si vous ne savez pas laquelle c’est, vous avez juste à en sélectionner un puis ensuite regarder la taille du disque. Puis vous refaites un autre disque dur virtuel.

    Et voilà, maintenant, vous allez pouvoir booter Jolicloud sur votre clé USB depuis VMware (mais aussi toutes les distributions Linux liveUSB).

    Twitter et un point sur la sécurité du « tout-ouvert »

    août 21st, 2009

    Suite au piratage de la firme Twitter ayant eu lieu il y a quelques mois et faisant encore maintes et maintes rebondissements aujourd’hui, il est primordial de faire un point sur la sécurité de ce que je qualifie de « tout-ouvert » mais que l’on pourrait par ailleurs appeler le « tout-API ».

    Aujourd’hui, de plus en plus de services et de réseaux sociaux misent sur les API pour permettre aux utilisateurs une réelle appropriation de leur service et ainsi, récolter un maximum de membres. Le piratage de Twitter n’est en aucun cas lié au « tout-API », mais aux vulnérabilités du could-computing et surtout à la capacité des administrateurs de Twitter de faire confiance à un système vulnérable en soi. D’ailleurs, je ne comprend pas encore pourquoi ils laissent aux yeux de Google (un de leurs concurents) par l’intermédiaire de GoogleDocs des documents confidentiels et extrêmement préjudiciables pour leur entreprise…

    Cependant, ce piratage amène à s’intéresser aux services professionnels et amateurs développés en parallèle des sites web 2.0 grâce aux différentes API mises à disposition par les développeurs. Ces derniers présentent de nombreuses vulnérabilités, pas uniquement liées aux vulnérabilités lambda du type XSS permettant le vol de compte des membres. Elles peuvent se transformer être de véritables risques, tant pour les utilisateurs, que pour d’autres sites Internet pouvant par l’intermédiaire du piratage de ces services subir de véritables DDos ou être le relai d’attaques plus pointues.

    1. Vulnérabilités

    Bref, voilà ce que l’on peut dire sur les types d’attaques dont peuvent être victimes les différents services et ce que cela peut engendrer pour les victimes :

    • Vol de session permettant, selon le type de configuration du service, de poster certaines informations à la place de l’internaute. Et peut-être, de pouvoir de fil en aiguille s’identifier totalement sur le site source produisant l’API à la place de l’internaute.
    • Attaque MIM, récupération des identifiants. Une large partie des services utilisant les API de certains réseaux sociaux demandent à l’internaute de s’identifier sur leur site – pour pouvoir, par exemple, poster un message à la place de l’internaute automatiquement -. Cependant, ces identifications sur certains services (une majorité) n’utilisent pas un protocole sécurisé -SSL- pour transmettre les identifiants du client vers leur serveur, permettant ainsi l’interception de ces derniers dans un réseau local. Ainsi, cela permet de contourner pour un pirate le https mis en place par certains réseaux sociaux pendant l’identification de leur membre.
    • Vulnérabilités lambda des services web Entre SQLi, XXS, CSRF, failles « d’upload », includes locales, injections dans des fichiers etc. Nous pouvons trouver de tout sur les services rattachés aux APIs de certains réseaux sociaux. Ceci permettant de faire un peu ce que l’on veut (ouverture d’un shell, mise en place d’une backdoor sur les différents serveurs, piratage des bases de données etc.). Cependant, les pirates auront – je pense – une attention toute particulière pour backdoorer les mécanismes d’identification des membres afin de récupérer les identifiants de ces derniers. Ils attaqueront – suivant leurs envies – ensuite les sessions des membres sur le réseau social promulguant les API, mais également testeront les mots de passes récoltés sur différents sites où les membres se sont sans doute inscrits ainsi que sur les webmails. D’autres s’amuseront peut-être avec la récupération des identifiants à inonder les services de micro-blogging de messages…
    • Hijacking des URLs Cette vulnérabilité pèse surtout sur les shorteners d’URL du type bit.ly ou tinyurl.com. Imaginez ce que peut ressentir un site internet étant pointé par des millions d’URLs potentiellement cliquables plusieurs fois par des utilisateurs. Le problème est à relever et la sécurité des shorteners d’URL est aujourd’hui un point critique auquel il faut faire très attention. D’ailleurs, ce problème est déjà arrivé au service Cligs, re-dirigeant deux millions d’URL vers un seul site… qui n’a pas tardé à tomber. Voir un article à ce sujet ici ou .

    2. Contre-mesures

    Les contre-mesures à appliquer sont assez simples pour les utilisateurs de réseaux sociaux, utilisez au minimum des services bâtis sur les API de certains services web, surtout quand ces derniers demandent une identification n’étant pas sécurisée. Il faut aussi essayer de deviner quels services sont susceptibles de garder dans leurs bases de données vos mots de passes en clair (cela est déductible assez facilement, si vous vous inscrivez à un service qui agit régulièrement sur votre Twitter sans votre intervention (transposition de flux RSS etc.)).

    Pour ce qui est des développeurs de services reposant sur des API, engager un hacker/pirate/spécialiste (rayez la mention inutile) reste la meilleure solution afin de tester les différentes vulnérabilités qui peuvent siéger dans le système. Après libre à eux de le faire ou non, cependant la qualité de service risque à tout moment de passer à la trappe si des audits de sécurité ne sont pas faits régulièrement sur les différentes sphères du système d’information régissant le webservice. (acteurs, physique, application).

    3. Conclusion

    Tout comme les plugins pour les CMS, les services utilisant des API de certains sites communautaires répandent leurs vulnérabilités au grès de leurs créations augmentant ainsi les risques de rendre tout un système vulnérable. Cependant, ces vulnérabilités (et c’est là toute la chose) ne se concentrent pas au seul site internet du service utilisant l’API d’un énième site communautaire, mais peuvent être utilisés contre les utilisateurs des sites communautaires et contre d’autres sites internet.

    Je pense que Twitter – même si la sécurité n’est pas leur fort – (ou d’autres sites communautaires) devraient avoir le droit de jeter un coup d’oeil sur les sources des scripts et des serveurs sur lesquels reposent les services utilisant leur API. C’est tout de même les utilisateurs du site internet diffusant les API les premiers attaqués. Bref, j’espère que cette petite parenthèse vous à un peu informé sur les risques du « tout-API » même si je n’ai pas énuméré l’intégralité des failles (ce qui est en soit impossible). Je prédis cependant une hausse significative des piratages de comptes utilisateurs par l’intermédiaire de ces services dans les prochains mois. D’ici là, prenez garde à vous ! NIARK :D

    Knock Knock Neo – Installation de port-knocking sur une BOX

    août 21st, 2009

    Le port-knocking est une technique assez méconnue des administrateurs serveurs, cependant, elle est l’une des meilleures afin d’établir des règles dynamiques de Firewall tout en étant extrêmement simple à mettre en place sur un serveur. Cette technique peut aussi servir à exécuter d’autres commandes et à démarrer des services, sans pour autant avoir un shell sous la main. Ce petit article va faire une brève description de ce qu’est le port-knocking, et ensuite, la mise en place de ce dernier sur une Ubuntu/Debian (la configuration ne change pas, seule l’installation change selon les distributions.)

    1. Port-knockwa ?

    Même si ce nom est assez barbare pour un français, son sens est devinable en deux secondes. Il veut littéralement signifier frapper sur les ports (…pour ouvrir la porte). En deux mots, c’est comme dans tous les films d’espionnage amateurs, on toc à la porte selon une certaine séquence afin que la personne étant derrière la porte sache que c’est vous pour venir l’ouvrir (voir le film Léon…).

    Cette technique, passée à la moulinette informatique se traduit par la modification des règles de Firewall à la volée, suite à l’envoi par un client d’une séquence de paquets SYN sur différents ports de la BOX. Par exemple, la séquence de paquets SYN sur les ports 45324, 15432 et 23942 changera les règles d’Iptables afin d’accepter la réception de paquets sur le port 22 provenant de l’IP source (envoyant les paquets SYN). Nous ferons une autre séquence afin de refermer la porte derrière nous à la fin de notre session SSH.

    2. L’intérêt du port-knocking

    L’intérêt est simplement d’interagir avec le serveur sans passer par une connexion distante, ainsi, nous pouvons ouvrir un service, changer son état ou modifier les règles de son fonctionnement. Il est principalement utilisé par pour manipuler les Firewalls afin d’ouvrir des ports prétendus bloqués. Ceci permettant ainsi d’éviter les attaques sur certains services par des Botnets remuant un peu trop les logs, ou des attaques ciblés contre votre box se faisant à la main.

    La chance de tomber par hasard sur la bonne combinaison pour un pirate est extrêmement petite (pour vous faire une petite idée) :

       * 65535^2 = 4 294 836 225 possibilités
       * 65535^3 = 2.81462092 × 10^14 possibilités
       * 65535^4 = 1.84456182 × 10^19 possibilités
       * etc...

    Autant vous dire que cette protection va limiter grandement le pirate dans ses tentatives d’attaque tellement les possibilités sont énormes, cependant, il existe quelques faiblesses matérielles et humaines à cette technique.

    3. Faiblesses

    Il existe deux principales faiblesses à cette technique de port-knocking. Tout d’abord, la possibilité pour un attaquant d’effectuer une attaque Man In The Middle (Monkey in the Middle pour les intimes) en local permettant ainsi de récupérer la séquence dans le flot de données en sniffant simplement la connexion.

    Une seconde vulnérabilité est plus imputable à l’humain, ainsi, nous avons pas un random service intégré dans notre cerveau donc souvent, un pirate expérimenté pourra tenter de deviner les numéros de ports employés par l’administrateur, souvent des multiples ou une séquence facilement mémorisable. (sans parler de l’administrateur qui laisse par défaut la séquence contenue dans le fichier de configuration après installation ou la lecture d’un tutoriel…).

    Nous pouvons aussi noter d’autres faiblesses où le pirate doit avec accès au client exécutant knockd, ainsi, si l’administrateur ne supprime pas ses logs de sessions sur le terminal, le pirate pourra avoir la suite des ports en faisant un petit $cat .bash_history

    Après avoir vu les faiblesses, nous allons passer à l’installation et la configuration du serveur, puis ensuite, l’utilisation du système de port-knocking avec un client.

    4. Installation et configuration

    Vu que nous n’allons pas réinventer la roue, nous allons utiliser un logiciel déjà développé afin de mettre en place la solution de port-knocking, son nom : knockd. L’installation (sur une Débian) se fait facilement avec un petit :

       * (# | sudo ) apt-get install knockd

    Cela va installer proprement (et tant mieux…) le programme. Après, nous allons passer à la configuration de la chose, vous allez voir, c’est d’une simplicité détonante. Donc c’est parti, tapez dans votre shell (je sais, j’utilise nano et j’aime ça) :

       * (# | sudo ) nano /etc/default/knockd

    Hop, là dans ce fichier knockd nous allons configurer le demon afin qu’il sache sur quelle interface réseau écouter et s’il doit s’exécuter au démarrage de la machine. pour ce faire, il suffit simplement de mettre :

       * START_KNOCKD=1 # Ainsi il démarrera au démarrage de la box
       * KNOCKD_OPTS="-i [votre interface (eth0, eth1 etc.)]"

    (si vous ne savez par votre interface, faites un petit ifconfig et regardez…) Arrivé à ce point là, nous sommes déjà bien partis, le demon peut fonctionner, reste maintenant à éditer les règles, pour cela, go to :

       * (# | sudo ) nano /etc/knockd.conf

    Et éditez vos rêgles simplement en faisant :

       * [Nom de la rêgle]
       * sequence = XXXXX, XXXX, XXXXX [séquence des ports]
       * seq_timeout = 5 [quant-est-ce que la séquence est "finie"]
       * command = /sbin/iptables (+règles) [commande à exec.]
       * tcpflags = syn

    Par défaut, les ports de la séquence sont en TCP, mais on peut s’amuser pour compliquer encore l’affaire à alterner TCP et UDP en faisant : XXX:tcp, XXXXX:udp, XXXX:tcp, XXXXX:tcp… Ainsi, un fichier de configuration bien paramétré, ressemblera à quelque chose (comme cela – lien). (n’oubliez pas de droper les paquets par défaut sur Iptables… car sinon, cela ne sert à rien…) Ensuite, nous devons redémarrer knockd afin qu’il reprenne bien en compte les nouveaux paramètres, pour se faire, une simple commande suffit :

       * (# | sudo ) /etc/init.d/knockd restart

    Voilà, l’installation, et la configuration est finie, reste plus qu’à tester avec un client !

    5. Utilisation d’un client

    Il existe des clients pour tous les systèmes d’exploitation, et cela, c’est cool ! Ainsi, il suffit simplement d’exécuter le binaire client knockd comme ceci afin de réaliser le port-knocking :

       * > knock (ip du serveur) (port):(tcp|udp) (port):(tcp|udp)...

    Vous trouverez les binaires et sources des clients sur le site de knockd : http://www.zeroflux.org/projects/knock (il existe même un client pour Iphone!). Bref, libre à vous ensuite de vous amuser avec knockd, sur différentes box et à partir de différents clients.

    PageJacking, le retour de l’attaque !

    août 21st, 2009

    Pagejacking, vous connaissez ? En début de semaine, je m’aperçus d’un problème de référencement sur CCTV-tracking, le site avait pris les métas d’un site pointant vers lui avec une redirection 302. Ainsi, Google le présentait avec l’ancien titre et l’ancienne description du site pointant vers lui en 302 sans toucher au nom de domaine. Cela me paraissait très vite être une superbe vulnérabilité, une sorte d’attaque indirecte touchant à l’image d’un site internet sur Google. Il suffisait juste – d’après ce que j’ai pu constater sur le vif – posséder un site ayant un PR plus élevé que le site que l’on ciblait et réaliser une petite redirection 302 vers ce dernier afin qu’il s’imprègne des métas données que Google avait indexé précédemment. (Bon, dans le même coup, on perd une grande partie du référencement de notre site internet) S’en suivi quelques tests et vérifications jusqu’à ce soir où je me suis mis dans la tête de trouver d’où pouvait bien venir ce problème de « spoofing de résultat » comme je l’appelais. Et c’est à mon grand étonnement qu’à la suite d’un petit débat avec un ami (Alexis) et de quelques recherches, j’ai trouvé un site qui parlait de ce même problème (et d’autres), et ce dernier n’était pas nouveau, il datait même de quelques années. Aujourd’hui, je qualifie cette « faille » d’ovni du SEO, tout d’abord du fait que Google étant une blackbox, nous ne savons pas réellement d’où cela peut provenir et surtout il serait assez dur de reproduire l’attaque en environnement stérile (avec deux sites réalisés dans ce seul but). De plus, son analyse prendrait beaucoup de temps (indexation des sites, tests etc.). Cet article était avant tout à but informat{if||ique} car je n’ai pas l’impression que l’on ait véritablement parlé de cette vulnérabilité sur le web français… et Google à encore du mal à la colmatée on dirait, même après de longues années :D