2010-01 Archives
21-01-2010 23:06:54
[Secu] 0day IE et blablabla
Etant donné la médiatisation de la dernière vulnérabilité Internet Explorer, je vais moi aussi donner mon opinion dessus
(meme si tout le monde s'en fiche :) ).
Commencons par un petit résumé de l'histoire : une nouvelle éclate et fait grand bruit disant que Google stoperait de filtrer ses contenus pour la Chine pour des raisons assez vagues de piratage de l'état Chinois. Déjà ca attaque fort ! Très vite Google annonce qu'une 20aine de grosses sociétés américaines seraient également victimes d'intrusions provenant de Chine. Ca commence à ressembler à un bon nanard de Vandamme avec pleins de méchants chinois. La, clou de l'histoire, qui commence à bien se médiatiser, la vulnérabilité proviendrait d'IE et plus particulièrement d'IE6 pour cette vulnérabilité selon McAfee. Et la ... c'est le drame !
A partir de là, IE est devenu le logiciel à abattre. Mais est ce justifié ?
La polémique provoqué purement par les médias provient principalement de l'avis du CERTA. Pour rappel, le CERTA a proposé la contre mesure suivante pour cette vulnérabilité :
Malgré cela, les médias ont insisté sur tous ces détails qui sont bien sur tombés dans les oreilles des décideurs qui ont vu que leur site préféré "d'actualité informatique" signale que IE c'est dangereux ! Certes cela a pu servir à appuyer des projets de migrations de navigateur... mais au final une société avec des antivirus et/ou des IPS et/ou des analyseur de flux et/ou des proxy et tout cela bien sur à jour ne risque pas grand chose de plus que d'habitude. Si le mal était fait, c'était avant que le 0day soit rendu publique.
Donc quel intéret de cette médiatisation ? A qui ca a servi ? Peut etre aux trolleurs anti Microsoft qui ne comprennent rien aux problématiques d'entreprises et qui croit que changer de navigateur se fait en 10mn. Ou alors aux autres sociétés proposant des navigateurs, comme ... Google :) qui par la meme occasion se prépare pour la sortir de son OS. Cela a du également bien amusé quelques chercheurs en sécurité informatique qui ont pu appliquer l'exploitation sur les différentes versions du navigateurs, sur les différents OS tout en tentant de bypasser les protections comme DEP.
Bref tout ca pour dire que les médias ont le pouvoir de faire "croire" qu'un risque est supérieur à d'habitude et à orienter les solutions à appliquer alors qu'ils n'ont pas les compétences pour le faire. Cela peut amener à faire croire des idées qui au final peuvent etre bien plus dangereuses. Quel est le risque le plus élevé ? Qu'une société moyenne change en urgence de navigateur sans passer par une étape d'intégration, sans avoir de support préparé à résoudre les problèmes d'un nouveau navigateur ou qu'une société garde IE tout en vérifiant que ses protections antivirales soient bien à jour ? Je pense que la réponse est évidente ... sauf pour les médias apparemment.
Allez je vous laisse patcher car si vous ne le saviez pas, le patch est déja sorti. Ah au fait, un nouveau 0day impacte tous les Windows, changez temporairement d'OS :)
Commencons par un petit résumé de l'histoire : une nouvelle éclate et fait grand bruit disant que Google stoperait de filtrer ses contenus pour la Chine pour des raisons assez vagues de piratage de l'état Chinois. Déjà ca attaque fort ! Très vite Google annonce qu'une 20aine de grosses sociétés américaines seraient également victimes d'intrusions provenant de Chine. Ca commence à ressembler à un bon nanard de Vandamme avec pleins de méchants chinois. La, clou de l'histoire, qui commence à bien se médiatiser, la vulnérabilité proviendrait d'IE et plus particulièrement d'IE6 pour cette vulnérabilité selon McAfee. Et la ... c'est le drame !
A partir de là, IE est devenu le logiciel à abattre. Mais est ce justifié ?
La polémique provoqué purement par les médias provient principalement de l'avis du CERTA. Pour rappel, le CERTA a proposé la contre mesure suivante pour cette vulnérabilité :
Dans l’attente d’un correctif de l’éditeur, le CERTA recommande l’utilisation d’un navigateur alternatifTout d'abord ce qu'il faut rappeler, c'est ce qu'est le CERTA, parce qu'apparement beaucoup de gens ne le savent pas. Donc sur le site officiel, on peut y lire :
Le CERTA est chargé d'assister les organismes de l'administration à mettre en place des moyens de protection et à résoudre les incidents ou les agressions informatiques dont ils sont victimesDonc quand on sait lire, on voit que cette recommandation est destinée à l'administration francaise, donc ni aux particuliers, ni aux entreprises. Par ailleurs il est bien dit "dans l'attente d'un correctif" donc il ne conseille pas de ne plus utiliser IE mais propose aux administrations de change provisoirement. De plus, quand on lit régulièrement les avis du CERTA, chose qu'apparemment la presse ne fait pas, on a l'habitude de voir cette recommandation étant donné qu'elle est mentionnée pour chaque 0day sur un produit. On l'a par exemple très récemment vu pour le 0day Adobe Reader qui a fait beaucoup moins de bruit et qui niveau impacte pouvait etre à mon sens plus risqué de par le fait qu'il peut etre plus dur à detecter par un antivirus ou un analyseur de flux et que les gens connaissent moins d'alternatives.
Malgré cela, les médias ont insisté sur tous ces détails qui sont bien sur tombés dans les oreilles des décideurs qui ont vu que leur site préféré "d'actualité informatique" signale que IE c'est dangereux ! Certes cela a pu servir à appuyer des projets de migrations de navigateur... mais au final une société avec des antivirus et/ou des IPS et/ou des analyseur de flux et/ou des proxy et tout cela bien sur à jour ne risque pas grand chose de plus que d'habitude. Si le mal était fait, c'était avant que le 0day soit rendu publique.
Donc quel intéret de cette médiatisation ? A qui ca a servi ? Peut etre aux trolleurs anti Microsoft qui ne comprennent rien aux problématiques d'entreprises et qui croit que changer de navigateur se fait en 10mn. Ou alors aux autres sociétés proposant des navigateurs, comme ... Google :) qui par la meme occasion se prépare pour la sortir de son OS. Cela a du également bien amusé quelques chercheurs en sécurité informatique qui ont pu appliquer l'exploitation sur les différentes versions du navigateurs, sur les différents OS tout en tentant de bypasser les protections comme DEP.
Bref tout ca pour dire que les médias ont le pouvoir de faire "croire" qu'un risque est supérieur à d'habitude et à orienter les solutions à appliquer alors qu'ils n'ont pas les compétences pour le faire. Cela peut amener à faire croire des idées qui au final peuvent etre bien plus dangereuses. Quel est le risque le plus élevé ? Qu'une société moyenne change en urgence de navigateur sans passer par une étape d'intégration, sans avoir de support préparé à résoudre les problèmes d'un nouveau navigateur ou qu'une société garde IE tout en vérifiant que ses protections antivirales soient bien à jour ? Je pense que la réponse est évidente ... sauf pour les médias apparemment.
Allez je vous laisse patcher car si vous ne le saviez pas, le patch est déja sorti. Ah au fait, un nouveau 0day impacte tous les Windows, changez temporairement d'OS :)
15-01-2010 00:20:44
[Secu] Et vous, quel disclosure etes vous ?
On voit en ce moment de nombreux 0days surgir d'un peu partout et par différentes voies. Certains par des sociétés
travaillant dans le secteur de la SSI, certains par des passionnés, d'autres par des labos ... Bref plusieurs types
de sources qui du coup gère leur publication (disclosure) de manière différente. Je vais ici faire un tour des différents
disclosures et donner mon opinion dessus.
On trouve principalement 3 types de philosophie concernant la diffusion de vulnérabilités en matière de sécurité informatique, le Non diclosure, le Full disclosure et le Responsible disclosure
-Non disclosure : celle ci consiste à ne rien dire concernant une vulnérabilité. Je l'attribuerai plutot aux pirates du type "blackhat" qui souhaitent que les failles ne soient pas dévoilées afin de les exploiter le plus longtemps possible. C'est d'ailleurs ce que prone le groupe anti-sec, soi disant constitué de "vilain blackhat" mais ca, ca reste une autre histoire :). Ces vulnérabilités restent alors connues d'un cercle très fermé qui en profite pour se faire de l'argent en volant et revendant des informations ou en extorquant en demandant des rancons pour laisser le site en état. Cela peut paraitre dangereux mais au final arrange plutot pas mal certaines sociétés surtout quand la vulnérabilité qui peut avoir un niveau de criticité élevé va donner un cout de développement,pour réaliser le patch en urgence, assez élevé. Il est d'ailleurs arrivé que certaines sociétés demandent à la personne remontant la vulnérabilité de ne rien dévoiler pendant une longue période pour qu'elle puisse corriger dans le délai qu'elle va imposer. Plus grave, notre cher pays, la France interdit la publication de code d'exploitation de vulnérabilité si celle ci n'est pas corrigée ou si l'on ne propose pas de solution de contournement. En gros, on préfère que nos systèmes restent insécures tant que personne ne le sait ... sauf que certains pays le savent et sont bien plus en avance sur nous dans le domaine de l'exploitation de vulnérabilité et eux ne vont pas hésiter à revendre ces 0day qui chez nous seront connus mais non dévoilés donc non corrigés ... Bien sur en tant que bon francais respectant la loi, je vous propose une solution corrective à cela : prenez un serveur dans un autre pays et publiez :)
-Full disclosure : cette méthode consiste à publier directement la vulnérabilité sans prévenir au préalable la société responsable de l'application de celle ci. Souvent considérée comme la méthode la plus préconisée pour la sécurité, elle est un peu plus complexe que ca je pense. Car au final quel est le but de publier directement ? Imposer que l'éditeur corrige vite en laissant l'application vulnérable et exploitable par des milliers de kiddies pendant une période plus ou moins longue ? Pas terrible quand meme. Personnellement je vois surtout en cette méthode le besoin de flatter son égo. Et oui le "pirate" a besoin de reconnaissance pour s'intégrer et montrer qu'il est plus fort qu'un autre. Au final, etre un pirate n'est rien d'autre qu'une classe regroupant un type de personnes qui ont besoin de ressembler à un modèle. Une adolescence un peu tardive pour certains quoi :) . Après le full disclosure peut quand meme etre une finalité si une société veut abuser sur une proposition de reponsible disclosure et prend énormément de temps pour corriger la vulnérabilité. Il faut selon la complexité de correction de la faille évaluer une date limite de correction et décider de publier si rien n'est fait car au final on peut avoir l'impression d'etre pris pour un pigeon. Ou tout simplement on peut choisir le full disclosure pour ne pas se prendre la tete :)
-Responsible disclosure : derrière cette méthode qui peut sembler la plus logique et sensée se cache plus de complexité. Le responsible disclosure consiste à prévenir la société responsable du produit vulnérable afin que celle ci la corrige et à publier la faille une fois le patch fourni. Du coup on reste quelqu'un de responsable, de "whitehat", notre égo est flatté meme si cela oblige à attendre et à réduire l'impact de la publication vu qu'il existera un patch et cela peut meme payer si l'on passe par des systèmes comme le propose ZDI. Cependant ZDI c'est bien gentil mais quand on regarde la liste des vulnérabilités en cours de traitement on constate que le temps de correction est parfois énorme (plusieurs années) ! Du coup la faille a largement le temps d'etre exploitée par d'autres hackers qui eux vont rester sur le principe du non-disclosure et se faire de l'argent sale. Du coup le responsible disclosure peut amener un abus des sociétés de développement qui se croient du coup à l'abris.
Un cas récent et intéressant je trouve est la position de la société Intevydis qui propose un module pour l'outil CANVAS d'Immunity. Le 0day est donc le business de cette société. Celle ci a donc fait une réponse concernant son choix de ne pas pratiquer le responsible disclosure. Celle ci explique que les sociétés de développement profitent des cabinet de recherche en vulnérabilité et se reposent sur elle, attendant que celles ci leur soumettent les vulnérabilités et appliquent le Responsible disclosure que j'expliquerai par la suite. Ceci n'est pas faux. A mon sens, le travail généré pour la recherche et l'aide à résoudre doit etre payé et en prime doit passer prioritaire si la criticité l'impose, chose qu'elles ne font jamais. Cependant leur explication sur le fait que les grosses sociétés ont des moyens pour sécuriser leur application ne tient pas la route car les moyens ne donnent pas forcément la compétence :) . Du coup on peut mettre énormement d'argent et avoir quand meme des bugs qui passent à la trappe.
Un autre point de vue intéressant est celui qu'a donné Laurent Gaffié lors de ses publications sur la vuln SMBv2. Lors de sa première publication, il lui a été reproché de ne pas avoir prévenu Microsoft. Cependant la 2e fois, voulant bien faire, il a pratiqué le responsible disclosure mais a constaté devenir le larbin de la société souhaitant obtenir le maximum d'information, la manière de trouver la vuln, la correction ... bref de les assister sans rémunération. Et ca faut avouer que ca donne pas envi d'etre très responsable :)
Donc que faire dans tout ca ? Et bien ce que l'on semble de mieux :) Tout dépend de l'objectif de la publication, d'ou on se situe dans le monde de l'informatique (professionnel, passionné, pirate) et de ce qu'on l'on souhaite obtenir en retour : de l'argent, flatter son égo ou une bonne conscience :)
On trouve principalement 3 types de philosophie concernant la diffusion de vulnérabilités en matière de sécurité informatique, le Non diclosure, le Full disclosure et le Responsible disclosure
-Non disclosure : celle ci consiste à ne rien dire concernant une vulnérabilité. Je l'attribuerai plutot aux pirates du type "blackhat" qui souhaitent que les failles ne soient pas dévoilées afin de les exploiter le plus longtemps possible. C'est d'ailleurs ce que prone le groupe anti-sec, soi disant constitué de "vilain blackhat" mais ca, ca reste une autre histoire :). Ces vulnérabilités restent alors connues d'un cercle très fermé qui en profite pour se faire de l'argent en volant et revendant des informations ou en extorquant en demandant des rancons pour laisser le site en état. Cela peut paraitre dangereux mais au final arrange plutot pas mal certaines sociétés surtout quand la vulnérabilité qui peut avoir un niveau de criticité élevé va donner un cout de développement,pour réaliser le patch en urgence, assez élevé. Il est d'ailleurs arrivé que certaines sociétés demandent à la personne remontant la vulnérabilité de ne rien dévoiler pendant une longue période pour qu'elle puisse corriger dans le délai qu'elle va imposer. Plus grave, notre cher pays, la France interdit la publication de code d'exploitation de vulnérabilité si celle ci n'est pas corrigée ou si l'on ne propose pas de solution de contournement. En gros, on préfère que nos systèmes restent insécures tant que personne ne le sait ... sauf que certains pays le savent et sont bien plus en avance sur nous dans le domaine de l'exploitation de vulnérabilité et eux ne vont pas hésiter à revendre ces 0day qui chez nous seront connus mais non dévoilés donc non corrigés ... Bien sur en tant que bon francais respectant la loi, je vous propose une solution corrective à cela : prenez un serveur dans un autre pays et publiez :)
-Full disclosure : cette méthode consiste à publier directement la vulnérabilité sans prévenir au préalable la société responsable de l'application de celle ci. Souvent considérée comme la méthode la plus préconisée pour la sécurité, elle est un peu plus complexe que ca je pense. Car au final quel est le but de publier directement ? Imposer que l'éditeur corrige vite en laissant l'application vulnérable et exploitable par des milliers de kiddies pendant une période plus ou moins longue ? Pas terrible quand meme. Personnellement je vois surtout en cette méthode le besoin de flatter son égo. Et oui le "pirate" a besoin de reconnaissance pour s'intégrer et montrer qu'il est plus fort qu'un autre. Au final, etre un pirate n'est rien d'autre qu'une classe regroupant un type de personnes qui ont besoin de ressembler à un modèle. Une adolescence un peu tardive pour certains quoi :) . Après le full disclosure peut quand meme etre une finalité si une société veut abuser sur une proposition de reponsible disclosure et prend énormément de temps pour corriger la vulnérabilité. Il faut selon la complexité de correction de la faille évaluer une date limite de correction et décider de publier si rien n'est fait car au final on peut avoir l'impression d'etre pris pour un pigeon. Ou tout simplement on peut choisir le full disclosure pour ne pas se prendre la tete :)
-Responsible disclosure : derrière cette méthode qui peut sembler la plus logique et sensée se cache plus de complexité. Le responsible disclosure consiste à prévenir la société responsable du produit vulnérable afin que celle ci la corrige et à publier la faille une fois le patch fourni. Du coup on reste quelqu'un de responsable, de "whitehat", notre égo est flatté meme si cela oblige à attendre et à réduire l'impact de la publication vu qu'il existera un patch et cela peut meme payer si l'on passe par des systèmes comme le propose ZDI. Cependant ZDI c'est bien gentil mais quand on regarde la liste des vulnérabilités en cours de traitement on constate que le temps de correction est parfois énorme (plusieurs années) ! Du coup la faille a largement le temps d'etre exploitée par d'autres hackers qui eux vont rester sur le principe du non-disclosure et se faire de l'argent sale. Du coup le responsible disclosure peut amener un abus des sociétés de développement qui se croient du coup à l'abris.
Un cas récent et intéressant je trouve est la position de la société Intevydis qui propose un module pour l'outil CANVAS d'Immunity. Le 0day est donc le business de cette société. Celle ci a donc fait une réponse concernant son choix de ne pas pratiquer le responsible disclosure. Celle ci explique que les sociétés de développement profitent des cabinet de recherche en vulnérabilité et se reposent sur elle, attendant que celles ci leur soumettent les vulnérabilités et appliquent le Responsible disclosure que j'expliquerai par la suite. Ceci n'est pas faux. A mon sens, le travail généré pour la recherche et l'aide à résoudre doit etre payé et en prime doit passer prioritaire si la criticité l'impose, chose qu'elles ne font jamais. Cependant leur explication sur le fait que les grosses sociétés ont des moyens pour sécuriser leur application ne tient pas la route car les moyens ne donnent pas forcément la compétence :) . Du coup on peut mettre énormement d'argent et avoir quand meme des bugs qui passent à la trappe.
Un autre point de vue intéressant est celui qu'a donné Laurent Gaffié lors de ses publications sur la vuln SMBv2. Lors de sa première publication, il lui a été reproché de ne pas avoir prévenu Microsoft. Cependant la 2e fois, voulant bien faire, il a pratiqué le responsible disclosure mais a constaté devenir le larbin de la société souhaitant obtenir le maximum d'information, la manière de trouver la vuln, la correction ... bref de les assister sans rémunération. Et ca faut avouer que ca donne pas envi d'etre très responsable :)
Donc que faire dans tout ca ? Et bien ce que l'on semble de mieux :) Tout dépend de l'objectif de la publication, d'ou on se situe dans le monde de l'informatique (professionnel, passionné, pirate) et de ce qu'on l'on souhaite obtenir en retour : de l'argent, flatter son égo ou une bonne conscience :)
11-01-2010 00:36:12
[Tool] Lire ses SMS iPhone depuis son PC
Avant toute chose, bonne année à tous :)
Un ami a eu la bonne idée de m'offrir un dock pour iPhone. Du coup mon téléphone est tout le temps connecté mais également hors de portée quand je suis sur mon PC. Et quand je l'entend au loin faire son "Tududuuu" qui signifie qu'un nouveau SMS est arrivé, j'ai souvent la fleme de me lever. Du coup je me suis codé un petit script rapide afin de lire mes nouveaux SMS directement depuis mon shell (oui l'informaticien est feignant :) ) Celui ci est codé en Python. Si j'ai un peu de temps, je l'améliorerai pour faire la jointure avec la base de contact pour avoir le nom de la personne qui envoie le SMS et non juste le numéro.
Voici le code :
Un ami a eu la bonne idée de m'offrir un dock pour iPhone. Du coup mon téléphone est tout le temps connecté mais également hors de portée quand je suis sur mon PC. Et quand je l'entend au loin faire son "Tududuuu" qui signifie qu'un nouveau SMS est arrivé, j'ai souvent la fleme de me lever. Du coup je me suis codé un petit script rapide afin de lire mes nouveaux SMS directement depuis mon shell (oui l'informaticien est feignant :) ) Celui ci est codé en Python. Si j'ai un peu de temps, je l'améliorerai pour faire la jointure avec la base de contact pour avoir le nom de la personne qui envoie le SMS et non juste le numéro.
Voici le code :
#!/usr/bin/env python import socket import sys import os import paramiko from pysqlite2 import dbapi2 as sqlite ip = '' port = 22 username = '' password = '' sms_remote = '/private/var/mobile/Library/SMS/sms.db' local_file = '/home/cloud/coding/Python/iphonesms/' def start(): print ">> iPhoneSMS v0.1 by cloud : http://blog.madpowah.org" #Function which dl the sms db on the iphone def dlsms(): if (len(sys.argv) == 4): ip = sys.argv[1] username = sys.argv[2] password = sys.argv[3] else: print "Usage : ./iphonesms" print "Exemple : ./iphonesms 192.168.0.2 root monpass" sys.exit(0); print 'Downloading SMS db on :', ip, '...', t = paramiko.SSHClient() t.set_missing_host_key_policy(paramiko.AutoAddPolicy()) t.load_system_host_keys() t.connect(ip, port=port, username=username, password=password) ftp = t.open_sftp() try: sms_file_ok = local_file + ip + '-sms.db' ftp.get(sms_remote, sms_file_ok) print "SMS downloaded ..." except: print "No SMS :( ..." return sms_file_ok #Connection to the Sqlite DB def connexionDB(smslocal): try: connexion = sqlite.connect(smslocal) cursor = connexion.cursor() except: print "Error connecting Sqlite DB" return cursor def checkLastSms(smslocal): cursor = connexionDB(smslocal) i = 1 for row in cursor.execute("select * from message where read='0'"): print "Message %d" % i, print row[1], print row[3] return 0 def main(): start() smslocal = dlsms() checkLastSms(smslocal) os.remove(smslocal) return 0 if __name__ == '__main__': main()