Most recent bundles.

Haunted by Legacy: Discovering and Exploiting Vulnerable Tunnelling Hosts

2025-02-22T13:57:14.052250+00:00

Ref: [https://github.com/vanhoefm/tunneltester/blob/main/README.md](https://github.com/vanhoefm/tunneltester/blob/main/README.md) # Haunted by Legacy: Discovering and Exploiting Vulnerable Tunnelling Hosts ## [1. Introduction](#id-intro) This repository will contain scripts to test whether hosts/servers accept unauthenticated tunneling packets. In particular, it can test whether a host accepts IPIP, IP6IP6, GRE, GRE6, 4in6, and 6in4 packets using various scanning methods. A high-level description of the resulting attacks can be found below, and a detailed description and evaluation of all attacks can be found in our [USENIX Security '25 paper](https://papers.mathyvanhoef.com/usenix2025-tunnels.pdf). **NOTE: To prevent abuse, this scanning script is not yet publicly available. Only the README of the script is available. Please contact [Angelos Beitis](https://www.kuleuven.be/wieiswie/en/person/00165395) and [Mathy Vanhoef](https://www.kuleuven.be/wieiswie/en/person/00086006) to get access to the actual scanning scripts. We can also provide Z-Map modules to scan multiple hosts at once.** For advice on how to mitigate the resulting attacks, see Section 6 in [our paper](https://papers.mathyvanhoef.com/usenix2025-tunnels.pdf). The vulnerabilities were reported to CERT/CC on May 16, 2024, and are being tracked using the identifier VU#199397 and using the [CVE identifiers described below](#id-summary-cves). We have also collaborated with the [Shadowserver Foundation](https://www.shadowserver.org/) to better reach affected organizations, and they are now performing periodic scans for vulnerable tunneling hosts. ## [2. Vulnerability Summary](#id-summary) ![Attack Overview](https://raw.githubusercontent.com/vanhoefm/tunneltester/refs/heads/main/attack_overview.png) We found that many Internet hosts accept unauthenticated [IPIP](https://datatracker.ietf.org/doc/html/rfc2003), [IP6IP6](https://datatracker.ietf.org/doc/html/rfc2473), [GRE](https://datatracker.ietf.org/doc/rfc2784/), [6in4](https://datatracker.ietf.org/doc/html/rfc4213), or [4in6](https://datatracker.ietf.org/doc/html/rfc2473) tunneling packets from an arbitrary source. This means an adversary can send a tunneling packet to such vulnerable hosts, and the vulnerable host will process the encapsulated inner packet, without authenticating (the source of) the tunneling packet. An adversary can abuse this to perform Denail-of-Service attacks, to spoof their source IP address, and possibly to gain access to an organization's private or local network. An example attack, written using the [Python Scapy](https://scapy.net/) library, is: from scapy.all import * inner_packet = IP(src="1.1.1.1", dst="8.8.8.8")/ICMP() vulnerable_host = "1.0.0.1" send(IP(dst=vulnerable_host)/GRE()/inner_packet) The vulnerable host at `1.0.0.1` will receive the IP/GRE packet and then process and forward the inner IP packet to its destination. More worrisome, many vulnerable hosts will perform no sanity checks on the inner packet. This means many vulnerable hosts can be abused to spoof the source IP addresses of packets. As shown in the above example, the forwarded packet can have the IP address `1.1.1.1`, even though the real IP address of the vulnerable host is `1.0.0.1`. This means an ICMP packet will be sent to `8.8.8.8` with as spoofed source address `1.1.1.1`. Similar attacks are possible against IPv4 and IPv6 hosts using the protocols [IPIP](https://datatracker.ietf.org/doc/html/rfc2003), [IP6IP](https://datatracker.ietf.org/doc/html/rfc2473), [GRE6](https://datatracker.ietf.org/doc/rfc2784/), [6in4](https://datatracker.ietf.org/doc/html/rfc4213), or [4in6](https://datatracker.ietf.org/doc/html/rfc2473). Note that we use 'host' as a synonym for an IPv4 or IPv6 address and that we will use 'GRE6' when GRE packets are sent between IPv6 hosts. ### [2.1 Scanning Methods](#id-summary-scans) To detect vulnerable hosts, we scanned the IPv4 and IPv6 Internet using three main methods. These methods are further explained in the indicated sections of our paper: - **Standard Scan** (Section 3.2.1): In this scan, the inner packet is an ICMP ping reply with as source IP address the vulnerable host and as destination our scanning server. We also did a subnet spoofing variant of this scan, where the inner packet has as source an IP address within the same subnet as the host. Additionally, we did a spoofing variant, where the inner packet has a spoofed source IP address that is outside the subnet of the host. - **ICMP Echo/Reply (Ping) Scan** (Section 3.2.2): In this scan, the inner packet is an ICMP ping request with as destination the vulnerable host itself and as source address our scanning server. In case the host is vulnerable, it will process the ping request, and send a ping reply to our scanning server. - **Time Exceeded (TTL) Scan** (Section 3.2.3): In this scan, the inner packet is an IP packet with a Time-To-Live (TTL) equal to one, or an IPv6 packet with a Hop Limit equal to zero. This inner packet has as source address our scanning server, and has as destination address a random public IP address. If the host tries to forward this packet, and hence is vulnerable, it will generate an ICMPv4 or ICMPv6 Time Exceeded packet towards our scanning server. For the 4in6 scans, where we send a tunneling packet to an IPv6 host with as inner packet an IPv4 packet, we cannot perform a ping scan because we do not know the IPv4 address of the IPv6 host being scanner. This also implies we can only do the spoofing variant of the standard scan, because we do not know the IPv4 subnet of the host. For the 6in4 scans, where we send a tunneling packet to an IPv4 host with as inner packet an IPv6 packet, we can use the [IPv4-Mapped IPv6 Address](https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.2) of the form `ffff:IPV4_ADDRESS_IN_HEX::` to perform the standard and ping scans. ### [2.2 Impact Summary](#id-summary-impact) - **Denial-of-Service**: An attack that is always possible is a Denial-of-Service attack by recursively encapsulating tunneling packets and sending this constructed packet to a vulnerable host. The vulnerable host will then recursively keep processing the encapsulated tunneling packets until the last nested packet is reached. This implies that sending a single packet will result in substantial processing time on the vulnerable host. In terms of CPU usage on the vulnerable host, this can result in an amplification factor of 70x when performing a DoS attack, and even higher when combined with IP fragmentation. Depending on the behaviour of the vulnerable tunneling host, other DoS attacks may also be possible, such as a Tunneled-Temporal Lensing Attack or Economic DoS attack. See our draft paper for details. - **Source Address Spoofing**: An adversary can abuse vulnerable tunneling hosts to spoof their source IP address. This is because the vulnerable tunneling host will forward IP packets on behalf of the attacker. A host can spoof source IP addresses when the Standard "subnet spoof" and "spoof" scans indicate that the server is vulnerable. - **Internal Network Access**: In case the vulnerable host is connected to a private network, then the open tunneling host can possibly be abused to gain access to all devices within this connected private network. This may particularly be possible if the vulnerable hosts also implement Network Address Translation (NAT). The precise details of this are still being investigated. ### [2.3 Assigned CVE Identifiers](#id-summary-cves) - [CVE-2020-10136](https://nvd.nist.gov/vuln/detail/CVE-2020-10136): IPv4-in-IPv4 (IPIP) protocol (RFC2003). - [CVE-2024-7595](https://nvd.nist.gov/vuln/detail/CVE-2024-7595): GRE and GRE6 (RFC2784). - [CVE-2024-7596](https://nvd.nist.gov/vuln/detail/CVE-2024-7596): Generic UDP Encapsulation (GUE) (IETF Draft). We did not detect any vulnerable hosts using this draft protocol. - [CVE-2025-23018](https://nvd.nist.gov/vuln/detail/CVE-2025-23018): IPv4-in-IPv6 (4in6) and IPv6-in-IPv6 (IP6IP6) protocols (RFC2473). - [CVE-2025-23019](https://nvd.nist.gov/vuln/detail/CVE-2025-23019): IPv6-in-IPv4 (6in4) protocol (RFC4213). ## [3. Tool Prerequisites](#id-prerequisites) You can execute the following commands to initialize the Python environment to execute the script. We tested these commands on Ubuntu 24.04: python3 -m venv venv source venv/bin/activate pip install wheel scapy==2.4.3 You can then load this Python environment as root and execute the script: sudo su source venv/bin/activate ./tunnel_tester.py ## [4. Steps to Reproduce](#id-reproduce) After the prerequisite steps, you can execute the following command to test IPv4-capable hosts: ./tunnel_tester.py eth0 -t 183.232.161.42 The parameters are: * `-i eth0`: The interface that should be used to send and receive the packets. It must have an IPv4 address, otherwise, no tests are performed. * `-t 183.232.161.42`: This is the IPv4 address of the host being tested. You can test IPv6-capable hosts using the following command: ./tunnel_tester.py eth0 -t6 2a00::1000 The parameters are: * `-i eth0`: The interface that should be used to send and receive the packets. It must have an IPv6 address, otherwise, no tests are performed. * `-t6 2a00::1001`: This is the IPv6 address of the host being tested. The IPv4 and IPv6 tests can also be performed in a single execution: ./tunnel_tester.py -t 183.232.161.42 -t6 2a00::1001 For each performed test, the script will output `SAFE` if no vulnerability was detected, and `VULNERABLE` if a vulnerability was detected. Note that we recommend executing the script multiple times, since sometimes replies may get lost. You can also increase or decrease how long the script waits for replies using the `--timeout` parameter. For instance, by specifying `--timeout 0.5` the script will only wait half a second for replies. ## [5. Advanced Usage](#id-advanced) By default, the script will use the IP address associated to the given interface as the source address in transmitted packets. To use a different source address, or explicitly set the IP address in case it does not get detected properly, you can use: * `-P A.A.A.A`: The IPv4 to use as source address in outgoing IP packets. * `-P6 2a00::1000`: The IPv6 to use as source address in outgoing IP packets. By default, the script will try to spoof IP addresses belonging to KU Leuven University in the standard spoof scan. To try to spoof a different source IP address you can use the following arguments: * `-s 212.224.129.90`: Test whether the vulnerable host has the ability to spoof the given source IPv4 addresses. * `-s6 2a02:2c40:0:80::80:15`: Test whether the vulnerable host has the ability to spoof the given source IPv6 addresses. In the Time Expired TTL scans, the inner IP addresses by default belong to KU Leuven University. To use a different inner destination IP address, in order to trigger packet forward and generate the TTL Expired error, you can use the following arguments: * `-t 212.224.129.90`: Test whether the vulnerable host has the ability to spoof the given source IPv4 addresses. * `-t6 2a02:2c40:0:80::80:15`: Test whether the vulnerable host has the ability to spoof the given source IPv6 addresses. When running the script on an AWS EC2 server, you need to explicitly provide the private and public IP address of the server using the following arguments: * `-p 172.0.0.1`: The private IPv4 address of the scanning server. * `-P 1.2.3.4`: The public IPv4 address of the scanning server. ## [6. Troubleshooting](#id-troubleshooting) - Ensure you are injecting packets on the correct interface! - When you are testing your own vulnerable server, ensure that the `accept_local` and `ip_forwarding` sysctl's for both IPv4/6 are set. Otherwise the host may not be vulnerable to (all) attacks. - With tcpdump you can use the filter `"proto 4 or proto gre or proto 41"` to capture the packets that the scanning tool is transmitting (this will not show possible replies). ## Additional feedback - [https://infosec.exchange/@jeroen@secluded.ch/113831359550444599](https://infosec.exchange/@jeroen@secluded.ch/113831359550444599) `that is only 20 years after http://www.dia.uniroma3.it/~compunet/tunneldiscovery/ and there are other similar papers that wrote this up. It is the full intent and purpose on how those protocols are supposed to be used, and spoofing is a network issue in this case (they rely on a trusted network... ouch). Source Address Validation is one solution, not using non-authenticated protocols another.`

Unit42 Threat Brief: CVE-2025-0282 and CVE-2025-0283

2025-02-22T13:57:14.052200+00:00

On Jan. 8, 2025, Ivanti released a security advisory for two vulnerabilities (CVE-2025-0282 and CVE-2025-0283) in its Connect Secure, Policy Secure and ZTA gateway products. This threat brief provides attack details that we observed in a recent incident response engagement to provide actionable intelligence to the community. These details can be used to further detect current attacks noted in the wild using CVE-2025-0282. These Ivanti products are all appliances that facilitate remote connections into a network. As such, they are outward-facing assets that attackers could target to infiltrate a network. CVE-2025-0282 is a stack-based buffer overflow in Ivanti Connect Secure before version 22.7R2.5, Ivanti Policy Secure before version 22.7R1.2 and Ivanti Neurons for ZTA gateways before version 22.7R2.3 that allows a remote unauthenticated attacker to achieve remote code execution. This vulnerability has been assigned a critical CVSS score of 9.0. CVE-2025-0283 is a stack-based buffer overflow in Ivanti Connect Secure before version 22.7R2.5, Ivanti Policy Secure before version 22.7R1.2 and Ivanti Neurons for ZTA gateways before version 22.7R2.3 that allows a local authenticated attacker to escalate their privileges. This vulnerability has been assigned a high CVSS score of 7.0. On the same day of Ivanti’s advisory, Mandiant disclosed its findings of attacks in the wild using the CVE-2025-0282 remote code execution vulnerability. On January 10, Watchtowr Labs also provided analysis of the exploited vulnerability. On January 12, Watchtowr provided a walkthrough and on January 16 they published a proof of concept (PoC). For more info [https://unit42.paloaltonetworks.com/threat-brief-ivanti-cve-2025-0282-cve-2025-0283/](https://unit42.paloaltonetworks.com/threat-brief-ivanti-cve-2025-0282-cve-2025-0283/)

CISA and FBI Release Advisory on How Threat Actors Chained Vulnerabilities in Ivanti Cloud Service Applications

2025-02-22T13:57:14.052150+00:00

CISA, in partnership with the Federal Bureau of Investigation (FBI), released Threat Actors Chained Vulnerabilities in Ivanti Cloud Service Applications. This advisory was crafted in response to active exploitation of vulnerabilities—CVE-2024-8963, an administrative bypass vulnerability; CVE-2024-9379, a SQL injection vulnerability; and CVE-2024-8190 and CVE-2024-9380, remote code execution vulnerabilities—in Ivanti Cloud Service Appliances (CSA) in September 2024. CISA, and the use of trusted third-party incident response data, found that threat actors chained the listed vulnerabilities to gain initial access, conduct remote code execution (RCE), obtain credentials, and implant webshells on victim networks. CISA and FBI strongly encourage network administrators and defenders to upgrade to the latest supported version of Ivanti CSA and to hunt for malicious activity on their networks using the detection methods and indicators of compromise (IOCs) provided in the advisory. All members of the cybersecurity community are also encouraged to visit CISA’s Known Exploited Vulnerabilities Catalog to help better manage vulnerabilities and keep pace with threat activity. For more information and guidance on protection against the most common and impactful threats, tactics, techniques, and procedures, visit CISA’s Cross-Sector Cybersecurity Performance Goals. Ref: [https://www.cisa.gov/news-events/alerts/2025/01/22/cisa-and-fbi-release-advisory-how-threat-actors-chained-vulnerabilities-ivanti-cloud-service](https://www.cisa.gov/news-events/alerts/2025/01/22/cisa-and-fbi-release-advisory-how-threat-actors-chained-vulnerabilities-ivanti-cloud-service)

CISA Releases Fact Sheet Detailing Embedded Backdoor Function of Contec CMS8000 Firmware

2025-02-22T13:57:14.052101+00:00

CISA released a fact sheet, Contec CMS8000 Contains a Backdoor, detailing an analysis of three firmware package versions of the Contec CMS8000, a patient monitor used by the U.S. Healthcare and Public Health (HPH) sector. Analysts discovered that an embedded backdoor function with a hard-coded IP address, CWE – 912: Hidden Functionality (CVE-2025-0626), and functionality that enables patient data spillage, CWE – 359: Exposure of Private Personal Information to an Unauthorized Actor (CVE-2025-0683 ), exists in all versions analyzed. Please note the Contec CMS8000 may be re-labeled and sold by resellers. For a list of known re-labeled devices, please refer to FDA’s safety communication, Cybersecurity Vulnerabilities with Certain Patient Monitors from Contec and Epsimed: FDA Safety Communication. Contec Medical Systems, the company which manufactures this monitor as well as other medical device and healthcare solutions, is headquartered in Qinhuangdao, China. The Contec CMS8000 is used in medical settings across the U.S. and European Union to provide continuous monitoring of a patient’s vital signs—tracking electrocardiogram, heart rate, blood oxygen saturation, non-invasive blood pressure, temperature, and respiration rate. CISA assesses that inclusion of this backdoor in the firmware of the patient monitor can create conditions which may allow remote code execution and device modification with the ability to alter its configuration. This introduces risk to patient safety as a malfunctioning patient monitor could lead to an improper response to patient vital signs. CISA strongly urges HPH sector organizations review the fact sheet and implement FDA's mitigations. Visit CISA’s Healthcare and Public Health Cybersecurity page to learn more about how to help improve cybersecurity within the HPH sector. For more information and guidance on protection against the most common and impactful threats, tactics, techniques, and procedures, visit CISA’s Cross-Sector Cybersecurity Performance Goals. [Reference](https://www.cisa.gov/news-events/alerts/2025/01/30/cisa-releases-fact-sheet-detailing-embedded-backdoor-function-contec-cms8000-firmware)

Threat Actors Use CVE-2019-18935 to Deliver Reverse Shells and…

2025-02-22T13:57:14.052053+00:00

From: [https://www.esentire.com/blog/threat-actors-use-cve-2019-18935-to-deliver-reverse-shells-and-juicypotatong-privilege-escalation-tool](https://www.esentire.com/blog/threat-actors-use-cve-2019-18935-to-deliver-reverse-shells-and-juicypotatong-privilege-escalation-tool) # Threat Actors Use CVE-2019-18935 to Deliver Reverse Shells and… BY eSentire Threat Response Unit (TRU) Adversaries don’t work 9-5 and neither do we. At eSentire, our 24/7 SOCs are staffed with Elite Threat Hunters and Cyber Analysts who hunt, investigate, contain and respond to threats within minutes. We have discovered some of the most dangerous threats and nation state attacks in our space – including the Kaseya MSP breach and the more_eggs malware. Our Security Operations Centers are supported with Threat Intelligence, Tactical Threat Response and Advanced Threat Analytics driven by our Threat Response Unit – the TRU team. In TRU Positives, eSentire’s Threat Response Unit (TRU) provides a summary of a recent threat investigation. We outline how we responded to the confirmed threat and what recommendations we have going forward. Here’s the latest from our TRU Team… What did we find? In early January 2025, the eSentire Threat Response Unit (TRU) identified an unknown threat actor(s) exploiting the now six year old vulnerability, CVE-2019-18935, in Progress Telerik UI for ASP.NET AJAX. TRU observed threat actor(s) using the w3wp.exe (IIS worker process) to load a reverse shell and run follow up commands for reconnaissance through cmd.exe. Reverse shells were dropped in the C:\Windows\Temp directory matching [10 digits].[6 digits].dll and [10 digits].[7 digits].dll. The infection process begins when the threat actor(s) send a specific request to the IIS server to determine if the file upload handler is available. This can be seen in IIS logs as shown below: 2025-01-03 10:25:51 10.22.12.20 GET /Telerik.Web.UI.WebResource.axd type=rau 443 - - - 200 0 0 171 After confirming the file upload handler is available and determining the software version is vulnerable, the threat actor(s) made use of a customized version of the PoC here to upload and execute a remote shell. The reverse shell is simple and is a mixed mode .NET assembly containing a routine that serves to connect to the C2 at 213.136.75[.]130 via Windows Sockets. The legitimate windows binary cmd.exe is started and the input/output/error handles are redirected to threat actor control. Figure 1 – Decompiled reverse shell Figure 1 – Decompiled reverse shell After the threat actor(s) established connection via the reverse shell, they executed several commands to get information about users on the system. The figure below contains the parent/child relationships and subsequent commands executed through the reverse shell to enumerate users via net.exe and net1.exe. Figure 2 – Remote shell loaded by w3wp.exe IIS worker process leading to recon commands Figure 2 – Remote shell loaded by w3wp.exe IIS worker process leading to recon commands The following Yara rule can be used for detecting the reverse shell. This Yara rule is also available for download here. rule TCP_Reverse_Shell_Windows_x64 { meta: description = "Detects Windows based 64-bit TCP reverse shell" author = "YungBinary" hash = "b971bf43886e3ab1d823477826383dfaee1e2935788226a285c7aebeabee7348" strings: $winsock_2_0 = { 66 B? 02 00 FF 15 } $winsock_2_1 = { 66 B? 02 01 FF 15 } $winsock_2_2 = { 66 B? 02 02 FF 15 } $winsock_1_0 = { 66 B? 01 00 FF 15 } $winsock_1_1 = { 66 B? 01 01 FF 15 } $socket_params = { 41 B8 06 00 00 00 BA 01 00 00 00 B9 02 00 00 00 } $cmd = { 48 C7 44 24 ?? 00 00 00 00 48 C7 44 24 ?? 00 00 00 00 C7 44 24 ?? 00 00 00 00 C7 44 24 ?? (01 | 00) 00 00 00 45 33 C9 45 33 C0 48 8D 15 ?? ?? ?? ?? 33 C9 FF 15 } $wait = { BA FF FF FF FF 48 8B 4C ?? ?? FF 15 } condition: uint16(0) == 0x5a4d and ((1 of ($winsock*)) and $socket_params and $cmd and $wait) } Figure 3 – Yara rule to detect Windows TCP reverse shell TRU also observed the threat actor(s) dropping the open-source privilege escalation tool JuicyPotatoNG on the host under various file names: C:\Users\Public\PingCaler.exe C:\Users\Public\JuicyPotatoNG.exe The following batch files were also dropped on the host but the purpose of these files is not known at this time: C:\Users\Public\rdp.bat C:\Users\Public\user.bat C:\Users\Public\All.bat The following diagram provided by Telerik can be used to determine if your specific version of Telerik UI for ASP.NET AJAX is vulnerable. Figure 4 – Vulnerable version decision tree diagram, source Figure 4 – Vulnerable version decision tree diagram, source. What did we do? Our team of 24/7 SOC Cyber Analysts proactively isolated the affected host to contain the infection on the customer’s behalf. We communicated what happened with the customer and helped them with incident remediation efforts. What can you learn from this TRU Positive? While the vulnerability in Progress Telerik UI for ASP.NET AJAX is several years old, it continues to be a viable entry point for threat actors. This highlights the importance of patching systems, especially if they are going to be exposed to the internet. Recommendations from the Threat Response Unit (TRU): Implement a comprehensive vulnerability management service with robust patch management solution and process to ensure systems are up to date with the latest security patches before exposing them to the Internet. Use an Endpoint Detection and Response (EDR) solution and ensure it is deployed across all workstations and servers. Indicators of Compromise You can access the Indicators of Compromise here. References https://www.esentire.com/security-advisories/active-exploitation-of-cve-2019-18935 https://bishopfox.com/blog/cve-2019-18935-remote-code-execution-in-telerik-ui https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/common-allows-javascriptserializer-deserialization https://github.com/noperator/CVE-2019-18935 https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-074a https://github.com/antonioCoco/JuicyPotatoNG

Android Security Bulletin February 2025

2025-02-22T13:57:14.052002+00:00

Android Security Bulletin February 2025 Published February 3, 2025 The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2025-02-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version. Android partners are notified of all issues at least a month before publication. Source code patches for these issues have been released to the Android Open Source Project (AOSP) repository and linked from this bulletin. This bulletin also includes links to patches outside of AOSP. The most severe of these issues is a high security vulnerability in the Framework component that could lead to local escalation of privilege with no additional execution privileges needed. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed. Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform. Android and Google service mitigations This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android. Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible. The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play. Note: There are indications that CVE-2024-53104 may be under limited, targeted exploitation. 2025-02-01 security patch level vulnerability details In the sections below, we provide details for each of the security vulnerabilities that apply to the 2025-02-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates. Framework The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed. CVE References Type Severity Updated AOSP versions CVE-2024-49721 A-354682735 EoP High 12, 12L, 13 CVE-2024-49743 A-305695605 [2] [3] EoP High 12, 12L, 13, 14, 15 CVE-2024-49746 A-359179312 [2] EoP High 12, 12L, 13, 14, 15 CVE-2025-0097 A-364037868 EoP High 15 CVE-2025-0098 A-367266072 EoP High 15 CVE-2025-0099 A-370962373 EoP High 15 CVE-2023-40122 A-286235483 ID High 12, 12L, 13, 14, 15 CVE-2023-40133 A-283264674 ID High 12, 12L, 13 CVE-2023-40134 A-283101289 ID High 12, 12L, 13 CVE-2023-40135 A-281848557 ID High 12, 12L, 13 CVE-2023-40136 A-281666022 ID High 12, 12L, 13 CVE-2023-40137 A-281665050 ID High 12, 12L, 13 CVE-2023-40138 A-281534749 ID High 12, 12L, 13 CVE-2023-40139 A-281533566 ID High 12, 12L, 13 CVE-2024-0037 A-292104015 ID High 12, 12L, 13, 14, 15 CVE-2025-0100 A-372670004 ID High 12, 12L, 13, 14, 15 CVE-2024-49741 A-353240784 DoS High 12, 12L, 13, 14, 15 Platform The vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed. CVE References Type Severity Updated AOSP versions CVE-2025-0094 A-352542820 EoP High 12, 12L, 13, 14, 15 System The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed. CVE References Type Severity Updated AOSP versions CVE-2025-0091 A-366401629 EoP High 12, 12L, 13, 14, 15 CVE-2025-0095 A-356117796 EoP High 14, 15 CVE-2025-0096 A-356630194 EoP High 15 CVE-2024-49723 A-357870429 [2] ID High 15 CVE-2024-49729 A-368069390 ID High 12, 12L, 13, 14, 15 Google Play system updates The following issues are included in Project Mainline components. Subcomponent CVE Conscrypt CVE-2024-49723 2025-02-05 security patch level vulnerability details In the sections below, we provide details for each of the security vulnerabilities that apply to the 2025-02-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Kernel The most severe vulnerability in this section could lead to physical escalation of privilege with no additional execution privileges needed. CVE References Type Severity Subcomponent CVE-2024-53104 A-378455392 Upstream kernel [2] EoP High UVC CVE-2025-0088 A-377672115 Upstream kernel [2] EoP High mremap Arm components This vulnerability affects Arm components and further details are available directly from Arm. The severity assessment of this issue is provided directly by Arm. CVE References Severity Subcomponent CVE-2025-0015 A-376311652 * High Mali Imagination Technologies These vulnerabilities affect Imagination Technologies components and further details are available directly from Imagination Technologies. The severity assessment of these issues is provided directly by Imagination Technologies. CVE References Severity Subcomponent CVE-2024-43705 A-372931317 PP-160756* High PowerVR-GPU CVE-2024-46973 A-379728401 PP-160739* High PowerVR-GPU CVE-2024-47892 A-365954523 PP-160576 * High PowerVR-GPU CVE-2024-52935 A-380478495 PP-171230* High PowerVR-GPU MediaTek components These vulnerabilities affect MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek. CVE References Severity Subcomponent CVE-2025-20634 A-381773169 M-MOLY01289384 * High Modem CVE-2024-20141 A-381773173 M-ALPS09291402 * High DA CVE-2024-20142 A-381773175 M-ALPS09291406 * High DA CVE-2025-20635 A-381771695 M-ALPS09403752 * High DA CVE-2025-20636 A-381773171 M-ALPS09403554 * High secmem Unisoc components This vulnerability affects Unisoc components and further details are available directly from Unisoc. The severity assessment of this issue is provided directly by Unisoc. CVE References Severity Subcomponent CVE-2024-39441 A-381429835 U-2811333 * High Android Qualcomm components These vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm. CVE References Severity Subcomponent CVE-2024-45569 A-377311993 QC-CR#3852339 Critical WLAN CVE-2024-45571 A-377313069 QC-CR#3834424 High WLAN CVE-2024-45582 A-377312377 QC-CR#3868093 High Camera CVE-2024-49832 A-377312238 QC-CR#3874301 High Camera CVE-2024-49833 A-377312639 QC-CR#3874372 [2] [3] [4] High Camera CVE-2024-49834 A-377312055 QC-CR#3875406 High Camera CVE-2024-49839 A-377311997 QC-CR#3895196 High WLAN CVE-2024-49843 A-377313194 QC-CR#3883522 High Display Qualcomm closed-source components These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm. CVE References Severity Subcomponent CVE-2024-38404 A-357616389 * High Closed-source component CVE-2024-38420 A-357616296 * High Closed-source component Common questions and answers This section answers common questions that may occur after reading this bulletin. 1. How do I determine if my device is updated to address these issues? To learn how to check a device's security patch level, see Check and update your Android version. Security patch levels of 2025-02-01 or later address all issues associated with the 2025-02-01 security patch level. Security patch levels of 2025-02-05 or later address all issues associated with the 2025-02-05 security patch level and all previous patch levels. Device manufacturers that include these updates should set the patch string level to: [ro.build.version.security_patch]:[2025-02-01] [ro.build.version.security_patch]:[2025-02-05] For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2025-02-01 security patch level. Please see this article for more details on how to install security updates. 2. Why does this bulletin have two security patch levels? This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level. Devices that use the 2025-02-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins. Devices that use the security patch level of 2025-02-05 or newer must include all applicable patches in this (and previous) security bulletins. Partners are encouraged to bundle the fixes for all issues they are addressing in a single update. 3. What do the entries in the Type column mean? Entries in the Type column of the vulnerability details table reference the classification of the security vulnerability. Abbreviation Definition RCE Remote code execution EoP Elevation of privilege ID Information disclosure DoS Denial of service N/A Classification not available 4. What do the entries in the References column mean? Entries under the References column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs. Prefix Reference A- Android bug ID QC- Qualcomm reference number M- MediaTek reference number N- NVIDIA reference number B- Broadcom reference number U- UNISOC reference number 5. What does an * next to the Android bug ID in the References column mean? Issues that are not publicly available have an * next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site. 6. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin? Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

February Security Advisory Ivanti Connect Secure (ICS),Ivanti Policy Secure (IPS) and Ivanti Secure Access Client (ISAC) (Multiple CVEs)

2025-02-22T13:57:14.051947+00:00

February Security Advisory Ivanti Connect Secure (ICS),Ivanti Policy Secure (IPS) and Ivanti Secure Access Client (ISAC) (Multiple CVEs) Primary Product Connect-Secure Created Date Feb 11, 2025 3:01:15 PM Last Modified Date Feb 11, 2025 3:37:50 PM **Summary** Ivanti has released updates for Ivanti Connect Secure (ICS),Ivanti Policy Secure (IPS) and Ivanti Secure Access Client (ISAC) which addresses medium, high and critical severity vulnerabilities. We are not aware of any customers being exploited by these vulnerabilities at the time of disclosure. **Vulnerability Details** **CVE Number** **Description** **CVSS Score (Severity)** **CVSS Vector** **CWE** **Impacted Products** CVE-2024-38657 External control of a file name in Ivanti Connect Secure before version 22.7R2.4 and Ivanti Policy Secure before version 22.7R1.3 allows a remote authenticated attacker with admin privileges to write arbitrary files. 9.1 (Critical) CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H CWE-73 Connect Secure & Policy Secure CVE-2025-22467 A stack-based buffer overflow in Ivanti Connect Secure before version 22.7R2.6 allows a remote authenticated attacker to achieve remote code execution. 9.9 (Critical) CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H CWE-121 Connect Secure CVE-2024-10644 Code injection in Ivanti Connect Secure before version 22.7R2.4 and Ivanti Policy Secure before version 22.7R1.3 allows a remote authenticated attacker with admin privileges to achieve remote code execution. 9.1 (Critical) CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H CWE-94 Connect Secure & Policy Secure CVE-2024-12058 External control of a file name in Ivanti Connect Secure before version 22.7R2.6 and Ivanti Policy Secure before version 22.7R1.3 allows a remote authenticated attacker with admin privileges to read arbitrary files. 6.8 (Medium) CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N CWE-73 Connect Secure & Policy Secure CVE-2024-13830 Reflected XSS in Ivanti Connect Secure before version 22.7R2.6 and Ivanti Policy Secure before version 22.7R1.3 allows a remote unauthenticated attacker to obtain admin privileges. User interaction is required. 6.1 (Medium) CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N CWE-79 Connect Secure & Policy Secure CVE-2024-13842 A hardcoded key in Ivanti Connect Secure before version 22.7R2.3 and Ivanti Policy Secure before version 22.7R1.3 allows a local unauthenticated attacker to read sensitive data. 6.0 (Medium) CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N CWE-321 Connect Secure & Policy Secure CVE-2024-13843 Cleartext storage of information in Ivanti Connect Secure before version 22.7R2.6 and Ivanti Policy Secure before version 22.7R1.3 allows a local unauthenticated attacker to read sensitive data. 6.0 (Medium) CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N CWE-312 Connect Secure & Policy Secure CVE-2024-13813 Insufficient permissions in Ivanti Secure Access Client before version 22.8R1 allows a local authenticated attacker to delete arbitrary files. 7.1 (High) CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H CWE-732 Secure Access Client Affected Versions **Product Name** **Affected Versions** **Resolved Versions** **Patch Availability** Ivanti Connect Secure (ICS) 22.7R2.5 and below 22.7R2.6 Download Portal [https://portal.ivanti.com/](https://portal.ivanti.com/) Ivanti Policy Secure (IPS) 22.7R1.2 and below 22.7R1.3 Download Portal [https://portal.ivanti.com/](https://portal.ivanti.com/) Ivanti Secure Access Client (ISAC) 22.7R4 and below 22.8R1 Download Portal [https://portal.ivanti.com/](https://portal.ivanti.com/) **Solution** These vulnerabilities are resolved on the latest version of the product and can be accessed in the download portal (Login Required): * Ivanti Connect Secure 22.7R2.6 * Ivanti Policy Secure 22.7R1.3 * Ivanti Secure Access Client 22.8R1 **Acknowledgements** Ivanti would like to thank the following for reporting the relevant issues and for working with Ivanti to help protect our customers: * Matthew Galligan, CISA Rapid Action Force (CVE-2024-38657) * Ori David of Akamai (CVE-2024-37374, CVE-2024-37375) * sim0nsecurity of HackerOne (CVE-2024-13813) _Note: Ivanti is dedicated to ensuring the security and integrity of our enterprise software products. We recognize the vital role that security researchers, ethical hackers, and the broader security community play in identifying and reporting vulnerabilities. Visit_ [_HERE_](https://www.ivanti.com/support/contact-security) _to learn more about our Vulnerability Disclosure Policy._ **_FAQ_** 1. **Are you aware of any active exploitation of these vulnerabilities?** We are not aware of any customers being exploited by these vulnerabilities prior to public disclosure. These vulnerabilities were disclosed through our responsible disclosure program. 2. **How can I tell if I have been compromised?** Currently, there is no known public exploitation of this vulnerability that could be used to provide a list of indicators of compromise. 3. **What should I do if I need help?** If you have questions after reviewing this information, you can log a case and/or request a call via the [Success Portal](https://success.ivanti.com/Community_RegStep1_Page?inst=UL) 4. **Are any of these vulnerability fixes backported to any of the 9.x versions?** No. The Pulse Connect Secure 9.x version of the product reached End of Engineering June 2024 and has reached End-of-Support as of December 31, 2024. Because of this, the 9.x version of Connect Secure no longer receives backported fixes. We strongly encourage customers to upgrade to Ivanti Connect Secure 22.7 to benefit from important security updates that we have made throughout the solution. 5. **What does it mean when a vulnerability describes remote authenticated attackers?** It means that an attacker who is able to interact with the vulnerable component and pass authentication is able to exploit the vulnerability. Article Number : 000097586

Fortinet - Authentication bypass in Node.js websocket module and CSF requests

2025-02-22T13:57:14.051880+00:00

PSIRT | FortiGuard Labs ======================= ### Summary An Authentication Bypass Using an Alternate Path or Channel vulnerability \[CWE-288\] affecting FortiOS and FortiProxy may allow a remote attacker to gain super-admin privileges via crafted requests to Node.js websocket module or via crafted CSF proxy requests. Please note that reports show this is being exploited in the wild. Version Affected Solution FortiOS 7.6 Not affected Not Applicable FortiOS 7.4 Not affected Not Applicable FortiOS 7.2 Not affected Not Applicable FortiOS 7.0 7.0.0 through 7.0.16 Upgrade to 7.0.17 or above FortiOS 6.4 Not affected Not Applicable FortiProxy 7.6 Not affected Not Applicable FortiProxy 7.4 Not affected Not Applicable FortiProxy 7.2 7.2.0 through 7.2.12 Upgrade to 7.2.13 or above FortiProxy 7.0 7.0.0 through 7.0.19 Upgrade to 7.0.20 or above FortiProxy 2.0 Not affected Not Applicable Follow the recommended upgrade path using our tool at: [https://docs.fortinet.com/upgrade-tool](https://docs.fortinet.com/upgrade-tool) ### IoCs The following log entries are possible IOC's: * Following login activity log with random scrip and dstip: type="event" subtype="system" level="information" vd="root" logdesc="Admin login successful" sn="1733486785" user="admin" ui="jsconsole" method="jsconsole" srcip=1.1.1.1 dstip=1.1.1.1 action="login" status="success" reason="none" profile="super\_admin" msg="Administrator admin logged in successfully from jsconsole" * Following admin creation log with seemingly randomly generated user name and source IP: type="event" subtype="system" level="information" vd="root" logdesc="Object attribute configured" user="admin" ui="jsconsole(127.0.0.1)" action="Add" cfgtid=1411317760 cfgpath="system.admin" cfgobj="vOcep" cfgattr="password\[\*\]accprofile\[super\_admin\]vdom\[root\]" msg="Add system.admin vOcep" * The following IP addresses were mostly found used by attackers in above logs: 1.1.1.1 127.0.0.1 2.2.2.2 8.8.8.8 8.8.4.4 Please note that the above IP parameters are not the actual source IP addresses of the attack traffic, they are generated arbitrarily by the attacker as a parameter. Because of this they should not be used for any blocking. Please note as well that sn and cfgtid are not relevant to the attack. The operations performed by the Threat Actor (TA) in the cases we observed were part or all of the below: \- Creating an admin account on the device with random user name \- Creating a Local user account on the device with random user name \- Creating a user group or adding the above local user to an existing sslvpn user group \- Adding/changing other settings (firewall policy, firewall address, ...) \- Logging in the sslvpn with the above added local users to get a tunnel to the internal network. Admin or Local user created by the TA is randomly generated. e.g: Gujhmk Ed8x4k G0xgey Pvnw81 Alg7c4 Ypda8a Kmi8p4 1a2n6t 8ah1t6 M4ix9f ...etc... Additionally, the TA has been seen using the following IP addresses: 45.55.158.47 \[most used IP address\] 87.249.138.47 155.133.4.175 37.19.196.65 149.22.94.37 ### Workaround Disable HTTP/HTTPS administrative interface OR Limit IP addresses that can reach the administrative interface via local-in policies: config firewall address edit "my\_allowed\_addresses" set subnet end Then create an Address Group: config firewall addrgrp edit "MGMT\_IPs" set member "my\_allowed\_addresses" end Create the Local in Policy to restrict access only to the predefined group on management interface (here: port1): config firewall local-in-policy edit 1 set intf port1 set srcaddr "MGMT\_IPs" set dstaddr "all" set action accept set service HTTPS HTTP set schedule "always" set status enable next edit 2 set intf "any" set srcaddr "all" set dstaddr "all" set action deny set service HTTPS HTTP set schedule "always" set status enable end If using non default ports, create appropriate service object for GUI administrative access: config firewall service custom edit GUI\_HTTPS set tcp-portrange 443 next edit GUI\_HTTP set tcp-portrange 80 end Use these objects instead of "HTTPS HTTP "in the local-in policy 1 and 2 below. Please note that the trusthost feature achieves the same as the local-in policies above _only_ if all GUI users are configured with it. Therefore, the local-in policies above are the preferred workaround. Please note as well that an attacker needs to know an admin account's username to perform the attack and log in the CLI. Therefore, having a non-standard and non-guessable username for admin accounts does offer some protection, and is, in general, a [best practice](https://fortinetweb.s3.amazonaws.com/docs.fortinet.com/v2/attachments/81327170-6878-11ea-9384-00505692583a/FortiOS-6.4.0-Hardening_your_FortiGate.pdf). Keep in mind however that the targeted websocket not being an authentication point, nothing would prevent an attacker from bruteforcing the username. Please contact customer support for assistance. CSF requests issue: Disable Security Fabric from the CLI: Config system csf Set status disable end ### Acknowledgement Fortinet is pleased to thank Sonny of watchTowr ([https://watchtowr.com/)](https://watchtowr.com/)) for reporting the CSF related vulnerability under responsible disclosure. ### Timeline 2025-01-14: Format 2025-01-15: Added non-standard admin account username best practice 2025-01-15: Clarified that IP addresses "under attacker control" means they are arbitrarily generated by the attacker 2025-01-21: Added IPS package info 2025-01-24: Removed IPS package info 2025-02-11: Added CVE-2025-24472 and its acknowledgement CVE-2024-55591 and CVE-2025-24472

Console Chaos: A Campaign Targeting Publicly Exposed Management Interfaces on Fortinet FortiGate Firewalls - Arctic Wolf

2025-02-22T13:57:14.051787+00:00

Key Takeaways ------------- * Arctic Wolf observed a recent campaign affecting Fortinet FortiGate firewall devices with management interfaces exposed on the public internet. * The campaign involved unauthorized administrative logins on management interfaces of firewalls, creation of new accounts, SSL VPN authentication through those accounts, and various other configuration changes. * While the initial access vector is not definitively confirmed, a zero-day vulnerability is highly probable. * Organizations should urgently disable firewall management access on public interfaces as soon as possible. Summary ------- In early December, Arctic Wolf Labs [began observing a campaign](https://arcticwolf.com/resources/blog/arctic-wolf-observes-targeting-of-publicly-exposed-fortinet-firewall-management-interfaces/) involving suspicious activity on Fortinet FortiGate firewall devices. By gaining access to management interfaces on affected firewalls, threat actors were able to alter firewall configurations. In compromised environments, threat actors were observed extracting credentials using DCSync. While the initial access vector used in this campaign is not yet confirmed, Arctic Wolf Labs assesses with high confidence that mass exploitation of a zero-day vulnerability is likely given the compressed timeline across affected organizations as well as firmware versions affected. We are sharing details of this campaign to help organizations defend against this threat. Please note that our investigation of this campaign is ongoing, and we may add further detail to this article as we uncover additional information. **Update:** On January 14, 2025, Fortinet [published an advisory](https://www.fortiguard.com/psirt/FG-IR-24-535) confirming the existence of an authentication bypass vulnerability affecting FortiOS and FortiProxy products, which was designated as CVE-2024-55591. The advisory also confirmed key details observed in the campaign described here. See our [security bulletin](https://arcticwolf.com/resources/blog/cve-2024-55591/) for updated remediation guidance. Background ---------- FortiGate next-generation firewall (NGFW) products have a feature that allow administrators to access the command-line interface through the web-based management interface. This comes as a standard feature on most NGFW devices and is a convenient feature for administrators. The CLI Console feature in the FortiGate web interface ([source](https://docs.fortinet.com/document/fortigate/6.4.5/administration-guide/639044/cli-script-action)) According to the [FortiGate Knowledge Base](https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-check-filter-configuration-changes-logs/ta-p/269484), when changes are made via the web-based CLI console, the user interface is logged as jsconsole along with the source IP address of whomever made the changes. In contrast, changes made via ssh would be listed as ssh for the user interface instead. Behind the scenes, there are proprietary command-line tools that FortiGate software uses to perform administrative functions. One binary in particular, newcli, is [described](https://community.fortinet.com/t5/FortiGate/Technical-Tip-Short-list-of-processes-on-the-FortiGate/ta-p/190775) as managing the creation and termination of CLI connections. In a [2023 report](https://www.synacktiv.com/sites/default/files/2023-01/fortimanager_multiple_vulnerabilities_2021_published_lpe.pdf) by Synacktiv about CVE-2022-26118, a privilege escalation vulnerability, a proof-of-concept bash session is provided that demonstrates how threat actors could invoke the newcli utility to add backdoor users. Notably, the –userfrom switch specifies a value of jsconsole(127.0.0.1), suggesting that a loopback interface can be arbitrarily specified as the source IP address for initiation of a CLI console. ``` bash$ cat add_backdoor_user.txt config system admin user edit backdoor set password backdoor set profileid Super_User set adom "all_adoms" end exit bash$ cat add_backdoor_user.txt | /bin/newcli system system \ --userfrom="jsconsole(127.0.0.1)" \ --adminprof=Super_User --adom=root --from_sid=0 ``` Although we do not have direct confirmation that such commands are utilized in the present campaign, the observed activities follow a similar pattern in the way they invoke jsconsole. What We Know About the Campaign ------------------------------- At a high level, the present campaign can be thought of in 4 distinct phases: 1. Vulnerability scanning (November 16, 2024 to November 23, 2024) 2. Reconnaissance (November 22, 2024 to November 27, 2024) 3. SSL VPN configuration (December 4, 2024 to December 7, 2024) 4. Lateral Movement (December 16, 2024 to December 27, 2024) These phases are delineated by the types of malicious configuration changes that were observed on compromised firewall devices across multiple victim organizations, and the activities that were taken by threat actors upon gaining access. Note, however, that our portrayal of these phases may be incomplete or oversimplified given that our visibility is likely limited to a narrow subset of the overall activity in the campaign. What stands out about these activities in contrast with legitimate firewall activities is the fact that they made extensive use of the jsconsole interface from a handful of unusual IP addresses. Given subtle differences in tradecraft and infrastructure between intrusions, it is possible that multiple individuals or groups may have been involved in this campaign, but jsconsole usage was a common thread across the board. The firmware versions of devices that were affected ranged between 7.0.14 and 7.0.16, which were released on February 2024 and October 2024 respectively. ### Phase 1: Vulnerability scanning One of the most notable indicators of compromise in this campaign is the use of jsconsole sessions with connections to and from unusual IP addresses, such as loopback addresses and popular DNS resolvers including Google Public DNS and Cloudflare. These combinations of source and destination IP addresses are not typical for jsconsole activity, making them an ideal target for threat hunting. These values appear to be spoofed, since jsconsole traffic to and from these IP addresses would not be possible without the threat actor having control over them. |Source IP Address|Destination IP address| |-----------------|----------------------| |127.0.0.1 |127.0.0.1 | |8.8.8.8 |8.8.4.4 | |1.1.1.1 |2.2.2.2 | Anomalous source and destination IP addresses for jsconsole administrative logins Numerous successful admin login events from jsconsole were observed originating from the anomalous IP addresses, all using the admin account. Interestingly, jsconsole login events using loopback IP addresses seemed to occur more frequently than events with the other two pairs of addresses using DNS resolvers, especially during the first phase of the campaign. In contrast, beyond the first phase of the campaign, events with the DNS resolver IP addresses were more commonly associated with configuration changes than those with the loopback addresses. ``` date=2024-12-07 time=REDACTED devname="REDACTED" devid="REDACTED" eventtime=REDACTED tz="-0500" logid="0100032001" type="event" subtype="system" level="information" vd="root" logdesc="Admin login successful" sn="REDACTED" user="admin" ui="jsconsole" method="jsconsole" srcip=127.0.0.1 dstip=127.0.0.1 action="login" status="success" reason="none" profile="super_admin" msg="Administrator admin logged in successfully from jsconsole" ``` Additionally, there was corresponding traffic to and from loopback interfaces on TCP port 8023, which [according to the Fortinet Knowledge Base](https://community.fortinet.com/t5/Customer-Service/Technical-Tip-FortiGate-inside-socket-for-Web-CLI/ta-p/219844) is the web CLI port. Loopback traffic was also observed on TCP port 9980, which is [used internally](https://community.fortinet.com/t5/FortiGate/Technical-Tip-Logs-regarding-port-9980-and-local-traffic/ta-p/222791) by the web-based management interface for security fabric and REST API queries on FortiGate devices. The timestamps of traffic on ports 8023 and 9980 matched jsconsole activity down to the second. ``` date=2024-12-07 time=REDACTED devname="REDACTED" devid="REDACTED" eventtime=REDACTED tz="-0500" logid="0001000014" type="traffic" subtype="local" level="notice" vd="root" srcip=127.0.0.2 srcport=REDACTED srcintf="root" srcintfrole="undefined" dstip=127.0.0.1 dstport=8023 dstintf="root" dstintfrole="undefined" srccountry="Reserved" dstcountry="Reserved" sessionid=REDACTED proto=6 action="close" policyid=0 service="tcp/8023" trandisp="noop" app="tcp/8023" duration=1 sentbyte=879 rcvdbyte=778 sentpkt=14 rcvdpkt=14 appcat="unscanned" ``` The first occurrences of this type of jsconsole activity were observed in the wild as early as November 16, 2024 across victim organizations in a variety of sectors. It is important to note, however, that although malicious logins were observed this early, the first signs of impactful configuration changes from these console sessions only began to ramp up en masse between December 4, 2024 and December 7, 2024. ### Web management HTTPS activity Correlated closely in time with the jsconsole activity, we observed HTTPS web management traffic from a group of VPS hosting providers’ IP addresses. Some of these IP addresses would later proceed to establish SSL VPN tunnels to the same compromised firewalls. These HTTPS events took place tens of seconds before the jsconsole activity. There are several noteworthy aspects to this traffic: 1. Action was client-rst, which means that the client side of the TCP session has sent an RST packet to terminate the connection. 2. The amount of data sent to the destination firewall was over a megabyte in size. 3. The duration of the session was over 100 seconds. 4. The app was “Web Management(HTTPS)”. In the example below, the HTTPS management port was 8443 but this is set to 443 by default. However, it can be set arbitrarily to another value and is often different depending on the environment. 5. The traffic originated from a WAN interface. ``` date=2024-12-15 time=REDACTED devname="REDACTED" devid="REDACTED" eventtime=REDACTED tz="-0500" logid="0001000014" type="traffic" subtype="local" level="notice" vd="root" srcip=157.245.3.251 srcport=56010 srcintf="wan1" srcintfrole="wan" dstip=REDACTED dstport=8443 dstintf="root" dstintfrole="undefined" srccountry="United States" dstcountry="United States" sessionid=REDACTED proto=6 action="client-rst" policyid=0 policytype="local-in-policy" service="HTTPSMGMT" trandisp="noop" app="Web Management(HTTPS)" duration=570 sentbyte=1315775 rcvdbyte=2084318 sentpkt=18225 rcvdpkt=18092 appcat="unscanned" ``` While the technical details of the suspected vulnerability are not yet known, the characteristics outlined here for malicious web management traffic provide a glimpse into the nature of a potential exploit. ### Indications of opportunistic exploitation Typically, the total count of successful jsconsole logins from anomalous IP addresses ranged between several hundred and several thousand entries for each victim organization, spanning between November 16, 2024 and the end of December 2024. Most of these sessions were short-lived, with corresponding logout events within a second or less. In some instances, multiple login or logout events occurred within the same second, with up to 4 events occurring per second. The victimology in this campaign was not limited to any specific sectors or organization sizes. The diversity of victim organization profiles combined with the appearance of automated login/logout events suggests that the targeting was opportunistic in nature rather than being deliberately and methodically targeted. ### Phase 2: Reconnaissance In the first phase of the campaign, although there were extensive login and logout events that appeared to be automated, configuration changes were nonexistent. Then, beginning on November 22, 2024, the first unauthorized configuration changes were made: ``` date=2024-11-22 time=REDACTED devname="REDACTED" devid="REDACTED" eventtime=REDACTED tz="-0500" logid="0100044546" type="event" subtype="system" level="information" vd="root" logdesc="Attribute configured" user="admin" ui="jsconsole(1.1.1.1)" action="Edit" cfgtid=REDACTED cfgpath="system.console" cfgattr="output[more->standard]" msg="Edit system.console " date=2024-11-22 time=REDACTED devname="REDACTED" devid="REDACTED" eventtime=REDACTED tz="-0500" logid="0100044546" type="event" subtype="system" level="information" vd="root" logdesc="Attribute configured" user="admin" ui="jsconsole(1.1.1.1)" action="Edit" cfgtid=REDACTED cfgpath="system.console" cfgattr="output[standard->more]" msg="Edit system.console " ``` Similar configuration changes were made across a handful of victim organizations until November 27, 2024. The [output setting](https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-show-more-command-output-without-pressing/ta-p/193674) referenced in these logs is used to toggle whether user interaction is needed to advance to the next page of console output. The “more” setting means that interaction is required to advance long output and “standard” prints out all output at once. In all intrusions, this setting was first set to “standard” and then set to “more”, usually within 10-30 seconds of each other. The purpose of these changes is not known, but it may hint at threat actors’ preferred mode of interacting with the web console. It is also possible that this was a simple means of verifying that access was successfully obtained to commit changes on exploited firewalls. ### Phase 3: SSL VPN configuration In the third phase of the campaign, beginning on December 4, 2024, threat actors began to make more substantial changes on compromised devices, with the goal of gaining SSL VPN access. There were several distinct approaches for how to achieve this. In some intrusions, new super admin accounts were created, adhering to an alphanumeric naming convention consisting of 5 characters. In other intrusions, the naming convention was slightly different, with 6 randomized alphanumeric characters. ``` date=2024-12 time=REDACTED devname="REDACTED" devid="REDACTED" eventtime=1733554955692189638 tz="-0500" logid="0100044547" type="event" subtype="system" level="information" vd="root" logdesc="Object attribute configured" user="admin" ui="jsconsole(127.0.0.1)" action="Add" cfgtid=REDACTED cfgpath="system.admin" cfgobj="Dbr3W" cfgattr="password[*]accprofile[super_admin]vdom[root]" msg="Add system.admin Dbr3W" ``` The newly created super admin accounts were then used to create several local user accounts (up to 6 per device) with similar naming conventions, which were ultimately added to existing groups that had been previously created by victim organizations for SSL VPN access. In other intrusions, existing accounts were hijacked by threat actors to gain SSL VPN access. As with the previous scenario, these accounts were also added to existing groups with VPN access. This included use of the guest account, which is [created by default](https://community.fortinet.com/t5/FortiGate/Technical-Tip-Purpose-and-Function-of-the-Default-Guest-User/ta-p/272456) on FortiGate devices. The password on the guest account was reset to facilitate this process. Threat actors were also observed creating new SSL VPN portals which they added user accounts to directly. In addition, some threat actors assigned specific ports to their VPN portal configurations, changing them between different sessions. These ports included 4433, 59449, and 59450, among others. Upon making the necessary changes, threat actors established SSL VPN tunnels with the affected devices. All of the client IP addresses of the tunnels originated from a handful of VPS hosting providers. In most instances where firewall configuration changes were made, the ui field showed jsconsole with loopback or public DNS resolver IP addresses in parentheses (e.g., jsconsole(8.8.8.8)). However, there were several intrusions where the same field referenced other remote IP addresses, suggesting that the threat actor did not attempt to spoof their actual IP addresses in those instances. These were some of the same client IP addresses of the malicious tunnels that were later established. There were also instances where the https ui was used instead of jsconsole, and newly created accounts were used instead of the admin account for those sessions. ### Phase 4: Lateral Movement In the final phase observed in this campaign, upon successfully establishing SSL VPN access in victim organization environments, threat actors sought to extract credentials for lateral movement. DC sync was used with previously obtained domain admin credentials. The threat actors used a workstation hostname of kali. At this point, the threat actors were removed from affected environments before they could proceed any further. How Arctic Wolf Protects Its Customers -------------------------------------- Arctic Wolf is committed to ending cyber risk with its customers, and when active ransomware campaigns are identified we move quickly to protect our customers. Arctic Wolf Labs has leveraged threat intelligence around this campaign to implement new detections in the Arctic Wolf Platform to protect Managed Detection and Response (MDR) customers. As we discover any new information, we will enhance our detections to account for additional indicators of compromise and techniques leveraged by this threat actor. Remediation ----------- In December 2024, Arctic Wolf sent out a [security bulletin](https://arcticwolf.com/resources/blog/arctic-wolf-observes-targeting-of-publicly-exposed-fortinet-firewall-management-interfaces/) warning of the activity observed in this campaign. See our [follow-up security bulletin](https://arcticwolf.com/resources/blog/cve-2024-55591/) published on January 14, 2025 for additional remediation guidance, including version details. In addition to locking down management interfaces, as a security best practice, regularly upgrading the firmware on firewall devices to the latest available version is advised to protect against known security issues. Conclusion ---------- In this campaign, we observed opportunistic exploitation of a handful of victim organizations. While the final objectives of the threat actor are not known, the technical details we’ve provided should help defenders protect against the early stages of this campaign. As documented in this campaign and in [several](https://arcticwolf.com/resources/blog/arctic-wolf-labs-observes-increased-fog-and-akira-ransomware-activity-linked-to-sonicwall-ssl-vpn/) [others](https://arcticwolf.com/resources/blog/arctic-wolf-observes-threat-campaign-targeting-palo-alto-networks-firewall-devices/), management interfaces should not be exposed on the public internet, regardless of the product specifics. Instead, access to management interfaces should be limited to trusted internal users. When such interfaces are left open on the public internet, it expands the attack surface available to threat actors, opening up the potential to identify vulnerabilities that expose features that are meant to be limited to trusted administrators. From a security best practices standpoint, these types of misconfigurations should be addressed promptly to protect against not only this vulnerability, but an entire class of other potential vulnerabilities in the future. Note: On December 12, 2024, Arctic Wolf Labs notified Fortinet about the activity observed in this campaign. Confirmation was received by FortiGuard Labs PSIRT on December 17, 2024 that the activity was known and under investigation. Acknowledgements ---------------- Arctic Wolf Labs would like to acknowledge members of the Security Services team for their role in identifying this campaign. We thank Mo Sharif who identified the campaign and associated TTPs, as well as Ruben Raymundo and Trevor Daher who helped investigate the intrusions. Appendix -------- ### Tactics, Techniques, and Procedures (TTPs) * Tactic: Initial Access * Technique: T1190: Exploit Public-Facing Application * Sub-techniques or Tools: • Exploited public-facing FortiGate firewall management interfaces * Tactic: Persistence * Technique: T1136.001: Create Account: Local Account * Sub-techniques or Tools: • Created multiple local admin accounts * Tactic: T1133: External Remote Services * Technique: • Modified SSL VPN configurations * Sub-techniques or Tools: * Tactic: T1078.001: Valid Accounts: Default Accounts * Technique: • Hijacked default guest account to obtain SSL VPN access * Sub-techniques or Tools: * Tactic: Credential Access * Technique: T1003.006: OS Credential Dumping: DCSync * Sub-techniques or Tools: • The threat actors used a domain admin account to conduct a DCSync attack ### Vulnerabilities Exploited * Vulnerability: No CVE registered * Use: The activity observed in this article has not been assigned a CVE as of publication. ### Indicators of Compromise (IoCs) * Indicator: 23.27.140[.]65 * Type: IPv4 Address * Description: • AS149440 – Evoxt Enterprise• SSL VPN client IP address• Web management interface client * Indicator: 66.135.27[.]178 * Type: IPv4 Address * Description: • AS20473 – The Constant Company Llc• SSL VPN client IP address• Web management interface client * Indicator: 157.245.3[.]251 * Type: IPv4 Address * Description: • AS14061 – Digitalocean Llc• SSL VPN client IP address• Web management interface client * Indicator: 45.55.158[.]47 * Type: IPv4 Address * Description: • AS14061 – Digitalocean Llc• SSL VPN client IP address• Web management interface client * Indicator: 167.71.245[.]10 * Type: IPv4 Address * Description: • AS14061 – Digitalocean Llc• SSL VPN client IP address• Web management interface client * Indicator: 137.184.65[.]71 * Type: IPv4 Address * Description: • AS14061 – Digitalocean Llc• SSL VPN client IP address * Indicator: 155.133.4[.]175 * Type: IPv4 Address * Description: • AS62240 – Clouvider Limited• SSL VPN client IP address• Web management interface client * Indicator: 31.192.107[.]165 * Type: IPv4 Address * Description: • AS50867 – Hostkey B.V.• SSL VPN client IP address * Indicator: 37.19.196[.]65 * Type: IPv4 Address * Description: • AS212238 – Datacamp Limited• Web management interface client * Indicator: 64.190.113[.]25 * Type: IPv4 Address * Description: • AS399629 – BL Networks• Web management interface client Detection Opportunities ----------------------- As part of our Managed Detection and Response service, Arctic Wolf has detections in place for techniques described in this blog article, in addition to other techniques employed by threat actors described here. ### Firewall This campaign was identified early because external monitoring was in place for unexpected firewall configuration changes. As described in this article, jsconsole activity was observed from a handful of anomalous IP addresses that appeared to be spoofed. Monitoring for jsconsole activity from commonly spoofed IP addresses might be helpful in responding early to such attacks. The weakness of this approach is that threat actors may choose to spoof jsconsole activity using different IP addresses in the future. Additionally, although details of the vulnerability in this article are not yet available, monitoring for web management traffic on the WAN interface over 1MB originating from VPS hosting IP addresses may be a worthwhile means of detecting exploitation. This detection criteria could be further narrowed down by setting a minimum session duration of 100 seconds. Please note, however, that a better long-term approach to this detection would be to remove web management from the public internet entirely. Finally, given that malicious SSL VPN logins were known to take place with client IP addresses originating from VPS hosting providers, monitoring for unexpected logins from such providers would also potentially be worth exploring. Additional Resources -------------------- Get actionable insights and access to the security operations expertise of one of the largest security operations centers (SOCs) in the world in [Arctic Wolf’s 2024 Security Operations Report](https://arcticwolf.com/resource/security-operations-report/arctic-wolf-security-operations-report-2024). Learn what’s new, what’s changed, and what’s ahead for the cybersecurity landscape, with insights from 1,000 global IT and security leaders in the [Arctic Wolf State of Cybersecurity: 2024 Trends Report](https://arcticwolf.com/resource/aw/the-state-of-cybersecurity-2024-trends-report?lb-mode=overlay). About Arctic Wolf Labs ---------------------- [Arctic Wolf Labs](https://arcticwolf.com/labs/) is a group of elite security researchers, data scientists, and security development engineers who explore security topics to deliver cutting-edge threat research on new and emerging adversaries, develop and refine advanced threat detection models with artificial intelligence, including machine learning, and drive continuous improvement in the speed, scale, and detection efficacy of Arctic Wolf’s solution offerings. With their deep domain knowledge, Arctic Wolf Labs brings world-class security innovations to not only Arctic Wolf’s customer base, but the security community at large. Authors ------- ### Stefan Hostetler Stefan is a Lead Threat Intelligence Researcher at Arctic Wolf. With over a decade of industry experience under his belt, he focuses on extracting actionable insight from novel threats to help organizations protect themselves effectively. ### Julian Tuin Julian is a Senior Threat Intelligence Researcher at Arctic Wolf Labs with more than 6 years of industry experience. He has experience in identifying and tracking campaigns for new and emerging threats. ### Trevor Daher Trevor Daher is a Technical Lead within Arctic Wolf’s Security Services group supporting the Managed Detection and Response (MDR) service. ### Jon Grimm Jon is a Threat Intelligence Analyst at Arctic Wolf dedicated to identifying new cyber threats and producing actionable intelligence that enhances organizational defenses. He has background of 10 years’ experience in several domains of cybersecurity, holds a bachelor’s degree in law enforcement, and holds several industry certifications (CISSP, GCFA, GCTI). ### Alyssa Newbury Alyssa Newbury is a Threat Intelligence Analyst at Arctic Wolf, with over a decade of experience in tactical threat intelligence and cybersecurity. She has background working for various agencies within the intelligence community, including the FBI and NGA, and focuses primarily on researching and identifying emerging cyber threats and producing impactful finished intelligence products. ### Joe Wedderspoon Joe Wedderspoon is a Sr. Forensic Analyst at Arctic Wolf Incident Response, focused on leading complex incident response and digital forensic investigations. He holds multiple certifications and has over 7 years of operational experience in incident response, defensive cyber operations, and researching adversary tradecraft in both the public and private sectors. ### Markus Neis Markus Neis is a Principal Threat Intelligence Researcher in Arctic Wolf Labs focused on leading advanced threat research. He has more than a decade of experience in researching adversary tradecraft and responding to sophisticated attacks.

HP Universal Print Driver Series (PCL 6 and PostScript) - Potential Security Vulnerabilities

2025-02-22T13:57:14.050260+00:00

| CVE | CVSS | Level | CVSS String | library | | | ----------------------------------------------------------------- | --- | -------- | ----------------------------------------------- | ------- | ------------------------ | | [CVE-2017-12652](https://nvd.nist.gov/vuln/detail/CVE-2017-12652) | 9.8 | Critical | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | libpng | Arbitrary Code Execution | | [CVE-2022-2068](https://nvd.nist.gov/vuln/detail/CVE-2022-2068) | 9.8 | Critical | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | OpenSSL | Arbitrary Code Execution | | [CVE-2023-45853](https://nvd.nist.gov/vuln/detail/CVE-2023-45853) | 9.8 | Critical | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | zlib | Information Disclosure | | [CVE-2020-14152](https://nvd.nist.gov/vuln/detail/CVE-2020-14152) | 7.1 | High | CVSS:3.1/AF4AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:H | libjpeg | Denial of Service | # Resolution Update your version of the HP Universal Print Driver Series. HP has provided updates to the HP Universal Print Driver Series. To obtain the updated version, go to www.hp.com/go/UPD. [https://support.hp.com/us-en/document/ish_11892982-11893015-16/hpsbpi03995](https://support.hp.com/us-en/document/ish_11892982-11893015-16/hpsbpi03995)