OWASP TOP 10: Security Misconfiguration (#5)

OWASP is a non-profit organization with the goal of improving the security of software and internet. They have put together a list of the ten most common vulnerabilities, which we will cover one by one in this blogpost-series. This is the fifth post, and you will be able to find the rest byclicking here.

Description

The fifth vulnerability category on the list is called Security Misconfiguration. If a component is susceptible to attack due to an insecure configuration it would classify as security misconfiguration.This is considered the same vulnerability regardless if the misconfiguration happens in the web server, database or, for that matter, custom code.

Prevalence

As it is such a broad category it is very common vulnerability. A web application is built upon multiple layers, and making a configuration mistake in one of them is quite likely.

Potential impact

The impact varies and depends on the specific kind of misconfiguration. Atworst, it could lead to a full takeover, which means stolen sensitive data and expensive recover.

Exploitability

In many cases this is one of the easiest vulnerabilities to exploit. For example, if a system admin forgets to delete a default account with admin privileges, all an attacker has to do is to simply google the default credentials to login.

However, there can of course be more difficult alternatives of this vulnerability type that require more knowledge. All misconfigurations do not result in a possible full takeover, but may be used aspart of a bigger attack.

Well-known events

Werkzeug Debugger included a console, allowing a user to execute system commands. Some exposed that interface to the internet, which would result in an RCE (remote code execution). An example of this that has received a lot of attention is when we found this vulnerability at Patreon .

How to discover

The only way to discover security misconfigurationsis to start looking over the system.

Are any default accounts left, and if so, have thepasswords to those been changed? When it is possible to enforce better security in a framework, are those options chosen? Are there any unnecessary features installed/enabled that can be removed? Accounts, unnecessarily many privileges, ports, etc. As it is one of the most common issues; does the error handling reveal overly informative error messages to users? Example of vulnerable application

A great example that helps understand this issue is the aforementioned Patreon case. There is often some feature allowing debugging the system. If that is exposed towards the internet and not behind any authorization, any user could abuse it for their purpose.

Prevention Make sure everything is updated. Build the system in such way that software updates and patches can be deployed in a timely manner. Use the very same configuration for staging, production and developing environments. Inconsistencies are a common reason for the introduction of many misconfigurations. Automate what can be automated. Humans are good at making mistakes, and if the same setup procedure is performed often, it is better to make sure it is secure once and then just repeat it. Doing scans and/or audits regularly to discover future misconfigurations. When possible, configure the system with the thought in mind that the system will get compromised because that is very likely. In case of a security breach, an attacker should only be able todo very little damage. Read more

OWASP:

https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration

Our blog:

How Patreon got Hacked : Publicly Exposed Werkzeug Debugger

Author:

Linus Srud, Security Researcher

Twitter: @_zulln