#30640 – FEATURE for FileScan

Posted in ‘Akeeba Admin Tools for Joomla!’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Wednesday, 05 December 2018 08:57 CST
Hi Nick,
while checking the FileScan on my clients site I noticed the filescanner output and the option it gives me which aren’t as good as they could be.

I’m also doin‘ Wordpress-Sites and I’m very impressed how Wordfence handles the filescanning process. Mainly it’s this…

Checks against own database
They keep a database of the Core and manymany plugins original files and compare these „clean“ versions in their repository against the ones on-site.

I read that you recommend the same method on
https://www.akeebabackup.com/documentation/admin-tools/php-file-scanner-reports.html
but only manually, which is quite a task.

Diff
They only display the differing parts on a details page not the whole file which is quite handy.

Marking Files as safe
Another thing they are doin‘ well is to give the user multiple options on how to handle suspicious files. For details see here https://www.wordfence.com/help/scan/#working-with-scan-results

Do you see any chance to implement those things into AdminTools? That’ll be great improvement I'd think :-)

Best regards,
Ralf
Custom Fields
Joomla! version (in x.y.z format) 3.9.1
PHP version (in x.y.z format) 7.2.x
Admin Tools version (x.y.z format) 5.2.x
RRO
Wednesday, 05 December 2018 09:32 CST
This is not going to be implemented and for a good reason.

For starters, this requires creating per-line hashes for every single file of every single version of every single plugin. I say per line because a file can be uploaded with different line endings if you use FTP on Windows (or you're using Git to work on your site on Windows).

Then you have to ship all these hashes with Admin Tools. We're talking about several Gigabytes. This is impractical. It's also daft because if your site gets hacked the attacker can very easily modify a couple of hashes that affect him and you'll never notice because they are lost in a sea of hashes which needs to be updated dozens of times per day.

In practical terms this means that the scanner needs to be a service, not software running on your site. The whole point of Admin Tools is that it's not a service. If you want a service there are plenty, they have funding, we can't compete with them. I know that myJoomla.com is about to go into WordPress and they have a more robust platform than WordFence. I know what they do, I know what it'd take to compete with them, I know it'd make no sense for us to do that. Cool features are not very cool when they require a capital expense twice as much as the company's assets and carry an 80% risk of failure. It's a bet I am not willing to take.

Even if that was not a problem, we'd have two major problems. One, "vetted" files are actually not safe. We assume they are safe because they are on the WordPress Plugin Directory. As we already know, the Directory does not proactively stop malware. So we'd just be lulling you into a fake sense of security. Manually vetting every file requires several thousand human developers on staff which is, of course, impractical. In my opinion this fake sense of security alone is the show stopper for this feature. Telling you a file is safe when it's definitely not just because someone uploaded it in an unvetted repository is insane.

The second major problem is that this approach only covers free of charge plugins on the directory. What about premium versions and plugins not on the directory? Trying to trawl the web and purchase them just to include them in an index is a massively complicated and expensive operation. In fact, it would not be practical at all. We did the same analysis with Joomla! where at lest discovery was much easier as over 90% of the extensions, free or paid, were listed on the Joomla! Extensions Directory. WordPress doesn't even have that.

So how do scanning services provide defaults for safe files? Well, it's a popularity contest. If the same file is present with the same size and content hashes in the same location of many sites and passes an automatic inspection (or a manual inspection, in case it seems fishy) it is marked as safe automatically. That still has the same problem with underhanded popular extensions bought out and backdoored by sneaky attackers. Some will be caught, some will not. It's better than nothing but I'm not convinced it's a safe approach I'd like to follow on my site.

Also, this is missing the point. We have written a PHP file change scanner. The whole point is answering the question "have my files changed without me expecting it to happen". If the answer is "yes", you are hacked. If the answer is "no" we do a secondary analysis of code patterns to draw your attention towards files which might be problematic. That secondary analysis only makes sense either on an existing site OR to have a human developer identify the interesting files in a new and untested plugin which you don't necessarily trust.

Finally, regarding diff, there is an option to show only the changes in DIFF format. I wrote that about five years ago. I believe we have ported it to the WordPress version as well. It's usually good enough for a quick scan but most people don't understand it. It also requires basically storing every .php file in the database. That's why it's disabled by default.


Nicholas K. Dionysopoulos

Lead Developer and Director



Greek: native

English: excellent

French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



nicholas
Friday, 04 January 2019 17:17 CST
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.
system
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!

Cookies Notification - Action required

This website uses cookies to provide user authentication and improve your user experience. Please indicate whether you consent to our site placing these cookies on your device. You can change your preference later, from the controls which will be made available to you at the bottom of every page of our site.