By Fernando Arnaboldi
Security updates are a common occurrence once you have installed Drupal. In October 2014, there was a massive defacement attack that effected Drupal users who did not upgrade in the first seven hours after a security update was released. This means that Drupal updates must be checked as frequently as possible (even though by default, Drupal checks once a day).
Just a few days after installing Drupal v7.39, I noticed there was a security update available: Drupal v7.41. This new version fixes an open redirect in the Drupal core. In spite of my Drupal update process checking for updates, according to my local instance, everything was up to date:
The issue was due to some sort of network problem. Apparently, in Drupal 6 there was a warning message in place, but this is not present in Drupal 7 or Drupal 8.
Nevertheless, if the scheduled update process fails, it is always possible to check for the latest updates by using the link that says "Check Manually". This link is valuable for an attacker because it can be used to perform a cross-site request forgery (CSRF) attack to force the admin to check for updates whenever they decide:
Since there is a CSRF vulnerability in the "Check manually" functionality (Drupal 8 is the only one not affected), this could also be used as a server-side request forgery (SSRF) attack against drupal.org. Administrators may unwillingly be forcing their servers to request unlimited amounts of information from updates.drupal.org to consume network bandwidth.
An attacker may care about updates because they are sent unencrypted, as the following Wireshark screenshot shows:
To exploit unencrypted updates, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs 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 update process downloads a plaintext version of an XML file at http://updates.drupal.org/release-history/drupal/7.x and checks to see if it is the latest version. This XML document can point to a backdoored version of Drupal.
- The current security update (named on purpose "7.41 Backdoored")
- The security update is required and a download link button
- The URL of the malicious update that will be downloaded
However, updating Drupal is a manual process. Another possible attack vector is to offer a backdoored version of any of the modules installed on Drupal. In the following example, a fake "Additional Help Hint” update is offered to the user:
Offering fake updates is a simple process. Once requests are being intercepted, a fake update response can be constructed for any module. When administrators click on the “Download these updates” buttons, they will start the update process.
This is how it looks from an attacker’s perspective before and after upgrading the "Additional Help Hint” module. First it checks for the latest version, and then it downloads the latest (malicious) version available.
As part of the update, I included a reverse shell from pentestmonkey (http://pentestmonkey.net/tools/web-shells/php-reverse-shell) that will connect back to me, let me interact with the Linux shell, and finally, allow me to retrieve the Drupal database password:
You may have heard about such things in the past. Kurt Seifried from Linux Magazine wrote an article entitled "Insecure updatesare the rule, not the exception" that mentioned that Drupal (among others) were not checking the authenticity of the software being downloaded. Moreover, Drupal itself has had an open discussion about this issue since April 2012 (https://www.drupal.org/node/1538118). This discussion was reopened after I reported the previous vulnerabilities to the Drupal Security Team on the 11th of November 2015.
You probably want to manually download updates for Drupal and their add-ons. At the moment of publishing there are no fixes available.