Bienvenue dans le résumé hebdomadaire des nouvelles relatives à la sécurité, saison 1, épisode 2. Dans l’article précédent, nous en avons appris plus sur les voitures qui se déverrouillaient automatiquement, sur le StageFright chronique d’Android et sur le fait que nous ne serions plus surveillés sur le Web (en principe).
Vous trouverez dans cet article deux nouvelles qui semblent ne pas avoir de rapport entre elles mais qui, en réalité, ont une chose en commun : les vulnérabilités émergent de la réticence des distributeurs à prendre les mesures de sécurité disponibles. La troisième nouvelle ne concerne pas du tout la sécurité, mais se rapporte plutôt à des cas particuliers dans son industrie.
Laissez-moi vous rappeler les règles : chaque semaine les éditeurs de Threatpost choisissent trois sujets d’actualité importants auxquels j’ajoute des commentaires détaillés et impitoyables. Vous pourrez trouver tous les épisodes de cette série ici.
Pirater des portes d’hôtel
On dit souvent qu’il y a une dichotomie des sciences et des lettres, et que les experts dans ces deux domaines peuvent à peine se comprendre. En général, les personnes sont convaincues qu’un humaniste intellectuel ne peut pas devenir un scientifique ou un ingénieur.
John Wiegand, un musicien de formation, a cassé ce stéréotype. Dans les années 1930, il était pianiste et il dirigeait la choral pour enfants, jusqu’à ce qu’il s’intéresse à la conception des amplificateurs audio. Dans les années 1940, il a travaillé sur la nouveauté de l’époque : l’enregistrement sur bande magnétique. C’est en 1974 (il avait 62 ans), qu’il a fait sa plus grande découverte.
Elle s’appelle « le fil Wiegand ». C’est un fil magnétique comprenant un alliage de cobalt, de fer et de vanadium traité de telle manière qu’il est formé d’un fil extérieur dur recouvrant un fil intérieur doux. Les champs externes magnétisent facilement la couche externe, qui résiste aussi à la démagnétisation, même quand les champs externes sont enlevés : c’est une caractéristique qui s’appelle le champ coercitif élevé. Le fil doux interne réagit différemment : il n’est pas magnétisé, jusqu’à ce que la couche externe le soit entièrement.
Au moment où la couche extérieure du fil est complètement magnétisée, l’intérieur est finalement autorisé à l’être aussi. Puis les deux fils inversent leur polarité. Cette réaction produit un voltage très important qui peut être exploité pour tout type d’application de détection et de mouvement. Elle peut être utilisée par exemple pour les clefs des hôtels.
Contrairement aux cartes modernes, les uns et les zéros ne sont pas enregistrés dans la puce, mais plutôt dans une séquence directe de fils qui sont disposés d’une certaine manière. Reprogrammer une telle puce est impossible, et le schéma général n’est pas similaire aux cartes magnétiques d’abonnement modernes pour les transports publiques ou les cartes de paiement, mais il ressemble plutôt aux cartes de bande magnétique, qui sont plus fiables.
Devrions-nous abandonner les cartes magnétiques ? Pas encore. Wiegand a donné son nom, non seulement à l’effet découvert, mais aussi au protocole d’échange de données qui est plutôt ancien. Cependant, tout ce qui est mentionné est très mauvais. Premièrement, il n’a jamais été vraiment normalisé, et il dispose de nombreuses versions.
Deuxièmement, le code d’identification original peut aller jusqu’à 16 bits et ne produit que très peu de combinaisons. Troisièmement, la conception de ces cartes magnétiques qui possèdent des fils, et qui ont été inventées avant que l’on ait appris comment mettre un ordinateur complet dans une carte de crédit, restreint la longueur de la clé à juste 37 bits et ne peut donc pas lire les cartes plus longues.
De ce fait, la semaine dernière, pendant la conférence Black Hat, les chercheurs Eric Evenchick et Mark Baseggio ont présenté leur appareil qui, s’il y est autorisé, intercepte (déchiffre) les séquences clés. Il est d’autant plus intéressant que les cartes n’ont rien à faire avec ça, car l’information est volée pendant que les données sont transmises d’un lecteur de carte à un contrôleur de porte qui utilise toujours ce protocole Wiegand.
Le nom de cet appareil est BLEkey. Il représente un petit bout de matériel informatique qui a besoin d’être incorporé dans un lecteur de carte, par exemple, dans la porte d’un hôtel. Les chercheurs ont montré que l’opération complète prend seulement quelques secondes. Tout est simple. Il suffit juste de lire la clé, attendre pour le vrai propriétaire de partir et ouvrir la porte. Bien sûr, il est possible de ne pas attendre ou de ne jamais ouvrir la porte. Sans aller dans les détails techniques, le dialogue entre la porte et le lecteur sans fil peut être représenté par :
« Qui est là?
– C’est moi
– Ah, te voilà ! Entre ! »
Final talk run through! pic.twitter.com/TQB472izkO
— Eric Evenchick (@ericevenchick@mastodon.social) (@ericevenchick) August 6, 2015
Tout semble être plutôt clair, mais il y a une petite subtilité. Comme d’habitude, les systèmes de contrôle ne sont pas tous vulnérables à cette attaque. Même ceux qui le sont peuvent être protégés sans être complétement remplacés. Selon les chercheurs, les lecteurs possèdent des mesures de protection contre de tels piratages, mais elles sont, en général, désactivées.
Certains soutiennent même l’Open Supervised Device Protocol (le protocole ouvert de périphérique supervisé), qui vous permet de chiffrer les séquences clés transmises. Ces « fonctions » ne sont pas utilisées, je n’arrêterais jamais de le répéter, car négliger les mesures de sécurité revient moins cher et c’est plus facile.
Voici une autre étude intéressante de 2009 sur ce sujet en anglais, avec des détails techniques. Apparemment, les vulnérabilités des cartes (et non des lecteurs) ont été relevées en 1992. Ensuite, il a été proposé que la carte soit démontée ou radiographiée. À cette fin, il fallait par exemple, prendre directement la carte des mains du propriétaire. Maintenant, la solution à ce problème se résume en un tout petit appareil de la taille d’une pièce d’un euro. C’est ce que j’appelle le progrès !
L’immunité de Microsoft. La complexité de Windows Server Update Services.
L’histoire de Threatpost. L’original livre blanc des chercheurs.
Les Windows Server Update Services (les services de mis à jour de Windows) permettent aux grandes entreprises de centraliser les mises à jour installées sur les ordinateurs via un serveur interne à la place d’une source externe. C’est un système très fiable et suffisamment sûr. Premièrement, toutes les mises à jour doivent être signées par Microsoft. Deuxièmement, la communication entre le serveur de mises à jour de l’entreprise et le serveur du vendeur est chiffrée par un SSL.
C’est un système plutôt simple. Le serveur de l’entreprise reçoit une liste de mises à jour sous la forme d’un fichier XML. Elle contient des informations sur la manière, l’emplacement et le contenu du téléchargement. Il se trouve que cette première interaction se fait dans un texte simple. Excusez-moi, je me suis mal exprimé. Elle doit être chiffrée et quand on veut utiliser WSUS, un administrateur est fortement recommandé pour permettre le chiffrement. Malheureusement, il est désactivé par défaut.
C’est vraiment embêtant, car ce n’est pas facile de remplacer les « instructions », mais il est possible qu’un agresseur puisse le faire s’il sait comment intercepter le trafic (comme pour l’attaque de l’homme du milieu qui a déjà eu lieu). Les chercheurs Paul Stone et Alex Chapman ont découvert que si l’on remplace les instructions, on pourrait ensuite exécuter un code arbitraire avec de grands privilèges sur le système mis à jour. Cependant, Microsoft vérifie toujours les certificats numériques mais il accepte toute sorte de certificat d’entreprise. Par exemple vous pouvez introduire (de manière clandestine) des utilitaires comme PSExec à partir de kits SysInternals et grâce à eux, vous pouvez lancer quoi que ce soit.
Pourquoi en est-il ainsi ? Le fait est que faire fonctionner un SSL (Secure Sockets Layer, protocole de sécurisation des échanges sur Internet), pendant que l’on utilise WSUS, n’est pas automatique car il faut créer un certificat. Comme les chercheurs ont remarqué dans ce cas, Microsoft ne peut rien faire à l’exception de vous inciter à utiliser un SSL. De ce fait, il semble qu’il y ait une vulnérabilité mais qu’en même temps, il n’y en a pas. Malheureusement, rien ne peut être fait, et personne d’autre que l’administrateur n’est coupable.
One of our weaker advertising campaigns for Windows: pic.twitter.com/Fon5IvBFnP
— Mark Russinovich (@markrussinovich) August 12, 2015
De plus, Kaspersky Lab à découvert le logiciel espion Flame qui peut se répandre à cause d’une mise à jour Windows Update. Cependant, il agit différemment : le faux proxy intercepte les demandes du serveur de Microsoft, de plus, ses fichiers de réponses étaient un peu différents, bien que certains d’entre eux avaient même été signés par le fournisseur.
Ingénierie inverse et douleur
L’histoire de Threatpost. L’article original d’Oracle CSO.
Les deux présentations mentionnées précédemment, au cours de la conférence de Black Hat, sont liées car les chercheurs de ces études, les experts en sécurité, ont découvert des défauts de certaines technologies ou de produits qui étaient conçus par quelqu’un d’autre. Ils ont publié leurs découvertes, et dans le cas de BLEKey, ils ont aussi présenté le code et le matériel informatique en entier afin de le rendre accessible publiquement. En général, la sécurité informatique communique avec le monde extérieur de cette manière. Cependant, pas tout le monde n’aime cette situation.
Je ne veux surtout pas juger, c’est en effet un sujet très délicat. Convient-il d’analyser les codes des autres personnes et sous quelles conditions est-ce correct ? Comment devrais-je dévoiler des vulnérabilités de peur de causer des préjudices ? Serais-je rétribué pour les défauts que j’ai trouvés ? Les restrictions législatives, le code pénal et la coutume dans ce domaine peuvent tous avoir des conséquences.
Un article récent du chef de la sécurité chez Oracle, Mary Ann Davidson, a produit l’effet d’un éléphant dans un magasin chinois. Il se nomme « No, you Really Can’t ». Il est presque entièrement dédié aux clients de l’entreprise (et non à l’industrie en soit), qui ont envoyé des informations à propos des vulnérabilités qu’ils ont trouvés dans les produits des fournisseurs.
Tous les paragraphes de l’article datant du 10 août 2015, sur le blog d’Oracle, valent la peine d’être cités, mais l’un d’entre eux contient un détail plus important : si un client n’avait pas d’autre choix que de s’informer sur la vulnérabilité via l’ingénierie inverse, alors il violerait le contrat de licence, et ce serait mal.
https://media.kasperskydaily.com/wp-content/uploads/sites/93/2020/06/30144619/security-week-33-sobchak.png
Citation :
Un client ne peut pas analyser le code afin de savoir s’il y a un contrôle qui empêche l’attaque que l’outil de balayage a détectée (et qui est probablement due à un faux positif). Afin d’y remédier, un client ne peut pas concevoir un patch, seulement le fournisseur peut le faire. Un client est presque certain de violer le contrat de licence en utilisant un outil qui fait des analyses statiques (et qui agit contre un code source).
La réaction du publique était comme ça :
https://twitter.com/nicboul/status/631183093580341248
Ou bien comme ça :
Adobe, Microsoft Push Patches, Oracle Drops Drama http://t.co/XN4Tpb9RXw #oraclefanfic
— briankrebs (@briankrebs) August 12, 2015
Ou encore :
Don't look for vulns. Fuck bug bounties. We won't even credit you. https://t.co/VgCrjGYx1j An @oracle love letter to the security community.
— Morgan Marquis-Boire (@headhntr) August 11, 2015
Cet article n’est pas resté plus d’un jour en ligne. Il a été supprimé à cause d’un « désaccord de l’entreprise avec les clients sur ce sujet » (mais Internet s’en rappelle). Laissez-moi vous rappeler qu’Oracle a conçu Java, et que seulement les plus paresseux ne profitent pas des vulnérabilités de celui-ci. Il y a trois ans, sur une période de 12 mois, nous avions conté les vulnérabilités trouvées sur Java, et nous en avions détectées 160 !
Peut-être que dans un monde idéal, chercher et réparer les vulnérabilités des logiciels devrait être fait exclusivement par les fournisseurs eux-mêmes. Toutefois, ce n’est pas le cas dans le monde réel.
Regardons de plus près l’autre version des faits. La semaine dernière, le créateur de Black Hat, Jeff Moss, nous a fait une présentation sur le fait que les fournisseurs de logiciels sont responsables pour les défauts dans leur code. Il a dit qu’il était temps de se débarrasser des lignes écrites dans les conditions générales d’utilisation qui mentionnent le fait que l’entreprise n’a aucune responsabilité sur ses clients. Cette déclaration est intéressante, mais n’est pas moins prétentieuse que l’appel « interdisons le désassembleur ». Jusqu’à présent, la seule chose qui est assez évidente est que : si les utilisateurs (de l’entreprise et les particuliers), les fournisseurs et les chercheurs peuvent se comprendre mutuellement, ce ne sera pas fait par des affirmations qui tapent à l’œil ni par des plaisanteries sur Twitter.
Quelles sont les autres nouvelles de la semaine ?
Il y a eu une autre présentation, au cours de la conférence de Black Hat, sur le piratage de Square Reader (le lecteur que vous connectez à votre smartphone afin de payer le livreur de sushis). Ce produit a besoin d’être amélioré.
Des chercheurs ont trouvé dans les ordinateurs de Lenovo (pas tous, mais certains), un autre rootkit (outil de dissimulation d’activité). L’histoire précédente se trouve ici.
Les plus anciens
La famille de malwares « Small »
Au cours d’un téléchargement, les virus résidents standards sont ajoutés à la fin des fichiers .com (à l’exception des Small -114, -118 et -122 qui sont écrits au début). La plupart des familles de virus utilisent les commandes POPA et PUSHA des processeurs 80×86. Les Small -132 et -149 infectent certains fichiers incorrectement. Ils n’ont pas été créés par les mêmes concepteurs. Apparemment, l’origine de la famille Small peut être considérée comme un concurrent des virus résidents dans la mémoire courte de MS-DOS.
Citations tirées de l’ouvrage « Computer virus in MS-DOS », par Eugène Kaspersky, 1992.
Clause de non-responsabilité : cet article ne reflète que l’opinion personnelle de l’auteur. Elle peut correspondre à la position de Kaspersky Lab, mais pas nécessairement.