Comments

MustangGB created an issue. See original summary.

mustanggb’s picture

StatusFileSize
new9.9 KB

This is the patch I'm using on 7.x-2.0-beta5, it adds support for files that have been added to project, but ignores *.patch files, so needed to add regex support to hacked_file_scan_directory() as well.

mustanggb’s picture

StatusFileSize
new9.91 KB

Whoops, spotted a typo in default $nomask parameter.

EDIT: Sorry about the unnecessary chmod's.

mustanggb’s picture

Status: Active » Needs review
StatusFileSize
new9.99 KB

An untested reroll against dev.

hockey2112’s picture

I tested the patch in #4 against the current dev, and I have a few comments/questions...

  1. When I run the Hacked report or view a result, it throws this error message:

    Notice: Constant HACKED_STATUS_DELETED already defined in include_once() (line 18 of /home/ruffsack/public_html/sites/all/modules/hacked/hacked.module).

  2. When you view a result, it shows "Created" files as "Deleted" in the column on the right.
  3. It did find a test.php file that I added to the Webform module directory, so that is working quite nicely.
  4. It also reported several "files created" for benign files that are part of contrib modules. For example, it told me that the Ubercart contrib folder contained "9 files created". I compared the Ubercart installation files to a fresh download of the module, and it appears that Ubercart adds files to its installation folder, perhaps when you activate certain features. For example, I have a file called shipping/uc_ups/uc_ups.css that doesn't exist in a fresh download of UC. It is simply CSS code to style the UPS options at checkout. Not sure how that could be handled/ignored. Perhaps there simply needs to be some due diligence by the webmaster to take note of which modules contain those kinds of files.

    Another example is the Entity API module. Hacked reports this file, which is benign: "views/error_log" (no extension on the file)

  5. It reports that Drupal core has "9502 files created", so it is counting the fils/ dir, the contrib modules, etc. Again, not sure of a way to avoid that, but it makes it difficult or even impossible to find backdoors in Drupal core.

Thanks!

mustanggb’s picture

1+2. Yea I just looked at the patch again myself, seems like it wasn't formed correctly, should be a pretty easy fix.

3. Yea for me this was really the main use-case, to aid with detection of custom tweaks to contrib modules.

4. Not sure what to do about these sort of things either, perhaps suggest the offending modules don't do it, haven't run into this issue yet myself though.

5. I think this is the main big task that'll need to be tackled for this feature, but for me it's not so important because I don't hack core and run a web server config that blocks access to a lot of stuff, and regular core updates take care of the rest of my concerns, it also makes it incredibly slow to run a scan on large sites, so on my version I've just disabled core scanning for new files, someone else can take the reins on this one.

hockey2112’s picture

How would I disable scanning of core files. You are right that regular updates will eliminate any new files in the core folder structure...

mustanggb’s picture

Assigned: Unassigned » mustanggb
Status: Needs review » Needs work

I'll do a new patch tomorrow if I remember, also setting write permissions correctly helps eliminate backdoor injections.

hockey2112’s picture

Sounds good, thanks!

mustanggb’s picture

Assigned: mustanggb » Unassigned
Status: Needs work » Needs review
StatusFileSize
new10.31 KB

Untested dev roll with #5-1+2 & #7.

hockey2112’s picture

Had a moment to try the new patch today. 1 and 2 are resolved.

RE: #5, it shows Drupal core in red with "Changed!" and says "0 files changed, 0 files deleted".

Thanks!

hockey2112’s picture

I've been rolling out the patched version on several sites, and have been encountering this error while running the Hacked report on quite a few of them:

An AJAX HTTP request terminated abnormally. Debugging information follows. Path: /batch?id=35&op=do StatusText: error ResponseText: ReadyState: 0

Is this a memory issue on the server? Or something else?

zmove’s picture

Status: Needs review » Reviewed & tested by the community

Essential patch that works well.

It could provide an useful option : the possibility to ignore the public file directory cause if you have a lot of media, the system will detect a lot of changes.

zmove’s picture

Status: Reviewed & tested by the community » Needs work

I put it as reviewer too quickly, it seems that with this patch, drupal consider every contributed module as added files. It should ignore it.

mustanggb’s picture

StatusFileSize
new15.73 KB

Latest code re-rolled against dev, haven't looking into any of the feedback, however it does now distinguish between hacked and patched code.

generalredneck’s picture

mustanggb’s picture

StatusFileSize
new16.62 KB
mustanggb’s picture

StatusFileSize
new16.55 KB
mustanggb’s picture

StatusFileSize
new15.61 KB
mustanggb’s picture

Status: Needs work » Needs review
gngn’s picture

I am using #19 with 7.x-2.0-beta8 and can confirm that it finds added files.

ivnish’s picture

Status: Needs review » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.