5 Medium
CVSS2
Attack Vector
NETWORK
Attack Complexity
LOW
Authentication
NONE
Confidentiality Impact
NONE
Integrity Impact
PARTIAL
Availability Impact
NONE
AV:N/AC:L/Au:N/C:N/I:P/A:N
10 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
CHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
NONE
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
10 High
AI Score
Confidence
High
0.971 High
EPSS
Percentile
99.8%
Hello everyone! It has been 3 months since the last episode. I spent most of this time improving my Vulristics project. So in this episode, let's take a look at what's been done.
Alternative video link (for Russia): <https://vk.com/video-149273431_456239139>
Also, let's take a look at the Microsoft Patch Tuesdays vulnerabilities, Linux Patch Wednesdays vulnerabilities and some other interesting vulnerabilities that have been released or updated in the last 3 months. Finally, I'd like to end this episode with a reflection on how my 2023 went and what I'd like to do in 2024.
In Vulristics you can now provide input data in JSON format and receive output in JSON format. Which opens up new opportunities for automation.
Simply provide a list of CVEs and comments for them (if you have them) as input, and the output will be rated CVEs (with vulnerability type, product, exploitation in the wild, public exploits, etc.).
You can create reports in both JSON and HTML format at the same time:
python3 vulristics.py --report-type "custom_profile" --profile-json-path "profile.json" --cve-data-sources "ms,nvd,epss,attackerkb,vulners,custom" --result-formats "json,html" --result-json-path "results.json" --result-html-path "results.html" --rewrite-flag "True"
As an example, I uploaded a JSON file with a task for Vulristics (January Linux Patch Wednesday). In the JSON task file, you can specify the name of the report, a list of CVE identifiers and comments for them.
I've also uploaded a sample JSON results file. This file contains the same information as a regular HTML report. You can see there information on products and vulnerabilities related to them.
There is also a block with vulnerabilities, which contains information about each analyzed vulnerability: their overall criticality (vvs) and the described components that affected it.
JSON input and output combined with other Vulristics features make it a very flexible tool:
A Custom Data Source allows you to use any vulnerability data you know about in Vulristics. Including the existence of an exploit and signs of exploitation in the wild. Thus, even non-public data can be used when prioritizing vulnerabilities.
You can control the detection of a vulnerable product and set the prevalence of that product (which affects the final vulnerability score) by editing the products.json file. You can set keywords for detection there and increase or decrease the detection priority.
In a similar way, you can control the detection of vulnerability types and their criticality in the data_classification_vulnerability_types.py file.
Let's now talk in more detail about detecting a vulnerable product for a specific CVE. Vulristics had problems with these. Especially when I used it to analyze Linux Patch Wednesdays. For more than half of the vulnerabilities, Vulristics could not detect the related vulnerable products. Types of vulnerabilities too. But there were most problems with the products. Of course, it would be possible to manually add detection rules for them, but this would require too much time and effort.
So instead, I decided to take the time to implement detection based on short CPE IDs (type:vendor:product).
I take these IDs from NVD Data Source.
I add the same identifiers to the product descriptions in products.json.
The work is in progress, but the reports are already much more informative even if the affected product is not described in products.json.
Vulristics now uses a combined method to detect vulnerable product names based on CPE IDs and keywords.
In CPE detections, I give the highest priority to the first identifier of type a (application), if it is not there, then h (hardware), if it is not there, then o (operating system).
I solved the problem with detecting types of vulnerabilities in a similar way. Now Vulristics can detect vulnerability types not only by keywords (expressions), but also by CWE identifiers from NVD Data source.
For each vulnerability type in Vulristics, you can specify a set of corresponding CWE IDs in data_classification_vulnerability_types.py file. I've already mapped some CWE IDs to Vulristics vulnerability types. But, of course, not all of them. There are over 600 CWE IDs! I will add them as needed.
Additionally, I made the following changes to Vulristics vulnerability type detection:
I have added a new Incorrect Calculation vulnerability type for massive non-critical vulnerabilities that are not memory related (and therefore can't be classified as Memory Corruption). For example, "Divide By Zero" or "Integer Overflow". In fact, such vulnerabilities are simply bugs, because it is not clear from the description how an attacker can exploit them. If they lead to an application crash or RCE, then why not write about this directly? And if they don’t, then why bother? In my opinion, it would be better not to create CVE identifiers for such problems at all. But in fact, there are such CVE identifiers (especially often for Linux). Therefore, it is necessary to detect the type for such "vulnerabilities". Now they will be classified as Incorrect Calculation with a relatively low criticality (same as Memory Corruption).
I started to get annoyed by Path Traversal vulnerabilities, which in fact give an attacker the ability to read and write arbitrary files.
Therefore, for such vulnerabilities I will use the types Arbitrary File Reading (already existed) and Arbitrary File Writing (a new one).
I adjusted the weights for the types of vulnerabilities. The logic is this: the more specific the type and the more clear how this type of vulnerability can be used by an attacker, the greater the weight. But this thing, of course, is extremely subjective and I will most likely tweak it many more times. In the moment it looks like this:
Remote Code Execution 1.0
Code Injection 0.97
XXE Injection 0.97
Command Injection 0.97
Authentication Bypass 0.95
Arbitrary File Writing 0.95
Security Feature Bypass 0.90
Elevation of Privilege 0.85
Information Disclosure 0.83
Arbitrary File Reading 0.83
Cross Site Scripting 0.8
Open Redirect 0.75
Path Traversal 0.7
Denial of Service 0.7
Memory Corruption 0.5
Incorrect Calculation 0.5
Spoofing 0.4
Tampering 0.3
Unknown Vulnerability Type 0
Right now it seems like XSS and Open Redirect are a little underrated. But on the other hand, they require more human interaction, so maybe that's okay. In any case, although the type of vulnerability affects the final criticality quite strongly, it does not affect as much as the presence of an exploit and signs of exploitation in the wild.
As part of this project, I am analyzing Linux vulnerabilities that have been patched in the last month. The main difficulty in distributing CVEs by month is to determine the date when the CVE was patched for the first time. Usually the Debian team is the fastest to patch vulnerabilities. But the problem is that some Debian OVAL definitions do not have a publication date.
I'll demonstrate this with an example. When I generated the Linux Patch Wednesday report for January, I saw in the report UnRAR Arbitrary File Overwrite (CVE-2022-30333). Why did the 2022 vulnerability appeared at the beginning of 2024? Because it was patched in Ubuntu recently, on January 8th. In this case, it was not the UnRAR utility that was fixed, but the third-party ClamAV library for anti-virus scanning of archives. Does this mean that Linux vendors did not patch this CVE vulnerability until 2024? Well, some Linux vendors did. There is a message on the Debian mailing list dated August 17, 2023. It's also late, not 2022 (as it should be), but still a little earlier. But the problem is that this date, August 17, 2023, was not in the Debian OVAL content. And that's why the CVE got from 2022 to 2024. Simply because the earliest (and only) date that was in the Linux vendors' OVAL content for this vulnerability was the date of the belated fix in Ubuntu Linux.
So, OVAL is good and universal, but, unfortunately, not a panacea. Surprisingly, there is also a mess there, which no one cares about.
That's why I had to learn how to parse archives of the Debian Security Bulletin mailing list. As a result, the list of vulnerabilities in LPW has become more adequate. In particular, CVE-2022-30333 went to the LPW for September 2023. And it is also possible to work with other mailing lists, for example with Suse, in the same manner.
From November to January there were between 81 and 192 CVEs in Linux Patch Wednesdays. Among them were vulnerabilities with public exploits and signs of active exploitation in the wild:
There were also vulnerabilities with the signs of active exploitation in the wild, but without public exploits:
It makes no sense to list all the vulnerabilities for which there is a PoC or an exploit, but there are no signs of exploitation in the wild. Simply because there are a lot of them, about 90. You can look at them yourself in the Vulristics reports. I've updated the Vulristics reports for these Linux Patch Wednesdays on January 30th:
November Linux Patch Wednesday
December Linux Patch Wednesday
January Linux Patch Wednesday
Thanks to the latest improvements to Vulristics, I processed them to almost perfect condition. The product name and type of vulnerability were NOT detected only for "This candidate has been reserved…" stubs and for vulnerabilities with such a strange description that even manual processing is difficult.
Over the past 3 months, Microsoft has been releasing Patch Tuesdays with relatively few CVEs. From 53 to 98, including vulnerabilities that were released between Patch Tuesdays.
At the moment, there is only one vulnerability with a public exploit and signs of exploitation in the wild:
Security Feature Bypass - Windows SmartScreen (CVE-2023-36025). To exploit the vulnerability, an attacker must convince a user to click on a specially crafted Internet Shortcut (.URL) or a hyperlink pointing to an Internet Shortcut file to be compromised by them.
Signs of exploitation in the wild have been noted for these vulnerabilities:
PoCs have also appeared for these vulnerabilities. Most of them are EoPs. And VM vendors ignored most of these vulnerabilities in their Microsoft Patch Tuesday reviews.
I've updated the Vulristics reports for these Microsoft Patch Tuesdays on January 29th:
November Microsoft Patch Tuesday
December Microsoft Patch Tuesday
January Microsoft Patch Tuesday
Among the many other critical vulnerabilities that have appeared or been updated over the past 3 months, I would like to highlight the following:
It was a great year for me, it's hard to complain. I’m alive and feel good. Everything is fine with my family too. I praise the Creator for everything!
I have worked on many interesting projects. In some projects I achieved quite good results. In some projects, not really. But it doesn’t matter, it will work out on the next approach. And if it doesn’t work out, that’s also not a problem.
What can be noted:
Besides working on current projects (primarily Vulristics), I'd also like to write some open source code to manage vulnerability remediation. Just like a process; I think it would be interesting and useful both for educational purposes and for use in organizations.
I'm also thinking about turning my educational content into a book about Vulnerability Management. So far my ideas about the book are:
But these are just my thoughts and I won’t plan or promise anything. Let it be as it will be.
5 Medium
CVSS2
Attack Vector
NETWORK
Attack Complexity
LOW
Authentication
NONE
Confidentiality Impact
NONE
Integrity Impact
PARTIAL
Availability Impact
NONE
AV:N/AC:L/Au:N/C:N/I:P/A:N
10 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
CHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
NONE
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
10 High
AI Score
Confidence
High
0.971 High
EPSS
Percentile
99.8%