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

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.

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.

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?

• https://www.kwaai.ai/
• https://blog.cryptographyengineering.com/2025/02/23/three-questions-about-apple-encryption-and-the-u-k/

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, 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!

• https://tuxcare.com/blog/
• https://tuxcare.com/endless-lifecycle-support/net-eol-support/
• https://enterpriselinuxsecurity.show/

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, 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!

• Nand2Tetris

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, 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!

• CentOS primer
• Migration from CentOS
• Rocky Linux
• RESF FAQ
• CIQ Open Source Ethos

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, 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!

• https://blog.thunderbird.net/2023/11/the-untold-history-of-thunderbird/
• https://techcrunch.com/2012/07/06/so-thats-it-for-thunderbird/

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