Don t Get Burned! Are you Leaving your Critical Applications Defenseless?

Transcription

1 Don t Get Burned! Are you Leaving your Critical Applications Defenseless? Ed Bassett Carolyn Ryll, CISSP Enspherics Division of CIBER

2 Presentation Overview Applications Exposed The evolving application security threat Shortcomings of perimeter security Challenges faced Strategy for effective protection Securing Applications to Protect Data Design in vs. bolt on

3 Web-Based Applications Under Attack All the organizations covered by this year s survey experienced some Web site incidents» Source 2004 Computer Crime and Security Survey, Computer Security Institute with the participation of the San Francisco Federal Bureau of Investigation's (FBI) Computer Intrusion Squad

4 Evolving Threat Application security mechanisms are generally the arbiter of data access Less reliance on network, operating system, and database controls Successful attacks more likely to result in access to valuable data/transactions More use of packaged applications, standardized development platforms Attackers can develop attacks with widespread utility Path of least resistance Applications are visible, accessible Many applications are not very well secured

5 Perimeter Controls What about perimeter controls? Largely block network vulnerabilities Example: HTTP requests are able to sail past firewalls, filters, platform hardening, and intrusion detection systems Attacks are inside legal HTTP requests Attacker can tamper with the URL, query string, headers, cookies, form fields, hidden fields to bypass security mechanisms Some of these attacks are buffer overflows, code injection, SQL injection, command insertion, cookie poisoning, hidden field manipulation, format string attacks, and cross site scripting Even SSL secured Websites accept the requests without scrutiny.

6 Perimeter Controls Application code is part of the security perimeter As number, size, and complexity of applications increase, so does perimeter exposure Case study demonstrates one organization that produces hundreds of applications per year Without a proper application security focus, perimeter security is extremely hampered Initial incident, weak access controls Zero traceability.

7 But I Have A Firewall Perimeter security devices do a good job stopping other things but are largely transparent to application attacks Application protocols (usually HTTP, HTTPS) are used for valid access, so are passed by the firewall Applications generally can be accessed from any source address Most applications encrypt sensitive transactions using SSL so firewall cannot see contents of transaction The nomenclature of application requests is not known by the firewall Request to log in remotely telnet://webserver.xyz.com STOP Firewall recognizes that telnet is the wrong protocol and blocks access

8 But I Have A Firewall Perimeter security devices do a good job stopping other things but are largely transparent to application attacks Application protocols (usually HTTP, HTTPS) are used for valid access, so are passed by the firewall Applications generally can be accessed from any source address Most applications encrypt sensitive transactions using SSL so firewall cannot see contents of transaction The nomenclature of application requests is not known by the firewall Request to application Firewall recognizes HTTPS as an approved protocol and allows access Details of request are encrypted with SSL Firewall cannot tell if request is valid or malicious

9 But I Have An Intrusion Prevention System These devices typically look for Attack Signatures Many web server attacks and some application attacks can be detected and blocked by IPS Attacks in an SSL connection are not visible to the IPS because they are still encrypted Web server attack common_attack_signature STOP IPS recognizes the attack signature and blocks access

10 But I Have An Intrusion Prevention System These devices typically look for Attack Signatures Many web server attacks and some application attacks can be detected and blocked by IPS Attacks in an SSL connection are not visible to the IPS because they are still encrypted Encrypted web server attack common_attack_signature Simply using SSL (HTTPS) causes attack to be invisible to IPS

11 Successful Attacks Can Yield Significant Damage SQL injection attacks one of the OWASP Top 10 can permit execution of arbitrary database queries Dumping the entire database is not uncommon Similar attacks can often bypass the login prompt Permits attacker to impersonate a valid user Most applications cannot detect these attacks Unauthorized access can continue over a long period The OWASP list ( is similar to the SANS/FBI Top Twenty List ( The SANS/FBI list is organized around network and infrastructure products. OWASP is focused on application security. While OWASP states a particular focus on Web application security, their recommendations are quite useful to application development vulnerabilities in general, as many of the same coding practices often carry over.

12 Successful Attacks Can Yield Significant Damage The OWASP Top Ten: Unvalidated Input Information from Web requests is not validated before being used by a Web application. Attackers can use these flaws to attack backend components through a Web application Broken Access Control Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users accounts, view sensitive files, or use unauthorized functions Note previously mentioned Case Study that referenced insignificant access control mechanisms. Broken Authentication and Session Management Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users identities

13 Successful Attacks Can Yield Significant Damage The OWASP Top Ten: Cross Site Scripting (XSS) Flaws The Web application can be used as a mechanism to transport an attack to an end user s browser. A successful attack can disclose the end user s session token, attack the local machine, or spoof content to fool the user. Phishing attacks Buffer Overflows Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and Web application server components. An excellent reference for these types of attacks, as well as attacks on Unvalidated Input, and Injection Flaws (next) is The Shellcoder s Handbook by Koziol, Litchfield, Aitel, Anley, Eren, Mehta, and Hassell (Wiley Publishing, 2004)

14 Successful Attacks Can Yield Significant Damage The OWASP Top Ten: Injection Flaws Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the Web application. Improper Error Handling Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the Web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server. In actuality, it is very difficult to test for all errors. This being said, it is then difficult to perform complete error handling.

15 Successful Attacks Can Yield Significant Damage The OWASP Top Ten: Insecure Storage Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection. Case study: Cryptographic algorithm conversion Denial of Service Attackers can consume Web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail. An excellent reference is How to Break Software Security, by Whittaker and Thompson (Pearson Education, 2004). Holodeck Written by faculty and students at Florida Tech Case study: Network fault injection denial of all ports vs. denial of network access

16 Successful Attacks Can Yield Significant Damage The OWASP Top Ten: Insecure Configuration Management Having a strong server configuration standard is critical to a secure Web application. These servers have many configuration options that affect security and are not secure out of the box. Case study: Medical devices and Web servers.

17 Comparison Factor How to Break Software Security (Wiley, 2004) Unanticipated Scenarios Blocking access to libraries Manipulating application registry values Forcing use of corrupt files Manipulation and replacement of files Environmental fault conditions (low memory, disk-space and network-availability conditions) Any of the above may result in a minimum of Denial of Service, to Broken Access Control

18 Comparison Factor How to Break Software Security (Wiley, 2004) User Interface Attacks Overflowing input buffers (Corresponds to Buffer Overflows) Examine all common switches and options Explore escape characters, character sets, and commands Note the similarity to OWASP s Injection Flaws and Unvalidated Input

19 Comparison Factor How to Break Software Security (Wiley, 2004) Design Attacks Default and test account names and passwords (Corresponds to Broken Access Control) Expose unprotected test APIs Connect to all ports Fake the source of data Create loop conditions in any application that interprets script, code, or other user-supplied logic (Corresponds to Injection Flaws, Unvalidated Input, Cross Site Scripting) Use alternate routes to accomplish the same task Force the system to reset values (Corresponds to Unvalidated Input)

20 Comparison Factor How to Break Software Security (Wiley, 2004) Implementation Attacks Get between time of check and time of use (Corresponds to Insecure Storage) Create files with the same name as those protected with a higher classification (Corresponds to Broken Access Control) Force all error messages (Corresponds to Improper Error Handling) Look for temporary files and screen their contents for sensitive information (Corresponds to Broken Access Control, and Broken Authentication and Session Management)

21 Successful Attacks Can Yield Significant Damage These issues are not new many have been around for decades Mistakes keep recurring No magic cure-all Requires a change in development culture, developer training, updated software processes, use of technology where appropriate

22 Challenges Faced Lack of true definition of application security gray area in understanding Some definitions, it relates only to custom application code Other definitions, it covers the entire application layer, which includes libraries, server configurations, and application layer protocols Organizational specificity Difficult to state relativity of specific vulnerabilities to individual organizations Individual organizations are the only ones qualified to assess their own risk levels in relation to specific types of vulnerabilities Example: Algorithmic vulnerabilities versus cross-site scripting

23 Challenges Faced Placement of application security into the SDLC Often gets placed into the cycle after code completion, as an afterthought Succeeds when built in from the start Most cost effective Consulting projects often see a change in attitude in the client from entry to departure. Entry, the client is bored, does not think that vulnerabilities will be found Departure, the client is overwhelmed at everything they must do to mitigate all the vulnerabilities that were found.

24 Strategy For Effective Protection Be deliberate Make security a priority item in application projects Adopt reliable, consistent application security processes Obtain specialized application security expertise Establish security standards for apps Use independent validation to monitor compliance

25 Designing Security In Design applications to be secure Analyze potential attacks/risks Establish security requirements for custom applications Evaluate security features in selection of off-the-shelf packages Build applications to be secure Mandate secure coding practices Test the security of applications Before acceptance, perform assurance testing Monitor applications to maintain security Monitor logs Validate security posture during operations Evaluate security impact of changes

26 What s Included? Typical Application Security Scope Authentication Authorization Session Context Control Audit Logging Intrusion Detection and Deterrence Data Cleansing Data Privacy and Integrity Back-end Communications Alternative Interfaces

27 Application Security Scope Authentication Mechanisms such as passwords or tokens that are used to authenticate the identity of the user, including an analysis of whether the login process can by bypassed Authorization Mechanisms for controlling what application functionality and data are accessible to each user, including an analysis of anonymous access restrictions (what users can see without logging into the application) Session Context Control Mechanisms to ensure the integrity and segregation of user sessions, including an analysis of whether it is possible to spoof or hijack another user s session

28 Application Security Scope Audit Logging Features to track and log user actions, especially unauthorized access attempts Intrusion Detection and Deterrence Mechanisms to detect and/or block unauthorized access attempts, including an analysis of the application s response to account and password guessing attacks and URL guessing/modification attacks Data Cleansing Mechanisms to detect bad user input, including an analysis of the application s reaction to null/missing data, extraneous data, and buffer overflow attacks in selected fields

29 Application Security Scope Data Privacy and Integrity Mechanisms to protect the privacy and integrity of data exchanged with the user during an application session, including encryption of passwords and sensitive data, and attempts to spoof or replay a user session Back-End Communications Mechanisms by which the application exchanges data with back-end databases or applications, including an analysis of the protocols used and means of authentication Alternative Interfaces Other application interfaces (Web or otherwise) that are used by administrators and maintainers to configure the application

30 Application Security Scope Importance is also on Policies and Procedures Policies and procedures should be present that surround the use and administration of the application Security should be built using a Security Development Life Cycle that mirrors the Software Development Life Cycle Security should be built into the application from the beginning, rather than retrofitted at the end.

31 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production Support Timely and relevant security input at each stage of application development Reference: NIST Special Publication , Security Considerations in the System Development Life Cycle Incident Handling

32 Life Cycle Considerations Time Line Requirement/Specification Set requirements for security features/functions Design Development Test Documentation Post-production support Incident Handling

33 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production support Detailed design Choose security products/mechanisms Trade-offs between security and other criteria Incident Handling

34 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Implement security features Training Secure coding guidelines Post-production support Incident Handling

35 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production support Incident Handling Security Compliance testing Ensure the application security features meet the design requirements Penetration testing Ensure the application is resistant to hostile acts

36 Spectrum of Assurance Testing Automated External Network Scan Network Penetration Testing Network, Host, and App Testing Compliance Testing Customized Testing of All Components In-depth S/W and H/W Trust Evaluation Low Typical Choices Commercial Gov t Non-DoD DoD/Intel High

37 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production support Incident Handling Risk evaluation Assurance evidence as a decision aid for the business unit in accepting the security risks associated with the application Compliance evaluation Document how application meets security and privacy regulations

38 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production Support Incident Handling Establish operational procedures to monitor/maintain security Review and test any software changes that affect security Periodic verification of the security posture of applications

39 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production support Procedures and resources for Incident analysis Investigation Damage control Reporting Incident Handling

40 What About Risks In Existing Applications? Assessment Testing Decision Support for Risk Acceptance Decisions Certification Testing Incident Handling Recommendations for Enhancements Implementation of Enhancements

41 Risks in Existing Applications May perform a triage to decide critical applications Organization should perform a formal application security assessment Factors involved will include tradeoffs in security versus consequences to the business. This is not the pretty picture, but it is the reality. Case study: Low-end medical device and small hospital Organizations have only so much time, and so much money. When assessing existing application security risks, not all risks may be mitigated. This, again, supports the argument that it is better to add application security to the design/build process from the beginning.

42 California SB 1386 Information Practices Act If you store personal information on one or more California residents, you must notify them if their data have (or may have) been accessed illegally Disclosure no longer a PR decision Stated goal: minimize damage from identity theft Expeditious notification of possible misuse is imperative Encryption of data is critical but not sufficient Law only applies to unencrypted personal information But what if data is decrypted as part of the breach? Affects all companies who do business with California residents Outsourcing companies Data processing and storage companies Similar legislation being introduced elsewhere

43 Q&A and thanks!