Was your website hacked?
In October 2014 the Drupal world was shocked. The proverbial excrement had hit the fan, and a security vulnerability had been found in the Drupal core version 7.31. Normally the discovery of a bug in an application is not a newsworthy event in the world of Internet, but in this case the security hole was of such an epic magnitude that it was dubbed “Drupalgeddon”.
The vulnerability found on 15 October was a SQL injection bug. This bug allowed the hacker to run all the commands he wanted in Drupal’s main data storage SQL database through a web form on a web page. A couple of reasons made the bug especially serious: the bug allowed the hacker to gain control of a whole website, it applied to all earlier Drupal 7 versions, and it’s mechanical exploitation started just a few hours after the vulnerability was made public.
Even though Drupal is a community administered application, its security is handled by a dedicated security team, which receives bug reports, informs about issues and oversees the resolution of those issues. As is good practice, security issues are made public only after a fix is available, and it’s made sure that administrators have a chance to update vulnerable systems. The security team announced the SQL injection bug (DRUPAL-SA-CORE-2014-005) and released a fix (Drupal version 7.32) on 15 October 2014 at 18:04. After only a few hours, hacker programmed bots started scanning vulnerable computers and begun breaching them automatically.
If the security vulnerability was not fixed within 7 hours, the service could be considered hacked. Those parties whose services were under active system administration could mostly breathe a sigh of relief. The biggest damage was done to those parties that didn’t have an administration arrangement with Drupal professionals. We informed all our clients about the issue within 3 hours of the fix being released while at the same time updating their services regardless of the coverage our administration agreement offered.
The security team has received unnecessary flack for publishing a fix in October even though the vulnerability was found in late September. The reason for the delay was that the world’s largest Drupal event was held around the same time. That would have meant that hackers would have been at their computers ready to rock, while the administrators for all the major websites would have been on the road and away from their posts. There’s no knowledge of any sites being hacked due to the delay, but on the other hand, by timing the fix within the official update window, the information could be distributed as widely as possible.
Every application has bugs. The bigger the application, the more there’s room for bugs. Naturally Drupal is no exception, but the maturity of the application and its wide use in web based business have more than likely made it more bug-free than many other open source applications.
Even though the stir around Drupalgeddon has died down, there is still a large number of sites on the Internet that use vulnerable versions of Drupal and which are more than likely still playgrounds for hackers. During the spring we made information security audits for many of our new clients in an attempt to root out hacker activity. The problem is that when a site is breached, the hackers create a dozen new vulnerabilities that allow the site to be accessed even if the original breach is closed.
If you have concerns about your own Drupal system, you might be able check its version number without having to log in by navigating to http://www.your-own-site.com/CHANGELOG.txt. If the topmost version number is 7.31 or lower (or if your site is unintentionally marketing erectile dysfunction medicine), don’t hesitate to contact us, and together we’ll decide what steps should be taken to fix the matter!
