Common Vulnerability Scoring System Engineering Secure Software - PowerPoint PPT Presentation

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? 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? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 2

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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 3

CVSS: Base Metric Group Exploitability metrics: ● Base Metric Group characteristics of the thing Exploitability Impact Metrics Metrics that is vulnerable AV: Attack Confidentiality Vector Impact Impact metrics: represent ● the consequence to the AC: Attack Integrity Complexity Impact thing that suffers the impact PR: Privileges Availability Required Impact Exploit(AV, AC, PR, UI), ● UI: User Interaction Impact(C, I, A), S Scope SWEN-331: Engineering Secure Software Benjamin S Meyers 4

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) SWEN-331: Engineering Secure Software Benjamin S Meyers 5

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? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 6

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? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 7

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? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 8

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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 9

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 ● SWEN-331: Engineering Secure Software Benjamin S Meyers 10 10

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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 11 11

Base: Privileges Required (PR) Examples: ● In an authentication system (e.g. Kerberos) itself? (N) None ○ Path traversal in photo upload for Twitter client? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 12 12

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? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 13 13

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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 14 14

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 ● SWEN-331: Engineering Secure Software Benjamin S Meyers 15 15

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 ● SWEN-331: Engineering Secure Software Benjamin S Meyers 16 16

Base: CIA Impact Any impact on C onfidentiality, I ntegrity, or A vailability? ● 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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 17 17

Base: CIA Impact Examples: ● Disclosing a few database tables? C=Low, I=None, A=None ○ Temporary DoS? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 18 18

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? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 19 19

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? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 20 20

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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 21 21

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 ■ SWEN-331: Engineering Secure Software Benjamin S Meyers 22 22

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 SWEN-331: Engineering Secure Software Benjamin S Meyers 23 23