[Security-news] Drupal file upload by anonymous or untrusted users into public file systems -- PSA-2016-003

[security-news at drupal.org]

View online: https://www.drupal.org/psa-2016-003

   * Advisory ID: DRUPAL-PSA-2016-003
   * Project: Drupal core [1]
   * Version: 7.x, 8.x
   * Date: 2016-October-10
   * Security risk: 20/25 ( Critical)
     AC:None/A:None/CI:Some/II:Some/E:Exploit/TD:All [2]

-------- DESCRIPTION
---------------------------------------------------------

Recently the Drupal Security Team has seen a trend of attacks utilizing a
site mis-configuration.
This issue only affects sites that allow file uploads by non-trusted or
anonymous visitors, and stores those uploads in a public file system. These
files are publically accessible allowing attackers to point search engines
and people directly to them on the site.  The majority of the reports are
based around the webform module, however, other modules are vulnerable to
this misconfiguration as well.

For example, if a webform configured to allow anonymous visitors to upload an
image into the public file system, that image would then be accessible by
anyone on the internet. The site could be used by an attacker to host images
and other files that the legitimate site maintainers would not want made
publicly available through their site.
-------- TO RESOLVE THIS ISSUE:
----------------------------------------------

   1) Configure upload fields that non-trusted visitors, including anonymous
      visitors, can upload files with, to utilize use the private file system
      [3].
   2) Ensure cron is properly running on the site. Read about setting up cron
      for  for Drupal 7  [4] or  or Drupal 8 [5]).
   3) Consider forcing users to create accounts before submitting content.
   4) Audit your public file space to make sure that files that are uploaded
      there are valid.

-------- AWARENESS ACKNOWLEDGMENT
--------------------------------------------

The Drupal Security Team became aware of the existence and exploits of this
issue because the community reported this issue to the security team [6]. As
always, if your site has been exploited, even if the cause is a mistake in
configuration, the security team is interested in hearing about the nature of
the issue. We use these reports to look for trends and broader solutions.
-------- COORDINATED BY
------------------------------------------------------

   * Michael Hess [7] of the Drupal Security Team
   * Damien McKenna [8] of the Drupal Security Team
   * Alex Pott [9] of the Drupal Security Team
   * David Snopek [10] of the Drupal Security Team
   * Greg Knaddison [11] of the Drupal Security Team
   * Cash Williams [12] of the Drupal Security Team

*This post may be updated as more information is learned.*
-------- CONTACT AND MORE INFORMATION
----------------------------------------

The Drupal security team can be reached at security at drupal.org or via the
contact form at  https://www.drupal.org/contact [13].

Learn more about the Drupal Security team and their policies [14], writing
secure code for Drupal [15], and securing your site [16].


[1] https://www.drupal.org/project/drupal
[2] https://www.drupal.org/security-team/risk-levels
[3] https://www.drupal.org/documentation/modules/file#access
[4] https://www.drupal.org/docs/7/setting-up-cron/overview
[5] https://www.drupal.org/docs/8/setting-up-cron/overview
[6] https://www.drupal.org//www.drupal.org/node/101494”
[7] https://www.drupal.org/u/mlhess
[8] https://www.drupal.org/u/damienmcKenna
[9] https://www.drupal.org/u/alexpott
[10] https://www.drupal.org/u/dsnopek
[11] https://www.drupal.org/u/greggles
[12] https://www.drupal.org/u/cashwilliams
[13] https://www.drupal.org/contact
[14] https://www.drupal.org/security-team
[15] https://www.drupal.org/writing-secure-code
[16] https://www.drupal.org/security/secure-configuration