Magento-lts: check core file integrity for additional security

[ioweb-gr]

Description (*)

I'd like to discuss the possibility of adding a security related feature for OpenMage. Generally it's very good to have a log of file modifications to backtrace malicious activity and detect hacks early.

Expected behavior (*)

The idea is that with each release of OpenMage, a hashlist of all the core files is created. Then we also provide a shell tool to verify the current installation against the core hashes. This would effectively list all unauthorized modifications of the core.
The script can run on a daily basis via cron job and should any discrepancies be found, we can choose a course of action. For example we can add a notification to the dashboard or email the results to the administrator. Even the raw output of the script could be used by any control panel to send the email to the admins.

Benefits

The benefit is that in a case of malicious code injection we can quickly check the core and see if it has been tampered with and maintain a log of when it happened and in what sequence.

Additional information

In the future we could even provide an interface in the backend to take snapshots of the current installation to check third party code and use this hashlist for the verification. Similar to what wordfence does in wordpress.

[colinmollenhour]

While this is a great idea, I think it already exists.. git diff and git reset --hard HEAD 😄

[ioweb-gr]

True story, but not everyone is deploying via Git. Git would add a significant overhead in resource utilization in some cloud systems as it can grow quite big over time. Plus I feel it would be useful only for developers. It can't be extended to present this data to the eshop admin conveniently in the future. Can it? 😮😳

I've seen lots of installations on environments without SSH access even

[colinmollenhour]

Git is an incredibly efficient tool and can be installed anywhere.. Even if it wasn't used in development, a fresh repo could be created as the last step of deployment:

git init && git add . && git commit -m "One and only commit"

Then use a cron job to detect changed files with git diff and reset changes with git reset --hard HEAD. Even if it was done every 60 seconds I don't think it would cause a detectable increase in load. I'm sure I couldn't build a tool that maintains hashes of thousands of files and can detect and revert changes so easily and so quickly as git can, unless perhaps the tool I built was just a wrapper for git, and then I could do it in about 5 minutes.

I hope I'm not coming across as snarky, but honestly git can easily do this so unless there is already some other purpose built tool to do what you are describing I wouldn't try to do it any other way.

[ioweb-gr]

That's ok don't worry it's why we're discussing it here. Assuming we use git

1. The comparison is happening based on an online repo which is cloned on the production server, correct?
   That means if we only monitor the codebase a minimum of 2x the codebase size is needed in space. A few years later this can easily become 20x the original codebase size due to historical data maintained by git and the various branches.

So for a codebase of 100mb we should calculate 2gb of extra data in disk space needed which will probably increase over time. That's additional cost for the eshop which is a con in my opinion.

1. To execute git, you can't be in shared hosting unless you run with the big / more expensive providers like a2 hosting which is developer friendly. Most companies will use plain chroot for ssh with a very small subset of commands which are the least exploitable for privilege escalation. I know major players plesk and cpanel in chrooted shell don't allow it. To be more exact you put so much stuff in the jail that you compromise it to make it work. If you need more than jailed shell they always suggest vps. That's also additional cost for the eshop and a con

2. In order to get a meaningful result that's readable in a daily scan we'd have to exclude cache / tmp / session folders because it will flood you too much. In a severe case where the site is compromised and shelled in the tmp folder, with git available couldn't the attacker just issue a new commit to bypass the git status check?

3. Git speed is awesome I agree and that's a pro.

4. Touching a file, changing permissions and delete/recreate the same file will trigger a false positive with git. E.g. Running a plesk repair fs on all domains to repair file permissions. Lots of users upload files with bad permissions and occasionally the hosting provider may reset them to sane defaults in managed hosting.

5. Running find . -mtime or -mmin is faster than git and can give you a list of modified files much faster without any additional space needed but suffers from false positives too.

On the other hand an integrity check based on an official hashlist and a php script

1. will not have false positives, or at least have extremely low possibilities of collisions. (Pro)
2. Will monitor only the core (con)
3. Will not be compromised because the site is compromised (pro). You can ask the hosting provider to make the integrity check file immutable to guarantee it's never compromised

[Flyingmana]

One of the expert solutions would probably be something like https://osquery.readthedocs.io/en/stable/deployment/file-integrity-monitoring/

For a simpler variant in the chat was initially this mentioned:
https://github.com/magesec/projectintegrity
Which would/will only work for the core and not for extensions and custom code.

Git is not as reliable here, as the .git part is prone to manipulations and it may even be used to persist a manipulation over some of the git hooks and by changing references/remotes so the check does not show any differences.

[colinmollenhour]

I think we just have vastly different deployment strategies. :)

Perhaps a strategy or two for file integrity monitoring would make for a good blog post?