aux grands connaisseurs de NTFS ;ecrasement definif d'un fichier

[inviteed6105a2]

Bonjour,
Pour mes utilisateurs Windows
J ai réalisé 3 scripts (batch dos ) pour effectuer un certain nombres d'opérations sécurisés a l ouverture session ; montage VPN , volume crypté , etc.
Comme on peut cracker un password Windows en cas d' ordi volé ;
Le premier script vérifie un certain nombre de paramètres telle que adresse IP publique de sortie internet et quelques autres paramètres du genre.
pour éviter que le batch soit lisible tel quel je l ai converti en fichier .exe avec un utilitaire .

si tout est OK , mon script lance un 2eme script qui monte automatiquement un volume veracrypt puis lance le troisième batch situé dans le volume veracrypt.
si mon script détecte quelque chose de "bizarre" il ré-écrit une 20 ene de fois des données par dessus le 2 eme script
( du type : echo "r6Sas2fxKtxrCqQI36p3" > c:\utilisateur\2eme-script.bat)

et de cette façon empêche quiconque de monter définitivement le volume veracrypt sans le password.


ce que j'aimerais savoir c'est si cela suffit a éviter que quelqu’un d'autre que la N.S.A. puisse récupérer le script d'origine (et donc le password veracrypt) avec un utilitaire type undelete ?






p.s. a l'origine j étais parti sur un delete du ficher avec un sdelete derrière ; mais c est vraiment trop long et trop gourmand en ressources;
et je n ai pas trouver de soft en ligne de commande qui ré écrive x-fois sur un fichier.

p.p.s. je vois d 'ici que quelqu'un va répondre a ma question avec un "mais pourquoi tu demande pas a tes utilisateurs de taper un mot de passe pour le volume veracrypt ?" mais cela ne répondra pas a ma question. car j ai une autre problématique avec une appli qui utilise des tokens qui expirent très rapidement , et des utilisateurs un peu lent du clavier ou parti en pause café en attendent que ça démarre

merci d'avance
-----

[pm42]

Tout dépend de qui tu veux te protéger. Une personne sérieuse qui a volé l’ordi commencera par faire une copie complète de ton disque. Au 1er effacement, il recommencera le process en désactivant tes scripts par exemple.

[bisou10]

+1

Un simple boot avec une clé USB linux exp(l)ose ton script #2.

Pour répondre à ta question, l'effacement n'est pas sécurisé. D'une part parce que ton echo doit au moins faire la taille complète du script, d'autre part parce que tu ne maitrises pas les décisions NTFS qui peut choisir de composer ton fichier ailleurs puis de mettre à jour l'index de fichiers. Ajoute à ca le TRIM ou autre algo d'opti orienté mémoire flash... et c'est difficile de te répondre avec certitude.

Pas trop le choix pour la sécurisation, le mot de passe à saisir par l'utilisateur pour le montage d'un volume reste indispensable (ca peut être au boot par contre, chiffrement de disque et non pas de volume à monter après le boot).

[inviteed6105a2]

+1
Un simple boot avec une clé USB linux exp(l)ose ton script #2.
.

non pas vraiment car je n ai pas dévoilé toute ma statégie de sécurité il y as aussi du virtual disk dans le process et différentes autres petite choses

[A voir en vidéo sur Futura]

[inviteed6105a2]

tiens d ailleurs je crois tenir ma solution
je vais faire plusieurs formats du disque virtuel avec différentes taille de cluster. ce qui devrais empecher de pourvoir récupérer le disque avec un undelete

[Ikhar84]

Comme dit plus haut, il n'y a aucune garantie de sécurité.

Pour assurer un effacement sécurisé, il faudrait connaitre précisement les secteurs sur lesquels est stocké le script n°2.
Ce qui n'est pas possible avec un simple script.

Par contre, effacer le script et saturer la totalité de l'espace libre avec des 0 ou des données aléatoires, deux ou trois fois, rendrait l'effacement assez sécure...

Avec une partition dédiée de quelques Mo, cela ne devrait pas être trop gourmand en temps et en proc...

[inviteed6105a2]

au final mon script 1 en cas d'échec fait un rmdir puis un sdelete avec 7 passe du disque virtuel . comme il ne fait que 50 Mo ca prend 10 sec et vu que le disque virtuel lui n'as pas changer de taille sur le disque physique cela devrais empecher définitivement de pouvoir récuperer le script2

[invite2d7144a7]

Bonjour,

au final mon script 1 en cas d'échec fait un rmdir puis un sdelete avec 7 passe du disque virtuel . comme il ne fait que 50 Mo ca prend 10 sec et vu que le disque virtuel lui n'as pas changer de taille sur le disque physique cela devrais empecher définitivement de pouvoir récuperer le script2

Tu peux faire tout ce que tu veux, il y aura 2 cas :
1- tu tombes un un "lambda" qui n'y connaît pas grand chose, alors ça peut marcher (sans garantie !!)
2- sur un "chevronné", il passera les doigts dans le nez

Tu te fatigues donc pour rien

[Ikhar84]

En l'occurence, ici, les deux principales failles sont
1. Le premier scrip
2. Le fait d'avoir dévoilé (une partie au moins) ta stratégie...

Je sais pas si on exposer ici un exemple de procédure pour exploiter ces failles... en MP alors...

[bisou10]

Comme whoami ! Pour moi c'est "defective by design", le stockage dans un fichier de la clé de chiffrement

[inviteed6105a2]

Comme whoami ! Pour moi c'est "defective by design", le stockage dans un fichier de la clé de chiffrement

mmm perso j essaye de prendre en compte toute les menaces pas seulement les plus évidentes.


Pour info tout les ans je demande un petit budget pour effectuer des tests d intrusion.
et ce que j ai pu constater c est qu'autant les utilisateurs on une vague notion de sécurité sur les passwords.
Autant il ne sont absolument pas conscient des autres formes de hacking.
l année dernière j ai testé le micro testé dans une plante grasse envoyé par un fournisseur ; ça marche plutôt bien , bien que cela ait été un casse tête juridique a mettre en place a cause de la législation sur le travail
cette année je teste les key-logger physique et la c'est jackpot....
j ai tester sur un bureau de 5 personnes sans avertir personne. avec 6 key-logger a 50 € pièce; sur lesquels j ai au préalable collé une étiquette faite par mes soins sous un logiciel de dessin avec : "secure keybord" un joli logo et un numéro de série....
Ca fait plus d'un mois qu'ils sont en place et que j'en remplace 1 toute les semaine pour relever les données...
Pour l instant ca n'as dérangé personne .
Donc bon; même en ayant encrypter tout le disque avec un password de 80 caractères numerico-alphanumérico-caractère spécialo- majusculé.......
il y as des moyens tellement plus facile que le brut-force pour récupérer des passwords...

[invite6486d7bd]

Je n'ai peut-être pas tout compris, mais est-il nécessaire de mettre le .bat sur le disque ? S'il se trouve sur une clef USB qui part en fumée (comme dans Mission Impossible ) après l'instal, c'est un problème ?

[inviteae524c6f]

Je trouve ça très bien que tu te lances dans ce genre de projet pour sécuriser les postes sous ta gestion.
Pour tes key-logger, tu ferais bien de former (d'informer ?) tes utilisateurs avant l'application officielle de la RGPD ou tu risque gros.

Mais la majeure partie des systèmes sont faillibles et encore plus quand ils sont pensés par un sysadmin seul dans son coin.

Autrement tu peux toujours crypter tes scripts en passant sur powershell.

Et autrement tu fais mettre en place un système que crypte le disque entièrement.
Tu gères ta politique d'effacement de données comme tu veux, mais notre métier est amené à changer, le bricolage va te compliquer la vie.

[invite84ef135b]

À propos de l'effacement sûr d'un fichier:

Sur un disque mécanique, lorsqu'on réécrit un fichier avec la même taille, Ntfs écrase normalement les même secteurs déjà attribués au fichier. Les soucis viennent avec les disques flash et apparentés, clefs USB notamment.

Pour répartir l'usure, le contrôleur du disque Flash écrit à de nouveaux endroits même lorsque le système d'exploitation lui indique la même adresse LBA pour le même fichier, et tient à jour une table des correspondances. Donc, si un logiciel d'effacement sûr réécrit le même fichier ou la même LBA, le contrôleur du disque Flash mettra les données écrasantes ailleurs, et les données à supprimer restent dans le disque. Le général Rondot de la DGSE s'était fait piéger ainsi après l'opération Clearstream montée contre Sarko.

Avec les disques Flash, la seule solution que je connaisse est de saturer tout l'espace libre du disque après avoir effacé le fichier. Et j'ai bien écrit : l'espace libre du disque, pas du volume. Le contrôleur du disque ignore ce que sont des volumes (partitions, si vous préférez) et où ils sont.

Puisque nous somme dans NTFS : il offre un cryptage des fichiers qui dépend du compte d'usager et de son mot de passe, auxquels il ajoute du sel (=séquence pseudo-aléatoire). Sauf qu'en France, on peut installer un nouveau Windows sur le disque ou sur un autre disque, créer un compte d'usager avec les mêmes nom et mot de passe, et accéder aux fichiers. Donc, le sel n'est pas aléatoire. Je suppose qu'on peut accéder à distance si les réglages chez la cible le permettent. Ce gouffre de sûreté français ancien (Nt4-2k-Xp) se corrige par KB955417. Ou mieux, en utilisant un autre cryptage que celui de NTFS.