- Joined
- Mar 1, 2021
Between this banner and the tidal wave of zero days across the last few years that has only been gaining more speed, it seems like it's a decent time to have a general in I&T related to CVE/zero day information and discussion to keep it all in one place and (hopefully) make it easier to find information when another new zero day
CVES FOR NIGGERS - DEFINITION
CVEs, or "Common Vulnerabilities and Exposures" are things computer users and IT workers are becoming more and more familiar with as the years go by as a term. The CVE database is one of publicly disclosed information security issues, ranging from old news to zero days and everything in between. For reference, a "zero day" is a vulnerability in software or hardware that is generally unknown to the vendor who created the product said vulnerability has been discovered in, and for which no patch or fix is available at the time it is discovered. This is also known as literal hell on earth for anybody working in related disciplines of IT for obvious reasons.
THE INTRICACIES OF CVES - A BRIEF OVERVIEW
Firstly, two core differences that must be distinguished here are:
VULNERABILITIES:
- These are weaknesses which show potential for exploitation to gain unauthorized access to, or perform unauthorized actions on a host. Vulnerabilities allow adversaries to gain direct access to a host or network and do what they wish or what the vulnerability may allow. This can range from installing unwanted applications or malware, running code, stealing, modifying or destroying sensitive information and more.
EXPOSURES:
- These are better thought of as "damage for a time period". Exposures are signification that said vulnerability as mentioned above, has been taken advantage of by a threat actor which then allows them to run actions on objectives (as per the lockheed martin cyber kill chain(archive)), aka they will now ransom or steal your shit thanks to said vulnerability allowing them the access they need to do so.
CVE CRITERIA
Vulnerabilities must meet certain criteria in order to be published. These include:
It must be independent of other issues
- The vendor has to be able to fix said vulnerability independently of other issues.
It is a proven risk- The vulnerability is submitted with evidence of security impact that violates the security policies of the vendor.
It only affects one codebase- Each product vulnerability is given a separate CVE. If vulnerabilities stem from shared protocols, standards, or libraries a separate CVE is assigned for each vendor affected. The one exception to this is if there is no way to use the shared component without including the vulnerability.
THE BASICS OF NUMBERING
A single CVE number uniquely identifies a vulnerability within the list, starting with the year the CVE was discovered and followed by a unique, short string of numbers (for example, CVE-2024-4577). The CVE Numbering Authority (CNA) handles the number assignment. The CVE database serves as a way for vendors, enterprise environments and other relevant parties to organize and prioritise their vulnerability mitigation, inform clients of more severe issues that may come to affect their environment via security advisories, and for general information sharing on cybersecurity related issues.
A typical CVE page does not tend to contain much detail outside of the basics of the vulnerability, the severity, what version(s) of software/hardware are affected by said vulnerability and some relevant resources, for example:
SEVERITY AND SCORING
CVE severity can be measures in a few ways, however they are typically scored according to the Common Vulnerability Scoring System (CVSS) which is used to measure potential impact and is also known as the CVE score. A CVEs severity can range according to the following data as per version 3.1 which is in use at the time of initial creation of this OP:
| SEVERITY | BASE SCORE |
|---|---|
| None | 0 |
| Low | 0.1-3.9 |
| Medium | 4.0-6.9 |
| High | 7.0-8.9 |
| Critical | 9.0-10.0 |
CVSS scoring is based on a combination of a few subsets of scores. these are exploitability, impact and scope. These will be broken down:
Exploitability, predictably, covers how easily a vulnerability can be exploited by an adversary, and is composed of the following table of metrics:
| Metric | Measurement | Scale (low to high) |
| Attack vector (AV) | How easy it is for attackers to access a vulnerability | Physical (presence) Local (presence) Adjacent (connected networks) Network (remote) |
| Attack complexity (AC) | What prerequisites are necessary for exploitation | Low High |
| Privileges required (PR) | The level of privileges needed to exploit the vulnerability | None Low High |
| User interaction (UI) | Whether exploitation requires actions from a tertiary user | Binary—either None or Required |
Impact essentially covers how absolutely fucked the affected compontent will be post-exploit. The metrics for this are:
| Metric | Measurement | Scale |
| Confidentiality (C) | Loss of data confidentiality in the component or wider systems | None Low High |
| Integrity (I) | Loss of data integrity throughout the component system | None Low High |
| Availability (A) | Loss of availability of the component or attached systems | None Low High |
Scope covers what impact a vulnerability will have on compotents aside from the one affected by the vulnerability. The metrics for this one are as follows:
| Metric | Measurement | Scale (from low to high) |
| Exploit code maturity (E) | The availability of tools or code that can be used to exploit the vulnerability | Proof of concept Functional Unproven High Not defined |
| Remediation level (RL) | The level of remediation currently available to users | Official fix Workaround Temporary fix Unavailable Not defined |
| Report confidence (RC) | The degree of accuracy of the vulnerability report | Unknown Reasonable Confirmed Not defined |
NERD SHIT - SMALL HISTORY EDITION
For a brief bit of history, the CVE program initially started(archive) as a concept by MITRE corporation members David E. Mann and Steven M. Christey via a paper(archive(PDF is also attached to this OP)) titled "Towards a Common Enumeration of Vulnerabilities". The database was launched in 1999 with 321 initial records created alongside it after the working group which later became the CVE Editorial Board was put together. The CVE database gained serious traction extremely quickly due to the importance of needing to be able to have information so critical easily obtained and accessed by relevant parties, it also provided a sorely needed standard for vendors, corporations and researchers alike to inform clients in a uniform manner of potential issues that need immediate attention within their environments.
Today, MITRE primarily run and maintain the CVE database alongside NIST who run the National Vulerability Database (NVD). Both of these are often used in tandem, and are two of the most widely used databases across the industry, however they are far from the only two. As a side note, CVE.mitre.org is still being used in the interim, however MITRE are migrating all pages to the above hyperlinked cve.org so bear this in mind if you plan to use cve.mitre.org as one of your resources.
WHY SHOULD I CARE NIGGER - The purpose of the thread
This general thread intends to serve as a more central place for discussion on new and old CVEs alike, alerting fellow kiwis to newly discoverd CVEs and/or zero days which may affect more standard end users (read: fags) like us over a corporate environment that we really should know about, sharing resources and information regarding patches for said CVEs that might not be added to the CVE page at the time of discovery, to highlight some of the more notorious CVEs (log4j(archive)I'm looking at you, you nigger), as well as potentially showcase older CVEs which do not get much discussion these days but are still regularly exploited. By having a general, it will potentially make finding information on more critical CVEs easier to locate across the forum rather than bouncing between A&H articles and random threads as each CVE is published
RESOURCES YOU CAN USE TO KEEP UP TO DATE
I would highly advise setting up your own RSS feed and grabbing whatever you want/need that might be related to your particular host and/or environment, however there are many vendor pages you can use. Here's a few to start you off:
Official CVE Database
NVD | NVD Dashboard
Tenable Latest CVEs
Rapid7 Vulnerabilities Database
Arch Linux Security Tracker
Debian Security Tracker
CVEDetails
Microsoft Vulnerability Page
CISA
CVEFeed
Palo Alto Security Advisories
CVEProject Github Repo
OWASP
A FEW NOTEWORTHY CVES TO FINISH US OFF
Some more infamous and recent CVEs include:
CVE-2024-4577 - Critical vulnerability in PHP
CVE-2021-44228 - Log4J (aka log4shell)
CVE-2023-4863 - WebP zero day
CVE-2014-0160 - Heartbleed
CVE-2014-6271 - Shellshock
CVE-2024-38063 (current forum thread discussion link)- Windows RCE that affects literally any host with IPv6 enabled on it. Yes this is very new but come the fuck on microsoy this is some bullshit
