A6 Security Misconfiguration (2017)

A6-Security Misconfiguration

DESCRIPTION:

It is the Sixth most critical web application security risk according to OWASO Top ten lists (2017).

If a component is susceptible to attack due to an insecure configuration it would classify as security misconfiguration. It is nothing but incorrectly assembling the safeguards of the web application. Such risks occur when holes are left open in the framework by the developers, DBAs or the administrator. This can occur at any level such as web server, application server, platform, database, custom code or frameworks etc. Attackers can easily find these vulnerabilities through default accounts, un-patched flaws, unprotected files, directories, unused web pages and many more.

Good security requires a secure configuration defined and deployed for the application, web server, database server, and platform. It is equally important to have the software up to date.

In my experience, web servers and applications that have been misconfigured are way more common than those that have been configured properly. 

Let’s see some examples:

1.Running the application with debug enabled in production.

Following figure is an example of the ASP.NET Runtime error coming from a web application with debug mode enabled.

Debug mode can reveal some detailed information about the system, eventually helping an attacker to find a weak point or to exploit and compromise the system. That’s the main reason for disabling it in a production environment.

Debug mode is disabled by default.

2.Directory listing is enabled on the server, which leaks valuable information.

What is directory listing?

Directory listing is a web server function that displays a list of all the files when there is not an index file, such as index.php and default.asp in a specific website directory.

 Directory listing is not disabled on your server. Attacker discovers she can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which she decompiles and reverse engineers to get all your custom code. She then finds a serious access control flaw in your application. 

3.Running outdated software (think WordPress plugins, old PhpMyAdmin).

4.Unnecessary services running on the machine.

5.Not changing default keys and passwords. (Happens way more frequently than you’d believe!)

6.Revealing error handling information to the attackers, such as stack traces.

Prevention:

Security misconfiguration is very easily exploitable but there are number of ways to prevent them. The developers should work with the administrators to make sure that the stack is properly configured.

Following are some of the recommendations for the industry experts:

Reduce the surface of the vulnerability with a repeatable process

Make sure everything is updated. Build the system in such way that software updates and patches can be deployed in a timely manner.

Disable all the default accounts and change passwords regularly.

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 to do very little damage.

Develop strong app architecture and encrypt data which has sensitive information.

Make sure that the security settings in the framework and libraries are set to secured values.

Perform regular audits and run tools to identify the holes in the system

  

NOTE:Information showing on this blog is only use for educational purpose.