[SMSI] Evalsmsi install

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

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

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?

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

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

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

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.