This vulnerability tests tries to verify if your MSSQL server uses default, known, or weak credentials. It also relates to CVE-2021-33583 and CVE-2024-6912.
How does it work?
The test tries to find a system with MSSQL first. Then it will try to login with a number of known default credentials. To avoid account lockouts, the test will only try 2 passwords for each tested account.
If you've disabled brute force checks, this test will not run.
The test establishes a TCP connection to the MSSQL server.
It sends crafted login packets using each credential pair and waits for a response.
If the response indicates a successful login, the test flags the server as vulnerable and logs the credentials used.
If no vulnerabilities are found or the maximum threshold for accounts is reached, the test stops.
How False Positives can occur
Shared Accounts with Common Credentials:
An organization may intentionally configure an account with a default username/password (e.g.,
sa:sa) for integration or testing purposes. The script may flag this as a vulnerability even if it is intentional and access to the server is otherwise secure.
Intermediary Devices or Misconfigured Proxies:
If a network device like a proxy server or intrusion detection/prevention system (IDS/IPS) is misconfigured, it might respond to login attempts in a way that mimics a successful connection.
Mismatched Protocol Versions:
The script relies on specific MSSQL packet formats. If the server uses a non-standard or custom implementation of MSSQL that gives unexpected responses, the script might misinterpret them as successful logins.
Account Lockout Policies with Delayed Actions:
If the MSSQL server has a lockout policy with delayed enforcement (e.g., accounts are locked after a short delay instead of immediately), the test might interpret this delay as a successful login.
False Responses in Multi-Service Scenarios:
If the detected port (e.g., 1433) is running a different service or an application mimicking MSSQL responses, the script might flag it as vulnerable.
Mitigating False Positives
To reduce the likelihood of false positives:
Verify Results: Cross-check successful logins manually using the flagged credentials.
Validate the Environment: Ensure that the tested MSSQL instance is the intended target and not another service on the same port.
Accept Vulnerability: If you've verified the vulnerability is not present, mark the vulnerability as accepted and comment it as a false positive which got manually verified by you.