YomPage

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Compte-rendu de SSTIC 2007, 5e édition. ======

{{ start:bandeau_sstic_2007.jpg }}

  * La 5e édition du SSTIC s'est tenue à Rennes les 30, 31 et 1er juin dernier.

  * Comme les années précédentes, il ne fallait pas traîner pour réserver sa place : beaucoup d'appelants pour (trop ?) peu d'élus et, rançon du succès, sûrement beaucoup de déçus. Déçus qui se consoleront cependant à la lecture des actes dès qu'ils seront en ligne.
  * Résultat de la ruée vers Rennes cette année, un amphi rempli comme une prison : 350 places, 450 occupants.

  * A part cela, cette édition était celle de la transition, l'équipe à Pappy ayant passé cette année la main à la bande à Francky (si vous caressez l'espoir ou l'ambition de devenir team leader de SSTIC dans les prochaines années, trouvez-vous vitre un pseudo en "y". Sachant que Scapy est déjà pris...).

  * Alors SSTIC 2007 a t-elle (il?) tenu toutes ses promesses ? SSTIC est-il toujours SSTIC ?


===== Mercredi 30 mai 2007 =====

  * Alleluïa ! L'option TGV s'est avérée payante, je n'ai   *que  * 10 minutes de retard sur la séance d'introduction !


==== Prise en compte des nouveaux risques SSI : un défi pour les petites ou moyennes entités publiques. ====
  * Stéphane COTTIN, Jérôme RABENOU, Conseil Constitutionnel

  * Le Conseil Constitutionnel explique sa vision de la SSI dans ses missions. On aborde des sujets on ne peut plus intéressants et motivants (dématérialisation de la Justice, J.O. électronique) mais on dérape un peu lorsqu'on en vint à parler "machines à voter". Un troll fut lancé qui ne mourut que deux jours plus tard aux alentours de 16h15.
Moi de mon temps il existait un dicton qui disait "Don't feed the troll".

  * Autre point évoqué : le nombre trop restreint de RSSI pour, selon l'orateur, assurer un niveau de sécurité. L'air du temps n'étant pas à la relance de la dépense publique mais au "travailler plus" (pour gagner plus, on verra plus tard), je suis sceptique quant à l'ouverture de postes de RSSI en masse dans la fonction publique... OK, OK, on avait dit "Don't feed the troll" !

==== Marquage spatio-temporel ====
  * Philippe Balbiani, IRI Toulouse / CNRS

  * Malgré de trompeuses apparences, aucun rapport avec Valérian ni Laureline, mais un concept intéressant : comment prouver qu'un document a été modifié ici et maintenant ? Si le "maintenant" ne posait pas - trop - de problèmes, le "ici" (ou "là") par contre, était moins facile à résoudre.
  * La solution proposée est séduisante, il suffit de ne pas trop se demander "A qu(o)i cela peut-il bien être utile ?". N'oublions pas que SSTIC, ça a quand même un gros parfum de R&D. :-)
  * Plus sérieusement, on touche là à la problématique d'une version électronique de l'acte dit "authentique", c'est-à-dire d'un acte dont on sait quand et où il a été signé. Le genre de projet, s'il aboutit, qui devrait mettre pas mal de notaires sur la paille...

==== Secrets d'authentification sous Windows ====
  * Aurélien Bordes.

  * Aurélien Bordes présente une problématique très intéressante : la mise en cache des credentials (jetons d'authentification in french ?) Windows et ce qui peut en découler (Genre "Et ce qui devait arriver arriva").
Que cela soit lors de sessions d'authent. interactives (avec un/e utilisateur/trice au bout du clavier) ou on interactives (montage d'un partage réseau).

  * Dans la plupart des cas, les credentials que Windows conservent en cache sont les empreintes/condensats/hash des mots de passe des utilisateurs. L'objectif de cette mise en cache est de fournir aux utilisateurs un simili-SSO.
Les deux types d'empreintes utilisées par Windows sont LM et NTLM. Les protocoles d'authentification qui utilisent ces condensats sont LM, NTLM et NTLM v2.

  * Passons sur la faiblesse de LM. L'affaire est/devrait être entendue et l'utilisation de cette forme d'authentification relève de la faute de goût sinon professionnelle.

  * Dans le cas des protocoles d'authentification par le réseau (cas d'un client qui s'authentifie auprès d'un serveur ou cas du montage d'un partage réseau), les empreintes suffisent, la connaissance du mot de passe en clair de l'utilisateur dont on usurpe l'identité n'est pas stricto sensu nécessaire.

  * Sous Windows, LSASS joue un rôle essentiel dans le processus d'authentification des utilisateurs : c'est en effet lui qui gère les sessions ouvertes et les credentials mises en cache. C'est donc à ce processus LSASS que l'on va faire jouer le rôle de cafteur involontaire pour récupérer les credentials Windows.

  * Pour les authentifications non interactives, le principe est le même : récupération de l'empreinte/des credentials de l'utilisateur (ou d'une machine, puisque dans un domaine Windows une machine a une identité et est vue comme un utilisateur) et usurpation d'identité.

Bonne présentation émaillée de moult exemples.

==== Attaques par analyse de canaux cachés et de fautes. ====
  * Christophe<sup>1</sup> Clavier, Gemalto.

  * Un SSTIC sans sécurité matérielle ni reverse engineering ne serait pas vraiment un SSTIC.
  * C. Clavier présente donc différentes méthodes d'attaques contre la sécurité des cartes à puces, basées sur l'observation de leur comportement : consommation électrique, mesures de temps, etc.
  * L'objectif est d'analyser des composants de type cartes à puces en aveugle, et de tirer de cette analyse des informations sur les clefs secrètes utilisées (information utile quand la même clef secrète est embarquée dans tous les équipements d'une gamme donnée. Non, non, je n'ai pas dit qu'il pouvait s'agir de téléphones mobiles !) ou l'algorithme mis en oeuvre. Ce qui peut s'avérer utile quand le fabricant du composant refuse de communiquer sur son algorithme super robuste et dont il ne peut pas donner le code-source, propriété intellectuelle oblige. Des mauvaises langues pourront ajouter à ces objectifs l'espionnage industriel et la veille concurrentielle, mais bon... C'est quoi déjà l'activité de Gemalto ? :-)

<sup>1</sup> Et non Christian comme me le soufflait bêtement mon voisin...

==== CryptoPage : une architecture efficace combinant chiffrement, intégrité mémoire et protection contre les fuites d'informations ====
  * Guillaume DUC, Ronan KERYELL, ENST Bretagne

  * CryptoPage, c'est, pour faire très court, une grille de calcul hyper-sécurisée, dans laquelle un petit malin de chez Gemalto par exemple, ne pourrait rien tirer de l'observation et de l'écoute des composants de la grille.
  * L'idée est de construire et fournir à la grille un environnement d'exécution sécurisé, ce à tous les niveaux (bus, processeurs, mémoire, etc.). CryptoPage reprend pour cela les travaux qui ont donné naissance au projet HIDE (Hardware support for leakage Immune Dynamic Execution).
  * CryptoPage étend les fonctionnalités de HIDE pour couvrir des points qui ne l'étaient pas ou peu ou mal.
  * Concept intéressant - chaque noeud de la grille pouvant jusqu'à ne pas savoir ce qu'il fait/calcule - que l'on pourrait étendre à d'autres domaines moins académiques sur lesquels je n'ose pas m'étendre (l'informatique distribuée à beaucoup à apprendre des botnets...). 

==== Mécanisme d'observation d'attaques sur Internet avec rebonds ====
  * Eric ALATA, Ion ALBERDI, Vincent NICOMETTE, Philippe OWEZARSKI, Mohammed KAANICHE

  * Un SSTIC sans honeypot ne serait pas vraiment un SSTIC.

  * Le concept est le suivant : un pot de miel (pour ma part je traduirai "honeypot" par "pièjacon") c'est bien quand la machine qui l'héberge est la cible finale d'une attaque. Mais si cette machine ne sert que de point d'entrée, comment observer les rebonds et les attaques qui seraient lancées depuis cette machine après sa compromission ?
  * Une première réponse serait : "Ben, en regardant, gros malin !". D'où cette précision : comment observer les tentatives de rebonds en toute sécurité pour soi (sécurité au sens juridique du terme) et son environnement (sécurité des autres machines et notamment de celles qui n'auraient pas vocation à faire office de pièjacon) ?
  * L'utilisation de réseaux virtuels est envisageable, mais d'une manière générale ces réseaux sont isolés, notamment d'Internet.
  * L'objectif est donc de permettre à une attaque de rebondir a minima, au moins le temps de l'analyser. Précisons que par "permettre" il faut comprendre : donner l'illusion à l'attaquant qu'il peut sortir sur Internet depuis notre pièjacon.
  * La mise en oeuvre s'appuie sur un module NetFilter, on laissera le soin aux experts et spécialistes de trancher sur l'utilité d'avoir développé pour cela un nouveau module et ne pas avoir utilisé d'autres existants. Comme je le disais plus haut, "don't feed the troll"... :-)

==== Découverte de réseaux IPv6  ====
  * Nicolas Collignon, HSC

  * En théorie, IPv6 sonnera le glas des scanners réseau type nmap. L'espace d'adressage théorique est en effet tel qu'il est, dans l'état actuel de la technologie, irrationnel de découvrir en "bruteforce" (test de toutes les adresses possibles) les machines présentes sur un tel réseau. Je passe rapidement sur la première objection qui consiste à préciser qu'nmap ne sera réellement mort que le jour où la grande majorité des machines seront passées en IPv6. Le troll, toujours le troll...

  * Nicolas, à l'aide du framework sherlock et d'un peu de bon sens, montre cependant que "scan's not dead" dans le monde IPv6. Tout du moins: "scan's not dead Yet".

  * Les mécanismes de transition et la cohabitation entre IPv4 et IPv6 réservent également de bonnes surprises et de belles opportunités à l'attaquant.

==== Fin de journée. ====
  * Allez hop, deux crêpes et au lit. Enfin, non, pas vraiment... Une bonne partie de la soirée sera consacrée à la préparation d'une Rump Session qui a failli s'intituler "Esprit de Daniel, sors de ce corps !" ou "La Loose a encore frappé (et fort)". Un coup de fil de la réception mettra brutalement fin à de très fructueuses discussions sur la mise au point du MooSSTIC v1. Comme pourrait le dire un proverbe mauritanien : "La gardien passe, la R&D trépasse."

===== Jeudi 31 mai 2007 =====

  * Menu chargé, avec, en fin de journée, la perspective des désormais quasi-légendaires Rump Sessions.

==== Recherche de vulnérabilités dans les drivers 802.11 par techniques de fuzzing ====
  * Laurent Butti, Julien Tinnes, FT R&D

  * En amuse-gueule, le fuzzing de drivers Wifi par Laurent Butti épaulé de Julien Tinnes, tous deux de FT R&D. Si le sujet n'est pas vraiment neuf puisque déjà abordé lors de la Hack.lu et de la Black Hat Europe, il n'en est pas moins intéressant. D'une part parce que tout le monde n'a pas la chance d'avoir des parents communistes de pouvoir se déplacer aussi aisément que d'autres à l'étranger, ensuite - et surtout - parce que la présentation se conclut par une démonstration d'exploitation d'une faille dans le pilotes madwifi pour Linux : en un paquet un portable sous Ubuntu se fait rooter, le tout empaqueté dans et par MetaSploit, ça s'applaudit bien fort.

==== Exploitation en espace noyau  ====
  * Stéphane DUVERGER, EADS Innovation Works<sup>2</sup>

  * Puisqu'on est dans les rootkits (ou assimilés) restons-y. Et puis SSTIC serait-il encore SSTIC sans rootkits invisibles indétectables et furtifs s'exécutant en mémoire ?

  * Stéphane Duverger nous expliquent comment les rootkits qui s'exécutent dans le noyau (en l'occurrence Linux) fonctionnent, à quelles contraintes ils doivent répondre.

  * Je renvoie lâchement le lecteur intéressé par le sujet - au demeurant passionnant - aux actes SSTIC dès qu'ils seront en ligne.

<sup>2</sup>Est-ce que cela signifie "Travaux d'innovation" ou bien "L'innovation, ça marche !" ?

==== De l'invisibilité des rootkits : application sous Linux  ====
  * Eric LACOMBE, Vincent NICOMETTE, Frédéric RAYNAL, CNRS, Sogeti.

  * Du rootkit en veux-tu , en voilà.

  * Il était écrit que la matinée serait placée sous le signe des rootkits. Deuxième présentation sur le sujet, donc. Avec cette fois, Frédéric Raynal à l'affiche (oui, "LE" Frédéric Raynal de MISC, mon magazine préféré !<sup>3</sup>).

  * On enchaîne donc en répondant - avec brio - à deux questions existentielles : Comment rendre un rootkit complètement invisible ? Comment le faire réapparaître quand on (i.e.: l'attaquant) en a besoin ?

  * Une fois encore, tout cela est très bien décrit dans les actes dont je conseille très fortement la lecture.

<sup>3</sup> Hakin9, c'est pour le fun...

==== Analyse statique par interprétation abstraite  ====
  * Xavier ALLAMIGEON, Charles HYMANS, EADS IW, CEA.

  * Alors je tiens à faire taire dans l'oeuf de méchantes rumeurs : non, je ne dormais pas, j'étais concentré !<sup>4</sup>

  * Dans cette présentation, on nous présente NewSpeak<sup>5</sup>, un outil d'analyse de code. Bref, on aborde la sécurité sous un angle Qualité / Contrôle.

  * NewSpeak est un langage de très haut niveau qui permet d'analyse du code sans devoir l'exécuter, dans le but d'y détecter des bogues ou des vulnérabilités.

<sup>4</sup> Et non, Philippe n'est pas gros non plus...
<sup>5</sup> "Hommage" à la novlangue orwellienne dont certains (j'en fais partie) pensent qu'elle constitue le vrai thème de 1984, et non la seule omni-surveillance policière.

==== Metasm, l'assembleur ====
  * Yoann GUILLOT, FT R&D

  * Si je vous dis "MetASM", que je précise que ce framework est développé en Ruby, vous pensez à quoi ? Si vous répondez "MetaSploit", vous avez gagné. :-)

  * MetASM est donc un framework de désassemblage/assemblage/linkage écrit en Ruby<sup>6</sup>. Il permet de manipuler du code compilé, de compiler ses propres shellcodes, le tout dynamiquement et, excusez du peu, pour plusieurs types de processeurs et de formats de fichiers exécutables.
  * MetASM, c'est tout simplement la Killer App' qui manquait à MetaSploit. La démonstration de l'exploitation de la faille madwifi du jeudi matin avait mis en lumière la puissance de cette alliance naturelle des deux frameworks.

<sup>6</sup> Cela aurait pu être Python, mais non, ce langage est réservé à d'autres applications...

==== Indiscrétions et « zones constructeurs » des disques durs ====
  * Laurent Dupuy, FreeSecurity.

  * SSTIC serait-il encore SSTIC sans analyses forensic ?

  * Dans cette présentation, on apprend ainsi qu'un disque dur peut être cachottier et non cacher bien des choses...

==== Autopsie d'une intrusion "tout en mémoire" sous Windows ====
  * Nicolas Ruff, EADS IW

  * On continue sur la lancée.

  * Nicolas - qu'on ne devrait plus présenter, et dont je n'ai pas saisi pourquoi il affirme que certains le présentent comme un escroc - passe en revue les différentes méthodes d'analyse post-mortem qui permettent de tracer une intrusion en mémoire sous Windows.
  * Parmi les méthodes classiques présentées, citons le crashdump, que l'on peut parfois provoquer, et qui permet de récupérer une bonne partie des informations sur l'état des processus en cours d'exécution au moment de l'analyse.
  * Autre piste évoquée : le fichier d'hibernation. Encore faut-il que celle-ci soit activée. Sur un serveur, j'ai des doutes, sur un portable par contre...

  * Notons qu'une fois récupéré le dump de la mémoire, il faut être capable de reconstituer celle-ci, tâche non impossible selon Nicolas mais pas simple non plus.

  * Suivent quelques exemples d'analyses sur des cas d'école, dont la détection de la présence de la DLL de Meterpreter ou le challenge Securitech.

==== Confidentialité et cryptographie en entreprise ====
  * Marie Bareil, juriste attitrée et - heureusement - inamovible du SSTIC.

  * SSTIC serait-il SSTIC sans une conférence de Marie Bareil ? 

  * M. Bareil fait un point très intéressant sur l'état de l'art juridique et judiciaire en matière d'utilisation des outils cryptographiques en entreprise. Notamment les obligations de déclaration   *préalable  * et le status des documents (fichiers) présents sur le poste de travail des salariés. Ces documents seraient ainsi considérés comme à usage professionnel par défaut, ce qui donne à l'entreprise une plus grande liberté d'action en la matière.
  * Notons que l'interdiction d'utiliser des outils de chiffrement externes peut (doit ?) être inscrite dans les chartes informatique ou les règlements intérieurs.


==== Rump Sessions ====

  * Mea culpa, mea maxima culpa, trop occupé par ma propre Rump, je n'ai suivi que d'un oeil discret les quelques 23 autres (si j'ai bien compté)...
  * J'ai retenu :
  * Eric Filiol sur la "solution" OneCare de Microsoft. En résumé : if one cares, most are scared !".
  * Philippe Biondi et son traceroute IPv6 en 3D.
  * Du MetaSploit, encore du MetaSploit, beaucoup de MetaSploit (3 si je n'en oublie pas).
  * Un affichage de fichier dans un commentaire de blog avec une grosse vanne à l'encontre de Nicolas Ruff que personnellement je n'ai pas totalement saisie, voire pas du tout.
  * Un retour sur NewSpeak, cette fois sous un angle pratique.
  * La cyberguerre esto-russe.
  * L'utilisation de disques durs usagés comme enceintes audio.


=== Rump Session tHTP ===

  * Les slides : {{start:thtp.pdf}}. 
  * A noter que les RFCs 1149 et 2549 existent bel et bien et font partie des légendaires RFCs 1st April.
  * Parmi les applications auxquelles vous avez échappées :
  * Scanner WiFi/BlueTooth embarqué. Problème de poids, l'hélico pèse 9 grammes et on a manqué de temps pour otpimiser.
  * Utilisation des mouvements de l'hélicoptère dans un PRNG 3D. L'idée : une webcam filme l'espace dans lequel évolue l'hélico et génère à partir de ses mouvements des nombres pseudo-aléatoires. Ce sujet a bien failli être celui de la Rump jusqu'à ce qu'Alexis suggère une solution pour simuler une prise USB, ce à quoi Daniel a répondu qu'on pouvait embarquer une mémoire Flash, ce qui a fait "tilt" dans la tête d'Olivier qui a trouvé l'idée d'utiliser une clef USB Sony de type mini. Bref, un vrai travail d'équipe !

===== Vendredi 1er juin =====

==== Démarches de sécurité & Certification : atouts, limitations et avenir ====
  * Christian DAMOUR, Orange Business Services

  * A ma grande honte je n'ai pas pu suivre cette présentation dans sa totalité.

==== VOIP, une opportunité pour la sécurité ? ====
  * Nicolas DUBÉE, SecWay

  * Comment sécuriser les protocoles SIP et RTP et mettre en oeuvre ZRTP, le tout dans un boîtier. Si si, ça tient dans une boite, faut juste un bon chausse-pied... :-)

==== Sécurité d'OpenDocument et Open XML (OpenOffice et MS Office 2007) ====
  * Philippe Lagadec, OTAN.

  * Bonne analyse comparative des nouveaux formats OpenDocument et OpenXML utilisés respectivement par les suites bureautiques OpenOffice et MS Office.
  * Dans les deux cas on a du XML dans du ZIP.
  * A noter que OpenOffice accepte, pour les macros, des langages comme Python, avec tout ce que cela peut amener comme problèmes.

==== Evolution des attaques de type "Cross Site Request Forgery" ====
  * Louis NYFFENEGGER, Renaud FEIL, HSC

  * SSTIC serait-il SSTIC sans une petite touche de Web 2.0 ?

  * Rapide état de l'art en matière de compromission du navigateur à l'aide de JavaScript et autres XML-eries.

  * Quelques exemples pratiques sympathiques, notamment le coup du navigateur fantôme à l'aide d'un XMLHttpRequest en boucle. Cadeau Bonux : une faille sur le formulaire de soumission de présentation pour SSTIC. Je viens de comprendre pourquoi mon papier n'a pas été accepté cette année. Ah, si seulement j'avais connu le marquage spatio-temporel ! :-)

==== La cryptographie au secours du vote électronique ====
  * Marc GIRAULT, FT R&D

  * Excellente présentation sur un sujet brûlant. Elle n'aura pas réussi à convaincre quelques récalcitrants ronchons mais les problèmes et solutions ont été bien posés.

  * Une fois encore je donne dans la facilité et renvoie aux actes, mais j'adhère - partiellement - à la conclusion de l'orateur : quand le vote électronique sera possible de manière sécurisée, et la présentation a montré que cela est du domaine du possible, on pourra impliquer plus souvent le citoyen à travers le vote. Et - c'est là que je rejoins l'orateur - ce sera réellement une avancée démocratique.
  * Pour ma part, je rêve en effet d'un système de vote qui permettra à tout un chacun de vérifier les résultats d'une vote à la maison. Par exemple je charge les bulletins électroniques anonymes, je charge la routine de dépouillement, et je refais le décompte des voix à la maison.
  * Dans sa version "papier", le vote est en partie sécurisé par le nombre de contrôles qui s'applique sur la chaîne vote - dépouillement. Plus il y a de points de contrôle, plus la triche et la fraude sont compliquées. Malgré ses avantages, le vote "papier" n'empêche nullement un certain degré de triche. Et même si tout citoyen peut assister à l'ouverture des urnes et au décompte des voix, cela est facilement possible dans un bureau de vote. Aux échelons suivants (regroupement au niveau de la commune, département, etc.) le contrôle se dilue, vu du citoyen. Si le vote électronique prévoit un recomptage intégral par tout citoyen de l'ensemble des votes d'une élection donnée, locale ou nationale, ce à chaque échelon (je peux charger les bulletins de chaque commune, puis de chaque département, effectuer les regroupements et recoupement, etc.) on frise la transparence totale.
  * Il semble de plus tout à fait réaliste d'avoir un système mixte dans lequel chaque machine à voter imprimerait tout ou partie du vote en cas de contestation.
  * Les systèmes utilisés actuellement ne sont pas parfaits, ne serait-ce que parce que leurs cahiers des charges Sécurité n'ont pas forcément été bien rédigés ou contrôlés (ne serait-ce que par manque de moyen, Cf la présentation d'ouverture), cela ne signifie pas à mon sens qu'ils ne soient pas perfectibles. Même le processus "papier" fut en son temps imparfait.
  * Seul grand regret sur cette présentation : les actes ne présentent qu'une version très "light" de ces travaux.

==== État de l'art - cassage de mots de passe ====
  * Simon MARECHAL, Thalès.

  * A première vue une présentation des techniques de cassage d'empreintes. On pense évidemment à John The Ripper.
  * Puis rapidement - et heureusement - on dévie sur la description du casseur idéal, que ce soit au niveau du matériel (quel processeur choisir, sur quels critères ?) que fonctionnel (cassage distribué).
  * Tout ça pour aboutir à la conclusion que le processeur CELL d'IBM semble un bon choix. Et où trouve t-on ledit processeur ? Je vous le donne Emile : dans une PlayStation 3 !
  * De là à penser que ce fut juste un bon alibi pour se faire offrir une PS3 par sa boite...

===== Conclusion =====

  * Il est temps maintenant de répondre à la question posée en introduction : SSTIC est-il encore SSTIC ?
  * Mettons donc fin à ce suspens insoutenable : 2007 ne fut par pour SSTIC l'année de la rupture. Cette 5e édition s'est selon moi inscrite dans la continuité des précédentes. C'est peut-être là que le bât pourrait d'ailleurs blesser : il ne faudrait pas que SSTIC tombe dans la routine. Les Rump Sessions cette année ont été exceptionnelles, de par leur nombre (23 selon la Police, 25 selon les organisateurs) et la diversité des sujets traités. Ce peut être une piste pour l'édition 2008 : conclure chaque journée par des Rump (bon, peut-être pas 25 par jour non plus). Ca détend l'atmosphère et réveille le petit chercheur qui sommeille en chacun de nous.
  * Pour ma part, j'ajouterai : un challenge façon CTF de la Hack.lu. Il y eut cette année une tentative de ce genre à SSTIC : le challenge était de deviner à quoi servait un des goodies estampillés ESAT présent dans la pochette avec les actes. L'an prochain, on se lance dans le Sudoku ? :-)



===== Liens =====
  * Eux aussi y étaient :

  * [[http://sid.rstack.org/blog/index.php/2007/06/04/193-le-sstic-2007-comme-si-vous-y-etiez-ou-pas|Cédric Blancher]]
  * [[http://www.lexfo.fr/blog/index.php/2007/06/04/23-sstic07|Samuel Dralet]]
  * [[http://nonop.blogspot.com/2007/05/rchauffement-climatique-et-le-sstic.html|Nono et/ou FX]]
  * [[http://altmylife.blogspot.com/2007/06/sstic-2007.html|Vincent Guasconi]]
  * [[http://bruno.kerouanton.net/dotclear/|Bruno Kerouanton]]
  * [[http://ivanlef0u.free.fr/?p=52|ivanlef0u]] (sans son sous-marin ?)
YomPage

User Tools

Site Tools

Page Tools
