Page non traduite. Anglais uniquement.
On 12th July, 2016, Drupal announces three highly critical remote execution vulnerabilities on contributed modules.
Modules concerned are:
- Webform Multiple File Upload
Only Drupal version 7.x and sites using those modules are affected. Drupal core is not affected.
Highly Critical: RESTWS
This module enables you to expose Drupal entities as RESTful web services.
RESTWS alters the default page callbacks for entities to provide additional functionality.
A vulnerability in this approach allows an attacker to send specially crafted requests resulting in arbitrary PHP execution.
There are no mitigating factors. This vulnerability can be exploited by anonymous users.
The following exploit has been tested in your labs with the following configuration :
- Drupal 7.50
- RESTWS module 2.5
- Entity module (needed by RESTWS)
- Taxonomy module
We will use the php function "passthru" to execute system commands on the remote server :
We send a payload with a simple directory listing command :
The server returns directory contents :
Php Shell upload
The following payload will create a file named "shell.php" then fill it with a php shell (base64 encoded) :
Payload blocked by the ICX Engine :
With DenyAll WAF in front of a vulnerable Drupal web site, exploitation payloads are detected and blocked by the ICX engine (Drupal security template).
- In the case of an exploit passing through the ICX Engine, a negative rule can be created to mitigate and block any GET Vars containing "taxonomy_vocabulary/".
- Use the web services firewall with the a XML parsing node or the JSON to table node before the ICX Security Engine.
See the worklow " " (provided by default) or the use case JSON firewall.
- Manage access on the RESTful web services by using the Web SSO or IP restrictions.
- Update the module to the latest version (RESTful Web Services 7.x-2.6 or 7.x-1.7).
Highly Critical: Coder
The Coder module checks your Drupal code against coding standards and other best practices. It can also fix coding standard violations and perform basic upgrades on modules.
The module doesn't sufficiently validate user inputs in a script file that has the php extension. A malicious unauthenticated user can make requests directly to this file to execute arbitrary php code.
There are no mitigating factors. The module does not need to be enabled for this to be exploited. Its presence on the file system and being reachable from the web are sufficient.
Be careful, the module does not need to be enabled for exploit.
- Restrict the access to the module path "/modules/coder" and especially the script "/modules/coder/coder_upgrade/scripts/coder_upgrade.run.php"
- Restrict PHP file access, except the main index.php or other mandatory pages ending by ".php".
- Manage access to the Drupal administration section by using the Web SSO or IP restrictions.
- Update the module to the latest version (Coder 7.x-1.3 or Coder 7.x-2.6).
Critical: Webform Multiple File Upload
The Webform Multiple File Upload module allows users to upload multiple files on a Webform.
The Webform Multifile File Upload module contains a Remote Code Execution (RCE) vulnerability where form inputs will be unserialized and a specially crafted form input may trigger arbitrary code execution depending on the libraries available on a site.
This vulnerability is mitigated by the fact that an attacker must have the ability to submit a Webform with a Multiple File Input field. Further, a site must have an object defined with methods that are invoked at wake/destroy that include code that can be leveraged for malicious purposes. Drupal 7 Core contains one such class which can be used to delete arbitrary files, but contributed or custom classes may include methods that can be leveraged for RCE.
Note: this vulnerability exists in the Webform Multiple File Upload (webform_multifile) module. There is a similarly named module Webform Multiple File (webform_multiple_file) which is not related to this issue.
Uploaded files from the module are serialized and DenyAll WAF or i-Suite can not unserialized php objects. The best way to protect a Drupal backend is to:
- Manage access to the upload form of the module by using the Web SSO or IP restrictions.
- Update the module to the latest version (Webform Multiple File Upload 7.x-1.4).