Notes - MCS
Analysis and Exploration of Vulnerabilities
Notes - MCS
Analysis and Exploration of Vulnerabilities
  • Analysis and Exploration of Vulnerabilities
  • Vulnerabilities
    • Vulnerabilities
      • CIA Triad
      • Vulnerability Sources
    • Vulnerability Tracking
    • Vulnerability Disclosure
  • Vulnerability Assessment of Networked Systems
    • Vulnerability Research
    • Vulnerability Assessment
    • Penetration Test
      • Scope
    • Types of Assessments
    • Vulnerability Management Life Cycle
  • Enumeration and Information Leakage
    • Network access
    • Information leakage
    • Errors
    • Web Sources and Support Files
    • Cookies
    • Ports
    • Banners
    • OS Fingerprinting
  • Injection
    • CWE-74
    • How it works
    • Common Pitfalls
    • CWE-89 SQL Injection
    • Using SQL
    • Things to consider
    • The NULL plate
    • SQLi types
    • SQL Injection - Avoiding
    • CWE-78 OS Command Injection
    • Command Override
    • Argument Exploitation
    • GTFOBins and LOLBAS
    • Environmental Variables
    • Parameter Expansion
    • Code Injection - CWE-94
    • Avoiding OS Injection
  • Broken Authentication
    • OWASP A2
    • HTTP Basics
    • HTTP Communication
    • Authentication
    • Authentication Flow State
    • Referer Header
    • SESSION ID
    • Cookies (RFC 6265)
    • JWT - JSON Web Tokens
  • XSS Cross Site Scripting
    • Prevalence and Detectability
    • Reflected XSS
    • Stored XSS
    • DOM XSS
    • Cross Site Request Forgery
    • Avoiding XSS
    • Same Origin Policy
  • Concurrency
    • Concurrency
    • CWE-361 - 7PK - Time and State
    • Basic Time Related CWEs
      • CWE-362 – Race Condition
    • Serializability
    • Database ACID characteristic
    • State Related CWEs
    • Basic Side Effects Related CWEs (Covert Channel)
    • Covert Timing Channel
    • Meltdown Type
  • Buffers
    • Buffer Overflow
    • Popularity decline
    • Potentially Vulnerable Software
    • Dominant prevalence
    • Vulnerabilities in languages (mostly C/C++)
    • Why? Memory Structure 101
    • CWE-120 Classic Overflow
      • Practical Examples
    • Stack Based Vulnerabilities
    • Stack Smashing
    • Countermeasures
    • ROP
Powered by GitBook
On this page
  • Establish a Baseline
  • Vulnerability Assessment
  • Assessment Methods
  • Assessment Strategies
  • Risk Assessment
  • Documentation
  • Remediation
  • Verification
  • Monitoring
  1. Vulnerability Assessment of Networked Systems

Vulnerability Management Life Cycle

Last updated 1 year ago

Establish a Baseline

Select the assets to be assessed and define priorities.

  • Some assets may be excluded due to potential impact or cost.

Characterize the systems/software state.

Determine what is known and what must be assessed.

  • Known vulnerabilities may be ignored from the assessment.

Vulnerability Assessment

Assess the entities for vulnerabilities.

  • Takes into consideration priorities.

  • Takes into consideration scope.

Construct a detailed report with:

  • What vulnerability was found?

  • What are the affected entities?

  • What are the recommendations to handle it?

Assessment usually doesn’t exploit the vulnerability or build an exploit chain.

  • It’s not a penetration test.

Assessment Methods

A subject close to software testing but with a focus on security-related impact.

  • Extensively studied in the Robust Software course.

Highly dependent on the scope of the assessment.

  • Application: Static, Dynamic, or Component Analysis.

  • Network entity: Protocol, message, authentication, authorization analysis.

  • Processes/Companies: OSINT, Social Engineering.

Assessment Strategies

Black Box

Researchers have no information about internal aspects and are presented with a publicly available view.

  • No source code, no documentation.

  • Assumes an actor with a specific set of resources.

    • Script kiddie, a researcher, competitor, a crowd-based effort.

Aims to mimic assessments from outside attackers.

  • Finds what can be explored by intruders with no access.

    • Usually finds vulnerabilities easier to exploit.

  • May find alternative paths and use cases (which may present vulnerabilities).

Limited on the impact of the assessment.

  • Existing vulnerabilities with remedies (e.g. Firewall) may not be detected.

White Box

Researchers are given full documentation and access to systems.

  • A replica of the production system.

  • The production system with a limited scope.

  • The source code and infrastructure code.

Aims to find faults and bugs in all scoped domains.

  • Assumes an actor at any location (insider and outsider).

  • Finds what can be exploited by: outsiders, insiders, outsiders with lateral movement.

  • May mimic specific users and roles.

Extensive (and expensive) analysis of the domains.

  • Remedies are known and considered, but vulnerability may still be found.

Gray Box

Some information is provided to researchers.

  • Documentation about the application or systems.

  • A specific set of credentials.

Aims to find faults and bugs in a limited set of scoped domains.

  • Can mimic a specific user.

Risk Assessment

The company takes into consideration the report and assesses the risk.

  • For every asset with vulnerabilities.

  • Assign risk indicators (3-4 levels).

Risk assessment may take into consideration all vulnerabilities found.

  • Individual vulnerabilities may be combined in an exploit chain with higher impact.

Documentation

Researchers should carefully document assessments.

  • Describe the rationale for the assessment, the strategy, and the findings.

  • Essential in cooperation between teams.

Important to understand how vulnerability was explored, and what the impact may be.

  • Wrong attitude: we found this, you are not doing your job.

  • Correct attitude: we found this, which may be caused by that, this is the impact, you may fix it by doing X.

    • Clients may not understand the vulnerability, the reason, or the impact.

Remediation

The company implements methods to increase the security of its assets.

May fix the vulnerability.

  • Correct software bugs or flaws.

  • Implement specific configurations.

  • Update software/firmware.

  • This capability is not always present.

May reduce the impact of a successful exploitation.

  • Implement mechanisms that reduce impact to a smaller domain.

  • Implement redundancy and fail recovery.

This may increase the cost of exploiting the vulnerability.

  • Deploy firewalls or change its rules.

  • Increase isolation so that assets are not available in a domain.

Verification

Verifies the effectiveness of the remediation.

Involves assessing the existence and risk of the vulnerabilities found.

  • Using the same scope!

  • Vulnerability risk may be similar if explored from other perspectives.

    • E.g. External vs Internal actor.

Monitoring

Deploys mechanism to detect the vulnerability being explored.

  • May consider variations.

Involves configuring Firewalls, log analysis systems, IDS/NIDS/HIDS, profillers.