Common Vulnerability Scoring System Engineering Secure Software - - PowerPoint PPT Presentation

▶
common vulnerability scoring system
SMART_READER_LITE
LIVE PREVIEW

Common Vulnerability Scoring System Engineering Secure Software - - PowerPoint PPT Presentation

Dec 02, 2022 189 likes •546 views

Common Vulnerability Scoring System Engineering Secure Software Last Revised: November 13, 2020 SWEN-331: Engineering Secure Software Benjamin S Meyers 1 How Bad is Bad? Weve seen many vulnerabilities Many of them can do catastrophic

slide-1
SLIDE 1

SWEN-331: Engineering Secure Software Benjamin S Meyers

Common Vulnerability Scoring System

Engineering Secure Software

Last Revised: November 13, 2020 1

slide-2
SLIDE 2

SWEN-331: Engineering Secure Software Benjamin S Meyers

How Bad is Bad?

  • We’ve seen many vulnerabilities

○ Many of them can do catastrophic things ○ Danger really depends on the situation

  • Many, many situational factors, such as:

○ Asset exposed (and its relative importance) ○ Remotely or locally exploitable? ○ Expertise needed to exploit the vulnerability? ○ Affects all deployments? ○ Impact on CIA properties? ○ How good is the reporting as of now?

2

slide-3
SLIDE 3

SWEN-331: Engineering Secure Software Benjamin S Meyers

CVSS

  • Common Vulnerability Scoring System

○ Adopted by NIST (National Institute of Standards & Technology) ○ Required for reporting a vulnerability in CVE ○ Note: we are studying v3, most of the world still uses v2

  • An open scoring system from FIRST

○ FIRST: Forum for Incident Response & Security Teams ○ Group of researchers and practitioners

  • Three metric groups

○ Base: no changes over time or environment ○ Environmental: might vary in different deployments ○ Temporal: might change over time ○ Essentially a weighted average

3

slide-4
SLIDE 4

SWEN-331: Engineering Secure Software Benjamin S Meyers

CVSS: Base Metric Group

  • Exploitability metrics:

characteristics of the thing that is vulnerable

  • Impact metrics: represent

the consequence to the thing that suffers the impact

  • Exploit(AV, AC, PR, UI),

Impact(C, I, A), S

4

AC: Attack Complexity AV: Attack Vector Confidentiality Impact

Base Metric Group

Exploitability Metrics Impact Metrics

PR: Privileges Required UI: User Interaction Integrity Impact Availability Impact Scope

slide-5
SLIDE 5

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Attack Vector (AV)

  • Regarding networking, what are the methods of exploiting?
  • Metric values:

○ (P) Physical ○ (L) Local Only ○ (A) Adjacent Network (e.g. wifi, local IP subnet) ○ (N) Network (fully remotely exploitable)

  • Assumption:

○ The more remote the AV, the more likely it is to be exploited

  • Examples:

○ Client that opens stuff from an untrusted internet source? Go with (N) Network (e.g. zip utility with a buffer overflow)

5

slide-6
SLIDE 6

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Attack Vector (AV)

  • Examples:

○ Client that opens stuff from an untrusted internet source? Go with (N) Network (e.g. zip utility with a buffer overflow) ○ XSS in a web application?

6

slide-7
SLIDE 7

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Attack Vector (AV)

  • Examples:

○ Client that opens stuff from an untrusted internet source? Go with (N) Network (e.g. zip utility with a buffer overflow) ○ XSS in a web application? (N) Network ○ ARP Spoofing?

7

slide-8
SLIDE 8

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Attack Vector (AV)

  • Examples:

○ Client that opens stuff from an untrusted internet source? Go with (N) Network (e.g. zip utility with a buffer overflow) ○ XSS in a web application? (N) Network ○ ARP Spoofing? (A) Adjacent Network ○ Side-channel attacks?

8

slide-9
SLIDE 9

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Attack Vector (AV)

  • Examples:

○ Client that opens stuff from an untrusted internet source? Go with (N) Network (e.g. zip utility with a buffer overflow) ○ XSS in a web application? (N) Network ○ ARP Spoofing? (A) Adjacent Network ○ Side-channel attacks? (L) Local

9

slide-10
SLIDE 10

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Attack Complexity (AC)

  • How complex would the exploit be?

○ One step? (e.g. buffer overflow) ○ Multiple steps? (e.g. convince an email user to download a malicious attachment)

  • Metric values:

○ (H) High: specialized access conditions

■ e.g. overcoming advanced exploit mitigation techniques ■ e.g. man-in-the-middle attack

○ (L) Low: no specialized conditions

■ e.g. default configuration ■ e.g. requires little skill to perform

  • (L) → higher metric score, (H) → lower metric score

10 10

slide-11
SLIDE 11

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Privileges Required (PR)

  • Level of privileges needed for exploit?
  • Metric values:

○ (H): privileges that provide significant control (e.g. admin) ○ (L): privileges that provide basic user capabilities ○ (N): no authorization needed

  • The fewer privileges necessary, the higher the metric score
  • Examples:

○ In an authentication system (e.g. Kerberos) itself? (N) None

11 11

slide-12
SLIDE 12

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Privileges Required (PR)

  • Examples:

○ In an authentication system (e.g. Kerberos) itself? (N) None ○ Path traversal in photo upload for Twitter client?

12 12

slide-13
SLIDE 13

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Privileges Required (PR)

  • Examples:

○ In an authentication system (e.g. Kerberos) itself? (N) None ○ Path traversal in photo upload for Twitter client? (L) Low ○ Insecure PRNG for session ID’s?

13 13

slide-14
SLIDE 14

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Privileges Required (PR)

  • Examples:

○ In an authentication system (e.g. Kerberos) itself? (N) None ○ Path traversal in photo upload for Twitter client? (L) Low ○ Insecure PRNG for session ID’s? (N) None

14 14

slide-15
SLIDE 15

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: User Interaction (UI)

  • A user, other than the attacker, participates in the exploit
  • Metric values:

○ (N): can be exploited without interaction from any user ○ (R): requires a user to take action(s)

■ e.g. exploit may only be possible during the installation of an application by a system administrator

  • Examples:

○ Reflected XSS? (R) -- user must click on a link ○ CSRF? (R) -- need a victim to forge the HTTP request and be logged in

  • The less user interaction required, the higher the metric score

15 15

slide-16
SLIDE 16

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: Scope (S)

  • The ability for a vulnerability in one software component to

impact resources beyond its means or privileges

  • Metric values:

○ (U)Unchanged: the vulnerable component and the impacted component are the same ○ (C) Changed: the vulnerable component and the impacted component are different

  • Examples:

○ Vulnerability in Linux VM that compromises host OS? (C) ○ Sandbox violations? (C)

  • Scoped changed → higher metric score

16 16

slide-17
SLIDE 17

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: CIA Impact

  • Any impact on Confidentiality, Integrity, or Availability?

○ These are separate metrics

  • Metric values (for each C, I, and A):

○ (N) None ○ (L) Low ○ (H) High

  • CIA of the system, not the user
  • Examples:

○ Disclosing a few database tables? C=Low, I=None, A=None

17 17

slide-18
SLIDE 18

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: CIA Impact

  • Examples:

○ Disclosing a few database tables? C=Low, I=None, A=None ○ Temporary DoS?

18 18

slide-19
SLIDE 19

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: CIA Impact

  • Examples:

○ Disclosing a few database tables? C=Low, I=None, A=None ○ Temporary DoS? C=None, I=None, A=Low ○ Reading arbitrary memory locations?

19 19

slide-20
SLIDE 20

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: CIA Impact

  • Examples:

○ Disclosing a few database tables? C=Low, I=None, A=None ○ Temporary DoS? C=None, I=None, A=Low ○ Reading arbitrary memory locations? C=High, I=None, A=None ○ Full bypass of plugin sandbox?

20 20

slide-21
SLIDE 21

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base: CIA Impact

  • Examples:

○ Disclosing a few database tables? C=Low, I=None, A=None ○ Temporary DoS? C=None, I=None, A=Low ○ Reading arbitrary memory locations? C=High, I=None, A=None ○ Full bypass of plugin sandbox? C=?, I=High, A=None ○ Root-level access? C=I=A=High ○ Hardcoded root credentials in blog software? C=I=A=High

21 21

slide-22
SLIDE 22

SWEN-331: Engineering Secure Software Benjamin S Meyers

CVSS: Environmental Metric Group

  • Modified base metrics

○ Loss of life, physical assets, productivity ○ Levels: None, Low, Medium, High, Not Defined

  • Security Requirements (CR, IR, AR)

○ Levels: ■ (X) Not Defined: it will not influence the score ■ (H) High: a catastrophic adverse effect ■ (M) Medium: a serious adverse effect ■ (L) Low: a limited adverse effect

22 22

slide-23
SLIDE 23

SWEN-331: Engineering Secure Software Benjamin S Meyers

CVSS: Temporal Exploitability (E)

  • Is there a public exploit known?
  • Metric values:

○ (U) Unproven: entirely theoretical exploit ○ (POC): Proof of Concept exists, no known malicious exploits ○ (F): Functional exploit is available ○ (H): Functional exploit is widely disseminated ○ (X) Not Defined (skip this part of the metric)

  • Notes:

○ Being temporal, this could change quickly ○ Many white hats will write exploits to make this score go up, so that it gets fixed

23 23

slide-24
SLIDE 24

SWEN-331: Engineering Secure Software Benjamin S Meyers

CVSS: Temporal Remediation (RL)

  • What is the level of remediation (RL)?
  • How has the vendor reacted?
  • Metric levels:

○ (O): Official fix is available ○ (TF): Temporary fix is available ○ (W): Workaround is available ○ (U): Nothing is released yet ○ (X): Not defined

  • Workarounds:

○ Unofficial, non-vendor patches ○ Temporary configuration change

24 24

slide-25
SLIDE 25

SWEN-331: Engineering Secure Software Benjamin S Meyers

CVSS: Temporal Confidence (RC)

  • What is the report confidence (RC)?
  • Metric levels:

○ (U): Unconfirmed by the source, or multiple conflicting reports ○ (R): Significant details are published (e.g. proof-of-concept) ○ (C): Confirmed by the source ○ (ND): Not defined

25 25

slide-26
SLIDE 26

SWEN-331: Engineering Secure Software Benjamin S Meyers

Scoring Tips

  • Ignore interactions with other vulnerabilities, score each

individually

  • Emphasize targets to the host, not necessarily other users

○ e.g. XSS is a partial impact on integrity, but not full because it doesn’t affect the host

  • Assume the most common or default configuration on the

server

  • Score the greatest exploitation impact, if there are many

26 26

slide-27
SLIDE 27

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example: CVE-2015-7197

  • “Mozilla Firefox before [...] improperly control the ability of a

web worker to create a WebSocket object, which allows remote attackers to bypass intended mixed-content restrictions via crafted JavaScript code.”

○ Web workers: long-running JavaScript tasks that do not interrupt the user ○ Mixed-content restrictions: cannot use one WebSocket for multiple protocols (e.g. both HTTPS and SSH)

27 27

slide-28
SLIDE 28

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example: CVE-2015-7197

  • Access Vector (AV)?

○ (N) Network

  • Privileges Required (PR)?

○ (N) None

  • User Interaction (UI)?

○ (N) None (usually)

  • Attack Complexity (AC)?

○ (L) Low (more details needed)

28 28

slide-29
SLIDE 29

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example: CVE-2015-7197

  • Access Vector (AV)?

○ (N) Network

  • Privileges Required (PR)?

○ (N) None

  • User Interaction (UI)?

○ (N) None (usually)

  • Attack Complexity (AC)?

○ (L) Low (more details needed)

29 29

  • Confidentiality?

○ (N) None (possibly low depending on worker’s access)

  • Integrity?

○ (L) Low (allows access to sockets)

  • Availability?

○ (N) None

slide-30
SLIDE 30

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base Weights

30 30

Source: https://www.first.org/cvss/specification-document

slide-31
SLIDE 31

SWEN-331: Engineering Secure Software Benjamin S Meyers

Base Weights

31 31

Source: https://www.first.org/cvss/specification-document

slide-32
SLIDE 32

SWEN-331: Engineering Secure Software Benjamin S Meyers

Weighting & Vectors

  • Weights were derived from

○ Security experts got together (mostly industry) and analyzed a bunch of vulnerabilities in their products ○ Agreed on all labels for each vulnerability ○ Agreed on overall ranking of many previous vulnerabilities ○ Adjusted the weights to match from there

  • CVSS writers recommend

○ Using their calculator: https://www.first.org/cvss/calculator/3.1 ○ Report each level along with the weighting

■ Weights may evolve ■ Comparing two vulnerabilities can be done at a finer level than just numbers

32 32

slide-33
SLIDE 33

SWEN-331: Engineering Secure Software Benjamin S Meyers

Alternative: CWSS

  • Common Weakness Scoring System

○ Relatively recent (~2010) response to CVSS ○ More detailed, but not as widely-adopted ○ Categories: Base, Attack Surface, Environmental

  • Base Finding Metric Group

○ 5 metrics total ○ e.g. Acquired Privilege

■ User-level access required

○ e.g. Acquired Privilege Layer

■ Access to network, app, entire enterprise

○ e.g. Internal Control Effectiveness

■ Would our internal detection measures have been effective? Would we have known this was exploited?

33 33

slide-34
SLIDE 34

SWEN-331: Engineering Secure Software Benjamin S Meyers

Alternative: CWSS

  • Attack Surface Metric Group

○ 7 metrics total ○ e.g. Required Privilege & Required Privilege Layer

■ How much authentication was needed?

○ e.g. Level of Interaction

■ How much social engineering is required?

  • Environmental Impact Metric Group

○ 6 metrics total ○ e.g. Business Impact, Likelihood of Discovery, Likelihood of Exploit ○ e.g. Remediation Effort

■ Is this really difficult to fix? Should we be worried about this coming up again or being incorrectly fixed?

34 34

slide-35
SLIDE 35

SWEN-331: Engineering Secure Software Benjamin S Meyers

Activity

  • Let’s assess four vulnerabilities from industry

○ One from: PHP, Chromium, Apache Tomcat, Linux Kernel

■ Patches are reports are linked in ■ Feel free to use the internet to make your decisions (but don’t look at any CVSS scorings online!)

○ CVSS base score only ○ Also: two “detection” questions

■ Domain-specific? ■ New code or changed code?

  • In groups of 4-6

○ Planning Poker-like discussion ○ First: answer all four vulnerabilities for one question ○ Then: focus on one vulnerability at a time for all other questions

35 35