Add option to use unaltered hashes with Windows syscheck

[denied39]

I use OSSEC in a mostly Windows environment and find it difficult to trace back files using MD5 hashes. I know that OSSEC concatenates the MD5 and SHA1 hashes, but it seems to do that only with Windows agents. The Linux agents in use produce the correct MD5 hashes which can be verified using third-party tools.

Having the OSSEC Windows agent produce the same verifiable MD5/SHA1 hashes would enhance the forensic capabilities by allowing for a quick lookup of a file hash in a database or via the internet. Plus, it would eliminate the need to pull the same data twice from a computer.

Regards,
Mike

[jrossi]

Sorry for taking so long to respond. This is not how something should be working. Could you supply some details and example of where you are seeing this problem? Please also include the windows agent you are dealing with.

[denied39]

No problem.
Here is an example from a Windows 7 SP1 64-bit machine running the OSSEC 2.7 agent.

First the OSSEC Syscheck entry for c:\windows\system32\svchost.exe

Here's the same file scanned using md5deep64:

And finally, here's the same file scanned using powershell v4 get-filehash:

You can see that the two hashes are different, but the ones done with third-party tools match. We are seeing this across all of our Windows agents. Let me know if you need any more detail.

[mstarks01]

Do you see the correct hashes in the alert? I think the idea was to hash one over the other or something like that in order to have some additional assurance over collision attacks. But the original alert should have two hashes.

[denied39]

Just to clarify, do you mean the initial alert sent from the first time a syscheck is run?

We use AlienVault's OSSIM as our log server, so I'm trying to decipher the alerts.log file. The following entries were taken from a different machine than the previous screenshots and it's running OSSEC v2.7.1:

First, the md5deep hash of the file:

Now, the OSSEC syscheck entry (I'm guessing this is the initial scan of the file):
#++76152:0:0:0:355f4fb9aa95d894fd95ba2f0c63b756:5384dcaf9f9c86403d47ebc322337a0899144bb9 !1392315640 C:./Program Files (x86)/Adobe/Reader 10.0/Reader/wow_helper.exe

Now the generated alert.log entry (again, I'm hoping this is the correct one):
AV - Alert - "1392624724" --> RID: "550"; RL: "7"; RG: "ossec,syscheck,"; RC: "Integrity checksum changed."; USER: "None"; SRCIP: "None"; HOSTNAME: "(computer) 10.1.1.50->syscheck"; LOCATION: "(computer) 10.1.1.50->syscheck"; EVENT: "[INIT]Integrity checksum changed for: 'C:./Program Files (x86)/Adobe/Reader 10.0/Reader/wow_helper.exe'\nOld md5sum was: '355f4fb9aa95d894fd95ba2f0c63b756'\nNew md5sum is : 'cdfe019f5667029fe68fd1371c0685c0'\nOld sha1sum was: '5384dcaf9f9c86403d47ebc322337a0899144bb9'\nNew sha1sum is : '8a4c6ebdb1b0421aa96b008c21c3680315bc05c5'\n[END]";

And finally, the next scan of the file with OSSEC showing a change:
!++76152:0:0:0:cdfe019f5667029fe68fd1371c0685c0:8a4c6ebdb1b0421aa96b008c21c3680315bc05c5 !1392624724 C:./Program Files (x86)/Adobe/Reader 10.0/Reader/wow_helper.exe

Let me know if I am missing something. Thanks.

[johnluko]

Is there any update on this issue? We are experiencing the same problem.

[santiago-bassett]

As reported in the mailing list this is still a problem. We will try to fix it and submit a pull request

[vikman90]

Windows doesn't appear to change intencionally the hash, but I found that OSSEC opens the files in text mode, and they should be opened in binary mode to work properly. I fixed this problem and sent the pull request, hoping that this solves the issue.

ossec_md5 uses the current implementation, while ossec_md5_bin is the fixed version, whose result matches the hash produced by Windows PowerShell.

[mschilt]

Can this bug be closed since the fix was merged?