Archives de l’auteur : Janiko

2018

Pour le SANS Institute, les cinq grands types de cyberattaques les plus dangereuses attendues1 pour 2018 sont :

  • Le piratage des données stockées dans le cloud : plus il y en a, plus ça intéresse les pirates. Le crime suit l’usage.
  • La désanonymisation des données : en lien avec la quantité astronomique de données que nous produisons et la capacité à les traiter à grande échelle, des données a priori anonymes peuvent être réattribuées à leur propriétaire (et à leur véritable identité).
  • La monétisation des compromissions (minage de cryptomonnaies) : le vol de ressources informatiques se rentabilise via le détournement des ressources pour du minage.
  • L’exploitation de failles matérielles : vous avez entendu parler de Spectre ? On pensait ces vulnérabilités peu fréquentes, mais on n’en est plus aussi sûr que cela, et leurs conséquences peuvent être énormes tout en étant très difficile à corriger.
  • La perturbation de services essentiels : l’appât du gain ne rentre pas forcément en ligne de compte, mais des considérations géo-stratégiques conduisent des Etats à produire ce genre d’attaque.

Le Ministère de l’Intérieur français a publié un « État de la menace liée au numérique en 2018« , dans lequel on voit surtout la continue professionnalisation de la cybercriminalité, avec des modèles économiques variant selon la demande, avec du Crime-as-a-Service où on achète non pas seulement un malware mais tout un ensemble de services pour le mettre en oeuvre.

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 lecture →

2017

Quels sont les événements marquants (en sécurité de l’information) en 2017 ?

Pour le NCA (National Crime Agency) britannique1:

  • L’impact des ransomwares ;
  • Le volume des fuites de données, comme celle d’Equifax ;
  • La multiplication des attaques sur les chaines de production industrielles ;
  • Les actions de manipulation d’opinion publique à grande échelle, comme lors des élections américaines.

Pour l’ANSSI, les grandes tendances2 sont  :

  • Déstabilisation des processus démocratiques
  • Déstabilisation de l’ordre économique ;
  • Sophistication des modes opératoires ;
  • Caractère indirect et non discriminant des attaques ;
  • Résurgence d’effets destructeurs (destructions de données, voire d’infrastructures industrielles).

Son rapport d’activité est visible ici.

Côté NTT : https://www.nttsecurity.com/docs/librariesprovider3/resources/gbl-ntt-security-2018-gtir-summary-uea.pdf

TrueCrypt

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

Sources