Monitoring File Changes
In many environments it is important to be alerted when certain files are modified. For example you may wish to be notified if access to the root account has changed, potentially granting high level access to an account that should not receive it. The most obvious parameters to monitor for file changes is “file size” and “date/time stamp”. If these parameters change, you know the file has been modified. The problem is skilled attackers know how to tweak these values so their changes go undetected. So what we need is a reliable method for detecting file changes that cannot be easily fooled.
Hashing is a process we can leverage to identify when a file has changed. A hash algorithm is simply a math formula. It can take the contents of a file, perform some computations, and then output to a fixed length string of characters. The length of the output string is determined by which hash algorithm you are using. What is important however is that regardless of the size of the file you are inputting, the output length will always be the same. Thus is useful as we can always count on the hash being a specific size even if we are hashing files of different length.
Another important aspect of hashing is that it is very sensitive to change. Even if I merely add a space character to a file or change the capitalization of a single letter, the resulting hash is going to change dramatically. This means that if an attacker makes any changes to the file at all, a comparison of the hash before and after the change will detect the modification.
Let’s look at a few examples so you can see what I mean. We’ll be working with SHA-256, the same hashing algorithm used by Halo FIM. SHA-256 outputs a 256-bit hash we can use for comparison. The tool I will use is “sha256sum” which is a stock Linux tool on most distributions.
First, let’s start by creating a simple file:
$ echo This is a test file. It is only a test. > test-file.txt
Now let’s let sha256sum process the file to generate a hash:
$ sha256sum test-file.txt 7e6ca124362a1cd9a4af371f87eb77209c6673d0ba05ba6d64cb7ce7704b8a91 test-file.txt
We would now store this hash value to use for later comparison. If processing “text-file.txt” using SHA-256 produces the same hash value, we know the file has not changed. If it is different, we know we have a problem.
Next I’m going to edit the file to make a minor change. I will change the “I” in “It” to be a lowercase character. I’ll then run the file back through sha256sum to see if a different hash value is created:
$ vi test-file.txt $ cat test-file.txt This is a test file. it is only a test. $ sha256sum test-file.txt 14f7e5845f66e18d0cf23e4caa7926f6430320937a783b88f03a959b110744be test-file.txt
Note the resulting hash is dramatically different. So even a minor change (capitalization change of a single character) will result in a very different hash value. Let’s try this one more time. This time I’ll add a single space character between the “t” in “test” and the period:
$ sha256sum test-file.txt 14f7e5845f66e18d0cf23e4caa7926f6430320937a783b88f03a959b110744be test-file.txt $ vi test-file.txt $ cat test-file.txt This is a test file. it is only a test . $ sha256sum test-file.txt dd143c4dda4b7c3d9a63526d5cc4b9ab7756999b139bb8d9a78844be7d228f8a test-file.txt
Again, note the dramatic change in the hash value.
How Halo FIM Works
Halo FIM works in a similar fashion to what we were doing above. When you specify which files you want to protect with FIM, Halo goes out and generates a 256-bit hash of each of the files. Those hash values are then stored on the grid for later comparison. Halo will then go back at regular intervals to verify the hash value for each specified file has not changed. If it has, FIM will generate a security event which you can optionally choose to turn into an alert.
Like most security technologies, hashing has its limitations. To start, hashing can tell you a file has changed, but it cannot tell you what content within the file has changed. You’ll need to do a bit of investigation work with a backup copy of the file to figure that out. Also, hashing does not identify if the change actually poses a threat. For example say you hash a number of binaries and then later apply patches. Chances are the patches may include new versions of those binaries. So yes the binary has changed, but that’s actually a feature. It is up to you to determine which changes are due to normal patching and which are indications of a compromise.