This is very concerning, and I wanted to have our team run some security tests before we replied. Our developers were unable to find places in the application code that would allow for this type of intervention - while it is possible that we've missed something, I suspect it may have to do with your deployment or configuration.
I will talk to our team and see what resources we can provide that might help you with term cleanup. In the meantime, I wanted to make a few other suggestions.
First, if you have been regularly making backups (as we strongly recommend anyone with a production site do!), now would be the time to load one! This will be the easiest way to undo the damage that has been done to your term data.
Also, if you haven't already, I strongly recommend that you review all your user accounts. Delete or mark inactive any that you don't need. Make sure there's not a demo account left in there that might have been accessed. Consider enabling the "require strong passwords
" security setting, and resetting all your user passwords with temporary ones and asking them to create new ones.
We did test the security of the API endpoints in AtoM as well, but if you have the API plugin enabled and aren't using it, you can disable the arRestApiPlugin in Admin > Plugins.
I would also suggest that you take a look at your Nginx access logs to see if you can determine the IP address of the bots responsible for this. You can then use a combination of a robots.txt file and Nginx access rules to block these IPs. Some resources to get you started:
Nginx restrict access by IP
A couple other points worth mentioning:
First, you should know that we have NOT tested AtoM 2.6 releases on Ubuntu 20.04 and PHP 7.4. We will be supporting both of these with the 2.7 release, but at this time we formally recommend using 18.04 and PHP 7.2 for AtoM 2.6 releases. I don't think this would be the cause of the vulnerability, but thought it worth mentioning.
More importantly - looking at your full AtoM version number (2.6.2 - v175), I am concerned that at some point you have not upgraded properly. The database schema version (the second number - 175 in your case) for AtoM 2.6 releases should be v185. This means there are up to 10 schema migrations from previous releases that have not successfully been run in your MySQL database - meaning some changes to tables and columns are not currently present in your database where they should be, which could cause other errors as you try to make changes in AtoM.
This can happen when the upgrade task is not run during the upgrade process. I don't know what the effects will be now, but I recommend that you make a backup of your data, and then try running the upgrade task again to see if it helps, followed by the recommended maintenance tasks. See the upgrading documentation:
I'm really sorry this has happened to you, and I'm sure it must be frustrating. As I've said, we haven't found anything in the application code that would allow this type of attack to a properly secured site outright, but it's always possible we've missed something - please let us know what you learn as you investigate further. I will also talk to our team to see if they have further suggestions, including some ways to help clean up the terms data if you don't have backups to load. Some questions that will help us target our responses:
- Were new terms created? Or did these bots simply add scope note text to existing terms? Or both?
- Is it just in the Subjects taxonomy, or have other taxonomies been affected as well?
- Would deleting all terms that are not linked to any descriptions resolve the issue for you? Or what about deleting all scope notes in a particular taxonomy? Trying to get a sense of how broad we can perform any cleanup actions without accidentally deleting data you want to keep.