Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Auto verifying files in boot partition
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
irenicus09
Tux's lil' helper
Tux's lil' helper


Joined: 07 Jun 2013
Posts: 118

PostPosted: Tue Apr 25, 2017 2:01 pm    Post subject: Auto verifying files in boot partition Reply with quote

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 :P

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
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Tue Apr 25, 2017 11:26 pm    Post subject: Reply with quote

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
View user's profile Send private message
cboldt
l33t
l33t


Joined: 24 Aug 2005
Posts: 829

PostPosted: Tue Apr 25, 2017 11:33 pm    Post subject: Reply with quote

Not just a maid, but an evil maid!
Back to top
View user's profile Send private message
cboldt
l33t
l33t


Joined: 24 Aug 2005
Posts: 829

PostPosted: Tue Apr 25, 2017 11:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Tue Apr 25, 2017 11:46 pm    Post subject: Reply with quote

cboldt wrote:
Not just a maid, but an evil maid!

cboldt ... I'd settle for either ;)

best ... khay
Back to top
View user's profile Send private message
cboldt
l33t
l33t


Joined: 24 Aug 2005
Posts: 829

PostPosted: Wed Apr 26, 2017 12:36 am    Post subject: Reply with quote

I was figuring "evil" costs more, if you can get it at all.
Back to top
View user's profile Send private message
irenicus09
Tux's lil' helper
Tux's lil' helper


Joined: 07 Jun 2013
Posts: 118

PostPosted: Wed Apr 26, 2017 1:53 am    Post subject: Reply with quote

@khayyam:

Hmm, interesting...I haven't had the thought of hashing the whole partition 8O

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

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 :P
Back to top
View user's profile Send private message
cboldt
l33t
l33t


Joined: 24 Aug 2005
Posts: 829

PostPosted: Wed Apr 26, 2017 2:22 am    Post subject: Reply with quote

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
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Wed Apr 26, 2017 5:02 am    Post subject: Reply with quote

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
View user's profile Send private message
irenicus09
Tux's lil' helper
Tux's lil' helper


Joined: 07 Jun 2013
Posts: 118

PostPosted: Wed Apr 26, 2017 3:47 pm    Post subject: Reply with quote

@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! :P
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
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