HackDig : Dig high-quality web security articles for hacker

Drupal - Insecure Update Process

2016-01-06 18:15



By Fernando Arnaboldi

Security updates are a common occurrenceonce 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 hoursafter a security update was released. This means that Drupal updates must bechecked as frequently as possible (even though by default, Drupal checks once aday). 

Just a few days after installingDrupal 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 Drupalupdate process checking for updates, according to my local instance, everythingwas up to date: 



Issue #1: Whenever the Drupal update process fails,Drupal states that everything is up to date instead of giving a warning.

The issue was due to some sortof network problem. Apparently, in Drupal 6 there was a warning message inplace, but this is not present in Drupal 7 or Drupal 8.

Nevertheless, if the scheduledupdate process fails, it is always possible to check for the latest updates byusing the link that says "CheckManually". This link is valuable for an attacker because it can beused to perform a cross-site request forgery (CSRF) attack to force the adminto check for updates whenever they decide:

  • http://yoursite/?q=admin/reports/updates/check

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-siderequest forgery (SSRF) attack against drupal.org. Administrators mayunwillingly be forcing their servers to request unlimited amounts ofinformation from updates.drupal.org to consume network bandwidth.

Issue #2: An attacker may force an admin to check forupdates due to a CSRF vulnerability on the update functionality

An attacker may care about updates because they aresent unencrypted, as the following Wireshark screenshot shows: 



To exploit unencrypted updates,an attacker must be suitably positioned to eavesdrop on the victim's networktraffic. This scenario typically occurs when a client communicates with theserver over an insecure connection, such as public WiFi, or a corporate or homenetwork that is shared with a compromised computer.  

The update process downloads aplaintext version of an XML file athttp://updates.drupal.org/release-history/drupal/7.x and checks to see if it isthe latest version. This XML document can point to a backdoored version ofDrupal.  

  1. The current security update(named on purpose "7.41 Backdoored")
  2. The security update is required and a download link button
  3. The URL of the malicious update that will be downloaded

However, updating Drupal is amanual process. Another possible attack vector is to offer a backdoored versionof any of the modules installed on Drupal. In the following example, a fake"Additional Help Hint” update isoffered to the user:



Offering fake updates is asimple process. Once requests are being intercepted, a fake update response canbe constructed for any module. When administrators click on the “Download these updates” buttons, theywill start the update process.

This is how it looks from anattacker’s perspective before and after upgrading the "Additional Help Hint” module. First itchecks for the latest version, and then it downloads the latest (malicious)version available. 



As part of the update, I included a reverseshell 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:


Issue #3: Drupal security updates are transferred unencryptedwithout checking the authenticity, which could lead to code execution anddatabase access.

You may have heard about such things in the past. KurtSeifried 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, Drupalitself 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 tothe Drupal Security Team on the 11th of November 2015.

You probably want to manually download updates for Drupaland their add-ons. At the moment of publishing there are no fixes available.

TL;DR - It is possible to achieve code executionand obtain the database credentials when performing a man-in-the-middle attack againstthe Drupal update process. All Drupal versions are affected.


Source: lmth.ssecorp-etadpu-erucesni-lapurd/10/6102/moc.evitcaoi.golb

“Drupal - Insecure Update Process”0 Comments

Submit A Comment

Name:

Email:

Blog :

Verification Code:

Announce

Share high-quality web security related articles with you:)

Tools

Tag Cloud