Il ne sera plus possible de se faire pirater sa connexion sécurisée en ligne. Telle est la promesse de la nouvelle version du protocole SSL, tout juste proposée par l’IETF (Internet Engineering Task Force) et rapidement ratifiée. Désormais, aucun pirate ne devrait pouvoir s’interposer entre un utilisateur et son réseau d’entreprise, le site sécurisé de sa banque ou encore l’interface d’administration d’un centre de données. Rappelons que dans de tels scénarios, les objectifs des pirates sont multiples : soit voler les clés, les codes des cartes bancaires ou encore le mot de passe de l’utilisateur, soit le rediriger vers un autre serveur sans qu’il s’en aperçoive.

Une faille subtile

La norme SSL sert déjà à chiffrer les communications entre un client et un serveur pour éviter qu’elles soient sur écoute. Mais son évolution a été motivée par une faille découverte en novembre dernier.

A l’époque, des chercheurs s’aperçoivent que le serveur ne vérifie pas qu’il converse toujours avec le même client à la suite d’une micro-interruption. Et pourtant, un pirate pourrait d’abord établir une communication sécurisée vers le serveur avec sa propre clé, puis se servir d’une micro-interruption pour s’intercaler entre le client d’un utilisateur et le serveur.

Cette attaque est assez subtile, car la communication entre le serveur et le client s’effectue à pleine vitesse, sans que personne ne remarque que le flux d’informations est détourné. Et il l’est, puisque toutes les informations transitent dès lors par la machine du pirate. Celui-ci étant à l’initiative de la création de la clé, il lui est ensuite simple de décoder les informations qu’il détourne.

Suite à la découverte de cette faille, un étudiant turc l’exploitait pour détourner des comptes Twitter. Dès lors, de nombreux sites ont interdit la procédure de renégociation, laquelle sert à reconnecter un client après une micro-interruption.

La correction sera longue

Dans sa nouvelle version, SSL signe cette renégociation. Autrement dit, le serveur identifie avec certitude le client avec lequel il dialogue. Cela signifie que, pour continuer à détourner les données, le pirate devrait injecter en temps réel sa signature à la place de celle du client dans un flot d’informations chiffrées, une opération jusque-là impossible à réaliser.

Reste qu’il faudra un certain temps avant que le correctif soit pris en compte sur les serveurs et les clients qui utilisent SSL. Selon les chercheurs qui avaient détecté la faille, cela pourrait prendre des mois. Ils maintiennent une page qui suit l’avancement du correctif dans les principaux produits de connexion SSL, dont Firefox, Internet Explorer, IIS, ou encore OpenSSL.

Lire l’article sur : 01net Pro…

Merci à Benoit Minvielle, Hirschmann pour le lien vers cette information.

Partager cette information :

Deuxième mauvaise nouvelle dans le monde de la sécurité, la clé RSA de 768 bits à été craqué. Il a fallu quand même 1 à 1700 cœurs sur 425 machines et  12 mathématiciens / chercheurs pour casser cette clé de 232 caractères. Casser le chiffrement RSA 1024 bit devrait prendre de 3 à 4 ans. Une clé de 2048 bits est donc maintenant recommandée pour garantir l’inviolabilité de ‘l’information (mais pour combien de temps ?)
Lire cet article à ce propos sur 01netPro…

Partager cette information :

Cisco a proposé cette semaine un patch afin de mettre à jour ses routeurs et ses commutateurs contre des attaques par Déni de Service (DOS ou Denial Of Service).
La faille permet aux hackers de manipuler l’état des connexions TCP, selon Cisco. Conséquence, la connexion TCP peut rester active longtemps, voire indéfiniment. En conservant suffisamment de connexions TCP actives, cela consomme des ressources sur la machine, empêchant d’ouvrir de nouvelles connexions TCP, aboutissant à un début de DOS.
Le bug avait été découvert il y a un an, par un fournisseur de sécurité suédois. Les produits concernés sont :
- les routeurs et les commutateurs fonctionnant sous IOS, IOS-XE, et CatOS,
- les appliances ASA et Cisco Pix dans leurs versions 7.0, 7.1, 7.2, 8.0 et 8.1,
- certaines configurations de produits sous NX-OS tels que les commutateurs Nexus 5000 et 7000,
- les produits de Scientific Atlanta (modem câbles) et Linksys (produits pour la maison et les PME).

Lire l’article complet sur : Réseaux & Télécoms…

Partager cette information :

C’est ce qui s’appelle mettre les bouchées doubles. Les chercheurs japonais Toshihiro Ohigashi et Masakatu Morii viennent de montrer une nouvelle technique qui permet de briser le chiffrement WPA/TKIP des communications Wi-Fi en une minute, montre en main.

Cette nouvelle technique s’appuie sur l’attaque dite de « Beck-Tews », qui a été découverte en novembre 2008 par deux chercheurs allemands et qui permettait déjà d’intercepter en clair quelques paquets Wi-Fi et de les modifier.

Plus rapide et mieux applicable

En couplant cette technique avec une interception de type « man-in-the-middle » (1), les deux Japonais arrivent à réduire le temps d’exécution de l’attaque de quinze minutes à quelques minutes, voire à seulement soixante secondes.

Ils arrivent également à élargir le cadre d’application. L’attaque Beck-Tews ne fonctionnait qu’avec des équipements supportant certaines fonctions de qualité de service du WPA. Toshihiro Ohigashi et Masakatu Morii, au contraire, sont capables de cibler toutes les implémentations du WPA/TKIP. Les deux chercheurs donnent les détails de leur attaque dans un article scientifique.

Il faut souligner que le chiffrement basé sur WPA/AES ou WPA2 n’est pas concerné par cette attaque. Les entreprises qui utilisent des réseaux Wi-Fi ont donc tout intérêt à délaisser le WPA/TKIP et à s’orienter vers ces deux technologies alternatives.

Lire l’article sur : 01net Pro…

Partager cette information :

Est-ce que la mégafaille DNS de cet été est désormais un problème résolu dans le monde d’Internet ?

Cricket Liu : Malheureusement non. Nous venons justement de réaliser, en octobre 2008, une étude sur les serveurs DNS. Sur les 11,9 millions de serveurs existants, 44 % répondent à des requêtes dites « récursives ouvertes », c’est-à-dire que n’importe qui peut les interroger sur des adresses DNS. Ce qui constitue déjà un risque en soi.

Parmi ces serveurs déjà fragilisés, le quart d’entre eux n’appliquent pas le patch de Dan Kaminsky. Ce correctif complique la tâche aux pirates en introduisant un choix aléatoire du numéro de port dans les requêtes DNS. Au final, cela représente donc plus d’un million de serveurs qui ne sont pas protégés vis-à-vis de la faille de cet été. C’est encore beaucoup trop. Il reste encore du pain sur la planche.

Cette faille a-t-elle déjà servi pour des actes de piraterie ?

Elle a servi dès le jour de sa publication. Cela a été relevé dans des rapports de sécurité. Mais il très difficile d’évaluer l’étendu du problème. On ne peut pas ausculter tous les serveurs DNS pour voir s’ils sont corrompus ou non. Ce serait comme chercher une aiguille dans une botte de foin.

Mais le danger est réel. Grâce à cette faille, les hackers malintentionnés peuvent, par exemple, détourner le trafic e-mail ou usurper le nom de sites Internet.

…

Ne vaudrait-il pas mieux réécrire le protocole DNS ?

Ce serait beaucoup trop compliqué vu l’adoption d’Internet aujourd’hui. C’est pourquoi au sein de l’Internet Engineering Task Force, aucun projet de refonte du DNS n’a vu le jour jusqu’à maintenant. Déployer un nouveau système DNS nécessiterait la mise à jour de tous les équipements Internet. C’est une tâche titanesque, à comparer avec l’IPv6 qui, on le voit, a beaucoup de mal à se faire une place. A ce jour, seul 0,44 % des serveurs DNS utilisent IPv6.

Donc la seule solution, c’est DNSsec ?

En effet, c’est la solution qu’il convient d’adopter aujourd’hui. Elle permet de signer électroniquement les échanges de données pendant les requêtes DNS et donc d’identifier clairement les serveurs DNS. Malheureusement, l’adoption de DNSsec est très lente. Nous avons testé près d’un million de zones Internet. Parmi elles, seules 45 utilisent DNSsec. C’est très peu.

Il faut dire que ce protocole de sécurité est assez difficile à implémenter. Les outils mis à disposition des administrateurs sont très rudimentaires. Par ailleurs, il y a un effet réseau : pour que DSNsec servent à quelque chose, il faut qu’un grand nombre de serveurs l’utilisent. En Europe, DNSsec est davantage implémenté qu’aux Etats-Unis. Des pays comme la Suède ou la Hollande sont particulièrement en avance sur ce sujet.

Lire l’article sur : 01net…

Partager cette information :

A noter que le WPA2 qui utilise une autre méthode de codage n’est pas concerné par cette faille. Il est donc urgent de migrer vos point d’accès Wi-Fi vers cette méthode de protection.

Petite secousse dans l’univers des réseaux sans fil : selon différentes sources d’information, dont le site spécialisé securityfocus.com, deux chercheurs allemands, Martin Beck et Erik Tews, auraient décelé une faille importante dans le WPA (Wi-Fi Protected Access), le mécanisme de sécurisation des réseaux Wi-Fi le plus répandu à l’heure actuelle. Les deux chercheurs en informatique assurent avoir trouvé une manière de mettre à mal le principal algoritme de chiffrement de la norme WPA, l’algorithme TKIP (Temporal Key Integrity Protocol). Et ce, en un temps relativement court, soit entre 12 et 15 minutes environ.

Selon eux, grâce à leur procédé, on pourrait intercepter en clair un petit nombre de paquets en provenance d’un point d’accès Wi-Fi sécurisé par WPA vers un poste client. Mais aussi de les modifier au passage. Leur méthode, qui sera dévoilée lors de la conférence PacSec de Tokyo la semaine prochaine, récupérerait un certain nombre de clés temporaires utilisées dans l’algorithme TKIP. Toutefois, les clés permettant de déchiffrer les données allant de l’ordinateur vers le point d’accès ne seraient, quant à elles, pas encore menacées par cette méthode.

…Rappelons que la norme WPA a été mise au point pour pallier les insuffisance du WEP, devenu largement craquable au fil du temps. Jusqu’à maintenant, le WPA était réputé comme fiable.

…Menace possible de déni de service

Sur ce point, il semblerait que la vulnérabilité ne permette d’effectuer que des attaques de type « déni de service » en servant sur le réseau Wi-Fi des messages erronés. « La méthode semble consister à sélectionner des paquets volontairement très petits, ceux du protocole ARP par exemple, de 14 octets environ. Or, ce protocole est utilisé pour faire des résolutions entre l’adresse Ethernet Mac et l’adresse IP. Elle pourrait donc théoriquement servir à planter toutes les sessions clientes d’un point d’accès. Il n’est pas certain qu’avec des paquets plus gros (donc d’autres protocoles) cette attaque puisse donner de bons résultats ».

Lire l’article en entier sur 01net…

Partager cette information :

DNSSEC a été créé il y a dix ans pour éviter la corruption des données et l’usurpation d’identité au sein du système DNS. En effet, chaque navigation Internet fait intervenir des requêtes DNS pour traduire les noms des sites Web en adresses IP. Cela se fait de manière récursive et hiérarchique : quand un serveur de nom d’un sous-domaine ne sait pas répondre, il se réfère aux serveurs du domaine supérieur qui fera de même. Pour un hacker, les occasions d’intercepter les données et de les modifier sont donc nombreuses. DNSSEC propose d’assurer l’intégrité des informations fournies par l’ajout, à chaque échange, d’une signature chiffrée qui va authentifier le serveur de nom. Et le tour est joué.

Seulement voilà, l’implémentation de DNSSEC est loin d’être simple. Tout d’abord, l’adjonction d’une signature chiffrée nécessite des paquets DNS de plus grande taille. Il faut donc utiliser le protocole Extended DNS. « Mais seuls 40 % des "resolvers" [logiciels client pour la traduction DNS, NDLR] supportent actuellement EDNS », explique Raphaël Marichez, consultant sécurité chez Hervé Schauer Consultants.

Le ticket d’entrée est élevé

La signature fait également augmenter sensiblement le trafic réseau et ajoute des temps de calcul. Par ailleurs, DNSSEC suppose la mise en place d’une véritable architecture PKI, ce qui est complexe et coûteux. Enfin, pour que la sécurité soit vraiment assurée, il faudrait installer la technologie dans tous les pays et à tous les niveaux, du serveur DNS dans l’entreprise aux serveurs racines.

Ces différents obstacles expliquent pourquoi, en l’espace d’une décennie, les déploiements DNSSEC sont encore peu nombreux. A ce jour, seuls quatre pays ont implanté ce protocole de sécurité : la Suède, la Bulgarie, le Brésil et Porto Rico. « D’un point de vue économique, le déploiement de DNSSEC à grande échelle ne se justifie pas », poursuit Raphaël Marichez.

En savoir plus sur : 01net

Partager cette information :

Hors une faille de DNS Cache Poisonning (connue depuis longtemps mais non corrigé car elle semblait compliquer à exploiter) vient d’être publiquement dévoilée lors d’une conférence par Dan Kaminsky) (avant qu’il fasse la démonstration début août de son exploitation). Tous les serveurs DNS sont concernés (ceux connectés sur Internet) par cette faille de sécurité et il est urgent d’appliquer un correctif (déjà publiés entre autre par Cisco, Microsoft, Red Hat,… pour leurs produits) car cette faille permet à un pirate de se faire passer pour un serveur « fiable » et autorisé.

C’est la première fois qu’une telle coordination a lieu. Mardi, alors qu’au cours d’une conférence de presse, un chercheur en sécurité, Dan Kaminsky, dévoilait une faille importante dans le protocole DNS (Domain Name System), pierre angulaire du fonctionnement d’Internet, plusieurs éditeurs parmi lesquels Microsoft, Cisco, Red Hat, Sun Microsystems et l’Internet Software Consortium publiaient, dans un timing parfait, un correctif de cette faille pour leurs propres produits.

Il faut dire que cette faille, si elle est exploitée pourrait avoir des effets « horribles ». « Les conséquences de cette faille sont gravissimes et leur ampleur est difficile à imaginer », assure un consultant d’Hervé Schauer Consulting, HSC, cabinet spécialisé dans la sécurité.

Cette vulnérabilité qui touche le coeur du protocole DNS et concerne donc, a priori, tous les systèmes d’exploitation, est une attaque de type DNS Cache Poisoning – contamination du cache DNS. Les serveurs dont le cache est contaminé accueillent les informations de serveurs pirates comme étant celles de vrais serveurs. Ainsi, un internaute se retrouvera à utiliser des services contrôlés par les pirates alors que son serveur lui dira qu’il est sur le bon service. Est concerné le trafic Web, mais aussi les e-mails qui peuvent être détournés.

« Cette faille du protocole DNS est connue depuis longtemps, assure le consultant d’Hervé Schauer Consulting, ce que le chercheur a démontré, c’est surtout qu’elle pouvait être exploitée beaucoup plus facilement qu’on ne le pensait jusque là ». Pour l’instant, aucune attaque exploitant la faille n’a été répertoriée.

Si Cisco, Microsoft et les autres, ont pu réagir avec cette précision de métronome, c’est parce que le chercheur Dan Kaminsky les a alertés depuis six mois sur sa découverte. Une quinzaine d’experts se sont alors réunis fin mars de manière confidentielle pour travailler sur les correctifs.

…

Mais qui est réellement concerné ? Toutes les entreprises qui gèrent leurs propres DNS, c’est à dire généralement les grandes entreprises, et toutes la chaîne de gestion des DNS, des fournisseurs d’accès à Internet, des hébergeurs, etc. Pour vérifier si l’on est vulnérable aux attaques, le chercheur a mis au point un test en ligne sur Doxpara.com.

Si votre site se révèle vulnérable, « il faut vous adresser au prestataire de service qui gère votre DNS », explique Loïc Damilaville, adjoint au directeur général de l’Afnic, ou faire la mise à jour de vos matériels si vous les gérez vous-même.

« De nombreux matériels, comme les box grand public, intègrent un serveur DNS », ajoute le consultant de HSC. Du côté de chez Cisco, quatre gammes de produits sont concernées à cause de leur implémentation du protocole DNS. Les plus répandus sont les routeurs qui utilisent le système d’exploitation IOS de Cisco. « Mais, pour être vulnérable à cette faille, il faut que le serveur DNS soit activé dans le routeur, or, par défaut, il est désactivé », note Christophe Perrin, responsable du développement du marché de la sécurité chez Cisco, « la criticité est plus grande pour les matériels et logiciels qui sont directement utilisés en tant que serveurs DNS ». Il conseille donc de ne faire la mise à jour immédiate que pour ces matériels.

Microsoft et Red Hat dans la même faille

C’est le cas de Microsoft qui a publié un correctif, concernant Windows 2000, XP, 2003 et 2008. Vista échappe à la faille comme Windows Server 2008 pour les systèmes Itanium.

Autres correcteurs : Red Hat et ICS. Red Hat a fourni les patchs pour les principales distributions Entreprise (2.1, 3 et 4 et 5) qui utilisent les versions de BIND (9.3, 9.4 et 9.5) d’ICS, elles-mêmes contaminées et corrigées.

Si le patch comble la faille, il risque aussi de ralentir les performances du serveur DNS. En effet, la correction consiste à rajouter des routines qui vont compliquer le dialogue entre le serveur DNS et celui qui l’interroge (serveur ou client), et par là même le ralentir.

Le CERT (Computer Emergency Readiness Team) US a publié une liste des constructeurs et des produits qui sont vulnérables à la faille. Le niveau de la vulnérabilité de la plupart des constructeurs et éditeurs cités est actuellement « inconnu », seuls ceux ayant publié des patchs étant identifiés comme « vulnérables ».

Pour les principaux intéressés, il reste quelques semaines pour faire la mise à jour. Début août, lors de la Black Hat Conference, Dan Kaminsky a annoncé qu’il donnerait plus de détail sur la faille en question. Et notamment, comment elle peut être exploitée. A vos patchs !

Lire l’article sur : 01net…

Partager cette information :