Introduction to Software Security

Software Security (1/2)

Computer Security & OS LabDept. of Software Science, DKU

Cho, Seong-je (조성제)

Spring, 2020

- 2 -

References

Building Security Into The Software Life Cycle, A Business Case, Marco M. Morana

https://www.blackhat.com/presentations/bh-usa-06/bh-us-06-Morana-R3.0.pdf

Fundamental Practices for Secure Software Development, 2ND EDITION, SAFECode

A Guide to the Most Effective Secure Development Practices in Use Today, February 8,2011

Software Security, Principle, Policies, and Protection, Mathias Payer, April 2019

https://nebelwelt.net/SS3P/softsec.pdf

Code Coverage and Static Analysis, CSC216, Heckman, NC State University

https://www.csc.ncsu.edu/courses/csc216-common/Heckman/lectures/05_Coverage_StaticAnalysis.pdf

Secure Coding in C and C++, 2nd Edition

Please do not duplicate and distribute

Computer Security & OS Lab, DKU

- 3 -

Contents

Software Security

Vulnerability ≒ Risk

Weakness

Secure SDLC

Microsoft SDL

Threat Modeling

Secure Coding

Computer Security & OS Lab, DKU

- 4 -

Glossary

Software Security:

a way to defend against software exploits by building software to be secure (McGraw Exploiting Software)

Application Security:

a way to defend against software exploits in a post-facto way after deployment is complete (McGraw Exploiting Software)

Information Security Risks:

the probability that a particular threat-source will exercise a particular information system vulnerability and the resulting impact if this should occur (NIST publication 800-27)

Security Software:

any type of software that secures and protects a computer, network or any computing-enabled device.

It manages access control, provides data protection, secures the system against viruses and network/Internet based intrusions,

and defends against other system-level security risks.

any computer program designed to enhance information security.

E.g.) anti-malware, anti-keyloggers, Firewall, IDS, Cryptographic software, …

Computer Security & OS Lab, DKU

- 5 -

SDLC process

Source: Basic Guide on Security Testing, https://aksystemsinc.blogspot.com/2017/01/basic-guide-on-security-testing.html

Computer Security & OS Lab, DKU

- 6 -

How we approach risk?

Computer Security & OS Lab, DKU

Source: Building Security Into The Software Life Cycle, A Business Case, Marco M. Morana

- 7 -

Vulnerability

a bug, flaw, weakness, or exposure of an application, system, device, or service that could lead to a failureof confidentiality, integrity, or availability

Any weakness in an asset or security protection which would allow for a threat to cause harm.

It may be a flaw in coding, a mistake in configuration, a limitation of scope or capability, an error in architecture, design, or logic or a clever abuse of valid systems and their functions.

Software Vulnerability An error, flaw, or mistake in computer software that permits or causes an unintended behavior to occur.

A security flaw, glitch, or weakness found in S/W that can be exploited by an attacker.

Computer Security & OS Lab, DKU

- 8 -

What is at risk?

Target Applications At Risk

92% of reported vulnerabilities are in applications not in networks

Computer Security & OS Lab, DKU

Source: Building Security Into The Software Life Cycle, A Business Case, Marco M. Morana

- 9 -

When we do address the problem?

Today most people test after software is built!

Computer Security & OS Lab, DKU

- 10 -

SW Risk Management and Secure SDLC (S-SDLC)

Development

Coding

Implementation

Deployment (전개)

Release (배포)

Testing

Verification & Validation

Computer Security & OS Lab, DKU

Source: Building Security Into The Software Life Cycle, A Business Case, Marco M. Morana

- 11 -

Microsoft Security Development Lifecycle (SDL)

1. Training: Core security training

2. Requirements: Establish security requirements, Security & Privacy risk assessment

3. Design: Establish design requirements, Threat modeling

4. Implementation: Deprecate unsafe functions, Static analysis

5. Verification: Dynamic analysis, Fuzz testing

6. Release: Incident response plan, Final security review

7. Response: Execute incident response plan

Computer Security & OS Lab, DKU Source: Microsoft SDL in practice, Alex Thissen

- 12 -

Software Security Frameworks

Computer Security & OS Lab, DKU Source: Building Security Into The Software Life Cycle, A Business Case, Marco M. Morana

- 13 -

Secure development for software development life cycle

Design

Threat modeling

Coding

Static analysis

Testing

Fuzzing

Source: A Survey on Design Methods for Secure Software Development, A. Hudaib et. al., Dec. 2017

Computer Security & OS Lab, DKU

- 14 -

A Taxonomy of Vulnerabilities

Two important dimensions: when and where

When

Design

Implementation

(Operation)

Where

Security mechanisms

Other parts of the code base

A secure system must allow users to do everything they are allowed to do and nothing they are not allowed

Computer Security & OS Lab, DKU

Source: Adam O'Brien, “Common Criteria and Source Code Analysis Tools: Competitors or Complement”, International Common Criteria Conferences 9th, Sep. 2010. Oracle

Security mechanisms mapped on security goals

- 15 -

The Vulnerability Landscape: Common Vulnerabilities

Source: Adam O'Brien, “Common Criteria and Source Code Analysis Tools: Competitors or Complement”, International Common Criteria Conferences 9th, Sep. 2010. Oracle

Computer Security & OS Lab, DKU

I&A: Identification and Authentication

XSS: Cross-site Scripting

TOCTTOU: time-of-check to time-of-use

brk

Threat Modeling in Design phase

Computer Security & OS Lab, DKU

Source: Basics of Software Development Life Cycle (SDLC), by Krishnan

- 17 -

Threat Modeling (Design Phase)

Threat Modeling, a design-time conceptual exercise where a system’s dataflow is analyzed to find security vulnerabilities and identify ways they may be exploited. Proactively understanding and identifying threats and potential vulnerabilities early in the development

process helps mitigate potential design issues

Threat Modeling is sometimes referred to as “Threat Analysis” or “Risk Analysis.”

The process of Threat Modeling begins with the identification of possible and commonly occurring threats.

Computer Security & OS Lab, DKU

Source: Fundamental Practices for Secure Software Development, 2ND EDITION

- 18 -

Approaches to Threat Modeling (1/2)

Different Approaches to the tasks of enumerating threats

STRIDE

Threat library

a format that makes threat identification more accessible to non-security professionals

Publicly available efforts can be used to help build this library.

» CWE (Common Weakness Enumeration—a dictionary of software weakness types),

» OWASP (Open Web Application Security Project) Top Ten and

» CAPEC (Common Attack Pattern Enumeration and Classification that describes common methods of exploiting software)

Computer Security & OS Lab, DKU

Source: Fundamental Practices for Secure Software Development, 2ND EDITION

- 19 -

Approaches to Threat Modeling (2/2)

Different Approaches to the tasks of enumerating threats

Misuse cases

Misuse and abuse cases describe how users can misuse or exploit weak controls in software features to attack an

application.

Misuse and abuse cases can be an effective tool to drive security requirements that protect business features or processes.

A misuse case involving authentication would state “By successively entering login names, an attacker can harvest

information regarding the validity (or not) of such login names.”

Brainstorming

a method for generating ideas to solve a design problem.

a group creativity technique by which efforts are made to find a conclusion for a specific problem by gathering a list of ideas

spontaneously contributed by its members.

Computer Security & OS Lab, DKU

Source: Fundamental Practices for Secure Software Development, 2ND EDITION

- 20 -

CWE (Common Weakness Enumeration)

CWE is a community-developed list of common software and hardware weaknesses types.

https://cwe.mitre.org/

It serves as

a common language for describing software security weaknesses in architecture, design, or code,

a measuring stick for security tools,

a baseline for weakness identification, mitigation, and prevention efforts.

CWE List Version 4.0

Total weakness: 839 (on Apr. 30, 2020)

CWE-ID Number (CWE-699, CWE-701, CWE-702, CWE-999, CWE-1200, …)

Computer Security & OS Lab, DKU

- 21 -

Weakness & Vulnerability by MITRE

Weakness (약점)

a type of mistake that, in proper conditions, could contribute to the introduction of vulnerabilities within that product.

This term applies to mistakes regardless of whether they occur in implementation, design, or other phases of a product lifecycle.

Weaknesses are errors that can lead to vulnerabilities.

“Weaknesses” are flaws, faults, bugs, vulnerabilities, or other errors in software or hardware implementation, code, design, or architecture that if left unaddressed could result in systems, networks, or hardware being vulnerable to attack.

Vulnerability (취약점)

an occurrence of a weakness (or multiple weaknesses) within a product, in which the weakness can be used by a party to cause the product to modify or access unintended data, interrupt proper execution, or perform incorrect actions that were not specifically granted to the party who uses the weakness.

Computer Security & OS Lab, DKU

- 22 -

CWE-701 (Weaknesses Introduced During Design)

This view lists weaknesses that can be introduced during design.

Computer Security & OS Lab, DKU

Four main types (in square)• Category• Compound Element• View• Weakness

Sub-Classifications of Weakness (in circle)• P: Pillar• C: Class• B: Base• V: Variant

- 23 -

CWE-20: Improper Input Validation

Common Consequences

Computer Security & OS Lab, DKU

Demonstrative Examples

https://cwe.mitre.org/data/definitions/20.html

- 24 -

CWE-20: Improper Input Validation

Demonstrative Examples

Computer Security & OS Lab, DKU

This example asks the user for a height and width of an

m X n game board with a maximum dimension of 100

squares.

While this code checks to make sure the user cannot

specify large, positive integers and consume too much

memory, it does not check for negative values supplied

by the user.

As a result, an attacker can perform a resource

consumption (CWE-400) attack against this program by

specifying two, large negative values that will not

overflow, resulting in a very large memory allocation

(CWE-789) and possibly a system crash.

Alternatively, an attacker can provide very large

negative values which will cause an integer overflow

(CWE-190) and unexpected behavior will follow

depending on how the values are treated in the

remainder of the program.

- 25 -

CWEs are applicable to the threat modeling process

CWE

a community-developed formal list or dictionary of common software weaknesses.

Computer Security & OS Lab, DKU

CWE Entries include:• name of the weakness type

• description of the type

• alternate terms for the weakness

• description of the behavior of the weakness

• description of the exploit of the weakness

• likelihood of exploit for the weakness

• description of the consequences of the exploit

• potential mitigations

• node relationship information

• source taxonomies

• code samples for the languages/architectures

• CVE identifiers of vulnerabilities for which that type of weakness exists

• references

- 26 -

CWEs are applicable to the threat modeling process

CWE-287: Improper authentication is an example of weakness that could be exploited by a Spoofing threat

CWE-264: Permissions, Privileges, and Access Controls is a parent weakness of many Tampering,

Repudiation and Elevation of Privilege threats

CWE-311: Missing Encryption of Sensitive Data is an example of an Information Disclosure threat

CWE-400: Uncontrolled resource consumption (‘Resource Exhaustion’) is one example of an unmitigated

Denial of Service threat

※ Much of CWE focuses on implementation issues, and Threat Modeling is a design-time event.

Design(CWE-701): Weaknesses introduced During Design

Implementation(CWE-702): Weaknesses introduced During Implementation

Security mechanisms(CWE-254)

Computer Security & OS Lab, DKU

Source: Fundamental Practices for Secure Software Development, 2ND EDITION

- 27 -

Threat Modeling

Once identified, each threat must be evaluated and mitigated according to the risk attached to it, the resources available, the business case and the system requirements.

CWSS provides a mechanism for prioritizing software weaknesses in a consistent, flexible, open manner.

CWSS: “Common Weakness Scoring System”; https://cwe.mitre.org/cwss/cwss_v1.0.1.html

This will help prioritize the order in which threats should be addressed, as well as the costs involved in the mitigation.

An example of a portion of a test plan derived from a Threat Model could be:

Computer Security & OS Lab, DKU

Threat Identified Design Element(s) Mitigation Verification

Session Hijacking

GUI Ensure random session identifiers of appropriate length

Collect session identifiers over a number of sessions and examine distribution and length

Tampering with data in transit

Process A on server to Process B on client

Use SSL to ensure that data isn’t modified in transit

Assert that communication cannot be established without the use of SSL

Source: Fundamental Practices for Secure Software Development, 2ND EDITION

brk

Secure Coding in Implementation phase

Computer Security & OS Lab, DKU

- 29 -

Secure Coding Practices (Implementation Phase)

Deprecate Unsafe Functions

Minimize use of Unsafe String and Buffer Functions

Automatic use of safer functions

VisualC++:–D_CRT_SECURE_CPP_OVERLOAD_ STANDARD_NAMES=1

gcc: –D_FORTIFY_SOURCE=2 –O2

CWE References related to memory & Buffer CWE-119: Improper Restriction of Operations within the Bounds of a

Memory Buffer

CWE-120: Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

CWE-805: Buffer Access with Incorrect Length Value

Computer Security & OS Lab, DKU

Source: Fundamental Practices for Secure Software Development, 2ND EDITION

ISO/IEC TR 24731(Safer C lib functions)

- 30 -

Secure Development

Array index

unsigned short or unsigned int

Index cannot be negative number

Compile option

-fstack-protector

Thus, no stack smashing due to a local variable (buffer)

Return address, Saved EBP are not changed

Computer Security & OS Lab, DKU

char canary[4];unsigned short j, k;int cmu[5];int mit[5];

scanf (“%hu, %hu”, &j, &k);

cmu[j] = 0x102030;mit[k] = 0xcafebabe;

• canary: low address

• j, k

• cmu[]

• mit[] : high address

- 31 -

CWE

CWE, targeted to developers and security practitioners, is a formal list of software weaknesses that:

Computer Security & OS Lab, DKU

Examples of Weakness

- 32 -

Secure Coding Practices

Validate Input and Output to Mitigate Common Vulnerabilities by considering

CWE-20: Improper Input Validation

CWE-183: Permissive List of Allowed Inputs (Permissive Whitelist, formerly)

CWE-184: Incomplete List of Disallowed Inputs (Incomplete Blacklist, formerly)

CWE-625: Permissive Regular Expression

Use Robust Integer Operations for Dynamic Memory Allocations and Array Offsets by considering

CWE-129: Improper Validation of Array Index

CWE-190: Integer Overflow or Wraparound

CWE-131: Incorrect Calculation of Buffer Size

CWE-680: Integer Overflow to Buffer Overflow

CWE-805: Buffer Access with Incorrect Length Value

Computer Security & OS Lab, DKU

- 33 -

Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors

Computer Security & OS Lab, DKU

CWE-1200

- 34 -

Helpful Views with CWE

These are based on a specific criteria and hope to provide insight for a certain domain or use case.

Computer Security & OS Lab, DKU

• CWE-658: Weaknesses in Software Written in C

• CWE-659: Weaknesses in Software Written in C++

• CWE-660: Weaknesses in Software Written in Java

• CWE-661: Weaknesses in Software Written in PHP

• CWE-999: Weaknesses without Software Fault Patterns

- 35 -

External Mappings with CWE

These views are used to represent mappings to external groupings such as a Top-N list, as well as to express subsets of entries that are related by some external factor.

Computer Security & OS Lab, DKU

- 36 -

OWASP Foundation

The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software.

Computer Security & OS Lab, DKU

Flagship Projects• OWASP Application Security Verification

Standard• OWASP Cheat Sheet Series• OWASP CSFRGuard• OWASP Defectdojo• OWASP Dependency-Check• OWASP Dependency-Track• OWASP Juice Shop• OWASP Mobile Security Testing Guide• OWASP Mobile Top 10• OWASP ModSecurity Core Rule Set• OWASP OWTF• OWASP Risk Assessment Framework• OWASP SAMM• OWASP security Knowledge Framework• OWASP Security Shepherd• OWASP Top Ten• OWASP Web Security Testing Guide

Lab Projects• OWASP AntiSamy• OWASP API Security Project• OWASP Automated Threats to Web Applications• OWASP Benchmark• OWASP Code Pulse• OWASP Cornucopia• OWASP Enterprise Security API (ESAPI)• OWASP Internet of Things• OWASP mobile security• OWASP Proactive Controls• OWASP Snakes And Ladders• OWASP Top 10 Privacy Risks• OWASP WebGoat

https://owasp.org/

- 37 -

OWASP Top 10

Open Web Application Security Project (https://owasp.org/)

Top 10 Vulnerabilities in Web applications: (https://owasp.org/www-project-top-ten/)

Security weakness, Example Attack Scenarios, How to prevent

Computer Security & OS Lab, DKU

- 38 -

OWASP WebGoat

Learn the hack - Stop the attack

WebGoat is a deliberately insecure application that allows interested developers just like you to test vulnerabilities commonly found in Java-based applications that use common and popular open source components.

https://owasp.org/www-project-webgoat/

https://webgoat.github.io/WebGoat/

Computer Security & OS Lab, DKU

- 39 -

Summary

Software Security

Is not application security

Is not security software

Secure SDLC

Threat Modeling

Secure Coding Practice

Common Weakness Enumeration (CWE)

Common Vulnerabilities and Exposures (CVE)

https://cve.mitre.org/

OWASP Top 10

Computer Security & OS Lab, DKU brk