Building Custom Kali ISOs
One of the most powerful features of Kali Linux is the ability to create your own flavors of the distribution containing customized tools, desktop managers, and services. This workshop will show you how to create your own personalized Kali Linux ISO, customizing virtually every aspect using the live-build utility and making efficient use of the various meta-packages available in Kali.
The Awesomeness of Live Build
0x00 – Begin by updating the repos, installing the prerequisites, and checking out a fresh version of live-build-config from the Kali Git repositories:
apt-get update
apt-get install git live-build cdebootstrap devscripts -y
git clone git://git.kali.org/live-build-config.git
cd live-build-config
0x01 – Overwrite the default Kali package list, including only the packages you want. In the video, we simply edited the list and changed a few package names.
cat > config/package-lists/kali.list.chroot << EOF
kali-root-login
kali-defaults
kali-menu
kali-debtags
kali-archive-keyring
debian-installer-launcher
alsa-tools
locales-all
dconf-tools
openssh-server
EOF
0x02 – Add a customised syslinux boot entry which includes a boot parameter for a custom preseed file.
cat << EOF > config/includes.binary/isolinux/install.cfg
label install
menu label ^Install Automated
linux /install/vmlinuz
initrd /install/initrd.gz
append vga=788 — quiet file=/cdrom/install/preseed.cfg locale=en_US keymap=us hostname=kali domain=local.lan
EOF
0x03 – Customise the ISO build. In this example, we’ll have the SSH service start by default. To do this, we can use a chroot hook script which is placed in the “hooks” directory:
echo ‘update-rc.d -f ssh enable’ >> config/hooks/01-start-ssh.chroot
chmod +x config/hooks/01-start-ssh.chroot
0x04 – Next, we download a wallpaper and overlay it. Notoce how chroot overlayed files are placed in the includes.chroot directory.
mkdir -p config/includes.chroot/usr/share/wallpapers/kali/contents/images
wget http://1hdwallpapers.com/wallpapers/kali_linux.jpg
mv kali_linux.jpg config/includes.chroot/usr/share/wallpapers/kali/contents/images
0x05 – Add a preseed file that will run through a default Kali installation with no input (unattended). We can include a ready made preseed configuration and alter it as needed:
mkdir -p config/debian-installer
wget https://raw.githubusercontent.com/offensive-security/kali-linux-preseed/master/kali-linux-full-unattended.preseed -O config/debian-installer/preseed.cfg
0x06 – Let’s include a Nessus Debian package into the packages directory for inclusion into our final build. Since we used a 64 bit build, we’re including a 64 bit Nessus Debian package.Download the Nessus .deb file and place it in the packages.chroot directory:
mkdir config/packages
mv Nessus-*amd64.deb config/packages/
0x07 – Now you can proceed to build your ISO, this process may take a while depending on your hardware and internet speeds. Once completed, your ISO can be found in the live-build root directory.
For more live-build implementations, refer to the following:
USB Persistence & Encrypted Persistence
In this workshop, we will examine the various features available to us when booting Kali Linux from USB devices. We will explore features such as persistence, creating LUKS encrypted persistence stores, and even dabble in “LUKS Nuking” our USB drive. The default Kali Linux ISOs (from 1.0.7 onwards) support USB encrypted persistence.
0x01 – Start by imaging the Kali ISO onto your USB stick (ours was /dev/sdb). Once done, you can inspect the USB partition structure using parted /dev/sdb print.
dd if=kali-linux-1.1.0-amd64.iso of=/dev/sdb bs=1M
0x02 – Create and format an additional partition on the USB stick. In our example, we create a persistent partition of about 7 GB in size:
root@kali:~# parted
GNU Parted
2.3
Using
/dev
/sda
Welcome to GNU Parted
! Type
‘help’ to view a list of commands.
(parted) print devices
/dev/sda (480GB)
/dev/sdb (31.6GB)
(parted) select /dev/sdb
Using /dev/sdb
(parted) print
Model: SanDisk SanDisk Ultra (scsi)
Disk /dev/sdb: 31.6GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.8kB 2988MB 2988MB primary boot, hidden
2 2988MB 3050MB 64.9MB primary fat16
(parted) mkpart primary 3050 10000
(parted) quit
Information: You may need to update /etc/fstab.
0x04 – Encrypt the partition with LUKS:
cryptsetup –verbose –verify-passphrase luksFormat /dev/sdb3
0x05 – Open the encrypted partition:
cryptsetup luksOpen /dev/sdb3 my_usb
0x06 – Create an ext3 filesystem and label it.
mkfs.ext3 /dev/mapper/my_usb
e2label /dev/mapper/my_usb persistence
0x07 – Mount the partition and create your persistence.conf so changes persist across reboots:
mkdir -p /mnt/my_usb
mount /dev/mapper/my_usb /mnt/my_usb
echo “/ union” > /mnt/my_usb/persistence.conf
umount /dev/mapper/my_usb
cryptsetup luksClose /dev/mapper/my_usb
Now your USB stick is ready to plug in and reboot into Live USB Encrypted Persistence mode.
Multiple Persistence Stores
At this point we should have the following partition structure:
root@kali:~# parted /dev/sdb print
We can add additional persistence stores to the USB drive, both encrypted or not…and choose which persistence store we want to load, at boot time. Let’s create one more additional non-encrypted store. We’ll label and call it “work”.
0x01 – Create an additional, 4th partition which will hold the “work” data. We’ll give it another 5GB of space.
root@kali:~# parted
/dev
/sdb
GNU Parted
2.3
Using
/dev
/sdb
Welcome to GNU Parted
! Type
‘help’ to view a list of commands.
(parted
) print
Model: SanDisk SanDisk Ultra
(scsi
)
Disk
/dev
/sdb: 31.6GB
Sector
size (logical
/physical
): 512B
/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.8kB 2988MB 2988MB primary boot, hidden
2 2988MB 3050MB 64.9MB primary fat16
3 3050MB 10.0GB 6947MB primary
(parted) mkpart primary 10000 15000
(parted) quit
Information: You may need to update /etc/fstab.
0x02 – Format the fourth partition, label it “work”.
mkfs.ext3 /dev/sdb4
e2label /dev/sdb4 work
0x03 – Mount this new partition and create a persistence.conf in it:
mkdir -p /mnt/usb
mount /dev/sdb4 /mnt/usb
echo “/ union” > /mnt/usb/persistence.conf
umount /mnt/usb
Boot the computer, and set it to boot from USB. When the boot menu appears, edit the persistence-label parameter to point to your preferred persistence store!
Emergency Self Destruction of Data in Kali
As penetration testers, we often need to travel with sensitive data stored on our laptops. Of course, we use full disk encryption wherever possible, including our Kali Linux machines, which tend to contain the most sensitive materials.
root@kali:~# cryptsetup luksAddNuke /dev/sdb3
Enter any existing passphrase:
Enter new passphrase for key slot:
Now dump the keyslots to see the changes:
root@kali:~# cryptsetup luksDump
/dev
/sda5
Device
/dev
/sda5 doesn
‘t exist or access denied.
root@kali:~# cryptsetup luksDump /dev/sdb3
LUKS header information for /dev/sdb3
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: f7 17 b9 a7 9f 7f 9b 21 f2 b9 40 78 c2 97 f5 f0 c2 bb 28 8b
MK salt: f5 a4 80 02 e7 21 0d 7e 5a 64 f4 96 78 a3 15 3c
09 7b 3f 41 80 2b 5c bf c5 de 92 70 69 bb 34 b2
MK iterations: 64500
UUID: 96793acb-c2d3-45b7-aed9-1af952386556
Key Slot 0: ENABLED
Iterations: 258064
Salt: df 3c d6 03 4a 78 ce ef 62 fd f1 56 25 d4 c5 96
2a 12 bb 94 4b d7 cf c1 0a b5 27 47 09 ae 31 46
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 259108
Salt: 30 07 ff ef fc f5 74 65 04 f7 66 87 77 f1 74 4f
7d 2f 76 e2 71 e7 6a 9c 6d c1 c1 7b 80 53 cb c1
Key material offset: 264
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
root@kali:~#
Backup you LUKS keyslots and encrypt them:
cryptsetup luksHeaderBackup –header-backup-file luksheader.back /dev/sdb3
openssl enc -d -aes-256-cbc -in luksheader.back.enc -out luksheader.back
Now boot into your encrypted store, and give the Nuke password, rather than the real decryption password. This will render any info on the encrypted store useless. Once this is done, verify that the data is indeed inacessible.
Lets restore the data now. We’ll decrypt our backup of the LUKS keyslots, and restore them to the encrypted partition:
openssl enc -d -aes-256-cbc -in luksheader.back.enc -out luksheader.back
cryptsetup luksHeaderRestore –header-backup-file luksheader.back /dev/sdb3
Our slots are now restored. All we have to do is simply reboot and provide our normal LUKS password and the system is back to its original state.
With the advent of smaller, faster ARM hardware such as the new Raspberry Pi 2, we’ve been seeing more and more use of these small devices as “throw away hackboxes”. While this might be a new and novel technology, there’s one major drawback to this concept – and that is the confidentiality of the data stored on the device itself. Most of the setups we’ve seen do little to protect the sensitive information saved on the SD cards of these little computers. This fact, together with a nudge from friends on twitter is what prompted us to create an LUKS encrypted, NUKE capable Kali Linux image for our Raspberry Pi 2 device. The following blog post describes the process, so you can repeat it and make your own shiny shiny.
Birds Eye View of the Disk Encryption Process
Before we begin, let’s take a minute to quickly describe what we’ll be doing – as while this process is not complicated, it *is* involved. This is basically our shpiel:
- We download Kali Raspberry Pi 2 (RPi 2) image, dd it to an SD card.
- We chroot to the RPi 2 image and install / update several files in preparation for our crypted boot.
- We create an initramfs file which includes Dropbear and freshly generated SSH keys.
- We rsync the modified rootfs to a temporary backup location, and then delete the rootfs partition from the SD.
- We then recreate an encrypted partition to which we restore the root partition data. That’s it!
If all goes well, the RPi 2 will boot, and then LUKS will kick in and ask for a password to decrypt the root drive, while simultaneously opening a Dropbear SSH session through which you can SSH in and provide a boot decryption password. Oh yeah, did we mention this image also has LUKS NUKE capabilities?
Getting your hands dirty
As always, all our ARM dev is done on a Kali amd64 machine, and we’ve made sure that we have all the dependencies we need. We download the Kali RPi 2 image, extract is and dd it to our SD card, which in our case showed up as sdb2 – adapt as necessary!
dd if=/root/kali-1.0.9-rpi.img of=/dev/sdb bs=1M
Once dd’ed we mount the various partitions and chroot into the Kali RPi 2 image:
mkdir -p /mnt/chroot/boot
mount /dev/sdb2 /mnt/chroot/
mount /dev/sdb1 /mnt/chroot/boot/
mount -t proc none /mnt/chroot/proc
mount -t sysfs none /mnt/chroot/sys
mount -o bind /dev /mnt/chroot/dev
mount -o bind /dev/pts /mnt/chroot/dev/pts
cp /usr/bin/qemu-arm-static /mnt/chroot/usr/bin/
LANG=C chroot /mnt/chroot/
We then update our image and install some essential packages we will need for our process:
rm -rf /var/lib/apt/lists
mkdir -p lists/partial
apt-get update
apt-get install kali-archive-keyring busybox cryptsetup dropbear
We create an initial initramfs file which will trigger the dropbear SSH key generation. We first find out the modules directory version number…
root@kali:/# ls -l /lib/modules/ |awk -F” ” ‘{print $9}’
3.12.26
…and then use that version info to generate the initramfs file.
mkinitramfs -o /boot/initramfs.gz 3.12.26
We configure the OpenSSH service to start at boot, and remember to change the default password!
update-rc.d ssh enable
passwd
Next, we verify that the /boot directory is mounted, and if so, we modify the boot parameters in cmdline.txt and config.txt.
and add / change to the following parameters:
root=/dev/mapper/crypt_sdcard cryptdevice=/dev/mmcblk0p2:crypt_sdcard rootfstype=ext4
Next comes config.txt:
echo initramfs initramfs.gz 0x00f00000 > /boot/config.txt
Now we deal with the Dropbear SSH access. We copy over the SSH private key to our laptop :
cat /etc/initramfs-tools/root/.ssh/id_rsa
…and limit the SSH connection to allow interaction with the cryptroot application only.
nano /etc/initramfs-tools/root/.ssh/authorized_keys
We paste the following before the ssh public key begins.
command=”/scripts/local-top/cryptroot && kill -9 `ps | grep -m 1 ‘cryptroot’ | cut -d ‘ ‘ -f 3`”
We then create a fstab and crypttab with our configure boot device and exit the chroot:
cat <<EOF > /etc/fstab
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mapper/crypt_sdcard / ext4 defaults,noatime 0 1
EOF
echo crypt_sdcard /dev/mmcblk0p2 none luks > /etc/crypttab
We re-generate the initramfs and exit the chroot.
mkinitramfs -o /boot/initramfs.gz 3.12.26
exit
…and proceed to backup our rootfs partition:
umount /mnt/chroot/boot
umount /mnt/chroot/sys
umount /mnt/chroot/proc
mkdir -p /mnt/backup
rsync -avh /mnt/chroot/* /mnt/backup/
Once outside of the chroot, we unmount everything:
umount /mnt/chroot/dev/pts
umount /mnt/chroot/dev
umount /mnt/chroot
Once done, we delete the existing 2nd partition on the SD card, and recreate an empty one, which we set up for LUKS encryption.
echo -e “d\n2\nw” | fdisk /dev/sdb
echo -e “n\np\n2\n\n\nw” | fdisk /dev/sdb
Unplug your SD card and replug it back in to have the new partitions register, then start setting up your encrypted partition.
cryptsetup -v -y –cipher aes-cbc-essiv:sha256 –key-size 256 luksFormat /dev/sdb2
cryptsetup -v luksOpen /dev/sdb2 crypt_sdcard
mkfs.ext4 /dev/mapper/crypt_sdcard
Once ready, we restore the rootfs backup to the now encrypted partition…
mkdir -p /mnt/encrypted
mount /dev/mapper/crypt_sdcard /mnt/encrypted/
rsync -avh /mnt/backup/* /mnt/encrypted/
umount /mnt/encrypted/
rm -rf /mnt/backup
sync
…then unmount and close the volume.
cryptsetup luksClose /dev/mapper/crypt_sdcard
That’s it! Now all that remains to do is boot up the RPi 2 using the modified SD card. The initramfs will load Dropbear and get a DHCP address on your local LAN (you can also hardcode an IP) allowing you to SSH to the booting RPi and enter a decryption password. Once the password is accepted, Dropbear will exit and the RPi will continue to boot. You should see something like the following:
root@kali:~# ssh -i key 192.168.0.52
The authenticity of host ‘192.168.0.52 (192.168.0.52)’ can’t be established.
RSA key fingerprint is a6:a2:ad:7d:cb:d8:70:58:d1:ed:81:e8:4a:d5:23:3a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘192.168.0.52’ (RSA) to the list of known hosts.
Unlocking the disk /dev/mmcblk0p2 (crypt_sdcard)
Enter passphrase: cryptsetup: crypt_sdcard set up successfully
Connection to 192.168.0.52 closed.
root@kali:~#
References
- https://www.ofthedeed.org/posts/Encrypted_Raspberry_Pi/
- http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=7626
Never Ending Security 
