Support

Admin Tools

#26129 Admin Tools PHP File Scanner

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by samw on Thursday, 15 September 2016 16:08 CDT

samw
Hello,

This is a little bit of a laundry list of questions about the PHP File Scanner, and it's low priority - nothing is wrong, I think. I'm just trying to understand things and be careful.

I've read the manual and installed and configured Admin Tools 4.0.1. I apologize if the questions are tedious and perhaps, in some cases, downright foolish.

1. When I ran my first scan the PHP File Scanner reported 5,141 total files, but only 5,140 new files. Per the documentation, I was expecting the same number of total and new files on the first scan. Is this any cause for concern?

2. This first scan spotted 27 potential threats, none with a threat score over 15. This is a largely fresh install of Joomla! (it has Akeeba Backup Pro, Akeeba Ticket System Core, and the OS Solutions subscription component "Membership Pro" installed). It's in a subdirectory where it's never been exposed to the public.

Is it highly probable that it's OK to mark these files as safe without checking individual files against a completely fresh Joomla! install, as described in the documentation?

3. It seems pretty clear, but just to be sure ... when reviewing individual suspicious files, it looks like the items causing nonzero threat scores are highlighted in yellow - is that correct?

4. It looks like many of the flagged files (including some Akeeba files) are flagged on account of the presence of 'REMOTE_ADDR'. What is REMOTE_ADDR, and is there a rule-of-thumb way to know when it's a problem and when it's not?

I have a similar question regarding "curl_exec" and "base64_decode."

5. After the first scan, I marked one file safe and ran another scan. After that second scan, there are only 26 suspicious files, as expected, but they all still say they are "modified". I didn't modify them since the first scan - do they retain the "modified" status through subsequent scans until marked as safe? Or is this a cause for concern?

6. The biggest threat score (15), and a couple of other nonzero threat scores, were associated with files in /libraries/omnipay/vendor/symfony - Is that a common false positive?

7. I saw in the documentation that the directories tmp, cache, administrator/cache, and log are not included in the scan, and the note that these "neither of those directories is supposed to be directly accessible over the web – and that's why Joomla! allows you to relocate them to off-site locations." Does that mean that the permissions of these directories and their files should be tighter than 755 / 644, or that they should be outside the site root?

8. I set up an email address for emails from PHP File Scan after a scan runs, but I'm not getting any such emails, either for manual scans or when run by chron job. "Diff" is disabled. Do you only get these emails when doing DIFF? (fyi ... a similar email feature in Akeeba Backup that emails when you run a backup is working fine).

9. What does "purge file cache" do in the context of the PHP File Scanner, and is that something I should just do periodically? I didn't see this in the documentation.

Thanks again for your help.

nicholas
Akeeba Staff
Manager
1. Not really. A fluctuation of the files is normal if you have extensions which write .php files to your site to store private data which must not be web accessible (they put a die statement in the top of the .php file to achieve that) or even some templates which use .php files to deliver combined and/or GZipped (compressed) CSS and JS files.

2. I can rephrase your question as "Do you feel lucky?". If you feel lucky, sure, go ahead and blindly mark those files are safe. If you want to be absolutely sure those files are safe you'd better check them against a fresh local installation which is guaranteed not to be hacked OR check these files manually if you are a developer. Since you're not a developer the documentation suggestion should work best for you.

3. Correct. It helps developers manually inspect suspicious files.

4. I am not here to teach PHP development. It suffices to say that none of them on its own right is malicious. If there were purely malicious PHP functions it stands to reason that they would have been removed from the language. Like with any language (programing or even human) you can combine otherwise innocuous constructs to inflict damage. The threat score merely gives a ballpark estimate of the concentration of constructs which are typically used in malicious code (but NOT ONLY in malicious code!).

Think about having a library of thousands of books and you're tasked to ferret out the ones that incite racial hatred. Going through all of these books one by one would take you more than a lifetime. You can, however, make a weighted criteria matrix for each of the books, correlating possibly troubling words (like the n-word, "race" and its derivatives, "inferior" etc) with a weight factor and number of occurances. The sum of all the weight times number of occurances products would give you a Threat Score. Most of the books would have a zero –or near zero– score, making them unlikely to be inciting racial hatred. Those with a high score are the ones you need to read – or ask your colleagues from other libraries whether they are safe or not. In fact, it could work on books written in languages you don't speak, as long as someone provided the weighted matrix criteria for you. And since you don't speak the language you'd just have to list the suspect books and ask around if they are safe.

Sounds familiar? That's exactly what the Threat Score does. The entire point is that you don't speak PHP, you don't need to speak PHP and I can provide you with the weighed matrix. In the end of the day I give you a small list of files to check which you can check against a predictably safe, easy to obtain source. If you want to delve deeper you will need to learn how to speak PHP but that's way beyond the scope of support.

5. Yes, files with a non-zero threat score retain their status and get reported again and again. Otherwise you'd miss them: normall files which are neither modified or new don't get reported, at all.

6. I cannot answer that question. See #2 and #4 about what you should be doing.

7. No, changing the permissions of folders WILL NOT help with being web accessible in most cases. Please take a look at the .htaccess Maker. It actually blocks web access very efficiently at the Apache (web server) level. That's before PHP even has the chance to load, let alone run. Or put a .htaccess file whcih prevents web access inside each one of these directories.

8. Manual scans never email you. CRON scans should be emailing you. Which CRON method do you use, the admintools-filescanner.php script or the front-end scheduling URL? Actually, please file a different ticket for this issue to make it easier to manage :)

9. Basically this is a "don't press that button unless I tell you so" kind of thing.

The PHP File Change Scanner keeps a database table with the paths to each scanned file, its size, modification date/time stamp, MD5 checksum and SHA-1 checksum. If you have enabled the diff feature it also keeps a copy of the contents of the file so we can produce a diff on the next run. This is how it "remembers" files between runs and knows if a file has been added or modified between this and the previous run of the file scanner.

If you deliberately make large changes to your site (like unhacking a site) or you've blindly marked as safe more files than you really should have you may want to purge that database table and start the file scanning afresh. Same goes in the very rare case something is stuck and we need you to purge that table (very, very, very, VERY rare issue). Typically we'd tell you to go to the database management tool (e.g. phpMyAdmin) and do that but it's not very user-friendly. So we added a button. It's not documented because you're not really supposed to press that unless we tell you. You must definitely NOT do that periodically.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

samw
Nicholas,

1. OK, thanks.
2. I will go ahead and check the files then.
3. Thanks for confirming.
4. Yeah, fair enough, I suppose you could drown in questions like that. I will follow the documentation procedure or do my own PHP research/learning (or both).
5. OK, thanks.
6. Yep, got it.
7. I understand now, have already applied .htaccess maker.
8. I will file another ticket re this, but briefly, I'm using admintools-filescanner.php.
9. I am glad I asked. If I may suggest, you might want to add that "don't press that button" comment to the documentation.

Thanks for your help. I will mark this one closed.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

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!