Diving in the Slunk eventtype hell 🙂

Feel free to assess Splunk App for Web Analytics

Le grand vainqueur du concours du meilleur Kébab parisien est : L’Everest !

Et ce n’est pas ce minus de Booba qui me contredira. Jamais entendu le moindre son de ce gazier, jamais croisé sur place non plus, mais je me souviens très de la couv’ d’un numéro des Inrocks en 2011.

J’ai du mettre les pieds là-bas pour la première fois dans les années 2000. C’était à quelques centaines de mètres des ancien bureaux d’Alliacom.

Ce billet m’est largement inspiré par l’article Wikipedia version anglaise ainsi que par ma traversée attentive de l’évènement qui m’aura permis de revisiter TLS, les sockets Python et TCPDump.

Je sais, comme dirait ma mère à @turblog : « pffff, c’est compliqué !« . Mais, je peux vous éclairer.

J’avais par ailleurs publié dès le 11 avril sur le site d’Alliacom mon analyse à chaud de la situation.

Ce post servira de trame à notre Afterwork Alliacom du jeudi 24 avril 2014 à 18h00.

En l’écrivant, je me remémore curieusement / furieusement une vidéo de Julien Codorniou à CONF@42 – Facebook – Why hackers will rule the world et la nécessité d’être un peu DEV pour comprendre le monde d’aujourd’hui. Nécessité de l’être même davantage si on ne veut pas que le gimmick se transforme en Why hackers will ruin the world !

Chronologie :

• Janvier 1999 : RFC 2246 on passe de SSLv3.0 à TLS1.0
• Février 2012 : RFC 6520. L’extension Heartbeat ! Un des gros soucis de TLS, la phase de négociation aussi appelée handshake est très consommatrice  en ressources, on crée donc une extension pour garantir qu’une connexion est toujours vivante (keep-alive). Simple échange de messages entre les 2 pairs détaillé sur son blog par Stéphane Bortzmeyer dès 2012. Il aurait pu nous prévenir de la faille 🙂

« Heartbeat fournit un moyen de tester et de maintenir vivante un lien de connexion sécurisé sans être obligé de renégocier une connexion« .

• 31 décembre 2011 : Robin Seggelmann réalise le comit fatal, en implémentant Heartbeat au sein d’openSSL. Beaucoup d’annedotes invérifiables pas forcément glorieuses pour l’auteur circulent sur internet sur les conditions de cette réalisation.
• 14 mars 2012 : openSSL v1.0.1 est publiée. Cette version est la première à intégrer le bug.
• 3 décembre 2013 : réservation du CVE – 2014 – 0160 sur le site du MITRE, par qui ? pour quoi ?
• 21 mars 2014 : Bodo Moeller et Adam Langley de Google publient un patch corrigeant le bug découvert auparavant par Neel Mehta membre de l’équipe sécu de Google.
• 31 mars 2014 ; CloudFlare patche ses serveurs après avoir été mystérieusement averti et avoir signé un accord de non-divulgation.
• 1er avril 2014 : Google notifie openSSL de la faille.
• 3 avril 2014 : Codenomicon, une société de cybersécu finlandaise rapporte à son tour le bug qu’elle signale au CERT finlandais.
• 7 avril 2014 ; la version 1.0.1g d’openSSL intégrant le patch est publiée.
• Dans la nuit du 7 au 8 avril,  Cloudflare sur son blog et Codenomicon (qui a imaginé le nom de la faille et dans la foulée déposé le nom de domaine heartbleed.com) lancent le buzz volant la vedette à Microsoft qui devait être ce même jour sur le grill du fait de l’arrêt de maintenance pour Windows XP.

 

Le bug :

• Une bonne démonstration technique de la cause sur le blog de Lexsi ou sur le site de The Register. Il s’agit en termes techniques d’un très banal buffer overflow.
• Une présentation très pertinente de DenyAll sur le sujet.
• Les versions impactées : 1.0.1 à 1.0.1f, la version 1.0.1.g étant la version patchée.
• En raccourci : le bug vous permet de voler le contenu de la mémoire du serveur vulnérable auquel vous vous connectez par paquets de 64 Ko.
• Une explication simplifiée en images:

•  Ne pas oublier que le bug est une faille d’implémentation et ne remet absolument pas en cause TLS.
• Cette faille apparaît très tôt après le gotoFail d’Apple et les déboires de GnuTLS.
• Microsoft et Oracle (Java) traditionnels gros pourvoyeurs de failles en tout genre rigolent doucement de la situation car non touchés par leur implémentation.
• Vous voulez la liste des produits impactés ?
• Conduite à tenir pour les utilisateurs des systèmes vulnérables : changement de mot de passe après patch du site impacté, révocation des certificat après regénération de clefs.

 

Les risques :

• Vol de mots de passe, clefs privée, numéro de CB, …
• Ecoute d’échanges numériques.

 

Démonstration :

• Sur des sandboxes internes à Alliacom
• Sur des sites non patchés  ahhh non ça c’est interdit 🙂
• En utilisant les démonstrateurs plus ou moins faibles/fiables en ligne.
• Cloudflare challenge : 4 personnes ont réussi à récupérer une clef privée sur un serveur de tests. Cela leur a demandé de générer entre 200 000 et 2 500 000 requêtes.
• Limites : exploits basiques largement diffusés mais outils d’attaque pertinents rares et complexes. Il est amusant de constater que dans un tweet du 7 avaril, Adam Langley pensait qu’il n’était pas possible de voler une clef privée.

 

Conséquences :

• Depuis mars 2012, vos mots de passe de 47 caractères dont 13 caractères spéciaux ne vous protègent pas de grand chose.
• NSA au courant  (on me dit dans l’oreillette que Vupen revend l’exploit depuis 18 mois  Bad joke !) ? Théorie du complot ?
• Sale temps pour les bibliothèques SSL (Apple et GnuTLS).
• Coup de mou et stress test pour les autorités de certification et les CRL qui explosent.
• Tests non fiables et sécurité en carton (attention, rien ne remplace un audit de vos équipements et recherche d’utilisation d’openSSL par des professionnels)
• 500 000 serveurs webs touchés (plus autant d’équipements réseau ?)
• Je veux un IDS/IPS. Tu l’as vu passer mon \x16\x03\x02\x00 ?
• openSSL => fork LibreSSL lancé par quelques membre de la communauté openBSD. La concurrence, ça dope la qualité ? En tout cas, ça fait maigrir : on parle de 90 000 lignes de code C supprimées.
• Communauté opensource : des voix s’élèvent déjà pour critiquer la faible qualité d’openSSL qui a bénéficié de 800 $ de dons la semaine de la divulgation de la faille. Que se passerait-il avec du code propriétaire ? Personne ne serait au courant sauf ceux ayant découvert la faille après reverse engineering (ah non c’est vrai, c’est interdit …)
• Autres victimes collatérales : découverte dans les produits de notre ami éditeur xxxxx de bibliothèques openSSL 0 .9.8a (antédiluviennes ? = avant le bug de l’an 2000 ) datant de 2000 et farcies de failles … mais non vulnérables à Heartbleed !
• Non, SSH n’est pas concerné !
• Nous, Alliacom ? Par exemple, comment utiliser SPLUNK pour détecter ce genre d’activité suspecte.

 

Questions en suspens :

• Pourquoi cette date de création de l’entrée CVE – 2014 – 0160 sur le site du MITRE (2013-12-03) ?
• Je fais comment pour lire précisément telle ou telle zone mémoire ?
• A qui le tour ?
• Rappel d’une question du FIC 2014 : La cybersécurité est-elle un échec ?
  

  CVE MITRE 2014-0160

 

 

Bon là j’avoue, je sèche lamentablement…

Je veux mettre en place une authentification transparente sur une application web pour un utilisateur ayant ouvert sa session Windows sur son poste de travail.

J’ai téléchargé trunk-tcp-26092012 sur https://tomcatspnego.codeplex.com (mais si vous avez une solution alternative, je prends aussi)

J’ai un Tomcat6 sur Windows 8 avec JDK1.6. J’utilise l’application « examples » fournie avec Tomcat6 accessible via mon navigateur depuis l’url suivante :

http://localhost:8080/examples/jsp/security/protected/index.jsp

L’authentification classique fonctionnait parfaitement avec tomcat/tomcat (et elle fonctionne d’ailleurs toujours)

J’ai suivi le How-to fourni dans le configure.txt  dont je vous livre ma version commentée spnego.

Le fichier web.xml (renommé en txt) est disponible ici.

Et ça ne marche pas … Pourquoi ?

Pack your bag… faut y aller !

Lever à 3h45 le lundi 20 pour cause de premier TGV avancé à 5h15 le lundi matin depuis Vannes vers Paris.

2 jours à Lille, occasion pour Alliacom de présenter son nouveau service de CERT (Alliacert  – Computer Emergency Response Team) mais aussi de se tenir au fait des dernières actualités de la cybersécurité.

Programme du mardi 21 :

Programme du mercredi 22 :

Retour à 21h00 le mercredi 22 avec la grippe après 2 journées très riches.

---

Quelques comptes rendus du FIC trouvés sur le WEB

• Retour sur le FIC 2014 en infographie (publié le 3 février 2014 par organisation FIC2014)
• Newletter n°114 Hervé Schauer Consultants (HSC le 4 février 2014)
• #FIC2014: Entrée en territoire inconnu (par Ludovic Blin, secuobs.com le 04/02/2014)

Continue Reading

Un dimanche à  la campagne au milieu des chambres à air, alors qu’on aurait pu aller transpirer un peu à VTT dans la froidure mais sous le soleil… et bien non, il y a ce fichu problème de crash pdAdminIII qui vous retient.

Comment est-il possible qu’un outil qui fonctionnait correctement depuis plus de 6 mois sans attention particulière  se mette à planter systématiquement au démarrage ?

Euh… ah oui, ça se sont les joies de Windows où à force de clic-clic, tu pètes ta config sans t’en rendre compte. 

« Papa … l’ordinateur y marche plus …« 

Donc, au bout de 3 tentatives infuctueuses de relancer l’outil, il reste la recette magique « made In Microsoft« , l’imparable reboot. Mais là, malheureusement, il doit manquer quelques incantations car le redémarrage ne change rien.

Ca devient donc, critique … comment vais-je faire ? Je ne regarde même pas si le problème touche seulement pgAdminIII mais aussi le moteur de la base postgresql… Je m’interoge pour la première fois: où sont les logs, comment les activer … pfff, trop compliqué !

Je joue ma dernière dernière carte : désisntallation puis réinstalallation. Et là, ça va sérieusement se corser…

Je me lance donc dans la désinstallation. Pas d’inquiétude me direz-vous. Et bien si car malgré l’utilisation du désisntalleur depuis le panneau de conf des applications installées on laisse un max de traces :

• arborescence …/postpresql9.0/… contenant entre autres vos données
• clefs de registre
• compte de service postgres

Du coup, à la réinstallation ça couine de partout. Et le bug au démarrage reste le même. Je suis pas ailleurs surpris de retrouver mes données et d’apprendre que le compte postgres existe dékà avec un autre mot de passe que celui que je veux saisir.

Je retente donc une vraie désinstallation avec suppression du répertoire à la base (tant pis pour mes données, j’ai des sauvegardes, ce sera l’occasion de vérifier qu’elles fonctionnent), nettoyage des clefs de registre (galère, il y en a partout …) et suppression du compte de service « postgres ».

Et enfin, une réinstallation en principe propre…

Pas mieux !!! Ceux qui me connaissent imaginent aisément la salve de mot douteux que je ne peux réprimer … « P… mais ça me fait c… cette vie de cliqueur de m…« 

C’est bien la peine d’être dans l’informatique depuis 20 ans et d’être aussi désemparé devant un plantage applicatif que madame Cléro devant un bug Facebook.

Donc, là il va falloir se poser et réfléchir … Pour cela je décide d’aller contrôler l’état de ma chambre à air avant de mon Lapierre 500 et arrière du trentenaire Marin Muirwoods.

Quelques minutes plus tard, je reviens donc à la charge avec l’esprit clair et une question intéressante : « Qu’ai-je pu installer sur mon poste de travail qui se lance automatiquement et qui créerait un conflit avec PGAddmin III ?« 

Au bout de quelques minutes je tiens mon coupable : HitMan Pro !!! http://www.surfright.nl/en/hitmanpro/cyscon-en.

Je refais 3 fois la désinstallation et 2 réinstallations de Hitman Pro pour m’assure que quand Hitman Pro est là, PGAdmin ne fonctionne plus … avant de remonter gentiment pourrir copieusement l’éditeur…

et un WE d’énervement, un !!!

 

 

 

 

J’avais du vous raconter il y a quelques mois mon contact avec Coursera. Première expérience de formation 100% en ligne.

C’est à cette occasion que j’avais découvert les MOOC : massive open online courses.

On peut mesurer le progrès depuis l’époque pas si lointaine où chaque « enseignant » protégeait quasi secrètement sa production personnelle de « polys », expression écrite et quasi immuable de son savoir.