Hello and welcome to the Wednesday, December 17th, 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 Graduate Certificate Program in
Cybersecurity Leadership. I want to start today's podcast
not sort of with breaking news, but with an issue that
has come up beginning of the month and is something that
you probably should address early next year. So now is the
time kind of to get ready and get organized to get this
worked out. And that's Microsoft discontinuing RC4
for all the occasion. Hopefully for your
organization, this will be really a non-event. And the
last version of Windows that did require RC4 was Windows
Server 2003, if I remember correctly. So hopefully you
don't have 20 plus year old systems around. But we all
know it's easier said than done. And yes, sometimes these
legacy systems are hanging around. So what Microsoft did
in order to support this transition is that they came
up with an extensive blog or website here beyond RC4 for
Windows authentication that goes over some of the steps
that you can take in order to make sure that you won't be
affected once RC4 will at least by default be disabled
for authentication with Active Directory. Now that turnover
will be mid next year. So again, you still have some
time. And what they did now to get ready for it was to enable
additional logging in the security events that basically
log what authentication mechanisms are used and what
are available. If you do have one of the newers like AS and
such available and you still use RC4, well, in this case,
it may just be as easy as changing the particular user's
password, which again, may not necessarily be easy. They also
do provide PowerShell scripts to search your logs for any
accounts that may need to be updated and set up an email
address that you can use in case you're running into any
devices or such that just won't work with RC4. If you do
run into this situation, you can't really get this resolved
by mid next year. There is an option to still manually
enable RC4. So it's not that you're sort of left out in the
cold here, but it's definitely something that you should
address. And it's probably going to point you to a bunch
of devices that you probably should have retired a long
time ago. And well, this may be sort of the last push it
takes to actually make that happen. So like I said, not
breaking news, but something that you definitely should
tackle. And beginning next year is probably when you sort
of should have a plan ready and figure out how much this
affects you. And last week I mentioned that Fortinet did
publish a single sign-on authentication bypass
vulnerability in its FortiGate devices. This affects any
device that is using the FortiCloud single sign-on in
order to authenticate. Arctic Wolf now says that they have
seen active exploit attempts against this vulnerability. So
you must get your systems up to date. Now, if you can't get
them up to date, again, there is a workaround. You basically
just disable the cloud-based single sign-on feature and use
local authentication. And then you should be good here. They
also point out that as part of these exploit attempts,
attackers were then reading configuration files. As
always, and we have seen this many times before, if a
compromise like this happens, you must change all local
credentials stored on the device. This may include any
seats for multi-factor authentication. Not sure if
that applies here in this particular case, but that's
something that has sort of caused problems for people
where then later they were compromised even though they
had multi-factor authentication enabled. But
the seats were not changed and as a result, the attacker was
able to replicate the two -factor authentication tokens.
And Horizon 3 published a blog post with details regarding
three different newly discovered vulnerability in
FreePBX. A couple months ago, we sort of had this fire trail
where we hadn't already exploited vulnerability being
patched in FreePBX. This research sort of evolved out
of looking into this earlier vulnerability. So three
vulnerabilities. Two of them are SQL injection
vulnerabilities that could lead in the worst case to
arbitrary code execution vulnerability. Similar to the
prior exploit, the way this is exploited to actually achieve
remote code execution is by actually using the SQL
injection to add data to a ground job table that's being
maintained in SQL and then is being used to periodically via
cron launch various scripts. And if the attacker can add a
script to that table, they have arbitrary code execution.
Now, the newer version of the SQL injection vulnerabilities
does require authentication. However, that's where the
third and in some ways most critical vulnerability comes
in. There is an authentication bypass vulnerability that can
then be leveraged with these other vulnerabilities to gain
unauthenticated full code execution. Well, the only good
thing about this vulnerability is it's not exploitable in the
default configuration. You need to send your
authentication type to web server, which is not the way
it's usually configured, but at that point, if you are
vulnerable, it's exploitable by just sending a specific
header. And with that, you essentially bypass
authentication. So definitely get this patched. And even the
authenticated vulnerabilities could be an issue depending on
who you have authenticating to your free PBX server. Well,
and this is it for today. So thanks for listening and talk
to you again tomorrow. Bye. Bye.
