• Resolved yosmc

    (@yosmc)


    …it is not a good idea to disable scanning image file types by default. For the issue I had, the malicious code was stored in an *.ico file and simply added as an include (I am assuming this is common practice).

    Also, it seems like the plugin doesn’t scan files starting with a . which is a similar problem.

    Other than that – thanks for providing this great plugin!

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Eli

    (@scheeeli)

    Actually the plugin does scan hidden files starting with “.” (a period), and it is ok to skip the ICO files because the malicious PHP code cannot be executed directly so it is only the include statements that call on the ICO files that are the real threat and my plugin found all those malicious includes, right?

    Also, you can of course remove ico from the list of file extensions to skip and it will find and remove this dormant code as well.

    Thread Starter yosmc

    (@yosmc)

    “Actually the plugin does scan hidden files starting with “.” (a period)”

    I can positively confirm that such a file was either not scanned or overlooked by your plugin.

    “it is ok to skip the ICO files because the malicious PHP code cannot be executed directly so it is only the include statements that call on the ICO files that are the real threat and my plugin found all those malicious includes, right?”

    That’s like the bomb squad saying, it’s ok to leave the bombs, we just went for the matches. Seriously?

    Fact is that the cleanup operation from last night was unsuccessful. So in the end, there were still bombs AND matches. Presumably, the original issue was fixed earlier, so this is about malicious code still remaining in the system.

    Plugin Author Eli

    (@scheeeli)

    First of all, if I’m the bomb squad, then removing the detonator is to make the site safe, but ICO files are binary images not bombs. If you call up any image file in your browser it will try to render a graphic and it will never, under any circumstance, execute the PHP code within that file. This is not like a bomb that might be set off accidentally by a random fire or a stray bullet. the PHP code in an image file can only be executed with an intentional and malicious addition of an include or require statement in a PHP file within your site. I’m not trying to be argumentative or even overly defensive, I really just want you to understand how non-threatening and harmless that ICO file really is.

    The important thing that I wanted to confirm is that my plugin was able to successfully remove the actual threat and this still seems to be in question, so I would like you to tell me more about what was missed. You said you can positively confirm that a file starting with a period was overlooked by my plugin: please do. I can tell you it was not ignored simply because it was hidden, but the threat inside may have been missed because it is new and not yet identified as a known threat. My plugin is not perfect and new threats are written every day. If you can send me this file that was not identified then I can add this threat to my definition update so that it can be automatically fixed.

    I think you might be happier with my plugin if you consider that it’s main goal is not to “clean up” the site but really just to “fix the malicious threats”. That said, if it was unsuccessful in any way I really want to know more about that. I work on my plugin almost every day and I want to make it better whenever I have the opportunity. If you are willing to work with me and give me the details I need then this could be one of those opportunities.

    You can also email me directly if you want to send me infected files and such:
    eli AT gotmls DOT net

    Thread Starter yosmc

    (@yosmc)

    Your plugin was of great help, because it identified 68 files that were infected with malicious code, and helped me see how serious the situation was. It missed two php files, however, which were designed to load and execute php code via an include, and it missed said .ico file which carried the payload.

    In my mind, if the plugin looked at all files by default, it would have a better chance of either eliminating all payloads or all detonators (catching either would have defused the situation). I don’t think many people realize that an image file carrying malicious php code can indeed be half the problem.

    In this case, the script didn’t find the .ico file even after I had activated all extensions, but it also got stuck several times and retried scanning. The furthest I got was 99%.

    Thanks for writing back – I’m sending over the files that weren’t identified.

    Plugin Author Eli

    (@scheeeli)

    Thanks for sending those files. I just wanted to post here that those threats were added to my definition updates and should be found and fix automatically now.

    Thanks for your feedback and help with identifying these files that were missed.

Viewing 5 replies - 1 through 5 (of 5 total)

The topic ‘Great, but…’ is closed to new replies.