AppSec, Camels, Typhoons, and Backdoors

Welcome back to the F5 SIRT's weekly roundup of whatever news caught the editor's eye, and whatever else we feel like covering. It’s our soapbox, and we’re going to use it! This week MegaZone is once again at the keyboard, and we'll be covering news for the week of March 2-8, 2025.

One thing that wasn't cybersecurity news, per se, which I've been watching in professional horror is how the DOGE team seems to be intent on systematically violating every fundamental tenet of cybersecurity. Connecting unvetted devices to secure networks. Transferring sensitive information to untrusted devices. Publishing sensitive information to the public. Running roughshod over every kind of access control and security check that protect these networks and information. It doesn't matter what your politics are, it is objectively a cybersecurity horror show.

This is a team that couldn't even secure their own website. They've contaminated secure networks which would now have to be scrubbed top to bottom, at great expense, before they could be considered properly secured again. They're doing the kind of things that would get most of us fired if we did them on our corporate networks.

Things like this make me question why we fight the good fight in trying to make things more secure, if it is all going to be thrown out the window in the name of convenience. 'Move fast and break things' isn't a great approach when the systems involved are mission-critical and contain sensitive, even classified, data. Some things can't be fixed - once sensitive data is compromised, that's forever.

But if I continue on this topic I will get into politics, so I'll move on.

AppSec, Hot and Fresh

Some of you may be familiar with the ongoing 'AppSec Monthly' podcast, which is a collaboration of the F5 SIRT and F5 Labs, with occasional guests from within and without F5. I’ve been a regular since I took over as the F5 SIRT's participant last fall. Well, I have some news - AppSec Monthly will no longer be produced. However, it isn't bad news, and it has ceased only to make way for a new podcast, 'AppSec Now'. The goal is to produce shorter, more timely episodes. We're going to try to record each Monday, and sometimes Tuesday when necessary.

The first episode of AppSec Now, entitled Exploring CISA Layoffs, Microsoft's Quantum Chip, MongoDB Vulnerabilities & More, released last week. Ideally we'll have a weekly schedule, and the new cadence will allow us to touch on more stories before they become stale. That was always an issue when planning the content for the monthly release. Sometimes good stories were just old news by the time we recorded. We may have some teething issues as we figure out the new routine, bear with us.

You can keep up with new episodes via the AppSec Now Playlist, and you should check out the DevCentral YouTube Channel for a lot of great content, including some other ongoing podcast series. Most recently, you'll find a lot of AppWorld 2025 coverage.

Apache Camel Kerfuffle

As last week drew to a close, there was a growing clamor in the infosec community about a reported 'Critical' issue in Apache Camel. Nothing had been released officially, and the rumor mill was in full force. With little to no details available, there wasn't much anyone could do. Security teams were being stood up - but could only wait for something tangible to work on. It was a classic example of why sharing unsubstantiated reports without any actionable details is a major waste of community resources, and why coordinated vulnerability disclosure is the right way to handle things. I won't go too far down this road, as in the process of preparing this entry I came across an article posted earlier today (as I write this bit on Sunday), but Kevin Beaumont on Medium: "No, there isn't a world ending Apache Camel vulnerability". He said pretty much what I would. In short, sharing information in this way is being Chicken Little.

So, anyway, we started seeing customer interest in this 'sky is falling' issue toward the end of last week, but information was limited and spotty. So, like everyone else, there was little we could offer in response. That is, until CVE-2025-27636 was published in Sunday. It wasn't given a CVSS score, but it is generally considered to be of Medium severity, and not a Critical issue. The scope of the issue is much more limited than the rumor mill had been claiming. The Apache Software Foundation published a statement about the issue, sent out an email covering the issue, and there is also an associated Jira issue.

With more details now available, F5 also published a Security Advisory for the issue on Sunday and my F5 SIRT colleague, Dharminder, published an article here on DevCentral. The short version is that there is an Attack Signature Update available for BIG-IP Next WAF, BIG-IP Advanced WAF & ASM, and NGINX App Protect WAF, to protect any systems that are 'behind' one of those products. For others, there is also an iRule available for HTTP virtual servers to protect backend systems. Other vendors have also begun to release responses to this issue.

The irresponsible, premature sharing of incomplete information cost an untold amount across many organizations as many people scrambled to get details on this supposed world-ending zero-day RCE, which turned out to be a medium-severity issue with a very limited scope of impact. We need better discipline within these threat-sharing groups, as this is not the first time someone has started a panic over nothing. Spreading unsubstantiated rumors does more harm than good. It panics management, who then demand that 'something be done', but the cybersecurity teams responsible can do little without actionable intelligence. So they reach out to vendors, who then must spin up their own teams, but are just as stuck. And, if there is a real, exploitable issue, it also gives those with nefarious goals a heads-up that they should start looking, while defenders are at a loss.

In the future, I hope we collectively can avoid going off half-cocked, and wait for coordinated disclosure to provide the details. But, given history as an example, I’m not going to hold my breath.

Deja Vu All Over Again

Very often, when working on TWIS, I feel like I end up covering the same thing I have previously. Last time in the hot seat one of the topics I covered was Chinese threat actors, including Silk Typhoon, aka APT27. Once again, they were one of the leading stories of the week. This time the issue is that Silk Typhoon has expanded their operations to include attacks on IT supply chains, to gain initial access to networks. This is according to a new report published by Microsoft Threat Intelligence. This was followed by a report published the next day by GreyNoise which detailed active exploitation attributed to Silk Typhoon.

It's the standard arms race - as defenders address the vulnerabilities they formerly leveraged, they find new ways to crack networks open to expose their succulent centers for exploitation. Their latest move is to focus on remote management tools and cloud applications to obtain keys and credentials they can then use to penetrate deeper into the victim's network. A chain is only as strong as its weakest link - and a network is only as secure as its most vulnerable component. Silk Typhoon appears very adept at using a myriad of different approaches, and rapidly pivoting to adjust their approach as target behavior changes. There's a lot of good information in the Microsoft and GreyNoise reports and I encourage checking them out.

In related news, the day after Microsoft published their report, US government agencies filed criminal charges against alleged members of Silk Typhoon. Internet domains attributed to the group's campaigns were also seized. Now, the indictments don't actually amount to much as those indicted reside in China, and there is little to no chance China will turn any of the individuals over to the US. They'd only be actionable if those indicted traveled to a nation friendly to the US, willing to act on them.

Governments Insist on Breaking Security

The Register had a nice opinion piece on governments insisting on backdoors into encrypted services, effectively killing end-to-end encryption (E2EE) and therefore making their citizens less secure. Everyone and anyone with the faintest knowledge of security knows that you can't put backdoors into encryption without weakening the system and making them more susceptible to attack. Yet governments continue to insist that their ability to snoop outweighs the need for users to be secure, despite decades of evidence of how increasingly important security and encryption are. (Often this takes the form of the classic 'Think of the children!' emotional argument.)

Recent examples include the UK's insistence causing Apple to pull iCloud E2EE for UK users rather than comply and weaken the service. Now those users are left to fend for themselves, and only those technically savvy enough to install and use independent encryption products to locally encrypt data before uploading will be protected. Which, of course, defeats the entire purpose of the government insisting on backdoors in the first place. So sophisticated criminals and technically savvy users would always be able to avoid this form of government snooping. The whole thing is a lose-lose for the average user - whether a service caves and introduces a backdoor, or refuses and pulls all E2EE, the average user is demonstrably less secure.

Not learning anything from the UK's reckless (and frankly stupid) actions. Sweden is also looking at demanding E2EE backdoors - which has Signal threatening to pull out of that country. (And I expect Apple and others would do the same, just like in the UK.) It has been reported that Apple has filed a complaint over the backdoor demands with the UK's Investigatory Powers Tribunal (IPT), so we'll see how this plays out.

Maybe someday politicians and spooks will realize these attempts to weaken security are a fool's errand as there are readily available standalone systems for those who really want to avoid scrutiny, and weakening protections for the vast majority of innocent users is not a worthwhile tradeoff. You just make life harder for the majority of users.

VulnCon Schedule Live

Before I sign off for the week, a plug. As I've mentioned previously, I'm one of the organizers behind VulnCon. VulnCon 2025 is coming up, April 7-10 in Raleigh, North Carolina, USA. This is our second year, and last year was a smashing success, exceeding our best projections. This year is bigger and better with an extra day and an additional programing tracks, so there is even more content to choose from. I know some people were waiting to see exactly what that content would be before registering, and the good news is that the schedule is now live.

Registration for in-person attendance is US$300 through March 15th (that's this Saturday), and US$375 after the 15th, until we sell out. We have an in-person attendance cap of around 400, and we're well along with registrations, so don't delay. While I strongly encourage attending in person if possible, this is a hybrid event and you can also attend remotely for US$100. Remote attendance will utilize Zoom and Discord, and we've taken feedback from last year seriously and have made some changes. While it worked well enough last year, we're hoping it is even better this year, with dedicated channels and Discord monitors for each session, rather than 'track' channels and ad hoc monitors. Having a dedicated channel for each session will allow conversations to continue after the session, and will make it easier to keep discussions for each session separated, compared to the 'track' channels where one discussion often ran over into the next session.

If you are going to attend in person, see my Pro Tip on VulnCon Hotels from my last time in the editor's seat. It might save you a bit.

I am also proud to say that F5 is also one of the event sponsors this year.