The Drupal based websites were supposed to be patched within seven hours of the critical security update release on October 15, 2014. The security release carried a clear warning about the security vulnerability (SA-CORE-2014-005 SQL injection), which was exploited by the hackers to write web bots that traced vulnerable sites on the web in no time.The Drupal 7 and Drupal core 8.0.x websites were found to be particularly vulnerable to the SQL injection while Drupal core 6.x websites were relatively safer if not running on the same server that hosted Drupal 7 sites. Here are a few precautionary and remediative measures that you must know as a Drupal site administrator.
# Patch your Installation on time: Take critical security releases seriously
As the popular adage goes a stitch in time indeed saves a lot more than nine. So the best strategy to ward off malicious attacks is to take the impending vulnerabilities into account and implement the solutions available.
Although two highly critical advisories were issued by the Drupal Security team in October this year, it failed to create enough hype about the impending doom. As a result the security of around 900,000 websites was compromised as they became targets of sweeping automated attacks. It affected all the Drupal core 7.x versions as many Drupal 7 websites chose to ignore or were too late to apply the patch release along with the Drupal 7.32 version update.
# Keep Track of your Vulnerabilities : Check for Backdoors
Sometimes there are multiple long standing issues that eventually lead to sites being hacked. But that is not the end of the road as the real challenge lies in resolving the issues by finding out the loopholes that led that security bug in. A vulnerability in the database abstraction API of Drupal 7 allowed attackers to generate requests that led to privilege escalation and arbitrary SQL execution. In short the hackers created backdoors(menu_router entry) to run a PHP code on your site which let them upload any content on it. Once the exploit files are installed to the server, the hacker can send http requests to execute PHP.
# If Hacked: Build a new server/rebuild an existing one
The choice between keeping a site or trashing it, after an attack should be made after considering the kind of efforts you would have to put in to restore it with a backup for all your files. You can replace the site with a static HTML file and take the site offline if it is being used to perpetuate malware. All the active sessions on the site should be put to an end and passwords must be replaced as a precautionary measure if you decide to keep the website. Keep track of the logins from external IP addresses by analysing the sessions table to identify fraudulent users. It will be a fairly easier task to rebuild a site with the help of an older database and file backup. You can check the integrity of your files using the Git status and scan the private file locations for *.php, *.sh or any other dubious files.
# Review the Damage : Follow the Breadcrumbs
While you can begin with examining the exploit files left on the server, a great option to conduct the post-mortem is to reverse engineer the tools that were employed to create these exploit files. Document all your exploited vulnerabilities along with solutions to fix the issues. Make an inventory of useful ideas to counter different vulnerabilities by assessing the damage done.
# Stay Safe: Continue following good security practices
An easy way to keep non-administrators off your site is to use an IP access control list in the Drupal .htaccess file. So the next time someone tries to post unauthorized content on your site, the result will be an error 404. The initial wave of attacks during Drupalgeddon were characterized by unauthorized content upload which could have been prevented if proper Unix File Permissions were set in advance. You must get accustomed to creating regular back-ups for both the database and the files on your web server.
Follow the Drupal community at Drupal.org to keep a tab on the latest developments and get into the habit of evaluating your website, especially in event of security releases and version updates.It is a good practice to notify fellow users about any security breaches on your site through the hosting company,as it may have implications for other websites hosted on the same server.Although every software is prone to vulnerabilities more often than not, the risk of future attacks can be minimized by making the platform write protected.
We at Valuebound understand your unique business needs while we strive to provide you with secure Drupal based Enterprise level Web Solutions. For information on our service offerings, please Contact Us.
