F5 is unintentionally dabbling in releasing the source code behind their BIG-IP networking gear, announcing this week that an unknown threat actor had access to their internal vulnerability and code tracking systems. This security breach was discovered on August 9th, and in the time since, F5 has engaged with CrowdStrike, Mandiant, and NCC Group to review what happened.

So far it appears that the worst result is access to unreleased vulnerabilities in the F5 knowledge management system. This means that any unpatched vulnerabilities were effectively 0-days, though the latest set of patches for the BIG-IP system has fixed those flaws. There aren’t any reports of those vulnerabilities being exploited in the wild, and F5 has stated that none of the leaked vulnerabilities were critical or allowed for remote exploitation.

Slightly more worrying is that this access included the product development environment. The problem there isn’t particularly the leak of the source code — one of the covered projects is NGINX, which is already open source software. The real danger is that changes could have been surreptitiously added to those codebases. The fact that NGINX is Open Source goes a long way to alleviate that danger, and when combined with the security built into tools like git, it seems very unlikely that malicious code could be sneaked into the NGINX public code base. A thorough review of the rest of the F5 codebases has similarly come up negative, and so far it looks like the supply-chain bullet has been dodged.

WatchGuard Out of Bounds

WatchGuard’s Fireware OS has a stack buffer overflow. There’s a few interesting details about this story. The first, as WatchTowr researchers gleefully point out, is that it’s 2025 and a security vendor has a stack overflow bug straight out of the ’90s. But second, this is one of the first vulnerabilities we’ve covered that has a CVSS 4.0 score. In CVSS 3 terms, this would be a severity 10 vulnerability. As the the 4th iteration of the Common Vulnerability Scoring System also measures the impact on the rest of the network, it scores a bit lower 9.3 there, though one could probably make an argument that it should be higher.

The actual vulnerability is in the VPN service, and it’s as simple as it gets. An attacker controlled buffer is copied into a fixed length memory region without any bounds checking. That VPN service uses an IKEv2 handshake protocol to establish connections, and the server responds with an odd Base64 encoded string. Decode the string, and it turns out the vulnerable service announces VN=12.11.3 BN=719894, the version number and build string, allowing for super easy identification of vulnerable targets.

The final step in turning this into a true vulnerability is to corrupt the stack, take control of the program counter, and Return-Oriented-Program your way through a couple gadgets to be able to call system(). Right? This platform doesn’t turn on every mitigation — stack canaries and position independent execution are noticeably missing. But there are some good hardening steps that were done, like leaving out /bin/sh altogether. How do you run shellcode when the machine doesn’t have a shell at all? The answer the WatchTowr crew turned to was to run the system code in the Python3 shell. Thinking outside the box!

Sonicwall and Unintentional Distributed Backups

About a month ago, we shared the news that Sonicwall had a breach of their own, with limited customers backups being exposed. At the time, the word was that fewer than 5% of customers would be affected. That estimate seems to have been a bit optimistic, as SonicWall is now recommending that all customers step through their new remediation playbook, which calls for a complete cycling of all credentials stored on Sonicwall devices.

It’s unclear if this is because more configuration data was accessible than was previously believed, or because attackers are actively using the pilfered data in attacks against SonicWall customers. The unintentional distribution of system backups turns out not to have been a good strategy.

UEFI Backdoor

UEFI and Secure Boot have been viewed with skepticism, particularly by Linux enthusiasts over the years. There is, however, something to be said for the idea that your computer won’t boot a manipulated OS without your permission, and especially since major Linux distros have access to signed Secure Boot keys, it hasn’t been the dystopian disaster that many of us feared. The security question of the UEFI root of trust has had its own problems, and one of those problems has recently bitten Framework laptops. The issue is the mm (Memory Modify) command that can optionally be built into UEFI shells. This is strictly for debugging purposes, and it’s been discovered that allowing arbitrary access to system memory is not great for system security.

Eclypsium researchers are calling this one BombShell, and it boils down to overwriting the security handler pointer in the UEFI firmware, so all Secure Boot checks are disabled. It seems that this level of tampering is invisible to the system and booted OS. And with just a bit of cleverness, it can be injected as a permanent boot payload. While it’s specifically Framework laptops that are in question with this specific disclosure, it’s not strictly a Framework issue, but can affect any UEFI machine that ships a signed UEFI shell, that includes dangerous commands like mm.

Hack a Car Company, and All the Cars

We have a delightful hack from Def Con 33, where an as-of-yet-unnamed car brand had a couple security problems with their admin web portal, and those problems are pretty serious when put together. First, the invite-only dealer portal didn’t actually verify the invite tokens. And second, when creating an account, the back-end didn’t actually check the account creation details. Meaning that anyone that knew where to look could create an admin account.

The result was that a VIN number could be used to look up a car, and the owner’s details could be accessed. Or the system could be searched via owner’s information, to find vehicle information. It allowed transferring authentication of one of the vehicles to a new mobile app account, and the mobile app could be used to unlock the vehicle.

Windows 10

It’s time to turn out the lights, the party is over. The sun has set and Windows 10 has entered its twilight. The advice from every other legacy OS applies: upgrade if you can. Yes, there are some frustrating problems with upgrading to Windows 11, particularly if your machine is just too old to have a TPM or Secure Boot.

If you’re stuck on Windows 10, there’s good news and bad news. The good news is that Microsoft is making security updates available for free, for many computers, if you use a Microsoft account on the machine. The bad news is that those updates are a monthly trickle of fresh vulnerabilities that some machines just won’t ever get patched for.

Bits and Bytes

What do you do when you’re flying, and you’re too cheap frugal to pay for in-flight wifi? Naturally, find some way to tunnel out for free. The key is usually DNS. It’s probably the inverse of the meme, that the problem is always DNS, as that’s the last thing a security hardening team wants to break. And if that won’t work, there’s always MAC address cloning.

Many a pen test has hit a brick wall when faced with a gRPC endpoint. Google’s Remote Procedure Call framework is binary, and without reflection turned on, extremely difficult to map what calls are available. There’s a new tool, grpc-scan, that just might shed some light on the subject. It’s a combination of common design patterns, and carefully parsing the returned errors to learn about the system.

And finally, where’s the most bulletproof place you can host some malicious code? A server in Russia? Apparently it’s now on the blockchain. This isn’t a theoretical attack from a security thinktank, but a real-world malware campaign believed to originate from North Korean hackers. Yet another red flag to watch out for in smart contracts!

This week Jonathan talks to James Cole about Firefly III, the personal finance manager! This one itches James’ own itch, but brings great visualization and management tools for your personal finances!

• https://www.firefly-iii.org/
• https://docs.firefly-iii.org/?mtm_campaign=firefly-iii-org&mtm_kwd=top-link
• https://github.com/firefly-iii/firefly-iii/

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.

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

Licensed under Creative Commons: By Attribution 4.0 License

Discord had a data breach back on September 20th, via an outsourced support contractor. It seems it was a Zendesk instance that was accessed for 58 hours through a compromised contractor user account. There have been numbers thrown around from groups claiming to be behind the breach, like 1.6 Terabytes of data downloaded, 5.5 million user affected, and 2.1 million photos of IDs.

Discord has pushed back on those numbers, stating that it’s about 70,000 IDs that were leaked, with no comments on the other claims. To their credit, Discord has steadfastly refused to pay any ransom. There’s an interesting question here: why were Discord users’ government issued IDs on record with their accounts?

The answer is fairly simple: legal compliance. Governments around the world are beginning to require age verification from users. This often takes the form of a scan of valid ID, or even taking a picture of the user while holding the ID. There are many arguments about whether this is a good or bad development for the web, but it looks like ID age verification is going to be around for a while, and it’ll make data breaches more serious.

In similar news, Salesforce has announced that they won’t be paying any ransoms to the group behind the compromise of 39 different Salesforce customers. This campaign was performed by calling companies that use the Salesforce platform, and convincing the target to install a malicious app inside their Saleforce instance.

Unity

[RyotaK] from Flatt Security found an issue in the Unity game engine, where an intent could influence the command line arguments used to launch the Unity runtime. So what’s an intent?

On Android, an Intent is an object sent between applications indicating an intention. It’s an intra-process messaging scheme. So the problem here is that when sending an intent to a Unity application on Android, a command line option can be included as an extra option. One of those command line options allows loading a local library by name. Since a malicious library load results in arbitrary code execution, this seems like a pretty big problem.

At first it seems that this doesn’t gain an attacker much. Doesn’t a malicious app already need to be running on the device to send a malicious intent? The reality is that it’s often possible to manipulate an innocent app into sending intents, and the browser is no exception. The bigger problem is that a malicious library must first be loaded into a location from which the Unity app can execute. It’s a reasonably narrow window for practical exploitation, but was still scores an 8.4 severity. Unity has released fixes for versions all the way back to 2019.1.

Code Smell: Perl?

We have two stories from WatchTwr, packed full of the sardonic wit we have to expect from these write-ups. The first is about Dell’s UnityVSA, a Virtual Storage Appliance that recently received a whole slew of security fixes for CVEs. So WatchTowr researchers took a look at the patch set from those fixes, looking for code smell, and found… Perl?

Turns out it wasn’t the presence of Perl that was considered bad code smell, though I’m sure some would argue that point. It was the $exec_cmd variable that wasn’t escaped, and Perl backticks were used to execute that string on the system. Was there a way to inject arbitrary bash commands into that string? Naturally, there is. And it’s a reasonably simple HTTP query to run a command. A security advisory and updated release was published by Dell at the end of July, fixing this issue.

Poetic Flow of Vulnerabilities

There’s an active exploitation campaign being waged against Oracle E-Business Suite instances, using a zero-day vulnerability. This exploit works over the network, without authentication, and allows Remote Code Execution (RCE). It appears that a threat group known as Graceful Spider, another great name, is behind the exploitation.

The folks at WatchTowr got their hands on a Proof of Concept, and have reverse engineered it for our edification. It turns out it’s a chain of little weaknesses that add up to something significant.

It starts with a Server-Side Request Forgery (SSRF), a weakness where a remote service can be manipulated into sending an additional HTTP request on to another URL. This is made more significant by the injection of a Carriage Return/Line Feed (CRLF) attack, that allows injecting additional HTTP headers.

Another quirk of the PoC is that it uses HTTP keep-alive to send all of the malicious traffic down a single HTTP session. And the actual authentication bypass is painfully classic. A /help path doesn’t require authentication, and there is no path traversal protection. So the SSRF connection is launched using this /help/../ pattern, bypassing authentication and landing at a vulnerable .jsp endpoint.

That endpoint assembles a URL using the Host: header from the incoming connection, and fetches and parses it as an eXtensible Stylesheet Language (XSL) document. And XSL documents are unsafe to load from untrusted sources, because they can lead directly to code execution. It’s a wild ride, and a great example of how multiple small issues can stack up to be quite significant when put together.

Bits and Bytes

Caesar Creek Software did an audit on a personal medical device and found issues, but because fixes are still being reviewed by the FDA, we don’t get many details on what exactly this is. Reading between the lines, it sounds like a wearable glucose monitor. It’s based on the nRF52 platform, and the best bit of this research may be using power line fault injection to get Single Wire Debug access to the MCU. They also found what appears to be a remote leak of uninitialized memory, and a Bluetooth Low Energy Man in the Middle attack. Interesting stuff.

And finally, [LaurieWired] has a great intro to the problem of trusting trust with a bit of bonus material on how to build and obfuscate quines while at it. How do you know your compiler binary doesn’t have malware in it? And how do you establish trust again? Enjoy!

This week Jonathan and Aaron chat with Piers Finlayson about One ROM! Why does the retro-computing world need a solution for replacement ROMs? How difficult was it to squeeze a MCU and layout into the original ROM footprint? And what’s next for the project? Listen to find out!

• https://piers.rocks/
• https://onerom.org/
• https://github.com/piersfinlayson/one-rom
• https://github.com/piersfinlayson/airfrog

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.

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

Licensed under Creative Commons: By Attribution 4.0 License

This week a reader sent me a story about a CVE in Notepad++, and something isn’t quite right. The story is a DLL hijack, a technique where a legitimate program’s Dynamic Link Library (DLL) is replaced with a malicious DLL. This can be used for very stealthy persistence as well as escalation of privilege. This one was assigned CVE-2025-56383, and given a CVSS score of 8.4.

The problem? Notepad++ doesn’t run as a privileged user, and the install defaults to the right permissions for the folder where the “vulnerable” DLL is installed. Or as pointed out in a GitHub issue on the Proof of Concept (PoC) code, why not just hijack the notepad++ executable?

This is key when evaluating a vulnerability write-up. What exactly is the write-up claiming? And what security boundary is actually being broken? The Common Weakness Enumeration (CWE) list can be useful here. This vulnerability is classified as CWE-427, an uncontrolled search path element — which isn’t actually what the vulnerability claims, and that’s another clue that something is amiss here. In reality this “vulnerability” applies to every application that uses a DLL: a CVSS 0.

Smish Boxes

There’s a trend to replace land lines with cellular modems. While wearing my phone tech hat, I’ve even installed a few cellular routers in hotel telecom closets. It turns out there’s a potential problem with that particular arrangement. Hotels and other commercial installations often assign a public IP address to each piece of equipment, and as a result it’s not uncommon for that equipment to be directly exposed to the Internet. And what happens when cellular routers are exposed to the Internet, sometimes with vulnerabilities or even default credentials? Naturally, scammers use them to send spammy SMS messages.

The scale of the problem is surprising. After researchers at Sekoia discovered the problem, they discovered 18,000 of these devices accessible on the Internet. It seems like this campaign may be responsible for the majority of the SMS spam being sent in modern smishing campaigns. It also appears that there may be an unknown 0-day being exploited in the campaign.

VMWare

VMware just fixed CVE-2025-41244, a local privilege escalation vulnerability that has been in use in the wild since at least October of last year. This vulnerability is in the service discovery feature of VMware Aria. The idea is that the installed VMware Tools can discover running services and probe for version numbers.

On a Linux guest, this probe works by listing the currently running processes, and if the a process matches one of the regular expressions, that process is run with the -v flag. As root. Yes, this vulnerability that was being actively exploited in the wild by a Chinese threat actor for over a year, was as simple as an over-matching regex and carelessly running binaries as root. The trick favored by the attackers was to place a malicious binary at /tmp/httpd, run it as a regular user, and just wait for the VMware tooling to come along and run it as root.

Sudo Chwoot

The maintainers behind sudo fixed a pair of vulnerabilities back in June that allowed a local attacker to escalate privileges. The most interesting of the two abuses is in the handling of the chroot option, resulting in an attack [Rich Mirch] refers to as “chwoot”.

The actual weakness is that sudo would use the chroot() system call while setting up the chroot environment, prior to dropping privileges. In this state, sudo performs Name Service Switch calls as root, which results in looking for /etc/nsswitch.conf inside the chroot directory. This config file can trigger a shared library load, and since it’s happening in the context of a chroot, that library is also first loaded from the chroot directory if it exists there, resulting in a handy escalation to root.

This behavior is enabled for all users by default, resulting in a serious vulnerability on many Linux machines. It was fixed and disclosed back in June, but has now been added to the CISA list of known exploited vulnerabilities.

Not in the Threat Model

Intel and AMD both have trusted computing solutions for encrypted VMs, that among other things, encrypt the bits in memory so even a compromised kernel can’t extract data from the running VM. The approaches from both companies are similar, using symmetric encryption with the memory location as part of the encryption Initialization Vector (IV). This means that while the same key is in use, a plaintext value in a given memory location will always be represented by the same encrypted value. Two pieces of research came out this week suggesting that this codebook-like behavior has security ramifications.

Before we dive into the rest of the details, it’s worth pointing out that asymmetric encryption is likely not a viable option for VM memory encryption, due to the processing latency overhead. The exploit here is to physically connect to the memory sticks inside a target computer, and record the encrypted bits. In some cases, an attacker can later run a malicious VM on the same hardware, and use the physical hack to replay the captured bits, allowing easy decryption. Another option is to replay the VM attestation report, falsely claiming that the virtual machine is still fully protected.

What’s initially surprising is that both Intel and AMD have maintained that their SGX and SEV-SNP systems are not intended to protect against physical access. But seeing what is possible with physical modification to system memory, it’s no longer a surprising line to draw. The other interesting note is that so far these attacks are limited to DDR4, as DDR5 memory has a higher data rate, making the entire operation even more difficult.

Bit and Bytes

Red Hat has confirmed that one of its GitLab instances was compromised by Crimson Collective, leading to the exfiltration of over 500 GB of data. This seems to include customer data related to consulting contracts.

RCE Security dug into a product called TRUfusion Enterprise, a data transfer solution that is marketed as undergoing regular audits. It came as a surprise that they found four vulnerabilities that could be called low-hanging fruit. The takeaway: not all audits are created equal, and there’s no guarantee that this style of code review will catch every bug.

Our last two links are both about memory management. The first is from Cybervelia, looking at how to find uninitialized memory access with just a program binary and no source code. Binary Ninja is the tool that really shines here, but it’s certainly not an easy task.

The other is the latest from Google’s Project Zero, taking a look at some non-obvious ways to defeat Address Layout Randomization using careful analysis of hash tables. Very in-depth work, and on-brand for Project Zero. Enjoy!

This week Jonathan talks with Brandon and TC about Veilid, the peer-to-peer networking framework that takes inspiration from Tor, and VeilidChat, the encrypted messenger built on top of it. What was the inspiration? How does it work, and what can you do with it? Listen to find out!

• Veilid.com
• https://gitlab.com/veilid/veilid
• https://veilid.gitlab.io/developer-book/index.html

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.

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

Licensed under Creative Commons: By Attribution 4.0 License

Randomness is hard. To be precise, without dedicated hardware, randomness is impossible for a computer. This is actually important to keep in mind when writing software. When there’s not hardware providing true randomness, most rnd implementations use a seed value and a pseudo random number generator (PRNG). A PRNG is a function that takes a seed value, and turns it into a seemingly random value, and also produces a new seed for the next time a random value is needed. This could be as simple as a SHA256 sum, where the hash output is split to become the next seed and the random value.

The PRNG approach does still have a challenge. Where does the initial seed come from? There are a few common, if flawed, approaches, and one of the most common is to use the system clock. It’s not a bulletproof solution, but using the microsecond counter since the last system boot is often good enough, because there are a lot of them to choose from — the entropy is high. With that brief background in mind, let’s talk about what happens in VBScript. The Randomize call is used to seed that initial value, but Randomize has some quirks.

The first is a great feature: calling Randomize a second time with the same seed doesn’t reset the PRNG engine back to the same initial state. And second, when called without a value, Randomize uses the number of system ticks since midnight as the PRNG seed. There are 64 ticks per second, giving five-and-a-half million possible seeds, or 22 bits of entropy. This isn’t great on its own, but Randomize internally typecasts that number of ticks into a narrower value, with a maximum possible of time-based seeds set at 65,536, which is a lot easier to brute-force.

We don’t know the exact application where the researchers at Doyensec found VBScript generating secure tokens, but in their Proof of Concept (PoC) test run, the generated token could be found in four guesses. It’s a terrible security fail for basically any use, and it’s a deceptively easy mistake to make.

GoAnywhere Exploit

The folks at WatchTowr have a report on a blistering 10.0 CVE in the GoAnywhere Managed File Transfer (MFT) product. This vulnerability was first published on September 18, and the WatchTowr crew took a look at it, and had questions. This bug is a deserialization attack that can land even without any authentication. It can result in command injection, and the latest update from GoAnywhere vendor Forta vaguely indicates that it is being used for attacks in the wild. But this is particularly odd: before the vulnerable interface deserializes, it first checks for a valid signature. And WatchTowr researchers couldn’t find a leak of a valid private key. So how was the vulnerability in use in the wild?

Lucky for us, there’s a part two to this story, but not all of the mysteries are explained. This CVE is indeed being exploited in the wild, with the earliest known exploit being September 10th. Since there was a full week between the earliest known compromise and the release of the patch, it seems unfortunate that it took WatchTowr this long to confirm that this vulnerability was actually exploited in the wild.

Cisco and Public SNMP

Two million Cisco systems are at risk from CVE-2025-20352. This is a remotely accessible flaw in the handling of Simple Network Management Protocol traffic. The attack does require valid credentials, but the attack works using SNMPv1, v2, or v3. While SNMPv3 has more secure user credentials, the earlier SNMP versions just used “community strings”, a text based password that was often set to “public”.

This vulnerability seems to lead to either a crash or a Remote Code Exploitation (RCE). It’s not entirely clear how difficult it is to achieve RCE, but it’s noteworthy that RCE here is run as root, a level of access not usually available even to administrators of Cisco equipment. So far there’s no indication that this was used in the wild, but now that some information and a patch is available, it’s likely not going to take long for someone to reverse-engineer the vulnerability and weaponize it.

More Spilled Tea

Remember the Tea Spilling from a couple months ago? The Tea app had an unsecured Firebase database. It turns out that wasn’t an isolated incident. [Mike Oude Reimer] has been working on OpenFirebase, an auditing tool for FireBase installs. And to prove the point, did an audit on 400 of the most popular Android apps from a trio of categories in the play store, and found 150 Firebase servers that granted unintended access of some sort. That’s a bit stunning, that over one in three Android apps have insecure Firebase servers associated with them.

Github Malware Delivery

There’s a malware campaign that has happened in the last couple weeks, based around Search Engine Optimization and GitHub repositories. The instructions peddle malicious commands to users looking for popular software on the Mac, like LastPass and others. I was prepared to write about how Ad Blocking is really a form of security protection, as these campaigns are often delivered via advertising, but this one seems to primarily be based on real search engine placement.

This isn’t the only malware campaign that takes advantage of GitHub’s reputation as a trusted source of software. A phishing campaign was also recently spotted, where spam messages were added as GitHub issues, with the spammers tagging their victims, and offering fake Y Combinator sponsorships. Since the messages were sent via GitHub, most spam blockers treated them as legitimate. This campaign was a bit more clever than most, making use of domain typo-squatting, with the y-comblnator.com domain used as part of the campaign. The goal here being draining the crypto accounts of people sufficiently fooled by the messages.

Bits and Bytes

Is nothing sacred? In addition to GitHub, malware appears to be distributed via Steam, in updates to games. The most recent example was the Block Blasters game, which was on Steam for nearly two months before shipping malicious code.

How can you figure out whether an image is AI, or has been manipulated with AI or other tools? There’s quite a few approaches, but one of the interesting ones is to look at the JPEG artifacting. If part of the image has ever been compressed via JPEG, this results in blocky artifacts that are hard for the human eye to spot, but easy to see with the right tools.

And finally, in a blast from the past, Supermicro has another pair of vulnerabilities that could allow malicious firmware on server Baseboard Management Controller (BMCs). The way these images are signed is slightly odd, with the various portions of the file signed independently. The attack is to treat these sections like cards in a deck, and shuffle malicious slices into the stack. The verification routine thinks all the important pieces are signed, but during a real boot, the malicious code runs instead. Patches coming soon.