Another day, another edge device being targeted - it’s a typical Thursday!

In today’s blog post, we’re excited to share our previously private analysis of the now exploited in-the-wild N-day vulnerabilities affecting SonicWall’s SMA100 appliance. Over the last few months, our client base has fed us rumours of in-the-wild exploitation of SonicWall systems, and thus, this topic has had our attention for a while.

Specifically, today, we’re going to be analyzing and reproducing:

CVE-2024-38475 - Apache HTTP Pre-Authentication Arbitrary File Read
Discovered by Orange Tsai
Although this is a CVE attached to the Apache HTTP Server, it is important to note that due to how CVEs are now assigned, a seperate CVE will not be assigned for SonicWall's usage of the vulnerable version.
This makes the situation confusing for those responding to CISA's KEV listing - CISA is referring to the two vulnerabilities in combination being used to attack SonicWall devices.
You can see this evidenced in SonicWall's updated PSIRT advisory: https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2024-0018

CVE-2023-44221 - Post-Authentication Command Injection
Discovered by "Wenjie Zhong (H4lo) Webin lab of DBappSecurity Co., Ltd”
As of the day this research was published, CISA had added these vulnerabilities to the Known Exploited Vulnerabilities list.

Do you know the fun things about these posts? We can copy text from previous posts about edge devices:

We've previously, publicly and privately, analysed vulnerabilities in various ‘Backup and Replication’ platforms, including those offered by Veeam and NAKIVO - both of which have struggled to avoid scrutiny and in some cases, even opting to patch issues silently.

However, we’re glad to see that sense prevails - kudos to NAKIVO for acknowledging CVE-2024-48248 from our previous research and publicly responding to a new XXE vulnerability (CVE-2025-32406).

Backup and Replication solutions have become prime targets for ransomware operators for logical reasons — Veeam, for instance, has already seen widespread exploitation in the wild.

The TL;DR is that this time, we ended up discovering ~150 Amazon S3 buckets that had previously been used across commercial and open source software products, governments, and infrastructure deployment/update pipelines - and then abandoned.

Naturally, we registered them, just to see what would happen - “how many people are really trying to request software updates from S3 buckets that appear to have been abandoned months or even years ago?”, we naively thought to ourselves.

After the excitement of our .MOBI research, we were left twiddling our thumbs. As you may recall, in 2024, we demonstrated the impact of an unregistered domain when we subverted the TLS/SSL CA process for verifying domain ownership to give ourselves the ability to issue valid and trusted TLS/

We agree - modern security engineering is hard - but none of this is modern. We are discussing vulnerability classes - with no sophisticated trigger mechanisms that fuzzing couldnt find - discovered in the 1990s, that can be trivially discovered via basic fuzzing, SAST (the things product security teams do with real code access).

As an industry, should we really be communicating that these vulnerability classes are simply too complex for a multi-billion dollar technology company that builds enterprise-grade, enterprise-priced network security solutions to proactively resolve?

This is a pair of vulnerabilities, described as ‘Authentication Bypass in the Management Web Interface’ and a ‘Privilege Escalation‘ respectively, strongly suggesting they are used as a chain to gain superuser access, a pattern that we’ve seen before with Palo Alto appliances. Before we’ve even dived into to code, we’ve already ascertained that we’re looking for a chain of vulnerabilities to achieve that coveted pre-authenticated Remote Code Execution.

This one is a privesc bug yielding SYSTEM privileges for any VDI user, which is actually a lot worse than it might initially sound since that’s SYSTEM privileges on the server that hosts all the applications and access is ‘by design’ - allowing an attacker to impersonate any user (including administrators) and monitor behaviour, connectivity.

It affected (before patching) all currently-maintained branches, and recently was highlighted by CISA as being exploited-in-the-wild.

This must be the first time real-world attackers have reversed a patch, and reproduced a vulnerability, before some dastardly researchers released a detection artefact generator tool of their own. /s

At watchTowr's core, we're all about identifying and validating ways into organisations - sometimes through vulnerabilities in network border appliances - without requiring such luxuries as credentials or asset lists.

We recently performed research that started off "well-intentioned" (or as well-intentioned as we ever are) - to make vulnerabilities in WHOIS clients and how they parse responses from WHOIS servers exploitable in the real world (i.e. without needing to MITM etc).

As part of our research, we discovered that a few years ago the WHOIS server for the .MOBI TLD migrated from whois.dotmobiregistry.net to whois.nic.mobi – and the dotmobiregistry.net domain had been left to expire seemingly in December 2023.

Every sysadmin is familiar with Veeam’s enterprise-oriented backup solution, ‘Veeam Backup & Replication’. Unfortunately, so is every ransomware operator, given it's somewhat 'privileged position' in the storage world of most enterprise's networks. There's no point deploying cryptolocker malware on a target unless you can also deny access to backups, and so, this class of attackers absolutely loves to break this particular software.
With so many eyes focussed on it, then, it is no huge surprise that it has a rich history of CVEs. Today, we're going to look at the latest episode - CVE-2024-40711.
Well, that was a complex vulnerability, requiring a lot of code-reading! We’ve successfully shown how multiple bugs can be chained together to gain RCE in a variety of versions of Veeam Backup & Replication.

Orange Tsai tweeted a few hours ago about “One of [his] PHP vulnerabilities, which affects XAMPP by default”, and we were curious to say the least. XAMPP is a very popular way for administrators and developers to rapidly deploy Apache, PHP, and a bunch of other tools, and any bug

Gather round, gather round - it’s time for another blogpost tearing open an SSLVPN appliance and laying bare a recent in-the-wild exploited bug. This time, it is Check Point who is the focus of our penetrative gaze.

Check Point, for those unaware, is the vendor responsible for the 'CloudGuard Network Security' appliance, yet another device claiming to be secure and hardened. Their slogan - "you deserve the best security" - implies they are a company you can trust with the security of your network. A bold claim.

Infosec is, at it’s heart, all about that data. Obtaining access to it (or disrupting access to it) is in every ransomware gang and APT group’s top-10 to-do-list items, and so it makes sense that our research voyage would, at some point, cross paths with products intended to manage - and safeguard - this precious resource.

Welcome to April 2024, again. We’re back, again.

Over the weekend, we were all greeted by now-familiar news—a nation-state was exploiting a “sophisticated” vulnerability for full compromise in yet another enterprise-grade SSLVPN device.

We’ve seen all the commentary around the certification process of these devices for certain .GOVs - we’re not here to comment on that, but sounds humorous.