[HITB Conference] SAP Hacking - Overview 2/2

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

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

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

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

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

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