Archives de mot-clé : Techno

Heartbleed, la NSA et les vulnérabilités logicielles

Hearbleed défraie les manchettes depuis la semaine dernière, mais déjà la nouvelle a fait son petit bout de chemin. En commençant par les excuses du malheureux programmeur derrière l’erreur de programmation responsable de la vulnérabilité. Les rapports préliminaires laissaient penser à d’une porte dérobée, placée délibérément à l’intérieur du code d’OpenSSL, mais les origines du bogue semblent finalement tout à fait banales.

Une autre hypothèse discutée est que la NSA connait l’existence de Heartbleed depuis un certain temps déjà, mais a décidé de ne pas en avertir les développeurs et le grand public. C’est du moins ce que laisse entendre cet article qui prétend que l’agence américaine avait identifié le bogue dès son introduction malencontreuse en début 2012, et l’exploitait depuis à ses propres fins. Des accusations que la NSA s’est empressée de démentir, mais la réputation de l’organisation étant ce qu’elle est depuis un an, mon petit doigt me dit qu’un simple communiqué ne sera pas suffisant pour convaincre les sceptiques.

Qu’elle soit véridique ou non, cette accusation ramène sur le tapis une question intéressante, que plusieurs commentateurs n’ont d’ailleurs pas hésité à soulever: la NSA (ou les autres agences de renseignement ayant de semblables activités) devrait-elle dévoiler publiquement les vulnérabilités logicielles découvertes par ses employés dans l’exercice de leur travail? C’est un problème fort épineux et qui met en lumière les différents objectifs des deux cultures impliquées.

Pour les professionnels de la sécurité informatique, les bonnes pratiques en matière de traitement des vulnérabilités logicielles font l’objet de discussions depuis plusieurs années. La plupart des développeurs ont depuis adopté des processus encadrant la découverte des vulnérabilités, leur divulgation, la production des correctifs appropriés et leur distribution et installation chez les utilisateurs. La philosophie promulguée par la communauté à travers ces pratiques en est une de transparence: les nouvelles vulnérabilités affectant un logiciel doivent être communiquées rapidement à tous, afin que les propriétaires et utilisateurs de système puissent prendre les mesures nécessaires pour protéger leur information contre le risque encouru. Parfois, un court laps de temps est laissé aux développeurs afin qu’ils soient en mesure de produire le correctif nécessaire et éviter une trop longue période de temps entre la divulgation de la vulnérabilité au public et la disponibilité d’un correctif. En contrepartie, les entreprises sont sévèrement blâmées s’ils tardent à procéder à cette divulgation pour des raisons d’image – ce qui arrive encore de temps en temps.
Cette approche n’a évidemment du sens que dans un contexte où les acteurs cherchent à se défendre contre des attaques utilisant ces vulnérabilités. Les cybercriminels, qui ont leur propre raison de découvrir et d’exploiter des vulnérabilités logicielles, n’ont évidemment aucun avantage à se plier à ces bonnes pratiques; au contraire, ils cherchent à garder secrètes ces vulnérabilités le plus longtemps possible.

Les objectifs des agences de renseignement s’apparentent à la fois à ceux des professionnels en sécurité et des cybercriminels. Dans le contexte de la sécurité informatique, leur mission est à la fois de protéger l’infrastructure stratégique de leur pays face à l’espionnage international, mais également d’effectuer des opérations clandestines à l’étranger visant à recueillir de l’information jugée d’importance stratégique, souvent confidentielle.

C’est pour cette seconde mission, dite offensive (connue en anglais par le terme « offensive security », ou OFFSEC) que les agences de renseignement ont développé au cours des dernières années l’expertise interne nécessaire à l’identification et l’exploitation de vulnérabilités logicielles inédites. Ces vulnérabilités ne sont pas communiquées aux développeurs; plutôt, on les garde secrètes dans le but ultime de les utiliser pour exploiter des cibles, généralement étrangères. Stuxnet, le ver qui a infecté les centrifugeuses nucléaires iraniennes il y a quelques années, utilisait des vulnérabilités jusqu’alors inconnues du grand public car jamais dévoilées. D’une grande complexité, il a probablement été développé par les services Américains et Israéliens.

Évidemment, ces agences pourraient très bien communiquer leurs découvertes aux développeurs de logiciel, et ainsi participer à la philosophie de transparence en gestion des vulnérabilités mentionnée plus haut. La NSA pourrait ainsi aider l’industrie du logiciel commercial à rendre leurs produits plus sécuritaires qu’ils ne le sont présentement, et contribuer de façon positive à la communauté. C’est certainement ce qu’un grand nombre de professionnels en sécurité souhaitent. Cela dit, il y a peu de chance que ça arrive.

D’un point de vue offensif, et tel que mentionné plus haut, publier ces vulnérabilités diminue leur valeur. Une agence de renseignement désire pouvoir se fier à des vulnérabilités encore inédites pour infiltrer un système d’information étranger avant que les correctifs applicables ne soient conçus et installés. C’est une tâche qui devient plus difficile du moment où la cible est mise au courant du risque pour sa sécurité.

D’un point de vue défensif, c’est plus compliqué. Les agences de renseignement, en adoptant un rôle dans la recherche de vulnérabilité pour le compte de l’industrie logicielle, se retrouveraient également à faire un travail qui n’est, à la base, pas le leur. C’est normalement aux développeurs que revient la tâche de s’assurer que les logiciels vendus sont exempts de vulnérabilités. Comme c’est un objectif qui s’avère difficile à atteindre, on s’attend à ce que ces entreprises soient réceptives face aux vulnérabilités trouvées sur leurs produits par des chercheurs indépendants; certaines d’entre elles allant jusqu’à offrir des primes pour les cas les plus sérieux. Est-ce une si bonne idée de demander à une organisation comme la NSA de s’introduire (gratuitement?) dans cet écosystème, surtout lorsque ce sont tous les acteurs internationaux qui en bénéficieraient, puisqu’ils utilisent souvent les mêmes produits? Si un gouvernement désire diminuer le nombre de vulnérabilités présentes dans les produits informatiques (ce qui est, en soi, un objectif fort valable), il devrait probablement s’y prendre autrement, en stimulant la sécurité de l’information à même l’industrie logicielle par exemple, ce qui serait probablement plus efficace et moins coûteux pour tout le monde, et ne mettrait pas la NSA en conflit d’intérêts.

Face à la grogne engendrée par le silence de la NSA sur des vulnérabilités connues, mais non divulguées, l’administration Obama a récemment suggéré d’obliger le service de renseignement à publier ses découvertes… sauf lorsqu’elles présentent un enjeu national stratégique pour les ÉU. Compte tenu de la difficulté à déterminer ce qui devrait être un enjeu et ce qui ne l’est pas, ce n’est pas une proposition qui risque de changer les habitudes. Cela pourrait quand même les inciter à dévoiler les vulnérabilités qui ne leur sont plus utiles: celles dont on soupçonne la publication imminente ou quand d’autres vulnérabilités, plus efficaces et insidieuses, sont déjà connues et utilisées, rendant la nouvelle superflue du point de vue des agences de renseignements.

Finalement, une troisième option s’offre, qui est peut-être déjà sur le bout de votre langue si vous vous êtes rendu jusqu’ici dans votre lecture: celle de demander aux agences de renseignement de complètement se retirer de la recherche en vulnérabilités logicielles. C’est une proposition qui en cache en fait une autre: celle de leur interdire tout simplement d’effectuer des opérations offensives. Pour diverses raisons, je ne pense pas qu’on doit s’attendre à ce que ça arrive de sitôt… mais il s’agit d’un tout autre sujet, que je vais me réserver pour une discussion future.

Advertisements
Marqué ,

Heartbleed

Ça ne me tentait pas d’en parler, mais je vais le faire quand même: Heartbleed, une vulnérabilité plutôt déconcertante (pour ne pas dire catastrophique) qui affecte certaines versions d’OpenSSL. Ce logiciel est utilisé par un grand nombre de sites pour chiffrer les communications qu’ils effectuent avec leurs visiteurs, dans un contexte de commerce électronique par exemple. Donc, un outil plutôt important pour le fonctionnement d’Internet tel que nous le connaissons.

L’exploitation de Hearthbleed permet de lire aléatoirement des blocs de données présents en mémoire sur les ordinateurs utilisant une version d’OpenSSL comportant la vulnérabilité. En pratique, cela veut dire qu’un attaquant pourrait connaître, au bout d’un certain temps, la totalité des informations présentes en mémoire sur le serveur concerné, incluant des données de configuration, mots de passe des utilisateurs, etc. D’un point de vue de sécurité, c’est très grave.

Nous savons déjà que plusieurs sites internet sont affectés. Près de chez nous, il semble que l’Agence du Revenu du Canada soit au courant du problème.

Heureusement, on connaît déjà la solution: une nouvelle version d’OpenSSL, corrigeant le bogue menant à cette vulnérabilité, est déjà disponible. Mais la mise à jour de l’ensemble des serveurs touchés pourrait être longue. Comme un attaquant éventuel pourrait déjà avoir exploité cette vulnérabilité avant sa correction, les administrateurs de systèmes devront également changer leurs mots de passe et renouveler leurs clés privées, certificats et autres éléments nécessaires à la sécurité de leurs communications, ce qui représente un effort plus important que la simple mise à jour d’un logiciel.

Comme je le disais, je ne voulais pas en parler… pourquoi? Parce que ce n’est pas mon intention d’adresser sur ce blogue chaque nouvelle vulnérabilité logicielle découverte – et il y en a tous les jours. Ça finirait par devenir ennuyant pour la majorité des lecteurs cibles, et n’intéresserait qu’une poignée de gens plus techniques qui fréquentent déjà des sites plus spécialisés sur le sujet. J’ai décidé de faire une exception aujourd’hui pour Heartbleed à cause de l’importance de la découverte.

Pour le commun des mortels, le mot d’ordre reste le même: mettez à jour vos logiciels et appliquez-y les correctifs de sécurité disponibles. C’est important.

Marqué

À propos de Windows XP

Il n’y aura pas de « bogue » du 8 avril, date à laquelle Microsoft cesse d’offrir des mises à jour sur le système d’exploitation Windows XP, qui équipe encore beaucoup de PC à travers le monde. Si votre ordinateur utilise Windows XP, il continuera à fonctionner normalement demain.

Ces ordinateurs ne deviendront pas « plus vulnérable »; on devrait plutôt dire qu’ils ne bénéficieront plus d’une mesure de sécurité, soit la mise à jour du système d’exploitation suite à la découverte de nouvelles vulnérabilités logicielles.

À partir de demain, les chercheurs en vulnérabilités logicielles voudront peut-être concentrer leurs travaux sur Windows XP en sachant que toute nouvelle vulnérabilité découverte ne sera pas corrigée par Microsoft, et donc, sera exploitable pour une période plus longue.

La bonne nouvelle, c’est que Windows XP est un système d’exploitation qui a déjà un certain âge, et donc, que beaucoup de ses vulnérabilités ont déjà été découvertes et corrigées au fil des années. La mauvaise nouvelle, c’est qu’il en reste encore fort probablement.

Si vous êtes concernés, que devez-vous faire? Si vous utilisez votre ordinateur pour accéder à Internet, alors vous devriez fortement songer à migrer vers Windows 7 ou 8, ou même MacOS/Linux. S’il s’agit d’un système isolé (je pense entre autres à certains commerces, comme un restaurant, où l’ordinateur en question n’est pas impliqué dans les transactions de cartes de crédit), le risque à court terme est moins important.

Marqué