Vista Normal

Hay nuevos artículos disponibles. Pincha para refrescar la página.
Hoy — 9 Mayo 2025Salida Principal

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

9 Mayo 2025 at 14:00

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.

AnteayerSalida Principal

This Week in Security: AirBorne, EvilNotify, and Revoked RDP

2 Mayo 2025 at 14:00

This week, Oligo has announced the AirBorne series of vulnerabilities in the Apple Airdrop protocol and SDK. This is a particularly serious set of issues, and notably affects MacOS desktops and laptops, the iOS and iPadOS mobile devices, and many IoT devices that use the Apple SDK to provide AirPlay support. It’s a group of 16 CVEs based on 23 total reported issues, with the ramifications ranging from an authentication bypass, to local file reads, all the way to Remote Code Execution (RCE).

AirPlay is a WiFi based peer-to-peer protocol, used to share or stream media between devices. It uses port 7000, and a custom protocol that has elements of both HTTP and RTSP. This scheme makes heavy use of property lists (“plists”) for transferring serialized information. And as we well know, serialization and data parsing interfaces are great places to look for vulnerabilities. Oligo provides an example, where a plist is expected to contain a dictionary object, but was actually constructed with a simple string. De-serializing that plist results in a malformed dictionary, and attempting to access it will crash the process.

Another demo is using AirPlay to achieve an arbitrary memory write against a MacOS device. Because it’s such a powerful primative, this can be used for zero-click exploitation, though the actual demo uses the music app, and launches with a user click. Prior to the patch, this affected any MacOS device with AirPlay enabled, and set to either “Anyone on the same network” or “Everyone”. Because of the zero-click nature, this could be made into a wormable exploit.

Apple has released updates for their products for all of the CVEs, but what’s going to really take a long time to clean up is the IoT devices that were build with the vulnerable SDK. It’s likely that many of those devices will never receive updates.

EvilNotify

It’s apparently the week for Apple exploits, because here’s another one, this time from [Guilherme Rambo]. Apple has built multiple systems for doing Inter Process Communications (IPC), but the simplest is the Darwin Notification API. It’s part of the shared code that runs on all of Apple’s OSs, and this IPC has some quirks. Namely, there’s no verification system, and no restrictions on which processes can send or receive messages.

That led our researcher to ask what you may be asking: does this lack of authentication allow for any security violations? Among many novel notifications this technique can spoof, there’s one that’s particularly problematic: The device “restore in progress”. This locks the device, leaving only a reboot option. Annoying, but not a permanent problem.

The really nasty version of this trick is to put the code triggering a “restore in progress” message inside an app’s widget extension. iOS loads those automatically at boot, making for an infuriating bootloop. [Guilherme] reported the problem to Apple, made a very nice $17,500 in the progress. The fix from Apple is a welcome surprise, in that they added an authorization mechanism for sensitive notification endpoints. It’s very likely that there are other ways that this technique could have been abused, so the more comprehensive fix was the way to go.

Jenkins

Continuous Integration is one of the most powerful tools a software project can use to stay on top of code quality. Unfortunately as those CI toolchains get more complicated, they are more likely to be vulnerable, as [John Stawinski] from Praetorian has discovered. This attack chain would target the Node.js repository at Github via an outside pull request, and ends with code execution on the Jenkins host machines.

The trick to pulling this off is to spoof the timestamp on a Pull Request. The Node.js CI uses PR labels to control what CI will do with the incoming request. Tooling automatically adds the “needs-ci” label depending on what files are modified. A maintainer reviews the PR, and approves the CI run. A Jenkins runner will pick up the job, compare that the Git timestamp predated the maintainer’s approval, and then runs the CI job. Git timestamps are trivial to spoof, so it’s possible to load an additional commit to the target PR with a commit timestamp in the past. The runner doesn’t catch the deception, and runs the now-malicious code.

[John] reported the findings, and Node.js maintainers jumped into action right away. The primary fix was to do SHA sum comparisons to validate Jenkins runs, rather than just relying on timestamp. Out of an abundance of caution, the Jenkins runners were re-imaged, and then [John] was invited to try to recreate the exploit. The Node.js blog post has some additional thoughts on this exploit, like pointing out that it’s a Time-of-Check-Time-of-Use (TOCTOU) exploit. We don’t normally think of TOCTOU bugs where a human is the “check” part of the equation.

2024 in 0-days

Google has published an overview of the 75 zero-day vulnerabilities that were exploited in 2024. That’s down from the 98 vulnerabilities exploited in 2023, but the Threat Intelligence Group behind this report are of the opinion that we’re still on an upward trend for zero-day exploitation. Some platforms like mobile and web browsers have seen drastic improvements in zero-day prevention, while enterprise targets are on the rise. The real stand-out is the targeting of security appliances and other network devices, at more than 60% of the vulnerabilities tracked.

When it comes to the attackers behind exploitation, it’s a mix between state-sponsored attacks, legal commercial surveillance, and financially motivated attacks. It will be interesting to see how 2025 stacks up in comparison. But one thing is for certain: Zero-days aren’t going away any time soon.

Perplexing Passwords for RDP

The world of computer security just got an interesting surprise, as Microsoft declared it not-a-bug that Windows machines will continue to accept revoked credentials for Remote Desktop Protocol (RDP) logins. [Daniel Wade] discovered the issue and reported it to Microsoft, and then after being told it wasn’t a security vulnerability, shared his report with Ars Technica.

So what exactly is happening here? It’s the case of a Windows machine login via Azure or a Microsoft account. That account is used to enable RDP, and the machine caches the username and password so logins work even when the computer is “offline”. The problem really comes in how those cached passwords get evicted from the cache. When it comes to RDP logins, it seems they are simply never removed.

There is a stark disconnect between what [Wade] has observed, and what Microsoft has to say about it. It’s long been known that Windows machines will cache passwords, but that cache will get updated the next time the machine logs in to the domain controller. This is what Microsoft’s responses seem to be referencing. The actual report is that in the case of RDP, the cached passwords will never expire, regardless of changing that password in the cloud and logging on to the machine repeatedly.

Bits and Bytes

Samsung makes a digital signage line, powered by the MagicINFO server application. That server has an unauthenticated endpoint, accepting file uploads with insufficient filename sanitization. That combination leads to arbitrary pre-auth code execution. While that’s not great, what makes this a real problem is that the report was first sent to Samsung in January, no response was ever received, and it seems that no fixes have officially been published.

A series of Viasat modems have a buffer overflow in their SNORE web interface. This leads to unauthenticated, arbitrary code execution on the system, from either the LAN or OTA interface, but thankfully not from the public Internet itself. This one is interesting in that it was found via static code analysis.

IPv6 is the answer to all of our IPv4 induced woes, right? It has Stateless Address Autoconfiguration (SLAAC) to handle IP addressing without DHCP, and Router Advertisement (RA) to discover how to route packets. And now, taking advantage of that great functionality is Spellbinder, a malicious tool to pull off SLACC attacks and do DNS poisoning. It’s not entirely new, as we’ve seen Man in the Middle attacks on IPv4 networks for years. IPv6 just makes it so much easier.

This Week in Security: XRP Poisoned, MCP Bypassed, and More

25 Abril 2025 at 14:00

Researchers at Aikido run the Aikido Intel system, an LLM security monitor that ingests the feeds from public package repositories, and looks for anything unusual. In this case, the unusual activity was five rapid-fire releases of the xrpl package on NPM. That package is the XRP Ledger SDK from Ripple, used to manage keys and build crypto wallets. While quick point releases happen to the best of developers, these were odd, in that there were no matching releases in the source GitHub repository. What changed in the first of those fresh releases?

The most obvious change is the checkValidityOfSeed() function added to index.ts. That function takes a string, and sends a request to a rather odd URL, using the supplied string as the ad-referral header for the HTML request. The name of the function is intended to blend in, but knowing that the string parameter is sent to a remote web server is terrifying. The seed is usually the root of trust for an individual’s cryptocurrency wallet. Looking at the actual usage of the function confirms, that this code is stealing credentials and keys.

The releases were made by a Ripple developer’s account. It’s not clear exactly how the attack happened, though credential compromise of some sort is the most likely explanation. Each of those five releases added another bit of malicious code, demonstrating that there was someone with hands on keyboard, watching what data was coming in.

The good news is that the malicious releases only managed a total of 452 downloads for the few hours they were available. A legitimate update to the library, version 4.2.5, has been released. If you’re one of the unfortunate 452 downloads, it’s time to do an audit, and rotate the possibly affected keys.

Zyxel FLEX

More specifically, we’re talking about Zyxel’s USG FLEX H series of firewall/routers. This is Zyxel’s new Arm64 platform, running a Linux system they call Zyxel uOS. This series is for even higher data throughput, and given that it’s a new platform, there are some interesting security bugs to find, as discovered by [Marco Ivaldi] of hn Security and [Alessandro Sgreccia] at 0xdeadc0de. Together they discovered an exploit chain that allows an authenticated user with VPN access only to perform a complete device takeover, with root shell access.

The first bug is a wild one, and is definitely something for us Linux sysadmins to be aware of. How do you handle a user on a Linux system, that you don’t want to have SSH access to the system shell? I’ve faced this problem when a customer needed SFTP access to a web site, but definitely didn’t need to run bash commands on the server. The solution is to set the user’s shell to nologin, so when SSH connects and runs the shell, it prints a message, and ends the shell, terminating the SSH connection. Based on the code snippet, the FLEX is doing something similar, perhaps with -false set as the shell instead:

$ ssh user@192.168.169.1
(user@192.168.169.1) Password:
-false: unknown program '-false'
Try '-false --help' for more information.
Connection to 192.168.169.1 closed.

It’s slightly janky, but seems set up correctly, right? There’s one more step to do this completely: Add a Match entry to sshd_config, and disable some of the other SSH features you may not have thought about, like X11 forwarding, and TCP forwarding. This is the part that Zyxel forgot about. VPN-only users can successfully connect over SSH, and the connection terminates right away with the invalid shell, but in that brief moment, TCP traffic forwarding is enabled. This is an unintended security domain transverse, as it allows the SSH user to redirect traffic into internal-only ports.

Next question to ask, is there any service running inside the appliance that provides a pivot point? How about PostgreSQL? This service is set up to allow local connections on port 5432 — without a password. And PostgreSQL has a wonderful feature, allowing a COPY FROM command to specify a function to run using the system shell. It’s essentially arbitrary shell execution as a feature, but limited to the PostgreSQL user. It’s easy enough to launch a reverse shell to have ongoing shell access, but still limited to the PostgreSQL user account.

There are a couple directions exploitation can go from there. The /tmp/webcgi.log file is accessible, which allows for grabbing an access token from a logged-in admin. But there’s an even better approach, in that the unprivileged user can use the system’s Recovery Manager to download system settings, repack the resulting zip with a custom binary, re-upload the zip using Recovery Manager, and then interact with the uploaded files. A clever trick is to compile a custom binary that uses the setuid(0) system call, and because Recovery Manager writes it out as root, with the setuid bit set, it allows any user to execute it and jump straight to root. Impressive.

Power Glitching an STM32

Micro-controllers have a bit of a weird set of conflicting requirements. They need to be easily flashed, and easily debugged for development work. But once deployed, those same chips often need to be hardened against reading flash and memory contents. Chips like the STM32 series from ST Microelectronics have multiple settings to keep chip contents secure. And Anvil Secure has some research on how some of those protections could be defeated. Power Glitching.

The basic explanation is that these chips are only guaranteed to work when run inside their specified operating conditions. If the supply voltage is too low, be prepared for unforeseen consequences. Anvil tried this, and memory reads were indeed garbled. This is promising, as the memory protection settings are read from system memory during the boot process. In fact, one of the hardest challenges to this hack was determining the exact timing needed to glitch the right memory read. Once that was nailed down, it took about 6 hours of attempts and troubleshooting to actually put the embedded system into a state where firmware could be extracted.

MCP Line Jumping

Trail of Bits is starting a series on MCP security. This has echoes of the latest FLOSS Weekly episode, talking about agentic AI and how Model Context Protocol (MCP) is giving LLMs access to tools to interact with the outside world. The security issue covered in this first entry is Line Jumping, also known as tool poisoning.

It all boils down to the fact that MCPs advertise the tools that they make available. When an LLM client connects to that MCP, it ingests that description, to know how to use the tool. That description is an opportunity for prompt injection, one of the outstanding problems with LLMs.

Bits and Bytes

Korean SK Telecom has been hacked, though not much information is available yet. One of the notable statements is that SK Telecom is offering customers a free SIM swapping protection service, which implies that a customer database was captured, that could be used for SIM swapping attacks.

WatchTowr is back with a simple pre-auth RCE in Commvault using a malicious zip upload. It’s a familiar story, where an unauthenticated endpoint can trigger a file download from a remote server, and file traversal bugs allow unzipping it in an arbitrary location. Easy win.

SSD Disclosure has discovered a pair of Use After Free bugs in Google Chrome, and Chrome’s Miracleptr prevents them from becoming actual exploits. That technology is a object reference count, and “quarantining” deleted objects that still show active references. And for these particular bugs, it worked to prevent exploitation.

And finally, [Rohan] believes there’s an argument to be made, that the simplicity of ChaCha20 makes it a better choice as a symmetric encryption primitive than the venerable AES. Both are very well understood and vetted encryption standards, and ChaCha20 even manages to do it with better performance and efficiency. Is it time to hang up AES and embrace ChaCha20?

This Week in Security: No More CVEs, 4chan, and Recall Returns

18 Abril 2025 at 14:00

The sky is falling. Or more specifically, it was about to fall, according to the security community this week. The MITRE Corporation came within a hair’s breadth of running out of its contract to maintain the CVE database. And admittedly, it would be a bad thing if we suddenly lost updates to the central CVE database. What’s particularly interesting is how we knew about this possibility at all. An April 15 letter sent to the CVE board warned that the specific contract that funds MITRE’s CVE and CWE work was due to expire on the 16th. This was not an official release, and it’s not clear exactly how this document was leaked.

Many people made political hay out of the apparent imminent carnage. And while there’s always an element of political maneuvering when it comes to contract renewal, it’s worth noting that it’s not unheard of for MITRE’s CVE funding to go down to the wire like this. We don’t know how many times we’ve been in this position in years past. Regardless, MITRE has spun out another non-profit, The CVE Foundation, specifically to see to the continuation of the CVE database. And at the last possible moment, CISA has announced that it has invoked an option in the existing contract, funding MITRE’s CVE work for another 11 months.

Android Automatic Reboots

Mobile devices are in their most secure state right after boot, before the user password is entered to unlock the device for the first time. Tools like Cellebrite will often work once a device has been unlocked once, but just can’t exploit a device in the first booted state. This is why Google is rolling out a feature, where Android devices that haven’t been unlocked for three days will automatically reboot.

Once a phone is unlocked, the encryption keys are stored in memory, and it only takes a lock screen bypass to have full access to the device. But before the initial unlock, the device is still encrypted, and the keys are safely stored in the hardware security module. It’s interesting that this new feature isn’t delivered as an Android OS update, but as part of the Google Play Services — the closed source libraries that run on official Android phones.

4chan

4chan has been hacked. It turns out, running ancient PHP code and out-of-date libraries on a controversial site is not a great idea. A likely exploit chain has been described, though this should be considered very unofficial at this point: Some 4chan boards allow PDF uploads, but the server didn’t properly vet those files. A PostScript file can be uploaded instead of a PDF, and an old version of Ghostscript processes it. The malicious PostScript file triggers arbitrary code execution in Ghostscript, and a SUID binary is used to elevate privileges to root.

PHP source code of the site has been leaked, and the site is still down as of the time of writing. It’s unclear how long restoration will take. Part of the fallout from this attack is the capture and release of internal discussions, pictures of the administrative tools, and even email addresses from the site’s administration.

Recall is Back

Microsoft is back at it, working to release Recall in a future Windows 11 update. You may remember our coverage of this, castigating the security failings, and pointing out that Recall managed to come across as creepy. Microsoft wisely pulled the project before rolling it out as a full release.

If you’re not familiar with the Recall concept, it’s the automated screenshotting of your Windows machine every few seconds. The screenshots are then locally indexed with an LLM, allowing for future queries to be run against the data. And once the early reviewers got over the creepy factor, it turns out that’s genuinely useful sometimes.

On top of the security hardening Microsoft has already done, this iteration of Recall is an opt-in service, with an easy pause button to temporarily disable the snapshot captures. This is definitely an improvement. Critics are still sounding the alarm, but for a much narrower problem: Recall’s snapshots will automatically extract information from security focused applications. Think about Signal’s disappearing messages feature. If you send such a message to a desktop user, that has Recall enabled, the message is likely stored in that user’s Recall database.

It seems that Microsoft has done a reasonably good job of cleaning up the Recall feature, particularly by disabling it by default. It seems like the privacy issues could be furthered addressed by giving applications and even web pages a way to opt out of Recall captures, so private messages and data aren’t accidentally captured. As Recall rolls out, do keep in mind the potential extra risks.

16,000 Symlinks

It’s been recently discovered that over 16,000 Fortinet devices are compromised with a trivial backdoor, in the form of a symlink making the root filesystem available inside the web-accessible language folder. This technique is limited to devices that have the SSL VPN enabled. That system exposes a web interface, with multiple translation options. Those translation files live in a world-accessible folder on the web interface, and it makes for the perfect place to hide a backdoor like this one. It’s not a new attack, and Fortinet believes the exploited devices have harbored this backdoor since the 2023-2024 hacking spree.

Vibes

We’re a little skeptical on the whole vibe coding thing. Our own [Tyler August] covered one of the reasons why. LLMs are likely to hallucinate package names, and vibe coders may not check closely, leading to easy typosquatting (LLMsquatting?) attacks. Figure out the likely hallucinated names, register those packages, and profit.

But what about Vibe Detections? OK, we know, letting an LLM look at system logs for potentially malicious behavior isn’t a new idea. But [Claudio Contin] demonstrates just how easy it can be, with the new EDV tool. Formally not for production use, this new gadget makes it easy to take Windows system events, and feed them into Copilot, looking for potentially malicious activity. And while it’s not perfect, it did manage to detect about 40% of the malicious tests that Windows Defender missed. It seems like LLMs are going to stick around, and this might be one of the places they actually make sense.

Bits and Bytes

Apple has pushed updates to their entire line, fixing a pair of 0-day vulnerabilities. The first is a wild vulnerability in CoreAudio, in that playing audio from a malicious audio file can lead to arbitrary code execution. The chaser is the flaw in the Pointer Authentication scheme, that Apple uses to prevent memory-related vulnerabilities. Apple has acknowledged that these flaws were used in the wild, but no further details have been released.

The Gnome desktop has an interesting problem, where the yelp help browser can be tricked into reading the contents of arbitrary filesystem files. Combined with the possibility of browser links automatically opening in yelp, this makes for a much more severe problem than one might initially think.

And for those of us following along with Google Project Zero’s deep dive into the Windows Registry, part six of that series is now available. This installment dives into actual memory structures, as well as letting us in on the history of why the Windows registry is called the hive and uses the 0xBEE0BEE0 signature. It’s bee themed, because one developer hated bees, and another developer thought it would be hilarious.

This Week in Security: AI Spam, SAP, and Ivanti

11 Abril 2025 at 14:00

AI continues to be used in new and exciting ways… like generating spam messages. Yes, it was inevitable, but we now have spammers using LLM to generate unique messages that don’t register as spam. AkiraBot is a Python-powered tool, designed to evade CAPTCHAs, and post sketchy SEO advertisements to web forms and chat boxes around the Internet.

AkiraBot uses a bunch of techniques to look like a legitimate browser, trying to avoid triggering CAPTCHAs. It also runs traffic through a SmartProxy service to spread the apparent source IP around. Some captured logs indicate that of over 400,000 attempted victim sites, 80,000 have successfully been spammed.

SSRF Attacking AWS

March brought a spike in instances of an interesting EC2 attack. F5 labs has the details, and it’s really pretty simple. Someone is sending requests ending in /?url=hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/, with the hope that the site is vulnerable to a Server Side Request Forgery (SSRF).

That IP address is an interesting one. It’s the location where Amazon EC2 makes the Instance Metadata Service available (IMDSv1). Version 1 of this service completely lacks authentication, so a successful SSRF can expose whatever information that service makes available. And that can include AWS credentials and other important information. The easiest fix is to upgrade the instance to IMDSv2, which does have all the authentication features you’d expect.

SAP and setuid

Up next is this Anvil Secure report from [Tao Sauvage], about finding vulnerable setuid binaries in the SAP Linux images.

Setuid is a slightly outdated way to allow a less-privileged user to run a binary with elevated privileges. The simplest example is ping, which needs raw socket access to send special ICMP packets. The binary is launched by the user, escalates its privileges to send the packet, and then terminates without actually breaking the security barrier. At least that’s what is supposed to happen. In reality, setuid binaries are a consistent source of privilege escalation problems on Linux. So much so, that it’s now preferred to use the capabilities functionality to achieve this. But that’s fairly new, and many distros just give binaries like ping the setuid bit.

This brings us to SAP’s Linux images, like SAP HANA Express. These images include a small collection of custom setuid binaries, with icmbnd and hostexecstart catching our researcher’s eyes. icmbnd notably has the -f flag to specify the output file for a debug trace. That’s a typical setuid problem, in that a user can specify an oddball location, and the binary will change the system’s state in unexpected ways. It’s an easy denial of service attack, but is there a way to actually get root? It turns out the the Linux /etc/passwd file is particularly resilient. Lines that don’t make any sense as password entries are just ignored. Inject a pair of newlines and a single valid passwd entry into the passwd file, and you too can be root on an SAP system.

The hostexecstart vulnerability is a bit more involved. That binary starts and stops the SAP Host Agent on the system. That would be a dead end, except it can also take a SAR archive and upgrade the system agent. [Tao] chased a couple of dead ends regarding library injection and SAR archive signing, before finally using another standard setuid technique, the symbolic link. In this case, link the /etc/passwd file to the local sapcar_output location, and include a malicious passwd line inside a cooked SAR archive. hostexecstart tries to unpack the archive, and outputs the log right into the local sapcar_output file. But that file is really a symbolic link, and it once again clobbers passwd.

Google’s Take on End-to-end-encryption

We’re fans of end-to-end encryption around here. If Alice had a message that’s only intended for Bob to see, then it seems only right that Bob is really the only one that can read the message. The reality of modern cryptography is that this is 100% possible via RSA encryption, and the entire variety of asymmetric encryption schemes that followed. The problem with actually using such encryption is that it’s a pain. Between managing keys, getting an email client set up properly, and then actually using the system in practice, end-to-end asymmetric encryption is usually just not worth the hassle for everyday people.

Google feels that pain, and is bringing easy end-to-end encryption to business Gmail accounts. Except, it’s not actually asymmetric encryption. This works using the key access control list (KACL). Here Alice writes a message, and asks the KACL server for a key to use to send it to Bob. The server provides a symmetric key, and Alice encrypts the message. Then when Bob receives the message, he asks the same server for the same key, and the server provides it, allowing him to decrypt the message.

So is this actually end-to-end encryption? Yes, but also no. While this solution does mean that Google never has the key needed to decrypt the message, it also means that whoever is running the KACL server does have that key. But it is better than the alternative. And the technique in use here could be adapted to make true symmetric encryption far easier for end users.

Ivanti Connect Active Exploit

Google’s Mandiant has announced that Ivanti Connect Secure boxes are under active exploitation via an n-day exploit. This is a buffer overflow that Ivanti discovered internally, and patched in February of this year. The overflow was considered to be strictly limited to denial of service, as the characters written to memory could only be digits and the dot symbol. If that sounds like an IP address, just hang on, and we’ll get there.

It’s apparent that malware actors around the world are actively checking for potential vulnerabilities in Ivanti firmware updates, as the group Mandiant calls UNC5221 has apparently worked out a way to achieve Remote Code Execution with this vulnerability, and is using it to deploy malware on these systems. This is thought to be the same Chinese group that Microsoft appropriately calls Silk Typhoon.

Our friends at watchTowr have dug a bit more into this issue, and found the exact vulnerable code. It’s in HTTP header handling code, where a specific header is first limited to numerals and the period, and then copied into a fixed size buffer. Remember that observation that this sounds like an IP address? The header is X-Forwarded-For, and setting that to a long string of numbers on a vulnerable Ivanti box will indeed trigger a crash in the web binary. There’s no word yet on how exactly that was used to achieve RCE, but we’re very much hoping the rest of the story comes to light, because it’s an impressive feat.

Bits and Bytes

About 100,000 WordPress sites have a real problem. The Ottokit plugin has an authentication bypass issue, where a blank API key can be matched by setting an empty st_authorization header in an incoming request. The flaw was reported privately on April 3rd, and a fixed version was released the same day. But within hours exploitation attempts were seen in the wild.

Legacy Gigacenter devices expose a TR-069 service on port 6998. That service can be accessed with a simple telnet connection, and the commands entered here are not properly sanitized before being evaluated. Anything inside a $() substitution string is executed locally: $(ping -c5 your.ip.address) This makes for an exceedingly trivial remote code execution attack on these devices.

And finally, the Langflow AI workflow tool has a simple remote exploit vulnerability fixed in version 1.3.0. This vulnerability notably allows bypassing authentication through an API endpoint. While Langflow has Python execution by design, doing it while bypassing authentication is a definite problem. You should update to 1.3.0, and don’t expose Langflow to the Internet at all if you can help it.

FLOSS Weekly Episode 828: Incus Inception

9 Abril 2025 at 20:00

This week, Jonathan Bennett and Rob Campbell talk to Stéphane Graber about LXC, Linux Containers, and Incus! Why did Incus fork from LXD, why are Fortune 500 companies embracing it, and why might it make sense for your home lab setup? Watch to find out!

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:


Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

This Week in Security: Target Coinbase, Leaking Call Records, and Microsoft Hotpatching

4 Abril 2025 at 14:00

We know a bit more about the GitHub Actions supply chain attack from last month. Palo Alto’s Unit 42 has been leading the charge on untangling this attack, and they’ve just released an update to their coverage. The conclusion is that Coinbase was the initial target of the attack, with the open source agentkit package first (unsuccessfully) attacked. This attack chain started with pull_request_target in the spotbugs/sonar-findbugs repository.

The pull_request_target hook is exceptionally useful in dealing with pull requests for a GitHub repository. The workflow here is that the project defines a set of Continuous Integration (CI) tests in the repository, and when someone opens a new Pull Request (PR), those CI tests run automatically. Now there’s an obvious potential problem, and Github thought of it and fixed it a long time ago. The GitHub Actions are defined right in the repository, and letting any pull request run arbitrary actions is a recipe for disaster. So GitHub always uses actions as they are defined in the repository itself, ignoring any incoming changes in the PR. So pull_request_target is safe now, right? Yes, with some really big caveats.

The simplest security problem is that many projects have build scripts in the repository, and those are not considered part of GitHub Actions by GitHub. So include malicious code in such a build script, make it a PR that runs automatically, and you have access to internal elements like organization and repository secrets and access tokens. The most effective mitigation against this is to require approval before running workflows on incoming PRs.

So back to the story. The spotbugs/sonar-findbugs repository had this vulnerability, and an attacker used it to export secrets from a GitHub Actions run. One of those secrets happened to be a Personal Access Token (PAT) belonging to a spotbugs maintainer. That PAT was used to invite a throwaway account, [jurkaofavak], into the main spotbugs repository. Two minutes after being added, the [jurkaofavak] account created a new branch in spotbugs/spotbugs, and deleted it about a second later. This branch triggered yet another malicious CI run, now with arbitrary Github Actions access rather than just access through a build script. This run leaked yet another Personal Access Token, belonging to a maintainer that worked on both the spotbugs and reviewdog projects.

That token had access to create and edit tags in reviewdog/action-setup, a GitHub Action that runs as a dependency for multiple other actions. The attacker created a fork of this repository, added malicious code, and then overwrote the v1 git tag to point to this malicious code. The tj-actions/changed-files ran a CI flow that made use of the malicious reviewdog/action-setup fork, leaking a GitHub token with write permission to tj-actions/changed-files.

The tag override trick does a lot of heavy lifting in this story, and that’s what was used on tj-actions/changed-files too. Another malicious fork, and a specific tag was overridden to point there. The tag chosen was one used in a Coinbase repository. Specifically coinbase/agentkit used the newly malicious tag in one of its workflows. A Coinbase maintainer discovered this, and deleted the targeted workflow, putting an end to the Coinbase-specific attack. At this point, the attacker opted to burn the pilfered access, and pushed malicious code to every tj-actions/changed-files tag. The idea apparently being that there would likely be some interesting secrets that were leaked. It’s also possible this was intended to hide Coinbase as the primary target. Regardless, that’s the widespread attack we’ve already covered, and now you know the rest of the story.

ZendTo: No CVE, No Problem?

ZendTo is a nifty Open Source, web-based file sharing platform. It’s been around for a while, and the release notes from a 2021 release makes reference to a “security fix” with no additional details given. That caught the attention of [Jay] from Project Black. It sounds like a potential vulnerability, but it seems like no CVE was ever assigned, and no further details were given.

Here’s the issue: ZendTo has an anonymous file upload feature on by default. This has a security feature built in, in the form of scanning the uploaded file with ClamAV in a temporary location, before moving the file to its long term storage directory. Part of this process includes the ever lovely exec("/bin/chmod go+r " . $ccfilelist); line. PHP has some footguns to be aware of, and calling exec() with any user-provider input is one of them. And of course, the user-provided tmp_name value is used to construct the $ccfilelist string. Set tmp_name to 1;command, and you’ve got code execution.

There is another outstanding issue, where legacy md5 passwords that happen to begin with 0e will be interpreted as a number in scientific notation. PHP handles some type comparisons a bit weirdly. These scientific notation values all evaluate as 0. Using any password that also evaluates to one of these special “scientific” md5 hashes, and the comparison collapses to 0 == 0. So one out of every 256 users have a trivially bypassed password — if their account was still using a md5 password hash.

So here we have a pair of serious vulnerabilities, though one has limited exposure, with neither being fully disclosed nor given CVEs. What’s the result of this lack of transparency? Old, vulnerable installs of ZendTo are still on the Internet. Without a CVE, there’s much less pressure to update. No CVE doesn’t necessarily mean no vulnerabilities.

Leaking Call Records

Researcher [Evan Connelly] was looking into the Verizon Call Filter iOS app, and found it to be using an interesting web service. The callLogRetrieval endpoint allows a user to look up call logs for their own Verizon number. Authorization is done using JSON Web Tokens (JWT), which included a “sub” field, indicating the phone number the token was authorized to fetch. The request itself also has a field to indicate the number being queried. This particular endpoint uses a JWT for authorization, but returns the information requested in the query field — without comparing the two values. Yes, any customer that could obtain a valid JWT could query the call records of virtually any other Verizon number. While this is particularly bad, Verizon acknowledged it quickly, and rolled a fix out in less than a month.

When Parameterized Queries Aren’t

What’s the single most powerful tool to prevent SQL injection attacks? Easy: Parameterized queries. Write the SQL query ahead of time, the library converts it into native database code, and only then are the user-generated values plugged in. In theory that means those values can never be understood as part of the SQL logic. While there are ways this can still go wrong, the basic approach is sound. But what if a language, like Nim, had a parameterization option that didn’t actually do parameterized queries?

Yes, Nim’s db_postgres module provides the facility to run code like getRow(sql"SELECT username FROM users WHERE username=?;", "user"), which is intended to protect against SQL injection. But, under the hood, it really is just doing string replacement with character escaping, like replacing null characters with \\0. Now consider PostreSQL’s standard_conforming_strings setting, which among other things, removes the backslash as a special character. But if that setting is disabled, the backslash can be used to escape quotes. Nim doesn’t know anything about that behavior. This combination of not-actually-parameterized parameterization, and lack of awareness of the standard_conforming_strings behavior, means that ./poc '\' ' OR user_id=1; --' is once again a potential SQL injection. Whoops.

Oracle: Oh, That Oracle Cloud!

We finally have a bit more insight into what’s going on at Oracle. You probably remember that the company has continually denied a breach into Oracle Cloud. It seems this is a bit of verbal sleight-of-hand, as Oracle has renamed part of their cloud offering to Oracle Cloud Classic. The remaining, current generation service is the Oracle Cloud. Oracle Cloud Classic has suffered the breach, not technically Oracle Cloud.

It’s not clear that this is really all there is to the story, though, as more data is getting released by the attacker, including video of a web meeting from 2019. Oracle has started reaching out to customers and confirmed the breach, though apparently strictly avoiding putting anything in writing.

Microsoft Joins the Hotpatch Game

Enterprise Linux distros have long had support for various forms of live-patching. We even interviewed TuxCare about this feature for FLOSS Weekly a few weeks ago. It seems that Microsoft finally wants in on the fun. Windows 11 Enterprise has in-memory security patching starting with the 24H2 update. This support is strictly for machines with an Enterprise or certain Education Microsoft subscriptions. The Hotpatches will be available for 8 of the 12 monthly security patches, with an enforced quarterly update via traditional updates and a reboot.

Bits and Bytes

Researchers at GreyNoise have noted an uptick in IPs scanning for Palo Alto device login pages for several days in March. The scanning had as many as 20,000 unique IPs hunting for these login interfaces, which suggests a botnet has been tasked with finding these devices. It’s very possible that a threat actor has found a new vulnerability in Palo Alto devices, and is preparing to launch an attack.

And finally, a pair of posts from ZDI caught our attention this week. The first is a dive into how Binary Ninja’s static code analysis can find potential use-after-free vulnerabilities. The second is all about building an electric car simulator, that can actually plug into real electric vehicle charging stations, and actually fool the charger into believing a car is attached. How is this problem approached safely, given the high voltages and amperages involved? Very carefully.

This Week in Security: IngressNightmare, NextJS, and Leaking DNA

28 Marzo 2025 at 14:00

This week, researchers from Wiz Research released a series of vulnerabilities in the Kubernetes Ingress NGINX Controller  that, when chained together, allow an unauthorized attacker to completely take over the cluster. This attack chain is known as IngressNightmare, and it affected over 6500+ Kubernetes installs on the public Internet.

The background here is that web applications running on Kubernetes need some way for outside traffic to actually get routed into the cluster. One of the popular solutions for this is the Ingress NGINX Controller. When running properly, it takes incoming web requests and routes them to the correct place in the Kubernetes pod.

When a new configuration is requested by the Kubernetes API server, the Ingress Controller takes the Kubernetes Ingress objects, which is a standard way to define Kubernetes endpoints, and converts it to an NGINX config. Part of this process is the admission controller, which runs nginx -t on that NGINX config, to test it before actually deploying.

As you might have gathered, there are problems. The first is that the admission controller is just a web endpoint without authentication. It’s usually available from anywhere inside the Kubernetes cluster, and in the worst case scenario, is accessible directly from the open Internet. That’s already not great, but the Ingress Controller also had multiple vulnerabilities allowing raw NGINX config statements to be passed through into the config to be tested.

And then there’s nginx -t itself. The man page states, “Nginx checks the configuration for correct syntax, and then tries to open files referred in the configuration.” It’s the opening of files that gets us, as those files can include shared libraries. The ssl_engine fits the bill, as this config line can specify the library to use.

That’s not terribly useful in itself. However, NGINX saves memory by buffering large requests into temporary files. Through some trickery, including using the /proc/ ProcFS pseudo file system to actually access that temporary file, arbitrary files can be smuggled into the system using HTTP requests, and then loaded as shared libraries. Put malicious code in the _init() function, and it gets executed at library load time: easy remote code execution.

This issue was privately disclosed to Kubernetes, and fixed in Ingress NGINX Controller version 1.12.1 and 1.11.5, released in February. It’s not good in any Kubernetes install that uses the Ingress NGINX Controller, and disastrously bad if the admission controller is exposed to the public Internet.

Next.js

Another project, Next.js, has a middleware component that serves a similar function as an ingress controller. The Nixt.js middleware can do path rewriting, redirects, and authentication. It has an interesting behavior, in that it adds the x-middleware-subrequest HTTP header to recursive requests, to track when it’s talking to itself. And the thing about those headers is that they’re just some extra text in the request. And that’s the vulnerability: spoof a valid x-middleware-subrequest and the Next.js middleware layer just passes the request without any processing.

The only hard part is to figure out what a valid header is. And that’s changed throughout the last few versions of Next.js. The latest iteration of this technique is to use x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware or a minor variant, to trigger the middleware’s infinite recursion detection, and pass right through. In some use cases that’s no problem, but if the middleware is also doing user authentication, that’s a big problem. The issue can be mitigated by blocking x-middleware-subrequest requests from outside sources, and the 14.x and 15.x releases have been updated with fixes.

Linux’ No-op Security Function

The linux kernel uses various hardening techniques to make exploitation of bugs difficult. One technique is CONFIG_RANDOM_KMALLOC_CACHES, which makes multiple copies of memory allocation caches, and then randomizes which copy is actually used, to make memory corruption exploitation harder. Google researchers found a flaw in nftables, and wrote up the exploit, which includes the observation that this mitigation is completely non-functional when used from kvmalloc_node.

This happens as a result of how that randomization process is done. The function that calculates which of the copies to actually call actually uses its own return address as the seed value for the random value. That makes sense in some cases, but the calling function is an “exported symbol”, which among other things, means the return value is always the same, rendering the hardening attempt completely ineffective. Whoops. This was fixed in the Linux 6.15 merge window, and will be backported to the stable kernels series.

Your DNA In Bankruptcy

I’ve always had conflicting feelings about the 23andMe service. On one hand, there is some appeal to those of us that may not have much insight to our own genetic heritage, to finally get some insight into that aspect of our own history. On the other hand, that means willingly giving DNA to a for-profit company, and just trusting them to act responsibly with it. That concern has been brought into sharp focus this week, as 23andMe has filed for Chapter 11 bankruptcy. This raises a thorny question, of what happens to that DNA data as the company is sold?

The answer seems to be that the data will be sold as well, leading to calls for 23andMe customers to log in and request their data be deleted. Chapter 11 bankruptcy does not prevent them from engaging in business activities, and laws like the GDPR continue to apply, so those requests should be honored. Regardless, it’s a stark reminder to be careful what data you’re willing to entrust to what business, especially something as personal as DNA. It’s unclear what the final fallout is going to be from the company going bankrupt, but it’s sure to be interesting.

Appsmith and a Series of Footguns

Rhino Security did a review of the Appsmith platform, and found a series of CVEs. On the less severe side, that includes a error handling problem that allows an unauthorized user to restart the system, and an easily brute-forced unique ID that allows read-only users to send arbitrary SQL queries to databases in their workspace. The more serious problem is a pseudo-unauthenticated RCE that is in some ways more of a default-enabled footgun than a vulnerability.

On a default Appsmith install, the default postgres database allows local connections to any user, on any database. Appsmith applications use that local socket connection. Also in the default configuration, Appsmith will allow new users to sign up and create new applications without needing permission. And because that new user created their own application on the server, the user has permissions to set up database access. And from there postgres will happily let the user run a FROM PROGRAM query that runs arbitrary bash code.

Bits and Bytes

There’s been a rumor for about a week that Oracle Cloud suffered a data breach, that Oracle has so far denied. It’s beginning to look like the breach is a real one, with Bleeping Computer confirming that the data samples are legitimate.

Google’s Project Zero has a blast from the past, with a full analysis of the BLASTPASS exploit. This was a 2003 NSO Group exploit used against iMessage on iOS devices, and allowed for zero-click exploitation. It’s a Huffman tree decompression vulnerability, where attempting to decompress the tree overwrites memory and triggers code execution. Complicated, but impressive work.

Resecurity researchers cracked the infrastructure of the BlackLock ransomware group via a vulnerability in the group’s Data Leak Site. Among the treasures from this action, we have the server’s history logs, email addresses, some passwords, and IP address records. While no arrests have been reported in connection with this action, it’s an impressive hack. Here’s hoping it leads to some justice for ransomware crooks.

And finally, Troy Hunt, master of pwned passwords, has finally been stung by a phishing attack. And had a bit of a meta-moment when receiving an automated notice from his own haveibeenpwned.com service. All that was lost was the contents of Troy’s Mailchimp mailing list, so if your email address was on that list, it’s available in one more breach on the Internet. It could have been worse, but it’s a reminder that it can happen to even the best of us. Be kind.

This is too many levels of meta for my head to grasp 🤯 pic.twitter.com/Pr0iFQGNlh

— Troy Hunt (@troyhunt) March 25, 2025

This Week in Security: The Github Supply Chain Attack, Ransomware Decryption, and Paragon

21 Marzo 2025 at 14:00

Last Friday Github saw a supply chain attack hidden in a popular Github Action. To understand this, we have to quickly cover Continuous Integration (CI) and Github Actions. CI essentially means automatic builds of a project. Time to make a release? CI run. A commit was pushed? CI run. For some projects, even pull requests trigger a CI run. It’s particularly handy when the project has a test suite that can be run inside the CI process.

Doing automated builds may sound straightforward, but the process includes checking out code, installing build dependencies, doing a build, determining if the build succeeded, and then uploading the results somewhere useful. Sometimes this even includes making commits to the repo itself, to increment a version number for instance. For each step there are different approaches and interesting quirks for every project. Github handles this by maintaining a marketplace of “actions”, many of which are community maintained. Those are reusable code snippets that handle many CI processes with just a few options.

One other element to understand is “secrets”. If a project release process ends with uploading to an AWS store, the process needs an access key. Github stores those secrets securely, and makes them available in Github Actions. Between the ability to make changes to the project itself, and the potential for leaking secrets, it suddenly becomes clear why it’s very important not to let untrusted code run inside the context of a Github Action.

And this brings us to what happened last Friday. One of those community maintained actions, tj-actions/changed-files, was modified to pull an obfuscated Python script and run it. That code dumps the memory of the Github runner process, looks for anything there tagged with isSecret, and writes those values out to the log. The log, that coincidentally, is world readable for public repositories, so printing secrets to the log exposes them for anyone that knows where to look.

Researchers at StepSecurity have been covering this, and have a simple search string to use: org:changeme tj-actions/changed-files Action. That just looks for any mention of the compromised action. It’s unclear whether the compromised action was embedded in any other popular actions. The recommendation is to search recent Github Action logs for any mention of changed-files, and start rotating secrets if present.

Linux Supply Chain Research

The folks at Fenrisk were also thinking about supply chain attacks recently, but specifically in how Linux distributions are packaged. They did find a quartet of issues in Fedora’s Pagure web application, which is used for source code management for Fedora packages. The most severe of them is an argument injection in the logging function, allowing for arbitrary file write.

The identifier option is intended to set the branchname for a request, but it can be hijacked in a request, injecting the output flag: http://pagure.local/test/history/README.md?identifier=--output=/tmp/foo.bar. That bit of redirection will output the Git history to the file specified. Git history consists of a git hash, and then the short commit message. That commit message has very little in the way of character scrubbing, so Bash booleans like || can be used to smuggle a command in. Add the cooked commit to your local branch of something, query the URL to write the file history to your .bashrc file, and then attempt to SSH in to the Pagure service. The server does the right thing with the SSH connection, refusing to give the user a shell, but not before executing the code dropped into the .bashrc file. This one was disclosed in April 2024, and was fixed within hours of disclosure by Red Hat.

Pagure was not the only target, and Fenrisk researchers also discovered a critical vulnerability in OpenSUSE’s Open Build Service. It’s actually similar to the Fedora Pagure issue. Command options can be injected into the wget command used to download the package source file. The --output-document argument can be used to write arbitrary data to a file in the user’s home directory, but there isn’t an obvious path to executing that file. There are likely several ways this could be accomplished, but the one chosen for this Proof of Concept (PoC) was writing a .proverc file in the home directory. Then a second wget argument is injected, using --use-askpass to trigger the prove binary. It loads from the local rc file, and we have arbitrary shell code execution. The OpenSUSE team had fixes available and rolled out within a few days of the private disclosure back in June of 2024.

Breaking Ransomware Encryption

What do you do when company data is hit with Akira ransomware, and the backups were found wanting? If you’re [Yohanes Nugroho], apparently you roll up your sleeves and get to work. This particular strain of Akira has a weakness that made decryption and recovery seemingly easy. The encryption key was seeded by the current system time, and [Yohanes] had both system logs and file modification timestamps to work with. That’s the danger of using timestamps for random seeds. If you know the timestamp, the pseudorandom sequence can be derived.

It turns out, it wasn’t quite that easy. This strain of Akira actually used four separate nanosecond scale time values in determining the per-file encryption key. Values we’ll call t3 and t4 are used to seed the encryption used for the first eight bytes of each file. If there’s any hope of decrypting these files, those two values will have to be found first. Through decompiling the malware binaries, [Yohanes] knew that the malware process would start execution, then run a fixed amount of code to generate the t3 key, and a fixed amount of code before generating the t4 key. In an ideal world, that fixed code would take a fixed amount of time to run, but multi-core machines, running multi-threaded operations on real hardware will introduce variations in that timing.

The real-world result is a range of possible time offsets for both those values. Each timestamp from the log results in about 4.5 quadrillion timestamp pairs. Because the timing is more known, once t3 and t4 are discovered, finding t1 and t2 is much quicker. There are some fun optimizations that can be done, like generating a timestamp to pseudorandom value lookup table. It works well ported to CUDA, running on an RTX 4090. In the end, brute-forcing a 10 second slice of timestamps cost about $1300 dollars when renting GPUs through a service like vast.ai. The source code that made this possible isn’t pretty, but [Yohanes] has made it all available if you want to attempt the same trick.

Github and Ruby-SAML — The Rest of the Story

Last week we briefly talked about Github’s discovery of the multiple parser problem in Ruby-SAML, leading to authentication bypass. Researchers at Portswigger were also working on this vulnerability, and have their report out with more details. One of those details is that while Github had already moved away from using this library, Gitlab Enterprise had not. This was a real vulnerability on Gitlab installs, and if your install is old enough, maybe it still is.

The key here is a CDATA section wrapped in an XML comment section is only seen by one of the parsers. Include two separate assertion blocks, and you get to drive right through the difference between the two parsers.

Paragon

There’s a new player in the realm of legal malware. Paragon has reportedly targeted about 90 WhatsApp users with a zero-click exploit, using a malicious PDF attachment to compromise Android devices. WhatsApp has mitigated this particular vulnerability on the server side.

It’s interesting that apparently there’s something about the process of adding the target user to the WhatsApp group that was important to making the attack work. Paragon shares some similarities with NSO Group, but maintains that it’s being more careful about who those services are being offered to.

Bits and Bytes

We have a pair of local privilege escalation attacks. This is useful when an attacker has unprivileged access to a machine, but can use already installed software to get further access. The first is Google’s Web Designer, that starts a debug port, and exposes an account token and file read/right to the local system. The other is missing quotation marks in Plantronics Hub, which leads to the application attempting to execute C:\Program.exe before it descends into Program Files to look for the proper location.

This is your reminder, from Domain Guard, to clean up your DNS records. I’ve now gone through multiple IP address changes of my “static” IP Addresses. At the current rate of IPv4 exhaustion, those IPs are essentially guaranteed to be given out to somebody else. Is it a problem to have dangling DNS records? It’s definitely not a good situation, because it enables hacks from cross-site scripting vulnerabilities, to cookie stealing, to potentially defeating domain verification schemes with the errant subdomain.

MacOS has quite a fine history of null-pointer dereference vulnerabilities. That’s when a pointer is still set to NULL, or 0, and the program errantly tries to access that memory location. It used to be that a clever attacker could actually claim memory location 0, and take advantage of the bogus dereference. But MacOS put an end to that technique in a couple different ways, the most effective being disallowing 32 bit processes altogether in recent releases. It seems that arbitrary code execution on MacOS as result of a NULL Pointer Dereference is a thing of the past. And yes, we’re quite aware that this statement means that somehow, someone will figure out a way to make it happen.

And Finally, watchTowr is back with their delightful blend of humor and security research. This time it’s a chain of vulnerabilities leading to an RCE in Kentico, a proprietary web Content Management System. This vulnerability has one of my least favorite data formats, SOAP XML. It turns out Kentico’s user authentication returns an empty string instead of a password hash when dealing with an invalid username. And that means you can craft a SOAP authenticaiton token with nothing more than a valid nonce and timestamp. Whoops. The issue was fixed in a mere six days, so good on Kentico for that.

This Week in Security: The X DDoS, The ESP32 Basementdoor, and the camelCase RCE

14 Marzo 2025 at 14:00

We would be remiss if we didn’t address the X Distributed Denial of Service (DDoS) attack that’s been happening this week. It seems like everyone is is trying to make political hay out of the DDoS, but we’re going to set that aside as much as possible and talk about the technical details. Elon made an early statement that X was down due to a cyberattack, with the source IPs tracing back to “the Ukraine area”.

The latest reporting seems to conclude that this was indeed a DDoS, and a threat group named “Dark Storm” has taken credit for the attack. Dark Storm does not seem to be of Ukrainian origin or affiliation.

We’re going to try to read the tea leaves just a bit, but remember that about the only thing we know for sure is that X was unreachable for many users several times this week. This is completely consistent with the suspected DDoS attack. The quirk of modern DDoS attacks is that the IP addresses on the packets are never trustworthy.

There are two broad tactics used for large-scale DDoS attacks, sometimes used simultaneously. The first is the simple botnet. Computers, routers, servers, and cameras around the world have been infected with malware, and then remote controlled to create massive botnets. Those botnets usually come equipped with a DDoS function, allowing the botnet runner to task all the bots with sending traffic to the DDoS victim IPs. That traffic may be UDP packets with spoofed or legitimate source IPs, or it may be TCP Synchronization requests, with spoofed source IPs.

The other common approach is the reflection or amplification attack. This is where a public server can be manipulated into sending unsolicited traffic to a victim IP. It’s usually DNS, where a short message request can return a much larger response. And because DNS uses UDP, it’s trivial to convince the DNS server to send that larger response to a victim’s address, amplifying the attack.

Put these two techniques together, and you have a botnet sending spoofed requests to servers, that unintentionally send the DDoS traffic on to the target. And suddenly it’s understandable why it’s so difficult to nail down attribution for this sort of attack. It may very well be that a botnet with a heavy Ukrainian presence was involved in the attack, which at the same time doesn’t preclude Dark Storm as the originator. The tea leaves are still murky on this one.

That ESP32 Backdoor

As Maya says, It Really Wasn’t a backdoor. The Bleeping Computer article and Tarlogic press release have both been updated to reflect the reality that this wasn’t really a backdoor. Given that the original research and presentation were in Spanish, we’re inclined to conclude that the “backdoor” claim was partially a translation issue.

The terminology storm set aside, what researchers found really was quite interesting. The source of information was official ESP32 binaries that implement the Bluetooth HCI, the Host Controller Interface. It’s a structured format for talking to a Bluetooth chip. The official HCI has set aside command space for vendor-specific commands. The “backdoor” that was discovered was this set of undocumented vendor-specific commands.

These commands were exposed over the HCI interface, and included low-level control over the ESP32 device. However, for the vast majority of ESP32 use cases, this interface is only available to code already running on the device, and thus isn’t a security boundary violation. To Espressif’s credit, their technical response does highlight the case of using an ESP32 in a hosted mode, where an external processor is issuing HCI commands over something like a serial link. In that very narrow case, the undocumented HCI commands could be considered a backdoor, though still requires compromise of the controlling device first.

All told, it’s not particularly dangerous as a backdoor. It’s a set of undocumented instructions that expose low-level functions, but only from inside the house. I propose a new term for this: a Basementdoor.

The Fake Recruitment Scam

The fake recruitment scam isn’t new to this column, but this is the first time we’ve covered a first-hand account of it. This is the story of [Ron Jansen], a freelance developer with impressive credentials. He got a recruiter’s message, looking to interview him for a web3 related position. Interviews often come with programming tasks, so it wasn’t surprising when this one included instructions to install something from Github using npm and do some simple tasks.

But then, the recruiter and CTO both went silent, and [Ron] suddenly had a bad feeling about that npm install command. Looking through the code, it looked boring, except for the dependency NPM package, process-log. With only 100-ish weekly downloads, this was an obvious place to look for something malicious. It didn’t disappoint, as this library pulled an obfuscated blob of JSON code and executed it during install. The deobfuscated code establishes a websocket connection, and uploads cookies, keychains, and any other interesting config or database files it can find.

Once [Ron] new he had been had, he started the infuriating-yet-necessary process of revoking API keys, rotating passwords, auditing everything, and wiping the affected machine’s drive. The rest of the post is his recommendations for how to avoid falling for this scam yourself. The immediate answer is to run untrusted code in a VM or sandbox. There are tools like Deno that can also help, doing sandboxing by default. Inertia is the challenge, with a major change like that.

Camel CamelCase RCE

Apache Camel is a Java library for doing Enterprise Integration Patterns. AKA, it’s network glue code for a specific use case. It sends data between endpoints, and uses headers to set certain options. One of the important security boundries there is that internal headers shouldn’t be set by outside sources. To accomplish that, those headers are string compared with Camel and org.apache.camel as the starting characters. The problem is that the string comparison is exact, while the header names themselves are not case sensitive. It’s literally a camelCase vulnerability. The result is that all the internal headers are accessible from any client, via this case trickery.

The vulnerability has been fixed in the latest release of Camel. The seriousness of this vulnerability depends on the component being connected to. Akamai researchers provided a sample application, where the headers were used to construct a command. The access to these internal values makes this case an RCE. This ambiguity is why the severity of this vulnerability is disputed.

Bits and Bytes

Researchers at Facebook have identified a flaw in the FreeType font rending library. It’s a integer underflow leading to a buffer overflow. An attacker can specify a very large integer value, and the library will add to that variable during processing. This causes the value to wrap around to a very small value, resulting in a buffer much too small to hold the given data. This vulnerability seems to be under active exploitation.

We don’t normally see problems with a log file leading to exploitation, but that seems to be the situation with the Below daemon. The service runs as root, and sets the logfile to be world readable. Make that logfile a symlink to some important file, and when the service starts, it overwrites the target file’s permissions.

Microsoft’s Patch Tuesday includes a whopping six 0-day exploits getting fixed this month. Several of these are filesystem problems, and at least one is an NTFS vulnerability that can be triggered simply by plugging in a USB drive.

The ruby-saml library had a weird quirk: it used two different XML parsers while doing signature validations. That never seems to go well, and this is not any different. It was possible to pack two different signatures into a single XML document, and the two different parsers would each see the file quite differently. The result was that any valid signature could be hijacked to attest as any other user. Not good. An initial fix has already landed, with a future release dropping one of the XML parsers and doing a general security hardening pass.

FLOSS Weekly Episode 824: Gratuitous Navel Gazing

12 Marzo 2025 at 20:00

This week, Jonathan Bennett chats with Doc Searls about SCaLE and Personal AI! What’s the vision of an AI that consumers run themselves, what form factor might that take, and how do we get there?

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:


Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

FLOSS Weekly Episode 823: TuxCare, 10 Years Without Rebooting!

5 Marzo 2025 at 19:30

This week, Jonathan Bennett and Aaron Newcomb talk with Joao Correia about TuxCare! What’s live patching, and why is it so hard? And how is this related to .NET 6? Watch to find out!

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:


Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

FLOSS Weekly Episode 822: Nand2Tetris

26 Febrero 2025 at 19:30

This week, Jonathan Bennett and Rob Campbell talk with Shimon Schocken about Nand2Tetris, the free course about building a computer from first principles. What was the inspiration for the course? Is there a sequel or prequel in the works? Watch to find out!

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:


Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

FLOSS Weekly Episode 821: Rocky Linux

19 Febrero 2025 at 19:30

This week, Jonathan Bennett talks Rocky Linux with Gregory Kurtzer and Krista Burdine! Where did the project come from, and what’s the connection with CIQ and RESF? Listen to find out!

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:


Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

FLOSS Weekly Episode 820: Please Don’t add AI Clippy to Thunderbird

12 Febrero 2025 at 19:30

This week, Jonathan Bennett talks Thunderbird with Ryan Sipes! What’s the story with almost becoming part of LibreOffice, How has Thunderbird collected so many donations, and more!

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:


Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

❌
❌