Modification de phrase de passe pour disque chiffré LUKS

Une phrase de passe complexe, longue et difficile à deviner c’est bien. La changer régulièrement c’est mieux. On peut également avoir besoin de plusieurs phrases de passe (si on veut confier son ancien lappy à une voisine dans le besoin, par exemple).

Les disques chiffrés avec Cryptsetup/LUKS sont de petites merveilles. LUKS supporte, en effet, plusieurs phrases de passe stockée dans les slots. On peut, à loisir, ajouter et supprimer des phrases de passe (jusqu’à 8). Facile alors de fournir une phrase de passe temporaire le temps d’un prêt.

Lister les infos :
% cryptsetup luksDump /dev/disk/by-id/scsi-SATA_Hitachi_HDS7216_PVF904Z23V7KLN-part1
LUKS header information for /dev/disk/by-id/scsi-SATA_Hitachi_HDS7216_PVF904Z23V7KLN-part1

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 1032
MK bits:        128
MK digest:      08 fc d8 1c f8 49 a9 a1 8e 47 8e b4 32 11 64 4a 5e ca 14 26
MK salt:        0a 24 2a 6e 90 68 a0 8e d3 06 bd 25 f5 c3 7e af
                d3 e9 0b 54 3a d3 f3 a3 b2 bd 4a 63 4a 54 63 c4
MK iterations:  10
UUID:           8702329c-0242-4d20-ad8c-1a5986d0ea82

Key Slot 0: ENABLED
        Iterations:             178684
        Salt:                   d5 76 c0 bc 93 55 76 31 15 75 10 65 76 ef 0e 32
                                02 6a 88 5c 95 b4 83 c2 dd 3b d1 36 de 58 b0 55
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Nous avons un slot (le 0) d’utilisé. C’est celui de la phrase de passe utilisé lors de la création du disque chiffré. Nous pouvons en ajouter une avec :
% cryptsetup luksAddKey /dev/disk/by-id/scsi-SATA_Hitachi_HDS7216_PVF904Z23V7KLN-part1
Enter any LUKS passphrase:
key slot 0 unlocked.
Enter new passphrase for key slot:
Verify passphrase:
Command successful.
On entre la phrase de passe existante pour débloquer le périphérique LUKS, puis la nouvelle, deux fois. On vérifiera le bon déroulement de l’opération avec un nouvel appel à la demande d’information :
Key Slot 0: ENABLED
        Iterations:             178684
        Salt:                   d5 76 c0 bc 93 55 76 31 15 75 10 65 76 ef 0e 32
                                02 6a 88 5c 95 b4 83 c2 dd 3b d1 36 de 58 b0 55
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: ENABLED
        Iterations:             182347
        Salt:                   43 e8 e2 ee d3 be bc 4d 51 3f cc c8 16 4e 80 9b
                                83 60 28 cc 28 c9 91 32 eb 48 2d 21 5f 92 c7 74
        Key material offset:    136
        AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Le slot 1 est maintenant utilisé. On utilise ensuite la configuration habituelle pour tester (via le script d’init).
% /etc/init.d/cryptdisks start
Starting remaining crypto disks… satahitachi (starting)Enter LUKS passphrase:
key slot 1 unlocked.
Command successful.
 satahitachi (started)done.
Ça marche (bien sûr). On voit dans la sortie que c’est la clef sur le slot 1 qui a été utilisée.

Pour retirer une phrase de passe, c’est :
% cryptsetup luksDelKey /dev/disk/by-id/scsi-SATA_Hitachi_HDS7216_PVF904Z23V7KLN-part1 1
Enter any remaining LUKS passphrase:
key slot 0 unlocked.
Command successful.
On utilise alors l’une des phrase de passe stockée dans l’un des slot restant (ici 0). Un chagement de phrase de passe revient à ajouter la nouvelle et supprimer l’ancienne, tout simplement. C’est tout.

Vérifier rapidement la vulnérabilité de sa clef SSH Debian

Comme vous le savez sans doute une faille majeure a été trouvée dans l’implémentation SSL présente dans les distribution Debian et dérivée. Cette faille est présente dans les distributions depuis environ deux ans et concerne le générateur de nombres pseudo-aléatoire (PRNG), réduisant ainsi l’espace de clef de manière catastrophique.

Vous trouverez sur http://metasploit.com/users/hdm/tools/debian-openssl/ deux archives contenant tout l’espace de clef. Pour savoir si votre clef est dans le lot c’est très simple. Désarchivez l’une ou l’autre des archives (selon le type et la taille de clef). Les paires de clefs sont stockées dans des fichiers nommés en utilisant l’empreinte de la clef publique.

Vous pouvez donc récupérer l’empreinte de votre clef avec:
% ssh-keygen -l -f id_dsa | cut -d  »  » -f 2 | sed « s/://g »
f9040774bddfdfed7c2fccdfac60ad26
Regardez ensuite si un fichier est présent dans le répertoire contenant l’espace de clef avec un simple ls. Si c’est le cas, vous êtes mal. Un attaquant n’aura qu’à essayer tout l’espace de clef et finira par avoir un accès à un moment ou un autre (selon le nombre de tentatives infructueuses autorisées pour une adresse, directive MaxAuthTries dans sshd_config). Mais ce n’est qu’une question de temps.

Rendre disponible un tunnel SSH

Tout le monde connaiît OpenSSH (non ? Tant pis) et les possibilités de création de tunnel. Très pratique pour sécuriser (chiffrer) des protocoles trop bavards (HTTP; FTP, POP3, etc), il est possible de tunneliser presque n’importe quoi depuis le client SSH et le serveur (et inversement). Plus rarement utilisé, il est aussi possible de partager le tunnel du client sur le réseau.

L’idée de base est depuis la machine A d’accéder au serveur HTTP sur la machine B mais sans laisser circuler plein de HTTP en clair dans les tuyaux. On utilise donc sur la machine A :
% ssh -L 8000:localhost:80 machineb
Dès lors, sur la machine B on peut accéder au serveur HTTP de B avec l’adresse http://localhost:8000/. OpenSSH se charge comme un grand de chiffrer tout ça et de l’enfoncer joyeusement dans le tunnel.

Pour faire plus simple on peut ajouter dans son ~/.ssh/config :
Host montunnelhttp
Hostname machineb
Port 22
Compression yes
CompressionLevel 6
LocalForward 8000 127.0.0.1:80
et ensuite utiliser simplement
% ssh montunnelhttp
Seulement voilà. Le point d’entrée du tunnel est localhost:8000 sur A. Si l’on veut, par exemple, vérifier que son application Web ressemble vaguement à quelque chose avec un navigateur du mal sous un OS du mal, on se retrouve coincé. « Bin, je sors mon iptables de la mort et de forwa… » NON ! OpenSSH a ce qu’il faut (idem pour le « j’installe Putty et…« . Moins je touche aux OS sales, moins je m’ennerve, mieux je me porte) :
% ssh -L mon_ip_sur_eth0:8000:localhost:80 machineb
On bind gentillement sur l’adresse de l’interface ethernet de la machine cliente. Du coup, OpenSSH écoute le port 8000 de l’interface en question. Depuis notre OS du mal, on utilise http://mon_ip_sur_eth0:8000, et rulez…

Côté ~/.ssh/config, on utilisera ceci :
Host montunnelhttp
Hostname machineb
Port 22
Compression yes
CompressionLevel 6
GatewayPorts yes
LocalForward 8000 127.0.0.1:80

A la recherche de rootkits

Une méthode (toute relative) pour vérifier si un rootkit est installé sur une machine est d’utiliser ceci :
find /usr -type f -mtime -7 | less
On recherche tout simplement les fichiers dont la date de modification est 7*24h au minimum. Bref, si un attaquant a remplacé un exécutable ou une bibliothèque dernièrement (sans changer la date de dernière modification), vous le saurez.