Security Misconfiguration

Sunday, 12 August 2018

Security Mis-configuration
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date

Server configuration problems
> Unpatched security flaws in the server software
> Server software flaws or misconfiguration that permit directory listing and directory traversal attacks
> Unnecessary default, backup, or sample files, including scripts, applications, configuration files, and web pages
> Improper file and directory permissions
> Unnecessary services enabled, including content management and remote administration
> Default accounts with their default passwords
> Administrative or debugging functions that are enabled or accessible
> Overly informative error messages (more details in the error handling section)
> Misconfigured SSL certificates and encryption settings
> Use of self-signed certificates to achieve authentication and man-in-the-middle protection
> Use of default certificates
> Improper authentication with external systems

All about => Insecure-direct-object-references
Critical Vulnerability => Sql-injection-attack-and-defense-notes

** Do security hardening
1) Configuring all security mechanisms
2) Turning off all unused services
3) Setting up roles, permissions, and accounts, including disabling all default accounts or changing their passwords
4) Logging and alerts
5) Monitoring the latest security vulnerabilities published
6) Applying the latest security patches
8) Updating the security configuration guideline
9) Regular vulnerability scanning from both internal and external perspectives
10) Regular internal reviews of the server’s security configuration as compared to your configuration guide
11) Regular status reports to upper management documenting overall security posture

Security Misconfiguration Cases
Case 1 :
Your application relies on a powerful framework like Struts or Spring. XSS flaws are found in these framework components you rely on. An update is released to fix these flaws but you don’t update your libraries. Until you do, attackers can easily find and exploit these flaws in your app.

Case 2 :
The app server admin console is automatically installed and not removed. Default accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over

Case 3 :
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 attackers reverse engineers to get all your custom code. Attacker then finds a serious access control flaw in your application.

Case 4 :
App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information error messages provide.

All about => Insecure-direct-object-references
Critical Vulnerability => Sql-injection-attack-and-defense-notes

Exploit  1:
We can try out as many options as we can think of. All we need to find the URL of config file and we all know developers follow kind of naming convention for config files. It can be anything that is listed below. It is usually done by BRUTE force technique.


Exploit 2: 
Error Handling

There are quite a few different ways to handle errors in ASP.NET MVC and Web API, whether through error handlers, filters and overrides, as well as granular application of error handling at the action or controller level. But, very likely you have experienced those edge cases where some exception has managed to bubble up past your custom control gates unhandled and you have experienced a error message

Exploit 3:
URL redirection