Closed the-bumble closed 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?
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.
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.
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!
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.
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