File integrity on Mac OS X

Recently the US-CERT released a documented titled “Security Recommendations to Prevent Cyber Intrusions“, which seems to add quite a few measurements to another US official document, but this time in more technical terms. I don’t live in the US, but having a set of recommendations to prevent intrusions on a computer that are originally intended for government purposes, does make me wonder if I could borrow any of them in order to make my computer environment more secure.

The first and apparently most important recommendation is to use a Host Intrusion Detection System. SANS provides a very broad and descriptive definition for that term and also points to some great software. Although I will not do any reviews of those, I’d like to point out something they all have in common: File integrity checks.

What “file integrity checking” basically does is periodically run a program or agent that checks if files on your computer were altered, regardless of the reason why or who did it. File integrity checking by itself does not prevent an intrusion, but it could warn you if someone is poking around on your computer, as they are likely to leave traces of their presence. If they do leave traces, you could be alerted if anything was changed. Depending on how often you would scan for changes, you’d still have to assess if the changes made were made by you and were intended or not. You could argue that if you were to keep strict versions of each file, then file integrity checking would very likely be unnecessary. Some file systems work in such a way that allows them to do just that, although there are still ways to circumvent any form of detection that is started on the host that is under surveillance. Despite the shortcomings of file integrity checks, the US-CERT recommends Host Intrusion Detection which suggests that most hackers aren’t that clever or do not care very much for keeping out of sight. If that were true you could assume that file integrity checking does work as a measurement to detect intrusions and allow you to take action to prevent further damage. Or at least save time in assessing the impact of the damage that was done.

File integrity checking is not new. Tripwire is probably the most widely known tool for that and there are a lot more like them. Mtree is such a tool hat was included in 4.3BSD-Reno, released in 1990. Mac OS X being derived from BSD/Unix also has it installed. With mtree you can scan if a file was altered quite easily. Below is a small Unix shell script that does that.

#!/bin/sh

SCRIPT="`basename $0 | sed 's/\..*$//'`"

CONFIG=${1:-$HOME/.$SCRIPT}
DIR=${2:-$HOME/Documents}

cd $DIR || \
       { echo "Failed to change working directory to $DIR" >&2; exit 1; }

if [ -f $CONFIG ]; then
       /usr/sbin/mtree -f $CONFIG
fi

/usr/sbin/mtree -c -k time,md5digest,ripemd160digest > $CONFIG

How does this work? Save this file as “filescan.sh” and make it executable by using “chmod 755 filescan.sh”. It can take two parameters: the first is the name of the configuration file and the second is the name of the directory you wish to scan. If there is no earlier configuration, the script will create one for you automatically. Next time the script is run, it will use this configuration to determine if any changes occurred in between. This is an Achilles’ heel, more about that later. To use it to guard the integrity of the files in your Documents directory, you would type (in Terminal.app):

chmod 755 filescan.sh
./filescan.sh ~/filescan.mtree ~/Documents

Depending on your files, filescan-documents.mtree looks somewhat like this:

/set type=file
.               type=dir time=1312400030.0
    filescan.sh time=1312400080.0 md5digest=c14927148b8950448c511fad48cd3703 \
                ripemd160digest=ecbaf94ddf18995166a526cfd906d26db64115c9
..

Next time you run filescan.sh with the same parameters as you did on its first run, any differences would be displayed. So if you would have a directory with only filescan.sh in it, adding a blank line to it would be noticed:

mkdir ~/bin
cp filescan.sh ~/bin
cd ~/bin
chmod 755 filescan.sh
./filescan.sh ~/TEST.txt ~/bin
echo "" >> filescan.sh
./filescan.sh ~/TEST.txt ~/bin
filescan.sh changed
    modification time expected Wed Aug  3 21:33:50 2011 found Wed Aug  3 21:34:40 2011
    MD5 expected f7bba5bad20101755c3fa4804d7a56ce found c14927148b8950448c511fad48cd3703
    RIPEMD160 expected 3550b1ee76919154a8b357a014b2f2bfb8553d2b found ecbaf94ddf18995166a526cfd906d26db64115c9

So there it is: Simple file integrity checks!

Epilogue

File integrity checking is only useful if you regularly scan for modifications and keep up to date with any file changes. The amount of changes will otherwise soon become an overwhelming pile and intrusion detection will be like searching for a needle in a haystack. Cron is a nice tool to help you with that:

crontab -e
0  */4  *  *  *  ~/bin/filescan.sh 2>&1
[[Hit 'esc' and type :wq followed by enter to save and exit]]

Next time you start terminal.app and if there have been changes to files, then you will be greeted with something like:

Last login: Tue Aug  2 05:31:04 on ttys001
You have mail.

Indicating that you should type ‘mail’ 😉

Some final remarks:

First and foremost: if a hacker finds the configuration file, then you should assume that all is lost, as there is no valid point of reference for files to be compared with. The hacker could update your configuration file between checks and you would never see the modification. Storing your configuration file off-site would make things more secure, but more difficult to use.

Second: mtree is not the best or a very feature-full file integrity checker and is limited to changes to files and not file system. It will not check for creation or access times of a file or directory, it will only check modification time. There is another command for that, which could be added to a shellscript just like this, but that is beyond the scope of this article. There are plenty free host-based intrusion detection tools available that can address these all at once, but still require a lot of attention and aren’t fool-proof by design.

Last: Running mtree as described here makes quite an impact on the performance of your computersystem. Less bytes to check means better performance. Filescan.sh uses md5 and ripemd160 which could be reduced to just one.

 

This entry was posted in IT Security and tagged , . Bookmark the permalink.