| View previous topic :: View next topic |
| Author |
Message |
irenicus09
Tux's lil' helper
Joined: 07 Jun 2013
Posts: 118
|
 Posted: Tue Apr 25, 2017 2:01 pm Post subject: Auto verifying files in boot partition |
 |
|
So, I have my boot partition on a usb and I have full disk encryption with Luks + Lvm.
The point of having a separate boot partition on USB or any other removable media is to guard against evil maid style of attacks...so that in my absence someone can not mess around or tamper with my boot partition.
Anyway, the problem is sometimes I forget to keep the USB with me and might have it lying around. So I'm trying to think of an effective way to figure out whether the contents of my boot partition have changed or not.
Here's how I approached the problem. Initially mount boot partition in read-only mode, generate hash of all files in boot partition and store the checksum locally..and then verify contents of boot partition against locally stored checksum. Ofcourse after installing / updating kernel or some other file, the checksum file needs to be manually removed and let the script auto generate a new one.
Since I'm learning bash, I thought it would be a good practice for me 
| Code: |
#!/bin/bash
# Filename: mount-boot.sh
# Description: Script to verify contents of boot partition
# Version: 0.1
# Author: irenicus09
# Last Modified: Tue Apr 25, 2017 (08:36 PM)
# User settings
checksum_tool="/usr/bin/sha512sum"
hash_file="/etc/boot_hash.txt"
boot_directory="/boot"
current_directory="$(pwd)"
# Colors & other stuff
font_bold="\e[1m"
color_red="\e[31m"
color_green="\e[32m"
color_yellow="\e[33m"
color_none="\e[0m"
sign_warning="$color_red$font_bold[!]$color_none"
sign_plus="$color_green$font_bold[+]$color_none"
sign_info="$color_yellow$font_bold>>$color_none"
# Checking if argument is valid
if [[ "$1" == "" || "$#" > 1 ]]; then
echo "Usage: $0 [partition]"
echo " $0 sda1"
exit 1
fi
# Checking if we have root priviledge
if [[ "$EUID" != "0" ]]; then
echo -e "$sign_warning Root priviledge required"
exit 1
fi
# Checking whether partition is mounted or not
grep "/dev/$1" "/proc/mounts" &>/dev/null
# Specified partition not mounted, so we try to mount it
if [[ "$?" == "1" ]]; then
mount -o ro "/dev/$1" "/boot/" &>/dev/null
# Checking if mounting failed due to invalid input partition
# If mounting fails it returns status "1" or "32"
if [[ "$?" != "0" ]]; then
echo -e "$sign_warning Unable to mount /dev/$1"
exit 1
fi
fi
# Checking again if we have right partition mounted in right directory
partition="$(mount | grep $boot_directory | cut -d " " -f1 | cut -d "/" -f3)"
if [[ "$?" != "0" || "$partition" != "$1" ]]; then
echo -e "$sign_warning Partition /dev/$1 mounted in invalid location"
exit 1
fi
# Assuming we have successfully mounted partition beyond this point
#==================================================================
cd $boot_directory
# If hash file exists
if [[ -f "$hash_file" ]]; then
echo -e "$sign_info Verifying files.."
$checksum_tool -c $hash_file
# If atleast 1 file has incorrect hash
if [[ "$?" != 0 ]]; then
echo -e ">>$color_red$font_bold WARNING:$color_none Hash mismatch detected, please check manually"
else
echo -e "$sign_plus Hashes verified successfully, no anomalies detected"
fi
else # Hash file doesn't exist
echo -e "$sign_warning No previous hash file exists.."
echo -e -n "$sign_info"
read -p " Generate new hash (Y/n)? " input
if [[ "$input" == 'Y' || "$input" == 'y' || "$input" == "" ]]; then
$checksum_tool * > $hash_file
echo -e "$sign_plus Generated hashes successfully!"
fi
fi
# Unmounting boot partition safely
if [[ "$current_directory" == "$boot_directory" ]]; then
cd $HOME
else
cd $current_directory
fi
umount "$boot_directory"
if [[ "$?" != "0" ]]; then
echo -e "$sign_warning Error unmounting boot partition"
exit 1
fi
exit 0;
|
Sample output:
| Code: |
mount-boot.sh sda1
>> Verifying files..
initramfs-genkernel-x86_64-4.4.57-gentoo: OK
initramfs-genkernel-x86_64-4.4.59-gentoo: OK
initramfs-genkernel-x86_64-4.4.61-gentoo: OK
kernel-genkernel-x86_64-4.4.57-gentoo: OK
kernel-genkernel-x86_64-4.4.59-gentoo: OK
kernel-genkernel-x86_64-4.4.61-gentoo: OK
System.map-genkernel-x86_64-4.4.57-gentoo: OK
System.map-genkernel-x86_64-4.4.59-gentoo: OK
System.map-genkernel-x86_64-4.4.61-gentoo: OK
[+] Hashes verified successfully, no anomalies detected
|
Another thing is should I also consider hashing files in grub directory? What other ways can I approach the problem or improve the script further?
As always I appreciate your time and feedback.
Thanks. |
|
| Back to top |
|
 |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6228
Location: Room 101
|
| Posted: Tue Apr 25, 2017 11:26 pm Post subject: |
|
|
irenicus09 ...
admittedly I haven't given this much thought, but why not check the device itself?
| Code: | # md5sum /dev/sda1
15c00cf7ec43751ea65618f50eb85cb6 /dev/sda1
# mount /dev/sda1 /boot
# touch /boot/foo
# umount /boot
# md5sum /dev/sda1
5c1b447109927bbbb9ed094211a00a4b /dev/sda1 |
Also ... you have a maid? ;)
best ... khay |
|
| Back to top |
|
|
cboldt
l33t
Joined: 24 Aug 2005
Posts: 864
|
| Posted: Tue Apr 25, 2017 11:33 pm Post subject: |
|
|
| Not just a maid, but an evil maid! |
|
| Back to top |
|
|
cboldt
l33t
Joined: 24 Aug 2005
Posts: 864
|
| Posted: Tue Apr 25, 2017 11:44 pm Post subject: |
|
|
Following your question about testing the grub directory, the issue of detecting file changes generically can be handled with tripwire and similar programs. The system has to be tested periodically to make that worth the trouble.
Intruders can also leave "few tracks" by adding new files in odd locations that aren't apt to be watched.
Programs like rkhunter hash a few files that are critical for forensic work, and also look for known signatures of rootkits.
I personally think it is important to keep an eye on network activity (and a tight firewall), and especially on auth.log - not that the network is the only vector for an attack, just that being attached to the network is risky that way.
Not to discourage you, but much of what you are doing is reinventing the wheel. Although the idea of having /boot on removable media is something I hadn't thought of doing; and your concern about the integrity of those contents is certainly valid. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6228
Location: Room 101
|
| Posted: Tue Apr 25, 2017 11:46 pm Post subject: |
|
|
| cboldt wrote: | | Not just a maid, but an evil maid! |
cboldt ... I'd settle for either ;)
best ... khay |
|
| Back to top |
|
|
cboldt
l33t
Joined: 24 Aug 2005
Posts: 864
|
| Posted: Wed Apr 26, 2017 12:36 am Post subject: |
|
|
| I was figuring "evil" costs more, if you can get it at all. |
|
| Back to top |
|
|
irenicus09
Tux's lil' helper
Joined: 07 Jun 2013
Posts: 118
|
| Posted: Wed Apr 26, 2017 1:53 am Post subject: |
|
|
@khayyam:
Hmm, interesting...I haven't had the thought of hashing the whole partition 
I thought about another problem...suppose that I lost the usb drive (removable media)...let's say my maid is really evil and stole it.
All I'll have is just a full disk encrypted hard disk with a customised gentoo install that I had spent months customizing and nothing that I can do other than looking at it in frustration
Anyway, to address that problem I have used dd to clone the boot partition on usb to a backup drive..so that in case I lose existing one I can clone it to a new usb drive.
Now I tried a small test and saw that hash of boot partition cloned to a new drive and that on existing one doesn't match...but when I checked using the script the contents are intact..not sure why that is the case. Also hashing the entire partition takes couple of minutes as opposed to a few seconds when done on small files.
Anyway, both are valid approaches to the problem..I'm just trying to figure out the pros and cons of each.
Thanks for showing me an alternative approach that I haven't thought about.
Man so many response...I think I'll come back later and go through it lol.
Thanks again guys |
|
| Back to top |
|
|
cboldt
l33t
Joined: 24 Aug 2005
Posts: 864
|
| Posted: Wed Apr 26, 2017 2:22 am Post subject: |
|
|
Losing the USB drive really isn't much of an issue. There are ways around that. You could boot with sysrescuecd and rebuild at least one kernel and initramfs. I save a copy of working kernel .config files in /root for that sort of contingency.
I make backups of the system (including /boot, which is mounted ONLY to make these backups) to a removable hard drive. I know that is bigger than a thumb drive, and /boot is sitting on the HD, so evil maid can get to it if she can figure out my password (or can figure out booting with sysrescuecd).
If evil maid can boot off sysrescue, she can copy your HD, or wipe it out, even though she can't access it. Then she'll hold your dog hostage until you give up the encryption. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6228
Location: Room 101
|
| Posted: Wed Apr 26, 2017 5:02 am Post subject: |
|
|
| irenicus09 wrote: | | I thought about another problem...suppose that I lost the usb drive (removable media)...let's say my maid is really evil and stole it. All I'll have is just a full disk encrypted hard disk with a customised gentoo install that I had spent months customizing and nothing that I can do other than looking at it in frustration :P |
irenicus09 ... if I were concerned about evil maids I'd probably be at the point of abandoning the use of a computer. As far as I know I'm not subject to covert appropriation of my data, anyone who might make this effort would find nothing of interest. My threat model is loss or theft, if someone steals the machine I'd not want them to have access to user data (such as login credentials, contacts, etc), anyone looking to hire, and implant, an evil maid would end up expending more on costs than the value they might gain (particularly considering the age of my various hardware). If they were after data, then there is nothing of value, except perhaps to me. So, that said, I don't see the point in verifying the integrity of /boot as I can't see anyone fiddling with it under normal circumstances. If I loose the machine, or it gets stolen, then they are going to have to figure out how to get the machine to boot, before they can sell, or use, it ... and I've made that difficult. I don't expect it to be returned if this happens, but at least I know that all the data is at least safe, if they want to hack away at the files in boot then, by all means, be my guest. So, can you foresee a circumstance in which someone might gain access to /boot and, having the skills, modify the kernel, or initramfs, and so gain the luks passphrase? If not, then I think it's more likely that you loose the USB stick, and perhaps lock yourself out.
| irenicus09 wrote: | | Now I tried a small test and saw that hash of boot partition cloned to a new drive and that on existing one doesn't match...but when I checked using the script the contents are intact..not sure why that is the case. Also hashing the entire partition takes couple of minutes as opposed to a few seconds when done on small files. |
That would depend on the size of sda1 I guess. Anyhow, when you clone 'sda1' it will change when written to another disk (ie, UUID, etc) so the md5sum will be different, if you want a copy then make an image:
| Code: | # md5sum /dev/sda1
526e04f8f7b99204f8bf02b01bd73e5d /dev/sda1
# dd if=/dev/sda1 of=sda1.img
409600+0 records in
409600+0 records out
209715200 bytes (210 MB, 200 MiB) copied, 7.38243 s, 28.4 MB/s
# md5sum sda1.img
526e04f8f7b99204f8bf02b01bd73e5d sda1.img |
| irenicus09 wrote: | | Thanks for showing me an alternative approach that I haven't thought about. |
You're welcome & best ... khay |
|
| Back to top |
|
|
irenicus09
Tux's lil' helper
Joined: 07 Jun 2013
Posts: 118
|
| Posted: Wed Apr 26, 2017 3:47 pm Post subject: |
|
|
@khayyam ...
You are right, there's a high chance of me locking myself out or losing the USB than someone with the skills or the time to pull something like this off and tamper with my boot partition...but I tried this just as a proof of concept to test if something like this is possible using Gentoo and of course anything is possible when you're using Gentoo! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
