SamJoan / droopescan

A plugin-based scanner that aids security researchers in identifying issues with several CMSs, mainly Drupal & Silverstripe.
GNU Affero General Public License v3.0
1.27k stars 249 forks source link

Added checks for exposed Drupal configuration files #24

Closed the-bumble closed 6 years ago

the-bumble commented 6 years ago

Hi!

I added a few "interesting" URLs to the Drupal plugin. During a recent pentest, we found that the client had misconfigured these sensitive files with read permissions. Thought these would be worthwhile to add to droopescan.

Thank you!

Jake

SamJoan commented 6 years ago

Hi there

This looks good! When I have time I'll fix the failing test and merge. Out of curiosity, what kind of information did you obtain from the .php files?

the-bumble commented 6 years ago

Awesome! Thank you for the help with the test case :) Haha, I was having some trouble with that. Here are some brief descriptions of the proposed "interesting" files:

sites/default/settings.php This file contained the database password for the Drupal installation, which we used to access the client's MySQL database. The file can also contain proxy credentials/configuration, salts used for token generaton, and more: https://github.com/drupal/drupal/blob/8.6.x/sites/default/default.settings.php

sites/sites.php This files lists alternative VHOSTs or aliases that are being used with the Drupal site. Disclosure of this file could provide attackers with hidden alternate versions of the Drupal site.

sites/default/services.yml Site-configuration options, such as CORS configuration and template debug configuration. This file could provide additional information to an attacker.

SamJoan commented 6 years ago

Hi there,

The reason I ask is that PHP files are not normally served to an attacker, and when making a request to a php url what you will normally get is a blank file. Services.yml however seems like a goldmine, I'll look into merging it in for sure.

the-bumble commented 6 years ago

True, this would be the result of a misconfigured installation. Our case was a defunct instance that shared common credentials with other live instances.

That said, I wonder if there would be value in performing a quick check for the file and common editor suffixes:

settings.php settings.php.bak
settings.php.dist
settings.php.old
settings.php.save
settings.php.swp settings.php.swo
settings.php.txt
settings.php~

There are number of defunct/misconfigured sites that serve up the settings.php file or variants suffixed with editor extensions: https://www.google.com/search?q=inurl:sites/default/settings.php+-git&num=100&filter=0

It might be a shot in the dark, but given that it could lead to full CMS compromise, it might be worth the check. At this time these checks aren't implemented for Drupal in any major wordlist (I checked FuzzDB, Seclists, and dirsearch).

Curious for your thoughts

Thank you!

SamJoan commented 6 years ago

Hi @the-bumble

Sorry I dropped the ball on this one. I have been super busy lately but I am about to release a new version of droopescan when I have a time to make an update to CMS versioons.

I think it's a brilliant idea. Absolutely think it would be good to implement.