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

previous

next

Cloudflare Response to 1.1.1.1 Certificate; AI Modem Namespace Reuse; macOS Vulnerability Allowed Keychain Decryption

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

New Discussions closed for all Podcasts older than two(2) weeks
Please send your comments to our Contact Form

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.