When reviewing file integrity changes with Change Tracker, you’ll have undoubtedly noticed the hash value within the events.
The below event, the result of Internet Explorer patching, updated ieproxy.dll and generating a new hash value - 9D4B1B9C267F7E3435A0A2556D9722741FA8AD91.
To understand where the hash value comes from, we have to look at the Change Tracker templates. All out-of-the-box templates provided by Change Tracker have the hashing function enabled and offer a selection of cryptographic functions ranging from MD5 to SHA512, so as soon as a host registered, the hashing begins!
(Note: See section regarding SHAttered and why SHA1 as a file integrity measure has its days numbered)
As we’ve seen from the ieproxy.dll change, the hash value is used as a method to verify a file’s integrity. Change Tracker uses the content of a file and the cryptographic function selected in the template to calculate a unique hexadecimal number for each file. If the file remains the same, then so will the hash value but, should the file contents change the calculated hash value will differ. Remember that Change Tracker is always watching and as with ieproxy.dll, a change to a hash value results in an alert event.
Possibly the most important aspect of hashing is this, the hash value of a specific file, whether calculated by NNT or another hash creating application, will always be the same when the same cryptographic function is used. As Change Tracker users we can leverage this when faced with the inevitable file investigation by taking our hashes to online resources such as VirusTotal.
VirusTotal describes itself as:
‘ an information aggregator. The aggregated data is the output of different antivirus engines, website scanners, file and URL analysis tools and user contributions.’
So lots of feeds, pulled into one location constantly analyzing file for authenticity and crucially for us, creating hash values! We can, therefore, take our Change Tracker hashes, input them it into VirusTotal and review any data about associated matches.
The below is the VirusTotal output for the ieproxy.dll file. Thankfully the information reported by Change Tracker matches what VirusTotal has on record!
SHAttered: Why SHA1 will soon become a discredited File Integrity hashing algorithm
As detailed at https://shattered.io/, researchers have now proven that a SHA1 'collision' can be created for two legible PDF documents. A collision in hashing terms is where two different files, with different contents can be crafted in order to generate the same hash value. So the very reason for generating a hash value ie. to provide a unique measure for a file, has now been undermined as far as SHA1 is concerned.
The shattered.io project describes how the research was conducted - it required enormous computing power and time in order to generate sufficient iterations of the second file so that one would eventually provide a SHA1 collision.
The implications of the work are that a trojan could be developed that would evade SHA1-based file integrity checks - a scary prospect.
Shattered Project demonstrates how two different files CAN have the same SHA1 hash value
NNT have always provided the option of using stronger hashing algorithms other than SHA1 and MD5 but our strong recommendation now is to use SHA256, with SHA384 or SHA512 available beyond this. The downside is of course that more computing resources will be needed to hash files, but the game is now officially up for SHA1.