🕶️
VICEINTELPRO
GitHub: HorrorClause
  • In Tenebris Videmus
  • 🚩CTFs
    • 💾Hack the Box
      • 🏫Academy
        • Command Injection Assessment
        • XSS Assessment
        • Web Attacks Assessment
    • Try Hack Me
      • In Progress
  • 📖Documents
  • 👨‍🏫HOW-TOs
    • Obisidian How-To
    • Setup Mandiant FLARE VM
  • 📑Security Fundamentals
    • Security Controls
      • Physical Security
      • Endpoint Security
      • Email Security
      • Network Security
      • AAA Controls
    • Networking 101
      • OSI Model
      • Network Fundamentals
      • Network Devices
      • Network Tools
      • Protocols and Ports
    • 👨‍💼Management Principles
      • Risk
      • Policies and Procedures
      • Compliance and Frameworks
      • Change and Patch Management
  • 🛡️Security Concepts
    • ⚠️Risk Assessment Models
      • DREAD Risk Assessment Model
      • STRIDE Threat Model
      • Common Vulnerability Scoring System (CVSS)
    • Pentesting
      • Common Terms
      • AV Identification-Evasion
      • Introduction to Payloads
      • Automating Payloads & Delivery with Metasploit
      • Shells Jack Us In, Payloads Deliver Us Shells
      • Web Shells
      • Pentesting Overview
      • Penetration Testing Process
    • 🐛Vulnerability Assessment
      • Common Vulnerabilities and Exposures (CVE)
      • Common Vulnerability Scoring System (CVSS)
      • Assessment Standards
      • Vulnerability Assessment
      • Vulnerability Scanning
      • Reporting
      • 🎯Nessus
        • Getting Started with Nessus
        • Nessus Scan
        • Working with Nessus Scan Output
        • Advanced Settings
        • Scanning Issues
      • 🦴OpenVAS (Greenbone)
        • Getting Started with OpenVAS
        • OpenVAS
        • Exporting Results
    • Passwords
      • Password Managers
      • Password Policies
      • Password Security Fundamentals
    • Frameworks
    • GRC
    • Logon Types
    • What is Dev-Null ?
  • ⚔️Offensive Security
    • OSINT
      • OSINT - Websites
      • Google Dorks
    • 🔫Attacking Common Services
      • The Concept of Attacks
      • Interacting with Common Services
      • Finding Sensitive Information
      • Attacking DNS
      • Attacking Email Services
      • Attacking FTP
      • Attacking RDP
      • Attacking SMB
      • Attacking SQL Databases
      • Cheat Sheet - Attacking Common Services
      • Service Misconfigurations
    • 🔪Attacking Web Apps with Ffuf
      • Web Fuzzing
      • Directory Fuzzing
      • Page Fuzzing
      • Recursive Fuzzing
      • DNS Records
      • Sub-domain Fuzzing
      • Vhost Fuzzing
      • Filtering Results
      • Parameter Fuzzing - GET
      • Parameter Fuzzing - POST
      • Value Fuzzing
    • ☁️Cloud
      • AWS
        • AWS S3 Buckets
    • 💉Command Injection
      • Command Injection Cheat Sheet
      • Intro to Command Injections
      • Detection
      • Injecting Commands
      • Other Injection Operators
      • Identifying Filters
      • Bypassing Space Filters
      • Bypassing Other Blacklisted Characters
      • Bypassing Blacklisted Commands
      • Advanced Command Obfuscation
      • Evasion Tools
      • Command Injection Prevention
    • Containers
      • Docker
    • ❌Cross-Site Scripting (XSS)
      • Introduction to XSS
      • Stored XSS
      • Reflected XSS
      • DOM XSS
      • XSS Discovery
      • Defacing
      • Phishing
      • Session Hijacking
      • XSS Prevention
    • Directory Busting
      • DirB
      • DirBuster
      • Ffuf
      • Gobuster
    • 🅰️DNS
      • DNSRecon
      • Fierce
    • File Inclusion
      • Local File Inclusion Cheatsheet
      • Intro to File Inclusion
      • Local File Inclusion (LFI)
      • Basic Bypass
      • PHP Filters
      • PHP Wrappers
      • Remote File Inclusion (RFI)
      • LFI and File Uploads
      • Log Poisoning
      • Automated Scanning
      • File Inclusion Prevention
    • File Transfers
      • Transferring Files
      • File Transfer - Quick Commands
      • Living off the Land
      • Windows File Transfer Methods
      • Linux File Transfer Methods
      • Catching Files over HTTP(S)
      • Transferring Files with Code
      • Miscellaneous File Transfer Methods
      • Protected File Transfers
      • Mounting Encrypted VHD Drives
      • Mounting VHD in Kali
      • File Transfer Detection
    • File Upload Attacks
      • File Upload Cheatsheet
      • Absent Validation
      • Upload Exploitation
      • Client-Side Validation
      • Blacklist Filters
      • Whitelist Filters
      • Type Filters
      • Limited File Uploads
      • Other Upload Attacks
      • Preventing File Upload Vulnerabilities
    • 👣Footprinting
      • Linux Remote Management Protocols
      • Windows Remote Management Protocols
      • Enumeration
        • Enumeration Methodology
        • 🖥️Host Based
          • Quick Commands
          • DNS
          • FTP
          • IMAP-POP3
          • IPMI
          • MSSQL
          • MySQL
          • NFS
          • Oracle TNS
          • SMB
  • Powershell
    • Powershell CheatSheet
  • Python
    • Map
    • Anonymous Functions
    • Recursion
      • ZipMap
      • Nested Sum
      • Recursion on a Tree
      • Count Nested Levels
      • Longest Word
    • Function Transformations
      • More Transformations
      • Why Transform?
    • Closures
    • Currying
    • Decorators
    • Sum Types
    • Enums
    • Match
    • Regex
  • Kusto (KQL)
    • SQL and KQL Comparison
    • Using the Where and Sort Operators
    • KQL Queries
  • HTML
  • Insecure File Uploads
Powered by GitBook
On this page
  • Open Vulnerability Assessment Language (OVAL)
  • OVAL Process
  • OVAL Definitions
  • Common Vulnerabilities and Exposures (CVE)
  • Stages of Obtaining a CVE
  • Stage 1: Identify if CVE is Required and Relevant
  • Stage 2: Reach Out to Affected Product Vendor
  • Stage 3: Identify if Request Should Be For Vendor CNA or Third Party CNA
  • Stage 4: Requesting CVE ID Through CVE Web Form
  • Stage 5: Confirmation of CVE Form
  • Stage 6: Receival of CVE ID
  • Stage 7: Public Disclosure of CVE ID
  • Stage 8: Announcing the CVE
  • Stage 9: Providing Information to The CVE Team
  • Responsible Disclosure
  • Examples
  • CVE-2020-5902
  • CVE-2021-34527
  1. Security Concepts
  2. Vulnerability Assessment

Common Vulnerabilities and Exposures (CVE)

PreviousVulnerability AssessmentNextCommon Vulnerability Scoring System (CVSS)

Last updated 4 months ago

Open Vulnerability Assessment Language (OVAL)

is a publicly available information security international standard used to evaluate and detail the system's current state and issues. OVAL is also co-supported by the office of Cybersecurity and Communications from the U.S. Department of Homeland Security. OVAL provides a language to understand encoding system attributes and various content repositories shared within the security community. The OVAL repository has over 7000+ definitions for public use. Additionally, OVAL is also used by the U.S. National Institute of Standards and Technology's (NIST) Security Content Automation Protocol (SCAP) which brings together community ideas for automating vulnerability management, measurement, and ensuring systems meet policy compliance.

OVAL Process

The goal of the OVAL language is to have a three-step structure during the assessment process that consists of:

  • Identifying a system's configurations for testing

  • Evaluating the current system's state

  • Disclosing the information in a report

The information can be described in various types of states, including: Vulnerable, Non-compliant, Installed Asset, and Patched.

OVAL Definitions

The OVAL definitions are recorded in an XML format to discover any software vulnerabilities, misconfigurations, programs, and additional system information taking out the need to exploit a system. By having the ability to identify issues without directly exploiting the issue, an organization can correlate which systems need to be patched in a network.

The four main classes of OVAL definitions consist of:

  • OVAL Vulnerability Definitions: Identifies system vulnerabilities

  • OVAL Compliance Definitions: Identifies if current system configurations meet system policy requirements

  • OVAL Inventory Definitions: Evaluates a system to see if a specific software is present

  • OVAL Patch Definitions: Identifies if a system has the appropriate patch

Additionally, the OVAL ID Format consist of a unique format that consists of "oval:Organization Domain Name:ID Type:ID Value". The ID Type can fall into various categories including: definition (def), object (obj), state (ste), and variable (var). An example of a unique identifier would be oval:org.mitre.oval:obj:1116.

Scanners such as Nessus have the ability to use OVAL to configure security compliance scanning templates.

Common Vulnerabilities and Exposures (CVE)

Common Vulnerabilities and Exposures (CVE) is a publicly available catalog that identifies and tracks cybersecurity vulnerabilities and exposures. Sponsored by the United States Department of Homeland Security (DHS), CVE provides a standardized method for naming, defining, and cataloging vulnerabilities that are found in software, hardware, or network environments. Each security issue is assigned a unique CVE ID number by a CVE Numbering Authority (CNA), which ensures consistency and clarity in the tracking of vulnerabilities.

The primary purpose of CVE is to create a common identifier for vulnerabilities so that researchers, cybersecurity professionals, and organizations can accurately share information and implement remediation strategies. CVE entries include critical information such as:

  • CVE ID: A unique identifier (e.g., CVE-2021-34527) for the specific vulnerability or exposure.

  • Description: A concise explanation of the vulnerability, including the risk or potential damage it may cause.

  • References: Links to detailed resources like vendor advisories, security patches, and external reports that can help mitigate the risk.

By creating these standardized entries, CVE helps organizations understand the scope and severity of a particular vulnerability, allowing them to prioritize responses effectively. This system is vital in vulnerability management, as IT teams can use CVE identifiers to quickly assess and respond to risks. Additionally, the CVE database is leveraged by various security tools and platforms to automate processes such as patch management and risk assessment.

For example, the PrintNightmare vulnerability (CVE-2021-34527) in the Windows Print Spooler service allowed attackers to remotely execute arbitrary code. The CVE entry for this issue provided a unique identifier that organizations could use to track and address the problem, whether through patching, configuration changes, or other mitigations.

The following chart explains how a CVE ID may be assigned to a vulnerability. Any vulnerabilities assigned a CVE must be independently fixable, affect just one codebase, and be acknowledged and documented by the relevant vendor.

Stages of Obtaining a CVE

Stage 1: Identify if CVE is Required and Relevant

Identify if the issue found is a vulnerability. According to the CVE Team, "A vulnerability in the context of the CVE Program is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change, or specification deprecation to mitigate or address." Additionally, research should verify there is not a CVE ID already in the CVE database.

Stage 2: Reach Out to Affected Product Vendor

Stage 3: Identify if Request Should Be For Vendor CNA or Third Party CNA

Stage 4: Requesting CVE ID Through CVE Web Form

Stage 5: Confirmation of CVE Form

Upon submitting the CVE Web Form mentioned in Stage 4, an individual will receive a confirmation email. The CVE team will contact the requestor if any additional information is required.

Stage 6: Receival of CVE ID

Upon approval, the CVE Team will notify the requestor of a CVE ID if the affected product's vulnerability is confirmed. Please note that the CVE ID is not public yet at this stage.

Stage 7: Public Disclosure of CVE ID

CVE IDs can be announced to the public as soon as appropriate vendors and parties are aware of the issue to prevent duplication of CVE IDs. This stage ensures that all associated parties are aware of the problem before being publicly disclosed.

Stage 8: Announcing the CVE

Stage 9: Providing Information to The CVE Team

Responsible Disclosure

Security researchers and consultants constantly reference the CVE database since it consists of thousands of vulnerabilities that could be leveraged for exploitation. In addition, there are also times when individuals may come across an issue they have never seen in the wild or it has never disclosed while digging into a specific software or program.

Responsible disclosure is essential in the security community because it allows an organization or researcher to work directly with a vendor providing them with the issue details first to ensure a patch is available before the vulnerability announcement to the world. If an issue is not responsibly disclosed to a vendor, real threat actors may be able to leverage the issues for criminal use, also referred to as a zero day or an 0-day.

Examples

CVE-2020-5902

CVE-2021-34527

CVE is maintained by the MITRE Corporation, with collaboration from the global cybersecurity community, ensuring that it remains a comprehensive and trusted resource for identifying, sharing, and mitigating vulnerabilities. For more information, you can visit the official CVE website at .

A researcher should ensure they have made a good faith effort to contact a vendor directly. Researchers can reference CVE's for additional information.

If a company is a part of participating CNA's, they can assign a CVE ID for one of their products. If the issue is for a participating CNA, researchers can contact the appropriate CNA organization . If the vendor is not a participating CNA, a researcher should attempt to reach out to the vendor's third-party coordinator.

The CVE Team has a form that can be filled out online if the methods above do not work for CVE requests.

The CVE Team asks researchers who are sharing multiple CVEs to ensure each CVE indicates the different vulnerabilities. Additional information can be found .

At this stage, the CVE Team asks that the researcher help provide additional information to be used in the official CVE listing on the website. The maintains this information online in their database as well.

is an unauthenticated, remote code execution vulnerability in the BIG-IP Traffic Management User Interface (TMUI). The issue is exploitable when TMUI is available through the BIG-IP management port and leads to a complete system takeover since an attacker could execute code, edit files, and enable or disable services on the remote host.

, also known as PrintNightmare, is a remote code execution vulnerability within the Windows Print Spooler service. The Windows Print Spooler service can be abused due to the service improperly handling privileges file operations. The issue requires a user to be authenticated but allows complete takeover of a system from remote or local code execution. The issue is extremely dangerous since it allows an attacker to fully control a domain since it exploits servers (including domain controllers) and workstations.

🛡️
🐛
https://cve.mitre.org/
Documents on Disclosure Practices
here
here
here
U.S. National Vulnerability Database (NVD)
CVE-2020-5902
CVE-2021-34527
Open Vulnerability Assessment Language (OVAL)