Attaques à Paris : le chef de la NSA met en cause le chiffrement

Qui, selon lui, aurait empêché de prévoir ces attaques

  Au lendemain des attaques de Paris survenues le 13 novembre dernier, plusieurs voix se sont levées pour pointer du doigt les techniques de chiffrement des communications qui selon certaines personnes auraient été utilisées dans la mise en œuvre de ces attaques.

Alors qu’aucune source officielle n’a jusque-là confirmé ces affirmations, l’amiral de la marine américaine Michael Rogers, également directeur de la NSA, a accordé une interview à un journaliste de Yahoo il y a quelques jours afin de donner quelques informations à ce sujet.

Pour le directeur de la NSA, « certaines communications » utilisées par les attaquants « étaient chiffrées », ce qui n’a pas permis aux agences de surveillance américaine d’anticiper sur leurs actions. Pour lui, ces attaques « ne seraient pas survenues » si ces derniers n’avaient pas fait usage de moyens de communications chiffrées.

Il faut préciser que ces récentes déclarations surviennent dans un contexte fortement polarisé par l’affaire d’Apple. En effet, suite à la décision de justice ordonnant à Apple d’aider le FBI à accéder aux données d’une des personnes auteur de la fusillade de San Bernadino, Apple a fait savoir qu’il s’opposait à cette décision exigeant de fournir aux agences américaines des moyens détournés pour déverrouiller d’une manière ou d’une autre l’iPhone 5C de l’attaquant.

À travers les déclarations de Rogers, l’on pourrait donc entrevoir une volonté d’attirer l’attention des acteurs IT sur les éventuelles dérives qu’une telle action pourrait occasionner. Pour mieux étayer son propos sur les conséquences du chiffrement, Rogers n’a pas usé de voies détournées pour faire savoir que certains types de chiffrement entravent fortement les actions des forces de l’ordre dans leurs missions.

« Est-il plus difficile pour nous de générer le type de connaissances que j’aimerais avoir contre certaines de ces cibles ? Oui », a déclaré Rogers. « Est-ce en partie directement lié aux changements qu’elles utilisent dans leurs communications ? Oui. Est-ce que le chiffrement fait qu’il est beaucoup plus difficile pour nous de mener à bien notre mission ? Oui », a fait savoir le chef de la NSA à Yahoo.

Il faut souligner par ailleurs que la position de Rogers en matière de chiffrement des appareils est connue de tous depuis bien longtemps. Pendant un discours qu’il donnait à l’université de Princeton, Rogers n’a pas manqué d’affirmer « qu’il ne voulait pas de backdoor, mais plutôt un frontdoor ».

La surprise ne fut donc pas grande quand il proposa, lors du 6^e sommet annuel de l’Association des Forces armées pour l’Électronique et les Communications (AFCE), la création d’une clé de déchiffrement permettant d’accéder à n’importe quel appareil verrouillé dont les différentes parties seraient réparties entre plusieurs entités afin d’empêcher son utilisation unilatérale.

Revenant sur les attaques de Paris, il faut savoir que le rapport de police produit aux premières heures des attentats souligne que les forces de l’ordre ont retrouvé dans une poubelle le téléphone d’un des terroristes contenant le message suivant : « On est parti ». Le message aurait été envoyé juste avant les attaques du Bataclan.

Mais étant donné que ce n’est probablement pas le seul message qu’ont échangé les terroristes, il serait difficile de se prononcer sur les propos du chef de la NSA. Les attaquants ont-ils véritablement utilisé des communications chiffrées ? Le cas échéant, est-ce cela qui aurait empêché de détecter à l'avance ces attaques ? Ou est-ce uniquement pour orienter les acteurs IT vers l’affaiblissement des mécanismes de chiffrement que ces propos sont tenus ?

Source : Yahoo, Daily Mail

Le cheval de Troie Metel a permis à des malfaiteurs de transformer leur carte de crédit ordinaire

En carte de crédit illimité

Kaspersky a donné des détails sur Metel, le cheval de Troie qui comprend plus de 30 modules qui peuvent être adaptés pour infecter les ordinateurs cibles. L'un de ces modules phares permet d'annuler automatiquement une transaction faite dans un distributeur automatique peu après qu'elle ait été opérée, permettant aux malfaiteurs de retirer plusieurs fois de l'argent. Parce que le module Metel réinitialise le solde des cartes à plusieurs reprises, les malfaiteurs n'atteignent pas le seuil qui déclencherait normalement un blocage de la carte. Kaspesky a expliqué que l'année dernière, ce cheval de Troie a fait perdre à une banque russe gardée sous anonymat des millions de roubles en une seule nuit.

« En 2015, les criminels derrière Metel se sont attaqués aux banques, en particulier aux distributeurs automatiques. En combinant leur bon sens et une campagne malveillante, ces criminels ont transformé leur carte de crédit ordinaire en carte de crédit illimité. Imaginez un instant pouvoir imprimer de l'argent, mais en mieux », ont rappelé les chercheurs de Kaspersky.

Mais comment s'y sont-ils pris ? Les criminels ont successivement infecté des ordinateurs d'employés de banque soit par une technique d’hameçonnage en se servant de courriels contenant des fichiers exécutables malveillants, soit en se servant de vulnérabilités du navigateur. Une fois dans le réseau, ils se sont servis d'applications légitimes pour pirater d'autres ordinateurs jusqu'à ce qu'ils parviennent à atteindre le dispositif qu'ils cherchaient (celui qui avait accès aux transactions monétaires, comme ceux des opérateurs de centre d'appel ou de l'équipe de support). Aussi, les criminels pouvaient par la suite retirer autant d'argent qu'ils le voulaient, étant limités uniquement par le montant disponible dans le distributeur automatique à ce moment-là.

« De ce que nous savons, la bande organisée est relativement petite et comporte dix personnes au maximum. Une partie de cette équipe parle le russe et nous n'avons détecté aucune infection en dehors des frontières russes. Les cybercriminels sont encore actifs et recherchent de nouvelles victimes », ont avancé les chercheurs.

Un exemple qui vient illustrer combien les attaques contre les banques deviennent de plus en plus sophistiquées au fil du temps. D'ailleurs les chercheurs ont donné deux autres illustrations de cette observation :

• « les criminels du groupe GCMAN sont passés par des opérations similaires sauf que, au lieu de voler des distributeurs automatiques de billets, ils ont opté pour transférer de l'argent dans des services de devises électroniques  », expliquent les chercheurs. Pour pénétrer le réseau, ils se servent des techniques traditionnelles d’hameçonnage (un courriel avec un objet malicieux attaché). Ils ciblent les dispositifs du côté de la comptabilité ou des ressources humaines et attendent que l'administrateur système se connecte au système. « Par la suite, les membres du GCMAN traversent littéralement le réseau de la banque jusqu'à ce qu'ils trouvent un dispositif, qui sera utilisé pour transférer silencieusement de l'argent dans différents services de devises électroniques. Dans certaines entreprises, les criminels l'ont même fait avec l'aide de logiciels légitimes ainsi que des outils de tests de pénétration comme VNC et Meterpreter ».
  
  Ces transactions ont été faites à partir script Cron qui a automatiquement transféré de petites sommes toutes les minutes à hauteur de 200 dollars à chaque fois, ce montant représentant la limite supérieure des montants de transactions financières anonymes en Russie. Les chercheurs estiment que le groupe est constitué au maximum de deux personnes qui parlent russe ;
  
  
  
• le logiciel malveillant Carbanak dans sa forme évoluée : ici, lorsqu'un ordinateur est infecté, les criminels cherchent à avoir accès au compte de l'administrateur système pour voler les identifiants afin de pirater le domaine, voler de l'argent des comptes bancaires et parfois changer les données relatives au propriétaire de l'entreprise.
  

Les chercheurs précisent que ces trois bandes organisées sont encore en activité et auraient infecté près de 29 entreprises en Russie. Ils ont également expliqué aux administrateurs comment les attaques par hameçonnage fonctionnent et comment les éviter, pourquoi il est nécessaire de faire des mises à jour logicielles, mais également des astuces pour se protéger des chevaux de Troie.

Source : Kaspersky

L'UE envisage de supprimer l'anonymat pour Bitcoin et les cartes prépayées

Dans le cadre de la lutte contre le financement du terrorisme

Le terrorisme est devenu ces dernières années l’une des questions de sécurité les plus préoccupantes, non plus seulement pour les États-Unis, mais aussi pour l’Europe. Mardi 2 février à Strasbourg, la Commission européenne (CE) a donc présenté un plan d’action destiné à combattre plus efficacement le terrorisme en renforçant la lutte contre le financement de ce phénomène.

L’objectif, d’après le premier vice-président de la Commission, M. Frans Timmermans, est de « priver les terroristes des ressources qu’ils utilisent pour commettre leurs crimes ». « En repérant et en tarissant les sources de financement des réseaux terroristes, nous pouvons réduire leur capacité à voyager, à acheter des armes et des explosifs, à planifier des attentats et à propager la haine et la peur sur la toile », a-t-il ajouté.

Le plan dévoilé se décline en plusieurs points. Mais estimant que les nouveaux instruments financiers et les nouveaux modes de paiement sont source de nouvelles vulnérabilités auxquelles il convient de remédier, la Commission européenne veut agir également sur les risques de financement du terrorisme liés aux monnaies virtuelles et aux instruments prépayés anonymes tels que les cartes prépayées. L’idée est de limiter au plus l’anonymat afin de tracer les réseaux de terroristes. Pour cela, la CE veut forcer les utilisateurs de monnaies virtuelles et des cartes de crédit prépayées à fournir plus de détail sur leur identité lors des opérations effectuées :

• la Commission propose d’inclure les plateformes de change de monnaies virtuelles dans le champ d’application de la directive anti-blanchiment, de manière à ce que ces plateformes doivent appliquer des mesures de vigilance à l’égard de la clientèle lors de l’échange de monnaies virtuelles contre des monnaies réelles, ce qui mettra fin à l’anonymat associé à ce type d’échange ;
• la Commission propose également d’abaisser les seuils en dessous desquels une identification n’est pas requise et d’élargir les exigences relatives à la vérification de l’identité des clients.

La CE devra donc proposer une nouvelle législation d’ici la fin du deuxième trimestre 2016 au plus tard visant à atteindre les objectifs qu’elle s’est fixés. Elle rassure également qu’elle va veiller à ce que ces mesures n’exposent pas les citoyens vulnérables sur le plan financier, qui sont des utilisateurs légitimes de Bitcoin et des instruments de paiements anonymes.

Source : Communiqué de presse de la Commission européenne

Google va désormais avertir les internautes en cas de soupçon d'une attaque d'ingénierie sociale

Via de faux boutons de téléchargement

Ayant un rôle de premier plan sur le web, Google veut tirer parti de sa position pour offrir une expérience web plus saine et plus sécurisée aux utilisateurs de Chrome en particulier, à travers son programme « Safe Browsing » (ou Navigation Sécurisée).

Depuis 2006, la fonction Navigation Sécurisée de Google a permis de protéger les utilisateurs contre les sites de phishing ; il s’agit de pages web qui ressemblent à des sites légitimes, avec pour but d’inciter les internautes à saisir leur nom d’utilisateur et leur mot de passe, ou toute autre information privée. Le géant du web s’est également attaqué aux programmes malveillants déguisés en logiciels légitimes pour tromper les utilisateurs dans l’installation de malwares. Pour le cas particulier des injecteurs d’annonces, la firme a par exemple procédé à la suppression de près de 200 extensions Chrome qui se sont avérées être des logiciels malveillants.

Google poursuit sa mission de rendre le web plus sain et plus sécurisé avec des améliorations continues de son programme de détection des menaces qui guettent les utilisateurs lors de leur navigation. La société vient en effet de se fixer une nouvelle mission visant à atteindre son objectif d’assainissement du net. Dans un billet de blog récent, la firme de Mountain View a annoncé qu’elle va commencer à avertir les utilisateurs en cas de soupçon d’une attaque d’ingénierie sociale via de faux boutons de téléchargement. Ces attaques utilisent des « tactiques trompeuses qui tentent de vous inciter à faire quelque chose de dangereux, comme installer des logiciels indésirables ou révéler vos informations personnelles (par exemple, mots de passe, numéros de téléphone ou données de cartes de crédit) ».

Vous avez probablement déjà rencontré ce type de menaces qui utilisent très souvent de faux boutons de téléchargement ou des images publicitaires qui prétendent à tort que votre système n'est pas à jour. Les images ci-dessous vont probablement vous donner une idée des techniques d’ingénierie sociale auxquelles Google fait allusion :

Cette image prétend que votre logiciel n’est pas à jour et vous invite à cliquer sur un bouton « update »

Cette image ressemble à un formulaire de dialogue de FLV, mais il s’agit en réalité d’un faux.

Ces boutons sont parfois utilisés sur des sites à contenu multimédia et s’intègrent souvent parfaitement aux sites de sorte que l’utilisateur puisse croire qu’il s’agit de boutons légitimes.

Google va donc avertir les utilisateurs quand le contenu intégré à une page web sera considéré comme suspect. Si vous vous demandez à quel moment un tel contenu sera considéré comme de l’ingénierie sociale, il faut noter que Google va avertir les utilisateurs lorsque l’une ou l’autre des conditions suivantes sera vérifiée :

• si le contenu intégré dans la page web prétend agir comme une entité de confiance, c’est-à-dire votre appareil, votre navigateur, ou le site web lui-même ;
• si le contenu essaie de vous inciter à faire quelque chose que vous ne feriez que pour une entité de confiance, par exemple saisir un mot de passe.

La navigation sécurisée cible premièrement les utilisateurs de Chrome et est activée par défaut sur le navigateur de Google. Toutefois, Google fournit également cette protection sur d’autres navigateurs (Firefox et Safari) et sur différentes plateformes (Windows, Linux, Mac OS X, Android).

Source : Google

Des serveurs Apache mal configurés peuvent faire fuiter des informations

Sur le trafic Tor

Le web profond, cette partie d'internet non indexée par des moteurs de recherche classiques généralistes, est souvent accessible via des services comme Tor ou I2P. Une portion d'internet souvent utilisée par des personnes désireuses de s'exprimer sous couvert de l'anonymat.

Mais, comme toutes portions du web, les sites en oignons auxquels des individus accèdent ont besoin d'être hébergés sur un serveur web. S'il y a plusieurs méthodes pour le faire, l'une des plus répandues consiste à se servir d'un serveur Apache Web en plus d'un daemon Tor pour gérer la partie anonyme du trafic serveur.

Toutefois, un paramètre par défaut dans les serveurs Apache Web, s'il n'est pas modifié, pourrait permettre de faire fuiter des informations sur le traffic serveur ainsi que sur le serveur lui-même.

« Si vous utilisez le service d'anonymisation Tor pour un serveur Apache, assurez-vous de désactiver mod_status avec la commande $ a2dismod status. Sur la plupart des distributions, Apache est livré avec une fonctionnalité pratique appelée mod_status qui est activée. C'est une fonctionnalité située à /server-status qui permet d'afficher quelques statistiques comme la disponibilité, l'utilisation des ressources, le trafic total, les hôtes virtuels activés et les requêtes actives HTTP. Pour des raisons de sécurité, elle est accessible uniquement depuis localhost par défaut.

Cela semble assez raisonnable, jusqu'à ce que vous vous rendiez compte que le daemon Tor tourne en localhost. Par conséquent, tout service caché utilisant la configuration par défaut d'Apache a sa page /server-status exposée au monde. Que peut faire un acteur malveillant dans ce cas ? Espionner des demandes potentiellement sensibles, déduire approximativement la longitude du serveur si le fuseau horaire est défini, voire déterminer l'adresse IP si un hôte virtuel clearnet est présent ».

Il ne s'agit pas là d'un nouveau problème dans la mesure où il a déjà été signalé auparavant au Projet Tor. Mais suite au tweet d'Alec Muffet – un ingénieur logiciel Facebook connu dans la communauté des chercheurs en sécurité – qui pointait vers le blog d'un étudiant en sciences informatiques expliquant le problème et ses ramifications, le problème a été remis une fois de plus à l'ordre du jour.

« J'ai découvert de nombreuses expositions de ce type durant les six derniers mois, et je les ai signalées partout où un contact était fourni. Ce ne sont pas seulement les pages statiques ou de petits sites personnels qui en sont affectés. Même des sites où la vie privée des utilisateurs est un impératif montrent de la négligence à cet égard. Vers la fin de 2015, j'ai trouvé un moteur de recherche populaire .onion qui n'avait pas désactivé ce module d'état. Comme vous pouvez l'imaginer, le résultat n'était pas des plus beaux ».

Il recommande de vérifier si votre mod_status est désactivé en vous rendant à l'adresse http://your.onion/server-status : « si vous avez une réponse autre que 404 et 403, ouvrez un shell sur votre serveur et exécutez $ sudo a2dismod status ».

Source : blog Wirefla

Une autre faille critique de sécurité a été découverte dans glibc

Et rend les machines sous Linux vulnérables à l'exécution d'un code à distance

L'année dernière, des chercheurs en sécurité de Qualys ont parlé d'une faille dans glibc, la bibliothèque C de base de toutes les distributions Linux. Baptisée Ghost, la faille permettait à un pirate distant de prendre le contrôle complet d’un système affecté, sans avoir la moindre connaissance préalable concernant les références du système. Pour rappel, la faille se situe au niveau des fonctions gethostbyname et gethostbyaddr, qui sont appelées par les distributions Linux lorsqu’elles doivent gérer des connexions réseau. Un pirate pouvait alors déclencher un dépassement de mémoire tampon (buffer overflow) dans ces fonctions, en utilisant, par exemple, un argument de nom d’hôte non valide lorsqu’une application effectue une résolution de DNS.

C'est encore cette même bibliothèque glibc qui est au cœur d'une vulnérabilité découverte indépendamment par des chercheurs de Google et de Red Hat.

Google a expliqué que la faille CVE-2015-7547, qui est un dépassement de mémoire tampon (buffer overflow) dans la pile glibc du resolver DNS côté client rendant les machines sous Linux vulnérables à l'exécution d'un code à distance, est déclenchée lorsque la fonction getaddrinfo() est utilisée.

« Les dépassements d'octets sont entièrement sous le contrôle de l'attaquant et sont le résultat d'une réponse DNS », a indiqué dans un autre billet Carlos O'Donnell de Red Hat. Il a avancé par la suite qu'une analyse a « démontré qu'il est possible d'écrire des réponses DNS correctes avec des charges utiles qui vont pénétrer la hiérarchie de cache DNS et donc permettre aux attaquants d'exploiter des machines derrière de tels caches ».

« Les tests effectués en local montrent que nous avons été en mesure de contrôler au moins l'exécution d'un appel free() avec un dépassement de tampon et pris le contrôle de l'EIP. D'autres exploitations n'ont pas été testées, mais cette seule tentative suffisait pour montrer qu'il est très probable que le contrôle de l'exécution puisse être acquis sans beaucoup plus d'effort », a précisé O'Donnel.

Le bogue a été signalé aux responsables de la bibliothèque glibc en juillet dernier, mais semble avoir été signalé dans la version 2.9 de glibc en mai 2008. Carlos O’Donnell (de Red Hat), Florian Weimer (de Red Hat) et Fermin J. Serna (de Google) ont travaillé sur un correctif de sécurité.

Serna pour sa part a confirmé que le problème affecte toutes les versions de glibc à partir de la version 2.9, mais qu'il y a des solutions qui peuvent être implémentées pour mitiger temporairement l'impact en attendant que les machines Linux reçoivent un correctif de sécurité.

« La vulnérabilité repose sur une réponse UDP et TCP surdimensionnée (plus de 2048 octets) qui est suivie par une autre réponse qui va écraser la pile », a expliqué Serna. « Aussi, pour en mitiger l'effet, nous suggérons de limiter la taille des réponses (par exemple en vous servant de DNSMasq ou de programmes similaires) acceptées par le resolver DNS localement. Assurez-vous également que les requêtes DNS ne sont envoyées qu'aux serveurs DNS, ce qui limitera la taille des réponses UDP ».

Google a expliqué que plusieurs vecteurs d'exploitations peuvent être utilisés pour utiliser cette vulnérabilité parmi lesquels ssh, sudo et curl.

Les experts encouragent les administrateurs à appliquer le correctif de sécurité immédiatement.

Source : Google, Red Hat

Une famille de trois chevaux de Troie infecte les processus système d'Android

Après avoir obtenu les privilèges utilisateur

L’entreprise de sécurité informatique Dr Web vient de détecter un ensemble de chevaux de Troie opérant sur la plateforme Android. Et le moins qu’on puisse dire est que ces applications malveillantes gagnent en complexité au fil des années.

Pour cette nouvelle découverte, Dr Web note un ensemble de trois malwares nommés Android.Loki.1.origin, Android.Loki.2.origin, Android.Loki.3 qui fonctionnent de concert afin d’infiltrer les terminaux Android.

Pour y arriver, plusieurs actions sont mises en œuvre. D’abord, Android.Loki.1.origin est téléchargé sur le système visé à partir d’une bibliothèque nommée liblokih.so. Une fois téléchargée, cette dernière va se fondre dans un processus système en s’appuyant sur Android.Loki.3. Il faut préciser que selon Dr Web, Android.Loki.3 agit en tant qu’un serveur permettant d’exécuter des scripts shell reçus des tiers malveillants via un serveur de commande et contrôle (C&C).

C’est lui qui permettra à Android.Loki.1.origin d’obtenir des droits d’accès élevés pour effectuer plusieurs actions sur le système infecté. Comme actions envisageables, l’on a par exemple la possibilité de télécharger n’importe quelle application sur Google Play Store, installer et supprimer des applications sur l’appareil, activer ou désactiver des applications, afficher des notifications, suivre les clics sur l’écran de l’appareil, etc.

À côté de ces deux applications indésirables, nous avons également Android.Loki.2.origin qui est utilisée par les attaquants pour installer des applications et afficher de la publicité sur les appareils infectés et cela à partir d’un serveur C&C. En plus de ces tâches, Dr Web souligne qu’Android.Loki.2.origin effectue également de l’espionnage en envoyant aux attaquants des informations relatives à l’appareil infecté (IMEI de l’appareil, adresse Mac, version du système d’exploitation, résolution de l’écran, etc.).

Après avoir envoyé les informations désirées aux tiers malveillants, Android.Loki.2.origin reçoit des instructions à partir du serveur (C&C), par exemple afficher une notification. En cliquant sur cette dernière, l’utilisateur sera redirigé vers un site web ou encore initialisera l’installation d’une application sans le savoir.

Une des particularités avec ces chevaux de Troie, explique Dr Web, c’est que les attaquants installent certains composants de ces malwares dans les dossiers système inaccessibles aux antivirus. Pour pouvoir donc se débarrasser de ces chevaux de Troie, il est recommandé de réinitialiser le système d’exploitation aux paramètres d’usine.

Source : Dr Web

Keybase lance un service de partage de fichiers chiffré de bout en bout

Open source et actuellement disponible en version alpha

Keybase est un système qui permet d’envoyer des messages chiffrés, soit à partir d’une interface dédiée en ligne, soit en ligne de commande avec votre machine Windows, Mac OS X ou Linux. Keybase a commencé à déployer, à certains de ses utilisateurs, un service de partage de fichiers annoncé comme un concurrent plus sûr que les solutions classiques telles que Dropbox, Google Drive, Box, etc. Avec le chiffrement de bout en bout qu’il offre, le nouveau service de partage de fichiers cible bien sûr tout le monde, mais en particulier les individus et organisations qui traitent des informations confidentielles.

Le nouveau service permet aux utilisateurs de créer des dossiers publics de fichiers ou des dossiers privés uniquement accessibles à d’autres utilisateurs qu’ils invitent.

Avec la commande « public », vous pouvez créer des répertoires signés pour tout le monde. Si vos données sont par exemple écrites dans l’emplacement " /keybase/public/votrenom ", chaque fichier que vous écrivez dans ce dossier est signé. « Il n’y a pas de processus de signature manuelle, pas de taring ou de gzipping, aucune signature détachée. Au lieu de cela, tout dans ce dossier apparaît sous forme de fichiers en clair sur les ordinateurs de chacun », explique Keybase. La société ajoute encore que tout ce que vous mettez dans votre dossier public est à vous, mais tout le monde pourra voir les mêmes choses que vous, sans aucun risque côté serveur ou une menace man-in-the-middle.

Une option « private » vous permettra de créer des dossiers chiffrés et privés. Par exemple, " /keybase/private/votrenom " sera un dossier chiffré juste pour vous. Les choses que vous mettez dans ce dossier ne pourront être lues que par vous. Si vous souhaitez que les données de votre dossier chiffré soient lues également par un ami, vous devez simplement ajouter le nom de votre ami, par exemple : " /keybase/private/votrenom, nomdevotreami ".

Les dossiers étant chiffrés de bout en bout, leur contenu n'est pas lisible via les serveurs de Keybase. La société explique en effet que « les serveurs Keybase ne possèdent pas les clés privées qui peuvent lire ces données. Ils ne peuvent pas non plus injecter de clés publiques dans ce processus, pour vous inciter à chiffrer pour des parties supplémentaires ».

La société envisage de permettre aussi aux utilisateurs de Keybase de partager en toute sécurité des fichiers avec d’autres personnes qui n’utilisent pas encore le service. En tant qu’utilisateur de Keybase, vous pourrez par exemple partager un dossier privé avec une connaissance sur Twitter en ajoutant le nom utilisé par cette personne sur le réseau social professionnel, suivi de « @twitter ». Vous aurez par exemple : " /keybase/private/votrenom,nomdevotreami@twitter ".

Contrairement aux services de partage classiques, il n'y a pas de modèle de synchronisation avec Keybase. Les fichiers sont diffusés seulement à la demande.

Les utilisateurs précoces du service de partage de fichiers de Keybase ont bénéficié d’un espace de stockage de 10 Go. La société promet que son service va rester sans pub et gratuit pour les utilisateurs « réguliers », et assure que les données de ses utilisateurs ne seront jamais commercialisées. S’il n’y a pour l’instant pas de plan pour augmenter cette capacité de stockage, il est toutefois probable que la société mette en place un plan premium pour permettre à ceux qui le veulent d’augmenter leur espace de stockage. Il s’agira donc des plus gourmands en espace de stockage, c’est-à-dire les grandes entreprises en général.

Le service de partage de fichiers chiffré de bout en bout est actuellement disponible en version alpha à une sélection d’utilisateurs. La version bêta est en cours de développement.

Source : Keybase

Fraude sur les cartes de crédit en dupant le service client d'un E-commerce

Un client d'Amazon explique qu'un attaquant aurait obtenu ses données de carte de crédit

En dupant le service client

Éric Springer est un ingénieur en développement logiciel et un utilisateur sensible à la sécurité qui estime être assez prudent pour éviter d’être victime de vol de données. Toutefois, il a vécu une expérience avec le site de commerce en ligne Amazon ; expérience à l’issue de laquelle il retient qu’un système a beau être protégé, mais parfois, il ne faut pas grand-chose pour le pirater. En ce qui concerne le système du géant du commerce en ligne, Éric Springer estime que c’est le service clientèle qui est la porte dérobée qui expose les données personnelles des clients.

Éric Springer est un utilisateur « lourd » de la plateforme AWS (600 $/mois) et cela a été repéré par un attaquant. Alors qu’il s’y attendait le moins, il reçoit un email d’Amazon qui le remercie d’avoir contacté le service clientèle, chose qu’il n’avait pas faite depuis bien longtemps.

Par curiosité, Springer se renseigne auprès d’Amazon pour en savoir plus. Il apprend alors qu’il a récemment contacté le service clientèle qui lui envoie ensuite sur demande le transcript du chat. Il se rend donc compte qu’un individu a réussi à obtenir ses informations réelles en engageant une conversation avec le service clientèle.

Dans la conversation, après que le chargé de clientèle lui a demandé sa préoccupation, l’usurpateur a répondu qu'il voulait savoir où sa dernière commande a été expédiée. Avant de répondre à sa question, par précaution, le chargé de clientèle a demandé à l’attaquant de confirmer ses informations personnelles, à savoir nom et prénoms, adresse email et adresse de facturation. L'usurpateur a bien renseigné ces informations même si l’adresse de facturation du propriétaire légitime du compte, Éric Springer, était une fausse adresse que ce dernier utilisait sur internet par précaution. Il l'avait par exemple utilisée pour enregistrer certains domaines.

D’après Éric, les informations fournies par l’attaquant auraient donc probablement été obtenues à partir de Whois, un service de recherche fourni par les registres Internet et qui permet d’obtenir des informations sur une adresse IP ou un nom de domaine.

Le chargé de clientèle étant convaincu qu’il s’adressait à monsieur Éric Springer n’a pas hésité à communiquer le nom du dernier produit acheté, l’adresse d’expédition complète ainsi que le numéro de téléphone. Le fraudeur a également demandé le solde de la gift card sur le compte de Springer, qui était alors de 0 $.

La première partie de la mission était accomplie. Après ce premier chat avec le service clientèle, l’attaquant a obtenu l’adresse réelle de sa cible ainsi que son numéro de téléphone. Il ne reste plus que les informations de la carte de crédit qu’il projette d’avoir dans une autre conversation avec le service clientèle.

Se rendant compte de ce qui se passait sur son compte, Éric a alors contacté Amazon en leur demandant de mettre une note sur son compte, laquelle note indiquait que le compte était à un risque d’ingénierie sociale très élevée et qu’il sera toujours en mesure de se connecter.

Quelques mois plus tard, Éric reçoit un email du service client indiquant qu’il avait à nouveau contacté le site. Le transcrit du chat montre que c’était l’attaquant dans la deuxième étape de son plan, essayant d’avoir les données de carte de crédit de Springer.

Dans la deuxième discussion avec le service clientèle d’Amazon, l’attaquant utilise la même technique pour tenter d’obtenir les quatre derniers digits de la carte de crédit. Cette fois, quand le chargé de clientèle lui demande ses informations personnelles pour vérification, l’usurpateur prend la peine de fournir l’adresse réelle de Springer qu’il a obtenue lors de la phase précédente. Il n’hésite pas alors à demander le moyen de paiement utilisé et il apprend que c'était une carte de crédit. Sans passer par quatre chemins, il demande ensuite les quatre derniers digits, chose que le chargé de clientèle refuse de donner par mesure de sécurité.

N’arrivant pas à obtenir cette donnée de la part du chargé de clientèle, l’attaquant laisse entendre qu’il utilise couramment plusieurs cartes de crédit et qu’en ayant un peu plus d’informations sur la carte qui a permis d’effectuer son dernier achat, il pourrait identifier la bonne carte parmi celles dont il dispose. Pour cela, il demande l’un après l’autre, les deux derniers digits de la carte, le type de carte (VISA, MasterCard ?), la date d’expiration, bref. Il essaie tout ce qu’il peut, mais sans succès. Il décide alors de recontacter le service plus tard.

Après cette deuxième alerte, Éric contacte à nouveau Amazon pour réitérer combien il est important que son compte soit sécurisé et demander de ne pas donner ses coordonnées à quiconque avec un nom et une adresse. Mais la prochaine étape du plan de l’attaquant lui a probablement été fatale. L’usurpateur entre une nouvelle fois en contact avec le service clientèle, mais cette fois, Éric ne peut avoir de transcript. L’attaquant change de technique et contacte Amazon par téléphone, mais la société refuse de donner à monsieur Springer l’enregistrement de la conversation téléphonique. Quant à Éric, il est persuadé que l'attaquant a réussi à obtenir les quatre derniers digits de sa carte de crédit.

Source : Éric Springer