OWASP Top 10 in 2021: Security Misconfiguration Practical Overview

Security Misconfiguration is #5 in the current OWASP Top Ten Most Critical Web Application Security Risks. Misconfiguration can include both errors in the installation of security, and the complete failure to install available security controls.

Application Security Series
Monday, March 22, 2021

An April 2018 report from IBM noted some interesting changes in security trends over 2017. One of the key points was the skyrocketing rate of poorly-configured cloud infrastructure. The report estimated that breaches related to bad configuration jumped by 424%, accounting for nearly 70% of compromised records over the year. While data security is growing more sophisticated and best practices for preventing breaches grows more refined, simple human error is becoming a bigger and bigger problem. These human errors lead to security misconfiguration, ranked #6 in OWASP's 2017 list of application security risks.

Do you want to have an in-depth understanding of all modern aspects of
Security Misconfiguration?
Read this article and bookmark it to get back later, we regularly update this page.

IBM reports that breaches related to bad configuration jumped by 424% in 2018, accounting for nearly 70% of compromised records over the year.

What is the Security Misconfiguration risk?

Badly configured app-security can come in many different forms. Misconfigurations can occur in a developer's own code, in the code of pre-made features and functions, or through the API. They can appear in the app itself, in the servers and databases used by the app, or in resources used during the development process. Any level of an organization’s application stack can manifest a configuration flaw, and the more layers there are the greater the chances for a mistake leading to a vulnerability.

Firewalls, for example, are frequently misconfigured by their users. Policies can be left too broad, effectively leaving the network permanently exposed. Test systems may not be properly firewalled from production systems; and the basic principal of least privilege is not always enforced.

As an application grows in scope, it becomes more difficult to keep security configurations tight and effective. This becomes a bigger problem if the application includes unnecessary or unused features. This might be caused by things like unnecessary ports being enabled from the development cycle, default accounts not being properly removed, and so on. If these unused features are left in, they will likely be ignored or at least poorly maintained, giving attackers greater potential to discover vulnerabilities.

Security vulnerabilities can be exposed from unexpected places. Error messages may contain clues for attackers if they're improperly handled. Leftover code and sample applications from the development process may contain known vulnerabilities, allowing attackers to gain access to the application server. When not properly configured, debugging information like these error messages and detailed stack traces, vital to the developer, can become weapons in an attacker's hand.

However, as adoption of cloud storage options has grown, a more simple but devastating security misconfiguration has moved centre stage: failure to lock down access to data stored in internet-facing storage devices. People seem to assume that any third-party involved will provide the security – which is generally not true.

In 2017, Accenture left 137 Gb of data, including 40,000 plaintext passwords, hashed passwords, access keys for the enStratus cloud infrastructure management platform, email data, and information on the consulting firm’s ASGARD database, exposed on an AWS S3 bucket.

Also in 2017, Viacom left sensitive company data exposed in an S3 bucket, including the passwords and manifests for Viacom’s servers. The access key and secret key for the corporation’s AWS account were similarly stored in the repository.

This misconfiguration issue can also occur on private servers that use third-party software. Earlier this year, data broker Exactis exposed a massive database of personal information about 218 million individuals, 110 million households and 21 million companies. The database was front-ended by Elasticsearch, but no access control was deployed.

Companies need to recognize that they are always responsible for their data wherever and however it is stored.

The solution to this type of misconfiguration is relatively simple – companies need to recognize that they are always responsible for their data wherever and however it is stored. It is their own responsibility to secure it – often with authentication controls provided by the third-party.

The effect of Security Misconfigurations

Misconfigured security can stem from very simple oversights, but can leave an application wide open to attackers. In some cases, misconfiguration can leave data exposed without any need for an active attack by malicious agents. In October 2014, security journalist Brian Krebs reported a vulnerability in the website of MBIA Inc., America's largest bond insurer. Because of a misconfigured database server, search engines had indexed hundreds of pages of user account statements, making the data easily accessible via a simple web search. This also included a page of administrator credentials, meaning an attacker could have accessed even more data on the company's servers that had not been indexed by search engines.

In the earlier examples of misconfigured – or in this case absent – security controls on storage devices, massive amounts of personal and sensitive data were exposed to everyone on the internet. There is often no way of knowing who may have accessed this data before it was protected.

The more data and code exposed to users, the greater the risk for app security. Directory listing in particular is a problem with many web applications, especially those based on pre-existing frameworks such as WordPress. If users can freely access and browse the file structure, it gives them ample time to find security exploits.

Failure to properly lock down access to an app's structure can even give attackers the opportunity to reverse-engineer or even modify parts of the application. This can be difficult to control if an application is intended for delivery to mobile devices. As OWASP's page on preventing reverse engineering says:

Failure to properly lock down access to an app's structure can even give attackers the opportunity to reverse-engineer or even modify parts of the application.

“In making the switch to mobile applications, organizations are now deploying more of the presentation layer and business layer of the application on a phone instead of on their own servers. As a result, they lose a lot more control over who gets to see or modify their application’s code.”

Solutions

Security misconfiguration stems from human error, rather than general weaknesses in protocols or common attack vectors. This means that a well-structured development and update cycle, if properly implemented, will reliably counteract this risk. A repeatable process should be put in place to secure and test the application during development, on the deployment of any new features, and when any component is updated or changed. Attention to compliance will provide good guidelines for security configurations, such as the NIST guidelines on keeping servers secured.

High Tech Bridge CEO Ilia Kolochenko comments on the importance of penetration testing to find misconfigurations: “It’s very important to properly integrate penetration testing into all other business processes – we need to thoroughly plan what to test, how to test and when to test. Afterwards, we also need a process to make sure that all the detected vulnerabilities were properly patched. Last but not least, people responsible for the vulnerabilities detected need to revise their procedures to avoid similar flaws and misconfigurations in the future.”

App developers should keep applications efficient, using as few components and frameworks as possible to achieve the required functionality. Feature-creep increases the likelihood of misconfiguration. A segmented approach should be taken with the app architecture, and strong hardening techniques should be integrated into the development cycle. As much as possible, this app-hardening should be repeatable and automated. A 2014 report by Gartner suggested that automated and self-testing application hardening would be the way forward, estimating that 25% of web and cloud applications will self-protect in this way by 2020.

Gartner suggests that automated and self-testing application hardening would be the way forward, estimating that 25% of web and cloud applications will self-protect in this way by 2020.

Fortunately, most security misconfiguration risks are known and documented. This means automated testing resources are especially useful for detecting this kind of problem, especially if the testing tools are well-integrated into the development plan. High-Tech Bridge's ImmuniWeb is a great place to start finding and eliminating web application misconfigurations.

Application Security Series Latest news and insights on AI and Machine Learning for application security testing, web, mobile and IoT security vulnerabilities, and application penetration testing.