SANS Stormcast Thursday July 31st, 2025: Firebase Security; WebKit Vuln Exploited; Scattered Spider Update

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/9550.mp3

previous

next

Firebase Security; WebKit Vuln Exploited; Scattered Spider Update

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Thursday, July 31st, 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
 Industrial Control Systems Security. And today on the
 Internet Storm Center website, in our diary, you're trying
 something a little bit different. Now, we had guest
 diaries in the past from not our usual group of handlers,
 but this time we actually tried a little bit of video.
 And the reason behind this is that, well, last week we had
 this huge breach in the Tea application. The breach
 itself, I think, was a little bit stupid in a sense how
 simple it was. But of course, it had a big impact for some
 of the victims affected by the breach. However, when I'm
 talking about breaches here also in the podcast, I don't
 like to do it because I don't like the victim shaming, even
 if some of them may deserve it. I usually try to focus on
 what are the lessons we can all learn from a particular
 breach so we don't end up in the same situation as the
 victim here. And of course, one of the victims here was Tea
 and they made really sort of a very crucial, simple mistake
 with Firebase. A mistake that has been made many times
 before, but has been sort of brought to everybody's
 attention here in this latest breach. Brandon focuses on
 that technical lesson here in his video. Essentially, how do
 you secure Firebase if you have to use it at all? And how
 do you make sure that you're not a victim of the same
 simple exploit that was used here in this particular
 attack? So definitely, if you are coding with Firebase, take
 a look at the video. If you consider coding with Firebase,
 maybe take a look at a video and rethink that decision. But
 anyway, let me see how this works for you, what we should
 change with content like this in the future, and if it's
 overall useful to you. And then a quick follow-up to
 yesterday's Apple patches. I noted yesterday that there was
 no actually already exploited vulnerability in this set of
 patches. Well, that at least is true according to Apple's
 statements. However, Google patched one of these
 vulnerabilities in Google Chrome. And this patch came
 out about a week ago on July 15th. And Google did state
 that it is already being exploited. Now, it's not a
 surprise that Google Chrome sort of shares vulnerabilities
 with Apple Safari. The simple reason behind it is that
 Google Chrome or Chromium does use WebKit, which is the open
 source HTML rendering library that Apple produces. So both
 Safari and Chromium, Chrome, Brave, and Edge share all the
 same parsing library. And with that, also some at least of
 the same vulnerabilities. And CISA released update for its
 report on Scattered Spider. Scattered Spider keeps making
 the news with breaching some high-value targets. So always
 interesting what kind of updates they have here. Now,
 well, some of the updates here are really not that terribly
 exciting. Like, for example, they used some new file
 sharing site. I think it was Mega.nz actually to exfiltrate
 files. Yes, that's bound to always change. But also their
 social engineering part is seeing some changes. And
 that's, I think, part of what Scattered Spider is really
 sort of the most special about. They apparently have it
 down to impersonate various people and not necessarily
 with AI. So there's no real AI component necessarily here to
 it. They're just good at it. They're just good in
 pretending to be someone else. And the latest part here is
 for the posted employees to convince IT and help desk
 staff to provide sensitive information. It's often the
 other way around where a random employee is getting a
 call claiming to come from the help desk. But here's actually
 the other way around, which is actually a little bit more
 difficult for the help desk because they're used to
 receiving calls from users that may be sitting in front
 of broken computers. So authentication and such always
 is a challenge there. Think through the procedures. How
 are you dealing with these challenges? And implement some
 strict procedures here. Also alert the help desk that, yes,
 people will try social engineering. They will try to
 claim it's an emergency and not to fall for these ruses
 and also, you know, how to deal with a real emergency and
 how to distinguish them how to properly escalate things
 without revealing, for example, passwords, access
 credentials or just simple procedures or reporting
 relationships that then later could be used by the attacker
 to further escalate access and, well, basically fool the
 next employee. That's always part of the social engineering
 where you as a victim here may not necessarily really give
 them a lot of data or details, but it's enough to then
 impersonate the next employee in the next phone call. And
 that's sort of how they step up their privileges call by
 call until they have access to the kingdom and launch the
 actual attack. So good report here to read. Definitely given
 sort of the urgency and the currency of these types of
 attacks, definitely something that you should be aware of
 and should stay up to date with. Also from the social
 engineering point of view, not just from indicators of
 compromise and such that are very ephemeral. I usually
 don't even look at them that much in these reports. Well,
 and that's it for today. So thanks for listening. Thanks
 for liking, subscribing, and as always for leaving good
 comments and good ratings in your favorite podcast
 platform. Thanks and talk to you again tomorrow. Bye.