New feature (possibly service?) for 4.0 (security related)

[Wolfie]

With the recent rash of hackings and with the fact that peoples sites get compromised on a regular basis (not the fault of IPS), I was thinking that it would be a great help if a feature were built in that would perform a scan of all the files starting at a specified location. Default would be the root folder that the software is installed at, but could be made to go up levels, so if the software isn't the root of the site, it could be pointed to it.

Anyways, when scanning the files, certain changes would be made to the files (see below) and an md5 hash generated for that file. Here is where it would be better as a service but there could be ways to make it work without it being a service. Once a certain number of files are hashed, send the results to an IPS server which would then compare the hash values received to known good hash values as well as known bad values (files known to be malware/etc). Anything left over would get sorted out to know if it's an altered version of an IPS file (like if someone modifies a core file for customization). For each client, a list of custom hashes would be kept. After all is done, an email would be sent out notifying the admin of any bad files found as well as a report of edited files. If there are no bad files and no edited files, no report unless the admin wants to receive a daily email anyway.

Now before people go getting paranoid about "big brother" and such, only hash values (and the file names/locations) would be sent. The reason for keeping a copy of custom hashes/files would be strictly for knowing if a file has been modified or not. Old or 'stale' hash values would expire after a weeks worth of scans when the value hasn't been matched, so that as files are deleted or modified, they will clear out instead of building up non-stop.

Now here's where it gets interesting. I think it would also help if 3rd party application developers were able to use a tool that would generate a hash listing of files for versions of apps that they distributed, so that people who download and install those apps won't get bombarded with notifications of file changes when they do updates and such.

Now, obviously there are some folders and files that should be skipped (conf_global, constants, initdata) or not have their hash values stored (such as uploads, skin images, emoticons, cache folder, etc). The overall goal would be to only keep track of files that could be used to compromise a site and notify site admins of anything that they might need to investigate.

As for it not being a service, I imagine a file could be included with an app download that could be used for hash value comparisons, however that wouldn't be as reliable because a hacker could easily modify it. I know the same could be said about the connecting to a service, but I'm sure there are ways to safeguard against that happening or ways to know when it's been tampered with.

As a service, I see this being able to develop even further where any 'current' methods of attacking a site could have code sent to a site for content to look for to know if a site may have been compromised (again, reporting it directly to the site admin). For example, if malicious is found to be getting added into skin templates, the system could be told to look in the skins for certain code and if it's found, admin is notified with details so they can address it. Not only that but obsolete files (old IPB files no longer needed, etc) could be detected and included in a report so that an admin could remove those files.


Now as far as changes to files that I mentioned earlier, what I'm thinking is to replace all 'space' type characters with NULLs. Something along the lines of preg_replace( '#s+#', '', $content ) or something like it, so that when people upload IPS files to their servers, if any NL/CR conversion happens to take place, this should help generate the same hash values. I don't doubt that there are other ways to make sure that the contents are the same, but that one seems the simplest to me.


For the scans, I'm thinking that there could be a set maximum number of files to do in a single run, so maybe one execution would generate a list of files and perhaps send that to IPS. A check on that file could be done to make sure no 'suspicious' files, for example the 'df.php' file found in the cache folder from recent attacks. Then on subsequent runs, the site would pull the file back, process a chunk of files from the list, send in those hash values and the list would be reduced so that the same files aren't hashed twice. Would also be to prevent malicious code from trying to 'remove itself' from the list of files to be scanned. Yes, again, I know that the 'scanner' could be compromised and generate unreliable results or whatever, but there are bound to be ways to protect against that.


Okay so yeah, there's the idea. Now to wait for someone to IM me to jump my case... In the meantime, I hope others like this idea and that it's somehow not an impossible thing to implement. As a mention, it wouldn't need to be a replacement for server anti-virus software. It would be more for checking the integrity of files and for things that happen to be affecting a number of sites, not for every little instance of a hack discovered. (I again refer to the df.php file as an example.) So for the most part, updates for extra content to check should remain minimal, with the bulk being hash checks and reports.

[Marcher Technologies]

Now, obviously there are some folders and files that should be skipped (conf_global, constants, initdata) or not have their hash values stored (such as uploads, skin images, emoticons, cache folder, etc). The overall goal would be to only keep track of files that could be used to compromise a site and notify site admins of anything that they might need to investigate.

Does not compute, some of the most likely files/folders to be targeted you name here(obviously the first 3 files should not be writable anyway, but the rest you list as no-store have to be). :hmm:

[Wolfie]

Does not compute, some of the most likely files/folders to be targeted you name here(obviously the first 3 files should not be writable anyway, but the rest you list as no-store have to be). :hmm:

The hash values would never match anything. Although for keeping a history to detect changes, yeah I guess those three should be included. I was keeping in mind that there are going to be files that you don't want to add to the list of things to track because someone uploading a new profile photo would generate an unnecessary report. Template edits, new emoticons, etc. Still compare against hashes of known malicious files, but not keep a record of the hash. (Well maybe template and language files, but you get what I'm aiming at.)