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.
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.
So I think the descriptions of the VT should be updated.
I misunderstood that Open Access means not protected by credentials.
The tag impact says Successful exploitation could allow an attacker to obtain the sensitive information of the database., but exploit which vulnerability, sensitive information of database or DBMS?
The tag insight says Do not restricting direct access of databases to the remote systems., sounds like a recommendation.
There seems to be indeed quite a lot room for improvements and also misunderstandings in the description of that VT, thanks a lot for collecting these points
While this VT wasn’t created by Greenbone but by a 3rdparty contributor i still have raised an internal task to review and possible improve the text to avoid such confusion. It might take a while though as the VT in question is more informative, having a community provided patch might speed up the process.
One additional note:
I misunderstood that Open Access means not protected by credentials.
In that case it would have a high severity, not a “log level” one as this would indeed poses a high risk on the database.
