Handler on Duty: Xavier Mertens
Threat Level: green
Podcast Detail
SANS Stormcast Friday, September 5th, 2025: Cloudflare Response to 1.1.1.1 Certificate; AI Modem Namespace Reuse; macOS Vulnerability Allowed Keychain Decryption
If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9600.mp3

Cloudflare Response to 1.1.1.1 Certificate; AI Modem Namespace Reuse; macOS Vulnerability Allowed Keychain Decryption
00:00
My Next Class
Application Security: Securing Web Apps, APIs, and Microservices | Las Vegas | Sep 22nd - Sep 27th 2025 |
Application Security: Securing Web Apps, APIs, and Microservices | Denver | Oct 4th - Oct 9th 2025 |
Unauthorized Issuance of Certificate for 1.1.1.1
Cloudflare published a blog post with more details regarding the bad 1.1.1.1 certificate that was issued by Fina.
https://blog.cloudflare.com/unauthorized-issuance-of-certificates-for-1-1-1-1/
AI Model Namespace Reuse
Deleted accounts on Huggingface can be taken over by other entities unrelated to the original owner.
https://unit42.paloaltonetworks.com/model-namespace-reuse/
macOS vulnerability allowed Keychain and iOS app decryption without a password
Excessive entitlements for the gcore binary facilitated access to key material that was sufficient to access secrets stored in Apple’s keychain.
https://www.helpnetsecurity.com/2025/09/04/macos-gcore-vulnerability-cve-2025-24204/
Application Security: Securing Web Apps, APIs, and Microservices | Las Vegas | Sep 22nd - Sep 27th 2025 |
Application Security: Securing Web Apps, APIs, and Microservices | Denver | Oct 4th - Oct 9th 2025 |
Application Security: Securing Web Apps, APIs, and Microservices | Dallas | Dec 1st - Dec 6th 2025 |
Application Security: Securing Web Apps, APIs, and Microservices | Orlando | Mar 29th - Apr 3rd 2026 |
Network Monitoring and Threat Detection In-Depth | Amsterdam | Apr 20th - Apr 25th 2026 |
Podcast Transcript
Hello and welcome to the Friday, September 5th, 2025 edition of the SANS Internet Storm Center's Stormcast. My name is Johannes Ullrich, recording today from Jacksonville, Florida. And this episode is brought to you by the SANS.edu Master's Degree Program in Information Security Engineering. Today I want to start with a story that I well ended yesterday's podcast on, and that's the rogue certificate that was issued for 1.1.1.1. Whenever we have sort of a trust issue here with the certificate of authority system, in particular if it affects a critical resource like this public DNS server, it's certainly worthwhile looking into it a little bit further. And that's what Cloudflare did now. Cloudflare published a blog post with additional details that they're investigating as part of this incident. So the main concern here we have with this particular incident is the use of TLS in protocols like DNS over TLS and DNS over HTTPS as they're being used with these DNS servers. And of course certificates are being used in order to verify that you're connecting to the correct resolver in this case. And in particular when you're connecting to a DNS resolver, you are often connecting using an IP address, not a host name. So as a result, the certificates involved here must include the IP address. And that's exactly what's happening here with the Cloudflare DNS certificate. It does include the 1.1.1.1 IP address as well as other IP addresses. And of course, the host names that this particular server is also known under in case a user uses that to connect. Typically Cloudflare uses DigiCert for its certificates, not this particular set of authority that issued the 1.1.1.1 rogue certificate. Cloudflare states that well they talked to them and they basically were told that this certificate was issued as a test. Now this is still a breach of trust as far as certificate authority best practices go. If you are issuing a certificate as a test, well you're supposed to use a test certificate authority. There are a number of host names that were part of the certificate. Most of them were obviously tests like test.hr and the like. FINA was the name of the certificate authority that did it. At this point, Cloudflare did not notice any abuse of this particular certificate. So the story seems to be right that it was used for some internal testing, but again still not good, still not what's supposed to be happening. Also Cloudflare looked at its own procedures. The problem from Cloudflare's perspective was also that Cloudflare didn't detect this bad certificate. It was added to certificate transparency logs and as such, Cloudflare should have been able to detect it. But they're now refining some of their internal procedures to get better and more timely alerts in case something like this happens. And I always recommend this to people. Set yourself up with the certified transparency log alerts. There are a couple free options that you have in order to get these alerts. Facebook, for example, is one that I use the day as part of developer tools sort of have an alert even will alert you off some lookalike names. But there are plenty of other options that you have. And actually even Cloudflare itself will alert you off certificates that they notice for domains that they are handling. So definitely build some scripting and such around it to make sure that you get accurate alerts and then also some actionable alerts, not just a bunch of false positives from people registering legitimate certificates. In this particular case, it should be pretty obvious because of the use of this, well, I don't want to call them necessarily obscure because they're part of the Windows trust or but of sort of authority that certainly Cloudflare usually doesn't interact with. And for anybody using AI models, just a reminder that well, you have to be careful what the name of a particular model is. Palo Alto's unit 42 has an interesting blog post here outlining some of the risks in particular when it comes to hugging phase, which well is sort of the de facto GitHub for AI models. The problem is that models name is usually the author or basically account name within hugging phase followed by whatever identifier this author assigned to their model. And the problem comes up and we had similar issues with GitHub where if an author removes their account, someone else can re-register an account with the same username and then essentially replace this particular author's models. Sometimes, well, for good by sort of keeping software dependencies working, sometimes for bad by actually replacing them with a malicious model or malicious code. And again, also remember that many of these models are really just the Python pickle files. So essentially code that you're executing as you are loading these models. Really something to be, like I said, to be careful about. There is not really much you can do about it. Other than that, to watch for certain changes, pin versions. But then again, you also probably want to have the latest, greatest model and you want to keep updating your models. The article goes to more detail what some of the signs are of a possible issue with a name change and ownership takeover. But overall, there isn't really much you can do other than be careful and alert. And HelpNet security has a good summary of a talk presented at Nolcon in Berlin. Security researcher Ko Nagagawa did publish a paper at the conference or a talk that demonstrated how recently patched vulnerability in macOS can be used to essentially get access to the user's keychain. The problem here was the G -core utility that basically had excessive permissions in the form of additional entitlements. That's sort of how macOS restricts what software can access what parts of the operating system. G -core is used to create core dumps of processes. And core dumps typically include memory, but they're not supposed to include, well, protected memory that is being used to store keys and the like. And that's exactly what happened here. You could use G -core to get a complete memory dump of utilities that access the keychain. And with that, you gained access to the master key being used to actually encrypt and then decrypt the keychain file. So that was the core of this vulnerability. And yes, certainly exploitable. And yet another reason why you want to upgrade to macOS 15.3, which fixed this particular vulnerability. Well, and this is it for today. Thanks again for listening. Thanks for liking and subscribing to this podcast. And talk to you again on Monday. Bye.