#29245 – PHP file scan threat scores

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.
Monday, 19 February 2018 10:35 CST

after our latest update batch (19/02/2018) on few websites we maintain, I noticed that all of the sudden the threat score has changed.
Until this version of Admin Tools, now updated to 5.0.1, we didn't have a threat score bigger than 10, only when installing Admin tools and running PHP Scanner for the first time.

What I find even more interesting is that the new threat score system is indicating a lot of your PHP files with the score 50 and bigger.

For example:
  • administrator/components/com_admintools/engine/Util/Encrypt.php score 50

  • administrator/components/com_akeeba/BackupEngine/Util/Encrypt.php score 50

  • libraries/vendor/simplepie/simplepie/library/SimplePie.php score 100

  • administrator/components/com_akeeba/restore.php score 100

  • administrator/components/com_akeeba/BackupEngine/Archiver/Jps.php score 250

  • libraries/vendor/simplepie/simplepie/library/SimplePie/Misc.php score 300

Of course, there are other PHP files with threat scores up to 600. All are marked as modified or suspicious. Modified, yes, because it was updated today. That is clear.

OK, so you said a file marked as suspicious is a file that already existed during the previous scan, has not been modified and has a non-zero Threat Score. The thing is when I try to search for a specific 'suspicious' or 'modified' file I can not find it in previous reports.
For example the file libraries/tcpdf/html_entity_decode_php4.php was today marked as suspicious with a Threat score 200 on all sites we maintain.
Or, the file administrator/components/com_akeeba/BackupEngine/Archiver/Jps.php is marked as modified with a Threat score 250.
So, yeah, hmh is the best phrase of the question that's spinning in my mind now.

Paraphrased in words: Can you please tell me what has changed and what should I keep in mind when reading the reports now.

Please note: we have cronjobs setup on all sites to fire the PHP scanner once every 24 h. So yes, I check the reports whenever I see that the emails indicate some changes are made to the websites.

Tnx for your time,

Custom Fields

Joomla! version (in x.y.z format) 3.8.5
PHP version (in x.y.z format) from 5.6.31-pl0-gentoo to 7.0.27-he.0
Admin Tools version (x.y.z format) 5.0.1
Tuesday, 20 February 2018 02:25 CST
Ah, finally, someone who's paying attention! Thank you for this ticket :)

We added more malware detection patterns in version 5. These patterns carry a high threat score since the code they detect is most often -but not exclusively- used in advanced malware. Some existing code will of course match these patterns and show a higher Threat Score for the file. After all, scanning source code is by definition impossible to do in a way that's free of false positives unless you have a highly trained, highly experienced, highly expensive and really slow human developer do it.

The example files you shared are exactly where I would expect to see false positives. These files deal with encryption (all of the files belonging to our software that you shared) or use complex regular expression patterns (the SimplePie ones). This kind of code is very likely to trigger the new patterns by error, i.e. a false positive. However, I am healthily paranoid -if you deal with security some low key paranoia is a very healthy sign- and I don't just mark as safe any file I would expect to throw false positives. This kind of complacency is what gets you hacked.

Sidebar: you wondered, why does the Akeeba Backup file show as both modified and high threat score? You are running your scanning every 24 hours. In those past 24 hours you updated Akeeba Backup and Admin Tools. Their files changed so they are no longer marked as safe. The detection patterns in Admin Tools do report false positives on these (changed) files. So everything is working as expected. Closing this sidebar, this is also an inference and susceptible to complacency. So just keep it in mind as a potential explanation of the observed behavior, not as a gospel. End of sidebar.

What you really need to do is check if the file has changed. If the file has not changed but the threat score got bumped it's a false positive; mark as safe and don't think about it twice. If the file has changed you need to verify it. Compare it to the file that's shipped in the official distribution of the software it belongs to. If the files are identical mark them as safe. If they are not, analyze the contents of the file on disk. Clicking the file in the report will highlight the suspicious parts of the file, letting you see what the PHP File Change Scanner "sees" as a problem on the file.

What you should be doing to avoid this pain in the future is run the detection right before and right after updating a bunch of components. You know that the changed files between those two scans are legitimate - you just installed them. Therefore you can blindly mark as safe all of the changed files with a non-zero threat score in this scenario. This is a safe and easy thing to do on top of your daily scan.

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!

Tuesday, 20 February 2018 03:51 CST
Thank you very much, Nicholas for your extensive explanation.

I don't mind the false positives. They have to exist in order to point out the malicious code. So yes, your paranoia is healthy and reasonable. And it's what keeps you improving Admin Tools. ;)

Well, thanks again for your hard work..
I'm off to check those reports again and mark them safe or check the files if necessary.

This sentence: "I don't just mark as safe any file I would expect to throw false positives. This kind of complacency is what gets you hacked." is worth repeating.

Have a very nice day.
Yours sincerely,
Thursday, 22 March 2018 18:17 CDT
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.
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!