Give yourself the best-case, imaginary scenario. You’ve joined the Drupal Security Team and you’re the first to get notified about vulnerabilities in both core and contributed Drupal modules. You take advantage of your position on the security team to patch your Drupal websites before the exploit notifications and patches are released to the general public at-large.
Unfortunately, attackers don’t necessarily report vulnerabilities to the Drupal Security Team. Some groups exploit vulnerabilities for profit. You may also find yourself faced with an angry, former customer or a competitor that doesn’t have any interest in reporting vulnerabilities and would rather just deface your website.
Don’t arm your adversaries with everything they need to attack you.
Go back to that best case scenario. Even if your website is fully patched, knowing that you run the latest version of Drupal still tells the attacker that if they download the latest Drupal release and comb through the code, that is where they’ll find their exploit. Imagine instead, your attacker isn’t exactly sure whether your website runs Drupal, Wordpress, Joomla, Backdrop, or Plone and they needed to download the source code to each to research new vulnerabilities. Albeit, this outcome isn’t entirely realistic, but it’s a goal to work towards.
Use a more realistic example, the SA-CORE-2014-004 - Drupal core - Denial of service of August 6, 2014, which created a zero-day vulnerability for any Drupal 6 or 7 site, and many Wordpress sites. The XML exploit was already a known XML bomb from other software platforms, so within hours, videos were posted about how to exploit the DoS. Since all Drupal and Wordpress implementations were vulnerable, roughly 23% of the Internet could be DoSed!.
A default installation of Drupal showers visitors with all sorts of signals about what software is running your website. By arming your adversaries with the name of your CMS (Drupal), you eliminate a bunch of reconnaissance and homework that would be required to narrow down either using a known vulnerability or researching the source code to find a new one. With a vulnerability like SA-CORE-2014-004 and your website is a critical part of your business, you shouldn’t broadcast to any anonymous visitor that you use Drupal and what version.
Nessus has a plugin used just to detect the use of Drupal.
Drupal, whether downloaded as a zip, tarball, or through git, includes a CHANGELOG.txt in the root directory. The CHANGELOG.txt file clearly identifies the version of Drupal running on your server.
The start of the Drupal 7.32 CHANGELOG.txt looks like the following excerpt:
Drupal 7.32, 2014-10-15 ---------------------- - Fixed security issues (SQL injection). See SA-CORE-2014-005. Drupal 7.31, 2014-08-06 ---------------------- - Fixed security issues (denial of service). See SA-CORE-2014-004. Drupal 7.30, 2014-07-24 ----------------------- - Fixed a regression introduced in Drupal 7.29 that caused files or images attached to taxonomy terms to be deleted when the taxonomy term was edited and resaved (and other related bugs with contributed and custom modules). - Added a warning on the permissions page to recommend restricting access to the "View site reports" permission to trusted administrators. See DRUPAL-PSA-2014-002. - Numerous API documentation improvements. - Additional automated test coverage. Drupal 7.29, 2014-07-16 ---------------------- - Fixed security issues (multiple vulnerabilities). See SA-CORE-2014-003.
Guardr has a rolling issue for each core release to update a patch that removes the CHANGELOG.txt file for every build of the distribution. The removal of CHANGELOG.txt is a controversial topic, even within the Guardr maintenance team.
By default, Drupal inserts some additional tags in HTML output. One such tag identifies Drupal as the generator of the page
<meta name="generator" content="Drupal 7 (http://drupal.org)" />
When caching is enabled to cache pages for anonymous users, on admin/config/development/performance in Drupal 7, Drupal sends an additional HTTP header named X-Drupal-Cache. The header can be used to identify a site as using Drupal. Disabling the anonymous page caching is the only configuration-based method to prevent the header from being sent. Otherwise, editing the source code in Drupal 7’s bootstrap.inc to remove a direct header() call is required.