Author Archives: Alexander Leonov

About Alexander Leonov

Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. You can discuss my posts or ask questions at @avleonovchat. А всех русскоязычных я приглашаю подписаться на мой канал @avleonovrus "Управление Уязвимостями и прочее" в MAX или в Telegram.

The digest of March trending vulnerabilities was published on the Positive Technologies website (in Russian)

Leave a reply

The digest of March trending vulnerabilities was published on the Positive Technologies website (in Russian)The digest of March trending vulnerabilities was published on the Positive Technologies website (in Russian)The digest of March trending vulnerabilities was published on the Positive Technologies website (in Russian)The digest of March trending vulnerabilities was published on the Positive Technologies website (in Russian)The digest of March trending vulnerabilities was published on the Positive Technologies website (in Russian)

The digest of March trending vulnerabilities was published on the Positive Technologies website (in Russian). I also generated a Vulristics report for these vulnerabilities. There are 5 vulnerabilities in total.

🔻 For 3 vulnerabilities there are exploits and confirmed signs of exploitation in the wild: AuthBypass - TeamCity (CVE-2024-27198), RCE - FortiClientEMS (CVE-2023-48788), EoP - Windows Kernel (CVE-2024-21338).

🔻 For 2 more vulnerabilities there are no signs of exploitation in the wild yet, but there are exploits: EoP - Windows CLFS Driver (CVE-2023-36424), RCE - Microsoft Outlook (CVE-2024-21378).

На русском

The fundamental Open Source vulnerability demonstrated by the XZ Utils backdoor is not technical at all

Leave a reply

The fundamental Open Source vulnerability demonstrated by the XZ Utils backdoor is not technical at all

The fundamental Open Source vulnerability demonstrated by the XZ Utils backdoor is not technical at all. The fact is that the work of the communities responsible for writing commonly used code is based on more infantile principles than the work of children building a castle in a sandbox.

Some dedicated computer geeks on some mailing list somehow get organized and solve monstrously complex technical problems that affect hundreds of millions of people. 🤷‍♂️ Who are these geeks, what is their motivation, how adequate are the community leaders they choose? 🤔

As people familiar with the situation write, the backdoor in XZ Utils was allegedly added by a developer who, over the course of 2 years, joined the project, becoming its maintainer and main contributor. 😎 And the previous maintainer was gaslighted with the help of virtual trolls and was forced to share power. 🤷‍♂️ As a result, a Microsoft employee accidentally found the backdoor and raised the alarm.

На русском

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

2 Replies

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. 🤷‍♂️

На русском

I generated a report on the March Linux Patch Wednesday

Leave a reply

I generated a report on the March Linux Patch Wednesday
I generated a report on the March Linux Patch WednesdayI generated a report on the March Linux Patch WednesdayI generated a report on the March Linux Patch WednesdayI generated a report on the March Linux Patch WednesdayI generated a report on the March Linux Patch Wednesday

I generated a report on the March Linux Patch Wednesday. 134 vulnerabilities, of which 68 are in the Linux Kernel. There are no vulnerabilities with signs of exploitation in the wild. There are 15 vulnerabilities with PoCs.

🔸 The top vulnerability is Command Injection - libuv (CVE-2024-24806). This is a multi-platform library for asynchronous I/O. An attacker could potentially access internal APIs.

🔸 For aiohttp there is a pack of Command Injection (CVE-2023-37276, CVE-2023-47627, CVE-2023-49082) and Security Feature Bypass (CVE-2023-47641, CVE-2023-49081) with PoCs. It is an asynchronous client/server HTTP framework. The vulns were patched only in Russian RedOS and Debian.

🔸There are problems with vulnerability types/products detection due to the NVD crisis (no CPE & CWE). 🤷‍♂️

🔸 The Linux Kernel team is now a CNA and is creating a ton of CVEs with monstrously large descriptions. Because they can! 😏

🗒 March Linux Patch Wednesday

На русском

Over the weekend, I achieved the first results in my open source vulnerability detection project Vuldetta

Leave a reply

Over the weekend, I achieved the first results in my open source vulnerability detection project Vuldetta
Over the weekend, I achieved the first results in my open source vulnerability detection project VuldettaOver the weekend, I achieved the first results in my open source vulnerability detection project Vuldetta

Over the weekend, I achieved the first results in my open source vulnerability detection project Vuldetta. 😇

What I managed to do:

🔹 I parsed Ubuntu OVAL into simple detection rules based on package versions. The structure of Ubuntu OVAL is quite sophisticated, especially when it comes to detecting kernel vulnerabilities (not by packages, but by uname_test and variable_test 🤯). Despite the fact that OVAL content for each distribution version is downloaded in a separate file, distribution version checks are also implemented in OVAL. Now I just go through all the definitions, see which dpkginfo_test are used in the criteria and parse only them.

🔹 I made a primitive utility that uses these detection rules. Without any optimizations, parsing OVAL and calculating vulnerabilities takes 6.5 seconds. It works. 🙂👍

All code is available on Github. Next I will deal with kernel vulnerabilities, optimization and turn the code into an http API.

На русском

I looked at VulnCheck KEV

Leave a reply

I looked at VulnCheck KEV
I looked at VulnCheck KEVI looked at VulnCheck KEVI looked at VulnCheck KEVI looked at VulnCheck KEVI looked at VulnCheck KEVI looked at VulnCheck KEV

I looked at VulnCheck KEV. This is an analogue of CISA KEV (Know Exploited Vulnerabilities) by VulnCheck.

🔹 Unlike the public CISA KEV, only registered users have access to VulnCheck KEV. The VulnCheck website is accessible from Russian IPs 🇷🇺, but when registering they write that "account is currently under review" (in fact requests are simply blocked 🥸). Requests from non-Russian IPs are registered automatically. 🌝
🔹 There are ~2 times more CVEs in the database than in CISA KEV.
🔹 There are no standard tools for downloading all these CVEs via web-gui. 🤷‍♂️
🔹 There are links to exploits for CVEs that look good. 👌
🔹 There are signs of exploitation in the wild. Sometimes it's clear, like "Outbreak Alerts 2023" pdf report. Sometimes it’s strange, like a link to a Shadowserver dashboard or a non-related blog post. 🤷‍♂️

The selection of CVEs is quite interesting, but the rationale for exploitation in the wild needs to be improved. 😉

На русском

Recently there was news about an RCE vulnerability in FortiOS and FortiProxy (CVE-2023-42789)

Leave a reply

Recently there was news about an RCE vulnerability in FortiOS and FortiProxy (CVE-2023-42789)
Recently there was news about an RCE vulnerability in FortiOS and FortiProxy (CVE-2023-42789)Recently there was news about an RCE vulnerability in FortiOS and FortiProxy (CVE-2023-42789)

Recently there was news about an RCE vulnerability in FortiOS and FortiProxy (CVE-2023-42789). It "allows attacker to execute unauthorized code or commands via specially crafted HTTP requests". The vulnerability is exploited in the captive portal, which, in theory, should not be accessible from the Internet. This is why the Fortinet bulletin warns about an "inside attacker".

There is a repository on GitHub that allegedly contains a PoC, but its reliability is questionable. The code only implements checking the availability of the captive portal; there is no payload there. The repository was created by a user without any reputation or previous activity. He sells the full exploit code for ~$262. It looks like a scam, but if suddenly this is a truly functional exploit, then it is likely that it will quickly leak to the public.

In any case, it is worth updating or getting rid of this solution.

На русском