Log in to StudySoup
Get Full Access to ASU - BMS 101 - Study Guide
Join StudySoup for FREE
Get Full Access to ASU - BMS 101 - Study Guide

Already have an account? Login here
Reset your password

byeng asu

byeng asu


School: Arizona State University
Department: Biomedical Science
Course: Software Security
Term: Fall 2016
Tags: Security, software, and Techniques
Cost: 50
Name: Study guide to be covered.
Description: These are topics covered in final exam. Only important slides are present and unimportant have been removed.
Uploaded: 12/05/2016
436 Pages 324 Views 0 Unlocks

■ What are you attempting to protect?

■ Who are the potential attackers and threats?

What Is Secure Software Engineering?

CSE 545 Software Security Secure Software Engineering  Lifecycle Professor Stephen S. Yau Fall, 2016Goal of Secure Software Engineering ■ Minimize number of security vulnerabilities in  software ■ Implement repeatable processes which reliably  deliver improved security ■ Adopt a more stringent software development  process that greatly focuses on security ■ Identify and remove vulnerabilities in development  process as early as possible CSE 545 Fall 2016 2What Is Secure Software Engineering? ■ Recognize threats that almost every software controlled system faces from potential adversaries,  and produce systems with credible defense ■ Integrate security in software development  process ■ Security reviews at each stage: requirement, design,  implementation, test, and maintenance ■ Keep track of risks over time as a software project  unfolds. ■ Much easier and economical than retrofitting a  system for security CSE 545 Fall 2016 3Software Development Process Requirements Design Implementation System Testing Deployment Maintenance CSE 545 Fall 2016 41-Requirements Phase ■ Gather all information about the application ■ Including security related information ■ Analyze threats ■ Who are the potential attackers and threats? ■ What are you attempting to protect? ■ Analyze requirements ■ Make sure all security issues have been included and addressed ■ Confidentiality ■ Integrity ■ Availability ■ Authentication (identity management) ■ Authorization (access control) ■ Intrusion detection ■ Contingency plans and recovery plans CSE 545 Fall 2016 51-Requirements Phase (cont.) ■ Verify requirements ■ Make sure all security requirements are consistent  with each other ■ Documentation ■ Check feasibility of requirements ■ Balance security with usability ■ Cost ■ Effort at this phase offers most efficient way to build  secure software ■ cost ■ time CSE 545 Fall 2016 62-Design Phase ■ All design decisions, including ■ System architecture ■ Software components  ■ Programming languages  ■ Interfaces ■ Confirm that all requirements are followed and met ■ Documentation is the key CSE 545 Fall 2016 7Design Principles  1. Least privilege 2. Fail safe defaults 3. Economy of security mechanisms 4. Complete mediation 5. Separation of privilege 6. Least common mechanism 7. Psychological acceptability 8. Architecture for secure software CSE 545 Fall 2016 8Design Principles (Cont.) ■ Complete Mediation ■ Make sure all security mechanisms are checked  to ensure that they are allowed ■ Separation of Privilege ■ A system should not grant permission based on  a single condition ■ Remove “single point of failure” CSE 545 Fall 2016 9Design Principles (Cont.) ■ Least Common Mechanisms ■ Security mechanisms used to secure different resources should  not be shared ■ The more security mechanisms share, the more likely these  mechanisms affect each other ■ Bad example - Microsoft NT architecture: FTP and Web  services on the same computer share a common thread pool.  Exhausting FTP thread pool will cause failed connection  requests for web service. ■ Psychological Acceptability ■ Security mechanisms should not make a resource more  difficult to access ■ In practice, difficulty in use should be proportional to the  value of the protected asset CSE 545 Fall 2016 10Design Principles (Cont.) ■ Architecture for Secure Software ■ Most vulnerabilities are caused by flaws in software  architectural design  ■ Some examples of the design principles should be  adopted: ■ If a module is suspected not to be trustful, decompose the  module to several smaller modules so that the compromise of  one of these smaller modules will not affect others. ■ Decompose each module, in which there are different privilege  access requirements ■ Identify and restricted certain application modules with higher  privileged access CSE 545 Fall 2016 113-Implementation Phase ■ To write secure software code, you need ■ Coding standards ■ Security designs ■ Aware of known security vulnerabilities  in coding, such as race conditions, buffer  overflow, format string. malicious logic ■ Follow design documents CSE 545 Fall 2016 12CSE 545 Software Security Professor Stephen S. Yau Fall, 2016IA Courses ■ *CSE465: Information Assurance ■ CSE466: Computer Systems Security ■ CSE467: Data and Information Security ■ CSE468: Computer Network Security ■ CSE469: Computer and Network Forensics ■ CSE539: Applied Cryptography ■ *CSE543: Information Assurance and Security ■ CSE545: Software Security ■ CSE548: Advanced Computer Network Security ■ CSE591: Security and Vulnerability Analysis * Only one of these two courses.S S Yau - CSE545 Fall 2016 2 IA Concentrations in MS, MCS and Ph.D. in Computer Science ■ MS and MCS: ■ A minimum of 15 credits in Information Assurance  and related areas are required. ■ M.S. thesis or the project portfolio for M.C.S. must  have a major portion of the content in the  information assurance area ■ Ph.D. ■ A minimum of 18 credits in Information Assurance and related areas are required. ■ Ph.D. dissertation must have a major portion of the content in the information assurance area ■ For more information: http://ia.asu.edu/education.php S S Yau - CSE545 Fall 20163 CSE 545 Course Description ■ A core course of our IA Concentration Programs at  graduate level. ■ Objective and Scope: Building secure software ■ Provide students with good understanding of theories and tools used for secure software design, threat analysis and modeling, security coding and testing. ■ Cover various analysis and design techniques for improving software security, as well as using these techniques and tools to improve and verify software designs and programs from security point of view. S S Yau - CSE545 Fall 20164 Major Topics in CSE 545 ■ Software security overview ■ Evolution of computing paradigms and  challenges to software security ■ Secure software design and coding ■ Common software vulnerabilities ■ Software attack patterns and defense ■ Software assurance ■ Software security standards and tools ■ Secure software engineering lifecycle ■ Risk management in software development S S Yau - CSE545 Fall 20165 Major Topics in CSE 545 (cont.) ■ Software testing (verification and validation) for security. ■ Privacy protection in software ■ Service and cloud computing security ■ Malicious software ■ Software security for social computing ■ Security for open-sourced software ■ Security for outsourced software S S Yau - CSE545 Fall 20166 Course Prerequisites Knowledge of computer systems and  networks, experience in software  development. S S Yau - CSE545 Fall 20167 Course Information ■ Instructor: Professor Stephen S. Yau ■ E-mail: yau@asu.edu ■ Office: BYENG Room 488 ■ Office hours: T Th 4:00 – 5:00 p.m.(also by appointment) ■ Teaching Associate/Assistant: ■ Yaozhong Song ■ E-mail: ysong75@asu.edu ■ Office: BYENG Room 468AB ■ Office hours: T Th 3:00 p.m. to 4:00 p.m. (also by appointment) ■ Evaluation ■ Two examinations (60%) ■ One course project (40%) S S Yau - CSE545 Fall 20168 Course Project ■ Each group will have 18 or 19 students. ■ Each group will conduct a software development project with security requirements, covering from requirement analysis to demonstration ■ The software developed will be hosted on a cloud computing system for testing by other students ■ The project to be evaluated with the following aspects: ■ Quality of developed software system ■ Project documents ■ Oral presentation with demonstration ■ Each student is required to test the software developed by three other groups for finding vulnerabilities. ■ The final group project report will include responses to all the  vulnerabilities discovered by other group students. 9 S S Yau - CSE545 Fall 2016Course Project (cont.) ■ Extra credit points for testing ■ For every vulnerability you find in another  group’s’ project, you get 0.3 extra point in your final project grade (6 max) ■ For every vulnerability found by other students  in your group’s project, you will lose 0.3 point in your final project grade (6 max) ■ Adjustment based on peer evaluation by members  of your group S S Yau - CSE545 Fall 201610 Course Project Groups ■ One Group leader ■ Responsible for coordinating group activities and managing  group course project. ■ Two or Three Subgroup Leaders ■ Each subgroup leader is responsible for coordinating  subgroup activities, managing subgroup course project and  coordinating the interactions with other subgroups. ■ Incentive: ■ Total 15% distributed to all the leaders and subgroup group  leaders with the group leader having no more than 7%. S S Yau - CSE545 Fall 2016 11Course Website ■ ASU Blackboard will be used for posting  lecture notes, project description, grades and instructor’s feedback. S S Yau - CSE545 Fall 201612 National IA Program ▪ The National Centers of Academic Excellence in Information  Assurance Education (CAE IA/CD) and the National Centers  of Academic Excellence in Information Assurance Research  (CAE-R) Programs are outreach programs designed and operated  initially by the National Security Agency (NSA) in the spirit of  Presidential Decision Directive 63, National Policy on Critical  Infrastructure Protection, May 1998.  ▪ The program is now jointly sponsored by the NSA and the  Department of Homeland Security (DHS) in support of the  President's National Strategy to Secure Cyberspace, 2003.  ▪ The goal of the program is to reduce vulnerability in our national  information infrastructure by promoting higher education in  information assurance (IA), and producing a growing number of  professionals with IA expertise in various disciplines. ▪ ASU has been certified as both CAE IA/CD and CAE-R S.S. Yau S S Yau - CSE545 Fall 2016 13Information Assurance Center (cont.) • The IA Center was designated by National Security Agency and  Department of Homeland Security • As a National Center of Academic Excellence in Information  Assurance Education (CAEIAE) since 2007 and re-designated  as a National Center of Academic Excellence in Information  Assurance Education/Cyber Defense (CAE IA/CD) under the  new criterion in 2015 with five focus areas  • Data Management Systems Security • Digital Forensics  • Network Security Engineering  • Secure Cloud Computing • Secure Software Development  • As a CAE-Research since 2009, and re-designated under the  new criterion since 2014 14 S S Yau - CSE545 Fall 2016CAE IA/CD Program ▪ In order to be designated as a CAE IA/CD (Center of Academic  Excellence in Information Assurance/Cyber Defense), each  applicant must demonstrate its commitment to and capability for  academic excellence in IA education.  ▪ Prerequisite: IA courseware must satisfy the CAE IA/CD 4Y Knowledge  Unit criteria.  ▪ Satisfy the following: ■ Partnerships in IA Education  ■ IA Treated as a multidisciplinary  science  ■ University encourages the practice  of IA  ■ Academic program encourages  research in IA  ■ IA curriculum reaches beyond  geographic borders  ■ Faculty active in IA practice and  research, and contribute to IA  literature  ■ State-of-the-art IA resources  ■ Declared IA Concentrations  ■ Declared Center for IA education  or research  ■ Full-time IA faculty  S.S. Yau 15 S S Yau - CSE545 Fall 2016CAE-R Criteria 1. Engagement in serving on technical program  committees of IA conferences, editing IA  journals, hosting IA conferences and IA  workshops, and collaborating with or assisting  local government, business, and industry. 2. Producing students’ thesis, dissertations, or  projects, related to IA. 3. Strong peer-reviewed publications in IA by  faculty and students 4. History of research funding related to IA  S.S. Yau S S Yau - CSE545 Fall 2016 16Benefits from CAE IA/CD or  CAE-R Programs  ▪ Formal recognition from the U.S. government, as  well as opportunities for prestige and publicity, for  their role in securing our nation's information  systems.  ▪ Students attending CAE IA/CD or CAE-R schools  are eligible to apply for scholarships and grants  through  ▪ The Department of Defense (DoD) Information  Assurance Scholarship Program  ▪ The Federal Cyber Service Scholarship for Service  Program (SFS) operated by National Science Foundation  (NSF) S.S. Yau S S Yau - CSE545 Fall 2016 17Major IA On-going Development  ■ Center for Digital Identity and Cyber Defense  Research ■ IA Symposium ■ October 21, 2016 at SkySong ■ Outreach Programs ■ Industry ■ Community Colleges ■ Entrepreneurship S S Yau - CSE545 Fall 2016 18CSE 545 Software SecuritySecure Software Design and Coding Professor Stephen S. Yau Fall, 2016 Software Design ■ The process of organizing structured solutions to  tasks from software requirements, which  includes ■ Overall architecture in which software components  are integrated ■ Data structures ■ Information flows ■ Use case and misuse case scenarios ■ Abstractions of software components, modules,  services CSE 545 Fall 2016 2Goals of Software Design ■ Decompose a software system to components ■ Identify software architecture and its components ■ Determine relationships among components ■ Identify component dependencies ■ Determine internal communication mechanisms  among components ■ Global variables, function calls, shared memory, IPC/RPC ■ Specify component interfaces ■ Well defined interfaces facilitate component testing and  communication among developers ■ Describe component functionality CSE 545 Fall 2016 3Secure Software Design ■ Integrating security in software development after  software design often requires architectural changes,  not only code changes or small design changes.  ■ Such changes often result in insecure software ■ Integrating security in software design requires the  consideration:  ■ What software components need to be created to satisfy  security requirements? ■ How to integrate components securely? ■ How sensitive data is stored and retrieved in the system? ■ How to control information flows between components? CSE 545 Fall 2016 4Secure Software Design (cont.) ■ Secure software design is difficult because ■ No general methodology suitable for design of all  kinds of software ■ A secure design for certain software may not be  secure for other software ■ Software design heavily relies on developers’  knowledge, experiences and intuition ■ Emerging technologies and new threats require new  software design patterns CSE 545 Fall 2016 5Secure SW Design Principles ■ Secure the weakest link ■ Attackers usually attack a weak spot in a  software system, and do not penetrate a heavily  fortified component.  ■ Example: Cryptographic algorithms can take  long time to break, and attackers are not likely  to attack encrypted information communicated  in a network. Instead, the endpoints of  communication (e.g., servers) may be much  easier to attack. CSE 545 Fall 2016 6Secure SW Design Principles (cont.) ■ Defense in depth ■ Apply multiple layers of security  mechanisms. ■ Example: ■ Use firewalls to protect a network from malicious user  inputs, virus and worms ■ The next layer may be IDS ■ The next layer may be access control for a particular  asset ■ The next layer may be contingency safe mode CSE 545 Fall 2016 7Secure SW Design Principles (cont.) ■ Trust the community and library  ■ Use least privilege principle ■ Create secure defaults ■ Are user accounts disabled by default and must be explicitly  enabled when required? ■ If an account is not used for a specified period, remove or  disable it ■ Disable or remove unused services, protocols and  functionalities. ■ Does user’s server need all the current services and ports? ■ Does user’s application need all the enabled features? CSE 545 Fall 2016 8Secure SW Design Principles (cont.) ■ Keep software design simple ■ Reuse software components as much as possible ■ Funnel security-critical operations through a few  chokepoints ■ Avoid hidden interfaces and backdoors ■ Fail securely.  ■ If an application fails, do not leave sensitive data accessible ■ Error messages should not expose internal system details ■ Determine what may occur when a system fails and be sure  it does not threaten the system.  CSE 545 Fall 2016 9Secure SW Design Principles (cont.) ■ Protect customers’ privacy ■ Comply with the privacy regulations of the Fair  Information Practice Principles (FIPPs) of the Federal  Trade Commission.  https://en.wikipedia.org/wiki/FTC_Fair_Information_Practice  ■ Create a formal privacy statement ■ Request the users’ consent before collecting their personal  information ■ Do not collect unnecessary information ■ Do not trust user input CSE 545 Fall 2016 10Secure SW Design Principles (cont.) ■ Avoid making frequent changes ■ Avoid making the design too detailed ■ Avoid ambiguous design ■ Avoid inconsistent design ■ Do not rely on users making correct security  decisions CSE 545 Fall 2016 11Secure Software Design Patterns ■ A software design pattern (or design pattern) is  a description or template for how to solve a  commonly occurring software design problem in various situations  ■ A secure software design pattern (or secure  design pattern) is a description/template for how  to solve a commonly occurring security problem in software design in various scenarios. ■ It helps avoid known vulnerabilities in software  design. CSE 545 Fall 2016 12Secure Software Design Patterns:  Architecture-level Patterns ■ To define high-level assignment of responsibilities  among various components of the system and the  interactions among them. ■ Decomposition of distrustful components: If a  component is suspected to be not trustful, then  decompose it into several smaller components,  reducing the potential attack area and data exposure  even if one of the smaller components is  compromised. CSE 545 Fall 2016 13Secure Software Design Patterns: Architecture-level Patterns (Cont.) ■ Privilege reduction: If a function in a component  does not require as high as the privileges for other  functions in the component, then we reduce the  function’s privilege to what is required for the  function.  ■ Move functions with similar privileges together:  In a given component, separate the functions with  higher privileges from those with lower privileges  to reduce the effort for preventing unauthorized  access. CSE 545 Fall 2016 14Secure Software Design Patterns: Design-level Patterns ■ When design high-level system components, do not  address the interactions among the components already addressed at the architecture level ■ Some useful secure design patterns: ■ Separate processes involved in object creation from other  basic functions of the component. Applicable only for  systems which construct object versions based on readily  available security credentials ■ Define easily manipulatatable tasks/privileges for each  object/entity based on security credentials of the object/entity  to prevent changes at design level, which might introduce  new vulnerabilities. CSE 545 Fall 2016 15Secure Software Design Patterns: Design-level Patterns (Cont.) ■ Separate the process involved in creating complex object (interrelated  entities) with security credentials from the process of creating simple  objects. ■ Secure Visitor: By default, lock all nodes (data/method) and allow  access to entities only with proper visitor credentials (credentials to  unlock nodes) ■ Example: In DMS, lock all data and operations unless provided with  proper access credentials ■ Secure Supply Chain of Responsibility: Separate and simplify security operations from components requesting the security  functionality.  ■ Example: Required for changing security policies dynamically without  affecting basic functionality of application. CSE 545 Fall 2016 16Secure Coding ■ Affected by the programming language to  be used ■ Secure coding includes ■ Validating incoming requests ■ Handling exceptions ■ Creating self-monitoring code ■ Complying with coding standards CSE 545 Fall 2016 17Validating Incoming Requests ■ Every incoming request should be treated as a  potential attack ■ Each incoming request should be validated ■ Who is the requester? ■ Does the requester have proper privilege? ■ Is the request in a right format? ■ Does the request contains any malicious code? ■ If a request contains data to be processed, make  sure the data has not been changed or tempered  during the transmission CSE 545 Fall 2016 18Handling Exceptions ■ Motivated attackers like to see error messages  and look for information that may give clues as  to what types of attacks they can unleash on the  application software ■ If not handled properly, errors can provide  useful information to attackers, such as  database information, code location and Web  server information CSE 545 Fall 2016 19Handling Exceptions (Cont.) ■ Two major types of errors in software ■ Compile-time errors occur at compile-time and code  will not execute until fixed. ■ Applicable to languages like Java and C, but may not be  applicable to languages like Python ■ Easy to find and fix ■ Runtime errors occur when a program is running ■ Hard to find and fix ■ These errors give a lot of secure information about the  application software, and must be dealt up front CSE 545 Fall 2016 20Creating Self-Monitoring Code ■ Self-monitoring code watches the user’s activity and looks  for unusual events. For example, the number of times a  single user has tried to log on, request-sensitive  information that exceeds normal conditions. ■ Self-monitoring applications is designed to react misuses ■ Examples: ■ Canceling user passwords based on situational awareness ■ Automated bounds checking ■ Requiring physical requests for data based on user’s activity ■ Alerting stakeholders of intrusion  CSE 545 Fall 2016 21Complying with Coding Standards ■ CERT (Computer Emergency Readiness Team) Secure Coding  Initiative is working with various software development and  security communities to reduce vulnerabilities resulting from  coding errors before deployment.  https://www.securecoding.cert.org/confluence/display/seccode/S EI+CERT+Coding+Standards ■ Secure coding standards  ■ Provide developers guidance for secure implementation of  software. ■ Help developers avoid common software defects and  programming errors. http://www.cert.org/secure-coding/ CSE 545 Fall 2016 22CSE 545 Software Security Software Attack Patterns and Defense Professor Stephen S. Yau Fall, 2016Challenges for Software Developers ■ Advantages of Attackers ■ Only need to find one exploitable vulnerability to achieve  his/her goal  ■ May possess a copy of the target software and perform  reverse engineering or penetration testing on it ■ Attacks can be done remotely from anywhere through  networks. ■ Functionality over security ■ The products offering the best functionality are often  chosen over those offering most cost effective security. ■ More functionalities and shorter developing time often  cause more vulnerabilities.  CSE 545 Fall 2016 2Challenges for Software Developers (Cont.) ■ The knowledge gap ■ Attackers gain attack knowledge for a long time. ■ New technologies, such as wireless mobile devices  web and cloud services, have brought new attack  vectors. ■ Developers are generally not aware of the ways  software is exploited.  ■ Developers may not keep up with the knowledge  as attackers in software security.  ■ Developers may not be aware of emerging security  issues and solutions. CSE 545 Fall 2016 3Addressing the Challenges ■ Have solid understanding of the attacker's  perspective  ■ Be aware of new security issues and  solutions ■ Address the security issues efficiently in  timely manner ■ Use “Attack Patterns” CSE 545 Fall 2016 4Definition of Attack Pattern ■ Is a group of frequently used rigorous methods for  finding bugs/errors in the code related to computer  security.  ■ Provides an abstraction of an observed attack – what attack was executed on which software, under  what conditions ■ Describes techniques used by attackers to carry out  particular type of attack against software ■ Standardizes the terminologies to describe a  particular type of attacks and security concept CSE 545 Fall 2016 5Benefits of Using Attack Patterns ■ Provide developers with attackers’ viewpoints and  indicate how they may attack software.  ■ Help developers solve recurring common security  problems during software development.  ■ Help developers categorize attacks meaningfully ■ Security roblems and solutions can be discussed  effectively.  ■ Can identify the types of known attacks to software  so that mitigations may be incorporated in the  software. CSE 545 Fall 2016 6Find Attack Patterns ■ Common Attack Pattern Enumeration and  Classification (CAPEC) is sponsored by DHS  in Software Assurance Initiative to categorize,  update and maintain the community  knowledge resource for software attack  patterns,  ■ 504 common attack patterns under 56  categories have been published at (latest  information (December 07, 2015)  http://capec.mitre.org/data/slices/2000.html CSE 545 Fall 2016 7Structure of Attack Patterns ■ Attack patterns should contain sufficient  detailed information about how attacks  are carried out to help developers  prevent them.  ■ Attack patterns should not contain  certain specifics about the actual  exploits to help attackers improve their  skills (e.g., script kiddies).  CSE 545 Fall 2016 8Structure of Attack Patterns (cont.) ■ An attack pattern should include the  following information: ■ Pattern Name and Classification: A unique,  descriptive identifier for the pattern. ■ Attack Prerequisites: What conditions must  exist or what functionality and  characteristics must the target software have,  or what behavior must the target software  exhibit for the attack to succeed? CSE 545 Fall 2016 9Structure of Attack Patterns (cont.) ■ Description: A description of the attack  including the chain of actions taken and  possible scenarios. ■ Sample Attack Code: If it is possible to  demonstrate the exploited code, this section  provides a demonstration code. In some cases,  such as a Denial of Service attack, specific  code may not be possible. However, in many  cases, such as Buffer Overflow, and Cross Site  Scripting attacks, sample code, is very useful. CSE 545 Fall 2016 10Structure of Attack Patterns (cont.) ■ Related Vulnerabilities: What specific vulnerabilities does this  attack leverage? Specific vulnerabilities should refer to  industry-standard identifiers. For examples,  ■ Common Vulnerabilities and Exposures (CVE): A DHS  initiative to standardize terminologies for common software  vulnerabilities (http://cve.mitre.org).  ■ Common Weakness Enumeration (CWE): A DHS software  assurance strategic initiative to update and maintain software  assurance issues in computer software lifecycle, such as design  phase, implementation phase and operation phase.  (http://cwe.mitre.org) ■ The members of CVE and CWE include NSA, NIST, 16  companies and 2 universities  (http://cve.mitre.org/community/board/index.html)  CSE 545 Fall 2016 11Structure of Attack Patterns (cont.) ■ Method of Attack: What is the vector of attack used (e.g.,  malicious data entry, maliciously crafted file, protocol  corruption)? ■ Attack Motivation-Consequences: What does the attacker try to  achieve using this attack? What are the specific results? ■ Attacker’s Skill or Knowledge Required: What level of skill or  specific knowledge must the attacker have to execute such an  attack? (e.g., low, moderate, high) as well as in contextual detail  of what types of skills or knowledge are required. ■ Resources Required: What resources (e.g., computing power,  network bandwidth, IP addresses, tools, time) are required to  execute the attack? CSE 545 Fall 2016 12Structure of Attack Patterns (cont.) ■ Solutions and Mitigations: What actions or approaches  are recommended to mitigate this attack, either through  resistance or through resiliency? ■ Context Description: In what technical context, e.g.,  platform, OS, language, architectural paradigm, is this  attack pattern relevant? This information is useful for  developers to identify the attack patterns to be  concerned with in a given context ■ References: What further sources of information are  available to describe this attack? CSE 545 Fall 2016 13Attack Pattern Example 1  ■ Pattern name : Password Recovery Exploitation ■ Pattern classification : Functionality Misuse ■ Attack Prerequisites :  ■ The software system allows users to recover their  passwords and gain access back into the system. ■ Password recovery mechanism has been designed or  implemented insecurely. ■ Password recovery mechanism relies only on what the  user knows and not what the user has, such as user’s  private key installed on the user’s computer. ■ No third party intervention is required to use the  password recovery mechanism. CSE 545 Fall 2016 14Attack Pattern Example 1 (cont.) ■ Description: An attacker may take advantage of the  application feature to help users recover their forgotten  passwords in order to gain access to the system with the  same privileges as the original users. Password  recovery schemes generally tend to be insecure. Often,  only one security question is asked, such as mother's  maiden name. In many cases, this information is not  hard to find, especially if the attacker knows the  legitimate user personally. A weak password recovery  scheme undermines the effectiveness of a strong  password scheme. CSE 545 Fall 2016 15Attack Pattern Example 1 (cont.) ■ A possible scenario: An attacker clicks on the  "forgot password" and is presented with a  single security question. The question is  regarding the name of the first dog of the user.  The system does not limit the number of  attempts to provide the dog's name. An  attacker goes through a list of 100 most  popular dog names and may find the right  name, and then reset the password and access  the system. CSE 545 Fall 2016 16Attack Pattern Example 1 (cont.) ■ Related Vulnerabilities : CWE 522 - Insufficiently  Protected Credentials, CWE 640 - Weak Password  Recovery Mechanism for Forgotten Password, CWE  718 - Broken Authentication and Session  Management  ■ Methods of Attack: Brute force, API abuse ■ Attack Motivation-Consequences: Privilege  escalation ■ Attacker’s Skill or Knowledge Required: Low  (brutal-force attack and possible social engineering) CSE 545 Fall 2016 17Attack Pattern Example 1 (cont.) ■ Resources Required: For a brute force attack, need a  machine with sufficient CPU, RAM and HD. ■ Solutions and Mitigations:  ■ Use multiple security questions. Let the user select their  own security questions or provide them with choices of  questions that are not generic. ■ E-mail the temporary password to the registered e-mail  address of the user, rather than letting the user reset the  password online. CSE 545 Fall 2016 18Attack Pattern Example 2  ■ Pattern name: Detect Unpublished Web Pages ■ Pattern Classification: Predictable Resource  Location ■ Attack Prerequisites:  ■ The targeted website must have unpublished  (unauthorized for general users) web pages within its  web server.  ■ The unpublished web pages are not linked with the  published web pages. (The unpublished web pages are  not accessible through the published web pages) ■ The unpublished web pages are not protected by any  access control mechanism. CSE 545 Fall 2016 19Attack Pattern Example 2 (cont.) ■ Description: An attacker searches a targeted website  for web pages that have not been made available for  the general users. Generally, this involves  ■ Attempt to access well-known debugging or  logging pages (e.g. from a default home page of a  web server) ■ Attempt to access unpublished pages which are  predictable from the published pages, such as  changing certain attributes of a document.  CSE 545 Fall 2016 20Attack Pattern Example 2 (cont.) ■ A possible scenario  A company has published the following documents on  its web server: ftp://public.dhe.ibm.com/annualreport/2010/2010_ibm_letter.pdf ftp://public.dhe.ibm.com/annualreport/2008/2008_ibm_letter.pdf The attacker is able to access the document  “2007_ibm_letter.pdf” using  ftp://public.dhe.ibm.com/annualreport/2007/2007_ibm_letter.pdf.  CSE 545 Fall 2016 21Attack Pattern Example 2 (cont.) ■ Related Vulnerabilities : CWE 425 - Forced Browsing,  CWE 285 - Improper Access Control, CWE 693 - Protection Mechanism Failure ■ Method of Attack: Brute force ■ Attack Motivation-Consequences: The attacker may be  able to gain access to information that the targeted site  did not intend for the entire user group. The sensitivity  of the content of the unpublicized pages determines the  severity of this attack. CSE 545 Fall 2016 22Attack Pattern Example 2 (cont.) ■ Skill or Knowledge Required: Low (unpublished pages can be discovered  using a number of automated tools. Doing the same manually is tedious, but  not necessarily difficult) ■ Resources Required: No special resources are required. An automated tool  to explore the target web site may be useful in this attack, especially when  attacking a large site ■ Solutions and Mitigations:  ■ Authenticate requests to every web page and directory ■ Protect every web page, including unpublished page, using access  control mechanisms.  ■ Possibly use randomized document names which are difficult to predict.  ■ Reference: "WASC Threat Classification 2.0 - WASC-34 - Predictable  Resource Location". 2010. http://projects.webappsec.org/Predictable Resource-LocationCSE 545 Fall 2016 23Attack Pattern Example 3  ■ Pattern name: Phishing ■ Pattern Classification: Spoofing ■ Attack Prerequisites:  ■ An attacker needs to have a way to initiate  contact with the victim. Typically through e-mail. ■ An attacker needs to correctly guess the entity  with which a potential victim does business and  impersonate it. Attackers may just impersonate  the most popular entities, such as banks or public  services. CSE 545 Fall 2016 24Attack Pattern Example 3 (cont.) ■ Description: Phishing is a social engineering  technique, where an attacker masquerades as a  legitimate entity with which the victim might  do business in order to prompt the user to  reveal some confidential information (very  frequently authentication credentials) that can  later be used by an attacker. CSE 545 Fall 2016 25An Attack Pattern Example 3 (cont.) ■ A possible scenario: An attacker creates a fake website which  looks exactly the same as a popular bank website. The fake  website has a login form for the victims to put in their  authentication credentials. The attacker sends an e-mail to a  potential victim, which looks like a real official email from the  bank. The email has some sort of a call to action to get the user  to click on the link included in the e-mail which takes the  victim to the attacker's fake website, and log in. If a victim  logs in the fake website by providing his/her authentication  credentials, the attacker can collect the victim’s online banking  information which can be used by the attacker to log in the  victim’s bank account and transfer money to a bank account of  the attacker's choice. CSE 545 Fall 2016 26Attack Pattern Example 3 (cont.) ■ Related Vulnerabilities: CAPEC-148: Content  Spoofing ■ Methods of Attack: Social engineering, spoofing ■ Attack Motivation-Consequences: The victim’s  sensitive information is disclosed to the attacker. ■ Skill or Knowledge Required: Medium (skills for  building a fake website and social engineering) ■ Resources Required: Some web development tools to  host a fake website. CSE 545 Fall 2016 27Attack Pattern Example 3 (cont.) ■ Solutions and Mitigations:  ■ Do not follow any links received from your e-mail  and certainly do not input any requested login  credentials on the page. ■ Type the URL of your bank in the browser directly  and then log in ■ Reference: "WASC Threat Classification 2.0 - WASC-12 - Content Spoofing". 2010.  http://projects.webappsec.org/Content-Spoofing CSE 545 Fall 2016 28

Page Expired
It looks like your free minutes have expired! Lucky for you we have all the content you need, just sign up here