This Week in Security: Encrypted Messaging, NSO’s Judgement, and AI CVE DDoS

Cryptographic messaging has been in the news a lot recently. Like the formal audit of WhatsApp (the actual PDF). And the results are good. There are some minor potential problems …read more

May 9, 2025 - 15:11

This Week in Security: Encrypted Messaging, NSO’s Judgement, and AI CVE DDoS

Cryptographic messaging has been in the news a lot recently. Like the formal audit of WhatsApp (the actual PDF). And the results are good. There are some minor potential problems that the audit highlights, but they are of questionable real-world impact. The most consequential is how easy it is to add additional members to a group chat. Or to put it another way, there are no cryptographic guarantees associated with adding a new user to a group.

The good news is that WhatsApp groups don’t allow new members to read previous messages. So a user getting added to a group doesn’t reveal historic messages. But a user added without being noticed can snoop on future messages. There’s an obvious question, as to how this is a weakness. Isn’t it redundant, since anyone with the permission to add someone to a group, can already read the messages from that group?

That’s where the lack of cryptography comes in. To put it simply, the WhatsApp servers could add users to groups, even if none of the existing users actually requested the addition. It’s not a vulnerability per se, but definitely a design choice to keep in mind. Keep an eye on the members in your groups, just in case.

The Signal We Have at Home

The TeleMessage app has been pulled from availability, after it was used to compromise Signal communications of US government officials. There’s political hay to be made out of the current administration’s use and potential misuse of Signal, but the political angle isn’t what we’re here for. The TeleMessage client is Signal compatible, but adds message archiving features. Government officials and financial companies were using this alternative client, likely in order to comply with message retention laws.

While it’s possible to do long term message retention securely, TeleMessage was not doing this particularly well. The messages are stripped of their end-to-end encryption in the client, before being sent to the archiving server. It’s not clear exactly how, but those messages were accessed by a hacker. This nicely demonstrates the inherent tension between the need for transparent archiving as required by the US government for internal communications, and the need for end-to-end encryption.

The NSO Judgement

WhatsApp is in the news for another reason, this time winning a legal judgement against NSO Group for their Pegasus spyware. The $167 Million in damages casts real doubt on the idea that NSO has immunity to develop and deploy malware, simply because it’s doing so for governments. This case is likely to be appealed, and higher courts may have a different opinion on this key legal question, so hold on. Regardless, the era of NSO’s nearly unrestricted actions is probably over. They aren’t the only group operating in this grey legal space, and the other “legal” spyware/malware vendors are sure to be paying attention to this ruling as well.

The $5 Wrench

In reality, the weak point of any cryptography scheme is the humans using it. We’re beginning to see real world re-enactments of the famous XKCD $5 wrench, that can defeat even 4096-bit RSA encryption. In this case, it’s the application of old crime techniques to new technology like cryptocurrency. To quote Ars Technica:

We have reached the “severed fingers and abductions” stage of the crypto revolution

The flashy stories involve kidnapping and torture, but let’s not forget that the most common low-tech approach is simple deception. Whether you call it the art of the con, or social engineering, this is still the most likely way to lose your savings, whether it’s conventional or a cryptocurrency.

The SonicWall N-day

WatchTowr is back with yet another reverse-engineered vulnerability. More precisely, it’s two CVEs that are being chained together to achieve pre-auth Remote Code Execution (RCE) on SonicWall appliances. This exploit chain has been patched, but not everyone has updated, and the vulnerabilities are being exploited in the wild.

The first vulnerability at play is actually from last year, and is in Apache’s mod_rewrite module. This module is widely used to map URLs to source files, and it has a filename confusion issue where a url-encoded question mark in the path can break the mapping to the final filesystem path. A second issue is that when DocumentRoot is specified, instances of RewriteRule take on a weird dual-meaning. The filesystem target refers to the location inside DocumentRoot, but it first checks for that location in the filesystem root itself. This was fixed in Apache nearly a year ago, but it takes time for patches to roll out.

SonicWall was using a rewrite rule to serve CSS files, and the regex used to match those files is just flexible enough to be abused for arbitrary file read. /mnt/ram/var/log/httpd.log%3f.1.1.1.1a-1.css matches that rule, but includes the url-encoded question mark, and matches a location on the root filesystem. There are other, more interesting files to access, like the temp.db SQLite database, which contains session keys for the currently logged in users.

The other half of this attack is a really clever command injection using one of the diagnostic tools included in the SonicWall interface. Traceroute6 is straightforward, running a traceroute6 command and returning the results. It’s also got good data sanitization, blocking all of the easy ways to break out of the traceroute command and execute some arbitrary code. The weakness is that while this sanitization adds backslashes to escape quotes and other special symbols, it stores the result in a fixed-length result buffer. If the result of this escaping process overflows the result buffer, it writes over the null terminator and into the buffer that holds the original command before it’s sanitized. This overflow is repeated when the command is run, and with some careful crafting, this results in escaping the sanitization and including arbitrary commands. Clever.

The AI CVE DDoS

[Daniel Stenberg], lead developer of curl, is putting his foot down. We’ve talked about this before, even chatting with Daniel about the issue when we had him on FLOSS Weekly. Curl’s bug bounty project has attracted quite a few ambitious people, that don’t actually have the skills to find vulnerabilities in the curl codebase. Instead, these amateur security researchers are using LLMs to “find vulnerabilities”. Spoiler, LLMs aren’t yet capable of this task. But LLMs are capable of writing fake vulnerability reports that look very convincing at first read. The game is usually revealed when the project asks a question, and the fake researcher feeds the LLM response back into the bug report.

This trend hasn’t slowed, and the curl project is now viewing the AI generated vulnerability reports as a form of DDoS. In response, the curl Hackerone bounty program will soon ask a question with every entry: “Did you use an AI to find the problem or generate this submission?” An affirmative answer won’t automatically disqualify the report, but it definitely puts the burden on the reporter to demonstrate that the flaw is real and wasn’t hallucinated. Additionally, “AI slop” reports will result in permanent bans for the reporter.

It’s good to see that not all AI content is completely disallowed, as it’s very likely that LLMs will be involved in finding and describing vulnerabilities before long. Just not in this naive way, where a single prompt results in a vulnerability find and generates a patch that doesn’t even apply. Ironically, one of the tells of an AI generated report is that it’s too perfect, particularly for someone’s first report. AI is still the hot new thing, so this issue likely isn’t going away any time soon.

Bits and Bytes

A supply chain attack has been triggered against several hundred Magento e-commerce sites, via at least three software vendors distributing malicious code. One of the very odd elements to this story is that it appears this malicious code has been incubating for six years, and only recently invoked for malicious behavior.

On the WordPress side of the fence, the Ottokit plugin was updated last month to fix a critical vulnerability. That update was force pushed to the majority of WordPress sites running that plugin, but that hasn’t stopped threat actors from attempting to use the exploit, with the first attempts coming just an hour and a half after disclosure.

It turns out it’s probably not a great idea to allow control codes as part of file names. Portswigger has a report of a couple ways VS Code can do the wrong thing with such filenames.

And finally, this story comes with a disclaimer: Your author is part of Meshtastic Solutions and the Meshtastic project. We’ve talked about Meshtastic a few times here on Hackaday, and would be remiss not to point out CVE-2025-24797. This buffer overflow could theoretically result in RCE on the node itself. I’ve seen at least one suggestion that this is a wormable vulnerability, which may be technically true, but seems quite impractical in practice. Upgrade your nodes to at least release 2.6.2 to get the fix.