Notices by Will Dormann (wdormann@infosec.exchange)

Ooh, another of my NTFS vulnerabilities that I reported years ago was patched today. 🎉
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-32707

I'm at a meeting hosted by somebody else where they're using Microsoft Teams, and in the chat I attempted to share an image that is on my laptop. By clicking the + button and Attach file.

The result of doing this is that Teams puts the image in MY COMPANY'S SHAREPOINT SERVER, and nobody else in Teams can see the image because they DON'T HAVE AN ACCOUNT on my company's SharePoint server. 🤦♂️

Wonders:
1) Has anybody at Microsoft actually tried using Teams?
2) Why do people choose to use Teams?

Aside: If you copy an image and press Cmd - V to put the image in the chat, Teams actually... puts the image in the chat.

It's fruit update time.
https://support.apple.com/en-us/100100

@deepthoughts10
No, Tamper Protection does nothing to stop this.

Neat way to disable Windows Defender (or possibly other AV products)...

Register a no-op AV product in the Windows Security Center (WSC). This action is protected by an NDA that AV vendors sign, and, well...

Anyway, yeah, admin users can do admin things. Don't forget that.

https://github.com/es3n1n/defendnot

Oh, what's that?
'NICIPConfigUpdateDeployment-1745511600265' is not valid?

Oh, let me put my Azure translation hat on. Ok, got it:

You have exceeded your limit of 10 publicly available IP addresses. Please first Disassociate the IP address and then delete it. Otherwise you will get another error message.

Boy, this hat is useful.
Just kidding. There's no such hat.
You need to trudge through things until you brute-force figure things out.

Time to go touch grass...

What's that?

The "Most used by Azure users" VM type that I picked isn't available?

You know what, instead of Go Fish, maybe tell me what I can use?

Edit: Azure Spot pricing apparently isn't a thing. No matter which Size + Region combination you choose, you'll get an error that says that the combo isn't available where you want it. 🤦♂️

What's that? I need to remove the number of data disks in my VM? Maybe tell me how to do this?

Ohhhh... You've selected an Azure VM image that requires more than 4 disks, and the VM type currently selected has only 4 disks? I'm no UI/UX expert, but maybe just TELL ME THIS?

If you create an ARM VM in Azure, beware that your "Recently used size" will be ARM, and as such you will not be able to create any preconfigured x64 VMs.

Because of course if your "Recently used size" is ARM, Microsoft will disable the ability to pick an x64 size. 🤦♂️

Yes, I had to create a sacrificial x84 VM in Azure to work around this. Once my recently used size was x64, I was able to pick any size that I wanted.

Now that I have a local copy of the Commvault VM so that I don't burn truckloads of Azure dollars, I can look at things at my leisure.

AND, it seems that the VM that I have is 11.38.25, which contains the fix for CVE-2025-34028.

EXCEPT the exploit for CVE-2025-34028 still works against it. 🤦♂️

Commvault claims that 11.38.20 and 11.38.25 fixes the watchTowr-reported CVE-2025-34028 vulnerability. (Aside: How is it even possible that two different versions in the same product line are the ones that fix a single vulnerability?) watchTowr discovered the bug in 11.38.20.

I trust watchTowr, so I don't believe Commvault's statement that 11.38.20 fixes the vulnerability that watchTowr found in 11.38.20.

I also trust the PoC that I just ran against 11.38.25, so I don't believe Commvault's statement that 11.38.25 fixes the vulnerability that watchTowr found in 11.38.20.

Yes, I have trust issues. 😕

After successfully touching grass and beginning to write up CVE-2025-34028...

CVE-2025-34028 is a path traversal vulnerability. And yes, the path traversal allows for an unauthenticated attacker to plant files in arbitrary locations. And presumably Commvault has fixed the path traversal part.

BUT, what about the fact that deployCCPackage() is reachable by design (by way of deployServiceCommcell.do being explicitly listed in authSkipRules.xml)?

Directory traversal aside, in what world does the ability for an unauthenticated client to deploy a Command Center package make sense, whatever that means? 🤔

Ok, after a lenghthy call with Commvault:

The 11.38 version of Commvault is what's referred to as the "Innovation Release" of the software, where the expectation is that "Pioneer customers" register with Commvault and are specifically approved to even see updates that are available.

The problem with this:
Customers who fire up a Commvault 11.38 VM through Azure or the like did not to through the front door of registering with Commvault. As such, they would NOT SEE UPDATES AVAILABLE. This was... not ideal.

However, based on what the Commvault engineers did on the call that just ended a few minutes ago, they just have changed the backend to provide the "Additional updates" that fix CVE-2025-34028 to weirdos who use Azure such as myself.

That is, as of about 10 minutes ago, all Commvault 11.38 users can get the fix for CVE-2025-34028 by:

1. In Manage -> System -> Maintenance, click Download or copy software
2. Click the Download button (and Next and Run)
3. In Manage -> Servers, click the ⋮ under Actions and click Upgrade software
4. Watch the software update.
5. In Manage -> Servers, click the and click the number next toAdditional updates`
6. Confirm that you have SP38-CU20-433 and SP38-CU20-436 (if you're runing 11.38.20) or SP38-CU25-434 and SP38-CU25-438 (if you're running 11.38.25).

NOTE: With the "Innovation Release" (11.38) version of Commvault, the build number does NOT change with the installation of additional updates. That is, 11.38.25 is both vulnerable and not vulnerable to CVE-2025-34028, depending on whether the relevant Additional updates are installed.

You're all welcome. 😂

I'll admit that even with the updated explicit instructions on how to get Commvault updates, I fail to see how one can get these mythical SP38-CU25-434 and SP38-CU25-438 optional updates.

When I first go to "Download or copy software", Commvault tells me that I'm Up-to-date

If I manually force a download of Latest Fixes for Current Release: 11.38.25, I get an installer that specifies:

And if I run this installer and even reboot for good measure, the system is still vulnerable. And the jar that contains the vulnerable code, cv-ac-common.jar has not changed from my original 11.38.25 vulnerable system.

I'm not particularly good with computers, so hopefully Commvault sysadmins in the real world are better at this than I am. But I'll admit that even with explicit instructions, I have no idea how to get the updates that protect me against CVE-2025-34028.🤷♂️

Oh, wow.

Only after pestering the Commvault PSIRT did they update the language of their advisory.

While it still incorrectly says that 11.38.0 - 11.38.19 are affected and that 11.38.20 is resolved (it is not), the've added a section below this misinformation to convey the actual state of the world:

11.38.20 is only patched if it has the SP38-CU20-433 and SP38-CU20-436 additional updates installed.

And 11.38.25 is only patched if it has the SP38-CU25-434 and SP38-CU25-438 additional updates installed.

I cannot think of a behavior that is more vindictive to their customers to botch language in an advisory so bad, and also to not bother bumping release versions for the fixes for a CVSS 10 EITW vulnerability. 🤦♂️

If we compare pre-patch and post-patch versions of Commvault, we can see that the fix for CVE-2025-34028 is that the endpoints of webpackage.do, deployWebpackage.do, and deployServiceCommcell.do are no longer exempt from authentication. And while they were at it, they removed the web endpoints altogether.

So yeah, while the CVE entry for CVE-2025-34028 indicates that the vulnerability is a directory traversal, the real vulnerability is (IMO) that an unauthenticated user can install packages on a Commvault server.

Sure, the directory traversal makes the impact bad. But the underlying problem is that the endpoint can be reached by unauthenticated users. And that's what was corrected with the updates.

@ryanc
If you find one that works, test posting an animated GIF.
Last one I tried failed to retain animation because BlueSky is weird in that it requires that you post GIFs as videos instead of images.
This is the point that I lost interest in cross posting. 😂

@GossiTheDog @mttaggart
Not sure what you mean...
My hotmail account is passwordless? (Locally it uses a PIN)

Unless you're talking about something else?

@mttaggart @GossiTheDog
In my case:
Windows 11 Enterprise with a local account initially (via BYPASSNRO)
I added a Microsoft (hotmail.com) account.
I then turned on RDP.
That's all. Absolutely nothing else.

If I log in via that hotmail account to RDP, it will accept the original cached password even if I change my hotmail account password.

@mttaggart @GossiTheDog
Hm, that all sounds different than what I tested.

@GossiTheDog @mttaggart
Yeah, I didn't have a local AD ready to test.
But I could definitely see a difference with authenticating RDP using a local account vs. an online account.
With local accounts, the instant the password changes, the RDP client needs the new password.
For online accounts, the old password still works, indefinitely.