EU Regulating InfoSec: How Detectify helps achieving NIS 2 and DORA compliance
**Disclaimer: The content of this blog post is for general information purposes only and is not legal advice. We are very passionate about cybersecurity rules and …
Misconfigurations may derive from many different reasons, such as:
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.
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 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.
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.
**Disclaimer: The content of this blog post is for general information purposes only and is not legal advice. We are very passionate about cybersecurity rules and …
TLDR: This article details methods and tools (from DNS records and IP addresses to HTTP analysis and HTML content) that practitioners can use to classify …