Hello Readers, I will be updating the vulnerabilities description according to the bugcrowd taxanomy . I will be giving tips how to test also. Also please provide your comments/suggestions to update this in proper way. This is collecting resources from various posts and putting at one place
P1 Vulnerability- Using Default Credentials
Vulnerability Category: Security Misconfiguration
Vulnerability Description: Web applications often make use of popular open source or commercial software that can be installed on servers with minimal configuration or customisation by the server administrator. Often these applications, once installed, are not properly configured and the default credentials provided for initial authentication and configuration are never changed. These default credentials are well known by penetration testers and, unfortunately, also by malicious attackers, who can use them to gain access to various types of applications.
Impact: An attacker take control of the application / application server.
Severity: Critical
CVSS v3.0 Score:9.8
CVSS v3.0 Vector:CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Recommendation: Change the default passwords for the application/application servers and admin portals.
How to test:
● Try the following usernames — “admin”, “administrator”, “root”, “system”, “guest”, “operator”, or “super”. These are popular among system administrators and are often used. Additionally you could try “qa”, “test”, “test1”, “testing” and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you manage to successfully identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following “password”, “pass123”, “password123”, “admin”, or “guest” with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
● Application administrative users are often named after the application or organization. This means if you are testing an application named “Obscurity”, try using obscurity/obscurity or any other similar combination as the username and password.
● When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords. Customer email addresses mail reveal the user accounts naming convention: if employee John Doe has the email address jdoe@example.com, you can try to find the names of system administrators on social media and guess their username by applying the same naming convention to their name.
● Attempt using all the above usernames with blank passwords.
● Review the page source and JavaScript either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example “If username=’admin’ then starturl=/admin.asp else /index.asp” (for a successful log in versus a failed log in). Also, if you have a valid account, then log in and view every request and response for a valid log in versus an invalid log in, such as additional hidden parameters, interesting GET request (login=yes), etc.
● Look for account names and passwords written in comments in the source code. Also look in backup directories for source code (or backups of source code) that may contain interesting comments and code.
Tools to Test:
- Use Jobert Abma Virtual host discovery tool to find virtual hosts and check for login portals on the target .
Link: https://github.com/jobertabma/virtual-host-discovery
2. Also use knockpy, aquatone and sublist3r to enumerate more subdomains and look out for login portals.
Link: https://github.com/guelfoweb/knock
