The scenario
We received this email from a small business owner requesting help:
Our site shows Chinese text trying to sell sunglasses instead of showing our content. My team can log into the site and can see our content is still there. Also, some of the code seems to have been changed and I understand index.php is missing. Is there something we should do, like, right away?
Our email response:
An injection attack is the most probable explanation. WordPress, on which your site is built, is like any major CMS in providing
... a set of functions ... to assist developers in making sure unauthorized code cannot be injected, and help ... protect, validate, or sanitize input ... [to] the database and filesystem.
https://wordpress.org/about/security/
The key detail to note is that injections typically compromise the database as well as the code stored in files. The reference to the filesystem in the quote may relate to your missing index.php. Re-adding that file is very unlikely to address the actual issue.
Simply fixing code here and there after an attack would be like painting deeply rusted metal. A paint store employee may happily recommend that solution, and the situation might look better when the paint dries, but the time and money you put into this effort is most likely wasted. The rust will replace the paint again pretty quickly, and the the metal remains weakened and permeable.
The current risks
Risks at this point include the possibility that sensitive information has been stolen, like login credentials that account holders may use to access other accounts (email accounts, financial accounts, etc.).
Consider how to inform anyone who has an account on your site that their information may no longer be protected.
There may be other risks to unrelated data stored on the same server, or to sites that exchange data with yours.
The quickest remediation plan
To get your site back online, the best remediation steps are almost always to:
- Remove the outdated CMS code that runs your site.
- Install the latest CMS version.
- Revert to a database backup that predates the exploit.
- Confirm any custom code, such as your theme, is uncompromised.
- Reset login credentials.
- Test.
- Relaunch the site.
Identifying a backup that is uncompromised may be challenging, and the backup may have out of date content or features. Once your site is back online and you have confirmed it is healthy, you may need to rebuild missing pieces.
These steps aim to get your site back online relatively quickly and easily. However, they may not fully address the cause of the problem. If the original vulnerability still exists, the fix will not last long. Read on to protect against recurrences.
Are the original developers no longer available? They would most likely be the fastest at reverting to a backup if it is something outside your current team's routines.
Key assumptions
Our recommendation above assumes:
- Your site was built following the recommended practices of your CMS.
- Your CMS provider has issued a fix for the vulnerability that had not been installed on your site at the time your security was breached.
- Your server software is up to date.
- Your server is properly secured and was not itself affected by the breech.
None of these assumptions should be taken for granted. Once your site is back online, confirming them is your best next focus.
Building a WordPress site is reasonably easy, but building one suited to long-term maintenance can be pretty challenging, and some long-established firms fall short on this front. Similarly, many long-established hosting providers rely on software that is years out of date.
An alternative remediation plan
If you don't have a good backup available or have reason to believe the original site is not built sufficiently securely, the next best approach is to extract content and theme, then build a fresh instance of your CMS.
This approach is significantly more labor intensive than restoring a backup. In addition to rebuilding the site functionality, you will need to ensure neither content nor theme contains security issues.
Entering content via your CMS's APIs is usually the most effective at sanitizing it. Importing directly into the database should be avoided, as doing so bypasses checks on the data.
For guidance on ensuring your theme is secure, review the code against your CMS's published standards.
The rabbit hole to avoid
Both suggestions above are significantly lighter and more reliable efforts than digging around for the actual exploit and attempting to undo the related effects.
Attempting to apply fixes to a compromised site involves unreasonably high risks. It's natural for web teams to want to troubleshoot. The effort is unlikely to produce a lasting solution.
Protecting against the issue in the future
Well maintained server and CMS software is your best defense. A well crafted disaster recovery plan is an essential risk mitigation strategy.
Note that the skills for managing servers are very specialized, and the challenge of online security is intensifying. The majority of organizations should work with a specialized hosting provider and avoid direct responsibility for the heavy lifting of running their own server hardware, software and network management.
Cost management
Relying on an external host may appear more expensive, and it may mean giving up some flexibility. However, if your web application is important to your business, avoid making sticker price your top consideration. A more useful datapoint is Total Cost of Ownership.
If you've been on inexpensive shared hosting, you might expect to pay 10x more per month for reasonable assurances. Even at that level of budget change, the cost is exponentially less than a single day of a specialist's time.
imageby Daniel Gies, taken on July 24, 2010 in El Cerrito, California, United States
- Log in to post comments