Security misconfiguration sildeshow

1. A5: SECURITY MISCONFIGURATION
Prepared By: Michel HAYEK & Salah KLAIMI

2. TABLE OF CONTENT
I. Introduction
II. Impacts
III. Causes
IV. Results
V. OWASP Top Security Misconfiguration
VI. Where does Security Misconfiguration happen
VII. How does Security Misconfiguration happen
VIII. Solutions and How to Protect Yourself
IX. Conclusion

3. WHAT IS SECURITY MISCONFIGURATION?
Application Misconfiguration attacks exploit configuration weaknesses found in web
applications.
Misconfiguration is define as configuration mistakes that results in unintended
application behavior that includes misuse of default passwords, privileges,
and excessive debugging information disclosure.
The effects of misconfiguration can be nonthreatening but also can lead service
outages, loss of sensitive data, and other serious problems.

4. OWASP RANKING
Top 10 2013-A5 Security Misconfiguration by OWASP
Top 10 2010-A6 Security Misconfiguration by OWASP
OWASP defines this risk as being easily exploitable, common in prevalence, easily
detectable, with moderate impact.

5. IMPACT
Partial or full data loss.
Data modification.
Compromise of full system.
Can be severe.
Expensive recovery.

6. STATISTICS

7. CAUSE: INADVERTENT USE OF DEFAULT
OPTIONS
Default options are always an easy target for hackers. It is very common that
users often do not change their default password or do not delete default
user ID.
Some applications come with default port number as well.
Examples: Oracle database default installation includes default user id and
password User/schema: scott, password: tiger and default port number
1521.

8. CAUSE: EXCESS DEBUGGING
INFORMATION
Revealing too much debugging information is a very common
misconfiguration problem. This usually does not result directly to
exploitation of a system.
Attackers can collect extra information, such as the internal working of an
application and version numbers.
Attackers can use this excessive debugging information to craft SQL to
perform a SQL injection attack. Also, when applications fail to
perform an action, they can leak sensitive information.

9. CAUSE: IMPROPER POLICY OR ROLE
CONFIGURATION
Role misconfiguration is another leading cause of web application
misconfiguration.
This causes groups or roles to access settings or records that were not
intended for them. There are many reasons for role
misconfigurations.
Complex business roles and polices can be blamed for role
misconfiguration. Example: allowing admin staff to view human
resource data.

10. CAUSE: HUMAN MISTAKES
Human mistakes are frequent and unavoidable and can account for up to
43% of all system failures.
Operator error is the main reason for downtime for large websites, such as
Google, MSN, and Yahoo. Proper interfaces and good design can
drastically reduce operator mistakes.
Poorly designed application interfaces and too tight restriction may force
user to attempt or bypass security then they need to accomplish a
goal.

11. RESULTS OF SECURITY
MISCONFIGURATION
Because of blindly trusting the default configuration settings, security
misconfiguration vulnerabilities can be of a varied nature. Attackers
may target default accounts, unused pages, unprotected files,
The default configuration may include unnecessary and unsafe features,
including known usernames and passwords, hard-coded backend
admin accounts and special access mechanisms for the developers
group.
It is useful to have such features during the development stage, but before
production roll-out, all such unsafe features must be identified and
deactivated in order to prevent any possibility of security
compromises in the future.

12. OWASP TOP SECURITY MISCONFIGURATIONS
OWASP has identified 8 most probable security misconfiguration target areas
that can be exploited by the hackers to compromise the security of web-based
environments. These are:
1. Unpatched security flaws in the server software.
2. Improper file and directory permissions.
3. Unnecessary services in enabled state.
4. Default accounts with their default passwords.
5. Exposure of administrative or debugging notifications to general users.
6. Misconfigured SSL certificates and encryption settings.
7. Misconfiguration of user roles.
8. Improper authentication with external systems.

13. WHERE?
Security misconfiguration may happen any of the following levels:
Operating system or platform
Web server
Application server
Database server
Framework
Custom code

14. HOW?:HIDDEN MANIPULATION
Often used to save users’ session without the need to maintain a complex
database on the server side.
In hidden manipulation users do not see or modify the hidden field.
Once hacked application acts according to the modified information not
according to the real data. Example: Alter product price or SKU
numbers.

15. HOW?:PARAMETER TAMPERING
Based on the manipulation of application parameter exchanged between
client and the server. This is a form of web based hacking where
certain parameters in the URL or web application page entered by a
authorized users that hackers change without users authorization.
Hackers take the advantage of hidden or fixed fields and modify
parameters by bypassing the security mechanisms.
Once hacked web application acts according to the modified information
and allows access to the users data. Example: Arbitrarily
manipulating user’s selection from a field values, such as; check box
or combo box.

16. HOW?:COOKIE POISONING
Act of manipulating or forging a cookie for the purpose of bypassing
security measures or sending false information to a server.
Cookies are common elements in web applications and their usage
involves saving information for instance; user ID, account numbers,
time stamp, passwords, etc. The saved information is stored in the
user’s hard drive.
Cookies are not cryptographically secure, therefore; a hacker can modify
users’ information by modifying the cookie file.

17. HOW?:STEALTH COMMANDING
Is a set of techniques allowing attackers to exploit parsing problems in
server-side scripts to change the code executed by the server.
Primarily used in the execution of operating system commands, allowing
complete takeover of the server.
Likely targets are server-side includes, parsed scripts, code that appears to
take input and turn it into OS commands, and anything that takes
parameters and turns them into parsed protocols.

18. HOW?:FORCED BROWSING
An attack where the aim is to enumerate and access resources that are not
referenced by the application, but are still accessible.
Attacker can use Brute Force techniques to search for unlinked contents in
the domain directory, such as temporary directories and files, and old
backup and configuration files.
Inadequate enforcement and authorization on all restricted URL,s scripts,
or files can be blamed.

19. HOW?:BACKDOORS AND DEBUG OPTIONS
Applications contain code left for debugging purposes, and some even
contain code left by disgruntled employees.
Debug options comprise entry points that allows a hacker access to the
application.
Backdoors substantially allow visitors to log into applications without
using a password and access grants users many other privileges.

20. AM I AT RISK?
Is your software out of date?
Any unnecessary features enabled?
Are default accounts and associated credentials unchanged?
Does error handling reveal stack traces to users?
Are the security settings not set to secure values?

21. SOLUTION: BASIC POLICIES
Do not use default credentials.
Avoid default installations.
Maintain consistency of configuration between versions.
Restrict default configuration options.
Avoid default port numbers.
Restrict roles and privileges.
Centralize configuration as much as possible.
Scans and audits.
Strong encryption.

22. SOLUTION: SECURE CODING AND CODE
REVIEW
Design application functionality with security in mind.
Extends development time.
Practice defensive coding.
Review codes to ensure security properties.
Stay up to date with coding standards compliance.
Consistent design and implementation.
Finding security issues/bugs early.

23. SOLUTION: SECURE CONFIGURATION AND
TESTING
Attention to detail .
Each component should be checked and verified.
Turn off unsafe features.
Remove default accounts and expire default passwords.
Stress testing.
Penetration testing.
Both automatic and manual testing.

24. SOLUTION: PATCHING AND EDUCATION
Keep applications up to date.
Apply vendor patches on time.
Apply critical security and vulnerability regularly.
Educate developers, administrators, and testers.
Participate security training.
 Attend security conferences.
Subscribe to vendor’s security alert.

25. HOW TO PROTECT YOURSELF
Bridge the gap between developers and administrators: The web
development team is not involved in the day-to-day operation. A
team system administrators are more likely to handle the operation
part. It may lead to a communication gap between those who built
the application and those who take care of the operational
responsibility. It's important to bridge this gap to ensure members
from both the groups are working as one single team to eliminate
any security vulnerability.
Well Defined Security Policies: Each web environment is unique in its
own way. So it's unlikely that a standard configuration would suit all
of them. Default configuration, in certain cases, may not be the
optimal choice. So the need of the hour is to find out what could be
the ideal security settings for a particular environment before
implementing and documenting the security policies.

26. HOW TO PROTECT YOURSELF
Securing Individual Modules & Components: All the components and
modules must be configured using different passwords. Besides, a strong
application architecture must be adopted which can provide effective and
secure separation between different components and modules.

27. SUMMARY
Risk: The prevalence of web application misconfiguration is very high in
IT industry.
Priority: Safeguarding web application from malicious users and attacks.
 Avoid: Security misconfiguration
Do’s : Follow IT security best practices, use common sense, have good
understanding of application security, practice good designing
principles and defensive coding, and as always ensure the proper
security configuration of application.

28. REFERENCES:
 Whitelegg, D. (2014, June 17). Scan your app to find and fix OWASP Top 10 2013 vulnerabilities. Retrieved September 17, 2014, from
http://www.ibm.com/developerworks/library/se-owasp-top10/index.html
 Auger, R. (2010, January 1). Application Misconfiguration. Retrieved September 15, 2014, from
http://projects.webappsec.org/w/page/13246914/ApplicationMisconfiguration
 Henneberger, D. (2012, January 1). Misconfiguration of Web Applications: A View of Security. Retrieved September 15, 2014, from
http://danielhenneberger.com/dist/papers/misconfiguration.pdf
 How Misconfiguration Can Leave You Vulnerable to Attackers - Calavista Software. (2014, January 1). Retrieved September 22, 2014,
from http://www.calavista.com/misconfiguration-can-leave-vulnerable-attackers/
 Pasho, A. (2011, June 22). Is Your Web Site or App Secure? Avoiding Security Misconfiguration. Retrieved September 20, 2014, from
http://blog.makingsense.com/2011/06/is-your-web-site-or-app-secure-avoiding-security-misconfiguration/

29. REFERENCES:
 Kerner, S. (2014, February 3). App Misconfiguration, Mobile Apps With Poor Encryption Pose Risks, HP. Retrieved September 23,
2014, from http://www.eweek.com/security/app-misconfiguration-mobile-apps-with-poorencryption-pose-risks-hp.html
 Misconfigurations: The Firewall’s Greatest Threat. (2012, December 3). Retrieved September 24, 2014, from
http://www.firemon.com/blog/firewall-management/misconfigurations-the-firewalls-greatest-threat
 Weldermariam, K. (2014, January 1). Early Detection of Security Misconfiguration Vulnerabilities in Web Applications.
Retrieved September 25, 2014, from
http://www.academia.edu/2719069/Early_Detection_of_Security_Misconfiguration_Vulnerabilities_in_Web_Applications
 Brady, P. (2014, January 1). PHP Security: Default Vulnerabilities, Security Omissions and Framing Programmers?. Retrieved
September 25, 2014, from
http://phpsecurity.readthedocs.org/en/latest/_articles/PHP-Security-Default-Vulnerabilities-Security-Omissions-And-
Framing-Programmers.html

30. REFERENCES:
 Statistics reference: http://securityaffairs.co/wordpress/16557/hacking/statistics-on-web-application-vulnerabilities-statistics-2013.html
 Reshef, E. (n.d.). Internet Application Security. Retrieved September 29, 2014, from http://www.cgisecurity.com/lib/IAS.pdf
 Cookie Poisoning. (n.d.). Retrieved October 1, 2014, from http://security.radware.com/knowledge-center/DDoSPedia/cookie-poisoning/
 Behringer, M. (n.d.). Understanding Operational Security. Retrieved September 24, 2014, from
http://www.cisco.com/web/about/security/intelligence/opsecurity.html
 Cookie Poisoning | Hacker4Lease. (2012, January 1). Retrieved October 1, 2014, from
http://www.hacker4lease.com/attack-methods/cookie-poisoning/
 Top 10 2013-A5-Security Misconfiguration. (2013, June 23). Retrieved September 14, 2014, from
https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration
 OWASP Top security misconfiguration: https://www.eurovps.com/blog/security-misconfiguration-owasp-6