Nous avons déjà expliqué comment créer des "boîtes de piratage jetables" sécurisées à l'aide du Raspberry Pi, mais nous avons pensé qu'il était temps de revenir en arrière et de revoir le processus. Avec tous les nouveaux modèles de Raspberry Pi et les changements de Kali depuis la dernière fois que nous avons couvert cela, nous avons constaté que l'ancien processus avait besoin d'être mis à jour.
En guise d'examen, ce que nous essayons d'accomplir est de créer un appareil autonome «à laisser derrière» qui, une fois découvert, ne permet pas de comprendre facilement ce que vous faisiez. Nous utilisons donc le cryptage complet du disque LUKS avec la capacité LUKS Nuke pour assembler cela. Si vous avez un Raspberry Pi 3 modèle B+, ou vraiment tout autre modèle ou appareil similaire, n'hésitez pas à utiliser les instructions ci-dessous pour configurer votre propre système sécurisé. Ce processus mis à jour est basé sur notre documentation précédente et mis à jour avec quelques suggestions de la communauté.
Aperçu du processus
Avant de nous plonger dans la technologie de ce que nous allons essayer d'accomplir, jetons un coup d'œil à nos objectifs sur la configuration de notre Raspberry Pi 3 Model B+ (ci-après appelé "RPi") :
- Créer une installation Kali Linux RPi normale
- Préparer le système pour un démarrage chiffré avec déverrouillage à distance du disque
- Créez un initramfs configuré avec les clés Dropbear et SSH pour permettre le déverrouillage
- Sauvegarder les données existantes
- Configurer les partitions chiffrées
- Restaurer nos données
- Configurer LUKS Nuke
- Hack !
Cela peut sembler beaucoup, mais c'est vraiment assez simple et une fois terminé, il nous restera un RPi qui démarrera, obtiendra une IP de DHCP, et Dropbear nous permettra de nous connecter via SSH pour fournir la clé LUKS. Cela nous permet d'exécuter le RPi sans tête, tout en gardant nos données sécurisées. Ensuite, lorsque nous en aurons terminé, nous pourrons le récupérer ou le récupérer à distance et détruire nos données avec LUKS NUKE.
Préparation du système de base
Pour commencer, nous devons écrire l'image RPi sur une carte SD. Nous n'aborderons pas cela ici, mais vous pouvez trouver des informations à ce sujet dans nos documents.
Avec cela à l'écart, nous insérons la carte SD dans le RPi et la laissons démarrer. Au premier démarrage, il redimensionnera la carte SD et redémarrera, après quoi il sera prêt à l'emploi. Ensuite, nous nous connectons via SSH, mettons à jour Kali et installons quelques packages dont nous aurons besoin.
apt update
apt dist-upgrade
apt install cryptsetup lvm2 busybox dropbear
Faire le Magic-Fu
Le RPi est tout configuré et prêt à fonctionner, alors mettons-nous la main à la pâte et plongeons dans les choses. Prenez note qu'une fois que nous aurons commencé ce processus, nous allons modifier un certain nombre de fichiers critiques sur notre installation RPi. Il est important de ne pas redémarrer l'appareil ou d'arrêter le système jusqu'à ce que vous soyez prêt, sinon vous vous retrouverez avec un système qui ne démarrera pas.
Tout d'abord, nous devons ajouter une ligne à /boot/config.txt :
echo initramfs initramfs.gz followkernel >> /boot/config.txt
Ensuite, nous souhaitons valider l'emplacement de notre périphérique de système de fichiers racine :
[email protected]:~# cat /etc/fstab
# proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
Prenez note que notre système de fichiers racine vit à /dev/mmcblk0p2 . C'est ce que nous utiliserons pour nos exemples à venir, alors assurez-vous de mettre à jour les instructions avec la valeur que vous avez reçue sur votre système.
Maintenant que nous connaissons l'emplacement de notre système de fichiers racine, nous allons modifier le fichier /boot/cmdline.txt . Par défaut, il contient les éléments suivants :
[email protected]:~# cat /boot/cmdline.txt
dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0
Prenez note de l'entrée lisant root=/dev/mmcblk0p2 . Nous allons le mettre à jour avec un cryptdevice valeur :
root=/dev/mapper/crypt cryptdevice=/dev/mmcblk0p2:crypt
Avec la modification effectuée, notre fichier ressemble à ceci :
[email protected]:~# cat /boot/cmdline.txt
dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mapper/crypt cryptdevice=/dev/mmcblk0p2:crypt rootfstype=ext4 rootwait rootflags=noload net.ifnames=0
Nous devons également modifier /etc/fstab et remplacez le périphérique où notre système de fichiers racine doit actuellement être /dev/mapper/crypt :
[email protected]:~# cat /etc/fstab
# proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mapper/crypt / ext4 defaults,noatime 0 1
#/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
Ensuite, nous devons créer un /etc/crypttab fichier contenant les éléments suivants :
crypt /dev/mmcblk0p2 none luks
Faites particulièrement attention ici :les séparateurs entre les entrées doivent être des tabulations , pas des espaces. Maintenant, avant de commencer à créer notre initramsfs, nous devons faire un petit hack sournois pour forcer l'inclusion de cryptsetup. Pour ce faire, nous allons créer un faux système de fichiers LUKS. Nous jj un fichier vide, formatez-le en LUKS, montez-le et placez-y un système de fichiers.
dd if=/dev/zero of=/tmp/fakeroot.img bs=1M count=20
cryptsetup luksFormat /tmp/fakeroot.img
cryptsetup luksOpen /tmp/fakeroot.img crypt
mkfs.ext4 /dev/mapper/crypt
Ne vous souciez pas trop de définir un mot de passe fort pour cette fausse racine car il n'est utilisé que dans ce cas.
Configurer SSH et Initramfs
Maintenant, nous sommes sur la dernière ligne droite. Cette partie est vraiment cool, car normalement, lorsqu'un système exécutant LUKS démarre, le processus de démarrage s'interrompt pour vous permettre de déverrouiller le disque dur avec votre clé LUKS. Si vous utilisez un système sans tête, ce n'est pas particulièrement pratique.
Pour contourner ce problème, nous allons configurer Dropbear pour qu'il démarre, vous permettre de vous authentifier avec SSH, puis vous connecter pour fournir votre mot de passe LUKS, le tout à distance !
Nous commençons par créer un fichier dans /etc/dropbear-initramfs/authorized_keys qui contient :
command="export PATH='/sbin:/bin/:/usr/sbin:/usr/bin'; /scripts/local-top/cryptroot && kill -9 \`ps | grep -m 1 'cryptroot' | cut -d ' ' -f 3\` && exit"
Il est important de noter que tout doit être sur une seule ligne. Aucun saut de ligne là-dedans. Si vous avez bien configuré cette configuration, elle devrait ressembler à ceci :
[email protected]:~# cat /etc/dropbear-initramfs/authorized_keys
command="export PATH='/sbin:/bin/:/usr/sbin:/usr/bin'; /scripts/local-top/cryptroot && kill -9 `ps | grep -m 1 'cryptroot' | cut -d ' ' -f 3` && exit" ssh-rsa AAAAB3NzaC... [email protected]
Ensuite, nous apportons une petite modification à /usr/share/initramfs-tools/scripts/init-premount/dropbear . Ce changement est dû au fait que nous devons ralentir Dropbear pour nous assurer que la mise en réseau est configurée avant que Dropbear ne démarre. À la fin du fichier, où il se lit :
# On NFS mounts, wait until the network is configured. On local mounts,
# configure the network in the background (in run_dropbear()) so someone
# with console access can enter the passphrase immediately. (With the
# default ip=dhcp, configure_networking hangs for 5mins or so when the
# network is unavailable, for instance.)
[ "$BOOT" != nfs ] || configure_networking
run_dropbear &
echo $! >/run/dropbear.pid
Nous voulons ajouter un simple sommeil déclaration comme suit :
[ "$BOOT" != nfs ] || configure_networking
sleep 5
run_dropbear &
echo $! >/run/dropbear.pid
Une fois cela terminé, nous sommes enfin prêts à créer notre initramfs !
mkinitramfs -o /boot/initramfs.gz
Avant de continuer, nous nous assurons que nos modifications personnalisées ont été intégrées au nouvel initramfs :
lsinitramfs /boot/initramfs.gz | grep cryptsetup
lsinitramfs /boot/initramfs.gz | grep authorized
Une fois cela validé, nous nous assurons que toutes les modifications sont écrites sur le disque et arrêtons le RPi.
sync && sync
init 0
Sauvegarde et restauration
Retirez la carte SD de votre RPi et revenez au système que vous avez initialement utilisé pour écrire la carte SD. Préparons l'environnement :
ls -al /mnt/{chroot,backup,encrypted}
# Please make sure there is nothing here first before you move on, otherwise you will have a bad day.
rm -rf /mnt/{chroot,backup,encrypted}
mkdir -p /mnt/{chroot,backup,encrypted}
Insérez maintenant la carte SD et validez l'ID de l'appareil. Dans notre cas, le périphérique est /dev/sdc2 mais le vôtre peut être différent, ajustez-le si nécessaire sur votre système. Nous montons l'appareil et faisons une sauvegarde du système de fichiers :
mount /dev/sdc2 /mnt/chroot/
rsync -avh /mnt/chroot/* /mnt/backup/
umount /mnt/chroot
Une fois cela fait, nous supprimons la 2ème partition existante sur la carte SD et en recréons une vide, que nous configurons pour le cryptage LUKS.
echo -e "d\n2\nw" | fdisk /dev/sdc
echo -e "n\np\n2\n\n\nw" | fdisk /dev/sdc
Une fois les partitions mises à jour, nous les rechargeons en exécutant partprobe puis configurez LUKS sur la nouvelle partition :
cryptsetup -v -y --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdc2
cryptsetup -v luksOpen /dev/sdc2 crypt
mkfs.ext4 /dev/mapper/crypt
Avec cela à l'écart, nous restaurons la sauvegarde du système de fichiers racine sur la partition maintenant chiffrée.
mount /dev/mapper/crypt /mnt/encrypted/
rsync -avh /mnt/backup/* /mnt/encrypted/
sync
umount /mnt/encrypted/
cryptsetup luksClose /dev/mapper/crypt
Le tester
Vous pouvez maintenant remettre la carte SD dans le RPi et le laisser démarrer. Si vous regardez le démarrage, vous devriez voir Dropbear démarrer. À ce stade, vous devriez pouvoir vous connecter en SSH au système et déverrouiller le lecteur.
[email protected]:~# ssh -o "UserKnownHostsFile /dev/null" [email protected]
The authenticity of host '10.42.42.94 (10.42.42.94)' can't be established.
ECDSA key fingerprint is SHA256:L+QVP+OmncGDleuEoj77OlRGuCji2gp0c1gMYjUupU0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.42.42.94' (ECDSA) to the list of known hosts.
Please unlock disk /dev/mmcblk0p2 (crypt):
cryptsetup (crypt): set up successfully
Connection to 10.42.42.94 closed.
La polyvalence de ces petits appareils alliée à la puissance de Kali ne cesse de nous étonner. Nous nous retrouvons maintenant avec un joli système sans tête que nous pouvons exploiter avec une relative confiance que, même s'il est découvert, il ne sera pas trop simple d'y entrer.
Mais nous n'avons pas encore fini ! Ajoutons quelques fonctionnalités LUKS NUKE :
cryptsetup luksDump /dev/mmcblk0p2
cryptsetup luksAddNuke /dev/mmcblk0p2
Maintenant, lorsque nous nous connectons en SSH, nous avons un mot de passe que nous pouvons entrer pour permettre à la carte SD de se déverrouiller et de poursuivre le processus de démarrage, et un autre qui détruit l'en-tête LUKS, rendant les données inaccessibles. Si vous vous retrouvez dans une situation où vous ne pouvez pas récupérer l'appareil, cette option pour graver l'appareil pourrait être très utile. Si vous voulez être vraiment fantaisiste, vous pouvez également combiner cela avec la transformation du RPi en un point d'accès sans fil, vous permettant de vous connecter à distance et de déverrouiller / neutraliser le système via une connexion sans fil. Ceci est très utile si vous n'avez pas un accès direct continu au réseau auquel le RPi sera attaché.