IOActive’s Fernando Arnaboldi has sounded the alarm on three major flaws in Drupal’s update process that may allow attackers to poison Drupal installations via update packages and in worst case scenarios even take over servers.
Drupal, one of the Internet’s Top 3 CMSs, isn’t as popular as WordPress and Joomla, but it’s a favorite for building large-scale, enterprise-ready, and highly customizable websites.
Just like any modern CMS these days, Drupal can be updated from its backend administration panel, just by pressing a button. To make things even easier for busy site admins, the CMS is also fitted with an automatic update checker, for both its core and its modules. This lets admins know when a new version is out and allows them to quickly apply the update package and move on to other more important things.
According to Mr. Arnaboldi, there are three problems with the way Drupal handles this update process, flaws for which there are no current fixes.
Webmasters may think their site is updated when it’s not
The first issue has to do with failed update queries. Because of various connectivity issues, Drupal sites may sometimes fail when checking for an update. The problem is that, when this happens, the CMS prints the “All your projects are up to date” message, instead of clearly stating that the update has failed to complete.
This problem may be used by attackers to flood local networks with traffic when an update process is taking place, forcing the CMS to print an erroneous update status in the backend.
In less paranoid scenarios, this same issue may also fool the Drupal admin into thinking their site is up to date when in reality it remains vulnerable for tens of dangerous bugs, which can quickly add up when not keeping the CMS properly updated.
This failure to print the proper update status message affects both major versions of Drupal, 7.x and 8.x.
CSRF bug in the Drupal manual update button
The second issue Mr. Arnaboldi described has to do with the “Check manually” button included on the Drupal update page. This button allows the site’s administrators to check for new updates on command, and later apply the update.
Unfortunately, this specific button is vulnerable to CSRF (Cross-Site Request Forgery) attacks.
“Since there is a CSRF vulnerability in the ‘Check manually’ functionality, this could also be used as a server-side request forgery (SSRF) attack against drupal.org,” explained Mr. Arnaboldi. “Administrators may unwillingly be forcing their servers to request unlimited amounts of information from updates.drupal.org to consume network bandwidth.”
Only Drupal versions from the 6.x and 7.x series are affected. Drupal 8.x’s manual update checker is CSRF bug-free.
Taking over Drupal sites via poisoned update packages
But these two bugs are not that dangerous when you consider what they can actually do. On the other hand, the third flaw is more critical and has to do with the fact that Drupal’s update process is unencrypted.
By sending everything in cleartext, an attacker present on the local network in the form of an infected computer can sniff out traffic between the Drupal CMS and the drupal.org servers, and detect when an update process is started.
They can then launch a simple MitM (Man-in-the-Middle) attack, spoof communications, and send malicious update packages to the CMS instead. This attack scenario is valid for both core Drupal updates and module packages.
By using this third flaw, Mr. Arnaboldi successfully installed a backdoored Drupal update on a test website, in which he packaged a reverse PHP shell that gave him access to the Web server running the CMS, and later extracted the MySQL database’s username and password (image below).
What’s worse is that Drupal’s team had known of this issue since 2012, but only recently reopened discussions on fixing the problem, after Mr. Arnaboldi’s recent findings.
Mitigation: For now, until Drupal’s devs will get around to fix these issues, Mr. Arnaboldi recommends that all installations should be performed manually (“manually” as in downloading the update package from drupal.org on a local computer, unzipping the files, and moving them via FTP to the Web server).
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
