if True: home()
Archives de catégorie : Enigmes
iOS (sécurité)
Bien que faisant partie du monde Apple, MacOS et iOS ne sont pas équivalents en ce qui concerne leur niveau de sécurité. De la même façon, dans le monde des smartphones, Android diffère également d’iOS du point de vue de la sécurité.
Continuer la lectureLes gestionnaires de mots de passe faillibles ?
Vraiment ? L’actualité court sur tous les sites web (enfin, quelques uns) pour indiquer que les gestionnaires de mots de passe comme KeePass ou 1Password laisseraient des informations critiques en clair.
Continuer la lectureMacOS (sécurité)
MacOS est-il sécurisé ? Je ne saurais pas mieux répondre que pour Windows ! Un petit mot, en passant, sur les mythes et réalités de l’informatique : j’ai souvent entendu des partisans du Mac (d’Apple) dire que les Mac n’étaient pas sensibles aux virus informatiques. La preuve, selon eux, était qu’on n’entendait jamais parler de virus sur cet environnement. Evidemment, c’est faux. La situation est néanmoins différente sur iOS (sur iPhone).
Logique de marché
Même il y a quelques années, cette affirmation était partiellement fausse : on n’en entendait peu parler, ce qui ne signifie pas qu’on n’en parlait pas du tout. Il y a une logique très simple dans la criminalité, informatique ou pas :
Le crime suit l’usage.
Les cybercriminels suivent donc l’usage : développer un programme malveillant ou toute attaque informatique demande de la préparation, du temps, des moyens, avec l’espérance d’un retour sur investissement pour l’initiateur. Ce retour peut être financier mais pas seulement (les motifs peuvent aller de la recherche de notoriété à l’idéologie).
Quelqu’un voulant attaquer les Mac n’attaquera que des Macintosh. Et donc seulement 10% du marché1 des ordinateurs personnels (à la louche). Donc beaucoup d’efforts pour peu de retours. Autant dire que c’est peu rentable et peu intéressant pour un attaquant.
Donc si les Macs sont moins attaqués, c’est uniquement parce qu’ils sont moins nombreux et moins intéressants.
Sécurité intrinsèque
Par contre, quelqu’un cherchant à attaquer un Mac y arrivera à peu près avec les mêmes techniques qu’un ordinateur PC Windows : il n’y a aucune différence fondamentale entre MacOS et Windows qui, comme tout programme informatique est faillible. Tout l’environnement MacOS peut présenter le même genre de vulnérabilités que des PC sous Windows. Il suffit de regarder les failles régulièrement corrigées par Apple. Les archives des vulnérabilités corrigées remontent au moins à 2003.
A la conférence Black Hat 2018, un chercheur du projet Google Zero a même enjoint Apple de changer de mentalité, car même avec du personnel très compétent en matière de sécurité informatique, la société manque de culture et ignore un peu trop la réalité des exploitations ; il relève même que les exploitations ciblées de vulnérabilités (comme par exemple l’infiltration d’Amnesty grâce à l’outil d’attaque Pegasus) sont beaucoup plus fréquentes2 qu’on ne l’imagine (et qu’Apple ne l’imagine).
Vulnérabilités notables
- https://www.securityweek.com/macos-high-sierra-logs-external-volume-passwords-plaintext
- Bug SSL (Apple)
- https://arstechnica.com/information-technology/2018/06/simple-technique-bypassed-macos-signature-checks-by-third-party-tools/
- Black Hat 2018 : Un éditeur de sécurité montre comme il est facile de contourner le pare-feu d’Apple3.
- DefCon 2018 : Un chercheur arrive à avoir accès au noyau (kernel) avec un programme de deux lignes45. Il n’y a pas que Windows à avoir de problèmes de ring 0 ! Plus précisément6, la simulation d’une action souris, trouvée (par hasard ?) par un chercheur (Patrick Wardle, ancien collaborateur de la NSA) voulant vérifier qu’une ancienne vulnérabilité avait été bien corrigée, a permis de découvrir le pot aux roses.
Programmes malveillants
Tordons le cou aux idées reçues : il existe des programmes malveillants7 pour Mac. Leur proportion reste très inférieure à celle de la part de marché des Macs, mais c’est logique par rapport à ce qui est dit plus haut : les retours sur investissement sont faibles, donc les pirates s’y intéressent moins.
Start-up
start-up n.f. inv. : Jeune entreprise mono-produit s’auto-qualifiant d’innovante, dans le secteur des nouvelles technologies, et qui fera faillite dans les 3 ans1 qui suivent sa création.
Loterie internationale
Curieux esprit de la glorification des start-up, pour lesquelles « l’important [est] de lever [des fonds] et de se faire racheter des millions en créant un modèle disruptif et scalable« 2. Or une start-up fera faillite 9 fois sur 103, ou même pire.
C’est un peu comme le loto : on peut gagner le gros lot, mais rarement, et surtout au prix d’énormes efforts qui la plupart du temps conduiront au chômage.
Un petit exemple
Il y en a plein, mais celui-ci est emblématique car il s’agit d’une entreprise rachetée par Facebook himself, tbh, application quasi-inconnue avant sont rachat fin 20174, devenue phénomène de mode et finalement abandonnée5 en juillet 2018.
En sécurité aussi
La mode start-up touche forcément aussi la sécurité informatique, puisque ça touche toute l’informatique. Voir aussi acqui-hiring.
Bulle internet
Les start-up contribuent, à leur façon, à la bulle internet, ou plutôt aux bulles internet, car elles sont récurrentes (on en a eu dans les années 2000, on en a encore en 2018).
Un article intéressant d’informatiquenews.fr (bien que peu détaillé comme souvent) nous donne les principales raisons de l’échec6 pour une startup :
- Le produit proposé ne répond à aucune demande du marché… Incroyable, non ? Il ne suffit pas d’être innovant pour vendre. Tout le monde n’est pas Apple qui veut ! Apple est une des rares marques à pouvoir créer du besoin.
- Le manque de cash. Ce qui rejoint un peu le point précédent : on manque de cash faute de débouché économique, et donc si le modèle économique est pourri, la startup ne s’en relèvera pas.
- Le 3e est que l’équipe dirigeante n’est pas compétente (ou n’existe parfois même pas). DevOps, c’est bien, mais il faut savoir où aller…
Manque de contrôle
Tout cela ne fait que montrer un manque inquiétant de contrôle sur ce que font les startups : du fait de leur mode de financement, elles échappent aux contrôles habituels de sociétés côtés en bourse (non pas qu’il soit suffisant mais c’est déjà une première sécurité).
Par ailleurs, la technicité des solutions masque souvent la réalité industrielle de l’entreprise : en gros, l’utilisation d’outils informatiques compliqués rend peu visible ce qui se passe vraiment en termes de métier, de produit, de stratégie. Les startups vendent trop souvent du rêve, et vendent un produit qui n’existe pas, qui n’est pas construit ou qui n’est pas au point (et dont, dans certains cas, on en sait pas s’il sera un jour au point).
Escroquerie
Cette opacité peut même conduire (facilement ?) à des escroqueries, comme dans le cas de Theranos7, à côté desquelles l’art moderne est un modèle de probité.
Bug SSL (Apple)
Je classe la vulnérabilité CVE-2014-1266 parmi les énigmes de sécurité informatique, comme l’affaire TrueCrypt, car les circonstances entourant ce bug SSL sont mystérieuses, et n’ont pas l’air d’avoir été éclaircies (en 2018).
Comme son nom l’indique, cette faille a été découverte en 2014.
AMD, des failles
Allez, mettons tout le monde d’accord : AMD aussi à ses failles, tout comme Intel. Et son site dédié, sans quoi une faille n’est pas une faille. Comme souvent, les détails ne sont pas dévoilés1 immédiatement, tant qu’on n’a pas essayé de remédier à ces problèmes, mais cela reste inquiétant.
Continuer la lectureTrueCrypt
Que penser de TrueCrypt ? C’est l’un des plus étonnants mystères de ces dernières années dans le petit monde de l’informatique.
TrueCrypt est un utilitaire permettant de chiffrer ses documents, voire des volumes entiers sur vos disques plus ou moins durs. Très utilisé, et même recommandé par des personnes de confiance, l’utilitaire a disparu du jour au lendemain (littéralement), sans donner d’explication convaincante1. D’autant plus étonnant que des initiatives avaient abouti à la réalisation d’un audit du code (qui est à peu près en open source), sans que l’on trouve en première approche de grosse faille ou de faiblesse particulière, à peine un mois plus tôt. Par ailleurs, en 2013, l’ANSSI avait fait réaliser une certification de premier niveau (CSPN), c’est-à-dire que fonctionnellement il répond bien à la cible de sécurité choisie.
Une communication discrète…
L’équipe de développement s’est toujours montrée discrète, ce qui est la fois un gage de sécurité (au sens où il est alors difficile de faire pression sur les auteurs) mais aussi une source d’inquiétude car il est alors impossible de connaître la notoriété ou la réputation des personnes impliquées.
…jusqu’à la fermeture !
Car ce jour là, le site fut modifié brutalement pour indiquer que le logiciel ne devait plus être considéré comme sûr, et qu’il fallait se tourner vers BitLocker, le produit de chiffrement de Microsoft dont la sécurité est difficilement évaluable puisqu’il s’agit d’un produit commercial, dont les sources sont inconnues (le retro engineering étant interdit sur les produits Microsoft), et surtout en provenance d’un éditeur soumis comme tous les autres à la législation américaine et aux agences fédérales.
Pourquoi ?
On nage alors dans le paradoxe : les développeurs de l’outil permettant d’échapper au big brother promeuvent d’un seul coup un outil sur lequel plane la suspicion ! Certains penchent pour un gag order, qui consiste en une obligation de silence, pratique relativement usuelle en droit anglo-saxon, en lien avec par exemple une interdiction de continuer à développer le logiciel (j’imagine) ou l’obligation d’y inclure une porte dérobée, ce qu’auraient refusé évidemment les développeurs.
D’autres pensent à de gros problèmes de structure et de conception, n’induisant pas de faille majeure au moment de l’examen du code, mais que les avancées technologiques rendent nécessaires de revoir, avec un coût de réécriture trop important pour les développeurs.
On peut aussi penser que c’est par lassitude, ou suite à la découverte de leur propre chef d’une faille trop importante, mais cela me semble peu probable au vu de leur communication quasi-provocatrice.
Par ailleurs, la dernière version publiée (7.2) de l’outil a été expurgée de toutes les parties de code concernant le chiffrement, ne laissant à l’utilisateur que la possibilité de déchiffrer ses données, pour ne pas les perdre, mais sans plus pouvoir les protéger. Pourquoi s’en donner la peine ? Sauf dans le cas d’une faille béante dans le mécanisme de chiffrement qui le rendrait impropre à une protection correcte des données, mais aucun des audits postérieurs à cet arrêt n’a révélé de tels problèmes.
Peut-on encore l’utiliser ?
Certains le font. En tout cas la version 7.1a2, la dernière contenant toutes les fonctionnalités et qui a été auditée, sans qu’on n’y trouve de faille sévère.
Il existe un site web assez curieux, truecrypt71a.com, qui se prétend extérieur au projet mais dont l’auteur connaît parfaitement tous les détails de TrueCrypt, et où certains passages sont rédigés à la 1ère personne (« nous », en parlant du développement de TrueCrypt). C’est une mine de renseignements, et on peut y trouver les sources et les binaires (avec des éléments d’identifications comme des signatures GPG).
Comment monter un conteneur sous Linux ?
J’ai dû me poser la question (pour le boulot), et on peut très bien le faire sans installer TrueCrypt. Il faut toutefois installer cryptsetup
, un utilitaire permettant une configuration un peu plus simple (car il y a en réalité tout un tas d’autres outils mis en oeuvre).
Sur un Raspberry, sous Raspbian 10, il faut installer les packages suivants :
- cryptsetup_1.7.3-4_armhf.deb
- cryptsetup-bin_1.7.3-4_armhf.deb
- libcryptsetup4_1.7.3-4_armhf.deb
On les trouve sur le site officiel de Raspbian, à l’adresse https://archive.raspbian.org/raspbian/pool/main/. Les numéros de versions changeront au fur et à mesure des mises-à-jour.
Ensuite il y a une petite manip, en trois étapes (trouvée ici) :
- Attacher le fichier conteneur à un périphérique virtuel (loopback device) ;
- Ouvrir le conteneur avec
cryptsetup
; - Enfin monter le conteneur dans le filesystem.
En pratique :
$ sudo losetup /dev/loop0 nom_fichier_conteneur $ sudo cryptsetup --type trcrypt open /dev/loop0 nom_conteneur $ sudo mount /dev/mapper/conteneur point_de_montage
On peut donner n’importe quel nom au conteneur, qui sera ensuite accessible via /dev/mapper/nom_conteneur
. On peut vérifier la 1ère étape comme suit :
$ losetup NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop0 0 0 0 0 /jean/test.tc 0 512