False positives

Hi, I noticed that the plugin “Sensitive File Disclosure (HTTP)” always report the following message when I scan WHM/cPanel sites:

The following files containing sensitive information were identified (URL:Description):

https://IP/settings.py:Django Configuration File containing a SECRET_KEY or a username and/or password.

Also, the plugin “Database Open Access Vulnerability” report the following message for some hosts when the database actually protected:

Oracle MySQL can be accessed by remote attackers

Meanwhile, Django sites with verbose error messages usually contain credentials, but are not reported.

Hi,
Thanks for reaching out.

I noticed that the plugin “Sensitive File Disclosure (HTTP)” always report the following message when I scan WHM/cPanel sites

Do you mean the mentioned file is not reachable or that it doesn’t contain sensitive information?

Also, the plugin “Database Open Access Vulnerability” report the following message for some hosts when the database actually protected

Can you elaborate about what you mean with “protected”?
The more information you can give us the easier it is for us to investigate.

1 Like

Meanwhile, Django sites with verbose error messages usually contain credentials, but are not reported.

Can you give us some example of which URL(s) and if possible some example output? Thanks!

1 Like

It’s doesn’t contain sensitive information, just a login page. Some demo sites:

1 Like

Users can’t access the database without credentials, thus protected. I’m not sure what “Open access” means.

Can’t provide specific sites with password or sensitive information, but you can search for sites whose HTTP title is “DisallowedHost at /” (just an example of Django error pages with verbose error messages enabled), they will disclose source code, sensitive information. Passwords are obfuscated, but sometimes still in plaintext.

1 Like

Thanks a lot for providing this additional info.

The VT in question seems to have matched a part in the HTTP headers of the response while it should only have checked the body of the response. The routine of this VT has been updated to be more strict and to improve the response check in general, these changes should arrive in the feed in the next few days.

This shouldn’t be a false positive. The VT in question will report as long as a remote user can access and read out the version of the MySQL server remotely. This can be checked in the following VT:

Name: MariaDB / Oracle MySQL Detection (MySQL Protocol)
OID: 1.3.6.1.4.1.25623.1.0.100152

If the version was extracted in the related output of MariaDB / Oracle MySQL Detection (MySQL Protocol) then the VT Database Open Access Vulnerability will report as designed, if the access is blocked you would get a reporting like e.g. the following in MariaDB / Oracle MySQL Detection (MySQL Protocol):

Scanner received a ER_HOST_NOT_PRIVILEGED error from the remote MySQL/MariaDB server.
Some tests may fail. Allow the scanner to access the remote MySQL/MariaDB server for better results.

Please do note that this Database Open Access Vulnerability VT is doing “Log” level reporting without a severity so it is also more like a informative reporting. IIRC this was done like this because the scanner requires access to the remote system for remote vulnerability checks and to be able to determine the system remotely but in turn you would again get an additional vulnerability because access to the scanner was allowed on purpose.

This approach allows a user to decide what is more important, either allow access to the database by the scanner for MySQL vulnerability reporting or search for Systems which always allows access but should block it.

This sounds interesting, thanks a lot again for providing this info. I have raised an internal ticket to see if we can make something out of this.

2 Likes