Tag Archives: vulnerability

The Remote Code Execution vulnerability – PHP on Windows hosts (CVE-2024-4577) is used in ransomware attacks

Leave a reply

The Remote Code Execution vulnerability - PHP on Windows hosts (CVE-2024-4577) is used in ransomware attacks

The Remote Code Execution vulnerability – PHP on Windows hosts (CVE-2024-4577) is used in ransomware attacks. I already had a post about this vulnerability earlier. Now Imperva Threat Research reports that this vulnerability is being used by attackers to deliver malware identified as a component of the TellYouThePass ransomware.

⏳ The attacks were noticed on June 8, less than 48 hours after the PHP developers released a patch. The attacks used an exploit that by that time was already publicly available.

TellYouThePass attacks have been reported since 2019. They target enterprises and individuals. Attackers encrypt both Windows and Linux infrastructure.

What conclusions can be drawn? If you see a vulnerability with a public exploit and a more or less clear vector of exploitation, don’t be lazy to patch it as quickly as possible. Because attackers will definitely not be too lazy to add this exploit to their malware. 😉

На русском

Critical Remote Code Execution – PHP on Windows hosts (CVE-2024-4577) vulnerability with a public exploit

Leave a reply

Critical Remote Code Execution - PHP on Windows hosts (CVE-2024-4577) vulnerability with a public exploit

Critical Remote Code Execution – PHP on Windows hosts (CVE-2024-4577) vulnerability with a public exploit. CVSS 9.8. On June 6, PHP developers released an update to fix an RCE vulnerability which exists due to incorrect work with the Best-Fit encoding conversion function in the Windows operating system. An unauthenticated attacker performing an argument injection attack can bypass protection against the old actively exploited RCE vulnerability CVE-2012-1823 using certain character sequences and thus execute arbitrary code. Exploits for the vulnerability are already available on GitHub. The Shadowserver Foundation has noticed active scans aimed at detecting vulnerable hosts. 👾

The vulnerability affects all versions of PHP installed on the Windows operating system.

🔻 PHP 8.3 < 8.3.8
🔻 PHP 8.2 < 8.2.20
🔻 PHP 8.1 < 8.1.29 PHP 8.0, PHP 7 and PHP 5 are also vulnerable, but they are already in End-of-Life and are not supported. 🤷‍♂️ It is specifically emphasized that all XAMPP installations are also vulnerable by default. XAMPP is a free and open-source cross-platform web server solution containing Apache, MariaDB, PHP, Perl and a large number of additional libraries. If updating to the latest version of PHP is not possible, researchers from DEVCORE suggest configuration recommendations that prevent vulnerability exploitation. However, these recommendations apply to installations on Windows with certain language locales (Traditional Chinese, Simplified Chinese, Japanese) for which the exploitation of the vulnerability has been verified. For other locales, due to the wide range of PHP use cases, it is currently impossible to fully list and exclude all potential exploitation scenarios. Therefore, users are advised to conduct a comprehensive asset assessment, check PHP usage scenarios, and update PHP to the latest version.

На русском

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

Leave a reply

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.

На русском

Information Disclosure vulnerability – Check Point Security Gateway (CVE-2024-24919) exploited in the wild

Leave a reply

Information Disclosure vulnerability - Check Point Security Gateway (CVE-2024-24919) exploited in the wild

Information Disclosure vulnerability – Check Point Security Gateway (CVE-2024-24919) exploited in the wild. On May 28, Check Point released a security bulletin reporting a critical vulnerability in Check Point Security Gateways configured with the “IPSec VPN” or “Mobile Access” software blades.

📖 Almost immediately, technical details on the vulnerability appeared. The vulnerability allows an unauthenticated remote attacker to read the content of an arbitrary file located on an affected device. This allows an attacker to read the /etc/shadow file with password hashes for local accounts, including accounts used to connect to Active Directory. An attacker can obtain passwords from hashes, and then use these passwords for authentication and further development of the attack. Of course, if the Security Gateway allows password-only authentication.

🔨 Exploiting the vulnerability is trivial – one Post request is enough. There are already many scripts on GitHub for this.

👾 Attempts to exploit the vulnerability have been detected since April 7. In other words, 1.5 months before the vendor released the fixes. The vulnerability is already in CISA KEV.

Vulnerable products:

🔻 CloudGuard Network
🔻 Quantum Maestro
🔻 Quantum Scalable Chassis
🔻 Quantum Security Gateways
🔻 Quantum Spark Appliances

🔍 How many vulnerable hosts can there be? Qualys found 45,000 hosts in Fofa and about 20,000 hosts in Shodan. Most of all, of course, in Israel. Russia is not in the TOP 5 countries. Fofa shows 408 hosts for Russia. 🤷‍♂️

🩹 The vendor’s website provides hotfixes, a script for checking for compromise, and recommendations for hardening devices.

На русском

RCE – Confluence (CVE-2024-21683) with public exploits on GitHub

Leave a reply

RCE - Confluence (CVE-2024-21683) with public exploits on GitHub

RCE – Confluence (CVE-2024-21683) with public exploits on GitHub. Authentication is required. Both Confluence Data Center and Confluence Server are vulnerable.

🔻 Version 8.5.9 LTS, which fixes the vulnerability, was released on May 9.
🔻 On May 23, after the description of the vulnerability in NVD and the Atlassian ticket became public, researcher Huong Kieu studied the patch, described the vulnerability and reported that he was able to make a PoC. On the same day, exploits for this vulnerability appeared on GitHub.

Atlassian likely held back information about fixing this vulnerability so that more organizations could update before active exploitation began. However, they didn’t quite succeed. Apparently they accidentally published the ticket on May 15th, and then hid it until May 23rd. But the vulnerability search engine Vulners remembered it. 😉 So information about the vulnerability was available all this time.

На русском

RCE – Fluent Bit (CVE-2024-4323) “Linguistic Lumberjack”

Leave a reply

RCE - Fluent Bit (CVE-2024-4323) Linguistic Lumberjack

RCE – Fluent Bit (CVE-2024-4323) “Linguistic Lumberjack”. Fluent Bit is a multi-platform open source tool for collecting and processing logs. It is easy to use, scales well, and can handle large amounts of data. Fluent Bit is often used in the infrastructures of large companies, especially in the infrastructures of cloud providers.

The vulnerability discovered by Tenable Research is related to memory corruption in the built-in Fluent Bit HTTP server. This HTTP server is used to monitor the status of Fluent Bit: uptime, plugin metrics, health checks, etc. Certain unauthenticated requests to the server API may result in denial of service (DoS), information leakage, or remote code execution (RCE). According to researchers, making a reliable RCE exploit will not be easy, but the PoC for DoS is already publicly available and, perhaps, it will be converted into RCE.

The fix is expected in version 3.0.4.

На русском

Regarding Jacob Williams’ idea of using “Accepted Insecure Time” instead of “Service-level Agreement” when discussing vulnerabilities and patches

Leave a reply

Regarding Jacob Williams' idea of using Accepted Insecure Time instead of Service-level Agreement when discussing vulnerabilities and patches

Regarding Jacob Williams’ idea of using “Accepted Insecure Time” instead of “Service-level Agreement” when discussing vulnerabilities and patches. There is logic in this. Indeed, the term SLA hides the essence of the problem: as long as the vulnerability is not fixed (even if IT performs patching in the SLA window), the company can be HACKED. And this is no longer performing service operations, but something else, something more important.

On the other hand, where should this new term be used?

🔹 IT thinks in terms of services. Do you propose to go to them with your newspeak? Looks unconstructive. Nowadays it is common to speak to businesses in their language. Why do you speak to IT in the language of information security? 🤔
🔹 Or are you going to bring this to the business and then translate it into an SLA for IT? Isn’t this an extra unnecessary step? 🙂

BTW, it will be “принятое время незащищённости” (ПВН) in Russian and creates additional allusions to PWN. 😉

На русском