septembre, 2014

A moins d’avoir passé les 15 derniers jours dans la caverne de Platon, l’homme du siècle s’est ému au rythme des annonces concernant le bug bash Shellshock. Le dernier soubresaut était celui d’Apple qui vient d’annoncer, sans la moindre précision aucune (histoire de préserver la tradition) la publication des correctifs pour Maverick, Mountain Lion et Lion.

Mais, pour un utilisateur Apple non technicien, le laconisme du bulletin d’alerte ne confirme en rien le colmatage de l’intégralité des trous Shellshock et défauts secondaires liés. Car, toujours durant ces 15 derniers jours, les tortureurs de code (tels que Michal Zalewski, Tavis Ormandy ou Florian Weimer) se sont lancés dans une quête du Graal visant à débusquer le moindre défaut. Du coup, le nombre de CVEs déclarés a subit une rapide inflation. Shellshock désigne désormais CVE-2014-6271 (l’originel), CVE-2014-7169 (l’imparfait du patch), CVE-2014-7186, CVE-2014-7187, CVE-2014-6277 et CVE-2014-6278 (les derniers découverts). Un trou, six alertes, chacune ne représentant pas le même indice de dangerosité, loin s’en faut.

Fort heureusement, Michal Zalewski s’est lancé dans une revue de détails de tous ces trous officiels. Johannes Ullrich, du Sans, est allé jusqu’à monter une petite séquence vidéo d’explication, avec un support « papier virtuel » disponible sous forme de fichier pdf ou de podcast . Les explications sont claires, relativement techniques, but in english. Ceux pour qui ce genre d’intervention fait grincer des Molières* peuvent se reporter sur la baladodiffusion en Français, réalisée par No Limit Secu, avec la participation de Nicolas Ruff, Nicolas Prigent, Jean-François Audenard et Johanne Ulloa.

Ces explications demeureront totalement cryptiques pour la majorité des êtres humains normalement constitués, lesquels se poseront encore et toujours la question « Ais-je bien appliqué la bonne rustine, le problème bash est-il résolu ? ». Chaque jour qui passe fait de Shellshock un proche-parent des séries B américaines, qui plonge le lecteur dans les affres du plus pénible des suspens et lui fait attendre avec impatience la parution du prochain épisode.

*NdlC Note de la Correctrice. Tiens, j’ai crû voir passer Boby Lapointe. Ca faisait longtemps

Ils, ce sont les enquêteurs du Ponemon Institute, travaillant pour le compte de Raytheon (obtention de l’étude par inscription obligatoire ). Cette étude dresse un bilan des outils Byod à la mi-2014 et brosse à grand traits la vision que les responsables sécurité portent sur ces outils.

Dans le secteur industriel, 40 % des RSSI interrogés affirment qu’un cinquième des employés de leur entreprise utilise un mobile. 31% vont même jusqu’à dire que, dans les 12 mois à venir, les outils de mobilité constitueront la majorité des systèmes informatiques et serviront à remplir les tâches les plus courantes (édition de texte, consultation du courriel, gestion de l’emploi du temps). Pourtant, ainsi le démontrent d’autres études, la sécurité est le parent pauvre de ces déploiements et changement d’usage, et près de 50 % des personnes interrogées avouent faire l’impasse sur cet aspect de la question. La sécurité est quasi systématiquement sacrifiée au profit de la productivité. A cette situation, deux raisons : le coût jugé trop élevé des offres sécurité, et une satisfaction très relative quant à l’efficacité desdites solutions.

L’autre moitié consciencieuse, celle qui tente de superviser la sécurité du parc Byod, et ce pour des infrastructures pouvant compter plus de 50 000 terminaux, le coût moyen par poste s’élève à 100$ par an. Lorsque le parc diminue, la note devient plus salée : 600 dollars par appareil et par an pour moins de 250 appareils par site. Le prix de la sécurité mobile gravite, en moyenne, aux alentours de 278 $ par terminal. Pourtant, si l’on interroge uniquement les responsables sécurité appliquant réellement une politique Byod, seuls 36% d’entre eux estiment disposer d’un budget en adéquation avec leurs obligations de protection. 50% d’entre eux pensent que leurs MDM (mobile management suite, le plus utilisé des outils de gestion/administration Byod) ne suffisent pas à protéger leurs ressources mobiles.

Quant aux solutions à mettre en place, 57 % des sondés estiment que les données sensibles de l’entreprise doivent non pas être stockées sur le périphérique mobile lui-même, mais sur une ressource distante, Cloud ou assimilée. Ce qui revient à dire que les RSSI « mobile » souhaiteraient voir se développer une sorte de Byod à la sauce « thin client », moins intelligente et plus « client-serveur » qu’elle ne l’est jusqu’à présent. La chose est-elle praticable ? Les opérateurs télécom disent que oui… mais leurs tarifs ainsi que leur très relative omniprésence ne plaide pas en faveur d’une telle évolution. Achevons ce très rapide survol de l’étude d’usage du Ponemon pour noter que le frein le plus puissant au déploiement des politique de sécurité appliquées aux mobiles provient des utilisateurs eux-mêmes. Un fait rapporté par plus de 56 % des RSSI interrogés. Cette méfiance envers les services « parachutés par la direction » recoupe l’analyse d’Adaptative Mobile sur ce point.

Pour Adaptative Mobile, l’usage plus ou moins accepté du Byod est avant tout une histoire de confiance. L’étude de ce vendeur de solutions de sécurité destinées aux opérateurs tendrait à prouver que :

– 84 % des employés interrogés place la protection de la vie privée en première place des préoccupations liées à l’usage des mobiles

– 42% d’entre eux accordent plus de confiance envers leur opérateur qu’envers leur dirigeants d’entreprise (30%) (rappelons qu’Adaptative Mobile travaille pour les opérateurs)

– Lorsqu’il s’agit d’un téléphone personnel utilisé dans le cadre du travail, 44% des usagers souhaitent une franche séparation des partitions « travail » et « informations personnelles », et 24 % n’accordent aucune confiance dans le fait que leur direction puisse avoir le moindre contrôle de leur terminal.

L’annonce par Apple d’un IOS8 doté d’un outil de chiffrement fort dépourvu de porte dérobée (donc de possibilité de collecte de preuve numérique en cas d’enquête de police) a provoqué une multitude de prises de position, certaines irréfléchies, d’autres bien plus sages.

L’une des plus remarquées (et pourtant lapidaire) fut celle de Bruce Schneier. Certes, Apple affirme ne pas pouvoir « débloquer » le contenu de ses clients même en cas d’injonction légale, mais ce contenu peut généralement être récupéré sur les bases iCloud dit en substance l’auteur de Blowfish. Et iCloud ne constitue qu’une des fuites possibles. Les outils de mobilité utilisant IOS (ou tout autre systèmes d’exploitation) doivent communiquer. Et si le chiffrement garanti un certain niveau de sécurité local, il n’est absolument pas certain que ce même niveau de sécurité soit toujours aussi consistant dès lors que les données franchissent une passerelle réseau, empruntent un service Internet, ou sont accessibles par une application locale qui pourrait être compromise. Le chiffrement constitue une protection de premier niveau qui n’est que très rarement garanti « de bout en bout ».

L’on pourrait rappeler que, notamment lors du « Moab » (Month of Apple Bug) et à l’occasion de nombreuses communications, les programmes de protection d’Apple ont très souvent montré d’incroyables faiblesses. De l’accès quasi libre par le câble de chargement/synchronisation en passant par les fichiers de backup vulnérables, les failles iTunes ou les contournements de procédure d’identification par code PIN, Apple n’a jamais brillé pour la solidité de ses outils. A décharge, il faut également reconnaître que ses concurrents ne font guère mieux.

Un groupe de trois chercheurs et universitaires vient de publier une étude sur le profilage et la « désanonymisation » des utilisateurs de terminaux mobiles grâce à l’analyse des relevés GPS de ces appareils. L’article s’achève avec la description technique de mesures renforçant l’anonymat des trajets

Le Point Exquis de l’affaire du Grand Chiffre d’Apple, c’est le blogueur Orin Kerr (du Washington Post) qui le détecte. En écrivant tout d’abord un article assez peu réfléchi sur « la légèreté d’Apple », édito conservateur arguant du fait que Cupertino fait ainsi le jeu des trafiquants de drogue, des cyber-pédophiles et des djihadistes terroristes. Tollé général sur les réseaux sociaux, Kerr revient sur sa position et admet que ce débat n’est pas aussi manichéen qu’il y paraît. Un troisième article conclut la polémique et pose deux questions, des classiques du genre en matière de chiffrement :

– « Où donc se situe la limite » d’un chiffrement qui protège la vie privée des gens honnête mais qui, également, masque les activités des véritables truands.

– « quid du compromis acceptable en matière de vie privée »

Or, cette question du compromis acceptable est une constante dans la politique intérieure des USA. Tant le gouvernement Bush que la présidence Obama ont utilisé l’argument du « léger sacrifice de la vie privée au profit d’une plus grande sécurité ».
C’est là que le bât blesse réplique Steeve Bellovin, l’un des pères de Usenet et surtout de l’identification EKE. L’usage des outils de mobilité n’est pas l’unique source d’échange des hors-la-loi. Ce n’est qu’un des nombreux outils possibles. Le chiffrement ne constitue pas seulement une protection des données personnelles, c’est également un bouclier contre les fréquentes attaques des pirates voleurs d’identités numériques, de données confidentielles etc. (ndlr : lesquelles sont d’ailleurs considérablement plus fréquentes et moins virtuelles que les attaques cyber-djihadistes ou les intrusions d’espions sino-russo-américains). Pis encore, renforcer la protection des équipements mobiles n’est qu’une forme de rétablissement de l’équilibre d’autrefois, équilibre compromis par l’intensif, l’abusif usage des perquisitions numériques réalisées par les services de police aujourd’hui. Depuis la généralisation des téléphones intelligents, cette même police a accès à des données qu’elle ne pouvait posséder auparavant, et c’est cette « ouverture » que la décision d’Apple referme très partiellement. Très partiellement, car même chiffré par des mécanismes inviolables, un iPhone 6, 7 ou 8 fournira toujours à cette même police son lot de métadonnées. En outre, si le débat peut se tenir aux USA ou dans la plupart des pays du bloc occidental, il y a de grandes chances pour que des gouvernement un peu moins amoureux des usages républicains demandent à Apple de « fragiliser », voire de supprimer ces outils de chiffrement, précisément pour que leurs services de police puissent continuer à accéder aux données privées de leurs citoyens.

Conséquence de l’annonce du chiffrement fort d’Apple se pose également la question de l’obsolescence tant du noyau que du mécanisme de chiffrement lui-même. De mémoire de gourou de la cryptanalyse, et à l’exception de l’inviolable « one time pad », il n’existe aucun système qui ne se casse avec le temps. C’est d’ailleurs sur ce principe que reposent les appels d’offres du NIST lorsque sont demandés à périodes régulières, et pour des longévités estimées, de nouveaux algorithmes destinés à la protection des communications de l’Administration Fédérale. La meute de SHA (de 0 à 3 couvrant les 21 dernières années) prouve qu’aussi perfectionnée soit-elle, une fonction de hachage finit toujours par trouver son maître. Si la résistance aux casseurs de code peut parfois prendre plus de 10 ans, la résistance de l’environnement logiciel lui-même rend généralement ces mesures de protection totalement inutiles. C’est la question que pose Graham Clueley sur le blog d’Intego : doit-on jeter les déjà « vieux » iphone 4 pour des raisons de sécurité ? Les constructeurs de téléphones portables ont besoin en permanence de cet oxygène financier que provoque un renouvellement de parc. De là à accélérer le phénomène en décidant d’arrêter le support des anciennes plateformes… ergo de les fragiliser, il n’y a qu’un pas. Ce que protège un algorithme de chiffrement encore inviolé, une montagne de bugs transversaux non corrigés sur certaines applications pourra en venir à bout. IOS, Android, Windows Mobile même combat. Passé 4 ans, le niveau de sécurité d’un téléphone ne vaut plus un kopek. Il en va de même pour les systèmes d’exploitation d’ordinateurs, sur une période généralement plus longue, d’environ 10 ans (record de longévité de Windows XP mis à part). La sécurité des systèmes d’information est l’enfant bâtard du marketing high-tech.

La course à la rustine CVE-2014-7169, alias Shellshock, alias bash bashing, a dû passablement occuper le week-end des développeurs de bon nombre d’outils serveurs. Chez Oracle, on annonce fièrement la disponibilité de 6 correctifs (Database Appliance, Exadata Storage Server Software, Exalogic, Exalytics, Linux 4, 5, 6 et 7 ainsi que Solaris 8, 9, 10 et 11).

Mais plus de 44 autres produits du catalogue sont encore vulnérables, informe le bulletin d’alerte.
Notons que le groupe chargé de la maintenance de bash a corrigé les imperfections du premier correctif. Bash 4 .3 est désormais débarrassé du CVE-2014-7169.

La presse, les pirates auteurs de virus, les éditeurs, les responsables sécurité… Shellshock, la faille bash, a fait réagir tout le monde, partout, en moins de 24 heures. Sauf, peut-être, les chasseurs de failles eux-mêmes.

La presse, tout d’abord, puisque 48 heures après les premières alertes, les journaux grand public (dont les quotidiens gratuits) se lancent dans des concours de superlatifs. Ce nouveau « bug du siècle » (du moins le bug du siècle du mois en cours), est-il oui ou non plus dangereux que Heartbleed ? Est-ce la fin de l’ère Internet ? Le monde Apple est-il devenu moins sûr ? S’il est intéressant de constater que les quotidiens prêtent une attention grandissante à la sécurité informatique (une bonne chose compte tenu de l’informatisation croissante des ménages) l’on peut regretter que la seule manière d’aborder la question se fasse sur le mode « DON’T PANIIIIIIIIC !!!! »

Les auteurs d’exploits n’ont pas traînés non plus. La première preuve d’exploitation dans la nature a été détectée quelques heures à peine après la révélation publique de la faille. Les exploitations les plus probables, ainsi l’explique Jen Ellis de Rapid7, sont celles qui visent une application Web dont le CGI fait appel à bash.

En d’autres termes, la faille bash est intrinsèquement moins importante que la mauvaise pratique qui consiste à permettre à un processus externe (lié à Internet de surcroît) de pouvoir passer directement des paramètres au shell. Et c’est peut-être ce point que n’ont pas détecté les chasseurs de faille. Car des « trous vieux de 25 ans », il y en a probablement encore beaucoup dans le noyau Unix. Mais des trous accessibles aussi facilement par le biais d’une cohabitation vénéneuse, il n’en existe heureusement pas tant que ça. Reste que bien des auteurs de malwares se sont lancés, dans l’urgence, dans un scan massif d’Internet rapporte l’Australien IT News. Probablement histoire de répertorier les points de faiblesse qui pourront s’avérer exploitables dans un proche avenir. Signalons également ce « gentil » Poc signé TrustedSec qui utilise DHCP pour mieux converser avec le shell Bourne.

Les éditeurs de noyaux eux aussi ont immédiatement réagi, mais préviennent que le premier correctif n’est pas parfait (il porte d’ailleurs lui-même un numéro CVE-2014-7169 ). Red Hat, Apple, Ubuntu, Debian et tant d’autres ont immédiatement « poussé » une nouvelle version du shell.

Mais les systèmes d’exploitation pour serveurs ou ordinateurs personnels ne sont qu’une facette du problème. Des centaines de milliers d’appareils connectés (du routeur Wifi aux boîtiers multimédia en passant par ces mille et un « appliances » à base de Linux embarqué, seront vulnérables ad vitam aeternam. Soit par le truchement de l’attaque CGI via leur interface Web d’administration (si celle-ci est accessible à distance) soit, plus simplement, parce que l’appareil est ouvert aux quatre vents « by design », avec un port ssh ouvert associé à un mot de passe par défaut. Cela s’est souvent vu, particulièrement sur certains équipements « rootés ». Si ces objets de l’Internet ne contiennent pas nécessairement de grandes richesses en termes de contenu, ils peuvent toujours venir grossir les rangs d’un botnet.

Le navigateur Firefox et le client de messagerie Thunderbird doivent être « rustinés » dans l’urgence la plus absolue. Une faille ssl affecte les « Network Security Services » des logiciels et ouvrirait la voie à une possible attaque « man in the middle ». Le Cert US rappelle que ce trou NSS pourrait également affecter Chrome et d’autres distributions Linux.