A misconfiguration is exactly what it sounds like; something that is wrongly configured. From a security perspective this can be either fairly harmless, or in the worst case devastating. We have written about misconfigurations before, both here and here.
Misconfigurations may derive from many different reasons, such as:
- A user or developer has changed a setting in the application without knowing about the security impact.
- A developer has configured an installed web application or system incorrectly by not following the security guidelines.
- A developer has unconsciously left files or webpages with potentially sensitive information, open for the public to access.
Hackers often exploit misconfigurations, since this can have a huge security impact. Furthermore, misconfigurations could be the last resort for hackers, since the application may follow good security standards, but because of the way it has been [mis]configured, it could be vulnerable and an easy way in.
The “good” thing about misconfigurations is that they can just as easily be fixed by simply configuring them differently to remediate the security vulnerability.
Below are examples of the most common misconfigurations.
Default credentials
When installing a new web application, you often get the option to set your own username and password. However, in many cases the web application has already done that for you. This could be the reason for showcasing a demo or simply just to speed up the installation process.
Hackers often take this as an opportunity to break into systems. Documentation, guides and even collected lists exist with different products and their default credentials.
The impact of having default credentials may vary depending on the privileges the user has in the system, but either way an attacker may pivot and find other attack vectors whilst being authenticated.
One way to check whether your web application has any default credentials is by googling the product added by “default credentials”. If you find any search results you can try them against your own system and see if the credentials are valid, and if so remove the user from the system if it’s not in use.
Information disclosure
Information disclosure varies in severity based on the information that is disclosed. In some cases it may be an error message containing the full path to the script, and in other cases it may be very sensitive data such as PII or passwords/tokens. Either way the cause often the same; a misconfigured system that leaks data that shouldn’t be disclosed.
One way for this to happen is that the application is set to run in a development or debug environment in production. When an application uses the development setting, it will print out error and debug messages, and those may contain information such as HTTP requests with included cookies, database queries and more.
One recent example is a debugging tool called Telescope which is part of Laravel. The default environment setting is “local” for Laravel, and if users didn’t change this before production, attackers could access the Telescope dashboard without any authentication and view HTTP requests and database queries.
File disclosure
A common mistake is to leave files accessible for the public. This could be files created by other programs that a developer may use, or a web application creating log files. Either way these files may contain sensitive data, and it is important not to leave these files accessible.
Our Crowdsource hacker Sebastian Neef wrote about WordPress plugins created log files that anyone could view. Many of those log files contained credentials, email addresses, usernames and information about the system.
Conclusion
Fixing misconfigurations can be tricky because they are often due to human errors. The best thing is to have good routines when configuring and setting up new web applications to make sure that the settings are as intended and that they won’t have any negative impact on the security. Furthermore, it’s important to continuously check your assets for potential misconfigurations. Detectify can find many different types of misconfigurations in several products found by our Crowdsource community.
Keeping up with the fast-pace of web security is a challenge if you are only relying on standard CVE libraries and annual security checks. Detectify works with some of the best ethical hackers in the world to deliver security research to check for security misconfigurations and more, so you can stay on top of emerging threats. Interested in giving Detectify a go? Start your 14-day free trial today.