OWASP Top 10: Security Misconfiguration

Welcome to Secumantra! In this post, we’re going to talk about the number six vulnerability from OWASP Top Ten – Security Misconfiguration. We have already covered top five vulnerabilities in our previous posts – injection, broken a uthentication , sensitive data exposure, XML external entities and broken access control.

OWASP (Open Web Application Security Project) is a nonprofit foundation that works to improve the security of software. OWASP Foundation is globally recognized by developers as the first step towards more secure coding. It releases OWASP Top Ten list every 2-3 years sharing the most critical security risks to modern web applications.

What is Security Misconfiguration?

Security misconfiguration has different aspects and it depends on a specific context. It happens when we fail to implement all the security controls for a server or web application, or implement the security controls in a wrong way.

In short, security misconfiguration happens when the responsible party fails to follow best practices when configuring an asset. This asset can be an operating system, a web server, software running on a machine, etc.

Security misconfigurations don’t affect web assets only. Any component which requires a configuration is subject to this vulnerability. This means that network devices, hardware, email services, etc. can suffer from this vulnerability.

Security misconfigurations can happen at various points across the application stack. So it could be at the web server or at the application server or framework or at some point in custom code.

Some of the most common misconfigurations in traditional data centers include default configurations that have never been changed and remain insecure, incomplete configurations that were intended to be temporary, and wrong assumptions about the application expected network behavior and connectivity requirements.

In today’s hybrid data centers and cloud environments, and with the complexity of applications, operating systems, frameworks and workloads, this challenge is growing. These environments are technologically diverse and rapidly changing, making it difficult to understand and introduce the right controls for secure configuration.

How to Detect Security Misconfiguration?

The application might be vulnerable if the application is:

Missing appropriate security hardening across any part of the application stack, or improperly configured permissions on cloud services.
Unnecessary features are enabled or installed (e.g. unnecessary ports, services, pages, accounts, or privileges).
Default accounts and their passwords still enabled and unchanged.
Error handling reveals stack traces or other overly informative error messages to users.
For upgraded systems, latest security features are disabled or not configured securely.
The security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values.
The server does not send security headers or directives or they are not set to secure values.
The software is out of date or vulnerable (see Using Components with Known Vulnerabilities).

Without a concerted, repeatable application security configuration process, systems are at a higher risk.

Examples – Attack Scenarios

The application server comes with sample applications that are not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. If one of these applications is the admin console, and default accounts weren’t changed the attacker logs in with default passwords and takes over.
Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application.
The application server’s configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws such as component versions that are known to be vulnerable.
A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed.

Prevention

Secure installation processes should be implemented, including:

A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to setup a new secure environment.
A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
A task to review and update the configurations appropriate to all security notes, updates and patches as part of the patch management process (see Using Components with Known Vulnerabilities). In particular, review cloud storage permissions (e.g. S3 bucket permissions).
A segmented application architecture that provides effective, secure separation between components or tenants, with segmentation, containerization, or cloud security groups (ACLs).
Sending security directives to clients, e.g. Security Headers.
An automated process to verify the effectiveness of the configurations and settings in all environments.

OWASP Risk Rating

Let us take a look at the OWASP overview and risk rating –

Threat agents are pretty broad, considering external attackers as well as people who might actually have accounts in the system. All these are possible threat actors for security misconfiguration. Exploitability is easy and broad range of possible attack vectors exist. For example, default accounts, unused pages, unwanted open ports etc. There are many ways a security misconfiguration can be exploited.

There is no single thing which we can point at as security misconfiguration, rather a broad range of individual discrete risks. When we look at the security weaknesses, we can see that prevalence is common but the detectability is also easy. There are lots of different points where the risk of security misconfiguration may be present.

A6:2017-Security Misconfiguration (source – OWASP)

As detectability is quite easy, we can use automated tools to detect common security misconfiguration risks. It helps us a little bit in the mitigation. OWASP classifies the technical impact as moderate and business impact will depend on the type of data to be protected.

Generally, security misconfiguration leads to sensitive data exposure. We have seen that in the previous post. This opens the door to impact on Confidentiality, Integrity and Availability, depending on the context.

Summary

Security misconfiguration is the most common vulnerability. This is commonly a result of insecure default configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information.

Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion. Removing any unused features, making error messages more general, dynamic application security testing could help mitigating this risk .

When securing your applications against any critical vulnerability (specially from OWASP Top Ten), it is always a good practice to follow defense in depth strategy.

Thank you for reading. Stay Safe, Stay Secure!