Threat Assessment
The SQL Injection vulnerability in Drupal versions 7.0 through 7.31 is an extremely dangerous vulnerability that is likely to have profound implications for the Internet as a whole. This vulnerability is particularly serious because it is extremely easy to exploit, affects a large number of assets and systems that are already being targeted by cybercriminals, and a lot of target systems are likely to remain unpatched for a long time.
The solution for this vulnerability is to install the vendor-supplied patch. However, this type of vulnerability can be also be easily prevented by applying simple development guidelines that are presented in TEAM Mentor.
If the Drupal team had followed these guidelines, this vulnerability would have never existed in the first place.
Affected Assets and Attack Vectors
The following assets are potentially affected by the Drupal SQL Injection vulnerability:
Sites using Drupal
Obviously, the sites using Drupal itself are affected by this vulnerability. An attacker is able to leverage this vulnerability to take full control of the site, compromise user information (such as stored authentication credentials and contact information), modify its content, redirect its visitors elsewhere, or execute arbitrary PHP code on the server. Executing arbitrary PHP code on the server usually allows executing arbitrary system commands on the server and executing privilege escalation attacks to take full administrative control of the server.
Sites and other assets on the same servers as the sites using Drupal
Once an attacker has taken full control over the server, any other site hosted on the same server is also compromised. Any databases or email spools stored on the same server are also compromised. Additional privilege escalation vulnerabilities have to be present on these servers for these assets to be compromised. Unfortunately, the combination of a vulnerable version of Drupal and an exploitable privilege escalation vulnerability is not a hypothetical possibility.
Systems on the same internal network segment as the servers hosting Drupal
Once an attacker has compromised a server hosting Drupal, they can use the vulnerability to attack other systems on any internal network that the compromised server is connected to.
Registered users of sites using Drupal
Once an attacker has compromised a site using Drupal, the users' email addresses and the password hashes become available to the attacker. The attacker can then crack a significant portion of these hashes to recover the plain-text passwords and correlate them to e-mail addresses. Since a lot of people use the same passwords for various Internet accounts (including e-mail), the attacker might be able to use these passwords to break into users' personal e-mail accounts. Once a personal e-mail account is compromised, an attacker is able to download the user's contact list for spamming and compromise many common types of Internet accounts registered using that e-mail address by using the password recovery feature.
Registered users of sites on the same servers as servers that host Drupal
If a server that hosts a vulnerable version of Drupal also contains an exploitable privilege escalation vulnerability, the attacker will be able to obtain e-mail addresses and password hashes of the registered users on the other sites hosted on the same server. Once the attacker has e-mail addresses and hashes, the attacker will usually be able to break into a sub-set of these e-mail accounts. These hacked e-mail accounts can then be used for impersonation in social engineering attacks, spam, and breaking into Internet accounts that are registered using these e-mail accounts.
Visitors to sites using Drupal
An attacker is able to replace content on a compromised Drupal site with exploits that target web browsers and web browser plug-ins of the users that visit the compromised site. If a visitor is running a vulnerable web browser or has a vulnerable plug-in installed, the attacker will be able to take partial control of the visitor's personal computer. While modern operating systems will usually prevent the attacker from taking full control of the personal computer, the attacker will still usually be able to retrieve the passwords stored on the user's computer, record data entered by the user into web sites, monitor keystrokes, take pictures with the camera, record sound with the microphone, take screenshots of user activity, take remote control of the user's desktop, use the user's computer to participate in DDoS attacks, send spam, or act as a proxy when the attacker is doing something illegal.
Visitors to sites on the same servers as Drupal sites
If a server that hosts a vulnerable version of Drupal also contains an exploitable privilege escalation vulnerability, the attacker will be able to replace content on the other sites hosted on that server with exploits that target web browsers and web browser plug-ins of the users that visit these sites - with the goal of taking over the personal computers of these users.
Impact
The degree of impact of this vulnerability depends on how quickly vulnerable installations of Drupal are updated. Without the extensive media coverage that was granted to Heartbleed, Shellshock, and even Poodle vulnerabilities, many Drupal sites will likely remain vulnerable for months, because many administrators will be simply unaware that their sites are vulnerable.
If major Drupal sites are not updated in a matter of days, we’ll likely witness elevated levels of DDoS attacks, a significant increase in the volume of spam, large amounts of financial fraud using credentials stolen from personal computers of visitors to compromised sites, and clandestine high-profile attacks that are difficult to investigate, but are actually carried out using credentials stolen from compromised sites or from personal computers of visitors to compromised sites.
Prevention
This vulnerability and all SQL Injection vulnerabilities can be easily prevented by using parameterized APIs for database access. This is a very important point. SQL Injection vulnerabilities are some of the most common, most dangerous, easiest to discover and easiest to exploit vulnerabilities that have been plaguing the Internet for the past decade.
It might seem like this type of vulnerability is mysterious and difficult to prevent, since it is so persistent. However, this is not the case. It is actually quite easy to prevent SQL Injection vulnerabilities, provided developers have the appropriate knowledge needed to implement defensive coding techniques.
The guidelines for preventing SQL Injection can be found on the Security Innovation TEAM Mentor Vulnerability index site.
Additional resources are available on the Security Innovation SQL Injection page.
To prevent SQL Injection vulnerabilities, be sure to validate all input and use parameterized APIs for database access. Input validation is an effective countermeasure against a broad range of injection vulnerabilities including SQL Injection, but it should always be used as a defense-in-depth measure and not relied on solely for defense on its own.
For SQL Injection, the key is to use parameterized APIs for database access. It is also recommended to validate all input as an additional layer of protection. Parameterized database access APIs are prepared statements and stored procedures. Prepared statements are always parameterized. Stored procedures have to be written in a way that does not concatenate user input with SQL syntax in order to prevent SQL Injection.
Using prepared statements or properly written stored procedures for database access will eliminate any possibility of SQL Injection in code that follows these guidelines. SQL Injection occurs when malicious data is concatenated with SQL syntax and passed to the database engine. When an application does that, the database engine cannot distinguish SQL syntax from malicious data, malicious data is executed as SQL syntax, and SQL Injection results. Using prepared statements or properly written stored procedures keeps malicious data separate from SQL syntax and the database engine knows not to execute the data, and thus SQL Injection is prevented.
Want to learn more about SQL Injection?
Take our FREE SQL Injection Course!
-----
Want to be notified of any similar articles about Attack Trends? Click here to subscribe!
