Journal Effacer proprement ses données

Posté par (page perso) . Licence CC by-sa
Tags :
19
20
mar.
2011

Cher journal,

Il semblerait que, dans le cardre de l'affaire Fortis¹, les avocats de la banque ait transmis des données sur une clef USB à la police. Cependant, afin de ne pas être trop transparent et d'éviter que des informations qui pourraient être compromettantes circule n'importe, les avocats du service juridique ont supprimer certains fichiers. La police a cependant fait une analyse un peu poussée du support et a découvert ces fichiers qui avaient été supprimé (et pas réécrit).

Tout ça pour te dire qu'il y a encore du chemin à faire avant que les gens comprenne ce qu'il est possible de faire avec l'outil qu'ils manipulent. Et que même si les gens savent utiliser Windows, une formation ne ferrait pas de mal.

http://www.rtbf.be/info/economie/detail_fortis-aurait-cache-une-serie-de-donnees-cruciales-a-la-justice?id=5799333

¹: l'affaire Fortis concerne une banque belge qui a failli faire faillite et qui a été sauvée in-extremis par l'état belge. Ceci aurait fait perdre beaucoup d'argent aux actionnaires essayent de prouver que la banque ne les a pas suffisamment informé comme elle l'aurait dû.

  • # Et vous ?

    Posté par . Évalué à 6.

    Comment auriez-vous fait ?

    • un coup de dd pour écrire de /dev/urandom vers le périphérique (genre /dev/sdb1) ?
    • un shred bien placé ?
    • N formatage ?
    • autre ?

    Perso, je pense à la première méthode, mais ça aurait retardé d'une journée l'envoie des fichiers. Franchement quand tu vois les enjeux là j'aurais acheté une nouvelle clef USB (je présume qu'éviter la prison vaut bien une poignée d'euros en contrepartie).

    Là pour le coup il y a moyen que les fichiers soient dans un dossier caché "trash" de la clef....

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Et vous ?

      Posté par (page perso) . Évalué à 9.

      Comment auriez-vous fait ?

      Filer une clé USB qui n'a jamais contenu les fichiers qu'on ne veut pas filer. Bref, une clé neuve, "spéciale police", sur laquelle on n'écrit que ce qu'on veut filer, le plus sûr moyen de ne pas filer une chose est de ne l'avoir jamais écrit sur la clé.

      Toutes tes méthodes peuvent être déjouées si on y met les moyens ("effet mémoire" des puces) + possibilité d'erreur humaine (oubli etc...).

      • [^] # Re: Et vous ?

        Posté par . Évalué à 3.

        Le flash posséderait un effet mémoire ? Par quel mécanisme ?

        • [^] # Re: Et vous ?

          Posté par (page perso) . Évalué à 3.

          La, comme ça, je n'ai pas les liens, d'autres ici sont plus au courant que moi, mais de tête j'ai lu qu'en étudiant de près les cellules et leur état électrique suivi d'un algo pour tester les "possibilités viables" (ce qui aurait du sens, on écarte les erreurs), on peut retrouver leur état précédent voire quelques uns avant. Après, il faut avoir le matos et les compétences pour...

          Après, si tu écrit 10x /dev/random, je pense que même la CIA aurait du mal, mais le principe de plus de sécurité (ne pas filer ce qui est écrit) est dans tous les cas plus viable. : on ne connait jamais les avancées techniques du mec en face.

          • [^] # Re: Et vous ?

            Posté par (page perso) . Évalué à 7.

            Cette technique c'est pour les disques magnétiques style les disque durs, je n'ait pas entendu parler du même genre d'attaque contre les mémoires flash.

            Si quelqu'un à des infos je suis intéressé.

          • [^] # Re: Et vous ?

            Posté par . Évalué à 3.

            Si tu penses a une depeche/journal poste par ici ya qq mois, c'etait tres loin d'etre applicable.
            En gros, tu retrouvais le contenu si le disque etait ridiculement petit et si tu savais plus ou moins ce qu'il contenait avant. C'est pratique pour retrouver ses donnees a soi, pas trop pour espionner.

            Des fichiers effaces mais pas reecrit par contre, la c'est zezette, tu recuperes presque tout sans forcer.

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: Et vous ?

      Posté par (page perso) . Évalué à 1.

      Le plus simple reste "wipe" ... non ?

    • [^] # Re: Et vous ?

      Posté par . Évalué à 10.

      Déjà j'aurais transmis un CD plutôt qu'une clé USB.

    • [^] # Re: Et vous ?

      Posté par . Évalué à 7.

      Les supports de stockage ayant eu des données confidentielles ne doivent jamais sortir intacts du cercle de confidence. Mon choix se serait donc porté sur une clef USB neuve ou des CD gravés.

      The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

      • [^] # Re: Et vous ?

        Posté par (page perso) . Évalué à 4.

        ou des CD gravés.

        Ils auraient peut-être utilisé des CD réinscriptibles :)

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Et vous ?

      Posté par (page perso) . Évalué à 9.

      J'aurais acheté une nouvelle clef, pour ensuite la remplir de plein de petites images de chats (ou pr0n au choix). Après avoir supprimé les images, j'aurais enfin mis les documents importants.

      Envoyé depuis mon lapin.

    • [^] # /dev/frandom ?

      Posté par (page perso) . Évalué à 1.

      y'a /dev/frandom aussi par le bien d'un module, qui est plus rapide et qui ne perd pas trop en élément aléatoire. A priviligier sur disque dur.

    • [^] # Re: Et vous ?

      Posté par . Évalué à 3.

      J'aurais été encore plus subtil:

      • première suppression des données confidentielles
      • envoie massif de /dev/urandom sur la clé
      • écriture de fichiers qui ressemblent à des données confidentielles censées ne pas sortir mais en réalité préparés pour induire la police en erreur
      • effacement de ces derniers fichiers
      • expédition de la clé

      Mais ça fait trop longtemps que je suis en Chine, et maintenant j'ai beaucoup d'idées un peu tordues...

      Du reste, je viens de lire que remplir la clé de 0 (ou de random) aurait retardé l'expédition de la clé d'une journée.
      Je ne sais pas ce que les avocats utilisent comme clés USB ou comme ordinateur, mais chez moi (TM), formatter une clé en bas niveau prend vachement moins d'une journée...

      Non, en fait la bonne réponse c'était de ne rien effacer parce que c'est pas bien d'essayer de gruger la police, qu'il y a de bonnes chances qu'ils s'en rendent compte tôt ou tard, et que finalement ils vont probablement mal le prendre et à la fin ça va être pire...

      • [^] # Re: Et vous ?

        Posté par (page perso) . Évalué à 3.

        chez moi (TM), formatter une clé en bas niveau prend vachement moins d'une journée

        Certes. Et générer un fichier de plusieurs Giga à partir de /dev/random ? Je pense que le facteur limitant auquel se référait la personne en question se situe là...

        [Xate@Schorl ~]$ time dd if=/dev/random of=/tmp/plop bs=1 count=1024
        1024+0 enregistrements lus
        1024+0 enregistrements écrits
        1024 octets (1,0 kB) copiés, 171,46 s, 0,0 kB/s
        
        real    2m51.465s
        user    0m0.002s
        sys     0m0.034s
        

        Après, on peut utiliser urandom, qui est bien plus rapide, mais théoriquement moins sûr...

        • [^] # Re: Et vous ?

          Posté par . Évalué à 8.

          Mais en même temps, tu t'en fiche là que ça soit pas vraiment aléatoire, ce qui compte c'est d'écraser ce qu'il y a dessus, tu génère pas une clef RSA non plus quoi. Même si la séquence est prévisible, ben, c'est pas grave, ta clef est quand même "écrasée".

          • [^] # Re: Et vous ?

            Posté par . Évalué à 2.

            Une fois la clef prête, il suffit d'écrire dessus et remplier le clef avec des fichiers sans intérêt, même pas besoin d'utiliser random ou /dev/null.

            Ensuite, on efface ses fichiers supplémentaires et le tour est joué.

            "La première sécurité est la liberté"

        • [^] # Re: Et vous ?

          Posté par (page perso) . Évalué à 0.

          Tu peux aussi utiliser /dev/urandom, qui est bien plus rapide pour générer beaucoup de données aléatoires :

          /tmp %  time dd if=/dev/urandom of=/tmp/plop bs=1 count=1024
          1024+0 records in
          1024+0 records out
          1024 bytes (1.0 kB) copied, 0.00294724 s, 347 kB/s
          dd if=/dev/urandom of=/tmp/plop bs=1 count=1024  0.00s user 0.00s system 62% cpu 0.005 total
          
    • [^] # Re: Et vous ?

      Posté par . Évalué à 1.

      Il y a secure-delete sous Debian (la commande s'appelle srm)

  • # Cas des SSD

    Posté par . Évalué à 10.

    Plus généralement, concernant les mémoires de masse flash (pas les simples clef usb), la situation est plus complexe. Le contrôleur fait un peu ce qu'il veut (compresser les données, répartir l'usure, effacer seulement s'il en a l'envie). Il y a aussi des zones où on ne peut pas écrire même en faisant un dd sur le disque complet. Bref, jamais de fichier confidentiel en clair sur un SSD.

    http://hardware.slashdot.org/story/11/02/17/1911217/Confidential-Data-Not-Safe-On-Solid-State-Disks

    Mais également, les SSD sont plus difficiles à analyser par la police. Faire un dd pour récupérer le contenu d'un disque magnétique (ou d'une clef usb) pour analyse est facile, mais pour les mêmes raisons que plus haut, faire un dd sur un ssd peut ne pas renvoyer le contenu effacé. Le seul moyen de savoir ce qu'il y a octet à octet est de lire les données au niveau du microcontrôleur, ce qui est à la fois plus difficile techniquement et juridiquement (il faut justifier de devoir détruire l'appareil et copier subrepticement le contenu sans qu'un suspect le sache n'est plus possible).

    http://hardware.slashdot.org/story/11/03/01/1740240/SSDs-Cause-Crisis-For-Digital-Forensics

  • # Suppression exhaustive

    Posté par (page perso) . Évalué à 2.

    J'écris un gros fichier sur tout le disque, puis un shred dessus.

    rm -rf /media/disk/* /media/disk/.*  # il ne doit pas rester un seul fichier
    dd if=/dev/zerp of=/media/disk/file  # dd sans limite de taille, remplit le disque
    shred /media/disk/file               # toute méthode pour supprimer le contenu d'un fichier
    rm /media/disk/file
    

    De cette manière, et à moins que le disque en garde sous le coude, la totalité des blocs devient atteignable avec un seul gros fichier.

    • [^] # Re: Suppression exhaustive

      Posté par . Évalué à 2.

      Ta technique (remplir avec 1 seul fichier) devrait bien fonctionner, mais j'en profite pour présenter srm (secure rm) http://sourceforge.net/projects/srm/

      Après les passes aléatoires, srm renomme et tronque les fichiers, faisant disparaitre aussi les métadonnées (nom, taille) de la table de fichiers.

      L'algorithme d'effacement est plus complet que shred, il cumule les passes avec des zéros, des passes avec des 1, certaines avec /dev/urandom. L'algorithme est optimisé pour les médias magnétiques et il n'existe encore rien d'optimisé pour les mémoires flash.

      Attention cependant que les systèmes de fichiers journalisés (donc, presque tous) peuvent de leur propore initiative rendre inopérantes ces mesures, en gardant des morceaux de données sensibles dans le journal, ou en y écrivant tous les effacements.

      • [^] # Re: Suppression exhaustive

        Posté par . Évalué à 2.

        Le papier d'origine (1996) du spécialiste. Lire aussi les épilogues en bas pour les développements récents (techniques pour les SSD) et les mises en garde sur les limitations.

        http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

      • [^] # Re: Suppression exhaustive

        Posté par . Évalué à 3.

        L'algorithme d'effacement est plus complet que shred, il cumule les passes avec des z
        zéros, des passes avec des 1, certaines avec /dev/urandom.

        Toutes ces passes n'ont pas d'intérêt. A priori, avec un AFM (microscope à force atomique), on peut scanner en quelques heures la surface équivalente ~10ko. Par contre, on ne sait pas quels 10ko, sur un disque de plusieurs centaine de Go mais en plus, il faut retraiter un fichier de scan de plusieurs centaines de Go pour retrouver les donnés.

        Donc bon...

        "La première sécurité est la liberté"

        • [^] # Re: Suppression exhaustive

          Posté par . Évalué à 4.

          Dans l'hypothèse où tu as donc démonté le disque, tu peux le monter sur un spin-stand (système de rotation et de têtes de disque dur utilisé pour les tests en salle blanche). Ensuite tu passes un bon moment à aligner l'axe de rotation du spin-stand avec celui du qui a écrit les données. Une fois que c'est fait, tu peux lire le signal brut, non pas 1/0 mais une courbe du signal. Éventuellement mets le disque en rotation plus lente pour acquérir le signal avec une plus grande résolution spatiale. Là, tu as accès à deux choses :

          • les débuts et fin de bit (direction longitudinale), qui peuvent présenter les derniers états présents sur le disque.
          • Par un décalage latéral, tu mesures les données off-track, qui avec un peu de chance contiennent encore un état antérieur non effacé (parce que l'effacement a été fait une dizaine de nanomètres d'un côté ou de l'autre de la piste).

          Si tu fais une seule passe d'effacement, y'a ds chances que l'état antérieur soit encore lisible d'un côté ou de l'autre des bits. La procédure décrite est automatisable.

          • [^] # Re: Suppression exhaustive

            Posté par . Évalué à 2.

            A moins que la technologie a été modifié, il est impossible de ré-aligner les têtes de lectures. Les têtes sont calibré en usines avec des paramètres en mémoires flash. Si ses paramètres sont perdus, les données le serait aussi.

            "La première sécurité est la liberté"

            • [^] # Re: Suppression exhaustive

              Posté par . Évalué à 2.

              J'ai vu passer un papier sur récupérer un alignement il y a quelques années. Maintenant les pistes on beaucoup réduit en taille, c'est peut-être plus possible sans les paramètres d'usine... Mais sans enlever le disque de son axe, tu peux essayer de prendre le contrôle du bras et de la tête de lecture au niveau du contrôleur, et récupérer les signaux de bas niveau.

              • [^] # Re: Suppression exhaustive

                Posté par . Évalué à 2.

                A priori, c'est ce qu'ils font en laboratoire pour lire un disque abimé, mais si la flash des données de calibration est morte, il ne peuvent rien faire.

                "La première sécurité est la liberté"

    • [^] # Re: Suppression exhaustive

      Posté par (page perso) . Évalué à 2.

      Sauf qu'on parle de clef USB, c'est-à-dire de la mémoire Flash, il se peut donc que des secteurs ne soient plus inscriptible et donc la méthode ne fonctionne pas. Sauf si la clef est neuve mais il y a toujours un risque.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Suppression exhaustive

        Posté par . Évalué à 1.

        Oui à cause du wear-leveling on efface les secteurs logiques, non les secteurs physiques qui suivant les types d'algo utilisés par le controleur peuvent très bien conserver les data ( un effacement d'un secteur n'est qu'une réallocation d'un secteur vierge le plus souvant).
        Comme mentionné plus haut même en ayant accès à la mémoire en bypassant le controleur et en connaissant l'algo utilisé cela ne doit pas être évidant de retrouvé ses petits.

        • [^] # Re: Suppression exhaustive

          Posté par (page perso) . Évalué à 2.

          Avec le Wear_levelling, les secteurs peuvent être mis en repos. Mais si un seul gros fichier occupe tout l'espace, tous les secteurs sont forcément mobilisés à la fin. Cette méthode ne marche pas pour les metadonnées, comme ça a été pointé plus haut, et pour les secteurs jugés défectueux.

          Rien n'empêche de faire ce que j'ai indiqué, puis de refaire un bon dd/shred sur toute la clé. En principe, tous les secteurs sont parcourus, non ?

          • [^] # Re: Suppression exhaustive

            Posté par (page perso) . Évalué à 3.

            En principe, tous les secteurs sont parcourus, non ?

            Sauf les secteurs défectueux. Ce qui arrive assez « rapidement » sur une clef usb.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Suppression exhaustive

      Posté par . Évalué à 5.

      Hou lallalalalala
      JAMAIS faire un rm -rf /PATH/.* !!!

      L'option f a des propriétés trop forte, le risque de remonter dans la racine est trop grand

      Toujours rm -r uniquement et si ça pose des questions :

      • CTRL-C

      • unalias rm; puis rm -r

        ou

      • /bin/rm -r

      L'option f doit être utilisé avec la plus grande précaution...

      "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

      • [^] # Re: Suppression exhaustive

        Posté par . Évalué à 5.

        À la place de :

        • /bin/rm -r

        tu peut faire :

        • \rm -r

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Suppression exhaustive

        Posté par . Évalué à 5.

        Les bons shells ne transorment pas .* en . et .. ; les bons rm refusent les argument . et .. mais il est vrai qu'on n'est jamais trop prudent avec un rm -r...

    • [^] # Re: Suppression exhaustive

      Posté par . Évalué à 1.

      Pourquoi pas directement /dev/sdX ?
      Au moins aucun FS ne sera suceptible de rendre certaines zones inaccessibles ou de conserver des journaux.

  • # Editeur de texte?

    Posté par (page perso) . Évalué à 3.

    Je n'ai pas ouvert un .doc depuis des années avec un éditeur de texte mais je me souviens que vers les années 2000, il était possible de trouver de cette manière des fragments des anciennes versions du document.
    Si tel est toujours le cas alors, outre les mesures relatives au système de fichier, je transmettrai une version nouvelle du document réalisée par copier coller.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.