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.
