rulururu

post Nouvelle attaque web

August 31st, 2008

Filed under: Sécurité — gryzor @ 08:01

Le monde de la sécurité web est impressionnant. Il regorge d’attaques parfois bien tordues, et difficiles à comprendre, et une fois de temps en temps, on nous “découvre” une nouvelle technique. Cette fois-ci c’est CSRF. Le point particulier de ce genre d’attaque, c’est qu’il n’y a rien de nouveau à savoir, n’importe qui ayant fait un tout petit peu de web la maîtrise déja… mais jusqu’ici sans le savoir. Bref, si cela doit démontrer une chose, c’est que personne ne maîtrise [plus] la sécurité du web.

Le point le plus amusant avec CSRF, c’est qu’il s’appuie sur une fonctionnalité fondamentale du web, présente depuis les version les plus antiques de HTTP : la possibilité d’inclure et d’adresser des éléments depuis d’autres sites web. Depuis quelques années, nous nous moquons des institutions dont les avocats ont créé une charte Internet qui interdit la création de liens hypertextes ou l’inclusion d’image ou d’autres objets sans leur accord. Avec CSRF, la question se pose : et s’ils avaient eu raison ?!

post Sécurité du modèle de développement des Logiciels Libres (2ème partie : quelques attaques)

August 30th, 2008

Filed under: Sécurité — gryzor @ 15:56

La plupart des projets développés en Logiciels Libres s’appuient sur des communautés de développeurs, qui se créent et évoluent au fil du temps selon les intérêts et talents de chacun. La méritocratie à la base de la constitution de ces communautés est-elle bien suffisante pour garantir l’intégrité des développeurs qui rejoignent un projet ?

Il semble que les projets LL disposent de peu de critères objectifs et stricts pour décider d’accorder à un contributeur des droits d’écriture sur tout ou partie du code. Les système simplement basés sur le vote des membres en place sont attaquables, par exemple par des attaques sociales. Un attaquant peut tâcher de devenir sympathique aux yeux de quelques membres clés, et cela peut suffire, en manifestant sa présence sur un salon IRC, et en envoyant les bons patches au bon moment…

Mettons nous à la place de vendeurs de Logiciels propriétaires/privatifs, qui n’ont pour certains eu de cesse ces derniers temps que de décrier les Logiciels Libres pour défendre leur bifsteak. Les moyens mis en oeuvre par ces acteurs sont parfois douteux, comme on le voit plus ou moins couramment lors de certaines campagnes de lobbying auprès d’institutions politiques. Ces vendeurs/éditeurs disposent de moyens colossaux, et peuvent vouloir nuire à tel ou tel projet, voire vouloir discréditer le Logiciel libre dans son ensemble. Si j’étais à leur place, je considérerais que payer des “taupes” pour infiltrer des projets et y semer du code dormant sur la durée pourrait être un moyen relativement efficace de parvenir à mes fins.

À la place, notamment, des distributions Linux, je me méfierais.

Suggestions :

  • Formaliser un délai minimum et incompressible entre les premiers contacts avec un développeur et son admission au titre de commiteur
  • Formaliser une politique sur le volume de code envoyé avant de gagner le moindre droit de commit
  • Formaliser une procédure de parrainage
  • Exiger une preuve d’identité de chaque développeur (et pourquoi pas un jour mettre en place une liste noire centralisée d’indésirables ?)

Aucun de ces moyens ne suffit à garantir l’intégrité d’un développeur, mais leur application conjointe pourrait ralentir considérablement les agissements d’un attaquant.

post Sécurité du modèle de développement des Logiciels Libres (1ère partie : les bonnes nouvelles)

August 30th, 2008

Filed under: Sécurité — gryzor @ 15:34

Le développement de logiciels libres relève, dans la plupart des cas, d’une initiative communautaire.
Une communauté de développeurs s’agglomère autour d’un projet, de manière relativement naturelle, en fonction des intérêts et des compétences des contributeurs.
Ainsi, pour joindre un projet et contribuer à son développement, il faut :

  • s’y intéresser. Que ce soit de manière personnelle, ou pour le compte d’une entité qui pousse à le faire contre un intéressement matériel, par exemple.
  • l’intéresser. Il s’agit de la fameuse notion de méritocratie que nous trouvons dans nombre de grands projets.

Tout est question de confiance et de légitimité gagnée. Logiquement, un contributeur qui propose ses compétences sur un projet ne reçoit pas au départ une très grande confiance : ses patches sont relus et (éventuellement) appliqués par d’autres, on ne lui demande pas son avis pour les questions d’architecture.
Quand la sauce prend (après quelques patches*(semaines|mois|années)), le projet peut commencer à reconnaître ce contributeur, et à lui attribuer des fonctions officielles. C’est ainsi que l’on gagne son “droit de commit”.

Ce modèle permet aux acteurs de se connaître avant de s’accorder la confiance de modifier le coeur des projets en question.

Bien entendu, les procédures diffèrent selon les projets. Très souvent, tout ceci est extrêmement informel. Mais pour certains gros projets, les choses ont été quelque peu structurées. Le projet Apache, par exemple,

  • fait voter les membres pour déterminer si une personne devrait gagner des droits de commit
  • exige la signature papier d’un accord au sujet de la propriété intellectuelle du projet : http://www.apache.org/licenses/icla.pdf.

post Naviguer de manière sécurisée

July 13th, 2008

Filed under: Sécurité — gryzor @ 16:43

Comme l’ont souligné plusieurs conférences du SSTIC, la sécurité des navigateurs web les plus utilisés est catastrophique. Je ne parle même pas d’internet explorer, le sujet a été exploré de multiples fois. Firefox n’est pas en reste : les worms, bankers et derniers virus en tous genre commencent à le gérer, ce qui souligne bien qu’il est vulnérable, d’une manière ou d’une autre à des attaques (cf la conférence du SSTIC sur Anserin).

Certaines recherches (EDIT : et la pratique) ont montré que Firefox est extrêmement perméable à des attaques visant l’utilisateur final : il est possible d’installer des extensions “fantômes”, c’est à dire que l’utilisateur de firefox n’a aucun moyen de détecter qu’une extension a été installée : aucune confirmation n’est demandée, l’extension n’apparaît pas dans la liste…

Par ailleurs, les extensions Firefox ne sont aucunement bridées : il s’agit de code qui tourne avec les privilèges système de l’utilisateur qui a lancé firefox, ni plus ni moins : une extension peut donc modifier à la volée les pages web avant affichage, envoyer des données confidentielles sur un canal caché, par exemple.

Le tableau n’est donc pas brillant, et les “protections” positionnées par certains sites web sensibles (comme celui de votre banque) ne sont pas de nature à [me] rassurer, puisque, bien sûr, éminement contournables!

Les mesures que je m’auto-préconise sont donc désormais :

– Rester en veille pour voir peut-être un jour l’émergence d’un navigateur conçu dès le départ pour être sécurisé

– Dans l’immédiat, utiliser des navigateurs alternatifs “spécialisés” pour les tâches sensibles. On peut citer, parmi d’autres, Konqueror, epiphany. Avec un peu de chance, ces navigateurs sont trop peu utilisés pour être ciblés par les auteurs de malware (en tous cas, de malware de masse…). Bien que je n’aie pas spécialement plus confiance dans leur design (parfois très proche de firefox d’ailleurs…), j’espère tomber dans une “niche”.

– Dans le même registre, mais de manière un peu plus stricte, s’appuyer sur la sécurité et le système de privilèges sous-jacent : créer des utilisateurs systèmes dédiés à mes tâches “sécurisée” comme payer mes impôts, me connecter sur le site de ma banque… Peut-être un système à trois niveaux pourrait-il se révéler intéressant :

  • un compte utilisateur pour le surf en zone non maîtrisée, dont je nettoyerais le profil à chaque démarrage du navigateur
  • un compte pour surfer sur les sites dont j’ai l’habitude, mais auxquels je n’accorde pas une grande confiance, dont j’auditerais la configuration aussi souvent que possible. Cette approche est cependant très limitée du fait de la mode du web 2.0… les sites web intègrent des “contenus” venant de leurs utilisateurs ou d’autres sites web…
  • enfin, un compte pour les applications sensibles. Avec la même restriction que ci-dessus, mais je me permets d’espérer que les administrateurs du site web de ma banque garderont la clairvoyance de ne pas passer leurs applications en Web 2.0…

– Utiliser des extensions pour améliorer la sécurité de Firefox, comme NoScript. Mais je reste persuadé que cela revient à appliquer des emplâtres sur une jambe de bois.

– Essayer d’auditer régulièrement la configuration de Firefox de chaque utilisateur de mes systèmes, et notamment les extensions installées/activées. J’en dirai un peu plus à ce sujet prochainement car j’ai des choses sur le feu …

post Batailles de zombies

March 2nd, 2008

Filed under: Sécurité — gryzor @ 11:58

On connaissait Echelon, les européens s’y mettent aussi (il n’y a qu’à voir certains appels d’offres de certaines entités françaises reliées à l’armée mais réalisant des tâches proches de la police dans les campagnes françaises)

La résultante logique de cette surveillance généralisée des réseaux est tout simplement le chiffrement. Les acteurs du marché sensibles à la confidentialité de leurs échanges : criminels pédophiles et autres terroristes divers, mais également citoyens sensibles et autres geeks se mettent à utiliser des protocoles chiffrés et , tant que possible, anonymisants.

(Au passage, choisissez bien votre protocole de chiffrement. Par exemple, il semble une mauvaise idée de se fier à des protocoles “améliorés” par la NSA… )

Les entités qui veulent contrôler globalement l’information réagissent donc depuis quelques années en mettant au point leurs propres rootkits (ici et aussi ici). En effet, pourquoi dépenser des ressources énormes pour déchiffrer des protocoles indéchiffrables, alors qu’il est tellement plus simple de manipuler l’information en clair directement sur l’ordinateur de notre cyber-pédo-citoyo-terroriste ?

Monsieur Dupont aura donc bientôt, en plus du robot zombie spammeur, le rootkit de la NSA, celui de la CIA, et un ou deux bons rootkits bien français.
Il sera intéressant de voir comment ces charmants “invités” se partageront l’espace et les ressources : sans doute essayeront-ils un peu de se battre entre eux. Mais peut-être qu’en v2 ils accepteront de collaborer “Salut zombie de la police française, moi, zombie de la CIA, je te laisse analyser les images de M. Dupont mais seulement si tu me laisses m’installer sur l’ordinateur de Madame Michu”.

On devrait tout de suite commencer à écrire le protocole de négociation inter-zombie, ça promet d’être interessant. Bien entendu, officiellement, aucun zombie n’acceptera de négocier avec le spammeur …

post Le puit sans fond de la sécurité Web

February 24th, 2008

Filed under: Sécurité — gryzor @ 12:47

Pas une semaine sans qu’on ne découvre des trous de sécurité béants dans des services en ligne, des applications web, les languages eux-mêmes.
Sans compter que les technologies elles-mêmes évoluent à une vitesse conférant au dirty hacking.

Dernière plateforme unifiée d’authentification à la mode, OpenID, et un excellent document expliquant les possiblités génériques de phishing offertes par cette technologie. La conclusion est simple : si on veut partager une authentification avec des milliers d’autres sites web, s’appuyer sur un modèle de secret partagé (le couple login/password) est totalement hors de question, car tout le monde se retrouve à partager les mêmes, pour un utilisateur donné…
Bref, il reste du travail (comme pour le reste ) …

Les services web sont tradiditionnellement très vulnérables, peut-être parce que :

  • Beaucoup de développeurs sont peu qualifiés, ou au moins peu sensibles aux problèmes de sécurité
  • Ces services sont enrichis par une interaction (entre eux, et avec les utilisateurs) très grandissante, ce qui complexifie à outrance les problèmes de filtrage des données, et les “déports de confiance”

À la louche, quelques outils, dont l’énumération, à défaut d’être originale, pourrait être utile :

  • Coté serveur, sécurité web avec PHP : l’incontournable suhosin, relativement simple à déployer
  • Toujours coté serveur, un très grand classique est bien sûr mod_security, dont la difficulté de configuration a comme pendant une exceptionnelle souplesse
  • Coté client, NoScript est un must, et se montre utilisable avec un minimum de bonne volonté par tout utilisateur
  • Pour les [maudits] développeurs qui travaillent avec PHP, voyez aussi ce post de haypo sur le profiling PHP

post Sécurité et Darwinisme

November 1st, 2007

Filed under: Sécurité — gryzor @ 18:32

Linus Torvalds présentait le bazar des Logiciels Libres comme une jungle, un milieu naturel où seuls les projets adaptés à leur environnement survivront.
On peut sans doute étendre ce concept un peu plus largement, et notamment dans le domaine de la sécurité. Les projets qui gèrent réellement la sécurité ont toutes les chances, sur une échelle de temps suffisante, de voir leurs utilisateurs et/ou clients augmenter. Alors que les projets vulnérables devraient voir le nombre de déçus exploser avec le temps.
Dans les faits, ceci peut être sans doute ponderé par de nombreux autres facteurs : utilisabilité, ergonomie, marketing, étendue des fonctionnalités…

Mais après tout, peut-être que des stratégies, qui fonctionnent dans la nature, pourraient être utilisées dans la sécurité des projets d’information?
Par exemple, ces animaux qui prennent l’apparence de prédateurs de leurs prédateurs pour les faire fuire, ou qui essaient de se camoufler totalement pour passer inaperçu… Après tout, n’importe quel partisan d’une sécurité un peu stricte fustige de tels comportements 😉

À pondérer, car les prédateurs sur internet ont beaucoup moins de contraintes à satisfaire pour attaquer…

ruldrurd
« Previous Page
Powered by WordPress, Web Design by Laurentiu Piron
Entries (RSS) and Comments (RSS)