Sortie d'un utilitaire de fuzzing Bluetooth BSS v0.6

Posté par  . Modéré par rootix.
Étiquettes :
0
7
fév.
2006
Sécurité
Dans le cadre d'un dossier d'une dizaine de pages, vous trouverez un tutoriel sur la sécurité du protocole de communication sans-fil Bluetooth reprenant les attaques déjà connues (Helomoto, Bluebug, etc etc ...). Vous y trouverez également la première version diffusée par Secuobs d'un utilitaire (BSS - Bluetooth Stack Smasher) destiné à tester la sécurité de ce protocole.

D'après les tests effectués par l'équipe de ce site, plusieurs éléments mobiles sont faillibles aux opérations de fuzzing. Cet utilitaire développé par Pierre Betouin de la société Infratech a été placé sous licence GPL.

On notera parmi les résultats la présence d'un Déni de Service dans la version 1.29 de hcidump, mais également dans la pile Bluetooth de plusieurs téléphones portables des marques Sony/Ericsson, Samsung et Nokia. Les fonctions Bluetooth avaient été activées, ce qui n'est pas le cas par défaut sur ces appareils. Le fuzzing consiste à incrémenter automatiquement différents paramètres dans les requêtes lancées à l'encontre d'une application afin d'y découvrir des exceptions de traitement aboutissant peut être à une faille potentielle comme un Déni de Service (DoS) résultant d'un dépassement de tampon (Buffer Overflow) par exemple.

Deux codes de type PoC (Proof of Concept) sont disponibles ; ces codes permettent de démontrer de la faisabilité de ces failles hors utilisation de BSS.

Le protocole Bluetooth semble avoir été plutôt bien développé d'un point de vue sécurité, ses implémentations rapides ne sont malheureusement pas toujours de la même facture. Conseil de l'auteur, n'activez ces fonctions que lorsque vous en avez besoin.

Aller plus loin

  • # Fuzzing, une technique très intéressante

    Posté par  (site web personnel) . Évalué à 10.

    Bien que je ne l'ai jamais essayée, je trouve la technique du « fuzzing » très intéressante. Effectivement, tous les rapports de fuzzing que j'ai lu montraient des plantages dans la majorités des logiciels testés (tous dans certains cas). Pour ceux qui ne connaissent pas, le fuzzing consiste à envoyer des données plus ou moins aléatoires (l'idéal étant d'être proche du protocole mais en faisant varier les paramètres aléatoirement) à un programme et attendre sa réaction :-) Cela permet de rapidement (enfin, disons que c'est moins éreintant que la rétro-ingénierie) trouver des erreurs de programmation qui peuvent se révéler être des failles de sécurité.

    La magasine MISC numéro 22 (Jan/Fév 2006) y consacre un article de 8 pages très intéressant (fuzzing de client IRC, de navigateur web, le lecteurs multimédias, etc.). Je me demande si les personnes qui utilisent ces outils remontent les erreurs aux auteurs des logiciels…

    Haypo qui espère ne pas avoir dit trop de bétises

    • [^] # Re: Fuzzing, une technique très intéressante

      Posté par  (site web personnel) . Évalué à 5.

      Ben, pour la remonté d'erreur, j'ai rien vu passer sur la ML de bluez ...

    • [^] # Re: Fuzzing, une technique très intéressante

      Posté par  . Évalué à 5.

      Une meilleure formulation de la question peut être, pourquoi les auteurs de logiciels ne développent pas ce genre d'outils pour tester leurs logiciels eux même ? Ou pourquoi ils n'utilisent pas les outils disponibles pour le faire en les adaptant un minimum ?

      • [^] # Re: Fuzzing, une technique très intéressante

        Posté par  (site web personnel) . Évalué à 5.

        A priori je dirais parce que les développeurs n'ont pas le temps, l'envie ou la connaissance pour faire des tests unitaires (tester un bout du code), d'intégration (mettre bout à bout les différentes parties), du système (tester l'intégration de l'ensemble), de régression (la nouvelle version n'est pas pire que l'ancienne), de charge (comportement en multipliant les utilisations simultanéesi, ou en augmentant la taille des données à traiter), de performance (rapidité du logiciel dans une situation donnée), de stress (soumettre des données atypiques ou erronées pour étudier la robustesse), de sécurité (rechercher des problèmes de sécurité dans le code ou l'algorithme), d'installation (le logiciel s'installe correctement et sur toutes les configurations logicielles et matérielles souhaitées), d'utilisabilité (mesurer comment le logiciel permet bien aux utilisateurs de faire ce pour quoi il est fait), de stabilité, d'acceptation par l'utilisateur, de conformité (respect de normes, formats, protocoles, etc.), de couverture (chaque ligne de code est testée, ou recherche de code inutile), etc., etc.

        Globalement un projet parfait pour un hacker pur nécessiterait un temps quasi infini (et je passe sur les blagues sur hacker vaillant rien d'impossible).

        Parfois les développeurs font une partie de ces tests sur leur projet, parfois un type motivé lance un type de tests sur plein de projets (genre recherche d'une faille de sécu donnée sur l'intégralité des sources du projet Debian), parfois un organisme écrit un papier sur tel ou tel sujet et réalise un audit de divers projets, mais globalement tous les tests ne sont pas réalisés sur tous les projets, cela nécessiterait probablement un temps infini, un argent infini, un nombre infini de développeurs, un nombre infini d'ordi. et personne n'a trouvé « La méthode pour trouver des vies infinies dans les jeux qui sont trop difficiles sinon (LMPTDVDLJQSTDS) » (référence cachée).

        • [^] # Re: Fuzzing, une technique très intéressante

          Posté par  . Évalué à 1.

          C'est quand même dommage ce peu de considération pour l'utilisateur final, les solutions commerciales propriétaires sont souvent vendues suffisament chères pour embaucher des personnes spécialisées qui ont cette envie et les connaissances nécessaires en plus des développeurs "réguliers".

          Je ne parle pas içi des logiciels libres, le concept est différent sur le fond à l'exception peut être de ceux qui en tirent un profit. Si on ne peut pas garantir le résultat, on peut tout au moins engager les moyens.

          Ca me fait penser à "certaines" banques qui préfèrent se payer une bonne assurance plutôt que d'auditer sérieusement leur application parceque ça leur coûte moins cher finalement.

          C'est certain que la sécurité d'une application pour être optimale est un puit sans fond, mais on observe quand même assez régulièrement le non respect des rêgles de base pour des solutions qui une nouvelle fois sont achetées à un prix non négligeable pour la plupart.

          Sans parler de ceux qui basent leur argumentation commerciale sur la pseudo-sécurité de leur applicatif ... "unbreakable" (référence non cachée)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.