Tag Archives: Linux

TOP 5 CVEs that were most often exploited by Positive Technologies pentesters in 2023

TOP 5 CVEs that were most often exploited by Positive Technologies pentesters in 2023. The report was released on July 2. I generated a rap track on this topic in Russian using Suno. 🙂 English subtitles available.

List of vulnerabilities:

🔻 Remote Code Execution – Microsoft Exchange “ProxyNotShell” (CVE-2022-41040, CVE-2022-41080, CVE-2022-41082)
🔻 Remote Code Execution – Bitrix Site Manager “PollsVotes” (CVE-2022-27228)
🔻 Elevation of Privilege – Polkit “PwnKit” (CVE-2021-4034)

На русском

Trending vulnerabilities for June according to Positive Technologies

Trending vulnerabilities for June according to Positive Technologies. Traditionally, in 3 formats (in Russian):

📹 The section “Trending VM” in the SecLab news video (starts at 15:03)
🗞 Post on the Habr website, in fact this is a slightly expanded scenario for the “Trending VM” section
🗒 Compact digest with technical details on the official PT website

List of vulnerabilities:

🔻 EoP in Microsoft Windows CSC (CVE-2024-26229)
🔻 EoP in Microsoft Windows Error Reporting (CVE-2024-26169)
🔻 EoP in Microsoft Windows Kernel (CVE-2024-30088)
🔻 RCE in PHP (CVE-2024-4577)
🔻 EoP in Linux Kernel (CVE-2024-1086)
🔻 InfDisclosure in Check Point Security Gateways (CVE-2024-24919)
🔻 RCE in VMware vCenter (CVE-2024-37079, CVE-2024-37080)
🔻 AuthBypass in Veeam Backup & Replication (CVE-2024-29849)

На русском

Linux Patch Wednesday: here is this May peak!

Linux Patch Wednesday: here is this May peak!

Linux Patch Wednesday: here is this May peak! 🤦‍♂️ Also about June Linux Patch Wednesday. If you remember, in my post about the May Linux Patch Wednesday I was happy that, despite the launch of the rule for Unknown dates, the peak in May was insignificant. Although “32406 oval definitions without a date received a nominal date of 2024-05-15”. It turned out that the peak was not visible due to an error in the code. Ba-dum-tss! 🥸🤷‍♂️

I noticed that not all CVEs are in LPW bulletins, despite the addition of nominal dates, for example the high-profile vulnerability Elevation of Privilege (Local Privilege Escalation) – Linux Kernel (CVE-2024-1086). I could not find it anywhere. I debugged the function that distributes vulnerabilities into bulletins and added tests. I have ensured that all 38362 CVEs from the Linux OVAL content are actually distributed in bulletins. Including CVE-2024-1086. Here it is in February:

$ grep "CVE-2024-1086"  bulletins/*
bulletins/2024-02-21.json: "CVE-2024-1086": [
bulletins/2024-02-21.json: "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json: "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json: "title": "CVE-2024-1086 linux",

Well, there really is a peak in May. And how huge it is! 11476 CVEs! 😱 This is so much that I regenerated the Vulristics report for it only using 2 sources: Vulners and BDU. Since even from Vulners the data was not collected quickly enough. The report contains 77 vulnerabilities with signs of active exploitation in the wild and 1404 vulnerabilities with exploits, but without signs of active exploitation in the wild. Since for the most part these are old vulnerabilities for which it was simply not clear exactly when they were fixed, for example, Remote Code Execution – Apache HTTP Server (CVE-2021-42013), I will not analyze them in detail – for those interested, see the report. But please note that the report size is very large.

🗒 Vulristics report on the May Linux Patch Wednesday (31.3 MB)

As for the June Linux Patch Wednesday, which was finalized on June 19, there are 1040 vulnerabilities. Also quite a lot. Why is this so? On the one hand, the rule for Unknown dates added 977 Debian OVAL definitions without a date. Not 30k, like in May, but also significant. Out of 1040 vulnerabilities, 854 are Linux Kernel vulnerabilities. Moreover, there are quite a lot of “old” vulnerability identifiers, but created in 2024. For example, CVE-2021-47489 with NVD Published Date 05/22/2024. 🤔 CNA Linux Kernel is doing something strange.

🔻 With signs of exploitation in the wild again Remote Code Execution – Chromium (CVE-2024-5274, CVE-2024-4947), like in Microsoft Patch Tuesday. According to the BDU, Remote Code Execution – Libarchive (CVE-2024-26256) is also exploited in the wild.

🔸 Another 20 vulnerabilities with a public exploit. I can highlight separately Remote Code Execution – Cacti (CVE-2024-25641) and Remote Code Execution – onnx/onnx framework (CVE-2024-5187).

🗒 Vulristics report on the June Linux Patch Wednesday (4.4 MB)

Elevation of Privilege (Local Privilege Escalation) – Linux Kernel (CVE-2024-1086) has been added to CISA KEV

Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) has been added to CISA KEV

Elevation of Privilege (Local Privilege Escalation) – Linux Kernel (CVE-2024-1086) has been added to CISA KEV. The vulnerability itself is relatively old, from January. I already wrote about it in March, when the write-up and public exploit were released.

Despite the fact that the exploitation of this vulnerability is trivial (the attacker launches a local utility and gains root privileges), until recently there were no signs of exploitation in the wild. This is quite strange: such a useful exploit should immediately be included in the attackers’ toolkit. So either the practical exploitation of this vulnerability is somehow complicated, or the attackers did not leave any traces. 🤔

In any case, on May 30, the vulnerability was added to CISA KEV, and this means the fact of its exploitation in attacks has been proven. But there are no details yet. Please be aware of this vulnerability when upgrading Linux hosts.

На русском

May Linux Patch Wednesday

May Linux Patch Wednesday
May Linux Patch WednesdayMay Linux Patch WednesdayMay Linux Patch WednesdayMay Linux Patch WednesdayMay Linux Patch Wednesday

May Linux Patch Wednesday. Last month, we jointly decided that it was worth introducing a rule for Unknown dates starting from May 2024. Which, in fact, is what I implemented. Now, if I see an oval definition that does not have a publication date (date when patches for related vulnerabilities were available), then I nominally assign today’s date. Thus, 32406 oval definitions without a date received a nominal date of 2024-05-15. One would expect that we would get a huge peak for vulnerabilities that “started being patched in May” based on the nominal date. How did it really turn out?

In fact, the peak was not very large. There are 424 CVEs in the May Linux Patch Wednesday. While in April there were 348. It’s comparable. Apparently the not very large peak is due to the fact that most of the vulnerabilities had patch dates older than the nominal one set (2024-05-15). And this is good. 🙂 It should get even better in June.

As usual, I generated a Vulristics report for the May vulnerabilities. Most of the vulnerabilities (282) relate to the Linux Kernel. This is due to the fact that Linux Kernel is now a CNA and they can issue CVEs for all sorts of things like bugs with huge traces right in the vulnerability descriptions.

The vulnerability from CISA KEV comes first.

🔻Path Traversal – Openfire (CVE-2023-32315). This is the August 2023 trending vulnerability. It was included in the report due to a fix in RedOS 2024-05-03. Has it not been fixed in other Linux distributions? It looks like this. In Vulners, among the related security objects, we can only see the RedOS bulletin. Apparently there are no Openfire packages in the repositories of other Linux distributions.

In second place is a vulnerability with a sign of active exploitation according to AttackerKB.

🔻 Path Traversal – aiohttp (CVE-2024-23334). The bug allows unauthenticated attackers to access files on vulnerable servers.

According to data from the FSTEC BDU, another 16 vulnerabilities have signs of active exploitation in the wild.

🔻 Memory Corruption – nghttp2 (CVE-2024-27983)
🔻 Memory Corruption – Chromium (CVE-2024-3832, CVE-2024-3833, CVE-2024-3834, CVE-2024-4671)
🔻 Memory Corruption – FreeRDP (CVE-2024-32041, CVE-2024-32458, CVE-2024-32459, CVE-2024-32460)
🔻 Memory Corruption – Mozilla Firefox (CVE-2024-3855, CVE-2024-3856)
🔻 Security Feature Bypass – bluetooth_core_specification (CVE-2023-24023)
🔻 Security Feature Bypass – Chromium (CVE-2024-3838)
🔻 Denial of Service – HTTP/2 (CVE-2023-45288)
🔻 Denial of Service – nghttp2 (CVE-2024-28182)
🔻 Incorrect Calculation – FreeRDP (CVE-2024-32040)

Another 22 vulnerabilities have an exploit (public or private), but so far there are no signs of active exploitation in the wild. I won’t list them all here, but you can pay attention to:

🔸 Security Feature Bypass – putty (CVE-2024-31497). A high-profile vulnerability that allows an attacker to recover a user’s private key.
🔸 Remote Code Execution – GNU C Library (CVE-2014-9984)
🔸 Remote Code Execution – Flatpak (CVE-2024-32462)
🔸 Command Injection – aiohttp (CVE-2024-23829)
🔸 Security Feature Bypass – FreeIPA (CVE-2024-1481)

I think that to improve the Vulristics report, it makes sense to separately group vulnerabilities with public exploits and private exploits, since this still greatly affects the criticality. Put 🐳 if you would like to see this feature.

🗒 Vulristics report on the May Linux Patch Wednesday

На русском

Detection of known (CVE) vulnerabilities without authentication (in Pentest mode): overkill or necessity? There is an opinion that when detecting vulnerabilities in internal infrastructure, scanning without authentication is not necessary at all

Detection of known (CVE) vulnerabilities without authentication (in Pentest mode): overkill or necessity? There is an opinion that when detecting vulnerabilities in internal infrastructure, scanning without authentication is not necessary at all

Detection of known (CVE) vulnerabilities without authentication (in Pentest mode): overkill or necessity? There is an opinion that when detecting vulnerabilities in internal infrastructure, scanning without authentication is not necessary at all. That it is enough to install agents on the hosts. And those hosts where agents cannot be installed, for example network devices, just need to be scanned with authentication. They say scans without authentication are always less reliable than scans with authentication, and they are needed only for perimeter scanning or primary network inventory. In my opinion, this is not completely correct. Scanning without authentication for known vulnerabilities is mandatory, especially when the target is a host running a web application.

And this is due to the peculiarities of detecting vulnerabilities during scanning with authentication. Let’s take Linux hosts. Typically, VM vendors when scanning Linux hosts with authentication, limit themselves to detecting vulnerabilities in packages from the official Linux vendor repository. 🤷‍♂️ Simply because these vulnerabilities are described in publicly available security bulletins or even as formalized OVAL content. It’s convenient. If you have learned to work with such content, you can check the box that the Linux distribution is supported by the VM solution. What about vulnerabilities for software that is not in the official Linux vendor repository? This is where things get more complicated.

This software can be installed:

🔹 From a connected third-party Linux software repository
🔹 From a package (made by some vendor or selfbuilt) of the standard package system for this Linux distro (deb, rpm), brought to the host manually
🔹 From alternative packages for software distribution (snap, flatpak, appimage, etc.)
🔹 From module distribution tools (pip, conda, npm, etc.)
🔹 From a container image (docker, podman, etc.)
🔹 From software source codes; the software can be built directly on the target host or can be transferred there as binary files.

Ideally, no matter how the software is installed on a host, a vulnerability scanner should correctly detect that software installation, determine the version, and identify associated vulnerabilities based on the version. 🧙‍♂️ But in practice, due to the fact that there are many ways to install software, this is a very non-trivial task. 🧐

As a result, we get a situation: let’s say we have some kind of commercial or open source software on a Linux host (Zabbix, GitLab, Confluence, Jira). This software is not easy to reliably find simply by exploring the host from the inside via SSH. And when looking at the host from the outside, searching for this software is trivial: we scan the ports, find the web-GUI, often find the version directly on the main page and use it to detect vulnerabilities. At the same time, we are not at all dependent on the specific method of installing and running the software on the host. The main thing is that we see the web interface of the application itself. 🤩

Such “external” rules for detecting vulnerabilities are much easier to develop. You can also use ready-made expertise. Fingerprinting to obtain a CPE ID combined with a CPE lookup in NVD is, of course, a dirty path. But this allows you to add vulnerability detection rules in large quantities. 😏 And if you can tweak both the fingerprint and the CPE detection rules, then the number of errors can be reduced to an acceptable level. And if you also add validation of vulnerabilities with an exploitation attempt (for example, using nuclei), then a significant set of vulnerabilities can be detected more than reliably. 😉

So, scanning for known vulnerabilities without authentication (“pentest”) is a must have for internal infrastructure as well, especially for hosts with web applications.

На русском

For the January Elevation of Privilege (Local Privilege Escalation) – Linux Kernel (CVE-2024-1086), the write-up and PoC were released on March 26

For the January Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086), the write-up and PoC were released on March 26
For the January Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086), the write-up and PoC were released on March 26

For the January Elevation of Privilege (Local Privilege Escalation) – Linux Kernel (CVE-2024-1086), the write-up and PoC were released on March 26. The video demo for the script looks impressive: they run the script as a regular user and after a couple of seconds they get a root shell. According to the author, the exploit works with most Linux kernels between versions 5.14 and 6.6, including Debian, Ubuntu and KernelCTF.

🔻 The exploit requires kconfig CONFIG_USER_NS=y; sh command sysctl kernel.unprivileged_userns_clone = 1; kconfig CONFIG_NF_TABLES=y. The author writes that this is the default for Debian, Ubuntu, and KernelCTF, and for other distributions it is necessary to test it.
🔹 The exploit does not work with kernels v6.4> with kconfig CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y (including Ubuntu v6.5)

NSFOCUS writes that Redhat is also vulnerable. 🤷‍♂️

На русском