The Drupal CMS is identified as one of the most secure CMS out there. But, like every other CMS, Drupal has been at the center of notoriety a few times due to impending vulnerabilities in it.
Today we are looking back onto the 5 most critical vulnerabilities ever found in Drupal. We will also try to understand how those attacks were possible and what were the ramifications.
The 5 Most Critical Vulnerabilities That Had Left Drupal Shaken
This vulnerability dates back to October 2014. It was an SQL vulnerability, dubbed as “Drupalgeddon”. The Drupal 7 database API abstraction layer became vulnerable to an SQL Injection attack. Drupal core 7.x versions prior to 7.32 were affected.
This vulnerability allowed an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests, this led to privilege escalation, arbitrary PHP execution, or other attacks.
Later, Drupal released an advisory sharing more information around the vulnerability. The advisory assigned this vulnerability a risk score of 25/25 (Highly critical). A risk score of 25 meant the attacker needed a bare minimum to absolutely no prior information to exploit this vulnerability.
To curb this, Drupal released remediation steps. Drupal web owners were prompted to urgently upgrade to the patched version.
When the Drupalgeddon buzz died down. The revelation of another Drupalgeddon 2 startled the Drupal community on 13th April 2018. This time it was a Remote Code Execution vulnerability. Drupal 8, 7, 6 all were affected. Once again, Drupal was prompt in releasing an advisory. Drupalgeddon 2 was assigned a risk score of – 24/25.
Only a few days had passed when another advisory made it to Drupal’s official website. Drupalgeddon – Part 3 was it. This was again a critical RCE (Remote Code Execution) Vulnerability affecting Drupal versions 8.x & 7.x.
2. Drupal Core Critical Access Bypass
A critical access bypass vulnerability came to light rendering Drupal-based websites at the peril of hacking. Successful exploitation of the vulnerability led to a complete compromise of data confidentiality and website integrity. This affected the Drupal 8 version, users of which were advised to upgrade to the then newly released 8.3.1 or 8.2.8 versions.
To exploit the vulnerability, websites must have the RESTful Web Services enabled. The site should also allow PATCH requests. Furthermore, the attacker needs to register a new user account on the website or gain access to an existing one.
3. Code Execution Vulnerability
In 2017, Drupal had also been deemed as vulnerable to code execution (CVE-2017-6381) putting it at peril to database credential theft. To exploit the CMS flaw, the attacker needed to be on the same network and execute as a middle man.
The vulnerability rose by the way Drupal handled updates. The key reason for this flaw was the transfer of Drupal security updates without a prior authenticity check. This leads to users ultimately resorting to a manual download of updates and their add ons. The vulnerability could also be exploited further to prevent the reception of update alerts and entice admins to install modules from unreliable servers.
4. CSRF Vulnerability
In addition to the code execution flaw, the insecure update process of Drupal version 7 also rendered the CMS to CSRF attacks. Due to a CSRF vulnerability on the update, an attacker may force an admin to check for updates. He would do so by eavesdropping on the victim’s network traffic.
Such situations generally occur when a client communicates with the server over an insecure connection, such as public WiFi, or a corporate or home network that is shared with a compromised computer. The Drupal Form API protects against CSRF using special tokens in the automatically added forms.
5. Cross-Site Scripting Vulnerability
The Cross-site scripting (XSS) vulnerability (CVE-2016-7571) in versions prior to Drupal 8.1.10 allowed remote attackers to inject arbitrary web script or HTML via vectors.
Contact Astra to secure your Drupal website from such potential threats.